Вступ

З моменту заснування індустрії блокчейнів з’явилася незліченна кількість L1/L2, і майже кожна публічна мережа розробила власну екосистему DeFi. Деякі люди взаємодіють лише в певних публічних мережах, тоді як більше людей сподіваються знайти можливості отримання прибутку, такі як торгівля та майнінг, у різних мережах. Серед них міжланцюговий переказ коштів став неодмінною необхідністю.

Крім звичайних користувачів, багатьом сторонам проекту також потрібно переказувати кошти між різними ланцюжками, керувати ліквідністю в різних ланцюгах і досягати «одних грошей для багаторазового використання».

Однак різні блокчейни є ізольованими консенсусними системами, і немає можливості для прямого переходу коштів з одного ланцюга в інший. Суть крос-ланцюгових фондів полягає в тому, що міжланцюговий міст діє як публічний контрагент, отримуючи кошти користувачів у вихідному ланцюзі та надсилаючи гроші користувачам у цільовому ланцюгу. (Випуск зіставлених активів або вивільнення коштів для користувачів із пулу ліквідності, зарезервованого цільовим ланцюгом).

Який найкращий спосіб реалізації міжланцюжкових коштів? На початку люди все ще довіряли централізованим біржам. Свого часу була приказка: «Централізовані біржі — найкращі міжланцюгові мости». Однак операція «Stake-swap-withdraw» дуже громіздка, і люди сподіваються мати чистий ланцюжок. Таким чином, кошти можна зв’язувати більш прямо.

Крім того, у порівнянні з централізованими обмінами, крос-ланцюгові мости можуть завершити більш загальний міжланцюговий обмін повідомленнями, не обмежуючись лише переказами коштів. Наприклад, якщо ви використовуєте міжланцюгове кредитування dApp, щоб надати частку з ланцюга A та позичити активи в ланцюжку B, вам потрібно використовувати міжланцюговий обмін повідомленнями.

Якщо дослідити історичне походження крос-ланцюга, то його можна простежити до ранніх етапів розвитку технології блокчейн. У той час поява різних публічних ланцюжків змусила людей усвідомити, що проблема взаємодії між ланцюгами повинна бути вирішена, інакше з’явиться багато інформаційних/фондових острівців. З часом люди запропонували різні типи крос-ланцюгових методів, поступово сформувавши сучасну загальну модель крос-ланцюгів.

Нижче ми пояснимо деякі розробки в крос-ланцюжковій технології.

1. Методика

Знайдіть контрагентів самостійно, подумайте, який метод крос-ланцюга найбільш інтуїтивно зрозумілий? Припустімо, у вас є 100 USDT у ланцюжку A, і ви хочете перевести їх у ланцюжок B. Випадково є людина, яка має 100 USDT у ланцюжку B, і він хоче перевести USDT у ланцюжок A. Ви двоє побачили, що це в самий раз, так що ви одразу влучили. Але коли ви перевели USDT на адресу іншої сторони в ланцюжку A, він пошкодував про це й не переказав свій USDT в ланцюжку B на вашу адресу. Тому ця торгова модель P2P не дуже надійна. По-перше, інша сторона може розірвати договір, що спричинить ваші збитки без будь-яких гарантій; по-друге, цього контрагента нелегко знайти, і вам, можливо, доведеться довго чекати, щоб знайти такого, який тільки відповідає сумі, яку ви хочете перетнути, але міжланцюговий напрям Навпаки, користувачі можуть навіть не мати змоги чекати для такого контрагента цілу вічність.

2. Нотаріальні послуги

2.1 Індивідуальний нотаріус

Тож ми подумали, що оскільки інша сторона може порушити договір, чи можу я знайти надійну третю сторону для проведення транзакцій? Я передаю йому гроші спочатку по вихідному ланцюжку, а потім він обіцяє передати мені гроші по цільовому ланцюжку. Наприклад, ця особа має активи як у ланцюжку A, так і в ланцюжку B, і тоді вона гарантує, що поки вона отримує від мене 100 USDT у ланцюжку A, вона переведе мені 100 USDT із ланцюжка B.

Це набагато краще, ніж перший міжланцюговий обмін активами P2P, тому що є надійний публічний контрагент, який має в руках чарівну річ під назвою «ліквідність», і ви можете торгувати з ним у будь-який час.

Іншими словами, ваша транзакція з ним стає транзакцією «точка-пул», а не транзакцією «точка-точка». Але ви все одно відчуваєте себе неспокійно. Якщо ви торгуєте з ним 100 USDT, це добре. Що, якщо ви хочете обміняти з ним 1 мільйон доларів США? Незважаючи на добру репутацію, він все одно взяв гроші та втік.

Зрештою, цей нотаріус запроваджує свого роду централізацію, яка все ще не є тим методом Trustless cross-chain, який ми хочемо.

2.2 Кілька нотаріусів (MultiSig)

А якщо цей нотаріус не одна особа, а група людей? Ми можемо створити обліковий запис із спільним керуванням, і кілька підписантів спільно керуватимуть обліковим записом. Вони мають підписати повідомлення. Кошти будуть перераховані лише тоді, коли кількість підписів досягне порогу (зазвичай 2/3).

У цьому випадку, якщо невелика кількість із них (не більше 1/3) має неправильне уявлення та хоче отримати від мене гроші в вихідному ланцюжку, але не хоче надсилати мені гроші в цільовому ланцюжку, або офлайн, це не має значення. Інший чесний нотаріус все одно підписав би і перерахував належні мені гроші.

Це рішення надійніше, послаблює ризик централізації та безпечніше. Наприклад, якщо загалом є 20 нотаріусів із авторитетом, ймовірність того, що вони вчинять неправильно одночасно, все ще дуже мала. (Сюди не входять такі ситуації, як Multichain, де 20 вузлами керує одна особа, або ситуації, такі як Axie cross-chain bridge, де хакери вкрали 2/3 ключів підпису нотаріуса.)

2.3 Кілька державних нотаріусів (MPC)

Однак метод управління обліковим записом за допомогою мультипідпису також має багато незручностей.

Мультипідписи полегшують доступ до правил підпису. Якщо це схема підпису 5/7, код смарт-контракту гаманця з кількома підписами покаже, скільки підписантів є, і хакери можуть цілеспрямовано шукати цих підписантів і чекати можливості викрасти закритий ключ.

Мультипідпис вимагає адаптації до різних публічних мереж. Наприклад, деякі публічні ланцюги не підтримують смарт-контракти, тому вам доведеться використовувати спеціалізовані криптографічні примітиви ланцюга для реалізації облікових записів із кількома підписами. Якщо це не підтримується, ваш гаманець із кількома підписами не зможе працювати.

Підписувач кількох підписів не може бути змінений після визначення підписувача. Наприклад, якщо ви хочете змінити схему підпису 5/7 на схему 6/8 або якщо ви хочете змінити підписувача, вам потрібно перерозподілити контракт із кількома підписами та перевести кошти в новий контракт із кількома підписами .

Перше крос-чейн рішення для деривативів BTC, tBTC, використовувало метод мультипідпису, який був усунений, оскільки він був кульгавим і важким у використанні. Більшість поточних перехресних ланцюгових мостів використовують більш вдосконалений метод MPC.

Повна назва Multi-Party Computation — Multi-Party-Computation (Multi-Party Secure Computation), яка є технологією шардингу приватного ключа. Обліковий запис із кількома підписами керує обліковим записом із кількома закритими ключами, тоді як обліковий запис MPC керує обліковим записом із одним закритим ключем. Приватний ключ розділений на кілька фрагментів. Кілька підписантів мають один фрагмент закритого ключа. Коли кількість підписантів дорівнює. Повний підпис можна синтезувати лише після досягнення порогового значення, і повний приватний ключ не буде розкрито під час процесу підписання. Облікові записи MPC мають такі переваги: вони більш конфіденційні, ніж звичайні гаманці з декількома підписами. . Коли потрібен підпис, наприклад, 5/7 фрагментів закритого ключа використовуються для підпису кожного, а кілька субпідписів об’єднуються, щоб сформувати остаточний юридичний підпис. Таким чином, те, що ви бачите в ланцюжку, є одним звичайним підписом. Ви не можете визначити, чи надходить він з облікового запису MPC, не кажучи вже про те, хто за ним стоїть підписувач, а також кількість фрагментів закритого ключа та конкретні правила підпису. Він може адаптуватися до більшості публічних ланцюжків краще, ніж гаманці з кількома підписами. MPC — це технологія підпису, яка не має нічого спільного з ланцюгом. Обліковий запис MPC - це звичайний обліковий запис. Незалежно від того, чи підтримує загальнодоступний ланцюг смарт-контракти, обліковий запис із спільним керуванням можна створити за допомогою технології MPC. Механізм заміни підпису MPC більш гнучкий. Він може підтримувати більш гнучкі налаштування правил підпису, такі як зміна кількості фрагментів закритого ключа та порогових значень підпису в будь-який час, і ви також можете будь-коли змінити підписувача. Вам потрібно лише повторно поділитися закритим ключем.

