Discurso de Gavin Wood: Progreso en la entrega de JAM y estrategia a medio y largo plazo para introducir ZK en JAM.

¡Este artículo es la versión en español de la charla de Gavin Wood en el Web3 Summit del mes pasado! Dado que la serie es extensa, la publicaremos en cuatro partes. Esta es la primera parte, que cubre principalmente:

• El estado de entrega de JAM
• El rendimiento de ZK ha mejorado, pero aún está lejos de ser comercializable
• 33 repeticiones vs. prueba matemática: el coste real de dos modos de seguridad
• ¿Cuánto cuesta ejecutar un nodo ZK-JAM? ¡La respuesta es 10 veces más caro de lo que piensas!
• La evolución a corto, medio y largo plazo de ZK en JAM

¡Vamos a ver qué ideas interesantes compartió Gavin!

Entonces, sin más preámbulos, ¿de qué voy a hablar en esta charla?

En primer lugar, quiero compartir mi visión general sobre Polkadot, es decir, mi posición de pensamiento actual, que puede entenderse como una "instantánea del estado actual". Probablemente ya hayan oído hablar de JAM, un proyecto en el que he trabajado durante mucho tiempo y que está estrechamente relacionado con Polkadot. Esperamos que finalmente pueda respaldar la próxima etapa de desarrollo de Polkadot. Además, hablaré sobre tecnologías de cifrado de conocimiento cero (ZK), especialmente su aplicación en la expansión de las capacidades de blockchain.

También abordaré el modelo económico del token DOT. Después, presentaré algunos de los nuevos temas en los que he estado investigando recientemente, con el objetivo de mejorar las capacidades existentes e incluso aportar nuevas posibilidades tanto para Polkadot como para el mundo más amplio de Web3. Esta parte abarca varios aspectos; algunos los trataré en detalle y otros solo los mencionaré. Bien, ahora comenzamos oficialmente.

Estado actual de la entrega de JAM

La versión inicial de JAM es la 0.1 y actualmente se acerca gradualmente a la 1.0. Cuando alcance la versión 1.0, significará que el protocolo JAM está listo para ser utilizado en la actualización de Polkadot. A medida que el protocolo se estabiliza, nuestro enfoque se desplaza hacia la optimización, especialmente en la modelización del gas. A principios de este año, di una charla sobre este tema en la conferencia de Ethereum en Praga (East Prague). La modelización del gas es un tema muy interesante, pero también extremadamente complejo.

Se espera que JAM inicie la auditoría del protocolo este año. No queda mucho trabajo por hacer en la serie de la versión 0.7; pero en la versión 0.8 se introducirá oficialmente la modelización del gas, lo que aumentará significativamente la carga de trabajo. Espero que podamos avanzar a la versión 0.9 este año y comenzar la auditoría en ese momento.

Por supuesto, tener un protocolo central es una cosa, pero poder desarrollar sobre él es otra. Se necesitan SDK, documentación y otras herramientas de desarrollo. Esta parte aún está en una etapa temprana. Aunque ya se puede desarrollar software en JAM, en Parity, principalmente soy yo quien impulsa la construcción y publicación del SDK. Sin embargo, en la práctica, esto requerirá meses o incluso años de inversión y perfeccionamiento continuos. Por supuesto, el desarrollo del SDK no se limitará a Parity. También espero que más equipos se unan para construir sus propios SDK de JAM.

Ya hemos comenzado a establecer estándares para la mensajería entre servicios, que puede considerarse la versión JAM de XCM/XCMP. Al mismo tiempo, CoreVM está convirtiéndose gradualmente en parte del SDK y se perfeccionará y mejorará en los próximos meses. Actualmente, CoreVM ya admite muchas funciones, como salida de audio, salida de vídeo, entrada/salida de datos, procesamiento de transacciones y servicios internos que están por llegar. Por ahora, aún no es compatible con EVM, pero planeamos añadir esta función. Además, el mecanismo que antes llamaba coreplay (coordinación central de tareas) también está previsto para implementarse en los próximos 12–24 meses.

Recientemente, en el grupo de chat de JAM, alguien planteó una pregunta interesante: ¿cómo evitar que yo mismo me convierta en un punto único de fallo para JAM? Actualmente, la evolución del protocolo JAM depende completamente de lo que escribo en el Gray Paper. Esto significa que, si me ocurre algo, todo el proyecto podría quedar paralizado. Evidentemente, esto no es bueno ni para JAM ni para mí.

