Когда мне следует создавать модуль времени выполнения субстрата по сравнению с интеллектуальным контрактом субстрата?
Каковы различия между разработкой модуля времени выполнения субстрата и смарт-контракта субстрата (например, с языком чернил!)?
Какие примеры приложений лучше всего написать в той или иной форме?
1 ответ
Модули Substrate Runtime и Substrate Smart Contracts - это две совершенно разные платформы для создания "децентрализованных приложений". Здесь, возможно, есть лучший термин, но ради этого поста я подразумеваю, что сами блокчейны являются децентрализованными приложениями, в дополнение к умным контрактам.
Смарт Контракты
Традиционная платформа интеллектуальных контрактов позволяет пользователям публиковать дополнительную логику поверх некоторой базовой логики блокчейна, которая в субстрате называется средой выполнения. Поскольку этот код может быть опубликован кем угодно, включая злоумышленников и неопытных разработчиков, существует ряд преднамеренных мер безопасности, построенных на платформе смарт-контрактов. Вот некоторые примеры:
- Сборы: Обеспечение того, что разработчики контракта взимают плату за вычисления и хранилище, которые они навязывают на компьютерах, на которых выполняется их контракт, и не допускается злоупотребление создателями блока.
- Песочница: Контракт не может изменять базовое хранилище времени выполнения или хранилище других контрактов напрямую. Его мощность ограничена только изменением его собственного состояния и возможностью совершать внешние вызовы для других контрактов или функций времени выполнения.
- Налоги: контракт занимает место на блокчейне, и, следовательно, должен взиматься плата за просто существующий. Это гарантирует, что люди не смогут воспользоваться "бесплатным неограниченным хранилищем".
- Возврат: контракт может быть подвержен ситуациям, которые приводят к логическим ошибкам. Ожидания разработчика контракта невелики, поэтому добавляются дополнительные накладные расходы для поддержки возврата транзакций при сбое, поэтому состояние не обновляется, когда что-то идет не так.
Эти различные накладные расходы делают выполнение контрактов более медленным и более дорогостоящим, но, опять же, "целевая аудитория" для разработки контрактов отличается от разработчиков времени выполнения.
Контракты могут позволить вашему сообществу расширяться и развиваться на основе вашей логики времени выполнения без необходимости проходить через все сумасшедшие предложения, обновления времени выполнения и т. Д. Это может даже использоваться как основание для тестирования будущих изменений времени выполнения, но сделано в способ, который изолирует вашу сеть от любых проблем роста или ошибок, которые могут произойти.
Таким образом, субстрат смарт-контрактов:
- По своей природе безопаснее для сети.
- Внедрили экономические стимулы против злоупотреблений.
- Иметь вычислительные накладные расходы для поддержки изящных сбоев в логике.
- Имейте более низкую планку для входа для развития.
- Обеспечьте быстрое взаимодействие с сообществом через игровую площадку, чтобы написать новую логику.
Модули времени выполнения
Модули времени выполнения, с другой стороны, не предоставляют ни одну из этих защит или защитных мер, которые предоставляет вам Smart Contracts. Как разработчик во время выполнения, панель ввода кода, который вы создаете, поднимается вверх.
У вас есть полный контроль над базовой логикой, которую будет выполнять каждый узел в вашей сети. У вас есть полный доступ ко всем элементам хранилища во всех ваших модулях, которые вы можете изменять и контролировать. Вы даже можете зацепить свою цепочку неправильной логикой или плохой обработкой ошибок.
Разработка Substrate Runtime Module направлена на создание экономичных, высокопроизводительных и быстрых узлов. Он не предоставляет никакой защиты или накладных расходов при возврате транзакции, и не подразумевает, что система вычислений, которую выполняют узлы в вашей цепочке, не вводит никакой платы. Это означает, что при разработке функций времени выполнения вы должны правильно оценивать и применять сборы к различным частям вашей логики времени выполнения, чтобы она не использовалась плохими участниками и не вредила вашей сети.
Таким образом, модули времени выполнения субстрата:
- Обеспечить низкоуровневый доступ ко всей цепочке блоков.
- Убрали накладные расходы на встроенную безопасность для производительности.
- Иметь высокую планку для входа для разработчиков.
- Не обязательно писать рабочий код, но избегать написания неработающего кода.
- Не имеет врожденных экономических стимулов для отражения плохих актеров.
Правильный инструмент для вас
Модули Substrate Runtime и Smart Contracts - это инструменты, доступные вам для решения проблем.
Вероятно, существует некоторое совпадение в типах проблем, которые может решить каждая, но есть также четкий набор проблем, подходящих только для одной из двух задач. Два дают только один пример в каждой категории:
- Runtime Module: создание слоя конфиденциальности поверх транзакций в вашей цепочке блоков.
- Совместное использование: создание DApp, подобного Cryptokitties, для которого может потребоваться создание сообщества пользователей (склонность к Smart Contract) или может потребоваться масштабирование до миллионов транзакций в день (склонение к Runtime Module).
- Смарт-контракт: введение токенов 2-го уровня и пользовательских ресурсов в вашу сеть.
В дополнение ко всему, что написано выше, вам также необходимо учитывать затраты на настройку DApp с использованием определенного инструмента. Развертывание контракта - это относительно простой и легкий процесс, поскольку вы используете преимущества существующей сети. Единственными расходами для вас являются те сборы, которые вы платите за развертывание и поддержание вашего контракта.
С другой стороны, создание собственной блокчейна требует затрат для создания сообщества, которое будет ценить ваши услуги, или создания частной сети с накладными расходами на систему облачных вычислений и общее обслуживание сети.
Я думаю, что сейчас это действительно первый случай, когда стало так легко и доступно построить логику времени выполнения. В прошлом каждый создавал свою "идею децентрализованного приложения", используя доступный им инструмент, Smart Contracts, даже когда это был не лучший инструмент для работы.
С введением Substrate появился новый инструмент для создания ваших децентрализованных приложений; но опять же, было бы неправильно думать, что все ваши идеи должны быть модулем времени выполнения субстрата.
Вместо этого, впервые как сообщество, у нас есть два инструмента, и нам нужно вместе выяснить, какой из них лучше использовать для каждого сценария. Я не думаю, что все ответы на это существуют сегодня, но мы можем учиться и делать некоторые образованные предположения по пути.