3. Подальші заходи безпеки

3.1 Поділ гарячого і холодного

Після того, як рахунок нотаріуса отримав мої 100 USDT у ланцюжку A, він переказав 100 USDT на мою адресу в ланцюжку B. Яким має бути процес ініціювання такої поведінки?

Припустімо, що кожен член-нотаріус має машину, яка контролює транзакції в ланцюжку A. Коли вони дізналися, що я перерахував 100 USDT на міжланцюговий бридж-кастодіальний рахунок, у цій транзакції було зазначено, що я сподіваюся бути вказаним у ланцюжку B. Отримайте ці USDT за адреса користувача2.

У цей час нотаріуси спільно підписали та перерахували користувачеві 100 USDT на міжланцюговому мостовому рахунку в ланцюжку B. Цей процес має бути записаний у код і виконуватися автоматично, інакше нотаріус мав би бути онлайн у режимі реального часу та працювати одразу після отримання запиту, що надто нереально.

Ця автоматизована програма складатиметься з кількох частин

1. Програма моніторингу: відповідає за моніторинг транзакцій у вихідному ланцюжку. Щоб відфільтрувати нерелевантні транзакції або недійсні транзакції, на цьому етапі може виконуватися певна базова перевірка формату;

2. Процедура перевірки: це включатиме клієнт легкого вузла (який також може бути повним вузлом) підтримуваного блокчейну, відповідального за перевірку того, що транзакція у вихідному ланцюжку, яка взаємодіє з міжланцюговим мостовим контрактом, упакована в блок і поставлена на ланцюжку. ;

3. Процедура підпису: відповідає за підписання та ініціювання транзакцій передачі користувачам у цільовому ланцюжку.

Але автоматизація також створює проблему, тобто автоматизовану програму можуть атакувати та маніпулювати хакери. Тому, щоб контролювати ризики, міжланцюгові мости вживатимуть заходів для розділення гарячого та холодного. Автоматизована програма керує гарячою клавішею, а сума переказу обмежена. Для великих переказів нотаріус повинен використовувати холодний ключ для підпису вручну. Правила гарячої та холодної сепарації можуть бути реалізовані в обліковому записі MPC.

3.2 Ізоляція ризику

Якщо є помилка, чи не хочете ви впоратися з нею за один інцидент? Таким чином, необхідно ізолювати пул капіталу та використовувати кілька рахунків зберігання для управління коштами ліквідності. Наприклад, відповідно до ізоляції між різними публічними ланцюгами, A і B, B і C, а також C і D є незалежними пулами капіталу.

3.3 ТІ

Програми автоматизованого моніторингу та підпису, якими керує нотаріус, можна запускати на пристроях TEE, що може значно ускладнити хакерські атаки.TEE означає Trusted Execute Environment, яке є обчислювальним середовищем, що працює на певному пристрої, ізольованому від основного операційна система, як анклав.

Ця ізоляція забезпечується апаратним забезпеченням із надзвичайно високим рівнем безпеки, тому TEE можуть запускати програми з високими вимогами до безпеки, наприклад керування ключами шифрування, біометричну автентифікацію, безпечну обробку платежів тощо.

3.4 PoA йде ліворуч, PoS – праворуч

Щоб зробити міжланцюгові мости більш безпечними, існує два напрямки відбору нотаріусів:

Один — вибирати якомога більше великих компаній і відомих закладів з хорошою репутацією. Для цих установ ціна зла надзвичайно висока, і вони можуть втратити роки доброї волі. Крім того, намагайтеся, щоб вони були максимально різноманітними за географічним розташуванням (уникаючи концентрації в одній юрисдикції).

