Los planes y caracteristicas de la privacidad en Decred están listos para ser revelados. Y nuestro objetivo es que sean simples, adaptables y creativas.
En lugar de seguir las rutas establecidas por proyectos que tienen gran enfoque en la privacidad, p. Ej. circulos de firmas (Ring Signature - utilizada en Monero), zk-SNARKs o Mimblewimble (Grin), decidimos poner atención en adoptar un mixnet, integrandolo a nuestro sistema de gobernanza en "PoS" (prueba de participación). Actualmente, poco más del 50% de DCRs en circulación participan en PoS, lo que requiere un flujo constante de compra de tickets. Este flujo de transacciones existente, exclusivo de Decred, funciona como base natural para un mixnet. Según el enfoque con el sistema de gobernanza PoS, esto produce un escenario de "matar muchos pájaros de un tiro"
: los stakeholders obtienen anonimato y simultáneamente crean un volumen de fondo sustancial con el que las personas que no son stakeholders puedan mezclar sus transacciones regulares. Aquí hay un resumen del alto rendimiento del mixnet de Decred:
- Se basa en el protocolo CoinShuffle++ del "P2P Mixing and Unlinkable Bitcoin Transactions" de Ruffing, Moreno-Sanchez y Kate.
- El proceso de mezcla (mixer) está integrado con el proceso de compra de tickets, por lo que los stakeholders que ejecutan sus billeteras con esta función pueden obtener los tickets de manera anónima.
- Además de tener una denominación basada en el precio actualizado del ticket, se utilizan denominaciones fijas más pequeñas para mezclar el cambio y las transacciones regulares.
- El cambio en el proceso de mezcla requiere un manejo especial para evitar vincular las salidas de las transacciones no gastadas ("UTXO").
- Hay un aumento aproximado de 12 veces en el almacenamiento de transacciones dentro de la cadena (on-chain) cuando se usa la privacidad.
- La versión inicial es solo un interfaz de línea de comandos ("CLI") y solo admitirá transacciones con y sin staking.
A continuación en este artículo, mencionaré la motivación detrás de las decisiones que se tomaron para llegar a este sistema, cómo funciona con a más detalle y cuáles son los próximos pasos después de esta versión inicial.
El trabajo para integrar la privacidad en Decred se ha mantenido en secreto desde a mediados del 2017, y esto merece una clara explicación. En ese momento, había hecho la observación de que tanto Monero como Zcash, aunque proporcionaban una privacidad sustancial, percibí un problema grave: no pueden eliminar las transacciones históricas de sus nodos completos, es decir, podar (reducir el espacio), porque no es posible saber si una salida de transacción ("TXO") se gasta o no. Aunque está claro que ambos proyectos sintieron que esto no era un problema serio, mi pensamiento era que esto sería un problema masivo para la sustentabilidad a largo plazo. Una blockchain tendrá dificultades para funcionar como una reserva de valor si está demasiado pesada para descargarla y replicarla fácilmente, lo que reduce su seguridad. Parecía que la mayoría de las personas en el espacio de criptomonedas no compartían esta opinión, por lo que sentí que era mejor retener mis críticas, en lugar de hacerlas públicas e indicarle a otra persona que implementará alguna solución.
Más allá de esta preocupación y que fue una mala decisión de ingeniería a largo plazo que podría afectar negativamente la sostenibilidad, a pesar de ser buena para ejecutar a corto plazo, me preocupaba la complejidad de ambos enfoques. Los circulos de firma tienen una complejidad moderada y las zk-SNARK tienen una complejidad alta, lo cual me indicó que debía encontrar un enfoque más simple que no rompiera la poda. Inicialmente, había planeado implementar TumbleBit del documento “TumbleBit: An Untrusted Bitcoin-Compatible Anonymous Payment Hub” de Heilman, AlShenibr, Baldimtsi, Scafuro y Goldberg. Entre el invierno del 2017 y la primavera del 2018, Mikhail Belopuhov, un desarrollador con una experiencia sustancial estaba trabajando en proyectos de ingeniería criptográfica, implementó TumbleBit en Go. Una vez que se completó su implementación inicial, llegó el momento de integrar el código, me di cuenta de las deficiencias de TumbleBit, al saber que el servidor de mezcla es vulnerable a ataques de denegación de servicio ("DoS") y que la contramedida (comprobantes de tarifas anónimos) significaba agregar más código y más complejidad. A pesar de no integrar el código TumbleBit en Decred, estamos lanzando este código para beneficio público.
Fue en este punto que pensé que era mejor echar un vistazo de cerca al protocolo CoinShuffle++ de "P2P Mixing and Unlinkable Bitcoin Transactions" de Ruffing, Moreno-Sanchez y Kate, que encontré sustancialmente menos complejo que TumbleBit. CoinShuffle++ se basa en primitivas criptográficas comunes, p. Ej. intercambios de claves, claves de sesión, funciones hash, firmas y aritmética de campos finitos. Después de observar de cerca CoinShuffle++, quedó claro que era más simple y más resistente a DoS que TumbleBit, por lo que pivotamos y buscamos CoinShuffle++. El código simple y las primitivas simples significan menos cosas para romper y/u obtener resultados no deseados. Debido a las limitaciones de los recursos de ingeniería, este trabajo no comenzó hasta diciembre del 2018 y ahora está listo para ser publicado después de varios meses de trabajo.
CoinShuffle++ aborda solo el componente de trazabilidad de la privacidad, sin abordar el problema de los montos de las transacciones. Dado que CoinShuffle++ no requirió ningún cambio de consenso, este trabajo se pudo completar en privado. No se puede decir lo mismo de las técnicas para ofuscar los montos de las transacciones. Para hacerlo, deben ocurrir cambios de consenso, y estos deben ocurrir como parte de un proceso público con Decred, según la voluntad de los stakeholders.
Decred se basa en los principios de la seguridad de la cadena de bloques, la gobernanza incorporada y una recompensa en bloque de autofinanciamiento que lo convierte en una reserva superior de valor. Con estos fundamentos en su lugar, estamos ansiosos por desarrollar funciones de privacidad que mejorarán la seguridad de nuestros usuarios. A pesar de que se requiere un proceso público para ofuscar los montos de las transacciones, soy de la opinión de que el tema de la trazabilidad es mucho más importante cuando se trata de la seguridad de nuestros stakeholders, quienes experimentarán una ganancia sustancial de privacidad como resultado.
Decred ha implementado una variante de CoinShuffle++ en su billetera. Aunque es posible realizar este proceso de manera totalmente peer-to-peer ("P2P"), que pasa por alto las restricciones que provienen del enrutamiento a través de la internet pública, por lo que hemos creado un servidor, csppserver, y se ha integrado el cliente de dcrwallet. Con el fin de brindar una comprensión más profunda de cómo funciona CoinShuffle++, trabajaremos con un ejemplo simple que ilustra el concepto detrás del proceso. Además de lo que se describe en el documento, hay una denominación sólida y un manejo de cambios integrado en la billetera, y está configurado para manejar tanto las transacciones regulares como la compra de tickets. Hay un par de limitaciones notables para esta versión inicial, ya que es solo CLI, requiere una configuración, y un atacante puede deshacer las mezclas que pueden romper el problema del logaritmo discreto ("DLP"). Se espera que aproximadamente el 12.5% de todos los Decreds en circulación hagan uso de la privacidad en pocos meses. Para usar la privacidad en la configuración de dcrwallet requiere editar el archivo de configuración.
CoinShuffle++ es un proceso sin custodia para crear transacciones CoinJoin, donde las direcciones de salida se convierten en anonimas a través de un mixnet. El proceso mediante el cual las direcciones de salida son anonimas se llama DiceMix Light, que es una iteración de Ruffing del proceso DiceMix propuesto originalmente en el documento CoinShuffle++. Ten en cuenta que el CoinJoin que se produce filtra las entradas y direcciones de cambio que pertenecen a este par del servidor, pero no a los otros pares que participan en la mezcla. Las direcciones de salida son completamente anónimas, de modo que ninguno de los pares o el servidor pueden saber qué salida pertenece a qué par. Las mezclas ocurren de forma episódica en épocas, con la época inicial de la red principal establecida en 20 minutos (1200 segundos).
La arquitectura cliente-servidor que elegimos esta enfocado en común para la infraestructura de la red, principalmente porque la traducción de direcciones de red significa que es posible que no puedas comunicarte directamente con otros pares con los que se está mezclando. Este problema es muy común y se reduce a una cuestión de reenvío en los puertos. Además, el uso de P2P directo significaría que todos los pares verían la IP pública de los demás, lo que no es bueno para la privacidad. El servidor, csppserver, requiere acceso JSON-RPC a dcrd, el servicio de consenso de Decred, todo esto para verificar que las TXO no se hayan gastado.
El csppserver inicial se alojará en cspp.decred.org, pero es posible ejecutar su propio servidor. Ejecutar su propio servidor tendrá una utilidad limitada porque el objetivo es obtener la mayor cantidad posible de pares en cada combinación, por lo que recomendamos no hacerlo. Hay planes para hacer que el servidor tenga alta disponibilidad en el futuro.
Para comprender cómo funciona el protocolo DiceMix, es necesario trabajar a través de un algoritmo simplificado, llamado “Secure Sum”. Este ejemplo usa 3 pares, pero es sencillo extender este proceso a un número arbitrario de pares.
Supón que Alice, Bob y Carol tienen cada uno un número y quieren calcular la suma de todos esos números, pero cada uno de ellos quiere evitar que sus compañeros sepan cuáles son los números de los demás.
- Alice divide su número como A1 + A2 + A3
- Bob divide su número como B1 + B2 + B3
- Carol divide su número como C1 + C2 + C3.
- Alice luego envía A2 a Bob y A3 a Carol
- Bob envía B1 a Alice y B3 a Carol
- Y Carol envía C1 a Alice y C2 a Bob.
- Alice calcula A1 + B1 + C1,
- Bob calcula A2 + B2 + C2
- Carol calcula A3 + B3 + C3
- luego todos transmiten sus respectivas sumas parciales a los demás compañeros. Cada uno de ellos ahora puede calcular la suma de todos los números sumando las sumas parciales, y ningún par sabe cuál era el número de cada uno, asumiendo que no hay colusión.
El truco que se usa en el ejemplo anterior es "la suma de las sumas horizontales es igual a la suma de las sumas verticales", lo cual es evidente si escribe las particiones:
Con DiceMix, se agrega complejidad adicional, pero el concepto central sigue siendo el mismo. DiceMix implica que cada par crea un vector de los exponentes de su dirección de pago, agrega términos de relleno a cada componente del vector que se basan en las claves de sesión por pares del proceso de intercambio de claves, suma estos vectores de cada par para crear un sistema de ecuaciones, y luego resolviendo el sistema de ecuaciones para las direcciones de pago. El truco aquí es que los términos de relleno se eligen de manera que se cancelen, ya que se suman en los vectores de todos los pares. Una vez que tenemos una lista anónima de direcciones de pago, se produce un proceso CoinJoin estándar con los pares.
DiceMix hace anonimas las direcciones de salida para una transacción CoinJoin, pero no hace que las salidas sean indistinguibles. Para que esto sea posible, deben tener una denominación fija para cada mezcla. La necesidad de denominaciones de salida fijas se señaló en el documento técnico de CryptoNote en 2012, por lo que es bien conocido la necesidad de cantidades de salida idénticas para preservar la privacidad. Las denominaciones utilizadas para Decred son el precio actual del ticket (más una tarifa) y varias denominaciones fijas por debajo del precio del ticket. El precio cambia cada 144 bloques, aproximadamente cada 12 horas, por lo que esta denominación cambia con el tiempo. Si el precio cambia durante una época, la combinación se cancela y los pares se suscriben a la siguiente combinación.
Como es típico en el mundo de la criptografía y la privacidad, "todo está en los detalles", y el cambio de las mezclas de CoinShuffle++ no es una excepción a esta regla. CoinShuffle++ hace un buen trabajo al poner anonimas las direcciones de salida, pero si el cambio no se maneja con cuidado, puede vincular UTXO mixtas y no mezcladas. En muchos casos, las salidas de cambio se pueden vincular a sus entradas haciendo un análisis de suma parcial, p. un subconjunto de entradas suma 12.34, una salida anónima de 10, una tarifa de 0.001 y un cambio de 2.339. Esto significa que si el cambio de 2.339 incluye como entrada con salidas anónimas, crea un vínculo entre las entradas que suman 12.34 y esas salidas anónimas, reduciendo o eliminando por completo la privacidad que hemos trabajado para crear. Para hacer frente a esta amenaza, puede cambiar los flujos mixtos a una cuenta de billetera separada, donde luego se mezcla en denominaciones más pequeñas hasta que el cambio sea menor a la denominación de mezcla más pequeña.
Las denominaciones fijas se eligieron para equilibrar el tamaño promedio de almacenamiento de transacciones en cadena, la calidad de la mezcla y la facilidad de realizar multiplicaciones. Si asumimos que las denominaciones usan la base N y hay M denominaciones, en el peor de los casos, habrá N-1 salidas de una denominación dada, y M x (N - 1) salidas totales de una única entrada de cambio. Para la base 10, esto significa que una cantidad de cambio de 99.999 requeriría hasta 5 x (10 - 1) = 45 salidas mixtas, por lo que puede esperar un aumento de aproximadamente 22 veces en el almacenamiento de transacciones en cadena. Hemos optado por trabajar en base 4, con 8 denominaciones por debajo del tamaño del ticket, por lo que un cambio en el peor de los casos requeriría 8 x (4 - 1) = 24 salidas, creando un aumento de aproximadamente 12 veces en el almacenamiento en cadena. Se han incluido 2 denominaciones adicionales por encima del precio, pero esperamos que reciban un uso limitado. La denominación más pequeña es 4^9 atoms = 0.00262144 y la que está debajo del tamaño actual del ticket es 4^16 atoms = 42.94967296.
Este código inicial solo es compatible con CLI wallet, dcrwallet y solo stakers, es decir, no funciona con proveedores de servicios de votación ("VSP") y transacciones regulares. Obviamente, estamos interesados en extender el soporte para la privacidad a las billeteras GUI, p. Decrediton y hacer que funcione con los VSP. El desafío con las billeteras GUI es en la experiencia del usuario ("UX"), ya que el proceso de mezclar los pagos recién recibidos o el cambio requiere que la billetera se desbloquee durante períodos de tiempo más largos, p. Decenas de minutos. Los VSP crean un desafío más sustancial porque los usuarios tienen una noción de identidad cuando registran una cuenta en un VSP, y cada cuenta tiene un script de firma múltiple fijo de 1 de 2. En el caso de que un atacante pueda romper DLP y haya grabado pasivamente todas las comunicaciones entre los clientes mixtos y el servidor, puede revelar la vinculación entre las entradas, salidas y cambios. Tenga en cuenta que no hay riesgo de que un atacante de este tipo provoque una inflación silenciosa.
Un aspecto importante a tomar en cuenta de la privacidad es lo que los usuarios pueden esperar obtener de ella, particularmente en el contexto de la privacidad opcional. Al precio actual del ticket que es de ~128 DCR, la compra en estado estable requiere que nuestros interesados (stakeholders) gasten 128 DCR x 5 tickets por bloque x 288 bloques por día = 184 320 DCR al día. Actualmente hay aproximadamente 10 282,000 DCR en circulación, por lo que esta compra en estado estable representa aproximadamente el 1.8% de la emisión total que se utiliza para comprar tickets cada día. Aproximadamente el 50% de todas las entradas son bloqueadas en modo solo, se estima que el 50% del bloqueo individual hará uso de la privacidad, y aproximadamente el 50% de todas los tickets se bloquearan en participación, lo que significa que una estimación del 12,5% de todas los tickets de Decred utilizará la privacidad a través de esta liberación de privacidad inicial. Es probable que la participación demore unos meses en alcanzar este nivel porque los tickets se llaman para votar lentamente con el tiempo y solo los nuevos pueden optar por usar la privacidad.
Tanto los stakeholders como quienes no lo son, pueden utilizar el sistema de privacidad y confiar en un flujo constante de transacciones mixtas, ya que hemos integrado estas transacciones con el flujo constante al comprar tickets de nuestro sistema de gobernanza. El sistema descrito anteriormente, los usuarios que opten por la privacidad podrán recibir y gastar pagos con una negación saludable y plausible, y la situación solo mejorará a medida que mejoremos la UX y aumentemos el nivel de participación. Los observadores pasivos externos podrán ver que se gastan colecciones de UTXO mixtas, pero no podrán vincular esas transacciones a una identidad.
Con toda esta explicación sobre cómo funciona la privacidad, algunos lectores seguramente están ansiosos por configurarla y hacerlo funcionar. Se deben establecer varias opciones nuevas en dcrwallet.conf:
csppserver = cspp.decred.org: 15760 - Este es el FQDN y el puerto que csppserver está escuchando.
csppserver.ca = cspp.decred.org.pem: este es el certificado de CA para el csppserver.
purchaseaccount = mixed: establece la cuenta desde la que comprará los tickets.
mixaccount = mixed / 1 - A medida que ocurren las mezclas, las direcciones de salida mixtas vendrán de esta cuenta.
changeaccount = unmixed: cada conjunto de entradas de mezcla utiliza una dirección de cambio de esta cuenta.
mixchange = 1: esto le dice a dcrwallet que mezcle los pagos para cambiar la cuenta en la cuenta mixta.
ticketbuyer.votingaccount = vote - Esto le dice a la billetera qué cuenta usar al configurar las direcciones de votación de los tickets de votación.
Además de configurar estas nuevas opciones en dcrwallet.conf, se deben crear dos nuevas cuentas: mixtas y sin mezclar. Si su billetera para comprar tickets también vota, la cuenta de votación se puede crear localmente, o bien, puede importar una clave pública extendida para una cuenta de votación desde una billetera de votación externa.
Los stakeholders que ejecutan un comprador de tickets querrán configurar un segundo ya que se ejecutará en paralelo, donde las configuraciones son tales que los tickets recién comprados en la primera billetera tienen la rama 0 de la cuenta mixta de la segunda billetera configurada como su cuenta mixta. Las grandes partes interesadas pueden tardar hasta el vencimiento completo del ticket aproximadamente 4.7 meses para migrar completamente a la nueva billetera mixta. Los no interesados pueden establecer estas opciones, dejando fuera la cuenta de compra y participar en la mezcla sin comprar. Para recibir pagos, puede generar nuevas direcciones desde la cuenta sin mezclar, luego esos pagos se mezclarán en la cuenta mixta.
Tenga en cuenta que el proceso de mezcla requiere que la billetera se desbloquee durante períodos de tiempo más largos, de modo que pueda participar en una mezcla, que ocurre cada 20 minutos. Las billeteras de los compradores de tickets ya se encuentran desbloqueadas, pero las billeteras que no son de participación deberán dejarse desbloqueadas el tiempo suficiente para completar sus mezclas.
Queda bastante trabajo por hacer para mejorar la privacidad, tanto en términos de como agregar la versión de privacidad inicial. La UX para carteras GUI, p. Ej. Decrediton, requiere integración tanto en los componentes de la GUI como en dcrwallet. Volver a configurar los VSP para que sean compatibles con la privacidad requiere pasar de un sistema basado en cuentas a un sistema basado en tickets directos, requiriendo la modificación de dcrstakepool y dcrwallet. Esta versión inicial se basa en un proceso de servidor único, pero podemos reemplazarlo con un clúster o un mempool de mezcla en dcrd. Después de ver la complejidad que surge del manejo de cambios, la adición del soporte de transacciones confidenciales ("CT") sería el siguiente paso natural, que requeriría un cambio de consenso. Dado que el proceso de mezcla no ocurre en la cadena, es posible modificar DiceMix para que admita la criptografía post-cuántica ("PQ"), lo que haría que la mezcla sea segura contra un atacante que pudiera romper la DLP.
Como se mencionó anteriormente, hay algunos cambios que se deben realizar en dcrwallet para que la UX de la mezcla con Decrediton sea aceptable. El problema aquí es que una época del orden de 20 minutos requiere que una billetera mixta esté lista para firmar la transacción CoinJoin durante al menos esa cantidad de tiempo. La opción simple es dejar la billetera completa desbloqueada durante un período prolongado, pero esta es una mala práctica de seguridad. Con algo de trabajo, es posible hacer que dcrwallet desbloquee solo una cuenta a la vez, p. Ej. la cuenta sin mezclar y hacer que todas las RPC de la billetera que implican la firma requieran explícitamente la frase de contraseña. Una vez que se realicen estos cambios, la integración del soporte para la privacidad en Decrediton debería ser sencilla.
Los VSP actualmente operan por cuenta, p. Ej. tiene un inicio de sesión, una dirección de firma múltiple fija 1 de 2 para esa cuenta y un solo conjunto de preferencias de votación, pero para respaldar la privacidad de manera adecuada, los VSP deben operar por ticket. Esto requiere que los usuarios envíen una clave privada individual por ticket al VSP, las tarifas correspondientes se pagarán directamente y las preferencias de tickets se establecen por ticket. Además, sería ideal si los tickets se delegaran a los VSP a través de Tor o similar. Esto requiere cambios tanto en dcrwallet como en dcrstakepool. Dado que aproximadamente el 50% de las entradas están en poder de los VSP, esto debería traducirse en una duplicación aproximada del uso de la privacidad, del 12.5% al 25% de Decreds en circulación.
Es sencillo operar un solo servidor de mezcla, pero no es una configuración particularmente resistente, aunque es suficiente para manejar un volumen de transacciones sustancial. Una configuración más resistente a largo plazo sería un clúster de alta disponibilidad, o incluso la integración del servidor en dcrd, creando un mempool de mezcla. Puede haber razones para no integrar esto en dcrd, por lo que se requiere más investigación.
La complejidad y el aumento del almacenamiento de transacciones en cadena necesarios para manejar adecuadamente los cambios con CoinShuffle ++ es una buena motivación para considerar agregar la ofuscación de los montos de las transacciones. La ofuscación de cantidades hace que todo el análisis de "suma sum" y la correspondiente mezcla basada en la denominación queden obsoletos. Esto conduce a una sola transacción de mezcla por época, en lugar de varias transacciones separadas de varias denominaciones. Convenientemente, hay un documento “Mezcla de transacciones confidenciales: privacidad integral de transacciones para Bitcoin” de Ruffing y Moreno-Sánchez, que cubre exactamente esta mejora. Si se utilizan Bulletproofs ("BP"), el tamaño de las transacciones que utilizan CT es tal que es probable que esto reduzca los requisitos de almacenamiento.
Una preocupación válida acerca de CT es que un atacante que puede romper DLP puede crear una inflación silenciosa, lo que sería desastroso para el sistema de gobernanza de Decred PoS y su capacidad de servidor como reserva de valor. Si bien existen argumentos válidos basados en información pública de que todavía faltan muchos años para que una computadora cuántica a gran escala funcione, existe un incentivo masivo para que los gobiernos de los estados nacionales más grandes desarrollen dicha tecnología en secreto y la utilicen para descifrar una amplia variedad de datos cifrados. Los autores de BP sugieren en la sección 4.9 que es posible implementar BP que se ocultan computacionalmente y son perfectamente vinculantes, en lugar de los BP más simples que se esconden perfectamente y vinculan computacionalmente. Investigaremos esta opción porque el modo de falla de la inflación silenciosa dañaría seriamente a Decred.
Uno de los principales beneficios de CoinShuffle++ y su protocolo DiceMix asociado es que se puede modificar para admitir la criptografía PQ, lo que hace que el proceso de mezcla sea seguro contra atacantes que pueden romper la DLP. DiceMix requiere que los pares participantes realicen un intercambio de claves por pares, en donde se realice intercambios de claves no interactivos por motivos de simplicidad porque un intercambio de claves interactivo crearía rondas adicionales de comunicación. Al agregar una ronda adicional, es posible utilizar la criptografía PQ para asegurar el proceso de intercambio de claves. Company 0 tiene una implementación existente de uno de los mejores criptosistemas PQ, Streamlined NTRU Prime 4591 ^ 761, basado en el trabajo de Bernstein, Chuengsatiansup, Lange y van Vredendaal, por lo que esta sería una elección acertada para tal aplicación. Dado que el proceso de mezcla ocurre fuera de la cadena, las consideraciones típicas del tamaño de la transacción para usar la criptografía PQ no son relevantes, p. que las claves públicas de PQ suelen tener 1 KB o más. Tenga en cuenta que esto no evitaría que un atacante que pueda romper DLP robe fondos donde se ha revelado la clave pública correspondiente, pero evitaría que deshaga pasivamente mezclas para despojar de la privacidad.
Es reconfortante hacer público este trabajo y ofrecer una versión inicial de privacidad a nuestros stakeholders de una manera que pueda beneficiar a todos los usuarios de Decred. Estas funciones están disponibles como una solicitud de extracción de dcrwallet en GitHub, y alentamos a los usuarios más técnicos a probar este código con nosotros. Este código ha sido sometido a pruebas sustanciales en testnet durante su desarrollo, por lo que ya debería ser bastante estable. Después de algunas pruebas adicionales, este código se convertirá en parte de la rama maestra y se incluirá en la próxima versión, 1.5.0. Siempre estamos buscando desarrolladores talentosos, así que si este trabajo de privacidad te interesa, ingresa a nuestro chat y avísanos.
Si bien el trabajo ya completado es sustantivo, aún queda mucho por hacer. Nuestro objetivo es mantener el código de privacidad simple, tanto en términos de primitivas criptográficas como de sus limitaciones implícitas en la cadena de bloques Decred. Decred continuará iterando y adaptándose al cambiante panorama de privacidad que nos rodea, integrando nuevas funciones según sea necesario, según la voluntad de los stakeholders, para hacer frente a las amenazas a medida que surjan. Como siempre, nos esforzamos por maximizar la seguridad de nuestra cadena de bloques y sus usuarios, y lo haremos de manera sostenible, para hacer de Decred una reserva superior de valor a largo plazo.
A continuación, de acuerdo con el artículo de privacidad anterior, hemos agregado Decred al siguiente cuadro.
Articulo original: https://blog.decred.org/2019/08/28/Iterating-Privacy/