Se espera que la bifurcación dura de Pectra se ponga en marcha en la red principal en marzo de 2025. La actualización de Pectra incluye 11 Protocolos de Mejora de Ethereum (EIP), que son los siguientes:
EIP-2537: Precompilación de operaciones de curva BLS12-381
EIP-2935: Guardar los valores hash de bloques anteriores en el Estado
EIP-6110: Proporcionar depósitos de validadores en la cadena
EIP-7002: Ejecución de capa desencadena la salida
EIP-7251: aumentar el MAX_EFFECTIVE_BALANCE
EIP-7549: Mover el índice del comité fuera de la validación
EIP-7623: Aumentar el costo de calldata
EIP-7685: solicitud de capa de ejecución general
EIP-7691: Aumentar el rendimiento de Blob
EIP-7702: Configurar el código de cuenta EOA
EIP-7840: Agregar plan de Blob al archivo de configuración EL
Protocolos técnicos relacionados con el staking
EIP-6110: BLS12-381 Curva de operaciones precompiladas
Simplifica el proceso de participación en el staking para los usuarios, reduciendo significativamente el tiempo de espera.
La forma en que los usuarios participan en el staking es depositando 32 ETH en la capa de ejecución y registrándolo en el registro de eventos (Event Log). Luego, la capa de consenso analiza el registro de eventos para determinar si alguien participa en el staking, y luego los usuarios que participan en el staking se convierten en validadores.
Sin embargo, los validadores de la capa de consenso primero necesitan depositar consenso en un punto de tiempo específico, de lo contrario, algunos validadores verán 5 nuevos depósitos, mientras que otros verán solo 3, por lo que los validadores de la capa de consenso votarán por qué bloque de capa de ejecución (eth1data) debe ser referenciado para asegurar que todos vean el mismo bloque de capa de ejecución.
Sin embargo, al principio, para evitar que se produzcan errores graves en la capa de ejecución que puedan causar una bifurcación en la cadena, el bloque de referencia de la capa de ejecución (eth1data) será un bloque de la capa de ejecución que data de hace unas 10 horas, asegurando que los desarrolladores del nivel de consenso tengan suficiente tiempo para reaccionar y manejar cualquier error grave que ocurra. Sin embargo, esto también significa que la participación en la apuesta no será efectiva hasta después de unas 10 horas.
!
△ CL In the 10900000 eth1data in the block, the Block Hash recorded in it is the execution layer block 21683339, which appeared 10 hours ago.
Después de ejecutar el protocolo técnico EIP-6110, los datos de compromiso del usuario en el contrato se convertirán directamente en parte de la capa de ejecución, y debido a que el bloque de capa de consenso en sí mismo contendrá el bloque de capa de ejecución (pero no eth1data), los validadores de la capa de consenso ya no necesitan considerar el problema de "confirmar que el bloque de memoria de la capa de ejecución de referencia es el mismo", siempre que el bloque de memoria de la capa de consenso sea votado por más de dos tercios de los validadores, todos llegarán a un consenso sobre el mismo bloque de capa de ejecución. Por lo tanto, después de participar en el compromiso, el usuario puede esperar a que el bloque de memoria de la capa de ejecución complete el procesamiento en unos 13 minutos como muy pronto, y el cliente de la capa de consenso también puede eliminar la lógica compleja utilizada originalmente para procesar los datos de participación.
EIP-7002: Guardar hashes de bloques históricos en estado
Puede utilizarse para mejorar el proceso de retirada de la participación o retiro de depósitos y ganancias de los validadores, reduciendo el riesgo de los validadores.
La participación en el staking requiere dos llaves, a saber, la clave del validador y la credencial de retiro.
La clave del validador se utiliza para el contenido del trabajo del validador, y la credencial de retiro se utiliza para la dirección donde se retirarán el depósito y las ganancias cuando el validador se retire del staking.
Si pierde la clave del validador, no podrá realizar el trabajo de validador ni retirar el depósito; si pierde la Credencial de Retiro, perderá todo el depósito y las ganancias. Además, algunos usuarios pueden utilizar servicios de depósito de terceros como Lido. Al utilizar estas plataformas, los usuarios deben cuidar la Credencial de Retiro por sí mismos, mientras que la clave del validador es custodiada por el proveedor de servicios y se utiliza para realizar el trabajo de validador en su nombre.
Al ejecutar el protocolo técnico EIP-7002, los usuarios pueden llamar al 'contrato de retiro' (es decir, desplegado en 0x0c15F14308530b7CDB8460094BbB9cC28b9AaaAA) utilizando su Credencial de Retiro para salir del depósito (Exit) o retirar el depósito y las ganancias (Retiro parcial), lo que puede reducir los riesgos relacionados con el uso de servicios de depósito de terceros. Si un usuario participa en el depósito por sí mismo pero pierde la Clave del Validador, también puede utilizarla para salir del depósito.
Los parámetros de la solicitud incluyen validator_pubkey y amount: validator_pubkey es la clave pública del validador, amount es la cantidad a retirar.
La credencial de retiro que inició la solicitud debe ser la credencial de retiro del validador _pubkey validador.
Al llamar al contrato de retiro para hacer una solicitud, debe adjuntar una tarifa de gas (ETH). La tarifa de gas se calculará según la cantidad actual de solicitudes de retiro, y si la cantidad es grande, la tarifa de gas aumentará.
Si la credencial de retiro del usuario es un contrato, puede ir al contrato de retiro para obtener el monto de la tarifa actual y luego iniciar una solicitud y adjuntar la tarifa; Sin embargo, si la credencial de retiro es una cuenta EOA, no hay forma de obtener una tarifa precisa, por lo que solo puede simular la fuera de la cadena por adelantado y pagar la tarifa excedente (que no se reembolsará) para asegurarse de que la solicitud se ejecute con éxito.
Nota: Si tu credencial de retiro todavía está en formato de clave pública BLS, recuerda cambiarla primero a formato de dirección EL.
EIP-7251: aumentar el MAX_EFECTIVO_BALANCE
Es posible aumentar significativamente el límite de staking para reducir el número de validadores, y los validadores que no alcancen el límite superior pueden disfrutar automáticamente de recompensas de staking.
Los usuarios que hacen staking para convertirse en validadores proporcionan MAX_EFFECTIVE_BALANCE cantidad de ETH, que no puede ser menor ni mayor (actualmente MAX_EFFECTIVE_BALANCE es de 32 ETH). Si un usuario tiene 1024 ETH en staking, puede participar en el staking 32 veces, habilitar 32 validadores y ejecutar 32 nodos validadores. Además de hacer que los datos de estado de la capa de consenso sean más grandes, la carga en la capa de red p2p de la capa de consenso es más significativa, porque cada ranura (cada 12 segundos) tiene decenas de miles de firmas de validadores para pasar y agregar en la capa de red p2p.
Después de implementar el protocolo técnico EIP-7251, el límite mínimo de participación (MIN_ACTIVATION_BALANCE) seguirá siendo de 32 ETH, pero el límite máximo (MAX_EFFECTIVE_BALANCE) se aumentará significativamente a 2048 ETH. Puede apostar cualquier cantidad de ETH entre 32 y 2048 para obtener ganancias por participación, ya no es necesario retirar las ganancias periódicamente, simplemente continúe con una nueva participación una vez que haya acumulado 32 ETH.
En la actualidad, los validadores existentes no necesitan retirarse primero del staking y luego fusionarse y volver a unirse al staking juntos, sino que pueden usar directamente el nuevo "contrato para fusionar depósitos" (implementado en el 0x00431F263cE400f4455c2dCf564e53007Ca4bbBb) en la capa de ejecución, y el Crédito de Retiro del validador llamará al contrato para iniciar una solicitud de fusión del depósito.
Los parámetros para solicitar la fusión del depósito incluyen source_pubkey y target_pubkey: ambas claves son la Clave de Validador del validador, el validador de origen se fusionará con el validador de destino.
El Withdrawal Credential que inicia la solicitud debe ser el Withdrawal Credential del validador de origen.
Al llamar al contrato de depósito de combinación para hacer una solicitud, se debe adjuntar una tarifa (ETH), que se calculará según la cantidad actual de solicitudes. Si la cantidad de solicitudes es grande, la tarifa aumentará.
Si el Credencial de Retiro del usuario es un contrato, puede llamar primero al contrato de depósito combinado para obtener la cantidad actual de tarifas, y luego realizar la solicitud adjuntando la tarifa; pero si el Credencial de Retiro es una cuenta EOA, no se puede obtener una tarifa precisa, solo se puede simular y pagar una tarifa excesiva por adelantado (no se reembolsará) para asegurar que la solicitud se realice con éxito.
Nota: Si su credencial de retiro está en formato de clave pública BLS, primero debe cambiarla al formato de dirección EL.
EIP-7685: Solicitud de capa de ejecución común
Establezca una canalización de información formal de EL-> CL para que los usuarios y los servicios de participación puedan enviar solicitudes directamente a la capa de consenso.
Los usuarios pueden enviar solicitudes directamente desde la capa de ejecución a la capa de consenso, y los servicios de staking (como Lido) pueden operar de manera más descentralizada. Por ejemplo, las solicitudes de retiro de staking mencionadas anteriormente en EIP-7002, así como las solicitudes de combinación de depósitos en EIP-7251. Sin este protocolo técnico, los usuarios de Lido tendrían que confiar en que los proveedores de servicios de nodo de Lido cumplan con precisión el retiro de staking o la combinación de depósitos en la capa de consenso; con este protocolo técnico, los usuarios de Lido pueden enviar solicitudes directamente a través del contrato de gobernanza en la capa de ejecución.
Estas solicitudes se diferenciarán por el tipo de solicitud, así como por la solicitud a través de diferentes contratos, y finalmente se escribirán en bloques de memoria de la capa de ejecución, por lo que la capa de consenso puede obtener esta información directamente a través de los bloques de memoria de la capa de ejecución sin necesidad de escribir lógica de análisis separada.
EIP-6110, EIP-7002 y EIP-7251 se basan en los criterios definidos por EIP-7685:
EIP-6110 Agregar solicitud de participación: Tipo de solicitud = 0, a través del contrato de depósito
(0x00000000219ab540356cbb839cbe05303d7705fa) inició la solicitud.
EIP-7002 solicitud de retiro de participación: Tipo de solicitud=1, a través del contrato Withdraw
(0x0c15F14308530b7CDB8460094BbB9cC28b9AaaAA) ha iniciado una solicitud.
Solicitud de consolidación de depósitos EIP-7251: Tipo de solicitud=2, a través del contrato de consolidación
(0x00431F263cE400f4455c2dCf564e53007Ca4bbBb) Iniciar una solicitud.
Mejora del protocolo técnico de la experiencia de uso
EIP-7702: Configuración del código de cuenta EOA
Permitir que la cuenta EOA se transforme en una cuenta de contrato inteligente a voluntad, mejorando significativamente la experiencia de uso.
La cuenta EOA tiene algunas deficiencias en su uso, incluyendo:
Se requiere registrar y guardar la clave privada o la frase mnemotécnica, lo que supone una barrera de entrada relativamente alta para los nuevos usuarios que se registran y utilizan.
Una transacción de cuenta EOA solo puede realizar una operación, por ejemplo, para intercambiar USDT por ETH en Uniswap, primero debe iniciar una transacción para aprobar USDT, y luego enviar otra transacción para realizar el intercambio.
No se puede detallar el control de permisos, como delegar ciertas operaciones de la cuenta a terceros para que las realicen en nombre del usuario. El usuario debe ocuparse personalmente de cada asunto y firmar cada operación para enviar una transacción una vez.
Sin mecanismo de recuperación, solo puede mantener segura la clave privada o las palabras clave. Si se pierden, los activos de la cuenta no se pueden recuperar.
Si se trata de una cuenta de contrato inteligente (por ejemplo, Safe), se pueden resolver los problemas anteriores:
Los usuarios pueden usar la clave privada en el chip de seguridad del teléfono móvil (o computadora) para firmar la autorización, sin necesidad de recordar ninguna clave privada o palabras mnemotécnicas, o usar el correo electrónico para firmar la autorización, u otros métodos de autorización diversos.
Varios operaciones pueden agruparse en lotes y ejecutarse juntas en una sola transacción, lo que permite completar todas las operaciones complejas de DApp con una sola firma de autorización y una sola transacción.
Los usuarios pueden autorizar a terceros a controlar sus cuentas, pero al mismo tiempo especificar restricciones como "con qué contratos se puede interactuar", "qué acciones no se pueden realizar", "cuántos activos solo se pueden usar cuando se trata de transferencias de activos" o "cuántas operaciones no se pueden realizar por semana".
Se puede agregar un mecanismo de recuperación para transferir los activos de la cuenta a una nueva cuenta en caso de pérdida de la frase mnemotécnica, teléfono o correo electrónico.
La propuesta EIP-7702 es otorgar a la cuenta EOA el poder de transformarse en una cuenta de contrato. El usuario firma el mensaje de transformación con la clave privada EOA, y el contenido de la firma incluye "ID de cadena", "dirección de contrato transformada" y "valor de Nonce de EOA".
ID de cadena: Se utiliza para evitar que la firma de la cadena A sea reproducida por la cadena B. Sin embargo, si el ID de la cadena se establece en 0, significa que está dispuesto a transformarse en cada cadena.
Dirección del contrato que desea convertir: Si completa una dirección de contrato seguro, su cuenta de EOA se convertirá en un contrato seguro; si completa una dirección vacía (dirección(0)), esto significa que desea cancelar la conversión y volver a una cuenta EOA simple.
Valor Nonce de EOA: Se utiliza para evitar que se reproduzcan las firmas. Si se aumenta el valor nonce, se invalidará la firma original.
Sin embargo, hay algunas cosas que hay que tener en cuenta:
La clave privada EOA se puede seguir utilizando
Incluso si la cuenta EOA del usuario se convierte en un contrato, puede seguir utilizándola de la misma manera que la cuenta EOA original. Por ejemplo, si su cuenta EOA se convierte en un contrato seguro, puede usar la interfaz segura, pasar por el proceso de transacción segura o continuar firmando y enviando transacciones con la billetera EOA original. Sin embargo, esto también significa que la seguridad de la cuenta sigue estando limitada a la clave privada.
Sigue siendo la seguridad de la clave privada EOA
Incluso si el EOA del usuario se convierte en una dirección multi-firma, siempre y cuando no pierda la clave privada del EOA, la seguridad de su cuenta siempre será la seguridad de la clave privada del EOA: todavía tiene que guardar bien su clave privada o frase mnemotécnica, su cuenta no se volverá tan segura como la de una dirección multi-firma.
El almacenamiento de la cuenta EOA no se formateará
Cuando una cuenta EOA se transforma en un contrato y escribe datos en su almacenamiento, a menos que los datos se eliminen explícitamente, los datos escritos en el almacenamiento no se formatearán porque la cuenta EOA se transforma en otro contrato o cancela la transformación, por lo que los desarrolladores deben tener cuidado de no leer los datos dejados por el contrato de transformación anterior, puede consultar ERC-7201.
El proceso de EIP-7702 no incluye la inicialización
Por lo general, las cuentas de contratos inteligentes requieren un paso de inicialización, que es escribir de forma sincronizada la información del propietario de la cuenta (como la clave pública o la dirección) al implementar la cuenta para evitar que el paso de implementación sea adelantado (Frontrun) y se pierda el derecho de propiedad de la cuenta. Normalmente, esto lo realiza el contrato Factory que implementa la cuenta mediante "implementación + inicialización", pero debido a que EIP-7702 es un cambio directo en lugar de ser implementado por un Factory para implementar el contrato en la cuenta EOA, los atacantes pueden copiar la firma de transformación del usuario y enviar la transacción primero a la cadena para transformarse en el usuario, pero inicializar la cuenta de forma que sea controlada por el atacante. Por lo tanto, los desarrolladores deben prestar atención a EIP-7702. Posibles métodos preventivos pueden incluir la verificación de la firma de la cuenta EOA dentro de la función de inicialización, de modo que incluso si se adelanta, el atacante no podrá generar la firma de la cuenta EOA para completar la inicialización.
Solicitudes de cambio de gatekeeper de billetera
La billetera debe hacer un buen trabajo de verificación del usuario, detener la solicitud y advertir al usuario cuando el sitio web DApp malicioso le pida al usuario que firme una transacción de transformación, de lo contrario, si el usuario firma una transacción de transformación maliciosa, los activos se transferirán instantáneamente. Estos son algunos ejemplos de cómo transformarse en un contrato:
Cuenta Safe Ithaca modificada
Cuenta de Ithaca
Protocolo técnico de DApp
EIP-2537: Precompilación de operaciones en la curva BLS12-381
Reducir el costo y hacer que sea más factible la aplicación de la prueba de conocimiento cero basada en la curva BLS.
EIP-2537 agrega varios contratos de precompilación nuevos para proporcionar operaciones de curva BLS de bajo costo, lo que hace más factible desarrollar aplicaciones de prueba de conocimiento cero basadas en curvas BLS.
EIP-2935: Guardar los valores hash de bloques anteriores en el Estado
Permite a los desarrolladores o nodos leer el hash de bloque de bloques de memoria pasados directamente desde el almacenamiento del contrato del sistema.
Si un desarrollador necesita demostrar el contenido de un bloque de memoria anterior, por ejemplo, si en un desafío de fraude de Optimismtic Rollup necesita demostrar que existen 1000 bloques de memoria anteriores a una transacción, el desafiante no puede simplemente afirmarlo.
"Por favor, créeme, realmente existía esta transacción antes de 1000 bloques de memoria", él debe presentar evidencia, pero no hay evidencia directa que pueda demostrar directamente que "estos contenidos estaban en los 1000 bloques de memoria anteriores", por lo tanto, debe demostrar hacia atrás, bloque por bloque, en forma de una "cadena" de bloques de memoria, hasta llegar a los 1000 bloques anteriores, y luego demostrar que esta transacción estaba en ese bloque de memoria.
Cada bloque apunta a un bloque principal, por lo que se puede demostrar cualquier bloque en la historia en el camino hacia adelante.
Supongamos que actualmente es un bloque de memoria con un número 10000, y el desafío de fraude quiere proporcionar pruebas de que el bloque de memoria con el número 9000 tiene una transacción X, el retador debe comenzar con el hash del bloque de memoria 10000, primero probar el hash del bloque de memoria principal 9999 conectado al bloque de memoria 10000 y luego probar el bloque de memoria 9998... Hasta el bloque de memoria 9000, se propone que el contenido del bloque de memoria 9000 contenga la transacción X.
Después de EIP-2935, habrá un contrato del sistema (desplegado en 0x0F792be4B0c0cb4DAE440Ef133E90C0eCD48CCCC), cuyo almacenamiento almacenará como máximo 8192 valores hash de bloques de memoria anteriores. Cada vez que se genere un nuevo bloque de memoria, este contrato del sistema se actualizará automáticamente, escribiendo el valor hash del bloque de memoria anterior en el contrato del sistema (sobrescribiendo 8192 valores hash de bloques de memoria anteriores).
De esta manera, en el ejemplo del desafío de fraude Optimismtic Rollup, el retador no tiene que volver al bloque de memoria anterior para probar un bloque de memoria a la vez, sino que puede probar directamente que en el estado actual de la cadena del bloque de memoria 10000, el valor de un determinado almacenamiento (correspondiente al bloque de memoria 9000) del contrato del sistema es el valor hash del bloque de memoria 9000. Si el rango supera 8192, como el bloque de memoria 1000, entonces como máximo es un paso más para probar el valor hash del bloque de memoria 1808 (= 10000 - 8192), y luego probar el valor hash del bloque de memoria 1000 en el contrato del sistema en el estado actual de la cadena del bloque de memoria 1808.
Esto también allana el camino para un futuro cliente sin estado: en el futuro, los nodos ligeros ya no necesitarán almacenar los encabezados de bloque de todos los bloques de memoria históricos, sino que solo tendrán que pedir a otra persona que proporcione pruebas utilizando el método de prueba en el ejemplo anterior de desafío de fraude cuando sea necesario usar el hash de un bloque de memoria en el historial o el contenido del bloque de memoria.
EIP-7623: Aumento del costo de calldata
Aumente el costo de publicación de datos con calldata para crear suficiente espacio seguro para aumentar el límite de gas de bloque y el límite de blobs.
Con la creciente demanda de publicación de paquetes acumulativos de datos, después de la introducción de blobs en EIP-4844 para permitir que los paquetes acumulativos coloquen datos de una manera muy económica, el aumento del número de blobs ha sido una actualización que la comunidad espera con ansias.
Cada vez más validadores expresan su apoyo para aumentar el límite de gas del bloque.
Pero ya sea aumentando el límite de gas del bloque o la cantidad de blobs, el aumento del volumen de datos de la transacción ejerce más presión sobre la red p2p de Ethereum, lo que aumenta la eficiencia de los ataques de los atacantes, a menos que también se aumente el costo de publicación de datos.
Después de que se lance el protocolo EIP-7623, el costo de los datos de llamada se incrementará 2,5 veces desde el original "Byte cero: 4 gases, bytes distintos de cero: 16 gases" a "Byte cero: 10 gases, bytes distintos de cero: 40 gases".
Originalmente, si un atacante usaba todo el límite de gas de bloque (30 M) para colocar datos basura, el tamaño de los datos del bloque de memoria sería de aproximadamente 1,79 MB (30 M / 16), en comparación con el tamaño promedio del bloque de memoria de solo unos 100 KB. Si el límite de gas de bloque se incrementa a 40 M, un atacante puede generar un bloque de memoria de aproximadamente 2,38 MB. Cuando el coste de los datos de llamada se incrementa 2,5 veces, la eficiencia del atacante se reducirá a un máximo de 0,72 MB para 30 M y 0,95 MB para 40 M, de modo que el límite de gas de bloque y el blob se puedan aumentar con más confianza. Sin embargo, este protocolo técnico no quiere afectar al usuario general que "no utiliza calldata para publicar datos", por lo que calculará el uso total de gas de la transacción de dos formas, la que sea mayor:
El método original de cálculo del uso de gas de la transacción se calcula con el costo de los datos de llamada antiguos: es decir, los datos de llamada se calculan de la manera de "Byte cero: 4 gas, byte distinto de cero: 16 gas", y se suman el gas consumido por la ejecución de la transacción y el gas consumido por el contrato de despliegue.
Simplemente calcule la cantidad de gas de datos de llamadas, pero use el nuevo costo para calcular: es decir, los datos de llamadas se calculan en forma de "Byte cero: 10 gas, byte distinto de cero: 40 gas", pero no incluye el gas consumido por la ejecución o el gas consumido por el despliegue del contrato, por lo que para los usuarios que generalmente "no usan datos de llamadas para publicar datos" (como ir a Uniswap para intercambiar), es el gas principal El consumo es la parte de la ejecución, e incluso si los datos de llamada se calculan a un nuevo costo, no excederán el gas consumido por la ejecución, por lo que los usuarios generales no se verán afectados.
El impacto real será en Rollup de escala pequeña, ya que Blob tiene un tamaño y un costo fijo, por lo que el uso de Blob es menos eficiente para los Rollup pequeños. El uso de calldata es más rentable, pero después de EIP-7623, los costos de estos Rollup pequeños se incrementarán en un 2.5 veces. Es posible que tengan que cambiar a Blob o encontrar una forma de compartir un Blob juntos.
EIP-7691: Aumentar el rendimiento de blobs
Aumente el número de blobs y agregue más espacio para la publicación de datos en los paquetes acumulativos. *
EIP-7691 aumenta el número de blobs de "Destino: 3 blobs, máx.: 6 blobs" a "Destino: 6 blobs, máx.: 9 blobs" para aumentar el espacio para publicar más datos en resúmenes.
Nota: Además, hay algunos diseños en el mercado de tarifas de Blob que necesitan ser ajustados, como que la velocidad de ajuste de tarifas no es lo suficientemente instantánea y el piso de tarifas es demasiado bajo, pero esto no está en el problema que este protocolo técnico pretende resolver.
Otros protocolos técnicos
EIP-7549: Mover el índice del comité fuera de la validación
Ajustar el contenido de la votación de los validadores para facilitar la agregación de votos y reducir la presión sobre la red P2P.
Los validadores se asignan aleatoriamente a un grupo de comités y pares para cada época
En la votación por bloques de memoria, los votos de los validadores de cada comité se pueden sumar, lo que reduce el número de votos aprobados en la red P2P, pero los votos del validador contendrán información sobre el número de comités a los que pertenece el validador, lo que significa que los votos de diferentes comités no se pueden agregar, incluso si todos votan en el mismo bloque de memoria.
EIP-7549 elimina la información de que el validador pertenece al primer comité del contenido de la votación, de modo que los validadores de diferentes comités se pueden agregar cuando el contenido de la votación es el mismo, lo que reduce aún más el número de votos aprobados en la red P2P y reduce la presión sobre la red P2P.
EIP-7840: Agregar plan de Blob al archivo de configuración EL
Cree un archivo de configuración para los parámetros de blob en la capa de ejecución, ahorrando al nodo de la capa de ejecución la molestia de preguntar al nodo de la capa de consenso los parámetros relacionados con los blobs.
Actualmente, todos los parámetros relacionados con Blob se almacenan en los nodos de la capa de consenso, pero los nodos de ejecución aún necesitan estos parámetros en algunas situaciones (por ejemplo, RPC eth_feeHistory), por lo que deben consultar a los nodos de la capa de consenso.
EIP-7840 crea un archivo de configuración para los parámetros relacionados con blobs en la capa de ejecución, y los nodos de la capa de ejecución pueden leer directamente los parámetros relacionados con blobs a través de este archivo de configuración sin tener que preguntar a los nodos de la capa de consenso.
El contenido es solo de referencia, no una solicitud u oferta. No se proporciona asesoramiento fiscal, legal ni de inversión. Consulte el Descargo de responsabilidad para obtener más información sobre los riesgos.
Ethereum Pectra Bifurcación dura介绍
Autor: NIC Lin, Medium
Se espera que la bifurcación dura de Pectra se ponga en marcha en la red principal en marzo de 2025. La actualización de Pectra incluye 11 Protocolos de Mejora de Ethereum (EIP), que son los siguientes:
Protocolos técnicos relacionados con el staking
EIP-6110: BLS12-381 Curva de operaciones precompiladas
Simplifica el proceso de participación en el staking para los usuarios, reduciendo significativamente el tiempo de espera.
La forma en que los usuarios participan en el staking es depositando 32 ETH en la capa de ejecución y registrándolo en el registro de eventos (Event Log). Luego, la capa de consenso analiza el registro de eventos para determinar si alguien participa en el staking, y luego los usuarios que participan en el staking se convierten en validadores.
Sin embargo, los validadores de la capa de consenso primero necesitan depositar consenso en un punto de tiempo específico, de lo contrario, algunos validadores verán 5 nuevos depósitos, mientras que otros verán solo 3, por lo que los validadores de la capa de consenso votarán por qué bloque de capa de ejecución (eth1data) debe ser referenciado para asegurar que todos vean el mismo bloque de capa de ejecución.
Sin embargo, al principio, para evitar que se produzcan errores graves en la capa de ejecución que puedan causar una bifurcación en la cadena, el bloque de referencia de la capa de ejecución (eth1data) será un bloque de la capa de ejecución que data de hace unas 10 horas, asegurando que los desarrolladores del nivel de consenso tengan suficiente tiempo para reaccionar y manejar cualquier error grave que ocurra. Sin embargo, esto también significa que la participación en la apuesta no será efectiva hasta después de unas 10 horas.
!
△ CL In the 10900000 eth1data in the block, the Block Hash recorded in it is the execution layer block 21683339, which appeared 10 hours ago.
Después de ejecutar el protocolo técnico EIP-6110, los datos de compromiso del usuario en el contrato se convertirán directamente en parte de la capa de ejecución, y debido a que el bloque de capa de consenso en sí mismo contendrá el bloque de capa de ejecución (pero no eth1data), los validadores de la capa de consenso ya no necesitan considerar el problema de "confirmar que el bloque de memoria de la capa de ejecución de referencia es el mismo", siempre que el bloque de memoria de la capa de consenso sea votado por más de dos tercios de los validadores, todos llegarán a un consenso sobre el mismo bloque de capa de ejecución. Por lo tanto, después de participar en el compromiso, el usuario puede esperar a que el bloque de memoria de la capa de ejecución complete el procesamiento en unos 13 minutos como muy pronto, y el cliente de la capa de consenso también puede eliminar la lógica compleja utilizada originalmente para procesar los datos de participación.
EIP-7002: Guardar hashes de bloques históricos en estado
Puede utilizarse para mejorar el proceso de retirada de la participación o retiro de depósitos y ganancias de los validadores, reduciendo el riesgo de los validadores.
La participación en el staking requiere dos llaves, a saber, la clave del validador y la credencial de retiro.
La clave del validador se utiliza para el contenido del trabajo del validador, y la credencial de retiro se utiliza para la dirección donde se retirarán el depósito y las ganancias cuando el validador se retire del staking.
Si pierde la clave del validador, no podrá realizar el trabajo de validador ni retirar el depósito; si pierde la Credencial de Retiro, perderá todo el depósito y las ganancias. Además, algunos usuarios pueden utilizar servicios de depósito de terceros como Lido. Al utilizar estas plataformas, los usuarios deben cuidar la Credencial de Retiro por sí mismos, mientras que la clave del validador es custodiada por el proveedor de servicios y se utiliza para realizar el trabajo de validador en su nombre.
Al ejecutar el protocolo técnico EIP-7002, los usuarios pueden llamar al 'contrato de retiro' (es decir, desplegado en 0x0c15F14308530b7CDB8460094BbB9cC28b9AaaAA) utilizando su Credencial de Retiro para salir del depósito (Exit) o retirar el depósito y las ganancias (Retiro parcial), lo que puede reducir los riesgos relacionados con el uso de servicios de depósito de terceros. Si un usuario participa en el depósito por sí mismo pero pierde la Clave del Validador, también puede utilizarla para salir del depósito.
Nota: Si tu credencial de retiro todavía está en formato de clave pública BLS, recuerda cambiarla primero a formato de dirección EL.
EIP-7251: aumentar el MAX_EFECTIVO_BALANCE
Es posible aumentar significativamente el límite de staking para reducir el número de validadores, y los validadores que no alcancen el límite superior pueden disfrutar automáticamente de recompensas de staking.
Los usuarios que hacen staking para convertirse en validadores proporcionan MAX_EFFECTIVE_BALANCE cantidad de ETH, que no puede ser menor ni mayor (actualmente MAX_EFFECTIVE_BALANCE es de 32 ETH). Si un usuario tiene 1024 ETH en staking, puede participar en el staking 32 veces, habilitar 32 validadores y ejecutar 32 nodos validadores. Además de hacer que los datos de estado de la capa de consenso sean más grandes, la carga en la capa de red p2p de la capa de consenso es más significativa, porque cada ranura (cada 12 segundos) tiene decenas de miles de firmas de validadores para pasar y agregar en la capa de red p2p.
Después de implementar el protocolo técnico EIP-7251, el límite mínimo de participación (MIN_ACTIVATION_BALANCE) seguirá siendo de 32 ETH, pero el límite máximo (MAX_EFFECTIVE_BALANCE) se aumentará significativamente a 2048 ETH. Puede apostar cualquier cantidad de ETH entre 32 y 2048 para obtener ganancias por participación, ya no es necesario retirar las ganancias periódicamente, simplemente continúe con una nueva participación una vez que haya acumulado 32 ETH.
En la actualidad, los validadores existentes no necesitan retirarse primero del staking y luego fusionarse y volver a unirse al staking juntos, sino que pueden usar directamente el nuevo "contrato para fusionar depósitos" (implementado en el 0x00431F263cE400f4455c2dCf564e53007Ca4bbBb) en la capa de ejecución, y el Crédito de Retiro del validador llamará al contrato para iniciar una solicitud de fusión del depósito.
Nota: Si su credencial de retiro está en formato de clave pública BLS, primero debe cambiarla al formato de dirección EL.
EIP-7685: Solicitud de capa de ejecución común
Establezca una canalización de información formal de EL-> CL para que los usuarios y los servicios de participación puedan enviar solicitudes directamente a la capa de consenso.
Los usuarios pueden enviar solicitudes directamente desde la capa de ejecución a la capa de consenso, y los servicios de staking (como Lido) pueden operar de manera más descentralizada. Por ejemplo, las solicitudes de retiro de staking mencionadas anteriormente en EIP-7002, así como las solicitudes de combinación de depósitos en EIP-7251. Sin este protocolo técnico, los usuarios de Lido tendrían que confiar en que los proveedores de servicios de nodo de Lido cumplan con precisión el retiro de staking o la combinación de depósitos en la capa de consenso; con este protocolo técnico, los usuarios de Lido pueden enviar solicitudes directamente a través del contrato de gobernanza en la capa de ejecución.
Estas solicitudes se diferenciarán por el tipo de solicitud, así como por la solicitud a través de diferentes contratos, y finalmente se escribirán en bloques de memoria de la capa de ejecución, por lo que la capa de consenso puede obtener esta información directamente a través de los bloques de memoria de la capa de ejecución sin necesidad de escribir lógica de análisis separada.
EIP-6110, EIP-7002 y EIP-7251 se basan en los criterios definidos por EIP-7685:
(0x00000000219ab540356cbb839cbe05303d7705fa) inició la solicitud.
(0x0c15F14308530b7CDB8460094BbB9cC28b9AaaAA) ha iniciado una solicitud.
(0x00431F263cE400f4455c2dCf564e53007Ca4bbBb) Iniciar una solicitud.
Mejora del protocolo técnico de la experiencia de uso
EIP-7702: Configuración del código de cuenta EOA
Permitir que la cuenta EOA se transforme en una cuenta de contrato inteligente a voluntad, mejorando significativamente la experiencia de uso.
La cuenta EOA tiene algunas deficiencias en su uso, incluyendo:
Si se trata de una cuenta de contrato inteligente (por ejemplo, Safe), se pueden resolver los problemas anteriores:
La propuesta EIP-7702 es otorgar a la cuenta EOA el poder de transformarse en una cuenta de contrato. El usuario firma el mensaje de transformación con la clave privada EOA, y el contenido de la firma incluye "ID de cadena", "dirección de contrato transformada" y "valor de Nonce de EOA".
Sin embargo, hay algunas cosas que hay que tener en cuenta:
Incluso si la cuenta EOA del usuario se convierte en un contrato, puede seguir utilizándola de la misma manera que la cuenta EOA original. Por ejemplo, si su cuenta EOA se convierte en un contrato seguro, puede usar la interfaz segura, pasar por el proceso de transacción segura o continuar firmando y enviando transacciones con la billetera EOA original. Sin embargo, esto también significa que la seguridad de la cuenta sigue estando limitada a la clave privada.
Incluso si el EOA del usuario se convierte en una dirección multi-firma, siempre y cuando no pierda la clave privada del EOA, la seguridad de su cuenta siempre será la seguridad de la clave privada del EOA: todavía tiene que guardar bien su clave privada o frase mnemotécnica, su cuenta no se volverá tan segura como la de una dirección multi-firma.
Cuando una cuenta EOA se transforma en un contrato y escribe datos en su almacenamiento, a menos que los datos se eliminen explícitamente, los datos escritos en el almacenamiento no se formatearán porque la cuenta EOA se transforma en otro contrato o cancela la transformación, por lo que los desarrolladores deben tener cuidado de no leer los datos dejados por el contrato de transformación anterior, puede consultar ERC-7201.
Por lo general, las cuentas de contratos inteligentes requieren un paso de inicialización, que es escribir de forma sincronizada la información del propietario de la cuenta (como la clave pública o la dirección) al implementar la cuenta para evitar que el paso de implementación sea adelantado (Frontrun) y se pierda el derecho de propiedad de la cuenta. Normalmente, esto lo realiza el contrato Factory que implementa la cuenta mediante "implementación + inicialización", pero debido a que EIP-7702 es un cambio directo en lugar de ser implementado por un Factory para implementar el contrato en la cuenta EOA, los atacantes pueden copiar la firma de transformación del usuario y enviar la transacción primero a la cadena para transformarse en el usuario, pero inicializar la cuenta de forma que sea controlada por el atacante. Por lo tanto, los desarrolladores deben prestar atención a EIP-7702. Posibles métodos preventivos pueden incluir la verificación de la firma de la cuenta EOA dentro de la función de inicialización, de modo que incluso si se adelanta, el atacante no podrá generar la firma de la cuenta EOA para completar la inicialización.
La billetera debe hacer un buen trabajo de verificación del usuario, detener la solicitud y advertir al usuario cuando el sitio web DApp malicioso le pida al usuario que firme una transacción de transformación, de lo contrario, si el usuario firma una transacción de transformación maliciosa, los activos se transferirán instantáneamente. Estos son algunos ejemplos de cómo transformarse en un contrato:
Protocolo técnico de DApp
EIP-2537: Precompilación de operaciones en la curva BLS12-381
Reducir el costo y hacer que sea más factible la aplicación de la prueba de conocimiento cero basada en la curva BLS.
EIP-2537 agrega varios contratos de precompilación nuevos para proporcionar operaciones de curva BLS de bajo costo, lo que hace más factible desarrollar aplicaciones de prueba de conocimiento cero basadas en curvas BLS.
EIP-2935: Guardar los valores hash de bloques anteriores en el Estado
Permite a los desarrolladores o nodos leer el hash de bloque de bloques de memoria pasados directamente desde el almacenamiento del contrato del sistema.
Si un desarrollador necesita demostrar el contenido de un bloque de memoria anterior, por ejemplo, si en un desafío de fraude de Optimismtic Rollup necesita demostrar que existen 1000 bloques de memoria anteriores a una transacción, el desafiante no puede simplemente afirmarlo.
"Por favor, créeme, realmente existía esta transacción antes de 1000 bloques de memoria", él debe presentar evidencia, pero no hay evidencia directa que pueda demostrar directamente que "estos contenidos estaban en los 1000 bloques de memoria anteriores", por lo tanto, debe demostrar hacia atrás, bloque por bloque, en forma de una "cadena" de bloques de memoria, hasta llegar a los 1000 bloques anteriores, y luego demostrar que esta transacción estaba en ese bloque de memoria.
Cada bloque apunta a un bloque principal, por lo que se puede demostrar cualquier bloque en la historia en el camino hacia adelante.
Supongamos que actualmente es un bloque de memoria con un número 10000, y el desafío de fraude quiere proporcionar pruebas de que el bloque de memoria con el número 9000 tiene una transacción X, el retador debe comenzar con el hash del bloque de memoria 10000, primero probar el hash del bloque de memoria principal 9999 conectado al bloque de memoria 10000 y luego probar el bloque de memoria 9998... Hasta el bloque de memoria 9000, se propone que el contenido del bloque de memoria 9000 contenga la transacción X.
Después de EIP-2935, habrá un contrato del sistema (desplegado en 0x0F792be4B0c0cb4DAE440Ef133E90C0eCD48CCCC), cuyo almacenamiento almacenará como máximo 8192 valores hash de bloques de memoria anteriores. Cada vez que se genere un nuevo bloque de memoria, este contrato del sistema se actualizará automáticamente, escribiendo el valor hash del bloque de memoria anterior en el contrato del sistema (sobrescribiendo 8192 valores hash de bloques de memoria anteriores).
De esta manera, en el ejemplo del desafío de fraude Optimismtic Rollup, el retador no tiene que volver al bloque de memoria anterior para probar un bloque de memoria a la vez, sino que puede probar directamente que en el estado actual de la cadena del bloque de memoria 10000, el valor de un determinado almacenamiento (correspondiente al bloque de memoria 9000) del contrato del sistema es el valor hash del bloque de memoria 9000. Si el rango supera 8192, como el bloque de memoria 1000, entonces como máximo es un paso más para probar el valor hash del bloque de memoria 1808 (= 10000 - 8192), y luego probar el valor hash del bloque de memoria 1000 en el contrato del sistema en el estado actual de la cadena del bloque de memoria 1808.
Esto también allana el camino para un futuro cliente sin estado: en el futuro, los nodos ligeros ya no necesitarán almacenar los encabezados de bloque de todos los bloques de memoria históricos, sino que solo tendrán que pedir a otra persona que proporcione pruebas utilizando el método de prueba en el ejemplo anterior de desafío de fraude cuando sea necesario usar el hash de un bloque de memoria en el historial o el contenido del bloque de memoria.
EIP-7623: Aumento del costo de calldata
Aumente el costo de publicación de datos con calldata para crear suficiente espacio seguro para aumentar el límite de gas de bloque y el límite de blobs.
Con la creciente demanda de publicación de paquetes acumulativos de datos, después de la introducción de blobs en EIP-4844 para permitir que los paquetes acumulativos coloquen datos de una manera muy económica, el aumento del número de blobs ha sido una actualización que la comunidad espera con ansias.
Cada vez más validadores expresan su apoyo para aumentar el límite de gas del bloque.
Pero ya sea aumentando el límite de gas del bloque o la cantidad de blobs, el aumento del volumen de datos de la transacción ejerce más presión sobre la red p2p de Ethereum, lo que aumenta la eficiencia de los ataques de los atacantes, a menos que también se aumente el costo de publicación de datos.
Después de que se lance el protocolo EIP-7623, el costo de los datos de llamada se incrementará 2,5 veces desde el original "Byte cero: 4 gases, bytes distintos de cero: 16 gases" a "Byte cero: 10 gases, bytes distintos de cero: 40 gases".
Originalmente, si un atacante usaba todo el límite de gas de bloque (30 M) para colocar datos basura, el tamaño de los datos del bloque de memoria sería de aproximadamente 1,79 MB (30 M / 16), en comparación con el tamaño promedio del bloque de memoria de solo unos 100 KB. Si el límite de gas de bloque se incrementa a 40 M, un atacante puede generar un bloque de memoria de aproximadamente 2,38 MB. Cuando el coste de los datos de llamada se incrementa 2,5 veces, la eficiencia del atacante se reducirá a un máximo de 0,72 MB para 30 M y 0,95 MB para 40 M, de modo que el límite de gas de bloque y el blob se puedan aumentar con más confianza. Sin embargo, este protocolo técnico no quiere afectar al usuario general que "no utiliza calldata para publicar datos", por lo que calculará el uso total de gas de la transacción de dos formas, la que sea mayor:
El impacto real será en Rollup de escala pequeña, ya que Blob tiene un tamaño y un costo fijo, por lo que el uso de Blob es menos eficiente para los Rollup pequeños. El uso de calldata es más rentable, pero después de EIP-7623, los costos de estos Rollup pequeños se incrementarán en un 2.5 veces. Es posible que tengan que cambiar a Blob o encontrar una forma de compartir un Blob juntos.
EIP-7691: Aumentar el rendimiento de blobs
EIP-7691 aumenta el número de blobs de "Destino: 3 blobs, máx.: 6 blobs" a "Destino: 6 blobs, máx.: 9 blobs" para aumentar el espacio para publicar más datos en resúmenes.
Nota: Además, hay algunos diseños en el mercado de tarifas de Blob que necesitan ser ajustados, como que la velocidad de ajuste de tarifas no es lo suficientemente instantánea y el piso de tarifas es demasiado bajo, pero esto no está en el problema que este protocolo técnico pretende resolver.
Otros protocolos técnicos
EIP-7549: Mover el índice del comité fuera de la validación
Ajustar el contenido de la votación de los validadores para facilitar la agregación de votos y reducir la presión sobre la red P2P.
Los validadores se asignan aleatoriamente a un grupo de comités y pares para cada época
En la votación por bloques de memoria, los votos de los validadores de cada comité se pueden sumar, lo que reduce el número de votos aprobados en la red P2P, pero los votos del validador contendrán información sobre el número de comités a los que pertenece el validador, lo que significa que los votos de diferentes comités no se pueden agregar, incluso si todos votan en el mismo bloque de memoria.
EIP-7549 elimina la información de que el validador pertenece al primer comité del contenido de la votación, de modo que los validadores de diferentes comités se pueden agregar cuando el contenido de la votación es el mismo, lo que reduce aún más el número de votos aprobados en la red P2P y reduce la presión sobre la red P2P.
EIP-7840: Agregar plan de Blob al archivo de configuración EL
Cree un archivo de configuración para los parámetros de blob en la capa de ejecución, ahorrando al nodo de la capa de ejecución la molestia de preguntar al nodo de la capa de consenso los parámetros relacionados con los blobs.
Actualmente, todos los parámetros relacionados con Blob se almacenan en los nodos de la capa de consenso, pero los nodos de ejecución aún necesitan estos parámetros en algunas situaciones (por ejemplo, RPC eth_feeHistory), por lo que deben consultar a los nodos de la capa de consenso.
EIP-7840 crea un archivo de configuración para los parámetros relacionados con blobs en la capa de ejecución, y los nodos de la capa de ejecución pueden leer directamente los parámetros relacionados con blobs a través de este archivo de configuración sin tener que preguntar a los nodos de la capa de consenso.