# HG changeset patch
# User ichikitakahiro <e165713@ie.u-ryukyu.ac.jp>
# Date 1558766663 -32400
# Node ID d1dff3305e0db76be6da11067f35d7a530e8af11
# Parent  2b71bf2c73c976654c8a203c5cf3d3e27108ba8e
upgrade

diff -r 2b71bf2c73c9 -r d1dff3305e0d slide/prosym.html
--- a/slide/prosym.html	Tue May 21 17:09:58 2019 +0900
+++ b/slide/prosym.html	Sat May 25 15:44:23 2019 +0900
@@ -91,7 +91,7 @@
 <div class='slide'>
   
 <!-- _S9SLIDE_ -->
-<h1 id="研究目的">研究目的</h1>
+<h2 id="研究目的">研究目的</h2>
 
 <ul>
   <li>コンピュータのデータの不整合は, 誤作動や複数人によるデータの同時書き込みによって発生し, 特に分散環境下で問題となる.</li>
@@ -111,11 +111,18 @@
 
 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h1 id="christie">Christie</h1>
+<h2 id="christie">Christie</h2>
 <ul>
   <li>Christieは当研究室で開発している分散フレームワークである.</li>
   <li>現在はjava上で開発されているが, GearsOSに組み込む予定があるため, 言語Continuation based Cへ書き換え可能な構成となっている. (?GeasOSの解説がより欲しい？)</li>
-  <li>言語CbCと近い概念としてCodeGear(以下CG), CodeGearManager(以下CGM), DataGear(以下DG), DataGearManager(以下DGM)という概念が存在する.</li>
+  <li>言語CbCと近い概念として以下の概念が存在する。
+    <ul>
+      <li>CodeGear(以下CG)</li>
+      <li>CodeGearManager(以下CGM)</li>
+      <li>DataGear(以下DG)</li>
+      <li>DataGearManager(以下DGM)</li>
+    </ul>
+  </li>
 </ul>
 
 
@@ -124,14 +131,17 @@
 
 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h1 id="christieの言語概念">Christieの言語概念</h1>
+<h2 id="christieの言語概念">Christieの言語概念</h2>
 <ul>
   <li>CGはスレッド, クラスに相当し, javaの継承を用いて記述する.</li>
   <li>DGは変数データに相当し, CG内でアノテーションを用いて変数データを取り出せる.</li>
   <li>CGMはノードであり, DG, CG, DGMを管理する.</li>
-  <li>DGMはDGを管理するものであり, putという操作により, 変数データ(DG)を格納できる.</li>
-  <li>DGMにはLocalDGMとRemoteDGMが存在する。LocalDGMは各ノード固有のデータベースである。RemoteDSMは他ノードのLocalDGMに対応するproxyであり、接続しているノードの数だけ存在する。</li>
-  <li>DGMのput操作を行う際にはLocalとRemoteのどちらかを選ぶ.Localであれば、LocalのCGMが管理するDGMに対しDGを格納し, Remoteの場合は接続したRemoteさきのCGMのDGMにDGを格納する.</li>
+  <li>DGMはDGを管理するものであり, putという操作により, 変数データ(DG)を格納できる.
+    <ul>
+      <li>DGMにはLocalDGMとRemoteDGMが存在する。LocalDGMは各ノード固有のデータベースである。RemoteDSMは他ノードのLocalDGMに対応するproxyであり、接続しているノードの数だけ存在する。</li>
+      <li>DGMのput操作を行う際にはLocalとRemoteのどちらかを選ぶ.Localであれば、LocalのCGMが管理するDGMに対しDGを格納し, Remoteの場合は接続したRemoteさきのCGMのDGMにDGを格納する.</li>
+    </ul>
+  </li>
 </ul>
 
 
@@ -140,7 +150,7 @@
 
 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h1 id="dgm">DGM</h1>
+<h2 id="dgm">DGM</h2>
 <ul>
   <li>RocalDGMを立ち上げるにはDataSegmentクラスが提供する、connectメソッドを用い、接続したいポートのipアドレスとport番号、そして任意のManager名を指定することで立ち上げる。</li>
   <li>立ち上げ後はManager名を指定してDataSegmentAPI用いてDSのやり取りを行うため、プログラマはManager名を意識することでLocalへの操作もRemoteへの操作も同様に扱える。</li>
@@ -152,14 +162,33 @@
 
 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h1 id="dgのアノテーション">DGのアノテーション</h1>
+<h2 id="dgのアノテーション">DGのアノテーション</h2>
 <ul>
   <li>DGを取り出す際にはCG内で宣言した変数データにアノテーションをつける。DGアノテーションには
-Take、Peek、TakeFrom、PeekFrom、の4つがある。</li>
-  <li>Take 先頭のDGを読み込み、そのDGを削除する。</li>
-  <li>Peek 先頭のDGを読み込むが、DGが消去されない。そのため特に操作をしない場合、同じデータを参照し続ける。</li>
-  <li>TakeFrom Takeと似ているが、Remote DGM nameをしているすることで、その接続先のDGM からTake操作をおこえる。</li>
-  <li>PeekFrom Peekと似ているが、 Remote DGM nameをしているすることで、その接続先のDGM からPeek操作をおこえる。</li>
+Take、Peek、TakeFrom、PeekFrom、の4つがある。
+    <ul>
+      <li>Take
+        <ul>
+          <li>先頭のDGを読み込み、そのDGを削除する。</li>
+        </ul>
+      </li>
+      <li>Peek
+        <ul>
+          <li>先頭のDGを読み込むが、DGが消去されない。そのため特に操作をしない場合、同じデータを参照し続ける。</li>
+        </ul>
+      </li>
+      <li>TakeFrom
+        <ul>
+          <li>Takeと似ているが、Remote DGM nameをしているすることで、その接続先のDGM からTake操作をおこえる。</li>
+        </ul>
+      </li>
+      <li>PeekFrom
+        <ul>
+          <li>Peekと似ているが、 Remote DGM nameをしているすることで、その接続先のDGM からPeek操作をおこえる。</li>
+        </ul>
+      </li>
+    </ul>
+  </li>
 </ul>
 
 
@@ -168,7 +197,7 @@
 
 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h1 id="christieのコード例">Christieのコード例</h1>
+<h2 id="christieのコード例">Christieのコード例</h2>
 <pre><code class="language-code">package christie.example.HelloWorld;
 
 import christie.codegear.CodeGearManager;
@@ -196,13 +225,12 @@
 
 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h1 id="annottation">Annottation</h1>
+<h2 id="annottation">Annottation</h2>
 <ul>
   <li>ChristieではInputDGの指定にはアノテーションを使う。</li>
   <li>アノテーションとはクラスやメソッド、パッケージに対して、付加情報を記述できるJavaのMeta Computationである。</li>
   <li>先頭に@をつけることで記述し、オリジナルのアノテーションを定義することもできるInput
 となる型の変するを直接宣言し、変数名としてkeyを記述する。その上にアノテーションでTakeもしくはPeekを指定する。
--
     <pre><code class="language-code">@Take
 public String name;
 </code></pre>
@@ -218,7 +246,7 @@
 
 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h1 id="topologymanager">TopologyManager</h1>
+<h2 id="topologymanager">TopologyManager</h2>
 <ul>
   <li>TopologyManagerとはTopologyを形成するために、参加を表明したノード、TopologyNodeに名前を与え、必要があればノード同士の配線を行うノードである。</li>
   <li>TopologyManagerのTopology形成方法として、静的Topologyと動的Topologyがある。</li>
@@ -231,7 +259,7 @@
 
 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h1 id="静的topology">静的Topology</h1>
+<h2 id="静的topology">静的Topology</h2>
 <ul>
   <li>静的Toopologyはdotファイルを与えることでノード関係を下の図のようにする。</li>
   <li>静的Topologyはdotファイルのノード数と同等のTopologyNodeがあって初めて、CodeGearが実行される。
@@ -254,7 +282,7 @@
 
 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h1 id="ブロックチェーンのトランザクション">ブロックチェーンのトランザクション</h1>
+<h2 id="ブロックチェーンのトランザクション">ブロックチェーンのトランザクション</h2>
 <ul>
   <li>ブロックチェーンはP2Pにてネットワーク間が動作している。つまり、ブロックチェーンにはサーバー、クライアントの区別がなく全てのノードが平等である。</li>
   <li>ブロックチェーンにおけるブロックは複数のトランザクションをまとめたものである。ブロックの構造は使用するコンセンサスにより変わるが基本的には、previous block hash, merkle root hash, timeが含まれるBlockHeaderとTransactionListにより構成される。</li>
@@ -266,7 +294,7 @@
 
 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h1 id="blockheader">BlockHeader</h1>
+<h2 id="blockheader">BlockHeader</h2>
 <ul>
   <li>BlockHeaderには、前のブロックをハッシュ化したもの、トランザクションをまとめたmarkle treeのrootのhash、そのブロックを生成したtimeとなっている。</li>
   <li>previous block hashは、前のブロックのパラメータを並べてhash化したものである。</li>
@@ -282,7 +310,7 @@
 
 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h1 id="blockの動作">Blockの動作</h1>
+<h2 id="blockの動作">Blockの動作</h2>
 <ul>
   <li>ブロックが生成された場合、知っているノードにそのブロックをブロードキャストする。通信量を抑えるためにブロックを送ったあと、ブロックをシリアライズして送信する場合もある。</li>
   <li>誤りがあればさらにそのノードがブロックをブロードキャストする。そしてTransaction PoolというTransactionをためておく場所から、そのブロックに含まれるTransactionを削除し、新しいブロックを生成する。</li>
@@ -294,14 +322,34 @@
 
 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h1 id="transaction">Transaction</h1>
+<h2 id="transaction">Transaction</h2>
 <ul>
   <li>トランザクションとはデータのやり取りを行なった記録の最小単位である。トランザクションの構造は次のとおりである。</li>
-  <li>TransactionHash トランザクションをハッシュ化したもの。</li>
-  <li>data データ</li>
-  <li>sendAddress 送り元のアドレス。</li>
-  <li>receiveAddress 送り先のアカウントのアドレス。</li>
-  <li>signature トランザクションの一部と秘密鍵をSHA256でハッシュ化したもの。ECDSAで署名している。</li>
+  <li>TransactionHash
+    <ul>
+      <li>トランザクションをハッシュ化したもの。</li>
+    </ul>
+  </li>
+  <li>data
+    <ul>
+      <li>データ</li>
+    </ul>
+  </li>
+  <li>sendAddress
+    <ul>
+      <li>送り元のアドレス。</li>
+    </ul>
+  </li>
+  <li>receiveAddress
+    <ul>
+      <li>送り先のアカウントのアドレス。</li>
+    </ul>
+  </li>
+  <li>signature
+    <ul>
+      <li>トランザクションの一部と秘密鍵をSHA256でハッシュ化したもの。ECDSAで署名している。</li>
+    </ul>
+  </li>
   <li>トランザクションはノード間で伝搬され、ノードごとに検証される。そして検証を終え、不正なトランザクションであればそれを破棄し、検証に通った場合はTransaction Poolに取り込まれ、また検証したノードからトランザクションがブロードキャストする。</li>
 </ul>
 
@@ -311,11 +359,47 @@
 
 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h1 id="data-gear">Data Gear</h1>
+<h2 id="コンセンサスアルゴリズム">コンセンサスアルゴリズム</h2>
 <ul>
-  <li>Data Gear は データの単位であり、int や文字列などの Primitive Type を持っている。</li>
-  <li>Code Gear は任意の数の Input Data Gear を参照して処理を行い、Output Data Gear を出力し処理を終える。</li>
-  <li>Code Gear は接続された Data Gear 以外には参照を行わない。</li>
+  <li>fork
+    <ul>
+      <li>ブロック生成後にブロードキャストを行うと、ブロック高の同じもしくは高いブロックチェーンにたどり着く状態があり、異なるブロックを持った二つのブロックチェーンのうちどちらかを破棄する必要がある。</li>
+    </ul>
+  </li>
+  <li>fork状態を解消するために用いられるのがコンセンサスアルゴリズムである。</li>
+  <li>ブロックチェーンはパブリックブロックチェーンとコンソーシアムブロックチェーンの場合によってコンセンサスアルゴリズムが変わる。
+    <ul>
+      <li>パブリックブロックチェーン
+        <ul>
+          <li>不特定たすのノードが参加するブロックチェーンを指す。</li>
+          <li>不特定多数のノード間、全体のノードの参加数が変わる状況でコンセンサスの変わるアルゴリズムでなければならない。</li>
+        </ul>
+      </li>
+      <li>コンソーシアムブロックチェーン
+        <ul>
+          <li>許可したノードのみが参加できるブロックチェーンである。</li>
+        </ul>
+      </li>
+    </ul>
+  </li>
+</ul>
+
+
+
+</div>
+
+<div class='slide'>
+  <!-- _S9SLIDE_ -->
+<h1 id="paxos">Paxos</h1>
+<ul>
+  <li>Paxosはノードの多数決によってコンセンサスをとるアルゴリズムである。</li>
+  <li>Paxosは以下のような問題があっても値を一意に決めることができる。
+    <ul>
+      <li>1,プロセス毎に処理の速度が違う。つまりメッセージの返信が遅い可能性がある。</li>
+      <li>2,通信にどれだけの時間がかかるかわからず、その途中でメッセージが失われる可能性がある。</li>
+      <li>3,プロセスは停止する可能性もある。</li>
+    </ul>
+  </li>
 </ul>
 
 
@@ -324,15 +408,77 @@
 
 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h1 id="gears-でのメタ計算">Gears でのメタ計算</h1>
+<h1 id="paxosの役割ノード">Paxosの役割ノード</h1>
 <ul>
-  <li>Gears OS ではメタ計算を Meta Code Gear、Meta Data Gear で表現する。</li>
-  <li>Meta Code Gear はノーマルレベルの Code Gear の直後に遷移され、メタ計算を実行する。</li>
-  <li>Meta Code Gear で OS の機能であるメモリ管理やスレッド管理を行う。</li>
+  <li>Paxosは3つの役割ノードがある。
+    <ul>
+      <li>proposer
+        <ul>
+          <li>値を提案するノード。</li>
+        </ul>
+      </li>
+      <li>accepter
+        <ul>
+          <li>値を決めるノード。</li>
+        </ul>
+      </li>
+      <li>lerner
+        <ul>
+          <li>accepterから値を集計し、過半数以上のaccepterが持っている値を決める。</li>
+        </ul>
+      </li>
+    </ul>
+  </li>
 </ul>
 
+
+
+</div>
+
+<div class='slide'>
+  <!-- _S9SLIDE_ -->
+<h1 id="paxosの役割定義">Paxosの役割定義</h1>
+<ul>
+  <li>提案
+    <ul>
+      <li>異なる提案ごとにユニークな提案番号と値からなる。提案番号とは、異なる提案を見分けるための識別子であり、単調増加である。</li>
+    </ul>
+  </li>
+  <li>値(提案)がacceptされる
+    <ul>
+      <li>accepterによって値(提案)が決まること。</li>
+    </ul>
+  </li>
+  <li>値(提案)が選択(chosen)される
+    <ul>
+      <li>過半数以上のacceptorによって、値がacceptされた場合、それを値(提案)が選択されたと言う。</li>
+    </ul>
+  </li>
+</ul>
+
+
+
+</div>
+
+<div class='slide'>
+  <!-- _S9SLIDE_ -->
+<h1 id="paxosのアルゴリズム">paxosのアルゴリズム</h1>
+<ul>
+  <li>paxosのアルゴリズムは2フューズあり、一つ目のフェーズprepare-promiseと二つ目のフェーズaccept-acceptedの二つに区分される。</li>
+</ul>
+
+
+
+</div>
+
+<div class='slide'>
+  <!-- _S9SLIDE_ -->
+<h1 id="paxosのアルゴリズム-prepare-promise">paxosのアルゴリズム prepare-promise</h1>
+<ul>
+  <li>(言葉での説明記入?)</li>
+</ul>
 <div style="text-align: center;">
-　<img src="./fig/meta.pdf" alt="MetaGear" width="600" />
+　<img src="../paper/images/prepare-promise.pdf" alt="MetaGear" width="600" />
 </div>
 
 
@@ -341,26 +487,19 @@
 
 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h1 id="gears-でのメタ計算の記述">Gears でのメタ計算の記述</h1>
-
+<h1 id="paxosのアルゴリズム-accept-accepted">paxosのアルゴリズム accept-accepted</h1>
 <ul>
-  <li>各 Code Gear の引数は Data Gear である。</li>
-  <li>code1, node2 は ノーマルな Code Gear であり、meta は Meta Code Gear である。</li>
+  <li>(1)proposerは過半数のacceptorから返事が来たのなら、次の提案をaccepterに送る。これをacceptリクエストという。
+    <ul>
+      <li>(a)もし、約束のみ帰って来ているのならば、任意の値vをprepareリクエストで送った提案に設定する。</li>
+      <li>(b)もし、acceptされた提案が帰って来たら、その中で最大の提案番号v’をprepareリクエストで送った提案の値として設定する。</li>
+    </ul>
+  </li>
+  <li>(2)acceptorはacceptリクエストが来た場合、Promiseした提案よりもacceptリクエストで提案された番号が低ければ、その提案を拒否する。それ以外の場合、acceptする。</li>
 </ul>
-
-<pre><code class="language-code">__code code1 (struct Array* array) {
-    ...
-    goto code2(array);
-}
-
-__code meta(struct Context* context, enum Code next) {
-    goto (context-&gt;code[next])(context);
-}
-
-__code code2(struct Array* array) {
-    ...
-}
-</code></pre>
+<div style="text-align: center;">
+　<img src="../paper/images/accept-accepted.pdf" alt="MetaGear" width="600" />
+</div>
 
 
 
@@ -368,32 +507,16 @@
 
 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h1 id="gears-os-の構成">Gears OS の構成</h1>
+<h1 id="paxos-1">Paxos</h1>
 <ul>
-  <li>Gears OS は以下の要素で構成される。
+  <li>Proof of Workと比較しメッセージ通信量と耐障害性のトレードオフになっている。</li>
+  <li>Paxosでコンセンサスを取る際、Proof of Workと比較して次のようなメリットがある。
     <ul>
-      <li>Context
-        <ul>
-          <li>使用されるCode/Data Gear のリストを持っておりTaskでもある。</li>
-        </ul>
-      </li>
-      <li>TaskQueue
-        <ul>
-          <li>Task のリストを扱う</li>
-        </ul>
-      </li>
-      <li>TaskManager
-        <ul>
-          <li>Task の依存関係の解決、作成や停止を行います。</li>
-        </ul>
-      </li>
-      <li>Worker
-        <ul>
-          <li>Task の実行を行う</li>
-        </ul>
-      </li>
+      <li>CPUにリソースを消費しない。</li>
+      <li>Transactionの確定に時間がかからない。</li>
     </ul>
   </li>
+  <li>Paxos自体がリーダー選出に向いているアルゴリズムである。そのため、リーダーを決定し、そのノードのブロックチェーンの一貫性のみをかんがえることができる。</li>
 </ul>
 
 
diff -r 2b71bf2c73c9 -r d1dff3305e0d slide/prosym.md
--- a/slide/prosym.md	Tue May 21 17:09:58 2019 +0900
+++ b/slide/prosym.md	Sat May 25 15:44:23 2019 +0900
@@ -4,7 +4,7 @@
 lang: Japanese
 code-engine: coderay
 
