3.3 Zytron Kit

3.3.1 Sovereign Rollup for Data 

3.3.1.1 Sequencer

Sequecner是Layer2系统中决定交易顺序的重要组件，是整个系统入口的第一个组件。Sequencer负责将内存池中的交易排序，并打包形成Layer2的区块。并将Layer2的区块按照顺序打包为Batch。后续的交易执行，交易处理等功能，都是基于Sequencer产生的区块顺序执行。

用户传输到Zytron上的交易，会优先被Sequencer进行排序，确定一个全局顺序。这个顺序的确定由去中心化排序器决定。去中心化排序器只会执行交易排序以及基础的交易签名验证工作，不会执行具体的交易，更不会运行智能合约。这也就意味着Sequencer无法打包产生完整的交易receipt，仅仅只是将交易的排序组成一组Batch交由Zytron的交易分片服务完成。

具体的打包流程如下：

1. Sequencer的各个节点使用不会进行P2P的内存池，发送给这个节点的交易只会在本地进行打包。Sequecer节点每隔固定时间打包一次交易，形成一个交易区块。

2. 该交易区块内的交易会被构造为一颗Merkle树。其中Merkle的根在Sequener的P2P网络中广播。这个广播过程只需要广播Merkle根，而无需要广播完整的交易体。通过聚合交易块中的签名进行验证，进一步减少了数据量。

3. Sequencer打包出来的交易区块具体数据将会提交给外部DA。为了防止 DA 中的确认周期过长而导致延迟，Sequencer将数据临时提交至“弱”DA上。

4. Sequencer产生的交易区块会交由Sequcner的PBFT共识进行进一步打包为Batch。这个Batch会被最终递交给后续的服务分片中进行具体的交易合约执行。

3.3.1.2 External DA

Zytron中使用了两类DA，分别为”强”DA与“弱“DA。所谓的”弱”DA用于Sequencer打包交易区块时记录交易区块的数据。这种DA不要求共识支持，仅仅为了快速的向Sequencer网络中的节点传递具体的交易区块信息。此类DA可以直接使用可以公开访问的Server，s3等中心化服务。这个“弱”DA主要支持Zytron的“pipeline”式交易执行优化策略。

“强”DA中记录的则是Sequencer打包后的Batch数据，这个数据成型后是要作为最终合约执行的输入。因此此交易的数据必须放置于可访问性强的系统中。此类数据强调数据的可访问性，往往会导致数据提交周期变长。因此强DA中的数据更多用于在固定时间点前对链上数据执行结果的验证。

强DA和弱DA的区别如下:

DA与Sequencer交互流程中，Sequencer间通过P2P采用主动推送的模式进行数据广播。这种数据广播主要为了快速的在共识前实现数据的广播，降低交易处理的延时。而具体的交易数据则需要Sequcner主动从对应的节点提取。

3.3.1.3 Sequencer Pending State

在游戏过程中，经常会有大量的交易频繁地发送到网络中。由于游戏低延时性的要求，要求等待交易的执行结果最终被链确认后再返回用户会导致用户游戏体验的急剧下降。因此用户将交易发送给Sequencer的时候，Sequencer会在本地维护一个Pending State，用户可以基于自己所连接的Sequeuncer交易节点，不断地拉取Pending状态，在交易最终被确认前提前发出新的交易。Sequencer中记录的Pending State会不断地与链上的最终状态同步，用于修正自己的Pending State。

3.3.2 ZK Rollup for Assets

资产不同于数据，资产有十分明显的价值属性，而且需要流动，因此，对于 layer3 中的资产需要进行单独的处理，将资产的安全性依赖于更加安全的 layer1/layer2 中，对此，我们设计了一套基于 zk rollup 的 assets 管理解决方案，用于 zytron kit 所发行的 layer3。

使用 zk-Rollups 进行资产管理：

L3 资产交易：

Merkle 树存储：我们将 L3 中产生的资产交易，以及与 L1/L2 source chain 产生的 deposit 和 withdraw 交易，均存放于一颗 Merkle 树中，该 Merkle 树 的每一个分支都会有 3 个 leaf，每一个 leaf 代表一个 output。

• UTXO 模型：通过采取 UTXO 模型的传输算法，我们促进了所有交易有效性检查的 zk 聚合，从而可以在 L1/L2 上立即进行验证。无需像 op一样有 7 天的挑战期。

交易类型和流程：

• Deposit： 存在于source chain上，因此无需将其签名写入电路，因为它是完全公开的public inputs。

• Transfer：涉及提交inputs和outputs的交易的有效性，并在电路中嵌入用户签名来验证交易。L3 传输交易采用field友好的签名算法，以实现电路内的高效证明。

• Withdraw：与 Transfer 算法同样处理，只是该 output 的接受者会被指定成 source chain 对应的账号格式，可以参与 Merkle 树的证明，而且无法再被任何 input 所使用。

电路驱动的交易有效性：

• Leaf 证明和 Merkle Root 更新：Leaf 的变化会导致 Merkle Root 的更新。 这些更改的有效性在电路中得到了证明，减少了更新 Merkle Root 所需的链上计算。

• 提交到 source chain 上的 public inputs：包括 deposit 以及对应的 output， transfer 所关联的 inputs 和 outputs， withdraw 所产生的 inputs 和 特殊 outputs，以及最终的 Merkle tree root，所有资产交易的有效性都通过 ZKP 进行证明。

UTXO 结构：

• 资产类型和金额：两者都是u256类型，能够处理ERC20代币类型和ERC721 NFT类型。

• Source Chain 上的合约映射：只需要在 source chain 的合约中做好对应的映射关系，就可以实现将资产桥接到L3，将资产的安全假设基于 source chain 上，减少对L3安全性的依赖。

• 实施计划包括创建图表，直观地解释处理为 ZK inputs 和 outputs 的 UTXO 交易、从旧 Merkle 根到新 Merkle 根的过渡，以及将资产类型和金额与代币和 NFT 类型相关联的映射表，以及映射关系 。 这种结构化方法利用底层区块链层的安全功能，增强了L3资产管理的理解和透明度。

3.3.3 服务分片

Zytron设计目的在于实现低延时的链上游戏服务，因此为了实现这个目的，Zytron上运行的合约会通过将链节点的数据服务分片的方式执行。

3.3.3.1 基于 Kademlia 算法的节点数据分片

Kademlia是一种分布式哈希表算法，使用节点ID的异或运算测量网络中的节点距离。利用这个距离的规定，可以以此为基准进行节点分片计算，网络中节点发现等功能。原本Kademlia设计用于P2P网络的数据存储和节点发现方案。而在Zytron中，利用kademlia算法的节点规则，可以仅通过计算，就完成对服务分片的计算，降低系统中网络请求的数量。

Zytron 会将具体执行合约验证的节点通过P2P网络连接起来。节点间的寻址利用结构化Kademlia算法完成。同时，网络中合约的执行过程也会按照Kademlia的节点距离进行分片，将指定合约的的执行按照Kademlia的距离规则分散在整个Zytron网络的执行节点中执行。要成为 Zytron 中的执行节点，需要完成如下的流程：

• Zytron中每一个执行节点均可以接受来自Sequencer发送过来的交易区块，并且会从Zytron所依赖的上层区块链读取经过共识过的Batch，以及从DA中读取具体的Batch数据。

• 节点利用自己的的私钥生成一个160位的节点id。

• 每一个节点需要在上层区块链中进行注册，注册后上层区块链的合约会记录当前节点的ID。

• 节点加入网络后用过P2P协议发起一次对自己的查询操作，使得自己能够被更新到相关邻居的路由表中。

• 向周边节点发起状态数据同步请求。

• 同步完成后，向上层区块链注册同步成功的结果（自己所记录的数据状态的Merkle Root）。

当节点成为执行节点之后，节点会向周围数据发起状态数据同步请求，这个数据同步请求会将周边节点中，账户地址距离自己节点ID最近的相关数据，余额，nonce等数据同步至自己的存储中。

3.3.3.2 地址状态组

Zytron 中的执行节点不会记录全局状态，每个执行节点只会记录距离自己最近的地址相关的存储信息。而为了保证节点离线后，执行节点依旧能够正常验证交易。执行节点每次从与其最近的地址同步存储数据时，便会加入或者创建一个地址状态组。每一个地址状态组中存在8个成员，他们使用 BFT 算法在本地更新地址的状态。

地址状态组初始化算法:

当一笔交易被发送到 Zytron 节点中执行时，地址状态组会基于交易记录的Address Space将多个地址状态组联合起来，执行智能合约，并更新这个交易中的状态，用以实现对交易状态的更新。此外，由于 Zytron 具有Address Space Access List 和 Key Space Access List等功能，因此可以在合约执行之前完成地址状态组的合并，而无需等待合约执行再进行合并。

当某一个节点离线后，相关的地址节点组会将该节点剔除，并向上层区块链记录此退出行为。

3.3.3.3 交易 Space Access List 字段

由于 Zytron 中节点的数据被分片存储，因此执行节点中不太存在完整的全局状态。即便交易执行过程中地址状态组会联合执行交易，也很难动态的不断增加连接，执行交易等操作。因此为了保证数据能够正常的分片处理计算，交易发送至链上时，需要附加这个交易会更新的State Change信息，这个信息被称为Space Access Limit。这些信息包括交易会变更的Balance， Nonce，Storage信息。节点收到交易后，会按照Space Access Limit 在节点本地构造满足合约执行条件的状态放置于交易“to”地址所在的地址状态组节点中。当节点执行过程中发现访问的数据超过了Space Access List 中记录的数据范围，或者与其中的状态变化有差异，则会判定交易失败。

而每一个 Batch 执行结束后，地址状态组都会向上层链提交一次 State Root，以及相关的 zkproof 或 Fraud Proof。

3.3.3.4 Key Space 估算

对于大部分 EVM 类或者全状态类合约执行引擎，默认是不存在Space Access List字段，在智能合约执行结束之前，没有任何人可以知道交易的执行状态。因此为了辅助客户端能够正常的标注出此字段，Zytron 提供了Space Access Limit估算功能。此功能会将发送的交易，基于指定的状态执行智能合约，并基于在合约执行过程中访问的数据和产生的数据构造Space Access Limit。

3.3.4 定制网络

目前区块链的底层 P2P 网络，很多项目会基于 libp2p或者自定义的库，这些库都是基于区块链而产生，最重要的特性是将区块和交易进行快速传播，因此特别注重 broadcast 算法，比如 gossip算法。用于保证消息能够在较短的时间内广播到全网。但是游戏的场景是有限的节点之间的消息传输，甚至只涉及到两个节点，而且要求这个连接是稳定高效的，不会被随意断开，或者在断开后能够保证迅速恢复。而区块链的 P2P 库并不具备这些特点。因此，我们针对 P2P 网络库进行了定制化开发。

首先就是针对网络传输协议，在高频操作的游戏中，我们必须要保证网络的延迟极低，假设是 60 帧的游戏，那么每秒更新 60 次，就要求延迟必须低于 16ms 才可以无掉帧和避免卡顿。对此，我们不仅需要对客户端的性能进行优化，也需要对占大部分时间的网络传输进行优化，传统 P2P 网络，一般采取 TCP的传输协议，但是 TCP包含 可靠重传，并且具有拥塞机制，如果网络中流量很大，就会导致 TCP 的传输时间被延长，无法满足游戏的要求，因此我们修改了一个基于 KCP传输协议的 p2p 网路库，KCP 基于 UDP实现。KCP是一个快速可靠协议，能以比 TCP 浪费10%-20%的带宽的代价，换取平均延迟降低 30%-40%，且最大延迟降低三倍的传输效果。KCP是纯算法实现，并不负责底层协议（如UDP）的收发，需要使用者自己定义下层数据的发送方式，以 callback的方式提供给 KCP。甚至时钟都需要外部传递进来，内部不会有任何一次系统调用。

为了满足节点连接的稳定性，我们针对 P2P 核心的寻址算法进行了优化，采取基于双重 DHT 下的稳定 P2P 网络结构，一层使用节点的 peer id，进行前 160 bit 下的亦或 (xor) 距离下的 kademlia 算法，并保持该 dht 的 bucket 保持在 8，足够应对网络中的连接和波动，同时使用 stable kademlia来维持网络节点的进出所引起的 table 波动。另一层采取 socket ip address 的距离算法，使用 ip 进行物理位置的远近，这个的优势是保证，如果两个节点无法直接连接，比如都存在于局域网中，而且受限于 ISP设备是 Port-Restricted Cone 或者 Symmetric，那么将无法通过 NAT和 hole punching 直接发起连接的时候，可以使用 relay 算法，借助第三个节点，实现稳定的连接，那么就要求第三个节点物理距离两者不能太远，用于提高传输效率和减少时间。

3.3.5 Zytron chain

3.3.5.1 Web3 兼容接口

Zytron 使用了多种优化技术来降低交易的延迟，但这些优化技术导致了链的接口和数据格式与原始的Web3接口产生了较大差异。因此为了保证开发者一致的用户体验，Zytron提供了两套接口。第一套是Zytron专有的接口，可以较好的利用Zytron优化技术以获得更低的交易延时。而为了保证开发者生态的一致性，Zytron还会封装出一套Web3兼容接口，这套接口中，将Web3 接口中的Pending State转换为Pending相关的查询，由独立的Web3兼容接口负责数据寻址，交易Space Access List估算等工作。

3.3.5.2 多执行引擎支持

Zytron 本质上是一个交易执行引擎，其设计目的在于降低交易执行的延时，增大网络的TPS。但是在设计中并未限定合约执行引擎的种类，目前设计中允许使用UTXO交易模型与EVM合约引擎。随着更多的需求的引入，Zytron可以介入更多的执行引擎，以实现多样化的应用场景。甚至基于需求的不同，Zytron不同的地址状态组可以使用不同的执行引擎。例如，利用Zytron中的代币可以使用UTXO模式，避免在交易并发执行时导致的问题，而具体的合约交易使用EVM模型，从而避免gas结算时交易依赖问题等。

3.3.5.3 Zero Gas

ERC4337 是一个以太坊标准，它提出了一个无需修改现有层一基础架构的方法，允许创建 "账户抽象钱包"。这种钱包的交易可以由任何人发送到区块链上，而费用可以由第三方支付。这意味着用户可以执行交易而不必用ETH来支付交易费用或代付手续费。

Zytron原生支持EIP4337的账户抽象钱包，利用账户抽象钱包，Zytron会对符合规则的账户提供豁免交易手续费的功能。此功能直接由Sequencer在交易接收时直接进行转换，实现了0gas的服务功能。

3.3.5.4 Cross-chain Bridge

Zytron 的分片执行模式，使得链与上层区块链可以关联到一个具体的地址状态组中。因此，在这个特殊的地址状态组中，Zytron会支持一种特殊的deposit交易。这种交易从上层区块链派生而来，用于可以将上层区块链锁定的Token在Zytron中mint出来。