OCAP Playground 入門

著者： Shijun（ArcBlock エンジニアリングチームのフロントエンドエンジニア）

ブロックチェーン技術について基本的な理解がある方、あるいは簡単なブロックチェーンアプリケーションを自分で開発したことさえある方なら、チェーンごとに異なるインターフェースやデータ形式に戸惑ったことがあるのではないでしょうか。ブロックチェーンアプリケーションの大規模な開発を妨げる最大の障害は、ブロックチェーン上のデータを読み書きするために、ブロックチェーンごとにフルノードを動かす必要があることです。経験豊富な開発者であっても、こうした「面倒な作業」には多くの時間がかかります。

開発者なら、もっと開発者に優しく、従来のアプリケーションに近い方法でブロックチェーンアプリを開発できないかと考えるはずです。ArcBlock のエンジニアはこの問題を長い間検討し、数か月にわたる開発を経て、ArcBlock はマルチチェーンのデータアクセスをサポートするソリューション、Open Chain Access Protocol（通称 OCAP）を正式に発表します。

OCAP サービスに関心がある方、またはより馴染みのある方法でブロックチェーンアプリケーションを開発したい方には、ぜひ5分かけてこの記事を読むことをお勧めします。ここでは、開発者の視点から OCAP Playground の基本的な使い方を紹介します。

OCAP Playground とは？

新しい技術を採用する前に、それが何であるかを理解する必要があります。では、OCAP Playground とは何でしょうか。次の3つの観点から定義できます。

1. OCAP サービスの小さなフロントエンド

ほぼすべての複雑な現代のシステムは、大きなバックエンドと小さなフロントエンドというパターンに当てはまり、ArcBlock の OCAP サービスも例外ではありません。ユーザーの視点から見て触れられるフロントエンドは、氷山の一角にすぎません。

OCAP Playground は OCAP サービスの小さなフロントエンドであり、OCAP サービス全体の目に見える部分です。開発者は OCAP Playground で OCAP サービスの能力を簡単に探索できます。Playground のインタラクティブ性とデータ可視化能力により、開発者は探索の過程で発見や着想を得られ、OCAP サービス上で DApp を構築する準備を整えられます。

2. OCAP サービスのライブドキュメント

OCAP はすべてのインターフェースを GraphQL 仕様に従って提供しているため、GraphQL の単一エンドポイントと強い型付けのおかげで、OCAP Playground は OCAP サービスのライブかつリアルタイムなドキュメントになります。開発者は Playground でドキュメントを閲覧・検索でき、使い慣れた IDE でコードを書くように、クエリエディターのインテリジェントな自動補完を利用できます。

3. ArcBlock エコシステム初の DApp

OCAP サービスをブラックボックスとして扱うと、ArcBlock エコシステム全体における OCAP Playground の役割は次のように示せます。

OCAP Playground の使い方

実際に手を動かす前に、いくつか準備が必要です。

準備

ブロックチェーンデータのメンタルモデルを構築する

技術を概念的に理解すると、より早く習得できます。ほぼすべてのブロックチェーンデータは、次のような共通のメンタルモデルを持っています。

データのすべてまたは一部をブロックチェーンに保存する DApp の大半は、実際にはブロックチェーン上のアカウント、トランザクション、ブロックに関連するデータを読み書きしています。そのため、OCAP サービス API の大半はこの3つのエンティティを中心に構築されています。

GraphQL の構文を少し知る

OCAP サービスはクエリ言語として GraphQL を使用しています。jQuery の作者である John Resig は、GraphQL を新しい RESTだと考えています。エンドポイント仕様、エラー定義、データ型、パラメーター検証、API ドキュメントを考慮すると、GraphQL ははるかに優れた API ソリューションです。GraphQL コミュニティは非常に速く進化しており、一部のデジタル通貨取引所では GraphQL を使った API の提供も始まっています。

OCAP サービス上で DApp を開発したい人は、全員まず GraphQL を学ばなければならないのかと思うかもしれません。答えは「はい」ですが、心配はいりません。GraphQL の構文はかなり簡単です。一度も使ったことがなくても、OCAP Playground を使い始めることができます。次の例で、その直感性と簡潔さを感じられるでしょう。

Hello OCAP Playground!

百聞は一見にしかず、コードを見せてください。お気に入りのブラウザーで ocap.arcblock.io を開くと、OCAP Playground のデフォルト画面は2列に分かれています。左列がクエリエディター、右列が結果ビューアーです。Playground を初めて訪れた場合は、デフォルトのクエリがクエリエディターに入力され、その結果が自動的に表示されます。

独自のクエリを実行するにはどうすればよいでしょうか。クエリエディターをクリアし、次のクエリを入力します。このクエリは OCAP サービスに Bitcoin のジェネシスブロックのデータを要求します。Bitcoin ブロックのデータ構造について詳しくはこちらをご覧ください。

{
  genesisBlock {
    hash
    size
    total
    numberTxs
  }
}

次に「実行」ボタンをクリックするか、キーボードショートカット CTRL + Enter（Mac では CMD + Enter）を押すと、Bitcoin のジェネシスブロックデータが結果ビューアーに JSON 形式で表示されます。

{
  "data": {
    "genesisBlock": {
      "total": 0,
      "size": 285,
      "numberTxs": 1,
      "hash": "000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f"
    }
  }
}

このデータから、Bitcoin のジェネシスブロックにはトランザクションが1件だけ含まれ、ブロックハッシュは 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f であることがわかります。

おめでとうございます。OCAP Playground で最初のクエリを正常に完了しました。

OCAP Playground での複雑なクエリ

Bitcoin のジェネシスブロックにはトランザクションデータがあるのでしょうか。あるとすれば、受取人は誰でしょうか。Bitcoin はいくら送られたのでしょうか。Nakamoto がジェネシスブロックで自分のために50 Bitcoin を作ったというのは本当でしょうか。

OCAP Playground を使えば、自分で検証できます。冗長性なしに必要なブロックデータをすべて取得するクエリを1回で実行できます。既存のブロックチェーンデータクエリサービスの大半はブロックデータ全体を返しますが、多くの場合データが大きすぎて、アプリケーションが遅くなる可能性があります。

次のクエリをクエリエディターに貼り付けてください。手で入力することもお勧めします。その過程でクエリエディターの機能を理解できます。

{
  genesisBlock {
    hash
    size
    total
    numberTxs
    transactions {
      data {
        hash
        total
        inputs {
          data {
            account
            value
          }
        }
        outputs {
          data {
            account
            value
          }
        }
      }
    }
  }
}

このクエリは genesisBlock クエリ型にトランザクション関連のフィールドを追加しています。Bitcoin のトランザクションデータ形式について詳しくはこちらをご覧ください。クエリを実行すると、次の結果が得られます。

{
  "data": {
    "genesisBlock": {
      "transactions": {
        "data": [
          {
            "total": 5000000000,
            "outputs": {
              "data": [
                {
                  "value": 5000000000,
                  "account": "1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa"
                }
              ]
            },
            "inputs": {
              "data": [
                {
                  "value": 0,
                  "account": null
                }
              ]
            },
            "hash": "4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b"
          }
        ]
      },
      "total": 0,
      "size": 285,
      "numberTxs": 1,
      "hash": "000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f"
    }
  }
}

データから、ジェネシスブロックにはトランザクションが1件だけあり、そのトランザクションがアドレス 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa のアカウントに50 Bitcoin を送ったことがわかります。この50 Bitcoin は Nakamoto が使ったのでしょうか。

OCAP Playground の transactionsByAddress クエリ型を使って、さらに深く調べられます。

OCAP Playground のテーブルビューを使用する

ここで、Nakamoto の Bitcoin アドレスが 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa だと大胆に仮定してみましょう。このアドレスはジェネシスブロック以降、さらにトランザクションを送信または受信したのでしょうか。それらのトランザクションでは、いくら送金されたのでしょうか。

次のクエリを使って Nakamoto のアカウントのトランザクションを確認できます。

{
  transactionsByAddress(sender: "1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa") {
	data {
      hash
      total
    }
  }
}

結果は次のとおりです。

{
  "data": {
    "transactionsByAddress": {
      "data": []
    }
  }
}

どうやら、ジェネシスブロックで作られた Bitcoin は一度も動かされていません。誰かがこのアカウントに Bitcoin を送ったことはあるのでしょうか。次のクエリで答えを得られます。

