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?
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.
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:
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í.
¿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.
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.
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).
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).
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:
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).
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:
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.
Esta categoría se centra en la programabilidad de la computación privada y en cuáles son sus limitaciones:
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)
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:
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).
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.
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?
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.
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:
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í.
¿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.
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.
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).
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).
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:
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).
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:
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.
Esta categoría se centra en la programabilidad de la computación privada y en cuáles son sus limitaciones:
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)
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:
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).
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.