Por lo tanto, consideramos el contenido del Gray Paper como la especificación técnica de JAM. El Gray Paper más reciente es el JAM más reciente. Si una versión del Gray Paper ya ha sido auditada, el protocolo JAM que define se considera de madurez a nivel de producción, así de simple.

Entonces, ¿cómo evolucionará el Gray Paper en el futuro si ya no depende completamente de mí?

Mi idea es formar un comité editorial. Los miembros iniciales serán aquellos que realmente hayan participado en la redacción del Gray Paper, lo comprendan profundamente y hayan hecho contribuciones sustanciales. Espero que estos miembros mantengan un alto nivel de participación técnica en la implementación de JAM. Yo no me retiraré por completo y seguiré siendo el editor principal, pero quiero reducir mi carga de trabajo y otorgar a otros el poder de proponer, revisar y fusionar cambios.

A medida que JAM supere la versión 1.0, este comité editorial asumirá responsabilidades de mayor nivel:

• No solo gestionar pequeños cambios, sino decidir la dirección y prioridades de desarrollo de JAM;
• Cuando haya opiniones diferentes, el juicio colectivo del comité debe ser la voz más importante.

Planeo nombrar un adjunto que asuma el trabajo cuando yo no esté presente, de vacaciones u otras circunstancias. A largo plazo, los adjuntos también serán responsables de seleccionar, invitar y decidir nuevos miembros del comité editorial, para garantizar que el mecanismo funcione de forma autónoma. Finalmente, espero que este sistema de gobernanza se vuelva gradualmente independiente e incluso integre la participación de algunas organizaciones externas, como Polkadot Fellowship.

De hecho, planeo poner el Gray Paper bajo una licencia abierta, aunque aún no he decidido cuál exactamente, pero probablemente será una licencia copyleft, con algunas cláusulas para prevenir el abuso de patentes.

En cuanto a la gobernanza de Polkadot, tiene plena autoridad para decidir qué protocolo ejecutar. Polkadot es un protocolo soberano, y el mecanismo de gobernanza es la manifestación de esa soberanía. Actualmente, la gobernanza de Polkadot ha dejado claro que quiere adoptar JAM. Eso está bien. Al mismo tiempo, otras redes también pueden elegir JAM, ya que es un protocolo abierto.

En el futuro, si JAM sigue evolucionando, Polkadot puede optar por mantenerse sincronizado y seguir la última versión; si no está satisfecho con la dirección de JAM, puede fijarse en una versión concreta, modificar el protocolo central o incluso bifurcar el Gray Paper. Esto demuestra que JAM es un sistema independiente, y personalmente espero que mantenga una relación simbiótica y mutuamente beneficiosa con Polkadot a largo plazo. Por supuesto, si algún día toman caminos separados y se desarrollan de forma independiente, también es totalmente viable.

Mientras ambas partes estén de acuerdo, espero que la gobernanza de Polkadot participe activamente y apoye el funcionamiento del comité editorial del Gray Paper. Si en el futuro otros protocolos adoptan JAM, también espero que participen de manera similar.

Bien, este es el progreso actual de JAM, o el estado que está a punto de alcanzar. A continuación, quiero hablar sobre las pruebas de conocimiento cero (ZK).

El rendimiento de ZK ha mejorado, pero aún está lejos de ser comercializable

Mucha gente me pregunta: ¿cuándo podrá ZK (pruebas de conocimiento cero) usarse realmente en el ámbito comercial?

Ethereum está muy entusiasmado con ZK; su hoja de ruta gira casi por completo en torno a ZK. En JAM, en realidad solo usamos ZK en algunos mecanismos de consenso especiales durante la construcción de bloques, pero no dependemos de él en general. Aun así, sigue siendo una cuestión que debe considerarse seriamente:

• ¿Cuándo podrá ZK ser una tecnología realmente útil para ampliar la capacidad de cómputo y comercialmente viable?
• ¿Ya ha llegado ese momento?
• Si no, ¿cuánto falta?

Si revisas la información en el ecosistema de Ethereum (por ejemplo, ethprovers.com), verás algunas cifras sorprendentes que afirman que ZK ya es económicamente viable. Pero lo hemos investigado y esos números no son reales. La buena noticia es que, aunque aún no es totalmente viable, la brecha se ha reducido mucho en comparación con hace 18 meses.

Por ejemplo: actualmente, la máquina virtual PVM de JAM (equivalente a la EVM de JAM) es aproximadamente un 34% más lenta que la ejecución nativa al ejecutar código. Es decir, si un programa tarda 34 minutos en ejecutarse en un entorno nativo, en PVM tardaría unos 100 minutos.

