Rejtett szem előtt: A zárt licit aukció alattomos, szilárd megvalósítása

A szerkesztő megjegyzése: Ez a darab a web3 minden aukcióiról szóló, folyamatban lévő sorozatunk része. rész 1 áttekintést nyújtott az aukciós tervekről, valamint a mechanizmustervezésre jellemző technikai kihívásokról (és lehetőségekről) engedély nélküli blokklánc-kontextusban. rész 2 a piac tisztázásáról és a gázháborúk elkerüléséről szólt. rész 3 megosztja a kanonikus aukciótípusok áttekintését, áttekintést az elmélet gyakorlatba való átültetésével, valamint egy újszerű, lezárt Vickrey-aukció első megvalósítását. 

A láncon belüli aukciók a web3 egyik legérdekesebb (és mindenütt jelenlévő) tervezési területei – az NFT-értékesítéstől a biztosítéki aukciókig –, amelyek a megvalósítások és a kutatások új környezetét teremtik meg. Míg az aukciós mechanizmusok tervezése évszázadok óta létezik, és az elmúlt évtizedekben az internet és az e-kereskedelem megjelenésével fejlődött, ezeket a megközelítéseket csak most alkalmazzuk az intelligens szerződéseknél.

Egyre több olyan aukciós tervvel kezdünk találkozni, amelyek a blokkláncokon alapulnak, többek között mi nyílt forráskódú Egy Vickrey-aukció szilárd megvalósítása, és számos érdekes fejlesztés a közösség részéről (beleértve javaslatok a hatékonyság javítására, új elméleti eredményeketés kettő hackathon-győztes megvalósítások zárt ajánlatú aukciók). Első tervünkben kompromisszumot kötöttünk a magánélet és a tőkehatékonyság között: túlfedezetet alkalmaztunk (az ajánlattevők több biztosítékot zárolnak, mint amennyit az ajánlatuk megkövetel) annak érdekében, hogy a nyertes ajánlattevőtől fizetést kényszerítsünk ki anélkül, hogy a biztosítékon keresztül felfednénk a pontos ajánlati értéket. összeg. Ha több tőkét zárol le, akkor több magánélethez jut, potenciálisan magasabb alternatív költség mellett. De mi van, ha a magánélet védelmét kérhettük volna nélkül túlfedezet? 

Ez a bejegyzés egy új aukciótervet mutat be, amelyet „SneakyAuction”-nak hívunk, és amely egyesíti a CREATE2 opcode és állami igazolások az ajánlatok titkosságának garantálása érdekében anélkül, hogy az ajánlattevőknek a szükségesnél több biztosítékot kellene zárolniuk. Kezdjük azzal, hogy lebontjuk, hogyan működik, majd összehasonlítjuk a korábbi megvalósításunkkal (OverCollateralizedAuction) a gázköltség, a felhasználói élmény és az adatvédelem szempontjából. A megvalósítást is hozzáadtuk a sajátunkhoz Aukciós Állatkert adattárat a GitHubon, így elágazhatod, építhetsz rá, és követheted, ahogy újabb mechanikákba merülünk; Addig is többet megtudhat a működéséről, és összehasonlíthatja korábbi tervünkkel lent. 

Hogyan működik: Ajánlattétel a CREATE2 használatával

Két feltételt kell teljesítenünk egy „végül nyilvános” zárt ajánlatú aukció létrehozásához a láncon belül. Először is, az ajánlatoknak privátnak kell lenniük az ajánlattételi időszak időtartama alatt, majd az ajánlattételi időszak végén nyilvánosságra kell hozni; A commit-reveal sémák (ahol a felhasználók közzéteszik a hash-commitált értékeket, majd később felfedik bemeneteiket) megismételhetik ezt a mechanizmust a láncon. A második követelmény a biztosíték: az ajánlatokat biztosítékkal kell alátámasztani, hogy a nyertesnek elegendő forrása legyen a kötelezettségvállalás teljesítéséhez. 

A túlfedezetű Vickrey megvalósításunkban a leendő vevők az alábbi telefonszámon tesznek ajánlatot commitBid funkciót, biztosítva a hash kötelezettségvállalást és a letétbe helyezendő biztosítékot. Ez a megközelítés kielégíti a követelményeket, de van néhány hátránya. Annak ellenére, hogy magát az ajánlatot elrejti a hash, a commitBid A tranzakció nyíltan és azonnal jelzi a felhasználó szándékát: "Szeretnék licitálni ezen az aukción, és itt van az ajánlatom fedezete." Túlfedezet nélkül, mindkettő láthatósága (és összekapcsolhatósága). A szándék és a biztosíték felfedné az ajánlati értékeket. De ha el tudjuk homályosítani egy tranzakció szándékát, akkor a túlzott fedezetre való támaszkodás nélkül is elérhetjük az ajánlatok adatvédelmét. 

A CREATE2 opcode, bevezetve EIP-1014 és szerepel a konstantinápolyi keményvillában, módot ad erre. Az CREATE és a CREATE2 A műveleti kódokat egyaránt használják az intelligens szerződések üzembe helyezésére, de különböznek a telepítési címek kiszámításának módjában. Az CREATE a telepítési cím a telepítő címének és a nonce hash-jeként kerül kiszámításra; az CREATE2 A telepítési cím ezzel szemben a szerződés bájtkódjának és a konstruktor paramétereinek, egy tetszőleges sónak és a telepítő címének hash-jeként kerül kiszámításra.részletek).

CREATE2 gyakran használják a gyári mintában a szerződések kiszámítható címekre történő telepítésére - például a UniswapV3PoolDeployer szerződéses felhasználások CREATE2 hogy minden egyes készletszerződést olyan címre telepítsen, amely a token pár és a díjszint függvénye. CREATE2 frissíthető intelligens szerződések (újra)telepítésére is használható, különösen a metamorf szerződésminta.

Ami számunkra még fontosabb, a CREATE2 A telepítési cím a bemeneti bájtkód és a paraméterek által meghatározott tetszőleges viselkedés kivonatolásaként működhet. Ha a konstruktor paraméterei ajánlatot kódolnak, a CREATE2 cím ajánlattételi kötelezettségként szolgálhat.

Sőt, maga a szerződés páncélszekrényként is szolgálhat – az ajánlattevő elküldheti az ETH-t a CREATE2 trezor címe mielőtt a szerződés megtörténik fedezetet nyújtani és elkötelezni ajánlatukat egyetlen egyszerű átutalással! Mivel az ajánlattevő nem rendelkezik a trezor címéhez tartozó privát kulccsal, a biztosíték zárolva van az ajánlat feltárásáig, ekkor a SneakyAuction szerződés feloldja és feloldja a trezort. 

Ez a megközelítés megkülönböztethetetlenné teszi a tranzakciót a külső tulajdonú címre (EOA) történő átviteltől. Az ajánlati tranzakció jól láthatóan el van rejtve a blokkláncon végzett egyéb átutalások között. Egy fontos figyelmeztetés azonban: ez a látszólag rendezett megoldás a meghatározást is megnehezíti amikor a biztosítékot zárolták. Az aukció biztonsága érdekében elengedhetetlen, hogy a trezort az ajánlatok nyilvánosságra hozatala előtt finanszírozzák. Ellenkező esetben az opportunista vevő a felfedési időszak legvégéig várhat, amikor a legtöbb ajánlat már nyilvánosságra került, hogy eldöntse, fedezi-e vagy sem. Biztosítanunk kell, hogy a trezorok biztosítékkal vannak ellátva az ajánlattételi időszak alatt, nem a feltárási időszakban, egy másik eszközzel: állítsa be a bizonyítást.

Biztosítékok visszamenőleges ellenőrzése állami bizonylatok segítségével

Egyik módja annak biztosítására, hogy egy trezort biztosítékként biztosítsanak az ajánlattételi időszak alatt, az egyenlegének ellenőrzése egy múltbeli blokknál. Ezt viszonylag egyszerű megtenni a láncon kívül egy archív csomópont lekérdezésével; de sokkal nehezebb (megbízhatatlanul) megvalósítani a láncon. Az EVM-ek BALANCE Az opcode beolvassa egy cím aktuális egyenlegét, de nem létezik ilyen műveleti kód az a múlt egyensúly. Valójában az egyetlen EVM műveleti kód, amely bármilyen történelmi állapotú hozzáférést biztosít BLOCKHASH, amely visszaadja az utolsó 256 blokk egyikének kivonatát. Szerencsére – némi láncon kívüli segítséggel – a blockhash éppen elég jól működik a mi használati esetünkben.

A blockhash a blokkfejléc hash-je, amely (egyéb metaadatok mellett) tartalmazza a állapotgyökér abból a blokkból. Az állapotgyök az a gyökércsomópontja Merkle-Patricia próbálkozás, ahol minden levélcsomópont egy adott címnek felel meg, és tartalmazza a címet" egyensúly abban a blokkban. A láncon belül nem tudjuk közvetlenül elérni ezeket a levélcsomópontokat, de ellenőrizhetjük, hogy egy levélcsomópont tartalma helyes-e. Valójában a eth_getProof által támogatott RPC módszer Aranycsinálás (más szolgáltatók mellett) visszaküldi az ellenőrzés elvégzéséhez szükséges Merkle-bizonyítékokat (Leo Zhang egy mélyreható magyarázatot hogyan működik ez az Ethereum light kliensekkel kapcsolatban). Ez azt jelenti, hogy egy kis láncon kívüli segítséggel (egyetlen RPC-hívás) az ajánlattevők igazolhatják a SneakyAuction szerződésben, hogy a páncélszekrényük biztosítékot kapott az ajánlattételi időszakban. 

Megvalósításunkban a első licit egy aukcióra felfedve tárolja az előző blokk blockhash-ét. Ez a tranzakció hatékonyan áthelyezi az aukciót az ajánlattételi szakaszból a felfedés fázisába – mindezt későbbi ajánlatok A felfedettnek Merkle-féle bizonyítékot kell szolgáltatnia arra vonatkozóan, hogy a páncélszekrényük kellően fedezett volt a blokk előtt (azaz az első licit felfedése előtt). Vegye figyelembe, hogy a első revealBid a tranzakciót ideális esetben privát tranzakciós készleten (pl. Flashbotokon) keresztül kell benyújtani; ellenkező esetben a mempoolt figyelő licitáló (látva a feltárt ajánlat értékét) előre lebonyolíthatja a tranzakciót, és az utolsó másodpercben ajánlatot tehet. 

LibBalanceProof

Az ajánlattevők költségeinek minimalizálása érdekében gázoptimalizálást írtunk könyvtár az egyenlegigazolások ellenőrzésére az arra épülő láncon szerződések írta az Aragon csapat (akik 2018-ban úttörői voltak a láncon belüli tárolási bizonyítékoknak), és Hamdi Allam szerződései a láncon keresztül RLP dekódolás. Könyvtárunk számos alacsony szintű trükköt és optimalizálást alkalmaz, amelyek az állapottrie sajátos szerkezetére támaszkodnak, így nem használható általános Merkle-Patricia trie bizonyításra. Cserébe lehetővé teszi a SneakyAuction szerződés számára, hogy 30,000 XNUMX gáznál kevesebb értékben ellenőrizze egy trezor múltbeli egyenlegét.

Írtunk egy könnyűsúlyt is JavaScript burkoló az eth_getProof RPC módszer. Adott egy cím és blokkszám, visszaadja az egyenlegellenőrző és az RLP-soros blokkfejlécet, amely felhasználható az ajánlat felfedésére. 

Hogyan viszonyul 

Hasonlítsuk össze új SneakyAuction-megközelítésünket a legutóbb kiadott OverCollateralizedAuction-tervvel, számos olyan kulcsfontosságú dimenzió mentén, amelyek a műszaki tervezőket vagy a felhasználókat érdeklik: gázköltség, felhasználói élmény és adatvédelem. 

Gázköltség

SneakyAuction revealBid, endAuctionés withdrawCollateral funkciók telepítését igénylik a SneakyVault, tehát drágábbak, mint OverCollateralizedAuction társaik. revealBid különösen drága, mert az egyensúly igazolását is igazolja, ami körülbelül 25,000 XNUMX gázba kerül.

Különböző műveletek hozzávetőleges gázköltsége, öntödei egységtesztek alapján

Felhasználói élmény

Bár a két megvalósítás hasonló általános folyamatot követ (ajánlattételi szakasz, közzétételi szakasz, az aukció vége), vannak különbségek a felhasználói élményben. A SneakyAuctionnek van néhány kisebb hátránya:

• Az a tapasztalat, hogy az ETH-t egy nem telepített tárolóba küldjük, bár a kezelőfelület ezt elvontan, megzavarhatja azokat a felhasználókat, akik blokkfelfedezőn vizsgálják ajánlati tranzakciójukat.
• Az OverCollateralizedAuction segítségével lehetőség van az aukció korai befejezésére, ha az összes ajánlatot nyilvánosságra hozták. Ez nem lehetséges a SneakyAuctionben, mert a szerződésből nem lehet tudni, hogy hány ajánlatot kötöttek.
• Az ajánlattevők frissíthetik ajánlatukat és feltölthetik fedezetüket OverCollateralizedAuction segítségével a telefonszámon. commitBid újra. A SneakyAuction szolgáltatásban az ajánlattevők nem hajthatnak végre frissítéseket, miután az ajánlat tárolóját biztosítékként biztosították.

Adatvédelem

Az OverCollateralizedAuction ajánlati adatvédelme azon múlik, hogy az ajánlattevők úgy döntenek, hogy többletbiztosítékot zárolnak (így a bámészkodók ismerik az ajánlat felső határát, de nem a pontos összeget). A SneakyAuction viszont adatvédelmet nyer a láncon belüli tevékenységből, amely teljesen független magától az aukciótól: ETH átutalások, amelyek az aukció licitálási időszakában történnek. 

Az egyszerűség kedvéért tegyük fel, hogy minden ajánlat egyetlen ETH-átutalással van biztosítva. Megfigyeljük, hogy: 

1. A biztosítéki tranzakciónak kell lennie az első alkalomnak, amikor bárki kapcsolatba lép a trezor címével a láncon. 
2. Nem számítunk arra, hogy más tranzakciók érintik a trezor címét az ajánlattételi időszak hátralévő részében. 
3. A trenzek címéről nem származhatnak tranzakciók (mivel senkinek nincs magánkulcsa). 

A licitálási időszakban az egyébként „érintetlen” címekre történő ETH-átutalások valószínű ajánlatok – más szóval, ez a „zaj”, amely elrejti az ajánlati tranzakciókat. A SneakyAuction adatvédelmének számszerűsítéséhez megtekinthetjük ennek a zajeloszlásnak az alakját.

Ez a hisztogram a napi ETH-átvitelek (az Ethereum mainneten) érintetlen címekre történő évről-napra történő megoszlását mutatja, illusztrálva a zajeloszlást egy 24 órás ajánlattételi időszakra vonatkozóan. Láthatjuk, hogy a legtöbb tranzakció a [0.001, 1] ETH tartományba esik, ami azt jelenti, hogy az ebben a tartományban várható ajánlati értékkel rendelkező aukciók rendelkeznek a legerősebb adatvédelemmel. Másrészt előfordulhat, hogy a tipikus zaj nem biztosít kellő adatvédelmet az olyan aukciókon, ahol a várt ajánlat meghaladja a 10 ETH-t – ritkán van 100-nál több átutalás ebben a tartományban, így egy sok ajánlatot vonzó aukció szembetűnő kiugrást okozna az elosztásban. . 

Az adatok másik szemszögéből ezek a szóródási diagramok a 15. október 2022-i átutalásokat mutatják be két feltételezett aukció ajánlataival: 

Intuitív módon a megfigyelő számára sokkal könnyebb lenne azonosítani a második aukció ajánlatait. A gyakorlatban használhat egy klaszterezési algoritmust, például a elvárás-maximalizálás (EM) algoritmus annak előrejelzésére, hogy mely tranzakciók ajánlatok. 

Van azonban néhány egyéb tényező is, amelyek a SneakyAuctiont privátabbá (és ezáltal meggyőzőbbé) tehetik a gyakorlatban:

1. Hosszabb ajánlattételi időszakok: Adatvédelmi skálák az ajánlattételi időszak hosszával – – minél hosszabb a licitálási időszak, annál több átutalással lehet elrejteni az ajánlatokat. 
2. Párhuzamos aukciók: Adatvédelmi skálák az egyidejű aukciók számával – – ha két aukció van egyidejűleg licitálási fázisban, az egyik aukció licitjei a másik számára zajt keltenek.

A SneakyAuction is profitálhat a túlfedezetből – mivel a SneakyVault minden többlet ETH-t visszaad az ajánlattevőnek, az ajánlattevők dönthetnek úgy, hogy túlfedezetet nyújtanak a további adatvédelem érdekében. Tehát bizonyos értelemben a SneakyAuction szigorúan erősebb adatvédelmet biztosít, mint a korábbi megvalósításunk.

A SneakyAuction adatvédelmi mechanizmusának egyszerű következménye, hogy elrejti a szám az ajánlattételi időszak alatti ajánlatokból. Ez előnyt jelent az OverCollateralizedAuctionnel szemben, amely csak az ajánlati értékeket takarja el – az adott aukcióra tett ajánlattételi kötelezettségvállalások száma teljesen nyilvános (és elárulhatja az aukció versenyképességét).

***

Míg a lezárt ajánlattételű aukció első megvalósítása a valós világ jellemzőit láncon belüli tervezési döntésekké alakította át, a második tervünk egy újszerű és praktikus mechanizmusra támaszkodik, hogy a blokkláncok nyilvános jellegét kihasználja: a lezárt ajánlatok „elrejtőznek” a függetlenek között. blokklánc tevékenység.

Bár ez az új megközelítés kényelmes módja annak, hogy túlfedezet nélkül biztosítsa az ajánlatok adatvédelmét, nem feltétlenül alkalmas minden aukcióra (például sok nagy értékű ajánlatot tartalmazó aukciókra). Az adatvédelem javul az olyan aukciók esetében, amelyek kisebb ajánlatokat várnak (és különösen hosszabb ideig).

***
Az itt kifejtett nézetek az AH Capital Management, LLC („a16z”) egyes alkalmazottainak nézetei, és nem az a16z vagy leányvállalatai nézetei. Az itt található bizonyos információk harmadik féltől származnak, többek között az a16z által kezelt alapok portfólióvállalataitól. Noha megbízhatónak vélt forrásokból származnak, az a16z nem ellenőrizte önállóan ezeket az információkat, és nem tesz kijelentést az információk aktuális vagy tartós pontosságáról, illetve annak egy adott helyzetre való megfelelőségéről. Ezenkívül ez a tartalom harmadik féltől származó hirdetéseket is tartalmazhat; az a16z nem vizsgálta át az ilyen hirdetéseket, és nem támogatja az abban található reklámtartalmat.

Ez a tartalom csak tájékoztatási célokat szolgál, és nem támaszkodhat rá jogi, üzleti, befektetési vagy adótanácsadásként. Ezekkel a kérdésekkel kapcsolatban konzultáljon saját tanácsadójával. Bármely értékpapírra vagy digitális eszközre történő hivatkozások csak illusztrációs célt szolgálnak, és nem minősülnek befektetési ajánlásnak vagy ajánlatnak befektetési tanácsadási szolgáltatások nyújtására. Ezen túlmenően ez a tartalom nem befektetőknek vagy leendő befektetőknek szól, és nem is szánható felhasználásra, és semmilyen körülmények között nem támaszkodhat rá az a16z által kezelt alapokba történő befektetésről szóló döntés meghozatalakor. (A16z alapba történő befektetésre vonatkozó ajánlatot csak az ilyen alap zártkörű kibocsátási memoranduma, jegyzési szerződése és egyéb vonatkozó dokumentációja tesz, és azokat teljes egészében el kell olvasni.) Minden említett, hivatkozott befektetés vagy portfóliótársaság, ill. A leírtak nem reprezentatívak az a16z által kezelt járművekbe történő összes befektetésre, és nem garantálható, hogy a befektetések nyereségesek lesznek, vagy a jövőben végrehajtott egyéb beruházások hasonló tulajdonságokkal vagy eredménnyel járnak. Az Andreessen Horowitz által kezelt alapok befektetéseinek listája (kivéve azokat a befektetéseket, amelyek esetében a kibocsátó nem adott engedélyt az a16z számára a nyilvánosságra hozatalra, valamint a nyilvánosan forgalmazott digitális eszközökbe történő be nem jelentett befektetéseket) a https://a16z.com/investments oldalon érhető el. /.

A benne található diagramok és grafikonok kizárólag tájékoztató jellegűek, és nem szabad rájuk hagyatkozni befektetési döntések meghozatalakor. A múltbeli teljesítmény nem jelzi a jövőbeli eredményeket. A tartalom csak a feltüntetett dátum szerint beszél. Az ezekben az anyagokban megfogalmazott előrejelzések, becslések, előrejelzések, célok, kilátások és/vagy vélemények előzetes értesítés nélkül változhatnak, és eltérhetnek mások véleményétől, vagy ellentétesek lehetnek azokkal. További fontos információkért látogasson el a https://a16z.com/disclosures oldalra