Zenith EVM: testnet ドキュメント

クイックスタート

以下のセクションでは、標準的な Ethereum ツールを使用して、シンプルな Solidity コントラクトを Zenith EVM Testnet にデプロイする手順を説明します。

Zenith EVM は Reth ベースの環境であり、標準的な Ethereum JSON-RPC エンドポイントを公開しています。ほとんどの EVM ワークフローでは、ネットワーク設定を変更するだけで済みます。

testnet をウォレットに追加する

MetaMask またはその他の EVM ウォレットで、Zenith EVM Testnet をカスタムネットワークとして追加します。

ウォレットへの資金供給

testnet トークンの入手

Zenith EVM testnet のフォーセットを使用します:

• https://explorer.testnet.zenith.network/faucet

ZTH は Zenith EVM testnet のネイティブガストークンです。小数点以下は 18 桁で、コントラクトのデプロイやトランザクションの送信に必要です。

基本的な EVM クイックスタートに必要なのは ZTH のみです。Testnet wCTN (Wrapped Canton) は、ローカルの Canton テストネットワークと直接やり取りする Canton ネイティブのワークフローにのみ関係します。

シンプルなコントラクトの作成

以下は、Zenith EVM へのコントラクトデプロイをテストするために使用できるシンプルなコントラクトの例です。

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;
contract Counter {
    uint256 public number;
    event NumberChanged(uint256 newNumber);
    function setNumber(uint256 newNumber) external {
        number = newNumber;
        emit NumberChanged(newNumber);
    }
    function increment() external {
        number += 1;
        emit NumberChanged(number);
    }
}

環境の設定

テスト用として、RPC URL、チェーン ID、デプロイヤーの秘密鍵を環境変数として設定できます。

export ZENITH_RPC_URL="<zenith-evm-rpc-url>"
export ZENITH_CHAIN_ID="<zenith-evm-chain-id>"
export PRIVATE_KEY="<your-private-key>"

重要な注意: 秘密鍵を環境変数として保存することは開発およびテストでは一般的ですが、本番環境では以下を行うべきです:

• .env ファイルを決してバージョン管理にコミットしない
• .env を .gitignore に追加する
• 本番デプロイにはシークレットマネージャー(例: AWS Secrets Manager、HashiCorp Vault)の使用を検討する
• 必要な資金のみを保有する専用のデプロイヤーウォレットを使用する

Foundry でのデプロイ

以下の手順に従って、Foundry を使用してコントラクトをデプロイします:

forge init zenith-counter
cd zenith-counter
# Replace the default Counter with the contract above.
forge build
forge create \
  --rpc-url "$ZENITH_RPC_URL" \
  --private-key "$PRIVATE_KEY" \
  src/Counter.sol:Counter

デプロイコマンドは、デプロイされたコントラクトのアドレスとトランザクションハッシュを返します。

コントラクトとの対話

コントラクトをデプロイしたら、Foundry の cast ツールを使用して、コマンドラインから直接ステートの読み取りやトランザクションの送信ができます。

export COUNTER_ADDRESS="<deployed-contract-address>"
cast call \
  --rpc-url "$ZENITH_RPC_URL" \
  "$COUNTER_ADDRESS" \
  "number()(uint256)"
cast send \
  --rpc-url "$ZENITH_RPC_URL" \
  --private-key "$PRIVATE_KEY" \
  "$COUNTER_ADDRESS" \
  "increment()"

トランザクションの確認

エクスプローラーは Canton レイヤーと EVM レイヤーの両方をリアルタイムで監視しており、現在は Canton の更新と EVM ブロックを同期して追跡しています。

Zenith Explorer を開きます:

• https://explorer.testnet.zenith.network/

上部の検索バーで EVM トランザクションハッシュを検索します。エクスプローラーは以下のビューを提供します:

• Blocks: EVM ブロック履歴を閲覧
• Transactions: インデックスされた EVM トランザクションの完全な一覧
• Linked Transactions: EVM トランザクションと対応する Canton 更新とのリンクを表示
• Contracts: デプロイされたコントラクトの詳細を表示

トランザクションページには、標準的な EVM トランザクションの詳細、ログ、コントラクトとの対話が表示されます。

