Hidden in Plain Sight: En lömsk soliditetsimplementering av en auktion med förseglade bud

Redaktörens anmärkning: Det här stycket är en del av vår pågående serie om allt som är auktioner för web3. del 1 var en översikt över auktionsdesigner och tekniska utmaningar (och möjligheter) specifika för mekanismdesign i ett tillståndslöst blockkedjekontext. del 2 var en del om att rensa marknaden och undvika gaskrig. del 3 delar en översikt över kanoniska auktionstyper, en titt på hur teori omsätts i praktiken och vår första implementering av en ny Vickrey-auktion med förseglat bud. 

Auktioner i kedjan är en av de mest intressanta (och allestädes närvarande) designutrymmena i web3 – från NFT-försäljning till bilaterala auktioner – vilket ger upphov till ett nytt landskap av implementeringar och forskning. Även om design av auktionsmekanismer har funnits i århundraden och har utvecklats under de senaste decennierna med tillkomsten av webben och e-handeln, tillämpar vi först nu dessa metoder för smarta kontrakt.

Vi börjar också se fler auktionsdesigner som är inhemska i blockkedjor, inklusive vår öppen källkod Soliditetsimplementering av en Vickrey-auktion och flera intressanta utvecklingar från samhället (inklusive föreslagna för effektivitetsförbättringar, nytt teoretiska resultat, och två hackathon-vinnande implementeringar av auktioner med förseglade bud). I vår första design gjorde vi en avvägning mellan integritet och kapitaleffektivitet: vi använde översäkerhet (budgivare låser upp mer säkerheter än vad som krävs av deras bud) för att tvinga fram betalning från den vinnande budgivaren, utan att avslöja de exakta budvärdena via säkerheten belopp. Genom att låsa in mer kapital får du mer integritet till en potentiellt högre alternativkostnad. Men tänk om vi kunde ha bjudit integritet utan översäkerhet? 

Det här inlägget introducerar en ny auktionsdesign som vi kallar "SneakyAuction", som kombinerar CREATE2 opcode och statliga bevis för att garantera budets integritet utan att kräva att budgivare låser in mer säkerheter än vad som krävs. Vi börjar med att dela upp hur det fungerar och sedan jämföra det med vår tidigare implementering (OverCollateralizedAuction) när det gäller gaskostnad, användarupplevelse och integritet. Vi har också lagt till implementeringen till vår Auktionszoo repository på GitHub så att du kan dela det, bygga på det och följa med när vi dyker in i mer mekanik; under tiden, mer om hur det fungerar och jämför med vår tidigare design nedan. 

Så här fungerar det: Förbinder sig till bud med CREATE2

Det finns två krav vi behöver för att skapa en "så småningom-offentlig" auktion med förseglade bud på kedjan. Först måste buden vara privata under budperioden och sedan avslöjas när den slutar. commit-reveal-scheman (där användare publicerar hash-kommitterade värden och sedan avslöjar sina indata senare) kan replikera denna mekanism i kedjan. Det andra kravet är säkerheter: bud måste backas upp av säkerheter för att säkerställa att vinnaren har tillräckligt med pengar för att uppfylla sitt åtagande. 

I vår översäkrade Vickrey-implementering lägger potentiella köpare bud genom att ringa commitBid funktion, tillhandahåller ett hashåtagande och de säkerheter som ska deponeras. Detta tillvägagångssätt uppfyller kraven, men har vissa nackdelar. Även om själva budet är dolt av hashen, commitBid transaktionen signalerar öppet och omedelbart användarens avsikt: "Jag skulle vilja bjuda på den här auktionen, och här är säkerheten för mitt bud." Utan översäkerhet, synlighet (och länkbarhet) för båda uppsåt och säkerhet skulle avslöja budvärden. Men om vi kan fördunkla avsikten med en transaktion kan vi kanske uppnå budintegritet utan att förlita oss på översäkerhet. 

Smakämnen CREATE2 opcode, introducerad i EIP-1014 och ingår i Konstantinopel hårdgaffel, ger oss ett sätt att göra just det. De CREATE och CREATE2 opcodes används båda för att distribuera smarta kontrakt, men de skiljer sig åt i hur distributionsadresserna beräknas. De CREATE distributionsadress beräknas som en hash av driftsättarens adress och nonce; de CREATE2 distributionsadress, å andra sidan, beräknas som en hash av kontraktets bytekod och konstruktorparametrar, ett godtyckligt salt och deployerns adress (detaljer).

