今一度、"愛記"について記載を開始したい。どのように実装していけばよいのか、概念的なところからアプローチ方法を記載していく。

システム評価とは、このシステムを導入して成功だったか失敗だったかという効果検証という意味だ。概念設計をする上で必ず抑えておくべきポイントということだ。それには各項目があり、それぞれの項目を見ていくことで、その結果が得られる。そのシステム評価項目を1つずつ見ていきたい。

システム構築の品質評価のポイント1：理解可能性（Understandability）

システム構築の品質評価のポイント2：完全性（Completeness）

システム構築の品質評価のポイント3：簡潔性（Conciseness）

システム構築の品質評価のポイント4：移植性（Portability）　

システム構築の品質評価のポイント5：一貫性（Consistency）と構造化の度合い　

システム構築の品質評価のポイント6：保守性（Maintainability）

システム構築の品質評価のポイント7：試験性（Testability）

システム構築の品質評価のポイント8：ユーザビリティ（Usability）

システム構築の品質評価のポイント9：効率性（Efficiency）

システム構築の品質評価のポイント10：セキュリティ（Security）

システム構築の品質評価のポイント4：移植性（Portability）

システム構築の評価に繋がる移植性とは、異なるブロックチェーン間の相互運用性を意識し、アプリケーションの移植性や互換性を加味してシステム設計を行うことが肝要であるということだ。というのも、パブリックブロックチェーンは、インセンティブ不整合と呼ぶ問題を抱えている。つまり、ブロックチェーンを支えるノード群とブロックチェーン上アプリケーションに共通の動機がないのである。アプリケーションは、ブロックチェーンが提供する存在証明といった能力を活用したい。一方で、ブロックチェーンを支えるノード群、その運用者（マイナー）は、ただただコイン（愛貨）が欲しいだけであり、ブロックチェーンの能力はそうした経済的な動機に支えられている。それゆえ、ノード群に対して経済的な動機を与えられないパブリックブロックチェーンは、トランザクションの安全な承認ができない。

例えば、コイン（愛貨）の価値低下はノード群の離脱を招き、ひいては承認能力の低下を招き、様々な攻撃に対して脆弱となる。アプリケーションとノード群の動機を整合させられればそれに越したことはない。しかしその方法は知られておらず、未解決問題である。せめて、依って立つブロックチェーンが危うくなった際に他のブロックチェーン上に脱出できれば、アプリケーションは破綻を免れる。そうした移行を可能とするミドルウェアの構成法や移行の手順を考えておきたい。以下、こちらより抜粋。

2 アプリケーション移植性の恩恵

移植性は，パブリックとプライベートブロックチェーン，双方のアプリケーションにとって，それぞれ理由は異なれど，望ましい性質である．

2. 1 パブリックブロックチェーンのアプリケーション

パブリックブロックチェーンでは，トランザクションの承認は Proof of Workやその派生形である Proof of Stake，Proof of Elapsed Time等によって達成されており，そうした機構はノード群の経済的な動機に基づく．ノード群はただコインを稼ごうとしているだけであり，アプリケーションを支えるという動機は持たない．パブリックブロックチェーンは，ノード群に対して充分な経済的動機を与えそこねると，トランザクションを安全に承認することができなくなる．アプリケーション移植性は，この問題への暫定解となる．もし，移植性，特に移行可能性があれば，ブロックチェーンが機能不全に陥りそうな状況でも，アプリケーションを他のブロックチェーンに移行できる．

2. 2 プライベートブロックチェーンのアプリケーション

移植性は，プライベートブロックチェーン上のアプリケーションにとっても望ましい性質である．移植性が低いと，いわゆるベンダロックインを被ることとなる．例えば，アプリケーションとその利用者は，より良い他のミドルウェアの恩恵を受けられない．悪いと，ミドルウェアと共にアプリケーションも死んでしまう．ここで言う死とは，古さが原因でミドルウェアを実行できくなる，という意味である．

3．アプリケーション移植性

アプリケーション移植性にはいくつかのレベルがある．以降，次の 2 レベル（図 2）を区別して扱う．

