¡Bienvenido! ¿Eres nuevo en Zcash?
La red de Zcash es joven, ¡pero evoluciona rápidamente! ¡Regístrate y nos pondremos en contacto con más información sobre cómo puedes comenzar con Zcash!

Idioma

Una Actualización sobre la Integración de Zcash on Ethereum (ZoE)

Ariel Gabizon and Christian Reitwiessner | Jan 19, 2017

Miembros del equipo de Ethereum R&D y de Zcash Company están colaborando en un proyecto de investigación que aborda la combinación de programabilidad y privacidad en blockchains. Este artículo conjunto está siendo simultáneamente publicado en el blog de Ethereum, y ha sido coescrito por Ariel Gabizon (Zcash) y Christian Reitwiessner (Ethereum).

La interfaz de contrato inteligente flexible de Ethereum permite una gran variedad de aplicaciones, muchas de las cuales probablemente aún no han sido concebidas. Las posibilidades crecen considerablemente al agregar la capacidad de privacidad.

Imaginemos, por ejemplo, una elección o subasta realizada en el blockchain a través de un contrato inteligente, de modo que el resultado pueda ser verificado por cualquier observador del blockchain, sin que los votos individuales o las ofertas sean revelados. Otro escenario es el de la divulgación selectiva; por ejemplo, proporcionar a los usuarios la posibilidad de probar que están en una ciudad determinada sin revelar su ubicación exacta.

La clave para agregar estas capacidades a Ethereum son los argumentos de conocimiento sucinto no-interactivo del conocimiento-cero (zk-SNARKs) ─precisamente el motor criptográfico subyacente de Zcash.

Uno de los objetivos de Zcash Company, denominada Proyecto Alquimia, es permitir un intercambio directo descentralizado entre Ethereum y Zcash. La conexión de estos dos blockchains y equipos, uno centrado en la programación y el otro en la privacidad, parece la forma natural de dar vida a las aplicaciones que requieren ambas cosas.

Como parte del esfuerzo colaborativo Zcash/Ethereum, Ariel Gabizon de Zcash visitó a Christian Reitwiessner del centro de Ethereum hace unas semanas en Berlín. El punto culminante de la visita es una implementación de prueba de concepto de un verificador zk-SNARK escrito en Solidity, basado en contratos Ethereum precompilados implementados para el cliente Ethereum C++. Esto complementa a Baby ZoE, en donde un contrato precompilado zk-SNARK fue escrito para Parity ─el cliente Ethereum Rust. La diferencia es que sólo añadimos pequeñas primitivas criptográficas (multiplicación, adición y emparejamiento de la curva elíptica) e hicimos el resto en Solidity. Esto permite una flexibilidad mucho mayor y permite el uso de una variedad de construcciones zk-SNARK sin necesidad de un hard fork (ver más detalles más adelante). Probamos este código comprobando con éxito una transacción real de Zcash que preserva la privacidad, en un testnet del blockchain de Ethereum. La verificación tardó sólo 42 milisegundos, lo que demuestra que tales contratos precompilados se pueden agregar y los costos de funcionamiento pueden resultar bastante asequibles.

Lo que se puede hacer con este sistema

El sistema Zcash puede reutilizarse en Ethereum para crear tokens blindados personalizados. Estos tokens permiten ya muchas aplicaciones como votaciones (más sobre eso más adelante) o una simple subasta en la cual los compradores no llegan a conocer las ofertas de los demás.

Si deseas intentar compilar la prueba de concepto, puedes utilizar los siguientes comandos. Si necesitas ayuda, ve a https://gitter.im/ethereum/privacy-tech

git clone https://github.com/scipr-lab/libsnark.git

cd libsnark
sudo PREFIX=/usr/local make NO_PROCPS=1 NO_GTEST=1 NO_DOCS=1 CURVE=ALT_BN128 \
FEATUREFLAGS="-DBINARY_OUTPUT=1 -DMONTGOMERY_OUTPUT=1 -DNO_PT_COMPRESSION=1" \
lib install
cd ..
git clone --recursive -b snark https://github.com/ethereum/cpp-ethereum.git
cd cpp-ethereum
./scripts/install_deps.sh && cmake . -DEVMJIT=0 -DETHASHCL=0 && make eth
cd ..
git clone --recursive -b snarks https://github.com/ethereum/solidity.git
cd solidity
./scripts/install_deps.sh && cmake . && make soltest
cd ..
./cpp-ethereum/eth/eth --test -d /tmp/test
# And on a second terminal:
./solidity/test/soltest -t "*/snark" -- --ipcpath   /tmp/test/geth.ipc  --show-messages

Hemos discutido también varios aspectos de la integración de zk-SNARKs en el blockchain de Ethereum, sobre lo cual ampliamos ahora.

Decidir cuáles contratos precompilados definir

Recordemos que un SNARK es una prueba corta de alguna propiedad, y lo que se necesita para agregar las características de privacidad al blockchain de Ethereum es que los clientes tengan la capacidad de verificar tal prueba.

En todas las construcciones recientes, el procedimiento de verificación consiste únicamente en operaciones sobre curvas elípticas. Específicamente, el verificador requiere la multiplicación y adición escalar en un grupo de curva elíptica; pero también, una operación más pesada llamada emparejamiento bilinear.

Como se ha mencionado aquí, la implementación de estas operaciones directamente en EVM es demasiado costosa. Por lo tanto, queremos implementar contratos precompilados que realicen estas operaciones. Ahora, la pregunta que debatimos fue: ¿a qué nivel de generalidad deben apuntar estos contratos pre-compilados?

El nivel de seguridad del SNARK corresponde a los parámetros de la curva. A grandes rasgos, cuanto mayor sea el orden de la curva, y cuanto mayor sea lo que llamamos el grado de incrustación, más seguro será el SNARK basado en esta curva. Por otra parte, naturalmente, cuanto más grandes sean estas cantidades, más costosas serán las operaciones en la curva correspondiente. Por lo tanto, un diseñador de contratos que utilice SNARKs puede desear elegir estos parámetros según su propio balance de eficiencia/seguridad deseado. Este es uno de los argumentos para implementar un contrato precompilado con un alto nivel de generalidad, donde el diseñador del contrato puede elegir entre una gran familia de curvas. Comenzamos de hecho apuntando a un nivel alto de generalidad ─donde la descripción de la curva se da como parte del input del contrato. En tal caso, un contrato inteligente podría, por ejemplo, realizar adiciones en cualquier grupo de curvas elípticas.

Una complicación con este enfoque es asignar costo de funcionamiento a la operación ─debe ser posible evaluar, simplemente a partir de la descripción de la curva, y sin acceso a una implementación específica, cuán costosa sería una operación de grupo en esa curva (en el peor de los casos) . Un enfoque algo menos general es permitir todas las curvas de una familia dada. Hemos notado que cuando se trabaja con la familia de curvas Barreto-Naehrig (BN), se puede evaluar aproximadamente cuán costosa será la operación de emparejamiento dados los parámetros de la curva, ya que todas estas curvas son compatibles con un tipo específico de emparejamiento Ate óptimo. Aquí hay un bosquejo de cómo una precompilación de ese tipo podría funcionar y cómo se calcularía el costo de funcionamiento.

Aprendimos mucho de este debate, pero en última instancia, decidimos "mantenerlo simple" para esta prueba de concepto, e implementar contratos para operaciones sobre la curva específica actualmente utilizada por Zcash. Hemos hecho esto usando wrappers de las funciones correspondientes en la librería libsnark, también utilizada por Zcash. Observamos que podríamos simplemente haber utilizado un wrapper para toda la función de verificación de SNARK actualmente utilizada por Zcash ─como se hizo en el proyecto Baby ZoE mencionado anteriormente. Sin embargo, la ventaja de definir explícitamente las operaciones de la curva elíptica permite el uso de una amplia variedad de construcciones SNARK, las cuales, nuevamente, tienen todas un verificador trabajando según alguna combinación de las tres operaciones de curva elíptica mencionadas.

Reutilización de la configuración de Zcash para nuevos tokens anónimos y otras aplicaciones

Como ya habrás escuchado, el uso de SNARK requiere una fase de configuración compleja en la cual son construidos los llamados parámetros públicos del sistema. El hecho de que estos parámetros públicos necesiten ser generados de forma segura cada vez que queremos usar un SNARK para un circuito particular dificulta significativamente la usabilidad de SNARKs. (Simplificar esta fase de configuración es también un objetivo importante en el que hemos estado pensando, pero en el que no hemos tenido éxito por el momento).

Por otra parte, la buena noticia es que alguien que desee emitir un token que soporte transacciones con preservación de privacidad puede simplemente reutilizar los parámetros públicos que ya han sido generados con seguridad por Zcash. La razón de esto es que el circuito Zcash que se utiliza para verificar las transacciones con preservación de privacidad no está intrínsecamente vinculado a una moneda o a un blockchain. Por el contrario, una de sus entradas explícitas es la raíz de un árbol Merkle que contiene todas las notas válidas de la moneda y, por lo tanto, esta entrada se puede cambiar de acuerdo a la moneda con la que uno desea trabajar. Por otra parte, si es relativamente fácil iniciar un nuevo token anónimo, se pueden realizar ya muchas tareas que no se ven como tokens a primera vista. Por ejemplo, supongamos que deseamos realizar una elección anónima para elegir una opción preferida entre dos. Podemos emitir un token personalizado anónimo para la votación, y enviar una moneda a cada votante. Puesto que no hay "minería", no será posible generar fichas de otra manera. Ahora cada uno de esos votantes envía su moneda a una de las dos direcciones de acuerdo con su voto. La dirección con un balance final mayor determinará el resultado de la elección.

Otras aplicaciones

Un sistema no basado en tokens que es bastante simple de construir permite la "divulgación selectiva": puedes, por ejemplo, publicar constantemente en el blockchain un mensaje cifrado que contenga tu ubicación física (tal vez con firmas de otras personas para evitar la suplantación de identidad). Si utilizas una clave diferente para cada mensaje, puedes revelar tu ubicación sólo en un momento determinado revelando la clave. Con zk-SNARKs, sin embargo, puedes probar que estuviste en un área determinada sin revelar dónde exactamente has estado: dentro del zk-SNARK, descifras tu ubicación y muestras que esa ubicación está dentro del área. Debido a la propiedad de conocimiento-cero, todo el mundo puede verificar ese hecho, pero nadie puede recuperar tu ubicación real.

El trabajo por delante

Lograr realmente las funcionalidades mencionadas ─la creación de tokens anónimos y la verificación de las transacciones de Zcash en el blockchain Ethereum─, requerirá la implementación en Solidity de otros elementos utilizados por Zcash. Para la primera, debemos tener una implementación de tareas realizadas por nodos en la red Zcash, tales como actualizar el árbol de compromisos de notas. Para la segunda, necesitamos una implementación del algoritmo de prueba de trabajo equihash usado por Zcash en Solidity. De lo contrario, las transacciones pueden ser verificadas como válidas en sí mismas, pero no sabemos si las notas utilizadas existieron en el blockchain de Zcash o si la transacción se envió realmente al blockchain de Zcash. Afortunadamente, dicha implementación fue escrita pero, sin embargo, su eficiencia necesita ser mejorada para poder ser utilizada en aplicaciones prácticas.

Reconocimientos: Damos las gracias a Sean Bowe por la asistencia técnica. También damos las gracias a Sean y Vitalik Buterin por sus comentarios útiles, y a Ming Chan por la edición.