pytonlib - это обычно используемый пакет python для TON, но у них не так много примеров. Как мне создать адрес TON, проверить транзакции по этому адресу и отправлять транзакции с его помощью?

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

click to show

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

Решено

Вы можете использовать компонент 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();

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

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

Решено

Я нашел решение. Может быть, кому-то это будет полезно:

const tempFilePath = './storage/saved2' // tempFile - file generated by daemon-cli const payload = await fsPromise.readFile(tempFilePath, {encoding: 'base64'}); const payloadBase64 = Cell.fromBase64(payload) await provider.internal(via, { value: "0.5", body: payloadBase64 });

Решено

Я полагаю, что у всех SDK есть метод для приведения адресов необработанной / дружественной формы. Например, в tonweb (https://github.com/toncenter/tonweb/blob/master/src/utils/README.md), вы можете использовать адрес.wc и address.hashPart, чтобы получить необработанный адрес как wc:hashPart.

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

Это должно быть аналогично для любого SDK - вам нужно найти объект Address и проверить его методы и свойства, чтобы увидеть, как получить необработанный адрес.

Решено

Вот пересмотренная версия с улучшенной грамматикой:

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

Решено

В настоящее время популярные приложения TON wallet, такие как "TonKeeper" и "TONHUB", не поддерживают добавление ключевой фразы к начальной мнемонической фразе при создании или восстановлении кошелька.

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

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

Экосистема TON все еще относительно нова, и приложения для кошельков постоянно совершенствуются и добавляют новые функции. Возможно, что в будущем TonKeeper, TONHUB или другие приложения TON wallet могут добавить поддержку парольных фраз наряду с мнемоническими начальными значениями.

До тех пор пользователям необходимо будет использовать ваше приложение wallet для целей восстановления, если они создали кошелек с исходным кодом + парольная фраза в вашем приложении.

Решено

Один из возможных способов получить адрес "кошелька V3r2" из адреса v4r2 - это вычислить его по открытому ключу.

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

Решено

Это отличный вопрос. Если вы проверите 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

Один из способов, который может быть полезен, - это использование индексатора: https://github.com/tonindexer/anton

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

https://anton.tools/api/v0/accounts?latest=true&interface=nft_item&owner_address=EQDYo6otRICNYyM2SAcS1mzTUvm1dsN5LCteE7DjeYfKgA4C&minter_address=EQAOQdwdw8kGftJCSFgOErM1mBjYPe4DBPq8-AhF6vr9si5N&order=DESC&limit=10

Решено

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

Решено

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

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

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

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

Решено

Прежде чем мы начнем, вам нужно знать, что само сообщение отправляется с типом данных "Ячейка" в 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

Поскольку я подробно изучаю проект multisig, как я могу использовать командную строку в GitHub (https://github.com/akifoq/multisig) используя следующую команду:

fift -s <script-name> <args>.

Можете ли вы дать какие-то общие рекомендации по этому поводу?"

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

Например, если вы подробно изучите код здесь: 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 и почему это происходит?

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

EQCfQ0jtpebRP69fDrgnQ83Ph4wncGCXc9NcoY_mlfHyvxU-

Решено

Адреса источника и получателя важны в сообщении по разным причинам:

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

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

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

`Маршрутизация сообщений": Как упоминалось в этом отрывке, при создании сообщения может быть выбран любой правильно сформированный адрес назначения. После установки адрес назначения не может быть изменен. Такой выбор дизайна, наряду с фиксированным адресом источника, гарантирует, что маршрутизация сообщений между учетными записями и смарт-контрактами является эффективной и безопасной.

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

Блокчейн 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 поддерживает автоматическое преобразование ключей между двумя алгоритмами, оптимизируя криптографические операции внутри сети.