Переслано Оригінальний Заголовок: Дизайнер Blockspace: Майбутнє середовища виконання

Протягом дев'яти років з моменту запуску Ethereum першого децентралізованого, програмованого блокчейну, криптовалюта стикалася з численними перешкодами у прагненні масштабувати децентралізовані додатки для мільярдів користувачів. І для розробки рішень щодо масштабування для вирішення цього, криптоіндустрія постійно фінансує та розробляє зовсім нові типи блокчейнів для вирішення "проблеми продуктивності."

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

Незважаючи на цей туман, ми бачили, що впродовж останніх кількох років відбулися важливі, стійкі поліпшення масштабованості блокчейну. Поки Ethereum просувається за своєю дорожньою картою, орієнтованою на Rollup, нова хвиля Rollups, копроцесорів,доступність даних(DA) шари, і з'являються конкуруючі L1, кожен з унікальними виборами дизайну, щоб забезпечити розробникам більш продуктивні середовища для створення масштабованих, зручних для користувачів додатків.

Сьогодні запровадження EIP4844 та альтернативних шарів DA допомогли подолати критичний бутлег DA. Незважаючи на цей критичний віхідний пункт, свідчення свідчить, що інші важливі вузькі місця повинні бути вирішені. Минулого місяця, Базовийзібраний$1.57 млн в комісіях за транзакції за один деньпід час сплати лише $5K витрат на доступність даних для Ethereum. Це свідчить про те, що обчислювальна робота, необхідна для перевірки та обробки оновлень стану, залишається критичним обмеженням і можливістю для вдосконалення.

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

Виклики сьогодення

Продуктивність рівня виконання може бути оцінена за рахунок обчислювальної роботи, яку виконавчі вузли здійснюють відносно часу блоку своїх ланцюгів або "газу, обчисленого за секунду".

З цим на увазі ми можемо звузити вузькі місця виконавчого рівня до двох взаємопов'язаних факторів: неефективний доступ до стану та неефективне обчислення.

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

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

Бутылочное горло №1: Неефективний доступ до стану

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

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

Ефіріум спеціально ґрунтується на структурі даних, відомій як Мерклівське Патріцієве дерево (MPT), яке включає @chiqing/merkle-patricia-trie-explained-ae3ac6a7e123">four sub-tries.

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

Цей прямий ріст впливає на продуктивність Ethereum, оскільки стан зберігається на диску, а операції з диском призводять до великого накладення. Під час доступу до даних з регістра ЦП може зайняти 0,1 наносекунди, це може зайняти від 10 до 100 мікросекунд.(100x–1000x повільніше)для доступу до даних з диска, що приблизно відповідає 200 000 інструкціям процесора, які могли б бути виконані за цей час. Це означає консервативну оцінку 36 переказів ERC-20, які могли б бути виконані!

Погіршуючи цю проблему, у блокчейнах є багато неефективних шаблонів доступу для читання та запису до стану. Наприклад, не послідовна структура Merkle Patricia trie властиво призводить до цих операцій введення/виведення даних (I/O) читання з та запису до різних непередбачуваних місць на диску. Випадковий характер вхідних транзакцій і наступні зміни стану, які вони викликають, призводять до розсипаного шаблону доступу до даних, що значно уповільнює процес перевірки та оновлення стану та використовує лише частину можливість апаратного пристрою.

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

Eng різне #2: Неефективні обчислення

Шари виконання також стикаються з проблемою неефективних обчислень, яка проявляється різними способами.

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

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

Ці неефективності призводять до неоптимального використання обчислювальних ресурсів та утруднюють роботу рівнів виконання.

Рішення: Неефективний доступ до стану

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

Бездержавність & Комп'ютерна пам'ять

Деякі рівні виконання вирішують зростання обсягу даних шляхом простого його прийняття на короткий термін. Вони переносять зберігання даних стану з повільних систем на основі диска на швидшу оперативну пам'ять з випадковим доступом (RAM). Отримання інформації про стан в RAM значно зменшує накладні витрати, пов'язані з операціями диска, які є повільними та вимагають більше ресурсів.

Однак цей підхід викликає виклик основному принципу децентралізації. Зберігання все більших обсягів даних про стан в оперативній пам'яті вимагає більш розвинутої та дороговартісної апаратури, що може обмежити можливість фізичних осіб брати участь як оператори вузлів. Внаслідок цього, коли вимоги до апаратного забезпечення зростають, менше суб'єктів можуть дозволити собі запускати ці вузли.

