github.com/dim4egster/coreth@v0.10.2/README.md (about)

     1  # Coreth and the C-Chain
     2  
     3  [Avalanche](https://docs.avax.network/learn/platform-overview) is a network composed of multiple blockchains.
     4  Each blockchain is an instance of a Virtual Machine (VM), much like an object in an object-oriented language is an instance of a class.
     5  That is, the VM defines the behavior of the blockchain.
     6  Coreth (from core Ethereum) is the [Virtual Machine (VM)](https://docs.avax.network/learn/platform-overview#virtual-machines) that defines the Contract Chain (C-Chain).
     7  This chain implements the Ethereum Virtual Machine and supports Solidity smart contracts as well as most other Ethereum client functionality.
     8  
     9  ## Building
    10  
    11  Coreth is a dependency of AvalancheGo which is used to implement the EVM based Virtual Machine for the Avalanche C-Chain. In order to run with a local version of Coreth, users must update their Coreth dependency within AvalancheGo to point to their local Coreth directory. If Coreth and AvalancheGo are at the standard location within your GOPATH, this will look like the following:
    12  
    13  ```bash
    14  cd $GOPATH/src/github.com/dim4egster/qmallgo
    15  go mod edit -replace github.com/dim4egster/coreth=../coreth
    16  ```
    17  
    18  Note: the C-Chain originally ran in a separate process from the main AvalancheGo process and communicated with it over a local gRPC connection. When this was the case, AvalancheGo's build script would download Coreth, compile it, and place the binary into the `qmallgo/build/plugins` directory.
    19  
    20  ## API
    21  
    22  The C-Chain supports the following API namespaces:
    23  
    24  - `eth`
    25  - `personal`
    26  - `txpool`
    27  - `debug`
    28  
    29  Only the `eth` namespace is enabled by default. 
    30  To enable the other namespaces see the instructions for passing the C-Chain config to AvalancheGo [here.](https://docs.avax.network/nodes/maintain/chain-config-flags/#c-chain-configs)
    31  Full documentation for the C-Chain's API can be found [here.](https://docs.avax.network/apis/qmallgo/apis/c-chain/)
    32  
    33  ## Compatibility
    34  
    35  The C-Chain is compatible with almost all Ethereum tooling, including [Remix,](https://docs.avax.network/build/tutorials/smart-contracts/deploy-a-smart-contract-on-avalanche-using-remix-and-metamask) [Metamask](https://docs.avax.network/build/tutorials/smart-contracts/deploy-a-smart-contract-on-avalanche-using-remix-and-metamask) and [Truffle.](https://docs.avax.network/build/tutorials/smart-contracts/using-truffle-with-the-avalanche-c-chain)
    36  
    37  ## Differences Between Avalanche C-Chain and Ethereum
    38  
    39  ### Atomic Transactions
    40  
    41  As a network composed of multiple blockchains, Avalanche uses *atomic transactions* to move assets between chains. Coreth modifies the Ethereum block format by adding an *ExtraData* field, which contains the atomic transactions.
    42  
    43  ### Avalanche Native Tokens (ANTs)
    44  
    45  The C-Chain supports Avalanche Native Tokens, which are created on the X-Chain using precompiled contracts. These precompiled contracts *nativeAssetCall* and *nativeAssetBalance* support the same interface for ANTs as *CALL* and *BALANCE* do for AVAX with the added parameter of *assetID* to specify the asset.
    46  
    47  For the full documentation of precompiles for interacting with ANTs and using them in ARC-20s, see [here](https://docs.avax.network/build/references/coreth-arc20s).
    48  
    49  ### Block Timing
    50  
    51  Blocks are produced asynchronously in Snowman Consensus, so the timing assumptions that apply to Ethereum do not apply to Coreth. To support block production in an async environment, a block is permitted to have the same timestamp as its parent. Since there is no general assumption that a block will be produced every 10 seconds, smart contracts built on Avalanche should use the block timestamp instead of the block number for their timing assumptions.
    52  
    53  A block with a timestamp more than 10 seconds in the future will not be considered valid. However, a block with a timestamp more than 10 seconds in the past will still be considered valid as long as its timestamp is greater than or equal to the timestamp of its parent block.
    54  
    55  ## Difficulty and Random OpCode
    56  
    57  Snowman consensus does not use difficulty in any way, so the difficulty of every block is required to be set to 1. This means that the DIFFICULTY opcode should not be used as a source of randomness.
    58  
    59  Additionally, with the change from the DIFFICULTY OpCode to the RANDOM OpCode (RANDOM replaces DIFFICULTY directly), there is no planned change to provide a stronger source of randomness. The RANDOM OpCode relies on the Eth2.0 Randomness Beacon, which has no direct parallel within the context of either Coreth or Snowman consensus. Therefore, instead of providing a weaker source of randomness that may be manipulated, the RANDOM OpCode will not be supported. Instead, it will continue the behavior of the DIFFICULTY OpCode of returning the block's difficulty, such that it will always return 1.
    60  
    61  ## Block Format
    62  
    63  To support these changes, there have been a number of changes to the C-Chain block format compared to what exists on Ethereum.
    64  
    65  ### Block Body
    66  
    67  * `Version`: provides version of the `ExtData` in the block. Currently, this field is always 0.
    68  * `ExtData`: extra data field within the block body to store atomic transaction bytes.
    69  
    70  ### Block Header
    71  
    72  * `ExtDataHash`: the hash of the bytes in the `ExtDataHash` field
    73  * `BaseFee`: Added by EIP-1559 to represent the base fee of the block (present in Ethereum as of EIP-1559)
    74  * `ExtDataGasUsed`: amount of gas consumed by the atomic transactions in the block
    75  * `BlockGasCost`: surcharge for producing a block faster than the target rate