Evaluación de EigenLayer
Esta página es un registro de decisiones vivo. Su propósito es explicar qué podría hacer EigenLayer por OrcaRail, dónde no ayuda y cuándo construiríamos sobre él.
Recomendación actual
Aplazar.
Motivo: el planificador de NestJS + Chainlink Automation (o Gelato) nos da redundancia doble para SubscriptionHub.charge(). La mejora marginal de fiabilidad o de descentralización de un Keeper AVS todavía no compensa los meses de ingeniería ni la coordinación continua con operadores.
Qué es EigenLayer (con precisión)
EigenLayer es un protocolo de restaking en Ethereum. Los validadores que protegen Ethereum pueden optar por aportar seguridad económica adicional a redes secundarias llamadas AVS (Actively Validated Services).
Lo que aporta un AVS: un cálculo off-chain (una «tarea»), un comité de operadores que da fe del resultado, verificación on-chain de esas atestaciones y slashing para los resultados demostrablemente erróneos.
Lo que EigenLayer no es:
- Una cadena.
- Una plataforma de smart contracts.
- Una solución de custodia.
- Un sustituto de las auditorías, el diseño de contratos o la disciplina operativa.
Dónde podría encajar un AVS en OrcaRail
1. Keeper AVS (charge() descentralizado)
Idea: los operadores vigilan SubscriptionHub, envían charge(ids[]) cuando toca y dan fe on-chain de que lo hicieron a tiempo. Saltarse un cobro vencido es penalizable con slashing.
Ventajas:
- Disponibilidad descentralizada. Ninguna parte (OrcaRail) es imprescindible para que funcionen las suscripciones.
- Corrección penalizable con slashing cuando no se cumplen los SLO.
Inconvenientes:
- Ingeniería: construir un AVS (definición de tareas, condición de slashing, cliente de operador, agregador) o adaptar una plantilla existente. Meses en ambos casos.
- Operación: reclutar y dar soporte a operadores (o pagar a un servicio que lo haga).
- Beneficio marginal: nuestro par actual Chainlink + NestJS ya tiene redundancia doble.
¿Lo construiríamos? Solo si se da algún motivo (ver abajo).
2. AVS de atestación de puentes
Idea: sustituir el puente de confianza de Relay por un AVS que dé fe de «fondos observados en la cadena X; liberar en la cadena Y» con seguridad penalizable.
Ventajas:
- Liquidación entre cadenas sin confiar en un único operador de puente.
- Encaja bien con los marcos de mensajería al estilo ISM existentes (Hyperlane, Omni).
Inconvenientes:
- Relay ya nos funciona bien con los volúmenes actuales.
- Un puente respaldado por un AVS es una apuesta mayor que un Keeper AVS: o lo construimos nosotros o dependemos de una red emergente.
¿Lo construiríamos? Solo si Relay deja de ser viable o un socio ofrece una ruta respaldada por un AVS ya hecha.
3. Oráculo de políticas / cumplimiento
Idea: un AVS da fe de hechos que guían decisiones de política on-chain: pertenencia a listas de sanciones, confirmaciones de entrega, señales de fraude.
Ventajas:
- Saca las comprobaciones de políticas de los servidores centralizados.
Inconvenientes:
- De nicho. Solo es útil si OrcaRail asume una responsabilidad explícita de políticas on-chain.
¿Lo construiríamos? No, a corto plazo no.
Motivos que cambiarían la recomendación
Revisaremos esta recomendación cada trimestre. Cualquiera de estos motivos abriría un documento de diseño para el AVS correspondiente:
- Una conversación comercial bloqueada explícitamente por el riesgo de un «keeper de una sola parte» que no podamos mitigar de otro modo.
- Un marco regulatorio que cite la disponibilidad o la atestación respaldadas por un AVS como control aceptable o preferido.
- Un deterioro relevante de la disponibilidad o el precio de Chainlink Automation en una cadena en la que procesemos un volumen significativo.
- Una alianza en la que podamos reutilizar el keeper o el AVS de puente de otro con un coste operativo casi nulo.
- Que OrcaRail crezca lo suficiente como para que «los raíles de pago deben sobrevivir a que OrcaRail esté caído» sea una expectativa razonable.
Si lo construimos
Restricciones de diseño que seguiríamos:
- Partir de plantillas. Othentic y la Eigen Foundation publican plantillas de AVS para redes de atestación de tareas. No implementaríamos el slashing a mano.
- Mantener el punto de entrada on-chain sin cambios.
SubscriptionHub.charge(ids[])sigue siendo pública y sin permisos. El AVS pasa a ser un llamador más junto a NestJS y Chainlink. - Sin token nuevo. Ningún token de staking de OrcaRail. A los operadores se les paga en ETH (o USDC) del presupuesto de gas de la plataforma.
- Sin nueva custodia. El AVS no guarda ni enruta fondos.
- Auditoría. Incluso los AVS basados en plantillas necesitan auditoría.
- Plan de retirada. Si Chainlink, Gelato y los keepers propios cubren la brecha de fiabilidad, deberíamos poder desmantelar el AVS.
Preguntas abiertas (en seguimiento; no bloqueantes)
- ¿Existe un grupo natural de operadores de AVS que ya gestione infraestructura relacionada con pagos (indexadores, keepers)?
- ¿Qué latencias de atestación son realistas para «vencido en el último minuto»?
- ¿Cuál es el tamaño mínimo del conjunto de operadores para un slashing creíble?
- ¿Cómo se integra la primitiva de slashing de la mainnet de Eigen con nuestra monitorización actual?
Historial de decisiones
| Fecha | Decisión | Notas |
|---|---|---|
| 2026-04-20 | Aplazar | La redundancia doble de Chainlink + NestJS es suficiente; se reevalúa cada trimestre. |
Las nuevas entradas se añaden aquí cuando cambia la decisión.