Los próximos horquillas duras de Parse Ethereum: Pectra Updatead

introducir

En nuestro artículo anterior, revisamos el ciclo de vida del validador de Ethereum en detalle, discutiendo múltiples aspectos relacionados con la próxima bifurcación de electra.Ahora, es hora de centrarse en los cambios en las próximas actualizaciones de Electra y Praga y explicarlas en detalle.

La historia del Ethereum 2.0 «Prueba de estaca» es complicada.Comienza con la adición de una capa de baliza a la capa de ejecución existente, que mantiene la prueba de trabajo (Fase0 y Altair Hard Funcks) mientras la capa de baliza inicia el consenso de prueba de estaca.Posteriormente, POS se activa completamente en la bifurcación dura de Bellatrix (aunque la retirada no está habilitada).Luego, Capella Hard Fork permite retiros, completando el ciclo de vida del validador.Las horquillas duras recientes Deneb (parte de la actualización de Dencun (Deneb/Cancun)) han hecho revisiones menores a los parámetros de la cadena de balizas, como las ventanas de tiempo que contienen pruebas, manejo de salidas voluntarias y restricciones de reemplazo de validador.Los principales cambios en Dencun ocurren en la capa de ejecución, el lanzamiento de transacciones BLOB, el gas blob, las promesas de KZG para las blobs y el abandono de las operaciones de autodestrucción.

Ahora, la horquilla dura Praga/Electra (es decir, Pectra) introduce importantes actualizaciones de las capas de ejecución y consenso.Como auditores para el proyecto LIDO, nos centramos principalmente en el consenso y los cambios relacionados con la apuesta en esta horquilla dura.Sin embargo, no podemos ignorar los cambios de la capa de ejecución en Praga, ya que incluyen características importantes que afectan la red y los validadores de Ethereum.Cavemos en los detalles de estos cambios.

Una descripción general de nivel de Pectra

Electra presenta numerosas características en la capa de baliza.Las actualizaciones principales incluyen:

• Permite que el equilibrio válido del verificador varíe entre 32 y 2048 ETH (en lugar de un 32 ETH fijo).

• Permite que los verificadores inicien las salidas a través de cupones secundarios de «retiro» (ya no se requiere la clave del verificador activo).

• Cambie cómo la capa de baliza maneja los depósitos ETH1 (el evento ya no se analiza del contrato de depósito).

• Agregue un nuevo marco común para manejar solicitudes de contratos ETH1 regulares en la capa de baliza (similar a cómo se gestionan los depósitos previos a los electros).

Mientras tanto, Praga introdujo los siguientes cambios en la capa de ejecución:

• Un nuevo contrato precompilado que respalda la curva BLS12-381 para verificar la evidencia de Zksnark (a excepción de la popular curva BN254).

• Un nuevo contrato del sistema para almacenar y acceder hasta 8192 Hashes de bloques históricos (muy útil para clientes sin estado).

• Aumente los costos de gas de calldata para reducir el tamaño del bloque y alentar a los proyectos a migrar operaciones intensivas en datos de llamadas, como el encierro a las blobs introducidas en Dencun.

• Admite más blobs por bloque ETH1 y proporciona una API para leer estos números.

• Permitir que EOA (cuenta de propiedad externa) tenga su propio código de cuenta expande en gran medida lo que EOA puede hacer, como ejecutar multicalls o delegar la ejecución a otras direcciones.

Consulte la propuesta de mejora de Ethereum (EIP) relevante para una discusión adicional:

• EIP-7251: Se agregó Max_Effective_Balance

• EIP-7002: Salida de desencadenantes de la capa de ejecución

• EIP-6110: el depósito del verificador se proporciona en la cadena

• EIP-7549: Mueva el índice del comité de la prueba

• EIP-7685: Solicitud de capa de ejecución general

• EIP-2537: Precompilación de la operación de la curva BLS12-381

• EIP-2935: Guardar el hash de bloque histórico en el estado

• EIP-7623: aumentar el costo de los datos de llamada

• EIP-7691: aumenta el rendimiento de Blob

• EIP-7840: Agregar programación de blob al archivo de configuración de El

• EIP-7702: Configuración del código de cuenta EOA

Algunos de estos EIP implican principalmente la capa de consenso (Beacon), mientras que otros están relacionados con la capa de ejecución.Algunas abarcan dos capas, porque ciertas operaciones (como depósitos y retiros) requieren cambios sincrónicos entre el consenso y las capas de ejecución.Debido a esta interdependencia, no es práctico separar Electra y Praga, por lo que revisaremos cada EIP a su vez y especificaremos los componentes de Ethereum afectados en cada caso.

EIP-7251: Se agregó Max_Effective_Balance

Referencia: EIP-7251

Desde la primera bifurcación dura de la primera fase0, para preparar la prueba de estaca para Ethereum, el equilibrio máximo válido del verificador se ha fijado en 32 eth hasta el electra.Active los requisitos del verificador al menos Spec.min_Activation_balance (32 ETH).Después de la activación, el validador comienza con este equilibrio máximo válido, pero puede reducir su balance válido a Spec.Eyection_Balance (16 ETH) y ser desalojado cuando se alcanza este umbral.Esta lógica «mínima» permanece sin cambios en Electra, pero ahora SPEC.max_Effective_Balance se ha incrementado a 2048 ETH.Por lo tanto, el validador puede depositar entre 32 y 2048 ETH para activarse, todo lo cual contribuirá con su saldo válido.Este cambio marca el cambio de «32eth a prueba de estaca» a «prueba de estaca» 🙂

Este balance válido variable ahora se utilizará para:

• Aumentar la probabilidad de convertirse en un proponente de bloque, proporcional al equilibrio efectivo

• Aumentar la probabilidad de convertirse en miembro del comité sincrónico, proporcional al saldo efectivo

• Como base para calcular la cantidad de recortes relativos y sanciones inactivas

Las dos primeras actividades son las acciones más gratificantes para los validadores.Por lo tanto, después de Electra, los validadores de gran estancamiento participarán con mayor frecuencia en los comités de propuesta de bloque y sincronización, con frecuencia proporcional a su equilibrio efectivo.

Otro impacto tiene que ver con los recortes.Todos los cortes son proporcionales al equilibrio válido del verificador:

• Los recortes «inmediatos» y «retrasos» son aún mayores para los validadores de altas apuestas.

• Las multas recortadas «retrasadas» con validadores de corte con altas promesas también son mayores, ya que la porción de «corte» de la promesa total se hace más grande.

• Los denunciantes que informan validadores con saldos válidos más altos reciben una mayor proporción de apuestas reducidas.

Electra también propuso cambios a la relación de corte, definiendo una parte del saldo de validador cortado y recibiéndolo por el denunciante.

El siguiente es el impacto de la invalidez.Cuando el validador está fuera de línea cuando está activo (demuestre o proponga), se acumula la puntuación de invalidez, lo que resulta en la imposición de la penalización por invalidez para cada ciclo.Estas sanciones también tienen que ver con el saldo válido del validadorProporciónrelación.

Debido al aumento en el equilibrio válido, el «límite de reemplazo» del verificador también ha cambiado.En Ethereum «Antes de Electra», los validadores generalmente tienen el mismo equilibrio válido, y el límite de reemplazo de salida se define como «En un ciclo, no puede haber un máximo de 1/65536 (Spec.Churn_Limit_Quotient) Total Stake para salir». Crea un número «fijo» de salidas verificadoras con la misma estaca.Sin embargo, después de Electra, puede haber solo unas pocas salidas de «ballenas» porque representan una parte importante de la promesa total.

Otra consideración es la rotación de muchas teclas de verificador en una sola instancia de verificador.Actualmente grandes validadores se ven obligados a ejecutar miles de claves de validador en una instancia para acomodar una gran participación, dividiéndolas en 32 secciones ETH.Con Electra, este comportamiento ya no es obligatorio.Desde una perspectiva financiera, este cambio tiene poco impacto porque las recompensas y la probabilidad se escalan linealmente con la cantidad de compromiso.Por lo tanto, 100 validadores por 32 ETH son equivalentes a un 3200 ETH.Además, múltiples claves de verificador activo pueden tener la misma credencial de retiro ETH1, lo que permite que todas las recompensas se retiren a una sola dirección ETH, evitando los costos de gas asociados con las fusiones de recompensas.Sin embargo, la gestión de grandes cantidades de claves incurre en costos administrativos adicionales.

La capacidad de agregar saldos de validador agrega un nuevo tipo de solicitud de capa de ejecución.Antes, teníamos depósitos y retiros.Ahora, habrá otro tipo: solicitud agregada.Combina dos validadores en uno.Esta solicitud de operación incluirá la clave pública del verificador de origen y la clave pública de destino y se procesará de manera similar a los depósitos y retiros.Las agregaciones también tendrán solicitudes pendientes y restricciones de reemplazo de saldo, al igual que los depósitos y los retiros.

El resumen es el siguiente:

• Para pequeños validadores independientes, Electra introduce la capacidad de aumentar automáticamente su equilibrio efectivo (y recompensas).Anteriormente, cualquier excedente superior a 32 ETH solo podía retirarse, pero después de Electra, este excedente eventualmente contribuirá a su equilibrio efectivo.Sin embargo, el equilibrio efectivo solo puede aumentar en múltiplos de especificación.

• Para grandes validadores independientes, Electra proporciona una simplificación de gestión significativa al permitir que múltiples claves de validador activo se consoliden en una.Si bien esto no cambiará el juego, operar una participación 1×2048 es, sin duda, mucho más fácil que administrar 64×32 apuestas.

• Para los proveedores de replanteo móvil, que recopilan pequeñas rejas de los usuarios y asignan entre los validadores, Electra agrega más flexibilidad en el esquema de asignación de replanteación, pero también requiere contabilidad para los validadores basados ​​en 32 saldos válidos de ETH fijos realizan una refactorización severa.

Otro tema importante son los datos históricos y la estimación de ganancias de los validadores, especialmente relevantes para los nuevos participantes, que intentan evaluar los riesgos y las recompensas.Antes de Electra (a partir de este escrito), el 32 CAP ETH (tanto más pequeño o más grande, en realidad) creó uniformidad en datos históricos.Todos los validadores tienen el mismo saldo de validación, recompensas, sanciones de corte individual, frecuencia de propuestas de bloque y otras métricas.Esta uniformidad permite a Ethereum probar su mecanismo de consenso sin valores atípicos estadísticos, recopilando así valiosos datos de comportamiento de red.

Después de Electra, la distribución de la participación cambiará significativamente.Grandes validadores participarán en propuestas de bloques y comités de sincronización con mayor frecuencia, con mayores sanciones en los recortes y un mayor impacto en los recortes retrasados, las colas de activación y las colas de salida.Si bien esto puede crear un desafío en la agregación de datos, el consenso de Ethereum asegura que la computación no lineal sea mínima.El único componente no lineal usa SQRT (Total_Effective_Balance) para calcular la recompensa base, que se aplica a todos los validadores.Esto significa que las recompensas y los recortes de validador aún se pueden estimar en una base «por 1 ETH» (o más precisamente, basada en Spec.Effective_Balance_incement, que puede cambiar en el futuro).

Para obtener más detalles, consulte nuestro artículo anterior sobre el comportamiento de validador.

EIP-7002: salida de la capa de ejecución activable

Referencia: EIP-7002

Cada validador en Ethereum tiene dos pares de claves: una clave activa y una clave de retiro.Una clave pública BLS activa sirve como la identidad principal del verificador en la cadena de baliza, que se utiliza para firmar bloques, pruebas, recortes, sincronizar las agregaciones del comité y (antes de este EIP) la salida voluntaria (seguir un retraso iniciar el consenso del verificador. salida).El segundo par de claves («cupón de retiro») puede ser otro par de claves BLS o una cuenta ETH1 regular (clave privada y dirección).Ahora, los mensajes de retiro firmados por la clave privada BLS Active deben extraerse a la dirección ETH.Este EIP ha sido cambiado.

De hecho, los propietarios de estos dos pares de claves (activos y retirados) pueden ser diferentes.La clave activa del verificador es responsable de las responsabilidades de verificación: ejecutar el servidor, mantenerlo en funcionamiento normalmente, etc., y los cupones de retiro generalmente están controlados por el propietario de la estaca, que recibe recompensas y es responsable de los fondos.En la actualidad, solo el propietario de la compromiso que controla el cupón de retiro no puede iniciar la salida del verificador y solo puede retirar la recompensa.Esta situación permite al propietario de la clave activa del verificador mantener efectivamente el equilibrio del verificador como un «rehén» en su mano.El verificador puede «pre-firmar» el mensaje de salida y entregarlo a la parte interesada, pero esta solución no es ideal.Además, tanto la extracción como la salida actualmente requieren interacción con los validadores de la capa de baliza a través de una API dedicada.

La mejor solución es permitir que el propietario de la estaca realice operaciones de salida y retiro a través de llamadas regulares de contratos inteligentes.Esto implica la verificación de firma ETH1 estándar, que simplifica enormemente las operaciones.

Este EIP permite a las partes interesadas activar retiros y salidas enviando transacciones estándar a contratos inteligentes dedicados de su dirección ETH (similar al proceso de depósito existente utilizando contratos de «depósito»).El proceso de extraer (o salir cuando se elimina suficiente estaca) es el siguiente:

• El prometedor envía una solicitud de retiro («en» solicitud) al contrato de «retiro» del sistema.

• El contrato cobra tarifas específicas (en ETH) para mitigar los posibles ataques maliciosos, y de manera similar al EIP-1559, las tarifas aumentan cuando la cola de solicitud está ocupada.

• El contrato guarda la solicitud de retiro/salida «en» a su almacenamiento.

• Cuando se propone un bloque a la capa de baliza, la solicitud de retiro/salida «en» en la cola se recupera del almacenamiento.

• La capa de baliza procesa la solicitud «En», interactúa con el saldo del verificador activo, organiza el verificador para salir y forma una solicitud de retiro «fuera».

• La solicitud de retiro «fuera» se procesa en la capa de ejecución, y la parte interesada recibe su ETH.

Aunque los depósitos son operaciones activadas en el bloque ETH1 y luego se «trasladan» a la capa de baliza a través de la cola de depósito «pendiente», los retiros siguen diferentes esquemas.Se activan en la capa de baliza (a través de la CLI) y luego se «trasladan» al bloque ETH1.Ambos esquemas ahora operarán a través del mismo marco común (como se describe a continuación): cree una solicitud en la capa ETH1, procese las colas de depósito/retiro/fusión «pendiente» y procesela en la capa de baliza.Para operaciones de «salida» como retiro, la cola de salida también se procesará, y el resultado se «resolverá» en el bloque ETH1.

Con este EIP, los Stakers pueden usar transacciones ETH regulares para extraer y salir de sus validadores sin interactuar directamente con la CLI de validador o acceder a la infraestructura del validador.Esto simplifica enormemente las operaciones de replanteo, especialmente para grandes proveedores de replanteo.La infraestructura del verificador ahora puede estar casi completamente aislada porque solo se mantiene la clave del verificador activo, mientras que todas las operaciones de replanteación se pueden manejar en otro lugar.Elimina la necesidad de que los Stakers independientes esperen acciones activas de validador y simplifica significativamente la porción fuera de la cadena de los servicios LIDO como el módulo de apuestas comunitarias.

Por lo tanto, este EIP «completa» la operación de replanteo, migrándola por completo a la capa ETH1, reduciendo significativamente los riesgos de seguridad de la infraestructura y mejorando la descentralización de iniciativas de referencia independientes.

EIP-6110: Suministro de depósitos de verificador en la cadena

Referencia: EIP-6110

Actualmente, los depósitos se logran a través de eventos en el contrato de «depósito» del sistema (como se discutió en detalle en artículos anteriores).El contrato acepta eventos de «depósito» de credenciales y emitidos de verificadores, que luego se analizan y se convierten en solicitudes de depósito en la capa de baliza.El sistema tiene muchas desventajas: requiere votar en los Eth1Data de la capa de cadena de baliza, que agrega retrasos significativos.Además, la capa de baliza necesita consultar la capa de ejecución, lo que aumenta aún más la complejidad.Estos temas se discuten en detalle en el EIP.Una forma más fácil de hacerlo sin tratar con muchos de estos problemas es incluir solicitudes de depósito directamente en el bloque ETH1 en la ubicación especificada.Este mecanismo es similar al proceso de procesamiento de abstinencia descrito en el EIP anterior.

