barterDEX Whitepaper v2 Russian Translation - SuperNETorg/komodo GitHub Wiki

unofficial russian translate by Decker

• Оригинал документа: https://github.com/SuperNETorg/komodo/wiki/barterDEX-Whitepaper-v2
• Статус перевода: Черновик 1.0
• Выделенные примечания в переводе (Примечание) сделаны лично мной, для облегчения понимания смысла whitepaper.

barterDEX - децентрализованная биржа обмена монет на основе технологии атомарного свопа (eng, atomic swap - здесь, атомарный, является термином, который означает что обмен совершится только при выполнении всех условий в системе, своп - соответственно обмен, далее по тексту, вместо atomic swap мы будем употреблять термин "атомарный своп").

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

В текущей версии в barterDEX была добавлена поддержка SPV кошельков на базе Electrum в дополнение к десяткам "обычных кошельков", запущенных на базе полных узлов. Во внутренней реализации barterDEX предусмотрен определенный уровень абстракции для SPV-кошельков и обычных кошельков, таким образом большинство API работают прозрачно для того и другого типа кошельков. Также, текущая реализация barterDEX реализует "Liquidity Multiplication" ("Умножение Ликвидности"), которое позволяет использовать одни и те же средства для запросов в нескольких orderbook'ах (направлениях обмена), где первый выполнившийся ордер завершает сделку.

(Примечание: на обычных биржах, принцип Liquidity Multiplication не поддерживается, так, например, осуществляя обмен 1 BTC на какую-либо другую монету вы вынуждены "заморозить" 1 BTC в ордере и пока вы не отмените его, вы не сможете использовать эти 1 BTC в других направлениях обмена, barterDEX обладает более широкими возможностями, обладая 1 BTC - вы можете выставить ордеры одновременно на нескольких рынках, например KMD/BTC, ZEC/BTC и т.п., которые кажутся вам наиболее выгодными, при этом средства не будут "заморожены" и обмен может быть произведен, как по одному направлению, так и по другому, в зависимости от того какой ордер "сработает" первым).

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

За исключением вызовов самого Electrum API и некоторых различий в формате возвращаемого JSON для методов вроде "listunspent" можно создать модель API, которая будет одинаковой для всех монет. Ниже приведен список текущих API с их параметрами (также, на данный момент существует документ shossain'а - barterDEX_API_Summary_by_Category.doc , который содержит более подробное описание API barterDEX):

pricearray(base, rel, starttime=0, endtime=-1, timescale=60) -> [timestamp, avebid, aveask, highbid, lowask]
setprice(base, rel, price)
autoprice(base, rel, minprice, margin, refbase, refrel, factor, offset)*
goal(coin=*, val=<autocalc>)
myprice(base, rel)
enable(coin)
disable(coin)
notarizations(coin)
parselog()
statsdisp(starttime=0, endtime=0, gui=, pubkey=)
getrawtransaction(coin, txid)
inventory(coin)
bestfit(rel, relvolume)
lastnonce()
buy(base, rel, price, relvolume, timeout=10, duration=3600, nonce, pubkey=)
sell(base, rel, price, basevolume, timeout=10, duration=3600, nonce, pubkey=)
withdraw(coin, outputs[])
sendrawtransaction(coin, sinumconfirmsgnedtx)
swapstatus()
swapstatus(coin, limit=10)
swapstatus(base, rel, limit=10)
swapstatus(requestid, quoteid)
recentswaps(limit=3)

public API:

getcoins()
getcoin(coin)
portfolio()
getpeers()
passphrase(passphrase, gui)
listunspent(coin, address)
setconfirms(coin, numconfirms, maxconfirms=6)
trust(pubkey, trust) # positive to trust, 0 for normal, negative to blacklist
balance(coin, address)
orderbook(base, rel, duration=3600)
getprices(base, rel)
sendmessage(base=coin, rel=, pubkey=zero, <argjson method2>)
getmessages(firsti=0, num=100)
deletemessages(firsti=0, num=100)
secretaddresses(prefix='secretaddress', passphrase, num=10, pubtype=60, taddr=0)
electrum(coin, ipaddr, port)
snapshot(coin, height)
snapshot_balance(coin, height, addresses[])
dividends(coin, height, <args>)
stop()

Кроме того, монеты с отличающимися механизмами построения транзакций на низком уровне, а также с отличающейся структурой блоков, также приводятся к универсальной модели монеты. Другими словами, вне зависимости от внутренней реализации, устройства монеты, в рамках единой модели API, достаточно указать название (symbol) монеты, чтобы получить ответ от API. Протокол Bitcoin необходим (речь идет о кошельках, демонах монет, которые вы будете использовать), но даже более старые кошельки (монеты) без поддержки опкода CLTV могут работать совместно с barterDEX.

Требования к монете в основном режиме (native mode) состоят в том, чтобы barterDEX имел возможность получить ответ на вызов gettxout через RPC и если он имеет CLTV опкод - он может быть как liquidity provider (bob), так и liquidity taker (alice). Для монеты использующих SPV на даный момент поддреживается только liquidity taking, в силу производительности сети. Кроме того, логика заключается в том, что любой кто серьезно относится к торговле, должен быть достаточно серьезным, чтобы запустить полные кошельки монет, которыми он торгует.

(Примечание: Если вы никогда раньше не сталкивались с технологией атомарных свопов, не представляете кто такие bob и alice, не знакомы с терминами liquidity provider и liquidity taker, рекомендуется посмотреть следующее видео - Show & Tell: XCAT (Zcash & Bitcoin) , иллюстрирующее безопасный обмен монетами между блокчейнами ZCash и Bitcoin при помощи XCAT. barterDEX фактически реализует примерно аналогичную схему обмена, но распространяющуюся не на какие-то два конкретные блокчейна, а фактически на все монеты, которые вы используете в SPV кошельке или для которых у вас запущены полные узлы.)

Прежде чем мы перейдем к деталям атомарных свопов, есть еще один аспект barterDEX, который является довольно важным - это децентрализованный orderbook (orderbook - дословно это "книга заказов", содержащая ордеры на покупку и продажу, т.е. bids и asks). Для реализации этого, barterDEX создает собственную децентрализованную p2p сеть, которая имеет аналоги полного ретрансляционного узла и узла, который не задействован в ретрансляции. Общая нагрузка на эту сеть минимизируется благодаря использованию комбинации иерархической передачи книги заказов (orderbook) вместе с выборкой данных. Кроме этого, существует несколько различных способов получения данных для увеличения числа узлов, которые могут полностью быть подключены к сети barterDEX.

Следует отметить, что существует возможность создания полностью отдельного набора узлов barterDEX, путем создания сети с полностью независимым набором seed узлов. Это позволяет масштабировать сеть barterDEX на произвольные уровни, поскольку, если достигнут какой-либо предел масштабирования, возникает вопрос о создании отдельной сети, которая напрямую не соединяется с другой. При таком масштабировании строится предположение о том, что каждая книга заказов (orderbook) имеет большое количество ордеров, особенно если разбиение производится на основе каждой монеты. В случае, когда желательно переходить между различными книгами заказов из различных сетей, можно было бы иметь специализированные узлы-мосты (bridge nodes), которые осуществляли бы избирательный выбор (cherry pick) нужных записей из одной сети в другую.

Поскольку адресация в сети barterDEX осуществляется с использованием публичного ключа curve25519, IP адрес узла не имеет никакого значения, а для не-ретрансляционных узлов он не является частью какого-либо пакета протокола barterDEX. Таким образом ваш IP адрес никак не фиксируется на уровне самого протокола обмена в barterDEX, однако, не исключена возможность существования "вредоносного ретрансляционного узла" в сети, который будет контролировать IP адреса пакетов на низком уровне и осуществлять связывание IP-адреса с публичными ключами (например, в целях логирования и попытки определения IP адресов участников транзакций). Так или иначе, barterDEX - это биржа основанная на блокчейне (распределенном реестре), который сам по себе является публичным, т.е. все транзакции в нем прозрачны и доступны для просмотра другим пользователям. Не стоит думать что barterDEX обеспечивает полностью конфеденциальный обмен, для обеспечения конфенденциальности - используйте JUMBLR.

(Примечание: Речь идет о том, что никакие части протокола barterDEX не включают в себя информацию об IP адресах источников или получателей транзакций, однако, как и любая система построенная на блокчейне, barterDEX не гарантирует полной анонимности или конфеденциальности ваших транзакций, также, например, как и в блокчейне Bitcoin существует возможность просмотра информации по любым транзакциям связанным с определенным адресом, также и в barterDEX информация об определенном pubkey является публичной, т.к. она является частью блокчейна).

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

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

Не ретрансляционный узел (non-relaying node) способен делать все то же самое, что и полный узел ретрансляции, поэтому мы ожидаем, что подавляющее большинство узлов будут не ретранслирующими узлами, и это позволит сети barterDEX масштабироваться до большого количества узлов. С 100 полными узлами могут поддерживаться тысячи нерелейных узлов, возможно, десятки тысяч, хотя пока это число не было достигнуто на практике, поэтому нам придется подождать и посмотреть, каковы на самом деле данные ограничения в реальной действительности.

Третья значительная часть barterDEX - это исходный код Iguana, который является "родительской веткой" для данной части barterDEX. Это позволяет создать "специальный кошелек", который будет контролировать все поддерживаемые монеты, с использованием полностью автономного набора исходного кода. Все транзакции протокола атомарного свопа - это пользовательские необработанные транзакции, которые подписываются с помощью кода Iguana. Используя команду API "withdraw" можно создать кошелек общего назначения, который использует barterDEX API. Он использует секретный ключ с парольной фразой, поэтому для него нет необходимости в создании отдельного wallet.dat, который бы поддерживался самим barterDEX'ом и он использует только один адрес, полученный из активного секретного ключа. Фактически - все монеты получают адрес, но адреса каждой монеты основаны на одном и том же секретном ключе.

(Примечание: возможно этот момент в официальном whitepaper написан слишком абстрактно для понимания, если пояснить смысл в двух словах, то, как вы уже поняли, barterDEX для обеспечения обмена поддерживает работу с кошельками практически всех монет, об ограничениях говорилось выше, на практике это означает то, что при работе с barterDEX вы должны придумать некую надежную секретную фразу, на основании которой будут сгенерированы приватные ключи для каждой из используемых вами монет, т.е. для каждой монеты участвующей в обмене, кошелек которой запущен у вас на ПК, на основании вашей секретной фразы будет сгенерирован специальный адрес, зависящий от этой секретной фразы, поместив средства на который вы можете начать обмен. Таким образом, если провести аналог с обычной биржей, на которой требуется регистрации, после чего вы получаете адрес той или иной монеты для размещения депозита, здесь вы просто придумываете секретную фразу и в кошельках, которые запущены у вас генерируется специальный smartaddress на основании вашей парольной фразы, который как раз и предназначен для депозита средств, которые вы планируете к обмену. Таким образом, средства предназначенные для обмена находятся на вашем локальном кошельке, а доступ к ним осуществляется при помощи назначенной вами секретной фразы. Например, если вы имеете несколько локальных кошельков: BTC, KMD, ZEC и т.п., то при вводе парольной фразы из barterDEX в кошельке каждой из этих монет будет сгенерировано по одному специальному smartaddress'у, соответствующему введенной вами парольной фразе. И именно на эти адреса, владельцем которых являетесь вы сами, вы и размещаете депозит.)

Средства, размещенные как депозит на данном smartaddress'е автоматически становятся доступными для торговли. Обратите внимание, что все средства доступны только пользователю с парольной фразой и что его секретный ключ импортируется в любые локальные кошельки. Это позволяет использовать обычный кошелек (coin daemon) для совершения транзакций, однако, необходимо быть осторожным, чтобы не использовать тот же самый utxo, который использовался начатым обменом.

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

barterDEX реализует протокол Tier Nolan'а, так как описано в соответствующей ветке Atomic swaps using cut and choose на Bitcointalk. Хотя описание протокола в данной ветке довольно техническое, оно дает довольно хорошее представление о том, почему для реализации обмена были выбраны именно атомарные сфопы. Важно отметить, что на каждом этапе / шаге данного протокола есть различные предпосылки / препятствия для перехода к следующему шагу и что независимо от того на каком этапе протокол обмена завершает свобй работу, каждая сторона в конечном итоге получает то, что она должна получить. Понимание заключается в том, что если вы не будете следовать протоколу, в конечном итоге вы заплатите штраф.

Для достижения этого liquidity provider (в данном случае под liquidity provider имеется ввиду собственник неких активов, или проще говоря продавец, liquidity taker в данном контексте - это покупатель, т.е. лицо желающее приобрести какие-либо активы, однако, данные определения возможно не являются точными в полной мере, поэтому здесь и далее по тексту я буду употреблять оригинальные определения, а именно liquidity provider и liquidity taker, при чтении для упрощения можно воспринимать их как "продавец" и "покупатель" соответственно), которого мы будем называть Боб, должен сделать депозит, для обеспечения завершения протокола обмена с его стороны. Это означает что Бобу необходимо два различных utxo (два различных непотраченных выхода) для совершения атомарного свопа, Элис, также нуждается в двух utxo, но ее дополнительным utxo является dexfee ("комиссия"), которая требуется для обеспечения защиты orderbook'а от "спама". Без этого Элис могла бы инициировать неограниченное количество атомарных свопов, и Бобы просто бы "застряли" / "подвисли", ожидая истечения срока, чтобы получить возмещение своего депозита. С введением dexfee существуют определенные финансовые затраты и для Элис нет никакой финансовой выгода для подобного поведения, это позволяет ожидать, что никто не будет преднамеренно "спамить" в orderbook несуществующими сделками, т.к. начало каждой сделки сопряжено с расходами на dexfee.

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

1. Alice посылает dexfee.

2. Bob посылает bobdeposit.

3. Alice посылает alicepayment.

4. Bob посылает bobpayment.

5. Alice тратит bobpayment.

6. Bob тратит alicepayment.

7. Bob возвращает собственный deposit.

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

Давайте посмотрим, что произойдет если обмен просто остановится на определенном шаге:

1. Alice отправляет dexfee. Если Боб не отправляет свой bobdeposit, у Alice отсутствует dexfee, которая составляет 1/777 от суммы транзакции. Это создает плохую репутацию Бобу и очень быстро никто не будет торговать с Бобом. До тех пор пока частота с которой Боб не вносит bobdeposit низкая, дополнительный dexfee со стороны Alice не является значительной проблемой. Предусмотрены дополнительные планы по обеспечению возврата средств, если узел Alice испытывает существенные материальные убытки, ввиду "пропавших" dexfee.

2. Боб отправляет bobdeposit. Если Alice не отправляет alicepayment, то она теряет не только dexfee, но и получает плохую репутацию, и вскоре никто не будет торговать с Alice. Благодаря этому мы не ожидаем, что подобная ситуация будет происходить часто.

3. Alice отправляет alicepayment. Если Боб не отправляет платеж, через 4 часа, Alice может затребовать bobdeposit, что на 12.5% больше, чем платеж, так что для Alice все заканчивается отличным бонусом в этом случае. Я не удивлюсь если узлы Alice будут стремиться к этому случаю протокола атомарного свопа.

4. Боб отправляет bobpayment. Если Alice не тратит bobpayment, тогда через два часа он может вернуть свой платеж, а еще через 4 часа и свой депозит. Как только Боб возвращает свой депозит, Alice может вернуть свой платеж. Все это взаимосвязано, так, что трата каждой конкретной транзакции позволяет другой стороне израсходовать свою сторону (свою часть, участвующую в процессе обмена).

5. Alice тратит bobpayment. Если Боб не тратит alicepayment, Alice фактически уже завершила сделку и от нее больше ничего не требуется. Боб спит и не расходует alicepayment, тогда он выходит из alicepayment, пока не потратит его. Это зависит от Боба, но это немного опасно, как если бы он возвращал свой депозит до того как потратить alicepayment. Alice получит всю необходимую информацию для возврата ее alicepayment. Важно, чтобы оба участника продолжали работу по протоколу атомарного свопа, пока он не завершится. Если Боб через 4 часа все еще спит, Alice может затребовать депозит и станет "счастливым туристом". Однако, трата депозита Боба не дает ей информации необходимой для возврата ее собственно платежа, таким образом Боб все еще способен сделать это (потратить alicepayment), когда он проснется.

(Примечание: довольно запутанное объяснение, однако, если упрощенно, то все сводится к простому факту - каждый из участников обмена перед его совершением вносит некую конкретную комиссию dexfee и bobdeposit, помимо основного payment, данная комиссия служит гарантом завершения сделки, и если одна из сторон по каким-то причинам выходит нарушает протокол обмена, то другая может потребовать эту комиссию, при этом основные средства участвующие в обмене останутся на своих прежних местах. Другими словами нарушение протокола обмена одной из сторон сводится к ухудшению ее репутации и потери комиссии за участие в обмене).

6. Боб расходует alicepayment. Как и в случае выше, если Боб не возвращает свой депозит - это чисто его потеря и его ответственность. Если через 4 часа он все еще не попытался вернуть депозит, тогда Alice может претендовать на него.

7. Боб возвращает свой депозит. Как вы можете видеть, на каждом шаге сторона, которая должна что-то сделать, мотивирована сделать это как можно быстрее к окончанию протокола обмена.

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

Попробую пояснить все это на примере, как это понимаю лично я:

Предположим что Alice и Боб хотят совершить обмен 1 COIN1 на 1 COIN2. Для простоты предположим что курс обмена между COIN1 и COIN2 - 1:1, т.е. 1 COIN1 = 1 COIN2. У Alice есть 1 COIN1, которые она хочет поменять на COIN2, а у Боба есть 1 COIN2, которые он хочет продать за COIN1. В этом случае порядок совершения обмена будет следующим:

1. Alice отправляет dexfee = 1/777 COIN1 = 0,001287001 COIN1.

2. Боб посылает bobdeposit = 1,125 COIN1 (9/8 от payment). Обратите внимание, что dexfee и bobdeposit вносятся в монете COIN1.

3. alicepayment = 1 COIN1

4. bobpayment = 1 COIN2 (как вы уже поняли, Alice вносит dexfee, а Боб отправляет в качестве bobdeposit 1.125 COIN1, несмотря на то что он хотел обменять 1 COIN2, т.е. Боб для совершения обмена должен иметь как COIN1, так и COIN2 монеты, но зато он не платит dexfee).

5. Alice тратит bobpayment = 1 COIN2.

6. Боб тратит alicepayment = 1 COIN1.

7. Боб возвращает bobdeposit.

Резонный вопрос - куда уходит dexfee? Эта fee аккумулируется и периодически распределяется между холдерами токена / ассетчейна DEX, всего в природе существует 1.000.000 токенов DEX. Т.е. barterDEX является децентрализованной биржей не только в плане обмена, но в плане владения DEX-токенами. Их владельцы как раз и получают dexfee от всех проиведенных на бирже обменов.)

barterDEX реализует все вышеперечисленное на многих платформах, т.е. фактически barterDEX является кроссплатформенным приложением, при этом он поддерживает сотни различных монет, с использованием родных coin daemon'ов (кошельков полных узлов), либо SPV-серверы Electrum. Обмен, который не завершен в течении одного сеанса, может быть завершен до тех пор, пока barterDEX запущен до истчения времени. Другими словами, лучше не торговать большими суммами, если вы не уверены в надежности вашего узла, особенно в интернет-соединении.

Верите вы или нет, использование вышеописанного протокола атомарного свопа со всеми криптографическими проверками между ничими вместе с обменом разлиными ключами и т.п. составляет менее половины всей сложности barterDEX. Проще говоря, относительно легко осуществить атомарный своп между двумя изолированными тестовыми узлами с тщательно подготовленными utxos, сделанными специально для теста. И совсем другое - позволить кому-либо начать с торговать с другой стороной, и добиться работоспособности таких вещей как книга заказов (orderbook) и сопоставление ордеров (ordermaching). Из-за природы p2p сетей, невозможно изначально гарантировать успешный обмен, однако неудавшийся обмен на старте - это всего лишь несколько секунд потерянного времени и нет никаких затрат чтобы попытаться начать обмен еще раз. Как и в обычной торговле - нет никакой гарантии, что вы сможете получить ту сделку, которую хотите (совершить обмен с указанными вами условиями), аналогично подобных гарантий нет и с barterDEX.

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

Теперь, когда мы узнали о протоколе атомарного свопа больше, давайте рассмотрим процесс обмена чуть подробнее. Чтобы начать атомарный своп (обмен), нам необходима пара utxo от Alice, чтобы создать dexfee и alicepayment и аналогично со стороны Боба, для создания bobdeposit и bobpayment. barterDEX необходимо чтобы все четыре из этих utxos были указаны до начала процесса обмена.

Здесь возникает первая "пользовательская проблема". Большинство пользователей даже не знают что такое utxo (непотраченный выход) и большинство из них считают свой баланс единым блоком монет, который они могут потратить на уровне одного "сатоши" (минимальной единицы измерения данной конкретной монеты). Реальность заключается в том, что протокол bitcoin'а и других монет поддерживает список неизрасходованных транзакционных выходов (utxo) с определенными значениями и для совершения транзакции необходимо чтобы входы были достаточными для оплаты выходов. Любое превышение переходит в изменение выхода (давайте не будем игнорировать txfee на данный момент, хотя barterDEX автоматически вычисляет текущий BTC txfee для совершения платежа, чтобы транзакция подтвердилась достаточно быстро).

Указывать пользователю какую именно utxo пару использовать нецелесообразно, и Alice может даже не знать какие именно utxo доступны в распоряжении у Боба на момент заключения сделки. Для этого в barterDEX предусмотрен протокол согласования атомарных свопов, который работает следующим образом:

1. Alice отправляет запрос ("request") конкретному Бобу с ее парой utxos, ценой и объемом (количеством монет. подлежащими обмену).

2. Боб проверяет запрос Alice, чтобы убедиться что, что utxo Alice действительны и что указанная ей цена является преемлемой для него, затем Боб сканирует все свои utxos для наиболее эффективного создания, как bobpayment, так и bobdeposit utxo выходов. Ограничение состоит в том, что они должны соответствовать цене, которую Alice хочет заплатить, а объем (volume) и депозит (deposit) не менее чем на 12.5% больше, чем оплата. Если все это выполнено, Боб отправляет обратно "зарезервированный" ("reserved") пакет Alice. Делая это вовремя, Боб минимизирует средства, которые связаны с размещением депозита.

3. Alice проверяет "reserved" ("зарезервированный") пакет от Боба, удостоверяясь что все utxo действительны, цена и объемы преемлемы, и если это так, отправляет пакет "connect" для Боба с теми же параметрами что и в "reserved" пакете. Между отправленным запросом "request" и "reserved" пакетами или 10-ти секундным таймаутом Alice не разрешается делать какие-либо другие торговые запросы. Важно убедиться, что текущий ожидающий атомарный своп правильно запущен, И это ограничение также является одной из ключевых частей в организации dICO.

4. Боб проверяет "connect", полученный от Alice и если все хорошо запускает новый поток для атомарного свопа.

5. Alice получает "connect" и если все хорошо также запускает для осуществления обмена.

Существует еще один шаг "переговоров", который необходим между Alice и Бобом, и хотя он мог быть частью одного из 5-ти шагов перечисленных выше, из-за устаревших причин он оказался внтури самого протокола атомарного свопа. В случае отсутствия консенсуа в отношении подтверждений в блокчейнах монет - атомарный своп прерывается без отправки каких-либо платежей. Как говорится, хорошо, что все хорошо кончается - раз нет платежей, значит и нет никаких проблем.

Поскольку barterDEX осуществляет операции с настоящими монетами, а не просто обновляет внутреннюю базу данных (или баланс прокси-токенов для прокси-сервера DEX), обе стороны должны ждать подтверждения монет до уровня, который преемлем для них. Поскольку платежи отправленные в одном блокчейне не будут преобразованы, пока платежи в другом блокчейне будут, важно иметь достаточное количество подтверждений для завершения всей сделки (?). Для установки количества подтверждений существует метод специальный метод API - setconfirms, который может быть вызван для каждой монеты. Это нужно сделать до начала протокола атомарного свопа, т.е. до фактического начала обмена, так как текущие numconfirms (количество подтверждений) также отсылаются на другую сторону. При осуществелении обмена будут использоваться наибольшее значение из тех, которые будут установлены Alice, либо Бобом. Также существует значение maxconfirms, чтобы предотвратить одну из сторон от установки чрезмерно большого значения подтверждений, такого например, как 100 подтверждений в блокчейне BTC.

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

Также здесь предусмотрен один "экстремальный режим", в котором число подтверждений может быть установлено в ноль (zeroconf mode). Сейчас это довольно рискованно, особенно для монет имеющих быстрое время блока с низким хешрейтом. Однако, для внутреннего тестирования или торговли между между друзьями (доверенными узлами) становится намного интереснее увидеть завершение атомарного свопа от начала до конца за 13 секунд. Идея заключается в том, что между людьми, которые согласны делать все правильно в случае неожиданной реорганизации блокчейна, если люди доверяют друг-другу настолько, что другая сторона будет делать то что нужно, чтобы все исправить, тогда режим zeroconf может быть разрешен. Существует специальный trust api, чтобы установить положительное доверие. Если для узла, наооборот, установлено отрицательное значение, то его pubkey добавляется в черный список.

Последним аспектом процесса сопоставления ордеров (ordermatch process) является метрика реального времени (RTmetrics), которая используется для фильтрации возможных кандидатов для сопоставления. Все узлы отслеживают глобальную статистику через файл stats.log, и это позволяет каждому узлу обновлять список ожидающих свопов. Используя эту информацию, узлам которые заняты присваивается меньший приоритет. Кроме того, Alice отдает меньше предпочтений Бобу, у которго нет нужного диапазона utxo в книге заказов. Эта часть все еще довольно нована и может быть улучшена в следующей версии (итерации) barterDEX.

Сейчас мы рассматривали весь процесс "задом наперед" - от деталей реализации атомарного свопа к процессу сопоставления ордеров и теперь настало время рассмотреть механизм эффективного распространения книг заказов (orderbook'ов), т.к. это единственная часть которую осталось описать. barterDEX использует соответствие base/rel, подразумевающее что базовая валюта (base) выражена по отношению к относительной (rel) валюте. Покупка base/rel означает использование rel валюты для покупки базовой (base) валюты, при этом цена в данном случае выражена в соотношении base/rel. В этом документе - full_swap.odt подробно разъясняется что есть base, а что есть rel на примере реального обмена KMD ->REVS.

Чтобы построить книгу заказов (orderbook), узел должен иметь информацию о ценах и поскольку все основано на публичном ключе (pubkey), это означает цену полученную от определенного pubkey. В конечном итоге необходим определенный txid/vout (utxo), но один узел может иметь сотни различных utxo, что может сказаться на пропускной способности сети, если распространять эту информацию глобально, между всеми узлами сети. Поэтому barterDEX использует иерархическую книгу заказов (orderbook), где ее скелетом является только - pubkey/цена для конкретной пары base/rel. Обратите внимание, что покупка base/rel по указанной цене - это то же самое что продажа rel/base по цене 1/price. Таким образом все что необходимо для заполнения скелета (основы) книги заказов - это узел, который будет транслировать свой публичный ключ и цену для пары base/rel. Учитывая это, узлы на которых запущен локальный кошелек (daemon) монеты, могут мгновенно найти возможный список выходов utxo через listunspent. Упс ... Узлы Bitcoin не полностью осуществляют индексацию по адресу, так что на самом деле это недоступный сервис и для узла также необходимо передавать свой список utxo и это делается в фоновом режиме по требованию.

Критическая информация полностью подписана, чтобы предотвратить подмену (spoofing), поэтому все узлы могут проверять адрес (smartaddress), связанный с pubkey, а также то, что цена которую вы передаете является действительной ценой. Монеты Electrum SPV выполняют специальную проверку SPV для всех utxo, прежде чем они будут одобрены для торговли.

Если бы все узлы всегда транслировали все свои utxos всем, это быстро приводило бы к перегрузке. В большинстве случаев barterDEX просто полагается на pubkey/цена и этого достаточно для создания книг заказов, которые могут быть использованы. Посколько существует N*N возможных книг заказов по N валютам, нецелесообразно обновлять все возможные книги заказов, вместо этого они создаются по запросу из необработанных данных. Во время создания книги заказов (orderbook), если верхние записи в книге заказов не имеют каких-либо данных listunspent, запрос для них осуществляется к сети.

Этот процесс гарантирует, что к моменту совершения сделки уже запрошен соответствующий orderbook, который в свою очередь запрашивает данные по неизрасходованным выходам (listunspent) для наиболее вероятных публичных ключей (pubkeys). Фактически процесс сопоставления ордеров (ordermatch process) затем повторяется через книгу заказов, просматривая все локальные utxo, чтобы найти контрагента которому можно сделать предложение "request" с высокой вероятностью. На практике мы наблюдаем почти мгновенный ответ, если все условия правильно выполнены.

Все вышеописанное представляет небольшие итоги того, что уже реализовано и уже работает в barterDEX. Детали могут быть изменены, но по состоянию на 29 октября 2017 года barterDEX достиг полной готовности в плане своего функционала на уровне ядра для готовящегося Monaize dICO. Предстоящее dICO будет "пробным шаром" с потенциально большим количеством атомных свопов, вызываемых одновременно. Текущие стресс-тесты показывают, что ожидаемая нагрузка будет обработана, единственные проблемы будут, если мы получим неожиданно большие объемы ...

(Примечание: ядром barterDEX является marketmaker, который фактически представляет собой консольное приложение / демон / сервис, обращение к API которого осущетсвляется посредством RPC-JSON запросов на выделенный для этих целей TCP порт).

barterDEX будет продолжать развиваться и текущая версия определила несколько областей улучшения для следующей версии. С несколькими различными GUI, которые строятся поверх barterDEX 1.0 api, новые версии будут поддерживать обратную совместимость в API.