La mainnet di Aptos abiliterà 🔒 asset riservati 💸 molto presto!! i.e., saldi e importi delle transazioni crittografati 🔐, sebbene con indirizzi del mittente e del destinatario visibili pubblicamente 🌍! (Un passo alla volta, ragazzi...) Ecco come funzionano! 🤓👇

Gli asset riservati di Aptos si basano e ampliano il lavoro precedente. Cifriamo i saldi on-chain utilizzando Twisted ElGamal, come PGC (). Questo si combina bene con Bulletproofs per dimostrare che un saldo cifrato è stato addebitato correttamente dopo un invio/prelievo riservato.

Oppure, come mi piace spesso dire [e di cui vengo preso in giro a questo punto]... "Guarda il mio blog!"

*Caratteristica 1:* A differenza di PGC e Solana, i nostri ciphertext di ElGamal distorti sono _aggressivamente suddivisi_ per garantire una decrittazione super veloce mentre gestiscono saldi e importi di ~256 bit. Lo chiamiamo *chunked'n'twisted ElGamal.* Per quanto ne so, Aptos ha bisogno solo di saldi a 128 bit e importi a 64 bit.

Per Aptos, il chunking garantisce che l'istanza massima di log discreto (DL) che deve essere risolta durante la decrittazione sia di 32 bit, nel caso peggiore (e molto più piccola in media). => facilmente risolvibile in 2^16 aggiunte di curve ellittiche utilizzando algoritmi semplici come baby-step giant-step (BSGS)👇

*Caratteristica 2:* Acceleriamo BSGS per la nostra scelta della curva ellittica Ristretto255 tramite compressioni in batch. Riduciamo anche la dimensione della sua tabella pre-calcolata di 4 volte (=> riduciamo la dimensione e la latenza dell'SDK delle dapps riservate). Chiamiamo questo nuovo algoritmo *BSGS-k troncato (TBSGS-k).*

Ho già parlato di questo algoritmo prima: ...ma non ho sottolineato il *perché*: TBSGS-k è deterministico => più semplice da implementare e testare. TBSGS-k è solo ~2x più lento (10,6 ms contro 4,8 ms) rispetto all'algoritmo [BL12] più complesso, e ha solo tabelle 2x più grandi.

*Caratteristica 3:* Quando l'auditing è abilitato, manteniamo una crittografia provabilmente corretta del saldo (disponibile) di ciascun utente sotto la chiave di crittografia dell'auditor (EK). Questo impedisce agli auditor di esaminare le TXN degli utenti per ricostruire il loro saldo. Chiave: consente le rotazioni della EK dell'auditor 👌

*Caratteristica 4:* In Aptos, la rotazione della chiave _di firma_ dell'utente è una funzione di sicurezza centrale. Quindi: abbiamo anche progettato asset riservati per supportare la rotazione della chiave *di decrittazione* dell'utente! Per ora, le politiche di gestione delle chiavi sono lasciate alle applicazioni/portafogli (famosi ultimi parole 🤞).

La buona notizia: le dapp riservate senza chiave possono riutilizzare in sicurezza il loro 🌶️ come chiave di decrittazione! () ==> non viene introdotto alcun onere di gestione delle chiavi extra per tali applicazioni ==> il modo più semplice per costruire una dapp riservata è come dapp senza chiave; non è necessaria alcuna [supporto] per il wallet!

*Caratteristica 5:* Implementare la crittografia che protegge i fondi reali degli utenti è spaventoso. Per ridurre al minimo gli errori (🤞), utilizziamo una metodologia ampiamente trascurata per progettare e comporre in sicurezza i protocolli Sigma: Il *framework dell'omomorfismo,* che ho scoperto nel libro di @danboneh 🙏

*Caratteristica 6:* La prima implementazione di asset riservati pronta per la produzione in Move. Il codice è attualmente privato mentre è in fase di audit, ma sarà rilasciato a breve. Ecco un'anticipazione di quanto possa essere semplice un trasferimento riservato 👇

Inoltre, poiché non posso farne a meno, ecco parte del nostro framework di omomorfismo del protocollo Sigma implementato in Move 😍

*Caratteristica 7:* Specifica crittografica completa con prove di sicurezza. (Cavolo, forse possiamo codificarlo in @leanprover?) In arrivo, con i dettagli piccanti, in un eprint accanto a te 👇

Infine, il merito va dato a chi di dovere: gli asset riservati di Aptos si basano e ampliano idee introdotte in lavori precedenti 👇 1. Zether (): risolve il problema del "front-running" del modello di conto fisso tramite saldi in attesa

2. PGC (): propone Twisted ElGamal + Bulletproofs come un'alternativa più semplice a \Sigma-bullets. Questo riduce drasticamente la complessità di implementazione: dobbiamo solo concentrarci sul progettare correttamente i nostri protocolli Sigma! La composizione sicura è discussa di seguito 👇

3. Solana (): ha consentito importi trasferiti a 48 bit suddividendo il saldo in attesa in un blocco "alto" da 32 bit e un blocco "basso" da 16 bit. Consentiamo importi maggiori utilizzando un numero maggiore di blocchi e suddividendo anche il saldo disponibile.

Ultimo ma non meno importante, voglio ringraziare @mstrakastrak e le persone di @distributedlab, che hanno aiutato a progettare la versione iniziale del protocollo per asset riservati e a implementarlo in Move e TypeScript 🖖 State attenti al nostro documento congiunto che uscirà presto!