Giter Club home page Giter Club logo

dendreth's Introduction

Introduction

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).

Deployed instances of our smart contracts

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)

Gas Usage

EVM(ETH) blockchain

Deployment Update(Min) Update(Max)
BeaconLightClient 1399127 266717 357029

COSMOS blockchain

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

Working with the Codebase

Pre-requisites

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=1234567890ABCDEF1234567890ABCDEF12

How does a smart contract sync with the network?

A 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

EVM Simulation

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-simulation

You should see a Hardhat simulation, sequentially processing all available updates. At the time of this writing, each update costs around 330K in gas.

Running the DendrETH relay node

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-node command within the development environment provided by this repository.

To run the relay node, please follow these steps:

  1. Ensure that you have Docker installed on your system.
  2. Open a terminal or command prompt.
  3. Execute the following command:
docker run --env-file .env -v relay-node-data:/DendrETH/data metacraft/dendreth-relay-node

This 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:

For accessing the networks and signing transactions:

USER_PRIVATE_KEY=private_key
ALCHEMY_API_KEY=api_key

To configure the starting point and frequency of updates:

INITIAL_SLOT=5355991
SLOTS_JUMP=64

To configure which networks should be followed:

PRATTER=TRUE
MAINNET=FALSE
FOLLOW_NETWORK=pratter

Currently the scripts within the container support following a single network. You can manually run the tasks for publishing updates on a second network.

To specify the deployed instances of the DendrETH smart contracts:

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=0x8E4D36CD13015EA6F384cab3342156b3dC5d0a53

If 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.

How does the relayer work?

We utilize BullMQ for our system.

We have set up a recurring job that repeats itself after a specified time interval (slotsjump) 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 --slotsjump $SLOTS_JUMP --follownetwork 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 --lightclient $LC_ADDRESS --network goerli --follownetwork pratter

in the beacon-light-client/solidity folder.

Diagram of the relayer

Relayer diagram

One-shot syncing simulation

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-simulation

Building the Circom circuits

The 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:

https://github.com/metacraft-labs/DendrETH/blob/main/beacon-light-client/circom/scripts/proof_efficient/build_proof.sh

Running the test suites

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
    

Suggested citation

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} }

License

All code within this repository is licensed under GPLv3.

Roadmap

Please check out our roadmap to learn more about the blockchains and the use cases that we plan to support in the future.

dendreth's People

Contributors

chonkov avatar dimo99 avatar emilivanichkovv avatar georgehntr avatar hristostaykov avatar kkirkov avatar martinnikov avatar monyarm avatar nikolaykostadinov21 avatar owliie avatar petarkirov avatar rafaelapb avatar smanilov avatar stefan-nikolov96 avatar xearty avatar zah avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

dendreth's Issues

Write script that dynamically creates Prometheus config

Currently the ports on which the Prometheus service is actively listening are a predetermined set.

Extend the run-relay.sh script so that it counts the number of launched services and dynamically creates the Prometheus targets in its config file.

Redesign relayer

  1. Update the relayer polling task to work with {from, to} tasks that will generate proof from a given slot to a given slot.

  2. Introduce an orchestration module that will be triggered every SLOTS_JUMP*12s. This module will create a new task from a given slot to the best multiple of SLOTS_JUMP.

The orchestration module will review all the smart contracts and their respective slots. If any contracts are not aligned to the same slot, the orchestration will generate an optimized set of updates to synchronize them.

Develop a HardHat based simulation of a Solidity sync

Once the archive of light client updates in place, develop a script based on HardHat, Ethers.js and TypeScript that will simulate a full sync of a Solidity-based light client implementation such as the one from Darwinia (MIT licenesed). The main objective is to gather some data on the required gas under such realistic conditions. We shall maintain our own copy of all Solidity contracts in this repo in order to be able to experiment with gas usage optimizations that will be contributed back to the Darwinia project.

Create a commitment mapper SHA256 -> Poseidon for the validators

