（3）エンタープライズに適した決済の確定性を保つ仕組みを持つ

　ビットコインで用いられる分散合意のアルゴリズム「PoW（Proof of Work）」はノード数が数千台という超大規模なP2Pネットワークを実現できる一方で、計算に掛かるコスト（消費電力）が大きく、決済が確率現象となり厳密な意味では結果が確定しない（この特性は「確率的ビザンチン合意」と呼ばれることもある）。こうした性質はエンタープライズシステムに適用する際のネックとされている。

　この問題を解消するために、Hyperledger Fabricでは「確定的な挙動の分散合意アルゴリズム」を搭載することで、金融分野で求められる「ファイナリティ（決済の確定性）」を保つ。ただし、確定的な合意形成アルゴリズムを使うことの代償として、合意に参加できるノード数の上限の数が小さくなる。ビットコインのように「数千ノードに冗長化された絶対に消えない台帳」を作れる訳ではない。

　Hyperledger Fabric v0.6では、分散合意アルゴリズムとして「PBFT（Practical Byzantine Fault Tolerance：実用的ビザンチン・フォールトトレラント・アルゴリズム）」を実装、間もなく登場する「Fabric v1.0」では、その改良版（詳細は後述）を搭載する予定だ。

（4）柔軟に実装できるスマートコントラクトの仕組み（Chaincode）

　ブロックチェーンにおけるスマートコントラクトとは、ブロックチェーンの上で管理されて自動執行されるプログラムを指す言葉だ。Hyperledger Fabricの用語では「Chaincode」と呼ぶ。

　ビットコインでは、送金機能を標準搭載する一方、他の機能の追加は簡単にはできない。一方のHyperledger Fabricは、送金などの機能をChaincodeを使って各自が作り込んでいく設計思想になっている。ちなみに、FabricのChaincodeは、GoまたはJavaで開発できる。また、ChaincodeはDockerコンテナ上で稼働する。

　　以上のことを踏まえて要約すると、「Hyperledger Fabricはプログラムを作り込める柔 軟性があり、挙動が確定的な分散型台帳管理システムを目指している」といえる。ビットコインのように仮想通貨とセットになったパブリックブロックチェーンとは大きく異なる設計思想だといえる。

　ビットコインのブロックチェーンでは仮想通貨の管理や送金は標準機能だが、Hyperledger Fabricではエンタープライズシステムのミドルウェアを意識しており、システムごとに処理のロジックを設計しChaincodeとして実装する。前述した「確定的な挙動」の合意形成アルゴリズムを使っているために、決済処理の挙動が確率的になることはないが、ビットコインのように大規模な冗長化には向かない。規模が大きなネットワークを作る場合には工夫が必要となる。

　このHyperledger Fabricは、間もなくGA（General Availability）版がリリースされる予定だ。特に合意形成アルゴリズムの並列処理対応によりトランザクション処理性能が大幅に改善する見込みだ。