Nascosto in bella vista: un'implementazione subdola della solidità di un'asta a offerta sigillata

Nota del redattore: questo pezzo fa parte della nostra serie in corso su tutto ciò che riguarda le aste per web3. Parte 1 era una panoramica dei progetti di aste e delle sfide (e opportunità) tecniche specifiche per la progettazione di meccanismi in un contesto di blockchain senza autorizzazione. Parte 2 era un pezzo sulla compensazione del mercato e sull'evitare le guerre del gas. Parte 3 condivide una panoramica dei tipi di aste canoniche, uno sguardo su come la teoria si traduce in pratica e la nostra prima implementazione di una nuova asta Vickrey con offerta sigillata. 

Le aste on-chain sono uno degli spazi di progettazione più interessanti (e onnipresenti) nel web3, dalle vendite NFT alle aste collaterali, dando vita a un nuovo panorama di implementazioni e ricerca. Mentre il design del meccanismo delle aste esiste da secoli e si è evoluto negli ultimi decenni con l'avvento del web e dell'e-commerce, stiamo solo ora applicando questi approcci ai contratti intelligenti.

Stiamo anche iniziando a vedere più progetti di aste nativi delle blockchain, incluso nostro open source Implementazione solida di un'asta Vickrey e diversi sviluppi interessanti da parte della comunità (tra cui suggerimenti per miglioramenti dell'efficienza, nuovo risultati teorici, e due vincitore dell'hackathon implementazioni delle aste a prezzo chiuso). Nel nostro primo progetto, abbiamo fatto un compromesso tra privacy ed efficienza del capitale: abbiamo utilizzato l'overcollateralization (gli offerenti bloccano più garanzie di quanto richiesto dalla loro offerta) per imporre il pagamento all'aggiudicatario, senza rivelare i valori precisi dell'offerta tramite la garanzia Quantità. Bloccando più capitale ottieni più privacy a un costo opportunità potenzialmente maggiore. Ma cosa succederebbe se potessimo offrire privacy senza sovracollateralizzazione? 

Questo post introduce un nuovo design di aste che chiamiamo "SneakyAuction", che combina il CREATE2 codice operativo e prove di stato per garantire la privacy delle offerte senza richiedere agli offerenti di bloccare più garanzie di quelle richieste. Iniziamo analizzando come funziona, quindi confrontandolo con la nostra precedente implementazione (OverCollateralizedAuction) in termini di costo del gas, esperienza utente e privacy. Abbiamo anche aggiunto l'implementazione al nostro Zoo dell'asta repository su GitHub in modo che tu possa creare un fork, costruire su di esso e seguire mentre ci immergiamo in più meccanismi; nel frattempo, di più su come funziona e confronta con il nostro design passato di seguito. 

Come funziona: Impegno alle offerte utilizzando CREATE2

Ci sono due requisiti di cui abbiamo bisogno per creare un'asta a offerta sigillata "eventualmente pubblica" on-chain. In primo luogo, le offerte devono essere private per tutta la durata del periodo di offerta e quindi rivelate al termine; gli schemi commit-reveal (in cui gli utenti pubblicano valori hash-commit e quindi rivelano i loro input in un secondo momento) possono replicare questo meccanismo on-chain. Il secondo requisito è la garanzia: le offerte devono essere garantite per garantire al vincitore fondi sufficienti per adempiere al proprio impegno. 

Nella nostra implementazione Vickrey sovracollateralizzata, i potenziali acquirenti fanno offerte chiamando il commitBid funzione, fornendo un impegno hash e la garanzia da depositare. Questo approccio soddisfa i requisiti, ma presenta alcuni inconvenienti. Anche se l'offerta stessa è nascosta dall'hash, il file commitBid la transazione segnala apertamente e immediatamente l'intenzione dell'utente: "Vorrei fare un'offerta per questa asta, ed ecco la garanzia per la mia offerta". Senza overcollateralization, la visibilità (e la collegabilità) di entrambi intento ed garanzia rivelerebbe i valori dell'offerta. Ma se riusciamo a offuscare l'intento di una transazione, potremmo essere in grado di ottenere la riservatezza delle offerte senza fare affidamento sull'eccessiva garanzia. 

I CREATE2 codice operativo, introdotto in EIP-1014 e incluso nell'hard fork di Costantinopoli, ci offre un modo per fare proprio questo. Il CREATE ed CREATE2 i codici operativi sono entrambi utilizzati per distribuire contratti intelligenti, ma differiscono nel modo in cui vengono calcolati gli indirizzi di distribuzione. Il CREATE l'indirizzo di distribuzione viene calcolato come hash dell'indirizzo del distributore e nonce; il CREATE2 l'indirizzo di distribuzione, d'altra parte, viene calcolato come un hash del bytecode e dei parametri del costruttore del contratto, un sale arbitrario e l'indirizzo del distributore (dettagli).

