ブロックチェーンのアカウント仕様の紹介
はじめに
ブロックチェーンスタジオでは、ブロックチェーンを用いたサービスの研究開発のため、ブロックチェーン基盤に関する調査検討を行っています。今回は、いくつかのブロックチェーンのユーザアカウントの仕様について、調査した内容を紹介します。
共通仕様
ブロックチェーンでは、多くの場合、イベントの発火(トランザクション)に対して「誰が」「何を」実行したのかという情報を紐づけるため、電子署名の仕組みを利用しています。このため、ブロックチェーンを利用するユーザは、基本的に個別の「秘密鍵」と「公開鍵」と呼ばれる暗号化のための鍵を持っています。この「秘密鍵」と「公開鍵」についての説明は、この記事の公開鍵暗号方式を参照してください。
なお、基本的には、秘密鍵をトランザクションの署名に利用するため、秘密鍵を漏れるとトランザクションを実行されてしまうリスクがあります。
Bitcoin/Ethereum…etc
概要
Bitcoinをはじめ、ほとんどのブロックチェーン基盤で用いられているアカウントは、秘密鍵と公開鍵のペアに対して1つのWalletアドレスを持っており、この3つの組み合わせが1つのアカウントとして管理されます。ちなみに、この3つの組み合わせですが、秘密鍵から公開鍵が生成され、公開鍵からWalletアドレスが生成されるため、秘密鍵さえ紛失しなければ復元可能になっています。
Mnemonic
Mnemonicは、ブロックチェーンの秘密鍵を生成する規格の1つであり、英数字の文字列である秘密鍵を人が理解できる文字列の組み合わせから生成・復元できるようにした仕組みです。これは、秘密鍵のバックアップをする際に、バイナリや16進数の文字列を扱うのではなく、人が読めて覚えることができる単語を組み合わせることでバックアップできることを目指して実装されています。BitcoinとEthereumの場合、BIP(Bitcoin Improvement Proposals)39に仕様としてドキュメント化されています。
HD(Hierarchical Deterministic) Wallet
HD Walletは、特定の暗号鍵から別の暗号鍵を階層構造的に作成することができる仕組みです。この仕組みを図示したものは以下のようになります。
このHD Wallet自体は、秘密鍵が盗難されるリスクを分散するために複数のアカウントを保有するといった手段を取っているユーザの鍵管理を簡易化する仕組みとして実装されています。BitcoinとEthereumの場合、BIP32、BIP43、BIP44で仕様としてドキュメント化されています。
EOSIO
概要
EOSIOのアカウントは、秘密鍵と公開鍵のペアではなく、12文字のユニークなアカウント名で管理されています。また、各アカウントには、後述のPermission管理の仕様に従い、複数の秘密鍵と公開鍵が紐づけることが可能になっており、トランザクションに署名時にどの鍵を利用するのか指定することになります。
各EOSIOアカウントは、EOSIO基盤内にNET、Disk、CPU、RAMと呼ばれるコントラクト実行用のリソースを確保しておく必要があります。
- NET：コントラクト実行のためのネットワーク帯域
- Disk：コントラクトのログ(ブロック、トランザクション)を保存するリソース
- CPU：コントラクトを実行するリソース
- RAM：保有するトークン数のようなアプリケーションからアクセスされる情報を保存するリソース
このため、EOSIOでは、リソース確保やアカウント名の登録をするためのトランザクションを発生させる必要があります。よって、EOSIOを利用するには、既存のユーザにアカウントを登録してもらう必要があります。
また、このコントラクト実行用のリソースは、アカウント作成時はアカウントを作成したユーザの一部が割り当てられてます。この状況は、アカウント保有者がEOSIOトークンをEOSIOに預ける(staking)ことで、EOSIO内にアカウントの実行用リソースを正式に確保するまで継続されます。
アカウントのPermission管理
EOSIOのアカウントは、「declarative permission management system」と呼ばれるPermission管理システムが存在します。このPermission管理システムの図は下記のようになっています。各ユーザは、コントラクトの実行権限を定義したロールをアカウント内に明示的に設定し、このロールに単数、もしくは複数の鍵を紐づけてトランザクションを発行させることができます。
ちなみに、EOSIOでは、デフォルトのロールとして、「OWNER」と「ACTIVE」の2つが宣言されています。このうち、「OWNER」のロールは、アカウントの管理者権限を持っており、すべての実行権限を持つため、「OWNER」ロールの秘密鍵を盗まれるとアカウントが乗っ取られることになります。一方で、「ACTIVE」のロールは、「OWNER」に割り当てられている鍵を変更すること以外のことを実行することができるロールとなっています。
また、その他のロールについては、アカウント保有者が名前とPermissionを設定することができ、これらはすべて「ACTIVE」グループの下位の階層となっており、「active」の権限のうち、一部(もしくは全て)を明示的に割り当てる仕様となっています。例えば、上記の図では、「FAMILY」は「ACTIVE」の権限のうち、「EXCHANGE」と呼ばれるコントラクトの実行権限のみ割り当てられているため、他のコントラクトは実行することができなくなっています。このため、一部の限定されたPermissionしか持たないロール作成し、これをデバイスに埋め込む等ができるため、安全なアカウントの管理が可能になっています。
Hyperledger Fabric v1.X
概要
Hyperledger Fabricは、PermissionChainであり、権限のないユーザがアカウントを作成できないようにするため、PKIの仕組みを用いてアカウントを管理しています。また、Hyperledger Fabricの場合、このPKIの仕組みでシステムにおける各組織のPermission管理をしているため、ユーザの他に下記のようなシステム構成ノードにもアカウントが設定されています。(なお、システム全体としては、所属グループを管理するチャンネルという仕組みが別途存在します。)
- FabricCA: 組織ごとのPKIを管理するノード
- Peer: トランザクションの発行／検証やブロックの保持を行うノード
- Orderer: トランザクションを元にブロックを生成し、Peerへ送付するノード
アカウントの識別
各組織ごとにEnrollmentIDと呼ばれるユーザIDで管理されており、このユーザIDに対して秘密鍵と公開鍵の他、ユーザ証明書が紐づいています。
なお、このユーザ証明書には、CSR(Certificate Signing Request)の情報や、ユーザの権限等が付与されており、アプリケーションやChaincodeから各アカウントの付帯情報を参照することもできます。
アカウントの作成方法
Hyperledger Fabricでは、新規アカウントを作成・利用するには、以下の手順で行います。
- 【初期セットアップ】各組織に管理者権限をもつアカウントを予め作成
- 管理者権限をもつアカウントでFabricCAにパスワード認証し、秘密鍵とユーザ証明書を取得
- 新規ユーザのパラメータとして、以下を設定し、FabricCAに登録
- EnrollmentID
- EnrollmentSecret
- パスワード認証の回数(無制限に設定可能)
- 権限(新規アカウントの作成、中間CAの作成許可等)
- ユーザの属性
- EnrollmentID/EnrollmentSecretを用いてパスワード認証し、秘密鍵とユーザ証明書を取得
アカウントの失効
Hyperledger Fabricは、PermissionChainのため、管理者が特定のアカウントを失効する仕組みがCRL(Certification Revocation List)を用いて実装されています。FabricCAは、アカウントの失効リクエストを受け付けると、指定されたEnrollmentIDのユーザ証明書を失効するCRLを作成し、自身が管理している組織のPeerに対してCRLを発行し、更新させることができます。この影響で、失効されたユーザ証明書をもつアカウントは、Peerに対してトランザクションを検証させることができなくなります。
おわりに
ブロックチェーンのアカウント仕様については、分散性を保ちながら、どこまで基盤側の機能として提供するのか、という部分で各基盤で方針があるのかなと思いました。特に、EOSIOの仕様のうち、コントラクトの実行権限を一部委譲してトランザクションの実行を一部許可する仕様は、Gasを定期的に補充する必要なくデバイスから一定時間ごとに何かを実行させるようなサービスを実現することが可能になるため、応用性が広がりそうだと感じました。ただ、ユーザ側からしか設定することができず、コントラクト作成者がユーザを限定する(アカウントの購入が必要等)ようなロール作成ができる方が、サービス提供側の汎用性が広がるのではないかと思います。
参考
Author
