Una de las críticas que muchos han hecho sobre la dirección actual del espacio de las criptomonedas es el aumento de la fragmentación que estamos viendo. Lo que antes era quizás una comunidad más unida centrada en desarrollar la infraestructura común de Bitcoin, ahora es cada vez más una colección de "silos", proyectos discretos trabajando en sus propias cosas separadas. Hay numerosos desarrolladores e investigadores que están trabajando para Ethereum o trabajando en ideas como voluntarios y que pasan mucho tiempo interactuando con la comunidad de Ethereum, y este conjunto de personas se ha unido en un grupo dedicado a construir nuestra visión particular.

Otro colectivo cuasi descentralizado, Bitshares, ha puesto su corazón en su propia visión, combinando su particular combinación de DPOS, activos vinculados al mercado y visión de la blockchain como corporación autónoma descentralizada como una forma de alcanzar sus objetivos políticos de liberalismo de mercado libre y una sociedad sin contratos. Blockstream, la compañía detrás de "sidechains", ha atraído también a su propio grupo de personas y su propio conjunto de visiones y agendas, y lo mismo ocurre con Truthcoin, Maidsafe, NXT y muchos otros.

Un argumento, a menudo planteado por los maximalistas de Bitcoin y los proponentes de sidechains, es que esta fragmentación es perjudicial para el ecosistema de las criptomonedas: en lugar de ir cada uno por nuestro camino y competir por usuarios, deberíamos estar trabajando juntos y cooperando bajo la bandera común de Bitcoin. Como resume Fabian Brian Crane:

Un evento reciente que ha inflamado aún más la discusión es la publicación de la propuesta de sidechains. La idea de las sidechains es permitir la innovación “trustless” o sin confianza de las altcoins ofreciéndoles la misma base monetaria, liquidez y poder de minería de la red Bitcoin.

Para los proponentes, esto representa un esfuerzo crucial para reunir al ecosistema de criptomonedas detrás de su proyecto más exitoso y para construir sobre la infraestructura y el ecosistema ya existentes, en lugar de dispersar esfuerzos en cien direcciones diferentes.

Incluso para aquellos que no están de acuerdo con el maximalismo de Bitcoin, esto parece un punto bastante razonable, y aunque la comunidad de criptomonedas no debería necesariamente estar unida bajo la bandera de "Bitcoin", se podría argumentar que necesitamos estar juntos de alguna manera, trabajando para construir un ecosistema más unificado. Si Bitcoin no es lo suficientemente poderoso para ser una columna vertebral viable para la vida, el universo cripto y todo lo demás, entonces, ¿por qué no construir una computadora descentralizada mejor y más escalable en su lugar y construir todo sobre eso? Los hipercubos ciertamente parecen lo suficientemente poderosos como para valer la pena ser maximalistas sobre ellos, si eres el tipo de persona a quien le resultan intuitivamente atractivas las propuestas de un-X-para-gobernarlos-todos, y los miembros de Bitshares, Blockstream y otros "silos" a menudo están bastante ansiosos por creer lo mismo sobre sus propias soluciones particulares, ya sea que se basen en minería combinada, DPOS más BitAssets u otra cosa.

Entonces, ¿por qué no? Si realmente hay un mecanismo de consenso que es el mejor, ¿por qué no deberíamos tener una gran fusión entre los diversos proyectos, encontrar la mejor clase de computadora descentralizada para impulsar como base para la criptoeconomía y avanzar juntos bajo un sistema unificado? En algunos aspectos, esto parece noble; la "fragmentación" ciertamente tiene propiedades indeseables, y es natural ver "trabajar juntos" como algo bueno. En realidad, sin embargo, aunque más cooperación ciertamente es útil, y este blog post describirá más adelante cómo y por qué, los deseos de consolidación extrema o de el-ganador-se-lleva-todo están en gran medida exactamente equivocados; no solo la fragmentación no es tan mala, sino que es inevitable, y probablemente la única manera en que este espacio puede prosperar razonablemente.

Estar de acuerdo en que no estamos de acuerdo

¿Por qué ha estado ocurriendo la fragmentación y por qué deberíamos permitir que continúe? A la primera pregunta, y también simultáneamente a la segunda, la respuesta es simple: nos fragmentamos porque no estamos de acuerdo. En particular, consideremos algunas de las siguientes afirmaciones, todas las cuales creo, pero que en muchos casos son una desviación sustancial de las filosofías de muchas otras personas y proyectos:

1. No creo que la subjetividad débil sea un problema tan grande. Sin embargo, grados mucho más altos de subjetividad e intrínseca dependencia del consenso social extra-protocolo aún no me resultan cómodos.

2. Considero que los $600 millones al año que Bitcoin desperdicia en electricidad para proof of work es una tragedia ambiental y económica absoluta.

3. Creo que los ASIC son un problema serio, y que como resultado de ello, Bitcoin se ha vuelto cualitativamente menos seguro en los últimos dos años.

4. Considero que Bitcoin (o cualquier otra moneda de oferta fija) es demasiado incorregiblemente volátil para ser alguna vez una unidad estable de cuenta, y creo que el mejor camino hacia la estabilidad de precios de las criptomonedas es experimentar con políticas monetarias flexibles inteligentemente diseñadas (es decir, NO "el mercado" o "el banco central de Bitcoin"). Sin embargo, no estoy interesado en someter la política monetaria de criptomonedas bajo ningún tipo de control centralizado.

5. Tengo una mentalidad sustancialmente más antiinstitucional/libertaria/anarquista que algunas personas, pero sustancialmente menos que otras (y, de paso, no soy un economista austríaco). En general, creo que hay valor en ambos lados de la cerca, y creo firmemente en ser diplomático y trabajar juntos para hacer del mundo un lugar mejor.

6. No estoy a favor de que haya una-moneda-para-gobernarlas-todas, en la criptoeconomía o en cualquier lugar.

7. Creo que las ventas de tokens son una herramienta increíble para la monetización de protocolos descentralizados, y que todos los que atacan el concepto de plano están haciendo un mal servicio a la sociedad al amenazar con quitar algo hermoso. Sin embargo, estoy de acuerdo en que el modelo implementado por nosotros y otros grupos hasta ahora tiene sus defectos y deberíamos estar experimentando activamente con diferentes modelos que intenten alinear mejor los incentivos.

8. Creo que la futarquía es lo suficientemente prometedora como para valer la pena intentarlo, particularmente en un contexto de gobernanza de blockchain.

9. Considero que la economía y la teoría de juegos son una parte clave del análisis de protocolos criptoeconómicos, y considero que el principal déficit académico de la comunidad de criptomonedas no es la ignorancia de la ciencia de la computación avanzada, sino más bien la economía y la filosofía. Deberíamos acercarnos más a http://lesswrong.com/.

10. Veo una de las principales razones por las que la gente adoptará tecnologías descentralizadas (blockchains, whisper, DHTs) en la práctica como el simple hecho de que los desarrolladores de software son perezosos, y no desean lidiar con las complejidades de mantener un sitio web centralizado.

11. Considero la metáfora de la blockchain como corporación autónoma descentralizada útil, pero limitada. Particularmente, creo que nosotros, como desarrolladores de criptomonedas, deberíamos aprovechar este período quizás breve en el que la criptomoneda sigue siendo una industria controlada por idealistas para diseñar instituciones que maximicen las métricas de bienestar social utilitarias, no el beneficio (no, no son equivalentes, principalmente debido a estas).

Probablemente hay muy pocas personas que estén de acuerdo conmigo en cada uno de los puntos anteriores. Y no solo soy yo quien tiene mis propias opiniones peculiares. Como otro ejemplo, considera el hecho de que el CTO de OpenTransactions, Chris Odom, dice cosas como esta:

Lo que se necesita es reemplazar las entidades de confianza con sistemas de prueba criptográfica. Cualquier entidad que veas en la comunidad de Bitcoin en la que tengas que confiar va a desaparecer, va a dejar de existir... El sueño de Satoshi era eliminar por completo las entidades [de confianza], ya sea eliminando el riesgo por completo o distribuyendo el riesgo de una manera que esté prácticamente eliminado.

Mientras tanto, otros sienten la necesidad de decir cosas como esta:

Expresado de otra manera, las redes comerciales viables con confianza reducida no necesitan proteger al mundo de los operadores de plataformas. Necesitarán proteger a los operadores de plataformas del mundo por el beneficio de los usuarios de la plataforma.

Por supuesto, si ves el beneficio principal de las criptomonedas como una evasión de regulaciones, entonces esa segunda cita también tiene sentido, pero de una manera completamente diferente a como su autor original lo pretendía --pero eso una vez más solo sirve para mostrar cuán diferente piensan las personas. Algunas personas ven a las criptomonedas como una revolución capitalista, otras como una revolución igualitaria, y otras ven todo lo intermedio. Algunos ven el consenso humano como algo muy frágil y corruptible y a las criptomonedas como un faro de luz que puede reemplazarlo con matemáticas duras; otros ven el consenso de criptomonedas solo como una extensión del consenso humano, hecho más eficiente con la tecnología. Algunos consideran que la mejor manera de lograr que los criptoactivos tengan paridad con el dólar es a través de esquemas de derivados financieros de doble moneda; otros ven el enfoque más simple como usar blockchains para representar reclamos sobre activos del mundo real (y aún otros piensan que Bitcoin eventualmente será más estable que el dólar por sí solo). Algunos piensan que la escalabilidad se logra mejor "escalando hacia arriba"; otros creen que la opción definitivamente superior es "escalando hacia afuera".

Por supuesto, muchos de estos problemas son inherentemente políticos, y algunos involucran bienes públicos; en esos casos, vivir y dejar vivir no siempre es una solución viable. Si una plataforma particular permite externalidades negativas, o amenaza con empujar a la sociedad hacia un equilibrio subóptimo, entonces no puedes "optar por no participar" simplemente usando tu plataforma en su lugar. Allí, puede ser necesaria alguna forma de censura impulsada por efectos de red o incluso, en casos extremos, por ataques del 51%. En algunos casos, las diferencias están relacionadas con bienes privados y son principalmente simplemente una cuestión de creencias empíricas. Si creo que SchellingDollar es el mejor esquema para la estabilidad de precios, y otros prefieren Seignorage Shares o NuBits, entonces después de unos años o décadas, un modelo probará funcionar mejor, reemplazará a su competencia, y eso será todo.

En otros casos, sin embargo, las diferencias se resolverán de una manera diferente: resultará que las propiedades de algunos sistemas son más adecuadas para algunas aplicaciones, y otros sistemas más adecuados para otras aplicaciones, y todo se especializará naturalmente en aquellos casos de uso donde funcione mejor. Como han señalado varios comentaristas, para aplicaciones de consenso descentralizado en el mundo financiero convencional, es probable que los bancos no estén dispuestos a aceptar una red gestionada por nodos anónimos; en este caso, algo como Ripple será más útil. Pero para Silk Road 4.0, el enfoque exactamente opuesto es el único camino a seguir, y para todo lo demás es un análisis de costo-beneficio todo el tiempo. Si los usuarios desean redes especializadas en realizar funciones específicas de manera altamente eficiente, entonces existirán redes para eso, y si los usuarios desean una red de propósito general con un alto efecto de red entre aplicaciones en cadena, eso también existirá. Como señala David Johnston, las blockchains son como los lenguajes de programación: cada uno tiene sus propias propiedades particulares, y pocos desarrolladores se adhieren religiosamente a un solo lenguaje exclusivamente, sino que usamos cada uno en los casos específicos para los que está mejor adaptado.

Espacio para la Cooperación

Sin embargo, como se mencionó anteriormente, esto no significa que simplemente debamos seguir nuestro propio camino e intentar ignorarnos, o peor aún, sabotearnos activamente unos a otros. Incluso si todos nuestros proyectos necesariamente se están especializando hacia diferentes objetivos, aún hay una oportunidad sustancial para mucha menos duplicación de esfuerzos y más cooperación. Esto es cierto en múltiples niveles. Primero, observemos un modelo del ecosistema de criptomonedas, o quizás, una visión de cómo podría verse en 1 a 5 años:

Ethereum tiene su propia presencia en prácticamente todos los niveles:

• Consensus: Blockchain de Ethereum, voto Schelling de disponibilidad de datos (quizás para Ethereum 2.0)

• Economía: ether, un token independiente, así como investigación sobre propuestas de stablecoin

• Servicios de Blockchain: registro de nombres

• Servicios fuera de la cadena: Whisper (mensajería), web de confianza (en progreso)

• Interop: puente BTC-a-ether (en progreso)

• Navegadores: Mist

Ahora, considera algunos otros proyectos que están intentando construir ecosistemas holísticos de algún tipo. Bitshares tiene al menos:

• Consensus: DPOS

• Economía: BTSX y BitAssets

• Servicios de Blockchain: intercambio descentralizado BTS

• Navegadores: cliente de Bitshares (aunque no es exactamente un navegador en el mismo concepto)

Maidsafe tiene:

• Consensus: red SAFE

• Economía: Safecoin

• Servicios fuera de la cadena: tabla de hash distribuida, Maidsafe Drive

BitTorrent ha anunciado sus planes para Maelstrom, un proyecto destinado a cumplir una función bastante similar a Mist, aunque mostrando su propia tecnología (que no se basa en blockchain). Generalmente, los proyectos de criptomonedas construyen su propia blockchain, una moneda y un cliente, aunque es común que se bifurque un único cliente en los casos menos innovadores. Los sistemas de registro de nombres y gestión de identidades ahora son una docena. Y, por supuesto, casi todos los proyectos se dan cuenta de que necesitan algún tipo de reputación y red de confianza.

Ahora, pintemos un cuadro de un mundo alternativo. En lugar de tener una colección de ecosistemas verticalmente integrados claramente disjuntos, con cada uno construyendo sus propios componentes para todo, imagina un mundo donde Mist podría usarse para acceder a Ethereum, Bitshares, Maidsafe o cualquier otra red de infraestructura descentralizada importante, con nuevas redes descentralizadas instalables de manera similar a los plugins para Flash y Java dentro de Chrome y Firefox. Imagina que los datos de reputación en la red de confianza para Ethereum también podrían reutilizarse en otros proyectos. Imagina StorJ funcionando dentro de Maelstrom como una dapp, utilizando Maidsafe para un backend de almacenamiento de archivos, y utilizando la blockchain de Ethereum para mantener los contratos que incentivan el almacenamiento y la descarga continuos. Imagina identidades que sean automáticamente transferibles a través de cualquier red criptográfica, siempre que utilicen los mismos algoritmos criptográficos subyacentes (por ejemplo, ECDSA + SHA3).

La idea clave aquí es la siguiente: aunque algunas de las capas en el ecosistema están inextricablemente vinculadas -por ejemplo, una dapp a menudo corresponde a un servicio específico en la blockchain de Ethereum-, en muchos casos las capas pueden diseñarse fácilmente para ser mucho más modulares, permitiendo que cada producto en cada capa compita por separado según sus propios méritos. Los navegadores son quizás el componente más separable; la mayoría de los conjuntos de servicios de blockchain de nivel inferior razonablemente holísticos tienen necesidades similares en términos de qué aplicaciones pueden ejecutarse en ellos, por lo que tiene sentido que cada navegador soporte cada plataforma. Los servicios fuera de la cadena también son un objetivo para la abstracción; cualquier aplicación descentralizada, independientemente de la tecnología blockchain que utilice, debería ser libre de usar Whisper, Swarm, IPFS o cualquier otro servicio que los desarrolladores inventen. Los servicios en cadena, como la provisión de datos, teóricamente pueden construirse de manera que interactúen con múltiples cadenas.

Además, hay muchas oportunidades para colaborar en la investigación y el desarrollo fundamentales. La discusión sobre prueba de trabajo, prueba de participación, sistemas de moneda estable y escalabilidad, así como otros problemas difíciles de la criptoeconomía, pueden ser fácilmente mucho más abiertos, de modo que los diversos proyectos puedan beneficiarse y ser más conscientes de los desarrollos de los demás. Los algoritmos básicos y las mejores prácticas relacionadas con las capas de red, las implementaciones de algoritmos criptográficos y otros componentes de bajo nivel pueden y deben ser compartidos. Las tecnologías de interoperabilidad deben desarrollarse para facilitar el intercambio e interacción fáciles entre servicios y entidades descentralizadas en una plataforma y otra. El Cryptocurrency Research Group es una iniciativa que planeamos apoyar inicialmente, con la esperanza de que crezca para florecer independientemente de nosotros mismos, con el objetivo de promover este tipo de cooperación. Otras instituciones formales e informales sin duda pueden ayudar a apoyar el proceso.

