[Mega Tracking] Successfully Running Beacon Node + 8 Validators

[rauljordan]

This is a tracking issue for required fixes to the repo to allow us to run a local testnet of one beacon node and 8 connected validator clients with a deposit contract deployed on goerli. This local config should successfully perform shuffling, assignments, and validators should successfully perform their responsibility. I was able to successfully do this locally after encountering many bugs and features we need to fix. This is a tracking issue for all of these required fixes so our runtime will work on the master branch.

NOTE: This local testnet does NOT include incoming deposits post ChainStart or any slashings of any kind

• Beacon node should send ChainStart time to validators only after the beacon state has been initialized
• Debug validators being assigned as proposers AND attesters in the same slot
• Finish integrating the real attestations pool into the validator client, as right now the system will panic given it is a stub when proposing blocks
• Give the validator struct access to the unlocked keystore throughout its runtime
• Check for 0 values when modifying config to smaller numbers, namely, in EpochCommitteeCount, maxCommiteeCount will be 0 currently if we pick a low enough shard count, given it is calculated as SHARD_COUNT / EPOCH_LENGTH, and in a custom config with 1 shard and epoch of 8, 1 / 8 returns 0
• Implement ETH1 data in the server side
• We should use tree hashing as the keys we use to store items in our DB, otherwise blocks are stored by sha3 hash but fetching the parent block by its tree hash root will return nil and our validator client will panic
• Sometimes, we may receive the same log twice from our ETH1 node, so we should store the last received merkle index to make sure we do not unnecessarily update our trie, which will lead to an inconsistent root with that of the contract
• RPC Servers such as validator, proposer had some panics due to not being passed in important properties such as chainService or powChainService during initialization
• BLS public key from herumi is 96 bytes, not 48 as expected by our RPC server, so our beacon node will return an error when fetching assignments
• Deploying the deposit contract should have a higher gas limit as it typically costs almost 3m gas
• Slot ticker in validator client ticks starting from 0 but it should start from params.BeaconConfig().GenesisSlot
• We need to fetch the very initial assignments as soon as the chain starts, so we can add a check if assignments are nil, fetch them

How to Run Local Configuration

First, deploy our deposit contract to goerli using the command

bazel run //contracts/deposit-contract/deployContract -- --httpPath=https://goerli.prylabs.net --privKey=$(echo /path/to/private/key/file) --chainStart=8 --minDeposit=100000 --maxDeposit=3200000 --customChainstartDelay 120

Then, copy the contract address in the output above and spin up a beacon node (MAKE SURE YOU USE A NEW DATA DIRECTORY) with:

 bazel run //beacon-chain -- --web3provider wss://goerli.prylabs.net/websocket --enable-powchain --datadir /path/to/your/datadir --deposit-contract DEPOSIT_CONTRACT_ADDRESS --demo-config

Then, create 8 validator accounts with a unique keystore path each time using the command:

bazel run //validator -- accounts create --password /path/to/passwordfile --keystore-path /path/to/unique/keystore

Copy the output hex data to your clipboard as you will need it later.

Next, run 8 validator clients in separate terminal windows:

 bazel run //validator -- --demo-config --password /path/to/passwordfile --keystore-path /path/to/unique/keystore

Next, using the deposit data hex string from the account creation, for each validator, add it to the javascript list called depositData = []; as shown below:

/**
 * Useful for testing deposits with a deployed contract via metamask.
 *
 * Note: Assumes deposit contract is deployed with max deposit of 3200gwei.
 */

var address = "CONTRACT_ADDRESS_HERE"; // change me!
var d = web3.eth.contract(INSERT_ABI_HERE).at(address);

var cb = function(idk, receipt) {
    console.log("TX = " + receipt);
};

// Add a list of deposit data hex strings here
depositData = [
    "YOUR_VALIDATOR_DEPOSIT_DATA_HERE"
];

depositData.forEach(data => {
    web3.eth.sendTransaction({to: d.address, value: web3.toWei(3200000, 'gwei'), data: d.deposit.getData(data), gas: 1000000}, cb);
});

Then, navigate to a web3 enabled website such as etherscan.io, open the javascript console, and paste in the js from above. Metamask will ask to confirm 8 transactions. Make sure your beacon node and 8 validators are running, and then press confirm. Then, the system will begin as ChainStart will be reached and validators will begin their responsibilities!

[rauljordan]

Issue with the validators being assigned as proposer/attester in same slot is due to the pigeonhole principle when using a committee size of 1 or 2 with a shard count of 1. In production this case will happen extremely rarely, as we will also have a higher shard count.

[rauljordan]

Going to continue doing some local tests today to see if we can consistently reach the success scenario of validators performing their responsibility. Will identify any bugs and add any issues if necessary, if not, then we can close this.

[terencechain]

I'll join you with this after I wrap up operations pool work in an hour