Техническая документация X.Blockchain

Квон Ёнсок
21 мая 2018 г.

Copyright © 2018 XBLOCK SYSTEMS CO., LTD. Воспроизведение и распространение информации, содержащейся в данном техническом документе, допускается только в некоммерческих и образовательных целях (т.е. за исключением взимания отдельной платы и коммерческого использования) и при условии указания первоначального источника и авторских прав.

Дисклеймер: Настоящая техническая документация X.Blockchain предназначена лишь для информационных целей. XBLOCK SYSTEMS не гарантирует точность выводов, приведенных в данном техническом документе, документ предоставляется “таким, какой он есть”. XBLOCK SYSTEMS отказывается от предоставления гарантийных обязательств, установленных законом или иным образом, включая: (i)гарантии товарности, пригодности для определенных целей, пригодности использования названия, гарантии не нарушения авторских прав;(ii) гарантии того, что содержание данной технической документации не содержит ошибок;(iii) гарантии того, что содержание документа не будет нарушать права третьих лиц. XBLOCK SYSTEMS и его представительства предупреждают о потенциальном ущербе, который может возникнуть в результате использования информации, приведенной в данной документации, и при использовании ссылок на её содержание, однако, невзирая на это, никакой ответственности за последствия не несут. Компания XBLOCK SYSTEMS или ее представительства не несут ответственности за затраты или расходы любого рода, будь то прямые или косвенные, компенсационные, случайные, фактические, примерные расходы, карательные или специальные убытки, которые могут возникнуть вследствие использования содержащейся в данном документе информации, цитирования, ссылки на данный технический документ и др. Компания XBLOCK SYSTEMS также не несёт ответственности за любой возникший ущерб бизнесу, доходам, прибыли, данным и нематериальные убытки.

АннотацияВозникновение Биткойна, а также резкое увеличение использования Биткойнов в сфере торговли стало доказательством того, что технология блокчейн достаточно надёжна, чтобы её можно было использовать в качестве журнала транзакций (a transaction ledger). Основные причины столь высокого внимания к технологии блокчейн следующие: 1) Третья доверенная сторона (Trusted Third Party,TTP) была устранена в целях обеспечения надежности, что отличается от существующего метода; 2) так как все данные о транзакциях распределяются и хранятся у всех участников сети, манипулирование содержимым транзакции невозможно. Важнейшими и ключевыми понятиями технологии блокчейн являются концепции ‘децентрализации’ и ‘распределенного журнала’(distributed ledger). Имеющийся метод заключается в том, что все транзакции фиксируются в централизованном головном сервере, а надёжность транзакций ‘гарантируется’ этим центральным сервером (доверенным третьим лицом). Однако транзакции, происходящие в цепочке блоков, передаются всем участникам, участвующим в сети, и ‘проверяются’, ‘согласовываются’ и ‘блокируются’, соединяясь последовательным (линейным) образом. Размер блок-цепочки, в которой записывается вся транзакционная информация, увеличивается по мере увеличения количества накопленных транзакций, другими словами, размер цепочки блоков увеличивается с течением времени. Это означает, что в определенный момент для всех участников сети станет невозможным практически хранить все цепочки блоков, а также управлять ими.
Другими словами, существует высокая вероятность того, что с постепенным уменьшением числа систем (узел сети, «node? обладающих достаточной производительностью, чтобы хранить всю цепочку блоков и управлять ею, будет сформировано относительно небольшое количество наборов узлов сети. И это приведет к другой форме централизации. В ситуации, когда относительно небольшое количество наборов узлов управляет всей цепочкой блоков, надежность транзакции вынуждена зависеть от этого небольшого числа набора узлов. Следовательно, это означает, что такая фундаментальная концепция блокчейн как ‘децентрализация’, может серьёзно пострадать.**

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

Problems

С течением времени размер блочной цепи постоянно увеличивается пропорционально аккумулированному числу транзакций. Во всех узлах, учавствующих в сети блокчейн, происходит распределение и сохранение транзакционного журнала; при намерении с помощью него применить к блокчейн, сохраняющая надежность транзакций без участия третьей доверенной стороны (trusted third party), традиционную концепцию, то проблема непрерывного увеличения размера блок-цепи, возникающая из-за участия узлов для проверки транзакций, будет генерировать предельную ситуацию. Другими словами, для участия в качестве полного узла ¹ который хранит и управляет огромной цепочкой блоков, требуется определенный уровень производительности, такой как обеспечение пространства для хранения. Поскольку уровень производительности постоянно увеличивается пропорционально размеру блокчейн, числовое сокращение участвующих узлов становится неизбежным, что приводит к другой (иной) форме централизации ². По состоянию на май 2018 года общий объем данных блочной цепи биткойна ³ приближается к 200G, а данные блокчейн Эфириум (Ethereum) за последнее время превысили 600G.

Размер блокчейн Биткоина и Эфириума - Источник: http://bc.daniel.net.nz/

Использование CPU Биткоина и Эфириума - Источник: http://bc.daniel.net.nz/

Такой уровень «квалификационных условий» делает практически невозможным абсолютное участие большего числа пользовательских клиентов (включая мобильные устройства) в сети цепочки блоков в качестве полного узла. В итоге пользовательский клиент не в состоянии самостоятельно проверить надёжность транзакции (без участия третьей доверенной стороны) и ему ничего не остаётся делать кроме как ‘обратиться’ к относительно небольшому числу полных наборов узлов и в одностороннем порядке ‘принять’ результат. Здесь небольшая группа полных узлов действует как ‘доверенная третья сторона’. Как уже было упомянуто, проблема ‘централизации полных узлов’ обусловлена высокой вычислительной мощностью, необходимой для хранения и построения блоков крупных блочных цепей. Необходимость сохранения цельной цепочки блоков заключается в том, что, поскольку структура блокчейна состоит из линейной структуры соединения, выделить только необходимые блоки невозможно. Набор отключенных блоков не представляет никакой ценности, так как он не может подтвердить надежность. Особенностью данной блокчейн является то, что она обладает не только выдающейся инновационностью, но и также обладает способностью снижать свою неэффективность. К примеру, допустим, одна компания решила использовать «публичный блокчейн» (‘public blockchain’) для создания внутренних отчетов о деятельности компании и управления ими. Узел цепочки блоков, управляемый компанией, должен хранить большое количество транзакций, которые происходят в этой общедоступной блочной цепочке во всем мире, независимо от их собственных записей. Эта полная блок-цепочка данных, вероятно (скорее всего) будет в сотни тысяч раз больше, чем транзакции компании. В итоге организации необходимо хранить бесполезные для неё данные, превышающие по объему самостоятельно производимые данные. Для того чтобы решить данные проблемы, мы намерены рассмотреть использование системы «частного блокчейн» (‘private blockchain’). Разумеется, частный блокчейн также важен и представляет высокую ценность, однако он не может стать решением проблемы с точки зрения наличия централизованной структуры.

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

X.Blockchain не принуждает все возникающие транзакции формироваться лишь в единую линейную структуру. Это означает наличие разрешения умышленно форкировать (fork) в соответствии с транзакцией, следовательно, возможность построения отдельной структуры, состоящей из транзакций, имеющих значимые отношения. FНапример, когда «документ» используется как ссылка, ‘начальное создание’ каждого документа записывается в цепочке блоков (MainChain), имеющей ту же линейную структуру, что и существующая цепочка блоков. Однако дополнительные транзакции, возникающие при корректировании конкретного документа и т. д., уже записанные в MainChain, записываются в SubChain, которыйсам по себе является другой блочной цепочкой, отличной от MainChain и исполняет роль ‘блока генезиса’ (genesis block). В качестве примера, рассмотрим ситуацию, описанную ранее, компания намеревается управлять внутренними записями активности в цепочке открытых блоков. В связи с этим она в уже существующем MainChain создает блок, который будет использоваться как ‘блок генезиса (genesis block)’ своего Блокчейн, а также формирует другой SubChain,исходный блок, и уже в нем сохраняет данные о внутренней активности компании. Таким образом, компания может минимизировать хранение транзакций и блоков, служащих для разных целей.

Background

В обычной блочной цепочке fork искажает согласованность данных, записанных в блок. Наличие множества блоков, имеющих одну и ту же высоту блока, означает, что один объект в определенное время имеет одновременно множество различных значений статуса, что само по себе является противоречием. То есть ‘баланс счета в настоящее время составляет 2 миллиона вон и в то же время 3 миллиона вон’. Предположим, вы отозвали 2,5 миллиона вон со своей учетной записи A. каков баланс счета A после снятия денег? Возможно ли снятие до этого?
Чтобы избежать возникновение такого рода проблемы, события, которые изменяют состояние одного и того же объекта, должны обрабатываться последовательно. Это означает, что результат обработки для другого события должен быть дополнительно отражен в измененном состояния после завершения обработки другого события для изменения состояния и подтверждения его состояния. Например, состоянием A является S_A, набор событий, которые его изменяют, называется T_A а состояние A, измененное отдельным событием t ( $t \in T_{A}$ ) равно S_A,t . Принимая за множество событий t1 и t2, обработка события t1 должна быть завершена, и обработка события t2 должна продолжаться после того, как состояние A определено как S_A,t1. То же самое верно в случае, когда t2 выполняется заранее. В результате обработки t2 обработка t1 должна продолжаться в состоянии, в котором состояние A определяется как S_A,t2.

$\begin{array}{c}T_A = \{t1, t2, \space ...\}, \\\\\\S_{A,t0} \xrightarrow{t1} S_{A,t1} \xrightarrow{t2} S_{A,t2} \\or \\S_{A,t0} \xrightarrow{t2} S_{A,t2} \xrightarrow{t1} S_{A,t1}\end{array}$

Это выражается в виде блочной структуры следующим образом.

Однако, если обработка для t2 выполняется одновременно до завершения обработки t1 для S_A,t0 , предыдущее состояние A во время события обработки t1 является S_A,t0 , предыдущее состояние SA для А в момент обработки события t2 становится S_A,t0 , и S_A,t0раветвляется на 2 ветви, S_A,t1 и S_A,t2 .

$\left .\begin{array}{c}S_{A,t0} \xrightarrow{t1} S_{A,t1} \\\\S_{A,t0} \xrightarrow{t2} S_{A,t2}\end{array}\right \} \space \text{What is A's state?} \space\space\space S_{A,t1} \space\space \text{or} \space\space S_{A,t2}$

В этом случае возникает типичная проблема с двойным платежом. Чтобы решить эту проблему, в определенный момент (block height = #n-1) должна быть принудительно установлена только одна S_AТо есть конечное состояние S_Aдолжно определяться как S_A,t1или S_A,t2 , что означает, что любое событие, t1 или t2, должно быть отменено (аннулировано).

Это является объяснением того, что не все события, вызывающие изменение состояния одного и того же объекта, могут обладать синхронностью, а также того, что обработка обязательно должна осуществляться в определенной последовательности. В случае транзакции с криптовалютой, событие (транзакция) изменяет статус не только конкретной учетной записи (баланс), но и состояние нескольких учетных записей, включая учетные записи денежных переводов и задолженностей. В то же время одна учетная запись, за исключением себя, должна потенциально иметь возможность связываться со всеми остальными аккаунтами. Когда транзакция t1: A -> B и транзакция t2: A -> C, t1 одновременно изменяет состояние A и B (баланс). Таким образом, она принадлежит к тому же набору событий, что и другие события, которые изменяют состояние A и B. В то же время t2 одновременно изменяет состояние A и C, поэтому оно относится к тому же множеству событий, что и все другие события, которые изменяют A и C. В результате события, изменяющие состояния A, B и C, включая t1 и t2, все принадлежат одному и тому же набору событий. Допустим транзакция t3: D -> E, а t3 не имеет отношения к изменениям состояния А, В, то возможна классификация как отдельного набора событий. Однако, поскольку D или E могут также связываться с A, B и C, необходимо учитывать возможность изменения D состояния А в связи возможным возникновением таких событий (Е точно также). Если изменение состояния D принадлежит множеству событий T_i и принадлежит другому набору событий T_jиз-за другой учетной записи и новой транзакции, T_i и T_j должны в конечном итоге включаться в качестве подмножества большего набора событий, которые должны быть гарантированы последовательностью. В результате это удобно для всех событий для A, B, C, D и E, состоящих из одного набора событий. В тоге, состояние, которое нужно контролирвать, - это состояние единого ‘журнала истории транзакций’, в котором фиксируется неопределённое количество транзакций, соврешенных между учетными записями, а не каждое отдельное состояние транзакций.

X.Blockchain Overview

MainChain: в качестве родительской цепочки блоков, состоящих из структуры линейного блочного соединения, может иметь несколько SubChain. The Main Chain может быть SubChain другого родительского MainChain.
SubChain: независимый блокчейн, взявший в основу определенный блок MainChain в качестве genesis block. SubChain может быть MainChain другого SubChain.
X.Block: один из блоков, формирующих блокчейн, выполняющий роль Genesis Block какого либо SubChain.
X.Transaction: X.Transaction**: транзакция для создания X.Block.
Full Node: узел сети, управляющий MainChain и всеми низкоразрядными блоками SubChain.
Sub Node: узел, который управляется блоком только определенного SubChain.
Blockchain Depth: Depth(глубина) SubChain, управляемая узлом на основе высокоразрядного блокчейн.

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

Это означает, что каждый отдельный набор событий такой как T_A, T_B, T_C, …для множества отличающихся друг от друга разных объектов (документов) A, B и C, … может формироваться в отдельную независимую линейную структуру. То есть события t_a1 и t_b1, входящие в T_A и T_B, которые принадлежат к разным наборам событий, необязательно должны обрабатываться последовательно друг относительно друга или включаться в одну и ту же структуру сериализации.

$\begin{array}{c}T_A = \{t_{a1}, t_{a2},\space...\}, \space\space T_B = \{t_{b1}, t_{b2},\space...\}, \\\\ T_A \cap T_B = \emptyset , \\\\\\\text{A's blockchain} : S_{A,t_{a0}} \xrightarrow{t_{a1}} S_{A,t_{a1}} \xrightarrow{t_{a2}} S_{A,t_{a2}} \cdots\\\\\text{B's blockchain} : S_{B,t_{b0}} \xrightarrow{t_{b1}} S_{B,t_{b1}} \xrightarrow{t_{b2}} S_{B,t_{b2}} \cdots\end{array}$

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

MainChain

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

SubChain

SubChain — это еще одно соединение и расширение блока, запускающееся специальным блоком, который содеражится в MainChain и который обладает возможностью разветвляться. Ряд блок-цепочек, запущенных специальным блоком MainChain, создают отдельные блоки, сформированные из транзакций, входящих в независимые наборы событий; созданные блоки соединяются с последним блоком каждого блокчейна, поэтому формируются отдельные блок-цепи не обладающие синхронизацией. В такой ситуации SubChain является независимая цепочка блоков каждого набора событий, имеющих связи с другими наборами событий. SubChain—завершенная и независимая блочная цепь. Механизм достижения всех функций и соглашений на SubChain в точности совпадает с механизмом MainChain. Как и в случае с MainChain, возможно создать X.Block в SubChain, поэтому SubChain может быть MainChain другого SubChain. Это позволяет X.Blockchain развиться в структуру многомерной блочной цепи.

X.Block

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

Специальный блок способный разветвляться называется X.Block. Только один SubChain может быть запущен с определенного X.Block. Однако SubChain может содержать другой X.Block, и в итоге, развить структуру многомерного блочейн.

Все цепочки блоков на X.Blockchain (MainChain & SubChain) состоят из двух типов блоков: X.Block и обычных блоков. Кроме того, X.Block имеет множество структур хеш-соединений, в отличие от обычного блока. X.Block - хеш-соединение с предыдущим блоком (обычный блок) и одновременно с предыдущим X.Block. Причина наличия такой структуры множественного соединения связана с отправлением X.Blockchain для обеспечения более эффективной целостности всех «электронных данных», включая электронные документы. Если необходимо проверить целостность «данных», проверка данных возможна, поддерживая только SubChain, содержащий данные и родительский MainChain этого SubChain, что является важным мотивом предложения X.Blockchain. Однако, когда в MainChain происходят частые транзакции с активами, количество стандартных блоков, которые их записывают, должно быть включено в объект обслуживания, поэтому исходная эффективность X.Blockchain может серьезно снизиться.

X.Block имеет «множественную структуру ссылок на хэш» для решения эффективности проверки целостности данных и проверки целостности транзакции актива (журнала транзакций). Если клиент предназначен только для проверки целостности данных на X.Blockchain, необходимо сохранить часть MainChain и определенный SubChain, состоящий только из X.Blocks, и, не поддерживая обычные блоки, можно построить цепочку блоков, необходимую для проверки данных. При этом «часть MainChain, состоящая только из X.Block? должна связываться с единым блоком, поэтому X.Block, помимо связи с обычным блоком, должен иметь дополнительную структуру соединения с непосредственно предшествующим X.Block.

X.Transaction

Специальная транзакция, предназаначенная для создания X.Block называется X.Transaction. X.Tx должен описывать характеристики сгенерированного SubChain, а также начальное состояние и свойства активов, созданных в SubChain. Это похоже на содержание обычного «блока генезиса» (genesis block) в общей блок-цепочке, а также содержание «токена», генерируемого при помощи интеллектуального контракта в Эфириуме. X.Tx должен описывать следующее.

- Target ChainID
- SubChain's Name
- SubChain Asset's Name & Code
- Initial State of SubChain Assets
- Initial Validator Set
- Tx. Fee in MainChain Asset

Оплата за обработку X.Transaction производится при помощи активов MainChain. Оплата за осущетвление обработки X.Tx. должна отличаться от общей оплаты за услуги обработки Tx, но решение будет приниматься только по усмотрению генератора блоков и верификатора. Чтобы повысить общую эффективность блокчейна, предотвращая чрезмерное возникновение X.Transaction, приводящее к ненужным генерации X.Block и SubChain, правильным будет взимать сумму выше, чем за обычную Tx.

Consensus Algorithm

X.Blockchain в основном достигает консенсуса с использованием механизма PBFT + DPoS. Это консенсусный механизм, предложенный Tendermint, который позволяет построить Public & Private blockchain, путём объединения традиционного алгоритма PBFT и концепции DpoS.

PBFT (Practical Byzantine Fault Tolerance)

PBFT - это консенсусный алгоритм, введенный в конце 90-х годов. Существующий BFT мог работать с допущением синхронной среды и имел слишком много проблем с производительностью для практического использования. Именно PBFT улучшает такой BFT, чтобы иметь возможность работать в асинхронной среде и решать высокоскоростную обработку транзакций при решении общей проблемы Византии. В консенсусном алгоритме на основе PBFT, если $\ge\frac{2}{3}n$ или более из всех узлов (n) участвующих в консенсусе, соглашаются принять предложенный блок, они могут достичь консенсуса, если доля вредоносных узлов не превышает $\frac{1}{3}$ .

Алгоритм PBFT - Источник: http://pmg.csail.mit.edu/papers/osdi99.pdf

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

Основной узел собирает все запросы транзакций от клиента.
Первичный узел упорядочивает транзакции в порядке запросов и строит их в блоки и распространяет их в цепочку блоков.
Узел Replica передает блок, полученный от первичного узла, обратно на другие узлы Replica.
Каждый узел Replica подтверждает, является ли распространяемый им блок тем же, что и блок, полученный от другого узла. Если количество узлов, передающих один и тот же блок, превышает кворум $(\frac{2}{3}n)$ , он подтверждает блок.
И затем он распространяет результат проверки блока на другие узлы.
Каждый узел агрегирует результаты проверки блока, которые были отправлены другими узлами. Если тот же результат превышает кворум $(\frac{2}{3}n)$ , он соединяет блок с его собственной цепочкой. В противном случае он не связывает блок с цепочкой.
Результаты отправляются клиенту.

Все используемые в настоящее время алгоритмы на основе PBFT основаны на базовой процедуре согласования, как описано выше. Одним из них является PBFT + DPoS, который был принят Tendermint-ом. В процедуре соглашения Tendermint основной узел называется Proposer, узел Replica называется Validator, и не все узлы в сети становятся Validators, только узел, который имеет свои собственные акции, становится Validator и участвует в процессе урегулирования. В обычном PBFT все узлы имеют одинаковый вес, но в алгоритме соглашения Tendermint каждый Validator имеет вес, пропорциональный количеству акций, поэтому кворум - это не количество Validator, а сумма $\frac{2}{3}$ голосов Validator-ов.

Процедура Соглашения Tendermint – Источник: https://tendermint.com/static/docs/tendermint.pdf

Для получения дополнительной информации о механизме соглашения PBFT + DPoS, посмотрите Документ Tendermint .

Validators and Delegating

Валидатор - это узел, участвующий в процессе проверки и согласования блока. Узлы, включенные в набор Валидатора, решают согласиться или нет с предлагаемым блоком путем голосования на основании их полномочий голоса. Все узлы, составляющие сеть, могут быть валидаторами, резервируя свои собственные ресурсы, но это не всегда возможно, потому что максимальное количество узлов, составляющих набор Валидатора, является фиксированным. Если количество узлов, составляющих текущий набор Валидатора, является максимальным, то единственным способом сделать новый узел Валидатором является внесение большей доли, чем Валидатор, с самой маленькой долей из текущих Валидаторов. В этом случае Валидатор с наименьшей долей акций будет дезактивирован, а новый узел, который будет держать большую ставку, будет служить в качестве Валидатора.
Даже если это не Валидатор, есть способ косвенно участвовать в процессе консенсуса путем делегирования права собственности определенному Валидатору. Каждый узел в сети может делегировать права собственности определенному Валидатору. Доля голосующих акций делегированного валидатора будет увеличена за счет делегированной доли, и компенсация, которая будет получена Валидатором, также будет увеличиваться. В это время узел, который делегировал право собственности, также получит часть компенсации, которую Валидатор получит в качестве компенсации за делегирование. Акции, которые были депонированы для того, чтобы стать Валидатором, должны быть недоступны, пока узел действует как Валидатор. Если Валидатор совершает злонамеренные действия, такие как несоблюдение согласованного консенсусного механизма, некоторые или все депозиты исчезнут. Это своего рода концепция наказания за несправедливое поведение консенсусного процесса, которое решает проблему «Nothing at Stake?традиционного алгоритма PoS.

Proof of Forkability

Из-за специальной блочно-связывающей структуры X.Blockchain невозможно применить уже известный консенсусный механизм, какой он есть. Механизм консенсуса отсутствует, потому что не рассматривается «ветвление», предложенное X.Blockchain. Другими словами, X.Blockchain требует дополнительного консенсусного процесса с учетом принятия филиала. То есть, «Генерация X.Block?и «Связывание нового блока с определенным SubChain?являются законными. Доказательство Forkability (PoF) является ключевым компонентом механизма соглашения, используемого в X.Blockchain с PBFT + DPOs.

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

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

X.Tx confirmation

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

X.Block confirmation

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

Forking from X.Block

К X.Block можно подключить до двух блоков. Первый блок - это основной блок, за которым следует X.Block. Номер блока этого блока - это номер блока X.Block + 1. Второй - это блок, который подключается после X.Block в SubChain, который создается начиная с X.Block. Номер блока этого блока имеет вид {ChainID}. {N}. Где {ChainID} - номер блока X.Block в MainChain, а {N} - порядок конкатенации блоков в subchain. Если номер блока равен 100, номер блока десятого блока составляет 100,10 в подцепочке X.Block. Аналогично, номер блока 20-го блока в другом SubChain, начиная с 200-го X.Block (номер блока: 100.200), существующего в SubChain, равен 100.200.20 Up to two blocks can be connected to X.Block. The first block is the main block followed by X.Block. This block has a block number the block number of X.Block + 1 . The second is the block that is connected after X.Block on the SubChain that is created starting from X.Block. The block number of this block is of the form {ChainID}.{N} . Here {ChainID}is the block number of X.Block in MainChain, and {N}is the block concatenation order in the subchain. If the block number is 100, the block number of the tenth block is 100.10in the subchain of X.Block. Similarly, the block number of the 20th block in another SubChain starting from the 200th X.Block (block number:100.200) existing in the SubChain is 100.200.20 .

Asset Model

X.Blockchain может генерировать несколько SubChains через X.Block, которые могут разветвляться и могут продолжать соединение. Однако это ветвление в X.Block вызывает ‘проблему двойного платежа’ в криптографических транзакциях. Следовательно, не должно быть никакой корреляции между журналом транзакций, который управляется в MainChain и журналом транзакций, который управляется в SubChain. Чтобы решить эту проблему, необходимо тщательно отделить учетную запись, управляемую каждой блочной цепочкой, или сам актив (сам журнал транзакций) должен быть отдельным.

X.Blockchain отделяет активы. В X.Blockchain активы на MainChain, активы на SubChain и активы на другом SubChain - это разные активы. Другими словами, все SubChains, включая MainChain, имеют свои собственные активы (монеты) и независимый журнал транзакций, который регистрирует статус этих активов. Активы по каждому SubChain в основном запрещены путем взаимной передачи активов между различными торговыми механизмами. Однако, согласно процедуре Связь между SubChains можно перемещать активы между различными SubChains.

Accounts & States

Запись всех неизменных данных о состоянии, таких как транзакции между отдельными учетными записями на X.Blockchain, данных для проверки целостности, записывается с использованием структуры IAVL + tree. Различные значения состояния, обрабатываемые X.Blockchain, организованы в формате key-value, и хранятся в структуре IAVL + tree, и определяется Merkle Root Hash - наивысшее хэш-значение этого tree. Другими словами, изменение состояния конкретной учетной записи приводит к изменению значения Merkle Root Hash, и это значение Merkle Root Hash включено в блок, так что состояние всей учетной записи отражается в каждом блоке. В случае, если требуется реконфигурация из-за добавления или изменения нового узла, в соответствии с модифицированным алгоритмом AVL Algorithm с временной сложностью O(log(n)), происходит реконфигурация tree. Так как каждый SubChain имеет независимые активы, журнал транзакций, представляющий статус активов каждой учетной записи, также должен быть независимым для каждого SubChain. Поэтому каждый SubChain имеет собственную структуру IAVL + tree для независимого управления учетными записями.

Currency & Issurance

В настоящее время активы ATX X.Blockchain были выпущены в общей сложности на 1, 000,000,000 ATX, включая сумму, предоставленную через ICO и нераспределенную прибыль. Текущий общий объем выпуска будет сохраняться до тех пор, пока основная сеть X.Blockchain не будет открыта, а затем общий объем выпуска будет постепенно увеличиваться в зависимости от дополнительных проблем. Дополнительная выдача ATX заключается в предотвращении централизации ATX, которая может произойти с течением времени. Если соответствующие дополнительные методы выпуска не предоставляются, ATX может быть сконцентрирован в некоторых производителях блоков во имя транзакционных сборов с течением времени, и фактическая сумма денег, обращающихся на рынке, может уменьшиться. Без дальнейшей выдачи и предоставления сильных стимулов, необходимых для поддержания цепочки блоков, исчезнет или, по крайней мере, будет сокращена в серьезной степени. В сети с блочной цепочкой, такой как X.Blockchain, где более высокие уровни доверия могут быть защищены при участии производителей блоков, это может привести к фатальным проблемам. С другой стороны, неограниченная дополнительная выдача вызывает инфляцию, которая уменьшает реальную стоимость денег, что, в свою очередь, может ослабить мотивацию вышеупомянутых участников сети блокчейнов. С точки зрения политики, связанной с валютой блокчейна Etherium, которая является типичной блок-цепью открытого типа, Etherium объясняет, что можно смягчить феномен «концентрации богатства», позволяя ежегодно выпускать и поставлять предопределенное количество Etherium. Темпы роста предложения постоянно снижаются и сводятся к нулю, предоставляя фиксированную сумму дополнительной эмиссии, и это дает возможность нынешним или будущим участникам продолжать получать Etherium путем майнинга, а не покупая на рынке. В то же время говорится, что количество эфириумов, которые будут выпущены, будет балансироваться с суммой денег, которая исчезнет из-за небрежности пользователей с течением времени. Ниже приведена часть белой бумаги Etherium.

Постоянная модель роста линейного предложения снижает риск того, что некоторые считают чрезмерной концентрацией богатства в Биткойне, и дает людям, живущим в нынешних и будущих эпохах, шанс получить валютные единицы, и в то же время сохранить сильный стимул для получения и удержания эфириума, поскольку ?темпы роста предложения?в процентах по-прежнему со временем становятся равными нулю. Мы также теоретизируем, что, поскольку монеты всегда теряются с течением времени из-за небрежности, смерти и т. д., и потери монет могут быть смоделированы в процентах от общего объема предложения в год, что общий объем предложения валюты в обращении фактически стабилизируется при стоимости равный годовой эмиссии, деленной на коэффициент потерь (например, при коэффициенте убыточности 1%, после того, как предложение достигнет 26X, тогда будет добываться 0,26X и 0,26X теряться каждый год, создавая равновесие).

Долгосрочный рост спроса и предложения

X.Blockchain, пользуясь моделью эфириума, основывается на политике «модели роста постоянных лайнеров» (permanent liner supply growth model), производящих дополнительную выдачу фиксированного количества. Мы намерены установить соответствующие ставки темпа роста предложения относительно объема первоначальной эмиссии ATX, и по средствам осуществления проверки и тестов, направленных на решение таких вопросов, как поддержание настоящей денежной массы и проблемы инфляции, постепенно измененять эту цену. Оптимальная начальная скорость роста предложения будет определяться во время основного открытия сети. Разумеется, проведение совещаний, касательно изменения этой цены, будет доступно и после открытия главной сети, однако в настоящее время упоминание об этом может привести к неточным прогнозам, поэтому мы опустим разъяснения по этому поводу.

Долгосрочный темп роста предложения X.Blockchain

Стимулирование

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

Use Cases

Система управления регистрацией резидентов

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

Вид	2016год
Количество миграц	7,378
Процент миграции (%)	14.4%
Количество отчётов о миграции	4,636
Коэффициент миграции (женщина=100)	103.9

Источник: Корейские Национальние Статистические Данные 「Статистика внутренней миграции населения Кореи」, [Един.измерения: 1000 человек, тысячи случаев]

Согласно информации, опубликованной Национальным статистическим порталом Республики Корея (http://kosis.kr), общая численность населения данной страны на конец 2015 года составила 51,525,338 человек. Документ о регистрации гражданина по месту жительства существует лишь в одном экземпляре, поэтому при каждой смене адреса гражданин обязан её обновлять. Согласно приведенным ниже данным, в 2016 году обновление данного документа произошло 7, 378, 000 раз⁵. Если выразить это в виде линейной цепи блоков, то начальная цепь блоков будет выражать общее количество населения, и к ней следует добавить число блоков, соответствующее числу мигрирующего каждый год населения. Если начать применение данного способа с 2016 года, то на конец 2016 года количество блоков в блокчейн будет следующим:

$51,525,338 + 7,378,000 = 58,903,338$

И, если допустить, что в год среднее количество мигрирующего населения составляет 7, 000, 000 чел., то, следовательно, в год добавляется 7 млн. блоков. Принимая за размер одной цепи – 80 bytes⁶, подсчитаем общий размер блочной цепочки, содержащей записи, накопленные за 10 лет. Вычисления в данном случае будут выглядеть следующим образом:

$\begin {aligned}\text{Full Blockchain's Size} &= \frac{51,525,338 + 7,000,000 \times 10}{1024^3} \times 80 \\ &= 9.1 G\end {aligned}$

Следовательно, в случае блокчейн с линейной структурой, накопленный в течение 10 лет размер блокчейн 9.1 G, а также ежегодное увеличение 0.52 G линейно возрастают.

Если применить аналогичные условия к Блокчейн, то общее число блоков и их размеры будут совпадать, однако изменяющееся количество блоков, возрастающее каждый год, не будет линейно соединяться с MainChain, а будет формироваться из SubChain. Иначе говоря, 70,000,000 блоков, изменявшихся в течение 10 лет, будут формироваться из SubChain, состоящего из 51,525,338 блоков и входящего в MainChain. Если применить степень дисперсии измененного блока к SubChain MainChain как простое среднее арифметическое, то 1блок MainChain имеет 1 SubChain, а SubChain приобретает 1,35 блоков ⁷. Размер блокчейн для каждого отдельного человека населения выглядит следующим образом:

$\begin {aligned}\text{SubChain Size (avg.)} &= \frac{7,000,000 \times 10}{51,525,338} \times 80 \\ &= 108.68 B \\\\\text{MainChain Size} &= \frac{51,525,338}{1024^3} \times 80 \\ &= 3.83 G\end {aligned}$

В отличие от блокчейна с линейной структурой, при X.Blockchain возможно выборочное управление требуемыми функциями. Возможно наличие такой услуги, как регистрация определенного миллиона граждан при возникновении причины. В таком случае для проверки истории изменений регистрации (прописки) одного миллиона граждан за 10 лет, необходима следующая общая ёмкость памяти:

$\begin {aligned}3.83 G + \frac{108.68 B \times 1,000,000}{1024^3} = 3.93 G\end {aligned}$

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

В данной воображаемой ситуации не были учтены изменения (увеличение)⁸ SubChain, зависящее от таких показателей как уровень роста, смертность, число браков / разводов, MainChain, зависящего, в свою очередь, от уровня рождаемости. В связи с этим в действительности понадобится весь блокчейн ещё больших размеров. Кроме этого, критерием классификации MainChain не обязательно должен становиться 1 человек от всего населения, равно как нет необходимости включать в один блок лишь один документ (Transaction). Следовательно, рассчитанное выше значение не является реальным, а подразумевает лишь относительное значение, служащее для сравнения X.Blockchain, обладающего многомерной структурой, с блокчейном, обладающего линейной структурой. Несмотря на то, что приведенный выше пример применяется только к одному документу, прописке граждан, в действительности одновременно могут применяться различные публичные документы. Чем больше документов добавлено, тем резче возрастает относительная эффективность сравнительной многомерной цепочки блоков по сравнению с линейной блочной цепью.
Допустим, если в приведенном выше примере будет добавлен ещё один публичный документ и если транзакция, такая как история изменения документа, будет происходить с таким же коэффициентом, как и регистрация гражданина, то в случае с линейным блокчейн, возникнет необходимость в, двойном увеличении блоков во время добавления 1 документа. Если будет добавлен другой документ, то так же происходит увеличение того же блока. Однако в случае X.Blockchain, изменение размеров MainChain не происходит, а поскольку добавление всех блоков в соответствии с типом добавленного документа происходит только в SubChain, увеличивается и относительная эффективность X.Blockchain многомерной структуры.

1. Полный узел - это узел, который хранит целую блок-цепочку и выполняет новую операцию разработки блоков. ↩

2. В качестве решения данной проблемы Биткойн предлагает SPV. Это метод минимизации ресурсов, необходимых для выполнения проверки транзакции, при которой используется только информация заголовка блока, за исключением данных транзакции, что является существенным в приложении цепочки блоков для электронных документов. Если в криптографии транзакция состоит из транзакционной информации, то данные электронного документа становятся основной частью транзакции в приложении электронного документа. В это же время размер документа настолько велик, что его нельзя сравнить с историей транзакций криптографической валюты, так что цепочка блоков не включает сами данные документа. Если в этом документе не указано иное, ‘размер цепочки блоков’ означает ‘размер заголовка блока’. ↩

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

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

5. Согласно данным, опубликованным Национальным статистическим порталом РК, точное число мигрантов в 2016 году составляет 7,378,383 человека. ↩

6. Размер блока заголовка Bitcoin составляет 81 bytes. ↩

7. Это соответствует среднему числу мигрантов в течение 10 лет на население. ↩

8. Чем больше прирост SubChain, тем выше эффективность многомерной структуры X.Blockchain. ↩

X.Blockchain

Technical White Paper