Esperemos que en el futuro veamos muchos más proyectos existiendo de una manera mucho más modular, viviendo en solo una o dos capas del ecosistema de criptomonedas y proporcionando una interfaz común que permita que cualquier mecanismo en cualquier otra capa trabaje con ellos. Si el espacio de las criptomonedas avanza lo suficiente, entonces incluso Firefox y Chrome podrían terminar adaptándose para procesar protocolos de aplicaciones descentralizadas también. Un viaje hacia tal ecosistema no es algo que necesite ser apresurado de inmediato; en este punto, tenemos bastante poca idea de qué tipos de servicios impulsados por blockchain estarán usando las personas en primer lugar, lo que hace difícil determinar exactamente qué tipo de interoperabilidad sería realmente útil. Sin embargo, las cosas lentamente pero seguramente están dando sus primeros pasos en esa dirección; Decerver de Eris, su propio "navegador" en el mundo descentralizado, admite el acceso a Bitcoin, Ethereum, sus propias blockchains Thelonious, así como una red de alojamiento de contenido IPFS.

Hay espacio para que muchos proyectos que actualmente están en el espacio cripto 2.0 tengan éxito, y por lo tanto, tener una mentalidad de que el ganador se lo lleva todo en este punto es completamente innecesaria y dañina. Todo lo que necesitamos hacer ahora para comenzar el viaje por un mejor camino es vivir con la suposición de que todos estamos construyendo nuestras propias plataformas, ajustadas a nuestro propio conjunto particular de preferencias y parámetros, pero al final del día una pluralidad de redes tendrá éxito y necesitaremos vivir con esa realidad, así que mejor comenzamos a prepararnos para eso ahora.

Feliz año nuevo y espero con ansias un emocionante 2015 007 Anno Satoshii.

Agradecimientos especiales a Ansgar Dietrichs, Barnabe Monnot y Davide Crapis por sus comentarios y revisión.

En Ethereum, los recursos estaban limitados y tarifados hasta hace poco mediante un único recurso denominado "gas". El gas mide la cantidad de "esfuerzo computacional" necesario para procesar una transacción o bloque dado. El gas agrupa múltiples tipos de "esfuerzo", notablemente:

• Computación cruda (por ejemplo, ADD, MULTIPLY)

• Lectura y escritura en el almacenamiento de Ethereum (por ejemplo, SSTORE, SLOAD, transferencias de ETH)

• Ancho de banda de datos

• Costo de generar una prueba ZK-SNARK del bloque

Por ejemplo, esta transacción que envié costó un total de 47,085 gas. Esto se divide entre (i) un "costo base" de 21000 gas, (ii) 1556 gas por los bytes en los datos de llamada incluidos como parte de la transacción (iii) 16500 gas por la lectura y escritura en almacenamiento, (iv) 2149 gas por hacer un “log” o registro, y el resto por la ejecución EVM. La tarifa de la transacción que un usuario debe pagar es proporcional al gas que consume la transacción. Un bloque puede contener hasta un máximo de 30 millones de gas, y los precios del gas se ajustan constantemente a través del mecanismo de targeting de EIP-1559, asegurando que en promedio, los bloques contengan 15 millones de gas.

Este enfoque tiene una gran eficiencia: debido a que todo se fusiona en un recurso virtual, conduce a un diseño de mercado muy simple. Optimizar una transacción para minimizar costos es fácil, optimizar un bloque para recolectar las tarifas más altas posibles es relativamente fácil (sin incluir MEV), y no hay incentivos extraños que alienten a algunas transacciones a agruparse con otras para ahorrar en tarifas.

Sin embargo, este enfoque también tiene una gran ineficiencia: trata diferentes recursos como si fueran mutuamente convertibles, cuando los límites subyacentes reales de lo que la red puede manejar no lo son. Una forma de entender este problema es mirar este diagrama:

El límite de gas impone una restricción de x1 * data+x2 * computation < N. La restricción de seguridad subyacente real a menudo está más cerca de max (x1 * data,x2 * computation) < N. Esta discrepancia lleva a que el límite de gas excluya innecesariamente bloques que son realmente seguros, o acepte bloques que son realmente inseguros, o alguna mezcla de ambos.

Si hay recursos que tienen límites de seguridad distintos, entonces el gas unidimensional plausiblemente reduce el rendimiento hasta en un factor de n. Por esta razón, ha habido interés durante mucho tiempo en el concepto de gas multidimensional, y con el EIP-4844 ahora tenemos gas multidimensional funcionando en Ethereum hoy. Esta publicación explora los beneficios de este enfoque y las perspectivas para aumentarlo aún más.

Blobs: gas multidimensional en Dencun

Al inicio de este año, el bloque promedio tenía un tamaño de 150 kB. Una gran parte de ese tamaño corresponde a datos de rollup: protocolos de capa 2 que almacenan datos en la cadena por seguridad. Estos datos eran costosos: aunque las transacciones en los rollups costaban aproximadamente 5-10x menos que las transacciones correspondientes en la capa 1 de Ethereum, incluso ese costo era demasiado alto para muchos casos de uso.

¿Por qué no reducir el costo del gas para los "calldata” o datos de llamada (actualmente 16 gas por byte no cero y 4 gas por zero byte) para abaratar los rollups? Ya lo hicimos antes, podríamos hacerlo de nuevo. La respuesta aquí es: el tamaño máximo de un bloque en el peor de los casos era de 30,000,000 / 16 = 1,875,000 nonzero bites, y la red ya apenas puede manejar bloques de ese tamaño. Reducir los costos por otro factor de 4x aumentaría el máximo a 7.5 MB, lo que sería un gran riesgo para la seguridad.

Este problema terminó siendo manejado mediante la introducción de un espacio separado para datos amigables con los rollups, conocidos como "blobs", en cada bloque. Los dos recursos tienen precios y límites separados: después del hard fork de Dencun, un bloque de Ethereum puede contener como máximo (i) 30 millones de gas, y (ii) 6 blobs, que pueden contener aproximadamente 125 kB de datos de llamada cada uno. Ambos recursos tienen precios separados, ajustados por mecanismos de fijación de precios similares a EIP-1559, con el objetivo de un uso promedio de 15 millones de gas y 3 blobs por bloque.

Como resultado, los rollups se han vuelto 100 veces más baratos, el volumen de transacciones en los rollups ha aumentado más de 3 veces, y el tamaño máximo teórico del bloque solo aumentó ligeramente: de aproximadamente 1.9 MB a aproximadamente 2.6 MB.

Gas multidimensional y clientes sin estado

En un futuro cercano, surgirá un problema similar en cuanto a las pruebas de almacenamiento para los “stateless clients” o clientes sin estado. Los clientes sin estado son un nuevo tipo de cliente que podrá verificar la cadena sin almacenar muchos datos o ninguno localmente. Los clientes sin estado logran esto aceptando pruebas de las piezas específicas del estado de Ethereum que las transacciones en ese bloque necesitan tocar.

Una lectura de almacenamiento cuesta entre 2100 y 2600 gas dependiendo del tipo de lectura, y las escrituras de almacenamiento cuestan más. En promedio, un bloque realiza algo así como 1000 lecturas y escrituras de almacenamiento (incluyendo verificaciones de saldo de ETH, llamadas a SSTORE y SLOAD, lectura de código de contrato y otras operaciones). El máximo teórico, sin embargo, es de 30,000,000 / 2,100 = 14,285 lecturas. La carga de ancho de banda de un cliente sin estado es directamente proporcional a este número.

Hoy, el plan para apoyar a los clientes sin estado consiste en cambiar el diseño del árbol de estado de Ethereum de árboles Merkle Patricia a árboles Verkle. Sin embargo, los árboles Verkle no son resistentes a la computación cuántica y no son óptimos para las nuevas generaciones de sistemas de prueba STARK. Como resultado, muchas personas están interesadas en apoyar a los clientes sin estado mediante árboles Merkle binarios y STARKs en su lugar, ya sea omitiendo completamente Verkle o actualizando un par de años después de la transición a Verkle, una vez que los STARKs hayan madurado más.

Las pruebas STARK de las ramas de árboles de hash binarios tienen muchas ventajas, pero tienen la debilidad clave de que las pruebas tardan mucho en generarse: mientras que los árboles Verkle pueden probar más de cien mil valores por segundo, los STARK basados en hash típicamente pueden probar solo un par de miles de hashes por segundo, y probar cada valor requiere una "rama" que contiene muchos hashes.

Dada la información proyectada hoy de sistemas de prueba hiper-optimizados como Binius y Plonky3, y hashes especializados como Vision-Mark-32, parece probable que por algún tiempo estemos en un régimen donde sea práctico probar 1,000 valores en menos de un segundo, pero no 14,285 valores. Los bloques promedio estarían bien, pero los bloques en el peor caso, potencialmente publicados por un atacante, romperían la red.

La forma "predeterminada" en que hemos manejado tal escenario es mediante la re-precificación: hacer la lectura de almacenamiento más cara para reducir el máximo por bloque a algo más seguro. Sin embargo, ya hemos hecho esto muchas veces, y hacerlo de nuevo haría que muchas aplicaciones fueran demasiado caras. Un enfoque mejor sería el gas multidimensional: limitar y cobrar por el acceso al almacenamiento por separado, manteniendo el uso promedio en 1,000 accesos de almacenamiento por bloque, pero estableciendo un límite por bloque de, por ejemplo, 2,000.

Gas multidimensional más generalmente

Otro recurso que vale la pena considerar es el crecimiento del tamaño del estado: operaciones que aumentan el tamaño del estado de Ethereum, que los nodos completos necesitarán mantener de ahí en adelante. La propiedad única del crecimiento del tamaño del estado es que la razón para limitarlo proviene completamente del uso sostenido a largo plazo, y no de picos. Por lo tanto, podría ser valioso agregar una dimensión de gas separada para operaciones que aumentan el tamaño del estado (por ejemplo, SSTORE de cero a no cero, creación de contratos), pero con un objetivo diferente: podríamos establecer un precio flotante para apuntar a un uso promedio específico, pero no establecer ningún límite por bloque en absoluto.

Esto muestra una de las propiedades poderosas del gas multidimensional: nos permite preguntar por separado (i) cuál es el uso promedio ideal y (ii) cuál es el máximo uso seguro por bloque, para cada recurso. En lugar de establecer precios de gas basados en máximos por bloque, y permitir que el uso promedio siga, tenemos 2n grados de libertad para establecer 2n parámetros, ajustando cada uno según lo que sea seguro para la red.

Situaciones más complicadas, como aquellas en las que dos recursos tienen consideraciones de seguridad que son parcialmente aditivas, podrían manejarse haciendo que un opcode o recurso cueste cierta cantidad de múltiples tipos de gas (por ejemplo, un SSTORE de cero a no cero podría costar 5000 gas de prueba de cliente sin estado y 20000 gas de expansión de almacenamiento).

Máximo por transacción: la forma más débil pero más fácil de implementar el gas multidimensional

Sea x1 el costo en gas de los datos y x2 el costo en gas de la computación, entonces en un sistema de gas unidimensional podemos escribir el costo en gas de una transacción como:

gas = x1 * data + x2 * computación

En este esquema, en lugar de ello, definimos el costo en gas de una transacción como:

gas = max ( x1 * data, x2 * computación)

Es decir, en lugar de que se cobre a una transacción por datos más computación, la transacción se cobra en base a cuál de los dos recursos consume más. Esto puede extenderse fácilmente para cubrir más dimensiones. Por ejemplo:

max(…, x3 * storage_access)

Debería ser fácil ver cómo esto mejora el rendimiento mientras preserva la seguridad. La cantidad máxima teórica de datos en un bloque sigue siendo GASLIMIT / x1, exáctamente la misma que en el esquema de gas unidimensional. De manera similar, la cantidad máxima teórica de cómputo es GASLIMIT / x2, de nuevo, la misma que en el esquema de gas unidimensional. Sin embargo, el costo en gas de cualquier transacción que consume tanto datos como cómputo disminuye.

Este es aproximadamente el esquema empleado en la propuesta EIP-7623, para reducir el tamaño máximo del bloque mientras se aumenta aún más el número de blobs. El mecanismo preciso en EIP-7623 es ligeramente más complicado: mantiene el precio actual de los datos de llamada de 16 gas por byte, pero agrega un "precio mínimo" de 48 gas por byte; una transacción paga el mayor entre (16 * bytes + execution_gas) y (48 * bytes). Como resultado, EIP-7623 disminuye el calldata máximo teórico de transacción en un bloque de aproximadamente 1.9 MB a aproximadamente 0.6 MB, mientras deja los costos de la mayoría de las aplicaciones sin cambios. El beneficio de este enfoque es que es un cambio muy pequeño desde el esquema actual de gas unidimensional, por lo que es muy fácil de implementar.

Hay dos inconvenientes:

1. Las transacciones que consumen muchos recursos en una sola área todavía se cargan innecesariamente con una gran cantidad, incluso si todas las otras transacciones en el bloque usan poco de ese recurso.

2. Crea incentivos para que las transacciones con gran cantidad de datos y las que requieren mucho cálculo se fusionen en un paquete para ahorrar costos.

Podría argumentar que una regla al estilo de EIP-7623, tanto para los datos de llamada de las transacciones como para otros recursos, puede traer beneficios suficientemente grandes como para valer la pena a pesar de estos inconvenientes. Sin embargo, si estamos dispuestos a invertir un esfuerzo de desarrollo significativamente mayor, hay un enfoque más ideal.

EIP-1559 multidimensional: la estrategia ideal pero más compleja

Primero, repasemos cómo funciona el EIP-1559 "regular". Nos centraremos en la versión que se introdujo en el EIP-4844 para blobs, ya que es matemáticamente más elegante.

Rastreamos un parámetro, excess_blobs. Durante cada bloque, establecemos:

excess_blobs <-- max(excess_blobs + len(block.blobs) - TARGET, 0)

Donde TARGET = 3. Es decir, si un bloque tiene más blobs que el objetivo, excess_blobs aumenta, y si un bloque tiene menos que el objetivo, disminuye. Luego establecemos blob_basefee = exp(excess_blobs / 25.47), donde exp es una aproximación de la función exp(x) = 2.71828x.

Es decir, cada vez que excess_blobs aumenta en aproximadamente 25, la tarifa base de los blobs aumenta en un factor de aproximadamente 2.7. Si los blobs se vuelven demasiado caros, el uso promedio disminuye y excess_blobs comienza a disminuir, bajando automáticamente el precio de nuevo. El precio de un blob se ajusta constantemente para asegurarse de que, en promedio, los bloques estén medio llenos, es decir, contengan un promedio de 3 blobs cada uno.

Si hay un pico de uso a corto plazo, entonces el límite entra en juego: cada bloque solo puede contener un máximo de 6 blobs, y en tal circunstancia las transacciones pueden competir entre sí aumentando sus tarifas de prioridad. En el caso normal, sin embargo, cada blob solo necesita pagar el blob_basefee más una pequeña tarifa de prioridad extra como incentivo para ser incluido.

Este tipo de precio existió en Ethereum para el gas durante años: un mecanismo muy similar se introdujo con el EIP-1559 en 2020. Con el EIP-4844, ahora tenemos dos precios flotantes separados para el gas y para los blobs.

En principio, podríamos agregar más tarifas flotantes separadas para la lectura de almacenamiento y otros tipos de operaciones, aunque con una advertencia que expandiré en la siguiente sección.

Para los usuarios, la experiencia es notablemente similar a la de hoy: en lugar de pagar una tarifa base, pagas dos tarifas base, pero tu billetera puede abstraer eso de ti y simplemente mostrarte la tarifa esperada y la tarifa máxima que puedes esperar pagar.

Para los constructores de bloques, la mayoría del tiempo la estrategia óptima es la misma que hoy: incluir cualquier cosa que sea válida. La mayoría de los bloques no están llenos, ni en gas ni en blobs. El caso desafiante es cuando hay suficiente gas o suficientes blobs para superar el límite del bloque, y el constructor necesita resolver potencialmente un problema de la mochila multidimensional para maximizar sus ganancias. Sin embargo, incluso allí existen algoritmos de aproximación bastante buenos, y las ganancias de hacer algoritmos propietarios para optimizar las ganancias en este caso son mucho menores que las ganancias de hacer lo mismo con MEV.

Para los desarrolladores, el principal desafío es la necesidad de rediseñar características del EVM y su infraestructura circundante, que actualmente están diseñadas alrededor de un precio y un límite, en un diseño que acomode múltiples precios y múltiples límites. Un problema para los desarrolladores de aplicaciones es que la optimización se vuelve un poco más difícil: en algunos casos, ya no puedes decir de manera unívoca que A es más eficiente que B, porque si A usa más datos de llamada pero B usa más ejecución, entonces A podría ser más barato cuando los datos de llamada son baratos, y más caro cuando los datos de llamada son caros. Sin embargo, los desarrolladores todavía podrían obtener resultados razonablemente buenos al optimizar basándose en precios promedio históricos a largo plazo.

