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

Джерело: Журнал Bitcoin; Переклад: Ву Жу, Золота Фінансова

Роллапи останнім часом стали фокусом розширення BTC, ставши першим справжнім речами, які забрали славу від Lighting Network, в більш широкому контексті уваги. Роллапи мають стати другим рівнем поза блокчейном, який не обмежується або обмежується ядром Ліквідність Lighting Network, тобто кінцевому користувачеві потрібно, щоб хтось виділив (або “позичив”) кошти заздалегідь, щоб отримати гроші, або проміжний маршрут Нода потребує балансу каналу для полегшення потоку платежу від відправника до одержувача.

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

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

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

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

Підходящий Rollup

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

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

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

Термін дії

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

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

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

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

В глухой угол

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

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

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

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

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