You are reading an excerpt from our free but shortened abridged report! While still packed with incredible research and data, for just $20/month you can upgrade to our FULL library of 50+ reports (including this one) and complete industry-leading analysis on the top crypto assets.
Becoming a Premium member means enjoying all the perks of a Basic membership PLUS:
- Full-length CORE Reports: More technical, in-depth research, actionable insights, and potential market alpha for serious crypto users
- Early access to future CORE ratings: Being early is sometimes just as important as being right!
- Premium Member CORE+ Reports: Coverage on the top issues pertaining to crypto users like bridge security, layer two solutions, DeFi plays, and more
- CORE report Audio playback: Don’t want to read? No problem! Listen on the go.
Fusion blockchain
Chainge is built on an Ethereum fork called Fusion. To Fusion’s credit, rather than waiting for Ethereum to solve its own Proof of Stake design, Fusion was operating a PoS network in the summer of 2019 along with other specific fit-for-purpose alterations. Because Fusion is an Ethereum fork, nearly all Ethereum-specific tools are compatible with Fusion. Important developer tooling, infrastructure, and user-facing products, such as the popular web wallet Metamask, can be simply modified to work with Fusion. Since Ethereum and Fusion addresses are identical, migrating from Ethereum to Fusion is a simple process.
Fusion represents a permutation on a Proof of Stake network with token rewards based on participating in staking via a Ticketed Proof of Stake (TPoS) consensus mechanism. TPoS involves buying tickets to potentially be given the right to generate the next block. It's essentially a lottery where “5,000 FSN purchases a ticket for a chance to win a block with their anonymous node”.
Fusion aims to facilitate interoperability between chains via a network of custodial wallets on various chains. When Fusion initially launched DCRM in 2019, it was in a beta test environment comprised of five organizations and 29 community nodes. Now, as of Q4 2022, Fusion has ~64 validators. While obviously headed in the right direction, the validator count remains well behind many PoS chains and could benefit from more total validators as well as geographic and hosting diversity.
Fusion’s Distributed Control Rights Management Approach
The Fusion Distributed Control Rights Management (DCRM) technology aims to solve some of the centralization concerns related to private key management via a “distributed key generation and signing algorithm.” Fusion was made with the backing of various academic cryptographers and involves technologies, such as Multi-Party Computation (MPC) and Threshold Signature Scheme (TSS).
MPC
Multi-party computation is a solution for securing data among several participants in a private manner. It allows many parties, each with their own private data, to verify the final computation without revealing their own secret portion of the data. Each participant in an MPC possesses a piece of confidential information. Typically, in the case of bridges, one entity owns one part of a cryptographic key that can move funds or change code.
MPCs are (generally) used when a bridging system has multiple and/or a permissionless relayer set and is looking to eliminate one bad actor as a single point of failure. MPCs shard a private key into many segments, with each individual possessing a portion of the private key. When signing a transaction, a subset of MPC nodes must independently sign the transaction and communicate it to the larger group.
Even if a bridging protocol has a limited quantity of relayer nodes, the relayers can be chosen at random from the pool of candidates to create the multi-party computing (MPC) group. To authorize a cross-chain transaction, the protocol can require a minimum number of relayers to come together and sign the message before any action can be taken. The greater the threshold of an MPC group, the less likely it is that relayer groups will collude.
MPC also guarantees that if a number of parties inside the group decide to disclose information or depart from the protocol's instructions during execution, the MPC will not allow them to coerce the honest parties into outputting an inaccurate result or leaking confidential information.
TSS
Threshold Signature Schemes (TSS) involve a subset of trusted nodes participating in key generation (and signature) events. MPC requires that more than one entity/node/validator is necessary to control the wallet's contents. TSS is a subset of MPC. TSS enables multiple entities to collaboratively generate a key and signature rather than just one party. After the key is generated, no single entity ever has access to the full key and can't sign without the cooperation of the others. TSS is comprised of two values: n/t, where n is the number of nodes required to generate a signature, and t is the total number of entities involved.
The benefits of TSS over simple multi-sig configurations, per the Fusion website:
- “Multisigs performs its cryptography on-chain, exposing details, such as the number of signers that weaken security.
- TSS signatures are treated as one signature on the blockchain, making costs of TSS signatures much cheaper.”
DCRM
DCRM attempts to create a decentralized custodian model that leverages multi-party sign-offs for smart contract transactions by allowing multiple nodes in a network to share access permissions for wallets or other sensitive information. The Fusion blockchain uses sharded storage of private keys in which the key is broken into parts and distributed across nodes in the network, such that the private key isn’t recoverable in any one place.
Fusion’s DCRM Alliance appears to be the primary MPC participant. Each Alliance member operates their own off-chain node that functions solely to maintain custody of assets during cross-chain bridging. With the combination of the Fusion chain and the Alliance, the protocol stores assets on the various external blockchains. When individuals wish to transfer their assets, the Fusion chain uses these external wallets to transfer the funds to the user. With different nodes managed by multiple individuals, there is no central authority, and no one member can act without consent from the others.
DCRM Alliance members. Source
However, TSS, and by extension DCRM, is only applicable in Proof of Authority (PoA) scenarios in which the total number of nodes (t) is fixed and known. This is not ideal, as PoA consensus mechanisms run counter to the open and permissionless ethos of blockchains and cryptocurrencies. While DCRM has created a trustless scenario among five participants in the Alliance, it's still a small and inflexible number of entities.
The ideal architecture would be a more adaptable, albeit complex system. Such a system would enable the nodes that are considered part "n" and "t" to increase/decrease based on the number of nodes joining the network while honoring the TSS ratio that’s been established.
