На что следует обратить внимание при работе с TON Blockchain
Эта страница переведена сообществом на русский язык, но нуждается в улучшениях. Если вы хотите принять участие в переводе свяжитесь с @alexgton.
В этой статье мы рассмотрим и обсудим элементы, которые необходимо учитывать тем, кто хочет разрабатывать приложения TON.
Чек-лист
1. Коллизии имен
Переменные и функции Func могут содержать практически любой допустимый символ. Т.е. var++, ~bits, foo-bar+baz, включая запятые, являются допустимыми именами переменных и функций.
При написании и проверке кода Func следует использовать Linter.
2. Проверьте значения выбросов
Каждый раз, когда выполнение TVM завершается нормально, оно останавливается с кодами выхода 0 или 1. Хотя это происходит автоматически, выполнение TVM может быть прервано неожиданным образом, если коды выхода 0 и 1 будут выброшены непосредственно командой throw(0) или throw(1).
3. Func - строго типизированный язык, в структурах данных которого хранится именно то, что они должны хранить
Очень важно следить за тем, что делает код и что он может вернуть. Помните, что компилятор учитывает только сам код и только в его начальное состояние. После выполнения определенных операций сохраненные значения некоторых переменных могут измениться.
Чтение неожиданных значений переменных и вызов методов для типво данных, которые не должны иметь таких методов (или их возвращаемые значения сохраняются неправильно), являются ошибками и не пропускаются как "предупреждения" или "уведомления", а приводят к недостижимому коду. Помните, что сохранение неожиданного значения может быть допустимым, однако его чтение может вызвать проблемы, например, код ошибки 5 (целое число вне ожидаемого диапазона) может быть выброшен для целочисленной переменной.
4. Сообщения имеют режимы
Необходимо проверять режим сообщения, в частности, его взаимодействие с предыдущими отправленными сообщениями и платой за хранение. Возможной проблемой может быть неучет платы за хранение, в этом случае у контракта может закончиться TON, что приведет к неожиданным сбоям при отправке исходящих сообщений. Вы можете просмотреть режимы сообщений здесь.
5. TON полностью реализует модель акторов
Это означает, что код контракта может быть изменен. Его можно изменить либо постоянно, используя директиву TVM SETCODE, либо во время выполнения, устанавливая в реестре TVM кода новое значение ячейки до окончания выполнения.
6. Блокчейн TON имеет несколько фаз транзакций: фаза вычислений, фаза действий и фаза отскока.
На вычислительной фазе выполняется код смарт-контрактов, и только после этого производятся действия (отправка сообщений, модификация кода, изменение библиотек и другие). Поэтому, в отличие от блокчейнов на базе Ethereum, Вы не увидите код завершеия вычислительной фазы, если ожидаете, что отправленное сообщение завершится неудачно, так как это происходит не в вычислительной фазе, а позже, в фазе выполнения действий.
7. Контракты TON являются автономными
Контракты в блокчейне могут находиться в отдельных шардах, обрабатываемых другим набором валидаторов, а это значит, что разработчик не может получить данные из других контрактов по запросу. Таким образом, любая коммуникация осуществляется асинхронно, путем отправки сообщений.
8. В отличие от других блокчейнов, TON не содержит сообщений о возврате, только коды выхода
Прежде чем приступить к программированию смарт-контракта TON, следует продумать дорожную карту кодов выхода для потока кода (и задокументировать ее).
9. Функции Func, имеющие идентификаторы method_id, имеют идентификаторы методов
Они могут быть заданы либо явно "method_id(5)", либо неявно компилятором func. В этом случае их можно найти среди объявлений методов в файле ассемблера .fift. Два из них предопределены: один для приема сообщений внутри блокчейна (0), обычно называемый recv_internal, и другой для приема сообщений извне (-1), recv_external.
10. Криптоадрес TON может не содержать ни монет, ни кода
Адреса смарт-контрактов в блокчейне TON детерминированы и могут быть предварительно вычислены. TON-аккаунты, связанные с адресами, могут даже не содержать кода, что означает, что они не инициализированы (если не были развернуты) или заморожены, не имея больше ни хранилища, ни монет TON, если было отправлено сообщение со специальными флагами.
11. Адреса TON могут иметь три представления
Адреса TON могут иметь три представления.
Полное представление может быть либо "сырым" (workchain:address), либо "user-friendly". С последним чаще всего сталкиваются пользователи. Оно содержит байт метки, указывающий на то, является ли адрес bounceable или not bounceable, и байт идентификатора воркчейна. Эту информацию следует учитывать.
12. Отслеживайте недостатки в выполнении кода
В отличие от Solidity, где видимость методов настраивается вами, в случае с Func видимость ограничивается более сложным способом - либо с помощью отображения ошибок, либо через условия if.
13. Следите за газом перед отправкой bounced-сообщений
В случае, если смарт-контракт отправляет отскочившие сообщения со значением, указанным пользователем, убедитесь, что соответствующая плата за газ вычтена из возвращенной суммы, чтобы избежать потери средств.
14. Отслеживайте обратные вызовы и их сбои
Блокчейн TON является асинхронным. Это означает, что сообщения необязательно должны приходить последовательно. Например, когда приходит уведомление о неудачном выполнении действия, оно должно быть обработано корректно.
15. Проверьте, был ли отправлен флаг отскока при получении внутренних сообщений
Вы можете получать отскакивающие сообщения (уведомления об ошибках), которые следует обработать.
16. Напишите защиту от повторной отправки для внешних сообщений:
Существует два пользовательских решения для кошельков (смарт-контрактов, хранящих деньги пользователей): seqno-based (проверка счетчика, чтобы не обрабатывать сообщение дважды) и high-load (хранение идентификаторов процессов и сроков их действия).
Ссылки
Автор оригинальной статьи: 0xguard