-
Notifications
You must be signed in to change notification settings - Fork 6
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
zoe1 proposal #18
zoe1 proposal #18
Conversation
3984a5d
to
989c3bf
Compare
// TODO: factor out ambient authority from these | ||
// or at least allow caller to supply authority. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not my words! :)
future work #21
// XXX vestige of Ava | ||
const context = await makeTestContext(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
to be cleaned up in #21
converting to draft while I, 1. try to solve the missing refs
2. add a test of restarting vat-adminThe SDK PR tests head against head. It shows that the bug with promise watchers is gone but can't test the "repair" because it doesn't have the earlier state to repair. So this test needs to:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks pretty good.
I got a different hash on one of the bundles; I almost requested a change because of that, but I suppose until the proposal goes on chain, a certain amount of iteration is likely anyway, so I'll leave it to your discretion.
I went into detail about the flip side of cognitive overhead around ambient authority. It's largely orthogonal to this PR, but I hope it moves the overall conversation forward.
A3P=/opt/agoric/agoric-3-proposals | ||
cd packages/builders | ||
# build the proposal | ||
agoric run scripts/vats/upgrade-zoe.js | tee run-report.txt |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not able to reproduce these bundles.
I get 1 bundle that matches but one that does not:
b1-b75c88c4a783b0a0fb2886fea6cf2fa0ced579d25f73cbe5f7d72e4dfdf2d2c06c014875726dc5fbaf2d586b2d4f975bb3a73ac3faaeb789e5b20d556b7a9623.json
b1-a3dc21c56535b4bebdf8c8413650eec2b37a6d9f5669b27f8c571601a6f641ffae2b925dd7e3d67c6953a1f8122c8ba814305e034c9087056816a6f05dd41069.json
@@ -0,0 +1 @@ | |||
nodeLinker: node-modules |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These yarn files are new to me, so I'm reading docs. I can't comment on the .gz file directly...
Why are we committing .yarn/install-state.gz
?
.yarn/install-state.gz
is an optimization file that you shouldn't ever have to commit
-- https://yarnpkg.com/getting-started/qa
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for catching that. The .gitignore
does ignore it, but the pattern assumes .yarn
dir will only be at root. https://github.com/yarnpkg/berry/blob/master/.gitignore
I could change the ignore but WDYT of having one yarn.lock for the repo and making all the other packages workspaces? I've shied away because under the existing structure the root package would have to be in /usr/src
of the Docker image, which is icky. I could refactor so that proposals
is under upgrade-test-scripts
, next to lib
, and then upgrade-test-scripts
has the one root. Though it would still require changing the gitignore so I"ll probably just do that :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
one yarn.lock for the repo sounds attractive.
I am, as usual, reticent to move things around.
I guess don't feel strongly one way or the other. This repo is still young.
}; | ||
|
||
/** | ||
* URLs of assets, including bundle hashes (to be) agreed by BLD stakers |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
stale comment
|
||
// TODO move into core-eval-support | ||
const readSubmissions = async () => { | ||
const files = await fsp.readdir('submission'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here I need to make a mental note that fsp
is accessed ambiently, so that when I see calls to readSubmissions
, I know there's an extra implicit argument. This is cognitive overhead.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
so that when I see calls to readSubmissions, I know there's an extra implicit argument
Why do you need to know that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
because normally, return values of top-level functions only depend on the args. In particular, a 0-argument function can only return a constant (again, modulo allocation).
This is normal local reasoning. The alternative is a burden to know the implementation details of every function in the system.
// XXX vestige of Ava | ||
const context = await makeTestContext(); | ||
|
||
const step = async (name: string, fn: Function) => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nice: interesting low-cost way to reuse the test(...)
idiom.
@@ -0,0 +1,18 @@ | |||
{ | |||
"consume": { | |||
"vatAdminSvc": "vatAdminSvc", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think a few times I have given the impression that vatAdminSvc
is horribly powerful. I just double-checked, and it's not. BundleCap lookup and vat creation is all VatAdminSvc provides. Vat creation is expensive, but it doesn't give the caller access to any existing vats, nor contract privateArgs
, etc.
{ | ||
"consume": { | ||
"vatAdminSvc": "vatAdminSvc", | ||
"vatStore": "vatStore", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
vatStore
, on the other hand, is excess authority. Much like in Agoric/agoric-sdk#8378, what this proposal needs is access to the zoe adminFacet, but vatStore
is access to the adminFacet of all vats, plus the ability to update the store - overwrite or delete entries, for example.
"consume": { | ||
"vatAdminSvc": "vatAdminSvc", | ||
"vatStore": "vatStore", | ||
"agoricNamesAdmin": "makeCoreProposalBehavior", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think agoricNamesAdmin
is just plain not needed. But agoric run
isn't smart enough to know that. IOU another issue?
"vatAdminSvc": "vatAdminSvc", | ||
"vatStore": "vatStore", | ||
"agoricNamesAdmin": "makeCoreProposalBehavior", | ||
"zoe": "makeCoreProposalBehavior" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think makeCoreProposalBehavior
uses zoe
for E(zoe).install()
but we're not installing anything in this proposal, so again, this is excess authority. But zoe is designed to be shared widely (modulo Agoric/agoric-sdk#3725, Agoric/agoric-sdk#4395), so not much harm.
It's passing so I suspec the missing-refs problem was solved by omitting the slogfile. I still have to improve the test coverage but I think this is good to land for now. |
Closes: Agoric/agoric-sdk#8502
Proposal to upgrade Zoe on the chain with version from Agoric/agoric-sdk#8453