• 文書
  • モジュール
    • 前書き
    • 前書き
    • Contents
    • QURASブロックチェーンの構造
    • QURASブロックチェーンのCONSENSUS アルゴリズム
    • QURASブロックチェーンのVIRTUAL MACHINEの構造
    • QURASブロックチェーンの暗号化モジュール
    • QURASブロックチェーンのJSON-RPC
    • QURASブロックチェーンの構築
    • Future Projects
    • FUTUREのプロジェクトおよびサビース
    • 参照
    • 参照
  • テクニカルペーパー
  • 開発リファレンス
  • 日本語
    • EN
    • 日本語
  • 前書き
  • 前書き
  • Contents
  • QURASブロックチェーンの構造
  • QURASブロックチェーンのCONSENSUS アルゴリズム
  • QURASブロックチェーンのVIRTUAL MACHINEの構造
  • QURASブロックチェーンの暗号化モジュール
  • QURASブロックチェーンのJSON-RPC
  • QURASブロックチェーンの構築
  • Future Projects
  • FUTUREのプロジェクトおよびサビース
  • 参照
  • 参照
QURASブロックチェーンのCONSENSUS アルゴリズム

ブロックチェーンでConsensusアルゴリズムはブロックチェーンの特徴を規定する重要な指標である。

ブロックの歴史にさまざまなConsensusアルゴリズムが登場した。

ブロックの初期にPOW方式で具現されたBitcoinやEthereumで利用されるConsensusアルゴリズムから始めてPOS、DBFTなど多くのConsensusアルゴリズムが登場するようになった。

QURASブロックチェーンではDBFTアルゴリズムをConsensusアルゴリズムに利用する。

ここで私たちはブロックチェーンのシステムに適用されるByzantine Generals Problemの解決をどのように実現したかどうかを提案することになる。

ブロックチェーンのシステムにはどのような信頼できる機関がないためメッセージに対する正確性検証が難しい。

またブロックチェーンのシステムのすべてのノードはP2P方式で連結されており、ブロックチェーンに連結されたノードは任意の時刻に連結及び切断の可能性がある。

そして不正確な資料を受けてノードが消えることもできるようになる。このような問題点はブロックチェーン内に連結された正しくないノードにより発生することができる。

この時ブロックチェーンを形成していくConsensus Nodeに対して見ることにしよう。

私たちはP2Pネットですべてのノードに対して信頼できない。

Consensus Nodeの個数をNとする際、ここで不正直なノード個数をfだとしよう。

この時ブロックチェーンのシステムでブロックチェーンの安全指数はNとfによって決定されることとなる。

DBFTアルゴリズムでfが(N-1)/3よりも小さい場合、QURASブロックチェーンは安全である。

それではDBFTアルゴリズムについて具体的に見ることにしよう。

QURASブロックチェーンのシステムの構成

ブロックチェーンは分散帳簿のシステムとしてすべてのノードがP2Pネットに相互に接続されて形成されるようになる。

ノードに発生する全てのメッセージはP2Pネット全体にbroadcastされてブロックチェーンネットに接続したすべてのノードが受けることになる。

ここに大きく2つの形式のノードが存在するが、一つは一般的なノードであり、他の一つはConsensus Nodeである。

一般的なノードは帳簿の資料を伝送して交換する役割をする。つまり送ってくるメッセージについて受け付け、他の連結されたノードへ再送信する機能を遂行する。

Consensus Nodeは全体P2Pネットで提起されているメッセージの処理と分散帳簿を形成して維持していくノードである。

それでここにDigital署名を利用して伝送される資料に対する処理を進めることとしている。

すなわちあるノードiがTransactionを作って送る場合、ノードiはTransactionを自分のPrivate Keyを利用して署名して送っている。それでは他のノードでTransaction生成者のPublic Keyで検証して実地Transactionの変更があるのかどうかを検査することができる。

合意アルゴリズム

合意アルゴリズムで不正直なノード数が(n-1)/3より小さければブロックチェーンの安全性は確保されることになる。

ここでnはブロックチェーンを維持しているconsensus nodeの個数である。

この時このシステムで許容できる不正直なノード数は最大f=(n-1)/3となる。

実はブロックチェーンを維持するノードは一般的なノードではなくてConsensus Nodeである。

すべてのConsensus Nodeは現在のConsensusの状態を記録する状態表を維持しなければならない。

合意の始まりから最後まで利用されるデータの集まりをViewと呼ぶ。もし合意が現在Viewに到達しなければViewの変更を要求することになる。すべてのViewは0から始まって合意が行われるまでの間は一つずつ増加させ、vで区別することになる。

すべてのConsensus Nodeは数字0からn-1までの番号をつけて区別する。

合意作りで即ViewでConsensus Nodeの中の一つのノードが代表者役割をして残りのノードは投票者役割をすることになる。

代表者ノードの選出は次のアルゴリズムによって進行される。

現在ブロックの長さがhとしよう。それでは代表者ノードp=(h–v)mod nに決定することになる。

ここでvはView番号を示す。

新しい様式はConsensus Nodeから少なくともn-fの署名ですべての合意の項目で生成されるようになる。

ブロックが生成されれば新たなConsensusの会が再び開始されるようになる。

合意アルゴリズムの一般的な手続きは以下の通りである。

合意アルゴリズムの一般的な手続き

ブロックの生成間隔時間をtとして標準状況で次の手続きによってアルゴリズムが実行されるようになる。

  1. ノードはTransactionを生成して署名をしてQURASブロックチェーンにbroadcastする。 すべてのConsensus Nodeは発生するTransactionに検査をして自分のメモリ区域にデータを保管する。
  2. 以前のブロック生成後からt時間ほど過ぎた後、代表者に選出されたノードは次の項目としてメッセージを構成してConsensus Nodeらに送る。(ConsensusRequest) ブロックの高さh、View番号v、代表者ノード番号p、そしてpが生成したブロックとブロックの署名
  3. 代表者ノードが送ったメッセージを受ければノードは(例えばi番目のノードが受けた場合)次の項目で回答メッセージを送る。(ConsensusResponse) ブロックの高さh、View番号v、回答ノード番号i、ブロックに対する署名情報
  4. すべてのノードは少なくてもn-f以上のブロックに対する署名データを受け取った場合、合意で成功に見てブロックをQURASブロックチェーンに入る。
  5. すべてのノードはブロック情報を受ければブロックに含まれているtransactionを確認して自分のMempoolから削除する。
CHANGEVIEWに対する手続き

Chage Viewは一定時間の間に合意が行われない場合、Viewを変えて代表者を改めて選出して合意を継続する目的で実施する方式である。

ChangeViewを進める方式は大きく2つである。

一番目の場合はあるノードが代表者に選出されてConsensusRequestを送ったがn-f以下のConsensusResponseを受けた場合ChangeViewを行うことになる。

二番目の場合はView番号vについて2^(v+1)*t時間の間にConsensus Requestがない場合ChangeViewを行うことになる。

それではChangeViewの過程について具体的に見ることにしよう。

  1. kは現在ViewでChangeViewが発生した数を示す。初めてChangeViewが呼び出さればk=1に設定する。そしてVk=v+kに設定する。
  2. i番目のノードは次のパラメーターでChangeViewRequestを送る。 ブロックの高さh、View番号v、ノード番号i、vk
  3. もしノードが他のノードから(iにあたる)同じvkをパラメーターとするChangeViewRequestを少なくてもn-f犬以上もらう場合ViewChangeは成功と判断してvをvkに設定する。そしてvで合意を再び進行する。

もし 2(v+1)*t時間の間にChangeViewが行われない場合kを増加させて2から再び繰り返す。

TOKENの分配
XQCの分配

XQCトークンの発行総額は8億8888万8888件である。

XQGの分配

XQGの総発行量は888,888,888であり、ここで16,888,888XQGは先に初期発行し、残りのXQGはブロックが生成されるたびに採掘される。

ブロックは約15秒ごとに採掘され、年間約200万個のブロックが生成されます。

初めて200万個のブロックでは各ブロックごとに64XQGを採掘して200万ブロックごとにXQGの採掘の量は8個ずつ減少される。

減少は各ブロックごとに採掘されるXQGの量が4XQGになるまで続く。具体的に見ると、以下の表のとおりである。

スタートブロックの番号 終了ブロックの番号 ブロックごとに生成されるXQGの数 全体的に採掘されたXQGの数とパーセント数
1 2 million 64 128million, 14.4%
2,000,001 4 million 56 240million, 27%
4,000,001 6 million 48 336million, 37.8%
6,000,001 8 million 40 416million, 46.8%
8,000,001 10 million 32 480million, 54%
10,000,001 12 million 32 544million, 61.2%
12,000,001 14 million 24 592million, 66%
14,000,001 16 million 24 640million, 72%
16,000,001 18 million 16 672million, 75.6%
18,000,001 20 million 16 704million, 79.2%
20,000,001 22 million 16 736million, 82.8%
22,000,001 24 million 8 752million, 84.6%
24,000,001 26 million 8 768million, 86.4%
26,000,001 28 million 8 784million, 88.2%
28,000,001 30 million 8 800million, 90%
30,000,001 32 million 8 816million, 91.8%
32,000,001 34 million 4 824million, 92.7%
34,000,001 36 million 4 860million, 93.6%
...
右表に示すように、すべてのXQG は約23 年間で4600 万ブロックで採掘され、初年度はXQG の14.4%が採掘され、8 年後にはXQG の約72%が採掘される。
TOKENの手数料の分配

Token Feeの分配の機能はQURASブロックチェーンでトークンの管理者がトークンを発行した時に当該トークンの送受信のトランザクションで発生するFeeを管理者に分配する方式である。

