\documentclass[submit]{ipsj}
%\documentclass{ipsj}

\usepackage[dvipdfmx]{graphicx}
\usepackage{ascmac}
\usepackage{graphicx}
\usepackage{latexsym}
\usepackage{url}
\usepackage{listings,jlisting}
\usepackage{enumitem}


  \lstset{
    language=C, 
    tabsize=2, 
    frame=single, 
    basicstyle={\ttfamily\footnotesize},% 
    identifierstyle={\footnotesize},% 
    commentstyle={\footnotesize\itshape},% 
    keywordstyle={\footnotesize\bfseries},% 
    ndkeywordstyle={\footnotesize},% 
    stringstyle={\footnotesize\ttfamily}, 
    breaklines=true, 
    captionpos=b, %キャプションの位置 
    columns=[l]{fullflexible},% 
    xrightmargin=0zw,% 
    xleftmargin=1zw,% 
    aboveskip=1zw, 
    numberstyle={\scriptsize},% 
    stepnumber=1, 
    numbersep=0.5zw,% 
    lineskip=-0.5ex, 
}
\renewcommand{\lstlistingname}{Code}


\def\Underline{\setbox0\hbox\bgroup\let\\\endUnderline}
\def\endUnderline{\vphantom{y}\egroup\smash{\underline{\box0}}\\}
\def\|{\verb|}

\setcounter{巻数}{59}
\setcounter{号数}{1}
\setcounter{page}{1}


\受付{2016}{3}{4}
\再受付{2015}{7}{16}   %省略可能
\再再受付{2015}{7}{20} %省略可能
\再再受付{2015}{11}{20} %省略可能
\採録{2016}{8}{1}




\begin{document}


\title{情報処理学会論文誌ジャーナル論文の準備方法\\
（ipsj.cls version 2.01）}

\etitle{How to Prepare Your Paper for IPSJ Journal \\
(ipsj.cls version 2.01)}

\affiliate{IPSJ}{情報処理学会\\
IPSJ, Chiyoda, Tokyo 101--0062, Japan}


\paffiliate{JU}{情報処理大学\\
Johoshori University}

\author{情報 太郎}{Taro Joho}{IPSJ}[joho.taro@ipsj.or.jp]
\author{処理 花子}{Hanako Shori}{IPSJ}
\author{学会 次郎}{Jiro Gakkai}{IPSJ,JU}[gakkai.jiro@ipsj.or.jp]

\begin{abstract}
本稿は，情報処理学会論文誌ジャーナルに投稿する原稿を執筆する際，
および論文採択後に最終原稿を準備する際の注意点等をまとめたものである．
大きく分けると，
論文投稿の流れと，\LaTeX と専用のスタイルファイルを用いた場合の論文フォーマットに関する指針，
および論文の内容に関してするべきこと，
するべきでないことをまとめたべからずチェックリストからなる．
本稿自体も \LaTeX と専用のスタイルファイルを用いて執筆されているため，
論文執筆の際に参考になれば幸いである．
\end{abstract}


\begin{jkeyword}
情報処理学会論文誌ジャーナル，\LaTeX，スタイルファイル，べからず集
\end{jkeyword}

\begin{eabstract}
This document is a guide to prepare a draft for submitting to IPSJ
Journal, and the final camera-ready manuscript of a paper to appear in
IPSJ Journal, using {\LaTeX} and special style files.  Since this
document itself is produced with the style files, it will help you to
refer its source file which is distributed with the style files.
\end{eabstract}

\begin{ekeyword}
IPSJ Journal, \LaTeX, style files, ``Dos and Don'ts'' list
\end{ekeyword}

\maketitle

%1
\section{はじめに}

コンピュータにおいてデータの破損や不整合は深刻な異常を引き起こす原因となる.そのため,破損、不整合を検知するためのブロックチェーン技術の実装を試みたい.ブロックチェーンは分散ネットワーク技術であり,データの破損や不整合をハッシュ値によって比較できる.そして,誤操作や改ざんが発生した場合でも,ブロックチェーンを用いてデータの追跡が行える.\\
当研究室では独自の分散フレームワークとしてChristieを開発しており,これはGearsOSにファイルシステムとして組み込む予定がある。そのため,Christieにブロックチェーンを実装し,GearsOSに組み込むことにより,GearsOSのファイルシステムにおいてデータの破損,不整合を検知することができる.また,GearsOS同士による分散ファイルシステムを構成することができ,非中央的なデータの分散ができるようになる.もし分散システムを構成しない場合においてもデータの整合性保持は行え,上記の目的は達成することができる.\\
本研究では,Christieにブロックチェーンを実装し,実際に学科のPC上の分散環境にて動かす.



%\footnotetext{本文は実際には論文誌ジャーナル編集委員会で作成したものである．}

%2
\section{ブロックチェーンについて}
%2.1
\subsection{P2P (Peer-to-Peer)}			
ブロックチェーンはP2Pにてネットワーク間が動作している,つまり.ブロックチェーンネットワークにはサーバー,クライアントの区別がなく,全てのノードが平等である.そのため,非中央時にデータの管理をおこなう.

\subsection{ブロックとその構造}
ブロックチェーンにおけるブロックは,複数のトランザクションをまとめたものである.ブロックの構造はしようするコンセンサスアルゴリズムによって変わるが,基本的な構造としては次のとおりである.
\begin{itemize}
\item BlockHeader
\begin{itemize}
\item previous block hash
\item merkle root hash
\item time
\end{itemize}
\item TransactionList
\end{itemize}

BlockHeaderには,前のブロックをハッシュ化したもの,トランザクションをまとめたmerkle treeのrootのhash,そのブロックを生成したtimeとなっている.\\previous block hashは,前のブロックのパラメータを選べてhash化したものである.それが連なっていることで図2.1のようなhash chainとして,ブロックがつながっている.


\begin{figure}[h]
\begin{center}
\includegraphics[width=240pt]{./images/chain.pdf}
\caption{hash chain}
\end{center}
\end{figure}

そのため,一つのブロックが変更されれば,その後につながるブロック全てを更新しなければいけなくなる.\\
ブロックが生成された場合,知っているノードにそのブロックをブロードキャストする.実際には通信量を抑えるためにブロック高を送った後、ブロックをシリアライズして送信する場合もある.\\
ノードごとにブロックを検証し,誤りがあればそのブロックを破棄し,誤りがなければ更にそのノードがブロックをブロードキャストする.そして,Transaction PoolというTransactionを貯めておく場所から,そのブロックに含まれているTransactionを削除し,新しいブロックを生成する.

%\begin{quote}
%\small
%\|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で署名している.
\end{description}

トランザクションはノード間で伝搬され,ノードごとに検証される.そして検証を終え,不正なトランザクションであればそのトランザクションを破棄し,検証に通った場合はTransaction Poolに取り組まれ,また検証したノードからトランザクションがブロードキャストされる.

\subsection{fork}
ブロックの生成をした後にブロードキャストをすると,ブロック高の同じ,もしくは相手のブロック高の高いブロックチェーンにたどり着く場合がある.当然,相手のブロックチェーンはこれを破棄する.しかしこの場合,異なるブロックを持った2つのブロックチェーンをこの状態をforkと呼ぶ.fork状態になると,2つの異なるブロックチェーンができることになるため,一つにまとめなければならない.１つにまとめるためにコンセンサスアルゴリズムを用いるが,コンセンサスアルゴリズムについては次章で説明する.

\section{Proof of Workを用いたコンセンサス}
ブロックチェーンでは,パブリックブロックチェーンの場合とコンソーシアムブロックチェーンによってコンセンサスアルゴリズムが変わる.この章ではパブリックブロックチェーンのBitcoin,Ethereumに使われているProof of Workとコンソーシアムブロックチェーンに使えるPaxosを説明する。

\subsection{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の難しさ,正確にいえば１つのブロックを生成する時間を調整している.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に示す.

\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のコンセンサス}
\end{center}
\end{figure}

計算量の差が51\%以上になると,forkしたブロック同士で差が生まれる.それによって,IPアドレスでのコンセンサではなく,CPUの性能によるコンセンサスを取ることができる.\\コンセンサスでは,ブロックとの差が大きければ大きいほど,コンセンサスが正確に取れる.しかし,正しいチェーンが決まるのに時間がかかる.そのため,コンセンサスに必要なブロックの差はコンセンサスの正確性と時間のトレードオフになっている.\\

この方法でコンセンサスを取る場合の欠点を挙げる.
\begin{itemize}
\item CPUのリソースを使用する. 
\item Transactionが確定するのに時間がかかる. 
\end{itemize}

\subsection{Paxos}
コンソーシアムブロックチェーンは許可したのノードのみが参加できるブロックチェーンである.そのため,ノードの数も把握できるため,Paxosを使うことができる.Paxosはノードの多数決によってコンセンサスを取るアルゴリズムである.ただし,Paxosは次のような問題があっても値を一意に決めることができる.
\begin{enumerate}
\item プロセス毎に処理の速度が違う. つまり, メッセージの返信が遅い可能性がある
\item 通信にどれだけの時間がかかるかわからず, その途中でメッセージが失われる可能性がある, 
\item プロセスは停止する可能性がある. また, 復旧する可能性もある.
\end{enumerate}
Proof of Workにある特性の4がないが,コンソーシアムブロックチェーンは3つの問題を解決するだけで十分である.何故ならば,コンソーシアムブロックチェーンは許可したノードのみが参加可能だからである.つまり,悪意あるノードが参加する可能性が少ないためである.//
Paxosは3つの役割ノードがある.
\begin{description}
\item[proposer] 値を提案するノード.
\item[acceptor] 値を決めるノード.
\item[learner] acceptorから値を集計し, 過半数以上のacceptorが持っている値を決める.
\end{description}
Paxosのアルゴリズムの説明の前に,定義された用語の解説をする.いかにその用語の定義を示す.

\begin{description}
\item[提案] 提案は, 異なる提案ごとにユニークな提案番号と値からなる. 提案番号とは, 異なる提案を見分けるための識別子であり, 単調増加する. 値は一意に決まってほしいデータである.
\item[値(提案)がacceptされる] acceptorによって値(提案)が決まること. 
\item[値(提案)が選択(chosen)される] 過半数以上のacceptorによって, 値(提案)がacceptされた場合, それを値(提案)が選択されたと言う.

paxosのアルゴリズムは2フェーズある.\\
1つ目のフェーズ,prepare-promiseは次のような手順で動作する.

1フェーズ目を図にしたものを図3.3に示す.

\begin{figure}[h]
\begin{center}
\includegraphics[width=240pt]{./images/prepare-promise.pdf}
\caption{Proof of Workのコンセンサス}
\end{center}
\end{figure}


2つ目のフェーズ, accept-acceptedは次のような手順で動作する. 
\begin{enumerate}
\item proposerは過半数のacceptorから返信が来たならば, 次の提案をacceptorに送る. これをacceptリクエストという.
\begin{enumerate}
\item もし, 約束のみが返ってきているならば, 任意の値vをprepareリクエストで送った提案に設定する.
\item もし, acceptされた提案が返ってきたら, その中で最大の提案番号を持つ提案の値v'をprepareリクエストで送った提案の値として設定する.
\end{enumerate}

\item acceptorはacceptリクエストが来た場合, Promiseした提案よりもacceptリクエストで提案された提案番号が低ければ, その提案を拒否する. それ以外の場合はacceptする.
\end{enumerate}
２フェーズ目を図にしたものを図3.4に示す.

\begin{figure}[h]
\begin{center}
\includegraphics[width=240pt]{./images/accept-accepted.pdf}
\caption{Proof of Workのコンセンサス}
\end{center}
\end{figure}

このアルゴリズムによって,各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を受け取れない.
\end{enumerate}

2つの方法はメッセージ通信量と耐障害性のトレードオフになっていることがわかる.
Paxosでコンセンサスを取ることは, Proof of Workと比較して次のようなメリットがある.

\begin{itemize}
\item CPUのリソースを消費しない
\item Transactionの確定に時間がかからない.
\end{itemize}

\subsection{Paxosによるブロックチェーン}
PaxosはProof of Workと比べ,CPUのリソースを消費せず,Transactionの確定に時間がかからない.そのため,Paxosでブロックのコンセンサスを取るブロックチェーンを実装することにはメリットがある.また,Paxos自体がリーダー選出に向いているアルゴリズムである.そのため,リーダーを決め,そのノードのブロックチェーンの一貫性のみを考えることもできる.

