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

[warner]

Problem Description?

zoe is widely shared; everyone is welcome to E(zoe).offer(). But contract installation is a power reserved to the BLD stakers, in MN-1. By POLA, different authorities should be represented by different objects. So E(zoe).install() should move to some other object.

Original Description

Under what circumstances should a new contract be installable on MN-1? We don't want to admit a lot of unvetted code until a later stage, but we might still decide to install some new carefully-audited contracts during MN-1: how does the chain know what is ok and what is not?

When we switch to MN-2 and start to open it up, this mechanism will change. How?

There are a couple of separate aspects to this question:

• what policy do we want?
• how is this policy enforced?
• how will we execute a change in that policy?

Two implementation tools which come to mind are:

• a cosmic-swingset guard around the SwingSet.installBundle txn/message type
  • this protects controller.installBundle(), which is how a code bundle gets installed into the kernel and made available for zoe installation
  • anyone who can invoke this gets to consume significant storage space on the chain
  • this could require the txn be signed by some hardcoded list of addresses, or by an account that has at least one magic "install" token
• an ocap-style guard around zoe~.install()
  • I think install is on the Zoe public facet, making it widely-held
  • we could move it off that facet and restrict access to some other object, but then we need to implement that other object

In the long run, we may want to use deposits of some sort, or something to make sure the installer 1: is serious, and 2: is providing long-term benefit to the chain, both to compensate for the cost they're imposing upon validators and their storage space. Paying a fee proportional to the size of the installed bundle (and remembering the perpetual storage obligation they're purchasing) might be enough. Discouraging spam is important.

But fees are independent of our policy around permissioned/permissionless contracts, and the latter needs a concrete mechanism to be in place by MN-1.

Description of the Design

Separating out the installation authority into a separate ocap.

Security Considerations

We'll rely upon this mechanism to protect the chain against malicious contracts that might seek to cause a chain halt, or to cause non-determinism and validator problems.

Test Plan

TBD

[dckc]

This overlaps with #3724; is it a dup?

[michaelfig]

@warner I would prefer to just charge fees for bundle installation at the Cosmos level. Otherwise, we're forced to use ACLs or the possession of a Cosmos token to decide who is allowed to do it, and that's a political problem.

Much better to do the ocap split you're suggesting, and initially say "governance has access to E(zoeInstanceManager).install() and instantiate()", then later another governance action can distribute the ZIM to everybody's wallet, which is the kind of operation we already support in core bootstrap.

[dckc]

an idea: home.zoe1 wraps zoe so that install and startInstance always throw.
full home.zoe is only granted in the sim chain. It was simple enough that I coded it up: #4405

[warner]

From our conversation today, it sounds like:

• the core-bootstrap code ugprade mechanism ("Big hammer" Cosmos governance via bootstrap code evaluation #4352) will retain access to the full-powered zoe object, so a governance action can evaluate code that grants it to parties that did not have it before
• the install-bundle cosmos transaction will require fees but is otherwise available to all users
• in MN-1, all users will get a home.zoe (or home.zoe1, TBD) object which goes through a forwarder that denies access to .install and .startInstance
• when MN-2 starts, a governance action will use the "Big hammer" Cosmos governance via bootstrap code evaluation #4352 upgrade to define a "contract review committee" and give it access to the full-powered zoe, allowing that group to perform installs
• when MN-3 starts, a similar action will change the forwarder that all users get to start allowing .install and .startInstance

I want to make sure that the MN-3 transition doesn't require a for loop over millions of user objects: it should only change one forwarder's behavior. I think that means users should get home.zoe instead of home.zoe1, despite the potential confusion of "but it says zoe, why doesn't it provide all of Zoe's methods?".

[dckc]

@erights , @dtribble suggests another approach to this issue:

It's worth considering just separating out the instance creation authority into a separate ocap.

I suppose part of my hesitation to consider it is the amount of tests and docs such that it would impact.

That effort seems better directed at Zoe 2.

[dckc]

As discussed in yesterday's Zoe meeting:

This risk is mitigated by the policy that mailbox/ag-solo access is limited to devnet (#5965), so home.zoe is not so widely available.

I was concerned about postponing this, as it would mean a backwards-incompatible upgrade of zoe. But it's not clear that we need to share zoe widely until MN-3, at which point installation is permissionless anyway. So while this would be nice to address, we don't seem to have any essential requirement for it, as long as we charge sufficiently for InstallBundle transactions (#6858).

[erights]

Another consideration: Our MN3 is permissionless. But our stack is not just for ourselves. From the beginning (see https://www.youtube.com/watch?v=52SgGFpWjsY&list=PLzDw4TTug5O1oHRbp2HkcvKABAY9FKsmG&t=154 at 2:34) we are building our stack to run on chains and non-chains, public, private, permissioned, permissionless, etc. Our current experience already reveals that, for some uses and some scenarios, it is useful to separate the ability to install a contract from the ability to instantiate and run installed contracts. Given that experience, POLA suggests that we do separate them into separate objects. Then, for permissionless chains including our MN3, we just make both objects generally available. But there's no need to bundle them together into one object.

Clearly this is not an immediate issue for the Vaults release. Important but not urgent.