El Protocolo Zecrey: Mantener la privacidad en el mundo de los contratos inteligentes

Albert Inim
4 min readFeb 2, 2022

--

Con el desarrollo exitoso de la tecnología blockchain y las iniciativas DeFi, la privacidad de los activos y las identidades de los clientes ha atraído una gran atención. La privacidad de la cuenta y la privacidad de las transacciones son los dos componentes principales de la preocupación por la privacidad de la cadena de bloques. La privacidad de la cuenta se refiere a la necesidad de que el saldo y la dirección de la cuenta de blockchain se mantengan privados, mientras que la privacidad de la transacción se refiere a la protección del monto de la transacción, así como la conexión entre los participantes de la transacción.
Muchas iniciativas de blockchain que se concentran en la protección de la privacidad han surgido en los últimos años. Sin embargo, estos esfuerzos han mostrado una serie de fallas que han obstaculizado significativamente la estandarización de los protocolos de privacidad de blockchain. Para empezar, la mayoría de los mecanismos de privacidad existentes se basan en el concepto UTXO. Para una verificación más rápida y un procesamiento paralelo, el modelo UTXO almacena el conjunto de todas las transacciones no gastadas en la cadena de bloques. Sin embargo, es incapaz de hacer un razonamiento complejo y tiene una programabilidad limitada. Aunque el modelo basado en cuentas es más programable y fácil de usar que el modelo UTXO, mantener la privacidad de la cadena de bloques del modelo de cuenta es problemático, ya que el saldo de la cuenta se actualiza cada vez que se confirma una transacción relevante en la cadena de bloques.
En segundo lugar, una gran cantidad de esquemas de privacidad existentes buscan construir su propia cadena de bloques, que es solo una cadena de moneda sin la capacidad de ser programada. Debido a que esta forma de protocolo de privacidad no se puede adaptar a las redes blockchain actuales, no se puede usar como una solución de privacidad genérica. Teniendo en cuenta la heterogeneidad, la magnanimidad y la variedad de las plataformas blockchain actuales, es fundamental ofrecer un protocolo de privacidad genérico que pueda adaptarse a múltiples redes blockchain. Además, ZK-Snark se utiliza en la mayoría de los métodos de privacidad existentes.
Sin embargo, ZK-Snark tiene la desventaja inherente de ser una técnica intensiva en recursos. Debido a que los usuarios comunes están continuamente limitados por los recursos computacionales, los protocolos actuales no pueden garantizar la privacidad de un extremo a otro. Zether es el primer enfoque viable para salvaguardar la privacidad de las transacciones basado en el concepto de contabilidad. Zether completa el modelo de transacción de privacidad con contratos inteligentes y realiza transacciones privadas basadas en ElGamal Encryption, One-out-of-Many Proofs y BulletProofs-driven Sigma.
Sin embargo, los experimentos han demostrado que los costos de las transacciones privadas en Zether son demasiado altos (la transacción de transferencia utiliza 718,8 W de gas) y la cantidad de datos de la transacción es demasiado grande (la transacción transmitida es de 1472 bytes), lo que hace que Zether no sea adecuado para su uso en situaciones reales. -circunstancias del mundo. La solución en sí también tiene fallas. Zether solo admite transacciones privadas uno a uno, y un solo usuario solo puede enviar una transacción en cada ronda. Estos defectos limitarán severamente la disponibilidad del protocolo y tendrán un impacto negativo en el rendimiento del sistema.
Según la investigación anterior, el desarrollo de un mecanismo universal y escalable para proteger la privacidad de las cuentas y las transacciones en el entorno de los contratos inteligentes sigue siendo un tema importante. Sin embargo, estamos en medio de una explosión de cadenas, con cientos de redes de cadenas de bloques, lo que hace que sea poco práctico crear una nueva cadena de bloques de privacidad de capa 1. A largo plazo, la creación de un protocolo genérico de capa 2 que garantice la privacidad tanto de la cuenta como de la transacción y vincule cadenas de bloques dispares de una manera escalable y liviana tendría un efecto más significativo en el desarrollo de la cadena de bloques, que es precisamente nuestra visión. Finalmente, un protocolo de privacidad genérico debe cumplir las siguientes características.
Preservación de la privacidad: el protocolo propuesto debe proteger no solo el saldo y la dirección de la cuenta de la cadena de bloques, sino también los montos transferidos y la relación entre las partes de la transacción para que no queden expuestos. Este es el requisito más importante.
Programable: este es el requisito básico para diseñar protocolos de cadena de bloques, lo que permite que la lógica y las regulaciones de aplicaciones complejas se asignen a la cadena de bloques a través de contratos inteligentes.
Escalable: para adaptarse a los escenarios con grandes cantidades de clientes, el protocolo propuesto debe satisfacer la escalabilidad requerida para evitar la congestión del servicio o fallas del sistema debido al ancho de banda de la red, la carga de almacenamiento, la carga informática, la topología del protocolo, etc.
Ligero: este es un requisito único para los protocolos de capa 2. Dado que la tarifa de transacción se vuelve cada vez más costosa en las principales redes de cadenas de bloques, como Ethereum y BSC, cada vez es más difícil para el público usar protocolos de capa 2. Para atraer usuarios y reducir el umbral, el protocolo necesita disminuir las tareas de computación intensivas en recursos y los costos de interacción.
Cross-Chain: A medida que surgen más y más proyectos de blockchain, el protocolo de privacidad debería permitir a los desarrolladores migrar los activos de uno a otro, para garantizar la disponibilidad y la sostenibilidad del servicio.
Para abordar el antecedente

Medium:https://medium.com/@zecrey
Twitter: https://twitter.com/zecreyprotocol
Telegram: https://t.me/zecrey
Discord: https://discord.com/invite/U98ghQsJE5

--

--

No responses yet