Un agradecimiento especial a Dan Finlay, Karl Floersch, David Hoffman y a los equipos de Scroll y SoulWallet por sus comentarios, revisiones y sugerencias.

A medida que Ethereum pasa de ser una tecnología experimental joven a una pila tecnológica madura que es capaz de brindar una experiencia abierta, global y sin permisos a los usuarios promedio, hay tres transiciones técnicas principales que la pila debe experimentar, aproximadamente simultáneamente:

• La transición de escalado de L2: todos los usuarios pasan a los rollups
• La transición de la seguridad de la billetera: todos se mudan a billeteras de contratos inteligentes
• La transición a la privacidad: asegurarse de que las transferencias de fondos que preservan la privacidad estén disponibles y asegurarse de que todos los demás dispositivos que se están desarrollando (recuperación social, identidad, reputación) preserven la privacidad

El triángulo de transición ecosistémico. Solo puedes elegir 3 de 3.

Sin el primero, Ethereum fracasa porque cada transacción cuesta 3,75 dólares (82,48 dólares si tenemos otra carrera alcista), y todo producto que apunta al mercado masivo inevitablemente se olvida de la cadena y adopta soluciones centralizadas para todo.

Sin el segundo, Ethereum fracasa porque los usuarios se sienten incómodos almacenando sus fondos (y activos no financieros), y todo el mundo se traslada a los exchanges centralizados.

Sin la tercera, Ethereum falla porque tener todas las transacciones (y POAP, etc.) disponibles públicamente para que literalmente cualquiera las vea es un sacrificio de privacidad demasiado alto para muchos usuarios, y todos se mueven a soluciones centralizadas que al menos ocultan un poco sus datos.

Estas tres transiciones son cruciales por las razones anteriores. Pero también son un reto debido a la intensa coordinación que implica resolverlos adecuadamente. No son solo las características del protocolo las que deben mejorar; en algunos casos, la forma en que interactuamos con Ethereum debe cambiar de manera bastante fundamental, lo que requiere cambios profundos de las aplicaciones y billeteras.

Las tres transiciones remodelarán radicalmente la relación entre los usuarios y las direcciones

En un mundo de escalado L2, los usuarios van a existir en muchos L2. ¿Eres miembro de ExampleDAO, que vive de Optimism? ¡Entonces tienes una cuenta en Optimism! ¿Tienes un CDP en un sistema de stablecoin en ZkSync? ¡Entonces tienes una cuenta en ZkSync! ¿Alguna vez fuiste a probar alguna aplicación que vivía en Kakarot? ¡Entonces tienes una cuenta en Kakarot! Los días en los que un usuario solo tenía una dirección desaparecerán.

Tengo ETH en cuatro lugares, según mi vista de Brave Wallet. Y sí, Arbitrum y Arbitrum Nova son diferentes. ¡No te preocupes, se volverá más confuso con el tiempo!

Las billeteras de contratos inteligentes agregan más complejidad, al hacer que sea mucho más difícil tener la misma dirección en L1 y las diversas L2. Hoy en día, la mayoría de los usuarios utilizan cuentas de propiedad externa, cuya dirección es literalmente un hash de la clave pública que se utiliza para verificar las firmas, por lo que nada cambia entre L1 y L2. Sin embargo, con las billeteras de contratos inteligentes, mantener una dirección se vuelve más difícil. Aunque se ha trabajado mucho para tratar de hacer que las direcciones sean hashes de código que puedan ser equivalentes en todas las redes, sobre todo CREATE2 y la fábrica de singleton ERC-2470, es difícil hacer que esto funcione perfectamente. Algunas L2 (p. ej. "ZK-EVM de tipo 4 ") no son del todo equivalentes a EVM, a menudo utilizan Solidity o un ensamblaje intermedio en su lugar, lo que evita la equivalencia de hash. E incluso cuando puede tener equivalencia de hash, la posibilidad de que las billeteras cambien de propietario a través de cambios de clave crea otras consecuencias poco intuitivas.

La privacidad requiere que cada usuario tenga aún más direcciones, e incluso puede cambiar el tipo de direcciones con las que estamos tratando. Si las propuestas de direcciones ocultas se utilizan ampliamente, en lugar de que cada usuario tenga solo unas pocas direcciones, o una dirección por L2, los usuarios podrían tener una dirección por transacción. Otros esquemas de privacidad, incluso los existentes como Tornado Cash, cambian la forma en que se almacenan los activos de una manera diferente: los fondos de muchos usuarios se almacenan en el mismo contrato inteligente (y, por lo tanto, en la misma dirección). Para enviar fondos a un usuario específico, los usuarios deberán confiar en el propio sistema de direcciones interno del esquema de privacidad.

