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トランザクションハッシュを検索してください。Explorerは以下のビューを提供します：

• 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 APIs：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コントラクトを使用して、ビルド→デプロイ→トランザクション→読み取りの全ワークフローを説明します。

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

[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プロジェクトをZenith EVMに接続するには、testnet RPCを指すネットワークエントリを追加します。以下のセットアップは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トランザクションハッシュを検索してください。エクスプローラーでは以下のビューが提供されます：

• ブロック：EVMブロック履歴の閲覧
• トランザクション：インデックス済みEVMトランザクションの全一覧
• リンクトランザクション：対応するCantonアップデートにリンクされたEVMトランザクションを表示
• コントラクト：デプロイ済みコントラクトの詳細を表示

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

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

リンクトランザクションビューはZenith固有の機能であり、各EVMトランザクションに対応するCantonアップデートIDを表示することで、EVMからCantonまでのトランザクションのライフサイクル全体をトレースできます。

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

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

Zenith EVMとは？

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

開発者の視点から：

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

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

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

Zenith EVMとCantonの関係

Zenith EVMは、Canton上のEVMベースのサブネットとして理解するのが最も適切です。独自のEthereumスタイルのコンセンサスレイヤーを持つ独立したチェーンではありません。その代わり、Zenith EVMのブロック生成、正規チェーンの状態、およびファイナリティはCantonを通じて仲介されます。

概要：

• EVMユーザーはJSON-RPCを通じて標準的なEVMトランザクションを送信します。
• トランザクションは収集され、Cantонサイドのブロックプロポーザルにバッチ処理されます。
• バリデーターは同じ順序付きインプットから提案されたEVMブロックを再構築します。
• どの提案されたEVMブロックが正規となるかは、Cantonのファイナリティによって決定されます。
• ファイナライズされたブロックはEVM実行サイドに伝播されます。

このアーキテクチャにより、Zenith EVMは通常のEthereumツールと実行セマンティクスを維持しながら、決定論的なファイナリティとCanton固有のアトミックな相互運用性をCantonに依存することができます。

Canton上のオンレジャー表現

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

Cantонサイドでこのオンレジャー状態を整理するために使用される識別子は、ウォレットおよびEVMトランザクションで使用されるEthereum EIP-155チェーンIDとは異なります。

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

external_call() プリミティブ

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

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

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 オペレーションのエンドツーエンドの典型的なレイテンシーは、400ms から 1.5 秒の間で変動します。これは、Canton のみのトランザクション（ファイナリティに約 4〜5 秒かかる）と比較して、最小限のレイテンシーしか追加しません。

注意: これらのレイテンシーの数値は testnet 初期の計測値であり、まだ最適化されていません。

Ethereum Mainnet との違い

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

同じ点は？

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

何が異なるのか？

開発者への影響

• 標準的なEVMワークフローは引き続き機能します： デプロイ、インタラクション、イベント、レシート、およびツールは使い慣れた状態を維持します。
• 確認済みトランザクションは最終的です： Cantonを通じてトランザクションがファイナライズされると、確率的ファイナリティチェーンのように複数のブロック確認を待つ必要は通常ありません。
• デュアルトランザクションID： EVMトランザクションは、それが含まれるEVMブロックの対応するCantonアップデートIDと紐付けてトレースできます。
• CantonネイティブワークフローによるエVM実行の調整： すべての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ネイティブの相互運用性パスであり、CantonワークフローがZenith EVM上でのEVM実行を調整し、その結果として生じるステート遷移がCantonを通じてセトルされます。これが可能なのは、Zenith EVMのブロック生成とファイナリティが、独立したEthereumコンセンサスレイヤーではなく、Cantonコントラクトとバリデーター確認を通じて仲介されているためです。

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

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

Gateway vs 外部ブリッジ

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

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

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