Noot van de redactie: dit stuk maakt deel uit van onze doorlopende serie over alles wat met veilingen te maken heeft voor web3. Deel 1 was een overzicht van technische uitdagingen (en kansen) die specifiek zijn voor het ontwerpen van kettingveilingen. Deel 2 was een stuk over het opruimen van de markt en het vermijden van gasoorlogen. Deel 3 en Deel 4 onderzoeken hoe veilingtheorie zich vertaalt in de praktijk door twee implementaties van veilingen met gesloten bod te introduceren. 

In de loop van deze serie hebben we verschillende strategieën onderzocht om de kloof te overbruggen tussen de veilingtheorie en wat er op de keten kan worden gebouwd, elk met zijn unieke nuances. We hebben ons met name gericht op de implementatie verzegeld bod, tweede prijs (Vickrey) veilingen, die al tientallen jaren worden gebruikt voor de verkoop van kunst, hout en advertentieruimte. Maar we zien ze zelden geïmplementeerd onbetrouwbaar het gebruik van slimme contracten, deels vanwege de moeilijkheid om onderhandse biedingen uit te voeren. Het transparante karakter van openbare blockchains kan oneerlijkheid voorkomen tussenpersonen van het censureren van biedingen of het manipuleren van veilingresultaten; maar ze stellen ontwikkelaars ook voor uitdagingen, die nieuwe oplossingen moeten vinden om de privacy van hun gebruikers te beschermen. 

In onze vorige veilingimplementaties hebben we twee benaderingen gebruikt om on-chain biedingen privé te houden: de eerste (Overcollateralized-veiling) verbergt biedwaarden door middel van overcollateralisatie (waarbij bieders meer onderpand vastleggen dan nodig is voor het bod), waardoor de privacy wordt beschermd ten koste van kapitaalefficiëntie. Dit leidde ons naar ons tweede ontwerp (Sneakyveiling), die gebruik maakt van de CREATE2 opcode om biedingen en andere overdrachten op de blockchain te camoufleren. Maar empirische analyse toonde aan dat deze aanpak niet effectief zou zijn in het verbergen van zeer grote biedingen die afwijken van bedragen die doorgaans op Ethereum worden verhandeld. 

In dit bericht komen we terug met een nieuwe ketenoverschrijdende benadering (genaamd AztecConnect-veiling) die privacy kunnen bieden aan biedingen van elke omvang, zonder dat er extra zekerheden nodig zijn. Door te vertrouwen op meerdere blockchains wordt functionaliteit bereikt die alleen op een enkele keten niet mogelijk zou zijn, en biedt het ontwikkelaars een andere reeks voordelen en afwegingen waarmee ze rekening moeten houden bij het implementeren van hun eigen protocollen. In ons geval gebruiken we Aztec Connect om de anonimiteit van Aztec's ZK rollup te benutten, terwijl we de voordelen van Ethereum L1-afwikkeling behouden. 

We hebben de implementatie toegevoegd aan onze veiling dierentuin repository op GitHub, naast onze eerdere veilingimplementaties. We hopen dat u hierop voortbouwt, uw ideeën deelt, en stuur ons uw feedback.

Hoe het werkt

Eerst even een opfriscursus over de Vickrey veiling: Bieders dienen privébiedingen (traditioneel voor een enkel item) in verzegelde enveloppen in bij de veilingmeester. De hoogste bieder wint, maar betaalt het op een na hoogste bod. Om deze kenmerken on-chain te vertalen, volgt onze nieuwe veiling dezelfde blauwdruk als voorheen: Biedingen worden gedekt en vastgelegd tijdens de "biedingsfase", op een zodanige manier dat hun precieze waarden pas worden onthuld als ze worden onthuld in de daaropvolgende "onthullingsfase". Zodra de onthullingsfase voorbij is, kan de veiling worden beëindigd en betaalt de winnende bieder de verkoper het bedrag van het op één na hoogste bod (de Vickrey betalingsregeling). Onze veilingimplementaties verschillen in de manier waarop ze biedingen verborgen houden tijdens de biedfase. Deze keer gebruiken we een mechanisme dat kapitaalefficiënt is, zelfs voor grote biedingen. 

