Binary file paper/sigos.pdf has changed

--- a/paper/sigos.tex	Thu May 09 15:15:51 2019 +0900
+++ b/paper/sigos.tex	Thu May 09 16:24:42 2019 +0900
@@ -13,17 +13,17 @@
 
 
   \lstset{
-    language=C, 
-    tabsize=2, 
+    language=C,
+    tabsize=2,
     frame=single, 
     basicstyle={\ttfamily\footnotesize},% 
     identifierstyle={\footnotesize},% 
     commentstyle={\footnotesize\itshape},% 
     keywordstyle={\footnotesize\bfseries},% 
-    ndkeywordstyle={\footnotesize},% 
+    ndkeywordstyle={\footnotesize}, 
     stringstyle={\footnotesize\ttfamily}, 
-    breaklines=true, 
-    captionpos=b, %キャプションの位置 
+    breaklines=true,
+    captionpos=b,%キャプションの位置 
     columns=[l]{fullflexible},% 
     xrightmargin=0zw,% 
     xleftmargin=1zw,% 
@@ -63,12 +63,18 @@
 
 
 \paffiliate{IPSJ}{琉球大学工学部情報工学科\\
-Information Engineering, University of the Ryukyus.}
+Information Engineering,University of the Ryukyus.}
 
 
-\author{一木貴裕}{Takahiro Itsuki}{IPSJ}
-\author{赤堀貴一}{Ki-ichi Akahori}{IPSJ}
-\author{河野真治}{Shinji KONO}{IPSJ}
+\author{一木 貴裕}{Takahiro Itsuki}{IPSJ}
+%\author{赤堀貴一}{Ki-ichi Akahori}{IPSJ}
+\author{河野 真治}{Shinji KONO}{IPSJ}
+
+\contact{一木 貴裕\\
+        〒903-2213 沖縄県宜野湾市志真市1-16-5 曙荘III 4-J号室\\
+	琉球大学工学部情報工学科\\
+        TEL: (080)-8262-6637\qquad FAX: (0538)-85-2170\\
+        email: ikki-tkhr@cr.ie.u-ryukyu.ac.jp}
 
 
 \begin{abstract}
@@ -91,7 +97,7 @@
 \end{eabstract}
 
 \begin{ekeyword}
-Distributed Computation, Block chain
+Distributed Computation， Block chain
 \end{ekeyword}
 
 \maketitle
@@ -99,9 +105,9 @@
 %1
 \section{Block Chain と Gears OS}
 
-コンピュータのデータに不整合は起こり得る. 不整合は誤操作や, 複数人によるデータの同時書き込みによって起こる.
+コンピュータのデータに不整合は起こり得る． 不整合は誤操作や， 複数人によるデータの同時書き込みによって起こる．
 特に分散環境下で問題になる。
-ブロックチェーンはデータを分散でき, 不整合の検知が可能な仕組みを提供していう。
+ブロックチェーンはデータを分散でき， 不整合の検知が可能な仕組みを提供していう。
 当研究室で開発中のGearsOSの分散ファイルシステムの技術として、ブロックチェーンが使用できるかどうかを調査中である。
 そのために当研究室ではJava上で開発された分散フレームワーク
 Christieにブロックチェーンを実装することにした。
@@ -110,12 +116,12 @@
 
 %2
 \section{ブロックチェーンの概要}
-%2.1
+%2．1
 %\subsection{P2P (Peer-to-Peer)}			
-ブロックチェーンはP2Pにてネットワーク間が動作している,つまり.ブロックチェーンネットワークにはサーバー,クライアントの区別がなく,全てのノードが平等である.そのため,非中央時にデータの管理をおこなう.
+ブロックチェーンはP2Pにてネットワーク間が動作している，つまり．ブロックチェーンネットワークにはサーバー，クライアントの区別がなく，全てのノードが平等である．そのため，非中央時にデータの管理をおこなう．
 
-ブロックチェーンにおけるブロックは,複数のトランザクションをまとめたものである.
-ブロックの構造は使用するコンセンサスアルゴリズムによって変わるが,基本的な構造としては次のとおりである.
+ブロックチェーンにおけるブロックは，複数のトランザクションをまとめたものである．
+ブロックの構造は使用するコンセンサスアルゴリズムによって変わるが，基本的な構造としては次のとおりである．
 \begin{itemize}
 \item BlockHeader
 \begin{itemize}
@@ -126,9 +132,9 @@
 \item TransactionList
 \end{itemize}
 
-BlockHeaderには,前のブロックをハッシュ化したもの,トランザクションをまとめたmerkle treeのrootのhash,そのブロックを生成したtimeとなっている.
-previous block hashは,前のブロックのパラメータを選べてhash化したものである.
-それが連なっていることで図2.1のようなhash chainとして,ブロックがつながっている. %図はrefで
+BlockHeaderには，前のブロックをハッシュ化したもの，トランザクションをまとめたmerkle treeのrootのhash，そのブロックを生成したtimeとなっている．
+previous block hashは，前のブロックのパラメータを選べてhash化したものである．
+それが連なっていることで図2．1のようなhash chainとして，ブロックがつながっている． %図はrefで
 
 
 \begin{figure}[h]
@@ -138,233 +144,229 @@
 \end{center}
 \end{figure}
 
-そのため,一つのブロックが変更されれば,その後につながるブロック全てを更新しなければいけなくなる.
-ブロックが生成された場合,知っているノードにそのブロックをブロードキャストする.
-実際には通信量を抑えるためにブロック高を送った後、ブロックをシリアライズして送信する場合もある.% ブロック高はタイポ?
+そのため，一つのブロックが変更されれば，その後につながるブロック全てを更新しなければいけなくなる．
+ブロックが生成された場合，知っているノードにそのブロックをブロードキャストする．
+実際には通信量を抑えるためにブロック高を送った後、ブロックをシリアライズして送信する場合もある．% ブロック高はタイポ?
 
-ノードごとにブロックを検証し,誤りがあればそのブロックを破棄し,誤りがなければ更にそのノードがブロックをブロードキャストする.
-そして,Transaction PoolというTransactionを貯めておく場所から,そのブロックに含まれているTransactionを削除し,新しいブロックを生成する.
+ノードごとにブロックを検証し，誤りがあればそのブロックを破棄し，誤りがなければ更にそのノードがブロックをブロードキャストする．
+そして，Transaction PoolというTransactionを貯めておく場所から，そのブロックに含まれているTransactionを削除し，新しいブロックを生成する．
 
 %\begin{quote}
 %\small
-%\|http://www.ipsj.or.jp/journal/submit/style.html|
+%\|http://www．ipsj．or．jp/journal/submit/style．html|
 %\end{quote}
 
 %\subsection{トランザクションとその構造}
-トランザクションとはデータのやり取りを行った記録の最小単位である. 
-トランザクションの構造は次のとおりである.
+トランザクションとはデータのやり取りを行った記録の最小単位である． 
+トランザクションの構造は次のとおりである．
 \begin{description}
-\item[TransactionHash] トランザクションをハッシュ化したもの.
-\item[data] データ.
-\item[sendAddress] 送り元のアカウントのアドレス.
-\item[recieveAddress] 送り先のアカウントのアドレス.
-\item[signature] トランザクションの一部と秘密鍵をSHA256でハッシュ化したもの.  ECDSAで署名している.
+\item[TransactionHash] トランザクションをハッシュ化したもの．
+\item[data] データ．
+\item[sendAddress] 送り元のアカウントのアドレス．
+\item[recieveAddress] 送り先のアカウントのアドレス．
+\item[signature] トランザクションの一部と秘密鍵をSHA256でハッシュ化したもの．  ECDSAで署名している．
 \end{description}
 
-トランザクションはノード間で伝搬され,ノードごとに検証される.
-そして検証を終え,不正なトランザクションであればそのトランザクションを破棄し,検証に通った場合はTransaction Poolに取り組まれ,また検証したノードからトランザクションがブロードキャストされる.
+トランザクションはノード間で伝搬され，ノードごとに検証される．
+そして検証を終え，不正なトランザクションであればそのトランザクションを破棄し，検証に通った場合はTransaction Poolに取り組まれ，また検証したノードからトランザクションがブロードキャストされる．
 
 %\subsection{fork}
-ブロックの生成をした後にブロードキャストをすると,ブロック高の同じ,もしくは相手のブロック高の高いブロックチェーンにたどり着く場合がある.
-当然,相手のブロックチェーンはこれを破棄する.
-しかしこの場合,異なるブロックを持った2つのブロックチェーンをこの状態をforkと呼ぶ.
-fork状態になると,2つの異なるブロックチェーンができることになるため,一つにまとめなければならない.
-１つにまとめるためにコンセンサスアルゴリズムを用いるが,コンセンサスアルゴリズムについては次章で説明する.
+ブロックの生成をした後にブロードキャストをすると，ブロック高の同じ，もしくは相手のブロック高の高いブロックチェーンにたどり着く場合がある．
+当然，相手のブロックチェーンはこれを破棄する．
+しかしこの場合，異なるブロックを持った2つのブロックチェーンをこの状態をforkと呼ぶ．
+fork状態になると，2つの異なるブロックチェーンができることになるため，一つにまとめなければならない．
+１つにまとめるためにコンセンサスアルゴリズムを用いるが，コンセンサスアルゴリズムについては次章で説明する．
 
 %\section{Proof of Workを用いたコンセンサス}
-ブロックチェーンでは,パブリックブロックチェーンの場合とコンソーシアムブロックチェーンによってコンセンサスアルゴリズムが変わる.
-この章ではパブリックブロックチェーンのBitcoin,Ethereumに使われているProof of Workとコンソーシアムブロックチェーンに使えるPaxosを説明する。
+ブロックチェーンでは，パブリックブロックチェーンの場合とコンソーシアムブロックチェーンによってコンセンサスアルゴリズムが変わる．
+この章ではパブリックブロックチェーンのBitcoin，Ethereumに使われているProof of Workとコンソーシアムブロックチェーンに使えるPaxosを説明する。
 
 %\subsection{Proof of Workを用いたコンセンサス}
-パブリックブロックチェーンとは,不特定多数のノードが参加するブロックチェーンシステムのことをさす。
-よって,不特定多数のノード間,全体のノードの参加数が変わる状況でコンセンサスが取れるアルゴリズムを使用しなければならない.
-Proof of Workは不特定多数のノードを対象としてコンセンサスが取れる.
-ノードの計算量によってコンセンサスを取るからである.
-次のような問題が生じてもProof of Workはコンセンサスを取ることができる.
+パブリックブロックチェーンとは，不特定多数のノードが参加するブロックチェーンシステムのことをさす。
+よって，不特定多数のノード間，全体のノードの参加数が変わる状況でコンセンサスが取れるアルゴリズムを使用しなければならない．
+Proof of Workは不特定多数のノードを対象としてコンセンサスが取れる．
+ノードの計算量によってコンセンサスを取るからである．
+次のような問題が生じてもProof of Workはコンセンサスを取ることができる．
 
 \begin{enumerate}
-\item プロセス毎に処理の速度が違う. つまり, メッセージの返信が遅い可能性がある
-\item 通信にどれだけの時間がかかるかわからず, その途中でメッセージが失われる可能性がある, 
-\item プロセスは停止する可能性がある. また, 復旧する可能性もある.
-\item 悪意ある情報を他のノードが送信する可能性がある.
+\item プロセス毎に処理の速度が違う． つまり， メッセージの返信が遅い可能性がある
+\item 通信にどれだけの時間がかかるかわからず， その途中でメッセージが失われる可能性がある， 
+\item プロセスは停止する可能性がある． また， 復旧する可能性もある．
+\item 悪意ある情報を他のノードが送信する可能性がある．
 \end{enumerate}
-Proof of Workに必要なパラメータは次のとおりである.
+Proof of Workに必要なパラメータは次のとおりである．
 
 \begin{itemize}
 \item nonce
 \item difficulty
 \end{itemize}
-nonceはブロックのパラメータに含まれる.
-difficultyはProof of Workの難しさ,正確にいえば１つのブロックを生成する時間を調整している.Proof of Workはこれらのパラメータを使って次のようにブロックを作る. 
+nonceはブロックのパラメータに含まれる．
+difficultyはProof of Workの難しさ，正確にいえば１つのブロックを生成する時間を調整している．Proof of Workはこれらのパラメータを使って次のようにブロックを作る． 
 
 \begin{enumerate}
-\item ブロックとnonceを加えたものをハッシュ化する. この際, nonceによって, ブロックのハッシュは全く違うものになる.
-\item ハッシュ化したブロックの先頭から数えた0ビットの数がdifficultyより多ければ, そのブロックにnonceを埋め込み, ブロックを作る. 
-\item 2の条件に当てはまらなかった場合はnonceに1を足して, 1からやり直す.
+\item ブロックとnonceを加えたものをハッシュ化する． この際， nonceによって， ブロックのハッシュは全く違うものになる．
+\item ハッシュ化したブロックの先頭から数えた0ビットの数がdifficultyより多ければ， そのブロックにnonceを埋め込み， ブロックを作る． 
+\item 2の条件に当てはまらなかった場合はnonceに1を足して， 1からやり直す．
 \end{enumerate}
-difficulty = 2でProof of Workの手順を図にしたものを図３.1に示す. %refで
+difficulty = 2でProof of Workの手順を図にしたものを\ref{fig:example-of-Proof}に示す． %refで
 
 \begin{figure}[h]
 \begin{center}
 \includegraphics[width=240pt]{./images/proof-of-work.pdf}
 \caption{proof-of-workの例}
-\end{center}
-\end{figure}
-
-2の条件については,単純に(桁数 - difficulty + 1) * 10 $>$ hash とも置き換えることができる.\\nonceを変えていくことで,hashはほぼ乱数のような状態になる.つまり,difficultyを増やすほど,条件に当てはまるhashが少なくなっていくことがわかり,そのhashを探すための計算量も増えることがわかる.\\これがProof of Workでブロックを生成する手順となる.これを用いることによって,ブロックが長くなるほど,すでに作られたブロックを変更することは計算量が膨大になるため,不可能になっていく.Proof of Workでノード間のコンセンサスを取る方法は単純で,ブロックの長さの差が一定以上になった,場合,長かったブロックを正しいものとする.これを図で示すと3.2のようになる.\\
-
-\begin{figure}[h]
-\begin{center}
-\includegraphics[width=240pt]{./images/proof-of-work-fork.pdf}
-\caption{Proof of Workのコンセンサス}
+\label{fig:example-of-Proof}
 \end{center}
 \end{figure}
 
-計算量の差が51\%以上になると,forkしたブロック同士で差が生まれる.
-それによって,IPアドレスでのコンセンサではなく,CPUの性能によるコンセンサスを取ることができる.
+2の条件については，単純に(桁数 - difficulty + 1) * 10 $>$ hash とも置き換えることができる．\\nonceを変えていくことで，hashはほぼ乱数のような状態になる．つまり，difficultyを増やすほど，条件に当てはまるhashが少なくなっていくことがわかり，そのhashを探すための計算量も増えることがわかる．\\これがProof of Workでブロックを生成する手順となる．これを用いることによって，ブロックが長くなるほど，すでに作られたブロックを変更することは計算量が膨大になるため，不可能になっていく．Proof of Workでノード間のコンセンサスを取る方法は単純で，ブロックの長さの差が一定以上になった，場合，長かったブロックを正しいものとする．これを図で示すと\ref{fig:fork}のようになる．\\
+
+\begin{figure}[h]
+\includegraphics[width=240pt]{./images/proof-of-work-fork.pdf}
+\caption{Proof of Workのコンセンサス}
+\label{fig:fork}
+\end{figure}
 
-コンセンサスでは,ブロックとの差が大きければ大きいほど,コンセンサスが正確に取れる.
-しかし,正しいチェーンが決まるのに時間がかかる.
-そのため,コンセンサスに必要なブロックの差はコンセンサスの正確性と時間のトレードオフになっている.
+計算量の差が51\%以上になると，forkしたブロック同士で差が生まれる．
+それによって，IPアドレスでのコンセンサではなく，CPUの性能によるコンセンサスを取ることができる．
 
