By Bitcoin Журнал - 1 рік тому - Час читання: 6 хвилини
Softchains забезпечують двосторонню прив’язку та потенційні можливості для використання — але не без витрат на безпеку
Softchains — це сайдчейн, який взаємодіє на більш глибокому рівні з механізмами консенсусу, що може принести переваги та ризики.
Це редакційна стаття Шинобі, педагога-самоучки в Bitcoin орієнтований на космос і техніку Bitcoin ведучий подкастів.
У цій наступній статті ми розглянемо різні дизайни реалізації сайдчейну м'які ланцюги. Це ще один із Рубен Сомсенпропозиції щодо механізму сайдчейну. Це сильно відрізняється від космічних ланцюгів, дизайн, описаний у моїй попередній статті. Це вимагає певних змін до Bitcoin Основний протокол, спеціально структурований для реалізації бічного ланцюга, накладає нову вартість перевірки Bitcoin повні вузли та має підтримку двостороннього механізму прив’язки, який не залежить від федерації до зберігання коштів.
Будівельний блок
Суть ідеї ґрунтується на попередній пропозиції Сомсена під назвою Докази шахрайства PoW, механізм для покращення безпеки спрощеної перевірки платежів (SPV) для гаманців. Ідея ґрунтується на простому спостереженні про блокчейн — якщо буде створено недійсний блок, то, ймовірно, станеться форк у блокчейні, оскільки будь-які чесні майнери відмовляться будувати на недійсному блоці та зрештою видобуватимуть дійсний. Створено недійсний блок і не створено форк чесними майнерами, по суті, означає, що стався повний збій у процесі консенсусу в мережі, тому статистичні шанси на те, що це станеться, незначно мізерні. Таким чином, розгалуження можна розглядати як своєрідний сигнал про те, що «Гей, тут могло щось трапитися, тож вам слід це перевірити». Клієнти можуть використовувати такі форки як своєрідний сигнал тривоги про те, що вони дійсно повинні завантажити ці блоки та перевірити, що відбувається.
Однак це створює фундаментальну проблему — щоб перевірити блок, вам потрібно встановити UTXO. Щоб мати набір UTXO, ви повинні перевірити всі попередні блоки в ланцюжку для його створення. Отже, як це функціонує як механізм SPV? Відповідь: зобов’язання UTXO.
Кожен блок потрібно перевірити на відповідність набору UTXO, базі даних кожного bitcoin що існує, але ще не витрачено, і наразі це лише локальна база даних, яку кожен вузол створює та зберігає під час сканування блокчейну з самого початку. Зобов’язання набору UTXO бере набір UTXO, створює з нього дерево Merkle та в ідеалі фіксує його хеш усередині кожного блоку. Це дозволяє отримати блок із деякими додатковими даними — гілку Merkle для кожного входу кожної транзакції, що підтверджує, що це було в останньому зобов’язанні набору UTXO — і перевірити це таким чином. Якби система використовувала таку схему зобов’язань із самого початку, і вона фактично використовувалася великою кількістю користувачів, які повністю перевіряли ланцюг, тоді вони забезпечили б гарантію безпеки, майже еквівалентну повному вузлу. Щоразу, коли відбувається поділ ланцюга, ви можете завантажити всі задіяні блоки та переконатися, що ланцюжок, за яким ви стежите, дійсний. Якщо обидві сторони поділу дійсні, виграє той, хто найдовший. Однак якщо один із них був недійсним, це дало б вам змогу одразу його виявити.
Двосторонній кілок
У рамках дизайну програмного ланцюга вузли основного ланцюга мали б завантажувати та перевіряти заголовки блоків для кожного програмного ланцюга, а у випадку будь-якого розділення ланцюга завантажувати та перевіряти ці блоки за допомогою зобов’язань набору UTXO. Це стане основою механізму кріплення для двостороннього кріплення. Щоб перенести монети в сайдчейн, користувач повинен створити транзакцію основного ланцюга, призначаючи їх певному софтчейну, а потім вказати на цю транзакцію, коли буде підтверджено вимогу монет у сайдчейні. І навпаки, ви б зробили протилежне, намагаючись вийти з бічного ланцюга. Ось тут і вступають у гру докази шахрайства PoW. Під час пегоуту ідея полягає в тому, щоб створити транзакцію в основному ланцюзі, посилаючись на транзакцію зняття коштів у бічному ланцюзі. Ці монети стануть доступними для витрачання лише після довгого вікна підтвердження (скажімо, рік) і залишаться «заблокованими в софтчейні», якщо транзакцію зняття коштів у бічній ланцюзі буде повторно організовано або виявиться недійсною. Останнє буде виявлено, тому що в разі розбиття ланцюга вузол основного ланцюга завантажить усі блоки з кожної сторони розбиття та перевірить їх за допомогою зобов’язань набору UTXO.
Тривале вікно підтвердження для pegouts призначене для того, щоб навіть невеликий відсоток чесних майнерів міг мати достатньо часу, щоб створити єдиний дійсний блок, розбиваючи ланцюжок і запускаючи перевірку всього з цього моменту за допомогою зобов’язань UTXO. Це дозволяє вузлам основного ланцюга виловлювати шахрайські прив’язки бічного ланцюга до того, як зняття буде підтверджено в основному ланцюзі, таким чином роблячи транзакцію недійсною, не вимагаючи від них перевірки всього бічного ланцюга — що нічим не відрізнятиметься від збільшення розміру блоку.
Параметри безпеки та ризики
Ця конструкція створює деякі питання щодо рівня безпеки на основі певних змінних і того, як такий сайдчейн буде взаємодіяти з майнерами. Перш за все, будь-який програмний ланцюг слід розгортати з мінімальними вимогами до складності для блоків, щоб, якщо хеш-рейт стає занадто низьким, замість рівня складності нижче цього мінімального рівня, пошук блоків у сайдчейні просто триватиме більше часу — тобто інтервал між блоками буде збільшити. Це необхідно, оскільки базові вузли перевірки PoW на захист від шахрайства повинні виконуватися як частина цього дизайну. Якщо складність програмного ланцюга занадто низька, тоді майнерам стане легко регулярно зловмисно розгалужувати програмний ланцюг і ефективно виконувати атаку типу «відмова в обслуговуванні» (DoS) проти вузлів основного ланцюга, збільшуючи обсяг додаткових даних, які вони потрібно підтвердити.
Об’єднаний майнінг є вирішенням цієї проблеми. Якщо все Bitcoin майнери також видобувають блоки на бічній ланцюзі, тоді проблема DoS-атак на основний ланцюг шляхом створення ланцюжків на софтчейні вирішується настільки добре, наскільки це можливо. Щоб розділити програмний ланцюг, потрібно було б стільки ж працювати, скільки і основний ланцюг, запобігаючи довільним і недорогим атакам, щоб збільшити кількість даних, необхідних для перевірки основного ланцюга. Однак у вирішенні проблеми DoS-атаки це створює іншу проблему: збільшення вартості перевірки майнерів.
Якщо майнери також збираються майнити програмні ланцюги, вони повинні запустити для них вузли, щоб переконатися, що блоки, які вони майнить, дійсні. Якщо ні, вони ризикують залишитися сиротами та втратити дохід від комісії через недійсний блок. Якщо було активовано багато програмних ланцюжків, які дорогі для перевірки, наприклад ланцюги клонів Ethereum або великі ланцюжки блоків, це могло б зробити майнінг більш централізованим і дорогим для участі. Майнери повинні перевірити ланцюжок, щоб знати, що вони будують не на недійсному блоці. і втрачати гроші, тому це не є необов’язковим. Здорожчання валідації підриває зусилля щодо максимальної децентралізації майнінгу.
Найбільшою проблемою є ризик того, що помилка консенсусу в софтчейні фактично спричинить консенсусний розкол самого основного ланцюга. Існує ризик того, що великі реорганізації сайдчейну скасують дійсну транзакцію pegout на стороні сайдчейну, оскільки сторона основного ланцюга незабаром стане дійсною. Пам’ятайте, вузли основного ланцюга також стежать за заголовками softchain. Це може призвести до розбиття основного ланцюга, якщо різні частини мережі знаходяться по різні сторони розділення м’якого ланцюга, оскільки перевіряється прив’язка бічного ланцюга на основному ланцюзі. Недетерміновані помилки консенсусу в програмному ланцюзі також можуть спричинити розкол основного ланцюга, тобто якщо деякі вузли вважатимуть прив’язку недійсною, а інші вважають її дійсною.
Цей більш глибокий зв’язок із консенсусом основного ланцюга робить цей дизайн сайдчейну дещо ризикованим і потенційно таким, чого не слід робити. Принаймні, софтчейни слід активувати по одному в окремих форках, замість того, щоб розгортати один форк, який би дозволяв розкручувати софтчейни за бажанням. Той факт, що в цьому дизайні ланцюги розривів змушують вузли основного ланцюга перевіряти більше даних, робить можливість просто ввімкнути багато програмних ланцюгів одночасно вектором атаки на головний ланцюг.
Softchains більше залучаються до консенсусного рівня основного ланцюга, ніж spacechains, що пов’язано з багатьма ризиками, але вони дозволяють створити рідну двосторонню прив’язку, а отже, більше потенційного простору для різних випадків використання. Далі я перейду до приводних ланцюгів, а після цього кілька останніх думок про бічні ланцюги загалом.
Це гостьовий пост від Shinobi. Висловлені думки є повністю їх власними і не обов’язково відображають думки BTC Inc або Bitcoin Журнал
Оригінальний джерело: Bitcoin журнал