The DendrETH project implements the beacon chain light client syncing algorithm in the form of a smart contract for multiple targeted blockchains, aiming to enable the creation of secure cross-blockchain bridges that don't require a trusted operator. In their current state, our contracts are complete and suitable for testnet deployments, but they are still not intended for production use.
For EVM-based blockchains, we build upon prior research by 0xPARC, Darwinia, Alex Stokes and the Nimbus team to deliver the first end-to-end implementation capable of syncing the entire Mainnet history since Altair. Our current Solidity contract leverages a Circom zero-knowledge circuit to verify the BLS signatures of the Ethereum 2 validators and all of the syncing protocol rules.
Since the base circuit is able to verify complete header-to-header transitions, we also provide a recursive variant that can be used by any Ethereum client to implement one-shot syncing capabilities similar to the ones available in the Mina protocol (please see our analysis regarding the limitations of this approach).
For blockchains based on WebAssembly and BPF, we are developing a direct implementation of the light client syncing protocol based on the highly efficient BLS, SSZ and Light client syncing libraries developed by Supranational and the Nimbus team. When compared to the similarly positioned Snowbridge project, our implementation brings a 36-fold reduction in code size (2.2MB vs 60kb) which should also translate in a significant reduction in gas costs (currently, our code is targeting only the standard WebAssembly run-time instead of the full blockchain environments).
| The smart contract is deployed in | The targeted network is | Circuit Version |
|---|---|---|
| Goerli/Ethereum | goerli | #94 (Capella) |
| Goerli/Optimism | goerli | #94 (Capella) |
| Goerli/Base | goerli | #94 (Capella) |
| Goerli/Arbitrum | goerli | #94 (Capella) |
| Sepolia/Ethereum | goerli | #94 (Capella) |
| Mumbai/Polygon | goerli | #94 (Capella) |
| Testnet/Fantom | goerli | #94 (Capella) |
| Alfajores/Celo | goerli | #94 (Capella) |
| Chiado/Gnosis | goerli | #94 (Capella) |
| Testnet/EVMOS | goerli | #94 (Capella) |
| Malaga/Cosmos | goerli | #94 (Capella) |
| Jungle/EOS | goerli | #94 (Capella) |
| Aurora/Near | goerli | #94 (Capella) |
| Gnosis/Gnosis | goerli | #94 (Capella) |
| Deployment | Update(Min) | Update(Max) | |
|---|---|---|---|
| BeaconLightClient | 1399127 | 266717 | 357029 |
| Deployment | Initialize | Update | |
|---|---|---|---|
| NIM-WASM Light Client | 1308702 | 2991395 | 11706455 |
| ZK-Verifier using nim-bncurve | 1302849 | 447436 | 1812337 |
| ZK-Verifier using constantine | 1378889 | 391408 | 871846 |
Due to the large number of required compiler toolchains and blockchain run-time environments targeted by this project, installing all pre-requisites by hand is impractical. We are offering a deterministic build environment based on the Nix package manager, which is best supported on Linux, but also runs on macOS with some minor limitations at the moment. Windows users may try to use Nix in the Windows Subsystem for Linux, but our team is not currently testing this configuration.
See Getting started with Nix for more details.
Certain scripts in this repository will require API credentials for Infura
and Etherscan in order to be able to deploy the contracts in the official
networks. To specify such credentials, please create a file named .env and
place it at the root of your working copy. Its contents should look like this:
INFURA_API_KEY=1234567890abcdef1234567890abcdef
ETHERSCAN_API_KEY=1234567890ABCDEF1234567890ABCDEF12A normal light client will download light client updates from the Ethereum P2P network or from the Beacon REST API of an Ethereum node. To sync a smart contract, we perform the same process in reverse - we upload the light client updates to the contract hosted on another blockchain in the form of regular transactions. The contract is initialized with a starting bootstrap state and it updates its view of the beacon chain with each processed update.
This allows it to maintain information about a recent finalized beacon chain
block header and a recent optimistic head. The information in these headers
is enough to authenticate any data point in the Ethereum ecosystem because a
beacon chain block header references a BeaconState root hash, which in turn
references a recent execution layer block header, which in turn references the
root hash of the execution layer state. Thus, if a chain of Merkle proofs is
also supplied and verified against the light client contract state, it can be
used to prove in the targeted blockchain the occurrence of any event in the
Ethereum world.
To facilitate the development of ours and other similar projects, we'll be maintaining an archive of the best light client updates for each sync committee period since Altair, as produced by a fully-synced Nimbus node:
https://github.com/metacraft-labs/eth2-light-client-updates
Our archive of light client updates also includes pre-generated zero-knowledge proofs for the latest version of the light client Circom circuit.
To see a full syncing simulation in action, you can execute the following commands:
git clone https://github.com/metacraft-labs/DendrETH.git
cd DendrETH
git submodule update --init --recursive
nix develop # or `direnv allow` if you are using direnv
yarn install
make evm-simulationYou should see a Hardhat simulation, sequentially processing all available updates. At the time of this writing, each update costs around 330K in gas.
The DendrETH relay node efficiently generates proofs and publishes updates for all blockchains supported by the DendrETH project. To simplify the process of running a relay, we provide up-to-date Docker images.
You can also build a custom image yourself by executing the
make dendreth-relay-nodecommand within the development environment provided by this repository.
To run the relay node, please follow these steps:
- Ensure that you have Docker installed on your system.
- Open a terminal or command prompt.
- Execute the following command:
docker run --env-file .env -v relay-node-data:/DendrETH/data metacraft/dendreth-relay-nodeThis command assumes that you want to store all runtime data in a local directory
called relay-node-data. If you prefer to use a different directory, please modify
the command accordingly.
The provided .env file must supply the following variables:
USER_PRIVATE_KEY=private_key
ALCHEMY_API_KEY=api_keyINITIAL_SLOT=5355991
SLOTS_JUMP=64PRATTER=TRUE
MAINNET=FALSE
FOLLOW_NETWORK=pratterCurrently the scripts within the container support following a single network. You can manually run the tasks for publishing updates on a second network.
LC_GOERLI=0xf65B59bc947865490eF92D8461e8B5D0eA87c343
LC_OPTIMISTIC_GOERLI=0xa38f1c6F9F50dbd8d11AdD89c1A218F037498Bc1
LC_BASE_GOERLI=0x8A72855F61181BC3C281dE9C24EFc2571Fe96a04
LC_ARBITRUM_GOERLI=0x6d38269d6670f73630FB3d481c58f064B63E123c
LC_SEPOLIA=0xaf352346cE4c413Cc96f607e4FaBEF5aE523D7Bf
LC_MUMBAI=0xcbF3850657Ea6bc41E0F847574D90Cf7D690844c
LC_FANTOM=0x83809AB88743ecfa320163430d769Fdf07278baf
LC_ALFAJORES=0x85Ba37415962bc0828f7b986a9D52a2760a57317
LC_CHIADO=0xAa5eeb05D0B080b366CB6feA00d16216B24FB9bE
LC_EVMOS=0x8E4D36CD13015EA6F384cab3342156b3dC5d0a53If you skip some of these variables, the relay node won't publish updates for the particular network.
For a full list of supported ENV variables, please see the provided example .env file.
We utilize BullMQ for our system.
We have set up a recurring job that repeats itself after a specified time interval (slots-jump) and starts from an initial slot. The job follows a specific network, currently supporting Pratter and Mainnet. To run this job, execute the following command in the beacon-light-client/solidity folder:
yarn hardhat run-update --initialslot $INITIAL_SLOT --slots-jump $SLOTS_JUMP --follow-network pratter
The Update Polling Worker, responsible for executing this recurring job, is run by executing the following command in the relay folder:
yarn run pollUpdatesWorker
The Update Polling Worker retrieves updates from the Beacon REST API and saves the lastDownloadedUpdate for the job in Redis. Next time, the job starts from this point and adds a task for the Proof Generation Worker, which is executed using in the relay folder.
yarn run proofGenerationWorker
The Proof Generation Worker sends a request to the Prover Server, using input from the Update Polling task.
The Prover Server is started with the following command:
proverServer $PORVER_SERVER_PORT ./build/light_client.zkey
The Prover Server requires a path to a build folder containing the .zkey file. The build folder should also include an executable and a .dat file (light_client and light_client.dat) for witness generation. (Refer to Circom proof generation documentation for more details)
Upon completion of proof generation, the generated proof is saved in Redis. The system uses Redis pub/sub to notify that a proof is ready. Multiple instances subscribing to this notification attempt to publish the proof on-chain.
These instances can be executed using:
yarn hardhat start-publishing --light-client $LC_ADDRESS --network goerli --follow-network pratter
in the beacon-light-client/solidity folder.
Our archive of light client updates also includes pre-generated zero-knowledge proofs for the latest version of the one-shot syncing Circom circuit.
To see a simulation demonstrating the syncing process to any sync committee period, you can execute the following commands:
git clone https://github.com/metacraft-labs/DendrETH.git
cd DendrETH
git submodule update --init --recursive
nix develop # or `direnv allow` if you are using direnv
yarn install
make one-shot-syncing-simulationThe circuits employed by this project are some of the largest ever developed. We are building upon the BLS primitives implemented by the circom-pairing project and the SHA256 implementation from circomlib, both of which are already very large. To perform our compilations, we had to purchase a server with two Intel(R) Xeon(R) E5-2650 CPUs and 384GB of RAM where the fully integrated build takes the following amount of time:
| Circuit compilation | 6h, 27m, 47s |
| Circuit template instances | 410 |
| Circuit non linear Constraints | 89648756 |
| Circuit linear Constraints | 0 |
| Circuit public inputs | 0 |
| Circuit public outputs | 2 |
| Circuit private inputs | 20961 |
| Circuit private outputs | 0 |
| Circuit wires | 88833842 |
| Circuit labels | 472858554 |
| Witness generator C++ compilation | 1h |
| Trusted setup phase 2 key generation | 26h |
| Trusted setup phase 2 contribution | N/a |
| Proving key size | 49G |
| Proving key verification | N/a |
| Proof generation (rapidsnark) | 4m, 25s |
| Proof verification time | 1s |
The cited proof generation time was obtained from a configuration with a single Intel(R) i9-12000K CPU with 128GB of RAM.
You can examine the required commands for building the final circuit here:
At the moment, there are multiple test suites of interest:
-
The WebAssembly tests of the Nim light client:
yarn test -
The Circom components test suite:
cd beacon-light-client/circom yarn hardhat test -
The Solidity contract test suite:
cd beacon-light-client/solidity yarn hardhat test
Please use the following BibTex entry to cite this work while an official paper is not available:
@report{dendreth2023, author = {Armenchev, Simeon and Belchior, Rafael and Dimov, Dimo and Ivanichkov, Emil and Karadjov, Zahary and Kirkov, Kristin and Kirov, Petar and Miladinov, Yordan}, title = {DendrETH: A smart contract implementation of the Ethereum light client sync protocol}, year = {2023}, institution = {Metacraft Labs and Blockdaemon}, number = {0}, url = {https://github.com/metacraft-labs/DendrETH}, note = {Accessed: 21-June-2023} }
All code within this repository is licensed under GPLv3.
Please check out our roadmap to learn more about the blockchains and the use cases that we plan to support in the future.