Приховування даних та захист від шахрайства: чому у Плазмі не передбачено підтримки смарт-контрактів

Автор: Фауст, гік web3

Що стосується того, чому Плазма була похована протягом тривалого часу, і чому Віталік рішуче підтримуватиме Rollup, підказки в основному вказують на два моменти: впровадження DA off-chain у ланцюжку Ethereum є ненадійним, а приховування даних легко відбувається, а як тільки відбувається приховування даних, докази шахрайства важко розробити; ** Ці два пункти роблять Плазму в основному лише UTXO або приблизними моделями.

Щоб зрозуміти ці два основні моменти, давайте почнемо з DA та збереження даних. DA розшифровується як Data Avalibility, що буквально перекладається як доступність даних, і зараз багато людей зловживають, настільки, що його серйозно плутають з «історичні дані можна перевірити». Але насправді «історичні дані» та «доказ зберігання» є давніми проблемами, які були вирішені такими компаніями, як Filecoin та Arweave. За даними Ethereum Foundation і Celestia, проблема DA пов’язана виключно зі сценаріями приховування даних. **

Дерево Меркла & Корінь Меркла & Доказ Меркла

Щоб проілюструвати, що означають атаки на приховування даних та проблеми з DA, нам потрібно спочатку коротко поговорити про Merkle Root та Merkle Tree. **В Ethereum або більшості публічних ланцюгів деревоподібна структура даних, яка називається деревом Меркла, використовується як зведення/каталог стану всього облікового запису або для запису транзакцій, упакованих у кожен блок.

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

(Запис у нижній частині діаграми є вихідним набором даних, що відповідає листовому вузлу)

Корінь Меркла має властивість: якщо листовий вузол у нижній частині дерева Меркла змінюється, обчислений корінь Меркла також зміниться. Таким чином, дерева Меркла, що відповідають різним вихідним наборам даних, матимуть різні корені Меркла, так само, як різні люди мають різні відбитки пальців. Технологія перевірки доказів, відома як Доказ Меркла, використовує цю властивість дерева Меркла.

Наприклад, якщо Лі Ган знає лише значення кореня Меркла на малюнку, він не знає, які дані містить повне дерево Меркла. Нам потрібно довести Лі Гану, що Запис 3 дійсно пов’язаний з коренем на малюнку, або що хеш Запису 3 існує на дереві Меркла, що відповідає кореню.

Нам потрібно лише відправити Record3 і 3 блоки дайджесту, позначені сірим кольором, до Li Gang, замість того, щоб зберігати все дерево Меркла або всі його листові вузли, що є простотою Merkle Proof. Коли базовий запис дерева Меркла має велику кількість листків, наприклад, 2 в ступені 2 блоків даних (близько 1 мільйона), доказ Меркла повинен містити лише принаймні 21 блок даних.

(Блок даних 30 і H2 на малюнку може бути доказом Меркла, доводячи, що блок даних 30 існує на дереві Меркла, що відповідає H0)**

У Bitcoin, Ethereum або кросчейн-мостах часто використовується ця «простота» Merkle Proof. Легкий вузол, який ми знаємо, насправді є вищезгаданим Лі Ганом, який отримує заголовок блоку лише від повного вузла, а не від повного блоку. Тут важливо підкреслити, що Ethereum використовує дерево Меркла під назвою State Trie, яке діє як підсумок усього облікового запису. Корінь Меркла в State Trie, званий StateRoot, змінюється щоразу, коли змінюється стан одного з облікових записів, пов’язаних зі штатом Трі.

У заголовку блоку Ethereum буде записаний StateRoot, а також буде записаний корінь Меркла (іменований як Txn Root) дерева транзакцій. Якщо блок 100 містить 300 транзакцій, то листочки торгового дерева представляють ці 300 Txn.

Ще одна відмінність полягає в тому, що загальний обсяг даних в State Trie особливо великий, а його базовий лист відповідає всім адресам в ланцюжку Ethereum (насправді існує безліч застарілих хешів станів), тому вихідний набір даних, відповідний State Trie, не буде опублікований в блоці, в заголовку блоку буде записаний тільки StateRoot. Вихідним набором даних дерева транзакцій є дані Txn у кожному блоці, а TxnRoot дерева буде записаний у заголовку блоку.

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

Якщо Ван Цян хоче довести легкому вузлу (Лі Ган згадував раніше), що блок 100 містить певну транзакцію, і відомо, що легкий вузол знає заголовок блоку 100 і знає TxnRoot, то вищевказана проблема перетворюється на: довести, що цей Txn існує на дереві Меркла, що відповідає TxnRoot. У цей час Ван Цяну потрібно лише подати відповідний доказ Меркла.

