Продолжение…
Публикуем личный взгляд на проект DashPay разработчика DCG, quantumexplorer
Блокчейн-ID
Определение Блокчейн-ID Dash дано в DIP11. Грубо говоря, Блокчейн-ID похож на аккаунт. В нём хранится баланс кредитов, то есть Dash (валюты), сконвертированной для оплаты изменения состояний в блокчейне Dash Platform.
В теории, Блокчейн-ID должен идентифицировать любого пользователя, будь то человек, организация, электронное устройство или даже более абстрактные сущности. Например, у холодильника мог бы быть Блокчейн-ID, который публиковал бы запросы на покупку молока, когда его остаётся мало. Холодильник бы не заказывал молоко сам, но уведомлял бы Блокчейн-ID пользователя о том, что его мало. Затем Блокчейн-ID пользователя мог бы приобрести молоко в Блокчейн-ID супермаркета, возможно, с использованием DashPay. Если говорить о нашей первой версии DashPay, Блокчейн-ID будет представлять пользователя или продавца, использующих наш кошелёк DashPay.
Блокчейн-ID также являются частью Dash Platform. Это означает, что доказательство существования и баланса Блокчейн-ID есть в дереве состояний платформы. Следовательно, мобильные клиенты могут получить доказательство существования Блокчейн-ID, как я описал выше. Эти доказательства очень важны для DashPay.
Хочу упомянуть ещё одну важную вещь — идентификатор Блокчейн-ID проистекает из транзакции финансирования, которая может быть отслежена в части своей энтропийной генерации вплоть до майнинга, доказательства работы. Я говорю об этом, потому что полезно понимать, что все части нашей системы в какой-то степени представляют собой множество слоёв, в основе которых лежит доказательство работы.
Блокчейн-ID регистрируются с привязанными ключами, которые позже можно изменить или добавить дополнительные. Эти ключи дают возможность аутентификации, шифрования и расшифровки сообщений на основе типа ключа. DIP13, который был зарелизен одновременно с этим постом, работает с Блокчейн-ID в HD-кошельках, и ключи детерминированным образом формируются из фразы восстановления (также известной, как мнемоническая или сид фраза). Исходя из этого описания, DashWallet от Dash Core Group для iOS и Android являются HD-кошельками. Предположим, что вы с ними знакомы.
Самое главное, что важно понять о DIP13 — Блокчейн-ID может быть восстановлен из фразы восстановления. Даже если вы заплатили за создание Блокчейн-ID, но ещё не зарегистрировали его на платформе Dash, его тоже можно восстановить.
DPNS
Идентификатор Блокчейн-ID — это 256-битное число. С таким не очень удобно работать, когда пытаешься кого-то найти или повзаимодействовать. На помощь приходят реестры имён! Мы пользуемся реестрами имён ежедневно. Вы пользуетесь одним из них прямо сейчас, если читаете этот пост на сайте Dash.org. То, что вы видите в строке браузера адрес blog.dash.org — это потому, что blog.dash.org указывает на соответствующий ему IP-адрес сервера, который в формате IPv4 является 128-битным числом. Если вы введёте этот IP-адрес напрямую в адресное окно своего браузера, то увидите ту же самую информацию.
Не буду сейчас глубоко погружаться в тему DPNS, поскольку я хочу сосредоточиться на DashPay, но суть в том, что DPNS используется для связывания имени, например “quantumexplorer” с соответствующим ему Блокчейн-ID. Механизмы DPNS технически объясняются в DIP12.
Контракты данных
Если вы когда-нибудь работали с базами данных, следующее объяснение должно быть вам понятнее. Чтобы данные могли храниться в базе данных, им нужно соответствовать структуре таблиц базы. Например, таблица машин содержит их определённые качества — цвет, марку, номер. В Dash Platform всё то же самое, только мы называем наши таблицы “типами документов”. Регистрация контрактов данных влечёт за собой отправку команды о переходе состояний на Platform, которая определяет один или больше типов документов.
Допустим, разработчик хочет хранить на Dash Platform расписания рейсов. Он мог бы создать тип документа “самолёт” и тип документа “рейс”. У рейса было бы назначенное время отправления и прибытия, которое соответствовало бы заданному формату меток времени с правилом, что время отправления должно быть раньше времени прибытия. Если поступают переходы состояний, которые пытаются создать новый рейс, платформа будет верифицировать структуру данных. Например, что время отправления имеет соответствующий формат, и что оно не позже, чем время прибытия.
Существуют два основных контракта, которые важны для корректной работы DashPay: контракт DPNS и контракт DashPay. Дальше в этом посте я расскажу об аспектах контракта DashPay.
Продолжение следует…
Ссылка на первую часть: https://hub.forklog.com/put-k-dashpay-chast-1-iz-4/
Первоисточник: https://blog.dash.org/the-journey-to-dashpay-3e604d17814c