\section{Chrsitie}
\subsection{Christieとは}
Christieは当研究室で開発している分散フレームワークである.Christieは当研究室で開発している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つがある.

\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操作を行える.
\end{description}

\subsection{プログラミングの例}
ここでは,Christieで実際にプログラムを記述する例を述べる.CGMを作り,setup(new CodeGear)を動かすことにより,DGを持ち合わせ,DGが揃った場合にCodeGearが実装される.CGMを作る方法はStartCodeGear(以下SCG)を継承したものからcreate-CGM(port)methodを実行することによりCGMが作られる.SCGのコードの例をソースコード4.1に示す.

\begin{flushleft}
\lstinputlisting[label=code:StartHelloWorld, caption=StartHelloWorld]{./src/HelloWorld/StartHelloWorld.java}
\end{flushleft}

\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が実行される.
 
 \lstinputlisting[caption=ring.dot, label=code:dot-example]{./src/ring.dot}
 

\begin{figure}[h]
\begin{center}
\includegraphics[width=120pt]{./images/ring.pdf}
\caption{ring.dotを図式化したもの}
\end{center}
\label{fig:dot-example}
\end{figure}
 動的Topologyは参加を表明したノードに対し,動的にノード同士の関係を作る.例えばTreeを構成する場合,参加したノードから順に,rootに近い位置の役割を与える.また,CodeGearはノードが参加しmparentに接続された後に実行される.
 
\subsection{Chrisiteにおけるブロックチェーンの実装の利点と欠点}


Christieにおいてブロック, トランザクション, Paxos, Proof of Workを実装した. 
その際, Christieで実装した場合の便利な点を述べる.

\begin{itemize}
\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に同名の変数がロックされ, 実行されない場合がある. 
\end{itemize}

\section{評価}
本研究室では,実際にコンセンサスアルゴリズムPaxosを分散環境場で実行した,分散環境場で動かすため,JobSchedulerの一種であるTorque Resource Manager(Torque)を使用した.ここではTorqueとは何か,どのような評価をしたかを述べる.

\subsection{Torqueとは}
PCクラスタ上でプログラムの実験を行う際には,他のプログラムとリソースを取り合う懸念がある.それを防ぐためにTorqueを使用する.Torqueはjobという単位でプログラムを管理し,リソースを確保できたら実行する.jobはqsubというコマンドを使って,複数登録することができる.また,実行中の様子も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, 管理する.
\end{description}

今回は図\ref{fig:kvm}のように,学科のKVM上にMaster Node, Submit/Interactive Nodeの役割を持つVM1台と,Computer Nodesとして15台のVMうぶbを用意し,jobの投入を行なった.

\begin{figure}[h]
\begin{center}
\includegraphics[width=240pt]{./images/kvm.pdf}
\caption{環境実験}
\end{center}
\label{fig:kvm}
\end{figure}

jobはシェルスクリプトの形で与えることができる.ソースコードref{code:torque-example}を例として挙げる.

\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数字」というファイルに書き出す.

\subsection{PCクラスタ上でのPaxosの実際の動作}
PCクラスタ上で実際にPaxosを動かした際の解説をする.今回は単純化し,proposerの数を2,accepterの数を3,learnerの数を1としてPaxosを動かし,値が一意に決まる過程を見る.また,分かりやすいように,提案の数値を整数とし,各processerごとに異なった値とした.正確には,「proposer + 数字」の部分を値とし,コンセンサスを取るようにした.実際にPaxosを動かし,シーケンス図で結果を示したものが図\ref{fig:paxos}である.

\begin{figure}[h]
\begin{center}
\includegraphics[width=300pt]{./images/paxos1.pdf}
\caption{Paxos動作を表したシーケンス図}
\end{center}
\label{fig:paxos}
\end{figure}

一意の値を決めることができており,また,Learnerが値を選択した後でも,Paxosは常に決めた値を持ち続けるアルゴリズムである.ログの出力では提案番号がより大きいものの提案まで続いていたが,値がこれ以上覆らなかった。
今回はわかりやすいよう値を数字で行なった実験であるが,これをタランザクション,ブロックに応用することで,ブロックチェーンにおけるコンセンサス部分を完成させることができる.

\section{計測実験}

\section{まとめ}


 
 \end{document}