Для збалансування привабливості обчислень у пам'яті з мінімізацією довіри як L1s (такі як Ethereum), так і L2s працюють над шляхом масштабованості, який ґрунтується на роз'єднанні ролі валідатора на окремі, централізовані виконавчі вузли з багатьма перевіряючими вузлами. У цій моделі високопродуктивні виробники блоків з апаратними вимогами для обчислення у пам'яті відповідальні за генерування блоків, а криптографічні докази (докази шахрайства та докази достовірності) використовуються перевіряючими вузлами для забезпечення відповідальності виробників блоків.

В результаті ці системи повинні дозволити виробникам блоків максимізувати свою швидкість, оскільки можна очікувати, що вони будуть обчислювати у пам'яті, повністю усуваючи диск I/O під час виконання. Оскільки затримка ОЗП зазвичай становить менше 100 наносекунд, затримка доступу до стану зменшується до 1000 разів у порівнянні з реалізаціями на основі диска.

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

Для сприяння цьому процесу в довірено-мінімізованому стилі, шари виконання повинні реалізувати певний ступінь бездержавність, найпопулярнішим є концепція «слабкої бездержавності». Слабка бездержавність досягається шляхом обов'язкового надання блок-виробниками криптографічного підтвердження, відомого як свідокдо перевірюючого вузла. Цей свідок упаковує всі запропоновані зміни стану нового блоку, дозволяючи валідаторам перевірити ці зміни без додаткових історичних даних.

Хоча цю концепцію можна застосовувати з використанням різних структур дерев, Verkle-дерева часто вважаються більш вигідними в порівнянні з Merkle-деревами через їх ефективність. Merkle-дерева вимагають включення всіх хешів братніх вузлів по шляху від точки даних (листка) до кореня дерева для підтвердження цілісності даних. Ця вимога означає, що розмір свідка (доказ цілісності) збільшується з висотою дерева, оскільки кожен рівень потребує додаткових хешів. В результаті перевірка цілісності даних в Merkle-деревах стає обчислювально інтенсивною та витратною, особливо для великих наборів даних. Натомість, Verkle-дерева спрощують цей процес, зменшуючи накладні витрати, пов'язані з обчисленням та зберіганням при генерації та перевірці нових блоків.

Verkle tree scaling from Невідворотне Ethereum’s “Verkle Tree”

Дерева Verkle покращують структуру традиційних дерев Merkle шляхом оптимізації зв'язків між листям та коренем та усунення необхідності включення суміжних вузлів у процес верифікації. У дереві Verkle перевірка доказу передбачає лише значення в листковому вузлі, зобов'язання до кореневого вузла та одне векторне зобов'язання на основі поліноміальних зобов'язань, яке замінює кілька зобов'язань на основі хешування, знайдених у деревах Merkle. Цей зсув дозволяє деревам Verkle зберігати фіксований розмір свідка, який не збільшується з висотою дерева або кількістю перевірених листків, що значно покращує ефективність зберігання та обчислень під час верифікації даних.

Наступні роки побачать втілення бездержавності на рівнях L1 та L2 з різними конфігураціями. Згідно з останнім планом розвитку Ethereum, валідатори можуть покладатися на блок-білдерів для надання доказів Verkle щодо стану певних блоків та перевірки цих легких доказів замість безпосереднього збереження стану Ethereum.

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

Проте варто відзначити, що переваги відсутності стану та наслідуюча можливість обчислень у пам'яті не є срібною кулею для продуктивності рівня виконання.

Реальний час TPS від MegaETH «Розуміння продуктивності виконання Ethereum Execution Layer»

Як співзасновник MegaETH, Їлонг Лі, визначає у наступномупрезентація дослідженьпри виконанні на Ethereum існують інші неефективності у структурах даних та шаблонах доступу onchain, які залишаються оптимізованими.

Покращення баз даних

Команди, які працюють над шарами виконання, шукають способи поліпшення структури цих баз даних самостійно, щоб усунути деякі з проблем, що виникають у Ethereum та інших блокчейнах, сумісних з EVM, у зв'язку з неефективним доступом до стану, що має доміноюючий ефект на обчислювальну ефективність.