Los cambios propuestos en este EIP son prometedores.El procesamiento ETH1Data ahora se puede eliminar por completo, ya no tiene que votar o retrasos prolongados entre los eventos en el lado ETH1 y las inclusiones de depósito en la capa de baliza (actualmente aproximadamente 12 horas).También elimina la lógica de las instantáneas del contrato de depósito.Este EIP simplifica el procesamiento de depósitos y lo alinea con el esquema de procesamiento de retiro descrito anteriormente.

Para los Stakers y Validators, estos cambios reducen significativamente el retraso entre el depósito y la activación del validador.Cuando se cortan los validadores, los suplementos necesarios también serán más rápidos.

No hay nada más que decir sobre este EIP, excepto que elimina la lógica obsoleta, simplifica el proceso y crea mejores resultados para todos los involucrados.

EIP-7685: solicitud de capa de ejecución general

Referencia: EIP-7685

Este EIP debería haberse propuesto antes de los primeros tres EIP relacionados con el depósito/retiro/fusión, ya que sienta las bases para estos EIP.Sin embargo, la introducción aquí es resaltar la creciente demanda de datos dedicados móviles consistentes entre los bloques de cadena de ETH1 (ejecución) y Beacon (consenso) (capas).Este EIP afecta a dos capas, lo que hace que el procesamiento de solicitudes activado por las transacciones ETH convencionales sea más eficiente.Actualmente, observamos:

• El evento de depósito en el bloque ETH1 se «traslada» al bloque Beacon para su procesamiento.

• La solicitud de retiro (usando la CLI) en el bloque Beacon se «moverá» al bloque ETH1 para su procesamiento.

• Se debe procesar el verificador de fusiones, lo cual también es una solicitud ETH1- & GT; Beacon.

Estas tres operaciones demuestran la necesidad de un procesamiento constante de varios tipos de solicitudes al cambiar entre la capa de ejecución y la capa de baliza.Además, necesitamos la capacidad de activar estas operaciones utilizando solo la capa ETH1, ya que esto nos permitirá aislar la infraestructura del validador de la infraestructura de gestión de replanteo, mejorando así la seguridad.Por lo tanto, una solución general para administrar tales solicitudes es práctica y necesaria.

Este EIP establece un marco para al menos tres situaciones principales: depósitos, retiros y fusiones.Esta es la razón por la cual EIP temprano introdujo campos como retiro_request_type y deposit_request_type, y ahora la fusión agregará otro campo, consolidation_request_type.Además, este EIP puede incluir un mecanismo común para manejar restricciones en tales solicitudes (constantes de referencia: pending_deposits_limit, pending_partial_withdrawals_limit, pending_consolidations_limit).

Si bien los detalles de implementación detallados de este marco aún no están disponibles, sin duda incluirá tipos de solicitudes críticas, mecanismos de integridad (por ejemplo, solicitudes de hash y merkelized), y el procesamiento y limitación de tarifas en la cola.

Este EIP es arquitectónicamente significativo, lo que permite a ETH1 desencadenar operaciones críticas en la capa de baliza a través de un marco unificado.Para los usuarios finales y los proyectos, esto significa que todas las solicitudes activadas en la capa ETH1 se entregarán y procesarán de manera más eficiente en la capa de baliza.

EIP-2537: Precompilación de la operación de la curva BLS12-381

Referencia: EIP-2537

Si no desea obtener un aspecto más profundo, puede pensar en la precompilación de BLS12-381 como una operación compleja de cifrado «hash» que ahora se puede usar en contratos inteligentes.Para los interesados, exploremos más.

Las operaciones matemáticas en curvas elípticas como BLS12-381 (y su BN-254 correspondiente) se utilizan principalmente principalmente para dos fines:

• Las firmas BLS, donde se utiliza una operación especial llamada «emparejamiento» para verificar estas firmas.Las firmas BLS son ampliamente utilizadas por los verificadores porque agregan múltiples firmas en una.Los validadores se basan en las firmas BLS basadas en las curvas BLS12-381 (aunque también se pueden implementar utilizando cualquier curva que admita el emparejamiento, como BN254).

• Verificación de pruebas de Zksnark, donde el emparejamiento se usa para verificar las pruebas.Además, los compromisos de KZG para grandes fragmentos introducidos por Dencun Hard Forks también usan emparejamiento para validar los compromisos de bloque.

