tonpie.io

Следующее должно работать как эквивалент мороженого, поскольку они позволяют выполнять автономные вычисления - https://docs.orbs.network/v3/orbs-lambda/step-by-step-overview

Решено

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

Решено

Избирательный контракт отвечает за управление выборами валидатора на блокчейне TON.

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

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

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

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

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

click to show

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

Решено

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

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

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

Решено

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

Решено

Ответ, скорее всего, будет "нет". Смарт-контракты предназначены для цепной логики, а сервер находится вне цепочки. Действия, происходящие в смарт-контракте, не будут определяться исключительно TVM.

Вы могли бы использовать смарт-контракт в качестве интерфейса для прослушивания сервером: например, учетная запись A взаимодействует со смарт-контрактом B и отправляет событие для удаления файла с идентификатором C на сервере D. Но нет ничего, что гарантировало бы, что файл C существует или что логика сервера D. буду слушать Б.

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

Решено

Короткий ответ - нет. EVM и TVM принципиально отличаются друг от друга, поэтому невозможно напрямую перенести ваш код Solidity в TVM. Однако, возможно, что в будущем будут разработаны инструменты, позволяющие компилировать байт-код ABI в TL-B на основе TVM.

Для получения дополнительной информации об основных концепциях и сравнения двух блокчейнов вы можете найти дополнительные подробности здесь: https://blog.ton.org/six-уникальныеаспектыблокчейнаton,которыеудивятразработчиковsolidity.

Для более глубокого понимания различий между Ethereum, Solana и TON сообщество TON создало всеобъемлющий 10-страничный документ, который можно найти здесь: https://ton.org/comparison_of_blockchains.pdf.

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

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

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

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

click to show

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

Решено

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

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

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

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

Вы можете увидеть это, например, здесь (раздел "осколок"): https://test-explorer.toncoin.org/last

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

Кроме того, в настоящее время в TON используется около 2 tx в секунду. (В середине 2022 года)

Один сегмент способен обрабатывать около 100 tps и начинать разделяться на подмассивы примерно с этим значением. Таким образом, для многих осколков недостаточно нагрузки. На самом деле было 16 сегментов до 9-миллионных блоков (из-за глобального разделения параметров), а также некоторые события спама.

Более подробную информацию о цепочке обмена можно найти в этом ответе: https://answers.ton.org/question/1485660759835807744/ton-supports-multiple-рабочиецепочки-какую-изних-я-должен-использовать-в-своем-коде

Основное отличие заключается в том, что в версии 4 введены плагины, которыми может управлять пользователь и которые могут взаимодействовать с контрактами onchain.

Имейте в виду, что добавление (если таковые имеются) ненадежного плагина или добавление плагина, который может обновить его код, может быть опасным.

я думаю, это то, что вам нужно https://github.com/ton-blockchain/mnemonic2key

Решено

Вы можете узнать больше здесь: https://ton.org/docs/develop/smart-contracts/fees

Мастер-цепочка стоит намного дороже базовой рабочей цепочки, примерно в тысячу раз.

я думаю, это то, что вам нужно

https://github.com/ton-society/ton-footsteps/issues/79 * https://github.com/ton-blockchain/TEPs/pull/101/files?short_path=fc72a73#diff-fc72a73b400a1b54ef6ed276bb6ee1eb2bf7048471f9854778459fa65a664d8c

Решено

Чтобы разрабатывать смарт-контракты, вам нужно, по крайней мере, изучить FunC. В процессе вы также можете изучить Fift, чтобы лучше понять, как все работает на более низком уровне.

Для разработки Telegram-ботов вы можете использовать множество различных языков программирования общего назначения. Здесь доступно множество вариантов.

Для клиентской части dApps вы можете использовать JavaScript или другие инструменты, которые могут сгенерировать клиентское приложение.

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

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

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