Виталик: Как централизованные биржи могут подтвердить наличие средств?

Автор：Vitalik

Составитель：Дун Имин, ChainCatcher

Каждый раз, когда происходит взрыв важной централизованной биржи, возникает распространенный вопрос: можем ли мы использовать криптографические технологии для решения этой проблемы. Биржи могут создать криптографические доказательства, показывающие, что у них на счетах достаточно средств для покрытия их обязательств перед пользователями, а не полагаться только на "законные" методы, такие как лицензии от правительства, аудиторы и проверка личных данных управляющих биржей.

Биржи могут создать систему, в которой невозможно вывести средства клиентов без их согласия. Потенциально мы можем исследовать весь спектр между "не делай плохого" амбициозных добрых людей CEX и "не могу сделать плохого", но сейчас неэффективных и нарушающих конфиденциальность DEX на блокчейне. Эта статья углубится в историю попыток сделать торговлю более доверенной, ограничения этих технологий и некоторые обновленные и более мощные идеи, основанные на ZK-SNARKs и других передовых технологиях.

Баланс и Merkle дерево : старомодное доказательство платежеспособности

Биржи начали пытаться использовать криптографические методы для доказательства того, что они не обманывают своих пользователей, еще очень давно. В 2011 году крупнейшая на тот момент биржа биткойнов MtGox доказала наличие средств, отправив транзакцию, в которой 424242 BTC были переведены на заранее объявленный адрес. В 2013 году начали обсуждать другую сторону проблемы: доказательство общего объема клиентских депозитов. Если вы докажете, что сумма депозитов клиентов равна X ("доказательство обязательств"), и докажете право собственности на приватный ключ X монет ("доказательство активов"), то у вас есть доказательство платежеспособности: вы доказали, что у биржи есть средства для возврата всем вкладчикам.

Самый простой способ доказать депозиты — это просто опубликовать список пар (имя пользователя, баланс). Каждый пользователь может проверить, включен ли его баланс в список, и любой может проверить полный список, чтобы убедиться, что (i) каждый баланс неотрицателен, (ii) общая сумма равна сумме обязательств. Конечно, это нарушает конфиденциальность, поэтому мы можем немного изменить схему: опубликовать список пар (хэш(имя пользователя, соль), баланс) и отправить каждому пользователю их соль в частном порядке. Но даже в этом случае это приведет к утечке баланса и утечке паттернов изменения баланса. Желание защитить конфиденциальность привело нас к следующему изобретению: Merkle дерево.

Зеленый: узел Чарли. Синий: узел Дэвида, который также будет получен Чарли как часть его доказательства. Желтый: корневой узел, который публично демонстрируется всем.

Технология Merkle tree заключается в том, чтобы поместить таблицу балансов клиентов в Merkle sum tree. В Merkle sum tree каждый узел представляет собой пару (баланс, хэш). Листовые узлы представляют собой отдельные балансы клиентов и хэшированные значения имен пользователей с солью. В каждом верхнем узле баланс является суммой двух нижних балансов, а хэш — хэшами двух нижних узлов. Доказательство Merkle sum, как и доказательство Merkle, представляет собой "ветвь" дерева, состоящую из сестринских узлов на пути от листа к корню.

Биржа отправит каждому пользователю доказательство Merkle sum их баланса, чтобы подтвердить его. Затем пользователь получит гарантию, что его баланс правильно включен в общую сумму. Простой пример кода можно найти ++здесь++**.

Утечка конфиденциальности в этом дизайне значительно ниже, чем в полностью открытом списке, и может быть дополнительно снижена путем перемешивания ветвей каждый раз, когда публикуется корень, но некоторые утечки конфиденциальности все же существуют. Чарли может узнать, что чей-то баланс составляет 164 ETH, что два пользователя имеют в сумме 70 ETH и так далее. Атакующий, контролирующий множество аккаунтов, все еще может получить много информации о пользователях биржи.

Одним из важных нюансов этого решения является возможность отрицательного баланса: что делать, если у биржи есть 1390 ETH клиентских балансов, но только 890 ETH резервов, и они пытаются компенсировать разницу, добавив баланс -500 ETH под каким-то фиктивным аккаунтом в дереве? Оказалось, что такая возможность не разрушает схему, хотя именно поэтому нам особенно нужны Merkle sum деревья, а не обычные Merkle деревья. Предположим, что Генри — это фиктивный аккаунт, контролируемый биржей, и биржа помещает туда -500 ETH.

