Un borrador de Ethereum propone compartir el trabajo de verificación de pruebas por lotes sin fusionar los pagos ni las firmas de las transacciones individuales. La iniciativa sigue en etapa de revisión y todavía depende de mediciones de rendimiento.
***

• El diseño permitiría que un patrocinador cubra el costo de las hojas de prueba, mientras cada transacción paga por sus propias reclamaciones.
• Los constructores podrían incluir subconjuntos válidos del lote sin solicitar nuevas firmas a sus miembros.
• Las tarifas y los límites son provisionales: el borrador no tiene número de EIP ni fecha de activación en la red principal.

Ethereum estudia pagos compartidos para verificar pruebas por lotes

Un borrador presentado por el colaborador de Ethereum Marchhill propone combinar la verificación de pruebas con pagos patrocinados para procesar lotes de reclamaciones. El diseño permitiría compartir una prueba entre varias transacciones, pero mantendría separados sus pagos, firmas, nonces y recibos, de acuerdo con la descripción publicada por crypto.news.

Según ese reporte, la presentación llegó al repositorio de propuestas de Ethereum el 13 de noviembre y continúa como un pull request en borrador, no como una actualización aprobada de la red. Aún no tiene un número de EIP asignado ni una fecha de activación en la mainnet, y sus tarifas y límites de recursos requieren calibración y mediciones antes de que pueda evaluarse su puesta en marcha.

El lote compartiría la prueba, no las obligaciones de cada transacción

El mecanismo central separa el pago por la verificación compartida de los costos asociados a las reclamaciones individuales. Un patrocinador cubriría cada hoja de lote retenida, es decir, un componente de prueba que reúne varias reclamaciones, mientras que las transacciones miembros pagarían según las reclamaciones que presentan.

La separación busca que el constructor de un bloque pueda escoger cualquier subconjunto válido de miembros sin pedirles que vuelvan a firmar. Si una transacción está lista para incluirse y otras del lote original quedan fuera, el diseño permitiría conservar la primera sin exigir una firma nueva por el cambio en la composición del grupo.

El borrador también mantendría los nonces y recibos vinculados a cada transacción individual, en lugar de reemplazarlos por un registro común del lote. El nonce identifica el lugar de una operación en la secuencia de una cuenta, mientras que el recibo conserva el resultado de su ejecución; compartir el trabajo criptográfico no eliminaría esos elementos separados.

La comprobación de que las reclamaciones son válidas y la confirmación de que los pagos requeridos acompañan al lote aparecen como tareas distintas. Las pruebas recursivas autenticarían las fuentes utilizadas y la correspondencia de pagos se revisaría durante la finalización, según el borrador; por ello, la validez de una reclamación no bastaría por sí sola para demostrar que se cubrieron los costos asociados.

La propuesta amplía el camino previsto por EIP-8288

El borrador de Marchhill se apoya en EIP-8288, escrito por Vitalik Buterin y Thomas Coratger, que plantea incorporar firmas criptográficas y pruebas fuera del proceso de ejecución principal de Ethereum. En ese esquema, las transacciones identifican qué declaraciones deben verificarse y un STARK recursivo demuestra su validez a nivel de bloque.

Un STARK permite demostrar que un cálculo se realizó correctamente sin pedir a cada verificador que repita todo el cálculo. La recursión, por su parte, permite que una prueba verifique otras pruebas y reúna sus resultados, lo que sustenta la posibilidad de agrupar la verificación sin convertir las transacciones subyacentes en una sola operación.

EIP-8288 reserva actualmente el esquema genérico leanSTARK, en vez de permitir su uso en marcos de dependencias. La presentación de Marchhill propone habilitar esa vía y sustituir la declaración simple de hash de datos del borrador base por un resumen estable que represente una lista de reclamaciones.

La iniciativa integra en una misma propuesta la verificación genérica, la identidad de las pruebas, los límites de recursos, los resúmenes de dependencias y los pagos por lotes. También reemplaza una presentación anterior, el pull request número 12654, aunque todavía falta asignarle un número EIP y abrir un hilo de discusión dedicado.

Las tarifas y los límites siguen sujetos a calibración

La revisión enumera un costo provisional de 15.400 gas para la verificación nativa y de 572.000 gas para la verificación genérica ordinaria. También asigna 5.100 gas a la parte intrínseca de la prueba, 675.000 gas al pago de una hoja y 4.200 gas a una reclamación de lote.

El cargo separado por hoja responde, según el borrador, al trabajo fijo adicional que requieren los pagos vinculantes frente a la verificación ordinaria. Las reclamaciones y los pagos no añadirían una parte intrínseca de prueba, pero las cifras todavía necesitan calibración conjunta y no constituyen una tarifa definitiva ni prueban que los usuarios obtendrían un ahorro.

Entre los controles de recursos figura un límite provisional de 16.384 dependencias distintas por bloque, aplicado independientemente del gas, junto con una regla de encaje correspondiente para las listas de inclusión. El diseño también plantea que cada hoja contenga hasta 256 reclamaciones y que cada paso de prueba tenga 16 entradas; esas cifras no son límites para todo el bloque.

El tratamiento de las transacciones también dependería de cómo se construye el lote. Las reclamaciones con descuento y los pagos de patrocinadores irían directamente a los constructores de bloques, mientras que las pruebas ordinarias que cubren una sola declaración podrían seguir entrando al mempool público, donde las transacciones esperan su inclusión en un bloque.

La activación dependería de pruebas de rendimiento

Antes de activar el mecanismo, el borrador exige medir el calendario completo de procesamiento, la reparación tardía de patrocinadores y los costos de prueba que caben dentro de los límites de gas de las transacciones, incluida la sobrecarga requerida. La propuesta pide registrar tanto la evidencia obtenida como las brechas de rendimiento que sigan abiertas.

El material de referencia distingue resultados medidos en nodos individuales y en una sola máquina para bloques de las cifras modeladas con 16 trabajadores. Esa diferencia importa porque una estimación de varios trabajadores no equivale a un resultado observado en las condiciones de procesamiento que la propuesta exige evaluar.

El borrador también reconoce un riesgo para la construcción de bloques: si un patrocinio queda invalidado, el constructor podría perder el trabajo que dedicó a preparar el lote. El gas de inclusión no reembolsaría ese esfuerzo, de modo que la propuesta plantea medir ese escenario como parte de la evaluación y no lo presenta como un costo ya resuelto.

La construcción concreta de compromisos y las codificaciones permanecerían en la especificación del sistema de pruebas fijado, y la iniciativa no introduce nuevos mensajes de red. En conjunto, el diseño describe una forma de compartir la verificación mientras conserva registros y pagos individuales, pero su adopción sigue pendiente de revisión, calibración y evidencia de rendimiento suficiente.

ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín