Gavin Wood: Después de EVM, JAM se convertirá en el nuevo consenso de la industria.

Continuando con el artículo de ayer, ¡compartimos la segunda parte de la última entrevista de Gavin Wood!

Las blockchains públicas pueden competir entre sí, pero los desarrolladores solo se agrupan en torno al consenso.

Hace diez años, el EVM inventado por Gavin se convirtió en consenso; desde entonces, toda la industria tiene un “lenguaje” común.

Diez años después, Gavin lanza JAM y espera que se convierta en el próximo “lenguaje”.

No es una herramienta de una sola cadena, sino un protocolo subyacente que permite a todas las cadenas obtener escalabilidad elástica, colaboración distribuida y capacidad de interoperabilidad entre redes.

Cualquier constructor puede crear su propio sistema sobre él, e incluso permitir que diferentes tokens y ecosistemas compartan la misma red de seguridad.

Para los desarrolladores, esto significa una cosa:

Construir la próxima generación de blockchain ya no requiere empezar desde cero, JAM es el nuevo punto de partida por defecto.

El ambiente de JAM es algo que no sentía desde 2015

Pala Labs: Actualmente, la gira global de JAM ya está a mitad de camino. Has viajado personalmente por todo el mundo para reunirte con desarrolladores activos de JAM y con seguidores interesados y entusiastas. ¿Cómo te sientes respecto al modelo de construcción descentralizada de JAM?

Gavin: Hasta ahora, soy muy optimista sobre el progreso general de JAM. Los desarrolladores de JAM muestran un entusiasmo y una proactividad que no eran comunes durante el desarrollo de Polkadot—realmente aman este proyecto y están dispuestos a asumir una verdadera responsabilidad por su trabajo.

Para entender esta diferencia, hay que volver al modelo de desarrollo de Polkadot. En ese momento, el desarrollo se realizaba dentro de una estructura empresarial. Aunque había personas comprometidas y dispuestas a asumir responsabilidades, bajo la estructura de la empresa, esa “proactividad” era en parte una consecuencia natural del sistema: recibes un salario, así que asumir responsabilidades es parte de tu trabajo.

Pero JAM es completamente diferente. Los desarrolladores actuales no tienen un salario estable; invierten su propio tiempo, energía y asumen riesgos. Es cierto que en el futuro podrían recibir financiación o recompensas, pero primero deben entregar resultados. En comparación, la lógica de una empresa es opuesta: la empresa paga un salario alto por adelantado y asume el riesgo de si el empleado es competente o no.

Los desarrolladores de JAM asumen el riesgo ellos mismos, y esa inversión ya dice mucho. Estás ante un equipo que realmente construye por una visión y es capaz de entregar resultados. En este entorno, se percibe una fe poco común, algo que es difícil de encontrar en empleados de empresas tradicionales.

En última instancia, la estructura organizativa de una empresa tradicional es esencialmente un sistema de poder de arriba hacia abajo: el jefe tiene la máxima autoridad, delega a los altos directivos, estos a los líderes de equipo y finalmente los empleados ejecutan las tareas. Todos deben reportar a sus superiores, seguir instrucciones y su desempeño depende de la evaluación de sus superiores.

Pero JAM no es así en absoluto.

En este proyecto, soy más como un asesor, solo respondo preguntas cuando la gente lo necesita—a veces de forma breve, incluso un poco directa, pero en general amigable. Además, me encargo de escribir el gray paper y de verificar si los diseños son viables, al menos convencerme a mí mismo y, si es posible, que otros entiendan la racionalidad de estas propuestas.

Sin embargo, quienes realmente impulsan JAM hacia adelante no soy yo, sino los equipos de desarrollo involucrados. Puede que participen por pasión, para ganar experiencia o porque creen que este sistema tendrá valor comercial en el futuro. Pero sea cual sea la motivación, están construyendo este sistema de manera activa y espontánea.

Este ambiente es algo que no sentía desde 2015, muy parecido a los primeros días de Ethereum: todos participaban con entusiasmo; incluso si el gray paper era extremadamente complejo, estaban dispuestos a dedicar mucho tiempo a entenderlo y convertirlo paso a paso en software funcional.

Después del EVM, JAM será el nuevo consenso de la industria

Pala Labs: Por lo que cuentas, JAM no es solo un proyecto blockchain tradicional, parece ir más allá de las criptomonedas e incluso tiene una visión más amplia que Polkadot. Si tuvieras que explicar JAM a alguien que no conoce Polkadot, ¿cómo lo describirías? ¿Para qué sirve esta herramienta?

Gavin: En términos simples, JAM es un protocolo llamado “Join Accumulate Machine”, cuya especificación completa está claramente escrita en el gray paper de JAM. Según el gray paper, JAM combina las principales ventajas de Polkadot y Ethereum:

• Por un lado, hereda el mecanismo criptoeconómico de Polkadot—es este mecanismo el que soporta la alta escalabilidad de Polkadot;
• Por otro lado, adopta una interfaz y un modelo de servicios más cercanos a Ethereum, permitiendo que la cadena principal sea programable.

A diferencia de las arquitecturas tradicionales que solo permiten programar módulos de cómputo de alto rendimiento, JAM va más allá. No solo permite programar las unidades de cómputo, sino también el “proceso de colaboración” y el “efecto acumulativo” entre diferentes módulos—de ahí el nombre “Join Accumulate Machine”.

Aunque JAM se propuso inicialmente como una propuesta de actualización de Polkadot y recibió un amplio apoyo de la comunidad, su diseño no se limita a Polkadot. Es una arquitectura subyacente altamente abstracta e independiente de cualquier blockchain específica, puede considerarse el diseño base de la próxima generación de blockchains.

La capacidad central de JAM es que puede programar y distribuir cargas de trabajo de manera segura y distribuida en toda la red, proporcionando escalabilidad elástica de forma nativa a las aplicaciones que se ejecutan sobre ella—algo que ninguna otra solución en la industria puede lograr actualmente.

Aún más, JAM permite la interconexión de múltiples instancias de red, superando las limitaciones de una sola cadena. Así, no solo es una nueva arquitectura de cadena, sino que también puede convertirse en el paradigma de la próxima generación de soluciones de escalabilidad.

Podemos ver JAM fuera del marco de “propuesta de actualización de Polkadot”. Como insistí al escribir el gray paper: soy mejor haciendo trabajo pionero de cero a uno, no llevando un sistema existente de uno a cien. Por eso, el diseño de JAM no se basa en expandir gradualmente un marco existente, sino en partir de los principios más básicos y construir un sistema completamente nuevo desde cero.

Aunque JAM absorbe algunos logros técnicos de Polkadot, también incorpora muchas ideas y mecanismos completamente nuevos. Al sistematizar estos contenidos en el gray paper, espero desvincularlo del contexto de Polkadot y convertirlo en una arquitectura subyacente de mayor valor—algo parecido al conjunto de instrucciones x64 de antaño.

Hablando de esto, vale la pena repasar la historia de x64. Intel diseñó originalmente el conjunto de instrucciones x86 para sus procesadores, evolucionando desde el 8086 al 80286, 80386 y la serie Pentium, convirtiéndose en el estándar de las computadoras compatibles con IBM y dominando el sector de la computación de escritorio durante mucho tiempo.

Pero cuando la industria se preparaba para la era de 64 bits, la propuesta propia de Intel era demasiado avanzada y no fue aceptada por el mercado. AMD, considerada un “seguidor”, diseñó una extensión de 64 bits más simple y viable basada en el conjunto de instrucciones de 32 bits de Intel—AMD64. El mercado eligió la ruta de AMD, e Intel tuvo que abandonar su propia propuesta y adoptar la extensión de AMD. Desde entonces, los roles de líder y seguidor se invirtieron.

Esta historia es significativa. Aunque Intel adoptó la tecnología de AMD, no quería usar el nombre “AMD64”, y la industria finalmente adoptó el término neutral “x64”. Hoy, ambas empresas construyen productos sobre esta arquitectura de conjunto de instrucciones unificada.

Menciono este caso porque creo que JAM tiene el potencial de convertirse en la “tecnología x64” del sector blockchain. Se considera la dirección racional de la evolución de las blockchains, especialmente adecuada para aquellas que valoran la resiliencia y la descentralización, principios de Web3. El protocolo mantiene deliberadamente un diseño abierto en muchos aspectos, como el modelo de gobernanza, el mecanismo de emisión de tokens y el sistema de staking, lo que significa que diferentes proyectos blockchain pueden personalizar la implementación de estos módulos e incluso elegir su propio lenguaje de programación al adoptar JAM.

El PVM que utiliza JAM es una arquitectura de conjunto de instrucciones altamente generalizada. Las cadenas que adopten esta arquitectura pueden beneficiarse de la escalabilidad y composabilidad de JAM, e incluso podrían lograr la colaboración e integración entre diferentes cadenas a través de JAM en el futuro.

Últimamente estoy pensando en una dirección—espero poder publicarla pronto—sobre cómo permitir que dos redes blockchain basadas en JAM, pero con diferentes tokens, logren una mayor integración: compartir la misma red de seguridad manteniendo sus propios sistemas de tokens. Creo que, aunque esta vía técnica no sea la forma definitiva de la industria blockchain, sí puede ser un avance importante que cambie el panorama del sector.

Desde una perspectiva más amplia, JAM probablemente se convertirá, como la tecnología temprana de Ethereum, en una base común de referencia para la industria. El EVM de Ethereum ya ha sido adoptado o parcialmente adoptado por muchas blockchains públicas, y su formato de transacción y lógica de ejecución se han convertido en el estándar de facto de la industria. JAM también tiene este potencial tecnológico neutral entre tokens y redes.

Como he enfatizado repetidamente, JAM debe ser una tecnología subyacente neutral. Estoy convencido de que su diseño puede sostener el desarrollo estable de la industria blockchain durante los próximos cinco a diez años, o incluso más. Por supuesto, el sistema seguirá evolucionando. Si las pruebas de conocimiento cero (ZK) se vuelven económicamente viables, algunos módulos de JAM podrían ser reemplazados. Pero en general, JAM, como innovación sistémica razonable, no estará limitada al ecosistema Polkadot; cualquier cadena que reconozca su valor puede adoptarla bajo su propio marco de gobernanza.

Además, JAM ha insistido desde el principio en la descentralización y el principio de “primero la especificación”: primero se publica la especificación del protocolo, luego se organiza la implementación y se promueve la participación de más de 35 equipos independientes de todo el mundo, distribuyendo el conocimiento y el control de forma natural. Este enfoque ayudará a que JAM se convierta en la tecnología central subyacente verdaderamente neutral y ampliamente adoptada en el mundo Web3.

En la “era post-confianza”, Gavin dice a los jóvenes desarrolladores: Web3 no es una opción, es una responsabilidad

Pala Labs: En esta ocasión nos hemos encontrado con muchos desarrolladores entusiastas de JAM, muchos de ellos muy jóvenes, quizás aún estudiantes, representando la nueva generación del sector. Si tuvieras que decirles algo—aquellos que quizás se parecen a ti hace 20 años, apasionados por crear y soñando con una sociedad y un mundo libres—¿qué les dirías?

Gavin: Entra lo antes posible y profundiza. Debes seguir tu propio juicio de valores. Si crees en los principios fundamentales de la Ilustración, como la libertad de voluntad y la soberanía personal, entonces debes actuar por ti mismo—porque nadie puede asumir esa responsabilidad por ti.

Pala Labs: ¿La inteligencia artificial también traerá problemas de suplantación de identidad?

Gavin: El sistema de confianza de la sociedad actual se está desmoronando rápidamente. Alrededor de 2014 o 2015, se popularizó el término “era post-verdad”, que significa que la gente ya no cree en la existencia de una verdad objetiva. Aunque esta observación tiene cierto valor, filosóficamente no es válida. Siempre he sostenido que la verdad existe y que la humanidad tiene el deber de buscarla. Si una decisión no se basa en los hechos más razonables y fiables disponibles, inevitablemente será errónea.

Aun así, realmente hemos entrado en una “era post-confianza”: la gente o duda de todo o deposita su confianza ciegamente en agitadores peligrosos. Ambos extremos están erosionando la racionalidad social. En este contexto, la inteligencia artificial solo amplificará el problema.

Por supuesto, la IA tiene un impacto positivo en muchos campos, como mejorar la comunicación y enriquecer la creación artística. Yo mismo la uso cuando hago de DJ o creo música. Pero en los ámbitos socioeconómico, político y geopolítico, los riesgos de la IA no deben subestimarse.

No podemos depositar nuestras esperanzas en la regulación. La regulación suele limitar las oportunidades de los individuos respetuosos de la ley en sociedades libres para usar IA, pero no puede detener a las organizaciones maliciosas ni evitar que los países no libres utilicen IA para atacar a las sociedades libres. Por tanto, la regulación por sí sola no es la solución.

