---
title: MaxEB
metaTitle: Пектра MaxEB
description: Дізнайтеся більше про MaxEB в оновленні Пектра
lang: uk
authors: ["Ніксо"]
---

*Коротко:* Хардфорк Пектра дозволяє валідаторам Етеріуму вибрати вищий максимальний ефективний баланс і компаундинг (нарахування складних відсотків), перетворивши облікові дані для виведення **Типу 1** на **Тип 2**. Офіційним інструментом для цього є Launchpad. Цю операцію неможливо скасувати.

## Огляд {#overview}

### Кого це стосується? {#who-is-affected}

Будь-кого, хто керує валідатором — ймовірно, це той, хто знає індекс (наприклад, [Валідатор #12345](https://beaconcha.in/validator/12345)) валідатора, який він контролює. Якщо ви використовуєте протокол для запуску валідатора (наприклад, Lido CSM або Rocket Pool), вам доведеться уточнити у них, чи підтримують вони maxEB і коли саме.

Якщо ви здійснюєте стейкінг за допомогою токена ліквідного стейкінгу (наприклад, rETH або stETH), жодних дій не вимагається і не рекомендується.

### Що таке «maxEB»? {#what-is-maxeb}

maxEB = МАКСимальний ефективний баланс (MAXimum Effective Balance) валідатора. До хардфорку Пектра кожен валідатор заробляє максимум на 32 ETH. Після Пектра валідатори мають можливість заробляти на будь-якому балансі від 32 до 2048 ETH з кроком в 1 ETH, погодившись на цю зміну.

### Як валідатору погодитися на зміни? {#how-does-a-validator-opt-in}

Валідатор погоджується на зміну maxEB шляхом перетворення облікових даних для виведення **Типу 1** на **Тип 2**. Це можна зробити на [Launchpad (Дії валідатора)](https://launchpad.ethereum.org/validator-actions) після активації хардфорку Пектра. Як і у випадку з **Типом 0** → **Типом 1**, перетворення з **Типу 1** → **Тип 2** є незворотним процесом.

### Що таке облікові дані для виведення? {#whats-a-withdrawal-credential}

Коли ви запускаєте валідатор, у вас є набір облікових даних для виведення. Їх можна знайти у вашому json-файлі даних депозиту або переглянути на [вкладці депозитів](https://beaconcha.in/validator/12345#deposits) вашого валідатора на beaconcha.in.

1. Облікові дані для виведення **Типу 0**: Якщо облікові дані для виведення вашого валідатора починаються з `0x00...`, ви внесли депозит до хардфорку Шапелла і ще не встановили адресу для виведення.

![Type 0 withdrawal credential](./0x00-wd.png)

2. Облікові дані для виведення **Типу 1**: Якщо облікові дані для виведення вашого валідатора починаються з `0x01...`, ви внесли депозит після хардфорку Шапелла або вже перетворили свої облікові дані **Типу 0** на облікові дані **Типу 1**.

 ![Type 1 withdrawal credential](./0x01-wd.png)

3. Облікові дані для виведення **Типу 2**: Цей новий тип облікових даних для виведення починатиметься з `0x02...` і буде активований після Пектра. Валідатори з обліковими даними для виведення **Типу 2** іноді називають «**компонуючими валідаторами**» (compounding validators).

| **Дозволено** | **Не дозволено** |
| --- | --- |
| ✅ Тип 0 → Тип 1 | ❌ Тип 0 → Тип 2 |
| ✅ Тип 1 → Тип 2 | ❌ Тип 1 → Тип 0 |
|  | ❌ Тип 2 → Тип 1 |
|  | ❌ Тип 2 → Тип 0 |

### Ризики {#risks}

MaxEB дозволяє валідатору відправити весь свій баланс іншому валідатору. Користувачі, які подають запит на консолідацію, повинні перевірити джерело та вміст транзакції, яку вони підписують. Офіційним інструментом для використання функцій maxEB є Launchpad. Якщо ви все ж вирішите скористатися стороннім інструментом, вам слід переконатися, що:

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

Ми **наполегливо рекомендуємо** обговорити будь-який сторонній інструмент, який ви плануєте використовувати, зі [спільнотою EthStaker](https://ethstaker.org/about). Це корисне місце, щоб перевірити свій підхід на адекватність та уникнути помилок. Якщо ви скористаєтеся зловмисним або неправильно налаштованим інструментом, **весь баланс вашого валідатора може бути надісланий на валідатор, який ви не контролюєте**, — без можливості його повернути.

## Технічні деталі {#technical-details}

### Процес {#the-flow}

Буде два варіанти використання операції `ConsolidationRequest`:

1. Перетворення існуючого валідатора з **Типу 1** на валідатор **Типу 2**
2. Консолідація інших валідаторів в існуючий валідатор **Типу 2**

При перетворенні валідатора **Типу 1** на **Тип 2** як *джерелом* (source), так і *ціллю* (target) буде валідатор, який ви перетворюєте. Операція коштуватиме газ і буде поставлена в чергу за іншими запитами на консолідацію. Ця черга є **окремою** від черги депозитів, на неї не впливають нові депозити валідаторів, і її можна переглянути на [pectrified.com](https://pectrified.com/).

Щоб консолідувати валідатори, ви повинні мати *цільовий валідатор*, який має облікові дані для виведення **Типу 2**. Це місце призначення для будь-яких балансів валідаторів, що консолідуються, при цьому індекс зберігається.

### Вимоги для перетворення на Тип 2 {#requirements-for-converting-to-type-2}

Це буде потрібно для першого валідатора, який ви перетворюєте на **Тип 2**. Індекс цього валідатора зберігається і залишається активним. Для перетворення *вихідний валідатор* == *цільовий валідатор*.

Валідатор повинен...

- бути активним
- мати облікові дані для виведення **Типу 1**
- не перебувати у стані виходу (або підданим слешингу)
- не мати незавершених виведень, ініційованих вручну (не стосується автоматичних зборів)

![conversion illustration](./conversion.png)

### Вимоги для консолідації {#requirements-for-consolidating}

Це *та сама операція*, що й перетворення, але у випадку, коли *вихідний валідатор* відрізняється від *цільового валідатора*. Індекс цільового валідатора зберігається, і він приймає баланс від вихідного валідатора. Індекс вихідного валідатора переводиться у стан `EXITED`.

У цьому випадку вихідний валідатор має всі ті ж вимоги, що й вище, плюс:

- був активним щонайменше ~27,3 години (одна `SHARD_COMMITTEE_PERIOD`)

Цільовий валідатор повинен

- мати облікові дані для виведення **Типу 2**
- не перебувати у стані виходу.

![consolidation illustration](./consolidation.png)

### Запит на консолідацію {#the-consolidation-request}

Запит на консолідацію буде підписаний адресою для виведення, пов'язаною з вихідним валідатором, і міститиме:

1. Адресу вихідного валідатора (наприклад, `0x15F4B914A0cCd14333D850ff311d6DafbFbAa32b`)
2. Відкритий ключ вихідного валідатора (наприклад, `0xa1d1ad0714035353258038e964ae9675dc0252ee22cea896825c01458e1807bfad2f9969338798548d9858a571f7425c`)
3. Відкритий ключ цільового валідатора

При перетворенні пункти 2 і 3 будуть однаковими. Цю операцію можна виконати на [Launchpad](https://launchpad.ethereum.org/).

### Вимоги до підписання {#signing-requirements}

Щоб надіслати `ConsolidationRequest`, **адреса для виведення вихідного валідатора** повинна підписати запит. Це підтверджує контроль над коштами валідатора.

### Що підписується? {#what-is-signed}

Використовується розділений за доменами [корінь підписання](https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/beacon-chain.md#compute_signing_root) об'єкта `ConsolidationRequest`.

- **Домен:** `DOMAIN_CONSOLIDATION_REQUEST`
- **Поля кореня підписання:**
  - `source_pubkey`: `BLSPubkey`
  - `target_pubkey`: `BLSPubkey`
  - `source_address`: `ExecutionAddress`

Отриманий **BLS-підпис** надсилається разом із запитом.

Примітка: Підписання здійснюється адресою для виведення, а не ключем валідатора.

### Часткові виведення {#partial-withdrawals}

Валідатори з обліковими даними **Типу 1** отримують автоматичні безкоштовні (без витрат газу) збори свого надлишкового балансу (все, що перевищує 32 ETH) на свою адресу для виведення. Оскільки **Тип 2** дозволяє валідатору накопичувати баланси з кроком в 1 ETH, він не буде автоматично збирати баланси, доки не досягне 2048 ETH. Часткові виведення на валідаторах **Типу 2** повинні ініціюватися вручну і коштуватимуть газ.

## Інструменти для консолідації {#consolidation-tooling}

Існує кілька інструментів для управління консолідаціями. Офіційним інструментом, створеним Фундацією Ethereum, є [Launchpad](https://launchpad.ethereum.org/en/validator-actions). Існують також сторонні інструменти, створені учасниками спільноти стейкінгу, які можуть пропонувати функції, не передбачені в Launchpad. Хоча наведені тут інструменти не перевірені та не схвалені Фундацією Ethereum, нижче представлені інструменти з відкритим вихідним кодом від відомих членів спільноти.

| Інструмент | Вебсайт | Відкритий вихідний код | Творець | Пройшов аудит | Інтерфейс | Визначні функції |
| --- | --- | --- | --- | --- | --- | --- |
| Pectra Staking Manager | pectrastaking.com | Так, Apache 2.0 | [Pier Two](https://piertwo.com/) | Ні | Вебінтерфейс | WalletConnect, працює з SAFE |
| Pectra Validator Ops CLI Tool | [GitHub](https://github.com/Luganodes/Pectra-Batch-Contract) | Так, MIT | [Luganodes](https://www.luganodes.com/) | Так, Quantstamp [Травень 2025](https://certificate.quantstamp.com/full/luganodes-pectra-batch-contract/23f0765f-969a-4798-9edd-188d276c4a2b/index.html) | Командний рядок | Пакетування, для багатьох валідаторів одночасно |
| Ethereal | [GitHub](https://github.com/wealdtech/ethereal) | Так, Apache 2.0 | [Jim McDonald](https://www.attestant.io/team/) | Ні | Командний рядок | Повний набір функцій для управління валідатором та вузлом |
| Siren | [GitHub](https://github.com/sigp/siren) | Так, Apache 2.0 | [Sigma Prime](https://sigmaprime.io/) | Ні | Частково командний рядок, але переважно вебінтерфейс | Працює лише якщо ви використовуєте клієнт консенсусу Лайтхаус |
| Consolideth.app | https://consolideth.app/ [GitHub](https://github.com/Stakely/consolideth) | Так, ліцензії MIT | [Stakely](https://stakely.io/) | Ні | Вебінтерфейс, розміщений на stakely і готовий до вільного самостійного хостингу | Підтримує основні підключення гаманців, включаючи safe з WalletConnect |

## Часті запитання {#faq}

Ні. Згода не зменшує ваші шанси на пропозицію — ваші обов'язки та вибір для пропозиції залишаються незмінними. Наприклад, якщо у вас є два валідатори по 32 ETH порівняно з одним валідатором на 64 ETH, ви матимете однакові загальні шанси бути обраним для пропозиції блоку та отримання винагород.
### Чи змінить згода мій ризик слешингу? {#change-slashing-risk}

Для невеликих або непрофесійних операторів коротка відповідь — ні. Більш розгорнута відповідь полягає в тому, що для професійних операторів, які запускають багато валідаторів на вузол зі швидким сповіщенням, консолідація в меншу кількість валідаторів може знизити їхню здатність реагувати на слешинг і запобігати каскадним подіям. Початковий *штраф* за слешинг для всіх валідаторів був значно зменшений з 1 ETH (на 32 ETH) до 0,0078125 ETH (на 32 ETH), щоб компенсувати цей ризик.

### Чи потрібно мені здійснювати вихід мого валідатора для перетворення? {#exit-validator}

Ні. Ви можете здійснити перетворення на місці без виходу.

### Скільки часу займе перетворення / консолідація? {#how-long}

Мінімум 27,3 години, але консолідації також підлягають черзі. Ця черга не залежить від черг депозитів і виведень і не піддається їхньому впливу.

### Чи можу я зберегти свій індекс валідатора? {#keep-validator-index}

Так. Перетворення на місці зберігає той самий індекс валідатора. Якщо ви консолідуєте кілька валідаторів, ви зможете зберегти лише індекс *цільового валідатора*.

### Чи пропущу я атестації? {#miss-attestations}

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

### Чи будуть на мене накладені штрафи? {#incur-penalties}

Ні. Поки ваш валідатор перебуває в мережі, штрафи не накладатимуться.

### Чи повинні збігатися адреси для виведення валідаторів, що консолідуються? {#withdrawal-addresses-match}

Ні. Але *джерело* повинно авторизувати запит зі своєї власної адреси.

### Чи будуть мої винагороди накопичуватися (компаундуватися) після перетворення? {#rewards-compound}

Так. З обліковими даними **Типу 2** винагороди понад 32 ETH автоматично рестейкаються — але не миттєво. Через невеликий буфер (який називається [*гістерезисом*](https://eth2book.info/capella/part2/incentives/balances/#hysteresis)), ваш баланс повинен досягти **приблизно на 1,25 ETH більше**, перш ніж надлишок буде рестейкнуто. Тому замість компаундингу на рівні 33,0 ETH, це відбувається на рівні 33,25 (ефективний баланс = 33 ETH), потім 34,25 (ефективний баланс = 34 ETH) і так далі.

### Чи можу я все ще отримувати автоматичні збори після перетворення? {#automatic-sweep}

Автоматичні збори відбуватимуться лише з надлишковими балансами понад 2048. Для всіх інших часткових виведень вам доведеться ініціювати їх вручну.

### Чи можу я передумати і повернутися з Типу 2 до Типу 1? {#go-back-to-type1}

Ні. Перетворення на **Тип 2** є незворотним.

### Якщо я хочу консолідувати кілька валідаторів, чи потрібно мені спочатку перетворити кожен з них на Тип 2? {#consolidate-multiple-validators}

Ні! Перетворіть один валідатор на Тип 2, а потім використовуйте його як ціль. Усі інші валідатори, консолідовані в цю ціль Типу 2, можуть бути Типу 1 або Типу 2.

### Мій валідатор не в мережі або має менше 32 ETH — чи можу я все одно його перетворити? {#offline-or-below-32eth}

Так. Поки він активний (не здійснив вихід) і ви можете підписати за допомогою його адреси для виведення, ви можете його перетворити.

## Ресурси {#resources}

- [Специфікації консенсусу Electra](https://github.com/ethereum/consensus-specs/blob/master/specs/electra/beacon-chain.md): Це «найправдивіша» версія, на яку вам слід покладатися. Якщо сумніваєтеся, читайте специфікації.
- Не всім зручно розбиратися в коді, тому [цей maxEB-GPT](https://chatgpt.com/g/g-67f1650fb48081918f555e0c8d1c2ae9-maxeb-gpt) може допомогти інтерпретувати специфікації. *Відмова від відповідальності: Слід покладатися на специфікації, а не на ШІ, як на істину, оскільки ШІ може неправильно інтерпретувати інформацію або галюцинувати відповіді.*
- [pectrified.com](https://pectrified.com/): Переглядайте стан консолідацій, депозитів та час очікування в черзі.
- [Ethereal](https://github.com/wealdtech/ethereal): Створений спільнотою інструмент командного рядка (CLI) для управління типовими завданнями валідатора.
- [batch-validator-depositor](https://github.com/attestantio/batch-validator-depositor): Створений спільнотою контракт, який дозволяє вносити депозити для кількох валідаторів Етеріуму в одній транзакції.