У багатьох кросчейн-мостах, заснованих на легких клієнтських рішеннях, часто використовується легкість і простота світлових вузлів і згаданий вище доказ Меркла. Наприклад, мости ZK, такі як Map Protocol, встановлять контракт у ланцюжку ETH для отримання заголовків блоків від інших ланцюгів (наприклад, Polygon). Коли Relayer надішле заголовок 100-го блоку Polygon контракту в ланцюжку ETH, контракт перевірить валідність заголовка (наприклад, чи достатньо в ньому підписів від 2/3 POS-вузлів у мережі Polygon).

Якщо заголовок дійсний і користувач заявляє, що він ініціював кросчейн Txn від Polygon до ETH, Txn упаковується в 100-й блок Polygon. Йому потрібно лише довести за допомогою доказу Меркла, що ініційований ним кросчейн Txn може відповідати TxnRoot заголовка блоку 100 (іншими словами, це доводить, що кросчейн Txn, який він ініціював, має запис у блоці 100 Polygon). Однак міст ZK використовуватиме докази з нульовим розголошенням, щоб стиснути обсяг обчислень, необхідних для перевірки Merkle Proof, що ще більше знизить вартість перевірки контрактів на кросчейн-мости.

Проблеми з DA та атаками на збереження даних

Після розмови про Merkle Tree та Merkle Root and Merkle Proof, давайте повернемося до проблеми DA та атак приховування даних, згаданих на початку статті, яка була досліджена до 2017 року, і оригінальна стаття Celestia археологізувала походження проблеми DA. У документі 2017~18 року сам Віталік говорив про те, як блокувальники можуть навмисно приховувати певні фрагменти даних блоку та публікувати неповні блоки, щоб повні ноди не могли підтвердити правильність виконання транзакцій/переходів станів.

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

У публічних ланцюжках рівня 1, таких як Bitcoin або Ethereum, чесні повні ноди безпосередньо відхилятимуть вищезазначені недійсні блоки. Але легкі ноди відрізняються, вони отримують тільки заголовок блоку з мережі, вони знають тільки StateRoot і TxnRoot, і вони не знають, чи дійсний оригінальний блок, що відповідає заголовку і двом коренем.

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

Але Сатоші Накамото не став робити більш детальний аналіз цього рішення, і пізніше засновник Vitalik і Celestia Мустафа розвинув цю ідею, в поєднанні з роботою інших попередників, щоб запровадити вибірку даних DA, щоб гарантувати, що чесні повні ноди можуть відновити повні дані кожного блоку та підняти тривогу, коли це необхідно.

Примітка: DA Data Sampling (DAS) та Celestia не є предметом цієї статті, зацікавлені читачі можуть прочитати попередню статтю Geek Web3: “Хибні уявлення про доступність даних: DA= Data Publishing ≠ Historical Data Retrieval”

Доказ шахрайства у Плазмі

Простіше кажучи, Плазма — це рішення для масштабування, яке публікує лише заголовки блоків рівня 2 на рівні 1, а дані DA поза заголовком блоку (повний набір даних транзакцій/зміна стану для кожного облікового запису) публікуються лише поза мережею. Іншими словами, Plasma схожа на кросчейн-міст, заснований на легких клієнтах, що реалізує легкий клієнт рівня 2 з контрактом у ланцюжку ETH, і коли користувач заявляє, що хоче перетнути активи з L2 на L1, він повинен надати доказ Меркла, щоб довести, що він дійсно володіє активами.

**Логіка перевірки для активів, що охоплюють діапазон від L2 до L1, подібна до згаданого вище мосту ZK, за винятком того, що модель мосту Plasma базується на доказах шахрайства, а не на доказах ZK, що ближче до так званого «оптимістичного мосту». **Запити на виведення коштів з L2 до L1 у мережі Plasma не оприлюднюються негайно, але мають «період виклику», що стосується мети періоду виклику, ми пояснимо нижче.

Плазма не має жорстких вимог до вивільнення даних/DA, секвенсор/оператор просто транслює кожен блок L2 поза мережею, а вузли, які бажають отримати блок L2, роблять це самостійно. Після цього секвенсор опублікує заголовок блоку L2 на Layer 1. Наприклад, секвенсор транслює блок 100 поза мережею, а потім публікує заголовок блоку ончейн. Якщо блок 100 містить недійсні транзакції, будь-який вузол плазми може подати доказ Меркла до контракту на ETH до кінця «періоду виклику», щоб довести, що заголовок блоку 100 може бути пов’язаний з недійсною транзакцією, що є сценарієм, на який поширюються докази шахрайства.

