Автор: Чакра Перевод: 0xjs@金财经

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

боковая цепь

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

Как работает сайдчейн?

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

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

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

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

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

Проблемы и методы

Основная критика сайдчейнов включает в себя:

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

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

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

тематическое исследование

Жидкость

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

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

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

Подвой (RSK)

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

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

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

Стеки

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

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

Другие предложения по сайдчейну в настоящее время широко обсуждаются в сообществе.

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

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

Майнеры биткойнов также несут ответственность за одобрение транзакций вывода средств. Они инициируют предложение о выводе средств, создавая вывод OP_RETURN в транзакции Coinbase добытого ими блока. Затем другие майнеры смогут проголосовать за это предложение, поддерживая или противодействуя ему в каждом добытом ими блоке. Как только транзакция вывода превышает порог (13 150 блоков), она выполняется и подтверждается в основной цепочке Биткойн.

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

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

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

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

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

Софтчейн

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

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

Предложение Softchain добавляет дополнительные затраты на проверку полных узлов основной сети Биткойн, а разделение консенсуса внутри Softchain может повлиять на консенсус основной сети и представлять собой возможный вектор атаки на Биткойн.

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

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

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

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

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

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

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

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

поток операций

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

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

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

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

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

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

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

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

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

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

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

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

Проблемы

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

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

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

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

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

RGB

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

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

Верификация клиента

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

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

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

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

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

Рабочий процесс

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

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

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

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

за и против

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

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

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

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

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

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

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

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

недостаток

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

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

Свернуть

Обзор

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

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

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

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

Свертывания можно разделить на две основные категории: Оптимистические свертки (Optimistic Rollups) и свертки достоверности (ZK Rollups). Основное различие заключается в методе проверки перехода между состояниями.

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

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

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

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

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

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

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

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

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

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

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

Объединение OP и объединение сроков действия

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

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

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

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

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

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

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

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

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

Когда мы рассмотрели различные двухуровневые решения, стало ясно, что каждое решение имеет свои ограничения. Эффективность уровня 2 во многом зависит от возможностей уровня 1 (т. е. Биткойна) при определенных предположениях о доверии.

Успешное создание сети Lightning было бы невозможно без обновлений SegWit и временных блокировок; эффективные фиксации в RGB были бы невозможны без обновлений Taproot Validity Rollups в Биткойне без OP_CAT и других соглашений…

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

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