tonpie.io

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

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

click to show

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

В блокчейне TON каждый NFT использует свой собственный смарт-контракт. А хранение вещей в TON требует оплаты платы за хранение, вычитаемой из любого смарт-контракта. Означает ли это, что у каждого NFT на TON есть свой баланс, который очень медленно уменьшается из-за платы за хранение? Что произойдет, если температура опустится ниже нуля? Может ли NFT быть удален?

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

click to show

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

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

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

click to show

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

Решено

Строго говоря, поиск наиболее эффективного способа структурирования хранилища является задачей NP-класса, что означает, что для этого потребуется слишком много ресурсов, учитывая количество битов. Словари представляют собой бинарные деревья (до 2 ветвей в ячейке), хотя их чтение и обновление на самом деле дешевле, чем квадродеревья. Поэтому я бы рекомендовал использовать dicts.

Я хочу убедиться, что передача прошла успешно, используя этот метод ответа tonConnectUI.sendTransaction()

Я использую : React js @tonconnect/ui-react @ton/тонна

Среда : Тестовая сеть

отправить транзакцию с помощью : tonConnectUI.sendTransaction()

ответ на транзакцию с помощью веб-расширения : {boc:"x{B92CC224AD7A1546F9974E8ACD9B4D7305D90A21A75A24C9732DB161B7D034A0D78239814924A11BAED572D69782624216DE00BCEE93A99090469BFEE2477D0029A9A31764E4EA950000000503}\n x{620019F5CCE72C6549AE5B6A58A2B80A5E02FD23B696B24A5EDCD3C6E47A671D3AECA017D7840000000000000000000000000001}\n x{5FCC3D140000000000000000801DC05C9F00471C18F28FB322BE12D4FE504AE6C28DCE7493DB17433AE4959A0CF001AF614CF808EEEE5A8EB27AC9BD31B27BB5F6B986682F71A7F8E1A0C5F0A51F54202}"} ответ на транзакцию с помощью мобильного кошелька :

{boc: 'te6cckEBAwEA/gAB4YgB3AXJ8ARxwY8o+zIr4S1P5QSubCjc50…T4Ajjgx5R9mRXwlqfyglc2FG5zpJ7YuhnXJKzQZwgKMscEHI='}

=============================================================

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

Итак, я пытаюсь получить владельца nft по адресу NFT после получения ответа на транзакцию, но все равно получаю старого владельца, который не обновляется после транзакции, я думаю, это требует времени.

Итак, я решил расшифровать ответ и получить хэш Trasaction и данные проверки с помощью этого хэша из api.

Но я не знаю, как получить хэш транзакции.

Кто-нибудь может каким-либо образом помочь решить эту проблему? мне просто нужно подтвердить, что NFT получен в x wallet.

Спасибо

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

Вообще говоря, из сообщения об ошибке следует, что для BigInt

Вы должны заметить, что ваша строка кода неверна: .storeUint(0,1) // forward_payload:(любая ячейка ^Cell)

Я думаю, это должна быть "ячейка", не использующая "Uint".

Решено

Основано на техническом документе, найденном здесь, логическое время описывается как:

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

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

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

Решено

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

Если вы хотите посмотреть на их кошельки в TON blockchain explorers, вам нужно сначала найти контролирующий кошелек, то есть кошелек, который отправляет TON для участия в выборах.

Эту информацию можно найти, запустив метод get participant_list_extended, и он возвращает полезные данные только до завершения выборов.

Например, если я запущу lite-клиент в testnet и выполню эту команду:

runmethod kf8zMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzM_BP participant_list_extended

Результатом будет что-то вроде:

