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

Для того, щоб зрозуміти вищезазначені дві ключові точки, давайте почнемо з питань DA та утримання даних. Повна назва DA - Цінність даних, що буквально перекладається як доступність даних. Зараз цим терміном зловживають багато людей. Навіть до такої міри, що його серйозно плутають з “історичні дані можуть бути перевірені”. Але насправді проблеми “історичні дані можуть бути перевірені” та “доказ зберігання” вже вирішені у Filecoin та Arweave. Згідно з Фондом Ethereum та Celestia, питання DA чисто досліджує сценарії утримання даних.

Дерево Меркла, корінь Меркла та доказ Меркла

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

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

(Запис у нижній частині малюнка є вихідним набором даних, що відповідає листовому вузлу)Корінь Меркла має властивість:Якщо листовий вузол у нижній частині дерева Меркла змінюється, обчислений корінь Меркла також зміниться. Таким чином, дерева Меркла, що відповідають різним вихідним наборам даних, матимуть різні корені Меркла, так само, як у різних людей різні відбитки пальців. Технологія перевірки доказів під назвою Merkle Proof використовує цю властивість дерева Меркла. Візьмемо для прикладу наведену вище картинку, якщо Лі Ган знає лише значення Кореня Меркла на малюнку, він не знає, які дані містить повне Дерево Меркла. Ми хочемо довести Лі Гану, що Запис 3 дійсно пов'язаний з Коренем на малюнку, або, іншими словами, довести, що хеш Запису 3 існує на Дереві Меркла, що відповідає Кореню. Нам потрібно лише надіслати Record3 і три блоки даних дайджесту, позначені сірим кольором, Лі Гану, без необхідності надсилати все дерево Меркла або всі його листові вузли. Така простота Merkle Proof.Коли базові записи Дерева Меркла містять дуже багато листків, наприклад, воно містить від 2 до 20-го степеня блоків даних (приблизно 1 мільйон), Merkle Proof повинен містити лише принаймні 21 блок даних.

(Блок даних 30 і H2 на малюнку можуть становити доказ Меркла, доводячи, що блок даних 30 існує на дереві Меркла, що відповідає H0)Ця «простота» Merkle Proof часто використовується в Bitcoin, Ethereum або кросчейн-мостах. Світловий вузол, який ми знаємо, насправді є згаданим вище Лі Ганом. Він отримує лише заголовок блоку від повного вузла, а не від усього блоку. Тут слід підкреслити, що Ethereum використовує дерево Меркла під назвою State Trie, щоб служити підсумком усіх облікових записів. До тих пір, поки статус облікового запису, пов'язаного з State Trie, буде змінюватися корінь Меркла State Trie, званий StateRoot. У заголовку блоку Ethereum буде записаний StateRoot, а також буде записаний корінь Меркла дерева транзакцій (іменований як Txn Root), одна з відмінностей між деревом транзакцій і деревом станів полягає в тому, що дані, представлені базовими листками, відрізняються. Якщо блок No 100 містить 300 транзакцій, то листочки дерева транзакцій представляють ці 300 Txn. Ще одна відмінність полягає в тому, що загальний обсяг даних State Trie надзвичайно великий. Його нижні листки відповідають усім адресам у ланцюжку Ethereum (насправді існує безліч застарілих хешів станів), тому вихідний набір даних, що відповідає State Trie, не буде оприлюднено. У блоці в заголовку блоку записується тільки StateRoot. Вихідним набором даних дерева транзакцій є дані Txn у кожному блоці, а TxnRoot цього дерева буде записаний у заголовку блоку.

