Mercurial > hg > Papers > 2019 > ikki-sigos

comparison slide/prosym.html @ 24:a263efdfdab5 default tip

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
Revise last on 5/29
author ichikitakahiro <e165713@ie.u-ryukyu.ac.jp>
date Wed, 29 May 2019 23:22:31 +0900
parents 8a3b1147329e
children
comparison
equal deleted inserted replaced
23:8a3b1147329e 24:a263efdfdab5
324 <div class='slide'> 324 <div class='slide'>
325 <!-- _S9SLIDE_ --> 325 <!-- _S9SLIDE_ -->
326 <h2 id="ブロックチェーン">ブロックチェーン</h2> 326 <h2 id="ブロックチェーン">ブロックチェーン</h2>
327 <ul> 327 <ul>
328 <li>ネットワーク構築方式の一つである。データ情報をまとめたものをブロックと呼び、ブロックが連鎖的につながるっている形となる。</li> 328 <li>ネットワーク構築方式の一つである。データ情報をまとめたものをブロックと呼び、ブロックが連鎖的につながるっている形となる。</li>
329 <li>ノード一つにつき一つのブロックを持ち合わせるが、その間でデータの差異が生じた際に他のノードの総意によって選択し、差異の解消を行う。</li> 329 <li>ノードがそれぞれブロックを持つ、その間でデータの差異が生じた際に他のノードの総意によって選択し、差異の解消を行う。</li>
330 <li>ブロックチェーンはP2P(Peer to Peer)の形にてネットワーク間が動作している。つまり、ブロックチェーンにはサーバー、クライアントの区別がなく全てのノードが対等な関係にある。</li> 330 <li>ブロックチェーンはP2P(Peer to Peer)の形にてネットワーク間が動作している。つまり、ブロックチェーンにはサーバー、クライアントの区別がなく全てのノードが対等な関係にある。</li>
331 </ul> 331 </ul>
332 332
333 333
334 334
336 336
337 <div class='slide'> 337 <div class='slide'>
338 <!-- _S9SLIDE_ --> 338 <!-- _S9SLIDE_ -->
339 <h2 id="ブロックチェーンのトランザクション">ブロックチェーンのトランザクション</h2> 339 <h2 id="ブロックチェーンのトランザクション">ブロックチェーンのトランザクション</h2>
340 <ul> 340 <ul>
341 <li>ブロックチェーンにおけるブロックは複数のトランザクションをまとめたものである。ブロックは基本的に以下の要素によって構成される。 341 <li>ブロックは基本的に以下の要素によって構成される。
342 <ul> 342 <ul>
343 <li>BlockHeader 343 <li>BlockHeader
344 <ul> 344 <ul>
345 <li>previous block 345 <li>previous block
346 <ul> 346 <ul>
429 <!-- _S9SLIDE_ --> 429 <!-- _S9SLIDE_ -->
430 <h2 id="コンセンサスアルゴリズム">コンセンサスアルゴリズム</h2> 430 <h2 id="コンセンサスアルゴリズム">コンセンサスアルゴリズム</h2>
431 <ul> 431 <ul>
432 <li>fork 432 <li>fork
433 <ul> 433 <ul>
434 <li>ブロック生成後にブロードキャストを行うと、ブロック高の同じもしくは高いブロックチェーンにたどり着く状態があり、異なるブロックを持った二つのブロックチェーンのうちどちらかを破棄する必要がある。</li> 434 <li>ブロック生成を行う過程で、異なるブロックを持った二つのブロックチェーンが生成されてしまうことがある。そのうちどちらかを破棄する必要が生じ、この状態をforkと呼ぶ。</li>
435 </ul> 435 </ul>
436 </li> 436 </li>
437 <li>fork状態を解消するために用いられるのがコンセンサスアルゴリズムである。</li> 437 <li>fork状態を解消するために用いられるのがコンセンサスアルゴリズムである。</li>
438 <li>ブロックチェーンはパブリックブロックチェーンとコンソーシアムブロックチェーンの場合によってコンセンサスアルゴリズムが変わる。 438 <li>ブロックチェーンはパブリックブロックチェーンとコンソーシアムブロックチェーンの場合によってコンセンサスアルゴリズムが変わる。
439 <ul> 439 <ul>
450 </li> 450 </li>
451 </ul> 451 </ul>
452 </li> 452 </li>
453 </ul> 453 </ul>
454 454
455 455 <!--
456 456 ## Proof of Work
457 </div> 457 - Proof of Workは次のような問題が生じている場合にもコンセンサスを取ることができる。
458 458 - プロセス毎の処理速度が違う。つまりメッセージの返信が遅い場合がある。
459 <div class='slide'> 459 - 通信にどれだけの時間がかかるか分からず、その途中でメッセージが途切れる場合がある
460 <!-- _S9SLIDE_ --> 460 - プロセスは停止する可能性がある。また復旧する場合もある。
461 <h2 id="proof-of-work">Proof of Work</h2> 461 - 悪意ある情報を他のノードが送信する可能性がある。
462 <ul> 462 - Proof of Workに必要なパラメーターは次のとおりである。
463 <li>Proof of Workは次のような問題が生じている場合にもコンセンサスを取ることができる。 463 - nonce
464 <ul> 464 - ブロックのパラメータに含まれる。
465 <li>プロセス毎の処理速度が違う。つまりメッセージの返信が遅い場合がある。</li> 465 - dificulty
466 <li>通信にどれだけの時間がかかるか分からず、その途中でメッセージが途切れる場合がある</li> 466 - Proof of Workの難しさ、正確には一つのブロックを生成する時間の調整。
467 <li>プロセスは停止する可能性がある。また復旧する場合もある。</li> 467
468 <li>悪意ある情報を他のノードが送信する可能性がある。</li> 468 ## Proof of Workのブロック生成手順
469 </ul> 469 - 1, ブロックとnonceを加えたものをハッシュ化する。この際、nonceによって、ブロックのハッシュは全く異なるものとなる。
470 </li> 470 - 2, ハッシュ化したブロックの先頭から数えた0ビットの数がdifficultyより多ければ、そのブロックにnonceを埋め込み、ブロックを作る。
471 <li>Proof of Workに必要なパラメーターは次のとおりである。 471 - 3, 2の条件に当てはまらなければnonceに1を足して１からやり直す。
472 <ul>
473 <li>nonce
474 <ul>
475 <li>ブロックのパラメータに含まれる。</li>
476 </ul>
477 </li>
478 <li>dificulty
479 <ul>
480 <li>Proof of Workの難しさ、正確には一つのブロックを生成する時間の調整。</li>
481 </ul>
482 </li>
483 </ul>
484 </li>
485 </ul>
486
487
488
489 </div>
490
491 <div class='slide'>
492 <!-- _S9SLIDE_ -->
493 <h2 id="proof-of-workのブロック生成手順">Proof of Workのブロック生成手順</h2>
494 <ul>
495 <li>1, ブロックとnonceを加えたものをハッシュ化する。この際、nonceによって、ブロックのハッシュは全く異なるものとなる。</li>
496 <li>2, ハッシュ化したブロックの先頭から数えた0ビットの数がdifficultyより多ければ、そのブロックにnonceを埋め込み、ブロックを作る。</li>
497 <li>3, 2の条件に当てはまらなければnonceに1を足して１からやり直す。</li>
498 </ul>
499 472
500 <div style="text-align: center;"> 473 <div style="text-align: center;">
501 　<img src="../paper/images/proof-of-work.svg" alt="MetaGear" width="600" /> 474 　<img src="../paper/images/proof-of-work.svg" alt="MetaGear" width="600">
502 </div> 475 </div>
503 476
504 477 ## Proof of workの欠点
505 478 - CPUのリソースを使用する
506 </div> 479 - Transactionが確定するのに時間がかかる。
507 480
508 <div class='slide'> 481 -->
509 <!-- _S9SLIDE_ -->
510 <h2 id="proof-of-workの欠点">Proof of workの欠点</h2>
511 <ul>
512 <li>CPUのリソースを使用する</li>
513 <li>Transactionが確定するのに時間がかかる。</li>
514 </ul>
515 482
516 483
517 484
518 </div> 485 </div>
519 486
520 <div class='slide'> 487 <div class='slide'>
521 <!-- _S9SLIDE_ --> 488 <!-- _S9SLIDE_ -->
522 <h2 id="paxos">Paxos</h2> 489 <h2 id="paxos">Paxos</h2>
523 <ul> 490 <ul>
524 <li>Paxosはノードの多数決によってコンセンサスをとるアルゴリズムである。</li> 491 <li>Paxosはノードの多数決によってコンセンサスをとる分散合意アルゴリズムである。</li>
492 <li>Paxosは3つの役割ノードがある。
493 <ul>
494 <li>proposer
495 <ul>
496 <li>値を提案するノード。</li>
497 </ul>
498 </li>
499 <li>accepter
500 <ul>
501 <li>値を決めるノード。</li>
502 </ul>
503 </li>
504 <li>lerner
505 <ul>
506 <li>accepterから値を集計し、過半数以上のaccepterが持っている値を決める。</li>
507 </ul>
508 </li>
509 </ul>
510 </li>
511 </ul>
512
513
514
515 </div>
516
517 <div class='slide'>
518 <!-- _S9SLIDE_ -->
519 <h2 id="paxosの利点特徴">Paxosの利点、特徴</h2>
520 <ul>
525 <li>Paxosは以下のような問題があっても値を一意に決めることができる。 521 <li>Paxosは以下のような問題があっても値を一意に決めることができる。
526 <ul> 522 <ul>
527 <li>1,プロセス毎に処理の速度が違う。つまりメッセージの返信が遅い可能性がある。</li> 523 <li>1,プロセス毎に処理の速度が違う。つまりメッセージの返信が遅い可能性がある。</li>
528 <li>2,通信にどれだけの時間がかかるかわからず、その途中でメッセージが失われる可能性がある。</li> 524 <li>2,通信にどれだけの時間がかかるかわからず、その途中でメッセージが失われる可能性がある。</li>
529 <li>3,プロセスは停止する可能性もある。</li> 525 <li>3,プロセスは停止する可能性もある。</li>
530 </ul> 526 </ul>
531 </li> 527 </li>
532 </ul> 528 <li>従来のコンセンサスアルゴリズム(Proof of Workなど)と比較し、
533
534
535
536 </div>
537
538 <div class='slide'>
539 <!-- _S9SLIDE_ -->
540 <h2 id="paxosの役割ノード">Paxosの役割ノード</h2>
541 <ul>
542 <li>Paxosは3つの役割ノードがある。
543 <ul>
544 <li>proposer
545 <ul>
546 <li>値を提案するノード。</li>
547 </ul>
548 </li>
549 <li>accepter
550 <ul>
551 <li>値を決めるノード。</li>
552 </ul>
553 </li>
554 <li>lerner
555 <ul>
556 <li>accepterから値を集計し、過半数以上のaccepterが持っている値を決める。</li>
557 </ul>
558 </li>
559 </ul>
560 </li>
561 </ul>
562
563
564
565 </div>
566
567 <div class='slide'>
568 <!-- _S9SLIDE_ -->
569 <h2 id="paxosの役割定義">Paxosの役割定義</h2>
570 <ul>
571 <li>提案
572 <ul>
573 <li>異なる提案ごとにユニークな提案番号と値からなる。提案番号とは、異なる提案を見分けるための識別子であり、単調増加である。</li>
574 </ul>
575 </li>
576 <li>値(提案)がacceptされる
577 <ul>
578 <li>accepterによって値(提案)が決まること。</li>
579 </ul>
580 </li>
581 <li>値(提案)が選択(chosen)される
582 <ul>
583 <li>過半数以上のacceptorによって、値がacceptされた場合、それを値(提案)が選択されたと言う。</li>
584 </ul>
585 </li>
586 </ul>
587
588
589
590 </div>
591
592 <div class='slide'>
593 <!-- _S9SLIDE_ -->
594 <h2 id="paxosのアルゴリズム">paxosのアルゴリズム</h2>
595 <ul>
596 <li>paxosのアルゴリズムは2フューズあり、一つ目のフェーズprepare-promiseと二つ目のフェーズaccept-acceptedの二つに区分される。</li>
597 </ul>
598
599
600
601 </div>
602
603 <div class='slide'>
604 <!-- _S9SLIDE_ -->
605 <h2 id="paxosのアルゴリズム-prepare-promise">paxosのアルゴリズム prepare-promise</h2>
606 <ul>
607 <li>(言葉での説明記入?)</li>
608 </ul>
609 <div style="text-align: center;">
610 　<img src="../paper/images/prepare-promise.svg" alt="MetaGear" width="600" />
611 </div>
612
613
614
615 </div>
616
617 <div class='slide'>
618 <!-- _S9SLIDE_ -->
619 <h2 id="paxosのアルゴリズム-accept-accepted">paxosのアルゴリズム accept-accepted</h2>
620 <ul>
621 <li>(1)proposerは過半数のacceptorから返事が来たのなら、次の提案をaccepterに送る。これをacceptリクエストという。
622 <ul>
623 <li>(a)もし、約束のみ帰って来ているのならば、任意の値vをprepareリクエストで送った提案に設定する。</li>
624 <li>(b)もし、acceptされた提案が帰って来たら、その中で最大の提案番号v’をprepareリクエストで送った提案の値として設定する。</li>
625 </ul>
626 </li>
627 <li>(2)acceptorはacceptリクエストが来た場合、Promiseした提案よりもacceptリクエストで提案された番号が低ければ、その提案を拒否する。それ以外の場合、acceptする。</li>
628 </ul>
629 <div style="text-align: center;">
630 　<img src="../paper/images/accept-accepted.svg" alt="MetaGear" width="600" />
631 </div>
632
633
634
635 </div>
636
637 <div class='slide'>
638 <!-- _S9SLIDE_ -->
639 <h2 id="paxosとproof-of-workの比較">PaxosとProof of Workの比較</h2>
640 <ul>
641 <li>Proof of Workと比較しメッセージ通信量と耐障害性のトレードオフになっている。</li>
642 <li>Paxosでコンセンサスを取る際、Proof of Workと比較して次のようなメリットがある。
643 <ul> 529 <ul>
644 <li>CPUにリソースを消費しない。</li> 530 <li>CPUにリソースを消費しない。</li>
645 <li>Transactionの確定に時間がかからない。</li> 531 <li>Transactionの確定に時間がかからない。</li>
646 </ul> 532 </ul>
647 </li> 533 </li>
648 <li>Paxos自体がリーダー選出に向いているアルゴリズムである。そのため、リーダーを決定し、そのノードのブロックチェーンの一貫性のみをかんがえることができる。</li> 534 <li>アルゴリズムの形式上、リーダーのノードの一貫性のみを考えることで構成しやすい。</li>
535 </ul>
536
537
538
539 </div>
540
541 <div class='slide'>
542 <!-- _S9SLIDE_ -->
543 <h2 id="paxosの役割定義">Paxosの役割定義</h2>
544 <ul>
545 <li>提案
546 <ul>
547 <li>異なる提案ごとにユニークな提案番号と値からなる。提案番号とは、異なる提案を見分けるための識別子であり、単調増加である。</li>
548 </ul>
549 </li>
550 <li>値(提案)がacceptされる
551 <ul>
552 <li>accepterによって値(提案)が決まること。</li>
553 </ul>
554 </li>
555 <li>値(提案)が選択(chosen)される
556 <ul>
557 <li>過半数以上のacceptorによって、値がacceptされた場合、それを値(提案)が選択されたと言う。</li>
558 </ul>
559 </li>
560 </ul>
561
562
563
564 </div>
565
566 <div class='slide'>
567 <!-- _S9SLIDE_ -->
568 <h2 id="paxosのアルゴリズム">paxosのアルゴリズム</h2>
569 <ul>
570 <li>paxosのアルゴリズムは2フューズあり、一つ目のフェーズprepare-promiseと二つ目のフェーズaccept-acceptedの二つに区分される。</li>
571 <li>単純化としてproposerの数を2、accepterの数を3、lernerの数を1とする。</li>
572 </ul>
573 <div style="text-align: center;">
574 　<img src="../paper/images/paxos2.svg" alt="MetaGear" width="900" />
575 </div>
576
577
578
579 </div>
580
581 <div class='slide'>
582 <!-- _S9SLIDE_ -->
583 <h2 id="paxosのアルゴリズム-prepare-promise">paxosのアルゴリズム prepare-promise</h2>
584 <ul>
585 <li>paxosのアルゴリズムはprepare-promiseとaccepter-acceptedの２フェーズに分けられる。</li>
586 <li>(1)proposerは提案番号nを設定した提案を過半数以上のaccepterに送る。これをprepareリクエストと呼ぶ。</li>
587 <li>(2)それぞれのaccepterは各proposerからprepareリクエストが来たら
588 <ul>
589 <li>(a)もし、以前に送られたprepareリクエストの提案番号より、今送られて来たprepareリクエストの方が大きければ、それ以下の提案番号の提案を拒否するという約束を返す。この状態をpromiseしたという。</li>
590 <li>(b)もし値がすでにacceptされていたら、すでにacceptされているという報告を返す。</li>
591 </ul>
592 </li>
593 </ul>
594
595
596
597 </div>
598
599 <div class='slide'>
600 <!-- _S9SLIDE_ -->
601 <h2 id="paxosのアルゴリズム-accepter-accepted">paxosのアルゴリズム accepter-accepted</h2>
602 <ul>
603 <li>(1))proposerは過半数のacceptorから返事が来たのなら、次の提案をaccepterに送る。これをacceptリクエストという。
604 <ul>
605 <li>(a)もし、accepterがpromiseされた状態のままであるならaccepterは提案を(acceptリクエストと同様)を選択し、lernerへacceptされた提案を報告する。</li>
606 <li>(b)もし、acceptされた提案が帰って来たなら、その中で最大の提案番号を持つ提案をprepareリクエストで送った提案とする。</li>
607 </ul>
608 </li>
609 <li>(2)acceptorはacceptリクエストが来た場合、Promiseした提案よりもacceptリクエストで提案された番号が低ければ、その提案を拒否する。それ以外の場合、acceptする。</li>
649 </ul> 610 </ul>
650 611
651 612
652 613
653 </div> 614 </div>
656 <!-- _S9SLIDE_ --> 617 <!-- _S9SLIDE_ -->
657 <h2 id="christieにおけるブロックチェーンの実装の利点">Christieにおけるブロックチェーンの実装の利点</h2> 618 <h2 id="christieにおけるブロックチェーンの実装の利点">Christieにおけるブロックチェーンの実装の利点</h2>
658 <ul> 619 <ul>
659 <li>データの取り出しが簡単。ChristieはDataGearという単位でデータを保持する。そのためブロックやトランザクションはDataGearに包めばいいため、どう送るか考えなくて済む。</li> 620 <li>データの取り出しが簡単。ChristieはDataGearという単位でデータを保持する。そのためブロックやトランザクションはDataGearに包めばいいため、どう送るか考えなくて済む。</li>
660 <li>TopologyManagerでのテストが便利。dotファイルがあれば、TopologyManagerが任意の形でTopologyを作れる。そのため、ノードの配置については理想の環境を作れるため、理想のテスト環境を作ることができる。</li> 621 <li>TopologyManagerでのテストが便利。dotファイルがあれば、TopologyManagerが任意の形でTopologyを作れる。そのため、ノードの配置については理想の環境を作れるため、理想のテスト環境を作ることができる。</li>
661 <li>機能ごとにファイルが実装できるため、見通しが良い。ChristieはCbCのgotoと同じように関数が終わるとsetupによって別の関数に移動する。そのため自然に機能ごとにファイルを作るため、見通しがよくなる。</li> 622 <li>機能ごとにファイルが実装できるため、見通しが良い。Christieは関数が終わるとsetupによって別の関数に移動するため分かりやすい実装が行える。</li>
662 </ul> 623 </ul>
663 624
664 625
665 626
666 </div> 627 </div>
667 628
668 <div class='slide'> 629 <div class='slide'>
669 <!-- _S9SLIDE_ --> 630 <!-- _S9SLIDE_ -->
670 <h2 id="christieにおけるブロックチェーンの実装の欠点">Christieにおけるブロックチェーンの実装の欠点</h2> 631 <h2 id="christieにおけるブロックチェーンの実装の欠点">Christieにおけるブロックチェーンの実装の欠点</h2>
671 <ul> 632 <ul>
672 <li>デバックが難しい。cgm.setupでCodeGearが実行されるが、keyの待ち合わせで止まり、どこのCGで止まっているのか分からないことが多かった。例えばputするkeyのスペルミスでコードの待ち合わせが起こり、CGが実行されず、エラーなども表示されずにwaitすることがある。その時に、どこで止まっているか特定するのが難しい。</li> 633 <li>デバックが難しい。cgm.setupでCodeGearが実行されるが、keyの待ち合わせで止まり、どこのCGで止まっているのか判断できなくなりやすい。例として、putするkeyのスペルミスでコードの待ち合わせが起こり、CGが実行されず、エラーなども表示されずにwaitすることがあり、誤っている部分が見つけづらい。</li>
673 <li>Takefrom,PeekFromの使い方が難しい。TakeFrom,PeekFromは引数でDGMnameを指定する。しかし、DGMの名前を静的に与えるよりも、動的に与えたい場合が多かった。</li>
674 <li>Takeの待ち合わせでCGが実行されない。2つのCGで同じ変数をTakeしようとすると、setupされた時点で変数がロックされる。この時、片方のCGはDGがもう全て揃っているのに、全ての変数が揃っていないもう片方のCGに同名の変数がロックされ、実行されない場合がある。</li>
675 </ul> 634 </ul>
676 635
677 <!-- 636 <!--
637 - Takeの待ち合わせでCGが実行されない。2つのCGで同じ変数をTakeしようとすると、setupされた時点で変数がロックされる。この時、片方のCGはDGがもう全て揃っているのに、全ての変数が揃っていないもう片方のCGに同名の変数がロックされ、実行されない場合がある。
678 (ロックはおかしい) 638 (ロックはおかしい)
639 - Takefrom,PeekFromの使い方が難しい。TakeFrom,PeekFromは引数でDGMnameを指定する。しかし、DGMの名前を静的に与えるよりも、動的に与えたい場合が多かった。
679 --> 640 -->
680 641
681 642
682 643
683 </div> 644 </div>
741 702
742 </div> 703 </div>
743 704
744 <div class='slide'> 705 <div class='slide'>
745 <!-- _S9SLIDE_ --> 706 <!-- _S9SLIDE_ -->
746 <h2 id="実際にpaxosを動かした際の解説">実際にPaxosを動かした際の解説</h2>
747 <ul>
748 <li>単純化としてproposerの数えを2、accepterの数を3、lernerの数を1とする。</li>
749 </ul>
750 <div style="text-align: center;">
751 　<img src="../paper/images/paxos1.svg" alt="MetaGear" width="900" />
752 </div>
753
754
755
756 </div>
757
758 <div class='slide'>
759 <!-- _S9SLIDE_ -->
760 <h2 id="まとめ">まとめ</h2> 707 <h2 id="まとめ">まとめ</h2>
761 <ul> 708 <ul>
762 <li>Paxosの動作は確認できた。トランザクションの速度がノード数にどのように影響されるか調査する必要がある。</li> 709 <li>Paxosの動作は確認できた。トランザクションの速度がノード数にどのように影響されるか調査する必要がある。</li>
763 <li>ChristieのTopology Managerは実験するノードの設定を行う集中制度ノードであり、ブロックチェーンとの相性は良くないが、分散ファイルシステムなどの用途の場合、このような手法の方がノードの管理が可能な利点がある。</li> 710 <li>ChristieのTopology Managerは実験するノードの設定を行う集中制度ノードであり、ブロックチェーンとの相性は良くないが、分散ファイルシステムなどの用途の場合、このような手法の方がノードの管理が可能な利点がある。</li>
764 <li>現在、ChristieではBlock,Transaction,Hashの生成、署名、Proof of Workのためのクラスは作られている。しかし、Transactionに置いてまだファイルのデータを入れる機能がない。</li> 711 <li>現在、ChristieではBlock,Transaction,Hashの生成、署名、Proof of Workのためのクラスは作られている。しかし、Transactionに置いてまだファイルのデータを入れる機能がない。</li>