Argomenti di tendenza
#
Bonk Eco continues to show strength amid $USELESS rally
#
Pump.fun to raise $1B token sale, traders speculating on airdrop
#
Boop.Fun leading the way with a new launchpad on Solana.
Mentre aspettiamo il verdetto nel processo Storm, è bene ricordare che i pool protetti sono solo matematica e non sono così difficili da capire.
Chiunque può implementarne uno.
Quindi ecco un thread con l'intuizione di base su come funzionano:
L'obiettivo è costruire un sistema in cui tutte le informazioni in ogni transazione rimangano completamente private per gli utenti.
Non dovremmo aspettarci nulla di meno dai nostri sistemi transazionali.
Questo è il fondamentale diritto umano alla privacy.
Il problema è: se tutte le informazioni sono private, come fa la blockchain a sapere che la transazione è valida? Come fa a sapere che l'utente ha effettivamente i fondi che intende inviare? Che non sta spendendo due volte?
La risposta ovvia è: zk-proofs. Ma è davvero così semplice?
Supponiamo che tu abbia un conto con un saldo di 10. Vuoi inviare 5 alla difesa di Roman. Quindi fai una zk-proof che dimostra di avere 10, e la tua transazione invia 5. Sembra abbastanza semplice!
Ma aspetta! Quando hai fornito una prova di avere 10, quella prova si riferiva a uno stato nel passato, prima dell'ultimo blocco in cui la tua transazione è stata inclusa. Forse da allora hai speso tutte le monete! Come puoi dimostrare di avere ancora 10, all'ultimo blocco?
Questo è in realtà piuttosto complicato, ed è il motivo per cui i pool protetti non funzionano realmente con i sistemi basati su account - non c'è un modo semplice e affidabile per dimostrare a una blockchain, in zk, l'ultimo stato in tempo reale.
La soluzione? Usare UTXO. I famosi "Unspent Tx Outputs" di Bitcoin.
Con gli UTXO, non hai un singolo account aggiornabile, hai "note" individuali che possono essere spese solo una volta, per intero (come una vera moneta). I sistemi UTXO sono piuttosto fastidiosi da sviluppare in generale, ma questa proprietà di "spesa una sola volta" li rende molto utili per i pool protetti.
In un sistema UTXO come Bitcoin, quando vai a spendere un UTXO, tutti i nodi completi possono verificare che l'UTXO esista (è stato creato in passato) e che non sia ancora stato speso. Questo è semplice. Ma se tutti i dati nell'UTXO sono crittografati, come possiamo verificarlo?
Non solo i dati sono crittografati, ma non vogliamo nemmeno rivelare *quale* UTXO viene speso. Se lo facessimo, chiunque ti avesse inviato l'UTXO saprebbe quando lo hai speso. In un design ideale di pool protetto, ZERO informazioni vengono trapelate da una transazione.
Il trucco fondamentale delle pool protette è introdurre un valore di "nullificatore" che può essere rivelato pubblicamente ma è unicamente derivato dal spenditore per ogni UTXO. Per spendere l'UTXO, la blockchain verifica che il nullificatore non esista già. Questo garantisce che ogni UTXO possa essere speso solo una volta.
Ora possiamo tornare al nostro zk-proof. Dobbiamo semplicemente dimostrare che l'UTXO che stiamo spendendo esiste effettivamente on-chain e che il nullificatore che abbiamo rivelato per esso è correttamente derivato dall'UTXO che stiamo spendendo.
Questo è tutto!
In pratica, ciò significa che i sistemi di pool protetti tipicamente mantengono due alberi di Merkle distinti. Uno contiene gli hash degli UTXO (gli UTXO sono spesso chiamati "note", e i loro hash come "impegni delle note"), e l'altro contiene i nullificatori. Entrambi gli alberi sono solo in append!.
Quando viene creata una nuova nota, il suo hash viene memorizzato nell'albero di Merkle della nota. La nota stessa è crittografata. Quando un utente successivamente va a spendere quella nota, calcola il nullificatore per la nota e crea una zk-proof che dimostra che la nota è presente nell'albero di Merkle e che il nullificatore è corretto.
Il nullificatore viene rivelato pubblicamente e la catena verifica che non esista già nell'albero dei nullificatori. Viene quindi memorizzato lì, in modo che la nota non possa essere spesa di nuovo. Nessuno può effettivamente dire quale nota venga spesa, poiché la nota originale rimane intatta nell'albero delle note!
Ecco qui, il design di base di tutte le pool protette oggi, inclusi @Zcash, @TornadoCash, @penumbrazone, @namada e altri
Naturalmente, ci sono molte altre cose coinvolte nel design delle pool protette. Rimanete sintonizzati per ulteriori thread in cui approfondiremo quelle meccaniche.
@AThryver @0xkaiserkarel Comune malinteso e uso potenzialmente fuorviante del termine “zk” qui. Vedi

24 lug 2024
TEE? ZKP? MPC? FHE?
Tutto ciò che devi sapere sui più importanti acronimi di tre lettere nel mondo delle criptovalute
Oppure, come fare amicizia e influenzare le persone con il TEE 🧵
33,41K
Principali
Ranking
Preferiti