3.3 Zytron Kit

3.3.1 Sovereign Rollup for Data

3.3.1.1 Sequencer

The Sequencer is an important component that determines the order of transactions in the Layer2 system and is the first component at the entry point of the entire system. The Sequencer is responsible for sorting transactions in the memory pool and packaging them into Layer2 blocks. It then packages the Layer2 blocks in order into Batches. Subsequent transaction execution and processing functions are based on the block order generated by the Sequencer.

Transactions sent by users to Zytron will be prioritized by the Sequencer for sorting to determine a global order. This order is determined by a decentralized sorter. The decentralized sorter only performs transaction sorting and basic transaction signature verification, without executing specific transactions or running smart contracts. This means that the Sequencer cannot package complete transaction receipts; it merely organizes the transaction order into a Batch for Zytron's transaction sharding service to complete.

The specific packaging process is as follows:

1. Each node of the Sequencer uses a memory pool that does not perform P2P operations; transactions sent to this node will only be packaged locally. The Sequencer nodes package transactions at fixed intervals to form a transaction block.

2. The transactions within this transaction block will be constructed into a Merkle tree. The Merkle root is broadcasted in the Sequencer's P2P network. This broadcasting process only requires broadcasting the Merkle root, without needing to broadcast the complete transaction body. By aggregating the signatures in the transaction block for verification, the data volume is further reduced.

3. The specific data of the transaction block packaged by the Sequencer will be submitted to an external DA. To prevent delays caused by long confirmation cycles in the DA, the Sequencer temporarily submits the data to a "weak" DA.

4. The transaction block generated by the Sequencer will be further packaged into a Batch by the Sequencer's PBFT consensus. This Batch will be ultimately submitted to subsequent service shards for specific transaction contract execution.

3.3.1.2 External DA

Zytron uses two types of DAs, namely "strong" DA and "weak" DA. The so-called "weak" DA is used to record the data of the transaction block when the Sequencer packages it. This type of DA does not require consensus support and is only for quickly transmitting specific transaction block information to nodes in the Sequencer network. Such DAs can directly use publicly accessible servers, S3, and other centralized services. This "weak" DA mainly supports Zytron's "pipeline" transaction execution optimization strategy.

The "strong" DA records the Batch data packaged by the Sequencer, which is to be used as the final input for contract execution. Therefore, the data of this transaction must be placed in a highly accessible system. This type of data emphasizes accessibility, which often leads to longer data submission cycles. Therefore, data in the strong DA is more used for verifying the results of on-chain data execution before a fixed point in time.

The differences between strong DA and weak DA are as follows:

In the interaction process between DA and Sequencer, Sequencers use a proactive push model for data broadcasting through P2P. This data broadcasting is mainly to quickly achieve data broadcasting before consensus, reducing transaction processing delays. The specific transaction data needs to be actively extracted by the Sequencer from the corresponding nodes.

3.3.1.3 Sequencer Pending State

During the gaming process, a large number of transactions are frequently sent to the network. Due to the low latency requirements of the game, waiting for the execution results of transactions to be confirmed on-chain before returning to users would lead to a sharp decline in user gaming experience. Therefore, when users send transactions to the Sequencer, the Sequencer maintains a Pending State locally, allowing users to continuously pull the Pending status based on the Sequencer transaction node they are connected to and to issue new transactions in advance before the transaction is ultimately confirmed. The Pending State recorded in the Sequencer will continuously synchronize with the final state on-chain to correct its own Pending State.

3.3.2 ZK Rollup for Assets

Assets are different from data; assets have very obvious value attributes and need to be liquid. Therefore, assets in layer3 need to be handled separately, relying on the security of the more secure layer1/layer2. To this end, we have designed a zk rollup-based asset management solution for the layer3 issued by the Zytron kit.

Using zk-Rollups for asset management:

L3 Asset Transactions:

Merkle Tree Storage: We store the asset transactions generated in L3, as well as the deposit and withdraw transactions generated with the L1/L2 source chain, in a Merkle tree. Each branch of this Merkle tree will have 3 leaves, with each leaf representing an output.

• UTXO Model: By adopting the UTXO model for transfer algorithms, we facilitate zk aggregation of all transaction validity checks, allowing for immediate verification on L1/L2 without a 7-day challenge period like OP.

Transaction Types and Processes:

• Deposit: Exists on the source chain, so there is no need to write its signature into the circuit, as it is completely public inputs.

• Transfer: Involves submitting the validity of transactions with inputs and outputs, embedding user signatures in the circuit to verify transactions. L3 transfer transactions use field-friendly signature algorithms for efficient proof within the circuit.

• Withdraw: Processed similarly to the Transfer algorithm, except that the recipient of the output is designated as the corresponding account format on the source chain, can participate in the Merkle tree proof, and cannot be used by any input.

Circuit-Driven Transaction Validity:

• Leaf Proof and Merkle Root Update: Changes in Leaves will lead to updates in the Merkle Root. The validity of these changes is proven in the circuit, reducing the on-chain computation required to update the Merkle Root.

• Public Inputs Submitted to the Source Chain: Include deposits and corresponding outputs, inputs and outputs associated with transfers, inputs and special outputs generated by withdrawals, and the final Merkle tree root. The validity of all asset transactions is proven through ZKP.

UTXO Structure:

• Asset Type and Amount: Both are of u256 type, capable of handling ERC20 token types and ERC721 NFT types.

• Contract Mapping on the Source Chain: By establishing the corresponding mapping in the contract on the source chain, assets can be bridged to L3, basing the security assumptions of the assets on the source chain, reducing reliance on L3 security.

• The implementation plan includes creating charts to visually explain the processing of UTXO transactions as ZK inputs and outputs, the transition from old Merkle root to new Merkle root, and the mapping table that associates asset types and amounts with token and NFT types, as well as the mapping relationships. This structured approach leverages the security features of the underlying blockchain layer, enhancing the understanding and transparency of L3 asset management.

3.3.3 Service Sharding

The design purpose of Zytron is to achieve low-latency on-chain gaming services. To achieve this goal, contracts running on Zytron will execute by sharding the data services of the chain nodes.

3.3.3.1 Node Data Sharding Based on Kademlia Algorithm

Kademlia is a distributed hash table algorithm that measures the distance between nodes in the network using the XOR operation on node IDs. By utilizing this distance specification, node sharding calculations and node discovery functions can be performed. Originally, Kademlia was designed for data storage and node discovery solutions in P2P networks. In Zytron, the rules of the Kademlia algorithm can be used to complete service sharding calculations through computation alone, reducing the number of network requests in the system.

Zytron connects specific nodes that execute contract verification through the P2P network. Addressing between nodes is accomplished using a structured Kademlia algorithm. Meanwhile, the execution process of contracts in the network will also be sharded according to the node distances of Kademlia, distributing the execution of specified contracts across the execution nodes of the entire Zytron network according to Kademlia's distance rules. To become an execution node in Zytron, the following process must be completed:

• Each execution node in Zytron can accept transaction blocks sent from the Sequencer and will read the Batch that has gone through consensus from the upper-layer blockchain, as well as read specific Batch data from the DA.

• Nodes generate a 160-bit node ID using their private keys.

• Each node needs to register on the upper-layer blockchain, and after registration, the contract on the upper-layer blockchain will record the current node's ID.

• After joining the network, the node initiates a query operation on itself via the P2P protocol, allowing itself to be updated in the routing tables of relevant neighbors.

• Initiate status data synchronization requests to surrounding nodes.

• After synchronization is complete, register the successful synchronization result (the Merkle Root of the data state recorded by itself) on the upper-layer blockchain.

Once a node becomes an execution node, it will initiate status data synchronization requests to surrounding data. This data synchronization request will synchronize relevant data, balances, nonce, etc., from the surrounding nodes whose account addresses are closest to its own node ID into its storage.

3.3.3.2 Address State Group

Execution nodes in Zytron do not record a global state; each execution node only records storage information related to the addresses closest to itself. To ensure that execution nodes can still verify transactions normally after going offline, each time an execution node synchronizes storage data from the nearest address, it will join or create an address state group. Each address state group contains 8 members, who use the BFT algorithm to locally update the state of the address.

Address State Group Initialization Algorithm:

When a transaction is sent to a Zytron node for execution, the address state group will combine multiple address state groups based on the Address Space of the transaction record, execute the smart contract, and update the state in this transaction to achieve the update of the transaction state. Additionally, since Zytron has features like Address Space Access List and Key Space Access List, the merging of address state groups can be completed before contract execution, without waiting for the contract execution to merge.

When a node goes offline, the relevant address node group will remove that node and record this exit behavior on the upper-layer blockchain.

3.3.3.3 Transaction Space Access List Field

Since the data of nodes in Zytron is stored in a sharded manner, there is generally no complete global state in execution nodes. Even if the address state group executes transactions jointly during transaction execution, it is challenging to dynamically increase connections and execute transactions. Therefore, to ensure that data can be processed and computed normally in a sharded manner, when a transaction is sent to the chain, it needs to attach the State Change information that this transaction will update, known as Space Access Limit. This information includes the Balance, Nonce, and Storage information that the transaction will change. After receiving the transaction, the node will construct a state that meets the contract execution conditions based on the Space Access Limit and place it in the address state group node corresponding to the "to" address of the transaction. If the node discovers that the accessed data exceeds the data range recorded in the Space Access List or has discrepancies with the state changes, the transaction will be deemed failed.

After each Batch execution is completed, the address state group will submit a State Root to the upper-layer chain, along with the relevant zkproof or Fraud Proof.

3.3.3.4 Key Space Estimation

