В этом посте мы подробно опишем наши смарт-контракты, нашу терминологию, специфичную для системы, и то, как она преобразуется в заявление о допустимом переходе состояния, которое мы доказываем.

Цели дизайна

Основная цель смарт-контракта — обеспечить самостоятельную защиту пользователей, а также возможность торговать на бирже. Для масштабируемости контракт не хранит все состояние баланса, как это делают децентрализованные биржи. Вместо этого он сохраняет краткое представление состояния баланса — обязательство Меркла (32 байта для всего состояния). Мы обеспечиваем целостность состояния, требуя действительное доказательство STARK для каждого обновления обязательства состояния, показывающее действительность обновления. Наш аварийный механизм гарантирует, что пользователи всегда смогут получить свои средства, даже если служба обмена не отвечает или решит злонамеренно подвергнуть их цензуре.

Дизайн высокого уровня

Существует два центральных контракта:
(a) контракт StarkVerifier — контракт без сохранения состояния, который получает в качестве входных данных доказательство STARK и его общедоступные данные, а также проверяет правильность общедоступных данных с использованием доказательства. Если доказательство принято, публичный ввод затем передается в контракт StarkExchange, чтобы управлять его состоянием.
(b) Контракт StarkExchange — этот контракт поддерживает обязательство — краткое представление балансов. Кроме того, он хранит записи о депозитах и ​​выводах средств в сети.

Обозначение

Ключ пользователя StarkDEX

Ключ пользователя StarkDEX используется StarkDEX для проверки подписей пользователей ECDSA. Подпись проверяется как часть доказательства, и поскольку эллиптическая кривая, используемая в Ethereum, не подходит для STARK, мы используем реализацию ECDSA поверх другой, удобной для STARK кривой. Это требует от пользователей создания дополнительных пар ключей для использования системы StarkDEX. Чтобы отличить стандартный ключ Ethereum от пользовательского ключа StarkDEX, мы называем его здесь и в коде «ключом STARK».

Хранилища

Хранилища используются для хранения балансов. Каждое хранилище идентифицируется уникальным идентификатором и помечается открытым ключом его владельца (STARK) и идентификатором хранящегося в нем актива (AKA tokenId). Содержимое хранилища — это количество монет в хранилище. Пользователи могут иметь несколько хранилищ, в которых хранятся разные части одного и того же актива.

Актив Quantum

В системе доказательства мы ограничены 63 битами для представления суммы (по дизайну), поэтому мы нормализуем каждый актив, используя выделенный квант, определенный при регистрации актива. Ожидается, что одна единица квантованной суммы (любого актива) будет стоить примерно 10–4 доллара США, за исключением случая невзаимозаменяемых токенов. Например, при торговле обернутым эфиром мы будем использовать квант примерно 103 (обернутых) Gwei (в одном эфире 109 Gwei), что на данный момент составляет примерно 10–4 доллара США и позволяет торговать суммами от 10–4 до 1015 долларов США, что кажется достаточным для большинства практических целей. Квант актива может устареть в результате резких изменений стоимости актива. Чтобы предотвратить это, актив можно зарегистрировать снова с другим идентификатором и обновленным квантом.

Стандартные потоки пользователей

Регистрация

Для регистрации пользователь вызывает функцию контракта register, предоставляя ей свой открытый ключ STARK. Контракт связывает ключ Ether вызывающего абонента с предоставленным ключом STARK. Эта ассоциация необходима для преобразования адресов пользователей во время потоков вывода и депозита, так как в системе пользователи StarkDEX идентифицируются по их ключу STARK.

Депозит

