Дорожня карта Ethereum спочатку містила дві стратегії масштабування: шардінг та протоколи Layer2. Шардінг дозволяє кожному вузлу перевіряти та зберігати лише невелику частину транзакцій, тоді як Layer2 будує мережу поверх Ethereum, використовуючи його безпеку, одночасно зберігаючи більшість даних та обчислень поза основним ланцюгом. Ці два шляхи врешті-решт об'єдналися, утворивши дорожню карту, зосереджену на Rollup, яка досі залишається основною стратегією розширення Ethereum.
Дорожня карта, зосереджена на Rollup, пропонує чіткий розподіл обов'язків: Ethereum L1 зосереджується на тому, щоб стати потужним і децентралізованим базовим шаром, тоді як L2 бере на себе завдання допомагати екосистемі розширюватися. Ця модель є поширеною в суспільстві, подібно до судової системи (L1), яка існує для захисту контрактів і прав власності, тоді як підприємці (L2) здійснюють інновації на цій основі.
Цього року цей дорожня карта досягла важливого прогресу: запуск EIP-4844 blobs суттєво збільшив пропускну здатність даних Ethereum L1, кілька EVM Rollup перейшли до першої стадії. Кожен L2 існує як "шар" з власними правилами та логікою, різноманітність реалізації шарів сьогодні стала реальністю. Але цей шлях також стикається з деякими унікальними викликами. Наше теперішнє завдання полягає в завершенні дорожньої карти, зосередженої на Rollup, вирішуючи ці проблеми, одночасно зберігаючи стійкість і децентралізацію Ethereum L1.
Трикутний парадокс масштабованості стверджує, що між децентралізацією, масштабованістю та безпекою блокчейну існує суперечність. Це не теорема, а вказує на те, що розірвати трикутний парадокс важко, потрібно вийти за межі звичних рамок мислення. Деякі високопродуктивні мережі стверджують, що вирішили трикутний парадокс, але це зазвичай є оманливим, оскільки на цих мережах запуск вузлів є складнішим, ніж на Ethereum.
Однак, поєднання вибірки доступності даних та SNARK-ів дійсно вирішує тріадичний парадокс: це дозволяє клієнту завантажувати лише невелику кількість даних та виконувати дуже мало обчислень, щоб перевірити доступність великої кількості даних та правильність обчислювальних етапів. SNARK-и є бездоказовими, а вибірка доступності даних має тонку модель довіри few-of-N, але зберігає основні характеристики незбільшуваних ланцюгів.
Архітектура Plasma є ще одним рішенням, яке покладає відповідальність за доступність даних на користувачів у спосіб, що стимулює їхню зацікавленість. З поширенням SNARKs, Plasma стає життєздатною для більш широких сценаріїв використання.
Наразі в Ethereum кожні 12 секунд є 3 слоти приблизно по 125 кБ блобів, доступна пропускна здатність даних становить близько 375 кБ. Припустимо, що дані транзакцій безпосередньо публікуються в ланцюзі, переказ ERC20 становить приблизно 180 байтів, тому максимальна TPS для Rollup в Ethereum становить 173.6. Додаючи calldata, можна досягти 607 TPS. Використовуючи PeerDAS, кількість блобів може зрости до 8-16, забезпечуючи для calldata 463-926 TPS.
Це значне покращення, але цього недостатньо. Наша середньострокова мета — 16 МБ на слот, разом із вдосконаленнями стиснення даних Rollup, це призведе до ~58000 TPS.
Що це? Як це працює?
PeerDAS є простою реалізацією "1D sampling". У Ethereum кожен blob є 4096-м поліномом над полем простих чисел з 253 елементів. Ми транслюємо частки полінома, кожна частка містить 16 значень оцінки на сусідніх 16 координатах з 8192 координат. Будь-які 4096 значень оцінки можуть відновити blob.
PeerDAS дозволяє кожному клієнту слухати невелику кількість підмереж, i-та підмережа транслює i-ий зразок будь-якого блобу, клієнт запитує інші блоби в підмережах через запит до однорангових учасників у глобальній p2p мережі. SubnetDAS використовує лише механізм підмереж, без додаткових запитів до однорангового рівня. Поточна пропозиція дозволяє вузлам, що беруть участь у доказі частки, використовувати SubnetDAS, інші вузли використовують PeerDAS.
Теоретично, ми можемо значно розширити масштаб "1D sampling": якщо збільшити максимальну кількість blob до 256, ми зможемо досягти цілі в 16MB, тоді як кожен вузол повинен обробляти 1MB даних на кожен slot. Це навряд чи можливо, але означає, що клієнти з обмеженою пропускною здатністю не зможуть виконувати вибірку. Ми можемо оптимізувати, зменшивши кількість blob та збільшивши їхній розмір, але це призведе до підвищення витрат на відновлення.
Отже, ми врешті-решт хочемо виконати 2D-вібрацію, випадково вибираючи не тільки всередині блобу, але і між блобами. Використовуючи лінійні властивості KZG-комітменту, розширити набір блобів у блоці з набором нових віртуальних блобів, які надмірно кодують ту ж інформацію.
2D вибірка є дружньою до побудови розподіленого блоку, фактичним вузлам, що будують блоки, потрібно лише мати blob KZG зобов'язання і можуть покладатися на вибіркову доступність даних для перевірки доступності блоків даних. 1D DAS по суті також є дружнім до побудови розподілених блоків.
Що ще потрібно зробити? Які є компроміси?
Далі слідує реалізація та запуск PeerDAS. Після цього буде постійно збільшуватися кількість blob на PeerDAS, одночасно уважно спостерігаючи за мережею та вдосконалюючи програмне забезпечення для забезпечення безпеки. Нам також потрібно більше наукових робіт для стандартизації PeerDAS та його взаємодії з правилами вибору розгалужень безпеки та іншими питаннями.
У майбутньому нам потрібно визначити ідеальну версію 2D DAS і довести її безпечні властивості. Ми також хочемо перейти від KZG до альтернатив, які є квантово-безпечними і не потребують довіреної настройки, але наразі ще не зрозуміло, які кандидати є дружніми до розподіленого блокчейн-будування.
Я вважаю, що довгостроковий реальний шлях це:
Реалізація ідеальної 2D DAS;
Дотримуйтесь використання 1D DAS, жертвуючи ефективністю смуги пропускання для простоти та надійності, приймаючи нижчий верхній межу даних;
Відмовитися від DA, повністю прийняти Plasma як основну архітектуру Layer2.
Навіть якщо ми вирішимо безпосередньо масштабувати виконання на рівні L1, цей вибір також існує. Якщо L1 має обробляти велику кількість TPS, блоки L1 стануть дуже великими, клієнтам потрібно буде ефективно перевіряти їх правильність, тому ми змушені будемо використовувати ту ж технологію на рівні L1, що й Rollup.
Як взаємодіяти з іншими частинами дорожньої карти?
Якщо реалізувати стиснення даних, потреба в 2D DAS зменшиться або затримається, якщо Plasma буде широко використовуватися, потреба ще більше зменшиться. DAS також ставить виклики для протоколів і механізмів побудови розподілених блоків: хоча DAS теоретично дружній до розподіленого відновлення, на практиці це потребує поєднання з пропозицією списку включення пакетів та механізмами вибору розгалуження навколо нього.
Кожна транзакція в Rollup займає велику кількість місця на ланцюгу: передача ERC20 потребує близько 180 байт. Навіть за наявності ідеальної вибірки даних, це обмежує масштабованість Layer протоколів. Кожен слот 16 МБ, отже, ми отримуємо:
16000000 / 12 / 180 = 7407 TPS
Якщо ми зможемо вирішити не тільки проблему чисельника, а й проблему знаменника, і зменшити кількість байтів, які займають транзакції в кожному Rollup на ланцюзі, що тоді буде?
Що це таке, як це працює?
У нульовій байтовій компресії два байти замінюють кожну довгу послідовність нульових байтів, вказуючи, скільки нульових байтів є. Далі ми скористалися певними властивостями транзакцій:
Агрегація підписів: перехід від підписів ECDSA до підписів BLS, підписи BLS можна об'єднати в єдиний підпис, що підтверджує дійсність усіх оригінальних підписів. У L1, через високі витрати на обчислення перевірки, використання підписів BLS не розглядається. Але в L2, в середовищі з нестачею даних, використання підписів BLS має сенс. Агреговані характеристики ERC-4337 забезпечують шлях для реалізації цієї функції.
Заміна адреси на вказівники: якщо раніше використовували якусь адресу, ми можемо замінити 20-байтову адресу на 4-байтовий вказівник, що вказує на певне місце в історії.
Кастомізоване серіалізування значень транзакцій: більшість значень транзакцій мають невелику кількість знаків, наприклад, 0.25 ETH представляється як 250000000000000000 wei. Максимальна базова комісія та пріоритетна комісія також подібні. Таким чином, ми можемо використовувати кастомізований формат десяткових чисел з плаваючою комою для представлення більшості валютних значень.
що ще потрібно зробити, які є компроміси?
Далі основне, що потрібно зробити, це фактично реалізувати вищезгадане рішення. Основні компроміси включають:
Перехід на підпис BLS потребує значних зусиль і знижує сумісність з надійними апаратними чіпами. Можна використати упаковку ZK-SNARK з іншими схемами підпису як альтернативу.
Динамічне стиснення ( заміна адреси на вказівники ) ускладнить код клієнта.
Публікація різниці стану на ланцюзі замість транзакцій знижує можливість аудиту і робить багатьох програмне забезпечення (, таких як блокчейн-браузери ), непрацюючими.
Як взаємодіяти з іншими частинами дорожньої карти?
Використання ERC-4337 та остаточне включення деяких його частин до L2 EVM може значно прискорити впровадження агрегуючих технологій. Розміщення частини ERC-4337 на L1 може пришвидшити його впровадження на L2.
Навіть використання blob обсягом 16 МБ і стиснення даних не забезпечить 58 000 TPS, щоб повністю задовольнити потреби споживчих платежів, децентралізованих соціальних мереж або інших областей з високою пропускною спроможністю, особливо якщо врахувати фактори конфіденційності, які можуть знизити масштабованість у 3-8 разів. Для сценаріїв з високим обсягом транзакцій і низькою вартістю наразі одним із варіантів є використання Validium, яке зберігає дані поза ланцюгом і використовує цікаву модель безпеки: оператори не можуть вкрасти кошти користувачів, але вони можуть тимчасово або назавжди заморозити всі кошти користувачів. Але ми можемо зробити краще.
Що це таке, як це працює?
Plasma є рішенням для масштабування, яке передбачає, що оператори публікують блоки поза ланцюгом, а корені Merkle цих блоків розміщують на ланцюзі. Для кожного блоку оператори надсилають користувачам Merkle гілки, що підтверджують зміни або незміни активів цього користувача. Користувачі можуть витягувати активи, надаючи Merkle гілку. Важливо, що ця гілка не обов'язково повинна бути коренем з останнього стану. Тому, навіть якщо виникають проблеми з доступністю даних, користувачі все ще можуть відновити активи, витягуючи доступний останній стан. Якщо користувач надсилає недійсну гілку, можна визначити право власності на активи через механізм виклику на ланцюзі.
Ранні версії Plasma могли обробляти лише випадки використання платежів, і не могли бути ефективно розгорнуті. Однак, якщо вимагати, щоб кожен корінь перевірявся за допомогою SNARK, Plasma стане набагато потужнішим. Кожна гра викликів може бути значно спрощена, оскільки ми усунули більшість можливих шляхів шахрайства операторів. Водночас це відкриває нові шляхи, дозволяючи технології Plasma розширюватися на більш широкий спектр класів активів. Нарешті, за умови, що оператори не обманюють, користувачі можуть негайно виводити кошти, не чекаючи тижневого терміну оскарження.
Один із способів створення EVM Plasma-ланцюга ( не є єдиним методом ): використання ZK-SNARK для побудови паралельного UTXO-дерева, що відображає зміни балансу, здійснені EVM, і визначає унікальне відображення "однієї і тієї ж монети" в історичні різні моменти часу. Потім можна побудувати структуру Plasma на основі цього.
Одне з ключових уявлень полягає в тому, що система Plasma не потребує досконалості. Навіть якщо ви можете захистити лише підмножину активів (, як лише минулі.
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
17 лайків
Нагородити
17
6
Поділіться
Прокоментувати
0/400
MetaverseVagabond
· 07-16 11:43
Ранні приєднуйтесь до криптосвіту, старі невдахи, рубали копалини, торгували NFT
Переглянути оригіналвідповісти на0
LiquidityOracle
· 07-14 02:19
І просто пусте базікання: L2 працює, L1 відпочиває.
Переглянути оригіналвідповісти на0
TrustlessMaximalist
· 07-14 02:11
бичачий L2, Гаманець вже готовий
Переглянути оригіналвідповісти на0
CryptoPhoenix
· 07-14 01:59
про повернувся! Ведмежий ринок старі невдахи перебувають у процесі відновлення менталітету на дні...
Переглянути оригіналвідповісти на0
Blockwatcher9000
· 07-14 01:58
l2 врешті-решт це патч, так?
Переглянути оригіналвідповісти на0
GasFeeCrybaby
· 07-14 01:57
Один невдаха з криптосвіту, хто розуміє, скільки я щодня плачу за газ за імпульсивні угоди.
Ethereum The Surge дорожня карта: від Rollup до 100000 TPS шляхи розширення
Можливе майбутнє Ethereum: The Surge
Дорожня карта Ethereum спочатку містила дві стратегії масштабування: шардінг та протоколи Layer2. Шардінг дозволяє кожному вузлу перевіряти та зберігати лише невелику частину транзакцій, тоді як Layer2 будує мережу поверх Ethereum, використовуючи його безпеку, одночасно зберігаючи більшість даних та обчислень поза основним ланцюгом. Ці два шляхи врешті-решт об'єдналися, утворивши дорожню карту, зосереджену на Rollup, яка досі залишається основною стратегією розширення Ethereum.
Дорожня карта, зосереджена на Rollup, пропонує чіткий розподіл обов'язків: Ethereum L1 зосереджується на тому, щоб стати потужним і децентралізованим базовим шаром, тоді як L2 бере на себе завдання допомагати екосистемі розширюватися. Ця модель є поширеною в суспільстві, подібно до судової системи (L1), яка існує для захисту контрактів і прав власності, тоді як підприємці (L2) здійснюють інновації на цій основі.
Цього року цей дорожня карта досягла важливого прогресу: запуск EIP-4844 blobs суттєво збільшив пропускну здатність даних Ethereum L1, кілька EVM Rollup перейшли до першої стадії. Кожен L2 існує як "шар" з власними правилами та логікою, різноманітність реалізації шарів сьогодні стала реальністю. Але цей шлях також стикається з деякими унікальними викликами. Наше теперішнє завдання полягає в завершенні дорожньої карти, зосередженої на Rollup, вирішуючи ці проблеми, одночасно зберігаючи стійкість і децентралізацію Ethereum L1.
! Віталік Новини: Можливе майбутнє Ethereum, сплеск
Підйом: ключова мета
Зміст цього розділу
! Віталік Нова стаття: Можливе майбутнє Ethereum, сплеск
Парадокс трьох вимірів масштабованості
Трикутний парадокс масштабованості стверджує, що між децентралізацією, масштабованістю та безпекою блокчейну існує суперечність. Це не теорема, а вказує на те, що розірвати трикутний парадокс важко, потрібно вийти за межі звичних рамок мислення. Деякі високопродуктивні мережі стверджують, що вирішили трикутний парадокс, але це зазвичай є оманливим, оскільки на цих мережах запуск вузлів є складнішим, ніж на Ethereum.
Однак, поєднання вибірки доступності даних та SNARK-ів дійсно вирішує тріадичний парадокс: це дозволяє клієнту завантажувати лише невелику кількість даних та виконувати дуже мало обчислень, щоб перевірити доступність великої кількості даних та правильність обчислювальних етапів. SNARK-и є бездоказовими, а вибірка доступності даних має тонку модель довіри few-of-N, але зберігає основні характеристики незбільшуваних ланцюгів.
Архітектура Plasma є ще одним рішенням, яке покладає відповідальність за доступність даних на користувачів у спосіб, що стимулює їхню зацікавленість. З поширенням SNARKs, Plasma стає життєздатною для більш широких сценаріїв використання.
! Віталік Новини: Можливе майбутнє Ethereum, сплеск
Подальший прогрес у вибірці доступності даних
Яку проблему ми вирішуємо?
Наразі в Ethereum кожні 12 секунд є 3 слоти приблизно по 125 кБ блобів, доступна пропускна здатність даних становить близько 375 кБ. Припустимо, що дані транзакцій безпосередньо публікуються в ланцюзі, переказ ERC20 становить приблизно 180 байтів, тому максимальна TPS для Rollup в Ethereum становить 173.6. Додаючи calldata, можна досягти 607 TPS. Використовуючи PeerDAS, кількість блобів може зрости до 8-16, забезпечуючи для calldata 463-926 TPS.
Це значне покращення, але цього недостатньо. Наша середньострокова мета — 16 МБ на слот, разом із вдосконаленнями стиснення даних Rollup, це призведе до ~58000 TPS.
Що це? Як це працює?
PeerDAS є простою реалізацією "1D sampling". У Ethereum кожен blob є 4096-м поліномом над полем простих чисел з 253 елементів. Ми транслюємо частки полінома, кожна частка містить 16 значень оцінки на сусідніх 16 координатах з 8192 координат. Будь-які 4096 значень оцінки можуть відновити blob.
PeerDAS дозволяє кожному клієнту слухати невелику кількість підмереж, i-та підмережа транслює i-ий зразок будь-якого блобу, клієнт запитує інші блоби в підмережах через запит до однорангових учасників у глобальній p2p мережі. SubnetDAS використовує лише механізм підмереж, без додаткових запитів до однорангового рівня. Поточна пропозиція дозволяє вузлам, що беруть участь у доказі частки, використовувати SubnetDAS, інші вузли використовують PeerDAS.
Теоретично, ми можемо значно розширити масштаб "1D sampling": якщо збільшити максимальну кількість blob до 256, ми зможемо досягти цілі в 16MB, тоді як кожен вузол повинен обробляти 1MB даних на кожен slot. Це навряд чи можливо, але означає, що клієнти з обмеженою пропускною здатністю не зможуть виконувати вибірку. Ми можемо оптимізувати, зменшивши кількість blob та збільшивши їхній розмір, але це призведе до підвищення витрат на відновлення.
Отже, ми врешті-решт хочемо виконати 2D-вібрацію, випадково вибираючи не тільки всередині блобу, але і між блобами. Використовуючи лінійні властивості KZG-комітменту, розширити набір блобів у блоці з набором нових віртуальних блобів, які надмірно кодують ту ж інформацію.
2D вибірка є дружньою до побудови розподіленого блоку, фактичним вузлам, що будують блоки, потрібно лише мати blob KZG зобов'язання і можуть покладатися на вибіркову доступність даних для перевірки доступності блоків даних. 1D DAS по суті також є дружнім до побудови розподілених блоків.
Що ще потрібно зробити? Які є компроміси?
Далі слідує реалізація та запуск PeerDAS. Після цього буде постійно збільшуватися кількість blob на PeerDAS, одночасно уважно спостерігаючи за мережею та вдосконалюючи програмне забезпечення для забезпечення безпеки. Нам також потрібно більше наукових робіт для стандартизації PeerDAS та його взаємодії з правилами вибору розгалужень безпеки та іншими питаннями.
У майбутньому нам потрібно визначити ідеальну версію 2D DAS і довести її безпечні властивості. Ми також хочемо перейти від KZG до альтернатив, які є квантово-безпечними і не потребують довіреної настройки, але наразі ще не зрозуміло, які кандидати є дружніми до розподіленого блокчейн-будування.
Я вважаю, що довгостроковий реальний шлях це:
Навіть якщо ми вирішимо безпосередньо масштабувати виконання на рівні L1, цей вибір також існує. Якщо L1 має обробляти велику кількість TPS, блоки L1 стануть дуже великими, клієнтам потрібно буде ефективно перевіряти їх правильність, тому ми змушені будемо використовувати ту ж технологію на рівні L1, що й Rollup.
Як взаємодіяти з іншими частинами дорожньої карти?
Якщо реалізувати стиснення даних, потреба в 2D DAS зменшиться або затримається, якщо Plasma буде широко використовуватися, потреба ще більше зменшиться. DAS також ставить виклики для протоколів і механізмів побудови розподілених блоків: хоча DAS теоретично дружній до розподіленого відновлення, на практиці це потребує поєднання з пропозицією списку включення пакетів та механізмами вибору розгалуження навколо нього.
! Віталік Нова стаття: Можливе майбутнє Ethereum, сплеск
Стиснення даних
Яку проблему ми вирішуємо?
Кожна транзакція в Rollup займає велику кількість місця на ланцюгу: передача ERC20 потребує близько 180 байт. Навіть за наявності ідеальної вибірки даних, це обмежує масштабованість Layer протоколів. Кожен слот 16 МБ, отже, ми отримуємо:
16000000 / 12 / 180 = 7407 TPS
Якщо ми зможемо вирішити не тільки проблему чисельника, а й проблему знаменника, і зменшити кількість байтів, які займають транзакції в кожному Rollup на ланцюзі, що тоді буде?
Що це таке, як це працює?
У нульовій байтовій компресії два байти замінюють кожну довгу послідовність нульових байтів, вказуючи, скільки нульових байтів є. Далі ми скористалися певними властивостями транзакцій:
Агрегація підписів: перехід від підписів ECDSA до підписів BLS, підписи BLS можна об'єднати в єдиний підпис, що підтверджує дійсність усіх оригінальних підписів. У L1, через високі витрати на обчислення перевірки, використання підписів BLS не розглядається. Але в L2, в середовищі з нестачею даних, використання підписів BLS має сенс. Агреговані характеристики ERC-4337 забезпечують шлях для реалізації цієї функції.
Заміна адреси на вказівники: якщо раніше використовували якусь адресу, ми можемо замінити 20-байтову адресу на 4-байтовий вказівник, що вказує на певне місце в історії.
Кастомізоване серіалізування значень транзакцій: більшість значень транзакцій мають невелику кількість знаків, наприклад, 0.25 ETH представляється як 250000000000000000 wei. Максимальна базова комісія та пріоритетна комісія також подібні. Таким чином, ми можемо використовувати кастомізований формат десяткових чисел з плаваючою комою для представлення більшості валютних значень.
що ще потрібно зробити, які є компроміси?
Далі основне, що потрібно зробити, це фактично реалізувати вищезгадане рішення. Основні компроміси включають:
Перехід на підпис BLS потребує значних зусиль і знижує сумісність з надійними апаратними чіпами. Можна використати упаковку ZK-SNARK з іншими схемами підпису як альтернативу.
Динамічне стиснення ( заміна адреси на вказівники ) ускладнить код клієнта.
Публікація різниці стану на ланцюзі замість транзакцій знижує можливість аудиту і робить багатьох програмне забезпечення (, таких як блокчейн-браузери ), непрацюючими.
Як взаємодіяти з іншими частинами дорожньої карти?
Використання ERC-4337 та остаточне включення деяких його частин до L2 EVM може значно прискорити впровадження агрегуючих технологій. Розміщення частини ERC-4337 на L1 може пришвидшити його впровадження на L2.
! Віталік Нова стаття: Можливе майбутнє Ethereum, сплеск
Узагальнений Плазма
Яку проблему ми вирішуємо?
Навіть використання blob обсягом 16 МБ і стиснення даних не забезпечить 58 000 TPS, щоб повністю задовольнити потреби споживчих платежів, децентралізованих соціальних мереж або інших областей з високою пропускною спроможністю, особливо якщо врахувати фактори конфіденційності, які можуть знизити масштабованість у 3-8 разів. Для сценаріїв з високим обсягом транзакцій і низькою вартістю наразі одним із варіантів є використання Validium, яке зберігає дані поза ланцюгом і використовує цікаву модель безпеки: оператори не можуть вкрасти кошти користувачів, але вони можуть тимчасово або назавжди заморозити всі кошти користувачів. Але ми можемо зробити краще.
Що це таке, як це працює?
Plasma є рішенням для масштабування, яке передбачає, що оператори публікують блоки поза ланцюгом, а корені Merkle цих блоків розміщують на ланцюзі. Для кожного блоку оператори надсилають користувачам Merkle гілки, що підтверджують зміни або незміни активів цього користувача. Користувачі можуть витягувати активи, надаючи Merkle гілку. Важливо, що ця гілка не обов'язково повинна бути коренем з останнього стану. Тому, навіть якщо виникають проблеми з доступністю даних, користувачі все ще можуть відновити активи, витягуючи доступний останній стан. Якщо користувач надсилає недійсну гілку, можна визначити право власності на активи через механізм виклику на ланцюзі.
Ранні версії Plasma могли обробляти лише випадки використання платежів, і не могли бути ефективно розгорнуті. Однак, якщо вимагати, щоб кожен корінь перевірявся за допомогою SNARK, Plasma стане набагато потужнішим. Кожна гра викликів може бути значно спрощена, оскільки ми усунули більшість можливих шляхів шахрайства операторів. Водночас це відкриває нові шляхи, дозволяючи технології Plasma розширюватися на більш широкий спектр класів активів. Нарешті, за умови, що оператори не обманюють, користувачі можуть негайно виводити кошти, не чекаючи тижневого терміну оскарження.
Один із способів створення EVM Plasma-ланцюга ( не є єдиним методом ): використання ZK-SNARK для побудови паралельного UTXO-дерева, що відображає зміни балансу, здійснені EVM, і визначає унікальне відображення "однієї і тієї ж монети" в історичні різні моменти часу. Потім можна побудувати структуру Plasma на основі цього.
Одне з ключових уявлень полягає в тому, що система Plasma не потребує досконалості. Навіть якщо ви можете захистити лише підмножину активів (, як лише минулі.