📝 Теперь вы знаете:

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

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

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

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

📚Примечания к лекции
В этом уроке мы поговорим о структуре памяти TON и работе TVM.

🏁 Давайте начнем с уникальной функции TON, которая называется cell.

Ячейки.
Что такое ячейка?
🔶 Ячейка - небольшой строительный блок всех структур данных в блокчейне TON. Каждая ячейка содержит до 1023 бит данных 🔸 и до четырех ссылок 🔗 на другие ячейки. И это позволяет использовать ячейки для построения сколь угодно сложных и вложенных структур данных.

❗️ Таким образом, в TON невозможно выделить массив произвольного размера, как это можно сделать в Ethereum. В TON вам приходится работать с деревом ячеек 🌳.

Модель хранения в TON, очевидно, создает некоторые проблемы для разработчиков, потому что теперь вам приходится разбивать свои данные на блоки по 1023 бита, что немного меньше 128 байт. ❓ И вы должны подумать, насколько плоским или глубоким вы хотите построить дерево ваших данных.

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

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

Больше типов в TVM.
В TVM достаточно типов для работы:
Ячейки
Целые числа
257-битное целое число (позволяет представлять широкий диапазон целых чисел, подходящих для криптографической работы и для финансовых операций 😎)
Все типы данных, с которыми работает TVM, могут быть считаны кодом в контракте из его собственного хранилища, обработаны в стеке, а затем может быть создано новое хранилище с защитой от несанкционированного доступа. Если выполнение прошло успешно ✔️, то TVM выгружается из памяти и на его месте сохраняется новое состояние контракта.

Расположение памяти.
Давайте поговорим о расположении памяти, доступном для контракта.

Единственный доступный вариант для вашей структуры памяти - это дерево ячеек в контракте.

❓ Но как хранить списки, словари и наборы в системе?

😟 Это не очень тривиально сделать, потому что ячейки очень компактны и образуют дерево.

Чтобы помочь разработчикам в этом, TON поставляется на уровне TVM и на уровне FunC, языка более высокого уровня, с инструментами, которые помогают вам более эффективно работать с хэш-картами и использовать ячейки в качестве базовой реализации.

Ключ к масштабируемости в TON.
❗️ Масштабируемость в TON заключается в ограничении объема работы, выполняемой в каком-либо одном месте, потому что TON масштабируется по контрактам, но каждый отдельный контракт сам по себе не масштабируется "из коробки".

❓ Какие ключевые моменты следует иметь в виду?

Вполне допустимо иметь вложенные ячейки для небольшого объема данных. Если вы создаете систему с очень небольшим количеством участников, скажем, контракт с несколькими подписями, тогда вы можете сохранить эти данные в своей хэш-карте прямо в контракте, и они будут достаточно маленькими. Однако, если вы создаете систему с миллионами пользователей, вам следует подумать об использовании токенов для представления участия пользователей и вообще избегать сохранения списков этих пользователей в вашем контракте.
Ячейки имеют встроенную детерминированную схему хэширования, которая позволяет однозначно идентифицировать любую ячейку в любой части дерева, и это используется как для дедупликации, так и для сжатия данных. Например, когда в контракте заканчиваются деньги для оплаты аренды, его текущее состояние выгружается из блокчейна. Это полностью забыто, но сеть по-прежнему хранит хэш ячейки хранения. Это означает, что пользователь может прийти позже и предоставить исходное 🌲 дерево ячеек, соответствующее этому хэшу, и повторно создать экземпляр контракта, и таким образом состояние контракта полностью сохраняется хэшем всего его хранилища.
Вывод.
Вот некоторые из основных результатов:
Все построено из 🔸 ячеек.
Поверх ячеек у вас есть типы, предоставляемые 💻 TVM.
TVM создается для каждого контракта для каждого сообщения, которое обрабатывается 📝 контрактом.
Вы должны знать о затратах, связанных с большими структурами данных и глубокими цепочками ячеек, которые могут повлечь за собой более высокие, чем обычно, затраты на выполнение вашего контракта.

2.2 Типы сообщений и этапы вычисления

📝 Вы также узнаете о:

Какие типы сообщений может получать контракт?

Что такое транзакция?

Каковы этапы транзакции?

📝 Теперь вы знаете:

Существует два вида входящих сообщений, которые могут поступать в контракт: внешние и внутренние.

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

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

Транзакция - это комплекс изменений состояния контракта.

Транзакция проходит пять фаз: фаза хранения, фаза зачисления, фаза вычисления, фаза действия, фаза возврата.

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

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

На этапе расчета TVM выполняет код и проверяет каждую операцию, а также отслеживает использование газа.

На этапе действия смарт-контракт переходит в новое состояние, и исходящие сообщения обрабатываются.

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

📚Примечания к лекции
Давайте углубимся в то, как обрабатывается сообщение и что на самом деле является транзакцией.

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

Существует два типа входящих сообщений:
⚪️ - Внешние сообщения. 🔵 - Внутренние сообщения.

Внешние сообщения.
Внешнее сообщение - строка данных, которая берется из ниоткуда с точки зрения блокчейна.

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

Внутренние сообщения.
Внутренние сообщения - те, которые отправляются контрактами другим контрактам. 👥

Эти сообщения имеют немного более богатую структуру:
Внутренние сообщения могут содержать балансы. 💸
Эти сообщения надежно аутентифицируются по адресу контракта на отправку. 🔑 Вся архитектура TON гарантирует контрактам, что этот адрес отправителя правильный.
Обработка сообщений и кодов операций.
Как только контракт получит сообщение, у него может быть два отдельных обработчика для внутреннего и внешнего. Оба вида сообщений будут содержать произвольные 🗻 данные полезной нагрузки, разработанные автором контракта. Если контракт хочет обрабатывать различные типы сообщений, то он будет использовать то, что мы называем кодами операций.

Коды операций (коды операций) 🔢 - префикс из четырех байт в пользовательских данных в сообщении для указания типа операции, которую должен поддерживать контракт.

Операции.
❓ Что такое транзакция?

Транзакция 💸 - комплекс изменений состояния контракта. ❗️ Сообщение - это не транзакция, это просто входные данные для транзакции!

❓ Что делает транзакция?
1. ▶️ Оно изменяет состояние контракта. 2. 📋 Он создает список исходящих действий.

Этапы транзакции.
Существует пять этапов 5️⃣, которые проходит транзакция:
Этап хранения 📒 Вычитает плату за хранение на основе байтов, сохраненных контрактом с момента последней транзакции. Если средств недостаточно, контракт переходит в замороженное состояние, сохраняя свое состояние в течение ограниченного времени.
Фаза зачисления - Это когда монеты, прикрепленные к входящему сообщению, зачисляются на контракт.
Фаза вычисления - это когда ваша программа оживает. TVM выполняет код и проверяет каждую операцию, а также отслеживает использование газа.
Фаза действия 🏃 Наиболее важным действием на этом этапе является новое состояние контракта. Ваш контракт может в конце выполнения или на любом промежуточном этапе создать новое состояние и новое хранилище для себя, и это будет записано после успешного выполнения контракта. В списке есть и другие действия, и эти действия являются исходящими сообщениями.
Фаза возврата 🎱 Это происходит, если контракт не был выполнен и во входящем сообщении был отмечен флаг, говорящий, что я могу вернуть сообщение. Это означает, что на данном этапе, если произойдет какой-либо сбой и от входящего сообщения останутся какие-либо деньги, то контракт создаст исходящее сообщение обратно отправителю, чтобы вернуть деньги обратно. Это функция безопасности, которая позволяет людям вернуть большую часть средств в случае возникновения какой-либо ошибки или сбоя в контракте.
Вывод.
Давайте подведем итог:
Контракт получает входящее сообщение, которое может быть внутренним или внешним.
Внутренние сообщения могут содержать деньги и могут быть аутентифицированы по адресу отправляющего контракта, в то время как внешние сообщения вообще не аутентифицируются сами по себе, и задача контракта - создать аутентификацию.
Выполнение транзакции проходит через пять этапов.
Этап хранения для взимания арендной платы.
Фаза зачисления, когда поступающие монеты зачисляются на баланс.
Фаза вычисления, на которой выполняется ваш код.
Фаза действия, когда хранилище обновляется и исходящие сообщения перенаправляются.
Фаза возврата, когда контракт устраняет сбои и отправляет монеты обратно отправителю.

