¿Qué queremos decir en realidad cuando hablamos de privacidad en las redes de cadena de bloques?

AvanzadoAug 23, 2024
Este artículo argumenta que la privacidad en las redes de cadena de bloques es esencial para una adopción más amplia, en lugar de ser simplemente una característica deseable. Destaca los desafíos planteados por la transparencia actual de las cadenas de bloques y enfatiza que los diferentes usuarios y casos de uso requerirán diferentes niveles de privacidad, sugiriendo que un enfoque único no es suficiente.
¿Qué queremos decir en realidad cuando hablamos de privacidad en las redes de cadena de bloques?

Las opiniones y suposiciones subyacentes en esta pieza:

  • Algunas privacidad en las redes de cadena de bloques es algo indispensable, no algo opcional
  • La naturaleza transparente actual de las cadenas de bloques es un gran obstáculo para una mayor adopción
  • Diferentes usuarios y casos de uso requerirán diferentes niveles de privacidad. No todos los problemas necesitan ser resueltos con la misma herramienta.

¿Los usuarios individuales se preocupan por la privacidad?

Sí, pero algunos más que otros.

Todos se preocupan por la privacidad en cierto grado y todos hacemos suposiciones implícitas sobre la privacidad en nuestra vida diaria. Por ejemplo, al escribir un mensaje en un grupo de Slack de la empresa, asumes que solo tus compañeros de trabajo pueden ver los mensajes. De manera similar, muchos están de acuerdo con que la compañía de tarjetas de crédito o el banco puedan monitorear sus transacciones, pero no querrían difundir su historial de transacciones al resto del mundo.

Las corporaciones tienen razones adicionales para preocuparse por la privacidad (competitivas, de seguridad y regulatorias) y suelen tener una mayor disposición a pagar por ella en comparación con los usuarios individuales.

Otra pregunta importante es: ¿De quién quieren los usuarios privacidad?

  1. Otros usuarios de la red y observadores externos
  2. Terceros e intermediarios que facilitan el servicio
  3. Gobiernos, organismos gubernamentales y vigilancia masiva

El primero es absolutamente imprescindible para la mayoría de los casos de uso y ya es alcanzable en las redes de cadena de bloques hoy en día si aceptamos garantías más débiles (más sobre esto más adelante). El segundo es hacia lo que la industria está trabajando para dar más control a los usuarios y evitar que las empresas con modelos comerciales aprovechen nuestros datos sin permiso. El tercero, la privacidad frente a gobiernos y organismos gubernamentales, es el más complicado desde un punto de vista regulativo y político.

¿Cómo definimos "privacidad"?

La privacidad no es secreto. Un asunto privado es algo que uno no quiere que todo el mundo sepa, pero un asunto secreto es algo que uno no quiere que nadie sepa. La privacidad es el poder de revelarse selectivamente al mundo - Manifiesto de un Ciberpunk

La privacidad es un tema complejo que abarca varios temas separados (pero relacionados) como la soberanía de los datos (propiedad individual de los datos), la criptografía, etc. Además, las personas suelen utilizar el término de manera bastante laxa en diferentes contextos sin definiciones claras, lo que dificulta el razonamiento al respecto. Términos como confidencialidad (qué) y anonimato (quién) se utilizan a menudo indistintamente con la privacidad, aunque ambos son solo un subconjunto de las características de privacidad a las que aspirar.

Algunas preguntas clave sobre la privacidad son:

  • ¿Qué se puede revelar y a quién si se desea?
  • ¿Quién tiene el poder de revelar información?
  • ¿Qué se debe revelar y a quién para que el sistema funcione?
  • ¿Qué garantías hay de que lo que es privado hoy seguirá siéndolo mañana?

Basándonos en estas preguntas, podríamos resumirlo en una sola frase:

La privacidad se trata de que el usuario (propietario de los datos) tenga control sobre qué datos se comparten, con quién y bajo qué condiciones, junto con garantías sólidas de que lo que se programa para ser privado permanezca así.

¿Necesitamos una nueva terminología?

¿Considerando lo anterior, "privacidad" es un mal término para lo que estamos tratando de lograr? Quizás, quizás no. Depende de cómo te acerques a ello.

Por un lado, el término "privacidad" parece bastante binario (algo es privado o no), pero como hemos destacado anteriormente, es mucho más matizado que eso. Diferentes cosas pueden ser privadas (entrada, salida, programa interactuado, etc), algo puede ser privado para una persona pero público para otra, y hay una gama de suposiciones de confianza detrás de diferentes soluciones de privacidad. Además, el término tiene una connotación negativa que puede desviar la discusión del tema real.

Por otro lado, "privacidad" es un término conocido con presencia en la mente existente. Introducir nueva terminología puede ser confuso, especialmente si no hay consenso sobre qué nuevo término se debe usar. Intentar evitar el tema utilizando un término alternativo también parece algo deshonesto y deberíamos poder hablar de las cosas tal como son.

Como ingenieros de protocolos y constructores de redes de cadenas de bloques, mirar las cosas desde una nueva perspectiva puede ayudarnos a detectar nuevos problemas o resaltar vacíos en las soluciones actuales. Términos alternativos como control de flujo de información (utilizado en la literatura de privacidad más amplia) o divulgaciones programables (nuestra sugerencia) quizás capturen mejor el matiz. La información puede ser privada para algunos pero pública para otros, y depende de los usuarios decidir qué información se comparte con quién.

Sin embargo, nos mantendremos en el término privacidad en esta publicación para evitar confusiones innecesarias.

¿En qué se diferencia la privacidad en Web2 de las redes de blockchain?

La mayoría de los usuarios de Internet están familiarizados con la “privacidad” de la web2. Nuestros datos están encriptados durante la transmisión ( hasta el 95% de todo el tráfico hoy) y protegidos de otros usuarios, pero compartidos con intermediarios y proveedores de servicios de confianza. En otras palabras, la “privacidad” (de otros usuarios) proviene de confiar en un intermediario.

Este enfoque le da cierto control al usuario sobre con quién compartir sus datos más allá del proveedor de servicios. Sin embargo, se deposita mucha confianza (directa o indirectamente) en el proveedor de servicios para mantener los datos seguros y manejarlos adecuadamente. Además, las garantías limitadas y poca transparencia sobre cómo se utilizan los datos significa que los usuarios solo pueden esperar que los proveedores de servicios se comporten como afirman (modelo basado en la reputación).

Las redes de cadena de bloques tienen como objetivo reducir la dependencia de los intermediarios y proporcionar garantías más sólidas mediante el paso de un modelo basado en la reputación a garantías económicas o criptográficas. Sin embargo, el modelo distribuido también impone nuevos desafíos, especialmente para la privacidad. Los nodos necesitan sincronizarse y llegar a un consenso sobre el estado actual de la red, lo cual es relativamente fácil cuando todos los datos son transparentes y compartidos entre todos los nodos (estado actual). Esto se vuelve significativamente más difícil cuando comenzamos a cifrar los datos, una razón principal por la cual la mayoría de las redes de cadena de bloques son transparentes hoy en día.

¿Por qué es difícil lograr privacidad en las redes de cadenas de bloques?

Hay dos formas de lograr privacidad para las redes de cadena de bloques: privacidad confiable (intermediada) o privacidad de confianza minimizada (no intermediada).

Ambos son desafiantes, pero por diferentes razones (ideológicas vs técnicas). La privacidad confiable está más fácilmente disponible pero tiene garantías más débiles y requiere sacrificar parte de la ideología de las cadenas de bloques al depender de actores y intermediarios centralizados. La privacidad con una minimización de la confianza puede ofrecer garantías mucho más sólidas y asegurar que los usuarios mantengan el control de sus datos, pero es más difícil tanto desde un aspecto técnico como político (cómo cumplir con las regulaciones actuales).

Privacidad confiable en redes de cadena de bloques

El enfoque confiable se parece bastante a la privacidad de estilo web2 en el sentido de que puede lograr privacidad frente a otros usuarios, pero requiere confiar en un tercero o intermediario para facilitarlo. No es tan técnicamente exigente, lo que lo convierte en una opción pragmática para proyectos que requieren algunas garantías de privacidad hoy en día, pero son sensibles al costo y tienen transacciones de menor valor. Un ejemplo de esto son los protocolos sociales web3 (como Red de lentes), que pone más énfasis en el rendimiento y la practicidad que en la dureza de las garantías de privacidad.

Un enfoque simple es usar un validiumdonde un comité de disponibilidad de datos (DAC) mantiene el estado actual y los usuarios confían en los operadores de DAC para mantener ese estado privado y actualizarlo según sea necesario. Otro ejemplo es Extensión del token de Solana, que logra la confidencialidad de los pagos (ocultando saldos de cuentas y transacciones) mediante ZKPs pero permite designar a un tercero de confianza con derechos de auditoría para garantizar el cumplimiento normativo.

Argumentaríamos que este modelo puede extender el paradigma web2 actual donde solo confías en un intermediario para cumplir las reglas. Con las cadenas de bloques, el modelo de confianza pura puede combinarse con algunas garantías adicionales (económicas o criptográficas) de que los intermediarios se comportarán como se espera, o al menos aumentarán el incentivo para hacerlo.

También existen soluciones híbridas en las que una solución con un mínimo de confianza depende de un componente centralizado para mejorar el costo, la UX o el rendimiento. Ejemplos en esta categoría incluyen la externalización de la demostración de ZKPs privados a un único demostrador, o una red FHE en la que un intermediario centralizado tiene la clave de descifrado.

(Incluimos las blockchains con permisos en la categoría de confiables, pero todas las demás soluciones se refieren a blockchains sin permisos).

Privacidad Minimizada de Confianza en Redes de Cadena de Bloques

El enfoque de minimización de la confianza evita tener un único punto de falla a través de un intermediario de confianza que puede ofrecer garantías más sólidas. Sin embargo, es mucho más difícil de implementar desde un punto de vista técnico. En la mayoría de los casos, requiere una combinación de soluciones de criptografía moderna y cambios estructurales como el uso de una estructura de cuenta diferente.

Las soluciones existentes se centran principalmente en casos de uso especializados, como:

  • Financiero: las transferencias privadas, los pagos y los intercambios tienen como objetivo ocultar la identidad, la entrada y/o la salida (quién envió qué, cuánto y a quién). Los compromisos entre diferentes soluciones incluyen piscinas protegidas de un solo activo frente a piscinas protegidas de varios activos y cuánto es privado. Los ejemplos aquí incluyen Zcash, Namada, y Penumbra.
  • Identidad: La privacidad es un requisito indispensable para cualquier solución que requiera conectar nuestra identidad fuera de la cadena con nuestra identidad en la cadena o intentar almacenar documentos de identidad en la cadena de bloques. Existen varios intentos por parte del sector privado (como,Prueba de PasaporteyHolónimojunto coninterés creciente por los gobiernospara apoyar soluciones de identidad digital que preserven la privacidad.
  • Gobernanza: La idea de la votación privada en cadena es ocultar quién votó qué y mantener el recuento total en privado hasta el final de la votación, de modo que no influya en la decisión de voto de ningún individuo. El gráfico a continuación enumera algunos ejemplos con características variables y suposiciones de confianza:

  • Resumen de algunas soluciones existentes (origen)

Muchos casos de uso, sin embargo, dependen de un estado compartido y se vuelve mucho más desafiante cuando intentamos extender la privacidad minimizada de confianza a estos casos de uso de propósito general.

Otra cosa a tener en cuenta es que si bien los casos de uso especializados (pagos, votaciones, identidad, etc.) pueden funcionar bien de forma aislada, requieren que los usuarios se muevan entre conjuntos protegidos (zonas de confianza) para diferentes casos de uso. Esto no es óptimo ya quela mayoría de la información se filtracuando se mueve dentro y fuera de un conjunto blindado.

Por lo tanto, el objetivo debería ser permitir la privacidad para la computación de propósito general (todos los casos de uso, incluidos aquellos que requieren estado compartido), expandir el conjunto protegido y agregar controles de gestión de acceso granulares (expresividad).

¿Cómo podemos evaluar diferentes soluciones?

Si bien el objetivo final está claro, el camino para llegar allí es largo. Mientras tanto, necesitamos marcos para evaluar las soluciones actuales y los compromisos que hacen. Creemos que el espacio de compromiso se puede dividir en tres categorías principales:

  1. ¿Qué es privado - Diferentes tipos de privacidad relacionados con las cadenas de bloques:
  1. Entradas privadas (mensajes)
  2. Salidas privadas (cambios de estado)
  3. Contrapartes privadas
    1. Usuarios
    2. Función
    3. Programa

Cuanto más casillas pueda marcar una solución, mejor. Idealmente, tendrías todas ellas, pero esto a menudo requiere hacer algunos compromisos. La diferencia entre la función y la privacidad del programa es que algunos sistemas permiten ocultar qué función se llamó (por ejemplo, qué lógica de oferta utilizó el usuario), pero aún revelan el programa con el que interactuó el usuario. La privacidad del programa es una forma más estricta de esto, donde todas las llamadas a función son privadas junto con el programa con el que se interactuó. Esta categoría también es donde se encuentra la discusión sobre el anonimato (quién) versus la confidencialidad (qué)

Es importante tener en cuenta que el usuario tiene la opción de revelar selectivamente algunos (o todos) de estos a ciertas partes, pero si ninguno de ellos es privado por defecto, entonces el usuario no tiene esa opción.

  1. Programabilidad: ¿Para qué puedes usar la privacidad?

Esta categoría se centra en la programabilidad de la computación privada y en cuáles son sus limitaciones:

  • ¿Se puede calcular sobre datos cifrados? ¿Existe alguna componibilidad entre los programas privados?
  • ¿Pueden los estados privados y públicos interactuar de alguna manera? ¿Cuáles son las limitaciones y compensaciones de esto?
  • ¿Qué límites hay en cuanto a la complejidad de los programas que se pueden tener (límites de gas, expresividad, etc)?

Como se mencionó anteriormente, muchas aplicaciones (en el mundo real) requieren un estado compartido, lo cual es difícil de lograr de manera descentralizada y confiable. Existe mucho trabajo e investigación en esta área para ayudarnos a pasar de soluciones de privacidad específicas de aplicaciones que solo requieren estado local (por ejemplo, pagos) a una privacidad programable de propósito general con estado compartido.

La programabilidad también se relaciona con tener herramientas granulares para divulgar selectivamente cierta información y revocar el acceso si es necesario (por ejemplo, cuando un empleado renuncia, queremos asegurarnos de que ya no tenga acceso a información específica de la empresa u otra información confidencial)

  1. Fortaleza de las garantías de privacidad - ¿Cuán confiable es la privacidad?

La pregunta clave es: ¿Qué tan seguro podemos estar de que lo que es privado hoy seguirá siéndolo en el futuro (privacidad hacia adelante) y cuáles son las garantías que respaldan esto?

Esto incluye cosas como:

  • ¿Qué información (si la hubiera) necesita compartir el usuario con un tercero o intermediario de confianza? ¿Qué garantías hay de que el intermediario se comporte como se espera?
  • ¿Qué tan grande es el conjunto protegido? (Multichain > Red (L1/L2) > Aplicación > Único activo)
  • ¿Cuáles son los riesgos de la censura? (Privacidad de la aplicación vs. la capa base)
  • ¿Es el sistema de prueba una prueba cuántica?
  • ¿El sistema de prueba requiere una configuración de confianza? Si es así, ¿cuántos participantes tuvo?
  • ¿El sistema tiene privacidad por defecto o hay otros incentivos para maximizar el número de interacciones dentro del conjunto blindado?

Como podemos ver arriba, esta categoría incluye tanto preguntas técnicas (por ejemplo, qué esquema de prueba se elige) como preguntas basadas en el diseño (por ejemplo, agregar incentivos que aumenten el tamaño del conjunto protegido).

¿Cómo se relaciona este marco de compensación con las cuatro preguntas presentadas al principio de la publicación?

  • ¿Qué se puede revelar y a quién si se desea? Esta pregunta se relaciona con lo que es privado y programabilidad. Si toda la información es pública por defecto, entonces la única opción que tienen los usuarios relacionada con la privacidad es si participar o no en la red. Necesitamos privacidad por defecto para tener la opción de revelar (como mínimo, privacidad frente a otros usuarios/observadores externos). La programabilidad se puede representar como reglas de divulgación granulares, es decir, a quién, cuándo, qué y cómo se revela (y se revoca) la información.
  • ¿Quién tiene el poder de revelar información? Esto está principalmente relacionado con la fortaleza de las garantías de privacidad y es más fuerte cuando solo el usuario tiene el poder de compartir información (privacidad minimizada de confianza).
  • ¿Qué debe revelarse y a quién para que el sistema funcione? Se relaciona principalmente con la programabilidad. Idealmente, es necesario revelar la menor cantidad de información posible mientras se pueda calcular sobre un estado compartido, tener composabilidad entre diferentes programas y construir nuevas relaciones de confianza. En la práctica, esto no es el caso (al menos hoy) y se deben hacer algunos compromisos.
    • Alejándonos por un segundo más allá de las cadenas de bloques, los ZKP podrían proporcionar un cambio de paradigma a este aspecto de la privacidad, ya que nos permiten demostrar que algo es cierto sin tener que revelar un exceso de información. Por ejemplo, cuando alquilamos un apartamento, tenemos que demostrar al posible propietario que tenemos ingresos suficientes para hacer frente a los pagos del alquiler. Hoy en día, esto requiere que enviemos nuestro extracto bancario completo, lo que revela mucha información adicional. En el futuro, esta relación de confianza podría construirse sobre la base de una ZKP sucinta.
  • ¿Qué garantías hay de que lo que es privado hoy seguirá siéndolo mañana? La noción de "privacidad hacia adelante" está mayormente relacionada con la fortaleza de las garantías de privacidad. Conjuntos blindados más grandes ayudarán con esto y harán que sea más difícil para los observadores externos extraer información. Confiar menos en intermediarios puede ayudar, pero no necesariamente, ya que incluso si los usuarios tienen el control total de sus datos, sus claves podrían filtrarse, los datos podrían revelarse involuntariamente o los datos revelados podrían ser copiados. Esta área sigue siendo relativamente inexplorada y poco estudiada, pero aumentará en importancia a medida que la privacidad en las redes de cadena de bloques sea más ampliamente adoptada.

Resumen

En última instancia, todo se reduce a quién debe tener el control sobre qué datos compartir: los usuarios o los intermediarios. Las cadenas de bloques intentan aumentar la soberanía individual, pero es una lucha desafiante ya que, en última instancia, el control es poder y las luchas de poder son desordenadas. Esto también se relaciona con el aspecto regulatorio y el cumplimiento, una de las principales razones por las que la privacidad no intermediada o minimizada por la confianza será un desafío (incluso si resolvemos los obstáculos técnicos).

Hoy en día, la discusión se centra ampliamente en la privacidad de los casos de uso financieros (pagos, transferencias, intercambios, etc.) - en parte porque es donde se produce la mayor adopción. Sin embargo, argumentaríamos que los casos de uso no financieros importan igual, si no más, que los financiarizados y no tienen el mismo pretexto cargado. Los juegos que requieren entradas o estados privados (póquer, batalla naval, etc.) o soluciones de identidad en las que el individuo quiere mantener su documento original seguro pueden actuar como poderosos incentivos para normalizar la privacidad en las redes blockchain. También existe la opción de tener diferentes niveles de privacidad dentro de la misma aplicación para diferentes transacciones o para revelar cierta información si se cumplen ciertas condiciones. La mayoría de estas áreas siguen siendo poco exploradas hoy en día.

En un mundo ideal, los usuarios tienen plena expresividad de lo que es privado y para quién, además de garantías sólidas de que lo programado como privado permanezca así. Analizaremos más de cerca las diferentes tecnologías que lo hacen posible y los compromisos entre ellas en la segunda parte de nuestra serie sobre privacidad.

La transición hacia la informática de propósito general en blockchains con mínima confianza y privacidad será larga y difícil, pero valdrá la pena al final.

Descargo de responsabilidad:

  1. Este artículo es reimpreso de [equilibrio], Título original [¿Qué queremos decir realmente cuando hablamos de privacidad en las redes blockchain (y por qué es difícil de lograr)?], Todos los derechos de autor pertenecen al autor original [Hannes Huitula]. Si hay objeciones a esta reimpresión, por favor contacte al Gate Learnequipo y lo resolverán rápidamente.
  2. Descargo de responsabilidad por responsabilidad: Las opiniones y puntos de vista expresados en este artículo son únicamente los del autor y no constituyen ningún consejo de inversión.
  3. Las traducciones del artículo a otros idiomas son realizadas por el equipo de Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.

¿Qué queremos decir en realidad cuando hablamos de privacidad en las redes de cadena de bloques?

AvanzadoAug 23, 2024
Este artículo argumenta que la privacidad en las redes de cadena de bloques es esencial para una adopción más amplia, en lugar de ser simplemente una característica deseable. Destaca los desafíos planteados por la transparencia actual de las cadenas de bloques y enfatiza que los diferentes usuarios y casos de uso requerirán diferentes niveles de privacidad, sugiriendo que un enfoque único no es suficiente.
¿Qué queremos decir en realidad cuando hablamos de privacidad en las redes de cadena de bloques?

Las opiniones y suposiciones subyacentes en esta pieza:

  • Algunas privacidad en las redes de cadena de bloques es algo indispensable, no algo opcional
  • La naturaleza transparente actual de las cadenas de bloques es un gran obstáculo para una mayor adopción
  • Diferentes usuarios y casos de uso requerirán diferentes niveles de privacidad. No todos los problemas necesitan ser resueltos con la misma herramienta.

¿Los usuarios individuales se preocupan por la privacidad?

Sí, pero algunos más que otros.

Todos se preocupan por la privacidad en cierto grado y todos hacemos suposiciones implícitas sobre la privacidad en nuestra vida diaria. Por ejemplo, al escribir un mensaje en un grupo de Slack de la empresa, asumes que solo tus compañeros de trabajo pueden ver los mensajes. De manera similar, muchos están de acuerdo con que la compañía de tarjetas de crédito o el banco puedan monitorear sus transacciones, pero no querrían difundir su historial de transacciones al resto del mundo.

Las corporaciones tienen razones adicionales para preocuparse por la privacidad (competitivas, de seguridad y regulatorias) y suelen tener una mayor disposición a pagar por ella en comparación con los usuarios individuales.

Otra pregunta importante es: ¿De quién quieren los usuarios privacidad?

  1. Otros usuarios de la red y observadores externos
  2. Terceros e intermediarios que facilitan el servicio
  3. Gobiernos, organismos gubernamentales y vigilancia masiva

El primero es absolutamente imprescindible para la mayoría de los casos de uso y ya es alcanzable en las redes de cadena de bloques hoy en día si aceptamos garantías más débiles (más sobre esto más adelante). El segundo es hacia lo que la industria está trabajando para dar más control a los usuarios y evitar que las empresas con modelos comerciales aprovechen nuestros datos sin permiso. El tercero, la privacidad frente a gobiernos y organismos gubernamentales, es el más complicado desde un punto de vista regulativo y político.

¿Cómo definimos "privacidad"?

La privacidad no es secreto. Un asunto privado es algo que uno no quiere que todo el mundo sepa, pero un asunto secreto es algo que uno no quiere que nadie sepa. La privacidad es el poder de revelarse selectivamente al mundo - Manifiesto de un Ciberpunk

La privacidad es un tema complejo que abarca varios temas separados (pero relacionados) como la soberanía de los datos (propiedad individual de los datos), la criptografía, etc. Además, las personas suelen utilizar el término de manera bastante laxa en diferentes contextos sin definiciones claras, lo que dificulta el razonamiento al respecto. Términos como confidencialidad (qué) y anonimato (quién) se utilizan a menudo indistintamente con la privacidad, aunque ambos son solo un subconjunto de las características de privacidad a las que aspirar.

Algunas preguntas clave sobre la privacidad son:

  • ¿Qué se puede revelar y a quién si se desea?
  • ¿Quién tiene el poder de revelar información?
  • ¿Qué se debe revelar y a quién para que el sistema funcione?
  • ¿Qué garantías hay de que lo que es privado hoy seguirá siéndolo mañana?

Basándonos en estas preguntas, podríamos resumirlo en una sola frase:

La privacidad se trata de que el usuario (propietario de los datos) tenga control sobre qué datos se comparten, con quién y bajo qué condiciones, junto con garantías sólidas de que lo que se programa para ser privado permanezca así.

¿Necesitamos una nueva terminología?

¿Considerando lo anterior, "privacidad" es un mal término para lo que estamos tratando de lograr? Quizás, quizás no. Depende de cómo te acerques a ello.

Por un lado, el término "privacidad" parece bastante binario (algo es privado o no), pero como hemos destacado anteriormente, es mucho más matizado que eso. Diferentes cosas pueden ser privadas (entrada, salida, programa interactuado, etc), algo puede ser privado para una persona pero público para otra, y hay una gama de suposiciones de confianza detrás de diferentes soluciones de privacidad. Además, el término tiene una connotación negativa que puede desviar la discusión del tema real.

Por otro lado, "privacidad" es un término conocido con presencia en la mente existente. Introducir nueva terminología puede ser confuso, especialmente si no hay consenso sobre qué nuevo término se debe usar. Intentar evitar el tema utilizando un término alternativo también parece algo deshonesto y deberíamos poder hablar de las cosas tal como son.

Como ingenieros de protocolos y constructores de redes de cadenas de bloques, mirar las cosas desde una nueva perspectiva puede ayudarnos a detectar nuevos problemas o resaltar vacíos en las soluciones actuales. Términos alternativos como control de flujo de información (utilizado en la literatura de privacidad más amplia) o divulgaciones programables (nuestra sugerencia) quizás capturen mejor el matiz. La información puede ser privada para algunos pero pública para otros, y depende de los usuarios decidir qué información se comparte con quién.

Sin embargo, nos mantendremos en el término privacidad en esta publicación para evitar confusiones innecesarias.

¿En qué se diferencia la privacidad en Web2 de las redes de blockchain?

La mayoría de los usuarios de Internet están familiarizados con la “privacidad” de la web2. Nuestros datos están encriptados durante la transmisión ( hasta el 95% de todo el tráfico hoy) y protegidos de otros usuarios, pero compartidos con intermediarios y proveedores de servicios de confianza. En otras palabras, la “privacidad” (de otros usuarios) proviene de confiar en un intermediario.

Este enfoque le da cierto control al usuario sobre con quién compartir sus datos más allá del proveedor de servicios. Sin embargo, se deposita mucha confianza (directa o indirectamente) en el proveedor de servicios para mantener los datos seguros y manejarlos adecuadamente. Además, las garantías limitadas y poca transparencia sobre cómo se utilizan los datos significa que los usuarios solo pueden esperar que los proveedores de servicios se comporten como afirman (modelo basado en la reputación).

Las redes de cadena de bloques tienen como objetivo reducir la dependencia de los intermediarios y proporcionar garantías más sólidas mediante el paso de un modelo basado en la reputación a garantías económicas o criptográficas. Sin embargo, el modelo distribuido también impone nuevos desafíos, especialmente para la privacidad. Los nodos necesitan sincronizarse y llegar a un consenso sobre el estado actual de la red, lo cual es relativamente fácil cuando todos los datos son transparentes y compartidos entre todos los nodos (estado actual). Esto se vuelve significativamente más difícil cuando comenzamos a cifrar los datos, una razón principal por la cual la mayoría de las redes de cadena de bloques son transparentes hoy en día.

¿Por qué es difícil lograr privacidad en las redes de cadenas de bloques?

Hay dos formas de lograr privacidad para las redes de cadena de bloques: privacidad confiable (intermediada) o privacidad de confianza minimizada (no intermediada).

Ambos son desafiantes, pero por diferentes razones (ideológicas vs técnicas). La privacidad confiable está más fácilmente disponible pero tiene garantías más débiles y requiere sacrificar parte de la ideología de las cadenas de bloques al depender de actores y intermediarios centralizados. La privacidad con una minimización de la confianza puede ofrecer garantías mucho más sólidas y asegurar que los usuarios mantengan el control de sus datos, pero es más difícil tanto desde un aspecto técnico como político (cómo cumplir con las regulaciones actuales).

Privacidad confiable en redes de cadena de bloques

El enfoque confiable se parece bastante a la privacidad de estilo web2 en el sentido de que puede lograr privacidad frente a otros usuarios, pero requiere confiar en un tercero o intermediario para facilitarlo. No es tan técnicamente exigente, lo que lo convierte en una opción pragmática para proyectos que requieren algunas garantías de privacidad hoy en día, pero son sensibles al costo y tienen transacciones de menor valor. Un ejemplo de esto son los protocolos sociales web3 (como Red de lentes), que pone más énfasis en el rendimiento y la practicidad que en la dureza de las garantías de privacidad.

Un enfoque simple es usar un validiumdonde un comité de disponibilidad de datos (DAC) mantiene el estado actual y los usuarios confían en los operadores de DAC para mantener ese estado privado y actualizarlo según sea necesario. Otro ejemplo es Extensión del token de Solana, que logra la confidencialidad de los pagos (ocultando saldos de cuentas y transacciones) mediante ZKPs pero permite designar a un tercero de confianza con derechos de auditoría para garantizar el cumplimiento normativo.

Argumentaríamos que este modelo puede extender el paradigma web2 actual donde solo confías en un intermediario para cumplir las reglas. Con las cadenas de bloques, el modelo de confianza pura puede combinarse con algunas garantías adicionales (económicas o criptográficas) de que los intermediarios se comportarán como se espera, o al menos aumentarán el incentivo para hacerlo.

También existen soluciones híbridas en las que una solución con un mínimo de confianza depende de un componente centralizado para mejorar el costo, la UX o el rendimiento. Ejemplos en esta categoría incluyen la externalización de la demostración de ZKPs privados a un único demostrador, o una red FHE en la que un intermediario centralizado tiene la clave de descifrado.

(Incluimos las blockchains con permisos en la categoría de confiables, pero todas las demás soluciones se refieren a blockchains sin permisos).

Privacidad Minimizada de Confianza en Redes de Cadena de Bloques

El enfoque de minimización de la confianza evita tener un único punto de falla a través de un intermediario de confianza que puede ofrecer garantías más sólidas. Sin embargo, es mucho más difícil de implementar desde un punto de vista técnico. En la mayoría de los casos, requiere una combinación de soluciones de criptografía moderna y cambios estructurales como el uso de una estructura de cuenta diferente.

Las soluciones existentes se centran principalmente en casos de uso especializados, como:

  • Financiero: las transferencias privadas, los pagos y los intercambios tienen como objetivo ocultar la identidad, la entrada y/o la salida (quién envió qué, cuánto y a quién). Los compromisos entre diferentes soluciones incluyen piscinas protegidas de un solo activo frente a piscinas protegidas de varios activos y cuánto es privado. Los ejemplos aquí incluyen Zcash, Namada, y Penumbra.
  • Identidad: La privacidad es un requisito indispensable para cualquier solución que requiera conectar nuestra identidad fuera de la cadena con nuestra identidad en la cadena o intentar almacenar documentos de identidad en la cadena de bloques. Existen varios intentos por parte del sector privado (como,Prueba de PasaporteyHolónimojunto coninterés creciente por los gobiernospara apoyar soluciones de identidad digital que preserven la privacidad.
  • Gobernanza: La idea de la votación privada en cadena es ocultar quién votó qué y mantener el recuento total en privado hasta el final de la votación, de modo que no influya en la decisión de voto de ningún individuo. El gráfico a continuación enumera algunos ejemplos con características variables y suposiciones de confianza:

  • Resumen de algunas soluciones existentes (origen)

Muchos casos de uso, sin embargo, dependen de un estado compartido y se vuelve mucho más desafiante cuando intentamos extender la privacidad minimizada de confianza a estos casos de uso de propósito general.

Otra cosa a tener en cuenta es que si bien los casos de uso especializados (pagos, votaciones, identidad, etc.) pueden funcionar bien de forma aislada, requieren que los usuarios se muevan entre conjuntos protegidos (zonas de confianza) para diferentes casos de uso. Esto no es óptimo ya quela mayoría de la información se filtracuando se mueve dentro y fuera de un conjunto blindado.

Por lo tanto, el objetivo debería ser permitir la privacidad para la computación de propósito general (todos los casos de uso, incluidos aquellos que requieren estado compartido), expandir el conjunto protegido y agregar controles de gestión de acceso granulares (expresividad).

¿Cómo podemos evaluar diferentes soluciones?

Si bien el objetivo final está claro, el camino para llegar allí es largo. Mientras tanto, necesitamos marcos para evaluar las soluciones actuales y los compromisos que hacen. Creemos que el espacio de compromiso se puede dividir en tres categorías principales:

  1. ¿Qué es privado - Diferentes tipos de privacidad relacionados con las cadenas de bloques:
  1. Entradas privadas (mensajes)
  2. Salidas privadas (cambios de estado)
  3. Contrapartes privadas
    1. Usuarios
    2. Función
    3. Programa

Cuanto más casillas pueda marcar una solución, mejor. Idealmente, tendrías todas ellas, pero esto a menudo requiere hacer algunos compromisos. La diferencia entre la función y la privacidad del programa es que algunos sistemas permiten ocultar qué función se llamó (por ejemplo, qué lógica de oferta utilizó el usuario), pero aún revelan el programa con el que interactuó el usuario. La privacidad del programa es una forma más estricta de esto, donde todas las llamadas a función son privadas junto con el programa con el que se interactuó. Esta categoría también es donde se encuentra la discusión sobre el anonimato (quién) versus la confidencialidad (qué)

Es importante tener en cuenta que el usuario tiene la opción de revelar selectivamente algunos (o todos) de estos a ciertas partes, pero si ninguno de ellos es privado por defecto, entonces el usuario no tiene esa opción.

  1. Programabilidad: ¿Para qué puedes usar la privacidad?

Esta categoría se centra en la programabilidad de la computación privada y en cuáles son sus limitaciones:

  • ¿Se puede calcular sobre datos cifrados? ¿Existe alguna componibilidad entre los programas privados?
  • ¿Pueden los estados privados y públicos interactuar de alguna manera? ¿Cuáles son las limitaciones y compensaciones de esto?
  • ¿Qué límites hay en cuanto a la complejidad de los programas que se pueden tener (límites de gas, expresividad, etc)?

Como se mencionó anteriormente, muchas aplicaciones (en el mundo real) requieren un estado compartido, lo cual es difícil de lograr de manera descentralizada y confiable. Existe mucho trabajo e investigación en esta área para ayudarnos a pasar de soluciones de privacidad específicas de aplicaciones que solo requieren estado local (por ejemplo, pagos) a una privacidad programable de propósito general con estado compartido.

La programabilidad también se relaciona con tener herramientas granulares para divulgar selectivamente cierta información y revocar el acceso si es necesario (por ejemplo, cuando un empleado renuncia, queremos asegurarnos de que ya no tenga acceso a información específica de la empresa u otra información confidencial)

  1. Fortaleza de las garantías de privacidad - ¿Cuán confiable es la privacidad?

La pregunta clave es: ¿Qué tan seguro podemos estar de que lo que es privado hoy seguirá siéndolo en el futuro (privacidad hacia adelante) y cuáles son las garantías que respaldan esto?

Esto incluye cosas como:

  • ¿Qué información (si la hubiera) necesita compartir el usuario con un tercero o intermediario de confianza? ¿Qué garantías hay de que el intermediario se comporte como se espera?
  • ¿Qué tan grande es el conjunto protegido? (Multichain > Red (L1/L2) > Aplicación > Único activo)
  • ¿Cuáles son los riesgos de la censura? (Privacidad de la aplicación vs. la capa base)
  • ¿Es el sistema de prueba una prueba cuántica?
  • ¿El sistema de prueba requiere una configuración de confianza? Si es así, ¿cuántos participantes tuvo?
  • ¿El sistema tiene privacidad por defecto o hay otros incentivos para maximizar el número de interacciones dentro del conjunto blindado?

Como podemos ver arriba, esta categoría incluye tanto preguntas técnicas (por ejemplo, qué esquema de prueba se elige) como preguntas basadas en el diseño (por ejemplo, agregar incentivos que aumenten el tamaño del conjunto protegido).

¿Cómo se relaciona este marco de compensación con las cuatro preguntas presentadas al principio de la publicación?

  • ¿Qué se puede revelar y a quién si se desea? Esta pregunta se relaciona con lo que es privado y programabilidad. Si toda la información es pública por defecto, entonces la única opción que tienen los usuarios relacionada con la privacidad es si participar o no en la red. Necesitamos privacidad por defecto para tener la opción de revelar (como mínimo, privacidad frente a otros usuarios/observadores externos). La programabilidad se puede representar como reglas de divulgación granulares, es decir, a quién, cuándo, qué y cómo se revela (y se revoca) la información.
  • ¿Quién tiene el poder de revelar información? Esto está principalmente relacionado con la fortaleza de las garantías de privacidad y es más fuerte cuando solo el usuario tiene el poder de compartir información (privacidad minimizada de confianza).
  • ¿Qué debe revelarse y a quién para que el sistema funcione? Se relaciona principalmente con la programabilidad. Idealmente, es necesario revelar la menor cantidad de información posible mientras se pueda calcular sobre un estado compartido, tener composabilidad entre diferentes programas y construir nuevas relaciones de confianza. En la práctica, esto no es el caso (al menos hoy) y se deben hacer algunos compromisos.
    • Alejándonos por un segundo más allá de las cadenas de bloques, los ZKP podrían proporcionar un cambio de paradigma a este aspecto de la privacidad, ya que nos permiten demostrar que algo es cierto sin tener que revelar un exceso de información. Por ejemplo, cuando alquilamos un apartamento, tenemos que demostrar al posible propietario que tenemos ingresos suficientes para hacer frente a los pagos del alquiler. Hoy en día, esto requiere que enviemos nuestro extracto bancario completo, lo que revela mucha información adicional. En el futuro, esta relación de confianza podría construirse sobre la base de una ZKP sucinta.
  • ¿Qué garantías hay de que lo que es privado hoy seguirá siéndolo mañana? La noción de "privacidad hacia adelante" está mayormente relacionada con la fortaleza de las garantías de privacidad. Conjuntos blindados más grandes ayudarán con esto y harán que sea más difícil para los observadores externos extraer información. Confiar menos en intermediarios puede ayudar, pero no necesariamente, ya que incluso si los usuarios tienen el control total de sus datos, sus claves podrían filtrarse, los datos podrían revelarse involuntariamente o los datos revelados podrían ser copiados. Esta área sigue siendo relativamente inexplorada y poco estudiada, pero aumentará en importancia a medida que la privacidad en las redes de cadena de bloques sea más ampliamente adoptada.

Resumen

En última instancia, todo se reduce a quién debe tener el control sobre qué datos compartir: los usuarios o los intermediarios. Las cadenas de bloques intentan aumentar la soberanía individual, pero es una lucha desafiante ya que, en última instancia, el control es poder y las luchas de poder son desordenadas. Esto también se relaciona con el aspecto regulatorio y el cumplimiento, una de las principales razones por las que la privacidad no intermediada o minimizada por la confianza será un desafío (incluso si resolvemos los obstáculos técnicos).

Hoy en día, la discusión se centra ampliamente en la privacidad de los casos de uso financieros (pagos, transferencias, intercambios, etc.) - en parte porque es donde se produce la mayor adopción. Sin embargo, argumentaríamos que los casos de uso no financieros importan igual, si no más, que los financiarizados y no tienen el mismo pretexto cargado. Los juegos que requieren entradas o estados privados (póquer, batalla naval, etc.) o soluciones de identidad en las que el individuo quiere mantener su documento original seguro pueden actuar como poderosos incentivos para normalizar la privacidad en las redes blockchain. También existe la opción de tener diferentes niveles de privacidad dentro de la misma aplicación para diferentes transacciones o para revelar cierta información si se cumplen ciertas condiciones. La mayoría de estas áreas siguen siendo poco exploradas hoy en día.

En un mundo ideal, los usuarios tienen plena expresividad de lo que es privado y para quién, además de garantías sólidas de que lo programado como privado permanezca así. Analizaremos más de cerca las diferentes tecnologías que lo hacen posible y los compromisos entre ellas en la segunda parte de nuestra serie sobre privacidad.

La transición hacia la informática de propósito general en blockchains con mínima confianza y privacidad será larga y difícil, pero valdrá la pena al final.

Descargo de responsabilidad:

  1. Este artículo es reimpreso de [equilibrio], Título original [¿Qué queremos decir realmente cuando hablamos de privacidad en las redes blockchain (y por qué es difícil de lograr)?], Todos los derechos de autor pertenecen al autor original [Hannes Huitula]. Si hay objeciones a esta reimpresión, por favor contacte al Gate Learnequipo y lo resolverán rápidamente.
  2. Descargo de responsabilidad por responsabilidad: Las opiniones y puntos de vista expresados en este artículo son únicamente los del autor y no constituyen ningún consejo de inversión.
  3. Las traducciones del artículo a otros idiomas son realizadas por el equipo de Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.
Empieza ahora
¡Regístrate y recibe un bono de
$100
!