$63 606
-6,64%
$3260,4
-9,18%
$0,1285
-12,78%
$0,0613
-14,56%
$0,0259
-14,61%
Опубликовано: 19:46, 01 декабрь 2020

0x - инфраструктура для токенизации активов

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

0x defi dao

В этом руководстве мы сравним торговлю на централизованных биржах криптовалют (например, Binance) и маркетинг на 0x, децентрализованном протоколе обмена, построенном на Ethereum.

Праймер высокого уровня

Все централизованные биржи выполняют три основных вида деятельности:

  1. Хранение средств пользователей
  2. Размещение и распространение заказов
  3. Расчеты по сделкам

В протоколе 0x эти задачи выполняются по другому.

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

    При торговле на 0x ваши активы никогда не должны покидать ваш адрес Ethereum, пока сделка не будет урегулирована.

  3. Размещение и распространение заказов
  4. Заказы на 0x могут размещаться кем угодно, а не единственным участником, размещающим заказы. Любая организация, которая размещает и распределяет заказы 0x, называется «ретранслятором». В настоящее время большинство ретрансляторов представляют собой централизованные объекты, на которых размещен API, из которого можно получать заказы.

    В дополнение к хостингу ретранслятора, распространение также может быть достигнуто через Mesh, одноранговую сеть, созданную специально для совместного использования заказов 0x. Для получения дополнительной информации см. 0x.org/mesh .

    Ордер 0x - это пакет данных, который содержит детали заказа вместе с действительной подписью (например, действительной подписью эллиптической кривой, сгенерированной из адреса Ethereum трейдера) его содержимого.

  5. Расчеты по сделкам

Когда два участника соглашаются с условиями сделки, заказ 0x отправляется в блокчейн Ethereum и рассчитывается с помощью смарт-контракта протокола 0x.

Чтобы смарт-контракты 0x могли перемещать средства от имени трейдеров, трейдеры должны сначала дать контрактам явное разрешение. Это делается путем установки «допуска» для определенного количества активов, которые 0x может затем передать со своего адреса Ethereum.

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

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

А как насчет согласования заказов?

Сегодня существуют две доминирующие стратегии ретранслятора: сопоставление и открытая книга заказов. Ретрансляторы открытой книги заказов размещают заказы, которые любой может заполнить, напрямую отправив транзакцию (с деталями заказа и желаемой суммой заполнения) в блокчейн Ethereum.

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

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

Соответствующие ретрансляторы требуют, чтобы трейдеры создали ордер, обратный 0x к тому, который они хотят заполнить, и отправили его обратно в сопоставитель. Затем соответствующий ретранслятор выполнит оба заказа в одной атомарной транзакции в Ethereum от имени трейдера.

В обеих моделях ретранслятор никогда не контролирует активы трейдера.

Создание заказов

0x заказы существуют только вне сети и их можно создавать совершенно бесплатно. Чтобы создать действительный порядок 0x, вы можете использовать библиотеку @ 0x / order-utils TypeScript / jаvascript или, альтернативно, библиотеку Python 0x-order-utils.py . Эти библиотеки помогут вам:

1) Сгенерировать заказ в правильном формате (например, кодирование / декодирование assetData)
2) Создание правильного хеша для содержимого заказа
3) Подпишите заказ своей подписью в виде эллиптической кривой

Для набора сценариев, демонстрирующих вышеуказанные шаги, а также настройку допуска, взгляните на 0x Starter Project .

Обратите внимание, что saltполе заказа должно быть установлено на текущую временную метку unix в миллисекундах для полной совместимости с cancelOrdersUpTo функцией. Для получения подробных сведений о том, как создается заказ, обратитесь к разделу заказов в спецификации протокола.

Распространение заказов

Если у вас есть действительный заказ 0x, его можно отправить ретранслятору или в Mesh-сеть. Вы можете использовать конечную точку POST / v3 / order стандартного API ретранслятора (см. SubmitOrderAsync в 0x Connect) или метод JSON-RPC mesh_addOrders Mesh (см. AddOrdersAsync в@0x/mesh-rpc-client).

