> 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/deposits-withdrawals-payments.md).

# 예치, 출금 및 결제

게이트웨이가 EVM 입금, 출금, 결제를 각각의 Canton 레그에 연결하는 방식.

게이트웨이는 체인의 제네시스에 포함된 EVM 컨트랙트입니다. 이는 블록이 Canton에 수행하도록 요구하는 내용을 기록합니다. 각 요청은 레그입니다. 블록의 증명은 기록된 순서대로 레그의 해시를 포함한 게이트웨이 상태에 커밋합니다.

이 페이지는 커밋에 대해 설명합니다 `a84e84e439a5cc669c0ae61facf7c8c995d9d564`. 전체 내용을 읽어보세요 [게이트웨이 README](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/gateway/README.md) 및 [Daml 인터페이스](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/daml/README.md).

| 레그 | 게이트웨이 호출                         | EVM 작업                      | Canton 작업의 `선지급`                       |
| -- | -------------------------------- | --------------------------- | -------------------------------------- |
| 예치 | `claim(id, token, amount)`       | 호출자에게 래핑된 토큰을 발행합니다.        | 예치자의 할당을 게이트웨이로 실행합니다.                 |
| 출금 | `withdraw(token, amount, party)` | 호출자의 래핑된 토큰을 소각합니다.         | 게이트웨이 보관분의 Canton 토큰을 지정된 당사자에게 지급합니다. |
| 지급 | `pay(id, token, to, amount)`     | 지급자로부터 수취인에게 ERC-20을 이전합니다. | 합의된 지급 조건에 따라 지정된 할당을 실행합니다.           |

## Canton 토큰 예치

예치자는 운영자를 실행자로 하여 Canton 토큰을 게이트웨이에 할당합니다. 예치자는 다음에 서명합니다. `예치 요청` 예치 ID, 청구가 허용된 EVM 주소, 그리고 할당을 지정합니다.

그 EVM 주소는 다음을 호출합니다 `claim`. 게이트웨이는 호출자에게 발행하고 예치 레그를 기록합니다. 수령인은 가스 비용을 위해 tROME이 필요합니다. 빌더는 레그를 요청, 등록된 토큰 및 할당과 매칭합니다.

`선지급` 할당을 게이트웨이 보관으로 실행하고 래핑된 토큰을 발행한 블록을 커밋합니다. 래핑된 토큰은 Canton 금액과 일치하는 10자리 소수점을 가집니다. 두 금액 간 변환은 반올림 없이 정확합니다.

## Canton 당사자로 출금

보유자는 다음을 호출합니다 `withdraw` 래핑된 토큰, 금액, 그리고 전체 Canton 당사자 ID를 사용합니다. 게이트웨이는 래핑된 토큰을 소각하고 레그에 수신자를 기록합니다.

수신자는 다음에 서명했어야 합니다 `출금 수락`. 보관될 때까지 활성 상태로 유지됩니다. 또한 빌더는 등록된 상품의 잠금 해제된 게이트웨이 보유분이 충분해야 합니다. 이러한 조건이 충족되지 않으면 거래를 제외합니다.

`선지급` 토큰 레지스트리의 전송 팩토리를 통해 수신자에게 지급합니다. Canton 전송과 소각을 포함한 블록은 함께 커밋됩니다. 빌더는 다음에 설명된 대로 블록당 상품의 출금을 최대 하나만 포함합니다: [빌더 README](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/builder/README.md).

## 하나의 할당에 지급을 연결하기

U가 V에게 Canton 토큰을 할당합니다. U와 V는 다음에 서명합니다 `Dvp 조건` 할당, 지급 ID, EVM 토큰, EVM 수취인 및 금액을 지정합니다. 지급 ID는 UTF-8 텍스트의 SHA-256입니다 `<U의 당사자 ID>,<V의 당사자 ID>,<레이블>`를 소문자 16진수로 작성합니다. 조건은 다른 어떤 ID도 거부합니다.

V는 게이트웨이를 승인하고 다음을 호출합니다 `pay` 해당 ID로. 게이트웨이는 ERC-20을 V에서 수취인으로 이동시키고 지급 레그를 기록합니다. `선지급` 서명된 조건을 사용하여 U에서 V로의 할당을 실행합니다.

일반 ERC-20 전송은 어떤 레그도 기록하지 않습니다. 같은 블록에서 같은 토큰을 같은 수취인에게 전송하더라도 다음을 대체할 수 없습니다 `pay`. 이 [설계의 지급 흐름](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/docs/DESIGN.md#the-flows) 이 결속을 설명합니다.

## 증명이 고정하는 것

각 레그는 해당되는 경우 종류, ID, 토큰, 계정, 금액 및 Canton 당사자를 기록합니다. 게이트웨이는 레그를 순서대로 해시합니다. `선지급` 부착된 레그가 증명된 게이트웨이 상태의 해시를 생성하는지 확인합니다. 레그가 누락되거나, 추가되거나, 순서가 바뀌거나, 변경되면 거래는 실패합니다. 이 검사는 레그가 없는 블록도 포함합니다.

블록을 증명한다고 해서 해당 Canton 할당이 예약되는 것은 아닙니다. 발신자는 결제 전에 여전히 할당을 되돌릴 수 있습니다. 증명 후에 그런 일이 발생하면 Canton은 거부합니다 `선지급` 그리고 reth는 마지막으로 커밋된 블록으로 돌아갑니다. 동일한 증명된 블록은 레그를 제거한 채 다시 제출할 수 없습니다. 다음 빌드는 결제를 제외하며, 다음에서 시연됩니다 [실행 4](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/demo/README.md#results).

## 토큰 및 보관 한계

Canton 토큰은 운영자의 참가자에서 게이트웨이 당사자가 보유합니다. 해당 참가자를 운영하는 사람은 누구나 이를 이동할 수 있습니다. 토큰을 등록한다는 것은 게이트웨이 권한으로 실행되는 해당 레지스트리의 Daml 코드를 신뢰한다는 뜻이기도 합니다.

게이트웨이의 EVM 주소로 직접 전송된 토큰은 복구할 수 없습니다. 토큰이 전송 수수료를 부과하거나 다른 금액이 이전되도록 하는 경우에도, 지급 레그는 실제 전송된 금액이 아니라 요청된 금액을 기록합니다. 다음을 읽어보세요 [신뢰 모델 및 한계](/ko/canton-zk-evm/trust-model.md).


---

# 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/deposits-withdrawals-payments.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.