-この方法でコンセンサスを取る場合の欠点を挙げる.
+コンセンサスでは，ブロックとの差が大きければ大きいほど，コンセンサスが正確に取れる．
+しかし，正しいチェーンが決まるのに時間がかかる．
+そのため，コンセンサスに必要なブロックの差はコンセンサスの正確性と時間のトレードオフになっている．
+
+この方法でコンセンサスを取る場合の欠点を挙げる．
 \begin{itemize}
-\item CPUのリソースを使用する. 
-\item Transactionが確定するのに時間がかかる. 
+\item CPUのリソースを使用する． 
+\item Transactionが確定するのに時間がかかる． 
 \end{itemize}
 
 %\subsection{Paxos}
-コンソーシアムブロックチェーンは許可したのノードのみが参加できるブロックチェーンである.
-そのため,ノードの数も把握できるため,Paxosを使うことができる.
-Paxosはノードの多数決によってコンセンサスを取るアルゴリズムである.ただし,Paxosは次のような問題があっても値を一意に決めることができる.
+コンソーシアムブロックチェーンは許可したのノードのみが参加できるブロックチェーンである．
+そのため，ノードの数も把握できるため，Paxosを使うことができる．
+Paxosはノードの多数決によってコンセンサスを取るアルゴリズムである．ただし，Paxosは次のような問題があっても値を一意に決めることができる．
 \begin{enumerate}
-\item プロセス毎に処理の速度が違う. つまり, メッセージの返信が遅い可能性がある
-\item 通信にどれだけの時間がかかるかわからず, その途中でメッセージが失われる可能性がある, 
-\item プロセスは停止する可能性がある. また, 復旧する可能性もある.
+\item プロセス毎に処理の速度が違う． つまり， メッセージの返信が遅い可能性がある
+\item 通信にどれだけの時間がかかるかわからず， その途中でメッセージが失われる可能性がある， 
+\item プロセスは停止する可能性がある． また， 復旧する可能性もある．
 \end{enumerate}
-Proof of Workにある特性の4がないが,コンソーシアムブロックチェーンは3つの問題を解決するだけで十分である.何故ならば,コンソーシアムブロックチェーンは許可したノードのみが参加可能だからである.つまり,悪意あるノードが参加する可能性が少ないためである.//
-Paxosは3つの役割ノードがある.
+Proof of Workにある特性の4がないが，コンソーシアムブロックチェーンは3つの問題を解決するだけで十分である．何故ならば，コンソーシアムブロックチェーンは許可したノードのみが参加可能だからである．つまり，悪意あるノードが参加する可能性が少ないためである．//
+Paxosは3つの役割ノードがある．
 \begin{description}
-\item[proposer] 値を提案するノード.
-\item[acceptor] 値を決めるノード.
-\item[learner] acceptorから値を集計し, 過半数以上のacceptorが持っている値を決める.
+\item[proposer] 値を提案するノード．
+\item[acceptor] 値を決めるノード．
+\item[learner] acceptorから値を集計し， 過半数以上のacceptorが持っている値を決める．
 \end{description}
-Paxosのアルゴリズムの説明の前に,定義された用語の解説をする.いかにその用語の定義を示す.
+Paxosのアルゴリズムの説明の前に，定義された用語の解説をする．いかにその用語の定義を示す．
 
 \begin{description}
-\item[提案] 提案は, 異なる提案ごとにユニークな提案番号と値からなる. 提案番号とは, 異なる提案を見分けるための識別子であり, 単調増加する. 値は一意に決まってほしいデータである.
-\item[値(提案)がacceptされる] acceptorによって値(提案)が決まること. 
-\item[値(提案)が選択(chosen)される] 過半数以上のacceptorによって, 値(提案)がacceptされた場合, それを値(提案)が選択されたと言う.
+\item[提案] 提案は， 異なる提案ごとにユニークな提案番号と値からなる． 提案番号とは， 異なる提案を見分けるための識別子であり， 単調増加する． 値は一意に決まってほしいデータである．
+\item[値(提案)がacceptされる] acceptorによって値(提案)が決まること． 
+\item[値(提案)が選択(chosen)される] 過半数以上のacceptorによって， 値(提案)がacceptされた場合， それを値(提案)が選択されたと言う．
 
-paxosのアルゴリズムは2フェーズある.
-1つ目のフェーズ,prepare-promiseは次のような手順で動作する.
+paxosのアルゴリズムは2フェーズある．
+1つ目のフェーズ，prepare-promiseは次のような手順で動作する．
 
-1フェーズ目を図にしたものを図3.3に示す.
+1フェーズ目を図にしたものを\ref{fig:prepare-promise}に示す．
 
 \begin{figure}[h]
-\begin{center}
 \includegraphics[width=240pt]{./images/prepare-promise.pdf}
-\caption{Proof of Workのコンセンサス}
-\end{center}
+\label{fig:prepare-promise}
+\caption{Proof of Workの例}
 \end{figure}
 
 
-2つ目のフェーズ, accept-acceptedは次のような手順で動作する. 
+2つ目のフェーズ， accept-acceptedは次のような手順で動作する． 
 \begin{enumerate}
-\item proposerは過半数のacceptorから返信が来たならば, 次の提案をacceptorに送る. これをacceptリクエストという.
+\item proposerは過半数のacceptorから返信が来たならば， 次の提案をacceptorに送る． これをacceptリクエストという．
 \begin{enumerate}
