【決定版 ガイド】SBT(ソウルバウンドトークン)

この記事は、SBT(ソウルバウンドトークン)について解説している完全ガイドです。

主に以下のことを学べます。

• SBTについて
• SBTの実際の使用例
• SBTを作る方法
• その他色々

また、NFT(Non-Fungible Token)についてある程度知識がないとSBTを理解するのは難しいと思うので、まだNFTについてわからない方は、NFTの基礎を勉強してから読むことをおすすめします。

では、さっそく見ていきましょう！

CHAPTER 1

SBTの基礎

SBTとは？

permalink

SBTとは、簡単にいうと誰かに送ったり売ったりできないNFTで、最初にVitalik Buterinのブログでアイディアが提案されました。ソウルバウンドを直訳すると、「魂に紐づいた」という意味でここでの魂というのはウォレットのアカウントのことなので、もっと簡単にいうとウォレットから離れられないデジタルデータということになります。

通常のNFTとSBTの違いを理解するために、簡単なデモを用意しました。購入ボタンを押して移動させて見てください。

通常のNFTは移動できますが、 SBTはできないのがわかると思います。

しかし、移動できないNFTに何の価値があるのでしょうか？次はこの部分について見ていきます。

なぜSBTが必要なのか

permalink

移動できないNFTであるSBTは、一見不便に見えると思います。

では、なぜSBTが必要なのでしょうか？

証明証に使える

SBTは売却や人に送ったりできないので、金銭的価値がないものや転売されては困るものをNFTにしたい時に使えます。みなさんの持っているもので、マイナンバーカードや免許証などは誰かに送ったりせず自分自身を証明するときに使いますよね。そういう証明証などをデジタルで表現したい時にSBTは使えます。

SBTを使えば偽造とかもできないので、認証をするのがすごく楽になります。具体例を出すと、とあるところに寄付をしても自分から言わないと相手に伝わらないですし、証明する手段もあまりないですよね。しかも、自分から言うのは中々気が引けたりします。NFTを使えばデジタルの証明証を作れますが転売できてしまうので、寄付していない人でもしました！と言うことができてしまいます。

そこで、一定の金額を寄付をした人にSBTを発行するとします。そうすれば、その人のウォレットを見るだけでこの人は〇〇にこれだけの金額を寄付していると、わざわざ自分で言わなくても証明することができますし、ウォレットから移動できないので嘘をつけません。

また、イーサリアムで発行すれば支援した履歴はイーサリアムがなくならない限り消えないので、10年後に支援した人にお礼するなどがすごく簡単にできます。

なので、NFTもすごく便利ですがSBTはNFTでは、やりずらかったことやできなかったことを実現できます。

あと、現実世界だけではなくゲーム内のアチーブメントの達成などにもSBTは使えます。

レピュテーションの獲得

SBTが生まれた背景として、現状だとリアルでの活動や実績よりも、高額なNFTを持っているかどうかでその人がすごいかどうか判断されてしまっているという懸念がありました。NFTについてある程度知識がある方ならわかると思いますが、BAYCやCryptoPunksを持っていたおそらくすごいなーってなりますよね。ただ、判断基準がこれだけだと単純にお金を持っているかどうかでその人が判断されてしまいます。

もし、自分の活動を表すSBTがあれば、この人はあのコミュニティでこれだけの実績があって、寄付もしているんだなーと疑うことなく人を判断する基準を増やすことができます。

SBTのデメリット

permalink

SBTは証明証などで使えるので便利ですが、まだまだ発展途上なのでデメリットも当然あります。

ここでは、以下の3つを紹介します。

• プライバシーの問題
• ウォレットのハッキング
• 差別をしやすくなってしまう

順番に見ていきます。

プライバシーの問題

先ほどSBTは証明証に使えると言いましたが、個人情報が必要なSBTの場合に関しては、そのままブロックチェーンに上げたら世界中の誰でもその情報を確認できて一生消せなくなってしまいます。これを解決するためには、オフチェーンで個人のデータを管理し、オンチェーン部分ではハッシュ値だけ載せて、証明する時はゼロ知識証明を使う必要があります。ほとんどの人はSBTを使う時に何かしたことを証明できればいいので、ユーザーの個人情報をもらう必要はないと思います。

ウォレットのハッキング

SBTはウォレットから離れられないので、ウォレットをハッキングされても特別なギミックがない限りハッカーも移動できません。

しかし、SBTを使った機能を使うことができてしまいますし、SBTを持っている人に配られるNFTなどの場合はハッカーのウォレットに移動できてしまいます。

また、SBTによっては所有者のみがバーンできるようになっている場合があるので、ハッカーがそれを実行したらSBTを失うことになります。

SBTが自分の生活に関わるものではない場合は、気分が最悪になるだけで済みますが、そうでない場合はかなりの致命傷になってしまいます。ハッキング以外にもシークレットリカバリーフレーズを間違えて保存してしまい、ウォレットにアクセスできないなどのリスクも考えられます。これは、SBTの問題というかウォレットの課題でもあり、現状だとウォレットをハッキングされたりアクセスできないリスクが常にあるので、SBTを持っているからと言って完全に信頼できるというわけではないです。

なので、理論上はマイナンバーカードなどの個人情報や大学の卒業証明証もSBTにできますが、それを実現するには様々な問題を解決する必要があるので、現状は一般公開しても大丈夫なデータなどをSBTにすることがほとんどだと思います。

ただ、ウォレットをハッキングされない限り大丈夫なので、信頼度は既存のサービスと比べてかなり高いです。

差別をしやすくなってしまう

SBTを持っている方に向けて何か特典を付与するというのは結構あると思いますが、逆にこのSBTを持っている人を出禁するなどといった特定のコミュニティに対する悪意のある差別もできてしまいます。論文内でもSBTは「レッドライニングを自動化し差別をより透明化する」と書かれています。

なので、ユーザー側でSBTを削除したり隠す機能が場合によっては必要では？と言われています。

ただ、SBTを削除できるようにしても過去にこのSBTを持っていたということは消せません。隠す機能に関しては、マケプレ側でできてもNFTやSBTなどの本体を隠す機能は現状実装されていません。

CHAPTER 2

SBTの実際の使用例

SBTはまだまだ発展途上で、今後様々なものに応用されていくと思います。

現状で考えられる使い道をいくつかあげると下記の通りです。

• クラウドファンディングのリターン
• 資格や卒業証明書などの何かを成し遂げた証明証
• イベントなどの参加証明書
• シビルアタックの対策
• オンラインでの評判
• ブロックチェーンゲーム

理論的にはできることを解説するより、実際に使われている事例を紹介した方がいいかなと思ったので、ここでは実際にSBTが使われた例を紹介します。

では、見ていきましょう！

CryptoAnime Labs：アニメクラウドファンディング

permalink

CryptoAnime Labsはweb3時代のアニメ制作委員会で、「株式会社THE BATTLE、一般社団法人オタクコイン協会、株式会社ツクリエ、株式会社ファンワークス、合同会社日本の田舎は資本主義のフロンティアだ」と共同で設立されました。PR TIMESから「web3時代のアニメ制作委員会」の部分をを引用いたします。

web3時代のアニメ制作委員会は、NFTを活用して直接的にアニメ制作にまつわるクリエイターや関係者たちに金銭的な支援・応援ができる”クラウドファンディング2.0”ともいうべきサービスです

具体的にはパスポートNFTとステーキング用のNFTの二つを購入してもらい、ステーキングした枚数に応じてパスポートの色が変化します。このパスポートNFTにSBTが使われています。

第一弾として、日本のNFTコレクションで有名なCryptoNinjaの咲耶が主人公のアニメ「CryptoNinja-咲耶」のクラウドファンディングが行われました。

最初のセールはまさかの1分で完売して2,000万円を調達し、応援したかったけどできなかった人が続出して「応援させろ」がトレンド入りしました笑。僕も最初のセールに参加しましたが買えず、その後の追加のセールで何とか20枚購入してパスポートをゴールドにすることができました(本当は虹にしたい)。最初のクラファンでは2000万の調達でしたが、追加の販売でなんと7000万円を超える資金をクラファンで集めています。

SBTを見れば自分がどのくらい支援したかわかりますし、既存のクラファンとは下記が違います。

• P2Pなので販売手数料が取られない
• 着金に時間がかからない
• クラファンのサービスがなくなって後で支援者にお礼ができなくなるリスクの回避

まさにクラファン2.0ですね✨。

チムニータウン：CHIMNEY TOWN GIFT

permalink

チムニータウンは、キングコングの西野さんが立ち上げたエンタメの会社で、えんとつ町のプペルで有名ですね。西野さんは投資対象になるNFTにあまり興味がないみたいで、手段としてのNFTに可能性を感じており、色々なところでNFTを活用しています。その中で、CHIMNEY TOWN GIFTという子供施設に絵本を支援したらリターンとして支援したことを証明する支援NFTがもらえるプロジェクトがあり、そこにSBTを使われています。

メダルは一つ一つ「寄贈先の団体名」「寄贈する絵本の冊数」が記載され、「寄贈する絵本の冊数」に応じて、メダルの色が変わります。

このSBTを見れば、この団体に〇〇冊数を寄付していますとすぐわかりますね✨。

また、西野さんの後輩が経営しているCHIMNEY COFFEEも支援のSBTを出しています。

ポイントは、CHIMNEY TOWN GIFTのデザインと合わせることでコーヒー支援したい人だけではなくて、メダルのコレクターも顧客になるように設計されています。その他にも西野さんは、舞台テイラーバートンのクラファンでもリターンとしてSBTを出されています。

値段が30万なのにすぐ売り切れになったみたいです😳。今後も色々なところで、SBTを活用していくと思います。

セブン銀行 ATM： NFT募金キャンペーン

permalink

セブン銀行は、環境をテーマにした社会貢献活動の支援の証として、ATMに寄付するとSBTがもらえるキャンペーンを実地しました。

レシートにQRコードが記載されており、読み取ればNFTがもらえるようです。

現在でもレシートに割引が付いてくるとかあるので、今後レシートからNFTを受け取れるようにする事例は増えそうですね👀。

Binance：BABトークン

permalink

Binanceは仮想通貨取引所でBABトークンは、BinanceのKYC(本人確認)が完了しているアカウントに送られるトークンでBNBチェーン上で発行されます。このSBTを持っているということは本人確認が完了したということなので、ボット対策やプライバシー保護などに役に立ちますね！

LLAC(Live Like A Cat)：会員証SBT

permalink

LLACは「猫のように自由気ままに生きる」がテーマの日本のNFTプロジェクトです。ファウンダーはしゅうへいさんでマーケティングアドバイザーにイケハヤさん、リードデザイナーに猫森うむ子さんが入られています。LLACはまたたび屋というオンラインショップも展開しており、購入した方に会員証SBTを手に入れられるようにしています。

この会員証SBTを持っていると期間限定で割引を受けられたりします。

また、LLACはセミナーを参加した人にSBTを配布したり、初期で購入してくれた方にSBTを配布など色々なところでSBTを応用しています。

猫ちゃんの画像がすごく可愛いですね🥰。

TMAs(TheMafiaAnimalsSoldiers)：絆の証SBT

permalink

TMAsは、TMAの世界観をもっと拡げるために生まれた日本のNFTプロジェクトで、ファウンダーはRii2さんです。僕もエンジニアとして参加させていただいており、syouさんとLavuliteさんもエンジニアとして参加しています。TMAsでは、2次流通でNFTを買ってくれた方に絆の証というSBTを配布しました。

これを見れば2次で買い増しをして、プロジェクトを支えてくれた方がわかりますね✨。

APP(Aopanda Party)：クリスマスプレゼント

permalink

APPは、TikTokで有名なあおぱんだが元になった日本のNFTプロジェクトで、ファウンダーはAoさんです。APPでは、クリスマスにクリエイターが書いたイラストの交換会を実地し、そこにSBTが使われました。

プレゼントなので、売買できないSBTと相性いいですね✨。