Biedingen verbergen via “splitsen”

In OverCollateralizedAuction was privacy afhankelijk van overcollateralisatie om de exacte biedwaarde te verbergen. In SneakyAuction konden we bodprivacy bereiken door de CREATE2-opcode te gebruiken om de aandachtig van een biedtransactie –– de waarde van de transactie is publiekelijk zichtbaar, maar de transactie is niet te onderscheiden van een normale ETH-overdracht.

Een alternatieve benadering is om de waarde van een bod te verdoezelen door het op te splitsen in meerdere, niet-koppelbare transacties. Stel je voor dat een veilingmeester drie cheques ontvangt van $ 100, $ 200 en $ 300, elk ondertekend met onzichtbare inkt. Alle drie hadden ze kunnen zijn ondertekend door dezelfde bieder, die een bod uitbracht van $ 600. Of het kunnen drie afzonderlijke biedingen zijn, ondertekend door drie respectieve bieders. Of er kunnen twee bieders zijn, van wie er één zijn bod heeft opgesplitst in twee cheques. Zelfs als de chequebedragen openbaar zijn, blijven de onderliggende biedwaarden verborgen totdat de handtekeningen worden onthuld.

Als we dit on-chain vertalen, kunnen bieders hun biedingsonderpand in meerdere betalingstransacties verzenden vanaf niet-koppelbare portemonnee-adressen. Bij elke transactie bieden ze een hash-toezegging die later kan worden geopend om de stukken weer aan elkaar te koppelen. De toezegging kan bijvoorbeeld worden berekend als keccak256(totalBidValue, bidderId, nonce), waar betalingen met hetzelfde bidderId en totalBidValue maken deel uit van hetzelfde bod. Het willekeurige nonce waarde voorkomt dat biedingen met brute kracht worden teruggevorderd.

Het onderliggende concept is logisch als een manier om de privacy van de bieder te behouden, maar een keerzijde van deze aanpak is dat de bieder meerdere niet-gekoppelde portemonnee-adressen moet hebben, gefinancierd met de bedragen die hij van plan is te gebruiken voor zijn bod. Dit kan in de praktijk moeilijk te bereiken zijn - zelfs het ontwijken van een amateur Etherscan-speurneus vereist zorg, laat staan ​​​​institutionele forensische hulpmiddelen zoals Chainalysis of TRM.

Erger nog, openbaar maken van een bod en permanent alle gebruikte adressen koppelen. Dus om in een volgende veiling te bieden, heeft u een nieuwe set niet-gekoppelde adressen nodig. Om dit probleem op te lossen, wenden we ons tot een andere tool: Aztec Connect. 

Aztec Connect voor anoniem bieden

Azteekse verbinding is een raamwerk waarmee gebruikers toegang krijgen tot slimme contracten op Ethereum L1 vanuit de privacy van Aztec's ZK-pakket. Het rollup-processorcontract op Ethereum kan naar compatibel bellen overbruggingscontracten die zich houden aan een specifieke interface, waardoor Azteekse gebruikers kunnen communiceren met die contracten met hun in bewaring gegeven activa. Een bridge-contract wordt doorgaans aangesloten op een bestaand DeFi-protocol op L1; er zijn bijvoorbeeld bruggen voor gerealiseerd uniswap, Lido en Element Financiën.

De belangrijkste eigenschap die Aztec Connect onze veiling biedt, is Anonimiteit: het Aztec-account dat de Aztec Connect-transactie heeft gegenereerd, is verborgen voor waarnemers. Anonimiteit stelt ons in staat om het schema na te bootsen met behulp van niet-gekoppelde adressen die in de vorige sectie zijn beschreven. Het onthullen van een bod zal niet onthullen welk Aztec-account is gebruikt om het bod te plaatsen, dus hetzelfde account kan voor meerdere veilingen worden gebruikt zonder de privacy in gevaar te brengen. 

