This article is the first in the Geth source code series. Through this series, we will build a framework for studying the implementation of Geth, allowing developers to delve into the parts they are interested in. There are a total of six articles in this series. In the first article, we will explore the design architecture of the execution layer client Geth and the startup process of Geth nodes. The Geth code is updated rapidly, so the code seen later may differ, but the overall design remains consistent, and the new code can be read with the same approach.

01\Ethereum Client

Before the The Merge upgrade, Ethereum had only one client, which was responsible for executing transactions and also for the consensus of the blockchain, ensuring that new blocks were produced in a certain order. After the The Merge upgrade, the Ethereum client was divided into the execution layer and the consensus layer. The execution layer is responsible for executing transactions, maintaining state and data, while the consensus layer is responsible for implementing consensus functions. The execution layer and consensus layer communicate via APIs. Each layer has its own specifications, and clients can be implemented in different languages, but they must comply with the corresponding specifications. Geth is one such implementation of the execution layer client. The current mainstream execution layer and consensus layer clients are as follows:

Execution Layer

• Geth: Maintained by a team directly funded by the Ethereum Foundation, developed in Go language, recognized as the most stable and time-tested client.
• Nethermind: Developed and maintained by the Nethermind team, developed in C#, initially funded by the Ethereum Foundation and the Gitcoin community.
• Besu: Originally developed by ConsenSys's PegaSys team, now part of the Hyperledger community, developed in Java.
• Erigon: Developed and maintained by the Erigon team, funded by the Ethereum Foundation and BNB Chain. Forked from Geth in 2017, aimed at improving synchronization speed and disk efficiency.
• Reth: Led by Paradigm, developed in Rust, emphasizing modularity and high performance, now nearing maturity and usable in production environments.

Consensus Layer

• Prysm: Maintained by Prysmatic Labs, one of the earliest consensus layer clients for Ethereum, developed in Go, focusing on usability and security, initially funded by the Ethereum Foundation.
• Lighthouse: Maintained by the Sigma Prime team, developed in Rust, emphasizing high performance and enterprise-level security, suitable for high-load scenarios.
• Teku: Initially developed by ConsenSys's PegaSys team, later became part of the Hyperledger Besu community, developed in Java.
• Nimbus: Developed and maintained by the Status Network team, developed in Nim, optimized for resource-constrained devices (such as mobile phones and IoT devices), aiming for lightweight operation in embedded systems.

02\Introduction to the Execution Layer

The Ethereum execution layer can be viewed as a transaction-driven state machine. The most basic function of the execution layer is to update state data by executing transactions through the EVM. In addition to transaction execution, it also involves saving and verifying blocks and state data, running a p2p network, and maintaining a transaction pool.

Transactions are generated by users (or programs) in a format defined by the Ethereum execution layer specifications. Users need to sign the transactions. If the transaction is valid (nonce is consecutive, signature is correct, gas fee is sufficient, business logic is correct), then the transaction will ultimately be executed by the EVM, thereby updating the state of the Ethereum network. Here, the state refers to the collection of data structures, data, and databases, including external account addresses, contract addresses, address balances, as well as code and data.

The execution layer is responsible for executing transactions and maintaining the state after transaction execution, while the consensus layer is responsible for selecting which transactions to execute. The EVM serves as the state transition function within this state machine, with inputs coming from various sources, possibly from the latest block information provided by the consensus layer or from blocks downloaded via the p2p network.

The consensus layer and execution layer communicate through the Engine API, which is the only communication method between the execution layer and the consensus layer. If the consensus layer obtains block production rights, it will use the Engine API to allow the execution layer to produce new blocks. If it does not obtain block production rights, it will synchronize the latest blocks for the execution layer to verify and execute, thus maintaining consensus with the entire Ethereum network.

Logically, the execution layer can be divided into six parts:

• EVM: Responsible for executing transactions; transaction execution is the only way to modify state data.
• Storage: Responsible for storing state and block data.
• Transaction Pool: Temporarily stores transactions submitted by users and propagates them across different nodes via the p2p network.
• p2p Network: Used for node discovery, transaction synchronization, downloading blocks, and other functions.
• RPC Service: Provides the ability to access nodes, such as users sending transactions to nodes and interactions between the consensus layer and execution layer.
• BlockChain: Responsible for managing Ethereum's blockchain data.

