X-Cash DPoPS — Технический дизайн(Yellow paper)

Перевод официальной технической документации с сайта xcash.foundation

DPoPS: Делегированное Доказательство доли Приватного Владения, реализация DPoS в X-Сash, приватно-публичной монете основанная на протоколе Monero

Guilhem Chaumont, Paul Bugnot, Zach Hildreth, Balthazar Giraux Июль 30, 2019 г.

Издание 1

Аннотация. В этом документе содержится обширное описание компонентов DPoPS, Делегированное Доказательство доли Приватного Владения в рамках X-Cash, приватно-публичной монете основанная на протоколе Monero. Изменение алгоритма консенсуса с PoW на DPoPS является значительным обновлением для блокчейна X-Cash, а также принесет инновации в CryptoNote, Monero и в общую экосистему блокчейна.

Делегированное доказательство доли владения (DPoS) — это эффективная, децентрализованная, демократичная и гибкая основа для достижения консенсуса в блокчейне, которая активно исследуется в последние годы. Однако приватный характер монеты может усложнить реализацию DPoS, поскольку балансы на кошельках скрыты. Как репрезентативная система, DPoS нуждается в правильном балансе прозрачности, чтобы оставаться эффективным, и большинство приватных монет не могут справиться с отсутствующей частью своей непрозрачности.

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

С точки зрения технической реализации было выбрано использование сочетания DPoS и делегированную византийскую схему отказоустойчивости (DBFT, как в NEO) с использованием функции проверяемого случайного числа (VRF, как в ONT) для выбора производителя блока. Поскольку X-Cash — это приватная монета, в которой скрыты остатки баланса, резервные доказательства Monero широко используются в процессе выборов.

1 Введение

В централизованной системе все стороны экосистемы относятся к принятию решений известной и доверенной третьей стороной. Общий консенсус не требуется, так как централизованный орган управляет решениями и проверкой. В децентрализованной системе (блокчейн, DLT и т.д.), достижение консенсуса является сложной задачей, поскольку каждая сторона должна согласиться с большинством по аналогичному решению, немедленно и без ошибок. Алгоритмически было разработано несколько решений для решения этой проблемы, а именно, но не ограничиваясь только этими, PoW, PoS или DPoS.

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

В последние несколько лет мы видели, как приватные PoS монеты появлялись с использованием методов смешивания и объединения, чтобы использовать приватные транзакции. Наличие приватного баланса и ставки — еще одна проблема сама по себе. Некоторые блокчейны успешно достигли частичной или полной анонимности через комбинацию доказательств резервирования и смешивания транзакций. Если конфиденциальность может быть достигнута и даже гарантируется использование алгоритма PoS, можно предположить, что в цепочке блоков можно разместить монету конфиденциальности при использовании алгоритма DPoS.

Что делает DPoS привлекательным, так это то, что он позволяет любому лицу с минимальным количеством монет принимать прямое или косвенное участие в процессе достижения консенсуса, при этом имея те же преимущества, что и алгоритм PoS — быть более энергоэффективным и гибким, быстрые транзакции и быть более защищенным от атак. В некотором смысле, DPoS позволяет большему количеству людей принимать участие в управлении блокчеином, чем PoS, и можно утверждать, что он ближе к общему принципу децентрализации, поскольку он более открыт для общественности.

Тем не менее, применение DPoS к приватной монете довольно сложная задача из-за приватного характера блокчейна. Необходимо столкнуться с теми же проблемами, что и для PoS (конфиденциальность ставок и баланс), и конфиденциальность голосования также должна быть гарантирована. Достижение консенсуса DPoS в приватной монете доказало бы, что блокчейн может быть альтернативой традиционным моделям управления, в том числе тем, которые используются вне экосистем блокчейна. В этой статье мы исследуем один из возможных путей достижения консенсуса DPoS в монете CryptoNote (CN). Этот опыт может проложить путь для Monero и других монет CN к новой модели управления.

Чтобы объяснить проблемы внедрения DPoS в приватных монетах, особенно в монетах CN, мы расскажем о структуре DPoS. Затем мы обсудим различные моменты, к которым нужно обратиться, чтобы сделать этот консенсус блокчейна применимым к приватным монетам. Наконец, мы объясним, как мы реализовали DPoPS в протоколе X-CASH.

2 Уровень развития

Существует две основные причины создания консенсуса DPoS (и PoS в некоторой степени). Дэн Лаример, в частности, ссылается на тот факт, что PoW биткоина слишком расточительный. Большая часть энергии уходит на майнинг биткоина, и, вероятно, есть другие альтернативы для достижения той же цели. Он также смотрел на повышение эффективности алгоритма. По его мнению, избыточность PoW была одним из недостатков биткоина.

DPoS разработан так, чтобы быть таким же надежным, как алгоритм PoW Биткоина, конкурентно быстрым (если возможно, таким же быстрым, как централизованная база данных бирж), оставаясь открытым и децентрализованным. Дэн Лаример успешно внедрил DPoS в BitShares, Steem и EOS. Теперь все больше и больше проектов успешно используют DPoS в качестве модели управления своей архитектурой блокчеина (Arc, Cardano, Tezos, Lisk и т.д.).

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

2.1 Производство блоков в DPoS

Основа PoW, и в некоторой степени и PoS, считается неэффективной — как с точки зрения энергопотребления, так и скорости блокчейна — в том, что вся сеть участвует в проверке блоков (например, проверка транзакций). Этот принцип — необходимый для обеспечения нейтрального и цензуростойкого создания блоков — предоставляется избранным в DPoS, которые называются производителями блоков.

