2.ブロックチェーンで債務証書(支払い指図)を作る
ブロックチェーンで使う伝票、Chain of Signatures を使う
ここで、ビットコインの伝票が流通していく仕組みを見てみましょう。この図では、左から右へと流れていきます
ビットコインでは、一件の伝票を Transaction と呼んでいます。ここに「Owner 1さんへ」「Owner 0より+署名」「XX (金額)」と書いて、次の Owner 1 さんへと渡る仕組みです。前の情報を次の伝票に埋め込んでおきますので、手形で言うと、裏書して譲渡するイメージです
金額を分割して使うことはできますが、自分で勝手に鋳造する、勝手に増額することはできません
PoW(定期的に沢山の伝票を書庫にしまうような仕事)の作業をした人に、ご褒美がシステムから自動で鋳造されます
こうして、PoW の作業が何度も起きて、流通残高が増えていきます

売買の買掛債務をブロックチェーンに起票する
以後、伝票の流れを、右から左へ、表記します
前ページのビットコインの図と反対方向に表記していきます
ビットコインでは、その歴史上の最初の本源的な価値と、その後のPoWで自動的に与えられる褒美という形でしか、鋳造されません。参加者や管理者が勝手に価値を鋳造できると、すぐにインフレになるでしょう
一方、次の世代のブロックチェーン基盤では、プログラミング次第ですので、ここで、買掛債務の債務証書、あるいは支払い指図書と言ってもよいですが、これを買掛債務者がブロックチェーンの伝票として起票できる、というシステムを想定します。債務の金額のほか、支払期日も書きます
この仕組みは、原債務者が最後まで唯一の債務者であり、仮に、デフォルトが起きても、流通過程の主体は責任を持ちません
あくまでも債務証書、支払い指図書であり、その流通は、「指示払い」となるので、価値の売買ではありません

支払期日を書き込む意義
ブロックチェーンの伝票には、期限、満了日、期日などを埋め込めます。また、その期日が来た時に何をするのか、処理IDを埋め込んで、期日が来た時に、プログラムがそれを参照して、指定された処理を行うことができます

商流に対する債務証書の流通、会計記帳
左から、原料会社、素材会社、部品会社、製品会社と商流が流れるとき、それぞれの間で、売掛、買掛の勘定が立ちますが、右端の最終アセンブラーが買掛債務証書を起票した時、それを手形のように左方向へ支払い手段として使うという仕組みです
利益をゼロと仮定すると、Aの債務がDあてとなり決済されるので、B、Cの決済はその前に済んでいます
決済日には、センターの処理でD社/A社の債権債務となり、A社がD社に振り込む仕組みです
会計帳簿の仕分け情報への反映は、BがAの債務を免除して、代わりにBのCに対する債務を引き受けてもらう、次にCは同じようにAの債務を免除して、Dに対する債務をAに引き受けてもらう、この繰り返しです
指示払い、という見方でも良いです。BはAの債務に対して、うちに払わないでCに払ってくれれば良いですよ、というのが指示払いですが、同じように債務処理であり、価値の売買ではありません

債務取引の構成
債務証書が流通するときに、権利の売買ではなく、債務引き受けや債務免除と言った法律構成が想定できます

分割送付
ブロックチェーンに起票された債務証書は、分割して使用できます
紙の手形は、ちぎって分割して使うことはできません
今の銀行が運営するデジタルの手形は、分割使用ができるそうです
ブロックチェーンでも同様に分割使用ができます。なお、合算することもシステム上可能ですが、ここで紹介するシステムは、原取引と原債務者の情報をキープしなければならないので、合算は使用しません。複数の債務証書を束ねて、合計額を増やすという運用は可能です

債務証書のレコード・フィールド構成
ブロックチェーンの伝票(transaction)の上には、オプショナルフィールドを活用して、いくつかの属性を書き込めます。書き込めない場合は、外側のデータベース上に保持しますが、どちらにしても、この仕組みに必要な情報は以下の通りです
- 原取引ID: もととなる取引を特定できる契約書や請求書上の番号などを会計システムやERPからコピーします
- トランザクションID: ブロックチェーン基盤が自動で振ります
- 通貨種別: 原取引で定めた取引通貨です。期日にネッティングの決済尻を何の通貨で授受するかは、企業間であらかじめ決めておきます
- 原債務者: 債務証書が流通しても、期日には、原債務者が支払い債務を負うので、この情報をキープする必要があります
- 期日と決済方法: 決済予定日を記録して、その日には、決済方法のフラグに従って、予定される決済を行います
- 受取者、送付者: 債務証書の流通に伴い、伝票上で(transaction上で)変わっていきます
- 金額: この仕組みでは、月次の為替換算表をもって、例えば毎月末に決済するような運用を想定しており、複数通貨間のネッティングもできます。その換算のため、「satoshi」などの共通通貨や、ドルでも円でもいいので予め換算して伝票に記載するか、原通貨建てで起票して、決済日に換算しても良いです
レコードのフィールド項目 | 取りえる値 |
原取引のID | Invoice XX、請求書番号XXなど。原取引を特定できる必要 |
トランザクションID(原取引に紐づけ)の履歴 | ブロックチェーンの transaction ID(最初のIDは原取引に紐づけ、その後、債務証書が流通すると、複数の履歴を保持する) |
通貨種別 | USD、JPY、Euroなど |
原債務者 | 原 Payerのアドレス。債務証書を起票するため、最初の送付者名(および電子署名) |
期日(決済予定日) | 年月日 |
予定される決済方法 | バイラテラル(to XX)、マルチラテラル(ネッティングセンターXX)、銀行送金 |
受取者名 | Payeeのブロックチェーン上のアドレス |
送付者名(および電子署名) | Payerのブロックチェーン上のアドレスと署名 |
金額 | 各通貨建ての金額(例えば、XX円や、XX satoshi) |
ブロックチェーンの伝票の内外
元祖、ビットコインのソースコードをもとに作る場合は、かなりの情報をブロックチェーンの外において、紐づけて管理しなければなりません。今の世代のブロックチェーン基盤であれば、ブロックチェーン内「transaction」の中にかなりの情報を収録して、流通させることができます
