Remove Zoe support for full-source bundles in favor of hash bundles #4565
Labels
Comments
warner
added a commit
that referenced
this issue
Feb 16, 2022
Previously, `E(zoe).install()` accepted a source bundle. Now it accepts either a source bundle, or a "bundle ID". The ID is a hash-based identifier string that refers to a bundle installed into the kernel via `controller.validateAndInstallBundle()`, and is retrievable from vatAdminService. Zoe exchanges the ID for a bundlecap, and retains the bundlecap for future use (including passing to the new ZCF vat, which converts it into a source bundle for evaluation at the last possible moment). The kernel install step can happen either before or after `E(zoe).install`, because the id-to-bundlecap conversion waits until the kernel install is complete. This begins the process of making Zoe work exclusively with (small) bundlecaps, and not (large) source bundles. The next step is to modify all unit tests and external callers (including deploy scripts, #4564) to kernel-install their bundle and use a bundleID for the Zoe install() invocation. After that is complete, #4565 will remove support for full bundles, and `E(zoe).install(bundleID)` will be the only choice. closes #4563
|
De-prioritized for MN-1 in discussion with @warner on Feb 22. |
warner
added a commit
that referenced
this issue
Feb 27, 2022
The new preferred way to install a contract is by its bundleID, using `E(zoe).installBundleID(id)` instead of `E(zoe).install(bundle)`. The bundle itself must first be installed/registered with the VatAdmin service. In a real swingset, this happens out-of-band, via `controller.validateAndInstallBundle`. In a non-swingset unit test, the `fakeVatAdmin` has a new `vatAdminState.installBundle(id, bundle)`. This changes most Zoe unit tests to perform `vatAdminState.installBundle` and then use Zoe's `installBundleID` method. This requires some mechanical changes to the way many tests get access to their fakeVatAdmin. I took the opportunity to switch all tests to importing `makeFakeVatAdmin` and building their own local copy, rather than relying upon the shared singleton created and exported by `fakeVatAdmin.js` itself. This leaves one test in `unitTests/` using the old `E(zoe).install(bundle)`, to ensure it still works until we decide to remove it entirely. All tests in `swingsetTests/` still use `install(bundle)`, those will be changed later. refs #4565
warner
added a commit
that referenced
this issue
Feb 27, 2022
This updates all swingset-based zoe tests to install contracts by BundleID instead of a full bundle. In all cases, we add the bundles by name to `config.bundles`, from which you can obtain the BundleID with: ```js const bcap = await E(vatAdminService).getNamedBundleCap(name); const id = D(bcap).getBundleID(); ``` In a real chain, the bundles would be installed into the kernel at runtime, and zoe would be given a BundleID by the (off-chain) user doing the install (or their deploy script). refs #4565
warner
added a commit
that referenced
this issue
Mar 1, 2022
The new preferred way to install a contract is by its bundleID, using `E(zoe).installBundleID(id)` instead of `E(zoe).install(bundle)`. The bundle itself must first be installed/registered with the VatAdmin service. In a real swingset, this happens out-of-band, via `controller.validateAndInstallBundle`. In a non-swingset unit test, the `fakeVatAdmin` has a new `vatAdminState.installBundle(id, bundle)`. This changes most Zoe unit tests to perform `vatAdminState.installBundle` and then use Zoe's `installBundleID` method. This requires some mechanical changes to the way many tests get access to their fakeVatAdmin. I took the opportunity to switch all tests to importing `makeFakeVatAdmin` and building their own local copy, rather than relying upon the shared singleton created and exported by `fakeVatAdmin.js` itself. This leaves one test in `unitTests/` using the old `E(zoe).install(bundle)`, to ensure it still works until we decide to remove it entirely. All tests in `swingsetTests/` still use `install(bundle)`, those will be changed later. refs #4565
warner
added a commit
that referenced
this issue
Mar 1, 2022
This updates all swingset-based zoe tests to install contracts by BundleID instead of a full bundle. In all cases, we add the bundles by name to `config.bundles`, from which you can obtain the BundleID with: ```js const bcap = await E(vatAdminService).getNamedBundleCap(name); const id = D(bcap).getBundleID(); ``` In a real chain, the bundles would be installed into the kernel at runtime, and zoe would be given a BundleID by the (off-chain) user doing the install (or their deploy script). refs #4565
warner
added a commit
that referenced
this issue
Mar 1, 2022
The new preferred way to install a contract is by its bundleID, using `E(zoe).installBundleID(id)` instead of `E(zoe).install(bundle)`. The bundle itself must first be installed/registered with the VatAdmin service. In a real swingset, this happens out-of-band, via `controller.validateAndInstallBundle`. In a non-swingset unit test, the `fakeVatAdmin` has a new `vatAdminState.installBundle(id, bundle)`. This changes most Zoe unit tests to perform `vatAdminState.installBundle` and then use Zoe's `installBundleID` method. This requires some mechanical changes to the way many tests get access to their fakeVatAdmin. I took the opportunity to switch all tests to importing `makeFakeVatAdmin` and building their own local copy, rather than relying upon the shared singleton created and exported by `fakeVatAdmin.js` itself. This leaves one test in `unitTests/` using the old `E(zoe).install(bundle)`, to ensure it still works until we decide to remove it entirely. All tests in `swingsetTests/` still use `install(bundle)`, those will be changed later. refs #4565
warner
added a commit
that referenced
this issue
Mar 1, 2022
This updates all swingset-based zoe tests to install contracts by BundleID instead of a full bundle. In all cases, we add the bundles by name to `config.bundles`, from which you can obtain the BundleID with: ```js const bcap = await E(vatAdminService).getNamedBundleCap(name); const id = D(bcap).getBundleID(); ``` In a real chain, the bundles would be installed into the kernel at runtime, and zoe would be given a BundleID by the (off-chain) user doing the install (or their deploy script). refs #4565
warner
added a commit
that referenced
this issue
Mar 2, 2022
The new preferred way to install a contract is by its bundleID, using `E(zoe).installBundleID(id)` instead of `E(zoe).install(bundle)`. The bundle itself must first be installed/registered with the VatAdmin service. In a real swingset, this happens out-of-band, via `controller.validateAndInstallBundle`. In a non-swingset unit test, the `fakeVatAdmin` has a new `vatAdminState.installBundle(id, bundle)`. This changes most Zoe unit tests to perform `vatAdminState.installBundle` and then use Zoe's `installBundleID` method. This requires some mechanical changes to the way many tests get access to their fakeVatAdmin. I took the opportunity to switch all tests to importing `makeFakeVatAdmin` and building their own local copy, rather than relying upon the shared singleton created and exported by `fakeVatAdmin.js` itself. This leaves one test in `unitTests/` using the old `E(zoe).install(bundle)`, to ensure it still works until we decide to remove it entirely. All tests in `swingsetTests/` still use `install(bundle)`, those will be changed later. refs #4565
warner
added a commit
that referenced
this issue
Mar 2, 2022
This updates all swingset-based zoe tests to install contracts by BundleID instead of a full bundle. In all cases, we add the bundles by name to `config.bundles`, from which you can obtain the BundleID with: ```js const bcap = await E(vatAdminService).getNamedBundleCap(name); const id = D(bcap).getBundleID(); ``` In a real chain, the bundles would be installed into the kernel at runtime, and zoe would be given a BundleID by the (off-chain) user doing the install (or their deploy script). refs #4565
warner
added a commit
that referenced
this issue
Mar 3, 2022
The new preferred way to install a contract is by its bundleID, using `E(zoe).installBundleID(id)` instead of `E(zoe).install(bundle)`. The bundle itself must first be installed/registered with the VatAdmin service. In a real swingset, this happens out-of-band, via `controller.validateAndInstallBundle`. In a non-swingset unit test, the `fakeVatAdmin` has a new `vatAdminState.installBundle(id, bundle)`. This changes most Zoe unit tests to perform `vatAdminState.installBundle` and then use Zoe's `installBundleID` method. This requires some mechanical changes to the way many tests get access to their fakeVatAdmin. I took the opportunity to switch all tests to importing `makeFakeVatAdmin` and building their own local copy, rather than relying upon the shared singleton created and exported by `fakeVatAdmin.js` itself. This leaves one test in `unitTests/` using the old `E(zoe).install(bundle)`, to ensure it still works until we decide to remove it entirely. All tests in `swingsetTests/` still use `install(bundle)`, those will be changed later. refs #4565
warner
added a commit
that referenced
this issue
Mar 3, 2022
This updates all swingset-based zoe tests to install contracts by BundleID instead of a full bundle. In all cases, we add the bundles by name to `config.bundles`, from which you can obtain the BundleID with: ```js const bcap = await E(vatAdminService).getNamedBundleCap(name); const id = D(bcap).getBundleID(); ``` In a real chain, the bundles would be installed into the kernel at runtime, and zoe would be given a BundleID by the (off-chain) user doing the install (or their deploy script). refs #4565
warner
added a commit
that referenced
this issue
Mar 3, 2022
The new preferred way to install a contract is by its bundleID, using `E(zoe).installBundleID(id)` instead of `E(zoe).install(bundle)`. The bundle itself must first be installed/registered with the VatAdmin service. In a real swingset, this happens out-of-band, via `controller.validateAndInstallBundle`. In a non-swingset unit test, the `fakeVatAdmin` has a new `vatAdminState.installBundle(id, bundle)`. This changes most Zoe unit tests to perform `vatAdminState.installBundle` and then use Zoe's `installBundleID` method. This requires some mechanical changes to the way many tests get access to their fakeVatAdmin. I took the opportunity to switch all tests to importing `makeFakeVatAdmin` and building their own local copy, rather than relying upon the shared singleton created and exported by `fakeVatAdmin.js` itself. This leaves one test in `unitTests/` using the old `E(zoe).install(bundle)`, to ensure it still works until we decide to remove it entirely. All tests in `swingsetTests/` still use `install(bundle)`, those will be changed later. refs #4565
warner
added a commit
that referenced
this issue
Mar 3, 2022
This updates all swingset-based zoe tests to install contracts by BundleID instead of a full bundle. In all cases, we add the bundles by name to `config.bundles`, from which you can obtain the BundleID with: ```js const bcap = await E(vatAdminService).getNamedBundleCap(name); const id = D(bcap).getBundleID(); ``` In a real chain, the bundles would be installed into the kernel at runtime, and zoe would be given a BundleID by the (off-chain) user doing the install (or their deploy script). refs #4565
warner
added a commit
that referenced
this issue
Mar 4, 2022
The new preferred way to install a contract is by its bundleID, using `E(zoe).installBundleID(id)` instead of `E(zoe).install(bundle)`. The bundle itself must first be installed/registered with the VatAdmin service. In a real swingset, this happens out-of-band, via `controller.validateAndInstallBundle`. In a non-swingset unit test, the `fakeVatAdmin` has a new `vatAdminState.installBundle(id, bundle)`. This changes most Zoe unit tests to perform `vatAdminState.installBundle` and then use Zoe's `installBundleID` method. This requires some mechanical changes to the way many tests get access to their fakeVatAdmin. I took the opportunity to switch all tests to importing `makeFakeVatAdmin` and building their own local copy, rather than relying upon the shared singleton created and exported by `fakeVatAdmin.js` itself. This leaves one test in `unitTests/` using the old `E(zoe).install(bundle)`, to ensure it still works until we decide to remove it entirely. All tests in `swingsetTests/` still use `install(bundle)`, those will be changed later. refs #4565
warner
added a commit
that referenced
this issue
Mar 4, 2022
This updates all swingset-based zoe tests to install contracts by BundleID instead of a full bundle. In all cases, we add the bundles by name to `config.bundles`, from which you can obtain the BundleID with: ```js const bcap = await E(vatAdminService).getNamedBundleCap(name); const id = D(bcap).getBundleID(); ``` In a real chain, the bundles would be installed into the kernel at runtime, and zoe would be given a BundleID by the (off-chain) user doing the install (or their deploy script). refs #4565
turadg
pushed a commit
that referenced
this issue
Mar 4, 2022
The new preferred way to install a contract is by its bundleID, using `E(zoe).installBundleID(id)` instead of `E(zoe).install(bundle)`. The bundle itself must first be installed/registered with the VatAdmin service. In a real swingset, this happens out-of-band, via `controller.validateAndInstallBundle`. In a non-swingset unit test, the `fakeVatAdmin` has a new `vatAdminState.installBundle(id, bundle)`. This changes most Zoe unit tests to perform `vatAdminState.installBundle` and then use Zoe's `installBundleID` method. This requires some mechanical changes to the way many tests get access to their fakeVatAdmin. I took the opportunity to switch all tests to importing `makeFakeVatAdmin` and building their own local copy, rather than relying upon the shared singleton created and exported by `fakeVatAdmin.js` itself. This leaves one test in `unitTests/` using the old `E(zoe).install(bundle)`, to ensure it still works until we decide to remove it entirely. All tests in `swingsetTests/` still use `install(bundle)`, those will be changed later. refs #4565
turadg
pushed a commit
that referenced
this issue
Mar 4, 2022
This updates all swingset-based zoe tests to install contracts by BundleID instead of a full bundle. In all cases, we add the bundles by name to `config.bundles`, from which you can obtain the BundleID with: ```js const bcap = await E(vatAdminService).getNamedBundleCap(name); const id = D(bcap).getBundleID(); ``` In a real chain, the bundles would be installed into the kernel at runtime, and zoe would be given a BundleID by the (off-chain) user doing the install (or their deploy script). refs #4565
|
This has fairly large documentation impact. |
|
@warner, @michaelfig, and I arrived at a different consensus, one where we keep
Description update to follow. |
kriskowal
changed the title
This was referenced Mar 31, 2022
|
I hope we don't spend too much time in the intermediate state: I'm not thrilled about "hash bundles" at this point. BundleIDs (strings) are great, full Bundles are a necessary evil in some cases, but something that is shaped like a bundle yet depends upon external resources just feels confusing and wrong. |
the documentation impact is significant. Also: p.s. How is "Remove..." an enhancement? This smells like a bug, to me: "E(zoe).install(bundle) is too resource-intensive to support" or some such. |
|
(BTW my original plan was to change the API of zoe.install, from bundle to bundleID, in one fell swoop. But that flag day didn't work because of the external dapps, so we needed two APIs for a while. Turned out to be a longer while than we thought. I think that once we get rid of the old API, we can rename |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
[updated by @kriskowal]
What is the problem being solved
Zoe currently accepts bundles that contain all of their source, resulting in very large transactions to the chain. Per #4563, then #4974, Zoe will be able to additionally accept “hash bundles”, specifically
EndoZipBase64Sha512Bundle. These would be bundles that just refer to the bundle by its consistent hash, instead of carrying all the source, and SwingSet will receive the bundles bycontroller.validateAndInstallBundle(sourceBundle)instead.This issue tracks the eventual breaking change that will remove support for source bundles, making hash bundles the only supported option.
[original ticket by @warner]
What is the Problem Being Solved?
After #4563 adds the ability to do
E(zoe).installBundleID(bundleID), and #4564 changes all our dapps to use it, we can remove support forE(zoe).install(bundle). This will simplify zoe's contract-installation storage table (just{ Bundlecap }, not{ Bundlecap | Bundle }, as well as the Zoe-to-ZCFevaluateContract()message.Description of the Design
E(zoe).install(bundle), leaving onlyE(zoe).installBundleID(bundleID)installationStorage.jsstores only bundlecapszcfZygote.js'sevaluateContract(bundleOrBundlecap)becomesevaluateContract(bundlecap)Security Considerations
Test Plan
The one zoe unit test that asserts
bundlesupport is removed.The text was updated successfully, but these errors were encountered: