Автор: Chakra Research

В дополнение к собственному решению расширения, упомянутому в первом томе, другой путь расширения Биткойна использует дополнительный уровень протокола поверх Биткойна, называемый Уровнем 2. Двумя наиболее важными моментами решения уровня 2 являются безопасное двустороннее соединение и наследование консенсусной безопасности Биткойна.

Боковая цепь

Истоки концепции сайдчейна можно проследить до статьи «Включение инноваций в блокчейн с помощью привязанной сайдчейна», представленной BlockStream в 2014 году. Это относительно простой план расширения.

Принцип работы

Боковая цепь — это блокчейн, который работает полностью независимо от основной цепи. Он имеет собственный протокол консенсуса и может использоваться в качестве экспериментальной области для инноваций в основной цепи. Когда злокачественный инцидент происходит в боковой цепи, повреждение полностью ограничивается самой боковой цепью и не влияет на основную цепь. Боковая цепь может использовать протокол консенсуса с более высоким TPS, чтобы расширить возможности программирования в цепочке и добиться улучшения BTC.

Боковая цепь может осуществлять передачу биткойнов между различными цепочками блоков посредством двусторонней или односторонней привязки. Конечно, на самом деле BTC может оставаться только в сети Биткойн, поэтому нам нужен механизм привязки, чтобы сделать боковую цепь. BTC в цепочке связан с BTC в сети Биткойн.

Односторонняя привязка требует, чтобы пользователи отправили BTC в основной сети на недоступный адрес для уничтожения, а затем соответствующее количество BTC будет получено в боковой цепи, но процесс нельзя повернуть вспять. Двусторонняя привязка — это дальнейшее обновление односторонней привязки, позволяющее BTC перемещаться между основной и боковой цепочками. Вместо того, чтобы отправлять его на недоступный адрес для уничтожения, двусторонняя привязка блокирует BTC с помощью сценариев управления, таких как мультиподпись, и создает новые BTC в боковой цепи. Когда пользователь захочет вернуться в основную сеть, BTC в боковой цепи будут сожжены, а первоначально заблокированные B TC будут выпущены в основной сети.

Реализация односторонней привязки намного проще, чем реализация двусторонней привязки, поскольку нет необходимости управлять соответствующим состоянием в сети Биткойн, но активы боковой цепи, генерируемые посредством односторонней привязки, могут оказаться бесполезными из-за отсутствие обратного механизма крепления.

Существуют разные решения и разные уровни безопасности для проверки транзакций блокировки в основной цепочке и транзакций уничтожения в боковой цепи. Самый простой вариант — использовать внешнюю проверку участниками с несколькими подписями, но риск централизации высок. Лучшим вариантом является использование SPV Proof для достижения децентрализованной проверки. Конечно, поскольку в сети Биткойн отсутствуют необходимые возможности программирования, проверка SPV не может быть выполнена, и можно только выбрать другие методы, обычно хранение с несколькими подписями.

Вопросы и идеи

Есть две основные проблемы, за которые критикуют сайдчейны:

Зависимость межцепочных активов от верификаторов: поскольку основная сеть Биткойн еще не способна реализовывать смарт-контракты, невозможно обрабатывать межцепочную передачу активов с помощью логики ненадежного контракта при обратном переходе из боковой цепи в Биткойн. , вам необходимо полагаться на группу проверяющих, для завершения операции существует предположение о доверии и существует риск мошенничества.

Боковая цепь не может наследовать безопасность основной цепи: боковая цепь работает полностью независимо от основной сети и не может наследовать безопасность основной сети. Могут произойти такие события, как вредоносная реорганизация блоков.

В этом отношении идеи сайдчейнов включают в себя опору на авторитет (тип альянса), опору на экономическую безопасность (PoS), опору на децентрализованных майнеров биткойнов (объединенный майнинг), опору на аппаратные модули безопасности (HSM), хранение средств и сайдчейн. в Биткойне за производство блоков в цепочке могут отвечать разные роли, тем самым вводя более сложные механизмы безопасности.

Введение в дело

Жидкость

Первой формой сайдчейна является сайдчейн альянса, в котором несколько заранее выбранных организаций выступают в качестве верификаторов и несут ответственность за хранение основных средств сети и производство блоков сайдчейна.

Liquid является представителем боковой цепи альянса, верификаторами которого являются 15 участников. Метод управления закрытыми ключами не раскрывается, для проверки требуется 11 подписей. Блоки боковой цепи Liquid также совместно поддерживаются 15 участниками. Цепочка альянса с небольшим количеством узлов может достичь более высокого TPS и достижения целей расширения. Основная область применения — DeFi.

Подход альянса с боковой цепью сопряжен со значительными централизованными рисками безопасности.

Подвой (RSK)

RSK также имеет 15 узлов, выступающих в качестве хранителей средств основной сети, и для проверки требуется только 8 подписей. Отличие от Liquid заключается в том, что ключ с мультиподписью управляется аппаратным модулем безопасности HSM, а инструкция развязки подписывается в соответствии с консенсусом PoW, чтобы предотвратить прямое манипулирование средствами условного депонирования верификатором, у которого есть ключ.

С точки зрения консенсуса по боковой цепи, RSK использует объединенный майнинг для использования вычислительной мощности основной сети для обеспечения безопасности транзакций в боковой цепи. Когда доля вычислительной мощности объединенного майнинга в основной сети высока, это может лучше предотвратить побочный майнинг. цепь от взлома. RSK внесла улучшения в объединенный майнинг, чтобы обеспечить безопасность боковых цепей при низких скоростях хеширования. Он использует метод распознавания форков для выполнения консенсусного вмешательства вне цепочки в поведение форков и снижения вероятности двойных расходов.

Однако Merged Mining меняет стимулы майнеров и усиливает риски MEV, что в конечном итоге может дестабилизировать систему. В долгосрочной перспективе Merged Mining может усилить централизацию майнинга.

Стеки

Stacks привязывает историю цепочки Stacks к Биткойну, отправляя хэш блока боковой цепи в блок Биткойна. Он имеет ту же окончательность, что и Биткойн. Разветвление Стеков может быть вызвано только форком Биткойна. сопротивляться двойным тратам.

sBTC представляет новый токен STX и модель стимулирования, используя подход моста ставок, который позволяет использовать до 150 валидаторов основной сети. В так называемом мосте ставок валидаторам необходимо ставить токены STX, чтобы получить разрешение на одобрение депозитов и снятия средств. Безопасность залогового моста во многом зависит от стоимости заложенных активов. Когда стоимость заложенных активов сильно колеблется, безопасность кросс-цепочки BTC легко нарушается. Если стоимость заложенных активов ниже стоимости кроссчейн-активов, у валидатора появляется стимул творить зло.

Есть также некоторые предложения по сайдчейну, которые широко обсуждаются в сообществе.

Приводная цепь

Наибольшее внимание привлекла технология Drivechain, предложенная Полом Шторцем в 2015 году. Ключевым технологиям в плане были присвоены BIP 300 (механизм привязки) и BIP 301 (слепой объединенный майнинг). BIP 300 подробно определяет логику добавления новой боковой цепи. Активация новой боковой цепи аналогична активации софт-форка посредством сигналов майнера. BIP 301 позволяет майнерам биткойнов становиться производителями блоков боковой цепи без проверки содержимого конкретной транзакции.

Майнеры биткойнов также несут ответственность за одобрение транзакций вывода. Майнерам сначала необходимо создать вывод OP_RETURN в транзакции coinbase добытого ими блока, чтобы предложить транзакцию вывода. После этого каждый майнер может проголосовать за каждый добытый вами блок. может проголосовать за или против предложения в любое время. Как только транзакция вывода превышает пороговое значение (13150 блоков), транзакция вывода официально выполняется и подтверждается основной цепочкой Биткойн.

Фактически, майнеры имеют полный контроль над средствами в Drivechain. Если средства украдены, пользователи могут спастись только через UASF (активируемый пользователем софт-форк), но достичь консенсуса очень сложно. Более того, уникальное положение майнеров в Drivechain усугубляет риски MEV, как это уже было продемонстрировано на примере Ethereum.

Космическая цепь

Spacechain применил другой подход, используя бессрочную одностороннюю привязку (P1WP). Пользователи сжигают BTC для получения токенов в Spacechain, напрямую пропуская проблему безопасности средств. Этот токен можно использовать только для продажи на аукционе пространства блока в спейсчейне и он не имеет никакой функции хранения стоимости.

Чтобы обеспечить безопасность боковой цепи, Spacechain применяет слепой майнинг слиянием. Другие пользователи используют ANYPREVOUT (APO) для публичной конкуренции за право создания блоков биткойнов. Майнерам биткойнов нужно только зафиксировать заголовок блока Spacechain без проверки. боковая цепь. Однако запуск Spacechain требует поддержки Covanent, и сообщество Биткойн все еще обсуждает необходимость софт-форка для добавления опкода Covanent.

В целом, Spacechain может реализовать боковую цепь с теми же свойствами децентрализации и устойчивости к цензуре, что и Биткойн, и большей программируемостью благодаря функции торгов за блоки в Биткойне.

Софтчейн

Softchain — это предложение боковой цепи 2wp, предложенное автором Spacechain Рубеном Сомсеном. Оно использует механизм консенсуса PoW FP для обеспечения безопасности боковой цепи. В обычных обстоятельствах полному узлу Биткойна необходимо только загрузить заголовок блока софтчейна и проверить доказательство работы. При возникновении форка загрузите потерянный блок и соответствующее обязательство установки UTXO, чтобы проверить достоверность блока.

Для механизма 2wp во время привязки в основной цепочке создается транзакция депозита, и на транзакцию основной цепочки ссылаются в программной цепочке для получения средств во время привязки, в программной цепочке создается транзакция вывода средств; транзакция упоминается в основной цепочке для получения средств BTC, и процесс вывода должен ждать длительного периода проверки, прежде чем он может быть завершен. Конкретные механизмы привязки и привязки требуют поддержки софт-форка, поэтому решение называется Softchain.

Решение Softchain накладывает дополнительные затраты на проверку полных узлов основной сети Bitcoin. Разделение консенсуса Softchain может повлиять на достижение консенсуса в основной сети и стать возможным средством атаки на основную сеть Bitcoin.

Молниеносная сеть

Lightning Network выпустила официальный документ в 2015 году и была официально запущена в 2018 году. Будучи протоколом p2p-платежей уровня 2 в Биткойне, он нацелен на передачу большого количества небольших высокочастотных транзакций на внесетевую обработку. долгое время она считалась самой передовой технологией в сети Биткойн. Перспективный план расширения.

основной модуль

Реализация Lightning Network неотделима от нескольких важных модулей Биткойна, которые вместе обеспечивают безопасность транзакций Lightning Network.

Первая — это предварительно подписанная транзакция. Предварительно подписанные транзакции стали безопасными и доступными только после обновления SegWit. SegWit отделяет подписи от остальных данных транзакций, решая такие проблемы, как потенциальные циклические зависимости, подделка транзакций третьих сторон и подделка транзакций третьих сторон. Безопасность вычислений в цепочке Lightning Network гарантируется безотзывным обязательством, данным другой стороной, и это обязательство реализуется посредством предварительно подписанных транзакций. После получения предварительно подписанной транзакции, предоставленной другой стороной, пользователь может в любой момент транслировать транзакцию в цепочку для завершения выполнения обещания.

Во-вторых, мультиподпись. Для частых переводов средств вне сети между двумя сторонами требуется перевозчик. Этот перевозчик требует, чтобы обе стороны сохраняли определенные права контроля, поэтому требуются мультиподписи. Как правило, используется 2/2 мультиподписи, что гарантирует передачу средств. должно быть осуществлено по обоюдному согласию обеих сторон.

Однако мультиподпись 2/2 вызовет проблемы с работоспособностью, то есть, если другая сторона не будет сотрудничать, пользователь не сможет перевести какие-либо активы с адреса с мультиподписью, что приведет к потере первоначальных средств. Временные блокировки могут решить проблему жизнеспособности. Предварительно подписав контракт с временной блокировкой возврата средств, можно гарантировать, что даже если одна сторона станет неактивной, другая сторона сможет вернуть первоначальные средства.

Наконец, существует хэш-блокировка, которая может соединить несколько каналов состояния и построить сеть. Исходный образ хеша будет использоваться в качестве средства связи для координации правильной работы нескольких объектов.

Запустить процесс

двусторонний канал

Обе стороны, использующие сеть Lightning для проведения транзакций, сначала должны открыть двусторонний платежный канал в Биткойне. Обе стороны могут проводить любое количество транзакций вне цепочки. После завершения всех транзакций последний статус будет отправлен в цепочку Биткойн. завершить расчет и закрыть проход платежа.

В частности, реализация каналов оплаты включает в себя следующие ключевые этапы:

  1. Создайте адрес с мультиподписью. Обеим сторонам канала сначала необходимо создать адрес с мультиподписью 2 из 2 в качестве адреса блокировки средств канала. Каждая сторона имеет закрытый ключ подписи и предоставляет свой собственный открытый ключ.

  2. Инициализируйте канал. Обе стороны транслируют транзакцию в цепочке и фиксируют определенное количество биткойнов на адресе с мультиподписью в качестве начальных средств канала. Эта транзакция называется «якорной» транзакцией канала.

  3. Обновить статус канала. При совершении платежа внутри канала обе стороны обновляют статус канала путем обмена предварительно подписанными транзакциями. Каждое обновление будет генерировать новую «транзакцию обязательства», отражающую текущий статус распределения средств. Транзакция обязательства имеет два выхода, соответствующие долям фонда обеих сторон.

  4. Трансляция последнего статуса. Любая сторона канала может в любой момент передать в блокчейн последнюю транзакцию обязательства, чтобы вывести свою долю средств. Чтобы другая сторона не транслировала старый статус, каждая транзакция обязательства имеет соответствующую «транзакцию наказания». Если другая сторона обманывает, вы можете получить все средства другой стороны.

  5. Закройте канал. Когда две стороны решают закрыть канал, они могут сотрудничать для создания «расчетной транзакции», которая передает окончательный статус распределения средств в блокчейн. Таким образом, средства, заблокированные на адресе с мультиподписью, возвращаются на личные адреса обеих сторон.

  6. Ончейн арбитраж. Если две стороны не могут прийти к соглашению при закрытии канала, любая из сторон может в одностороннем порядке транслировать последнюю транзакцию обязательства и начать процесс внутрисетевого арбитража. Если в течение определенного периода времени (например, 1 дня) не будет возражений, средства будут отправлены обеим сторонам в соответствии с распределением совершенной транзакции.

платежная сеть

Платежные каналы могут быть соединены друг с другом, образуя сеть, поддерживающую многошаговую маршрутизацию, реализованную через HTLC. HTLC использует хэш-блокировку в качестве прямого условия и оплату подписи с блокировкой по времени в качестве резервного условия. Пользователи могут работать с хешированным исходным изображением до истечения срока блокировки.

При отсутствии прямого канала между двумя пользователями оплата может осуществляться с помощью HTLC между маршрутизаторами. Хэш-прообраз R играет ключевую роль во всем процессе, обеспечивая атомарность платежа. В то же время временная блокировка HTLC настроена на уменьшение по пути, гарантируя, что у каждого перехода будет достаточно времени для обработки и пересылки платежа.

Проблемы

По сути, сеть Lightning Network обходит предположение внешнего доверия о мостовом соединении активов через каналы состояния p2p, используя при этом сценарии блокировки по времени, чтобы обеспечить максимальную гарантию активов и защиту от сбоев. Когда другая сторона теряет активность и отказывается сотрудничать, односторонний выход может быть завершен. Таким образом, Lightning Network имеет большое значение для сценариев оплаты, но также имеет множество ограничений, в том числе:

  • Ограничение пропускной способности канала. Емкость платежного канала в сети Lightning ограничена первоначальными заблокированными средствами и не может поддерживать крупные платежи, превышающие пропускную способность канала. Это может ограничивать некоторые сценарии применения, например, торговлю сырьевыми товарами.

  • Онлайн и синхронизировано. Чтобы своевременно получать и пересылать платежи, узлам Lightning Network необходимо оставаться в сети. Если узел находится в автономном режиме в течение длительного времени, он может пропустить некоторые обновления статуса канала, что приведет к рассинхронизации статуса. Это может стать проблемой для отдельных пользователей и мобильных устройств, а также увеличивает стоимость операций узла.

  • Управление ликвидностью. Эффективность маршрутизации Lightning Network зависит от распределения ликвидности по каналам. Если средства распределяются неравномерно, некоторые способы оплаты могут не работать, что повлияет на удобство работы пользователей. Управление балансом ликвидности канала требует определенных технических и капитальных затрат.

  • Нарушение конфиденциальности. Чтобы найти доступные пути оплаты, алгоритм маршрутизации Lightning Network требует определенного уровня знаний о емкости канала и информации о подключении. Это может раскрыть конфиденциальность некоторых пользователей, например распределение средств, контрагентов и т. д. Открытие и закрытие платежных каналов также может раскрыть информацию о соответствующих участниках.

RGB

Первоначальная идея протокола RGB была вдохновлена ​​концепциями проверки на стороне клиента и одноразовой запечатывания, предложенными Питером Тоддом. Он был предложен Джакомо Зукко в 2016 году. Это масштабируемый и сохраняющий конфиденциальность протокол второго уровня Биткойн. .

Основная идея

Проверка клиента

Процесс проверки блокчейна заключается в трансляции блоков, состоящих из транзакций, для всех, позволяя каждому узлу вычислять транзакции в блоке и завершать проверку. Это фактически создает общественное благо, то есть узлы в сети помогают каждому человеку, отправляющему транзакцию, пройти полную проверку, а пользователи предоставляют BTC в качестве комиссии за обработку в качестве стимула помочь с проверкой. Проверка на стороне клиента в большей степени ориентирована на человека. Проверка состояния не выполняется глобально, а проверяется отдельными лицами, участвующими в определенных переходах состояний. Только стороны, генерирующие транзакцию, проверяют действительность перехода состояний. Это значительно улучшает конфиденциальность, а также уменьшает. нагрузка на узлы и улучшает масштабируемость.

Одноразовая пломба

В переходе состояний между точками существует скрытая опасность. Если пользователи не могут собрать полную историю переходов состояний, они могут быть обмануты и совершить двойные траты. Для решения этой проблемы предлагается одноразовая пломба. В ней используется специальный предмет, который можно использовать только один раз, чтобы избежать двойных расходов и повысить безопасность. UTXO Биткойна — наиболее подходящий одноразовый запечатанный объект, гарантированный механизмом консенсуса Биткойна и вычислительной мощностью всей сети, поэтому активы RGB могут наследовать безопасность Биткойна.

Крипто-обещание

Одноразовую печать необходимо сочетать с обязательством по шифрованию, чтобы гарантировать, что пользователь знает о переходе состояний, и избежать возникновения атак двойного расходования. Так называемое обязательство заключается в информировании других о том, что что-то произошло и не может быть изменено позже, но нет необходимости раскрывать конкретные события до момента, когда потребуется проверка. Мы можем использовать хэш-функцию для принятия обязательства. В RGB содержанием обязательства является переход состояния. Посредством расходования UTXO получатель актива RGB получит сигнал о переходе состояния, а затем сверит обязательство с конкретными данными, переданными вне цепочки отправителем. актив.

процесс работы

RGB использует консенсус Биткойна для обеспечения безопасности двойных расходов и устойчивости к цензуре, а все проверки государственных переводов передаются вне цепочки и проверяются только клиентом, принимающим платеж.

Для эмитента активов RGB контракт RGB должен быть создан путем инициирования транзакции, а подтверждение конкретной информации будет храниться в сценарии OP_RETURN для определенного условия расходов в транзакции Taproot.

Когда владелец актива RGB хочет потратить деньги, ему необходимо получить соответствующую информацию от получателя актива, создать транзакцию RGB, зафиксировать детали транзакции RGB и поместить сумму обязательства в UTXO, указанный получателем актива. . и выполните транзакцию, которая расходует исходный UTXO и создает UTXO, указанный получателем. Когда получатель актива замечает, что UTXO, в котором изначально хранился актив RGB, израсходован, он может проверить достоверность транзакции RGB посредством обязательства в транзакции Биткойн. Как только проверка действительна, он считает, что он действительно получил актив. RGB-актив.

Получателю активов RGB плательщику необходимо предоставить исходное состояние и правила перехода между состояниями контракта, транзакции биткойнов, используемые для каждой передачи, транзакции RGB, совершенные каждым обменом биткойнов, и достоверность каждой транзакции биткойнов. проверенный клиентом получателя на основе этих данных, проверяет достоверность транзакции RGB. Среди них UTXO Биткойна используется в качестве контейнера для сохранения состояния контракта RGB. История передачи каждого контракта RGB может быть выражена в виде направленного ациклического графа. Получатель актива RGB может получить только информацию, связанную с RGB. актив, который он хранит, и не имеет доступа к другим веткам.

Преимущества и недостатки

Упрощенная проверка

По сравнению с полной проверкой блокчейна протокол RGB значительно снижает стоимость проверки. Пользователям не нужно просматривать все исторические блоки для получения последнего статуса, им нужно только синхронизировать исторические записи, связанные с активами, которые они получают для проверки. эффективность сделки.

Эта упрощенная проверка упрощает одноранговые транзакции, устраняя необходимость в централизованных поставщиках услуг и повышая уровень децентрализации.

Масштабируемость

Протокол RGB наследует безопасность Биткойна только за счет фиксации хеша. Благодаря сценариям Taproot практически не требуется дополнительное пространство в цепочке Биткойн, что делает возможным сложное программирование активов. Благодаря использованию UTXO в качестве контейнера протокол RGB имеет естественный параллелизм. Активы RGB на разных ветвях передачи не будут блокировать друг друга и могут расходоваться одновременно.

Конфиденциальность

В отличие от обычных протоколов, только получатель активов RGB может получить исторический статус передачи активов RGB. После завершения расходов невозможно получить будущий статус передачи, что в значительной степени гарантирует конфиденциальность пользователя. Нет никакой корреляции между транзакцией активов RGB и передачей биткойн-UTXO, и другие не могут получить следы транзакций RGB в цепочке биткойнов.

Кроме того, RGB также поддерживает слепые расходы, и плательщик не может знать, в какой UTXO будут выплачены активы RGB, что еще больше улучшает конфиденциальность и повышает устойчивость к цензуре.

недостаточный

Когда активы RGB переходят из рук в руки много раз, новые пользователи, получающие активы, будут вынуждены проверять длительную историю передачи, что приводит к более тяжелой проверке, время проверки может увеличиться, а возможность быстрого подтверждения теряется. Для узлов, которые продолжают работать в блокчейне, поскольку последний статус всегда синхронизируется, время получения быстрой передачи статуса проверки новой зоны каждый раз ограничивается.

Сообщество обсуждает возможность повторного использования исторических вычислений, а рекурсивное ZK Proof имеет возможность добиться постоянного времени и размера проверки состояния.

Свернуть

Обзор

Rollup — лучшее решение для расширения, к которому пришла экосистема Ethereum после многих лет исследований: от государственных каналов до Plasma и, наконец, до Rollup.

Rollup — это независимый блокчейн, который собирает транзакции за пределами цепочки Биткойн, упаковывает несколько транзакций в пакет и выполняет его, а также передает данные и статусные обязательства этого пакета в основную цепочку, реализуя внесетевую обработку транзакций и обновление статуса. Чтобы добиться максимального расширения, на этом этапе Rollup обычно использует централизованный секвенсор, чтобы повысить эффективность выполнения без потери безопасности, поскольку безопасность гарантируется проверкой переходов состояний Rollup в основной цепочке.

По мере развития решения Rollup в экосистеме Ethereum, экосистема Биткойн также начала экспериментировать с Rollup. Однако наиболее важным различием между Биткойном и Эфириумом является отсутствие возможностей программирования и неспособность выполнять вычисления, необходимые для создания Rollup в цепочке. Это заставляет людей в настоящее время пытаться реализовать только суверенный Rollup и OP Rollup.

Классификация

В соответствии с различными методами проверки передачи состояния накопительный пакет можно разделить на две основные категории: оптимистический накопительный пакет и накопительный пакет достоверности (ZK Rollup).

Optimistic Rollup использует оптимистичный метод проверки. В период спора после отправки каждого пакета транзакций любой может проверить данные вне цепочки, выдвинуть возражения против проблемных пакетов транзакций, представить доказательства мошенничества в основную цепочку и лишиться Sequencer. Если после периода спора нет действительных доказательств мошенничества, пакет транзакций считается действительным, а обновление статуса подтверждается в основной цепочке.

Validity Rollup использует Validity Proof для завершения проверки, а Sequencer использует алгоритм доказательства с нулевым разглашением для создания краткого доказательства достоверности для каждого пакета транзакций, доказывая, что передача состояния пакета является правильной. Каждое обновление должно отправлять пакет транзакций. основная цепочка подтверждения действительности, основная цепочка проверяет подтверждение, а затем понимает и подтверждает обновление статуса.

Преимущество Optimistic Rollup в том, что его относительно просто реализовать и требуется меньше модификаций основной цепочки. Но подтверждение транзакций занимает больше времени (в зависимости от периода возражений) и требует более высокой доступности данных. Транзакции Validity Rollup подтверждаются быстро, не зависят от периодов возражений, а данные транзакций могут оставаться конфиденциальными, но создание и проверка доказательств с нулевым разглашением требует больших вычислительных затрат.

Celestia также предложила концепцию суверенного объединения. Данные транзакций объединения публикуются в выделенном блокчейне уровня DA, который отвечает за доступность данных, а сам суверенный объединение отвечает за исполнение и расчеты.

Исследуйте и обсуждайте

Развертывание Биткойна все еще находится на ранней стадии. Из-за различий между моделью учета и языком программирования и Эфириумом трудно напрямую копировать практический опыт Эфириума. Сообщество Биткойн активно изучает инновационные решения.

Сводный пакет суверенитета

5 марта 2023 года Rollkit был объявлен первой платформой, поддерживающей суверенные накопительные пакеты Биткойн. Создатели суверенных накопительных пакетов могут публиковать данные о доступности Биткойна через Rollkit.

Rollkit вдохновлен Ordinals и публикует данные через транзакции Taproot. Стандартная транзакция Taproot через общедоступный мемпул может содержать до 390 КБ данных, а нестандартная транзакция Taproot, выпущенная непосредственно майнером, может содержать почти 4 МБ произвольных данных.

Фактическая задача Rollkit — предоставить интерфейс независимому Rollup для чтения и записи данных в Биткойн, предоставить клиентам услуги промежуточного программного обеспечения и превратить Биткойн в уровень DA.

Идея суверенного объединения была встречена с большим скептицизмом, причем многие оппоненты утверждали, что суверенное объединение Биткойна — это не что иное, как использование Биткойна в качестве доски объявлений и совершенно неспособное наследовать безопасность Биткойна. Фактически, если вы отправляете данные о транзакциях только в Биткойн, вы можете только улучшить жизнеспособность, то есть все пользователи могут получить соответствующие данные для проверки через Биткойн, но безопасность может определяться только самим суверенным Rollup и не может быть унаследована. Кроме того, пространство в блоке Биткойна имеет большое значение, и предоставление полных данных о транзакциях может быть не лучшим решением.

Сводка OP и сводка срока действия

Хотя многие проекты второго уровня Биткойна называют себя ZK Rollup, что по сути ближе к OP Rollup, но включает в себя технологию Validity Proof, программные возможности Биткойна еще недостаточны для поддержки прямой проверки Validity Proof.

В настоящее время набор кодов операций Биткойна очень ограничен и не может даже напрямую вычислить умножение. Проверка достоверности требует расширения кодов операций, а также в значительной степени зависит от реализации рекурсивных контрактов. В настоящее время в сообществе обсуждаются OP_CAT, OP_CHECKSIG. OP_TXHASH и т. д. Конечно, если бы мы могли добавить OP_VERIFY_ZKP напрямую, возможно, нам не потребовались бы какие-либо другие модификации, но это явно маловероятно. Кроме того, ограничения на размер стека также препятствуют усилиям по проверке достоверности в биткойн-скриптах, и в настоящее время изучается множество попыток.

Так как же работает подтверждение действительности? Большинство проектов публикуют заявления и доказательства действительности пакетов транзакций в Биткойн в виде надписей и используют BitVM для оптимистической проверки. BitVM Bridge заменяет здесь традиционное решение с несколькими подписями. Оператор моста сформирует альянс из N человек для планирования депозитов пользователей. Прежде чем пользователи внесут депозит, альянс должен будет предварительно подписать сгенерированный UTXO, чтобы гарантировать, что депозит может быть получен Оператором только на законных основаниях. После получения предварительной подписи BTC будет привязан к Taproot-адресу с мультиподписью N/N.

Когда пользователь отправляет запрос на вывод средств, Rollup отправляет подтверждение действительности с выводом Root в цепочку Биткойн. Оператор сначала удовлетворяет потребности пользователя в выводе средств из своего кармана, а затем проверяет действительность с помощью контракта BitVM. Если каждый Оператор считает, что сертификат действителен, Оператор получит возмещение посредством мультиподписи, если кто-либо считает, что имело место мошенничество, будет проведен процесс оспаривания, и неправильная сторона будет удалена.

Этот процесс на самом деле аналогичен OP Rollup. Допущение доверия — 1/N. Пока один верификатор честен, протокол безопасен.

Однако могут возникнуть трудности при технической реализации данного решения. В проекте OP Rollup Ethereum Arbitrum разрабатывался уже много лет, и текущая версия Fraud Proof все еще предоставляется разрешенными узлами. Optimism только недавно объявил, что поддерживает Fraud Proof, что показывает, насколько сложно ее реализовать.

Что касается предварительно подписанной операции в мосте BitVM, то при поддержке Bitcoin Covanent она может быть реализована более эффективно, что еще ждет консенсуса сообщества.

Что касается атрибутов безопасности, путем отправки хэша блока Rollup в Биткойн достигается устойчивость к реорганизации и двойным расходам, а использование оптимистического моста приводит к предположению о безопасности 1/N. Однако устойчивость моста к цензуре все еще может быть. ждите дальнейшего развития.

Вывод: Уровень 2 не является панацеей.

Глядя на множество решений уровня 2, мы легко можем обнаружить, что каждое решение ограничено в задачах, которые оно может решить. При определенных предположениях о доверии эффекты, которых может достичь уровень 2, во многом зависят от уровня 1, то есть от собственных возможностей Биткойна.

Без обновлений SegWit и временных блокировок сеть Lightning не может быть успешно построена; без обновлений Taproot обязательства RGB не могут быть успешно отправлены без OP_CAT и других Covanent, накопительный пакет достоверности в Биткойне не может быть успешно создан;

Многие Bitcoin Maxi считают, что Биткойн никогда не следует менять и добавлять новые функции. Все дефекты должны устраняться на уровне 2. Это невозможно. Уровень 2 не является панацеей. Нам нужен более мощный уровень 1, чтобы построить более безопасный, эффективный и масштабируемый уровень 2.

В следующей статье мы представим попытки улучшить программируемость Биткойна, так что следите за обновлениями.