Precios multidimensionales, la EVM y las sub-llamadas

Existe un problema que no apareció con los blobs, y que no aparecerá con el EIP-7623 o incluso con una implementación "completa" de precios multidimensionales para los datos de llamada, pero que sí aparecerá si intentamos tarificar por separado los accesos al estado, o cualquier otro recurso: los límites de gas en las sub-llamadas.

Los límites de gas en la EVM existen en dos lugares. Primero, cada transacción establece un límite de gas, que limita la cantidad total de gas que se puede usar en esa transacción. Segundo, cuando un contrato llama a otro contrato, la llamada puede establecer su propio límite de gas. Esto permite que los contratos llamen a otros contratos en los que no confían, y aún así garantizar que tendrán gas suficiente para realizar otras computaciones después de esa llamada.

El desafío es el siguiente: hacer que el gas sea multidimensional entre diferentes tipos de ejecución parece requerir que las sub-llamadas proporcionen múltiples límites para cada tipo de gas, lo que requeriría un cambio muy profundo en el EVM, y no sería compatible con las aplicaciones existentes.

Esta es una razón por la cual las propuestas de gas multidimensional a menudo se detienen en dos dimensiones: datos y ejecución. Los datos (ya sea calldata de transacciones o blobs) solo se asignan fuera del EVM, por lo que nada dentro del EVM necesita cambiar para que el calldata o los blobs tengan precios separados.

Podemos pensar en una "solución al estilo EIP-7623" para este problema. Aquí hay una implementación simple: durante la ejecución, se cobra 4 veces más por las operaciones de almacenamiento; para simplificar el análisis, digamos 10000 gas por operación de almacenamiento. Al final de la transacción, se reembolsa min(7500 * storage_operations, execution_gas). El resultado sería que, después de restar el reembolso, se le cobraría al usuario:

execution_gas + 10000 * storage_operations - min(7500 * storage_operations, execution_gas)

Lo que es igual a:

max(execution_gas + 2500 * storage_operations, 10000 * storage_operations)

Esto refleja la estructura del EIP-7623. Otra manera de hacerlo es rastrear storage_operations y execution_gas en tiempo real, y cobrar 2500 o 10000 dependiendo de cuánto aumente max(execution_gas + 2500 * storage_operations, 10000 * storage_operations) en el momento en que se llama al opcode. Esto evita la necesidad de que las transacciones sobreasignen gas que en su mayoría recuperarán a través de reembolsos.

No obtenemos permisos detallados para sub-llamadas: una sub-llamada podría consumir toda la "asignación" de una transacción para operaciones de almacenamiento baratas. Pero sí obtenemos algo suficientemente bueno, donde un contrato que realiza una sub-llamada puede establecer un límite y asegurarse de que, una vez que la sub-llamada termina de ejecutarse, la llamada principal todavía tiene suficiente gas para hacer cualquier post-procesamiento que necesite realizar.

La solución "más sencilla a la tarificación multidimensional completa" que puedo pensar es tratamos los límites de gas de sub-llamadas como proporcionales. Es decir, supongamos que hay k diferentes tipos de ejecución, y cada transacción establece un límite multidimensional L1… Lk. Supongamos que, en el punto actual de la ejecución, el gas restante es g1… gk. Supongamos que se llama a un opcode CALL, con un límite de gas de sub-llamada S. Dejemos que s1 = S y luego s2 = s1 / g1 * g2, s3 = s1 / g1 * g3 y así sucesivamente.

Es decir, tratamos el primer tipo de gas (realísticamente, ejecución de VM) como una especie de "unidad de cuenta" privilegiada, y luego asignamos los otros tipos de gas de manera que la sub-llamada obtenga el mismo porcentaje de gas disponible en cada tipo. Esto es algo feo, pero maximiza la compatibilidad con versiones anteriores. Si queremos hacer el esquema más "neutral" entre diferentes tipos de gas, a costa de sacrificar la compatibilidad con versiones anteriores, simplemente podríamos hacer que el parámetro del límite de gas de sub-llamada represente una fracción (por ejemplo, [1...63] / 64) del gas restante en el contexto actual).

En cualquier caso, sin embargo, vale la pena enfatizar que una vez que comienzas a introducir gas de ejecución multidimensional, el nivel inherente de fealdad aumenta, y esto parece difícil de evitar. Por lo tanto, nuestra tarea es hacer un intercambio complicado: ¿aceptamos algo más de fealdad a nivel de EVM, con el fin de desbloquear de manera segura ganancias significativas de escalabilidad en L1, y si es así, cuál propuesta específica funciona mejor para la economía del protocolo y los desarrolladores de aplicaciones? Es muy probable que no sea ninguna de las que mencioné anteriormente, y todavía hay espacio para idear algo más elegante y mejor.

Agradecimientos especiales a los equipos de Worldcoin y Modulus Labs, Xinyuan Sun, Martin Koeppelmann e Illia Polosukhin por sus comentarios y discusiones.

Muchas personas a lo largo de los años me han hecho una pregunta similar: ¿cuáles son las intersecciones entre cripto e IA que considero más fructíferas? Es una pregunta razonable: cripto e IA son las dos principales tendencias tecnológicas profundas (de software) de la última década, y simplemente parece que debe haber algún tipo de conexión entre las dos. Es fácil imaginar sinergias a un nivel superficial: la descentralización de cripto puede equilibrar la centralización de IA, la IA es opaca y cripto aporta transparencia, la IA necesita datos y las cadenas de bloques son buenas para almacenar y rastrear datos. Pero a lo largo de los años, cuando la gente me pedía que profundizara y hablara de aplicaciones específicas, mi respuesta ha sido decepcionante: "sí, hay algunas cosas pero no mucho".

En los últimos tres años, con el surgimiento de una IA mucho más potente en forma de LLMs modernos, y el surgimiento de cripto mucho más potente en forma de soluciones de escalado de blockchain, pero también de ZKPs, FHE, (de 2 partes y N-partes) MPC, estoy empezando a ver este cambio. De hecho, hay algunas aplicaciones prometedoras de IA dentro de los ecosistemas de blockchain, o de IA junto con criptografía, aunque es importante tener cuidado con cómo se aplica la IA. Un desafío particular es: en criptografía, el código abierto es la única manera de hacer algo verdaderamente seguro, pero en IA, que un modelo (o incluso sus datos de entrenamiento) sea abierto aumenta mucho su vulnerabilidad a los ataques de machine learning adversarial. Esta publicación revisará una clasificación de las diferentes formas en que cripto + IA podrían intersectarse, y las perspectivas y desafíos de cada categoría.

Link al blog post de uETH.

Las cuatro categorías principales

La IA es un concepto muy amplio: puedes pensar en "IA" como el conjunto de algoritmos que creas no especificándolos explícitamente, sino más bien agitando una gran sopa computacional y aplicando algún tipo de presión de optimización que empuja la sopa hacia la producción de algoritmos con las propiedades que deseas. Esta descripción definitivamente no debe tomarse de manera despectiva: ¡incluye el proceso que nos creó a los humanos en primer lugar! Pero esto significa que los algoritmos de IA tienen algunas propiedades comunes: su capacidad para hacer cosas que son extremadamente poderosas, junto con límites en nuestra capacidad de saber o entender qué está sucediendo bajo el capó.

Hay muchas formas de categorizar la IA; para los propósitos de esta publicación, que habla sobre las interacciones entre la IA y las cadenas de bloques (que han sido descritas como una plataforma para crear "juegos"), la categorizaré de la siguiente manera:

• IA como jugador en un juego [viabilidad más alta]: IA participando en mecanismos donde la fuente última de los incentivos proviene de un protocolo con entradas humanas.

• IA como una interfaz para el juego [alto potencial, pero con riesgos]: IA ayudando a los usuarios a entender el mundo cripto que los rodea, y asegurando que su comportamiento (es decir, mensajes firmados y transacciones) coincida con sus intenciones y no sean engañados o estafados.

• IA como las reglas del juego [proceder con mucho cuidado]: cadenas de bloques, DAOs y mecanismos similares pidiendo ayuda directamente a las IA. Piensa, por ejemplo, en "jueces IA".

• IA como el objetivo del juego [más a largo plazo pero intrigante]: diseñar cadenas de bloques, DAOs y mecanismos similares con el objetivo de construir y mantener una IA que podría utilizarse para otros propósitos, utilizando los bits cripto ya sea para incentivar mejor el entrenamiento o para prevenir que la IA filtre datos privados o sea mal utilizada.

Ahora vamos a analizarlas una a una.

IA como jugador en un juego

Esta es, de hecho, una categoría que ha existido durante casi una década, al menos desde que los intercambios descentralizados en cadena (DEXes) comenzaron a usarse significativamente. Cada vez que hay un intercambio, existe la oportunidad de ganar dinero a través del arbitraje, y los bots pueden realizar arbitraje mucho mejor que los humanos. Este caso de uso ha existido durante mucho tiempo, incluso con IA mucho más simples de lo que tenemos hoy, pero en última instancia, es una intersección muy real entre IA y cripto. Más recientemente, hemos visto que los bots de arbitraje MEV a menudo se explotan entre sí. Cada vez que tienes una aplicación blockchain que involucra subastas o comercio, vas a tener bots de arbitraje.

Pero los bots de arbitraje de IA son solo el primer ejemplo de una categoría mucho más grande, que espero pronto comience a incluir muchas otras aplicaciones. Conoce a AIOmen, una demostración de un mercado de predicción donde las IA son jugadoras:

Los mercados de predicción han sido el santo grial de la tecnología epistémica durante mucho tiempo; ya en el 2014 yo estaba emocionado por usar los mercados de predicción como una entrada para la gobernanza ("futarquía"), y jugué con ellos extensamente en las últimas elecciones, así como más recientemente. Pero hasta ahora, los mercados de predicción no han despegado demasiado en la práctica, y hay una serie de razones comúnmente dadas por qué: los participantes más grandes son a menudo irracionales, las personas con el conocimiento adecuado no están dispuestas a tomarse el tiempo y apostar a menos que esté involucrado mucho dinero, los mercados a menudo son escasos, etc.

Una respuesta a esto es señalar las mejoras continuas en la experiencia de usuario en Polymarket u otros nuevos mercados de predicción, y esperar que tengan éxito donde las iteraciones anteriores han fallado. Después de todo, dice la historia, la gente está dispuesta a apostar decenas de miles de millones en deportes, ¿por qué no iban a invertir suficiente dinero apostando en las elecciones de EE. UU. o LK99 para que comience a tener sentido que los jugadores serios empiecen a participar? Pero este argumento debe enfrentarse con el hecho de que, bueno, las iteraciones anteriores no han logrado alcanzar este nivel de escala (al menos en comparación con los sueños de sus proponentes), y por lo tanto parece que necesitas algo nuevo para hacer que los mercados de predicción tengan éxito. Y así, una respuesta diferente es señalar una característica específica de los ecosistemas de mercados de predicción que podemos esperar ver en los años 2020 que no vimos en los años 2010: la posibilidad de participación ubicua por parte de las IA.

Las IA están dispuestas a trabajar por menos de $1 la hora, y tienen el conocimiento de una enciclopedia; y si eso no es suficiente, incluso pueden integrarse con capacidad de búsqueda en tiempo real en la web. Si creas un mercado y ofreces un subsidio de liquidez de $50, a los humanos no les importará lo suficiente para hacer una oferta, pero miles de IA se abalanzarán fácilmente sobre la pregunta y harán la mejor suposición que puedan. El incentivo para hacer un buen trabajo en una pregunta puede ser pequeño, pero el incentivo para crear una IA que haga buenas predicciones en general puede estar en los millones. Ten en cuenta que potencialmente, ni siquiera necesitas a los humanos para adjudicar la mayoría de las preguntas: puedes usar un sistema de disputa de múltiples rondas similar a Augur o Kleros, donde las IA también participarían en las rondas anteriores. Los humanos solo necesitarían responder en esos pocos casos donde se han llevado a cabo una serie de escalaciones y se han comprometido grandes cantidades de dinero por ambas partes.

Este es un primitivo poderoso, porque una vez que un "mercado de predicción" puede funcionar en una escala tan microscópica, puedes reutilizar el primitivo de "mercado de predicción" para muchas otras clases de preguntas:

• ¿Es esta publicación de redes sociales aceptable según [términos de uso]?

• ¿Qué sucederá con el precio de la acción X (por ejemplo, ver Numerai)?

• ¿Es esta cuenta que me está enviando mensajes actualmente realmente Elon Musk?

• ¿Es aceptable esta entrega de trabajo en un mercado de tareas en línea?

• ¿Es la dapp en https://examplefinance.network una estafa?

• ¿Es 0x1b54....98c3 realmente la dirección del token ERC20 "Casinu Inu"?

Es posible que notes que muchas de estas ideas van en la dirección de lo que llamé "info defense o defensa de la información" en mis escritos sobre "d/acc". Definido de manera amplia, la pregunta es: ¿cómo ayudamos a los usuarios a distinguir entre información verdadera y falsa y detectar estafas, sin empoderar a una autoridad centralizada para decidir lo correcto e incorrecto que podría entonces abusar de esa posición? A nivel micro, la respuesta puede ser "IA". Pero a nivel macro, la pregunta es: ¿quién construye la IA? La IA es un reflejo del proceso que la creó, y por lo tanto no puede evitar tener sesgos. Por lo tanto, existe la necesidad de un juego de nivel superior que adjudique qué tan bien están funcionando las diferentes IA, donde las IA pueden participar como jugadores en el juego.

Este uso de la IA, donde las IA participan en un mecanismo en el que son finalmente recompensadas o penalizadas (probabilísticamente) por un mecanismo en cadena que recopila entradas de humanos (llámalo RLHF basado en mercado descentralizado?), es algo que creo que realmente vale la pena investigar. Ahora es el momento adecuado para explorar más casos de uso como este, porque la escalabilidad de blockchain finalmente está teniendo éxito, haciendo que "micro-" cualquier cosa finalmente sea viable en cadena cuando a menudo no lo era antes.

Una categoría relacionada de aplicaciones va en la dirección de agentes altamente autónomos que utilizan blockchains para cooperar mejor, ya sea a través de pagos o mediante el uso de contratos inteligentes para hacer compromisos creíbles.

IA como una interfaz para el juego

Una idea que mencioné en mis escritos es la oportunidad de mercado para escribir software orientado al usuario que proteja los intereses de los usuarios interpretando e identificando peligros en el mundo en línea que el usuario está navegando. Un ejemplo ya existente de esto es la función de detección de estafas de Metamask:

Otro ejemplo es la función de simulación de la cartera Rabby, que muestra al usuario las consecuencias esperadas de la transacción que están a punto de firmar.

“HarryPotterObamaSonic10Inu”

Edición 2024.02.02: una versión anterior de este post refería a este token como una estafa que intentaba suplantar a bitcoin. No es así; es un memecoin. Disculpas por la confusión.

Potencialmente, este tipo de herramientas podría potenciarse enormemente con la IA. La IA podría ofrecer una explicación mucho más rica y amigable para el usuario sobre el tipo de dapp en la que está participando, las consecuencias de operaciones más complicadas que está firmando, si un token particular es genuino o no (por ejemplo, BITCOIN no es solo una cadena de caracteres, normalmente es el nombre de una criptomoneda importante, que no es un token ERC20 y cuyo precio es mucho mayor que $0.045, y un LLM moderno sabría eso), y así sucesivamente. Hay proyectos que están comenzando a explorar completamente esta dirección (por ejemplo, la cartera LangChain, que utiliza la IA como interfaz principal). En mi opinión, las interfaces puramente basadas en IA probablemente son demasiado riesgosas en este momento, ya que aumentan el riesgo de otros tipos de errores, pero la IA complementando una interfaz más convencional se está volviendo muy viable.

Existe un riesgo particular que vale la pena mencionar. Profundizaré más en esto en la sección "IA como reglas del juego" más abajo, pero el problema general es el aprendizaje automático adversarial: si un usuario tiene acceso a un asistente de IA dentro de una billetera de código abierto, los malos también tendrán acceso a ese asistente de IA, y por lo tanto tendrán una oportunidad ilimitada para optimizar sus estafas para que no activen las defensas de esa billetera. Todas las IA modernas tienen errores en algún lugar, y no es demasiado difícil para un proceso de entrenamiento, incluso uno con acceso limitado al modelo, encontrarlos.

Aquí es donde "las IA participando en micro-mercados en cadena" funciona mejor: cada IA individual es vulnerable a los mismos riesgos, pero estás creando intencionalmente un ecosistema abierto de docenas de personas que constantemente iteran y mejoran estas IA de manera continua. Además, cada IA individual es cerrada: la seguridad del sistema proviene de la apertura de las reglas del juego, no del funcionamiento interno de cada jugador.