Если вы хотите получать уведомления всякий раз, когда трейдер заполняет ордер, вы также должны отправить ордер в экземпляр узла 0x Mesh, который вы используете.

В то время как размещение заказов на ретранслятор или в Mesh представляет собой модель распределения «push», существует также альтернативная модель «pull», известная как Request for Quote (RFQ). Это особенность 0x API , которая реализует не только Standard Relayer API, но и дополнительные ресурсы для агрегирования ликвидности как из 0x, так и из источников, отличных от 0x. Для RFQ API 0x настроен со списком маркет-мейкеров, и всякий раз, когда трейдер запрашивает котировку для наилучшей доступной цены из всех источников, API связывается с этими маркет-мейкерами, которые могут ответить приказом 0x, представляющим их "котировку". . " Если этот заказ превосходит цены из других источников, он будет передан API-клиенту, который может заполнить его так же, как и любой другой заказ 0x.

Выполнение заказов

Ордера могут быть заполнены путем вызова различных методов в контракте Биржи , как описано в разделе «Заполнение ордеров» спецификации протокола. В целом эти методы можно разделить на категории:

Заполнение одного заказа

Эти методы полезны для выполнения разовых заказов. Все эти методы имеют несколько разные условия отказа:

fillOrder
fillOrKillOrder
fillOrderNoThrow

Выполнение нескольких заказов

Эти методы полезны для выполнения нескольких заказов за одну транзакцию. Каждый метод имеет разные условия сбоев транзакции и выполнения:

batchFillOrders
batchFillOrKillOrders
batchFillOrdersNoThrow
marketSellOrders
marketSellOrdersNoThrow
marketBuyOrders
marketBuyOrdersNoThrow

Соответствующий порядок заполнения

Особый случай существует при заполнении как ордеров на покупку, так и на продажу одной и той же пары активов, когда цена ордера на продажу меньше или равна цене ордера на покупку. Эти 2 ордера могут быть одновременно заполнены без требований к капиталу, вызвав функцию matchOrders .

Взаимодействие с разными моделями

Обратите внимание, что процесс заполнения заказов отличается при взаимодействии с ретранслятором открытой книги заказов или подходящим ретранслятором. Эти заказы можно различить, просмотрев поля senderAddress и takerAddress в заказе .

Когда оба поля имеют значение 0 (как в модели открытой книги заказов) или когда просто senderAddressравно 0 (как в модели RFQ-T), заказ можно заполнить напрямую, вызвав желаемую функцию заполнения в контракте Exchange. Берущий, заполняющий заказ таким образом, выигрывает от атомарности транзакции Ethereum и более детального контроля сбоев транзакций . Однако в этом сценарии ответственность за оплату газа и выбор конкретных заказов для выполнения ложится на покупателя.

В модели сопоставления берущий сначала отправляет подписанный заказ в сопоставитель (где либо порядок, senderAddressлибо takerAddressустановлен на адрес сопоставителя). Затем сопоставитель выбирает, какой ордер (ы) сопоставить с подписанным ордером берущего, и заполняет ордера одновременно (обычно путем вызова batchFillOrKillOrdersили matchOrders). В этом сценарии сопоставитель отвечает за оплату газа и выбор конкретных заказов для сопоставления.

Отмена заказов

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

Этот cancelOrdersUpTo подход, пожалуй, наименее прямолинейный, но и самый эффективный для маркет-мейкера. Он позволяет отменить произвольное количество заказов на фиксированное количество газа. Создавая заказы, в которых saltполе равно текущей временной метке unix в миллисекундах, вы можете отменить все заказы, которые были созданы в определенное время или раньше, за один cancelOrdersUpTo вызов (транзакция фиксированного размера). Обратите внимание, что любые будущие заказы, созданные с помощью, saltкоторый меньше самого большого saltаргумента cancelOrdersUpTo вызова по вашему адресу, будут автоматически недействительными.

Явная отмена заказов всегда требует транзакции в цепочке. Однако вы можете создавать краткосрочные заказы и заменять просроченные заказы без каких-либо транзакций в цепочке. Из-за вариабельности времени включения транзакций в блоки не рекомендуется устанавливать чрезвычайно агрессивные сроки истечения срока для ордеров. (Опытным путем большинство маркет-мейкеров устанавливают срок действия ордеров примерно на 5 минут.)

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

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

Получение заказов за пределами сети

Поскольку заказы 0x находятся вне сети, их нужно откуда-то получать. В настоящее время есть два места для получения заказов:

1) Непосредственно от ретрансляторов через их конечные точки API. Чтобы упростить жизнь трейдерам, многие реализуют API Standard Relayer , позволяя использовать один клиент для получения заказов от нескольких ретрансляторов. Стандартные клиенты API Relayer существуют в Python и TypeScript / jаvascript . Чтобы узнать больше о получении заказов от ретрансляторов, ознакомьтесь с нашим учебным курсом Как использовать стандартный Relayer API .

2) Косвенно через p2p сеть 0x Mesh. Многие ретрансляторы разделяют ликвидность через сеть Mesh p2p, что означает, что все их ордера 0x доступны любому, у кого есть узел Mesh. Вместо того, чтобы извлекать заказы из нескольких API-интерфейсов Relayer, вы можете развернуть узел Mesh и подключиться к агрегированному потоку заказов.

Торговля на Ethereum

При торговле на централизованной бирже вы должны интегрироваться исключительно с торговым API CEX, чтобы знать состояние мира (например, книга заказов, состояние заполнения / отмены). При торговле на 0x вашими источниками правды являются блокчейн Ethereum и существующие офчейн-ордера. В этом разделе мы подробнее рассмотрим состояние сети, которое вам понадобится.

Управление узлами Ethereum

Чтобы отслеживать блокчейн Ethereum, вы должны взаимодействовать с узлом Ethereum. Вы можете либо интегрировать своего маркет-мейкера с сервисом размещенных узлов, например Infura.io, либо разместить свой собственный узел. При разработке своего маркет-мейкера вы можете настроить локальную тестовую сеть 0x , предоставляющую вам поддельный узел Ethereum, полезный для целей тестирования.

Вероятностная окончательность

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

Вероятностная окончательность означает, что ни один торговый расчет никогда не бывает окончательным на 100%. Он становится экспоненциально более окончательным с каждым дополнительным блоком Ethereum, который добывается поверх того, в который он был включен.

Это означает, что в течение определенного периода времени урегулирование все еще может возобновиться. Это происходит, когда происходит реорганизация блока, в результате чего следующий действующий блок становится «не задействованным» (т. Е. Больше не является частью основной цепочки). Это случается не часто, но это важный крайний случай. 0x Mesh может помочь вам справиться со всеми возможными изменениями состояния, связанными с нужными вам порядками 0x (включая реверсии состояния).

Отметки времени блока

В Ethereum единственное требование к блоку timestamp - он должен быть больше, чем временная метка предыдущего блока. Это означает, что timestamp следующий блок может быть до или после текущей временной метки unix.

Поскольку протокол 0x проверяет истечение срока действия заказа, используя временные метки блока, заказ будет считаться истекшим, только если существует временная метка блока, превышающая срок действия заказа. Вы можете использовать текущее время как приблизительное время блока, однако все еще существует вероятность того, что «истекший» заказ будет заполнен, если следующая временная метка блока окажется между меткой времени последнего блока и текущей меткой времени.

Усмотрение майнера

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

Допустим, трейдер отправляет транзакцию отмены ордера; нет никаких гарантий относительно порядка, в котором эта транзакция будет включена в цепочку блоков. Вы можете попытаться побудить майнеров включать его раньше, увеличив gasPrice (читай: комиссию), уплаченную за транзакцию, но то же самое может сделать любой другой трейдер, пытающийся заполнить заказ (подробнее об этой проблеме читайте в нашем обзоре, обзоре и опасностях. серии сообщений в блоге о виртуальном поселении ). Из-за этого состояния гонки мы рекомендуем вам использовать более короткие сроки истечения ваших заказов, а не полагаться на отмену в цепочке. Кроме того, вы можете использовать нашу функцию cancelOrdersUpTo, чтобы отменить несколько заказов за одну транзакцию.

Сбои транзакций

Как правило, транзакция Ethereum либо выполняется, либо полностью завершается с ошибкой. Это позволяет транзактору обновлять состояние цепочки блоков, зная, что изменения состояния будут отменены, если в рамках той же транзакции не будет выполнено какое-либо более позднее условие.

Атомарность транзакции

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

Управление риском

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

Короткие продажи, деривативы и маржинальная торговля

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

Augur
bZx
Compound
Dharma
dYdX
Maker

Асинхронность хеджирования

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

1) Маркетмейкер видит незавершенное исполнение своего собственного ордера в мемпуле.
2) Маркет-мейкер хеджируется, занимая противоположную позицию того же актива на CEX.
3) Первоначальное исполнение не удается из-за недостаточного баланса или допуска берущего, и у мейкера остается только хеджирующая часть своей позиции.

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

Размещение капитала

Протокол 0x предполагает, что активы пользователя будут находиться в их собственном кошельке, а не депонированы в контракте, специфичном для DEX. Это позволяет маркет-мейкерам размещать заказы через несколько ретрансляторов 0x без необходимости делить свой капитал в нескольких разных местах.

Инструменты разработчика 0x

Каково состояние инструментария разработчика 0x?

В настоящее время у нас есть лучшая поддержка инструментов для jаvascript / TypeScript, и мы активно улучшаем поддержку Python. Посетите раздел для разработчиков на сайте проекта, чтобы ознакомиться с полным списком доступных инструментов для разработчиков.

Если вы планируете реализовать настраиваемую инфраструктуру, вам потребуются как минимум следующие функции:

  • Взаимодействие с ретрансляторами через веб-сокеты или HTTPS
  • Кодирование assetDataзаказа с помощью ABIv2
  • Хеширование заказов
  • Криптографическая подпись заказов с адресом, с которым вы хотите торговать

Кроме того, настоятельно рекомендуется подключиться к узлу Ethereum, чтобы вы могли:

  • Отслеживать состояние заказов
  • Получать уведомления при изменении состояния заказа (подписавшись на соответствующие события)
  • Устанавливать скидки для смарт-контрактов 0x для активов, которые вы хотите продать
  • Размещать или отменять заказы

Примеры проектов на 0x

Предлагаем краткий список примеров маркетинговых проектов, построенных на 0x:

Маркетмейкер Maker на Python: https://github.com/makerdao/market-maker-keeper
Hummingbot - бот для создания рынка с открытым исходным кодом: https://hummingbot.io/
Пример бота RadarRelay: https://github.com/RadarTech/sdk-bot-example

Появилось много вопросов? Получите ответы здесь.

cryptocoinexpert 0x

На сайте CryptoCoinExpert.info публикуются обзоры криптопроектов, технологических решений для IoT, Defi, Dao, токенизации активов с использованием технологии блокчейн.

Присоединяйтесь к нам!

cryptocoinexpert.info
Ctrl
Enter
Заметили ошЫбку
Выделите текст и нажмите Ctrl+Enter
Обсудить (0)
Ссылки по теме:
Другие материалы рубрики:
ETH
Криптовалюты
ETH
05 апрель 2021
0
BTC
Криптовалюты
BTC
05 апрель 2021
0
BNB
Криптовалюты
BNB
04 апрель 2021
0
XRP
Криптовалюты
XRP
03 апрель 2021
0
IOTX
Криптовалюты
02 декабрь 2020
1
Binance
Биржи
14 апрель 2021
0
Bitfinex
Биржи
11 апрель 2021
0
USDT
Криптовалюты
02 апрель 2021
0
Этот сайт использует cookie для хранения данных. Продолжая использовать сайт, Вы даете свое согласие на работу с этими файлами.