Quick Merge Demo: Prysm x Catalyst interop

Last Updated: Mar 30, 2021

• Quick Merge Demo: Prysm x Catalyst interop
  • Background
  • Setup
  • Commands to start
  • What you should see
    • Catalyst
    • Beacon node
    • Validator client
  • Next steps
  • How to send transaction
    • Metamask
    • Beacon node
    • Validator
  • Reference

Background

This provides instructions on running beacon chain and eth1 chain using Prysm's interop mode. Beacon chain node (Prysm) inserts application payload into the eth1 chain node (Catalyst). Beacon chain validator produces application payload by requesting from eth1 node and signs over it. In this interop mode, participation is 100% and the chain should finalize at the start of epoch 4.

Setup

• Install Bazel

  • The cmake package
  • The git package installed
  • libssl-dev installed
  • libgmp-dev installed
  • libtinfo5 installed
  • Then, install Bazel

• Prysm

  • Link: https://github.com/prysmaticlabs/prysm/tree/quick-merge-demo
  • Branch: quick-merge-demo
  • Commit: 91334408302e09097a143fc3032e1df8bfbc0166

• Catalyst

  • Link: https://github.com/prysmaticlabs/bazel-go-ethereum/tree/catalyst
  • Branch: catalyst
  • Commit: a7522982fb2a9f60ddb08f28d42029c3d23267a2

Commands to start

1.) Check out catalyst branch and start the Catalyst eth1 instance

./run-catalyst.sh

Notes: If you plan to send transaction later, edit run-catalyst.sh's "alloc\": \{\} with the address and eth amount.

2.) Check out quick-merge-demo branch and generate the beacon chain genesis state

bazel run //tools/genesis-state-gen – –num-validators=64 –output-ssz=/tmp/genesis.ssz –mainnet-config

Note: There's no limit to the number of validators you can use. But make sure it's consistent with the validator command below

3.) In the same quick-merge-demo branch, start the beacon node in interop mode

bazel run //beacon-chain – –datadir /tmp/mergechaindata –clear-db –interop-genesis-state /tmp/genesis.ssz –interop-eth1data-votes –min-sync-peers=0 –http-web3provider=http://localhost:8545 –deposit-contract 0x8A04d14125D0FDCDc742F4A05C051De07232EDa4 –pyrmont –bootstrap-node=

4.) In the same quick-merge-demo branch, start the validator client in interop mode

bazel run //validator – –beacon-rpc-provider localhost:4000 –interop-num-validators=64 –interop-start-index=0 –clear-db

What you should see

Catalyst

Receives from beacon node and imports new application payload to the eth1 chain

Beacon node

Produces new application payload using Catalyst and package payload into beacon block
Inserts beacon block application payload to Catalyst

Validator client

Receives from beacon node and signs beacon block which contains application payload

Next steps

• Further alignment with the merge spec
• Brainstorm how we can leverage this experience for a more public testnet so the community can test drive it. Please do reach out to us if you have any cool ideas

How to send transaction

Metamask

1. Connect to Localhost 8545 and change the chain ID to the one specified in genesis.json (i.e. 220720). Balance with your address should be reflected
   

2. Now send a transaction
   

3. To verify, you should see transaction picked up by the eth1 node
   

Beacon node

Beacon node requests eth1 application data and produces it for validator. It then inserts it back to the eth1 node. (See numTransactions=1)

Validator

Validator signs over the block with eth1 application payload

Back in Metamask, you should see original transaction has been confirmed

Reference

Spec
Research: executable beacon chain
Research: eth1+eth2 client relationship research
Original quick merge proposal
[DRAFT] Eth1-Eth2 communication protocol