Проверка доказательства Греты провалится: биржа будет вынуждена предоставить ей узел -500 ETH Генри, и она отклонит этот узел, потому что он недействителен. Проверки Эвы и Фреда также провалятся, потому что общая сумма ETH на промежуточном узле над Генри составляет -230, что также недействительно! Чтобы избежать кражи, биржа должна надеяться, что никто не проверит их доказательства баланса в правой половине дерева.

Если биржа сможет идентифицировать пользователей с балансом 500 ETH, в которых они уверены, что эти пользователи либо не будут беспокоиться о проверке доказательства, либо не будут верить, когда они жалуются, что никогда не получили доказательства, то они будут уверены избежать наказания за кражу. Однако биржа также может исключить этих пользователей из дерева, чтобы достичь того же эффекта.

Таким образом, если просто для достижения цели доказательства обязательств, технология Merkle tree в основном так же хороша, как и схема доказательства обязательств (proof-of-liabilities). Но ее свойства конфиденциальности все еще не идеальны. Вы можете использовать Merkle tree более изящным способом, например, ++сделав каждую сатоши или wei отдельным листом++, но в конечном итоге с более современными технологиями есть лучшие способы сделать это.

Улучшение конфиденциальности и надежности с помощью ZK-SNARKs

ZK-SNARKs — это мощная технология. Роль ZK-SNARKs в криптографии может быть такой же, как роль трансформеров в искусственном интеллекте: это такая мощная универсальная технология, что она полностью затмит множество проблем, возникающих в специфических приложениях, разработанных десятилетия назад. Поэтому, конечно, мы можем использовать ZK-SNARKs, чтобы значительно упростить и улучшить конфиденциальность в протоколах доказательства обязательств.

Самое простое, что мы можем сделать, это поместить все депозиты пользователей в одно Merkle дерево (или, что проще, ++KZG обязательство++) и использовать ZK-SNARK для доказательства того, что все балансы в этом дереве неотрицательны и в сумме равны какому-то заявленному значению. Если мы добавим уровень хэширования для конфиденциальности, Merkle ветви (или KZG доказательства) для каждого пользователя не будут раскрывать балансы других пользователей.

Использование KZG обязательств — это один из способов избежать утечек конфиденциальности, поскольку не требуется предоставлять "сестринские узлы" в качестве доказательства, простое ZK-SNARK может быть использовано для доказательства суммы балансов и того, что каждый баланс неотрицателен.

Мы можем использовать специальное ZK-SNARK для доказательства суммы и неотрицательности балансов в вышеупомянутом KZG. Вот простой пример, как это сделать. Мы вводим вспомогательный многочлен, который "устанавливает бит каждого баланса" (для примера, мы предполагаем, что балансы находятся в пределах), и каждые 16 позиций отслеживает запущенную сумму с смещением, так что только когда фактическая сумма совпадает с заявленной, ее сумма равна нулю. Если z — это корень единицы -128 степени, мы можем доказать следующее равенство.

Первое значение для корректной настройки — это 0 0 0 0 0 0 0 0 0 0 1 2 5 10 20 -165 0 0 0 0 0 0 0 0 1 3 6 12 25 50 -300 …

Что касается того, как преобразовать такое уравнение в проверку многочлена, а затем в ZK-SNARK, смотрите мое дальнейшее объяснение в ++статье о ZK-SNARK++ ++здесь++ и ++здесь++. Это не оптимальный протокол, но он действительно показывает, что в наши дни такие типы криптографических доказательств не так уж странны!

С несколькими дополнительными формулами такая система ограничений может адаптироваться к более сложным условиям. Например, в системе маржинальной торговли допустимо, чтобы у отдельных пользователей были отрицательные балансы, при условии, что у них достаточно других активов для покрытия средств с некоторыми залоговыми требованиями. SNARK может быть использован для доказательства этого более сложного ограничения, успокаивая пользователей, что биржа не подвергнет их средства риску через ++скрытые++ ++освобождения++ ++других пользователей++.

В более отдаленном будущем такое ZK доказательство обязательств может быть использовано не только для депозитов клиентов на бирже, но и для более широких кредитов. Каждый раз, когда кто-то берет кредит, он будет помещать запись в многочлен или дерево, включающее этот кредит, корень которого будет опубликован в блокчейне. Это позволит любому, кто ищет кредит, предоставить кредитору ZK доказательство того, что он еще не взял слишком много других кредитов. В конечном итоге юридические инновации могут даже сделать кредиты, которые уже были обещаны таким образом, более приоритетными, чем кредиты, которые не были обещаны. Это приведет нас к совершенно тому же направлению, что и обсуждаемая в ++"децентрализованном обществе++ ++:++ ++поиск души Web3"++ идея: создание концепции негативной репутации или залога в блокчейне через какую-то форму "душевых токенов (soulbound tokens)".

Доказательство активов

Самая простая версия доказательства активов — это протокол, который мы видели выше: чтобы доказать, что вы владеете X монетами, вам просто нужно переместить X монет в транзакции, которая происходит в заранее установленное время или в которой поле данных содержит "эти средства принадлежат Binance". Чтобы избежать уплаты транзакционных сборов, вы можете подписать информацию вне цепи вместо этого; как биткойн, так и эфириум имеют стандарты для подписанной информации вне цепи.

Эта простая технология доказательства активов имеет две практические проблемы.

• Обработка "холодного хранилища"
• Двойное использование залога

По соображениям безопасности большинство бирж хранят подавляющее большинство средств клиентов в "холодном хранилище": на оффлайн-компьютере, где транзакции требуют ручной подписи и переноса в интернет. Я когда-то использовал холодное хранилище для личных средств, которое включало в себя постоянно отключенный компьютер, генерирующий QR-код с подписанными транзакциями, который я мог сканировать своим телефоном. Современные биржевые протоколы становятся все более сложными и часто требуют многопартийных вычислений между несколькими устройствами. Учитывая такую настройку, даже дополнительная информация для доказательства контроля над адресом становится дорогостоящей операцией!

Транзакция может принимать несколько направлений:

• Сохранение нескольких открытых адресов длительного использования. Биржа будет генерировать несколько адресов, публиковать доказательства владения для каждого адреса, а затем повторно использовать эти адреса. Это самый простой вариант на сегодняшний день, хотя он действительно добавляет некоторые ограничения в том, как защитить безопасность и конфиденциальность.
• Создание множества адресов и случайное доказательство нескольких из них. Биржа может иметь множество адресов, возможно, даже каждый адрес используется только один раз и выводится из обращения после одной транзакции. В этом случае биржа может иметь протокол, который время от времени случайным образом выбирает несколько адресов, которые должны быть "открыты", чтобы доказать владение. Некоторые биржи уже делали что-то подобное с аудиторами, но в принципе эта технология может быть превращена в полностью автоматизированную программу.
• Более сложные варианты ZKP. Например, биржа может установить все свои адреса как 1/2 мультиподпись, где ключи для каждого адреса разные, а другой является слепой версией какого-то "значительного" ключа резервного копирования, хранящегося каким-то сложным, но очень безопасным образом, например, 12/16 мультиподписью. Чтобы защитить конфиденциальность и избежать раскрытия всего набора своих адресов, биржа может даже запустить нулевое знание на блокчейне, которое докажет, что общий баланс всех адресов такого формата на цепи.

Еще одной основной проблемой является предотвращение двойного использования залога. Биржа может легко перемещать залог между собой для доказательства резервов, что позволит им притворяться, что у них есть платежеспособность, когда на самом деле ее нет. В идеале доказательство платежеспособности должно проводиться в реальном времени, обновляя доказательства после каждого блока. Если это невозможно, второстепенным вариантом будет координация фиксированного расписания между различными биржами, например, доказательство резервов во вторник в 14:00 UTC.

Последний вопрос: можно ли делать доказательства активов на фиатные деньги? Биржи не только хранят криптовалюту, но и держат фиатные деньги в банковской системе. Здесь ответ: да, но такая процедура неизбежно будет зависеть от модели доверия "фиатных денег": банки сами могут доказать балансы, аудиторы могут подтвердить балансы, и так далее. Учитывая, что фиатные деньги не могут быть проверены криптографически, это лучшее, что можно сделать в рамках этой модели, но это все равно стоит делать.

Другой подход заключается в том, чтобы четко разделить сущность, управляющую биржей и обрабатывающую активы, поддерживаемые стабильными монетами, такими как USDC, и другую сущность, обрабатывающую движение наличных между криптовалютой и традиционной банковской системой (сам USDC). Поскольку "обязательства" USDC — это просто ERC20 токены на цепи, доказательство обязательств "бесплатно" и требует только доказательства активов.

Plasma и validiums: можем ли мы сделать CEXs беззаботными?

Предположим, мы хотим пойти дальше: мы не просто хотим доказать, что у биржи есть средства для возврата денег пользователям. Напротив, мы хотим полностью предотвратить кражу средств пользователями биржи.

Первой значительной попыткой в этом направлении был Plasma, решение для масштабирования, популярное в исследовательских кругах Ethereum в 2017 и 2018 годах. Принцип работы Plasma заключается в том, чтобы разбить баланс на набор отдельных "монет", каждая из которых имеет индекс и находится на определенном месте в Merkle дереве блока Plasma. Для эффективного перевода монеты необходимо разместить транзакцию в правильном месте дерева, а корень дерева будет опубликован на цепи.

Plasma — это чрезмерно упрощенная схема. Монеты хранятся в смарт-контракте, и при выводе средств принудительно применяются правила протокола Plasma.

OmiseGo пыталась создать децентрализованную биржу на основе этого протокола, но с тех пор они переключились на другие идеи — в этом отношении сама группа Plasma также изменила направление и теперь является проектом rollup с оптимистичным EVM ++Optimism++.

Технические ограничения Plasma, задуманные в 2018 году (например, ++доказательство фрагментации монет++), не стоят внимания. С момента пика обсуждений Plasma в 2018 году ZK-SNARKs стали гораздо более жизнеспособными в связанных с масштабированием случаях использования, как мы уже упоминали, ZK-SNARKs изменили все.

Более современная версия идеи Plasma — это так называемый ++validium++: по сути, это то же самое, что и ZK-rollup, только данные хранятся вне цепи. Эта структура может быть использована для множества случаев использования, можно представить любую централизованную серверную систему, которая должна выполнять некоторый код и доказывать его правильное выполнение. Внутри validium оператор не может украсть средства, хотя в зависимости от деталей реализации, если оператор исчезнет, некоторые средства пользователей могут быть заблокированы.

Все это действительно хорошо: CEX и DEX — это далеко не бинарное противостояние, и оказывается, что существует целый набор вариантов, включая различные формы смешанной централизации, которые могут предоставить некоторые преимущества, такие как эффективность, но все же имеют множество криптографических барьеров, предотвращающих участие централизованных операторов в большинстве форм злоупотреблений.

Однако в правой части этого пространства дизайна нам все же необходимо обсудить самый основной вопрос: как обрабатывать ошибки пользователей. На данный момент самым важным типом ошибок является: что делать, если пользователь забыл свой пароль, потерял устройство, подвергся взлому или иным образом потерял доступ к своему аккаунту?

Биржи могут решить эту проблему: сначала с помощью восстановления по электронной почте, а если это не сработает, можно использовать более сложные формы восстановления через KYC. Однако для того, чтобы иметь возможность решать такие проблемы, биржа должна действительно контролировать монеты. Чтобы иметь возможность восстановить средства аккаунта пользователя по уважительной причине, биржа должна иметь власть, которая также может быть использована для кражи средств аккаунта пользователя по плохой причине. Это неизбежный компромисс.

Идеальное долгосрочное решение — полагаться на самообслуживание, дополненное ++мультиподписями++ ++и кошельками для социального восстановления++, которые помогут пользователям справляться с экстренными ситуациями. Но в краткосрочной перспективе есть два очевидных альтернативных варианта, которые имеют явно разные затраты и выгоды.

Заключение: лучшие биржи будущего

В краткосрочной перспективе есть два очевидных "категории" бирж: централизованные и децентрализованные. Сегодня последняя категория — это просто DEX, такие как Uniswap, но в будущем мы также можем увидеть "обремененные" CEX, где средства пользователей хранятся в чем-то подобном смарт-контракту validium. Мы также можем увидеть полудецентрализованные биржи, которым мы доверяем фиатные деньги, а не криптовалюту.

Обе эти категории бирж будут продолжать существовать, и самый простой способ повысить безопасность централизованных бирж — это увеличить доказательства резервов. Это включает в себя сочетание доказательства активов и доказательства обязательств. Разработка хороших протоколов для обоих представляет собой технические вызовы, но мы также должны стремиться к прогрессу в обоих направлениях и по возможности делать программное обеспечение и процессы с открытым исходным кодом, чтобы все биржи могли извлечь из этого выгоду.

В более отдаленном будущем я надеюсь, что мы все ближе к тому, чтобы все биржи были децентрализованными, по крайней мере в отношении криптовалют. Восстановление кошельков будет существовать, для новых пользователей, работающих с небольшими суммами, а также для учреждений, которым по юридическим причинам необходимо такое соглашение, может потребоваться иметь высокоцентрализованные варианты восстановления, но это может быть реализовано на уровне кошелька, а не на самой бирже. Взаимодействие с платформами, такими как ++magic.link++ и ++Polymarket++, является примером такого подхода. В отношении фиатных денег движение между традиционной банковской системой и экосистемой криптовалют может быть осуществлено через процессы ввода/вывода наличных, поддерживаемые активами (такими как USDC). Однако прежде чем мы полностью достигнем этой цели, потребуется время.

Особая благодарность Баладжи Сринивасану, а также обсуждениям с сотрудниками Coinbase, Kraken и Binance.