{
  transactionsByAddress(receiver: "1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa") {
	data {
      hash
      total
    }
    page {
      cursor
      total
      next
    }
  }
}

1つのアドレスには多数のトランザクションが含まれる可能性があるため、OCAP サービスはパフォーマンス向上のため大規模なデータセットをページ分割します。クエリの page.total フィールドを使ってトランザクションの総数を取得できます。

{
  "data": {
    "transactionsByAddress": {
      "page": {
        "total": 1252,
        "next": true,
        "cursor": "pU7180SPAj6PCYTB1r%2BCHg%3D%3D"
      },
      "data": [
        {
          "total": 2267721,
          "hash": "256add784c8975fb357010b1b21539a5e55c25af231870616675ff757c5a64f5"
        },
        ...
      ]
    }
  }
}

Nakamoto のアカウント宛てには1252件のトランザクションがあります。必要であれば、各トランザクションの送信者と金額を確認できます。

クエリ結果をより見やすくするため、OCAP Playground は結果がリスト型のデータかどうかを検出し、テーブルとして表示します。

同時に、開発者がデータをよりよく理解できるよう、テーブルでフィールド値を表示する際に多くの工夫を施しています。

クエリ結果に transaction inputs や transaction outputs のようなネストしたデータ、または1つの block 内の複数の transactions が含まれていても、テーブルビューで適切に可視化できます。試してみたいですか。次のセクションのクエリを実行し、テーブルビューで表示結果を確認してみてください。

OCAP Playground のチャートビューを使用する

百聞は一見にしかず。ArcBlock のエンジニアは、ブロックチェーンデータを正しく可視化するために多くの作業を重ねてきました。次のクエリを例に見てみましょう。

{
  transactionsByAddress(receiver: "1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa") {
    data {
      hash
      total
      inputs {
        data {
          account
          value
        }
      }
      outputs {
        data {
          account
          value
        }
      }
    }
    page {
      cursor
      total
      next
    }
  }
}

このクエリは、アカウント 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa に送られたすべてのトランザクションを返します。Bitcoin ネットワークは本質的に分散型であるため、ネットワーク内のお金の流れはサンキーダイアグラムで可視化できます。アカウントをネットワーク内のノード、トランザクションをノード間のデータフローとして扱い、結果ビューアーで chart view に切り替え、チャートの種類で sankey を選択すると、次の可視化が得られます。

すべてのトランザクションの金額が非常に小さいことから、ブロックチェーンコミュニティが Nakamoto に寄付している可能性が高いとわかります。

sankey ダイアグラムを試していて興味深い可視化に出会ったら、ぜひ私に共有してください。

OCAP Playground がサポートするその他のクエリ

ここまでの例は最初から最後まで Bitcoin を扱ってきましたが、マルチブロックチェーンのサポートはどうでしょうか。この記事を読みながら実際に OCAP Playground を試した方なら、異なるブロックチェーンを切り替える方法に気づいたはずです。Playground ではタブ形式で複数のクエリを作成でき、各タブで異なるブロックチェーンを選択できます。タブ左上のドロップダウンボタンを使ってブロックチェーンを切り替えられます。

異なるチェーンがサポートするクエリはほぼ同じです。たとえば、次のクエリ型は Ethereum と Bitcoin の両方でサポートされていますが、データ構造は多少異なる場合があります。

トークンは Ethereum エコシステムの重要な一部であり、Ethereum ブロックチェーン上に大量のデータも生み出しています。OCAP サービスは、クエリ型 [transactionsByToken](https://ocap.arcblock.io/doc/ethereum/#transactionsbytoken) によるトークン別のトランザクション照会にも対応しています。便利ではないでしょうか。

OCAP Playground を試しているときに問題が起きたらどうすればよいでしょうか。OCAP サービスはバックエンドとフロントエンドの両方ですべての例外を記録します。バグが見つかった場合は、できる限り早く修正します。

もう一つ

Playground の改善について提案がありますか。提案はこちらまでお送りください：shijun@arcblock.io

ブロックチェーン時代の幕はすでに上がっています。ブロックチェーン技術の成熟と大規模な普及において、すべての開発者に果たすべき役割があると私は信じています。傍観するよりも、すぐに飛び込んで何かを始めるほうがよいでしょう。