Refine Validator Registration Approval section#116
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
| 3. verifies the `deposit_root` matches current Beacon Chain state and commits to it by signing its approval message; | ||
| 4. uploads the encrypted exit shares to IPFS and includes the IPFS hash in the approval message it signs, so the location of the shares becomes part of the on-chain record. | ||
|
|
||
| Once enough Oracles have signed, the Operator Service submits the bundled signatures to the Vault contract. The [Keeper contract ↗](https://etherscan.io/address/0x6B5815467da09DaA7DC83Db21c9239d98Bb487b5#code) verifies the threshold (`validatorsMinOracles`, currently **6 of 11**) and confirms the current `deposit_root` still matches the one the Oracles signed. The last check protects against the [front-running withdrawal credentials attack ↗](https://blog.lido.fi/vulnerability-response-update/). Finally, the Vault forwards the deposit to the Beacon Chain Deposit Contract, and the validator is queued for activation. |
There was a problem hiding this comment.
validator is queued for activation.
Be careful with 'queued' word. There is pending_queued validator status which means validator is in beacon chain activation queue. But when deposit is congested by Beacon chain it does not immediately create validator. It is put into pending deposits queue. Validator does not yet exist at this point. Currently deposits queue processing takes ~50 days.
| 3. verifies the `deposit_root` matches current Beacon Chain state and commits to it by signing its approval message; | ||
| 4. uploads the encrypted exit shares to IPFS and includes the IPFS hash in the approval message it signs, so the location of the shares becomes part of the on-chain record. | ||
|
|
||
| Once enough Oracles have signed, the Operator Service submits the bundled signatures to the Vault contract. The [Keeper contract ↗](https://etherscan.io/address/0x6B5815467da09DaA7DC83Db21c9239d98Bb487b5#code) verifies the threshold (`validatorsMinOracles`, currently **6 of 11**) and confirms the current `deposit_root` still matches the one the Oracles signed. The last check protects against the [front-running withdrawal credentials attack ↗](https://blog.lido.fi/vulnerability-response-update/). Finally, the Vault forwards the deposit to the Beacon Chain Deposit Contract, and the validator is queued for activation. |
There was a problem hiding this comment.
This is done to maintain the protocol's ability to exit validators on demand
This statement was lost.
deposit_root check exists to ensure we predicted validator index correctly. Validator index is a part of exit message. Index is NOT provided by beacon chain at this point. So we could only guess.
Deposit root check ensures that deposit contract state did not change since the moment we created exit signature.
| ::: | ||
| Each Oracle then independently: | ||
|
|
||
| 1. re-derives the Vault's withdrawal credentials from the Vault address and verifies the deposit signature against those credentials; |
There was a problem hiding this comment.
i would say Oracle rebuilds deposit message. Not just withdrawal creds
class DepositMessage(Serializable):
fields = [
('pubkey', bytes48),
('withdrawal_credentials', bytes32),
('amount', uint64),
]
There was a problem hiding this comment.
Deposit signature is built upon deposit message.
|
|
||
| The recheck guards two things. The pre-signed exit signature is bound to a specific validator index the Operator Service predicted at registration — a new deposit would shift that index and invalidate the signature. The recheck also protects from the [front-running withdrawal credentials attack ↗](https://blog.lido.fi/vulnerability-response-update/), where a malicious operator races their own deposit ahead of the Vault's. | ||
|
|
||
| Once everything passes, the Vault forwards the deposit to the Beacon Chain [Deposit Contract ↗](https://etherscan.io/address/0x00000000219ab540356cbb839cbe05303d7705fa#code). The deposit enters the Beacon Chain's [deposit queue ↗](https://beaconcha.in/validators/queues) before the validator is queued for activation. Processing time depends on network congestion. |
There was a problem hiding this comment.
before the validator is queued for activation
Validator is pending_initialized when created, then pending_queued, then ...
i would remove this part (about validator) if we dont want to dive into validator lifecycle.
There was a problem hiding this comment.
maybe say that validator is created once pending deposit is processed
| 1. re-derives the Vault's withdrawal credentials from the Vault address and verifies the deposit signature against those credentials; | ||
| 2. decrypts its own exit-signature share and verifies it is a valid BLS signature against the corresponding public-key shard; | ||
| 3. verifies the `deposit_root` matches current Beacon Chain state and commits to it by signing its approval message; | ||
| 4. includes the IPFS hash of the encrypted exit shares in the approval message it signs. The shares are uploaded to IPFS. This is done to maintain the protocol's ability to exit validators on demand. |
There was a problem hiding this comment.
if you want clarity about signing process, then maybe describe approval message to sign
'KeeperValidators': [
{'name': 'validatorsRegistryRoot', 'type': 'bytes32'},
{'name': 'vault', 'type': 'address'},
{'name': 'validators', 'type': 'bytes'},
{'name': 'exitSignaturesIpfsHash', 'type': 'string'},
{'name': 'deadline', 'type': 'uint256'},
],
| Oracles approve validator registration requests before the Vault contract forwards the deposit to the Beacon Chain [Deposit Contract ↗](https://etherscan.io/address/0x00000000219ab540356cbb839cbe05303d7705fa#code). | ||
|
|
||
| This process ensures Oracles approve validators based on current Beacon Chain state, bridging the consensus and execution layers while preventing stale approvals and replay attacks. | ||
| The Operator Service monitors the Vault and, once enough ETH has accumulated (32 ETH per validator), prepares a registration and sends an **approval request** to all 11 Oracles. The request carries all the information each Oracle needs to verify the registration trustlessly, including the encrypted exit signature shares that let the protocol exit the validators on demand. |
There was a problem hiding this comment.
32 ETH per validator
Since Pectra fork the things have changed. Upper bound 32 eth was removed. So all staked amount likely will go to register single validator.
Maybe rephrase "per validator" to
at least 32 ETH
2 participants
No description provided.