2.3 Авторизация сообщений в контрактах

📝 Вы также узнаете о том:
Какие категории аутентификации существуют в блокчейне TON?

📝 Теперь вы знаете:

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

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

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

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

📚Примечания к лекции
В этом уроке рассматриваются различные методы авторизации для сообщений.

Обзор всех типов аутентификации
Аутентификация с помощью подписи.
❗️ Любое событие в блокчейне TON должно начинаться с внешнего сообщения. Всякий раз, когда внешнее сообщение поступает в wallet, оно считывает 64 байта данных 6️⃣4️⃣, которые являются подписью для остальной части сообщения, проверяет подпись своим открытым ключом, а затем обрабатывает остальную часть сообщения как инструкции для отправки других сообщений другим контрактам внутри кошелька. блокчейн.

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

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

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

2.4 Типы сообщений и этапы вычисления
📝 Вы также узнаете о:

Сколько типов комиссий существует в блокчейне TON?

Какие полезные шаблоны присутствуют в хорошо продуманном смарт-контракте?

📝 Теперь вы знаете:

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

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

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

Арендная плата просто определяется как стоимость одного бита данных, которые контракт хранит в единицу времени, то есть в секунду.

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

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

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

❗️ Это означает, что если есть какие-либо нетривиальные издержки, которые несут некоторые участники сети и которые могут быть увеличены внешними субъектами, это создает огромный риск для жизнеспособности всей экосистемы. ⚠️ Вот почему все, что имеет сколько-нибудь заметную стоимость и может быть увеличено, должно быть явно учтено с точки зрения сборов.

В TON обычно существует три категории сборов:
Стоимость газа.
Арендовать.
Плата за сообщение.
Плата за газ.
💻 TON - это вычислительная платформа. Ваш контракт может содержать произвольный код, и любой желающий может загрузить в сеть любой код, который он захочет. Как только он это сделает, вся сеть будет обрабатывать 🔨 сообщения ✉️ с использованием этого кода.

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

❗️ TON спроектирован, в отличие от Ethereum или Bitcoin, таким образом, чтобы не создавать рынок для ограниченного количества газа или размера блока. Вместо этого он бесконечно разбивается на сегменты, так что если сегодня вы платите одну цену за газ, а завтра у вас гораздо более высокая нагрузка 🔺, то валидаторы сети будут получать более высокие сборы, но пользователям не придется конкурировать за сборы и они будут платить ту же цену, просто сеть будет масштабироваться горизонтально.

Соображения, касающиеся газа.
Вы, как дизайнер, должны позаботиться о паре соображений, касающихся газа.

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

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

Арендовать.
Арендная плата - стоимость одного бита данных, которые хранятся в контракте в единицу времени.

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

😲 Это связано с тем, что ваш кошелек простаивал неделю или две, и накопилась некоторая заметная сумма арендной платы, которая была списана при совершении этой транзакции.

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

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

2.5 Масштабируемые контракты

📝 Вы также узнаете о:

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

Каким принципам следует следовать, чтобы выжать максимум из масштабируемого блокчейна TON?

📝 Теперь вы знаете:

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

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

Избегайте использования данных переменной длины в качестве первоочередной задачи.

Если вам нужен список, то, по крайней мере, сделайте его коротким и ограниченным, например, статически определенным.

Доменное имя TON DNS - это коллекционный несменяемый токен, с которым может быть связано произвольное количество дополнительных записей.

Масштабируемый способ создания больших списков или словарей данных в TON заключается в использовании самого блокчейна в качестве массива.

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

📚Конспекты лекции
Давайте поговорим о масштабируемости.

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

Таким образом, операции с одним контрактом не создадут узкого места 🍼 для операций с другим контрактом. И тогда сеть TON, очевидно, позаботится обо всей маршрутизации сообщений 🚅 между ними.

❗️ Ваша задача - использовать преимущества всей масштабируемости блокчейна и не создавать узких мест в ваших собственных контрактах!

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

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

1️⃣ Во-первых, у вас будет постепенно растущая стоимость аренды для всех этих данных, которые вы храните в своем контракте. 💸
2️⃣ Во-вторых, каждый раз, когда пользователь приходит и хочет совершить операцию с этим контрактом, ему придется платить все большую и большую комиссию за транзакцию, потому что он будет оперировать все большим объемом данных в контракте. 🌄
Правила.
Чтобы помочь вам, дам руководство о том, как правильно проектировать многопользовательские и крупномасштабные приложения, и, кроме того, есть несколько правил. 📰

❗️ Избегайте использования данных переменной длины.
❗️ Если вам нужен список, то, по крайней мере, сделайте его коротким и ограниченным, например, статически определенным.
❗️ Если вам нужен список, и он должен динамически увеличиваться, то, по крайней мере, убедитесь, что этот контракт принадлежит одному пользователю и у него есть исключительное право контролировать его хранение. Простым примером являются записи в элементах TON DNS.
Блокчейн в виде массива.
Масштабируемый способ создания больших списков или словарей данных в TON - использовать сам блокчейн в качестве массива. Вот простой пример.

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

💎 Наиболее популярным примером реализации этой идеи является дизайн токенов в экосистеме TON. Балансы отдельных пользователей распределены по так называемым кошелькам Jetton. 🔥 Что в этом круто, так это то, что операции между двумя кошельками Jeton в одном месте не мешают операциям двух других в каком-либо другом месте, и они могут быть распределены по отдельным цепочкам блоков и не создавать никаких узких мест.

2.6 Обзор классических бизнес-задач
📝 Вы также узнаете о:

В каких ситуациях мы могли бы применить наши принципы разработки масштабируемых контрактов?

📝 Теперь вы знаете:

В TON токены реализованы в виде отдельных контрактов. По одному контракту на пользователя плюс отдельный контракт minter, который предоставляет интерфейс для создания новых единиц токена.

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

Жетоны.
В реализациях Ethereum или даже без блокчейна токены были бы реализованы как простая бухгалтерская книга счетов.

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

❓ Что такое подход TON?

В TON токены реализованы в виде отдельных контрактов. Один контракт на пользователя плюс отдельный контракт minter, который предоставляет интерфейс для создания новых единиц токена.

Контракты для каждого пользователя называются кошельками Jetton, и задача этих кошельков Jetton заключается в хранении баланса токена для каждого отдельного пользователя. Всякий раз, когда пользователь хочет перевести токен с одной учетной записи на другую 💸 , он сначала отправляет внешнее сообщение на свой кошелек, затем этот кошелек разворачивает это внешнее сообщение и отправляет через внутреннее сообщение на кошелек Jetton этого пользователя со словами "Пожалуйста, отправьте деньги на определенный адрес". Затем Jetton wallet уменьшает их баланс на необходимую сумму и отправляет сообщение своему родственному контракту, который имеет точно такой же код, но другого владельца, и в этом сообщении говорится: "Пожалуйста, увеличьте свой баланс на ту же сумму.

🍞 Здесь используется проверка ДНК, потому что код Jettons одинаков.

Контракт с несколькими подписями.
📖 Концепция контракта с несколькими подписями иллюстрируется в контексте TON, где несколько сторон коллективно санкционируют действия, маркируя запросы, инициированные пользователем.

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

Платежи по подписке.
👀 Начиная с версии 4 кошелька, кошельки поддерживают плагины, которые позволяют пользователям создавать платежи по подписке.

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

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