Shard chain
Overview
The core protocol of data sharding ensures that state transitions are valid through the proof of validity, which will ensure that certain rules are fulfilled. This set of rules is determined by a smart contract on the L1 chain, which will validate the proof of state transitions. This validation will check that each state transition is correct. This is achieved by using the ZK-SNARK circuit, which will ensure that all state transition rules are followed. Any validator must submit the proof in order to prove the correctness of the state transition computation.
The L2 chain consists of the collator, the validator, and the smart contract on the L1 chain.
Collator
The collator is responsible for collecting transactions submitted by users to the shard chain, checking the validity of the transactions, and packaging the valid transactions together to form a batch to generate a witness, which is handed over to the validator to generate the proof.
Validator
The validator is responsible for computing all state changes and calculating the ZK-SNARK proofs. The validator will be in charge of submitting the ZK-SNARK to the smart contract on the beacon chain for final validation, which will ensure the validity of the state transitions.
Smart Contract
responsible for shard chain governance, depositing assets onto the shard chain, withdrawing assets to the beacon chain, and verifying the finality of the shard chain blocks. The shard chain strictly inherits the security guarantee of the beacon chain.
Merkle Tree
A sparse Merkle tree is used to store the status data of all accounts and balances. This information is stored on the shard chain where users will sign transactions to spend their balances between accounts on the shard chain. These transactions on the shard chain are collected together to produce a batch. Afterward, the batch data is compressed by ZK-SNARK, which will prove that the state transitions of all these transactions on the shard chain are correct.
Data Availability
This batch of transactions is made public on the beacon chain in order to provide data availability for the protocol, which means that anyone can re-establish the state of the shard chain based on the data on the beacon chain. Therefore, there is no need to rely on a third party to provide or store this data. The finality of the transaction state will be guaranteed by the smart contract on the beacon chain, so the data security of the shard chain is fully equivalent to that of the beacon chain.
The system is composed of beacon chain and shard chain transactions. Beacon chain transactions are executed via smart contracts and affect the state tree of the shard chain. Shard chain transactions are executed exclusively on the shard chain and affect the state tree of the shard chain.
Beacon chain transactions are enforced by the collator in the protocol. Therefore, these types of transactions will always be executed at some time.
State tree
A sparse Merkle tree is used to represent the entire ZK-Rollup state identified by its root.
Data Types
AccountId: Account unique identifier on the shard chain (32 bits)
EthAddr: Ethereum address (160 bits)
Publickey: Account public key on the shard chain (160 bits)
Nonce: The total number of executed transactions on the sharded chain for the account (32 bits)
Signature：Indicates that the user is signing a transaction for a shard chain, which is used to avoid transaction replay. (512 bits)
TokenId: Token unique identifier on the shard chain (16 bits)
Balance: Token balance (128 bits)
TransactionAmount: Transaction amount (40 bits)
TransactionFee：Transaction gas fee (12 bits)
TransactionHash: Transaction unique identifier on the shard chain (32 bits)
SwapFee: Swap transaction fee (12 bits)
BlockHeight: The current number block in the shard chain (32 bits)
RootHash: Sparse merkle tree root hash (32 bits)
Floating Point Format (Float40)
A custom floating-point, 40-bit, internal encoding called Float40 has been adopted to encode large integers. This is done to save bits when posting L2 transactions.
Formula is as follows:
X=m×10^x
where:
x is integer value to encode.
m is mantissa (35 bits).
e is exponent (5 bits).
Shared Chain Subaccount Generation
There are two ways to create a shard chain account for an ethereum address.
Make a transfer to an address that does not yet exist in the shard chain.
Make a deposit to an address that does not yet exist in the shard chain.
Last updated
