Introducción a Ethereum Pectra Hard Fork

Autor: Nic Lin, Medio

Se espera que la bifurcación dura de Pectra inicie la implementación de Mainnet en marzo de 2025.La actualización de Pectra contiene 11 protocolos técnicos (EIP), que son:

• EIP-2537: BLS12-381 Curva Operación Precompilación

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

• EIP-6110: proporcionar depósitos de validador en cadena

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

• EIP-7251: Se agregó el max_Effective_balance

• EIP-7549: mueva el índice del comité fuera de la verificación

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

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

• EIP-7691: aumentar el rendimiento de la blob

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

• EIP-7840: Agregar planes de blob a los archivos de configuración de El

Acuerdos técnicos relacionados con el compromiso

EIP-6110: BLS12-381 Curva Operación Precompilación

Simplifique el proceso de usuarios que participan en la compromiso y acortan en gran medida el tiempo de espera.

La forma en que los usuarios participan en la participación es depositar 32 ETR en la capa de ejecución y grabarlos por el registro de eventos (registro de eventos). En la referencia se convierte en el verificador.

Sin embargo, los validadores de la capa de consenso primero deben llegar a un consenso en el que se depositará en el tiempo. Depósitos, mientras que algunos validadores solo verán 3. Votaremos sobre qué bloqueo de la capa de ejecución (ETH1DATA) a los que queremos referirnos para garantizar que veamos el mismo bloque de capa de ejecución.

Sin embargo, para evitar errores importantes en la capa de ejecución que causa horquillas de cadena, el bloque de la capa de ejecución de referencia (ETH1DATA) será un bloque de capa de ejecución hace aproximadamente 10 horas, asegurando que cuando ocurra un error importante, los desarrolladores de la capa de consenso tienen Basta de tiempo para responder, pero esto también lleva al hecho de que tienen que esperar más de 10 horas para entrar en vigencia lo antes posible.

△ El 10900000 Eth1Data en el bloque CL, el hash de bloque registrado en él es el bloque de la capa de ejecución 216833339, que apareció hace 10 horas.

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. No tiene que considerar el problema de «confirmar que los bloques de memoria de la referencia de la capa de ejecución son los mismos». Ver la misma ejecución.Por lo tanto, después de que el usuario participa en la referencia, el bloque de memoria de la capa de ejecución puede entrar en vigencia después de que la capa de ejecución se completa dentro de los 13 minutos en el momento más rápido, y el cliente de la capa de consenso también puede eliminar la lógica compleja que se usó originalmente para procesar el Datos de replanteo.

EIP-7002: Guardar el valor del hash de bloque histórico en el estado

Se puede utilizar para mejorar el proceso para que los verificadores salgan de compromiso o retiren depósitos y beneficios, y reduzcan el riesgo de verificadores.

Participar en el replanteo requiere dos claves, a saber, la clave de validador y la credencial de retiro.

La clave de validador se utiliza para el contenido de trabajo del verificador, y la credencial de retiro se usa para la dirección donde el depósito y el ingreso se retirarán cuando el verificador salga de la estaca.

Si se pierde la clave de validador, el trabajo del verificador no se puede realizar y el replanteo no se puede retirar;Además, algunos usuarios utilizarán servicios de replanteo de terceros como LIDO. verificador.

Ejecute el acuerdo técnico EIP-7002, y los usuarios pueden usar la credencial de retiro para llamar al «contrato de retiro» (es decir, implementado en 0x0c15f14308530b7cdb8460094bbbb9cc28b9AAAAA) para salir de la participación (salida) o retirar los depósitos e ingresos (retiros parciales) y reducir el uso de el tercer uso de la tercera- estacas de la fiesta.Si el usuario participa en la promesa por sí mismo pero pierde la clave de validador, también puede usar esto para salir de la promesa.

• Los parámetros para iniciar la solicitud incluyen validator_pubkey y cantidad: Validator_pubkey es la clave de validador (pública) del validador, y la cantidad es el número que se recopilará.

• La credencial de retiro que inició la solicitud debe ser la credencial de retiro del validador Validator_PubKey.

• Al llamar al contrato de retiro para iniciar una solicitud, la tarifa de gas (ETH) debe adjuntarse.

• Si la credencial de retiro del usuario es un contrato, primero puede ir al contrato de retiro para obtener la tarifa de transacción actual, y luego iniciar una solicitud y adjuntar la tarifa de transacción; Los resultados precisos.

Nota: Si su credencial de retiro todavía está en formato de clave pública BLS, recuerde cambiarlo primero y cambiarlo al formato de dirección EL.

EIP-7251: Se agregó el max_Effective_balance

Puede aumentar significativamente el límite superior de la cantidad de compromiso para reducir el número de validadores, y los verificadores que no alcanzan el límite superior pueden disfrutar automáticamente del ingreso de la promesa.

Apuestas de usuario para convertirse en verificadores para proporcionar a Max_Effective_Balance con el número de ETH, que no puede ser menor o más (actualmente max_eFfective_balance es 32 ETH).Si el usuario posee 1024 ETH para que se estote, puede participar en la estaca en 32 veces, habilitar 32 validadores y ejecutar 32 nodos de validador.Y la participación activa de todos en el replanteo también ha llevado al aumento continuo de aproximadamente 1 millón de validadores. Porque cada una ranura (cada 12 segundos) tiene decenas de miles de firmas de autenticador para ser continuamente aprobados y agregados en la capa de red P2P.

Después de ejecutar el acuerdo técnico EIP-7251, el límite inferior de la promesa (min_activation_balance) sigue siendo 32 ETH, pero el límite superior (Max_Effective_Balance) se incrementará en gran medida a 2048 ETH. Puede obtener ingresos de compromiso.

En la actualidad, los verificadores existentes no necesitan salir de la estaca primero y luego fusionarse y volver a unir la estaca. a la verificación de retiro de crendencial Vaya al contrato de llamada para iniciar una solicitud de depósito fusionado.

• Los parámetros de la solicitud de depósito fusionado incluyen Source_PubKey y Target_PubKey: estas dos claves son claves de validador del verificador, y el verificador de origen se fusionará en el verificador de destino.

• La credencial de retiro que inició la solicitud debe ser la credencial de retiro del verificador de origen.

• Al llamar al contrato de depósito fusionado para iniciar una solicitud, debe adjuntar una tarifa de manejo (ETH).

• Si la credencial de retiro del usuario es un contrato, primero puede llamar al contrato de depósito fusionado para obtener la tarifa de transacción actual, y luego iniciar una solicitud y adjuntar la tarifa de transacción; Las tarifas de manejo precisas solo se pueden simular fuera de la cadena por adelantado y pagar las tarifas de manejo excesivas (sin reembolso) para garantizar que la solicitud se ejecutará con éxito.

Nota: Si su credencial de retiro es un formato de clave pública BLS, debe cambiarlo primero y cambiarlo al formato de dirección EL.

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

Establecer una tubería de información formal de El -& GT;

Los usuarios pueden enviar solicitudes directamente desde la capa de ejecución a la capa de consenso, y los servicios de replanteación (como LIDO) pueden ejecutarse de manera más descentralizada.Por ejemplo, la solicitud de la participación de EIP-7002 mencionada anteriormente y la solicitud del depósito consolidado de EIP-7251.Si este acuerdo técnico no está disponible, los usuarios de LIDO deben creer que el proveedor de servicios del nodo LIDO realmente ejecutará el depósito de estaca o fusionar a la capa de consenso; .

Estas solicitudes tendrán un tipo de solicitud para distinguir diferentes tipos de solicitudes e iniciar solicitudes a través de diferentes contratos. No hay necesidad de escribir lógica de análisis individual.

EIP-6110, EIP-7002 y EIP-7251 hacen todas las solicitudes basadas en estándares definidos por EIP-7685:

• EIP-6110 Une la solicitud de compromiso: Tipo de solicitud = 0, a través del contrato de depósito

  (0x00000000219AB540356CBB839CBE05303D7705FA) Inicie la solicitud.

• Solicitud de compromiso de salida EIP-7002: Tipo de solicitud = 1, a través del contrato de retiro

  (0x0c15f14308530b7cdb8460094bbb9cc28b9aaaaa) inicie la solicitud.

• Solicitud de depósito de consolidación EIP-7251: Tipo de solicitud = 2, a través del contrato de consolidación

  (0x00431F263CE400F4455C2DCF564E53007CA4BBBB) inicia la solicitud.

Acuerdo técnico para mejorar la experiencia del usuario

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

Deje que la cuenta EOA se transforme en una cuenta de contrato a voluntad, mejorando enormemente la experiencia del usuario.

Algunas deficiencias en el uso de cuentas de EOA incluyen:

• Las claves privadas o las palabras mnemónicas deben grabarse y mantenerse, lo que tiene un umbral alto para que los nuevos usuarios se registren y usen.

• Una transacción de cuenta EOA solo puede realizar una operación.

• Control de permiso no refinado, como entregar ciertas operaciones en la cuenta a un tercero para operaciones, los usuarios deben manejar personalmente cada tarea y firmar y emitir transacciones para cada operación.

• Sin un mecanismo de recuperación, solo puede mantener su propia clave privada o palabras mnemónicas, y si lo pierde, nunca volverá a obtener los activos en la cuenta.

Si se trata de una cuenta de contrato inteligente (como seguro), entonces todos los problemas anteriores se pueden resolver:

• Los usuarios pueden firmar y autorizar con la clave privada en el chip de seguridad de su teléfono móvil (o computadora).

• Las operaciones múltiples se pueden completar juntas en la misma transacción.

• Puede haber un control de permisos muy detallado, y los usuarios pueden autorizar a terceros a controlar sus propias cuentas, pero al mismo tiempo especificar «en qué contrato se puede interactuar», «qué operaciones no se pueden realizar», «solo hay otras involucradas Transferencias de activos.

• Se puede agregar un nuevo mecanismo de recuperación, y los activos de la cuenta se pueden transferir a una nueva cuenta a través del mecanismo de recuperación cuando pierde las palabras de su asistente, teléfono móvil o correo electrónico.

La propuesta EIP-7702 es dar a las cuentas EOA la capacidad de transformarse en cuentas de contrato.El usuario usa la clave privada EOA para firmar el mensaje transformado.

• ID de cadena: se usa para evitar que la firma de la cadena A se lleva a la cadena B y se repite.Sin embargo, si la ID de cadena se completa en 0, significa que está dispuesto a transformarse en cada cadena.

• La dirección del contrato en la que desea convertirse: si completa una dirección de contrato segura, su cuenta EOA se convertirá en un contrato seguro; De vuelta la cuenta EOA simple.

• Valor Nonce de EOA: se utiliza para evitar que se reproduzcan firmas.Si el valor de nonce aumenta, la firma original no será válida.

Sin embargo, hay algunos puntos a tener en cuenta:

1. La clave privada EOA también se puede usar

Incluso si la cuenta EOA del usuario se convierte en un contrato, aún puede continuar usándola en la cuenta EOA original.Su cuenta, 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 todavía se limita a esa clave privada.

2. Sigue siendo la seguridad de las claves privadas de EOA

Incluso si el EOA del usuario se convierte en una firma múltiple, siempre que no tire la clave privada de EOA, su seguridad de cuentas siempre será la seguridad de la clave privada de la EOA: todavía necesita mantener bien su clave privada o las palabras mnemónicas , él la cuenta no se volverá tan segura como múltiples señales.

3. El almacenamiento de la cuenta EOA no se formateará

Cuando una cuenta de EOA se transforma en un contrato y escribe datos en su almacenamiento, a menos que la acción de eliminar datos se realice explícitamente, los datos escritos en el almacenamiento no se transformarán en otro contrato ni se cancele porque la cuenta EOA se transforma en un contrato o se transforma En un contrato cancelado a menos que la acción de eliminar datos se realice explícitamente.

4. El proceso de EIP-7702 no incluye la inicialización

En general, las cuentas de contrato requieren un paso de inicialización, que sincroniza la información del propietario de la cuenta (como la clave o la dirección pública) al implementar la cuenta, para evitar el paso de implementación que se retira (frontrun) y pierde la propiedad de la cuenta.Esto generalmente es realizado por el contrato de fábrica que implementa la cuenta del contrato para realizar «implementación + inicialización», pero debido a que EIP-7702 se cambia directamente, en lugar de una fábrica implementa el contrato al EOA, el atacante puede copiar la transformación y el signo del usuario y envíe las transacciones primero al enlace para transformar al usuario, pero inicialice la cuenta para ser controlada por el atacante, por lo que los desarrolladores deben prestar atención al EIP-7702.Posibles métodos de prevención, como verificar la firma de la cuenta EOA dentro de la función de inicialización, de modo que incluso si se retira, el atacante no podrá generar la firma de la cuenta EOA para completar la inicialización.

5. La billetera necesita verificar los cambios

