Ukryty na widoku: podstępna solidna implementacja aukcji z zapieczętowaną ofertą

Uwaga edytora: Ten artykuł jest częścią naszej ciągłej serii poświęconej wszystkim aukcjom dotyczącym web3. Część 1 był przeglądem projektów aukcji oraz wyzwań technicznych (i możliwości) specyficznych dla projektowania mechanizmów w kontekście blockchainów bez pozwolenia. Część 2 był artykuł o oczyszczeniu rynku i unikaniu wojen gazowych. Część 3 dzieli się przeglądem typów aukcji kanonicznych, spojrzeniem na to, jak teoria przekłada się na praktykę, oraz naszą pierwszą implementacją nowatorskiej aukcji Vickrey z zapieczętowaną ofertą. 

Aukcje on-chain to jedna z najciekawszych (i wszechobecnych) przestrzeni projektowych w web3 — od sprzedaży NFT po aukcje zabezpieczeń — tworząc nowy krajobraz wdrożeń i badań. Chociaż projektowanie mechanizmów aukcyjnych istnieje od wieków i ewoluowało w ostatnich dziesięcioleciach wraz z pojawieniem się sieci i handlu elektronicznego, dopiero teraz stosujemy te podejścia do inteligentnych kontraktów.

Zaczynamy również widzieć więcej projektów aukcji, które są natywne dla blockchainów, w tym ludzkiej, open source Solidna implementacja aukcji Vickrey i kilka interesujących zmian ze strony społeczności (m.in sugestie dla poprawy wydajności, nowy wyniki teoretyczne, i dwa zwycięzca hackathonu wdrożenia aukcji zamkniętych). W naszym pierwszym projekcie dokonaliśmy kompromisu między prywatnością a efektywnością kapitałową: zastosowaliśmy nadzabezpieczenie (oferenci blokują więcej zabezpieczeń niż wymaga tego ich oferta) w celu wyegzekwowania płatności od zwycięskiego oferenta, bez ujawniania dokładnych wartości oferty poprzez zabezpieczenie ilość. Blokując większy kapitał, zyskujesz więcej prywatności przy potencjalnie wyższych kosztach alternatywnych. Ale co by było, gdybyśmy mogli mieć prywatność podczas składania ofert bez nadzabezpieczenie? 

Ten post przedstawia nowy projekt aukcji, który nazywamy „SneakyAuction”, który łączy w sobie CREATE2 opcode i stanowe dowody, aby zagwarantować prywatność ofert bez wymagania od oferentów blokowania większej ilości zabezpieczeń niż jest to wymagane. Zaczynamy od wyjaśnienia, jak to działa, a następnie porównujemy je z naszą poprzednią implementacją (OverCollateralizedAuction) pod względem kosztów gazu, doświadczenia użytkownika i prywatności. Dodaliśmy również implementację do naszego Zoo aukcyjne repozytorium na GitHub, abyś mógł je rozwidlić, budować na nim i śledzić, jak zagłębiamy się w więcej mechaniki; w międzyczasie więcej o tym, jak to działa i porównuje się z naszym poprzednim projektem poniżej. 

Jak to działa: Składanie ofert za pomocą CREATE2

Istnieją dwa wymagania, których potrzebujemy, aby stworzyć „ostatecznie publiczną” aukcję z zapieczętowaną ofertą w łańcuchu. Po pierwsze, oferty muszą być prywatne przez cały okres licytacji, a następnie ujawnione po jej zakończeniu; schematy zatwierdzania-ujawniania (w których użytkownicy publikują zatwierdzone wartości skrótu, a następnie ujawniają swoje dane wejściowe później) mogą replikować ten mechanizm w łańcuchu. Drugim wymogiem jest zabezpieczenie: oferty muszą być poparte zabezpieczeniem, aby zapewnić, że zwycięzca ma wystarczające środki na wypełnienie swojego zobowiązania. 

W naszej implementacji Vickrey z nadmiernym zabezpieczeniem potencjalni nabywcy składają oferty, dzwoniąc pod numer commitBid funkcję, dostarczając zobowiązanie haszujące i zabezpieczenie, które ma zostać zdeponowane. Takie podejście spełnia wymagania, ale ma pewne wady. Mimo że sama oferta jest ukryta przez skrót, the commitBid transakcja otwarcie i natychmiast sygnalizuje zamiar użytkownika: „Chciałbym licytować na tej aukcji, a oto zabezpieczenie mojej oferty”. Bez nadzabezpieczenia widoczność (i możliwość powiązania) obu zamiar i dodatkowy ujawni wartości stawek. Ale jeśli uda nam się zaciemnić intencje transakcji, być może uda nam się osiągnąć prywatność ofert bez polegania na nadmiernym zabezpieczeniu. 

Połączenia CREATE2 opcode, wprowadzony w EIP-1014 i zawarte w hard forku Konstantynopola, daje nam sposób na zrobienie tego. The CREATE i CREATE2 oba kody operacyjne są używane do wdrażania inteligentnych kontraktów, ale różnią się sposobem obliczania adresów wdrażania. The CREATE adres wdrożenia jest obliczany jako skrót adresu wdrażającego i wartości jednorazowej; the CREATE2 z drugiej strony adres wdrożenia jest obliczany jako skrót kodu bajtowego kontraktu i parametrów konstruktora, dowolnej soli i adresu wdrażającego (detale).

CREATE2 jest często używany we wzorcu fabrycznym do wdrażania kontraktów pod przewidywalnymi adresami — na przykład Narzędzie UniswapV3PoolDeployer zastosowania kontraktowe CREATE2 wdrożyć każdą umowę puli na adres, który jest funkcją pary tokenów i poziomu opłat. CREATE2 może być również wykorzystany do (ponownego) wdrożenia inteligentnych kontraktów, które można aktualizować, w szczególności w metamorficzny wzór umowy.

Co ważniejsze dla nas, CREATE2 adres wdrożenia może działać jako zobowiązanie skrótu do dowolnego zachowania zdefiniowanego przez wejściowy kod bajtowy i parametry. Jeśli parametry konstruktora kodują ofertę, metoda CREATE2 adres może służyć jako zobowiązanie do złożenia oferty.

Co więcej, sama umowa może służyć jako skarbiec — oferent może wysłać ETH do CREATE2 adres skarbca przed wdrożeniem kontraktu aby zabezpieczyć i zobowiązać się do ich oferty w jednym prostym przelewie! Ponieważ licytant nie ma klucza prywatnego do adresu skarbca, zabezpieczenie jest zablokowane do momentu ujawnienia oferty, kiedy to umowa SneakyAuction wdraża i odblokowuje skarbiec. 

Takie podejście sprawia, że ​​transakcja jest nie do odróżnienia od przeniesienia na adres będący własnością zewnętrzną (EOA). Transakcja kupna jest ukryta na widoku, między innymi przelewami na blockchainie. Jednak jedno ważne zastrzeżenie: to pozornie uporządkowane rozwiązanie również utrudnia ustalenie jeśli chodzi o komunikację i motywację zabezpieczenie zostało zablokowane. Dla bezpieczeństwa aukcji ważne jest, aby skarbiec został sfinansowany przed ujawnieniem jakichkolwiek ofert. W przeciwnym razie oportunistyczny nabywca mógłby czekać do samego końca okresu ujawniania, w którym to momencie większość ofert została już ujawniona, aby zdecydować, czy zabezpieczyć swój skarbiec. Musimy zapewnić zabezpieczenie skarbców w okresie licytacji, nie w okresie ujawniania, używając innego narzędzia: dowodów państwowych.

Weryfikacja zabezpieczenia z mocą wsteczną przy użyciu dowodów państwowych

Jednym ze sposobów upewnienia się, że skarbiec był zabezpieczony w okresie licytacji, jest sprawdzenie jego salda w poprzednim bloku. Stosunkowo łatwo jest to zrobić poza łańcuchem, wysyłając zapytanie do węzła archiwum; ale znacznie trudniejsze do wykonania (bez zaufania) w łańcuchu. EVM BALANCE opcode odczytuje bieżące saldo adresu, ale nie istnieje taki opcode, który mógłby pobrać a Przeszłość saldo. W rzeczywistości jedynym kodem operacyjnym EVM, który zapewnia jakikolwiek dostęp do stanu historycznego, jest BLOCKHASH, która zwraca wartość skrótu jednego z ostatnich 256 bloków. Na szczęście — z pewną pomocą poza łańcuchem — blockhash działa wystarczająco dobrze w naszym przypadku użycia.

Blockhash to skrót nagłówka bloku, który zawiera (między innymi metadane) korzeń stanu tamtego bloku. Korzeń stanu jest węzłem głównym elementu a Merkle-Patricia Trie, gdzie każdy węzeł liścia odpowiada określonemu adresowi i zawiera adres” równoważyć w tamtym bloku. Nie możemy bezpośrednio uzyskać dostępu do tych węzłów liścia w łańcuchu, ale możemy zweryfikować, czy zawartość węzła liścia jest poprawna. W rzeczywistości eth_getProof Metoda RPC obsługiwana przez Alchemia (między innymi dostawcami) zwraca dowody Merkle potrzebne do przeprowadzenia tej weryfikacji (Leo Zhang zapewnia szczegółowe wyjaśnienie jak to działa w kontekście lekkich klientów Ethereum). Oznacza to, że przy odrobinie pomocy poza łańcuchem (pojedyncze wywołanie RPC) licytujący mogą udowodnić kontraktowi SneakyAuction, że ich skarbiec był zabezpieczony w okresie licytacji. 

W naszej realizacji tzw pierwsza oferta ujawnione na aukcję przechowuje blokhasz poprzedniego bloku. Ta transakcja skutecznie przenosi aukcję z fazy licytacji do fazy ujawniania — wszystko kolejne oferty ujawnione muszą przedstawić dowód Merkle, że ich skarbiec był wystarczająco zabezpieczony przed tą blokadą (tj. przed ujawnieniem pierwszej oferty). Zauważ, że drugim revealBid najlepiej byłoby, gdyby transakcja została przesłana za pośrednictwem prywatnej puli transakcji (np. Flashbots); w przeciwnym razie licytant obserwujący mempool (widząc wartość ujawnionej oferty) mógłby przeprowadzić transakcję z wyprzedzeniem i złożyć ofertę w ostatniej chwili. 

LibBalanceProof

Aby zminimalizować koszty dla oferentów, napisaliśmy wersję zoptymalizowaną pod kątem gazu biblioteka aby zweryfikować dowody równowagi w łańcuchu, który opiera się na umowy napisany przez zespół Aragon (który w 2018 r. dekodowanie RLP. Nasza biblioteka wykorzystuje szereg sztuczek i optymalizacji niskiego poziomu, które opierają się na szczególnej strukturze state trie, więc nie można jej używać do ogólnych dowodów trie Merkle-Patricia. W zamian pozwala kontraktowi SneakyAuction zweryfikować przeszłe saldo skarbca za mniej niż 30,000 XNUMX gazu.

Napisaliśmy też lekki Opakowanie JavaScript dla eth_getProof Metoda RPC. Biorąc pod uwagę adres i numer bloku, zwraca dowód salda i nagłówek bloku z serializacją RLP, którego można użyć do ujawnienia oferty. 

Jak to się porównuje 

Porównajmy nasze nowe podejście do SneakyAuction z ostatnio wydanym projektem OverCollateralizedAuction, uwzględniając kilka kluczowych aspektów, na których zwracają uwagę projektanci techniczni lub użytkownicy: koszty gazu, wrażenia użytkownika i prywatność. 

Koszty gazu

SneakyAuction's revealBid, endAuction, withdrawCollateral funkcje wymagają wdrożenia a SneakyVault, więc są droższe niż ich odpowiedniki w OverCollateralizedAuction. revealBid jest szczególnie kosztowny, ponieważ weryfikuje również dowód równowagi, który kosztuje około 25,000 XNUMX gazu.

Przybliżone koszty gazu dla różnych operacji na podstawie testów jednostkowych odlewni

Doświadczenie użytkownika

Chociaż obie implementacje przebiegają według podobnego ogólnego przebiegu (faza licytacji, faza ujawniania, zakończenie aukcji), istnieją pewne różnice w doświadczeniach użytkowników. SneakyAuction ma kilka drobnych wad:

• Doświadczenie związane z wysyłaniem ETH do niewdrożonego skarbca, choć może zostać pobrane przez interfejs użytkownika, może być mylące dla użytkowników, którzy sprawdzają swoją transakcję przetargową w eksploratorze bloków.
• Dzięki OverCollateralizedAuction możliwe jest wcześniejsze zakończenie aukcji, jeśli wszystkie oferty zostały ujawnione. Nie jest to możliwe w SneakyAuction, ponieważ umowa nie ma możliwości sprawdzenia, ile ofert zostało złożonych.
• Oferenci mogą aktualizować swoje oferty i uzupełniać swoje zabezpieczenia za pomocą OverCollateralizedAuction, dzwoniąc commitBid ponownie. W SneakyAuction licytujący nie mogą dokonywać aktualizacji, gdy skarbiec oferty zostanie zabezpieczony.

Prywatności

Prywatność oferty OverCollateralizedAuction zależy od tego, czy licytujący decydują się na zablokowanie dodatkowego zabezpieczenia (aby obserwatorzy znali górną granicę oferty, ale nie jej dokładną kwotę). SneakyAuction, z drugiej strony, czerpie prywatność z działań w łańcuchu, które są całkowicie niezwiązane z samą aukcją: Transfery ETH, które mają miejsce w okresie licytacji aukcji. 

Dla uproszczenia załóżmy, że każda oferta jest zabezpieczona pojedynczym przelewem ETH. Obserwujemy, że: 

1. Transakcja zabezpieczenia powinna być pierwszą interakcją dowolnej osoby z adresem skarbca w łańcuchu. 
2. Nie spodziewamy się, aby jakiekolwiek inne transakcje dotykały adresu Vault przez resztę okresu licytacji. 
3. Żadne transakcje nie mogą pochodzić z adresu skarbca (ponieważ nikt nie ma klucza prywatnego). 

Transfery ETH w okresie licytacji na „nietknięte” adresy są wiarygodnymi ofertami — innymi słowy, są „szumem”, który ukrywa transakcje licytacji. Aby pomóc w ilościowym określeniu prywatności SneakyAuction, możemy przyjrzeć się kształtowi tego rozkładu szumów.

Ten histogram pokazuje roczny rozkład dziennych transferów ETH (w sieci głównej Ethereum) na nietknięte adresy, ilustrując rozkład szumu w 24-godzinnym okresie licytacji. Widzimy, że większość transakcji mieści się w zakresie [0.001, 1] ETH, co oznacza, że ​​aukcje z oczekiwaną wartością oferty w tym zakresie miałyby największą prywatność. Z drugiej strony typowy hałas może nie zapewniać wystarczającej prywatności w przypadku aukcji, w których oczekiwana oferta jest większa niż 10 ETH — rzadko zdarza się więcej niż 100 transferów w tym zakresie, więc aukcja przyciągająca wiele ofert spowodowałaby wyraźny skok w dystrybucji . 

Aby spojrzeć na te dane z innej perspektywy, te wykresy punktowe przedstawiają transfery z 15 października 2022 r., na które nakładają się oferty z dwóch hipotetycznych aukcji: 

Intuicyjnie obserwatorowi znacznie łatwiej byłoby zidentyfikować oferty z drugiej aukcji. W praktyce można użyć algorytmu grupowania, takiego jak maksymalizacja oczekiwań (EM) do przewidywania, które transakcje są ofertami. 

Istnieje jednak kilka innych czynników, które w praktyce mogą sprawić, że SneakyAuction będzie bardziej prywatna (a przez to bardziej przekonująca):

1. Dłuższe okresy licytacji: Prywatność skaluje się z długością okresu licytacji – im dłuższy okres licytacji, tym więcej jest transferów, aby ukryć oferty. 
2. Równoczesne aukcje: skale prywatności z liczbą jednoczesnych aukcji –– jeśli dwie aukcje są w fazie licytacji w tym samym czasie, oferty jednej aukcji stanowią szum dla drugiej.

SneakyAuction może również skorzystać z dodatkowego zabezpieczenia — ponieważ SneakyVault zwraca oferentowi nadwyżkę ETH, licytujący mogą zdecydować się na dodatkowe zabezpieczenie w celu zachowania większej prywatności. W pewnym sensie SneakyAuction zapewnia ściślejszą prywatność niż nasza poprzednia implementacja.

Prostym następstwem mechanizmu prywatności SneakyAuction jest to, że ukrywa on numer ofert w okresie składania ofert. Jest to przewaga nad OverCollateralizedAuction, która ukrywa tylko wartości ofert — liczba zobowiązań do składania ofert, które zostały złożone dla danej aukcji, jest w pełni jawna (i może zdradzić, jak bardzo konkurencyjna jest aukcja).

***

Podczas gdy nasze pierwsze wdrożenie aukcji z zapieczętowaną ofertą przełożyło rzeczywiste funkcje na decyzje projektowe w łańcuchu, nasz drugi projekt opiera się na nowatorskim i praktycznym mechanizmie wykorzystania publicznego charakteru łańcuchów bloków na swoją korzyść: zapieczętowane oferty „ukrywają się” wśród niepowiązanych aktywność blockchaina.

Chociaż to nowe podejście jest wygodnym sposobem na uzyskanie prywatności ofert bez nadmiernego zabezpieczenia, niekoniecznie jest odpowiednie dla wszystkich aukcji (na przykład aukcji z wieloma ofertami o wysokiej wartości). Prywatność poprawia się w przypadku aukcji, które oczekują niższych stawek (a zwłaszcza w dłuższym okresie).

***
Wyrażone tutaj poglądy są poglądami poszczególnych cytowanych pracowników AH Capital Management, LLC („a16z”) i nie są poglądami a16z ani jej podmiotów stowarzyszonych. Niektóre informacje w nim zawarte zostały pozyskane ze źródeł zewnętrznych, w tym od spółek portfelowych funduszy zarządzanych przez a16z. Chociaż pochodzą ze źródeł uważanych za wiarygodne, a16z nie zweryfikowało niezależnie takich informacji i nie składa żadnych oświadczeń dotyczących aktualnej lub trwałej dokładności informacji lub ich adekwatności w danej sytuacji. Ponadto treści te mogą zawierać reklamy osób trzecich; a16z nie przeglądał takich reklam i nie popiera żadnych zawartych w nich treści reklamowych.

Te treści są udostępniane wyłącznie w celach informacyjnych i nie należy ich traktować jako porady prawnej, biznesowej, inwestycyjnej lub podatkowej. Powinieneś skonsultować się w tych sprawach z własnymi doradcami. Odniesienia do jakichkolwiek papierów wartościowych lub aktywów cyfrowych służą wyłącznie celom ilustracyjnym i nie stanowią rekomendacji inwestycyjnej ani oferty świadczenia usług doradztwa inwestycyjnego. Ponadto treść ta nie jest skierowana ani przeznaczona do użytku przez jakichkolwiek inwestorów lub potencjalnych inwestorów iw żadnym wypadku nie można na nich polegać przy podejmowaniu decyzji o zainwestowaniu w jakikolwiek fundusz zarządzany przez a16z. (Oferta inwestycji w fundusz a16z zostanie złożona wyłącznie na podstawie memorandum dotyczącego oferty prywatnej, umowy subskrypcyjnej i innej odpowiedniej dokumentacji takiego funduszu i należy ją przeczytać w całości.) Wszelkie inwestycje lub spółki portfelowe wymienione, wymienione lub opisane nie są reprezentatywne dla wszystkich inwestycji w pojazdy zarządzane przez a16z i nie można zapewnić, że inwestycje będą opłacalne lub że inne inwestycje dokonane w przyszłości będą miały podobne cechy lub wyniki. Lista inwestycji dokonanych przez fundusze zarządzane przez Andreessena Horowitza (z wyłączeniem inwestycji, w przypadku których emitent nie wyraził zgody na publiczne ujawnienie przez a16z oraz niezapowiedzianych inwestycji w aktywa cyfrowe będące w obrocie publicznym) jest dostępna pod adresem https://a16z.com/investments /.

Wykresy i wykresy zamieszczone w niniejszym dokumencie służą wyłącznie celom informacyjnym i nie należy na nich polegać przy podejmowaniu jakichkolwiek decyzji inwestycyjnych. Wyniki osiągnięte w przeszłości nie wskazują na przyszłe wyniki. Treść mówi dopiero od wskazanej daty. Wszelkie prognozy, szacunki, prognozy, cele, perspektywy i/lub opinie wyrażone w tych materiałach mogą ulec zmianie bez powiadomienia i mogą się różnić lub być sprzeczne z opiniami wyrażanymi przez innych. Dodatkowe ważne informacje można znaleźć na stronie https://a16z.com/disclosures