CREATE2 används ofta i fabriksmönstret för att distribuera kontrakt till förutsägbara adresser - till exempel UniswapV3PoolDeployer kontraktsanvändningar CREATE2 att distribuera varje poolkontrakt till en adress som är en funktion av tokenparet och avgiftsnivån. CREATE2 kan också användas för att (om)distribuera uppgraderingsbara smarta kontrakt, framför allt i metamorf kontraktsmönster.

Ännu viktigare för oss är CREATE2 distributionsadressen kan fungera som en hash-åtagande för alla beteenden som definieras av indatabytekoden och parametrarna. Om konstruktorparametrarna kodar ett bud, CREATE2 adress kan fungera som ett budåtagande.

Dessutom kan själva kontraktet fungera som ett valv - en budgivare kan skicka ETH till CREATE2 valv adress innan kontraktet distribueras att ställa säkerhet och förbinda sig till sitt bud i en enkel överföring! Eftersom budgivaren inte har den privata nyckeln för valvets adress, låses säkerheten tills budet avslöjas, då SneakyAuction-kontraktet distribueras och låser upp valvet. 

Detta tillvägagångssätt gör att transaktionen inte kan skiljas från en överföring till en externt ägd adress (EOA). Budtransaktionen är gömd i sikte, bland andra överföringar på blockkedjan. En viktig varning, dock: denna till synes snygga lösning gör det också svårt att avgöra när säkerheten var låst. Det är viktigt för auktionssäkerheten att valvet finansierades innan några bud avslöjas. Annars kan en opportunistisk köpare vänta till slutet av avslöjningsperioden, då de flesta buden redan har avslöjats, för att bestämma sig för att ställa säkerhet i sitt valv eller inte. Vi måste se till att valven har säkerhet under budperioden, inte under avslöjningsperioden, med ett annat verktyg: statliga bevis.

Retroaktivt verifiera säkerheter med hjälp av statliga bevis

Ett sätt att säkerställa att ett valv har ställts som säkerhet under budperioden är att kontrollera dess saldo vid ett tidigare block. Det är relativt enkelt att göra detta utanför kedjan genom att fråga en arkivnod; men mycket svårare att åstadkomma (troligt) på kedjan. EVM:erna BALANCE opcode läser det aktuella saldot för en adress, men det finns ingen sådan opcode för att hämta en Tidigare balans. Faktum är att den enda EVM-opkoden som ger någon form av historisk tillståndsåtkomst är BLOCKHASH, som returnerar hashen för ett av de senaste 256 blocken. Lyckligtvis - med lite hjälp utanför kedjan - fungerar blockhash precis tillräckligt bra för vårt användningsfall.

Blockhash är hash för blockhuvudet, som inkluderar (bland annat metadata) den statlig rot av det blocket. Tillståndsroten är rotnoden för a Merkle-Patricia försöker, där varje bladnod motsvarar en viss adress och inkluderar adressen" balansera vid det kvarteret. Vi kan inte direkt komma åt dessa lövnoder i kedjan, men vi kan verifiera att innehållet i en lövnod är korrekt. Faktum är att eth_getProof RPC-metod som stöds av Alkemi (bland andra leverantörer) returnerar Merkle-bevisen som behövs för att utföra denna verifiering (Leo Zhang tillhandahåller en djupgående förklaring om hur detta fungerar i samband med Ethereum light-klienter). Detta innebär att med lite hjälp utanför kedjan (ett enda RPC-samtal) kan budgivare bevisa för SneakyAuction-kontraktet att deras valv var belånat under budperioden. 

I vår implementering är första budet avslöjade för en auktion lagrar blockhash från föregående block. Denna transaktion överför effektivt auktionen från budgivningsfasen till avslöjningsfasen - allt efterföljande bud avslöjade måste ge ett Merkle-bevis på att deras valv var tillräckligt säkrad före det blocket (dvs innan det första budet avslöjades). Observera att först revealBid transaktionen skulle helst skickas via en privat transaktionspool (t.ex. Flashbots); Annars kan en budgivare som tittar på mempoolen (som ser värdet av det avslöjade budet) köra transaktionen i förväg och lägga ett bud i sista sekund. 

LibBalanceProof

