Ascuns la vedere: O implementare de soliditate furtunoasă a unei licitații cu licitație sigilată

Nota editorului: această piesă face parte din seria noastră în curs de desfășurare despre toate lucrurile legate de licitațiile pentru web3. Partea 1 a fost o privire de ansamblu asupra proiectelor de licitație și a provocărilor tehnice (și oportunităților) specifice proiectării mecanismelor într-un context blockchains fără permisiune. Partea 2 a fost o piesă despre compensarea pieței și evitarea războaielor cu gaze. Partea 3 împărtășește o privire de ansamblu asupra tipurilor de licitații canonice, o privire asupra modului în care teoria se traduce în practică și prima noastră implementare a unei noi licitații Vickrey cu licitație sigilată. 

Licitațiile în lanț sunt unul dintre cele mai interesante (și omniprezente) spații de design din web3 — de la vânzări NFT la licitații colaterale — dând naștere unui nou peisaj de implementări și cercetări. În timp ce proiectarea mecanismelor de licitație există de secole și a evoluat în ultimele decenii odată cu apariția web și a comerțului electronic, abia acum aplicăm aceste abordări contractelor inteligente.

De asemenea, începem să vedem mai multe modele de licitație care sunt native pentru blockchain-uri, inclusiv al nostru open-source Implementarea solidă a unei licitații Vickrey și câteva evoluții interesante din partea comunității (inclusiv sugestii pentru îmbunătățirea eficienței, nou rezultate teoretice, si doi câștigătoare de hackathon implementările a licitaţiilor cu licitaţie sigilată). În primul nostru design, am făcut un compromis între confidențialitate și eficiența capitalului: am folosit supracolateralizarea (ofertanții blochează mai multe garanții decât este cerut de oferta lor) pentru a impune plata de la ofertantul câștigător, fără a dezvălui valorile precise ale ofertei prin garanție. Cantitate. Prin blocarea mai mult capital, obțineți mai multă confidențialitate la un cost de oportunitate potențial mai mare. Dar dacă am putea licita confidențialitate fără supracolateralizare? 

Această postare prezintă un nou design de licitație pe care îl numim „SneakyAuction”, care combină CREATE2 opcode și dovezi de stat pentru a garanta confidențialitatea ofertelor, fără a solicita ofertanților să blocheze mai multe garanții decât este necesar. Începem prin a detalia modul în care funcționează și apoi o comparăm cu implementarea noastră anterioară (OverCollateralizedAuction) în ceea ce privește costul gazului, experiența utilizatorului și confidențialitatea. Am adăugat, de asemenea, implementarea în programul nostru Gradina zoologica de licitatie depozit de pe GitHub, astfel încât să îl puteți bifurca, să construiți pe el și să urmăriți pe măsură ce ne scufundăm în mai multe mecanici; Între timp, mai multe despre cum funcționează și se compară cu designul nostru anterior de mai jos. 

Cum funcționează: Angajamentul la sume licitate folosind CREATE2

Există două cerințe de care avem nevoie pentru a crea o licitație „eventual publică” în lanț. În primul rând, ofertele trebuie să fie private pe durata perioadei de licitație și apoi să fie dezvăluite când se încheie; Schemele de commit-reveal (în cazul în care utilizatorii publică valori hash-committed și apoi își dezvăluie intrările mai târziu) pot replica acest mecanism în lanț. A doua cerință este garantarea: ofertele trebuie să fie susținute de garanții pentru a se asigura că câștigătorul are suficiente fonduri pentru a-și îndeplini angajamentul. 

În implementarea noastră Vickrey supracolateralizată, potențialii cumpărători plasează oferte apelând la commitBid funcția, furnizând un angajament hash și garanția care urmează să fie escrowed. Această abordare satisface cerințele, dar are unele dezavantaje. Chiar dacă oferta în sine este ascunsă de hash, the commitBid tranzacția semnalează în mod deschis și imediat intenția utilizatorului: „Aș dori să licit la această licitație și iată garanția pentru oferta mea.” Fără supracolateralizare, vizibilitatea (și legabilitatea) ambelor scop și colateral ar dezvălui valorile licitate. Dar dacă putem obstrucționa intenția unei tranzacții, s-ar putea să putem obține confidențialitatea ofertelor fără a ne baza pe supracolateralizare. 

CREATE2 opcode, introdus în PEI-1014 și inclus în hard fork Constantinopol, ne oferă o modalitate de a face exact asta. The CREATE și CREATE2 codurile operaționale sunt ambele folosite pentru a implementa contracte inteligente, dar diferă în modul în care sunt calculate adresele de implementare. The CREATE adresa de implementare este calculată ca un hash al adresei deployerului și nonce; cel CREATE2 adresa de implementare, pe de altă parte, este calculată ca un hash al codului octet al contractului și al parametrilor constructorului, o sare arbitrară și adresa deployerului (detalii).

