> 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/vi/canton-zk-evm/deposits-withdrawals-payments.md).

# Nạp tiền, rút tiền và thanh toán

Cách cổng gateway liên kết tiền gửi, rút tiền và thanh toán EVM với các nhánh Canton tương ứng của chúng.

Cổng là một hợp đồng EVM được đưa vào genesis của chuỗi. Nó ghi lại những gì một khối cần Canton thực hiện. Mỗi yêu cầu là một nhánh. Bằng chứng của khối cam kết với trạng thái của cổng, bao gồm cả hàm băm của các nhánh theo đúng thứ tự chúng được ghi lại.

Trang này mô tả commit `a84e84e439a5cc669c0ae61facf7c8c995d9d564`. Đọc toàn bộ [README của gateway](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/gateway/README.md) và [giao diện Daml](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/daml/README.md).

| Nhánh      | Lời gọi gateway                  | Hành động EVM                                   | Hành động Canton trong `Tiến hành`                                          |
| ---------- | -------------------------------- | ----------------------------------------------- | --------------------------------------------------------------------------- |
| Nạp        | `claim(id, token, amount)`       | Đúc token bọc cho bên gọi.                      | Thực thi phần phân bổ của người nạp vào gateway.                            |
| Rút        | `withdraw(token, amount, party)` | Đốt token bọc của bên gọi.                      | Thanh toán token Canton từ quyền lưu ký của gateway cho bên được nêu tên.   |
| Thanh toán | `pay(id, token, to, amount)`     | Chuyển một ERC-20 từ người trả sang người nhận. | Thực thi phần phân bổ được nêu bởi các điều khoản thanh toán đã thỏa thuận. |

## Nạp một token Canton

Người nạp phân bổ một token Canton cho gateway, với operator là bên thực thi. Người nạp ký một `DepositRequest` đặt tên id nạp, địa chỉ EVM được phép nhận và phần phân bổ.

Địa chỉ EVM đó gọi `claim`. Gateway đúc cho bên gọi và ghi lại nhánh nạp tiền. Người nhận cần tROME để trả gas. Trình dựng khớp nhánh với yêu cầu, token đã đăng ký và phần phân bổ.

`Tiến hành` thực thi phần phân bổ vào quyền lưu ký của gateway và cam kết khối đã đúc các token bọc. Một token bọc có 10 chữ số thập phân, khớp với số lượng Canton. Việc chuyển đổi giữa hai số lượng là chính xác, không làm tròn.

## Rút về một bên Canton

Người nắm giữ gọi `rút` với token bọc, số lượng và đầy đủ id bên Canton. Gateway đốt các token bọc và ghi người nhận trong nhánh.

Người nhận phải đã ký một `WithdrawalAcceptance`. Nó vẫn hoạt động cho đến khi được lưu trữ. Trình dựng cũng cần đủ lượng nắm giữ chưa mở khóa của gateway đối với công cụ đã đăng ký. Nếu các điều kiện này không thỏa, nó sẽ loại giao dịch ra.

`Tiến hành` thanh toán cho người nhận thông qua factory chuyển nhượng của sổ đăng ký token. Việc chuyển Canton và khối chứa thao tác đốt được cam kết cùng nhau. Trình dựng chỉ đưa tối đa một lần rút của một công cụ vào mỗi khối, như được mô tả trong [README của trình dựng](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/builder/README.md).

## Gắn một khoản thanh toán với một phần phân bổ

U phân bổ một token Canton cho V. U và V ký `DvpTerms` đặt tên cho phần phân bổ, id thanh toán, token EVM, bên nhận EVM và số lượng. Id thanh toán là SHA-256 của văn bản UTF-8 `<id bên của U>,<id bên của V>,<nhãn>`, được viết bằng hex thường. Các điều khoản từ chối mọi id khác.

V chấp thuận gateway và gọi `pay` với id đó. Gateway chuyển ERC-20 từ V sang bên nhận và ghi lại nhánh thanh toán. `Tiến hành` dùng các điều khoản đã ký để thực thi phần phân bổ từ U sang V.

Một giao dịch chuyển ERC-20 thuần túy không ghi lại nhánh nào. Ngay cả việc chuyển cùng token cho cùng bên nhận trong cùng khối cũng không thể thay thế cho `pay`. [luồng thanh toán của thiết kế](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/docs/DESIGN.md#the-flows) giải thích ràng buộc này.

## Những gì bằng chứng xác định

Mỗi nhánh ghi loại, id, token, tài khoản, số lượng và bên Canton nếu có. Gateway băm các nhánh theo thứ tự. `Tiến hành` kiểm tra rằng các nhánh đính kèm của nó tạo ra hàm băm trong trạng thái gateway đã được chứng minh. Thiếu, thừa, đổi thứ tự hoặc thay đổi một nhánh nào sẽ làm giao dịch thất bại. Việc kiểm tra cũng bao phủ các khối không có nhánh.

Việc chứng minh khối không giữ chỗ cho phần phân bổ Canton của nó. Người gửi vẫn có thể lấy lại phần phân bổ trước khi thanh toán. Nếu điều đó xảy ra sau khi chứng minh, Canton từ chối `Tiến hành` và reth quay về khối đã cam kết gần nhất. Cùng một khối đã chứng minh không thể được gửi lại với nhánh của nó bị xóa. Bản dựng tiếp theo bỏ qua khoản thanh toán, như được minh họa trong [chạy 4](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/demo/README.md#results).

## Giới hạn token và quyền lưu ký

Các token Canton được giữ bởi bên gateway trên participant của operator. Bất kỳ ai vận hành participant đó đều có thể di chuyển chúng. Đăng ký một token cũng có nghĩa là tin tưởng mã Daml của sổ đăng ký của nó, mã này chạy với thẩm quyền của gateway.

Các token được gửi trực tiếp đến địa chỉ EVM của gateway không thể khôi phục. Nếu một token tính phí chuyển hoặc bằng cách khác chuyển một số lượng khác, nhánh thanh toán vẫn ghi lại số lượng đã yêu cầu, chứ không phải số lượng thực tế được chuyển. Đọc [Mô hình tin cậy và các giới hạn](/vi/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/vi/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.