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

Siguiendo 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 “idioma” común.

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

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 mundial de JAM ya está a mitad de camino, y vos mismo viajaste por el mundo para encontrarte con desarrolladores reales de JAM y con seguidores interesados y apasionados. ¿Qué sentís respecto a este 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, en una estructura corporativa, esa “proactividad” viene dada por el sistema—recibís un sueldo, y 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 pueden recibir financiamiento o recompensas, pero primero deben entregar resultados. En cambio, la lógica de una empresa es al revés: primero paga sueldos altos y la empresa asume el riesgo de si el empleado está a la altura o no.

Los desarrolladores de JAM asumen el riesgo ellos mismos, y esa inversión ya dice mucho. Estás frente a un equipo que realmente construye por una visión y puede producir resultados. En este entorno, ves una convicción poco común—algo que es difícil de encontrar en empleados de empresas tradicionales.

En última instancia, la estructura organizacional 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 jefes.

Pero JAM no es para nada así.

En este proyecto, yo soy más como un asesor, solo respondo preguntas cuando me necesitan—a veces de forma breve, incluso algo directa, pero en general de manera amigable. Además, me encargo de escribir el gray paper y trato de verificar si el diseño es viable, al menos convencerme a mí mismo y también ayudar a otros a entender la lógica de estas propuestas.

Sin embargo, quienes realmente impulsan JAM hacia adelante no soy yo, sino los equipos de desarrollo. Se involucran 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 la primera vez que lo siento desde 2015, muy parecido a los primeros días de Ethereum — todos participaban con entusiasmo; aunque el gray paper era muy 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 decís, JAM no es solo un proyecto blockchain tradicional, parece ir más allá de la blockchain y las criptomonedas, incluso más allá del alcance de Polkadot. Si tuvieras que explicarle JAM a alguien que no conoce Polkadot, ¿cómo lo describirías? ¿Para qué sirve esta herramienta?

Gavin: En pocas palabras, 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 ventajas principales de Polkadot y Ethereum:

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

A diferencia de las arquitecturas tradicionales que solo permiten programar módulos 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 para 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, y 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 de manera segura y descentralizada la carga de trabajo en toda la red, permitiendo que las aplicaciones que corren sobre ella tengan escalabilidad elástica de forma nativa—algo que ninguna otra solución en la industria puede lograr hoy.

Aún más, JAM permite interconectar múltiples instancias de red, rompiendo el límite de una sola cadena para la expansión de aplicaciones. Esto lo convierte no solo en una nueva arquitectura de cadena, sino también en un posible paradigma para las soluciones de escalabilidad de próxima generación.

Podemos ver JAM fuera del marco de “propuesta de actualización de Polkadot”. Como insistí al escribir el gray paper: soy mejor haciendo trabajo innovador de cero a uno, no tanto en llevar un sistema existente del uno al 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 incorpora algunos logros técnicos de Polkadot, también introduce muchas ideas y mecanismos nuevos. Al sistematizarlos en el gray paper, busco extraerlos del contexto de Polkadot y convertirlos en una arquitectura subyacente de valor más amplio—algo parecido al conjunto de instrucciones x64 en su momento.

Hablando de esto, vale la pena repasar la historia de x64. Intel diseñó originalmente el conjunto de instrucciones x86 para sus procesadores, desde los primeros 8086, 80286, 80386 hasta la serie Pentium, evolucionando gradualmente hasta convertirse en el estándar de las PC compatibles con IBM y dominando el sector de computadoras 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 una “seguidora”, 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ó el camino de AMD, e Intel tuvo que abandonar su propuesta y adoptar la extensión de AMD. Desde entonces, los roles de líder y seguidor se invirtieron.

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

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

El PVM que utiliza JAM es una arquitectura de conjunto de instrucciones altamente generalista. Las cadenas que adopten esta arquitectura podrán beneficiarse de la escalabilidad y composabilidad de JAM, y en el futuro, JAM podría permitir la colaboración e integración entre diferentes cadenas.

Ú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 se integren aún más: compartir la misma red de seguridad manteniendo sus propios sistemas de tokens. Creo que, aunque este camino técnico no sea la forma final 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, 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 de ser una tecnología 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 de Polkadot; cualquier cadena que valore su propuesta 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 impulsa la participación de más de 35 equipos independientes en todo el mundo, distribuyendo el conocimiento y el control de forma natural. Este enfoque ayudará a que JAM se convierta en una tecnología central verdaderamente neutral y ampliamente adoptada en el mundo Web3.

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

Pala Labs: En esta ocasión conocimos a muchos desarrolladores apasionados por JAM, muchos de ellos muy jóvenes, quizás estudiantes, y representan una nueva generación en la industria. Si tuvieras que decirles algo—a quienes quizás se parecen a vos hace 20 años, apasionados por crear y soñando con una sociedad y un mundo libres—¿qué les dirías?

