El fundador de Ethereum, Vitalik Buterin (dios V), publicó un blog "¿Cuáles son los casos de uso no financiero de blockchain?" ". V God dijo que siempre ha apoyado firmemente la tendencia de usar blockchain para aplicaciones no financieras, y que las personas deben mantenerse alejadas tanto de la "omnipotencia de blockchain" como del "minimalismo de blockchain". Dijo que ve valor en blockchain en muchos casos, a veces para objetivos realmente importantes como la confianza y la censura, a veces solo por conveniencia.
V God también enumeró 8 escenarios de aplicaciones no financieras que pueden usar blockchain en el artículo: cambio y recuperación de clave de cuenta de usuario, modificación y revocación de certificación, reputación negativa, prueba de escasez, conocimiento público y otras aplicaciones de blockchain Interoperabilidad de programas, código abierto métricas, almacenamiento de datos. Las dos aplicaciones no financieras en las que dice que tiene más confianza hasta ahora son: la interoperabilidad con otras aplicaciones de blockchain y la gestión de cuentas.
La siguiente es una publicación de blog larga de V God, compilada por Odaily Planet Daily:
Recientemente, ha habido un mayor interés en las aplicaciones no financieras de blockchain, a las que siempre he apoyado mucho. El mes pasado, fui coautor de un artículo con Puja Ohlhaver y Glen Weyl que describe una visión más detallada de lo que podrían hacer los tokens vinculados al alma (SBT) en un ecosistema más rico donde estas monedas pueden describir varias relaciones. Esto ha provocado cierta discusión sobre si tiene sentido usar blockchain en un ecosistema de identidad descentralizado.
A partir de esto, también hacemos la pregunta: ¿cuál es el punto de usar blockchain en aplicaciones no financieras? ¿Deberíamos dirigirnos hacia un mundo en el que, incluso con aplicaciones de chat descentralizadas, cada mensaje se procese a través de una transacción en cadena que contenga información cifrada? ¿O la cadena de bloques solo es adecuada para la industria financiera (por ejemplo, porque los efectos de red significan que las monedas tienen una necesidad única de una "visión global"), mientras que todas las demás aplicaciones se realizan mejor utilizando sistemas centralizados o más localizados?
Mi propio punto de vista es como la votación de blockchain (Odaily Note: V God insinúa que es más neutral y objetivo), ni "blockchain en todas partes" ni "minimalismo de blockchain" (minimalismo de blockchain) maximalista). Veo el valor de blockchain en muchas situaciones, a veces para objetivos realmente importantes como la confianza y la resistencia a la censura, pero a veces simplemente por conveniencia. Esta publicación intentará describir blockchain, situaciones en las que puede o no ser útil de alguna manera. Tenga en cuenta que este artículo no es una lista completa y muchas cosas se omiten intencionalmente, nuestro objetivo es aclarar algunas categorías comunes.
1. Cambio y recuperación de clave de cuenta de usuario
Uno de los mayores desafíos en los sistemas de cuentas criptográficas es el problema del cambio de clave, que puede ocurrir de varias maneras:
「1」Le preocupa que su clave actual pueda perderse o ser robada y desea cambiar a una clave diferente;
"2" desea cambiar a un algoritmo de cifrado diferente (por ejemplo, porque le preocupa que pronto aparezcan computadoras cuánticas y desea actualizar a un algoritmo poscuántico);
"3" Su clave se perdió y desea recuperar el acceso a su cuenta;
"4" Te han robado la clave y quieres recuperar el acceso exclusivo a la cuenta (lo que no quieres que haga el ladrón).
Implementar los dos primeros puntos es relativamente simple porque se pueden hacer de forma completamente autónoma: usted controla la tecla X y desea cambiar a la tecla Y, por lo que publica un mensaje firmado por X que dice "Verifíqueme con Y de ahora en adelante". ." ', todos aceptan eso.
Tenga en cuenta, sin embargo, que incluso para estos escenarios de cambio de clave relativamente simples, no puede simplemente usar criptografía. Considere la siguiente situación:
Le preocupa que le roben la clave A, por lo que firma un mensaje con A que dice "Uso B ahora";
Un año más tarde, los piratas roban la clave A, pero pueden usar A para firmar mensajes que digan "Uso C ahora", donde C es su propia clave;
Para los que llegan tarde y reciben dos mensajes al mismo tiempo, solo ven que A ya no se usa, pero no saben cuál de los dos mensajes "reemplazar A con B" o "reemplazar A con C" tiene una clase de prioridad más alta .
Esto es muy similar al "problema de doble gasto" que se encuentra al diseñar una moneda descentralizada, excepto que el objetivo esta vez no es evitar que el propietario anterior del token lo envíe nuevamente, sino evitar que la clave anterior que controla la cuenta pudiendo cambiar la clave. Al igual que crear una moneda descentralizada, administrar cuentas de forma descentralizada requiere algo como una cadena de bloques. La cadena de bloques puede marcar con fecha y hora los mensajes de cambio de clave para determinar cuál fue primero, B o C.
Resolver "3" y "4" es más difícil, mi solución preferida es la billetera de recuperación social y de múltiples firmas. En caso de pérdida o robo, tus amigos, familiares y otros contactos pueden transferir el control de tu cuenta a una nueva clave. Su participación también puede ser necesaria para operaciones críticas como la transferencia de grandes cantidades de fondos o la firma de contratos importantes.
La "recuperación social" mediante el uso compartido de secretos es teóricamente posible, pero difícil en la práctica: si ya no confía en algunos de sus contactos, o si quieren cambiar sus claves, no puede revocar los derechos de acceso en caso de Así que volvemos al problema de necesitar algún tipo de registro en cadena.
Hay una idea sutil pero importante en el artículo de DeSoc: para mantener la intransferibilidad, es posible que sea necesario aplicar los perfiles socialmente restaurados. Dicho esto, incluso si vende su cuenta, siempre puede usar la recuperación social para recuperar la propiedad de la cuenta. Esto abordaría problemas como los conductores con mal crédito que compran cuentas verificadas en plataformas de viajes compartidos. Esta es una idea especulativa y no tiene que realizarse completamente para obtener los otros beneficios de un sistema de identidad y reputación basado en blockchain.
Tenga en cuenta que este es solo un caso de uso limitado de blockchain hasta el momento: está perfectamente bien tener cuentas en la cadena pero hacer otras cosas fuera de la cadena. Este tipo de visión híbrida tiene su lugar; Iniciar sesión con Ethereum es un buen ejemplo simple de cómo se puede hacer esto en la práctica.
2. Modificar y revocar la certificación
Alice asiste a Example College para obtener su título y recibe un certificado de registro digital firmado por la clave de Example College. Desafortunadamente, seis meses después, Example College descubrió que Alice había plagiado mucho y revocó su título. Pero Alice continúa caminando usando los viejos registros digitales, afirmando a varias personas e instituciones que tiene un título. Incluso la prueba puede venir con algunos permisos (por ejemplo, iniciar sesión en el foro en línea de la universidad), Alice podría intentar ¿Cómo podemos evitar esto?
El enfoque del "minimalismo de cadena de bloques" es convertir el título en una NFT en la cadena, de modo que Example College pueda emitir una transacción en la cadena para revocar la NFT. Pero esto puede ser un gasto necesario: las emisiones son comunes, las revocaciones son raras; no queremos que Example College emita transacciones innecesariamente y pague por cada emisión. Por lo tanto, podemos adoptar una solución híbrida: hacer que el grado inicial sea un mensaje firmado fuera de la cadena y una revocación dentro de la cadena. Este es el método utilizado por OpenCerts.
Una solución completamente fuera de la cadena, defendida por muchos defensores de las credenciales verificables fuera de la cadena, es hacer que Example College ejecute un servidor donde publiquen una lista completa de certificados revocados (cada certificado puede ir acompañado de un nonce para una mayor privacidad, una revocación lista puede ser simplemente una lista de números aleatorios).
Ejecutar un servidor no es una gran carga para una universidad. Pero para otras organizaciones o individuos más pequeños, administrar "otro script de servidor más" y asegurarse de que permanezca en línea puede ser una carga importante para el personal de TI. Si le decimos a la gente que "simplemente use servidores" por miedo a la cadena de bloques, el resultado probable es que todos subcontraten las tareas a un proveedor centralizado. Es mejor mantener el sistema descentralizado y usar solo la cadena de bloques, especialmente ahora que los rollups, el sharding (fragmentación) y otras tecnologías finalmente están comenzando a estar en línea, lo que hace que las cadenas de bloques sean cada vez más baratas.
3. Reputación negativa
Otra área importante en la que las firmas fuera de la cadena se quedan cortas es la "reputación negativa", es decir, las pruebas que está haciendo involucran a personas u organizaciones que pueden no querer que vea sus pruebas. Estoy usando "reputación negativa" como término técnico aquí: el caso de uso más obvio son las malas críticas sobre alguien, como malas críticas o informes sobre el comportamiento negativo de alguien en ciertos contextos; pero hay otros escenarios en los que la prueba "Negativa", lo que no implica un mal comportamiento, como sacar un préstamo que quiere demostrar que no ha sacado demasiados otros préstamos al mismo tiempo.
Para reclamos fuera de la cadena, puede tener una reputación positiva porque mostrarlo lo hace más respetable (o hacer una prueba de conocimiento cero) para el destinatario del reclamo; pero no puede tener una reputación negativa porque las personas siempre eligen mostrar declaración positiva e ignorar todas las demás malas afirmaciones.
Por lo tanto, escribir pruebas en cadena puede resolver los problemas anteriores. Para la privacidad, podemos agregar encriptación y pruebas de conocimiento cero: una prueba puede ser simplemente un dato registrado en la cadena, encriptado con la clave pública del receptor, y el usuario puede demostrar que no tiene una reputación negativa ejecutando una prueba de cero. prueba de conocimiento, esto requiere atravesar todo el historial registrado en la cadena. Las pruebas están en la cadena y el proceso de verificación es consciente de la cadena de bloques, por lo que es fácil verificar que la prueba realmente atravesó todo el historial y no omitió ningún registro. Para que este cómputo sea factible, los usuarios pueden usar cómputos verificables incrementales (como Halo) para mantener y probar un árbol de registros, al tiempo que revelan partes del árbol cuando es necesario.
Las pruebas de reputación negativa y revocación son, en cierto sentido, un problema equivalente: puede revocar una prueba agregando otra prueba de reputación negativa que diga "esta otra prueba ya no es válida", y puede revocar una prueba con reputación positiva Para lograr la revocación de reputación negativa: el título de Alice de Example College se puede revocar y reemplazar con un certificado de grado que diga "Alice obtuvo un título de estudios de ejemplo, pero plagió mucho".
**¿Es una buena idea una reputación negativa? **
Una crítica de la reputación negativa que a veces escuchamos es: ¿No es la reputación negativa una solución binaria distópica de "letras escarlatas" y no deberíamos tratar de hacer cosas con reputación positiva? (Nota Odaily: La heroína en la novela de letras escarlatas es castigada y necesita usar una letra escarlata "A" que simboliza "adulterio" en su pecho).
Si bien apoyo el objetivo de evitar una reputación negativa ilimitada, no estoy de acuerdo con la idea de evitarla por completo. La reputación negativa es importante para muchos casos de uso. Los préstamos no garantizados son extremadamente valiosos para mejorar la eficiencia del capital dentro y fuera del espacio blockchain y claramente pueden beneficiarse de ello. Unirep Social demostró una plataforma de redes sociales de prueba de concepto que combina un alto grado de anonimato con un sistema de reputación negativa que preserva la privacidad para limitar el abuso.
A veces, una reputación negativa puede empoderar, mientras que una reputación positiva puede ser exclusiva. Un foro en línea donde todos tienen derecho a publicar hasta que sean demasiado "castigados" por comportamiento inapropiado es más igualitario que un foro que requiere algún tipo de "prueba de buen carácter" para poder hablar. La mayoría de las personas marginadas que viven "fuera del sistema", por muy buena que sea su conducta, es difícil obtener tal certificado.
Los lectores que están fuertemente a favor de los libertarios civiles también pueden considerar el caso de los sistemas de reputación anónimos para clientes que ejercen el trabajo sexual: usted quiere privacidad, pero también puede querer un sistema: si un cliente abusa de un trabajador sexual, otros pueden ver y mantenerse alejados con más cuidado. . De esta manera, una reputación negativa que es difícil de ocultar puede empoderar a los vulnerables y mantenerlos a salvo. El punto aquí no es defender algún esquema específico para la reputación negativa, sino mostrar que la reputación negativa puede desbloquear un valor muy real, y que un sistema exitoso necesita respaldarlo de alguna manera.
La reputación negativa no tiene por qué ser una reputación negativa ilimitada: creo que siempre debería ser posible crear nuevos perfiles a algún costo (posiblemente sacrificando la mayor parte o la totalidad de la reputación positiva existente). Existe un equilibrio entre muy poca rendición de cuentas y demasiada rendición de cuentas, y debemos encontrar ese equilibrio. Pero tener alguna tecnología que podría permitir una reputación negativa en primer lugar es un requisito previo para desbloquear este espacio de diseño.
4. Comprometidos con la Escasez (Prueba de la Escasez)
Otro ejemplo del valor de blockchain es la emisión de un número limitado de pruebas. Si quisiera respaldar a alguien (por ejemplo, uno podría imaginarse que una empresa de reclutamiento o un programa de visas del gobierno podría considerar dicho respaldo), un tercero que vea el respaldo podría preguntarse si desconfío del respaldo, o si es casi siempre y cuando sea mi amigo quien lo haga. Como una solicitud educada, los apoyaré.
La solución ideal a este problema sería hacer públicos los avales, de modo que los avales se alineen con los incentivos: si la persona a la que avalé hizo algo mal, todos podrían darme un descuento en el futuro. Pero muchas veces, también queremos proteger la privacidad. Entonces puedo publicar el hash de cada respaldo en la cadena para que cualquiera pueda ver cuántos respaldos he emitido.
Un caso de uso más eficiente es emitir múltiples a la vez: si un artista quiere emitir N copias de un NFT de "edición limitada", puede emitir un solo hash en cadena que contenga la raíz de Merkle de su NFT emitido. Un solo problema evita que emitan más después del hecho, y puede emitir un número que represente un límite (por ejemplo, 100) con la raíz de Merkle, lo que significa que solo las 100 ramas de Merkle más a la izquierda son válidas.
Al publicar una sola raíz de Merkle y un recuento máximo en cadena, puede enviar una cantidad limitada de pruebas. En este ejemplo, solo hay cinco ramas Merkle válidas posibles que satisfacen la verificación de prueba. Los lectores astutos pueden notar una similitud conceptual con las cadenas de plasma.
Cinco, conocimiento público
Una de las propiedades poderosas de las cadenas de bloques es que crean conocimiento público: si publico algo en la cadena, Alice puede verlo; Alice puede ver, Bob puede verlo; Charlie puede ver, Alice puede verlo Hasta que Bob pueda verlo, y así en.
El conocimiento común es a menudo importante para la colaboración. Por ejemplo, un grupo de personas puede querer hablar sobre un tema, pero solo se sentirán cómodos si suficientes personas hablan al mismo tiempo para que puedan ocultarse de manera segura entre la multitud. Una forma posible de lograr esto es que una persona inicie un "grupo de compromiso" en torno a una declaración en particular e invite a otros a publicar un hash (en privado al principio) para indicar su acuerdo. Solo si participan suficientes personas dentro de un cierto período de tiempo, todos los participantes deben declarar públicamente su posición en su próximo mensaje en la cadena.
Tal diseño podría implementarse con una combinación de pruebas de conocimiento cero y una cadena de bloques (podría realizarse sin una cadena de bloques, pero esto requeriría un cifrado de testigos, que actualmente no está disponible; o requeriría hardware confiable, cuyas suposiciones de seguridad son seriamente cuestionables). Hay mucho espacio de diseño en torno a estas ideas, que no se explora por completo en la actualidad, pero crecerá rápidamente a medida que el ecosistema de blockchain y las herramientas de criptografía se desarrollen aún más.
6. Interoperabilidad con otras aplicaciones de blockchain
Este es un ejemplo simple: algo debe estar en la cadena para interoperar mejor con otras aplicaciones en la cadena. Pruebas de identidad humana como NFT en cadena, lo que permite que los proyectos se envíen automáticamente o concedan permisos a cuentas con pruebas de identidad humana. Poner los datos de Oracle en la cadena facilita la lectura de los proyectos de finanzas descentralizadas (DeFi). En estos casos, blockchain no elimina la necesidad de confianza, aunque puede adaptarse a estructuras que gestionan la confianza (como las DAO). El valor principal que existe en la cadena es simplemente estar ubicado junto con las cosas con las que está interactuando, lo que requiere el uso de la cadena de bloques por otras razones.
Por supuesto, podría ejecutar oráculos fuera de la cadena y solo importar datos cuando necesite leerlos, pero en muchos casos esto sería más costoso e introduciría una complejidad y un costo innecesarios para los desarrolladores.
Siete, indicadores de código abierto
Un objetivo clave del documento de sociedad descentralizada es habilitar la posibilidad de computar en gráficos de prueba, y una métrica muy importante es medir la descentralización y la diversidad. Por ejemplo, mucha gente parece pensar que el mecanismo de votación ideal permitiría la diversidad, dando más peso a los proyectos que no solo están respaldados por una gran cantidad de tokens e incluso humanos, sino que también están respaldados por puntos de vista genuinamente diversos.
La financiación cuadrática implementada en Gitcoin Grants también incluye cierta lógica que apoya explícitamente la diversidad para mitigar los ataques. Lógica explícita para apoyar la diversidad para mitigar los ataques
Otra cosa que puede hacer que la medición y la puntuación sean valiosas son los sistemas de reputación. Esto ya existe en las calificaciones de manera centralizada, pero se puede hacer de una manera más descentralizada, haciendo transparente el algoritmo y protegiendo más la privacidad del usuario al mismo tiempo.
Además de casos de uso estrechamente acoplados como este (tratar de medir qué tan conectado está alguien y alimentarlo directamente en el mecanismo), existen casos de uso más amplios para ayudar a una comunidad a comprenderse a sí misma. Cuando se trata de medir la descentralización, es posible que las áreas que están demasiado concentradas deban responder. En estos casos, es inevitable ejecutar algoritmos informáticos en una gran cantidad de pruebas y compromisos, y realizar operaciones realmente importantes en la salida.
En lugar de tratar de abolir las métricas cuantitativas, deberíamos intentar crear mejores métricas
Kate Sills expresa su escepticismo sobre la computación de objetivos de reputación, un argumento que se aplica tanto al análisis público como a los ZK individuales que prueban su reputación (como Unirep Social): "El proceso de evaluación de afirmaciones es muy subjetivo y depende del contexto. Gente Naturalmente habrá los desacuerdos sobre la credibilidad de los demás, y la confianza depende del contexto... (por lo tanto) deberíamos ser extremadamente escépticos de todas las propuestas para afirmar que la 'computación' produce resultados objetivos".
En este caso, estoy de acuerdo en que se debe tener en cuenta la subjetividad y el contexto, pero no estoy de acuerdo con la afirmación de que evitar por completo los cálculos en torno a la reputación es lo correcto. El análisis individualizado puro no irá mucho más allá del "número de Dunbar", y cualquier sociedad compleja que intente apoyar la cooperación a gran escala debe basarse en la agregación y la simplificación hasta cierto punto. (Nota diaria: el número de Dunbar también se llama "la ley de 150", que se refiere al límite superior del número de personas que pueden mantener una relación interpersonal cercana con una determinada persona, generalmente considerado como 150).
Habiendo dicho eso, creo que un ecosistema de prueba abierto y participativo (a diferencia del ecosistema centralizado que tenemos hoy) puede lograr lo mejor de ambos mundos al abrir espacio para mejores métricas. Aquí hay algunos principios que tales diseños pueden seguir:
Intersubjetividad: por ejemplo, la reputación no debe ser una calificación global única, sino que debe ser un cálculo más subjetivo que involucre a la persona o entidad que se evalúa, al observador que ve la calificación y quizás incluso a otros aspectos del entorno local.
Neutralidad creíble: el programa claramente no debe dejar espacio para que élites poderosas lo manipulen constantemente para su propio beneficio. Algunas formas posibles de lograr esto son la máxima transparencia y menos cambios en los algoritmos.
Apertura: la capacidad de tener aportes significativos y de examinar los resultados de los demás por uno mismo debe estar abierta a todos, no solo a unos pocos grupos poderosos.
Si no creamos una buena agregación de datos sociales a escala, corremos el riesgo de perder participación de mercado debido a una puntuación de crédito social opaca y centralizada.
No todos los datos deben estar en cadena, pero exponer algunos datos con sentido común puede ayudar a mejorar la legibilidad de la comunidad sin crear discrepancias en el acceso a los datos que podrían ser objeto de abuso para el control centralizado.
Ocho, como almacenamiento de datos
Este es un caso de uso realmente controvertido, a pesar de que muchas personas adoptan otros casos de uso de blockchain. En el espacio de las cadenas de bloques, existe una opinión general de que las cadenas de bloques solo deben usarse cuando existe una necesidad real y no se pueden evitar, y que en otros lugares debemos usar otras herramientas.
En un mundo donde las tarifas de transacción son muy caras y las cadenas de bloques son terriblemente ineficientes, este argumento tiene sentido. Pero en una cadena de bloques con acumulaciones y fragmentación y tarifas de transacción reducidas a centavos, esta idea es menos plausible. En un mundo así, la diferencia de redundancia entre el almacenamiento descentralizado blockchain y no blockchain podría ser solo un factor de 100.
Incluso en un mundo así, no sería prudente almacenar todos los datos en la cadena. Pero, ¿qué pasa con los pequeños registros de texto? Absolutamente. ¿Por qué? Porque la cadena de bloques es en realidad un lugar muy conveniente para almacenar cosas. Guardo una copia de este blog en IPFS. Pero la carga a IPFS generalmente toma una hora y requiere puertas de enlace centralizadas para brindar acceso a los usuarios a velocidades cercanas a la latencia del nivel del sitio web y, a veces, los archivos desaparecen y ya no se pueden ver. Por otro lado, volcar todo el blog en la cadena resolvería completamente este problema. Por supuesto, incluso después de fragmentar el blog es demasiado grande para volcarlo en la cadena, el mismo principio se aplica a los registros más pequeños.
Algunos ejemplos de pequeños casos de uso donde los datos pueden almacenarse en cadena incluyen:
Intercambio de secretos mejorado: divida la contraseña en N partes, donde cualquier parte M = NR puede recuperar la contraseña, pero puede elegir el contenido de todas las N partes. Por ejemplo, estas piezas pueden ser hashes de contraseñas, secretos generados por otras herramientas o respuestas a preguntas de seguridad. Al publicar partes R adicionales en la cadena (aparentemente al azar) y compartir secretos N-of-(N+R) para todo el conjunto.
Optimización ENS. ENS se puede hacer más eficiente combinando todos los registros en un solo hash, publicando solo el hash en la cadena y requiriendo que cualquier persona que acceda a los datos obtenga los datos completos de IPFS. Pero esto agrega una complejidad significativa y aumenta la dependencia de otra pieza de software. Por lo tanto, incluso si la longitud de los datos de ENS supera los 32 bytes, permanecerá en la cadena.
Metadatos sociales: datos asociados con su cuenta (por ejemplo, para un inicio de sesión de Ethereum) que desea hacer públicos y de muy corta duración. Eso está bien para registros de texto, pero generalmente no para datos más grandes, como una imagen de perfil (que podría funcionar si la imagen es un archivo SVG pequeño).
Autenticación y derechos de acceso. Especialmente cuando los datos almacenados tienen menos de unos pocos cientos de bytes, puede ser más conveniente almacenar los datos en la cadena que poner el hash en la cadena y los datos fuera de la cadena.
En muchos casos, la compensación no es solo el costo, sino también la privacidad en el caso extremo de claves o contraseñas comprometidas. A veces, la privacidad solo importa hasta cierto punto, y en lugar de preocuparse por las claves filtradas o la pérdida ocasional de privacidad de la computación cuántica, es mejor asegurarse de que siempre se pueda acceder a los datos de manera confiable. Después de todo, los datos fuera de la cadena almacenados en su "billetera de datos" también pueden ser pirateados.
Pero a veces, los datos son particularmente sensibles, y ese podría ser otro argumento en contra de ponerlos en cadena y almacenarlos localmente como una segunda capa de defensa. Tenga en cuenta, sin embargo, que en estos casos la necesidad de privacidad es un argumento no solo contra las cadenas de bloques, sino contra todo el almacenamiento descentralizado.
en conclusión
De la lista anterior, los dos casos de uso en los que personalmente me siento más seguro en este momento son "interoperabilidad con otras aplicaciones de blockchain" y "administración de cuentas". El primero ya está en la cadena, el segundo es relativamente barato (necesita usar la cadena una vez por usuario, no una vez por operación), tiene un caso claro para ello y realmente no tiene una buena solución no basada en blockchain. .
La "reputación negativa" y la "revocación de la certificación" también son importantes, aunque todavía son casos de uso relativamente tempranos. Puede hacer mucho con la reputación confiando únicamente en la reputación positiva fuera de la cadena, pero espero que los casos de revocación y reputación negativa se aclaren con el tiempo. Predigo que alguien intentará hacer esto con un servidor centralizado, pero con el tiempo debería quedar claro para todos: blockchain es la única forma de evitar la difícil elección entre la inconveniencia y la centralización.
Las cadenas de bloques como almacenamiento de datos para registros de texto cortos pueden ser triviales o significativas, pero espero que este tipo de usos al menos continúen ocurriendo. Blockchain es realmente útil para la recuperación de datos confiable y de bajo costo, ya sea que la aplicación tenga dos usuarios o dos millones de usuarios, los datos pueden continuar recuperándose.
Las métricas de código abierto aún se encuentran en una etapa conceptual muy temprana, y queda por ver cuánto pueden hacer sin ser explotadas (como las reseñas en línea, las calificaciones de las redes sociales, etc., a menudo son explotadas). Y el juego de conocimiento común necesita convencer a las personas para que acepten flujos de trabajo completamente nuevos para cosas socialmente importantes, por lo que también es una idea en etapa inicial.
No estoy muy seguro del alcance exacto del uso no financiero de la cadena de bloques en estas categorías, pero está claro que la cadena de bloques como herramienta habilitadora en estas áreas no debe descartarse.
Ver originales
El contenido es solo de referencia, no una solicitud u oferta. No se proporciona asesoramiento fiscal, legal ni de inversión. Consulte el Descargo de responsabilidad para obtener más información sobre los riesgos.
Vitalik: ¿Cuáles son los casos de uso no financiero de blockchain?
V God también enumeró 8 escenarios de aplicaciones no financieras que pueden usar blockchain en el artículo: cambio y recuperación de clave de cuenta de usuario, modificación y revocación de certificación, reputación negativa, prueba de escasez, conocimiento público y otras aplicaciones de blockchain Interoperabilidad de programas, código abierto métricas, almacenamiento de datos. Las dos aplicaciones no financieras en las que dice que tiene más confianza hasta ahora son: la interoperabilidad con otras aplicaciones de blockchain y la gestión de cuentas.
La siguiente es una publicación de blog larga de V God, compilada por Odaily Planet Daily:
Recientemente, ha habido un mayor interés en las aplicaciones no financieras de blockchain, a las que siempre he apoyado mucho. El mes pasado, fui coautor de un artículo con Puja Ohlhaver y Glen Weyl que describe una visión más detallada de lo que podrían hacer los tokens vinculados al alma (SBT) en un ecosistema más rico donde estas monedas pueden describir varias relaciones. Esto ha provocado cierta discusión sobre si tiene sentido usar blockchain en un ecosistema de identidad descentralizado.
A partir de esto, también hacemos la pregunta: ¿cuál es el punto de usar blockchain en aplicaciones no financieras? ¿Deberíamos dirigirnos hacia un mundo en el que, incluso con aplicaciones de chat descentralizadas, cada mensaje se procese a través de una transacción en cadena que contenga información cifrada? ¿O la cadena de bloques solo es adecuada para la industria financiera (por ejemplo, porque los efectos de red significan que las monedas tienen una necesidad única de una "visión global"), mientras que todas las demás aplicaciones se realizan mejor utilizando sistemas centralizados o más localizados?
Mi propio punto de vista es como la votación de blockchain (Odaily Note: V God insinúa que es más neutral y objetivo), ni "blockchain en todas partes" ni "minimalismo de blockchain" (minimalismo de blockchain) maximalista). Veo el valor de blockchain en muchas situaciones, a veces para objetivos realmente importantes como la confianza y la resistencia a la censura, pero a veces simplemente por conveniencia. Esta publicación intentará describir blockchain, situaciones en las que puede o no ser útil de alguna manera. Tenga en cuenta que este artículo no es una lista completa y muchas cosas se omiten intencionalmente, nuestro objetivo es aclarar algunas categorías comunes.
1. Cambio y recuperación de clave de cuenta de usuario
Uno de los mayores desafíos en los sistemas de cuentas criptográficas es el problema del cambio de clave, que puede ocurrir de varias maneras:
Implementar los dos primeros puntos es relativamente simple porque se pueden hacer de forma completamente autónoma: usted controla la tecla X y desea cambiar a la tecla Y, por lo que publica un mensaje firmado por X que dice "Verifíqueme con Y de ahora en adelante". ." ', todos aceptan eso.
Tenga en cuenta, sin embargo, que incluso para estos escenarios de cambio de clave relativamente simples, no puede simplemente usar criptografía. Considere la siguiente situación:
Para los que llegan tarde y reciben dos mensajes al mismo tiempo, solo ven que A ya no se usa, pero no saben cuál de los dos mensajes "reemplazar A con B" o "reemplazar A con C" tiene una clase de prioridad más alta .
Resolver "3" y "4" es más difícil, mi solución preferida es la billetera de recuperación social y de múltiples firmas. En caso de pérdida o robo, tus amigos, familiares y otros contactos pueden transferir el control de tu cuenta a una nueva clave. Su participación también puede ser necesaria para operaciones críticas como la transferencia de grandes cantidades de fondos o la firma de contratos importantes.
La "recuperación social" mediante el uso compartido de secretos es teóricamente posible, pero difícil en la práctica: si ya no confía en algunos de sus contactos, o si quieren cambiar sus claves, no puede revocar los derechos de acceso en caso de Así que volvemos al problema de necesitar algún tipo de registro en cadena.
Hay una idea sutil pero importante en el artículo de DeSoc: para mantener la intransferibilidad, es posible que sea necesario aplicar los perfiles socialmente restaurados. Dicho esto, incluso si vende su cuenta, siempre puede usar la recuperación social para recuperar la propiedad de la cuenta. Esto abordaría problemas como los conductores con mal crédito que compran cuentas verificadas en plataformas de viajes compartidos. Esta es una idea especulativa y no tiene que realizarse completamente para obtener los otros beneficios de un sistema de identidad y reputación basado en blockchain.
Tenga en cuenta que este es solo un caso de uso limitado de blockchain hasta el momento: está perfectamente bien tener cuentas en la cadena pero hacer otras cosas fuera de la cadena. Este tipo de visión híbrida tiene su lugar; Iniciar sesión con Ethereum es un buen ejemplo simple de cómo se puede hacer esto en la práctica.
2. Modificar y revocar la certificación
Alice asiste a Example College para obtener su título y recibe un certificado de registro digital firmado por la clave de Example College. Desafortunadamente, seis meses después, Example College descubrió que Alice había plagiado mucho y revocó su título. Pero Alice continúa caminando usando los viejos registros digitales, afirmando a varias personas e instituciones que tiene un título. Incluso la prueba puede venir con algunos permisos (por ejemplo, iniciar sesión en el foro en línea de la universidad), Alice podría intentar ¿Cómo podemos evitar esto?
El enfoque del "minimalismo de cadena de bloques" es convertir el título en una NFT en la cadena, de modo que Example College pueda emitir una transacción en la cadena para revocar la NFT. Pero esto puede ser un gasto necesario: las emisiones son comunes, las revocaciones son raras; no queremos que Example College emita transacciones innecesariamente y pague por cada emisión. Por lo tanto, podemos adoptar una solución híbrida: hacer que el grado inicial sea un mensaje firmado fuera de la cadena y una revocación dentro de la cadena. Este es el método utilizado por OpenCerts.
Una solución completamente fuera de la cadena, defendida por muchos defensores de las credenciales verificables fuera de la cadena, es hacer que Example College ejecute un servidor donde publiquen una lista completa de certificados revocados (cada certificado puede ir acompañado de un nonce para una mayor privacidad, una revocación lista puede ser simplemente una lista de números aleatorios).
Ejecutar un servidor no es una gran carga para una universidad. Pero para otras organizaciones o individuos más pequeños, administrar "otro script de servidor más" y asegurarse de que permanezca en línea puede ser una carga importante para el personal de TI. Si le decimos a la gente que "simplemente use servidores" por miedo a la cadena de bloques, el resultado probable es que todos subcontraten las tareas a un proveedor centralizado. Es mejor mantener el sistema descentralizado y usar solo la cadena de bloques, especialmente ahora que los rollups, el sharding (fragmentación) y otras tecnologías finalmente están comenzando a estar en línea, lo que hace que las cadenas de bloques sean cada vez más baratas.
3. Reputación negativa
Otra área importante en la que las firmas fuera de la cadena se quedan cortas es la "reputación negativa", es decir, las pruebas que está haciendo involucran a personas u organizaciones que pueden no querer que vea sus pruebas. Estoy usando "reputación negativa" como término técnico aquí: el caso de uso más obvio son las malas críticas sobre alguien, como malas críticas o informes sobre el comportamiento negativo de alguien en ciertos contextos; pero hay otros escenarios en los que la prueba "Negativa", lo que no implica un mal comportamiento, como sacar un préstamo que quiere demostrar que no ha sacado demasiados otros préstamos al mismo tiempo.
Para reclamos fuera de la cadena, puede tener una reputación positiva porque mostrarlo lo hace más respetable (o hacer una prueba de conocimiento cero) para el destinatario del reclamo; pero no puede tener una reputación negativa porque las personas siempre eligen mostrar declaración positiva e ignorar todas las demás malas afirmaciones.
Por lo tanto, escribir pruebas en cadena puede resolver los problemas anteriores. Para la privacidad, podemos agregar encriptación y pruebas de conocimiento cero: una prueba puede ser simplemente un dato registrado en la cadena, encriptado con la clave pública del receptor, y el usuario puede demostrar que no tiene una reputación negativa ejecutando una prueba de cero. prueba de conocimiento, esto requiere atravesar todo el historial registrado en la cadena. Las pruebas están en la cadena y el proceso de verificación es consciente de la cadena de bloques, por lo que es fácil verificar que la prueba realmente atravesó todo el historial y no omitió ningún registro. Para que este cómputo sea factible, los usuarios pueden usar cómputos verificables incrementales (como Halo) para mantener y probar un árbol de registros, al tiempo que revelan partes del árbol cuando es necesario.
Las pruebas de reputación negativa y revocación son, en cierto sentido, un problema equivalente: puede revocar una prueba agregando otra prueba de reputación negativa que diga "esta otra prueba ya no es válida", y puede revocar una prueba con reputación positiva Para lograr la revocación de reputación negativa: el título de Alice de Example College se puede revocar y reemplazar con un certificado de grado que diga "Alice obtuvo un título de estudios de ejemplo, pero plagió mucho".
**¿Es una buena idea una reputación negativa? **
Una crítica de la reputación negativa que a veces escuchamos es: ¿No es la reputación negativa una solución binaria distópica de "letras escarlatas" y no deberíamos tratar de hacer cosas con reputación positiva? (Nota Odaily: La heroína en la novela de letras escarlatas es castigada y necesita usar una letra escarlata "A" que simboliza "adulterio" en su pecho).
Si bien apoyo el objetivo de evitar una reputación negativa ilimitada, no estoy de acuerdo con la idea de evitarla por completo. La reputación negativa es importante para muchos casos de uso. Los préstamos no garantizados son extremadamente valiosos para mejorar la eficiencia del capital dentro y fuera del espacio blockchain y claramente pueden beneficiarse de ello. Unirep Social demostró una plataforma de redes sociales de prueba de concepto que combina un alto grado de anonimato con un sistema de reputación negativa que preserva la privacidad para limitar el abuso.
A veces, una reputación negativa puede empoderar, mientras que una reputación positiva puede ser exclusiva. Un foro en línea donde todos tienen derecho a publicar hasta que sean demasiado "castigados" por comportamiento inapropiado es más igualitario que un foro que requiere algún tipo de "prueba de buen carácter" para poder hablar. La mayoría de las personas marginadas que viven "fuera del sistema", por muy buena que sea su conducta, es difícil obtener tal certificado.
Los lectores que están fuertemente a favor de los libertarios civiles también pueden considerar el caso de los sistemas de reputación anónimos para clientes que ejercen el trabajo sexual: usted quiere privacidad, pero también puede querer un sistema: si un cliente abusa de un trabajador sexual, otros pueden ver y mantenerse alejados con más cuidado. . De esta manera, una reputación negativa que es difícil de ocultar puede empoderar a los vulnerables y mantenerlos a salvo. El punto aquí no es defender algún esquema específico para la reputación negativa, sino mostrar que la reputación negativa puede desbloquear un valor muy real, y que un sistema exitoso necesita respaldarlo de alguna manera.
La reputación negativa no tiene por qué ser una reputación negativa ilimitada: creo que siempre debería ser posible crear nuevos perfiles a algún costo (posiblemente sacrificando la mayor parte o la totalidad de la reputación positiva existente). Existe un equilibrio entre muy poca rendición de cuentas y demasiada rendición de cuentas, y debemos encontrar ese equilibrio. Pero tener alguna tecnología que podría permitir una reputación negativa en primer lugar es un requisito previo para desbloquear este espacio de diseño.
4. Comprometidos con la Escasez (Prueba de la Escasez)
Otro ejemplo del valor de blockchain es la emisión de un número limitado de pruebas. Si quisiera respaldar a alguien (por ejemplo, uno podría imaginarse que una empresa de reclutamiento o un programa de visas del gobierno podría considerar dicho respaldo), un tercero que vea el respaldo podría preguntarse si desconfío del respaldo, o si es casi siempre y cuando sea mi amigo quien lo haga. Como una solicitud educada, los apoyaré.
La solución ideal a este problema sería hacer públicos los avales, de modo que los avales se alineen con los incentivos: si la persona a la que avalé hizo algo mal, todos podrían darme un descuento en el futuro. Pero muchas veces, también queremos proteger la privacidad. Entonces puedo publicar el hash de cada respaldo en la cadena para que cualquiera pueda ver cuántos respaldos he emitido.
Un caso de uso más eficiente es emitir múltiples a la vez: si un artista quiere emitir N copias de un NFT de "edición limitada", puede emitir un solo hash en cadena que contenga la raíz de Merkle de su NFT emitido. Un solo problema evita que emitan más después del hecho, y puede emitir un número que represente un límite (por ejemplo, 100) con la raíz de Merkle, lo que significa que solo las 100 ramas de Merkle más a la izquierda son válidas.
Cinco, conocimiento público
Una de las propiedades poderosas de las cadenas de bloques es que crean conocimiento público: si publico algo en la cadena, Alice puede verlo; Alice puede ver, Bob puede verlo; Charlie puede ver, Alice puede verlo Hasta que Bob pueda verlo, y así en.
El conocimiento común es a menudo importante para la colaboración. Por ejemplo, un grupo de personas puede querer hablar sobre un tema, pero solo se sentirán cómodos si suficientes personas hablan al mismo tiempo para que puedan ocultarse de manera segura entre la multitud. Una forma posible de lograr esto es que una persona inicie un "grupo de compromiso" en torno a una declaración en particular e invite a otros a publicar un hash (en privado al principio) para indicar su acuerdo. Solo si participan suficientes personas dentro de un cierto período de tiempo, todos los participantes deben declarar públicamente su posición en su próximo mensaje en la cadena.
Tal diseño podría implementarse con una combinación de pruebas de conocimiento cero y una cadena de bloques (podría realizarse sin una cadena de bloques, pero esto requeriría un cifrado de testigos, que actualmente no está disponible; o requeriría hardware confiable, cuyas suposiciones de seguridad son seriamente cuestionables). Hay mucho espacio de diseño en torno a estas ideas, que no se explora por completo en la actualidad, pero crecerá rápidamente a medida que el ecosistema de blockchain y las herramientas de criptografía se desarrollen aún más.
6. Interoperabilidad con otras aplicaciones de blockchain
Este es un ejemplo simple: algo debe estar en la cadena para interoperar mejor con otras aplicaciones en la cadena. Pruebas de identidad humana como NFT en cadena, lo que permite que los proyectos se envíen automáticamente o concedan permisos a cuentas con pruebas de identidad humana. Poner los datos de Oracle en la cadena facilita la lectura de los proyectos de finanzas descentralizadas (DeFi). En estos casos, blockchain no elimina la necesidad de confianza, aunque puede adaptarse a estructuras que gestionan la confianza (como las DAO). El valor principal que existe en la cadena es simplemente estar ubicado junto con las cosas con las que está interactuando, lo que requiere el uso de la cadena de bloques por otras razones.
Por supuesto, podría ejecutar oráculos fuera de la cadena y solo importar datos cuando necesite leerlos, pero en muchos casos esto sería más costoso e introduciría una complejidad y un costo innecesarios para los desarrolladores.
Siete, indicadores de código abierto
Un objetivo clave del documento de sociedad descentralizada es habilitar la posibilidad de computar en gráficos de prueba, y una métrica muy importante es medir la descentralización y la diversidad. Por ejemplo, mucha gente parece pensar que el mecanismo de votación ideal permitiría la diversidad, dando más peso a los proyectos que no solo están respaldados por una gran cantidad de tokens e incluso humanos, sino que también están respaldados por puntos de vista genuinamente diversos.
Otra cosa que puede hacer que la medición y la puntuación sean valiosas son los sistemas de reputación. Esto ya existe en las calificaciones de manera centralizada, pero se puede hacer de una manera más descentralizada, haciendo transparente el algoritmo y protegiendo más la privacidad del usuario al mismo tiempo.
Además de casos de uso estrechamente acoplados como este (tratar de medir qué tan conectado está alguien y alimentarlo directamente en el mecanismo), existen casos de uso más amplios para ayudar a una comunidad a comprenderse a sí misma. Cuando se trata de medir la descentralización, es posible que las áreas que están demasiado concentradas deban responder. En estos casos, es inevitable ejecutar algoritmos informáticos en una gran cantidad de pruebas y compromisos, y realizar operaciones realmente importantes en la salida.
En lugar de tratar de abolir las métricas cuantitativas, deberíamos intentar crear mejores métricas
Kate Sills expresa su escepticismo sobre la computación de objetivos de reputación, un argumento que se aplica tanto al análisis público como a los ZK individuales que prueban su reputación (como Unirep Social): "El proceso de evaluación de afirmaciones es muy subjetivo y depende del contexto. Gente Naturalmente habrá los desacuerdos sobre la credibilidad de los demás, y la confianza depende del contexto... (por lo tanto) deberíamos ser extremadamente escépticos de todas las propuestas para afirmar que la 'computación' produce resultados objetivos".
En este caso, estoy de acuerdo en que se debe tener en cuenta la subjetividad y el contexto, pero no estoy de acuerdo con la afirmación de que evitar por completo los cálculos en torno a la reputación es lo correcto. El análisis individualizado puro no irá mucho más allá del "número de Dunbar", y cualquier sociedad compleja que intente apoyar la cooperación a gran escala debe basarse en la agregación y la simplificación hasta cierto punto. (Nota diaria: el número de Dunbar también se llama "la ley de 150", que se refiere al límite superior del número de personas que pueden mantener una relación interpersonal cercana con una determinada persona, generalmente considerado como 150).
Habiendo dicho eso, creo que un ecosistema de prueba abierto y participativo (a diferencia del ecosistema centralizado que tenemos hoy) puede lograr lo mejor de ambos mundos al abrir espacio para mejores métricas. Aquí hay algunos principios que tales diseños pueden seguir:
Intersubjetividad: por ejemplo, la reputación no debe ser una calificación global única, sino que debe ser un cálculo más subjetivo que involucre a la persona o entidad que se evalúa, al observador que ve la calificación y quizás incluso a otros aspectos del entorno local.
Neutralidad creíble: el programa claramente no debe dejar espacio para que élites poderosas lo manipulen constantemente para su propio beneficio. Algunas formas posibles de lograr esto son la máxima transparencia y menos cambios en los algoritmos.
Apertura: la capacidad de tener aportes significativos y de examinar los resultados de los demás por uno mismo debe estar abierta a todos, no solo a unos pocos grupos poderosos.
Si no creamos una buena agregación de datos sociales a escala, corremos el riesgo de perder participación de mercado debido a una puntuación de crédito social opaca y centralizada.
No todos los datos deben estar en cadena, pero exponer algunos datos con sentido común puede ayudar a mejorar la legibilidad de la comunidad sin crear discrepancias en el acceso a los datos que podrían ser objeto de abuso para el control centralizado.
Ocho, como almacenamiento de datos
Este es un caso de uso realmente controvertido, a pesar de que muchas personas adoptan otros casos de uso de blockchain. En el espacio de las cadenas de bloques, existe una opinión general de que las cadenas de bloques solo deben usarse cuando existe una necesidad real y no se pueden evitar, y que en otros lugares debemos usar otras herramientas.
En un mundo donde las tarifas de transacción son muy caras y las cadenas de bloques son terriblemente ineficientes, este argumento tiene sentido. Pero en una cadena de bloques con acumulaciones y fragmentación y tarifas de transacción reducidas a centavos, esta idea es menos plausible. En un mundo así, la diferencia de redundancia entre el almacenamiento descentralizado blockchain y no blockchain podría ser solo un factor de 100.
Incluso en un mundo así, no sería prudente almacenar todos los datos en la cadena. Pero, ¿qué pasa con los pequeños registros de texto? Absolutamente. ¿Por qué? Porque la cadena de bloques es en realidad un lugar muy conveniente para almacenar cosas. Guardo una copia de este blog en IPFS. Pero la carga a IPFS generalmente toma una hora y requiere puertas de enlace centralizadas para brindar acceso a los usuarios a velocidades cercanas a la latencia del nivel del sitio web y, a veces, los archivos desaparecen y ya no se pueden ver. Por otro lado, volcar todo el blog en la cadena resolvería completamente este problema. Por supuesto, incluso después de fragmentar el blog es demasiado grande para volcarlo en la cadena, el mismo principio se aplica a los registros más pequeños.
Algunos ejemplos de pequeños casos de uso donde los datos pueden almacenarse en cadena incluyen:
Intercambio de secretos mejorado: divida la contraseña en N partes, donde cualquier parte M = NR puede recuperar la contraseña, pero puede elegir el contenido de todas las N partes. Por ejemplo, estas piezas pueden ser hashes de contraseñas, secretos generados por otras herramientas o respuestas a preguntas de seguridad. Al publicar partes R adicionales en la cadena (aparentemente al azar) y compartir secretos N-of-(N+R) para todo el conjunto.
Optimización ENS. ENS se puede hacer más eficiente combinando todos los registros en un solo hash, publicando solo el hash en la cadena y requiriendo que cualquier persona que acceda a los datos obtenga los datos completos de IPFS. Pero esto agrega una complejidad significativa y aumenta la dependencia de otra pieza de software. Por lo tanto, incluso si la longitud de los datos de ENS supera los 32 bytes, permanecerá en la cadena.
Metadatos sociales: datos asociados con su cuenta (por ejemplo, para un inicio de sesión de Ethereum) que desea hacer públicos y de muy corta duración. Eso está bien para registros de texto, pero generalmente no para datos más grandes, como una imagen de perfil (que podría funcionar si la imagen es un archivo SVG pequeño).
Autenticación y derechos de acceso. Especialmente cuando los datos almacenados tienen menos de unos pocos cientos de bytes, puede ser más conveniente almacenar los datos en la cadena que poner el hash en la cadena y los datos fuera de la cadena.
En muchos casos, la compensación no es solo el costo, sino también la privacidad en el caso extremo de claves o contraseñas comprometidas. A veces, la privacidad solo importa hasta cierto punto, y en lugar de preocuparse por las claves filtradas o la pérdida ocasional de privacidad de la computación cuántica, es mejor asegurarse de que siempre se pueda acceder a los datos de manera confiable. Después de todo, los datos fuera de la cadena almacenados en su "billetera de datos" también pueden ser pirateados.
Pero a veces, los datos son particularmente sensibles, y ese podría ser otro argumento en contra de ponerlos en cadena y almacenarlos localmente como una segunda capa de defensa. Tenga en cuenta, sin embargo, que en estos casos la necesidad de privacidad es un argumento no solo contra las cadenas de bloques, sino contra todo el almacenamiento descentralizado.
en conclusión
De la lista anterior, los dos casos de uso en los que personalmente me siento más seguro en este momento son "interoperabilidad con otras aplicaciones de blockchain" y "administración de cuentas". El primero ya está en la cadena, el segundo es relativamente barato (necesita usar la cadena una vez por usuario, no una vez por operación), tiene un caso claro para ello y realmente no tiene una buena solución no basada en blockchain. .
La "reputación negativa" y la "revocación de la certificación" también son importantes, aunque todavía son casos de uso relativamente tempranos. Puede hacer mucho con la reputación confiando únicamente en la reputación positiva fuera de la cadena, pero espero que los casos de revocación y reputación negativa se aclaren con el tiempo. Predigo que alguien intentará hacer esto con un servidor centralizado, pero con el tiempo debería quedar claro para todos: blockchain es la única forma de evitar la difícil elección entre la inconveniencia y la centralización.
Las cadenas de bloques como almacenamiento de datos para registros de texto cortos pueden ser triviales o significativas, pero espero que este tipo de usos al menos continúen ocurriendo. Blockchain es realmente útil para la recuperación de datos confiable y de bajo costo, ya sea que la aplicación tenga dos usuarios o dos millones de usuarios, los datos pueden continuar recuperándose.
Las métricas de código abierto aún se encuentran en una etapa conceptual muy temprana, y queda por ver cuánto pueden hacer sin ser explotadas (como las reseñas en línea, las calificaciones de las redes sociales, etc., a menudo son explotadas). Y el juego de conocimiento común necesita convencer a las personas para que acepten flujos de trabajo completamente nuevos para cosas socialmente importantes, por lo que también es una idea en etapa inicial.
No estoy muy seguro del alcance exacto del uso no financiero de la cadena de bloques en estas categorías, pero está claro que la cadena de bloques como herramienta habilitadora en estas áreas no debe descartarse.