До доказів шахрайства у Плазмі також належать такі випадки:

1. Припустимо, прогрес мережі Плазми досягає блоку 200, і користувач А ініціює заяву про виведення коштів, кажучи, що у нього є 10 ETH у блоці 100. Але насправді користувач А витратив ETH на акаунт після 100 блоку.

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

2. Якщо це схема Плазми, заснована на моделі UTXO (що в основному було в минулому), то в заголовку блоку немає StateRoot, є лише TxnRoot (UTXO не підтримує модель адреси облікового запису в стилі Ethereum, а також не має глобального дизайну стану, як State Trie). Іншими словами, ланцюжок, який використовує модель UTXO, має лише записи транзакцій, а не записи стану.

У цьому випадку секвенсор сам може запустити атаку подвійних витрат, наприклад, витратити вже витрачений UTXO або видати користувачеві додаткові UTXO на рівному місці. Будь-який користувач може надіслати доказ Меркла, щоб довести, що історія використання UTXO з’являлася (була витрачена) у попередніх блоках, або щоб довести, що історичне походження UTXO є сумнівним. **

3. Для EVM-сумісних схем Плазми з підтримкою State-Trie секвенсер може надіслати недійсний StateRoot, наприклад, після виконання транзакції, що міститься у блоці 100, StateRoot має бути перетворено на ST+, але секвенсер надсилає ST- на рівень 1.

У цьому випадку доказ шахрайства є складнішим і вимагає повторного відтворення транзакції в блоці 100 у ланцюжку Ethereum, який споживає багато газу з необхідною кількістю обчислень та вхідних параметрів. ** Раннім командам із впровадження Плазми важко досягти таких складних доказів шахрайства, тому більшість із них використовують модель UTXO, зрештою, докази шахрайства на основі UTXO є дуже простими та легкими у застосуванні** (Fuel, перша схема Rollup, яка запускає докази шахрайства, заснована на UTXO)

Збереження даних і вихід з гри****

Звичайно, вищезгадані сценарії, за яких докази шахрайства можуть набути чинності, встановлюються лише тоді, коли DA/оприлюднення даних є дійсним. Якщо секвенсер приховує дані і не публікує повний блок поза мережею, вузол Плазми не зможе підтвердити, чи є заголовок блоку на рівні 1 дійсним, і, звичайно ж, він не зможе безперешкодно опублікувати доказ шахрайства.

У цей час секвенсер може вкрасти активи користувача, наприклад, перевести всі монети з рахунку А на рахунок Б, потім перевести гроші з рахунку Б на рахунок С і, нарешті, ініціювати виведення коштів на ім’я С. Облікові записи B і C належать секвенсеру, і передача B->C є нешкідливою, навіть якщо вона оприлюднена.** Але секвенсер може приховати дані про недійсну передачу A->B, і люди не можуть довести, що існує проблема з джерелом активів B і C** (щоб довести, що джерело активів B є проблематичним, необхідно зазначити, що цифровий підпис «певного Txn, переданого B» є неправильним).

Рішення Plasma на основі UTXO орієнтоване на те, що будь-хто, хто ініціює виведення коштів, повинен надати повну історію активу, хоча пізніше з’являться інші покращення. Однак, якщо це EVM-сумісний плазмовий розчин, він буде слабким у цій області. Тому що, якщо буде задіяний Txn, пов’язаний з контрактом, перевірка процесу переходу стану в ланцюжку буде пов’язана з величезними витратами, тому важко реалізувати схему перевірки дійсності зняття коштів за допомогою підтримки моделі адреси облікового запису та смарт-контракту Plasma.

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

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

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

Причини, через які Плазма ускладнює підтримку смарт-контрактів****

Після розмови про вихід із гри та проблеми зі збереженням даних, давайте розглянемо, чому Плазму важко підтримувати смарт-контракти, головним чином з двох причин:

По-перше, якщо це актив Defi-контракту, хто повинен вивести його на рівень 1? Оскільки це, по суті, перенесення стану контракту з рівня 2 на рівень 1, припустимо, хтось стягує 100 ETH з LP-пулу DEX, а потім секвенсор Plasma робить зло, і люди хочуть терміново вивести, в цей час 100 ETH користувача все ще контролюються контрактом DEX, хто повинен згадувати ці активи на рівень 1 в цей час?

Здається, найкращий спосіб зробити це — дозволити користувачеві спочатку викупити активи з DEX, а потім сам виведе гроші на L1, але проблема полягає в тому, що секвенсор Плазми зробив щось погане і може відхилити запит користувача у будь-який момент.

