tonpie.io

Решено

В целом

В порядке байтов с большим числом байтов **самый значимый байт (MSB) хранится по самому низкому адресу памяти, а наименее значимый байт (LSB) хранится по самому высокому адресу памяти.

Это также известно как сетевой порядок байтов, потому что это формат, используемый в интернет-протоколах, таких как TCP/IP в целом.

Биг-энд в TVM

В TVM целые числа внутри ячеек по умолчанию сериализуются с использованием формата big-endian. Это означает, что когда целое число преобразуется в последовательность байтов для сохранения, самый старший байт помещается в начало.

Пример 1: Сериализация с большим порядком байтов

Рассмотрим 16-разрядное целое число 0xABCD. В формате big-endian он будет сохранен в виде:

0xAB 0xCD Little-Endian со специальными примитивами

В тексте также упоминаются специальные примитивы, такие как STULE, которые позволяют (де) сериализовать целые числа с малым порядком следования. В системе с младшим порядком байтов первым сохраняется наименее значимый байт.

Пример 2: Сериализация в строгом порядке

Используя little-endian для того же целого числа 0xABCD, оно будет сохранено как:

0xCD 0xAB Отношение к TVM По умолчанию используется Big-Endian : TVM использует big-endian для стандартной сериализации целых чисел внутри ячеек, что делает его машиной с большим порядком байтов в этом отношении. Внутреннее представление: Внутреннее представление целых чисел в TVM зависит от реализации и не имеет отношения к тому, как работает TVM. Примитивы с литтл-эндианом : Доступны специальные примитивы для обработки целых чисел с литтл-эндианом, которые могут быть полезны при взаимодействии с системами или форматами данных, использующими литтл-эндиан. Это может быть важно для анализа пользовательских сообщений из внешних источников. Краткое описание

Понимание последовательности имеет жизненно важное значение при работе с низкоуровневыми манипуляциями с данными в TVM.

По умолчанию TVM использует big-endian, но при необходимости существуют инструменты для обработки данных в формате little- endian.

Выбор между big-endian и little-endian влияет на то, как данные считываются из памяти и записываются в нее, поэтому важно знать, какой конкретный формат используется в контексте TVM или любой другой системы, с которой вы работаете.

Согласно документации, мы находим функциональный код commit(), описанный следующим образом:

Commits the current state of registers c4 (“persistent data”) and c5 (“actions”) so that the current execution is considered “successful” with the saved values, even if an exception is thrown later.

https://docs.ton.org/develop/func/stdlib#commit

Описание может сбить с толку. Вот несколько вопросов, которые необходимо прояснить:

Что мы получим в виде исключения или ошибки, если мы уже зафиксировали код в смарт-контракте? * Почему нам нужно фиксировать данные или статус в коде смарт-контракта, даже если в конечном итоге это приведет к ошибке? * Каковы будут последствия, если смарт-контракт получит "статус неизвестной ошибки"?

Оригинал вопроса

Решено

К сожалению, ответ отрицательный.

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

Нет, обновление еще не реализовано в test-net.

В настоящее время блокчейн TON состоит только из одной рабочей цепочки и мастер-цепочки. Весь код смарт-контрактов в masterchain и базовой рабочей цепочке выполняется TVM (виртуальной машиной Ton). Но TON предоставляет возможность создавать больше рабочих цепочек в будущем. И в техническом документе Николая Дурова упоминается, что эти гипотетические будущие рабочие цепочки могли бы использовать разные виртуальные машины:

Разные рабочие цепочки могут иметь разные правила, что означает разные форматы адресов учетных записей, разные форматы транзакций, разные виртуальные машины (ВМ) для смарт-контрактов, разные базовые криптовалюты и так далее.

Итак, я пытаюсь понять: обязательно ли эти "разные виртуальные машины" должны быть похожи на TVM, или они могут быть очень разными, как EVM? Мог бы кто-нибудь гипотетически создать рабочую цепочку TON, где код выполнялся бы EVM вместо TVM, так что код, написанный для EVM, можно было бы повторно использовать в TON?

Оригинал вопроса

Решено

Вычисление цены на газ для операций "get / set" на хэш-карте в виртуальной машине TON (TVM) может быть немного сложным, поскольку оно "динамическое" и зависит от "размера словаря", которым манипулируют.

Хотя точной формулы для определения цены на газ не существует, вы можете оценить ее, используя следующий подход:

Gas Price ≈ 600 * log2(SIZE)

Здесь "РАЗМЕР" представляет размер словаря. Цена на газ, полученная по этой формуле, выражена в единицах стоимости газа, что означает, что она измеряется в "микротонах (10^-6 тонн)`.

Пожалуйста, обратите внимание, что эта оценка основана на тестах и может быть не полностью точной во всех случаях.

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

У меня ошибка с кодом выхода 5.

