The Ethereum Classic (ETC) blockchain organizes information into blocks. These help improve performance and minimize storage requirements. Blocks can be divided into headers, transaction lists, and, uncle header lists. It is informative to also consider the following three alternative block element divisions: context, computation and consensus categories.
The context, or environment, of all ETC computations must be completely specified. Therefore, blocks contain block numbers, parent header hashes, dates and times. Parents of blocks are the preceding blocks:
Every block has a unique identifier equal to the number of past blocks. The first (genesis) block has an identifier of zero.
All block elements, except for the transaction and uncle header lists, form the headers. Every block contains the Keccak 256 hash of the header of its parent. This is partially for security reasons.
All blocks contain the date and time they were added to the blockchain. This is denoted by the number of seconds since 1970–01–01 00:00:00 UTC.
All ETC computations must be completely specified as well. Therefore, blocks contain transaction lists, transaction list hashes, transaction list gas requirements, transaction list state hashes, transaction receipt list hashes, and, transaction receipt list Bloom filters. It may seem problematic that blocks only contain hashes of states and receipts. This is acceptable because the blockchain contains sufficient information to repeat the entire history of the ETC world computer. Therefore, the blockchain implicitly contains all states and receipts:
Entities external to ETC submit jobs as transactions. Blocks contain lists of these transactions.
Blocks contain the Keccak 256 hashes of special trees formed from their transaction lists. This is partially for security reasons.
ETC resources are measured in units of gas. Blocks include the number of gas units required to execute their transaction lists.
The state refers to all the values in all the accounts. Blocks must specify the states after the transaction lists, and the related chores, have been executed. Therefore, blocks include the Keccak 256 hashes of special trees formed from these states.
Execution information for all transactions is included in receipts. These are used by search engines and other applications. Blocks contain the Keccak 256 hashes of special trees formed from their list of transaction receipts.
Bloom filters are binary strings used to quickly determine set membership with nominal storage requirements. Blocks contain Bloom filters for their sets of transaction receipt logs.
Mining is the process of creating and validating new blocks. This is referred to as mining because the participants (miners) are rewarded with newly created funds. The mining procedure is referred to as the consensus algorithm. This involves a race to find the proof of work information necessary to create new blocks. The block candidates that lose this race are referred to as the uncles since they are related to the parents. All information pertaining to the consensus algorithm must be specified. Therefore, blocks contain: miner extra data, miner addresses, miner validation helps, miner gas maxima, proof of work information, proof of work difficulty levels, uncle header lists, and, uncle header list hashes:
Miners can optionally include up to an additional 32 bytes in blocks they create. There are no further restrictions on this element.
Miners specify account addresses to receive mining rewards in the blocks they create.
Miners include values to speed up block validation. Blocks could in principle have been designed without these aids. However, some denial of service attacks are possible if block validation is too slow.
Blocks specify the maximum possible gas requirements of transaction lists. Miners can adjust these maxima by small amounts relative to the parents.
Miners can only add new blocks to the blockchain if they compute the proof of work information for those blocks. This proof of work information is included in the blocks.
The consensus algorithm automatically increases the difficulty level for finding proof of work information when new blocks are being added too quickly. Likewise, the difficulty level decreases when new blocks are being added too slowly. Blocks include their proof of work difficulty levels.
Blocks contain lists of uncle headers. This improves the security of the blockchain.
Blocks include the Keccak 256 hashes of their uncle header lists. This is partially for security reasons.
Considering these context, computation and consensus categories has hopefully been enlightening. Sometimes different perspectives can make all the difference.
You can contact me by clicking any of these icons:
I would like to thank IOHK (Input Output Hong Kong) for funding this effort.
This work is licensed under the Creative Commons Attribution ShareAlike 4.0 International License.