separate E(zoe).startInstance() authority from E(zoe).offer()

[rowgraus]

Description

In Mainnet1 and Mainnet2, we share E(zoe).offer() access widely, but until Mainnet3, we restrict access to E(zoe).startInstance(). This reminds us of rule # 1 of ocap design: separate authority should be on separate objects. Having both on the same zoe object is awkward.

Solution

E(zoe).startInstance() should be moved to a separate ocap returned from Zoe creation, and should be provided to appropriate services which are allowed to create other contracts as private arguments in their construction. (See #4395 for doing likewise with E(zoe).install().)

[dtribble]

There are 15 uses of zcf.getZoeService() in the system. Only 2 appear to use that to create contract instances. Those contracts would need the additional contract creation object to be provided,

[dckc]

hm... without REMOTE_WALLET privilege (for ag-solo), one can't do REPL nor deploy script stuff, so you can't provoke E(zoe).startInstance().

that is: in the PSM config (#6009), this is addressed by #5965.

[ivanlei]

from @Chris-Hibbert in slack

The issue is about removing some authority from the public I/F of Zoe in line with POLA expectations. That same functionality would need to be made available in other ways in order for us to continue to create new instances of contracts.
Up to at least MN2, the only contracts that need to be dynamically instantiated are probably for governance (ballot counter, e.g.).
But after MN2 or MN3, there will be other contracts that we'll want people to be able to make new instances of. We can wait until we need this to be available to settle on a design for "permissioned instantiation". (fees seem like an obvious choice, but I'll be we have other ideas.)

[dckc]

postponing as discussed in yesterday's Zoe meeting: #4395 (comment)

[dckc]

where to track separating E(zoe).startInstance() authority from E(zoe).offer()?

Mainnet1 and Mainnet2 both require contract installation and instantiation to be approved as a result of governance.

True.

Those features must therefore be removed from the Zoe service object that is available in home and that is available via the zcf.getZoeService().

False. We found another way to control access to E(zoe).startInstance() while providing permissioned instantiation of contracts:

• constrain mailbox to devnet config, to protect against c-list/liveslots DoS attacks #5965
• feat(vats): implement "big hammer" governance #4642

So the issue stated in the title here has been addressed.

But...

Rule # 1 of ocap design: separate authority should be on separate objects. Therefore, these operations [startInstance] should be moved to a separate ocap returned from Zoe creation

is still true. So we should address that, along with...

• separate E(zoe).install() authority from E(zoe).offer() #4395

So I'm inclined to re-scope this issue to be about separating offer() access, which is shared widely, from startInstance() access, which is more closely held.