Оскільки легкий вузол отримує лише заголовок блоку та знає тільки StateRoot та TxnRoot, він не може вивести повне дерево Меркля на основі кореня (це визначається властивостями дерева Меркля та хеш-функції), тому легкі вузли не можуть знати дані транзакцій, що містяться в блоку, а також не знають, які зміни відбулися в обліковому записі, відповідному до State Trie. Якщо Ван Цян хоче довести легкому вузлу (перебуває згаданий раніше Лі Ган) те, що блок № 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 у заголовку блоку No 100 (іншими словами, це довести, що ініційований вами кросчейн Txn записаний у блоці Polygon 100.). Однак ZK Bridge використовуватиме доказ з нульовим розголошенням, щоб стиснути суму розрахунку, необхідну для перевірки Merkle Proof, що ще більше знизить вартість перевірки контрактів на кросчейн-мости.

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

Після розмови про дерево Меркла, корінь Меркла та доказ Меркла давайте повернемося до питання DA та атак з утриманням даних, згаданих на початку статті. Це питання обговорювалося ще з 2017 року. Оригінальна стаття Celestia містить джерело проблеми DA. Віталік сам зазначив у документі з 2017 по 2018 рік, що блок-продюсер може усвідомлено приховати певні фрагменти даних блоку і випустити неповні блоки на зовнішній світ. У результаті повний вузол не може підтвердити правильність виконання транзакції / переходу стану.

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

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

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

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

Примітка: ДА Вибіркове даних (DAS) та Celestia не є основною темою цієї статті. Зацікавлені читачі можуть прочитати минулі статті "Geek Web3":«Непорозуміння доступності даних: DA = Видання даних ≠ Пошук історичних даних»

доказ про шахрайство Плазми

Простіше кажучи, Плазма — це рішення для розширення, яке публікує лише заголовок блоку Layer2 до Layer1, а дані DA поза заголовком блоку (повний набір даних про транзакції/зміни стану кожного облікового запису). Іншими словами, Плазма схожа на кросчейн-міст, заснований на легких клієнтах. Він використовує контракти для реалізації легких клієнтів рівня 2 у ланцюжку ETH. Коли користувачі заявляють, що вони хочуть перетнути активи з L2 на L1, вони повинні надати доказ Меркла, щоб довести свою правоту. володіє цими активами. Логіка перевірки перетину активів з L2 до L1 подібна до згаданого вище мосту ZK, за винятком того, що мостова модель Plasma базується на доказі шахрайства, а не на доказі ZK, і є ближчою до так званого «оптимістичного мосту». Запити на виведення коштів з L2 до L1 у мережі Plasma не будуть оприлюднені негайно, але буде "період виклику". Що стосується мети періоду челенджу, ми розповімо нижче.

У Плазмі немає жорстких вимог до вивільнення даних/DA. Секвенсор/Оператор транслює лише кожен блок L2 поза мережею, а вузли, які бажають отримати блоки L2, можуть отримати його самостійно. Після цього сортувальник опублікує заголовок блоку L2 в Layer1. Наприклад, секвенсор спочатку транслює блок No 100 поза мережею, а потім публікує заголовок блоку в ланцюжок. Якщо блок 100 містить недійсні транзакції, будь-який вузол Плазми може подати доказ Меркла до контракту на ETH до закінчення "періоду виклику". Доведіть, що заголовок блоку No 100 може бути пов'язаний з недійсною транзакцією, це сценарій, на який поширюється доказ шахрайства.