La billetera debe verificar el usuario, detener la solicitud y advertir al usuario cuando el sitio web de DAPP malicioso solicite al usuario que firme una transacción de transformación.Aquí hay algunos ejemplos de implementación del contrato de transformación:

• Cuenta Ithaca segura modificada

• Cuenta de Ithaca

Acuerdo técnico DAPP

EIP-2537: BLS12-381 Curva Operación Precompilación

Hacer que el costo de la aplicación a prueba de conocimiento cero basada en las curvas BLS sea más factible.

EIP-2537 ha agregado varios contratos precompilados (precompilos) para proporcionar operaciones de curva BLS baratas, por lo que será más factible desarrollar aplicaciones a prueba de conocimiento cero basadas en curvas BLS.

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

Permite a los desarrolladores o nodos leer el valor hash de los bloques de memoria pasados ​​directamente desde el almacenamiento del contrato del sistema.

Si el desarrollador necesita probar el contenido de un bloque de memoria anterior, por ejemplo, suponga que el desafío de fraude de Optimismtic Rollup tiene que demostrar que hay una transacción en 1,000 bloques de memoria anteriores, el retador no puede decirlo directamente.

«Cree que esta transacción realmente existía en 1000 bloques de memoria antes». El método de «cadena» del bloque es probar un bloque de memoria un bloque de memoria hacia adelante hasta alcanzar 1,000 bloques de memoria anteriores, y luego demostrar que la transacción existe en el bloque de memoria.

△ Cada bloque apuntará a un bloque principal, por lo que puede probar cualquier bloque en la historia a seguir.

Suponiendo que actualmente es un bloque de memoria numerado 10000, y el desafío de fraude debe proporcionar una prueba de que una transacción X existe en un bloque de memoria numerado 9000, el Challenger debe comenzar con el valor hash del bloque de memoria de 10000 primero demuestra que la memoria El bloque es 10000. El valor hash del bloque de memoria principal conectado 9999, y luego pruebe el bloque de memoria 9998 … hasta que el bloque de memoria 9000, y finalmente el contenido del bloque de memoria 9000 contiene la transacción X.

Después de EIP-2935, habrá un contrato del sistema (implementado en 0x0f792Be4B0C0CB4DAE440EF133E90C0ECD48CCCC), y su almacenamiento almacenará hasta 8192 valores de hash de bloques de memoria anteriores.Cada vez que se genera un nuevo bloque de memoria, el contrato del sistema se actualizará automáticamente y el valor hash del bloque de memoria anterior se escribe en el contrato del sistema (el valor hash de 8192 se copiará bloques de memoria anteriores).

De esta manera, en el ejemplo de un desafío de fraude optimista de fraude, el Challenger no tiene que demostrarlo lentamente en el bloque de memoria anterior y un bloque de memoria, pero puede demostrar directamente que el estado de cadena actual del bloque de memoria 10,000 es un determinado sistema Contrato.Si el rango excede 8192, como el bloque de memoria 1000, entonces, a lo sumo, un paso es probar el valor hash del bloque de memoria 1808 (= 10000 – 8192), y luego demostrar que el bloque de memoria 1808 está en el estado de la cadena actual, en el estado de la cadena actual, en el Sistema Contrato hash Valor del bloque de memoria 1000.

Esto también allana el camino para el futuro cliente sin estado: los nodos de luz futuros ya no necesitan almacenar todos los bloques de memoria en el historial, sino que use una determinada parte del historial cuando sea necesario usarlo. De un bloque de memoria, solicite a otros que proporcionen pruebas utilizando el método de prueba en el ejemplo de desafío de fraude anterior.

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

Aumente el costo de usar CallData para publicar datos para desviar suficiente espacio de seguridad para aumentar el número de límite de gas de bloque y blobs.

A medida que la demanda de liberación de datos de Rollup se vuelve cada vez más alta, después de introducir blobs en EIP-4844 para permitir que el rollup coloque datos de una manera muy barata, aumentar el número de blobs siempre ha sido una actualización que la comunidad espera. Por la comunidad para aumentar el límite de gas de bloque, refleja la necesidad de que la ecología aumente los recursos.

△ Más y más validadores dicen que apoyan el límite de gas de bloque.

Sin embargo, ya sea para aumentar el número de límite de gas de bloque o las blobs, ejercerá más presión sobre la red P2P de Ethereum porque el volumen de transacción se hace mayor, lo que aumentará la eficiencia del ataque del atacante a menos que los datos se publiquen. también aumentan.

