По мере развития и совершенствования сети Ethereum все большее значение приобретает понимание концепции различных типов узлов. Однако реальность такова, что большинство пользователей не готовы приложить усилия для запуска узла, несмотря на то, что аппаратные требования выполнимы для многих. В «конечной стадии» развития Ethereum крайне важно, чтобы пользователи могли проверять целостность состояния и доступность данных без необходимости обладать обширными техническими знаниями или ресурсами. Ведь блокчейн без возможности проверки - это всего лишь неэффективная база данных.

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

Кінцеві вузли без стану

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

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

Візія для бездержавного Ethereum

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

У цьому фінальному етапі, фактично всі гаманці варто використовувати буде мати безстатевий вузол, який для кожного нового блоку, що додається до ланцюжка, може запитати будь-який повний вузол на рівні p2p для отримання останнього блок-заголовка та zk-доказу того, що зміни стану від попереднього заголовка блоку було виконано правильно, запросити деякі випадкові вибірки даних від кількох пір для отримання майже на 100% впевненості в тому, що всі дані (блоби та дані виконання блоку) були опубліковані, а також zk-доказ, який підтверджує, що мережа прийшла до згоди та завершила блок.

Пропускна здатність / обчислення для цього дуже мала і може повністю виконуватися на телефоні (чи навіть на смарт-годиннику, наприклад@drakefjustin""> @drakefjustin любить згадувати).Такий тип вузла, згаданий вище, був би класифікований як тип "безстатевий" вузол, оскільки вузол може перевіряти нові блоки, не потребуючи поточного стану локально і замість цього покладаючись на різні типи доказів для перевірки нових блоків.

Ці докази не повинні бути zk-доказами. Ми будемо мати безстандартну перевірку виконання давно, перш ніж ми зможемо зробити те, що я описав вище з zk-доказами для виконання. Фактично, безстандартне виконання може бути виконано сьогодні, але це ДУЖЕ неефективно з поточною структурою Merkle-Patricia-Tree, докази свідків занадто великі, щоб бути практичними. (див. @peter_szilagyi‘s tweet).

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

Структура Ethereum m’s MPT

Проте Ethereum планує оновити структуру свого дерева стану на щось інше, ніж поточна структура дерева Меркла-Патріції у майбутньому. Багато з вас можливо чули про дерева Verkle, які були в дорожній карті вже кілька років (Якщо ні, то прочитайте нашу статтю -Verkle Trees для нас решта: частина 1). Вони дозволили би створення безстатевих клієнтів, що є практичними, оскільки природа структури дерева Веркле дозволяє дуже маленькі свідки/докази.

Merkle tree проти дерева Verkle

Одна з основних проблем Веркл-дерев полягає в тому, що вони не є квантово-безпечними, це означає, що вони в найкращому випадку будуть тимчасовим рішенням, до того часу, поки постійне рішення для структури дерева стану не стане досить зрілим та/або ефективним. Кінцеве рішення, ймовірно, буде деревом хешування з бінарним доказом STARK, і дуже можливо, що Веркл-дерева будуть пропущені на користь якоїсь версії дерева хешування з бінарним доказом STARK. (відповідний мем з @VitalikButerin)

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

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

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

Вузли зі станом кінцевої гри

Станові вузли зберігають лише поточний та дуже останній стан, вони видаляють все, що старше певного віку (див. eip-4444proposal). Поточний стан потрібний для локальної побудови блоків, і це є щось, що безстатеві вузли не здатні робити.

Stateful nodes should not be confused with “full” nodes as a stateful node will not hold the complete chain history because that will get really data intensive in the future. A stateful node is useful for any user who wants quick and trustless access to the current state of Ethereum, whether it is for querying data from the state, building blocks or using this type of a node for staking.

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

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

Добра новина в тому, що зі строком припинення ми можемо значно спростити запуск станового вузла, оскільки стан, з яким ніхто не взаємодіяв протягом деякого часу, може бути видалений з диска вузла, кожен, хто хоче взаємодіяти зі станом, який має строк припинення, повинен мати свідка (в основному мерклове доказу), щоб повернути прострочений стан у поточний стан. Кожен, хто має доступ до історії ланцюжка, може безпосередньо побудувати ці типи доказів для повернення простроченого стану. На момент написання цього тексту стан Ethereum наближається до 300 ГБ і до впровадження якогось виду строку припинення стан буде продовжувати зростати в більш-менш тільки вгору тенденції.

(Тутце дуже велика стаття від @paradigmщо глибоко займається темою зростання держави та закінчення терміну дії держави)

Повні/архівні вузли

Для цілей цього стаття я збираюсь пакетний повний і архівні вузли разом, оскільки звичайний повний вузол може з інформацією, яку він записав на локальний диск, обчислити всі дані, які архівний вузол записав на диск. Різниця полягає в тому, що повний вузол обрізає стан, який більше не є останнім/найновішим станом. Ви не можете запитати, наприклад, "який був баланс ETH рахунку X на блоку Y близько 5 років тому" звичайному повному вузлу, тоді як архівний вузол відповів би на цей запит за мілісекунду.

Простий посібник з Ethereum Full Node Vs Archive Node за @0xZeeve

З огляду на це, в теорії можливо обчислити відповідь на це запитання з даних, які повний вузол записав на диск (весь ланцюжок історії), але не багато виконавчих клієнтів підтримують цю функцію. Я думаю, що нерозумно думати, що багато користувачів, навіть висококваліфіковані, будуть використовувати повний/архівний вузол, скажімо, через 10 років, щоб це була розумна опція, ми повинні обмежити пропускну здатність L1 до рівнів, які абсолютно нерозумні, коли ми можемо отримати набагато більше пропускної здатності на L1 з мінімальними компромісами. Коли більшість користувачів може легко перевірити нові блоки з zk-доказом, я думаю, що це варто розглянути, коли переваги настільки великі.

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

Нова ера для Ethereum

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

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

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