📝 Теперь вы знаете:
- В TON токены реализуются как отдельные контракты. Один контракт на пользователя плюс отдельный контракт minter, который обеспечивает интерфейс для создания новых единиц токена.
📚Чтение Заметок
Здесь мы пройдемся по трем примерам, чтобы увидеть, как принципы проектирования контрактов применяются к различным приложениям и как платформа TON помогает вам создавать масштабируемые и безопасные приложения.
Токены.
В реализации Ethereum или даже неблокчейнных реализациях, токены будут реализованы в виде простой книги счетов.
У вас есть список, программа контролирует этот список счетов, и каждый элемент в списке фактически является адресом участника и его балансом. Это довольно просто, но, к сожалению, оно не масштабируется в контексте блокчейна, потому что ваш смарт-контракт должен постоянно увеличиваться с количеством пользователей и становится дороже для взаимодействия каждого пользователя.
❓Что такое подход TON?
В TON токены реализуются как отдельные контракты. Один контракт на пользователя плюс отдельный контракт minter, который обеспечивает интерфейс для создания новых единиц токена.
Контракты на пользователя называются кошельками Jetton, и работа этих кошельков Jetton заключается в том, чтобы держать баланс токена для каждого отдельного пользователя. Всякий раз, когда пользователь хочет перевести токен с одной учетной записи на другую 💸, он сначала отправляет внешнее сообщение на свой кошелек, затем этот кошелек разворачивает это внешнее сообщение и отправляет через внутреннее сообщение на кошелек Jetton этого пользователя с надписью: "Пожалуйста, отправьте деньги на определенный адрес". Затем кошелек Jetton сокращает свой баланс на необходимую сумму и отправляет сообщение своему брату-контракту, который имеет точно такой же код, но другого владельца, и в этом сообщении говорится: "Пожалуйста, увеличьте свой баланс на ту же сумму.
🍞Здесь используется проверка ДНК, потому что код Jettons тот же.
Контракт с несколькими подписями.
📖 Концепция контракта с несколькими подписями проиллюстрирована в контексте TON, где несколько сторон коллективно разрешают действия путем токенизации запросов, инициированных пользователем.
Вместо того, чтобы напрямую обрабатывать сообщения, пользователи получают уникальные токены, инкапсулируя их запросы и голоса. Эти токены, принадлежащие пользователям, упрощают отслеживание и предотвращают превышение контракта злоумышленниками. Честные пользователи собирают голоса по токенам временных запросов, и после достижения порога контракт с несколькими подписями выполняет действие после проверки подлинности запроса. Эта токенизация оптимизирует процесс и фокусируется на временном состоянии системы, а не на отдельных контрактных акциях или values.
Абонентские платежи.
👀 Начиная с версии кошелька 4, кошельки поддерживают плагины, которые позволяют людям создавать платежи по подписке.
Это очень мощная функция, и она относительно хорошо масштабируется, потому что пользователь контролирует этот список плагинов. Но мы могли бы представить себе лучший способ сделать это.
🔥 Классная идея заключается в том, что вместо того, чтобы перечислять конкретные адреса плагинов, вы можете перечислить различные реализации кода этих плагинов. И если они имеют один и тот же код, будет только одна запись для любого количества плагинов подписки, которые у вас есть.