Este artigo é o primeiro de uma série sobre o código fonte do Geth. Através desta série, iremos construir uma estrutura para estudar a implementação do Geth, permitindo que os desenvolvedores aprofundem sua pesquisa nas partes que mais lhes interessam. Esta série contém um total de seis artigos. No primeiro artigo, iremos explorar a arquitetura de design do cliente de camada de execução Geth e o processo de inicialização do nó Geth. O código do Geth é atualizado rapidamente, e o código que veremos posteriormente pode ser um pouco diferente, mas o design geral permanece bastante consistente, e o novo código pode ser lido com a mesma lógica.
01\Cliente Ethereum
Antes da atualização The Merge, o Ethereum tinha apenas um cliente, que era responsável pela execução das transações e também pela consensualidade da blockchain, garantindo que novos blocos fossem gerados em uma certa ordem. Após a atualização The Merge, os clientes do Ethereum foram divididos em camada de execução e camada de consenso, onde a camada de execução é responsável pela execução das transações, manutenção do estado e dos dados, enquanto a camada de consenso é responsável pela implementação da funcionalidade de consenso. As camadas de execução e consenso comunicam-se através de API. Cada camada possui suas próprias especificações, e os clientes podem ser implementados em diferentes linguagens, desde que atendam às especificações correspondentes, sendo que Geth é uma das implementações do cliente da camada de execução. Atualmente, as implementações principais de clientes de camada de execução e camada de consenso são as seguintes:
Camada de Execução
Geth: Mantido por uma equipe diretamente financiada pela Fundação Ethereum, desenvolvido em Go, é reconhecido como o cliente mais estável e testado.
Nethermind: desenvolvido e mantido pela equipe da Nethermind, utilizando a linguagem C#, e recebeu financiamento inicial da Fundação Ethereum e da comunidade Gitcoin.
Besu: originalmente desenvolvido pela equipe PegaSys da ConsenSys, agora é um projeto da comunidade Hyperledger, desenvolvido em Java.
Erigon: Desenvolvido e mantido pela equipe Erigon, financiado pela Fundação Ethereum e pela BNB Chain. Forkado do Geth em 2017, o objetivo é melhorar a velocidade de sincronização e a eficiência do disco.
Reth: desenvolvido sob a liderança da Paradigm, a linguagem de programação é Rust, enfatizando modularidade e alto desempenho, atualmente quase maduro, podendo ser utilizado em ambientes de produção.
Camada de Consenso
Prysm: mantido pela Prysmatic Labs, é um dos primeiros clientes da camada de consenso do Ethereum, desenvolvido em Go, com foco em usabilidade e segurança, recebeu financiamento inicial da Fundação Ethereum.
Lighthouse: Mantido pela equipe Sigma Prime, desenvolvido em linguagem Rust, foca em alto desempenho e segurança de nível empresarial, adequado para cenários de alta carga.
Teku: Desenvolvido inicialmente pela equipe PegaSys da ConsenSys, tornou-se parte da comunidade Hyperledger Besu, desenvolvido em Java.
Nimbus: desenvolvido e mantido pela equipe do Status Network, desenvolvido na linguagem Nim, otimizado para dispositivos com recursos limitados (como smartphones e dispositivos de IoT), com o objetivo de alcançar uma execução leve em sistemas embarcados.
02\Introdução à camada de execução
Pode-se considerar a camada de execução do Ethereum como uma máquina de estados impulsionada por transações, cuja função básica é atualizar os dados de estado através da execução de transações pelo EVM. Além da execução de transações, também há funções como armazenar e validar blocos e dados de estado, operar uma rede p2p e manter um pool de transações.
As transações são geradas pelos usuários (ou programas) de acordo com o formato definido pelas especificações da camada de execução do Ethereum. Os usuários precisam assinar as transações e, se a transação for legítima (Nonce contínuo, assinatura correta, taxa de gas suficiente, lógica de negócios correta), então a transação será finalmente executada pela EVM, atualizando assim o estado da rede Ethereum. O estado aqui refere-se ao conjunto de estruturas de dados, dados e banco de dados, incluindo endereços de contas externas, endereços de contratos, saldo de endereços, bem como códigos e dados.
A camada de execução é responsável por executar transações e manter o estado após a execução das transações, enquanto a camada de consenso é responsável por selecionar quais transações executar. O EVM é a função de transformação de estado dentro desta máquina de estado, e a entrada da função pode vir de vários lugares, podendo ser fornecida pelas informações do bloco mais recente da camada de consenso ou podendo vir de blocos baixados da rede p2p.
A camada de consenso e a camada de execução comunicam-se através da API Engine, que é a única forma de comunicação entre a camada de execução e a camada de consenso. Se a camada de consenso obtiver o direito de criar blocos, ela usará a API Engine para permitir que a camada de execução produza novos blocos; se não obtiver o direito de criar blocos, ela sincronizará os blocos mais recentes para que a camada de execução possa verificar e executar, mantendo assim o consenso com toda a rede Ethereum.
A camada de execução pode ser logicamente dividida em 6 partes:
EVM: responsável pela execução de transações, a execução de transações também é a única forma de modificar o estado.
Armazenamento: responsável pelo armazenamento de dados como o estado e blocos.
Pool de Transações: utilizado para transações submetidas pelos usuários, armazenadas temporariamente, e que serão propagadas entre diferentes nós através da rede p2p.
rede p2p: utilizada para descobrir nós, sincronizar transações, baixar blocos, entre outras funções
Serviço RPC: fornece a capacidade de acessar nós, como por exemplo, os usuários enviando transações para os nós, a interação entre a camada de consenso e a camada de execução.
BlockChain: responsável pela gestão dos dados da blockchain do Ethereum
A figura abaixo mostra os principais processos da camada de execução e as funções de cada parte:
Para a camada de execução (aqui apenas discutimos o Nó Completo), existem três processos chave:
Se for um novo nó que se junta ao Ethereum, é necessário sincronizar blocos e dados de estado a partir de outros nós pela rede p2p. Se for Full Sync, começará a descarregar blocos um a um a partir do bloco génese, verificando os blocos e reconstruindo a base de dados de estado através da EVM. Se for Snap Sync, saltará todo o processo de verificação de blocos, descarregando diretamente os dados de estado do último checkpoint e os dados dos blocos subsequentes.
Se for um nó que já está sincronizado com o estado mais recente, então continuará a obter os blocos mais recentes produzidos a partir da camada de consenso através da Engine API, validar os blocos e, em seguida, executar todas as transações no bloco através da EVM para atualizar o banco de dados de estado e escrever o bloco na cadeia local.
Se um nó que já está sincronizado com o estado mais recente e obteve o poder de criar blocos na camada de consenso, ele irá acionar a camada de execução através da API Engine para produzir o bloco mais recente. A camada de execução obtém transações do pool de transações e as executa, depois as reúne em um bloco e o transmite à camada de consenso através da API Engine, que por sua vez irá difundir o bloco na rede p2p da camada de consenso.
03\Estrutura de código fonte
A estrutura de código do go-ethereum é enorme, mas muito do código é código auxiliar e testes de unidade, e ao olhar para o código-fonte Geth, você só precisa se concentrar na implementação principal do protocolo, e os módulos individuais funcionam da seguinte maneira. Você precisa se concentrar em módulos como core, eth, ethdb, node, p2p, rlp, trie & triedb, etc.:
Contas: Gerencie contas Ethereum, incluindo a geração de pares de chaves públicas e privadas, verificação de assinatura, derivação de endereço, etc
beacon: processar a lógica de interação com a cadeia de sinalização Ethereum (Beacon Chain), suportando a funcionalidade após a fusão (The Merge) do consenso de prova de participação (PoS)
build: scripts de construção e configurações de compilação (como Dockerfile, suporte à compilação multiplataforma)
cmd: entrada da ferramenta de linha de comando, que contém vários subcomandos
comum：ferramentas gerais, como manipulação de bytes, conversão de formato de endereço, funções matemáticas
consenso: Definir mecanismo de consenso, incluindo o anterior Proof-of-Work (Ethash), Single-Node Proof-of-Stake (Clique), Beacon engine, etc
console: fornece um console interativo de JavaScript que permite aos usuários interagir diretamente com o nó Ethereum através da linha de comando (como chamar a API Web3, gerenciar contas, consultar dados da blockchain)
core: Lógica central da blockchain, gerenciando o ciclo de vida de blocos/transações, máquina de estados, cálculo de Gas, etc.
crypto: Implementação de algoritmos de criptografia, incluindo curvas elípticas (secp256k1), hash (Keccak-256), verificação de assinatura
docs: Documentos (como normas de design, descrição da API)
eth: implementação completa do protocolo da rede Ethereum, incluindo serviços de nó, sincronização de blocos (como sincronização rápida, modo de arquivo), transmissão de transações, etc.
ethclient: biblioteca de cliente Ethereum implementada, encapsulando a interface JSON-RPC, para desenvolvedores Go interagirem com nós Ethereum (como consultar blocos, enviar transações, implantar contratos)
ethdb: camada de abstração de banco de dados, suporta LevelDB, Pebble, bancos de dados em memória, etc., armazena dados da blockchain (blocos, estado, transações)
ethstats: coleta e reporta o estado de funcionamento do nó para o serviço de estatísticas, usado para monitorar a saúde da rede
evento：implementar um mecanismo de assinatura e publicação de eventos, suportando comunicação assíncrona entre módulos internos do nó (como a chegada de novos blocos, atualização do pool de transações)
graphql: fornece uma interface GraphQL, suportando consultas complexas (substituindo algumas funcionalidades do JSON-RPC)
Interno: Ferramentas internas ou código que restringe o acesso externo
log: sistema de registo, suporta saída de registo em níveis, registo de contexto de registo
métricas: coleta de indicadores de desempenho (suporte a Prometheus)
miner: lógica relacionada à mineração, gerando novos blocos e empacotando transações (em cenários PoW)
nó：Nó serviço de gestão, integração do p2p, RPC, configuração e arranque da base de dados e outros módulos.
p2p: Protocolo de rede ponto a ponto implementado, suporta descoberta de nós, transmissão de dados, comunicação encriptada
params: define parâmetros da rede Ethereum (mainnet, testnet, configuração do bloco gênesis)
rlp: Implementar o protocolo de serialização de dados específico do Ethereum RLP (Prefixo de Comprimento Recursivo), utilizado para codificar/decodificar estruturas de dados como blocos, transações, etc.
rpc: Implementar interfaces JSON-RPC e IPC para que programas externos interajam com o nó
signer：Gestão de assinaturas de transações (integração de carteira de hardware)
testes: testes de integração e testes de estado, verificando a compatibilidade do protocolo
trie & triedb: implementação da Árvore Merkle Patricia (Merkle Patricia Trie) para armazenar e gerenciar de forma eficiente o estado das contas e o armazenamento de contratos.
04\Divisão do módulo da camada de execução
O acesso externo ao nó Geth pode ser feito de duas formas: uma é através do RPC, e a outra é através do Console. O RPC é adequado para ser disponibilizado a usuários externos, enquanto o Console é apropriado para os administradores do nó. Mas, quer seja através do RPC ou do Console, utiliza-se capacidades já encapsuladas internamente, que são construídas de forma hierárquica.
A camada mais externa é a capacidade da API para nós de acesso externos, API do mecanismo para comunicação entre a camada de execução e a camada de consenso, API Eth para usuários externos ou programas para enviar transações e obter informações de bloco, API de rede para obter o estado da rede p2p e assim por diante. Por exemplo, se um usuário enviar uma transação por meio da API, a transação acabará sendo enviada ao pool de transações e gerenciada por meio do pool de transações.
Na próxima camada da API está a implementação das funcionalidades principais, incluindo o pool de transações, o empacotamento de transações, a geração de blocos, a sincronização de blocos e estados, entre outros. Essas funcionalidades, por sua vez, precisam depender de capacidades mais fundamentais, como a sincronização do pool de transações, blocos e estados que requerem a capacidade da rede p2p. A geração de blocos e a sincronização de blocos provenientes de outros nós precisam ser validadas antes de serem escritas na base de dados local, o que depende das capacidades do EVM e do armazenamento de dados.
Estruturas de dados centrais da camada de execução
Ethereum
A estrutura Ethereum em eth/backend.go é uma abstração de todo o protocolo Ethereum, incluindo basicamente os principais componentes do Ethereum, mas a EVM é uma exceção, pois é instanciada a cada processamento de transação, não necessitando ser inicializada com todo o nó. Abaixo, a Ethereum refere-se a esta estrutura:
type Ethereum struct { // Configuração Ethereum, incluindo chain config *ethconfig. Config // Pool de transações, após a transação do usuário ser enviada, vá para o pool de transações txPool *txpool. TxPool // Usado para rastrear e gerenciar transações locais localTxTracker *locals. TxTracker // Blockchain estrutura blockchain *core. BlockChain // é o componente central da camada de rede do nó Ethereum, responsável por lidar com toda a comunicação com outros nós, incluindo sincronização de blocos, transmissão de transações e recebimento, bem como gerenciar o manipulador de conexão de nó de mesmo nível // responsável pela descoberta de nós e gerenciamento de origem de nós discmix *enode. FairMix // Responsável pelo armazenamento persistente de blockchain data chainDb ethdb. Base de dados // Responsável pela publicação e subscrição de vários eventos internos ao eventMux *event. TypeMux // Consenso sobre motores. Motor // Gerir contas de utilizador e chaves accountManager *accounts. Manager // Gerir filtros de registo e filtros de blocosMapas *filtermaps. FilterMaps // Canal para desligar filterMaps com segurança, garantindo que os recursos são limpos corretamente quando os nós são desligados fecharFilterMaps chan chan struct{} // Fornecer suporte de back-end para API RPC APIBackend *EthAPIBackend // Em PoS, trabalhe com o mecanismo de consenso para validar o minerador de blocos *miner. Minerador // O preço de gás mais baixo aceite pelo nó é gasPrice *big. Int // Network ID networkID uint64 // Fornece serviços RPC relacionados com a rede, permitindo que o estado da rede seja consultado através de RPC netRPCService *ethapi. NetAPI // Gerencie conexões de rede P2P, manipule a descoberta de nós e o estabelecimento de conexões e forneça funções de transporte de rede subjacentes p2pServer *p2p. Servidor // Proteger o acesso simultâneo a campos mutáveis bloquear a sincronização. RWMutex // Rastreia se o nó está inativo normalmente e ajuda a restaurar o shutdownTracker após um desligamento anormal *shutdowncheck. ShutdownTracker }
Nó
Node in node/node.go é outra estrutura de dados central que atua como um contêiner para gerenciar e coordenar a operação de vários serviços. Na estrutura abaixo, é importante se concentrar no campo de ciclos de vida, que os ciclos de vida usam para gerenciar o ciclo de vida das funções internas. Por exemplo, a abstração do Ethereum acima precisa depender do Node para iniciar e registrar nos ciclos de vida. Desta forma, as funções específicas podem ser separadas da abstração do nó, e a escalabilidade de toda a arquitetura precisa ser diferenciada, o que precisa ser distinguido do nó no devp2p.
type Node struct { eventmux *event. TypeMux config *Config // Gestor de conta, responsável pela gestão de carteiras e contas accman *accounts. Log do gerente. Logger keyDir string keyDirTemp bool dirLock *flock. Flock stop chan struct{} // servidor de instância de rede p2p *p2p. Sincronização startStopLock do servidor. Mutex // Rastrear estado do ciclo de vida do nó (inicializado, em execução, fechado) estado int lock sync. Mutex // Todos os back-ends, serviços e ciclos de vida de serviços auxiliares registados []Ciclo de vida // Lista de APIs atualmente disponíveis rpcAPIs []rpc. API // Diferentes métodos de acesso para RPC http *httpServer ws *httpServer httpAuth *httpServer wsAuth *httpServer ipc *ipcServer inprocHandler *rpc. Mapa de bancos de dados do servidor[*closeTrackingDB]struct{} }
Se olharmos para a camada de execução do Ethereum a partir de uma dimensão abstrata, o Ethereum como um computador mundial precisa incluir três partes: rede, computação e armazenamento. Assim, os componentes da camada de execução do Ethereum que correspondem a essas três partes são:
Rede: devp2p
Cálculo: EVM
Armazenar: ethdb
devp2p
A essência do Ethereum é ainda um sistema distribuído, onde cada nó se conecta a outros nós através de uma rede p2p. A implementação do protocolo de rede p2p no Ethereum é o devp2p.
O devp2p tem duas funcionalidades principais, uma é a descoberta de nós, permitindo que os nós estabeleçam contato com outros nós ao se conectarem à rede; a outra é o serviço de transmissão de dados, que permite a troca de dados após estabelecer contato com outros nós.
Na estrutura Node em p2p/enode/node.go representa um nó na rede p2p, onde os pares de chave-valor com informações detalhadas do nó são armazenados na estrutura enr.Record, incluindo informações de identidade (algoritmo de assinatura usado pela identidade do nó, chave pública), informações de rede (endereço IP, número da porta), informações de protocolo suportado (como suporte aos protocolos eth/68 e snap) e outras informações personalizadas. Essas informações são codificadas através de RLP, e a especificação específica está definida no eip-778:
type Node struct { // Nó registro, contém várias propriedades do nó r enr.Record // Identificador único do nó, comprimento de 32 bytes id ID // hostname Nome DNS do nó hostname string // Endereço IP do nó ip netip.Addr // Porta UDP udp uint16 // Porta TCP tcp uint16 }// enr.Recordtype Record struct { // Número de série seq uint64 // Assinatura signature []byte // Registro codificado em RLP raw []byte // Lista ordenada de todos os pares chave-valor pairs []pair }
A estrutura Table no p2p/discover/table.go é a estrutura de dados central da implementação do protocolo de descoberta de nós do devp2p, que implementa uma tabela hash distribuída semelhante à Kademlia, utilizada para manter e gerenciar informações sobre nós na rede.
printf("type Table struct { mutex sync. Mutex // Indexar buckets de nó conhecidos por distância [nBuckets]*bucket // bootstrap node nursery []*enode. Node rand reseedingRandom ips netutil. Tabela de revalidação DistinctNetSetRevalidação // Base de dados de nós conhecidos db *enode. DB net transport cfg Config log log. Logger // Processa periodicamente vários eventos na rede refreshReq chan chan struct{} revalResponseCh chan revalidationResponse addNodeCh chan addNodeOp addNodeHandled chan bool trackRequestCh chan trackRequestOp initDone chan struct{} closeReq chan struct{} closed chan struct{} // Adicionar e remover interfaces para nós nodeAddedHook func(*bucket, *tableNode) nodeRemovedHook func(*bucket, *tableNode)} mundo!" );
ETHDB
ethdb completa a abstração do armazenamento de dados do Ethereum, fornecendo uma interface de armazenamento unificada, onde a base de dados subjacente pode ser leveldb, pebble ou outra base de dados. Podem existir muitas extensões, desde que se mantenha a uniformidade a nível da interface.
Alguns dados (como dados de bloco) podem ser lidos e escritos diretamente no banco de dados subjacente através da interface ethdb, enquanto outras interfaces de armazenamento de dados são construídas sobre a base do ethdb. Por exemplo, uma grande parte dos dados no banco de dados é composta por dados de estado, que são organizados em uma estrutura MPT. Na implementação correspondente do Geth, isso é chamado de trie. Durante a operação do nó, os dados da trie geram muitos estados intermediários que não podem ser lidos e escritos diretamente com a ethdb, sendo necessário o triedb para gerenciar esses dados e estados intermediários, que por fim são persistidos através da ethdb.
A interface que define os recursos de leitura e gravação do banco de dados subjacente em ethdb/database.go não inclui uma implementação específica, que será implementada pelos próprios diferentes bancos de dados. Por exemplo, bancos de dados leveldb ou pebble. Duas camadas de interfaces de leitura/gravação de dados são definidas no banco de dados, entre as quais a interface KeyValueStore é usada para armazenar dados ativos e que mudam com frequência, como o último bloco, estado, etc. AncientStore é usado para processar dados históricos de blocos, que raramente mudam uma vez escritos.
// Interface de nível superior do banco de dados
type Database interface {
KeyValueStore AncientStore
}
// Interface de leitura e escrita de dados KV
type KeyValueStore interface {
KeyValueReader
KeyValueWriter
KeyValueStater
KeyValueRangeDeleter
Batcher
Iteratee
Compacter
io.Closer
}
// Interface para leitura e escrita de dados antigos
type AncientStore interface {
AncientReader
AncientWriter
AncientStater
io.Closer
}
EVM
EVM é a função de conversão de estado da máquina de estados do Ethereum, todas as atualizações de dados de estado só podem ser feitas através do EVM, a rede p2p pode receber informações de transações e blocos, essas informações, após serem processadas pelo EVM, se tornam parte do banco de dados de estado. O EVM oculta as diferenças de hardware subjacente, permitindo que os programas executem em diferentes EVMs de plataformas e ainda assim obtenham resultados consistentes. Esta é uma forma de design muito madura, a JVM na linguagem Java também é um design semelhante.
A estrutura EVM em core/vm/evm.go define a estrutura geral e as dependências do EVM, incluindo o contexto de execução, dependências de banco de dados de estado, etc.; O EVMInterpreter struct em core/vm/interpreter.go define a implementação do interpretador e é responsável pela execução do bytecode EVM; A estrutura do contrato em core/vm/contract.go encapsula os parâmetros específicos da chamada de contrato, incluindo o chamador, o código do contrato, a entrada, etc., e define todos os opcodes atuais em core/vm/opcodes.go:
EVMtype EVM struct { // Contexto de bloco, contendo informações relacionadas a blocos Contexto BlockContext // Contexto de transação, contendo informações relacionadas à transação TxContext // Banco de dados de estado, usado para acessar e modificar o estado da conta StateDB StateDB // Profundidade de chamada atual int // Parâmetro de configuração de cadeia chainConfig *params. ChainConfig chainRules params. Regras // EVM Config Config // Interpretador de bytecode *EVMInterpreter // Anular a execução do sinalizador abortar atômico. Bool callGasTemp uint64 // mapa pré-compilado[common. Endereço]PrecompiledContract jumpDests map[common. Hash]bitvec }type EVMInterpreter struct { // Aponte para a instância EVM à qual pertence evm *EVM // Opcode Jump Table table *JumpTable // Keccak256 hasher instance, share hasher crypto between opcodes. KeccakState // Keccak256 hasherBuf buffer de resultado de hash comum. Hash // Quer seja modo só de leitura, a modificação de estado não é permitida no modo só de leitura bool somente leitura // Os dados de retorno da última CALL são usados para reutilização subsequente returnData []byte }type Contract struct { // caller's address caller common. Endereço // Endereço do contrato endereço comum. Endereço jumpdests map[common. Análise de hash]bitvec bitvec // Código de bytecódigo de contrato []byte // Código hash CodeHash comum. Hash // Entrada de chamada []byte // Se deve implantar IsDeployment bool para o contrato // Se deve chamar IsSystemCall bool // Gás disponível uint64 // A quantidade de ETH anexada ao valor da chamada *uint256. Int }
Outros módulos implementados
A funcionalidade da camada de execução é alcançada através de uma abordagem em camadas, e outros módulos e funcionalidades são construídos com base nesses três componentes centrais. Aqui estão apresentados alguns dos módulos centrais.
Na eth/protocols, há a implementação dos subprotocolos de rede p2p do Ethereum atual. Existem os subprotocolos eth/68 e snap, que são construídos sobre o devp2p.
eth/68 é o protocolo central do Ethereum, o nome do protocolo é eth, 68 é o seu número da versão, e sobre a base deste protocolo foram implementadas funcionalidades como o pool de transações (TxPool), sincronização de blocos (Downloader) e sincronização de transações (Fetcher). O protocolo snap é utilizado para a rápida sincronização de blocos e dados de estado quando novos nós se juntam à rede, o que pode reduzir significativamente o tempo de inicialização de novos nós.
ethdb fornece a capacidade de leitura e escrita para o banco de dados subjacente. Devido à complexidade de muitas estruturas de dados no protocolo Ethereum, não é possível gerenciar esses dados diretamente através do ethdb. Portanto, foram implementados o rawdb e o statedb sobre o ethdb para gerenciar, respetivamente, os dados de blocos e de estado.
O EVM perpassa todos os processos principais, seja na construção de blocos ou na validação de blocos, é necessário usar o EVM para executar transações.
05\Geth Nó processo de inicialização
O início do Geth é dividido em duas fases, a primeira fase inicializa os componentes e recursos necessários para iniciar o nó, a segunda fase inicia oficialmente o nó e, em seguida, oferece serviços externamente.
Nó inicialização
Ao iniciar um nó geth, o seguinte código estará envolvido:
A inicialização de cada módulo é a seguinte:
cmd/geth/main.go: entrada para o nó geth
cmd/geth/config.go（makeFullNode）：Carregar configurações, inicializar Nó
nó/node.go: inicializar o contêiner central do nó Ethereum
eth/ethconfig/config.go: Inicializar a instância do motor de consenso (o motor de consenso aqui não participa realmente do consenso, apenas valida os resultados da camada de consenso e processa os pedidos de retirada dos validadores)
core/blockchain.go: inicializar blockchain
core/filterMaps.go: inicializar filtermaps
core/txpool/blobpool/blobpool.go: inicializar o pool de transações blob
core/txpool/legacypool/legacypool.go: inicializar o pool de transações comum
cord/txpool/locals/tx_tracker.go: Rastreio de transações local (é necessário configurar para ativar o rastreio de transações local, transações locais serão processadas com prioridade mais alta)
eth/handler.go: Inicializar a instância do Handler do protocolo
miner/miner.go: módulo de empacotamento de transações instanciadas (antigo módulo de mineração)
eth/api_backend.go: Instanciar serviço RPC
eth/gasprice/gasprice.go: Instanciar o serviço de consulta de preços de gás
internal/ethapi/api.go: Instanciar a API RPC da rede P2P
nó/node.go(RegistarAPIs)： registar API RPC
nó/node.go(RegistarProtocolos)：registar p2p dos Protocolos
nó/node.go(RegistrarCicloDeVida)：registrar o ciclo de vida dos vários componentes
cmd/utils/flags.go(RegistrarFiltroAPI)：registar API RPC de Filtro
cmd/utils/flags.go(RegistrarServiçoGraphQL)：Registrar API RPC GraphQL (se configurado)
cmd/utils/flags.go(Registrar serviço EthStats): Regista a API RPC do EthStats (se configurada).
eth/catalyst/api.go: Registar API do Motor
A inicialização do nó será concluída na função makeFullNode em cmd/geth/config.go, com foco na inicialização dos seguintes três módulos.
Na primeira etapa, será inicializada a estrutura Node no arquivo node.go, que é o contêiner de todo o nó, todas as funcionalidades precisam ser executadas dentro deste contêiner. Na segunda etapa, será inicializada a estrutura Ethereum, que inclui a implementação de várias funcionalidades principais do Ethereum, o Ethereum também precisa ser registrado no Nó. A terceira etapa é registrar a API Engine no Nó.
A inicialização do Nó consiste em criar uma instância de Nó, e depois inicializar o servidor p2p, a gestão de contas e as portas de protocolo http expostas externamente.
A inicialização do Ethereum é muito mais complexa, a maioria das funcionalidades principais é inicializada aqui. Primeiro, o ethdb será inicializado e a configuração da cadeia será carregada do armazenamento, em seguida, o mecanismo de consenso será criado, onde o mecanismo de consenso não executará operações de consenso, mas apenas verificará os resultados retornados pela camada de consenso. Se houver um pedido de retirada na camada de consenso, a operação de retirada real também será concluída aqui. Em seguida, a estrutura da Blockchain e o pool de transações serão inicializados.
Depois de completar tudo isso, o handler será inicializado. O handler é o ponto de entrada para o processamento de todos os pedidos de rede p2p, incluindo sincronização de transações, download de blocos, etc., sendo um componente chave para a execução descentralizada do Ethereum. Após completar esses passos, alguns subprotocolos implementados sobre o devp2p, como eth/68, snap, entre outros, serão registrados no contêiner Node, e por fim, o Ethereum será registrado como um ciclo de vida no contêiner Node, completando a inicialização do Ethereum.
Por fim, a inicialização da Engine API é relativamente simples, bastando registrar a Engine API no Nó. Com isso, a inicialização do nó está completamente concluída.
Nó de启动
Após a conclusão da inicialização do nó, é necessário iniciar o nó. O processo de inicialização do nó é relativamente simples, basta iniciar todos os serviços RPC já registrados e o Lifecycle, e então todo o nó poderá fornecer serviços ao exterior.
06\resumo
Antes de entender a implementação da camada de execução do Ethereum, é necessário ter uma visão geral do Ethereum. O Ethereum pode ser visto como uma máquina de estados impulsionada por transações, onde a camada de execução é responsável pela execução das transações e pela alteração do estado, enquanto a camada de consenso é responsável por impulsionar a operação da camada de execução, incluindo a produção de blocos pela camada de execução, a determinação da ordem das transações, a votação dos blocos e a obtenção de finalização dos blocos. Como esta máquina de estados é descentralizada, é necessário comunicar-se com outros nós através de uma rede p2p para manter a consistência dos dados de estado.
A camada de execução não é responsável por decidir a ordem das transações, apenas se encarrega de executar as transações e registrar as mudanças de estado após a execução das mesmas. Aqui, o registro tem duas formas, uma é registrar todas as mudanças de estado em forma de blocos, a outra é registrar o estado atual na base de dados. Ao mesmo tempo, a camada de execução também é a entrada para as transações, armazenando as transações que ainda não foram empacotadas em blocos na pool de transações. Se outros nós precisarem obter blocos, estados e dados de transações, a camada de execução enviará essas informações através da rede p2p.
Para a camada de execução, existem três módulos centrais: computação, armazenamento e rede. A computação corresponde à implementação do EVM, o armazenamento corresponde à implementação do ethdb, e a rede corresponde à implementação do devp2p. Com essa compreensão geral, é possível aprofundar-se em cada um dos submódulos, sem se perder nos detalhes específicos.
O conteúdo serve apenas de referência e não constitui uma solicitação ou oferta. Não é prestado qualquer aconselhamento em matéria de investimento, fiscal ou jurídica. Consulte a Declaração de exoneração de responsabilidade para obter mais informações sobre os riscos.
Cliente principal do Ethereum: Arquitetura geral do Geth
Este artigo é o primeiro de uma série sobre o código fonte do Geth. Através desta série, iremos construir uma estrutura para estudar a implementação do Geth, permitindo que os desenvolvedores aprofundem sua pesquisa nas partes que mais lhes interessam. Esta série contém um total de seis artigos. No primeiro artigo, iremos explorar a arquitetura de design do cliente de camada de execução Geth e o processo de inicialização do nó Geth. O código do Geth é atualizado rapidamente, e o código que veremos posteriormente pode ser um pouco diferente, mas o design geral permanece bastante consistente, e o novo código pode ser lido com a mesma lógica.
01\Cliente Ethereum
Antes da atualização The Merge, o Ethereum tinha apenas um cliente, que era responsável pela execução das transações e também pela consensualidade da blockchain, garantindo que novos blocos fossem gerados em uma certa ordem. Após a atualização The Merge, os clientes do Ethereum foram divididos em camada de execução e camada de consenso, onde a camada de execução é responsável pela execução das transações, manutenção do estado e dos dados, enquanto a camada de consenso é responsável pela implementação da funcionalidade de consenso. As camadas de execução e consenso comunicam-se através de API. Cada camada possui suas próprias especificações, e os clientes podem ser implementados em diferentes linguagens, desde que atendam às especificações correspondentes, sendo que Geth é uma das implementações do cliente da camada de execução. Atualmente, as implementações principais de clientes de camada de execução e camada de consenso são as seguintes:
Camada de Execução
Camada de Consenso
02\Introdução à camada de execução
Pode-se considerar a camada de execução do Ethereum como uma máquina de estados impulsionada por transações, cuja função básica é atualizar os dados de estado através da execução de transações pelo EVM. Além da execução de transações, também há funções como armazenar e validar blocos e dados de estado, operar uma rede p2p e manter um pool de transações.
As transações são geradas pelos usuários (ou programas) de acordo com o formato definido pelas especificações da camada de execução do Ethereum. Os usuários precisam assinar as transações e, se a transação for legítima (Nonce contínuo, assinatura correta, taxa de gas suficiente, lógica de negócios correta), então a transação será finalmente executada pela EVM, atualizando assim o estado da rede Ethereum. O estado aqui refere-se ao conjunto de estruturas de dados, dados e banco de dados, incluindo endereços de contas externas, endereços de contratos, saldo de endereços, bem como códigos e dados.
A camada de execução é responsável por executar transações e manter o estado após a execução das transações, enquanto a camada de consenso é responsável por selecionar quais transações executar. O EVM é a função de transformação de estado dentro desta máquina de estado, e a entrada da função pode vir de vários lugares, podendo ser fornecida pelas informações do bloco mais recente da camada de consenso ou podendo vir de blocos baixados da rede p2p.
A camada de consenso e a camada de execução comunicam-se através da API Engine, que é a única forma de comunicação entre a camada de execução e a camada de consenso. Se a camada de consenso obtiver o direito de criar blocos, ela usará a API Engine para permitir que a camada de execução produza novos blocos; se não obtiver o direito de criar blocos, ela sincronizará os blocos mais recentes para que a camada de execução possa verificar e executar, mantendo assim o consenso com toda a rede Ethereum.
A camada de execução pode ser logicamente dividida em 6 partes:
A figura abaixo mostra os principais processos da camada de execução e as funções de cada parte:
Para a camada de execução (aqui apenas discutimos o Nó Completo), existem três processos chave:
03\Estrutura de código fonte
A estrutura de código do go-ethereum é enorme, mas muito do código é código auxiliar e testes de unidade, e ao olhar para o código-fonte Geth, você só precisa se concentrar na implementação principal do protocolo, e os módulos individuais funcionam da seguinte maneira. Você precisa se concentrar em módulos como core, eth, ethdb, node, p2p, rlp, trie & triedb, etc.:
04\Divisão do módulo da camada de execução
O acesso externo ao nó Geth pode ser feito de duas formas: uma é através do RPC, e a outra é através do Console. O RPC é adequado para ser disponibilizado a usuários externos, enquanto o Console é apropriado para os administradores do nó. Mas, quer seja através do RPC ou do Console, utiliza-se capacidades já encapsuladas internamente, que são construídas de forma hierárquica.
A camada mais externa é a capacidade da API para nós de acesso externos, API do mecanismo para comunicação entre a camada de execução e a camada de consenso, API Eth para usuários externos ou programas para enviar transações e obter informações de bloco, API de rede para obter o estado da rede p2p e assim por diante. Por exemplo, se um usuário enviar uma transação por meio da API, a transação acabará sendo enviada ao pool de transações e gerenciada por meio do pool de transações.
Na próxima camada da API está a implementação das funcionalidades principais, incluindo o pool de transações, o empacotamento de transações, a geração de blocos, a sincronização de blocos e estados, entre outros. Essas funcionalidades, por sua vez, precisam depender de capacidades mais fundamentais, como a sincronização do pool de transações, blocos e estados que requerem a capacidade da rede p2p. A geração de blocos e a sincronização de blocos provenientes de outros nós precisam ser validadas antes de serem escritas na base de dados local, o que depende das capacidades do EVM e do armazenamento de dados.
Estruturas de dados centrais da camada de execução
Ethereum
A estrutura Ethereum em eth/backend.go é uma abstração de todo o protocolo Ethereum, incluindo basicamente os principais componentes do Ethereum, mas a EVM é uma exceção, pois é instanciada a cada processamento de transação, não necessitando ser inicializada com todo o nó. Abaixo, a Ethereum refere-se a esta estrutura:
type Ethereum struct { // Configuração Ethereum, incluindo chain config *ethconfig. Config // Pool de transações, após a transação do usuário ser enviada, vá para o pool de transações txPool *txpool. TxPool // Usado para rastrear e gerenciar transações locais localTxTracker *locals. TxTracker // Blockchain estrutura blockchain *core. BlockChain // é o componente central da camada de rede do nó Ethereum, responsável por lidar com toda a comunicação com outros nós, incluindo sincronização de blocos, transmissão de transações e recebimento, bem como gerenciar o manipulador de conexão de nó de mesmo nível // responsável pela descoberta de nós e gerenciamento de origem de nós discmix *enode. FairMix // Responsável pelo armazenamento persistente de blockchain data chainDb ethdb. Base de dados // Responsável pela publicação e subscrição de vários eventos internos ao eventMux *event. TypeMux // Consenso sobre motores. Motor // Gerir contas de utilizador e chaves accountManager *accounts. Manager // Gerir filtros de registo e filtros de blocosMapas *filtermaps. FilterMaps // Canal para desligar filterMaps com segurança, garantindo que os recursos são limpos corretamente quando os nós são desligados fecharFilterMaps chan chan struct{} // Fornecer suporte de back-end para API RPC APIBackend *EthAPIBackend // Em PoS, trabalhe com o mecanismo de consenso para validar o minerador de blocos *miner. Minerador // O preço de gás mais baixo aceite pelo nó é gasPrice *big. Int // Network ID networkID uint64 // Fornece serviços RPC relacionados com a rede, permitindo que o estado da rede seja consultado através de RPC netRPCService *ethapi. NetAPI // Gerencie conexões de rede P2P, manipule a descoberta de nós e o estabelecimento de conexões e forneça funções de transporte de rede subjacentes p2pServer *p2p. Servidor // Proteger o acesso simultâneo a campos mutáveis bloquear a sincronização. RWMutex // Rastreia se o nó está inativo normalmente e ajuda a restaurar o shutdownTracker após um desligamento anormal *shutdowncheck. ShutdownTracker }
Nó
Node in node/node.go é outra estrutura de dados central que atua como um contêiner para gerenciar e coordenar a operação de vários serviços. Na estrutura abaixo, é importante se concentrar no campo de ciclos de vida, que os ciclos de vida usam para gerenciar o ciclo de vida das funções internas. Por exemplo, a abstração do Ethereum acima precisa depender do Node para iniciar e registrar nos ciclos de vida. Desta forma, as funções específicas podem ser separadas da abstração do nó, e a escalabilidade de toda a arquitetura precisa ser diferenciada, o que precisa ser distinguido do nó no devp2p.
type Node struct { eventmux *event. TypeMux config *Config // Gestor de conta, responsável pela gestão de carteiras e contas accman *accounts. Log do gerente. Logger keyDir string keyDirTemp bool dirLock *flock. Flock stop chan struct{} // servidor de instância de rede p2p *p2p. Sincronização startStopLock do servidor. Mutex // Rastrear estado do ciclo de vida do nó (inicializado, em execução, fechado) estado int lock sync. Mutex // Todos os back-ends, serviços e ciclos de vida de serviços auxiliares registados []Ciclo de vida // Lista de APIs atualmente disponíveis rpcAPIs []rpc. API // Diferentes métodos de acesso para RPC http *httpServer ws *httpServer httpAuth *httpServer wsAuth *httpServer ipc *ipcServer inprocHandler *rpc. Mapa de bancos de dados do servidor[*closeTrackingDB]struct{} }
Se olharmos para a camada de execução do Ethereum a partir de uma dimensão abstrata, o Ethereum como um computador mundial precisa incluir três partes: rede, computação e armazenamento. Assim, os componentes da camada de execução do Ethereum que correspondem a essas três partes são:
devp2p
A essência do Ethereum é ainda um sistema distribuído, onde cada nó se conecta a outros nós através de uma rede p2p. A implementação do protocolo de rede p2p no Ethereum é o devp2p.
O devp2p tem duas funcionalidades principais, uma é a descoberta de nós, permitindo que os nós estabeleçam contato com outros nós ao se conectarem à rede; a outra é o serviço de transmissão de dados, que permite a troca de dados após estabelecer contato com outros nós.
Na estrutura Node em p2p/enode/node.go representa um nó na rede p2p, onde os pares de chave-valor com informações detalhadas do nó são armazenados na estrutura enr.Record, incluindo informações de identidade (algoritmo de assinatura usado pela identidade do nó, chave pública), informações de rede (endereço IP, número da porta), informações de protocolo suportado (como suporte aos protocolos eth/68 e snap) e outras informações personalizadas. Essas informações são codificadas através de RLP, e a especificação específica está definida no eip-778:
type Node struct { // Nó registro, contém várias propriedades do nó r enr.Record // Identificador único do nó, comprimento de 32 bytes id ID // hostname Nome DNS do nó hostname string // Endereço IP do nó ip netip.Addr // Porta UDP udp uint16 // Porta TCP tcp uint16 }// enr.Recordtype Record struct { // Número de série seq uint64 // Assinatura signature []byte // Registro codificado em RLP raw []byte // Lista ordenada de todos os pares chave-valor pairs []pair }
A estrutura Table no p2p/discover/table.go é a estrutura de dados central da implementação do protocolo de descoberta de nós do devp2p, que implementa uma tabela hash distribuída semelhante à Kademlia, utilizada para manter e gerenciar informações sobre nós na rede.
printf("type Table struct { mutex sync. Mutex // Indexar buckets de nó conhecidos por distância [nBuckets]*bucket // bootstrap node nursery []*enode. Node rand reseedingRandom ips netutil. Tabela de revalidação DistinctNetSetRevalidação // Base de dados de nós conhecidos db *enode. DB net transport cfg Config log log. Logger // Processa periodicamente vários eventos na rede refreshReq chan chan struct{} revalResponseCh chan revalidationResponse addNodeCh chan addNodeOp addNodeHandled chan bool trackRequestCh chan trackRequestOp initDone chan struct{} closeReq chan struct{} closed chan struct{} // Adicionar e remover interfaces para nós nodeAddedHook func(*bucket, *tableNode) nodeRemovedHook func(*bucket, *tableNode)} mundo!" );
ETHDB
ethdb completa a abstração do armazenamento de dados do Ethereum, fornecendo uma interface de armazenamento unificada, onde a base de dados subjacente pode ser leveldb, pebble ou outra base de dados. Podem existir muitas extensões, desde que se mantenha a uniformidade a nível da interface.
Alguns dados (como dados de bloco) podem ser lidos e escritos diretamente no banco de dados subjacente através da interface ethdb, enquanto outras interfaces de armazenamento de dados são construídas sobre a base do ethdb. Por exemplo, uma grande parte dos dados no banco de dados é composta por dados de estado, que são organizados em uma estrutura MPT. Na implementação correspondente do Geth, isso é chamado de trie. Durante a operação do nó, os dados da trie geram muitos estados intermediários que não podem ser lidos e escritos diretamente com a ethdb, sendo necessário o triedb para gerenciar esses dados e estados intermediários, que por fim são persistidos através da ethdb.
A interface que define os recursos de leitura e gravação do banco de dados subjacente em ethdb/database.go não inclui uma implementação específica, que será implementada pelos próprios diferentes bancos de dados. Por exemplo, bancos de dados leveldb ou pebble. Duas camadas de interfaces de leitura/gravação de dados são definidas no banco de dados, entre as quais a interface KeyValueStore é usada para armazenar dados ativos e que mudam com frequência, como o último bloco, estado, etc. AncientStore é usado para processar dados históricos de blocos, que raramente mudam uma vez escritos.
// Interface de nível superior do banco de dados type Database interface { KeyValueStore AncientStore }
// Interface de leitura e escrita de dados KV type KeyValueStore interface { KeyValueReader KeyValueWriter KeyValueStater KeyValueRangeDeleter Batcher Iteratee Compacter io.Closer }
// Interface para leitura e escrita de dados antigos type AncientStore interface { AncientReader AncientWriter AncientStater io.Closer }
EVM
EVM é a função de conversão de estado da máquina de estados do Ethereum, todas as atualizações de dados de estado só podem ser feitas através do EVM, a rede p2p pode receber informações de transações e blocos, essas informações, após serem processadas pelo EVM, se tornam parte do banco de dados de estado. O EVM oculta as diferenças de hardware subjacente, permitindo que os programas executem em diferentes EVMs de plataformas e ainda assim obtenham resultados consistentes. Esta é uma forma de design muito madura, a JVM na linguagem Java também é um design semelhante.
A estrutura EVM em core/vm/evm.go define a estrutura geral e as dependências do EVM, incluindo o contexto de execução, dependências de banco de dados de estado, etc.; O EVMInterpreter struct em core/vm/interpreter.go define a implementação do interpretador e é responsável pela execução do bytecode EVM; A estrutura do contrato em core/vm/contract.go encapsula os parâmetros específicos da chamada de contrato, incluindo o chamador, o código do contrato, a entrada, etc., e define todos os opcodes atuais em core/vm/opcodes.go:
EVMtype EVM struct { // Contexto de bloco, contendo informações relacionadas a blocos Contexto BlockContext // Contexto de transação, contendo informações relacionadas à transação TxContext // Banco de dados de estado, usado para acessar e modificar o estado da conta StateDB StateDB // Profundidade de chamada atual int // Parâmetro de configuração de cadeia chainConfig *params. ChainConfig chainRules params. Regras // EVM Config Config // Interpretador de bytecode *EVMInterpreter // Anular a execução do sinalizador abortar atômico. Bool callGasTemp uint64 // mapa pré-compilado[common. Endereço]PrecompiledContract jumpDests map[common. Hash]bitvec }type EVMInterpreter struct { // Aponte para a instância EVM à qual pertence evm *EVM // Opcode Jump Table table *JumpTable // Keccak256 hasher instance, share hasher crypto between opcodes. KeccakState // Keccak256 hasherBuf buffer de resultado de hash comum. Hash // Quer seja modo só de leitura, a modificação de estado não é permitida no modo só de leitura bool somente leitura // Os dados de retorno da última CALL são usados para reutilização subsequente returnData []byte }type Contract struct { // caller's address caller common. Endereço // Endereço do contrato endereço comum. Endereço jumpdests map[common. Análise de hash]bitvec bitvec // Código de bytecódigo de contrato []byte // Código hash CodeHash comum. Hash // Entrada de chamada []byte // Se deve implantar IsDeployment bool para o contrato // Se deve chamar IsSystemCall bool // Gás disponível uint64 // A quantidade de ETH anexada ao valor da chamada *uint256. Int }
Outros módulos implementados
A funcionalidade da camada de execução é alcançada através de uma abordagem em camadas, e outros módulos e funcionalidades são construídos com base nesses três componentes centrais. Aqui estão apresentados alguns dos módulos centrais.
Na eth/protocols, há a implementação dos subprotocolos de rede p2p do Ethereum atual. Existem os subprotocolos eth/68 e snap, que são construídos sobre o devp2p.
eth/68 é o protocolo central do Ethereum, o nome do protocolo é eth, 68 é o seu número da versão, e sobre a base deste protocolo foram implementadas funcionalidades como o pool de transações (TxPool), sincronização de blocos (Downloader) e sincronização de transações (Fetcher). O protocolo snap é utilizado para a rápida sincronização de blocos e dados de estado quando novos nós se juntam à rede, o que pode reduzir significativamente o tempo de inicialização de novos nós.
ethdb fornece a capacidade de leitura e escrita para o banco de dados subjacente. Devido à complexidade de muitas estruturas de dados no protocolo Ethereum, não é possível gerenciar esses dados diretamente através do ethdb. Portanto, foram implementados o rawdb e o statedb sobre o ethdb para gerenciar, respetivamente, os dados de blocos e de estado.
O EVM perpassa todos os processos principais, seja na construção de blocos ou na validação de blocos, é necessário usar o EVM para executar transações.
05\Geth Nó processo de inicialização
O início do Geth é dividido em duas fases, a primeira fase inicializa os componentes e recursos necessários para iniciar o nó, a segunda fase inicia oficialmente o nó e, em seguida, oferece serviços externamente.
Nó inicialização
Ao iniciar um nó geth, o seguinte código estará envolvido:
A inicialização de cada módulo é a seguinte:
A inicialização do nó será concluída na função makeFullNode em cmd/geth/config.go, com foco na inicialização dos seguintes três módulos.
Na primeira etapa, será inicializada a estrutura Node no arquivo node.go, que é o contêiner de todo o nó, todas as funcionalidades precisam ser executadas dentro deste contêiner. Na segunda etapa, será inicializada a estrutura Ethereum, que inclui a implementação de várias funcionalidades principais do Ethereum, o Ethereum também precisa ser registrado no Nó. A terceira etapa é registrar a API Engine no Nó.
A inicialização do Nó consiste em criar uma instância de Nó, e depois inicializar o servidor p2p, a gestão de contas e as portas de protocolo http expostas externamente.
A inicialização do Ethereum é muito mais complexa, a maioria das funcionalidades principais é inicializada aqui. Primeiro, o ethdb será inicializado e a configuração da cadeia será carregada do armazenamento, em seguida, o mecanismo de consenso será criado, onde o mecanismo de consenso não executará operações de consenso, mas apenas verificará os resultados retornados pela camada de consenso. Se houver um pedido de retirada na camada de consenso, a operação de retirada real também será concluída aqui. Em seguida, a estrutura da Blockchain e o pool de transações serão inicializados.
Depois de completar tudo isso, o handler será inicializado. O handler é o ponto de entrada para o processamento de todos os pedidos de rede p2p, incluindo sincronização de transações, download de blocos, etc., sendo um componente chave para a execução descentralizada do Ethereum. Após completar esses passos, alguns subprotocolos implementados sobre o devp2p, como eth/68, snap, entre outros, serão registrados no contêiner Node, e por fim, o Ethereum será registrado como um ciclo de vida no contêiner Node, completando a inicialização do Ethereum.
Por fim, a inicialização da Engine API é relativamente simples, bastando registrar a Engine API no Nó. Com isso, a inicialização do nó está completamente concluída.
Nó de启动
Após a conclusão da inicialização do nó, é necessário iniciar o nó. O processo de inicialização do nó é relativamente simples, basta iniciar todos os serviços RPC já registrados e o Lifecycle, e então todo o nó poderá fornecer serviços ao exterior.
06\resumo
Antes de entender a implementação da camada de execução do Ethereum, é necessário ter uma visão geral do Ethereum. O Ethereum pode ser visto como uma máquina de estados impulsionada por transações, onde a camada de execução é responsável pela execução das transações e pela alteração do estado, enquanto a camada de consenso é responsável por impulsionar a operação da camada de execução, incluindo a produção de blocos pela camada de execução, a determinação da ordem das transações, a votação dos blocos e a obtenção de finalização dos blocos. Como esta máquina de estados é descentralizada, é necessário comunicar-se com outros nós através de uma rede p2p para manter a consistência dos dados de estado.
A camada de execução não é responsável por decidir a ordem das transações, apenas se encarrega de executar as transações e registrar as mudanças de estado após a execução das mesmas. Aqui, o registro tem duas formas, uma é registrar todas as mudanças de estado em forma de blocos, a outra é registrar o estado atual na base de dados. Ao mesmo tempo, a camada de execução também é a entrada para as transações, armazenando as transações que ainda não foram empacotadas em blocos na pool de transações. Se outros nós precisarem obter blocos, estados e dados de transações, a camada de execução enviará essas informações através da rede p2p.
Para a camada de execução, existem três módulos centrais: computação, armazenamento e rede. A computação corresponde à implementação do EVM, o armazenamento corresponde à implementação do ethdb, e a rede corresponde à implementação do devp2p. Com essa compreensão geral, é possível aprofundar-se em cada um dos submódulos, sem se perder nos detalhes específicos.
07\Ref
[1]
[2]
[3]
[4]
[5]
[6]
·FIM·
Conteúdo | Ray
Edição & Layout | Huanhuan
Design | Daisy