QURASブロックチェーンを利用してトークンを生成したトークンの管理者は当該トークンを利用するユーザが支払うFeeをもらうことになる。

この時、ユーザが支払うFeeの100%は全部トークンの管理者(あるいは生成者)に行くのではなくてトークンの管理者とQURAS Consensusノードに分割して支払うことになる。

この時、トークンの管理者とQURAS Consensusノードに支払うコインのパーセントは6:4から8:2程度で自動調整されるように設計されている。

トークンの手数料の分配は下記の通りである。

手数料(XQG) 分配の比率
0.1コイン以下の場合 (0.1も含み) 8:2*
0.1~1コインの場合(1も含み) 7.5:2.5
1~5コインの場合(5も含み) 7:3
5~10コインの場合(10も含み) 6.5:3.5
10コイン以上の場合 6.4

**8:2はトランザクションの手数料の80%がQURAS Consensusノードに配分されて、手数料の20%がトークン発行者に配分されているということを意味する。

以下の図にはトークンの発行者に一定の範囲内でスマートコントラクトのトランザクションの手数料を受け取ることができる機会を提供する機能が詳細に説明されている。前述したように上記の設計ではトークンを発行するトークン発行者にトークンの取引手数料を返還することができる。一般的にトークンの手数料の返還比率は手数料の金額によって異なる。
トークンの手数料の分配

図7. Tokenの手数料の分配

システムの手数料
ガスの料金とガスリミット
qurasブロックチェーンではガス量とガスの料金を利用してスマートコントラクトの実行やトランザクションの伝送の手数料を確定する。consensusノードはガスの料金がより高い優先順位で取引を処理するようになっている。
ガスリミットはトランザクションが消費できる最大量を設定するのに使われ、スマートコントラクトを実行する時は複雑な契約を実行するほど、より多くのガスが必要となる。
また、プログラミング言語がチューリング完成言語であるだけに、契約ロジックが無限ループ状態にならないようにガス限度を設定してこれを避けるようにする。
トランザクションの手数料
  • Transparentのトランザクション
    正常的なXQG及びXQCの取引の場合、ガスの消費量は使用者が取引の際、一定の範囲内で選択できる。
    Qurasブロックチェーンを構築する時に、エンジンの内部でXQCとXQGの取引手数料の範囲を一定の範囲とし、構築を進める。
    取引手数料が多いほど優先順位が高まり、ブロックチェーン内で処理速度が速くなる。
  • AnonymouseとRingCTのトランザクション
    取引手数料は静的に定める。
XQCの送金
XQCの送金する時に取引手数料はXQGで支払う。
  • Transparentのトランザクション
    ユーザはXQCの取引時に、ブロックチェーンの構築する時に設定したXQC手数料の上限と下限間の任意の値で手数料を設定する。
    手数料を高く設定するほど、該当取引の処理優先度が高くなる。
  • AnonymouseとRingCTのトランザクション
    取引手数料は静的に定める
XQGの送金
XQGの送金する時に取引手数料はXQGで支払う。
  • Transparentのトランザクション
    ユーザはXQGの取引時に、ブロックチェーンの構築する時に設定したXQC手数料の上限と下限間の任意の値で手数料を設定する。
    手数料を高く設定するほど、該当取引の処理優先度が高くなる。
  • AnonymouseとRingCTのトランザクション
    取引手数料は静的に定める。
スマートコントラクトの手数料
ガスリミットによってスマートコントラクトの手数料に対する状況は以下の2つになる。
使用されたガスの量がガスリミットと同じか小さい場合
トランザクションの手数料 = ガスの料金 * (opcodeのガスの使用量)の手数料が支払われる。
トランザクションが実行され、余分のガスは払い戻される。
使用されたガスの量がガスリミットより大きい場合
取引手数料 = ガスの料金 * ガスリミットの手数料が支払われる。
この場合にはスマートコントラクトの発行が失敗し、すでに支払った手数料は払い戻されない。
それのためにユーザーは十分な手数料を設定し、スマートコントラクトを発行しなければならない。
QURASブロックチェーンの構造 QURASブロックチェーンのVIRTUAL MACHINEの構造
  • QURASブロックチェーンのシステムの構成
  • 合意アルゴリズム
  • 合意アルゴリズムの一般的な手続き
  • CHANGEVIEWに対する手続き
  • TOKENの分配
  • XQCの分配
  • XQGの分配
  • TOKENの手数料の分配
  • システムの手数料
  • ガスの料金とガスリミット
  • トランザクションの手数料
  • スマートコントラクトの手数料
Tweets by @qurasofficial
Tweets by qurasofficial
  • 文書
  • テクニカルペーパー
  • 開発リファレンス
私たちはここにいる!
コミュニティ
  • Quras Telegram Group
  • Facebook
  • Twitter
更新を取得するためにあなたのEメールアドレスを登録しなさい

Copyright © 2019 Quras. All Rights Reserved.

info@quras.io