Hidden in Plain Sight: En snikende soliditetsimplementering av en auksjon med forseglet bud

Redaktørens merknad: Dette stykket er en del av vår pågående serie om alle ting auksjoner for web3. Del 1 var en oversikt over auksjonsdesign, og tekniske utfordringer (og muligheter) spesifikke for mekanismedesign i en tillatelsesfri blokkjedekontekst. Del 2 var et stykke om å rydde markedet og unngå gasskriger. Del 3 deler en oversikt over kanoniske auksjonstyper, en titt på hvordan teori omsettes i praksis, og vår første implementering av en ny, forseglet Vickrey-auksjon. 

Auksjoner i kjeden er et av de mest interessante (og allestedsnærværende) designområdene i web3 – fra NFT-salg til sideauktioner – som gir opphav til et nytt landskap av implementeringer og forskning. Mens design av auksjonsmekanismer har eksistert i århundrer, og har utviklet seg de siste tiårene med fremveksten av nettet og e-handel, bruker vi først nå disse tilnærmingene til smarte kontrakter.

Vi begynner også å se flere auksjonsdesign som er hjemmehørende i blokkjeder, inkludert vår åpen kildekode Soliditetsimplementering av en Vickrey-auksjon, og flere interessante utviklinger fra samfunnet (inkludert forslag for effektivitetsforbedringer, nytt teoretiske resultater, og to hackathon-vinnende implementeringer av auksjoner med lukkede bud). I vårt første design gjorde vi en avveining mellom personvern og kapitaleffektivitet: Vi brukte oversikkerhet (budgivere låser opp mer sikkerhet enn det som kreves av budet deres) for å tvinge inn betaling fra den vinnende budgiveren, uten å avsløre de nøyaktige budverdiene via sikkerheten beløp. Ved å låse opp mer kapital får du mer privatliv til en potensielt større alternativkostnad. Men hva om vi kunne ha tilbudt personvern uten oversikkerhet? 

Dette innlegget introduserer et nytt auksjonsdesign som vi kaller "SneakyAuction", som kombinerer CREATE2 opcode og statlige bevis for å garantere budets personvern uten å kreve at budgivere låser opp mer sikkerhet enn nødvendig. Vi begynner med å bryte ned hvordan det fungerer, og deretter sammenligne det med vår tidligere implementering (OverCollateralizedAuction) når det gjelder gasskostnader, brukeropplevelse og personvern. Vi har også lagt til implementeringen til vår Auksjon Zoo repository på GitHub slik at du kan dele det, bygge på det og følge med mens vi dykker inn i mer mekanikk; i mellomtiden, mer om hvordan det fungerer og sammenlignet med vårt tidligere design nedenfor. 

Hvordan det fungerer: Forplikter seg til bud ved å bruke CREATE2

Det er to krav vi trenger for å opprette en «eventuelt-offentlig» auksjon med forseglet bud på kjeden. Først må bud være private i løpet av budperioden, og deretter avsløres når den avsluttes. commit-reveal-ordninger (der brukere publiserer hash-forpliktede verdier, og deretter avslører inputene deres senere) kan replikere denne mekanismen i kjeden. Det andre kravet er sikkerhet: bud må støttes av sikkerhet for å sikre at vinneren har nok midler til å oppfylle forpliktelsene sine. 

I vår oversikkerhetssikrede Vickrey-implementering legger potensielle kjøpere inn bud ved å ringe commitBid funksjon, leverer en hash-forpliktelse og sikkerheten som skal deponeres. Denne tilnærmingen tilfredsstiller kravene, men har noen ulemper. Selv om selve budet er skjult av hashen, er det commitBid transaksjonen signaliserer åpent og umiddelbart brukerens intensjon: "Jeg vil gjerne by på denne auksjonen, og her er sikkerheten for budet mitt." Uten oversikkerhet, synligheten (og koblingsevnen) til begge hensikt og sikkerhet vil avsløre budverdier. Men hvis vi kan tilsløre intensjonen med en transaksjon, kan vi kanskje oppnå budpersonvern uten å stole på oversikkerhet. 

De CREATE2 opcode, introdusert i EIP-1014 og inkludert i Konstantinopel-hardgaffelen, gir oss en måte å gjøre nettopp det på. De CREATE og CREATE2 opcodes brukes begge til å distribuere smarte kontrakter, men de er forskjellige i hvordan distribusjonsadressene beregnes. De CREATE distribusjonsadressen beregnes som en hash av distribusjonsadressen og nonce; de CREATE2 distribusjonsadresse, på den annen side, beregnes som en hash av kontraktens bytekode og konstruktørparametere, et vilkårlig salt og distribusjonsadressen (detaljer).

CREATE2 brukes ofte i fabrikkmønsteret for å distribuere kontrakter til forutsigbare adresser - for eksempel UniswapV3PoolDeployer kontraktsbruk CREATE2 å distribuere hver poolkontrakt til en adresse som er en funksjon av token-paret og gebyrnivået. CREATE2 kan også brukes til å (re)distribuere oppgraderbare smarte kontrakter, spesielt i metamorfe kontraktsmønster.

Enda viktigere for oss er CREATE2 distribusjonsadresse kan fungere som en hash-forpliktelse til enhver oppførsel definert av inngangsbytekoden og parametere. Hvis konstruktørparameterne koder for et bud, vil CREATE2 adresse kan tjene som en budforpliktelse.

Dessuten kan selve kontrakten tjene som et hvelv - en budgiver kan sende ETH til CREATE2 hvelvadresse før kontrakten utplasseres å stille sikkerhet og forplikte seg til deres bud i en enkel overføring! Siden budgiveren ikke har den private nøkkelen til hvelvadressen, låses sikkerheten inntil budet blir avslørt, på hvilket tidspunkt SneakyAuction-kontrakten distribuerer og låser opp hvelvet. 

Denne tilnærmingen gjør at transaksjonen ikke kan skilles fra en overføring til en eksternt eid adresse (EOA). Budtransaksjonen er skjult i vanlig syn, blant andre overføringer på blokkjeden. En viktig advarsel: denne tilsynelatende ryddige løsningen gjør det også vanskelig å fastslå når sikkerheten var låst. Det er viktig for auksjonssikkerheten at hvelvet ble finansiert før noen bud avsløres. Ellers kan en opportunistisk kjøper vente helt til slutten av avsløringsperioden, da de fleste budene allerede er avslørt, med å bestemme seg for om de skal stille sikkerhet for hvelvet deres. Vi må sørge for at hvelv er sikret i løpet av budperioden, ikke under avsløringsperioden, ved å bruke et annet verktøy: statlige bevis.

Retroaktiv verifisering av sikkerhet ved hjelp av statlige bevis

En måte å sikre at et hvelv ble bevilget i løpet av budperioden er ved å sjekke saldoen ved en tidligere blokk. Det er relativt enkelt å gjøre dette utenfor kjeden ved å spørre en arkivnode; men mye vanskeligere å oppnå (uten tillit) på kjeden. EVM-ene BALANCE opcode leser gjeldende saldo til en adresse, men det finnes ingen slik opcode for å hente en Past balansere. Faktisk er den eneste EVM-opkoden som gir noen form for historisk statstilgang BLOCKHASH, som returnerer hashen til en av de siste 256 blokkene. Heldigvis – med litt hjelp utenfor kjeden – fungerer blockhash akkurat godt nok for vår brukssituasjon.

Blockhash er hashen til blokkhodet, som inkluderer (blant andre metadata) den statlig rot av den blokken. Tilstandsroten er rotnoden til en Merkle-Patricia prøver, der hver bladnode tilsvarer en bestemt adresse og inkluderer adressen' balansere på den blokken. Vi kan ikke få direkte tilgang til disse bladnodene på kjeden, men vi kan bekrefte at innholdet i en bladnode er riktig. Faktisk eth_getProof RPC-metode støttet av Alchemy (blant andre leverandører) returnerer Merkle-bevisene som trengs for å utføre denne verifiseringen (Leo Zhang gir en utdypende forklaring av hvordan dette fungerer i sammenheng med Ethereum light-klienter). Dette betyr at med litt hjelp utenfor kjeden (et enkelt RPC-anrop), kan budgivere bevise overfor SneakyAuction-kontrakten at hvelvet deres ble bevilget i løpet av budperioden. 

I vår implementering er første bud avslørt for en auksjon lagrer blockhash fra forrige blokk. Denne transaksjonen overfører effektivt auksjonen fra budfasen til avsløringsfasen - alt påfølgende bud avslørt må gi et Merkle-bevis på at hvelvet deres var tilstrekkelig sikret før den blokkeringen (dvs. før det første budet ble avslørt). Merk at først revealBid transaksjonen vil ideelt sett bli sendt via en privat transaksjonspool (f.eks. Flashbots); Ellers kan en budgiver som ser på mempoolen (som ser verdien av det avslørte budet) kjøre transaksjonen i forkant og legge inn et bud i siste sekund. 

LibBalanceProof

For å minimere kostnader for budgivere skrev vi en gassoptimalisert bibliotek å verifisere balansebevis på kjeden som bygger på kontrakter skrevet av Aragon-teamet (som var banebrytende for lagringsprøver på kjeden i 2018), og Hamdi Allams kontrakter for kjeden RLP-dekoding. Biblioteket vårt bruker en rekke triks og optimaliseringer på lavt nivå som er avhengige av statens spesielle struktur, så det kan ikke brukes til generiske Merkle-Patricia-prøvebevis. Til gjengjeld lar det SneakyAuction-kontrakten verifisere den tidligere balansen til et hvelv med mindre enn 30,000 XNUMX gass.

Vi skrev også en lettvekter JavaScript-innpakning for eth_getProof RPC-metoden. Gitt en adresse og blokknummer, returnerer den balansebeviset og RLP-serialisert blokkoverskrift, som kan brukes til å avsløre et bud. 

Hvordan det sammenlignes 

La oss sammenligne vår nye SneakyAuction-tilnærming med OverCollateralizedAuction-designet vi sist ga ut, sammen med flere nøkkeldimensjoner som tekniske designere eller brukere bryr seg om: gasskostnader, brukeropplevelse og personvern. 

Gasskostnader

SneakyAuction's revealBid, endAuctionog withdrawCollateral funksjoner krever utplassering av en SneakyVault, så de er dyrere enn sine OverCollateralizedAuction-kolleger. revealBid er spesielt dyrt fordi det også verifiserer et balansebevis, som koster rundt 25,000 XNUMX gass.

Omtrentlig gasskostnader ved ulike operasjoner, basert på støperienhetstester

Brukeropplevelse

Selv om de to implementeringene følger en lignende overordnet flyt (budfase, avsløringsfase, auksjonsavslutning), er det noen forskjeller i brukeropplevelsen. SneakyAuction har noen få mindre ulemper:

• Opplevelsen av å sende ETH til et ikke-utplassert hvelv, selv om det kan abstraheres bort av front-end, er potensielt forvirrende for brukere som undersøker budtransaksjonen deres på en blokkutforsker.
• Med OverCollateralizedAuction er det mulig å avslutte auksjonen tidlig hvis alle bud har blitt avslørt. Dette er ikke mulig i SneakyAuction fordi kontrakten ikke har noen mulighet til å vite hvor mange bud som er gitt.
• Budgivere kan oppdatere budet og fylle på sikkerheten med OverCollateralizedAuction ved å ringe commitBid en gang til. I SneakyAuction kan ikke budgivere foreta oppdateringer når budets hvelv er mottatt.

Privatliv

Budpersonvernet til OverCollateralizedAuction er avhengig av at budgivere velger å låse opp ekstra sikkerhet (slik at tilskuere kjenner en øvre grense for et bud, men ikke det nøyaktige beløpet). SneakyAuction, derimot, henter personvern fra aktivitet på kjeden som er fullstendig urelatert til selve auksjonen: ETH-overføringer som skjer i løpet av auksjonens budperiode. 

For enkelhets skyld, la oss anta at hvert bud er sikret med en enkelt ETH-overføring. Vi observerer at: 

1. Sikkerhetstransaksjonen skal være første gang noen har interaksjon med hvelvadressen på kjeden. 
2. Vi forventer ikke at andre transaksjoner berører hvelvadressen for resten av budperioden. 
3. Ingen transaksjoner kan stamme fra hvelvadressen (fordi ingen har den private nøkkelen). 

ETH-overføringer i løpet av budperioden til ellers "uberørte" adresser er plausibelt bud - med andre ord er de "støyen" som skjuler budtransaksjoner. For å hjelpe til med å kvantifisere personvernet til SneakyAuction, kan vi se på formen på denne støyfordelingen.

Dette histogrammet viser hittil år distribusjon av daglige ETH-overføringer (på Ethereums hovednett) til uberørte adresser, og illustrerer støyfordelingen for en 24-timers budperiode. Vi kan se at de fleste transaksjoner faller innenfor [0.001, 1] ETH-området, noe som antyder at auksjoner med en forventet budverdi i det området vil ha det sterkeste personvernet. På den annen side kan det hende at den typiske støyen ikke gir tilstrekkelig personvern for auksjoner der det forventede budet er høyere enn 10 ETH – det er sjelden mer enn 100 overføringer i det området, så en auksjon som tiltrekker seg mange bud vil skape en iøynefallende økning i fordelingen . 

For et annet perspektiv på disse dataene viser disse spredningsplottene overføringene 15. oktober 2022, overlagt med bud fra to hypotetiske auksjoner: 

Intuitivt ville det være mye lettere for en observatør å identifisere bud fra den andre auksjonen. I praksis kan du bruke en klyngealgoritme som f.eks forventningsmaksimering (EM) algoritme for å forutsi hvilke transaksjoner som er bud. 

