• 0 Голоса
    1 Сообщения
    13 Просмотры

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

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

    click to show

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

  • 0 Голоса
    1 Сообщения
    11 Просмотры

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

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

    click to show

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

  • 0 Голоса
    2 Сообщения
    12 Просмотры

    Решено

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

  • 0 Голоса
    1 Сообщения
    58 Просмотры

    Я хочу убедиться, что передача прошла успешно, используя этот метод ответа 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.

    Спасибо

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

  • 0 Голоса
    3 Сообщения
    56 Просмотры

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

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

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

  • 0 Голоса
    2 Сообщения
    22 Просмотры

    Решено

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

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

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

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

  • 0 Голоса
    3 Сообщения
    30 Просмотры

    Решено

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

  • 0 Голоса
    2 Сообщения
    34 Просмотры

    Решено

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

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

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

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

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

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

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

  • 0 Голоса
    2 Сообщения
    20 Просмотры

    Решено

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

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

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

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

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

  • TONpie Answers & TON WIKI

    Прикреплена Возможности tonpie.io
    0 Голоса
    1 Сообщения
    19 Просмотры

    Два новых модуля нашей экосистемы: TONpie Answers & TON WIKI от большого майского обновления [220523], читайте на новостной странице tonwiki прямо ниже под этим текстом:

  • Существуют ли примеры set_code()?

    TON Overflow на русском
  • 0 Голоса
    2 Сообщения
    23 Просмотры

    Решено

    В целом

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

  • 0 Голоса
    2 Сообщения
    58 Просмотры

    Решено

    Вы можете подписать ячейку с помощью 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()`?

    TON Overflow на русском
    0 Голоса
    1 Сообщения
    11 Просмотры

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

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

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

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

  • 0 Голоса
    3 Сообщения
    12 Просмотры

    Решено

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

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

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

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

  • 1 Голоса
    2 Сообщения
    25 Просмотры

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

  • 0 Голоса
    1 Сообщения
    3 Просмотры

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

    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

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

  • 0 Голоса
    2 Сообщения
    18 Просмотры

    Решено

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

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

  • Телеминт / Fragment.com NFT

    TON Overflow на русском
    1 Голоса
    1 Сообщения
    13 Просмотры

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

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

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

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

  • 0 Голоса
    2 Сообщения
    15 Просмотры

    Решено

    Вообще говоря, функциональный код 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