はじめに
冒頭からタイトルと反対のことを言うが・・・
実際は（特にSellingMessageとしては）広義のブロックチェーンと言っても良いと思う。
日本ブロックチェーン協会(JBA)の定義にある
１）「ビザンチン障害を含む不特定多数のノードを用い、時間の経過とともにその時点の合意が覆る確率が0へ収束するプロトコル、またはその実装をブロックチェーンと呼ぶ。」
２）「電子署名とハッシュポインタを使用し改竄検出が容易なデータ構造を持ち、且つ、当該データをネットワーク上に分散する多数のノードに保持させることで、高可用性及びデータ同一性等を実現する技術を広義のブロックチェーンと呼ぶ。」
こちらの２番目を満たしていると思われるからだ。
しかし、その上でfabricの仕組みを知れば知るほど、気になる点もある。
簡単に（そして結構乱暴に）言えば、
Fabricは（ブロックチェーンとは無関係の）分散データ配置の仕組みを有し
最終的に各ノード(Peer)に配置するデータの出力形式をブロックチェーン形式にしているに過ぎないからだ。
（なので分散台帳なのだが）
以下にその仕組みを簡単に説明する。
１．データの分散配置の仕組みはあくまでkafka
実際は、データの分散配置に何を用いるかはアダプタブルな設計となっており
soloモードなども有しているが事実上、一定の可用性を担保しようとした場合は
少なくともこの記事を記載した2018年3月時点では、kafka一択になる。
２．コアデータがそもそもブロックチェーンではない
fabricで最も大切なデータは、
各ノード（Peer）に配置されるブロックチェーンのバイナリデータではなく
kafka（およびOrderer）が保持しているトランザクションリストデータだ。
ここには、今まで実行されたトランザクションの内容が
実行順に並べられ全て記録されている。
新規にブロックチェーンノード(Peer)を追加する場合、
Fabricは別のPeerからデータを持ってくるわけではなく
実際はこのトランザクションリストデータをもとに
先頭から最新までのトランザクションを順番に実行してブロックチェーンデータの作成を行う。
『ブロックチェーンノード（Peer）のデータだけ残っていても
fabricでそのネットワークを復旧させるのは容易ではない』
あるいは
『fabricでは（ブロックチェーン形式ではない）kafkaのデータさえ保全していれば
ブロックチェーンノード（Peer）が仮に全滅したとしても、
簡単にネットワークを復旧させることができる』
とも言える。
３．ネットワークセグメントを超えたOrdererのクラスタ構成は現実的ではない
Ordererはkafkaのトランザクションリストデータを（重複して）保持し、
ネットワークで『唯一』となるようにトランザクションの実行順序を制御している。
コンソーシアム等で異なるネットワークセグメントでOrdererを繋ぐということは、
例えばCPUの制御に、わざわざレイテンシの大きい回路を採用するのと同じだ。
Ordererは通常同じネットワークセグメントのなかでのみ構築すべきだ。
（※ 公式見解ではなく、個人の意見です）
fabric的には
CAを持つところがパワーのある参加者だというイメージがあったが
実際は、Ordererを集中管理する参加者こそが
もっともパワー（主導力・影響力）のある参加者かもしれない。
４．まとめると
fabricが扱うデータの本体はあくまでトランザクションリストであり、
ブロックチェーンはそこから二次的に生成される参照用データでしかない（言い過ぎか・・・）
ブロックチェーンの内容自体が各Peerで異なるケースさえあるかもしれない。
サービスからの要求時には失敗していたトランザクションが
Peer復旧時の再実行では成功してブロックチェーンの内容が変わることも推定はできる。
ただし、復旧前に失敗トランザクションで終わっているデータがない限り
最終的に全てのトランザクションが成功すれば
ワールドステートの値は復旧前後で変わらず、整合性は保てる
５．コンセンサスアルゴリズム（おまけ）
ブロックを積むのに多大なハッシュレートを求められるPoWでは
（一定以上のネットワークの規模では）
最長のチェーンが常に正しいという極めてシンプルな約束事が成立する。1
しかし、トレードオフとして書き込み時点のファイナリティもなく
多大な電力の消費と低いスループットという課題がある。2
Ordererが実行順序（とトランザクションのコミット要求）を制御している限り
fabricは「基本的には」全てのノードのブロックチェーンは常に同一であり、また同じ長さになる。
これは書き込み時点のファイナリティがあることを示すし
fabricのブロックチェーンも当然ハッシュポインタ方式なので
（ネットワークに侵入されないという前提条件付きだが）改竄検出容易性も備えるだろう。
６．最大の魅力はスマートコントラクト
とはいえ、例え上記のような構成であったとしても
fabricにはスマートコントラクトという大きな魅力がある。
恐らく、同じくスマートコントラクト機構を持つイーサリアムとfabricは
『少なくともこれから先しばらくの間は』共存していくだろう。
それは両者の特徴が結構異なるからだ。
全部上げるのは大変なので、いくつかあげてみる。
コンセンサスアルゴリズムの違い
イーサリアムはPoWコンセンサスアルゴリズムを持つ（将来的にはCasperと言う懲罰的PoSへ移行）
なので本家ネットワークに繋げば、ERCトークンなどの発行に使える（fabricでは無理だろう）
ローカルネットワークで運用する場合は、難易度調整できるとはいえマイニングが必要になる
小さなネットワークでは、低いハッシュレートで簡単に最長のチェーンが作れるため
公開ポリシーを間違えるとPoWによる改ざん耐性など機能せず、一瞬で覆される可能性もある。
スマートコントラクトコードのアップデートに関する違いがある
fabricは比較的容易にチェーンコードをアップデートできるが
イーサリアムではスマートコントラクトのアップデートはできない。これにはこれで、コードの不変性（信頼性）などのメリットもあるが
名前とアドレスを管理するコントラクトを別に作るパターンが事実上必須になるなど
fabricと比較すると設計面での敷居は高いと考えた方が良い。
秘匿性に関する注力具合が違う
現時点では、マルチチャネルコンセンサスなどfabricの方が注力度が高い。
もっともイーサリアムでもそのうちそうした仕組みは提供されてくるかもしれない。
秘匿性に関してはトランザクションデータの設計次第である程度どうにでもなる、という側面もある。
スループット（スケーラビリティ）の違い
コンセンサスアルゴリズムの違いによるものではあるが
fabricは現時点ではイーサリアムよりはスループットは高くできるだろう。3