Модель эскроу KeyShield – криптосделки в безопасной системе. Техническая реализация на основе математики, а не гарантов

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

Гарантированно безопасные криптосделки могут быть технически воплощены в жизнь за счет кошельков с мультиподписями, Node.js, продвинутых контрактов и TronWeb v5. Предлагаем разобраться в коде и логике девелопмента платформы формата P2P, где даже у администраторов не будет шансов поживиться пользовательскими денежками. Мы покажем, каким образом подобная система, внутри которой даже у распорядителей нет доступа к клиентским средствам, может функционировать в сфере обслуживания взаиморасчетов между рядовыми криптовладельцами.

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

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

Схема обмена под контролем стороннего наблюдателя выглядит следующим образом:

1. На площадке P2P покупающая сторона определяется с условиями, сроками, суммой, порядком платежа и выставляет объявление.

2. Далее покупатель направляет свои активы на временное хранение на баланс посредника.

3. После этого исполнитель/продавец выполняет заказ.

4. Заказчик принимает результат сделки.

5. Медиатор производит платеж исполнителю/продавцу.

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

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

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

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

Однако отличия есть и они существенны:

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

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

Технология минимизированного доверия уже существует. Она нашла свое воплощение в кошельках с мультиподписями. Чтобы автоматизировать процессы, такие системы управляются несколькими закрытыми ключами (2-3 – минимум). Таким образом, появляется возможность отхода от схемы с единой контрольной точкой. В работу включаются несколько сторон, что диверсифицирует управление средствами. Если другие участники не дадут своего согласия, ни одна из сторон присвоить деньги не может.

По объему USDT TRON является крупнейшим блокчейном. Через него перетекает свыше половины всего мирового предложения этих долларобеспеченных стейблкойнов, подчиненных стандарту TRC-20. К тому же сеть отличается минимальным комиссионным отягощением, исчисляемым долями цента, в то время как Эфириум может забирать до 20 USD. На одобрение блока у той системы уходит всего 3 секунды. Разработчики любят эту криптоинфраструктуру за ее доступность и удобство. Здесь не требуется отдельный продвинутый контракт для поддержки мультиподписи – все сделано на уровне пользовательского профиля.

В рамках мегапопулярного мессенджера уже проводится множество обменов в P2P формате. Заказчикам здесь комфортно договариваться с исполнителями. Телеграм располагает собственным криптовалютным кошельком, благодаря чему платежи на платформе становятся все более привычным делом. Благодаря наличию Telegram Web Apps не возникает проблем с прорисовкой нормального фронтенда на JS/HTML. Продукт KeyShield представлен в виде криптобота.

Но требуется интегрироваться в сообщества и площадки P2P. Для данной цели проект пользуется бесплатными стабильными провайдерами API TronGrid. Ведется работа с сервисом FeeSaver, сдающим в аренду энергию. В планах команды:

· Подключение криптокошельковых служб TrustWallet, TronLink, SafePal.

· Сотрудничество с цифробиржами Binance, Bybit, OKX.

· Интеграция эскроу-сервиса на площадки P2P.

· Создание плагина для безопасных взаиморасчетов на платформе для фрилансеров.

В блокчейне TRON под каждую конкретную криптосделку генерируется уникальный эскроу-адрес, с тремя подписантами.

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

Криптосделка протекает под управлением трех приват-допусков:

· первый – у покупателя;

· второй – у продающей стороны;

· третий – у сервиса-арбитра.

Пользовательские приват-ключи производятся в автоматическом режиме. Для того чтобы их зафиксировать у клиента есть всего минута. Эти пароли не направляются на хранение в базу данных, а мгновенно стираются, поэтому их нет ни в памяти, ни в логах. От пользователя нужен лишь минимум доверия на момент, когда идет генерация. Зато потом полностью исключается доступ администрации. Приват-ключи хранятся под флажком «select: false», так как после первого назначения моментально удаляются.

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

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

Вот таким образом воплощается в действительность модель кошельков с мультиподписью в пределах базы данных:

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

Предлагаем вашему вниманию диаграмму базовых состояний:

На последовательность клиентских HTTP-запросов полагаться категорически противопоказано. Здесь могут появляться дубли, да и порядок их может быть хаотичным.

Центром архитектуры выступает состояние заблокированных средств. До того, как дензнаки будут заморожены, операция представляет собой запись, внесенную в информационную базу MongoDB. Как только криптосделка переходит в блокированное состояние, она преобразуется в умный контракт в блокчейне. Теперь условия не подлежат переписыванию. На случай, если продавец исчезнет, на сервере запускается отсчет времени автоматического возврата.

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

