Ethernodes.io structure
Last updated
Last updated
Ethernodes is a custodial solution for Ethereum staking in its V1, and in Revenue Share format in its V2. Probably, if you've gone through the Ethernodes documentation, you'll wonder why the platform isn't built as a "non-custodial" solution.
"Non-custodial" refers to a platform that receives funds in SmartContracts, without the platform being able to act on them and with the client/user having control over the funds deposited at all times.
"Custodial" refers to a platform that receives deposits from its users/customers and is responsible for maintaining the same.
Each model has its advantages and disadvantages, depending on the needs of the user/client who uses the platform, the business model, etc.
Ethernodes is a custodial platform mainly for three reasons:
Centralizing deposits allows us to choose the best option for staking Ethereum at all times to provide greater profitability to our clients. A fundamental derivative of this is that we have the capacity to negotiate with different projects in the ecosystem to commit volumes that give us access to very beneficial agreements for our clients and, of course, for us.
Efficiency in distribution, management and generation of profitability is much greater on a platform that centralizes funds. In some ways, we don't have to worry about making volume commitments based on our clients' preferences, as we act directly for their good.
It would not be possible to create a Revenue Share model without a centralized platform! And, let's not fool ourselves, the returns from a model of this type... are much higher than what a simple staking model can generate.
It is clear that this type of infrastructure requires an enormous degree of customer trust in Ethernodes. It is because of them that the information related to the managed funds is public and traceable at all times.
Once this little intro is done, get busy! Ethernodes manages validators using a very robust structure, in which there are several operational nodes... that support both volume in "traditional" validation as well as through the use of DVT (Distributed Validator Technology) technology. Remember that here we explained the reasons. Below we show you the distribution scheme in nodes that we have.
Ethernodes works with a very resilient and uncommon execution and consensus client variety model in the market. This translates into high reliability of our managed validators against different failures. Learn more here.
This is the outline of our hyper-resilient infrastructure, designed both to get the most out of DVT technology and to avoid a single point of failure in the validation system.
A single point of failure can be critical in an Ethereum node validation structure. If one of the components fails, we must be able to ensure that there will always be a backup that will cover this failure.
With this structure, making use of sufficient DVT and back-up Nodes:
Any failure in any client (execution or consensus) allows the cluster to continue validating, signing and creating blocks, regardless of the activation of the back-up node.
Any failure in one of the nodes allows the cluster to continue validating, signing and creating blocks, regardless of the activation of the back-up node.
Any failure in an SSV thin client allows the cluster to continue validating, signing and creating blocks.
The simultaneous critical failure of several clients (execution or consensus) or of several nodes would imply diverting the entire volume to one of the active nodes, maintaining performance for a maximum of ~30 minutes, since there are always 5 active nodes, and any one can from them receive the entire volume. It's like having 4 backup nodes 100% available!
One of the most important risks in the validation process is double signature. Occurs when two validators are activated simultaneously on two different infrastructures.
To combat this risk, in addition to all the checks we do whenever we have to move validators, we have a little trick: doppleganger. It is a small piece of software that monitors our validators and, in case at any time it considers that two assets exist simultaneously... stop signing attestations and check that everything is working correctly. One more anti-slashing security layer!
A fundamental aspect of this entire process is the ability to monitor the performance of the validators that are managed from Ethernodes. To do this, we have a Node specially installed solely to consume on-chain data and be able to have a Dashboard appropriate to our needs. What aspects do we measure?
Attestations The function that a validator performs the most is "attestations", a process by which the validator signs as valid the new block included in the network. It is a process that occurs approximately every ~minute. Failing an attestation is normal. Failing two in a row is indicative that there may be a failure somewhere in the infrastructure.
Propose a block It is something less common, but more important, since the rewards obtained by this process are greater... And that is when the MEV is activated! It happens when the network requests your validator to add a new block to the network.
Sync Commitie partocipation It is a very rare event. They are blocks of 256 validators selected every 27 hours that are responsible for certifying that the network is correctly updated. The probability of participating in one of them is rather low but when it happens, you receive a good amount of rewards.
Nodes with connectivity problems The Ethernodes infrastructure has many components, which need to be monitored on their own: each of the nodes, the light clients, the execution and consensus clients, as well as the relayers that we use for the MEV. There are many things, and they all have to work like a Swiss watch.
Daily generation and extracted MEV It is a metric more linked to the business but just as important. On average, it is expected to obtain a minimum of rewards per daily consensus and an estimated average per execution, based on the number of validators you manage. Checking that the generation parameters fit is healthy so as not to lose sight of possible impacts on the business.
Other performance metrics In addition to all of the above, our dashboards alert us to many other performance metrics of our hardware, runaways of our clusters, or even if the monitoring systems themselves stop reporting data.
It wasn't light reading... Get some rest for today!
