Написал: Питер
Предисловие
С момента появления BTC в 2009 году Биткойн, претерпевший три технологические итерации, превратился из простой концепции цифровых активов в децентрализованную финансовую систему со сложными функциями и приложениями.
Эта статья написана основателем BEVM, который делится своими взглядами на эволюцию технологии BTC. В ней также подробно объясняется, как BEVM, ключевая веха в развитии технологии BTC Layer2, реализует будущее BTC на техническом уровне. Децентрализованное экологическое процветание.
Из этой статьи вы узнаете больше о:
- Необходимость BTC Layer2
- Как реализовать BTC Layer2?
- Полностью децентрализованное решение BEVM
Отдайте должное трем великим революционным технологическим итерациям BTC с момента его рождения:
- 2009: родился BTC, впервые использовавший структуру блокчейна для открытия децентрализованных валютных приложений.
- 2017: BTC Segregated Witness был модернизирован для поддержки максимального объема хранилища 4 МБ, что решило проблему хранения BTC в цепочке. Это также обеспечивает основу для популярного в настоящее время протокола Ordinals (выпуска активов).
- 2021: BTC Taproot обновляется для поддержки алгоритма пороговой подписи BTC, который обеспечивает базовую поддержку полностью децентрализованной технологии BTC Layer2.
1. Почему вы хотите создать BTC Layer2?
1. Спрос есть. Сеть Биткойн удовлетворяет спрос на регистрацию активов, но все еще существует большое количество активов, требующих расчетов в сети (уровень 2).
Текущий уровень 2 ETH является просто копией уровня 1 ETH и не решает никаких практических бизнес-задач, которые не могут быть решены на уровне 1 и должны быть решены на уровне 2.
Надо сказать, что ETH Layer2 решает проблему ETH Layer1: Layer2 решает проблему высокой стоимости газа Layer1. Именно из-за этого спроса были созданы приложения для деривативов на крупнейшем арбитраже уровня 2 ETH, таком как GMX.
Уровень 2 BTC не так важен, как уровень 2 ETH.
Поскольку виртуальная машина BTC, не полная по Тьюрингу, может только регистрировать активы, но не может производить расчеты, BTC Layer1 должен потребовать, чтобы BTC Layer2 был завершен по Тьюрингу для расчетов по активам, выпущенным BTC Layer1.
2. Возможности: BTC может стать полностью децентрализованным уровнем 2.
До обновления BTC Taproot в 2021 году будет невозможно достичь полностью децентрализованного уровня BTC Layer2. Однако после этого обновления алгоритм пороговой подписи BTC позволяет BTC поддерживать полностью децентрализованный вычислительный уровень 2-го уровня.
Во-вторых, как добиться децентрализации BTC L2?
Предложения по улучшению Биткойна (BIP) — это проектные документы, которые вводят в Биткойн новые функции и информацию, а обновление Taproot представляет собой компиляцию трех BIP, а именно: Подпись Шнорра (BIP 340), Taproot (BIP 341) и Tapscript (BIP 342). три обновления вместе называются BIP Taproot.
Он принесет в Биткойн более эффективный, гибкий и конфиденциальный метод передачи данных, и его суть заключается в использовании подписей Шнорра и абстрактных синтаксических деревьев Меркель.
Он принесет в Биткойн более эффективный, гибкий и конфиденциальный метод передачи данных, и его суть заключается в использовании подписей Шнорра и абстрактных синтаксических деревьев Меркель.
Подпись Шнорра — это схема цифровой подписи, известная своей простотой и безопасностью. Подписи Шнура предлагают несколько преимуществ с точки зрения вычислительной эффективности, хранения и конфиденциальности.
Пользователь подтверждает личность подписывающего лица с помощью открытого ключа и подтверждает содержание контракта с помощью данных, тем самым проверяя действительность цифрового контракта.
Агрегатная подпись Шнорра может сжимать и объединять несколько данных подписи в одну агрегатную подпись.
Верификатор проверяет единую совокупную подпись с помощью списка всех связанных с подписями данных и открытых ключей. Если проверка пройдена, эффект эквивалентен независимой проверке всех связанных подписей и всех результатов.
Большинство современных блокчейнов используют алгоритм мультиподписи ECDSA.Для данных блока каждый узел использует свой собственный закрытый ключ для генерации независимой цифровой подписи и передачи ее другим узлам. Другие узлы проверят подпись и запишут ее в следующий блок данных.
При использовании этого метода, когда количество узлов консенсуса велико, данные подписи, хранящиеся в каждом раунде блоков консенсуса, будут продолжать увеличиваться и занимать место для хранения.
Всякий раз, когда новый узел присоединяется к сети и ему необходимо синхронизировать исторические блоки, большой объем сигнатурных данных создает серьезную проблему для пропускной способности сети.
После использования технологии совокупной подписи каждый узел будет собирать визитные карточки совокупной подписи, транслируемые другими узлами, а затем объединять и сохранять подписи во фрагментах, как показано на рисунке 2.
Таким образом, когда присоединяется новый узел, для синхронизации исторических блоков требуется только загрузка агрегированных данных подписи, что значительно снижает использование пропускной способности сети и снижает комиссию за транзакции.
Кроме того, агрегирование ключей делает все выходные данные Taproot похожими. Независимо от того, будут ли выходные данные с несколькими подписями, выходные данные с одной подписью или другие сложные смарт-контракты выглядеть одинаково в блокчейне, многие анализы блокчейна будут недоступны, что сохранит конфиденциальность для всех пользователей Taproot.
MAST (Абстрактное синтаксическое дерево Меркла) использует дерево Меркла для шифрования сложных сценариев блокировки, листьями которых являются непересекающиеся сценарии Шиллера (например, мультиподписи или временные блокировки).
MAST (Абстрактное синтаксическое дерево Меркла) использует дерево Меркла для шифрования сложных сценариев блокировки, листьями которых являются непересекающиеся сценарии Шиллера (например, мультиподписи или временные блокировки).
При выплате раскрываются только соответствующий сценарий и путь от этого сценария до корня дерева Merck. Как показано на рисунке 3, чтобы использовать скрипт1, вам нужно раскрыть только скрипт1, скрипт2 и хеш3.
Ключевые преимущества MAST включают в себя:
- Поддерживает сложные условия выплат
- Нет необходимости раскрывать невыполненные скрипты или неактивированные условия выплат, обеспечивая лучшую защиту конфиденциальности.
- Размер сжатой транзакции. По мере увеличения количества скриптов размер транзакции, отличной от MAST, растет линейно, а размер транзакции MAST растет логарифмически.
Однако в обновлении Taproot есть проблема: P2SH ведет себя иначе, чем обычный хэш с оплатой по открытому ключу (P2PKH), и все еще существуют проблемы с защитой конфиденциальности.
Можно ли сделать так, чтобы P2SH и P2PKH выглядели одинаково в цепочке?
С этой целью Taproot предложил решение, которое можно разбить на две части для скриптов с ограниченным количеством подписантов:
Первая часть представляет собой мультиподпись, при которой все подписавшиеся договариваются об определенном результате расходов, который называется «совместными расходами».
Вторая часть называется «несовместные расходы» и может иметь очень сложную структуру сценария.
Эти две части находятся в отношениях «или».
Как показано на рисунке 3, Script3 представляет собой мультиподпись 2 из 2, которая требует подписи как Алисы, так и Боба, чтобы быть действительной. Это «совместные расходы», тогда как Script1 и 2 являются «несовместными расходами».
Этот выход могут расходовать как «совместные расходы», так и «несовместные расходы», среди которых:
- Для сценария «несовместных расходов» примените описанный выше метод MAST и используйте MerkleRoot для представления корня дерева Меркла.
- Для сценария «совместных расходов» принят алгоритм мультиподписи, основанный на подписи Шноора. Пусть 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.
3. Наше полностью децентрализованное решение BTC Layer2:
3.1 Легкий узел BTC + контракт подписи с распределенным порогом
В этом решении n (n может быть всеми валидаторами на BEVM) фиксированных валидаторов выбираются для завершения контракта на хранение распределенной пороговой агрегации подписей в цепочке BTC.
В этом решении n (n может быть всеми валидаторами на BEVM) фиксированных валидаторов выбираются для выполнения контракта на хранение распределенной пороговой агрегации подписей в цепочке BTC.
Генерирующий блок закрытый ключ каждого валидатора на уровне BEVM 2 также получает часть совокупного закрытого ключа пороговой подписи BTC. Пороговые частные ключи n валидаторов объединяются в совокупный адрес фотографии подписи BTC. Максимальный диапазон значений n может составлять 1000 или более.
- Когда пользователь А хочет перекрестно подключить BTC к BEVM, ему нужно только отправить BTC в контракт хранения агрегации биткойнов, и пользователь может получить BTC на уровне BEVM 2.
- Соответственно, когда пользователь А выполняет операцию вывода средств, только m из n узлов проверки, составляющих агрегированные подписи, автоматически завершают взаимодействие контракта подписи с распределенным пороговым значением, и передача из депозитарного контракта пользователю А может быть завершена в Биткойне. , BTC будет уничтожен на BEVM.
3.2 Внедрение BTC в качестве платы за газ и EVM-совместимого уровня 2
1) Принцип ЭВМ
Виртуальная машина Ethereum — это среда выполнения смарт-контрактов Ethereum. Он не только изолирован, но и полностью изолирован.
Это означает, что код, работающий в EVM, не может получить доступ к сети, файловой системе и другим процессам. Даже доступ между смарт-контрактами ограничен.
Нижний уровень Ethereum поддерживает исполнение и вызов контрактов через модуль EVM.При вызове код контракта получается по адресу контракта и загружается в EVM для запуска. Обычно процесс разработки смарт-контрактов заключается в использовании Solidity для написания логического кода, затем компиляции его в байт-код с помощью компилятора и, наконец, публикации в Ethereum.
2) Основная часть ЭВМ
3) Код ЭВМ
Код EVM — это код виртуальной машины Ethereum, который относится к коду языка программирования, который может содержать Ethereum. Код EVM, связанный с учетной записью, выполняется каждый раз, когда сообщение отправляется в учетную запись, и имеет возможность чтения/записи хранилища и самой отправки сообщений.
4)Состояние машины
Состояние Mchine — это место, где выполняется код evm, включая счетчик программ, стек и память.
5)Хранение
Хранилище — это постоянное хранилище, доступное для чтения, записи и изменения. Это также место, где каждый контракт постоянно хранит данные. Хранилище представляет собой огромную карту с 2256 слотами, каждый слот имеет 32 байта.
6) Используйте BTC в качестве комиссии за газ.
Хранилище — это постоянное хранилище, доступное для чтения, записи и изменения. Это также место, где каждый контракт постоянно хранит данные. Хранилище представляет собой огромную карту с 2256 слотами, каждый слот имеет 32 байта.
6) Используйте BTC в качестве комиссии за газ.
Пусть BTC, переведенный из сети Биткойн, будет использоваться в качестве валюты расчета комиссии за газ для выполнения транзакции на EVM.
Все комментарии