Een toezegging communiceren

Anonimiteit alleen is niet voldoende om een ​​bod uit te brengen. We moeten ook een hash-toezegging koppelen aan elke betaling die later kan worden geopend tijdens de onthullingsfase. Herinner dat erin Overcollateralized-veiling, wordt de toezegging geleverd als een parameter voor de commitBid</code<-functie, die de toezegging en het onderpandbedrag in opslag registreert. In Sneakyveiling, onderpand wordt verzonden naar een niet-geïmplementeerde CREATE2 contract, het adres waarvan dient als de hash-verbintenis. 

In een Aztec Connect-bridgecontract worden alle cross-chain-oproepen gerouteerd via de bridge's convert functie (zie hieronder). De activaparameters maken meestal de intentie van de oproep ondubbelzinnig –– in de Lido-brug, bijvoorbeeld als het input-activum ETH is, is de convert functie converteert het naar verpakte stETH; als het invoermiddel is ingepakt, STETH de convert functie converteert het naar ETH. Om een ​​bod uit te brengen in ons veilingcontract, zouden bieders een beroep doen op de convert functioneren met ETH als invoermiddel (eenmaal per betaling). 

Interface van de convert functie (van de Aztec docs)

Soms zijn de activa alleen niet voldoende om het beoogde gedrag van de oproep te bepalen. De Uniswap-brug, laat gebruikers bijvoorbeeld privé tokens uitwisselen op Uniswap v3. Om dit te doen, moet de gebruiker het pad van de transactie, dwz tegen welke activapools u wilt ruilen –– om de beste verkoopprijs van ETH voor DAI te verkrijgen, wilt u misschien de pool van 30 bps gebruiken om ETH in USDC te verhandelen, en vervolgens de pool van 1 bps om USDC in DAI te verhandelen. Om dit handelspad te specificeren, moet de gebruiker de intermediate token (USDC) en fee tiers (30 bps en 1 bps) opgeven voor de twee gebruikte pools. 

De convert functie auxData parameter is hoe deze "hulpgegevens" worden doorgegeven aan de brug. Merk echter op dat auxData is slechts 64 bits! (Dit is een artefact van de afweging tussen de grootte van gespreksdata en bewijskosten –– meer auxData zou langere rijstijd en hogere gaskosten vereisen. 64 bits is een redelijk evenwicht voor de meeste gebruikssituaties) Dit betekent dat bridges zuinig moeten zijn in de manier waarop ze hun hulpgegevens gebruiken: de Uniswap-bridge codeert paden door tokens en fee-tiers weer te geven met elk slechts een paar bits (het coderingsschema is beschreven hier).

Ons eerste instinct zou kunnen zijn om te gebruiken auxData voor onze hashtoezegging. Maar auxData is slechts 64 bits, wat niet genoeg is om cryptografisch veilig te zijn. Slimme codeertrucs zullen hier niet werken - elke poging om de toezegging te comprimeren zou de beveiliging ervan in gevaar brengen. Om de beperkingen van auxData, zullen we creatief moeten worden. 

Virtuele activa en herbestemming inputValue

Anders dan auxData, de enige andere parameter van convert die kan worden gebruikt om willekeurige gegevens te coderen is inputValue –– de hoeveelheid inputactiva die wordt gebruikt in de Aztec Connect-transactie. Maar kunnen we gebruiken inputValue om onze hasjverplichting te coderen? Om ervoor te zorgen dat de parameter een cryptografisch veilige hash-toezegging codeert (ongeveer 256 bits), moet de bieder een lot van welk input-activum dan ook wordt gebruikt –– zozeer zelfs dat elk activum met echte geldwaarde uitgesloten is. 