Este resultado ya es bastante bueno, estamos satisfechos y aún hay margen de mejora.

Por supuesto, en algunos casos la diferencia es mayor, por ejemplo, del 50% o más. Especialmente en tareas como el hash SHA-1, la ejecución en PVM es más lenta. Esto puede deberse a que en el entorno nativo el compilador puede usar instrucciones SIMD u otras optimizaciones, mientras que PVM aún no puede hacerlo.

Veamos ahora otra cifra clave: este es el coste de generar una prueba de ejecución utilizando el mejor probador que hemos encontrado, Succinct SP1, es decir, el coste adicional en comparación con la ejecución directa en PVM. Ten en cuenta que la comparación es con PVM, no con el entorno nativo. PVM ya es aproximadamente un 34% más lento que el entorno nativo.

Los resultados actuales de las pruebas son los siguientes: utilizamos la última versión del software y suponemos que solo usamos una GPU (porque el repositorio de código abierto solo admite una GPU). Si fuera una versión comercial cerrada, podría escalarse a un clúster de GPU, pero en un entorno de código abierto, solo es posible así. El contenido de la prueba es el mismo que antes, sigue siendo SHA-1, para garantizar la coherencia de la comparación.

¿Dónde está el cambio?

Hace 18 meses, hicimos un experimento similar y los datos eran mucho mayores, alrededor de 60 millones a 64 millones. Ahora el coste ha bajado notablemente.

Las razones son probablemente dos:

• Por un lado, el alquiler de GPU se ha abaratado;
• Por otro, el software ha mejorado enormemente, posiblemente aumentando su eficiencia en un orden de magnitud o más.

Hay que añadir que hace 18 meses no usábamos SP1, sino RISC-0. Pero en cualquier caso, los resultados muestran que la tecnología de vanguardia está avanzando rápidamente y el progreso es considerable.

Hasta julio de 2025, generar una prueba de una traza de ejecución con SP1 (el probador de Succinct) es 306,451 veces más caro que ejecutar el mismo cálculo de forma segura directamente en PVM. En los últimos 18 meses, el coste de la prueba ha bajado unas 200 veces, pero la cifra sigue siendo enorme. La tecnología ZK avanza rápidamente, pero sigue siendo mucho más cara que la ejecución directa.

Ahora hablemos de la medición del gas.

Que el código se ejecute rápido es una cosa, pero lo clave es que puedas confiar en él. ¿Qué pasa si alguien escribe código intencionadamente para ralentizar el sistema? En los mecanismos de consenso, si el sistema debe llegar a un acuerdo en un tiempo determinado y ese código está diseñado maliciosamente para ser lento, todo el sistema podría quedar bloqueado o incluso colapsar.

En Polkadot, este problema no es tan grave porque tenemos subastas de slots de parachain. Es decir, quienes pueden enviar código al sistema son identificables, ya que han pagado por el slot, por lo que es poco probable que realicen acciones perjudiciales que no les beneficien.

Pero si ampliamos el escenario a un entorno más abierto y general, el problema se agrava.

¿Cuál es la solución?

Debemos poder estimar de antemano el tiempo máximo de ejecución de un código, es decir, cuánto tardará en el peor de los casos. Y asegurarnos de que, pase lo que pase, nunca será más lento que ese peor caso. De lo contrario, si alguien puede hacer que el código sea 10 veces más lento de lo que estimamos, sería un gran problema.

¿Hasta dónde hemos llegado con la estimación del peor caso?

Tomando SHA-1 como ejemplo, actualmente el resultado es: para garantizar la seguridad, debemos suponer que puede ser hasta 4,5 veces más lento que en condiciones normales. Es decir, si un código normalmente tarda 1 segundo, en la estimación del peor caso debemos considerarlo como 4,5 segundos. Solo así podemos asegurarnos de que ningún atacante pueda ralentizarlo aún más.

Este método de "calcular varias veces por seguridad" es esencial para garantizar la seguridad en mecanismos de consenso con restricciones de tiempo.

En el futuro, este multiplicador debería poder reducirse, es decir, la estimación será más precisa y eficiente. Ahora, 4,5 veces es el mejor resultado que hemos obtenido tras una o dos semanas de trabajo. Siendo optimistas, quizás en el futuro pueda bajar a 3 veces, pero no mucho más.

33 repeticiones vs. prueba matemática: el coste real de dos modos de seguridad

