Autor: EQ Labs Fonte: equilibrium Tradução: Shenouba, Golden Finance

A nossa série de privacidade Parte 1 introduziu o significado da “privacidade”, a diferença entre a privacidade na Blockchain e a privacidade na web2, e por que é difícil alcançar a privacidade na Blockchain.

O ponto principal deste artigo é que, se o estado final ideal for ter uma infraestrutura de privacidade com Programabilidade, capaz de lidar com estados privados compartilhados sem nenhum ponto de falha, então todos os caminhos levam ao MPC. Também discutiremos a maturidade do MPC e suas suposições de confiança, enfatizando métodos alternativos, comparando trade-offs e fornecendo uma visão geral da indústria.

Libertar-se das amarras do passado e dar as boas-vindas ao futuro

A infraestrutura de privacidade existente na Bloco链 destina-se a lidar com casos de uso muito específicos, como pagamentos privados ou votação. Esta é uma visão bastante restrita, que reflete principalmente os usos atuais da Bloco链 (transações, transferências e especulação). Como Tom Walpo disse, a Criptomoeda sofre do paradoxo de Fermi.

Além de aumentar a liberdade individual, acreditamos que a privacidade é uma condição prévia para expandir o espaço de design do Bloco, além dos metadados especulativos atuais. Muitos aplicativos exigem algum estado privado e/ou lógica oculta para funcionar corretamente:

• Estado oculto : a maioria dos casos de uso financeiro requer (pelo menos) confidencialidade em relação a outros utilizadores, e sem algum estado de ocultação, o interesse de muitos jogos seria grandemente Gota (por exemplo, se todos na mesa de pôquer pudessem ver as cartas uns dos outros).
• Ocultar lógica：Alguns casos de uso exigem que certa lógica seja ocultada, enquanto ainda permitem que outros utilizem a aplicação, por exemplo, motor correspondente, estratégias de negociação na cadeia, etc.

Análises empíricas (de web2 e web3) indicam que a maioria dos usuários não está disposta a pagar taxas adicionais ou pular etapas extras para aumentar a privacidade, e concordamos que a privacidade em si não é um ponto de venda. No entanto, ela permite que novos casos de uso mais significativos (e esperançosamente) possam existir na blockchain - vamos nos livrar da Paradoxo de Fermi.

A tecnologia de reforço de privacidade (PET) e as soluções modernas de criptografia ('Programabilidade de Senhas') são os blocos de construção fundamentais para alcançar essa visão (para obter mais informações sobre as diferentes soluções disponíveis e suas compensações, consulte o Apêndice).

Três suposições que influenciam nosso ponto de vista

Três pressupostos-chave determinam a nossa visão sobre o desenvolvimento da infraestrutura de privacidade da blockchain:

1. A tecnologia de encriptação será abstraída das mãos dos desenvolvedores de aplicativos: a maioria dos desenvolvedores de aplicativos não quer (ou não sabe como lidar com ela) a tecnologia de encriptação necessária para lidar com a privacidade. Não é razoável esperar que implementem a sua própria tecnologia de encriptação e construam cadeias de aplicações privadas* (por exemplo, Zcash ou Namada) ou aplicações privadas em cima de cadeias públicas (por exemplo, Tornado Cash). Isso é simplesmente muito complexo e sobrecarregado, e atualmente limita o espaço de design para a maioria dos desenvolvedores (incapaz de criar aplicativos que exigem alguma privacidade). Portanto, acreditamos que é importante abstrair a complexidade de gerenciar a parte de encriptação das mãos dos desenvolvedores de aplicativos. As duas abordagens aqui são a infraestrutura de privacidade da Programabilidade (L1/L2 privada compartilhada) ou "secret-as-a-service", que permite a terceirização de computação confidencial.
2. Muitos casos de uso (possivelmente mais do que imaginamos) requerem compartilhamento de estado privado: como mencionado anteriormente, muitos aplicativos precisam de algum estado oculto e/ou lógica para funcionar corretamente. O compartilhamento de estado privado é um subconjunto disso, onde vários participantes calculam sobre o mesmo estado privado. Embora possamos confiar em uma entidade centralizada para fazer isso por nós e encerrar o assunto, idealmente gostaríamos de fazer isso de forma minimamente confiável para evitar pontos únicos de falha. Apenas com Prova de conhecimento zero (ZKP) não é possível alcançar isso - precisamos aproveitar outras ferramentas, como Ambiente de execução confiável (TEE), Criptografia homomórfica completa (FHE) e/ou cálculo mais longo (MPC).
3. Uma coleção de blindagem maior pode proteger a privacidade ao máximo: a maioria das informações vazam ao entrar ou sair da coleção de blindagem, portanto, devemos minimizar essa situação. A construção de vários aplicativos privados na mesma blockchain pode ajudar a fortalecer a proteção de privacidade, aumentando o número de usuários e transações na mesma coleção de blindagem.

O fim da infraestrutura de privacidade

Dado essas suposições, qual é o objetivo final da infraestrutura de privacidade da cadeia de blocos? Existe uma maneira que se adequa a todos os aplicativos? Existe uma tecnologia de aprimoramento de privacidade que pode ser usada em todos os aplicativos?

Não é completamente. Todos estes têm diferentes compromissos, e vimos que se combinam de várias maneiras. No total, identificamos 11 métodos diferentes.

Atualmente, os dois métodos mais populares para construir infraestruturas de privacidade na blockchain são o uso de ZKP ou FHE. No entanto, ambos têm falhas fundamentais:

• Com base em ZK e com prova de cliente, o protocolo de privacidade pode fornecer uma forte proteção de privacidade, mas não permite o cálculo mais longo do mesmo estado privado. Isso limita a capacidade de expressão, ou seja, que tipo de aplicativos os desenvolvedores podem construir.
• FHE suporta o cálculo de dados de encriptação e compartilhamento de estado privado, mas levanta a questão de quem possui esse estado, ou seja, quem possui a Chave Secreta de desencriptação. Isso limita a força da proteção de privacidade e até que ponto podemos confiar que a privacidade de hoje permanecerá a mesma amanhã.

Se o estado final ideal é ter uma infraestrutura de privacidade com Programabilidade, que pode lidar com estados privados compartilhados * sem qualquer ponto de falha *, então ambos os caminhos podem levar ao MPC:

Por favor, note que, embora esses dois métodos acabem convergindo, o uso de MPC é diferente:

• Rede ZKP: MPC aumenta a capacidade de expressão através da computação de estados privados compartilhados.
• Rede FHE: O MPC melhora a segurança e reforça a privacidade, distribuindo a Chave Secreta para o comité do MPC (em vez de um terceiro individual).

Embora a discussão esteja começando a se voltar para pontos de vista mais detalhados, as garantias por trás desses diferentes métodos ainda não foram totalmente exploradas. Dado que nossa suposição de confiança se resume à suposição de MPC, três questões-chave que precisam ser levantadas são:

1. Quão forte é a proteção de privacidade que o protocolo MPC pode fornecer na cadeia de blocos?
2. A tecnologia está suficientemente madura? Se não estiver, qual é o gargalo?
3. Considerando a intensidade da garantia e os custos associados, faz sentido em comparação com outros métodos?

Vamos responder a essas perguntas de forma mais detalhada.

Usar MPC para analisar riscos e pontos fracos

Sempre que uma solução utiliza FHE, as pessoas sempre perguntam: "Quem possui a chave secreta de decifração?". Se a resposta for "a rede", a pergunta subsequente seria: "Quais entidades reais compõem essa rede?". A última pergunta está relacionada a todos os casos de uso que dependem de alguma forma do MPC.

Fonte de informação: Palestra de Zama sobre ETH CC

O principal risco do MPC é a conluio, ou seja, o conluio malicioso de um número suficiente de participantes para descriptografar dados ou roubar cálculos. O conluio pode ser alcançado fora da cadeia e só é revelado quando a parte maliciosa toma algumas ações óbvias (como extorsão ou cunhagem de Tokens do nada). Sem dúvida, isso tem um impacto significativo na privacidade que o sistema pode oferecer. O risco de conluio depende de:

• Quantos atores maliciosos este protocolo pode suportar?
• De que partes é composta a rede? Quão confiáveis são eles?
• Número e distribuição das diferentes partes envolvidas na rede - Existem meios comuns de ataque?
• A rede é permissiva ou licenciada (interesses econômicos e reputação/base legal)? Qual é a punição para comportamentos maliciosos? O conluio de jogos é teoricamente o resultado ideal?

1. Quão forte é a privacidade que o protocolo MPC pode fornecer na cadeia de blocos?

Resumindo: não é tão poderoso quanto esperávamos, mas é mais poderoso do que depender de uma terceira parte centralizada.

O limiar necessário para descriptografar depende do esquema de MPC selecionado - em grande parte, é um equilíbrio entre a atividade (“garantia de entrega de saída”) e a segurança. Você pode optar por um esquema N/N muito seguro, mas ele falhará assim que um Nó estiver offline. Por outro lado, os esquemas N/2 ou N/3 são mais robustos, mas têm um risco maior de conluio.

As duas condições a serem equilibradas são:

1. A informação confidencial nunca será revelada (por exemplo, decifrar Chave Secreta)
2. As informações confidenciais nunca desaparecerão (mesmo que 1/3 dos participantes saiam repentinamente).

O plano selecionado varia com a implementação. Por exemplo, o objetivo da Zama é N/3, enquanto a Arcium está atualmente implementando o esquema N/N, mas em breve também suportará esquemas com garantias de atividade mais alta (e suposições de confiança maiores).

Nesta fronteira de equilíbrio, uma solução de compromisso é adotar uma abordagem híbrida:

• 高信任委员会以例如 N/3 阈值进行Chave Secreta处理。
• Comitê de Cálculo é rotativo, por exemplo, há N-1 limiares (ou vários comitês de cálculo diferentes com características diferentes para o usuário escolher).

Embora isso seja teoricamente atraente, também introduz uma complexidade adicional, como a interação do comitê de cálculo com o comitê de alta confiança.

Outro método de reforçar a segurança é executar o MPC em hardware confiável para compartilhar e armazenar a Chave Secreta em uma área segura. Isso torna mais difícil extrair ou usar a Chave Secreta compartilhada para qualquer operação fora da definição do protocolo. Pelo menos Zama e Arcium estão explorando a perspectiva do TEE.

Riscos mais subtis incluem situações marginais como engenharia social, por exemplo, todas as empresas no cluster MPC empregam um engenheiro sênior com mais de 10 a 15 anos de experiência.

2. A tecnologia é suficientemente madura? Se não, qual é o gargalo?

Do ponto de vista de desempenho, o desafio chave que o MPC enfrenta é o custo de comunicação. Isso subir com a complexidade do cálculo e o aumento do número de Nó na rede (mais idas e vindas de comunicação são necessárias). Para o caso de uso do Bloco, isso terá dois impactos práticos:

1. Conjunto de operadores de pequena escala: para controlar o custo da comunicação, a maioria dos atuais protocolos estão limitados a um conjunto de operadores de pequena escala. Por exemplo, a rede de descriptografia da Zama atualmente permite no máximo 4 nós (embora planejem expandir para 16). De acordo com a Referência inicial publicada pela Zama para sua rede de descriptografia (TKMS), mesmo com um cluster de apenas 4 nós, a descriptografia leva de 0,5 a 1 segundo (o processo completo de ponta a ponta leva mais tempo). Outro exemplo é o MPC implementado pelo Taceo para o banco de dados de íris do Worldcoin, que envolve 3 partes (supondo que 2/3 sejam honestas).

Fonte de informação: Palestra de Zama sobre ETH CC 2. 3. Conjunto de operadores licenciados: na maioria dos casos, um conjunto de operadores é licenciado. Isso significa que dependemos de reputação e contratos legais, não de segurança econômica ou de criptografia. O principal desafio de um conjunto de operadores não licenciados é que não podemos saber se as pessoas estão conspirando fora da cadeia. Além disso, é necessário guiar ou redistribuir regularmente as partes das chaves para que os nós possam entrar/sair dinamicamente da rede. Embora o conjunto de operadores não licenciados seja o objetivo final e esteja sendo estudada a forma de expandir o mecanismo de PoS para alcançar MPC por limite (por exemplo, Zama), a rota licenciada parece ser a melhor direção atualmente.

Métodos Alternativos

A combinação abrangente de privacidade inclui:

• FHE utilizado para cálculo de privacidade delegada
• ZKP é usado para verificar se o cálculo FHE é executado corretamente
• MPC para descriptografia de limiar
• Cada Nó MPC é executado dentro do TEE para aumentar a segurança

É complicado, envolve muitos cenários extremos não explorados, é custoso e pode não ser viável nos próximos anos. Outro risco é que as pessoas podem ter uma falsa sensação de segurança ao combinar vários conceitos complexos. Quanto mais complexidade e suposições de confiança adicionamos, mais difícil é inferir a segurança da solução como um todo.

Vale a pena? Talvez valha a pena, mas também vale a pena explorar outras abordagens que podem trazer uma eficiência computacional significativamente melhor, enquanto garantem um pouco menos de privacidade. Como Lyron, da Seismic, apontou - devemos nos concentrar nas soluções mais simples que atendam aos nossos padrões de nível de privacidade desejado e compromissos aceitáveis, em vez de projetá-las apenas por causa disso.

1. Uso direto do MPC para cálculos gerais

Se ZK e FHE eventualmente voltarem à suposição de confiança de MPC, por que não usar diretamente MPC para cálculos? Esta é uma pergunta válida, e é o que equipes como Arcium, SodaLabs (usando Coti v2), Taceo e Nillion estão tentando fazer. Observe que MPC tem várias formas, mas aqui estamos nos referindo ao protocolo baseado em compartilhamento secreto e circuito garbled (GC), não ao protocolo baseado em FHE para descriptografia usando MPC.

Embora o MPC já tenha sido usado para assinaturas distribuídas e cálculos mais seguros, como a Carteira, o principal desafio ao usar o MPC para cálculos mais genéricos é o custo de comunicação (que aumenta com a complexidade dos cálculos e o número de Nós envolvidos).

Existem algumas maneiras de reduzir os custos, como a realização de pré-processamento offline (a parte mais cara do protocolo) - Arcium e SodaLabs estão explorando isso. Em seguida, execute os cálculos na fase online, o que consome alguns dos dados gerados na fase offline. Isso reduz significativamente os custos gerais de comunicação.

A tabela abaixo da SodaLabs mostra quanto tempo leva para executar 1.000 vezes diferentes Código de operação em seu gcEVM, com Referência inicial em microssegundos. Embora seja um passo na direção certa, há muito trabalho a ser feito para aumentar a eficiência e expandir o conjunto de operadores para além de vários Nós.

Fonte: SodaLabs

A vantagem do método baseado em ZK é que você só usa MPC para casos de uso que requerem cálculos em estado privado compartilhado. A competição entre FHE e MPC é mais direta e depende muito do hardware acelerado.

2. Ambiente de execução confiável

Recentemente, o interesse pelo TEE foi reacendido, podendo ser usado sozinho (com base em uma blockchain privada TEE ou coprocessador), ou combinado com outros PET (como soluções baseadas em ZK) (apenas compartilhando o cálculo de estado privado usando TEE).

