SBT on Monaparty
つぶやき。ぽえむ。
結論: 来ると思います。
Ⓜ️
従来は、アセットの送受信が、トークンアセットプラットフォームの主な使われ方でした。しかし送受信の対象を限定したいユースケースは従来でもあり、モナパーティでは Counterparty には存在しない、vendable やら reassignable やらフラグを用意して拡張してきました。設計時の想定は、発行者との間でのみ送受信可能なアセット、会員権のような「受け側に権利を持つ(返却可能な)モノの抽象化」を想定していました。
ここから、更に推し進めて「送り側に権利がある(受け側には返却不可能な)ものの抽象化」には、ユースケースはあるでしょう。世の中には他人からのラベル付けという行為が存在しますので。それは信用と差別、両方の道具にもなる怖い行為なのですが。
たとえば融資実行とその償還は、すぐに思いつくユースケースです。貸し手アリスが、ボブへの融資実行を行う場合を考えてみます。
- アリスは、融資実行時に、アリスしか失効できず誰も移転できないアセット(SBT)を、ボブのアドレスに発行する。アリスがボブから得た担保は、償還期日までロックされる。
- この融資にはイベント駆動のコントラクトが設定されており、期限内にボブが債務を償還できたなら、SBT は自動的に失効する。
- 償還期日を過ぎても SBT が失効していなかったら(つまりボブが借りを返せなかったら)、アリスは担保を回収できるようになる。
Ⓜ️
SBT、モナパーティでも理屈では(≒モナパーティを拡張すれば)、実現可能です。
ただし、安直に実装すると、他人のアドレスにゴミを投げつける spam 攻撃が簡単に実現できます。単なるゴミなら良いのですが、Automation を絡めて窃盗が起きる可能性もあり、結構怖い機能になりえます。
anti-spam fee を取るだけでは不十分でしょう。SBT 目的で発行されたアセットのオプトイン機能など、いくつかの配慮が必要になるはずです。
「金融工学超人が拳を交える、資本市場主義の鉄火場」たるイーサリアムとは異なる性質をもつモナパーティで SBT が必要なのかは、もう少しユースケースを分析しないと結論は出ないですが。(直感としては、あるような気がします)
言い換えると、イーサリアムの世界では、SBT は必要でしょう。流行ると思います。
ぽえむ。