El colaborador de Ethereum Marchhill ha presentado una propuesta preliminar para habilitar la verificación genérica de pruebas y el procesamiento por lotes patrocinado, permitiendo que múltiples reclamaciones de transacciones compartan una prueba mientras conservan pagos y firmas separados.
Resumen
- Los patrocinadores podrían pagar por pruebas por lotes mientras las transacciones de los miembros pagan por sus reclamaciones individuales.
- Los subconjuntos válidos podrían entrar en un bloque sin requerir que los miembros firmen sus transacciones nuevamente.
- Las tarifas propuestas y los límites de recursos siguen siendo provisionales, con activación dependiente de mediciones de rendimiento.
- La presentación es una solicitud de extracción preliminar, sin número EIP asignado ni fecha de activación en la red principal.
La propuesta de Marchhill, presentada al repositorio de EIP de Ethereum el 13 de noviembre, activaría el LEANSTARK_SCHEME reservado en la EIP-8288 e introduciría reglas para lotes patrocinados. La presentación sigue en desarrollo y no ha sido adoptada como una actualización de la red Ethereum.
El borrador reúne la verificación genérica, la identidad de pruebas, los límites de recursos, los resúmenes de dependencias y los pagos por lotes en una sola propuesta. Reemplaza una presentación anterior, la solicitud de extracción n.º 12654, mientras que aún quedan por asignar un número EIP y un hilo de discusión dedicado.
Las pruebas por lotes de Ethereum separarían los pagos del patrocinador y de los miembros
En el centro del borrador hay un acuerdo de pago en el que un patrocinador cubre cada hoja de lote retenida, un componente de prueba individual que contiene varias reclamaciones. Las transacciones de los miembros pagarían según sus propias reclamaciones presentadas.
Un constructor podría incluir cualquier subconjunto válido sin pedir a los miembros que firmen nuevamente. Por lo tanto, alguien cuya transacción estuviera lista para su inclusión no necesitaría una nueva firma únicamente porque otros miembros del grupo original quedaron fuera, según el mecanismo propuesto.
El borrador preservaría los nonces y recibos individuales de las transacciones. Un nonce identifica el lugar de una transacción en la secuencia de transacciones de una cuenta, mientras que un recibo registra su resultado de ejecución. Compartir el trabajo de prueba dejaría esos registros adjuntos a las transacciones separadas.
La coincidencia de pagos se verificaría durante la finalización, con pruebas recursivas que autenticarían las fuentes utilizadas en el lote. La presentación distingue el trabajo de establecer que las reclamaciones son válidas del trabajo de confirmar que los pagos necesarios las acompañan.
Las reclamaciones con descuento y los pagos de patrocinadores irían directamente a los constructores de bloques. Las pruebas ordinarias que cubren una sola declaración seguirían siendo elegibles para el mempool público, donde las transacciones esperan ser incluidas en bloques.
La verificación genérica se basa en la EIP-8288
La EIP-8288 subyacente, escrita por Vitalik Buterin y Thomas Coratger, propone agregar firmas criptográficas y pruebas fuera del proceso de ejecución principal de Ethereum. Las transacciones identificarían las declaraciones que necesitan verificar, y un STARK recursivo establecería su validez a nivel de bloque.
Los STARK son pruebas criptográficas que demuestran que un cálculo se realizó correctamente sin requerir que cada verificador lo repita. La recursión permite que una prueba verifique otras pruebas, combinando sus resultados.
Actualmente, la EIP-8288 reserva el esquema genérico leanSTARK en lugar de permitir su uso en marcos de dependencia. La presentación de Marchhill propone habilitar esa vía y reemplazar la declaración de hash de datos simple del borrador base con un resumen estable que represente una lista de reclamaciones.
El diseño sigue una discusión anterior sobre verificación criptográfica, incluido el apoyo de Buterin para manejar criptografía compleja mediante pruebas agregadas. Sus comentarios concernían a la arquitectura subyacente; el borrador de Marchhill establece un acuerdo específico de verificación y pago.
Los cargos propuestos siguen sujetos a calibración
La revisión proporcionada enumera cargos provisionales de 15.400 gas para verificación nativa y 572.000 gas para verificación genérica ordinaria. Asigna 5.100 gas a la parte intrínseca de la prueba, 675.000 gas a un pago de hoja y 4.200 gas a una reclamación por lote.
Los pagos de hojas conllevan un cargo separado porque los pagos vinculantes añaden trabajo fijo más allá de la verificación ordinaria, explica el borrador. Las reclamaciones y los pagos no incurrirían en una parte intrínseca adicional de la prueba. Las cifras requieren calibración conjunta, por lo que no establecen un calendario de tarifas final ni un ahorro confirmado para los usuarios.
Los controles de recursos incluyen un límite provisional de bloque de 16.384 dependencias distintas, aplicado de forma independiente del gas, junto con una regla correspondiente de ajuste a la lista de inclusión. Una hoja podría contener hasta 256 afirmaciones, mientras que un paso de prueba podría tener 16 entradas. Ninguna de las dos cifras es un límite para todo el bloque.
La activación requeriría mediciones de rendimiento de bloque completo
Antes de la activación, la propuesta requiere mediciones que abarquen el cronograma de procesamiento completo, la reparación tardía del patrocinador y los cargos por prueba que se ajusten a los límites de gas de transacción, incluida la sobrecarga requerida.
Su material de referencia distingue los resultados de bloque medidos para nodo individual y máquina única de las cifras modeladas para 16 trabajadores. El borrador requiere que la evidencia y las brechas de rendimiento restantes se registren en su material de referencia.
Un patrocinio invalidado podría desperdiciar el trabajo de un constructor, y la presentación afirma que el gas de inclusión no reembolsaría ese trabajo. La construcción concreta de compromisos y las codificaciones permanecen en la especificación del sistema de prueba fijada. La propuesta no introduce nuevos mensajes de red.