Linked transactions ビューは Zenith 独自のもので、各 EVM トランザクションに対応する Canton 更新 ID を表示し、EVM から Canton までのトランザクションの完全なライフサイクルを追跡できます。

平均レイテンシに関する注意: ダッシュボードに表示される 3〜4 秒の平均レイテンシは、Canton テストネットワークにおける送信からファイナリティまでのエンドツーエンドのトランザクション処理時間を意味します。

内部では、RPC を通じて送信された EVM トランザクションは Zenith EVM Sequencer によって収集され、Canton を介したブロック提案に含められます。これによって標準的な EVM 開発者ワークフローが変わることはありません。

その他の EVM 開発者向けリソース

EVM の基礎、Solidity の開発パターン、そして Zenith EVM が完全な互換性を持つ標準ツールについてより深く学ぶには、Ethereum の開発者ドキュメントを参照してください:

• Ethereum 開発者ドキュメント: 中核となる概念、スマートコントラクト開発、デプロイガイド。
• Ethereum JSON-RPC リファレンス: Zenith EVM がサポートする eth_* メソッドの完全な仕様。
• Ethereum JavaScript API: ethers.js、web3.js、その他のクライアントライブラリのガイド。

開発者ガイド

MetaMask の設定

1. MetaMask を開きます
2. ネットワークのドロップダウンを選択します
3. カスタムネットワークを追加を選択します
4. 以下のとおり Zenith EVM Testnet の詳細を入力します

または、ワンクリックでネットワークを追加します:

ネットワークを追加した後、https://explorer.testnet.zenith.network/faucet で testnet ZTH をリクエストしてください。

ガスと手数料

現在の Zenith EVM testnet は、実行レイヤーで標準的な EVM ガスセマンティクスを使用しています。ガス見積もりとトランザクションレシートは、eth_estimateGas や eth_getTransactionReceipt などの標準的な Ethereum JSON-RPC メソッドを通じて取得できます。

ガスは、Zenith EVM Testnet のネイティブ通貨である ZTH で支払われます。

Foundry の設定

Foundry は Zenith EVM でそのまま動作し、必要な設定は testnet の RPC エンドポイントを追加することだけです。以下の例では、シンプルな Counter コントラクトを使用して、ビルド → デプロイ → トランザクション送信 → 読み取りという一連のワークフローを示します。

foundry.toml に Zenith EVM の RPC エイリアスを追加します。

[rpc_endpoints]
zenith_testnet = "${ZENITH_RPC_URL}"

変更される可能性のある値には環境変数を使用します。

export ZENITH_RPC_URL="<zenith-evm-rpc-url>"
export PRIVATE_KEY="<your-private-key>"

ビルドとデプロイ:

forge build
forge create \
  --rpc-url zenith_testnet \
  --private-key "$PRIVATE_KEY" \
  src/Counter.sol:Counter

トランザクションを送信します:

cast send \
  --rpc-url zenith_testnet \
  --private-key "$PRIVATE_KEY" \
  "$COUNTER_ADDRESS" \
  "increment()"

ステートを読み取ります:

cast call \
  --rpc-url zenith_testnet \
  "$COUNTER_ADDRESS" \
  "number()(uint256)"

Hardhat の設定

Hardhat プロジェクトは、testnet の RPC を指すネットワークエントリを追加することで Zenith EVM に接続します。以下のセットアップでは TypeScript と公式の Hardhat Toolbox プラグインを使用していますが、JavaScript の設定でも同様に動作します。

必要に応じて Hardhat をインストールします:

npm install --save-dev hardhat @nomicfoundation/hardhat-toolbox

Hardhat の設定ファイルを作成または更新します:

import { HardhatUserConfig } from "hardhat/config";
import "@nomicfoundation/hardhat-toolbox";
const config: HardhatUserConfig = {
  solidity: "0.8.24",
  networks: {
    zenithTestnet: {
      url: process.env.ZENITH_RPC_URL || "",
      chainId: Number(process.env.ZENITH_CHAIN_ID || "0"),
      accounts: process.env.PRIVATE_KEY ? [process.env.PRIVATE_KEY] : [],
    },
  },
};
export default config;

環境を設定します:

export ZENITH_RPC_URL="<zenith-evm-rpc-url>"
export ZENITH_CHAIN_ID="<zenith-evm-chain-id>"
export PRIVATE_KEY="<your-private-key>"

デプロイします:

npx hardhat compile
npx hardhat run scripts/deploy.ts --network zenithTestnet

デプロイスクリプトの例:

import { ethers } from "hardhat";
async function main() {
  const Counter = await ethers.getContractFactory("Counter");
  const counter = await Counter.deploy();
  await counter.waitForDeployment();
  console.log("Counter deployed to:", await counter.getAddress());
  console.log("Deployment tx:", counter.deploymentTransaction()?.hash);
}
main().catch((error) => {
  console.error(error);
  process.exitCode = 1;
});

Remix の設定

Remix はローカルへのインストールが不要です。MetaMask を Zenith EVM testnet に接続し、ブラウザから直接デプロイするだけです。

MetaMask を通じて Remix を使用します。

1. Zenith EVM Testnet を MetaMask に追加します。
2. アカウントに testnet ZTH を入金します。
3. Remix を開きます。
4. Solidity コントラクトをコンパイルします。
5. Deploy & Run Transactions で Injected Provider - MetaMask を選択します。
6. MetaMask が Zenith EVM Testnet に接続されていることを確認します。
7. 他の EVM チェーンと同様にデプロイします。

Remix は、MetaMask を通じて Zenith EVM の RPC エンドポイントにトランザクションを送信します。

注意: 開発者は Remix の「External HTTP Provider」オプションを使用して、RPC URL を直接入力することもできます。

スマートコントラクトのデプロイ

Zenith EVM へのデプロイは、Ethereum やその他の EVM 互換チェーンへのデプロイと同一です。以下の表は、変わらない点といくつかの留意点をまとめたものです。

コントラクトとの対話

コントラクトがデプロイされたら、任意の標準的な Ethereum ライブラリを使用してステートの読み取りやトランザクションの送信ができます。以下の例では、デプロイ手順と同じ Counter コントラクトを使用しており、Ethereum 上とまったく同様に動作します。プロバイダーを Zenith EVM の RPC エンドポイントに向けるだけです。

Ethers.js の例

import { Contract, JsonRpcProvider, Wallet } from "ethers";
import counterAbi from "./Counter.abi.json" assert { type: "json" };
const provider = new JsonRpcProvider(process.env.ZENITH_RPC_URL);
const wallet = new Wallet(process.env.PRIVATE_KEY!, provider);
const counter = new Contract(
  process.env.COUNTER_ADDRESS!,
  counterAbi,
  wallet
);
const before = await counter.number();
console.log("Before:", before.toString());
const tx = await counter.increment();
console.log("Tx hash:", tx.hash);
const receipt = await tx.wait();
console.log("Included in block:", receipt?.blockNumber);
const after = await counter.number();
console.log("After:", after.toString());

Web3.js の例

import Web3 from "web3";
import counterAbi from "./Counter.abi.json" assert { type: "json" };
const web3 = new Web3(process.env.ZENITH_RPC_URL!);
const account = web3.eth.accounts.privateKeyToAccount(process.env.PRIVATE_KEY!);
web3.eth.accounts.wallet.add(account);
const counter = new web3.eth.Contract(
  counterAbi as any,
  process.env.COUNTER_ADDRESS
);
const before = await counter.methods.number().call();
console.log("Before:", before);
const receipt = await counter.methods.increment().send({
  from: account.address,
});
console.log("Tx hash:", receipt.transactionHash);

Zenith EVM の RPC からトランザクションレシートが返された時点で、そのトランザクションは Canton を通じてファイナライズされています。確率的ファイナリティを持つチェーンとは異なり、アプリケーションは複数のブロック承認を待つ必要はありません。

Canton ワークフローの詳細

Canton ネイティブのワークフローをさらに詳しく知りたい場合は、以下のリソースが良い出発点となります:

ネットワーク情報

Testnet の詳細

Zenith EVM Testnet は、本番環境に移行する前にコントラクトのデプロイ、トランザクションの開始、ネットワークの探索ができるパブリックなテスト環境です。以下の詳細情報を使用してウォレットやツールを設定し、フォーセットから testnet トークンを取得して始めてください。

JSON-RPC

Zenith EVM は標準的な Ethereum JSON-RPC エンドポイントを公開しており、Ethereum JSON-RPC API を実装する Reth に含まれる標準的な JSON-RPC メソッドをサポートしています。よく使用されるメソッドには以下が含まれます:

サポートされているメソッドの完全な一覧については、Ethereum JSON-RPC API ドキュメント を参照してください。

公開されている Ethereum JSON-RPC インターフェースを通じて送信されたトランザクションは、開発者から見れば標準的な EVM の送信モデルに従います。内部的には、Zenith EVM はそれらを Sequencer と Canton を介したブロック提案フローにルーティングします。

基本的な JSON-RPC リクエスト

RPC リクエストを送信するには、Ethereum ノードに対して使用するのと同じリクエスト形式を使用できます。

curl "$ZENITH_RPC_URL" \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "method": "eth_chainId",
    "params": [],
    "id": 1
  }'

curl "$ZENITH_RPC_URL" \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "method": "eth_blockNumber",
    "params": [],
    "id": 1
  }'

カスタム RPC メソッド

Zenith EVM は、公開 testnet RPC エンドポイントでカスタム RPC メソッドを公開していません。

一部の Zenith バリデータインフラストラクチャは、Canton を介したブロック生成の際に blockBuilder_buildBlock などの内部ブロックビルダー RPC メソッドを使用します。これらのメソッドは、公開されている開発者向け RPC の対象範囲には含まれず、標準的な EVM アプリケーション開発には必要ありません。

エクスプローラー

エクスプローラーは Canton レイヤーと EVM レイヤーの両方をリアルタイムで監視しており、現在は Canton の更新と EVM ブロックを同期して追跡しています。

Zenith Explorer を開きます:

• https://explorer.testnet.zenith.network/

上部の検索バーで EVM トランザクションハッシュを検索します。エクスプローラーは以下のビューを提供します:

• Blocks: EVM ブロック履歴を閲覧
• Transactions: インデックスされた EVM トランザクションの完全な一覧
• Linked Transactions: EVM トランザクションと対応する Canton 更新とのリンクを表示
• Contracts: デプロイされたコントラクトの詳細を表示

トランザクションページには、標準的な EVM トランザクションの詳細、ログ、コントラクトとの対話が表示されます。

平均レイテンシに関する注意: ダッシュボードに表示される 3〜4 秒の平均レイテンシは、Canton テストネットワークにおける送信からファイナリティまでのエンドツーエンドのトランザクション処理時間を意味します。

Linked Transactions ビューは Zenith 独自のもので、各 EVM トランザクションに対応する Canton 更新 ID を表示し、EVM から Canton までのトランザクションの完全なライフサイクルを追跡できます。

コンセプトとアーキテクチャ

このセクションでは、Zenith EVM の技術的な概要として、その仕組み、Canton との関係、そして Canton を介したブロック生成を通じて EVM の実行がどのように調整されるかを説明します。

Zenith EVM とは?

Zenith EVM は、高性能かつモジュール式の Ethereum 実行クライアントである Reth 上に構築されたリファレンス EVM 実行環境です。標準的な Ethereum JSON-RPC インターフェースを公開しているため、開発者は他の Ethereum 互換チェーンとまったく同じように Zenith EVM とやり取りできます。

開発者の視点から見ると:

• スマートコントラクトのデプロイ: Solidity、Foundry、Hardhat、または任意の EVM ツールチェーンを使用でき、変更は不要です。
• ウォレットの接続: Zenith EVM をカスタムネットワークとして追加することで、MetaMask などのウォレットを接続できます。
• 既存ライブラリの使用: ethers.js、viem、web3.js、OpenZeppelin など、すべてそのまま動作します。

Zenith EVM がスタンドアロンの EVM チェーンと異なる点は、Canton との関係にあります。すべての EVM アクティビティは Canton を経由してルーティングされ、Canton MainNet 上で決済されます。これにより、Zenith EVM は完全な Ethereum 開発者体験を維持しながら、Canton の規制およびコンプライアンス上の保証を得ています。

Zenith EVM は、登録済みの Canton Super Validator である Zenith によって維持されています。カスタマイズ可能な独自の EVM 環境を立ち上げたい企業や開発者は、Zenith Stack を通じて実現できます。

Zenith EVM と Canton の関係

Zenith EVM は、Canton 上の EVM ベースのサブネットとして理解するのが最も適切です。独自の Ethereum 型コンセンサスレイヤーを持つ別個のチェーンではありません。むしろ、Zenith EVM のブロック生成、正規のチェーンステート、ファイナリティは Canton を介して仲介されます。

概要としては:

• EVM ユーザーは JSON-RPC を通じて標準的な EVM トランザクションを送信します。
• トランザクションは収集され、Canton 側のブロック提案としてバッチ化されます。
• バリデータは、同じ順序付けされた入力から提案された EVM ブロックを再構築します。
• Canton のファイナリティにより、どの提案 EVM ブロックが正規のものになるかが決定されます。
• ファイナライズされたブロックは、その後 EVM 実行側に伝播されます。

このアーキテクチャにより、Zenith EVM は通常の Ethereum ツールと実行セマンティクスを維持しながら、決定論的なファイナリティと Canton ネイティブのアトミックなコンポーザビリティを Canton に依拠して実現します。

Canton 上のオンレジャー表現

Zenith EVM は、単一のモノリシックなステートコントラクトではなく、一連の Daml コントラクトによって Canton 上で表現されます。これらのコントラクトは連携して、正規の EVM チェーンステートを記録し、新しいブロックの生成とファイナライズの方法を統制します。

Canton 側でこのオンレジャーステートを整理するために使用される識別子は、ウォレットや EVM トランザクションで使用される Ethereum の EIP-155 チェーン ID とは異なります。

ブロック生成と正規のチェーンステートは、別個の Ethereum コンセンサスレイヤーではなく、Canton コントラクトとバリデータの承認を通じて統制されるため、Zenith EVM は Canton のファイナリティとトラストモデルを継承します。具体的なオンレジャーコントラクトの設計は、Zenith EVM 実装の内部事項です。

external_call() プリミティブ

Zenith EVM は、Canton 側の Daml ワークフローと決定論的な EVM 実行を接続するために external_call() を使用します。

external_call() プリミティブは、Canton ネイティブの2 段階検証プロセスに従います:

1. 送信フェーズ: 送信参加者はインタープリテーション中に external_call() を実行し、その結果、ハッシュ、メタデータをトランザクションビューに含めます。
2. 検証フェーズ: バリデータは、自身の EVM ノードに対して同じ操作をローカルで独立して再実行します。
3. コンセンサスとファイナリティ: トランザクションは、しきい値以上のバリデータが出力に合意した時点で承認されます。BFT 方式のクォーラムモデルに従い、少なくとも 3 分の 2 のバリデータが合意する必要があり、そうでない場合トランザクションは拒否されます。必要なバリデータ承認のしきい値に達すると、Canton メディエーターがトランザクションをファイナライズします。

この設計は、Canton の既存モデルを超える追加の信頼前提を導入しません。

Canton と Zenith EVM にまたがるトランザクションに対する実際的な保証は以下のとおりです:

• Canton 側と EVM 側の両方が成功した場合、結合されたトランザクションはコミットされます。
• いずれかの側が失敗した場合、トランザクション全体が失敗します。
• 失敗したワークフローが、部分的にコミットされた EVM または Canton 側のステート遷移を残すことはありません。

バリデータノード

Zenith EVM バリデータは、EVM チェーンのブロック生成を検証および承認する権限を持つ Canton 参加者です。バリデータはこのプロセスに参加するために必要な Canton と EVM の両方のノードソフトウェアを実行しますが、正規のチェーンが単一のノードによって決定されることはありません。

Zenith EVM チェーンの信頼できる情報源は、個々のノードのローカルビューではなく、Canton でファイナライズされたブロックのシーケンスです。ノードは候補ブロックを構築できますが、正規のステートは Canton のファイナリティの後にのみ更新されます。

ブロックビルディング

Zenith EVM でのブロックビルディングは Ethereum mainnet とは異なります。Zenith EVM は、Ethereum のメンプール駆動のプロポーザー・ビルダーフローや Ethereum Beacon Chain のバリデータ選出を使用しません。代わりに、ブロックは Canton を介した提案フローを通じて構築されます。

概要としては、次のブロックに向けたトランザクションは Canton 側で収集され、順序付けされます。次のブロックの準備が整うと、権限を持つバリデータがビルドを主導します:

• 順序付けされたトランザクションのセットから候補ブロックが組み立てられ、実行されます。
• 他のバリデータは、同じ入力から同じブロックを独立して再構築します。

その後、Canton のファイナリティによって、提案されたブロックが正規のものになるかどうかが決定されます。決定後、ブロックは EVM 実行レイヤーに伝播され、そのステートが更新されます。

検証に失敗したトランザクションは拒否され、結果のブロックから除外されることがあります。送信されたトランザクションが拒否された場合、そのトランザクションは結果のブロックに含まれず、レシートも存在しません。

ファイナリティとレイテンシ

Zenith EVM トランザクションのファイナリティは、Canton のコンセンサスによって提供されます。バリデータは同じ入力から提案された EVM ブロックを独立して再構築し、必要なバリデータ承認のしきい値に達すると、Canton メディエーターがブロックビルディングトランザクションをファイナライズします。

EVM の実行は Canton のトランザクションフローを通じて調整されるため:

• 実行はアトミック: 結合された Canton/EVM ワークフローはコミットされるか、全体として失敗するかのいずれかです。
• ファイナリティは決定論的: Canton トランザクションが承認された時点で、EVM のステート遷移は確定します。
• Canton のファイナリティ後に EVM のリオーグは発生しない: 正規の EVM ステートは、ファイナライズされた Canton 仲介のブロックシーケンスに従います。

現在の testnet では、Canton ネイティブトランザクション内の追加 EVM 操作の典型的なエンドツーエンドレイテンシは 400 ミリ秒から 1.5 秒の間で変動します。約 4〜5 秒でファイナリティに達する Canton のみのトランザクションと比較して、追加されるレイテンシはごくわずかです。

注意: これらのレイテンシの数値は初期の testnet 測定によるもので、まだ最適化されていません。

Ethereum Mainnet との相違点

Zenith EVM は Reth 上に構築され、標準的な Ethereum RPC インターフェースを公開しているため、同じ開発パターンを Zenith 上でそのまま適用できます。このセクションでは相違点を取り上げます。

同じ点は?

注意: Zenith EVM mainnet でのガス会計には、Canton トランザクション手数料をカバーする追加要素が含まれる予定です。

異なる点は?

開発者への影響

• 標準的な EVM ワークフローは引き続き機能します: デプロイ、対話、イベント、レシート、ツールは従来どおりです。
• 承認されたトランザクションは確定です: トランザクションが Canton を通じてファイナライズされると、確率的ファイナリティのチェーンとは異なり、アプリケーションは通常、複数のブロック承認を待つ必要はありません。
• 二重のトランザクション ID: EVM トランザクションは、それが含まれた EVM ブロックに対応する Canton 更新 ID で追跡できます。
• Canton ネイティブのワークフローは EVM 実行を調整できます: すべての Zenith EVM トランザクションバッチは、アトミックな Canton 仲介のブロックビルディングパスを通じて処理されます。
• アトミックワークフローでのレシート確認: EVM トランザクションが拒否された場合、そのレシートは存在しません。Canton 側のワークフローはこれを失敗した EVM レッグとして扱うべきです。
• Ethereum Beacon Chain のランダム性セマンティクスに依存しないでください: block.prevrandao を使用するコントラクトは、Zenith EVM がこの値を Ethereum Beacon Chain のバリデータ選出ランダム性から取得していないことを考慮すべきです。

相互運用性

Zenith EVM は、相互に補完し合う 2 つの相互運用性モデルをサポートしています:

1. Gateway: Canton ネイティブのワークフローと Zenith EVM の間の、Zenith によるアトミックな相互運用パス。
2. 外部エコシステムとの相互運用性: Zenith EVM を外部チェーンおよびメッセージングエコシステムに接続する予定のモデル。

Zenith Gateway

Gateway は、Canton と Zenith EVM の間の Zenith によるアトミックな相互運用性ソリューションです。

これは、Canton ワークフローが Zenith EVM 上の EVM 実行を調整でき、結果として生じるステート遷移が Canton を通じて決済される、Canton ネイティブの相互運用パスです。これが可能なのは、Zenith EVM のブロック生成とファイナリティが、別個の Ethereum コンセンサスレイヤーではなく、Canton コントラクトとバリデータの承認を通じて仲介されるためです。

Gateway は、Zenith EVM の他の部分と同じアトミックな Canton 仲介のブロック処理パスを使用します。Canton ネイティブのワークフローは、Canton 経由でルーティングされるトランザクションバッチに EVM トランザクションを送信でき、結果として生じる EVM ブロックは Canton を通じてアトミックに処理およびファイナライズされます。

いずれの場合も、ブロック生成は Canton を通じて調整および承認されます。バリデータは同じ入力から提案された EVM ブロックを再構築し、必要なバリデータ承認数に達すると、ブロックはファイナライズされ、正規のものとなります。その後、Canton 側のワークフローは、自身のステート変更をコミットする前に EVM の結果を検証できます。

Gateway と外部ブリッジの比較

Gateway ワークフロー

概要としては、Gateway ワークフローは Canton 側のアクションと EVM 側のトランザクションを調整します:

1. Canton ネイティブのワークフローが 1 つ以上の EVM トランザクションを準備します。
2. トランザクションは、EVM 実行の前に Canton を経由してルーティングされる順序付きバッチに含められます。
3. ブロック生成は Canton を通じて承認されます。バリデータは同じ入力から提案された EVM ブロックを再構築し、Canton のファイナリティに達すると EVM ブロックが正規のものになります。
4. その後、Canton 側のワークフローは、結果の EVM ブロックデータとトランザクションレシートを検査し、期待された EVM トランザクションが含まれていること、および期待されたログまたはイベントが発行されたことを確認します。

Gateway トランザクションは、独自のプライベートブロックとしてではなく、ブロックの残りの部分と一緒に含められ、ファイナライズされます。これにより、Gateway は、すべてのトランザクションバッチが Canton のコンセンサスを経由してルーティングされる、Zenith EVM の単一の Canton 仲介ブロック生成フローとの整合性を保ちます。

レシートベースの検証

Gateway が機能するためには、Canton 側のワークフローには結果のブロックハッシュ以上の情報が必要です。EVM トランザクションレシートは、標準的な Ethereum トランザクションレシートと同等の形式で、構造化された値として Canton ワークフローに提供されます。これには以下が含まれます:

• 成功または失敗のステータス、
• 発行されたログとイベント、
• EVM トランザクションハッシュ、
• 送信者、
• ターゲットまたは作成されたコントラクトのアドレス。

発行されたログから、Canton 側のワークフローは、単に何らかの EVM ステート遷移が発生したことを確認するだけでなく、意図した EVM イベントが発生したことを検証できます。

各トランザクションは検証され、拒否される可能性があるため、レシートはトランザクションが実際にファイナライズされたブロックに含まれた場合にのみ存在します。したがって、レシートの有無は、ワークフローが成功した EVM レッグと拒否されたレッグを区別する手段となります。レシートが存在しない場合、Canton が調整するワークフローは EVM 実行を失敗として扱い、結合された操作を中止すべきです。Canton の操作や更新 ID との相関は Canton 側から得られるものであり、別途追跡されます。これは EVM レシートの一部ではありません。

外部エコシステムとの相互運用性

外部エコシステムとの相互運用性は、Gateway とは別のものです。

Gateway は、ワークフローの両側が Canton を通じて仲介されるため、Canton ↔ Zenith EVM のアトミックなコンポーザビリティのために設計されています。Ethereum、Base、Solana、その他の L1/L2 ネットワークなどのエコシステムとの外部相互運用性は、独立したネットワーク間でのクロスチェーンメッセージング、ブリッジング、またはトークン転送という異なるモデルに従います。

これらの統合には、CCIP や LayerZero などの確立されたクロスチェーンメッセージングまたはブリッジプロトコルが使用される可能性があります。それらは、Gateway の Canton を介したアトミック性ではなく、選択された外部プロトコルの信頼、ファイナリティ、リトライ、失敗に関する前提に従うことになります。

現在のステータス: Gateway は、アトミックワークフローのための主要な Canton ↔ Zenith EVM 相互運用メカニズムです。外部エコシステムとの統合は、別のロードマップ項目です。