📖 Каковы основные идеи Ethereum?
Сначала проголосуйте, правильный ответ в комментариях. (подсказка - правильных ответа 2)
Сначала проголосуйте, правильный ответ в комментариях. (подсказка - правильных ответа 2)
Anonymous Poll
11%
Ethereum полагается на другой, менее требовательный консенсус.
74%
Транзакции Ethereum могут передавать состояние, а не только наличные.
20%
Монеты являются новой и лучшей альтернативой BTC.
77%
Учетные записи могут синхронно взаимодействовать друг с другом в виде функций смарт-контрактов.
1.4 Концепция счета/контракта
📝 Вы также узнаете о:
Каковы некоторые важные аспекты контрактов в TON?
В чем ключ к бесконечной масштабируемости блокчейна TON?
Что можно создать с помощью контрактов?
Что предусмотрено в TON для защиты от атак типа "отказ в обслуживании"?
Каковы некоторые важные соображения при разработке смарт-контрактов?
📝 Вы также узнаете о:
Каковы некоторые важные аспекты контрактов в TON?
В чем ключ к бесконечной масштабируемости блокчейна TON?
Что можно создать с помощью контрактов?
Что предусмотрено в TON для защиты от атак типа "отказ в обслуживании"?
Каковы некоторые важные соображения при разработке смарт-контрактов?
📝 Теперь вы знаете:
Адрес контракта - это криптографический хэш исходных данных контракта и исходного кода.
Все данные контракта полностью инкапсулированы, и с точки зрения программного кода он видит только хранилище самого контракта и его баланс.
Токен в 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?
Какие полезные шаблоны присутствуют в хорошо продуманном смарт-контракте?