Greetings! New to Zcash?
The Zcash network is young, but evolving quickly! Sign up and we'll be in touch with more information about how you can get started with Zcash!

Idioma

Uma atualização da Integração Zcash na Ethereum (ZoE)

Ariel Gabizon e Christian Reitwalessner | Jan 19, 2017

Membros do time Ethereum R&D e da Zcash Company estão colaborando em um projeto de pesquisa que trata da combinação de programabilidade e privacidade nas blockchains. Esse post está sendo postando também no Ethereum blog, tendo como coautores Ariel Gabizon (Zcash) e Christian Reitwiessner (Ethereum).

A interface flexível dos contratos inteligentes da Ethereum permite uma grande variedade de aplicações. muitas delas provavelmente ainda não foram concebidas. A possibilidade cresce consideravelmente quando a capacidade de privacidade é adicionada.

Imagine, por exemplo, uma eleição ou um leilão conduzidos na blockchain através de um contrato inteligente, que o resultado pode ser verificado por qualquer observador na blockchain, mas os votos dos indivíduos ou lances não são revelados. Uma outra configuração é da divulgação seletiva; por exemplo, provendo usuários a habilidade de provar que eles estão em uma determinada cidade sem divulgar sua localização exata.

A chave para adicionar tal capacidade para a Ethereum é conhecimento nulo, sucinto, com argumentos não-interativos de conhecimento (zk-SNARKs) - precisamente o motor criptográfico subjacente da Zcash.

Umas das metas da empresa Zcash, codinome Project Alchemy, é permitir uma descentralização direta de negociação entre Ethereum e Zcash. Conectando esses dois blockchains e times, um focado em programabilidade e a outro em privacidade, parece o jeito natural de criar aplicativos que precisam dos dois.

Como parte do esforços de colaboração Zcash/Ethereum, Ariel Gabizon da Zcash visitou Christian Reitwiessner do hub da Ethereum em Berlin algumas semanas atrás. O principal ponto da visita é a implementação da prova de conceito de um verificador zk-SNARK escrito em Solidity, baseado em contratos pré-compilados do cliente Ethereum C++. Isso complementa Baby ZoE onde um contrato pré-compilado foi escrito para Parity - cliente Ethereum Rust. A diferença é nós somente adicionamos pequenas primitivas criptográficas ( Multiplicação da curva elíptica, adição e emparelhamento) e fizemos o resto no Solidity. Isso permite uma flexibilidade muito maior e possibilita o usar uma variedade das construções zk-SNARK sem necessitar um hard fork ( veja mais detalhes mais tarde). Nós testamos esse código verificando com sucesso verificando uma transação real de Zcash preservando a privacidade, na testnet da blockchain da Ethereum. A verificação levou 42 milissegundos, o que mostra que tais contratos pré-compilados pode ser adicionados e um custo de gás para usá-los podem ser bem acessíveis.

O que pode ser feito com um sistema deste

O sistema Zcash pode ser reutilizado para criar token protegidos customizados. Esses tokens já permitem várias aplicações como votar ( mais disso mais tarde ) ou um simples leilão onde compradores não sabem os outros lances.

Se você quer tentar compilar a prova de conceito, você pode utilizar os seguintes comandos. Se você precisar de ajuda, vá em 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
nd on a second terminal:
./solidity/test/soltest -t "*/snark" -- --ipcpath /tmp/test/geth.ipc --show-messages

Nós também discutimos vários aspectos da integração zk-SNARKs na blockchain da Ethereum, no qual agora nós expandimos.

Decidindo qual contrato precompilado definir

Lembre-se que SNARK é uma pequena prova de uma propriedade e o que é necessário para adicionar características de privacidade na blockchain da Ethereum é a capacidade dos clientes verificarem tal prova.

Em todas as contruções recentes, a verificação do procedimento consiste somente nas operações em curvas elípticas. Especificamente, o verificador requer multiplicação escalar e adição em um grupo de curva elíptica; mas também, uma operação mais pesada conhecida como emparelhamento bilinear.

Como mencionado aqui, implementando essas operações diretamente na EVM é muito caro. Então, nós queremos implementar contratos pré-compilados que performam essas operações. Agora, a questão que debatemos foi - qual nível de generalidade esses contratos pré-compilados devem focar.

O nível de segurança do SNARK corresponde ao parâmetro da curva. Aproximadamente, maior a curva da ordem é, e mais largo algo chamado grau de incorporação é, mais seguro é o SNARK baseado nessa curva. Por outro lado, naturalmente, quanto mais largo essas quantidades, mais onerosas são as operações da curva correspondente. Logo, um designer de contrato usando SNARKs pode desejar escolher estes parâmetros de acordo com a sua própria desejada eficiência / segurança tradeoff. Esse é um argumento para implementar um contrato pré-compilado com um alto nível de generalidade, onde o designer de contrato pode escolher a partir de uma grande família de curvas. Nós realmente começamos visando um alto nível de generalidade - onde a descrição da curva é dada como parte do input de contrato. Nesse caso, um contrato inteligente poderia, por exemplo, performar uma adição em qualquer grupo de curvas elípticas.

