|
12
|
1 \documentclass[twocolumn,twoside,9.5pt]{jarticle}
|
|
|
2 \usepackage[dvipdfmx]{graphicx}
|
|
|
3 \usepackage{picins}
|
|
|
4 \usepackage{fancyhdr}
|
|
|
5 \usepackage{abstract}
|
|
13
|
6 \usepackage{here}
|
|
12
|
7 \usepackage{url}
|
|
|
8 %\pagestyle{fancy}
|
|
|
9 \lhead{\parpic{\includegraphics[height=1zw,keepaspectratio,bb=0 0 251 246]{pic/emblem-bitmap.pdf}}琉球大学主催 工学部情報工学科 卒業研究発表会}
|
|
|
10 \rhead{}
|
|
|
11 \cfoot{}
|
|
|
12
|
|
|
13 \setlength{\topmargin}{-1in \addtolength{\topmargin}{15mm}}
|
|
|
14 \setlength{\headheight}{0mm}
|
|
|
15 \setlength{\headsep}{5mm}
|
|
|
16 \setlength{\oddsidemargin}{-1in \addtolength{\oddsidemargin}{11mm}}
|
|
|
17 \setlength{\evensidemargin}{-1in \addtolength{\evensidemargin}{21mm}}
|
|
|
18 \setlength{\textwidth}{181mm}
|
|
|
19 \setlength{\textheight}{261mm}
|
|
|
20 \setlength{\footskip}{0mm}
|
|
|
21 \pagestyle{empty}
|
|
|
22
|
|
|
23 \input{dummy.tex}
|
|
|
24 \renewcommand{\abstractname}{Abstract}
|
|
|
25 \begin{document}
|
|
|
26 \title{Blockchain implements in Christie}
|
|
|
27 \author{155753A 氏名 {赤堀}{貴一} 指導教員 : 河野 真治}
|
|
|
28 \date{}
|
|
|
29 \twocolumn [
|
|
|
30 \maketitle
|
|
|
31 \begin{onecolabstract}
|
|
|
32
|
|
13
|
33 Data corruption and inconsistency in computers causes severe problem. Therefore, we detect corruption and inconsistency by Blockchain. The Blockchain is a distributed system. It is possible to compare between hash value and data which is correct. Even if there are incorrect operation and tampering, data are possible to recover with Blockchain.
|
|
12
|
34
|
|
|
35 We are developing Christie and GearsOS. Christie is a distributed framework and GearsOS is a Operating System. GearsOS Filesystem will refer to Christie. if implementing block chain in Christie and implementing it in GearsOS, makes it possible to detect data corruption and inconsistency in the GearsOS file system. In addition, it is possible to configure decentralized distributed network between Gears OS. if it does not configure, data is protected. So, our purpose can be achieved.
|
|
|
36
|
|
|
37 In this study, We implement Blockchain in Christie and run it in distributed environment on PC cluster.
|
|
|
38 \end{onecolabstract}]
|
|
|
39 \thispagestyle{fancy}
|
|
|
40
|
|
|
41 \section{研究目的}
|
|
|
42
|
|
13
|
43 ブロックチェーンとは分散型台帳技術とも呼ばれ, 複数のトランザクションをまとめたブロックをHashでつなげたものを, システムに参加しているすべてのノードが保持できる技術である.
|
|
12
|
44
|
|
13
|
45 当研究室では分散フレームワークとしてChristieを開発している. これはGearsOSにファイルシステムに組み込む予定がある. そのため, Christieにブロックチェーンを実装し, GearsOSに組み込むことにより, GearsOSのファイルシステムにおいてデータの不整合を検知できる. また, GearsOS同士による分散ファイルシステムを構成することができ, 非中央的にデータの分散ができるようになる. もし分散システムを構成しない場合でもデータの整合性保持は行え, 上記の目的は達成できる.
|
|
12
|
46
|
|
|
47 本研究では, Christieにブロックチェーンを実装し, 実際に学科のPCクラスタ上の分散環境で動かす.
|
|
|
48
|
|
|
49 \section{ブロックチェーン}
|
|
|
50 ブロックチェーンを実装することは次のようなメリットが有る.
|
|
|
51
|
|
|
52 \begin{itemize}
|
|
|
53 \item データの追跡, 検証が容易である.
|
|
|
54 \item 中央管理者が存在しない. 単一障害点がない.
|
|
|
55 \end{itemize}
|
|
|
56
|
|
|
57 データの追跡, 検証が容易であるのは, ブロックの構造によるものである. ブロックの構造は簡易化すれば次のようなものである.
|
|
|
58
|
|
|
59 \begin{itemize}
|
|
|
60 \item 前のブロックの暗号化ハッシュ.
|
|
|
61 \item タイムスタンプ.
|
|
|
62 \item トランザクションリスト.
|
|
|
63 \end{itemize}
|
|
|
64
|
|
|
65 ブロックは図\ref{fig:chain}のようにhashでつながっている. 一つのブロックが変更されれば, その後に連なるブロックも整合性が保たれないため, これによってデータの整合性保持が行える.
|
|
|
66
|
|
13
|
67 \begin{figure}[H]
|
|
12
|
68 \centering
|
|
|
69 \fbox{
|
|
|
70 \includegraphics[scale=0.3]{./images/chain.pdf}
|
|
|
71 }
|
|
|
72 \caption{hash chain}
|
|
|
73 \label{fig:chain}
|
|
|
74 \end{figure}
|
|
|
75
|
|
|
76
|
|
13
|
77 トランザクション, ブロックともにノード間で伝搬され, ノードごとに検証される. そして検証を終え, 不正なトランザクション, ブロックであれば破棄する. 検証に通った場合は, トランザクションはTransaction PoolにTransactionを貯めておき, ブロックはブロックチェーンに取り組まれ, 検証したノードからトランザクション, ブロックがブロードキャストされる. ノード間はP2Pで通信が行われている.
|
|
12
|
78
|
|
|
79 同時に異なるノードで複数のブロックができることを, forkという. これによってブロックチェーンの分岐が起こる.
|
|
|
80 ブロックチェーンの分岐を収束させるにはコンセンサスアルゴリズムを使用する.
|
|
|
81
|
|
|
82 \section{コンセンサスアルゴリズム}
|
|
|
83 コンセンサスアルゴリズムとは, 一意の値を分散環境上で決めるためのアルゴリズムである.
|
|
|
84
|
|
13
|
85 今回は分散アルゴリズムとしてPaxosを実装した.
|
|
|
86
|
|
|
87 Paxosは3つの役割のノードがある.
|
|
|
88
|
|
|
89 \begin{description}
|
|
|
90 \item[proposer] 値を提案するノード.
|
|
|
91 \item[acceptor] 値を決めるノード.
|
|
|
92 \item[learner] acceptorから値を集計し, 過半数以上のacceptorが持っている値を決める.
|
|
|
93 \end{description}
|
|
|
94
|
|
|
95 Paxosのアルゴリズムに入る前に, 定義された用語を説明する. 以下にその用語の定義を示す.\begin{description}
|
|
|
96 \item[提案] 提案は, 異なる提案ごとにユニークな提案番号と値からなる. 提案番号とは, 異なる提案を見分けるための識別子であり, 単調増加する. 値は一意に決まってほしいデータである.
|
|
|
97 \item[値(提案)がacceptされる] acceptorによって値(提案)が決まること.
|
|
|
98 \item[値(提案)が選択(chosen)される] 過半数以上のacceptorによって, 値(提案)がacceptされた場合, それを値(提案)が選択されたと言う.
|
|
|
99 \end{description}
|
|
|
100
|
|
|
101
|
|
|
102 Paxosのアルゴリズムは2フェーズある.
|
|
|
103
|
|
|
104 1つ目のフェーズ, prepare-promiseは次のような手順で動作する.
|
|
|
105 \begin{enumerate}
|
|
|
106 \item proposerは提案番号nを設定した提案を過半数以上のacceptorに送る. これをprepareリクエストという.
|
|
|
107 \item acceptorはprepareリクエストが来たら次の動作をする.
|
|
|
108 \begin{enumerate}
|
|
|
109 \item もし, 以前に送られたprepareリクエストの提案番号より, 今送られてきたprepareリクエストの提案番号のほうが大きければ, それ以下の提案番号の提案を拒否するという約束を返す. この状態をPromiseしたという.
|
|
|
110 \item もし, 値がすでにacceptされていれば, accpetされた提案を返す.
|
|
|
111 \end{enumerate}
|
|
12
|
112
|
|
13
|
113 \end{enumerate}
|
|
|
114
|
|
|
115 2つ目のフェーズ, accept-acceptedは次のような手順で動作する.
|
|
|
116 \begin{enumerate}
|
|
|
117 \item proposerは過半数のacceptorから返信が来たならば, 次の提案をacceptorに送る. これをacceptリクエストという.
|
|
|
118 \begin{enumerate}
|
|
|
119 \item もし, 約束のみが返ってきているならば, 任意の値vをprepareリクエストで送った提案に設定する.
|
|
|
120 \item もし, acceptされた提案が返ってきたら, その中で最大の提案番号を持つ提案の値v'をprepareリクエストで送った提案の値として設定する.
|
|
|
121 \end{enumerate}
|
|
|
122
|
|
|
123 \item acceptorはacceptリクエストが来た場合, Promiseした提案よりもacceptリクエストで提案された提案番号が低ければ, その提案を拒否する. それ以外の場合はacceptする.
|
|
|
124 \end{enumerate}
|
|
|
125
|
|
|
126
|
|
|
127 このアルゴリズムによって, 各accptorごとに値が一意に決まる. 値を集計, 選択するのはLearnerの役割である. Learnerが値を集計する方法には2つの方法がある.
|
|
|
128
|
|
|
129 \begin{enumerate}
|
|
|
130 \item Acceptorによって値がacceptされた時に, 各Learnerに送信される. ただし, Message通信量が, $Acceptorの数 \times Learnerの数$になる.
|
|
|
131 \item 1つのLearnerが各Learnerに選択された値を送信する. 1の方法に比べてMessage通信量が少なくなる($Acceptorの数 + Learnerの数$になる)代わりに, そのLearnerが故障した場合は各LearnerがMessageを受け取れない.
|
|
|
132 \end{enumerate}
|
|
|
133
|
|
|
134 2つの方法はメッセージ通信量と耐障害性のトレードオフになっていることがわかる.
|
|
|
135
|
|
|
136 Paxosでコンセンサスを取ることは, Proof of Workと比較して次のようなメリットがある.
|
|
|
137
|
|
|
138 \begin{itemize}
|
|
|
139 \item CPUのリソースを消費しない
|
|
|
140 \item Transactionの確定に時間がかからない.
|
|
|
141 \end{itemize}
|
|
12
|
142
|
|
|
143 \section{Christie}
|
|
|
144
|
|
|
145 Christieは当研究室で開発している分散フレームワークである. ChristieはJavaで書かれているが, 当研究室で開発しているGearsOSに組み込まれる予定がある. そのため, GearsOSを構成する言語Continuation based Cと似た概念がある. Christieに存在する概念として次のようなものがある.
|
|
|
146
|
|
|
147 \begin{itemize}
|
|
|
148 \item CodeGear(以下CG)
|
|
|
149 \item DataGear(以下DG)
|
|
|
150 \item CodeGearManager(以下CGM)
|
|
|
151 \item DataGearManager(以下DGM)
|
|
|
152 \end{itemize}
|
|
|
153
|
|
|
154 CGはクラス, スレッドに相当し, DGは変数データに相当する. CGMはノードであり, DGM, CG, DGを管理する. DGMはDGを管理するものであり, putという操作により変数データ, つまりDGを格納できる.
|
|
|
155
|
|
|
156 DGMにはLocalとRemoteと2つの種類があり, Localであれば, LocalのCGMが管理しているDGMに対し, DGを格納していく. Remoteであれば接続したRemote先のCGMのDGMにDGを格納できる. DGを取り出す際にはアノテーションを付けることで, データの取り出し方も指定できる. Take, Peekという操作があり, Takeは読み込んだDGが消えるが, PeekはDGを消さずにそのまま残す. また, RemoteTake, RemotePeekというものもあり, リモート先を指定することにより, RemoteDGMからデータを取ることができる.
|
|
|
157
|
|
|
158 CGはCGMによって実行されるが, 実行するにはCGに必要なDGが全て揃う必要がある. もしDGが全て揃わない場合, CGMはずっとlistenし, データが揃うまで実行を待つ.
|
|
|
159
|
|
13
|
160 \section{Christieでのブロックチェーンの実装}
|
|
|
161 Christieでブロックチェーンのブロック, トランザクション, Paxosを実装した.
|
|
|
162
|
|
|
163 その際の, Christieの便利な点を述べる.
|
|
|
164
|
|
|
165 \begin{itemize}
|
|
|
166 \item ブロック, トランザクションを送るのが簡単. ChristieはDataGearという単位でデータを保持する. そのため, ブロックやトランザクションはDataGearに包めばいい.
|
|
|
167 \item TopologyManagerでのテストが便利. dotファイルが有れば, TopologyManagerが任意の形でTopologyを作れる. そのため, ノードの配置については理想の環境を作れるため, 理想のテスト環境を作ることができる.
|
|
|
168 \item ソースコードの機能ごとにファイルが実装できるため, 見通しが良い. ChristieはCbCのgotoと同じように関数が終わるとsetupによって別の関数に移動する. そのため自然に機能ごとにファイルを作るため, 見通しが良くなる.
|
|
|
169 \end{itemize}
|
|
|
170
|
|
|
171 不便な点を以下に述べる.
|
|
|
172
|
|
|
173 \begin{itemize}
|
|
|
174 \item デバッグが難しい. DGでのkeyのスペルミスなどが起こると, CodeGearが実行されず, waitされる問題が出る.
|
|
|
175 \item TakeFrom, PeekFromの使い方が難しい. TakeFrom, PeekFromは引数でDGM nameを指定する. しかし, DGMの名前を静的に与えるよりも, 動的に与えたい場合が多かった.
|
|
|
176 \item Takeの待ち合わせでCGが実行されない. 2つのCGで同じ変数をTakeしようとすると, setupされた時点で変数がロックされる. このとき, 片方のCGはDGがすべて揃っているのに, すべての変数が揃っていないもう片方のCGに同名の変数がロックされ, 実行されない場合がある.
|
|
|
177 \end{itemize}
|
|
|
178
|
|
|
179
|
|
|
180
|
|
|
181
|
|
|
182 \section{実験, 評価}
|
|
|
183 ブロックチェーンにおいて, 分散環境上でテストしなければいけないのはコンセンサスアルゴリズムである. そのため, Paxosを実装し, 琉球大学のPCクラスタ上で動かした.
|
|
|
184
|
|
|
185 今回は単純化のために, 整数でコンセンサスを取る. ノードはproposerが2つ, acceptorが3つ, learnerが1つという構成で実験する.
|
|
|
186
|
|
|
187 Paxosの実験は3回行った. Paxosにはlog4j2を実装しており, logを取るようにしている. そのため, そのlogから値が一意に決まるまでを調べた. 1つの実験の結果を図\ref{fig:paxos2}に示す.
|
|
|
188
|
|
|
189 \begin{figure}[h]
|
|
|
190 \centering
|
|
|
191 \fbox{
|
|
|
192 \includegraphics[scale=0.45]{./images/paxos2.pdf}
|
|
|
193 }
|
|
|
194 \caption{実験の結果1}
|
|
|
195 \label{fig:paxos2}
|
|
|
196 \end{figure}
|
|
|
197
|
|
|
198 実際にLearnerの値が一意に決まっていることがわかる.
|
|
|
199
|
|
|
200
|
|
12
|
201
|
|
|
202 \section{まとめ}
|
|
|
203
|
|
|
204
|
|
13
|
205 本研究ではブロックチェーンと, 分散環境上で値を一意に決めるコンセンサスアルゴリズムを述べ, Christieという分散フレームワークで実際にPaxosを作り, PCクラスタ上で動かした. その結果, コンセンサスの結果として一意のデータが取り出せることがわかった.
|
|
|
206
|
|
|
207 まだPCクラスタ上ではブロックチェーンを動かすことができない. しかし, Block, Transaction, Hash生成, 署名のためのクラスはいずれも作られている. Transactionにおいてはまだファイルのデータを入れる機能は実装していないが, これらを組み合わせれば簡易的なブロックチェーンが作れる. そのため, あとはPaxosとこれらのクラスをどのようにつなげるかが問題となる.
|
|
|
208 また, Proof of Workを行うクラスも作られている. そのため, ブロックチェーンが実装できた場合, このクラスを用いてPaxosと速度比較も行える.
|
|
|
209
|
|
|
210 今後の課題としては, Paxosによるブロックチェーンを作り, 分散クラスタ上でファイルのやり取りができるかを見る. その際にどの程度スケーラビリティがあるのか, Proof of Workと比較し, どの程度速度が違うのかを見ていきたい.
|
|
|
211
|
|
|
212
|
|
|
213
|
|
12
|
214 \nocite{*}
|
|
|
215 \bibliographystyle{junsrt}
|
|
|
216 \bibliography{reference}
|
|
|
217 \end{document} |
