まとめ
Web Application
- リソース中心, READ負荷高, 複雑な整合性, クライアント&サーバ通信
- →RDB, REST, HTTP
Blockchain
- 手続き中心, WRITE負荷高, 単純な整合性, P2P・双方向
- →KVS(embedded), RPC, P2P
DBについて
ブロックチェーンでよく使われるDBはLevelDB, RocksDB, ParityDB。全てKVS and embedded。
why embedded database? → 高速, 高ポータビリティ
（他の用途では、ローカル環境をembeddedにしてテストに使ったり、クライアントサイドのDBで使ったりなど。FaktoryはストレージエンジンにRocksDBを採用している）
これらのKVSはLSM木 (vs. B木)を採用。
RDBは通常B木を採用していて、これが高い整合性とREAD負荷耐性を実現する一方でWRITE負荷耐性が低いというトレードオフを持つ。
いくつかのKVS(NoSQL, NewSQL)はLSM木を採用していて、これがWRITE負荷耐性は高い一方で整合性やREAD速度を犠牲にしている。
RPC vs REST
RESTは標準的なHTTP動詞を使ったリソース (名詞)に焦点を当て、RPCは引数を伴って呼び出されるアクション (プロシージャ)に焦点を当てる。多くのWebアプリケーションの基幹システムはRDB & RESTのようなリソース中心の思想と相性が良い。
一方でブロックチェーンはリソースに還元しにくい手続きが多く存在し（送金実行、署名検証など）、JSON-RPCなどのRPCが好んで採用される傾向にある。サーバ・クライアント方式に限らず双方向通信を多数使うのも特徴である。
P2P
ブロックチェーンはP2P通信をするが、libp2pというライブラリを利用した場合の通信システムを概説する。
初回はブートストラップノードに接続（あらかじめハードコードされた「常に稼働している有名なノード」）。アクティブなピアのリストをもらって保存しておく。
PeerIDのリストをDHT (Distributed Hash Table)に書き込む。libp2pでは主に Kademlia（カデムリア） というアルゴリズムが使う。「近さ」の定義 (XOR距離):物理的な距離ではなく、PeerID（ハッシュ値）がどれだけ似ているかで「距離」を計算する。各ノードが近いノードに高い確率で問い合わせることで、効率よく情報が伝播する。
プログラミング言語の選定
最近はRustが人気。
時間・リソース効率に優位性があるほか、Wasmとしてビルドする形でスマートコントラクトを書ける点（ネイティブコードは実行環境依存になってしまうので共通環境となるWasmを使う）
BitCoinはC++, EtheriumはGo。
ただしブロックチェーンのノードのプログラムは互換性があるため（計算結果が一致すれば機能する）、例えばEtheriumのRust実装で参加することも可能。複数の実装のノードがいることで耐障害性が高まるのではないかという指摘もある。