tonpie.io

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

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

click to show

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

Решено

Ваше понимание близко к истине.

Насколько я понимаю, "атомарность" в данном контексте - это концепция, которая родилась задолго до блокчейна TON. Вероятно, это появилось в поле базы данных: https://en.wikipedia.org/wiki/Atomicity_(database_systems)

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

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

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

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

click to show

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

Решено

Прежде чем мы начнем, вам нужно знать, что само сообщение отправляется с типом данных "Ячейка" в TON. Это означает, что каждая ячейка имеет ограничение в "1023 бита` для хранения данных. Это ограничение включает данные, хранящиеся в ячейке, и любые необходимые заголовки или метаданные.

Предположим, у вас есть текст сообщения длиной 900 бит, и вы хотите сохранить его в ячейке вместе с заголовком сообщения. Сам заголовок сообщения также будет занимать несколько битов для хранения его полей, таких как тип сообщения, информация об адресе и другие метаданные. При попытке сохранить как заголовок сообщения, так и 900-битный текст сообщения в одной ячейке общее количество требуемых битов превысит 1023-битный предел для одной ячейки.

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

Чтобы справиться с этой ситуацией, вам необходимо сохранить тело сообщения в отдельной ячейке, называемой ссылочной ячейкой. В заголовке сообщения вы бы использовали флаг, чтобы указать, что тело сообщения хранится в ссылочной ячейке. В этом случае "флаг тела сообщения inplace" (который может иметь значение 0 или 1) должен быть установлен в значение 1, указывающее, что тело сообщения хранится не в той же ячейке, что и заголовок, а в ссылочной ячейке.

Сохраняя тело сообщения в ссылочной ячейке, вы можете избежать исключения переполнения ячейки и по-прежнему сохранять все сообщение (заголовок и тело) в рамках ограничений структуры ячеек блокчейна TON.

Решено

Это отличный вопрос! (Мне тоже потребовалось много времени, чтобы понять)

** Итак, по сути, вы спрашиваете:**

Почему мы храним uint(....) там? * И почему мы там имеем дело с int_msg_info? 1/ Структура сообщения

Чтобы понять, почему мы храним uint(...) в сообщении, вам нужно понять, как TVM работает для Message. На практике макет сообщения показывает, что для "сжатия" сообщения, которое мы хотим сохранить, мы должны сохранить его в "ячейку" и загрузить в смарт-контракт в качестве сообщения.

2/ Значения по умолчанию для полей сообщений

Есть ряд значений, которые нам нужно установить "по умолчанию", указав значения для bounced, src, ihr_fee, fwd_fee в некоторых случаях.

Например, ниже приведен пример сообщения, которое мы помещаем в ячейку:

var msg = begin_cell() .store_uint(0, 1) ;; tag .store_uint(1, 1) ;; ihr_disabled .store_uint(1, 1) ;; allow bounces .store_uint(0, 1) ;; not bounced itself .store_slice(source) .store_slice(destination) ;; serialize CurrencyCollection (see below) .store_coins(amount) .store_dict(extra_currencies) .store_coins(0) ;; ihr_fee .store_coins(fwd_value) ;; fwd_fee .store_uint(cur_lt(), 64) ;; lt of transaction .store_uint(now(), 32) ;; unixtime of transaction .store_uint(0, 1) ;; no init-field flag (Maybe) .store_uint(0, 1) ;; in-place message body flag (Either) .store_slice(msg_body) .end_cell(); 3/ Значение целых чисел в .store_uint(0, 1 + 4 + 4 + 64 + 32 + 1 + 1)

Целые числа, используемые в .store_uint(0, 1 + 4 + 4 + 64 + 32 + 1 + 1) укажите количество битов в соответствии со схемой TL-B с разбивкой по длине полей, которые там указаны. Но мы всегда указываем 0.

Каждое целое число представляет длину в битах определенного поля в заголовке.

Первое целое число '1' предназначено для поля tag * За ним следуют два '4для полейihr_disabledиbounce* Затем 64 бита для поляcreated_lt* 32 бита для поляcreated_at' * и, наконец, два 1' для 'init и `поля тела.

Однако в приведенном примере все поля пусты, поэтому мы указываем 0 бит для всех полей.

Ссылка:

https://docs.ton.org/develop/smart-contracts/messages#message-layout * https://docs.ton.org/develop/smart-contracts/tutorials/wallet#commonmsginfo

Решено

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

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

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

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

Отличный вопрос, "seqno" - это интересная концепция на TVM, которая станет изюминкой

Который больше похож на номер транзакции кошелька, отправляющего Tx. Как "одноразовый номер" в EVM world.

Для дополнительного примера, если вы хотите отправить Txs через SDK в блокчейн, используйте следующий код:

// (=== more codes === ) // console.log("Interacting with Collection Contract: \n" + contract_address); let seqno: number = await wallet_address.getSeqno(); let transfer = await wallet_address.sendTransfer({ seqno: seqno, secretKey: keyPair.secretKey, messages: [ internal({ value: toNano("0.5"), to: contract_address, init: { code: init.code, data: init.data, }, bounce: true, body: packed, }), ], });

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

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

** Что вам следует сделать, так это:**

1). Создайте внешнее сообщение для вашего кошелька highload со списком денежных переводов, которые необходимо выполнить. Получите хэш внешнего сообщения или его тела.

2). Отправьте сообщение в сеть.

3). Опросите последние транзакции из блокчейна, используя идентификатор учетной записи вашего кошелька, и сопоставьте транзакцию, используя предварительно сгенерированный хэш.

4). Проверьте, что транзакция была выполнена успешно (код выхода = 0 || 1) и убедитесь, что исходящие сообщения содержат все требуемые передачи значений с правильными значениями.

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