--- a/paper/sigos.tex	Thu May 09 12:30:38 2019 +0900
+++ b/paper/sigos.tex	Thu May 09 15:15:51 2019 +0900
@@ -64,8 +64,6 @@
 
 \paffiliate{IPSJ}{琉球大学工学部情報工学科\\
 Information Engineering, University of the Ryukyus.}
-\paffiliate{JU}{琉球大学大学院理工学研究科情報工学専攻\\
-Interdisciplinary Information Engineering, Graduate School of Engineering and Science, University of the Ryukyus.}
 
 
 \author{一木貴裕}{Takahiro Itsuki}{IPSJ}
@@ -111,13 +109,13 @@
 
 
 %2
-\section{ブロックチェーンについて}
+\section{ブロックチェーンの概要}
 %2.1
-\subsection{P2P (Peer-to-Peer)}			
+%\subsection{P2P (Peer-to-Peer)}			
 ブロックチェーンはP2Pにてネットワーク間が動作している,つまり.ブロックチェーンネットワークにはサーバー,クライアントの区別がなく,全てのノードが平等である.そのため,非中央時にデータの管理をおこなう.
 
-\subsection{ブロックとその構造}
-ブロックチェーンにおけるブロックは,複数のトランザクションをまとめたものである.ブロックの構造はしようするコンセンサスアルゴリズムによって変わるが,基本的な構造としては次のとおりである.
+ブロックチェーンにおけるブロックは,複数のトランザクションをまとめたものである.
+ブロックの構造は使用するコンセンサスアルゴリズムによって変わるが,基本的な構造としては次のとおりである.
 \begin{itemize}
 \item BlockHeader
 \begin{itemize}
@@ -128,7 +126,9 @@
 \item TransactionList
 \end{itemize}
 
-BlockHeaderには,前のブロックをハッシュ化したもの,トランザクションをまとめたmerkle treeのrootのhash,そのブロックを生成したtimeとなっている.\\previous block hashは,前のブロックのパラメータを選べてhash化したものである.それが連なっていることで図2.1のようなhash chainとして,ブロックがつながっている.
+BlockHeaderには,前のブロックをハッシュ化したもの,トランザクションをまとめたmerkle treeのrootのhash,そのブロックを生成したtimeとなっている.
+previous block hashは,前のブロックのパラメータを選べてhash化したものである.
+それが連なっていることで図2.1のようなhash chainとして,ブロックがつながっている. %図はrefで
 
 
 \begin{figure}[h]
@@ -138,17 +138,21 @@
 \end{center}
 \end{figure}
 
-そのため,一つのブロックが変更されれば,その後につながるブロック全てを更新しなければいけなくなる.\\
-ブロックが生成された場合,知っているノードにそのブロックをブロードキャストする.実際には通信量を抑えるためにブロック高を送った後、ブロックをシリアライズして送信する場合もある.\\
-ノードごとにブロックを検証し,誤りがあればそのブロックを破棄し,誤りがなければ更にそのノードがブロックをブロードキャストする.そして,Transaction PoolというTransactionを貯めておく場所から,そのブロックに含まれているTransactionを削除し,新しいブロックを生成する.
+そのため,一つのブロックが変更されれば,その後につながるブロック全てを更新しなければいけなくなる.
+ブロックが生成された場合,知っているノードにそのブロックをブロードキャストする.
+実際には通信量を抑えるためにブロック高を送った後、ブロックをシリアライズして送信する場合もある.% ブロック高はタイポ?
+
+ノードごとにブロックを検証し,誤りがあればそのブロックを破棄し,誤りがなければ更にそのノードがブロックをブロードキャストする.
+そして,Transaction PoolというTransactionを貯めておく場所から,そのブロックに含まれているTransactionを削除し,新しいブロックを生成する.
 
 %\begin{quote}
 %\small
 %\|http://www.ipsj.or.jp/journal/submit/style.html|
 %\end{quote}
 
-\subsection{トランザクションとその構造}
-トランザクションとはデータのやり取りを行った記録の最小単位である. トランザクションの構造は次のとおりである.
+%\subsection{トランザクションとその構造}
+トランザクションとはデータのやり取りを行った記録の最小単位である. 
+トランザクションの構造は次のとおりである.
 \begin{description}
 \item[TransactionHash] トランザクションをハッシュ化したもの.
 \item[data] データ.
@@ -157,22 +161,32 @@
 \item[signature] トランザクションの一部と秘密鍵をSHA256でハッシュ化したもの.  ECDSAで署名している.
 \end{description}
 
-トランザクションはノード間で伝搬され,ノードごとに検証される.そして検証を終え,不正なトランザクションであればそのトランザクションを破棄し,検証に通った場合はTransaction Poolに取り組まれ,また検証したノードからトランザクションがブロードキャストされる.
+トランザクションはノード間で伝搬され,ノードごとに検証される.
+そして検証を終え,不正なトランザクションであればそのトランザクションを破棄し,検証に通った場合はTransaction Poolに取り組まれ,また検証したノードからトランザクションがブロードキャストされる.
 
-\subsection{fork}
-ブロックの生成をした後にブロードキャストをすると,ブロック高の同じ,もしくは相手のブロック高の高いブロックチェーンにたどり着く場合がある.当然,相手のブロックチェーンはこれを破棄する.しかしこの場合,異なるブロックを持った2つのブロックチェーンをこの状態をforkと呼ぶ.fork状態になると,2つの異なるブロックチェーンができることになるため,一つにまとめなければならない.１つにまとめるためにコンセンサスアルゴリズムを用いるが,コンセンサスアルゴリズムについては次章で説明する.
+%\subsection{fork}
+ブロックの生成をした後にブロードキャストをすると,ブロック高の同じ,もしくは相手のブロック高の高いブロックチェーンにたどり着く場合がある.
+当然,相手のブロックチェーンはこれを破棄する.
+しかしこの場合,異なるブロックを持った2つのブロックチェーンをこの状態をforkと呼ぶ.
+fork状態になると,2つの異なるブロックチェーンができることになるため,一つにまとめなければならない.
+１つにまとめるためにコンセンサスアルゴリズムを用いるが,コンセンサスアルゴリズムについては次章で説明する.
 
-\section{Proof of Workを用いたコンセンサス}
-ブロックチェーンでは,パブリックブロックチェーンの場合とコンソーシアムブロックチェーンによってコンセンサスアルゴリズムが変わる.この章ではパブリックブロックチェーンのBitcoin,Ethereumに使われているProof of Workとコンソーシアムブロックチェーンに使えるPaxosを説明する。
+%\section{Proof of Workを用いたコンセンサス}
+ブロックチェーンでは,パブリックブロックチェーンの場合とコンソーシアムブロックチェーンによってコンセンサスアルゴリズムが変わる.
+この章ではパブリックブロックチェーンのBitcoin,Ethereumに使われているProof of Workとコンソーシアムブロックチェーンに使えるPaxosを説明する。
 
-\subsection{Proof of Workを用いたコンセンサス}
-パブリックブロックチェーンとは,不特定多数のノードが参加するブロックチェーンシステムのことをさす。よって,不特定多数のノード間,全体のノードの参加数が変わる状況でコンセンサスが取れるアルゴリズムを使用しなければならない.Proof of Workは不特定多数のノードを対象としてコンセンサスが取れる.ノードの計算量によってコンセンサスを取るからである.次のような問題が生じてもProof of Workはコンセンサスを取ることができる.
+%\subsection{Proof of Workを用いたコンセンサス}
+パブリックブロックチェーンとは,不特定多数のノードが参加するブロックチェーンシステムのことをさす。
+よって,不特定多数のノード間,全体のノードの参加数が変わる状況でコンセンサスが取れるアルゴリズムを使用しなければならない.
+Proof of Workは不特定多数のノードを対象としてコンセンサスが取れる.
+ノードの計算量によってコンセンサスを取るからである.
+次のような問題が生じてもProof of Workはコンセンサスを取ることができる.
 
 \begin{enumerate}
 \item プロセス毎に処理の速度が違う. つまり, メッセージの返信が遅い可能性がある
 \item 通信にどれだけの時間がかかるかわからず, その途中でメッセージが失われる可能性がある, 
 \item プロセスは停止する可能性がある. また, 復旧する可能性もある.
-\item 悪意ある情報を他のノードが送信する可能性がある.\\
+\item 悪意ある情報を他のノードが送信する可能性がある.
 \end{enumerate}
 Proof of Workに必要なパラメータは次のとおりである.
 
@@ -180,14 +194,15 @@
 \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からやり直す.
 \end{enumerate}
-difficulty = 2でProof of Workの手順を図にしたものを図３.1に示す.
+difficulty = 2でProof of Workの手順を図にしたものを図３.1に示す. %refで
 
 \begin{figure}[h]
 \begin{center}
@@ -205,7 +220,12 @@
 \end{center}
 \end{figure}
 
-計算量の差が51\%以上になると,forkしたブロック同士で差が生まれる.それによって,IPアドレスでのコンセンサではなく,CPUの性能によるコンセンサスを取ることができる.\\コンセンサスでは,ブロックとの差が大きければ大きいほど,コンセンサスが正確に取れる.しかし,正しいチェーンが決まるのに時間がかかる.そのため,コンセンサスに必要なブロックの差はコンセンサスの正確性と時間のトレードオフになっている.\\
+計算量の差が51\%以上になると,forkしたブロック同士で差が生まれる.
+それによって,IPアドレスでのコンセンサではなく,CPUの性能によるコンセンサスを取ることができる.
+
+コンセンサスでは,ブロックとの差が大きければ大きいほど,コンセンサスが正確に取れる.
+しかし,正しいチェーンが決まるのに時間がかかる.
+そのため,コンセンサスに必要なブロックの差はコンセンサスの正確性と時間のトレードオフになっている.
 
 この方法でコンセンサスを取る場合の欠点を挙げる.
 \begin{itemize}
@@ -213,8 +233,10 @@
 \item Transactionが確定するのに時間がかかる. 
 \end{itemize}
 
-\subsection{Paxos}
-コンソーシアムブロックチェーンは許可したのノードのみが参加できるブロックチェーンである.そのため,ノードの数も把握できるため,Paxosを使うことができる.Paxosはノードの多数決によってコンセンサスを取るアルゴリズムである.ただし,Paxosは次のような問題があっても値を一意に決めることができる.
+%\subsection{Paxos}
+コンソーシアムブロックチェーンは許可したのノードのみが参加できるブロックチェーンである.
+そのため,ノードの数も把握できるため,Paxosを使うことができる.
+Paxosはノードの多数決によってコンセンサスを取るアルゴリズムである.ただし,Paxosは次のような問題があっても値を一意に決めることができる.
 \begin{enumerate}
 \item プロセス毎に処理の速度が違う. つまり, メッセージの返信が遅い可能性がある
 \item 通信にどれだけの時間がかかるかわからず, その途中でメッセージが失われる可能性がある, 
@@ -234,7 +256,7 @@
 \item[値(提案)がacceptされる] acceptorによって値(提案)が決まること. 
 \item[値(提案)が選択(chosen)される] 過半数以上のacceptorによって, 値(提案)がacceptされた場合, それを値(提案)が選択されたと言う.
 
-paxosのアルゴリズムは2フェーズある.\\
+paxosのアルゴリズムは2フェーズある.
 1つ目のフェーズ,prepare-promiseは次のような手順で動作する.
 
 1フェーズ目を図にしたものを図3.3に示す.
@@ -281,19 +303,35 @@
 \item Transactionの確定に時間がかからない.
 \end{itemize}
 
-\subsection{Paxosによるブロックチェーン}
-PaxosはProof of Workと比べ,CPUのリソースを消費せず,Transactionの確定に時間がかからない.そのため,Paxosでブロックのコンセンサスを取るブロックチェーンを実装することにはメリットがある.また,Paxos自体がリーダー選出に向いているアルゴリズムである.そのため,リーダーを決め,そのノードのブロックチェーンの一貫性のみを考えることもできる.
+%\subsection{Paxosによるブロックチェーン}
+PaxosはProof of Workと比べ,CPUのリソースを消費せず,Transactionの確定に時間がかからない.
+そのため,Paxosでブロックのコンセンサスを取るブロックチェーンを実装することにはメリットがある.
+また,Paxos自体がリーダー選出に向いているアルゴリズムである.
+そのため,リーダーを決め,そのノードのブロックチェーンの一貫性のみを考えることもできる.
 
 \section{Chrsitie}
-\subsection{Christieとは}
-Christieは当研究室で開発している分散フレームワークである.Christieは当研究室で開発しているGearsOSに組み込まれる予定がある.そのためGearsOSを構成する言語Continuation based Cと似た概念がある.Christieに存在する概念として次のようなものがある.
+%\subsection{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が複数ある場合, この動作を用いる.
@@ -302,8 +340,12 @@
 \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に示す.
+
+%\subsection{プログラミングの例}
+ここでは,Christieで実際にプログラムを記述する例を述べる.
+CGMを作り,setup(new CodeGear)を動かすことにより,DGを持ち合わせ,DGが揃った場合にCodeGearが実装される.
+CGMを作る方法はStartCodeGear(以下SCG)を継承したものからcreate-CGM(port)methodを実行することによりCGMが作られる.
+SCGのコードの例をソースコード4.1に示す. %refを使う
 
 \begin{flushleft}
 \lstinputlisting[label=code:StartHelloWorld, caption=StartHelloWorld]{./src/HelloWorld/StartHelloWorld.java}
@@ -311,9 +353,18 @@
 
 \end{description}
 
-\subsection{TopologyManager}
-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が実行される.
+%\subsection{TopologyManager}
+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が実行される.
  
  \lstinputlisting[caption=ring.dot, label=code:dot-example]{./src/ring.dot}
  
@@ -327,11 +378,11 @@
 \end{figure}
  動的Topologyは参加を表明したノードに対し,動的にノード同士の関係を作る.例えばTreeを構成する場合,参加したノードから順に,rootに近い位置の役割を与える.また,CodeGearはノードが参加しmparentに接続された後に実行される.
  
-\subsection{Chrisiteにおけるブロックチェーンの実装の利点と欠点}
+%\subsection{Chrisiteにおけるブロックチェーンの実装の利点と欠点}
 
 
 Christieにおいてブロック, トランザクション, Paxos, Proof of Workを実装した. 
-その際, Christieで実装した場合の便利な点を述べる.
+その際, Christieで実装した場合の便利な点を述べる. %こういうの書かない
 
 \begin{itemize}
 \item データの取り出しが簡単. ChristieはDataGearという単位でデータを保持する. そのため, ブロックやトランザクションはDataGearに包めばいいため, どう送るかという問題を考えなくてすむ. 
@@ -339,7 +390,7 @@
 \item 機能ごとにファイルが実装できるため, 見通しが良い. ChristieはCbCのgotoと同じように関数が終わるとsetupによって別の関数に移動する. そのため自然に機能ごとにファイルを作るため, 見通しが良くなる.
 \end{itemize}
 
-不便な点を以下に述べる.
+不便な点を以下に述べる. %こういうの書かない
 
 \begin{itemize}
 \item デバッグが難しい. cgm.setupでCodeGearが実行されるが, keyの待ち合わせで止まり, どこのCGで止まっているかわからないことが多かった. 例えば, putするkeyのスペルミスでコードの待ち合わせが起こり, CGが実行されず, エラーなども表示されずにwaitすることがある. その時に, どこで止まっているか特定するのが難しい.
@@ -348,11 +399,17 @@
 \end{itemize}
 
 \section{評価}
-本研究室では,実際にコンセンサスアルゴリズムPaxosを分散環境場で実行した,分散環境場で動かすため,JobSchedulerの一種であるTorque Resource Manager(Torque)を使用した.ここではTorqueとは何か,どのような評価をしたかを述べる.
+% 評価と利点と欠点は別物なの?
+本研究室では,実際にコンセンサスアルゴリズムPaxosを分散環境場で実行した,分散環境場で動かすため,JobSchedulerの一種であるTorque Resource Manager(Torque)を使用した.
 
-\subsection{Torqueとは}
-PCクラスタ上でプログラムの実験を行う際には,他のプログラムとリソースを取り合う懸念がある.それを防ぐためにTorqueを使用する.Torqueはjobという単位でプログラムを管理し,リソースを確保できたら実行する.jobはqsubというコマンドを使って,複数登録することができる.また,実行中の様子もqstatというコマンドを使うことで監視ができる.\\
-Torqueには主に3つのNodeの種類がある.\\
+%\subsection{Torqueとは}
+PCクラスタ上でプログラムの実験を行う際には,他のプログラムとリソースを取り合う懸念がある.
+それを防ぐためにTorqueを使用する.
+Torqueはjobという単位でプログラムを管理し,リソースを確保できたら実行する.
+jobはqsubというコマンドを使って,複数登録することができる.
+
+また,実行中の様子もqstatというコマンドを使うことで監視ができる.
+Torqueには主に3つのNodeの種類がある.
 
 \begin{description}
 \item[Master Node] pbs\_serverを実行しているノード. 他のノードの役割とも併用できる.
@@ -360,7 +417,8 @@
 \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うぶbを用意し,jobの投入を行なった.
+% タイポ
 
 \begin{figure}[h]
 \begin{center}
@@ -374,11 +432,15 @@
 
 \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コマンドを実行する. 
+「\#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}である.
+%\subsection{PCクラスタ上でのPaxosの実際の動作}
+PCクラスタ上で実際にPaxosを動かした際の解説をする.
+今回は単純化し,proposerの数を2,accepterの数を3,learnerの数を1としてPaxosを動かし,値が一意に決まる過程を見る.
+実験の単純化の為に,提案の数値を整数とし,各processerごとに異なった値とした.
+正確には,「proposer + 数字」の部分を値とし,コンセンサスを取るようにした.実際にPaxosを動かし,シーケンス図で結果を示したものが図\ref{fig:paxos}である. 
 
 \begin{figure}[h]
 \begin{center}
@@ -389,7 +451,7 @@
 \end{figure}
 
 一意の値を決めることができており,また,Learnerが値を選択した後でも,Paxosは常に決めた値を持ち続けるアルゴリズムである.ログの出力では提案番号がより大きいものの提案まで続いていたが,値がこれ以上覆らなかった。
-今回はわかりやすいよう値を数字で行なった実験であるが,これをタランザクション,ブロックに応用することで,ブロックチェーンにおけるコンセンサス部分を完成させることができる.
+今回はわかりやすいよう値を数字で行なった実験であるが,これをタランザクション,ブロックに応用することで,ブロックチェーンにおけるコンセンサス部分を完成させることができる. %わかりやすいようとか書かない
 
 \section{計測実験}