Aptos mainnet kommer snart att aktivera 🔒 konfidentiella tillgångar 💸!! dvs. krypterade saldon och transaktionsbelopp 🔐, om än med offentligt synliga 🌍 avsändar- och mottagaradresser! (Ett steg i taget, allihop...) Så här fungerar de! 🤓👇

Aptos konfidentiella tillgångar bygger vidare på och utvidgar tidigare arbete. Vi krypterar saldon on-chain med Twisted ElGamal, som PGC (). Detta fungerar bra med Bulletproofs för att bevisa att ett krypterat saldo debiterades korrekt efter en konfidentiell sändning/uttag.

Eller, som jag ofta säger [och blir retad vid det här laget]... "Se min blogg!"

*Bedrift 1:* Till skillnad från PGC och Solana är våra Twisted ElGamal-chiffertexter _aggressively-chunked_ för att säkerställa supersnabb dekryptering samtidigt som vi hanterar balanser och mängder på ~256 bitar. Vi döper detta *chunk'n' twisted ElGamal.* För övrigt behöver Aptos bara 128-bitars balanser och 64-bitars mängder.

För Aptos garanterar chunking att den maximala diskreta log (DL)-instansen som behöver lösas under dekrypteringen är 32-bitars i värsta fall (och i genomsnitt mycket mindre). => lätt lösbar i 2^16 elliptiska kurvadditioner med hjälp av enkla algoritmer som baby-step giant-step (BSGS) 👇

*Bedrift 2:* Vi snabbar upp BSGS för vårt val av Ristretto255 elliptisk kurva via batchkomprimeringar. Vi minskar också dess förberäknade tabellstorlek med 4x (=> minskar SDK-storleken och latensen på konfidentiella dapps) Vi kallar denna nya algoritm *trunkerad BSGS-k (TBSGS-k).*

Jag har diskuterat den här algoritmen tidigare: ... men misslyckades med att betona *varför*: TBSGS-k är deterministisk => enklare att implementera och testa. TBSGS-k är bara ~2 gånger långsammare (10,6 ms mot 4,8 ms) än den mer komplexa [BL12]-algoritmen och har endast 2 gånger större tabeller.

*Bedrift 3:* När revision är aktiverad upprätthåller vi en bevisbart korrekt kryptering av varje användares (tillgängliga) saldo under revisorns krypteringsnyckel (EK). Detta utesluter revisorer från att skanna användarnas TXN för att återskapa deras saldo. Nyckel: det möjliggör revisors EK-rotationer 👌

*Feat 4:* I Aptos är användarens _signerande_ nyckelrotation en central säkerhetsfunktion. Så: vi designade också konfidentiella tillgångar för att stödja användarens *dekryptering* nyckelrotation! För tillfället lämnas nyckelhanteringspolicyer till applikationer/plånböcker (kända sista ord 🤞).

Den goda nyheten: Nyckellösa konfidentiella dappar kan säkert återanvända dem 🌶️ som dekrypteringsnyckel! () ==> ingen extra nyckelhanteringsbelastning infördes för sådana applikationer ==> enklaste sättet att bygga en konfidentiell dapp är som en nyckellös dapp; Ingen plånbok [support] behövs!

*Bedrift 5:* Att implementera krypto(*graf*) som säkrar riktiga användarmedel är skrämmande. För att minimera fel (🤞), använder vi en till stor del förbisedd metodik för att säkert designa och komponera Sigma-protokoll: *homomorfiramen*, som jag upptäckte i @danboneh bok 🙏

*Feat 6:* Den första produktionsklara konfidentiella tillgångsimplementeringen i Move. Koden är för närvarande privat medan den genomgår en revision, men kommer att släppas snart. Här är en försmak på hur enkel en konfidentiell överföring kan vara 👇

Dessutom, eftersom jag inte kan hjälpa det, här är en del av vårt Sigma-protokoll-homomorfiramverk implementerat i Move 😍

*Bedrift 7:* Fullständig kryptografisk specifikation med säkerhetsbevis. (Kanske kan vi vibe koda det i @leanprover?) Kommer snart, med de kryddiga detaljerna, i en eprint bredvid dig 👇

Slutligen, erkännande där det är förtjänt: Aptos konfidentiella tillgångar bygger vidare på och utvidgar idéer som introducerats i tidigare arbete 👇 1. Zether (): fasta kontomodellens "front-running"-problem via väntande saldon

2. PGC (): föreslog Twisted ElGamal + Bulletproofs som ett enklare alternativ till \Sigma-bullets. Detta minskar implementeringskomplexiteten drastiskt: vi behöver bara fokusera på att korrekt designa våra Sigma-protokoll! Säker sammansättning argumenteras nedan 👇

3. Solana (): möjliggjorde 48-bitars överförda belopp genom att dela upp den väntande balansen i en "hög" 32-bitars bit och en "låg" 16-bitars chunk. Vi tillåter större belopp genom att använda ett större antal chunkar och dessutom chunking på det tillgängliga saldot.

Sist men inte minst vill jag tacka @mstrakastrak och folket på @distributedlab som hjälpte till att designa den initiala versionen av det konfidentiella tillgångsprotokollet och implementera det i Move och TypeScript 🖖 Håll utkik efter vår gemensamma artikel som snart kommer ut!