En Polkadot y JAM, utilizamos un protocolo llamado elves para garantizar la seguridad del cálculo. Su función es permitirnos confirmar que un cálculo se ha ejecutado correctamente.

En esencia, elves y las pruebas de conocimiento cero (ZK) son similares:

• ZK utiliza pruebas matemáticas, proporcionando una "prueba irrefutable";
• Mientras que elves es más como un juego de criptoeconomía: los participantes usan firmas y reglas para demostrar que el resultado es correcto, suponiendo que "los malos no superan un tercio".

Al ejecutar elves, el cálculo se repite. Los participantes deciden aleatoriamente si realizarán esta "repetición".

El resultado es: en este modo, el trabajo se repite unas 33 veces de media. Así que el coste es aproximadamente 33 veces el de la ejecución normal.

De este modo, podemos calcular la diferencia de costes entre ZK y elves. La respuesta es: ZK es unas 4000 veces más caro que elves. En otras palabras, usar pruebas de conocimiento cero para verificar la corrección es mucho más caro que usar el sistema criptoeconómico de elves. Puedes imaginarlo como una comparación de costes entre diferentes soluciones de Rollup.

Nota de PolkaWorld: Puedes imaginar que elves es como si 33 compañeros de clase copiaran los deberes y luego compararan las respuestas para confirmar que no hay errores; ZK sería como pedirle a un doctor en matemáticas que te escriba una "prueba absolutamente correcta", pero el doctor podría tardar días en escribirla.

Una diferencia de 4000 veces es enorme; para que ZK sea rentable en la práctica, su coste debe reducirse drásticamente. Por supuesto, también podemos seguir optimizando elves para hacerlo más eficiente.

Sin embargo, el problema del coste no es solo el hardware. Hay varios puntos clave:

• Coste de operación (sysadmin): no importa qué hardware uses, el salario del personal de operación es similar. Y en muchos casos, el coste de operación es incluso mayor que el del hardware.
• Coste de staking: para garantizar que los malos no superen un tercio, el sistema necesita un mecanismo de filtrado. En Polkadot, esto se logra mediante "staking + mecanismo de penalización". Es decir, los participantes deben depositar parte de sus fondos (capital de riesgo), lo que permite distinguir entre "buenos validadores" y posibles "malos validadores".

El problema es que el staking en sí es caro, lo que supone un coste adicional (lo explicaré más adelante).

En comparación, ZK no tiene la carga del staking. La lógica de ZK es simple: o la prueba es correcta o es incorrecta, se ve de inmediato.

Pero el problema es que generar pruebas ZK es demasiado lento. Si usas una sola GPU, puede tardar horas; mientras que ejecutar el mismo cálculo directamente en PVM (o en una CPU normal) solo lleva milisegundos o segundos. La diferencia es enorme.

Sin embargo, ya se ha demostrado que se puede reducir la latencia mediante la paralelización en clústeres de GPU. Si tienes suficientes GPU conectadas, puedes reducir la latencia. Pero el problema es:

El coeficiente de eficiencia de la paralelización no es transparente: es decir, no está claro cuánto aumentará el coste. Quienes han hecho experimentos no han publicado estos datos, y probablemente tampoco quieran hacerlo. Así que tenemos que diseñar experimentos por nuestra cuenta, desarrollar el código nosotros mismos o buscar investigaciones relacionadas que aún no se hayan descubierto.

Además, hay cuestiones de verificación y liquidación.

Por ejemplo, en Ethereum L1, el coste de la verificación es incluso mayor que el de generar la prueba. Hemos estimado que generar una prueba cuesta entre 1 y 1,20 dólares, pero verificarla en Ethereum L1 cuesta 1,25 dólares. Por supuesto, si tienes tu propia cadena, el coste de verificación puede ser mucho menor, pero aún necesitas:

• Verificación
• Liquidación
• Finalidad
• Almacenamiento

Estos pasos no pueden eliminarse con ZK. Así que, al final, aún necesitas asegurarte de que los participantes maliciosos no superen un tercio, es decir, volver al mecanismo de staking, como en Ethereum L1, Polkadot y la mayoría de las cadenas.

¿Cuánto cuesta ejecutar un nodo ZK-JAM? ¡La respuesta es 10 veces más caro de lo que piensas!

Bien, ahora pensemos desde otra perspectiva: supongamos que hay un nodo garante (guarantor node) ZK-JAM, ¿cuál sería su coste de operación?

Primero, una breve explicación: en JAM, hay un tipo de rol llamado garante (guarantors), que actúan como "porteros" del sistema. Todas las transacciones o tareas se les entregan primero, ellos realizan los cálculos y empaquetan los resultados, y luego los entregan a otros validadores. Los validadores pueden revisar sus resultados, pero también pueden no hacerlo.

Ahora supongamos el siguiente escenario:

• Eliminamos la revisión (ya no se exige que otros revisen el trabajo del garante);
• Reducimos los requisitos de staking (porque no dependemos completamente de la confianza en el garante);
• Pero obligamos al garante a ejecutar un clúster de GPU y generar pruebas ZK.

Entonces, ¿cuál es el coste de esto?

Según las estimaciones: generar una prueba ZK cuesta unos 1,18 dólares (tomando SHA-1 como ejemplo, equivalente a 6 segundos de cálculo y 12 MB de I/O). Esto equivale aproximadamente al trabajo que puede realizar un core de JAM en un slot. JAM tiene un total de 341 cores, y este es el coste por core.

Por supuesto, esto es solo una estimación aproximada. El coste de diferentes tareas puede variar: si es otro cálculo, puede ser más caro o más barato que 1,18 dólares, pero está en ese rango.

Si lo anualizamos: el coste anual de un core es de unos 9.5 millones de dólares.

Aquí suponemos que la paralelización del clúster de GPU añade un 50% de sobrecoste, principalmente para reducir la latencia. Sin embargo, ese 50% es solo una suposición; en la realidad podría ser solo un 5% o hasta un 200%. Lo que está claro es que habrá un sobrecoste adicional, y podría no ser pequeño.

¿Y cómo se compara esto con el mecanismo de staking actual de Polkadot?

En el mecanismo actual, para proporcionar una seguridad equivalente a elves (o aproximadamente el 80% de la seguridad de elves), el coste por core es de menos de 1 millón de dólares.

El 80% se debe a que, incluso si cambiamos a ZK, aún se necesita algo de staking para garantizar la seguridad de otras partes clave, como:

• El funcionamiento normal de la cadena principal
• Liquidación
• Finalidad
• Almacenamiento

Todo esto es importante, pero la corrección del cálculo es lo más esencial, y representa aproximadamente el 80% del coste de staking.

Supongamos que ejecutamos 341 cores y mantenemos el modelo económico de staking actual de Polkadot, el coste sería ese. Si el número de cores disminuye, el coste por core aumentaría, ya que el "pool" de staking total no cambia, pero hay menos participantes para repartirlo.

Así que, en resumen: actualmente, el coste de ZK es aproximadamente 10 veces el de elves.

Por supuesto, si podemos reducir el coste de la seguridad (creo que es posible), por ejemplo, de 9.16 millones de dólares a 2.7 millones, o incluso, combinando nuevos mecanismos en desarrollo, a 1.44 millones. En ese momento, la diferencia de costes entre ZK y elves se reduciría. Pero hay que tener en cuenta que 1.44 millones ya es una estimación optimista.

Entonces, ¿cuál es la conclusión final?

El coste de ZK está disminuyendo gradualmente, pero incluso así, sigue siendo entre 10 y 100 veces más caro que elves. Además, hay algunos costes adicionales e inciertos, como liquidación, almacenamiento y finalidad, que JAM ya soporta de forma nativa, o que elves puede aprovechar, pero ZK no puede.

Además, elves tiene una ventaja: puede escalar de forma superlineal. Es decir, se pueden conectar varias redes JAM y compartir el mismo conjunto de validadores, lo que aumenta la eficiencia general. ZK no tiene esta capacidad, solo puede escalar linealmente: si quieres generar pruebas para otro core, tienes que pagar el mismo coste de nuevo, no se puede combinar ni reutilizar.

La evolución a corto, medio y largo plazo de ZK en JAM

Así que, desde una perspectiva estratégica, el camino a seguir depende de la situación concreta.

Creo que una estrategia razonable es:

• Reducir el coste de las pruebas: aún debe bajar 1–2 órdenes de magnitud. Según la experiencia, esto puede llevar de 18 meses a 5 años.
• Necesitamos herramientas de código abierto: que permitan generar pruebas de forma eficiente y distribuida en clústeres de GPU. Actualmente no existen herramientas maduras, o al menos no las más rápidas y mejores. Sin ellas, nuestras estimaciones de costes actuales no se sostienen.
• El precio de los cores: si el precio de mercado de los cores ya está en un rango que hace razonable el modo elves, entonces ZK pierde su ventaja.
• Elección de seguridad: el mercado debe poder distinguir entre dos tipos de seguridad: ZK ofrece "seguridad perfecta", mientras que elves ofrece "seguridad bajo restricciones económicas". La cuestión es si el mercado realmente se preocupa por cuál usar, lo que aún no está claro.
• Eliminar la dependencia del staking elevado: debemos poder realizar otras tareas de JAM/elves, como almacenamiento, liquidación y finalidad, sin depender de un staking masivo. Si seguimos dependiendo del staking, no hay ventaja y solo hará que la solución ZK sea más cara.

Basándome en esto, mi estrategia ZK recomendada es:

• Comenzar por lo más fácil: por ejemplo, desarrollar un marco de servicios ZK-JAM, pero seguir utilizando el mecanismo criptoeconómico existente de JAM (elves) para la seguridad.
• Aprovechar las ventajas de JAM: un core de JAM tiene una gran capacidad de cálculo (CPU) y un buen I/O (12 MB), y la eficiencia de ejecución de PVM es alta. Esto significa que podemos realizar muchas verificaciones ZK directamente en el core de JAM, sin recurrir a procesos de prueba externos costosos y complejos.
• Optimizar la fase de pruebas: el proceso tradicional de pruebas ZK suele tener varias etapas y, al final, una "compresión de pruebas" para reducir el tamaño y facilitar la verificación. Pero en el core de JAM, gracias a su potencia, puede que no sea necesaria esta etapa, ahorrando costes.
• Priorizar las pruebas de almacenamiento: porque el core de JAM tiene mucha capacidad de cálculo, pero el I/O es relativamente limitado, y las pruebas de almacenamiento pueden compensar esta debilidad, permitiendo procesar rápidamente grandes volúmenes de transacciones.
• Otras tareas sencillas: como la verificación de firmas, que ya es fácil y no es un cuello de botella.

En otras palabras, el verdadero reto es garantizar que los datos de los que dependen las transacciones sean correctos. Ese es el problema clave que debemos resolver.

A medio plazo, lo más razonable es:

Ya tenemos una nueva visión para Kusama: construir una red compatible con ZK. Así que, aprovechando este presupuesto y colaborando con otros equipos, es muy adecuado centrarse en herramientas de generación de pruebas eficientes y distribuidas.

• Si ahora no hay ningún equipo trabajando en esto, lanzar un nuevo proyecto directamente;
• Si ya hay equipos trabajando en ello, o dispuestos a hacerlo, colaborar y apoyarlos para que lo hagan bien.

Especialmente importante es centrarse en las pruebas de ejecución de PVM, ya que esto es clave para que ZK-JAM sea compatible con JAM normal en el futuro, y la generación distribuida de pruebas es imprescindible.

El objetivo es mantener el sistema modular y abierto, para poder seguir el ritmo de la investigación más avanzada. Solo si seguimos el progreso tecnológico podremos reducir el coste de las pruebas varios órdenes de magnitud y hacerlas realmente viables comercialmente.

A largo plazo, si realmente queremos que ZK sea la solución principal, debemos encontrar una forma de sustituir el staking. Porque mientras exista el staking, el coste será muy alto.

Entonces, ¿cómo lograr un JAM completamente basado en ZK?

Primero, esto solo tiene sentido si el coste de ZK baja lo suficiente y se confirma que la utilización de los cores no es económicamente viable en el modelo actual. Ahora aún no está claro, así que es una hipótesis condicional.

Una vez que se cumplan las condiciones, podemos hacer que JAM evolucione hacia un modelo de seguridad multimodal:

• Por un lado, ofrecer seguridad barata pero limitada (similar a elves, bajo coste);
• Por otro, ofrecer seguridad perfecta pero más cara (basada en ZK, con coste lineal creciente).

La cuestión clave es: debemos encontrar una forma de lograr la finalidad (finality) y el almacenamiento (storage) sin depender del staking.

Una posible dirección es la prueba de personalidad (Proof of Personhood). Si podemos integrar este mecanismo en el protocolo central, la eficiencia y la utilización del capital mejorarían enormemente.

Sin embargo, para lograrlo, se necesita un mecanismo anti-sybil muy potente. La mayoría de las soluciones actuales no son lo suficientemente fuertes: o dependen de una autoridad central, o una organización recopila datos de los usuarios para decidir quién es real y quién no. Este enfoque es claramente centralizado, y solo unas pocas soluciones se acercan a ser viables.