Bitcoin Magazine: Які проблеми стикається Rollup?

Джерело: Bitcoin Magazine; Компіляція: Wu Zhu, Gold Finance

Останнім часом роллапи стали центром масштабування BTC, ставши першим, хто дійсно «вкрав шоу» у Lighting Network, з точки зору більш широкої уваги. Роллапи призначені для того, щоб бути позаблокчейном рівня 2, який не обмежений обмеженнями ліквідності ядра мережі освітлення, тобто кінцевому користувачеві потрібен хтось, хто виділить (або «позичить») кошти заздалегідь, щоб отримати гроші, або проміжним маршрутом Нода потрібен баланс каналу для полегшення повного потоку суми платежу від відправника до одержувача.

Ці системи спочатку запускалися на Ethereum та інших системах Повнота за Тюрінгом, але недавно акцент перенесено на їхнє перенесення на блокчейни на основі UTXO, такі як BTC. У цій статті ми не плануємо обговорювати поточний стан реалізації на BTC, але розглянемо функції ідеального Rollup, які довгий час прослідковуються людьми, що залежать від можливості безпосередньо перевіряти ZKP на BTC, що наразі не підтримується.

Основна структура Roll як наступна: окремий рахунок (в BTC це UTXO) зберігає баланси всіх користувачів у Rollup. Цей UTXO містить зобов’язання у формі кореня Merkle-дерева, яке зобов’язує всі поточні баланси рахунків у Rollup. Усі ці рахунки авторизовані за допомогою Відкритого ключа/Закритого ключа, тому для здійснення поза блокчейном витрат користувач все ще повинен підписати деякий вміст за допомогою Секретного ключа. Ця частина структури дозволяє користувачам виходити в будь-який момент без дозволу, вистачає зробити транзакцію, щоб довести, що їх рахунок є частиною Merkle-дерева, і вони можуть односторонньо вийти з Rollup без дозволу оператора.

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

Проблема в тому, що якщо тільки корінь дерева Меркле публікується в у блокчейні, користувачі можуть переглядати і отримувати до нього доступ, але як вони можуть додати свої гілки в дерево, щоб мати змогу вийти без дозволу в будь-який час, коли їм заманеться?

Підходящий Rollup

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

У більш високорівневій реалізації використовується різниця в балансі. Це в сутності є кратким описом того, які рахунки отримали або втратили кошти під час процесу оновлення. Це дозволяє кожне оновлення Rollup містити лише зміни в балансі рахунків. Після цього користувач може просто просканувати ланцюжок та здійснити “обчислення” від початку Rollup, щоб отримати поточний стан балансу рахунків, що дозволяє їм відновити дерево Меркла поточного балансу.

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

Термін дії

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

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

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

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

Втрачаючи напрямок

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

З одного боку, використання Біткойн Блокчейн як шару доступності даних буде мати жорсткий верхній ліміт масштабованості для rollup. Блокчейн має обмежений простір, що встановлює верхній ліміт кількості rollup, які можуть існувати одночасно, а також загальну кількість транзакцій, які можуть бути оброблені поза блокчейном. Кожне оновлення rollup потребує пропорційного обсягу Блок простору до кількості рахунків, баланси яких змінилися з моменту останнього оновлення. Теорія інформації дозволяє тільки стискання даних до певної міри, тому на цьому етапі немає більше можливостей для масштабування.

З іншого боку, використання різних рівнів для досягнення доступності даних прибирає жорстку верхню межу на розширюваність, але також вносить нові проблеми безпеки та суверенітету. У Rollup, що використовує BTC для досягнення доступності даних, якщо дані, які користувачам потрібно видобути, не автоматично публікуються в ланцюжку блоків, стан Rollup не може змінитися. У випадку використання Validiums, ця гарантія повністю залежить від здатності зовнішньої системи відстоювати обман та сховання даних.

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

Тоді якщо ми дійсно здійснимо ідеальну реалізацію Rollup на BTC і дійсно забезпечимо можливість виведення коштів однієї сторони, як це буде?