> For the complete documentation index, see [llms.txt](https://docs.rome.builders/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.rome.builders/ko/canton-zk-evm/how-it-works.md).

# 작동 방식

reth에서 증명 과정을 거쳐 Canton 커밋까지 하나의 Ostia 블록을 따라가 보세요.

빌더가 실행될 때마다 하나의 블록을 만들고, 증명하고, 제출합니다. Canton은 그 블록이 체인의 다음 헤드가 될지 결정합니다. EVM 블록과 그 안에 기록된 Canton 레그는 같은 트랜잭션으로 커밋됩니다.

이 페이지는 커밋에 대해 설명합니다 `a84e84e439a5cc669c0ae61facf7c8c995d9d564`. 전체 내용을 읽어보세요 [설계](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/docs/DESIGN.md).

```mermaid
흐름도 TD
    W["EVM 트랜잭션"] --> R["reth가 요청에 따라 빌드함"]
    R --> B["빌더가 게이트웨이 레그를 읽고 해당 Canton 계약을 찾음"]
    B -->|"레그를 정산할 수 없음: 해당 트랜잭션을 제외하고 다시 빌드"| R
    B -->|"모든 레그를 정산할 수 있음"| P["ZisK가 블록을 증명함"]
    P --> A["진행: 블록, 증명, 레그를 하나의 Canton 트랜잭션에 담음"]
    A --> S["외부 호출: 사이드카가 증명과 게이트웨이 상태를 확인함"]
    S --> D["Daml이 헤드를 확인하고 레그를 정산함"]
    D --> C["Canton이 블록과 그 레그를 함께 커밋함"]
    C --> F["reth가 블록을 최종 확정으로 표시함"]
```

## Canton의 헤드를 기준으로 빌드

지갑은 EVM 트랜잭션을 reth로 보냅니다. 제공된 실행기는 피어 검색을 꺼 둡니다. 빌더가 블록을 요청하면 reth가 블록을 만듭니다.

빌더는 먼저 활성 `ZkChain` Canton의 계약을 읽습니다. reth의 헤드, 안전 블록, 최종 확정 블록을 그 커밋된 헤드로 옮깁니다. 각 발신자의 넌스 순서를 유지하고 가스 한도 안에 두면서, 가격에 따라 대기 중인 트랜잭션을 선택합니다. 그런 다음 해당 명시적 트랜잭션 목록으로 reth에 빌드를 요청합니다.

Canton 작업이 필요한 EVM 트랜잭션은 게이트웨이를 호출합니다. 게이트웨이는 레그를 기록하고 이를 블록의 누적 해시에 반영합니다. 빌더는 로그 순서대로 게이트웨이 이벤트를 읽고 각 레그에 필요한 Canton 계약을 찾습니다.

배정이 사라졌거나, 수신자가 인출을 수락하지 않았거나, 다른 필요한 계약이 없으면, 빌더는 해당 트랜잭션과 그 발신자의 이후 트랜잭션을 제외합니다. reth를 Canton의 헤드로 되돌리고 다시 빌드합니다. 이러한 검사는 증명 전에 수행됩니다. 그 [빌더 README](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/builder/README.md) 각 레그에 대한 검사를 나열합니다.

## 블록을 증명

빌더는 블록과 reth의 실행 증인을 저장합니다. 입력 도구는 블록, 증인, 제네시스를 증명기 입력으로 결합합니다. ZisK는 게스트를 실행하며, 이는 체인의 고정 규칙에 따라 블록을 검증합니다.

증명기는 블록 해시에 커밋되는 1,344바이트 래핑된 증명을 반환합니다. 빌더는 제출합니다 `선지급` 헤더, 트랜잭션, 증명, 레그, 그리고 블록의 상태 루트에 있는 게이트웨이의 계정 및 저장소 증명과 함께.

## 하나의 트랜잭션에서 확인하고 정산

각 확인 참여자는 사이드카를 실행합니다. Canton's 외부 호출은 해당 참여자의 사이드카로 블록을 보내어 `검증`. 증명, 고정된 프로그램 키와 ZisK 릴리스, 헤더의 해시와 트랜잭션 목록의 루트를 확인합니다.

Daml은 답을 다음과 대조합니다 `ZkChain`: 부모는 현재 헤드여야 하고, 번호는 다음 번호여야 하며, 가스 한도와 사용 가스는 상한에 맞아야 합니다. Daml은 사이드카의 답을 비교할 뿐이며, 제로지식 증명 자체는 검증하지 않습니다.

그런 다음 Daml은 레그마다 그 레그가 지정하는 Canton 계약에서 한 줄씩 작성합니다. 출금의 id, 소각자, 금액은 빌더가 제공합니다. 증명된 해시는 그것들을 블록이 기록한 내용에 묶습니다. 사이드카의 `레그` 함수는 게이트웨이의 계정 및 저장소 증명을 확인하고, 그 줄들을 순서대로 해시한 뒤 결과를 증명된 상태의 게이트웨이 값과 비교합니다. 레그가 없는 블록도 빈 목록으로 같은 검사를 통과해야 합니다.

Daml은 레그를 순서대로 정산하고 다음을 생성합니다 `블록 기록` 그리고 다음 `ZkChain`. Canton은 이러한 변경을 함께 커밋합니다. 검사나 정산이 실패하면 아무것도 커밋되지 않습니다. 체인의 단 하나뿐인 상태 계약을 소비함으로써 Canton은 블록 순서의 권한이 됩니다. 전체 [Daml 인터페이스](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/daml/README.md) 및 [사이드카 검사](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/sidecar/README.md).

## Canton이 거부할 때

Canton이 블록을 커밋한 후, 빌더는 reth에서 이를 최종으로 표시합니다. Canton이 이를 거부하면, 빌더는 reth를 Canton의 마지막 커밋된 블록으로 되돌리고 거부된 블록의 트랜잭션을 다시 풀로 보냅니다. 다음 실행에서 그 레그를 다시 확인합니다. 배정이 회수된 결제는 제외됩니다.

빌더가 제출 응답을 잃으면, 블록이 커밋되었는지 확인하기 위해 Canton의 헤드를 다시 읽습니다. 그 읽기도 실패하면, 결과를 알 수 없음으로 보고 reth를 현재 위치에 둡니다. 다음 실행은 Canton의 헤드에서 시작합니다. 이러한 복구 규칙은 [빌더 README](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/builder/README.md#what-one-run-does).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.rome.builders/ko/canton-zk-evm/how-it-works.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.