Як Hemi поєднує Біткойн та Смарт-контракти через hVM та виконання на основі тунелів

Я зацікавився @Hemi, коли зрозумів, скільки криптовалютних проєктів говорить про з'єднання Біткойна та смартконтрактів, але все ще покладається на загорнуті токени, окремі оракули або третіх осіб-ретрансляторів. Те, що Hemi стверджує, привернуло мою увагу: він вбудовує нативну обізнаність про Біткойн у середовище, подібне до EVM, щоб смартконтракти могли безпосередньо посилатися на стан і активи Біткойна. Ця ідея — що ви не просто обгортаєте Біткойн, ви приносите стан Біткойна в середовище контракту — здавалася справжнім стрибком. (Дивіться документацію: hVM Hemi — це “EVM, вдосконалений з обізнаністю про Біткойн” завдяки вбудованій службі “Tiny Bitcoin”. ) Використовуючи $HEMI , я експериментував з ідеєю тунелів. Hemi представляє “Тунелі”, а не просто “містки” — тонка різниця полягає в тому, що тунель підтримує усвідомлення стану обох блокчейнів на рівні протоколу, а не покладається виключно на обгортання та кураторів. Наприклад: “Тунель Біткойн” від Hemi дозволяє користувачам заморожувати реальний Біткойн ( або активи, що належать до Біткойн ) на блокчейні Біткойн, і отримувати представницький токен на Hemi; коли ви викуповуєте, Біткойн розблоковується з сейфу. Що це означає на практиці: ви тримаєте BTC, ви хочете використовувати його в смартконтрактах, DeFi або dApps у стилі EVM — Hemi дозволяє це, надаючи вам представництво та забезпечуючи, щоб основний механізм був прив'язаний до Біткойна більш прямим способом, ніж багато ранніх містків. Спосіб, у який я дивився на архітектуру: спочатку hVM. #Hemi запускає EVM-сумісну віртуальну машину (, тож контракти Solidity, знайомі інструментальні засоби ) та вбудовує повний вузол Біткойн ( або легку версію, індексовану для детермінізму ) всередині середовища виконання цієї VM. Наприклад, “Tiny Bitcoin Daemon” (TBC) синхронізується з блоками Біткойн, а “Processed Bitcoin View” підтримується на всіх вузлах Hemi, щоб смартконтракти могли детерміністично отримувати дані з Біткойн: UTXO, баланси, підтвердження транзакцій, заголовки блоків. Що це дало мені як розробнику-користувачу, так це можливість писати контракти, які говорять такі речі: якщо певна адреса Біткойн отримує X сатоші, тоді активуйте цю логіку контракту на Hemi. Без проміжного оракула. Це здавалося потужним. Тоді механізм тунелю: коли я вніс BTC в $HEMI Біткойн Тунель, система заблокувала BTC у сховищі (мультипідпису або кастодіальної системи) з боку Біткойна, hVM контролював UTXO і стан Біткойна для перевірки депозиту, і після підтвердження (після деяких підтверджень Біткойна) Hemi випустив “hemiBTC” або представницький токен, який я міг використати в середовищі смартконтрактів Hemi. При виведенні я спалював представницький токен і активував сховище, щоб повернути BTC назад до мене. Документи кажуть про депозити: користувач надсилає BTC у сховище, hVM контролює таблицю UTXO, представницький токен випускається після ~6 підтверджень Біткойна. Для виведення: спалити представницький токен на Hemi, hVM + логіка тунелю перевіряють, і сховище повертає оригінальний BTC на адресу Біткойна. Я спробував невеликий переказ у тестовій мережі, побачив потік “блокування зі сторони BTC → випуск на стороні Hemi”. Інтерфейс користувача був простим; але архітектура бекенду є нетривіальною. Однією з речей, яка мені сподобалась, є дизайн безпеки: вбудовуючи стан Біткойна безпосередньо в VM, @Hemi уникає деяких довірчих припущень, які мають старі мости (наприклад, чисто централізовані кастодіани, оракули, які можуть зазнати невдачі). Hemi все ще має фази своєї моделі безпеки тунелю: Фаза 0 використовує надмірно закріплені мультипідписні сховища; майбутні фази мають намір використовувати BitVM / 1 з N довірчі моделі для вищої децентралізації. Для мене це означає: так, сьогодні все ще є елементи довіри, але архітектура має шари для покращення. З точки зору використання, я знайшов наслідки цікавими: ви, як власник Біткойнів, тепер можете перенести свій BTC у світ смартконтрактів Hemi ( і, завдяки його сумісності з EVM, можливо, в екосистеми на зразок Ethereum ). Ви можете використовувати свій BTC як заставу, взаємодіяти з DeFi, передавати цінність, а підлягаюча система все ще пов'язана з блокчейном Біткойна в доказовий спосіб. Якщо ви розробник смартконтрактів, ви можете написати контракт, який стежить за адресами Біткойна або подіями транзакцій (через hVM попередньо скомпільовані ) і запускає логіку на Hemi — щось, що було дуже складно раніше. Наприклад, hVM пропонує попередньо скомпільовані контракти, такі як BtcBalAddr (баланс адреси BTC ), BtcUtxosAddrList (UTXO адреси BTC ), BtcTxByTxid (отримати транзакцію за ID ). Звичайно, це не ідеально. Є компроміси та відкриті питання, які я відзначив, коли його використовував. Одне з них - складність: хоча інтерфейс був простим, механізми на задньому плані (сховища, часи підтвердження, забезпечення того, щоб потоки монетизації→знищення були надійними) означають, що є затримка (BTC часи підтвердження). Документи зазначають, що депозит може займати близько 1 години, а зняття - близько 12 годин у поточному моделюванні. Також, хоча доступ до вбудованого вузла є потужним, розробникам і користувачам все ще потрібно розуміти деталі стану Біткойна (UTXO, адреси тощо), щоб повністю використовувати функції; тому є трохи вищі технічні витрати, ніж у простого токена ERC-20 на L2. Ще одна проблема: довіра до сховища/кастоді до повної децентралізації: Фаза 0 використовує сховища з надмірно забезпеченими мультипідписами, а не повністю автономну некостодіальну модель з мінімальною довірою. Хоча архітектура обіцяє майбутній BitVM / 1 з N довіру, до того часу залишається певний ризик. Я досліджував, як обробляється штрафування або неналежна поведінка: документи вказують, що hVM контролює несанкціоновані виведення; злочинна активність сховища може бути позначена користувачами, і штрафування застосовується. Соціальність користувачів, які піднімають спори, все ще на початковому етапі; я хочу спостерігати далі, наскільки надійною стане ця система. Також, хоча контракти можуть отримувати доступ до даних Біткойн, важливі наслідки для продуктивності та вартості: ви маєте справу з більшими даними (Біткойн блоками, наборами UTXO) та синхронізацією стану між вузлами. Це може додати накладні витрати в порівнянні з тривіальною логікою ERC-20. У моїх тестуваннях я не відчував, що це надто повільно, але я б утримався від судження до повного використання основної мережі. Підсумовуючи, після спілкування з Hemi, я вважаю, що він пропонує переконливий міст між Біткойном і світом смартконтрактів — не лише загортаючи Біткойн, а й впроваджуючи Біткойн у середовище смартконтрактів через hVM та тунельне виконання. Для мене, як користувача криптовалюти, який володіє BTC і хоче брати участь у DeFi, або як розробника, що створює смартконтракти, які потребують стану Біткойна, Hemi представляє одну з елегантніших архітектур, які я бачив. Якби я обирав вирок: так, Hemi обіцяє і я оптимістично ставлюся до його потенціалу зробити Біткойн програмованим та взаємодіючим зі смартконтрактами в більш рідний спосіб. Ключові сфери, за якими я буду стежити, це: як модель довіри сховища/тунелю еволюціонує ( до повної децентралізації ), як поліпшуються інструменти для розробників та UX ( для зменшення технічних витрат ), і наскільки велике прийняття відбувається (, щоб ліквідність та використання проходили через тунелі ). Якщо все зійдеться, я очікую, що Hemi може стати основним шаром для смартконтрактів, які усвідомлюють Біткойн — поєднуючи безпеку Біткойна з універсальністю в стилі EVM. #Hemi $HEMI {точка}(HEMIUSDT)