Al leer la documentación de Consensus & Security del Protocolo Newton, un detalle de implementación llamó inmediatamente mi atención: los operadores no empiezan a firmar con BLS tan pronto como llega una tarea. En su lugar, Newton inserta una etapa de consenso dedicada antes de la evaluación de la política.

Según la documentación, el proceso comienza con la fase de Preparación. Los operadores obtienen de forma independiente datos externos de la política y devuelven respuestas no firmadas al Gateway. En esta etapa, no se producen firmas BLS.

A continuación, el Gateway calcula valores medianos a partir de las respuestas recopiladas para los datos numéricos y los comprueba frente a la tolerancia configurada. Si el valor de un operador supera el umbral de tolerancia, el consenso falla con un error de ToleranceExceeded. La documentación indica específicamente que los operadores no se excluyen silenciosamente cuando sus valores están fuera del rango permitido.

Solo después de que se haya establecido un conjunto de datos común comienza la fase Commit. La Gateway retransmite a los operadores los datos canónicos de consenso. Como ahora cada operador evalúa la política usando entradas idénticas, puede generar firmas BLS sobre el mismo mensaje.

Este orden parece estar estrechamente relacionado con otro detalle de implementación documentado: el sistema de dos digestos de Newton. La documentación explica que la agregación BLS requiere que cada operador firme exactamente el mismo mensaje. Para cumplir este requisito, los operadores firman con BLS el Consensus Digest, mientras que el Full Digest, que contiene atestaciones únicas, se almacena en cadena para la verificación en la impugnación.

Vistas en conjunto, estas mecánicas forman un flujo de trabajo coherente. La fase Prepare alinea las entradas de los operadores. El proceso de consenso de la mediana establece un conjunto de datos canónico. La fase Commit realiza la evaluación de la política usando esos valores compartidos. Finalmente, la agregación de firmas BLS ocurre solo después de que los operadores estén trabajando con datos idénticos.

Otro detalle digno de mención es cómo maneja Newton el desacuerdo. En lugar de aceptar la mayoría mientras ignora los valores atípicos, la documentación establece que los valores que superan la tolerancia configurada hacen que el consenso falle. Esto hace que el parámetro de tolerancia forme parte del comportamiento de consenso del protocolo en vez de ser meramente una recomendación.

La documentación también conecta este proceso con la seguridad económica respaldada por EigenLayer. Los operadores participan mediante ETH re-restakeado (restaked), y las evaluaciones incorrectas pueden impugnarse durante la ventana de impugnación, lo que potencialmente puede resultar en slashing. Combinado con la agregación BLS, esto proporciona tanto verificación criptográfica como responsabilidad económica para las evaluaciones de políticas.

Desde una perspectiva de implementación, lo interesante no es simplemente que Newton use firmas BLS. La documentación muestra que la agregación BLS se coloca a propósito después de un proceso de consenso dedicado. Al garantizar que los operadores evalúen políticas a partir del mismo conjunto de datos canónico, Newton crea las condiciones necesarias para la verificación de firmas agregadas, manteniendo al mismo tiempo las reglas de tolerancia documentadas para los datos externos.

Pregunta técnica: A medida que los datos externos se vuelven más volátiles, ¿qué consideraciones deberían guiar los ajustes de la tolerancia de consenso para que el consenso siga siendo fiable sin aumentar innecesariamente las evaluaciones fallidas @NewtonProtocol #Newt $NEWT