A rede principal Aptos permitirá 🔒 ativos confidenciais 💸 muito em breve!! o que significa, saldos e montantes de transação encriptados 🔐, embora com endereços de remetente e destinatário visíveis publicamente 🌍! (Um passo de cada vez, pessoal...) Aqui está como funcionam! 🤓👇

Os ativos confidenciais da Aptos baseiam-se e expandem trabalhos anteriores. Encriptamos saldos na cadeia usando Twisted ElGamal, como o PGC (). Isto compõe-se bem com Bulletproofs para provar que um saldo encriptado foi debitado corretamente após um envio/retiro confidencial.

Ou, como gosto de dizer muitas vezes [e sou alvo de gozações neste ponto]... "Veja o meu blog!"

*Feat 1:* Ao contrário do PGC e do Solana, os nossos ciphertexts de ElGamal Torcido são _agressivamente fragmentados_ para garantir uma decriptação super-rápida ao lidar com saldos e montantes de ~256 bits. Chamamos a isso *chunked'n'twisted ElGamal.* Para que conste, o Aptos só precisa de saldos de 128 bits e montantes de 64 bits.

Para Aptos, a fragmentação garante que a máxima instância de log discreto (DL) que precisa ser resolvida durante a decriptação é de 32 bits, no pior caso (e muito menor em média). => facilmente resolvível em 2^16 adições de curvas elípticas usando algoritmos simples como baby-step giant-step (BSGS)👇

*Feat 2:* Aceleramos o BSGS para a nossa escolha da curva elíptica Ristretto255 através de compressões em lote. Também reduzimos o tamanho da sua tabela pré-computada em 4x (=> reduz o tamanho e a latência do SDK de dapps confidenciais) Chamamos a este novo algoritmo *BSGS-k truncado (TBSGS-k).*

Já falei sobre este algoritmo antes: ...mas falhei em enfatizar o *porquê*: TBSGS-k é determinístico => mais simples de implementar e testar. TBSGS-k é apenas ~2x mais lento (10,6 ms vs 4,8 ms) do que o algoritmo [BL12] mais complexo, e tem apenas tabelas 2x maiores.

*Funcionalidade 3:* Quando a auditoria está ativada, mantemos uma criptografia comprovadamente correta do saldo (disponível) de cada usuário sob a chave de criptografia do auditor (EK). Isto impede que os auditores escaneiem as TXNs dos usuários para reconstruir o seu saldo. Chave: permite rotações da EK do auditor 👌

*Feat 4:* Em Aptos, a rotação da chave de _assinatura_ do usuário é uma característica central de segurança. Portanto: também projetámos ativos confidenciais para suportar a rotação da chave de *descriptografia* do usuário! Por agora, as políticas de gestão de chaves são deixadas para aplicações/carteiras (últimas palavras famosas 🤞).

A boa notícia: dapps confidenciais sem chave podem reutilizar com segurança o seu 🌶️ como uma chave de decriptação! () ==> não há carga adicional de gestão de chaves introduzida para tais aplicações ==> a maneira mais fácil de construir um dapp confidencial é como um dapp sem chave; não é necessário [suporte] de carteira!

*Feat 5:* Implementar criptografia que protege os fundos reais dos usuários é aterrorizante. Para minimizar erros (🤞), usamos uma metodologia amplamente negligenciada para projetar e compor protocolos Sigma de forma segura: A *estrutura de homomorfismo,* que descobri no livro do @danboneh 🙏

*Feat 6:* A primeira implementação de ativos confidenciais pronta para produção em Move. O código está atualmente privado enquanto passa por uma auditoria, mas será lançado em breve. Aqui está uma prévia de quão simples pode ser uma transferência confidencial 👇

Além disso, porque não consigo evitar, aqui está parte do nosso framework de homomorfismo do protocolo Sigma implementado em Move 😍

*Feat 7:* Especificação criptográfica completa com provas de segurança. (Talvez possamos codificá-la em @leanprover?) Em breve, com os detalhes picantes, em um eprint ao seu lado 👇

Por último, crédito onde o crédito é devido: os ativos confidenciais da Aptos baseiam-se e expandem ideias introduzidas em trabalhos anteriores 👇 1. Zether (): problema de "front-running" do modelo de conta fixa através de saldos pendentes

2. PGC (): propôs Twisted ElGamal + Bulletproofs como uma alternativa mais simples aos \Sigma-bullets. Isto reduz drasticamente a complexidade de implementação: só precisamos nos concentrar em projetar corretamente nossos protocolos Sigma! A composição segura é discutida abaixo 👇

3. Solana (): permitiu montantes transferidos de 48 bits ao dividir o saldo pendente em um pedaço "alto" de 32 bits e um pedaço "baixo" de 16 bits. Permitimos montantes maiores usando um número maior de pedaços e, adicionalmente, dividindo o saldo disponível também.

Por último, mas não menos importante, quero agradecer ao @mstrakastrak e ao pessoal da @distributedlab, que ajudaram a desenhar a versão inicial do protocolo de ativos confidenciais e a implementá-lo em Move e TypeScript 🖖 Fiquem atentos ao nosso artigo conjunto que será publicado em breve!