-# 研究目的
+## 研究目的
 
 - コンピュータのデータの不整合は, 誤作動や複数人によるデータの同時書き込みによって発生し, 特に分散環境下で問題となる.
 - ブロックチェーンはデータの分散ができ, 不整合の検知が可能な仕組みとなっている.
@@ -16,32 +16,40 @@
 
 -->
 
-# Christie
+## Christie
 - Christieは当研究室で開発している分散フレームワークである.
 - 現在はjava上で開発されているが, GearsOSに組み込む予定があるため, 言語Continuation based Cへ書き換え可能な構成となっている. (?GeasOSの解説がより欲しい？)
-- 言語CbCと近い概念としてCodeGear(以下CG), CodeGearManager(以下CGM), DataGear(以下DG), DataGearManager(以下DGM)という概念が存在する.
+- 言語CbCと近い概念として以下の概念が存在する。
+  - CodeGear(以下CG)
+  - CodeGearManager(以下CGM)
+  - DataGear(以下DG)
+  - DataGearManager(以下DGM)
 
-# Christieの言語概念
+## Christieの言語概念
 - CGはスレッド, クラスに相当し, javaの継承を用いて記述する.
 - DGは変数データに相当し, CG内でアノテーションを用いて変数データを取り出せる.
 - CGMはノードであり, DG, CG, DGMを管理する.
 - DGMはDGを管理するものであり, putという操作により, 変数データ(DG)を格納できる.
-- DGMにはLocalDGMとRemoteDGMが存在する。LocalDGMは各ノード固有のデータベースである。RemoteDSMは他ノードのLocalDGMに対応するproxyであり、接続しているノードの数だけ存在する。
-- DGMのput操作を行う際にはLocalとRemoteのどちらかを選ぶ.Localであれば、LocalのCGMが管理するDGMに対しDGを格納し, Remoteの場合は接続したRemoteさきのCGMのDGMにDGを格納する.
+  - DGMにはLocalDGMとRemoteDGMが存在する。LocalDGMは各ノード固有のデータベースである。RemoteDSMは他ノードのLocalDGMに対応するproxyであり、接続しているノードの数だけ存在する。
+  - DGMのput操作を行う際にはLocalとRemoteのどちらかを選ぶ.Localであれば、LocalのCGMが管理するDGMに対しDGを格納し, Remoteの場合は接続したRemoteさきのCGMのDGMにDGを格納する.
 
-# DGM
+## DGM
 - RocalDGMを立ち上げるにはDataSegmentクラスが提供する、connectメソッドを用い、接続したいポートのipアドレスとport番号、そして任意のManager名を指定することで立ち上げる。
 - 立ち上げ後はManager名を指定してDataSegmentAPI用いてDSのやり取りを行うため、プログラマはManager名を意識することでLocalへの操作もRemoteへの操作も同様に扱える。
 
-# DGのアノテーション
+## DGのアノテーション
 - DGを取り出す際にはCG内で宣言した変数データにアノテーションをつける。DGアノテーションには
 Take、Peek、TakeFrom、PeekFrom、の4つがある。
-- Take 先頭のDGを読み込み、そのDGを削除する。
-- Peek 先頭のDGを読み込むが、DGが消去されない。そのため特に操作をしない場合、同じデータを参照し続ける。
-- TakeFrom Takeと似ているが、Remote DGM nameをしているすることで、その接続先のDGM からTake操作をおこえる。
-- PeekFrom Peekと似ているが、 Remote DGM nameをしているすることで、その接続先のDGM からPeek操作をおこえる。
+  - Take
+    - 先頭のDGを読み込み、そのDGを削除する。
+  - Peek
+    - 先頭のDGを読み込むが、DGが消去されない。そのため特に操作をしない場合、同じデータを参照し続ける。
+  - TakeFrom
+    - Takeと似ているが、Remote DGM nameをしているすることで、その接続先のDGM からTake操作をおこえる。
+  - PeekFrom
+    - Peekと似ているが、 Remote DGM nameをしているすることで、その接続先のDGM からPeek操作をおこえる。
 
-# Christieのコード例
+## Christieのコード例
 ```code
 package christie.example.HelloWorld;
 
@@ -64,12 +72,11 @@
 
 ```
 
-# Annottation
+## Annottation
 - ChristieではInputDGの指定にはアノテーションを使う。
 - アノテーションとはクラスやメソッド、パッケージに対して、付加情報を記述できるJavaのMeta Computationである。
 - 先頭に@をつけることで記述し、オリジナルのアノテーションを定義することもできるInput
 となる型の変するを直接宣言し、変数名としてkeyを記述する。その上にアノテーションでTakeもしくはPeekを指定する。
--
 ```code
 @Take
 public String name;
@@ -79,12 +86,12 @@
 public String name;
 ```
 
-# TopologyManager
+## TopologyManager
 - TopologyManagerとはTopologyを形成するために、参加を表明したノード、TopologyNodeに名前を与え、必要があればノード同士の配線を行うノードである。
 - TopologyManagerのTopology形成方法として、静的Topologyと動的Topologyがある。
 - 動的Topologyは参加を表明したノードに対し、動的にノード同士の関係を作る。例えばTreeを構成する場合、参加したノードから順にrootに近い役割を与え、またCodeGearはノードが参加し、parentに接続された後に実行される。
 
-# 静的Topology
+## 静的Topology
 - 静的Toopologyはdotファイルを与えることでノード関係を下の図のようにする。
 - 静的Topologyはdotファイルのノード数と同等のTopologyNodeがあって初めて、CodeGearが実行される。
 ```Code
@@ -99,11 +106,11 @@
 　<img src="../paper/images/ring.pdf" alt="MetaGear" width="300">
 </div>
 
-# ブロックチェーンのトランザクション
+## ブロックチェーンのトランザクション
 - ブロックチェーンはP2Pにてネットワーク間が動作している。つまり、ブロックチェーンにはサーバー、クライアントの区別がなく全てのノードが平等である。
 - ブロックチェーンにおけるブロックは複数のトランザクションをまとめたものである。ブロックの構造は使用するコンセンサスにより変わるが基本的には、previous block hash, merkle root hash, timeが含まれるBlockHeaderとTransactionListにより構成される。
 
-# BlockHeader
+## BlockHeader
 - BlockHeaderには、前のブロックをハッシュ化したもの、トランザクションをまとめたmarkle treeのrootのhash、そのブロックを生成したtimeとなっている。
 - previous block hashは、前のブロックのパラメータを並べてhash化したものである。
 - 上記のものがそれぞれ連なっていることによって下の図のようなブロック繋がっている。そのため一つが更新されたらそのあとにつながるブロック全てを更新しなければならなくなる。
@@ -111,64 +118,87 @@
 　<img src="../paper/images/chain.pdf" alt="MetaGear" width="600">
 </div>
 
-# Blockの動作
+## Blockの動作
 - ブロックが生成された場合、知っているノードにそのブロックをブロードキャストする。通信量を抑えるためにブロックを送ったあと、ブロックをシリアライズして送信する場合もある。
 - 誤りがあればさらにそのノードがブロックをブロードキャストする。そしてTransaction PoolというTransactionをためておく場所から、そのブロックに含まれるTransactionを削除し、新しいブロックを生成する。
 
-# Transaction
+## Transaction
 - トランザクションとはデータのやり取りを行なった記録の最小単位である。トランザクションの構造は次のとおりである。
-- TransactionHash トランザクションをハッシュ化したもの。
-- data データ
-- sendAddress 送り元のアドレス。
-- receiveAddress 送り先のアカウントのアドレス。
-- signature トランザクションの一部と秘密鍵をSHA256でハッシュ化したもの。ECDSAで署名している。
+- TransactionHash
+  - トランザクションをハッシュ化したもの。
+- data
+  - データ
+- sendAddress
+  - 送り元のアドレス。
+- receiveAddress
+  - 送り先のアカウントのアドレス。
+- signature
+  - トランザクションの一部と秘密鍵をSHA256でハッシュ化したもの。ECDSAで署名している。
 - トランザクションはノード間で伝搬され、ノードごとに検証される。そして検証を終え、不正なトランザクションであればそれを破棄し、検証に通った場合はTransaction Poolに取り込まれ、また検証したノードからトランザクションがブロードキャストする。
 
 
-# Data Gear
-- Data Gear は データの単位であり、int や文字列などの Primitive Type を持っている。
-- Code Gear は任意の数の Input Data Gear を参照して処理を行い、Output Data Gear を出力し処理を終える。
-- Code Gear は接続された Data Gear 以外には参照を行わない。
+## コンセンサスアルゴリズム
+- fork
+  - ブロック生成後にブロードキャストを行うと、ブロック高の同じもしくは高いブロックチェーンにたどり着く状態があり、異なるブロックを持った二つのブロックチェーンのうちどちらかを破棄する必要がある。
+- fork状態を解消するために用いられるのがコンセンサスアルゴリズムである。
+- ブロックチェーンはパブリックブロックチェーンとコンソーシアムブロックチェーンの場合によってコンセンサスアルゴリズムが変わる。
+  - パブリックブロックチェーン
+    - 不特定たすのノードが参加するブロックチェーンを指す。
+    - 不特定多数のノード間、全体のノードの参加数が変わる状況でコンセンサスの変わるアルゴリズムでなければならない。
+  - コンソーシアムブロックチェーン
+    - 許可したノードのみが参加できるブロックチェーンである。
+
+# Paxos
+- Paxosはノードの多数決によってコンセンサスをとるアルゴリズムである。
+- Paxosは以下のような問題があっても値を一意に決めることができる。
+  - 1,プロセス毎に処理の速度が違う。つまりメッセージの返信が遅い可能性がある。
+  - 2,通信にどれだけの時間がかかるかわからず、その途中でメッセージが失われる可能性がある。
+  - 3,プロセスは停止する可能性もある。
 
-# Gears でのメタ計算
-- Gears OS ではメタ計算を Meta Code Gear、Meta Data Gear で表現する。
-- Meta Code Gear はノーマルレベルの Code Gear の直後に遷移され、メタ計算を実行する。
-- Meta Code Gear で OS の機能であるメモリ管理やスレッド管理を行う。
+# Paxosの役割ノード
+- Paxosは3つの役割ノードがある。
+  - proposer
+    - 値を提案するノード。
+  - accepter
+    - 値を決めるノード。
+  - lerner
+    - accepterから値を集計し、過半数以上のaccepterが持っている値を決める。
 
+# Paxosの役割定義
+- 提案
+  - 異なる提案ごとにユニークな提案番号と値からなる。提案番号とは、異なる提案を見分けるための識別子であり、単調増加である。
+- 値(提案)がacceptされる
+  - accepterによって値(提案)が決まること。
+- 値(提案)が選択(chosen)される
+  - 過半数以上のacceptorによって、値がacceptされた場合、それを値(提案)が選択されたと言う。
+
+
+# paxosのアルゴリズム
+- paxosのアルゴリズムは2フューズあり、一つ目のフェーズprepare-promiseと二つ目のフェーズaccept-acceptedの二つに区分される。
+
+# paxosのアルゴリズム prepare-promise
+- (言葉での説明記入?)
 <div style="text-align: center;">
-　<img src="./fig/meta.pdf" alt="MetaGear" width="600">
+　<img src="../paper/images/prepare-promise.pdf" alt="MetaGear" width="600">
 </div>
 
-# Gears でのメタ計算の記述
-
-- 各 Code Gear の引数は Data Gear である。
-- code1, node2 は ノーマルな Code Gear であり、meta は Meta Code Gear である。
-
-```code
-__code code1 (struct Array* array) {
-    ...
-    goto code2(array);
-}
-
-__code meta(struct Context* context, enum Code next) {
-    goto (context->code[next])(context);
-}
+# paxosのアルゴリズム accept-accepted
+- (1)proposerは過半数のacceptorから返事が来たのなら、次の提案をaccepterに送る。これをacceptリクエストという。
+    - (a)もし、約束のみ帰って来ているのならば、任意の値vをprepareリクエストで送った提案に設定する。
+    - (b)もし、acceptされた提案が帰って来たら、その中で最大の提案番号v'をprepareリクエストで送った提案の値として設定する。
+- (2)acceptorはacceptリクエストが来た場合、Promiseした提案よりもacceptリクエストで提案された番号が低ければ、その提案を拒否する。それ以外の場合、acceptする。
+<div style="text-align: center;">
+　<img src="../paper/images/accept-accepted.pdf" alt="MetaGear" width="600">
+</div>
 