Si desea verificar las firmas BLS o las pruebas de Zksnark en un contrato inteligente, debe calcular estos «pares», que es computacionalmente costoso.Ethereum ya tiene un contrato precompilado (EIP-196 y EIP-197) para la operación de la curva BN254.Sin embargo, la curva BLS12-381 (ahora considerada más segura y más ampliamente utilizada hoy en día) aún no se ha implementado como precompilado.En ausencia de dicha precompilación, la implementación de emparejamiento y otras operaciones curvas en contratos inteligentes requiere muchos cálculos, como se muestra aquí, y consume un gran gas (aproximadamente ~ 10^5 a 10^6 gas).

Este EIP abre la puerta a muchas aplicaciones potenciales, especialmente en la verificación de firma BLS barata basada en la curva BLS12-381.Esto permite lograr soluciones umbral para diversos fines.Como se mencionó anteriormente, los validadores de Ethereum han utilizado firmas basadas en BLS12-381.Con este EIP, los contratos inteligentes estándar ahora pueden verificar de manera eficiente las firmas de verificador agregado.Esto puede simplificar el puente de prueba de consenso y en todos los activos de red, ya que las firmas BLS se usan ampliamente en blockchains.Las firmas de umbral BLS en sí mismas permiten la construcción de muchos esquemas de umbral eficientes para la votación, generación de números aleatorios descentralizados, firma múltiple, etc.

La verificación más barata de la prueba de Zksnark desbloqueará una gran cantidad de aplicaciones.Muchas soluciones basadas en Zksnark se ven obstaculizadas por los costos de verificación de alta prueba, lo que hace que ciertos proyectos sean casi poco prácticos.Este EIP tiene el potencial de cambiar eso.

EIP-2935: Guardar el hash de bloque histórico en el estado

Referencia: EIP-2935

Este EIP propone almacenar 8192 (aproximadamente 27.3 horas) hash de bloques históricos en el estado de blockchain, proporcionando un historial extendido para clientes sin estado, como rollups y contratos inteligentes.Recomienda retener el comportamiento actual del código de operación Blockhash, mantener un límite en 256 bloques, al tiempo que introduce un nuevo contrato del sistema diseñado específicamente para almacenar y recuperar hashes históricos.Este contrato realiza la operación set () cuando la capa de ejecución procesa el bloque.Su método get () es accesible para cualquier persona para recuperar el hash de bloque requerido del búfer de anillo.

Actualmente, es posible hacer referencia al hash histórico en EVM, pero el acceso se limita a los 256 bloques más recientes (aproximadamente 50 minutos).Sin embargo, el acceso a los datos de bloques más antiguos es fundamental en algunos casos, especialmente para aplicaciones de cadena cruzada (datos que requieren bloques anteriores probados) y clientes sin estado, lo que periódicamente requiere acceso a hash de bloque temprano.

Este EIP extiende el marco de tiempo disponible para aplicaciones de retroceso y cadena cruzada, lo que les permite acceder directamente a los datos históricos en el EVM sin tener que recopilarlo externamente.Como resultado, estas soluciones se vuelven más robustas y sostenibles.

EIP-7623: aumentar el costo de los datos de llamada

Referencia: EIP-7623

El costo de los datos de llamadas regula el tamaño disponible de la carga útil de la transacción y puede ser grande en algunos casos (por ejemplo, al pasar matrices grandes o amortiguadores binarios como parámetros).El uso significativo de Datos de llamada se atribuye principalmente a los rollups, que envían cargas útiles a través de calldata que contienen el estado de acumulación actual.

La introducción de datos binarios grandes y probados en blockchain es crucial para el encofrado.La actualización de Dencun (Deneb-Cancun) introduce una innovación importante para tales casos de uso: las transacciones Blob (EIP-4844).Las transacciones Blob tienen sus propias tarifas especiales de gas «Blob».Por lo tanto, Blob proporciona una mejor solución para el encierro que el uso de CallData para almacenar datos.

Fomente el acurrucado para transferir sus datos al blob.La tarifa de gas blob reducida se usa como una «zanahoria», y este EIP suprime el almacenamiento de datos excesivos en las transacciones al aumentar el costo de los datos de llamadas como un «apalancamiento».Este EIP complementa el siguiente EIP-7691 (aumento del rendimiento del blob), que aumenta el número máximo de blobs permitidas por bloque.

EIP-7691: aumenta el rendimiento de Blob

Referencia: EIP-7691

Se introdujeron blobs en la bifurcación dura de Dencun anterior, y los valores iniciales del número máximo y objetivo de blobs «por bloque» son estimaciones conservadoras.Esto se debe a la complejidad de predecir cómo la red P2P manejará la propagación de grandes objetos binarios entre nodos de validador.La configuración anterior ha demostrado ser bueno, lo que hace que este sea el momento adecuado para probar nuevos valores.Anteriormente, el número de blob objetivo/máximo para cada bloque se estableció en 3/6.Estas restricciones ahora se elevan a 6/9 respectivamente.

Combinado con EIP-7623 anterior (aumentando los costos de los días de llamada), este ajuste motiva aún más el acurrucado para transferir sus datos de Data CallData a blobs.El trabajo de encontrar los mejores parámetros de blob continúa.

EIP-7840: Agregue el horario de blob al archivo de configuración de El

Referencia: EIP-7840

Este EIP propone agregar el recuento de blob «por bloque» máximo «por bloque» (discutido anteriormente) y el valor de fracción BasFeeUpdate-Fraction al archivo de configuración de la capa de ejecución de Ethereum (EL).También permite a los clientes recuperar estos valores a través de la API del nodo.Esta característica es especialmente útil para tareas como estimar los costos de gas Blob.

EIP-7702: Configurar el código de cuenta EOA

Referencia: EIP-7702

Este es un EIP muy importante que traerá cambios significativos a los usuarios de Ethereum.Como sabemos, EOA (cuenta externa) no puede tener ningún código, pero puede proporcionar una firma de transacción (tx.origin).Por el contrario, los contratos inteligentes tienen bytecode, pero no pueden proactivamente proponer una firma directa de «TI».Cualquier interacción del usuario que requiera lógica adicional, automática y verificable actualmente solo puede realizar las acciones requeridas llamando a contratos externos.Sin embargo, en este caso, el contrato externo se convierte en el mensaje de mensajería del contrato posterior, lo que hace que la llamada a «la llamada del contrato, no del usuario».

Este EIP presenta un nuevo SET_CODE_TX_TYPE = 0x04 Tipo de transacción (anteriormente tuvimos transacciones antiguas 0x1, nuevas transacciones 0x02 de Berlin y EIP-1559 actualizaciones, y transacciones de Blob 0x03 introducidas en Dencun).Este nuevo tipo de transacción permite configurar códigos para cuentas EOA.De hecho, permite a EOA ejecutar el código externo «en el contexto de su propia cuenta EOA».Desde una perspectiva externa, durante el proceso de transacción, EOA parece «pedir prestado» el código del contrato externo y ejecutarlo.Técnicamente, esto se logra agregando una tupla de datos autorizada especial al almacén de «código» de la dirección EOA (este almacén de «código» siempre estaba vacío para el EOA antes de este EIP).

Actualmente, el nuevo tipo de transacción 0x04 propuesto por este EIP contiene una matriz:

Authorization_list = [[Chain_id, Dirección, Nonce, Y_Parity, R, S], …]

Cada elemento permite que la cuenta use el código de la dirección especificada (desde el último elemento de autorización válido).Al procesar tales transacciones, el código de EOA se establece en un valor especial 0xef0100 || No se puede incluir un valor mágico especial (según EIP-3541).Este valor mágico asegura que este EOA no pueda considerarse un contrato regular, ni se puede llamar como un contrato regular.

Cuando esta EOA inicia una transacción, la dirección especificada se utilizará para llamar al código correspondiente en el contexto del EOA.Si bien los detalles de implementación completos de este EIP no están claros, es seguro que traerá cambios significativos.

Un impacto importante es la capacidad de hacer multicalls directamente de la EOA.Múltiples llamadas son una tendencia persistente en Defi, y muchos protocolos proporcionan esta característica como una herramienta poderosa (como Uniswap V4, Balancer V3 o Euler V2).Con este EIP, ahora puede iniciar múltiples llamadas directamente desde EOA.