また、APPはイベント参加のSBTやAoさんの誕生日にSBTを活用など色々SBTを応用しています。

誕生日にSBTを使うのは新しいですね！

CHAPTER 3

SBTの仕組み

ここでは、SBT内部の仕組みがどうなっているのか、スマートコントラクトのコードも紹介しながら説明します。

では、見ていきましょう！

SBTは転送できないNFT

permalink

先ほど説明したように、SBTはただ単に送ったり売ったりできないNFTです。

もっというと、NFTから転送や承認する関数を使えないようにしたものがSBTです。

では、SBT内部のコードはどうなっているのでしょうか？

次は、それについて見ていこうと思います。

SBT内部のコードを見ていこう

permalink

SBTのコードを見ていく前に、NFTからSBTに変えていったほうがわかりやすいと思うので、まずは通常のNFTのコードを見ていきます。通常のNFTは、ERC-721をベースに使うことが多いので、こちらを元に解説します。最初のコードは以下の通りです。

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import { ERC721 } from "@openzeppelin/contracts/token/ERC721/ERC721.sol";
import { Counters } from "@openzeppelin/contracts/utils/Counters.sol";

contract ERC721NFT is ERC721 {
  using Counters for Counters.Counter;

  string public baseURI = "https://demo.com/";

  string public baseExtension = ".json";

  Counters.Counter private _tokenIdCounter;

  constructor() ERC721("MyToken", "MTK") {
      _tokenIdCounter.increment();
  }

  function mint() external {
      uint256 tokenId = _tokenIdCounter.current();
      _tokenIdCounter.increment();
      _mint(msg.sender, tokenId);
  }

  function tokenURI(uint256 _tokenId) public view virtual override returns (string memory) {
      require(_exists(_tokenId), "URI query for nonexistent token");
      return string(abi.encodePacked(ERC721.tokenURI(_tokenId), baseExtension));
  }

  function _baseURI() internal view virtual override returns (string memory) {
      return baseURI;
  }
}

これは、誰でもNFTを購入できるシンプルなコードです。Counters でNFTを購入したときに、 tokenId を自動で上げるようにしています。ここに、転送と承認の関数をERC721からoverrideします。

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import { ERC721 } from "@openzeppelin/contracts/token/ERC721/ERC721.sol";
import { Counters } from "@openzeppelin/contracts/utils/Counters.sol";

contract ERC721NFT is ERC721 {
  using Counters for Counters.Counter;

  string public baseURI = "https://demo.com/";

  string public baseExtension = ".json";

  Counters.Counter private _tokenIdCounter;

  constructor() ERC721("MyToken", "MTK") {
      _tokenIdCounter.increment();
  }

  function mint() external {
      uint256 tokenId = _tokenIdCounter.current();
      _tokenIdCounter.increment();
      _mint(msg.sender, tokenId);
  }

  function tokenURI(uint256 _tokenId) public view virtual override returns (string memory) {
      require(_exists(_tokenId), "URI query for nonexistent token");
      return string(abi.encodePacked(ERC721.tokenURI(_tokenId), baseExtension));
  }

  function _baseURI() internal view virtual override returns (string memory) {
      return baseURI;
  }

  // 転送や承認の関数
  function safeTransferFrom(address from, address to, uint256 tokenId, bytes memory data) public override {
      super.safeTransferFrom(from, to, tokenId, data);
  }

  function safeTransferFrom(address from, address to, uint256 tokenId) public override {
      super.safeTransferFrom(from, to, tokenId);
  }

  function transferFrom(address from, address to, uint256 tokenId) public override {
      super.transferFrom(from, to, tokenId);
  }

  function approve(address approved, uint256 tokenId) public override {
      super.approve(approved, tokenId);
  }

  function setApprovalForAll(address operator, bool approved) public override {
      super.setApprovalForAll(operator, approved);
  }
}

SBTにするには、これらの関数を使えないようにする必要があります。コードにすると以下の通りです。

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import { ERC721 } from "@openzeppelin/contracts/token/ERC721/ERC721.sol";
import { Counters } from "@openzeppelin/contracts/utils/Counters.sol";

