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 블록을 동기화하여 추적합니다.

Open 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 테스트 네트워크에서 제출부터 최종 확정까지의 end-to-end 트랜잭션 처리 시간을 의미합니다.

내부적으로, RPC를 통해 제출된 EVM 트랜잭션은 Zenith EVM Sequencer에 의해 수집되어 Canton 중재 블록 제안에 포함됩니다. 이는 표준 EVM 개발자 워크플로우를 변경하지 않습니다.

EVM 개발자 추가 리소스

EVM 기초, Solidity 개발 패턴, 그리고 Zenith EVM이 완전히 호환되는 표준 툴링에 대해 더 깊이 알아보려면 Ethereum 개발자 문서를 참조하세요:

• Ethereum developer docs: 핵심 개념, 스마트 컨트랙트 개발, 배포 가이드.
• Ethereum JSON-RPC reference: Zenith EVM이 지원하는 eth_* 메서드의 전체 명세.
• Ethereum JavaScript APIs: ethers.js, web3.js 및 기타 클라이언트 라이브러리 가이드.

개발자 가이드

MetaMask 설정

1. MetaMask 열기
2. 네트워크 드롭다운 선택
3. Add a custom network 선택
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. MetaMask에 Zenith EVM Testnet을 추가하세요.
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을 통해 완결(finalized)된 것입니다. 확률론적 완결성을 가진 체인에서처럼 여러 블록 확인을 기다릴 필요가 없습니다.

Canton 워크플로우에 대해 더 알아보기

Canton 네이티브 워크플로우를 더 탐색하려면 아래 리소스가 좋은 출발점이 될 수 있습니다.

네트워크 정보

Testnet 세부 정보

Zenith EVM Testnet은 프로덕션 환경으로 전환하기 전에 컨트랙트를 배포하고, 트랜잭션을 시작하며, 네트워크를 탐색할 수 있는 공개 테스트 환경입니다. 아래 세부 정보를 사용하여 지갑이나 도구를 설정하고 faucet에서 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 트랜잭션 전체 목록
• 연결된 트랜잭션: EVM 트랜잭션과 해당하는 Canton 업데이트를 연결하여 표시
• 컨트랙트: 배포된 컨트랙트 세부 정보 보기

트랜잭션 페이지에는 표준 EVM 트랜잭션 세부 정보, 로그 및 컨트랙트 상호작용이 표시됩니다.

평균 지연 시간에 대한 참고 사항: 대시보드에서 표시되는 평균 지연 시간 3~4초는 Canton 테스트 네트워크에서 제출부터 최종 확정까지의 엔드투엔드 트랜잭션 처리 시간을 의미합니다.

연결된 트랜잭션 보기는 Zenith 고유의 기능으로, 각 EVM 트랜잭션에 대응하는 Canton 업데이트 ID를 표시하여 EVM에서 Canton까지 트랜잭션의 전체 수명 주기를 추적할 수 있도록 합니다.

개념 및 아키텍처

이 섹션에서는 Zenith EVM의 기술적 개요, 작동 방식, Canton과의 관계, 그리고 EVM 실행이 Canton 매개 블록 생성을 통해 어떻게 조율되는지를 설명합니다.

Zenith EVM이란?

Zenith EVM은 고성능 모듈형 Ethereum 실행 클라이언트인 Reth를 기반으로 구축된 참조 EVM 실행 환경입니다. 표준 Ethereum JSON-RPC 인터페이스를 제공하므로, 개발자는 Zenith EVM을 여느 Ethereum 호환 체인과 동일한 방식으로 사용할 수 있습니다.

개발자 관점에서:

• 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은 결정론적 최종 확정 및 Canton 네이티브 원자적 구성 가능성을 Canton에 의존하면서도 일반적인 Ethereum 툴링과 실행 의미 체계를 유지할 수 있습니다.

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 작업의 일반적인 종단 간 지연 시간은 400ms에서 1.5초 사이에서 변동합니다. 이는 약 4~5초 만에 최종성에 도달하는 Canton 전용 트랜잭션과 비교했을 때 최소한의 지연만 추가합니다.

참고: 이 지연 시간 수치는 초기 testnet 측정값이며 아직 최적화되지 않았습니다.