2.1.1 Производство блоков и роль делегатов

Производители блоков выбираются из числа делегатов в определенное время в течение цикла производства блоков. Делегаты избираются по процедуре, при которой владельцы токенов могут отдавать свои голоса пропорционально доле избирателей в сети. Этот процесс выборов позволяет держателям токенов поручать делегату представлять их, сохраняя при этом свои активы в холодном хранилище. Particl (аналог википедии) называет это «холодная ставка». В конце каждых выборов избираются лучшие кандидаты, набравшие наибольшее количество голосов.

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

Важно отметить, что число делегатов обычно намного меньше, чем количество узлов в цепочках блоков PoW (майнеры) и PoS (стейкеры). Вот почему DPoS обычно считается более централизованный, чем консенсус конкурентов.

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

Чтобы создать блок, текущий производитель блоков обращается к узлу(ам) консенсуса, чтобы установить текущее состояние сети и проверить как блоки, так и их связь в цепочке. Это показывает, насколько важны делегаты и согласованные узлы в DPoS. В PoW биткоина, в то время как блоки могут создавать только майнеры, каждый узел в сети (полные и легкие узлы) проверяет целостность транзакций и блоков.

2.1.1 Процесс выборов и вознаграждение за блок

Процесс выбора различен в каждой цепочке блоков DPoS — начало, продолжительность и окончание процесса могут различаться в зависимости от условий и времени. Это как говорится, процесс выборов обычно идет по тому же пути. Владельцы токенов голосуют за делегата, чтобы увеличить его шансы стать производителем блоков, набрав больше голосов, чем его конкуренты. Голосование в само по себе предоставляется делегату на определенный срок и негласно восстанавливается, если избиратель не изменил свой голос. Это подразумевает, что избиратель может изменить свой голос в любое время в течение раунда в ожидании следующего тура выборов.

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

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

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

2.2 DPoS и безопасность.

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

2.2.1 Атаки внутри сети

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

Как и в PoS, система ставок помогает предотвратить появление плохих игроков в сети. В дополнение к PoW, чтобы стать производителем блоков, нужно доказать свою заинтересованность в успехе сети через механизм ставок. Основное обоснование этого процесса заключается в обеспечении того, чтобы значительная доля была обеспечена субъектами, отвечающими за достижение консенсуса. Следовательно, их механически стимулируют к тому, чтобы они вели себя так, чтобы не оказать негативного влияния на монету и блокчейн. Например, в случае двойного расходования или DDOS-атаки, выполненной делегатами, на рыночную капитализацию монеты будет оказано значительное влияние, что сделает убытки от сопутствующей девальвации более вредными, чем потенциальная прибыль от атаки. В более общем смысле, любой, кто желает получить выгоду от сети — будь то путем блочного майнинга или голосования — заинтересован в защите целостности сети посредством этого процесса обеспечения. В результате, стимул быть плохим игроком в сети значительно падает.

2.2.2 Атаки извне

Как уже говорилось, может возникнуть гипотеза, что сторонние субъекты могут извлечь выгоду из повреждения блокчейна. В PoW атака может повредить сеть через то, что известно, как «атака 51%». В этом конкретном случае необходимо контролировать 51% вычислительной мощности блокчейна. Этот тип атаки может быть уже сложно реализовать, особенно для топовых криптовалют, где дополнительно необходимый хэшрейт недоступен; либо из-за ограничения поставок аппаратного обеспечения, либо из-за недостатка ликвидности на рынках хэшрейтов, таких как NiceHash. Чем больше сеть, тем труднее становится этот тип атаки.

Потенциально, это может стать еще сложнее с консенсусом PoS / DPoS. Вместо того, чтобы иметь 51% вычислительной мощности, злоумышленнику требуется 51% запаса монет, чтобы приступить к такой атаке. Беглый взгляд на рыночную капитализацию Биткоина показывает нелепость этой идеи.

Более того, большинство DPoS повысили порог требуемой доли в сети с 51% до 67%, что делает атаку еще более дорогостоящей и, следовательно, сеть более устойчивой.

Наконец, как и любой блокчейн, DPoS должен быть на византийской схеме отказоустойчивой (BFT). В данном конкретном случае мы называем это делегированным BFT (DBFT).

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

Одна из возможных реализаций DBFT состоит в том, чтобы один или группа согласованных узлов определяли состояние цепочки блоков. Узел консенсуса является свидетельством состояния системы. Как и любой заверитель, его доказательство ставится под сомнение и сталкивается с реальностью / фактами. Независимо от того, существует ли единый или группа из 7 согласованных узлов, большинство алгоритмов DPoS предлагают децентрализованный процесс, чтобы противостоять версии истины, предложенной каждым субъектом консенсуса.

Хотя часто утверждается, что DPoS является более централизованным, чем другие типы консенсуса, из-за процесса производства блоков и наличия узлов консенсуса выбор делегатов делает это очень демократично. Как и в политике, существует очень деликатная шкала между демократией (в данном случае децентрализацией) и эффективностью, и каждый блокчейн предлагает разные концепции.

Что более очевидно, так это тот факт, что этот алгоритм консенсуса все еще находится в зачаточном состоянии, и ни один из этих проектов не имеет приватных транзакций, кроме проекта начальной стадии реализации, такого как pEOS. Ключ, цель и мотивация варианта X-Cash DPoS состоит в том, чтобы предложить альтернативную модель управления сетями, в которых работают приватные монеты.

