Ethereum — це всесвітній комп’ютер без дозволів, який має (можливо) найвищий ступінь економічної безпеки на момент написання статті, діючи як реєстр розрахунків для величезної кількості активів, програм і послуг. Ethereum дійсно має свої обмеження – блоковий простір є дефіцитним і дорогим ресурсом на першому рівні Ethereum (L1). Масштабування другого рівня (L2) вважалося вирішенням цієї проблеми, оскільки в останні роки на ринок з’явилося багато проектів, переважно у формі зведених пакетів. Однак зведення, у строгому розумінні цього терміну (тобто дані зведення знаходяться на Ethereum L1), не дозволяє Ethereum масштабуватися необмежено, дозволяючи лише кілька тисяч транзакцій за секунду.

Мінімізація довіри – (особливість) системи L2 є мінімізованою довірою, якщо вона функціонує, не вимагаючи довіри поза межами базового L1.

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

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

1. Чому програми повинні бути зведені до мінімуму?
2. Навіщо створювати системи з горизонтальним масштабуванням?
3. Як ми можемо максимізувати як мінімізацію довіри, так і горизонтальну масштабованість?

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

Чому програми повинні бути зведені до мінімуму?

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

Існують значні ризики, пов’язані з довіреними позамережевими послугами. Крах основних бірж і сервісів у 2022 році, таких як FTX і Celsius, є чудовим попередженням про те, що відбувається, коли надійні сервіси поводяться неправильно та виходять з ладу.

З іншого боку, додатки з мінімізованою довірою можуть писати в Ethereum і зчитувати з нього. Приклади включають програми для смарт-контрактів, такі як Uniswap, зведені програми, такі як Arbitrum або zkSync, і співпроцесори, такі як Lagrange і Axiom. Загалом кажучи, довіра втрачається, коли програми стають захищеними мережею Ethereum, оскільки більше функціональних можливостей (див. нижче) передаються на аутсорсинг L1. У результаті можна пропонувати мінімізовані довірчі фінансові послуги без ризиків контрагента чи зберігача.

Є три ключові властивості, якими можуть володіти додатки та служби, які можуть бути передані L1:

1. Актуальність (та впорядкованість): трансакції, надані користувачем, мають бути включені (виконані та розраховані) своєчасно.
2. Дійсність: транзакції обробляються відповідно до заздалегідь визначених правил.
3. Доступність даних (і стану): історичні дані, а також поточний стан програми доступні для користувача.

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

Навіщо створювати системи з горизонтальним масштабуванням?

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

Вертикальне масштабування стосується масштабування через збільшення пропускної здатності монолітної системи, такої як Eth L1 або рівень доступності даних. Коли горизонтальне масштабування стикається з вузькими місцями на такому спільному ресурсі, часто потрібне вертикальне масштабування.

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

Доступність даних (DA) залишається вузьким місцем для зведених даних. Наразі максимальний розмір кожного блоку L1 становить ~1 МБ (85 КБ/с). З EIP-4844 буде доступно додатково ~2 МБ (171 КБ/с) (у довгостроковій перспективі). Завдяки Danksharding Eth L1 може підтримувати пропускну здатність DA до 1,3 МБ/с. Eth L1 DA — це спільний ресурс, за який конкурують багато програм і служб. Таким чином, хоча використання L1 для DA забезпечує найкращий захист, воно перешкоджає потенційній масштабованості таких систем. Системи, які використовують L1 для DA, (зазвичай) не зможуть горизонтально масштабуватись і матимуть негативний ефект від масштабу. Альтернативні рівні DA, такі як Celestia або EigenDA, також мають обмеження пропускної здатності (хоча й більші, 6,67 МБ/с і 15 МБ/с відповідно). Але це відбувається за рахунок перенесення припущення про довіру з Ethereum на іншу (часто менш децентралізовану) мережу, що ставить під загрозу (економічну) безпеку.

Твердження 2. Єдиний спосіб горизонтально масштабувати послуги з мінімізованою довірою — це отримати (близько до) нульових граничних даних L1 на транзакцію. Два відомі підходи — це зведення відмінностей у стані (SDR) і валідіуми.