The main issue we are encountering is that the SHA-256 hash function, which we currently use for our Merkle proofs in the Ethereum consensus specification trees, is not zk-friendly.

We propose to create a commitment mapping from the validators' root (a SHA-256 Merkle tree comprising all validators) to a Poseidon root of validators. This process would involve generating a proof that a given SHA-256 Merkle tree of validators matches a corresponding Poseidon Merkle tree of validators. Given the sheer number of validators, this tree will be formed using recursive proofs. Since only a small fraction of validators changes per epoch, we can economically update and reuse the proofs. The Poseidon hash function, being more zk-friendly, could then be used to validate that a specific validator belongs to the tree in a more cost-effective manner.

Steps:

  • We will begin by creating the leaves level with a hashtree root of a single validator.
  • Then, the second level will aggregate their hashes and the proofs of the leaves, producing one SHA256 hashtree root and one Poseidon hashtree root.
  • Eventually, we will provide proof that the SHA256 root corresponds to the Poseidon root.

Plonky2 seems like the suitable proving system for this as recursion there is very cheap and we have verifiers for circom implemented.

Create a Groth16 verifier based on the Constantine library

Constantine is a highly-optimized Nim library implementing the BN254 curve used for Groth16 verification:
https://github.com/mratsim/constantine

Its performance is largely based on the use of carefully tuned inline assembly (which we cannot use when targeting WASM), but according to the author of the library (Mamy Ratsimbazafy), even without these tricks it should be more performant than nim-bncurve.

To disable the use of inline assembly, we need to compile the library with -d:CttASM=false.

Create a benchmark for evaluating the performance of the WASM implementations of the BN curve

Our repository currently features a Nim and Rust implementation of the BN curve primitives required for Groth16 verification.

The Nim implementation is lifted from the Nimbus codebase and the Rust one is taken from arkworks. There are some additional implementations that we can potentially evaluate such as the original BN curve crate from ZCash and the WASM-native work in the wasmcurves project.

Due to various technical details, these implementations are not portable to all of our targeted blockchains, but we need to understand better how they stack against each other performance-wise.

We should create a basic test harness based on the standard WebAssembly run-time in node.js (and potentially other run-times in the future). The benchmark can measure either the wall clock time as a good proxy for the consumed gas or things like executed instructions count if some of the WASM run-times can provide such information.

Refresh DendrETH documentation

Remove the following code snippets and text from -

In How does the relayer work?

INITIAL_SLOT=5355991
SLOTS_JUMP=64

...

We have set up a recurring job that repeats itself after a specified time interval (slotsjump) 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 --slotsjump $SLOTS_JUMP --follownetwork pratter

@Dimo99, is this step completely redundant or should it be replaced by something else?

In Running DendrETH relay node

This passage -

You can also build a custom image yourself by executing the make dendreth-relay-node command within the development environment provided by this repository.

implies this step is optional while it is the default way to set up the docker environment in which we can deploy the relayer.

In Running the test suites

The WebAssembly tests of the Nim light client:
yarn test-emcc seems to be deprecated and should be replaced with yarn test

Additionally

Solidity tests fail if ETHEREUM_MAINNET_RPC is not set in .env

wasm nim-lc tests fail if

CUDOS_MNEMONIC
CUDOS_PUBLIC_KEY
CUDOS_CONTRACT_ADDRESS
CUDOS_RPC_ENDPOINT
COSMOS_LOCAL_MNEMONIC
COSMOS_LOCAL_RPC_ENDPOINT
MALAGA_ADDRESS
MALAGA_RPC_ENDPOINT
MALAGA_MNEMONIC

are missing from .env
These should be included in the README.md or better yet - provide the user with a preset .env

The docker image requires more than the default partition size - steps to increase the docker partition size should be included -

sudo systemctl stop docker.service docker.socket
sudo zfs umount -f zfs_root/nixos/var/lib/docker
sudo zfs destroy -fr zfs_root/nixos/var/lib/docker
sudo zfs create zfs_root/nixos/var/lib/docker -o canmount=on -o quota=100G
systemctl start docker.service docker.socket

sudo zfs set "zfs_root/nixos/var/lib/docker" -o canmount=on -o quota=300G
sudo zfs quota=300G "zfs_root/nixos/var/lib/docker"
  • The supervisor is central to the execution and common commands to interact with it should be provided.
    This is how you should shutdown the supervisor - sudo unlink /tmp/supervisor.sock

  • Add expected gas fee under deployed smart contracts table

[EPIC] Implementation of Validators Balance Proof

Objective: https://hackmd.io/@metacraft-labs/DendrETH-for-liquid-staking-protocols

Subtasks:

Implement the light client in Nim for WebAssembly based targets

The light client implementation will be extracted from the Nimbus codebase. We will compare the size and the efficiency of the resulting code against the Rust implementation created by the Snowbridge project on a real-world client updates obtained from the beacon chain mainnet. The results of the comparison will be reproducible and tracked over time in our CI.

The tested WebAssembly compiler toolchains will be Rust, Nim+Clang, NLVM.

We should be able to target Substrate, Cosmos, the Internet Computer, Elrond and Solana from the same codebase as well as well as stand-alone WebAssembly rumtimes such as Wasmer for a simplified form of unit testing.

Upgrade Circom compiler to the latest version

  1. @monyarm will create a branch in nix-blockchain-development that upgrades the Circom Nix package to the latest version (currently v2.1.5) and will open a PR.
  2. Once the CI for the PR is green, @monyarm will prepare a branch in DendrETH where the nix-blockchain-development flake input points to the branch
  3. @Dimo99 will test the new version of the compiler to ensure it works correctly
  4. Assuming all goes well, we'll merge the PR in nix-blockchain-development and merge the branch in DendrETH with the upgrade of Circom

From DevOps point of view, the main reason for upgrading is the -l option which was introduced in 2.0.8.

Encountering a build error

Hi, I'm trying to run the EVM Simulation, but I'm getting the following error when I'm running the nix develop command. I'm able to circumvent the issue by running direnv allow instead, but I'm not sure if that's the right approach.

