verifiability of vote counters requires one vat per question?

[dckc]

Describe the bug

In the internal demo (#3869), it seemed awkward / expensive that each call to Registrar.addQuestion() instantiates a vote counter contract in its own vat.

For reference: as of the demo, the execution cost was around 5 RUN, which was occasionally a practical issue. (or perhaps that was to instantiate the registrar contract, but the amounts were similar.)

To Reproduce

Steps to reproduce the behavior:

1. Visit the demo; make a committee.
2. As registrar, try to add a question with less than 5 RUN in your Zoe fee purse
3. bzzt. you lose. (I forget what the diagnostic was)

Expected behavior

Good question. Maybe this is as good as it gets? Does asking a question need to cost substantially less than 5 RUN? With "zygotes" (#2268), perhaps contract instantiation will be substantially cheaper.

Additional context

the context was an internal demo (#3869), using a branch of the governance contracts from #3448 .

cc @Chris-Hibbert @katelynsills @dtribble @rowgraus

[Tartuffo]

@dckc This was an overlooked New Issue. Do we need this for Mainnet 1?

[dckc]

I opened this on behalf of @dtribble . I'm assigning him in the customer role.

[dckc]

p.s. since the provisional Zoe fees went away, the 5 RUN charge is no longer.

[Tartuffo]

Resolve the design for MN-1, and then determine if we need to do anything from MN-1.

[Chris-Hibbert]

I don't know of a requirement to reduce the usage of vats for MN-1.

@dtribble, @rowgraus ?

[Tartuffo]

@dtribble Is this really needed for MN-1?

[dckc]

@warner and I did some testing today using the fact that each question results in a new vat to reach the maxVatsOnline threshold so that vats get paged out. Paging back in worked pretty much as expected, but it did remind us about this cost.

[warner]

One vat per vote is one kind of expensive, but never terminating that vat is a bigger kind of expensive.

[dckc]

@Chris-Hibbert I think I have heard you say that it's straightforward to have one contract count votes for multiple questions. If so, that reduces the scope of this issue from a design question to an enhancement to make it so, yes?

[Chris-Hibbert]

The remaining design question is how to satisfy the governance requirements about legibility and such. I'm pretty sure there's a straightforward answer, but it'll require a more complex validation approach to assure all participants that the dependencies are addressed.

[Chris-Hibbert]

Another approach came up in conversation with @warner. One of the objectives of this ticket is reducing the cost to the chain of using one eternal vat per vote. If the voteCounter records its outcome to vstorage in a place that can be reliably located, the vat doesn't have to stick around. I haven't spent any time looking at the details, but my instincts say that the outcome could be indexed by the electorate, and that would cover the long-term dependencies. According to Brian, single-use vats that go away after use are much less expensive than ones that can't be deleted.

If this becomes a priority to address, I'd recommend a redesign that presumed that concurrent users could get the vote outcome via a promise, and later clients would expect to access it via vstore. Then the voteCounter vat could resolve its outstanding promises, wait for quiescence, and then exit, and that would serve all the durability and legibility needs of Governance.

[aj-agoric]

THis issue came up in today's Kernal meeting. Looking to move this into coming work to help with performance.

[dckc]

for follow-up, see:

• Drop used voteCounter vats #9372