Глемстердам

Майбутнє оновлення Ethereum під назвою Glamsterdam покликане прокласти шлях для наступного покоління масштабування. Назва Glamsterdam походить від поєднання "Amsterdam" (оновлення рівня виконання, назване на честь попереднього місця проведення Devconnect) та "Gloas" (оновлення рівня консенсусу, назване на честь зірки).

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

У той час як Fusaka зосереджується на фундаментальних удосконаленнях, Glamsterdam просуває цілі «Scale L1» та «Scale Blobs», закріплюючи розподіл обов’язків між різними учасниками мережі та запроваджуючи ефективніші способи обробки даних для підготовки до високопродуктивної паралелізації.

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

Розглядаються можливі покращення для Гламстердама

Оновлення Glamsterdam зосереджено на трьох основних цілях:

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

Коротше кажучи, Glamsterdam запровадить структурні зміни, щоб забезпечити стабільність і високу продуктивність мережі в міру збільшення її пропускної спроможності.

Масштабування L1 та паралельна обробка

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

Основна пропозиція: закріплення розділення ролей між пропонентом і розробником (ePBS)

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

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

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

Закріплене розділення ролей пропонента та будівельника (ePBS, або EIP-7732) формально розділяє завдання пропонента (який обирає консенсусний блок) та будівельника (який збирає виконавче навантаження), закріплюючи цю передачу безпосередньо в протоколі.

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

Для вирішення проблеми вузького місця «гарячого шляху» ePBS також запроваджує Комітет своєчасності корисного навантаження (PTC) та логіку подвійного дедлайну, дозволяючи валідаторам засвідчувати консенсусний блок та своєчасність виконавчого навантаження окремо, щоб максимізувати пропускну здатність.

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

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

Ресурси: технічна специфікація EIP-7732 (opens in a new tab)

Пропозиція щодо основної теми: списки контролю доступу на рівні блоків (BAL)

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

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

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

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

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

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

eth/71 обмін списком доступу до блоків

Обмін списками доступу до блоків (eth/71 або EIP-8159) є прямим мережевим доповненням до списків доступу на рівні блоків. У той час як списки доступу до блоків розблоковують паралельне виконання, eth/71 оновлює протокол «рівний-рівному», щоб дозволити вузлам фактично обмінюватися цими списками через мережу. Впровадження обміну списками доступу до блоків забезпечить швидшу синхронізацію та дозволить вузлам виконувати оновлення стану без виконання.

Ресурси:

• Технічна специфікація EIP-7928 (opens in a new tab)
• Технічна специфікація EIP-8159 (opens in a new tab)

Стійкість мережі

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

Збільшення вартості газу для створення стану

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

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

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

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

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

EIP-8037 також запроваджує модель резервуару для більш передбачуваного управління цими витратами; плата за стан береться спочатку з state_gas_reservoir, а опкод GAS повертає лише gas_left, запобігаючи неправильному розрахунку доступного газу кадрами виконання.

До EIP-8037 обчислювальна робота (активна обробка) та постійне зберігання даних (збереження смарт-контракту в базі даних мережі) мали однаковий ліміт газу. Модель резервуара розділяє облік: ліміт газу для фактичної обчислювальної роботи транзакції (обробки) та для довгострокового зберігання даних (газ стану). Розділення цих двох аспектів допомагає запобігти тому, щоб величезний обсяг даних програми вичерпував ліміт газу; доки розробники надають достатньо коштів для заповнення резервуара для зберігання даних, вони можуть розгортати набагато більші та складніші смарт-контракти.

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

Ресурси: технічна специфікація EIP-8037 (opens in a new tab)

Оновлення вартості газу для доступу до стану

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

Зі зростанням стану Ethereum пошук і читання старих даних («доступ до стану») стали важчими та повільнішими для обробки вузлами. Комісії за ці дії залишалися незмінними, хоча зараз пошук інформації (з точки зору обчислювальної потужності) став трохи дорожчим.

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

Оновлення вартості газу для доступу до стану (або EIP-8038) збільшує газові константи для опкодів доступу до стану, таких як пошук даних облікового запису та контракту, щоб привести їх у відповідність до продуктивності сучасного обладнання та розміру стану.

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

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

Ресурси: технічна специфікація EIP-8038 (opens in a new tab)

Стійкість мережі

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

Виключити валідаторів, яким було накладено штраф, з пропозицій

• Запобігає вибору валідаторів, які отримали штраф (були покарані), для пропонування майбутніх блоків, усуваючи гарантовані пропущені слоти.
• Забезпечує безперебійну та надійну роботу Ethereum, запобігаючи серйозним збоям у разі масового слешингу.

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

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

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

Ресурси: технічна специфікація EIP-8045 (opens in a new tab)

Дозволити виходам використовувати чергу консолідації

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

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

Дозволити виходам використовувати чергу консолідації (або EIP-8080) демократизує чергу консолідації для всіх виходів зі стейкінгу, створюючи єдину, справедливу чергу для всіх.

Розберемо, як це працює сьогодні:

• Ліміт відтоку Ethereum — це запобіжний ліміт на швидкість, з якою валідатори можуть входити, виходити або об'єднувати (консолідувати) свої стейкнуті ETH, щоб гарантувати, що безпека мережі ніколи не буде дестабілізована.
• Оскільки консолідація валідаторів є складнішою дією з більшою кількістю рухомих частин, ніж стандартний вихід валідатора, вона займає більшу частину цього бюджету безпеки (ліміт обороту)
• Зокрема, протокол передбачає, що точна вартість безпеки одного стандартного виходу становить дві третини (2/3) вартості однієї консолідації.

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

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

Ресурси: технічна специфікація EIP-8080 (opens in a new tab)

Покращення досвіду користувачів і розробників

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

Зменшення внутрішніх витрат газу на транзакції

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

Усі транзакції Ethereum сьогодні мають фіксовану базову комісію за газ, незалежно від того, наскільки простою чи складною є їх обробка. Зменшення внутрішнього газу транзакції (або EIP-2780) пропонує зменшити цю базову комісію, щоб зробити стандартний переказ ETH між існуючими обліковими записами до 71% дешевшим.

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

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

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

Ресурси: технічна специфікація EIP-2780 (opens in a new tab)

Детерміноване попереднє розгортання фабрики

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

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

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

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

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

Ресурси: технічна специфікація EIP-7997 (opens in a new tab)

Перекази та спалювання ETH генерують журнал

• Автоматично створює постійний запис (журнал) щоразу, коли ETH переказується або спалюється
• Усуває історичну сліпу пляму, яка дозволяє додаткам, біржам і мостам надійно виявляти депозити користувачів без спеціальних інструментів відстеження.

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

Перекази та спалювання ETH генерують журнал (або EIP-7708), який зобов'язує мережу генерувати стандартну подію журналу щоразу, коли переміщується або спалюється ненульова сума ETH.

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

Ресурси: технічна специфікація EIP-7708 (opens in a new tab)

eth/70 часткові списки отриманих блоків

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

eth/70 (часткові списки отримання блоків, або EIP-7975) запроваджує новий спосіб взаємодії вузлів (eth/70), що дозволяє розбивати ці великі списки на менші, більш керовані частини. eth/70 запроваджує систему пагінації для комунікаційного протоколу мережі, яка дозволяє вузлам розбивати списки отримання блоків і безпечно запитувати дані меншими, більш керованими частинами.

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

Ресурси: технічна специфікація EIP-7975 (opens in a new tab)

Додаткова література

• Дорожня карта Ethereum
• Прогноз: Глемстердам (opens in a new tab)
• Glamsterdam Meta EIP (opens in a new tab)
• Оновлення пріоритетів протоколу на 2026 рік: анонс у блозі (opens in a new tab)
• Подкаст The Daily Gwei Refuel — Постквантовий Ethereum, наближається Glamsterdam (opens in a new tab)

Поширені запитання

Як можна конвертувати ETH після хардфорку Glamsterdam?

• Жодних дій для вашого ETH не потрібно: після оновлення Glamsterdam вам не потрібно конвертувати або оновлювати свій ETH. Баланси ваших рахунків залишаться незмінними, а ETH, який ви зараз маєте, залишиться доступним у його існуючій формі після хардфорку.
• Остерігайтеся шахрайства! Будь-хто, хто наказує вам «оновити» ваш ETH, намагається вас обдурити. Вам не потрібно нічого робити у зв’язку з цим оновленням. Ваші активи залишаться повністю недоторканими. Пам’ятайте, що бути поінформованим — найкращий захист від шахрайства.