Uma complicação com essa abordagem é devido ao custo de gás da operação - você deve avaliar meramente a partir da descrição da curva e com nenhum acesso à uma implementação específica, qual caro um grupo de operações nessa curva seria ( no pior caso). Uma abordagem menos geral é permitir todas as curvas de uma determinada família. Nós notamos que quando trabalhando com a família de curvas Barreto-Naehrig(BN), é possível avaliar aproximadamente qual caro a operação de emparelhamento será baseado nos parâmetros de curva, uma vez que todas essas curvas suportam um tipo específico de Ate emparelhamento otimizado. Aqui está um esboço de como um pré-compilado iria funcionar e como o custo de gás seria computado.

Nós aprendemos muito com esse debate, mas ultimamente, decidimos "mantê-lo simples" para essa prova de conceito; e implementar contratos para operações na curva especifica utilizada pela Zcash. Nós fizemos isso utilizando wrappers fnas unções correspondentes em libsnark <https://github.com/scipr-lab/libsnark>, também utilizada pela Zcash. Nós notamos que poderíamos simplesmente utilizado um wrapper para toda a função de verificação SNARK atualmente utilizada pela Zcash - assim como foi feito no projeto Baby ZoE mencionado a cima. Porém, a vantagem de explicitamente definir as operações de curva elíptica está permitindo utilizar uma grande variedade de construções SNARK, o que de novo, todas possuem um trabalho verificado por alguma combinação das três operações mencionadas da curva elíptica.

Reutilizando a configuração do Zcash para novos tokens anônimos e outras aplicações

Como você ter ouvido, utilizar SNARKs requer uma complexa fase de configuração na qual os parâmetros públicos do sistema são construídos. O fato que esses parâmetros públicos têm que ser gerados em um modo seguro toda vez que nós queremos utilizar SNARK para um circuito dificulta significativamente a usabilidade dos SNARKs. (Simplificando essa fase de configuração é uma importante meta que nós pensamos mas não obtivemos sucesso até o momento.)

Por outro lado, a boa notícia é que alguém deseja emitir um token que suporte transações que preservem a privacidade pode simplesmente reutilizar os parâmetros públicos que já foram gerados de forma segura pela Zcash. O motivo disso é que o circuito Zcash que utilizado para verificar a preservação de privacidade nas transações não é inerentemente vinculado à uma moeda ou blockchain. Em vez disso, um dos seus inputs é a raiz de uma árvore Merkle que contêm todas as notas válidas da moeda, e portanto, esse input pode ser mudado de um acordo com a moeda que se deseja trabalhar. Além disso, se é de fato fácil criar um token novo anônimo, você já pode realizar vários trabalhos que não se parecem com tokens a primeira vista. Por exemplo, suponha que nós queremos conduzir uma eleição anônima para escolher uma opção entre duas. Nós podemos emitir um token anônimo customizado para o voto e enviar uma moeda cada partido. Uma vez que não existe "mineração", não será possível criar tokens de uma outra maneira. Agora cada partido envia sua moeda para um dois endereços de acordo com o voto. O endereço com o saldo maior corresponde ao resultado da eleição.

Outras aplicações

Um sistema não baseado em tokens que é simples de construir permite "divulgação seletiva": você pode, por exemplo, constantemente postar uma mensagem criptografada contendo sua localização física na blockchain (talvez com a assinatura de outras pessoas para impedir falsicação). Se você utilizar uma chave diferente para cada mensagem, você pode revelar sua localização somente em um determinado tempo revelando a chave. Com zk-SNARKs, no entanto, você pode provar que você estava em uma determinada área sem revelar onde exatamente você esteve: dentro do zk-SNARK, você decriptografa sua localização e mostra o que está dentro da sua área. Por causa da propriedade de zero-conhecimento, todo mundo pode verificar esse fato mas ninguém pode salvar sua localização atual.

O trabalho pela frente

Alcançar de verdade as funcionalidades mencionadas - criar tokens anônimos and verificar as transações da Zcash na blockchain da Ethereum, irá requerer a implementação de outros elementos utilizados pela Zcash na Solidity. Primeiramente, nós temos que ter um implementação de trabalhos performada por nódulos na rede Zcash tal como atualizar a árvore de nota de compromisso. Segundo, nós temos que possuir um implementação do algoritmo da prova de trabalho equihash utilizado pela Zcash na Solidity. Caso contrário, transações podem ser verificadas mas nós não sabemos se as notas utilizadas existiram na blockchain Zcash ou se a transação foi na verdade enviada para blockchain Zcash. Felizmente, tal implementação foi escrita; porém, sua eficiência precisa ser melhorada para ser usada em aplicações práticas.

Reconhecimento: Nós agradecemos Sean Boew pela assistência técnica. Nós também agradecemos Sean Vitalik Buterin pelos importantantes comentários e Ming Chan por editar.