Orador: Vitalik Buterin, fundador de Ethereum Compilado por: 0xxz, Golden Finance EthCC7 se celebró recientemente en Bruselas. El organizador invitó a Vitalik, fundador de Ethereum, a dar un discurso de apertura. Vale la pena señalar que 2024 marca el décimo aniversario del IC0 de Ethereum. Después del discurso de Vitalik, los tres 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, compilado por Golden Finance 0xxz. Fortalecimiento del tema del discurso 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 validador 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, mientras que 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 la capa base de L2, segunda desde la 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 que las opciones más extremas están a la izquierda, y a la derecha podría ser una capa base, pero también intenta 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. En realidad, el propósito de esto es hacer viables los resúmenes basados como la forma principal de operación L2. Entonces, si desea que L2 tenga una experiencia de usuario de primer nivel, debe tener su propia validació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 aumentar la escalabilidad de L1, también habrá menos necesidad de L2. Entonces, este 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 el gráfico de tasa de hash de todos los grupos de minería de Bitcoin, y el lado derecho es el gráfico de stakeholders de 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 formada 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 todavía vale la pena reconocerlo. Ésa es una de las ventajas únicas que realmente podemos aprovechar.
Las ventajas de solidez de Ethereum también incluyen: ● Tener un ecosistema multicliente: hay clientes de ejecución Geth y clientes de ejecución no Geth, y la proporción de clientes de ejecución no Geth incluso supera a la de clientes de ejecución Geth. Una situación similar también ocurre en el sistema de cliente de consenso; ● Comunidad internacional: las personas están en muchos países diferentes, incluidos proyectos, L2, equipos, etc. ● Ecosistema de conocimiento multicéntrico: existe la Fundación Ethereum y hay equipos de clientes; incluso equipos como el equipo Reth de Paradigm han estado aumentando recientemente su liderazgo en código abierto; una cultura que valora estos atributos. Por lo tanto, 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. Me atrevería a decir que hay pasos claros que se pueden tomar para promover estas fortalezas e incluso abordar nuestras debilidades. ¿Dónde no cumple Ethereum L1 los altos estándares? ¿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 no poder invertir su ETH en un ¿Protocolo DeFi 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 observar que los dos principales obstáculos acordados 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 su garantía en los protocolos DeFi, encontramos que hay una gran cantidad de personas que ni siquiera usan 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 quisiéramos reducir a 100.000 validadores, el requisito mínimo probablemente aumentaría a unos 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 para 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 estos dos 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%, 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 romper 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 como Poseidon, una función hash compatible con Stark. Una vez que tenga esto, para verificar los bloques de Ethereum, ya no necesitará un disco duro. Posteriormente, también puede agregar un ZKVM Tipo 1 que puede verificar con Stark bloques completos 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. se cortará en alguna parte; si tenemos un cliente sin estado, ya no es necesario hacer esto. Simplemente puede iniciar un nuevo cliente independiente, cerrar el anterior, mover las claves e iniciar el nuevo. Solo pierdes una época. Una vez que tenga ZKVM, los requisitos de hardware básicamente se reducen a casi cero. Por lo tanto, ambos problemas, el umbral de 32 ETH y la dificultad de ejecutar nodos, 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 líquida 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 creer 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 un jet privado, hice un ataque del 51%, recuperé mis bitcoins y también conservé mi jet privado y volé. Un ataque más realista podría implicar realizar depósitos en intercambios y cosas como comprometer los protocolos DeFi. Pero la 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 finalidad tiene Slash, hay pruebas verificables inmediatas 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 tenemos un software escrito para realizar esta verificación, otro desafío con la revisión es si alguien quiere A los ataques, pueden hacer esto, comienzan retrasando las transacciones y los bloques que no les gustan durante 30 segundos, luego lo retrasan un minuto, luego lo retrasan dos minutos, y ni siquiera hay consenso sobre cuándo responder. . Entonces, digo, la censura es en realidad el mayor riesgo. Existe un argumento en la cultura blockchain de que si ocurre un ataque, la comunidad se unirá y obviamente harán algunas bifurcaciones suaves y eliminarán a los atacantes. Esto puede ser cierto hoy, pero se basa en 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 ponga en línea al menos la mayoría de los nodos basándose en algunas suposiciones sobre las condiciones de la red. El argumento que intento exponer 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 un resultado matemáticamente imposible: 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 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 que básicamente dice: 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 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 será 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, sería el 21 % de los nodos que se desconecten y detengan la finalidad. Esto es arriesgado. ¿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, ¿hubo algún incidente en el que entre el 20% y el 33% de los nodos estuvieran 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 variedad 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 trabajar juntas para descubrirlo. Qué salió mal. Si el umbral de Quórum aumenta del 67% al 80%, 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 las listas 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. De las diversas ideas que discutí, aproximadamente la mitad probablemente sean específicamente para soluciones L2 para Ethereum, pero la otra mitad son básicamente aplicables a usuarios de Ethereum con L2 como capa base y L1, o aplicaciones directas al usuario. Utilice clientes ligeros en cualquier lugar
En muchos sentidos, es un poco triste cómo interactuamos con la industria, 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, en realidad es bueno para Infura si no necesita confiar en 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, necesitamos un esquema 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 basa en Rollup, 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 tenga el encabezado del bloque Ethereum, tendrá una cadena de confianza bastante simple, el hash, la rama Merkle y la firma, que puede verificar y puede 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 fase 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. , digamos 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 de 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. Estrategia anticuá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. La alternativa cuántica resistente a Verkle Tree es Starked Poseidon Hash, o si queremos ser más conservadores, podemos usar la firma de consenso de Blake; actualmente usamos la firma agregada BLS, que puede ser reemplazada por la firma agregada Stark. Blob usa KZG, que se puede probar usando árboles Merkle Stark codificados por separación. 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, básicamente 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 vista de bloque. 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 una hoja de ruta agresiva de L1. Una de las cosas que más me complace de Ethereum, especialmente el proceso de desarrollo central, 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, validar los hashes de Poseidon en el EVM es demasiado costoso. 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 puede ser más barato verificar las pruebas, y mejor para las aplicaciones de la 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 una tarifa de $40 en lugar de $80? Más personas elegirán lo primero. Un segundo grupo de usuarios puede realizar transacciones en la Capa 2, mientras que la Capa 1 puede reducir significativamente los costos.