result: [ 1692631422 1692631242 10000000000000 14019250477034344 ([1785726394745260293869629821187026920743160317479397166793665319642004602034 [1000001000000000 1966080 101184175721668699951755525112601793644527200681998252172335557711320252984635 87647878168491834245916094424296400596840187149190938906730361646994336065092]] [...

Здесь первые 4 поля связаны с выборами (elect_at, elect_close, min_stake, total_stake), затем идет список валидаторов, первое поле - идентификатор валидатора, а затем 4 связанных поля, третье - адрес управляющего кошелька.

Например, здесь 1785726394745260293869629821187026920743160317479397166793665319642004602034 - это идентификатор валидатора или validator_pubkey, и 101184175721668699951755525112601793644527200681998252172335557711320252984635 - это десятичное число, которое может идентифицировать кошелек. Если вы преобразуете его в шестнадцатеричное значение, а затем преобразуете в адрес TON (ton.org/address и добавляя '-1:'), тогда вы прибудете по адресу: kf_ftDbFY_gRWt2FkqVk68scKhuoniW6Po7GndTGdkCtO_2Z.

Решено

Эй, в общем, нет никакого TEP (предложения по повышению TON), определенного для того, что представляет собой "Стандартное размещение ставок для NFT".

Как участник, внедривший стандарт NFT на языке Tact, вы можете легко установить статус своей доли, создав новый контракт и указав его в качестве нового владельца NFT.

В качестве альтернативы, вы можете изменить статус внутри самого элемента NFT, а затем добавить инструкцию require, чтобы ограничить метод Transfer для элемента NFT.

Таким образом, способ реализации этого довольно прост и гибок.

Возможно, в ближайшем будущем я запишу учебник по этому вопросу.

Наконец, я предполагаю, что вы пытались выполнить пошаговую задачу здесь https://github.com/ton-society/ton-footsteps/issues/295

Я уже вставил код POC (Proof of Concept), который может запускаться в тестовой сети. Иди и проверь это! <3

Решено

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

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

Асинхронная структура блокчейна TON создает проблемы с гарантиями доставки сообщений. Хотя логическое время помогает установить порядок событий и транзакций, оно не гарантирует порядок доставки сообщений между несколькими смарт-контрактами. Это происходит из-за различных маршрутов в цепочках осколков.

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

Для получения более подробной информации вы можете ознакомиться здесь: https://docs.ton.org/develop/smart-contracts/guidelines/message-delivery-guarantees#what-is-a-logical-time

The Elector smart contract: https://github.com/ton-blockchain/ton/blob/040df63c9864f2f37ebe50c4cafcc01f2d5d2d5c/crypto/smartcont/elector-code.fc#L431-L457

hTON liquid staking protocol (disclosure: I'm the author): https://github.com/HipoFinance/contract/blob/612e27fef6b641edfcc562ac9561c565ada8603d/contracts/treasury.fc#L1799-L1842

Решено

В целом

В порядке байтов с большим числом байтов **самый значимый байт (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 или любой другой системы, с которой вы работаете.

Решено

Вы можете подписать ячейку с помощью ton-crypto или ton-core, а позже проверить ее с помощью check_signature или check_data_signature из stdlib.fc в FunC.

Вот приблизительный фрагмент кода, который вам следует просмотреть:

sign(yourCell.hash(), keypair.secretKey); ## And in the FunC contract, check like this: check_signature(cell_hash(your_cell), signature, public_key)

Для получения более подробной информации вы можете обратиться к документации TON по проверке подписей.

С другой стороны, на языке такта, у нас также есть такая же функция на стороне смарт-контракта, как эта:

external(msg: ExtMessage) { let hash: Int = beginCell().storeUint(msg.seqno, 32).storeUint(msg.valid_until, 32).storeRef(msg.message_parameters.toCell()).endCell().hash(); require(checkSignature(hash, msg.signature, self.publicKey), "Invalid Signature"); // 😃😃😃 We checek the hash here require(msg.seqno == self.seqno, "Invalid Seqno"); require(now() <= msg.valid_until, "Invalid Time"); acceptMessage(); self.seqno = self.seqno + 1; send(msg.message_parameters); } https://docs.tact-lang.org/language/ref/math#checksignature

Согласно документации, мы находим функциональный код 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

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

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

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

Решено

Это правильно; вам нужно использовать кодировку данных Snake, если вы хотите сохранить более 1023 бит в смарт-контракте (TVM).

У вас нет другого выбора.

Короткий ответ заключается в том, чтобы использовать метод, предоставленный Arter, проверив пример кода кодировки snake здесь: Пример кода кодировки Snake

Кроме того, для более полного понимания того, как включить этот процесс в свою работу, вы можете обратиться к следующей документации: Ссылка на кодирование данных Snake

Вы можете использовать Buffer.from, чтобы решить эту проблему.

вот мой функциональный код:

forall X -> int is_null (X x) asm "ISNULL"; forall X -> (tuple, ()) push_back (tuple tail, X head) asm "CONS"; forall X -> (tuple, (X)) pop_back (tuple t) asm "UNCONS"; forall X -> X car(tuple list) asm "CAR"; () recv_internal() { ;;;;;;; } (tuple) write_bit(tuple lisp, int bit) { if (lisp.is_null()) | (lisp.car().builder_bits() == 1023) { lisp~push_back(begin_cell()); } builder b = lisp~pop_back(); b~store_int(bit, 1); lisp~push_back(b); return lisp; } ;; testable (cell) find_and_replace(int flag, int value, cell linked_list) method_id { tuple lisp = null(); int i = 0; ;; while i < 5 { ;; lisp = write_bit(lisp, 1); ;; ;; i += 1; ;; } lisp = write_bit(lisp, 1); lisp = write_bit(lisp, 1); lisp = write_bit(lisp, 1); lisp = write_bit(lisp, 1); lisp = write_bit(lisp, 1); return begin_cell().end_cell(); }

Хотелось бы знать, почему я получил код ошибки здесь: "Ошибка: не удается выполнить метод get. Получил код выхода: 7"

Но если я прокомментирую этот цикл и выполню итерацию вручную L147-151 - ошибок не будет

lisp = write_bit(lisp, 1); lisp = write_bit(lisp, 1); lisp = write_bit(lisp, 1); lisp = write_bit(lisp, 1); lisp = write_bit(lisp, 1);

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

click to show

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

Решено

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

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

Кто-нибудь когда-нибудь писал тестовые примеры для Telemint (также известного как анонимный телефонный номер Telegram)?

Ссылка на Telemint на GitHub

Код довольно сложный. Я надеюсь, что кто-нибудь сможет поделиться идеями и тестовыми примерами.

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