Cell

Introduction to CELL Protocol

CELL is a privacy computing platform built on Non-Interactive Poof of Liveness (NIPoL) and Proof of Stake consensus mechanism (PoS), which can also build a decentralized heterogeneous cross-chain channel.

Why CELL?

The CELL network is a decentralized, highly secure, and strongly private open network. The main decentralized cross-chain platform enables anyone to freely participate in building decentralized cross-chain channels using idle devices through a fair proof-of-stake consensus mechanism and a non-interactive proof-of-survival mechanism, supporting stable, efficient as well as low-cost connections to assets in heterogeneous chains.

Design Goal

The goal is to design a cross-chain system that supports heterogeneous chains and has better compatibility than existing homogeneous cross- chains. The most famous homogeneous cross-chain is Polkadot, which targets asset and message cross-chaining, so the system is very complex and not easy to engineer. Asset cross-chaining is called teleportation on Polkadot, meaning that assets are destroyed at one end and mint at the other. The asset cross-chaining covered in CELL is different from Polkadot and is called mapping, meaning that the assets are locked at one end and minted at the other, as if a copy is replicated on another chain.

What is distributed private key management?

CELL uses a distributed private key management model. The asset mapping we mentioned earlier is essentially locking the assets, who manages the private key of the locked account? This is something we need to focus on, because whoever holds that account is in control of the cross- chain assets. There are many solutions to this problem, such as the use of multiple signatures, threshold signatures, and at the heart of this lies the trust mechanism of trusted committees (trusted third parties). If the choice of committees is too centralised, then there is a low cost of joint mischief and not enough decentralisation.

Then ensuring that the committee is chosen randomly, secure and fault- tolerant is key to the whole system. We refer to the collective that manages the cross-chain accounts as the holding committee. When the base of the committee is large enough, the holding selection is random enough, and the rights of the holding members are securely transferable, it can be considered to achieve a system that satisfies decentrality and is a highly available and secure cross-chain system.

The security of the committee involves computational security and storage security, computational security is guaranteed by the MPC algorithm, that is, during the computation, no node will get the complete private key, and storage security is guaranteed by the sealing of the TEE. Intel SGX provides two policies for encryption keys: MRENCLAVE (enclave identification) and MRSIGNER (signature identification). The Intel SGX provides two policies for encryption keys: MRENCLAVE and MRSIGNER.

The MPC protocol allows a set of parties to interact with each other in several rounds of communication to compute a function f and learn the output y = f(x1, x2, …, xn), where xi is the input to party i0. In this way, even if up to t parties are malicious (for some conspiracy tolerance t); they cannot learn the inputs of the other parties, i.e., they are kept secret.

CELL is roughly divided into two subsystems, the chain and the committee. The chain is responsible for producing blocks that can yield random numbers and all data is open and transparent, a distributed ledger. The committee is made up of devices with trusted hardware that provide distributed private key management services.

A key idea in designing the system, TEE, MPC, and blockchain have complementary properties. First, the blockchain is multi-copy and guarantees availability and persistence of state, whereas TEE does not guarantee availability (because hosts can terminate TEE on their own), nor does it provide reliable access to the network or persistent storage. Second, blockchains have very limited computational power because of consensus constraints that require all nodes to agree on state, whereas TEE incurs little overhead compared to native computation and provides trusted computation through remote authentication (off-chain computation). Further, blockchain is an open and transparent ledger and does not have the privacy of collaborative computation, while MPC protocol does not disclose any party’s input during computation and guarantees the privacy of node input, so it seems logical to use these three to construct a distributed private key management system.

However, integrating TEE with MPC and blockchain is a challenge. When the three are merging, subtle mistakes can occur. Several challenges are listed below.

The issue of the environment in which the commissioner node is running. Not limited to proving that the non-trusted environment, the committee logic is running in sgx and the code has not been tampered with.

Randomness in the selection of member nodes maximizes the cost of nodes to do evil.

Storage validity of the member node, proving that the individual’s private key fragment file is saved or removed as required.

Availability of the commissioner node, proving that the service to be linked is in SGX and preventing witch attacks.

Scalability of commissioner nodes, considering TEE code upgrades.

In the next parts we will touch on important topics, so stay with us and subscribe to our social networks so as not to miss anything!