31 декабря 2020

Путь к DashPay (Часть 1 из 4)

Публикуем личный взгляд на проект DashPay разработчика  DCG, quantumexplorer


Привет, сообщество Dash! 

Хотя я и участвовал активно в разработке Dash c 2015 года, это будет мой первый пост для Dash блога. Мы приближаемся к запуску Dash Platform и обновлению наших кошельков, которое позволит им поддерживать контракты и спецификацию DashPay. Впредь я постараюсь писать больше постов с подведением итогов работы, которую мы делаем, в более доступной форме, чем технические описания наших DIP-ов.

Поэтому сегодня я рад объявить, что мы публикуем 4 новых Предложения по улучшению Dash (DIP-ы), касающихся DashPay, и мне бы хотелось поблагодарить всех тех людей, которые сделали это возможным. Прежде чем говорить о DashPay, позвольте сначала дать вводные пояснения о Dash Platform, блокчейн-ID, контрактах данных и DPNS. Скорее всего, позднее будут опубликованы дополнительные посты, которые подробно расскажут об этих компонентах, поэтому я не буду вдаваться в детали.

 

Dash Platform

Dash Platform — это византийская отказоустойчивая система, которая обеспечивает множественное изменение состояний. Византийская отказоустойчивая система — это сеть, ноды которой могут отключаться или даже пропадать, а система будет по-прежнему работать. Для этого платформа использует нечто под названием практическая византийская отказоустойчивость (pBFT), в то время как Dash Core работает на консенсусе Накамото. Взаимодействие между консенсусом Накамото и Византийской отказоустойчивой системой — это отличная статья на Medium, которую можно прочесть, чтобы познакомиться с этими концепциями поближе. Как бы то ни было, я вкратце поясню, каким образом они применяются в Dash. 

В Dash Core достоверность информации основана на транзакциях, которые включаются в блоки, и том факте, что эти блоки были включены в блокчейн. Например, в Dash Core, если у вас есть coinbase-транзакция “А”, которая появляется в блокчейне после добычи блока, а затем транзакция “Б”, которая использует “А” в качестве входа, достоверность “Б” проистекает из того факта, что “А” была достоверной, и существует доказательство, что “владелец” “А” тратит сумму через транзакцию “Б”. 

В Dash Platform, однако, текущее состояние информации можно доказать с помощью бинарного дерева состояний Меркла. Достоверность любой информации основана на том, что её таковой считает больше, чем ⅔ мастернод сети. Это означает, что нам больше не требуется опираться на доказательство совершённых ранее транзакций, а вместо этого мы можем положиться на то, что мы называем доказательством порогового состояния. Это, в свою очередь, позволяет нам сделать некоторые довольно крутые вещи. И одна из них — это DashPay.

 

Блокчейн Platform

На этом моменте я немного остановлюсь, чтобы ответить на вопросы, которые могут возникнуть. Некоторые люди слышали, что Dash Platform использует свой собственный блокчейн, и они, возможно, не понимают, что это значит. Сразу скажу — это не означает, что там появятся дополнительные монеты. Блокчейн платформы используется для того, чтобы помочь эффективно синхронизировать данные состояний. Блоки в цепочке платформы живут недолго, так что спустя определённое время после того, как они корректно синхронизировали данные состояний, они могут и должны быть обрезаны.

Мы можем держать некоторые архивные ноды, которые будут хранить все ранние блоки, однако, такого требования для мастернод установлено не будет. В прошлом году Иван Шумков опубликовал пост в блоге, где рассказывает о причинах и обоснованиях появления блокчейна Platform Chain. Его можно найти здесь

 

Движок Консенсуса

Второй вопрос, который может возникнуть — почему мы форкнули Tendermint, чтобы использовать его в качестве нашего консенсусного движка pBFT, и что именно это значит. Вплоть до начала 2019 года мы планировали использовать для работы DashPay наш основной блокчейн Dash Core, но такой подход не обеспечивал все необходимые функции и, по сути, просто не работал.

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

 

Модификации Tendermint

Вам, возможно, любопытно, чем наш форк отличается от Tendermint? Ну, я думаю, что наиболее существенное отличие в том, что в Dash Platform используются пороговые подписи, чтобы получать эффективные доказательства для текущих состояний данных. 

Возможно, объяснение на примере будет понятнее. Представьте, что на мобильном устройстве я отправляю запрос к Dash Platform и хочу получить контакты всех людей, кто отправлял мне запрос на добавление в контакты DashPay. Эта информация хранится в базе данных “ключ-значение”, а доказательства для этой информации находятся в дереве состояний Platform.

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

Важно то, чтобы корень дерева состояний был подписан кворумом мастернод, который мобильный клиент ранее получил и которому он доверяет. За техническими подробностями, как мобильные клиенты получают и доверяют кворумам, пожалуйста обратитесь к DIP4. Наиболее важно то, что у мобильных клиентов есть механизм доверия кворуму мастернод, а также публичный пороговый ключ для этого кворума. Если более ⅔ мастернод в кворуме подписали сообщение, может быть создана пороговая подпись, которую мобильный клиент способен проверить на подлинность. 

Резюмируя всё это — если мобильный клиент получает данные, может быть доказано, что данные находятся в дереве с определённым корнем дерева. Корень дерева, в свою очередь, подписан кворумом, и клиент может проверить подлинность этой подписи. Без пороговых подписей клиенту потребовалось бы проверять все ⅔ подписей кворума. Поскольку это работало бы довольно медленно и привело бы к очень объёмным доказательствам, мы внедрили пороговые подписи.

Теперь вы можете поинтересоваться, почему команда Tendermint сама не внедрила эти пороговые подписи? Что ж, возможно, это и было в их дорожной карте, но мне бы хотелось подчеркнуть, что дальше идут всего лишь мои догадки. Я думаю, одной из самых больших трудностей для них был тот факт, что участники в их кворумах не обязательно должны быть равны. На основании количества находящейся в стейкинге криптовалюты один валидатор мог бы обладать силой голоса в два раза сильнее, чем другой. Важно то, что в оригинальном Tendermint важно иметь более ⅔ всех голосов в кворуме, а не “более ⅔ фактических нод”. Таким образом, пороговая подпись стала бы для них проблемой. В Dash, однако, во всех мастернодах хранится именно по 1000 DASH, так что у нас такой проблемы нет.

Наш форк Tendermint называется Tenderdash, и с ним можно ознакомиться здесь. Хотя я обычно работаю на мобильную команду, огромным пластом моей работы за последние несколько месяцев было внедрение пороговых подписей в Tenderdash — и это один из финальных компонентов, который нам нужен для запуска релиза в тестовой сети.

Пока я говорил в основном о консенсусе Dash Platform, потому что это имеет отношение к дальнейшим пояснениям по DashPay. Dash Platform также предоставляет доступ к данным состояний, которые хранятся на всех мастернодах, через децентрализованный HTTP API (DAPI). Этот важный компонент платформы заслуживает отдельного поста потом, а я перехожу к блокчейн-ID.

Продолжение следует…

Первоисточник: https://blog.dash.org/the-journey-to-dashpay-3e604d17814c