Skip to content

Ethereum 1.0

date: 2023-02-04 last-updated: 2023-02-04

Overview

Consensus Mechanism

Ethereum 1.0 Proof Of Work

Existing Blockchain technology is working on the core concept of 'Proof Of Work' (POW). A proof-of-work (PoW) is a protocol that is difficult to compute but easy to verify. It can be verified in far less time than it took to compute in first place. The process involves scanning for a value that when hashed, (such as with SHA-256), the hash begins with a number of zero bits. The average work required is exponential in the number of zero bits required and can be verified by executing a single hash. In simple words, Proof of work is an expensive computation done by all miners to compete to find a number that, when added to the block of transactions, causes this block to hash to a code with certain rare properties. Finding such a rare number is hard (based on the cryptographic features of the hash function used in this process), but verifying its validity when it's found is relatively easy. One can take the challenge, the proof string and hash them together and check if the hash begins with a number of zero bits. This requires to apply the hash function just once and verify the output indeed has requisite numbers of 0's in front. If so, then the proof of work is considered valid under the application of that cryptographic hash function. Every block in the participating network should contain such rare number.

Proof Of Work

Block Structure from go-ethereum

// SealHash returns the hash of a block prior to it being sealed.
func (ethash *Ethash) SealHash(header *types.Header) (hash common.Hash) {
 hasher := sha3.NewLegacyKeccak256()
 
 rlp.Encode(hasher, []interface{}{
  header.ParentHash,
  header.UncleHash,
  header.Coinbase,
  header.Root,
  header.TxHash,
  header.ReceiptHash,
  header.Bloom,
  header.Difficulty,
  header.Number,
  header.GasLimit,
  header.GasUsed,
  header.Time,
  header.Extra,
 })
 hasher.Sum(hash[:0])
 return hash
}

Signing Mechanism

Transactions are signed using recoverable ECDSA signatures. This method utilises the SECP-256k1 curve. (see the Ethereum Yellow Paper Appendix F. Signing Transactions). go-ethereum utilizes the secp256k1 package which wraps the bitcoin secp256k1 C library. Signing is handled by the signer receives a request and produces a signature. Note, the produced signature conforms to the secp256k1 curve R, S and V values, where the V value will be 27 or 28 for legacy reasons, if legacyV==true.

Code Review

Signing

  • bls12381: BLS12-381 is a pairing-friendly elliptic curve.
  • bn256: Package bn256 implements the Optimal Ate pairing over a 256-bit Barreto-Naehrig curve. (insecure)
  • secp256k1: Package secp256k1 wraps the bitcoin secp256k1 C library.
  • signer: sign receives a request and produces a signature. Note, the produced signature conforms to the secp256k1 curve R, S and V values, where the V value will be 27 or 28 for legacy reasons, if legacyV==true.

Consensus

  • consensus
    • algorithm: hashimoto aggregates data from the full dataset in order to produce our final value for a particular header hash and nonce.
    • api: API's include GetWork, SubmitWork, SubmitHashRate and GetHashRate.
    • ethhash: Package ethash implements the ethash proof-of-work consensus engine.
    • sealer: Seal implements consensus.Engine, attempting to find a nonce that satisfies the block's difficulty requirements.
  • Additional Consensus Engines
    • beacon: Beacon is a consensus engine that combines the eth1 consensus and proof-of-stake algorithm. There is a special flag inside to decide whether to use legacy consensus rules or new rules. The transition rule is described in the eth1/2 merge specEIP-3675. The beacon here is a half-functional consensus engine with partial functions which is only used for necessary consensus checks. The legacy consensus engine can be any engine implements the consensus interface (except the beacon itself).
    • clique: Package clique implements the proof-of-authority consensus engine.

Cryptographic Primitives

general primitives
  • asm: Package asm provides support for dealing with EVM assembly instructions (e.g., disassembling them).
  • bitutil: Package bitutil implements fast bitwise operations.
  • bloombits: Package bloombits implements bloom filtering on batches of data.
  • forkid: Package forkid implements EIP-2124.
  • hexutil: Package hexutil implements hex encoding with 0x prefix. This encoding is used by the Ethereum RPC API to transport binary data in JSON payloads.
  • lru: Package lru implements generically-typed Least Recently Used(LRU) caches.
  • math: Package math provides integer math utilities.
  • mclock: Package mclock is a wrapper for a monotonic clock source
  • prque
    prque implements a priority queue data structure supporting arbitrary value types and int64 priorities.
  • trie: Package trie implements Merkle Patricia Tries.
hash functions
  • blake2b (go): Package blake2b implements the BLAKE2b hash algorithm defined by RFC 7693 and the extendable output function (XOF) BLAKE2Xb.
encryption
  • signify: signFile reads the contents of an input file and signs it (in armored format) with the key provided, placing the signature into the output file.ascii armored encryption
  • ecies: a hybrid encryption scheme
random number generators serilization/deserialization
  • RLP: Package rlp implements the RLP serialization format.(doc) The purpose of RLP (Recursive Linear Prefix) is to encode arbitrarily nested arrays of binary data, and RLP is the main encoding method used to serialize objects in Ethereum. The only purpose of RLP is to encode structure; encoding specific atomic data types (eg. strings, ints, floats) is left up to higher-order protocols. In Ethereum integers must be represented in big endian binary form with no leading zeroes (thus making the integer value zero equivalent to the empty string). RLP values are distinguished by a type tag. The type tag precedes the value in the input stream and defines the size and kind of the bytes that follow.
threading virtual machine
  • vm : Package vm implements the Ethereum Virtual Machine. The vm package implements one EVM, a byte code VM. The BC (Byte Code) VM loops over a set of bytes and executes them according to the set of rules defined in the Ethereum yellow paper.
compiler
  • compiler: Package compiler wraps the ABI compilation outputs. ParseCombinedJSON takes the direct output of a solc --combined-output run and parses it into a map of string contract name to Contract structs. The provided source, language and compiler version, and compiler options are all passed through into the Contract structs. The solc output is expected to contain ABI, source mapping, user docs, and dev docs. Returns an error if the JSON is malformed or missing data, or if the JSON embedded within the JSON is malformed.

References

Consensus Staking Additional