Compilado por: 0xxz, Golden Finance
EthCC7 se celebró recientemente en Bruselas y los organizadores invitaron a Vitalik, el fundador de Ethereum, a dar un discurso de apertura.
Vale la pena señalar que 2024 marca el décimo aniversario de Ethereum ICO. Después del discurso de Vitalik, los tres ex fundadores principales de Ethereum, Vitalik Buterin, Joseph Lubin y Gavin Wood, una vez más se tomaron una foto grupal juntos para conmemorar la ocasión.
Este artículo es el discurso de apertura pronunciado recientemente por Vitalik, el fundador de Ethereum, en EthCC7.
el tema del discurso
Fortalecimiento de L1: Optimización de Ethereum para convertirse en una capa base de Capa 2 altamente confiable, confiable y sin permisos
Espectro de visión de Ethereum
Creo que existe un espectro de posibles diferentes divisiones del trabajo con respecto al papel que la capa base de Ethereum puede desempeñar en el ecosistema durante los próximos cinco a diez años. Puedes pensar en ello como un espectro de izquierda a derecha.
En el lado izquierdo del espectro, básicamente intenta ser una capa base muy minimalista que básicamente actúa como un verificador de pruebas para toda la L2. Quizás también brinde la capacidad de transferir ETH entre diferentes L2. Pero aparte de eso, eso es básicamente todo.
En el lado derecho del espectro, básicamente hay un reenfoque en las dApps que se ejecutan principalmente en L1, y L2 solo se usa para algunas transacciones muy específicas y de alto rendimiento.
Hay algunas opciones interesantes en el medio del espectro. Puse Ethereum como capa base de L2 en la segunda izquierda. Puse una versión extrema en el extremo izquierdo. La versión extrema es que abandonamos por completo la parte del cliente de ejecución de Ethereum, mantenemos solo la parte de consenso y agregamos algunos validadores de prueba de conocimiento cero, básicamente convirtiendo toda la capa de ejecución en un Rollup.
Quiero decir, hay opciones muy extremas a la izquierda y a la derecha podría ser una capa base, pero también intentar darle más funcionalidad a L2. Una idea en esta dirección es reducir aún más el tiempo de intercambio de Ethereum, actualmente de 12 segundos, posiblemente hasta 2-4 segundos. El propósito de esto es hacer que los paquetes acumulativos básicos sean viables como la forma principal en que opera L2. Entonces, si desea que L2 tenga una experiencia de usuario de primer nivel, debe tener su propia confirmación previa, lo que significa un clasificador centralizado o su propio clasificador descentralizado. Si su consenso se acelera, L2 ya no necesitará hacer esto. Si realmente desea mejorar la escalabilidad de L1, entonces también se reducirá la necesidad de L2.
Entonces, es un espectro. Por el momento me estoy centrando principalmente en la versión dos de la izquierda, pero las cosas que sugiero aquí se aplican también a otras visiones, y los consejos aquí en realidad no obstaculizan otras visiones. Esto es algo que creo que es muy importante.
La ventaja de robustez de Ethereum
Una gran ventaja de Ethereum es que tiene un ecosistema de apuestas grande y relativamente descentralizado.
El lado izquierdo de la imagen de arriba es un gráfico de la potencia informática de todos los grupos de minería de Bitcoin, y el lado derecho es un gráfico de los participantes en Ethereum.
La distribución de la potencia informática de Bitcoin actualmente no es muy buena. Dos grupos de minería suman más del 50% de la potencia de cálculo y cuatro grupos de minería suman más del 75%.
Y la situación de Ethereum es en realidad mejor de lo que muestra el gráfico, porque la segunda gran parte de la parte gris en realidad no está identificada, lo que significa que puede ser una combinación de muchas personas, e incluso puede haber muchos participantes independientes en ella. La parte azul, Lido, es en realidad una estructura extraña y poco coordinada compuesta por 37 validadores diferentes. Entonces, Ethereum en realidad tiene un ecosistema de apuestas relativamente descentralizado que funciona bastante bien.
Podemos hacer muchas mejoras en esta área, pero creo que aún es valioso reconocerlo. Ésa es una de las ventajas únicas que realmente podemos aprovechar.
Las ventajas de solidez de Ethereum también incluyen:
Tiene un ecosistema multicliente: hay clientes de ejecución Geth y clientes de ejecución que no son Geth. La proporción de clientes de ejecución que no son Geth incluso supera la de clientes de ejecución Geth. Una situación similar ocurre en los sistemas de clientes de consenso;
Comunidad internacional: personas en muchos países diferentes, incluidos proyectos, L2, equipos, etc.;
Ecosistema de conocimiento multicéntrico: está la Fundación Ethereum, está el equipo del cliente e incluso el equipo Reth de Paradigm ha estado aumentando su liderazgo en código abierto recientemente;
Culturas que valoran estos atributos
Entonces, el ecosistema Ethereum como capa base ya tiene estas ventajas muy poderosas. Creo que esto es algo muy valioso y no debería abandonarse fácilmente. Incluso diría que hay pasos claros que se pueden tomar para promover estas fortalezas e incluso abordar nuestras debilidades.
¿Dónde Ethereum L1 no cumple con los altos estándares y cómo se puede mejorar?
Aquí hay una encuesta que hice en Farcaster hace aproximadamente medio año: si no estás apostando en solitario, ¿qué te impide hacerlo?
Puedo repetir la pregunta en este lugar: ¿quién hace apuestas individuales? Sin Solo Stake, ¿quién de ustedes siente que el umbral de 32 ETH es el mayor obstáculo, quién siente que ejecutar un nodo es demasiado difícil es el mayor obstáculo y quién siente que el mayor obstáculo es que no pueden invertir su ETH en DeFi? protocolo al mismo tiempo? ¿Quién cree que el mayor obstáculo es el miedo a tener que colocar claves privadas en un nodo en ejecución donde puedan ser robadas más fácilmente?
Se puede ver que los dos principales obstáculos acordados unánimemente son: el requisito mínimo de 32 ETH y la dificultad de operación del nodo. Siempre es importante darse cuenta de esto.
Muchas veces, cuando empezamos a investigar cómo maximizar la capacidad de las personas de hacer doble uso de sus garantías en los protocolos DeFi, encontramos que una gran cantidad de personas ni siquiera utilizan los protocolos DeFi en absoluto. Así que centrémonos en los problemas principales y en lo que podemos hacer para intentar resolverlos.
Comience ejecutando un nodo validador, o en otras palabras, comenzando desde el umbral de 32 ETH. De hecho, estas dos preguntas están relacionadas porque ambas son funciones de la cantidad de validadores en la Prueba de participación de Ethereum.
Hoy tenemos alrededor de 1 millón de entidades validadoras, cada una con un depósito de 32 ETH, por lo que si el requisito mínimo se cambiara a 4 ETH, entonces tendríamos 8 millones o tal vez más de 8 millones, tal vez 9 millones o 10 millones de validadores. Si queremos reducirlo a 100.000 validadores, es posible que el requisito mínimo deba aumentar a alrededor de 300 ETH.
Entonces, es una compensación. Históricamente, Ethereum ha intentado estar en medio de la compensación. Sin embargo, si podemos encontrar alguna manera de mejorarlo, entonces tendremos puntos de estadísticas adicionales que podemos usar opcionalmente para reducir los requisitos mínimos o facilitar la ejecución de un nodo.
De hecho, ahora creo que agregar firmas ni siquiera es la principal dificultad al ejecutar un nodo. Al principio quizá nos centremos más en reducir los requisitos mínimos, pero eventualmente implicará ambas cosas.
Entonces, existen dos técnicas que pueden mejorar ambos aspectos.
Una técnica es permitir apostar o permitir la finalidad sin requerir que cada validador firme. Básicamente, necesita algún tipo de muestreo aleatorio de suficientes nodos para lograr una seguridad económica significativa.
Ahora mismo creo que tenemos seguridad económica más que suficiente. El costo de realizar un ataque del 51%, calculado en términos de la cantidad de ETH recortado, es un tercio de 32 millones de ETH, que son aproximadamente 11 millones de ETH. ¿Quién gastaría 11 millones de ETH para destruir la cadena de bloques Ethereum? Nadie, ni siquiera el gobierno de Estados Unidos, quiere hacerlo.
Estas técnicas de muestreo son similares a si tuvieras una casa y la puerta de entrada estuviera protegida por cuatro capas de acero, pero la ventana fuera solo un trozo de vidrio de baja calidad que alguien podría romper fácilmente con un bate de béisbol. Creo que Ethereum es así hasta cierto punto: si quieres realizar un ataque del 51%, tienes que perder 11 millones de ETH. Pero, en realidad, hay muchas otras formas de atacar el protocolo y realmente deberíamos fortalecer más estas defensas. Entonces, si tiene un subconjunto de validadores que realizan la finalidad, entonces el protocolo aún es lo suficientemente seguro y realmente puede aumentar el nivel de descentralización.
La segunda técnica es una mejor agregación de firmas. Se podría hacer algo avanzado como Starks y, en lugar de admitir 30.000 firmas por ranura, eventualmente podremos admitir más firmas. Ésta es la primera parte.
La segunda parte facilita la ejecución de nodos.
El primer paso es la caducidad del historial. De hecho, EIP-4444, ha habido muchos avances en este sentido.
El segundo paso es el cliente apátrida. Verkle existe desde hace mucho tiempo, otra opción posible es crear un árbol hash binario similar a Poseidón con una función hash compatible con Stark. Una vez que tenga esto, para verificar los bloques de Ethereum, ya no necesitará un disco duro. Luego puede agregar un ZKVM Tipo 1 que puede verificar con Stark todo el bloque de Ethereum, de modo que pueda verificar bloques de Ethereum arbitrariamente grandes descargando datos o incluso datos de muestreo de disponibilidad de datos, y luego solo necesitará verificar una prueba.
Si hace esto, ejecutar el nodo será más fácil. Una de las cosas más molestas actualmente con los clientes sin estado es que si desea cambiar la configuración de hardware o software, generalmente necesita comenzar desde cero y perder un día, o debe hacer algo muy peligroso y poner las claves en dos. sería un Slah, si tenemos clientes apátridas ya no es necesario hacer esto.
Simplemente puede iniciar un nuevo cliente independiente, cerrar el anterior, mover las claves e iniciar el nuevo. Sólo pierdes una época.
Una vez que tenga ZKVM, los requisitos de hardware básicamente se reducen a casi cero.
Por lo tanto, tanto el umbral de 32 ETH como la dificultad de operación del nodo pueden resolverse técnicamente. Creo que hacer esto tiene muchos otros beneficios: realmente mejorará nuestra capacidad de aumentar las apuestas individuales de las personas, nos brindará un mejor ecosistema de apuestas individuales y evitará los riesgos de la centralización de las apuestas.
La prueba de participación tiene otros desafíos, como los riesgos relacionados con la participación de liquidez y los riesgos relacionados con MEV. Estas también son preguntas importantes que debemos seguir considerando. Nuestros investigadores están pensando en esto.
Recuperarse del ataque del 51%
Realmente comencé a pensar seria y rigurosamente. Es sorprendente cuánta gente no piensa en absoluto en este tema y simplemente lo trata como una caja negra.
¿Qué pasará si realmente nos encontramos con un ataque del 51%?
Ethereum puede sufrir un ataque del 51%, Bitcoin puede sufrir un ataque del 51% y un gobierno también puede sufrir un ataque del 51%, como comprar el 51% de los políticos.
Un problema es que no se quiere depender únicamente de la prevención, sino que también se quiere tener un plan de recuperación.
Un error común es pensar que el 51% de los ataques tienen como objetivo revertir la finalidad. La gente presta atención a esto porque es lo que Satoshi Nakamoto enfatizó en el libro blanco. Puedes gastar el doble, después de comprar mi jet privado, hice un ataque del 51%, recuperé mis bitcoins y pude conservar mi jet privado y volar.
Un ataque más realista podría implicar realizar depósitos en intercambios y cosas como comprometer los protocolos DeFi.
Pero una reversión no es en realidad lo peor. El mayor riesgo que debería preocuparnos es la censura. El 51% de los nodos dejó de aceptar bloques del otro 49% de nodos o cualquier nodo que intentara contener algún tipo de transacción.
¿Por qué es este el mayor riesgo? Debido a que la reversión de la finalidad tiene Slash, hay evidencia verificable inmediata en la cadena de que al menos un tercio de los nodos hicieron algo muy, muy mal y fueron castigados.
Y en un ataque de censura, no es procesalmente atribuible, no hay evidencia procesal inmediata para decir quién hizo algo malo. Ahora, si usted es un nodo en línea, si desea ver que una determinada transacción no se ha incluido dentro de 100 bloques, pero ni siquiera hemos escrito un software para realizar esta verificación,
Otro desafío con la censura es que si alguien quiere atacar, puede hacerlo retrasando las transacciones y los bloqueos que no le gustan durante 30 segundos, luego retrasándolo durante un minuto, luego retrasándolo durante dos minutos, y ni siquiera tener consenso sobre cuándo responder.
Entonces, digo, en realidad la censura es el mayor riesgo.
Existe un argumento en la cultura blockchain de que si hay un ataque, la comunidad se unirá y obviamente harán algunas bifurcaciones suaves y eliminarán a los atacantes.
Eso puede ser cierto hoy, pero depende de muchas suposiciones sobre coordinación, ideología y todo tipo de otras cosas, y no está claro qué tan cierto será algo como esto dentro de 10 años. Entonces, lo que muchas otras comunidades de blockchain están comenzando a hacer es, dicen, tenemos cosas como la censura, tenemos estos errores que no son de naturaleza atribuible. Por tanto, debemos confiar en el consenso social. Así que confiemos únicamente en el consenso social y estemos orgullosos de admitir que lo utilizaremos para resolver nuestros problemas.
De hecho, abogo por ir en la dirección opuesta. Sabemos que coordinar completamente las respuestas automatizadas y bifurcar automáticamente a la mayoría de los atacantes bajo revisión es matemáticamente imposible. Pero podemos acercarnos lo más posible a eso.
Puede crear una bifurcación que realmente traiga al menos una mayoría de nodos en línea basándose en algunas suposiciones sobre las condiciones de la red. El argumento que intento transmitir aquí es que lo que realmente queremos es intentar que la respuesta a un ataque del 51% sea lo más automatizada posible.
Si usted es un validador, entonces su nodo debería ejecutar un software que, si detecta transacciones censuradas o ciertos validadores censurados, decensurará automáticamente la mayor parte de la cadena y todos los nodos honestos lo harán automáticamente debido a su El código de ejecución está coordinado en los mismos pocos tenedores blandos.
Por supuesto, nuevamente hay una imposibilidad matemática en el resultado, al menos cualquiera que estuviera desconectado en ese momento no podría decir quién tenía razón y quién no.
Hay muchas limitaciones, pero cuanto más nos acercamos a este objetivo, menos trabajo necesita hacer el consenso social.
Si te imaginas lo que realmente sucede con un ataque del 51%. No va a ser como, a continuación, de repente, en algún momento, Lido, Coinbase y Kraken publicarán una publicación de blog a las 5:46 básicamente diciendo: Hola chicos, estamos haciendo una revisión ahora.
Lo que en realidad podría suceder es que veamos una guerra en las redes sociales al mismo tiempo y veamos todo tipo de otros ataques al mismo tiempo. Si de hecho ocurre un ataque del 51%, por cierto, quiero decir, no deberíamos asumir que Lido, Coinbase y Kraken estarán en el poder en 10 años. El ecosistema Ethereum se volverá cada vez más común y deberá ser muy adaptable a esto. Queremos que la carga sobre la capa social sea lo más ligera posible, lo que significa que necesitamos que la capa técnica al menos presente un candidato ganador claro, y si quieren separarse de una cadena que está bajo revisión, deberían unirse. alrededor de un puñado de tenedores blandos superiores.
Abogo por que investiguemos más y hagamos una recomendación muy específica.
Propuesta: aumentar el umbral de quórum al 75% o al 80%
Creo que el umbral de quórum (Nota: el mecanismo de quórum es un algoritmo de votación comúnmente utilizado en sistemas distribuidos para garantizar la redundancia de datos y la eventual coherencia) se puede aumentar de dos tercios hoy en día a 75% u 80% aproximadamente.
El argumento básico es que si una cadena maliciosa, como una cadena de censura, ataca, la recuperación se vuelve muy, muy difícil. Sin embargo, por otro lado, si se aumenta la proporción de Quórum, ¿cuáles son los riesgos? Si el Quórum es del 80 %, entonces, en lugar de que el 34 % de los nodos se desconecten y detengan la finalidad, es el 21 % de los nodos que se desconecten y detengan la finalidad.
Hay riesgos. ¿Veamos cómo se ve en la práctica? Por lo que tengo entendido, creo que solo una vez la finalidad se detuvo durante aproximadamente una hora porque más de un tercio de los nodos estaban fuera de línea. Y luego, ¿hay algún incidente en el que entre el 20% y el 33% de los nodos estén fuera de línea? Pienso una vez como máximo y cero veces al menos. Dado que en la práctica muy pocos validadores se desconectan, creo que el riesgo de hacerlo es bastante bajo. Los beneficios son básicamente que el listón que un atacante debe alcanzar aumenta considerablemente, y la gama de escenarios en los que la cadena entra en modo seguro en caso de una vulnerabilidad del lado del cliente aumenta considerablemente, por lo que las personas pueden colaborar para descubrir qué salió mal.
Si el umbral de Quórum aumenta del 67% al 80%, entonces, suponiendo que la proporción que un cliente necesita alcanzar aumenta del 67% al 80%, entonces el valor de un pequeño número de clientes, o el valor que un pequeño número de los clientes pueden ofrecer, realmente comienza a aumentar.
Otras preocupaciones de censura
Otras preocupaciones de la censura son las listas de inclusión o alguna alternativa a las listas de inclusión. Entonces, todo el asunto del proponente multiparalelo, si funciona, podría incluso convertirse en un reemplazo para las listas de inclusión. Necesita, ya sea una abstracción de cuenta, o una abstracción de cuenta dentro de algún tipo de protocolo.
La razón por la que lo necesita es porque en este momento, las billeteras de contratos inteligentes realmente no se benefician de la lista de inclusión. Las carteras de contratos inteligentes realmente no se benefician de ningún tipo de garantía de resistencia a la censura en la capa de protocolo.
Se beneficiarían si hubiera una abstracción de cuentas dentro del protocolo. Entonces, hay muchas cosas, en realidad muchas de estas cosas son valiosas en la visión del centro L2 y la visión del centro L1.
Creo que de las diferentes ideas de las que hablé, probablemente alrededor de la mitad fueron específicamente para Ethereum enfocadas en L2, pero la otra mitad fue básicamente para L2 como capa base para usuarios de Ethereum y L1, o, como, directamente para la aplicación de los usuarios como usuario.
Utilice clientes ligeros en todas partes
En muchos sentidos, es un poco triste cómo interactuamos con el espacio, estamos descentralizados, no tenemos confianza, ¿quién en esta sala está ejecutando un cliente liviano en su computadora que valida el consenso? extraño. ¿Quién usa Ethereum al confiar en la billetera del navegador de Infura? En cinco años, me gustaría que se invirtiera el número de manos levantadas. Me gustaría ver carteras que no confíen en Infura para nada. Necesitamos integrar clientes ligeros.
Infura puede seguir proporcionando datos. Quiero decir, si no es necesario confiar en Infura, eso en realidad es bueno para Infura porque les facilita la construcción e implementación de infraestructura, pero tenemos herramientas para eliminar el requisito de confianza.
Lo que podemos hacer es tener un sistema en el que el usuario final ejecute algo así como un cliente ligero Helios. En realidad, debería ejecutarse directamente en el navegador, validando directamente el consenso de Ethereum. Si quiere verificar algo en la cadena, como interactuar con la cadena, entonces simplemente verifica la prueba de Merkle directamente.
Si hace esto, en realidad obtendrá cierto grado de desconfianza en sus interacciones con Ethereum. Esto es para L1. Además, también necesitamos una solución equivalente para L2.
En la cadena L1, hay encabezados de bloque, estados, comités de sincronización y consenso. Si verifica el consenso, si sabe cuál es el encabezado del bloque, puede recorrer la rama Merkle y ver cuál es el estado. Entonces, ¿cómo podemos ofrecer garantías de seguridad ligeras para los clientes L2? La raíz de estado de L2 está ahí. Si se trata de un paquete acumulativo básico, hay un contrato inteligente y ese contrato inteligente almacena el encabezado del bloque de L2. O, si tiene una confirmación previa, entonces tiene un contrato inteligente que almacena quién es la confirmación previa, de modo que determina quién es la confirmación previa y luego escucha un subconjunto de dos tercios de sus firmas.
Entonces, una vez que tienes el encabezado del bloque Ethereum, hay una cadena de confianza bastante simple, el hash, la rama Merkle y la firma que puedes verificar, y puedes obtener una verificación ligera del cliente. Lo mismo ocurre con cualquier L2.
Le he mencionado esto a la gente en el pasado y muchas veces la respuesta es: Dios mío, eso es interesante, pero ¿cuál es el punto? Gran parte de L2 es de firma múltiple. ¿Por qué no confiamos en las firmas múltiples para verificar las firmas múltiples?
Afortunadamente, desde el año pasado esto ya no es así. Optimism y Arbitrum se encuentran en la primera etapa de Rollup, lo que significa que en realidad tienen sistemas de prueba ejecutándose en la cadena y un comité de seguridad que puede cubrirlos en caso de una vulnerabilidad, pero el comité de seguridad debe superar un umbral de votación muy alto. , como el 75% de 8 personas, el tamaño de Arbitrum aumentará a 15 personas. Entonces, en el caso de Optimism y Arbitrum, no son solo multifirmas, tienen sistemas de prueba reales, y esos sistemas de prueba en realidad tienen un papel, al menos en términos de tener la mayor parte del poder para decidir qué cadena es correcta o incorrecta. .
EVM va aún más lejos: creo que ni siquiera tiene un comité de seguridad, por lo que no es de confianza. Realmente estamos empezando a avanzar en esto y sé que muchas otras L2 también están avanzando. Entonces, L2 es más que simplemente multifirma, por lo que el concepto de clientes ligeros para L2 realmente comienza a tener sentido.
Hoy ya podemos verificar la rama Merkle, solo escribe el código. Mañana también podremos validar ZKVM, para que pueda validar completamente Ethereum y L2 en la billetera de su navegador.
¿Quién quiere ser un usuario de Ethereum sin confianza en la billetera de un navegador? maravilloso. ¿Quién preferiría ser un usuario de Ethereum sin confianza en su teléfono móvil? ¿Qué pasa con una Raspberry Pi? ¿Qué pasa con un reloj inteligente? ¿De la estación espacial? Eso también lo arreglaremos. Entonces, lo que necesitamos es el equivalente a una configuración RPC que contenga no solo con qué servidores está hablando, sino también las instrucciones reales de autenticación del cliente ligero. Esto es algo en lo que podemos trabajar.
Estrategias de resistencia cuántica
El tiempo para la computación cuántica se está acortando. Metaculous cree que las computadoras cuánticas llegarán a principios de la década de 2030, y algunos piensan que antes.
Por eso necesitamos una estrategia resistente a los cuánticos. Tenemos una estrategia de resistencia cuántica. Hay cuatro partes de Ethereum que son vulnerables a la computación cuántica y cada una tiene alternativas naturales.
Una alternativa cuántica resistente a Verkle Tree es Starked Poseidon Hash, o si queremos ser más conservadores, podemos usar firmas de consenso de Blake; actualmente usamos firmas agregadas BLS, que pueden reemplazarse con firmas agregadas Stark. Blob usa KZG y se puede probar usando una codificación separada del árbol Merkle Stark. Las cuentas de usuario actualmente usan ECDSA SECP256K1, que puede reemplazarse con firmas basadas en hash y abstracción y agregación de cuentas, billeteras de contratos inteligentes ERC 4337, etc.
Una vez que los tenga, el usuario puede configurar su propio algoritmo de firma, esencialmente utilizando una firma basada en hash. Creo que realmente necesitamos empezar a pensar en crear firmas basadas en hash para que las billeteras de los usuarios puedan actualizarse fácilmente a firmas basadas en hash.
Simplificación del protocolo
Si desea una capa base sólida, el protocolo debe ser simple. No debería tener 73 ganchos aleatorios y cierta compatibilidad con versiones anteriores que existe debido a una idea estúpida y aleatoria que se le ocurrió a un tipo llamado Vitalik en 2014.
Por lo tanto, es valioso intentar simplificar realmente y comenzar a eliminar realmente la deuda técnica. Actualmente, los registros se basan en filtros de floración, que no funcionan bien y no son lo suficientemente rápidos, por lo que se necesitan mejoras en los registros para agregar una inmutabilidad más fuerte, lo que ya hacemos en el lado sin estado, básicamente limitando el estado de cada bloque de Vistas.
Ethereum es una colección increíble en este momento, está RLP, está SSZ, está API e idealmente deberíamos usar SSZ, pero al menos deshacernos de RLP, estado y el árbol binario Merkle, una vez que tenga el árbol binario Merkle, entonces Todo Ethereum está en un árbol binario de Merkle.
Fast Finality, Single Slot Finality (SSF), limpia los precompiladores no utilizados, como el precompilador ModX, que a menudo causa errores de consenso; sería bueno si pudiéramos eliminarlo y reemplazarlo con código sólido de alto rendimiento.
Resumir
Como capa base sólida, Ethereum tiene ventajas únicas, incluidas algunas que Bitcoin no tiene, como la descentralización por consenso y una investigación significativa sobre el 51% de recuperación de ataques.
Creo que es necesario fortalecer realmente esas fortalezas. También reconocer y corregir nuestras deficiencias para garantizar que cumplimos con estándares muy altos. Estas ideas son totalmente compatibles con la agresiva hoja de ruta L1.
Una de las cosas que más me complace de Ethereum y del proceso de desarrollo central en particular es que nuestra capacidad para trabajar en paralelo ha mejorado significativamente. Ese es un punto fuerte: podemos trabajar en muchas cosas en paralelo. Por lo tanto, preocuparse por estos temas en realidad no afecta la capacidad de mejorar el ecosistema L1 y L2. Por ejemplo, mejorar el EVM L1 para que sea más fácil realizar criptografía. Actualmente es demasiado caro verificar los hashes de Poseidon en el EVM. La criptografía de 384 bits también es demasiado cara.
Entonces, hay algunas ideas además de EOF, como códigos de operación SIMD, EVM max, etc. Existe la posibilidad de conectar este coprocesador de alto rendimiento al EVM. Esto es mejor para la Capa 2 porque pueden verificar pruebas más baratas, y mejor para las aplicaciones de Capa 1 porque los protocolos de privacidad como zk SNARK son más baratos.
¿Quién ha utilizado el acuerdo de privacidad? ¿Quién quiere pagar 40 tarifas en lugar de 80 con un acuerdo de privacidad? mas gente. El segundo grupo se puede utilizar en la Capa 2 y la Capa 1 puede lograr importantes ahorros de costos.
Los "Tres Grandes" de Ethereum se reúnen
2024 es el décimo aniversario de Ethereum IC0. El EthCC 2024 invitó a los tres ex fundadores principales de Ethereum, Vitalik Buterin, Joseph Lubin y Gavin Wood, a asistir a la reunión.
Después del discurso de Vitalik, los invitaron a tomarse una foto grupal juntos:
Los Tres Grandes vuelven a darse la mano