Сценарії захисту від шахрайства у Плазмі також включають наступне:1. Припустимо, що прогрес мережі Плазми досягає блоку No 200. У цей час користувач А ініціює заяву про виведення коштів, кажучи, що коли він був у блоці No100, у нього було 10 ETH. Але насправді користувач А витратив ETH на свій рахунок після 100 блоку. Таким чином, поведінка А насправді така: витративши 10 ETH, він заявляє, що в минулому у нього було 10 ETH, і намагається вивести ці ETH. Це типове «подвійне зняття» і подвійні витрати. У цей час будь-хто може надати доказ Меркла, щоб довести, що останній статус активу користувача А не задовольняє його заяві про виведення коштів, тобто довести, що А не зняв гроші, зазначені після блоку 100. (У різних схемах Плазми для цієї ситуації використовуються несумісні методи доказування, а модель адреси облікових записів є набагато складнішою, ніж доведення подвійних витрат у UTXO). 2. Якщо це рішення Плазми, засноване на моделі UTXO (в основному так було в минулому), заголовок блоку не містить StateRoot, а лише TxnRoot (UTXO не підтримує модель адреси облікового запису в стилі Ethereum, і немає глобального стану, такого як State Trie). Іншими словами, ланцюжок, що використовує модель UTXO, має лише записи транзакцій і не має записів про статус. У цей час секвенсор сам може запустити атаку подвійних витрат, наприклад, витратити UTXO, який був витрачений знову, або видати користувачеві додатковий UTXO на рівному місці. Будь-який користувач може надати доказ Меркла, щоб довести, що запис про використання UTXO з'являвся (був витрачений) у минулих блоках, або щоб довести, що існує проблема з історичним джерелом певного UTXO.

1. Для сумісних з EVM/підтримуваними деревами стану рішень Plasma сортувальник може подати недійсний StateRoot. Наприклад, після виконання транзакції, що міститься у 100-му блоку, StateRoot повинен був бути перетворений на ST+, але сортувальник переходить до Layer1. Те, що було подано, — це ST-. Доказ шахрайства у цьому випадку є більш складним і вимагає повторного відтворення транзакції у блоку № 100 на ланцюгу Ethereum. Розрахункова сума та необхідні вхідні параметри вимагатимуть значну кількість газу. Команди, які рано прийняли Plasma, мали складнощі з досягненням таких складних доказів шахрайства, тому більшість з них прийняла модель UTXO. В кінці кінців, докази шахрайства на основі UTXO є простими та легкими у впровадженні. (Fuel, перше рішення rollup, яке надає докази шахрайства, ґрунтується на UTXO)

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

У цей момент секвенсор може вкрасти активи користувача,наприклад, приватно перевести всі монети з рахунку А на рахунок Б, потім перевести гроші з рахунку В на рахунок С і, нарешті, ініціювати виведення коштів на ім'я С. Рахунки В і С належать самому секвенсеру. Навіть якщо передача B->C буде оприлюднена, вона не завдасть жодної шкоди; Але сортувальник може приховати дані недійсної передачі А->В, і люди не можуть довести, що є проблема з джерелом активів Б і С.(Щоб довести, що джерело активів Б є сумнівним, необхідно вказати, що цифровий підпис «певний Txn, переданий Б» є неправильним). Плазмовий розчин на основі UTXO має цільові заходи. Наприклад, коли хтось ініціює виведення коштів, він повинен надати всі історичні джерела активів. Звичайно, пізніше буде більше заходів з благоустрою. Але якщо це EVM-сумісний плазмовий розчин, він буде здаватися слабким у цій області. Оскільки, якщо задіяний Txn, пов'язаний з контрактом, перевірка процесу переходу стану в ланцюжку спричинить величезні витрати, тому Plasma, яка підтримує моделі адрес облікових записів і смарт-контракти, не може легко реалізувати схему перевірки дійсності зняття коштів. Крім того, окрім наведеної вище теми, незалежно від того, чи це Плазма, заснована на UTXO, чи на моделі адреси облікового запису, як тільки відбувається приховування даних, це в основному спричиняє паніку, оскільки ви не знаєте, які транзакції виконав секвенсер. Вузли Плазми виявлять, що щось не так, але вони не зможуть видати докази шахрайства, оскільки секвенатор Плазми не видав дані, необхідні для доказів шахрайства. У цей час люди можуть бачити лише відповідний заголовок блоку, але вони не знають, що знаходиться в блоці або що стало з активами їхніх облікових записів. Кожен колективно ініціює заяву про виведення коштів і використовує відповідний заголовок блоку. Merkle Proof намагається вивести гроші,запускаючи екстремальний сценарій під назвою «Гра на виході», ця ситуація призведе до «тисняви» », що викличе серйозні затори на рівні 1, і все одно призведе до того, що активи деяких людей будуть пошкоджені. (Люди, які не отримували чесних сповіщень від вузлів або не перевіряють Twitter, не знатимуть, що секвенсер краде монети).