Como hemos visto, cada una de las tres transiciones debilita el modelo mental de "un usuario ~= una dirección" de diferentes maneras, y algunos de estos efectos retroalimentan la complejidad de la ejecución de las transiciones. Dos puntos particulares de complejidad son:

1. Si quieres pagarle a alguien, ¿cómo obtendrás la información sobre cómo pagarle?
2. Si los usuarios tienen muchos activos almacenados en diferentes lugares a través de diferentes cadenas, ¿cómo realizan cambios clave y recuperación social?

Las tres transiciones y los pagos on-chain (y la identidad)

Tengo monedas en Scroll y quiero pagar por el café (si la "I" soy literalmente yo, el escritor de este artículo, entonces "café" es, por supuesto, una metonimia de "té verde"). Me estás vendiendo el café, pero solo estás configurado para recibir monedas en Taiko. ¿Qué hacer?

Básicamente hay dos soluciones:

1. Las billeteras receptoras (que podrían ser comerciantes, pero también podrían ser personas normales) se esfuerzan mucho por admitir cada L2 y tienen alguna funcionalidad automatizada para consolidar fondos de forma asíncrona.
2. El destinatario proporciona su L2 junto con su dirección, y la billetera del remitente enruta automáticamente los fondos a la L2 de destino a través de algún sistema de puente entre L2.

Por supuesto, estas soluciones se pueden combinar: el destinatario proporciona la lista de L2 que está dispuesto a aceptar, y la billetera del remitente determina el pago, lo que podría implicar un envío directo si tiene suerte, o de lo contrario, una ruta de puente entre L2.

Pero este es solo un ejemplo de un desafío clave que introducen las tres transiciones: acciones simples como pagarle a alguien comienzan a requerir mucha más información que solo una dirección de 20 bytes.

Afortunadamente, la transición a las billeteras de contratos inteligentes no es una gran carga para el sistema de direccionamiento, pero todavía hay algunos problemas técnicos en otras partes de la pila de aplicaciones que deben resolverse. Las billeteras deberán actualizarse para asegurarse de que no envíen solo 21000 gas junto con una transacción, y será aún más importante asegurarse de que el lado receptor de pagos de una billetera rastree no solo las transferencias de ETH de EOA, sino también ETH enviado por código de contrato inteligente. Las aplicaciones que se basan en la suposición de que la propiedad de la dirección es inmutable (p. ej. Los NFT que prohíben los contratos inteligentes para hacer cumplir las regalías) tendrán que encontrar otras formas de lograr sus objetivos. Las billeteras de contratos inteligentes también facilitarán algunas cosas, en particular, si alguien recibe solo un token ERC20 que no sea ETH, podrá usar los pagadores ERC-4337 para pagar el gas con ese token.

La privacidad, por otro lado, vuelve a plantear grandes retos que aún no hemos abordado realmente. El Tornado Cash original no introdujo ninguno de estos problemas, porque no admitía transferencias internas: los usuarios solo podían depositar en el sistema y retirar de él. Sin embargo, una vez que pueda realizar transferencias internas, los usuarios deberán utilizar el esquema de direcciones internas del sistema de privacidad. En la práctica, la "información de pago" de un usuario tendría que contener (i) algún tipo de "clave pública de gasto", un compromiso con un secreto que el destinatario podría usar para gastar, y (ii) alguna forma de que el remitente envíe información cifrada que solo el destinatario puede descifrar, para ayudar al destinatario a descubrir el pago.

Los protocolos de direcciones ocultas se basan en un concepto de meta-direcciones, que funcionan de esta manera: una parte de la meta-dirección es una versión ciega de la clave de gasto del remitente, y otra parte es la clave de cifrado del remitente (aunque una implementación mínima podría establecer esas dos claves para que sean iguales).

Resumen esquemático de un esquema abstracto de direcciones sigilosas basado en cifrado y ZK-SNARKs.

Una lección clave aquí es que en un ecosistema amigable con la privacidad, un usuario tendrá claves públicas de gasto y claves públicas de cifrado, y la "información de pago" de un usuario tendrá que incluir ambas claves. También hay buenas razones además de los pagos para expandirse en esta dirección. Por ejemplo, si queremos un correo electrónico cifrado basado en Ethereum, los usuarios deberán proporcionar públicamente algún tipo de clave de cifrado. En el "mundo EOA", podríamos reutilizar las claves de cuenta para esto, pero en un mundo seguro de billetera de contratos inteligentes, probablemente deberíamos tener una funcionalidad más explícita para esto. Esto también ayudaría a hacer que la identidad basada en Ethereum sea más compatible con los ecosistemas de privacidad descentralizados que no son de Ethereum, sobre todo las claves PGP.

Las tres transiciones y la recuperación de claves

La forma predeterminada de implementar cambios clave y recuperación social en un mundo de muchas direcciones por usuario es simplemente hacer que los usuarios ejecuten el procedimiento de recuperación en cada dirección por separado. Esto se puede hacer con un solo clic: la billetera puede incluir software para ejecutar el procedimiento de recuperación en todas las direcciones de un usuario al mismo tiempo. Sin embargo, incluso con tales simplificaciones de UX, la recuperación ingenua de múltiples direcciones tiene tres problemas:

1. Impracticabilidad del costo de la gasolina: esto se explica por sí mismo.
2. Direcciones contrafactuales: direcciones para las que aún no se ha publicado el contrato inteligente (en la práctica, esto significará una cuenta desde la que aún no ha enviado fondos). Usted, como usuario, tiene un número potencialmente ilimitado de direcciones contrafácticas: una o más en cada L2, incluidas las L2 que aún no existen, y todo un conjunto infinito de direcciones contrafácticas que surgen de esquemas de direcciones sigilosas.
3. Privacidad: si un usuario tiene intencionalmente muchas direcciones para evitar vincularlas entre sí, ¡ciertamente no quiere vincularlas públicamente recuperándolas al mismo tiempo o más o menos!

Resolver estos problemas es difícil. Afortunadamente, existe una solución algo elegante que funciona razonablemente bien: una arquitectura que separa la lógica de verificación y las tenencias de activos.

Cada usuario tiene un contrato de almacén de claves, que existe en una ubicación (puede ser la red principal o una capa 2 específica). A continuación, los usuarios tienen direcciones en diferentes L2, donde la lógica de verificación de cada una de esas direcciones es un puntero al contrato de almacén de claves. El gasto de esas direcciones requeriría una prueba en el contrato del almacén de claves que muestre la clave pública de gasto actual (o, más realistamente, muy reciente).

La prueba podría implementarse de varias maneras:

• Acceso directo de solo lectura a L1 dentro de la L2. Es posible modificar las L2 para darles una forma de leer directamente el estado de la L1. Si el contrato de almacén de claves está en L1, esto significaría que los contratos dentro de L2 pueden acceder al almacén de claves "de forma gratuita"
• Ramas de Merkle. Las ramas de Merkle pueden probar el estado L1 a un L2, o el estado L2 a un L1, o puede combinar los dos para probar partes del estado de un L2 a otro L2. La principal debilidad de las pruebas de Merkle son los altos costos de gas debido a la longitud de la prueba: potencialmente 5 kB para una prueba, aunque esto se reducirá a < 1 kB en el futuro debido a los árboles de Verkle.
• ZK-SNARKs. Puede reducir los costos de datos utilizando un ZK-SNARK de una rama de Merkle en lugar de la propia sucursal. Es posible construir técnicas de agregación fuera de la cadena (por ejemplo, sobre EIP-4337) para que un solo ZK-SNARK verifique todas las pruebas de estado entre cadenas en un bloque.
• Compromisos de KZG. Tanto los L2, como los esquemas construidos sobre ellos, podrían introducir un sistema de direccionamiento secuencial, lo que permitiría que las pruebas de estado dentro de este sistema tuvieran solo 48 bytes de longitud. Al igual que con los ZK-SNARK, un esquema de pruebas múltiples podría fusionar todas estas pruebas en una sola prueba por bloque.

Si queremos evitar hacer una prueba por transacción, podemos implementar un esquema más ligero que solo requiera una prueba cruzada L2 para la recuperación. El gasto de una cuenta dependería de una clave de gasto cuya clave pública correspondiente se almacena en esa cuenta, pero la recuperación requeriría una transacción que copie el spending_pubkey actual en el almacén de claves. Los fondos en direcciones contrafactuales están seguros incluso si sus claves antiguas no lo están: "activar" una dirección contrafactual para convertirla en un contrato de trabajo requeriría hacer una prueba cruzada L2 para copiar el spending_pubkey actual. Este hilo en los foros de Safe describe cómo podría funcionar una arquitectura similar.