Фактично, обмеження існуючих дизайнів баз даних, знайдених в EVM, вказалиMonad’s* рішення йти за межі виключно оптимізації обчислювальної ефективності для досягнення паралелізації. Monad виявила, що навіть після впровадження паралельного виконання вони побачили лише невелике прискорення продуктивності через те, що багатопотокові запити на читання та запис до бази даних блокували один одного. В результаті Monad впровадила базу даних, сумісну з асинхронним IO (AIO), або паралельний доступ, як критичну частину рішення.

Асинхронний введення/виведення

Операції введення/виведення, такі як читання забо запис на пристрої зберігання, часто створюють труднощі, особливо з механічними жорсткими дисками (HDD). Ці диски потребують фізичного переміщення головки зчитування/запису для доступу до даних, що значно уповільнює обробку даних.

AIO addresses this challenge by allowing programs to perform I/O operations concurrently with other processes. Essentially, a program can initiate an I/O operation and move on without waiting for it to complete. It does this by registering a callback function or a promise that the operating system or an I/O library will fulfill once the I/O operation finishes. This asynchronous approach allows the main program to continue executing other tasks, improving overall efficiency by not stalling for I/O tasks to complete.

Асинхронний введення/виведення може бути реалізований як з традиційними HDD, так і з твердотільними накопичувачами (SSD), хоча переваги більш помітні з SSD. HDD можуть виконувати AIO, але їх механічна природа означає, що вони за своєю суттю повільніші, ніж SSD, які зберігають дані на флеш-пам'яті та не мають рухомих частин, що призводить до швидшого доступу.

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

Так само, Reth використовує метод, який відокремлює операції бази даних від основного двигуна виконання EVM. Ця настройка дозволяє виконувати байт-код EVM послідовно на одному потоці, щоб забезпечити послідовність, тоді як завдання введення/виведення бази даних переносяться на паралельні процеси. Reth використовує модель актора - шаблон архітектури програмного забезпечення - для ефективного керування цими паралельними процесами, забезпечуючи, що операції введення/виведення не переривають інтерпретатор EVM.

Частота мерклізації стану

Ще один вектор для оптимізації - частота мерклізації стану. Поточна модель мерклізації стану Ethereum після кожного блоку вводить значні накладні витрати, потребує часті записи в та читання з диска та постійного обходу трие. Зазвичай дерева Меркла працюють, групуючи проміжні хеші в набори по 16 (називають вузлом) та зберігаючи їх у базі даних ключ-значення, де ключ - це хеш вузла, а значення - сам вузол.

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

Підхід Солани оновлення зобов'язання до стану лише в кінці кожної епохи дозволяє амортизувати витрати на запис протягом багатьох операцій протягом цього періоду. Якщо запис стану змінюється кілька разів протягом тієї ж самої епохи, кожен запис не потребує негайного оновлення кореня Меркла. Це зменшує загальні обчислювальні накладні витрати, пов'язані з оновленням стану протягом епохи. Відповідно, витрати, пов'язані з читанням зі стану, залишаються постійними або O(1), оскільки стан може бути прочитаний безпосередньо без необхідності кожного разу проходити по шляху Меркла.

Зменшення частоти мерклізації в Ethereum може зменшити накладні витрати на читання та запис стану, покращуючи продуктивність. Однак легкі клієнти повинні бути відтворені зміни блоків для відстеження стану між епохами або надсилати транзакції onchain для перевірки стану, і така зміна наразі несумісна з Ethereum.

Ефективні та спеціалізовані структури даних

Крім того, шарові дерев'яні структури всередині існуючих клієнтів Ethereum загалом призводять до неефективних шаблонів доступу до стану, що додатково сприяє зростанню стану. Хоча стан Ethereum структурований як MPT, він також зберігається в базах даних клієнтів Ethereum, таких як LevelDB,PebbleDB(використовується go-ethereum), або MDBX (використовується Erigon), які зберігають дані в деревах Меркля, такі якB-TreeабоLSM-Tree.

У цій конфігурації структура даних вкорінена в іншу структуру даних окремого типу, створюючи «підсилення читання» при навігації внутрішніми деревними структурами вверх по клієнтах, що працюють під іншою системою на основі дерева Меркла. Підсилення читання можна розглядати як результат кількох кроків для доступу або оновлення інформації, що міститься в стані, який потребує навігації зовнішнім деревом для знаходження точки входу в MPT перед виконанням необхідної операції. В результаті кількість доступів до диска для випадкового читання множиться на фактор log(n).