Gelukkig heeft Aztec Connect het idee van virtuele activa, die worden gebruikt om middelen weer te geven die het Azteekse netwerk niet ondersteunt. Het belangrijkste voor onze use-case is dat een brug een willekeurig bedrag van een virtueel activum in een convert telefoongesprek. Dit leidt ons naar het volgende proces met twee transacties voor het communiceren van een hashtoezegging via Aztec Connect:

1. In de eerste transactie is het input-activum ETH en het output-activum virtueel. De bieder stort ETH-onderpand en ontvangt (2²⁵⁶ – 1) eenheden van het virtuele activum in ruil. Een opslagslot wordt bijgewerkt om aan te geven dat een hash-commitment "in uitvoering" is.
2. In de tweede transactie is het ingevoerde activum het virtuele activum dat is ontvangen in stap 1. De inputValue wordt geïnterpreteerd als de hash-toezegging en samen met de huidige tijdstempel opgeslagen. 

De levenscyclus van een Aztec Connect-veiling

De bieder stort ETH en ontvangt het virtuele activum. 

De bieder registreert een hashtoezegging door een deel van het virtuele activum te verbranden dat hij in de vorige stap heeft ontvangen. 

Met deze procedure in twee stappen omzeilen we de groottebeperking van auxData en associeer elke betaling met een veilige hash-verbintenis. Het nadeel van deze aanpak is dat er twee transacties per betaling nodig zijn. 

Hoe het zich verhoudt? 

Nu we een haalbare implementatie hebben voor onze Aztec Connect-veiling, kunnen we deze vergelijken met onze twee eerdere implementaties (OverCollateralizedAuction en SneakyAuction) –– kijkend naar gaskosten, gebruikerservaring en privacy in het bijzonder. 

Gaskosten

AztecConnectAuction's createAuction, endAuction en withdrawCollateral functies hebben vergelijkbare gaskosten als onze eerdere implementaties. De kosten van het vastleggen en onthullen van een bod schalen met het aantal stukken waarin het onderpand is opgesplitst. De volgende tabel toont de geschatte gaskosten voor een bieding die in twee delen is gesplitst.

Geschatte gaskosten van verschillende operaties, gebaseerd op Foundry-eenheidstests en Aztec Connect gas schattingen

User experience

Hoewel AztecConnectAuction een vergelijkbare stroom volgt als onze vorige implementaties (biedfase, onthullingsfase, veiling eindigt), zijn er enkele UX-eigenaardigheden die gepaard gaan met cross-chain werken. 

De verkoper hoeft geen activa te overbruggen of Azteekse transacties te doen en wordt uitbetaald op L1 wanneer de veiling eindigt. De bieders voeren daarentegen enkele acties uit op Aztec en andere op Ethereum:

• Biedingen worden gecommitteerd en gedekt via Aztec Connect. Dit betekent dat bieders al ETH op Aztec moeten hebben, of deze op een andere manier moeten overbruggen voordat ze hun bod uitbrengen.
• Biedingen worden onthuld op Ethereum. Het onthullen van een bod vereist relatief veel calldata (zelfs onze inputValue truc is niet genoeg), dus het moet rechtstreeks op Ethereum worden gedaan. 
• Zodra een veiling is afgelopen, hebben bieders de mogelijkheid om onderpand in te trekken voor Ethereum of Aztec. Bieders kunnen zich terugtrekken in Ethereum door de withdrawCollateral functie op het veilingcontract. Als ze hun ETH op L2 willen houden (bijvoorbeeld om te bieden in toekomstige veilingen), kunnen ze geld opnemen op hun Aztec-account met een Aztec Connect-transactie. 

Tot slot nog twee extra praktische problemen: ten eerste zijn voor het aangaan van een bod twee Aztec Connect-transacties per onderpand vereist. We zouden dit aan de voorkant kunnen abstraheren tot een enkele gebruikersinteractie voor een meer naadloze ervaring. Ten tweede moeten deze transacties gedurende de biedperiode worden verspreid om de privacy te maximaliseren. We zouden deze taak kunnen delegeren aan een bot, die de transacties namens de bieders zou indienen.