Отже, Плазма є ненадійним рішенням для розширення рівня 2. Як тільки станеться атака на приховування даних, буде запущена «Гра на виході», яка може легко призвести до збитків користувачів. Це основна причина відмови від нього. Чому у Плазми виникають труднощі з підтримкою смарт-контрактівПісля розмови про вихід з гри та проблеми зі збереженням даних, давайте розглянемо, чому Плазма має труднощі з підтримкою смарт-контрактів. Є дві основні причини: По-перше, якщо це актив Defi-контракту, хто повинен вивести його на рівень1? Тому що це, по суті, перенесення статусу контракту з Layer2 на Layer1.Припустимо, хтось вносить 100 ETH в пул LP DEX, а потім секвенсор Плазми робить щось погане, і люди хочуть терміново вивести гроші. На даний момент 100 ETH користувача все ще контролюються контрактом DEX. Хто має володіти цими активами в цей час? Згадується на Layer1? Здається, найкращий спосіб — дозволити користувачам спочатку викупити активи на DEX, а потім дозволити користувачам самостійно переказувати гроші на L1. Але проблема полягає в тому, що засіб для впорядкування Плазми чинить зло і може відхилити запити користувачів у будь-який час. Отже, що, якщо ми заздалегідь налаштуємо власника для контракту DEX і дозволимо йому підняти активи контракту до L1 в екстреній ситуації? Очевидно, що це надасть власнику контракту право власності на державні активи. Він може підняти ці активи до L1 і втекти в будь-який момент. Хіба це не жахливо? Очевидно, що те, як поводитися з цими «державними об'єктами», контрольованими контрактами Defi, є величезним сюрпризом. Звідси фактично виникає проблема розподілу публічної влади. Раніше злодії розповідали в інтерв'ю"Створення нових речей у високопродуктивних громадських ланцюгах важке, смарт-контракти передбачають розподіл потужності"Це було згадано в статті.

По-друге, якщо контракт не допустити до міграції, він зазнає величезних збитків; Якщо контракту буде дозволено перенести його стан на рівень1, відбудеться подвійне зняття, яке важко вирішити в доказі шахрайства Плазми:Наприклад, ми припускаємо, що Плазма використовує модель адреси облікового запису Ethereum і підтримує смарт-контракти., є мікшер, який наразі депонується зі 100 ETH, а власником мікшера керує Боб; припустимо, що Боб знімає 50 ETH з мікшера в 100-му блоці. Після цього Боб ініціює заяву про виведення коштів і переводить 50 ETH на рівень1; потім Боб використовує знімок стану минулого контракту (наприклад, 70-й блок), щоб перенести минулий стан мікшера на Layer1, що призведе до того, що 100 ETH, якими «володів» мікшер, також були перенесені на Layer1; очевидно, що це типове «подвійне зняття», тобто подвійне витрачання.150 ETH були згадані Бобом до рівня 1, але користувачі мережі рівня 2 заплатили лише 100 ETH мікшеру/Бобу, а 50 ETH були зняті на рівному місці. Це може легко виснажити запаси плазми。 Теоретично можна було б ініціювати доказ шахрайства, щоб довести, що стан контракту на змішувач змінився після 70-го блоку. Але якщо після блоку No70 всі Txn, які взаємодіяли з контрактом міксера, не змінили статус контракту, за винятком транзакції, в якій Боб забрав 50 ETH; якщо ви хочете показати докази, вкажіть, що контракт мікшера знаходиться в Якщо після блоку No 70 відбудуться зміни, всі згадані вище Txn повинні бути запущені в ланцюжку Ethereum, і, нарешті, контракт Plasma може бути підтверджений. Статус контракту змішувача дійсно змінився (причина, чому він такий складний, полягає в тому, що він визначається структурою самої плазми). Якщо кількість Txn у цій партії надзвичайно велика, доказ шахрайства взагалі не може бути опублікований на рівні 1. (Він перевищить ліміт газу одного блоку Ethereum).

