Discurso de Gavin Wood: estado de entrega de JAM y estrategia a mediano y largo plazo para incorporar ZK en JAM.

¡Esta es la versión en chino de la charla que Gavin Wood dio el mes pasado en el Web3 Summit! Dado que la serie es extensa, la publicaremos en cuatro partes. Esta es la primera parte, que cubre principalmente:

• 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 verdadero costo de dos modos de seguridad
• ¿Cuánto cuesta ejecutar un nodo ZK-JAM? ¡La respuesta es 10 veces más de lo que pensás!
• La evolución de ZK en JAM a corto, mediano y largo plazo

¡Veamos qué ideas interesantes compartió Gavin!

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

Primero, quiero compartir mi visión general sobre Polkadot, es decir, mi posición actual de pensamiento, que se puede entender como una "instantánea del estado actual". Probablemente ya hayan escuchado hablar de JAM: es un proyecto en el que he estado trabajando durante mucho tiempo y está estrechamente relacionado con Polkadot. Esperamos que eventualmente pueda respaldar la próxima etapa de desarrollo de Polkadot. Además, hablaré sobre tecnologías de cifrado de conocimiento cero (ZK), especialmente sobre su aplicación para ampliar las capacidades de blockchain.

También voy a analizar el modelo económico del token DOT. Luego, presentaré algunos de los nuevos temas en los que he estado investigando últimamente, exploraciones que buscan mejorar las capacidades actuales e incluso aportar nuevas posibilidades tanto para Polkadot como para el mundo más amplio de Web3. Esta parte abarca varios aspectos: algunos los detallaré más, otros solo los mencionaré. Bien, ahora sí, empecemos formalmente.

Estado actual de entrega de JAM

La versión inicial de JAM fue la 0.1, y actualmente estamos avanzando hacia la 1.0. Cuando lleguemos a la 1.0, significará que el protocolo JAM estará listo para ser adoptado por Polkadot en una actualización. A medida que el protocolo se estabiliza, nuestro enfoque se desplaza hacia la optimización, especialmente en el modelado de gas. A principios de este año, di una charla sobre esto en la conferencia de Ethereum en Praga (East Prague). El modelado de gas es un tema muy interesante, pero también extremadamente complejo.

Se espera que JAM inicie la auditoría del protocolo este año. En la serie de versiones 0.7 no queda mucho trabajo por hacer; pero en la 0.8 se introducirá formalmente el modelado de 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 sobre 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 trabajo continuo y perfeccionamiento. Por supuesto, el desarrollo del SDK no se limitará a Parity. 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 se puede considerar como la versión JAM de XCM/XCMP. Al mismo tiempo, CoreVM está convirtiéndose gradualmente en parte del SDK y se mejorará y fortalecerá en los próximos meses. CoreVM ya admite muchas funciones, como salida de audio, salida de video, entrada/salida de datos, procesamiento de transacciones y servicios internos que llegarán pronto. Actualmente no es compatible con EVM, pero planeamos agregar esta función. Además, el mecanismo que antes llamaba coreplay (coordinación central), también planeamos implementarlo en los próximos 12 a 24 meses.

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

Por eso, 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 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 quienes realmente hayan participado en la redacción del Gray Paper, lo entiendan 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é completamente, seguiré siendo el editor principal, pero quiero reducir mi carga de trabajo y dar a otros la autoridad para 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 manejar 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/a adjunto/a que se haga cargo cuando yo no esté, esté de vacaciones u ocurra otra situación. 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 incorpore la participación de 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 su 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, porque JAM es un protocolo abierto.

Si JAM sigue evolucionando en el futuro, 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 específica, 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 de beneficio mutuo a largo plazo con Polkadot. 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. Y si otros protocolos adoptan JAM en el futuro, también espero que participen de manera similar.

Bien, este es el progreso actual de JAM, o el estado al que está por llegar. 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 mundo comercial?

Ethereum está muy entusiasmado con ZK, y casi toda su hoja de ruta gira en torno a ZK. En JAM, en realidad solo usamos ZK en algunos mecanismos de consenso especiales durante la construcción de bloques, pero JAM en general no depende de ZK. Aun así, sigue siendo una cuestión que debemos considerar seriamente:

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

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

Por ejemplo: actualmente, la máquina virtual PVM de JAM (el equivalente JAM de EVM) ejecuta código un 34% más lento que la ejecución nativa. En otras palabras, si un programa tarda 34 minutos en ejecutarse en un entorno nativo, en PVM tardará 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.

Ahora veamos otro número clave: este es el costo de generar una prueba de ejecución usando el mejor probador que tenemos, Succinct SP1, es decir, el costo adicional sobre ejecutar directamente en PVM. Ojo, la comparación es con PVM, no con el entorno nativo. PVM ya es un 34% más lento que el nativo.

Los resultados actuales de las pruebas son así: usamos la última versión del software y asumimos el uso de una sola GPU (porque el repositorio público solo admite una GPU). Si fuera una versión comercial cerrada, podría escalarse a un clúster de GPU, pero en el entorno open source, solo se puede así. El contenido de la prueba es el mismo que antes, sigue siendo SHA-1 hash, para garantizar la comparación.

