[メモ] party系チェーンでSBT?

つぶやき。ぽえむ。

NFT の次は SBT だそうです。Vitalik さんも言っているようなので間違いない。Vitalik さん間違えない。

乗るぜこのビッグウェーブに!

って思ったとき、どういう設計が良いのかな、と。

Ⓜ

まず SBT 相当の概念になにか名前をつけたい。ここでは Label と呼ぶことにする。Label はアセットとは別の 1st class なオブジェクトである。

まず、create_label という API を用意する。

create_label(destination_address, text, is_hex)

このメッセージを解釈した counterparty-server は、下記テーブルにレコードを追加する。たぶん anti-spam-fee は徴収される。

/* 疑似 SQL */
INSERT into labels (
  block_index,
  transaction_index,
  source_address,
  destination_address,
  memo)

INSERT into label_states (
  transaction_index,
  accepted = False,
  revoked = False)

accepted = False であるのがキモ。自分のアドレスに対し、勝手にレッテルを貼られたら萎える。誹謗中傷やらハラスメントやらメモの温床になるのは避けたい。なので、opt-in 戦略を取る。このトランザクションに対する trigger message が destination_address から発行されると、 accepted = True へ更新される。一度 True となったら False には戻せない。前言撤回を許さないバイオゴリラの世界観。

一方、labels メッセージを発行したアドレス (source_address) から trigger (または cancel) メッセージを発行することで、この Label をいつでも失効させられる (revoked = True)。失効に対して destination_address 側は拒否できない。履歴は残る。source_address からの失効撤回もできない。失効させたら別の Label を再度発行してくださいねと。

Ⓜ

最先端金融工学ギャンブルマシーンではない、party 系チェーンで SBT のユースケースは在るのか? ちょっと考えていたのですが。

これ、アドレスの所有証明に使えます。

まず、Twitter ログイン可能でトラストフルな存在証明サービス A を用意します。

アドレスの所有証明を行いたい Alice は、 A に Twitter ログインします。

Alice は A に対し、自らが所有するアドレスで署名し A に提出します。

Alice の署名を検証できたら、A は、署名に使われたアドレスを destination とし Twitter ID を text に含む Label メッセージを発行します。

Alice は、発行された Label を accept するメッセージを発行します。

以上の手順で、Alice が秘密鍵を所有するアドレスとその Twitter アカウントが結びつきます。

もうちょっと設計っぽい感じで描くと、こんなの。

Twitter でなくても、ソーシャルログイン機能を提供しているサービスなら同様に結び付けられます。

ソーシャルアカウントは、実在の人物と結びつけるのは難しい感はありますが。しかしたとえば、政府が法人向けに発行している gBizID に対応させたら、かなり強い所有証明になるのではないでしょうか。

なお、Alice と A が結託すると偽造が可能であり、A へのトラストは必要です。しかし  A の発行するラベルの信頼性については、ブロックチェーン外での、メタ評価が可能でしょう。たぶんもんだいない。しらんけど。

Ⓜ

最近、無職業者 BOT では "やるやる詐欺" が多発しているうえに、上記実装には未実装の trigger message が必要なので、諸々アレなのですが。

ビッグウェーブが来たときには、割とシンプルに実装できそうよ?

というお話でした。

ぽえむ。

追記

署名を求めるのではなく「指定のメモ付きのユーティリティ・アセットを Alice から A が指定するアドレスへ送らせる」という実装もありえる。 A はユーティリティ・アセットの販売で収益をあげられるので、経済が回り始める。