test(solidity): prove packed Rocketh deployment and legacy proxy compatibility - #4316
Draft
mswilkison wants to merge 1 commit into
Draft
mswilkison wants to merge 1 commit into
mswilkison wants to merge 1 commit into
Conversation
|
Important Draft PR not reviewedDraft PRs are not automatically reviewed by default.
To automatically review draft PRs, update your CodeRabbit configuration: reviews:
auto_review:
drafts: trueThanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
piotr-roslaniec
added a commit
that referenced
this pull request
Sep 13, 2026
The Solidity packages still depended on ethers v5 after the strict TypeScript and Waffle-removal preparation. This ports their tests, tasks and executable deployment exports to ethers v6 while retaining Hardhat 2.29.0, maintained hardhat-deploy 1.0.4 and ES2020/CommonJS. It is the next preparation step for #4295; the Hardhat 3/Rocketh production port remains separate. Related feasibility proof: #4316. Stacked on #4306 (`codex/ecdsa-strict-cli`). Includes the maintained-deploy and Node 24/Yarn 4 preparation, a tested v5 comparison baseline, and the v6 migration. - Migrate bigint arithmetic, immutable Result arrays, contract/provider APIs, TypeChain, mocks and CLI tasks without relaxing strict TypeScript. - Use helpers 0.7.2 and OpenZeppelin Upgrades 2.5.1 with checked-in compatibility patches preserving shared-v4-admin behavior and legacy proxy receipt fields. Also adapt Threshold's pinned deployment scripts, Etherscan v2 verification and the TypeChain `target` name collision. - Pin Beacon's existing npm version, refresh ECDSA's bundled deployment and task exports, and ship the v6 bundle with ECDSA. Initialization, authorization, registration and account unlocking share the deployment export resolver. Explicit producer paths select task exports too and fail if they are missing. Include the confirmation helper in published exports. - Add reproducible full-chain/artifact comparisons, actual two-producer tarball deployment checks and the versioned-release-line decision. - Use helpers 0.7.2's `export-deployment-artifacts` task in both npm publication hooks, preserving explicit network selection and defaulting to Hardhat when `--network` is omitted. Document publication lifecycle reproduction. - Include local Yarn patches before dependency installation in both Docker images while excluding host caches. Install and remove the native build tools needed to pack the Thesis Git dependency in the same layer. The Beacon publishing workflow uses its Node version file and an immutable install, preserving the patched Threshold version instead of downgrading it. Validation on Node 24.11.1: immutable installs, both strict TypeScript checks, CommonJS export/prepack builds and full lint pass (existing warnings remain). Beacon: 962 passing, including seven new confirmation and initialization-task tests. ECDSA: 679 passing, 44 existing pending, including six task entrypoint checks. The full ECDSA suite passes with sibling Beacon exports unavailable. Fresh production-contract deployments preserve all 74 per-transaction EVM state roots and byte-identical export.json for 16 Beacon / 22 ECDSA contracts. The actual packed producers match the v6 source deployment exactly, including 46 ECDSA transaction state roots, all 22 deployment records and 52 artifacts. All 19 bundled JavaScript files match Beacon's compiled exports byte for byte. All six task checks pass through the packed ECDSA configuration with both explicit v6 Beacon exports and the pinned v5 dependency, exercising ECDSA's shipped v6 task bundle. The five initialization/registration regressions reproduce the original v5 failures before the import fix. The bundled fallback also matches its like-for-like v5 baseline. Review regression checks: both full Linux/arm64 Docker builds and container runtime checks pass. Their build contexts contain exactly the four checked-in patches, with host Yarn caches and install state excluded; the finished images omit Python, make and g++. Beacon's immutable install, the workflow's local deployment (including TokenholderTimelock), and prepack pass on Node 24.11.1. Publication lifecycle validation on Node 24.11.1/npm 11.6.2: six offline `npm publish --dry-run` checks pass across both packages (explicit Hardhat, omitted network, and Sepolia snapshots). They exercise `prepublishOnly` and `prepack`, plus ECDSA's `prepare`. Exported deployment records match their sources byte for byte, and every contract artifact appears in npm's packed file list. Both previous hooks reproduce `HH303` through the same npm lifecycle. Both gated npm workflows parse as YAML and pass Prettier and whitespace checks; all four publishing steps are covered by the disabled jobs. Two explicit data differences are documented and checked: six ECDSA gas-limit changes produce different transaction/block hashes without changing actual gas used or state; TokenStaking's exported artifact gains its compiler-verified storageLayout. All other artifact files are byte-identical. No Solidity sources, live deployment records or OpenZeppelin manifests change. Both npm publishing workflows are disabled at the job level, blocking automatic `main` publication to `development` and manual publication to `development` or `latest`. Re-enabling them requires a coordinated release change after consumer migration, upstream fixes, release channel agreement, a compatible Beacon dependency pin, and full packed-producer ECDSA/tbtc-v2 validation. CommonJS v6 scripts still require a compatible consumer runtime. Patches do not propagate into downstream installs, and ECDSA must pin a newly released v6 Beacon before executable exports are published. Full tbtc-v2 integration, upstream releases, explorer services, the manual V2/deputy workflow and the Hardhat 3/Rocketh cutover remain release gates. Keep #4295 open. Details and reproduction commands are in `solidity/docs/ethers-v6-compatibility.md`.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Issue #4295 needs evidence that the proposed Hardhat 3/Rocketh deployment layer can consume published producer scripts and preserve the legacy export/proxy contracts. This adds an isolated, pinned experiment and a decision record supporting staged implementation: viem/Rocketh deployments, ethers v6 tests, and separate versioned release lines during the transition.
The consumer installs an actual producer tarball, resolves cross-package dependencies and named accounts, and exercises reruns and ethers fixtures. A separate Hardhat 2/deploy-v1 process receives the same compiled artifacts; the prototype exporter produces byte-identical legacy JSON. Explicit OpenZeppelin v4 proxies share an admin, reject an incompatible layout, support an existing-proxy upgrade, and retain ownership/admin controls through the Hardhat 3 plugin.
Validation: all 10 local checks pass on Node 24.11.1. The two export files have SHA-256
669bd1ed435bed2b89e2a0677c47a922674ab77b4702b0194722fda6750dbcff. Reproduction commands and precise limits are in the experiment README and decision record.This is a feasibility gate, not the production port. It does not establish production compiler/artifact parity, the complete WalletRegistry workflow, upstream/downstream release agreement, or the full tbtc-v2 consumer. Keep #4295 open. The actual ethers v6 preparation is #4315, stacked on #4306.