Add gopherwatch sumdb verifiable index testing log

[mjl-]

vindex.gopherwatch.org is running https://github.com/transparency-dev/incubator/tree/main/vindex/cmd/sumdbindex. See https://vindex.gopherwatch.org/

It would be nice to get its output log witnessed, Martin added the necessary code to sumdbindex earlier today.

The vkey name is vindex.gopherwatch.org, but the actual tlog endpoints for the verifiable index are at https://vindex.gopherwatch.org/outputlog/. I think the vkey name can be considered "just an identifier", but ideally it would point to the actual tlog endpoint... See Martin's message in #vindex on the transparency-dev slack for more info and options.

Given the sumdb /latest refresh interval of 5 mins, I'm expecting 12 updates per hour, 288 per day. The specified qpd value is for an interval of 10s. Would it be better to set this closer to the expected rate, rather than specifying a higher value to leave room for future rate increases? I could also request an update to the qpd in the future when needed...

Let me know if discussion on the witness-network mailing list is preferred!

[AlCutter]

Hi @mjl-, nice!

On the qpd question, I'd say set it to something you reasonably expect to grow to.

What's happening here is that we use these values to bin-pack capacity requested by logs into fixed-dimension buckets, so in effect you're essentially "reserving" capacity in witnesses. Updating that reserved capacity later may be possible, but is not something we've thought much about, and may e.g. require bumping your log to a different bucket.

[mjl-]

Thanks Al. I changed the qpd to 288, which is what I expect it to be under normal circumstances. This is still just testing, so if anything needs to change, that's all fine. But no need to reserve capacity on these witnesses if we likely won't need it.

I think the question ("what's a reasonable qpd for me?") will come up more in the future, where people have lower-volume logs that could be checkpointed on-demand.

[AlCutter]

I think the question ("what's a reasonable qpd for me?") will come up more in the future, where people have lower-volume logs that could be checkpointed on-demand.

Yup, I agree, and this is one of the reasons for using QPD over, say, QPS - mostly-quiescent-but-occasionally-bursty on-demand don't have to struggle too hard to answer, and peaky demand bursts will likely be uncorrelated across many logs.

I also expect we'll see larger and more scalable witnessing services appear with sufficient headroom to make it moot for some time to come; it'll be a great problem to have if these then start having to worry about capacity :)