Contract Host without installations

[DavidBruant]

One problem i see with current ERTP is that studying an invite takes to do host.getInstallationSourceCode(invite.getBalance().installation) and invite.getBalance().terms (this feels a bit awkward to get one part one way and the other part a different way). In another issue, i suggest creating a host~.getInviteContractSourceCodeAndTerms(invite) method which unifies getting both at the same time

Taking a step back, i'm starting to wonder whether installations are useful at all. I remember that in my first encouter with ERTP, the 2-step process to get a contract started felt weird (host~.install(source)~.spawn(terms)), but i took it as granted. With more experience, i'm questionning whether the additional complexity is worth it.

I feel installations could be removed alongside the following changes:

• host.install(source, terms) (maybe rename the method to run or start or instantiate or startContract something else)
• the invite payment does not carry terms or installation any more. Terms + source are acquired via a new host~.getInviteContractSourceCodeAndTerms(invite) method (or any better name)
• check* methods are methods placed directly on the invite payment (on the usage side, this changes invite.getBalance().installation.check*() to invite.getBalance().check*())

[DavidBruant]

check* methods are methods placed directly on the invite payment

This probably requires to change inviteMaker.make to accept an object with the check* methods as last argument

This allows for another change/simplification:

• host~.install (or whatever new name) doesn't need to be an object with a start source code string. It can be directly a string

[DavidBruant]

If ERTP is considered already in use and this change is wanted, it might be a good time to start using semver

[michaelfig]

I like the direction this is going. Just one change: host~.install(source, moduleFormat='object') is the current signature, since it also supports different moduleFormats (notably the getExports format that allows for @agoric/bundle-source to create inputs for the contractHost).

Unfortunately, we can't put check* on the invite payment, because the restrictions of @agoric/marshal mean that we can't have both data members and methods on the same object.

I am uncertain as to whether we should be investing more time in contractHost, or if you are just looking for something I'd like to fill with a new spawner interface. Are you actually needing the inviteMaker?

[katelynsills]

I view contractHost as close to being deprecated, with its functionality split between Zoe (as a smart contract runner) and spawner as a generalized Vat spawner + code runner (am I characterizing it right, Michael?). I think it was good for us to document the contractHost and find its pain points, especially to check whether those pain points are eliminated with Zoe, but we shouldn't be recommending that people use the contractHost at this point.

[erights]

The inviteMaker enables transparency for joining a vat computation in progress. I like that the programs we are now inclined to call "contracts" are those that plug into Zoe, and that Zoe provides its own level of transparency for contracts.

But it is still useful to be able to invite someone to join an arbitrary program execution transparently, where the computation can be written so that other party can reason about what they're joining. Example:

How would I write a new mint/assay pair, such that those I invite to coordinate on the assay can tell what this assay means? When it is an old well known assay, then we solve it by assumption. The spawner with invites enables us to leverage this assumption for the spawner as a whole in order to gain credibility for a new assay.

[katelynsills]

How would I write a new mint/assay pair, such that those I invite to coordinate on the assay can tell what this assay means?

Can you elaborate on this? I'm not sure I understand how the spawner helps.

[erights]

I don't know about the spawner specifically. I am reasoning by analogy to the contractHost. @katelynsills and I just talked verbally. I am thinking about how I'd start a new mint/assay under the contractHost, and create invites to the new assay, so that others could leverage their prior knowledge of the contractHost into credibility in the logic of the assay they've just been invited to join.

In this case, the invite has no need for exclusivility. It lies in a different corner of our erights taxonomy that we haven't built yet. But it needs the same transparent assayability that objects don't have.

[DavidBruant]

I view contractHost as close to being deprecated

If i understand correctly what @Chris-Hibbert recently told me, this seems to be Agoric position (to deprecate contractHost in favor of Zoe). I had written this github issue before being aware of this :-p

[erights]

As a host of contracts, contractHost is indeed deprecated. However, it is already close to what we need as a transparent spawner of vats with assayable invites. Obviously its name needs to change, let's say to "spawner", and the TODO for actually spawning vats must be something we really do. Anything contract-specific about spawner, however, should probably be killed, with corresponding Zoe mechanisms taking their place. Anything that remains analogous between spawner and Zoe should be made not gratuitously different, and we should fold back in to spawner any lessons learnt doing Zoe.

[erights]

At https://github.com/Agoric/ERTP/issues/70#issuecomment-553662327 @Chris-Hibbert wrote:

so the clients can see what code the mint is running

That's why the spawner still needs the inviteMaker, so that Alice can tell that an alleged X (for example) that she receives from Bob is indeed the X run by that spawning of that code. Some of these will need the exclusivity of the existing invites. Many won't. All will need the assayability provided by the existing invites.

[warner]

this was issue 215 in the old ERTP repo

[katelynsills]

I'm going to close this issue for now given that we are deprecating the contractHost and reopening it under a new name and design in the future. I think we should open a new issue for that new design.

[erights]

Why are we deprecating the contractHost rather than (mostly) just renaming it?

[katelynsills]

Copying our discussion summary here:

Just discussed in person and concluded that we should "shelve" contractHost:

1. Rename contractHost to vatSpawner
2. Move vatSpawner and related files to a folder under /test so that we make sure they continuously work with our changes to ERTP but that they are not easily available for users to mistakenly use. Then, when we are ready to make the vatSpawner accessible to users, we can easily do that.