Чтобы внести средства в систему, пользователь вызывает depositфункцию, предоставляя ей tokenIdидентификацию актива, a vaultIdи quantizedAmountдля внесения депозита. При депонировании нового актива, для которого у пользователя нет хранилища, пользователь должен связаться со StarkDEX для получения выделенного идентификатора хранилища, назначенного этому активу. На практике такое общение может осуществляться прозрачно из внешнего интерфейса. Записи о депозитах в сети идентифицируются тройкой ( starkKey, tokenId, vaultId), и единственное ограничение, применяемое контрактом к депозитам пользователей, заключается в том, что ключ STARK должен быть совместим с эфирным ключом вкладчика. StarkDEX выбирает, какие депозиты являются законными. Если StarkDEX по какой-либо причине не заберет некоторые депозиты, будь то из-за того, что ( tokenId,vaultId) не были предоставлены оператором или потому что оператор стал злонамеренным, пользователь может отменить депозит, используя механизм Escape Hatch. Наконец, если депозит является законным, средства перемещаются из области депозитов в сети в область вне сети с использованием доказательства, подтверждающего, что баланс хранилища вне сети был увеличен на правильную сумму.

Вывод

Чтобы вывести средства с биржи, пользователь должен сначала связаться со StarkDEX через канал вне сети (например, веб-сайт биржи) и запросить перевод средств из зоны вне сети в зону вывода средств в сети. Как только доказательство подтвердит перемещение средств в ончейн-зону, пользователь может выйти из контракта StarkDEX напрямую, используя эту withdrawфункцию. Функция получает только tokenId, идентифицирует ключ пользователя из запроса и переводит сумму (этого конкретного актива), хранящуюся в области вывода средств в сети пользователя, непосредственно в кошелек пользователя.

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

Потоки аварийного люка

Escape Hatch предназначен для того, чтобы пользователь мог снимать средства независимо от доступности StarkDEX (в ближайшие недели мы опубликуем отдельный пост о решениях для доступности данных).

Как показано в нашем предыдущем сообщении в блоге , есть три области, в которых могут присутствовать средства (фактически, их записи) — область депозитов в сети, область снятия средств в сети и область торговли вне сети.

Вспомните стандартное движение средств между сферами: депозиты → торговля → снятие средств.

Каждое перемещение из одной области в другую требует участия StarkDEX. Используя стандартный поток, пользователи могут извлекать средства только из области вывода средств в сети. Механизм Escape Hatch позволяет пользователям извлекать средства из двух других областей.

Выход из зоны депозитов в сети

Основной целью этого механизма побега является извлечение средств, даже если StarkDEX, злонамеренно или нет, не забирает депозит (т. е. не перемещает средства вне сети).

Пользователи могут получить средства из области депозитов в сети, следуя описанному здесь процессу.

Пользователь должен сначала вызвать функцию depositCancel, предоставив ей tokenIdи vaultId, запросив отмену перевода депозита запрошенного актива в запрошенное хранилище. Запрос на отмену блокируется по времени, чтобы предотвратить состояние гонки между запросом и входящим подтверждением, отправленным биржей; таким образом, вызов depositCancelтолько записывает запрос, активируя временную блокировку. По прошествии достаточно длительного периода времени (установленного произвольно на 1 день в Альфа-контракте) пользователь может позвонить depositReclaimс теми же параметрами, переведя все средства из запрошенного хранилища на кошелек пользователя.

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

Выход из зоны торговли вне сети

Принудительный вывод средств из StarkDEX осуществляется двумя разными способами, которые мы подробно объясним далее в этом разделе: (1) Пока биржа работает, смарт-контракт гарантирует, что биржа не подвергает цензуре ни одного пользователя. (2) Как только биржа игнорирует запрос на вывод средств даже одного пользователя, контракт позволяет проигнорированному пользователю закрыть биржу (мы говорим, что биржа становится «замороженной» в этом состоянии) и позволяет пользователям выводить свои средства, отображая привязку их содержимое хранилища в (фиксированный) корень Merkle базы данных балансов. Теперь подробности.

Фаза (1): Оперативный обмен

Если запросы пользователя (вне сети) на вывод средств игнорируются биржей, они могут вызвать escapeRequestфункцию, предоставив ей vaultId, уведомив биржу о том, что она должна вывести средства пользователя из запрошенного хранилища. Чтобы предотвратить DoS-атаки на биржу, которая должна отвечать на каждый такой запрос (в течение определенного периода времени), за escapeRequest. Если в течение фиксированного времени (произвольно установленного на пять дней в альфа-версии) StarkDEX не предоставляет доказательства перемещения всего содержимого хранилища в область вывода средств в сети или, альтернативно, показывает, что хранилище не принадлежит вызывающему абоненту, тогда пользователь может позвонить функция escapeFreeze, замораживание обмена и переход к следующему этапу.

Фаза (2): Замороженный обмен

После того, как биржа заморожена, все представленные ею доказательства автоматически отклоняются контрактом, что приводит к замораживанию состояния базы данных внебиржевых балансов путем исправления ее корня Merkle и ее неизменности. Находясь в замороженном состоянии, все пользователи могут вывести свои средства, предоставив контракту прямое доказательство владения активами. Эта часть не была реализована в альфа-версии и может быть реализована лаконично с использованием STARK или менее лаконично, путем явного указания путей аутентификации Merkle от хранилища до (замороженного) корня БД.

Состояние контракта StarkDEX

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

Приверженность The Vaults Merkle

Как описано ранее, балансы пользователей хранятся в хранилищах, каждое хранилище представлено уникальным идентификатором и тройкой ( starkKey, tokenId, amount), где starkKeyидентифицирует владельца хранилища, tokenIdидентифицирует актив, хранящийся в нем, и amountпредставляет собой (квантованную) сумму. в настоящее время хранится в хранилище. Хранилище, хранящее ( starkKey=0, tokenId=0,amount=0) называется «пустым». Идентификаторы хранилища представляют собой последовательные целые числа от 0 до 2³¹-1, поэтому каждый идентификатор определяет уникальный путь к листу в дереве Меркла высотой 31, где хранится информация. Контракт StarkDEX управляет балансами вне сети, сохраняя корень дерева Меркла хранилищ (и его высоту), гарантируя, что любое изменение его состояния является результатом (законного) депозита, снятия или расчета. Если корень Merkle хранилища обновляется в результате депозита или снятия средств, контракт StarkDEX подтверждает, что балансы в цепочке обновляются соответствующим образом.

Доступность данных

Учтите, что в случае заморозки контракта StarkDEX (см. раздел Аварийный люк) крайне важно, чтобы пользователи имели доступ ко всему состоянию хранилищ. Это называется проблемой доступности данных. В качестве нашего текущего решения StarkDEX использует комитет надежных сторон (например, StarkWare, 0x, Ethereum Foundation, биржи и т. д.) и ожидает, что каждый новый корень будет подписан большинством комитета, обеспечивая общедоступность данных. . Обратите внимание, что (1) механизм доступности данных не реализован в альфа-версии и (2) если и когда другие решения для обеспечения доступности данных будут считаться «стандартной передовой практикой», мы планируем использовать их вместо этого.

Корень Меркла поселений

Каждое поселение идентифицируется уникальным идентификатором, подписанным обеими сторонами (мейкером и тейкером). Аналогично дереву Меркла хранилищ, идентификаторы поселений находятся в диапазоне 0…2³¹–1, и мы записываем множество выполненных поселений с помощью дерева Меркла с логическими значениями листьев, где каждый лист соответствует идентификатору поселения (логическое значение означает, выполнен расчет или нет). Корень дерева Меркла поселений (и его высота) также хранится в контракте StarkDEX и требуется для обеспечения того, чтобы расчет не выполнялся дважды. Эта функция лишь частично реализована в Альфе.

Последовательность чисел

Порядковый номер является монотонно возрастающим идентификатором состояния вне сети и вместе с корнем Меркла хранилища и высотой дерева подписывается членами комитета. Его цель состоит в том, чтобы гарантировать, что каждое изменение в корне проверяется комитетом, даже если новый корень представляет собой повторяющееся состояние баланса. Без порядкового номера кто-то мог бы сохранить все подписи комитета, и если состояние повторяется, они могли бы утаить данные от комитета и использовать старую подпись в том же состоянии, которое комитет может не восстановить.

Действия оператора StarkDEX

Оператор биржи может изменить состояние StarkDEX, выполнив любую из следующих операций: (а) внести депозит из ончейн-зоны в оффчейн-зону. (b) выполнение расчетов (c) вывод средств из оффчейн-зоны в ончейн-зону. (d) выполнение запросов Escape Hatch из офчейн-зоны («полный вывод»). Ниже мы описываем, как каждая из этих операций влияет на состояние контракта StarkDEX, и требования для проверки легитимности операций.

Депозиты: от On-Chain до Off-Chain  зон

Параметры депозитной операции: ( starkKey, vaultId, tokenId, amount).

Операция требует, чтобы соответствующий баланс в цепочке содержал как минимум (квантованный) amountтребуемый актив, и чтобы хранилище с требуемым идентификатором в состоянии вне цепочки (представленном корнем Merkle) либо принадлежало к тому же ключу STARK. или пусто.

После завершения депозита гарантируется следующее:

• Требуемая сумма уменьшается с баланса в сети и добавляется в хранилище вне сети.
• Хранилище вне сети starkKeyи tokenIdсоответствуют параметрам
• Изменения состояния вне сети отражаются в корне Merkle хранилищ в сети.

Населенные пункты

Параметры поселения:

• Два ключа СТАРК и подписи; по одному на каждую сторону
• Два идентификатора токена и суммы, представляющие торгуемые активы
• Четыре идентификатора хранилища. У каждой стороны есть два задействованных хранилища (по одному для каждого актива)
• Идентификатор населенного пункта

Для операции необходимо следующее:

• Знание подписи производителя на идентификаторах хранилища производителя, идентификаторах токенов, суммах и идентификаторе расчетов
• Знание подписи получателя на сообщении, подписанном создателем, вместе с идентификаторами хранилища получателя.
• Идентификатор населенного пункта еще не использовался (не в Альфе)
• Хранилища принадлежат предполагаемым владельцам (создателям/получателям) и хранят необходимые активы.

После окончательного расчета гарантируется следующее:

• Требуемые суммы уменьшаются из соответствующих исходящих хранилищ и добавляются к соответствующим входящим хранилищам.
• Идентификатор поселения изменен с неиспользуемого на используемый в дереве поселений Меркле.
• Если хранилище имеет amount=0 после выполнения расчетов, оно очищается, так что теперь оно также имеет starkKey== tokenId0
• Изменения состояния вне сети отражаются в хранилищах в сети Merkle root.

Стоит отметить, что хранилище, которое изначально было пустым, может принадлежать кому угодно и хранить любые активы.

Обратите внимание, что единственный эффект, который эта операция оказывает на состояние контракта StarkDEX, касается корней Merkle. То же самое и с партией многих поселений — нет необходимости передавать какие-либо данные поселений, достаточно просто отправить одно доказательство STARK для всей партии вместе с новыми корнями Меркла. Это дает StarkDEX возможность объединять огромное количество расчетов в один блок Ethereum.

Вывод средств: от Off-Chain к On-Chain

Операция снятия (естественно) очень похожа на операцию депозита. Его параметры также ( starkKey, vaultId, tokenId, amount), и он требует, чтобы автономное хранилище имело ожидаемые параметры (владелец starkKeyи хранение активов tokenId) и имело достаточно средств. Это гарантирует, что эта операция соответственно уменьшает сумму хранилища вне сети (влияя на корень Merkle) и помечает хранилище как пустое, если его сумма равна 0. Кроме того, она проверяет, что баланс вывода средств в сети, соответствующий starkKey, tokenIdувеличивается соответствующим образом. .

Выполнение запросов аварийного люка

Запрос на побег действителен только в том случае, если запрошенный идентификатор хранилища действительно принадлежит вызывающему. Текущая архитектура не предоставляет контракту StarkDEX достаточно информации для проверки правильности запроса на побег во время подачи, поэтому система также обрабатывает недействительные запросы на побег. Для выполнения запроса на побег оператор должен отправить в контракт доказательство, либо (1) доказывающее, что хранилище действительно принадлежит инициатору запроса и была вызвана операция изъятия, после чего хранилище стало пустым, либо (2) доказывающее, что запрошенное хранилище не принадлежит инициатору запроса, а значит, его состояние не должно измениться в результате выполнения данной операции.

На этом завершается раздел, описывающий основной контракт StarkDEX (он же StarkExchange). В следующем разделе мы углубимся в утверждение, проверенное контрактом StarkVerifier.

Заявление StarkDEX

Утверждение, проверенное контрактом верификатора StarkDEX, является допустимым последовательным выполнением пакета действий оператора, спроецированных в корнях Меркла и общедоступных входных данных, которые используются для изменения записей в цепочке.

Пакетные операции с использованием доказательств STARK

StarkDEX использует доказательства STARK для объединения множества операций. Каждое доказательство подтверждает целостность некоторых общедоступных входных данных (которые передаются по цепочке), которые используются для изменения состояния контракта StarkDEX. Предположим на данный момент, что единственной операцией является расчет. В этом случае общедоступными входными данными могли быть два корня Меркла, начальный и конечный. Доказанным утверждением в этом случае будет знание последовательности действительных расчетов, изменяющих состояние хранилищ от начального корня до конечного корня (см. рис. 4). На практике общедоступный ввод содержит дополнительные сведения. Есть две основные причины для дополнительных деталей.

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

В StarkDEX целостность общедоступных входных данных проверяется контрактом StarkVerifier (который не имеет состояния) с использованием доказательства STARK. Только если доказательство будет принято, общедоступные данные, необходимые для изменения состояния StarkDEX, будут переданы в контракт StarkExchange. Контракт StarkExchange подтверждает, что эти типы команд обновления отправляются только из контракта StarkVerifier, обеспечивая действительность каждого обновления. Далее мы опишем общедоступные поля ввода, используемые в нашем доказательстве STARK. Мы сосредоточимся на полях, влияющих на контракт StarkDEX, и для простоты пренебрежем полями, необходимыми для корректной работы верификатора (например, размер партии).

Merkle Roots

Каждое доказательство отправляется с четырьмя корнями Меркла на общедоступных входных данных, а именно с начальным и конечным корнями дерева хранилищ, а также с начальным и конечным корнями дерева поселений. Контракт StarkDEX гарантирует, что начальные корни равны сохраненным в настоящее время корням, и что корень хранилищ подписан комитетом (см. раздел о доступности данных) вместе с правильным порядковым номером. Высоты являются частью общедоступного ввода, для поддержки будущих потребностей необходимо увеличить одно из деревьев, но функциональность не реализована в альфа-версии. После подтверждения того, что начальные корни и высоты соответствуют состоянию контракта, корни контракта обновляются до окончательных значений.

Нерасчетные операции

Для любой операции, не связанной с расчетами, требуются общедоступные входные данные, показывающие изменения, внесенные в область вне сети, и эти данные используются для изменения области средств в сети. По техническим причинам (упрощение дизайна AIR — Algebraic Intermediate Representation ) мы используем один и тот же публичный формат ввода для всех операций (кроме расчетов, которые не требуют публичного ввода). Открытый формат ввода для каждой такой операции ( vaultId, starkKey, tokenId, amountBefore, amountAfter).

Следующее гарантируется доказательством Штарка:

• Операция была применена к хранилищу с ожидаемым идентификатором
• Хранилище принадлежит владельцу starkKey и хранит требуемые активы tokenId(или пусто)
• Операция изменила баланс в хранилище с amountBeforeнаamountAfter

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

На этом мы завершаем подробное обсуждение сетевых компонентов StarkDEX. В следующем посте серии StarkDEX Deep Dive мы подробно расскажем, что входит в конструкцию движка STARK для DEX.

Если у вас есть какие-либо вопросы или предложения, оставьте комментарий здесь или напишите нам в Твиттере @StarkWareLtd .

Михаил Рябзев и Алон Фридберг

StarkWare Industries