-\item もし, 約束のみが返ってきているならば, 任意の値vをprepareリクエストで送った提案に設定する.
-\item もし, acceptされた提案が返ってきたら, その中で最大の提案番号を持つ提案の値v'をprepareリクエストで送った提案の値として設定する.
+\item もし， 約束のみが返ってきているならば， 任意の値vをprepareリクエストで送った提案に設定する．
+\item もし， acceptされた提案が返ってきたら， その中で最大の提案番号を持つ提案の値v'をprepareリクエストで送った提案の値として設定する．
 \end{enumerate}
 
-\item acceptorはacceptリクエストが来た場合, Promiseした提案よりもacceptリクエストで提案された提案番号が低ければ, その提案を拒否する. それ以外の場合はacceptする.
+\item acceptorはacceptリクエストが来た場合， Promiseした提案よりもacceptリクエストで提案された提案番号が低ければ， その提案を拒否する． それ以外の場合はacceptする．
 \end{enumerate}
-２フェーズ目を図にしたものを図3.4に示す.
+２フェーズ目を図にしたものを図\ref{fig:Proof-of-Work}に示す．
 
 \begin{figure}[h]
-\begin{center}
 \includegraphics[width=240pt]{./images/accept-accepted.pdf}
+\label{fig:Proof-of-Work}
 \caption{Proof of Workのコンセンサス}
-\end{center}
 \end{figure}
 
-このアルゴリズムによって,各acccepterごとに値が一意の決まる.値を集計,選択するのはLearnerの役割である.Learnerが値を集計する方法には2つの方法である.
+このアルゴリズムによって，各acccepterごとに値が一意の決まる．値を集計，選択するのはLearnerの役割である．Learnerが値を集計する方法には2つの方法である．
 
 \begin{enumerate}
-\item Acceptorによって値がacceptされた時に, 各Learnerに送信される. ただし, Message通信量が, Acceptorの数 times Learnerの数になる.
-\item 1つのLearnerが各Learnerに選択された値を送信する. 1の方法に比べてMessage通信量が少なくなる(Acceptorの数 + Learnerの数になる)代わりに, そのLearnerが故障した場合は各LearnerがMessageを受け取れない.
+\item Acceptorによって値がacceptされた時に， 各Learnerに送信される． ただし， Message通信量が， Acceptorの数 times Learnerの数になる．
+\item 1つのLearnerが各Learnerに選択された値を送信する． 1の方法に比べてMessage通信量が少なくなる(Acceptorの数 + Learnerの数になる)代わりに， そのLearnerが故障した場合は各LearnerがMessageを受け取れない．
 \end{enumerate}
 
-2つの方法はメッセージ通信量と耐障害性のトレードオフになっていることがわかる.
-Paxosでコンセンサスを取ることは, Proof of Workと比較して次のようなメリットがある.
+2つの方法はメッセージ通信量と耐障害性のトレードオフになっていることがわかる．
+Paxosでコンセンサスを取ることは， Proof of Workと比較して次のようなメリットがある．
 
 \begin{itemize}
 \item CPUのリソースを消費しない
-\item Transactionの確定に時間がかからない.
+\item Transactionの確定に時間がかからない．
 \end{itemize}
 
 %\subsection{Paxosによるブロックチェーン}
-PaxosはProof of Workと比べ,CPUのリソースを消費せず,Transactionの確定に時間がかからない.
-そのため,Paxosでブロックのコンセンサスを取るブロックチェーンを実装することにはメリットがある.
-また,Paxos自体がリーダー選出に向いているアルゴリズムである.
-そのため,リーダーを決め,そのノードのブロックチェーンの一貫性のみを考えることもできる.
+PaxosはProof of Workと比べ，CPUのリソースを消費せず，Transactionの確定に時間がかからない．
+そのため，Paxosでブロックのコンセンサスを取るブロックチェーンを実装することにはメリットがある．
+また，Paxos自体がリーダー選出に向いているアルゴリズムである．
+そのため，リーダーを決め，そのノードのブロックチェーンの一貫性のみを考えることもできる．
 
 \section{Chrsitie}
 %\subsection{Christieとは}
-Christieは当研究室で開発している分散フレームワークである.
-Christieは当研究室で開発しているGearsOSに組み込まれる予定がある. %GearsOSとは
-そのためGearsOSを構成する言語Continuation based Cと似た概念がある.
-Christieに存在する概念として次のようなものがある.
+Christieは当研究室で開発している分散フレームワークである．
+Christieは当研究室で開発しているGearsOSに組み込まれる予定がある． %GearsOSとは
+そのためGearsOSを構成する言語Continuation based Cと似た概念がある．
+Christieに存在する概念として次のようなものがある．
 \begin{itemize}
 \item CodeGear(以下 CG)
 \item DataGear(以下 DG)
 \item CodeGearManager(以下 CGM)
 \item DataGearManager(以下 DGM)
 \end{itemize}
-CGはクラス,スレッドに相当し,javaの継承を用いて記述する.
-DGは変数データに相当し,CG内でアノテーションを用いて変数データを取り出せる.
-CGMはノードであり,DGM,CG,DGMを管理する.
-DGMはDGを管理するものであり,putという操作により変数データ,すなわちDGを格納できる.
-DGMのput操作を行う際にはLocalとRemoteと2つのどちらかを選び,変数のkeyとデータを引数に書く.
-Localであれば,LocalのCGMが管理しているDGMに対し,DGを格納していく.
-Remoteであれば接続したRemote先のCGMのDGMにDGを格納できる.
-put操作を行った後は,対象のDGMの中にqueとして補完される.
-DGを取り出す際には,CG内で宣言した変数データにアノテーションをつける.
-DGのアノテーションにはTake,Peek,TakeFrom,PeekFromの4つがある.
+CGはクラス，スレッドに相当し，javaの継承を用いて記述する．
+DGは変数データに相当し，CG内でアノテーションを用いて変数データを取り出せる．
+CGMはノードであり，DGM，CG，DGMを管理する．
+DGMはDGを管理するものであり，putという操作により変数データ，すなわちDGを格納できる．
+DGMのput操作を行う際にはLocalとRemoteと2つのどちらかを選び，変数のkeyとデータを引数に書く．
+Localであれば，LocalのCGMが管理しているDGMに対し，DGを格納していく．
+Remoteであれば接続したRemote先のCGMのDGMにDGを格納できる．
+put操作を行った後は，対象のDGMの中にqueとして補完される．
+DGを取り出す際には，CG内で宣言した変数データにアノテーションをつける．
+DGのアノテーションにはTake，Peek，TakeFrom，PeekFromの4つがある．
 
 
 \begin{description}
-\item[Take] 先頭のDGを読み込み, そのDGを削除する. DGが複数ある場合, この動作を用いる.
-\item[Peek] 先頭のDGを読み込むが, DGが削除されない. そのため, 特に操作をしない場合は同じデータを参照し続ける. 
-\item[TakeFrom(Remote DGM name)] Takeと似ているが, Remote DGM nameを指定することで, その接続先(Remote)のDGMからTake操作を行える.
-\item[PeekFrom(Remote DGM name)] Peekと似ているが, Remote DGM nameを指定することで, その接続先(Remote)のDGMからPeek操作を行える.
+\item[Take] 先頭のDGを読み込み， そのDGを削除する． DGが複数ある場合， この動作を用いる．
+\item[Peek] 先頭のDGを読み込むが， DGが削除されない． そのため， 特に操作をしない場合は同じデータを参照し続ける． 
+\item[TakeFrom(Remote DGM name)] Takeと似ているが， Remote DGM nameを指定することで， その接続先(Remote)のDGMからTake操作を行える．
+\item[PeekFrom(Remote DGM name)] Peekと似ているが， Remote DGM nameを指定することで， その接続先(Remote)のDGMからPeek操作を行える．
 \end{description}
 
 
 %\subsection{プログラミングの例}
-ここでは,Christieで実際にプログラムを記述する例を述べる.
-CGMを作り,setup(new CodeGear)を動かすことにより,DGを持ち合わせ,DGが揃った場合にCodeGearが実装される.
-CGMを作る方法はStartCodeGear(以下SCG)を継承したものからcreate-CGM(port)methodを実行することによりCGMが作られる.
-SCGのコードの例をソースコード4.1に示す. %refを使う
+ここでは，Christieで実際にプログラムを記述する例を述べる．
+CGMを作り，setup(new CodeGear)を動かすことにより，DGを持ち合わせ，DGが揃った場合にCodeGearが実装される．
+CGMを作る方法はStartCodeGear(以下SCG)を継承したものからcreate-CGM(port)methodを実行することによりCGMが作られる．
+SCGのコードの例をソースコード\ref{code:StartHelloWorld}に示す． %refを使う
 
-\begin{flushleft}
-\lstinputlisting[label=code:StartHelloWorld, caption=StartHelloWorld]{./src/HelloWorld/StartHelloWorld.java}
-\end{flushleft}
+\lstinputlisting[caption=StartHelloWorld, label=code:StartHelloWorld]{./src/HelloWorld/StartHelloWorld.java}
 
 \end{description}
 
 %\subsection{TopologyManager}
-Christieは当研究室で開発されたAliceを改良した分散フレームワークである.
-しかし,Aliceの機能を全て移行したわけではない.
-TopologyManagerは最たる例であり.分散プログラムを簡潔に書くために必要である.
-そのため,ChristieにTopoplogyManagerを実装した.
+Christieは当研究室で開発されたAliceを改良した分散フレームワークである．
+しかし，Aliceの機能を全て移行したわけではない．
+TopologyManagerは最たる例であり．分散プログラムを簡潔に書くために必要である．
+そのため，ChristieにTopoplogyManagerを実装した．
 
 
-ここではTopologyManagerがどのようなものかを述べる.
-TopologyManagerとは,Topologyを形成するために,参加を表明したノード,TopologyNodeに名前を与え,必要があればノード同士の配線も行うコードである.
-TopologyManagerのTopology形成方法として,静的Topologyと動的Topologyがある.
-静的Topologyはコード\ref{code:dot-example}のようなdotファイルを与えることで,ノードの関係を図\ref{fig:dot-example}のようにする.
-静的Topologyはdotがいるのノード数と同等のTopologyNodeがあって初めて,CodeGearが実行される.
+ここではTopologyManagerがどのようなものかを述べる．
+TopologyManagerとは，Topologyを形成するために，参加を表明したノード，TopologyNodeに名前を与え，必要があればノード同士の配線も行うコードである．
+TopologyManagerのTopology形成方法として，静的Topologyと動的Topologyがある．
+静的Topologyはコード\ref{code:dot-example}のようなdotファイルを与えることで，ノードの関係を図\ref{fig:dot-example}のようにする．
+静的Topologyはdotがいるのノード数と同等のTopologyNodeがあって初めて，CodeGearが実行される．
  
  \lstinputlisting[caption=ring.dot, label=code:dot-example]{./src/ring.dot}
  
@@ -376,48 +378,49 @@
 \end{center}
 \label{fig:dot-example}
 \end{figure}