Resumen: La IA puede ayudar a los usuarios a entender lo que está sucediendo en un lenguaje claro, puede funcionar como un tutor en tiempo real, puede proteger a los usuarios de cometer errores, pero hay que tener cuidado al intentar usarla directamente contra desinformadores maliciosos y estafadores.

Sistemas como Ethereum (y Bitcoin, y NXT, y Bitshares, etc.) son una clase fundamentalmente nueva de organismos criptoeconómicos: entidades descentralizadas y sin jurisdicción que existen enteramente en el ciberespacio, mantenidas por una combinación de criptografía, economía y consenso social. Son algo parecido a BitTorrent, pero también son distintos de BitTorrent, ya que BitTorrent no tiene concepto de estado, una distinción que resulta ser crucialmente importante. A veces se describen como corporaciones autónomas descentralizadas, pero tampoco son exactamente corporaciones: no puedes hacer un hard fork de Microsoft. Son algo parecidos a proyectos de software de código abierto, pero tampoco son exactamente eso: puedes bifurcar una blockchain, pero no tan fácilmente como puedes bifurcar OpenOffice.

Estas redes criptoeconómicas vienen en muchas variedades — PoW (Proof of Work o Prueba de Trabajo) basado en ASIC, PoW basado en GPU, PoS (Proof of Stake o Prueba de Participación) de ingenuo, PoS delegado, y, esperemos que pronto, PoS de Casper — y cada una de estas modalidades viene inevitablemente con su propia filosofía subyacente. Un ejemplo bien conocido es la visión maximalista de la prueba de trabajo, donde "la" cadena de bloques correcta, en singular, se define como la cadena para la cual los mineros han quemado la mayor cantidad de capital económico para crear. Originalmente una simple regla de elección de bifurcación en el protocolo, este mecanismo en muchos casos ha sido elevado a un tenet sagrado — vean esta discusión en Twitter entre Chris DeRose y yo mismo como ejemplo de alguien tratando seriamente de defender la idea en su forma pura, incluso frente a bifurcaciones duras del protocolo que cambian el algoritmo de hash. La prueba de participación delegada de Bitshares presenta otra filosofía coherente, donde todo fluye nuevamente de un único tenet, pero que puede describirse aún más simplemente: los accionistas votan.

Cada una de estas filosofías; el consenso de Nakamoto, el consenso social, el consenso de votación de accionistas, conduce a su propio conjunto de conclusiones y lleva a un sistema de valores que tiene bastante sentido cuando se ve en sus propios términos, aunque ciertamente pueden ser criticados cuando se comparan entre sí. El consenso de Casper también tiene una base filosófica, aunque hasta ahora no ha sido articulada de manera tan sucinta.

Yo mismo, Vlad, Dominic, Jae y otros todos tenemos nuestras propias opiniones sobre por qué existen los protocolos de prueba de participación y cómo diseñarlos, pero aquí pretendo explicar de dónde vengo personalmente.

Procederé a enumerar observaciones y luego conclusiones directamente.

• La criptografía es verdaderamente especial en el siglo XXI porque es uno de los pocos campos donde el conflicto adversarial sigue favoreciendo ampliamente al defensor. Los castillos son mucho más fáciles de destruir que de construir, las islas son defendibles pero aún pueden ser atacadas, pero las claves ECC de una persona promedio son lo suficientemente seguras como para resistir incluso a actores estatales. La filosofía cypherpunk se basa fundamentalmente en aprovechar esta preciosa asimetría para crear un mundo que preserve mejor la autonomía del individuo, y la criptoeconomía es en cierta medida una extensión de eso, excepto que esta vez protege la seguridad y la vitalidad de sistemas complejos de coordinación y colaboración, en lugar de simplemente la integridad y confidencialidad de mensajes privados. Los sistemas que se consideran herederos ideológicos del espíritu cyberpunk deberían mantener esta propiedad básica, y ser mucho más costosos de destruir o perturbar de lo que son de usar y mantener.

• El "espíritu cyberpunk" no es solo idealismo; hacer sistemas que sean más fáciles de defender que de atacar es también simplemente una ingeniería sólida.

• En escalas de tiempo medias a largas, los humanos son bastante buenos llegando a un consenso. Incluso si un adversario tuviera acceso a poder de hash ilimitado y lanzara un ataque del 51% en cualquier blockchain principal que revirtiera incluso el último mes de historia, convencer a la comunidad de que esta cadena es legítima es mucho más difícil que simplemente superar el poder de hash de la cadena principal. Necesitarían subvertir exploradores de bloques, cada miembro de confianza en la comunidad, el New York Times, archive.org y muchas otras fuentes en internet; en resumen, convencer al mundo de que la nueva cadena de ataque es la que vino primero en el siglo XXI, denso en tecnología de la información, es casi tan difícil como convencer al mundo de que los alunizajes de EE.UU. nunca ocurrieron. Estas consideraciones sociales son las que finalmente protegen cualquier blockchain a largo plazo, independientemente de si la comunidad de la blockchain lo admite o no (cabe destacar que Bitcoin Core sí admite esta primacía de la capa social).

• Sin embargo, una blockchain protegida solo por consenso social sería demasiado ineficiente y lenta, y demasiado fácil para que los desacuerdos continúen sin fin (aunque a pesar de todas las dificultades, esto ya ha ocurrido); por lo tanto, el consenso económico desempeña un papel extremadamente importante en la protección de las propiedades de vitalidad y seguridad a corto plazo.

• Debido a que la seguridad de la prueba de trabajo solo puede provenir de las recompensas por bloque (en términos de Dominic Williams, carece de dos de las tres E) y los incentivos para los mineros solo pueden venir del riesgo de que pierdan sus futuras recompensas por bloque, la prueba de trabajo necesariamente opera bajo una lógica de poder masivo incentivado por recompensas masivas. La recuperación de ataques en PoW es muy difícil: la primera vez que ocurre, puedes hacer un hard fork para cambiar la PoW y así volver inútiles los ASICs del atacante, pero la segunda vez ya no tienes esa opción, y por lo tanto el atacante puede atacar una y otra vez. Por lo tanto, el tamaño de la red de minería tiene que ser tan grande que los ataques sean inconcebibles. Los atacantes de tamaño menor a X son desalentados de aparecer al hacer que la red gaste constantemente X todos los días. Rechazo esta lógica porque (i) mata árboles, y (ii) no logra realizar el espíritu cyberpunk — el costo de ataque y el costo de defensa están en una relación de 1:1, por lo que no hay ventaja para el defensor.

• La prueba de participación rompe esta simetría al depender no de recompensas para la seguridad, sino de penalizaciones. Los validadores ponen dinero ("depósitos") en juego, son recompensados ligeramente para compensarlos por inmovilizar su capital y mantener nodos y tomar precauciones adicionales para asegurar la seguridad de su clave privada, pero la mayor parte del costo de revertir transacciones proviene de penalizaciones que son cientos o miles de veces mayores que las recompensas que recibieron en ese tiempo. La "filosofía en una frase" de la prueba de participación no es, por lo tanto, "la seguridad proviene de quemar energía", sino "la seguridad proviene de poner en riesgo valor económico". Un bloque o estado dado tiene seguridad de $X si se puede demostrar que alcanzar un nivel igual de finalización para cualquier bloque o estado en conflicto no se puede lograr a menos que los nodos maliciosos cómplices en un intento de hacer el cambio paguen $X en penalizaciones dentro del protocolo.

• Teóricamente, una colusión mayoritaria de validadores podría tomar el control de una cadena de prueba de participación y comenzar a actuar de manera maliciosa. Sin embargo, (i) mediante un diseño de protocolo inteligente, su capacidad de obtener ganancias adicionales mediante tal manipulación puede limitarse tanto como sea posible, y más importante aún (ii) si intentan impedir la entrada de nuevos validadores o ejecutar ataques del 51%, entonces la comunidad puede simplemente coordinar un hard fork y eliminar los depósitos de los validadores ofensivos. Un ataque exitoso puede costar 50 millones de dólares, pero el proceso de limpieza de las consecuencias no será mucho más oneroso que el fallo de consenso de geth/parity del 2016.11.25. Dos días después, la blockchain y la comunidad están de vuelta en el camino, los atacantes están 50 millones de dólares más pobres, y el resto de la comunidad probablemente sea más rico, ya que el ataque habrá causado que el valor del token suba debido a la consiguiente escasez de oferta. Esa es una asimetría de ataque/defensa para ti.

• Lo anterior no debe interpretarse como que los forks o bifurcaciones duras no programadas se convertirán en un evento regular; si se desea, el costo de un único ataque del 51% en prueba de participación ciertamente puede establecerse tan alto como el costo de un ataque permanente del 51% en prueba de trabajo, y el mero costo e ineficacia de un ataque deberían asegurar que prácticamente nunca se intente en la práctica.

• La economía no lo es todo. Los actores individuales pueden estar motivados por motivos extra protocolarios, pueden ser hackeados, pueden ser secuestrados, o simplemente pueden emborracharse y decidir arruinar la blockchain un día y al diablo con el costo. Además, en el lado positivo, las restricciones morales de los individuos y las ineficiencias en la comunicación a menudo elevarán el costo de un ataque a niveles mucho más altos que el valor de pérdida definido nominalmente por el protocolo. Esta es una ventaja en la que no podemos confiar ciegamente, pero al mismo tiempo es una ventaja que no deberíamos desechar innecesariamente.

• Por lo tanto, los mejores protocolos son aquellos que funcionan bien bajo una variedad de modelos y suposiciones — racionalidad económica con elección coordinada, racionalidad económica con elección individual, tolerancia a fallos simples, tolerancia a fallos bizantinos (idealmente tanto las variantes de adversario adaptativo como no adaptativo), modelos económicos conductuales inspirados en Ariely/Kahneman (“todos engañamos un poco”) y, idealmente, cualquier otro modelo que sea realista y práctico para razonar. Es importante tener ambas capas de defensa: incentivos económicos para desalentar a los cárteles centralizados de actuar de manera antisocial, e incentivos anti-centralización para desalentar la formación de cárteles en primer lugar.

• Los protocolos de consenso que funcionan lo más rápido posible tienen riesgos y deben abordarse con mucho cuidado, si es que se abordan, porque si la posibilidad de ser muy rápido está ligada a incentivos para hacerlo, la combinación recompensará niveles de centralización a nivel de red muy altos e inducidos por riesgos sistémicos (por ejemplo, todos los validadores operando desde el mismo proveedor de hosting). Los protocolos de consenso que no se preocupan demasiado por la rapidez con la que un validador envía un mensaje, siempre que lo hagan dentro de un intervalo de tiempo aceptablemente largo (por ejemplo, 4-8 segundos, como sabemos empíricamente que la latencia en Ethereum es generalmente de ~500ms-1s), no tienen estas preocupaciones. Un posible término medio es crear protocolos que puedan funcionar muy rápidamente, pero donde mecanismos similares al mecanismo de uncle de Ethereum aseguren que la recompensa marginal para un nodo al aumentar su grado de conectividad de red más allá de un punto fácilmente alcanzable sea bastante baja.

Desde aquí, por supuesto, hay muchos detalles y muchas formas de divergir en los detalles, pero los anteriores son los principios básicos en los que se basa al menos mi versión de Casper. A partir de aquí, ciertamente podemos debatir los compromisos entre valores en competencia. ¿Damos a ETH una tasa de emisión anual del 1% y obtenemos un costo de 50 millones de dólares por forzar una bifurcación dura remedial, o una tasa de emisión anual del 0% y obtenemos un costo de 5 millones de dólares por forzar una bifurcación dura remedial? ¿Cuándo aumentamos la seguridad de un protocolo bajo el modelo económico a cambio de disminuir su seguridad bajo un modelo de tolerancia a fallos? ¿Nos importa más tener un nivel predecible de seguridad o un nivel predecible de emisión? Todas estas son preguntas para otra publicación, y las diversas formas de implementar los diferentes compromisos entre estos valores son preguntas para aún más publicaciones. Pero llegaremos a ello :)

Agradecimientos especiales 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 un conjunto de tecnologías maduras capaz de ofrecer una experiencia abierta, global y sin permisos a los usuarios promedio, hay tres transiciones técnicas principales que el conjunto necesita experimentar, aproximadamente al mismo tiempo:

• La transición de escalabilidad en L2 - todos migrando a rollups

• La transición de seguridad en las carteras - todos migrando a carteras de contrato inteligente

• La transición de la privacidad - asegurando que las transferencias de fondos preserven la privacidad, y asegurando que todos los demás gadgets que se están desarrollando (recuperación social, identidad, reputación) también sean preservadores de la privacidad.

Sin la primera, Ethereum fracasa porque cada transacción cuesta $3.75 ($82.48 si tenemos otro bull market), y cada producto que apunta al mercado masivo inevitablemente se olvida la cadena y adopta soluciones centralizadas para todo.

Sin la segunda, Ethereum fracasa porque a los usuarios les incomoda almacenar sus fondos (y activos no financieros), y todos se pasan a los intercambios centralizados.

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

Estas tres transiciones son cruciales por las razones mencionadas anteriormente. Pero también son un desafío debido a la intensa coordinación necesaria para resolverlas adecuadamente. No solo son características del protocolo las que necesitan mejorar; en algunos casos, la forma en que interactuamos con Ethereum necesita cambiar de manera bastante fundamental, requiriendo cambios profundos por parte de aplicaciones y carteras.

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

En un mundo de escalabilidad L2, los usuarios existirán en varias L2. ¿Eres miembro de ExampleDAO, que reside en 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 probaste una aplicación que residía en Kakarot? ¡Entonces tienes una cuenta en Kakarot! Los días en que un usuario tenía solo una dirección habrán terminado.

Las carteras de contrato inteligente añaden más complejidad al hacer que sea mucho más difícil mantener la misma dirección entre L1 y las diversas L2s. 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 carteras de contrato inteligente, mantener una sola dirección se vuelve más difícil. Aunque se ha trabajado mucho para intentar que las direcciones sean hashes de código que puedan ser equivalentes en las redes, notablemente con CREATE2 y la fábrica singleton ERC-2470, es difícil que esto funcione perfectamente. Algunas L2s (por ejemplo, "ZK-EVMs tipo 4") no son tan equivalentes a EVM, a menudo utilizando Solidity o un ensamblado intermedio, lo que impide la equivalencia de hashes. Y aun cuando se puede tener equivalencia de hash, la posibilidad de que las carteras cambien de propietario a través de cambios de claves crea otras consecuencias poco intuitivas.

La privacidad requiere que cada usuario tenga aún más direcciones, y puede incluso cambiar el tipo de direcciones con las que estamos tratando. Si las propuestas de direcciones ocultas (stealth addresses) se vuelven ampliamente utilizadas, en lugar de que cada usuario tenga solo unas pocas direcciones, o una dirección por cada 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 los activos se almacenan 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 necesitarán depender del sistema de direccionamiento interno del propio 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 ejecutar las transiciones. Dos puntos particulares de complejidad son:

1. Si quieres pagarle a alguien, ¿cómo obtendrías 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 de clave y recuperación social?

Las tres transiciones y los pagos en cadena (y la identidad)

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

Básicamente hay dos soluciones:

1. Las carteras receptoras (que podrían ser comerciantes, pero también podrían ser simplemente individuos regulares) intentan arduamente soportar cada L2, y tienen alguna funcionalidad automatizada para consolidar fondos de manera asincrónica.

2. El receptor proporciona su L2 junto con su dirección, y la cartera del emisor automáticamente envía fondos al L2 de destino a través de algún sistema de puentes entre L2s.

Por supuesto, estas soluciones pueden combinarse: el receptor proporciona la lista de L2s que está dispuesto a aceptar, y la cartera del emisor resuelve el pago, que podría involucrar un envío directo si tienen suerte, o de lo contrario, un camino de puente entre L2s.

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.

Una transición a carteras de contrato inteligente afortunadamente no es una gran carga para el sistema de direcciones, pero aún hay algunos problemas técnicos en otras partes del conjunto de aplicaciones que necesitan ser resueltos. Las carteras necesitarán actualizarse para asegurarse de que no envíen solo 21000 de gas junto con una transacción, y será aún más importante asegurarse de que el lado receptor del pago en una cartera rastree no solo las transferencias de ETH desde cuentas de propiedad externa (EOAs), sino también ETH enviado por código de contrato inteligente. Las aplicaciones que dependen de la suposición de que la propiedad de una dirección es inmutable (por ejemplo, NFTs que prohíben contratos inteligentes para hacer cumplir regalías) tendrán que encontrar otras formas de alcanzar sus objetivos. Las carteras de contrato inteligente también facilitarán algunas cosas; notablemente, si alguien recibe solo un token ERC20 que no es ETH, podrán usar paymasters de ERC-4337 para pagar el gas con ese token.