Для вирішення цієї проблеми Monad за допомогою вбудованої структури даних Patricia trie на диску та в оперативній пам'яті. З технічної точки зору Patricia trie часто переважає інші структури дерева Меркля завдяки своєї унікальної комбінації ефективності використання простору, ефективного відповідання префіксів та мінімального обходу вузлів. Дизайн trie згортає вузли з одиночними дітьми та оптимізує вигляди, вставки та вилучення, зменшуючи кількість операцій введення-виведення на диски або мережу, що потрібні. Крім того, вмілість Patricia trie в роботі з відповідним відповіданням префіксів покращує продуктивність в додатках, які потребують швидкого пошуку часткового ключа.

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

Конфігурація бінарного дерева Меркла від Sovereign Labs «Майже оптимальна мерклізація стану»

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

Термін дії

Термін придатності - це механізм управління та зменшення розміру стану блокчейну шляхом видалення даних, до яких не було доступу протягом визначеного періоду часу. Хоча термін придатності часто включається в категорію "безстандартності", важливо відрізняти ці поняття в контексті виконання.

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

Існує кілька загально обговорюваних методів для впровадження закінчення терміну дії стану:

• Термін при оренді: Цей метод передбачає стягування плати за обслуговування або «оренду», щоб підтримувати активність облікових записів у державній базі даних. Якщо орендна плата не сплачується, облікові записи архівуються до сплати плати за відновлення.
• Термін дії за часом: Тут облікові записи вважаються неактивними, якщо до них не було доступу - це означає відсутність транзакцій або взаємодій протягом певного періоду.

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

Зберігаючи менший і більш керований стан, закінчення стану зменшує "надмірність стану", яка може серйозно уповільнити продуктивність блокчейну. Менший розмір стану дозволяє вузлам швидко навігувати та оновлювати стан, що перекладається в більш швидке виконання, оскільки вузли витрачають менше часу на сканування та більше часу на обробку.

Шардинг виконання

Sharding оптимізує використання ресурсів та продуктивність за допомогою розподілу завдань та даних між обмеженою кількістю спеціалізованих вузлів (не кожен вузол виконує глобальний стан).

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

Схема шардування з роботи Віталіка "Межі масштабованості блокчейну"

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

У Nightshade блокчейн структурований як єдиний логічний ланцюг, кожен блок складається з кількох «частин» і одна частина призначена для кожного шарду. Ці частини містять транзакції та переходи стану, які специфічні для кожного шарду. Включення частин з усіх шардів в єдиний блок дозволяє отримати єдиний погляд на загальний стан блокчейну та спрощує процес міжшарової комунікації.

Так само, як розділення між будівельником відповідного інструменту (PBS) на Ethereum, Nightshade явно визначає ролі вузлів, які зберігають стан, та вузлів, які не зберігають стан. На NEAR станові валідатори призначаються для конкретних фрагментів і відповідальні за збирання транзакцій, виконання їх та вироблення фрагмент-специфічних частинок. Вони підтримують повний стан свого призначеного фрагмента та генерують станові свідки для валідаторів, які використовують під час процесу перевірки.

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

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

Рішення: Неефективні обчислення

Паралельне виконання

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

Проте важливо врахувати, що кілька компонентів виконання можуть бути паралельною, багато з яких реалізовані копроцесорами, такими як Лагранж* та альтернативні клієнти блокчейну, такі як Firedancerпокращити продуктивність блокчейнів значно. Зокрема, паралелізація може включати в себе:

• Паралелізація доступу до стану
• Паралельне виконання конкретних операцій
• Паралелізація консенсусу та виконання

Паралельний доступ до стану

Паралельний доступ до стану приносить два критичні переваги:

• Паралельні EVM розподіляють обробку транзакцій по кількох ядрах ЦП. Ця настройка дозволяє обробляти кілька транзакцій одночасно, а не змушувати їх очікувати в черзі для одного ресурсу.
• Коли транзакція чекає на дані зберігання—що може викликати значну затримку—система не залишається бездіяльною. Натомість вона може перейти до іншої транзакції, готової до виконання. Це можливо тому, що кілька ядер можуть обробляти різні завдання незалежно і одночасно.

