ブロックチェーンマルチアプリケーションモデル②

以前の投稿「ブロックチェーンマルチアプリケーションモデル①」の続きである。

ノード毎にウォレットを用意し、これに少額のビットコインを送信する。ビットコインの送金額や組み合わせを情報として使い、上位アプリケーションの伝言にする。

ビットコインの送金の最小単位は1satoshiで、これは0.00000001BTC。また546satoshi以下の支払いはdustと呼ばれ承認されない。0.01BTC以下の取引には0.001BTCの手数料が掛かるようだ。これから考えると、例えば0.02~0.03BTCの間で100,000通りの情報が送れることになる。

ただ送るだけでは実際に金額が移動したままになってしまうので、特定のウォレット経由で迂回して同じ額を返してもらう。つまり送信先も情報として活用する。例えばウォレットA、B、C、Dがあるとして、

1. AからBに0.02002343BTCを送金することである情報を送る。
2. BはBからCに同額を送信する。
3. CからAに同額を送金する。

AからBに情報が送られたことは、送金が成功したことで情報が送られたことは分かっているので、Cからの送金はただウォレットの額を維持するためだけに使われる。また、BからCに送られた額がAからのものであることは、元の0.02002343という数字の中にAのIDが含まれている、という方法で解決する。Cから送られた額が送った額と違っていたら、システム異常である。

直接返してもよいのだが、例えば連続で同じノードからデータが送られた場合、その到着の順序は保証されないから、システム異常かどうかの区別がつきにくくなる。これを許容するなら直接返送してもよく、その場合は下記に説明するノードIDの問題は発生しない。

さて、10万通りというと凄そうに聞こえるが、そのうち何ビットかはノードIDで、例えば1000ノードだとすれば、真に送れる情報は100種類しか送れない。これはASCII文字1文字分にしかならない。また原理上暗号化ができないし、他のノード(ウォレット)から送金される可能性も否定できない。このため、次の措置を取ることが望ましい。

• システム毎に新しくウォレットを生成し、その情報はオフラインで伝える。セキュリティの懸念が出た場合はこれをやり直す。
• 電子投票など、極めて限定した、非永続的な、短期的なシステムでのみ使用する。
• 送るコードの中にコード体系切り替えトークンを混ぜておくなどして、コードの難読化を行う。
• 何回かに分けて送り、それに意味を持たせる。
• もっと高額のビットコインを送ることで桁数を稼ぐ。但し送金手数料が発生する。
• 指定外のウォレットから送金されたら、無視するか、同額を送り返す(送金無料の場合)。

こうしたとしても、必ずしも市販の業務システムで使えるようなものが出来上がる訳ではない。従って、通常の通信との併用として、送信データのチェックデジットに使うようなことが考えられる。例えば長文を送っておいて、そのチェックディジットをアルファベット大小文字＋数字の58文字から1文字になるように計算し、その1文字を送るようにする。

このシステムの欠点は、ノード数と情報量が限られることの他に、ビットコイン固有の10分問題がある。つまり送金の確定には最低でも10分掛かる。上のシステムの場合、送金が送り返される方が早いため、これで第一次確定が行えるため、この問題を多少なりともカバーできている。