Behind the Scenes of TON: Lessons Learned on Deploying Smart Contracts, Part 2

За кулисами TON: уроки, извлеченные из развертывания смарт-контрактов, часть 2

Это вторая статья в нашей серии об интеграции каналов оплаты в открытой сети Telegram. В первой части мы введены сеть, подробно рассказал о нашем опыте проведения конкурса и объяснил, как работают синхронные и асинхронные смарт-контракты. В качестве следующего дополнения к серии в этой статье подробно рассказывается, как мы построили канал синхронных платежей в сети во время Конкурс TON в сентябре Здесь мы будем говорить только о Fift (язык программирования TON общего назначения) и FunC (язык программирования TON для написания умных контрактов).

Тонна белая бумага обеспечивает Более подробная информация о платежных каналах, но мы кратко объясним их еще раз.

Связанный: За кулисами TON: уроки, извлеченные из развертывания смарт-контрактов, часть 1

Канал синхронного платежа позволяет отправлять транзакции между двумя пользователями вне сети, используя активы внутри сети. В нашем случае — ГРАММ. Одна сторона не может обмануть другую вне цепочки, и транзакции выполняются намного быстрее, чем выполнение транзакций блокчейна первого уровня, поскольку для их завершения используются только пользовательские устройства без необходимости записи в блокчейн. Существует две основные операции: пополнение и снятие. Вывод является наиболее сложным для осуществления.

Чтобы сделать правильный вывод, пользователи должны предоставить самую свежую информацию о состоянии своего канала. Состояние состоит из шагов и цифровых подписей каждого участника, что означает, что невозможно предоставить правильное состояние с данными, которые не были утверждены обеими сторонами.

Чтобы развернуть умный контракт, вам нужно написать скрипт развертывания в Fift и скомпилировать его в .boc (мешок с клетками) файл. Это позволяет создать несколько ячеек, которые будут связаны друг с другом. Затем GRAM необходимо отправить по адресу, который был получен во время выполнения сценария развертывания. Как только ГРАММЫ окажутся на адресе, отправьте .boc файл в сеть и контракт будет развернут.

Чтобы выполнить вызов функции, напишите сценарий, который будет отправлять внешнее сообщение в развернутый смарт-контракт.

По сути, все, что на TON — это ячейка с некоторыми ссылками. Мешок ячеек — это структура данных, разработанная командой Telegram. Это актерская модель. Более подробная информация на Тонна белой бумаги: «Все это мешок с клетками». Вы создаете ячейку, которая будет взаимодействовать с другой ячейкой при ее развертывании.

каждый пиринговый Платежный канал представляет собой единый умный договор. Давайте посмотрим на сегменты умного контракта.

Связанный: Чего ожидать от открытой сети Telegram: взгляд разработчика

Часть развертывания

Сериализованный скрипт Fift используется для развертывания контракта. Это сохраняется в .boc файл и отправляется в сеть через TON Cli, легкий клиент сети.

Последняя ячейка в стеке является результатом выполнения вышеупомянутого сценария Fift.

Обычные сегменты сценария развертывания Fift включают (но не ограничиваются ими):

  1. Код смарт-контракта в виде отдельной ячейки (обычно пишется в FunC, затем компилируется в код Fift ASM и включается в основной .fif использование файла путь к скомпилированному-asm.fif).
  2. Первоначальное хранение смарт-контракта (см. Ниже).
  3. Новый адрес смарт-контракта (хеш из начального состояния смарт-контракта, который также включает ячейку кода смарт-контракта и начальную ячейку хранения).
  4. Аргументы первого звонка recv_external функция (количество аргументов и тип зависит от договора).
  5. Внешняя ячейка сообщения для инициализации, которая будет сериализована в байты и упакована в .boc файл, который содержит все данные из пунктов 1–4 и некоторые дополнительные, которые до сих пор не хватает документации.

Когда .boc компилируется, определенное количество GRAM необходимо отправить на адрес смарт-контракта. Файл .boc должен быть отправлен в сеть для инициализации смарт-контракта. Количество GRAM зависит от размера и объема вычислений внешней ячейки сообщений развернутого смарт-контракта (а не только от ее кода). Газ × цена на газ берется из развернутого баланса умного контракта. Эта сумма является минимумом, необходимым для оплаты газа во время развертывания.

