Chain Research

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

Overview

Here we do a deep dive on individual chains with a focus on the following areas

• Consensus Mechanism
• Signing Algorithms Supported
• Light Client Support
• Gas Costs
• Settlement Time
• Codebases

Chain Economics

Following is an overview of the economics of sample chains. These chains are early candidates for the design and implementation of trustless bridging that we have been doing.

The above data is from Feburary 11th, 2023. Links are provided to get current information.

++ Polkadot TVL includes all parachains

+++ Cosmos TVL include all cosmos based networks

Chain Technology

Following is an overview of the consensus, signing and staking mechanisms for sample chains. These chains are early candidates for the design and implementation of trustless bridging that we have been doing.

The above data is from Feburary 11th, 2023. Links are provided to get current information.

Consensus Implementations

Consensus

• avalanche (go)
  • avalanche: a general avalanche instance that can be used directly to process a series of partially ordered elements.
  • snowball: a general snow instance that can be used directly to process the results of network queries.
  • snowman: a general snowman instance that can be used directly to process a series of dependent operations.
  • snowstorm: a snowball instance deciding between an unbounded number of non-transitive conflicts. After performing a network sample of k nodes, you should call collect with the responses.
  • Snowman++: congestion control for Snowman VMs: Snowman++ introduces a soft proposer mechanism which attempts to select a single proposer with the power to issue a block, but opens up block production to every validator if sufficient time has passed without blocks being generated.
  • Avalanche Warp Messaging (AWM): AWM enables Subnet Validators to collectively produce a BLS Multi-Signature that attests to the validity of an arbitrary message (e.g., transfer, contract data, etc.) that can be verified by any other Subnet.
• bsc (go)
  • 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 spec eip-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: Clique is the proof-of-authority consensus engine proposed to support the Ethereum testnet following the Ropsten attacks.
  • ethash: Ethash proof-of-work protocol (obsolete).
  • misc: includes code for eip-1559, DAO hard-fork extension to the header validity, VerifyForkHashes verifies that blocks conforming to network hard-forks do have the correct hashes and erifyGaslimit verifies the header gas limit according increase/decrease in relation to the parent gas limit.
  • parlia: Parlia is the consensus engine of BSC
• ethereum
  • Ethreum 2.0 Fork Choice
  • Paths toward single-slot finality: A look at how to improve Ethereum’s LMD GHOST + Casper FFG consensus.
    • lighthouse (rust): stores the actual block DAG in ProtoArrayForkChoice. - time is represented using Slot instead of UNIX epoch u64.
  • [proto_array]
    • lighthouse proto_array (rust): ProtoArray iterates backwards through the array, touching all nodes and their parents and potentially the best-child of each parent. The structure of the self.nodes array ensures that the child of each node is always touched before its parent.
  • SerDes: Serializer/Deserializer
    • lighthouse serde_utils (rust)
  • simple serialize
    • lighthouse ssz (rust): Provides encoding (serialization) and decoding(deserialization) in the SimpleSerialize (SSZ) format designed for use in Ethereum 2.0.
    • lighthouse ssz_derive (rust): Provides procedural derive macros for the Encode and Decode traits of the eth2_ssz crate.
    • lighthouse ssz_types (rust): Provides types with unique properties required for SSZ serialization and Merklization
    • prysm ssz.bzl (bazel): A rule that uses the generated pb.go files from a go_proto_library target to generate SSZ marshal and unmarshal functions as pointer receivers on the specified objects.
  • state_processing
    • lighthouse state_procesing (rust): State processing functions including block, slot and epoch functions.
  • compute_shuffled_index
    • lighthouse swap_or_not_shuffle (rust): Provides list-shuffling functions matching the Ethereum 2.0 specification.
  • [types]
    • lighthouse types (rust): Includes type definitions used in consensus including beacon_block_header, beacon_comittee, ,beacon_state, sync_comitte and more.
• harmony (go)
  • harmony consensus
• near (rust)
  • near nearcore
• polkadot (rust): code
  • aura
  • babe
  • beefy
  • grandpa
  • pow
  • additional primitives
    • common: Common utilities for building and using consensus engines in substrate.
    • slots: Primitives for slots-based consensus engines.
    • vrf: Primitives for VRF-based consensus engines. Schnorrkel-based VRF.
• polygon heimdall (go): Validator node for Matic Network. It uses peppermint, customized Tendermint. Here is where it sends validator updates to peppermint
  • polygon peppermint(go): Peppermint is a modified Tendermint. It is changed to make it compatible with Ethereum addresses and verifiable on Ethereum chain. (docs are here)
• tendermint tendermint (go)