For most EVM-like or full-state contract execution engines, the Space Access List field is generally absent. No one can know the execution state of the transaction before the smart contract execution is completed. Therefore, to assist clients in properly annotating this field, Zytron provides a Space Access Limit estimation feature. This feature will execute the smart contract based on the specified state with the sent transaction and construct the Space Access Limit based on the data accessed and generated during the contract execution.

3.3.4 Customized Network

Currently, many projects in the underlying P2P network of blockchain are based on libp2p or custom libraries. These libraries are generated based on blockchain and emphasize the rapid propagation of blocks and transactions, thus paying special attention to broadcast algorithms, such as gossip algorithms, to ensure that messages can be broadcasted across the network in a short time. However, the gaming scenario involves message transmission between limited nodes, sometimes only involving two nodes, and requires that this connection is stable and efficient, without being arbitrarily disconnected, or ensuring rapid recovery after disconnection. The P2P libraries of blockchain do not possess these characteristics. Therefore, we have customized the development of the P2P network library.

First, regarding the network transmission protocol, in high-frequency operations in games, we must ensure extremely low network latency. Assuming a 60-frame game, with updates 60 times per second, the latency must be below 16ms to avoid frame drops and stuttering. To achieve this, we need to optimize not only the performance of the client but also the network transmission, which occupies a significant portion of the time. Traditional P2P networks generally use TCP as the transmission protocol, but TCP includes reliable retransmission and has a congestion mechanism. If the network traffic is high, it can lead to extended transmission times, failing to meet the game's requirements. Therefore, we modified a P2P network library based on the KCP transmission protocol, which is implemented based on UDP. KCP is a fast and reliable protocol that can reduce average latency by 30%-40% at the cost of wasting 10%-20% of bandwidth compared to TCP, and it can achieve three times lower maximum latency. KCP is purely algorithmic and does not handle the sending and receiving of underlying protocols (such as UDP); users must define the sending method of lower-layer data and provide it to KCP via callbacks. Even the clock needs to be passed in externally, with no system calls made internally.

To ensure the stability of node connections, we optimized the core addressing algorithm of P2P, adopting a stable P2P network structure based on dual DHT. One layer uses the node's peer ID to perform the Kademlia algorithm under the XOR distance of the first 160 bits, keeping the DHT's bucket at 8, which is sufficient to handle connections and fluctuations in the network, while using stable Kademlia to maintain the table fluctuations caused by the entry and exit of network nodes. The other layer uses the distance algorithm based on socket IP addresses, utilizing IP to measure physical proximity. The advantage of this is to ensure that if two nodes cannot connect directly, for example, if they are both in a local area network and restricted by ISP devices as Port-Restricted Cone or Symmetric, they cannot initiate a direct connection through NAT and hole punching. In such cases, a relay algorithm can be used, leveraging a third node to achieve a stable connection, requiring that the third node is not too far from both to improve transmission efficiency and reduce time.

3.3.5 Zytron Chain

3.3.5.1 Web3 Compatible Interface

Zytron employs various optimization techniques to reduce transaction latency, but these optimizations have led to significant differences in the chain's interface and data format compared to the original Web3 interface. Therefore, to ensure a consistent user experience for developers, Zytron provides two sets of interfaces. The first set is Zytron's proprietary interface, which can better utilize Zytron's optimization techniques to achieve lower transaction latency. To ensure consistency in the developer ecosystem, Zytron will also encapsulate a Web3 compatible interface, which will convert the Pending State in the Web3 interface into Pending-related queries, with an independent Web3 compatible interface responsible for data addressing, transaction Space Access List estimation, and other tasks.

3.3.5.2 Multi-Execution Engine Support

Zytron is essentially a transaction execution engine designed to reduce transaction execution latency and increase network TPS. However, the design does not limit the types of contract execution engines. Currently, the design allows for the use of UTXO transaction models and EVM contract engines. As more demands arise, Zytron can incorporate more execution engines to achieve diverse application scenarios. Depending on different requirements, different address state groups in Zytron can use different execution engines. For example, tokens in Zytron can use the UTXO model to avoid issues during concurrent transaction execution, while specific contract transactions can use the EVM model to avoid dependency issues during gas settlement.

3.3.5.3 Zero Gas

ERC4337 is an Ethereum standard that proposes a method to create "account abstract wallets" without modifying existing layer one infrastructure. Transactions from such wallets can be sent to the blockchain by anyone, with fees paid by a third party. This means users can execute transactions without needing to pay transaction fees or cover service fees with ETH.

Zytron natively supports EIP4337's account abstract wallets, providing a feature to exempt transaction fees for compliant accounts. This feature is directly converted by the Sequencer when the transaction is received, achieving a 0 gas service function.

3.3.5.4 Cross-Chain Bridge

Zytron's sharded execution model allows the chain to be associated with a specific address state group in the upper-layer blockchain. Therefore, in this special address state group, Zytron will support a special deposit transaction. This transaction is derived from the upper-layer blockchain and is used to mint tokens locked on the upper-layer blockchain in Zytron.