３．外部に作る、外部管理せざるを得ないところ
外部に作る、外部管理する １
Bitcoinのトランザクション（ここでは一枚一枚の債務証書）の中に書ける情報は決まっています。それ以外の情報を持たせたいとき、各トランザクションにユニークなIDをキーとして（紐づけて）、外側のデータベースに持たせる、つまり外部に作る、外部管理する必要があります
Bitcoinの中にいれば、セキュリティは完璧ともいえます。一歩外に出た途端、外部からの侵入、盗聴、改ざんをうけるようなリスクは高まりますが、Bitcoinを使用する以上、その保護範囲は限られるので、広く世にあるトランザクション系システムと変わらぬリスク対策を打つしかありません
当システムの債務証書（支払い指図書）の発行、流通、決済に必要な主な要件は以下の通りです
- 債務証書は、原債務者が発行し、流通しても、分割されても、その債務者は引き続き、原債務者唯一であることです。手形の裏書譲渡では、原債務者がデフォルトに陥った時、手形の流通過程で裏書きした主体にも弁済義務が及びます。手形が不渡りの場合、所持人はすべての裏書した人に対して支払いを請求できます。当システムでは、債務証書であり支払い指図書であって、手形ではなく、原債務者が唯一の支払者として、流通過程の受取人も知ったうえで取引するとの前提です
- 債務証書それぞれは、原取引書類（契約書など、外部のシステムにある）が持つIDと紐づけられる必要があります
- 債務証書に、支払期日を持たせる必要があります
- 債務証書に、支払期日が来た時に、どのような処理をして終了するかのフラグを入れる必要があります
- 債務証書は原取引に従い、最終決済、支払時にどの通貨で行うかを決めておく必要があります
- 債務証書の流通過程で、原債務者が誰かという情報を債務証書上で受け継いでいく必要があります。Bitcoinのシステムでは、送信者から、宛先に対して、お金が幾ら、という当該トランザクションの情報しか残らないので、流通を繰り返すと、そもそもの本源的な原債務者が分かりません。取引が掲示板に公開されますので、過去の履歴をさかのぼれば検索可能ではありますが、債務証書の分割と流通が繰り返されると、原債務者の検索は厄介になるので、債務証書に持たせたい情報です
- 通貨種別を記入します
外部に作る、外部管理する ２
当システムの債務証書（支払い指図書）のフィールドを図示すると以下の通りです
原債務者の情報をキープすることが処理性能上必要で、そのほかにも、前述の情報を持たせます
外部に作る、外部管理する ３
当システムは、クロスボーダーでも、すべてドル建て、あるいは円建てであれば、そのままネッティング決済ができます。そこで、金額はそれぞれの原通貨建てで記載します
一方、マルチカレンシーの多くの債務証書を混ぜてネッティングしたい場合、決済間近になると、為替換算表により、いったん一つの通貨（例えばドル）に換算してネッティング計算し、決済尻をどの通貨で受け取りたいのかを予めマスターに記録しておいて、それに従って再度換算し、送金指図を行うことになります
こうした情報とロジックは、Bitcoinの外側に保持する必要があります
外部に作る、外部管理する ４
債務証書が流通していくとき、外部にトランザクションIDの履歴表を作ると便利です
これがあれば、流通するたびに、もともと誰の債務かすぐに分かりますし、決済予定日になると、決済ロジックも、その債務証書のトランザクションIDの履歴の最初を見ることで、原債務者が誰か分かります
外部に作る、外部管理する ５
債務証書を分割して（金額を分割）流通するとき、管理テーブルも分けて増やす必要があります
分割を繰り返すと、債務証書は樹状ツリーのように枝分かれしていきますが、管理テーブルも同じ数作る必要があります
おわりに
このコンテンツでは、当方の決済システムの最初の起案の時に、ビットコインのソースコードを最小限改変して開発するための検討内容をご紹介しました
ブロックチェーンのその後の世代では、決済システムがより簡易に作れるようになり、別紙「ブロックチェーンで作る決済システム」の方でご参照いただけます
ビットコインのどの機能をオフしたり、ブロックチェーンの外にデータを待つ必要があったかを備忘録として残しましたが、ビットコインの特徴も、ちょっと違った観点からレビューすることができたと思います 既存のブロックチェーンのネットワークを利用するのではなく、新規に開発環境から立ち上げることにご興味をお持ちでしたら、今後、決済システムの機能要件を書いて公開しますので、参考になるかもしれません
ーーーーーーーー
このコンテンツはここで終わりです