Останнім часом роллапи стали центром масштабування BTC, ставши першим, хто дійсно «вкрав шоу» у Lighting Network, з точки зору більш широкої уваги. Роллапи призначені для того, щоб бути позаблокчейном рівня 2, який не обмежений обмеженнями ліквідності ядра мережі освітлення, тобто кінцевому користувачеві потрібен хтось, хто виділить (або «позичить») кошти заздалегідь, щоб отримати гроші, або проміжним маршрутом Нода потрібен баланс каналу для полегшення повного потоку суми платежу від відправника до одержувача.
Ці системи спочатку працювали на платформах Ethereum та інших системах Повнота за Тюрінгом, але останнім часом акцент перейшов на їх перенесення на блокчейн, заснований на UTXO (наприклад, BTC). У цій статті не мається на меті обговорення поточного стану реалізації на BTC, але розглядається функціональність ідеального Rollup, яка залежить від можливостей, недоступних на BTC - безпосередньої можливості перевірки Доказу з нульовим розголошенням (ZKP) на BTC.
Основна структура Roll виглядає наступним чином: окремий рахунок (в BTC - UTXO) зберігає залишки всіх користувачів в Rollup. Цей UTXO містить зобов’язання у вигляді кореня Merkle-дерева, яке представляє собою зобов’язання всіх поточних залишків користувачів в Rollup. Усі ці рахунки авторизовані за допомогою відкритого/закритого ключа, тому для витрати за межами блокчейну користувачам все ще потрібно підписати деякий вміст за допомогою секретного ключа. Ця частина структури дозволяє користувачам виходити з системи в будь-який момент без дозволу, лише зробивши підтвердження транзакції їх рахунок є частиною Merkle-дерева, вони можуть односторонньо вийти з Rollup без дозволу оператора.
Оператор роллапа повинен включити ZKP в транзакцію, щоб оновити кореневий хеш балансу рахунку у блокчейні після завершення операції з позаблокчейні транзакції. Якщо немає цього ZKP, транзакція буде недійсною і не може бути включена до Блокчейну. Цей доказ дозволяє перевірити, чи всі зміни нарахувань на рахунку поза блокчейном були дійсно авторизовані власником рахунку, а також чи оператор не зловживав своїми повноваженнями при оновленні балансу, щоб вкрасти кошти користувачів або нечесно перерозподіляти їх іншим користувачам.
Проблема полягає в тому, як користувачі можуть розмістити свої гілки в дереві так, щоб вони могли вийти в будь-який момент без дозволу, якщо лише кореневий вузол дерева Меркла публікується в у блокчейні і доступний для перегляду його користувачами?
Відповідний Rollup
У відповідному Rollup, кожен раз, коли підтверджується нова поза блокчейном транзакція і стан рахунку Rollup змінюється, інформація безпосередньо включається в ланцюжок блоків. Не вся дерево, це було б надто абсурдно, але лише інформація, необхідна для відновлення дерева. У простій реалізації, викладена у Rollup, дайджест всіх існуючих рахунків містить баланс, а рахунок просто додається у транзакціях оновлення Rollup.
У більш просунутих реалізаціях використовуються дисперсії балансу. По суті, це підсумок того, який рахунок збільшився або зменшився в ході оновлення. Таким чином, кожне зведене оновлення містить лише ті зміни балансу, які відбуваються. Потім користувачі можуть просто просканувати ланцюжок і «обчислити» з початку зведення, щоб отримати поточний стан балансу рахунку, що дозволяє їм реконструювати дерево Меркла поточного балансу.
Це дозволяє заощадити значні витрати та простір в Блоку (таким чином, зекономити кошти), при цьому надалі дозволяючи користувачам забезпечити доступ до інформації, необхідної для одностороннього виходу. Згідно правил rollup, ці дані повинні бути включені в офіційний rollup, який надається користувачам через Блокчейн, тобто транзакції, які не містять рахунок-конспект або рахунок-відмінність, вважаються недійсними.
Термін дії
Ще один спосіб вирішення проблеми доступності даних для вилучення користувача полягає в тому, щоб зберігати дані в інших місцях, окрім Блокчейну. Це вводить дещо складні проблеми, оскільки rollup все ще потребує гарантії доступності даних в інших місцях. Традиційно для цієї мети використовувалися інші Блокчейни, спеціально розроблені як шар доступності даних для систем, таких як rollup.
Це призводить до того, що існує сильна проблема забезпечення безпеки. Коли дані безпосередньо публікуються в BTCБлокчейн, Консенсус правила можуть гарантувати, що вони абсолютно вірні. Однак, коли вони публікуються в зовнішній системі, найкраще, що вони можуть зробити, - перевірити SPV-доказ, тобто те, що дані вже були опубліковані в іншій системі.
Це потребує підтвердження того, що дані існують в іншому ланці у блокчейні, це в кінцевому рахунку є проблемою оракул-машина. Блокчейн BTC не може повністю підтвердити будь-які події, які відбуваються поза своїм власним блоком блокчейну, найкраще, що він може зробити - це підтвердити ZKP. Однак ZKP не може підтвердити, чи були роллап-дані блоку дійсно розголошені після їх створення. Він не може підтвердити, що зовнішня інформація дійсно доступна всім.
Це відкрило двері для атак затримки даних, тобто створення обіцянки щодо опублікованих даних та їх використання для просування rollup, але насправді дані недоступні. Це призводить до того, що користувачі не можуть виводити кошти. Єдиний справжній вихід - це повне залежання від вартості та структури стимулів поза BTC.
Патовая ситуация
Це створює проблему для rollup. Коли йдеться про проблему доступності даних, фактично існує двовибір: опублікувати дані в ланцюжок блоків BTC або в інше місце. Цей вибір має великий вплив на безпеку, суверенітет та масштабованість rollup.
З одного боку, використання BTC як шару доступності даних у Блокчейні встановить жорстку межу масштабованості для роллапів. Простір блоків обмежений, що встановлює межу для кількості роллапів, які можуть існувати одночасно, а також загальної кількості транзакцій, які можуть бути оброблені поза блокчейном. Кожне оновлення роллапу потребує відповідного простору блоку, пропорційного кількості рахунків, баланси яких змінилися з моменту попереднього оновлення. Інформаційна теорія дозволяє даним стиснути до певного рівня, і на цьому пункті немає більше потенціалу для масштабування.
З іншого боку, використання різних шарів для досягнення доступності даних буде прибрати жорстку верхню межу масштабованості, але воно також винесе нові питання безпеки та суверенітету. У використанні BTC для досягнення доступності даних у Rollup, якщо дані, які потрібно видобути, не автоматично публікуються на блокчейн, стан Rollup не може змінитися. Використання Validiums, ця гарантія повністю залежить від здатності використання зовнішньої системи відстоювати обман та сховання даних.
Тепер будь-який Блок-продюсер на системі доступності зовнішніх даних може перехоплювати кошти користувачів BTCRollup, виробляючи Блоки замість фактичного мовлення про ці Блоки, щоб зробити дані доступними.
Таким чином, якщо ми дійсно здійснимо ідеальну реалізацію Rollup на BTC, справжньо забезпечимо виведення коштів користувача в одному напрямку, як це буде?
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
Bitcoin Magazine: Що становить перешкоду для Rollup?
Джерело: Bitcoin Magazine; Переклад: Ву Чжу, Jinse Finance
Останнім часом роллапи стали центром масштабування BTC, ставши першим, хто дійсно «вкрав шоу» у Lighting Network, з точки зору більш широкої уваги. Роллапи призначені для того, щоб бути позаблокчейном рівня 2, який не обмежений обмеженнями ліквідності ядра мережі освітлення, тобто кінцевому користувачеві потрібен хтось, хто виділить (або «позичить») кошти заздалегідь, щоб отримати гроші, або проміжним маршрутом Нода потрібен баланс каналу для полегшення повного потоку суми платежу від відправника до одержувача.
Ці системи спочатку працювали на платформах Ethereum та інших системах Повнота за Тюрінгом, але останнім часом акцент перейшов на їх перенесення на блокчейн, заснований на UTXO (наприклад, BTC). У цій статті не мається на меті обговорення поточного стану реалізації на BTC, але розглядається функціональність ідеального Rollup, яка залежить від можливостей, недоступних на BTC - безпосередньої можливості перевірки Доказу з нульовим розголошенням (ZKP) на BTC.
Основна структура Roll виглядає наступним чином: окремий рахунок (в BTC - UTXO) зберігає залишки всіх користувачів в Rollup. Цей UTXO містить зобов’язання у вигляді кореня Merkle-дерева, яке представляє собою зобов’язання всіх поточних залишків користувачів в Rollup. Усі ці рахунки авторизовані за допомогою відкритого/закритого ключа, тому для витрати за межами блокчейну користувачам все ще потрібно підписати деякий вміст за допомогою секретного ключа. Ця частина структури дозволяє користувачам виходити з системи в будь-який момент без дозволу, лише зробивши підтвердження транзакції їх рахунок є частиною Merkle-дерева, вони можуть односторонньо вийти з Rollup без дозволу оператора.
Оператор роллапа повинен включити ZKP в транзакцію, щоб оновити кореневий хеш балансу рахунку у блокчейні після завершення операції з позаблокчейні транзакції. Якщо немає цього ZKP, транзакція буде недійсною і не може бути включена до Блокчейну. Цей доказ дозволяє перевірити, чи всі зміни нарахувань на рахунку поза блокчейном були дійсно авторизовані власником рахунку, а також чи оператор не зловживав своїми повноваженнями при оновленні балансу, щоб вкрасти кошти користувачів або нечесно перерозподіляти їх іншим користувачам.
Проблема полягає в тому, як користувачі можуть розмістити свої гілки в дереві так, щоб вони могли вийти в будь-який момент без дозволу, якщо лише кореневий вузол дерева Меркла публікується в у блокчейні і доступний для перегляду його користувачами?
Відповідний Rollup
У відповідному Rollup, кожен раз, коли підтверджується нова поза блокчейном транзакція і стан рахунку Rollup змінюється, інформація безпосередньо включається в ланцюжок блоків. Не вся дерево, це було б надто абсурдно, але лише інформація, необхідна для відновлення дерева. У простій реалізації, викладена у Rollup, дайджест всіх існуючих рахунків містить баланс, а рахунок просто додається у транзакціях оновлення Rollup.
У більш просунутих реалізаціях використовуються дисперсії балансу. По суті, це підсумок того, який рахунок збільшився або зменшився в ході оновлення. Таким чином, кожне зведене оновлення містить лише ті зміни балансу, які відбуваються. Потім користувачі можуть просто просканувати ланцюжок і «обчислити» з початку зведення, щоб отримати поточний стан балансу рахунку, що дозволяє їм реконструювати дерево Меркла поточного балансу.
Це дозволяє заощадити значні витрати та простір в Блоку (таким чином, зекономити кошти), при цьому надалі дозволяючи користувачам забезпечити доступ до інформації, необхідної для одностороннього виходу. Згідно правил rollup, ці дані повинні бути включені в офіційний rollup, який надається користувачам через Блокчейн, тобто транзакції, які не містять рахунок-конспект або рахунок-відмінність, вважаються недійсними.
Термін дії
Ще один спосіб вирішення проблеми доступності даних для вилучення користувача полягає в тому, щоб зберігати дані в інших місцях, окрім Блокчейну. Це вводить дещо складні проблеми, оскільки rollup все ще потребує гарантії доступності даних в інших місцях. Традиційно для цієї мети використовувалися інші Блокчейни, спеціально розроблені як шар доступності даних для систем, таких як rollup.
Це призводить до того, що існує сильна проблема забезпечення безпеки. Коли дані безпосередньо публікуються в BTCБлокчейн, Консенсус правила можуть гарантувати, що вони абсолютно вірні. Однак, коли вони публікуються в зовнішній системі, найкраще, що вони можуть зробити, - перевірити SPV-доказ, тобто те, що дані вже були опубліковані в іншій системі.
Це потребує підтвердження того, що дані існують в іншому ланці у блокчейні, це в кінцевому рахунку є проблемою оракул-машина. Блокчейн BTC не може повністю підтвердити будь-які події, які відбуваються поза своїм власним блоком блокчейну, найкраще, що він може зробити - це підтвердити ZKP. Однак ZKP не може підтвердити, чи були роллап-дані блоку дійсно розголошені після їх створення. Він не може підтвердити, що зовнішня інформація дійсно доступна всім.
Це відкрило двері для атак затримки даних, тобто створення обіцянки щодо опублікованих даних та їх використання для просування rollup, але насправді дані недоступні. Це призводить до того, що користувачі не можуть виводити кошти. Єдиний справжній вихід - це повне залежання від вартості та структури стимулів поза BTC.
Патовая ситуация
Це створює проблему для rollup. Коли йдеться про проблему доступності даних, фактично існує двовибір: опублікувати дані в ланцюжок блоків BTC або в інше місце. Цей вибір має великий вплив на безпеку, суверенітет та масштабованість rollup.
З одного боку, використання BTC як шару доступності даних у Блокчейні встановить жорстку межу масштабованості для роллапів. Простір блоків обмежений, що встановлює межу для кількості роллапів, які можуть існувати одночасно, а також загальної кількості транзакцій, які можуть бути оброблені поза блокчейном. Кожне оновлення роллапу потребує відповідного простору блоку, пропорційного кількості рахунків, баланси яких змінилися з моменту попереднього оновлення. Інформаційна теорія дозволяє даним стиснути до певного рівня, і на цьому пункті немає більше потенціалу для масштабування.
З іншого боку, використання різних шарів для досягнення доступності даних буде прибрати жорстку верхню межу масштабованості, але воно також винесе нові питання безпеки та суверенітету. У використанні BTC для досягнення доступності даних у Rollup, якщо дані, які потрібно видобути, не автоматично публікуються на блокчейн, стан Rollup не може змінитися. Використання Validiums, ця гарантія повністю залежить від здатності використання зовнішньої системи відстоювати обман та сховання даних.
Тепер будь-який Блок-продюсер на системі доступності зовнішніх даних може перехоплювати кошти користувачів BTCRollup, виробляючи Блоки замість фактичного мовлення про ці Блоки, щоб зробити дані доступними.
Таким чином, якщо ми дійсно здійснимо ідеальну реалізацію Rollup на BTC, справжньо забезпечимо виведення коштів користувача в одному напрямку, як це буде?