1. “動作可能（runnable）”：アプリケーションは異なるブロックチェーンの上で動作し得る．あるブロックチェーンから他への移行はできない．

2. “移行可能（migratable）”：アプリケーションとそのデータをあるブロックチェーンから異なるブロックチェーンへ移行できる．

ブロックチェーン群に共通する API があれば，“動作可能” レベルの移植性が達成される．また，同一のミドルウェアで運用される別ブロックチェーンの間で移植性があることは自明であろう．一方，異種ミドルウェアに対して，機能する共通API を策定できるかどうかは定かではない．各ミドルウェアはそれぞれの抽象化を採用しているからである．例えば，あるミドルウェアはブロックのハッシュチェーンの代わりに有向非巡回グラフ（DAG）を採用しているし，各ミドルウェアはそれぞれ自身のスマートコントラクト機構を持っている．しかし，もし，アプリケーションが利用するブロックチェーンの機能を限定し，限定した機能に対して共通 API を用意できたなら，移植性を達成できる．どのようなブロックチェーンもハッシュ値をタイムスタンプ付きで格納する程度の機能は持っており，このための共通 APIくらいは用意できる．

移植性が “動作可能” レベルにとどまる場合，別ブロックチェーンへ移行するアプリケーションはその初期状態での再起動しかできず，蓄積したデータは捨てざるを得ない．データの存在証明と状態変化の検証はブロックチェーンの特徴的な機能であり，それを可能にするログを伴わない移行ではほとんど意味がない．“移行可能” レベルの移植性が，プライベートブロックチェーンミドルウェアの喪失やパブリックブロックチェーンの機能不全を乗り越えてのアプリケーションの生存を可能にする．

4 アプリケーションのブロックチェーン間移行

では，どのようにしてアプリケーションのブロックチェーン間移行を達成するかの設計案を示す。

4. 1 移行対象データ

どういったデータをブロックチェーン間移行の対象とすべきか？アプリケーションがブロックチェーンに依存しないものであって，ミドルウェア間で移行する場合，たいていは，アプリケーションの最新状態，例えば関係データベース中のレコード，さえ移行すれば充分である．しかし，ブロックチェーンを採用する強い動機の１つは，過去のある時点であるデータが存在したことを証明できることや，状態（データ）の変化を検証できること，である．この場合，最新状態だけを移行したのでは不足である．存在証明や検証に必要なログの移行も必要である．つまり，移行の対象となるデータには次の 2 つのクラスがある．

1. アプリケーションの最新状態

2. ログ – 状態についてのメタデータであり，状態変化とそのタイムスタンプから成る．

例えば，Bitcoin のような貨幣アプリケーションでは，前者は口座残高である．もっとも，これは，Bitcoin では明には記録されず関連するトランザクションを集計することで算出できる．後者はトランザクションであり，口座残高の変化とタイムスタンプから成る．

4. 2 移行を可能とするミドルウェア設計

移行を可能にするミドルウェアを設計するにあたり，次の方針を採る．

• 特定のブロックチェーンミドルウェアへの依存を最小限にする．単純なデータ，つまり数値の組やバイト列等をタイムスタンプと共に記録する機能だけを前提とする．

• 移行元ブロックチェーンを信用し続けられるとは期待しない．あるブロックチェーンから脱出しようという理由の１つは，そのブロックチェーンの差し迫った機能不全である．例えば，パブリックブロックチェーンは，ノードを失い過ぎるとそうした機能不全に陥る．この場合，そのブロックチェーンに依拠し続けることはできない．図 3 に設計の候補を示す．

図中の “middleware” がブロックチェーン間移行を行う．上述の依存を最小限にするため，設計案では，ブロックチェーンにはいくつかの値とタイムスタンプの組を検索キー（例： Bitcoin アドレスといったアカウント ID）とともに記録する機能しか求めない．それ以上を求める場合も，せいぜいブロブ（バイト列）の記録までとする．それ以上の機能をサポートしつつの移行は今後の課題である．