Gavin: Entrá lo antes posible y profundizá. Tenés que seguir tu propio juicio de valores. Si creés en el libre albedrío y la soberanía personal, esos principios centrales de la Ilustración, entonces debés actuar por vos mismo—porque nadie puede asumir esa responsabilidad por vos.

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 tiene cierto valor como observación, filosóficamente no es válido. Siempre he sostenido: la verdad existe, y la humanidad tiene la obligación de buscarla. Si una decisión no se basa en los hechos más razonables y confiables disponibles, está destinada a ser errónea.

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

Por supuesto, la IA tiene aspectos positivos en muchos campos, como mejorar la comunicación y enriquecer la creación artística. Yo mismo la uso cuando hago de DJ o compongo música. Pero a nivel socioeconómico, político y geopolítico, los riesgos de la IA no deben subestimarse.

No podemos confiar en la regulación. La regulación suele limitar solo a los individuos respetuosos de la ley en sociedades libres en el uso de la IA, pero no puede detener a organizaciones maliciosas ni evitar que países no libres usen IA para atacar a sociedades libres. Por lo tanto, la regulación por sí sola no es la solución.

Lo realmente necesario es: utilizar una base tecnológica más fuerte y sólida para limitar los posibles efectos destructivos de la inteligencia artificial—ya sea para prevenir abusos internos o para defenderse de amenazas externas maliciosas.

En mi opinión (aunque quizás sea un poco 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 fortalecer la confianza”. Cuando dependemos de la inteligencia artificial, en realidad dependemos de las organizaciones que proveen los modelos y servicios—ya sean las que entrenan los grandes modelos o las 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 determinada; ni siquiera los propios entrenadores entienden realmente el mecanismo interno del modelo. En comparación, que las personas verifiquen los hechos por sí mismas es más confiable. Sin embargo, a medida que la sociedad depende más de la IA y la confía más fácilmente, la gente cae en una “confianza ciega que parece objetiva”.

Si la lógica de la IA es “menos verdad, más confianza”, entonces debemos equilibrarla 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 restricciones innecesarias y brindar apoyo y financiamiento real a quienes construyen la infraestructura de Web3.

Pala Labs: Ahora hay muchos nuevos desarrolladores uniéndose al proyecto JAM, ¿podés anticipar cómo será el desarrollo en cinco o seis años?

Gavin: Predecir el futuro siempre es difícil, pero puedo compartir mi experiencia. A fines de noviembre de 2013, vivía en Londres y tenía un amigo llamado “Johnny Bitcoin”, que también era amigo de Vitalik. Nos juntábamos una vez al mes en un bar a tomar una cerveza y charlar. Esa vez me contó que su amigo Vitalik estaba trabajando en un nuevo proyecto basado en Bitcoin, llamado Ethereum, y buscaba a alguien para desarrollar el código. Medio en broma le dije: “Dale, dejámelo a mí”. Siempre pensé que era bueno programando, y él me propuso: “Si sos tan bueno, ¿por qué no desarrollás Ethereum vos?”. Así me convertí en uno de los desarrolladores de Ethereum. El white paper de Ethereum en ese momento era un documento entre una visión y una especificación formal, no completamente inequívoco, pero con suficiente detalle técnico para ser viable. Durante los siguientes cuatro o cinco meses, todos trabajamos en diferentes versiones compatibles, lo que finalmente llevó al yellow paper de Ethereum—la especificación formal del protocolo. Yo era el desarrollador independiente a cargo de ese protocolo, junto con Vitalik y Jeff, que desarrollaba la versión en Go de Ethereum. Luego fui cofundador de Ethereum, fundé Parity y seguí desarrollando más productos relacionados.

Así empezó mi camino en blockchain—como desarrollador independiente, confiando solo en mi tiempo libre y empezando desde cero a desarrollar un protocolo.

Así que no sé si el equipo de desarrollo de JAM disfrutará tanto como yo 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 inversores potenciales, presentar el proyecto, pensar en casos de uso basados en el protocolo, escribir smart contracts, promocionar el proyecto, asesorar a otros, etc. Además de programar, hay muchas cosas por hacer, pero programar es el punto de partida y el núcleo de todo.

En los últimos 11 años, casi nunca dejé de programar por mucho tiempo. De hecho, esto viene de antes: desde los ocho o nueve años, casi nunca paré—la pausa más larga fue cuando fui a hacer trekking a Centroamérica, y solo fueron tres meses.

Ese fue mi camino, y si estos nuevos desarrolladores tienen suficiente pasión y capacidad, creo que nada puede impedirles entrar en este camino—¡solo que esta vez el objetivo es JAM y no Ethereum!