Mercurial > hg > Papers > 2019 > ikki-sigos

--- a/slide/prosym.html	Sat May 25 15:44:23 2019 +0900
+++ b/slide/prosym.html	Mon May 27 18:35:14 2019 +0900
@@ -390,7 +390,68 @@

 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h1 id="paxos">Paxos</h1>
+<h2 id="proof-of-work">Proof of Work</h2>
+<ul>
+  <li>Proof of Workは次のような問題が生じている場合にもコンセンサスを取ることができる。
+    <ul>
+      <li>プロセス毎の処理速度が違う。つまりメッセージの返信が遅い場合がある。</li>
+      <li>通信にどれだけの時間がかかるか分からず、その途中でメッセージが途切れる場合がある</li>
+      <li>プロセスは停止する可能性がある。また復旧する場合もある。</li>
+      <li>悪意ある情報を他のノードが送信する可能性がある。</li>
+    </ul>
+  </li>
+  <li>Proof of Workに必要なパラメーターは次のとおりである。
+    <ul>
+      <li>nonce
+        <ul>
+          <li>ブロックのパラメータに含まれる。</li>
+        </ul>
+      </li>
+      <li>dificulty
+        <ul>
+          <li>Proof of Workの難しさ、正確には一つのブロックを生成する時間の調整。</li>
+        </ul>
+      </li>
+    </ul>
+  </li>
+</ul>
+
+
+
+</div>
+
+<div class='slide'>
+  <!-- _S9SLIDE_ -->
+<h2 id="proof-of-workのブロック生成手順">Proof of Workのブロック生成手順</h2>
+<ul>
+  <li>1, ブロックとnonceを加えたものをハッシュ化する。この際、nonceによって、ブロックのハッシュは全く異なるものとなる。</li>
+  <li>2, ハッシュ化したブロックの先頭から数えた0ビットの数がdifficultyより多ければ、そのブロックにnonceを埋め込み、ブロックを作る。</li>
+  <li>3, 2の条件に当てはまらなければnonceに1を足して１からやり直す。</li>
+</ul>
+
+<div style="text-align: center;">
+　<img src="../paper/images/proof-of-work.pdf" alt="MetaGear" width="600" />
+</div>
+
+
+
+</div>
+
+<div class='slide'>
+  <!-- _S9SLIDE_ -->
+<h2 id="proof-of-workの欠点">Proof of workの欠点</h2>
+<ul>
+  <li>CPUのリソースを使用する</li>
+  <li>Transactionが確定するのに時間がかかる。</li>
+</ul>
+
+
+
+</div>
+
+<div class='slide'>
+  <!-- _S9SLIDE_ -->
+<h2 id="paxos">Paxos</h2>
 <ul>
   <li>Paxosはノードの多数決によってコンセンサスをとるアルゴリズムである。</li>
   <li>Paxosは以下のような問題があっても値を一意に決めることができる。
@@ -408,7 +469,7 @@

 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h1 id="paxosの役割ノード">Paxosの役割ノード</h1>
+<h2 id="paxosの役割ノード">Paxosの役割ノード</h2>
 <ul>
   <li>Paxosは3つの役割ノードがある。
     <ul>
@@ -437,7 +498,7 @@

 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h1 id="paxosの役割定義">Paxosの役割定義</h1>
+<h2 id="paxosの役割定義">Paxosの役割定義</h2>
 <ul>
   <li>提案
     <ul>
@@ -462,7 +523,7 @@

 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h1 id="paxosのアルゴリズム">paxosのアルゴリズム</h1>
+<h2 id="paxosのアルゴリズム">paxosのアルゴリズム</h2>
 <ul>
   <li>paxosのアルゴリズムは2フューズあり、一つ目のフェーズprepare-promiseと二つ目のフェーズaccept-acceptedの二つに区分される。</li>
 </ul>
@@ -473,7 +534,7 @@

 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h1 id="paxosのアルゴリズム-prepare-promise">paxosのアルゴリズム prepare-promise</h1>
+<h2 id="paxosのアルゴリズム-prepare-promise">paxosのアルゴリズム prepare-promise</h2>
 <ul>
   <li>(言葉での説明記入?)</li>
 </ul>
@@ -487,7 +548,7 @@

 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h1 id="paxosのアルゴリズム-accept-accepted">paxosのアルゴリズム accept-accepted</h1>
+<h2 id="paxosのアルゴリズム-accept-accepted">paxosのアルゴリズム accept-accepted</h2>
 <ul>
   <li>(1)proposerは過半数のacceptorから返事が来たのなら、次の提案をaccepterに送る。これをacceptリクエストという。
     <ul>
@@ -507,7 +568,7 @@

 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h1 id="paxos-1">Paxos</h1>
+<h2 id="paxosとproof-of-workの比較">PaxosとProof of Workの比較</h2>
 <ul>
   <li>Proof of Workと比較しメッセージ通信量と耐障害性のトレードオフになっている。</li>
   <li>Paxosでコンセンサスを取る際、Proof of Workと比較して次のようなメリットがある。
@@ -525,107 +586,11 @@

 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h1 id="gears-os-の構成図">Gears OS の構成図</h1>
-
-<div style="text-align: center;">
-　<img src="./fig/gears_structure.pdf" alt="gears_structure" width="900" />
-</div>
-
-
-
-</div>
-
-<div class='slide'>
-  <!-- _S9SLIDE_ -->
-<h1 id="context">Context</h1>
-<ul>
-  <li>Context とは使用される Code Gear と Data Gear を全て格納した Meta Data Gear である。</li>
-  <li>Gears OSは必要なCode Gear、Data Gearに参照したい場合、このContext を通す必要がある。</li>
-</ul>
-<div style="text-align: center;">
-　<img src="./fig/Gearef.pdf" alt="gearef" width="900" />
-</div>
-
-
-
-</div>
-
-<div class='slide'>
-  <!-- _S9SLIDE_ -->
-<h1 id="context-の定義">context の定義</h1>
-
-<pre><code class="language-contexr">/* context define */
-struct Context {
-    int codeNum; //実行可能な Code Gear の数
-    __code (**code) (struct Context*); //実行可能な code Gear のリスト
-    void* heapStart; //Data Gear の Allocate用のヒープ
-    void* heap;
-    long heapLimit;
-    int dataNum; //Data Gear の数
-    union Data **data; //Data Gear のリスト
-};
-</code></pre>
-
-<p>#Context</p>
+<h2 id="christieにおけるブロックチェーンの実装の利点">Christieにおけるブロックチェーンの実装の利点</h2>
 <ul>
-  <li>Code/Data Gear の名前は enum で定義される。</li>
-  <li>Code/Data Gear の名前とポインタの対応は enum を使って行われる。</li>
-</ul>
-
-<pre><code class="language-code">enum Code {
-    C_cg1,
-    C_cg2,
-};
-</code></pre>
-
-<pre><code class="language-data">enum Data {
-    D_dg1,
-    D_dg2,
-};
-</code></pre>
-
-
-
-</div>
-
-<div class='slide'>
-  <!-- _S9SLIDE_ -->
-<h1 id="data-gear-の定義">Data Gear の定義</h1>
-<ul>
-  <li>Data Gear は union と struxt を用いて定義される</li>
-  <li>これをもとに必要な Data Gear の allocate を行う</li>
-</ul>
-
-<pre><code class="language-data">union Data {
-    struct Time {
-        enum Code next;
-        double time;
-    } time;
-    struct LoopCounter {
-        int i;
-    } loopCounter;
-    ...
-};
-</code></pre>
-
-<!--
-# CbC による Gears OS 記述の問題点
-- Gears OS を CbC で実装する上でメタ計算の記述が煩雑であることがわかった。
-- 本研究ではこれらのメタ計算を自動生成することにより Gears OS を記述する上においてより良い構文をユーザーに提供することにした。
-- そのためのプロトタイプとして perl スクリプトを作成した。
--->
-
-
-
-</div>
-
-<div class='slide'>
-  <!-- _S9SLIDE_ -->
-<h1 id="interface">Interface</h1>
-<ul>
-  <li>Code Gear と Data Gear は Interface と呼ばれるまとまりとして記述される。</li>
-  <li>Interface は使用される Data Gear の定義と、それに対する Code Gear の集合である。</li>
-  <li>Interface の操作に対応する Code Gear の引数は Interface に定義されている Data Gear を通して行われる。</li>
+  <li>データの取り出しが簡単。ChristieはDataGearという単位でデータを保持する。そのためブロックやトランザクションはDataGearに包めばいいため、どう送るか考えなくて済む。</li>
+  <li>TopologyManagerでのテストが便利。dotファイルがあれば、TopologyManagerが任意の形でTopologyを作れる。そのため、ノードの配置については理想の環境を作れるため、理想のテスト環境を作ることができる。</li>
+  <li>機能ごとにファイルが実装できるため、見通しが良い。ChristieはCbCのgotoと同じように関数が終わるとsetupによって別の関数に移動する。そのため自然に機能ごとにファイルを作るため、見通しがよくなる。</li>
 </ul>


@@ -634,218 +599,13 @@

 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h1 id="interface-のコード">Interface のコード</h1>
-<pre><code class="language-interface">typedef struct Stack&lt;Type, Impl&gt;{
-        union Data* stack;
-        union Data* data;
-        union Data* data1;
-        __code whenEmpty(...);
-        __code clear(Impl* stack,__code next(...));
-        __code push(Impl* stack,Type* data, __code next(...));
-        __code pop(Impl* stack, __code next(Type* data, ...));
-        __code pop2(Impl* stack, __code next(Type* data, Type* data1, ...));
-        __code isEmpty(Impl* stack, __code next(...), __code whenEmpty(...));
-        __code get(Impl* stack, __code next(Type* data, ...));
-        __code get2(Impl* stack, __code next(Type* data, Type* data1, ...));
-        __code next(...);
-} Stack;
-</code></pre>
-
-
-
-</div>
-
-<div class='slide'>
-  <!-- _S9SLIDE_ -->
-<h1 id="interface-の実装例">Interface の実装例</h1>
-
-<pre><code class="language-impl">Stack* createSingleLinkedStack(struct Context* context) {
-    struct Stack* stack = new Stack();
-    struct SingleLinkedStack* singleLinkedStack = new SingleLinkedStack();
-    stack-&gt;stack = (union Data*)singleLinkedStack;
-    singleLinkedStack-&gt;top = NULL;
-    stack-&gt;push = C_pushSingleLinkedStack;
-    stack-&gt;pop  = C_popSingleLinkedStack;
-    stack-&gt;pop2  = C_pop2SingleLinkedStack;
-    stack-&gt;get  = C_getSingleLinkedStack;
-    stack-&gt;get2  = C_get2SingleLinkedStack;
-    stack-&gt;isEmpty = C_isEmptySingleLinkedStack;
-    stack-&gt;clear = C_clearSingleLinkedStack;
-    return stack;
-}
-</code></pre>
-
-
-
-</div>
-
-<div class='slide'>
-  <!-- _S9SLIDE_ -->
-<h1 id="interface-の実装例-1">Interface の実装例</h1>
-
-<pre><code class="language-impl">__code pushSingleLinkedStack(struct SingleLinkedStack* stack,
-                                union Data* data, __code next(...)) {
-    Element* element = new Element();
-    element-&gt;next = stack-&gt;top;
-    element-&gt;data = data;
-    stack-&gt;top = element;
-    goto next(...);
-}
-
-</code></pre>
-
-
-
-</div>
-
-<div class='slide'>
-  <!-- _S9SLIDE_ -->
-<h1 id="interface-の使用例">interface の使用例</h1>
-
+<h2 id="christieにおけるブロックチェーンの実装の欠点">Christieにおけるブロックチェーンの実装の欠点</h2>
 <ul>
-  <li>goto interface-&gt;code() と記述する。</li>
-</ul>
-
-<pre><code class="language-code">__code stackTest1(struct Stack* stack) {
-    Node* node = new Node();
-    node-&gt;color = Red;
-    goto stack-&gt;push(node, stackTest2);
-}
-
-</code></pre>
-
-<!--
-
-<div style="text-align: center;">
-　<img src="./images/multiComponent.pdf" alt="message" width="600">
-</div>
-
--->
-
-
-
-</div>
-
-<div class='slide'>
-  <!-- _S9SLIDE_ -->
-<h1 id="stub-code-gear">stub Code Gear</h1>
-
-<ul>
-  <li>Code Gear が必要とする Data Gear を取り出す際に Context を通す必要がある。</li>
-  <li>しかし、Meta Data Gear である Context をノーマルレベルの Code Gear から直接アクセスするのはよろしくない。</li>
-  <li>そこで Context から必要なデータを取り出して Code Gear に接続する、メタレベルの stub Code Gear を定義し、これを介して間接的に必要な Data Gear にアクセスする。</li>
+  <li>デバックが難しい。cgm.setupでCodeGearが実行されるが、keyの待ち合わせで止まり、どこのCGで止まっているのか分からないことが多かった。例えばputするkeyのスペルミスでコードの待ち合わせが起こり、CGが実行されず、エラーなども表示されずにwaitすることがある。その時に、どこで止まっているか特定するのが難しい。</li>
+  <li>Takefrom,PeekFromの使い方が難しい。TakeFrom,PeekFromは引数でDGMnameを指定する。しかし、DGMの名前を静的に与えるよりも、動的に与えたい場合が多かった。</li>
+  <li>Takeの待ち合わせでCGが実行されない。2つのCGで同じ変数をTakeしようとすると、setupされた時点で変数がロックされる。この時、片方のCGはDGがもう全て揃っているのに、全ての変数が揃っていないもう片方のCGに同名の変数がロックされ、実行されない場合がある。</li>
 </ul>

-
-
-</div>
-
-<div class='slide'>
-  <!-- _S9SLIDE_ -->
-<h1 id="stub-code-gear-の例">stub Code Gear の例</h1>
-<pre><code class="language-stub">__code clearSingleLinkedStack(struct Context *context,
-                    struct SingleLinkedStack* stack,enum Code next) {
-    stack-&gt;top = NULL;
-    goto meta(context, next);
-}
-
-__code clearSingleLinkedStack_stub(struct Context* context) {
-        SingleLinkedStack* stack =
-                (SingleLinkedStack*)GearImpl(context, Stack, stack);
-        enum Code next = Gearef(context, Stack)-&gt;next;
-        goto clearSingleLinkedStack(context, stack, next);
-}
-</code></pre>
-
-
-
-</div>
-
-<div class='slide'>
-  <!-- _S9SLIDE_ -->
-<h1 id="contextstub-code-gear-の自動生成">Context、stub Code Gear の自動生成</h1>
-<ul>
-  <li>Gears OS ではノーマルレベルの計算の他に Context や stub などのメタ計算を記述する必要がある。</li>
-  <li>現在の CbC で Gears OS を記述すると、このメタ計算の記述も行わなくてはならず、これには多くの労力を要する。</li>
-  <li>この記述を助けるために Context を生成する generate_context と stub Code Gear を生成する generate_stub を perl スクリプトで作成した。</li>
-</ul>
-
-
-
-</div>
-
-<div class='slide'>
-  <!-- _S9SLIDE_ -->
-<h1 id="stub-code-gear-の生成">stub Code Gear の生成</h1>
-<ul>
-  <li>stub Code Gear は Code Gear 間の継続に挟まれ、Code Gear が必要な Data Gear を Context から取り出す処理を行うものである。</li>
-  <li>stub Code Gear は Code Gear 毎に記述する必要があり、そのCode Gear の引数を見て取り出す Data Gear を選択する。</li>
-  <li>generate_stub は指定された cbc ファイルの __code で記述された Code Gear を取得。</li>
-  <li>Code Gear の引数と interface を照らし合わせ、Gearef または GearImpl を決定する。</li>
-  <li>cbc ファイルの Code Gear から、生成した stub Code Gear を加えたファイルを生成する。</li>
-</ul>
-
-
-
-</div>
-
-<div class='slide'>
-  <!-- _S9SLIDE_ -->
-<h1 id="生成された-stub-code-gear">生成された stub Code Gear</h1>
-
-<pre><code class="language-stub">__code clearSingleLinkedStack(struct Context *context,
-                    struct SingleLinkedStack* stack,enum Code next) {
-    stack-&gt;top = NULL;
-    goto meta(context, next);
-}
-
-__code clearSingleLinkedStack_stub(struct Context* context) {
-        SingleLinkedStack* stack =
-                (SingleLinkedStack*)GearImpl(context, Stack, stack);
-        enum Code next = Gearef(context, Stack)-&gt;next;
-        goto clearSingleLinkedStack(context, stack, next);
-}
-</code></pre>
-
-
-
-</div>
-
-<div class='slide'>
-  <!-- _S9SLIDE_ -->
-<h1 id="context-の生成">Context の生成</h1>
-
-<ul>
-  <li>generate_context は context.h から Data Gear、generate_stub から生成されたファイルから Code Gear を取得し、以下を生成する。
-    <ul>
-      <li>Code/Data Gear を enum で定義した enumCode.h、enumData.h</li>
-      <li>取得した Code/Data Gear から Context の生成を行う target-context</li>
-      <li>Context を生成する際の Data Gear の Allocation を行う dataGearInit.c</li>
-    </ul>
-  </li>
-</ul>
-
-<div style="text-align: center;">
-　<img src="./fig/generate_context3.pdf" alt="generate_context3" width="600" />
-</div>
-
-
-
-</div>
-
-<div class='slide'>
-  <!-- _S9SLIDE_ -->
-<h1 id="今後の課題">今後の課題</h1>
-<ul>
-  <li>本研究では CbC を用いた Code Gear と Data Gear を持つ Gears OS の記述を行なった。</li>
-  <li>また、Gears OS の記述に必要な Meta の生成を行う perl スクリプトの作成を行なった。</li>
-  <li>これにより Gears OS のコードの煩雑さは改善され、ユーザーは Context への接続を意識する必要がなくなった。</li>
-  <li>今後の課題は、今回 perl スクリプトによって Context や stub を含むファイルの生成を行なったが、LLVM/clang 上で実装しコンパイラから直接 CbC を実行できるようにすることを目的とする。</li>
-  <li>また、xv6 を Gears OS での書き換えや、継続ではスタックは積まないため、スタックトレースを使わない手法でのデバッグの考案などもある。</li>
-</ul>
-
-<p><a href="プロシン発表時間 セッション7 1/21 10:40 - 12:00"></a></p>
-
 </div>
--- a/slide/prosym.md	Sat May 25 15:44:23 2019 +0900
+++ b/slide/prosym.md	Mon May 27 18:35:14 2019 +0900
@@ -148,14 +148,39 @@
   - コンソーシアムブロックチェーン
     - 許可したノードのみが参加できるブロックチェーンである。

-# Paxos
+## Proof of Work
+- Proof of Workは次のような問題が生じている場合にもコンセンサスを取ることができる。
+  - プロセス毎の処理速度が違う。つまりメッセージの返信が遅い場合がある。
+  - 通信にどれだけの時間がかかるか分からず、その途中でメッセージが途切れる場合がある
+  - プロセスは停止する可能性がある。また復旧する場合もある。
+  - 悪意ある情報を他のノードが送信する可能性がある。
+- Proof of Workに必要なパラメーターは次のとおりである。
+  - nonce
+    - ブロックのパラメータに含まれる。
+  - dificulty
+    - Proof of Workの難しさ、正確には一つのブロックを生成する時間の調整。
+
+## Proof of Workのブロック生成手順
+- 1, ブロックとnonceを加えたものをハッシュ化する。この際、nonceによって、ブロックのハッシュは全く異なるものとなる。
+- 2, ハッシュ化したブロックの先頭から数えた0ビットの数がdifficultyより多ければ、そのブロックにnonceを埋め込み、ブロックを作る。
+- 3, 2の条件に当てはまらなければnonceに1を足して１からやり直す。
+
+<div style="text-align: center;">
+　<img src="../paper/images/proof-of-work.pdf" alt="MetaGear" width="600">
+</div>
+
+## Proof of workの欠点
+- CPUのリソースを使用する
+- Transactionが確定するのに時間がかかる。
+
+## Paxos
 - Paxosはノードの多数決によってコンセンサスをとるアルゴリズムである。
 - Paxosは以下のような問題があっても値を一意に決めることができる。
   - 1,プロセス毎に処理の速度が違う。つまりメッセージの返信が遅い可能性がある。
   - 2,通信にどれだけの時間がかかるかわからず、その途中でメッセージが失われる可能性がある。
   - 3,プロセスは停止する可能性もある。

-# Paxosの役割ノード
+## Paxosの役割ノード
 - Paxosは3つの役割ノードがある。
   - proposer
     - 値を提案するノード。
@@ -164,7 +189,7 @@
   - lerner
     - accepterから値を集計し、過半数以上のaccepterが持っている値を決める。

-# Paxosの役割定義
+## Paxosの役割定義
 - 提案
   - 異なる提案ごとにユニークな提案番号と値からなる。提案番号とは、異なる提案を見分けるための識別子であり、単調増加である。
 - 値(提案)がacceptされる
@@ -173,16 +198,16 @@
   - 過半数以上のacceptorによって、値がacceptされた場合、それを値(提案)が選択されたと言う。


-# paxosのアルゴリズム
+## paxosのアルゴリズム
 - paxosのアルゴリズムは2フューズあり、一つ目のフェーズprepare-promiseと二つ目のフェーズaccept-acceptedの二つに区分される。

-# paxosのアルゴリズム prepare-promise
+## paxosのアルゴリズム prepare-promise
 - (言葉での説明記入?)
 <div style="text-align: center;">
 　<img src="../paper/images/prepare-promise.pdf" alt="MetaGear" width="600">
 </div>

-# paxosのアルゴリズム accept-accepted
+## paxosのアルゴリズム accept-accepted
 - (1)proposerは過半数のacceptorから返事が来たのなら、次の提案をaccepterに送る。これをacceptリクエストという。
     - (a)もし、約束のみ帰って来ているのならば、任意の値vをprepareリクエストで送った提案に設定する。
     - (b)もし、acceptされた提案が帰って来たら、その中で最大の提案番号v'をprepareリクエストで送った提案の値として設定する。
@@ -191,234 +216,19 @@
 　<img src="../paper/images/accept-accepted.pdf" alt="MetaGear" width="600">
 </div>

-# Paxos
+## PaxosとProof of Workの比較
 - Proof of Workと比較しメッセージ通信量と耐障害性のトレードオフになっている。
 - Paxosでコンセンサスを取る際、Proof of Workと比較して次のようなメリットがある。
   - CPUにリソースを消費しない。
   - Transactionの確定に時間がかからない。
 - Paxos自体がリーダー選出に向いているアルゴリズムである。そのため、リーダーを決定し、そのノードのブロックチェーンの一貫性のみをかんがえることができる。

-
-
-# Gears OS の構成図
-
-<div style="text-align: center;">
-　<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 を通す必要がある。
-<div style="text-align: center;">
-　<img src="./fig/Gearef.pdf" alt="gearef" width="900">
-</div>
-
-# context の定義
-
-```contexr
-/* context define */
-struct Context {
-    int codeNum; //実行可能な Code Gear の数
-    __code (**code) (struct Context*); //実行可能な code Gear のリスト
-    void* heapStart; //Data Gear の Allocate用のヒープ
-    void* heap;
-    long heapLimit;
-    int dataNum; //Data Gear の数
-    union Data **data; //Data Gear のリスト
-};
-```
-
-#Context
-- Code/Data Gear の名前は enum で定義される。
-- Code/Data Gear の名前とポインタの対応は enum を使って行われる。
-
-```code
-enum Code {
-    C_cg1,
-    C_cg2,
-};
-```
-
-```data
-enum Data {
-    D_dg1,
-    D_dg2,
-};
-```
-
-# Data Gear の定義
-- Data Gear は union と struxt を用いて定義される
-- これをもとに必要な Data Gear の allocate を行う
-
-```data
-union Data {
-    struct Time {
-        enum Code next;
-        double time;
-    } time;
-    struct LoopCounter {
-        int i;
-    } loopCounter;
-    ...
-};
-```
-
-
-<!--
-# CbC による Gears OS 記述の問題点
-- Gears OS を CbC で実装する上でメタ計算の記述が煩雑であることがわかった。
-- 本研究ではこれらのメタ計算を自動生成することにより Gears OS を記述する上においてより良い構文をユーザーに提供することにした。
-- そのためのプロトタイプとして perl スクリプトを作成した。
--->
-
-# Interface
-- Code Gear と Data Gear は Interface と呼ばれるまとまりとして記述される。
-- Interface は使用される Data Gear の定義と、それに対する Code Gear の集合である。
-- Interface の操作に対応する Code Gear の引数は Interface に定義されている Data Gear を通して行われる。
-
-# Interface のコード
-```interface
-typedef struct Stack<Type, Impl>{
-        union Data* stack;
-        union Data* data;
-        union Data* data1;
-        __code whenEmpty(...);
-        __code clear(Impl* stack,__code next(...));
-        __code push(Impl* stack,Type* data, __code next(...));
-        __code pop(Impl* stack, __code next(Type* data, ...));
-        __code pop2(Impl* stack, __code next(Type* data, Type* data1, ...));
-        __code isEmpty(Impl* stack, __code next(...), __code whenEmpty(...));
-        __code get(Impl* stack, __code next(Type* data, ...));
-        __code get2(Impl* stack, __code next(Type* data, Type* data1, ...));
-        __code next(...);
-} Stack;
-```
-
-# Interface の実装例
+## Christieにおけるブロックチェーンの実装の利点
+- データの取り出しが簡単。ChristieはDataGearという単位でデータを保持する。そのためブロックやトランザクションはDataGearに包めばいいため、どう送るか考えなくて済む。
+- TopologyManagerでのテストが便利。dotファイルがあれば、TopologyManagerが任意の形でTopologyを作れる。そのため、ノードの配置については理想の環境を作れるため、理想のテスト環境を作ることができる。
+- 機能ごとにファイルが実装できるため、見通しが良い。ChristieはCbCのgotoと同じように関数が終わるとsetupによって別の関数に移動する。そのため自然に機能ごとにファイルを作るため、見通しがよくなる。

-```impl
-Stack* createSingleLinkedStack(struct Context* context) {
-    struct Stack* stack = new Stack();
-    struct SingleLinkedStack* singleLinkedStack = new SingleLinkedStack();
-    stack->stack = (union Data*)singleLinkedStack;
-    singleLinkedStack->top = NULL;
-    stack->push = C_pushSingleLinkedStack;
-    stack->pop  = C_popSingleLinkedStack;
-    stack->pop2  = C_pop2SingleLinkedStack;
-    stack->get  = C_getSingleLinkedStack;
-    stack->get2  = C_get2SingleLinkedStack;
-    stack->isEmpty = C_isEmptySingleLinkedStack;
-    stack->clear = C_clearSingleLinkedStack;
-    return stack;
-}
-```
-
-# Interface の実装例
-
-```impl
-__code pushSingleLinkedStack(struct SingleLinkedStack* stack,
-                                union Data* data, __code next(...)) {
-    Element* element = new Element();
-    element->next = stack->top;
-    element->data = data;
-    stack->top = element;
-    goto next(...);
-}
-
-```
-
-# interface の使用例
-
-- goto interface-\>code() と記述する。
-
-```code
-__code stackTest1(struct Stack* stack) {
-    Node* node = new Node();
-    node->color = Red;
-    goto stack->push(node, stackTest2);
-}
-
-```
-
-
-<!--
-
-<div style="text-align: center;">
-　<img src="./images/multiComponent.pdf" alt="message" width="600">
-</div>
-
--->
-
-# stub Code Gear
-
-- Code Gear が必要とする Data Gear を取り出す際に Context を通す必要がある。
-- しかし、Meta Data Gear である Context をノーマルレベルの Code Gear から直接アクセスするのはよろしくない。
-- そこで Context から必要なデータを取り出して Code Gear に接続する、メタレベルの stub Code Gear を定義し、これを介して間接的に必要な Data Gear にアクセスする。
-
-# stub Code Gear の例
-```stub
-__code clearSingleLinkedStack(struct Context *context,
-                    struct SingleLinkedStack* stack,enum Code next) {
-    stack->top = NULL;
-    goto meta(context, next);
-}
-
-__code clearSingleLinkedStack_stub(struct Context* context) {
-        SingleLinkedStack* stack =
-                (SingleLinkedStack*)GearImpl(context, Stack, stack);
-        enum Code next = Gearef(context, Stack)->next;
-        goto clearSingleLinkedStack(context, stack, next);
-}
-```
-
-# Context、stub Code Gear の自動生成
-- Gears OS ではノーマルレベルの計算の他に Context や stub などのメタ計算を記述する必要がある。
-- 現在の CbC で Gears OS を記述すると、このメタ計算の記述も行わなくてはならず、これには多くの労力を要する。
-- この記述を助けるために Context を生成する generate_context と stub Code Gear を生成する generate_stub を perl スクリプトで作成した。
-
-
-# stub Code Gear の生成
-- stub Code Gear は Code Gear 間の継続に挟まれ、Code Gear が必要な Data Gear を Context から取り出す処理を行うものである。
-- stub Code Gear は Code Gear 毎に記述する必要があり、そのCode Gear の引数を見て取り出す Data Gear を選択する。
-- generate_stub は指定された cbc ファイルの __code で記述された Code Gear を取得。
-- Code Gear の引数と interface を照らし合わせ、Gearef または GearImpl を決定する。
-- cbc ファイルの Code Gear から、生成した stub Code Gear を加えたファイルを生成する。
-
-# 生成された stub Code Gear
-
-```stub
-__code clearSingleLinkedStack(struct Context *context,
-                    struct SingleLinkedStack* stack,enum Code next) {
-    stack->top = NULL;
-    goto meta(context, next);
-}
-
-__code clearSingleLinkedStack_stub(struct Context* context) {
-        SingleLinkedStack* stack =
-                (SingleLinkedStack*)GearImpl(context, Stack, stack);
-        enum Code next = Gearef(context, Stack)->next;
-        goto clearSingleLinkedStack(context, stack, next);
-}
-```
-
-# Context の生成
-
-- generate_context は context.h から Data Gear、generate_stub から生成されたファイルから Code Gear を取得し、以下を生成する。
-    - Code/Data Gear を enum で定義した enumCode.h、enumData.h
-    - 取得した Code/Data Gear から Context の生成を行う target-context
-    - Context を生成する際の Data Gear の Allocation を行う dataGearInit.c
-
-<div style="text-align: center;">
-　<img src="./fig/generate_context3.pdf" alt="generate_context3" width="600">
-</div>
-
-# 今後の課題
-- 本研究では CbC を用いた Code Gear と Data Gear を持つ Gears OS の記述を行なった。
-- また、Gears OS の記述に必要な Meta の生成を行う perl スクリプトの作成を行なった。
-- これにより Gears OS のコードの煩雑さは改善され、ユーザーは Context への接続を意識する必要がなくなった。
-- 今後の課題は、今回 perl スクリプトによって Context や stub を含むファイルの生成を行なったが、LLVM/clang 上で実装しコンパイラから直接 CbC を実行できるようにすることを目的とする。
-- また、xv6 を Gears OS での書き換えや、継続ではスタックは積まないため、スタックトレースを使わない手法でのデバッグの考案などもある。
-
-[](プロシン発表時間 セッション7 1/21 10:40 - 12:00)
+## Christieにおけるブロックチェーンの実装の欠点
+- デバックが難しい。cgm.setupでCodeGearが実行されるが、keyの待ち合わせで止まり、どこのCGで止まっているのか分からないことが多かった。例えばputするkeyのスペルミスでコードの待ち合わせが起こり、CGが実行されず、エラーなども表示されずにwaitすることがある。その時に、どこで止まっているか特定するのが難しい。
+- Takefrom,PeekFromの使い方が難しい。TakeFrom,PeekFromは引数でDGMnameを指定する。しかし、DGMの名前を静的に与えるよりも、動的に与えたい場合が多かった。
+- Takeの待ち合わせでCGが実行されない。2つのCGで同じ変数をTakeしようとすると、setupされた時点で変数がロックされる。この時、片方のCGはDGがもう全て揃っているのに、全ての変数が揃っていないもう片方のCGに同名の変数がロックされ、実行されない場合がある。
--- a/slide/prosym.pdf.html	Sat May 25 15:44:23 2019 +0900
+++ b/slide/prosym.pdf.html	Mon May 27 18:35:14 2019 +0900
@@ -374,7 +374,68 @@

 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h1 id="paxos">Paxos</h1>
+<h2 id="proof-of-work">Proof of Work</h2>
+<ul>
+  <li>Proof of Workは次のような問題が生じている場合にもコンセンサスを取ることができる。
+    <ul>
+      <li>プロセス毎の処理速度が違う。つまりメッセージの返信が遅い場合がある。</li>
+      <li>通信にどれだけの時間がかかるか分からず、その途中でメッセージが途切れる場合がある</li>
+      <li>プロセスは停止する可能性がある。また復旧する場合もある。</li>
+      <li>悪意ある情報を他のノードが送信する可能性がある。</li>
+    </ul>
+  </li>
+  <li>Proof of Workに必要なパラメーターは次のとおりである。
+    <ul>
+      <li>nonce
+        <ul>
+          <li>ブロックのパラメータに含まれる。</li>
+        </ul>
+      </li>
+      <li>dificulty
+        <ul>
+          <li>Proof of Workの難しさ、正確には一つのブロックを生成する時間の調整。</li>
+        </ul>
+      </li>
+    </ul>
+  </li>
+</ul>
+
+
+
+</div>
+
+<div class='slide'>
+  <!-- _S9SLIDE_ -->
+<h2 id="proof-of-workのブロック生成手順">Proof of Workのブロック生成手順</h2>
+<ul>
+  <li>1, ブロックとnonceを加えたものをハッシュ化する。この際、nonceによって、ブロックのハッシュは全く異なるものとなる。</li>
+  <li>2, ハッシュ化したブロックの先頭から数えた0ビットの数がdifficultyより多ければ、そのブロックにnonceを埋め込み、ブロックを作る。</li>
+  <li>3, 2の条件に当てはまらなければnonceに1を足して１からやり直す。</li>
+</ul>
+
+<div style="text-align: center;">
+　<img src="../paper/images/proof-of-work.pdf" alt="MetaGear" width="600" />
+</div>
+
+
+
+</div>
+
+<div class='slide'>
+  <!-- _S9SLIDE_ -->
+<h2 id="proof-of-workの欠点">Proof of workの欠点</h2>
+<ul>
+  <li>CPUのリソースを使用する</li>
+  <li>Transactionが確定するのに時間がかかる。</li>
+</ul>
+
+
+
+</div>
+
+<div class='slide'>
+  <!-- _S9SLIDE_ -->
+<h2 id="paxos">Paxos</h2>
 <ul>
   <li>Paxosはノードの多数決によってコンセンサスをとるアルゴリズムである。</li>
   <li>Paxosは以下のような問題があっても値を一意に決めることができる。
@@ -392,7 +453,7 @@

 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h1 id="paxosの役割ノード">Paxosの役割ノード</h1>
+<h2 id="paxosの役割ノード">Paxosの役割ノード</h2>
 <ul>
   <li>Paxosは3つの役割ノードがある。
     <ul>
@@ -421,7 +482,7 @@

 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h1 id="paxosの役割定義">Paxosの役割定義</h1>
+<h2 id="paxosの役割定義">Paxosの役割定義</h2>
 <ul>
   <li>提案
     <ul>
@@ -446,7 +507,7 @@

 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h1 id="paxosのアルゴリズム">paxosのアルゴリズム</h1>
+<h2 id="paxosのアルゴリズム">paxosのアルゴリズム</h2>
 <ul>
   <li>paxosのアルゴリズムは2フューズあり、一つ目のフェーズprepare-promiseと二つ目のフェーズaccept-acceptedの二つに区分される。</li>
 </ul>
@@ -457,7 +518,7 @@

 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h1 id="paxosのアルゴリズム-prepare-promise">paxosのアルゴリズム prepare-promise</h1>
+<h2 id="paxosのアルゴリズム-prepare-promise">paxosのアルゴリズム prepare-promise</h2>
 <ul>
   <li>(言葉での説明記入?)</li>
 </ul>
@@ -471,7 +532,7 @@

 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h1 id="paxosのアルゴリズム-accept-accepted">paxosのアルゴリズム accept-accepted</h1>
+<h2 id="paxosのアルゴリズム-accept-accepted">paxosのアルゴリズム accept-accepted</h2>
 <ul>
   <li>(1)proposerは過半数のacceptorから返事が来たのなら、次の提案をaccepterに送る。これをacceptリクエストという。
     <ul>
@@ -491,7 +552,7 @@

 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h1 id="paxos-1">Paxos</h1>
+<h2 id="paxosとproof-of-workの比較">PaxosとProof of Workの比較</h2>
 <ul>
   <li>Proof of Workと比較しメッセージ通信量と耐障害性のトレードオフになっている。</li>
   <li>Paxosでコンセンサスを取る際、Proof of Workと比較して次のようなメリットがある。
@@ -509,107 +570,11 @@

 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h1 id="gears-os-の構成図">Gears OS の構成図</h1>
-
-<div style="text-align: center;">
-　<img src="./fig/gears_structure.pdf" alt="gears_structure" width="900" />
-</div>
-
-
-
-</div>
-
-<div class='slide'>
-  <!-- _S9SLIDE_ -->
-<h1 id="context">Context</h1>
-<ul>
-  <li>Context とは使用される Code Gear と Data Gear を全て格納した Meta Data Gear である。</li>
-  <li>Gears OSは必要なCode Gear、Data Gearに参照したい場合、このContext を通す必要がある。</li>
-</ul>
-<div style="text-align: center;">
-　<img src="./fig/Gearef.pdf" alt="gearef" width="900" />
-</div>
-
-
-
-</div>
-
-<div class='slide'>
-  <!-- _S9SLIDE_ -->
-<h1 id="context-の定義">context の定義</h1>
-
-<pre><code class="language-contexr">/* context define */
-struct Context {
-    int codeNum; //実行可能な Code Gear の数
-    __code (**code) (struct Context*); //実行可能な code Gear のリスト
-    void* heapStart; //Data Gear の Allocate用のヒープ
-    void* heap;
-    long heapLimit;
-    int dataNum; //Data Gear の数
-    union Data **data; //Data Gear のリスト
-};
-</code></pre>
-
-<p>#Context</p>
+<h2 id="christieにおけるブロックチェーンの実装の利点">Christieにおけるブロックチェーンの実装の利点</h2>
 <ul>
-  <li>Code/Data Gear の名前は enum で定義される。</li>
-  <li>Code/Data Gear の名前とポインタの対応は enum を使って行われる。</li>
-</ul>
-
-<pre><code class="language-code">enum Code {
-    C_cg1,
-    C_cg2,
-};
-</code></pre>
-
-<pre><code class="language-data">enum Data {
-    D_dg1,
-    D_dg2,
-};
-</code></pre>
-
-
-
-</div>
-
-<div class='slide'>
-  <!-- _S9SLIDE_ -->
-<h1 id="data-gear-の定義">Data Gear の定義</h1>
-<ul>
-  <li>Data Gear は union と struxt を用いて定義される</li>
-  <li>これをもとに必要な Data Gear の allocate を行う</li>
-</ul>
-
-<pre><code class="language-data">union Data {
-    struct Time {
-        enum Code next;
-        double time;
-    } time;
-    struct LoopCounter {
-        int i;
-    } loopCounter;
-    ...
-};
-</code></pre>
-
-<!--
-# CbC による Gears OS 記述の問題点
-- Gears OS を CbC で実装する上でメタ計算の記述が煩雑であることがわかった。
-- 本研究ではこれらのメタ計算を自動生成することにより Gears OS を記述する上においてより良い構文をユーザーに提供することにした。
-- そのためのプロトタイプとして perl スクリプトを作成した。
--->
-
-
-
-</div>
-
-<div class='slide'>
-  <!-- _S9SLIDE_ -->
-<h1 id="interface">Interface</h1>
-<ul>
-  <li>Code Gear と Data Gear は Interface と呼ばれるまとまりとして記述される。</li>
-  <li>Interface は使用される Data Gear の定義と、それに対する Code Gear の集合である。</li>
-  <li>Interface の操作に対応する Code Gear の引数は Interface に定義されている Data Gear を通して行われる。</li>
+  <li>データの取り出しが簡単。ChristieはDataGearという単位でデータを保持する。そのためブロックやトランザクションはDataGearに包めばいいため、どう送るか考えなくて済む。</li>
+  <li>TopologyManagerでのテストが便利。dotファイルがあれば、TopologyManagerが任意の形でTopologyを作れる。そのため、ノードの配置については理想の環境を作れるため、理想のテスト環境を作ることができる。</li>
+  <li>機能ごとにファイルが実装できるため、見通しが良い。ChristieはCbCのgotoと同じように関数が終わるとsetupによって別の関数に移動する。そのため自然に機能ごとにファイルを作るため、見通しがよくなる。</li>
 </ul>


@@ -618,218 +583,13 @@

 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h1 id="interface-のコード">Interface のコード</h1>
-<pre><code class="language-interface">typedef struct Stack&lt;Type, Impl&gt;{
-        union Data* stack;
-        union Data* data;
-        union Data* data1;
-        __code whenEmpty(...);
-        __code clear(Impl* stack,__code next(...));
-        __code push(Impl* stack,Type* data, __code next(...));
-        __code pop(Impl* stack, __code next(Type* data, ...));
-        __code pop2(Impl* stack, __code next(Type* data, Type* data1, ...));
-        __code isEmpty(Impl* stack, __code next(...), __code whenEmpty(...));
-        __code get(Impl* stack, __code next(Type* data, ...));
-        __code get2(Impl* stack, __code next(Type* data, Type* data1, ...));
-        __code next(...);
-} Stack;
-</code></pre>
-
-
-
-</div>
-
-<div class='slide'>
-  <!-- _S9SLIDE_ -->
-<h1 id="interface-の実装例">Interface の実装例</h1>
-
-<pre><code class="language-impl">Stack* createSingleLinkedStack(struct Context* context) {
-    struct Stack* stack = new Stack();
-    struct SingleLinkedStack* singleLinkedStack = new SingleLinkedStack();
-    stack-&gt;stack = (union Data*)singleLinkedStack;
-    singleLinkedStack-&gt;top = NULL;
-    stack-&gt;push = C_pushSingleLinkedStack;
-    stack-&gt;pop  = C_popSingleLinkedStack;
-    stack-&gt;pop2  = C_pop2SingleLinkedStack;
-    stack-&gt;get  = C_getSingleLinkedStack;
-    stack-&gt;get2  = C_get2SingleLinkedStack;
-    stack-&gt;isEmpty = C_isEmptySingleLinkedStack;
-    stack-&gt;clear = C_clearSingleLinkedStack;
-    return stack;
-}
-</code></pre>
-
-
-
-</div>
-
-<div class='slide'>
-  <!-- _S9SLIDE_ -->
-<h1 id="interface-の実装例-1">Interface の実装例</h1>
-
-<pre><code class="language-impl">__code pushSingleLinkedStack(struct SingleLinkedStack* stack,
-                                union Data* data, __code next(...)) {
-    Element* element = new Element();
-    element-&gt;next = stack-&gt;top;
-    element-&gt;data = data;
-    stack-&gt;top = element;
-    goto next(...);
-}
-
-</code></pre>
-
-
-
-</div>
-
-<div class='slide'>
-  <!-- _S9SLIDE_ -->
-<h1 id="interface-の使用例">interface の使用例</h1>
-
+<h2 id="christieにおけるブロックチェーンの実装の欠点">Christieにおけるブロックチェーンの実装の欠点</h2>
 <ul>
