こんにちは、BCHNews編集部のreiです。

ハードフォーク以降Bitcoin Cash(BCH)界隈では、侃侃諤諤の議論が止みませんね。
今回の記事では、それらの議論に関して触れるのを一旦おやすみいたします。
代わりに、BCHをさらに洗練するための技術として提案されたZero-Conf Forfeitsに関して、簡単にご紹介したいと思います。

Zero-confとは？

Zero-Conf Forfeitsについて説明する前に、まずZero-Confについて説明します。
Zero-Confとは、 “Zero Confirmation”が省略されたものです。
日本語では、0確認や0承認、つまり未確認や未承認と翻訳することができます。
では、何が未確認なのかと言うと、トランザクションです。

トランザクションは、発生してからブロックチェーンに記録されるまでにマイナーによって検証される必要があります。
ネットワークに転送されたトランザクションは、一旦メモプールに溜められ、マイニングされたブロックにまとめられ、その後チェーンに繋がれます。

ここで、トランザクションが発生してからチェーンに組み込まれるまでのラグが発生します。
BCHのブロック生成間隔はだいたい10分ごととなっており、１つの検証を得るために平均して約10分必要ということです。
言い換えると、１つの取引に対して、安全に送金できるまでに約10分以上かかります。

これは、一般的に使用されるクレジットカードなどの決済方法と比較して、商用利用に十分な速度とは言えません。
そこで、通常は未確認(Zero-Conf)トランザクションのままでも、アプリケーション上では送金されたとみなすなどの工夫が取られています。

ただし、未確認トランザクションには二重支払いリスク増加という問題が存在します。
これは、本来二重支払いのリスクを減らす仕組みとして設計されている検証の積み上げを行なっていないため、当然の帰結と言えます。
二重支払いがおきた場合は、受取手が送金されたとみなしていたトランザクションは承認されず、支払いが行われなかったことになってしまいます。
しかし、未確認トランザクションは、まとまった金額以下の取引で二重支払いを行うことは、複雑な操作を行うコストの関係上容易には実行されないということを前提として使用されています。

それでも、リスクが完全に存在しないわけではないため、未確認トランザクションを使用することに関しての議論は過去何度も行われてきています。

Forfeits

Forfeitは、英語で「代償」や「罰金」、「没収」といった意味を持つ単語です。
Zero-Conf Forfeits(ZCF)は、その名の通り二重支払いをしようとした人に対して、罰金アウトプットを与えることで思い留まらせる仕組みとして提案されています。
これは、受取手の側に立って保証金と表現されることもあります。
BCHのハードフォークで実装された、OP_CHECKDATASIGおよび、OP_CHECKDATASIGVERIFYのオペコードを使用することで自動化された枠組みとして実装することができるそうです。

OP_CHECKDATASIGは、Bitcoinスクリプトの署名で、署名が有効だった場合true(0)を、そうでなかった場合はfalse(1)を返します。
例えば、次のようなスクリプトで署名が有効だった場合OP_CHECKDATASIGは1を返します。

[signature] [message] [public key]

OP_CHECKDATASIGVERIFYは、同様に署名を検証しますが、署名が有効であった場合は何も返さず、無効であった場合は動作を停止するオペコードです。

ZCFは、二重支払いを行う場合、インプットの公開鍵からそれぞれ有効な異なる署名が生成されていることを利用します。
そこで、未確認トランザクションをZCFの枠組みで使用する場合、受取手は送信者に対して次のような構造のトランザクションを請求します。

Inputs: [P2PKH inputs 1] ... [P2PKH input I]
Outputs: [any-type-output 1] ... [any-type-output O] [Forfeit Output]

ここでのポイントは、インプットが全てP2PKHで異なるアドレスである点と、アウトプットにForfeit Outputが含まれている点です。
Forfeit Outputは、トランザクションが有効であった場合はあとで送信者に返却されます。
しかし、送信者が二重支払いを行おうとした場合は、二つ目の署名が同じ公開鍵から作られたものであることが明かされ、マイナーがこの罰金を請求するために使用されるため返却されません。

Forfeit Outputは、次のどちらかのscriptSigを使用してアウトプットの支払いを許可します。

1. [signature] [public key] [P2SH script]

2. [signature1] [message1] [signature2] [message2] [public key] [P2SH script]

   (同じ公開鍵の異なるメッセージと署名)

   1番目の支払いは通常の支払いですが、2番目の支払いはマイナーが二重支払いをしようとした人物に対する罰金の請求です。
   この支払いを有効化することによって、マイナーが同じ公開鍵から作成されている署名を二度確認した場合、Forfeit Outputを請求することを可能にしています。
   したがって、この仕組みは送信者が二重支払いを行なった時に資産を紛失する可能性を付与することで、二重支払いを防止しようというものです。

   しかし、この仕組みには以下のような問題が挙げられています。

   • 前のトランザクションに使用した古い署名を利用できる
   • マイナーが罰金を請求するためにはクライアントに変更が必要である
   • 受取手が資金を失ったことに対する補填にはなっていない
   • 罰金額の標準化が必要
   • 十分な効果を得るためにはある程度消費者に負担を強いる必要がある

   参考URL：https://gist.github.com/awemany/619a5722d129dec25abf5de211d971bd、http://archive.is/9z22x#selection-387.0-479.1、https://github.com/Electron-Cash/Electron-Cash/pull/964

   一言

   本日は、BCHをより洗練された通貨にするための一つの仕組みとして提案されたZero-Conf Forfeitsに関して簡単にご紹介しました。
   問題点を見る限りではまだアイデア段階のような気もしますが、すでにテストベッドおよびリファレンス実装がElectron CashのGitHubにプルリクされています。
   アイデア自体は、プロトコルを変更することなく実装することができるため、実際に実装される可能性も十分ありそうですが、今すぐという訳では無さそうですね。

   最新情報はこちら

   BCHNewsでは公式のTwitterアカウント（@bchnews_jp）を開設しました。
   更新情報を配信しておりますので、よろしければフォローしていただけると嬉しいです。