-
Notifications
You must be signed in to change notification settings - Fork 205
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
Bundle hashing #3859
Comments
This change depends on #3512 Expose SHA-512 to XSnap vats. |
*BREAKING CHANGE*: This change switches the default bundle format from `nestedEvaluate` to `endoZipBase64`. The new bundle format has a fundamentally different shape and content, so any existing code that depends on being able to inspect the `source` string of the bundle will break. This functionality will be replaced with a new feature for consistent-hash integrity checking. #3859
refs #3269 for the module/package -at-a-time install-to-chain API, plus the manifest-ish thing that sits on top of those to identify the complete bundle |
Archive hashing described in greater detail here endojs/endo#794 |
Just finished chatting with @kriskowal , it sounds like we'll wind up with four source formats:
We're adding the third thing now, and the fourth thing later. While we're in the third step, Zoe will still be passing around large strings, and the only support swingset needs to provide is a way to do SHA512 hashes from within vat code (and @kriskowal has a plan for making that visible as a global, although we should add that to V8-based vats too, for consistency). We'll be adding a method like When we get to step 4, and introduce blobcaps, then |
*BREAKING CHANGE*: This change switches the default bundle format from `nestedEvaluate` to `endoZipBase64`. The new bundle format has a fundamentally different shape and content, so any existing code that depends on being able to inspect the `source` string of the bundle will break. This functionality will be replaced with a new feature for consistent-hash integrity checking. #3859
*BREAKING CHANGE*: This change switches the default bundle format from `nestedEvaluate` to `endoZipBase64`. The new bundle format has a fundamentally different shape and content, so any existing code that depends on being able to inspect the `source` string of the bundle will break. This functionality will be replaced with a new feature for consistent-hash integrity checking. #3859
@kriskowal This is in the "Up Next" pipeline, but does not have a MN-1 label. If it is needed for MN-1, please label, otherwise move from "Up Next" to "Product Backlog". |
@kriskowal This does not have an area label that is covered by our weekly tech / planning meetings. Can you assign the proper label? We cover: agd, agoric-cosmos, amm, core economy, cosmic-swingset, endo, getrun, governance, installation-bundling, metering, run-protocol, staking, swingset, swingset-runner, token economy, wallet, zoe contract, |
@kriskowal Is your work for this covered in another issue? If not, you might want to create a separate issue. |
My work for this is covered entirely by this issue. |
What is the Problem Being Solved?
The current mechanism for checking integrity of a Zoe installation or generally any bundle is source inspection. Bundles are transparent and can be inspected directly. The new
endoZipBase64
format is also transparent but requires considerable machinery to inspect.Generally, integrity checks would be more robust if they were framed as verification of the bundle’s consistent hash.
Description of the Design
Endo now provides a mechanism for getting the SHA-512 of an Endo application, providing the same answer either on-disk or in-archive. For the existing
nestedEvaluate
andgetExports
bundle formats, we produce a SHA-512 from the UTF-8 encoded source.We can now implement a new package
hash-bundle
which likebundle-source
andimport-bundle
operates on all of our supported bundle formats to produce a consistent hash.We then can expose a
getHash
method on Zoe installations so anyone with a handle on an installation can inspect its hash without the need to obtain the content of the hash.Security Considerations
The hash function must be wide enough and strong enough to produce a unique value for any contract submitted to the chain and be resilient against attacks that might exploit it in order to submit imposters for other contracts.
Further Design Considerations
This design should flush with @warner’s proposal for “Blob Capabilities” that would allow us to feed bundles to the Agoric chain through a shared content address store and refer to bundles only by their consistent hash in messages to the chain.
This then would allow us to decompose Endo Zip archives into individual files addressed by SHA-512 for the purposes of reducing transmission of duplicate blobs between nodes of the content address store. (cc @dtribble)
Test Plan
This change will need tests that verify hash consistency for consistent bundles, crossed by all of the bundle formats, crossed by Node.js and XSnap vat environments. #3273 removes consistency checks from Zoe tests and this change must include replacements for those tests.
The text was updated successfully, but these errors were encountered: