Всё о технической части OMNI(часть 3)
Друзья привет! с Вами, как обычно я, Fixmaster и вот Вам третья часть переводов технички с офф сайта https://docs.omni.network/
Ссылка на гуглдрайв https://docs.google.com/document/d/1MH3FZ1GjH9V-H-NUG6Rf3YqLAxZ15VG6o_MTkPIC8is/edit?usp=sharing
Погнали!
Бэкграунд
Модульные блокчейны
Концепция модульных блокчейнов — это концептуальная модель построения блокчейнов, которая за последние несколько лет приобрела большую популярность в криптоиндустрии.
Монолитные блокчейны
Исторически сложилось так, что блокчейны строились монолитно. Большинство блокчейнов первого уровня были построены как “конечный” сервис — они брали на себя ответственность за все сервисы, которые должен предоставлять блокчейн. Именно так были построены такие решения первого уровня, как Bitcoin и Ethereum. По мере накопления опыта появлялись новые решения первого уровня, которые оптимизировали свои стеки для достижения различных компромиссов в плане безопасности, масштабируемости и скорости. И многие из этих Layer 1 применяли монолитный подход — оптимизацию всего стека цепочки для обеспечения оптимального уровня взаимодействия. Примерами таких новых монолитных систем первого уровня являются Solana, Aptos и Sui.
Модульные блокчейны
Однако с течением времени новейшие инновации стали все больше соответствовать архитектуре микросервисов в сфере разработки традиционного программного обеспечения. Блокчейн — разработчики поняли, что можно разделить компоненты, составляющие блокчейн, и оптимизировать их независимо друг от друга. Впервые такой подход был предложен в дорожной карте Ethereum, а в последнее время его популяризировали такие проекты, как Arbitrum, Celestia и теперь Omni.
Компоненты
Сегодня наше представление о блокчейне позволяет разделить стек на три основных компонента:
Доступность данных: обеспечение того, чтобы данные о транзакциях в блокчейне были доступны участникам сети в момент создания блока.
Исполнение: запуск функции перехода в состояние (STF) блокчейна на входных данных (транзакциях из модуля Data Availability) и вычисление ее выходных данных.
Консенсус: механизм согласования узлами вычисленного результата уровня исполнения и [опционально] окончательного формирования состояния цепи.
Ethereum и роллапы
По мере развития экосистемы Ethereum мы поняли, что масштабирование пропускной способности транзакций и снижение стоимости при сохранении высокого уровня безопасности на Layer-1 Ethereum будет чрезвычайно сложным. Со временем появились различные предложения по решению этой проблемы: каналы состояния, параллельные цепочки, плазменные системы и др. Однако каждый из этих вариантов был связан с неприятными компромиссами, которые, как правило, приводили к снижению безопасности для решения поставленных задач. Но их разработка не была напрасной! Они привели к появлению роллапов — оптимального на сегодняшний день решения для масштабирования Ethereum.
В связи с этим была предложена дорожная карта, ориентированная на создание роллапов.
Сегодня Layer-1 Ethereum обеспечивает доступность данных, исполнение и консенсус. Но со временем Ethereum станет в первую очередь уровнем обеспечения доступности данных. Роллапы будут исполняться вне цепочки, а для консенсуса будут использовать либо слой смарт-контрактов Ethereum, либо свой собственный слой вычислений. Это позволяет роллапам (Layer 2) заимствовать безопасность Ethereum при увеличении пропускной способности и снижении стоимости. Модернизации, подобные EIP-4844, еще больше улучшат Ethereum в качестве слоя доступности данных, предоставляя этот сервис по более низкой цене.
О росте экосистем роллапов можно судить по сайту L2Beat.com, который является отличным ресурсом для изучения вопросов безопасности, текущего состояния разработки и уровня внедрения роллапов.
Урегулирование роллапов
Различают два основных вида раллапов: optimistic роллап и ZK-роллап. Они имеют различные механизмы “урегулирования” для завершения состояния своего роллапа.
Optimistic роллапы работают с доказательствами ошибок. Привилегированный участник может отправить обновления состояния в расчетный контракт роллапа на первом уровне Ethereum. В течение ~7 дней любой желающий может оспорить достоверность этого обновления состояния сети, предоставив доказательство того, что обновление недействительно. Пока за роллапом следит 1 честный участник, недействительные обновления состояния будут оспорены и отброшены к концу 7-дневного периода.
Для роллапов ZK (zero knowledge) расчеты проводятся по-другому. Вместо 7-дневного окна запроса “ проверяющий” выполняет сложные вычисления для создания доказательства валидности. Это доказательство передается вместе с обновлениями состояния сети и является математической гарантией того, что обновление данных является действительным.
Обе системы имеют свои недостатки. У Optimistic-роллап — 7-дневное окно вносит определенные ограничения для пользователей, желающих вывести свои активы из роллапа обратно на первый уровень. ZK-роллапы основаны на сложной математике и тяжелых вычислениях, что затрудняет их децентрализацию с течением времени.
Omni внедряет единую систему расчетов для обеих категорий роллапов и сокращает время расчетов, чтобы быстрее установить стандарт совместимости. Более подробно об этом можно прочитать в разделе “Протокол”.
На этом пока-что Всё!
Соц сети проекта:
