# 3.3 Zytron Kit

## 3.3.1 データのためのソブリンロールアップ

3.3.1.1 シーケンサー

シーケンサーはLayer2システムにおいて取引の順序を決定する重要なコンポーネントであり、システム全体の入口の最初のコンポーネントです。シーケンサーはメモリプール内の取引をソートし、Layer2のブロックを形成するためにパッケージ化します。そして、Layer2のブロックを順番にバッチとしてパッケージ化します。その後の取引の実行、取引処理などの機能は、シーケンサーが生成したブロックの順序に基づいて実行されます。

ユーザーがZytronに送信する取引は、シーケンサーによって優先的にソートされ、グローバルな順序が決定されます。この順序の決定は分散型ソーターによって行われます。分散型ソーターは取引のソートと基本的な取引署名の検証のみを実行し、具体的な取引を実行することはなく、スマートコントラクトを実行することもありません。これは、シーケンサーが完全な取引レシートをパッケージ化して生成できないことを意味し、単に取引の順序を組み合わせてバッチをZytronの取引シャーディングサービスに渡すだけです。

具体的なパッケージ化プロセスは以下の通りです：

1. シーケンサーの各ノードはP2Pを行わないメモリプールを使用し、このノードに送信された取引はローカルでのみパッケージ化されます。シーケンサーのノードは一定の時間ごとに取引をパッケージ化し、取引ブロックを形成します。

2. 取引ブロック内の取引はMerkleツリーとして構築されます。そのMerkleのルートはシーケンサーのP2Pネットワーク内でブロードキャストされます。このブロードキャストプロセスではMerkleルートのみをブロードキャストし、完全な取引体をブロードキャストする必要はありません。取引ブロック内の署名を集約して検証することで、データ量をさらに削減します。

3. シーケンサーがパッケージ化した取引ブロックの具体的なデータは外部DAに提出されます。DA内の確認周期が長すぎて遅延が発生するのを防ぐため、シーケンサーはデータを一時的に「弱い」DAに提出します。

4. シーケンサーが生成した取引ブロックは、シーケンサーのPBFTコンセンサスによってさらにバッチとしてパッケージ化されます。このバッチは、後続のサービスシャーディングに最終的に提出され、具体的な取引契約の実行が行われます。

3.3.1.2 外部DA

Zytronでは「強い」DAと「弱い」DAの2種類のDAが使用されています。いわゆる「弱い」DAは、シーケンサーが取引ブロックをパッケージ化する際に取引ブロックのデータを記録するために使用されます。このDAはコンセンサスのサポートを要求せず、シーケンサーのネットワーク内のノードに具体的な取引ブロック情報を迅速に伝達するためだけに存在します。この種のDAは、公開アクセス可能なサーバーやS3などの中央集権的サービスを直接使用できます。この「弱い」DAは、Zytronの「パイプライン」式取引実行最適化戦略を主にサポートします。

「強い」DAには、シーケンサーがパッケージ化した後のバッチデータが記録されます。このデータは、最終的な契約実行の入力として使用されるため、取引データはアクセス性の高いシステムに配置する必要があります。この種のデータはデータの可用性を強調し、しばしばデータ提出周期が長くなる原因となります。したがって、強いDAのデータは、特定の時点前にチェーン上のデータ実行結果の検証により多く使用されます。

強いDAと弱いDAの違いは以下の通りです：

DAとシーケンサーのインタラクションプロセスにおいて、シーケンサー間はP2Pを使用して能動的にデータをブロードキャストします。このデータブロードキャストは、コンセンサス前にデータを迅速にブロードキャストし、取引処理の遅延を低減するために主に行われます。具体的な取引データは、シーケンサーが対応するノードから能動的に取得する必要があります。

3.3.1.3 シーケンサーの保留状態

ゲームの過程では、大量の取引が頻繁にネットワークに送信されることがあります。ゲームの低遅延性の要求により、取引の実行結果がチェーンによって確認されるのを待ってからユーザーに返すことは、ユーザーのゲーム体験を急激に低下させることになります。したがって、ユーザーが取引をシーケンサーに送信する際、シーケンサーはローカルで保留状態を維持し、ユーザーは接続しているシーケンサーの取引ノードに基づいて保留状態を継続的に取得し、取引が最終的に確認される前に新しい取引を事前に発行することができます。シーケンサーに記録された保留状態は、チェーン上の最終状態と継続的に同期され、自身の保留状態を修正するために使用されます。

## 3.3.2 資産のためのZKロールアップ

資産はデータとは異なり、非常に明確な価値属性を持ち、流動性が必要です。したがって、Layer3の資産は個別に処理する必要があり、資産の安全性はより安全なLayer1/Layer2に依存する必要があります。これに対して、私たちはZytronキットが発行するLayer3のためのzkロールアップに基づく資産管理ソリューションを設計しました。

zk-Rollupsを使用した資産管理：

L3資産取引：

Merkleツリーのストレージ：私たちはL3で生成された資産取引と、L1/L2ソースチェーンで生成されたデポジットおよび引き出し取引をすべてMerkleツリーに保存します。このMerkleツリーの各ブランチには3つのリーフがあり、各リーフは1つの出力を表します。

• UTXOモデル：UTXOモデルの伝送アルゴリズムを採用することで、すべての取引の有効性チェックのzk集約を促進し、L1/L2上で即座に検証できるようにします。opのように7日間のチャレンジ期間を必要としません。

取引の種類とプロセス：

• デポジット：ソースチェーン上に存在するため、その署名を回路に書き込む必要はありません。これは完全に公開されたpublic inputsです。

• 転送：inputsとoutputsの取引の有効性を提出し、回路内にユーザー署名を埋め込んで取引を検証します。L3転送取引はフィールドフレンドリーな署名アルゴリズムを採用し、回路内での効率的な証明を実現します。

• 引き出し：転送アルゴリズムと同様に処理されますが、この出力の受取人はソースチェーンに対応するアカウント形式に指定され、Merkleツリーの証明に参加でき、他のinputで使用されることはありません。

回路駆動の取引有効性：

• リーフ証明とMerkleルートの更新：リーフの変化はMerkleルートの更新を引き起こします。これらの変更の有効性は回路内で証明され、Merkleルートの更新に必要なチェーン上の計算を削減します。

• ソースチェーンに提出されるpublic inputs：デポジットおよび対応する出力、転送に関連するinputsとoutputs、引き出しから生じるinputsと特別なoutputs、最終的なMerkleツリールートを含み、すべての資産取引の有効性はZKPによって証明されます。

UTXO構造：

• 資産の種類と金額：両者はu256型で、ERC20トークンタイプとERC721 NFTタイプを処理できます。

• ソースチェーン上の契約マッピング：ソースチェーンの契約内で対応するマッピング関係を適切に設定するだけで、資産をL3にブリッジすることができ、資産の安全仮定をソースチェーン上に基づけ、L3の安全性への依存を減らします。

• 実施計画には、ZK inputsとoutputsのUTXO取引を処理するための図表を作成し、古いMerkleルートから新しいMerkleルートへの移行、および資産の種類と金額をトークンとNFTタイプに関連付けるマッピングテーブルを作成します。この構造化されたアプローチは、基盤となるブロックチェーン層のセキュリティ機能を活用し、L3資産管理の理解と透明性を強化します。

## 3.3.3 サービスシャーディング

Zytronの設計目的は、低遅延のオンチェーンゲームサービスを実現することです。したがって、この目的を達成するために、Zytron上で実行される契約は、チェーンノードのデータサービスをシャーディングする方法で実行されます。

3.3.3.1 Kademliaアルゴリズムに基づくノードデータシャーディング

Kademliaは分散ハッシュテーブルアルゴリズムであり、ノードIDの排他的論理和（XOR）演算を使用してネットワーク内のノード間の距離を測定します。この距離の規定を利用して、ノードのシャーディング計算やネットワーク内のノード発見などの機能を基準にすることができます。元々KademliaはP2Pネットワークのデータストレージとノード発見のために設計されましたが、ZytronではKademliaアルゴリズムのノードルールを利用して、計算のみでサービスシャーディングの計算を完了し、システム内のネットワークリクエストの数を減らします。

Zytronは具体的に契約検証を実行するノードをP2Pネットワークで接続します。ノード間のアドレッシングは構造化されたKademliaアルゴリズムによって完了します。同時に、ネットワーク内の契約の実行プロセスもKademliaのノード距離に従ってシャーディングされ、指定された契約の実行がKademliaの距離ルールに従ってZytronネットワーク全体の実行ノードに分散して実行されます。Zytron内の実行ノードになるためには、以下のプロセスを完了する必要があります：

• Zytron内の各実行ノードは、シーケンサーから送信された取引ブロックを受け入れることができ、Zytronが依存する上位ブロックチェーンからコンセンサスされたバッチを読み取り、DAから具体的なバッチデータを読み取ります。

• ノードは自身のプライベートキーを使用して160ビットのノードIDを生成します。

• 各ノードは上位ブロックチェーンに登録する必要があり、登録後に上位ブロックチェーンの契約が現在のノードIDを記録します。

• ノードがネットワークに参加した後、P2Pプロトコルを使用して自身のクエリ操作を開始し、関連する隣接ノードのルーティングテーブルに更新されるようにします。

• 周辺ノードに状態データの同期リクエストを発信します。

• 同期が完了した後、上位ブロックチェーンに同期成功の結果（自身が記録したデータ状態のMerkleルート）を登録します。

ノードが実行ノードになると、ノードは周囲のデータに対して状態データの同期リクエストを発信します。このデータ同期リクエストは、周辺ノードのアカウントアドレスが自身のノードIDに最も近い関連データ、残高、nonceなどのデータを自身のストレージに同期します。

3.3.3.2 アドレス状態グループ

Zytron内の実行ノードは全体の状態を記録せず、各実行ノードは自身に最も近いアドレスに関連するストレージ情報のみを記録します。ノードがオフラインになった後も、実行ノードが取引を正常に検証できるようにするために、実行ノードは毎回最も近いアドレスからストレージデータを同期する際に、アドレス状態グループを追加または作成します。各アドレス状態グループには8つのメンバーが存在し、彼らはBFTアルゴリズムを使用してローカルでアドレスの状態を更新します。

アドレス状態グループの初期化アルゴリズム：

取引がZytronノードに送信されて実行されると、アドレス状態グループは取引記録のアドレススペースに基づいて複数のアドレス状態グループを統合し、スマートコントラクトを実行し、この取引内の状態を更新して取引状態の更新を実現します。さらに、ZytronはAddress Space Access ListやKey Space Access Listなどの機能を持っているため、契約実行前にアドレス状態グループの統合を完了でき、契約実行を待つ必要はありません。

あるノードがオフラインになると、関連するアドレスノードグループはそのノードを除外し、上位ブロックチェーンにこの退出行動を記録します。

3.3.3.3 取引スペースアクセスリストフィールド

Zytron内のノードのデータがシャーディングストレージされているため、実行ノードには完全なグローバル状態が存在しません。取引実行中にアドレス状態グループが共同で取引を実行する場合でも、動的に接続を増やしたり、取引を実行したりすることは非常に困難です。したがって、データが正常にシャーディング処理計算されることを保証するために、取引がチェーンに送信される際には、この取引が更新するState Change情報を追加する必要があります。この情報はSpace Access Limitと呼ばれます。これらの情報には、取引が変更するBalance、Nonce、Storage情報が含まれます。ノードは取引を受け取った後、Space Access Limitに従ってノードローカルで契約実行条件を満たす状態を取引「to」アドレスが所在するアドレス状態グループノードに配置します。ノードが実行中にアクセスするデータがSpace Access Listに記録されたデータ範囲を超えたり、その中の状態変化と異なることが判明した場合、取引は失敗と見なされます。

各バッチの実行が終了した後、アドレス状態グループは上位チェーンにState Rootと関連するzkproofまたはFraud Proofを提出します。

3.3.3.4 キースペースの推定

ほとんどのEVMクラスまたは全状態クラスの契約実行エンジンでは、デフォルトでSpace Access Listフィールドは存在せず、スマートコントラクトの実行が終了するまで、誰も取引の実行状態を知ることはできません。したがって、クライアントがこのフィールドを正常にマークできるようにするために、ZytronはSpace Access Limit推定機能を提供します。この機能は、送信された取引を基に指定された状態でスマートコントラクトを実行し、契約実行中にアクセスされたデータと生成されたデータに基づいてSpace Access Limitを構築します。

## 3.3.4 カスタムネットワーク

現在、ブロックチェーンの基盤となるP2Pネットワークの多くのプロジェクトはlibp2pやカスタムライブラリに基づいています。これらのライブラリはブロックチェーンに基づいて生成され、最も重要な特徴はブロックと取引を迅速に伝播させることです。そのため、特にブロードキャストアルゴリズム、例えばgossipアルゴリズムに重点を置いています。これは、メッセージが短時間で全ネットワークにブロードキャストされることを保証します。しかし、ゲームのシナリオは限られたノード間のメッセージ伝送であり、場合によっては2つのノードだけに関与し、この接続が安定して効率的であることが要求され、任意に切断されることはなく、切断後は迅速に回復できる必要があります。しかし、ブロックチェーンのP2Pライブラリはこれらの特徴を持っていません。したがって、私たちはP2Pネットワークライブラリのカスタマイズ開発を行いました。

まず、ネットワーク伝送プロトコルに関して、高頻度操作のゲームでは、ネットワークの遅延を極めて低く保つ必要があります。60フレームのゲームを仮定すると、1秒間に60回更新する必要があるため、遅延は16ms未満でなければなりません。これにより、フレームのドロップやカクつきを避けることができます。これに対処するために、クライアントの性能を最適化するだけでなく、時間の大部分を占めるネットワーク伝送を最適化する必要があります。従来のP2Pネットワークは一般的にTCPの伝送プロトコルを採用していますが、TCPは信頼性のある再送を含み、輻輳メカニズムを持っています。ネットワーク内のトラフィックが非常に多い場合、TCPの伝送時間が延長され、ゲームの要求を満たすことができなくなります。したがって、KCP伝送プロトコルに基づくp2pネットワークライブラリを修正しました。KCPはUDPに基づいて実装されています。KCPは迅速で信頼性のあるプロトコルであり、TCPの10%-20%の帯域幅を浪費する代わりに、平均遅延を30%-40%低下させ、最大遅延を3倍に低下させる伝送効果を実現します。KCPは純粋なアルゴリズム実装であり、基盤となるプロトコル（UDPなど）の送受信を担当せず、使用者が下層データの送信方法を定義し、コールバックの形でKCPに提供する必要があります。さらには、時計も外部から渡す必要があり、内部では一切のシステムコールが行われません。

ノード接続の安定性を確保するために、P2Pコアのアドレッシングアルゴリズムを最適化し、二重DHTに基づく安定したP2Pネットワーク構造を採用しました。一層はノードのpeer IDを使用し、最初の160ビットのXOR距離に基づくKademliaアルゴリズムを適用し、このDHTのバケットを8に保ち、ネットワーク内の接続と変動に十分に対応できるようにします。同時に、stable kademliaを使用してネットワークノードの出入りによるテーブルの変動を維持します。もう一層はソケットIPアドレスの距離アルゴリズムを採用し、IPを使用して物理的な位置の近さを測定します。この利点は、2つのノードが直接接続できない場合、例えば両方がローカルネットワークに存在し、ISPデバイスがポート制限コーンまたは対称的な場合、NATやホールパンピングを介して直接接続を開始できない場合に、リレーアルゴリズムを使用して第三のノードを介して安定した接続を実現できることです。この場合、第三のノードは物理的に両者から遠くない必要があり、伝送効率を向上させ、時間を短縮します。

## 3.3.5 Zytronチェーン

3.3.5.1 Web3互換インターフェース

Zytronは取引の遅延を低下させるために多くの最適化技術を使用していますが、これらの最適化技術により、チェーンのインターフェースとデータ形式は元のWeb3インターフェースと大きな差異が生じました。したがって、開発者に一貫したユーザー体験を保証するために、Zytronは2つのインターフェースを提供します。最初のセットはZytron専用のインターフェースであり、Zytronの最適化技術を利用してより低い取引遅延を得ることができます。一方、開発者エコシステムの一貫性を保証するために、ZytronはWeb3互換インターフェースをラッピングし、このインターフェースではWeb3インターフェースの保留状態を保留関連のクエリに変換し、独立したWeb3互換インターフェースがデータアドレッシング、取引スペースアクセスリストの推定などの作業を担当します。

3.3.5.2 複数の実行エンジンのサポート

Zytronは本質的に取引実行エンジンであり、その設計目的は取引実行の遅延を低下させ、ネットワークのTPSを増加させることです。しかし、設計において契約実行エンジンの種類は限定されていません。現在の設計ではUTXO取引モデルとEVM契約エンジンの使用が許可されています。より多くの要求が導入されるにつれて、Zytronは多様なアプリケーションシナリオを実現するために、より多くの実行エンジンに介入できます。要求の違いに基づいて、Zytronの異なるアドレス状態グループは異なる実行エンジンを使用できます。例えば、Zytron内のトークンを利用することでUTXOモードを使用し、取引の同時実行時に発生する問題を回避し、具体的な契約取引はEVMモデルを使用してガスの清算時に取引依存の問題を回避します。

3.3.5.3 ゼロガス

ERC4337はEthereumの標準であり、既存のLayer1インフラストラクチャを変更することなく「アカウント抽象化ウォレット」を作成する方法を提案しています。このウォレットの取引は誰でもブロックチェーンに送信でき、手数料は第三者が支払うことができます。これは、ユーザーが取引を実行する際にETHを使用して取引手数料を支払ったり、手数料を代わりに支払ったりする必要がないことを意味します。

ZytronはEIP4337のアカウント抽象化ウォレットをネイティブにサポートしており、アカウント抽象化ウォレットを利用することで、Zytronはルールに適合するアカウントに対して取引手数料の免除機能を提供します。この機能は、シーケンサーが取引を受信する際に直接変換を行い、0ガスのサービス機能を実現します。

3.3.5.4 クロスチェーンブリッジ

Zytronのシャーディング実行モードにより、チェーンと上位ブロックチェーンは特定のアドレス状態グループに関連付けられることができます。したがって、この特別なアドレス状態グループ内で、Zytronは特別なデポジット取引をサポートします。この取引は上位ブロックチェーンから派生し、上位ブロックチェーンでロックされたトークンをZytronでミントすることができます。