Embora TEE seja mais maduro em alguns aspectos e introduza menos overhead de desempenho, não é sem falhas. Em primeiro lugar, TEE tem suposições de confiança diferentes (1/N) e fornece uma solução baseada em hardware em vez de software. Uma crítica comum é em torno das falhas passadas do SGX, mas é importante notar que TEE ≠ Intel SGX. TEE também requer confiança no fornecedor de hardware, e o hardware é caro (inacessível para a maioria). Uma solução para mitigar o risco de ataques físicos pode ser executar TEE no espaço para lidar com tarefas críticas.

No geral, TEE parece ser mais adequado para provas ou casos de uso que requerem apenas privacidade de curto prazo (descriptografia em limiar, livro de pedidos oculto, etc.). Para privacidade permanente ou de longo prazo, a segurança parece não ser atraente.

3. Métodos Privados DAC e Outros que Dependem de Terceiros de Confiança para Proteger a Privacidade

A privacidade mediada pode proporcionar privacidade e impedir o acesso de outros usuários, mas as garantias de privacidade vêm exclusivamente da confiança em terceiros (ponto único de falha). Embora seja semelhante à "privacidade web2" (impedindo a privacidade de outros utilizadores), pode ser reforçada com garantias adicionais (encriptadas ou económicas) e permitir que a verificação seja realizada corretamente.

Um exemplo disso é o Comitê de Disponibilidade de Dados Privados (DAC); os membros do DAC armazenam dados fora da cadeia e os usuários confiam neles para armazenar corretamente os dados e executar atualizações de transição de estado. Outra forma é o Serializador Concessional proposto por Tom Walpo.

Embora este método faça grandes concessões em termos de privacidade, pode ser a única alternativa viável para aplicações de baixo valor e alto desempenho, pelo menos por agora, em termos de custo e desempenho. Por exemplo, o Protocolo Lens planeja usar DAC privados para alcançar fluxos de informação privados. Para casos de uso como redes sociais na cadeia, o equilíbrio entre privacidade e custo/desempenho pode ser razoável atualmente, levando em consideração os custos e despesas das alternativas.

4. 隐身Endereço

O Endereço Endereço pode fornecer garantias de privacidade semelhantes à criação de um novo Endereço para cada transação, mas esse processo é realizado automaticamente nos bastidores e não é divulgado ao usuário. Para mais informações, consulte esta visão geral do Vitalik ou este artigo que explora diferentes métodos. Os principais participantes nessa área incluem Umbra e Fluidkey.

Embora Endereço invisível forneça uma solução relativamente simples, a principal desvantagem é que eles só podem adicionar privacidade às transações (pagamentos e transferências), mas não às computações gerais. Isso os torna diferentes das outras três soluções mencionadas acima.

Além disso, a privacidade oferecida pelo Endereço Anônimo não é tão forte quanto outras soluções alternativas. O anonimato pode ser quebrado por meio de análise simples de cluster, especialmente quando as transferências de entrada e saída não estão dentro de uma faixa semelhante (por exemplo, recebendo $10.000, mas gastando em média $10-100 por dia em transações). Outro desafio para o Endereço Anônimo é a atualização da Chave Secreta, que agora precisa ser atualizada separadamente para cada carteira (o armazenamento consolidado da Chave Secreta pode ajudar a resolver esse problema). Em termos de experiência do usuário, se a conta não tiver tokens de taxa (como ETH), o protocolo Endereço Anônimo ainda precisa de abstração de conta ou do pagador para pagar a taxa.

Os riscos que enfrentamos em nossa proposição

Devido à rápida velocidade de desenvolvimento e à ampla incerteza das soluções tecnológicas diferentes, acreditamos que há alguns riscos na afirmação de que o MPC será a solução final. Finalmente, podemos não precisar de algum tipo de MPC, principalmente devido às seguintes razões:

1. Compartilhar estados privados não é tão importante quanto imaginamos: nesse caso, a infraestrutura baseada em ZK tem mais chances de ter sucesso, pois oferece garantias de privacidade mais fortes e menor custo do que FHE. Já existem alguns casos de uso que mostram que sistemas baseados em ZK funcionam bem em casos isolados, como o protocoloPayy de pagamento privado.
2. Os compromissos de desempenho não valem os benefícios da privacidade: Alguém pode argumentar que a suposição de confiança em uma rede MPC com 2-3 partes autorizadas não é muito diferente de um participante centralizado único e que o aumento significativo de custos/despesas não vale a pena. Para muitos aplicativos, especialmente os de baixo valor e sensíveis ao custo (como redes sociais ou jogos), isso pode ser verdadeiro. No entanto, existem também muitos casos de uso de alto valor, nos quais a colaboração é atualmente muito cara (ou impossível) devido a questões legais ou fricção de coordenação. Este é um ponto em que as soluções baseadas em MPC e FHE podem brilhar.
3. A especialização é melhor que o design genérico: construir uma nova cadeia e orientar a comunidade de usuários e desenvolvedores é muito difícil. Portanto, a infraestrutura genérica de privacidade (L1/L2) pode ser difícil de obter. Outro problema envolve o especialização; o design de um único protocolo é difícil de cobrir todo o espaço de compensação. Neste mundo, as soluções de privacidade para ecossistemas existentes (privacidade como serviço) ou casos de uso específicos (como pagamentos) terão a vantagem. No entanto, somos céticos em relação a este último, pois isso traz complexidade aos desenvolvedores de aplicativos, que precisam implementar tecnologias de encriptação por conta própria (em vez de abstrair isso).
4. A regulamentação continua a impedir a experimentação de soluções de privacidade: é um risco para qualquer pessoa que esteja a construir infraestruturas de privacidade e aplicações com certas garantias de privacidade. Os casos de uso não financeiros enfrentam menos riscos regulamentares, mas é difícil (senão impossível) controlar o que é construído em cima de infraestruturas de privacidade sem permissão. É provável que resolvamos os problemas técnicos antes de resolvermos os problemas regulamentares.
5. Para a maioria dos casos de uso, as soluções baseadas em MPC e FHE ainda são muito caras: embora o MPC seja principalmente afetado pelo custo de comunicação, a equipe do FHE depende muito do hardware acelerado para melhorar seu desempenho. No entanto, se pudermos inferir o desenvolvimento de hardware dedicado ao aspecto ZK, o tempo necessário antes de termos hardware FHE disponível para produção será muito mais longo do que a maioria das pessoas imagina. As equipes dedicadas ao aceleramento de hardware FHE incluem Optalysys, fhela e Niobium.

Resumo

*Em última análise, a força de uma cadeia depende do seu elo mais fraco. No caso da infraestrutura de privacidade programável, se quisermos que ela possa lidar com o compartilhamento de estados privados sem falhas únicas, a garantia de confiança se resume à garantia do MPC.

Embora este artigo pareça criticar MPC, na verdade não é o caso. O MPC melhorou muito a situação atual, que depende em grande parte de terceiros centralizados. Acreditamos que o problema principal é a falsa confiança existente na indústria, que tem sido encoberta. Em vez disso, devemos enfrentar o problema e concentrar-nos na avaliação dos riscos potenciais.

No entanto, nem todos os problemas exigem a utilização da mesma ferramenta para resolução. Embora consideremos que o MPC seja o objetivo final, enquanto o custo das soluções impulsionadas pelo MPC ainda for elevado, outras abordagens também são escolhas viáveis. Sempre vale a pena considerar qual método é mais adequado para os requisitos/características específicas do problema que estamos tentando resolver, e que compromissos estamos dispostos a fazer.

Mesmo que você tenha o melhor martelo do mundo, nem tudo é um prego.