(Джерело: companiesmarketcap)
Біткойн, створений у 2008 році анонімним розробником, перетворився на великий актив, що посідає 7 місце за капіталізацією на ринку серед всіх класів активів. Тепер його визнали не лише фінансові установи, а й навіть президент США. На сьогоднішній день капіталізація ринку біткойну схожа на срібло. З урахуванням того, що прийняття біткойну все ще відносно низьке і його капіталізація ринку лише десята частина від золота, його потенціал майбутнього зростання залишається дуже перспективним.
Незважаючи на величезний ріст Bitcoin як активу, все ще існує значна недолік — його рівень використання. Традиційні активи, такі як акції та облігації, можуть бути використані в широкому спектрі фінансових продуктів, але фінансові застосування Bitcoin все ще дуже обмежені як технічно, так і практично. Подібно до днів підкорення Дикого Заходу Америки, Bitcoin представляє собою неосвоєну землю можливостей.
Через його великий ринковий капіталізації, численні компанії та протоколи намагалися використовувати Bitcoin для додаткового кредитного створення. Основні спроби використання BTC наразі включають:
Дослідження цих спроб використання BTC показує загальну проблему - важко використовувати Bitcoin в рідкісних випадках. Однією з найбільших переваг Bitcoin є його безпека, але якщо додаткові припущення про довіру підірвати цю безпеку, це створює значний бар'єр для власників BTC. Це основна причина, чому рівень використання Bitcoin залишається відносно низьким.
Це те місце, де@babylonlabs_ioзосереджується на. Babylon дозволяє власникам BTC ставити свій біткойн нативно на біткойн-мережі та брати участь у підтвердженні інших протоколів PoS, отримуючи додаткові винагороди.
Благодаря перевагам використання BTC без додаткових припущень про довіру, Babylon швидко досягла понад 5 мільярдів доларів обсягу заблокованого капіталу (TVL). TVL міг би бути ще вищим, якби не було обмежень на стейкінг BTC.
Проте зачекайте, мова сценаріїв Bitcoin не є повною, що означає, що вона не може легко підтримувати складні смарт-контракти. Так яким чином Вавилону вдається досягти цієї функціональності? У цій статті ми розглянемо конкретні механізми роботи Вавилона.
Насправді досягти справжнього використання BTC мовою, як будова Вавилонської вежі?
Місія Вавилона - масштабування Bitcoin для забезпечення децентралізованого світу. Хоча відомо, що Вавилон - це протокол стейкінгу BTC, він також пропонує послуги міткоріння Bitcoin, утворюючи набір протоколів безпеки BTC.
Вавилон складається з двох основних протоколів:
(Джерело: Вавилон)
Основна архітектура Вавилона показана на діаграмі вище, з Вавилонським Ланцюгом, побудованим на Cosmos SDK, в його основі. Крім Вавилонського Ланцюга, декілька периферійних програм допомагають в стейкингу BTC та спілкуванні з Bitcoin та іншими Консумерськими Зонами. Консумерські Зони відносяться до ланцюгів PoS, які фіксують контрольні точки в мережі Bitcoin через Вавилон.
Ланцюг Вавилона складається з різних модулів, які виконують важливі функції в екосистемі, включаючи керування набором валідаторів, відстеження заголовків блоків Bitcoin, надсилання контрольних точок в мережу Bitcoin та управління активним набором постійності, пов'язаним з BTC стейкінгом. Для посилання, постійний постачальник подібний до оператора AVS в EigenLayer, що означає, що він бере участь в перевірці інших протоколів PoS.
Крім того, Вавилон впровадив кілька допоміжних програм для сприяння плавній комунікації між мережею Bitcoin та Ланцюгом Вавилону:
Через цю екосистему Babylon дозволяє криптовалютній галузі використовувати міцну безпеку та глибоку ліквідність Bitcoin. Тепер давайте детальніше розглянемо дві основні функції Babylon: Bitcoin Timestamping та Bitcoin Staking.
Будь-хто, хто коли-небудь ставив токени раніше, знає, що відв'язування зазвичай потребує період очікування від 1 до 2 тижнів. Протягом цього часу токени не можуть бути використані або приносити відсотки, що викликає неефективність. Але чому відв'язування потребує період очікування? Чому не дозволити миттєві виведення?
Найпростіша причина - це мережева безпека. Якщо зняття коштів було б миттєвим, великі суми токенів могли б бути зняті відповідно до коливань на ринку, що значно підточує мережеву безпеку. Однак, крім безпеки, є ще одна фундаментальна причина: запобігання довготривалим атакам.
(Джерело: AP)
Довготривала атака відноситься до атаки, в якій зловмисні валідатори створюють нову вілку, починаючи з минулих блоків, спробуючи замінити поточний канонічний ланцюг. Якщо зловмисний форкнутий ланцюг стає таким самим або довшим, ніж канонічний ланцюг, внов приєднуючіся вузли в мережі можуть заплутатися, який ланцюг є законним, що призводить до потенційних проблем. Але зачекайте, чи це взагалі можливо?
У мережі PoW довгострокова атака практично неможлива. Щоб наздогнати поточний канонічний ланцюжок, зловмисники повинні б відтворити нові блоки з минулого, перевищуючи обчислювальну потужність існуючої мережі, що практично неможливо.
Так само, в належно функціонуючій мережі PoS такий атака також неможливий. Створення нового відгалуження потребувало би від зловмисних валідаторів підписувати кілька конфліктуючих блоків, що вважається подвійним підписанням—порушенням протоколу, що призводить до штрафів за зниження.
Проте що, якщо розблокування буде дозволено негайно?
У відміну від PoW мереж, мережі PoS не потребують великої обчислювальної потужності для генерації блоків. Це означає, що якщо зловмисні валідатори знімають свої активи з існуючого ланцюжка, а потім створюють новий розгалужений ланцюжок з минулого блоку, де їх ключі валідатора ще були дійсними, вони потенційно можуть наздогнати поточний канонічний ланцюжок. У цьому сценарії нові вузли, що приєднуються до мережі, можуть мати проблеми з визначенням ланцюжка, який є законним, що може призвести до потенційної плутанини та ризиків безпеки.
(Джерело: Вавилон)
Якщо успішний далекобійний напад, зловмисні валідатори можуть зловживати механізмами мостів, щоб вкрасти кошти. Наприклад, припустимо, що зловмисний атакувальник на ім'я Джон переказує 1M токенів RUG з ланцюга RugPull на Osmosis та обмінює їх на токени OSMO. Цей переказ відбувається через IBC, який працює шляхом блокування оригінальних токенів RUG на ланцюгу RugPull, при цьому видаючи еквівалентну кількість токенів RUG на ланцюзі Osmosis.
(Джерело: Вавилон)
Якщо ми припустимо, що Джон успішно виконує дію на велику відстань на ланцюг RugPull, він може злочинно опустити транзакцію, яка заблокувала токени RUG, щоб відправити їх на ланцюг Osmosis в новому відгалуженому ланцюгу. В результаті Джон фактично отримає токени OSMO безкоштовно.
Для запобігання атак на великі відстані необхідний період розблокування стейкінгу певної тривалості. Злоумисники не можуть здійснювати атаку на великій відстані під час періоду розблокування (якщо вони спробують, вони стикнуться з покаранням у вигляді відсікання). Крім того, протягом цього періоду учасники мережі можуть досягти соціальної згоди щодо того, який ланцюжок є канонічним. В результаті, навіть якщо пізніше відбудеться атака на великій відстані, злоумисний відгалужений ланцюжок ймовірно не буде прийнятий мережею.
Період розблокування ставки є ефективним методом запобігання атак з великого відстані, але він має деякі недоліки.
Перше питання полягає в тому, що воно ґрунтується на соціальній згоді для протидії атакам. Хоча поза ланцюжком спілкування між учасниками протягом достатньо довгого періоду може відігравати важливу роль, це не є 100% надійним рішенням.
Друга проблема полягає в тому, що, як зазначено раніше, більший період виведення грошей негативно впливає на досвід користувача та ліквідність.
Babylon вводить рішення під назвою Bitcoin Timestamping, яке дозволяє ланцюгам PoS значно скоротити періоди розблокування до всього кількох годин. Це дозволяє ланцюгам PoS записувати дані канонічних блоків ланцюга в мережу Bitcoin.
З відміткою про час, навіть якщо зловмисні перевіряючі намагаються здійснити атаку на велику відстань і стверджують, що їх відгалужений ланцюг є канонічним ланцюгом, їх атака не вдасться - оскільки початкові дані канонічного ланцюга вже безпечно записані в мережі Bitcoin. Поки безпека Bitcoin залишається недоторканною, атака гарантовано зазнає невдачі. Оскільки цей підхід усуває потребу у соціальній згоді, він дозволяє радикально скоротити необхідний період роз'єднання.
(Джерело: Вавилон)
Тут мітка часу Bitcoin записується за допомогою опкоду OP_RETURN в мережі Bitcoin. OP_RETURN - це інструкція, яка дозволяє зберігати до 80 байтів довільних даних в мережі Bitcoin. На відміну від звичайних транзакцій Bitcoin, OP_RETURN не може використовуватися для переказу коштів і не генерує UTXO.
Одним з ключових моментів є можливість всім ланцюгам PoS прямо створювати контрольні точки в мережі Bitcoin. Блоки Bitcoin мають невеликий розмір, час блоку 10 хвилин, а OP_RETURN може зберігати лише максимум 80 байт даних. Якщо багато ланцюгів PoS почали відправляти часті транзакції контрольних точок, мережа Bitcoin не змогла б впоратися з навантаженням.
Для вирішення цього питання Babylon вводить ланцюг Babylon, який агрегує контрольні точки з кількох ланцюгів PoS через IBC, а потім надсилає одну агреговану контрольну точку в мережу Bitcoin.
Ключовою складовою цього процесу є Vigilante Relayer, сутність, відповідальна за читання контрольних точок з вузла Вавилона, упаковку їх в транзакції OP_RETURN, а потім надсилання їх в мережу Bitcoin. Системі потрібен принаймні один чесний та діючий Vigilante Relayer для належної роботи.
(Джерело: Вавилон)
Часова маркування BTC відбувається наступним чином: ланцюги PoS надсилають контрольні точки, що містять інформацію про блоки, на ланцюг Вавилона. Ланцюг Вавилона потім надсилає контрольну точку блоків Вавилона в мережу Bitcoin на останній блок кожної епохи.
(Джерело: Вавилон)
Навіть якщо відбудеться атака на велику відстань, мітка контрольної точки зловісної розгалуженої ланцюжка завжди матиме пізніший час, ніж мітка контрольної точки канонічного ланцюжка. Це означає, що учасники мережі можуть просто перевірити контрольну точку мережі Bitcoin, щоб легко визначити зловісні розгалуження. Оскільки цей підхід усуває необхідність у соціальній згоді, період розблокування ставки може бути скорочений з кількох тижнів до кількох годин.
Мітка часу Bitcoin від Babylon робить більше, ніж просто покращує UX та ефективність ліквідності шляхом скорочення періодів розблокування PoS-ланцюжків — вона також надає різноманітні додаткові переваги.
З використанням повільної закінченості через Вавилон PoS-ланцюги можуть досягти рівня безпеки, що може бути порівняно з Bitcoin. Коли блок PoS, що містить конкретну транзакцію, має відмітку часу в мережі Bitcoin і підтверджується шістьма блоками Bitcoin, транзакція стає незворотною — за умови, що безпека Bitcoin залишається недоторканою.
Цей механізм корисний для обробки високоцінних транзакцій, таких як покупки нерухомості, де необхідна абсолютна безпека. Крім того, для новостворених зон Cosmos, які можуть мати слабшу безпеку, впровадження повільної остаточності може забезпечити додатковий рівень захисту для безпечної обробки транзакцій.
Мітки Bitcoin також можуть допомогти відновити живість у разі цензурного нападу на ланцюг PoS. Для вирішення цього питання Вавилон вводить спеціальне поняття, яке називається режимом rollup.
У традиційному ланцюгу PoS, принаймні дві третини (2/3) валідаторів повинні бути чесними, щоб забезпечити стійкість до цензури. Однак у режимі rollup Вавилона достатньо лише однієї половини (1/2) валідаторів, які повинні бути чесними, щоб досягти стійкості до цензури, що значно покращує стійкість ланцюга до атак.
(Джерело: Вавилон)
Якщо користувач ланцюга PoS вважає, що конкретну транзакцію цензурять, вони можуть подати скаргу на цензуру (червоний розділ на діаграмі) до ланцюга Вавилона, ініціюючи процес входу в режим rollup. Скарга на цензуру містить хеш цензурної транзакції.
Якщо після шести підтверджень блоків Bitcoin підозрювана цензурована транзакція все ще не була включена в ланцюг PoS, чесні валідатори надсилають свої погляди на ланцюг PoS в Вавилон. Якщо після додаткових шести підтверджень блоків Bitcoin в жодному блоку Bitcoin не виявлено жодного контрольного пункту, пов'язаного з цензурованою транзакцією, чесні валідатори та користувачі перейдуть в режим rollup.
У режимі rollup будь-який валідатор може запропонувати пакет транзакцій PoS, і якщо валідатори, що володіють принаймні однією половиною (1/2) від загальної кількості стейку, підписують пакет, транзакція буде завершена в мережі Bitcoin, ефективно запобігаючи цензурі.
Мітка часу Bitcoin дозволяє ланцюгам PoS використовувати безпеку Bitcoin для скорочення періодів розблокування стейку та покращення стійкості до цензури, але це використовується лише частково безпекою Bitcoin.
Поза Bitcoin Timestamping, Вавилон вводить Bitcoin Staking, який нативно реалізує стейкінг BTC за допомогою мови сценаріїв Bitcoin. Це дозволяє іншим протоколам PoS скористатися криптоекономічною безпекою стейкнутого BTC. Протокол стейкінгу розроблений як модульний плагін, що робить його легко адаптованим для різних протоколів згоди PoS.
Для власників BTC, Bitcoin Staking від Babylon - це приваблива інвестиційна можливість, оскільки вони можуть ставити BTC на рівні безпеки Bitcoin без покладання на зовнішні суб'єкти, отримуючи винагороду від зовнішніх протоколів.
Давайте визначимо деякі ключові терміни:
Проте зачекайте — на відміну від Ethereum, мережа Bitcoin не є тьюринг-повною, що ускладнює впровадження складних контрактів на стейкінг. Як же Бабилон це досягає?
Давайте розглянемо деталі на прикладі з блогу Babylon.
// Контракт V0: додавання умови блокування ставки Аліси до UTXO
умова-1 (блокування): time_lock = 1000 & alice_public_key
Давайте припустимо, що Аліса ставить BTC і також виступає як постачальник фінальності. Для впровадження ставки на BTC потрібен механізм блокування BTC. Це досягається шляхом налаштування однієї з умов витрат UTXO так, щоб лише Аліса (власник BTC) могла вивести кошти після певного періоду часу (time_lock = 1000), використовуючи її alice_public_key.
// Контракт V1: додавання наївного зниження
умова-1 (блокування): time_lock = 1000 & alice_public_key; OR
умова-2 (зниження): alice_eots_public_key
Одним із важливих компонентів, який повинен бути впроваджений у стейкінгу, є стриження. Якщо виникає злочинна дія, може бути застосований стимулюючий механізм шляхом спалювання стейкованого BTC. Для досягнення цього встановлюється другий умова витрати UTXO, щоб стриження могло відбутися, якщо хтось утримує ключ EOTS Аліси.
Тут, EOTS (Extractable One-Time Signature) - це підпис, реалізований за допомогою підписів Шнорра, який був запроваджений після оновлення Taproot в Bitcoin. Просто кажучи, це алгоритм, який гарантує, що якщо зловмисник підписує два різні блоки на одній висоті за допомогою того самого ключа, їх секретний ключ стає публічно відомим.
Розглянувши це докладніше, підпис Schnorr складається з приватного ключа x, публічного ключа P=xG та випадкового числа k. Процес підпису виглядає наступним чином: генерується випадкове число k, а з нього обчислюється публічне значення R=kG. Потім з повідомлення M та R обчислюється хеш-значення e, а значення підпису s обчислюється на основі числа-випадкового числа та e, де s = k + ex. Остаточний підпис Schnorr складається з (s, R).
Основна ідея EOTS полягає в тому, що якщо один і той самий ключ використовується двічі для підпису, то приватний ключ викритий. Якщо Аліса підписує два різні повідомлення, використовуючи той самий одноразовий параметр k, то перший підпис - s1= k + e_1x, а другий підпис - s2= k + e_2x. Оскільки s1, s2, e1, e2 відомі публічно, будь-хто може вирішити приватний ключ x Аліси, використовуючи рівняння x=(s1 - s2)/(e1 - e2).
Використовуючи цей механізм, якщо Еліс підло підписує дві різні повідомлення за допомогою одного ЄОТС ключа під час процесу валідації BSN, будь-хто, хто виявить це, може витягнути секретний ключ ЕОТС Еліс. Як тільки секретний ключ EOTS розкритий, зловмисник може вкрасти заставлені BTC Еліс або спалити заставлені BTC Еліс як покарання.
// Контракт V2
умова-1 (блокування): time_lock = 1000 & alice_public_key; OR
умова-2 (відсікання): alice_eots_public_key & covenant_committee_quorum
// Різання транзакції V0
введення:
виведення:
0000...0000
// Попереднє схвалення V0: зміцнення знищення
// Комітет зобов'язань попередньо підписує вищезазначену транзакцію на зниження як попередню затвердження
Оскільки ми вже обговорили умови, за яких відбувається стрижка, давайте зараз розглянемо, як вона фактично застосовується. Застосування стрижки є важливим, оскільки, якщо Еліс займається злочинною поведінкою, вона може спробувати зняти свої BTC, перш ніж хтось виявить порушення, витягне її секретний ключ EOTS та спалить її BTC.
Щоб цього уникнути, зниження повинно бути реалізовано таким чином, щоб примусово переводити BTC на передбачену заздалегідь адресу спалювання (0000…0000). Для досягнення цього умова витрачання другого UTXO включає Комітет договору. Комітет договору відповідальний за перевірку легітимності зниження. Шляхом включення схеми багато-підписового (M-of-N) у системі забезпечується, що Аліса не може односторонньо зняти свої BTC на свій власний гаманець до виконання зниження.
Перевага такого підходу полягає в тому, що, якщо Еліс веде себе чесно, її підпис EOTS ніколи не викривається, що означає, що Комітет Пактів не може захопити її кошти. Тому Еліс не потрібно довіряти Комітету Пактів, оскільки вони не можуть діяти проти неї, якщо вона не здійснює злочинну поведінку.
// Контракт V3: увімкнення безпечного доручення
умова-1 (блокування): time_lock = 1000 & alice_public_key; OR
умова-2 (зниження): alice_public_key & validator_eots_public_key & covenant_committee_quorum
// Зниження транзакції V0
входи:
виведення:
0000...0000
// Попереднє схвалення V1
// Еліс попередньо підписує транзакцію стриження як попередню схвалення.
// Комітет по угодам попередньо підписує транзакцію на зниження, як попередню затвердження.
Аліса може безпосередньо ставити в заставу BTC та брати участь у підтвердженні інших протоколів PoS як постачальник остаточності. Однак більшість користувачів виберуть делегувати свої BTC.
Для реалізації цього, додавання ключа EOTS валідатора до другої умови забезпечує, що у випадку зловживання валідатором Алісів BTC може бути спалено. Однак проблема полягає в тому, що якщо валідатор узгоджується з комітетом угоди, вони можуть вкрасти BTC Аліси, змушуючи Алісу довіряти валідатору.
Простим рішенням цієї проблеми є також включення відкритого ключа Еліс у другому умові. Таким чином, спалювання BTC також вимагатиме підпис Еліс, запобігаючи несанкціоновані крадіжки BTC.
Для досягнення цього Аліса попередньо підписує транзакцію, в якій заявляє, що "якщо відбудеться стрижка, BTC повинні бути відправлені на адресу згорання." У цьому випадку, якщо валідатор діє зловмисно, а їхній ключ EOTS викритий, і якщо комітет договору виконує багатопідпис, BTC буде відправлено на адресу згорання, зміцнюючи процес стрижки.
/ Контракт V3
умова-1 (блокування): time_lock = 1000 & alice_public_key; OR
умова-2 (зниження): alice_public_key & validator_eots_public_key & covenant_committee_quorum
// Зниження транзакції V0
вхідні дані:
виводить:
0000...0000
// Попереднє затвердження V2: зміцнення атомного зниження при делегуванні
Попереднє схвалення Аліси – це підпис адаптера косого передавача
// вона згенерувала за допомогою публічного ключа EOTS валідатора.
Комітет Ковенанту попередньо підписує різання як своє попереднє затвердження.
Що робити, якщо шкідливий валідатор націлений лише на конкретних стейкерів для скорочення? Щоб запобігти цьому, Вавилон вводить адаптивні підписи.
Еліса шифрує свій підпис, використовуючи публічний ключ EOTS валідатора як адаптивний підпис. Якщо валідатор намагається покарати тільки Елісу, вони повинні використовувати свій приватний ключ EOTS. Завдяки природі Адаптивних Підписів, це призведе до викриття приватного ключа EOTS валідатора, знявши будь-яку мотивацію для валідаторів здійснювати злочинну поведінку.
Договір V3
Умова-1 (замикання): time_lock = 1000 & alice_public_key; АБО
умова-2 (відсічення): alice_public_key & validator_eots_public_key & covenant_committee_quorum
// Зниження транзакції V1: увімкнення часткового зниження
вхідні дані:
виведення:
вивід-1: значення = 0.09 Bitcoin, власник = 0000...0000
output-2: значення = 0.9 Bitcoin,
умови:
// Попереднє схвалення V2
// Попередня затвердження Еліс - це підпис адаптера для транзакції стриження
// вона згенерувала за допомогою публічного ключа EOTS валідатора.
// Комітет з обіцянками передбачувано підписує зниження tx як передплату.
Але ви не вважаєте, що спалювання всіх Bitcoin у разі стримування є занадто екстремальним? Для вирішення цього проблеми, можна спалити лише частину Bitcoin (наприклад, спалювати лише 10%, повертаючи решту 90% після певного періоду). Це можна зробити, розділивши виходи угорувальної транзакції на дві, як описано вище.
// Контракт V4: Увімкнення повторного ставлення
Умова-1 (замикання): time_lock = 1000 & alice_public_key; АБО
Умова-2 (коса риска): alice_public_key та будь-який підпис зі списку[validator_eots_public_key] & covenant_committee_quorum
Делегований BTC Аліси може брати участь у підтвердженні кількох протоколів PoS, а не лише одного. Якщо валідатор бере участь у підтвердженні різних протоколів PoS, використовуючи той самий ключ EOTS, будь-який протік в одному місці може вплинути на інші системи. Тому постачальники остаточності в Вавилоні повинні використовувати різні ключі EOTS для різних систем PoS, і список ключів EOTS вводиться в другій умові.
На відміну від PoS мереж, таких як Ethereum або Solana, мережа Bitcoin працює на PoW, тому концепція стейкінгу за своєю суттю не існує. Однак Babylon реалізував функції блокування, зменшення та делегування BTC, необхідні для стейкінгу за допомогою характеристик UTXO, мови сценаріїв Bitcoin та різних алгоритмів підпису. Це дозволяє власникам BTC отримувати додатковий прибуток використовуючи BTC, не потребуючи міст мости або служби опіки.
Окрім Мережі Lightning, жоден інший протокол не повністю успадковує безпеку мережі Bitcoin. Однак, так само, як і мережа Bitcoin, функціональність Мережі Lightning досить обмежена, і важко відмовитися від надійної безпеки та великого ліквідного ресурсу Bitcoin.
Вавилон дозволив використання безпеки біткоїна двома різними способами за допомогою відмітки часу біткоїна та стейкінгу біткоїна. Перше використовує біткоїн як сервер відмітки часу для запобігання відмінних транзакцій або зловмисних відгалужень, тоді як останнє використовує потужну ліквідність BTC як криптоекономічну безпеку, що дозволяє власникам BTC заробляти додатковий прибуток нативним способом.
Наразі в Вавилоні зберігається приблизно 55 000 BTC, що відповідає обмеженню на зберігання, встановленому Вавилоном. Близько 3,9% від загального обсягу ETH повторно ставляться на EigenLayer. Ураховуючи це, навіть якщо власники BTC можуть бути консервативними у використанні BTC, варто розглянути потенціал зростання Вавилону, зі ставкою лише близько 0,2% від загального обсягу BTC, який наразі ставляється.
(Джерело: companiesmarketcap)
Біткойн, створений у 2008 році анонімним розробником, перетворився на великий актив, що посідає 7 місце за капіталізацією на ринку серед всіх класів активів. Тепер його визнали не лише фінансові установи, а й навіть президент США. На сьогоднішній день капіталізація ринку біткойну схожа на срібло. З урахуванням того, що прийняття біткойну все ще відносно низьке і його капіталізація ринку лише десята частина від золота, його потенціал майбутнього зростання залишається дуже перспективним.
Незважаючи на величезний ріст Bitcoin як активу, все ще існує значна недолік — його рівень використання. Традиційні активи, такі як акції та облігації, можуть бути використані в широкому спектрі фінансових продуктів, але фінансові застосування Bitcoin все ще дуже обмежені як технічно, так і практично. Подібно до днів підкорення Дикого Заходу Америки, Bitcoin представляє собою неосвоєну землю можливостей.
Через його великий ринковий капіталізації, численні компанії та протоколи намагалися використовувати Bitcoin для додаткового кредитного створення. Основні спроби використання BTC наразі включають:
Дослідження цих спроб використання BTC показує загальну проблему - важко використовувати Bitcoin в рідкісних випадках. Однією з найбільших переваг Bitcoin є його безпека, але якщо додаткові припущення про довіру підірвати цю безпеку, це створює значний бар'єр для власників BTC. Це основна причина, чому рівень використання Bitcoin залишається відносно низьким.
Це те місце, де@babylonlabs_ioзосереджується на. Babylon дозволяє власникам BTC ставити свій біткойн нативно на біткойн-мережі та брати участь у підтвердженні інших протоколів PoS, отримуючи додаткові винагороди.
Благодаря перевагам використання BTC без додаткових припущень про довіру, Babylon швидко досягла понад 5 мільярдів доларів обсягу заблокованого капіталу (TVL). TVL міг би бути ще вищим, якби не було обмежень на стейкінг BTC.
Проте зачекайте, мова сценаріїв Bitcoin не є повною, що означає, що вона не може легко підтримувати складні смарт-контракти. Так яким чином Вавилону вдається досягти цієї функціональності? У цій статті ми розглянемо конкретні механізми роботи Вавилона.
Насправді досягти справжнього використання BTC мовою, як будова Вавилонської вежі?
Місія Вавилона - масштабування Bitcoin для забезпечення децентралізованого світу. Хоча відомо, що Вавилон - це протокол стейкінгу BTC, він також пропонує послуги міткоріння Bitcoin, утворюючи набір протоколів безпеки BTC.
Вавилон складається з двох основних протоколів:
(Джерело: Вавилон)
Основна архітектура Вавилона показана на діаграмі вище, з Вавилонським Ланцюгом, побудованим на Cosmos SDK, в його основі. Крім Вавилонського Ланцюга, декілька периферійних програм допомагають в стейкингу BTC та спілкуванні з Bitcoin та іншими Консумерськими Зонами. Консумерські Зони відносяться до ланцюгів PoS, які фіксують контрольні точки в мережі Bitcoin через Вавилон.
Ланцюг Вавилона складається з різних модулів, які виконують важливі функції в екосистемі, включаючи керування набором валідаторів, відстеження заголовків блоків Bitcoin, надсилання контрольних точок в мережу Bitcoin та управління активним набором постійності, пов'язаним з BTC стейкінгом. Для посилання, постійний постачальник подібний до оператора AVS в EigenLayer, що означає, що він бере участь в перевірці інших протоколів PoS.
Крім того, Вавилон впровадив кілька допоміжних програм для сприяння плавній комунікації між мережею Bitcoin та Ланцюгом Вавилону:
Через цю екосистему Babylon дозволяє криптовалютній галузі використовувати міцну безпеку та глибоку ліквідність Bitcoin. Тепер давайте детальніше розглянемо дві основні функції Babylon: Bitcoin Timestamping та Bitcoin Staking.
Будь-хто, хто коли-небудь ставив токени раніше, знає, що відв'язування зазвичай потребує період очікування від 1 до 2 тижнів. Протягом цього часу токени не можуть бути використані або приносити відсотки, що викликає неефективність. Але чому відв'язування потребує період очікування? Чому не дозволити миттєві виведення?
Найпростіша причина - це мережева безпека. Якщо зняття коштів було б миттєвим, великі суми токенів могли б бути зняті відповідно до коливань на ринку, що значно підточує мережеву безпеку. Однак, крім безпеки, є ще одна фундаментальна причина: запобігання довготривалим атакам.
(Джерело: AP)
Довготривала атака відноситься до атаки, в якій зловмисні валідатори створюють нову вілку, починаючи з минулих блоків, спробуючи замінити поточний канонічний ланцюг. Якщо зловмисний форкнутий ланцюг стає таким самим або довшим, ніж канонічний ланцюг, внов приєднуючіся вузли в мережі можуть заплутатися, який ланцюг є законним, що призводить до потенційних проблем. Але зачекайте, чи це взагалі можливо?
У мережі PoW довгострокова атака практично неможлива. Щоб наздогнати поточний канонічний ланцюжок, зловмисники повинні б відтворити нові блоки з минулого, перевищуючи обчислювальну потужність існуючої мережі, що практично неможливо.
Так само, в належно функціонуючій мережі PoS такий атака також неможливий. Створення нового відгалуження потребувало би від зловмисних валідаторів підписувати кілька конфліктуючих блоків, що вважається подвійним підписанням—порушенням протоколу, що призводить до штрафів за зниження.
Проте що, якщо розблокування буде дозволено негайно?
У відміну від PoW мереж, мережі PoS не потребують великої обчислювальної потужності для генерації блоків. Це означає, що якщо зловмисні валідатори знімають свої активи з існуючого ланцюжка, а потім створюють новий розгалужений ланцюжок з минулого блоку, де їх ключі валідатора ще були дійсними, вони потенційно можуть наздогнати поточний канонічний ланцюжок. У цьому сценарії нові вузли, що приєднуються до мережі, можуть мати проблеми з визначенням ланцюжка, який є законним, що може призвести до потенційної плутанини та ризиків безпеки.
(Джерело: Вавилон)
Якщо успішний далекобійний напад, зловмисні валідатори можуть зловживати механізмами мостів, щоб вкрасти кошти. Наприклад, припустимо, що зловмисний атакувальник на ім'я Джон переказує 1M токенів RUG з ланцюга RugPull на Osmosis та обмінює їх на токени OSMO. Цей переказ відбувається через IBC, який працює шляхом блокування оригінальних токенів RUG на ланцюгу RugPull, при цьому видаючи еквівалентну кількість токенів RUG на ланцюзі Osmosis.
(Джерело: Вавилон)
Якщо ми припустимо, що Джон успішно виконує дію на велику відстань на ланцюг RugPull, він може злочинно опустити транзакцію, яка заблокувала токени RUG, щоб відправити їх на ланцюг Osmosis в новому відгалуженому ланцюгу. В результаті Джон фактично отримає токени OSMO безкоштовно.
Для запобігання атак на великі відстані необхідний період розблокування стейкінгу певної тривалості. Злоумисники не можуть здійснювати атаку на великій відстані під час періоду розблокування (якщо вони спробують, вони стикнуться з покаранням у вигляді відсікання). Крім того, протягом цього періоду учасники мережі можуть досягти соціальної згоди щодо того, який ланцюжок є канонічним. В результаті, навіть якщо пізніше відбудеться атака на великій відстані, злоумисний відгалужений ланцюжок ймовірно не буде прийнятий мережею.
Період розблокування ставки є ефективним методом запобігання атак з великого відстані, але він має деякі недоліки.
Перше питання полягає в тому, що воно ґрунтується на соціальній згоді для протидії атакам. Хоча поза ланцюжком спілкування між учасниками протягом достатньо довгого періоду може відігравати важливу роль, це не є 100% надійним рішенням.
Друга проблема полягає в тому, що, як зазначено раніше, більший період виведення грошей негативно впливає на досвід користувача та ліквідність.
Babylon вводить рішення під назвою Bitcoin Timestamping, яке дозволяє ланцюгам PoS значно скоротити періоди розблокування до всього кількох годин. Це дозволяє ланцюгам PoS записувати дані канонічних блоків ланцюга в мережу Bitcoin.
З відміткою про час, навіть якщо зловмисні перевіряючі намагаються здійснити атаку на велику відстань і стверджують, що їх відгалужений ланцюг є канонічним ланцюгом, їх атака не вдасться - оскільки початкові дані канонічного ланцюга вже безпечно записані в мережі Bitcoin. Поки безпека Bitcoin залишається недоторканною, атака гарантовано зазнає невдачі. Оскільки цей підхід усуває потребу у соціальній згоді, він дозволяє радикально скоротити необхідний період роз'єднання.
(Джерело: Вавилон)
Тут мітка часу Bitcoin записується за допомогою опкоду OP_RETURN в мережі Bitcoin. OP_RETURN - це інструкція, яка дозволяє зберігати до 80 байтів довільних даних в мережі Bitcoin. На відміну від звичайних транзакцій Bitcoin, OP_RETURN не може використовуватися для переказу коштів і не генерує UTXO.
Одним з ключових моментів є можливість всім ланцюгам PoS прямо створювати контрольні точки в мережі Bitcoin. Блоки Bitcoin мають невеликий розмір, час блоку 10 хвилин, а OP_RETURN може зберігати лише максимум 80 байт даних. Якщо багато ланцюгів PoS почали відправляти часті транзакції контрольних точок, мережа Bitcoin не змогла б впоратися з навантаженням.
Для вирішення цього питання Babylon вводить ланцюг Babylon, який агрегує контрольні точки з кількох ланцюгів PoS через IBC, а потім надсилає одну агреговану контрольну точку в мережу Bitcoin.
Ключовою складовою цього процесу є Vigilante Relayer, сутність, відповідальна за читання контрольних точок з вузла Вавилона, упаковку їх в транзакції OP_RETURN, а потім надсилання їх в мережу Bitcoin. Системі потрібен принаймні один чесний та діючий Vigilante Relayer для належної роботи.
(Джерело: Вавилон)
Часова маркування BTC відбувається наступним чином: ланцюги PoS надсилають контрольні точки, що містять інформацію про блоки, на ланцюг Вавилона. Ланцюг Вавилона потім надсилає контрольну точку блоків Вавилона в мережу Bitcoin на останній блок кожної епохи.
(Джерело: Вавилон)
Навіть якщо відбудеться атака на велику відстань, мітка контрольної точки зловісної розгалуженої ланцюжка завжди матиме пізніший час, ніж мітка контрольної точки канонічного ланцюжка. Це означає, що учасники мережі можуть просто перевірити контрольну точку мережі Bitcoin, щоб легко визначити зловісні розгалуження. Оскільки цей підхід усуває необхідність у соціальній згоді, період розблокування ставки може бути скорочений з кількох тижнів до кількох годин.
Мітка часу Bitcoin від Babylon робить більше, ніж просто покращує UX та ефективність ліквідності шляхом скорочення періодів розблокування PoS-ланцюжків — вона також надає різноманітні додаткові переваги.
З використанням повільної закінченості через Вавилон PoS-ланцюги можуть досягти рівня безпеки, що може бути порівняно з Bitcoin. Коли блок PoS, що містить конкретну транзакцію, має відмітку часу в мережі Bitcoin і підтверджується шістьма блоками Bitcoin, транзакція стає незворотною — за умови, що безпека Bitcoin залишається недоторканою.
Цей механізм корисний для обробки високоцінних транзакцій, таких як покупки нерухомості, де необхідна абсолютна безпека. Крім того, для новостворених зон Cosmos, які можуть мати слабшу безпеку, впровадження повільної остаточності може забезпечити додатковий рівень захисту для безпечної обробки транзакцій.
Мітки Bitcoin також можуть допомогти відновити живість у разі цензурного нападу на ланцюг PoS. Для вирішення цього питання Вавилон вводить спеціальне поняття, яке називається режимом rollup.
У традиційному ланцюгу PoS, принаймні дві третини (2/3) валідаторів повинні бути чесними, щоб забезпечити стійкість до цензури. Однак у режимі rollup Вавилона достатньо лише однієї половини (1/2) валідаторів, які повинні бути чесними, щоб досягти стійкості до цензури, що значно покращує стійкість ланцюга до атак.
(Джерело: Вавилон)
Якщо користувач ланцюга PoS вважає, що конкретну транзакцію цензурять, вони можуть подати скаргу на цензуру (червоний розділ на діаграмі) до ланцюга Вавилона, ініціюючи процес входу в режим rollup. Скарга на цензуру містить хеш цензурної транзакції.
Якщо після шести підтверджень блоків Bitcoin підозрювана цензурована транзакція все ще не була включена в ланцюг PoS, чесні валідатори надсилають свої погляди на ланцюг PoS в Вавилон. Якщо після додаткових шести підтверджень блоків Bitcoin в жодному блоку Bitcoin не виявлено жодного контрольного пункту, пов'язаного з цензурованою транзакцією, чесні валідатори та користувачі перейдуть в режим rollup.
У режимі rollup будь-який валідатор може запропонувати пакет транзакцій PoS, і якщо валідатори, що володіють принаймні однією половиною (1/2) від загальної кількості стейку, підписують пакет, транзакція буде завершена в мережі Bitcoin, ефективно запобігаючи цензурі.
Мітка часу Bitcoin дозволяє ланцюгам PoS використовувати безпеку Bitcoin для скорочення періодів розблокування стейку та покращення стійкості до цензури, але це використовується лише частково безпекою Bitcoin.
Поза Bitcoin Timestamping, Вавилон вводить Bitcoin Staking, який нативно реалізує стейкінг BTC за допомогою мови сценаріїв Bitcoin. Це дозволяє іншим протоколам PoS скористатися криптоекономічною безпекою стейкнутого BTC. Протокол стейкінгу розроблений як модульний плагін, що робить його легко адаптованим для різних протоколів згоди PoS.
Для власників BTC, Bitcoin Staking від Babylon - це приваблива інвестиційна можливість, оскільки вони можуть ставити BTC на рівні безпеки Bitcoin без покладання на зовнішні суб'єкти, отримуючи винагороду від зовнішніх протоколів.
Давайте визначимо деякі ключові терміни:
Проте зачекайте — на відміну від Ethereum, мережа Bitcoin не є тьюринг-повною, що ускладнює впровадження складних контрактів на стейкінг. Як же Бабилон це досягає?
Давайте розглянемо деталі на прикладі з блогу Babylon.
// Контракт V0: додавання умови блокування ставки Аліси до UTXO
умова-1 (блокування): time_lock = 1000 & alice_public_key
Давайте припустимо, що Аліса ставить BTC і також виступає як постачальник фінальності. Для впровадження ставки на BTC потрібен механізм блокування BTC. Це досягається шляхом налаштування однієї з умов витрат UTXO так, щоб лише Аліса (власник BTC) могла вивести кошти після певного періоду часу (time_lock = 1000), використовуючи її alice_public_key.
// Контракт V1: додавання наївного зниження
умова-1 (блокування): time_lock = 1000 & alice_public_key; OR
умова-2 (зниження): alice_eots_public_key
Одним із важливих компонентів, який повинен бути впроваджений у стейкінгу, є стриження. Якщо виникає злочинна дія, може бути застосований стимулюючий механізм шляхом спалювання стейкованого BTC. Для досягнення цього встановлюється другий умова витрати UTXO, щоб стриження могло відбутися, якщо хтось утримує ключ EOTS Аліси.
Тут, EOTS (Extractable One-Time Signature) - це підпис, реалізований за допомогою підписів Шнорра, який був запроваджений після оновлення Taproot в Bitcoin. Просто кажучи, це алгоритм, який гарантує, що якщо зловмисник підписує два різні блоки на одній висоті за допомогою того самого ключа, їх секретний ключ стає публічно відомим.
Розглянувши це докладніше, підпис Schnorr складається з приватного ключа x, публічного ключа P=xG та випадкового числа k. Процес підпису виглядає наступним чином: генерується випадкове число k, а з нього обчислюється публічне значення R=kG. Потім з повідомлення M та R обчислюється хеш-значення e, а значення підпису s обчислюється на основі числа-випадкового числа та e, де s = k + ex. Остаточний підпис Schnorr складається з (s, R).
Основна ідея EOTS полягає в тому, що якщо один і той самий ключ використовується двічі для підпису, то приватний ключ викритий. Якщо Аліса підписує два різні повідомлення, використовуючи той самий одноразовий параметр k, то перший підпис - s1= k + e_1x, а другий підпис - s2= k + e_2x. Оскільки s1, s2, e1, e2 відомі публічно, будь-хто може вирішити приватний ключ x Аліси, використовуючи рівняння x=(s1 - s2)/(e1 - e2).
Використовуючи цей механізм, якщо Еліс підло підписує дві різні повідомлення за допомогою одного ЄОТС ключа під час процесу валідації BSN, будь-хто, хто виявить це, може витягнути секретний ключ ЕОТС Еліс. Як тільки секретний ключ EOTS розкритий, зловмисник може вкрасти заставлені BTC Еліс або спалити заставлені BTC Еліс як покарання.
// Контракт V2
умова-1 (блокування): time_lock = 1000 & alice_public_key; OR
умова-2 (відсікання): alice_eots_public_key & covenant_committee_quorum
// Різання транзакції V0
введення:
виведення:
0000...0000
// Попереднє схвалення V0: зміцнення знищення
// Комітет зобов'язань попередньо підписує вищезазначену транзакцію на зниження як попередню затвердження
Оскільки ми вже обговорили умови, за яких відбувається стрижка, давайте зараз розглянемо, як вона фактично застосовується. Застосування стрижки є важливим, оскільки, якщо Еліс займається злочинною поведінкою, вона може спробувати зняти свої BTC, перш ніж хтось виявить порушення, витягне її секретний ключ EOTS та спалить її BTC.
Щоб цього уникнути, зниження повинно бути реалізовано таким чином, щоб примусово переводити BTC на передбачену заздалегідь адресу спалювання (0000…0000). Для досягнення цього умова витрачання другого UTXO включає Комітет договору. Комітет договору відповідальний за перевірку легітимності зниження. Шляхом включення схеми багато-підписового (M-of-N) у системі забезпечується, що Аліса не може односторонньо зняти свої BTC на свій власний гаманець до виконання зниження.
Перевага такого підходу полягає в тому, що, якщо Еліс веде себе чесно, її підпис EOTS ніколи не викривається, що означає, що Комітет Пактів не може захопити її кошти. Тому Еліс не потрібно довіряти Комітету Пактів, оскільки вони не можуть діяти проти неї, якщо вона не здійснює злочинну поведінку.
// Контракт V3: увімкнення безпечного доручення
умова-1 (блокування): time_lock = 1000 & alice_public_key; OR
умова-2 (зниження): alice_public_key & validator_eots_public_key & covenant_committee_quorum
// Зниження транзакції V0
входи:
виведення:
0000...0000
// Попереднє схвалення V1
// Еліс попередньо підписує транзакцію стриження як попередню схвалення.
// Комітет по угодам попередньо підписує транзакцію на зниження, як попередню затвердження.
Аліса може безпосередньо ставити в заставу BTC та брати участь у підтвердженні інших протоколів PoS як постачальник остаточності. Однак більшість користувачів виберуть делегувати свої BTC.
Для реалізації цього, додавання ключа EOTS валідатора до другої умови забезпечує, що у випадку зловживання валідатором Алісів BTC може бути спалено. Однак проблема полягає в тому, що якщо валідатор узгоджується з комітетом угоди, вони можуть вкрасти BTC Аліси, змушуючи Алісу довіряти валідатору.
Простим рішенням цієї проблеми є також включення відкритого ключа Еліс у другому умові. Таким чином, спалювання BTC також вимагатиме підпис Еліс, запобігаючи несанкціоновані крадіжки BTC.
Для досягнення цього Аліса попередньо підписує транзакцію, в якій заявляє, що "якщо відбудеться стрижка, BTC повинні бути відправлені на адресу згорання." У цьому випадку, якщо валідатор діє зловмисно, а їхній ключ EOTS викритий, і якщо комітет договору виконує багатопідпис, BTC буде відправлено на адресу згорання, зміцнюючи процес стрижки.
/ Контракт V3
умова-1 (блокування): time_lock = 1000 & alice_public_key; OR
умова-2 (зниження): alice_public_key & validator_eots_public_key & covenant_committee_quorum
// Зниження транзакції V0
вхідні дані:
виводить:
0000...0000
// Попереднє затвердження V2: зміцнення атомного зниження при делегуванні
Попереднє схвалення Аліси – це підпис адаптера косого передавача
// вона згенерувала за допомогою публічного ключа EOTS валідатора.
Комітет Ковенанту попередньо підписує різання як своє попереднє затвердження.
Що робити, якщо шкідливий валідатор націлений лише на конкретних стейкерів для скорочення? Щоб запобігти цьому, Вавилон вводить адаптивні підписи.
Еліса шифрує свій підпис, використовуючи публічний ключ EOTS валідатора як адаптивний підпис. Якщо валідатор намагається покарати тільки Елісу, вони повинні використовувати свій приватний ключ EOTS. Завдяки природі Адаптивних Підписів, це призведе до викриття приватного ключа EOTS валідатора, знявши будь-яку мотивацію для валідаторів здійснювати злочинну поведінку.
Договір V3
Умова-1 (замикання): time_lock = 1000 & alice_public_key; АБО
умова-2 (відсічення): alice_public_key & validator_eots_public_key & covenant_committee_quorum
// Зниження транзакції V1: увімкнення часткового зниження
вхідні дані:
виведення:
вивід-1: значення = 0.09 Bitcoin, власник = 0000...0000
output-2: значення = 0.9 Bitcoin,
умови:
// Попереднє схвалення V2
// Попередня затвердження Еліс - це підпис адаптера для транзакції стриження
// вона згенерувала за допомогою публічного ключа EOTS валідатора.
// Комітет з обіцянками передбачувано підписує зниження tx як передплату.
Але ви не вважаєте, що спалювання всіх Bitcoin у разі стримування є занадто екстремальним? Для вирішення цього проблеми, можна спалити лише частину Bitcoin (наприклад, спалювати лише 10%, повертаючи решту 90% після певного періоду). Це можна зробити, розділивши виходи угорувальної транзакції на дві, як описано вище.
// Контракт V4: Увімкнення повторного ставлення
Умова-1 (замикання): time_lock = 1000 & alice_public_key; АБО
Умова-2 (коса риска): alice_public_key та будь-який підпис зі списку[validator_eots_public_key] & covenant_committee_quorum
Делегований BTC Аліси може брати участь у підтвердженні кількох протоколів PoS, а не лише одного. Якщо валідатор бере участь у підтвердженні різних протоколів PoS, використовуючи той самий ключ EOTS, будь-який протік в одному місці може вплинути на інші системи. Тому постачальники остаточності в Вавилоні повинні використовувати різні ключі EOTS для різних систем PoS, і список ключів EOTS вводиться в другій умові.
На відміну від PoS мереж, таких як Ethereum або Solana, мережа Bitcoin працює на PoW, тому концепція стейкінгу за своєю суттю не існує. Однак Babylon реалізував функції блокування, зменшення та делегування BTC, необхідні для стейкінгу за допомогою характеристик UTXO, мови сценаріїв Bitcoin та різних алгоритмів підпису. Це дозволяє власникам BTC отримувати додатковий прибуток використовуючи BTC, не потребуючи міст мости або служби опіки.
Окрім Мережі Lightning, жоден інший протокол не повністю успадковує безпеку мережі Bitcoin. Однак, так само, як і мережа Bitcoin, функціональність Мережі Lightning досить обмежена, і важко відмовитися від надійної безпеки та великого ліквідного ресурсу Bitcoin.
Вавилон дозволив використання безпеки біткоїна двома різними способами за допомогою відмітки часу біткоїна та стейкінгу біткоїна. Перше використовує біткоїн як сервер відмітки часу для запобігання відмінних транзакцій або зловмисних відгалужень, тоді як останнє використовує потужну ліквідність BTC як криптоекономічну безпеку, що дозволяє власникам BTC заробляти додатковий прибуток нативним способом.
Наразі в Вавилоні зберігається приблизно 55 000 BTC, що відповідає обмеженню на зберігання, встановленому Вавилоном. Близько 3,9% від загального обсягу ETH повторно ставляться на EigenLayer. Ураховуючи це, навіть якщо власники BTC можуть бути консервативними у використанні BTC, варто розглянути потенціал зростання Вавилону, зі ставкою лише близько 0,2% від загального обсягу BTC, який наразі ставляється.