El borrador EIP-8390 de Ethereum plantea eliminar el "sync committee" y recortar en unos 33.800 ETH la emisión anual

Una propuesta recién incorporada al repositorio oficial de EIPs de Ethereum plantea retirar el "sync committee" de 512 validadores, suprimir sus recompensas y dejar obsoleta la interfaz de cliente ligero de Altair, sustituyéndola por pruebas de conocimiento cero offchain. El borrador EIP-8390 estima que, al eliminar el peso de recompensas del comité, la emisión anual de consenso se reduciría en torno a 33.800 ETH. La propuesta entró en el repositorio a las 02:04 UTC del 24 de agosto en estado Draft, por lo que se trata de un diseño para debate y no de una actualización adoptada. No incluye época de activación ni compromiso en la hoja de ruta de Ethereum, y deja la planificación en manos de los equipos de clientes. En la actualización inicial del hilo del autor no se mencionaron revisiones externas. El "sync committee" es una muestra de 512 validadores cuyas firmas permiten a los clientes ligeros seguir la beacon chain de forma compacta sin procesar el conjunto completo de validadores. EIP-8390 propone eliminar ese mecanismo en protocolo antes de detallar un servicio de pruebas, una interfaz de migración y un soporte económico para el reemplazo. Menos emisión, con cambios en el equilibrio de seguridad La fórmula de recompensas de consenso asigna al "sync committee" un peso de 2 sobre un denominador de 64. EIP-8390 retiraría ese peso sin redistribuirlo, lo que equivale a una reducción de 2/64 (1/32) en la emisión de consenso. Con una instantánea de 901.505 validadores y 42.328.615 ETH en staking, el borrador calcula una emisión anual de consenso de unos 1,082 millones de ETH; la parte eliminada sería aproximadamente 33.800 ETH al año. El recorte de 1/32 no implica una bajada automática del 3,125% en la rentabilidad total realizada por cada validador. Se aplica a la emisión de consenso destinada a recompensas del "sync committee", mientras que el rendimiento efectivo puede incluir otras recompensas de consenso e ingresos de la capa de ejecución. Altair no define una condición de "slashing" específica para un validador que firme un mensaje malicioso del "sync committee". EIP-7657, una propuesta separada que buscaba introducir esa penalización, figura ahora como Stagnant. En su momento advertía que las aplicaciones que aseguren más de 512 × 32 ETH (16.384 ETH) deberían combinar el protocolo de cliente ligero con protecciones adicionales. Aunque era una recomendación de diseño bajo el límite de 32 ETH de balance efectivo máximo, refleja la preocupación de fondo: las firmas muestreadas ayudan a los clientes ligeros a seguir Ethereum, pero los mensajes maliciosos del comité no conllevan su propia penalización en el protocolo. Eliminar la muestra cambiaría ese problema de responsabilidad por otra dependencia: los clientes ligeros pasarían a verificar una prueba de conocimiento cero de la finalidad Casper FFG sobre el conjunto completo de validadores. Esa prueba se convertiría en la señal de finalidad para clientes que no procesan el set completo. Impacto directo en los clientes ligeros de Altair EIP-8390 eliminaría las tareas de los validadores asociadas al comité, los mensajes de red, los contenedores de datos de cliente ligero y varios endpoints de la Beacon API. El texto señala que los clientes ligeros desplegados bajo Altair que sincronizan mediante LightClientUpdate dejarían de funcionar en el "fork". La categoría afectada incluye software que utiliza el flujo estándar de actualizaciones de Altair. Como ejemplos confirmados, se citan Helios (embebible en wallets y aplicaciones descentralizadas), que depende de un endpoint de consenso compatible con la Beacon API de cliente ligero; Lodestar, con un paquete de cliente ligero del lado del consumidor basado en esa ruta; Nimbus, que expone una interfaz de cliente ligero para los mismos objetos de actualización; y el cliente Ethereum IBC de Datachain, que construye cabeceras a partir de datos LightClientUpdate y FinalityUpdate obtenidos vía Beacon RPC. El impacto real dependería de si siguen usando las interfaces eliminadas y de las migraciones que publiquen sus mantenedores. El borrador suprime el flujo definido por la especificación actual de Altair sin aportar un contrato de Beacon API de reemplazo ni una especificación de migración para clientes. Pruebas ZK: promesas sin especificación ni incentivos EIP-8390 sostiene que la finalidad Casper FFG podría demostrarse en una época con una GPU y verificarse en milisegundos, pero no aporta una implementación reproducible, circuito, perfil de hardware o benchmark que respalde esa afirmación. Un diseño público comparable sobre el conjunto completo reporta preprocesado por debajo del minuto en una CPU de 64 núcleos sin aceleración GPU y sitúa partes de la composición final de la prueba como trabajo futuro o aún no construido. La propuesta tampoco define el servicio de generación de pruebas, su interfaz de cliente, el modelo de fiabilidad, los operadores ni la financiación. Además, declara explícitamente que no añade incentivos en protocolo para producir pruebas de finalidad y no propone ninguno, aunque podrían aparecer mecanismos offchain o financiación como bien público fuera del protocolo. Con los números del propio borrador, el ahorro de emisión es tangible, mientras que la disponibilidad del reemplazo, la ruta de migración y su economía quedan abiertas. Para avanzar hacia una activación harían falta una interfaz probada para clientes ligeros, migraciones funcionales para los consumidores actuales de Altair y una producción pública de pruebas que se mantenga disponible cuando los usuarios dependan de ella.