Может включать в себя от 8 до 10 шагов:

· Вы выбираете, как хотите выступить – покупателем или продавцом.

· Определяетесь с методом – через имя пользователя или пригласительную ссылку.

· Указываете контрагента.

· Вносите название товара или сервиса.

· Описываете все в 20 символах.

· Выбираете цифроактив, в роли которого выступает USDT в стандарте TRC-20.

· Указываете сумму, которая не может быть менее 50 USDT.

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

· Указываете сроки выполнения сделки – сутки, двое, трое, неделя, две недели.

· Назначаете криптокошелек. Вы можете использовать адрес, который уже задействовали ранее, или назначить новые реквизиты.

Так выглядит готовая покупающая криптосделка:

Другой участник сделки либо переходит по ссылке-приглашению, либо получает соответствующее уведомление. Контрагенту нужно будет:

· Указать личный цифрокошелек.

· Получить приват-доступ, который показывается единожды.

На адрес, защищенный мультиподписью, покупатель перечисляет стейблкойны:

· Обнаружение криптоперевода системой выполняется автоматически.

· Средства блокируются, как только поступает подтверждение. Им присваивается статус «locked».

· Участникам сделки направляются соответствующие уведомления.

· После того, как продавец справляется с выполнением заказа, ему нужно инициировать опцию «Работа выполнена».

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

· Вводится личный приват-ключ.

· Система приступает к формированию транзакции, ставит подпись и направляет операцию в блокчейн.

· На криптокошелек продавца поступают средства.

· Сервис в автоматическом порядке получает свои комиссионные отчисления.

· Сторонам процесса отсылаются ссылки на TronScan.

Спроектированы алгоритмы создания и отправки транзоперации следующим образом:

Платформа TRON является публичной сетью. Воспользовавшись службой TRON BlockChain Explorer, вы можете убедиться, что денежные средства находятся на электронном счете, который создавался непосредственно под эту конкретную криптосделку. Вы никак не ограничены в отношении того, каким кошельком или биржей воспользоваться, чтобы перечислить USDT.

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

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

· получает перечень криптоопераций, пребывающих в состоянии «ожидание депозита»;

· запрашивает на TronGrid перечисления, поступающие в стейблкойнах (для каждой криптосделки), в лимитированном формате – максимум 8 запросов в секунду.

· проверяет сумму и, установив ее достаточность, записывает транзоперацию, приводит цифрокошелек в активное состояние и направляет сторонам процесс уведомления.

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

· для получения криптосделок, временные сроки по которым истекли;

· для уведомления обеих сторон о скором истечении срока исполнения (стороны получаю 12 часов на какие-либо действия).

Если сроки истекли и истекли дополнительные 12 часов:

· Производится автоматическая выплата продавцу, если он справился и сдал задание.

· Производится автоматический возврат средств покупателю, если исполнитель не справился и не сдал задание.

Если один из участников не согласен доводить до завершения криптосделку, инициируется старт алгоритм разрешения спорной ситуации. Тогда:

· Кто-то из участников открывает спор.

· Оставлять комментарии имеют право обе стороны.

· Доказательством и принятием решения занимается арбитр.

· Тот, кто по решению арбитра признается победителем в споре, получает средства, введя свой приват-ключ.

· На счетчике поражений проигравшего спорщика добавляется единичка.

Пользователю, проигравшему три спора, грозит отправка в бан. Такое решение позволяет системе защититься от проблемных участников.

Без технических гарантий сформировать архитектуру безопасной криптосделки невозможно:

· Прозрачность и проверяемость обеспечивают такие инструменты, как TRON и TronScan.

· Защищенность средств от единоличного неправомерного присвоения обеспечивается система мультиподписей.

· Ни посредник, ни контрагент не имеют доступа к приват-ключу третьего участника.

· Обнаружение пользовательских депозитов осуществляется без подтверждения.

· Деньгу будут возвращены покупателю, если продавец не смог или не захотел выполнять свои обязательства.

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

· Пользователь отправляет команду /start.

· На каждом этапе криптобот переписывает только единственное сообщение.

Все это реализовано следующим образом:

· Навигация аналогична мобильному приложению. В истории сохраняется каждый экран.

· Вернуться к предыдущему экрану можно кнопкой «Назад». При этом введенные данные никуда не пропадают.

· Чат остается незасоренным, поскольку удаление сообщений происходит непосредственно после обработки – работает механизм автоматизированного удаления ввода.

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

Пример UX-потока:

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

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

Мы делимся только проверенной информацией, помогаем и поддерживаем на каждом шагу. Присоединяйтесь к нам в Telegram по кнопке ниже: