Este artículo es el primero de una serie sobre el código fuente de Geth. A través de esta serie, construiremos un marco para investigar la implementación de Geth, donde los desarrolladores pueden profundizar en las partes que les interesen. Esta serie consta de seis artículos, y en el primer artículo se estudiará la arquitectura de diseño del cliente de capa de ejecución Geth y el proceso de inicio del nodo Geth. La velocidad de actualización del código de Geth es muy rápida, por lo que el código que se verá más adelante puede diferir, pero el diseño general es bastante consistente, y el nuevo código también se puede leer con el mismo enfoque.
01\Cliente de Ethereum
Antes de la actualización The Merge, Ethereum solo tenía un cliente, que era responsable de la ejecución de transacciones y también del consenso de la blockchain, asegurando que se generaran nuevos bloques en un orden determinado. Después de la actualización The Merge, el cliente de Ethereum se dividió en una capa de ejecución y una capa de consenso. La capa de ejecución se encarga de la ejecución de transacciones, el mantenimiento del estado y los datos, mientras que la capa de consenso se encarga de la implementación de las funciones de consenso. La capa de ejecución y la capa de consenso se comunican a través de API. Cada capa tiene sus propias especificaciones, y los clientes pueden implementarse en diferentes lenguajes, pero deben cumplir con las especificaciones correspondientes, siendo Geth una de las implementaciones del cliente de la capa de ejecución. Las implementaciones actuales más comunes de clientes de la capa de ejecución y de la capa de consenso son las siguientes:
Capa de Ejecución
Geth: Mantenido por un equipo financiado directamente por la Fundación Ethereum, desarrollado en lenguaje Go, es reconocido como el cliente más estable y probado.
Nethermind: desarrollado y mantenido por el equipo de Nethermind, desarrollado en el lenguaje C#, recibió financiamiento temprano de la Fundación Ethereum y la comunidad de Gitcoin.
Besu: originalmente desarrollado por el equipo PegaSys de ConsenSys, ahora es un proyecto de la comunidad Hyperledger, desarrollado en lenguaje Java.
Erigon: desarrollado y mantenido por el equipo de Erigon, financiado por la Fundación Ethereum y BNB Chain. Se bifurcó de Geth en 2017 con el objetivo de mejorar la velocidad de sincronización y la eficiencia del disco.
Reth: desarrollado bajo la dirección de Paradigm, el lenguaje de desarrollo es Rust, enfatiza la modularidad y alto rendimiento, actualmente está casi maduro y puede ser utilizado en entornos de producción.
Capa de consenso
Prysm: mantenido por Prysmatic Labs, es uno de los primeros clientes de la capa de consenso de Ethereum, desarrollado en Go, enfocado en la usabilidad y la seguridad, y fue financiado en sus inicios por la Fundación Ethereum.
Lighthouse: mantenido por el equipo de Sigma Prime, desarrollado en el lenguaje Rust, enfocado en alto rendimiento y seguridad de nivel empresarial, adecuado para escenarios de alta carga.
Teku: Desarrollado por el equipo PegaSys de ConsenSys, posteriormente se convirtió en parte de la comunidad Hyperledger Besu, desarrollado en lenguaje Java.
Nimbus: desarrollado y mantenido por el equipo de Status Network, programado en el lenguaje Nim, optimizado para dispositivos con recursos limitados (como teléfonos móviles y dispositivos IoT), con el objetivo de lograr un funcionamiento ligero en sistemas embebidos.
02\Introducción a la capa de ejecución
Se puede considerar la capa de ejecución de Ethereum como una máquina de estados impulsada por transacciones. La función más básica de la capa de ejecución es actualizar los datos de estado mediante la ejecución de transacciones a través de la EVM. Además de la ejecución de transacciones, también hay funciones como guardar y validar bloques y datos de estado, ejecutar una red p2p y mantener el grupo de transacciones.
La transacción es generada por el usuario (o programa) de acuerdo con el formato definido por la especificación de la capa de ejecución de Ethereum, el usuario debe firmar la transacción y, si la transacción es legítima (Nonce continuo, la firma es correcta, la tarifa de gas es suficiente y la lógica comercial es correcta), entonces la transacción eventualmente será ejecutada por la EVM, actualizando así el estado de la red Ethereum. El estado aquí se refiere a la recopilación de estructuras de datos, datos y bases de datos, incluidas las direcciones de cuentas externas, las direcciones de contratos, los saldos de direcciones y los códigos y datos.
La capa de ejecución es responsable de ejecutar transacciones y mantener el estado después de la ejecución de la transacción, mientras que la capa de consenso se encarga de seleccionar qué transacciones ejecutar. EVM es la función de transformación de estado dentro de esta máquina de estados, y la entrada de la función puede provenir de múltiples lugares, ya sea de la información del bloque más reciente proporcionada por la capa de consenso o de bloques descargados de la red p2p.
La capa de consenso y la capa de ejecución se comunican a través de la API de Engine, que es la única forma de comunicación entre la capa de ejecución y la capa de consenso. Si la capa de consenso obtiene el derecho a crear bloques, utilizará la API de Engine para permitir que la capa de ejecución produzca nuevos bloques; si no obtiene el derecho a crear bloques, sincronizará los bloques más recientes para que la capa de ejecución los valide y ejecute, manteniendo así el consenso con toda la red de Ethereum.
La capa de ejecución se puede dividir lógicamente en 6 partes:
EVM: Responsable de ejecutar transacciones, la ejecución de transacciones también es la única forma de modificar el estado.
Almacenamiento: encargado del almacenamiento de datos como el estado y los bloques.
Pool de transacciones: utilizado para las transacciones enviadas por los usuarios, almacenadas temporalmente y que se propagan entre diferentes nodos a través de la red p2p.
red p2p: utilizada para descubrir nodos, sincronizar transacciones, descargar bloques, etc.
Servicio RPC: proporciona la capacidad de acceder a nodos, como que los usuarios envían transacciones a los nodos, la interacción entre la capa de consenso y la capa de ejecución.
BlockChain: Responsable de gestionar los datos de la cadena de bloques de Ethereum
La imagen de abajo muestra los procesos clave de la capa de ejecución, así como las funciones de cada parte:
Para la capa de ejecución (aquí solo discutimos el Nodo Completo), hay tres procesos clave:
Si es un nodo que se ha unido recientemente a Ethereum, necesita sincronizar bloques y datos de estado desde otros nodos a través de la red p2p. Si es una sincronización completa (Full Sync), comenzará a descargar bloques uno por uno desde el bloque génesis, verificando los bloques y reconstruyendo la base de datos de estado a través de EVM. Si es una sincronización instantánea (Snap Sync), saltará todo el proceso de verificación de bloques y descargará directamente los datos de estado del último checkpoint y los datos de bloques posteriores.
Si se trata de un nodo que ya ha sido sincronizado al estado más reciente, continuará obteniendo los bloques de producción más recientes a través de la API de Engine desde la capa de consenso, y validará los bloques, luego ejecutará todas las transacciones en los bloques a través de EVM para actualizar la base de datos de estado, y escribirá los bloques en la cadena local.
Si el nodo que ha sincronizado hasta el estado más reciente ha obtenido el derecho de crear bloques en la capa de consenso, entonces a través de la API de Engine impulsará la capa de ejecución para producir el último bloque, la capa de ejecución obtiene las transacciones del grupo de transacciones y las ejecuta, luego las ensambla en un bloque y lo transmite a la capa de consenso a través de la API de Engine, siendo la capa de consenso la que difunde el bloque a la red p2p de la capa de consenso.
03\estructura del código
La estructura del código de go-ethereum es enorme, pero gran parte del código es código auxiliar y pruebas unitarias, y cuando se mira el código fuente Geth, sólo hay que centrarse en la implementación central del protocolo, y los módulos individuales funcionan de la siguiente manera. Debes centrarte en módulos como core, eth, ethdb, node, p2p, rlp, trie y triedb, etc.:
cuentas: gestionar cuentas de Ethereum, incluyendo la generación de pares de claves públicas y privadas, verificación de firmas, derivación de direcciones, etc.
beacon: Maneja la lógica de interacción con la cadena de señalización de Ethereum (Beacon Chain), admite la funcionalidad posterior a la fusión (The Merge) del consenso de prueba de participación (PoS).
build: scripts de construcción y configuración de compilación (como Dockerfile, soporte de compilación multiplataforma)
cmd: entrada de la herramienta de línea de comandos, que incluye varios subcomandos
común: herramientas generales, como procesamiento de bytes, conversión de formato de dirección, funciones matemáticas
consenso: Defina el motor de consenso, incluyendo el anterior Proof-of-Work (Ethash), Single-Node Proof-of-Stake (Clique), Beacon engine, etc
consola: proporciona una consola interactiva de JavaScript que permite a los usuarios interactuar directamente con el nodo de Ethereum a través de la línea de comandos (como llamar a la API de Web3, gestionar cuentas, consultar datos de la blockchain)
núcleo: lógica central de la blockchain, gestión del ciclo de vida de bloques/transacciones, máquina de estados, cálculo de Gas, etc.
crypto: Implementación de algoritmos de cifrado, incluyendo curvas elípticas (secp256k1), hash (Keccak-256), verificación de firmas
docs: Documentos (como especificaciones de diseño, documentación de API)
ETH: La implementación completa del protocolo de red Ethereum, incluidos los servicios de nodos, la sincronización de bloques (como la sincronización rápida, el modo de archivo), la transmisión de transacciones, etc
ethclient: biblioteca de cliente de Ethereum que implementa la interfaz JSON-RPC, permitiendo a los desarrolladores de Go interactuar con nodos de Ethereum (como consultar bloques, enviar transacciones, desplegar contratos).
ethdb: capa de abstracción de base de datos, que admite LevelDB, Pebble, bases de datos en memoria, etc., almacena datos de blockchain (bloques, estado, transacciones)
ethstats: Recoge y reporta el estado de funcionamiento del Nodo al servicio de estadísticas, utilizado para monitorear la salud de la red.
evento: implementar un mecanismo de suscripción y publicación de eventos, soportando la comunicación asíncrona entre módulos internos del nodo (como la llegada de nuevos bloques, actualización del pool de transacciones)
graphql: proporciona una interfaz GraphQL que admite consultas complejas (sustituyendo parte de la funcionalidad JSON-RPC)
interno: herramientas internas o código que limita el acceso externo
log: sistema de registros, soporta salida de registros por niveles y registro de logs de contexto
métrica: recolección de indicadores de rendimiento (soporte de Prometheus)
miner: lógica relacionada con la minería, generación de nuevos bloques y empaquetado de transacciones (en el escenario de PoW)
nodo: gestión de servicios de nodo, integración del inicio y la configuración de módulos p2p, RPC, base de datos, etc.
p2p: implementación de protocolo de red punto a punto, soporte para descubrimiento de nodos, transmisión de datos, comunicación encriptada
params: definir los parámetros de la red Ethereum (mainnet, testnet, configuración del bloque génesis)
RLP: Implementar RLP (Prefijo de longitud recursiva), un protocolo de serialización de datos dedicado a Ethereum, que se utiliza para codificar/decodificar estructuras de datos como bloques y transacciones
rpc: Implementar interfaces JSON-RPC e IPC para que los programas externos interactúen con el Nodo.
firmante：gestión de firmas de transacción (integración de billetera de hardware)
pruebas: pruebas de integración y pruebas de estado, verificar la compatibilidad del protocolo
trie & triedb: implementación del árbol de Merkle Patricia (Merkle Patricia Trie) para el almacenamiento y gestión eficiente del estado de cuentas y almacenamiento de contratos.
04\ División del módulo de la capa de ejecución
Hay dos formas de acceso externo a los nodos Geth, una a través de RPC y la otra a través de la consola. RPC es adecuado para usuarios externos y la consola es adecuada para administradores de nodos. Pero ya sea a través de RPC o de la consola, utiliza capacidades que ya están encapsuladas internamente, y esas capacidades se crean en capas.
La capa exterior es la capacidad de la API para acceder a los nodos desde el exterior, la Engine API se utiliza para la comunicación entre la capa de ejecución y la capa de consenso, la Eth API se utiliza para que los usuarios externos o programas envíen transacciones y obtengan información de bloques, y la Net API se utiliza para obtener el estado de la red p2p, entre otros. Por ejemplo, si un usuario envía una transacción a través de la API, esa transacción se enviará finalmente al grupo de transacciones y se gestionará a través de este, y si el usuario necesita obtener datos de un bloque, deberá invocar la capacidad de la base de datos para obtener el bloque correspondiente.
En la siguiente capa de la API, la implementación de las funciones principales incluye la agrupación de transacciones, el empaquetado de transacciones, la producción de bloques, la sincronización de bloques y estados, etc. Estas funciones deben basarse en capacidades de nivel inferior, como la capacidad de la red P2P para sincronizar grupos de transacciones, bloques y estados, y la generación de bloques y bloques sincronizados desde otros nodos debe validarse antes de que puedan escribirse en la base de datos local, que debe depender de las capacidades de EVM y almacenamiento de datos.
Estructura de datos central del nivel de ejecución
Ethereum
La estructura de Ethereum en eth/backend.go es la abstracción de todo el protocolo de Ethereum, que incluye principalmente los componentes principales de Ethereum, pero EVM es una excepción, ya que se instancia cada vez que se procesa una transacción, sin necesidad de inicializarse junto con todo el nodo. En el siguiente texto, Ethereum se refiere a esta estructura:
type Ethereum struct { // Configuración de Ethereum, incluida la configuración de cadena *ethconfig. Config // Grupo de transacciones, después de enviar la transacción del usuario, vaya al grupo de transacciones txPool *txpool. TxPool // Se utiliza para rastrear y administrar transacciones locales localTxTracker *locals. TxTracker // Estructura blockchain blockchain *core. BlockChain // es el componente central de la capa de red del nodo Ethereum, responsable de manejar toda la comunicación con otros nodos, incluida la sincronización de bloques, la transmisión y recepción de transacciones, así como la administración del controlador de conexión de nodos pares // responsable del descubrimiento de nodos y la administración de fuentes de nodos discmix *enode. FairMix // Responsable del almacenamiento persistente de la cadena de datos blockchainDb ethdb. Base de datos // Responsable de gestionar la publicación y suscripción de diversos eventos internos a eventMux *event. TypeMux // Consenso del motor. Motor // Administrar cuentas de usuario y claves accountManager *accounts. Administrador // Administrar filtros de registro y fragmentos filterMaps *filtermaps. FilterMaps // Canal para cerrar de forma segura filterMaps, asegurando que los recursos se limpien correctamente cuando los nodos se cierran closeFilterMaps chan chan struct{} // Proporcionar soporte de backend para RPC API APIBackend *EthAPIBackend // En PoS, trabaje con el motor de consenso para validar el minero de bloques *miner. Minero // El precio de gas más bajo aceptado por el nodo es gasPrice *big. Int // ID de red networkID uint64 // Proporciona servicios RPC relacionados con la red, lo que permite consultar el estado de la red a través de RPC netRPCService *ethapi. NetAPI // Administre las conexiones de red P2P, maneje el descubrimiento de nodos y el establecimiento de conexiones, y proporcione funciones de transporte de red subyacentes p2pServer *p2p. Servidor // Proteja el acceso simultáneo a la sincronización de bloqueo de campos mutables. RWMutex // Rastrea si el nodo está inactivo correctamente y ayuda a restaurar shutdownTracker después de un apagado anormal *shutdowncheck. ShutdownTracker }
Nodo
En node/node.go, Node es otra estructura de datos central que actúa como un contenedor, responsable de gestionar y coordinar la ejecución de varios servicios. En la estructura a continuación, es necesario prestar atención al campo lifecycles, ya que Lifecycle se utiliza para gestionar el ciclo de vida de las funciones internas. Por ejemplo, la abstracción de Ethereum mencionada anteriormente necesita depender de Node para iniciarse y registrarse en lifecycles. Esto permite separar las funciones específicas de la abstracción del nodo, mejorando la escalabilidad de toda la arquitectura, y este Node debe distinguirse del Node en devp2p.
type Node struct { eventmux *event. TypeMux config *Config // Gestor de cuentas, responsable de la gestión de carteras y cuentas accman *cuentas. Registro del administrador. Registrador keyDir string keyDirTemp bool dirLock *flock. Flock stop chan struct{} // servidor de instancia de red p2p *p2p. Sincronización del servidor startStopLock. Mutex // Seguimiento del estado del ciclo de vida del nodo (inicializado, en ejecución, cerrado) state int lock sync. Mutex // Todos los backends, servicios y servicios auxiliares registrados Ciclos de vida []Ciclo de vida // Lista de APIs disponibles actualmente rpcAPIs []rpc. API // Diferentes métodos de acceso para RPC http *httpServer ws *httpServer httpAuth *httpServer wsAuth *httpServer ipc *ipcServer inprocHandler *rpc. Mapa de bases de datos de servidor[*closeTrackingDB]struct{} }
Si miramos la capa de ejecución de Ethereum desde una dimensión abstracta, Ethereum, como computadora mundial, necesita incluir tres partes, red, computación y almacenamiento, entonces los componentes correspondientes a estas tres partes en la capa de ejecución de Ethereum son:
Red: devp2p
Cálculo: EVM
Almacenamiento: ethdb
devp2p
Ethereum es esencialmente un sistema distribuido, donde cada nodo se conecta a otros nodos a través de una red p2p. La implementación del protocolo de red p2p en Ethereum es devp2p.
devp2p tiene dos funciones principales, una es el descubrimiento de nodos, que permite a los nodos establecer contacto con otros nodos al conectarse a la red; la otra es el servicio de transmisión de datos, que permite intercambiar datos una vez que se ha establecido la conexión con otros nodos.
En la estructura Node en p2p/enode/node.go representa un nodo en la red p2p, donde los pares clave-valor que almacenan información detallada del nodo se encuentran en la estructura enr.Record, incluyendo información de identidad (algoritmo de firma utilizado para la identidad del nodo, clave pública), información de red (dirección IP, número de puerto), información de protocolos soportados (como eth/68 y protocolo snap) y otra información personalizada. Esta información se codifica de manera RLP, y la especificación concreta se define en eip-778:
type Node struct { // Nodo registro, contiene varias propiedades del nodo r enr.Record // Identificador único del nodo, longitud de 32 bytes id ID // nombre de host Nombre DNS del nodo hostname string // Dirección IP del nodo ip netip.Addr // Puerto UDP udp uint16 // Puerto TCP tcp uint16 }// enr.Recordtype Record struct { // Número de serie seq uint64 // Firma signature []byte // Registro codificado en RLP raw []byte // Lista ordenada de todos los pares clave-valor pairs []pair }
La estructura Table en p2p/discover/table.go es la estructura de datos central de la implementación del protocolo de descubrimiento de nodos de devp2p. Implementa una tabla hash distribuida similar a Kademlia, utilizada para mantener y gestionar la información de los nodos en la red.
printf("type Table struct { mutex sync.Mutex // Índice de nodos conocidos por distancia buckets [nBuckets]*bucket // Nodos guía nursery []*enode.Node rand reseedingRandom ips netutil.DistinctNetSet revalidation tableRevalidation // Base de datos de nodos conocidos db *enode.DB net transport cfg Config log log.Logger // Procesamiento periódico de varios eventos en la red 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{} // Interfaz para agregar y eliminar nodos nodeAddedHook func(*bucket, *tableNode) nodeRemovedHook func(*bucket, *tableNode)} world!");
ethdb
ethdb completa la abstracción del almacenamiento de datos de Ethereum, proporcionando una interfaz de almacenamiento unificada. La base de datos concreta subyacente puede ser leveldb, pebble u otra base de datos. Puede haber muchas extensiones, siempre que se mantenga la uniformidad a nivel de interfaz.
Algunos datos (como los datos de bloques) se pueden leer y escribir directamente en la base de datos subyacente a través de la interfaz ethdb, mientras que otras interfaces de almacenamiento de datos se basan en ethdb. Por ejemplo, una gran parte de los datos de la base de datos son datos de estado, estos datos se organizan en una estructura MPT, cuya implementación correspondiente en Geth es trie. Durante el funcionamiento del nodo, los datos de trie generan muchos estados intermedios, estos datos no se pueden leer y escribir directamente a través de ethdb, se necesita triedb para gestionar estos datos y estados intermedios, y finalmente se persisten a través de ethdb.
En ethdb/database.go se define la interfaz de capacidades de lectura y escritura de la base de datos subyacente, pero no incluye una implementación concreta, que será realizada por las propias bases de datos. Por ejemplo, la base de datos leveldb o pebble. En Database se definen dos capas de interfaces de lectura y escritura de datos, donde la interfaz KeyValueStore se utiliza para almacenar datos activos, que pueden cambiar con frecuencia, como los últimos bloques, estados, etc. AncientStore se utiliza para manejar datos de bloques históricos, que una vez escritos, rara vez cambian.
// Interfaz de nivel superior de la base de datos
type Database interface {
KeyValueStore AncientStore
}
// Interfaz de lectura y escritura de datos KV
type KeyValueStore interface {
KeyValueReader
KeyValueWriter
KeyValueStater
KeyValueRangeDeleter
Batcher
Iteratee
Compacter
io.Closer
}
// Interfaz de lectura y escritura de datos antiguos
type AncientStore interface {
AncientReader
AncientWriter
AncientStater
io.Closer
}
EVM
EVM es la función de transición de estado de la máquina de estado de Ethereum, todas las actualizaciones de datos de estado solo se pueden realizar a través de EVM. La red p2p puede recibir información de transacciones y bloques, que después de ser procesada por EVM se convierte en parte de la base de datos de estado. EVM oculta las diferencias de hardware subyacente, permitiendo que los programas se ejecuten en diferentes EVM de la plataforma y obtengan resultados consistentes. Este es un enfoque de diseño muy maduro, el JVM en el lenguaje Java también tiene un diseño similar.
La implementación de EVM tiene tres componentes principales: la estructura EVM en core/vm/evm.go define la estructura general y las dependencias de EVM, incluyendo el contexto de ejecución, la dependencia de la base de datos de estado, etc.; la estructura EVMInterpreter en core/vm/interpreter.go define la implementación del intérprete, que es responsable de ejecutar el bytecode de EVM; la estructura Contract en core/vm/contract.go encapsula los parámetros específicos de la llamada al contrato, incluyendo el llamador, el código del contrato, la entrada, etc., y en core/vm/opcodes.go se definen todos los códigos de operación actuales:
// EVMtype EVM struct { // Contexto de bloque, contiene información relacionada con el bloque Context BlockContext // Contexto de transacción, contiene información relacionada con la transacción TxContext // Base de datos de estado, utilizada para acceder y modificar el estado de la cuenta StateDB StateDB // Profundidad de llamada actual depth int // Parámetros de configuración de la cadena chainConfig *params.ChainConfig chainRules params.Rules // Configuración de EVM Config Config // Intérprete de bytecode interpreter *EVMInterpreter // Indicador de interrupción de ejecución abort atomic.Bool callGasTemp uint64 // Mapeo de contratos precompilados precompiles map[common.Address]PrecompiledContract jumpDests map[common.Hash]bitvec }type EVMInterpreter struct { // Puntero a la instancia de EVM correspondiente evm *EVM // Tabla de salto de código de operación table *JumpTable // Instancia del hasher Keccak256, compartido entre las operaciones hasher crypto.KeccakState // Buffer de resultados del hash Keccak256 hasherBuf common.Hash // Modo de solo lectura, no se permiten modificaciones de estado en modo solo lectura readOnly bool // Datos de retorno de la última llamada CALL, para reutilización posterior returnData []byte }type Contract struct { // Dirección del llamador caller common.Address // Dirección del contrato address common.Address jumpdests map[common.Hash]bitvec analysis bitvec // Bytecode del contrato Code []byte // Hash del código CodeHash common.Hash // Entrada de llamada Input []byte // ¿Es un despliegue de contrato? IsDeployment bool // ¿Es una llamada del sistema? IsSystemCall bool // Cantidad de gas disponible Gas uint64 // Cantidad de ETH adjunta a la llamada value *uint256.Int }
Implementación de otros módulos
La funcionalidad de la capa de ejecución se implementa de manera jerárquica, y los otros módulos y funciones se construyen sobre la base de estos tres componentes centrales. A continuación, se presentan algunos de los módulos centrales.
En eth/protocols hay implementaciones de los subprotocolos de la red p2p actual de Ethereum. Hay subprotocolos eth/68 y snap, y estos subprotocolos están construidos sobre devp2p.
eth/68 es el protocolo central de Ethereum, el nombre del protocolo es eth, 68 es su número de versión, y sobre la base de este protocolo se han implementado funciones como el pool de transacciones (TxPool), la sincronización de bloques (Downloader) y la sincronización de transacciones (Fetcher). El protocolo snap se utiliza para la rápida sincronización de bloques y datos de estado cuando nuevos nodos se unen a la red, lo que puede reducir significativamente el tiempo de inicio de nuevos nodos.
ethdb proporciona la capacidad de lectura y escritura de la base de datos subyacente. Debido a que hay muchas estructuras de datos complejas en el protocolo de Ethereum, no es posible gestionar estos datos directamente a través de ethdb, por lo que se implementaron rawdb y statedb sobre ethdb para gestionar respectivamente los datos de bloques y de estado.
EVM atraviesa todos los procesos principales, ya sea la construcción de bloques o la validación de bloques, siempre se necesita ejecutar transacciones con EVM.
05\Geth Nodo inicio del proceso
El inicio de Geth se dividirá en dos fases, la primera fase inicializa los componentes y recursos necesarios para iniciar el nodo, la segunda fase iniciará formalmente el nodo y luego ofrecerá servicios al exterior.
Inicialización del Nodo
Al iniciar un nodo geth, se involucrará el siguiente código:
eth/ethconfig/config.go: Inicializar una instancia del motor de consenso (el motor de consenso aquí no participa realmente en el consenso, solo valida los resultados de la capa de consenso y maneja las solicitudes de retiro de los validadores)
core/blockchain.go: inicializar blockchain
core/filterMaps.go: inicializar filtermaps
core/txpool/blobpool/blobpool.go: inicializar el nodo de transacciones blob
core/txpool/legacypool/legacypool.go: inicializar el nodo de transacciones ordinarias
cord/txpool/locals/tx_tracker.go: Seguimiento de transacciones local (se necesita configurar para habilitar el seguimiento de transacciones local, las transacciones locales serán procesadas con mayor prioridad)
eth/handler.go: inicializar una instancia de Handler del protocolo
miner/miner.go: módulo de empaquetado de transacciones instanciadas (módulo de minería original)
eth/api_backend.go: Instanciar el servicio RPC
eth/gasprice/gasprice.go: Instanciar el servicio de consulta de precios de gas
internal/ethapi/api.go: Instanciar la API RPC de la red P2P
nodo/node.go(RegistrarAPIs)：注册 RPC API
nodo/node.go(RegistrarProtocolos)：registrar p2p de los Protocolos
nodo/node.go(RegistrarCicloDeVida)：registrar el ciclo de vida de cada componente
cmd/utils/flags.go(RegistrarAPI de Filtro)：Registrar API RPC de Filtro
cmd/utils/flags.go(RegistrarServicioGraphQL)：Registrar API RPC de GraphQL (si está configurado)
cmd/utils/flags.go(Registrar el servicio EthStats): Registra la API RPC de EthStats (si está configurada).
eth/catalyst/api.go: Registrar la API del Motor
La inicialización del nodo se completará en makeFullNode en cmd/geth/config.go, centrándose en inicializar los siguientes tres módulos.
En el primer paso, se inicializará la estructura de nodos en node/node.go, que es todo el contenedor de nodos, y todas las funciones deben ejecutarse en este contenedor, el segundo paso inicializará la estructura de Ethereum, que incluye la implementación de varias funciones básicas de Ethereum, y Etherereum también debe registrarse en Node, y el tercer paso es registrar la API del motor en Node.
La inicialización del Nodo consiste en crear una instancia de Nodo, luego inicializar el servidor p2p, la gestión de cuentas y los puertos de protocolo http expuestos al exterior.
La inicialización de Ethereum es mucho más compleja, la mayoría de las funciones centrales se inicializan aquí. Primero se inicializa ethdb y se carga la configuración de la cadena desde el almacenamiento, luego se crea el motor de consenso, el cual no ejecutará operaciones de consenso, sino que solo verificará los resultados devueltos por la capa de consenso; si hay una solicitud de retiro en la capa de consenso, también se completará aquí la operación de retiro real. Luego se inicializa la estructura de la cadena de bloques y el pool de transacciones.
Una vez que todo esto esté completo, se inicializará el handler, que es el punto de entrada para el procesamiento de todas las solicitudes de la red p2p, incluyendo la sincronización de transacciones, la descarga de bloques, etc. Es un componente clave para la implementación de la ejecución descentralizada de Ethereum. Después de completar todo esto, se registrarán algunos subprotocolos implementados sobre devp2p, como eth/68, snap, etc., en el contenedor Node, y finalmente Ethereum se registrará como un ciclo de vida en el contenedor Node, completando así la inicialización de Ethereum.
Por último, la inicialización de la API de Engine es relativamente simple, solo se registra la API de Engine en el Nodo. Hasta aquí, la inicialización del nodo se ha completado.
Inicio del Nodo
Después de completar la inicialización del Nodo, es necesario iniciar el Nodo. El proceso de inicio del Nodo es relativamente simple, solo es necesario iniciar todos los servicios RPC y Lifecycle que ya han sido registrados, y entonces todo el Nodo podrá proporcionar servicios al exterior.
06\resumen
Antes de profundizar en la implementación de la capa de ejecución de Ethereum, es necesario tener una comprensión general de Ethereum. Se puede ver a Ethereum en su conjunto como una máquina de estados impulsada por transacciones. La capa de ejecución es responsable de la ejecución de transacciones y del cambio de estado, mientras que la capa de consenso se encarga de impulsar la operación de la capa de ejecución, incluyendo la producción de bloques por parte de la capa de ejecución, la determinación del orden de las transacciones, la votación sobre los bloques y la consecución de la finalización de los bloques. Dado que esta máquina de estados es descentralizada, necesita comunicarse a través de una red p2p con otros nodos para mantener la coherencia de los datos de estado.
En la capa de ejecución no se encarga de decidir el orden de las transacciones, solo se encarga de ejecutar las transacciones y registrar los cambios de estado después de la ejecución de las transacciones. Aquí hay dos formas de registro, una es registrar todos los cambios de estado en forma de bloques, y la otra es registrar el estado actual en la base de datos. Al mismo tiempo, la capa de ejecución también es la entrada de las transacciones, almacenando las transacciones que aún no han sido empaquetadas en bloques a través de un pool de transacciones. Si otros nodos necesitan obtener bloques, estados y datos de transacciones, la capa de ejecución enviará esta información a través de la red p2p.
Para la capa de ejecución, hay tres módulos centrales: cálculo, almacenamiento y red. El cálculo corresponde a la implementación de EVM, el almacenamiento corresponde a la implementación de ethdb, y la red corresponde a la implementación de devp2p. Con esta comprensión general, se puede profundizar en cada uno de los submódulos sin perderse en los detalles específicos.
El contenido es solo de referencia, no una solicitud u oferta. No se proporciona asesoramiento fiscal, legal ni de inversión. Consulte el Descargo de responsabilidad para obtener más información sobre los riesgos.
Clientes principales de Ethereum: Arquitectura general de Geth
Este artículo es el primero de una serie sobre el código fuente de Geth. A través de esta serie, construiremos un marco para investigar la implementación de Geth, donde los desarrolladores pueden profundizar en las partes que les interesen. Esta serie consta de seis artículos, y en el primer artículo se estudiará la arquitectura de diseño del cliente de capa de ejecución Geth y el proceso de inicio del nodo Geth. La velocidad de actualización del código de Geth es muy rápida, por lo que el código que se verá más adelante puede diferir, pero el diseño general es bastante consistente, y el nuevo código también se puede leer con el mismo enfoque.
01\Cliente de Ethereum
Antes de la actualización The Merge, Ethereum solo tenía un cliente, que era responsable de la ejecución de transacciones y también del consenso de la blockchain, asegurando que se generaran nuevos bloques en un orden determinado. Después de la actualización The Merge, el cliente de Ethereum se dividió en una capa de ejecución y una capa de consenso. La capa de ejecución se encarga de la ejecución de transacciones, el mantenimiento del estado y los datos, mientras que la capa de consenso se encarga de la implementación de las funciones de consenso. La capa de ejecución y la capa de consenso se comunican a través de API. Cada capa tiene sus propias especificaciones, y los clientes pueden implementarse en diferentes lenguajes, pero deben cumplir con las especificaciones correspondientes, siendo Geth una de las implementaciones del cliente de la capa de ejecución. Las implementaciones actuales más comunes de clientes de la capa de ejecución y de la capa de consenso son las siguientes:
Capa de Ejecución
Capa de consenso
02\Introducción a la capa de ejecución
Se puede considerar la capa de ejecución de Ethereum como una máquina de estados impulsada por transacciones. La función más básica de la capa de ejecución es actualizar los datos de estado mediante la ejecución de transacciones a través de la EVM. Además de la ejecución de transacciones, también hay funciones como guardar y validar bloques y datos de estado, ejecutar una red p2p y mantener el grupo de transacciones.
La transacción es generada por el usuario (o programa) de acuerdo con el formato definido por la especificación de la capa de ejecución de Ethereum, el usuario debe firmar la transacción y, si la transacción es legítima (Nonce continuo, la firma es correcta, la tarifa de gas es suficiente y la lógica comercial es correcta), entonces la transacción eventualmente será ejecutada por la EVM, actualizando así el estado de la red Ethereum. El estado aquí se refiere a la recopilación de estructuras de datos, datos y bases de datos, incluidas las direcciones de cuentas externas, las direcciones de contratos, los saldos de direcciones y los códigos y datos.
La capa de ejecución es responsable de ejecutar transacciones y mantener el estado después de la ejecución de la transacción, mientras que la capa de consenso se encarga de seleccionar qué transacciones ejecutar. EVM es la función de transformación de estado dentro de esta máquina de estados, y la entrada de la función puede provenir de múltiples lugares, ya sea de la información del bloque más reciente proporcionada por la capa de consenso o de bloques descargados de la red p2p.
La capa de consenso y la capa de ejecución se comunican a través de la API de Engine, que es la única forma de comunicación entre la capa de ejecución y la capa de consenso. Si la capa de consenso obtiene el derecho a crear bloques, utilizará la API de Engine para permitir que la capa de ejecución produzca nuevos bloques; si no obtiene el derecho a crear bloques, sincronizará los bloques más recientes para que la capa de ejecución los valide y ejecute, manteniendo así el consenso con toda la red de Ethereum.
La capa de ejecución se puede dividir lógicamente en 6 partes:
La imagen de abajo muestra los procesos clave de la capa de ejecución, así como las funciones de cada parte:
Para la capa de ejecución (aquí solo discutimos el Nodo Completo), hay tres procesos clave:
03\estructura del código
La estructura del código de go-ethereum es enorme, pero gran parte del código es código auxiliar y pruebas unitarias, y cuando se mira el código fuente Geth, sólo hay que centrarse en la implementación central del protocolo, y los módulos individuales funcionan de la siguiente manera. Debes centrarte en módulos como core, eth, ethdb, node, p2p, rlp, trie y triedb, etc.:
04\ División del módulo de la capa de ejecución
Hay dos formas de acceso externo a los nodos Geth, una a través de RPC y la otra a través de la consola. RPC es adecuado para usuarios externos y la consola es adecuada para administradores de nodos. Pero ya sea a través de RPC o de la consola, utiliza capacidades que ya están encapsuladas internamente, y esas capacidades se crean en capas.
La capa exterior es la capacidad de la API para acceder a los nodos desde el exterior, la Engine API se utiliza para la comunicación entre la capa de ejecución y la capa de consenso, la Eth API se utiliza para que los usuarios externos o programas envíen transacciones y obtengan información de bloques, y la Net API se utiliza para obtener el estado de la red p2p, entre otros. Por ejemplo, si un usuario envía una transacción a través de la API, esa transacción se enviará finalmente al grupo de transacciones y se gestionará a través de este, y si el usuario necesita obtener datos de un bloque, deberá invocar la capacidad de la base de datos para obtener el bloque correspondiente.
En la siguiente capa de la API, la implementación de las funciones principales incluye la agrupación de transacciones, el empaquetado de transacciones, la producción de bloques, la sincronización de bloques y estados, etc. Estas funciones deben basarse en capacidades de nivel inferior, como la capacidad de la red P2P para sincronizar grupos de transacciones, bloques y estados, y la generación de bloques y bloques sincronizados desde otros nodos debe validarse antes de que puedan escribirse en la base de datos local, que debe depender de las capacidades de EVM y almacenamiento de datos.
! Cliente principal de Ethereum: Arquitectura general de Geth
Estructura de datos central del nivel de ejecución
Ethereum
La estructura de Ethereum en eth/backend.go es la abstracción de todo el protocolo de Ethereum, que incluye principalmente los componentes principales de Ethereum, pero EVM es una excepción, ya que se instancia cada vez que se procesa una transacción, sin necesidad de inicializarse junto con todo el nodo. En el siguiente texto, Ethereum se refiere a esta estructura:
type Ethereum struct { // Configuración de Ethereum, incluida la configuración de cadena *ethconfig. Config // Grupo de transacciones, después de enviar la transacción del usuario, vaya al grupo de transacciones txPool *txpool. TxPool // Se utiliza para rastrear y administrar transacciones locales localTxTracker *locals. TxTracker // Estructura blockchain blockchain *core. BlockChain // es el componente central de la capa de red del nodo Ethereum, responsable de manejar toda la comunicación con otros nodos, incluida la sincronización de bloques, la transmisión y recepción de transacciones, así como la administración del controlador de conexión de nodos pares // responsable del descubrimiento de nodos y la administración de fuentes de nodos discmix *enode. FairMix // Responsable del almacenamiento persistente de la cadena de datos blockchainDb ethdb. Base de datos // Responsable de gestionar la publicación y suscripción de diversos eventos internos a eventMux *event. TypeMux // Consenso del motor. Motor // Administrar cuentas de usuario y claves accountManager *accounts. Administrador // Administrar filtros de registro y fragmentos filterMaps *filtermaps. FilterMaps // Canal para cerrar de forma segura filterMaps, asegurando que los recursos se limpien correctamente cuando los nodos se cierran closeFilterMaps chan chan struct{} // Proporcionar soporte de backend para RPC API APIBackend *EthAPIBackend // En PoS, trabaje con el motor de consenso para validar el minero de bloques *miner. Minero // El precio de gas más bajo aceptado por el nodo es gasPrice *big. Int // ID de red networkID uint64 // Proporciona servicios RPC relacionados con la red, lo que permite consultar el estado de la red a través de RPC netRPCService *ethapi. NetAPI // Administre las conexiones de red P2P, maneje el descubrimiento de nodos y el establecimiento de conexiones, y proporcione funciones de transporte de red subyacentes p2pServer *p2p. Servidor // Proteja el acceso simultáneo a la sincronización de bloqueo de campos mutables. RWMutex // Rastrea si el nodo está inactivo correctamente y ayuda a restaurar shutdownTracker después de un apagado anormal *shutdowncheck. ShutdownTracker }
Nodo
En node/node.go, Node es otra estructura de datos central que actúa como un contenedor, responsable de gestionar y coordinar la ejecución de varios servicios. En la estructura a continuación, es necesario prestar atención al campo lifecycles, ya que Lifecycle se utiliza para gestionar el ciclo de vida de las funciones internas. Por ejemplo, la abstracción de Ethereum mencionada anteriormente necesita depender de Node para iniciarse y registrarse en lifecycles. Esto permite separar las funciones específicas de la abstracción del nodo, mejorando la escalabilidad de toda la arquitectura, y este Node debe distinguirse del Node en devp2p.
type Node struct { eventmux *event. TypeMux config *Config // Gestor de cuentas, responsable de la gestión de carteras y cuentas accman *cuentas. Registro del administrador. Registrador keyDir string keyDirTemp bool dirLock *flock. Flock stop chan struct{} // servidor de instancia de red p2p *p2p. Sincronización del servidor startStopLock. Mutex // Seguimiento del estado del ciclo de vida del nodo (inicializado, en ejecución, cerrado) state int lock sync. Mutex // Todos los backends, servicios y servicios auxiliares registrados Ciclos de vida []Ciclo de vida // Lista de APIs disponibles actualmente rpcAPIs []rpc. API // Diferentes métodos de acceso para RPC http *httpServer ws *httpServer httpAuth *httpServer wsAuth *httpServer ipc *ipcServer inprocHandler *rpc. Mapa de bases de datos de servidor[*closeTrackingDB]struct{} }
Si miramos la capa de ejecución de Ethereum desde una dimensión abstracta, Ethereum, como computadora mundial, necesita incluir tres partes, red, computación y almacenamiento, entonces los componentes correspondientes a estas tres partes en la capa de ejecución de Ethereum son:
devp2p
Ethereum es esencialmente un sistema distribuido, donde cada nodo se conecta a otros nodos a través de una red p2p. La implementación del protocolo de red p2p en Ethereum es devp2p.
devp2p tiene dos funciones principales, una es el descubrimiento de nodos, que permite a los nodos establecer contacto con otros nodos al conectarse a la red; la otra es el servicio de transmisión de datos, que permite intercambiar datos una vez que se ha establecido la conexión con otros nodos.
En la estructura Node en p2p/enode/node.go representa un nodo en la red p2p, donde los pares clave-valor que almacenan información detallada del nodo se encuentran en la estructura enr.Record, incluyendo información de identidad (algoritmo de firma utilizado para la identidad del nodo, clave pública), información de red (dirección IP, número de puerto), información de protocolos soportados (como eth/68 y protocolo snap) y otra información personalizada. Esta información se codifica de manera RLP, y la especificación concreta se define en eip-778:
type Node struct { // Nodo registro, contiene varias propiedades del nodo r enr.Record // Identificador único del nodo, longitud de 32 bytes id ID // nombre de host Nombre DNS del nodo hostname string // Dirección IP del nodo ip netip.Addr // Puerto UDP udp uint16 // Puerto TCP tcp uint16 }// enr.Recordtype Record struct { // Número de serie seq uint64 // Firma signature []byte // Registro codificado en RLP raw []byte // Lista ordenada de todos los pares clave-valor pairs []pair }
La estructura Table en p2p/discover/table.go es la estructura de datos central de la implementación del protocolo de descubrimiento de nodos de devp2p. Implementa una tabla hash distribuida similar a Kademlia, utilizada para mantener y gestionar la información de los nodos en la red.
printf("type Table struct { mutex sync.Mutex // Índice de nodos conocidos por distancia buckets [nBuckets]*bucket // Nodos guía nursery []*enode.Node rand reseedingRandom ips netutil.DistinctNetSet revalidation tableRevalidation // Base de datos de nodos conocidos db *enode.DB net transport cfg Config log log.Logger // Procesamiento periódico de varios eventos en la red 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{} // Interfaz para agregar y eliminar nodos nodeAddedHook func(*bucket, *tableNode) nodeRemovedHook func(*bucket, *tableNode)} world!");
ethdb
ethdb completa la abstracción del almacenamiento de datos de Ethereum, proporcionando una interfaz de almacenamiento unificada. La base de datos concreta subyacente puede ser leveldb, pebble u otra base de datos. Puede haber muchas extensiones, siempre que se mantenga la uniformidad a nivel de interfaz.
Algunos datos (como los datos de bloques) se pueden leer y escribir directamente en la base de datos subyacente a través de la interfaz ethdb, mientras que otras interfaces de almacenamiento de datos se basan en ethdb. Por ejemplo, una gran parte de los datos de la base de datos son datos de estado, estos datos se organizan en una estructura MPT, cuya implementación correspondiente en Geth es trie. Durante el funcionamiento del nodo, los datos de trie generan muchos estados intermedios, estos datos no se pueden leer y escribir directamente a través de ethdb, se necesita triedb para gestionar estos datos y estados intermedios, y finalmente se persisten a través de ethdb.
En ethdb/database.go se define la interfaz de capacidades de lectura y escritura de la base de datos subyacente, pero no incluye una implementación concreta, que será realizada por las propias bases de datos. Por ejemplo, la base de datos leveldb o pebble. En Database se definen dos capas de interfaces de lectura y escritura de datos, donde la interfaz KeyValueStore se utiliza para almacenar datos activos, que pueden cambiar con frecuencia, como los últimos bloques, estados, etc. AncientStore se utiliza para manejar datos de bloques históricos, que una vez escritos, rara vez cambian.
// Interfaz de nivel superior de la base de datos type Database interface { KeyValueStore AncientStore } // Interfaz de lectura y escritura de datos KV type KeyValueStore interface { KeyValueReader KeyValueWriter KeyValueStater KeyValueRangeDeleter Batcher Iteratee Compacter io.Closer } // Interfaz de lectura y escritura de datos antiguos type AncientStore interface { AncientReader AncientWriter AncientStater io.Closer }
EVM
EVM es la función de transición de estado de la máquina de estado de Ethereum, todas las actualizaciones de datos de estado solo se pueden realizar a través de EVM. La red p2p puede recibir información de transacciones y bloques, que después de ser procesada por EVM se convierte en parte de la base de datos de estado. EVM oculta las diferencias de hardware subyacente, permitiendo que los programas se ejecuten en diferentes EVM de la plataforma y obtengan resultados consistentes. Este es un enfoque de diseño muy maduro, el JVM en el lenguaje Java también tiene un diseño similar.
La implementación de EVM tiene tres componentes principales: la estructura EVM en core/vm/evm.go define la estructura general y las dependencias de EVM, incluyendo el contexto de ejecución, la dependencia de la base de datos de estado, etc.; la estructura EVMInterpreter en core/vm/interpreter.go define la implementación del intérprete, que es responsable de ejecutar el bytecode de EVM; la estructura Contract en core/vm/contract.go encapsula los parámetros específicos de la llamada al contrato, incluyendo el llamador, el código del contrato, la entrada, etc., y en core/vm/opcodes.go se definen todos los códigos de operación actuales:
// EVMtype EVM struct { // Contexto de bloque, contiene información relacionada con el bloque Context BlockContext // Contexto de transacción, contiene información relacionada con la transacción TxContext // Base de datos de estado, utilizada para acceder y modificar el estado de la cuenta StateDB StateDB // Profundidad de llamada actual depth int // Parámetros de configuración de la cadena chainConfig *params.ChainConfig chainRules params.Rules // Configuración de EVM Config Config // Intérprete de bytecode interpreter *EVMInterpreter // Indicador de interrupción de ejecución abort atomic.Bool callGasTemp uint64 // Mapeo de contratos precompilados precompiles map[common.Address]PrecompiledContract jumpDests map[common.Hash]bitvec }type EVMInterpreter struct { // Puntero a la instancia de EVM correspondiente evm *EVM // Tabla de salto de código de operación table *JumpTable // Instancia del hasher Keccak256, compartido entre las operaciones hasher crypto.KeccakState // Buffer de resultados del hash Keccak256 hasherBuf common.Hash // Modo de solo lectura, no se permiten modificaciones de estado en modo solo lectura readOnly bool // Datos de retorno de la última llamada CALL, para reutilización posterior returnData []byte }type Contract struct { // Dirección del llamador caller common.Address // Dirección del contrato address common.Address jumpdests map[common.Hash]bitvec analysis bitvec // Bytecode del contrato Code []byte // Hash del código CodeHash common.Hash // Entrada de llamada Input []byte // ¿Es un despliegue de contrato? IsDeployment bool // ¿Es una llamada del sistema? IsSystemCall bool // Cantidad de gas disponible Gas uint64 // Cantidad de ETH adjunta a la llamada value *uint256.Int }
Implementación de otros módulos
La funcionalidad de la capa de ejecución se implementa de manera jerárquica, y los otros módulos y funciones se construyen sobre la base de estos tres componentes centrales. A continuación, se presentan algunos de los módulos centrales.
En eth/protocols hay implementaciones de los subprotocolos de la red p2p actual de Ethereum. Hay subprotocolos eth/68 y snap, y estos subprotocolos están construidos sobre devp2p.
eth/68 es el protocolo central de Ethereum, el nombre del protocolo es eth, 68 es su número de versión, y sobre la base de este protocolo se han implementado funciones como el pool de transacciones (TxPool), la sincronización de bloques (Downloader) y la sincronización de transacciones (Fetcher). El protocolo snap se utiliza para la rápida sincronización de bloques y datos de estado cuando nuevos nodos se unen a la red, lo que puede reducir significativamente el tiempo de inicio de nuevos nodos.
ethdb proporciona la capacidad de lectura y escritura de la base de datos subyacente. Debido a que hay muchas estructuras de datos complejas en el protocolo de Ethereum, no es posible gestionar estos datos directamente a través de ethdb, por lo que se implementaron rawdb y statedb sobre ethdb para gestionar respectivamente los datos de bloques y de estado.
EVM atraviesa todos los procesos principales, ya sea la construcción de bloques o la validación de bloques, siempre se necesita ejecutar transacciones con EVM.
05\Geth Nodo inicio del proceso
El inicio de Geth se dividirá en dos fases, la primera fase inicializa los componentes y recursos necesarios para iniciar el nodo, la segunda fase iniciará formalmente el nodo y luego ofrecerá servicios al exterior.
Inicialización del Nodo
Al iniciar un nodo geth, se involucrará el siguiente código:
La inicialización de cada módulo es la siguiente:
La inicialización del nodo se completará en makeFullNode en cmd/geth/config.go, centrándose en inicializar los siguientes tres módulos.
En el primer paso, se inicializará la estructura de nodos en node/node.go, que es todo el contenedor de nodos, y todas las funciones deben ejecutarse en este contenedor, el segundo paso inicializará la estructura de Ethereum, que incluye la implementación de varias funciones básicas de Ethereum, y Etherereum también debe registrarse en Node, y el tercer paso es registrar la API del motor en Node.
La inicialización del Nodo consiste en crear una instancia de Nodo, luego inicializar el servidor p2p, la gestión de cuentas y los puertos de protocolo http expuestos al exterior.
La inicialización de Ethereum es mucho más compleja, la mayoría de las funciones centrales se inicializan aquí. Primero se inicializa ethdb y se carga la configuración de la cadena desde el almacenamiento, luego se crea el motor de consenso, el cual no ejecutará operaciones de consenso, sino que solo verificará los resultados devueltos por la capa de consenso; si hay una solicitud de retiro en la capa de consenso, también se completará aquí la operación de retiro real. Luego se inicializa la estructura de la cadena de bloques y el pool de transacciones.
Una vez que todo esto esté completo, se inicializará el handler, que es el punto de entrada para el procesamiento de todas las solicitudes de la red p2p, incluyendo la sincronización de transacciones, la descarga de bloques, etc. Es un componente clave para la implementación de la ejecución descentralizada de Ethereum. Después de completar todo esto, se registrarán algunos subprotocolos implementados sobre devp2p, como eth/68, snap, etc., en el contenedor Node, y finalmente Ethereum se registrará como un ciclo de vida en el contenedor Node, completando así la inicialización de Ethereum.
Por último, la inicialización de la API de Engine es relativamente simple, solo se registra la API de Engine en el Nodo. Hasta aquí, la inicialización del nodo se ha completado.
Inicio del Nodo
Después de completar la inicialización del Nodo, es necesario iniciar el Nodo. El proceso de inicio del Nodo es relativamente simple, solo es necesario iniciar todos los servicios RPC y Lifecycle que ya han sido registrados, y entonces todo el Nodo podrá proporcionar servicios al exterior.
06\resumen
Antes de profundizar en la implementación de la capa de ejecución de Ethereum, es necesario tener una comprensión general de Ethereum. Se puede ver a Ethereum en su conjunto como una máquina de estados impulsada por transacciones. La capa de ejecución es responsable de la ejecución de transacciones y del cambio de estado, mientras que la capa de consenso se encarga de impulsar la operación de la capa de ejecución, incluyendo la producción de bloques por parte de la capa de ejecución, la determinación del orden de las transacciones, la votación sobre los bloques y la consecución de la finalización de los bloques. Dado que esta máquina de estados es descentralizada, necesita comunicarse a través de una red p2p con otros nodos para mantener la coherencia de los datos de estado.
En la capa de ejecución no se encarga de decidir el orden de las transacciones, solo se encarga de ejecutar las transacciones y registrar los cambios de estado después de la ejecución de las transacciones. Aquí hay dos formas de registro, una es registrar todos los cambios de estado en forma de bloques, y la otra es registrar el estado actual en la base de datos. Al mismo tiempo, la capa de ejecución también es la entrada de las transacciones, almacenando las transacciones que aún no han sido empaquetadas en bloques a través de un pool de transacciones. Si otros nodos necesitan obtener bloques, estados y datos de transacciones, la capa de ejecución enviará esta información a través de la red p2p.
Para la capa de ejecución, hay tres módulos centrales: cálculo, almacenamiento y red. El cálculo corresponde a la implementación de EVM, el almacenamiento corresponde a la implementación de ethdb, y la red corresponde a la implementación de devp2p. Con esta comprensión general, se puede profundizar en cada uno de los submódulos sin perderse en los detalles específicos.
07\Ref
[1]
[2]
[3]
[4]
[5]
[6]
·FIN·
Contenido | Ray
Edición & Maquetación | Huán Huán
Diseño | Daisy