Вступ

Те, що зберігають та посилаються на блокчейнах під час обробки транзакцій, називають станом. На Ethereum стан - це властивість, яка сприяє консенсусу вузлів. Кожен повний вузол повинен зберігати та оновлювати цей стан під час кожного періоду дійсних блоків. Стан, як важливі для блокчейнів, мають й недолік; вони зростають з часом. Вони є серйозною проблемою у блокчейнах, таких як Bitcoin та Ethereum, оскільки збільшення розміру супроводжується відповідним зростанням апаратних вимог для вузлів. Поріг простору з часом виключає деякі вузли, що призводить до централізації.EIP-2935пропонує зробити Ethereum бездержавним, звільняючи вузли від обтяження обсягу. EIP-2935 - це пропозиція щодо вдосконалення, яка намагається досягти бездержавності, зберігаючи та обслуговуючи останні 8192 хеш-блоків зі стану для бездержавного виконання в Ethereum.

Короткий огляд поточної структури Ethereum

Блоки

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

Alt: Зміна стану в Ethereum

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

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

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

1. Провідний блок випадково вибирає валідатора,
2. Валідатор збирає транзакції разом та виконує їх для визначення нового глобального стану,
3. Вони включають цю інформацію в новий блок і розсилають її решті набору валідаторів за допомогою протоколу слухання,
4. Інші перевіряючі повторно виконують транзакції, щоб забезпечити їхню валідність та погодитися зі зміною глобального стану як консенсус,
5. Якщо перевірник підтверджує новий блок як дійсний, вони додають його до свого сховища.

Фінальність блоку та транзакції означає, що їх не можна змінити без значного спалювання ETH у розподіленій мережі. Ethereum має підхід з «контрольними блоками» для управління фіналізацією. Перший блок в кожній епосі вважається контрольною точкою цього слоту. Валідатори голосують за це припущення, щоб зробити його дійсною контрольною точкою. Якщо дві третини загальної кількості зароблених ETH з голосами валідаторів обирають пару контрольних точок, контрольні точки підвищуються до обґрунтованих. Попередні контрольні точки, що були обґрунтовані, підвищуються після наступного підвищення контрольних точок, і вони стають остаточними. Якщо зловмисник хоче скасувати фіналізований блок, йому потрібно зобов'язатися втратити принаймні одну третину загального обсягу зароблених ETH. Хоча існує механізм під назвоювитік неактивностііснує для відновлення остаточності шляхом накладання великих штрафів на кошти валідаторів та скорочення винагород атестаторів у разі постійної невдачі великої кількості валідаторів.

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

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

Дерева Меркла та Меркла-Патріції

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

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

Ethereum використовує Merkle Patricia Tries, подвійну структуру Merkle trie. Він використовує бінарні дерева для базової обробки даних, таких як дані транзакцій, оскільки цей підхід є більш ефективним у таких ситуаціях. Однак у складних випадках Ethereum використовує складніші Merkle Patricia Tries, наприклад, при роботі зі станом.

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

Корінь триє залежить лише від даних, а не від порядку. Оновлення даних у різному порядку не змінять сам корінь.

Alt: Бінарне дерево Меркла

Ефіріум використовує змінений Мерклівський Патріційний триє, який має деякі особливості від ПАТРІСІЯ (Практичний алгоритм для отримання інформації, закодованої в алфавітно-цифровому вигляді)та Merkle Trie з модифікаціями вздовж нього. Ця архітектура є детермінованою та криптографічно перевіреною. Єдиний спосіб згенерувати корінь стану в цій структурі - обчислити його з кожного окремого шматка стану. Два ідентичних стани можна легко підтвердити, порівнявши кореневий хеш та хеші, які до нього призвели.

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

Альт: Меркл-Патріція-дерево

Газ

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

Альт: https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf

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

Стан

Стан блокчейну може бути визначено як набір даних (або змінних), які описують певну систему в певний період часу. Інтернет мав стан практично з самого початку, але він зберігався на одному сервері. З Web3 був введений глобальний стан, який підтримується на відкритій та розподіленій мережі, захищеній за допомогою децентралізованих методів. Кожен може переглядати та підтверджувати стан розподіленої мережі у будь-який час, коли вони цього побажають.

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

Відмінності між закінченням даних та закінченням стану

Термін дії даних

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

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

EIP-4444забезпечує практичний шлях до@hBXHLw_9Qq2va4pRtI4bIA/ryzBaf7fJx?ref=ghost-2077.arvensis.systems">досягнути завершення даних через слабку суб'єктивність. Пропозиція не має на меті змінити спосіб обробки вузлами Ethereum даних стану; натомість, вона змінює доступ до історичних даних.

Термін дії

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

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

Stateless Ethereum

Вступ до бездомності та бездержавного Ethereum

Stateless Ethereum introduces new concepts to the core protocol. Ideally, statelessness doesn’t imply that state does not exist. Rather, it means clients can choose the state they want to maintain. When clients receive validated blocks, they also receive the corresponding witness for that block. Witnesses for each block consist of all the data required to execute the transactions contained in that block.

EIP-161вперше був введений підхід до скорочення стану. Ethereum потерпів атаку DoS (відмова в обслуговуванні), і ця уразливість дозволила створювати порожні облікові записи, які збільшували глобальний стан Ethereum. EIP-161 запропонував видаляти порожні облікові записи з нульовим (0) значенням їх nonce, які були створені цим нападом, із низькими витратами. Пропозиція була виконана, що призвело до повернення стану.

Ще одна спроба досягнення бездержавності була запропонована через EIP-4788. Ця пропозиція мала на меті викрити коріння блоків ланцюга маяка в EVM. Схоже на підхід Міст Eth1-Eth2з'єднуючи Ланцюг маяка (шар консенсусу) та шар виконання, ця пропозиція дозволяє доступ з мінімізацією довіри між EVM та шаром консенсусу.

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

Бездержавність в Ethereum можлива як слабка, так і сильна бездержавність.

Слабка бездержавність

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

Пропоненти блоку повинні зберігати повні дані стану. Однак перевірювальні клієнти не повинні зберігати дані стану в мережі. Замість цього вони можуть зберігати корінь стану (хеш всього стану). Слабка безстатевість потребує Розділення пропонента-будівельника (PBS)іVerkle спробуєвпровадження.

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

Міцна бездержавність

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

Однак деякі зміни та властивості можуть бути використані для досягнення безстатевості. EIP-2935 пропонує надавати історичні хеші блоків зі стану для виконання без стану.

Вступ до EIP-2935

EIP-2935 має на меті збереження історичних хешів блоків у стані блокчейну в спеціальних слотах зберігання, які називаються АДРЕСИ_ЗБЕРІГАННЯ_ІСТОРІЇ. Цей процес дозволить виконання без стану шляхом полегшення доступу до необхідної історичної інформації в безстандартних клієнтах.

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

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

Розширення діапазону блоків, які обслуговує blockHash до 8192 блоків, дозволить м'який перехід до виконавчих методів. Rollups можуть скористатися цим довшим вікном історії, безпосередньо запитуючи цей контракт, оскільки дані blockHash зберігаються в цьому контракті. Крім того, цей EIP сприятиме валідації доказів, пов'язаних з 8192 блоками, обсягу HISTORY_SERVE_WINDOW у порівнянні з поточним станом.

Розуміння EIP-2935

EIP-2935 дозволяє клієнтам Ethereum, особливо безстандартним, легко отримувати доступ до останніх хешів блоків. Щоб це працювало, воно вводить чотири нові параметри:

• BLOCKHASH_SERVE_WINDOW: Повідомляє клієнтам, скільки попередніх хеш-блоків вони повинні зберігати. Значення за замовчуванням - 256.
• HISTORY_SERVE_WINDOW: Цей параметр визначає, скільки блоків хешів зберігається. Значення за замовчуванням - 8191.
• SYSTEM_ADDRESS: Спеціальна адреса (спочатку введена в EIP-4788), яка виступає як "викликаючий" для запису хешів блоків в сховище.
• АДРЕС_ЗБЕРІГАННЯ_ІСТОРІЇ: Адреса контракту, де зберігаються хеші цих блоків.

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

Кільцевий буфер

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

Правила вибору вілки та специфікації

Після розділення, коли мережа стартує з урахуванням цих EIP, параметр HISTORY_STORAGE_ADDRESS буде відомий як SYSTEM_ADDRESS з блоком block.parent.hash введенням (за замовчуванням 32 байти), газовим лімітом 30 000 000 та значенням 0. Цей процес спричинить виклик функції set() контракту історії.

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

• Повинен виконатися до завершення
• Не враховується при ліміті газу блоку
• Не дотримується механізму спалювання EIP-1559
• Якщо код не існує за HISTORY_STORAGE_ADDRESS, виклик повинен завершитися не з фатальними помилками.

Цей процес повинен заповнити період блокування ІСТОРІЯ_СЕРВЕР_ВІКНО, щоб відповідати періоду тригера кільцевого буфера. Історичний контракт буде містити лише батьківський хеш блоку гілки, який служить посиланням на хеш та нову точку початку хешування.

Контракт історії хешу блоку матиме дві операції: get() та set(). Операція set() активується, якщо викликач контракту в транзакції дорівнює SYSTEM_ADDRESS, яка була введена з EIP-4788. Якщо викликач та SYSTEM_ADDRESS не дорівнюють або не виконують умови, активується операція get().

Операція get() використовується в EVM для знаходження хешів блоків. Вона дозволяє викликачам вказати номер блоку, який вони запитують, якщо вхідні дані calldata не становлять 32 байти (що означає, що це дійсний block.parent.hash), і якщо запит знаходиться за межами діапазону ([block.number-HISTORY_SERVE_WINDOW, block.number-1]), він скасовує транзакцію.

set() приймає вхідний block.parent.hash як calldata, коли викликач викликає контракт з транзакцією. Він також встановлює значення сховища як calldata[0:32] на block.number-1 % HISTORY_SERVE_WINDOW.

АДРЕСА_ЗБЕРІГАННЯ_ІСТОРІЇ буде розгорнуто через EIP-4788, який вище названий способом доступу до хешів блоків безпосередньо через шар консенсусу в EVM. АДРЕСА_ЗБЕРІГАННЯ_ІСТОРІЇ матиме значення nonce як 1 і буде виключено зі стандарту очищення нульового nonce за EIP-161.

Логіка переходу BLOCKHASH

Одне з питань, пов'язаних з цим EIP, - як найкраще перейти до логіки розв'язання BLOCKHASH після відгалуження. Розглядаються два основні підходи:

• Зачекайте HISTORY_SERVE_WINDOW блоків, щоб вся необхідна історія залишилася.
• Зберігайте всі останні хеші блоків HISTORY_SERVE_WINDOW на блоку гілки.

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

Яка різниця між EIP-2935 та подібними EIP?

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

• Підхід на основі структури трие: EIP-2935 не використовує структуру трие з кількома шарами, а замість цього вибирає один список. Навпаки, EIP-4444 пропонує обрізання історичних даних у виконавчих клієнтах старше року. Інші EIP зі схожими амбіціями вимагають Verkle tries.
• Запис EIP у коді EVM: EIP-2935 не потребує зміни в EVM.
• Послідовне необмежене зберігання хешів: Послідовне необмежене зберігання хешів є неефективним. Цей EIP подолає цю проблему, пакуючи хеші.

Питання безпеки

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

Що воно може принести?

• Зроблення безвідмовних систем оракулів швидше: у відоснованих на Uniswap v2 оракулах будь-хто з доступом до вузла Ethereum може згенерувати доказ зберігання Uniswap та надіслати його для перевірки на ланцюжку. Середня ціна визначається між поточним блоком та блоком, підтвердженим доказом, з перевіреним доказом до 256 блоків, оскільки blockHash підтримує до 256 блоків. Завдяки EIP-2935, цей процес можна покращити, дозволяючи доступ до старіших хешів блоків, що означає, що докази можуть бути підтверджені протягом тривалішого періоду.
• Дозволяючи договорам враховувати твердження про минулий стан, безпечно: покращення EIP-2935 створює можливість дивитися на дані блокчейну зсередини EVM, безпечно. Клієнт може запитати історію, отримати її хеш та перевірити з іншими вузлами. Рішення може зробити легкі клієнти ефективними та легкими в реалізації.
• Зведення між L1 <> L2: Для перевірки повідомлення з L2, L1 повинна знати про корені стану L2 та хеші блоків. Однак в поточному стані L1 не може отримати доступ до довільних хешів блоків через обмеження газу та архітектурні обмеження. EIP-2935 дозволяє L1 перевіряти довільні історичні дані з можливістю дослідження доказів включення для старих подій. Доступ та потужність перевірки покращаться, а продуктивність міжмережевого зв'язку.

Висновок

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

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

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

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

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