Det er imidlertid noen få andre faktorer som kan gjøre SneakyAuction mer privat (og derfor mer overbevisende) i praksis:

1. Lengre budperioder: Personvern skalerer med lengden på budperioden –– jo lengre budperioden er, jo flere overføringer er det for å skjule bud. 
2. Samtidige auksjoner: Personvern skalerer med antall samtidige auksjoner –– hvis to auksjoner er i sine budfaser samtidig, fungerer den ene auksjonens bud som støy for den andre.

SneakyAuction kan også dra nytte av oversikkerhet – siden SneakyVault returnerer eventuell overskytende ETH til budgiveren, kan budgivere velge å oversikre for ytterligere personvern. Så på en måte gir SneakyAuction strengt tatt sterkere personvern enn vår forrige implementering.

En enkel konsekvens av SneakyAuctions personvernmekanisme er at den skjuler Antall av bud i løpet av budperioden. Dette er en fordel fremfor OverCollateralizedAuction, som bare skjuler budverdiene - antallet budforpliktelser som er gitt for en gitt auksjon er fullt offentlig (og kan gi bort hvor konkurransedyktig auksjonen er).

***

Mens vår første implementering av en auksjon med forseglet bud oversatte funksjoner fra den virkelige verden til designbeslutninger i kjeden, er vårt andre design avhengig av en ny og praktisk mekanisme for å bruke blokkjedenes offentlige natur til sin fordel: forseglede bud «gjemmer seg» blant urelaterte blokkjedeaktivitet.

Selv om denne nye tilnærmingen er en praktisk måte å oppnå personvern for bud på uten oversikkerhet, er den ikke nødvendigvis egnet for alle auksjoner (for eksempel auksjoner med mange bud med høy verdi). Personvernet forbedres for auksjoner som forventer mindre bud (og spesielt over en lengre periode).

***
Synspunktene som er uttrykt her, er de fra individuelle AH Capital Management, LLC (“a16z”) personell som er sitert og er ikke synspunktene til a16z eller dets tilknyttede selskaper. Visse opplysninger her er innhentet fra tredjepartskilder, inkludert fra porteføljeselskaper av fond forvaltet av a16z. Selv om a16z er hentet fra kilder som antas å være pålitelige, har ikke a16z uavhengig verifisert slik informasjon og gir ingen representasjoner om den nåværende eller varige nøyaktigheten til informasjonen eller dens hensiktsmessighet for en gitt situasjon. I tillegg kan dette innholdet inkludere tredjepartsannonser; aXNUMXz har ikke vurdert slike annonser og støtter ikke noe reklameinnhold som finnes deri.

Dette innholdet er kun gitt for informasjonsformål, og bør ikke stoles på som juridisk, forretningsmessig, investerings- eller skatterådgivning. Du bør rådføre deg med dine egne rådgivere om disse sakene. Referanser til verdipapirer eller digitale eiendeler er kun for illustrasjonsformål, og utgjør ikke en investeringsanbefaling eller tilbud om å tilby investeringsrådgivningstjenester. Videre er dette innholdet ikke rettet mot eller ment for bruk av noen investorer eller potensielle investorer, og kan ikke under noen omstendigheter stoles på når du tar en beslutning om å investere i et fond som forvaltes av a16z. (Et tilbud om å investere i et a16z-fond vil kun gis av det private emisjonsmemorandumet, tegningsavtalen og annen relevant dokumentasjon for et slikt fond og bør leses i sin helhet.) Eventuelle investeringer eller porteføljeselskaper nevnt, referert til, eller beskrevet er ikke representative for alle investeringer i kjøretøy forvaltet av a16z, og det kan ikke gis noen garanti for at investeringene vil være lønnsomme eller at andre investeringer som gjøres i fremtiden vil ha lignende egenskaper eller resultater. En liste over investeringer foretatt av fond forvaltet av Andreessen Horowitz (unntatt investeringer som utstederen ikke har gitt tillatelse til at a16z kan offentliggjøre så vel som uanmeldte investeringer i børsnoterte digitale eiendeler) er tilgjengelig på https://a16z.com/investments /.

Diagrammer og grafer gitt i er kun for informasjonsformål og bør ikke stoles på når du tar investeringsbeslutninger. Tidligere resultater er ikke en indikasjon på fremtidige resultater. Innholdet taler kun fra den angitte datoen. Eventuelle anslag, estimater, prognoser, mål, prospekter og/eller meninger uttrykt i dette materialet kan endres uten varsel og kan avvike eller være i strid med meninger uttrykt av andre. Se https://a16z.com/disclosures for ytterligere viktig informasjon