Chainspace: Sharded Smart Contract Platform

When the blockchain enters the throughput bottleneck, the network can be sharded into multiple chains, blocks are generated by different consensus groups, and different block producers can process different transactions in parallel, thereby dispersing the transaction load and increasing the number of chains. overall throughput.

Two key points in designing such a sharded blockchain system are:

1. Design a protocol that can be used for cross-shard transactions to access and modify state atomically.

2. Enhance the transaction model so that smart contracts can be designed to run in parallel across shards.

The purpose of this design is to prevent transaction conflicts in different shards. In this case, a protocol is needed to achieve atomic cross-shard transactions.

Chainspace is a distributed ledger system that supports smart contracts. It allows nodes to process on-chain transactions in parallel through sharding. Therefore the main design goal is to allow atomic cross-shard transactions.

Specifically, Chainspace is a system that can scale indefinitely as the number of nodes increases, can tolerate Byzantine failures, and can be fully publicly audited.

Specifically, Chainspace proposes ‘object’, a UTXO-like data model for supporting atomic smart contracts, allowing parallel processing of transactions on different shards.

A new distributed atomic state confirmation protocol, called S-BAC, is proposed for sharding transactions of general smart contracts across multiple Byzantine nodes and properly coordinating these nodes to ensure security, availability, as well as vandal resistance.

Objects and Contracts

Chainspace objects are atoms that hold state in the system. All objects have cryptographically-based unique identifiers that are used to unambiguously refer to the object, and objects also have a type that contains the unique identifier of the smart contract that defines them, and the type name.

GcIhVh6652MTbQ2WHRnxo6m2dEIM86QO9zrnWOs3.png

In Chainspace, object state is immutable. But objects can be in two ‘meta’ states, active or inactive. Active objects can be manipulated through the process of smart contracts, while inactive objects are kept for auditing purposes.

Contracts are special types of objects that contain executable information about how to manipulate other types of objects defined by the contract. They define a set of initial objects that are created in Chainspace when the contract is first created. And as the contract logic runs, the result is finally output.

Each smart contract defines a checker. The checker is a pure function that takes the contract running process as well as input, output, reference and local variables as parameters. That is, get the contract data.

Although the Chainspace system ignores the process, it only relies on the checker. But applications can use procedures to create valid transactions.

The client packs enough information about the execution of these processes to allow Chainspace to safely serialize its execution so that all transactions, according to the relevant smart contract’s checker, are valid Atomic confirmation of the transaction.

Fragmented structure of the system

The Chainspace system consists of a network of basic nodes that manage valid objects and ensure that only valid transactions are submitted. A key design goal is to achieve scalability in terms of high transaction throughput and low latency. To this end, nodes are organized into shards, which manage the state of objects, ensure object validity, and record aborted or confirmed transactions.

In each shard, all honest nodes ensure that they are in complete agreement on whether to accept a transaction: whether the object is active or inactive at any moment, and the traces obtained from the contract they are involved in, according to the contract’s Checker, is it valid.

When crossing shards, nodes must ensure that the transaction is confirmed if all shards are willing to confirm the transaction, and if any shard decides to abort the transaction, the node must ensure that the transaction is rejected (or aborted due to the checker returning ‘false’ or the object being inactive) ). To meet these requirements, Chainspace implements the S-BAC protocol, a novel way to combine existing Byzantine

A protocol that confirms the basic concepts of consistency, and atomicity.

The consensus process of confirming (or aborting) transactions happens in parallel across different shards. For transparency and auditability, nodes in each shard periodically publish a signed blockchain consisting of checkpoints: shards make up blocks of evidence (yes

A Merkle tree) is added to the blockchain, with evidence including transactions processed in the current cycle, as well as signed commitments from other nodes.

trade

In Chainspace, a transaction is generated by the processes that make up the transaction, represented by a sequence of execution traces, and the interdependencies between them. These are computed and packaged by the end user’s client and contain all the information the checker needs to establish the correctness of the transaction.

A transaction is a data structure. In order to generate a set of traces that constitute a transaction, the user executes all the processes contained in the smart contract on the client side, based on input objects, references and local variables, and generates output objects and local variables for each process. return value. Therefore, the actual computation behind the transaction is performed by the user, and the trace forming the transaction already contains the output object and return value, as well as enough information to pass the smart contract’s checker to check its validity.

A contract procedure can call another smart contract’s transaction, giving it parameters and depending on its return value. This is achieved by passing variables to the smart contract’s checker.

In addition to executing transactions, Chainspace clients also need to read the state of objects to properly form transactions. Even if they are used as inputs or references to transactions, reads by themselves do not allow the system to accept an inconsistent state.

Therefore, any mechanism can be used to expose the state of an object to clients, and furthermore, any indexing mechanism can be used to allow clients to retrieve objects with specific characteristics faster.

privacy

Defining smart contract logic as a checker allows Chainspace to support privacy-friendly contracts by specific design. In such contracts, some information in the object is not public, but is instead committed using public key encryption, or using a secure commit scheme. Transactions contain only valid proof that the logic or invariants of the smart contract process are correctly applied or held individually, and can take the form of zero-knowledge proofs or succinct arguments of knowledge (SNARKs).

Scalability

Chainspace uses a sharding strategy to ensure scalability, with a public function that maps each object to a set of nodes that are collectively entrusted with managing the object’s state, ensuring its validity, recording transactions involving the object, and ultimately submitting at most one for use. A transaction that takes an object as input and makes the input object inactive. However, nodes can only record a transaction as confirmed if they are sure that all other nodes have, or are about to, record the same transaction by consuming these objects. This distributed algorithm is called an ‘intra-shard consensus algorithm’.

By combining Byzantine agreement and atomic confirmation agreement, Chainspace proposes Sharded Byzantine Atomic Confirmation (S-BAC) protocol, an intra-shard consensus algorithm for processing transactions under Byzantine and asynchronous conditions. in:

Byzantine agreement ensures that all honest members of a shard of size 3f + 1 can agree on a certain sequence of common operations, even if the shard contains f malicious nodes. Agreements also ensure that when an agreement is sought, a resolution or sequence of actions will ultimately be agreed upon. The consensus protocol is executed within each shard to coordinate all nodes. The MOD-SMART implementation of PBFT is used for state machine replication, thereby optimizing the number of communication steps.

The atomic commit protocol runs across all shards that manage the objects involved in the transaction. It requires that every shard needs to agree to confirm the transaction in order for the transaction to be confirmed; even if only one shard rejects the transaction, all ‘consent’ will be rejected.

In Chainspace, each transaction involves a fixed number of related nodes in the shards that manage its inputs and references. If the sets of related nodes between the two strokes do not intersect, then there is no conflict between them and can be executed in parallel or in any order.

However, if there is a common input object between two transactions, all nodes will only accept one of them. This process will be achieved through the S-BAC protocol. This process is only concerned with nodes managing conflicting transactions, so it is local and does not require global consensus.

PS: Chainspace is the technical principle of the modular blockchain Celestia. The above content is compiled and excerpted from the Celestia white paper.

Posted by:CoinYuppie,Reprinted with attribution to:https://coinyuppie.com/chainspace-sharded-smart-contract-platform/
Coinyuppie is an open information publishing platform, all information provided is not related to the views and positions of coinyuppie, and does not constitute any investment and financial advice. Users are expected to carefully screen and prevent risks.

Like (0)
Donate Buy me a coffee Buy me a coffee
Previous 2022-07-21 11:12
Next 2022-07-21 11:13

Related articles