Hyperledger Fabric v2.0がリリースされたので重要っぽい変更点などまとめてみる
Hyperledger Fabric v2.0が2020/1/29付でリリースされました。メジャーリリースだけあっていくつも重要な機能追加、変更、廃止が入っているのでそのへんを以下にまとめていきます。
読んでおくべき公式の情報
以下3つあります。たぶんこの順で読んでくとわかりやすい。
このブログポストでもこれらを情報ソースとしていますが、個人的に重要と感じたところだけまとめていきます（項目をけっこう省きます）。1点注意してほしいのが、まだ（v2.0 beta含め）v2.0を実機で動かして確認していないので、このポストで書くことは基本的にこれらの情報だけからの理解で書いています。間違っているところとかあったらコメント等で教えてくださいな。
重要っぽい変更点まとめ
Chaincode Lifecycle関連の変更
Chaincodeの初期パラメータの複数Orgでの承認：以前のLifecycleモデルではChaincodeをInstanciateするときに定義するEndorsement Policy、Private Data Collection定義およびChaincodeの初期化関数に渡す引数などのパラメータはInstanciateを実行するOrgが「勝手に」決められた（他Orgが検証してそのパラメータでのInstanciateの是非に関わることができなかった）んですが、当該ChaincodeがChannelで実際にActiveになる前に十分なOrgからの是認を必要とする、といったポリシーを取ることができるようになりました。
より適切なChaincode Upgradeプロセス：これについても以前のLifecycleモデルではあるOrgが「勝手に」Upgrade（新バージョンをInstanciate）のアクションを取ることができた（そして初期パラメータも「勝手に」決められた）、初期パラメータと同様にUpgradeには十分なOrgからの是認が必要、とするポリシーを取ることができるようになりました。
よりシンプルなEndorsement PolicyとPrivate Data Collectionのアップデート：以前のLifecycleではあるChannelで既にActiveになっているChaincodeのEndorsement PolicyやPrivate Data Collectionの定義を変更しようとする場合にはUpgradeのアクションが必要で、Upgradeをするためには前提として（内容的には同一のものでも）Chaincodeを新しいバージョンとしてInstallしておく必要があったんですが、これが要らなくなったようです。Endorsement PolicyとPrivate Data Collectionの定義だけ変更、というアクションが取れるようになった模様。
新しいデフォルトEndorsement Policy：「Channel上に存在するOrgの過半数」というのが特に指定しない場合のデフォルトのEndorsement Policyになりました。以前のLifecycleではOrgを具体的に列挙して指定するかたちのEndorsement Policyしか利用できなかったので、ChannelにOrgを追加した場合、削除した場合に適切なガバナンスを維持するにはEndorsement Policyを定義し直す必要、すなわちUpgradeをする必要があったんですが、このデフォルトEndorsement Policyを利用できる場合は不要になりますね。
Channelメンバー内であるChaincodeのパッケージが同一であることは必須ではなくなった：以前のLifecycleではChaincodeはInstanciate時に各Org配下の当該ChaincodeがInstallされているPeer間でFingerprintの比較が入り、一致していなければInstanciateできなかったため、あるChaincodeのあるバージョンはChannelメンバー間で同一のパッケージをInstallしていることが必須でした。が、このFingerprintチェックがなくなったようです。トランザクション実行時に適切な（Endorsement Policyを満たすだけの）Endorsement（＝同一のChaincode実行結果）が集まっていることでコンセンサスは担保できるので別にパッケージが同一であるかどうかはどっちでもいいということですね*1。これにより、各Orgで自身専用の関数や独自ValidationなどのLocal Fixを加えたChaincodeを自身のPeerで利用することができるようになります。便利ですね。
これらの新しいChaincode LifecycleモデルはChannelのApplication Capabilityをv2.0（以上）にセットすることで有効になります。ということはv1.xにしておけば以前のLifecycleも継続して利用することができるということですね。
以前のバージョンでは考えようによっては運用上ちょっと危なげな局面があり得そうだったChaincode Lifecycleが、ガバナンスを分権化できるようになったことでより安全に運用にできるようにななりました。コンソーシアムでの運用を想定した分散台帳の基盤としてかなり成熟してきたと感じています。
Private Data関連の変更
Collection-Level Endorsement Policyの追加：Private Data Collectionの単位でのEndorsement Policy設定が可能になりました。これを設定しておくと当該Collection内の変更を伴うトランザクションについてはChaincode単位のEndorsement PolicyをオーバーライドしてCollection-Level Endorsement Policyが評価されます。「ChaincodeとしてはOrg1,2,3の過半数というEndorsement Policyが設定されているが、Org1とOrg2の間でPrivateなCollectionに変更を加える場合にはOrg1およびOrg2両方のEndorsementが必須」みたいなことが実現できますね。
暗黙のPer-Organization Collectionの追加：これまではChaincode内の処理の中でPrivate Data Collectionを利用する場合には、常にInstantiate／Upgrade時にCollectionの定義をパラメータとして渡す必要がありました。v2.0では、各Org単独で所持するCollection＝Per-Organization Collectionについてはこの事前定義をしておかなくても暗黙で定義されて使えるようになりました。
_implicit_org_<MSPID>という形式のCollection IDでおもむろにPutPrivateData()およびGetPrivateData()しちゃえば使えます。特にChannelメンバーが増えていくようなときに楽ですね。
Chaincode稼働環境関連の選択肢追加
これまでInstantiateされActiveになったChaincodeはPeerごと×Chaincode（バージョン）ごとに作成されるDockerコンテナ上で稼働していました。v2.0からはDockerコンテナ以外の稼働環境も選ぶことができるようになり、また、必ずしもPeerごとの単位ではなく、外部サービスのかたちで稼働させて複数Peerから共用することができるようになりました。リソース節約とかパフォーマンス向上とかの面で効果のある施策が取れるようになる、また、ライブラリやツールのようなかたちで今後いろいろと出てくると思います。
Docker ImageでAlpine Linuxを使用
Peer、Orderer、およびChaincode稼働コンテナのDocker ImageでAlpine Linuxを使うようになりました。軽量化してリソースが節約できるのと、起動が早くなるそうです。これに伴いBashが使えなくなるのでAlpine Linuxにバンドルされているshかashを使えとのこと。
その他の特に注意が必要っぽい変更とか廃止とか
GoLangのChaincodeでのshimパッケージの手動Vendoring必須化：以前はfabric-chaincode-go/shimのパッケージはPeer内でのChaincodeビルド環境に含まれていたので、GoでChaincode書いてパッケージングするときにはこのshimパッケージは含めなくても（Instantiate時に行われていた）Chaincodeビルドが通りました。が、v2.0からはビルド環境からこのshimが取り除かれたため、手動でVendoringしといてねとのこと。shimにはChaincode書くうえで必須のライブラリが含まれているので気をつけましょう。このshim自動Vendoringは前からDeprecatedのステータスになってたのでメジャーリリースでの廃止は想定どおりですね。
User Chaincode内からのSystem Chaincode呼び出しの廃止：User Chaincodeというのはユーザー側で書くふつうのChaincodeのことですが、それに対してQSCCなどのSystem Chaincodeという予めビルトインされた特殊なChaincodeがあります。このSystem ChaincodeをUser Chaincodeから呼び出せる機能があったんですが、廃止されました。これも以前からDeprecatedのステータスでした。前も書きましたがこの辺これ使ってると過剰に複雑になるので、個人的には廃止は賛成、歓迎です。
ChaincodeがPeerへのInstall時にビルドされるように：以前はChaincodeはInstantiate時にPeerによりビルドされていたんですが、Installの時点でビルドされるように変更されました。これはPeerのバージョンがv2.0以降であれば以前のChaincode Lifecycleを利用している場合も、新しいLifecycleを利用している場合も共通だそうです。結果的にChaincodeのInstallに以前よりも時間がかかること（およびそれにより一旦タイムアウトが発生したというエラーが返ってくるが実際には成功しているケースが発生する可能性があること）には注意が必要です。個人的にはInstantiate時になって初めてビルド失敗してInstallからやり直す羽目になるよりはInstall時に失敗してくれたほうが嬉しいのでこの変更は歓迎です。
SoloとKafkaのOrdering Serviceのコンセンサスタイプは非推奨：依然サポートはされていますが非推奨、将来的に廃止されるかもというステータスです。Raft使いましょう。
*1:そもそもLSCC=Lifecycle System Chaincodeを変更しておくなどすればFingerprintチェックをお行儀悪くバイパスすることはもともとできたのであんまり実効性がなかったし、それもあって不要ということになったのかなと
