📝 Теперь вы знаете:
Адрес контракта - это криптографический хэш исходных данных контракта и исходного кода.
Все данные контракта полностью инкапсулированы, и с точки зрения программного кода он видит только хранилище самого контракта и его баланс.
Токен в TON, который вы можете передать, на самом деле является отдельным контрактом, который имеет свое собственное состояние, определяющее некоторые атрибуты этого токена.
Контракты на самом деле являются низкоуровневыми строительными блоками, из которых вы могли бы создавать учетные записи кошельков, протоколы с несколькими подписями, крупные децентрализованные приложения, отдельные токены или даже коллекции токенов.
TON гарантирует, что для каждого бита данных и для каждой секунды срока действия контракта существует определенный платеж, называемый арендной платой, который вычитается из баланса контракта.
📚Конспекты лекции
Давайте углубимся в счета и контракты.
Контракты
На предыдущем уроке мы узнали о контрактах следующее:
Учетная запись и контракт на низком уровне в TON являются взаимозаменяемыми терминами.
Контракт - это данные, код и баланс Toncoin.
Контракты получают входящие сообщения, обрабатывают их и отправляют исходящие сообщения, а также изменяют свое собственное внутреннее состояние.
Но давайте погрузимся немного глубже. 🐳
📬 Контракт также имеет идентификатор или адрес. Этот адрес является криптографическим хэшем исходных данных контракта и исходного кода. ❓ Почему это так? ☑️ Вы не хотите менять адрес всякий раз, когда меняется состояние контракта, и именно поэтому адрес однозначно идентифицирует само начальное состояние, с которым был создан контракт.
⛺️ Вторым важным аспектом контрактов является их местоположение.
Все эти данные полностью инкапсулированы, и с точки зрения программного кода он видит только хранилище самого контракта и его баланс. Он не может видеть состояние всех других контрактов. Это означает, что любые изменения, происходящие с контрактом в одной транзакции, полностью независимы от изменений в другом контракте в другой транзакции где-либо еще в блокчейне. Это ключ к бесконечной масштабируемости блокчейна TON.
Что можно сделать с контрактами?
❓ Что вы можете создать с помощью контрактов?
Во-первых, контракты позволяют создавать учетные записи пользователей. В TON учетная запись каждого пользователя фактически является контрактом на пользовательский кошелек.
Во-вторых, контракт с несколькими подписями, который управляется несколькими пользовательскими кошельками.
В-третьих, контракты используются для создания некоторых вещей, о которых вы обычно не думаете как о контракте. Например, токены.
Токены в TON
В TON токен, который вы можете передавать, на самом деле является отдельным контрактом, который имеет свое собственное состояние, определяющее некоторые атрибуты этого токена.
💰 Одним из этих атрибутов является владелец.
Всякий раз, когда вы хотите изменить владельца токена, вы должны отправить этому токену сообщение, в котором указывается новый владелец. Затем токен проверит, что сообщение отправлено соответствующим владельцем, сменит своего владельца на нового и покончит с этим.
Защита TON
Чтобы защитить сеть от атак типа "отказ в обслуживании", все контракты должны оплачивать свою работу.
Этот платеж (его также называют сборами) состоит из множества параметров, которые включают арендную плату, затраты на выполнение, маршрутизацию сообщений и некоторые другие вещи. Давайте углубимся в самые важные из них. 🐳
Адрес контракта - это криптографический хэш исходных данных контракта и исходного кода.
Все данные контракта полностью инкапсулированы, и с точки зрения программного кода он видит только хранилище самого контракта и его баланс.
Токен в TON, который вы можете передать, на самом деле является отдельным контрактом, который имеет свое собственное состояние, определяющее некоторые атрибуты этого токена.
Контракты на самом деле являются низкоуровневыми строительными блоками, из которых вы могли бы создавать учетные записи кошельков, протоколы с несколькими подписями, крупные децентрализованные приложения, отдельные токены или даже коллекции токенов.
TON гарантирует, что для каждого бита данных и для каждой секунды срока действия контракта существует определенный платеж, называемый арендной платой, который вычитается из баланса контракта.
📚Конспекты лекции
Давайте углубимся в счета и контракты.
Контракты
На предыдущем уроке мы узнали о контрактах следующее:
Учетная запись и контракт на низком уровне в TON являются взаимозаменяемыми терминами.
Контракт - это данные, код и баланс Toncoin.
Контракты получают входящие сообщения, обрабатывают их и отправляют исходящие сообщения, а также изменяют свое собственное внутреннее состояние.
Но давайте погрузимся немного глубже. 🐳
📬 Контракт также имеет идентификатор или адрес. Этот адрес является криптографическим хэшем исходных данных контракта и исходного кода. ❓ Почему это так? ☑️ Вы не хотите менять адрес всякий раз, когда меняется состояние контракта, и именно поэтому адрес однозначно идентифицирует само начальное состояние, с которым был создан контракт.
⛺️ Вторым важным аспектом контрактов является их местоположение.
Все эти данные полностью инкапсулированы, и с точки зрения программного кода он видит только хранилище самого контракта и его баланс. Он не может видеть состояние всех других контрактов. Это означает, что любые изменения, происходящие с контрактом в одной транзакции, полностью независимы от изменений в другом контракте в другой транзакции где-либо еще в блокчейне. Это ключ к бесконечной масштабируемости блокчейна TON.
Что можно сделать с контрактами?
❓ Что вы можете создать с помощью контрактов?
Во-первых, контракты позволяют создавать учетные записи пользователей. В TON учетная запись каждого пользователя фактически является контрактом на пользовательский кошелек.
Во-вторых, контракт с несколькими подписями, который управляется несколькими пользовательскими кошельками.
В-третьих, контракты используются для создания некоторых вещей, о которых вы обычно не думаете как о контракте. Например, токены.
Токены в TON
В TON токен, который вы можете передавать, на самом деле является отдельным контрактом, который имеет свое собственное состояние, определяющее некоторые атрибуты этого токена.
💰 Одним из этих атрибутов является владелец.
Всякий раз, когда вы хотите изменить владельца токена, вы должны отправить этому токену сообщение, в котором указывается новый владелец. Затем токен проверит, что сообщение отправлено соответствующим владельцем, сменит своего владельца на нового и покончит с этим.
Защита TON
Чтобы защитить сеть от атак типа "отказ в обслуживании", все контракты должны оплачивать свою работу.
Этот платеж (его также называют сборами) состоит из множества параметров, которые включают арендную плату, затраты на выполнение, маршрутизацию сообщений и некоторые другие вещи. Давайте углубимся в самые важные из них. 🐳
❗️ Каждый раз, когда вы выполняете код в контракте, вы вызываете затраты на газ – каждая инструкция в виртуальной машине, TVM, имеет определенную стоимость в абстрактных единицах, называемых gas. 💎 На уровне сети существует параметр, называемый ценой на газ, который определяет, сколько тонкоинов вы должны заплатить за каждую инструкцию. ⏳ Чем дольше работает ваша программа, тем больше затрат на газ она понесет, и эта стоимость вычитается из баланса контракта. ❌ Всякий раз, когда баланс опускается до нуля, выполнение прерывается, и транзакция завершается неудачей. 💲 Стоимость газа гарантирует, что вы не сможете наложить неограниченные затраты на выполнение работ на всю сеть, не заплатив за это.
Но есть еще одна важная стоимость, которая называется арендной платой!
❗️ TON гарантирует, что за каждый бит данных и за каждую секунду срока действия контракта взимается определенный платеж, называемый арендной платой, который вычитается из баланса контракта.
Соображения при разработке смарт-контрактов.
При разработке смарт-контрактов есть два наиболее важных соображения:
Расходы на газ, связанные с исполнением.
Арендная плата, которую должен нести контракт в течение срока его действия.
Замороженные контракты.
Если в контракте закончатся средства и из-за арендной платы, то он может быть заморожен 😰.
Это означает, что сеть выгрузит все свои данные и заменит их криптографическим хэшем последнего состояния. В этом случае данные не теряются, но сеть оптимизирует хранилище и выгружает дорогостоящие данные из хранилища валидаторов. Когда пользователь этого контракта приходит и хочет восстановить 🔮 контракт, чтобы разморозить его, он должен предоставить свой собственный снимок данных, который соответствует этому хэшу.
Но есть еще одна важная стоимость, которая называется арендной платой!
❗️ TON гарантирует, что за каждый бит данных и за каждую секунду срока действия контракта взимается определенный платеж, называемый арендной платой, который вычитается из баланса контракта.
Соображения при разработке смарт-контрактов.
При разработке смарт-контрактов есть два наиболее важных соображения:
Расходы на газ, связанные с исполнением.
Арендная плата, которую должен нести контракт в течение срока его действия.
Замороженные контракты.
Если в контракте закончатся средства и из-за арендной платы, то он может быть заморожен 😰.
Это означает, что сеть выгрузит все свои данные и заменит их криптографическим хэшем последнего состояния. В этом случае данные не теряются, но сеть оптимизирует хранилище и выгружает дорогостоящие данные из хранилища валидаторов. Когда пользователь этого контракта приходит и хочет восстановить 🔮 контракт, чтобы разморозить его, он должен предоставить свой собственный снимок данных, который соответствует этому хэшу.
1.5 Токены, валюты, элементы DNS и т.д.
📝 Вы также узнаете о:
Каковы некоторые важные аспекты контрактов в TON?
В чем ключ к бесконечной масштабируемости блокчейна TON?
Что можно построить с помощью контрактов?
Что предусмотрено в TON для защиты от атак типа "отказ в обслуживании"?
Каковы некоторые важные соображения при разработке смарт-контрактов?
📝 Вы также узнаете о:
Каковы некоторые важные аспекты контрактов в TON?
В чем ключ к бесконечной масштабируемости блокчейна TON?
Что можно построить с помощью контрактов?
Что предусмотрено в TON для защиты от атак типа "отказ в обслуживании"?
Каковы некоторые важные соображения при разработке смарт-контрактов?
📝 Теперь вы знаете:
Адрес контракта - это криптографический хэш исходных данных контракта и исходного кода.
Все данные контракта полностью инкапсулированы, и с точки зрения программного кода он видит только хранилище самого контракта и его баланс.
Токен в TON, который вы можете передать, на самом деле является отдельным контрактом, который имеет свое собственное состояние, определяющее некоторые атрибуты этого токена.
Контракты на самом деле являются низкоуровневыми строительными блоками, из которых вы могли бы создавать учетные записи кошельков, протоколы с несколькими подписями, крупные децентрализованные приложения, отдельные токены или даже коллекции токенов.
TON гарантирует, что за каждый бит данных и за каждую секунду срока действия контракта взимается определенный платеж, называемый арендной платой, который вычитается из баланса контракта.
📚Примечания к лекции
В этом уроке мы поговорим о токенах.
🎉 Важным аспектом платформы TON является то, что вы можете создавать свои собственные пользовательские ресурсы!
Это действительно означает всевозможные ценные вещи, которые вы собираетесь передать в своем приложении:
Валюты
Стабильные монеты
Поступления
Любые типы билетов
Любой финансовый контракт
📗 Токенизация – процесс разделения ценности, хранящейся в системе, на передаваемые фрагменты.
👀 Давайте посмотрим, какие токены существуют в TON.
Прежде всего, токены могут быть:
взаимозаменяемыми
, не взаимозаменяемыми
Что это значит?
Не взаимозаменяемые токены.
NFT (не взаимозаменяемые токены) - токены, которые удовлетворяют следующим свойствам:
Уникальный
Имеют владельца
Не могут быть разделены или объединены и свободно взаимозаменяемы
Взаимозаменяемые токены реализуют множество важных функций в экосистеме TON:
Записи TON DNS
Имена пользователей Telegram
Взаимозаменяемые токены.
Взаимозаменяемые токены добавляют еще одно измерение – у них также есть несколько единиц, которые могут взаимозаменяемо передаваться между пользователями.
В Ton взаимозаменяемые токены используются для реализации множества вещей:
Валюты
Криптовалюты
Доли
Права голоса
📙 В TON взаимозаменяемые токены реализованы масштабируемым образом.
В TON у вас нет единого контракта, который отслеживает все учетные записи, владеющие частями токена или единицами токена. Вместо этого существует множество независимых контрактов с одинаковым кодом, которые называются балансами токенов или кошельками токенов. И кошелек каждого пользователя напрямую взаимодействует с их собственным кошельком токенов.
Масштабируемость токенов
Что означает масштабируемость токенов? Это означает, что в то время как 👯 два пользователя осуществляют передачу одного токена между собой, эта передача не мешает транзакциям некоторых других 👬 двух пользователей, которые осуществляют передачу тех же токенов на каком-либо другом конце сети.
🔥 В TON все эти пользовательские ресурсы, которые вы создаете, наследуют полную неограниченную масштабируемость сети без каких-либо сокращений.
Вывод
Исходя из вышеизложенного, можно сделать следующие выводы:
💸 Взаимозаменяемые и невзаимозаменяемые токены позволяют вам реализовывать все виды активов, которые вы могли бы передавать непосредственно пользователям.
💎 Вместе с контрактами токены, созданные на основе контрактов, становятся одним из строительных блоков в арсенале разработчика приложений.
📚 Понимание того, как работают токены, важно для того, чтобы сделать вашу систему масштабируемой и производительной для всех пользователей в любом масштабе.
Адрес контракта - это криптографический хэш исходных данных контракта и исходного кода.
Все данные контракта полностью инкапсулированы, и с точки зрения программного кода он видит только хранилище самого контракта и его баланс.
Токен в TON, который вы можете передать, на самом деле является отдельным контрактом, который имеет свое собственное состояние, определяющее некоторые атрибуты этого токена.
Контракты на самом деле являются низкоуровневыми строительными блоками, из которых вы могли бы создавать учетные записи кошельков, протоколы с несколькими подписями, крупные децентрализованные приложения, отдельные токены или даже коллекции токенов.
TON гарантирует, что за каждый бит данных и за каждую секунду срока действия контракта взимается определенный платеж, называемый арендной платой, который вычитается из баланса контракта.
📚Примечания к лекции
В этом уроке мы поговорим о токенах.
🎉 Важным аспектом платформы TON является то, что вы можете создавать свои собственные пользовательские ресурсы!
Это действительно означает всевозможные ценные вещи, которые вы собираетесь передать в своем приложении:
Валюты
Стабильные монеты
Поступления
Любые типы билетов
Любой финансовый контракт
📗 Токенизация – процесс разделения ценности, хранящейся в системе, на передаваемые фрагменты.
👀 Давайте посмотрим, какие токены существуют в TON.
Прежде всего, токены могут быть:
взаимозаменяемыми
, не взаимозаменяемыми
Что это значит?
Не взаимозаменяемые токены.
NFT (не взаимозаменяемые токены) - токены, которые удовлетворяют следующим свойствам:
Уникальный
Имеют владельца
Не могут быть разделены или объединены и свободно взаимозаменяемы
Взаимозаменяемые токены реализуют множество важных функций в экосистеме TON:
Записи TON DNS
Имена пользователей Telegram
Взаимозаменяемые токены.
Взаимозаменяемые токены добавляют еще одно измерение – у них также есть несколько единиц, которые могут взаимозаменяемо передаваться между пользователями.
В Ton взаимозаменяемые токены используются для реализации множества вещей:
Валюты
Криптовалюты
Доли
Права голоса
📙 В TON взаимозаменяемые токены реализованы масштабируемым образом.
В TON у вас нет единого контракта, который отслеживает все учетные записи, владеющие частями токена или единицами токена. Вместо этого существует множество независимых контрактов с одинаковым кодом, которые называются балансами токенов или кошельками токенов. И кошелек каждого пользователя напрямую взаимодействует с их собственным кошельком токенов.
Масштабируемость токенов
Что означает масштабируемость токенов? Это означает, что в то время как 👯 два пользователя осуществляют передачу одного токена между собой, эта передача не мешает транзакциям некоторых других 👬 двух пользователей, которые осуществляют передачу тех же токенов на каком-либо другом конце сети.
🔥 В TON все эти пользовательские ресурсы, которые вы создаете, наследуют полную неограниченную масштабируемость сети без каких-либо сокращений.
Вывод
Исходя из вышеизложенного, можно сделать следующие выводы:
💸 Взаимозаменяемые и невзаимозаменяемые токены позволяют вам реализовывать все виды активов, которые вы могли бы передавать непосредственно пользователям.
💎 Вместе с контрактами токены, созданные на основе контрактов, становятся одним из строительных блоков в арсенале разработчика приложений.
📚 Понимание того, как работают токены, важно для того, чтобы сделать вашу систему масштабируемой и производительной для всех пользователей в любом масштабе.
🔥3
2. TVM, транзакции, масштабируемость
💎 Добро пожаловать во 2-ю главу.
В этой главе мы рассмотрим ряд тем. Мы кратко рассмотрим расположение памяти и создание экземпляров TVM. Теперь мы углубимся в обработку сообщений и исследуем истинную природу транзакций. Мы также рассмотрим важность аутентификации сообщений в контрактах. Кроме того, мы рассмотрим существующие в ГОРОДЕ сборы и рассмотрим, как принципы разработки контрактов могут быть применены к различным приложениям. Наконец, мы обсудим, как платформа TON облегчает разработку масштабируемых и безопасных приложений.
💎 Добро пожаловать во 2-ю главу.
В этой главе мы рассмотрим ряд тем. Мы кратко рассмотрим расположение памяти и создание экземпляров TVM. Теперь мы углубимся в обработку сообщений и исследуем истинную природу транзакций. Мы также рассмотрим важность аутентификации сообщений в контрактах. Кроме того, мы рассмотрим существующие в ГОРОДЕ сборы и рассмотрим, как принципы разработки контрактов могут быть применены к различным приложениям. Наконец, мы обсудим, как платформа TON облегчает разработку масштабируемых и безопасных приложений.
🔥1
📝 Вы также узнаете о:
Что такое ячейка в TON?
В чем смысл использования такого дизайна на основе ячеек в блокчейне TON?
Как мы храним в системе такие вещи, как списки, словари или наборы?
Что такое ячейка в TON?
В чем смысл использования такого дизайна на основе ячеек в блокчейне TON?
Как мы храним в системе такие вещи, как списки, словари или наборы?
📝 Теперь вы знаете:
Интересная вещь о 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. Каждая ячейка содержит до 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, языка более высокого уровня, с инструментами, которые помогают вам более эффективно работать с хэш-картами и использовать ячейки в качестве базовой реализации.
🔥1
Ключ к масштабируемости в TON.
❗️ Масштабируемость в TON заключается в ограничении объема работы, выполняемой в каком-либо одном месте, потому что TON масштабируется по контрактам, но каждый отдельный контракт сам по себе не масштабируется "из коробки".
❓ Какие ключевые моменты следует иметь в виду?
Вполне допустимо иметь вложенные ячейки для небольшого объема данных. Если вы создаете систему с очень небольшим количеством участников, скажем, контракт с несколькими подписями, тогда вы можете сохранить эти данные в своей хэш-карте прямо в контракте, и они будут достаточно маленькими. Однако, если вы создаете систему с миллионами пользователей, вам следует подумать об использовании токенов для представления участия пользователей и вообще избегать сохранения списков этих пользователей в вашем контракте.
Ячейки имеют встроенную детерминированную схему хэширования, которая позволяет однозначно идентифицировать любую ячейку в любой части дерева, и это используется как для дедупликации, так и для сжатия данных. Например, когда в контракте заканчиваются деньги для оплаты аренды, его текущее состояние выгружается из блокчейна. Это полностью забыто, но сеть по-прежнему хранит хэш ячейки хранения. Это означает, что пользователь может прийти позже и предоставить исходное 🌲 дерево ячеек, соответствующее этому хэшу, и повторно создать экземпляр контракта, и таким образом состояние контракта полностью сохраняется хэшем всего его хранилища.
Вывод.
Вот некоторые из основных результатов:
Все построено из 🔸 ячеек.
Поверх ячеек у вас есть типы, предоставляемые 💻 TVM.
TVM создается для каждого контракта для каждого сообщения, которое обрабатывается 📝 контрактом.
Вы должны знать о затратах, связанных с большими структурами данных и глубокими цепочками ячеек, которые могут повлечь за собой более высокие, чем обычно, затраты на выполнение вашего контракта.
❗️ Масштабируемость в TON заключается в ограничении объема работы, выполняемой в каком-либо одном месте, потому что TON масштабируется по контрактам, но каждый отдельный контракт сам по себе не масштабируется "из коробки".
❓ Какие ключевые моменты следует иметь в виду?
Вполне допустимо иметь вложенные ячейки для небольшого объема данных. Если вы создаете систему с очень небольшим количеством участников, скажем, контракт с несколькими подписями, тогда вы можете сохранить эти данные в своей хэш-карте прямо в контракте, и они будут достаточно маленькими. Однако, если вы создаете систему с миллионами пользователей, вам следует подумать об использовании токенов для представления участия пользователей и вообще избегать сохранения списков этих пользователей в вашем контракте.
Ячейки имеют встроенную детерминированную схему хэширования, которая позволяет однозначно идентифицировать любую ячейку в любой части дерева, и это используется как для дедупликации, так и для сжатия данных. Например, когда в контракте заканчиваются деньги для оплаты аренды, его текущее состояние выгружается из блокчейна. Это полностью забыто, но сеть по-прежнему хранит хэш ячейки хранения. Это означает, что пользователь может прийти позже и предоставить исходное 🌲 дерево ячеек, соответствующее этому хэшу, и повторно создать экземпляр контракта, и таким образом состояние контракта полностью сохраняется хэшем всего его хранилища.
Вывод.
Вот некоторые из основных результатов:
Все построено из 🔸 ячеек.
Поверх ячеек у вас есть типы, предоставляемые 💻 TVM.
TVM создается для каждого контракта для каждого сообщения, которое обрабатывается 📝 контрактом.
Вы должны знать о затратах, связанных с большими структурами данных и глубокими цепочками ячеек, которые могут повлечь за собой более высокие, чем обычно, затраты на выполнение вашего контракта.
🔥1
2.2 Типы сообщений и этапы вычисления
📝 Вы также узнаете о:
Какие типы сообщений может получать контракт?
Что такое транзакция?
Каковы этапы транзакции?
📝 Вы также узнаете о:
Какие типы сообщений может получать контракт?
Что такое транзакция?
Каковы этапы транзакции?
📝 Теперь вы знаете:
Существует два вида входящих сообщений, которые могут поступать в контракт: внешние и внутренние.
Внешнее сообщение - это на самом деле просто строка данных, которая берется из ниоткуда с точки зрения блокчейна. Эти данные сами по себе не аутентифицируются. К нему не привязаны никакие деньги в виде тонкоинов. И он действительно может содержать все, что захочет автор контракта.
Внутренние сообщения - это те, которые отправляются контрактами другим контрактам. И эти сообщения имеют немного более богатую структуру. Прежде всего, внутренние сообщения могут содержать балансы. И когда контракт отправляет сообщение другому контракту, они могут прикрепить к нему любое количество монет. Во-вторых, эти сообщения надежно аутентифицируются по адресу отправляющего контракта. И вся архитектура TON гарантирует контрактам, что этот адрес отправителя правильный.
Транзакция - это комплекс изменений состояния контракта.
Транзакция проходит пять фаз: фаза хранения, фаза зачисления, фаза вычисления, фаза действия, фаза возврата.
Фаза хранения - это фаза, когда блокчейн взимает с контракта всю арендную плату, которую он должен за свое существование. И арендная плата рассчитывается как цена за бит в секунду.
Фаза зачисления - это фаза, когда монеты, прикрепленные к входящему сообщению, зачисляются на контракт.
На этапе расчета TVM выполняет код и проверяет каждую операцию, а также отслеживает использование газа.
На этапе действия смарт-контракт переходит в новое состояние, и исходящие сообщения обрабатываются.
Фаза возврата происходит, если контракт завершился неудачно, а во входящем сообщении был отмечен флаг, говорящий, что я могу вернуть сообщение. Это означает, что на данном этапе, если произойдет какой-либо сбой и от входящего сообщения останутся какие-либо деньги, контракт вернет исходящее сообщение отправителю, чтобы вернуть деньги обратно.
📚Примечания к лекции
Давайте углубимся в то, как обрабатывается сообщение и что на самом деле является транзакцией.
💌 Для того, чтобы контракт изменил свое состояние, он должен получить сообщение. Это называется входящим сообщением.
Существует два типа входящих сообщений:
⚪️ - Внешние сообщения. 🔵 - Внутренние сообщения.
Внешние сообщения.
Внешнее сообщение - строка данных, которая берется из ниоткуда с точки зрения блокчейна.
Эти данные сами по себе не аутентифицируются.
К ним не привязаны какие-либо деньги в виде 💎 тонкоинов.
Они действительно могут содержать все, что захочет автор контракта.
❗️ Задача контракта - разобраться в этих данных и проанализировать их прямо в своем коде.
Внутренние сообщения.
Внутренние сообщения - те, которые отправляются контрактами другим контрактам. 👥
Эти сообщения имеют немного более богатую структуру:
Внутренние сообщения могут содержать балансы. 💸
Эти сообщения надежно аутентифицируются по адресу контракта на отправку. 🔑 Вся архитектура TON гарантирует контрактам, что этот адрес отправителя правильный.
Обработка сообщений и кодов операций.
Как только контракт получит сообщение, у него может быть два отдельных обработчика для внутреннего и внешнего. Оба вида сообщений будут содержать произвольные 🗻 данные полезной нагрузки, разработанные автором контракта. Если контракт хочет обрабатывать различные типы сообщений, то он будет использовать то, что мы называем кодами операций.
Коды операций (коды операций) 🔢 - префикс из четырех байт в пользовательских данных в сообщении для указания типа операции, которую должен поддерживать контракт.
Операции.
❓ Что такое транзакция?
Транзакция 💸 - комплекс изменений состояния контракта. ❗️ Сообщение - это не транзакция, это просто входные данные для транзакции!
❓ Что делает транзакция?
1. ▶️ Оно изменяет состояние контракта. 2. 📋 Он создает список исходящих действий.
Существует два вида входящих сообщений, которые могут поступать в контракт: внешние и внутренние.
Внешнее сообщение - это на самом деле просто строка данных, которая берется из ниоткуда с точки зрения блокчейна. Эти данные сами по себе не аутентифицируются. К нему не привязаны никакие деньги в виде тонкоинов. И он действительно может содержать все, что захочет автор контракта.
Внутренние сообщения - это те, которые отправляются контрактами другим контрактам. И эти сообщения имеют немного более богатую структуру. Прежде всего, внутренние сообщения могут содержать балансы. И когда контракт отправляет сообщение другому контракту, они могут прикрепить к нему любое количество монет. Во-вторых, эти сообщения надежно аутентифицируются по адресу отправляющего контракта. И вся архитектура TON гарантирует контрактам, что этот адрес отправителя правильный.
Транзакция - это комплекс изменений состояния контракта.
Транзакция проходит пять фаз: фаза хранения, фаза зачисления, фаза вычисления, фаза действия, фаза возврата.
Фаза хранения - это фаза, когда блокчейн взимает с контракта всю арендную плату, которую он должен за свое существование. И арендная плата рассчитывается как цена за бит в секунду.
Фаза зачисления - это фаза, когда монеты, прикрепленные к входящему сообщению, зачисляются на контракт.
На этапе расчета TVM выполняет код и проверяет каждую операцию, а также отслеживает использование газа.
На этапе действия смарт-контракт переходит в новое состояние, и исходящие сообщения обрабатываются.
Фаза возврата происходит, если контракт завершился неудачно, а во входящем сообщении был отмечен флаг, говорящий, что я могу вернуть сообщение. Это означает, что на данном этапе, если произойдет какой-либо сбой и от входящего сообщения останутся какие-либо деньги, контракт вернет исходящее сообщение отправителю, чтобы вернуть деньги обратно.
📚Примечания к лекции
Давайте углубимся в то, как обрабатывается сообщение и что на самом деле является транзакцией.
💌 Для того, чтобы контракт изменил свое состояние, он должен получить сообщение. Это называется входящим сообщением.
Существует два типа входящих сообщений:
⚪️ - Внешние сообщения. 🔵 - Внутренние сообщения.
Внешние сообщения.
Внешнее сообщение - строка данных, которая берется из ниоткуда с точки зрения блокчейна.
Эти данные сами по себе не аутентифицируются.
К ним не привязаны какие-либо деньги в виде 💎 тонкоинов.
Они действительно могут содержать все, что захочет автор контракта.
❗️ Задача контракта - разобраться в этих данных и проанализировать их прямо в своем коде.
Внутренние сообщения.
Внутренние сообщения - те, которые отправляются контрактами другим контрактам. 👥
Эти сообщения имеют немного более богатую структуру:
Внутренние сообщения могут содержать балансы. 💸
Эти сообщения надежно аутентифицируются по адресу контракта на отправку. 🔑 Вся архитектура TON гарантирует контрактам, что этот адрес отправителя правильный.
Обработка сообщений и кодов операций.
Как только контракт получит сообщение, у него может быть два отдельных обработчика для внутреннего и внешнего. Оба вида сообщений будут содержать произвольные 🗻 данные полезной нагрузки, разработанные автором контракта. Если контракт хочет обрабатывать различные типы сообщений, то он будет использовать то, что мы называем кодами операций.
Коды операций (коды операций) 🔢 - префикс из четырех байт в пользовательских данных в сообщении для указания типа операции, которую должен поддерживать контракт.
Операции.
❓ Что такое транзакция?
Транзакция 💸 - комплекс изменений состояния контракта. ❗️ Сообщение - это не транзакция, это просто входные данные для транзакции!
❓ Что делает транзакция?
1. ▶️ Оно изменяет состояние контракта. 2. 📋 Он создает список исходящих действий.
Этапы транзакции.
Существует пять этапов 5️⃣, которые проходит транзакция:
Этап хранения 📒 Вычитает плату за хранение на основе байтов, сохраненных контрактом с момента последней транзакции. Если средств недостаточно, контракт переходит в замороженное состояние, сохраняя свое состояние в течение ограниченного времени.
Фаза зачисления - Это когда монеты, прикрепленные к входящему сообщению, зачисляются на контракт.
Фаза вычисления - это когда ваша программа оживает. TVM выполняет код и проверяет каждую операцию, а также отслеживает использование газа.
Фаза действия 🏃 Наиболее важным действием на этом этапе является новое состояние контракта. Ваш контракт может в конце выполнения или на любом промежуточном этапе создать новое состояние и новое хранилище для себя, и это будет записано после успешного выполнения контракта. В списке есть и другие действия, и эти действия являются исходящими сообщениями.
Фаза возврата 🎱 Это происходит, если контракт не был выполнен и во входящем сообщении был отмечен флаг, говорящий, что я могу вернуть сообщение. Это означает, что на данном этапе, если произойдет какой-либо сбой и от входящего сообщения останутся какие-либо деньги, то контракт создаст исходящее сообщение обратно отправителю, чтобы вернуть деньги обратно. Это функция безопасности, которая позволяет людям вернуть большую часть средств в случае возникновения какой-либо ошибки или сбоя в контракте.
Вывод.
Давайте подведем итог:
Контракт получает входящее сообщение, которое может быть внутренним или внешним.
Внутренние сообщения могут содержать деньги и могут быть аутентифицированы по адресу отправляющего контракта, в то время как внешние сообщения вообще не аутентифицируются сами по себе, и задача контракта - создать аутентификацию.
Выполнение транзакции проходит через пять этапов.
Этап хранения для взимания арендной платы.
Фаза зачисления, когда поступающие монеты зачисляются на баланс.
Фаза вычисления, на которой выполняется ваш код.
Фаза действия, когда хранилище обновляется и исходящие сообщения перенаправляются.
Фаза возврата, когда контракт устраняет сбои и отправляет монеты обратно отправителю.
Существует пять этапов 5️⃣, которые проходит транзакция:
Этап хранения 📒 Вычитает плату за хранение на основе байтов, сохраненных контрактом с момента последней транзакции. Если средств недостаточно, контракт переходит в замороженное состояние, сохраняя свое состояние в течение ограниченного времени.
Фаза зачисления - Это когда монеты, прикрепленные к входящему сообщению, зачисляются на контракт.
Фаза вычисления - это когда ваша программа оживает. TVM выполняет код и проверяет каждую операцию, а также отслеживает использование газа.
Фаза действия 🏃 Наиболее важным действием на этом этапе является новое состояние контракта. Ваш контракт может в конце выполнения или на любом промежуточном этапе создать новое состояние и новое хранилище для себя, и это будет записано после успешного выполнения контракта. В списке есть и другие действия, и эти действия являются исходящими сообщениями.
Фаза возврата 🎱 Это происходит, если контракт не был выполнен и во входящем сообщении был отмечен флаг, говорящий, что я могу вернуть сообщение. Это означает, что на данном этапе, если произойдет какой-либо сбой и от входящего сообщения останутся какие-либо деньги, то контракт создаст исходящее сообщение обратно отправителю, чтобы вернуть деньги обратно. Это функция безопасности, которая позволяет людям вернуть большую часть средств в случае возникновения какой-либо ошибки или сбоя в контракте.
Вывод.
Давайте подведем итог:
Контракт получает входящее сообщение, которое может быть внутренним или внешним.
Внутренние сообщения могут содержать деньги и могут быть аутентифицированы по адресу отправляющего контракта, в то время как внешние сообщения вообще не аутентифицируются сами по себе, и задача контракта - создать аутентификацию.
Выполнение транзакции проходит через пять этапов.
Этап хранения для взимания арендной платы.
Фаза зачисления, когда поступающие монеты зачисляются на баланс.
Фаза вычисления, на которой выполняется ваш код.
Фаза действия, когда хранилище обновляется и исходящие сообщения перенаправляются.
Фаза возврата, когда контракт устраняет сбои и отправляет монеты обратно отправителю.
2.3 Авторизация сообщений в контрактах
📝 Вы также узнаете о том:
Какие категории аутентификации существуют в блокчейне TON?
📝 Вы также узнаете о том:
Какие категории аутентификации существуют в блокчейне TON?
📝 Теперь вы знаете:
Первый тип аутентификации - это аутентификация на основе подписи, например, в случае внешнего сообщения кошелек считывает первую часть данных, проверяет правильность подписи, а затем работает с остальной частью сообщения.
Второй механизм - аутентификация отправителя сообщения. Все внутренние сообщения в TON идентифицируются отправителем сообщения, корректность и безопасность которого гарантируется протоколом TON. Таким образом, каждый раз, когда контракт получает внутреннее сообщение, он точно знает, от какого другого контракта было получено сообщение.
Третий создается поверх отправителя сообщения. Поскольку адреса в экосистеме TON являются не просто уникальными идентификаторами контрактов, но и криптографически защищенными хэшами кода контракта и данных, а более конкретно, исходного кода и данных, поэтому они не меняются при изменении данных. И поскольку эти адреса являются криптографическими обязательствами для этого кода, вы могли бы проверить, какой код используется на другом конце, проверив отправителя сообщения.
Четвертый тип аутентификации - это то, о чем не следует забывать. Это отсутствие аутентификации вообще. Это важный шаблон, который вступает в игру, если вы создаете по-настоящему децентрализованные приложения.
📚Примечания к лекции
В этом уроке рассматриваются различные методы авторизации для сообщений.
Обзор всех типов аутентификации
Аутентификация с помощью подписи.
❗️ Любое событие в блокчейне TON должно начинаться с внешнего сообщения. Всякий раз, когда внешнее сообщение поступает в wallet, оно считывает 64 байта данных 6️⃣4️⃣, которые являются подписью для остальной части сообщения, проверяет подпись своим открытым ключом, а затем обрабатывает остальную часть сообщения как инструкции для отправки других сообщений другим контрактам внутри кошелька. блокчейн.
Аутентификация отправителя сообщения.
Все внутренние сообщения в TON идентифицируются отправителем сообщения, корректность и безопасность которого гарантируется протоколом TON. Каждый раз, когда контракт получает внутреннее сообщение, он точно знает, от какого другого контракта было получено сообщение. И это намного дешевле и эффективнее, чем проверка подписей.
Проверка ДНК на наличие надежного кода. 🙌
Поскольку адреса в экосистеме TON являются не просто уникальными идентификаторами контрактов, но и криптографически защищенными хэшами кода контракта и данных, они не меняются при изменении данных. Поскольку эти адреса являются криптографическими привязками к данному коду, вы можете проверить, какой код используется на другом конце, проверив отправителя сообщения.
Отсутствие аутентификации для защиты от цензуры.
❓ Разве небезопасно не проверять подлинность сообщений? В определенных ситуациях именно в этом и заключается безопасность. Вы можете иметь дело с системой, которая должна быть устойчива к цензуре, такой как децентрализованный пул ставок
Первый тип аутентификации - это аутентификация на основе подписи, например, в случае внешнего сообщения кошелек считывает первую часть данных, проверяет правильность подписи, а затем работает с остальной частью сообщения.
Второй механизм - аутентификация отправителя сообщения. Все внутренние сообщения в TON идентифицируются отправителем сообщения, корректность и безопасность которого гарантируется протоколом TON. Таким образом, каждый раз, когда контракт получает внутреннее сообщение, он точно знает, от какого другого контракта было получено сообщение.
Третий создается поверх отправителя сообщения. Поскольку адреса в экосистеме TON являются не просто уникальными идентификаторами контрактов, но и криптографически защищенными хэшами кода контракта и данных, а более конкретно, исходного кода и данных, поэтому они не меняются при изменении данных. И поскольку эти адреса являются криптографическими обязательствами для этого кода, вы могли бы проверить, какой код используется на другом конце, проверив отправителя сообщения.
Четвертый тип аутентификации - это то, о чем не следует забывать. Это отсутствие аутентификации вообще. Это важный шаблон, который вступает в игру, если вы создаете по-настоящему децентрализованные приложения.
📚Примечания к лекции
В этом уроке рассматриваются различные методы авторизации для сообщений.
Обзор всех типов аутентификации
Аутентификация с помощью подписи.
❗️ Любое событие в блокчейне TON должно начинаться с внешнего сообщения. Всякий раз, когда внешнее сообщение поступает в wallet, оно считывает 64 байта данных 6️⃣4️⃣, которые являются подписью для остальной части сообщения, проверяет подпись своим открытым ключом, а затем обрабатывает остальную часть сообщения как инструкции для отправки других сообщений другим контрактам внутри кошелька. блокчейн.
Аутентификация отправителя сообщения.
Все внутренние сообщения в TON идентифицируются отправителем сообщения, корректность и безопасность которого гарантируется протоколом TON. Каждый раз, когда контракт получает внутреннее сообщение, он точно знает, от какого другого контракта было получено сообщение. И это намного дешевле и эффективнее, чем проверка подписей.
Проверка ДНК на наличие надежного кода. 🙌
Поскольку адреса в экосистеме TON являются не просто уникальными идентификаторами контрактов, но и криптографически защищенными хэшами кода контракта и данных, они не меняются при изменении данных. Поскольку эти адреса являются криптографическими привязками к данному коду, вы можете проверить, какой код используется на другом конце, проверив отправителя сообщения.
Отсутствие аутентификации для защиты от цензуры.
❓ Разве небезопасно не проверять подлинность сообщений? В определенных ситуациях именно в этом и заключается безопасность. Вы можете иметь дело с системой, которая должна быть устойчива к цензуре, такой как децентрализованный пул ставок
2.4 Типы сообщений и этапы вычисления
📝 Вы также узнаете о:
Сколько типов комиссий существует в блокчейне TON?
Какие полезные шаблоны присутствуют в хорошо продуманном смарт-контракте?
📝 Вы также узнаете о:
Сколько типов комиссий существует в блокчейне TON?
Какие полезные шаблоны присутствуют в хорошо продуманном смарт-контракте?
📝 Теперь вы знаете:
TON - это общедоступная сеть, и, как и любая общедоступная сеть, она подвержена атакам со стороны любого, кто этого пожелает, поэтому следует проявлять особую осторожность при защите этого общего ресурса от атак типа "отказ в обслуживании".
В TON обычно существует три категории сборов. Это стоимость газа, арендная плата и плата за сообщение.
Идея, лежащая в основе стоимости газа, заключается в том, что для каждой операции в вашем коде существует номинальная стоимость газа, которая позволяет вам указать, насколько некоторые операции дороже или дешевле других.
Арендная плата просто определяется как стоимость одного бита данных, которые контракт хранит в единицу времени, то есть в секунду.
Плата за сообщение вступает в силу на этапе действия, когда ваш контракт создает исходящие сообщения и определяет для себя новое состояние. И, как правило, это довольно низкие сборы, потому что между контрактами передается не так много данных.
📚Конспекты лекций
TON - сложная система, и в TON не может быть ничего более сложного, чем ее модель транзакционных издержек и комиссий. Итак, давайте углубимся 🌊 в то, какие виды комиссий существуют в TON. Прежде всего, давайте поговорим о том, почему это важно.
Важность комиссий.
🌐 TON - это общедоступная сеть, и, как и любая общедоступная сеть, она подвержена атакам со стороны любого, кто пожелает это сделать, поэтому следует проявлять особую осторожность при защите этого общего ресурса от атак типа "отказ в обслуживании".
❗️ Это означает, что если есть какие-либо нетривиальные издержки, которые несут некоторые участники сети и которые могут быть увеличены внешними субъектами, это создает огромный риск для жизнеспособности всей экосистемы. ⚠️ Вот почему все, что имеет сколько-нибудь заметную стоимость и может быть увеличено, должно быть явно учтено с точки зрения сборов.
В TON обычно существует три категории сборов:
Стоимость газа.
Арендовать.
Плата за сообщение.
Плата за газ.
💻 TON - это вычислительная платформа. Ваш контракт может содержать произвольный код, и любой желающий может загрузить в сеть любой код, который он захочет. Как только он это сделает, вся сеть будет обрабатывать 🔨 сообщения ✉️ с использованием этого кода.
🚗 Термин "газ" происходит от "бензин", как топливо для выполнения, и первоначально он был изобретен в Ethereum. Идея заключается в том, что для каждой операции в вашем коде существует номинальная стоимость газа, которая позволяет вам указать, насколько некоторые операции дороже или дешевле других. И еще есть глобальный параметр, который определяет цену на газ, который определяет, сколько стоят все эти газовые установки по текущим ценам.
❗️ TON спроектирован, в отличие от Ethereum или Bitcoin, таким образом, чтобы не создавать рынок для ограниченного количества газа или размера блока. Вместо этого он бесконечно разбивается на сегменты, так что если сегодня вы платите одну цену за газ, а завтра у вас гораздо более высокая нагрузка 🔺, то валидаторы сети будут получать более высокие сборы, но пользователям не придется конкурировать за сборы и они будут платить ту же цену, просто сеть будет масштабироваться горизонтально.
Соображения, касающиеся газа.
Вы, как дизайнер, должны позаботиться о паре соображений, касающихся газа.
Вы должны позаботиться о том, чтобы решить, кто будет оплачивать расходы на газ, будь то ваш контракт или отправитель сообщения, который отправляет сообщение в этот контракт. 😩
Лучшая стратегия - возложить все расходы на отправителя и составить свой контракт таким образом, чтобы расходы были более или менее предсказуемы для отправителя, чтобы он мог прикрепить к своему сообщению достаточное количество монет для покрытия расходов на бензин
Арендовать.
Арендная плата - стоимость одного бита данных, которые хранятся в контракте в единицу времени.
> ❓ *Если вы пользуетесь кошельком, вы можете заметить, что если вы не пользовались кошельком в течение нескольких дней, то комиссия за первую отправленную вами транзакцию немного выше, чем за следующую.*
TON - это общедоступная сеть, и, как и любая общедоступная сеть, она подвержена атакам со стороны любого, кто этого пожелает, поэтому следует проявлять особую осторожность при защите этого общего ресурса от атак типа "отказ в обслуживании".
В TON обычно существует три категории сборов. Это стоимость газа, арендная плата и плата за сообщение.
Идея, лежащая в основе стоимости газа, заключается в том, что для каждой операции в вашем коде существует номинальная стоимость газа, которая позволяет вам указать, насколько некоторые операции дороже или дешевле других.
Арендная плата просто определяется как стоимость одного бита данных, которые контракт хранит в единицу времени, то есть в секунду.
Плата за сообщение вступает в силу на этапе действия, когда ваш контракт создает исходящие сообщения и определяет для себя новое состояние. И, как правило, это довольно низкие сборы, потому что между контрактами передается не так много данных.
📚Конспекты лекций
TON - сложная система, и в TON не может быть ничего более сложного, чем ее модель транзакционных издержек и комиссий. Итак, давайте углубимся 🌊 в то, какие виды комиссий существуют в TON. Прежде всего, давайте поговорим о том, почему это важно.
Важность комиссий.
🌐 TON - это общедоступная сеть, и, как и любая общедоступная сеть, она подвержена атакам со стороны любого, кто пожелает это сделать, поэтому следует проявлять особую осторожность при защите этого общего ресурса от атак типа "отказ в обслуживании".
❗️ Это означает, что если есть какие-либо нетривиальные издержки, которые несут некоторые участники сети и которые могут быть увеличены внешними субъектами, это создает огромный риск для жизнеспособности всей экосистемы. ⚠️ Вот почему все, что имеет сколько-нибудь заметную стоимость и может быть увеличено, должно быть явно учтено с точки зрения сборов.
В TON обычно существует три категории сборов:
Стоимость газа.
Арендовать.
Плата за сообщение.
Плата за газ.
💻 TON - это вычислительная платформа. Ваш контракт может содержать произвольный код, и любой желающий может загрузить в сеть любой код, который он захочет. Как только он это сделает, вся сеть будет обрабатывать 🔨 сообщения ✉️ с использованием этого кода.
🚗 Термин "газ" происходит от "бензин", как топливо для выполнения, и первоначально он был изобретен в Ethereum. Идея заключается в том, что для каждой операции в вашем коде существует номинальная стоимость газа, которая позволяет вам указать, насколько некоторые операции дороже или дешевле других. И еще есть глобальный параметр, который определяет цену на газ, который определяет, сколько стоят все эти газовые установки по текущим ценам.
❗️ TON спроектирован, в отличие от Ethereum или Bitcoin, таким образом, чтобы не создавать рынок для ограниченного количества газа или размера блока. Вместо этого он бесконечно разбивается на сегменты, так что если сегодня вы платите одну цену за газ, а завтра у вас гораздо более высокая нагрузка 🔺, то валидаторы сети будут получать более высокие сборы, но пользователям не придется конкурировать за сборы и они будут платить ту же цену, просто сеть будет масштабироваться горизонтально.
Соображения, касающиеся газа.
Вы, как дизайнер, должны позаботиться о паре соображений, касающихся газа.
Вы должны позаботиться о том, чтобы решить, кто будет оплачивать расходы на газ, будь то ваш контракт или отправитель сообщения, который отправляет сообщение в этот контракт. 😩
Лучшая стратегия - возложить все расходы на отправителя и составить свой контракт таким образом, чтобы расходы были более или менее предсказуемы для отправителя, чтобы он мог прикрепить к своему сообщению достаточное количество монет для покрытия расходов на бензин
Арендовать.
Арендная плата - стоимость одного бита данных, которые хранятся в контракте в единицу времени.
> ❓ *Если вы пользуетесь кошельком, вы можете заметить, что если вы не пользовались кошельком в течение нескольких дней, то комиссия за первую отправленную вами транзакцию немного выше, чем за следующую.*
😲 Это связано с тем, что ваш кошелек простаивал неделю или две, и накопилась некоторая заметная сумма арендной платы, которая была списана при совершении этой транзакции.
Плата за сообщение.
💭 Это вступает в силу на этапе действия, когда ваш контракт создает исходящие сообщения и определяет для себя новое состояние. И это, как правило, довольно низкие сборы, потому что между контрактами передается не так много данных.
Соображения при разработке смарт-контрактов
В контрактах не должно заканчиваться топливо и арендная плата.
Если вы возлагаете стоимость газа и исполнения на отправителя, то вы не всегда сможете гарантировать определенную стоимость исполнения по разным причинам. Но что вы могли бы гарантировать, так это какую-то верхнюю границу. ☔️
Стремитесь к тому, чтобы ваши контракты предусматривали постоянную стоимость с точки зрения хранения и расчетов. Потому что таким образом ваша арендная плата и расходы на газ могут быть более предсказуемыми.
Плата за сообщение.
💭 Это вступает в силу на этапе действия, когда ваш контракт создает исходящие сообщения и определяет для себя новое состояние. И это, как правило, довольно низкие сборы, потому что между контрактами передается не так много данных.
Соображения при разработке смарт-контрактов
В контрактах не должно заканчиваться топливо и арендная плата.
Если вы возлагаете стоимость газа и исполнения на отправителя, то вы не всегда сможете гарантировать определенную стоимость исполнения по разным причинам. Но что вы могли бы гарантировать, так это какую-то верхнюю границу. ☔️
Стремитесь к тому, чтобы ваши контракты предусматривали постоянную стоимость с точки зрения хранения и расчетов. Потому что таким образом ваша арендная плата и расходы на газ могут быть более предсказуемыми.