jakiro
El objetivo de este artículo es describir el equipo del paradigma Reth[4]Para la bifurcación dura de Praga, Praga es la próxima bifurcación de El Hard Fork después de Cankun, y la descripción general de nuestro plan 2024 «El Core Development».Los siguientes puntos de vista están en desarrollo, y solo la visión actual del equipo Reth no representa necesariamente un equipo de paradigma más amplio.
Creemos que la bifurcación dura de Praga se puede lograr en la red de pruebas Ethereum en el tercer trimestre de 2024, y se logrará en la red principal a fin de año.
Debe incluir:
Cualquier EIP relacionado con la compromiso, como EIP-7002, hace posible el estanque de re-estancamiento y no controlador.
Cambios de EVM independientes.
Estamos dispuestos a cooperar con cualquier equipo que queramos estudiar más a Praga u otras divisiones duras de EL Future El, y estar dispuestos a guiar o proporcionar orientación para modificar la ubicación de la biblioteca Reth Code.
apoyo:
Creemos que el siguiente EIP debe tener prioridad: 7002[5], 6110[6], 2537[7]Esencia
Apoyamos el EOF, como las especificaciones[8]En esto, espero determinar el alcance lo antes posible y crear un meta -eIP para prometer cumplir con el alcance.
Estamos dispuestos[9]Versión.No tenemos opinión sobre las cifras correctas, pero invitamos al personal de datos a cooperar con nosotros para investigar este problema.
Estamos dispuestos a publicar EIP-7547: incluir listas[10]La versión para ayudar a la capa básica anti -revisión.
No compatible:
No admitimos usar Verkle intentos en Praga[11]Sin embargo, apoyamos al equipo del cliente para lograrlo desde el segundo trimestre de 2024, y prometemos ser lanzados en Osaka a mediados de -2025 a mediados de -2025.
No creemos que el límite de gas de ejecución de L1 o el tamaño del contrato se incrementen, pero invitamos al personal de datos a cooperar con nosotros para investigar el impacto en la red.Estamos dispuestos a modificar nuestras vistas, porque las pruebas pasadas muestran que el nodo Reth puede manejar el aumento de la carga sin problemas.
Creemos que la billetera/abstracción de la cuenta EIP requiere más pruebas de confrontación mutua para comprender mejor el espacio de equilibrio.Si no son mutuamente excluyentes, entonces estamos dispuestos a implementar múltiples EIP relacionados con AA en el futuro.
Si la comunidad está en el rumor[12]NSA[13]Puerta trasera[14]Ok, podemos aceptar EIP-7212 (SECP256R1).
Otros temas de mapa de ruta: no tenemos vistas específicas sobre el acoplamiento de CL EIP o CL/EL Splits, sino EIP 7549[15]Y 7251[16]Parece muy prometedor.También esperamos contribuir al trabajo de Peerdas tanto como sea posible en El.Esperamos evitar temporalmente la introducción de raíces SSZ (EIP 6404, 6465, 6466).Finalmente, notamos la oportunidad de proporcionar soluciones de archivo de datos a largo plazo para la blob, el historial y el estado vencidos, porque EIP-4844[17]Y EIP-4444[18]No se especifica nada y si Ethereum está dispuesto a proporcionar dicha solución.
El siguiente es razonamiento.
apoyo
Resumen, apoyamos 1) la brecha entre CL y EL adicional, 2) La modificación EVM puede realizarse como un trabajo de una sola persona, y puede estar de forma aislada y paralela.
EIP-7002[19]
Este EIP desbloqueó la piscina replicada y de compromiso controlando el lado CL controlando el lado CL del lado CL.Desde nuestra perspectiva, este es un EIP en el que no necesita pensar, porque al menos permitirá que el grupo prometido existente elimine una capa de centralización del contrato inteligente que implementa su retiro.
La introducción de la pre -compilación del estado en la implementación de EVM es una nueva abstracción que necesitamos capturar en la implementación de EVM, pero además, creemos que este es un EIP que puede ejecutarse directamente.
EIP-6110[20]
Este EIP introduce depósitos en el Estado EL, que simplifica la gerencia estatal necesaria en el CL.En términos de implementación, esto es similar al rastrear la retirada de CL, por lo que en general, creemos que esto también es un EIP que es fácil de lograr e independiente.
EIP-2537[veintiuno]
Ahora hay múltiples implementación BLS12-381 afuera.Creemos que la complejidad es baja, ya que solo revela el algoritmo de verificación de la curva a través de la interfaz previa a la compilación.Tal vez también queremos una compilación previa de un hash a la curva BLS12-381.
EOF[Veintidós]Formato de objeto Ethereum
TL;Es algo que facilita analizar el formato de código y el ajuste de verificación.
beneficio:
Solo los cambios EVM pueden ser probados por Ethereum/Tests e implementados por una persona.
¡Haga los cambios EVM que desea Vyper y Solidity!
Ayuda al rendimiento y a mejorar el tamaño del contrato.
EVM elimina las necesidades del análisis de bytecode durante el tiempo de ejecución.
Se puede cargar parcialmente para ayudar a ejecutar grandes contratos.
DEVEX: Se permitirá usar DUPN/SWAPN para reparar «apilar demasiado» y otras herramientas en solidez.
Verificación futura: puede introducir nuevas características de manera segura en L2, y las herramientas sabrán qué es la compatibilidad.
insuficiente:
Cambiar el objetivo.
Ningún seguidor ha tratado de promover su adición.
Todavía necesita admitir el código anterior
Hasta la adopción, habrá diferencias temporales entre la red principal de Ethereum y otras cadenas EVM.
Creemos que las siguientes funciones de EOF deben implementarse en 2024.Recomendamos determinar el alcance lo antes posible y prometemos observar.Cualquier otra cosa debe considerar la implementación posterior.Nuestras sugerencias:
EIP -3540: EOF -EVM Formato de objeto V1[veintitrés]: Introducir contenedores de código y datos, y agregue estructuras y versiones a Ethereum bytes.
EIP -3670: verificación EOF -Code[Veinticuatro]: Reche los contratos que no sigan el formato EOF durante la implementación.Código obligatorio y más estructurado y deshabilitar las instrucciones inválidas e ingracidas.
EIP-663: Instrucciones ilimitadas de intercambio y DUP[25]: Esto resuelve el problema de «pila demasiado profunda» en la solidez, y puede tener los efectos secundarios a través del análisis más probable como un valor momentáneo.El lenguaje EVM espera tener esa función de este tipo.
EIP -4200: EOF -JUNTO RELATIVO ESTÁTICO[26]: Mejor análisis estático, no hay un salto incierto.Mejor compilación AOT.Relajado al código para el código es mejor.
EIP -4750: EOF -Function[27]: Debe lidiar con las sub -rutinas que pueden tener un salto dinámico pero no tienen salto estático.También permite que se cargue algún código, que se usa bien con Verkle y agrega restricciones de tamaño de contrato.
EIP -5450: EOF -Prack Verification[28]: Verificar los requisitos de código y pila.Todas las instrucciones, excepto Callf (EIP-4750), han eliminado el desbordamiento de la pila y la inspección de la presentación durante el tiempo de ejecución.
EIP -7480: instrucción de acceso al segmento EOF -data[29]: Permitir el segmento de datos del código de byte.
EIP-7069: la instrucción mejorada de llamadas[30]: Haga que el gas en las llamadas desaparezca, para que el gas tenga un precio en el futuro.Aunque independiente de EOF, creemos que esta es una buena oportunidad para presentarlo.
WE TIP-6206: EOF-JUMPF y funciones no retornadas[31]De hecho, es bajo.Aunque permite la optimización de llamadas de cola en la función EOF, aún necesitamos ver el análisis del lenguaje de su utilidad.Si no tenemos esto, creemos que podemos eliminarlo de la gama e incluir actualizaciones de EOF posteriores.
Tendremos el presupuesto de trabajo anterior durante 1-2 meses, que es completado por 1 persona.Si esto significa mantener la motivación, estamos dispuestos a reducir aún más el alcance mencionado anteriormente.
Explicación de las bytas tradicionales:
Aunque podemos prohibir los nuevos bytecodes tradicionales/no -eOf, no puede abandonar el bytecodo tradicional existente.El bytecodo tradicional aún necesita realizar un análisis más probable después de EOF, y aún necesita un procesamiento de código especial para segmentarlo en los intentos de Verkle.
Hasta donde sabemos, no hay una conversión de verificación de no -EOF bytecode a EOF sin acceso a piezas de trabajo de origen, pero estamos dispuestos a investigar el mecanismo de promover esta conversión.
Alternativamente, estamos dispuestos a explorar el método de vencimiento de migrar el estado a EOF.
Aumente el número de blob EIP-4844
Estamos dispuestos a aceptar este cambio, que será correcto
Target_blob_gas_per_block y max_blob_gas_per_block se seleccionan como 3 blob (0.375 mb) para cada bloque, con un máximo de 6 blob (0.75 mb).Estas restricciones iniciales más pequeñas están diseñadas para maximizar la presión causada por el EIP a la red, y se espera que aumente la actualización futura para que la red pueda mostrar confiabilidad en bloques más grandes.*
De hecho, este es un pequeño cambio de código.La capa de consenso puede encontrar dificultades al difundir más Blob;
No apoyo
Verkle intenta[33]
TL;Recomendamos que el equipo asigne recursos en el segundo trimestre de 2024 y prometiera desplegarse en el segundo trimestre de 2025 al tercer trimestre de Osaka.
beneficio:
Se logra un cliente de luz más barato a través de una prueba de almacenamiento más pequeña.
Al darse cuenta de la ejecución apátrida por el estado previo al estado en el bloque del bloque, que también puede deberse al acceso al estado estático.
Aumente el límite del tamaño del contrato cargando el Bytecode y habilite parte del código.
Debido al bajo costo del estado de «resurrección», el estado se vuelve más atractivo.
insuficiente:
Gran carga de trabajo: el impacto, la implementación de integración y las pruebas de cambios.
Cambio de facturación de gas: Verkle intenta presentar al testigo de la función de cálculo de gas.Nos preocupa que los cambios en los precios de almacenamiento no se hayan explorado (por ejemplo, ¿cuál es el costo de los principales consumidores de gas después de Verkle)?
Integración de la aplicación: cuando se ejecuta la transición de superposición, ¿qué debe hacer la aplicación con el dispositivo de verificación Merkle Patricia Trie?
Aunque entendemos los beneficios de Verkle intentos, creemos que necesitamos más pensar para comprender cómo deben adaptarse las herramientas/contratos del tercer partido, y el impacto de la transición en la solución de la segunda capa.Inicialmente, éramos escépticos sobre la estrategia de migración porque estipulaba que Verkle Trie debería actualizarse al leer el estado del MPT existente, pero parece que este no es el caso ahora.Por lo tanto, apoyamos el método del árbol de superposición como una ruta de migración factible.
El documento de la estrategia de migración de Verkle parece estar generalmente desactualizado, porque la mayoría de los recursos aún señalan que Verkle Trie debe actualizarse al leer el estado de MPT, aunque la situación no es el caso.Esperamos ver la actualización clave del documento de transición al último método, como este excelente documento.[34]EsenciaTambién esperamos ver un borrador del EIP de estrategia de transición.
Por lo tanto, todavía apoyamos el lanzamiento de Verkle en 2025, pero no vimos la ruta de implementación en la actualización de Praga.
Límite de gas L1
Creemos que aumentar las restricciones de gas L1 desde la perspectiva de la demanda no tendrá mucho efecto en la práctica.También pensamos que la mayoría de los clientes pueden manejar el aumento en la carga promedio, pero esperamos estar atentos a la peor situación, por lo que no recomendamos aumentar el límite de gas L1 por el momento.Creemos que agregar un límite de gas Blob a corto plazo es una solución más prometedora.
Invitamos a todos a cooperar con nosotros para realizar cualquier investigación en esta dirección y la forma de medir la medición de recursos alrededor de EVM.Papel de medidor roto[35]Es un buen punto de partida en esta dirección de investigación.
Abstracción de la cuenta
Estamos dispuestos a incluir 1 o más EIP (o ERC de implementación de protocolo), pero esperamos ver más experiencia en la experiencia del usuario y la comparación de la experiencia de desarrollo para comprender mejor el trabajo de pesaje y la integración de herramientas de cada propuesta.Estamos prestando atención al siguiente EIP/ERCS, pero sugiértanos en cualquier momento:
EIP-3074: Auth y authcall Opcodes[36]
ERC-4337: Abstracción de la cuenta utilizando Alt Mempool[37]
EIP-5806: transacción delegada[38]
EIP-5920: Page Opcode[39]
EIP-6913: Instrucción SetCode[40]
EIP-7377: Transacción de migración[41]
RIP -7560: Abstracción de cuenta nativa -Corte EIPS -Fellowship of Ethereum Magicians[42]
Queremos explicar que en el contenido anterior, la «abstracción de la cuenta» se refiere a la «función de verificación abstracta, el objetivo principal es habilitar la rotación clave, hacer de múltiples firmas una función de primera clase y proporcionarnos una ruta automática de resistencia cuántica «(H» /T VB), solo adecuado para 4337 y 7560, mientras que otras propuestas se dividen en dos categorías, a saber, el patrocinio de gas y el procesamiento por lotes de operaciones.
autor:
>
Georgios Konstantopoulos[43]
Georgios Konstantopoulos es el director de tecnología y socio de investigación de Paradigm, centrándose en la investigación de la cartera de inversiones de Paradigm y el protocolo de código abierto.Anteriormente, Georgios era un consultor e investigador independiente.