В списке кодов выхода TVM в документации указано, что это означает "Целое число вне ожидаемого диапазона".:

https://docs.ton.org/learn/tvm-instructions/tvm-exit-codes

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

Оригинал вопроса

В официальной документации есть список стандартного кода выхода TVM: https://docs.ton.org/learn/tvm-instructions/tvm-exit-code

Вот он:

0 - Стандартный код завершения успешного выполнения. 1 - Альтернативный код завершения успешного выполнения. 2 - Нижний поток стека. Последний операционный код потреблял больше элементов, чем есть в стеках. 1 3 - Переполнение стека. В стеке было сохранено больше значений, чем разрешено этой версией TVM. 4 - Целочисленное переполнение. Целое число не вписывается в -2256 ≤ x < 2256 или произошло деление на ноль. 5 - Целое число вне ожидаемого диапазона. 6 - Неверный код операции. Инструкция неизвестна в текущей версии TVM. 7 - Введите ошибку проверки. Аргумент примитива имеет неправильный тип значения. 1 8 - Переполнение ячейки. Запись в builder невозможна, так как после операции осталось бы более 1023 бит или 4 ссылки. 9 - Ячейковый нижний поток. Чтение из примитива slice пыталось прочитать больше битов или ссылок, чем есть на самом деле. 10 - Ошибка в словаре. Ошибка при работе со словарем (хэш-картами). 11 - Чаще всего вызывается попыткой вызвать get-метод, идентификатор которого не был найден в коде (отсутствует модификатор method_id или неверное имя get-метода, указанное при попытке его вызова). В документах TVM это описано как "Неизвестная ошибка, может быть вызвана пользовательскими программами". 12 - Брошен TVM в ситуациях, которые считаются невозможными. 13 - Ошибка с нехваткой газа. Выбрасывается TVM, когда оставшийся газ становится отрицательным. 32 - Список действий недействителен. Устанавливается на этапе действия, если регистр c5 после выполнения содержит неразрешимый объект. 32 (то же, что и предыдущий) - Идентификатор метода не найден. Возвращается TonLib при попытке выполнить несуществующий метод get. 34 - Действие недействительно или не поддерживается. Устанавливается на этапе действия, если текущее действие не может быть применено. 37 - Недостаточно ТОННЫ. Сообщение отправляет слишком много TON (или не хватает TON после вычета сборов). 38 - Недостаточно дополнительных валют. -14 - Это означает ошибку нехватки газа, такую же, как 13. Отрицательный, потому что его нельзя подделать

Насколько я понимаю, существуют также пользовательские коды выхода с другими, реализованными в конкретных смарт-контрактах, в этом случае вам нужно обратиться к конкретному контракту, чтобы выяснить причину.

Известны коды выхода TVM в диапазоне от -14 до 38, они перечислены на соответствующей странице документации: https://docs.ton.org/learn/tvm-инструкции/tvm-кодывыхода

Но что, если я получу "код выхода 75"? Есть ли какая-то ошибка? Где я могу проверить, что это за ошибка?

Этот вопрос был импортирован из чата Telegram: <***Скрыто***

click to show

Оригинал вопроса

Решено

Чтобы лучше понять роль "CRC-32" в сети TON и его связь с "пакетом ячеек" (BOCs), важно сначала ознакомиться с концепцией циклической проверки избыточности (CRC) и ее основным назначением.

** CRC - это широко используемый метод проверки целостности цифровых данных.** ** В качестве алгоритма обнаружения ошибок ** он проверяет наличие ошибок в цифровых данных во время передачи или хранения.

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

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

**В сети TON CRC-32 используется в качестве компонента формата сериализации пакета ячеек (BOC) для обеспечения целостности данных. ** BOC - это двоичный формат, представляющий дерево ячеек, используемый для хранения и передачи данных в сети TON. Каждая ячейка в BOC содержит небольшой фрагмент данных и может содержать ссылки на другие ячейки.

Во время сериализации или десериализации BOC для данных ячейки вычисляется контрольная сумма CRC-32, чтобы гарантировать, что они не были повреждены во время передачи или хранения. Если вычисленная контрольная сумма CRC-32 не совпадает с суммой, сохраненной в BOC, это указывает на то, что данные повреждены и их необходимо повторно передать или извлечь.

Для получения дополнительной информации о CRC-32 и его использовании в сети TON обратитесь к следующим ресурсам:

TON Documentation on CRC-32: https://docs.ton.org/develop/data-formats/crc32 * Online CRC-16 Calculator: https://emn178.github.io/online-tools/crc16.html

Решено

В TVM существуют ограничения по памяти, но они могут быть не такими строгими, как в EVM. Это связано с тем, что TVM разработан таким образом, чтобы быть более эффективным и гибким с точки зрения управления ресурсами. Однако разработчикам все равно следует помнить об использовании ресурсов при создании смарт-контрактов для бесплатной платформы TON.