¿Dónde está el cambio?

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

Las razones son dos:

• Por un lado, el alquiler de GPU se ha abaratado;
• Por otro, el software ha mejorado mucho, quizá hasta un orden de magnitud o más.

Hay que aclarar que hace 18 meses usamos el probador RISC-0, no SP1. 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 de forma segura el mismo cálculo directamente en PVM. En los últimos 18 meses, el costo de la prueba ha bajado unas 200 veces, pero sigue siendo un número muy grande. La tecnología ZK avanza rápido, pero sigue siendo mucho más cara que la ejecución directa.

Ahora hablemos de la medición de gas.

Que el código se ejecute rápido es una cosa, pero lo clave es poder confiar en él. ¿Qué pasa si alguien escribe código a propósito 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 atascado 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, han pagado dinero real para obtener el slot, así que es poco probable que hagan daño a propósito.

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

¿Cuál es la solución?

Hay que 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 asegurarse de que, pase lo que pase, nunca será más lento que ese peor caso. Si alguien logra que el código sea 10 veces más lento de lo que estimamos, sería un gran problema.

¿Qué tan buena es nuestra estimación del peor caso ahora?

Tomando SHA-1 hash como ejemplo, el resultado actual es: para garantizar la seguridad, debemos suponer que puede ser hasta 4,5 veces más lento que lo normal. Es decir, si un código normalmente tarda 1 segundo, en la estimación del peor caso lo tratamos como si tardara 4,5 segundos. Así nos aseguramos de que ni el atacante más malicioso pueda ralentizarlo más.

Este método de "multiplicar por varios para estar seguros" es lo que necesitamos para garantizar la seguridad bajo mecanismos de consenso con restricciones de tiempo.

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

33 repeticiones vs prueba matemática: el verdadero costo de dos modos de seguridad

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

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

• ZK usa una prueba matemática, te da una "prueba irrefutable";
• Elves es más como un juego de criptoeconomía: los participantes usan firmas y reglas para probar que el resultado es correcto, suponiendo que "los malos no superan un tercio".

Al ejecutar elves, el cálculo se repite varias veces. Los participantes deciden al azar si hacen esa "repetición".

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

De este modo, podemos calcular la diferencia de costo entre ZK y elves. La respuesta es: ZK es unas 4000 veces más caro que elves. Es decir, usar pruebas de conocimiento cero para verificar la corrección cuesta mucho más que usar el sistema criptoeconómico de elves. Podés imaginarlo como una comparación de costos entre diferentes soluciones de Rollup.

Nota de PolkaWorld: Podés imaginar que elves es como si 33 compañeros de clase copiaran la tarea y luego compararan las respuestas para asegurarse de que no hay errores; ZK sería como contratar a un doctor en matemáticas para que te escriba una "prueba absolutamente correcta", pero el doctor podría tardar días en hacerlo.

Una diferencia de 4000 veces es enorme. Para que ZK sea rentable en la práctica, su costo debe bajar mucho. Por supuesto, también podemos seguir optimizando elves para hacerlo más eficiente.

Sin embargo, el problema del costo no es solo el hardware. Hay otros puntos clave:

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