Over het algemeen is de gebruikerservaring voor verkopers bijna identiek aan die van onze eerdere implementaties. De ervaring voor bieders is gecompliceerder – ze moeten meerdere transacties uitvoeren om een ​​bod uit te brengen en ze moeten tijdens de veiling communiceren met zowel Ethereum als Aztec. 

Privacy

Een opmerkelijk voordeel dat AztecConnectAuction heeft ten opzichte van onze vorige twee implementaties, is dat het plausibel privacy kan bieden voor hoogwaardige veilingen zonder de kapitaalefficiëntie in gevaar te brengen. In OverCollateralizedAuction worden de kosten van overcollateralisatie verergerd wanneer de biedingen zelf aanzienlijk onderpand vereisen. In SneakyAuction is privacy afhankelijk van exogene ETH-overdrachten, die meestal niet groot genoeg zijn om hoogwaardige biedingen te verbergen. 

Net als SneakyAuction stelt AztecConnectAuction bieders ook in staat om hun biedingen te onderpand te geven voor een extra privacylaag. Biedingsprivacy schaalt ook met het aantal gelijktijdige veilingen - als twee veilingen tegelijkertijd in hun biedfase zijn, dienen de biedingen van de ene veiling als ruis voor de andere. Bieders blijven anoniem tijdens de biedperiode en het totale aantal biedingen is verborgen. 

Dat gezegd hebbende, heeft AztecConnectAuction zijn eigen kanttekeningen. Bieders moeten zich bewust zijn van de voetafdrukken in de keten die ze achterlaten, wat hun privacy in gevaar kan brengen:

• Tijdstip van betaling: Menselijke bieders kunnen onbedoeld hun betalingen zodanig timen dat hun biedprivacy kan worden verzwakt (bijvoorbeeld door betalingen snel achter elkaar uit te voeren of door een betaling op hetzelfde moment over een aantal dagen uit te voeren). 
• Instroom en uitkeringsbedragen: Stortingen aan Aztec vlak voor of tijdens het bieden kunnen erop wijzen dat dit geld zal worden gebruikt om op de veiling te bieden. Bieders moeten rekening houden met de wisselwerking tussen instromen, betalingsbedragen en timing. Een aanbetaling van 10 ETH aan Aztec, snel gevolgd door betalingen van 5 ETH, 3 ETH en 2 ETH, kan bijvoorbeeld gemakkelijk het vermoeden wekken dat die betalingen deel uitmaken van hetzelfde bod. 

Deze overwegingen zijn niet uniek voor onze veiling; het overbruggen van activa tussen een private en publieke blockchain introduceert inherent potentieel voor privacylekkage (Aztec's documentatie geeft meer details over de nuances van cross-chain privacy). Het goede nieuws is dat de proliferatie van Aztec-compatibele applicaties zoals deze veiling meer reden creëert om activa voor de lange termijn op Aztec te houden, in plaats van heen en weer te overbruggen. Meer activiteit op Aztec groeit privacy-sets, wat de waardepropositie versterkt van applicaties die op Aztec zijn gebouwd, wat meer activiteit genereert –– een positieve spiraal.

***

Dit uitstapje naar on-chain veilingen met verzegeld bod bracht ons buiten de muren van Ethereum L1, gebruikmakend van Aztec's private rollup om biedactiviteiten te anonimiseren. Ons derde recept voor veilingen met gesloten biedingen –– anonimiteit plus het splitsen van onderpand –– heeft zijn eigen privacykenmerken en -nuances, die we hebben vergeleken met onze eerdere ontwerpen, en die anderen misschien willen vergelijken met hun eigen benaderingen.

Onze veilingimplementatie is er een van een handvol native cross-chain slimme contractprotocollen, die afhankelijk zijn van het werken over meerdere blockchains om functionaliteit te bereiken die op een enkele keten alleen niet mogelijk zou zijn. Naarmate de cross-chain-infrastructuur volwassener wordt, verwachten we de opkomst van native cross-chain-protocollen die gebruikmaken van de unieke mogelijkheden van verschillende blockchains. We hopen dat onze veiling met gesloten bod enige inspiratie biedt voor wat hier mogelijk is.

Dankwoord: Bedankt aan het Aztec-team (Joe Andrews, Josh Crites) voor het beantwoorden van mijn vele vragen over Aztec Connect; Matt Gleason en Noah Citron voor het beoordelen van de code; en aan Daejun Park, Joseph Bonneau, Scott Kominers, Sonal Chokshi en Tim Roughgarden voor waardevolle feedback op dit bericht. Speciale dank aan Stephanie Zinn voor het bewerken. 

***

De standpunten die hier naar voren worden gebracht, zijn die van het individuele personeel van AH Capital Management, LLC (“a16z”) dat wordt geciteerd en zijn niet de standpunten van a16z of haar gelieerde ondernemingen. Bepaalde informatie in dit document is verkregen uit externe bronnen, waaronder van portefeuillebedrijven van fondsen die worden beheerd door a16z. Hoewel ontleend aan bronnen die betrouwbaar worden geacht, heeft a16z dergelijke informatie niet onafhankelijk geverifieerd en doet het geen uitspraken over de huidige of blijvende nauwkeurigheid van de informatie of de geschiktheid ervan voor een bepaalde situatie. Bovendien kan deze inhoud advertenties van derden bevatten; a16z heeft dergelijke advertenties niet beoordeeld en keurt de daarin opgenomen advertentie-inhoud niet goed.

Deze inhoud is uitsluitend bedoeld voor informatieve doeleinden en mag niet worden beschouwd als juridisch, zakelijk, investerings- of belastingadvies. U dient hierover uw eigen adviseurs te raadplegen. Verwijzingen naar effecten of digitale activa zijn alleen voor illustratieve doeleinden en vormen geen beleggingsaanbeveling of aanbod om beleggingsadviesdiensten te verlenen. Bovendien is deze inhoud niet gericht op of bedoeld voor gebruik door beleggers of potentiële beleggers, en mag er in geen geval op worden vertrouwd bij het nemen van een beslissing om te beleggen in een fonds dat wordt beheerd door a16z. (Een aanbod om te beleggen in een a16z-fonds wordt alleen gedaan door middel van het onderhandse plaatsingsmemorandum, de inschrijvingsovereenkomst en andere relevante documentatie van een dergelijk fonds en moet in hun geheel worden gelezen.) Alle genoemde beleggingen of portefeuillebedrijven waarnaar wordt verwezen, of beschreven zijn niet representatief voor alle investeringen in voertuigen die door a16z worden beheerd, en er kan geen garantie worden gegeven dat de investeringen winstgevend zullen zijn of dat andere investeringen die in de toekomst worden gedaan vergelijkbare kenmerken of resultaten zullen hebben. Een lijst van investeringen die zijn gedaan door fondsen die worden beheerd door Andreessen Horowitz (met uitzondering van investeringen waarvoor de uitgevende instelling geen toestemming heeft gegeven aan a16z om openbaar te maken, evenals onaangekondigde investeringen in openbaar verhandelde digitale activa) is beschikbaar op https://a16z.com/investments /.

De grafieken en grafieken die hierin worden verstrekt, zijn uitsluitend bedoeld voor informatieve doeleinden en er mag niet op worden vertrouwd bij het nemen van een investeringsbeslissing. In het verleden behaalde resultaten zijn geen indicatie voor toekomstige resultaten. De inhoud spreekt alleen vanaf de aangegeven datum. Alle projecties, schattingen, voorspellingen, doelstellingen, vooruitzichten en/of meningen die in deze materialen worden uitgedrukt, kunnen zonder voorafgaande kennisgeving worden gewijzigd en kunnen verschillen of in strijd zijn met meningen van anderen. Zie https://a16z.com/disclosures voor aanvullende belangrijke informatie.