contract ERC721NFT is ERC721 {
  using Counters for Counters.Counter;

  bool private isLocked = true;

  string public baseURI = "https://demo.com/";

  string public baseExtension = ".json";

  Counters.Counter private _tokenIdCounter;

  constructor() ERC721("MyToken", "MTK") {
      _tokenIdCounter.increment();
  }

  error ErrLocked();

  modifier checkLock() {
      if (isLocked) revert ErrLocked();
      _;
  }

  function mint() external {
      uint256 tokenId = _tokenIdCounter.current();
      _tokenIdCounter.increment();
      _mint(msg.sender, tokenId);
  }

  function tokenURI(uint256 _tokenId) public view virtual override returns (string memory) {
      require(_exists(_tokenId), "URI query for nonexistent token");
      return string(abi.encodePacked(ERC721.tokenURI(_tokenId), baseExtension));
  }

  function _baseURI() internal view virtual override returns (string memory) {
      return baseURI;
  }

  // 転送や承認の関数
  function safeTransferFrom(address from, address to, uint256 tokenId, bytes memory data) public override checkLock {
      super.safeTransferFrom(from, to, tokenId, data);
  }

  function safeTransferFrom(address from, address to, uint256 tokenId) public override checkLock {
      super.safeTransferFrom(from, to, tokenId);
  }

  function transferFrom(address from, address to, uint256 tokenId) public override checkLock {
      super.transferFrom(from, to, tokenId);
  }

  function approve(address approved, uint256 tokenId) public override checkLock {
      super.approve(approved, tokenId);
  }

  function setApprovalForAll(address operator, bool approved) public override checkLock {
      super.setApprovalForAll(operator, approved);
  }
}

転送と承認の関数に checkLock をつけて、呼び出した時にエラーになるようにしました。

なので、もしOpenSeaとかでこれを移動させようとしたら、エラーが出て移動できません。

これで、通常のNFTをSBTに変えることができました！

以上がSBTの内部の仕組みです。意外と簡単ですよね。

CHAPTER 4

SBTの作り方

ここではスマートコントラクトを自分で構築し、ゼロからSBTを作る方法を紹介します。

自分でSBTを作れるようになると、応用の幅が広がります。

では、見ていきましょう！

スマートコントラクトの構築

permalink

先ほどのコードを使ってもいいのですが、OpenSeaなどのマーケットプレイスがSBTか通常のNFTか判断できないのでユーザー体験が少し悪くなってしまいます。これを避けるためには、マーケットプレイスがNFTみたいにSBTと判断できる規格を採用する必要があるのですが、SBTにもいくつか出てきており、現在で最もマーケットプレイスに採用される確率が高いのはERC-5192だと思います。

実際にOpenSeaでは、ERC-5192がサポートされています。

なので、今回はERC-5192を使って作ります。

また、ERC-5192はERC-721をベースに作られており、たくさんの枚数を配布または購入する場合はERC-721Aなどに変えた方がいいのですが、今回は公式がデフォルトにしているERC-721をベースに作りたいと思います。

開発環境はお任せしますが、今回はすぐ始められるRemixを使って説明していこうと思います。

まず、 contracts に .sol ファイルを作り、以下のコードをコピペしてください。

// SPDX-License-Identifier: GPL-3.0-only
pragma solidity ^0.8.20;

import { ERC721 } from "@openzeppelin/contracts/token/ERC721/ERC721.sol";
import { Ownable } from "@openzeppelin/contracts/access/Ownable.sol";
import { Counters } from "@openzeppelin/contracts/utils/Counters.sol";
import { ERC5192 } from "https://github.com/attestate/ERC5192/blob/main/src/ERC5192.sol";

contract SBT is ERC5192, Ownable {
    using Counters for Counters.Counter;

    bool private isLocked;

    string public baseURI = "https://demo.xyz/";

    string public baseExtension = ".json";

    Counters.Counter private _tokenIdCounter;

    constructor(string memory _name, string memory _symbol, bool _isLocked) ERC5192(_name, _symbol, _isLocked) {
        isLocked = _isLocked;
        _tokenIdCounter.increment();
    }

    // only owner
    function setBaseURI(string memory _newBaseURI) external onlyOwner {
        baseURI = _newBaseURI;
    }

    function setBaseExtension(string memory _newBaseExtension) external onlyOwner {
        baseExtension = _newBaseExtension;
    }

    // mint
    function mint() external {
        uint256 tokenId = _tokenIdCounter.current();
        _tokenIdCounter.increment();
        _mint(msg.sender, tokenId);
        if (isLocked) emit Locked(tokenId);
    }

    // other
    function tokenURI(uint256 _tokenId) public view virtual override returns (string memory) {
        require(_exists(_tokenId), "URI query for nonexistent token");
        return string(abi.encodePacked(ERC721.tokenURI(_tokenId), baseExtension));
    }

    function _baseURI() internal view virtual override returns (string memory) {
        return baseURI;
    }
}

大事なところをピックアップして解説します。

僕は baseURI を適当なものにしていますが、自分の画像のURIに変更してください。

    string public baseURI = "https://demo.xyz/";

constructor では、コードをデプロイするときに「コレクションの名前、シンボル名、SBTにするかどうか」を決めます。

また、tokenId を 1 から始まるようにしています。

    constructor(string memory _name, string memory _symbol, bool _isLocked) ERC5192(_name, _symbol, _isLocked) {
        isLocked = _isLocked;
        _tokenIdCounter.increment();
    }

その下の set 関数は、後でURIと拡張子を変えられるように onlyOwner をつけて、コントラクトオーナーのみ変更できるようにしています。

ミント関数は、説明用なので誰でも呼び出せて何回でも呼び出せるようにしています。必要に応じて、コントラクトオーナーのみ配布できる関数に変えたり、アローリスト持っているユーザーのみ購入できるように変えてください。アローリスト登録のやり方は、こちらの記事で解説しているので気になる方はどうぞ。

デプロイ

permalink

今回は、Goerli というテストネットにデプロイしようと思います。

まず、テストネットにデプロイするにはGoerliのイーサが必要なので、こちらからゲットしてください。

そしたら、Remixに戻りコンパイラのバージョンがあっているか確認し、コンパイルボタンを押します。

コンパイルが完了したら、デプロイの設定を以下のようにします。

constractor の name と symbol は、自分の好きなものにしてください。

また、ネットワークがGoerliになっているか確認してください。

準備ができたら、transactボタンを押します。少し経つと、トランザクションが完了すると思います！

Deployed Contractsにデプロイしたコントラクトがあると思うので、自分が設定した通りになっているかどうか確認してみます。

問題なさそうですね！

実際にミントボタンを押して、SBTをゲットしてみましょう。

トランザクションが完了したら、イーサスキャンにアクセスしてコントラクトアドレスをコピーします。

次に、テストネット用のOpenSeaの検索にコピーしたアドレスを貼り付けます。

そうすると、自分のコレクションが確認できると思います。通常のNFTは出品や転送のボタンがありますが、自分のSBTを見ると出品と転送のボタンがないのがわかると思います。

これで、SBTを作ることができました🥳。

今回紹介したSBTのコードは、最低限必要なものを実装したので、必要であれば自分のニーズに合わせてカスタマイズしてください。

CHAPTER 5

SBTを作成できるツール

先ほどSBTを作る方法を解説しましたが、プログラミングできない方もいると思います。

そう言った方に朗報です。

すでに、SBTを作成できる素晴らしいツールがいくつかあります。

簡単なSBTを作りたいなら、自分でコントラクトを作らずツールを使ったほうが安全で、車輪の再発明をしなくて済みます。

では、見ていきましょう！

thirdweb

permalink

thirdwebはNFTや、マーケットプレイスなど色々なものをプログラミングのスキルがなくても作れるツールです。

また、作ったものは独自コントラクトで発行されます。

たくさんの種類のコントラクトを扱っており、購入するサイトの構築や色々制限を加えられるのでとても便利です。現在は完全に無料ですが、今後有料の高度な機能を導入する予定みたいです。SBTのやり方は、こちらの記事が参考になると思います。

ただ、注意点として転送の関数を制限しているだけなので、OpenSea等で買えないけどリストはできてしまうみたいです。

Manifold

permalink

Manifoldもthirdwebと同じく、プログラミングの知識がなくても購入するサイトや独自コントラクトのNFTを作れるツールです。普通のNFTも作れますが、アプリケーションを使うことでSBTの構築や既存のNFTをバーンして新しいNFTを作れたり、様々な機能を使うことができます。クリエイターは完全に無料で使うことができてロイヤリティや収益も全部もらえますが、NFTを1次で購入（ミント）する人は約$1の手数料が購入時に含まれます。

CHAPTER 6

Advanced：プログラマブルプライバシー

最後に論文で書かれていた、プログラマブルプライバシーについて解説します。

では、見ていきましょう！

プログラマブルプライバシーとは？

permalink

プログラマブルプライバシーは、個人のプライバシーをプログラムによって制御し、他の人に情報を共有したりする方法を自分で設定できる仕組みです。プライバシーをプログラムで制御ってどういうこと？ってなると思いますが、まず既存のプライバシーの問題を見ていきます。

X(Twitter)やLINEやFacebookなどを使う時って、プライバシーの規約に同意して自分の個人情報をそのサービスに提供していますよね。普通のサービスは、ユーザーに提供してもらったデータを第三者に公開するのを禁止していますが、ハッキングで情報漏洩する可能性も結構ありますし、ケンブリッジ・アナリティカ事件みたいにユーザーの同意なしで勝手にデータを公開されてしまうリスクもあります。

また、DMや個人のチャットなどはそれらのサービスで働いている従業員に見れないようになっていると思いますが、偉い人がやろうと思えば公開できてしまうと思います。

この問題の共通点は、自分がそのサービスに提供したプライバシーが第三者に譲渡可能な状態であるということです。

そこで、プライバシーを譲渡可能にするのではなくて、SBTにある個人のデータをユーザー側がプログラムを実行して、どのデータをどこに公開するか、使用する条件などを細かく自分で設定して決めるのが良いのではないかと話が出てきました。

これにより、サービスがユーザーのプライバシーを所有しないので、ハッキングで大量のデータが流出したり勝手に第三者に共有されるリスクを回避できますし、サービス側がユーザーのプライバシーを欲しがるようになるので、自分のプライバシーを提供するときはサービス側がお金を払うなどといったマネタイズが可能になります。

またプログラム可能なので、データの利用を特定の条件が満たされたら共有可能にしたり、特定の目的にためだけに制限したりなど、データを共有する際に細かい設定を行うことができます。

例えば、ある人が自分の医療情報を共有する場合、特定の医療機関だけに限定したり、特定の研究目的に限定したりすることが可能です。

zkSBT (Zero-Knowledge Soulbound Token)

permalink

zkSBTは、ゼロ知識証明を搭載したSBTです。先ほどユーザー側が自分で公開するデータを制御すると言いましたが、サービスにアクセス可能にしたら結局データを取られて第三者に公開されてしまうのでは？そもそもSBTに個人情報を載せるの危なくない？と思うかもですが、zkSBTなら具体的なデータを公開せず認証として使うことが可能です。

すみませんが、ここでゼロ知識証明の説明をするとかなり長くなるので、各自で調べてみてください(このブログでもいつか記事書きます)。

ゼロ知識証明とSBTを使った事例で、Masaという論文で書かれていたプログラマブルプライバシーの実現を軸にしているプロジェクトがあり、そこがzkSBTを出しています。

詳しくは、ホワイトペーパーかブログ記事を見ていただきたいのですが、一部抜粋します。

zkSBTコントラクトは、分散型データストレージの利点を維持しつつ、ユーザーのプライベートデータのプライバシーとセキュリティの安全性を確保しています。 ゼロ知識証明を利用することで、このコントラクトは第三者に実際のデータを明かすことなく、暗号化されたプライベートデータの共有を可能にします。

zkSBTの使用例を、いくつかブログ記事からピックアップすると下記の通りです。

安全な本人確認

ユーザーは暗号化された個人識別情報（パスポート番号、社会保障番号など）を、zkSBT内に保存することができます。 本人確認を必要とするサードパーティのサービスとやりとりする場合、ユーザーは実際の個人情報を明かすことなくzkSBT を共有でき、サードパーティはゼロ知識証明を使用してデータの真正性を検証できます。

プライバシーを保護するクレジットスコアリング

クレジットスコアリングサービスは、ユーザーの暗号化されたクレジットスコアデータをzkSBT内に保存することができる。ユーザーがローンを申し込むと、そのzkSBTを融資機関と共有することができる。金融機関は実際のクレジットスコアデータにアクセスすることなく、ユーザーの信用度を検証することができ、これによりユーザーのプライバシーが保護される。

プライベートな資産所有

ユーザーは、資産所有の暗号化された記録（不動産、車両など）をzkSBT内に保存できます。 所有権の証明が必要な場合、ユーザーは自分のzkSBTを関係当局と共有し、資産の具体的な詳細を明かすことなく所有権を確認することができます。

上記の通り、zkSBTはかなり応用が効くので、今後かなり注目されてくる分野かなと思います。 メタバースが流行ればデジタルで生活する人も増えるので、個人情報をデジタルで表現するときの選択肢としてかなり良さそうですよね。

ただ、これにも懸念点があり、論文では以下のように書かれていました(日本語はDeepLで翻訳してchatGPTでわかりやすくしています)。

Unilateral zk-sharing isn’t incentive-compatible with our use cases, nor does it reect our norms around privacy. Most of our applications depend on some level of publicity. But under zk-sharing, Souls can’t know another Soul possesses an SBT unless it is shared to them—making reputation-staking, credible commitments, sybil-resistant governance, and simple rental contracts (e.g., apartment lease) impossible to get o the ground as other commitments and encumbrances are not necessarily visible. More deeply, we are skeptical that unilateral shareability is usually the right privacy paradigm. Rarely does one party in a multi-party relationship have the unilateral rights to disclose the relationship without the consent of the other. Just as unilaterally transferable private property is not a rich property regime, simplistic unilateral shareability is not a very rich privacy regime. If two parties co-own an asset and choose to represent their relationship through a VC, such credential doesn’t allow for the mutual-consent and mutual-permissions.

一方向のzk共有も、私たちの使用事例やインセンティブに合わないことがあり、私たちのプライバシーに関する基準を十分に反映しているわけではありません。私たちの多くのアプリケーションは、一定程度の情報の共有に依存しています。しかしzk共有の場合、他の人々がSoulbound Token（SBT）を持っていることを知ることはできません。そのため、他のコミットメントや保証が必ずしも明確には見えないため、信頼性を重視するステーキングやコミットメント、不正防止の仕組み、シンプルな賃貸契約（アパートを借りるなど）を成立させるのは難しいです。さらに言えば、一方的な共有の能力が通常のプライバシーのアイデアに適しているかどうかについては、私たちは疑問を抱いています。複数の関係者が関与する場合、片方の関係者が相手の同意なしに関係を公開する権利を持つことはまれです。片方向に転送可能な私有財産が豊かな財産体制でないように、単純な片方向の共有能力だけでは十分なプライバシーの保護が難しいこともあります。

なので、全ての認証サービスがゼロ知識証明に置き換わるというわけではなさそうです。

また、人によっては自分でプライバシー管理するのめんどくさいという方もいると思うので、未来はどうなるか謎ですね。

まとめ

このSBTの完全ガイドが、少しでも皆さんのお役に立てば幸いです。

NFTもそうですが、SBTはこれから発展していく分野なので、今後様々な形で応用されていくと思います。

実際にSBTを作ってみたいなと思った方は、コードを書いたりツールを使って実際にSBTを作ってみてください。

もし自分でやるの怖いなと思った方や、もっと高度なSBTを作りたいという方は、僕にDMかメールでご連絡いだだければお手伝いしますので、お気軽にメッセージをいただければと思います🙇‍♂️。