För att minimera kostnaderna för budgivare skrev vi en gasoptimerad bibliotek för att verifiera balansbevis på kedjan som bygger på kontrakt skrivna av Aragon-teamet (som var banbrytande för lagringsprovisor på kedjan 2018), och Hamdi Allams kontrakt för on-chain RLP-avkodning. Vårt bibliotek använder ett antal trick och optimeringar på låg nivå som förlitar sig på statens särskilda struktur, så det kan inte användas för generiska Merkle-Patricia-provbevis. I gengäld tillåter det SneakyAuction-kontraktet att verifiera den tidigare balansen i ett valv med mindre än 30,000 XNUMX gas.

Vi skrev också en lättviktare JavaScript-omslag för eth_getProof RPC-metod. Med en adress och ett blocknummer returnerar den balansbeviset och RLP-serialiserad blockrubrik, som kan användas för att avslöja ett bud. 

Hur det jämförs 

Låt oss jämföra vår nya SneakyAuction-metod mot OverCollateralizedAuction-designen som vi senast släppte, längs flera nyckeldimensioner som tekniska designers eller användare bryr sig om: gaskostnader, användarupplevelse och integritet. 

Gaskostnader

SneakyAuction's revealBid, endAuctionoch withdrawCollateral funktioner kräver att en SneakyVault, så de är dyrare än deras OverCollateralizedAuction-motsvarigheter. revealBid är särskilt dyrt eftersom det också verifierar ett balansbevis, vilket kostar cirka 25,000 XNUMX gas.

Ungefärliga gaskostnader för olika operationer, baserat på gjuterietester

Användare erfarenhet

Även om de två implementeringarna följer ett liknande övergripande flöde (budgivningsfas, avslöjningsfas, auktionens slut), finns det vissa skillnader i användarupplevelsen. SneakyAuction har några mindre nackdelar:

• Upplevelsen av att skicka ETH till ett outplacerat valv, även om det skulle kunna abstraheras bort av front-end, är potentiellt förvirrande för användare som undersöker sin budtransaktion på en block explorer.
• Med OverCollateralizedAuction är det möjligt att avsluta auktionen tidigt om alla bud har avslöjats. Detta är inte möjligt i SneakyAuction eftersom kontraktet inte har någon möjlighet att veta hur många bud som har lagts.
• Budgivare kan uppdatera sitt bud och fylla på sina säkerheter med OverCollateralizedAuction genom att ringa commitBid om igen. I SneakyAuction kan budgivare inte göra uppdateringar när budets valv har ställts som säkerhet.

Integritetspolicy

Budsekretessen för OverCollateralizedAuction är beroende av att budgivare väljer att låsa upp extra säkerhet (så att åskådare vet en övre gräns för ett bud men inte det exakta beloppet). SneakyAuction, å andra sidan, härleder sekretess från aktivitet i kedjan som är helt orelaterade till själva auktionen: ETH-överföringar som sker under auktionens budperiod. 

För enkelhetens skull, låt oss anta att varje bud är belånat med en enda ETH-överföring. Vi observerar att: 

1. Säkerhetstransaktionen bör vara första gången någon har interagerat med valvadressen i kedjan. 
2. Vi förväntar oss inte att några andra transaktioner rör valvets adress under resten av budperioden. 
3. Inga transaktioner kan härröra från valvets adress (eftersom ingen har den privata nyckeln). 

ETH-överföringar under budperioden till annars "orörda" adresser är rimligtvis bud - med andra ord är de "bruset" som döljer budtransaktioner. För att hjälpa till att kvantifiera integriteten för SneakyAuction kan vi titta på formen på denna brusfördelning.

Detta histogram visar år-till-datum fördelningen av dagliga ETH-överföringar (på Ethereums huvudnät) till orörda adresser, vilket illustrerar brusfördelningen för en 24-timmars budperiod. Vi kan se att de flesta transaktioner faller inom [0.001, 1] ETH-intervallet, vilket innebär att auktioner med ett förväntat budvärde inom det intervallet skulle ha den starkaste integriteten. Å andra sidan kanske det typiska bruset inte ger tillräcklig sekretess för auktioner där det förväntade budet är högre än 10 ETH – det finns sällan fler än 100 överföringar i det intervallet, så en auktion som drar till sig många bud skulle skapa en iögonfallande topp i distributionen . 

För ett annat perspektiv på dessa data visar dessa spridningsdiagram överföringarna den 15 oktober 2022, överlagrade med bud från två hypotetiska auktioner: 

Intuitivt skulle det vara mycket lättare för en observatör att identifiera bud från den andra auktionen. I praktiken kan du använda en klustringsalgoritm som t.ex förväntningsmaximering (EM) algoritm för att förutsäga vilka transaktioner som är bud. 

