tonpie.io

Ваш перевод происходит в mainnet и будет отправлен на указанный вами адрес. То, что произойдет, будет зависеть от нескольких факторов:

Если вы (или ваш кошелек) отключите флажок "отказ", сумма в тоннах будет отправлена и останется на счете получателя.

Если вы (или ваш кошелек) сохраняете флаг "отказ", то это зависит от учетной записи получателя:

О. Если в пункте назначения нет смарт-контракта, он восстановится.

Б. Если существует смарт-контракт, это будет зависеть от его поведения, и он может принять или отклонить его.

На Tonscan и Tonviewer исследователи, вы можете найти некоторые общие статистические данные на TON. Но эти два веб-сайта предоставляют разное количество адресов. Чем вызвана эта разница?

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

click to show

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

Я не слышал о таком инструменте, но мне кажется, что для разработчика создать его должно быть легко. Библиотеки, подобные "ton-core", позволяют любому программно получить адрес для любой конкретной комбинации ключей и кошелька, для этого им даже не требуется Интернет. Таким образом, программа, которая запрашивает ключ и распечатывает адреса всех контрактов кошелька с этим ключом, будет состоять всего из десятков строк кода.

В этом руководстве содержится информация, необходимая для его написания: https://ton-community.github.io/tutorials/01-wallet/

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

Вот один из примеров того, как пакет Kotlin делает это:

https://github.com/andreypfau/ton-kotlin/blob/f0f2e7e05bc46d48fcbf6cef75249eea46890c7a/ton-block/src/commonMain/kotlin/org/ton/block/AddrStd.kt#L108

import org.ton.crypto.base64 import org.ton.crypto.base64url fun convert(address: String): String { val raw = try { base64url(address) } catch (E: Exception) { base64(address) } return raw; }

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

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

click to show

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

Решено

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

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

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

Решено

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

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

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

Решено

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

По сути, вы бы сгенерировали тысячи случайных мнемоник и отфильтровали те, которые соответствуют нужным вам параметрам.

Вы можете генерировать пары ключей с помощью TonWeb:

const nacl = TonWeb.utils.nacl; // use nacl library for key pairs const tonweb = new TonWeb(); const keyPair = nacl.sign.keyPair(); // create new random key pair let secretKey = keyPair.secretKey; let wallet = tonweb.wallet.create({publicKey: keyPair.publicKey}); // create interface to wallet smart contract (wallet v3 by default)

Решено

Адреса, перечисленные в двух источниках, отличаются, поскольку они по-разному закодированы. Однако, по сути, это один и тот же адрес. Чтобы преобразовать адрес в "каноническую", не удобную для пользователя форму, вы можете использовать следующий код на JavaScript:

new TonWeb.Address('kf-kkdY_B7p-77TLn2hUhM6QidWrrsl8FYWCIvBMpZKprBtN').toString(false);

Это преобразует адрес в каноническую форму -1:a491d63f07ba7eefb4cb9f685484ce9089d5abaec97c15858222f04ca592a9ac, которая совпадает с адресом, указанным в первом источнике.

Решено

В этом посте есть JS-код, который это делает, а также объяснения, как все это работает: https://ton-community.github.io/tutorials/01-wallet/

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

import { mnemonicToWalletKey } from "ton-crypto"; import { WalletContractV4 } from "ton"; async function main() { // open wallet v4 (notice the correct wallet version here) const mnemonic = "unfold sugar water ..."; // your 24 secret words (replace ... with the rest of the words) const key = await mnemonicToWalletKey(mnemonic.split(" ")); const wallet = WalletContractV4.create({ publicKey: key.publicKey, workchain: 0 }); // print wallet address console.log(wallet.address.toString({ testOnly: true })); } main();

Адреса, начинающиеся с EQ, являются адресами с возможностью возврата, а те, которые начинаются с UQ, не являются адресами с возможностью возврата. Это всего лишь подсказка программному обеспечению кошелька о том, хотите ли вы, чтобы отправленное сообщение могло отскочить или нет.

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

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

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

Вам нужно развернуть простой контракт для каждого пользователя (который проголосовал) и вычислить адрес (детерминированный) для голосования пользователя магазина. В вашем основном контракте будут храниться только подсчеты. Нравится: да - 313, нет - 131

Если пользователь хочет изменить голосование, пользователь должен отправить транзакцию в пункт личного голосования (вы можете подготовить его в своем ddap), и этот элемент изменит голосование по основному контракту

Вы можете увидеть простой пример здесь - https://github.com/Tonstarter/simple-vote чтобы понять, как это может работать для большого количества пользователей без большого хранилища

Решено

Вы можете использовать https://ton.org/address/ конвертер.

а для dns?)

Решено

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

Однако, если вы ищете источник данных общего назначения, вы можете попробовать использовать отчеты, доступные на https://m3talab.io/reports/ton-telegram-open-сеть.

Решено

Это адрес договора с избирателем. Более подробная информация доступна по адресу: https://ton.org/docs/develop/smart-contracts/governance

Невозможно обновить версию кошелька с версии v3 до версии 4 без изменения адреса.

По сути, кошелек является одним из смарт-контрактов TON blockchain, а адрес кошелька - это адрес смарт-контракта. Адрес вновь развернутого контракта в TON зависит от двух факторов - развернутого байт-кода и исходного хранилища контракта. Поскольку у нас будет новый байт-код (из-за разницы между контрактами v3 и v4) и новые исходные данные - мы всегда будем получать новый адрес.

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