changeset 11:534d552b4273

update
author akahori
date Mon, 18 Feb 2019 23:59:41 +0900
parents 9627f1774b45
children 2e843f65ac5f
files final_main/chapter1/chapter1.tex final_pre/finalPre.pdf final_pre/finalPre.tex final_pre/images/chain.pdf final_pre/main.pdf
diffstat 5 files changed, 1 insertions(+), 116 deletions(-) [+]
line wrap: on
line diff
--- a/final_main/chapter1/chapter1.tex	Mon Feb 18 23:28:23 2019 +0900
+++ b/final_main/chapter1/chapter1.tex	Mon Feb 18 23:59:41 2019 +0900
@@ -9,7 +9,7 @@
 
 % 序論の目安としては1枚半ぐらい.
 
-コンピュータにおいてデータの破損や不整合は深刻な異常を引き起こす原因となる. そのため, 破損, 不整合を検知するためにブロックチェーン技術を用いたい.  ブロックチェーンは分散ネットワーク技術であり, データの破損や不整合をハッシュ値によって比較できる. そして, 誤操作や改ざんがあった場合でも, ブロックチェーンを用いることで簡単にデータの追跡が行える. 
+コンピュータにおいてデータの破損や不整合は深刻な異常を引き起こす原因となる. そのため, 破損, 不整合を検知するためにブロックチェーン技術を用いたい.  ブロックチェーンは分散ネットワーク技術であり, データの破損や不整合をハッシュ値によって比較できる. そして, 誤操作や改ざんがあった場合でも, ブロックチェーンを用いることでデータの追跡が行える. 
 
 当研究室では分散フレームワークとしてChristieを開発しており, これはGearsOSにファイルシステムとして組み込む予定がある. そのため, Christieにブロックチェーンを実装し, GearsOSに組み込むことにより, GearsOSのファイルシステムにおいてデータの破損, 不整合を検知できる. また, GearsOS同士による分散ファイルシステムを構成することができ, 非中央的にデータの分散ができるようになる. もし分散システムを構成しない場合でもデータの整合性保持は行え, 上記の目的は達成できる.
 
Binary file final_pre/finalPre.pdf has changed
--- a/final_pre/finalPre.tex	Mon Feb 18 23:28:23 2019 +0900
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,115 +0,0 @@
-\documentclass[twocolumn,twoside,9.5pt]{jarticle}
-\usepackage[dvipdfmx]{graphicx}
-\usepackage{picins}
-\usepackage{fancyhdr}
-\usepackage{abstract}
-\usepackage{url}
-%\pagestyle{fancy}
-\lhead{\parpic{\includegraphics[height=1zw,keepaspectratio,bb=0 0 251 246]{pic/emblem-bitmap.pdf}}琉球大学主催 工学部情報工学科 卒業研究発表会}
-\rhead{}
-\cfoot{}
-
-\setlength{\topmargin}{-1in \addtolength{\topmargin}{15mm}}
-\setlength{\headheight}{0mm}
-\setlength{\headsep}{5mm}
-\setlength{\oddsidemargin}{-1in \addtolength{\oddsidemargin}{11mm}}
-\setlength{\evensidemargin}{-1in \addtolength{\evensidemargin}{21mm}}
-\setlength{\textwidth}{181mm}
-\setlength{\textheight}{261mm}
-\setlength{\footskip}{0mm}
-\pagestyle{empty}
-
-\input{dummy.tex}
-\renewcommand{\abstractname}{Abstract}
-\begin{document}
-\title{Christieによるブロックチェーンの実装}
-%\title{Supporting NAT in Screen Sharing System TreeVNC}
-\author{155753A 氏名 {赤堀}{貴一} 指導教員 : 河野 真治}
-\date{}
-\twocolumn [
-\maketitle
-\begin{onecolabstract}
-
-Data corruption and inconsistency in computers causes severe problem. Therefore, detect corruption and inconsistency by Blockchain. The Blockchain is a distributed system.  It is possible to compare between hash value and data which is correct. Even if there are incorrect operation and tampering, data are possible to recover with Blockchain.
-
-We are developing Christie and GearsOS. Christie is a distributed framework and GearsOS is a Operating System. GearsOS Filesystem will refer to Christie. if implementing a block chain in Christie and implementing it in GearsOS, makes it possible to detect data corruption and inconsistency in the GearsOS file system. In addition, it is possible to configure decentralized distributed network between Gears OS. if it does not configure, data is protected. So, our purpose can be achieved.
-
-In this study, We implement Blockchain in Christie and run it in distributed environment on PC cluster.
-\end{onecolabstract}]
-\thispagestyle{fancy} 
-
-\section{研究目的}
-
-コンピュータにおいてデータの破損や不整合は深刻な異常を引き起こす原因となる. そのため, 破損, 不整合を検知するためにブロックチェーン技術を用いたい.  ブロックチェーンは分散ネットワーク技術であり, データの破損や不整合をハッシュ値によって比較できる. そして, 誤操作や改ざんがあった場合でも, ブロックチェーンを用いることでデータの追跡が行える. 
-
-当研究室では分散フレームワークとしてChristieを開発しており, これはGearsOSにファイルシステムに組み込む予定がある. そのため, Christieにブロックチェーンを実装し, GearsOSに組み込むことにより, GearsOSのファイルシステムにおいてデータの破損, 不整合を検知できる. また, GearsOS同士による分散ファイルシステムを構成することができ, 非中央的にデータの分散ができるようになる. もし分散システムを構成しない場合でもデータの整合性保持は行え, 上記の目的は達成できる.
-
-本研究では, Christieにブロックチェーンを実装し, 実際に学科のPCクラスタ上の分散環境で動かす.
-
-\section{ブロックチェーン}
-ブロックチェーンとは分散型台帳技術とも呼ばれ, 複数のトランザクションをまとめたブロックをつなげたものを, システムに参加しているすべてのノードが参照できる技術である. 
-ブロックチェーンを実装することは次のようなメリットが有る.
-
-\begin{itemize}
-\item データの追跡, 検証が容易である.
-\item 中央管理者が存在しない. 単一障害点がない.
-\end{itemize}
-
-データの追跡, 検証が容易であるのは, ブロックの構造によるものである. ブロックの構造は簡易化すれば次のようなものである.
-
-\begin{itemize}
-\item 前のブロックの暗号化ハッシュ.
-\item タイムスタンプ.
-\item nonce
-\item トランザクションリスト.
-\end{itemize}
-
-ブロックは前のブロックと暗号化ハッシュでつながっている. 前のブロックのハッシュは, これらのパラメータがつなげられてハッシュ化されている. また, 現在のブロックのハッシュが作られる際も同様に, 直前のブロックのハッシュに依存して作られる. そのため, もしブロックを改ざんするならば, その先につながるすべてのブロックを改ざんしなければならない. 
-
-しかし, その仕組みだけならば複数のブロックのハッシュを同時に改ざんすることで, データが改ざんされてしまう可能性がある. そのため, ブロックに付け加える際に計算作業を行わせ, それによってある条件に収まるHashを作らせることで, 改ざんの可能性が抑えられている. 例えば, ビットコインだとProof of Workという計算問題を解かせ, Hashを生成する. これは単純にはソースコード\ref{code:proof of work}のような問題を解くのと同義である. 
-
-
-実際には $0 < rand() < 10000$はもっと大きな値であり, またこれは複数ノードでの分散環境下で計算される. もし, 条件に合うブロックのハッシュが生成できたならば, 他のノードによってそのハッシュが実際に生成されるかどうかを調べる. これを検証するのは, ハッシュが条件に収まっているか否かを判定するだけで良いので容易である. しかし, 新しい条件に収まるHashは簡単には求まらない. しかも, 1つを改ざんすればそれに連なるブロックすべてのHashが変わるため, これら全部を書き換える計算量は膨大なものになる. この仕組みにより, 改ざんを起きにくくしている. 
-
-トランザクションの中身はデータ, 前のトランザクションと後ろのトランザクションのハッシュ, 暗号鍵でのトランザクションの署名となっている. 署名により, 誰のトランザクションかが簡単にわかる.
-
-もし条件に当てはまるブロックが同時に複数作られた場合, ブロックに分岐が発生する場合がある. これをフォークという. これは一種の競合状態である. 分岐したブロック同士にある一定の差がついた場合, 長い方を正しいものとし, 競合を解決する. 
-
-ノード同士の通信は, すべてのノードが対等に通信を行うPeer to Peer方式で行われる. トランザクションやブロックが来た場合, ノードはそれらが正当なものかをルールに従って検証する. そしてトランザクション, ブロックが承認された場合, 他のノードにそのトランザクション, もしくはブロックを送り, 承認されなかった場合は破棄する. これによって, 承認されたものだけがネットワーク上に伝搬されていく.
-
- このような複数の仕組みによって, 中央管理者を必要とせずにデータの整合性保持が行われる..
-
-\section{Christie}
-
-Christieは当研究室で開発している分散フレームワークである. ChristieはJavaで書かれているが, 当研究室で開発しているGearsOSに組み込まれる予定がある. そのため, GearsOSを構成する言語Continuation based Cと似た概念がある. Christieに存在する概念として次のようなものがある.
-
-\begin{itemize}
-\item CodeGear(以下CG)
-\item DataGear(以下DG)
-\item CodeGearManager(以下CGM)
-\item DataGearManager(以下DGM)
-\end{itemize}
-
-CGはクラス, スレッドに相当し, DGは変数データに相当する. CGMはノードであり, DGM, CG, DGを管理する. DGMはDGを管理するものであり, putという操作により変数データ, つまりDGを格納できる. 
-
-DGMにはLocalとRemoteと2つの種類があり, Localであれば, LocalのCGMが管理しているDGMに対し, DGを格納していく. Remoteであれば接続したRemote先のCGMのDGMにDGを格納できる. DGを取り出す際にはアノテーションを付けることで, データの取り出し方も指定できる. Take, Peekという操作があり, Takeは読み込んだDGが消えるが, PeekはDGを消さずにそのまま残す. また, RemoteTake, RemotePeekというものもあり, リモート先を指定することにより, RemoteDGMからデータを取ることができる.
-
-CGはCGMによって実行されるが, 実行するにはCGに必要なDGが全て揃う必要がある. もしDGが全て揃わない場合, CGMはずっとlistenし, データが揃うまで実行を待つ.
-
-
-\section{まとめ}
-中間予稿までにやったこととして, Paxosの論文を読み, ChristieにTopologyManagerという機能を実装した. 
-
-Paxosを読んだ理由は, コンセンサスアルゴリズムの調査である. 実際, Paxosもビットコインで使用される候補に上がったコンセンサスアルゴリズムである. 分散システムはどのようなコンセンサスアルゴリズムを用いているかで性能が変わる. 例えばビットコインのコンセンサスアルゴリズムProof of Workは, 計算量を多くして改ざんを起こりにくくしているが無駄が多く, 10分以内で解かれないように動的に条件を変更している. これは先ほどの, 同時にブロックを変更するのを防ぐため, つまり信頼性を上げるためであるが, 速度面で大きな課題となる. 分散ファイルシステムを構成するにはスケーラビリティが課題であり, ノードの数が多くなればなるほど通信時間がかかる. そのため, コンセンサスリズムとして有名なPaxosの論文を読んだ.
-
-ChristieにTopologyManagerを実装した理由は, Christieのコードに慣れるため, そしてTopologyManager上に分散システムを実装するのが容易になるからである. TopologyManagerとは, ノードにTopologyを構成させ, ノードごとにどこのノードにつながればいいかを指定する機能である. Christieでは静的, 動的なトポロジー管理ができる. 静的ではdotファイルというものにノードごとの関係を記述する. 動的ではノードの木構造を作る. 
-
-
-また, ブロックチェーンについては実際にブロックを実装し, 簡易的ではあるがProof of Workを動かして理解を深めた. 
-
-今後の課題として, ブロックチェーンのトランザクション部分と分散環境を実装する. そして, 実際に分散環境下においてブロックチェーンを動かし, データの整合性保持, 追跡が行えるかを確認していく. コンセンサスアルゴリズムも調査していき, ファイルシステムに組み込めるコンセンサスアルゴリズムを探していきたい. 
-
-\nocite{*}
-\bibliographystyle{junsrt}
-\bibliography{reference}
-\end{document}
\ No newline at end of file
Binary file final_pre/images/chain.pdf has changed
Binary file final_pre/main.pdf has changed