Estructura de Ethernodes.io
Introducción
Ethernodes es una solución custodial para staking de Ethereum en su V1, y en formato de Revenue Sharing en su V2. Probablemente, si has repasado la documentación de Ethernodes, te preguntarás por qué la plataforma no se construye como una solución "non-custodial".
"Non-custodial" hace referencia a una plataforma que recibe fondos en SmartContracts, sin que la plataforma pueda actuar sobre ellos y teniendo el cliente/usuario el control sobre los fondos depositados en todo momento.
"Custodial" hace referencia a una plataforma que recibe los depósitos de sus usuarios/clientes y es responsable de mantener los mismos seguros.
Cada modelo tiene sus ventajas e inconvenientes, dependiendo de las necesidades del usuario/cliente que haga uso de la plataforma, el modelo de negocio, etc.
Ethernodes es una plataforma custodial principalmente por tres motivos:
Centralizar los depósitos nos permite elegir la mejor opción para hacer staking de Ethereum en cada momento para aportar mayor rentabilidad a nuestros clientes. Una derivada fundamental de esto, es que tenemos capacidad de negociación con diferentes proyectos del ecosistema para comprometer volúmenes que nos den acceso a acuerdos muy beneficiosos para nuestros cliente y, por supuesto, para nosotros.
La eficiencia en la distribución, gestión y generación de rentabilidad es mucho mayor en una plataforma que centraliza los fondos. De alguna manera, no hemos de preocuparnos de los compromisos en volumen en base a las preferencias de nuestros clientes, en tanto que nosotros actuamos directamente por el bien de éstos.
¡No sería posible crear un modelo de Revenue Sharing sin una plataforma centralizada! Y, no nos engañemos, las rentabilidades de un modelo de este tipo... son mucho mayores a las que puede generar un modelo simple de staking.
Está claro que este tipo de infraestructura requiere de un grado enorme de confianza del clientes en Ethernodes. Es por ellos que la información relativa a los fondos gestionados es pública y trazable en todo momento.
Hecha esta pequeña intro, ¡Al lio! Ethernodes gestiona validadores haciendo uso de una estructura muy robusta, en la que existen varios nodos operativos... que dan soporte tanto a volumen en validación "tradicional" así como mediante el uso de la tecnología DVT (Distributed Validator Technology). Recuerda que aquí explicábamos los motivos. A continuación te mostramos el esquema de distribución en nodos que tenemos.
Ethernodes trabaja con un modelo de variedad de clientes de ejecución y consenso muy resiliente y poco común en el mercado. Esto se traduce en una alta fiabilidad de nuestros validadores gestionados contra diferentes fallos. Aprende más aquí.
Infraestructura General
Este es el esquema de nuestra infraestructura híper-resiliente, pensada tanto para sacar el máximo provecho de la tecnología DVT como para evitar que exista un único punto de fallo en el sistema de validación.
Un único punto de fallo puede ser crítico en una estructura de validación de nodos de Ethereum. Si falla uno de los componentes, hemos de poder asegurar que existirá siempre un back-up que cubrirá este fallo.
Nodos, clientes de ejecución y clientes ligeros
Con esta estructura, haciendo uso de DVT y de Nodos de back-up suficientes:
Cualquier fallo en cualquier cliente (ejecución o consenso), permite al cluster seguir validando, firmando y creando bloques, con independencia de la activación del nodo de back-up
Cualquier fallo en uno de los nodo, permite al cluster seguir validando, firmando y creando bloques, con independencia de la activación del nodo de back-up
Cualquier fallo en un cliente ligero de SSV, permite al cluster seguir validando, firmando y creando bloques.
El fallo crítico simultáneo de varios clientes (ejecución o consenso) o de varios nodos, implicaría derivar todo el volumen a uno de los nodos activos, manteniendo la performance un un máximo de ~30 minutos, ya que siempre hay 5 nodos activos, pudiendo cualquiera de ellos recibir todo el volumen. ¡Es como tener 4 nodos de back-up 100% disponibles!
Uno de los riesgos más importantes en el proceso de validación es la doble firma. Se produce cuando se activan dos validadores simultáneamente en dos infraestructuras diferentes. Para combatir este riesgo, además de todos los controles que hacemos siempre que debemos mover validadores, tenemos un pequeño truco: doppleganger. Es un pequeño trozo de software que monitoriza nuestros validadores y, en caso de que en algún momento considere que existan dos activos simultáneamente... deja de firmar attestations has comprobar que todo funcione correctamente. ¡Una capa de seguridad más anti-slashing!
Monitorización
Un aspecto fundamental de todo este proceso es la capacidad para monitorizar la performance de los validadores que se gestionan desde Ethernodes. Para ello, contamos con un Nodo especialmente instalado únicamente para consumir datos on-chain y poder tener un Dashboard adecuado a nuestras necesidades. ¿Qué aspectos medimos?
Attestations La función que más realiza un validador son las "attestations", proceso por el cual el validador firma conforme da por válido el nuevo bloque incluido en la red. Es un proceso que se da cada ~minutos aproximadamente. Fallar una attestation es algo normal. Fallar dos seguidas es indicativo de que puede existir un fallo en alguna parte de la infraestructura.
Proponer un bloque Es algo menos común, pero más importante, ya que los rewards obtenidos por este proceso son mayores... ¡Y es cuando se activa el MEV! Sucede cuando la red solicita a tu validador incorporar un nuevo bloque en la red.
Participación en Sync Commities Es un evento muy poco común. Son bloques de 256 validadores seleccionados cada 27h que se ocupan de certificar que la red está correctamente actualizada. La probabilidad de participar en uno de ellos es más bien baja pero cuando sucede, se reciben una buena cantidad de rewards.
Nodos con problemas de conectividad La infraestructura de Ethernodes tiene muchos componentes, que son necesarios monitorizar por si mismos: cada uno de los nodos, de los clientes ligeros, de los clientes de ejecución y consenso, así como los relayers que utilizamos para el MEV. No son pocas cosas, y todas tienen que funcionar como un reloj suizo.
Generación diaria y MEV extraído Es una métrica más bien vinculada al negocio pero igual de importante. De media, se espera obtener un mínimo de rewards por consenso diario y una media estimada por ejecución, en base al número de validadores que manejas. Revisar que los parámetros de generación cuadran es sano para no perder de vista posibles impactos en el negocio.
No ha sido una lectura ligera... ¡Descansa un poco por hoy!
Last updated
