本連載では、ブロックチェーンの基本的な仕組みを解説しながら、オンチェーンデータを分析するための基本的な手法について、全8回で紹介します。

第2回となる今回は、ブロックチェーン技術が最初に発明された暗号資産(仮想通貨)であるビットコインの仕組みについて、技術的な観点やその目的などを中心に解説します。

ビットコインのデータ構造

本連載の最終的なゴールは、オンチェーンデータと呼ばれるブロックチェーン上のパブリックデータを用いたデータ分析ができるようになることですので、ブロックチェーンのデータ構造の理解が重要となります。

もちろん、異なるブロックチェーンシステムでは、データ構造が異なる部分もあります。そのため、複数のブロックチェーンのデータ構造を比較することで、多くのブロックチェーンに共通するデータ構造と、特定のブロックチェーンに固有のデータ構造が理解できるようになります。

今回はビットコインのデータ構造について概観し、次回記事にてイーサリアムのデータ構造を見ていく予定です。両者を比較することでブロックチェーンのデータ構造についての理解が深まると思います。

実データを観察する

まずは、具体的なビットコインブロックチェーンの実データを見てみましょう。

ビットコインは誰もが参加可能なP2P型のアプリケーションですので、OSSとして公開されているプログラムを用いて誰でも自分のノードを立ち上げて、ビットコインのネットワークから情報を取得することができます。

しかし、ビットコインのデータをデータベース化して利用しやすくしたオンラインサービスも数多く存在していますので、まずはそれらを使ってデータにアクセスしてみましょう。

Google BigQuery

Google Cloudが提供するデータウェアハウスサービスとして広く使われているBigQueryでは、同じくGoogle Cloudが提供する一般公開データセット(※1)を用いて簡単にデータ分析を始められます。

この一般公開データセットには、医療や経済、科学などをはじめ、さまざまなジャンルのデータが含まれており、主要なブロックチェーンのオンチェーンデータも提供されています。

また、BigQueryは従量課金制のクラウドサービスですが、毎月の無料枠も設定されており、課金を有効にしなくても一般公開データセットを用いた分析を始められます。詳しくはGoogle Cloudの公式ページのドキュメントを参照してください。

Google CloudとBigQueryのセットアップをおこない、テーブルID: 「bigquery-public-data.crypto_bitcoin」を検索すると、図1に示すようなビットコインのオンチェーンデータを格納したテーブルを表示できます。テーブルには「blocks」と「transactions」があり、アイコンの異なる「inputs」「outputs」は、他のテーブルから計算されたビューと呼ばれる特別なテーブルを示します。

BigQueryの画面上で特定のテーブルを選択し、「スキーマ」タブを選択するとテーブルのスキーマ定義が確認でき、「プレビュー」タブを選択するとテーブル内のサンプルデータを確認できます。

図1. BigQueryのBitcoin Cryptocurrencyデータセットにおけるblocksテーブルのサンプルデータ

※1 BigQuery の一般公開データセット

Blockchain Explorer

多くのブロックチェーンには、オンチェーンデータにリアルタイムにアクセスし、トランザクションの内容などを確認するための「Explorer」と呼ばれるオンラインサービスが提供されています。

ビットコインでも、多くのExplorerサービスが提供されています。図2は、Blockchain.com Explorerと呼ばれるサービスの画面です。

図2. Blockchain.com Explorerのサービス画面

※2 Blockchain.com Explorer

トランザクションのデータ構造

実データをもとにしながら、まずはビットコインの送金の単位であるトランザクションのデータ構造について概観してみましょう。

Blockchain.com Explorerで適当なトランザクション(例: Hash ID e2d6a46ff3c0ac7977c4e56250cc8e3a3bfb566cf1fbc1f41975ce927f268daa)をクリックしてみると、そのトランザクションの概要(図3)が表示されます。

図3. Blockchain.com Explorerでのトランザクション表示例

それぞれのトランザクションには、Hash IDと呼ばれる固有のIDが振られています。トランザクションの中で特に重要なデータ構造は、「Inputs」と「Outputs」です。「Inputs」は、過去に自身がビットコインを受け取ったトランザクションを参照し、「Outputs」は新たにビットコインを送るアドレスを指定します。このビットコインのトランザクションの形式は、お金の取引を「借方」と「貸方」の2面で表現する複式簿記の考え方に似ています。

図4. 複式簿記とビットコイントランザクションの比較イメージ

複式簿記は、お金の取引を原因と結果に分け、借方と貸方に記載します。図4の複式簿記の例では、後払いで代金を受け取る権利である売掛金50,000円を、普通預金で受け取り、支払い手数料を自社負担した場合の記載を示しています。ここで、借方の普通預金と支払手数料の合計と、貸方の売掛金の合計は一致しています。

ビットコイントランザクションの考え方も、取引の原因に該当する「Inputs」と、結果に該当する「Outputs」の合計が常に一致する、という考え方です。厳密には、「Inputs」の合計を「Outputs」の合計が超えることはなく、差額がある場合はこの取引を実行するための手数料として定義されるため、結果的に両者の合計が一致する形になっています。

ブロックのデータ構造

図5. ビットコインホワイトペーパーにおけるブロックのデータ構造イメージ

上記のトランザクションを、複数まとめたデータ構造がブロックです。ブロックにも、固有のHash IDが割り振られています。そのHash IDの計算は、ある入力に対して固定長のランダムな値を返す「ハッシュ関数」と呼ばれる関数でおこなわれます。このハッシュ関数に、「そのブロックが含んでいるトランザクション」「一つ前のブロックのHash ID」「Nonce」などを入力して、ブロックのHash IDが計算されています。Nonceとは、「number used once」の略で、一度だけ使われる使い捨てのランダムな値です。

ビットコインのブロックがなぜこのようなデータ構造になっているのかを理解するためには、ビットコインが解決しようとしてる課題が何なのかという前提の説明が必要です。少し脇道に逸れますが、ビットコインが解決しようとした課題について、身近な事例に落とし込んだ解説をしてみましょう。

ビットコインが解決しようとした課題

ビットコインが解決しようとした課題を正確に理解するためには、コンピュータサイエンスにおける分散システムの基礎知識が必要です。厳密な議論をおこなうためには本連載のみでは紙面が足りませんので、ここでは「現実世界で独自の通貨を流通させる」という仮の事例を想定しながら、どのような問題が起こりうるのかを思考実験として考えみましょう。

実世界で独自の通貨を流通させる思考実験

子どもの頃、学校の教室内で独自の通貨を流通させて遊んでいたことがある、という人もいるかもしれません。ここでは、学校の教室で独自の通貨を流通させてみるという思考実験を通じて、通貨システムと分散システムの課題について考えてみます。

レベル0. 物理的な通貨の発行

教室内で独自の通貨を流通させるためには、まずは通貨の発行が必要です。よく事例として挙がるのは、瓶の王冠やシャープペンシルの芯など、ある程度の数量が均質化された品質で入手でき、個人での偽造が難しいものを通貨として利用する事例でしょう。

通貨の代表的な役割として、「価値の尺度」「交換の手段」「価値の貯蔵」が挙げられるため、これらの役割を満たすための機能性が通貨には求められます。

特に、通貨の価値を担保するためには、その通貨が使えるユーティリティを確保するという「強制通用力」と、決められた手順以外で勝手に通貨を増やしたりできない「偽造防止」という性質が重要です。

ここでは仮に、「教師の持つ印鑑で押印された紙幣」を通貨として設定してみます。教師の持つ印鑑は複製が難しく、紙幣をコピーしてもすぐに見分けられるという前提を置いて、「偽造防止」が成立しているものとします。

また、「強制通用力」としては、教師の出題する宿題などを免除したり、教師の準備した文房具などと交換できたりといったユーティリティを想定します(ここではその是非については深入りしません)。教師と生徒の間で、この独自紙幣を用いた取引が成立するようになると、通貨としての価値が確立され、生徒間同士での取引でも使われることが期待できます。

現実世界では、日本の中央銀行が偽造の困難な紙幣を発行し、法律で強制通用力を持たせる(租税貨幣論と呼ばれる考え方では、日本の居住者は日本円で税金を納めなければならないというユーティリティを持たせる)という事例に対応しています。

レベル1. データ化された通貨の発明

上記のように発行された紙幣が広く利用されるようになると、いくつかの課題が発生しそうです。例えば、大量に発行された紙幣を「毎日持ち運ぶのが大変」「枚数を数えたり額面を足し合わせたりといった計算が大変」「紛失・盗難に遭うリスクがある」といった問題が考えられるでしょう。

これらの課題を解決する一手段として、通貨をデータ化して管理するという解決方法を導入してみます。

データ化といっても、ここでは「ノートにお金のやりとりを記録した帳簿をつくる」といった形のアナログな手段を想定します。帳簿は教師が管理し、個々の取引は教師が承認し押印することで効力を持つこととします。

この仕組みは、現実世界での銀行口座や電子マネーのようなものに該当します。大量の紙幣を持ち歩かなくても自身の持っている残高を帳簿が保証してくれますし、帳簿が適切に管理されている限りは紛失や盗難などのリスクもありません。

レベル2. システムの分散化

教師が管理する帳簿を導入しても、別の課題が発生します。例えば「教室など帳簿が存在する場所でしかやりとりできない」という課題が考えられます。物理的な紙幣を使っていたときは、部室や学校外でも生徒間で紙幣を用いた取引ができていましたが、教師が管理している帳簿に記載しなければ取引が成立しないとすると、毎回教師の下にうかがって記載してもらう必要があり、利便性を損ないます。

そこで、帳簿を記載するノートを分散化することが考えられます。生徒各自が毎日、自分の取引に関連するノートの一部を持ち帰ることができ、教室外でも取引を記載できるようにします。教室外でやりとりを記録したノートは、毎日教室で教師がチェックし、押印することで効力を持つこととします。矛盾したやりとりがあれば、どちらかを無効にする等で解消します。最終的な取引の確定には最長丸1日かかりますが、教室外でも取引を発生させることができるようになります。

現実世界では、インターネットなどのネットワークを介した分散システムを構築することに該当します。

レベル3. 管理者の分権化

分散化した帳簿を導入しても、さらなる課題が存在します。最も大きな課題として、「承認者(教師)が不在のときに停止する」という問題が発生します。例えば、教師が病気や出張などで長期間不在となってしまうと、この通貨システムは承認が行われず機能停止してしまいます。

これは、処理の一部(取引の発生)を分散化したとしても、特権的な操作(取引の承認)を一部の管理者(教師)に依存してしまっていることが原因です。

この課題を解決するためには、取引の承認を生徒自身が行えるよう、権限を分権化することが考えられます。

例えば、生徒が毎日持ち回りで承認者の役割を担うようにして、もしその生徒が何らかの事情で対応できないときは、次の生徒が繰り上がりで承認作業をおこなう、といった運用です。

レベル4. 悪意を持った参加者への対策

生徒が持ち回りで承認作業をおこなう運用にした場合、一部の生徒による不正行為が発生しないか、という懸念が持ち上がることがあります。

例えば、自分が承認者のときに自分に有利なように取引を改ざんしたり、そこまではしなくとも、仲の良くない生徒からの取引申請を意図的に受け入れなかったり対応を遅れさせたり、といった検閲行為がされる可能性があります。

(こういった問題は教師が承認者を担う場合でも存在していましたが、教師への信用によって顕在化しにくい状態だったと言えます)

こうした問題は、分散システムの領域では「ビザンチン将軍問題」(※3)として有名です。ビザンチン将軍問題とは、ビザンチン帝国の将軍たちが、物理的に離れた場所にいながら、敵国に攻撃するか撤退するかについてどのように合意形成すべきか、という問題です。このとき、将軍たちの中に複数名の裏切り者がいる場合でも、正しく合意形成を行うことができるアルゴリズムが考案されており、このようなアルゴリズムを「ビザンチン障害耐性」のある合意アルゴリズムと呼びます。

詳細なアルゴリズムの挙動については説明を省きますが、参加者たちがお互いに情報を共有しあい、矛盾した情報がある場合は多数決で情報を訂正しながら全体の合意を得る、といった流れがおおまかなアイデアになります。

ただし、古典的なビザンチン障害耐性アルゴリズムは、ネットワーク参加者のうち、裏切り者(ビザンチン障害ノード)が全体の3分の1未満であることが必要とされています。裏切り者が全体の3分の1以上の場合は解決手段が発見されていませんでした。

ビットコインのブロックチェーンは、このビザンチン将軍問題を、一部の妥協を許した形であれば、よりゆるい条件(ビザンチン障害ノードが全体の50%未満)で合意形成に到れるアルゴリズムを示した、と評価されることもあります。

※3 Leslie Lamport, Robert Shostak, Marshall Pease: “The Byzantine Generals Problem”, ACM Transactions on Programming Languages and Systems, Vol.4, No.3, pp. 382-401, 1982. https://lamport.azurewebsites.net/pubs/byz.pdf

レベル5. 不特定多数の参加者による利用

教室内に不正を働く可能性のある生徒が混ざっている状態において正しく取引を記録する仕組みが構築できたとしても、さらに困難な要求をされることがあります。

それは、自分たちのクラス以外の生徒など、不特定多数のメンバーも、そのクラス内で流通している通貨を使えるようにしたい、という要求です。

最初のレベル0の物理的な通貨であれば、通貨が本物であることが証明できればクラス外のメンバーなど誰でも通貨を使うことは可能でした。

しかし、物理的な紙幣を廃止し、データとしての通貨を利用しているレベル1からレベル4の状態は、いずれもクラス内の閉じた参加者の中で使われることが前提でした。

現実世界でも、現金のような物理的な通貨は、それをつかう人が誰であっても平等に使用することができる一方、銀行預金や電子マネーのようなデータ化された支払い手段は、信頼された特定の人々しか利用できない、といった制限がありました(例えば、子どもは親権者の同意がなければ銀行口座を作れない、等)。

レベル5に該当するような「不特定多数の誰もが自由に使えるデジタル通貨」の発明は、長らく開発者にとっての夢でしたが、ビットコインの登場によって初めてこの問題が実用的なレベルで解決されたのです。

余談ですが、昨今キーワードとして話題になる「Web3」という言葉は、レベル1~2のようなWebシステムを「Web2」として、レベル3以上の分権化の仕組みを実現したWebを指す言葉として使われることがあります。

レベル3~4の問題は従来の技術で解決できる範囲ではあったものの、多くのWebサービスはレベル2止まりのシステムでビジネスをおこなっていました。そこに、ビットコインがレベル5の問題を解決するソリューションとして登場し、レベル3以上のシステムの重要性が再評価されはじめています。

ただし、レベル3以上の問題のうち、どこまでを実現できていれば「Web3」と呼べるのか、という解釈については、意見が割れているところです。

ビットコインの発明

分散システムとしてのビットコインの新規性は、上記のレベル5の問題で示したような不特定多数が参加するネットワークにおいて、ビザンチン障害耐性を持った合意形成のための現実的な解を示したことです。

しかし、ビットコインの革新性はそれにとどまらず、通貨としての強制通用力の担保や、ゲーム理論的なインセンティブ設計などのアイデアもバランスよく取り込み、実運用に耐える全く新しいデジタル通貨システムを発明したことでしょう。

最後に、ビットコインの特徴といえるポイントをまとめます。

ブロックの特徴

ビットコインのブロックには、前述のとおり、そのブロックに含まれるトランザクションや、一つ前のブロックのIDなどから計算されたHash IDが振られています。

そのHash IDは、ある値以下の数値になるようにルールが設定されており、そのルールを満たす調整のために加えられたランダムなデータが前述のNonceです。

新しいブロックを生成するためには、このNonceを大量のパターンで試し、たまたまHash IDがある値以下になるようなパターンを見つけなければなりません。この処理に大量のコンピュータリソースが必要となる設計となっています。

ナカモトコンセンサス

ビットコインにおいて、あるトランザクションが承認されているかどうかは、そのトランザクションを含むブロックの連鎖に対して、どれくらいのコンピュータリソースを投入されたで判断するルールとなっています。2つの矛盾するトランザクションがあった場合、そのトランザクションを含むブロックやその後続のブロックを発見するために、より多くのリソースを消費したほうを正しいとみなす、といったアイデアです。

このアイデアは「ナカモトコンセンサス」とも呼ばれ、分散システムにおける「不特定多数の参加者」という扱いにくい対象を、コンピュータの計算リソースという定量的な数値に置き換え、それによる多数決の問題に帰着させたことに革新性があります。

このアイデアの欠点として、「どのトランザクションも、あとから覆される可能性は永久にゼロにはならない」という点があり、伝統的な金融サービスからは懸念を示されることがあります。

しかし、「トランザクションの覆る可能性が、ある一定の確率以下(0.0000….1%未満等)になればゼロとみなして良い」という妥協を許せば、現実的に機能するシステムとなることが、ビットコインの運用によって証明されつつあります。

通貨としての通用力・インセンティブ設計

国の中央銀行が発行する法定通貨の場合、最終的には「その国の税金をその法定通貨で支払わなければならない」という点が、通貨としての通用力を担保している、という考え方があります。

ビットコインの場合、ビットコインを送金するための手数料をビットコインで支払わなければならないことが通用力の根拠となっていると考えられます。

また、インセンティブ設計に関しては、トランザクション手数料や新しく発行されるビットコインが、ブロック生成者に報酬として付与される仕組みとなっており、システムの持続可能性や不正の抑制を実現しています。

ビットコインの価値を信じる人は、ブロックの生成を通じてビットコインを得ることでビットコインの仕組みの維持に貢献し、ビットコインに貢献する人が増えることでさらにビットコインの信頼性が向上し価値も向上する、という好循環が生まれやすい仕組みとなっているのです。

次回予告

ビットコインの発明によって、これまで技術的に実現が困難だと思われた不特定多数の参加者で構成される分散システム上で、新しいデジタル通貨の概念である仮想通貨(暗号資産)が登場しました。

その後、ビットコインを実現した要素技術が「ブロックチェーン」という名前で抽象化され、ビットコイン以外の仮想通貨(アルトコイン)や、より汎用的な分散台帳システムに応用されはじめました。

次回の記事では、ブロックチェーン技術を用いた「ワールド・コンピュータ」の実現を目指すイーサリアムについて解説し、ビットコインと比較しながらブロックチェーン技術の理解を深めます。

連載一覧

【第1回】ブロックチェーンとは
【第2回】ビットコインの仕組み
【第3回】イーサリアムの仕組み
【第4回】ビッグデータ分析のためのSQL基礎
【第5回】Ethereumデータ分析演習1
【第6回】Ethereumデータ分析演習2
【第7回】Ethereumデータ分析演習3
【第8回】Ethereumデータ分析演習4

#ビットコイン #オンチェーン分析

SHARE

  • facebook
  • twitter

SQRIPTER

加嵜 長門(かさき ながと)

記事一覧

合同会社DMM.com Web3事業部テックグループリーダー・DMM.comグループ株式会社DM2C Studio取締役(CTO)。ビッグデータ活用基盤の構築に携わり、SparkやSQL on Hadoopを用いた分散処理技術やブロックチェーン技術の研究開発、事業提案などを担当。共著に『試して学ぶスマートコントラクト開発』『ブロックチェーンアプリケーション開発の教科書』『ビッグデータ分析・活用のためのSQLレシピ』(マイナビ出版)、『詳解Apache Spark』(技術評論社)。

RANKINGアクセスランキング
#TAGS人気のタグ
  • 新規登録/ログイン
  • 株式会社AGEST
NEWS最新のニュース

Sqriptsはシステム開発における品質(Quality)を中心に、エンジニアが”理解しやすい”Scriptに変換して情報発信するメディアです

  • 新規登録/ログイン
  • 株式会社AGEST