)

Ideias centrais:

1. O FHE promete ser o “Santo Graal da criptografia”, porém há muitas preocupações de desempenho, experiência do desenvolvedor e segurança que limitam sua adoção atual.

2. Conforme mostrado no gráfico acima, o FHE precisará ser usado junto com os ZKPs e o MPC para construir um sistema de estado compartilhado verdadeiramente confidencial e seguro.

3.FHE está evoluindo rapidamente; O desenvolvimento de novos compiladores, bibliotecas, hardware etc. Sem mencionar que a FHE se beneficia imensamente da pesquisa e desenvolvimento de empresas Web2 (Intel, Google, DARPA etc.).

4. À medida que o FHE e o ecossistema circundante amadurecem, esperamos ver o “FHE verificável” tornar-se o padrão. Os aplicativos FHE podem optar por terceirizar a computação e a verificação para coprocessadores FHE.

5.Uma limitação fundamental do FHE onchain é “quem detém a chave de descriptografia?” A descriptografia de limite e o MPC oferecem soluções, mas geralmente estão sujeitos a uma compensação entre desempenho e segurança.

Introdução:

A natureza transparente dos blockchains é uma faca de dois gumes; embora haja beleza na sua abertura e observabilidade, é um obstáculo fundamental para a adoção empresarial.

A privacidade onchain tem sido um dos problemas mais desafiadores da criptografia por quase uma década. Embora existam muitas equipes construindo sistemas baseados em ZK para obter privacidade na cadeia; eles não podem suportar estado criptografado e compartilhado. Por que? A resposta curta é porque esses programas são função de uma série de ZKPs e, como tal, é impossível para qualquer pessoa aplicar lógica arbitrária ao estado atual. O que isto significa? Basicamente, não podemos construir aplicativos confidenciais de estado compartilhado (pense em Uniswap privado) usando apenas ZKPs.

No entanto, avanços recentes mostraram que a combinação de ZKPs com criptografia totalmente homomórfica (FHE) poderia alcançar DeFi confidencial e totalmente generalizável. Como? FHE é um campo florescente de criptografia que permite computação arbitrária sobre dados criptografados (parece loucura, certo?!). Conforme mostrado no gráfico acima, os ZKPs podem provar a integridade das entradas e da computação do usuário, e o FHE pode processar a própria computação.

Embora o FHE prometa ser o “Santo Graal da Criptografia”, tentamos fornecer uma análise objetiva do campo e seus vários desafios e possíveis soluções. Cobrimos os seguintes tópicos FHE onchain:

• Esquemas, bibliotecas e compiladores FHE
• Descriptografia de limite seguro
• ZKPs para entradas do usuário + grupo de computação
• Camada DA programável e escalável
• Hardware FHE

Esquemas, bibliotecas e compiladores FHE

Desafio: Esquemas, Bibliotecas e Compiladores FHE Nascentes

O gargalo fundamental do FHE onchain está nas ferramentas/infraestruturas de desenvolvimento atrasadas. Ao contrário dos ZKPs ou MPC, o FHE só existe desde 2009 e, portanto, teve um prazo muito mais curto para amadurecer.

As principais limitações do FHE DevEx são:

• Uma linguagem front-end fácil de usar para desenvolvedores codificarem sem muito conhecimento de criptografia back-end
• Um compilador FHE totalmente funcional que pode lidar com todo o trabalho sujo. (Seleção de parâmetros, otimização SIMD para BGV/BFV e otimização paralela)
• Os esquemas FHE existentes (particularmente TFHE) são cerca de 1000x mais lentos em comparação com a computação simples

Para realmente compreender as complexidades da integração do FHE, vamos percorrer a jornada do desenvolvedor:

O primeiro passo para integrar o FHE em sua aplicação é escolher um esquema de FHE para usar. O gráfico a seguir explica os esquemas primários:

Conforme mostrado na tabela acima, circuitos booleanos como FHEW e TFHE têm a inicialização mais rápida e podem evitar um procedimento complicado de seleção de parâmetros bastante complexo, e podem ser usados em cálculos arbitrários/genéricos, mas são relativamente lentos; Embora BGV/BFV possam ser adequados para DeFi geral, pois são mais eficientes em cálculos aritméticos de alta precisão, os desenvolvedores precisam conhecer a profundidade do circuito com antecedência para configurar todos os parâmetros do esquema. No outro extremo do espectro, o CKKS oferece suporte à multiplicação homomórfica onde erros de precisão são permitidos, tornando-o ideal para casos de uso não precisos, como ML.

Como desenvolvedor, você precisa escolher uma solução FHE com muito cuidado, pois ela afetará todas as outras decisões de design e desempenho futuro. Além disso, existem vários parâmetros-chave que são cruciais para configurar corretamente o esquema FHE, como a escolha do tamanho do módulo e o papel do grau polinomial.

Passando para as bibliotecas, os recursos e capacidades das populares bibliotecas FHE podem ser vistos na tabela abaixo:

Mas as bibliotecas também possuem relacionamentos diferentes com esquemas e compiladores, conforme mostrado abaixo:

Depois de selecionar a solução FHE, os desenvolvedores precisam definir parâmetros. A seleção adequada de parâmetros terá um enorme impacto no desempenho do esquema FHE. Mais dificuldade, isso requer alguma compreensão de álgebra abstrata, operações específicas de FHE, como relinearização e comutação analógico-digital, e circuitos aritméticos ou binários. Finalmente, para uma seleção eficaz dos parâmetros, é necessária uma compreensão conceitual de como eles afetam o esquema FHE.

Neste ponto, os desenvolvedores podem perguntar:

Qual deve ser o tamanho do meu espaço de texto simples? Que magnitude de textos cifrados são aceitáveis? Onde posso paralelizar a computação? E muitos mais…

Além disso, embora o FHE possa suportar cálculos arbitrários, os desenvolvedores precisam mudar sua mentalidade ao escrever programas FHE. Por exemplo, não se pode escrever uma ramificação (if-else) dependendo de uma variável no programa, porque os programas não podem comparar diretamente as variáveis como dados simples. Em vez disso, os desenvolvedores precisam mudar seu código de ramificações para algum tipo de computação que possa incorporar todas as condições das ramificações. Da mesma forma, isso evita que os desenvolvedores escrevam loops em seus códigos.

Resumindo, para um desenvolvedor não iniciado no FHE, é quase impossível integrar o FHE em seu aplicativo. Serão necessárias ferramentas/infraestruturas de desenvolvimento significativas para abstrair as complexidades apresentadas pelo FHE.

Solução:

1. Compiladores FHE específicos da Web3

Embora já existam compiladores FHE desenvolvidos por empresas como Google e Microsoft, eles são:

• Não foi projetado com o desempenho em mente, adicionando sobrecarga de 1000x versus circuitos de escrita diretamente
• Otimizado para CKKS (também conhecido como ML) e não tão benéfico para BFV/BGV necessário para DeFi
• Não foi desenvolvido para Web3. Não suporta compatibilidade com esquemas ZKP, encadeamento de programas, etc.

Isso até o compilador Sunscreen FHE. É um compilador nativo Web3 que oferece o melhor desempenho para operações aritméticas (pense em DeFi) sem aceleradores de hardware. Conforme discutido acima, a seleção de parâmetros é sem dúvida a parte mais difícil da implementação de um esquema FHE; O Sunscreen não apenas automatizou a seleção de parâmetros, mas também a codificação de dados, seleção de chave, implementa relinearização e comutação de módulo, configura os circuitos e implementa operações no estilo SIMD.

À medida que avançamos para o futuro, esperamos ver mais otimizações não apenas no compilador Sunscreen, mas em outras equipes construindo suas próprias implementações que suportam outras linguagens de alto nível.

1. Nova biblioteca FHE

Enquanto os pesquisadores continuam explorando novos esquemas poderosos, as bibliotecas FHE podem permitir que mais desenvolvedores integrem o FHE.

Tomemos como exemplo os contratos inteligentes FHE. Embora possa ser difícil escolher entre diferentes bibliotecas FHE, fica mais fácil quando falamos sobre FHE onchain porque existem apenas algumas linguagens de programação dominantes na Web3.

Por exemplo, o fhEVM da Zama integra a biblioteca de código aberto TFHE-rs da Zama em um EVM típico, expondo operações homomórficas como contratos pré-compilados. Permitir efetivamente que os desenvolvedores usem dados criptografados em seus contratos, sem quaisquer alterações nas ferramentas de compilação.

Para outros cenários específicos, poderá ser necessária alguma outra infraestrutura. Por exemplo, a biblioteca TFHE escrita em C++ não é tão bem mantida quanto a versão Rust. Embora o TFHE-rs possa suportar exportações para C/C++, se os desenvolvedores de C++ desejarem melhor compatibilidade e desempenho, eles deverão escrever sua própria versão da biblioteca TFHE.

Finalmente, uma das principais razões para a falta de infra-estrutura FHE no mercado é que não temos formas eficientes de construir FHE-RAM. Uma solução possível é trabalhar em um FHE-EVM sem determinados opcodes.

Descriptografia de limite seguro

Desafio: Descriptografia de limite insegura/centralizada

Todo sistema de estado confidencial e compartilhado é baseado em uma chave de criptografia/descriptografia. Nenhuma parte é confiável, portanto a chave de descriptografia é compartilhada entre os participantes da rede.

Um dos aspectos mais desafiadores do FHE onchain (Threshold FHE) é construir um protocolo de descriptografia de limite seguro e pré-formante. Existem dois gargalos principais: (1) A computação baseada em FHE introduz uma sobrecarga significativa, exigindo, consequentemente, nós de alto desempenho, o que reduz inerentemente o tamanho potencial do conjunto de validadores (2) À medida que o número de nós participantes no protocolo de descriptografia aumenta, a latência aumenta.

Pelo menos por enquanto, os protocolos FHE dependem de uma maioria honesta entre os validadores, no entanto, como afirmado acima, o Threshold FHE implica um conjunto menor de validadores e, portanto, uma maior probabilidade de conluio e comportamento malicioso.

E se os nós de limite conspirarem? Eles seriam capazes de contornar o protocolo e basicamente descriptografar qualquer coisa, desde entradas do usuário até quaisquer dados on-chain. Além disso, é importante observar que o protocolo de descriptografia pode acontecer de forma indetectável nos sistemas atuais (também conhecido como “ataque silencioso”).

Solução: Descriptografia de limite aprimorada ou MPC dinâmico

Existem algumas maneiras de resolver as deficiências da descriptografia de limite. (1) Habilitar um limite n/2 que tornaria mais difícil o conluio (2) Executar o protocolo de descriptografia de limite dentro de um HSM (3) Usar uma rede de descriptografia de limite baseada em TEE controlada por uma cadeia descentralizada para autenticação, permitindo dinâmica gerenciamento de chaves.

Em vez de aproveitar a descriptografia de limite, é possível usar o MPC. Um exemplo de protocolo MPC que poderia ser usado no FHE onchain inclui o novo 2PC-MPC da Odsy, o primeiro algoritmo MPC não conluio e massivamente descentralizado.

Uma abordagem diferente poderia ser usar apenas a chave pública do usuário para criptografar os dados. Os validadores então processam as operações homomórficas e os próprios usuários podem descriptografar o resultado, se necessário. Embora viável apenas para casos de uso de nicho, poderíamos evitar completamente a suposição de limite.

Para resumir, o FHE onchain precisa de uma implementação de MPC eficiente que: (1) funcione mesmo quando há atores maliciosos (2) introduza latência mínima (3) permita a entrada flexível/sem permissão de nós.

Prova de conhecimento zero (ZKP) para entrada do usuário e parte da computação

Desafio: Verificabilidade das entradas do usuário + computação:

Na web2, quando solicitamos a execução de uma tarefa computacional, confiamos completamente que uma determinada empresa executará a tarefa exatamente como prometeu nos bastidores. No web3, o modelo é completamente invertido; em vez de confiar na reputação de uma empresa e simplesmente confiar que ela agirá honestamente, agora estamos operando em um ambiente sem confiança, o que significa que os usuários não deveriam confiar em ninguém.

Embora o FHE permita o processamento de dados criptografados, ele não pode verificar a exatidão das entradas do usuário ou da computação. Sem a capacidade de verificar qualquer um deles, o FHE dificilmente será útil no contexto do blockchain.

