Skip to content
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

Merged
merged 5 commits into from
Nov 9, 2023
Merged

zoe1 proposal #18

merged 5 commits into from
Nov 9, 2023

Conversation

turadg
Copy link
Member

@turadg turadg commented Nov 8, 2023

Closes: Agoric/agoric-sdk#8502

Proposal to upgrade Zoe on the chain with version from Agoric/agoric-sdk#8453

@turadg turadg marked this pull request as ready for review November 9, 2023 14:17
Comment on lines +9 to +10
// TODO: factor out ambient authority from these
// or at least allow caller to supply authority.
Copy link
Member Author

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

Comment on lines +115 to +116
// XXX vestige of Ava
const context = await makeTestContext();
Copy link
Member Author

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

@turadg turadg requested review from dckc and Chris-Hibbert November 9, 2023 14:24
@turadg turadg marked this pull request as draft November 9, 2023 18:34
@turadg
Copy link
Member Author

turadg commented Nov 9, 2023

converting to draft while I,

1. try to solve the missing refs

2023-11-09T15:04:04.1698311Z #60 [execute-upgrade-11 4/5] WORKDIR /usr/src/upgrade-test-scripts
2023-11-09T15:04:04.1699914Z #60 ERROR: failed to load ref: tdx9hly5mm4ihe08v1v26wam8: not found
2023-11-09T15:04:04.1701034Z 
2023-11-09T15:04:04.1701921Z #61 [execute-upgrade-11 3/5] COPY --link --from=prepare-upgrade-11 /root/.agoric /root/.agoric
2023-11-09T15:04:04.1703639Z #61 ERROR: failed to load ref: 9puhtidm1jttk6rwrapechdfo: not found

2. add a test of restarting vat-admin

The 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:

  • Make an open offer (e.g. bid)
  • Core-eval to restart vat-admin vat
  • Make sure the offer stays open (demonstrating repair)

Copy link
Member

@dckc dckc left a 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
Copy link
Member

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
Copy link
Member

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

Copy link
Member Author

@turadg turadg Nov 9, 2023

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 :)

Copy link
Member

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.

proposals/b:zoe1/package.json Show resolved Hide resolved
};

/**
* URLs of assets, including bundle hashes (to be) agreed by BLD stakers
Copy link
Member

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');
Copy link
Member

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.

Copy link
Member Author

@turadg turadg Nov 9, 2023

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?

Copy link
Member

@dckc dckc Nov 9, 2023

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) => {
Copy link
Member

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",
Copy link
Member

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",
Copy link
Member

@dckc dckc Nov 9, 2023

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",
Copy link
Member

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"
Copy link
Member

@dckc dckc Nov 9, 2023

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.

@turadg turadg marked this pull request as ready for review November 9, 2023 23:47
@turadg
Copy link
Member Author

turadg commented Nov 9, 2023

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.

@turadg turadg merged commit 4ba8231 into main Nov 9, 2023
1 check passed
@turadg turadg deleted the 8387-zoe1 branch November 9, 2023 23:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Test that Zoe support seats and offers through upgrade.
2 participants