Основним викликом у паралельному виконанні транзакцій є управління одночасним доступом до спільного глобального стану без порушення KИСЛОправила оновлення розподілених систем. Якщо у блокчейні відбувається виконання великої кількості транзакцій паралельно, деякі з них будуть конфліктувати. У результаті дві основні методології паралельного доступу до стану відрізняються у тому, коли вони виділяють ресурси на вирішення конфліктів: модель песимістичного виконання (або блокування пам'яті) та модель оптимістичного виконання.

Песимістичне виконання

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

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

В результаті цього вибору дизайну песимістична модель виконання користується деталізованим контролем над розподілом ресурсів, що дозволяє сегментувати або розподіляти простір стану блокчейну.

Розпаралелювання ефективно створює кілька синхронно скомпонованих незалежних шардів виконання, підкріплених єдиною моделлю безпеки. Це допомагає вирішити проблему перевантаження мережі та оптимізувати витрати на газ завдяки точному управлінню ресурсами та динамічним ринкам зборів. Визначаючи «гарячі точки» доступу до штатів (області з високим транзакційним попитом), система може впроваджувати цільові оптимізації, такі як диференційоване ціноутворення комісій, обмеження ставок або виділення додаткових ресурсів для держав з високим рівнем суперечок. Важливо зазначити, що поточна реалізація розпаралелювання Solana не повністю реалізувати потенціал локалізованих ринків комісій.

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

У SolanaРівень морячас виконання, який реалізує цю песимістичну модель виконання, транзакції вказують рахунки, які вони будуть читати або записувати під час виконання. Sealevel аналізує шаблони доступу та створює паралельні черги транзакцій для кожного потоку ЦП на вузлі перевірки. Якщо до рахунку звертаються кілька разів, він вказується послідовно в одній черзі, щоб запобігти конфліктам. Транзакції, які не обробляються протягом часу блоку лідера, упаковуються і пересилаються наступному запланованому лідеру для обробки.

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

Визначивши, які контракти будуть задіяні, транзакції, які задіють неперетинні набори контрактів, можуть виконуватися паралельно за допомогою виконавчих вузлів (що можна досягти в моделі даних «рахунки» зі строгими списками доступу). Проте, для сумісності з розумними контрактами в стилі Ethereum, схеми UTXO, такі як Fuel, обмежують вузли, що виробляють блоки, виконувати транзакції з перекриваючими списками доступу послідовно.

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

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

Оптимістичне виконання

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

Замість того, щоб запобігати конфліктам до їх виникнення, транзакції оптимістично виконуються паралельно, припускаючи, що вони є незалежними. Час виконання використовує техніки, такі як багатоверсійний контроль конкурентності (MVCC) та програмна транзакційна пам'ять(STM) для відстеження наборів для читання та запису під час виконання. Після виконання час виконання виявляє будь-які конфлікти або залежності. Він приймає виправні заходи, такі як абортів та повторне виконання конфліктних транзакцій, але може це зробити, читаючи з пам'яті замість диска, щоб ідентифікувати конфліктні транзакції.

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

Одна помітна реалізація цієї моделі знаходиться в Aptosта MoveVM вMovement Labs*, яка використовує метод, відомий як Block-STM. У Block-STM транзакції спочатку виконуються паралельно; потім конфліктні транзакції визначаються та плануються для повторного виконання на основі виявлених залежностей. Цей підхід забезпечує неперервне використання ресурсів обробки, покращуючи пропускну здатність при збереженні цілісності транзакційного робочого процесу.

Block-STM Aptos від «Scaling Blockchain Execution by Turning Ordering Curse to a Performance Blessing»

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

Block-STM використовує MVCC для ефективного управління одночасними записами та збереження кількох версій даних, тим самим запобігаючи конфліктам між одночасними операціями запису. Він включає спільний планувальник для координації завдань виконання та перевірки через кілька потоків, забезпечуючи, що транзакції фіксуються в порядку їх початку. Ця настройка мінімізує відміну транзакцій за допомогою динамічної оцінки залежності, що дозволяє транзакціям з залежностями ефективно чекати та вирішувати ці залежності перед продовженням.

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

У Монаді початковий набір транзакцій, виконаних паралельно, може бути сформований як фаза введення/виведення, яка може виробляти негайно зобов'язувальні результати, і наступна фаза «повтору», яка вимагає невеликої кількості роботи для розв'язання конфліктуючих залишкових транзакцій. Ці конфліктні переходи виходять на поверхню і витягуються в кеш, що дозволяє зменшити накладні витрати на виконання, оскільки вони знаходяться в пам'яті. Хоча більшість стану знаходиться на диску, конфліктні транзакції швидко доступні під час виконання.

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

Паралельність даних та завдань

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

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

Паралелізм даних

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

Одним зі спільних методів паралельності даних є однокомандний, кілька даних(SIMD), який дозволяє виконувати одну інструкцію одночасно на кількох елементах даних. Сучасні ЦП часто мають вбудовані можливості SIMD, що дозволяє їм виконувати паралельні операції над кількома точками даних. Використовуючи інструкції SIMD, розробники можуть досягти значного прискорення для певних типів операцій, таких як математичні обчислення, трансформація даних або обробка сигналів.

Наприклад, розгляньте сценарій, де вам потрібно застосувати складну математичну функцію до великого масиву чисел. Замість обробки кожного числа послідовно, SIMD може працювати з декількома числами одночасно. Цю одночасну обробку досягається завантаженням підмножини чисел в реєстри SIMD процесора, виконанням математичної функції на всіх завантажених числах паралельно, а потім збереженням результатів у пам'ять. Обробляючи декілька чисел одночасно, SIMD може значно скоротити загальний час виконання.

Робота Firedancer на ED25519підпис підтвердження демонструє потужність SIMD для оптимізації складних обчислень. Процес підтвердження підпису включає арифметичні операції в галуа-полях, які можуть бути обчислювально інтенсивними. Завдяки інструкціям SIMD, Firedancer може виконувати ці операції на кількох елементах даних одночасно, що призводить до значних покращень продуктивності. Ці оптимізації будуть критичними для покращення продуктивності Solana, яка вже реалізувала паралелізацію доступу до стану.

Паралельна задача

Паралельність завдань передбачає паралелізацію різних завдань або операцій у межах програми на кількох обчислювальних блоках. Цей підхід корисний, коли програма складається з кількох незалежних завдань, які можуть виконуватися паралельно. Розподіляючи кожне завдання на окремий обчислювальний блок, такий як ядро ЦП або ГПУ, час загального виконання може бути скорочений.

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

Лагранжа @lagrangelabs/a-big-data-primer-introducing-zk-mapreduce-12cf404eab75">ZK MapReduce (ZKMR) використовує паралелізм даних і завдань для ефективного розпаралелювання та генерації доказів розподілених обчислень на великих наборах даних. На етапі картографування вхідний набір даних розбивається на менші фрагменти, і кожен фрагмент обробляється окремо окремим працівником картографа або машиною паралельно (паралелізм завдання). Операція "map" може бути розпаралелена в рамках кожного завдання mapper на декількох ядрах або процесорах (паралелізм даних). Аналогічно, у фазі скорочення, операція «зменшення» над значеннями, пов'язаними з кожним ключем, може бути розпаралелена в рамках кожного завдання редуктора (паралелізм даних). На противагу цьому, завдання редуктора виконуються паралельно у кількох працівників (паралелізм завдань).

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

Перевірка довільної процедури MapReduce в ZK від Лагранжа «Вступ до ZK MapReduce»

Здатність Лагранжа генерувати докази зберігання для обчислень SQL над @lagrangelabs/оголошення-тестової-мережі-євкліда-першої-перевіреної-бази-даних-та-zk-копроцесора-cc4a5595365c">888,888 сховищ за 1 хвилину і 20 секунд демонструє потужність ZKMR, а також завдання та паралелизм даних, які їй лягають в основу. Крім того, останній успіх Лагранжа Рекл Трісстаття підкреслює потребу в паралелизмі тим, що забезпечує, що партійні докази ончейн-даних також обчислюються в 𝑂(log𝑛), незалежно від розміру партії.

Паралелізація консенсусу та виконання

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

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

Перекладачі & Зменшення накладних витрат

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

Reth виправляє недоліки EVM, включаючи компілятор з моментальною (JIT). Цей компілятор перетворює байткод в рідний машинний код миттєво перед виконанням, обходячи витратний процес інтерпретації, який зазвичай потрібно виконувати під час виконання.

Об'єкт стаття Rethзазначає, що 50% часу виконання EVM під системою на основі інтерпретатора присвячено процесам, які теоретично може оптимізувати JIT, що вказує на можливість подвоєння швидкості виконання з JIT реалізацією. Однак, як вказує Їлонг, вця презентація, хоча JIT може значно зменшити час, необхідний для обробки конкретних опкодів, це може не дуже вплинути на загальне виконання. Це тому, що значна частина 50% часу виконання EVM, яку займає JIT, включає операції "хост" та "система" (Слайд 13), які не піддаються оптимізації JIT, такі як «арифметичні» чи «контрольні», через їх некомп'ютерний характер.

Хоча інтерпретатори можуть обмежувати продуктивність, вони створюють можливість для «перекладу», що збільшує обсяг коду, який може використовувати нові віртуальні машини, знижуючи накладні витрати для розробників у використанні блоків дизайнера. Наприклад, компанія Movement Labs розробила Fractal, що дозволяє розробникам розгортати їх контракти на основі Solidity на MoveVM. Fractal працює шляхом компіляції Solidity в проміжну мову, що містить інструкції, виражені в опкодах EVM, які потім відображаються на відповідні байткоди MoveVM, що дозволяє контрактам Solidity працювати в середовищі MoveVM.

Спеціалізовані та налаштовані станові машини

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

Наприклад, додатки бази даних можуть потребувати постійного обходу деревоподібних структур даних, пошуку записів, оновлення значень та балансування дерев. На звичайному ЦП відображення цих операцій більш високого рівня вимагає розбиття їх на довгі послідовності мікро-операцій низького рівня, таких як завантаження, зберігання, гілки та арифметичні операції, які виконуються окремо на загальному обладнанні. На відміну від цього, ISA, спеціалізований для баз даних, може об'єднати ці повторювані шаблони в оптимізовані широкі інструкції, які використовують спеціалізоване обладнання. Інструкція "TraverseTree" може обчислювати адреси пам'яті, завантажувати відповідні вузли та порівнювати ключі за допомогою паралельних порівняльних схем, призначених для цієї операції. "UpdateEntry" може безпосередньо збирати запис з оптимізованого макету зберігання бази даних, змінювати його та фіксувати новий стан все це в одній інструкції.

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

LayerN’s Північдемонструє користь використання спеціалізованих середовищ виконання та структур даних через їх конкретний випадок перевірного замовлення. Підхід LayerN спрямований на оптимізацію розміщення угод в структурі даних замовлення, тоді як їх механізм конвеєру призначений для ефективного вставлення нових замовлень у відповідне положення у дереві даних замовлення. Шляхом налаштування структури даних та алгоритму вставки під конкретні вимоги замовлення, LayerN досягає низькочасного розміщення замовлень та високої пропускної здатності.

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

ВпевненийіCWDвикористовуйте стратегію, яка забалансовує компроміси між оптимізацією сировинної обчислювальної продуктивності та підвищенням розробника в досвіді та сумісності екосистеми. Цей підхід центрується на використанні WebAssembly (Wasm) як віртуальної машини для виконання коду. Wasm став вибраною ​​веб-розробкою через свою широку підтримку мов та широкий ступінь, до якого вона була прийнята.

Рішення розробника використовувати Wasm замість виконання клієнта на рівні нативного коду відображає стратегічне віддання універсальності та широкої доступності середовища виконання загального призначення. Хоча нативне виконання, яке виконує код безпосередньо на обладнанні без віртуальної машини, може пропонувати кращу продуктивність, воно обмежує сумісність між платформами та менш доступне для розробників. Натомість, Wasm забезпечує однорідне та безпечне середовище виконання на різних платформах незважаючи на те, що не досягає такої ж сирої швидкості, як нативне виконання. Ця компромісна угода відповідає філософіям дизайну Fluent та CWD, надаючи перевагу продуктивності розробника та широкій інтеграції екосистеми над максимальною ефективністю продуктивності.

Розгортання CosmWasm (CWD), зокрема, ілюструє цей підхід не лише за допомогою Wasm для виконання смарт-контрактів, але й включаючи його в більш обширну структуру, призначену для підтримки витонченостей операцій з блокчейн. Збагачений «периферійною логікою», цей фреймворк пропонує вдосконалене управління обліковими записами, налаштований механізм газу та оптимізоване упорядкування транзакцій. Ці функції сприяють гнучкому, ефективному, безпечному середовищу розробки, що дозволяє розробникам досить легко будувати масштабні та складні додатки.

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

Мікро-роллап-дизайн Stackr з “Введення Stackr SDK”

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

Це призводить до більш легкої та ефективної реалізації, оскільки бізнес-логіка реалізована на рівні клієнта, що усуває потребу в дорогих викликах та перевірці розумних контрактів. В результаті можливості щодо того, як налаштовано додаток, розширюються у плані різних типів мов програмування, структур даних та підписів, які розробники можуть використовувати для одного додатку без втрати продуктивності.

Висновок

Є кілька шляхів до оптимальної продуктивності рівня виконання.

Жодна єдине оптимізація до доступу до держави або паралелізації не виділяється як пропріетарний пункт технічної відмінності між шаровими виконавчими шарами під час спроб захоплення додатків. Коли ми пройшли, переваги ресурсної паралелізації на Solana можуть бути однаково застосовані до моделі UTXO Fuel. Кожен може використовувати Amazon’sінформативні рішення для покращення горизонтальної масштабованості за допомогою шардінгута покращити продуктивність рівня виконання.

Хоча продуктивність рівня виконання є критичним вектором для залучення розробників децентралізованих додатків, нові L1 та L2, спрямовані на поліпшення виконання, повинні конкурувати за іншими змінними, включаючи безпеку, взаємодію та сумісність із існуючими інструментами. З цієї причини поширення нових шарів взаємодії - від Nebra до Statenet до AggLayer від Polygon - буде критичним для розробників, які купують дизайнерський блокпростір, оскільки вони можуть будувати або купувати спеціалізований блокпростір, не жертвуючи синхронною комбінаторною можливістю та загальною ліквідністю традиційних L1 загального призначення.

Покращення управління станом та обчислювальної ефективності взаємозалежні.

По всіх спільнотах, які проектують нові рівні виконання, паралелізація доступу до стану стала визначальним мемом для покращення продуктивності, яку вони обіцяють принести. Це має свою вагому причину, оскільки це може призвести до Покращення у виконанні EVM в 5 разів, докази з ранніх експериментів Monad з паралелизацією показують, що його роль переоцінена, якщо інші поліпшення, такі як асинхронне введення/виведення, не розвиваються паралельно.

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

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

В кінці дня цінності блокпростору впливають на простір дизайну для рівнів виконання.

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

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

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

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

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

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

Як відзначив Срірам, термін "мінімально можлива децентралізація" не означає, що "підтвердження має бути бездозвільним", але що воно "просто має бути правильно стимульованим". Це означає, що добре контрольована система, де валідатори стикаються з серйозними наслідками за недобросовісну поведінку, може забезпечити безпеку та життєздатність без необхідності в надмірній децентралізації (h/t Sreeram).

Такі моделі управління вже тестуються в практичних застосуваннях. Наприклад, rollups, як, Arbitrum досліджують управління або комітетні системи для забезпечення виконання правил впорядкування транзакцій та вибору лідера, і вони розглядають механізми, за яких послідовники використовують дані onchain для забезпечення дотримання політик впорядкування транзакцій.

Незважаючи на ці досягнення, не існує остаточної «оптимальної фронтальної фронтиру» для балансування децентралізації та продуктивності.

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

*позначає портфельну компанію Archetype

Disclaimer：

1. Ця стаття перепечатана з [ дзеркало ), Перенаправте оригінальний заголовок «Дизайнерський блокпост: майбутнє середовищ виконання», Всі авторські права належать оригінальному авторові [Бенджамін Фанк]. Якщо є зауваження до цього перепублікування, будь ласка, зв'яжіться з Gate Learnкоманда, і вони швидко з цим впораються.

2. Відповідальність за відмову: Погляди та думки, висловлені в цій статті, є виключно тими, хто їх висловлює, і не становлять жодної інвестиційної поради.

3. Переклади статті на інші мови здійснюються командою Gate Learn. Якщо не вказано інше, копіювання, поширення або плагіатування перекладених статей заборонене.