Lo verdaderamente necesario es: utilizar una base tecnológica más sólida y potente para limitar el impacto destructivo potencial de la inteligencia artificial—ya sea para prevenir abusos internos o para defenderse de amenazas externas maliciosas.

En mi opinión (aunque pueda parecer parcial), solo la tecnología Web3 puede resolver realmente este problema. La razón no es complicada: la esencia de la IA es “debilitar la verdad y reforzar la confianza”. Cuando dependemos de la inteligencia artificial, en realidad dependemos de las organizaciones que proporcionan los modelos y servicios—ya sean las que entrenan los grandes modelos o los proveedores que ejecutan los modelos en servidores cerrados y devuelven resultados.

Pero no podemos auditar los datos de entrenamiento del modelo, ni saber por qué da una respuesta concreta; ni siquiera los propios entrenadores entienden realmente el mecanismo interno del modelo. En comparación, es más fiable que las personas verifiquen los hechos por sí mismas. Sin embargo, a medida que la sociedad depende cada vez más de la IA y confía en ella con facilidad, la gente cae en una “confianza aparentemente objetiva pero en realidad ciega”.

Dado que la lógica de la IA es “menos verdad, más confianza”, debemos contrarrestarla con la tecnología Web3, que es “menos confianza, más verdad”.

En una sociedad libre, lo que realmente se debe hacer no es seguir reforzando la regulación sobre Web3, sino actuar cuanto antes: reducir las restricciones innecesarias y proporcionar apoyo y financiación reales a quienes construyen la infraestructura de Web3.

Pala Labs: Ahora muchos nuevos desarrolladores se están uniendo al proyecto JAM, ¿puedes prever cómo será el desarrollo en los próximos cinco o seis años?

Gavin: Predecir el futuro siempre es difícil, pero puedo compartir mi experiencia. A finales de noviembre de 2013, vivía en Londres y tenía un amigo llamado “Johnny Bitcoin”, que también era amigo de Vitalik. Nos reuníamos cada mes en un bar para tomar una cerveza y charlar. En una de esas ocasiones, me dijo que su amigo Vitalik estaba trabajando en un nuevo proyecto basado en bitcoin, llamado Ethereum, y que buscaba a alguien para desarrollar el código. Medio en broma le dije: “Vale, déjamelo a mí”. Siempre he pensado que soy bueno programando, así que me sugirió: “Si eres tan bueno, ¿por qué no desarrollas Ethereum tú?”. Así me convertí en uno de los desarrolladores de Ethereum. En ese momento, el white paper de Ethereum era una mezcla entre un documento de visión y una especificación formal clara; aunque no era completamente inequívoco, tenía suficientes detalles técnicos para ser viable. Durante los siguientes cuatro o cinco meses, todos trabajamos en el desarrollo de diferentes versiones compatibles, lo que finalmente dio lugar al yellow paper de Ethereum—la especificación formal del protocolo. Yo era el desarrollador independiente responsable de este protocolo, junto con Vitalik, y Jeff, que desarrollaba la versión en Go de Ethereum. Luego me convertí en cofundador de Ethereum, fundé Parity y seguí desarrollando más productos relacionados.

Así empezó mi camino en blockchain—como desarrollador independiente, confiando completamente en mi tiempo libre para desarrollar un protocolo desde cero.

Así que no estoy seguro de si el equipo de desarrollo de JAM disfrutará tanto como yo de este viaje. Pero para mí, realmente fue el comienzo de mi vida; no tenía otra opción, solo podía empezar desde ahí, y resultó que el potencial era mucho mayor de lo que imaginaba.

Por supuesto, no solo hay que programar, también hay que aprender a comunicarse: contactar con inversores potenciales, presentar el proyecto, idear casos de uso basados en el protocolo, escribir smart contracts, promocionar el proyecto, asesorar a otros, etc. Además de programar, hay muchas cosas que hacer, pero programar es el punto de partida y el núcleo de todo.

En los últimos 11 años, casi nunca he dejado de programar durante mucho tiempo. De hecho, esta experiencia se remonta a mucho antes; desde los ocho o nueve años casi nunca he parado—la interrupción más larga fue un viaje de senderismo por Centroamérica, y solo duró tres meses.

Ese es el camino que he seguido. Si estos nuevos desarrolladores tienen suficiente pasión y capacidad, en mi opinión, nada puede impedirles seguir este camino—¡solo que esta vez el objetivo es JAM y no Ethereum!