tonpie.io

Решено

Boc не ограничен по размеру, фактически все состояние блокчейна представляет собой ячейку с кучей ячеек, обернутых внутри них. Все - это клетка!

Размер внешнего сообщения ограничен 64 Кб, что может ограничить размер boc, который вы пытаетесь создать с помощью своей логики смарт-контракта. Вы можете видеть, что это определено в клиенте lite, но оно может быть изменено:

https://github.com/ton-blockchain/ton/blob/db3619ed310484fcfa4e3565be8e10458f9f2f5f/validator/impl/external-message.hpp#L40

Решено

Вы можете использовать компонент tonweb-contract пакета TonWeb.

Сначала создайте свой класс contract:

import {Contract} from 'web3-eth-contract'; export class MyContract extends Contract { constructor(provider, options) { // insert the bytes of your code here options.code = hexToBytes('abcd..'); super(provider, options); // add definitions of the functions of the contract this.method.myMethod = ... } // @override createDataCell() { } // @override createSigningMessage(options) { } }

Позже вы сможете выполнить развертывание с экземпляром контракта:

const contract = new MyContract(provider, options) const deployMethod = contract.deploy(keyPair.secretKey); await deployMethod.send();

Решено

Это отличный вопрос. Если вы проверите URL репозитория для этого NFT, который является кодом в FunC, Telemint, вы увидите строку кода, которая гласит throw_unless(err::not_enough_funds, bid >= initial_min_bid);*1.

Эта строка означает, что вам нужно больше средств в самом NFT, чтобы запустить такого рода транзакцию на практике. Другими словами, ** "недостаточно средств"** означает, что вы должны пополнить баланс смарт-контракта NFT таким образом, чтобы на нем было больше 1 йены.

*1: https://github.com/TelegramMessenger/telemint/blob/c6e3d326376fa902c932299e6bfd710111ee2fed/func/nft-collection-no-dns.fc#L47

Решено

Максимальный размер смарт-контракта, развернутого в сети TON, зависит от сложности контракта и количества используемых им ячеек. В общем, размер представления смарт-контракта в виде пакета ячеек (BoC) не должен превышать предельный размер одного блока shardchain, который составляет 2 МБ. Однако практические ограничения для смарт-контрактов намного меньше.

Одна ячейка в сети TON может хранить до "1023 битов данных" и имеет "4 ссылки на другие ячейки`. Чем сложнее смарт-контракт, тем больше ячеек он будет использовать. Однако не существует строгого правила относительно количества ячеек, которые может содержать смарт-контракт, поскольку это зависит от конкретного варианта использования и сложности контракта.

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

2 МБ на основе приведенного здесь: https://docs.ton.org/develop/howto/faq#average-block-size

Например, если вы подробно изучите код здесь: https://github.com/ton-blockchain/payment-каналы/blob-объект/e605580c3fb1feb22d80be9a0cddfcd05671c347/функция/асинхронныйканал.функция#L583

Вы увидите, что код одинаков как для внешних, так и для внутренних функций приема:

() recv_internal (int contract_balance, int _, cell _, slice in_msg) { return recv_any(contract_balance, in_msg); } () recv_external (int contract_balance, int _, cell _, slice in_msg) { ;; Note that only cooperative_close and cooperative_commit ;; will be accepted return recv_any(contract_balance, in_msg); }

Мой вопрос таков: в чем разница между этими функциями в FunC и почему это происходит?

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

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

Адреса учетных записей в TON состоят из двух частей:

workchain_id: 32-разрядное целое число со знаком big-endian, которое определяет рабочую цепочку. account_id: 256-битный внутренний адрес или идентификатор учетной записи, который определяет учетную запись в выбранной рабочей цепочке.

В отрывке упоминается, что разные рабочие цепочки могут использовать идентификаторы учетных записей (account_id) различной длины, которые могут быть короче или длиннее стандартных 256 бит, используемых в мастер-цепочке (workchain_id = -1) и базовой рабочей цепочке (workchain_id = 0). Такая гибкость позволяет разрабатывать различные рабочие цепочки с разной длиной идентификатора учетной записи в зависимости от их конкретных требований и вариантов использования.

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

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

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

Решено

Цитируемый текст описывает криптографию с эллиптической кривой (ECC), используемую в TON, в частности, в блокчейне TON и сети TON. ECC - это криптографический подход, который опирается на математику эллиптических кривых для создания безопасных пар ключей для криптографии с открытым ключом.

В отрывке упоминаются два конкретных алгоритма эллиптической кривой, используемых в TON: Ed25519 и Curve25519.

Ed25519: Это алгоритм цифровой подписи с эллиптической кривой, который обеспечивает высокую безопасность, высокую производительность и компактные подписи. Он основан на скрученной кривой Эдвардса и был разработан Дэниелом Дж. Бернштейном, Нильсом Дуифом, Таней Ланге, Питером Швабе и Бо-Инь Янгом. В TON Ed25519 используется для создания криптографических подписей Шнорра, которые являются разновидностью схемы цифровой подписи.

Curve25519: Это эллиптическая кривая, разработанная для согласования ключей в криптографии с открытым ключом, в частности, в протоколе обмена ключами Elliptic Curve Диффи-Хеллмана (ECDH). Он также был разработан Дэниелом Дж. Бернштейном. Curve25519 используется для асимметричной криптографии в TON, обеспечивая безопасную связь между сторонами без необходимости предварительного получения общего секретного ключа.

Как Ed25519, так и Curve25519 используются стандартными способами в соответствии с их первоначальными спецификациями и соответствующими RFC (Запрос комментариев) 7748 и 8032. Однако у TON есть некоторые специфические детали сериализации и адаптации для удовлетворения своих уникальных требований.

Одной из таких адаптаций является автоматическое преобразование ключей Ed25519 в ключи Curve25519. Эта функция позволяет использовать одни и те же ключи как для цифровых подписей (через Ed25519), так и для асимметричной криптографии (через Curve25519). Это упрощает управление ключами и повышает общую эффективность криптографических операций TON.

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

Решено

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

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

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

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

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

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

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

Решено

Использование метода **'getTransactions' ** было бы рекомендуемым подходом для проверки того, было ли получено конкретное сообщение по определенному адресу.

Репозиторий примеров TON JS на Github предлагает полезные ресурсы, включая фрагмент кода JavaScript, который можно использовать для получения списка транзакций по определенному адресу.

Пример кода можно найти по адресу https://github.com/toncenter/examples https://gist.github.com/slavafomin/1bcb401b5dc336bb4f9a2005b1660cbd.

Решено

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

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

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

Решено

В TON нет необходимости в прокси-контрактах, подобных Ethereum. Контракты в TON могут обновлять свой код без изменения своего адреса.

Решено

Не снимайте его!

Контракт minter является родительским, а кошелек - дочерним. Существует один экземпляр minter и N экземпляров кошелька (N - количество владельцев вашего токена). Избавление от кошелька означало бы, что ваши пользователи не будут владеть вашими джеттонами и не смогут ничего делать с ними.

Решено

Две проблемы:

Вы должны прочитать адрес из фрагмента через load_msg_addr, а не load_bits 2. Сохраняйте адрес в builder через Addr, а не addr

addr - это псевдоним для 256uint. Между тем, полная сериализация адресов с помощью Addr также включает тег формата адреса, рабочую цепочку, 256-битную часть и некоторые дополнительные поля.

Для этого существует "стандарт", и код ошибки - "0xffff". Он также используется в официальном смарт-контракте: https://github.com/ton-blockchain/token-contract/blob/main/nft/nft-collection.fc#L132

Я бы хотел поместить адрес и хэш-таблицу в регистр c4. Могу ли я поместить их оба отдельно или мне нужно поместить адрес в хэш-таблицу?

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

click to show

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

Некоторые исследователи могут показать вам код (fift) для популярных контрактов, таких как кошельки. В качестве примера tonscan на исходном коде вкладка Насколько я знаю, это основано на данных из verify

Также вы можете получить байт-код в base64 или hex для любого контракта и сравнить его со сборкой из репозитория (если контракт общедоступен).

Решено

Идея, лежащая в основе большинства блокчейн-dapps (не специфичных для TON), заключается в том, чтобы сделать весь бэкэнд on-chain в виде смарт-контрактов. Рекомендуется избегать каких-либо серверов для удаленных вычислений. Это возможно потому, что валидаторы/узлы блокчейна действуют как удаленные серверы. У них есть стимул действовать в качестве удаленных серверов, потому что вы платите за газ валютой TON.

Решено

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

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

Одна из упомянутых интересных вещей - это случайность, которая затруднена в пространстве Web3. Проверяемую функцию случайности (VRF) сложно создать на TON, и на случайность, генерируемую в цепочке, влияют валидаторы блоков.

https://ton.org/docs/participate/own-blockchain-software/random#how-does-блок-начальноезначение-влияет-случайнымобразом-в-контрактах

Возможно, вы захотите создать oracle для этих целей.

Решено

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

Однако, если байт-код контракта будет обновлен с помощью инструкции set_code(), хэш кода изменится. Это означает, что проверенный исходный код больше не будет связан с контрактом и исчезнет из проводника.

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

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

Диктует

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

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

https://blog.ton.org/how-to-shard-your-ton-smart-contract-and-why-studying-анатомия-тонн-джеттонов

Кортежи

Кортежи ограничены 256 записями, но вы можете использовать их как неограниченный список в стиле ML. Это означает сохранить первый элемент в качестве первого элемента кортежа, а остальную часть списка в другом кортеже в качестве второго элемента и снова использовать эту же структуру для остальной части списка до конца, который обычно является нулевым значением:

(1, (2, (3, null())))

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