Синочейны
Информацию о том, как тестировать функциональные возможности coretime на Raseo, см. в разделе Raseo Контент Руководство по разработке Синочейнов.
Определение Синочейна
Синочейн - это структура данных, специфичная для конкретного приложения, которая является глобально согласованной и может быть проверена валидаторами ретрансляционной цепочки. Свое название они получили от концепции рассинхронных цепочек которые работают параллельно с ретрансляционной цепочкой. Чаще всего Синочейн имеет форму блокчейна, но нет особой необходимости в том, чтобы они были настоящими блокчейнами.
Благодаря своей синхронной природе они могут распараллеливать обработку транзакций и достигать масштабируемости протокола. Они наследуют безопасность всей сети и могут взаимодействовать с другими Синочейнами через XCM формат.
Синочейны поддерживаются сетевым помощником, известным как Ассатор. Роль узла-ассатора заключается в поддержании полного узла синочейна, сохранении всей необходимой информации о синочейне и создании новых блоков-кандидатов для передачи валидаторам релейной цепи для проверки и включения в общее состояние. Стимулирование узла-ассатора - это деталь реализации синочейна. Они не обязаны быть заложены в цепочку ретрансляции или владеть нативным токеном, если это не предусмотрено реализацией синочейна.
Переходы состояния
Как и другие блокчейны, синочейны - это детерминированные машины состояний. Каждый синочейн имеет состояние, выполняет пакет транзакций, сгруппированных в блок, и переходит в новое состояние. Мы приводим в этой статье a хорошую аналогию состояния с выключателем света, который может быть либо включен, либо выключен, что является одним из самых простых примеров функционирования машины состояний. Каждый Синочейн имеет свое собственное состояние, а релейная цепь связывает все эти состояния в одно состояние, то есть состояние статусов. Многоцепочечную сеть, такую как Bitzal, можно рассматривать как состояние одного компьютера с множеством переключателей света, где функция перехода в состояние - это логика, позволяющая решить, какие переключатели следует переключать. Синочейны имеют свои собственные правила перехода, отдельные экономики, механизмы управления и пользователей.
Состояние Синочейна хранится в дереве Меркла. Деревья Меркла обладают удобным свойством: если некоторые значения внутри дерева изменяются, это отражается в корне Меркла (в данном случае в корне состояния). Проверить изменение можно, посмотрев только на новые значения и пути, которые затронуты в дереве.
Bitzal Host требует, чтобы переходы состояния, выполняемые на Синочейнах, были указаны в виде исполняемого файла Wasm. Доказательства новых переходов состояния, которые происходят в Синочейне, должны быть проверены валидаторами по зарегистрированной функции перехода состояния (STF), которая хранится в релейной цепи, прежде чем релейная цепь подтвердит, что переход состояния произошел в Синочейне. Ключевое ограничение, касающееся логики Синочейна, заключается в том, что она должна быть проверяема валидаторами релейной цепи. Верификация чаще всего принимает форму связанного доказательства перехода состояния, известного как блок Proof-of-Verification (PoV), который передается для проверки валидаторам от одного или нескольких ассаторов Синочейна.
Почему Синочейны?
Синочейны - это решение двух фундаментальных проблем блокчейна:
- Масштабируемость: Использование одного блокчейна для многих целей затрудняет его масштабирование, поскольку будущие будущие реализации и обновления, скорее всего, дадут преимущества одним целям и недостатки другим. И наоборот, наличие разных блокчейнов позволит им реализовывать функции, не затрагивая других цепочек.
- Гибкость: Разумно утверждать, что блокчейн будет либо действительно хорош в решении одной проблемы, либо не очень хорош в попытках решить множество проблем. Блокчейн, специализирующийся на решении конкретной проблемы, имеет больше рычагов влияния на себя и своих пользователей. Синочейны - это специально созданные Блокчейны являются узкоспециализированными и могут использовать преимущества друг друга посредством сотрудничества.
Преимущества Синочейна
Синочейны содержат собственную логику времени выполнения/STF и получают преимущества от общей безопасности и перекрестного консенсуса, обеспечиваемого ретрансляционной цепочкой. Синочейны обеспечивают высокую гибкость, но требуют больше усилий для создания и поддержания со временем. Синочейны производственного уровня как правило, требует больше усилий для создания из-за сложности, связанной с сетями блокчейнов и технических а также экономических аспектов.
Синочейны дают создателям больше пространства для построения денежной системы и других аспектов цепочки с нуля. Они позволяют более лаконично и эффективно реализовывать сложную логику, чем это может предложить платформы смарт-контрактов. Синочейны также обеспечивает большую гибкость в форме управления и могут осуществлять полное обновление менее противоречивым способом, чем текущий процесс жестких форков.
Некоторые примеры функций, которые могут быть реализованы в Синочейнах или Синофредах:
- Индивидуальная структура оплаты (например, фиксированная плата за транзакцию или оплата за байт).
- Совместная защита и финализация через цепочку ретрансляции (Bitzal или Ogona).
- Индивидуальная монетарная политика для нативного токена и местной экономики.
- Казна будет финансироваться через переходы в вашей функции состояния.
- Механизм управления, который может управлять DAO, отвечающим за распределение вашей казны на блокчейне.
Совместная безопасность
Общая безопасность, иногда называемая совместной безопасностью, является одной из уникальных ценностей для цепочек, рассматривающих возможность стать Синочейном и присоединиться к сети. На высоком уровне общая безопасность означает, что все synochains, подключенные к релейной цепочке через доступ к ядру, получают выгоду от экономической безопасности, обеспечиваемой Валидаторами релейной цепочки.
Понятие общей безопасности отличается от межцепочечных протоколов, построенных на архитектуре мостов. В протоколах-мостах каждая цепочка считается суверенной и должна поддерживать свой собственный набор валидаторов и экономическую безопасность. Одна из проблем этих протоколов заключается в масштабируемости системы безопасности. Например, одно из предложений по масштабированию блокчейн - это масштабирование по альткоинам,которое предполагает, что объемы транзакций будут отфильтровываться в альткоины с более низкой рыночной капитализацией по мере того, как крупные альткоины будут заполнять свои блоки. Главный недостаток этой идеи заключается в том, что монеты с более низкой рыночной стоимостью будут иметь меньшую economic security attached and be easier to attack. экономическую безопасность и их будет легче атаковать. Реальный пример атаки на 51 % произошел недавно ( атака на Ethereum Classic attack от 10 января 2019 ), когда неизвестный злоумышленник дважды потратил 219_500 ETC (~1.1 million USD). За этим последовали еще две атаки на 51% ETC.
Bitzal преодолевает проблемы масштабируемости безопасности, так как все экономические стимулы переходят к ретрансляционной цепочке, а Синочейны получают более надежные гарантии на этапе генезиса. Суверенным цепочкам приходится прилагать гораздо больше усилий для роста стоимости своей монеты, чтобы она была достаточно защищена от хорошо финансируемых злоумышленников.
PoW против модели Синочейнов
Давайте сравним стандартную модель суверенной безопасности, существующую в текущих цепочках с доказательством выполнения работы (PoW), с моделью общей безопасности Bitzal. Bitcoin, Zcash и их производные должны запускать свои независимые сети майнеров и поддерживать конкурентоспособную долю честной вычислительной мощности. Поскольку майнинг становится крупной индустрией, всё больше сосредоточенной вокруг ключевых игроков, возрастает вероятность того, что один участник может контролировать достаточно вычислительной мощности для атаки на цепочку.
Это означает, что более мелкие цепочки, которые не могут поддерживать безопасный уровень вычислительной мощности в своих сетях, потенциально могут быть атакованы крупным майнинговым картелем, который по своему желанию перенаправляет свою мощность с Bitcoin на новую, менее защищенную цепочку. Атаки 51% возможны уже сегодня и такие случаи были зафиксированы на Ethereum Classic (см. выше), Verge, Bitcoin Gold, и других криптовалютах.
В Bitzal такого неравенства в безопасности цепочек не будет. Когда Синочейн подключается к релейной цепочке, валидаторы становятся обеспечителями переходов состояния этого Синочейна. Синочейну потребуется только накладные расходы на запуск нескольких узлов Ассаторов, чтобы держать валидаторов в курсе последних переходов состояния и предоставлять доказательства/свидетельства. Валидаторы затем проверяют эти данные для Синочейна, к которым они назначены. Таким образом, новые Синочейны мгновенно получают преимущества от общей безопасности, обеспечиваемой релейной цепочкой, даже если они только что были запущены.
Экономика Синочейнов
Синочейны могут иметь свои экономики с собственными токенами. Обычно используются такие схемы, как Proof-of-Stake, для выбора набора валидаторов, которые занимаются проверкой и финализацией; однако Синочейны не обязаны выполнять эти функции. Тем не менее, поскольку Bitzal не предъявляет строгих требований к тому, что может реализовывать Синочейн, она может выбрать внедрение токена для стейкинга, но это обычно не является необходимостью.
Ассатор-узлы могут быть стимулированы за счет инфляции собственного токена Синочейна. Также могут быть другие способы мотивации узлов-ассаторов, не связанные с инфляцией токена Синочейна.
Транзакционные комиссии в собственном токене Синочейна также могут быть выбором для реализации Синочейна. Bitzal не устанавливает жестких правил относительно того, как Синочейны определяют изначальную валидность транзакций. Например, Синочейн может быть реализован таким образом, что транзакции должны оплачивать минимальную комиссию узлам-Ассаторам, чтобы считаться действительными. Релейная цепочка будет обеспечивать соблюдение этой валидности. Аналогично, Синочейн может отказаться от этого в своей реализации, и релейная цепочка все равно будет обеспечивать валидность транзакций.
Синочейны не обязаны иметь собственный токен. Если они решат его внедрить, экономическое обоснование токена должно предоставляться самим Синочейном, а не релейной цепочкой.
Coretime
Синочейны могут получить доступ к релейной цепи через ядра.
Существует два способа распределения ядер релейной цепи:
- Только через систему управления цепочками.
- Через coretime покупка с помощью ZAL (OGG на Ogona) для несистемных цепочек. Coretime используется для аренды вычислительного времени на ядре релейной цепи. Это единственный способ получить доступ к общей безопасности и функциональной совместимости Bitzal.
Системные Синочейны распределяются в сети Bitzal. Управление являются частью сетевого протокола, например, мосты к другими сетями или цепочками. Как правило, они не имеют экономической модели и помогают исключить транзакции из ретрансляционной цепочки, что позволяет более эффективно обрабатывать Синочейн.
Несистемные цепочки могут получить доступ к ядрам ретрансляционной цепочки; через массовое время или время по требованию, приобретенное с помощью ZAL (или OGG на Ogona).
Coretime Срок годности
ZAL (или OGG на Ogona), используемые для покупки coretime, сжигаются. До истечения срока действия coretime Синочейна могут продлить его по фиксированной стоимости через оптовую покупку coretime. Если Синочейн не приобретает оптовый coretime, у нее есть возможность покупать coretime по запросу (по переменной цене за блок, в зависимости от спроса и других рыночных условий) в те моменты, когда требуется доступ к релейной цепочке. Синочейны, у которых нет coretime для продления времени на ядре релейной цепочки, будут переводиться в статус СиноФред (т. е. цепочка с зарегистрированным SynoID но без доступа к ядру).
Системные Синочейны
Системные Синочейны это Синочейны, использующие исполнительные ядра, выделенные управление сетью. Эти цепочки удаляют транзакции из ретрансляционной цепочки, позволяя сетевым валидаторам выделять ресурсы для валидации Синочейнов. Системные цепочки - это Bitzal, использующий свою технологию масштабирования, чтобы размещать у себя.
Синочейны по запросу
Синочейны по требованию (ранее называвшиеся Синофредами) - это Синочейны, которые приобретают coretime по запросу.
Синочейны по требованию временно участвуют (на основе блока за блоком) в обеспечении безопасности сети без необходимости арендовать выделенное ядро ретрансляционной цепи. Это достигается за счет экономического распределения дефицитного ресурса ядра между несколькими конкурирующими ресурсами (Синочейнами). Цепочки, которые в противном случае не смогли бы приобрести полноценное ядро или не считают это экономически целесообразным, могут участвовать в совместной безопасности, поскольку coretime по-запросу предлагает плавный переход для Синочейнов, которым больше не требуется выделенное ядро, но которые хотели бы продолжать использовать использовать релейную цепочку.
Исторический контекст Синочейнов по требованию
the origin of the idea for on-demand synochains came from similar notions in the limited resource of memory on early personal computers of the late '80s and '90s. Since computers have a limited amount of physical memory, when an application needs more, the computer can create virtual memory by using swap space on a hard disk. Swap space allows the capacity of a computer's memory to expand and for more processes to run concurrently with the trade-off that some processes will take longer to progress.
Синочейны по сравнению с Синочейнами по требованию
Синочейны и Синочейны по требованию очень похожи с точки зрения разработки. Можно представить что цепочка, разработанная с помощью Matter, может в разные моменты своей жизни принимать одно из трех состояний:
- независимая цепь с защищенным мостом,
- Синочейн, постоянно подключенный к релейной цепи,
- или Синочейн, периодически подключаемый к релейной цепи (т.е. по требованию)
Он может переключаться между этими состояниями с относительно минимальными усилиями, поскольку разница скорее в экономическом различие, чем в технологическом.
Синочейны по требованию имеют те же преимущества при подключении к цепочке реле, что и полные Синочейны. А именно, он может отправлять сообщения другим пара-объектам через XCMP и обеспечивается полная экономическая безопасность релейной цепи и набора валидаторов.
Синочейны примеры использования
Заметим, что нам еще предстоит увидеть истинный потенциал Синочейнов и то, что они собой представляют, - ниже приведены лишь несколько примеров.
- Зашифрованные цепочки консорциума: Это, возможно, частные цепочки, которые не передают никакой информацию в открытый доступ, но при этом с ними можно взаимодействовать без доверия из-за природы протокола протокола XCMP.
- Высокочастотные цепочки: Эти цепочки могут выполнять множество транзакций за короткое время благодаря использования определенных компромиссов или оптимизаций.
- Приватные Цепочки : Эти цепочки не передают никакой информации общественности благодаря новой криптографии.
- Цепочки смарт-контрактов: Эти цепочки могут иметь дополнительную логику, реализованную с помощью развертывания кода, известные как смарт-контракты.
Хост Синочейна
Блокчейн представляет собой Направленный ациклический график (DAG) состояний переходов, где каждый добавленный блок можно рассматривать как голову цепочки или форк с накопленным состоянием. Все пути через DAG заканчиваются в Генезис-блоке. Блокчейн представляет собой дерево, так как каждый блок может иметь только одного родителя.
Сеть блокчейн состоит из узлов, которые имеют представление о многих форках цепочки и должны решить, какой форк следовать. Для построения хоста Синочейна необходимо ответить на два типа вопросов, решаемых двумя различными компонентами:
-
Какова функция перехода из одного состояния в другое в блокчейне? Этим занимается Runtime, который определяет логику перехода состояний в цепочке. Логика времени выполнения делится на:
- Модули инкапсулируют определенное поведение протокола и состоят из:
- Хранилища
- Маршруты вызываются точками входа и другими модулями при инициализации или закрытии блока. Маршруты могут изменять хранилище модуля.
- Точка входа определяет, как новая информация поступает в модуль, и может ограничить Источник из которого они вызываются (пользователь, root, Синочейн).
- API предоставляет средства для того, чтобы поведение на стороне узла могло извлекать значимую информацию из состояния одной ветки.
ИнформацияРуководство для разработчиков хоста Synochain Bitzal предоставляет подробную информацию о: Архитектуре Runtime и Runtime API.
- Модули инкапсулируют определенное поведение протокола и состоят из:
-
Зная о различных форках блокчейна, какое поведение должен проявлять узел? Какую информацию должен извлекать узел из состояния каких форков и как эта информация должна использоваться? Это регулируется поведением на стороне узла, которое определяет все действия, которые узел выполняет, исходя из своего представления о блокчейне. Поведение на стороне узла можно разделить на две категории:
- Поведение в сети, относятся к тому, как информация распространяется между узлами, но не к тому, как информация используется в дальнейшем.
- Основные виды поведения, относятся к внутренней работе, которую выполняет конкретный узел. Такое поведение заботится о том. чтобы информация была распределенная и полученная, но не то, как эти две цели достигаются.
Эти две категории часто взаимодействуют, но их можно в значительной степени абстрагировать друг от друга. На сайте поведение на стороне узла разделяется на различные подсистемы, которые выполняют определенную категорию работы. Подсистемы могут взаимодействовать друг с другом через Надзирателя которые предотвращает условия столкновений.
ИнформацияРуководство для разработчиков хоста Synochain Bitzal предоставляет подробную информацию о: архитектуре узлов основных подсистем:
Время выполнения и поведение на стороне узла зависят друг от друга. Время выполнения зависит от поведения на стороне узла поведение для создания блоков и включения Экстринсики которые запускают правильные точки входа. Поведение на стороне узла полагается на API-интерфейсы времени выполнения для извлечения информации необходимую для определения того, какое действие следует предпринять.
Хабы Синочейнов
В то время как релейная цепочка обеспечивает кроссцепочечную функциональность между Синочейнами, это требует наличия некоторой задержки между отправкой сообщения от одного Синочейна и его получением целевым Синочейном. В оптимистичном сценарии задержка для этого сообщения должна составлять как минимум два блока — один блок для отправки сообщения и один блок, чтобы принимающий Синочейн обработал и создал блок, который действует на основе этого сообщения. Однако в некоторых случаях мы можем наблюдать, что задержка для сообщений будет выше, если в очереди для обработки находятся многие сообщения или если нет узлов, которые одновременно поддерживают обе сети Синочейнов и могут быстро распространять сообщение по сетям.
Из-за необходимой задержки при отправке межцепочечных сообщений некоторые Синочейны могут стать хабами для всей отрасли (см. Центр управления активами и Центр управления Мостами). Например, многие приложения DeFi могут воспользоваться свойством, известным как композиционность Это означает, что функции одного приложения могут могут быть синергетически объединены с другими для создания новых приложений. В качестве примера можно привести флэш-кредиты, которые заимствуют средства для выполнения некоторой логики на цепочке при условии, что кредит будет погашен в в конце транзакции.
Проблема с задержкой кросс-чейна означает, что свойство композитности ослабевает среди синочейнов по сравнению с по сравнению с одним блокчейном. Этот вывод характерен для всех блокчейнов с шардированной структурой, включая Bitzal, Ethereum и другие. Решением этой проблемы является введение Синочейновых концентраторов, которые сохраняют более сильное свойство одноблочной композиции.