Зачем идти в обход, когда можно срезать?
Вы, наверное, слышали о Суэцком канале(кажется недавно об этом писали в новостях). До создания искусственного водного пути европейские корабли, доставляющие ткани и специи из Индии, должны были пройти печально известный “Кейп-Роут” - 40-дневное путешествие, покрывающее более 10 000 морских миль. Открытие канала сократило расстояние на более чем 5000 миль, сократило время до 10–12 дней и открыло новую эру морского судоходства. Меньше времени в море, меньше смертей от цинги, меньше пиратов, недоедания и разрушительных штормов. Прогресс.
И вот за окном 2021 год. Мировая капитализация крипто-рынка приближается к 2 триллионам долларов. PayPal запускает платежи в криптовалюте. Линдси Лохан шилит Трон. Рекламы Dogecoin на Super Bowl не случилось, но Илон вместо этого, в буквальном смысле, отправил его «ту зе мун». Свершилось. Крипта - это мейнстрим. Но даже сегодня получение определенных криптоактивов может стать своего рода эпическим путешествием.
Сначала вам нужно будет зарегистрироваться на одной из централизованных бирж. Там, вероятней всего, придется пройти утомительную процедуру KYC. Это не только довольно длительный процесс, но это также подразумевает дискомфортно высокий уровень доверия. Помимо необходимости передавать документы, удостоверяющие вашу личность, и другую конфиденциальную информацию (потенциально анонимной) третьей стороне, вам также придется временно предоставить им право полного управления своими крипто-активами. И точно так же, как драгоценный груз кораблей, плывущих по морскому пути из Индии, делал их огромным соблазном для пиратов, так и большая концентрация криптоактивов на биржах делает их привлекательными для хакеров.
Таким образом, использование централизованного обмена может быть медленным и дорогостоящим процессом, требующим передачи ваших денег и документов третьему лицу. Это работает, но не идеально. И на заре новой децентрализованной эпохи, обещающей индивидуальный финансовый суверенитет, такое решение смотрится как довольно устаревший способ ведения дел. Было бы неплохо иметь возможность выбирать более прямой маршрут, а значит, использовать более быструю и безопасную форму обмена.
Что такое Atomic Swaps?
Существует некоторая неопределенность в отношении термина Atomic Swap, поэтому для этой статьи мы сразу определим его как операцию, в которой задействованы две криптовалюты, каждая из которых имеет свой нативный блокчейн и техническую возможность создавать безопасные операции обмена между пользователями сети, не прибегая к услугам trusted third party и не доверяя друг другу. Например если Zano и Bitcoin имеют поддержку atomic swaps, то пользователи могут безопасно совершать обмен Zano на BTC. Операция называется atomic, потому что подразумевает что вся процедура не может остановиться на полпути, переведя только часть монет, она или происходит полностью и обе стороны получают ожидаемые монеты или же она не происходит совсем и обе стороны остаются при своих монетах. Таких образом ни одна из сторон не может смошенничать ни на каком из этапов сделки.
HTLC
В основе механизма atomic swap лежит так называемый HTLC(Hash-Time Locked Contract). Этот контракт можно условно перевести на человеческий язык таким образом:
Если прошло времени меньше чем Т, то перевести N монет на адрес A при условии предоставления секрета, хеш которого равен H. Если прошло времени больше чем Т, и за это время секрет не предоставлен, то перевести (вернуть) деньги на адрес B.
Другими словам, выход транзакции, заданный как HTLC, может быть потрачен получателем только, если отправитель сообщит ему секрет, и только в течение определенного времени, зафиксированного в транзакции (например, 24 часа). Если же это не произойдет в указанный период времени, то деньги будут выведены на обратный адрес отправителя.
Тот, кто создает этот контракт, придумывает секрет, но не раскрывает его, а в самом контракте указывают только адреса A, B, хеш H секрета, и период времени, в течение которого контракт может быть “открыт” с помощью секрета. То есть, если Боб (у которого адрес B) отправляет Алисе (у которой адрес A) такой контракт, то она не сможет “открыть” этот контракт и перевести себе деньги до тех пор, пока Боб не сообщит ей этот секрет.
Cross-chain Atomic Swap
Теперь, после знакомства с HTLC, опишем процесс осуществления cross-chain atomic swap между сторонами. Представим Алису и Боба. Допустим, у Алисы есть Zano(будем использовать этот проект для примера), а у Боба - BTC, и, разумеется, они хотят трейдить. Алиса и Боб договорились, что хотят поменять оговоренную сумму BTC на оговоренную сумму ZANO. У обоих участников сделки есть кошельки как в сети Bitcoin, так и в сети Zano, и оба договорились о том, что сделка должна быть завершена в течении суток.
Итак, все начинается с того, что Алиса придумывает секрет. Этот секрет будет краеугольным камнем всего процесса, поэтому важно понимать, что секрет есть только у Алисы, она его никому не раскрывает, но считает от него хеш и создает в сети Zano HTLC-транзакцию, адресованную Бобу и залоченную с помощью этого хеша. Боб не сможет воспользоваться выходом этой HTLC-транзакции пока не узнает секрет Алисы. Кроме того, в HTLC-транзакции задано условие, что она действительна только в течении суток, после чего с этой транзакции деньги можно будет вернуть только назад Алисе (и уже без предоставления секрета).
Увидев, что Алиса создала в сети Zano HTLC-транзакцию для Боба, и убедившись, что количество монет в этом контракте соответствует их с Алисой договоренности, Боб создает HTLC-транзакцию в сети Bitcoin, адресованную Алисе и содержащую оговоренное число монет BTC, и, что очень важно, залоченную именно тем же хешем, который Боб увидел в HTLC-транзакции, созданной Алисой.То есть, это хеш секрета Алисы.
Алиса убеждается в том, что количество монет в HTLC-транзакции, созданной Бобом на ее адрес в сети Bitcoin, соответствует их договоренностям, и принимает решение об исполнении сделки. Это решение по сути является тем самым атомарным моментом сделки, до него сделку можно отменить и все останутся при своих монетах (получив refund через определенное количество времени, указанное в HTLC, в нашем случае это 24 часа).
В отличие от Боба, Алиса знает секрет, хешем от которого залочен HTLC-выход транзакции в сети Bitcoin, поэтому она может создать redeem-транзакцию и вывести деньги в свой кошелек. Такая операция и будет той самой “атомарной” точкой невозврата, после этого сделка будет в техническом смысле “необратима”.
Алиса делает redeem-транзакцию.
Как только Алиса создала такую транзакцию и отправила ее в сеть Bitcoin, она раскрыла свой секрет поскольку этот секрет явно включается во вход redeem-транзакции для того, чтобы доказать, что она его знает. Этот же секрет является также локером транзакции, адресованной Бобу в сети Zano, поэтому Боб, внимательно следя за ситуацией, видит отправленную Алисой redeem-транзакцию, извлекает из нее секрет Алисы и создает соответствующую redeem-транзакцию в сети Zano:
По завершении последнего этапа Алиса и Боб получают то, о чем они договорились, при этом ни на одном из этапов ни одна сторона не сможет смошенничать. Если же любая из сторон передумала до того, как Алиса создала redeem-транзакцию и раскрыла свой секрет (в случае с Бобом до момента создания им HTLC в сети Bitcoin), то они просто ждут пока пройдет временное и предварительно оговоренное ими окно сделки. Важно иметь в виду, что timelock стороны, которая создает ответный HTLC, т.е. стороны которая не знает секрета, должен быть выбран таким образом, чтобы он закончился раньше, чем timelock стороны, инициирующей операцию HTLC первой. Если это условие не будет соблюдено, то вторая сторона (в нашем случае это Боб) может не успеть создать свою redeem транзакцию, и останется без монет.
Генетическая совместимость проектов
В описанном выше примере оба проекта имеют совершенно разную кодовую базу, и даже разные эллиптические кривые(!). К счастью, HTLC позволяют организовывать atomic swaps даже между такими “генетически” несовместимыми проектами.
Единственное, что у них должно быть общего, так это поддержка HTLC с одинаковой хеш-функцией. В подавляющем большинстве проектов для этой цели используется классека SHA-256.
Privacy considerations
В случае Bitcoin едва ли можно говорить о прайваси, но нужно прояснить особенности взаимодействия с прайвеси-блокчейном, в котором транзакции по умолчанию являются приватными. Очевидно redeem-транзакции не могут иметь anonymity set - использование mixins не имело бы никакого смысла в любом случае, поскольку всегда можно сопоставить к какому именно HTLC-выходу относится вход через проверки на соответствие хеша секрета. Поэтому связь между транзакцией с HTLC-выходом и redeem-транзакцией довольно однозначна. Кроме того, сопоставить пару транзакций HTLC-to-Redeem в сети Bitcoin для отдельно взятой операции atomic swap, связанной с соответствующей парой транзакцией в сети Zano, довольно легко, Это можно сделать, используя все тот же хеш секрета - в обоих сетях, очевидно, хеш должен быть одинаковым, поскольку для проведения операции в обоих блокчейнах использовался один и тот же секрет.
Практический пример
Для того, чтобы лучше проиллюстрировать работу atomics swaps для двух принципиально разных блокчейн проектов, мы реализовали небольшой пример под nodejs. За основу мы взяли статью и репозиторий, в которых был интересно представлен пример atomic swaps между Bitcoin и BitcoinСash. Мы существенно упростили код, чтобы продемонстрировать основные принципы, тем не менее, если у вас появится желание разобраться с работой HTLC в Bitcoin на более низком уровне, вплоть до оп-кодов, то мы рекомендуем ознакомиться с их статьей.
P2SH
В практическом примере, о котором идет речь, важно понимать концепцию P2SH, используемую на стороне Bitcoin для создания HTLC. В Bitcoin для определения конкретного способа использования выхода транзакции используется так называемый “script”(далее “скрипт”), элементарный стековый язык программирования. Причем скрипт, который определяется для конкретного выхода, на самом деле будет являться окончанием скрипта, ну а его начало должен будет предоставить тот, кто тратит этот выход (подробнее с этим можно ознакомиться в этой статье). Однако, кроме непосредственного включения “половинки” скрипта в выход, есть еще способ отправки на хеш скрипта (P2SH). Это значит, что содержание самого скрипта выхода не раскрывается до момента фактической траты выхода, а в транзакции содержится только указание, что при трате этого выхода должно быть предоставлено “окончание” скрипта, хеш от которого прописан в выходе, и “начало” скрипта, которое этот скрипт отпирает. В описываемом примере сети Bitcoin для создания HTLC используется именно такой тип выхода. Поскольку обе стороны договорились об условиях сделки и они знают свои public keys (именно public keys, а не адреса, потому что в отличие от Zano, например, в bitcoin адресом является хеш public key), то обе стороны смогут генерировать одинаковый HTLC скрипт выхода, получив один и тот же “script-хеш-адрес”(P2SH). Для одной стороны это будет “script-хеш-адрес”(P2SH), на который она отправит BTC, а для другой стороны это будет “script-хеш-адрес”(P2SH), который она будет мониторить для того, чтобы детектировать факт создания HTLC и его подтверждения сетью.
Заключение
Хотя в приведенных выше примерах мы использовали Bitcoin и Zano, atomic swaps могут выполняться между любыми цифровыми валютами, которые поддерживают HTLC. Это обеспечивает более безопасный и прямой маршрут между экосистемами Bitcoin, Bitcoin Cash, Decred, Litecoin, Qtum, Monacoin, Zano и тп. И список совместимых проектов постоянно растет.
На данный момент это инструменты низкого уровня, но они закладывают основу для гораздо большей совместимости в будущем. Мы уже предвидим создание платформ с более доступным и удобным интерфейсом, построенных на основе Atomic swaps (например, AtomicDex). Вскоре они станут настоящими децентрализованными альтернативами централизованным биржам. По мере того, как инструменты продолжают развиваться и совершенствоваться, мы можем визуализировать будущее, в котором вы сможете совершать быстрые, недорогие и надежные сделки без рисков, связанных с доверием третьей стороне.
Atomic swaps - это, прежде всего, более легкий доступ. Более легкий доступ означает большую ликвидность, а ликвидность должна быть у любого платежного инструмента.
Atomic swaps. Ликвидность. Прогресс.
PS: Материал составлен в соавторстве с участником нашего комьюнити проекта Zano - OrsonJ, за что ему огромное спасибо!
