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