Отже, що, якщо ми заздалегідь встановимо власника для контракту DEX, що дозволить йому розмістити активи контракту на L1 у разі надзвичайної ситуації? Очевидно, що це дасть власнику контракту право власності на публічні активи, і він може в будь-який момент поставити ці активи на L1 і втекти, хіба це не жахливо?

Очевидно, що робити з цією «державною власністю», в якій домінують контракти Defi, — це величезний грім. **Насправді це пов’язано з проблемою розподілу публічної влади, про яку Сянма раніше говорив в інтерв’ю «Високопродуктивним публічним мережам важко робити нові речі, а смарт-контракти передбачають розподіл влади».

По-друге, якщо контракту не буде дозволено мігрувати його стан, він зазнає величезних збитків, а якщо контракту буде дозволено перенести свій стан на рівень 1, виникнуть подвійні зняття, які важко вирішити за допомогою доказів шахрайства у Плазмі:

Наприклад, припустімо, що Плазма використовує модель адреси облікового запису Ethereum, підтримує смарт-контракти, має змішувач монет, наразі вносить 100 ETH, а власником мікшера монет керує Боб;

Припустимо, Боб знімає 50 ETH з мікшера на блоці 100. Після цього Боб ініціював заяву про виведення коштів і перетнув 50 ETH до рівня 1;

Після цього Боб використовує знімок минулого стану контракту (наприклад, блок 70), щоб перенести минулий стан мікшера на рівень 1, який також перетне 100 ETH, які мікшер «колись мав» на рівень 1.

Очевидно, що це типова «подвійна просадка», яка є подвійною витратою. 150 ETH були згадані Бобом на рівні 1, але користувачі мережі рівня 2 заплатили лише 100 ETH мікшеру/Бобу, а 50 ETH були зняті на рівному місці. Це може легко виснажити запаси плазми. Теоретично можна було б ініціювати доказ шахрайства, щоб довести, що стан контракту на змішувач змінився після блоку 70.

Але якщо ви хочете продемонструвати докази того, що контракт Mixer змінився після Block 70, вам слід запустити всі Txn, згадані вище, у ланцюжку Ethereum, щоб нарешті дозволити контракту Plasma визначити, що стан контракту Mixer дійсно змінився (причина, чому він такий складний, визначається структурою самої Плазми). Якщо сума Txn настільки велика, доказ шахрайства взагалі не буде опублікований на рівні 1 (він перевищить ліміт газу для одного блоку Ethereum).

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

Наприклад, коли ви заявляєте, що на вашому рахунку є 50 ETH, і ініціюєте виведення коштів, секвенсер може приватно очистити ваш рахунок до 0, а потім ініціювати утримання даних, відправити недійсний StateRoot в ланцюжок і відправити відповідний знімок стану, щоб помилково звинуватити вас у тому, що на вашому рахунку закінчилися гроші. На цьому етапі ви не можете довести, що StateRoot і State Snapshot, надіслані секвенсером, є недійсними, оскільки він ініціював зберігання даних, і ви не отримуєте достатньо даних, необхідних для доказу шахрайства. **

Щоб запобігти цьому, вузол Плазми також відтворює історію транзакцій протягом цього періоду, коли представляє знімок стану, щоб довести, що хтось має подвійні витрати, що не дозволяє секвенсеру приховувати дані, щоб запобігти виведенню даних іншими. У Rollup, якщо ви зіткнулися з вищезгаданим подвійним зняттям, вам не потрібно теоретично перегравати історичну транзакцію, тому що Rollup не має проблеми утримання даних і «змусить» секвенсор опублікувати дані DA в ланцюжку. **Зведені секвенсери, які надсилають недійсний знімок стану StateRoot, або не пройдуть перевірку контракту (ZK Rollup), або незабаром будуть оскаржені (OP Rollup).

Насправді, на додаток до згаданого вище прикладу з змішувачем монет, такі сценарії, як контракти з мультипідписом, також можуть призводити до подвійного зняття коштів у мережі Plasma. Докази шахрайства неефективні в таких сценаріях. **Ця ситуація проаналізована в ETH Research.

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

Крім того, оскільки доказ шахрайства сам по собі має сильну залежність від даних DA, буде важко досягти ефективної системи доказу шахрайства, якщо рівень DA ненадійний. Втім, обробка задач DA у Плазмі є надто примітивною, щоб розв’язати проблему атак на приховування даних, і з появою Rollup Плазма повільно зникла з історії. **