Amazon Managed BlockChainを使って分散台帳プラットフォームを構築する

はじめに

こんにちは。ABEJAのシステム開発グループでソフトウェアエンジニアをしている吉田です。 現在（2022年5月）仮想通貨が暴落中で、Blockchain技術自体も幻滅期にあると思われますが、 ABEJAでは最近、BlockchainやWeb3.0に関するSlackチャンネルができたり、社内ではこのあたりの技術がブームになってきているので、自分も波に乗り遅れないように、Blockchainを勉強しようと思い初めました。
そこでサービス自体は知っているけど得体の知れない、Amazon Managed BlockChainに入門してみたので、そのお話を記事にします。
Managedと書いてあるので、すぐに構築できそうかなと思っていたのですが全然そんなことなく、めちゃめちゃ手順が長いかつ、情報がとても少なくこのテーマにしたことを途中で後悔しました。。笑

Amazon Managed BlockChainとは

一般的なオープンソースフレームワークである Hyperledger Fabric や Ethereum を使用して、パブリックネットワークへの参加や、スケーラブルなプライベートネットワークの作成と管理を簡単に行えます。
出典: AWS公式

Amazon Managed BlockChainはブロックチェーンの作成と管理をできるようにしたサービスです。 現在パブリックネットワークの参加ではEthereumが、プライベートネットワークの作成ではHyperledger Fabricというプラットフォームを選択することができます。 今回は企業向けブロックチェーン・プラットフォームの事実上の標準とも言われているHyperledger Fabricで構築していきます。

Hyperledger Fabricとは

Hyperledger Fabric は 分散台帳プラットフォームの 1 つで、共有対象のデータのみが、「許可されている」（既知の） ネットワーク参加者間で共有されます。
出典: IBM　Hyperledger Fabricとは？

Hyperledger FabricはBitcoinやEthereumのようにオープンではなく、管理者が存在し、許可された参加者のみの「許可型」のブロックチェーンです。
Hyperledger Fabricのような許可型のブロックチェーンは、共通する目標をもちつつ、完全には互いを信用していないグループの中でのやりとりを行う場所を提供しています。
参加者の素性が明らかであることで、Bitcoinなどとは違い、従来からの合意形成プロトコルが使用でき、マイニングを必要としていないのが特徴です。
ユースケースとしてはサプライチェーンのトレーサビリティや医療情報の管理や金融機関間の取引に利用されているようです。

また、スマートコントラクトもEthereumのSolidity言語のように独自言語ではなく、JavaやGo、Node.jsで記述できます。（スマートコントラクトについては後述します。今回はサンプルでGO言語を使っています。）

Hyperledger Fabricに関する基本用語

Hyperledger Fabricの理解に最低限必要な用語についてご紹介します。 より詳しい構造を理解したい方はこちらを参照してください。

チェーンコード

一般的にはスマートコントラクトと呼ばれていますが、Hyperledger Fabricでは「チェーンコード」と呼んでいます。 チェーンコードはあるトランザクションにおいて、何かしらの処理を行い、必要に応じて台帳を読み書きする処理をするプログラムコードのことです。

ピアノード（ピア）

ブロックチェーンネットワークは、このピアノードのセットで構成されています。
ピアノードは、台帳とチェーンコードをホストしていて、チェーンコードをインスタンス化して実行しています、台帳の読み書きが必要な場合は、チェーンコードを使ってアクセスすることができます。

チャンネル

チャンネルは、ピア間の通信のためのパスのようなものです。 ピアがチャンネルに参加することによって、そのチャンネルに関連付けられた台帳のコピーを共有・管理することができます。また、1 つのピアが複数のチャンネルに参加することも可能です。

台帳

ブロックチェーンで扱うデータのことです。 全てのトランザクション履歴が記録されたブロックチェーンデータと、ステートの現在値が記録されたワールドステートの 2 種類が保存されています。 台帳のステートは、デフォルトではキーバリューのペアとして表現されます。

Orderer

すべてのピアの台帳が相互に一貫性を保つように、ordererと呼ばれる特殊なノードによって管理されています。

認証局（Certificate Authorities）

Hyperledger Fabric内の各要素を識別するための証明書を発行する役割をしています。また、Hyperledger Fabric内の各要素においてTLS 通信を行うための証明書を発行する役割もあります。

MSP（メンバーシップサービスプロバイダー）

認証局が証明書を生成するのに対して、MSPは許可された証明書のリストを持っていて、証明書に紐づくロールを管理し、付与をする役割を担っています。

Amazon Managed BlockChainにおけるHyperledger Fabricの構造

Amazon Managed BlockChainのHyperledger Fabricは以下のような構成になっています。
上側の部分がAmazon Managed BlockChainが管理をしてくれるHyperledger Fabric部分です。
Fabric Clinet Node（後述ではHyperledger Fabric クライアント）は今回EC2を使用して、Hyperledger Fabricをセットアップや操作していきます。

Amazon Managed BlockChainの構造（AWS公式）

Amazon Managed BlockChainでのHyperledger Fabricの構築

それではここから構築に入ってきます。構築方法は基本的にAWS公式の手順に従っていますので、アップデートで変更等があればそちらをご参照ください。
Amazon Managed BlockChainではHyperledger Fabricに他のAWSアカウントを招待することで、プライベートブロックチェーンを実現しています。
そのため今回は2つのアカウントを使用しますので用意をお願いします。私は新規に2つのアカウントを用意しました。

※一部画像等でAmazon Managed BlockChainのidなどが表示されているかと思いますが、アカウントごと既に削除済みですのでご安心ください。

Step.1 Hyperledger Fabricのネットワークの作成と最初のメンバーの作成

まずは一つ目のアカウントからセットアップと動作確認をしていきます。
Amazon Managed BlockChainはまだ限られたリージョンでしか使用できないため、使用可能なリージョンを選択する必要があります。私は今回us-east-1を使用しました。
コンソールからAmazon Managed BlockChainに移動し、ダッシュボードの「プライベートネットワークの作成」をクリックします。 すると以下の画面が表示されます。

Amazon Managed BlockChain

この画面では以下の項目を設定します。

• フレームワークはHyperledger Fabric、バージョンは2.2を選択します。
• ネットワーク名は任意の名前を入力します。
• 投票ポリシーは今回2つのアカウントしか参加させないので、デフォルト値で大丈夫です。

メンバーとCAの設定

「次へ」をクリックし、画面で以下の項目を設定します。

• 最初のメンバー名は任意の名前を入力します。
• Hyperledger Fabric 認証機関 (CA) の設定ではユーザー名とパスワードを設定します。（ここで設定したユーザー名とパスワードは後で使用するのでどこかにメモしておいてください。）

「次へ」をクリックし、確認画面で確認したら「ネットワークとメンバーの作成」の作成をクリックします。
これでHyperledger Fabricのネットワークの作成と最初のメンバーの作成が開始されます。ここまでは簡単ですね！記憶が曖昧ですが、20分程で作成が完了したと思います。

Step.2 VPCエンドポイントを作成する

VPCエンドポイントを作成します。ここでVPCエンドポイントを作成することで、後に作成するEC2（Hyperledger Fabric クライアント）がHyperledger Fabricネットワークと通信することができます。
ネットワークが作成されると、Amazon Managed BlockChainに以下のような画面が現れます。ここで、「VPCエンドポイントを作成する」ボタンをクリックします。

VPCエンドポイントの作成

VPCとサブネットとセキュリティグループを選択し、「作成」をクリックします。（デフォルトのVPCや自分で作成したVPC等を選択してください）

VPCエンドポイントの作成画面

Step.3 ピアノードを作成する

ネットワークからメンバーのタブを開き、Step.1 で作成したメンバーをクリックし、表示された画面の「ピアノードの作成」をクリックします。

ピアノードの作成

今回はピアノードで複雑な処理を行わないため、全てデフォルト値のままで、「ピアノードを作成」を押してください。

ここでの入力値の意味は以下の通りです。

ブロックチェーンのインスタンスタイプ：bc.t3.small – 2 vCPU、2GiB RAM

• ピアノードに割り当てられるインスタンスのCPUやメモリなどの組み合わせ。

ステートDB設定：LevelDB

• LevelDB：台帳のステートが単純なキーバリューの時に適しているDB
• CouchDB：台帳のステートがJSONの時に適しているDB

ステートDB詳細についてはこちらを参照ください。

Step.4 Hyperledger Fabric クライアントを作成する

まずはEC2の立ち上げを行います。コンソールやcliからEC2の立ち上げを行なってください。

立ち上げ時の注意点としては以下の3点になります。

1. 先ほどのVPCエンドポイントを作成した時と同じVPC・サブネット・セキュリティグループに作成してください。
2. インスタンスタイプはt2.medium以上を設定してください。（後のステップでdockerやdocker-composeを使用していきますので、念の為）
3. SSH接続のため、pemキーの取得を取得してください。

また、Hyperledger Fabricクライアントを自分で作成するのが面倒な方はCloudFormationテンプレートが用意されています。（Step.11まで自動で設定を行うことができます。）

Step.5 EC2にSSH接続を行う

SSH接続を行うために、セキュリティグループでSSHのインバウンドルールを追加します。
VSCodeのRemote SSHを使うなどお好きな方法で接続できることを確認してください。

Step.6 EC2にIAMロールを付与する

IAMのページに移動し、IAMポリシーの作成を行います。 こちらのページのJSONをコピーします。 JSONの中身のリージョン部分とアカウントID部分を変更し、IAMポリシーを作成し、そのIAMポリシーを紐付けたIAMロールを作成します。
EC2のページで先ほど作成したインスタンスを選択し、アクション>セキュリティ>IAMロールの変更で作成したIAMロールをアタッチします。

Step.7 Hyperledger Fabric クライアントでのセットアップ

ここからEC2にSSH接続しながら、Hyperledger Fabric クライアントをセットアップしていきます。
まずはパッケージのインストールです。dockerやGoをインストールしていきます。
こちらのStep 4.1 Install Packages部分のコマンドの実行および.bash_profileの設定を行います。
インストールができたら、docker-composeやGoの動作確認行い、問題なければ次に進みます。

Step.8 EC2からHyperledgerFabricCAの接続確認

EC2上で以下のコマンドからHyperledgerFabricCAのエンドポイントを取得します。
ここで使用されている、ネットワークIDやメンバーIDはAmazon managed blockchainのコンソール上から確認できます。

$ aws managedblockchain get-member \
--network-id {managed blockchainのネットワークID} \
--member-id {managed blockchainのメンバーID}

以下のようなCAエンドポイントが取得できると思います。

ca.m-123korehadummy767ci.n-6korehadummy.managedblockchain.us-east-1.amazonaws.com:30005

ここで取得したCAエンドポイントをStep.7で作成した.bash_profileのCASERVICEENDPOINTの変数に設定しておきます。

こちらの接続確認のために以下のコマンドを実行し、CANameなどが入ったレスポンスが帰って来れば大丈夫です。

$ curl https://$CASERVICEENDPOINT/cainfo -k

{"result":{"CAName":"abcd1efghijkllmn5op3q52rst","CAChain":"LongStringOfCharacters","Version":"1.4.7-snapshot-"}
,"errors":[],"messages":[],"success":true}

Step.9 とHyperledgerFabricCAクライアントのインストールとサンプルコードのクローン

以下のコマンドでStep.7でクローンしたgoのディレクトリ下にHyperledgerFabricCAクライアントをインストールします。

$ mkdir -p /home/ec2-user/go/src/github.com/hyperledger/fabric-ca
$ cd /home/ec2-user/go/src/github.com/hyperledger/fabric-ca
$ wget https://github.com/hyperledger/fabric-ca/releases/download/v1.4.7/hyperledger-fabric-ca-linux-amd64-1.4.7.tar.gz
$ tar -xzf hyperledger-fabric-ca-linux-amd64-1.4.7.tar.gz

ec2-userディレクトリにチェーンコードのサンプルレポジトリをクローンしてきます。

$ git clone --branch v2.2.3 https://github.com/hyperledger/fabric-samples.git

Step.10 docker-composeの構成ファイルの作成とHyperledger Fabric CLIの実行

docker-compose-cli.yamlファイルをec2-userのディレクトリ下に作成し、以下の内容をコピペしてMyMemberIDとMyPeerNodeEndpointを自分の環境の値に書き換えます。

version: '2'
services:
  cli:
    container_name: cli
    image: hyperledger/fabric-tools:2.2
    tty: true
    environment:
      - GOPATH=/opt/gopath
      - CORE_VM_ENDPOINT=unix:///host/var/run/docker.sock
      - FABRIC_LOGGING_SPEC=info # Set logging level to debug for more verbose logging
      - CORE_PEER_ID=cli
      - CORE_CHAINCODE_KEEPALIVE=10
      - CORE_PEER_TLS_ENABLED=true
      - CORE_PEER_TLS_ROOTCERT_FILE=/opt/home/managedblockchain-tls-chain.pem
      - CORE_PEER_LOCALMSPID=MyMemberID # 書き換え必要（コンソールに表示されている）
      - CORE_PEER_MSPCONFIGPATH=/opt/home/admin-msp
      - CORE_PEER_ADDRESS=MyPeerNodeEndpoint　# 書き換え必要

    working_dir: /opt/home
    command: /bin/bash
    volumes:
        - /var/run/:/host/var/run/
        - /home/ec2-user/fabric-samples/chaincode:/opt/gopath/src/github.com/
        - /home/ec2-user:/opt/home

MyPeerNodeEndpointの取得はコンソール上でメンバーのピアノードの詳細から取得もしくは以下のコマンドで取得できます。

$ aws managedblockchain get-node --network-id ${ネットワークID} --member-id ${メンバーID} --node-id ${ノードID}

yamlの作成が完了したら、以下のコマンドでHyperledger Fabric CLIを実行するコンテナを立ち上げます

$ docker-compose -f docker-compose-cli.yaml up -d
## 上がエラーになる場合はこちらを使用
$ sudo /usr/local/bin/docker-compose -f docker-compose-cli.yaml up -d

Step.11 証明書ファイルを作成する

# ${MyRegion}を自分のリージョンに変更して実行する
$ aws s3 cp s3://${MyRegion}.managedblockchain/etc/managedblockchain-tls-chain.pem  /home/ec2-user/managedblockchain-tls-chain.pem

Step.12 管理者ユーザーを登録する

CAエンドポイント（Step.8で取得したもの）・管理者プロファイル・および証明書ファイルを使用してメンバー管理者を登録します。 Step.1で作成したユーザー名とパスワードもここで使用します。

$ fabric-ca-client enroll \
-u 'https://${ユーザー名}:${パスワード}@$CASERVICEENDPOINT' \
--tls.certfiles /home/ec2-user/managedblockchain-tls-chain.pem -M /home/ec2-user/admin-msp

このfabric-ca-clinetコマンドは急に出てきましたが、Step.9でセットアップしたものになります。 fabric-ca-clinetのパスはあらかじめstep.7でbash_profileに登録してあるので、not foundエラーになった場合はsource ~/.bash_profileを実行してください。

このコマンドを実行すると以下のような出力がされます。

/home/ec2-user下で以下のコマンドを実行し、作成された証明書をsigncertsからadmincertsにコピーします。

$ cp -r /home/ec2-user/admin-msp/signcerts admin-msp/admincerts

Step.12 チャンネルのセットアップ

/home/ec2-user下にconfigtx.yamlを作成し、こちらのページのORGANIZATIONSで始まるものをconfigtx.yamlファイルにコピぺしてください。MemberIDと書かれた部分を作成したメンバーのIDに書き換えます。

このconfigtx.yamlはチャンネル構成についての定義ファイルになります。詳細についてはこちらをご覧ください。
以下のコマンドでconfigtxピアブロックを作成します（おそらくブロックチェーン最初のブロックであるジェネシスブロックのこと）

$ docker exec cli configtxgen -outputCreateChannelTx /opt/home/mychannel.pb -profile OneOrgChannel -channelID mychannel --configPath /opt/home/

この時Step.10で作成したcliのコンテナが起動していないとエラーになるので、エラーになった場合はコンテナを起動させます。 また、Step.7での設定を行なってから一度もログアウトしていない場合はpermissionエラーになるので先頭にsudoを付けます。

Step.13 チャンネルの作成

Ordererの環境変数を.bash_profileに設定します。設定したら再度source ~/.bash_profileを実行します。 OrdererはAmazon Managed BlockChainのネットワーク詳細ページのコンソールに表示されています。

Ordererの表示されている場所

以下のコマンドでmychannelというチャンネルを作成します。

$ docker exec cli peer channel create -c mychannel \
-f /opt/home/mychannel.pb -o $ORDERER \
--cafile /opt/home/managedblockchain-tls-chain.pem --tls

以下のコマンドでピアノードをチャンネルに参加させます。

docker exec cli peer channel join -b mychannel.block \
-o $ORDERER --cafile /opt/home/managedblockchain-tls-chain.pem --tls

Step.14 サンプルチェーンコードを実行してみる

ここからサンプルチェーンコードを動かしていきます。今回使用するGoで書かれたサンプルコードはこちらになります。AとBというステートがあり、これらのステートを変更したり、返したりするだけの簡単なコードです。

まずは動かすための準備です。
以下のコマンドでフォルダの所有者を変更し、GoのGO111MODULE環境変数を変更してモジュール対応モードにします。

$ sudo chown -R ec2-user:ec2-user fabric-samples/
$ cd fabric-samples/chaincode/abstore/go/
$ GO111MODULE=on go mod vendor
$ cd -

チェーンコードパッケージを作成します。

$ docker exec cli peer lifecycle chaincode package ./abstore.tar.gz \
--path fabric-samples/chaincode/abstore/go/ \
--label abstore_1

チェーンコードパッケージをピアノードにインストールします。

$ docker exec cli peer lifecycle chaincode install abstore.tar.gz

インストールが成功しているかチェックします。

$ docker exec cli peer lifecycle chaincode queryinstalled

成功している場合以下のようなものが表示されます。ここで返されたPackage IDは次のコマンドで使用します。

チェーンコードを承認します。

$ export CC_PACKAGE_ID=MyPackageID # 先ほどのPackage ID
$ docker exec cli peer lifecycle chaincode approveformyorg \
--orderer $ORDERER --tls --cafile /opt/home/managedblockchain-tls-chain.pem \
--channelID mychannel --name mycc --version v0 --sequence 1 --package-id $CC_PACKAGE_ID

コミットの準備状況の確認をします。コミット準備ができている場合trueが返されます。

$ docker exec cli peer lifecycle chaincode checkcommitreadiness \
--orderer $ORDERER --tls --cafile /opt/home/managedblockchain-tls-chain.pem \
--channelID mychannel --name mycc --version v0 --sequence 1

チェーンコードをコミットします。

$ docker exec cli peer lifecycle chaincode commit \
--orderer $ORDERER --tls --cafile /opt/home/managedblockchain-tls-chain.pem \
--channelID mychannel --name mycc --version v0 --sequence 1

チェーンコードの確認をします。

$ docker exec cli peer lifecycle chaincode querycommitted \
--channelID mychannel

正常にコミットされている場合、以下のようなものが返ってきます。

以下のコマンドでチェーンコードの初期化を行ない、AとBというステートをそれぞれ100と200という値で初期化します。

$ docker exec cli peer chaincode invoke \
--tls --cafile /opt/home/managedblockchain-tls-chain.pem \
--channelID mychannel \
--name mycc -c '{"Args":["init", "a", "100", "b", "200"]}'

queryで初期化されたAの値を確認します。正常に初期化されている場合、100という値が返されます。

$ docker exec cli peer chaincode query \
--tls --cafile /opt/home/managedblockchain-tls-chain.pem \
--channelID mychannel \
--name mycc -c '{"Args":["query", "a"]}'

次にinvokeを行います。Aには-10 Bは+10を行うことになります。
チェーンコードが正常に呼び出されると、status: 200と書いたレスポンスが返ってきます。

$ docker exec cli peer chaincode invoke \
--tls --cafile /opt/home/managedblockchain-tls-chain.pem \
--channelID mychannel \
--name mycc -c '{"Args":["invoke", "a", "b", "10"]}'

最後にAのステートを確認してきちんとinvokeの処理が行われAのステートの値が90になっているか確認します。

$ docker exec cli peer chaincode query \
--tls --cafile /opt/home/managedblockchain-tls-chain.pem \
--channelID mychannel \
--name mycc -c '{"Args":["query", "a"]}'

Step.15 メンバーの招待

ここから２つ目のアカウントを使用していきます。まずは２つ目のAWSアカウントのIDが必要なのでメモしておいてください。
１つ目のアカウントのAmazon Managed BlockChainコンソールからメンバーの追加の提案を行います。まだこの時点ではメンバーが自分一人しかいないために、自分で提案して、その提案を自分で承認することになります。

以下の画面で招待の提案を作成します。ネットワークに招待するアカウントIDに２つ目のAWSアカウントIDを入力し、作成します。

招待の提案

次に提案の投票を行います。 １つ目のアカウントのAmazon Managed BlockChainのコンソールのネットワーク>提案>アクティブで先ほどの作成した提案をクリックすると以下の画面が現れます。 ここで「はい」を選択し、投票を確認します。

提案の投票

2つ目のアカウントでログインしAmazon Managed BlockChainに移動します。招待のメニューに遷移すると招待が届いているので「招待の承諾」をクリックします。

招待の承諾

次の画面でStep.1と似た形で、メンバーの名やCA管理者のユーザー名とパスワードを入力し、メンバーを作成します。（CA管理者のユーザー名とパスワードはこちらも後で使用するのでメモをしておいてください。）

Step.16 ２つ目のアカウントでのセットアップ

2つ目のアカウントでも1つ目のアカウントと同様にセットアップが必要です。Step.2のVPCエンドポイントの作成からStep.11の証明書ファイルの作成まで行います。

Step.17 ネットワーク管理者にArtifactsと情報を共有する

２つ目のアカウントで作成された管理証明書とルートCA証明書が必要になります。
管理証明書はEC2上の/home/ec2-user/admin-msp/admincertsディレクトリに保存されています。
ルートCA証明書が必要で/home/ec2-user/admin-msp/cacertsに保存されています。

これら２つのファイルを１つ目のアカウントにorg2-msp/admincertsとorg2-msp/cacertsというフォルダを作成してそれぞれコピーしてきます。

$ mkdir /home/ec2-user/org2-msp
$ mkdir /home/ec2-user/org2-msp/admincerts
$ mkdir /home/ec2-user/org2-msp/cacerts

Step.18 チャンネルの作成（２）

またチャンネルを作成していきますが、今回はマルチメンバーになるので、configtx.yamlの中身が変わります。こちらのStep.8.6: Create configtx for the Multi-Member Channelのyamlファイルの中身をコピーしてきて、１つ目のアカウントの既存のconfigtx.yamlを上書きします。
Org1MemberIDとOrg2MemberIDを１つ目のアカウントのメンバーID、２つ目のアカウントのメンバーIDにそれぞれ書き換えます。

１つ目のアカウントのEC2上で以下のコマンドを実行し、configtxピアブロックを生成します。

$ docker exec cli configtxgen \
-outputCreateChannelTx /opt/home/ourchannel.pb \
-profile TwoOrgChannel -channelID ourchannel \
--configPath /opt/home/

こちらも１つ目のアカウントのEC2上で以下のコマンドを実行し、チャンネルを作成します。

$ docker exec cli peer channel create -c ourchannel \
-f /opt/home/ourchannel.pb -o $ORDERER \ 
--cafile /opt/home/managedblockchain-tls-chain.pem --tls

両方のアカウントのEC2上で以下のコマンドを実行し、それぞれジェネシスブロックを取得します。

$ docker exec cli peer channel fetch oldest /opt/home/ourchannel.block \
-c ourchannel -o $ORDERER \
--cafile /opt/home/managedblockchain-tls-chain.pem --tls

両方のアカウントのEC2上で以下のコマンドを実行し、それぞれのピアノードをチャンネルに参加させます。

$ docker exec cli peer channel join -b /opt/home/ourchannel.block \
-o $ORDERER --cafile /opt/home/managedblockchain-tls-chain.pem --tls

Step.19 サンプルチェーンコードの実行してみる（２）

２つ目のアカウントにもチェーンコードのパッケージ作成、チェーンコードのインストールを行います。(Step.14と同じです。)

$ sudo chown -R ec2-user:ec2-user fabric-samples/
$ cd fabric-samples/chaincode/abstore/go/
$ GO111MODULE=on go mod vendor
$ cd -
$ docker exec cli peer lifecycle chaincode package ./abstore.tar.gz \
--path fabric-samples/chaincode/abstore/go/ \
--label abstore_1
$ docker exec cli peer lifecycle chaincode install abstore.tar.gz
$ docker exec cli peer lifecycle chaincode queryinstalled

チェーンコードの定義をそれぞれのアカウントで承認します。

$ export CC_PACKAGE_ID=MyPackageID # 一つ目のアカウントの環境では変数設定済み
$ docker exec cli peer lifecycle chaincode approveformyorg \
--orderer $ORDERER --tls --cafile /opt/home/managedblockchain-tls-chain.pem \
--channelID ourchannel --name myjointcc --version v0 --sequence 1 --package-id $CC_PACKAGE_ID

どちらかのアカウントでチェーンコードのコミット準備の確認を行います。それぞれのmemberでtureになってることを確認します。

$ docker exec cli peer lifecycle chaincode checkcommitreadiness \
--orderer $ORDERER --tls --cafile /opt/home/managedblockchain-tls-chain.pem \
--channelID ourchannel --name myjointcc --version v0 --sequence 1

チェーンコードのコミットをどちらかのアカウントで行います。

$ docker exec cli peer lifecycle chaincode commit \
--orderer $ORDERER --tls --cafile /opt/home/managedblockchain-tls-chain.pem \
--channelID ourchannel --name myjointcc --version v0 --sequence 1

どちらかのアカウントで、前回と同様にチェーンコードの初期化します。AとBのステートをそれぞれ100と200で初期化します。

$ docker exec cli peer chaincode invoke \
--tls --cafile /opt/home/managedblockchain-tls-chain.pem \
-C ourchannel \
-n myjointcc -c '{"Args":["init", "a", "100", "b", "200"]}'

別のアカウントでステートの確認をしてみます。

$ docker exec cli peer chaincode query -C ourchannel \
-n myjointcc -c '{"Args":["query","a"]}'

ちゃんと初期化した100になってます。

チェーンコードの呼び出しを行います。ここでは両方のアカウントのPeerEndpointが必要になるので、既出のaws managedblockchain get-nodeのコマンドで取得します。

$ docker exec cli peer chaincode invoke \ 
-C ourchannel -n myjointcc -c '{"Args":["invoke","a","b","10"]}' \
--peerAddresses Org1PeerEndpoint \
--tlsRootCertFiles /opt/home/managedblockchain-tls-chain.pem \
--peerAddresses Org2PeerEndpoint \
--tlsRootCertFiles /opt/home/managedblockchain-tls-chain.pem \
-o $ORDERER --cafile /opt/home/managedblockchain-tls-chain.pem --tls

改めて、Aのステートを確認するために、以下のコマンドを別のアカウントで試してみます。

$ docker exec cli peer chaincode query -C ourchannel \
-n myjointcc -c '{"Args":["query","a"]}'

ちゃんと100-10で90になっています。これでマルチメンバーの時のチェーンコードの実行も確認できました。

後始末について

Amazon Managed Blockchainのコンソール上でそれぞれのアカウントから、自分のアカウントのメンバーを消すことができます。それぞれのメンバーを両方消すことによって自動的にネットワークも削除されました。

料金について

Amazon Managed Blockchainにかかった費用は一アカウント一日9ドルぐらいでした。ここにプラスでHyperlender Fabric クライアントのEC2インスタンスの料金がかかります。

まとめ

今回、Amazon Managed BlockChainを使ってHyperledger Fabricに入門してみました。 AWSのサービスで使用するまでに、こんなに手順が長いサービスは他にないんじゃないかというぐらい長かったです。いや本当に長い。。 今回は簡単なサンプルコードを動かしただけですが、次はLambdaなどを使ってサーバーレスブロックチェーンアプリケーションを作ってみたいなと思っています。

告知

株式会社ABEJAでは共に働く仲間を募集しています。興味ある方はぜひこちらの採用ページからエントリーください。

hrmos.co

参照

• OCHaCafe #4 Hyperledger Fabric - Speaker Deck
• ピア — hyperledger-fabricdocs master ドキュメント