Por ejemplo, esta nueva característica resuelve un problema común en defi: aprobar () + cualquier cosa () requiere ineficiencia de dos transacciones independientes.Este EIP permite la lógica común de «autorización previa», de modo que apruebe (x) + depósito (x) se puede completar en una sola transacción.

Otra ventaja de poder «representar» la ejecución de transacciones comisionada por EOA es el concepto de patrocinio.El patrocinio es una característica frecuentemente discutida y altamente deseada para ayudar a los nuevos usuarios a ingresar a Ethereum.

La lógica programable asociada con EOA desbloquea muchas posibilidades, como implementar restricciones de seguridad, establecer límites de gasto, requisitos obligatorios de KYC y más.

Por supuesto, este cambio también plantea muchos problemas de diseño.Un problema es el uso de Chain_ID, que determina si la misma firma puede ser válida en múltiples redes, dependiendo de si está incluida o no incluida en la firma.Otro problema complejo es la elección entre usar la dirección del código de destino e incrustar el código de bytecodo real.Estos dos métodos tienen sus propias características y limitaciones únicas.Además, el uso de NonCE juega un papel clave en la definición de si los permisos son «multipropósito» o «un solo propósito».Estos elementos afectan los problemas funcionales y de seguridad, incluidas las firmas de falla por lotes y la facilidad de uso.Vitalik planteó estas preguntas en una discusión (aquí) y merece una mayor exploración.

Vale la pena señalar que este cambio afectará un mecanismo de seguridad de Ethereum, TX.origin.Se necesitan más detalles sobre esta implementación de EIP, pero parece que el comportamiento de requerir (tx.origin == msg.sender) cambiará.Esta verificación siempre ha sido la forma más confiable de asegurarse de que Msg.Sender sea EOA, no un contrato.Otros métodos, como verificar ExtCodeSize (para verificar si es un contrato), generalmente falla y se pueden evitar (por ejemplo, llamando al constructor o implementando el código en una dirección predefinida después de una transacción).Estos cheques se utilizan para evitar ataques de reingreso y préstamos de rayos, pero están lejos de ser ideales, ya que también obstaculizan la integración con protocolos externos.Después de este EIP, incluso el requerimiento confiable (tx.origin == msg.sender) parece estar obsoleto.El protocolo debe adaptarse eliminando estas verificaciones, porque la diferencia entre «EOA» y «contrato» ya no se aplicará, ahora puede haber un código relevante para cada dirección.

La separación entre EOA tradicional y contratos inteligentes continúa siendo borrosa.Este EIP acerca a Ethereum a un diseño como ton, donde cada cuenta es esencialmente código ejecutable.A medida que las interacciones con los protocolos se vuelven más complejas, el uso de la lógica programable para mejorar la experiencia del usuario final es un proceso natural de esta evolución.

en conclusión

La actualización de Praga /Electra (Pectra) está programada para marzo de 2025.Los cambios en el plan más significativos incluyen:

• Verificador variable Apuestas válidas de hasta 2048 ETH, lo que cambiará significativamente la distribución de estaca, el cronograma del verificador y simplificará la gestión de los proveedores de gran estaca mediante la integración de estacas más pequeñas

• Mejore la interacción entre la capa de ejecución y la capa de consenso, y simplifique el intercambio de datos entre el bloque de ejecución de ETH1 y el bloque de la cadena de baliza.Esto simplificará enormemente depósitos, activaciones, retiros y salidas, acelerará estos procesos y sentará las bases para una mayor interacción entre la capa de consenso y la capa de ejecución

• Soporte para firmas BLS más baratas y verificación ZKSNARK directamente con la nueva precompilación BLS12-381 «amigable para parejas» en contratos inteligentes

• Alentar a los rollups a adoptar transacciones de blob aumentando los umbrales de transacciones de blob y el aumento de los costos de los datos de llamadas

• Hacer que EOA actúe como una cuenta programable, dándole múltiples llamadas, patrocinios y otras características avanzadas

Como puede ver, Pectra tendrá un impacto significativo en la experiencia del usuario final de la capa de replanteación y consenso, así como la capa de ejecución.Si bien no podemos analizar todos estos cambios en detalle a través del código en esta etapa, ya que el desarrollo aún está en progreso, cubriremos estas actualizaciones en futuros artículos.