С момента появления BTC в 2009 году биткоин претерпел три технические итерации и превратился из простой концепции цифровых нативных активов в децентрализованную финансовую систему со сложными функциями и приложениями.
Эта статья написана основателем BEVM,** который делится своими взглядами на эволюцию технологии BTC, а также подробно отвечает, как BEVM, являющийся ключевой вехой в развитии технологии BTC Layer 2, может реализовать будущее процветание децентрализованной экосистемы BTC на техническом уровне. **
Из этой статьи вы узнаете больше о:
Необходимость BTC Layer 2
Как достичь 2-го уровня BTC?
Полностью децентрализованное BEVM-решение
Дань уважения 3 великим революционным технологическим итерациям BTC с момента его рождения:
2009: Родился BTC, первый раз, когда структура блокчейна использовалась для открытия децентрализованных денежных приложений.
2017: BTC Segregated Witness был обновлен для поддержки хранилища до 4 МБ, решив проблему хранения BTC в сети. Это также послужило основой для взрывоопасного протокола Ordinals (эмиссия активов).
2021: BTC Taproot был обновлен для поддержки алгоритма подписи порога BTC, который обеспечивает базовую поддержку полностью децентрализованной технологии BTC Layer2.
Во-первых, почему вы хотите сделать BTC Layer2?**
1. Спрос есть: Сеть Bitcoin удовлетворяет потребности регистрации активов, но все еще есть большое количество активов, которые должны быть урегулированы в блокчейне (уровень 2)
В настоящее время Layer 2 ETH является лишь копией ETH Layer 1, и нет ничего, что Layer 1 не мог бы решить, кроме реальных бизнес-проблем, которые должен решить Layer 2.
Надо сказать, что ETH Layer 2 решает проблему ETH Layer 1: Layer 2 решает проблему дорогого газа Layer 1. Именно из-за этого спроса было достигнуто первое применение деривативов ETH на Layer2 Arbitrum, таких как GMX.
И 2-й уровень BTC не так неактуален, как 2-й уровень ETH.
Поскольку неполная по Тьюрингу виртуальная машина BTC может только регистрировать активы, но не может производить расчеты, BTC Layer 1 должен нуждаться в Turing-complete BTC Layer 2 для расчетов с активами, выпущенными BTC Layer 1.
2.Возможность: BTC может быть превращен в полностью децентрализованный уровень 2
До обновления BTC Taproot в 2021 году было невозможно достичь полностью децентрализованного BTC Layer 2. Однако после этого обновления алгоритм пороговой подписи BTC позволяет BTC поддерживать полностью децентрализованный вычислительный уровень Layer2.
II.Как достичь децентрализованного BTC L2?
Предложения по улучшению Биткойна (BIP) — это проектные документы, которые вводят новые функции и информацию в Биткойн, в то время как обновления Taproot представляют собой компиляцию трех BIP, а именно Schnorr Signature (BIP 340), Taproot (BIP 341) и Tap (BIP 342), вместе известных как BIP Taproot.
Это обеспечит более эффективный, гибкий и конфиденциальный способ перевода биткойнов за счет использования подписей Шнорра и абстрактных синтаксических деревьев Меркель.
Подписи Шнорра — это схема цифровой подписи, известная своей простотой и безопасностью. Сигнатуры Шнура обладают рядом преимуществ с точки зрения вычислительной эффективности, хранения и конфиденциальности.
! [Основатель BEVM: Зачем и как делать BTC Layer2?] (https://cdn-img.panewslab.com//panews/2022/11/11/images/f2c90430573edf17b34bc2b81d6fba2e.)
Пользователь подтверждает личность подписывающей стороны с помощью открытого ключа и содержание договора с помощью данных, чтобы подтвердить действительность цифрового контракта.
Агрегированные подписи Шнорра могут сжимать и объединять несколько данных подписей в одну агрегированную подпись.
Верификатор проверяет одну агрегированную подпись со списком связанных с ней данных и открытых ключей, что эквивалентно независимой проверке всех соответствующих подписей.
! [Основатель BEVM: Зачем и как делать BTC Layer2?] (https://cdn-img.panewslab.com//panews/2022/11/11/images/c7ed182df952263f95cd6b5da86e5aa3.)
В настоящее время большинство блокчейнов используют алгоритм ECDSA multisig, в котором каждый узел генерирует независимую цифровую подпись со своим закрытым ключом для данных блока и транслирует ее другим узлам. Другой узел проверяет подпись и записывает ее в следующий блок данных.
Таким образом, при большом количестве узлов консенсуса данные подписи, хранящиеся в каждом раунде блоков консенсуса, будут продолжать увеличиваться, занимая место в хранилище.
Всякий раз, когда новый узел присоединяется к сети и ему необходимо синхронизировать исторические блоки, большой объем данных сигнатур создает большую проблему для пропускной способности сети.
После использования технологии агрегированной подписи каждый узел будет собирать агрегированные визитные карточки подписей, транслируемые другими узлами, а затем сохранять агрегированный сегмент подписи, как показано на рисунке 2.**
Таким образом, при присоединении нового узла блоку истории синхронизации достаточно загрузить агрегированные данные подписи, что значительно снижает нагрузку на пропускную способность сети и снижает расходы на комиссию за транзакцию.
Кроме того, агрегация ключей делает все выходы Taproot похожими. Будь то выход с несколькими подписями, выход с одной подписью или другие сложные смарт-контракты, все они выглядят одинаково в блокчейне, поэтому многие аналитики блокчейна будут недоступны, сохраняя конфиденциальность для всех пользователей Taproot. **
! [Основатель BEVM: Зачем и как делать BTC Layer2?] (https://cdn-img.panewslab.com//panews/2022/11/11/images/187dbc4fe20ec85e558eb12132a2a850.)
MAST (Merkle Abstract Syntax Tree) — это серия непересекающихся скриптов (например, multisig или timelock), которые используют дерево Меркла для шифрования сложных скриптов блокировки.
При расходовании средств необходимо раскрывать только рассматриваемый сценарий и путь от этого скрипта к корню дерева Merck. Как показано на рисунке 3, для использования 1 нужно раскрыть только 1, 2 и hash3.
К основным преимуществам MAST можно отнести:
1) Поддержка сложных условий расходов
2) Нет необходимости раскрывать невыполненные сценарии или несработавшие условия расходов, что обеспечивает лучшую защиту конфиденциальности
**3) Сжатие размера транзакции: По мере увеличения количества скриптов размер транзакции, не относящейся к MAST, увеличивается линейно, в то время как размер транзакции MAST увеличивается логарифмически. **
Однако в обновлении Taproot есть проблема, то есть P2SH — это не то же самое, что обычный Pay-to-Public-Key-Hash (P2PKH), и все еще есть проблемы с защитой конфиденциальности.
Можно ли сделать так, чтобы P2SH и P2PKH выглядели одинаково в блокчейне?
С этой целью Taproot предлагает решение, которое можно разбить на две части для скрипта с ограниченным количеством подписантов:
Первая часть — это мультиподпись, когда все подписанты соглашаются с определенным результатом расходов, известным как «совместные расходы».
Вторая часть называется «несовместные расходы» и может иметь очень сложную структуру сценария.
Эти две части являются отношением «или».
Как показано на рисунках 3 и 3, мультиподпись 2-из-2 требует, чтобы и Алиса, и Боб были действительными, что является «совместными расходами», а 1 и 2 — «несовместными расходами».
Как «совместные расходы», так и «несовместные расходы» могут расходовать этот результат, где:
Для скрипта «несовместных расходов» используйте подход MAST, описанный выше, и используйте MerkleRoot для представления корня дерева Merck.
Для скрипта «совместных расходов» принят алгоритм мультиподписи, основанный на подписях Шнора. Pa и Pb используются для представления открытых ключей Алисы и Боба соответственно, а Da и Db — для представления закрытых ключей Алисы и Боба соответственно.
Таким образом, совокупный открытый ключ имеет вид P=Pa+Pb, а соответствующий закрытый ключ — Da+Db.
Объедините «совместные расходы» и «несовместные расходы» в виде P2PKH, и его публичный ключ: PP+H(P||MerkleRoot)G; соответствующий закрытый ключ — Da+Db+H(P||MerkleRoot)。
Когда Алиса и Боб договариваются о «совместном расходовании», они используют Da+Db+H(P||MerkleRoot) требует, чтобы только один из них добавил H(P||) к своему закрытому ключуMerkleRoot).
В блокчейне это ведет себя как транзакция P2PKH с открытым ключом и соответствующим закрытым ключом, без необходимости раскрывать базовый MAST.
III. Наше полностью децентрализованное решение 2-го уровня BTC:
3.1 BTC легкий узел + контракт на подписание распределенного порога
! [Основатель BEVM: Зачем и как делать BTC Layer2?] (https://cdn-img.panewslab.com//panews/2022/11/11/images/d6ddaf08422a0b02bc25e45cd2f5d947.)
В этой схеме выбираются n (n могут быть все валидаторы на BEVM) фиксированных валидаторов для завершения ончейн-контракта совокупного хранения BTC с распределенным пороговым подписанием.
Приватный ключ каждого валидатора в BEVM layer2 также является производным от части совокупного приватного ключа пороговой подписи BTC, а пороговый приватный ключ n валидаторов объединяется в агрегированный адрес подписи photo BTC. **n может быть до 1000 и более. **
Когда пользователь А хочет перевести BTC в BEVM, ему нужно только отправить BTC в контракт хранения агрегации биткоинов, и пользователь может получить BTC на уровне BEVM 2.
Соответственно, когда пользователь А совершает операцию вывода, ему нужно только взаимодействовать с m автозаполненными контрактами распределенной пороговой подписи в совокупной подписи среди n валидаторов, и перевод с эскроу-контракта пользователю А может быть завершен на Bitcoin, и BTC будет сожжен на BEVM одновременно с завершением перевода.
3.2 Реализация BTC в качестве нативной платы за газ и EVM-совместимого уровня 2
1) Принцип EVM
Виртуальная машина Ethereum — это среда выполнения смарт-контрактов Ethereum. Он не только изолирован, но и полностью изолирован.
Это означает, что код, выполняемый в EVM, не может получить доступ к сети, файловой системе и другим процессам. Даже доступ между смарт-контрактами ограничен.
Базовый уровень Ethereum поддерживает выполнение и вызов контракта через модуль EVM, а код контракта получается в соответствии с адресом контракта при вызове, и он загружается в EVM для работы. Как правило, процесс разработки смарт-контракта заключается в написании логического кода в solidlity, компиляции его в байт-код через компилятор и, наконец, публикации в Ethereum.
! [Основатель BEVM: Зачем и как делать BTC Layer2?] (https://cdn-img.panewslab.com//panews/2022/11/11/images/2d2d923b8ae9ff718bac8dedbf6a9314.)
2) Основные части EVM
! [Основатель BEVM: Зачем и как делать BTC Layer2?] (https://cdn-img.panewslab.com//panews/2022/11/11/images/67f265774f666ae9ab031a29230b5b8d.)
3)Код EVM
Код EVM — это код виртуальной машины Ethereum, который относится к коду языка программирования, который может содержать Ethereum. Код EVM, связанный с учетной записью, выполняется каждый раз, когда сообщение отправляется в учетную запись, и имеет возможность чтения/записи хранилища и отправки сообщений самостоятельно.
4)Штат Мчина
Состояние Mchine — это место, где выполняется код EVM, содержащий счетчики программ, стеки и память.
5)Хранение
Хранилище — это постоянное пространство хранения, которое можно читать, записывать и изменять, а также место, где каждый контракт постоянно хранит данные. Хранилище представляет собой огромную карту, насчитывающую в общей сложности 2256 слотов, каждый из которых имеет размер 32 байта каждый.
6) BTC в качестве платы за газ
Пусть BTC, переведенный из сети Bitcoin, используется в качестве валюты расчета платы за газ для выполнения транзакций на EVM.
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
Основатель BEVM: зачем и как делать BTC Layer 2?
Автор: Peter
Преамбула
С момента появления BTC в 2009 году биткоин претерпел три технические итерации и превратился из простой концепции цифровых нативных активов в децентрализованную финансовую систему со сложными функциями и приложениями.
Эта статья написана основателем BEVM,** который делится своими взглядами на эволюцию технологии BTC, а также подробно отвечает, как BEVM, являющийся ключевой вехой в развитии технологии BTC Layer 2, может реализовать будущее процветание децентрализованной экосистемы BTC на техническом уровне. **
Из этой статьи вы узнаете больше о:
Необходимость BTC Layer 2
Как достичь 2-го уровня BTC?
Полностью децентрализованное BEVM-решение
Дань уважения 3 великим революционным технологическим итерациям BTC с момента его рождения:
2009: Родился BTC, первый раз, когда структура блокчейна использовалась для открытия децентрализованных денежных приложений.
2017: BTC Segregated Witness был обновлен для поддержки хранилища до 4 МБ, решив проблему хранения BTC в сети. Это также послужило основой для взрывоопасного протокола Ordinals (эмиссия активов).
2021: BTC Taproot был обновлен для поддержки алгоритма подписи порога BTC, который обеспечивает базовую поддержку полностью децентрализованной технологии BTC Layer2.
Во-первых, почему вы хотите сделать BTC Layer2?**
1. Спрос есть: Сеть Bitcoin удовлетворяет потребности регистрации активов, но все еще есть большое количество активов, которые должны быть урегулированы в блокчейне (уровень 2)
В настоящее время Layer 2 ETH является лишь копией ETH Layer 1, и нет ничего, что Layer 1 не мог бы решить, кроме реальных бизнес-проблем, которые должен решить Layer 2.
Надо сказать, что ETH Layer 2 решает проблему ETH Layer 1: Layer 2 решает проблему дорогого газа Layer 1. Именно из-за этого спроса было достигнуто первое применение деривативов ETH на Layer2 Arbitrum, таких как GMX.
И 2-й уровень BTC не так неактуален, как 2-й уровень ETH.
Поскольку неполная по Тьюрингу виртуальная машина BTC может только регистрировать активы, но не может производить расчеты, BTC Layer 1 должен нуждаться в Turing-complete BTC Layer 2 для расчетов с активами, выпущенными BTC Layer 1.
2.Возможность: BTC может быть превращен в полностью децентрализованный уровень 2
До обновления BTC Taproot в 2021 году было невозможно достичь полностью децентрализованного BTC Layer 2. Однако после этого обновления алгоритм пороговой подписи BTC позволяет BTC поддерживать полностью децентрализованный вычислительный уровень Layer2.
II.Как достичь децентрализованного BTC L2?
Предложения по улучшению Биткойна (BIP) — это проектные документы, которые вводят новые функции и информацию в Биткойн, в то время как обновления Taproot представляют собой компиляцию трех BIP, а именно Schnorr Signature (BIP 340), Taproot (BIP 341) и Tap (BIP 342), вместе известных как BIP Taproot.
Это обеспечит более эффективный, гибкий и конфиденциальный способ перевода биткойнов за счет использования подписей Шнорра и абстрактных синтаксических деревьев Меркель.
Подписи Шнорра — это схема цифровой подписи, известная своей простотой и безопасностью. Сигнатуры Шнура обладают рядом преимуществ с точки зрения вычислительной эффективности, хранения и конфиденциальности.
! [Основатель BEVM: Зачем и как делать BTC Layer2?] (https://cdn-img.panewslab.com//panews/2022/11/11/images/f2c90430573edf17b34bc2b81d6fba2e.)
Пользователь подтверждает личность подписывающей стороны с помощью открытого ключа и содержание договора с помощью данных, чтобы подтвердить действительность цифрового контракта.
Агрегированные подписи Шнорра могут сжимать и объединять несколько данных подписей в одну агрегированную подпись.
Верификатор проверяет одну агрегированную подпись со списком связанных с ней данных и открытых ключей, что эквивалентно независимой проверке всех соответствующих подписей.
! [Основатель BEVM: Зачем и как делать BTC Layer2?] (https://cdn-img.panewslab.com//panews/2022/11/11/images/c7ed182df952263f95cd6b5da86e5aa3.)
В настоящее время большинство блокчейнов используют алгоритм ECDSA multisig, в котором каждый узел генерирует независимую цифровую подпись со своим закрытым ключом для данных блока и транслирует ее другим узлам. Другой узел проверяет подпись и записывает ее в следующий блок данных.
Таким образом, при большом количестве узлов консенсуса данные подписи, хранящиеся в каждом раунде блоков консенсуса, будут продолжать увеличиваться, занимая место в хранилище.
Всякий раз, когда новый узел присоединяется к сети и ему необходимо синхронизировать исторические блоки, большой объем данных сигнатур создает большую проблему для пропускной способности сети.
После использования технологии агрегированной подписи каждый узел будет собирать агрегированные визитные карточки подписей, транслируемые другими узлами, а затем сохранять агрегированный сегмент подписи, как показано на рисунке 2.**
Таким образом, при присоединении нового узла блоку истории синхронизации достаточно загрузить агрегированные данные подписи, что значительно снижает нагрузку на пропускную способность сети и снижает расходы на комиссию за транзакцию.
Кроме того, агрегация ключей делает все выходы Taproot похожими. Будь то выход с несколькими подписями, выход с одной подписью или другие сложные смарт-контракты, все они выглядят одинаково в блокчейне, поэтому многие аналитики блокчейна будут недоступны, сохраняя конфиденциальность для всех пользователей Taproot. **
! [Основатель BEVM: Зачем и как делать BTC Layer2?] (https://cdn-img.panewslab.com//panews/2022/11/11/images/187dbc4fe20ec85e558eb12132a2a850.)
MAST (Merkle Abstract Syntax Tree) — это серия непересекающихся скриптов (например, multisig или timelock), которые используют дерево Меркла для шифрования сложных скриптов блокировки.
При расходовании средств необходимо раскрывать только рассматриваемый сценарий и путь от этого скрипта к корню дерева Merck. Как показано на рисунке 3, для использования 1 нужно раскрыть только 1, 2 и hash3.
К основным преимуществам MAST можно отнести:
1) Поддержка сложных условий расходов
2) Нет необходимости раскрывать невыполненные сценарии или несработавшие условия расходов, что обеспечивает лучшую защиту конфиденциальности
**3) Сжатие размера транзакции: По мере увеличения количества скриптов размер транзакции, не относящейся к MAST, увеличивается линейно, в то время как размер транзакции MAST увеличивается логарифмически. **
Однако в обновлении Taproot есть проблема, то есть P2SH — это не то же самое, что обычный Pay-to-Public-Key-Hash (P2PKH), и все еще есть проблемы с защитой конфиденциальности.
Можно ли сделать так, чтобы P2SH и P2PKH выглядели одинаково в блокчейне?
С этой целью Taproot предлагает решение, которое можно разбить на две части для скрипта с ограниченным количеством подписантов:
Первая часть — это мультиподпись, когда все подписанты соглашаются с определенным результатом расходов, известным как «совместные расходы».
Вторая часть называется «несовместные расходы» и может иметь очень сложную структуру сценария.
Эти две части являются отношением «или».
Как показано на рисунках 3 и 3, мультиподпись 2-из-2 требует, чтобы и Алиса, и Боб были действительными, что является «совместными расходами», а 1 и 2 — «несовместными расходами».
Как «совместные расходы», так и «несовместные расходы» могут расходовать этот результат, где:
Для скрипта «несовместных расходов» используйте подход MAST, описанный выше, и используйте MerkleRoot для представления корня дерева Merck.
Для скрипта «совместных расходов» принят алгоритм мультиподписи, основанный на подписях Шнора. Pa и Pb используются для представления открытых ключей Алисы и Боба соответственно, а Da и Db — для представления закрытых ключей Алисы и Боба соответственно.
Таким образом, совокупный открытый ключ имеет вид P=Pa+Pb, а соответствующий закрытый ключ — Da+Db.
Объедините «совместные расходы» и «несовместные расходы» в виде P2PKH, и его публичный ключ: PP+H(P||MerkleRoot)G; соответствующий закрытый ключ — Da+Db+H(P||MerkleRoot)。
Когда Алиса и Боб договариваются о «совместном расходовании», они используют Da+Db+H(P||MerkleRoot) требует, чтобы только один из них добавил H(P||) к своему закрытому ключуMerkleRoot).
В блокчейне это ведет себя как транзакция P2PKH с открытым ключом и соответствующим закрытым ключом, без необходимости раскрывать базовый MAST.
III. Наше полностью децентрализованное решение 2-го уровня BTC:
3.1 BTC легкий узел + контракт на подписание распределенного порога
! [Основатель BEVM: Зачем и как делать BTC Layer2?] (https://cdn-img.panewslab.com//panews/2022/11/11/images/d6ddaf08422a0b02bc25e45cd2f5d947.)
В этой схеме выбираются n (n могут быть все валидаторы на BEVM) фиксированных валидаторов для завершения ончейн-контракта совокупного хранения BTC с распределенным пороговым подписанием.
Приватный ключ каждого валидатора в BEVM layer2 также является производным от части совокупного приватного ключа пороговой подписи BTC, а пороговый приватный ключ n валидаторов объединяется в агрегированный адрес подписи photo BTC. **n может быть до 1000 и более. **
Когда пользователь А хочет перевести BTC в BEVM, ему нужно только отправить BTC в контракт хранения агрегации биткоинов, и пользователь может получить BTC на уровне BEVM 2.
Соответственно, когда пользователь А совершает операцию вывода, ему нужно только взаимодействовать с m автозаполненными контрактами распределенной пороговой подписи в совокупной подписи среди n валидаторов, и перевод с эскроу-контракта пользователю А может быть завершен на Bitcoin, и BTC будет сожжен на BEVM одновременно с завершением перевода.
3.2 Реализация BTC в качестве нативной платы за газ и EVM-совместимого уровня 2
1) Принцип EVM
Виртуальная машина Ethereum — это среда выполнения смарт-контрактов Ethereum. Он не только изолирован, но и полностью изолирован.
Это означает, что код, выполняемый в EVM, не может получить доступ к сети, файловой системе и другим процессам. Даже доступ между смарт-контрактами ограничен.
Базовый уровень Ethereum поддерживает выполнение и вызов контракта через модуль EVM, а код контракта получается в соответствии с адресом контракта при вызове, и он загружается в EVM для работы. Как правило, процесс разработки смарт-контракта заключается в написании логического кода в solidlity, компиляции его в байт-код через компилятор и, наконец, публикации в Ethereum.
! [Основатель BEVM: Зачем и как делать BTC Layer2?] (https://cdn-img.panewslab.com//panews/2022/11/11/images/2d2d923b8ae9ff718bac8dedbf6a9314.)
2) Основные части EVM
! [Основатель BEVM: Зачем и как делать BTC Layer2?] (https://cdn-img.panewslab.com//panews/2022/11/11/images/67f265774f666ae9ab031a29230b5b8d.)
3)Код EVM
Код EVM — это код виртуальной машины Ethereum, который относится к коду языка программирования, который может содержать Ethereum. Код EVM, связанный с учетной записью, выполняется каждый раз, когда сообщение отправляется в учетную запись, и имеет возможность чтения/записи хранилища и отправки сообщений самостоятельно.
4)Штат Мчина
Состояние Mchine — это место, где выполняется код EVM, содержащий счетчики программ, стеки и память.
5)Хранение
Хранилище — это постоянное пространство хранения, которое можно читать, записывать и изменять, а также место, где каждый контракт постоянно хранит данные. Хранилище представляет собой огромную карту, насчитывающую в общей сложности 2256 слотов, каждый из которых имеет размер 32 байта каждый.
6) BTC в качестве платы за газ
Пусть BTC, переведенный из сети Bitcoin, используется в качестве валюты расчета платы за газ для выполнения транзакций на EVM.