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, таким образом, чтобы не создавать рынок для ограниченного количества газа или размера блока. Вместо этого он бесконечно разбивается на сегменты, так что если сегодня вы платите одну цену за газ, а завтра у вас гораздо более высокая нагрузка 🔺, то валидаторы сети будут получать более высокие сборы, но пользователям не придется конкурировать за сборы и они будут платить ту же цену, просто сеть будет масштабироваться горизонтально.
Соображения, касающиеся газа.
Вы, как дизайнер, должны позаботиться о паре соображений, касающихся газа.
Вы должны позаботиться о том, чтобы решить, кто будет оплачивать расходы на газ, будь то ваш контракт или отправитель сообщения, который отправляет сообщение в этот контракт. 😩
Лучшая стратегия - возложить все расходы на отправителя и составить свой контракт таким образом, чтобы расходы были более или менее предсказуемы для отправителя, чтобы он мог прикрепить к своему сообщению достаточное количество монет для покрытия расходов на бензин
Арендовать.
Арендная плата - стоимость одного бита данных, которые хранятся в контракте в единицу времени.
> ❓ *Если вы пользуетесь кошельком, вы можете заметить, что если вы не пользовались кошельком в течение нескольких дней, то комиссия за первую отправленную вами транзакцию немного выше, чем за следующую.*
😲 Это связано с тем, что ваш кошелек простаивал неделю или две, и накопилась некоторая заметная сумма арендной платы, которая была списана при совершении этой транзакции.
Плата за сообщение.
💭 Это вступает в силу на этапе действия, когда ваш контракт создает исходящие сообщения и определяет для себя новое состояние. И это, как правило, довольно низкие сборы, потому что между контрактами передается не так много данных.
Соображения при разработке смарт-контрактов
В контрактах не должно заканчиваться топливо и арендная плата.
Если вы возлагаете стоимость газа и исполнения на отправителя, то вы не всегда сможете гарантировать определенную стоимость исполнения по разным причинам. Но что вы могли бы гарантировать, так это какую-то верхнюю границу. ☔️
Стремитесь к тому, чтобы ваши контракты предусматривали постоянную стоимость с точки зрения хранения и расчетов. Потому что таким образом ваша арендная плата и расходы на газ могут быть более предсказуемыми.
Плата за сообщение.
💭 Это вступает в силу на этапе действия, когда ваш контракт создает исходящие сообщения и определяет для себя новое состояние. И это, как правило, довольно низкие сборы, потому что между контрактами передается не так много данных.
Соображения при разработке смарт-контрактов
В контрактах не должно заканчиваться топливо и арендная плата.
Если вы возлагаете стоимость газа и исполнения на отправителя, то вы не всегда сможете гарантировать определенную стоимость исполнения по разным причинам. Но что вы могли бы гарантировать, так это какую-то верхнюю границу. ☔️
Стремитесь к тому, чтобы ваши контракты предусматривали постоянную стоимость с точки зрения хранения и расчетов. Потому что таким образом ваша арендная плата и расходы на газ могут быть более предсказуемыми.
2.5 Масштабируемые контракты
📝 Вы также узнаете о:
Что на самом деле означает бесконечная горизонтальная масштабируемость и как вы используете это в своих приложениях?
Каким принципам следует следовать, чтобы выжать максимум из масштабируемого блокчейна TON?
📝 Вы также узнаете о:
Что на самом деле означает бесконечная горизонтальная масштабируемость и как вы используете это в своих приложениях?
Каким принципам следует следовать, чтобы выжать максимум из масштабируемого блокчейна TON?
📝 Теперь вы знаете:
TON гарантирует, что он может масштабироваться до уровня детализации отдельных контрактов.
Контракты монолитного кошелька из Ethereum на блокчейне TON должны быть реализованы по-другому ради скорости, масштабируемости и экономии газа.
Избегайте использования данных переменной длины в качестве первоочередной задачи.
Если вам нужен список, то, по крайней мере, сделайте его коротким и ограниченным, например, статически определенным.
Доменное имя TON DNS - это коллекционный несменяемый токен, с которым может быть связано произвольное количество дополнительных записей.
Масштабируемый способ создания больших списков или словарей данных в TON заключается в использовании самого блокчейна в качестве массива.
Токены в TON спроектированы таким образом, что существует единый контракт minter, но в этом контракте не хранится список всех его пользователей. Вместо этого ему разрешено чеканить и создавать токены для других пользователей, а балансы отдельных пользователей распределяются по так называемым кошелькам Jettons.
📚Конспекты лекции
Давайте поговорим о масштабируемости.
💎 В TON у вас действительно есть очень конкретная гарантия масштабируемости. TON гарантирует вам, что он может масштабироваться до уровня детализации отдельных контрактов.
Таким образом, операции с одним контрактом не создадут узкого места 🍼 для операций с другим контрактом. И тогда сеть TON, очевидно, позаботится обо всей маршрутизации сообщений 🚅 между ними.
❗️ Ваша задача - использовать преимущества всей масштабируемости блокчейна и не создавать узких мест в ваших собственных контрактах!
Проблемы с монолитными контрактами.
Одна из очевидных проблем для людей, использующих традиционные системы, крупномасштабные веб-базы данных или Ethereum, заключается в том, что они разрабатывают свои контракты как монолитные приложения со своим собственным хранилищем переменной длины.
🌐 Например, в Ethereum токен реализован в виде банковской книги, где у вас есть единый смарт-контракт, содержащий список учетных записей. И тогда, если у вас миллион пользователей, этот список будет состоять из миллиона строк. И для каждого пользователя будет запись с указанием адреса пользователя. И каков его баланс. И затем разработка таких контрактов довольно проста. У вас есть атомарные транзакции, вы вычитаете из одного баланса и добавляете к другому. И очень легко спроектировать и посмотреть, как будет работать система. Однако эта модель не будет масштабироваться в тоннах, потому что вы поместили бы этот длинный список в один контракт и сразу же столкнулись бы с проблемами.
1️⃣ Во-первых, у вас будет постепенно растущая стоимость аренды для всех этих данных, которые вы храните в своем контракте. 💸
2️⃣ Во-вторых, каждый раз, когда пользователь приходит и хочет совершить операцию с этим контрактом, ему придется платить все большую и большую комиссию за транзакцию, потому что он будет оперировать все большим объемом данных в контракте. 🌄
Правила.
Чтобы помочь вам, дам руководство о том, как правильно проектировать многопользовательские и крупномасштабные приложения, и, кроме того, есть несколько правил. 📰
❗️ Избегайте использования данных переменной длины.
❗️ Если вам нужен список, то, по крайней мере, сделайте его коротким и ограниченным, например, статически определенным.
❗️ Если вам нужен список, и он должен динамически увеличиваться, то, по крайней мере, убедитесь, что этот контракт принадлежит одному пользователю и у него есть исключительное право контролировать его хранение. Простым примером являются записи в элементах TON DNS.
Блокчейн в виде массива.
Масштабируемый способ создания больших списков или словарей данных в TON - использовать сам блокчейн в качестве массива. Вот простой пример.
Вы могли бы представить систему, в которой у вас есть несколько контрактов, которые связаны друг с другом, и каждый пользователь заботится о своем собственном индивидуальном контракте. И вам не нужно хранить весь список в центральной части приложения.
TON гарантирует, что он может масштабироваться до уровня детализации отдельных контрактов.
Контракты монолитного кошелька из Ethereum на блокчейне TON должны быть реализованы по-другому ради скорости, масштабируемости и экономии газа.
Избегайте использования данных переменной длины в качестве первоочередной задачи.
Если вам нужен список, то, по крайней мере, сделайте его коротким и ограниченным, например, статически определенным.
Доменное имя TON DNS - это коллекционный несменяемый токен, с которым может быть связано произвольное количество дополнительных записей.
Масштабируемый способ создания больших списков или словарей данных в TON заключается в использовании самого блокчейна в качестве массива.
Токены в TON спроектированы таким образом, что существует единый контракт minter, но в этом контракте не хранится список всех его пользователей. Вместо этого ему разрешено чеканить и создавать токены для других пользователей, а балансы отдельных пользователей распределяются по так называемым кошелькам Jettons.
📚Конспекты лекции
Давайте поговорим о масштабируемости.
💎 В TON у вас действительно есть очень конкретная гарантия масштабируемости. TON гарантирует вам, что он может масштабироваться до уровня детализации отдельных контрактов.
Таким образом, операции с одним контрактом не создадут узкого места 🍼 для операций с другим контрактом. И тогда сеть TON, очевидно, позаботится обо всей маршрутизации сообщений 🚅 между ними.
❗️ Ваша задача - использовать преимущества всей масштабируемости блокчейна и не создавать узких мест в ваших собственных контрактах!
Проблемы с монолитными контрактами.
Одна из очевидных проблем для людей, использующих традиционные системы, крупномасштабные веб-базы данных или Ethereum, заключается в том, что они разрабатывают свои контракты как монолитные приложения со своим собственным хранилищем переменной длины.
🌐 Например, в Ethereum токен реализован в виде банковской книги, где у вас есть единый смарт-контракт, содержащий список учетных записей. И тогда, если у вас миллион пользователей, этот список будет состоять из миллиона строк. И для каждого пользователя будет запись с указанием адреса пользователя. И каков его баланс. И затем разработка таких контрактов довольно проста. У вас есть атомарные транзакции, вы вычитаете из одного баланса и добавляете к другому. И очень легко спроектировать и посмотреть, как будет работать система. Однако эта модель не будет масштабироваться в тоннах, потому что вы поместили бы этот длинный список в один контракт и сразу же столкнулись бы с проблемами.
1️⃣ Во-первых, у вас будет постепенно растущая стоимость аренды для всех этих данных, которые вы храните в своем контракте. 💸
2️⃣ Во-вторых, каждый раз, когда пользователь приходит и хочет совершить операцию с этим контрактом, ему придется платить все большую и большую комиссию за транзакцию, потому что он будет оперировать все большим объемом данных в контракте. 🌄
Правила.
Чтобы помочь вам, дам руководство о том, как правильно проектировать многопользовательские и крупномасштабные приложения, и, кроме того, есть несколько правил. 📰
❗️ Избегайте использования данных переменной длины.
❗️ Если вам нужен список, то, по крайней мере, сделайте его коротким и ограниченным, например, статически определенным.
❗️ Если вам нужен список, и он должен динамически увеличиваться, то, по крайней мере, убедитесь, что этот контракт принадлежит одному пользователю и у него есть исключительное право контролировать его хранение. Простым примером являются записи в элементах TON DNS.
Блокчейн в виде массива.
Масштабируемый способ создания больших списков или словарей данных в TON - использовать сам блокчейн в качестве массива. Вот простой пример.
Вы могли бы представить систему, в которой у вас есть несколько контрактов, которые связаны друг с другом, и каждый пользователь заботится о своем собственном индивидуальном контракте. И вам не нужно хранить весь список в центральной части приложения.
👍2
💎 Наиболее популярным примером реализации этой идеи является дизайн токенов в экосистеме TON. Балансы отдельных пользователей распределены по так называемым кошелькам Jetton. 🔥 Что в этом круто, так это то, что операции между двумя кошельками Jeton в одном месте не мешают операциям двух других в каком-либо другом месте, и они могут быть распределены по отдельным цепочкам блоков и не создавать никаких узких мест.
2.6 Обзор классических бизнес-задач
📝 Вы также узнаете о:
В каких ситуациях мы могли бы применить наши принципы разработки масштабируемых контрактов?
📝 Вы также узнаете о:
В каких ситуациях мы могли бы применить наши принципы разработки масштабируемых контрактов?
📝 Теперь вы знаете:
В TON токены реализованы в виде отдельных контрактов. По одному контракту на пользователя плюс отдельный контракт minter, который предоставляет интерфейс для создания новых единиц токена.
📚 Примечания к лекции
Здесь мы рассмотрим три примера, чтобы увидеть, как принципы разработки контрактов применяются к различным приложениям и как платформа TON помогает вам создавать масштабируемые и безопасные приложения.
Жетоны.
В реализациях Ethereum или даже без блокчейна токены были бы реализованы как простая бухгалтерская книга счетов.
У вас есть список, программа управляет этим списком учетных записей, и каждый элемент в списке фактически является адресом участника и его балансом. Это довольно просто, но, к сожалению, не масштабируется в контексте блокчейна, потому что ваш смарт-контракт должен постоянно расти вместе с количеством пользователей и становится более дорогим для взаимодействия с каждым пользователем.
❓ Что такое подход TON?
В TON токены реализованы в виде отдельных контрактов. Один контракт на пользователя плюс отдельный контракт minter, который предоставляет интерфейс для создания новых единиц токена.
Контракты для каждого пользователя называются кошельками Jetton, и задача этих кошельков Jetton заключается в хранении баланса токена для каждого отдельного пользователя. Всякий раз, когда пользователь хочет перевести токен с одной учетной записи на другую 💸 , он сначала отправляет внешнее сообщение на свой кошелек, затем этот кошелек разворачивает это внешнее сообщение и отправляет через внутреннее сообщение на кошелек Jetton этого пользователя со словами "Пожалуйста, отправьте деньги на определенный адрес". Затем Jetton wallet уменьшает их баланс на необходимую сумму и отправляет сообщение своему родственному контракту, который имеет точно такой же код, но другого владельца, и в этом сообщении говорится: "Пожалуйста, увеличьте свой баланс на ту же сумму.
🍞 Здесь используется проверка ДНК, потому что код Jettons одинаков.
Контракт с несколькими подписями.
📖 Концепция контракта с несколькими подписями иллюстрируется в контексте TON, где несколько сторон коллективно санкционируют действия, маркируя запросы, инициированные пользователем.
Вместо прямой обработки сообщений пользователи получают уникальные токены, инкапсулирующие их запросы и голоса. Эти токены, принадлежащие пользователям, упрощают отслеживание и предотвращают нарушение контракта злоумышленниками. Честные пользователи собирают голоса за токены временного запроса, и как только порог достигнут, контракт с несколькими подписями выполняет действие после проверки подлинности запроса. Эта токенизация упрощает процесс и фокусируется на временном состоянии системы, а не на долях или значениях отдельных контрактов.
Платежи по подписке.
👀 Начиная с версии 4 кошелька, кошельки поддерживают плагины, которые позволяют пользователям создавать платежи по подписке.
Это очень мощная функция, и она относительно хорошо масштабируется, потому что пользователь контролирует этот список плагинов. Но мы могли бы придумать лучший способ сделать это.
🔥 Классная идея заключается в том, что вместо перечисления адресов конкретных плагинов вы могли бы перечислить различные реализации кода этих плагинов. И если они используют один и тот же код, для любого количества подключаемых плагинов, которые у вас есть, будет только одна запись.
В TON токены реализованы в виде отдельных контрактов. По одному контракту на пользователя плюс отдельный контракт minter, который предоставляет интерфейс для создания новых единиц токена.
📚 Примечания к лекции
Здесь мы рассмотрим три примера, чтобы увидеть, как принципы разработки контрактов применяются к различным приложениям и как платформа TON помогает вам создавать масштабируемые и безопасные приложения.
Жетоны.
В реализациях Ethereum или даже без блокчейна токены были бы реализованы как простая бухгалтерская книга счетов.
У вас есть список, программа управляет этим списком учетных записей, и каждый элемент в списке фактически является адресом участника и его балансом. Это довольно просто, но, к сожалению, не масштабируется в контексте блокчейна, потому что ваш смарт-контракт должен постоянно расти вместе с количеством пользователей и становится более дорогим для взаимодействия с каждым пользователем.
❓ Что такое подход TON?
В TON токены реализованы в виде отдельных контрактов. Один контракт на пользователя плюс отдельный контракт minter, который предоставляет интерфейс для создания новых единиц токена.
Контракты для каждого пользователя называются кошельками Jetton, и задача этих кошельков Jetton заключается в хранении баланса токена для каждого отдельного пользователя. Всякий раз, когда пользователь хочет перевести токен с одной учетной записи на другую 💸 , он сначала отправляет внешнее сообщение на свой кошелек, затем этот кошелек разворачивает это внешнее сообщение и отправляет через внутреннее сообщение на кошелек Jetton этого пользователя со словами "Пожалуйста, отправьте деньги на определенный адрес". Затем Jetton wallet уменьшает их баланс на необходимую сумму и отправляет сообщение своему родственному контракту, который имеет точно такой же код, но другого владельца, и в этом сообщении говорится: "Пожалуйста, увеличьте свой баланс на ту же сумму.
🍞 Здесь используется проверка ДНК, потому что код Jettons одинаков.
Контракт с несколькими подписями.
📖 Концепция контракта с несколькими подписями иллюстрируется в контексте TON, где несколько сторон коллективно санкционируют действия, маркируя запросы, инициированные пользователем.
Вместо прямой обработки сообщений пользователи получают уникальные токены, инкапсулирующие их запросы и голоса. Эти токены, принадлежащие пользователям, упрощают отслеживание и предотвращают нарушение контракта злоумышленниками. Честные пользователи собирают голоса за токены временного запроса, и как только порог достигнут, контракт с несколькими подписями выполняет действие после проверки подлинности запроса. Эта токенизация упрощает процесс и фокусируется на временном состоянии системы, а не на долях или значениях отдельных контрактов.
Платежи по подписке.
👀 Начиная с версии 4 кошелька, кошельки поддерживают плагины, которые позволяют пользователям создавать платежи по подписке.
Это очень мощная функция, и она относительно хорошо масштабируется, потому что пользователь контролирует этот список плагинов. Но мы могли бы придумать лучший способ сделать это.
🔥 Классная идея заключается в том, что вместо перечисления адресов конкретных плагинов вы могли бы перечислить различные реализации кода этих плагинов. И если они используют один и тот же код, для любого количества подключаемых плагинов, которые у вас есть, будет только одна запись.
🤯4
Please open Telegram to view this post
VIEW IN TELEGRAM
❤2👍1🔥1🤯1👀1
3. Жизненный цикл разработки смарт-контрактов
💎 Добро пожаловать в 3-ю главу.
В этой главе в целом мы рассмотрим различные аспекты разработки смарт-контрактов. Мы начнем с разбивки всего цикла разработки смарт-контрактов. Это будет включать в себя создание локального проекта, который может скомпилировать образец смарт-контракта. Кроме того, мы рассмотрим написание функционального кода и обеспечение того, чтобы код нашего контракта функционировал должным образом. Мы углубимся в создание пользовательского сценария развертывания, чтобы получить более глубокое представление о лежащей в его основе логике. Наконец, мы сосредоточимся на повышении гибкости нашего процесса развертывания. Благодаря этим 6 урокам мы приобретем всесторонние знания и навыки в области разработки смарт-контрактов.
💎 Добро пожаловать в 3-ю главу.
В этой главе в целом мы рассмотрим различные аспекты разработки смарт-контрактов. Мы начнем с разбивки всего цикла разработки смарт-контрактов. Это будет включать в себя создание локального проекта, который может скомпилировать образец смарт-контракта. Кроме того, мы рассмотрим написание функционального кода и обеспечение того, чтобы код нашего контракта функционировал должным образом. Мы углубимся в создание пользовательского сценария развертывания, чтобы получить более глубокое представление о лежащей в его основе логике. Наконец, мы сосредоточимся на повышении гибкости нашего процесса развертывания. Благодаря этим 6 урокам мы приобретем всесторонние знания и навыки в области разработки смарт-контрактов.
👨💻1
📝 Вы также узнаете о:
Какие этапы включает цикл разработки смарт-контрактов в TON?
Как называется язык программирования для смарт-контрактов в блокчейне TON?
Существуют ли какие-либо стандартные локальные среды настройки для написания, тестирования и развертывания смарт-контрактов?
Какие этапы включает цикл разработки смарт-контрактов в TON?
Как называется язык программирования для смарт-контрактов в блокчейне TON?
Существуют ли какие-либо стандартные локальные среды настройки для написания, тестирования и развертывания смарт-контрактов?
📝 Теперь вы знаете:
Мы могли бы представить контракт TON как спутник, который запускается на орбиту Земли, и спутник летает вокруг Земли, взаимодействуя с другими спутниками, он способен принимать информацию с Земли, обрабатывать ее и отправлять некоторые результаты. Но прежде чем мы действительно запустим его в космос, он должен пройти несколько этапов.
На первом этапе мы готовим нашу локальную установку, которая позволит нам внедрять наш спутниковый смарт-контракт на всех последующих этапах.
Фактический смарт-контракт на блокчейне TON хранится и выполняется в виде двоичного кода.
На втором этапе мы описываем команды, которые способен обрабатывать наш смарт-контракт.
На третьем этапе мы просто пишем наш функциональный код.
На четвертом этапе мы тестируем поведение нашего функционального кода локально.
На пятом этапе мы развертываем наш контракт в testnet.
📚Конспекты лекций
Вступление к главе 3
В этой главе мы будем очень практичны и фактически разберем весь цикл разработки смарт-контрактов TON, пройдем каждый его шаг вместе, и конечным результатом будет готовая пользовательская локальная настройка для программирования smartcontract, написанный функциональный код контракта, тесты для нашего контракта фактически развернутый контракт.
Давайте сразу перейдем к делу.
TON smartcontract подобен спутнику.
Лучшая аллегория, которую я смог придумать, чтобы объяснить жизненный цикл смарт-контракта TON, заключается в следующем. Вы можете представить, что смарт-контракт TON - это спутник, который запускается на орбиту Земли.
Спутник летает вокруг Земли, взаимодействует с другими спутниками, способен принимать информацию с Земли, обрабатывать ее и отправлять некоторые результаты. Но прежде чем мы действительно запустим его в космос, он должен пройти несколько этапов.
Есть базовая лаборатория, где он собирается. [Локальная настройка]
Существует определенный документированный протокол, который определяет все возможные команды, которые могут быть обработаны нашим спутником. [Схема TLB]
Каждый из сценариев поведения тестируется, пока спутник еще находится в лаборатории. [Локальные тесты]
После этого он помещается в имитируемую среду, очень похожую на ту, что ожидает его в космосе, это позволяет еще раз протестировать ожидаемое поведение в ответ на предопределенные команды, а также взаимодействие с другими объектами в космосе и на Земле. [Тесты Testnet и onchain после развертывания]
Как мы доставим спутник на орбиту? С помощью ракет. Ракеты выводят спутник на орбиту и оставляют его там, отваливаясь после успешного завершения своей миссии. [Развертывание производства Mainnet]
С этого момента спутник находится сам по себе в Космосе, работая со всем, что у него запрограммировано внутри.
Объясняю, как жизненный цикл разработки смарт-контракта TON соотносится с примером sattelite.
Когда мы пишем смарт-контракт, мы используем аналогичный цикл.
1. Мы готовим нашу локальную настройку, которая позволит нам провести наш спутниковый / смарт-контракт через все этапы, упомянутые выше.
Первой ключевой частью нашей локальной настройки будет компилятор. Фактический смарт-контракт в блокчейне TON хранится и выполняется в виде двоичного кода. Но мы хотим запрограммировать логику с помощью чего-то понятного человеку, поэтому язык, который мы используем для программирования контракта TON, - это FunC.
Путь между FunC и байт-кодом следующий: FunC компилируется в ассемблерный код Fift, который генерирует соответствующий байт-код для виртуальной машины TON (пробел, если мы ссылаемся на наш вспомогательный пример).
Для нас суть ассемблерного кода Fift не очень важна, и мы будем рассматривать его просто как скрытое промежуточное состояние нашего кода smartcontract. Мы передаем это нашему компилятору.
Наш код -> FunC -> Fift -> BOC (байт-код)
Я полагаю, что часть, объясняющая, как хранится и выполняется байт-код, должна быть объяснена в главах 1 и 2 (дерево ячеек и т.д.)
Мы могли бы представить контракт TON как спутник, который запускается на орбиту Земли, и спутник летает вокруг Земли, взаимодействуя с другими спутниками, он способен принимать информацию с Земли, обрабатывать ее и отправлять некоторые результаты. Но прежде чем мы действительно запустим его в космос, он должен пройти несколько этапов.
На первом этапе мы готовим нашу локальную установку, которая позволит нам внедрять наш спутниковый смарт-контракт на всех последующих этапах.
Фактический смарт-контракт на блокчейне TON хранится и выполняется в виде двоичного кода.
На втором этапе мы описываем команды, которые способен обрабатывать наш смарт-контракт.
На третьем этапе мы просто пишем наш функциональный код.
На четвертом этапе мы тестируем поведение нашего функционального кода локально.
На пятом этапе мы развертываем наш контракт в testnet.
📚Конспекты лекций
Вступление к главе 3
В этой главе мы будем очень практичны и фактически разберем весь цикл разработки смарт-контрактов TON, пройдем каждый его шаг вместе, и конечным результатом будет готовая пользовательская локальная настройка для программирования smartcontract, написанный функциональный код контракта, тесты для нашего контракта фактически развернутый контракт.
Давайте сразу перейдем к делу.
TON smartcontract подобен спутнику.
Лучшая аллегория, которую я смог придумать, чтобы объяснить жизненный цикл смарт-контракта TON, заключается в следующем. Вы можете представить, что смарт-контракт TON - это спутник, который запускается на орбиту Земли.
Спутник летает вокруг Земли, взаимодействует с другими спутниками, способен принимать информацию с Земли, обрабатывать ее и отправлять некоторые результаты. Но прежде чем мы действительно запустим его в космос, он должен пройти несколько этапов.
Есть базовая лаборатория, где он собирается. [Локальная настройка]
Существует определенный документированный протокол, который определяет все возможные команды, которые могут быть обработаны нашим спутником. [Схема TLB]
Каждый из сценариев поведения тестируется, пока спутник еще находится в лаборатории. [Локальные тесты]
После этого он помещается в имитируемую среду, очень похожую на ту, что ожидает его в космосе, это позволяет еще раз протестировать ожидаемое поведение в ответ на предопределенные команды, а также взаимодействие с другими объектами в космосе и на Земле. [Тесты Testnet и onchain после развертывания]
Как мы доставим спутник на орбиту? С помощью ракет. Ракеты выводят спутник на орбиту и оставляют его там, отваливаясь после успешного завершения своей миссии. [Развертывание производства Mainnet]
С этого момента спутник находится сам по себе в Космосе, работая со всем, что у него запрограммировано внутри.
Объясняю, как жизненный цикл разработки смарт-контракта TON соотносится с примером sattelite.
Когда мы пишем смарт-контракт, мы используем аналогичный цикл.
1. Мы готовим нашу локальную настройку, которая позволит нам провести наш спутниковый / смарт-контракт через все этапы, упомянутые выше.
Первой ключевой частью нашей локальной настройки будет компилятор. Фактический смарт-контракт в блокчейне TON хранится и выполняется в виде двоичного кода. Но мы хотим запрограммировать логику с помощью чего-то понятного человеку, поэтому язык, который мы используем для программирования контракта TON, - это FunC.
Путь между FunC и байт-кодом следующий: FunC компилируется в ассемблерный код Fift, который генерирует соответствующий байт-код для виртуальной машины TON (пробел, если мы ссылаемся на наш вспомогательный пример).
Для нас суть ассемблерного кода Fift не очень важна, и мы будем рассматривать его просто как скрытое промежуточное состояние нашего кода smartcontract. Мы передаем это нашему компилятору.
Наш код -> FunC -> Fift -> BOC (байт-код)
Я полагаю, что часть, объясняющая, как хранится и выполняется байт-код, должна быть объяснена в главах 1 и 2 (дерево ячеек и т.д.)
🤯1
На данный момент лучшим и распространенным способом работы с компилятором является использование языка TypeScript. Машинопись не имеет ничего общего с TVM. Думайте об этом как о чем-то, что остается на Земле после запуска спутника.
Компилятор, который мы собираемся использовать, - это @ton-community/func-js. Внутренне этот пакет использует как компилятор FunC, так и интерпретатор Fift, объединенный в единую библиотеку, скомпилированную в WebAssembly (WASM).
2. Мы используем схему TL-B для описания команд, которые способен обрабатывать наш smartcontract
TL-B (язык типов - двоичный) служит для описания системы типов, конструкторов и существующих функций. Вот пример возможного документа TL-B:
альтернативный текст для чтения с экрана
Обычно мы пишем наш документ TL-B, как только некоторые базовые функции готовы, а затем продолжаем обновлять его до запуска контракта. Мы собираемся приблизиться к этому, как только напишем наш первый функциональный код.
3. Самая приятная часть. Мы пишем функциональный код.
FunC - это специфичный для предметной области, подобный C, статически типизированный язык. Вы уже видели некоторый функциональный код в первых двух главах. Однако в этом уроке мы собираемся на самом деле написать некоторую логику с помощью функционального кода.
4. Мы тестируем поведение нашего функционального кода локально.
Затем мы снова используем TypeScript для написания тестовой логики. На этом шаге мы локально моделируем TVM-машину, отправляем данные в смоделированный контракт, анализируем выходные данные и повторяем это до тех пор, пока не получим желаемые результаты. Как только все будет готово к развертыванию - мы пишем машинописный код, который фактически развернет наш смарт-контракт в блокчейне. Это наши ракеты.
5. Мы развертываем наш код в testnet.
Процесс развертывания смарт-контрактов в TON очень интересен. Что делает его таким интересным? Как вы могли видеть из предыдущих уроков - мы можем рассчитать адрес, который будет иметь смарт-контракт, еще до того, как мы развернем его в сети. Чтобы сделать это, все, что нам нужно, это знать начальное состояние данных для контракта и его фактический код. Как только мы узнаем адрес - мы отправляем сообщение с начальным состоянием и кодом на этот адрес. Это просто. Это может быть внутреннее сообщение или внешнее сообщение.
Таким образом, наш сценарий развертывания был бы таким же простым, как вычисление адреса и отправка сообщения с начальным состоянием и кодом на этот адрес.
Возможно, вы заметили, что при отправке сообщения нам приходится тратить реальные деньги, поэтому мы не хотим тратить много реальных денег при развертывании и тестировании нашего контракта в сети.
Вот почему у нас есть копия реальной сети, которую я использовал только в тестовых целях. Вы можете бесплатно получать монеты, которые действительны в этой сети, и мы называем эту сеть testnet. Прежде чем наш контракт будет полностью готов к производству - мы только развернем его в тестовой сети.
6. Запуск. Мы развертываем наш код в mainnet.
Развертывание smartcontract в основной сети практически такое же, как и в тестовой сети, но мы развертываем наш контракт, отправляя сообщения с реальными монетами TON, наши сообщения попадают в основной блокчейн, и наш контракт доступен для всех пользователей TON.
Это очень интересный процесс. Иногда трудно найти ответы, но я призываю вас не сдаваться, и на протяжении всей этой главы я позабочусь о том, чтобы у вас:
Компилятор, который мы собираемся использовать, - это @ton-community/func-js. Внутренне этот пакет использует как компилятор FunC, так и интерпретатор Fift, объединенный в единую библиотеку, скомпилированную в WebAssembly (WASM).
2. Мы используем схему TL-B для описания команд, которые способен обрабатывать наш smartcontract
TL-B (язык типов - двоичный) служит для описания системы типов, конструкторов и существующих функций. Вот пример возможного документа TL-B:
альтернативный текст для чтения с экрана
Обычно мы пишем наш документ TL-B, как только некоторые базовые функции готовы, а затем продолжаем обновлять его до запуска контракта. Мы собираемся приблизиться к этому, как только напишем наш первый функциональный код.
3. Самая приятная часть. Мы пишем функциональный код.
FunC - это специфичный для предметной области, подобный C, статически типизированный язык. Вы уже видели некоторый функциональный код в первых двух главах. Однако в этом уроке мы собираемся на самом деле написать некоторую логику с помощью функционального кода.
4. Мы тестируем поведение нашего функционального кода локально.
Затем мы снова используем TypeScript для написания тестовой логики. На этом шаге мы локально моделируем TVM-машину, отправляем данные в смоделированный контракт, анализируем выходные данные и повторяем это до тех пор, пока не получим желаемые результаты. Как только все будет готово к развертыванию - мы пишем машинописный код, который фактически развернет наш смарт-контракт в блокчейне. Это наши ракеты.
5. Мы развертываем наш код в testnet.
Процесс развертывания смарт-контрактов в TON очень интересен. Что делает его таким интересным? Как вы могли видеть из предыдущих уроков - мы можем рассчитать адрес, который будет иметь смарт-контракт, еще до того, как мы развернем его в сети. Чтобы сделать это, все, что нам нужно, это знать начальное состояние данных для контракта и его фактический код. Как только мы узнаем адрес - мы отправляем сообщение с начальным состоянием и кодом на этот адрес. Это просто. Это может быть внутреннее сообщение или внешнее сообщение.
Таким образом, наш сценарий развертывания был бы таким же простым, как вычисление адреса и отправка сообщения с начальным состоянием и кодом на этот адрес.
Возможно, вы заметили, что при отправке сообщения нам приходится тратить реальные деньги, поэтому мы не хотим тратить много реальных денег при развертывании и тестировании нашего контракта в сети.
Вот почему у нас есть копия реальной сети, которую я использовал только в тестовых целях. Вы можете бесплатно получать монеты, которые действительны в этой сети, и мы называем эту сеть testnet. Прежде чем наш контракт будет полностью готов к производству - мы только развернем его в тестовой сети.
6. Запуск. Мы развертываем наш код в mainnet.
Развертывание smartcontract в основной сети практически такое же, как и в тестовой сети, но мы развертываем наш контракт, отправляя сообщения с реальными монетами TON, наши сообщения попадают в основной блокчейн, и наш контракт доступен для всех пользователей TON.
Это очень интересный процесс. Иногда трудно найти ответы, но я призываю вас не сдаваться, и на протяжении всей этой главы я позабочусь о том, чтобы у вас:
Была своя локальная "лаборатория" полного цикла для создания и "запуска" ваших смарт-контрактов
Вы поймете основы кодирования функционального контракта
Вы знаете, где искать ответы, если ваш контракт требует большего, чем мы рассмотрим в примерах
Существуют ли какие-либо стандартные локальные настройки (среды) для написания, тестирования и развертывания смарт-контрактов?
Это хороший вопрос. У TON быстро растущий набор инструментов программирования, и иногда нет смысла создавать свою собственную локальную установку. Стоит упомянуть замечательную программу, которая поддерживается командой TonTech и официально поддерживается TON Foundation - Blueprint.
Вы можете использовать его так же просто, как выполнить локальную команду:
npm create ton@latest
Это создаст для вас новый проект с кодом для всех этапов, описанных выше. Вы можете прочитать больше об этом в документации Bluprint.
В рамках этого курса мы по-прежнему собираемся создать пользовательский, чтобы вы могли глубже понять, как весь этот процесс работает под капотом.
Давайте сделаем это!
Вы поймете основы кодирования функционального контракта
Вы знаете, где искать ответы, если ваш контракт требует большего, чем мы рассмотрим в примерах
Существуют ли какие-либо стандартные локальные настройки (среды) для написания, тестирования и развертывания смарт-контрактов?
Это хороший вопрос. У TON быстро растущий набор инструментов программирования, и иногда нет смысла создавать свою собственную локальную установку. Стоит упомянуть замечательную программу, которая поддерживается командой TonTech и официально поддерживается TON Foundation - Blueprint.
Вы можете использовать его так же просто, как выполнить локальную команду:
npm create ton@latest
Это создаст для вас новый проект с кодом для всех этапов, описанных выше. Вы можете прочитать больше об этом в документации Bluprint.
В рамках этого курса мы по-прежнему собираемся создать пользовательский, чтобы вы могли глубже понять, как весь этот процесс работает под капотом.
Давайте сделаем это!
❤1