移行のために必要ではないものの，図 3 (b) のように，データはブロックチェーン内ではなく外部のデータベースに保存する，という設計もあり得る．ブロックチェーン上ミドルウェア Beyond Blockchain One (BBc-1) がこうした設計を採っている．この設計はブロックチェーンのサイズを削減する．ブロックチェーンは全ブロックチェーンノードにコピーされて，全ノード上のストレージを占有するため，サイズの削減にはメリットがある．加えて，もしアプリケーションが状態（データ）変化の検証までは必要としないという場合，データベース上のデータをただ上書きすれば済み，ストレージ専有量はさらに減る．

図 3 (b) の設計では，充分なデータ可用性を達成するためには，データベースの耐故障性が充分に高い必要がある．このためには，たいていの分散データベースがサポートしている複製や消失訂正符号（erasure coding）を用いることができる．耐故障性の程度は，複製数や消失訂正符号のパラメータを設定することで調整できる．

このように調整できる柔軟性は，全ブロックチェーンノードへの単純なコピー（図3(a)）に対する利点であろう．現在，そうした可用性の高いデータベースがパブリッククラウドのサービスとして提供されており，さらには自身でクラウド提供者をまたいで複数のデータベースに記録することもできる．図 3 (b) の設計では，アプリケーションが状態（データ）変化の検証までは必要としない場合は，更新時にデータをデータベース上で上書きしてしまうこともできる．これによって，ストレージの占有量をさらに減らすことができる．図 4 に，アプリケーションの移行を可能にするブロックチェーン設計の選択肢をまとめる．

4. 3 移行の手順

アプリケーションが移行元ブロックチェーン中のログへのアクセスを必要とするなら，ミドルウェアはアクセスを提供する必要がある．しかし，セキュリティ的な理由から，移行元ブロックチェーンを信用し続けられると期待するわけにはいかない．さらに，移行元ブロックチェーンのミドルウェアが実行を続けていてアクセスできるとは期待しない方が安全である．なぜなら，一般にパブリックブロックチェーンを制御できないのであるし，プライベートブロックチェーンのミドルウェアを実行させ続けるためには手間とCPU能力が要る．つまり，移行元ブロックチェーンを信用することなく，実行が続いていることを仮定することなく，その中のログにアクセスする方法が必要である．図 5 はこれらの要求を満たす移行手順である．

ミドルウェアは，移行元ブロックチェーンの静的なコピーを自身のストレージに保存し，有効期限以降を切り捨て，それをアクセスする．ミドルウェアは，移行直前の時刻を移行元ブロックチェーンの有効期限と設定する．タイムスタンプはある程度操作できてしまうので，有効期限はブロック高で指定することとなろう．静的保存によって，ブロックチェーンミドルウェア実行の必要性をなくせる．切り捨てによって，有効期限以降にそのブロックチェーンを信用する必要をなくせる．ミドルウェアは，図 5 の通り，保存されたブロックチェーン群からハッシュチェーンを構成する．ハッシュチェーンによって，保存されたブロックチェーンへの改ざんを検知でき，改ざんされていないことを信じられる．ハッシュチェーンによって，次のブロックチェーンに格納された有効期限が正しいことの確認もできる．

ここで，パブリックブロックチェーンではいったん承認されたブロックも無効化される可能性があることを思い出さねばならない．それは，攻撃によっても，また，自然にも発生する．そのブロックチェーン上のアプリケーションは，そうした無効化を単に無視できるように思われる．なぜなら，アプリケーションは，実行を続けている古いブロックチェーンではなく，静的に保存したブロックチェーン群にのみ依拠するからである．とはいえ，そうしたブロック無効化を考慮せねばならない状況もあるかもしれない．その場合，静的に保存したブロックチェーンも更新する必要がある．最低でも、保存したブロックチェーンの有効期限を，未だ有効なブロックまで巻き戻す必要はある．ともあれ，そうした更新は時間を食い，その間アプリケーションを止めてしまうので，避けたい．