Por otro lado, la privacidad una vez más plantea grandes desafíos que aún no hemos abordado realmente. 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 se pueden realizar transferencias internas, los usuarios necesitarán utilizar el esquema de direccionamiento interno del sistema de privacidad. En la práctica, la "información de pago" de un usuario necesitaría contener tanto (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 manera para que el emisor envíe información cifrada que solo el destinatario pueda descifrar, para ayudar al destinatario a descubrir el pago.

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

Una lección clave aquí es que, en un ecosistema amigable con la privacidad, un usuario tendrá tanto claves públicas de gasto como claves públicas de cifrado, y la "información de pago" de un usuario deberá incluir ambas claves. También hay buenas razones, aparte de los pagos, para expandirse en esta dirección. Por ejemplo, si queremos un correo electrónico cifrado basado en Ethereum, los usuarios necesitarán proporcionar públicamente algún tipo de clave de cifrado. En el "mundo EOA", podríamos reutilizar las claves de las cuentas para esto, pero en un mundo seguro de carteras de contrato inteligente, 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 ecosistemas de privacidad descentralizados no basados en Ethereum, notablemente las claves PGP.

Las tres transiciones y la recuperación de claves

La forma predeterminada de implementar cambios de clave y recuperación social en un mundo con múltiples 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 cartera 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 multi-dirección ingenua tiene tres problemas:

1. Costo de gas poco práctico: esto es autoexplicativo.

2. Direcciones contrafactuales: direcciones para las cuales el contrato inteligente aún no ha sido publicado (en la práctica, esto significará una cuenta de la que aún no has enviado fondos). Como usuario, tienes un número potencialmente ilimitado de direcciones contrafactuales: una o más en cada L2, incluidas L2s que aún no existen, y todo un conjunto infinito de otras direcciones contrafactuales que surgen de esquemas de direcciones ocultas.

3. Privacidad: si un usuario intencionalmente tiene muchas direcciones para evitar vincularlas entre sí, ciertamente no querrá vincularlas públicamente recuperándolas todas al mismo tiempo o cerca del mismo tiempo.

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 un lugar específico (podría ser la mainnet o una L2 específica). Los usuarios luego tienen direcciones en diferentes L2s, donde la lógica de verificación de cada una de esas direcciones es un puntero al contrato de almacén de claves. Gastar desde esas direcciones requeriría una prueba que se introduzca en el contrato de almacén de claves mostrando 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 L2: Es posible modificar los L2 para darles una manera de leer directamente el estado de 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 "gratis".

• Ramas de Merkle: Las ramas de Merkle pueden probar el estado de L1 a un L2, o el estado de L2 a un L1, o puedes combinar las dos para probar partes del estado de un L2 a otro L2. La principal debilidad de las pruebas de Merkle es el alto costo 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: Puedes reducir los costos de datos utilizando un ZK-SNARK de una rama de Merkle en lugar de la rama en sí. Es posible construir técnicas de agregación fuera de la cadena (por ejemplo, sobre EIP-4337) para tener un único ZK-SNARK que verifique todas las pruebas de estado entre cadenas en un bloque.

• Compromisos KZG: Los L2, o esquemas construidos sobre ellos, podrían introducir un sistema de direccionamiento secuencial, permitiendo que las pruebas de estado dentro de este sistema sean de solo 48 bytes de longitud. Al igual que con los ZK-SNARKs, un esquema de multiprueba 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 entre L2 para la recuperación. Gastar desde una cuenta dependería de una clave de gasto cuya clave pública correspondiente se almacena dentro de esa cuenta, pero la recuperación requeriría una transacción que copie la clave pública de gasto actual (spending_pubkey)en el almacén de claves. Los fondos en direcciones contrafactuales están seguros incluso si tus claves antiguas no lo están: "activar" una dirección contrafactual para convertirla en un contrato funcional requeriría hacer una prueba entre L2 para copiar la clave pública de gasto actual. Este hilo en los foros de Safe describe cómo podría funcionar una arquitectura similar.

Para añadir privacidad a este esquema, simplemente ciframos el puntero y realizamos todas nuestras pruebas dentro de los ZK-SNARKs:

Con más trabajo (por ejemplo, usando este trabajo como punto de partida), también podríamos eliminar la mayor parte de la complejidad de los ZK-SNARKs y crear un esquema basado en KZG más básico.

Estos esquemas pueden volverse complejos. En el lado positivo, hay muchas sinergias potenciales entre ellos. Por ejemplo, el concepto de "contratos de almacén de claves" (keystore contracts) 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 meta-direcciones 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 la "dirección" de un usuario.

Mucha infraestructura secundaria necesita actualizarse

Usar ENS es costoso. Hoy, en junio de 2023, la situación no es tan grave: la tarifa de transacción es significativa, pero sigue siendo comparable a la tarifa del 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, que el gas vuelva a 200 gwei elevaría la tarifa de transacción de un registro de dominio a $104. Por lo tanto, si queremos que la gente realmente use ENS, especialmente para casos de uso como los medios sociales descentralizados donde los usuarios exigen un registro casi gratuito (y la tarifa del 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 está sucediendo! ERC-3668 (también conocido como "el estándar CCIP"), junto con ENSIP-10, proporcionan una manera de que los subdominios de ENS en cualquiera L2 sean automáticamente verificables. El estándar CCIP requiere configurar un contrato inteligente que describa un método para verificar pruebas de datos en L2, y un dominio (por ejemplo, Optinames usa ecc.eth) puede ser puesto bajo el control de dicho contrato. Una vez que el contrato CCIP controla ecc.eth en L1, acceder a algún subdominio.ecc.eth implicará automáticamente encontrar y verificar una prueba (por ejemplo, rama de Merkle) del estado en L2 que realmente almacena ese subdominio particular.

Obtener realmente las pruebas implica ir a una lista de URLs almacenadas en el contrato, lo que admitidamente parece centralización, aunque yo argumentaría que realmente no lo es: es un modelo de confianza 1-de-N (las pruebas inválidas son detectadas por la lógica de verificación en la función de callback del contrato CCIP, y mientras al menos una de las URLs devuelva una prueba válida, todo está bien). La lista de URLs podría contener docenas de ellas.

El esfuerzo de ENS CCIP es una historia de éxito y debería ser visto como una señal de que las reformas radicales que necesitamos son realmente posibles. Pero hay muchas más reformas en la capa de aplicación que necesitarán ser realizadas. Algunos ejemplos:

• Muchas dapps dependen de que los usuarios proporcionen firmas fuera de la cadena (off-chain). Con cuentas de propiedad externa (EOAs), esto es fácil. ERC-1271 proporciona una forma estandarizada de hacer esto para carteras de contrato inteligente. Sin embargo, muchas dapps aún no soportan ERC-1271; necesitarán hacerlo.

• Las dapps que usan "¿es esto una EOA?" para discriminar entre usuarios y contratos (por ejemplo, para prevenir transferencias o hacer cumplir regalías) fallarán. En general, aconsejo no intentar encontrar una solución puramente técnica aquí; determinar si una transferencia particular de control criptográfico es una transferencia de propiedad beneficiosa es un problema difícil y probablemente no solucionable sin recurrir a algunos mecanismos fuera de la cadena impulsados por la comunidad. Lo más probable es que las aplicaciones tengan que depender menos de prevenir transferencias y más en técnicas como los impuestos de Harberger.

• Cómo interactúan las carteras con las claves de gasto y cifrado tendrá que ser mejorado. Actualmente, las carteras 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 una EOA genera un valor determinista que no puede ser generado sin la clave privada, y por lo tanto es seguro en un sentido puramente técnico. Sin embargo, estas técnicas son "opacas" para la cartera, impidiendo que la cartera implemente controles de seguridad a nivel de interfaz de usuario. En un ecosistema más maduro, la firma, cifrado y funcionalidades relacionadas tendrán que ser manejadas por las carteras de manera más explícita.

• Los clientes ligeros (por ejemplo, Helios) tendrán que verificar L2s y no solo el L1. Hoy en día, los clientes ligeros se centran en verificar la validez de los encabezados de L1 (usando el protocolo de sincronización de clientes ligeros) y verificar las ramas de Merkle del estado de L1 y las transacciones arraigadas en el encabezado de L1. Mañana, también necesitarán verificar una prueba del estado de L2 arraigada en la raíz de estado almacenada en la L1 (una versión más avanzada de esto realmente miraría las pre-confirmaciones de L2).

Las carteras necesitarán asegurar tanto los activos como los datos

Hoy en día, las carteras están en el negocio de asegurar activos. Todo vive en la cadena de bloques, y lo único que la cartera necesita proteger es la clave privada que actualmente guarda esos activos. Si cambias la clave, puedes publicar de manera segura tu clave privada anterior en internet al día siguiente. Sin embargo, en un mundo ZK, esto ya no es cierto: la cartera no solo protege las credenciales de autenticación, sino que también almacena tus datos.

Vimos los primeros indicios de tal mundo 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 podría usarse para hacer pruebas básicas como "probar que soy residente de Zuzalu, sin revelar cuál". Pero el sistema Zupass también comenzó a tener otras aplicaciones construidas encima, más notablemente sellos o “stamps” (la versión de Zupass de los POAPs).

La característica clave que los sellos ofrecen sobre los POAPs es que los sellos son privados: mantienes los datos localmente y solo pruebas en ZK un sello (o algún cálculo sobre los sellos) a alguien si quieres que esa persona tenga esa información sobre ti. Pero esto crea un riesgo adicional: si pierdes esa información, pierdes tus sellos.

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

La solución de facto de Zupass fue alentar a las personas a almacenar su clave en múltiples dispositivos (por ejemplo, laptop y teléfono), ya que la posibilidad de que pierdan acceso a todos los dispositivos al mismo tiempo es mínima. Podríamos ir más allá y usar el reparto 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 carteras, porque significa que no solo los guardianes actuales, sino también los guardianes anteriores podrían coludir para robar tus activos, lo cual es un riesgo inaceptablemente alto. Pero las filtraciones de privacidad generalmente son un riesgo menor que la pérdida total de activos, y alguien con un caso de uso que demande alta privacidad siempre podría aceptar un riesgo mayor de pérdida al no hacer una copia de seguridad de la clave asociada con esas acciones que demandan privacidad.

Para evitar abrumar al usuario con un sistema bizantino de múltiples caminos de recuperación, las carteras que soporten la recuperación social probablemente necesitarán gestionar tanto la recuperación de activos y la recuperación de claves de cifrado.

Regresando a la identidad

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

Una forma de hacer esto es convertir ENS en tu identidad: tu registro ENS podría simplemente contener toda esta información, y si envías a alguien bob.eth (o bob.ecc.eth, o...), podrían consultar y ver todo sobre cómo pagar e interactuar contigo, incluyendo las formas más complicadas y preservadoras de privacidad entre dominios.

Pero este enfoque centrado en ENS tiene dos debilidades:

• Vincula demasiadas cosas a tu nombre. Tu nombre no eres tú, tu nombre es uno de los muchos atributos que te definen. Debería ser posible cambiar tu nombre sin tener que trasladar todo tu perfil de identidad y actualizar un montón de registros en muchas aplicaciones.

• No puedes tener nombres contrafactuales sin confianza. Una característica clave de UX en cualquier blockchain es la capacidad de enviar monedas a personas que aún no han interactuado con la cadena. Sin tal funcionalidad, existe un catch-22 o dilema: interactuar con la cadena requiere pagar tarifas de transacción, lo cual requiere... contar con monedas. Las direcciones ETH, incluidas las direcciones de contratos inteligentes con CREATE2, tienen esta característica. Los nombres ENS no, porque si dos Bobs deciden fuera de la cadena que ambos son bob.ecc.eth, no hay forma de elegir cuál de ellos obtiene el nombre.

Una posible solución es incluir más elementos en el contrato de almacén de claves o contrato keystore mencionado en la arquitectura anteriormente en este post. El contrato de almacén de claves podría contener toda la información variada sobre ti y cómo interactuar contigo (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 estarían almacenados en todo tipo de lugares diferentes. Los contratos de almacén de claves no están vinculados a un nombre y son amigables con los contrafactuales: puedes generar una dirección que solo puede ser inicializada de manera comprobable por un contrato de almacén de claves que tenga ciertos parámetros iniciales fijos.

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

Independientemente de si actúa primero el emisor o el receptor, una mayor dependencia de las carteras generando 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 comunicación directa entre el emisor y el receptor es realmente complicada en la práctica, por lo que podríamos terminar viendo una combinación de diferentes técnicas.

En todos estos diseños, mantener las cosas tanto descentralizadas como comprensibles para los usuarios es primordial. Necesitamos asegurarnos de que los usuarios tengan fácil acceso a una visión actualizada de cuáles son sus activos actuales y qué mensajes se han publicado que están destinados para ellos. Estas vistas deberían depender de herramientas abiertas, no de soluciones propietarias. Requerirá un trabajo arduo evitar que la mayor complejidad de la infraestructura de pagos se convierta en una "torre de abstracción" opaca donde los desarrolladores tengan dificultades para entender qué está sucediendo y adaptarlo a nuevos contextos. A pesar de los desafíos, lograr escalabilidad, seguridad en las carteras y privacidad para los usuarios regulares es crucial para el futuro de Ethereum. No se trata solo de la viabilidad técnica, sino de la accesibilidad real para los usuarios comunes. Necesitamos elevarnos para enfrentar este desafío.

En el último año, ha habido una cantidad cada vez mayor de discusiones sobre los llamados protocolos “Bitcoin 2.0” - redes criptográficas alternativas inspiradas en Bitcoin pero que pretenden hacer la tecnología subyacente utilizable para mucho más que solo moneda. La implementación más temprana de esta idea fue Namecoin, una moneda similar a Bitcoin creada en 2010 que se usaría para la registro de nombres de dominio descentralizado. Más recientemente, hemos visto la emergencia de monedas coloreadas, permitiendo a los usuarios crear sus propias monedas en la red Bitcoin y protocolos más avanzados como Mastercoin, Bitshares y Counterparty, que pretenden proporcionar características como derivados financieros, carteras de ahorro e intercambio descentralizado. Sin embargo, hasta este momento, todos los protocolos que se han inventado han sido especializados, intentando ofrecer conjuntos de características detalladas dirigidas a industrias o aplicaciones específicas, generalmente de naturaleza financiera. Ahora, un grupo de desarrolladores, incluido yo, ha ideado un proyecto que toma la ruta opuesta: una red de criptomonedas que pretende ser lo más generalizada posible, permitiendo a cualquier persona crear aplicaciones especializadas en ella para casi cualquier propósito imaginable. El proyecto: Ethereum.

LOS PROTOCOLOS DE CRIPTOMONEDAS SON COMO LAS CEBOLLAS…

Una filosofía de diseño común entre muchos protocolos de criptomonedas 2.0 es la idea de que, al igual que internet, el diseño de criptomonedas funcionaría mejor si los protocolos se dividieran en diferentes capas. Bajo esta corriente de pensamiento, Bitcoin se debe considerar como una especie de TCP/IP del ecosistema de criptomonedas, y otros protocolos de próxima generación pueden construirse encima de Bitcoin, mucho como tenemos SMTP para el correo electrónico, HTTP para páginas web y XMPP para chat, todo encima de TCP como una capa de datos común subyacente.

Hasta ahora, los tres protocolos principales que han seguido este modelo son las monedas coloreadas, Mastercoin y Counterparty. La forma en que funciona el protocolo de monedas coloreadas es simple. Primero, para crear monedas coloreadas, un usuario etiqueta bitcoins específicos como teniendo un significado especial; por ejemplo, si Bob es un emisor de oro, puede desear etiquetar un conjunto de bitcoins y decir que cada satoshi representa 0.1 gramos de oro canjeable por él. El protocolo luego rastrea esos bitcoins a través de la cadena de bloques y, de esa manera, es posible calcular quién los posee en cualquier momento.

Mastercoin y Counterparty son algo más abstractos; utilizan la cadena de bloques de Bitcoin para almacenar datos, por lo que una transacción de Mastercoin o Counterparty es una transacción de Bitcoin, pero los protocolos interpretan las transacciones de una manera completamente diferente. Se pueden tener dos transacciones de Mastercoin, una enviando 1 MSC y la otra 100000 MSC, pero desde el punto de vista de un usuario de Bitcoin que no sabe cómo funciona el protocolo de Mastercoin, ambas parecen transacciones pequeñas enviando 0.0006 BTC cada una; los metadatos específicos de Mastercoin están codificados en las salidas de la transacción. Un cliente de Mastercoin entonces necesita buscar en la cadena de bloques de Bitcoin transacciones de Mastercoin para determinar el balance actual de Mastercoin.

Personalmente, he tenido el privilegio de hablar directamente con muchos de los creadores de los protocolos de monedas coloreadas y Mastercoin, y he participado considerablemente en el desarrollo de ambos proyectos. Sin embargo, tras aproximadamente dos meses de investigación y participación, lo que finalmente me di cuenta es que, aunque la idea subyacente de tener protocolos de alto nivel sobre protocolos de bajo nivel es loable, existen defectos fundamentales en las implementaciones, tal como están hoy, que bien podrían impedir que los proyectos ganen algo más que una pequeña cantidad de tracción.

La razón no es que las ideas detrás de los propios protocolos sean malas; las ideas son excelentes, y la respuesta de la comunidad por sí sola es prueba de que están intentando hacer algo que es muy necesario. Más bien, la razón es que el protocolo de bajo nivel sobre el cual intentan construir sus protocolos de alto nivel, Bitcoin, simplemente no está a la altura de la tarea. Esto no quiere decir que Bitcoin sea malo, o que no sea un invento revolucionario; como protocolo para almacenar y transferir valor, Bitcoin es excelente. Sin embargo, en cuanto a ser un protocolo de bajo nivel efectivo, Bitcoin es menos eficaz; en lugar de ser como un TCP sobre el cual uno puede construir HTTP, Bitcoin es como SMTP: un protocolo que es bueno en su tarea prevista (en el caso de SMTP, el correo electrónico, en el caso de Bitcoin, el dinero), pero no particularmente bueno como fundamento para cualquier otra cosa.

El fracaso específico de Bitcoin está particularmente concentrado en un lugar: la escalabilidad. Bitcoin en sí es tan escalable como puede ser una criptomoneda; incluso si la cadena de bloques se infla a más de un terabyte, hay un protocolo llamado "verificación de pago simplificada", descrito en el white paper de Bitcoin, que permite a los "clientes ligeros" con solo unos pocos megabytes de ancho de banda y almacenamiento determinar de manera segura si han recibido transacciones o no. Sin embargo, con las monedas coloreadas y Mastercoin, esta posibilidad desaparece. La razón es la siguiente. Para determinar qué color tiene una moneda coloreada, necesitas no solo usar la verificación de pago simplificada de Bitcoin para probar que existe; también necesitas rastrearla hasta su génesis y hacer una verificación SPV en cada paso del camino. A veces, el escaneo hacia atrás es exponencial; y con los protocolos de metacoin no hay forma de saber nada en absoluto sin verificar cada transacción.

Y esto es lo que Ethereum intenta solucionar. Ethereum no pretende ser un protocolo navaja suiza con cientos de características para satisfacer todas las necesidades; en cambio, Ethereum aspira a ser un protocolo fundamental superior y permitir que otras aplicaciones descentralizadas se construyan sobre él en lugar de Bitcoin, dándoles más herramientas con las que trabajar y permitiéndoles obtener todos los beneficios de la escalabilidad y eficiencia de Ethereum.

CONTRATOS, NO SOLO PARA DIFERENCIAS

En el momento en que se estaba desarrollando Ethereum, había un gran interés en permitir contratos financieros sobre las criptomonedas; el tipo básico de contrato era un "contrato por diferencia". En un contrato por diferencia, dos partes acuerdan poner cierta cantidad de dinero, y luego sacar dinero en una proporción que depende del valor de algún activo subyacente. Por ejemplo, un CFD podría tener a Alice poniendo $1000, Bob poniendo $1000 y luego después de 30 días la cadena de bloques devolvería automáticamente a Alice $1000 más $100 por cada dólar que el precio LTC/USD subiera durante ese período de tiempo y enviaría a Bob el resto. Estos contratos permiten a las personas especular sobre activos con un alto apalancamiento o, alternativamente, protegerse de la volatilidad de las criptomonedas cancelando su exposición, sin ningún intercambio centralizado.

En este punto, sin embargo, está claro que los contratos por diferencia son realmente solo un caso especial de un concepto mucho más general: contratos por fórmula. En lugar de tener el contrato tomando $x de Alice, $y de Bob, y devolviendo a Alice $x más un $z adicional por cada dólar que suba algún ticker dado, un contrato debería poder devolver a A una cantidad de fondos basada en cualquier fórmula matemática, permitiendo contratos de complejidad arbitraria. Si la fórmula permite datos aleatorios como entradas, estos CFD generalizados incluso podrían usarse para implementar una especie de apuestas entre pares.

Ethereum lleva esta idea un paso más allá. En lugar de que los contratos sean acuerdos entre dos partes que comienzan y terminan, los contratos en Ethereum son como una especie de agente autónomo simulado por la cadena de bloques. Cada contrato de Ethereum tiene su propio código de scripting interno, y el código de scripting se activa cada vez que se envía una transacción a él. El lenguaje de scripting tiene acceso al valor de la transacción, al remitente y a los campos de datos opcionales, así como a algunos datos de bloque y su propia memoria interna, como entradas, y puede enviar transacciones. Para hacer un CFD, Alice crearía un contrato y lo “seed” o siembra con $1000 en criptomoneda, y luego esperaría a que Bob aceptara el contrato enviando una transacción que contenga $1000 también. El contrato estaría entonces programado para iniciar un temporizador, y después de 30 días Alice o Bob podrían enviar una pequeña transacción al contrato para activarlo nuevamente y liberar los fondos.

Aparte de este estrecho modelo de contrato por diferencia, sin embargo, el white paper describe muchos otros tipos de transacciones que serán posibles con el scripting de Ethereum, de los cuales se incluyen algunos ejemplos:

Ejemplo de código de un contrato de moneda Ethereum, escrito en un lenguaje de alto nivel.

if tx.value < 100 * block.basefee: stopif contract.memory[1000]: from = tx.sender to = tx.data[0] value = tx.data[1] if to <= 1000: stop if contract.memory[from] < value: stop contract.memory[from] = contract.memory[from] - value contract.memory[to] = contract.memory[to] + valueelse: contract.memory[mycreator] = 10000000000000000 contract.memory[1000] = 1

Depósitos de garantía multisignatura, de un espíritu similar al servicio de arbitraje de Bitcoin Bitrated, pero con reglas más complejas que Bitcoin. Por ejemplo, no será necesario que los firmantes pasen transacciones parcialmente firmadas manualmente; las personas pueden autorizar un retiro de forma asincrónica a través de la cadena de bloques una a la vez y luego tener la transacción finalizada automáticamente una vez que suficientes personas hagan sus autorizaciones.

Cuentas de ahorros - una configuración interesante funciona de la siguiente manera. Supongamos que Alice quiere almacenar una gran cantidad de dinero, pero no quiere arriesgarse a perderlo todo si su clave privada se pierde o es robada. Ella hace un contrato con Bob, un banco semi-confiable, con las siguientes reglas: Alice puede retirar hasta 1 por día, Alice con la aprobación de Bob puede retirar cualquier cantidad, y Bob solo puede retirar hasta 0.05 por día. Normalmente, Alice solo necesitará pequeñas cantidades a la vez, y si Alice quiere más, puede probar su identidad a Bob y hacer el retiro. Si la clave privada de Alice es robada, ella puede correr a Bob y mover los fondos a otro contrato antes de que el ladrón se lleve más de 1 de los fondos. Si Alice pierde su clave privada, Bob eventualmente podrá recuperar sus fondos. Y si Bob resulta ser malvado, Alice puede retirar sus propios fondos veinte veces más rápido de lo que él puede. En resumen, toda la seguridad de la banca tradicional, pero con casi nada de la confianza.

Apuestas entre pares - cualquier tipo de protocolo de apuestas entre pares puede implementarse encima de Ethereum. Un protocolo muy básico sería simplemente un contrato por diferencia sobre datos aleatorios, como un hash de bloque.

Crear tu propia moneda - usando la memoria interna de Ethereum, puedes crear una moneda completamente nueva dentro de Ethereum. Estas nuevas monedas pueden ser construidas para interactuar entre sí, tener un intercambio descentralizado, o cualquier otro tipo de características avanzadas.

Esta es la ventaja del código de Ethereum: porque el lenguaje de scripting está diseñado para no tener restricciones excepto por un sistema de tarifas, esencialmente cualquier tipo de reglas pueden ser codificadas dentro de él. Incluso se puede tener una empresa entera que gestione sus ahorros en la cadena de bloques, con un contrato que diga, por ejemplo, que 60 de los accionistas actuales de una compañía son necesarios para acordar mover cualquier fondo (y quizás 30 puedan mover un máximo de 1 por día). Otras estructuras, menos tradicionalmente capitalistas, también son posibles; una idea es para una organización democrática con la única regla de que dos tercios de los miembros existentes de un grupo deben estar de acuerdo para invitar a otro miembro.

MÁS ALLÁ DE LO FINANCIERO

Las aplicaciones financieras, sin embargo, solo rascan la superficie de lo que Ethereum y los protocolos criptográficos sobre Ethereum pueden hacer. Aunque las aplicaciones financieras de Ethereum puedan ser lo que inicialmente emocione a muchas personas en la comunidad de criptomonedas, la promesa a largo plazo radica posiblemente en las formas en que Ethereum puede trabajar junto con otros protocolos de par a par no financieros. Uno de los principales problemas que han enfrentado hasta ahora los protocolos de par a par no financieros es la falta de incentivos; es decir, a diferencia de las plataformas centralizadas con fines de lucro, no hay una razón financiera para participar. En algunos casos, la participación es en cierto sentido su propia recompensa; es por esta razón que la gente continúa escribiendo software de código abierto, contribuyendo a Wikipedia y haciendo comentarios en foros y escribiendo publicaciones en blogs. Sin embargo, en el contexto de los protocolos de par a par, la participación a menudo no es una actividad "divertida" en ningún sentido significativo; más bien, consiste en invertir una gran cantidad de recursos, dejar que un daemon se ejecute en segundo plano acaparando potencialmente la CPU y la energía de la batería, y olvidarse de ello.

Por ejemplo, ya hace mucho tiempo existen protocolos de datos como Freenet que esencialmente proporcionan a todos alojamiento de contenido estático descentralizado e incensurable; sin embargo, en la práctica, Freenet es muy lento y pocas personas contribuyen con recursos. Los protocolos de compartición de archivos sufren todos del mismo problema: aunque el altruismo es suficiente para difundir blockbusters comerciales populares, se vuelve notablemente menos efectivo para aquellos con preferencias menos convencionales. Así, perversamente, la naturaleza de par a par de la compartición de archivos puede estar ayudando a la centralización de la producción de entretenimiento y medios de comunicación, en lugar de impedirla. Sin embargo, todos estos problemas pueden potencialmente resolverse si agregamos incentivos - empoderando a las personas para construir no solo proyectos secundarios sin fines de lucro, sino también negocios y medios de vida, alrededor de la participación en la red.

Almacenamiento de datos incentivado - esencialmente, un Dropbox descentralizado. La idea funciona de la siguiente manera: si un usuario quiere tener un archivo de 1GB respaldado por la red, construiría una estructura de datos conocida como árbol de Merkle con los datos. Luego, pondrían la raíz del árbol, junto con 10 ether, en un contrato y subirían el archivo a otra red especializada que los nodos que desean alquilar su espacio en disco duro escucharían en busca de mensajes. Todos los días, el contrato elegiría automáticamente una rama aleatoria del árbol (por ejemplo, "izquierda -> derecha -> izquierda -> izquierda -> izquierda -> derecha -> izquierda"), terminando en un bloque del archivo, y daría 0.01 ether al primer nodo que proporcione esa rama. Los nodos almacenarían el archivo completo para maximizar su oportunidad de obtener la recompensa.

BitMessage y Tor - Bitmessage es un protocolo de correo electrónico de próxima generación que es completamente descentralizado y cifrado, permitiendo a cualquier persona enviar mensajes de manera segura a cualquier otro usuario de Bitmessage sin depender de terceros excepto de la red. Sin embargo, Bitmessage tiene un gran defecto de usabilidad: en lugar de enviar mensajes a direcciones de correo electrónico amigables para el humano, como "miNombre@email", necesitas enviar a direcciones enrevesadas de 34 caracteres de Bitmessage (por ejemplo, "BM-BcbRqcFFSQUUmXFKsPJgVQPSiFA3Xash"). Los contratos de Ethereum ofrecen una solución: las personas pueden registrar sus nombres en un contrato especial de Ethereum, y los clientes de Bitmessage pueden consultar la cadena de bloques de Ethereum para obtener la dirección de Bitmessage de 34 caracteres asociada con cualquier nombre de manera transparente. La red de anonimización en línea Tor sufre de los mismos problemas, y por lo tanto también puede beneficiarse de esta solución.

Sistemas de Identidad y Reputación - una vez que puedes registrar tu nombre en la cadena de bloques, el siguiente paso lógico es obvio: tener una red de confianza en la cadena de bloques. Las redes de confianza son una parte clave de una infraestructura de comunicación de par a par efectiva: no solo quieres saber que una clave pública dada se refiere a una persona dada; también quieres saber que la persona es confiable en primer lugar. La solución es usar redes sociales: si confías en A, A confía en B y B confía en C, entonces hay una buena posibilidad de que puedas confiar en C, al menos hasta cierto punto. Ethereum puede servir como la capa de datos para un sistema de reputación completamente descentralizado - y potencialmente, en última instancia, un mercado completamente descentralizado.

Muchas de las aplicaciones mencionadas consisten en protocolos y proyectos de par a par reales que ya están bien desarrollados; en esos casos, pretendemos establecer asociaciones con tantos de estos proyectos como podamos, y ayudar a financiarlos a cambio de traer su valor al ecosistema de Ethereum. Queremos ayudar no solo a la comunidad de criptomonedas, sino también a la comunidad de par a par en su conjunto, incluyendo el intercambio de archivos, torrents, almacenamiento de datos y redes de mesh o malla. Creemos que hay muchos proyectos, especialmente en el área no financiera, que pueden potencialmente aportar un gran valor a la comunidad, pero cuyo desarrollo está subfinanciado precisamente porque carecen de una oportunidad para introducir efectivamente un componente financiero; quizás Ethereum sea lo que finalmente impulse a docenas de estos proyectos a la siguiente etapa.

¿Por qué todas estas aplicaciones son posibles sobre Ethereum? La respuesta yace en el lenguaje de programación interno de la criptomoneda. Aquí se puede hacer una analogía con internet. En 1996, la web no era más que HTML, y todo lo que la gente podía hacer con ella era servir páginas web estáticas en sitios como Geocities. Luego, la gente decidió que había una gran necesidad de que las personas enviaran formularios en HTML, así que HTML agregó una característica de formularios. Esto era como un "colored coins" de los protocolos web: intentar resolver un problema específico, pero hacerlo sobre un protocolo débil sin mirar el panorama más amplio. Sin embargo, pronto, se nos ocurrió Javascript, un lenguaje de programación dentro del navegador web. Y fue Javascript el que resolvió el problema: porque Javascript es un lenguaje de programación universal y Turing-completo, puede ser utilizado para construir aplicaciones de complejidad arbitraria; Gmail, Facebook e incluso carteras de Bitcoin han sido creadas con el lenguaje. Y esto no fue porque los desarrolladores de Javascript decidieran que querían que la gente construyera Gmail, Facebook y carteras de Bitcoin; solo querían un lenguaje de programación. Lo que podemos hacer con el lenguaje depende de nuestra propia imaginación. Y ese es el espíritu que queremos llevar a Ethereum. Ethereum no pretende ser el fin de toda la innovación en criptomonedas; pretende ser el comienzo.

INNOVACIONES ADICIONALES

Junto con su característica principal de un lenguaje de scripting universal y completo según Turing, Ethereum también tendrá una serie de otras mejoras sobre las criptomonedas existentes:

1. Tasas de Transacción: Los contratos de Ethereum regularán su funcionalidad completa según Turing y prevendrán transacciones abusivas, como aquellas que consumen demasiada memoria o bucles infinitos, mediante la institución de una tarifa de transacción por cada paso computacional de la ejecución del script. Las operaciones más costosas, como los accesos a almacenamiento y las operaciones criptográficas, tendrán tarifas más altas, y también habrá una tarifa por cada ítem de almacenamiento que un contrato ocupe. Para incentivar a los contratos a mantenerse limpios, si un contrato reduce la cantidad de almacenamiento que utiliza, se le cobrará una tarifa negativa; de hecho, hay un opcode especial SUICIDE para limpiar un contrato y enviar todos los fondos y la cuantiosa tarifa negativa de vuelta a su creador.

2. Algoritmos de Minería: Ha habido mucho interés en hacer criptomonedas cuya minería sea resistente contra hardware especializado, permitiendo a los usuarios ordinarios con hardware común participar sin ninguna inversión de capital y ayudando a evitar la centralización. Hasta ahora, el principal antídoto ha sido Scrypt, un algoritmo de minería que requiere una gran cantidad de poder computacional y memoria para calcular; sin embargo, Scrypt no es lo suficientemente resistente a la memoria y hay compañías construyendo dispositivos especializados para ello. Hemos ideado Dagger, un prototipo de prueba de trabajo que es incluso más resistente a la memoria que Scrypt, así como algoritmos prototipo de prueba de participación como Slasher, que evitan por completo el problema de la minería. Finalmente, sin embargo, pretendemos organizar un concurso similar a los concursos que determinaron los estándares para AES y SHA-3, donde invitamos a grupos de investigación de universidades de todo el mundo a idear el mejor algoritmo de minería posible amigable con hardware común.

3. GHOST: GHOST es un nuevo protocolo de propagación de bloques iniciado por Aviv Zohar y Yonatan Sompolinsky que permite a las cadenas de bloques tener tiempos de confirmación de bloques mucho más rápidos, idealmente en el rango de 3-30 segundos, sin encontrarse con los problemas de centralización y alta tasa de bloques caducados que las confirmaciones rápidas de bloques normalmente traen. Ethereum es la primera moneda importante en integrar una versión simplificada y de un solo nivel de GHOST como parte de su protocolo.

EL PLAN

Ethereum es potencialmente un emprendimiento masivo y de amplio alcance, y tomará meses desarrollarse. Con eso en mente, la moneda se lanzará en múltiples etapas. La primera etapa, la publicación del white paper, ya ha ocurrido. Se han establecido foros, una wiki y un blog, y cualquier persona es libre de visitarlos, crear una cuenta y comentar en los foros. El 25 de enero, se lanzará una recaudación de fondos de 60 días en la conferencia en Miami, durante la cual cualquiera podrá comprar ether, la moneda interna de Ethereum, por BTC de manera similar a la recaudación de fondos de Mastercoin; el precio será de 1000 ether por 1 BTC, aunque los inversores tempranos obtendrán aproximadamente un beneficio de 2x para compensar el riesgo aumentado que están tomando al participar en el proyecto más temprano. Los participantes de la recaudación de fondos no solo obtendrán ether; también habrá una serie de recompensas adicionales, probablemente incluyendo entradas gratuitas a conferencias, un lugar para poner 32 bytes en el bloque génesis y para los principales donantes incluso la capacidad de nombrar tres subunidades de la moneda (por ejemplo, el equivalente del "microbitcoin" en BTC).

La emisión de Ethereum no será mediante un único mecanismo; en su lugar, se utilizará un enfoque de compromiso que combina los beneficios de múltiples enfoques. El modelo de emisión funcionará de la siguiente manera: Ether se lanzará en una recaudación de fondos al precio de 1000-2000 ether por BTC, con los financiadores anteriores obteniendo un mejor precio para compensar la incertidumbre aumentada de participar en una etapa anterior. La cantidad mínima de financiación será de 0.01 BTC. Supongamos que X ether se libera de esta manera:

• 0.225X ether se asignará a los miembros fiduciarios y a los primeros colaboradores que participaron sustancialmente en el proyecto antes del inicio de la recaudación de fondos. Esta parte se almacenará en un contrato de bloqueo de tiempo; aproximadamente el 40% de ella será gastable después de un año, el 70% después de dos años y el 100% después de 3 años.

• 0.05X ether se asignará a un fondo para usar para pagar gastos y recompensas en ether entre el inicio de la recaudación de fondos y el lanzamiento de la moneda.

• 0.225X ether se asignará como un fondo de reserva a largo plazo para pagar gastos, salarios y recompensas en ether después del lanzamiento de la moneda.

• 0.4X ether será minado por año para siempre después de ese punto.

Existe una distinción importante en comparación con Bitcoin y la mayoría de las otras criptomonedas: aquí, el suministro final es ilimitado. El modelo de "inflación lineal permanente" está diseñado para hacer que el ether no sea inflacionario ni deflacionario; la falta de un límite de suministro tiene la intención de amortiguar algunos de los efectos especulativos y de desigualdad de riqueza de las monedas existentes, pero al mismo tiempo, el modelo de inflación lineal, en lugar del tradicionalmente exponencial, significará que la tasa de inflación efectiva tiende a cero con el tiempo. Además, dado que el suministro inicial de la moneda no comenzará desde cero, el crecimiento del suministro de la moneda en los primeros ocho años será en realidad más lento que el de Bitcoin, dando a los participantes de la recaudación de fondos y a los primeros adoptantes la oportunidad de beneficiarse sustancialmente a mediano plazo.

En algún momento de febrero, lanzaremos una red de prueba centralizada - un servidor que cualquiera puede usar para enviar transacciones y crear contratos. Poco después de eso, vendrá la red de prueba descentralizada, que usaremos para probar diferentes algoritmos de minería y asegurarnos de que el daemon de par a par funcione y sea seguro, y tomar medidas para buscar optimizaciones en el lenguaje de script. Finalmente, una vez que estemos seguros de que el protocolo y el cliente son seguros, lanzaremos el bloque génesis y permitiremos que comience la minería.

MIRANDO HACIA EL FUTURO

Dado que Ethereum incluye un lenguaje de script completo según Turing, se puede demostrar matemáticamente que puede hacer esencialmente cualquier cosa que una criptomoneda basada en blockchain similar a Bitcoin potencialmente pueda hacer. Pero aún hay problemas que el protocolo, tal como está hoy, deja sin resolver. Por ejemplo, Ethereum no ofrece una solución al problema fundamental de escalabilidad en todas las criptomonedas basadas en blockchain, es decir, el hecho de que cada nodo completo debe almacenar la hoja de balance completa y verificar cada transacción. El concepto de Ethereum de un "árbol de estado" y "lista de transacciones" separados, tomado de Ripple, mitiga esto hasta cierto punto, pero aun así no se logra un avance fundamental. Para ello, se requerirá tecnología como la Integridad y Privacidad Computacional Segura (SCIP) de Eli ben Sasson, actualmente en desarrollo.

Además, Ethereum no ofrece mejoras sobre la minería tradicional de prueba de trabajo con todos sus defectos, y la prueba de excelencia y el consenso al estilo de Ripple quedan sin explorar. Si resulta que la prueba de participación o algún otro algoritmo de prueba de trabajo es una mejor solución, entonces las futuras criptomonedas podrían usar algoritmos de prueba de participación como MC2 y Slasher en su lugar. Si hay espacio para un Ethereum 2.0, es en estas áreas donde se encontrarán las mejoras. Y en última instancia, Ethereum es un proyecto sin un final definido; si el proyecto obtiene suficiente financiamiento, podríamos ser nosotros mismos quienes lancemos Ethereum 2.0, trasladando los saldos de cuentas originales a una red aún más mejorada. En última instancia, tal como es nuestro lema para la moneda en sí, el único límite es nuestra imaginación.

*Imagen de portada: Presentación de Vitálik en la apertura de ETH LATAM 2024 en San Pedro Sula, Honduras.

Por cierto, si te gusta este contenido, ¡no olvides mintearlo y contribuye así directamente al proyecto!

***

El blogpost aborda la evolución de la visión inicial de las criptomonedas, mencionando peregrinaciones de Vitálik al Bitcoin Kiez, o al mítico Room 77, un restaurante “al final del capitalismo [donde hay] cerveza caliente, mujeres frías y comida rápida preparada de manera lenta” y que está situado en la “Graefestrasse, Berlín, Alemania - Europa - Planeta Tierra - Sistema Solar - Vía Láctea - Superclúster Virgo” según reza el archivo de su página web.

“La razón por la que traigo estos recuerdos” comenta Vitálik, “es que me recuerdan una visión más profunda subyacente a las criptomonedas: no estamos aquí simplemente para crear herramientas y juegos aislados, sino más bien construir de manera integral hacia una sociedad y una economía más libres y abiertas, donde las diferentes partes -tecnológicas, sociales y económicas- encajen unas con otras”.

Vitálik hace entonces un breve repaso sobre el movimiento del software de código abierto y gratuito desde su creción en los 80s y 90s, y las crecientes dificultades a los que el movimiento se enfrenta. En esta coyuntura, Ethereum puede llegar a ser un “disco duro compartido público y descentralizado”, realizando “la visión original de la cual nació el término ahora omnipresente ‘web3’”.

El principal culpable que ha evitado una adopción aun más masiva es “el aumento en las tarifas de transacción”, según nos dice el autor. Pero esto se está volviendo un problema del pasado, ya que ahora contamos con importantes avances como los rollups, soluciones de privacidad de segunda generación, la abstracción de cuentas, los clientes ligeros y las pruebas de conocimiento cero.

Luego, Vitálik hace un recuento de los valores compartidos de la comunidad de Ethereum: participación abierta y global, descentralización, resistencia a la censura, auditabilidad, neutralidad creíble, construcción de herramientas, no imperios y mentalidad cooperativa.

El autor pasa luego a hablar sobre el ethos pluralista de Ethereum: “Bitcoin intenta resolver un problema, o como máximo dos o tres. Ethereum, por otro lado, tiene muchas subcomunidades con muchos enfoques diferentes. No hay una narrativa dominante única. El objetivo de la pila es permitir este pluralismo, pero al mismo tiempo esforzarse por lograr una interoperabilidad creciente en toda esta pluralidad”.

Si bien es cierto que “hay muchas personas cuya primera introducción al espacio criptográfico es el deseo de enriquecerse […] luego se familiarizan con el ecosistema y se convierten en fervientes creyentes en la misión de construir un mundo más abierto y descentralizado”.

Por ello, como conclusión, Vitálik pasa a hablar sobre la capa social, las comunidades, como catalizadores para revitalizar la visión original, para que Ethereum “sea realmente el ecosistema sin permisos, descentralizado, resistente a la censura y de código abierto que originalmente vinimos a construir”.

***

En resumen, el artículo de Vitálik Buterin es un llamado a la comunidad plural de Ethereum a que recordemos el propósito original del movimiento, a no perder el rubro en los hypes del momento y a construir de manera colectiva la siguiente generación del internet.

He mantenido la fidelidad al texto original tanto como me fue posible, incluso incluyendo las imágenes e hipervínculos del artículo original. Más que un simple artículo, éste es un viaje intenso donde cada enlace te lleva a un fascinante "rabbit hole" de información, profundizando en los principios y valores detrás de Ethereum y web3.

¡Espero que disfruten tanto la lectura como lo hice yo!

Muchas gracias a Skyler Weaver por los consejos y orientación en este proyecto.

Hacer Ethereum cyberpunk otra vez

28 de diciembre de 2023

Un agradecimiento especial a Paul Dylan-Ennis por su retroalimentación y revisión.

Uno de mis recuerdos favoritos de hace diez años fue hacer una peregrinación a una parte de Berlín que se llamaba el Bitcoin Kiez: una región en Kreuzberg donde había alrededor de una docena de tiendas a pocos cientos de metros de distancia que aceptaban Bitcoin como pago. El centro de esta comunidad era Room 77, un restaurante y bar dirigido por Joerg Platzer. Además de simplemente aceptar Bitcoin, también funcionaba como un centro comunitario, y todo tipo de desarrolladores de código abierto, activistas políticos de varias afiliaciones y otros personajes venían con frecuencia.

Un recuerdo similar de dos meses antes fue PorcFest (que se pronuncia "porc" como en "puercoespín", como en "no me pises"), una reunión libertaria en los bosques del norte de New Hampshire, donde la principal forma de obtener comida era de pequeños restaurantes emergentes con nombres como "Revolution Coffee" y "Seditious Soups, Salads and Smoothies", que por supuesto aceptaban Bitcoin. Aquí también, discutir el significado político más profundo de Bitcoin y usarlo en la vida diaria, sucedían lado a lado.

La razón por la que traigo estos recuerdos es que me recuerdan una visión más profunda subyacente a las criptomonedas: no estamos aquí simplemente para crear herramientas y juegos aislados, sino más bien construir de manera integral hacia una sociedad y una economía más libres y abiertas, donde las diferentes partes -tecnológicas, sociales y económicas- encajen unas con otras.

La visión inicial de "web3" también era una visión de este tipo, yendo en una dirección igualmente idealista pero algo diferente. El término "web3" fue acuñado originalmente por el cofundador de Ethereum, Gavin Wood, y se refiere a una forma diferente de pensar sobre lo que es Ethereum: en lugar de verlo, como yo lo hice inicialmente, como "Bitcoin más contratos inteligentes", Gavin lo pensó de manera más amplia como uno de un conjunto de tecnologías que juntas podrían formar la capa base de una pila de internet más abierta.

Cuando el movimiento del software de código abierto gratuito comenzó en los años 1980 y 1990, el software era simple: se ejecutaba en tu computadora y leía y escribía archivos que permanecían en tu computadora. Pero hoy en día, la mayoría de nuestro trabajo importante es colaborativo, a menudo a gran escala. Y así, hoy en día, incluso si el código subyacente de una aplicación es abierto y gratuito, tus datos se enrutan a través de un servidor centralizado administrado por una corporación que podría leer tus datos arbitrariamente, cambiar las reglas o desplazarte en cualquier momento. Y así que si queremos extender el espíritu del software de código abierto al mundo de hoy, necesitamos que los programas tengan acceso a un disco duro compartido para almacenar cosas que múltiples personas necesitan modificar y acceder. ¿Y qué es Ethereum, junto con tecnologías hermanas como la mensajería peer-to-peer (entonces Whisper, ahora Waku) y el almacenamiento de archivos descentralizado (entonces solo Swarm, ahora también IPFS)? Un disco duro compartido público y descentralizado. Esta es la visión original de la cual nació el término ahora omnipresente "web3".

Desafortunadamente, desde aproximadamente 2017, estas visiones han quedado algo relegadas a un segundo plano. Pocos hablan sobre los pagos criptográficos para consumidores, la única aplicación no financiera que realmente se está utilizando a gran escala en cadena es ENS, y existe una gran brecha ideológica donde partes significativas de la comunidad de descentralización no relacionada con blockchain ven al mundo criptográfico como una distracción, y no como un espíritu afín y un aliado poderoso. En muchos países, las personas utilizan criptomonedas para enviar y guardar dinero, pero a menudo lo hacen a través de medios centralizados: ya sea a través de transferencias internas en cuentas de intercambio centralizadas, o mediante el comercio de USDT en Tron.

Habiendo vivido esa era, el principal culpable al que señalaría como la causa raíz de este cambio es el aumento en las tarifas de transacción. Cuando el costo de escribir en la cadena es de $0.001, o incluso de $0.1, podrías imaginar a personas creando todo tipo de aplicaciones que utilicen blockchain de diversas maneras, incluidas las no financieras. Pero cuando las tarifas de transacción superan los $100, como han ocurrido durante el pico de los mercados alcistas, queda exactamente una audiencia dispuesta a participar, y de hecho, debido a que los precios de las monedas están subiendo y se están volviendo más ricos, esa audiencia se vuelve aún más dispuesta a jugar: los jugadores “degen” o compulsivos. Los jugadores compulsivos pueden estar bien en dosis moderadas, y he hablado con muchas personas en eventos que estaban motivadas a unirse a las criptomonedas por el dinero pero se quedaron por los ideales. Pero cuando son el grupo más grande que utiliza la cadena a gran escala, esto ajusta la percepción pública y la cultura interna del espacio criptográfico, y lleva a muchos de los otros aspectos negativos que hemos visto desarrollarse en los últimos años.

Ahora, adelantémonos rápidamente a 2023. Tanto en el desafío central de escalar, como en varias "misiones secundarias" de crucial importancia para construir un futuro ciberpunk realmente viable, en realidad tenemos muchas noticias positivas para mostrar:

Los Rollups están empezando a existir de verdad.

Tras una pausa temporal después de los controles regulatorios sobre Tornado Cash, soluciones de privacidad de segunda generación como Railway y Nocturne están viendo la luz (de la luna).

La abstracción de cuentas está comenzando a despegar.

Los clientes ligeros, olvidados durante mucho tiempo, están empezando a existir de verdad.

Las zero knowledge proof, o pruebas de conocimiento cero, una tecnología que pensábamos que estaba décadas lejos, ya están aquí, son cada vez más amigables para los desarrolladores, y están al borde de ser utilizables para aplicaciones de consumo.

Estas dos cosas: la creciente conciencia de que la centralización descontrolada y la sobre-financialización no pueden ser “de lo que se trata el crypto", y las tecnologías clave mencionadas anteriormente que finalmente están dando sus frutos, nos presentan una oportunidad para tomar las cosas en una dirección diferente. Es decir, hacer que al menos una parte del ecosistema de Ethereum sea realmente el ecosistema sin permisos, descentralizado, resistente a la censura y de código abierto que originalmente vinimos a construir.

¿Cuáles son algunos de estos valores?

Muchos de estos valores son compartidos no solo por muchos en la comunidad de Ethereum, sino también por otras comunidades de blockchain e incluso comunidades de descentralización no relacionadas con blockchain, aunque cada comunidad tiene su propia combinación única de estos valores y cuánto énfasis se le da a cada uno.

Participación abierta y global: cualquier persona en el mundo debería poder participar como usuario, observador o desarrollador, en igualdad de condiciones máxima. La participación debe ser sin permisos.

Descentralización: minimizar la dependencia de una aplicación en cualquier actor único. En particular, una aplicación debería seguir funcionando incluso si sus desarrolladores principales desaparecen para siempre.

Resistencia a la censura: los actores centralizados no deberían tener el poder de interferir en la capacidad de operar de cualquier usuario o aplicación. Las preocupaciones sobre actores maliciosos deberían abordarse en capas superiores del sistema.

Auditabilidad: cualquiera debería poder validar la lógica de una aplicación y su operación continua (por ejemplo, ejecutando un nodo completo) para asegurarse de que esté operando según las reglas que sus desarrolladores afirman que sigue.

Neutralidad creíble: la infraestructura de la capa base debería ser neutral, y de tal manera que cualquiera pueda ver que es neutral incluso si no confía previamente en los desarrolladores.

Construcción de herramientas, no imperios. Los imperios intentan capturar y atrapar al usuario dentro de un jardín amurallado; las herramientas hacen su tarea pero de lo contrario interoperan con un ecosistema abierto más amplio.

Mentalidad cooperativa: incluso compitiendo, los proyectos dentro del ecosistema cooperan en bibliotecas de software compartidas, investigación, seguridad, construcción de comunidades y otras áreas que son comúnmente valiosas para ellos. Los proyectos intentan ser de suma positiva, tanto entre ellos como con el mundo en general.

Es muy posible construir cosas dentro del ecosistema criptográfico que no sigan estos valores. Se puede construir un sistema que se llame "capa 2", pero que en realidad sea un sistema altamente centralizado asegurado por una multisig, sin planes de cambiar a algo más seguro. Se puede construir un sistema de abstracción de cuentas que intente ser "más simple" que ERC-4337, pero a costa de introducir suposiciones de confianza que terminan eliminando la posibilidad de un mempool público y dificultan mucho más la incorporación de nuevos constructores. Se podría construir un ecosistema de NFT donde el contenido de los NFT se almacene innecesariamente en sitios web centralizados, haciéndolo innecesariamente más frágil que si esos componentes se almacenaran en IPFS. Se podría construir una interfaz de apuesta que canalice innecesariamente a los usuarios hacia el stacking pool más grande ya existente.

Resistir estas presiones es difícil, pero si no lo hacemos, corremos el riesgo de perder el valor único del ecosistema criptográfico y recrear un clon del ecosistema web2 existente con más ineficiencias y pasos adicionales.

Se necesita un alcantarillado para crear una tortuga ninja.

El espacio criptográfico es, en muchos aspectos, un entorno implacable. Un artículo de 2021 escrito por Dan Robinson y Georgios Konstantiopoulos expresa esto vívidamente en el contexto de MEV, argumentando que Ethereum es un bosque oscuro donde los traders en cadena están constantemente vulnerables a ser explotados por bots de front-running, esos bots a su vez son vulnerables a ser contrarrestados por otros bots, etc. Esto también es cierto en otros aspectos: los contratos inteligentes regularmente son hackeados, las billeteras de los usuarios regularmente son hackeadas, los intercambios centralizados fracasan aún más espectacularmente, etc.

Este es un gran desafío para los usuarios del espacio, pero también presenta una oportunidad: significa que tenemos un espacio para realmente experimentar, incubar y recibir comentarios rápidos en vivo sobre todo tipo de tecnologías de seguridad para abordar estos desafíos. Ya hemos visto respuestas exitosas a desafíos en varios contextos:

Todos quieren que el Internet sea seguro. Algunos intentan hacer que el Internet sea seguro promoviendo enfoques que obligan a depender de un solo actor particular, ya sea una corporación o un gobierno, que pueda actuar como un ancla centralizada de seguridad y verdad. Pero estos enfoques sacrifican la apertura y la libertad, y contribuyen a la tragedia que es el creciente "splinternet". Las personas en el espacio criptográfico valoran mucho la apertura y la libertad. El nivel de riesgos y las altas apuestas financieras involucradas significan que el espacio criptográfico no puede ignorar la seguridad, pero varias razones ideológicas y estructurales aseguran que los enfoques centralizados para lograr la seguridad no están disponibles para él. Al mismo tiempo, el espacio criptográfico está en la frontera de tecnologías muy poderosas como las pruebas de conocimiento cero, la verificación formal, la seguridad de claves basada en hardware y los gráficos sociales on-chain. Estos hechos juntos significan que, para la criptografía, la forma abierta de mejorar la seguridad es la única que existe.

Todo esto quiere decir que el mundo criptográfico es un entorno perfecto de laboratorio para tomar su enfoque abierto y descentralizado de seguridad y aplicarlo realmente en un entorno de alto riesgo realista, y madurarlo hasta el punto en que partes de él puedan luego aplicarse en el mundo más amplio. Esta es una de mis visiones sobre cómo las partes idealistas del mundo criptográfico y las partes caóticas del mundo criptográfico, y luego el mundo criptográfico en su conjunto y el mundo más amplio, pueden convertir sus diferencias en una simbiosis en lugar de una tensión constante y continua.

Ethereum como parte de una visión tecnológica más amplia.

En 2014, Gavin Wood presentó Ethereum como una de una serie de herramientas que se pueden construir, las otras dos son Whisper (mensajería descentralizada) y Swarm (almacenamiento descentralizado). El primero fue enfatizado en gran medida, pero con el giro hacia la financiarización alrededor de 2017, los últimos lamentablemente recibieron mucho menos amor y atención. Dicho esto, Whisper continúa existiendo como Waku y es utilizado activamente por proyectos como el mensajero descentralizado Status. Swarm continúa siendo desarrollado y ahora también tenemos IPFS, que se utiliza para alojar y servir este blog.

En los últimos años, con el surgimiento de las redes sociales descentralizadas (Lens, Farcaster, etc.), tenemos la oportunidad de volver a visitar algunas de estas herramientas. Además, también contamos con otra herramienta nueva y muy poderosa para agregar a la trifecta: las pruebas de conocimiento cero. Estas tecnologías son ampliamente adoptadas como formas de mejorar la escalabilidad de Ethereum, como los ZK rollups, pero también son muy útiles para la privacidad. En particular, la programabilidad de las pruebas de conocimiento cero significa que podemos superar el falso binario de "anónimo pero arriesgado" vs "KYC'd, por lo tanto, seguro", y obtener privacidad y muchos tipos de autenticación y verificación al mismo tiempo.

Un ejemplo de esto en 2023 fue Zupass. Zupass es un sistema basado en pruebas de conocimiento cero que fue incubado en Zuzalu, que se utilizó tanto para la autenticación en persona en eventos, como para la autenticación en línea en el sistema de votación Zupoll, el clon de Twitter Zucast y otros. La característica clave de Zupass fue esta: puedes demostrar que eres residente de Zuzalu, sin revelar qué miembro de Zuzalu eres. Además, cada residente de Zuzalu solo podía tener una identidad criptográfica generada aleatoriamente para cada instancia de aplicación (por ejemplo, una encuesta) a la que estaban accediendo. Zupass fue muy exitoso y se aplicó más tarde en el año para la venta de entradas en Devconnect.

Hasta ahora, el uso más práctico de Zupass probablemente sea las encuestas. Se han realizado todo tipo de encuestas, algunas sobre temas políticamente controvertidos o altamente personales donde las personas sienten una fuerte necesidad de preservar su privacidad, utilizando Zupass como una plataforma de votación anónima.

Aquí podemos empezar a vislumbrar los contornos de lo que sería un mundo ciberpunk-ethereum, al menos en un nivel técnico puro. Podemos tener nuestros activos en ETH y tokens ERC20, así como todo tipo de NFTs, y utilizar sistemas de privacidad basados en “stealth addresses” o direcciones ocultas y tecnología de Pools de Privacidad para preservar nuestra privacidad al mismo tiempo que bloqueamos la capacidad de actores malintencionados conocidos para beneficiarse del mismo conjunto de anonimato. Ya sea dentro de nuestros DAOs, o para ayudar a decidir sobre cambios en el protocolo Ethereum, o para cualquier otro objetivo, podemos usar sistemas de votación de conocimiento cero, que pueden utilizar todo tipo de credenciales para ayudar a identificar quién tiene derecho a votar y quién no: además de votar con tokens como se hizo en 2017, podemos tener encuestas anónimas de personas que han hecho contribuciones suficientes al ecosistema, personas que han asistido a suficientes eventos, o un voto por persona.

Los pagos en persona y en línea pueden realizarse con transacciones ultra baratas en L2s, que aprovechan el espacio de disponibilidad de datos (o datos off-chain asegurados con Plasma) junto con la compresión de datos para brindar a sus usuarios una escalabilidad ultra alta. Los pagos de un rollup a otro pueden ocurrir con protocolos descentralizados como UniswapX. Los proyectos de redes sociales descentralizadas pueden utilizar varias capas de almacenamiento para almacenar actividades como publicaciones, retweets y me gusta, y utilizar ENS (económico en L2 con CCIP) para los nombres de usuario. Podemos tener una integración perfecta entre tokens en cadena y certificaciones fuera de cadena mantenidas personalmente y probadas mediante ZK a través de sistemas como Zupass.

Mecanismos como la votación cuadrática, el consenso trans-tribal y los mercados de predicción pueden ser utilizados para ayudar a que las organizaciones y comunidades se gobiernen a sí mismas y se mantengan informadas, y las identidades basadas en blockchain y pruebas de conocimiento cero pueden hacer que estos sistemas sean seguros tanto contra la censura centralizada desde el interior como contra la manipulación coordinada desde el exterior. Carteras sofisticadas pueden proteger a las personas mientras participan en dapps, y las interfaces de usuario pueden ser publicadas en IPFS y accedidas como dominios .eth, con los hashes del HTML, JavaScript y todas las dependencias de software actualizadas directamente en cadena a través de un DAO. Las billeteras de contratos inteligentes, creadas para ayudar a las personas a no perder decenas de millones de dólares de su criptomoneda, se expandirían para proteger las "raíces de identidad" de las personas, creando un sistema que es aún más seguro que los proveedores de identidad centralizados como "iniciar sesión con Google".

Podemos pensar en el gran universo de Ethereum (o "web3") como la creación de una pila de protocolos tecnológicos independiente, que compite con la pila de protocolos centralizada tradicional en todos los niveles. Muchas personas combinarán ambos, y a menudo hay formas ingeniosas de combinar ambos: ¡con ZKEmail, incluso puedes hacer que una dirección de correo electrónico sea uno de los guardianes de tu billetera de recuperación social! Pero también hay muchas sinergias al usar las diferentes partes de la pila descentralizada juntas, especialmente si están diseñadas para integrarse mejor entre sí.

Uno de los beneficios de considerarlo como una pila es que encaja bien con el ethos pluralista de Ethereum. Bitcoin intenta resolver un problema, o como máximo dos o tres. Ethereum, por otro lado, tiene muchas subcomunidades con muchos enfoques diferentes. No hay una narrativa dominante única. El objetivo de la pila es permitir este pluralismo, pero al mismo tiempo esforzarse por lograr una interoperabilidad creciente en toda esta pluralidad.

La capa social

Es fácil decir "estas personas que hacen X son una influencia corruptora y mala, estas personas que hacen Y son lo verdaderamente auténtico". Pero esta es una respuesta perezosa. Para tener verdadero éxito, necesitamos no solo una visión para una pila técnica, sino también las partes sociales de la pila que hacen que la pila técnica sea posible de construir en primer lugar.

La ventaja de la comunidad de Ethereum, en principio, es que tomamos los incentivos en serio. PGP quería poner claves criptográficas en manos de todos para que pudiéramos tener correo electrónico firmado y encriptado durante décadas, en gran medida fracasó, pero luego obtuvimos criptomonedas y de repente millones de personas tienen claves asociadas públicamente a ellas, y podemos empezar a usar esas claves para otros propósitos, incluido volver completamente al correo electrónico y mensajería encriptados. Los proyectos de descentralización no basados en blockchain suelen estar crónicamente subfinanciados, mientras que los proyectos basados en blockchain obtienen una ronda de financiamiento Serie B de 50 millones de dólares. No es por la benevolencia del validador que conseguimos que las personas pongan su ETH para proteger la red de Ethereum, sino más bien por su propio interés propio, y obtenemos $20 mil millones en seguridad económica como resultado.

Al mismo tiempo, los incentivos no son suficientes. Los proyectos DeFi a menudo comienzan siendo humildes, cooperativos y completamente de código abierto, pero a veces empiezan a abandonar estos ideales a medida que crecen en tamaño. Podemos incentivar a los validadores para que vengan y participen con un tiempo de actividad muy alto, pero es mucho más difícil incentivar a los validadores para que sean descentralizados. Es posible que no se pueda hacer utilizando únicamente medios puramente protocolares. Muchas piezas críticas de la "pila descentralizada" descrita anteriormente no tienen modelos de negocio viables. La gobernanza del protocolo Ethereum en sí misma es notablemente no financiarizada, y esto la ha hecho mucho más robusta que otros ecosistemas cuya gobernanza es más financiarizada. Es por eso que es valioso para Ethereum tener una capa social fuerte, que aplique vigorosamente sus valores en aquellos lugares donde los incentivos puros no pueden, pero sin crear una noción de "alineación con Ethereum" que se convierta en una nueva forma de corrección política.

Existe un equilibrio entre estos dos aspectos que debe lograrse, aunque el término adecuado no es tanto equilibrio como integración. Hay muchas personas cuya primera introducción al espacio criptográfico es el deseo de enriquecerse, pero que luego se familiarizan con el ecosistema y se convierten en fervientes creyentes en la misión de construir un mundo más abierto y descentralizado.

¿Cómo logramos que esta integración suceda realmente? Esta es la pregunta clave, y sospecho que la respuesta no radica en una bala mágica, sino en una colección de técnicas que se desarrollarán de manera iterativa. El ecosistema de Ethereum ya es más exitoso que la mayoría en fomentar una mentalidad cooperativa entre los proyectos de capa 2 simplemente a través de medios sociales. La financiación de bienes públicos a gran escala, especialmente los Grants de Gitcoin y las rondas RetroPGF de Optimism, también es extremadamente útil, porque crea un canal de ingresos alternativo para los desarrolladores que no ven ningún modelo de negocio convencional que no requiera sacrificar sus valores. Pero incluso estas herramientas todavía están en su infancia, y hay un largo camino por recorrer tanto para mejorar estas herramientas particulares, como para identificar y desarrollar otras herramientas que podrían ser más adecuadas para problemas específicos.

Aquí es donde veo la propuesta de valor única de la capa social de Ethereum. Hay una mezcla única de valorar los incentivos, pero también de no dejarse consumir por ellos. Hay una combinación única de valorar una comunidad cálida y cohesionada, pero al mismo tiempo recordar que lo que se siente "cálido y cohesionado" desde adentro puede fácilmente sentirse "opresivo y exclusivo" desde afuera, y valorar las normas sólidas de neutralidad, código abierto y resistencia a la censura como una forma de protegerse contra los riesgos de ir demasiado lejos en ser impulsado por la comunidad. Si esta mezcla puede funcionar bien, estará en la mejor posición posible para realizar su visión en el nivel económico y técnico.

Soy Javi, un cineasta y escritor de El Salvador. Desde 2021 me interesé por la web3 y he estado aprendiendo constantemente. Hace algunos meses me uní al equipo de ETH Volcano, la comunidad de El Salvador dedicada a promover el conocimiento y los casos de uso de Ethereum en la región.

El propósito de este blog es claro: deseo contribuir al ecosistema brindando una comprensión más profunda sobre la filosofía y los valores que impulsan Ethereum, así como explorar las posibilidades y alternativas que ofrece la tecnología blockchain y la Web3 en comparación con la Web2 y el uso centralizado de la información.

Recientemente, tuve el privilegio de asistir a la conferencia ETH LATAM en San Pedro Sula. Durante la ponencia introductoria, Skylar Weaver mencionó uno de los artículos más recientes de Vitalik Buterin: “Make Ethereum Cypherpunk Again”. Me di cuenta de que la mayoría de los escritos de Vitalik no han sido traducidos al español, y aquí es donde surge la inspiración para este blog: contribuir con traducciones de sus obras para que las comunidades hispanohablantes podamos tener acceso a sus ideas innovadoras y revolucionarias.

Hablamos mucho sobre DeFi, NFTs y otros casos de uso dentro de nuestras comunidades, pero creo firmemente que entender las ideas fundamentales de Ethereum es crucial para dar forma al futuro de manera significativa. Por eso, en este espacio nos enfocaremos en explorar y explicar esas ideas de una manera accesible y comprensible para todos.

Gracias por unirse a este viaje 🫶🏼.

Espero que disfruten y aprendan tanto como yo lo hago cada día.

Javi.