3 DPoPS: Делегированное Доказательство доли Приватного Владения

Чтобы понять проблемы использования консенсуса DPoS в приватной монете, важно понять, какая информация защищена / скрыта в зависимости от блокчейна.

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

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

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

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

3.1 Проблемы стекинга и голосования в приватной монете

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

3.1.1. Стекинг приватной монеты: доказательство резервирования

Рисунок 2: доказательство резервирования, созданное участником сети, позволяет делать ставки, не отдавая секретный ключ

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

В отличие от систем PoW, вычислительная мощность в системе, основанной на PoS, в основном не имеет значения (включая DPoS). Консенсус PoW — это система, в которой кандидаты за нахождение блока постоянно конкурируют за вознаграждение за блок, транзакции. В PoS стать производителем блоков можно только доказав свою долю в сети. Ставка представлена минимальным количеством монет, запертых в кошельке.

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

Механизм немного меняется в консенсусе DPoS, потому что владельцы не могут напрямую стать производителем блоков. Как упоминалось ранее, делегат (производитель блоков-кандидатов) должен быть владелец монеты или должен собирать достаточно голосов, чтобы войти в список делегатов. Будь то PoS или DPoS, процесс выбора блока требует полной прозрачности количества ставок монет. Вот почему достичь консенсуса на основе доли в блокчейне приватных транзакций нелегко, не нанося ущерба конфиденциальности.

Одним из возможных решений является использование доказательство резервирования. Резервные доказательства были введены в Monero в 2018 году, что позволяет любому кошельку генерировать подтверждение суммы. До этого кто-то с Monero кошелека должен был отправить view key и signed key изображения аудитору. Отсутствие ключа просмотра не позволяет аудитору видеть все входящие переводы (прошлые и будущие). Это также означает, что до введения доказательства резервирования было бы очень трудно добиться стекинга в Monero (и других монетах CN) без нарушения конфиденциальности владельца кошелька.

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

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

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

Как мы видим, доказать, что у каждых достаточны монет для участия в сети, в то время как сохранение приватности сложно в консенсусе PoS, еще сложнее в DPoS, потому что у участника есть стимул раскрыть как можно больше своих ставок.

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

3.1.2 Выборы делегата

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

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

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

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

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

Несмотря на то, что кошелек делегата полностью открыт, человек / организация, стоящая за нодой, может принять решение остаться анонимным. Люди все еще остаются у власти и решают, достаточно ли человек / организация заслуживают доверия и заслуживают ли быть избранными в качестве делегата.

3.2 Остаться приватным и достичь консенсуса

3.2.1 Выбор производителя блоков через VRF

Как указывалось, ранее, большинство консенсусов DPoS основывают выбор производителя блока на алгоритме циклического планирования, что означает, что делегатам, в свою очередь, предоставляется равная возможность создать блок (равный отрезок времени). Если производителю блока не удается создать блок, его ход полностью пропускается, и следующий делегат в очереди становится новым производителем блока. Такая схема планирования используется в блокчейнах, таких как Lisk и Tendermint.

Рисунок 3: регулярное планирование производства блоков циклического перебора, при котором создание пропущенного блока производителя блоков определяется следующим производителем блоков

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

В блокчейнах использовали разные методы для рандомизации производства блоков. В PoW сложность блока и соревнование основаны на случайности. В PoS шансы узлов иногда основаны на количествах монеты, которые у них в ставке(стекинг). В DPoS рандомизация может предотвратить оптимизацию ставок (изменение места назначения или использования одной ставки) и атаки. Например, если делегат знает позиции, занимаемые его конкурентами в круговом режиме, он мог бы DDOS атаковать их до наступления их очереди, тем самым пропуская его. Это может быть мотивировано уровнем сборов(комиссия) или просто потому, что уменьшение делает весь банк больше.

Например, Peercoin использует так называемый параметр «возраст монет», когда чем дольше монеты находятся в кошельке ноды (предел 90 дней), тем выше шансы стать следующим производителем блоков. Каждый раз, когда генерируется блок, значение возраста монеты расходуется и возвращается к 0 — значительно уменьшая изменения при создании следующего блока.

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

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

Чтобы добиться случайности при выборе следующего производителя блоков, мы решили использовать проверяемые случайные функции (VRF), которые уже используются в некоторых криптовалютах на основе DPoS, таких как как ONT и ADA. VRF были представлены Сильвио Михали, Майклом Рабином и Салилом Вадханом. Это псевдослучайные функции, обеспечивающие открытое и проверяемое доказательство правильности вывода, не требуя секретного ключа, используемого для генерации функции. С VRF любой, имеющий доступ к открытому ключу, сможет проверить случайность процесса выбора производителя блока без предоставления секретного ключа для генерации используемой случайной функции.

3.2.2 Имплементация DBFT

Благодаря своим механизмам резервирования и консенсуса, блокчеин является одним из самых успешных византийских систем отказоустойчивости. В случае Биткоина (и PoW), блокчейн реплицируется столько раз, сколько есть узлов в сети. Одной из причин, по которой DPoS считается более эффективным, чем PoW или PoS, является тот факт, что BFT-консенсус достигается с меньшей избыточностью. Вследствие этого сеть по-прежнему устойчива к ошибкам или дезинформации, хотя и намного быстрее.

