|
| 1 | +--- |
| 2 | +title: MetaChain Consensus |
| 3 | +--- |
| 4 | + |
| 5 | +:::div{class="admonitions yellow"} |
| 6 | +Currently work in progress — this article/page is consider draft, the information reflected here might not be |
| 7 | +up-to-date. |
| 8 | +::: |
| 9 | + |
| 10 | +## Proof-of-? |
| 11 | + |
| 12 | +'Proof-of-' is often colloquially referred to as the consensus mechanism generally agreed upon between multiple actors |
| 13 | +for moving the chain forward. Given there is no disagreement between multiple actors, a consensus is achieved. Since its |
| 14 | +genesis, DeFiChain has used a Proof-of-Stake (PoS) consensus mechanism adapted from Bitcoin Core's original |
| 15 | +Proof-of-Work (PoW) implementation for moving the chain forward. |
| 16 | + |
| 17 | +```mermaid |
| 18 | +graph LR |
| 19 | +
|
| 20 | +n[UTXO Based Ledger] |
| 21 | +m[EVM Based Ledger] |
| 22 | +
|
| 23 | +subgraph "NativeChain (PoS)" |
| 24 | +n |
| 25 | +end |
| 26 | +
|
| 27 | +subgraph "MetaChain (PoA)" |
| 28 | +m |
| 29 | +end |
| 30 | +
|
| 31 | +n --Mint Block--> m |
| 32 | +n --Propogate Block--> m |
| 33 | +
|
| 34 | +``` |
| 35 | + |
| 36 | +For the purpose of describing the different DeFiChain consensus at play, NativeChain refers to the UTXO Bitcoin-based |
| 37 | +chain, while MetaChain refers to the EVM-based chain. |
| 38 | + |
| 39 | +### Proof-of-Stake (PoS) at NativeChain |
| 40 | + |
| 41 | +NativeChain utilizes a Proof-of-Stake (PoS) algorithm similar to Bitcoin Core's original Proof-of-Work (PoW) mining |
| 42 | +algorithm. Validators are selected in proportion to their quantity of holdings in the associated cryptocurrency. |
| 43 | + |
| 44 | +NativeChain uses the concept of Masternode for its PoS implementation. To run a Masternode on NativeChain, a staker must |
| 45 | +hold a minimum of 20,000 DFI. Masternodes on NativeChain participate in active transaction validations and block |
| 46 | +creations. Each staking node can perform only 1 hash per second, with the nonce from the Bitcoin Core PoW algorithm |
| 47 | +replaced by a staker's masternode ID. |
| 48 | + |
| 49 | +### Proof-of-Authority (PoA) at MetaChain |
| 50 | + |
| 51 | +The Proof-of-Authority (PoA) is a consensus method that gives a designated number of actors the power to validate |
| 52 | +transactions within the network. MetaChain validators are Masternodes appointed from the NativeChain group of |
| 53 | +validators. Running a Masternode on NativeChain allows the actor to validate transactions on the MetaChain network as |
| 54 | +they do on the NativeChain network. |
| 55 | + |
| 56 | +## MetaChain Consensus-lite Design |
| 57 | + |
| 58 | +Operating on a consensus-lite design via Proof-of-Authority (PoA), the MetaChain embeds each EVM Block on the |
| 59 | +NativeChain. It relies on NativeChain peer-to-peer networking for block propagation. Connectivity between NativeChain |
| 60 | +and MetaChain is established through JSON-RPC, secured within a trusted communication medium. |
| 61 | + |
| 62 | +### Block Creation |
| 63 | + |
| 64 | +When the NativeChain validator finds a valid hash, it will instruct the attached MetaChain node to mint a new block. The |
| 65 | +attached MetaChain node will mint a new block encoded |
| 66 | +with [SCALE CODEC](https://docs.substrate.io/reference/scale-codec/). The newly minted block will be next on top of the |
| 67 | +current tip, embedded into the NativeChain block index and propagated via NativeChain peer-to-peer networking. |
| 68 | + |
| 69 | +### Block Connecting |
| 70 | + |
| 71 | +MetaChain has no peer-to-peer (p2p) networking capability; encoded blocks are imported and propagated via the |
| 72 | +NativeChain p2p network. The encoded blocks are imported into MetaChain during NativeChain `connectBlock()`. MetaChain |
| 73 | +does its block validation separately and in addition to NativeChain's validation. Once validated and indexed on |
| 74 | +MetaChain, NativeChain will deem the entire block as valid during the `connectBlock()` subroutine. |
| 75 | + |
| 76 | +### Benefits of a consensus-lite Design |
| 77 | + |
| 78 | +Utilizing a consensus-lite design removes the usual complexity and problems that arise from a consensus-heavy design. |
| 79 | +Piggybacking on NativeChain, we isolate and concentrate consensus design decisions into the NativeChain. Rollback and |
| 80 | +fork resolutions become a non-issue on MetaChain as the NativeChain handles it. |
| 81 | + |
| 82 | +> ### Precedent for Innovation |
| 83 | +> |
| 84 | +> To set the precedent for innovation, MetaChain consensus is designed to be consensus-lite for continuous and |
| 85 | +> sustainable iterative development. MetaChain is designed to be operated as a parallel subnet of the NativeChain; it |
| 86 | +> utilizes the NativeChain consensus mechanism to move the chain forward, allowing more subchains to be abstracted and |
| 87 | +> added. |
0 commit comments