Posted on January 9, 2017 by antonylewis2015
*この記事はbitsonblocks.netより許可を頂き日本語に翻訳してご案内しております。
伝統的モデルでは、権限者が部下に指令を下すことでデータのコントロール権限を与えてデータを展開させる。権限者がデータを全てコントロールする。
分散型台帳モデルでは、事前に決められたルールを権限を持つ参加者によりデータが展開される。参加者のコンセンサス(合意)が重要である。
分散型台帳の文脈をたどってみると、多くのコメンテーターやコンサルタントがデータの共有コントロールとデータ共有を混同していることに私は気づきました。この違いは大変重要で、この簡単なミスが分散型台帳の重要な側面となります。
今回の投稿では3つのアイデアについてお話いたします。
1、データ共有 vs データのコントロール共有
データ共有なんてご存知ですよね。
- データ共有ができるのは、ブロックチェーンのグレイトなユースケース(外部で実現できる機能)ですよね。
- 多くの人がリアルタイムでアクセスする必要があるのでブロックチェーンを使うことになるでしょうね。
いやいや、違います。データ共有の方法なんて知っていますし、長年やってきています。目でデータを追う場合はGUI(グラフィカルユーザインタフェース:ビジュアル化されたアプリ)を使っていますし、他のシステムにアクセスする場合はAPIを使っています。データのアクセスはコントロールすることができますし、IDやパスワードの認証を使って権限の設定もしています。

コントロールの共有は新しいコンセプトです。
分散型台帳の技術はデータの共有ではありません。データのコントロールを共有することなのです。
特に、データを読み込んでのコントロールを意味しているのではなく、誰がデータを追加したり変更ができるのか、どのように権限を持つことができるのかです。リチャード・ブラウン氏が彼の秀逸なブログで以下のように記載しています。
2、データのコントロール パワー vs ルール
単体の独立体がデータコントロールの権力を持つ。
分散型台帳の出現以前は、データは単体の独立体にコントロールされていました。コンピューターをコントロールするものだけがデータ編集が可能で、ハードウェアとソフトウェアを駆使することでデータ保有者がデータの変更をできたわけです。ユーザーに対してはある特定の方法でしか使えないという組織間の法的な契約に基づいたものでもあります。
フェースブックはよい例です。画像をフェースブックのサーバーにアップロードし、どの友人に見せるべきか設定をし、フェースブックが私の意図していることを大まかにでも反映してくれることを期待します。究極的には、倫理観や法的な側面を無視すれば、フェースブックは自分のデータをコントロールできますし、一方的に追加、削除、修正などデータ展開をすることも可能です。でも、私にはどうすることもできません。もちろん、データをコントロールできているという感覚はあるかもしれませんが、やはり究極的にはフェースブックが個人のデータを持ってコントロールしています。
金融業界では、株式市場がよい例でしょう。買い手と売り手はトレードすることに合意し、取引所に対して記録を残すよう依頼をします。しかし、規制面における契約的なことや技術的なことに関しては取引所に任せるしかありません。技術的には、そのデータに関して好きなようにできるわけです。規則に基づいて、取引所は事実確認後に一方的にそのトレードの詳細を改ざんすることが可能です。これは約定取り消しルールと言われており、私達が思っている以上に頻繁に行われています。もちろん、大義名分はありますよ。
分散型台帳は、ルール(あるいは構成)に基づいてコントロールされている。
以上の話とは対照的に、分散型台帳は、新しい情報が有効か無効か、参加者がどのような対応を取るべきかといったルールのセットを指定しています。これらルールのセットは「構成」として考えられています。
時々、ブロックチェーンルール、ネットワークルール、台帳ルールと呼ばれますが、これらは新しいデータをどのように取り扱うかという事前に取り決められた技術的なルールだということです。参加者は、分散型台帳に名を連ねることに際し、ルールの「構成」に従います。
もちろん、参加者はルールに従うことについては自由であり、無効なデータを作ったり加えたりしますが、ネットワーク内の他の参加者がその無効なデータを受け入れることはルール上ありません。
例えばビットコインを例に取ります。一つ目のルールが、取引に対する一つのブロック内でデータ量は制限されています。もう一つは、ブロックの有効性を保つため指定されたパターンでハッシュ(暗号)を発行します。三つ目は、保有していないビットコインを使えないということです。
プライベートの分散型台帳で、最低三名の参加者が電子署名にて認証せずに取引を有効化することができないという決まりがあります。もしくは、ある資産において一人の特定の参加者がひとつひとつの取引に署名しないといけないといったルールもあります。(例えば、中央銀行が一回毎の現金での取引を承認する等)プライベートネットワークでは、恐らく相手方に対してSLA(サービス水準合意契約)のような契約を結ぶのに使われることもあります。
キーポイントは、分散型台帳のネットワーク内のデータの進展具合は技術レベルに応じてデータがどのように扱われるかというルールが存在します。分散型台帳の出現以前は、データは単体の独立体にコントロールされていました。そして、約束事は契約書やSLA(サービス水準合意契約)によってのみ結ばれたものでした。

伝統的モデルでは、権限者が部下に指令を下すことでデータのコントロール権限を与えてデータを展開させる。権限者がデータを全てコントロールする。
分散型台帳モデルでは、事前に決められたルールを権限を持つ参加者によりデータが展開される。参加者のコンセンサス(合意)が重要である。
3、参加者によるルールの強調
参加者は構成のコピーにより個人的にデータを正当化できる。
ブロックチェーンを含む分散型台帳は信頼できない参加者間で合意することが可能です。全員が同じルールに従うとは思われない、信用のできない状況下で、自分自身が受け取った情報を個人的に一つ一つ認証しなければならず、ルールに準拠しているかどうか確かめねばならないのです。有効だとみなせば、情報を受け入れて他者に伝達することもできますが、そうでなければ拒否することになります。
この仕組では、参加者はネットワークの構成を強要する委員会として振る舞います。データに何が起こったのか、委員会がコントロールするというイノベーションです。誰もデータを一方的に展開する上級の立場での力を持っていないことを意味します。
ビットコインのネットワークでは、参加者は自分自身を識別したり、一定レベルのサービスを提供したりする義務がなく、ある参加者が不履行を働いても法的手段はないのです。ビットコインは時々、無政府主義のネットワークと呼ばれます。ビットコインのネットワークでは、それぞれ参加者自身がビットコインの取引を全て有効化する必要があります。
プライベートの分散型台帳では、参加者は自分でもよく知っている取引先に対して、ビジネスへの参加前に契約を交わすことに同意したいかもしれません。参加前の契約で、もし一参加者が詐欺を働きネットワークを乱そうとした場合、法的手段に訴えることが可能です。たとえ契約を結んでいたとしても、他の取引先を100%信用しなくても、新しいデータを認証し個人的に有効とみなします。
新しい情報は、関連する参加者が合意した段階で有効とみなされる。
コンセンサス(合意)と呼ばれています。ネットワークがどのように設定されたかによりますが、すべての参加者は合意&同意台帳に組み込まれる前に新しいデータの有効性に同意しなければなりません。
ビットコインでは、約5000人の参加者がビットコイン・ブロックチェーンのフルコピーを保存しており、ブロックに新しい取引を入力し有効化しています。変更が行われた際に、一般的な快適さが感じられるかどうか、大多数がブロックチェーンの状態に同意する必要があります。もし、一人の参加者が同意しない場合は、他の全員が間違っているのか、その一人の参加者が正しくその構成を読めていないのか、何かを見逃しているのかのどれかです。このことは全体像からして一つの見方であり、他の全員が違った見方をしているということです。これをフォーク(分岐)と言います。
プライベートの分散型台帳では、二者間の取引や公証のような小さな参加者の団体においてコンセンサスを得るのに十分でした。常にすべての参加者から全体の台帳の同意を受ける必要はありませんし、ネットワーク全体の水準を保つというよりは一つの取引といった個人間でのデータ水準を守るのにコンセンサスを得ることで間に合いました。
しかし、個人参加者はユーザーを出し抜くこともあります。
もちろん、一人の個人参加者がデータの変更バージョンをユーザーに見せないようにすることはないでしょう。しかし、同時に編集していないバージョンを他の参加者に見せることはあるかもしれません。
これの意味することは、消費者は複数の参加者の台帳を見ることができるのであれば台帳を信用できるとみなすこともできますし、もしくは消費者は参加者になるという方法もあります。

結論
データの共有は既に解決されている問題であり、誤解されてしまう用例です。分散型台帳のコアであるイノベーションのデータコントロールの共有とは切り離して考えます。
分散型台帳では、データは委員会の参加者によりコントロールされており、これまでの単体規模の合意事項であったサービス水準合意を取るというよりは、技術的なルールである構成に従うように促しています。
分散型台帳は、単体規模というよりも複数でコントロールされたデータを展開するため、とても有用であると言えます。
データの統一性はどのように変わるのか | |||
---|---|---|---|
伝統的な単体規模のデータベース | パブリックのブロックチェーン | プライベートの分散型元帳 | |
誰がデータを変更するのか? | 単体で変更する | 個人がデータをマイニングし、ネットワークに提出することで新しい変更を提案する。 | 個人参加者が変更を提案し、関連するネットワークに対してその変更を提案する。 |
変更の制約は何か? | 変更の制約は契約に基づく。技術的な制約はない。 | ブロックサイズ等の技術的なルールに基づく。 | 技術的なルールに基づく。歩的な契約事項に基づく場合もある。 |
データの変更は誰が同意するべきか。 | 技術的な制約はない。 | 受諾と拒否はネットワークの参加者に委ねられる。 | 構成可能なデータにおいて、関連する参加者のみがネットワーク内にて認証 |
紛争メカニズム | 法的措置に従う | 法的措置はフレームワークとしては存在しない。 | 法的措置に訴えることは可能 |