> 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/ru/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 шлюзу, а оператор выступает исполнителем. Вкладчик подписывает `DepositRequest` в котором указаны идентификатор депозита, EVM-адрес, которому разрешено выполнить claim, и аллокация.

Этот EVM-адрес вызывает `claim`. Шлюз выпускает токены его вызывающему и записывает запись депозита. Получателю нужен tROME для газа. Сборщик сопоставляет запись с запросом, зарегистрированным токеном и аллокацией.

`Аванс` исполняет аллокацию в хранение шлюза и подтверждает блок, который выпустил обёрнутые токены. Обёрнутый токен имеет 10 знаков после запятой, что соответствует суммам Canton. Пересчёт между этими двумя суммами точен, без округления.

## Вывод к стороне Canton

Держатель вызывает `withdraw` с обёрнутым токеном, суммой и полным идентификатором стороны Canton. Шлюз сжигает обёрнутые токены и записывает получателя в запись.

Получатель должен подписать `WithdrawalAcceptance`. Она остаётся активной, пока не будет архивирована. Сборщику также нужно достаточно незаблокированных средств шлюза по зарегистрированному инструменту. Он исключает транзакцию, если эти условия не выполняются.

`Аванс` выплачивает получателю через фабрику переводов реестра токенов. Перевод Canton и блок, содержащий сжигание, подтверждаются вместе. Сборщик включает не более одного вывода инструмента на блок, как описано в [README сборщика](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/builder/README.md).

## Привязать платёж к одной аллокации

U выделяет токен Canton V. U и V подписывают `DvpTerms` в котором указаны аллокация, идентификатор платежа, EVM-токен, EVM-получатель и сумма. Идентификатор платежа — это SHA-256 текста UTF-8 `<идентификатор стороны U>,<идентификатор стороны V>,<метка>`, записанного строчными шестнадцатеричными символами. Условия отвергают любой другой идентификатор.

V одобряет шлюз и вызывает `pay` с этим идентификатором. Шлюз переводит ERC-20 от V получателю и записывает запись платежа. `Аванс` использует подписанные условия, чтобы исполнить аллокацию от U к V.

Обычный перевод ERC-20 не фиксирует никакой записи. Даже перевод того же токена тому же получателю в том же блоке не может служить заменой для `pay`.  [платёжный поток этой схемы](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/docs/DESIGN.md#the-flows) объясняет эту привязку.

## Что фиксирует доказательство

Каждая запись фиксирует свой тип, идентификатор, токен, счёт, сумму и, при наличии, сторону Canton. Шлюз вычисляет хэш записей по порядку. `Аванс` проверяется, что прикреплённые записи дают хэш в доказанном состоянии шлюза. Отсутствующая, лишняя, переупорядоченная или изменённая запись приводит к сбою транзакции. Проверка также охватывает блоки без записей.

Доказательство блока не резервирует его аллокацию Canton. Отправитель всё ещё может забрать аллокацию обратно до расчёта. Если это происходит после доказательства, Canton отклоняет `Аванс` и reth возвращается к последнему зафиксированному блоку. Тот же доказанный блок нельзя повторно отправить без его записи. Следующая сборка исключает платёж, как показано в [прогон 4](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/demo/README.md#results).

## Ограничения на токены и хранение

Токены Canton хранятся у стороны шлюза на участнике оператора. Тот, кто управляет этим участником, может перемещать их. Регистрация токена также означает доверие к коду Daml его реестра, который выполняется с полномочиями шлюза.

Токены, отправленные напрямую на EVM-адрес шлюза, невозможно восстановить. Если токен взимает комиссию за перевод или иным образом переводит другую сумму, запись платежа всё равно фиксирует запрошенную сумму, а не фактически переведённую. Читайте [Модель доверия и ограничения](/ru/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/ru/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.