-
Notifications
You must be signed in to change notification settings - Fork 204
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Contract Host without installations #95
Comments
This probably requires to change This allows for another change/simplification:
|
If ERTP is considered already in use and this change is wanted, it might be a good time to start using semver |
I like the direction this is going. Just one change: Unfortunately, we can't put 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 |
I view contractHost as close to being deprecated, with its functionality split between Zoe (as a smart contract runner) and |
The 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. |
Can you elaborate on this? I'm not sure I understand how the spawner helps. |
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. |
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 |
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. |
At https://github.com/Agoric/ERTP/issues/70#issuecomment-553662327 @Chris-Hibbert wrote:
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. |
this was issue 215 in the old ERTP repo |
.. instead of defining it locally. We have to drop a couple of safety features, like detecting/complaining about E(E(x)) and E(devicenode). TODO: we rely upon the imported E to harden the promise returned by E(x).foo() like our EPromiseHandler used to, to handle issue Agoric#95, since we cannot reach this promise to handle externally. The current eventual-send branch does not harden it, because it might be used outside of SES where harden() isn't necessarily available.
feat(zoe): implement 'home.zoe' and Zoe contract upload
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. |
Why are we deprecating the contractHost rather than (mostly) just renaming it? |
Copying our discussion summary here: Just discussed in person and concluded that we should "shelve" contractHost:
|
One problem i see with current ERTP is that studying an invite takes to do
host.getInstallationSourceCode(invite.getBalance().installation)
andinvite.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 ahost~.getInviteContractSourceCodeAndTerms(invite)
method which unifies getting both at the same timeTaking 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 torun
orstart
orinstantiate
orstartContract
something else)host~.getInviteContractSourceCodeAndTerms(invite)
method (or any better name)invite.getBalance().installation.check*()
toinvite.getBalance().check*()
)The text was updated successfully, but these errors were encountered: