)

Ideias essenciais:

1. FE promete ser o “Santo Graal da Criptografia”, no entanto, existem muitas preocupações de desempenho, experiência de desenvolvedor e segurança que limitam a sua adoção atual.

2. Como mostrado no gráfico acima, o FE precisará ser usado ao lado de ZKPs e MPC para construir um sistema de estado partilhado verdadeiramente confidencial e seguro.

3.FHA está a evoluir rapidamente; O desenvolvimento de novos compiladores, bibliotecas, hardware etc. Sem mencionar que o FHEW beneficia imensamente do R & D das empresas Web2 (Intel, Google, DARPA etc.).

4.À medida que o FUE e o seu ecossistema circundante amadurece, esperamos ver o “FE verificável” tornar-se o padrão. As aplicações FE podem optar por terceirizar a computação e a verificação para os coprocessadores FE.

5.Uma limitação fundamental do FHA onchain é “quem detém a chave de descriptografia?” A descriptografia de limiar e o MPC oferecem soluções, no entanto, geralmente estão vinculados por uma compensação de segurança & de desempenho.

Introdução:

A natureza transparente dos blockchains é uma espada 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 cripto há quase uma década. Embora existam muitas equipas a construir sistemas baseados em ZK para alcançar a privacidade na cadeia; não podem suportar um estado partilhado e encriptado. Porquê? A resposta curta é porque estes programas são uma função de uma série de ZKPs e, como tal, é impossível para alguém aplicar lógica arbitrária ao estado atual. O que é que isto significa? Basicamente, não podemos construir aplicações confidenciais de estado partilhado (pense no 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 um DeFi totalmente generalizável e confidencial. Como? FHA é um campo florescente de criptografia que permite computação arbitrária sobre dados criptografados (parece loucura certo?!) Como mostrado no gráfico acima, os ZKPs podem provar a integridade das entradas e do cálculo do utilizador, e o FHA pode processar o próprio cálculo.

Enquanto o FSE promete ser o “Santo Graal da Criptografia”, tentamos fornecer uma análise objetiva do campo e dos seus vários desafios e possíveis soluções. Cobrimos os seguintes tópicos de FUE em cadeia:

• Esquemas FHA, Bibliotecas e Compiladores
• Descriptografia de limiar seguro
• ZKPs para Entradas do Utilizador+Grupo de Computação
• Camada DA programável e escalável
• O Hardware

Esquemas FHA, Bibliotecas e Compiladores

Desafio: Esquemas FHA Nascentes, Bibliotecas e Compiladores

O gargalo fundamental do FE onchain reside nas suas ferramentas de programador/infra atrasadas. Ao contrário dos ZKPs ou MPC, o FUE só existe desde 2009 e, portanto, tinha um prazo muito mais curto para amadurecer.

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

• Uma linguagem front-end fácil de usar para os programadores programarem sem muito conhecimento da criptografia de back-end
• Um compilador FHA 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 de FH existentes (particularmente TFUE) são cerca de 1000x mais lentos em comparação com a computação simples

Para compreender verdadeiramente os meandros da integração do FHEN, vamos percorrer a jornada do programador:

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

Como mostrado na tabela acima, circuitos booleanos como o FHEW & TFHA têm o bootstrapping mais rápido 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; Enquanto o BGV/BFV pode ser adequado para o DeFi geral, pois são mais eficientes em cálculos aritméticos de alta precisão, mas os programadores têm de saber a profundidade do circuito avançar para configurar todos os parâmetros do esquema. No outro extremo do espectro, o CKKS suporta a multiplicação homomórfica onde são permitidos erros de precisão, tornando-o ideal para casos de uso não precisos, como ML.

Como desenvolvedor, precisa escolher uma solução FHE com muito cuidado, pois isso 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 FHA, tais como a escolha do tamanho do módulo e o papel do grau polinomial.

Passando para bibliotecas, as funcionalidades e capacidades das populares bibliotecas FHE podem ser vistas na tabela abaixo:

Mas as bibliotecas também têm relações diferentes com esquemas e compiladores, como mostrado abaixo:

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

Neste ponto, os programadores podem perguntar:

Quão grande tem de ser o meu espaço de texto simples? Qual a magnitude dos textos cifrados aceitáveis? Onde posso paralelizar a computação? E muito mais...

Além disso, embora o FUE possa suportar cálculos arbitrários, os programadores precisam de mudar a sua mentalidade ao escrever programas FE. Por exemplo, não se pode escrever uma ramificação (se não) 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 programadores precisam de alterar o seu código de ramificações para algum tipo de computação que possa incorporar as condições de todas as ramificações. Da mesma forma, isso impede que os programadores escrevam loops no seu código.

Resumindo, para um programador não iniciado no FSE, é quase impossível integrar o FE na sua aplicação. Vai exigir ferramentas de desenvolvimento significantes/infra para abstrair as complexidades apresentadas pelo Fhe.

Solução:

1. Compiladores FHA específicos da Web3

Embora já existam compiladores FHA construídos por Google e Microsoft, são eles:

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

Isso é até o compilador Sunscreen FE. É um compilador nativo da Web3 que oferece alguns dos melhores desempenhos para operações aritméticas (pense no DeFi) sem aceleradores de hardware. Como discutido acima, a seleção de parâmetros é indiscutivelmente a parte mais difícil da implementação de um esquema FHA; O protetor solar não só tem seleção automática de parâmetros, mas codificação de dados, seleção de chaves, implementa relinearização e comutação de módulo, configura os circuitos e implementa operações de estilo SIMD.

À medida que avançamos para o futuro, esperamos ver mais otimizações não só no compilador Sunscreen, mas outras equipas a construir as suas próprias implementações que suportam outras linguagens de alto nível.

1. Nova biblioteca FE

Enquanto os investigadores continuam a explorar novos esquemas poderosos, as bibliotecas FHA podem permitir que mais programadores integrem o FHA.

Vamos tomar os contratos inteligentes FHEE como exemplo. Embora possa ser difícil escolher entre diferentes bibliotecas FHE, torna-se mais fácil quando falamos de 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 num EVM típico, expondo operações homomórficas como contratos pré-compilados. Permitir eficazmente que os programadores utilizem dados encriptados nos seus contratos, sem quaisquer alterações nas ferramentas de compilação.

Para outros cenários específicos, pode ser necessária alguma outra infraestrutura. Por exemplo, a biblioteca TFHA escrita em C++ não é tão bem mantida como a versão Rust. Embora os TFHE-Rs possam suportar exportações para C/C++, se os programadores C++ quiserem melhor compatibilidade e desempenho, têm de escrever a sua própria versão da biblioteca TFHE-S.

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

Descriptografia de limiar seguro

Desafio: Descriptografia de limiar não seguro/centralizada

Cada sistema de estado partilhado confidencial baseia-se numa chave de encriptação/descriptografia. Nenhuma parte é confiável, portanto, a chave de descriptografia é partilhada entre os participantes da rede.

Um dos aspetos mais desafiadores do FHA onchain (Threshold FHA) é a construção de um protocolo de descriptografia de limiar seguro e com desempenho. Existem dois gargalos principais: (1) O cálculo baseado em FHEE introduz sobrecarga significativa, consequentemente exigindo nós de alto desempenho que reduzem inerentemente o tamanho potencial do conjunto de validadores (2) À medida que o número de nós que participam no protocolo de descriptografia aumenta, a latência aumenta.

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

E se os nós de limiar conluírem? Eles seriam capazes de ignorar o protocolo e basicamente descriptografar qualquer coisa, desde entradas do utilizador a quaisquer dados na cadeia. Além disso, é importante notar que o protocolo de descriptografia pode acontecer indetectavelmente nos sistemas atuais (também conhecido como “ataque silencioso”).

Solução: Descriptografia de limiar melhorada ou MPC dinâmico

Existem algumas maneiras de possivelmente resolver as deficiências da descriptografia de limiares. (1) Activar um limiar n/2 que tornaria mais difícil o conluio (2) Execute o protocolo de descriptografia de limiar dentro de um HSM (3) Use uma rede de descriptografia de limite baseada em TEE controlada por uma cadeia descentralizada para autenticação permitindo a gestão dinâmica de chaves.

Em vez de descriptografia do limite de alavancagem, é possível usar o MPC em vez disso. Um exemplo de um protocolo MPC que poderia ser usado em FHEs onchain inclui o novo 2PC-MPC da Odsy, o primeiro algoritmo MPC não colusivo e massivamente descentralizado.

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

Para resumir, o FHA onchain precisa de uma implementação MPC eficiente que: (1) Funciona mesmo quando existem agentes mal-intencionados (2) Introduz latência mínima (3) Permite a entrada de nós sem permissão/flexível.

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

Desafio: Verificabilidade das entradas do utilizador + Computação:

Na web2, quando pedimos que uma tarefa computacional seja executada, confiamos completamente que uma determinada empresa irá executar a tarefa exatamente como prometeu nos bastidores. Na web3, o modelo está completamente invertido; em vez de depender da reputação de uma empresa e simplesmente confiar que agirão honestamente, estamos agora a operar num ambiente sem confiança, o que significa que os utilizadores não devem ter de confiar em ninguém.

Embora o FHA permita o processamento de dados encriptados, não pode verificar a exatidão das entradas do utilizador ou do cálculo. Sem a capacidade de verificar nenhum dos dois, o FUE dificilmente é útil no contexto da blockchain.

Solução: ZKPs para Entradas do Utilizador+Grupo de Computação:

Enquanto o FHA permite a qualquer pessoa realizar cálculos arbitrários sobre dados encriptados, os ZKPs permitem provar que algo é verdade sem revelar a própria informação subjacente. Então, como eles se relacionam?

Existem três maneiras principais de o FUE e os ZKPs se encaixarem:

1. O utilizador tem de apresentar uma prova de que o texto cifrado de entrada está bem formado. O que significa que o texto cifrado cumpre os requisitos do esquema de encriptação e não são apenas cadeias de dados arbitrárias.
2. O utilizador tem de apresentar uma prova de que o seu texto simples de entrada satisfaz as condições de uma determinada aplicação. Ex. saldo de montante > amount_transfer
3. O nó validador (também conhecido como grupo de computação) precisa de provar que executou corretamente o cálculo FH. Isto é referido como “FUE verificável” e pode ser visto como análogo aos ZKPs necessários para os rollups.

Para explorar melhor as aplicações do ZKP:

1. ZIP ou texto cifrado

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

Para provar que o texto cifrado FHEW do utilizador está bem formado, precisamos mostrar que satisfaz alguma equação matrix-vetor com entradas de anéis e que os valores numéricos destes elementos são pequenos. Essencialmente, precisamos de um sistema de prova de verificação em cadeia 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 utilizador precisa provar que o texto simples de entrada satisfaz os requisitos de uma aplicação. Felizmente, ao contrário do passo anterior, podemos utilizar SNARKs gerais para provar a validade em torno das entradas do utilizador, permitindo assim que os programadores façam uso dos esquemas, bibliotecas e infra-estruturas ZKP existentes.

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

O protetor solar também lançou as bases com o seu compilador ZKP que oferece suporte para Bulletproofs, uma vez que se conecta mais facilmente com o SDLP. O desenvolvimento futuro está a ser feito para “ligar” o compilador FHO 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 alavancar o FHET para uma computação segura.

1. ZKP de Computação Correcta

O funcionamento com hardware existente é extremamente ineficiente e caro. Como vimos a dinâmica do trilema da escalabilidade acontecer antes, as redes com requisitos de recursos de nós mais elevados não podem ser dimensionadas para um nível suficiente de descentralização. Uma possível solução poderia ser um processo denominado “FHO verificável”, um processo em que a parte informática (validador) submete um ZKP para provar a execução honesta das transações.

Um protótipo inicial de FHEE verificável pode ser apresentado por um projeto chamado SherLocked. Essencialmente, o cálculo FHA é descarregado para o Bonsai do Risco ZERO que processa o cálculo sobre os dados criptografados fora da cadeia e retorna o resultado com um ZKP e atualiza o estado na cadeia.

Um exemplo recente de alavancagem de um coprocessador FE pode ser visto com a demonstração de leilão onchain da Aztec. Como abordamos anteriormente, as cadeias FHA existentes encriptam todo o estado com uma chave de limite, o que significa que o sistema é tão forte quanto o seu comité de limiares. Por outro lado, em asteca, o utilizador possui os seus próprios dados e, portanto, não está sujeito a uma suposição de segurança limite.

Por último, é importante abordar onde um programador pode construir uma aplicação FE em primeiro lugar. Os Desenvolveiros podem construir as suas aplicações num L1 alimentado por FHE/num rollup de FE ou construir em qualquer cadeia EVM e alavancar um coprocessador FHEN. Cada design vem com o seu próprio conjunto de compensações, no entanto, estamos mais inclinados a rollups FHA bem concebidos (pioneiros pela Fhenix) ou coprocessadores FHA, uma vez que herdam a segurança do Ethereum entre outros benefícios.

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

Disponibilidade de dados (DA) Camada de FHA

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 FHA mantém um grande aumento de dados de 10.000x+, precisamos de descobrir onde armazenar grandes cifertextos FHA. Se todos os operadores de nós numa determinada camada DA fizessem download e armazenassem todos os dados da cadeia FHA, apenas os operadores institucionais seriam capazes de acompanhar a procura, arriscando a centralização.

Em relação ao rendimento, o Celestia é de 6,7 mb/s, se quisermos executar qualquer forma FHEML, precisaríamos facilmente de n GBs+/ seg. De acordo com dados recentes partilhados por 1k (x), as camadas de DA existentes não podem suportar FHA 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 para a escalabilidade. Por outro lado, com escalabilidade horizontal, à medida que mais nós de DA entram no sistema, cada nó está a armazenar 1/nésimo dos dados, melhorando o desempenho e o custo à medida que mais espaço em bloco é disponibilizado.

Separadamente, dado o tamanho substancial dos dados associado ao FHA, faria sentido oferecer aos programadores um nível mais elevado de personalização em torno dos limites de codificação de eliminação. ou seja Com quanto do sistema DA se sente confortável com uma garantia? Quer seja ponderação baseada em participações ou ponderação baseada na descentralização.

A arquitetura do eiGenda serve de base para o que poderia ser uma camada DA para o FHE. São 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 poderá um dia suportar o FHA.

Por último, uma ideia de alto nível poderia ser construir slots de armazenamento otimizados para armazenar textos cifrados FH, 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 encriptação totalmente homomórfica (FH)

Desafio: Hardware FHO de baixo desempenho

Na promoção de aplicações de encriptação totalmente homomórfica (FHA) em cadeia, um problema importante é a latência significativa devido à sobrecarga computacional, o que torna a execução de FH impraticável em qualquer hardware de processamento padrão. Esta limitação decorre da grande quantidade de 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 FH, precisamos descobrir o espaço do projeto: Aceleradores FH específicos da aplicação vs. aceleradores FH generalizáveis.

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

Em relação ao custo de desenvolvimento：O hardware generalizável requer mais capital para projetar e fabricar do que o específico da aplicação, mas a sua flexibilidade permite que o hardware seja utilizado num âmbito de aplicação mais amplo. Por outro lado, com o design específico da aplicação, se as necessidades de uma aplicação mudarem e exigirem suporte para computação homomórfica mais profunda, então o hardware específico da aplicação teria de ser combinado com algumas técnicas de software, como o MPC, para atingir o mesmo fim que o hardware generalizável.

É importante notar que o FHE onchain é muito mais difícil de acelerar do que os casos de uso específicos da aplicação (ex.FHEML) porque requer a capacidade de processar cálculos mais gerais versus um conjunto mais nicho. Para ilustrar, o fheVM devnet está limitado a TPS de um dígito no momento.

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

Existem alguns módulos comuns entre o ZKP e o FH, tais como a transformada teórica dos números (NTT) e as operações polinomiais subjacentes. No entanto, a largura de bits do NTT utilizado nestes dois casos é diferente. No ZKP, o hardware precisa suportar uma ampla gama de largura de bits para NTT, como 64 bits e 256 bits, enquanto no FHD, os operandos para NTT são mais curtos devido a estarem representados no sistema de número de resíduos. Em segundo lugar, o grau de NTT tratado no ZKP é, em geral, superior ao do caso FE. Por estas duas razões, não é trivial conceber um módulo NTT que atinja um desempenho satisfatório tanto para o ZKP como para o FHA. Para além do NTT, existem outros estrangulamentos informáticos no FE, como o automorfismo, que não estão presentes nos ZKPs. Uma maneira ingénua de transferir hardware ZKP para a configuração FE é descarregar a tarefa de computação NTT para o hardware ZKP e usar a CPU ou outro hardware para lidar com o resto da computação no FHE.

Para completar os desafios, o cálculo de dados encriptados com FHA costumava ser 100.000 vezes mais lento do que em dados de texto simples. No entanto, graças aos esquemas de encriptação mais recentes e aos desenvolvimentos recentes no hardware FHA, o desempenho atual melhorou drasticamente para cerca de 100x mais lento do que os dados em texto simples.

Soluções:

1. Melhoria no Hardware FE

Existem muitas equipas a construir ativamente aceleradores FHA, no entanto, não estão a trabalhar em aceleradores FHA específicos para computação blockchain generalizável (i.e. TO). Um exemplo de um acelerador de hardware específico de blockchain é o FPT, um acelerador FPGA de ponto fixo. O FPT é o primeiro acelerador de hardware a explorar fortemente o ruído inerente presente nos cálculos FE implementando o bootstrapping TFE inteiramente com aritmética aproximada de ponto fixo. Outro projeto que poderia ser útil para o FUE é o BASALISC, uma família de arquitectura de aceleradores de hardware que visa acelerar substancialmente os cálculos FHE na nuvem.

Como referido anteriormente, um dos principais estrangulamentos no design do hardware FHA é 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 a computação perto da memória provavelmente é útil neste cenário. O PIM é uma solução promissora para enfrentar os desafios da “parede da memória” para futuros sistemas informáticos, o que permite que a memória sirva tanto as funções de computação como de memória, prometendo uma renovação radical da relação entre computação e memória. Na última década, foram feitos progressos tremendos na concepção das memórias não voláteis para este fim, tais como RAM resistiva, RAM magnética de torque de transferência de rotação e memória de mudança de fase. Usando esta memória especial, houve trabalhos que mostram melhorias significativas da computação no aprendizado de máquina e na encriptação 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 FHA 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-desenhados com compiladores FHA específicos da blockchain. Os compiladores FHA podem otimizar os programas FHA com base no modelo de custo do respetivo esquema FHA. Estes compiladores FHA podem ser integrados com compiladores de aceleradores FHA para melhorar o desempenho de ponta a ponta, incorporando um modelo de custo a partir de um aspecto a nível de hardware.

1. Aceleradores FHE em rede: A mudança do Scale-up para Scale-out

Os esforços existentes de aceleração de hardware do FE concentram-se em grande parte no “scale-up”, o que significa concentrar-se na melhoria de um único acelerador verticalmente. Por outro lado, o “scale-out” coloca o foco na ligação de vários aceleradores FE através de redes horizontalmente, o que poderia melhorar drasticamente o desempenho, semelhante à geração de prova paralela com ZKPs.

Uma das principais dificuldades com a aceleração do FHA é o problema da inflação dos dados: Refere-se ao aumento significativo do tamanho dos dados que ocorre durante a encriptação e a computação, colocando desafios para a movimentação eficiente de dados entre as memórias on-chip e off-chip.

A inflação dos dados representa um desafio significativo para ligar vários aceleradores FHA através de redes horizontalmente. Portanto, o co-design de hardware e rede FHO será uma direção promissora de pesquisas futuras. Um exemplo poderia incluir um encaminhamento de rede adaptativo para aceleradores FHA: Implementação de um mecanismo de encaminhamento que ajusta dinamicamente os caminhos de dados entre os aceleradores FHA 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 dos recursos.

Conclusão

FHA irá fundamentalmente reimaginar a forma como protegemos os dados através das plataformas, abrindo caminho para uma nova era de privacidade sem precedentes. Construir um sistema deste tipo exigirá avanços significativos não só no FSE, 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 falar dos legisladores, políticos etc. já que a conformidade regulamentar é o único caminho para a adoção convencional.

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

Agradecimento especial：

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 impressionante e os esforços que estas pessoas estão a fazer no terreno!

Isenção de responsabilidade：

1. Este artigo foi reimpresso da [HashKey Capital]. Todos os direitos de autor pertencem ao autor original [Jeffrey Hu、Arnav Pagidyala]. Se houver objeções a esta reimpressão, contacte a equipa do Gate Learn, e eles tratarão disso imediatamente.
2. Isenção de responsabilidade: As opiniões e opiniões expressas neste artigo são exclusivamente do autor e não constituem nenhum conselho de investimento.
3. As traduções do artigo para outras línguas são feitas pela equipa do Gate Learn. A menos que mencionado, é proibido copiar, distribuir ou plagiar os artigos traduzidos.