Hidden in Plain Sight: підступне впровадження аукціону із закритими ставками

Примітка редактора: ця частина є частиною нашої поточної серії аукціонів усіх речей для web3. Частина 1 був огляд дизайну аукціону та технічних проблем (і можливостей), характерних для розробки механізму в контексті блокчейнів без дозволу. Частина 2 був твір про очищення ринку та уникнення газових війн. Частина 3 ділиться оглядом канонічних типів аукціонів, поглядом на те, як теорія втілюється на практиці, і нашим першим впровадженням нового аукціону Vickrey із закритими ставками. 

Мережеві аукціони є одним із найцікавіших (і повсюдних) дизайнерських просторів у web3 — від продажу NFT до аукціонів застави — створюючи новий ландшафт впровадження та досліджень. Незважаючи на те, що механізми аукціону створювалися століттями та розвивалися в останні десятиліття з появою Інтернету та електронної комерції, ми лише зараз застосовуємо ці підходи до смарт-контрактів.

Ми також починаємо бачити більше дизайнів аукціонів, які є рідними для блокчейнів, зокрема наші з відкритим вихідним кодом Солідна реалізація аукціону Vickrey і кілька цікавих розробок від спільноти (включаючи пропозиції для підвищення ефективності, нов теоретичні результати, і два переможець хакатону реалізації аукціонів із закритими ставками). У нашому першому проекті ми досягли компромісу між конфіденційністю та ефективністю використання капіталу: ми використали надлишкову заставу (учасники торгів блокують більше застави, ніж вимагається їх пропозицією), щоб отримати платіж від переможця торгів, не розкриваючи точну вартість пропозиції через заставу. сума. Зберігаючи більше капіталу, ви отримуєте більше конфіденційності за потенційно вищих альтернативних витрат. Але що, якби ми могли мати конфіденційність ставок без надмірне забезпечення? 

Ця публікація представляє новий дизайн аукціону, який ми називаємо «SneakyAuction», який поєднує CREATE2 код операції та підтвердження стану, щоб гарантувати конфіденційність пропозиції, не вимагаючи від учасників торгів блокувати більше забезпечення, ніж потрібно. Ми починаємо з аналізу того, як це працює, а потім порівнюємо його з попередньою реалізацією (OverCollateralizedAuction) з точки зору вартості газу, взаємодії з користувачем і конфіденційності. Ми також додали реалізацію до нашого Аукціонний зоопарк репозиторій на GitHub, щоб ви могли розгалужувати його, створювати на ньому та стежити за тим, як ми зануримося в додаткові механізми; Тим часом докладніше про те, як це працює, і порівняння з нашим попереднім дизайном нижче. 

Як це працює: Прийняття ставок за допомогою CREATE2

Є дві вимоги, необхідні для створення «зрештою публічного» аукціону закритих ставок у мережі. По-перше, ставки мають бути приватними протягом періоду торгів, а потім розкриватися, коли він закінчиться; Схеми виявлення фіксації (де користувачі публікують хеш-зафіксовані значення, а потім розкривають свої вхідні дані пізніше) можуть відтворювати цей механізм у ланцюжку. Другою вимогою є забезпечення: заявки мають бути забезпечені забезпеченням, щоб переможець мав достатньо коштів для виконання своїх зобов’язань. 

У нашій реалізації Vickrey із надлишковою заставою потенційні покупці роблять ставки, зателефонувавши до commitBid функція, надаючи хеш-зобов'язання та заставу, яку потрібно депонувати. Такий підхід задовольняє вимоги, але має деякі недоліки. Незважаючи на те, що сама ставка прихована хешем, commitBid трансакція відкрито й одразу сигналізує про намір користувача: «Я хотів би взяти ставку на цьому аукціоні, і ось забезпечення моєї ставки». Без надмірної застави, видимість (і можливість зв’язування) обох намір та заставу покаже значення ставок. Але якщо ми зможемо приховати намір транзакції, ми зможемо досягти конфіденційності ставок, не покладаючись на надмірне забезпечення. 

Команда CREATE2 код операції, введений в ЕІП-1014 і включений у хардфорк Constantinople, дає нам спосіб зробити саме це. The CREATE та CREATE2 обидва коди операції використовуються для розгортання смарт-контрактів, але вони відрізняються тим, як обчислюються адреси розгортання. The CREATE адреса розгортання обчислюється як хеш адреси розгортача та nonce; в CREATE2 адреса розгортання, з іншого боку, обчислюється як хеш байт-коду контракту та параметрів конструктора, довільної солі та адреси розгортача (деталі).

CREATE2 часто використовується у шаблоні фабрики для розгортання контрактів за передбачуваними адресами — наприклад, the UniswapV3PoolDeployer договору використання CREATE2 щоб розгорнути кожен контракт пулу за адресою, яка є функцією пари токенів і рівня комісії. CREATE2 також можна використовувати для (повторного) розгортання оновлюваних смарт-контрактів, особливо в метаморфічний візерунок договору.

Що важливіше для нас, CREATE2 адреса розгортання може функціонувати як хеш-зобов’язання для будь-якої поведінки, визначеної вхідним байт-кодом і параметрами. Якщо параметри конструктора кодують ставку, CREATE2 адреса може служити зобов’язанням щодо пропозиції.

Крім того, сам контракт може служити сховищем — учасник торгів може надіслати ETH CREATE2 адреса сховища до розгортання контракту отримати заставу та взяти на себе зобов’язання виконати свою ставку одним простим переказом! Оскільки учасник торгів не має закритого ключа для адреси сховища, забезпечення заблоковано, доки не буде розкрито ставку, після чого розгортається контракт SneakyAuction і розблоковується сховище. 

Завдяки такому підходу трансакцію неможливо відрізнити від передачі на зовнішню адресу (EOA). Транзакція ставок прихована на видноті серед інших переказів у блокчейні. Однак одне важливе застереження: це, здавалося б, акуратне рішення також ускладнює визначення коли застава була заблокована. Для безпеки аукціону дуже важливо, щоб сховище було профінансовано до того, як будуть оголошені будь-які ставки. В іншому випадку покупець-оппортуніст міг би дочекатися самого кінця періоду розкриття, коли більшість заявок уже було розкрито, щоб вирішити, заставляти своє сховище чи ні. Нам потрібно забезпечити заставу сховищ протягом періоду торгів, не протягом періоду розкриття, використовуючи інший інструмент: державні докази.

Ретроспективна перевірка застави за допомогою державних доказів

Один із способів переконатися, що сховище було забезпечено під заставу протягом періоду ставок, – перевірити його баланс у минулому блоці. Відносно легко зробити це поза ланцюгом, зробивши запит до вузла архіву; але набагато важче виконати (без довіри) в ланцюжку. EVM BALANCE код операції читає поточний баланс адреси, але не існує такого коду операції для отримання a Минуле баланс. Насправді, єдиний код операції EVM, який забезпечує будь-який доступ до історичного стану, є BLOCKHASH, який повертає хеш одного з останніх 256 блоків. На щастя — з деякою допомогою поза ланцюгом — блокхеш працює достатньо добре для нашого випадку використання.

Хеш блоку — це хеш заголовка блоку, який включає (серед інших метаданих) державний корінь цього блоку. Корінь стану є кореневим вузлом a Меркле-Патриція триє, де кожен листовий вузол відповідає певній адресі та включає адресу' баланс в тому блоці. Ми не можемо отримати прямий доступ до цих кінцевих вузлів у ланцюжку, але ми можемо перевірити, чи вміст кінцевого вузла правильний. Фактично, eth_getProof Метод RPC підтримується Алхімія (серед інших постачальників) повертає докази Merkle, необхідні для виконання цієї перевірки (Leo Zhang надає поглиблене пояснення як це працює в контексті легких клієнтів Ethereum). Це означає, що за допомогою невеликої допомоги поза ланцюгом (один виклик RPC) учасники торгів можуть довести контракту SneakyAuction, що їх сховище було забезпечено під заставу протягом періоду торгів. 

У нашій реалізації, перша ставка представлений для аукціону, зберігає блок-хеш попереднього блоку. Ця транзакція фактично переводить аукціон із фази торгів до фази розкриття — і все наступні ставки розкритий повинен надати Merkle доказ того, що їхнє сховище було достатньо забезпечено до цього блоку (тобто до того, як було відкрито першу ставку). Зверніть увагу, що перший revealBid транзакцію в ідеалі було б надіслати через приватний пул транзакцій (наприклад, Flashbots); інакше учасник торгів, який спостерігає за mempool (побачивши значення виявленої ставки), може передати транзакцію та зробити ставку в останню секунду. 

LibBalanceProof

Щоб мінімізувати витрати для учасників тендеру, ми написали оптимізований газ бібліотека щоб перевірити докази балансу в ланцюжку, на основі якого контрактів написаний командою Aragon (яка вперше запровадила докази зберігання в ланцюжку в 2018 році), і контракти Хамді Аллама на ланцюжок Розшифровка RLP. Наша бібліотека використовує ряд низькорівневих трюків і оптимізацій, які покладаються на конкретну структуру стану trie, тому її не можна використовувати для загальних доказів Merkle-Patricia trie. Натомість це дозволяє контракту SneakyAuction перевірити минулий баланс сховища менш ніж за 30,000 XNUMX газів.

Ми також написали легку вагу Обгортка JavaScript для eth_getProof метод RPC. Отримавши адресу та номер блоку, він повертає підтвердження балансу та RLP-серіалізований заголовок блоку, який можна використовувати для виявлення ставки. 

Як це порівняти 

Давайте порівняємо наш новий підхід SneakyAuction із дизайном OverCollateralizedAuction, який ми опублікували останнім часом, за кількома ключовими параметрами, які турбують технічних дизайнерів або користувачів: витрати на газ, досвід користувача та конфіденційність. 

Витрати на газ

SneakyAuction's revealBid, endAuction та withdrawCollateral функції вимагають розгортання a SneakyVault, тому вони дорожчі за аналоги OverCollateralizedAuction. revealBid особливо дорогий, тому що він також перевіряє доказ балансу, який коштує приблизно 25,000 XNUMX газу.

Приблизні витрати газу на різні операції на основі випробувань ливарної установки

Користувач досвідом

Незважаючи на те, що обидві реалізації мають схожий загальний потік (фаза ставок, фаза відкриття, завершення аукціону), є деякі відмінності в взаємодії з користувачем. SneakyAuction має кілька незначних недоліків:

• Досвід надсилання ETH до нерозгорнутого сховища, хоча він може бути абстрагований інтерфейсом, потенційно може заплутати користувачів, які перевіряють свою транзакцію ставок у провіднику блоків.
• За допомогою OverCollateralizedAuction можна завершити аукціон достроково, якщо всі ставки були виявлені. Це неможливо в SneakyAuction, оскільки контракт не може дізнатися, скільки ставок було зроблено.
• Учасники торгів можуть оновити свою ставку та поповнити свою заставу за допомогою OverCollateralizedAuction, зателефонувавши commitBid знову. У SneakyAuction учасники торгів не можуть оновлювати, коли сховище ставок буде забезпечено.

Конфіденційність

Конфіденційність ставок OverCollateralizedAuction залежить від того, що учасники торгів вирішують заблокувати додаткову заставу (тому глядачі знають верхню межу ставки, але не точну суму). SneakyAuction, з іншого боку, отримує конфіденційність від активності в мережі, яка абсолютно не пов’язана з самим аукціоном: перекази ETH, які відбуваються протягом періоду ставок на аукціоні. 

Для простоти припустімо, що кожна ставка забезпечена за допомогою одного переказу ETH. Ми спостерігаємо, що: 

1. Транзакція застави має бути першою, коли хтось взаємодіє з адресою сховища в мережі. 
2. Ми не очікуємо, що будь-які інші транзакції стосуватимуться адреси сховища до кінця періоду ставок. 
3. Жодна транзакція не може виходити з адреси сховища (оскільки ніхто не має закритого ключа). 

Перекази ETH протягом періоду ставок на інші «недоторкані» адреси є правдоподібними ставками — іншими словами, це «шум», який приховує транзакції ставок. Щоб допомогти кількісно визначити конфіденційність SneakyAuction, ми можемо подивитися на форму цього розподілу шуму.

Ця гістограма показує розподіл щоденних переказів ETH (у головній мережі Ethereum) на недоторкані адреси з початку року на поточний момент, ілюструючи розподіл шуму протягом 24-годинного періоду ставок. Ми бачимо, що більшість транзакцій потрапляє в діапазон [0.001, 1] ETH, що означає, що аукціони з очікуваним значенням ставки в цьому діапазоні матимуть найвищу конфіденційність. З іншого боку, типовий шум може не забезпечувати достатню конфіденційність для аукціонів, де очікувана ставка перевищує 10 ETH — у цьому діапазоні рідко буває більше 100 переказів, тому аукціон, який привертає багато ставок, призведе до помітного сплеску розподілу . 

Для іншого погляду на ці дані ці діаграми розсіювання зображують перекази 15 жовтня 2022 року, накладені на ставки з двох гіпотетичних аукціонів: 

Інтуїтивно зрозуміло, що спостерігачу було б набагато легше визначити ставки з другого аукціону. На практиці ви можете використовувати такий алгоритм кластеризації, як очікування-максимізація (EM) алгоритм для передбачення транзакцій, які є ставками. 

Однак є кілька інших факторів, які можуть зробити SneakyAuction більш приватним (і, отже, більш переконливим) на практиці:

1. Довші періоди ставок: конфіденційність залежить від тривалості періоду торгів – чим довший період торгів, тим більше переказів, щоб приховати ставки. 
2. Одночасні аукціони: конфіденційність залежить від кількості одночасних аукціонів –– якщо два аукціони перебувають у фазі виставлення ставок одночасно, ставки одного аукціону створюють шум для іншого.

SneakyAuction також може отримати вигоду від надмірної застави — оскільки SneakyVault повертає будь-який надлишок ETH учаснику торгів, учасники торгів можуть вибрати надмірну заставу для додаткової конфіденційності. Тож у певному сенсі SneakyAuction забезпечує суворо більшу конфіденційність, ніж наша попередня реалізація.

Простим наслідком механізму конфіденційності SneakyAuction є те, що він приховує номер заявок протягом періоду торгів. Це перевага перед OverCollateralizedAuction, який лише приховує значення ставок — кількість зобов’язань щодо ставок, зроблених для даного аукціону, є повністю публічною (і може показати, наскільки конкурентоспроможним є аукціон).

***

У той час як наша перша реалізація аукціону із запечатаними ставками перевела функції реального світу в дизайнерські рішення в ланцюжку, наша друга розробка спирається на новий і практичний механізм використання загальнодоступного характеру блокчейнів на свою користь: запечатані пропозиції «ховаються» серед непов’язаних блокчейн діяльність.

Хоча цей новий підхід є зручним способом досягнення конфіденційності ставок без надмірної застави, він не обов’язково підходить для всіх аукціонів (наприклад, аукціонів із великою кількістю цінних ставок). Конфіденційність покращується для аукціонів, на яких очікуються менші ставки (особливо протягом тривалого періоду часу).

***
Погляди, висловлені тут, є поглядами окремих співробітників AH Capital Management, LLC («a16z»), які цитуються, і не є поглядами a16z або його філій. Певна інформація, що міститься тут, була отримана зі сторонніх джерел, зокрема від портфельних компаній фондів, якими керує a16z. Хоча отримано з джерел, які вважаються надійними, a16z не перевіряв таку інформацію незалежно та не робить жодних заяв щодо поточної чи довгострокової точності інформації чи її відповідності певній ситуації. Крім того, цей вміст може містити рекламу третіх сторін; a16z не переглядав такі оголошення та не схвалює будь-який рекламний вміст, що міститься в них.

Цей вміст надається лише в інформаційних цілях, і на нього не можна покладатися як на юридичну, ділову, інвестиційну чи податкову консультацію. Ви повинні проконсультуватися з власними радниками щодо цих питань. Посилання на будь-які цінні папери чи цифрові активи наведено лише з метою ілюстрації та не є інвестиційною рекомендацією чи пропозицією надати інвестиційні консультаційні послуги. Крім того, цей вміст не призначений для будь-яких інвесторів чи потенційних інвесторів і не призначений для використання ними, і за жодних обставин на нього не можна покладатися при прийнятті рішення інвестувати в будь-який фонд, яким керує a16z. (Пропозиція інвестувати у фонд a16z буде зроблена лише на підставі меморандуму про приватне розміщення, угоди про підписку та іншої відповідної документації будь-якого такого фонду, і її слід читати повністю.) Будь-які інвестиційні чи портфельні компанії, згадані, згадані або описані не є репрезентативними для всіх інвестицій у транспортні засоби, якими керує a16z, і не може бути гарантії, що інвестиції будуть прибутковими або що інші інвестиції, здійснені в майбутньому, матимуть подібні характеристики чи результати. Список інвестицій, здійснених фондами під управлінням Andreessen Horowitz (за винятком інвестицій, щодо яких емітент не надав дозволу a16z на оприлюднення, а також неоголошених інвестицій у публічні цифрові активи) доступний за адресою https://a16z.com/investments /.

Наведені в ньому діаграми та графіки призначені виключно для інформаційних цілей, і на них не слід покладатися під час прийняття інвестиційних рішень. Минулі результати не вказують на майбутні результати. Зміст відповідає лише вказаній даті. Будь-які прогнози, оцінки, прогнози, цілі, перспективи та/або думки, висловлені в цих матеріалах, можуть бути змінені без попередження та можуть відрізнятися або суперечити думкам, висловленим іншими. Додаткову важливу інформацію можна знайти на сторінці https://a16z.com/disclosures