Solução: ZKPs para entradas do usuário + equipe de computação:

Embora o FHE permita que qualquer pessoa realize cálculos arbitrários sobre dados criptografados, os ZKPs permitem provar que algo é verdadeiro sem revelar a própria informação subjacente. Então, como eles se relacionam?

Existem três maneiras principais pelas quais FHE e ZKPs se encaixam:

1. O usuário precisa enviar uma prova de que o texto cifrado de entrada está bem formado. O que significa que o texto cifrado atende aos requisitos do esquema de criptografia e não é apenas sequências arbitrárias de dados.
2. O usuário precisa enviar uma prova de que o texto simples de entrada satisfaz as condições de um determinado aplicativo. Ex. valor_saldo > valor_transferência
3. O nó validador (também conhecido como parte da computação) precisa provar que executou corretamente o cálculo do FHE. Isso é chamado de “FHE verificável” e pode ser visto como análogo aos ZKPs necessários para rollups.

Para explorar ainda mais as aplicações do ZKP:

1. ZKP de texto cifrado

O FHE é construído em criptografia baseada em rede, o que significa que a construção da primitiva criptográfica envolve redes, que são seguras PQ (pós-quântica). Em contraste, ZKPs populares como SNARKS, STARKS e Bulletproofs não dependem de criptografia baseada em rede.

Para provar que o texto cifrado FHE do usuário é bem formado, precisamos mostrar que ele satisfaz alguma equação matriz-vetor com entradas de anéis e que os valores numéricos desses elementos são pequenos. Essencialmente, precisamos de um sistema de prova de verificação on-chain econômico, projetado para lidar com relações baseadas em rede, que é uma área aberta de pesquisa.

1. ZKP de entrada de texto simples

Além de provar um texto cifrado bem formado, o usuário precisa provar que o texto simples de entrada satisfaz os requisitos da aplicação. Felizmente, ao contrário da etapa anterior, podemos utilizar SNARKs gerais para provar a validade das entradas do usuário, permitindo assim que os desenvolvedores façam uso dos esquemas, bibliotecas e infraestrutura ZKP existentes.

No entanto, a parte desafiadora é que precisamos “conectar” os dois sistemas de prova. Conecte-se como precisamos garantir que o usuário usou a mesma entrada para ambos os sistemas de prova; caso contrário, um usuário mal-intencionado poderá enganar o protocolo. Mais uma vez, este é um feito criptográfico incrivelmente difícil e uma área aberta para pesquisas iniciais.

A Sunscreen também lançou as bases com seu compilador ZKP, que oferece suporte para Bulletproofs, pois se conecta mais facilmente ao SDLP. O desenvolvimento futuro está sendo feito para “vincular” o compilador FHE e ZKP.

A Mind Network tem sido pioneira na integração de ZKPs para garantir entradas e saídas de confiança zero, além de aproveitar o FHE para computação segura.

1. ZKP de cálculo correto

A execução do FHE no hardware existente é extremamente ineficiente e cara. Como já vimos a dinâmica do trilema da escalabilidade acontecer antes, as redes com maiores requisitos de recursos de nós não podem ser dimensionadas para um nível suficiente de descentralização. Uma solução possível poderia ser um processo denominado “FHE verificável”, um processo em que a parte computacional (validador) envia um ZKP para provar a execução honesta das transações.

Um protótipo inicial de FHE verificável pode ser exibido por um projeto chamado SherLOCKED. Essencialmente, a computação FHE é transferida para o Bonsai do Risc ZERO, que processa a computação sobre os dados criptografados off-chain e retorna o resultado com um ZKP e atualiza o estado on-chain.

Um exemplo recente de aproveitamento de um coprocessador FHE pode ser visto na demonstração de leilão onchain da Aztec. Como abordamos anteriormente, as cadeias FHE existentes criptografam todo o estado com uma chave de limite, o que significa que o sistema é tão forte quanto o seu comitê de limite. Por outro lado, no Aztec, os usuários possuem seus próprios dados e, portanto, não estão sujeitos a uma suposição de segurança limite.

Por último, é importante abordar onde um desenvolvedor pode construir um aplicativo FHE. Os desenvolvedores podem construir seus aplicativos em um L1 alimentado por FHE, um rollup FHE ou construir em qualquer cadeia EVM e aproveitar um coprocessador FHE. Cada design vem com seu próprio conjunto de compensações, no entanto, estamos mais inclinados a rollups FHE bem projetados (dos quais Fhenix foi pioneiro) ou coprocessadores FHE, pois eles herdam a segurança do Ethereum, entre outros benefícios.

Até recentemente, obter provas de fraude em dados criptografados FHE era complexo, mas recentemente a equipe da Fhenix.io demonstrou como obter provas de fraude usando a pilha Arbitrum Nitro emparelhada com a compilação lógica FHE para WebAssembly.

Camada de Disponibilidade de Dados (DA) do FHE

Desafio: Falta de personalização e rendimento

Embora o armazenamento tenha sido comoditizado na web2, o mesmo não acontece na Web3. Dado que o FHE mantém uma grande explosão de dados de mais de 10.000x, precisamos descobrir onde armazenar grandes textos cifrados do FHE. Se cada operador de nó em uma determinada camada DA baixasse e armazenasse os dados de cada cadeia FHE, apenas os operadores institucionais seriam capazes de acompanhar a demanda, arriscando a centralização.

Em relação à taxa de transferência, o Celestia atinge 6,7 MB/s, se quisermos executar qualquer formato FHEML, precisaríamos facilmente de n GBs+/s. De acordo com dados recentes compartilhados por 1k(x), as camadas DA existentes não podem suportar FHE devido a decisões de design que limitam o rendimento (intencionalmente).

Solução: Dimensionamento Horizontal + Personalização

Precisamos de uma camada DA que possa suportar escalabilidade horizontal. As arquiteturas DA existentes propagam todos os dados para todos os nós da rede, o que é uma grande restrição à escalabilidade. Por outro lado, com a escalabilidade horizontal, à medida que mais nós DA entram no sistema, cada nó armazena 1/n dos dados, melhorando o desempenho e o custo à medida que mais espaço de bloco é disponibilizado.

Separadamente, dado o tamanho substancial dos dados associados ao FHE, faria sentido oferecer aos desenvolvedores um nível mais alto de personalização em torno dos limites de codificação de apagamento. ou seja Com quanto do sistema DA você se sente confortável com uma garantia? Quer seja a ponderação baseada em apostas ou a ponderação baseada na descentralização.

A arquitetura do EigenDA serve como base para a aparência de uma camada DA para FHE. Suas propriedades de escalabilidade horizontal, redução de custos estruturais, dissociação de DA e consenso, etc., tudo dá lugar a um nível de escalabilidade que um dia poderá apoiar o FHE.

Por último, uma ideia de alto nível poderia ser construir slots de armazenamento otimizados para armazenar textos cifrados FHE, uma vez que os textos cifrados seguem um esquema de codificação específico, portanto, ter slots de armazenamento otimizados pode ajudar no uso eficiente do armazenamento e na recuperação mais rápida.

Hardware de criptografia totalmente homomórfica (FHE)

Desafio: Hardware FHE de baixo desempenho

Na promoção de aplicações de criptografia totalmente homomórfica (FHE) on-chain, um problema importante é a latência significativa devido à sobrecarga computacional, o que torna a execução do FHE impraticável em qualquer hardware de processamento padrão. Essa limitação decorre da grande interação com a memória devido à enorme quantidade de dados que o processador precisa processar. Além das interações de memória, cálculos polinomiais complexos e operações demoradas de manutenção de texto cifrado também trazem muita sobrecarga.

Para entender melhor o estado dos aceleradores FHE, precisamos descobrir o espaço de design: aceleradores FHE específicos de aplicação versus aceleradores FHE generalizáveis.

O cerne da complexidade computacional e do design de hardware para FHE está sempre relacionado ao número de multiplicações necessárias para uma determinada aplicação, conhecido como “profundidade da operação homomórfica”. No caso específico da aplicação, a profundidade é conhecida, portanto os parâmetros do sistema e os cálculos relacionados são fixos. Portanto, o projeto de hardware para este caso específico de aplicação será mais fácil e geralmente pode ser otimizado para melhor desempenho do que o projeto de acelerador generalizável. No caso geral, onde o FHE é necessário para suportar um número arbitrário de multiplicações, o bootstrapping é necessário para remover parte do ruído acumulado nas operações homomórficas. Bootstrapping é caro e requer recursos de hardware consideráveis, incluindo memória no chip, largura de banda de memória e computação, o que significa que o design do hardware será muito diferente do design específico do aplicativo. Portanto, embora o trabalho realizado pelos principais players do setor, incluindo empresas como Intel, Duality, SRI, DARPA e muitos outros, esteja sem dúvida ultrapassando os limites com seus designs baseados em GPU e ASIC, eles podem não ser aplicáveis 1:1 a apoiar casos de uso de blockchain.

Em relação ao custo de desenvolvimento:Hardware generalizável requer mais capital para projetar e fabricar do que hardware específico para aplicação, mas sua flexibilidade permite que o hardware seja usado em um escopo de aplicação mais amplo. Por outro lado, com o design específico do aplicativo, se as necessidades de um aplicativo mudarem e exigirem suporte para computação homomórfica mais profunda, então o hardware específico do aplicativo precisaria ser combinado com algumas técnicas de software, como MPC, para atingir o mesmo fim que hardware generalizável.

É importante observar que o FHE onchain é muito mais difícil de acelerar do que os casos de uso específicos de aplicativos (ex.FHEML) porque requer a capacidade de processar cálculos mais gerais em vez de um conjunto mais específico. Para ilustrar, o fhEVM devnet está restrito a TPS de um dígito no momento.

Dado que precisamos de um acelerador FHE adaptado para blockchain, outra consideração é quão transferível é o trabalho do hardware ZKP para o hardware FHE?

Existem alguns módulos comuns entre ZKP e FHE, como a transformada teórica dos números (NTT) e as operações polinomiais subjacentes. No entanto, a largura de bits do NTT usada nesses dois casos é diferente. No ZKP, o hardware precisa suportar uma ampla faixa de largura de bits para NTT, como 64 bits e 256 bits, enquanto no FHE, os operandos para NTT são mais curtos por serem representados no sistema de numeração de resíduos. Em segundo lugar, o grau de NTT tratado no ZKP é em geral superior ao do caso FHE. Por essas duas razões, não é trivial projetar um módulo NTT que alcance desempenho satisfatório tanto para ZKP quanto para FHE. Além do NTT, existem alguns outros gargalos computacionais no FHE, como o automorfismo, que não estão presentes nos ZKPs. Uma maneira ingênua de transferir o hardware ZKP para a configuração FHE é descarregar a tarefa de computação NTT para o hardware ZKP e usar a CPU ou outro hardware para lidar com o restante da computação no FHE.

Para completar os desafios, a computação em dados criptografados com FHE costumava ser 100.000 vezes mais lenta do que em dados de texto simples. No entanto, graças aos esquemas de criptografia mais recentes e aos desenvolvimentos recentes no hardware FHE, o desempenho atual melhorou drasticamente para cerca de 100 vezes mais lento do que os dados de texto simples.

Soluções:

1. Melhoria no Hardware FHE

Há muitas equipes construindo ativamente aceleradores FHE, no entanto, elas não estão trabalhando em aceleradores FHE que sejam específicos para computação blockchain generalizável (ou seja, TFHE). Um exemplo de acelerador de hardware específico para blockchain é o FPT, um acelerador FPGA de ponto fixo. FPT é o primeiro acelerador de hardware a explorar fortemente o ruído inerente presente nos cálculos FHE, implementando o bootstrapping TFHE inteiramente com aritmética aproximada de ponto fixo. Outro projeto que pode ser útil para o FHE é o BASALISC, uma família de arquitetura de aceleradores de hardware que visa acelerar substancialmente os cálculos do FHE na nuvem.

