Binary file midterm/midterm.pdf has changed

--- a/midterm/midterm.tex	Thu Nov 15 17:40:39 2018 +0900
+++ b/midterm/midterm.tex	Thu Nov 15 23:41:39 2018 +0900
@@ -35,8 +35,6 @@
 }
 
 
-
-
 \begin{document}
 \title{Christieによるブロックチェーンの実装}
 \author{155753A 氏名: 赤堀 貴一 指導教員: 河野 真治}
@@ -52,7 +50,7 @@
 
 当研究室では分散フレームワークとしてChristieを開発しており, これはGearsOSにファイルシステムとして組み込む予定がある. そのため, Christieにブロックチェーンを実装し, GearsOSに組み込むことにより, GearsOSのファイルシステムにおいてデータの破損, 不整合を検知できる. また, GearsOS同士による分散ファイルシステムを構成することができ, 非中央的にデータの検証ができるようになる. もし分散システムを構成しない場合でもデータの整合性保持は行え, 上記の目的は達成できる.
 
-よって, 本研究では, Christieにブロックチェーンを実装し, 分散環境でのデータの整合性保持, 追跡を行う.
+本研究では, Christieにブロックチェーンを実装し, 分散環境でのデータの整合性保持, 追跡を行う.
 
 
 
@@ -79,7 +77,7 @@
 \item トランザクションリスト.
 \end{itemize}
 
-ブロックは前のブロックと暗号化ハッシュでつながっている. 前のブロックのハッシュは, これらのパラメータをつなげてハッシュ化している. また, 現在のブロックのハッシュが作られる際も同様に, 直前のブロックのハッシュに依存して作られる. そのため, もしブロックを改ざんするなら, その先につながるすべてのブロックを改ざんしなければならない. 
+ブロックは前のブロックと暗号化ハッシュでつながっている. 前のブロックのハッシュは, これらのパラメータがつなげられてハッシュ化されている. また, 現在のブロックのハッシュが作られる際も同様に, 直前のブロックのハッシュに依存して作られる. そのため, もしブロックを改ざんするならば, その先につながるすべてのブロックを改ざんしなければならない. 
 
 しかし, その仕組みだけならば複数のブロックのハッシュを同時に改ざんすることで, データが改ざんされてしまう可能性がある. そのため, ブロックに付け加える際に計算作業を行わせ, それによってある条件に収まるHashを作らせることで, 改ざんの可能性が抑えられている. 例えば, ビットコインだとProof of Workという計算問題を解かせ, Hashを生成する. これは単純にはソースコード\ref{code:proof of work}のような問題を解くのと同義である. 
 
@@ -100,9 +98,9 @@
 
 トランザクションの中身はデータ, 前のトランザクションと後ろのトランザクションのハッシュ, 暗号鍵でのトランザクションの署名となっている. 署名により, 誰のトランザクションかが簡単にわかる.
 
-もし至るところでブロックが作られた場合, ブロックに分岐が発生する場合がある. これをフォークという. これは一種の競合状態である. 分岐したブロック同士にある一定の差がついた場合, 長い方を正しいものとし, 競合を解決する. 
+もし条件に当てはまるブロックが同時に複数作られた場合, ブロックに分岐が発生する場合がある. これをフォークという. これは一種の競合状態である. 分岐したブロック同士にある一定の差がついた場合, 長い方を正しいものとし, 競合を解決する. 
 
-通信はp2pで行われ, トランザクションやブロックが来た場合, ノードはそれらが正当なものかをルールに従って検証する. そしてトランザクション, ブロックが承認された場合, 他のノードにそのトランザクション, もしくはブロックを送り, 承認されなかった場合は破棄する. これによって, 承認されたものだけがネットワーク上に伝搬されていく.
+ノード同士の通信は, すべてのノードが対等に通信を行うPeer to Peer方式で行われる. トランザクションやブロックが来た場合, ノードはそれらが正当なものかをルールに従って検証する. そしてトランザクション, ブロックが承認された場合, 他のノードにそのトランザクション, もしくはブロックを送り, 承認されなかった場合は破棄する. これによって, 承認されたものだけがネットワーク上に伝搬されていく.
 
  このような複数の仕組みによって, 中央管理者を必要とせずにデータの整合性保持が行われる..
 
@@ -124,19 +122,17 @@
 CGはCGMによって実行されるが, 実行するにはCGに必要なDGが全て揃う必要がある. もしDGが全て揃わない場合, CGMはずっとlistenし, データが揃うまで実行を待つ.
 
 
-\section{やったこと}
-中間予稿までにやったこととして, コンセンサスアルゴリズムPaxosの論文を読み, ChristieにTopologyManagerという機能を実装した. 
+\section{まとめ}
+中間予稿までにやったこととして, Paxosの論文を読み, ChristieにTopologyManagerという機能を実装した. 
 
 Paxosを読んだ理由は, コンセンサスアルゴリズムの調査である. 実際, Paxosもビットコインで使用される候補に上がったコンセンサスアルゴリズムである. 分散システムはどのようなコンセンサスアルゴリズムを用いているかで性能が変わる. 例えばビットコインのコンセンサスアルゴリズムProof of Workは, 計算量を多くして改ざんを起こりにくくしているが無駄が多く, 10分以内で解かれないように動的に条件を変更している. これは先ほどの, 同時にブロックを変更するのを防ぐため, つまり信頼性を上げるためであるが, 速度面で大きな課題となる. 分散ファイルシステムを構成するにはスケーラビリティが課題であり, ノードの数が多くなればなるほど通信時間がかかる. そのため, コンセンサスリズムとして有名なPaxosの論文を読んだ.
 
 ChristieにTopologyManagerを実装した理由は, Christieのコードに慣れるため, そしてTopologyManager上に分散システムを実装するのが容易になるからである. TopologyManagerとは, ノードにTopologyを構成させ, ノードごとにどこのノードにつながればいいかを指定する機能である. Christieでは静的, 動的なトポロジー管理ができる. 静的ではdotファイルというものにノードごとの関係を記述する. 動的ではノードの木構造を作る. 
 
 
-また, ブロックチェーンについては実際にブロックを実装し, 簡易的ではあるがProof of Workを動かして理解を深めた. 分散環境の実装はこれから行う.
-
+また, ブロックチェーンについては実際にブロックを実装し, 簡易的ではあるがProof of Workを動かして理解を深めた. 
 
-\section{これからやること}
-ブロックチェーンのトランザクション部分と分散環境を実装する. そして, 実際に分散環境下においてブロックチェーンを動かし, データの整合性保持, 追跡が行えるかを確認していく. コンセンサスアルゴリズムも調査していき, ファイルシステムに組み込めるコンセンサスアルゴリズムを探していきたい. 
+今後の課題として, ブロックチェーンのトランザクション部分と分散環境を実装する. そして, 実際に分散環境下においてブロックチェーンを動かし, データの整合性保持, 追跡が行えるかを確認していく. コンセンサスアルゴリズムも調査していき, ファイルシステムに組み込めるコンセンサスアルゴリズムを探していきたい. 
 
 \nocite{*}
 \bibliographystyle{junsrt}