Ethereum Mainnet과의 차이점

Zenith EVM은 Reth를 기반으로 구축되어 표준 Ethereum RPC 인터페이스를 노출하므로, 동일한 개발 패턴을 Zenith에 직접 적용할 수 있습니다. 이 섹션에서는 다른 점을 중점적으로 설명합니다.

동일한 점은 무엇인가요?

참고: Zenith EVM mainnet의 가스 회계에는 Canton 트랜잭션 수수료를 포함하는 추가 요소가 포함됩니다.

무엇이 다른가요?

개발자를 위한 시사점

• 표준 EVM 워크플로우가 계속 작동합니다: 배포, 상호작용, 이벤트, 수신, 툴링이 익숙한 방식으로 유지됩니다.
• 확정된 트랜잭션은 최종적입니다: Canton을 통해 트랜잭션이 확정되면, 확률적 최종성 체인에서와 달리 애플리케이션은 일반적으로 여러 블록 컨펌을 기다릴 필요가 없습니다.
• 이중 트랜잭션 식별: EVM 트랜잭션은 해당 트랜잭션이 포함된 EVM 블록의 Canton 업데이트 ID로 추적할 수 있습니다.
• Canton 네이티브 워크플로우가 EVM 실행을 조율할 수 있습니다: 모든 Zenith EVM 트랜잭션 배치는 Canton 중재 원자적 블록 생성 경로를 통해 처리됩니다.
• 원자적 워크플로우를 위한 수신 확인: EVM 트랜잭션이 거부되면 해당 수신이 존재하지 않으며, Canton 측 워크플로우는 이를 실패한 EVM 단계로 처리해야 합니다.
• Ethereum Beacon Chain 무작위성 시맨틱에 의존하지 마십시오: block.prevrandao를 사용하는 컨트랙트는 Zenith EVM이 이 값을 Ethereum Beacon Chain 검증자 선택 무작위성에서 가져오지 않는다는 점을 고려해야 합니다.

상호운용성

Zenith EVM은 두 가지 상호보완적인 상호운용성 모델을 지원합니다:

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 네이티브 워크플로우는 EVM 트랜잭션을 Canton 라우팅 트랜잭션 배치에 제출할 수 있으며, 결과적인 EVM 블록은 Canton을 통해 원자적으로 처리되고 확정됩니다.

모든 경우에서 블록 생성은 Canton을 통해 조율 및 확인됩니다. 검증자는 동일한 입력으로 제안된 EVM 블록을 재구성하며, 필요한 검증자 확인에 도달하면 블록이 확정되어 정식으로 인정됩니다. Canton 측 워크플로우는 자체 상태 변경을 커밋하기 전에 EVM 결과를 검증할 수 있습니다.

Gateway와 외부 브릿지 비교

Gateway 워크플로우

개략적으로, Gateway 워크플로우는 Canton 측 액션과 EVM 측 트랜잭션을 조율합니다:

1. Canton 네이티브 워크플로우가 하나 이상의 EVM 트랜잭션을 준비합니다.
2. 트랜잭션은 EVM 실행 전에 Canton을 통해 라우팅되는 순서가 지정된 배치에 포함됩니다.
3. 블록 생성은 Canton을 통해 확인됩니다: 검증자들은 동일한 입력으로부터 제안된 EVM 블록을 재구성하며, Canton 최종성에 도달하면 EVM 블록이 정식 블록이 됩니다.
4. 이후 Canton 측 워크플로우는 결과로 생성된 EVM 블록 데이터와 트랜잭션 영수증을 검사하여, 예상된 EVM 트랜잭션이 포함되었는지 그리고 예상된 로그 또는 이벤트가 발생했는지 확인합니다.

Gateway 트랜잭션은 별도의 프라이빗 블록이 아닌 나머지 블록과 함께 포함되고 최종 확정됩니다. 이는 모든 트랜잭션 배치가 Canton의 합의를 통해 라우팅되는 Zenith EVM의 단일 Canton 중재 블록 생성 흐름과 Gateway를 일치시킵니다.

영수증 기반 검증

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 상호운용성의 주요 메커니즘입니다. 외부 생태계 통합은 별도의 로드맵 항목입니다.