Модульные блокчейны: отслеживание выполнения, данных и расчетов
Модульный блокчейн разделяет обязанности между компонентами, а не требует, чтобы одна система выполняла каждую задачу. Из-за этого описание сети может показаться простым: исполнение происходит здесь, данные передаются туда, а расчет происходит где-то еще. Важный вопрос заключается в том, что на самом деле гарантирует каждый компонент.
В этой статье сравниваются архитектурные роли, а не символические цены или рейтинг проектов. Модульная конструкция не означает автоматически меньший риск, более высокую отдачу от инвестиций или одинаковую безопасность во всех реализациях.
Разделяйте задачи перед сравнением систем
Исполнение применяет правила транзакции и вычисляет предлагаемое изменение состояния. Доступность данных касается того, была ли доступна информация, необходимая для проверки системы. Урегулирование касается того, как криптографические обязательства о состоянии цепочки (state commitments), доказательства или споры принимаются в соответствии с конкретным протоколом. Консенсус определяет согласованный порядок или принятую историю внутри системы.
Эти роли могут перекрываться или распределяться по-разному. Меток проекта недостаточно: сеть может называть себя модульной, сохраняя при этом значительный контроль над секвенсором, ключом обновления или комитетом данных. Нарисуйте фактическую карту зависимостей, а не предполагайте, что все модульные сети имеют одну модель доверия.
Документация по доступности данных Ethereum объясняет, почему проверка зависит от доступа к данным транзакций и почему легким клиентам и накопительным пакетам необходимы соответствующие гарантии. Доступ к данным — это вопрос, отличный от того, правильно ли выполненное вычисление.
Следовать за гипотетической транзакцией
Представьте, что пользователь отправляет транзакцию в сеть исполнения. Секвенсор включает его в пакет. Система делает необходимые данные доступными, используя выбранный ею уровень данных, и передает криптографическое обязательство о состоянии цепочки (state commitment) с механизмом проверки, требуемым ее конструкцией, на уровень расчетов.
Пользователь может увидеть раннее подтверждение до того, как каждый этап достигнет своего окончательного статуса. Запишите, что означает каждый статус: получено, упорядочено, исполнено, данные опубликованы, подтверждение принято или окно спора завершено. Не называйте самое раннее подтверждение окончательным расчетом, если только протокол не поддерживает такую интерпретацию.
Этот пример описывает роли, а не предписывает одну универсальную последовательность. Различные объединения и модульные системы могут объединять этапы или использовать разные механизмы проверки и окончательности.
Спросите, что происходит, когда компонент выходит из строя
Если секвенсор останавливается, могут ли пользователи отправлять транзакции другим способом и при каких условиях? Если служба данных скрывает информацию, кто ее обнаруживает и что могут проверить пользователи? Если уровень расчетов перегружен, как это повлияет на обязательства или снятие средств?
Ответьте на эти вопросы, используя текущую документацию, включая аварийные процедуры и административный контроль. Резервный вариант, описанный в дорожной карте, не обязательно работоспособен. Сеть, которая продолжает отображать балансы, может по-прежнему иметь ограниченную возможность принимать транзакции или осуществлять снятие средств.
Просмотрите зависимости моста отдельно. Токен, появляющийся в двух сетях, не означает, что маршрут передачи наследует все свойства безопасности обеих цепочек.
Сравните полную стоимость и удобство использования
Низкая комиссия за исполнение — это лишь часть стоимости транзакции. Операции публикации данных, расчетов, соединения и вывода средств могут привести к увеличению сборов или задержек. Сравните эквивалентные действия за один и тот же период и объясните, кто какие расходы платит.
Измерьте полный маршрут, соответствующий пользователю: вход, исполнение, подтверждение, вывод и возврат к желаемому активу или сети. Ориентир, охватывающий только один этап, не должен представляться как цена всего путешествия туда и обратно. Экономия затрат также может варьироваться в зависимости от спроса и условий на уровне данных.
Используйте контрольный список зависимостей
Для каждой системы запишите правила выполнения, полномочия заказа, расположение данных, механизм проверки, место назначения расчетов, элементы управления обновлением и процедуру выхода. Отметьте, какие претензии действительны, а какие запланированы. Укажите источники и дату проверки, поскольку архитектурные настройки могут измениться.
Чтобы узнать о связанной, но отдельной проблеме, прочтите сравнение сообщений между цепочками: оно следует инструкциям между цепочками, а это руководство описывает разделение работы внутри архитектуры.
Технический дизайн протокола и экономические права его токена — это отдельные исследовательские вопросы. Проверьте полезность токена и его фактическую доступность на рынке самостоятельно через официальную документацию и страницу рынков OrangeX, а не рассматривайте заявление о масштабировании как торговое заключение.
