Основна перевага полягає в зменшенні обсягу даних, що зберігаються в Ethereum, тим самим зменшуючи витрати для користувачів на транзакції на L2.
**Автор: **OneTrueKirk
Складач: Yvonne, MarsBit
Оригінальна публікація від OneTrueKirk на ethresear.ch
Це мій перший раз, коли я пишу про цю тему, тому перепрошую, якщо чимось образив вас. Я думав про цю ідею (Stateless Rollups), здебільшого спеціалізовані зведені програми для нашого протоколу кредитування, але, сподіваюся, вона може бути загальнозастосовною, будь-який відгук буде вдячний.
TLDR:
Публікується лише корінь стану, а не дані виклику.
(Примітка MarsBit: Calldata — це значення частини даних у транзакції контракту, яке не можна змінити.)
деталь
Що, якщо замість використання Ethereum як рівня доступності даних опублікувати повний стан як calldata та опублікувати лише кореневий стан у основній мережі? Основна перевага полягає в зменшенні обсягу даних, що зберігаються в Ethereum, тим самим зменшуючи витрати користувачів на транзакції на L2. Навіть з EIP-4844 blobace не є безкоштовним.
Основним ризиком є атака із затримкою даних, коли пропонент публікує дійсний кореневий стан, але приховує повні дані з інших вузлів зведення, щоб монополізувати майбутнє виробництво блоків або тримати кошти в заручниках. Щоб запобігти цьому, чесні вузли повинні поставити під сумнів будь-яке оновлення стану, для якого жоден одноранговий вузол не може надати дані. Інтерактивні докази шахрайства в стилі Arbitrum можна використовувати, щоб змусити пропонентів розкрити повний стан основної мережі, але все одно спричинити невдачу виклику, якщо корінь дійсний, тому навіть у разі невдачі вартість виклику буде низькою.
(Примітка MarsBit: атака на приховування даних стосується того, що зловмисник навмисно не повертає всі дані або повертає неправильні дані під час доступу до захищених даних, щоб досягти мети обману або знищення.
Якщо вартість невдалого виклику низька, чесних заявників можна зробити нещасними, змусивши їх платити за розміщення всіх своїх даних про стан у головній мережі на захист виклику, навіть якщо вони правильно поширювали дані про стан між точками. Вартість ініціювання оскарження має бути пропорційною вартості захисту, щоб гарантувати, що чесні заявники не можуть бути атаковані таким чином.
У гіршому випадку, якщо зловмисник може витратити 1 долар, щоб чесний пропонент коштував 1 долар, він може змусити того, хто пропонує відмовитися, і повернути свій блок. Тоді новий чесний пропонент може зробити ставку, і якщо зловмисник не зможе повторити атаку на всіх потенційних чесних пропонентів, включаючи всіх, хто має кошти, вони не можуть призвести до постійного простою. Можна додати інше положення, де вартість виклику зростає, коли минуло занадто багато часу з моменту завершення дійсного блоку. Таким чином легко кинути виклик нечесному пропоненту, але неможливо надовго зупинити зміни стану.
Більш оптимістично, якщо вузли розподіляють дані між одноранговими вузлами, вони можуть вирішувати власні рішення для резервного копіювання даних і доступності, а користувачам краще локально зберігати дані, необхідні для власних переходів між станами. У контексті однієї конкретної програми я думав про кодування стану згортання зовсім іншим способом, ніж EVM, щоб оптимізувати для цього. Увесь стан, пов’язаний із певним обліковим записом користувача, можна закодувати в той самий хеш, тож користувачі можуть легше перевіряти зміни у своєму обліковому записі, не знаючи глобального стану (тобто підтверджуючи, що ви отримали кількість маркерів, не турбуючись про те, звідки вони надійшли).
Підведіть підсумки
Я хотів би почути ваші думки та був би вдячний за посилання на відповідну роботу. На відміну від звичайного оптимістичного зведення, у оптимістичному зведенні легко визначити, чи надіслані дані виклику відповідають кореню стану основної мережі, і чи обидва вони дійсні, але неможливо дізнатися, чи оновлення дійсне лише з кореня стану, тому необхідно ретельно розглянути економіку періодів виклику та печалі (тобто зловмисної поведінки).
Переглянути оригінал
Контент має виключно довідковий характер і не є запрошенням до участі або пропозицією. Інвестиційні, податкові чи юридичні консультації не надаються. Перегляньте Відмову від відповідальності , щоб дізнатися більше про ризики.
Короткий огляд переваг і потенційних проблем зведеного пакету без збереження даних
**Автор: **OneTrueKirk
Складач: Yvonne, MarsBit
Оригінальна публікація від OneTrueKirk на ethresear.ch
Це мій перший раз, коли я пишу про цю тему, тому перепрошую, якщо чимось образив вас. Я думав про цю ідею (Stateless Rollups), здебільшого спеціалізовані зведені програми для нашого протоколу кредитування, але, сподіваюся, вона може бути загальнозастосовною, будь-який відгук буде вдячний.
TLDR:
Публікується лише корінь стану, а не дані виклику.
(Примітка MarsBit: Calldata — це значення частини даних у транзакції контракту, яке не можна змінити.)
деталь
Що, якщо замість використання Ethereum як рівня доступності даних опублікувати повний стан як calldata та опублікувати лише кореневий стан у основній мережі? Основна перевага полягає в зменшенні обсягу даних, що зберігаються в Ethereum, тим самим зменшуючи витрати користувачів на транзакції на L2. Навіть з EIP-4844 blobace не є безкоштовним.
Основним ризиком є атака із затримкою даних, коли пропонент публікує дійсний кореневий стан, але приховує повні дані з інших вузлів зведення, щоб монополізувати майбутнє виробництво блоків або тримати кошти в заручниках. Щоб запобігти цьому, чесні вузли повинні поставити під сумнів будь-яке оновлення стану, для якого жоден одноранговий вузол не може надати дані. Інтерактивні докази шахрайства в стилі Arbitrum можна використовувати, щоб змусити пропонентів розкрити повний стан основної мережі, але все одно спричинити невдачу виклику, якщо корінь дійсний, тому навіть у разі невдачі вартість виклику буде низькою.
(Примітка MarsBit: атака на приховування даних стосується того, що зловмисник навмисно не повертає всі дані або повертає неправильні дані під час доступу до захищених даних, щоб досягти мети обману або знищення.
Якщо вартість невдалого виклику низька, чесних заявників можна зробити нещасними, змусивши їх платити за розміщення всіх своїх даних про стан у головній мережі на захист виклику, навіть якщо вони правильно поширювали дані про стан між точками. Вартість ініціювання оскарження має бути пропорційною вартості захисту, щоб гарантувати, що чесні заявники не можуть бути атаковані таким чином.
У гіршому випадку, якщо зловмисник може витратити 1 долар, щоб чесний пропонент коштував 1 долар, він може змусити того, хто пропонує відмовитися, і повернути свій блок. Тоді новий чесний пропонент може зробити ставку, і якщо зловмисник не зможе повторити атаку на всіх потенційних чесних пропонентів, включаючи всіх, хто має кошти, вони не можуть призвести до постійного простою. Можна додати інше положення, де вартість виклику зростає, коли минуло занадто багато часу з моменту завершення дійсного блоку. Таким чином легко кинути виклик нечесному пропоненту, але неможливо надовго зупинити зміни стану.
Більш оптимістично, якщо вузли розподіляють дані між одноранговими вузлами, вони можуть вирішувати власні рішення для резервного копіювання даних і доступності, а користувачам краще локально зберігати дані, необхідні для власних переходів між станами. У контексті однієї конкретної програми я думав про кодування стану згортання зовсім іншим способом, ніж EVM, щоб оптимізувати для цього. Увесь стан, пов’язаний із певним обліковим записом користувача, можна закодувати в той самий хеш, тож користувачі можуть легше перевіряти зміни у своєму обліковому записі, не знаючи глобального стану (тобто підтверджуючи, що ви отримали кількість маркерів, не турбуючись про те, звідки вони надійшли).
Підведіть підсумки
Я хотів би почути ваші думки та був би вдячний за посилання на відповідну роботу. На відміну від звичайного оптимістичного зведення, у оптимістичному зведенні легко визначити, чи надіслані дані виклику відповідають кореню стану основної мережі, і чи обидва вони дійсні, але неможливо дізнатися, чи оновлення дійсне лише з кореня стану, тому необхідно ретельно розглянути економіку періодів виклику та печалі (тобто зловмисної поведінки).