Título original: "Actualización 014 de la reunión de desarrolladores de Ethereum Core"
Fuente original: Actualización de AllCoreDevs
Autor original: Tim Beiko
Compilación original: Ethereum.cn
Bienvenido a una nueva edición de la actualización AllCoreDevs (Ethereum Core Developer Conference), la última de 2022.
descripción general
El contenido de la actualización Shanghai/Capella está ultimado: retiradas, EOF y algunas modificaciones menores... siempre que no retrasen las retiradas.
Se acerca el espacio Blob: EIP-4844 estará en el centro de la próxima actualización de Ethereum y su ceremonia de convocatoria comenzará pronto.
En el aspecto técnico, se están realizando esfuerzos para coordinar los procesos de actualización de la capa de ejecución y la capa de consenso. También estamos viendo discusiones activas sobre cómo incorporar mejor los aportes de la comunidad al proceso.
Protocol Guild ha publicado un informe piloto de mitad de período y un plan aproximado para ampliar el tamaño de los mantenedores de primer nivel y brindarles un mejor soporte en 2023.
Actualización de Shanghái/Capella
En una reciente reunión AllCoreDevs, el equipo del cliente llegó a un consenso sobre el alcance final de la actualización de Shanghai/Capella. Si bien el nombre de la actualización puede ser objeto de debate, el equipo tiene claro su alcance. La característica principal de la actualización es la introducción de retiros de Beacon Chain para los apostadores. Implementar esta función lo más rápido posible es algo en lo que el equipo del cliente no quiere comprometerse, por lo que otras funciones de la actualización deben estar listas al mismo tiempo o corren el riesgo de ser abandonadas.
La Especificación de capa ejecutiva de Shanghai enumera todos los EIP incluidos:
EIP-3540: Formato de objeto EVM (EOF) v1
EIP-3651: Reducir el costo del gas para acceder a direcciones COINBASE
EIP-3670: EOF - Verificación de código
EIP-3855: Código de operación agregado PUSH 0
EIP-3860: limitar el tamaño del código de inicio e introducir la medición de gas
EIP-4200: EOF - salto relativo estático
EIP-4750: EOF - Importación de funciones
EIP-4895: retiros push de cadena de balizas como operación del sistema
EIP-5450: EOF - Verificación de pila
Aunque la lista es larga, se puede dividir en tres partes diferentes: mejoras menores, formatos de objetos EVM y retiros. A continuación, los presentaremos uno por uno:
Pequeñas mejoras
EIP-3651: Warm COINBASE (reduce el costo del gas para acceder a las direcciones COINBASE)
Este EIP corrige un descuido en EIP-2929 donde el costo del gas para acceder a ciertos campos de datos se modificó en función de si los datos ya estaban en la memoria del cliente (CALIENTE) o debían recuperarse del disco (FRÍO).
EIP-2929 establece dos datos en la memoria del cliente en WARM al comienzo de cada transacción: la dirección de envío y la dirección de recepción. EIP-3651 agrega una tercera dirección a esta lista, la dirección COINBASE (es decir, feeRecipient), ya que también es la dirección que el cliente tiene en la memoria cuando procesa transacciones en bloque.
EIP-3855: instrucción PUSH 0 (nuevo código de operación `PUSH 0)
Como sugiere el nombre, EIP-3855 introduce un código de operación que inserta un valor de 0 en la pila. Empujar 0 se usa a menudo para completar valores en el EVM; este código de operación proporcionará una forma más eficiente y económica de hacerlo.
EIP-3860: Limitar y medir el código de inicio (limitar el tamaño del código de inicio e introducir la medición de gas)
Este EIP agrega un límite al tamaño del código de inicio e introduce la medición de gas en función de su longitud. Su límite de tamaño superior agrega una invariante al EVM, lo que facilita su comprensión y propuesta de modificaciones.
Introduce una sobrecarga de 2 gases por 32 bytes para el código de inicio, que se utiliza para pagar el análisis de salto que el cliente debe realizar antes de la ejecución, que no figura en el medidor de gas.
formato de objeto
La mayor parte del EIP incluido en la actualización de Shanghai es en realidad parte de una única característica: el formato de objeto EVM (EOF). El trabajo se dividió en cinco EIP diferentes para ayudar a los desarrolladores de clientes a comprender cada modificación individual, pero para brindar una descripción general de nivel superior, los desarrolladores publicaron una especificación unificada. Los EIP de estos cinco EOF son:
EIP-3540: formato de objeto EVM versión 1
EIP-3670: EOF - Verificación de código
EIP-4200: EOF - salto relativo estático
EIP-4750: EOF - Importación de funciones
EIP-5450: EOF - Verificación de pila
Vale la pena señalar que el primer paso de EOF fue la actualización de Londres EIP-3541, que reservó el prefijo 0xEF 00 para el contrato EOF. El alcance del EOF de la actualización de Shanghai también ha cambiado en los últimos meses.
En febrero, el equipo del cliente acordó considerar la actualización en Shanghai para incluir los dos EOF EIP más pequeños: EIP 3540 y 3670. Todos servirán como componentes básicos, pero no brindarán una funcionalidad completa sin la introducción de EIP 4200, 4750 y 5450. Aunque es posible ampliar EOF, la incompatibilidad con versiones anteriores puede requerir una nueva versión. Debido a que los contratos anteriores a EOF o EOF con una versión específica siempre deben ser ejecutables, cada nueva versión de EOF significa que los desarrolladores del cliente deben mantener un nuevo conjunto de reglas de ejecución de EVM en paralelo con las reglas anteriores.
Antes de EOF, los clientes mantenían solo un conjunto de reglas EVM a la vez. El código base también admite reglas EVM anteriores, que se modifican con cada actualización de la red, pero una vez que llegan a la cabeza de la cadena de bloques, solo se deben aplicar las reglas más recientes. Después de implementar EOF, el cliente mantendrá dos conjuntos paralelos de reglas EVM, para que pueda ejecutar código en contratos EOF y no EOF. En otras palabras, el aumento de versiones de EOF aumenta el número de conjuntos de reglas EVM paralelas en lugar de consecutivas que deben mantenerse.
Con este fin, en los últimos meses, los equipos de clientes han comenzado a favorecer un enfoque de "gran EOF". De esta manera, aunque tienen que implementar conjuntos de modificaciones más grandes, la versión EOF durará más y reducirá la cantidad de "EVM paralelos" que deben mantenerse. Por lo tanto, los desarrolladores consideraron un "gran EOF" y finalmente lo incluyeron en la actualización de Shanghai.
Dicho esto, las características más grandes son obviamente más difíciles de implementar y probar, y el equipo no quiere que EOF retrase severamente los retiros de la cadena de balizas. Por lo tanto, si la implementación de EOF no se ha completado en enero y no pueden interoperar rápidamente entre sí, el equipo del cliente acepta trasladar EOF fuera de Shanghai para su actualización.
Con estos contextos en mente, presentemos ahora brevemente cada EOF EIP:
EIP-3540: Formato de objeto EVM (EOF) v1 (Formato de objeto EVM versión 1)
Este EIP introduce el "contenedor" al contrato EOF. Agrega etiquetas para distinguir las partes de código y datos del contrato y evita que se implementen contratos EOF que no se ajusten al formato. Esto garantiza que cualquier contrato EOF en la cadena seguirá un formato válido, lo que simplifica la interacción con estos contratos, así como el análisis estático de los mismos.
EIP-3670: EOF - Validación de código (EOF - Validación de código)
Sobre la base del contenedor introducido por 3540, EIP-3670 garantiza que el código en el contrato EOF sea válido o impide su implementación.
Esto significa que no se pueden implementar códigos de operación indefinidos en los contratos EOF, lo que tiene el beneficio adicional de reducir la cantidad de versiones de EOF que deben agregarse. Si se agrega un nuevo código de operación, las reglas de validación pueden simplemente cambiarse para habilitarlo y garantizar que ningún contrato EOF implementado haga referencia a él en su sección de código.
EIP-4200: EOF - Saltos relativos estáticos (EOF - Saltos relativos estáticos)
EIP-4200 presenta los primeros códigos de operación específicos de EOF: RJUMP, RJUMPI y RJUMPV, que codifican destinos como valores inmediatos firmados. Los compiladores pueden utilizar estos nuevos códigos de operación JUMP para optimizar la sobrecarga de gas porque eliminan la necesidad de realizar un análisis de salto en tiempo de ejecución, que es requerido por los códigos de operación JUMP y JUMPI existentes.
EIP-4750: EOF - Funciones (funciones introducidas por EOF)
EIP-4750 va un paso más allá que 4200: no permite el uso de códigos de operación JUMP y JUMPI y agrega alternativas para funciones que no se pueden copiar. Se implementa introduciendo secciones de funciones específicas en el código de bytes EOF. Estas funciones pueden saltar desde los nuevos códigos de operación JUMPF, CALLF y RETF respectivamente, y usarlos para llamar y regresar.
EIP-5450: EOF - Validación de pila (Validación de pila EOF)
Finalmente, EIP-5450 agrega otra verificación de validación para contratos EOF, esta vez en la pila. Este EIP evita que los contratos EOF implementen código que pueda provocar un desbordamiento insuficiente de la pila y, en algunos casos, un desbordamiento. Con este EIP, los clientes pueden reducir la cantidad de verificaciones de validación al ejecutar contratos EOF porque tienen mejores garantías en torno a las excepciones relacionadas con la pila.
Como experto no en EVM y muy centrado en EIP en sí, ¡no hay mucho que pueda decir al respecto! Si los lectores quieren aprender más sobre EOF, recomiendo los tweets relevantes publicados por clientes ligeros del equipo Geth y Leo del equipo Solidity.
Retirada de la cadena de baliza
Por último, pero no menos importante, la parte principal de "Shapella" (Nota del traductor: nombre colectivo de Shanghai/Capella) es la retirada de la cadena de balizas. Esta parte del cambio se describe en la especificación de la capa de consenso y en EIP-4895. Ahora existe una metaespecificación ligeramente desactualizada que une estos cambios.
A alto nivel, la mecánica de retiros es la siguiente:
Al proponer un bloque, el validador escanea linealmente el índice del validador para encontrar los primeros 16 validadores con credenciales 0x01, que deben cumplir una de las siguientes condiciones:
Tener un saldo superior a 32 ETH (es decir, haber acumulado recompensas del validador)
Son retirables (es decir, han salido completamente del conjunto de validadores)
El saldo es mayor a 32 ETH (es decir, se ha obtenido la recompensa del validador)
Es retirable (retirable, es decir, ha salido completamente del conjunto del validador)
A partir de estos, el validador creará una lista de retiros que se incluirán en su ExecutionPayload. Cada elemento de esa lista contiene lo siguiente:
El validador creará una lista de retiros a partir de estos validadores y la empaquetará en su ExecutionPayload. Cada elemento de la lista contiene lo siguiente:
WithdrawalIndex: índice de todas las transacciones de retiro que se han realizado; esto ayuda a distinguir retiros del mismo monto desde la misma dirección, el mismo validador.
ValidatorIndex: el índice del validador donde se elevó el saldo
ExecutionAddress: la dirección ETH de la capa de ejecución, a donde se deben enviar los retiros.
Monto: el monto enviado a ExecutionAddress, este monto se mide en gwei (no wei)
Los clientes de la capa de ejecución realizarán estos retiros después de que se ejecuten las transacciones al crear o procesar bloques. En otras palabras, los retiros se procesan de manera similar a como se registran las recompensas de prueba de trabajo y no compiten con las transacciones de los usuarios por el espacio del bloque.
Hay algunos otros detalles que vale la pena señalar:
Al procesar retiros, no hay diferencia en prioridad/orden entre "fondos completos" y "fondos parciales". Los retiros completos ocurren cuando un validador abandona el equipo de salida, mientras que los retiros parciales ocurren periódicamente, es decir, cuando se realiza un escaneo lineal del conjunto de validadores y se escanea el número de índice de un determinado validador.
Para que se procesen los retiros, los validadores deben usar credenciales 0x01, que están representadas por direcciones ETH. Solo se permiten las credenciales del par de claves BLS 0x00 cuando la cadena de balizas se conecta. Para iniciar un retiro, un validador con credenciales 0x00 deberá firmar un mensaje BLSToExecutionChange. Estos se activarán en la actualización de Capella. Se utilizará una variedad de herramientas para firmar este mensaje y los validadores pueden esperar soporte y tutoriales para estas herramientas.
El escaneo de validadores es por bloque. Si no hay 16 retiros para procesar después de escanear un subconjunto del conjunto de validadores, el validador dejará de escanear y el siguiente validador comenzará desde el último índice de validador escaneado.
Como de costumbre, habrá varias redes de prueba para desarrolladores y redes de prueba (¡tal vez incluso algunas redes de prueba nuevas!) para que los validadores ejecuten todo el proceso y solucionen cualquier problema antes de que la red principal entre en funcionamiento.
¡Shanghai/Capella no es la única mejora que avanza! El equipo de desarrolladores todavía está esperando la próxima actualización.
Actualización de Cancún
Dado que el contenido de la actualización de Shanghai ya está completo, muchos EIP (CFI) que fueron considerados para la actualización no han podido ingresar a la actualización de Shanghai. El equipo del cliente comienza a discutir qué EIP deberían considerarse para la próxima actualización: la actualización de Cancún (el nombre de la capa de consenso está por determinarse).
En términos de la capa de consenso, EIP-4844 se convirtió en el primer EIP escrito en la especificación después de la actualización de Capella. No existe (todavía) una especificación para la capa ejecutiva que pueda implementar este diseño, pero el equipo de la capa ejecutiva acordó seguir un camino similar y centrar EIP-4844 en la próxima actualización.
Siguiendo la convención de actualizaciones utilizando los nombres de las ciudades donde se llevó a cabo Devcon, se creó cancun.md, con EIP-4844 incluido oficialmente en la actualización.
Esta decisión se produjo en el último minuto de la última reunión de AllCoreDevs de 2022, por lo que no hubo tiempo para trabajar en otras propuestas. Los EIP que ingresaron a la actualización de CFI en Shanghai pero que al final no fueron incluidos fueron trasladados a la lista de CFI para la actualización de Cancún. También se abrió una publicación en el foro de Ethereum Magicians para discutir los EIP candidatos en Cancún. Las discusiones sobre el alcance de las mejoras en Cancún deberían comenzar en serio a principios del próximo año.
Ceremonia KZG
Otra cosa que esperamos relacionada con la actualización de Cancún es la Ceremonia KZG, que es un requisito de EIP-4844.
Este ritual generará la aleatoriedad necesaria para verificar la validez de los datos del blob. Para que se considere seguro, sólo es necesario que un participante sea honesto. En otras palabras, si todos los participantes menos uno se confabulan, todo el proceso es criptográficamente seguro.
La ceremonia comienza en enero y estará abierta a todos durante varios meses. Con un objetivo de 10.000 participantes, está previsto que sea la ceremonia más grande de este tipo hasta la fecha. Si quieres asegurarte de no perdértelo, ¡sigue a Trent Van Epps en Twitter!
Proceso de actualización posterior a la fusión
Como se mencionó en la actualización anterior, después de la fusión, coordinar el proceso de actualización de Ethereum en la capa de ejecución y la capa de consenso es una tarea importante. Desde una perspectiva de alto nivel, la capa de ejecución utiliza Yellow Paper y EIP para describir las modificaciones, mientras que la capa de consenso utiliza especificaciones ejecutables de Python.
El beneficio del proceso del nivel ejecutivo es que el EIP es bien conocido por la comunidad y tiene un formato que demuestra claramente el razonamiento detrás de la propuesta. Los libros amarillos con mucho contenido matemático junto con los EIP y la necesidad de volver a colocar las especificaciones en el contexto de cada EIP hacen que las especificaciones de la capa de ejecución sean difíciles de comprender y ampliar.
El problema con la capa de consenso es el contrario: tiene una especificación clara y comprensible en un único repositorio, pero los cambios no son tangibles y las propuestas quedan enterradas en otros RP públicos del repositorio.
Con la introducción de la especificación de la capa de ejecución de Ethereum, esperamos acortar esta brecha desde el lado de la capa de ejecución. Y, con algunas discusiones sobre el proceso, ¡podríamos lograr que EIP se introduzca en el proceso de la capa de consenso!
Dicho esto, a medida que se discutió y finalizó el alcance de la actualización de Shanghai, quedó claro que podría faltar otra parte del proceso: permitir a la comunidad expresar sus preferencias relativas por los cambios y participar en discusiones sobre todo el alcance de la actualización (en lugar de EIP individuales) Discuta esto en el lugar y hágalo parte de las decisiones de las reuniones de AllCoreDevs y de la capa de consenso.
Aún no está claro cómo será. ¡Me encantaría recibir sugerencias! – pero a medida que creció el número de partes interesadas involucradas activamente en los cambios de protocolo, al igual que el número de áreas afectadas por los cambios de la capa 1, quedó claro que necesitábamos algo.
Afortunadamente, no necesitamos empezar de cero. Ethereum Magicians existe desde hace años y sus reuniones fuera de línea, reuniones de grupo dedicadas o reuniones comunitarias pueden ser buenos puntos de partida para la expansión.
¡Espere más avances en este frente a principios de 2023!
Actualización del acuerdo del gremio
Con el piloto de Protocol Guild (PG) ahora a la mitad, han publicado un informe para ver cómo van las cosas y considerar cuáles son los próximos pasos para el proyecto.
Como recordatorio, PG es un mecanismo de financiación sin permiso para desarrolladores de clientes de Ethereum Layer 1, investigadores de protocolos y contribuyentes de apoyo (como usted).
Este mecanismo se centra en el individuo, no en la organización. En resumen, cada miembro es elegible para recibir una parte de los tokens del gremio, ponderados según cuánto tiempo han contribuido a Ethereum. La adición y eliminación de miembros se realiza al estilo Ethereum, basándose en un conjunto de estándares y un consenso aproximado dentro de PG. Luego, esta lista se colocará en cadena mediante el contrato dividido 0xSplit. Luego, el donante puede enviar fondos directamente a la dirección del destinatario o a un contrato de adquisición de derechos que libere fondos a la dirección del destinatario.
El informe provisional piloto se resume en este tweet. Aquí hay algunos aspectos destacados
El piloto recaudó 9,7 millones de dólares de organizaciones como Lido, Uniswap, ENS, NounsDAO y MolochDAO, así como de donantes habituales de particulares (¡gracias Tetranode!). ¡Gracias a todos los que hicieron esto posible!
PG tenía 90 miembros en el lanzamiento y ahora tiene 128, con 5 millones de dólares distribuidos entre ellos.
En promedio, cada miembro recibió $39,000, siendo el más bajo $13,000 y el más alto llegando a $79,000.
La arquitectura de PG está cambiando y admitirá L2 y eliminará la necesidad de múltiples firmas para actualizar los pesos.
Estos primeros resultados muestran que PG está funcionando según lo planeado: un mecanismo para distribuir una canasta de tokens a un grupo creciente y en proceso de incubación de contribuyentes de protocolo. Este proyecto no sería lo que es hoy sin el generoso apoyo de los donantes piloto.
De cara al futuro, ahora es el momento de ampliar el alcance de PG y aprovechar todo su potencial: proporcionar a los mantenedores de Ethereum una compensación competitiva y ajustada al riesgo. Lo más fácil de hacer aquí es que el proyecto done a PG desde el principio, como dijo Danny Ryan en el tweet de lanzamiento de PG.
La mayoría de las donaciones del piloto provinieron de grandes proyectos con grandes cantidades de financiación. Si Protocol Guild puede convencer a estos proyectos de que donen a PG desde el primer día, cuando sus tokens todavía sean realmente "inútiles", entonces los mantenedores de Ethereum pueden beneficiarse de toda la trayectoria ascendente de estos proyectos exitosos.
Cuando hay suficientes proyectos involucrados, los incentivos pueden mantener a los mejores talentos en acuerdos de mantenimiento en lugar de alejarlos.
Para respaldar este y muchos otros tipos de donaciones, PG necesitará una revisión tecnológica. La próxima versión admitirá L1 y L2 y reducirá aún más su huella de gobernanza en cadena.
Si usted es un proyecto que desea hacer una donación al Protocol Guild, comuníquese conmigo: ¡mis mensajes directos están abiertos!
Hacer un seguimiento
Así concluye el 2022... ¡Qué año tan extraordinario! ¡Hace tres meses ni siquiera estábamos fusionados! Ahora que Ethereum tiene pruebas de participación ejecutándose silenciosamente en segundo plano, la atención se ha desplazado a transacciones futuras.
Como todos regresan en enero, puede esperar:
Shanghai/Capella actualizó la red de pruebas para desarrolladores y la bifurcación en la sombra
La ceremonia del KZG se pone en línea
Discusiones en torno a Cancún y cómo debería evolucionar el proceso de actualización de la red para capturar mejor las preferencias de la comunidad.
El piloto del gremio de protocolo finalizará y anunciaremos la estructura post-piloto.