--- a/final_main/Makefile	Thu Feb 14 17:07:56 2019 +0900
+++ b/final_main/Makefile	Fri Feb 15 18:20:41 2019 +0900
@@ -13,7 +13,7 @@
 # dependent document files
 TEX_FILES = \
     bibliography.tex \
-    chapter*.tex \
+    chapter*/chapter*.tex \
     thanks.tex \
 
 # dependent image files

--- a/final_main/bibliography.tex	Thu Feb 14 17:07:56 2019 +0900
+++ b/final_main/bibliography.tex	Fri Feb 15 18:20:41 2019 +0900
@@ -15,9 +15,13 @@
 % , 情報処理学会システムソフトウェアとオペレーティング・システム研究会(OS) (2016).
 
 \bibitem{torque}
-TORQUE Introduction. \\\verb|http://docs.adaptivecomputing.com/torque/4-2-8/help.htm#topics/0-intro/introduction.htm%3FTocPath%3DWelcome%7C_____1|
+TORQUE Introduction. \\
+\url{http://docs.adaptivecomputing.com/torque/4-2-8/help.htm#topics/0-intro/introduction.htm\%3FTocPath\%3DWelcome\%7C_____1}\\
+(2018年2月15日 アクセス)
 
-% \bibitem{llvm_ir}
-% LLVM Language Reference Manual. \\\verb|http://llvm.org/docs/LangRef.html|
+\bibitem{qsub-doc}
+qsub document. \\
+\url{http://docs.adaptivecomputing.com/torque/4-0-2/Content/topics/commands/qsub.htm}\\
+(2018年2月15日 アクセス)
 
 \end{thebibliography}

--- a/final_main/chapter1/chapter1.tex	Thu Feb 14 17:07:56 2019 +0900
+++ b/final_main/chapter1/chapter1.tex	Fri Feb 15 18:20:41 2019 +0900
@@ -1,4 +1,4 @@
-\input{/Users/e155753/.tex/setup}
+%\input{/Users/e155753/.tex/setup}
 
 %%文書開始****************************
 \begin{document} 

--- a/final_main/chapter2/chapter2.tex	Thu Feb 14 17:07:56 2019 +0900
+++ b/final_main/chapter2/chapter2.tex	Fri Feb 15 18:20:41 2019 +0900
@@ -1,4 +1,4 @@
-\input{/Users/e155753/.tex/setup}
+%\input{/Users/e155753/.tex/setup}
 
 %%文書開始****************************
 \begin{document} 
@@ -6,7 +6,7 @@
 \chapter{ブロックチェーンについて}
 
 ブロックチェーンとは分散型台帳技術とも呼ばれ, 複数のトランザクションをまとめたブロック, そのブロックをハッシュによって繋げ, 前後関係を表した台帳というものを, システムに参加しているすべてのノードが保持する技術である. ブロックチェーンにはパブリック型とコンソーシアム型の2種類がある. パブリック型は不特定多数のノードを対象にしており, コンソーシアム型は管理者が許可したノードが参加している.
-
+\
 \section{ブロックとその構造}
 ブロックチェーンにおけるブロックは, 複数のトランザクションをまとめたものである. ブロックの構造は使用するコンセンサスアルゴリズムによって変わるが, 基本的な構造としては次のとおりである.
 
@@ -22,18 +22,23 @@
 
 BlockHeaderには, 前のブロックをハッシュ化したもの, トランザクションをまとめたmerkle treeのrootのhash, このブロックを生成したtimeとなっている.
 
+previous block hashは, 前のブロックのパラメータを並べて, hash貸したものである. それが連なっていることで, 図のようなhash chainとして, ブロックがつながっている.
+
+
+
 
 \section{トランザクションとその構造}
 トランザクションとはデータのやり取りを行った記録の最小単位である. トランザクションの構造は次のとおりである.
-\begin{itemize}
-\item data
-\item input transactions
-\item output transactions
-\item signature
-\end{itemize}
+\begin{description}
+\item[TransactionHash] トランザクションをハッシュ化したもの.
+\item[data] データ.
+\item[sendAddress] 送り元のアドレスを指す.
+\item[recieveAddress] 送り先のアドレスを指す.
+\item[signature] 署名.
+\end{description}
 
-input transactionsはdataの
-output transaction
+
+\section{}
 
 
 

--- a/final_main/chapter3/chapter3.tex	Thu Feb 14 17:07:56 2019 +0900
+++ b/final_main/chapter3/chapter3.tex	Fri Feb 15 18:20:41 2019 +0900
@@ -1,3 +1,91 @@
-\chapter{コンセンサスアルゴリズムについて}
+%\input{/Users/e155753/.tex/setup}
+
+%%文書開始****************************
+\begin{document} 
+%%**************************************
+\chapter{コンセンサスアルゴリズム}
+
+ブロックチェーンでは, パブリックブロックチェーンの場合とコンソーシアムブロックチェーンによってコンセンサスアルゴリズムが変わる. この章ではパブリックブロックチェーンのBitcoin, Ethereumに使われているProof of Workについて説明し, コンソーシアムブロックチェーンに使えるPaxosを説明する.
+
+\section{Proof of Workを用いたコンセンサス}
+パブリックブロックチェーンとは, 不特定多数のノードが参加するブロックチェーンシステムのことを指す. よって, 不特定多数のノード間, 全体のノードの参加数が変わる状況でコンセンサスが取れるアルゴリズムを使用しなければならない. 
+Proof of Workは不特定多数のノードを対象としてコンセンサスが取れる. ノードの計算量によってコンセンサスを取るからである. 次のような問題があっても, Proof of Workはコンセンサスを取ることができる.
+
+\begin{enumerate}
+\item プロセス毎に処理の速度が違う. つまり, メッセージの返信が遅い可能性がある
+\item 通信にどれだけの時間がかかるかわからず, その途中でメッセージが失われる可能性がある, 
+\item プロセスは停止する可能性がある. また, 復旧する可能性もある.
+\item 悪意ある情報を他のノードが送信する可能性がある.
+\end{enumerate}
 
 
+Proof of Workに必要なパラメータは次のとおりである.
+
+\begin{itemize}
+\item nonce
+\item difficulty
+\end{itemize}
+
+nonceはブロックのパラメータに含まれる. difficultyはProof of Workの難しさ, 正確に言えば1つのブロックを生成する時間を調整している.
+Proof of Workはこれらのパラメータを使って次のようにブロックを作る.
+
+\begin{enumerate}
+\item ブロックとnonceを加えたものをハッシュ化する. この際, nonceによって, ブロックのハッシュは全く違うものになる.
+\item ハッシュ化したブロックの先頭から数えた0ビットの数がdifficultyより多ければ, そのブロックにnonceを埋め込み, ブロックを作る. 
+\item 2の条件に当てはまらなかった場合はnonceに1を足して, 1からやり直す.
+\end{enumerate}
+difficulty = 2でProof of Workの手順を図にしたものを図\ref{fig:proof-of-work}に示す. 
+
+\begin{figure}[H]
+\centering
+  \fbox{
+   \includegraphics[scale=0.5]{./images/proof-of-work.pdf}
+  }
+\caption{proof-of-workの例}
+\label{fig:proof-of-work}
+\end{figure}
+
+
+2の条件については, 単純に$(桁数 - difficulty + 1) \times 10 > hash$とも置き換えることができる. 
+
+nonceを変えていくことで, hashはほぼ乱数のような状態になる. つまり, difficultyを増やすほど, 条件に当てはまるhashが少なくなっていくことがわかり, そのhashを探すための計算量も増えることがわかる. 
+
+これらがProof of Workでブロックを生成する手順である. これを用いることによって, ブロックが長くなればなるほど, すでに作られたブロックを変更することは計算量が膨大になるため, 不可能になっていく. 
+
+Proof of Workでノード間のコンセンサスを取る方法は単純で, ブロックの長さの差が一定以上になった場合, 最も長かったブロックを正しいものとする. これを図で表すと, 図\ref{fig:proof-of-work-fork}のようになる. 
+
+\begin{figure}[H]
+\centering
+  \fbox{
+   \includegraphics[scale=0.5]{./images/proof-of-work-fork}
+  }
+\caption{Proof of Workでのコンセンサス}
+\label{fig:proof-of-work-fork}
+\end{figure}
+
+計算量の差が51\%以上になると, forkしたブロック同士で差が生まれる. それによって, IPアドレスでのコンセンサスではなく, CPUの性能によるコンセンサスを取ることができる.
+
+コンセンサスでは, ブロックの差が大きければ大きいほど, コンセンサスが正確に取れる. しかし, 正しいチェーンが決まるのに時間がかかる. そのため, コンセンサスに必要なブロックの差はコンセンサスの正確性と時間のトレードオフになっている. 
+
+この方法でコンセンサスを取る場合の欠点を挙げる.
+\begin{itemize}
+\item この計算をするためだけにCPUを消費する. 単純計算であるため, とても重要な計算をしているわけではなく, CPUの資源が無駄に使われる.
+\item Transactionが確定するのに時間がかかる. 
+\end{itemize}
+
+
+\section{Paxos}
+
+コンソーシアムブロックチェーンは許可したノードのみが参加できるブロックチェーンである. そのため, ノードの数も把握できるため, Paxosを使うことができる. Paxosはノードの多数決によってコンセンサスを取るアルゴリズムである. ただし, Paxosは次のような問題があっても値を一意に決めることができる.
+
+\begin{enumerate}
+\item プロセス毎に処理の速度が違う. つまり, メッセージの返信が遅い可能性がある
+\item 通信にどれだけの時間がかかるかわからず, その途中でメッセージが失われる可能性がある, 
+\item プロセスは停止する可能性がある. また, 復旧する可能性もある.
+\end{enumerate}
+
+Proof of Workにある特性の4がないが, これは許可したノードのみが参加可能だからである. つまり, 悪意あるノードが参加する可能性が少ないためである.
+
+
+%%文書終了****************************
+\end{document} 

--- a/final_main/chapter4/chapter4.tex	Thu Feb 14 17:07:56 2019 +0900
+++ b/final_main/chapter4/chapter4.tex	Fri Feb 15 18:20:41 2019 +0900
@@ -1,4 +1,4 @@
-\input{/Users/e155753/.tex/setup}
+%\input{/Users/e155753/.tex/setup}
 
 %%文書開始****************************
 \begin{document} 
@@ -33,7 +33,7 @@
 ここでは, Christieで実際にプログラムを記述する例を述べる.
 CGMを作り, setup(new CodeGear)を動かすことにより, DGを待ち合わせ, DGが揃った場合にCodeGearが実行される. CGMを作る方法はStartCodeGear(以下SCG)を継承したものからcreateCGM(port) methodを実行することにより, CGMが作られる. SCGのコードの例をソースコード\ref{code:StartHelloWorld}に示す.
 
-\lstinputlisting[caption=StartHelloWorld,label=code:StartHelloWorld]{../src/HelloWorld/StartHelloWorld.java}
+\lstinputlisting[caption=StartHelloWorld,label=code:StartHelloWorld]{./src/HelloWorld/StartHelloWorld.java}
 
 
 \section{TopologyManagerの実装}
@@ -43,12 +43,12 @@
 
 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}
+\lstinputlisting[caption=ring.dot,label=code:dot-example]{./src/ring.dot}
 
 \begin{figure}[H]
 \centering
   \fbox{
-   \includegraphics[scale=1]{../images/ring.pdf}
+   \includegraphics[scale=1]{./images/ring.pdf}
   }
 \caption{ソースコード\ref{code:dot-example}, ring.dotを図にしたもの}
 \label{fig:dot-example}

--- a/final_main/chapter5/chapter5.tex	Thu Feb 14 17:07:56 2019 +0900
+++ b/final_main/chapter5/chapter5.tex	Fri Feb 15 18:20:41 2019 +0900
@@ -1,5 +1,5 @@
 % 今後の課題
-\input{/Users/e155753/.tex/setup}
+%\input{/Users/e155753/.tex/setup}
 
 %%文書開始****************************
 \begin{document} 
@@ -10,29 +10,39 @@
 
 \section{Torqueとは}
 
-PCクラスタ上でプログラムの実験を行う際には, 他のプログラムとリソースを取り合う懸念がある. それを防ぐためにTorqueを使用する. Torqueはジョブという単位でプログラムを管理し, リソースを確保できたら実行する. ジョブはqsubというコマンドを使って複数登録することができ, queueのように投入した順番に実行される. また, 実行中の様子もqstatというコマンドを打つことで監視ができる.
+PCクラスタ上でプログラムの実験を行う際には, 他のプログラムとリソースを取り合う懸念がある. それを防ぐためにTorqueを使用する. Torqueはjobという単位でプログラムを管理し, リソースを確保できたら実行する. jobはqsubというコマンドを使って複数登録することができる. また, 実行中の様子もqstatというコマンドを打つことで監視ができる.
 
 
-Torqueには主に3つのNodeの種類がある.
+Torqueには主に3つのNodeの種類がある. 
 
 \begin{description}
 \item[Master Node] pbs\_serverを実行しているノード. 他のノードの役割とも併用できる.
-\item[Submit/Interactive Nodes] クライアントがジョブを投入したり監視したりするノード. qsubやqstatのようなクライアントコマンドが実行できる.
-\item[Computer Nodes] 投入されたジョブを実際に実行するノード.
+\item[Submit/Interactive Nodes] クライアントがjobを投入したり監視したりするノード. qsubやqstatのようなクライアントコマンドが実行できる.
+\item[Computer Nodes] 投入されたjobを実際に実行するノード. pbs\_momが実行されており, それによってjobをstart, kill, 管理する.
 \end{description}
 
-今回は学科のKVM上にMaster Node, Submit/Interactive Nodeの役割を持つVM1台と, Computer Nodesとして15台のVMを用意した. 
+今回は図\ref{fig:kvm}のように, 学科のKVM上にMaster Node, Submit/Interactive Nodeの役割を持つVM1台と, Computer Nodesとして15台のVMを用意し, jobの投入を行った.
+
+\begin{figure}[H]
+\centering
+  \fbox{
+   \includegraphics[scale=0.5]{./images/kvm.pdf}
+  }
+\caption{実験環境}
+\label{fig:kvm}
+\end{figure}
+
+jobはシェルスクリプトの形で与えることができる. ソースコード\ref{code:torque-example}を例としてあげる. 
+
+\lstinputlisting[caption=torque-example.sh,label=code:torque-example]{./src/torque-example.sh}
+
+
+「\#PBS オプション」とすることにより実行環境を設定できる. 使用できるオプションは参考文献\cite{qsub-doc}に書かれてある. 例として, ノード数10(vm0からvm9まで), jobの名前を「ExmpleJob」という形で実行した. その結果を
 
 
 
 
 
 
-ジョブはシェルスクリプトの形で与えることができる. ソースコード\ref{code:torque-example}を例としてあげる. 
-
-\lstinputlisting[caption=,label=]{../src/torque-example.sh}
-
-
-
 %%文書終了****************************
 \end{document} 
\ No newline at end of file

Binary file final_main/images/kvm.graffle has changed

Binary file final_main/images/kvm.pdf has changed

Binary file final_main/images/proof-of-work-fork.graffle has changed

Binary file final_main/images/proof-of-work-fork.pdf has changed

Binary file final_main/images/proof-of-work.graffle has changed

Binary file final_main/images/proof-of-work.pdf has changed

Binary file final_main/main.pdf has changed

--- a/final_main/thanks.tex	Thu Feb 14 17:07:56 2019 +0900
+++ b/final_main/thanks.tex	Fri Feb 15 18:20:41 2019 +0900
@@ -1,4 +1,4 @@
-\input{/Users/e155753/.tex/setup}
+%\input{/Users/e155753/.tex/setup}
 
 %%文書開始****************************
 \begin{document}