El problema es que el staking en sí es caro, es un costo 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 muy lento. Si usás una sola GPU, puede llevar horas; mientras que ejecutar el mismo cálculo en PVM (o 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 hay suficientes GPU conectadas, se puede bajar la latencia. Pero el problema es:

El coeficiente de eficiencia de la paralelización no es transparente: es decir, no se sabe cuánto aumentará el costo. Quienes han hecho experimentos no han publicado esos datos, quizá tampoco quieran. Así que o diseñamos nuestros propios experimentos para medirlo, o desarrollamos el código nosotros mismos, o buscamos investigaciones relevantes que aún no se hayan descubierto.

Además, está el tema de la verificación y la liquidación.

Por ejemplo, verificar en Ethereum L1 cuesta incluso más que generar la prueba. Estimamos 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 tenés tu propia cadena, el costo de verificación puede ser mucho menor, pero igual necesitás:

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

Estos pasos no los elimina ZK. Así que, al final, igual tenés que 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 de lo que pensás!

Bien, ahora pensemos desde otro ángulo: supongamos que hay un nodo garante ZK-JAM, ¿cuánto cuesta operarlo?

Primero, una breve explicación: en JAM, hay un rol llamado garante (guarantor), que actúa como "portero" del sistema. Todas las transacciones o tareas pasan primero por ellos, quienes procesan y empaquetan los resultados, y luego los entregan a otros validadores. Los validadores pueden revisar o no su trabajo.

Ahora supongamos este escenario:

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

¿Cuál es el costo de esto?

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

Por supuesto, esto es solo una estimación aproximada. El costo varía según la tarea: para otros cálculos puede ser más caro o más barato, pero está en ese rango.

Si lo anualizamos: el costo anual de un core es de unos 9,5 millones de dólares.

Aquí asumimos que la paralelización del clúster de GPU añade un 50% de costo extra, principalmente para reducir la latencia. Pero ese 50% es solo una suposición, en la realidad podría ser solo un 5% o hasta un 200%. Lo seguro es que habrá un costo extra, y puede no ser pequeño.

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

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

Ese 80% se debe a que, incluso usando 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 central, y representa alrededor del 80% del costo de staking.

Supongamos que operamos 341 cores y mantenemos el modelo económico de staking actual de Polkadot, ese sería el costo. Si el número de cores baja, el costo por core sube, porque el "pozo" de staking es el mismo, pero se reparte entre menos participantes.

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

Por supuesto, si logramos reducir el costo de 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, bajarlo a 1,44 millones. En ese caso, la diferencia de costo entre ZK y elves se reduciría. Pero ojo, 1,44 millones ya es una estimación optimista.

¿Cuál es la conclusión final?

El costo de ZK está bajando, pero aun así, sigue siendo entre 10 y 100 veces más caro que elves. Además, hay costos adicionales inciertos, como liquidación, almacenamiento y finalidad: JAM ya los soporta de forma nativa, o elves puede aprovecharlos, pero ZK no.

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 mejora la eficiencia general. ZK no puede hacer esto, solo escala linealmente: si querés generar pruebas para otro core, tenés que pagar el mismo costo de nuevo, no se puede fusionar ni reutilizar.

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

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 costo de las pruebas: aún debe bajar 1 o 2 órdenes de magnitud. Según la experiencia, esto puede llevar de 18 meses a 5 años.
• Necesitamos herramientas open source: que permitan generar pruebas de forma eficiente y distribuida en clústeres de GPU. Actualmente no hay herramientas maduras, o no son las mejores. Sin ellas, nuestras estimaciones de costos no se sostienen.
• El precio de los cores: si el precio de mercado de los cores ya está en un rango donde el modo elves es razonable, entonces ZK pierde su ventaja.
• Elección de seguridad: el mercado debe poder distinguir entre dos tipos de seguridad: ZK ofrece "seguridad perfecta", elves ofrece "seguridad bajo restricciones económicas". La cuestión es si al mercado realmente le importa cuál usar, eso aún no está claro.
• Eliminar la dependencia del staking elevado: debemos poder realizar las otras tareas de JAM/elves (almacenamiento, liquidación, finalidad) sin depender de un staking masivo. Si seguimos dependiendo de mucho staking, no hay ventaja, solo hace que la solución ZK sea más cara.

Basado en esto, mi estrategia recomendada para ZK es:

• Empezar por lo fácil: por ejemplo, desarrollar un marco de servicios ZK-JAM, pero seguir usando el mecanismo criptoeconómico de JAM (elves) para la seguridad.
• Aprovechar las ventajas de JAM: un core de JAM tiene mucha capacidad de cómputo (CPU) y buen I/O (12MB), y la eficiencia de ejecución de PVM es alta. Esto significa que podemos hacer mucha verificación ZK directamente en el core de JAM, sin recurrir a procesos externos caros y complejos.
• Optimizar la etapa de pruebas: el proceso tradicional de pruebas ZK suele tener varias etapas, y al final una "compresión de pruebas" para hacerlas más pequeñas y fáciles de verificar. Pero en el core de JAM, como hay suficiente potencia, quizá ni haga falta esa etapa, lo que ahorra costos.
• Priorizar las pruebas de almacenamiento: porque el core de JAM tiene mucha capacidad de cómputo pero menos I/O, y las pruebas de almacenamiento pueden compensar esa debilidad, permitiendo procesar muchas transacciones rápidamente.
• Otras tareas simples: como la verificación de firmas, que ya es fácil y no es un cuello de botella.

En otras palabras, el verdadero desafío es garantizar que los datos de los que dependen las transacciones sean correctos. Ese es el problema clave a resolver.

A mediano plazo, lo más razonable es:

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

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

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

El objetivo es mantener el sistema modular y abierto, para estar al día con la investigación más avanzada. Solo así podremos reducir el costo de las pruebas varios órdenes de magnitud y hacerlas realmente viables comercialmente.

A largo plazo, si realmente queremos que ZK sea la solución central, debemos encontrar una forma de reemplazar el staking. Porque mientras el staking siga, el costo será muy alto.

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

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

Cuando se cumplan las condiciones, JAM podrá evolucionar a un modelo de seguridad multimodal:

• Por un lado, ofrecer seguridad barata pero limitada (como elves, bajo costo);
• Por otro, ofrecer seguridad perfecta pero cara (basada en ZK, con costo lineal).

El problema clave es: debemos encontrar una forma de lograr finalidad (finality) y almacenamiento (storage) sin depender del staking.

Una posible dirección es la prueba de personalidad (Proof of Personhood). Si se puede integrar este mecanismo en el protocolo central, se puede mejorar mucho la eficiencia y el uso del capital.

Pero para lograr esto, se necesita un mecanismo anti-sybil muy fuerte. 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. Esto claramente es un problema de centralización, y solo unas pocas soluciones se acercan a ser viables.