CREATE2 este adesea folosit în modelul din fabrică pentru a implementa contracte la adrese previzibile - de exemplu, the UniswapV3PoolDeployer utilizări contractuale CREATE2 pentru a implementa fiecare contract de grup la o adresă care este o funcție a perechii de jetoane și a nivelului de taxă. CREATE2 poate fi folosit și pentru a (re)implementa contracte inteligente actualizabile, în special în metamorfic model contractual.

Mai important pentru noi, cel CREATE2 adresa de implementare poate funcționa ca un angajament hash față de orice comportament definit de bytecode de intrare și de parametri. Dacă parametrii constructorului codifică o ofertă, CREATE2 adresa poate servi drept angajament de ofertă.

În plus, contractul în sine poate servi ca un seif - un ofertant poate trimite ETH la CREATE2 adresa seifului înainte de implementarea contractului să garanteze și să se angajeze la oferta lor într-un simplu transfer! Deoarece ofertantul nu are cheia privată pentru adresa seifului, garanția este blocată până când oferta este dezvăluită, moment în care contractul SneakyAuction se desfășoară și deblochează seiful. 

Această abordare face ca tranzacția să nu se distingă de un transfer la o adresă deținută extern (EOA). Tranzacția licitată este ascunsă la vedere, printre alte transferuri pe blockchain. Un avertisment important, totuși: această soluție aparent ordonată face, de asemenea, dificil de determinat cand garanția a fost blocată. Este esențial pentru securitatea licitațiilor ca seiful să fi fost finanțat înainte ca orice oferte să fie dezvăluite. În caz contrar, un cumpărător oportunist ar putea aștepta până la sfârșitul perioadei de dezvăluire, moment în care majoritatea ofertelor au fost deja dezvăluite, pentru a decide dacă își garantează sau nu seiful. Trebuie să ne asigurăm că seifurile sunt garantate în perioada de licitație, nu în perioada de revelare, folosind un alt instrument: dovezile de stat.

Verificarea retroactivă a garanțiilor utilizând dovezi de stat

O modalitate de a vă asigura că un seif a fost garantat în timpul perioadei de licitație este prin verificarea soldului acestuia la un bloc trecut. Este relativ ușor să faci acest lucru în afara lanțului interogând un nod de arhivă; dar mult mai greu de realizat (fără încredere) în lanț. EVM-urile BALANCE opcode citește soldul curent al unei adrese, dar nu există un astfel de cod operațional pentru a prelua a trecut echilibru. De fapt, singurul cod operațional EVM care oferă orice fel de acces la starea istorică este BLOCKHASH, care returnează hash-ul unuia dintre ultimele 256 de blocuri. Din fericire, cu ajutor în afara lanțului, blockhash funcționează suficient de bine pentru cazul nostru de utilizare.

Blockhash-ul este hash-ul antetului blocului, care include (printre alte metadate) fișierul rădăcină de stat din acel bloc. Rădăcina de stare este nodul rădăcină al lui a Merkle-Patricia trie, unde fiecare nod frunză corespunde unei anumite adrese și include adresa" echilibra la acel bloc. Nu putem accesa direct aceste noduri frunză în lanț, dar putem verifica dacă conținutul unui nod frunză este corect. De fapt, cel eth_getProof Metoda RPC susținută de Alchimie (printre alți furnizori) returnează dovezile Merkle necesare pentru a efectua această verificare (Leo Zhang oferă un explicație aprofundată a modului în care funcționează acest lucru în contextul clienților light Ethereum). Aceasta înseamnă că, cu puțin ajutor în afara lanțului (un singur apel RPC), ofertanții pot demonstra contractului SneakyAuction că seiful lor a fost garantat în timpul perioadei de licitație. 

În implementarea noastră, prima ofertă dezvăluit pentru o licitație stochează blockhash-ul blocului anterior. Această tranzacție face efectiv tranziția licitației de la faza de licitare la faza de dezvăluire - toate ofertele ulterioare revelate trebuie să furnizeze o dovadă Merkle că seiful lor a fost suficient garantat înainte de acel bloc (adică înainte ca prima ofertă să fie dezvăluită). Rețineți că primul revealBid În mod ideal, tranzacția ar fi transmisă printr-un grup privat de tranzacții (de exemplu, Flashbots); în caz contrar, un ofertant care urmărește mempool-ul (văzând valoarea ofertei dezvăluite) ar putea conduce tranzacția și să plaseze o ofertă de ultima secundă. 

LibBalanceProof

Pentru a minimiza costurile pentru ofertanți, am scris o versiune optimizată pentru gaz bibliotecă pentru a verifica dovezile de echilibru pe lanț care se bazează pe contracte scrise de echipa Aragon (care a fost pionier în stocarea în lanț în 2018) și contractele lui Hamdi Allam pentru stocarea în lanț Decodare RLP. Biblioteca noastră folosește o serie de trucuri și optimizări de nivel scăzut care se bazează pe structura particulară a încercării de stat, deci nu poate fi utilizată pentru dovezile generale Merkle-Patricia. În schimb, permite contractului SneakyAuction să verifice soldul trecut al unui seif în mai puțin de 30,000 de gaze.

Am scris și o greutate ușoară Înveliș JavaScript pentru eth_getProof metoda RPC. Având în vedere o adresă și un număr de bloc, returnează dovada soldului și antetul blocului serializat RLP, care poate fi folosit pentru a dezvălui o ofertă. 

Cum se compară 

Să comparăm noua noastră abordare SneakyAuction cu designul OverCollateralizedAuction pe care l-am lansat ultima dată, de-a lungul mai multor dimensiuni cheie la care țin designerii tehnici sau utilizatorii: costurile cu gazul, experiența utilizatorului și confidențialitatea. 

Costurile cu gazele

SneakyAuction's revealBid, endAuction, și withdrawCollateral funcțiile necesită implementarea a SneakyVault, deci sunt mai scumpe decât omologii lor OverCollateralizedAuction. revealBid este deosebit de costisitor pentru că verifică și o dovadă a echilibrului, care costă aproximativ 25,000 de gaze.

Costurile aproximative ale gazului pentru diferite operațiuni, pe baza testelor unitare de turnătorie

Experiența utilizatorului

Deși cele două implementări urmează un flux general similar (faza de licitare, faza de dezvăluire, licitația se încheie), există unele diferențe în experiența utilizatorului. SneakyAuction are câteva dezavantaje minore:

• Experiența de a trimite ETH la un seif neimplementat, deși ar putea fi abstrasă de front-end, este potențial confuză pentru utilizatorii care își examinează tranzacția licitată pe un explorator de blocuri.
• Cu OverCollateralizedAuction, este posibil să încheiați licitația mai devreme dacă toate ofertele au fost dezvăluite. Acest lucru nu este posibil în SneakyAuction deoarece contractul nu are de unde să știe câte oferte au fost angajate.
• Ofertanții își pot actualiza oferta și își pot completa garanția prin OverCollateralizedAuction sunând commitBid din nou. În SneakyAuction, ofertanții nu pot face actualizări odată ce seiful licitației a fost garantat.

Privacy

Confidențialitatea ofertei OverCollateralizedAuction se bazează pe ofertanții care aleg să blocheze garanții suplimentare (astfel încât privitorii să cunoască limita superioară a unei oferte, dar nu suma exactă). SneakyAuction, pe de altă parte, obține confidențialitate din activitatea în lanț care nu are nicio legătură cu licitația în sine: transferuri ETH care au loc în perioada de licitație a licitației. 

Pentru simplitate, să presupunem că fiecare ofertă este garantată folosind un singur transfer ETH. Observăm că: 

1. Tranzacția de garantare ar trebui să fie prima dată când cineva interacționează cu adresa seifului în lanț. 
2. Nu ne așteptăm ca alte tranzacții să atingă adresa seifului pentru restul perioadei de licitare. 
3. Nicio tranzacție nu poate proveni de la adresa seifului (pentru că nimeni nu are cheia privată). 

Transferurile ETH în timpul perioadei de licitație către adrese altfel „neatinse” sunt oferte plauzibile – cu alte cuvinte, sunt „zgomotul” care ascunde tranzacțiile de licitație. Pentru a ajuta la cuantificarea confidențialității SneakyAuction, ne putem uita la forma acestei distribuții de zgomot.

Această histogramă arată distribuția anuală a transferurilor zilnice de ETH (pe rețeaua principală Ethereum) către adrese neatinse, ilustrând distribuția zgomotului pentru o perioadă de licitație de 24 de ore. Putem vedea că majoritatea tranzacțiilor se încadrează în intervalul [0.001, 1] ETH, ceea ce implică faptul că licitațiile cu o valoare licitată așteptată în intervalul respectiv ar avea cea mai puternică confidențialitate. Pe de altă parte, zgomotul obișnuit poate să nu ofere suficientă confidențialitate pentru licitațiile în care oferta așteptată este mai mare de 10 ETH - rareori există mai mult de 100 de transferuri în acest interval, așa că o licitație care atrage multe oferte ar crea o creștere vizibilă în distribuție. . 

Pentru o altă perspectivă asupra acestor date, aceste diagrame de dispersie descriu transferurile din 15 octombrie 2022, suprapuse cu oferte de la două licitații ipotetice: 

Intuitiv, ar fi mult mai ușor pentru un observator să identifice ofertele de la a doua licitație. În practică, puteți utiliza un algoritm de grupare, cum ar fi așteptare-maximizare (EM) algoritm pentru a prezice tranzacțiile care sunt oferte. 

Cu toate acestea, există alți câțiva factori care pot face SneakyAuction mai privat (și, prin urmare, mai convingător) în practică:

1. Perioade de licitare mai lungi: confidențialitatea crește odată cu durata perioadei de licitare – cu cât perioada de licitare este mai lungă, cu atât sunt mai multe transferuri pentru a ascunde ofertele. 
2. Licitații simultane: confidențialitatea se mărește în funcție de numărul de licitații simultane –– dacă două licitații sunt în faza de licitare în același timp, ofertele unei licitații servesc drept zgomot pentru cealaltă.

SneakyAuction poate beneficia, de asemenea, de supracolateralizare - deoarece SneakyVault returnează ofertantului orice exces de ETH, ofertanții pot opta să supracolateralizeze pentru mai multă confidențialitate. Deci, într-un fel, SneakyAuction oferă confidențialitate strict mai puternică decât implementarea noastră anterioară.

Un simplu corolar al mecanismului de confidențialitate al SneakyAuction este că ascunde număr de oferte în perioada de licitație. Acesta este un avantaj față de OverCollateralizedAuction, care ascunde doar valorile licitației — numărul de angajamente de licitație care au fost făcute pentru o anumită licitație este complet public (și poate dezvălui cât de competitivă este licitația).

***

În timp ce prima noastră implementare a unei licitații cu licitație sigilată a tradus caracteristicile din lumea reală în decizii de proiectare în lanț, al doilea proiect se bazează pe un mecanism nou și practic pentru a folosi natura publică a blockchain-urilor în avantajul său: ofertele sigilate „se ascund” printre care nu au legătură. activitate blockchain.

Deși această nouă abordare este o modalitate convenabilă de a obține confidențialitatea licitațiilor fără supracolateralizare, nu este neapărat potrivită pentru toate licitațiile (de exemplu, licitațiile cu multe oferte de valoare ridicată). Confidențialitatea se îmbunătățește pentru licitațiile care așteaptă oferte mai mici (și mai ales pe o perioadă mai lungă de timp).

***
Părerile exprimate aici sunt cele ale personalului individual AH Capital Management, LLC („a16z”) citat și nu sunt punctele de vedere ale a16z sau ale afiliaților săi. Anumite informații conținute aici au fost obținute din surse terțe, inclusiv de la companii de portofoliu de fonduri administrate de a16z. Deși este luat din surse considerate a fi de încredere, a16z nu a verificat în mod independent astfel de informații și nu face nicio declarație cu privire la acuratețea actuală sau de durată a informațiilor sau adecvarea acestora pentru o situație dată. În plus, acest conținut poate include reclame de la terți; a16z nu a revizuit astfel de reclame și nu aprobă niciun conținut publicitar conținut în acestea.

Acest conținut este furnizat doar în scop informativ și nu ar trebui să fie bazat pe consiliere juridică, de afaceri, de investiții sau fiscală. Ar trebui să vă consultați propriii consilieri cu privire la aceste aspecte. Referințele la orice titluri de valoare sau active digitale au doar scop ilustrativ și nu constituie o recomandare de investiții sau o ofertă de a oferi servicii de consiliere în materie de investiții. În plus, acest conținut nu este îndreptat și nici nu este destinat utilizării de către niciun investitor sau potențial investitor și nu poate fi bazat în nicio circumstanță atunci când se ia o decizie de a investi într-un fond administrat de a16z. (Ofertă de a investi într-un fond a16z va fi făcută numai prin memoriul de plasament privat, acordul de subscriere și alte documente relevante ale oricărui astfel de fond și trebuie citită în întregime.) Orice investiții sau companii de portofoliu menționate, la care se face referire sau descrise nu sunt reprezentative pentru toate investițiile în vehicule administrate de a16z și nu poate exista nicio asigurare că investițiile vor fi profitabile sau că alte investiții realizate în viitor vor avea caracteristici sau rezultate similare. O listă a investițiilor realizate de fondurile gestionate de Andreessen Horowitz (excluzând investițiile pentru care emitentul nu a oferit permisiunea ca a16z să dezvăluie public, precum și investițiile neanunțate în active digitale tranzacționate public) este disponibilă la https://a16z.com/investments /.

Diagramele și graficele furnizate în interior au doar scop informativ și nu trebuie să se bazeze pe acestea atunci când se ia vreo decizie de investiție. Performanța trecută nu indică rezultatele viitoare. Conținutul vorbește doar de la data indicată. Orice previziuni, estimări, previziuni, obiective, perspective și/sau opinii exprimate în aceste materiale pot fi modificate fără notificare și pot diferi sau pot fi contrare opiniilor exprimate de alții. Vă rugăm să consultați https://a16z.com/disclosures pentru informații suplimentare importante