そこで，自然発生するブロック無効化の原因である，ノード間ブロック遅延を減らそうと試みる．削減のための手法は，隣接ノード選択か経路選択となるだろう．そうした，性能のための隣接ノード選択や経路選択には，ノード間の近接性情報が必要である．そのためはまず，Vivaldiといったネットワーク座標系を用いてノード間の通信遅延を見積もる手法を確立しようと試みる．図 6 は，2 次元ユークリッド平面上で Vivaldi を用いて推測した Bitcoin ノード間の通信遅延である．この取り組みにおける次の一歩は，精度の向上である．

このミドルウェアはすべての移行元ブロックチェーンを解釈できる必要がある．それらブロックチェーンは，それぞれが自身の形式を持っているだろう．そうした解釈機能の開発は大きな労力を要し，また，ソフトウェアは複雑で多くの誤りを含みがちとなる．もしアプリケーションが許すなら，移行元ブロックチェーンは単純に捨てることが望ましい．アプリケーションが，存在証明は必要とするけれど状態（データ）変化の検証までは必要としないという場合，存在を証明するメタデータ（と図 3 (a) ならデータ自体）を次のブロックチェーンにコピーし，移行元ブロックチェーンは捨てることができる．

この場合，コピー元メタデータなしにコピー先メタデータが正しいことをどう信じたらよいだろうか？ブロックチェーンが提供する信用は，データが検証可能であることに基礎を置く．しかし，このコピーを行う設計では，コピー先メタデータは元データと明示的な関係を持たず，検証ができない．アプリケーションはそもそもコピーを行うミドルウェアを信用しているという前提ではあるが，そうしたソフトウェアの正しさに依拠する信用は検証可能データによる信用より弱い．なぜなら，例えばソフトウェアは人的誤りを含むからである．

次善の策は，コピーを行うプログラムの検証であろう．コピーを行うプログラムとそのハッシュ値をどこかに保存しておくことで，検証可能にできるだろう．

5 まとめ

ブロックチェーンのアプリケーションには，通常のアプリケーションと同様に移植性への動機がある一方，パブリックブロックチェーン上ではインセンティブ不整合という特有の動機もある．つまり，パブリックブロックチェーンはアプリケーションとは異なる経済的なインセンティブで駆動されており，アプリケーションから制御できるものではない．そのため，移植性，もっと言うと移行可能性がない限り，ブロックチェーンが機能不全になるとアプリケーションも機能不全に陥ってしまう．ブロックチェーンアプリケーションの生存能力を高めるべく，移植性と移行について論じた．

ブロックチェーン間移行を可能にするミドルウェアの設計を示し，要求の少ないアプリケーション向けにはより効率的な代替案を示した．アプリケーション移植性と移行は，一般に望ましい機能ではあると同時に，パブリックブロックチェーンのインセンティブ不整合問題に対する暫定解となる．それでも，ブロックチェーンは，ノードの経済的インセンティブではなく，アプリケーション群自身によって支えられることが望ましい．もし，パブリックブロックチェーンが常にアプリケーション群だけに支えられるなら，それはインセンティブ整合ブロックチェーンであると言える．

しかし，そうした機構をどう作るかは未解決問題である． ISO 等で分散台帳分野の標準化が始まっている． IETF や W3C もすでに議論を持った．機能する共通 API の策定でさえ挑戦的であり，ブロックチェーン間移行はそのさらに先にある．今日，まずソフトウェアが実装され，仕様書の作成はソフトウェアが多大な人気を得た後で行われる．実際，最初の Bitcoin Improvement Proposal（BIP）は Bitcoin ネットワークの立ち上げから 2 年半以上後だった．実効性のある次の一歩は，移植性のある，もしくは，移行可能なアプリケーションのデモンストレーションだろう．あまり論じなかったものの，スマートコントラクトのプログラムコードとデータの移植性も今後の課題である．同一ミドルウェア上でさえ，既存データを維持したままでのデータ形式やプログラムコードの更新は困難である．

いかがであろうか、システム評価の移植性について記載した。ブロックチェーンSNSと連動する愛記システムをどのように設計して移植性を確保するのか、課題は多い。

”愛記”の概念設計をやり直す：システム評価・移植性