Некоторые соображения по использованию памяти в TVM:

Управление памятью: TVM использует более сложную модель памяти, чем EVM, что обеспечивает более эффективное управление памятью. Однако это не означает, что разработчики могут игнорировать использование памяти, поскольку чрезмерное потребление памяти все равно может привести к проблемам с производительностью или увеличению затрат на выполнение.

Затраты на газ: Подобно EVM, TVM также использует газовую модель для выполнения смарт-контрактов, где газ представляет собой вычислительные затраты на выполнение операций. Хотя затраты на газ в TON могут быть не такими значительными, как в Ethereum, по-прежнему важно оптимизировать код вашего смарт-контракта, чтобы минимизировать потребление газа и затраты на выполнение.

Производительность и масштабируемость: Написание эффективного кода, оптимизирующего использование памяти, имеет решающее значение для обеспечения хорошей производительности и масштабируемости ваших смарт-контрактов в сети Free TON. Это помогает поддерживать общую работоспособность сети и позволяет ей поддерживать большее количество смарт-контрактов и транзакций.

Хранение данных: В сети TON смарт-контракты используют постоянное хранилище, называемое "Persistent Data Storage" (PDS), для хранения своего состояния. Разработчикам следует помнить о том, какой объем данных они хранят в PDS, поскольку большие требования к хранилищу могут привести к увеличению затрат и потенциальным проблемам с производительностью.

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

Решено

В блокчейне TON, как только транзакция включается в блокчейн, она считается ** "подтвержденной" ** и не может быть отменена. Таким образом, скорость, с которой транзакции включаются в блокчейн, имеет решающее значение для многих вариантов использования, особенно для децентрализованных приложений, которые полагаются на быструю и эффективную обработку транзакций.

В отличие от некоторых других блокчейнов, таких как Ethereum, "блокчейн TON не допускает динамической корректировки платы за газ в зависимости от рыночного спроса`. Цены на газ одинаковы для всех и определяются конфигурацией сети. * ** Таким образом, невозможно "заплатить больше", чтобы заставить валидаторов отдавать приоритет вашей транзакции перед другими.** *

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

Решено

Адреса, перечисленные в двух источниках, отличаются, поскольку они по-разному закодированы. Однако, по сути, это один и тот же адрес. Чтобы преобразовать адрес в "каноническую", не удобную для пользователя форму, вы можете использовать следующий код на JavaScript:

new TonWeb.Address('kf-kkdY_B7p-77TLn2hUhM6QidWrrsl8FYWCIvBMpZKprBtN').toString(false);

Это преобразует адрес в каноническую форму -1:a491d63f07ba7eefb4cb9f685484ce9089d5abaec97c15858222f04ca592a9ac, которая совпадает с адресом, указанным в первом источнике.

Решено

Короткий ответ - нет. EVM и TVM принципиально отличаются друг от друга, поэтому невозможно напрямую перенести ваш код Solidity в TVM. Однако, возможно, что в будущем будут разработаны инструменты, позволяющие компилировать байт-код ABI в TL-B на основе TVM.

Для получения дополнительной информации об основных концепциях и сравнения двух блокчейнов вы можете найти дополнительные подробности здесь: https://blog.ton.org/six-уникальныеаспектыблокчейнаton,которыеудивятразработчиковsolidity.

Для более глубокого понимания различий между Ethereum, Solana и TON сообщество TON создало всеобъемлющий 10-страничный документ, который можно найти здесь: https://ton.org/comparison_of_blockchains.pdf.

Решено

Основной репозиторий для TON существует на GitHub и написан на C++:

https://github.com/ton-blockchain/ton/tree/master/crypto/vm

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

() recv_internal(int balance, int msg_value, cell in_msg_cell, slice in_msg) {} () recv_internal(int msg_value, cell in_msg_cell, slice in_msg) {} () recv_internal(cell in_msg_cell, slice in_msg) {} () recv_internal(slice in_msg) {}

Вы должны проанализировать in_msg_body, чтобы получить код операции, основанный на том, как отправитель сохранил код операции в сообщении.

Обычно он хранится как первый 32-битный внутри in_msg_body.

"store_uint" - это, предположительно, функция или метод, который принимает два параметра. * Первый параметр, "0x18", представляет собой шестнадцатеричное представление числа. В десятичной форме "0x18" равно 24. * Вторым параметром, "6", может быть размер или длина сохраняемых данных, часто относящихся к количеству битов. В этом случае целое число 24 сохраняется в 6-битном формате.

В общем, сериализация - это процесс преобразования структур данных или состояний объектов в формат, который может быть сохранен, передан и реконструирован позже. Это часто используется при сетевом обмене данными, когда необходимо отправить данные по сети или когда необходимо сохранить сложные структуры данных для последующего использования.

https://docs.ton.org/develop/smart-contracts/messages#message-layout