Para agregar privacidad a un esquema de este tipo, simplemente encriptamos el puntero y hacemos todas nuestras pruebas dentro de ZK-SNARKs:

Con más trabajo (ej. usando <a href="https://notes.ethereum.org/@vbuterin/non_index_revealing_proof">this trabajo como punto de partida), también podríamos eliminar la mayor parte de la complejidad de los ZK-SNARKs y hacer un esquema más básico basado en KZG.

Estos esquemas pueden llegar a ser complejos. En el lado positivo, hay muchas sinergias potenciales entre ellos. Por ejemplo, el concepto de "contratos de almacén de claves" también podría ser una solución al desafío de las "direcciones" mencionado en la sección anterior: si queremos que los usuarios tengan direcciones persistentes, que no cambien cada vez que el usuario actualiza una clave, podríamos poner metadirecciones ocultas, claves de cifrado y otra información en el contrato de almacén de claves, y usar la dirección del contrato de almacén de claves como "dirección" de un usuario.

Es necesario actualizar una gran cantidad de infraestructura secundaria

El uso de ENS es costoso. Hoy, en junio de 2023, la situación no es tan mala: la tarifa de transacción es significativa, pero sigue siendo comparable a la tarifa de dominio ENS. Registrar zuzalu.eth me costó aproximadamente $ 27, de los cuales $ 11 fueron tarifas de transacción. Pero si tenemos otro mercado alcista, las tarifas se dispararán. Incluso sin aumentos en el precio de ETH, las tarifas de gas que regresan a 200 gwei aumentarían la tarifa de tx de un registro de dominio a $ 104. Por lo tanto, si queremos que la gente realmente use ENS, especialmente para casos de uso como las redes sociales descentralizadas donde los usuarios exigen un registro casi gratuito (y la tarifa de dominio ENS no es un problema porque estas plataformas ofrecen a sus usuarios subdominios), necesitamos que ENS funcione en L2.

Afortunadamente, el equipo de ENS ha dado un paso adelante, ¡y ENS en L2 realmente está sucediendo! ERC-3668 (también conocido como "el estándar CCIP"), junto con ENSIP-10, proporcionan una forma de hacer que los subdominios ENS en cualquier L2 sean verificables automáticamente. El estándar CCIP requiere la creación de un contrato inteligente que describa un método para verificar las pruebas de datos en L2 y un dominio (p. ej. Optinames utiliza ecc.eth) puede ponerse bajo el control de dicho contrato. Una vez que el contrato CCIP controla ecc.eth en L1, el acceso a algún subdominio.ecc.eth implicará automáticamente encontrar y verificar una prueba (p. ej. Merkle) del estado en L2 que realmente almacena ese subdominio en particular.

En realidad, obtener las pruebas implica ir a una lista de URL almacenadas en el contrato, lo que ciertamente se siente como una centralización, aunque yo diría que realmente no lo es: es un modelo de confianza 1 de N (las pruebas no válidas son atrapadas por la lógica de verificación en la función de devolución de llamada del contrato CCIP, y siempre que incluso una de las URL devuelva una prueba válida, eres bueno). La lista de URLs podría contener docenas de ellas.

El esfuerzo de ENS CCIP es una historia de éxito, y debe verse como una señal de que las reformas radicales del tipo que necesitamos son realmente posibles. Pero habrá que hacer muchas más reformas en la capa de aplicación. Algunos ejemplos:

• Muchas dapps dependen de que los usuarios proporcionen firmas fuera de la cadena. Con las cuentas de propiedad externa (EOA, por sus siglas en inglés), esto es fácil. ERC-1271 proporciona una forma estandarizada de hacer esto para billeteras de contratos inteligentes. Sin embargo, muchas dapps todavía no son compatibles con ERC-1271; Tendrán que hacerlo.
• Las dapps que usen "¿es esto una EOA?" para discriminar entre usuarios y contratos (por ejemplo, para evitar la transferencia o hacer cumplir regalías) se romperán. En general, aconsejo no intentar encontrar una solución puramente técnica aquí; Averiguar si una transferencia particular de control criptográfico es o no una transferencia de propiedad real es un problema difícil y probablemente no se pueda resolver sin resolver algunos mecanismos impulsados por la comunidad fuera de la cadena. Lo más probable es que las solicitudes tengan que depender menos de la prevención de transferencias y más de técnicas como los impuestos Harberger.
• Habrá que mejorar la forma en que las billeteras interactúan con las claves de gasto y cifrado. Actualmente, las billeteras a menudo usan firmas deterministas para generar claves específicas de la aplicación: firmar un nonce estándar (por ejemplo, el hash del nombre de la aplicación) con la clave privada de un EOA genera un valor determinista que no se puede generar sin la clave privada, por lo que es seguro en un sentido puramente técnico. Sin embargo, estas técnicas son "opacas" para la billetera, lo que impide que la billetera implemente comprobaciones de seguridad a nivel de interfaz de usuario. En un ecosistema más maduro, la firma, el cifrado y las funcionalidades relacionadas tendrán que ser manejadas por las billeteras de manera más explícita.
• Clientes ligeros (p. ej. Helios) tendrá que verificar las L2 y no solo las L1. Hoy en día, los clientes ligeros se centran en comprobar la validez de los encabezados L1 (mediante el protocolo de sincronización de clientes ligeros) y en verificar las ramas de Merkle del estado L1 y las transacciones arraigadas en el encabezado L1. Mañana, también tendrán que verificar una prueba del estado L2 arraigado en la raíz de estado almacenada en el L1 (una versión más avanzada de esto en realidad miraría las preconfirmaciones de L2).

Las billeteras deberán proteger tanto los activos como los datos

Hoy en día, las billeteras están en el negocio de asegurar activos. Todo vive en la cadena, y lo único que la billetera necesita proteger es la clave privada que actualmente protege esos activos. Si cambia la clave, puede publicar de forma segura su clave privada anterior en Internet al día siguiente. Sin embargo, en un mundo ZK, esto ya no es cierto: la billetera no solo protege las credenciales de autenticación, sino que también contiene sus datos.

Vimos los primeros signos de un mundo así con Zupass, el sistema de identidad basado en ZK-SNARK que se utilizó en Zuzalu. Los usuarios tenían una clave privada que usaban para autenticarse en el sistema, que podía usarse para hacer pruebas básicas como "demostrar que soy residente de Zuzalu, sin revelar cuál". Pero el sistema Zupass también comenzó a tener otras aplicaciones construidas sobre la parte superior, sobre todo sellos (la versión de Zupass de los POAP).

Uno de mis muchos sellos Zupass, que confirma que soy un orgulloso miembro del Team Cat.

La característica clave que ofrecen los sellos sobre los POAP es que los sellos son privados: usted tiene los datos localmente, y solo prueba un sello (o algún cálculo sobre los sellos) a alguien si desea que tenga esa información sobre usted. Pero esto crea un riesgo adicional: si pierdes esa información, pierdes tus sellos.

Por supuesto, el problema de la retención de datos puede reducirse al problema de la retención de una sola clave de cifrado: algún tercero (o incluso la cadena) puede mantener una copia cifrada de los datos. Esto tiene la cómoda ventaja de que las acciones que realice no cambian la clave de cifrado y, por lo tanto, no requieren ninguna interacción con el sistema que mantiene segura la clave de cifrado. Pero aún así, si pierdes tu clave de cifrado, lo pierdes todo. Y por otro lado, si alguien ve su clave de cifrado, verá todo lo que se cifró con esa clave.

La solución de facto de Zupass fue alentar a las personas a almacenar su clave en múltiples dispositivos (p. ej. computadora portátil y teléfono), ya que la posibilidad de que pierdan el acceso a todos los dispositivos al mismo tiempo es pequeña. Podríamos ir más allá y usar el uso compartido de secretos para almacenar la clave, dividida entre varios guardianes.

Este tipo de recuperación social a través de MPC no es una solución suficiente para las billeteras, porque significa que no solo los tutores actuales, sino también los tutores anteriores podrían confabularse para robar sus activos, lo cual es un riesgo inaceptablemente alto. Pero las fugas de privacidad suelen tener un riesgo menor que la pérdida total de activos, y alguien con un caso de uso que exija una alta demanda de privacidad siempre podría aceptar un mayor riesgo de pérdida al no hacer una copia de seguridad de la clave asociada con esas acciones que exigen privacidad.

Para evitar abrumar al usuario con un sistema bizantino de múltiples rutas de recuperación, es probable que las billeteras que admiten la recuperación social deban administrar tanto la recuperación de activos como la recuperación de claves de cifrado.

Volver a la identidad