The following diagram illustrates the key processes of the execution layer and the functions of each part:

For the execution layer (here we only discuss Full Node), there are three key processes:

• If it is a newly joined Ethereum node, it needs to synchronize blocks and state data from other nodes through the p2p network. If it is a Full Sync, it will start downloading blocks one by one from the genesis block, verifying the blocks, and rebuilding the state database through the EVM. If it is Snap Sync, it skips the entire block verification process and directly downloads the latest checkpoint's state data and subsequent block data.
• If it is a node that has already synchronized to the latest state, it will continuously obtain the currently produced latest blocks from the consensus layer through the Engine API, verify the blocks, then execute all transactions in the blocks through the EVM to update the state database, and write the blocks to the local chain.
• If it is a node that has already synchronized to the latest state and the consensus layer has obtained block production rights, it will drive the execution layer to produce the latest blocks through the Engine API. The execution layer retrieves transactions from the transaction pool, executes them, and then assembles them into blocks to be passed to the consensus layer via the Engine API, which will broadcast the blocks to the consensus layer's p2p network.

03\Source Code Structure

The code structure of go-ethereum is quite large, but much of it consists of auxiliary code and unit tests. When studying the Geth source code, one only needs to focus on the core implementation of the protocol. The functions of various modules are as follows. It is important to pay attention to modules such as core, eth, ethdb, node, p2p, rlp, trie & triedb:

• accounts: Manages Ethereum accounts, including the generation of public-private key pairs, signature verification, address derivation, etc.
• beacon: Handles the interaction logic with the Ethereum Beacon Chain, supporting functionalities after the Proof of Stake (PoS) consensus merge (The Merge).
• build: Build scripts and compilation configurations (such as Dockerfile, cross-platform compilation support).
• cmd: Command line tool entry, containing multiple subcommands.
• common: General utility classes, such as byte processing, address format conversion, mathematical functions.
• consensus: Defines the consensus engine, including previous proof of work (Ethash) and single-machine proof of stake (Clique) as well as the Beacon engine.
• console: Provides an interactive JavaScript console, allowing users to directly interact with Ethereum nodes via the command line (such as calling Web3 API, managing accounts, querying blockchain data).
• core: Core logic of the blockchain, handling the lifecycle management of blocks/transactions, state machine, gas calculation, etc.
• crypto: Implementation of cryptographic algorithms, including elliptic curves (secp256k1), hashing (Keccak-256), signature verification.
• docs: Documentation (such as design specifications, API descriptions).
• eth: Complete implementation of the Ethereum network protocol, including node services, block synchronization (such as fast sync, archive mode), transaction broadcasting, etc.
• ethclient: Implements the Ethereum client library, encapsulating the JSON-RPC interface for Go developers to interact with Ethereum nodes (such as querying blocks, sending transactions, deploying contracts).
• ethdb: Database abstraction layer, supporting LevelDB, Pebble, in-memory databases, etc., for storing blockchain data (blocks, state, transactions).
• ethstats: Collects and reports node operating status to a statistics service for monitoring network health.
• event: Implements an event subscription and publishing mechanism, supporting asynchronous communication between internal node modules (such as new block arrival, transaction pool updates).
• graphql: Provides a GraphQL interface, supporting complex queries (replacing some JSON-RPC functionalities).
• internal: Internal tools or code that restricts external access.
• log: Logging system, supporting hierarchical log output and contextual log recording.
• metrics: Performance metrics collection (Prometheus support).
• miner: Mining-related logic, generating new blocks and packaging transactions (in PoW scenarios).
• node: Node service management, integrating the startup and configuration of p2p, RPC, database, and other modules.
• p2p: Implementation of the peer-to-peer network protocol, supporting node discovery, data transmission, and encrypted communication.
• params: Defines Ethereum network parameters (mainnet, testnet, genesis block configuration).
• rlp: Implements Ethereum's specific data serialization protocol RLP (Recursive Length Prefix), used for encoding/decoding blocks, transactions, and other data structures.
• rpc: Implements JSON-RPC and IPC interfaces for external programs to interact with nodes.
• signer: Transaction signature management (hardware wallet integration).
• tests: Integration tests and state tests to verify protocol compatibility.
• trie & triedb: Implementation of the Merkle Patricia Trie for efficient storage and management of account states and contract storage.

04\Execution Layer Module Division

External access to Geth nodes can be done in two ways: one is through RPC, and the other is through the Console. RPC is suitable for external users, while the Console is intended for node administrators. However, whether through RPC or Console, both utilize the capabilities that are already encapsulated internally, which are built in a layered manner.

The outermost layer consists of APIs for external access to various capabilities of the node. The Engine API is used for communication between the execution layer and the consensus layer, the Eth API is for external users or programs to send transactions and retrieve block information, and the Net API is for obtaining the status of the p2p network, among other things. For example, if a user sends a transaction through the API, that transaction will ultimately be submitted to the transaction pool for management. Similarly, if a user needs to retrieve block data, they will need to call the database capabilities to obtain the corresponding block.

The next layer down is the implementation of core functionalities, including the transaction pool, transaction packaging, block production, and synchronization of blocks and states, etc. These functionalities rely on lower-level capabilities; for instance, the synchronization of the transaction pool, blocks, and states depends on the capabilities of the p2p network. The generation of blocks and the verification of blocks synchronized from other nodes must be validated before being written to the local database, which requires the capabilities of the EVM and data storage.

Core Data Structures of the Execution Layer

Ethereum

In eth/backend.go, the Ethereum structure is an abstraction of the entire Ethereum protocol, essentially including the main components of Ethereum, but the EVM is an exception; it is instantiated each time a transaction is processed and does not need to be initialized with the entire node. The Ethereum referred to in the following text is this structure:

type Ethereum struct { 
    // Ethereum configuration, including chain configuration 
    config *ethconfig.Config 
    // Transaction pool, where user transactions are submitted first 
    txPool *txpool.TxPool 
    // Used to track and manage local transactions 
    localTxTracker *locals.TxTracker 
    // Blockchain structure 
    blockchain *core.BlockChain 
    // Core component of the Ethereum node's network layer, responsible for handling all communications with other nodes, including block synchronization, transaction broadcasting and receiving, and managing peer node connections 
    handler *handler 
    // Responsible for node discovery and node source management 
    discmix *enode.FairMix 
    // Responsible for the persistent storage of blockchain data 
    chainDb ethdb.Database 
    // Responsible for handling the publication and subscription of various internal events 
    eventMux *event.TypeMux 
    // Consensus engine 
    engine consensus.Engine 
    // Manages user accounts and keys 
    accountManager *accounts.Manager 
    // Manages log filters and block filters 
    filterMaps *filtermaps.FilterMaps 
    // Channel for safely closing filterMaps, ensuring resources are correctly cleaned up when the node shuts down 
    closeFilterMaps chan chan struct{} 
    // Provides backend support for RPC API 
    APIBackend *EthAPIBackend 
    // Under PoS, collaborates with the consensus engine to validate blocks 
    miner *miner.Miner 
    // Minimum gas price accepted by the node 
    gasPrice *big.Int 
    // Network ID 
    networkID uint64 
    // Provides network-related RPC services, allowing querying of network status via RPC 
    netRPCService *ethapi.NetAPI 
    // Manages P2P network connections, handling node discovery and connection establishment, and providing underlying network transmission capabilities 
    p2pServer *p2p.Server 
    // Protects concurrent access to mutable fields 
    lock sync.RWMutex 
    // Tracks whether the node is shutting down normally, helping to recover after an abnormal shutdown 
    shutdownTracker *shutdowncheck.ShutdownTracker 
}

Node

In node/node.go, the Node is another core data structure that acts as a container responsible for managing and coordinating the operation of various services. In the structure below, attention should be paid to the lifecycles field, where Lifecycle is used to manage the lifecycle of internal functionalities. For example, the above Ethereum abstraction needs to rely on Node to start and register in lifecycles. This separation allows for the decoupling of specific functionalities from the node abstraction, enhancing the scalability of the entire architecture. This Node needs to be distinguished from the Node in devp2p.

type Node struct { 
    eventmux *event.TypeMux 
    config *Config 
    // Account manager, responsible for managing wallets and accounts 
    accman *accounts.Manager 
    log log.Logger 
    keyDir string 
    keyDirTemp bool 
    dirLock *flock.Flock 
    stop chan struct{} 
    // P2P network instance 
    server *p2p.Server 
    startStopLock sync.Mutex 
    // Tracks the lifecycle state of the node (initializing, running, shut down) 
    state int 
    lock sync.Mutex 
    // All registered backends, services, and auxiliary services 
    lifecycles []Lifecycle 
    // Currently provided API list 
    rpcAPIs []rpc.API 
    // Different access methods provided for RPC 
    http *httpServer 
    ws *httpServer 
    httpAuth *httpServer 
    wsAuth *httpServer 
    ipc *ipcServer 
    inprocHandler *rpc.Server 
    databases map[*closeTrackingDB]struct{} 
}

From an abstract perspective, the Ethereum execution layer, as a world computer, needs to include three parts: network, computation, and storage. The components corresponding to these three parts in the Ethereum execution layer are:

• Network: devp2p
• Computation: EVM
• Storage: ethdb

devp2p

Ethereum is essentially a distributed system, with each node connected to other nodes via a p2p network. The implementation of the p2p network protocol in Ethereum is devp2p.

devp2p has two core functions: one is node discovery, allowing nodes to establish connections with other nodes when joining the network; the other is data transmission service, which enables data exchange once connections with other nodes are established.

In p2p/enode/node.go, the Node structure represents a node in the p2p network, where the enr.Record structure stores key-value pairs of detailed information about the node, including identity information (the signature algorithm and public key used by the node), network information (IP address, port number), supported protocol information (such as support for eth/68 and snap protocols), and other custom information. This information is encoded using RLP, with specific specifications defined in EIP-778:

type Node struct { 
    // Node record, containing various attributes of the node 
    r enr.Record 
    // Unique identifier for the node, 32 bytes in length 
    id ID 
    // Hostname tracking the node's DNS name 
    hostname string 
    // Node's IP address 
    ip netip.Addr 
    // UDP port 
    udp uint16 
    // TCP port 
    tcp uint16 
}

In p2p/discover/table.go, the Table structure is the core data structure for implementing the node discovery protocol in devp2p. It implements a distributed hash table similar to Kademlia, used to maintain and manage node information in the network.

printf("type Table struct { mutex sync.Mutex // Index known nodes by distance buckets [nBuckets]bucket // Bootstrap nodes nursery []enode.Node rand reseedingRandom ips netutil.DistinctNetSet revalidation tableRevalidation // Database of known nodes db enode.DB net transport cfg Config log log.Logger // Periodically handle various events in the network 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{} // Interfaces for adding and removing nodes nodeAddedHook func(bucket, tableNode) nodeRemovedHook func(bucket, *tableNode) } world!");

**ethdb**

ethdb completes the abstraction of Ethereum data storage, providing a unified storage interface. The underlying database can be leveldb, pebble, or other databases. There can be many extensions as long as the interface layer remains unified.

Some data (such as block data) can be read and written directly to the underlying database through the ethdb interface, while other data storage interfaces are built on top of ethdb. For example, a large portion of the database consists of state data, which is organized into an MPT structure. In Geth, the corresponding implementation is a trie. During the operation of the node, trie data generates many intermediate states that cannot be directly read and written using ethdb; instead, they need to be managed by triedb, which ultimately persists through ethdb.

In `ethdb/database.go`, the interface for reading and writing capabilities of the underlying database is defined, but specific implementations are not included; these will be implemented by different databases themselves, such as leveldb or pebble. The Database defines two layers of data read and write interfaces, where the KeyValueStore interface is used for storing active, frequently changing data, such as the latest blocks and states. AncientStore is used to handle historical block data, which rarely changes once written.

go // Top-level interface for the database type Database interface { KeyValueStore AncientStore }

// KV data read and write interface type KeyValueStore interface { KeyValueReader KeyValueWriter KeyValueStater KeyValueRangeDeleter Batcher Iteratee Compacter io.Closer }

// Interface for handling old data read and write type AncientStore interface { AncientReader AncientWriter AncientStater io.Closer }

**EVM**

EVM is the state transition function of the Ethereum state machine, and all state data updates can only be performed through the EVM. The p2p network can receive transaction and block information, which, after being processed by the EVM, becomes part of the state database. The EVM abstracts the differences in underlying hardware, allowing programs to execute on different platforms' EVMs and achieve consistent results. This is a mature design approach, similar to the JVM in the Java language.

The implementation of the EVM has three main components: the `EVM` structure defined in `core/vm/evm.go`, which outlines the overall structure and dependencies of the EVM, including execution context and state database dependencies; the `EVMInterpreter` structure defined in `core/vm/interpreter.go`, which implements the interpreter responsible for executing EVM bytecode; and the `Contract` structure defined in `core/vm/contract.go`, which encapsulates the specific parameters for contract calls, including the caller, contract code, input, etc. The current operation codes are defined in `core/vm/opcodes.go`:

go // EVM type EVM struct { // Block context, containing block-related information Context BlockContext // Transaction context, containing transaction-related information TxContext // State database, used to access and modify account states StateDB StateDB // Current call depth depth int // Chain configuration parameters chainConfig *params.ChainConfig chainRules params.Rules // EVM configuration Config Config // Bytecode interpreter interpreter *EVMInterpreter // Flag to abort execution abort atomic.Bool callGasTemp uint64 // Precompiled contract mapping precompiles map[common.Address]PrecompiledContract jumpDests map[common.Hash]bitvec }

type EVMInterpreter struct { // Pointer to the owning EVM instance evm *EVM // Opcode jump table table *JumpTable // Keccak256 hasher instance, shared between opcodes hasher crypto.KeccakState // Keccak256 hash result buffer hasherBuf common.Hash // Whether in read-only mode, state modification is not allowed in read-only mode readOnly bool // Return data from the last CALL, for reuse in subsequent calls returnData []byte }

type Contract struct { // Caller address caller common.Address // Contract address address common.Address jumpdests map[common.Hash]bitvec analysis bitvec // Contract bytecode Code []byte // Code hash CodeHash common.Hash // Call input Input []byte // Whether it is a contract deployment IsDeployment bool // Whether it is a system call IsSystemCall bool // Available gas amount Gas uint64 // Amount of ETH accompanying the call value *uint256.Int }

#### **Other Module Implementations**

The functionalities of the execution layer are implemented in a layered manner, with other modules and functionalities built on top of these three core components. Here are a few core modules.

In `eth/protocols`, the current implementation of Ethereum's p2p network sub-protocols is found. There are eth/68 and snap sub-protocols, which are built on devp2p.

eth/68 is the core protocol of Ethereum, with the protocol name being eth and 68 as its version number. On this basis, functionalities such as the transaction pool (TxPool), block synchronization (Downloader), and transaction synchronization (Fetcher) are implemented. The snap protocol is used for quickly synchronizing blocks and state data when new nodes join the network, significantly reducing the startup time for new nodes.

ethdb provides the read and write capabilities of the underlying database. Due to the complex data structures in the Ethereum protocol, direct management of these data through ethdb is not feasible, so rawdb and statedb are implemented on top of ethdb to manage block and state data, respectively.

The EVM runs through all main processes; whether for block construction or block validation, the EVM is required to execute transactions.

### 05\\Geth Node Startup Process

The startup of Geth is divided into two phases: the first phase initializes the components and resources needed to start the node, and the second phase formally starts the node and provides services externally.

![Mainstream Ethereum Clients: Overall Architecture of Geth](https://static.aicoinstorge.com/attachment/article/20250427/174573723681438.jpg)

#### **Node Initialization**

When starting a Geth node, the following code is involved:

![Mainstream Ethereum Clients: Overall Architecture of Geth](https://static.aicoinstorge.com/attachment/article/20250427/174573723756794.jpg)

The initialization of each module is as follows:

*   cmd/geth/main.go: Entry point for starting the Geth node
*   cmd/geth/config.go (makeFullNode): Load configuration and initialize the node

*   node/node.go: Initialize the core container of the Ethereum node

1.  node.rpcstack.go: Initialize the RPC module
2.  accounts.manager.go: Initialize accountManager

*   eth/backend.go: Initialize the Ethereum instance

1. node/node.go OpenDatabaseWithFreezer: Initialize chaindb
2. eth/ethconfig/config.go: Initialize consensus engine instance (the consensus engine here does not actually participate in consensus, it only verifies the results of the consensus layer and handles validator withdrawal requests)
3. core/blockchain.go: Initialize blockchain
4. core/filterMaps.go: Initialize filtermaps
5. core/txpool/blobpool/blobpool.go: Initialize blob transaction pool
6. core/txpool/legacypool/legacypool.go: Initialize regular transaction pool
7. cord/txpool/locals/tx_tracker.go: Local transaction tracking (local transaction tracking needs to be configured to be enabled, local transactions will be processed with higher priority)
8. eth/handler.go: Initialize protocol's Handler instance
9. miner/miner.go: Instantiate the transaction packaging module (original mining module)
10. eth/api_backend.go: Instantiate RPC service
11. eth/gasprice/gasprice.go: Instantiate gas price query service
12. internal/ethapi/api.go: Instantiate P2P network RPC API
13. node/node.go(RegisterAPIs): Register RPC API
14. node/node.go(RegisterProtocols): Register p2p Protocols
15. node/node.go(RegisterLifecycle): Register the lifecycle of various components

• cmd/utils/flags.go(RegisterFilterAPI): Register Filter RPC API
• cmd/utils/flags.go(RegisterGraphQLService): Register GraphQL RPC API (if configured)
• cmd/utils/flags.go(RegisterEthStatsService): Register EthStats RPC API (if configured)
• eth/catalyst/api.go: Register Engine API

Node initialization will be completed in cmd/geth/config.go within makeFullNode, focusing on initializing the following three modules.

In the first step, the Node structure in node/node.go will be initialized, which is the entire node container where all functionalities need to run. The second step will initialize the Ethereum structure, which includes the implementation of various core functionalities of Ethereum. Ethereum also needs to be registered in the Node. The third step is to register the Engine API in the Node.

The Node initialization creates a Node instance, then initializes the p2p server, account management, and HTTP protocol ports exposed to the outside.

The initialization of Ethereum is much more complex, as most core functionalities are initialized here. First, ethdb will be initialized, and the chain configuration will be loaded from storage. Then, the consensus engine will be created. This consensus engine will not perform consensus operations but will only verify the results returned by the consensus layer. If there are withdrawal requests from the consensus layer, the actual withdrawal operations will also be completed here. After that, the Block Chain structure and transaction pool will be initialized.

Once all of this is completed, the handler will be initialized. The handler is the entry point for all p2p network requests, including transaction synchronization, block downloading, etc., and is a key component for Ethereum's decentralized operation. After completing these, some sub-protocols implemented on top of devp2p, such as eth/68, snap, etc., will be registered in the Node container. Finally, Ethereum will be registered as a lifecycle in the Node container, completing the initialization of Ethereum.

Finally, the initialization of the Engine API is relatively simple, just registering the Engine API in the Node. At this point, the node initialization is fully completed.

Node Startup

After completing the node initialization, the node needs to be started. The process of starting the node is relatively simple; it only requires starting all registered RPC services and Lifecycle, and then the entire node can provide services to the outside.

06\Summary

Before deeply understanding the implementation of the Ethereum execution layer, it is necessary to have an overall understanding of Ethereum. Ethereum can be viewed as a transaction-driven state machine, where the execution layer is responsible for executing transactions and changing states, while the consensus layer is responsible for driving the execution layer's operation, including allowing the execution layer to produce blocks, determining the order of transactions, voting for blocks, and ensuring blocks achieve finality. Since this state machine is decentralized, it needs to communicate with other nodes through a p2p network to jointly maintain the consistency of state data.

The execution layer does not determine the order of transactions; it only executes transactions and records the state changes after transaction execution. There are two forms of recording: one is to record all state changes in the form of blocks, and the other is to record the current state in the database. At the same time, the execution layer is also the entry point for transactions, storing transactions that have not yet been packaged into blocks in the transaction pool. If other nodes need to obtain block, state, and transaction data, the execution layer will send this information through the p2p network.

For the execution layer, there are three core modules: computation, storage, and network. Computation corresponds to the implementation of the EVM, storage corresponds to the implementation of ethdb, and the network corresponds to the implementation of devp2p. With this overall understanding, one can delve into understanding each sub-module without getting lost in specific details.

07\Ref

[1]https://ethereum.org/en/what-is-ethereum/

[2]https://epf.wiki/#/wiki/protocol/architecture

[3]https://clientdiversity.org/#distribution

[4]https://github.com/ethereum/devp2p

[5]https://github.com/ethereum/execution-specs

[6]https://github.com/ethereum/consensus-specs

·END·

Content | Ray

Editing & Formatting | Huanhuan

Design | Daisy

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。