Submodule 'vendor/build-artifacts' ([email protected]:metacraft-labs/DendrETH-build-artifacts.git) registered for path 'vendor/build-artifacts'
Submodule 'vendor/circom-pairing' (https://github.com/metacraft-labs/circom-pairing.git) registered for path 'vendor/circom-pairing'
Submodule 'vendor/eth2-light-client-updates' ([email protected]:metacraft-labs/eth2-light-client-updates.git) registered for path 'vendor/eth2-light-client-updates'
Submodule 'vendor/nim' ([email protected]:metacraft-labs/nim.git) registered for path 'vendor/nim'
Submodule 'vendor/nim-blscurve' ([email protected]:metacraft-labs/nim-blscurve.git) registered for path 'vendor/nim-blscurve'
Submodule 'vendor/nim-bncurve' (https://github.com/status-im/nim-bncurve) registered for path 'vendor/nim-bncurve'
Submodule 'vendor/nim-confutils' ([email protected]:status-im/nim-confutils.git) registered for path 'vendor/nim-confutils'
Submodule 'vendor/nim-faststreams' ([email protected]:status-im/nim-faststreams.git) registered for path 'vendor/nim-faststreams'
Submodule 'vendor/nim-serialization' ([email protected]:status-im/nim-serialization.git) registered for path 'vendor/nim-serialization'
Submodule 'vendor/nim-ssz-serialization' ([email protected]:metacraft-labs/nim-ssz-serialization.git) registered for path 'vendor/nim-ssz-serialization'
Submodule 'vendor/nim-stew' ([email protected]:status-im/nim-stew.git) registered for path 'vendor/nim-stew'
Submodule 'vendor/nim-stint' ([email protected]:status-im/nim-stint.git) registered for path 'vendor/nim-stint'
Submodule 'vendor/nim-terminaltables' ([email protected]:xmonader/nim-terminaltables.git) registered for path 'vendor/nim-terminaltables'
Submodule 'vendor/nimcrypto' ([email protected]:cheatfate/nimcrypto.git) registered for path 'vendor/nimcrypto'
Cloning into '/Users/jspark/Documents/GitHub/hackathon/2023ZKHackathon/second-try/DendrETH/vendor/build-artifacts'...
Cloning into '/Users/jspark/Documents/GitHub/hackathon/2023ZKHackathon/second-try/DendrETH/vendor/circom-pairing'...
Cloning into '/Users/jspark/Documents/GitHub/hackathon/2023ZKHackathon/second-try/DendrETH/vendor/eth2-light-client-updates'...
Cloning into '/Users/jspark/Documents/GitHub/hackathon/2023ZKHackathon/second-try/DendrETH/vendor/nim'...
Cloning into '/Users/jspark/Documents/GitHub/hackathon/2023ZKHackathon/second-try/DendrETH/vendor/nim-blscurve'...
Cloning into '/Users/jspark/Documents/GitHub/hackathon/2023ZKHackathon/second-try/DendrETH/vendor/nim-bncurve'...
Cloning into '/Users/jspark/Documents/GitHub/hackathon/2023ZKHackathon/second-try/DendrETH/vendor/nim-confutils'...
Cloning into '/Users/jspark/Documents/GitHub/hackathon/2023ZKHackathon/second-try/DendrETH/vendor/nim-faststreams'...
Cloning into '/Users/jspark/Documents/GitHub/hackathon/2023ZKHackathon/second-try/DendrETH/vendor/nim-serialization'...
Cloning into '/Users/jspark/Documents/GitHub/hackathon/2023ZKHackathon/second-try/DendrETH/vendor/nim-ssz-serialization'...
Cloning into '/Users/jspark/Documents/GitHub/hackathon/2023ZKHackathon/second-try/DendrETH/vendor/nim-stew'...
Cloning into '/Users/jspark/Documents/GitHub/hackathon/2023ZKHackathon/second-try/DendrETH/vendor/nim-stint'...
Cloning into '/Users/jspark/Documents/GitHub/hackathon/2023ZKHackathon/second-try/DendrETH/vendor/nim-terminaltables'...
Cloning into '/Users/jspark/Documents/GitHub/hackathon/2023ZKHackathon/second-try/DendrETH/vendor/nimcrypto'...
git-lfs filter-process: git-lfs: command not found
fatal: the remote end hung up unexpectedly
Submodule path 'vendor/circom-pairing': checked out '82bac4a27499fc11cf3ebbb64c525b526f13b552'
Submodule path 'vendor/eth2-light-client-updates': checked out 'c9d5a907b55db0e503661bcfa3963d6fd47eb462'
Submodule path 'vendor/nim': checked out '77edc2bacac1418aeee934fec871eb75b1b18b77'
Submodule path 'vendor/nim-blscurve': checked out 'd93da7af30a9a2160f68d84c5210a12c4d16df00'
Submodule 'vendor/blst' (https://github.com/supranational/blst) registered for path 'vendor/nim-blscurve/vendor/blst'
Submodule 'miracl-core' (https://github.com/miracl/core) registered for path 'vendor/nim-blscurve/vendor/miracl-core'
Cloning into '/Users/jspark/Documents/GitHub/hackathon/2023ZKHackathon/second-try/DendrETH/vendor/nim-blscurve/vendor/blst'...
Cloning into '/Users/jspark/Documents/GitHub/hackathon/2023ZKHackathon/second-try/DendrETH/vendor/nim-blscurve/vendor/miracl-core'...
Submodule path 'vendor/nim-blscurve/vendor/blst': checked out 'b38a52c86e4f5ae69ba6eca41d050707b6fcc72b'
Submodule path 'vendor/nim-blscurve/vendor/miracl-core': checked out 'd799a3f7f4edfdad8c8b709e04f8a0a7b5a7d251'
remote: Enumerating objects: 34, done.
remote: Counting objects: 100% (34/34), done.
remote: Compressing objects: 100% (5/5), done.
remote: Total 19 (delta 14), reused 19 (delta 14), pack-reused 0
Unpacking objects: 100% (19/19), 2.51 KiB | 20.00 KiB/s, done.
From https://github.com/status-im/nim-bncurve
 * branch            8136ebdc515df4a3f269eba5f05c625ae742df83 -> FETCH_HEAD
Submodule path 'vendor/nim-bncurve': checked out '8136ebdc515df4a3f269eba5f05c625ae742df83'
Submodule path 'vendor/nim-confutils': checked out 'a26bfab7e5fb2f9fc018e5d778c169bc05772ee6'
Submodule path 'vendor/nim-faststreams': checked out 'c80701f7d23815fab0b6362569f3195957e57856'
Submodule path 'vendor/nim-serialization': checked out '493d18b8292fc03aa4f835fd825dea1183f97466'
Submodule path 'vendor/nim-ssz-serialization': checked out '66097b911158d459e5114fabd0998f0b2870f853'
Submodule path 'vendor/nim-stew': checked out '06621a2fcddf01b0231aaa6d18531b0a746b3140'
Submodule path 'vendor/nim-stint': checked out '27a7608f33a485fb837c9759ddb4a7c874eb7ad2'
Submodule path 'vendor/nim-terminaltables': checked out '37981f5d403fb55688e00d24ab9b1d56e252f52b'
Submodule path 'vendor/nimcrypto': checked out '24e006df85927f64916e60511620583b11403178'
Unable to checkout '24a97aae330fc12007fe51d4918293f5fdc2e62b' in submodule path 'vendor/build-artifacts'
➜  DendrETH git:(main) git submodule update --init --recursive
➜  DendrETH git:(main) nix develop
warning: ignoring untrusted substituter 'https://nix-blockchain-development.cachix.org', you are not a trusted user.
Run `man nix.conf` for more information on the `substituters` configuration option.
error:
       … while evaluating the attribute 'optionalValue.value'

         at /nix/store/g738q3jxmym83jx24d422nwc0nas4zyv-source/lib/modules.nix:799:5:

          798|
          799|     optionalValue =
             |     ^
          800|       if isDefined then { value = mergedValue; }

       … while evaluating a branch condition

         at /nix/store/g738q3jxmym83jx24d422nwc0nas4zyv-source/lib/modules.nix:800:7:

          799|     optionalValue =
          800|       if isDefined then { value = mergedValue; }
             |       ^
          801|       else {};

       (stack trace truncated; use '--show-trace' to show the full trace)

       error: NAR hash mismatch in input 'github:numtide/flake-utils/93a2b84fc4b70d9e089d029deacc3583435c2ed6' (/nix/store/dc2fivkjahwx47zhjs9jx19ybd9wwcdr-source), expected 'sha256-nuEHfE/LcWyuSWnS8t12N1wc105Qtau+/OdUAjtQ0rA=', got 'sha256-U02riOqrKKzwjsxc/400XnElV+UtPUQWpANPlyazjH0='

Uploading the Verifier smart contract to Cosmos's testnet `Cudos` requires specific version of the `cargo dependencies`.

Right now the our uploading and initialising script does not support it. We need to find a workaround for this.

In previous testing we found that this change in the cargo file will solve the problem

cosmwasm-schema = { version = "1.0.0-beta", default-features = false }
cosmwasm-std = { version = "1.0.0-beta", default-features = false, features = ["iterator"]  }
cosmwasm-storage = { version = "1.0.0-beta", default-features = false, features = ["iterator"] }

Validator balances circom circuit

The public inputs to the circuit are:

  • validatorsAccumulator: A Merkle tree accumulator of validator public keys and Eth1 deposit indexes. Eth1 deposit index is need to validate if the validator is already part of the beacon chain.
  • stateRoot: The current beacon state root against which the proof is made.
  • balanceSum: The sum of all active validator balances.

The workflow of the circuit is as follows:

  1. Epoch Calculation: The currentEpoch is calculated from the provided slot. This calculation is then constrained. A Merkle proof verifies that the slot aligns with the provided stateRoot.

  2. Index and Root Validations: The circuit checks if the currentEth1DepositIndex aligns with the stateRoot. It also validates whether the provided validatorsRoot and balancesRoot are part of the stateRoot.

  3. Validator Verification: The circuit validates all validators within validatorsRoot. It uses the RangeCheck circuit to confirm that the currentEpoch falls between the validator's activation and exit epochs. If a validator is inactive or their Eth1 deposit index precedes the validator's Eth1 deposit index, the bitmask for that validator is set to 0. Validators whose Eth1 deposit index is larger than the current Eth1 deposit index aren't constrained to have valid Merkle proof because they aren't yet part of the tree.

  4. Balance Index Check: The circuit checks that provided balancesProofIndexes correspond to the validatorIndex divided by 4 plus balancesProofIndexesRemainders. This is because balances are stored in a 256-bit array, with each balance occupying a separate 64 bits of the 256-bit segment.

  5. Balance Validations: It validates that all the passed balances are valid with respect to the balancesRoot.

  6. Validator Accumulator Validation: The circuit verifies that the hash tree root of all passed validators and their Eth1 deposit indexes matches the passed validatorAccumulator.

  7. Balance Sum Calculation: The circuit sums all the balances according to the bitmask calculated for the validators.

  8. Hashing and Output Generation: The public values are hashed. The circuit outputs the first 253 bits of the SHA-256 hash of the public inputs to make circuit verification more cost-effective.

The circuit is implemented in #153

Survey existing EVM light client implementations for other Blockchains

We should maintain a documentation resource listing all existing smart contract light client implementations for other blockchains that can be used for creating a two-way bridge.

For Polkadot, the Snowbridge project has stated goals, very similar to ours.

For Solana, a similar bridge have been discussed here:
https://blog.nil.foundation/2021/11/01/solana-ethereum-bridge-design.html

For Cosmos, a light client implementation is being developed here:
https://github.com/ChorusOne/tendermint-sol

Tests for relayer

  1. Write unit tests for individual functions
  2. Use mock tests for API calls
  3. Think of ways to write integration tests for an asynchronous system

Recrusive proof

  • Add a commitment to the public inputs using poseidon/pedersen hash currently the public inputs are
  signal input originator[2];
  signal input nextHeaderHashNum[2];
  • Add the vk to the commitment
  • Introduce participation rate variables they can be an array of 1000 variables that will tell what was the participation for the sync committee and the commitment of public inputs

Add ESLint rule that forbids using `process.env` directly

We have a lot erroneous code that does things like String(process.env['SOME_VAR']), which simply masks possible issues when the variable is not defined, or defined but not following the expected schema.

The solution is three-fold:

  • Introduce a helper module for accessing env variables and validating that they match the expected format
  • Add ESLint rule that forbids access to process.env
  • Run ESLint in the CI pipeline

Setup Circom development environment

We need a basic example demonstrating how a simple Circom circuit can be compiled, executed and later verified in an Ethereum smart contract.

Create a Nix package for NLVM

NLVM is an alternative build of the Nim compiler that compiles the Nim code directly to LLVM IR and could potentially produce smaller and more efficient WASM binaries.

Once we have built-it, you should be able to act as a drop-in replacement for the Nim compiler. Since the build process is likely to be slow, we should cache the result in our Cachix org.

helpers.ts fails with yarn test

FAIL  tests/helpers/helpers.ts
 ● Test suite failed to run

    Your test suite must contain at least one test.

      at onResult (node_modules/@jest/core/build/TestScheduler.js:172:18)
      at node_modules/@jest/core/build/TestScheduler.js:300:17
          at Array.map (<anonymous>)

Do we have any unadded tests @kkirkov ? Please fix, since this is the only failing test.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.