З моменту появи BTC у 2009 році Bitcoin пройшов три технічні ітерації та еволюціонував від простої концепції цифрових нативних активів до децентралізованої фінансової системи зі складними функціями та додатками.
Ця стаття написана засновником BEVM**, який ділиться своїми думками про еволюцію технології BTC, а також докладно відповідає на те, як BEVM, яка є ключовою віхою в розвитку технології BTC Layer 2, може реалізувати майбутнє процвітання децентралізованої екосистеми BTC на технічному рівні. **
У цій статті ви дізнаєтеся більше про:
Необхідність BTC Layer 2
Як досягти рівня BTC 2?
Повністю децентралізоване рішення BEVM
Данина поваги 3 великим революційним технологічним ітераціям BTC з моменту його народження:
2009: Народився BTC, вперше використавши структуру блокчейну для відкриття децентралізованих грошових додатків.
2017: BTC Segregated Witness було оновлено для підтримки сховища до 4 МБ, що вирішило проблему ончейн-сховища BTC. Це також дає основу для протоколу Ordinals (видача активів).
2021: BTC Taproot був оновлений для підтримки алгоритму порогового підпису BTC, який забезпечує базову підтримку повністю децентралізованої технології BTC Layer2.
По-перше, чому ви хочете зробити BTC Layer2?**
1. Є попит: Мережа Bitcoin задовольняє потреби реєстрації активів, але все ще існує велика кількість активів, за якими потрібно розраховуватися в ланцюжку (рівень 2)
В даний час рівень 2 ETH є лише копією рівня ETH 1, і немає нічого, що рівень 1 не може вирішити, крім реальних бізнес-проблем, які повинен вирішити рівень 2.
Слід сказати, що ETH Layer 2 вирішує проблему ETH Layer 1: Layer 2 вирішує проблему дорогого газу Layer 1. Саме завдяки цьому попиту було досягнуто першого застосування деривативів ETH на Layer2 Arbitrum, таких як GMX.
І рівень 2 BTC не такий неактуальний, як рівень 2 ETH.
Оскільки віртуальна віртуальна машина BTC, яка не повна за Тюрінгом, може реєструвати лише активи, але не може здійснювати розрахунки, BTC рівня 1 повинен потребувати BTC-рівня 2, завершеного Тюрінгом, для розрахунків за активами, випущеними BTC рівня 1.
2.Можливості: BTC можна перетворити на повністю децентралізований рівень 2
До оновлення BTC Taproot у 2021 році було неможливо досягти повністю децентралізованого рівня BTC 2. Однак після цього оновлення алгоритм порогового підпису BTC дозволяє BTC підтримувати повністю децентралізований обчислювальний рівень Layer2.
II.Як досягти децентралізованого BTC L2?
Пропозиції щодо покращення Біткойн (BIP) – це проектні документи, які представляють нові функції та інформацію для Біткойн, тоді як оновлення taproot є компіляцією трьох BIP, а саме Schnorr Signature (BIP 340), Taproot (BIP 341) та Tap (BIP 342), разом відомих як BIP Taproot.
Це принесе більш ефективний, гнучкий і приватний спосіб передачі біткойнів за допомогою підписів Шнорра і абстрактних синтаксичних дерев Меркель.
Підписи Шнорра – це схема цифрового підпису, відома своєю простотою та безпекою. Підписи Schnoor мають кілька переваг з точки зору обчислювальної ефективності, зберігання та конфіденційності.
! [Засновник 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, в якому кожен вузол генерує незалежний цифровий підпис з власним закритим ключем для блокових даних і транслює його іншим вузлам. Інший вузол перевіряє сигнатуру та записує її до наступного фрагмента даних.
Таким чином, коли кількість вузлів консенсусу велика, сигнатурні дані, що зберігаються в кожному раунді блоків консенсусу, продовжуватимуть збільшуватися, займаючи місце для зберігання.
Щоразу, коли новий вузол приєднується до мережі та потребує синхронізації історичних блоків, велика кількість сигнатурних даних становитиме велику проблему для пропускної здатності мережі.
Після використання технології агрегованого підпису кожен вузол збирає агреговані візитні картки підписів, що транслюються іншими вузлами, а потім зберігає агрегат шардів підпису, як показано на рисунку 2.**
Таким чином, при приєднанні нового вузла блоку історії синхронізації потрібно лише завантажити агреговані дані підпису, що значно зменшує зайнятість пропускної здатності мережі та зменшує витрати комісій за транзакції.
Крім того, агрегація ключів робить усі виводи Taproot схожими. Незалежно від того, чи це вихід з мультипідписом, вихід з одним підписом або інші складні смарт-контракти, всі вони виглядають однаково в блокчейні, тому багато аналітики блокчейну будуть недоступні, зберігаючи конфіденційність для всіх користувачів Taproot. **
! [Засновник BEVM: Навіщо і як робити BTC Layer2?] (https://cdn-img.panewslab.com//panews/2022/11/11/images/187dbc4fe20ec85e558eb12132a2a850.)
MAST (Merkle Abstract Syntax Tree) — це серія скриптів, що не перетинаються (наприклад, мультипідпис або timelock), які використовують дерево Меркла для шифрування складних скриптів блокування.
При витрачанні повинен бути розкритий тільки відповідний скрипт і шлях від цього скрипта до кореня дерева Merck. Як показано на малюнку 3, щоб використовувати 1, вам потрібно лише розкрити 1, 2 та хеш3.
До основних переваг 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. Наше повністю децентралізоване рішення рівня BTC2:
3.1 Легкий вузол BTC + розподілений пороговий контракт підписання
! [Засновник BEVM: Навіщо і як робити BTC Layer2?] (https://cdn-img.panewslab.com//panews/2022/11/11/images/d6ddaf08422a0b02bc25e45cd2f5d947.)
У цій схемі n (n можуть бути всі валідатори на BEVM) фіксовані валідатори вибираються для завершення сукупного контракту зберігання BTC у мережі з розподіленим пороговим підписанням.
Приватний ключ кожного валідатора на рівні BEVM2 також є похідним від частини сукупного закритого ключа порогового підпису BTC, а пороговий закритий ключ n валідаторів об'єднується в загальну фотоадресу підпису BTC. **n може бути до 1000 і більше. **
Коли користувач A хоче передати BTC на BEVM, йому потрібно лише відправити BTC на контракт зберігання агрегації Bitcoin, і користувач може отримати BTC на рівні BEVM2.
Відповідно, коли користувач А виконує операцію виведення коштів, йому потрібно лише взаємодіяти з m автоматично заповненими розподіленими пороговими контрактами підпису в сукупному підписі між n валідаторами, і передача від ескроу-контракту до користувача A може бути завершена на 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?
Автор: Петро
Преамбула
З моменту появи BTC у 2009 році Bitcoin пройшов три технічні ітерації та еволюціонував від простої концепції цифрових нативних активів до децентралізованої фінансової системи зі складними функціями та додатками.
Ця стаття написана засновником BEVM**, який ділиться своїми думками про еволюцію технології BTC, а також докладно відповідає на те, як BEVM, яка є ключовою віхою в розвитку технології BTC Layer 2, може реалізувати майбутнє процвітання децентралізованої екосистеми BTC на технічному рівні. **
У цій статті ви дізнаєтеся більше про:
Необхідність BTC Layer 2
Як досягти рівня BTC 2?
Повністю децентралізоване рішення BEVM
Данина поваги 3 великим революційним технологічним ітераціям BTC з моменту його народження:
2009: Народився BTC, вперше використавши структуру блокчейну для відкриття децентралізованих грошових додатків.
2017: BTC Segregated Witness було оновлено для підтримки сховища до 4 МБ, що вирішило проблему ончейн-сховища BTC. Це також дає основу для протоколу Ordinals (видача активів).
2021: BTC Taproot був оновлений для підтримки алгоритму порогового підпису BTC, який забезпечує базову підтримку повністю децентралізованої технології BTC Layer2.
По-перше, чому ви хочете зробити BTC Layer2?**
1. Є попит: Мережа Bitcoin задовольняє потреби реєстрації активів, але все ще існує велика кількість активів, за якими потрібно розраховуватися в ланцюжку (рівень 2)
В даний час рівень 2 ETH є лише копією рівня ETH 1, і немає нічого, що рівень 1 не може вирішити, крім реальних бізнес-проблем, які повинен вирішити рівень 2.
Слід сказати, що ETH Layer 2 вирішує проблему ETH Layer 1: Layer 2 вирішує проблему дорогого газу Layer 1. Саме завдяки цьому попиту було досягнуто першого застосування деривативів ETH на Layer2 Arbitrum, таких як GMX.
І рівень 2 BTC не такий неактуальний, як рівень 2 ETH.
Оскільки віртуальна віртуальна машина BTC, яка не повна за Тюрінгом, може реєструвати лише активи, але не може здійснювати розрахунки, BTC рівня 1 повинен потребувати BTC-рівня 2, завершеного Тюрінгом, для розрахунків за активами, випущеними BTC рівня 1.
2.Можливості: BTC можна перетворити на повністю децентралізований рівень 2
До оновлення BTC Taproot у 2021 році було неможливо досягти повністю децентралізованого рівня BTC 2. Однак після цього оновлення алгоритм порогового підпису BTC дозволяє BTC підтримувати повністю децентралізований обчислювальний рівень Layer2.
II.Як досягти децентралізованого BTC L2?
Пропозиції щодо покращення Біткойн (BIP) – це проектні документи, які представляють нові функції та інформацію для Біткойн, тоді як оновлення taproot є компіляцією трьох BIP, а саме Schnorr Signature (BIP 340), Taproot (BIP 341) та Tap (BIP 342), разом відомих як BIP Taproot.
Це принесе більш ефективний, гнучкий і приватний спосіб передачі біткойнів за допомогою підписів Шнорра і абстрактних синтаксичних дерев Меркель.
Підписи Шнорра – це схема цифрового підпису, відома своєю простотою та безпекою. Підписи Schnoor мають кілька переваг з точки зору обчислювальної ефективності, зберігання та конфіденційності.
! [Засновник 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, в якому кожен вузол генерує незалежний цифровий підпис з власним закритим ключем для блокових даних і транслює його іншим вузлам. Інший вузол перевіряє сигнатуру та записує її до наступного фрагмента даних.
Таким чином, коли кількість вузлів консенсусу велика, сигнатурні дані, що зберігаються в кожному раунді блоків консенсусу, продовжуватимуть збільшуватися, займаючи місце для зберігання.
Щоразу, коли новий вузол приєднується до мережі та потребує синхронізації історичних блоків, велика кількість сигнатурних даних становитиме велику проблему для пропускної здатності мережі.
Після використання технології агрегованого підпису кожен вузол збирає агреговані візитні картки підписів, що транслюються іншими вузлами, а потім зберігає агрегат шардів підпису, як показано на рисунку 2.**
Таким чином, при приєднанні нового вузла блоку історії синхронізації потрібно лише завантажити агреговані дані підпису, що значно зменшує зайнятість пропускної здатності мережі та зменшує витрати комісій за транзакції.
Крім того, агрегація ключів робить усі виводи Taproot схожими. Незалежно від того, чи це вихід з мультипідписом, вихід з одним підписом або інші складні смарт-контракти, всі вони виглядають однаково в блокчейні, тому багато аналітики блокчейну будуть недоступні, зберігаючи конфіденційність для всіх користувачів Taproot. **
! [Засновник BEVM: Навіщо і як робити BTC Layer2?] (https://cdn-img.panewslab.com//panews/2022/11/11/images/187dbc4fe20ec85e558eb12132a2a850.)
MAST (Merkle Abstract Syntax Tree) — це серія скриптів, що не перетинаються (наприклад, мультипідпис або timelock), які використовують дерево Меркла для шифрування складних скриптів блокування.
При витрачанні повинен бути розкритий тільки відповідний скрипт і шлях від цього скрипта до кореня дерева Merck. Як показано на малюнку 3, щоб використовувати 1, вам потрібно лише розкрити 1, 2 та хеш3.
До основних переваг 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. Наше повністю децентралізоване рішення рівня BTC2:
3.1 Легкий вузол BTC + розподілений пороговий контракт підписання
! [Засновник BEVM: Навіщо і як робити BTC Layer2?] (https://cdn-img.panewslab.com//panews/2022/11/11/images/d6ddaf08422a0b02bc25e45cd2f5d947.)
У цій схемі n (n можуть бути всі валідатори на BEVM) фіксовані валідатори вибираються для завершення сукупного контракту зберігання BTC у мережі з розподіленим пороговим підписанням.
Приватний ключ кожного валідатора на рівні BEVM2 також є похідним від частини сукупного закритого ключа порогового підпису BTC, а пороговий закритий ключ n валідаторів об'єднується в загальну фотоадресу підпису BTC. **n може бути до 1000 і більше. **
Коли користувач A хоче передати BTC на BEVM, йому потрібно лише відправити BTC на контракт зберігання агрегації Bitcoin, і користувач може отримати BTC на рівні BEVM2.
Відповідно, коли користувач А виконує операцію виведення коштів, йому потрібно лише взаємодіяти з m автоматично заповненими розподіленими пороговими контрактами підпису в сукупному підписі між n валідаторами, і передача від ескроу-контракту до користувача A може бути завершена на 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.