Det finns dock några andra faktorer som kan göra SneakyAuction mer privat (och därför mer övertygande) i praktiken:

1. Längre budperioder: Sekretess skalar med budperiodens längd – ju längre budperiod, desto fler överföringar finns det för att dölja bud. 
2. Samtidiga auktioner: Sekretess skalar med antalet samtidiga auktioner –– om två auktioner är i sina budfaser samtidigt fungerar den ena auktions bud som brus för den andra.

SneakyAuction kan också dra nytta av översäkerhet – eftersom SneakyVault returnerar överskott av ETH till budgivaren, kan budgivare välja att översäkra för ytterligare integritet. Så på sätt och vis ger SneakyAuction en strikt starkare integritet än vår tidigare implementering.

En enkel följd av SneakyAuctions sekretessmekanism är att den döljer antal av bud under budperioden. Detta är en fördel jämfört med OverCollateralizedAuction, som bara döljer budvärdena – antalet budåtaganden som har gjorts för en given auktion är helt offentliga (och kan ge bort hur konkurrenskraftig auktionen är).

***

Medan vår första implementering av en auktion med förseglade bud översatte verkliga funktioner till designbeslut inom kedjan, bygger vår andra design på en ny och praktisk mekanism för att använda blockkedjors offentliga karaktär till sin fördel: förseglade bud "gömmer sig" bland orelaterade blockchain-aktivitet.

Även om det här nya tillvägagångssättet är ett bekvämt sätt att uppnå budintegritet utan översäkerhet, är det inte nödvändigtvis lämpligt för alla auktioner (till exempel auktioner med många högt värdefulla bud). Sekretessen förbättras för auktioner som förväntar sig mindre bud (och särskilt över en längre tidsperiod).

***
De åsikter som uttrycks här är de från den individuella AH Capital Management, LLC (“a16z”) personal som citeras och är inte åsikterna från a16z eller dess dotterbolag. Viss information som finns här har erhållits från tredjepartskällor, inklusive från portföljbolag av fonder som förvaltas av a16z. Även om den är hämtad från källor som anses vara tillförlitliga, har a16z inte självständigt verifierat sådan information och gör inga utfästelser om den aktuella eller varaktiga riktigheten av informationen eller dess lämplighet för en given situation. Dessutom kan detta innehåll innehålla tredjepartsannonser; a16z har inte granskat sådana annonser och stöder inte något reklaminnehåll i dem.

Detta innehåll tillhandahålls endast i informationssyfte och bör inte litas på som juridisk rådgivning, affärs-, investerings- eller skatterådgivning. Du bör rådfråga dina egna rådgivare i dessa frågor. Hänvisningar till värdepapper eller digitala tillgångar är endast i illustrativt syfte och utgör inte en investeringsrekommendation eller erbjudande om att tillhandahålla investeringsrådgivningstjänster. Dessutom är detta innehåll inte riktat till eller avsett att användas av några investerare eller potentiella investerare, och får inte under några omständigheter lita på när man fattar ett beslut om att investera i någon fond som förvaltas av a16z. (Ett erbjudande om att investera i en a16z-fond kommer endast att göras av det privata emissionsmemorandumet, teckningsavtalet och annan relevant dokumentation för en sådan fond och bör läsas i sin helhet.) Alla investeringar eller portföljbolag som nämns, hänvisas till, eller beskrivna är inte representativa för alla investeringar i fordon som förvaltas av a16z, och det finns ingen garanti för att investeringarna kommer att vara lönsamma eller att andra investeringar som görs i framtiden kommer att ha liknande egenskaper eller resultat. En lista över investeringar gjorda av fonder som förvaltas av Andreessen Horowitz (exklusive investeringar för vilka emittenten inte har gett tillstånd för a16z att offentliggöra såväl som oanmälda investeringar i börsnoterade digitala tillgångar) finns tillgänglig på https://a16z.com/investments /.

Diagram och grafer som tillhandahålls i är endast i informationssyfte och bör inte litas på när man fattar investeringsbeslut. Tidigare resultat är inte en indikation på framtida resultat. Innehållet talar endast från det angivna datumet. Alla prognoser, uppskattningar, prognoser, mål, framtidsutsikter och/eller åsikter som uttrycks i detta material kan ändras utan föregående meddelande och kan skilja sig åt eller strida mot åsikter som uttrycks av andra. Se https://a16z.com/disclosures för ytterligare viktig information