Nimbus + Nethermind: Tutorial Kintsugi

Diagrama cortesia do documento de espaço de desenvolvimento da Engine API de Mikhail Kalinin. Observe que este diagrama data da era Amphora e, portanto, não é estritamente preciso. No entanto, o fluxo geral de comunicação entre o consenso (consensus) e a execução (execution) para o Kintsugi é o mesmo.

O sprint de Merge do mês de novembro - Kintsugi - começou.

As especificações e marcos do Kintsugi foram lançadas no início deste mês. E nós, junto com as outras equipes clientes, começamos a participar dos devnets semanais de intercalação contínua em preparação para o testnet mais aberto e persistente planejado para o início de Dezembro.

Especificação Kintsugi: recapitulação rápida

Kintsugi incorpora todos os aprendizados (junto com alguns pequenos ajustes) da interoperabilidade anterior, Amphora.

Em um alto nível, o escopo do trabalho na atualização do software cliente da camada de consenso para a especificação Kintsugi é o seguinte:

• Implementação da nova versão da especificação de consenso e passagem em todos os testes de especificação de consenso
• Implementação da nova versão das chamadas de método da Engine API
• Implementação ou atualização da implementação já existente da sincronização otimista (optimistic sync)

No lado da camada de execução, será mais ou menos assim:

• Implementação da nova versão do EIP-3675
• Implementação da EIP-4399
• Implementar a nova versão do servidor Engine API

De acordo com nosso compromisso com a diversidade de clientes, este tutorial abordará como executar uma rede de teste local Nimbus com Nethermind (se você deseja fazer o mesmo com Geth, consulte este documento).

Presumimos que você tenha uma instalação funcional e atualizada do Nimbus - se este não for o caso, comece seguindo as instruções aqui.

1- Instale o dotnet

Nethermind é um cliente Ethereum baseado em .NET Core, então a primeira etapa é baixar o dotnet.

https://dotnet.microsoft.com/download

Note que você pode ter que baixar uma versão específica do dotnet para poder construir o branch Nethermind kintsugi. Neste guia, usamos a versão 5.0.12.

2- Realize o build do Nethermind

Na linha de comando, execute o seguinte:

git clone https://github.com/NethermindEth/nethermind.git --recursive -b themerge_kintsugi
cd src/Nethermind
dotnet build Nethermind.sln -c Release
# if src/Nethermind/Nethermind.Runner/bin/Release/net5.0/plugins has no Nethermind.Merge.Plugin.dll plugin then you may need to run the build again
dotnet build Nethermind.sln -c Release

3- Execute o Nethermind

Uma vez que o Nethermind foi criado, você está pronto para executá-lo:

cd Nethermind.Runner
rm -rf bin/Release/net5.0/nethermind_db
dotnet run -c Release -- --config themerge_kintsugi_m2 --Merge.TerminalTotalDifficulty 0

4- Realize o checkout do branch do Nimbus Kintsugi

Com o Nethermind em execução, abra uma janela de terminal separada. Mude para o diretório nimbus-eth2 e execute:

git checkout kintsugi
git pull
make update

5- Inicie o testnet local

Ainda em nimbus-eth2, execute:

./scripts/launch_local_testnet.sh --preset minimal --nodes 4 --disable-htop --stop-at-epoch 7 -- --verify-finalization --discv5:no

Isso criará um testnet local de 4 nós com 128 validadores que existirão por 7 épocas. Sinta-se à vontade para experimentar diferentes parâmetros, se desejar.

6- Verifique a saída do Nimbus

Se tudo estiver funcionando corretamente, a saída do console Nimbus deve ser semelhante a:

nimbus-eth2$ N=0; while ./scripts/launch_local_testnet.sh --preset minimal --nodes 4 --disable-htop --stop-at-epoch 8 -- --verify-finalization --discv5:no; do N=$((N+1)); echo "That was run #${N}"; sleep 67; done
Building: build/nimbus_beacon_node
Building: build/nimbus_signing_process
Building: build/deposit_contract
Build completed successfully: build/nimbus_signing_process
Build completed successfully: build/deposit_contract
Build completed successfully: build/nimbus_beacon_node
NOT 2021-11-17 15:40:11.894+01:00 Generating deposits                        tid=966934 file=keystore_management.nim:562 totalNewValidators=128 validatorsDir=local_testnet_data/validators secretsDir=local_testnet_data/secrets
NOT 2021-11-17 15:40:51.434+01:00 Deposit data written                       tid=966934 file=deposit_contract.nim:222 filename=local_testnet_data/deposits.json
Wrote local_testnet_data/genesis.ssz
WRN 2021-11-17 15:40:51.443+01:00 Using insecure password to lock networking key key_path=local_testnet_data/network_key.json
INF 2021-11-17 15:40:52.184+01:00 New network key storage was created        topics="networking" key_path=local_testnet_data/network_key.json network_public_key=08021221029b0d9c63dc15335b6f1f73dc359a0bda88a84cc7e0346f12e64084673a35a915
Wrote local_testnet_data/bootstrap_nodes.txt
Wrote local_testnet_data/config.yaml:
DEPOSIT_NETWORK_ID: 1
PRESET_BASE: minimal
MIN_GENESIS_ACTIVE_VALIDATOR_COUNT: 128
MIN_GENESIS_TIME: 0
GENESIS_DELAY: 10
DEPOSIT_CONTRACT_ADDRESS: 0x0000000000000000000000000000000000000000
ETH1_FOLLOW_DISTANCE: 1
ALTAIR_FORK_EPOCH: 1
MERGE_FORK_EPOCH: 2
TERMINAL_TOTAL_DIFFICULTY: 0
That was run #1

Se você estiver usando o macOS, também poderá ver vários avisos parecidos com esses:

warning: (x86_64)  could not find object file symbol for symbol _br_rsa_pkcs1_sig_unpad.pad1

Você pode ignorá-los com segurança.

7- Verifique a saída do Nethermind

No lado do Nethermind, você deve prestar atenção especial às seguintes chamadas JSON RPC: engine_forkchoiceUpdatedV1, engine_getPayloadV1, engine_executePayloadV1 – elas documentam o consenso chamando a engine api para uma carga útil valiosa.

Para elaborar um pouco, em uma beacon chain pós-merge, um cliente da camada de consenso precisa chamar duas funções do cliente da camada de execução para preparar um bloco:

• engine_forkchoiceUpdatedV1, que retorna o status (`SUCCESS` ou `SYNCING`) e um payloadId.
• engine_getPayloadV1 que aceita um payloadId.

O objetivo final dessas duas chamadas é permitir que um bloco de execução (eth1) seja incluído em um bloco de consenso (eth2).

Mais formalmente, engine_executePayloadV1 verifica a carga útil de acordo com o conjunto de regras do ambiente de execução (EIP-3675) e retorna o status da verificação.

forkchoiceUpdatedV1 primeiro propaga a mudança na escolha do fork para o cliente de execução (por exemplo, o cabeçalho da cadeia e o bloco finalizado devem ser atualizados de acordo com os dados fornecidos) antes de iniciar a preparação da carga útil, se necessário; isso permite que o cliente de consenso seja capaz de dar ao cliente de execução algum tempo para preparar a carga útil (ou seja, encontrar o melhor conjunto de transações que puder do mempool) antes que a chamada getPayloadV1 seja feita.

Para pegar emprestada uma explicação de Danny Ryan, intuitivamente as semânticas de chamada são:

• "atualize sua escolha de fork” (nenhuma construção de carga solicitada)
• "atualize sua escolha de fork e comece a construir algo valioso em cima dela!" (construção de carga solicitada)

Este último só acontece quando você precisa propor um bloco.

Como sabemos se o merge aconteceu?

A primeira chamada do método engine_executePayloadV1 que comunica uma carga válida para o cliente de execução inicia a transição do Merge.

Em seguida, o primeiro evento POS_FORKCHOICE_UPDATED (na forma de uma chamada de método engine_forkchoiceUpdatedV1), que finaliza a primeira carga útil comunicada, termina a transição.

Depois que a transição do Merge for finalizada, o Merge pode ser considerado como tendo ocorrido.

Este tutorial foi adaptado do original de Dustin Brody (Dustin está liderando à frente de interoperabilidade de Merge no Nimbus). Se você ficar emperrado em algum lugar ou tiver alguma dúvida, não hesite em entrar em contato conosco em nosso discord. Você pode acompanhar nosso progresso do Kintsugi aqui, e o progresso do Nethermind aqui.