Чтобы повысить скорость, некоторые цепочки блоков DPoS решили еще больше сократить число делегатов. Другие решили использовать так называемые «узлы консенсуса». Они обычно отличаются от делегатов, но иногда могут быть один или несколько избранных делегатов. Роль консенсуса заключается в установлении консенсусной истины. Обычно он получает новые блоки и проверяет их на наличие ошибок и фальсификации. Если консенсусный узел соглашается с данными, содержащимися в блоке, он передает последний всем делегатам, кроме того, кто создал блок. Если большинство делегатов согласны (обычно 67% делегатов), блок проверяется и добавляется в цепочку блоков.

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

В блокчейне EOS только 21 консенсусный делегат производит и проверяет блоки, это вызвало некоторую обеспокоенность в сообществе. Это дает преимущества — Блокчейн быстрее, но недоброжелатели утверждают, что он также делает блокчейн очень централизованным в руках нескольких действующих лиц. Сокращение числа делегатов также повышает удобство создания картеля, где делегаты получают и сохраняют контроль над сетью. Такое нездоровое поведение в настоящее время является одной из самых больших проблем, которые DPoS должен будет преодолеть, имеется несколько криптовалютных проектов, такие как EOS и Lisk были затронуты этой проблемой.

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

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

4 Имплементация DPoPS в X-Cash

Этот подраздел посвящен тому, как мы внедрили DPoPS в X-Cash. В этом описании рассматриваются процессы, которые необходимо изменить, чтобы адаптировать создание блоков и византийские сбои. Процесс выбора делегатов рассматривается в первую очередь потому, что он изменяет основные правила создания блоков — переход от PoW к DPoS. Затем мы объясняем и детализируем использование VRF, позволяющее рандомизировать процесс выбора производителя блока.

Обратите внимание, что это техническая реализация DPoPS, описанна ранее. Хотя есть некоторое теоретическое объяснение интеграции, большая часть этого подраздела посвящена практическим и техническим моментам — база данных, функции, процессы передачи данных и многое другое. Мы добавили комментарии к каждому подразделу, которые можно прочитать как предупреждения о трудностях, как и резюме.

4.1 Процесс выбора делегатов

4.1.1 Доказательство резервирования

Как описано в предыдущем подразделе, доказательства резервирования — это криптографические доказательства, используемые для подтверждения того, что адрес содержит определенную сумму криптовалюты. В CryptoNote эти доказательства используются для раскрытия этой информации без раскрытия закрытого ключа просмотра кошелька. В X-Cash DPoS эти доказательства являются основным компонентом консенсуса DPoPS, поскольку они используются в качестве голосов для процесса выборов делегатов.

С технической точки зрения доказательство резервирования является криптографическим доказательством, в котором можно доказать, что баланс кошелька попадает между двумя значениями и аналогично доказательствам диапазона, используемым в CryptoNote. По умолчанию эти суммы составляют от 0 до ((264) — 1) и выражены в атомных запасах (то есть для X-Cash каждая монета состоит из одного миллиона атомных монет). Потому что нижний диапазон всегда такой же, как и в верхнем диапазоне, лучше указать, что баланс кошелька составляет не менее X суммы. Доказательства диапазона — это проверка обязательств, в которой используются обязательства Педерсена.

Обязательство Педерсона — это схема обязательств, в которой:

C(a,x) = (x ∗ G) + (a ∗ H)

где: a = количество, x = маска, G = ed25519 базовый точек

H = 8 ∗ cnfasthash(G)

Примечание: cnfasthash умножается на 8, чтобы убедиться, что результаты находятся в основной подгруппе кривой ed255519.

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

Cнижний предел= Cверхний предел =Полный баланс ∗ H — C

Это означает, что кошелек может голосовать только за уникального делегата. Поэтому, если кто-то хочет проголосовать за нескольких делегатов, используя один кошелек, им сначала нужно будет разделить баланс между несколькими кошельками.

4.1.2 Децентрализованная база DPoPS

Переход на алгоритм на основе DPoS включает в себя дополнительные данные, используемые в процессе. Эти данные включают различную информацию, такую как идентификатор делегата, подсчет голосов, рейтинг делегатов, и в случае резервных доказательств X-Cash DPoPS много других более конкретных данных.

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

По этой причине было выбрано использование децентрализованной базы данных, которая хранится вне цепочки.

Тип базы данных для использования. Для более высокой производительности и потенциала масштабируемости был выбрано решение перейти на тип базы данных NoSQL, используя MongoDB. Предполагаемые данные, помещаемые в базу данных, оцениваются в 10 ГБ в год с возможностью архивирования данных через определенный период. База данных будет использоваться для четырех случаев:

• статистика системы DPoS, история ранжирования делегатов, статистика надежности, данные производителя исторических блоков и т.д.
• зарегистрированные делегаты: данные, связанные с деталями делегатов, идентификационный номер, владелец, местоположение, IP-адрес и т.д.
• резервные доказательства: хранение всех резервных доказательств, используемых в схеме голосования. Для сокращения времени синхронизации резервные доказательства делятся на порции по 12,5 МБ.
• резервные байты: данные VRF (ключи + случайные строки), публичные адреса верификаторов следующего блока, сигнатуры верификаторов текущего раунда.

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

Данные хранения в деталях.

Делегаты

Статистика

Доказательство резервирования

Резервные байты

4.2 Процессы и функции

4.2.1 Обновление информации о делегатах

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

• добавить делегата в базу данных;
• обновить информацию о делегате в базе данных;
• удалить делегата из базы данных.

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

Рисунок 4: децентрализованная база данных — обновление информации о делегатах

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

4.2.2 Синхронизация базы данных

Рисунок 5: децентрализованная база данных — процесс синхронизации статистики и данных делегатов

Статистика и делегаты. Базы данных статистики и делегатов синхронизируются с использованием одного и того же процесса. Сначала делегат запрашивает список верификаторов блоков, а затем вычисляет хэш своей базы данных. Этот хэш предоставляется всем делегатам, которые затем отвечают, если хеш совпадает с их. Если да, это подразумевает, что делегат использует тот же контент базы данных, что и запрашиваемый производитель блоков. Делегаты агрегируют результаты от всех производителей блоков и определяют итоговый консенсус по статусу своей базы данных. Если производители блоков согласно правилам, DBFT соглашаются с тем, что у делегата нет синхронизированной базы данных, этот последний делегат начнет синхронизацию базы данных со случайного узла в консенсусе.

Рисунок 6: децентрализованная база данных — процесс синхронизации резервного сбора доказательств

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

Рисунок 7: децентрализованная база данных — процесс синхронизации коллекции резервных байтов

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

Процесс выбора делегатов

Рисунок 8: децентрализованная база данных — процесс добавления доказательств резервирования

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

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

Рисунок 9: децентрализованная база данных — процесс подтверждения доказательств резервирования

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

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

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

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

4.2.3 Комментарий и заключение

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

Другая сложная проблема связана с тем фактом, что доказательства резервирования проверяются случайным образом блочными верификаторами. Это потенциально приводит к тому, что недействительное (неправильное) доказательство резервирования не может быть выбрано для проверки в течение определенного периода. Чтобы решить эту проблему, мы оценили вероятность жизни недействительных резервных доказательств при полной разбивке (50 000 доказательств резервирования 2M XCASH). На 300 случайных проверок в сети в секунду (полученных от 100 делегатов, проверяющих одно доказательство резервирования на каждые 300 мс.), мы оцениваем недействительно доказательство резервирования, которое должно быть идентифицировано менее чем за 500 с, 96,5% времени. Это означает, что большинство доказательств резервирования будут признаны недействительными максимум через несколько блоков. Мы полагаем, что в сочетании с необходимостью получения нескольких подтверждений на бирже для депозита, мы можем быть застрахованы от возможных краткосрочных голосов (имеется ввиду, когда выборщик голосует за делегата очень часто) и арбитража на рынке.

Рисунок 10: вероятность жизни недействительного доказательства резервирования во времени

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

5. Процесс выбора производителя блоков

5.1 Проверяемые случайные функции (VRF)

5.1.1 Что такое VRF

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

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

На практике, путем генерации пары секретного и публичного ключей (SK ^ PK), можно вычислить вывод строки бета y = FSK (x) на основе любого входного значения x (называемого альфа-строкой), а также сгенерировать доказательство правильности πx. Позже, этот человек может доказать кому-либо, что y = FSK (x) является правильным относительно PK и VRF.

5.1.2 Свойства VRF.

Ниже мы вспомним основные свойства VRF:

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

5.2 Интеграция VRF в DPoPS

Как RSA (RSA-FDH-VRF), так и эллиптическая кривая (ECVRF) могут использоваться в VRF для генерации ключей. Мы решили перейти на ECVRF, прежде всего потому, что это дает тот же уровень прочности ключа при сокращении длины. Для криптографических компонентов библиотека Libsodium используется в сочетании с интеграцией VRF Algorand.

5.3 Обзор процесса

Гарантия случайности выбора следующего блока производителя является ключевой особенностью X-Cash DPoPS. Этот процесс состоит из трех основных этапов:

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

5.4 Подробный процесс

Рисунок 11: выбор производителя следующего блока через процесс голосования VRF и DBFT

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

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

Как только это сделано, делегаты объединяют строки из ста символов с хешем предыдущего блока и генерируют из него хеш SHA2–512. Из этого хеша они извлекают байт, который будет преобразуется в число 1–100 с помощью процесса, описанного выше. На этом этапе ожидается, что все делегаты будут вычислять одно и то же число, которое соответствует рангу делегатов из которого ключи будут использоваться для выполнения VRF.

Последний этап процесса состоит в выполнении VRF с использованием ключей делегатов, которые были выбраны на шаге 3. На последнем этапе делегаты извлекают из строки бета-версии VRF номера 6 делегатов: первый — следующий производитель блоков, а 5 — его резервные узлы. Извлечение выполняется аналогичным образом, когда байты строки бета последовательно обрабатываются в номер делегата. Аналогично, на шаге 3 каждый байт выбирается, если ниже 200 в десятичном значении. Кроме того, каждый производитель блока и резервные узлы могут быть выбраны только один раз, поэтому в случае двойного выделение байта пропускается, а следующий выбирается.

Каждый этап, включающий исчисление, также проверяется и подтверждается путем консенсусного голосования DBFT. Основная цель голосования — создать окончательный консенсус по результатам этих шагов, чтобы позволить узлам с несоответствием отследить процесс. Это также позволяет потенциально идентифицировать злонамеренные узлы в сети, которые будут регулярно расходиться по общему согласию сети. Голосование DBFT выполняется на следующем этапе процесса:

• ключи делегата случайное агрегирование строк;
• альфа-строка для извлечения рейтинга делегата и VRF;
• номер участника делегирования для выбора ключа VRF;
• бета строка VRF.

5.5 Комментарий и заключение

Некоторые интересные комментарии могут быть сделаны по поводу процесса выбора производителей блоков. Первые касаются генерации случайной строки из ста символов, которая должна быть полностью случайной. В настоящее время это настроено в GitHub-версии X-Cash DPoPS, но ничто не мешает делегатам генерировать настроенную версию строки. Это означает, что делегаты могут представить любую строку для других, и это может поставить под сомнение случайность выбора производителей блоков. На практике, поскольку строка связана с другими делегатами, а после хеширования нет детерминизма в выборе секретного и публичного ключа делегата.

Учитывая, что мы извлекаем номер ключевого узла VRF из 64-байтового SHA2 и что мы исключаем байт, превышающий 200, это может поставить вопрос о том, что хеш не содержит используемого байта. Из 64 байтов эта вероятность составляет 5,7E-43. Таким образом, вероятность возникновения такого события считается достаточно низкой. Аналогичные рассуждения и выводы также могут быть применяется к производителю блока и извлечению резервной копии из строки бета-версии VRF. В случае, если для вычисления не хватает байтов, главный начальный узел создаст для этого блок круглый, чтобы блокчейн не застрял.

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

6. Процесс создания блока

Модифицированный процесс создания блока представлен в этой части. И мы рассмотрим, как мы обратились к выбранному протоколу DBFT и использовали его в DPoPS. Для упрощения чтения мы не охватываем полные детали унаследованные от процесса создания блока CryptoNote, но сосредоточены только на улучшениях, которые мы сделали. В этом разделе также освещаются как процессы синхронизации демонов, так и протокол передачи данных, который мы должны были создать.

6.1 Консенсус DBFT

Метод консенсуса, используемый в X-Cash DPoPS, представляет собой применение протокола консенсуса DBFT с некоторыми заметными изменениями по сравнению с существующей реализацией DBFT в других консенсусах криптовалют. Как обсуждалось ранее, выбор производителя блока выполняется через VRF, и не все консенсус данные хранятся в цепочке блоков.

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

Рисунок 12: правила голосования DBFT и процессы среди 100 делегатов

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

В данном наборе из N = 3n + 1 делегатов нам нужно 2n + 1 делегатов для достижения консенсуса.

6.2 Содержимое блока в DPoS

Хотя философия блока остается неизменной, то есть проведение транзакций, структура блока значительно развивается в соответствии с DPoPS X-Cash, чтобы адаптироваться к различным изменениям, которые он подразумевает. Наиболее заметным из них является необходимость отслеживать и фиксировать консенсус в отношении выборов делегатов. По техническим причинам, которые описаны в разделе 4.1.2, некоторые из этих данных хранятся в отдельной децентрализованной базе данных, где также применяются правила DBFT. Цель этого раздела — погрузиться в структуру блока и объяснить, как он связан с децентрализованной базой данных, чтобы убедиться, что основные принципы блокчейна все еще применяются.

Рисунок 13: содержимое блока и его связь с резервными байтами в децентрализованной базе данных

При использовании консенсуса DPoS, значительно увеличивается количество данных, используемых для достижения консенсуса. Эти данные хранятся в разделе резервных байтов децентрализованной базы данных. Он включает в себя имя производителя блока, его открытый адрес и все данные, связанные с производством VRF и верификаторами следующего раунда блока. Чтобы гарантировать прослеживаемость и целостность этих данных, нам нужно найти способ отразить их в блокчейне.

Это делается путем объединения данных резервных байтов с полным содержимым блока, при его создании и хеширование. Результат SHA2–512 добавляется в блок под переменной данных резервных блоков, и затем блок может быть окончательно хеширован в так называемый хеш блока. Используя этот метод, любые узлы в сети, включая делегатов, могут легко проверить любой блок в цепочке, а также данные ожидающих его резервных байтов в децентрализованной базе данных.

6.3 Процесс синхронизации демона

Чтобы приспособиться к изменению алгоритма, также необходимо обновить процесс синхронизации демона, чтобы учесть также необходимость проверки производителей и верификаторов блоков. Мы предоставляем ниже высокий уровень этого процесса, который состоит в первом извлечении списка верификаторов блоков из узла случайного источника(seed). Следующим шагом является случайное подключение к одному из них и запрос резервных байтов для как предыдущего, так и текущего блока.

Рисунок 14: процесс синхронизации демона

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

6.4 Протокол передачи данных

6.4.1 Резюме

Чтобы обеспечить быструю и эффективную связь между делегатами, а также добавить необходимые функции для достижения консенсуса, мы создали набор шаблонов данных, которые мы описываем как Протокол передачи данных. Эти шаблоны разделены на 4 основные категории:

• процесс верификации блочных верификаторов;
• команды делегатов;
• процесс синхронизации блокчейна;
• процесс синхронизации базы данных.

Цель этого раздела — описать основные компоненты и цели этих шаблонов. Более подробную информацию можно найти в специальном разделе DPoPS Github.

6.4.2 Процесс идентификации делегатов

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

• previous_block_hash — хеш предыдущего блока;
• current_round_part — текущая часть круга
• current_round_part_backup_node — текущий главный узел в текущей круглой части.

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

6.4.3 Шаблоны.

На рисунке ниже представлен общий обзор шаблонов, используемых в протоколе передачи данных. Более подробное описание каждой функции можно найти в Приложении 9.1.

Рисунок 15: обзор шаблонов протокола передачи данных

6.5 Подробности процесса

В этом разделе мы опишем типичный процесс для раунда производства блоков. Перед запуском процесса создания блока 100 избранных делегатов выполняют VRF согласно описанному процессу в разделе 5.3. Результат бета-строки будет включена в произведенный блок для определения следующего блока верификаторов и производителей.

Рисунок 16: процесс производства блока

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

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

Как только блок будет завершен, в сети делегатов будут сгенерированы два голоса DBFT. Первый голос проверяет достоверность блока (данные VRF, хэш и т. д.), а второй голос проверяет содержание транзакции. Если этот шаг успешно пройден, блок будет подписан всеми верификаторами блоков, и будет проведено дополнительное голосование DBFT для подтверждения шага подписи.

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

6.6 Комментарий и заключение

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

Также были высказаны некоторые опасения по поводу увеличения времени блока до пяти минут. Это увеличение сделано специально, так как основная сеть постепенно переключается на уровень полного расчета только для крупных транзакций. Увеличивая время, а также, возможно, плату за транзакции, мы надеемся создать стимул для транзакций, происходящих вне сети через боковые цепи (side chains) и боковые каналы (side channels, аналог lightning network для битка, транзакции через этот канал для xcash по словам Зака будут идти около 10 сек).

Процесс создания блока остается относительно сложным с точки зрения шагов, голосов DBFT, общего потребления и некоторых сложных вопросов, касающихся данных, которые он будет использовать. По нашим оценкам, общее потребление сетевых данных, необходимое для создания блока, будет в среднем в диапазоне 1,5 ГБ или 15 МБ на делегатов. За цикл производства блока это представляет собой среднюю необходимую полосу пропускания 50 кБ/с с пиками 500 кБ/с. Это интересный показатель, поскольку он показывает, что пропускная способность серверов будет достаточно высокой для управления сетью, а также показывает большой потенциал для дальнейшей масштабируемости через боковые цепи.

7 Внедрение DPoPS в X-Cash и криптовалюты

Цель этого раздела — изучить последствия, а именно связанные с экономичностью и масштабируемостью, которые DPoPS будет иметь для экосистемы X-Cash и других монет CryptoNote, исследующих возможность перехода на DPoPS. Наконец, мы объясним наше видение X-Cash и DPoPS в будущем и эволюцию, которую мы будем реализовывать.

7.1 Экономические последствия для X-Cash

7.1.1 Вознаграждение за блок и эмиссия монет.

Схема вознаграждения за блок останется такой же в DPoPS, как и в PoW, за исключением следующих изменений:

• время блока увеличено с двух до пяти минут;
• вознаграждение за блок, увеличится в два раза.

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

За этой философией скрывается цель — сохранить маленькое время в транзакциях и емкость транзакций в сети, что механически приведет к увеличению комиссионных за транзакции, которые несовместимы с микроплатежами. Это подразумевается, что это необходимо, чтобы избежать наполнения сети ненужными транзакциями. Действительно, консенсус и уровень безопасности каждой транзакции должны соответствовать ее потребностям. Через эти механизмы, мы надеемся постепенно создать стимул как с точки зрения рынка, так и с точки зрения времени транзакции, чтобы переложить транзакции на боковые цепи.

7.1.2 Цена майнинга и рыночный поток.

Интересным результатом перехода на DPoPS с точки зрения майнинга является снижение предельных издержки на создание X-CASH. В PoW затраты на добычу можно разложить на фиксированные аппаратные и предельные затраты на потребление электроэнергии. В DPoS обеспечение, необходимое для участия в консенсусе, можно представить, как фиксированные затраты, но после того, как это будет оплачено, добыча монеты не будет требовать предельных затрат.

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

7.1.3 Эффективность vs изоляция предложения оборота

Переключение на DPoPS также вводит новую форму предложения: изолированное оборотное предложение. При PoW мы различаем три предложения. Circulating supply — все монеты, которые добылись и находятся в обращении. Segregated supply — которые были добыты, но которые заперты в конкретном кошельке. И total supply — дополнительно включает добываемый запас. В соответствии с DPoPS оборотное предложение делится на эффективное и изолированное количество. Поскольку циркулирующие монеты должны быть заблокированы, чтобы сделать ставку, это вызывает дополнительную изоляцию монет, оцениваемую в 40–60% от circulating supply. Это приводит к снижению эффективного оборотного предложения, что обычно оказывает положительное влияние на цену монет, но возникает за счет снижения ликвидности на рынке. (получается с рынка уйдут монеты на блокировку для запуска ноды).

7.1.4 Рынок боковых цепей

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

Это будет реализовано через децентрализованный рынок, где делегаты будут размещать свои предложения для размещения боковых цепей и получать оплату в XCASH. Типичные метрики, используемые здесь, XCASH/kB/делегирования платежей и XCASH/kB/delegate/месяц хранения. Исходя из этого, мы видим, что XCASH будет действовать как gas в сети для запуска боковых цепей. С другой стороны, клиенты, потребители и пользователи будет иметь возможность покупать боковые цепи из этих заявок и создавать свою собственную подсеть, в которой делегаты несут консенсус, хранение и обработку транзакций.

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

7.2 Решение проблемы масштабируемости

7.2.1 Инфраструктура для дальнейшего развертывания

Благодаря DPoPS у нас будет более гибкая сеть при сохранении высокого уровня децентрализации (подобно биткоин и другим криптовалютам PoW, процесс майнинга привел к концентрации мощности майнинга в нескольких пулах майнинга, что вызывает озабоченность по поводу децентрализации). С точки зрения гибкости это приведет к динамическому количеству делегатов, если это необходимо для лучшего соответствия необходимости дальнейшей / меньшей децентрализации. Новый консорциум из 100 делегатов также обеспечит лучшую координацию между сетью и, в частности, на этапах тестирования которые имеют решающее значение для следующих событий.

