El 8 de abril de 2025, el fundador de Ethereum, Vitalik, dará una conferencia magistral en la Cumbre de Académicos Web3 2025. Jinse Finance ha organizado el contenido de la conferencia de la siguiente manera.
Ahora, salir de Optimism o Arbitrum requiere un período de salida de 1 semana, lo que provoca muchos problemas.
¿Por qué deberíamos preocuparnos por esto? ¿Por qué preocuparnos por una conexión más rápida entre L2 y L1? Creo que hay dos razones para mí. Una de ellas es la experiencia del usuario, queremos que los usuarios tengan una mejor experiencia, esperar una semana es una mala experiencia. La otra razón es que necesitamos un ecosistema más integrado. Necesitamos hacer algunas cosas para realmente mejorar Optimism, Arbitrum, Polygon.
Estas partes del mundo de Ethereum no son independientes.
Actualmente, la interoperabilidad entre L1 y L2 es muy rápida, pero requiere mucho Gas. Empezamos a preocuparnos realmente por este problema desde el verano pasado. Las dos cosas que nos preocupan incluyen: direcciones específicas de la cadena de bloques y proyectos de intención. Espero que transferir Optimism a Arbitrum no requiera una semana, incluso espero que pueda poner Optimism en un contrato inteligente.
En un contrato inteligente, si alguien proporciona primero pruebas de que ha enviado dinero a cualquier dirección de destino a través del contrato, automáticamente saltará a este paso. Por lo tanto, esperamos encontrar la manera adecuada de reducir el tiempo de espera de una semana lo más posible.
¿Por qué ahora tenemos una ventana de retiro de una semana? Porque el Rollup de Optimism necesita esperar una semana para ver si alguien cuestiona su hash; si nadie lo cuestiona, puedes aceptar el hash. La ventaja de Optimism radica en que la tecnología de la que depende es muy cautelosa, pero el costo es esperar una semana.
Si no queremos esperar 1 semana, entonces necesitamos establecer un sistema que pueda empaquetar bloques utilizando completamente un sistema de pruebas no Optimism, como la combinación de ZK+TEE+OP—esta es la solución de diseño que proponemos.
En condiciones normales, una vez que se realiza una transacción L2, el estado se confirmará en L1 dentro de una hora, reduciendo 1 hora a 12 segundos, lo que es básicamente un problema de eficiencia. Así que ese es el primer objetivo. El segundo objetivo es que queremos que L2 sea sin confianza. Queremos demostrar que el sistema puede determinar el estado correcto y registrar el estado incorrecto, incluso si los componentes de confianza son comprometidos. Así que hoy, Rollup está en la fase cero o en la fase uno, lo que significa que depositan un cierto grado de confianza o toda la confianza en algún tipo de comité de seguridad. Debes confiar en que el fabricante puede diseñarlos correctamente. Debes confiar en que el fabricante no mantendrá una copia de la clave del sitio.
Además, debes creer que el mecanismo de hardware no es algo que cualquier persona que tenga el hardware pueda dañar, debes creer que no pueden encontrar una manera, como el escaneo láser o infrarrojo del hardware, de extraer información sin dañar la visualización.
Ahora, no queremos poner toda nuestra confianza en ZK.
Usted distribuirá la confianza entre tres mecanismos diferentes que operan según tipos de lógica muy distintos. Si tenemos este diseño, entonces puede reducir el período de finalización de 1 semana a 1 hora. Por cierto, otra forma es mi opinión anterior sobre el sistema de grupos, que básicamente los divido en dos categorías. Una es la confianza institucional y la otra es la confianza criptográfica.
Otra dimensión es la rapidez y la lentitud. Las cosas rápidas pueden ser aprobadas de inmediato, mientras que las lentas requieren un tiempo de espera. Lo interesante es que, al igual que las cuatro cosas aquí, son básicamente cuatro componentes de sistemas de prueba que la gente utiliza o piensa en el contexto de L2, ¿verdad? Si realmente pudiéramos ponerlos en una caja, encajarían perfectamente en un 2×2.
El primer paso, básicamente, es que hemos reducido la ventana de tiempo del Devil Walk de 1 semana a 1 hora. ¿Qué significa esto para usted? Básicamente, significa que si utiliza el puente nativo para transferir activos directamente, su tiempo de espera se reducirá de 1 semana a 1 hora. Si utiliza un puente basado en intenciones, entonces el puente basado en intenciones es instantáneo, pero los proveedores de liquidez no tienen que esperar 1 hora, sino que deben esperar 1 hora. El costo de proporcionar liquidez se ha reducido en 168 veces. Por lo tanto, las tarifas que debe pagar se reducirán hasta en 168 veces.
L2s puede utilizar lowlookahead para leer L1 de forma asíncrona. Esta es una función que L2 ya tiene, ya que deben ser capaces de manejar depósitos. Adoptamos el mismo estado que se utiliza para leer depósitos y lo exponemos al opcode L1SLOAD. Es muy valioso poder leer datos de oráculos L1, billeteras de llaves y muchas otras aplicaciones, ya que uno de los desafíos que enfrentan con frecuencia los L2 es que necesitan pagar grandes cantidades de dinero.
Por lo tanto, obtuve varias aplicaciones personalizadas y integraciones específicas. Esto realmente puede reducir costos, ya que en muchos casos, las alternativas podrán leer directamente una copia de la aplicación que ya existe en una aplicación, lo que es aplicable para el procesamiento de datos. Se aplica a ciertas cosas, pero no a aquellas que requieren escribir para cualquier persona.
¿La billetera de almacenamiento de claves no es otra idea interesante, verdad? La idea de una billetera de almacenamiento de claves es, básicamente, que en la seguridad de red normal, si deseas cambiar una clave, no quieres que la clave tenga un ciclo de vida infinito. Neo es parte del objetivo de abstracción de cuentas y hoy discutiré este objetivo.
Pero ya he hablado de esto varias veces, básicamente se trata de crear cuentas con cualquier lógica, de modo que puedas hacer cosas como cambiar el algoritmo de cifrado, cambiar las claves, hacer que tengan mucha resistencia y hacer que utilicen snark añadidos como método de recuperación. Ahora, uno de los desafíos es que si puedes cambiar la clave, entonces tienes cien resultados después de los cambios. Por lo tanto, debes cambiar el registro de la clave actual en 100 lugares.
¿Cómo resuelves este problema? Lo resolvemos colocando el registro de la clave actual en un contrato central. Entonces, aparece una copia de la billetera en cada L2, solo necesitas leer L1. Esto hace que muchas prácticas de seguridad de securitización muy razonables y similares sean más viables y prácticas en el mundo de L2.
Otro beneficio es que esto hace que los flujos de trabajo que incluyen tanto L2 como L1 sean más fáciles y naturales para los desarrolladores. No solo estamos hablando de teoría, y de un montón de cadenas completamente independientes, sino que en realidad estamos hablando de que la teoría de L1 continúe siendo el núcleo de la experiencia del usuario de las aplicaciones y las personas.
El tercer paso es la prueba de agregación. Antes mencioné que si adoptamos este método basado en dos o tres formas, o en el futuro, si hacemos una verificación formal muy buena, solo dependemos de ZK, podríamos reducir el tiempo de envío de 1 semana a 1 hora. ¿Por qué 1 hora? ¿Por qué no 12 segundos? Hay dos razones, y podemos abordar estas dos razones. La primera razón es el costo de envío. Por lo tanto, enviar una prueba a L1 requiere un gasto adicional, alrededor de 500,000 gas, y el costo de AA es muy alto.
Ahora, si imaginas que cada intervalo de tiempo se presenta una prueba, entonces hay 2.5 millones de intervalos en un año. Gastamos 27.5 millones de dólares al año solo para mantener un valor relativo, eso es una locura. ¿Quién aquí está dispuesto a pagar 27 millones de dólares al año? Pero si presentas una vez por minuto, en lugar de cada 12 segundos, entonces el gasto de 27 millones de dólares al año se convierte en 5.5 millones de dólares. Luego, si presentas una vez por hora, bajaría a menos de 100 mil dólares al año. Esto es realmente manejable. Esta solución natural es la agregación de pruebas.
Si tenemos muchas herramientas diferentes, entonces no es necesario que estas herramientas se envíen por separado a diferentes grupos; la prueba en cadena puede agruparse, y el grupo puede enviar su prueba a una agregación, que luego puede enviar una única snark para probar la existencia de otras snark. El costo de verificar esa snark es solo un costo único de 500,000 gas. Lo que sucede aquí es básicamente lo que está en esta imagen, ¿verdad? Básicamente, tienes un montón de pruebas, y esas pruebas también especifican qué contrato. Estamos en un bloque. Luego tienes una prueba de agregación. La prueba de agregación se verifica. La prueba de agregación contiene toda la información resumida como entrada pública, y luego la prueba solo ocurre una vez. Luego, este contrato solo hará una llamada por cada resumen, y la única cosa que hace la llamada es cargar cada resumen por separado. El costo cada vez disminuye de 500,000 gas a menos de 10,000 gas.
Ahora hay un cuarto paso, que es reducir la latencia de la prueba. El cálculo de la prueba requiere más tiempo y más capacidad de cómputo que realizar el cálculo. Por defecto, este cálculo no colapsa. Debes ampliarlo y debes realizar este cálculo muy intensivo.
Por lo tanto, el resultado es que, en un estado de equilibrio, generar un bloque que necesita 5 segundos, aún requiere 500 segundos para ser probado, ¿verdad? Este es un problema. Así que la pregunta es, ¿cómo resolvemos este problema? Hay dos ideas. Una es que podemos usar hardware especializado para mejorarlo. Algunas empresas ya están haciendo esto. Si obtienes un factor de aceleración de hardware de 100 veces, entonces puedes probar en tiempo real. La otra idea es la prueba de super paralización. Así que desde un punto de vista matemático, esto es en realidad muy simple. Básicamente, descompones el cálculo en múltiples pasos. Luego generas en paralelo la prueba de cada paso en diferentes dispositivos.
Si esto no es suficiente, la velocidad de mejora del hardware especializado será aún más rápida. Al mismo tiempo, el costo de las mejoras también será más bajo. Así que tenemos muchas opciones.
Si usas Intensive Optimism y Arbitrum, ambos tienen espacios de tiempo mucho más rápidos, entonces también puedes completarlo en 2 segundos. Así que será muy barato. Por lo tanto, si usas Intensive, podrás transferir prácticamente cantidades ilimitadas de Ethereum a bajo costo y rápidamente. Esto también significa que podemos establecer conexiones más estrechas entre L1 y L2. Hemos logrado un mundo más integrado, lo que hace que todo sea más fácil y rápido para todos. Gracias.
El contenido es solo de referencia, no una solicitud u oferta. No se proporciona asesoramiento fiscal, legal ni de inversión. Consulte el Descargo de responsabilidad para obtener más información sobre los riesgos.
Vatilik: ¿Por qué acelerar la velocidad de confirmación de L2? ¿Cómo acelerar?
Organización: Wuzhu, Jinse Caijing
El 8 de abril de 2025, el fundador de Ethereum, Vitalik, dará una conferencia magistral en la Cumbre de Académicos Web3 2025. Jinse Finance ha organizado el contenido de la conferencia de la siguiente manera.
Ahora, salir de Optimism o Arbitrum requiere un período de salida de 1 semana, lo que provoca muchos problemas.
¿Por qué deberíamos preocuparnos por esto? ¿Por qué preocuparnos por una conexión más rápida entre L2 y L1? Creo que hay dos razones para mí. Una de ellas es la experiencia del usuario, queremos que los usuarios tengan una mejor experiencia, esperar una semana es una mala experiencia. La otra razón es que necesitamos un ecosistema más integrado. Necesitamos hacer algunas cosas para realmente mejorar Optimism, Arbitrum, Polygon.
Estas partes del mundo de Ethereum no son independientes.
Actualmente, la interoperabilidad entre L1 y L2 es muy rápida, pero requiere mucho Gas. Empezamos a preocuparnos realmente por este problema desde el verano pasado. Las dos cosas que nos preocupan incluyen: direcciones específicas de la cadena de bloques y proyectos de intención. Espero que transferir Optimism a Arbitrum no requiera una semana, incluso espero que pueda poner Optimism en un contrato inteligente.
En un contrato inteligente, si alguien proporciona primero pruebas de que ha enviado dinero a cualquier dirección de destino a través del contrato, automáticamente saltará a este paso. Por lo tanto, esperamos encontrar la manera adecuada de reducir el tiempo de espera de una semana lo más posible.
¿Por qué ahora tenemos una ventana de retiro de una semana? Porque el Rollup de Optimism necesita esperar una semana para ver si alguien cuestiona su hash; si nadie lo cuestiona, puedes aceptar el hash. La ventaja de Optimism radica en que la tecnología de la que depende es muy cautelosa, pero el costo es esperar una semana.
Si no queremos esperar 1 semana, entonces necesitamos establecer un sistema que pueda empaquetar bloques utilizando completamente un sistema de pruebas no Optimism, como la combinación de ZK+TEE+OP—esta es la solución de diseño que proponemos.
En condiciones normales, una vez que se realiza una transacción L2, el estado se confirmará en L1 dentro de una hora, reduciendo 1 hora a 12 segundos, lo que es básicamente un problema de eficiencia. Así que ese es el primer objetivo. El segundo objetivo es que queremos que L2 sea sin confianza. Queremos demostrar que el sistema puede determinar el estado correcto y registrar el estado incorrecto, incluso si los componentes de confianza son comprometidos. Así que hoy, Rollup está en la fase cero o en la fase uno, lo que significa que depositan un cierto grado de confianza o toda la confianza en algún tipo de comité de seguridad. Debes confiar en que el fabricante puede diseñarlos correctamente. Debes confiar en que el fabricante no mantendrá una copia de la clave del sitio.
Además, debes creer que el mecanismo de hardware no es algo que cualquier persona que tenga el hardware pueda dañar, debes creer que no pueden encontrar una manera, como el escaneo láser o infrarrojo del hardware, de extraer información sin dañar la visualización.
Ahora, no queremos poner toda nuestra confianza en ZK.
Usted distribuirá la confianza entre tres mecanismos diferentes que operan según tipos de lógica muy distintos. Si tenemos este diseño, entonces puede reducir el período de finalización de 1 semana a 1 hora. Por cierto, otra forma es mi opinión anterior sobre el sistema de grupos, que básicamente los divido en dos categorías. Una es la confianza institucional y la otra es la confianza criptográfica.
Otra dimensión es la rapidez y la lentitud. Las cosas rápidas pueden ser aprobadas de inmediato, mientras que las lentas requieren un tiempo de espera. Lo interesante es que, al igual que las cuatro cosas aquí, son básicamente cuatro componentes de sistemas de prueba que la gente utiliza o piensa en el contexto de L2, ¿verdad? Si realmente pudiéramos ponerlos en una caja, encajarían perfectamente en un 2×2.
El primer paso, básicamente, es que hemos reducido la ventana de tiempo del Devil Walk de 1 semana a 1 hora. ¿Qué significa esto para usted? Básicamente, significa que si utiliza el puente nativo para transferir activos directamente, su tiempo de espera se reducirá de 1 semana a 1 hora. Si utiliza un puente basado en intenciones, entonces el puente basado en intenciones es instantáneo, pero los proveedores de liquidez no tienen que esperar 1 hora, sino que deben esperar 1 hora. El costo de proporcionar liquidez se ha reducido en 168 veces. Por lo tanto, las tarifas que debe pagar se reducirán hasta en 168 veces.
L2s puede utilizar lowlookahead para leer L1 de forma asíncrona. Esta es una función que L2 ya tiene, ya que deben ser capaces de manejar depósitos. Adoptamos el mismo estado que se utiliza para leer depósitos y lo exponemos al opcode L1SLOAD. Es muy valioso poder leer datos de oráculos L1, billeteras de llaves y muchas otras aplicaciones, ya que uno de los desafíos que enfrentan con frecuencia los L2 es que necesitan pagar grandes cantidades de dinero.
Por lo tanto, obtuve varias aplicaciones personalizadas y integraciones específicas. Esto realmente puede reducir costos, ya que en muchos casos, las alternativas podrán leer directamente una copia de la aplicación que ya existe en una aplicación, lo que es aplicable para el procesamiento de datos. Se aplica a ciertas cosas, pero no a aquellas que requieren escribir para cualquier persona.
¿La billetera de almacenamiento de claves no es otra idea interesante, verdad? La idea de una billetera de almacenamiento de claves es, básicamente, que en la seguridad de red normal, si deseas cambiar una clave, no quieres que la clave tenga un ciclo de vida infinito. Neo es parte del objetivo de abstracción de cuentas y hoy discutiré este objetivo.
Pero ya he hablado de esto varias veces, básicamente se trata de crear cuentas con cualquier lógica, de modo que puedas hacer cosas como cambiar el algoritmo de cifrado, cambiar las claves, hacer que tengan mucha resistencia y hacer que utilicen snark añadidos como método de recuperación. Ahora, uno de los desafíos es que si puedes cambiar la clave, entonces tienes cien resultados después de los cambios. Por lo tanto, debes cambiar el registro de la clave actual en 100 lugares.
¿Cómo resuelves este problema? Lo resolvemos colocando el registro de la clave actual en un contrato central. Entonces, aparece una copia de la billetera en cada L2, solo necesitas leer L1. Esto hace que muchas prácticas de seguridad de securitización muy razonables y similares sean más viables y prácticas en el mundo de L2.
Otro beneficio es que esto hace que los flujos de trabajo que incluyen tanto L2 como L1 sean más fáciles y naturales para los desarrolladores. No solo estamos hablando de teoría, y de un montón de cadenas completamente independientes, sino que en realidad estamos hablando de que la teoría de L1 continúe siendo el núcleo de la experiencia del usuario de las aplicaciones y las personas.
El tercer paso es la prueba de agregación. Antes mencioné que si adoptamos este método basado en dos o tres formas, o en el futuro, si hacemos una verificación formal muy buena, solo dependemos de ZK, podríamos reducir el tiempo de envío de 1 semana a 1 hora. ¿Por qué 1 hora? ¿Por qué no 12 segundos? Hay dos razones, y podemos abordar estas dos razones. La primera razón es el costo de envío. Por lo tanto, enviar una prueba a L1 requiere un gasto adicional, alrededor de 500,000 gas, y el costo de AA es muy alto.
Ahora, si imaginas que cada intervalo de tiempo se presenta una prueba, entonces hay 2.5 millones de intervalos en un año. Gastamos 27.5 millones de dólares al año solo para mantener un valor relativo, eso es una locura. ¿Quién aquí está dispuesto a pagar 27 millones de dólares al año? Pero si presentas una vez por minuto, en lugar de cada 12 segundos, entonces el gasto de 27 millones de dólares al año se convierte en 5.5 millones de dólares. Luego, si presentas una vez por hora, bajaría a menos de 100 mil dólares al año. Esto es realmente manejable. Esta solución natural es la agregación de pruebas.
Si tenemos muchas herramientas diferentes, entonces no es necesario que estas herramientas se envíen por separado a diferentes grupos; la prueba en cadena puede agruparse, y el grupo puede enviar su prueba a una agregación, que luego puede enviar una única snark para probar la existencia de otras snark. El costo de verificar esa snark es solo un costo único de 500,000 gas. Lo que sucede aquí es básicamente lo que está en esta imagen, ¿verdad? Básicamente, tienes un montón de pruebas, y esas pruebas también especifican qué contrato. Estamos en un bloque. Luego tienes una prueba de agregación. La prueba de agregación se verifica. La prueba de agregación contiene toda la información resumida como entrada pública, y luego la prueba solo ocurre una vez. Luego, este contrato solo hará una llamada por cada resumen, y la única cosa que hace la llamada es cargar cada resumen por separado. El costo cada vez disminuye de 500,000 gas a menos de 10,000 gas.
Ahora hay un cuarto paso, que es reducir la latencia de la prueba. El cálculo de la prueba requiere más tiempo y más capacidad de cómputo que realizar el cálculo. Por defecto, este cálculo no colapsa. Debes ampliarlo y debes realizar este cálculo muy intensivo.
Por lo tanto, el resultado es que, en un estado de equilibrio, generar un bloque que necesita 5 segundos, aún requiere 500 segundos para ser probado, ¿verdad? Este es un problema. Así que la pregunta es, ¿cómo resolvemos este problema? Hay dos ideas. Una es que podemos usar hardware especializado para mejorarlo. Algunas empresas ya están haciendo esto. Si obtienes un factor de aceleración de hardware de 100 veces, entonces puedes probar en tiempo real. La otra idea es la prueba de super paralización. Así que desde un punto de vista matemático, esto es en realidad muy simple. Básicamente, descompones el cálculo en múltiples pasos. Luego generas en paralelo la prueba de cada paso en diferentes dispositivos.
Si esto no es suficiente, la velocidad de mejora del hardware especializado será aún más rápida. Al mismo tiempo, el costo de las mejoras también será más bajo. Así que tenemos muchas opciones.
Si usas Intensive Optimism y Arbitrum, ambos tienen espacios de tiempo mucho más rápidos, entonces también puedes completarlo en 2 segundos. Así que será muy barato. Por lo tanto, si usas Intensive, podrás transferir prácticamente cantidades ilimitadas de Ethereum a bajo costo y rápidamente. Esto también significa que podemos establecer conexiones más estrechas entre L1 y L2. Hemos logrado un mundo más integrado, lo que hace que todo sea más fácil y rápido para todos. Gracias.