Наприклад, проект крос-ланцюгового мосту Wormhole вибрав цю модель. Його 19 вузлів підтримують відомі великі установи з великими розмірами та потужними фондами. Це метод PoA.

Інший спосіб — допустити нотаріусів без дозволу, але вимагати від них ставки. Якщо вони поведуть себе погано, їхні вкладені кошти будуть скорочені. Ось як працює PoS. Це те, що використовує ZetaChain.

Який із двох методів краще, а який гірше, важко зробити довільний висновок прямо. Це залежить від того, наскільки добре працюють сторони проекту міжланцюгового мосту у своїх відповідних напрямках.

Незалежно від того, чи це PoA чи PoS, ви можете перетворити міжланцюговий міст безпосередньо в загальнодоступний ланцюг. Кожен вузол запускає ту саму програму, і всі міжланцюгові запити та процеси обробки будуть записані в цьому ланцюжку. Сама мережа також може розміщувати додатки, таким чином стаючи екологічним центром.

3.5 Спостерігач

Ще один спосіб підвищити безпеку — встановити роль спостерігача. Ця роль відповідає за моніторинг міжланцюжкової поведінки та, якщо виявлені проблеми, звітування про внутрішньоланцюгові та перервані транзакції. Оскільки спостерігачам потрібен період вікна для реакції, час надходження міжланцюжкових передач може бути відкладено. Тому спостерігачі втручаються лише в тому випадку, якщо користувачі погоджуються на затримки переказів для транзакцій на великі суми або чутливих міжланцюжкових операцій.

Інші крос-ланцюгові рішення. Хеш-блокування. Повернемося до першого методу, згаданого в цій статті: P2P шукає контрагентів для міжланцюгового обміну активами. Якщо ми боїмося, що контрагент не виплатить кредит, ми можемо створити механізм. Якщо хтось відмовиться, інша сторона може отримати гроші назад і повернути їх у недоторканому вигляді. Це хеш-блокування, яке вміло використовує хеш-блокування та блокування часу. Воно змушує одержувача коштів підтвердити платіж до кінцевого терміну та створити підтвердження отримання в ланцюжку джерела. З цим підтвердженням отримання платник зможе отримати еквівалентні активи одержувача в цільовому ланцюжку. В іншому випадку обидві сторони будуть. Усі кошти буде повернено початковим шляхом.

Однак цей метод може лише обмінювати кошти і не може завершити загальну міжланцюгову передачу інформації. Навіть з точки зору крос-ланцюжкового переказу коштів, досвід користувача блокувань часу хешування дуже поганий: якщо коливання цін на валюту є несприятливим для контрагента (постачальника ліквідності), він може раціонально вирішити не завершувати транзакцію; для завершення Для міжланцюжкового обміну і користувач, і контрагент повинні підписати двічі. отже, як крос-ланцюгове рішення, блокування часу хешування було усунено. Ранні крос-ланцюгові мости (такі як cBridge і Connext), які використовували це рішення, змінилися. Легкий клієнт у ланцюжку Цей метод призначений для безпосереднього розгортання контракту легкого клієнта вихідного ланцюга на цільовому ланцюжку. Якщо ви розгортаєте контракт у ланцюжку, усі вузли в ланцюжку запускатимуть код контракту, який ви розгорнули.

Таким чином, легке клієнтське рішення on-chain дозволяє цільовому ланцюжку безпосередньо перевіряти транзакції з вихідного ланцюга. Цей спосіб надзвичайно безпечний, але і найдорожчий. Витратність відображається в таких аспектах: Контракт легкого клієнта цільового ланцюга повинен отримувати та перевіряти новий заголовок блоку з вихідного ланцюжка в режимі реального часу. Цей процес споживає багато газу. Навіть якщо ZK використовується для отримання стислого доказу, споживання газу для перевірки доказу ZK буде не менше 400 000 газів (наприклад, EVM), у схемі MPC все, що потрібно для перевірки в ланцюжку, — це підпис , а витрата газу всього трохи більше 20 000, різниця в 20 разів! Чи використовували б ви більш безпечний міст, але в 20 разів дорожчий?

