🎃 Diversão assustadora, recompensas reais! Gate.io #Halloween Magic# está aqui!
🎁 Abra a Porta Misteriosa para obter doces ou moedas de ouro e compartilhe $60,000 em recompensas!
🎉 Receba 1 CHANCE GRÁTIS todos os dias: https://www.gate.io/activities/halloween-magic
Detalhes: https://www.gate.io/
Caminhos largos levam ao MPC? Explorando o fim da infraestrutura de privacidade
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:
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:
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:
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:
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:
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:
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:
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:
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:
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:
É 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:
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.