モナパーティ v9.5821.0 で直したもの
つぶやき。ぽえむ。
事の起こりは、「特定のヘビーユーザ・アドレスで、counterparty-serever (MONA) が MPMA send のトランザクションを生成できない」という報告でした。
結果として、修正が行われています。これを書いている時点では master に取り込まれていませんが、数時間内に完了予定。
Ⓜ️
これ原因を理解するには、Counterparty の歴史的事情を理解する必要があります。
まず、最初期の Counterparty は、OP_RETURN を使ってメッセージを埋め込むという、シンプルなトランザクションを作るだけでした。
しかし、OP_RETURN を使う手は、メッセージが高機能するにつれて限界を迎えます。この辺りは以前軽く書きました。
multisig を利用したメッセージの場合、少量の MONA を dust として utxo に残し、あとで回収できるようになっています。このメッセージを作るには、アドレスと紐づく公開鍵を知る必要あります。
公開鍵からアドレスは生成できますが、アドレスから公開鍵は得られません。multisig メッセージを作るためには次の 2 つから選択する必要があります。
1. Counterparty 側が頑張り、ブロックチェーン内にある情報から、アドレスと公開鍵の対応を見つけ出す
2. ウォレット側が頑張り、公開鍵の情報を counter-party server に引き渡す。
Counterparty server の API マニュアルには、「multisig の場合は pubkey に公開鍵を指定してくださいね」との明記があります。なので「上記の 2 を行ってください」で対応完了にする手もありました。ウォレットは必ず秘密鍵を持っており、秘密鍵から公開鍵は生成可能なので、負担も高くないはずです。
しかし、高くないとはいえ負担は負担ですし、ブロックチェーン内に情報があるなら Counterparty server 側が対応したほうが全体利益に適います。
Counterparty から受け継いだコードには 上記の 1 に相当するコードが含まれており、多くのアドレスで問題が起きなかったのは、このコードが存在していたからです。しかし、思いつく限りでぶっちぎりの最低性能を叩き出すコードでした。Counterparty 本家のコードでは割とありがち
Counterparty の開発者らも流石に耐えかねたのか、現行の彼らのコードは若干マシになっています。しかし、multisig メッセージが多用されがちなモナパーティでは焼け石に水の感が漂いました。
最終的には、「アドレスと公開鍵の対応テーブルを counterparty-server に加えることで、検索コストを最小限に抑える」という改良を行いました。
モナパーティって、現存する Counterparty 系列で、最も過激過酷な使われ方をしています。ゆえに、他のチェーンでは問題にならないような性能問題が、割と出やすくなっています。日々改良される「開発されていないチェーン」。
Ⓜ️
これで問題が解決したかというと、そんなには甘い問題ではなかったりします。
まず、マルチシグアドレスや P2SH アドレスへの対応が不十分です。しかし、現状の使われ方では、これが問題なるケースはほぼ無いと見ています。将来的に「Submarine Swap を使い BTC でモナカードを売る」みたいなことが現実的になった時点では対応が必要でしょう。DDoS 攻撃の温床にもなりかねないので、早めの対応が必要だったりはします。
そして、アドレスから公開鍵が検出できないケースがあります。典型的には、アドレスに送金はされたが、未だそのアドレスからの出金がない場合です。この場合は「pubkey が見つからんかった」というエラーを返すようになっているので、API 呼び出し時に pubkey 加えてください。大抵のケースでは、ウォレットの提供者に対応をお願いすることになると思います。