CREATE2 viene spesso utilizzato nel modello factory per distribuire contratti a indirizzi prevedibili, ad esempio the UniswapV3PoolDeployer usi contrattuali CREATE2 per distribuire ciascun contratto pool a un indirizzo che è una funzione della coppia di token e del livello tariffario. CREATE2 può anche essere utilizzato per (ri) distribuire contratti intelligenti aggiornabili, in particolare nel metamorfico modello contrattuale.

Ancora più importante per noi, il CREATE2 l'indirizzo di distribuzione può funzionare come impegno hash per qualsiasi comportamento definito dal bytecode e dai parametri di input. Se i parametri del costruttore codificano un'offerta, il CREATE2 l'indirizzo può fungere da impegno di offerta.

Inoltre, il contratto stesso può fungere da caveau: un offerente può inviare ETH al CREATE2 indirizzo del caveau prima della distribuzione del contratto per collateralizzare e impegnarsi nella loro offerta in un semplice trasferimento! Poiché l'offerente non dispone della chiave privata per l'indirizzo del caveau, la garanzia è bloccata fino a quando l'offerta non viene rivelata, a quel punto il contratto SneakyAuction si attiva e sblocca il caveau. 

Questo approccio rende la transazione indistinguibile da un trasferimento a un indirizzo di proprietà esterna (EOA). La transazione di offerta è nascosta in bella vista, tra gli altri trasferimenti sulla blockchain. Un avvertimento importante, tuttavia: questa soluzione apparentemente ordinata rende anche difficile la determinazione quando la garanzia era bloccata. È essenziale per la sicurezza dell'asta che il caveau sia stato finanziato prima che vengano rivelate le offerte. Altrimenti, un acquirente opportunista potrebbe attendere fino alla fine del periodo di rivelazione, momento in cui la maggior parte delle offerte è già stata rivelata, per decidere se collateralizzare o meno il proprio caveau. Dobbiamo assicurarci che i caveau siano garantiti durante il periodo di offerta, non durante il periodo di rivelazione, utilizzando un altro strumento: le prove di stato.

Verifica retroattiva della garanzia utilizzando prove di stato

Un modo per garantire che un caveau sia stato garantito durante il periodo di offerta è controllarne il saldo in un blocco passato. È relativamente facile eseguire questa operazione off-chain interrogando un nodo di archivio; ma molto più difficile da realizzare (senza fiducia) on-chain. Gli EVM BALANCE opcode legge il saldo corrente di un indirizzo, ma non esiste tale opcode per recuperare a passato equilibrio. In effetti, l'unico codice operativo EVM che fornisce qualsiasi tipo di accesso allo stato storico è BLOCKHASH, che restituisce l'hash di uno degli ultimi 256 blocchi. Fortunatamente, con un po' di aiuto off-chain, blockhash funziona abbastanza bene per il nostro caso d'uso.

Il blockhash è l'hash dell'intestazione del blocco, che include (tra gli altri metadati) il file radice di stato di quel blocco. La radice dello stato è il nodo radice di a Trie Merkle-Patricia, dove ogni nodo foglia corrisponde a un particolare indirizzo e include l'indirizzo' equilibrio a quel blocco. Non possiamo accedere direttamente a questi nodi foglia sulla catena, ma possiamo verificare che i contenuti di un nodo foglia siano corretti. Infatti il eth_getProof Metodo RPC supportato da Alchimia (tra gli altri fornitori) restituisce le prove Merkle necessarie per eseguire questa verifica (Leo Zhang fornisce un spiegazione approfondita di come funziona nel contesto dei client Ethereum light). Ciò significa che con un po' di aiuto off-chain (una singola chiamata RPC), gli offerenti possono dimostrare al contratto SneakyAuction che il loro caveau è stato garantito durante il periodo di offerta. 

