Hyperledger Fabric v1.4.1でRAFTのOrdering Serviceをサポート
3/29付でHLF v1.4.1のRC（Release Candidate）1がリリースされ、RAFTのOrdering Serviceサポートが含まれています。まだRC版なんで正式リリースじゃないんですが下記の通りドキュメントにも先んじて追記されてるしまあたぶん撤回されたりはしないでしょう
■HLF v1.4.1 RC1 リリースノート： Release v1.4.1-rc1 Release Notes - March 29, 2019 · hyperledger/fabric · GitHub
既に公式ドキュメントにもRAFT Ordering Serviceの説明が追加されていました。
■RAFT Ordering Serviceの説明： The Ordering Service — hyperledger-fabricdocs master documentation
これまで選べたSoloおよびKafkaはOrdererノードをひとつの組織（Organization）が独占することを（事実上）前提としていますが、RAFTは複数組織間でOrdererノードを分散させることが可能とされています。ていうかわたしはRAFT Ordering Serviceもひとつの組織がOrdererノードを独占するものだと思ってましたが違っていた、そのような説明を受けた方々すまんかった
RAFT自体のお勉強は以下の資料がわかりやすいと思いました。Paxosよりも百倍わかりやすいと言われるRAFTですが、まあまあ難しいです。でもまあFabricのコンセンサスを完全に理解している俺たちにはどうということはなかったぜ
RAFTそのものがBFT（Byzantine Fault Tolerant）ではなくCFT（Clash Fault Tolerant）なため、RAFT Ordering ServiceもBFTではないことには注意が必要です。そのうちBFT Smartを採用したOrdering Serviceも出るはずです。Ordering ServiceにBFT性が求められるような互いへのトラストが低いコンソーシアムの運用を考えている場合はBFT Smartが早くサポートされるように祈りましょう。
気になるのは速度（スループット）がどんくらい出るかデスヨネー。おそらくはKafkaよりもRAFTのほうがオーバーヘッドが多くて遅いでしょうというのと、OrdererノードをOrganization分散して持った場合にはネットワーク遅延がけっこう効いてきそう。コンソーシアムのトラストのあり方と求められるスループットを考慮してKafka、RAFTそしてBFT SmartからOrdering Serviceを選びましょうね、ということになるんでしょうね