-  <li>goto interface-&gt;code() と記述する。</li>
-</ul>
-
-<pre><code class="language-code">__code stackTest1(struct Stack* stack) {
-    Node* node = new Node();
-    node-&gt;color = Red;
-    goto stack-&gt;push(node, stackTest2);
-}
-
-</code></pre>
-
-<!--
-
-<div style="text-align: center;">
-　<img src="./images/multiComponent.pdf" alt="message" width="600">
-</div>
-
--->
-
-
-
-</div>
-
-<div class='slide'>
-  <!-- _S9SLIDE_ -->
-<h1 id="stub-code-gear">stub Code Gear</h1>
-
-<ul>
-  <li>Code Gear が必要とする Data Gear を取り出す際に Context を通す必要がある。</li>
-  <li>しかし、Meta Data Gear である Context をノーマルレベルの Code Gear から直接アクセスするのはよろしくない。</li>
-  <li>そこで Context から必要なデータを取り出して Code Gear に接続する、メタレベルの stub Code Gear を定義し、これを介して間接的に必要な Data Gear にアクセスする。</li>
+  <li>デバックが難しい。cgm.setupでCodeGearが実行されるが、keyの待ち合わせで止まり、どこのCGで止まっているのか分からないことが多かった。例えばputするkeyのスペルミスでコードの待ち合わせが起こり、CGが実行されず、エラーなども表示されずにwaitすることがある。その時に、どこで止まっているか特定するのが難しい。</li>
+  <li>Takefrom,PeekFromの使い方が難しい。TakeFrom,PeekFromは引数でDGMnameを指定する。しかし、DGMの名前を静的に与えるよりも、動的に与えたい場合が多かった。</li>
+  <li>Takeの待ち合わせでCGが実行されない。2つのCGで同じ変数をTakeしようとすると、setupされた時点で変数がロックされる。この時、片方のCGはDGがもう全て揃っているのに、全ての変数が揃っていないもう片方のCGに同名の変数がロックされ、実行されない場合がある。</li>
 </ul>

-
-
-</div>
-
-<div class='slide'>
-  <!-- _S9SLIDE_ -->
-<h1 id="stub-code-gear-の例">stub Code Gear の例</h1>
-<pre><code class="language-stub">__code clearSingleLinkedStack(struct Context *context,
-                    struct SingleLinkedStack* stack,enum Code next) {
-    stack-&gt;top = NULL;
-    goto meta(context, next);
-}
-
-__code clearSingleLinkedStack_stub(struct Context* context) {
-        SingleLinkedStack* stack =
-                (SingleLinkedStack*)GearImpl(context, Stack, stack);
-        enum Code next = Gearef(context, Stack)-&gt;next;
-        goto clearSingleLinkedStack(context, stack, next);
-}
-</code></pre>
-
-
-
-</div>
-
-<div class='slide'>
-  <!-- _S9SLIDE_ -->
-<h1 id="contextstub-code-gear-の自動生成">Context、stub Code Gear の自動生成</h1>
-<ul>
-  <li>Gears OS ではノーマルレベルの計算の他に Context や stub などのメタ計算を記述する必要がある。</li>
-  <li>現在の CbC で Gears OS を記述すると、このメタ計算の記述も行わなくてはならず、これには多くの労力を要する。</li>
-  <li>この記述を助けるために Context を生成する generate_context と stub Code Gear を生成する generate_stub を perl スクリプトで作成した。</li>
-</ul>
-
-
-
-</div>
-
-<div class='slide'>
-  <!-- _S9SLIDE_ -->
-<h1 id="stub-code-gear-の生成">stub Code Gear の生成</h1>
-<ul>
-  <li>stub Code Gear は Code Gear 間の継続に挟まれ、Code Gear が必要な Data Gear を Context から取り出す処理を行うものである。</li>
-  <li>stub Code Gear は Code Gear 毎に記述する必要があり、そのCode Gear の引数を見て取り出す Data Gear を選択する。</li>
-  <li>generate_stub は指定された cbc ファイルの __code で記述された Code Gear を取得。</li>
-  <li>Code Gear の引数と interface を照らし合わせ、Gearef または GearImpl を決定する。</li>
-  <li>cbc ファイルの Code Gear から、生成した stub Code Gear を加えたファイルを生成する。</li>
-</ul>
-
-
-
-</div>
-
-<div class='slide'>
-  <!-- _S9SLIDE_ -->
-<h1 id="生成された-stub-code-gear">生成された stub Code Gear</h1>
-
-<pre><code class="language-stub">__code clearSingleLinkedStack(struct Context *context,
-                    struct SingleLinkedStack* stack,enum Code next) {
-    stack-&gt;top = NULL;
-    goto meta(context, next);
-}
-
-__code clearSingleLinkedStack_stub(struct Context* context) {
-        SingleLinkedStack* stack =
-                (SingleLinkedStack*)GearImpl(context, Stack, stack);
-        enum Code next = Gearef(context, Stack)-&gt;next;
-        goto clearSingleLinkedStack(context, stack, next);
-}
-</code></pre>
-
-
-
-</div>
-
-<div class='slide'>
-  <!-- _S9SLIDE_ -->
-<h1 id="context-の生成">Context の生成</h1>
-
-<ul>
-  <li>generate_context は context.h から Data Gear、generate_stub から生成されたファイルから Code Gear を取得し、以下を生成する。
-    <ul>
-      <li>Code/Data Gear を enum で定義した enumCode.h、enumData.h</li>
-      <li>取得した Code/Data Gear から Context の生成を行う target-context</li>
-      <li>Context を生成する際の Data Gear の Allocation を行う dataGearInit.c</li>
-    </ul>
-  </li>
-</ul>
-
-<div style="text-align: center;">
-　<img src="./fig/generate_context3.pdf" alt="generate_context3" width="600" />
-</div>
-
-
-
-</div>
-
-<div class='slide'>
-  <!-- _S9SLIDE_ -->
-<h1 id="今後の課題">今後の課題</h1>
-<ul>
-  <li>本研究では CbC を用いた Code Gear と Data Gear を持つ Gears OS の記述を行なった。</li>
-  <li>また、Gears OS の記述に必要な Meta の生成を行う perl スクリプトの作成を行なった。</li>
-  <li>これにより Gears OS のコードの煩雑さは改善され、ユーザーは Context への接続を意識する必要がなくなった。</li>
-  <li>今後の課題は、今回 perl スクリプトによって Context や stub を含むファイルの生成を行なったが、LLVM/clang 上で実装しコンパイラから直接 CbC を実行できるようにすることを目的とする。</li>
-  <li>また、xv6 を Gears OS での書き換えや、継続ではスタックは積まないため、スタックトレースを使わない手法でのデバッグの考案などもある。</li>
-</ul>
-
-<p><a href="プロシン発表時間 セッション7 1/21 10:40 - 12:00"></a></p>
-
 </div>