-__code code2(struct Array* array) {
-    ...
-}
-```
+# Paxos
+- Proof of Workと比較しメッセージ通信量と耐障害性のトレードオフになっている。
+- Paxosでコンセンサスを取る際、Proof of Workと比較して次のようなメリットがある。
+  - CPUにリソースを消費しない。
+  - Transactionの確定に時間がかからない。
+- Paxos自体がリーダー選出に向いているアルゴリズムである。そのため、リーダーを決定し、そのノードのブロックチェーンの一貫性のみをかんがえることができる。
 
-# Gears OS の構成
-- Gears OS は以下の要素で構成される。
-    - Context
-        - 使用されるCode/Data Gear のリストを持っておりTaskでもある。  
-    - TaskQueue
-        - Task のリストを扱う
-    - TaskManager
-        - Task の依存関係の解決、作成や停止を行います。
-    - Worker
-        - Task の実行を行う
+
 
 # Gears OS の構成図
 
@@ -176,6 +206,8 @@
 　<img src="./fig/gears_structure.pdf" alt="gears_structure" width="900">
 </div>
 
+
+
 # Context
 - Context とは使用される Code Gear と Data Gear を全て格納した Meta Data Gear である。
 - Gears OSは必要なCode Gear、Data Gearに参照したい場合、このContext を通す必要がある。
diff -r 2b71bf2c73c9 -r d1dff3305e0d slide/prosym.pdf.html
--- a/slide/prosym.pdf.html	Tue May 21 17:09:58 2019 +0900
+++ b/slide/prosym.pdf.html	Sat May 25 15:44:23 2019 +0900
@@ -75,7 +75,7 @@
 <div class='slide'>
   
 <!-- _S9SLIDE_ -->
-<h1 id="研究目的">研究目的</h1>
+<h2 id="研究目的">研究目的</h2>
 
 <ul>
   <li>コンピュータのデータの不整合は, 誤作動や複数人によるデータの同時書き込みによって発生し, 特に分散環境下で問題となる.</li>
@@ -95,11 +95,18 @@
 
 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h1 id="christie">Christie</h1>
+<h2 id="christie">Christie</h2>
 <ul>
   <li>Christieは当研究室で開発している分散フレームワークである.</li>
   <li>現在はjava上で開発されているが, GearsOSに組み込む予定があるため, 言語Continuation based Cへ書き換え可能な構成となっている. (?GeasOSの解説がより欲しい？)</li>
-  <li>言語CbCと近い概念としてCodeGear(以下CG), CodeGearManager(以下CGM), DataGear(以下DG), DataGearManager(以下DGM)という概念が存在する.</li>
+  <li>言語CbCと近い概念として以下の概念が存在する。
+    <ul>
+      <li>CodeGear(以下CG)</li>
+      <li>CodeGearManager(以下CGM)</li>
+      <li>DataGear(以下DG)</li>
+      <li>DataGearManager(以下DGM)</li>
+    </ul>
+  </li>
 </ul>
 
 
@@ -108,14 +115,17 @@
 
 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h1 id="christieの言語概念">Christieの言語概念</h1>
+<h2 id="christieの言語概念">Christieの言語概念</h2>
 <ul>
   <li>CGはスレッド, クラスに相当し, javaの継承を用いて記述する.</li>
   <li>DGは変数データに相当し, CG内でアノテーションを用いて変数データを取り出せる.</li>
   <li>CGMはノードであり, DG, CG, DGMを管理する.</li>
-  <li>DGMはDGを管理するものであり, putという操作により, 変数データ(DG)を格納できる.</li>
-  <li>DGMにはLocalDGMとRemoteDGMが存在する。LocalDGMは各ノード固有のデータベースである。RemoteDSMは他ノードのLocalDGMに対応するproxyであり、接続しているノードの数だけ存在する。</li>
-  <li>DGMのput操作を行う際にはLocalとRemoteのどちらかを選ぶ.Localであれば、LocalのCGMが管理するDGMに対しDGを格納し, Remoteの場合は接続したRemoteさきのCGMのDGMにDGを格納する.</li>
+  <li>DGMはDGを管理するものであり, putという操作により, 変数データ(DG)を格納できる.
+    <ul>
+      <li>DGMにはLocalDGMとRemoteDGMが存在する。LocalDGMは各ノード固有のデータベースである。RemoteDSMは他ノードのLocalDGMに対応するproxyであり、接続しているノードの数だけ存在する。</li>
+      <li>DGMのput操作を行う際にはLocalとRemoteのどちらかを選ぶ.Localであれば、LocalのCGMが管理するDGMに対しDGを格納し, Remoteの場合は接続したRemoteさきのCGMのDGMにDGを格納する.</li>
+    </ul>
+  </li>
 </ul>
 
 
@@ -124,7 +134,7 @@
 
 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h1 id="dgm">DGM</h1>
+<h2 id="dgm">DGM</h2>
 <ul>
   <li>RocalDGMを立ち上げるにはDataSegmentクラスが提供する、connectメソッドを用い、接続したいポートのipアドレスとport番号、そして任意のManager名を指定することで立ち上げる。</li>
   <li>立ち上げ後はManager名を指定してDataSegmentAPI用いてDSのやり取りを行うため、プログラマはManager名を意識することでLocalへの操作もRemoteへの操作も同様に扱える。</li>
@@ -136,14 +146,33 @@
 
 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h1 id="dgのアノテーション">DGのアノテーション</h1>
+<h2 id="dgのアノテーション">DGのアノテーション</h2>
 <ul>
   <li>DGを取り出す際にはCG内で宣言した変数データにアノテーションをつける。DGアノテーションには
-Take、Peek、TakeFrom、PeekFrom、の4つがある。</li>
-  <li>Take 先頭のDGを読み込み、そのDGを削除する。</li>
-  <li>Peek 先頭のDGを読み込むが、DGが消去されない。そのため特に操作をしない場合、同じデータを参照し続ける。</li>
-  <li>TakeFrom Takeと似ているが、Remote DGM nameをしているすることで、その接続先のDGM からTake操作をおこえる。</li>
-  <li>PeekFrom Peekと似ているが、 Remote DGM nameをしているすることで、その接続先のDGM からPeek操作をおこえる。</li>
+Take、Peek、TakeFrom、PeekFrom、の4つがある。
+    <ul>
+      <li>Take
+        <ul>
+          <li>先頭のDGを読み込み、そのDGを削除する。</li>
+        </ul>
+      </li>
+      <li>Peek
+        <ul>
+          <li>先頭のDGを読み込むが、DGが消去されない。そのため特に操作をしない場合、同じデータを参照し続ける。</li>
+        </ul>
+      </li>
+      <li>TakeFrom
+        <ul>
+          <li>Takeと似ているが、Remote DGM nameをしているすることで、その接続先のDGM からTake操作をおこえる。</li>
+        </ul>
+      </li>
+      <li>PeekFrom
+        <ul>
+          <li>Peekと似ているが、 Remote DGM nameをしているすることで、その接続先のDGM からPeek操作をおこえる。</li>
+        </ul>
+      </li>
+    </ul>
+  </li>
 </ul>
 
 
@@ -152,7 +181,7 @@
 
 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h1 id="christieのコード例">Christieのコード例</h1>
+<h2 id="christieのコード例">Christieのコード例</h2>
 <pre><code class="language-code">package christie.example.HelloWorld;
 
 import christie.codegear.CodeGearManager;
@@ -180,13 +209,12 @@
 
 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h1 id="annottation">Annottation</h1>
+<h2 id="annottation">Annottation</h2>
 <ul>
   <li>ChristieではInputDGの指定にはアノテーションを使う。</li>
   <li>アノテーションとはクラスやメソッド、パッケージに対して、付加情報を記述できるJavaのMeta Computationである。</li>
   <li>先頭に@をつけることで記述し、オリジナルのアノテーションを定義することもできるInput
 となる型の変するを直接宣言し、変数名としてkeyを記述する。その上にアノテーションでTakeもしくはPeekを指定する。
--
     <pre><code class="language-code">@Take
 public String name;
 </code></pre>
@@ -202,7 +230,7 @@
 
 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h1 id="topologymanager">TopologyManager</h1>
+<h2 id="topologymanager">TopologyManager</h2>
 <ul>
   <li>TopologyManagerとはTopologyを形成するために、参加を表明したノード、TopologyNodeに名前を与え、必要があればノード同士の配線を行うノードである。</li>
   <li>TopologyManagerのTopology形成方法として、静的Topologyと動的Topologyがある。</li>
@@ -215,7 +243,7 @@
 
 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h1 id="静的topology">静的Topology</h1>
+<h2 id="静的topology">静的Topology</h2>
 <ul>
   <li>静的Toopologyはdotファイルを与えることでノード関係を下の図のようにする。</li>
   <li>静的Topologyはdotファイルのノード数と同等のTopologyNodeがあって初めて、CodeGearが実行される。
@@ -238,7 +266,7 @@
 
 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h1 id="ブロックチェーンのトランザクション">ブロックチェーンのトランザクション</h1>
+<h2 id="ブロックチェーンのトランザクション">ブロックチェーンのトランザクション</h2>
 <ul>
   <li>ブロックチェーンはP2Pにてネットワーク間が動作している。つまり、ブロックチェーンにはサーバー、クライアントの区別がなく全てのノードが平等である。</li>
   <li>ブロックチェーンにおけるブロックは複数のトランザクションをまとめたものである。ブロックの構造は使用するコンセンサスにより変わるが基本的には、previous block hash, merkle root hash, timeが含まれるBlockHeaderとTransactionListにより構成される。</li>
@@ -250,7 +278,7 @@
 
 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h1 id="blockheader">BlockHeader</h1>
+<h2 id="blockheader">BlockHeader</h2>
 <ul>
   <li>BlockHeaderには、前のブロックをハッシュ化したもの、トランザクションをまとめたmarkle treeのrootのhash、そのブロックを生成したtimeとなっている。</li>
   <li>previous block hashは、前のブロックのパラメータを並べてhash化したものである。</li>
@@ -266,7 +294,7 @@
 
 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h1 id="blockの動作">Blockの動作</h1>
+<h2 id="blockの動作">Blockの動作</h2>
 <ul>
   <li>ブロックが生成された場合、知っているノードにそのブロックをブロードキャストする。通信量を抑えるためにブロックを送ったあと、ブロックをシリアライズして送信する場合もある。</li>
   <li>誤りがあればさらにそのノードがブロックをブロードキャストする。そしてTransaction PoolというTransactionをためておく場所から、そのブロックに含まれるTransactionを削除し、新しいブロックを生成する。</li>
@@ -278,14 +306,34 @@
 
 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h1 id="transaction">Transaction</h1>
+<h2 id="transaction">Transaction</h2>
 <ul>
   <li>トランザクションとはデータのやり取りを行なった記録の最小単位である。トランザクションの構造は次のとおりである。</li>
-  <li>TransactionHash トランザクションをハッシュ化したもの。</li>
-  <li>data データ</li>
-  <li>sendAddress 送り元のアドレス。</li>
-  <li>receiveAddress 送り先のアカウントのアドレス。</li>
-  <li>signature トランザクションの一部と秘密鍵をSHA256でハッシュ化したもの。ECDSAで署名している。</li>
+  <li>TransactionHash
+    <ul>
+      <li>トランザクションをハッシュ化したもの。</li>
+    </ul>
+  </li>
+  <li>data
+    <ul>
+      <li>データ</li>
+    </ul>
+  </li>
+  <li>sendAddress
+    <ul>
+      <li>送り元のアドレス。</li>
+    </ul>
+  </li>
+  <li>receiveAddress
+    <ul>
+      <li>送り先のアカウントのアドレス。</li>
+    </ul>
+  </li>
+  <li>signature
+    <ul>
+      <li>トランザクションの一部と秘密鍵をSHA256でハッシュ化したもの。ECDSAで署名している。</li>
+    </ul>
+  </li>
   <li>トランザクションはノード間で伝搬され、ノードごとに検証される。そして検証を終え、不正なトランザクションであればそれを破棄し、検証に通った場合はTransaction Poolに取り込まれ、また検証したノードからトランザクションがブロードキャストする。</li>
 </ul>
 
@@ -295,11 +343,47 @@
 
 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h1 id="data-gear">Data Gear</h1>
+<h2 id="コンセンサスアルゴリズム">コンセンサスアルゴリズム</h2>
 <ul>
-  <li>Data Gear は データの単位であり、int や文字列などの Primitive Type を持っている。</li>
-  <li>Code Gear は任意の数の Input Data Gear を参照して処理を行い、Output Data Gear を出力し処理を終える。</li>
-  <li>Code Gear は接続された Data Gear 以外には参照を行わない。</li>
+  <li>fork
+    <ul>
+      <li>ブロック生成後にブロードキャストを行うと、ブロック高の同じもしくは高いブロックチェーンにたどり着く状態があり、異なるブロックを持った二つのブロックチェーンのうちどちらかを破棄する必要がある。</li>
+    </ul>
+  </li>
+  <li>fork状態を解消するために用いられるのがコンセンサスアルゴリズムである。</li>
+  <li>ブロックチェーンはパブリックブロックチェーンとコンソーシアムブロックチェーンの場合によってコンセンサスアルゴリズムが変わる。
+    <ul>
+      <li>パブリックブロックチェーン
+        <ul>
+          <li>不特定たすのノードが参加するブロックチェーンを指す。</li>
+          <li>不特定多数のノード間、全体のノードの参加数が変わる状況でコンセンサスの変わるアルゴリズムでなければならない。</li>
+        </ul>
+      </li>
+      <li>コンソーシアムブロックチェーン
+        <ul>
+          <li>許可したノードのみが参加できるブロックチェーンである。</li>
+        </ul>
+      </li>
+    </ul>
+  </li>
+</ul>
+
+
+
+</div>
+
+<div class='slide'>
+  <!-- _S9SLIDE_ -->
+<h1 id="paxos">Paxos</h1>
+<ul>
+  <li>Paxosはノードの多数決によってコンセンサスをとるアルゴリズムである。</li>
+  <li>Paxosは以下のような問題があっても値を一意に決めることができる。
+    <ul>
+      <li>1,プロセス毎に処理の速度が違う。つまりメッセージの返信が遅い可能性がある。</li>
+      <li>2,通信にどれだけの時間がかかるかわからず、その途中でメッセージが失われる可能性がある。</li>
+      <li>3,プロセスは停止する可能性もある。</li>
+    </ul>
+  </li>
 </ul>
 
 
@@ -308,15 +392,77 @@
 
 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h1 id="gears-でのメタ計算">Gears でのメタ計算</h1>
+<h1 id="paxosの役割ノード">Paxosの役割ノード</h1>
 <ul>
-  <li>Gears OS ではメタ計算を Meta Code Gear、Meta Data Gear で表現する。</li>
-  <li>Meta Code Gear はノーマルレベルの Code Gear の直後に遷移され、メタ計算を実行する。</li>
-  <li>Meta Code Gear で OS の機能であるメモリ管理やスレッド管理を行う。</li>
+  <li>Paxosは3つの役割ノードがある。
+    <ul>
+      <li>proposer
+        <ul>
+          <li>値を提案するノード。</li>
+        </ul>
+      </li>
+      <li>accepter
+        <ul>
+          <li>値を決めるノード。</li>
+        </ul>
+      </li>
+      <li>lerner
+        <ul>
+          <li>accepterから値を集計し、過半数以上のaccepterが持っている値を決める。</li>
+        </ul>
+      </li>
+    </ul>
+  </li>
 </ul>
 
+
+
+</div>
+
+<div class='slide'>
+  <!-- _S9SLIDE_ -->
+<h1 id="paxosの役割定義">Paxosの役割定義</h1>
+<ul>
+  <li>提案
+    <ul>
+      <li>異なる提案ごとにユニークな提案番号と値からなる。提案番号とは、異なる提案を見分けるための識別子であり、単調増加である。</li>
+    </ul>
+  </li>
+  <li>値(提案)がacceptされる
+    <ul>
+      <li>accepterによって値(提案)が決まること。</li>
+    </ul>
+  </li>
+  <li>値(提案)が選択(chosen)される
+    <ul>
+      <li>過半数以上のacceptorによって、値がacceptされた場合、それを値(提案)が選択されたと言う。</li>
+    </ul>
+  </li>
+</ul>
+
+
+
+</div>
+
+<div class='slide'>
+  <!-- _S9SLIDE_ -->
+<h1 id="paxosのアルゴリズム">paxosのアルゴリズム</h1>
+<ul>
+  <li>paxosのアルゴリズムは2フューズあり、一つ目のフェーズprepare-promiseと二つ目のフェーズaccept-acceptedの二つに区分される。</li>
+</ul>
+
+
+
+</div>
+
+<div class='slide'>
+  <!-- _S9SLIDE_ -->
+<h1 id="paxosのアルゴリズム-prepare-promise">paxosのアルゴリズム prepare-promise</h1>
+<ul>
+  <li>(言葉での説明記入?)</li>
+</ul>
 <div style="text-align: center;">
-　<img src="./fig/meta.pdf" alt="MetaGear" width="600" />
+　<img src="../paper/images/prepare-promise.pdf" alt="MetaGear" width="600" />
 </div>
 
 
@@ -325,26 +471,19 @@
 
 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h1 id="gears-でのメタ計算の記述">Gears でのメタ計算の記述</h1>
-
+<h1 id="paxosのアルゴリズム-accept-accepted">paxosのアルゴリズム accept-accepted</h1>
 <ul>
-  <li>各 Code Gear の引数は Data Gear である。</li>
-  <li>code1, node2 は ノーマルな Code Gear であり、meta は Meta Code Gear である。</li>
+  <li>(1)proposerは過半数のacceptorから返事が来たのなら、次の提案をaccepterに送る。これをacceptリクエストという。
+    <ul>
+      <li>(a)もし、約束のみ帰って来ているのならば、任意の値vをprepareリクエストで送った提案に設定する。</li>
+      <li>(b)もし、acceptされた提案が帰って来たら、その中で最大の提案番号v’をprepareリクエストで送った提案の値として設定する。</li>
+    </ul>
+  </li>
+  <li>(2)acceptorはacceptリクエストが来た場合、Promiseした提案よりもacceptリクエストで提案された番号が低ければ、その提案を拒否する。それ以外の場合、acceptする。</li>
 </ul>
-
-<pre><code class="language-code">__code code1 (struct Array* array) {
-    ...
-    goto code2(array);
-}
-
-__code meta(struct Context* context, enum Code next) {
-    goto (context-&gt;code[next])(context);
-}
-
-__code code2(struct Array* array) {
-    ...
-}
-</code></pre>
+<div style="text-align: center;">
+　<img src="../paper/images/accept-accepted.pdf" alt="MetaGear" width="600" />
+</div>
 
 
 
@@ -352,32 +491,16 @@
 
 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h1 id="gears-os-の構成">Gears OS の構成</h1>
+<h1 id="paxos-1">Paxos</h1>
 <ul>
-  <li>Gears OS は以下の要素で構成される。
+  <li>Proof of Workと比較しメッセージ通信量と耐障害性のトレードオフになっている。</li>
+  <li>Paxosでコンセンサスを取る際、Proof of Workと比較して次のようなメリットがある。
     <ul>
-      <li>Context
-        <ul>
-          <li>使用されるCode/Data Gear のリストを持っておりTaskでもある。</li>
-        </ul>
-      </li>
-      <li>TaskQueue
-        <ul>
-          <li>Task のリストを扱う</li>
-        </ul>
-      </li>
-      <li>TaskManager
-        <ul>
-          <li>Task の依存関係の解決、作成や停止を行います。</li>
-        </ul>
-      </li>
-      <li>Worker
-        <ul>
-          <li>Task の実行を行う</li>
-        </ul>
-      </li>
+      <li>CPUにリソースを消費しない。</li>
+      <li>Transactionの確定に時間がかからない。</li>
     </ul>
   </li>
+  <li>Paxos自体がリーダー選出に向いているアルゴリズムである。そのため、リーダーを決定し、そのノードのブロックチェーンの一貫性のみをかんがえることができる。</li>
 </ul>