Зведені різниці в стані (SDR) — це зведені дані, які публікують різниці в стані в сукупності транзакцій в Ethereum L1. Для EVM, коли пакети транзакцій збільшуються, дані кожної транзакції, опубліковані в L1, зменшуються до константи, яка є набагато меншою, ніж у зведених транзакційних даних.

Наприклад, під час стрес-тесту великого потоку записів zkSync спостерігав зменшення даних викликів на транзакцію до 10 байт на транзакцію. Навпаки, зведення даних транзакцій, як-от Arbitrum, Optimism і Polygon zkEVM, зазвичай бачать близько 100 байт на транзакцію для звичайного трафіку.

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

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

А як щодо централізованих проти децентралізованих секвенсорів? Щоб підтримувати горизонтальну масштабованість систем, вкрай важливо створювати незалежні секвенсори, централізовані чи децентралізовані. Примітно, що хоча системи, які використовують спільні секвенсори, мають атомарну <a href="https://hackmd.io/@EspressoSystems/SharedSequencing"> компоновність, вони не можуть горизонтально масштабуватися, оскільки секвенсор може стати вузьким місцем, коли додається більше систем.

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

Мінімізація довіри для горизонтально масштабованих систем

Чи можемо ми додатково мінімізувати вимоги довіри до живучості, упорядкованості та доступності даних у горизонтально масштабованих системах?

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

Інше рішення — просто децентралізувати (але не покладатися на L1). Замість одного секвенсора системи можуть стати більш децентралізованими, використовуючи децентралізовані секвенсори (наприклад, Espresso Systems або Astria), таким чином мінімізуючи довіру, необхідну для живучості, упорядкування та доступності даних. Це накладає обмеження порівняно з рішеннями з одним оператором: (1) продуктивність може бути обмежена продуктивністю розподіленої системи, і (2) для валідіумів із приватним DA гарантія конфіденційності за замовчуванням втрачається, якщо децентралізована мережа секвенсора не має дозволу.

Скільки довіри ми можемо додатково мінімізувати для валідіумів з одним оператором або SDR? Тут є пара відкритих напрямків.

Відкритий напрямок 1: доступність даних у валідіумах з мінімізованою довірою. Плазма певною мірою вирішує проблему доступності стану – вона вирішує проблему або для зняття лише для певних моделей стану (до яких входить модель стану UTXO), або вимагає від користувачів періодичного підключення до Інтернету (Без Плазми).

Відкритий напрямок 2: підзвітні попередні підтвердження в ЄСВ та валідіумах. Мета тут полягає в тому, щоб надати користувачам швидке попереднє підтвердження включення транзакції від секвенсора, і це підтвердження має дозволити користувачеві оскаржити та скоротити економічну частку секвенсора, якщо обіцянка включення не виконана. Проблема тут полягає в тому, що підтвердження невключення (необхідного для розрізання), ймовірно, потребує додаткових даних для користувача, які секвенсор може просто приховати. Таким чином, розумно припустити, що ми принаймні вимагаємо, щоб SDR або validium використовували (потенційно дозволений) комітет доступності даних для своїх повних даних викликів або історії транзакцій, що дозволяє цьому ж комітету надати докази невключення (попередніх підтверджені транзакції) за запитом користувача.

Відкритий напрямок 3: Швидке відновлення після збоїв у живучості. Системи з одним оператором можуть страждати від збоїв у життєдіяльності (наприклад, Arbitrum вийшов з мережі під час події запису). Чи можемо ми розробити системи, які забезпечать мінімальні перебої в обслуговуванні за цього сценарію? У певному сенсі L2, які дозволяють самопослідовність і пропозиції станів, дійсно забезпечують гарантії від тривалих збоїв живучості. Розробка систем з одним оператором, які є більш стійкими до коротших відмов у живучості, наразі недостатньо досліджена. Одне з потенційних рішень тут полягає в тому, щоб зробити невдачі живучості відповідальними, забезпечивши скорочення проти невдач живучості. Інше можливе рішення полягає в тому, щоб просто скоротити період затримки (який наразі становить близько тижня) до того, як може відбутися поглинання.

Висновок

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

Подяки

Велика подяка Віталіку Бутеріну та Террі Чангу за відгуки та обговорення, а також Діані Біггс за її редакційні коментарі.

声明:

Відмова від відповідальності:

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