permissioned bundle/contract-installation limits

What is the Problem Being Solved?

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

TBD

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

[warner]

From our conversation today, it sounds like:

• the core-bootstrap code ugprade mechanism (#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 #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.