-
Notifications
You must be signed in to change notification settings - Fork 208
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
9900 elide comments in bundles #9997
Conversation
base64 is completely reversible, so while it does introduce friction into any audit, it doesn't affect availability; it doesn't require readers to find the sources elsewhere. The transformation that's irreversible, and hence means you can't reliably recover the source from what's on chain, is the one that turns export * from './src/timeMath.js';
export * from './src/typeGuards.js';
// eslint-disable-next-line import/export -- just types
export * from './src/types.js'; into ({ imports: $h_imports, liveVar: $h_live, onceVar: $h_once, importMeta: $h____meta, }) => (function () { 'use strict'; $h_imports([["./src/timeMath.js", []],["./src/typeGuards.js", []],["./src/types.js", []]]);
})() p.s. I left implicit: we aim to stop doing that transformation in due course. |
This should let us get rid of the agoric-sdk/multichain-testing/scripts/update-config.sh Lines 19 to 28 in bd64eda
|
Deploying agoric-sdk with Cloudflare Pages
|
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.
@Chris-Hibbert amiright that this has A3P coverage? can we lose this permanently now or will it need a follow-up issue to restore it?
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.
most a3p-integration tests are short-lived--once the release they're attached to goes live, the tests get moved to agoric-3-proposals, and only run against that release. If we want a persistent test, it would have to go into z:acceptance
. I don't see a test of adding bids there, but we certainly have the ability to test that there.
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.
All of the changes pertaining to bundling look fine to me, though turning on elideComments by default for all agoric
CLI usage might override the intentions of individual contracts. It might be more polite to thread elideComments
at the call sites. It’s also currently possible to drive bundleSource
for other module formats (nestedEvaluate
) which don’t accept the elideComments
field in their overload. We should preserve the ability to override the format
option.
if (!pendingBundles.has(bundleID)) { | ||
pendingBundles.set(bundleID, makePromiseKit()); | ||
} | ||
return pendingBundles.get(bundleID).promise; | ||
return pendingBundles.get(bundleID)?.promise; |
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.
It’s a little weird to add a runtime check to appease the type system, when the runtime code above guarantees that the promise is defined.
const bundlePromise = pendingBundles.get(bundleId);
if (bundlePromise !== undefined) {
return bundlePromise;
}
const bundleKit = makePromiseKit()
pendingBundles.set(bundleId, bundleKit);
return bundleKit.promise;
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 agree that's better code but are you also asserting it's a better change to make? I opted for the minimum characters changed.
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.
🤷♂️
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 appended f389f5d to your stack to sort out the bundleSource signature so it’s sensitive to the format option.
f389f5d
to
47a8fe5
Compare
the accommodation is no longer needed after enabling elide-comments in bundler
It has some racy failure after elide-comments. These proposals are also tested in a3p-integration where they pass. getBundleCap fails because: ``` bundleID not yet installed: b1-ab8ea6984e25d2e95a6ff94cd475c6e044fba9439daafaa44e333a27efe157c24170febefe336f9eb7394a1b56540bec0a128fd5b183fbe5ee45c06d519c4136 ```
47a8fe5
to
9e15cb4
Compare
sed -i -e "s/max_txs_bytes = .*/max_txs_bytes = $MAX_TXS_BYTES/g" $CHAIN_DIR/config/config.toml | ||
sed -i -e "s/max_tx_bytes = .*/max_tx_bytes = $RPC_MAX_BODY_BYTES/g" $CHAIN_DIR/config/config.toml | ||
sed -i -e "s/^rpc-max-body-bytes =.*/rpc-max-body-bytes = $RPC_MAX_BODY_BYTES/" $CHAIN_DIR/config/app.toml | ||
|
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.
This edit was the only motivation for checking in update-config.sh
in the first place. We should be able to delete this file and the remove the reference from config.yaml:
ebeb975
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.
Noting to make that clearer next time, maybe with a comment like "This file only exists to support this change. If we find this is not needed, please remove this entire file"
- with #9997, we no longer need to override config.toml script - the defaults work fine
refs: #9900
Description
This uses the new
--elide-comments
option in Endo bundle-source to… elide comments. Always.Measured with:
Before: 26M (6.7M gz)
After: 19M (4.1M gz)
Security Considerations
No change in runtime. Does affect code auditability. Existing bundles are base64 encoded so readers will have to find the sources anyway. Either way we will need to invest in special tooling: endojs/endo#1656
Scaling Considerations
reduces on-chain storage
Documentation Considerations
End users who base64 decode the on-chain bundles will no longer see comments… I don't expect anyone was doing this.
Testing Considerations
existing coverage
Upgrade Considerations
won't affect any existing deployments