Продолжение…
Публикуем личный взгляд на проект DashPay разработчика DCG, quantumexplorer
DashPay
По своей сути, DashPay — это контракт данных, на основе которого работает децентрализованное приложение, создающее двусторонние каналы для прямых платежей между двумя Блокчейн-ID. Давайте разберём, что это значит. Мы уже объяснили, что контракт — это набор свойств для подтверждаемого типа документа. В DashPay есть три типа документа: профиль, запрос контакта и контактная информация.
Запрос контакта
В случае с DashPay наиболее важный тип документа — это запрос контакта. Запрос контакта — это документ, который говорит, что Блокчейн-ID A хочет “дружить” с Блокчейн-ID Б. Он также показывает, что любые платежи, которые Блокчейн-ID Б отправляет Блокчейн-ID А должны быть отправлены на ряд адресов, определяемых расширенным публичным ключом.
В текущей начальной версии DashPay все взаимоотношения между контактами публичны. Однако, сами платежи между контактами не являются публичными. Можно представить это как платёжный канал, который создаётся между двумя Блокчейн-ID и по которому можно отправлять транзакции, но при этом сами транзакции невозможно будет идентифицировать как привязанные к этому конкретному каналу. Мы называем такие каналы “каналами прямых мгновенных платежей” — в отличие от платёжных каналов, которые используются в сети Lightning у Bitcoin, и которые зачастую не получается наладить быстро. Возможно, в будущем мы позволим непрямым расчётам экономить место в блокчейне, но на данный момент мы этого не планируем.
Получение контактного адреса
Чтобы создать эти платёжные каналы, нам нужно создать детерминированный и доступный для получения уникальный набор адресов для двусторонних платежей между Блокчейн-ID в канале. Таким образом сид-фраза сможет восстановить всю информацию о платежах между Блокчейн-ID. Лично я считаю эту функцию очень полезной. Сейчас при просматривании истории своих транзакций сложно связать транзакции с фактически участвовавшими в них пользователями. После того, как DashPay станет доступен в наших кошельках, если вы будете отправлять средства от Блокчейн-ID А к Блокчейн-ID Б, эту информацию всегда можно будет получить, но только если вы являетесь Блокчейн-ID А или Блокчейн-ID Б.
Это потому, что расширенный публичный ключ, созданный для генерации адресов для платежей — шифруется между двумя Блокчейн-ID. Хотя я и говорю об адресах, эти адреса не показываются конечным пользователям в кошельке, и частично в этом заключается красота системы. Конечный пользователь, например, Боб, увидит только то, что он отправил платёж Алисе, если только он не захочет посмотреть подробную информацию о конкретной транзакции в обозревателе блоков.
Создание такого расширенного публичного ключа для платежа довольно интересно. BIP32, который определяет пути генерации адресов, используемых в HD-кошельках, допускает глубину генерации только до 31 бита, что формирует множество из примерно 2 миллионов адресов. Авторы BIP32, я уверен, не видят никаких преимуществ в генерации адресов свыше этого количества. Мы уже обсуждали тот факт, что внутреннее имя Блокчейн-ID — это 256-битный номер. Чтобы создать уникальный путь получения для платежей от Блокчейн-ID Б к Блокчейн-ID А, мы должны начать с корневого расширенного публичного ключа (который создаётся полностью на основе BIP32), затем получить номер Блокчейн-ID А, и затем — номер Блокчейн-ID Б. Проблема здесь в том, что Блокчейн-ID — 256-битные, а BIP32 поддерживает только 31 бит. Поэтому нам пришлось разрешить 256-битную глубину генерации адресов, сохраняя при этом совместимость с BIP32. DIP14 объясняет техническую реализацию этого изменения. Раздел “Путь получения входящих средств DashPay” в DIP15 объясняет, как это применяется в DashPay.
Вы можете подумать: но почему бы не сократить 256-битные номера до 31 бита и просто использовать их, чтобы всё упростить? Что ж, на самом деле, если бы вы это сделали, то система стала бы уязвима для довольно серьёзной атаки. Любой набор из 31 битов довольно легко поддается атаке методом “грубой силы” (брутфорс) и не обеспечивает достаточный уровень безопасности. Идентификатор Блокчейн-ID является доказуемо уникальным, однако, его первая или завершающая последовательности битов — нет, и можно было бы легко подобрать сопоставимые хеши даже на персональном компьютере. А если у двух Блокчейн-ID будут одинаковые биты, это приведёт к тому, что у них будет одинаковый набор входящих адресов, что может позволить пользователям шпионить за конфиденциальной информацией о транзакциях. Использование 256 битов, безусловно, защищает нас от этого.
Теперь, когда у нас есть расширенный публичный ключ, чтобы получать платежи, нам нужно зашифровать его, чтобы третьи стороны не могли видеть транзакции между Блокчейн-ID. Ключ шифрования создаётся с помощью протокола Диффи-Хеллмана на основе соответствующих ключей шифрования и дешифровки Блокчейн-ID. Шифрование расширенного публичного ключа делается с помощью CBC-AES-256 с 16-байтным инициирующим вектором, который мы добавляем при шифровании.
Многопользовательские кошельки
Запрос контакта также открывает возможности для работы многопользовательских кошельков. Например, если ваш кошелёк поддерживал бы два аккаунта, один — для работы, а другой — личный, вы могли бы создать связь своего Блокчейн-ID например с коллегой как на личном уровне, так и на профессиональном. Эта функция поддерживается на уровне контракта данных, но пока не будет представлена в DashWallet для iOS или Android, потому что они на данный момент не поддерживают несколько пользователей в одном кошельке.
Автоматическое принятие запроса на добавление в контакты
В определённых ситуациях Блокчейн-ID может захотеть принимать запросы на добавление в контакты (то есть отвечать на запрос — обратным запросом) автоматически. Например, такое может быть, когда вы даёте кому-то поблизости отсканировать свой QR-код, или же продавец даёт QR-код покупателям для оплаты. Представьте, что вы стоите рядом со своим другом и хотите стать с ним “друзьями” в DashPay. Дав ему отсканировать свой QR-код, вы становитесь “друзьями” автоматически. Вашего действия — предоставления ему QR-кода — достаточно, чтобы подтвердить своё желание принять запрос на добавление в контакты.
Хотя, я бы сказал, что эта функция больше важна для продавцов и бирж. Продавцы хотят получать платежи, не отвечая при этом на запросы о добавлении в контакты. За счёт предоставления автоматического принятия (которое является открытым), они, по сути, разрешают принимать любые запросы на добавление в контакты. Однако, это доказательство автоматического принятия не следует открыто выставлять в Интернете, а, скорее, стоит использовать его как физической QR-код, который сканируется в магазине. Скорее всего, существуют лучшие способы для принятия платежей продавцами, с менее прямолинейным подходом к платежам. Мы продолжим исследовать подходы и делать новые предложения по улучшению, насколько нам это позволят ресурсы.
Продолжение следует..
Ссылка на первую часть: https://hub.forklog.com/put-k-dashpay-chast-1-iz-4/
Первоисточник: https://blog.dash.org/the-journey-to-dashpay-3e604d17814c