¿Cuál es el pilar de la seguridad de Ethereum? ¿Los nodos, su ejecución o las atestaciones?
Antes de continuar, los invitamos a leer un artículo previo sobre el Proof of Stake “PoS - De Full Node a Validator Node”, donde encontrarán una clara explicación sobre el proceso de una transacción realizada por nodo validador.
El mecanismo de Proof of Stake es parte del consenso de la red, permitiendo a los validadores acordar la veracidad de las transacciones y la creación de nuevos bloques en la cadena.
Más allá del Proof of Stake, existen otros aspectos del consenso que no abordaremos en detalle aquí, aunque es crucial entender que PoS ofrece resistencia a ataques Sybil, no siendo exactamente un protocolo de consenso. Los protocolos de consenso son LLMD Ghost y Casper FFG, que juntos formaron “Gasper”.
Siguiendo, el consenso en Ethereum se lleva a cabo por el algoritmo, Gasper. que detalla el funcionamiento de los incentivos en la red, cómo se añaden nuevos bloques a la cadena, y cómo los nodos determinan la cadena canónica (la cadena con mayor cantidad de bloques). Este algoritmo también establece los intervalos temporales para eventos en la cadena dividiendo el tiempo en "slots" de 12 segundos y epochs de 32 slots, y cómo un validador asume el rol de proponedor de bloques.
En este artículo, nos enfocaremos específicamente en el papel del cliente validador, encargado de avalar el bloque actual en el bloque header de la cadena y los bloques “checkpoints”, que marcan el último bloque al inicio de la época.
Para entender el punto de vista del validador, tenemos que entender qué significa atestar.
Atestar es la acción que llevan a cabo los validadores de un comité, en cada slot, para confirmar que un bloque es válido y puede ser incorporado a la cadena. Cada atestación se emite por un slot específico y se propone por época. Su objetivo es respaldar el punto de vista del validador. ¿Qué implica esto? Significa que el validador confirma que el estado de la cadena refleja la misma información que el bloque verificado, y la atestación permite que otros validadores voten a favor o en contra de esta percepción, apoyando así el punto de vista del validador. Al lograr un consenso entre los demás validadores, se confirma el bloque propuesto.
Las atestaciones de cada validador individual se recopilan inicialmente dentro de subredes, antes de su propagación más amplia, debido a la carga que supone compartir esta información. Por ello, cada atestación incluye datos de consenso, su firma y la de otros validadores que coinciden con la información. El "agregador", un validador seleccionado de cada subred en cada época, recolecta atestaciones con datos de la “gossip network” y luego difunde la atestación agregada (attestation aggregate) a una red más amplia. Posteriormente, estas atestaciones son recopiladas por el “creador de bloques" (block proposer) en cada slot, formando un "paquete" de datos.
Una agregación está compuesta de la siguiente forma:
El validador que atesta primero debe construir la data con la información detallada anteriormente, una vez que la data es construida el validador puede cambiar el index del bit de “aggregation_bits” correspondiente a su validador para demostrar que han participado en el voto.
Finalmente el validador firma la atestación y la propaga a la red.
Los validadores tienen un máximo de una época para asumir su atestación. Si la pierden en la época 0, pueden subirla con inclusión delay en la época 1.
Validadores random se suscriben a dos subredes como backup en caso de que se pierda alguno de los 16 agregadores que hay por época en total.
Si el productor de bloques se pierde, el siguiente productor será quien elija la atestación agregada y la incluya en el siguiente bloque. Esto provocara que la inclusion delay aumente 1 punto.
Los validadores son recompensados por sus atestaciones, con la cantidad de recompensa variando según las banderas de participación (source, target, head), la base de recompensa y la tasa de participación.
Cada bandera de participación puede ser verdadera o falsa, dependiendo de la presentación en la atestación y el retraso de inclusión. El escenario ideal es cuando las tres banderas son verdaderas.
Inclusion Delay: Es el lapso entre el momento esperado de la atestación y cuando efectivamente se incluye en la cadena.
Si el bloque header de la cadena es el “bloque n”, y la atestación es incluida en el “bloque n+1” por lo que la inclusión es 1 en su mayoría de veces. Si por alguna razón, la tardanza se duplica, la recompensa será menor.
Esto es particularmente relevante para los nodos validadores en Latinoamérica, donde la escasez de nodos puede incrementar el retraso de inclusión (inclusion delay) y, por ende, disminuir las recompensas. Esta es una de las razones por las cuales es importante contar con más nodos validadores en LATAM, ya que con más nodos se puede mejorar la comunicación entre los mismos alrededor del mundo y reducir la inclusión delay.
Así como hay posibilidades de ganar, también existen riesgos de perder. Un validador puede ser penalizado, o "slasheado", perdiendo una parte de su participación económica si realiza atestaciones contradictorias.
BLS (Boneh-Lynn-Shacham) es una firma digital utilizada para firmar las transacciones de los usuarios.
El proceso de esta firma está compuesto por 4 piezas de información:
Algo importante de este proceso es que el mensaje, su firma y una llave pública permiten que verifiques el validador que firmó el mensaje ya que la llave pública deriva de la llave privada por lo que nadie más podría haber firmado ese mensaje.
En la cadena Beacon, los únicos mensajes que son firmados son “hash tree roots” de objetos llamados “signing roots”
(Un validador aplica su llave secreta a un mensaje que genera una firma digital única)
Para verificar una firma necesitamos conocer la llave pública del validador que la firmó. Cada validador tiene su llave pública guardada en el estado de la beacon chain y puede ser fácilmente consultada con el índice del validador.
La verificación de firmas puede ser tratada como una caja negra: enviamos el mensaje, la llave pública y la firma del verificador, luego de magia criptográfica las firmas coinciden con la llave pública y el mensaje por lo que lo declaramos válido. Si esto no sucede, la firma está corrompida, la llave secreta fue errónea o el mensaje no fue lo que se firmó;
La verificación volverá como válida sólo si la firma corresponde a la llave pública y al mensaje, si no volverá como falso.
A continuación podemos encontrar una representación de todo el proceso:
Penalidades
Los validadores reciben recompensas por su contribución a la seguridad de la cadena y enfrentan penalizaciones por acciones que van en contra de esta. Aunque estas sanciones suelen ser moderadas, cumplen con el propósito de incentivar a que los validadores mantengan un desempeño óptimo en sus operaciones.
Estas penalizaciones se descuentan de los saldos de los validadores en la beacon chain y se eliminan de la circulación, contribuyendo así a la reducción de la emisión total de la cadena.
Importante: Las penalidades no son lo mismo que el slashing
El rango para que un validador mantenga un equilibrio entre ganancias y penalizaciones es aproximadamente del 43%.
El Slashing se aplica a acciones que violan reglas críticas del protocolo, potencialmente amenazando la seguridad de la cadena. La expulsión implica la pérdida significativa de participación y la exclusión del protocolo, representando más un castigo severo que una simple penalización. Los validadores pueden evitar la expulsión tomando medidas preventivas básicas.
Las acciones que pueden llevar a la expulsión incluyen:
Estas infracciones están relacionadas con la "equivocación", es decir, cuando un validador emite información contradictoria a lo previamente anunciado a la red.
Al igual que con las penalizaciones menores, los fondos retirados de los validadores por expulsión son eliminados de la circulación, afectando la emisión total de la cadena de balizas.
Finalmente, al analizar el rol de los validadores en el mecanismo de consenso y las atestaciones podemos darnos cuenta de que son fundamentales para mantener la seguridad y la integridad de la red de Ethereum.
Las atestaciones no sólo facilitan la verificación y validación de los bloques dentro de la cadena, si no que también sostienen el consenso alrededor del estado actual de la red, reforzando su resistencia contra ataques y manipulaciones.
Las sanciones y penalizaciones, terminan siendo cruciales para incentivar a los validadores a mantener un alto nivel de rendimiento y compromiso. Es importante destacar la distinción entre ambas acciones para que exista una diferencia entre quien comete un error o corre su nodo validador en un estado de bajas condiciones (mal internet, alta inclusión delay, cortes de luz, etc.). No es lo mismo tener una conducta responsable en un “mal ambiente” que una gran negligencia por sobre cómo debemos actuar con nuestro nodo.
La efectividad de PoS y la seguridad de Ethereum dependen en gran medida de la precisión, puntualidad y honestidad (por sobre todo) de las atestaciones producidas por los validadores.
A través de un sistema de incentivos, la red puede asegurar que sus participantes actúen de manera que promueva el bienestar de la comunidad y el ecosistema.