- 動的Topologyは参加を表明したノードに対し,動的にノード同士の関係を作る.例えばTreeを構成する場合,参加したノードから順に,rootに近い位置の役割を与える.また,CodeGearはノードが参加しmparentに接続された後に実行される.
+ 動的Topologyは参加を表明したノードに対し，動的にノード同士の関係を作る．例えばTreeを構成する場合，参加したノードから順に，rootに近い位置の役割を与える．また，CodeGearはノードが参加しmparentに接続された後に実行される．
  
 %\subsection{Chrisiteにおけるブロックチェーンの実装の利点と欠点}
 
 
-Christieにおいてブロック, トランザクション, Paxos, Proof of Workを実装した. 
-その際, Christieで実装した場合の便利な点を述べる. %こういうの書かない
+Christieにおいてブロック, トランザクション，Paxos， Proof of Workを実装した． 
+ 利点を以下に述べる．
+ %こういうの書かない
 
 \begin{itemize}
-\item データの取り出しが簡単. ChristieはDataGearという単位でデータを保持する. そのため, ブロックやトランザクションはDataGearに包めばいいため, どう送るかという問題を考えなくてすむ. 
-\item TopologyManagerでのテストが便利. dotファイルが有れば, TopologyManagerが任意の形でTopologyを作れる. そのため, ノードの配置については理想の環境を作れるため, 理想のテスト環境を作ることができる. 
-\item 機能ごとにファイルが実装できるため, 見通しが良い. ChristieはCbCのgotoと同じように関数が終わるとsetupによって別の関数に移動する. そのため自然に機能ごとにファイルを作るため, 見通しが良くなる.
+\item データの取り出しが簡単． ChristieはDataGearという単位でデータを保持する． そのため， ブロックやトランザクションはDataGearに包めばいいため， どう送るかという問題を考えなくてすむ． 
+\item TopologyManagerでのテストが便利． dotファイルが有れば， TopologyManagerが任意の形でTopologyを作れる． そのため， ノードの配置については理想の環境を作れるため， 理想のテスト環境を作ることができる． 
+\item 機能ごとにファイルが実装できるため， 見通しが良い． ChristieはCbCのgotoと同じように関数が終わるとsetupによって別の関数に移動する． そのため自然に機能ごとにファイルを作るため， 見通しが良くなる．
 \end{itemize}
 
-不便な点を以下に述べる. %こういうの書かない
+欠点を以下に述べる． %こういうの書かない
 
 \begin{itemize}
-\item デバッグが難しい. cgm.setupでCodeGearが実行されるが, keyの待ち合わせで止まり, どこのCGで止まっているかわからないことが多かった. 例えば, putするkeyのスペルミスでコードの待ち合わせが起こり, CGが実行されず, エラーなども表示されずにwaitすることがある. その時に, どこで止まっているか特定するのが難しい.
-\item TakeFrom, PeekFromの使い方が難しい. TakeFrom, PeekFromは引数でDGM nameを指定する. しかし, DGMの名前を静的に与えるよりも, 動的に与えたい場合が多かった.
-\item Takeの待ち合わせでCGが実行されない. 2つのCGで同じ変数をTakeしようとすると, setupされた時点で変数がロックされる. このとき, 片方のCGはDGがすべて揃っているのに, すべての変数が揃っていないもう片方のCGに同名の変数がロックされ, 実行されない場合がある. 
+\item デバッグが難しい． cgm．setupでCodeGearが実行されるが， keyの待ち合わせで止まり， どこのCGで止まっているかわからないことが多かった． 例えば， putするkeyのスペルミスでコードの待ち合わせが起こり， CGが実行されず， エラーなども表示されずにwaitすることがある． その時に， どこで止まっているか特定するのが難しい．
+\item TakeFrom， PeekFromの使い方が難しい． TakeFrom， PeekFromは引数でDGM nameを指定する． しかし， DGMの名前を静的に与えるよりも， 動的に与えたい場合が多かった．
+\item Takeの待ち合わせでCGが実行されない． 2つのCGで同じ変数をTakeしようとすると， setupされた時点で変数がロックされる． このとき， 片方のCGはDGがすべて揃っているのに， すべての変数が揃っていないもう片方のCGに同名の変数がロックされ， 実行されない場合がある． 
 \end{itemize}
 
 \section{評価}
 % 評価と利点と欠点は別物なの?
-本研究室では,実際にコンセンサスアルゴリズムPaxosを分散環境場で実行した,分散環境場で動かすため,JobSchedulerの一種であるTorque Resource Manager(Torque)を使用した.
+本研究室では，実際にコンセンサスアルゴリズムPaxosを分散環境場で実行した，分散環境場で動かすため，JobSchedulerの一種であるTorque Resource Manager(Torque)を使用した．
 
 %\subsection{Torqueとは}
-PCクラスタ上でプログラムの実験を行う際には,他のプログラムとリソースを取り合う懸念がある.
-それを防ぐためにTorqueを使用する.
-Torqueはjobという単位でプログラムを管理し,リソースを確保できたら実行する.
-jobはqsubというコマンドを使って,複数登録することができる.
+PCクラスタ上でプログラムの実験を行う際には，他のプログラムとリソースを取り合う懸念がある．
+それを防ぐためにTorqueを使用する．
+Torqueはjobという単位でプログラムを管理し，リソースを確保できたら実行する．
+jobはqsubというコマンドを使って，複数登録することができる．
 
-また,実行中の様子もqstatというコマンドを使うことで監視ができる.
-Torqueには主に3つのNodeの種類がある.
+また，実行中の様子もqstatというコマンドを使うことで監視ができる．
+Torqueには主に3つのNodeの種類がある．
 
 \begin{description}
-\item[Master Node] pbs\_serverを実行しているノード. 他のノードの役割とも併用できる.
-\item[Submit/Interactive Nodes] クライアントがjobを投入したり監視したりするノード. qsubやqstatのようなクライアントコマンドが実行できる.
-\item[Computer Nodes] 投入されたjobを実際に実行するノード. pbs\_momが実行されており, それによってjobをstart, kill, 管理する.
+\item[Master Node] pbs\_serverを実行しているノード． 他のノードの役割とも併用できる．
+\item[Submit/Interactive Nodes] クライアントがjobを投入したり監視したりするノード． qsubやqstatのようなクライアントコマンドが実行できる．
+\item[Computer Nodes] 投入されたjobを実際に実行するノード． pbs\_momが実行されており， それによってjobをstart， kill， 管理する．
 \end{description}
 
-今回は図\ref{fig:kvm}のように,KVM上にMaster Node, Submit/Interactive Nodeの役割を持つVM1台と,Computer Nodesとして15台のVMうぶbを用意し,jobの投入を行なった.
+今回は図\ref{fig:kvm}のように，KVM上にMaster Node， Submit/Interactive Nodeの役割を持つVM1台と，Computer Nodesとして15台のVMを用意し，jobの投入を行なった．
 % タイポ
 
 \begin{figure}[h]
@@ -428,19 +431,19 @@
 \label{fig:kvm}
 \end{figure}
 
-jobはシェルスクリプトの形で与えることができる.ソースコードref{code:torque-example}を例として挙げる.
+jobはシェルスクリプトの形で与えることができる．ソースコード\ref{code:torque-example}を例として挙げる．
 
-\lstinputlisting[caption=torque-example.sh,label=code:torque-example]{./src/torque-example.sh}
+\lstinputlisting[caption=torque-example.sh, label=code:torque-example]{./src/torque-example.sh}
 
-「\#PBS オプション」とすることにより実行環境を設定できる. 使用できるオプションは参考文献に書かれてある.   %いらなさそう + 参考文献の番号が必要
-このスクリプトでは, ノード数10(vm0からvm9まで), jobの名前を「ExampleJob」という形で実行する設定をしている. もし, このコードを投入した場合, Submit/Interactive Nodesが各vmにsshし, hostnameコマンドを実行する. 
-実行後はstdout, stderrorの出力を「job名.o数字」, 「job名.e数字」というファイルに書き出す.
+「\#PBS オプション」とすることにより実行環境を設定できる． 使用できるオプションは参考文献に書かれてある．   %いらなさそう + 参考文献の番号が必要
+このスクリプトでは， ノード数10(vm0からvm9まで)， jobの名前を「ExampleJob」という形で実行する設定をしている． もし， このコードを投入した場合， Submit/Interactive Nodesが各vmにsshし， hostnameコマンドを実行する． 
+実行後はstdout， stderrorの出力を「job名．o数字」， 「job名．e数字」というファイルに書き出す．
 
 %\subsection{PCクラスタ上でのPaxosの実際の動作}
-PCクラスタ上で実際にPaxosを動かした際の解説をする.
-今回は単純化し,proposerの数を2,accepterの数を3,learnerの数を1としてPaxosを動かし,値が一意に決まる過程を見る.
-実験の単純化の為に,提案の数値を整数とし,各processerごとに異なった値とした.
-正確には,「proposer + 数字」の部分を値とし,コンセンサスを取るようにした.実際にPaxosを動かし,シーケンス図で結果を示したものが図\ref{fig:paxos}である. 
+PCクラスタ上で実際にPaxosを動かした際の解説をする．
+今回は単純化し，proposerの数を2，accepterの数を3，learnerの数を1としてPaxosを動かし，値が一意に決まる過程を見る．
+実験の単純化の為に，提案の数値を整数とし，各processerごとに異なった値とした．
+正確には，「proposer + 数字」の部分を値とし，コンセンサスを取るようにした．実際にPaxosを動かし，シーケンス図で結果を示したものが図\ref{fig:paxos}である． 
 
 \begin{figure}[h]
 \begin{center}
@@ -450,13 +453,17 @@
 \label{fig:paxos}
 \end{figure}
 
-一意の値を決めることができており,また,Learnerが値を選択した後でも,Paxosは常に決めた値を持ち続けるアルゴリズムである.ログの出力では提案番号がより大きいものの提案まで続いていたが,値がこれ以上覆らなかった。
-今回はわかりやすいよう値を数字で行なった実験であるが,これをタランザクション,ブロックに応用することで,ブロックチェーンにおけるコンセンサス部分を完成させることができる. %わかりやすいようとか書かない
+一意の値を決めることができており，また，Learnerが値を選択した後でも，Paxosは常に決めた値を持ち続けるアルゴリズムである．ログの出力では提案番号がより大きいものの提案まで続いていたが，値がこれ以上覆らなかった。
+今回は値を数字で行なった実験であるが，これをタランザクション，ブロックに応用することで，ブロックチェーンにおけるコンセンサス部分を完成させることができる． 
+%わかりやすいようとか書かない
 
 \section{計測実験}
 
 \section{まとめ}
 
+\nocite{*}
+\bibliographystyle{ipsjunsrt}
+\bibliography{sigos}
 
  
  \end{document}