7.2.2 Sidechains

Резюме. Боковые цепи станут следующим крупным обновлением сети и произойдут, когда DPoS будет установлен и будет работать точно. Боковые цепи — это параллельные блокчейны, которые зависят от X-Cash как технологически, так и консенсусно. Боковые цепи могут быть описаны как форки X-Cash, где консенсус по-прежнему управляется операторами основной сети и в соответствии с аналогичными правилами. Ключевое отличие полагается на тот факт, что боковые цепи управляются только подмножеством делегатов основной сети, что приводит к большим последствиям, таким как более низкие затраты, более быстрое согласие и более высокая гибкость за счет меньших затрат на безопасность.

Согласованный протокол. При первой реализации боковых цепей консенсус будет таким же, как и в основной сети, то есть DPoPS. Это означает, что аналогично основной сети 2x + 1 делегатам необходимо будет достичь консенсуса, увеличив минимальное число делегатов, необходимое для запуска боковой цепи до 4. В следующей версии наша цель состоит в том, чтобы предоставить более широкий диапазон типов консенсуса, таких как PoW, PoA (подтверждение полномочий) и PoI (подтверждение личности).

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

Типы боковых цепей. Мы можем выделить два типа боковых цепочек: боковые цепочки на основе X-CASH и боковые цепочки на основе данных. Первый имеет чисто денежную цель, где люди могут отправлять X-Cash при более низких затратах, а также с учетом большей масштабируемости. Благодаря функции расчета, когда боковая цепь закрыта, оставшиеся нераспределенные платежи (балансы) будут возвращены в основную сеть. С точки зрения масштабируемости, эти боковые цепи позволят значительно увеличить количество транзакций в секунду, поскольку каждая боковая цепь сможет выполнять от 10 до 20 транзакций в секунду, в то время как количество боковых цепей, которые могут быть запущены одновременно, практически не ограничено.

С другой стороны, у боковых цепей будет возможность основываться на данных без передачи X-Cash. Этот тип боковых цепей будет использоваться для широкого спектра случаев, когда доверенный токен не обязательно нужен: цепочка поставок, голосование и т.д.

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

Боковые каналы. Side channels аналогичны боковым цепям в том, что они используются для разгрузки основной сети от транзакций. Основное различие с точки зрения возможностей заключается в том, что они несут только денежные транзакции, которые включают X-Cash. С технической точки зрения боковые каналы заключаются в блокировке части монет, хранящихся в блокчейне, с помощью схемы с множеством подписей или умные контракты в наборе заранее определенных участников. Каждая транзакция будет опубликована и подписана участниками без трансляции в сеть. Это позволяет создавать несколько транзакции, в то время, как только одна из них записана на блокчейне, экономя комиссию за транзакции и обеспечивая почти мгновенные транзакции.

7.3 Будущее DPoPS

7.3.1 Слой настроенные на развитие

Эта первая итерация X-Cash DPoPS направлена на создание нового протокола с основными функциями, позволяющими достичь эффективного и безопасного консенсуса. Благодаря отзывам сообщества наша цель — улучшить его на следующей итерации, добавив при этом следующие функции, которые будут генерировать дополнительные варианты использования.

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

7.3.2 Предвестники реализации DPoS в приватной монете

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

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

7.3.3. Согласованный алгоритм, который можно использовать повторно и адаптировать ко всем монетам.

Переход от PoW к более энергоэффективному алгоритму станет ключевой задачей в ближайшие годы для всех криптовалют, включая биткоин. Благодаря алгоритму DPoPS мы надеемся создать структуру, которая может быть адаптирована для любых монет. Мы твердо верим в демократичность DPoS в сочетании с функциями приватности, которые могут быть реализованы в любой монете и может предложить интересную среду для развития криптовалюты.

8 Заключение

X-Cash начинала как криптовалюта с открытым исходным кодом, ориентированная на приватность и децентрализацию. Хотя CryptoNote предлагает современную приватность, основанную на кольцевых подписях и скрытых адресах, она также ограничивает потенциал блокчейна с точки зрения емкости, производительности транзакций и возможностей. Видение команды X-Cash заключается в том, чтобы предложить максимально гибкую криптовалюту из возможных — возможность публичных транзакций, sidechains хостинг и side channels платежы — и поэтому предлагает обновление сети, чтобы стать более масштабируемым. Наше видение заключается в том, что DPoS предлагает лучший компромисс между безопасностью, масштабируемостью, и децентрализацией.

Реализация любого алгоритма консенсуса на основе доли владения в приватной монете может быть сложной задачей. Для X-Cash было выбрано использование доказательство резервирования для проверки ставки в сочетании с специальным протоколом, который обеспечивает стандартизированную и защищенную связь в сети. С точки зрения консенсуса блокчейна было выбрано использование процесса, в котором все верификаторы блоков проверяют каждый шаг голосования на основе DBFT. Это обеспечивает дополнительный уровень безопасности, в то же время полагаясь на проверяемые случайные функции для выбора производителя блока каждого раунда для дальнейшей гарантии устойчивости к злонамеренным атакам.

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

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

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

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

Важные ссылки

Сайт: https://www.xcash.foundation/

Присоединяйтесь к сообществу на Discord: https://discord.gg/8VD74ba

Узнайте, как голосовать с XCASH и получать пассивный доход:

https://docs.xcash.foundation/dpops/vote-and-staking

X-Bank: https://x-bank.io/