Glamsterdam оновлення: відповідь на розширення L1 для Ethereum

Оригінал | Odaily Зірковий щоденник jk

Незабаром Ethereum чекає оновлення Glamsterdam, яке є найбільшою зміною на рівні протоколу з моменту The Merge, на думку основних розробників. Назва походить від двох частин: частина оновлення виконавчого рівня зберігає назву "Amsterdam", взяту з місця проведення попередніх Devconnect у Амстердамі; частина оновлення рівня консенсусу названа "Gloas", на честь зірки. Після попереднього оновлення Fusaka, Glamsterdam просуває розширення L1 шляхом реорганізації способу обробки транзакцій та управління зростаючою базою даних, кардинально оновлюючи спосіб створення та верифікації блоків в Ethereum.

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

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

Дві ключові пропозиції оновлення стосуються рівня консенсусу та виконавчого рівня:

Є дві основні пропозиції. Джерело: Ethereum

Основна пропозиція 1: ePBS, перетворення "зовнішніх посередників" на "вбудовані правила"

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

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

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

Основна пропозиція 2: BALs, спочатку складіть "список покупок"

Тепер про основну пропозицію на виконавчому рівні, список доступу на рівні блоку, скорочено BALs (EIP-7928).

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

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

Супутні пропозиції: перерахунок "займань"

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

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

Дата запуску основної мережі: наразі ще не визначена

Щодо графіка, Glamsterdam наразі перебуває на досить делікатному етапі. Офіційно остання перевірена зустріч основних розробників виконавчого рівня (ACDE) відбулася 241 раз 16 липня, основні питання включали останні звіти про прогрес етапу Glamsterdam Devnet та вибір основних пропозицій для наступного оновлення Hegota. Раніше широко цитований графік показував, що етап Devnet пройшов вісім ітерацій з 0 до 7, з 28 березня 2026 року по 8 липня, після чого заплановане розгалуження тестової мережі Sepolia на 3 серпня 2026 року, а розгалуження тестової мережі Hoodi на 17 серпня 2026 року, цільова дата активації основної мережі — 16 вересня 2026 року.

Спочатку графік був на першу половину 2026 року, джерело: Ethereum

Але з останніми новинами, цей графік, ймовірно, вже затримується. Команда EthPandaOps нещодавно запустила нову тестову мережу під назвою Plataberget, яка є першою короткостроковою публічною тестовою мережею, спеціально розробленою для Glamsterdam, а офіційні розгортання Sepolia та Hoodi, ймовірно, будуть відкладені до вересня, цільова дата запуску основної мережі також відповідно перенесена на четвертий квартал 2026 року. Це також є другим випадком зміни дати для Glamsterdam після попереднього перенесення з першої половини 2026 року. Основні розробники неодноразово підкреслювали, що правильність оновлення є важливішою, ніж дотримання будь-якої конкретної дати, тому до моменту, коли на офіційній зустрічі ACD буде зафіксовано конкретну висоту блоку, можливо, нам доведеться дочекатися четвертого кварталу або навіть кінця року, щоб побачити це оновлення.

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