Uno de los hilos conductores de estos cambios es que el concepto de "dirección", un identificador criptográfico que se utiliza para representarte a "ti" en la cadena, tendrá que cambiar radicalmente. "Instrucciones sobre cómo interactuar conmigo" ya no sería solo una dirección ETH; tendrían que ser, de alguna forma, alguna combinación de múltiples direcciones en múltiples L2, meta-direcciones sigilosas, claves de cifrado y otros datos.

Una forma de hacerlo es hacer de ENS tu identidad: tu registro de ENS podría contener toda esta información, y si envías a alguien bob.eth (o bob.ecc.eth, o...), podrían buscar y ver todo sobre cómo pagar e interactuar con usted, incluso en las formas más complicadas de cruzar dominios y preservar la privacidad.

Pero este enfoque centrado en ENS tiene dos puntos débiles:

• Ata demasiadas cosas a tu nombre. Tu nombre no eres tú, tu nombre es uno de tus muchos atributos. Debería ser posible cambiar su nombre sin tener que desplazarse por todo su perfil de identidad y actualizar un montón de registros en muchas aplicaciones.
• No se pueden tener nombres contrafácticos sin confianza. Una característica clave de UX de cualquier blockchain es la capacidad de enviar monedas a personas que aún no han interactuado con la cadena. Sin tal funcionalidad, hay una trampa 22: interactuar con la cadena requiere pagar tarifas de transacción, lo que requiere... ya teniendo monedas. Las direcciones ETH, incluidas las direcciones de contratos inteligentes con CREATE2, tienen esta característica. Los nombres de ENS no lo hacen, porque si dos Bobs deciden fuera de la cadena que son bob.ecc.eth, No hay forma de elegir cuál de ellos recibe el nombre.

Una posible solución es poner más cosas en el contrato de almacén de claves mencionado en la arquitectura anterior en esta publicación. El contrato de almacén de claves podría contener toda la información sobre usted y cómo interactuar con usted (y con CCIP, parte de esa información podría estar fuera de la cadena), y los usuarios utilizarían su contrato de almacén de claves como su identificador principal. Pero los activos reales que reciben se almacenarían en todo tipo de lugares diferentes. Los contratos de almacén de claves no están vinculados a un nombre y son compatibles con los contrafácticos: puede generar una dirección que solo se puede inicializar mediante un contrato de almacén de claves que tenga ciertos parámetros iniciales fijos.

Otra categoría de soluciones tiene que ver con el abandono total del concepto de direcciones orientadas al usuario, con un espíritu similar al protocolo de pago Bitcoin. Una idea es confiar más en los canales de comunicación directa entre el remitente y el destinatario; por ejemplo, el remitente podría enviar un enlace de reclamación (ya sea como una URL explícita o un código QR) que el destinatario podría utilizar para aceptar el pago como desee.

Independientemente de si el remitente o el destinatario actúan primero, una mayor dependencia de las billeteras que generan directamente información de pago actualizada en tiempo real podría reducir la fricción. Dicho esto, los identificadores persistentes son convenientes (especialmente con ENS), y la suposición de la comunicación directa entre el remitente y el destinatario es realmente complicada en la práctica, por lo que podemos terminar viendo una combinación de diferentes técnicas.

En todos estos diseños, mantener las cosas descentralizadas y comprensibles para los usuarios es primordial. Tenemos que asegurarnos de que los usuarios tengan fácil acceso a una vista actualizada de cuáles son sus activos actuales y qué mensajes se han publicado destinados a ellos. Estos puntos de vista deben depender de herramientas abiertas, no de soluciones propietarias. Se necesitará mucho trabajo para evitar que la mayor complejidad de la infraestructura de pago se convierta en una opaca "torre de abstracción" donde los desarrolladores tengan dificultades para dar sentido a lo que está sucediendo y adaptarlo a nuevos contextos. A pesar de los desafíos, lograr la escalabilidad, la seguridad de la billetera y la privacidad para los usuarios habituales es crucial para el futuro de Ethereum. No se trata solo de la viabilidad técnica, sino de la accesibilidad real para los usuarios habituales. Tenemos que estar a la altura de este desafío.

Renuncia:

1. Este artículo es una reimpresión de [vitalik], Todos los derechos de autor pertenecen al autor original [Vitalik Buterin]. Si hay objeciones a esta reimpresión, comuníquese con el equipo de Gate Learn y ellos lo manejarán de inmediato.
2. Descargo de responsabilidad: Los puntos de vista y opiniones expresados en este artículo son únicamente los del autor y no constituyen ningún consejo de inversión.
3. Las traducciones del artículo a otros idiomas son realizadas por el equipo de Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.