Después de la liberación del protocolo EIP-7623, el costo de los datos de llamada se incrementará 2.5 veces desde el original «Byte cero: 4 gas, byte distinto de cero: 16 gas» a «byte cero: 10 gas, byte distinto de cero : 40 gas «.

Originalmente, si el atacante usó todo el límite de gas de bloque (30 m) para poner datos basura, el tamaño de los datos del bloque de memoria fue de 1.79 MB (30m / 16), que era de solo 100 kb en comparación con el tamaño promedio del bloque de memoria; El límite de gas se eleva a 40 m, el atacante puede generar un bloque de memoria de aproximadamente 2.38 MB.Cuando el costo de los datos de llamadas se incrementa a 2.5 veces, la eficiencia del atacante disminuirá, convirtiendo a 30 m máximo de 0.72mb y 40 m máximo 0.95mb, por lo que puede aumentar el número de límite de gas de bloque y blobs con más confianza.Sin embargo, este acuerdo técnico no quiere afectar a los usuarios ordinarios que «no usan CallData para publicar datos», por lo que calculará el uso total de transacciones de gas de dos maneras y luego tomará uno más alto:

1. El método de cálculo de uso de gas comercial original se calcula con el antiguo costo de llamada de llamada: es decir, los días de llamada se calculan en forma de «byte cero: 4 gas, byte distinto de cero: 16 gas», y la ejecución de la transacción se consume. y gas consumido por la implementación de contratos.

2. Simplemente calcule la cantidad de gas de llamada de llamada, pero se calcula con un nuevo costo: es decir, calcule los datos de llamadas en forma de «byte cero: 10 gas, byte distinto de cero: 40 gas», pero no cuenta el gas consumido por La ejecución o el gas consumido al implementar el contrato. Un nuevo costo.

El que realmente se ve afectado será el pequeño rollup, porque los blobs son de tamaño y costos fijos, por lo que el rollup pequeño es ineficiente para usar blobs, y es más rentable usar CallData. El costo de estos pequeños rollups será igual.

EIP-7691: aumentar el rendimiento de la blob

Aumente el número de blobs y aumente más espacio para publicar datos en rollo.

EIP-7691 aumenta el número de blobs de «Target: 3 blobs, límite superior: 6 blobs» a «objetivo: 6 blobs, límite superior: 9 blobs», agregando más espacio para publicar información a la rata.

Nota: Además, hay algunos diseños en el mercado de tarifas de blob que deben ajustarse, como la velocidad del ajuste de la comisión no es inmediata y el límite de tarifa mínima es demasiado bajo, pero esto no está en el problema de que esto El acuerdo técnico debe resolver.

Otros acuerdos técnicos

EIP-7549: mueva el índice del comité fuera de la verificación

Ajuste el contenido de la votación de validador para hacer que los votos sean más convenientes para agregar y reducir la presión sobre la red P2P.

Los verificadores serán asignados aleatoriamente a un grupo de comités y

La votación del bloque de memoria, las boletas de los validadores de cada comité se pueden agregar juntos, lo que puede reducir el número de votos aprobados en la red P2P, pero las boletas del verificador incluirán «cuántos comités pertenece el verificador a» la información que causó la información que causó la información que causó la información que causó la información que causó la información que causó la información que causó la información que causó Los votos de diferentes comités no pueden agregarse incluso si todos votaron en el mismo bloque de memoria.

EIP-7549 elimina la información de «a qué comité pertenece este verificador» del contenido de votación, de modo que los verificadores de diferentes comités pueden agregarse junto con el mismo contenido de votación, reduciendo aún más los votos en la red P2P el número de transmisiones reducido a la presión de la red P2P.

EIP-7840: Agregar un plan de blob en un archivo de configuración de El

Establezca un archivo de configuración para los parámetros BLOB en la capa de ejecución, eliminando el problema del nodo de la capa de ejecución solicitando los parámetros relacionados con el blob del nodo de la capa de consenso.

Los parámetros relacionados con Blob se almacenan actualmente en los nodos de capa de consenso, pero los nodos de capa de ejecución aún necesitan estos parámetros (como RPC ETH_FEEHistory), por lo que deben preguntarse desde los nodos de la capa de consenso.

EIP-7840 establece un archivo de configuración para parámetros relacionados con Blob en la capa de ejecución.