Більше про те, як розпізнати шахрайство та уникнути його

Чи впливає оновлення Glamsterdam на всі вузли та валідатори Ethereum?

Так, оновлення Glamsterdam вимагає оновлення як клієнтів виконання, так і клієнтів консенсусу. Оскільки це оновлення запроваджує вбудоване розділення пропонента-будівельника (ePBS), операторам вузлів потрібно буде переконатися, що їхні клієнти оновлені для обробки нових способів створення, перевірки та підтвердження блоків мережею.

Усі основні клієнти Ethereum випустять версії, що підтримують хардфорк, позначений як високий пріоритет. Ви можете стежити за тим, коли ці випуски будуть доступні в репозиторіях клієнтів на GitHub, їхніх каналах Discord (opens in a new tab), EthStaker Discord (opens in a new tab) або підписавшись на блог Ethereum, щоб отримувати оновлення протоколу.

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

Що мені, як стейкеру, потрібно зробити для оновлення Glamsterdam?

Як і під час кожного оновлення мережі, переконайтеся, що ви оновили свої клієнти до останніх версій, позначених підтримкою Glamsterdam. Слідкуйте за оновленнями в списку розсилки та оголошеннями про протоколи в блозі EF, (opens in a new tab) щоб бути в курсі випусків.

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

Які вдосконалення Glamsterdam запропонує для масштабування L1?

Головною особливістю є ePBS (EIP-7732), яка відокремлює складне завдання перевірки мережевих транзакцій від завдання досягнення консенсусу. Це розширює вікно поширення даних з 2 до приблизно 9 секунд, розблоковуючи здатність Ethereum безпечно обробляти значно вищу пропускну здатність транзакцій та вміщувати більше блоків даних для мереж другого рівня.

Чи знизить Glamsterdam комісії за Ethereum (Layer 1)?

Так, Glamsterdam, швидше за все, зменшить комісії для звичайних користувачів! Зменшення внутрішнього газу транзакцій (або EIP-2780) знижує базову комісію за надсилання ETH, що робить ETH набагато дешевшим для використання в повсякденних платежах.

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

Чи будуть якісь зміни в моїх наявних смарт-контрактах після Glamsterdam?

Існуючі контракти продовжуватимуть функціонувати в звичайному режимі після запуску Glamsterdam. Розробники, ймовірно, отримають кілька нових інструментів і повинні переглянути використання газу:

• Збільшення максимального розміру контракту (або EIP-7954) дозволяє розробникам розгортати більші програми, підвищуючи максимальний ліміт розміру контракту з приблизно 24 КіБ до 32 КіБ.
• Детерміноване попереднє розгортання фабрики (або EIP-7997) запроваджує універсальний, вбудований фабричний контракт. Він дозволяє розробникам розгортати свої програми та гаманці смарт-контрактів за однією й тією ж адресою на всіх ланцюгах EVM, що беруть участь у процесі.
• Якщо ваш застосунок покладається на складне відстеження для пошуку переказів ETH, то перекази та спалювання ETH генерують журнал (або EIP-7708), що дозволить вам перейти до використання журналів для більш простого та надійного обліку.
• Збільшення вартості газу для створення стану (або EIP-8037) та оновлення вартості газу для доступу до стану (або EIP-8038) запроваджують нові моделі сталого розвитку, які змінять певні витрати на розгортання контрактів, оскільки створення нових облікових записів або постійного сховища матиме динамічно регульовану плату.

Як Glamsterdam вплине на сховище вузлів і апаратні вимоги?

Кілька пропозицій щодо вдосконалення протоколу Ethereum (EIP), які розглядаються для Glamsterdam, стосуються проблеми продуктивності, що виникає зі зростанням мережі:

• Збільшення вартості газу для створення стану (або EIP-8037) запроваджує динамічну модель ціноутворення, щоб досягти темпів зростання бази даних стану на 100 ГіБ/рік, забезпечуючи ефективну роботу мережі на стандартному фізичному обладнанні.
• eth/70 часткові списки квитанцій про отримання блоків (або EIP-7975) дозволяють вузлам запитувати квитанції про отримання блоків посторінково, що розбиває списки квитанцій про отримання блоків, які містять багато даних, на менші фрагменти, щоб запобігти збоям і синхронізації в міру масштабування Ethereum.