Обсяг роботи, необхідний для розробки легких клієнтських контрактів, величезний. Щоб зробити міжланцюговий міст сумісним із більш гетерогенними ланцюгами, вам потрібно реалізувати легкі клієнтські контракти інших ланцюгів у зовсім інших середовищах розробки різних ланцюгів, що є справжньою проблемою для розробників. Це призводить до більшої ймовірності помилок у написанні контракту, тобто безпека легкого клієнтського мосту лише на теоретичному рівні, але з точки зору інженерної практики це дуже небезпечно. Щоб зменшити обсяг роботи з розробки, можливим рішенням є запровадження ланцюга ретрансляції та дозволу всім ланцюгам укладати легкі клієнтські контракти з цим ланцюгом ретрансляції. Це справді може зменшити навантаження на C(n,2) до n, але все одно не надто мало. Початкова пряма перехресна передача від вихідного ланцюга до цільового ланцюга стала передачею другого порядку вихідний ланцюг → релейний ланцюг → цільовий ланцюг, що призведе до додаткового споживання газу та витрат часу.

Таким чином, технічне рішення полегшеного клієнта наразі не може бути використано для побудови більш універсального крос-ланцюгового мосту.

Кінець гри

По-перше, різні громадські мережі мають різні підходи та різні ресурси для їх підтримки. Поки вони не визнають поразки, екосистема існуватиме. Навіть якщо розвиток не дуже хороший у короткостроковій перспективі, одного разу він може бути модернізований і він повернеться до життя. Справа в такій базовій інформації полягає в тому, щоб побачити, хто може вистояти довше, а хто може швидко адаптуватися до ринку.

Біткойн та Ethereum не можуть вирішити всі сценарії застосування, або в певному сегменті завжди є люди, яким не подобається перше місце, тому вони створюють нове колесо, тому майбутнє буде багатоланцюжковим. У майбутньому нижній шар більше не буде ланцюгом, тому майбутнє має бути мультиекологічним. Для того, щоб передавати кошти та повідомлення між кількома екологіями, потрібна крос-ланцюгова/крос-екологічна технологія!

Що найбільше хвилює користувачів, коли мова заходить про крос-чейн? Нічого іншого, крім наступних пунктів:

Швидкість: скільки часу потрібно для завершення міжланцюжкової операції?

Комісія: скільки мені потрібно заплатити за міжланцюгову операцію

Безпека: чи безпечний міжланцюговий міст і чи будуть втрачені кошти?

Ліквідність: чи достатньо ліквідності для підтримки моєї торгівлі та прийнятного впливу на ціну?

Область підключення: скільки ланцюжків ви підтримуєте? Чи підтримуєте ви ланцюги, які мені потрібно використовувати в міжланцюжкових операціях?

Досвід: чи зручна робота між ланцюгами, наприклад, чи підтримується оплата газу, чи точна оцінка вартості, чи підтримується запит прогресу та перегляд у браузері, чи часто трапляються збої, як усунути збої тощо?

Давайте спочатку розглянемо характеристики деяких проектів з трьох відносно чітких точок зору: безпека, вартість і дальність з’єднання.

Перейдіть за посиланням, щоб переглянути зрозумілу таблицю (таблиця постійно оновлюється):

https://docs.google.com/spreadsheets/d/1LKlbd5KJUnQIx3ZBTgyMADhxHtWVwBH9qDRm765tPMw/

Щоб повністю пояснити перехресний ланцюговий міст, потрібно обговорити багато розмірних деталей, наприклад усі розміри та аналіз даних у таблиці вище. Отже, на які фактори ви звертаєте увагу під час схрещування ланцюгів? Які перехресні ланцюгові мости ви часто використовуєте? На які аспекти, на вашу думку, слід зосередитися міжланцюговими мостами для оптимізації? Якщо у вас є свої ідеї, будь ласка, зв’яжіться з автором.

Відмова від відповідальності:

1. Цю статтю передруковано з [极客Web3]. Усі авторські права належать оригінальному автору [0xKooKoo]. Якщо є заперечення щодо цього передруку, будь ласка, зв’яжіться з командою Gate Learn , і вони негайно розглянуть це.
2. Відмова від відповідальності: погляди та думки, висловлені в цій статті, належать виключно автору та не є жодною інвестиційною порадою.
3. Переклади статті на інші мови виконує команда Gate Learn. Якщо не зазначено вище, копіювання, розповсюдження або плагіат перекладених статей заборонено.