https://ethresear.ch/t/why-smart-contracts-are-not-feasible-on-plasma/2598Theoretically, у наведеному вище сценарії подвійних витрат, здається, що надсилається лише поточний знімок стану мікшера (насправді доказ Меркла, що відповідає StateRoot), але насправді, оскільки Plasma не публікує дані про транзакції у ланцюжку, контракт не може визначити, чи є ви Чи є надісланий знімок стану дійсним. Це пов'язано з тим, що секвенсер сам може ініціювати приховування даних, надсилати недійсні знімки стану та зловмисно компрометувати будь-якого відкликача. Наприклад, коли ви заявляєте, що у вас на рахунку є 50 ETH, і ініціюєте виведення коштів, секвенсер може приватно очистити ваш рахунок до 0, потім ініціювати утримання даних, відправити недійсний StateRoot в ланцюжок і відправити відповідний знімок стану , помилково звинувативши вас в тому, що у вас закінчилися гроші на рахунку. Наразі ми не можемо довести, що StateRoot та снапшот стану, надіслані секвенсером, є недійсними, оскільки він ініціював приховування даних, і ви не можете отримати достатньо даних, необхідних для доказу шахрайства. Щоб запобігти цьому, коли вузол Плазми показує знімок стану, щоб довести, що хтось витратив подвійно, він також відтворюватиме записи транзакцій протягом цього періоду. Це може перешкодити секвенсеру використовувати приховування даних, щоб інші не могли виводити гроші. У Rollup, якщо ви зіткнулися з вищезгаданим подвійним зняттям, теоретично немає необхідності перегравати історичні транзакції, тому що Rollup не має проблем з утриманням даних і «змусить» секвенсор публікувати дані DA в ланцюжку. Якщо секвенсер Rollup надішле недійсний знімок стану StateRoot, він або не пройде перевірку контракту (ZK Rollup), або буде оскаржений найближчим часом (OP Rollup). Насправді, на додачу до згаданого вище прикладу з змішувачем монет, такі сценарії, як контракти з мультипідписом, також можуть призвести до подвійного зняття коштів у мережі Plasma. Доказ шахрайства дуже неефективний у вирішенні цього сценарію. Ця ситуація аналізується в ETH Research. Підсумовуючи, можна сказати, що оскільки рішення Плазми не сприяє створенню смарт-контрактів і в основному не підтримує перенесення статусу контрактів на рівень 1, основна Плазма має використовувати UTXO або подібні механізми. Оскільки UTXO не має проблеми конфліктів власності на активи і може дуже добре підтримувати захист від шахрайства (він набагато менший за розміром), ціна полягає в тому, що він має єдиний сценарій застосування і в основному може підтримувати лише перекази або обмін книгами ордерів. Крім того, оскільки доказ шахрайства сам по собі має сильну залежність від даних DA, якщо рівень DA ненадійний, буде важко впровадити ефективну систему захисту від шахрайства. Втім, Плазма надто грубо розв'язує задачу DA і не може розв'язати проблему атак на приховування даних. З появою Rollup Плазма повільно зникала зі сцени історії.

Disclaimer：

1. Ця стаття перепечатана з [ Публічний обліковий запис WeChat: Geek Web3]. Усі авторські права належать оригінальному автору [Фауст]. Якщо є зауваження до цього повторного видання, будь ласка, зв'яжіться з Gate Learnкоманда, і вони швидко займуться цим.
2. Відмова від відповідальності: Погляди та думки, висловлені в цій статті, належать виключно автору і не становлять жодної інвестиційної поради.
3. Переклади статей на інші мови виконуються командою Gate Learn. Якщо не зазначено інше, копіювання, поширення або плагіатування перекладених статей заборонене.