Skip to content

Chainweb Revolution - #49

Open
edmundnoble wants to merge 453 commits into
masterfrom
evm/main
Open

edmundnoble wants to merge 453 commits into
masterfrom
evm/main

Conversation

@edmundnoble

Copy link
Copy Markdown

This PR includes:

  • PayloadProvider, a new protocol that decouples the block execution and payload storage layer from the consensus layer thereby bringing us closer to a multi-process, clustered future for massively parallel nodes.
  • The Pact payload provider based on the existing PactService, with automatic migration from the previous version. This comes with a drastic simplification of the data flow between consensus and Pact, which should make future Pact development easier.
  • An "EVM" payload provider which uses an Ethereum node (specifically kadena-reth) as an execution engine, appearing to developers to be an ordinary Ethereum node with added cross-chain capabilities.
  • A minimal payload provider that only produces cross-chain proofs of miner rewards to be used on other chains. This is necessary not only for testing but also because chainweb requires the use of expander chain graphs which may be larger than the desired chain count at a given time. For example, the next largest chain graph has 38 chains, and if we only wanted to add e.g. 5 EVM chains to mainnet, we could keep 20 Pact chains, 5 EVM chains, and 13 minimal chains.
  • Incremental block header and payload pruning and a standalone tool for executing this pruning on demand.
  • Improved fork resolution, meaning less scenarios where due to corruption an operator must manually rewind the node.
  • Optimizations and additional benchmark coverage for the catchup process.

There's much more to say about the EVM payload provider, but it will require more testing and updating to bring to mainnet, not to mention operational challenges that come with multi-process coordination and changes to the build.

edmundnoble and others added 30 commits May 29, 2025 16:29
Change-Id: Id0000000c710b3254c28490df4102788ad05b899
Change-Id: Id0000000e62e4d92520fbb52730df5ff49dbace1
Change-Id: Id0000000253662d2498dc6582f9a1782d2f2fb79
Change-Id: Id000000030b06b731faa8c6e47ff1b891945b720
Change-Id: Id000000003c31788c6d2bf3daf6ba67bf827dede
Change-Id: Id0000000c7ecef14f070061716476b1aff90d751
Change-Id: Id000000003df0e6228643907b06fda6e13d2dea2
Change-Id: Id00000001b24cc3d269cffcf1b3a67d230747c18
Change-Id: Id000000056296ea25046e7a8b9b001e84c259047
edmundnoble and others added 21 commits October 14, 2025 10:05
As large as traces can be sometimes, ForkInfoSyncFailure is a very
serious error and one failure case is that the trace is insufficient for
the payload provider to resolve the fork.

Change-Id: Id00000002dbaa0d9222fabfe4308ebca179301d0
1. `false` is no longer allowed, booleans are case-sensitive.
2. `debug-info` is an integer, not a bool.


Change-Id: Id0000000920444ab87872458636e74d196058c2c
1. Many utilities moved from ChainwebPactDb to Backend.Utils. (these are
   not specific to PactDb though they are related to storage)
2. Stop maintaining a "latest" in ConsensusState table. The latest row
   in the BlockHistory table reflects the true "latest" block, and
   duplication between the two may cause bugs.

Test Plan: Run Pact tests as normal. Ran on mainnet database locally.

Reviewers: rsoeldner, jmcardon, larskuhtz

Reviewed By: larskuhtz, rsoeldner

Pull Request: kadena-io#2260
Sometimes consensus and Pact are out of sync; this is normal and
expected because catchup is not atomic w.r.t. payload providers. In
particular Pact can be ahead of consensus.

However, consensus' store of validated block headers is used to migrate
the BlockHistory table. If the corresponding headers are missing from
consensus, we can't migrate those rows of the BlockHistory table. Thus
*we need to avoid erroring out in that case*.

Additionally, the rows of all other Pact tables should agree with the
highest BlockHistory row. Thus *we need to execute a rewind to that block
at the end of the migration*.

Test Plan:
replay on mainnet database.

Change-Id: Id000000074e2d41ff0d0254f3d31e9c712adc6e5

Reviewers: jmcardon, larskuhtz, rsoeldner

Reviewed By: rsoeldner, larskuhtz

Pull Request: kadena-io#2261
Test Plan:
none required.

Change-Id: Id000000068eb15bd1ff51bc3590ac087c73da495

Reviewers: chessai, larskuhtz

Reviewed By: chessai, larskuhtz

Pull Request: kadena-io#2262
Created using jj-spr 1.3.6-beta.1
Still has a TODO for supporting minimumBlockHeaderHistory in the new Pact header oracle.
Comment thread .github/workflows/macos.yaml Fixed
edmundnoble and others added 6 commits October 19, 2026 19:58
…ntain permissions'

Co-authored-by: Copilot Autofix powered by AI <62310815+github-advanced-security[bot]@users.noreply.github.com>
The cabal-cache sync step fails intermittently (e.g. S3 access issues),
aborting otherwise healthy builds. Mark it continue-on-error so builds
proceed from source when the remote cache is unavailable.
The macos-latest runners fail to link with:
  ld: tapi error: malformed file ... MacOSX27.0.sdk ...
  unknown architecture arm64e.x1-macos
because clang and ld are picked from mismatched toolchains. Probe both
xcode-select locations and keep the one that can actually link.
The macOS workflow still pointed at the upstream kadena-cabal-cache bucket
with the upstream secret names, so the cache sync failed with exit code 1
on this fork. Point it at community-kda-cabal-cache with the
kda_community_* secrets, matching applications.yml.
@CryptoPascal31 CryptoPascal31 changed the title PayloadProvider + EVM Chainweb Revolution Oct 21, 2026
@CryptoPascal31
CryptoPascal31 added this pull request to stack #51 October 23, 2026 09:03
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.

4 participants