Решено

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

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

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

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

Решено

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

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

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

Решено

Вообще говоря, функциональный код op::increase = "op::increase"c сначала преобразует это в uint (целое число без знака), поскольку в TVM (виртуальной машине Тьюринга) обмен данными осуществляется только в целых числах без знака, чтобы различать "неограниченные" функции, которые вы создаете.

С другой стороны, "uint" может быть преобразован в "шестнадцатеричный" код, чтобы сэкономить место при его хранении в смарт-контракте.

**Вот пример в TypeScript для завершения преобразования операционного кода в uint и шестнадцатеричные данные. Он использует метод CRC32 для распаковки этой информации операционного кода. **

Код:

const POLYNOMIAL = -306674912; let crc32_table: Int32Array | undefined = undefined; export function crc32(str: string, crc = 0xFFFFFFFF) { let bytes = Buffer.from(str); if (crc32_table === undefined) { calcTable(); } for (let i = 0; i < bytes.length; ++i) crc = crc32_table![(crc ^ bytes[i]) & 0xff] ^ (crc >>> 8); return (crc ^ -1) >>> 0; } function calcTable() { crc32_table = new Int32Array(256); for (let i = 0; i < 256; i++) { let r = i; for (let bit = 8; bit > 0; --bit) r = ((r & 1) ? ((r >>> 1) ^ POLYNOMIAL) : (r >>> 1)); crc32_table[i] = r; } }

Как только мы вызовем функцию crc32("депозит"), мы сможем получить значение 0xb04a29cf на практике.

Для получения дополнительной информации о методе CRC32 вы можете перейти по следующим ссылкам:

Документация TON CRC32 * Онлайн-инструмент CRC32

Может быть, углубиться в технические документы:

https://docs.ton.org/tblkch.pdf * https://docs.ton.org/catchain.pdf

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

Это старое определение и того, и другого:

;;; Checks whether the data parts of two slices coinside int equal_slice_bits(slice a, slice b) asm "SDEQ"; int equal_slices(slice a, slice b) asm "SDEQ";

Таким образом, это были обе равнозначные функции.

Решено

Цены на газ рассчитываются с учетом параметров конфигурации 20 (для masterchain) и 21 (для basechain). Пока они одинаковы, рассчитанные тарифы на газ будут одинаковыми.

Я проверил это, и в настоящее время в базовой цепи они равны, но в главной цепи это не так.

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

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

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

Таким образом, первые 32 бита - это время unix, а следующие 32 бита - последовательно увеличивающиеся числа.

Короткий ответ - через Интерфейс.

Но также вы можете взять ссылку в TEP62 (стандарт NFT) https://github.com/ton-blockchain/TEPs/blob/master/text/0062-nft-standard.md

А также проверьте мой код такта https://github.com/howardpen9/nft-template-in-тактичность

Решено

Привет, вы можете найти пример кода здесь:

https://docs.ton.org/develop/dapps/ton-connect/#third-party-ton-services-совместимость-с-ton-connect-20