Ми почали будувати Reth у 2022 році, щоб забезпечити стійкість Ethereum L1 та вирішити масштабування виконавчого рівня на Layer 2.

Сьогодні ми з нетерпінням ділимося шляхом Reth до 1 гігагаса на секунду в L2 до 2024 року та нашим довгостроковим планом для подальшого розвитку.

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

Ми вже масштабуємося?

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

Як ви вимірюєте продуктивність? Що означає газ на секунду?

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

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

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

Де ми сьогодні?

Кількість газу на секунду визначається шляхом ділення цільового використання газу на блок на час блоку. Тут ми демонструємо поточний пропускний здатність газу на секунду та запізнення на різних ланцюгах EVM L1s та L2s (не вичерпно):

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

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

Як Рет дістане 1 гігагаз за секунду? Поза цим?

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

Reth вже досягає 100-200mgas/s під час живої синхронізації (включаючи відновлення відправників, виконання транзакцій та обчислення триі на кожному блоку); ще 10 разів забезпечує досягнення нашої короткострокової цілі - 1 гігагас/с.

Поки ми розвиваємо розвиток Reth, наш план масштабування повинен балансувати масштабованість з ефективністю:

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

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

Ось краткий опис того, як ми маємо намір туди дістатися:

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

Вертикальна шкала маршрутування Reth

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

Вчасне та передчасне ЕОМ

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

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

Однак JIT може бути вразливим до зловмисного коду, розробленого для використання процесу JIT, або може бути занадто повільним для виконання під час виконання. Reth буде компілювати Ahead-of-Time (AOT) найвимогливіші контракти та зберігати їх на диску, щоб уникнути спроб ненадійного байткоду зловживати нашим кроком компіляції коду під час живого виконання.

Ми працюємо над компілятором JIT/AOT для Revm, який зараз інтегрується з Reth. Ми відкриємо вихідний код цього в наступні тижні, як тільки завершиться наше вимірювання продуктивності. Приблизно 50% часу виконання в середньому витрачається на інтерпретатор EVM, тому це має забезпечити покращення виконання EVM приблизно в 2 рази, хоча в деяких більш обчислювально важких випадках це може бути ще більш впливовим. Ми будемо ділитися нашими вимірюваннями продуктивності та інтеграцією нашого власного JIT EVM в Reth у наступні тижні.

Паралельний EVM

Концепція паралельної віртуальної машини Ethereum (Parallel EVM) дозволяє одночасну обробку транзакцій, відступаючи від традиційної послідовної моделі виконання EVM. У нас тут є 2 шляхи вперед:

1. Історична синхронізація: Під час історичної синхронізації ми можемо обчислити найкращий можливий графік розпаралелювання, аналізуючи минулі транзакції та виявляючи всі історичні конфлікти станів. Подивіться нашу ранню спробу зробити це в старій гілці на Github.
2. Live Sync: Для живої синхронізації ми можемо використовувати Блок STM-подібні техніки для спекулятивного виконання без будь-якої додаткової інформації, такої як списки доступу. Цей алгоритм показує погану продуктивність під час періодів важкого конфлікту стану, тому ми хочемо дослідити перехід між послідовним та паралельним виконанням залежно від форми робочого навантаження, а також статично прогнозувати, які слоти зберігання будуть використані для покращення якості паралельності. Перегляньте один PoC від команди 3-ї сторонитут.

За нашим історичним аналізом, ~80% слотів зберігання Ethereum доступні незалежно, що означає, що паралельність може призвести до покращення виконання EVM до 5 разів.

Удосконалення державних зобов'язань

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

В моделі Reth обчислення кореня стану - окремий процес від виконання транзакцій (бачити наш код) , що дозволяє використовувати стандартні магазини KV, які не потребують нічого знати про три. На даний момент це становить понад 75% часу від початку до кінця для запечатання блоку, і це дуже захоплююча область для оптимізації.

Ми визначаємо наступні 2 "легкі перемоги", які можуть дати нам 2-3 рази в продуктивності кореня стану, без будь-яких змін в протоколі:

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

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

1. Рідше становий корінь: Замість обчислення станового кореня на кожному блоку обчисліть його кожні T блоків. Це зменшує загальний відсоток часу, витраченого на становий корінь в усій системі, і може бути найпростішим та найефективнішим рішенням.
2. Слідчий корінь стану: Замість того, щоб обчислювати корінь стану в тому ж блоку, дозвольте йому відставати на кілька блоків. Це дозволяє виконанню просуватися вперед, не блокуючи обчислення кореня стану.
3. Замініть кодер RLP & Keccak256: Замість кодування за допомогою RLP може бути дешевше просто конкатенувати байти та використовувати швидку хеш-функцію, наприклад, Blake3.
4. Ширший Трай: Збільшити N-арність дерева, щоб зменшити I/O посилення через логарифмічну глибину трай.

Тут є кілька питань:

1. Які другорядні ефекти вищезазначених змін на легкі клієнти, L2s, мости, копроцесори та інші протоколи, які покладаються на часті докази рахунку та сховища?
2. Чи можемо ми оптимізувати зобов'язання до стану як для доведення SNARK, так і для внутрішньої швидкості виконання?
3. Який найширший зобов'язання держави, яке ми можемо отримати за допомогою наявних у нас інструментів? Які наслідки другого порядку є навколо розміру свідка?

горизонтальна доріжка масштабування Reth

Протягом 2024 року ми виконаємо кілька з перерахованих вище пунктів і досягнемо нашої мети в 1 гігагага/сек.

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

Multi-Rollup Reth

Сьогоднішні стеки L2 вимагають запуску кількох служб для слідування ланцюгу: L1 CL, L1 EL, функцію похідного L1 -> L2 (яка може бути включена до L2 EL), та L2 EL. Це дуже зручно для модульності, але ускладнюється при запуску кількох стеків вузлів. Уявіть, якщо вам потрібно запустити 100 rollups!

Ми хочемо дозволити запуск роллапів в тому ж процесі, що і Reth, та знизити операційні витрати на запуск тисяч роллапів практично до нуля.

Ми вже розпочали це з нашим Проекти розширення виконання ([1], [2]) , більше інформації буде надходити у наступні тижні тут.

Cloud-native Reth

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

Ми хочемо дозволити запуск Cloud-native Reth вузлів, розгорнутих як стек служб, які можуть автоматично масштабуватися за попитом обчислень та використовувати здається нескінченне об'єктне сховище хмар для постійності. Це загальна архітектура в проектах безсерверних баз даних, таких як NeonDB, CockroachDB або Amazon Aurora.

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

Перспектива

Ми маємо намір поетапно впроваджувати цю дорожню карту для всіх користувачів Reth. Наша місія - надати всім доступ до 1 гігагас / с та більше. Ми будемо тестувати наші оптимізації на Reth AlphaNet, і сподіваємося, що люди будуть будувати модифіковані високопродуктивні вузли, використовуючи Reth як SDK.

Є деякі питання, на які ми ще не знайшли відповіді.

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

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

Disclaimer：

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