Build Your Own Blockchain ETH2.0 Beaconchain (Part1)

Share Build Your Own Blockchain ETH2.0 Beaconchain (Part1)

Subscribe to Avenlabs

<100 subscribers

Subscribe to Avenlabs

<100 subscribers

This article is for educational purposes only. A beacon chain is a future Ethereum 2.0 relay connecting shard chains. There's literally no value in running a beacon chain currently as there are no shards yet and there's no other functionality on the beacon chain available. But it's new technology, and who's not excited about playing around with it?

To bootstrap a new, custom beacon chain, we would need to cover the following topics:

The deposit contract ceremony The beacon chain transition specification The genesis event Bootstrapping the actual network Before we start, we need to understand that the beacon chain, which we will also call eth2 chain for now, cannot live without a legacy Ethereum chain which we will call eth1 chain. There will be a transition from eth1 to eth2 defined by an interface, the so called deposit contract.

The deposit contract ceremony

The deposit contract is a tool that allows gathering Ether deposits on the eth1 chain to enable validators proposing blocks on the eth2 chain later. How this will work in detail, will be covered later. For now, we need to understand that we need the deposit contract before doing anything else.

An example of the deposit contract is available as validator_registration.vy in the eth2.0-specs repository written in the Vyper contract language. The main function of interest of that fairly simple contract is -- surprise -- deposit(). But we'll cover that later.

We need three things now:
The compiled bytecode of the contract The ABI of the contract And an eth1 testnet to deploy it to To compile the contract, we need to install Vyper locally or use an Vyper Online Compiler. The online-compiler comes in pretty handy in some cases, but for such an important piece of infrastructure, we'll use the native compiler locally. It's simple as that:

❯ vyper validator_registration.vy

Output Codes

This is our compiled bytecode which can be deployed later. Now we need the ABI:

❯ vyper -f abi validator_registration.vy

Output Code

[
    {
        "name": "DepositEvent",
        "inputs": [
            {
                "type": "bytes",
                "name": "pubkey",
                "indexed": false
            },
            {
                "type": "bytes",
                "name": "withdrawal_credentials",
                "indexed": false
            },
            {
                "type": "bytes",
                "name": "amount",
                "indexed": false
            },
            {
                "type": "bytes",
                "name": "signature",
                "indexed": false
            },
            {
                "type": "bytes",
                "name": "index",
                "indexed": false
            }
        ],
        "anonymous": false,
        "type": "event"
    },
    {
        "outputs": [],
        "inputs": [],
        "constant": false,
        "payable": false,
        "type": "constructor"
    },
    {
        "name": "get_deposit_root",
        "outputs": [
            {
                "type": "bytes32",
                "name": ""
            }
        ],
        "inputs": [],
        "constant": true,
        "payable": false,
        "type": "function",
        "gas": 112305
    },
    {
        "name": "get_deposit_count",
        "outputs": [
            {
                "type": "bytes",
                "name": ""
            }
        ],
        "inputs": [],
        "constant": true,
        "payable": false,
        "type": "function",
        "gas": 14558
    },
    {
        "name": "deposit",
        "outputs": [],
        "inputs": [
            {
                "type": "bytes",
                "name": "pubkey"
            },
            {
                "type": "bytes",
                "name": "withdrawal_credentials"
            },
            {
                "type": "bytes",
                "name": "signature"
            },
            {
                "type": "bytes32",
                "name": "deposit_data_root"
            }
        ],
        "constant": false,
        "payable": true,
        "type": "function",
        "gas": 1331065
    }
]

The ABI will allow us later to interact with the deposit contract once it is deployed. As testnet, we will use the Görli Testnet. We will go on straight deploying the bytecode from above and have a contract address: 0xaA888248144Bc5d584a7f400839d0D912F21C39A.

That's it, for a testnet at least. For a mainnet, this process will involve an actual ceremony to determine social consensus on the contract code and the official instance to use. For the sake of easing eth2 clients with eth1 synchronization, we also note down two values:

The deposit contract deploy block: 2355031 The deposit contract deploy date: 1584316800 (March/16, 2020)

The beacon chain transition specification

Now that we have an instance of the deposit contract deployed to a public eth1 network, we'll start configuring our eth2 network transitions. For that, we can template our future network on the existing specification for the official Ethereum 2.0 mainnet, namely mainnet.yaml.

We'll take that specification and modify it slightly to ease running a testnet with just a couple of validators:

DEPOSIT_CONTRACT_ADDRESS: 0xaA888248144Bc5d584a7f400839d0D912F21C39A
- We deployed this contract in the previous step.

GENESIS_FORK_VERSION: 0x00000539
- We just change this to something that's not 0x0 to distinguish our network from mainnet.

BLS_WITHDRAWAL_PREFIX: 0x05
- We change this to something that's not 0x0 to not conflict with mainnet.

MIN_GENESIS_ACTIVE_VALIDATOR_COUNT: 16
- We want to be able to bootstrap the network with as little as 16 validators.

MIN_GENESIS_TIME: 1584316800
- This is our day we deployed the deposit contract, the genesis cannot happen before (Mar/16, 2020).

MIN_DEPOSIT_AMOUNT: 100000000
- We reduce the minimum deposit amount to 0.1 GöETH.

MAX_EFFECTIVE_BALANCE: 3200000000
- We reduce the maximum effective balance to 3.2 GöETH.

EJECTION_BALANCE: 1600000000
- We reduce the ejection balance to 1.6 GöETH.

EFFECTIVE_BALANCE_INCREMENT: 100000000
- We reduce the effective balance increment to 0.1 GöETH.

ETH1_FOLLOW_DISTANCE: 16
- We change the eth1 follow distance to 16.

MIN_GENESIS_DELAY: 3600
- We reduce the minimum genesis delay to one hour.

The Genesis Event

After fully configuring the network, we still don't have a network, yet. What's missing is the genesis state. The genesis is determined by a certain starting condition which is defined in the clients and by our previous network specification. It mainly breaks down to the following criteria:

The minimum number of active validator deposits: We configured 16 and the genesis event will not happen before the deposit contract registered 16 valid deposits. The minimum genesis time: We configured March/16 2020 and the genesis event will not be happening before that date. The minimum genesis delay: We configured to delay the genesis state by at least one hour. The genesis will not happen before we don't have 16 validator deposits and one hour passed. Once these conditions are met, an eth2 client will be able to extract the genesis state from the eth1 chain and validators can start proposing blocks.

The Lighthouse client not only comes with beacon chain and a validator client, but also with a command line tool lcli that assists us in generating keypairs for validators and sending the required validator deposit directly to the deposit contract on the eth1 chain.

First, we instruct our lighthouse node how to configure the new testnet:

lcli --spec mainnet new-testnet \ # template new testnet on mainnet
--deposit-contract-address 0xaA888248144Bc5d584a7f400839d0D912F21C39A \
--deposit-contract-deploy-block 2355031 \
--effective-balance-increment 100000000 \
--ejection-balance 1600000000 \
--eth1-follow-distance 16 \
--genesis-fork-version 0x00000539 \
--max-effective-balance 3200000000 \
--min-deposit-amount 100000000 \
--min-genesis-active-validator-count 16 \
--min-genesis-delay 3600 \
--min-genesis-time 1584316800 \
--testnet-dir ~/.lighthouse/schlesi

These are the values we defined in the previous step and have now been written to our testnet directory ~/.lighthouse/schlesi for further use by the Lighthouse client. To run a beacon node, simply point it to the config:

lighthouse bn \ # lighthouse beacon node
--testnet-dir ~/.lighthouse/schlesi \
--spec mainnet \
--eth1-endpoint http://127.0.0.1:8545 \
--http

Now, our beacon node monitors our local Görli node on localhost port :8545 and waits that something happens on the deposit contract.

We can use lighthouse now to make validator deposits:

lighthouse account validator new \
--testnet-dir ~/.lighthouse/schlesi \
--spec mainnet \
--send-deposits \
--eth1-endpoint http://127.0.0.1:8545 \
--password ./password.txt \
--deposit-value 3200000000 random

This will do the following things:

It reads our testnet spec in ~/.lighthouse/schlesi mainly to know about the deposit contract.
It generates a keypair for a validator in ~/.lighthouse/validators.
It generates a transaction and broadcasts it to the eth1 network using your local node. Important to note here, is that you have enough testnet Ether on the first account of your local Görli node (eth.accounts[0]) and that you provide a valid password to unlock that account.

This does not work with Parity Ethereum, so we used Geth instead. Also, to have both, HTTP-RPC APIs exposed and being able to unlock the accounts, one would have to pass the --allow-insecure-unlock flag to the Görli node. Please, use this with caution!

Once this was done, the node will give positive feedback:

Mar 18 13:53:48.174 INFO Validator deposit successful            

validator_voting_pubkey: 0x82ad6def329bf94f06dae46b3222a3cb9baf2a68e1bf6e1dadaac5bb47dfe6690e2c3222b6256e17a4ec1bdbec6dbd65, 

eth1_tx_hash: 0x13cb9c913d946b222cb595f4bb42bd3e7d11e985d1d4dc3c50faacdc8e42e053

This is how a deposit transaction to our contract looks like. Repeat this step 16 times to meet the minimum genesis deposit threshold. The beacon chain closely monitoring the deposit contract notices the met threshold:

Mar 18 13:55:42.991 INFO Minimum genesis deposit count met       block_number: 2366961, deposit_count: 16, service: beacon

Mar 18 13:55:57.647 INFO Deposit contract genesis complete       validator_count: 16, eth1_block_height: 2366961, service: beacon

Mar 18 13:55:57.680 INFO Beacon chain initialized head_slot: 0, 
head_block: 0xd0ad…1b0d, head_state: 0xdadf…c6bc, service: beacon

The genesis state can be extracted from the eth1 contract using lcli:

lcli eth1-genesis \
--testnet-dir ~/.lighthouse/schlesi \
--eth1-endpoint http://127.0.0.1:8545

Bootstrapping the actual network

Now that the genesis event happened, we need two last things to bootstrap the actual network:

Validators proposing new blocks
Bootnode records allowing for other nodes to connect

Fortunately, both is available in Lighthouse. To run your 16 validators configured locally, simply run:

lighthouse vc --allow-unsynced

The --allow-unsynced option is required as we do not have any other peers yet and simply allow the validator to start proposing blocks right away.

Mar 18 13:57:20.871 WARN Ethereum 2.0 is pre-release. This software is experimental.

Mar 18 13:57:20.876 INFO Starting validator client datadir: "/home/user/.lighthouse/validators", beacon_node: http://localhost:5052/

Mar 18 13:57:20.893 INFO Connected to beacon node version: Lighthouse/v0.1.0-unstable/x86_64-linux

Mar 18 13:57:20.900 INFO Starting node prior to genesis          seconds_to_wait: 3759

The validator node now waits at least one hour before proposing blocks as defined in our MIN_GENESIS_DELAY.

Meanwhile, we can launch more beacon nodes and start wiring them. To connect them, we take the Ethereum Node Record (ENR) from each of the nodes and add them to our testnet configuration. The ENR looks as follows:

Mar 18 13:55:57.692 INFO ENR Initialised seq: 1, enr: enr:-Iu4QN6QRhX7abcUZ6E5eV9iSNwG0FGWWifEevi98EDGhoPVt3e82j9KC2H7DiLtDGnj03MMrs707fEBgmlkgnY0gmlwhH8AAAGJc2VjcDI1NmsxoQL4Lu3nwG5diXILEh3LiAauCrNgtoTJxGZQER33BTDMKoN0Y3CCIyiDdWRwgiMo, service: network

Our testnet configuration in ~/.lighthouse/schlesi contains a boot_enr.yaml file which we use to collect ENR of known peers to ease discovery. We simply add all known ENR of our beacon-bootnodes to that file which allows the network to have a first point of entry when adding new beacon nodes. The file could look like that:

- "enr:-Iu4QGCUN3RjOLZCab4LLqlOqnnOB9BspIE30Nj5gQGoY00ZXCIW2PCXuGqDLHEPZJK9NO8SFZlKzFF-5rSbTyPqksoBgmlkgnY0gmlwhH8AAAGJc2VjcDI1NmsxoQJmy_5ZkaIFozyMd3gPygG1lVLQONuTL4C1j_smkZ9WmoN0Y3CCIyiDdWRwgiMo"

- "enr:-Iu4QCKxIZVqkBMGHOxfeDvY8Yp0V0uq2MQ8wFS2tQGMfQ1YVuER_WeyVmqKawz6H4JE1OVeN52_kJUdZmkuvpyETjMBgmlkgnY0gmlwhH8AAAGJc2VjcDI1NmsxoQNsaKrbnhjMgAcpHREHrZiCA7sXyEOokOck_1oc3zZMG4N0Y3CCJRyDdWRwgiUc"

- "enr:-Iu4QN6QRhX7abcUZ6E5eV9-AIUSXpNBSytiSNwG0FGWWifEevi98EDGhoPVt3e82j9KC2H7DiLtDGnj03MMrs707fEBgmlkgnY0gmlwhH8AAAGJc2VjcDI1NmsxoQL4Lu3nwG5diXILEh3LiAauCrNgtoTJxGZQER33BTDMKoN0Y3CCIyiDdWRwgiMo"

That's it. We have our own, custom beacon chain now running on Lighthouse.

Mar 21 16:38:26.000 INFO Synced slot: 425, epoch: 13, finalized_epoch: 11, finalized_root: 0x41fc…1ac0, peers: 3, service: slot_notifier

Mar 21 16:38:32.226 INFO Block from local validator              block_slot: 426, block_root: 0xa2ef…e552, service: http

Mar 21 16:38:38.000 INFO Synced slot: 426, epoch: 13, finalized_epoch: 11, finalized_root: 0x41fc…1ac0, peers: 3, service: slot_notifier

Mar 21 16:38:44.218 INFO Block from local validator              block_slot: 427, block_root: 0x563c…b946, service: http

Mar 21 16:38:48.018 INFO Attestation from local validator slot: 427, index: 
0, source: 12, target: 12, service: http

Mar 21 16:38:50.000 INFO Synced slot: 427, epoch: 13, finalized_epoch: 11, finalized_root: 0x41fc…1ac0, peers: 3, service: slot_notifier

Mar 21 16:38:56.249 INFO Block from local validator              block_slot: 428, block_root: 0x8229…eb17, service: http

Mar 21 16:39:02.000 INFO Synced slot: 428, epoch: 13, finalized_epoch: 11, finalized_root: 0x41fc…1ac0, peers: 3, service: slot_notifier

It's important to note, that this network is permissionless. Everyone with 3.2 Görli ETH can generate a validator keypair and make a deposit to the Schlesi validator registration contract. Everyone can be part running validator nodes or beacon chain nodes by simply connecting to the provided ENR. Why don't you give it a try?

Soon, hopefully, we will be able to add other clients to our network, such as Prysm, Nimbus, Teku, or Trinity. The multi-client testnet phase is soon to be upon us.

Full Credit : Afri q9f - Head Of Protocol ChainSafe

https://github.com/ChainSafe

To bootstrap a new, custom beacon chain, we would need to cover the following topics:

The deposit contract ceremony

❯ vyper validator_registration.vy

Output Codes

This is our compiled bytecode which can be deployed later. Now we need the ABI:

❯ vyper -f abi validator_registration.vy

Output Code

[
    {
        "name": "DepositEvent",
        "inputs": [
            {
                "type": "bytes",
                "name": "pubkey",
                "indexed": false
            },
            {
                "type": "bytes",
                "name": "withdrawal_credentials",
                "indexed": false
            },
            {
                "type": "bytes",
                "name": "amount",
                "indexed": false
            },
            {
                "type": "bytes",
                "name": "signature",
                "indexed": false
            },
            {
                "type": "bytes",
                "name": "index",
                "indexed": false
            }
        ],
        "anonymous": false,
        "type": "event"
    },
    {
        "outputs": [],
        "inputs": [],
        "constant": false,
        "payable": false,
        "type": "constructor"
    },
    {
        "name": "get_deposit_root",
        "outputs": [
            {
                "type": "bytes32",
                "name": ""
            }
        ],
        "inputs": [],
        "constant": true,
        "payable": false,
        "type": "function",
        "gas": 112305
    },
    {
        "name": "get_deposit_count",
        "outputs": [
            {
                "type": "bytes",
                "name": ""
            }
        ],
        "inputs": [],
        "constant": true,
        "payable": false,
        "type": "function",
        "gas": 14558
    },
    {
        "name": "deposit",
        "outputs": [],
        "inputs": [
            {
                "type": "bytes",
                "name": "pubkey"
            },
            {
                "type": "bytes",
                "name": "withdrawal_credentials"
            },
            {
                "type": "bytes",
                "name": "signature"
            },
            {
                "type": "bytes32",
                "name": "deposit_data_root"
            }
        ],
        "constant": false,
        "payable": true,
        "type": "function",
        "gas": 1331065
    }
]