Nella nostra implementazione, il prima offerta rivelato per un'asta memorizza il blockhash del blocco precedente. Questa transazione fa passare efficacemente l'asta dalla fase di offerta alla fase di rivelazione: tutto successive offerte rivelato devono fornire una prova Merkle che il loro caveau fosse sufficientemente garantito prima di quel blocco (cioè prima che la prima offerta fosse rivelata). Si noti che il prima di tutto revealBid la transazione sarebbe idealmente inviata tramite un pool di transazioni privato (ad es. Flashbot); in caso contrario, un offerente che guarda il mempool (vedendo il valore dell'offerta rivelata) potrebbe anticipare la transazione e fare un'offerta dell'ultimo secondo. 

LibBalanceProof

Per ridurre al minimo i costi per gli offerenti, abbiamo scritto un gas ottimizzato biblioteca per verificare le prove di equilibrio sulla catena su cui si basa contratti scritto dal team Aragon (che ha aperto la strada alle prove di archiviazione su catena nel 2018) e dai contratti di Hamdi Allam per on-chain Decodifica RLP. La nostra libreria utilizza una serie di trucchi e ottimizzazioni di basso livello che si basano sulla particolare struttura del trie di stato, quindi non può essere utilizzata per dimostrazioni di trie Merkle-Patricia generiche. In cambio, consente al contratto SneakyAuction di verificare il saldo passato di un caveau in meno di 30,000 gas.

Abbiamo anche scritto un leggero Wrapper JavaScript per l' eth_getProof Metodo RPC. Dato un indirizzo e un numero di blocco, restituisce la prova del saldo e l'intestazione del blocco serializzata RLP, che può essere utilizzata per rivelare un'offerta. 

Come si confronta 

Confrontiamo il nostro nuovo approccio SneakyAuction con il design OverCollateralizedAuction che abbiamo rilasciato l'ultima volta, lungo diverse dimensioni chiave che interessano i progettisti tecnici o gli utenti: costi del gas, esperienza utente e privacy. 

Costi del gas

SneakyAuction revealBid, endAuctione withdrawCollateral le funzioni richiedono la distribuzione a SneakyVault, quindi sono più costosi delle loro controparti OverCollateralizedAuction. revealBid è particolarmente costoso perché verifica anche una prova di equilibrio, che costa circa 25,000 gas.

Costi approssimativi del gas di diverse operazioni, basati sui test unitari di Foundry

Esperienza utente

Sebbene le due implementazioni seguano un flusso complessivo simile (fase di offerta, fase di rivelazione, fine dell'asta), esistono alcune differenze nell'esperienza dell'utente. SneakyAuction presenta alcuni svantaggi minori:

• L'esperienza di invio di ETH a un deposito non distribuito, sebbene possa essere sottratta dal front-end, è potenzialmente fonte di confusione per gli utenti che esaminano la loro transazione di offerta su un block explorer.
• Con OverCollateralizedAuction, è possibile terminare l'asta in anticipo se tutte le offerte sono state rivelate. Questo non è possibile in SneakyAuction perché il contratto non ha modo di sapere quante offerte sono state impegnate.
• Gli offerenti possono aggiornare la loro offerta e ricaricare la loro garanzia con OverCollateralizedAuction chiamando commitBid ancora. In SneakyAuction, gli offerenti non possono effettuare aggiornamenti una volta che il caveau dell'offerta è stato garantito.

Privacy

La privacy dell'offerta di OverCollateralizedAuction si basa sugli offerenti che scelgono di bloccare garanzie extra (quindi gli spettatori conoscono un limite superiore di un'offerta ma non l'importo esatto). SneakyAuction, invece, deriva la privacy da attività on-chain completamente estranee all'asta stessa: trasferimenti di ETH che avvengono durante il periodo di offerta dell'asta. 

Per semplicità, supponiamo che ogni offerta sia collateralizzata utilizzando un singolo trasferimento di ETH. Osserviamo che: 

1. La transazione di collateralizzazione dovrebbe essere la prima volta che qualcuno ha interagito con l'indirizzo del vault on-chain. 
2. Non prevediamo che altre transazioni tocchino l'indirizzo del caveau per il resto del periodo di offerta. 
3. Nessuna transazione può provenire dall'indirizzo del vault (perché nessuno ha la chiave privata). 

I trasferimenti di ETH durante il periodo di offerta a indirizzi altrimenti "non toccati" sono plausibilmente offerte, in altre parole, sono il "rumore" che nasconde le transazioni di offerta. Per aiutare a quantificare la privacy di SneakyAuction, possiamo osservare la forma di questa distribuzione del rumore.

Questo istogramma mostra la distribuzione da inizio anno dei trasferimenti giornalieri di ETH (sulla mainnet di Ethereum) agli indirizzi non toccati, illustrando la distribuzione del rumore per un periodo di offerta di 24 ore. Possiamo vedere che la maggior parte delle transazioni rientra nell'intervallo [0.001, 1] ETH, il che implica che le aste con un valore di offerta previsto in tale intervallo avrebbero la massima privacy. D'altra parte, il rumore tipico potrebbe non fornire una privacy sufficiente per le aste in cui l'offerta prevista è superiore a 10 ETH: raramente ci sono più di 100 trasferimenti in tale intervallo, quindi un'asta che attrae molte offerte creerebbe un cospicuo picco nella distribuzione . 

Per un'altra prospettiva su questi dati, questi grafici a dispersione rappresentano i trasferimenti del 15 ottobre 2022, sovrapposti alle offerte di due ipotetiche aste: 

Intuitivamente, sarebbe molto più facile per un osservatore identificare le offerte della seconda asta. In pratica, potresti usare un algoritmo di clustering come il aspettativa-massimizzazione (EM) algoritmo per prevedere quali transazioni sono offerte. 

Tuttavia, ci sono alcuni altri fattori che possono rendere SneakyAuction più privato (e quindi più convincente) nella pratica:

1. Periodi di offerta più lunghi: la privacy si adatta alla durata del periodo di offerta: più lungo è il periodo di offerta, più trasferimenti ci sono per nascondere le offerte. 
2. Aste simultanee: la privacy scala con il numero di aste simultanee –– se due aste sono in fase di offerta contemporaneamente, le offerte di un'asta fungono da rumore per l'altra.

SneakyAuction può anche trarre vantaggio dall'overcollateralization: poiché SneakyVault restituisce all'offerente qualsiasi ETH in eccesso, gli offerenti possono scegliere di overcollateralize per maggiore privacy. Quindi, in un certo senso, SneakyAuction fornisce una privacy molto più forte rispetto alla nostra precedente implementazione.

Un semplice corollario del meccanismo di privacy di SneakyAuction è che nasconde il numero delle offerte durante il periodo di offerta. Questo è un vantaggio rispetto a OverCollateralizedAuction, che nasconde solo i valori dell'offerta: il numero di impegni di offerta che sono stati presi per una determinata asta è completamente pubblico (e può rivelare quanto sia competitiva l'asta).

***

Mentre la nostra prima implementazione di un'asta a offerta sigillata ha tradotto le caratteristiche del mondo reale in decisioni di progettazione sulla catena, il nostro secondo progetto si basa su un meccanismo nuovo e pratico per utilizzare la natura pubblica delle blockchain a proprio vantaggio: le offerte sigillate "si nascondono" tra non correlate attività blockchain.

Sebbene questo nuovo approccio sia un modo conveniente per ottenere la riservatezza delle offerte senza sovracollateralizzazione, non è necessariamente adatto a tutte le aste (ad esempio aste con molte offerte di alto valore). La privacy migliora per le aste che prevedono offerte più piccole (e soprattutto per un periodo di tempo più lungo).

***
Le opinioni qui espresse sono quelle del personale di AH Capital Management, LLC ("a16z") citato e non sono le opinioni di a16z o delle sue affiliate. Alcune informazioni qui contenute sono state ottenute da fonti di terze parti, incluse società in portafoglio di fondi gestiti da a16z. Sebbene tratti da fonti ritenute affidabili, a16z non ha verificato in modo indipendente tali informazioni e non fornisce dichiarazioni sull'accuratezza attuale o duratura delle informazioni o sulla sua adeguatezza per una determinata situazione. Inoltre, questo contenuto può includere pubblicità di terze parti; a16z non ha esaminato tali annunci pubblicitari e non approva alcun contenuto pubblicitario in essi contenuto.

Questo contenuto viene fornito solo a scopo informativo e non deve essere considerato come consulenza legale, commerciale, di investimento o fiscale. Dovresti consultare i tuoi consulenti in merito a tali questioni. I riferimenti a qualsiasi titolo o risorsa digitale sono solo a scopo illustrativo e non costituiscono una raccomandazione di investimento o un'offerta per fornire servizi di consulenza in materia di investimenti. Inoltre, questo contenuto non è diretto né destinato all'uso da parte di investitori o potenziali investitori e non può in alcun caso essere invocato quando si decide di investire in qualsiasi fondo gestito da a16z. (Un'offerta per investire in un fondo a16z sarà fatta solo dal memorandum di collocamento privato, dal contratto di sottoscrizione e da altra documentazione pertinente di tale fondo e dovrebbe essere letta nella sua interezza.) Eventuali investimenti o società in portafoglio menzionati, citati o descritti non sono rappresentativi di tutti gli investimenti in veicoli gestiti da a16z, e non si può garantire che gli investimenti saranno redditizi o che altri investimenti effettuati in futuro avranno caratteristiche o risultati simili. Un elenco degli investimenti effettuati da fondi gestiti da Andreessen Horowitz (esclusi gli investimenti per i quali l'emittente non ha autorizzato a16z a divulgare pubblicamente e gli investimenti non annunciati in asset digitali quotati in borsa) è disponibile all'indirizzo https://a16z.com/investments /.

Grafici e grafici forniti all'interno sono esclusivamente a scopo informativo e non dovrebbero essere presi in considerazione quando si prende una decisione di investimento. I rendimenti passati non sono indicativi di risultati futuri. Il contenuto parla solo a partire dalla data indicata. Eventuali proiezioni, stime, previsioni, obiettivi, prospettive e/o opinioni espresse in questi materiali sono soggette a modifiche senza preavviso e possono differire o essere contrarie alle opinioni espresse da altri. Si prega di consultare https://a16z.com/disclosures per ulteriori informazioni importanti