zoe contract legibility, invitation legibility properties

[dckc]

An important feature of our system is that contract participants can know what code is going to run before they accept an invitation. Code goes on chain in source form, not compiled. Installations are first-class objects that appear in Zoe invitations.

I asked @erights if we had written up the motivation for this, and it turns out we have: invitation legibility for higher order smart contracts, aka "the Fred problem" was written up in the 2003 Digital Path paper, with Alice selling her position in a covered call to Fred. In particular, see Figure 3.7 Layered games.

The contract host was introduced a bit earlier in the paper, around Fig 3.5. Parties to the contract rely on it to be sure they are playing the same game, i.e. executing the same code.

Zoe is an evolution of the contrct host. Note that Zoe serves as one contract host for many contracts. Note the seats in the figure correspond to seats in the Zoe API.

The 2013 Dr. SES paper updates the work for use with ubiquitous technology, i.e. JavaScript. It shows the contract host in Fig. 3., but it doesn't discuss higher order smart contracts.

cc @Tyrosine22 @Chris-Hibbert

[dckc]

governance adds a tricky wrinkle:

• Resolve Invitation Legibility under parameter governance agoric-sdk#4822

[dckc]

Agoric’s Composable Smart Contract Framework Reaches Mainnet-1 Milestone has some good discussion too.