Представление хранилища:

  1. SEQNO 32 бита
  2. Состояние контракта 4 бита
  3. first_user_pubkey. Открытый ключ первой стороны 256 бит
  4. second_user_pubkey. Открытый ключ второй стороны 256 бит
  5. time_to_send. Время для отправки после первого фактического состояния, представленного 32 бита (действует до 2038 года)
  6. depositSum. Внесенная сумма от двух участников до 121 бит
  7. state_num 64 бита, Текущее количество состояний, которые произошли

Ячейка содержит до 1023 бит и четыре ссылки на другие ячейки. Мы смогли разместить все хранилище на одной ячейке без единой ссылки. Наше хранилище может занимать максимум 765 бит.

Все умные контрактные государства

0x0 — состояние развертывания

0x1 — Канал открыт и готов к сдаче

0x2 — Депозит пользователем 1

0x3 — Депозит пользователем 2

0x4 — Депозит заблокирован. Можно предусмотреть состояние смарт-контракта

0x5 — Пользователь 1 указал состояние

0x6 — Пользователь 2 указал состояние

0x7 — канал закрыт

Депонирование

Функция депозита получает сообщение от простого кошелька (перевода) с дополнительной полезной нагрузкой тела.

Внесение ГРАММ на канал:

  1. Пользователь генерирует дополнительную полезную нагрузку тела, которая включает в себя сообщение (например, 1 бит) и его подпись в отдельном .fif файл.
  2. Полезная нагрузка тела компилируется в .boc файл.
  3. Из этого загружается тело .boc файл в файл .fif в качестве ссылки «передача» ячейки тела ( .fif отвечает за перевод ГРАММОВ с кошелька).
  4. recv_external функция вызывается с аргументами (сумма депозита и адрес назначения канала), когда компилируется .fif файл отправлен в сеть.
  5. send_raw_message функция выполнена. Депонированные GRAM и дополнительная полезная нагрузка тела отправляются на адрес назначения смарт-контракта P2P-канала.
  6. recv_internal вызывается функция умного контракта канала P2P. ГРАММЫ принимаются по контрактам канала.

Функция депозита может быть вызвана, если состояние смарт-контракта канала P2P 0x1 или 0x2 или 0x3,

Код FunC, который проверяет состояние:

1 "src =" https://s3.cointelegraph.com/storage/uploads/view/fec2786551d613f2491a5d1d0ed9e80e.png "title =" 1

Только владельцы открытых ключей (записанных в начальном хранилище) могут вносить депозит. Интеллектуальный контракт проверяет подпись каждого внутреннего сообщения, которое будет получено через recv_internal функция. Если сообщение подписано одним из владельцев открытых ключей, статус контракта изменится на 0x2 или 0x3 (0x2 если это открытый ключ 1 и 0x3 если это открытый ключ 2). Если все пользователи сделали депозит, статус контракта изменится на 0x4 на тот же вызов функции.

Код FunC, отвечающий за изменение статуса контракта:

2 "src =" https://s3.cointelegraph.com/storage/uploads/view/8e0a38712f545a84e75550886b981c54.png "title =" 2

Возврат

Средства могут быть возвращены, если контрагент не внес депозит в срок.

Для этого пользователю необходимо предоставить свой адрес и подпись с помощью внешнего сообщения. Средства будут возвращены, если предоставленная подпись принадлежит открытому ключу 1 или открытому ключу 2 (лицам, сделавшим депозит) и статус договора 0x2 или 0x3,

Код FunC, который отвечает за проверку заявки на возврат:

3 "src =" https://s3.cointelegraph.com/storage/uploads/view/b7aa62614b98dffc5bfb0a7765037cff.png "title =" 3

Вывод

Каждое лицо должно предоставить состояние выхода, подпись этого состояния и подпись основного сообщения.

Государственные детали:

  1. Умный контрактный адрес (чтобы исключить возможность входа в правильное состояние с предыдущего P2P-канала с теми же участниками).
  2. Финальный баланс первого участника.
  3. Финальный баланс второго участника.
  4. Государственный номер.

Подпись сообщения тела сохраняется в главном слайсе, состояние сохраняется в отдельной ссылке, а подписи состояния хранятся в виде ссылок на ссылку «подписи», чтобы избежать переполнения ячейки.

Этапы вывода средств:

  1. Проверьте подпись основного сообщения и определите участника.

4 "src =" https://s3.cointelegraph.com/storage/uploads/view/2bc23eac21afee3c36f71d8adaa342c7.png "title =" 4

  1. Убедитесь, что настала очередь участника или прошло 24 часа с момента последнего входа в состояние. Напишите очередь текущего участника (0x5 или 0x6) к Состояние контракта,

Пример правильной подписи основного сообщения для владельца first_user_pubkey:

5 "src =" https://s3.cointelegraph.com/storage/uploads/view/be5d23cf5c69a7b5a13fb84d54731e2c.png "title =" 5

Затем мы должны убедиться, что адрес смарт-контракта, указанный государству, является фактическим адресом контракта:

6 "src =" https://s3.cointelegraph.com/storage/uploads/view/34c973fd686dfd3e92390527df929504.png "title =" 6

Далее нам нужно проверить подписи под государством:

7 "src =" https://s3.cointelegraph.com/storage/uploads/view/9bf517ce3c99327ce8297a8438b8c32d.png "title =" 7

После этого есть два утверждения:

  1. Сумма депозита из хранилища должна быть равна сумме общих остатков участников.
  2. Новый введенный номер состояния должен быть больше или равен предыдущему.

В случае new_state_num> state_num нам нужно хранить new_state_num с новым time_to_send равный сейчас () + 86401 (24 часа от текущего времени), а также записать фактический статус контракта (0x5, если первый участник совершил звонок, в противном случае 0x6).

В другом случае, если new_state_num == state_num нам нужно добавить еще две ссылки на ссылку «подписи» с адресами каждого участника и подписи под их адресами.

Если подписи верны, GRAM снимаются с одного адреса и помещаются в адрес владельца.

9 "src =" https://s3.cointelegraph.com/storage/uploads/view/80e8e8d78e61f77b9a20ab15955be261.png "title =" 9

Каждый раз, когда происходит успешный вызов, нам нужно хранить все данные хранилища, даже если они не меняются.

Нерешенные вопросы

Предполагается, что первый пользователь развернул контракт, а участники договорились о комиссиях. Соглашение о комиссиях в нашем случае выходит за пределы цепочки.

Мы еще не выяснили, как рассчитать общую комиссию, принимая во внимание тот факт, что игроки могут писать не относящиеся к делу состояния и записывать фактические состояния после этого. Помните, что при каждом успешном звонке нам необходимо платить комиссионные с умного контракта канала P2P. recv_internal или recv_external функции.

Как упоминалось ранее, нам нужно добавить некоторое количество GRAM в адрес неразумного будущего умного контракта, чтобы его инициализировать.

В последний день конкурса разработчики TON сделанный приверженность stdlib.fc библиотека с новой функцией, которая позволяет получить реальный баланс умного контракта.

10

Предложения о возможных решениях этой проблемы приветствуются!

Вывод

FunC и Fift предоставляют любому разработчику доступ к низкоуровневому миру разработки программного обеспечения, открывая новые возможности и функции для разработчиков блокчейнов, которые уже привыкли Ethereum или любая другая умная контрактная платформа. Важно, чтобы TON был изолированным блокчейном, поэтому реализация интеллектуальных контрактов для него более сложна. Например, контракты Ethereum работают синхронно и не требуют обработки ситуаций, таких как ожидание ответа от другого контракта.

Асинхронный способ связи по интеллектуальному контракту — это единственная возможность сделать его масштабируемым, и TON имеет эти параметры. Наше решение оказалось более трудным для реализации, чем Solidity, но всегда есть компромисс. Определенно возможно построить продвинутый умный контракт на TON, и способ, которым команда TON справилась с этим, очень впечатляет. Мы с нетерпением ждем новых библиотек и инструментов, которые помогут развернуть и построить контракты FunC.

Мы полностью наслаждались всеми задачами и хотели бы, чтобы у нас было больше времени для их выполнения. Тем не менее, мы выиграли два приза на конкурсе TON: первое место за лучший канал синхронных платежей, а также третье место за лучший канал асинхронных платежей.

Мы поделимся своими личными отзывами в третьей части.

Мнения, мысли и мнения, выраженные здесь, являются одними только авторами и не обязательно отражают или представляют взгляды и мнения Cointelegraph.

Эта статья была соавтором Ник козлов и Кирилл Кузнецов,

Ник козлов является техническим директором и соучредителем Button Wallet, разработчиком и исследователем программного обеспечения, а также одним из победителей конкурса TON.

Кирилл Кузнецов является соучредителем Button Wallet, а также одним из победителей конкурса TON.





Источник: За кулисами TON: уроки, извлеченные из развертывания смарт-контрактов, часть 2


Похожие материалы по теме: За кулисами TON: уроки, извлеченные из развертывания смарт-контрактов, часть 2

Leave a comment