Conforme indicado anteriormente, um dos principais gargalos no design de hardware FHE é a interação massiva com a memória. Para contornar esta barreira, uma solução potencial é reduzir ao máximo a interação com a memória. O processamento na memória (PIM) ou computação próxima à memória é provavelmente útil neste cenário. O PIM é uma solução promissora para enfrentar os desafios do “muro de memória” para futuros sistemas computacionais, que permite que a memória sirva tanto funções de computação quanto de memória, prometendo uma renovação radical da relação entre computação e memória. Na última década, um tremendo progresso foi feito no projeto de memórias não voláteis para esse propósito, como RAM resistiva, RAM magnética de torque de transferência de spin e memória de mudança de fase. Usando essa memória especial, tem havido trabalhos mostrando melhorias computacionais significativas no aprendizado de máquina e na criptografia de chave pública baseada em rede.

1. Software e hardware otimizados

Em desenvolvimentos recentes, o software foi reconhecido como um componente crítico no processo de aceleração de hardware. Por exemplo, aceleradores FHE proeminentes, como F1 e CraterLake, usam compiladores para uma abordagem híbrida de co-design de software/hardware.

À medida que o espaço avança, podemos esperar que compiladores totalmente funcionais sejam co-projetados com compiladores FHE específicos para blockchain. Os compiladores FHE podem otimizar programas FHE com base no modelo de custo do respectivo esquema FHE. Esses compiladores FHE podem ser integrados aos compiladores aceleradores FHE para melhorar o desempenho ponta a ponta, incorporando um modelo de custo do ponto de vista do hardware.

1. Aceleradores FHE de rede: a mudança de expansão para expansão

Os esforços existentes de aceleração de hardware FHE concentram-se principalmente na “aumento de escala”, o que significa focar na melhoria vertical de um único acelerador. Por outro lado, o “scale-out” coloca o foco na conexão de vários aceleradores FHE por meio de rede horizontal, o que poderia melhorar drasticamente o desempenho, semelhante à geração de provas paralelas com ZKPs.

Uma das principais dificuldades com a aceleração FHE é o problema da inflação de dados: refere-se ao aumento significativo no tamanho dos dados que ocorre durante a criptografia e a computação, apresentando desafios para a movimentação eficiente de dados entre memórias dentro e fora do chip.

A inflação de dados representa um desafio significativo para conectar vários aceleradores FHE por meio de redes horizontalmente. Portanto, o co-design de hardware e rede FHE será uma direção promissora de pesquisas futuras. Um exemplo poderia incluir um roteamento de rede adaptativo para aceleradores FHE: Implementação de um mecanismo de roteamento que ajuste dinamicamente os caminhos de dados entre aceleradores FHE com base na carga computacional em tempo real e no tráfego de rede. Isso garantiria taxas ideais de transferência de dados e utilização eficiente de recursos.

Conclusão

A FHE irá reimaginar fundamentalmente a forma como protegemos os dados em todas as plataformas, abrindo caminho para uma nova era de privacidade sem precedentes. Construir tal sistema exigirá avanços significativos não apenas no FHE, mas também nos ZKPs e MPC.

À medida que nos aventuramos nesta nova fronteira, os esforços colaborativos entre criptógrafos, engenheiros de software e especialistas em hardware serão imperativos. Sem mencionar legisladores, políticos, etc., uma vez que a conformidade regulamentar é o único caminho para a adoção generalizada.

Em última análise, a FHE estará na vanguarda de uma onda transformadora de soberania digital, anunciando um futuro onde a privacidade e a segurança dos dados não serão mais mutuamente exclusivas, mas inextricavelmente unificadas.

Agradecimentos especiais:

Muito obrigado a Mason Song (Mind Network), Guy Itzhaki (Fhenix), Leo Fan (Cysic), Kurt Pan, Xiang Xie (PADO), Nitanshu Lokhande (BananaHQ) pela revisão. Estamos ansiosos para ler sobre o trabalho e os esforços impressionantes que essas pessoas estão realizando em campo!

Isenção de responsabilidade:

1. Este artigo foi reimpresso de [HashKey Capital]. Todos os direitos autorais pertencem ao autor original [Jeffrey Hu、Arnav Pagidyala]. Se houver objeções a esta reimpressão, entre em contato com a equipe do Gate Learn e eles cuidarão disso imediatamente.
2. Isenção de responsabilidade: As opiniões e pontos de vista expressos neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe do Gate Learn. A menos que mencionado, é proibido copiar, distribuir ou plagiar os artigos traduzidos.