ブロックチェーン批判者が要点を逃している理由
そしてそれは続く。 から 人気の記事 〜へ 軽蔑的なツイート 〜へ 将来についての予測、世界とその母親は、以前にプライベートブロックチェーンにトマトを投げるように並んでいます 彼らが何であるかを理解することさえ.
プライベートブロックチェーンが単なる共有データベースであると言うことは、HTMLとHTTPが「単なる」分散ハイパーテキストであると言うようなものです。 XNUMXつの点で間違っています。 まず、セマンティックのXNUMXつです。プライベートブロックチェーンは、 可能 ペンなどの共有データベースは書き込みを可能にし、HTML / HTTPは分散ハイパーテキストを可能にします。 ビットコインブロックチェーンとその主要なアプリケーションは、一方が他方なしでは存在できないため、意味のある分離はできません。 しかし、この同等性はプライベートブロックチェーンにはまったく適用されません。
XNUMXつ目の間違いは、「公正」という言葉の使用です。 ただ？ HTMLとHTTPでした ただ 分散ハイパーテキストを行う方法？ ハイパーテキストは 数十年前に発明された、それでこれらのテクノロジーはコンピュータの歴史の中で小さな脚注ですか？ ああしかし、彼らが彼らの場所を獲得した方法を数えましょう：（a）簡単な マークアップ言語 素人なら誰でも学ぶことができる、（b）a 階層型アドレス指定スキーム TCP / IPと場所の概念モデルの両方で機能します。（c）a シンプルなプロトコル 状態のないコンテンツの検索、および（d）両方 クライアント および すべてを生き生きとさせたソフトウェア。 ニュートンはただの科学者であり、ドストエフスキーはただの作家だったとも言えるでしょう。
だから、これを完全に明確にしましょう：はい、プライベートブロックチェーンはデータベースを共有するための単なる方法です。 しかし、それらは新しいタイプの共有データベースを可能にし、金融の世界とそれ以降に大きな影響を与えます。 そして、あなたが読み進んでよければ、その理由を正確に説明します。
データベースとは？
データベースは、テーブルに編成された構造化情報のリポジトリです。 これは、XNUMXつ以上のExcelスプレッドシートのコレクションと考えることができ、オプションで相互にリンクできます。 各テーブルには、特定のタイプのエンティティのセットに関する情報が含まれ、行ごとにXNUMXつのエンティティがあります。 各テーブルには、これらのエンティティのさまざまな側面を説明するXNUMXつ以上の列もあります。 たとえば、WidgetCoの社内スタッフディレクトリのテーブルには、従業員ID、名、姓、部門、社内電話番号、部屋番号の列が含まれる場合があります。
データベースがスプレッドシートを超える重要な方法のXNUMXつは、データベースに格納されているデータに関するルールが含まれていることです。 これらのルールは、情報が正常であり、組織全体の利益のために一貫していることを保証するのに役立ちます。 今日の 最も人気のあるデータベース、ルールにはいくつかの一般的な形式があります。
- データベーススキーマ 各列で許可される情報の種類を定義します。 たとえば、電話番号は4桁である必要があり、空白のままにすることはできません（「null」）。
- 一意のキー これは、特定の列（従業員IDなど）がすべての行で異なる値を持つ必要があることを示しています。
- チェック制約 各行の列値間の関係を強制します。 たとえば、部門が「調達」の場合、部屋番号は3または4で始まる必要があります。
- 外部キー テーブル間の関係を強制します。 たとえば、データベースに給与計算に使用される別のテーブルが含まれている場合、給与計算テーブルのすべての従業員IDがスタッフディレクトリにも存在する必要があるというルールが存在する場合があります。
トランザクションとは、全体として承認または拒否されるデータベースへの変更のコレクションです。 トランザクションがデータベースを変更するたびに、ソフトウェアはデータベースのルールが確実に守られるようにします。 トランザクションのいずれかの部分がこれらのルールのいずれかに違反している場合、トランザクション全体が対応するエラーで拒否されます。
リストできる他の難解なルールタイプがありますが、それらにはすべてXNUMXつの共通点があります。 彼らは質問に答えます： データベースは有効な状態ですか？ つまり、データベースのコンテンツに対する制約として機能します ある時点で表示した場合。 そして、これは単一の組織内にあるデータベースに対してはうまく機能します。 制約の主な仕事はプログラマーのエラーを防ぐことです。 WidgetCoの内部アプリケーションの3つがXNUMX桁の電話番号をディレクトリに挿入しようとした場合、これは悪意によるものではなく、開発者の考えやコードのバグによるものです。 データベースがこれらのミスをキャッチする機能は間違いなく便利であり、組織内に伝播する悪い情報を防ぐのに役立ちますが、 それは信頼の問題を解決しません。 （制約は、アプリケーションロジックの簡素化にも役立ちます。たとえば、 外部キーのカスケード or 重複句、しかし、これらはまだ開発者を助けるための単なる方法です。）
データベース共有
次に、WidgetCoの内部スタッフディレクトリがどのように外部の世界と共有されるかを考えてみましょう。 多くの場合、問題はありません。 共有読み取り アクセス。 ディレクトリをテキストファイルにエクスポートし、顧客やサプライヤに電子メールで送信できます。 インターネットと同じように投稿できます この1。 外部コードによる検索を可能にするAPIを与えることもできます。 共有読み取りは、誰が何を参照できるかを決定する問題である、技術的な問題です。
しかし、私たちが考えるとき、物事は粘り強くなります 共有書き込み。 WidgetCoが外部エンティティに 修正する そのデータベース？ おそらく、電話はPhoneCoに置き換えられています。PhoneCoは、スタッフディレクトリの電話番号を更新します。 この場合、WidgetCoはPhoneCoが使用する新しい「アカウント」を作成します。 WidgetCoの内部使用のためのアカウントとは異なり、PhoneCoのアカウントは電話番号列の変更のみが許可されており、行を追加または削除することはできません。 PhoneCoのすべてのトランザクションはWidgetCoのデータベースシステムによって処理され、XNUMX種類の制限が適用されます。
- すべてのデータベースユーザーに適用されるグローバルルール。 たとえば、電話会社は番号を3桁のみに変更することはできず、他の誰も変更することはできません。
- PhoneCoが実行できることを制限するアカウントごとのルール。この場合、既存の行の電話番号列のみを変更します。
ここまでは順調ですね。 共有書き込みデータベースがあります。 WidgetCoがデータベースを担当し、電話会社がWidgetCoの優雅さによりアクセスできるため、この機能が動作します。 PhoneCoがランダムに電話番号の設定を開始した場合、WidgetCoはアクセスをシャットダウンし、契約を終了し、古いデータの一部をバックアップから復元できます。 そして、WidgetCoが誤動作し始めた場合、たとえばPhoneCoによって入力された新しい電話番号を逆にすることによって、それは完全に無意味です。 WidgetCo自体に害を及ぼすだけです。 電話会社はWidgetCoを奇妙な顧客であると考えていますが、時間どおりに支払いを済ませていれば、特に気にすることはありません。
しかし、XNUMXつ以上のパーティが（a）どのパーティも制御できない、（b）どのパーティも書き込めない、（c）全員が信頼できるデータベースを共有したい場合にどうなるかを見てみましょう。 さらに悪いことに、これらの当事者は異なるインセンティブを持ち、お互いを信頼せず、激しい競争相手である可能性があるとしましょう。 この場合、解決策は常に同じです。 信頼できる仲介者を紹介する。 この仲介者は、データベースを集中管理し、すべての関係者にアカウントを提供し、既知の一連のルールに従ってすべての操作が許可されるようにします。 多くの場合、特に財務上の場合は、すべての当事者がデータの独自のコピーを保持しているため、全員が多くの時間を費やしてそれを確認しています 彼らのデータベースは同意する.
すべてがかなり面倒で面倒です。 しかし、私たちが話しているなら 信頼が限られている環境での共有書き込みデータベース、現在、代替手段はありません。 これが、金融取引が行われる主な理由のXNUMXつです。 中央清算所、使用する理由 Googleカレンダー 小さなワークグループでさえ、なぜクラウドソーシングの不思議なのか Wikipedia 支出 何百万ドル ホスティングに。 ウェブのユーザーインターフェースとしても クライアント側に移動します、一元化されたサーバーは、これらのインターフェースが依存するデータを保存し続けます。
実際の共有書き込み
データベースの共有を許可したいとしましょう。 書き込みの意味で、中央当局なし。 たとえば、いくつかの競合する企業は、相互の顧客の利益のために共同スタッフディレクトリを維持したいと考えています。 実際にはどのように見えるでしょうか？ まあ、それは多くのものが必要になるでしょう：
- トランザクションを任意のパーティで作成し、接続されているすべてのノードに迅速に伝播できるようにする堅牢なピアツーピアネットワーク。
- トランザクション間の競合を識別し、それらを自動的に解決する方法。
- すべてのピアがデータベースの同一のコピーに収束することを保証する同期テクノロジー。
- さまざまな情報をさまざまな参加者に属するものとしてタグ付けし、中央の権限なしにこの形式のデータ所有権を強制する方法。
- たとえば、XNUMXつの会社が架空のエントリでディレクトリを膨らませるのを防ぐなど、許可される操作の制限を表すためのパラダイム。
ふew。 これはすぐに難しいリストであり、今日の既成のデータベースではサポートされていません。 電流 ピアツーピア複製テクノロジー 不器用で、紛争解決へのアプローチが複雑です。 サポートしているデータベース 行ベースのセキュリティ それを執行するために依然として中央当局が必要です。 また、一意のキーやチェック制約などの標準的なデータベースレベルの制限では、悪意のある変更からデータベースを保護することはできません。 一番下の行はこれです：
共有書き込みデータベースが機能するためには、たくさんの新しいものが必要です。たまたま、ブロックチェーンがそれらを提供するのは偶然です。
詳細についてはあまり触れません の ブロックチェーンはこれらのことを行います それの多くを以前にカバーしました。 いくつかの重要な要素は定期的に含まれています ピアツーピア テクニック、グループ化 ブロックへのトランザクション、 一方通行 暗号化ハッシュ関数、マルチパーティ コンセンサスアルゴリズム、配布済み マルチバージョン同時実行制御 およびに基づく行ごとの権限 公開鍵暗号。 新しい方法で結合された古いアイデアの長いリスト。 HTML / HTTP（必要な場合）。
これらすべてに加えて、共有書き込みデータベースには、まったく新しいタイプのルールが必要です。 トランザクションが実行できる変換を制限する。 これは絶対に重要な革新であり、信頼できないエンティティ間でデータベースを共有している場合にすべての違いが生まれます。 これらのタイプのルールは、ビットコインスタイルのトランザクション制約またはイーサリアムスタイルの強制として表現できます。 ストアドプロシージャ （「スマート契約」）、それぞれが持っています 長所と短所。 おそらく、発見されるのを待っている他のより良い方法があるでしょう。 しかし、それらはすべて、トランザクションの実行前と実行後のデータベースの状態を結び付ける特性を共有しています。 言い換えれば、彼らは質問に答えます： それは有効な取引でしたか？ これは、データベースが特定の時点で有効かどうかを尋ねることとは根本的に異なります。
このタイプのデータベースに実用的なアプリケーションがあるかどうか疑問に思っているのであれば、それは公正な質問です。 しかし、あなたはプライベートブロックチェーンへの強い関心を 少なくともXNUMXつのセクター、プロセスを簡素化し、コストと遅延を削減する可能性があるためです。 金融機関は今日のデータベースプラットフォームのヘビーユーザーであり、それらのプラットフォームは共有書き込みシナリオを有効にしません。 これが銀行が求めていることです。
この問題とその解決策は、ビットコインや検閲なしのお金の考え方とはまったく関係ありません。 実際、ビットコインへの唯一の接続は 技術的 ビットコインブロックチェーンとこれらのプライベートブロックチェーンのいくつかの類似性 今日実装されました。 主な違いのXNUMXつは、プライベートブロックチェーンが不要であることです。 仕事の証明 マイニング。ブロックは、特定された参加者の閉じたセットによって作成されます。 時間の経過とともに、XNUMXつの世界の要件は完全に異なるため、XNUMXつの世界はさらに異なる可能性があります。 金融規制が好きかどうかに関係なく、簡単な事実は、プライベートブロックチェーンは規制された世界で潜在的に有用ですが、少なくとも今のところは 公開ブロックチェーンは.
類推を終えれば、国連 国際法の原則に関する宣言 明確にマークされたフェンスで囲まれている限り、希望する領土を保持できることを国に伝えません。 むしろ、それは「脅迫または武力の行使に起因する領土取得は合法であると認識されるべきではない」と述べています。 言い換えれば、それはの正当性に関するルールです 変更だけでなく 状況。 そして、今や私たちには非常に明白に思える国連宣言は、国際法の完全な革命でした。 それはもはや、一方的な権力と権威に基づいた世界ではなく、相互のコンセンサスによって違いを解決できる世界を意味していました。
共有データベースに関して言えば、プライベートブロックチェーンはまったく同じことを行います。
