Aptosin pääverkko mahdollistaa 🔒 luottamukselliset resurssit 💸 hyvin pian!! Eli salatut saldot ja tapahtumasummat 🔐, vaikkakin julkisesti 🌍 näkyvillä lähettäjä- ja vastaanottajaosoitteilla! (Yksi askel kerrallaan, ihmiset...) Näin ne toimivat! 🤓👇

Aptosin luottamukselliset omaisuuserät rakentuvat ja laajentavat aiempaa työtä. Salaamme saldot ketjussa Twisted ElGamalilla, kuten PGC (). Tämä toimii hyvin Bulletproofsin kanssa todistaakseen, että salattu saldo on veloitettu oikein luottamuksellisen lähetyksen/noston jälkeen.

Tai kuten usein sanon [ja minua pilkataan tässä vaiheessa]... "Katso blogiani!"

*Feat 1:* Toisin kuin PGC ja Solana, Twisted ElGamal -salatekstimme ovat _aggressively-chunked_, jotta salaus puretaan erittäin nopeasti ja käsitellään saldoja ja ~256 bittiä. Me nimeämme tämän *chunked'n'twisted ElGamaliksi.* Tiedoksi, Aptos tarvitsee vain 128-bittiset saldot ja 64-bittiset summat.

Aptosissa chunking takaa, että purkamisen aikana ratkaistava maksimidiskreetti logariti (DL) -instanssi on pahimmassa tapauksessa 32-bittinen (ja keskimäärin paljon pienempi). => helposti ratkaistavissa 2^16 elliptisen käyrän yhteenlaskulla yksinkertaisilla algoritmeilla kuten baby-step giant-step (BSGS) 👇

*Saavutus 2:* Nopeutamme BSGS:ää valitsemassamme Ristretto255 elliptisen käyrän kohdalla eräpaineilla. Pienennämme myös sen esilaskettua taulukokoa 4-kertaiseksi (=> vähentäen luottamuksellisten dappsien SDK-kokoa ja viivettä) Kutsumme tätä uutta algoritmia *trunkated BSGS-k (TBSGS-k).*

Olen pohtinut tätä algoritmia aiemmin: ... mutta ei korostanut *miksi*: TBSGS-k on deterministinen => helpompi toteuttaa ja testata. TBSGS-k on vain ~2x hitaampi (10,6 ms vs 4,8 ms) kuin monimutkaisempi [BL12]-algoritmi, ja siinä on vain 2x suuremmat taulukot.

*Feat 3:* Kun auditointi on käytössä, pidämme todistettavasti oikeaa salausta jokaisen käyttäjän (käytettävissä) olevasta saldosta tarkastajan salausavaimen (EK) alla. Tämä estää tarkastajia skannaamasta käyttäjien TXN-tiedostoja saldon rekonstruoimiseksi. Tärkeintä: se mahdollistaa tilintarkastajien EK -kierron 👌

*Feat 4:* Aptosissa käyttäjän _signing_-näppäinten kierto on keskeinen turvaominaisuus. Joten: suunnittelimme myös luottamuksellisia assetteja tukemaan käyttäjän *purku*avainten kiertoa! Tällä hetkellä avainten hallintapolitiikat on jätetty sovelluksien/lompakoiden (kuuluisat viimeiset sanat 🤞).

Hyvä uutinen: Avaimettomat luottamukselliset dappit voivat turvallisesti 🌶️ käyttää niitä uudelleenpurkuavaimena! () ==> tällaisissa sovelluksissa ei ole lisäavainten hallintataakkaa ==> helpoin tapa rakentaa luottamuksellinen dapp on avaimeton dapp; Ei lompakkoa [tukea] tarvita!

*Saavutus 5:* Krypton (*grafiikka*) toteuttaminen, joka suojaa oikeita käyttäjien varoja, on pelottavaa. Virheiden minimoimiseksi (🤞), käytämme laajasti aliarvostettua menetelmää Sigma-protokollien turvalliseen suunnitteluun ja laatimiseen: *homomorfismikehys*, jonka löysin @danboneh:n kirjasta 🙏

*Saavutus 6:* Ensimmäinen tuotantovalmis luottamuksellinen resurssin toteutus Movessa. Koodi on tällä hetkellä yksityinen tarkastuksen ajaksi, mutta se julkaistaan pian. Tässä on maistiainen siitä, kuinka yksinkertainen luottamuksellinen siirto voi olla 👇

Lisäksi, koska en voi sille mitään, tässä on osa Sigma-protokollan homomorfismikehystä, joka on toteutettu Movessa 😍

*Saavutus 7:* Täysi kryptografinen spesifikaatio turvallisuustodisteineen. (Ehkä voimme vibekoodata sen @leanprover?) Tulossa pian, mausteisten yksityiskohtien kanssa, eprintissä vieressäsi 👇

Lopuksi, anna tunnustus sinne, missä ansaitaan: Aptosin luottamukselliset omaisuuserät rakentuvat ja laajentavat aiemmissa töissä 👇 esiteltyjä ideoita 1. Zether (): korjasi tilimallin "etuajo"-ongelman odottavien saldojen kautta

2. PGC (): ehdotettu Twisted ElGamal + Bulletproofs -menetelmää yksinkertaisempana vaihtoehtona \Sigma-luodeille. Tämä vähentää merkittävästi toteutuksen monimutkaisuutta: meidän tarvitsee keskittyä vain Sigma-protokollien oikeaan suunnitteluun! Turvallista esseetä käsitellään alla 👇

3. Solana (): mahdollisti 48-bittiset siirtosummat jakamalla odottava saldo "korkeaan" 32-bittiseen lohkoon ja "matalaan" 16-bittiseen lohkoon. Sallimme suuremmat määrät käyttämällä enemmän lohkoja ja lisäksi myös saatavilla olevan saldon.

Viimeisenä mutta ei vähäisimpänä haluan kiittää @mstrakastrak ja @distributedlab:n väkeä, jotka auttoivat luottamuksellisen assetin protokollan alkuperäisen version suunnittelussa ja sen toteuttamisessa Move- ja TypeScript-palveluissa 🖖 Pidä silmällä yhteistä artikkeliamme, joka ilmestyy pian!