# Presentation

### 1. Hey hey!

Hello everyone, thanks for coming! I am Kirill Minenko, I work on Tooling at Lido.

Today I wanna talk about the tooling for Node Operators version 2.

### 2. v2 tooling scope

* First I will tell you about scope of changes **pause**
* Then I will mention our schedule **pause**
* And then will go through technical stuff, and it's ok if you don't get it at first, it took quite a long time for me to understand technical details.

And feel free to ask questions at the end.
**pause**

So let's start...

### 3. v2 tooling scope - brand new tooling

The first scope is **Withdrawals**, and as you know, it is the next big thing for Ethereum and we should be prepared.
**pause**
The second scope is a Staking router, it is basically the load balancer for stake. If you want to know more about Staking Router
you can watch previous Node Operators call recording.

So, Withdrawals and Staking router are the brand new tooling. Yay!

### 4. Schedule

Sometimes we all have a deadline that seems impossible to hit, but it's a deadline and it's unmovable. Our schedule is, the same.
**pause**
We have a Gorli Testnet in Mid March.
And Mainnet launch somewhere in Early April.
So, timeline, as you can see on the picture, is quite tight.

And the next slide.

### 5. Brand New Tooling

**pause**
As you know It's important to use the right tools to do the job right, so what we have here.
**pause**
We have two new tools (it's Key Api and Ejector).
And two pretty big updates - Oracle v2 and DSM
(which stands for Deposit Security Module)

Let's talk first about K-API.

### 6. Key api - works now along with oracle, ejector and dsm

**pause**
Key API is here to serve information about keys, validators and other data for Tooling services like Ejector, Oracle v2 and DSM.
It periodically grabs the snapshot of data from Execution and Consensus nodes and keeps this snapshot nearby.
**pause**
It's worth mentioning that KAPI Consensus node connectivity is optional and can be disabled if it's not needed.
KAPI in this case will serve only keys information.
**pause**

### 7. Key api - goals and tech

You know, getting all the state from Ethereum Nodes can take a while, and moreover in case of using third-party services it can cost a penny.
Key API helps us with that -- since blockchain data is fetched from ethereum nodes, it is stored in KAPI to be quickly served via REST API interface.
And key API is also designed to support Staking Router and Staking Modules.
**pause**

### 8. Key api - monitoring
Monitoring is crucial for K-API.

It is not good if KAPI suddenly stops receiving new state from Ethereum nodes, because it will stop other services connected to it.

Therefore it is pretty critical part of the whole system and right monitoring is necessary.

Good news there are grafana dashboards carefully handcrafted for you in Github repo and you can take them, use them and improve them if you want.
**pause**
Aand next thing.

### 9. Ejector

The Ejector.

### 10. Ejector - motivation.

Let's talk how Node Operators should manage validator exits.
**pause**
Node Operator should constantly monitor specific event, called ValidatorExit event, emitted by the Oracle, and respond to it.

Respond by MANUALLY making voluntary exit call to Consensus Node with a specially prepared exit message for that validator.
Sounds pretty easy, however, this event can be triggered anytime 24 hours a day 7 days a week.

And Ejector is here to make Node Operators's life easier.

Node Operator just loads a small batch of presigned exit messages into Ejector and that's it!

Then if user wants to withdwraw and buffer is empty -
protocol will emit event and it will be handled by the Ejector.
Super simple!

### 11. Ejector - tech details

There are some technical details here,
Ejector will need Execution and Consensus nodes and a bunch of presigned exit messages.

Presigned messages can be created with public and private keys of validators with tools like E-T-H Do.

Public keys of the oldest validators from KAPI.

### 12. Ejector - flow

So, to summarize the flow, Node Operators should:
1 - Prepare batch of presigned messages
2 - Push this batch to Ejector
3 - Restart Ejector
4 - Wait until presigned messages will be used by Ejector
5 - And then just repeat everything from the beginning.

### 13. Ejector - compatible

Ejector can be loaded with presigned messages coming from various tools and support messages that are compatible with Generic Message Format and E-T-H Do message format.

And also you can build your own automatization to keep Ejector working.

### 14. Ejector - monitoring

Right monitoring is also important for Ejector.

Because if Node Operator delays validator ejection, protocol will handle it and ask OTHER node operator to eject a one of it's validators instead of delayed validator.
**pause**
Good news grafana dashboard is included in Github repo, and you can use it.

### 15. Oracle v2 - main

Here you can see our oracles.

First of all I want to say that the oracle v2 update
is important only for Node Operators that run current oracles.
If you don't run Oracle you can skip this update.

**pause**

Current oracle reports only protocol TVL, **pause**
V2 Oracle brings TVL, handles withdrawals and reports exited and stucked validators.
Plus new oracle supports Staking Router and designed to be extensible.

Actually new oracle is not just one - there are two different oracles - small Exit Bus Oracle and big Acounting Oracle.
They are bundled in separate applications and can be deployed separately.

**pause**

To handle withdrawals and new features of Staking Router
oracle's onchain reports got a lot bigger.
Bigger means more gas for each report and each oracle instance.
And that is not good. =(

To spend less on reporting and to be extensible, we use multiple techniques. I am going to tell you more about them.

**pause**

### 16. Oracle v2 - hash consensus

The first technique is a hash consensus, the idea is simple - oracles now agree on hash of the data instead of sending large data onchain. This is the first gas economy strategy.

### 17. Oracle v2 - reporting

The second technique is a multi-phase reporting.
Current oracle's sends full report in one transaction, and latest report costs even more gas,

while v2 oracle will send multiple transactions splitting big last report into chunks.

Of course this multi-phase report will only be made after hash consensus is reached, to keep all the needed data onchain.

### 18. Oracle v2 - fast lane

The third technique is, what we call "fast lane".

Each oracle has it's own number, and they have some kind of ordering.
**pause**
On each report
all oracles are split into two groups - "fast lane" group
and group of remaining oracles.

In a good weather only "fast-lane" group actually do their reports,
the rest of oracles do nothing, thus saving gas on transactions.

Each report "fast-lane" group is shifted to the right by 1, so the oracles are rotated, and oracles order is checked onchain.
This makes participation more predictable and equal.

**pause**
Let's talk about our small oracle.

### 19. Oracle v2 - Validator Exit Bus

Couple words here.

Exit bus oracle makes a decision what validator should be ejected,
based on deterministic algoritm and emits the ValidatorExitRequest transaction onchain. The event in it is immediately handled by the Ejector, and he knows what to do with it.
**pause**

### 20. Oracle v2 - Archive node

Good news v2 oracles spend less gas on consensus, bad news they
now require Archive Execution node, which is bigger.

Correct calculation of protocol TVL after withdrawals era is only possible when looking at historic data, and only Archive node can provide it.
**pause**
There are different execution clients with different capabilities and options regarding archive data pruning, oracles will need up to 7 days of historic data. Everything older can be safely removed.

Nodes compatible with history pruning are Erigon, Besu and Nethermind.

So, you don't need to store whole history,
because it's quite huge.

### 21. Oracle v2 - Gas economy

Summing up...

* previously every oracle paid a lot, and the last one even more because of report finalization.

* now everyone pays less

* and the participation is made more predictable and equal

**pause**

### 22. DSM update

Few words about Deposit Security Module update -

New version is designed to support Staking Router and can individually pause each Staking Module independently.
That's all the updates for DSM.

### 23. Node operators care.

That's all about the tools.
As you can see a lot of things changed, a lot of things left to be deploed and schedule is tight.

There will be READMEs, manuals and docker-composes, what to do's in testnet and in what order.

Plus there will be a team of DevOps rangers who can help you with some technical issues.

### 24. Fin

That's all from tooling team for today!

Thanks for coming! Now, questions time!