💭

🔑マルチシグ・AA・MPCについて〜Web3 セキュリティ〜

2022/12/31に公開・約24,200字

ブロックチェーン

Web3セキュリティ.001.jpeg

皆さん、こんにちは！

先日、UNCHAINでマルチシグをテーマとした勉強会を実施したのですが。思いのほか反響がありましたので多くの方にシェアしたいと思い、ブログでもまとめることにしました！

ぜひ UNCHAINに興味のある方は下のリンクからエントリーしてみてください！
本当に素晴らしいコミュニティですよ！！

https://unchain.tech/

1. マルチシグについて

そもそもマルチシグとは？

日本の暗号資産交換所であれば、交換所のラインセンスを取得するために顧客資産をコールドウォレットとマルチシグの仕組みを利用して管理することは必須となっています！

大事な顧客資産(それも膨大な額)を管理することになるので、内部不正を防ぐという意味でマルチシグは重要な鍵を握っていると考えています。

🔽 有名な暗号資産交換所でも取り入れられています！

https://www.whalefin.com/ja

https://bitflyer.com/ja-jp/security

ビットコインとイーサリアムでの実装の違い

マルチシグといってもその実装方法は、プロトコルレイヤーであるブロックチェーンの仕様にかなり左右されることになる。例えば、ビットコインとイーサリアムを比較しても次の様な違いがあります。

	ビットコイン	イーサリアム
標準であるか	マルチシグは標準仕様として存在している。	マルチシグは標準仕様ではない。
開発言語等	bitcore-jsなどのライブラリを使えばマルチシグウォレットを作成することができる。	標準ではないのでSolidityなどで自分達で作るか事業者が提供しているものを利用する必要がある
セキュリティ上の留意点	標準ライブラリの機能として提供されているのでそのライブラリを信じるしかないが、万が一脆弱性が見つかった場合にはバージョンアップなどの対応が必要	コードを書くことになるため、商用の際には監査の実施が必須となる。その他、Solidityの仕様を把握した上でコーディングしていくことが必要。

上記は、ビットコインとイーサリアムを比較した場合の話。その他のチェーンも考慮する必要がああるので日本の交換所は新しいチェーンに対応するのにかなり苦労しているのではないかと考えられます・・。

2. マルチシグコントラクトの実装例について

今回は、非常にシンプルなマルチシグコントラクトの仕組みをポンチ絵にまとめてみました！

multiSig.drawio.png

factoryコントラクトを介してマルチシグコントラクトを生成することで、使う環境にあったownerのアドレス数と閾値を決めることができます！

この場合であれば下記のように処理を進めて目的のアドレスに送金します！

核となるMulitiSigWalletコントラクトにはコメントを振っているソースコードがあるので、是非ご参考にしていただければと思います！

// SPDX-License-Identifier: MIT
pragma solidity >=0.4.22 <0.9.0;

/**
 * MultiSigWalletコントラクト
 */
contract MultiSigWallet {

  // トランザクションデータ用の構造体を定義
  struct Transaction {
    // 送信先のアドレス
    address to;
    // 送金額
    uint value;
    // トランザクションのバイトデータ
    bytes data;
    // 実行済みのフラグ
    bool executed;
  }

  // マルチシグウォレットの名前
  string public walletName;
  // Ownerのアドレスを格納する配列
  address[] public owners;
  // 閾値
  uint public required;
  // トランザクションデータを格納する配列
  Transaction[] public transactions;
  
  // アドレスとowner権限の有無を紐付けるmap
  mapping(address => bool) public isOwner;
  // トランザクションID毎にonwerの承認状況を紐づけるmap
  mapping(uint => mapping(address => bool)) public approved;

  // 各種イベントの定義
  event Deposit(address indexed sender, uint amount);
  event Submit(uint indexed txId);
  event Approve(address indexed owner, uint indexed txId);
  event Revoke(address indexed owner, uint indexed txId);
  event Execute(uint indexed txId);

  // 呼び出し元のアドレスがownerであるかチェックする修飾子
  modifier onlyOwner() {
    require(isOwner[msg.sender], "msg.sender must be owner address");
    _;
  }

  // 指定したIDに該当するトランザクションデータが存在するかチェックする修飾子
  modifier txExists(uint _txId) {
    require(_txId < transactions.length, "tx does not exist");
    _;
  }

  // 承認ずみかチェックする修飾子
  modifier notApproved(uint _txId) {
    require(!approved[_txId][msg.sender], "tx already approved");
    _;
  }

  // 指定したIDのトランザクションがブロードキャスト済みかチェックする修飾子
  modifier notExecuted(uint _txId) {
    require(!transactions[_txId].executed, "this tx already executed");
    _;
  }

  /**
   * コンストラクター
   * @param _name ウォレットの名前
   * @param _owners owner用のアドレスの配列
   * @param _required 閾値
   */
  constructor(string memory _name, address[] memory _owners, uint _required) {
    // 引数の内容をチェックする。
    require(_owners.length > 0, "number of owner addresses must be more than zero!!");
    require(_required > 0 && _required <= _owners.length, "invalid required number of owners");

    // ownerのアドレス群を配列とmapに詰めていく
    for(uint i; i < _owners.length; i++) {
      // ownerアドレスを取得する。
      address owner = _owners[i];
      // ownerのアドレスが条件を満たしているかチェックする。
      require(owner != address(0), "invalid address");
      // 同じアドレスが連続で登録されるのを防ぐ
      require(!isOwner[owner], "owner is not unique");
      // mapと配列にセットする。
      isOwner[owner] = true;
      owners.push(owner);
    }

    // ウォレットの名前を設定
    walletName = _name;
    // 閾値を設定
    required = _required;
  }

  /**
   * 入金用のメソッド
   */
  receive() external payable {
    // イベントの発行
    emit Deposit(msg.sender, msg.value);
  }

  /**
   * トランザクションデータを作成するメソッド
   * @param _to 送金先アドレス
   * @param _value 送金額
   * @param _data バイトデータ
   */
  function submit(address _to, uint _value, bytes calldata _data) external onlyOwner {
    // Transaction型のデータを作成して配列に格納する。
    transactions.push(Transaction({
      to: _to,
      value: _value,
      data: _data,
      executed: false
    }));
    // イベントの発行
    emit Submit(transactions.length - 1);
  }

  /**
   * 指定したIDのトランザクションを承認するメソッド
   * @param _txId トランザクションID
   */
  function approve(uint _txId) 
    external
    onlyOwner
    txExists(_txId)
    notApproved(_txId)
    notExecuted(_txId)
  {
    // 承認済みのフラグをオンにする。
    approved[_txId][msg.sender] = true;
    // イベントの発行
    emit Approve(msg.sender, _txId);
  }

  /**
   * 指定してIDのトランザクションの承認数を取得する。
   * @param _txId トランザクションID
   */
  function _getApprovalCount(uint _txId) public view returns (uint count) {
    // ループにより承認数を取得する。
    for(uint i; i < owners.length; i++) {
      // もし承認されていたらcountをインクリメントする。
      if (approved[_txId][owners[i]]) {
        count += 1;
      }
    }
  }

  /**
   * トランザクションをブロードキャストするメソッド
   * @param _txId トランザクションID
   */
  function execute(uint _txId) payable external txExists(_txId) notExecuted(_txId) {
    // 閾値以上の承認が得られているかチェックする。
    require(_getApprovalCount(_txId) >= required, "approvals < required");
    // トランザクションデータを作成する。
    Transaction storage transaction = transactions[_txId];
    // 実行済みのフラグをオンにする
    transaction.executed = true;
    // トランザクションを実行する。
    (bool success, ) = payable(transaction.to).call{value: transaction.value}(
      transaction.data
    );
    // トランザクションが成功したかチェックする。
    require(success, "tx failid");
    // イベントの発行
    emit Execute(_txId);
  }

  /**
   * トランザクションの承認を削除するメソッド
   * @param _txId トランザクションID
   */
  function revoke(uint _txId) external onlyOwner txExists(_txId) notExecuted(_txId) {
    // 承認されているかどうかチェックする
    require(approved[_txId][msg.sender] = true);
    // 承認済みのフラグをオフにする。
    approved[_txId][msg.sender] = false;
    // イベントの発行
    emit Revoke(msg.sender, _txId);
  }

  /**
   * ウォレットの名前を取得するメソッド
   */
  function getName() public view returns (string memory) {
    return walletName;
  }

  /**
   * ウォレットの閾値を取得するメソッド
   */
  function getRequired() public view returns (uint) {
    return required;
  }

  /**
   * ownerのアドレス数を取得するメソッド
   */
  function getOwnersCount() public view returns (uint) {
    return owners.length;
  }

  /**
   * トランザクションデータを全て取得するメソッド
   */
  function getTxs() public view returns (Transaction[] memory) {
    return transactions;
  }
}

その他にもhttps://solidity-by-example.org/app/multi-sig-wallet/ やyoutubeなどにシンプルなマルチシグコントラクトを作成する方法は記載されています！

その他、セキュリティのスペシャリストとも言えるBitGo社やGnosisSafeが作成しているマルチシグコントラクトもあり、こちらはテストやコードのなどもかなりしっかりしており、構造も上のコントラクトより複雑になっています！

セキュアなコードを開発するのは難易度がやはり高そうです・・・。

https://gnosis-safe.io/

3. デモ

↓ こちらのDappを利用します！

デモでは、2-of-3のマルチシグコントラクトを作成して実際に署名・送金を行います！

デモでやったこと

2-0f-3のマルチシグコントラクトウォレットを作成する。
トランザクションデータを作成する。
1.で作成したマルチシグコントラクトウォレットに送金用のETHをdepositする。
2人のownerにより承認処理を実施する。
送金処理を実行する。
送金結果を確認する！

デモで利用するアドレス

owner1 : 0x51908F598A5e0d8F1A3bAbFa6DF76F9704daD072

owner2 : 0x9f9115893713934AA5AFd3540937eB60ea43eb3a

owner3 : 0xb5a05Af300C50baAadE18f8EA8AA7e856177Afe8

送信先：0xEef377Bdf67A227a744e386231fB3f264C158CDF

実際にデプロイしてあるコントラクトの情報

No.	コントラクト名	ネットワーク	アドレス
1	WalletFactory	Goerli	0x3c955E552Fd383435765313330301c23f014e0a6
2	MultiSigWallet	Goerli	0x5ba5DF0955d0C95500966acE28041F3D7BC45D1D
3	WalletFactory	Mumbai	0xFEbf942Ce0f403a48a01D4757710289E0458bca9
4	MultiSigWallet	Mumbai	0x455d21AE3F9Cdd21365757B5528bbE3b3eCC1C1A

4. 残課題と拡張性について

現段階で感じている残課題・拡張性については以下の通りです。

残課題

No	課題
1	送金処理にのみしか対応していないこと
2	もっとセキュアにするためには、ecrecover()などを利用して検証を厳格化する必要がある。
3	どんなアカウントでもマルチシグを作れてしまう状態になっている。
4	どんなアカウントでもマルチシグを作れてしまう状態になっている。
5	考えにくいが、複数のチームがマルチシグコントラクトを共有していた場合に、資金が抜かれる可能性がある。

拡張性

No	項目
1	現在流行りのAAにも使える設計パターンなので、秘密鍵を必要としないウォレットアプリが開発できそう！→ Web3のマスアダオプション？
2	NFTの発行処理など送金以外の処理にも応用できればウォレットとしても十分に機能するはずなので、ハッカソンなどでやってみたい。

5. マルチシグとコントラクトウォレットについて

MultiSigWalletコントラクトには、「コントラクトウォレット」という考え方が採用されています。

コントラクトウォレットの応用としては、**AA(Account Abstraction)がかなり盛り上がってきており、ETHIndiaでもAA(Account Abstraction)**の考え方を採用したプロダクトが1st prizeを獲得するなど注目を集めています。

AAは使っていませんが、せっかくなのでコントラクトウォレットとAAの考え方についても触れていきたいと思います！！

一旦、関連用語の整理をします！

💡 EIP4337とは

2021.09.29 に提案されたAAに関する規格案。
バンドラーと呼ばれるユーザーのトランザクションの肩代わりを行うEOAが最低1つ存在する形にはなるものの、その他のユーザーのウォレットはコントラクトウォレットとして扱うことのできるシステム体系が考案されている！

👉 メタトランザクションを思い浮かべると分かりやすいかもしれません！
👉 バンドラーにトラストが集中する形になるので、バンドラーの鍵は権限分離して管理
　するか信頼できる第三者に預けてもらうのが良いかもしれません！
👉 とにかくユーザーが秘密鍵を管理しなくて良くなる点はでかいです！
👉 エントリーポイントコントラクトが、核となる機能部分を担っている。　　　　　　　　　　　　👉 エントリーポイントコントラクトに脆弱性があるとやばい・・。

EIP-4337の詳細についてはヴィタリックさんの記事の中でも紹介されている。

重要になるのは、Bundlerとエントリーポイントコントラクト!!

今回のデモで共有したマルチシグDappdeでは、factoryコントラクトからMultiSigWalletコントラクトを生成し、owner達の共有の資金プールとしてMultiSigWalletコントラクトを利用しています。(複数人で一つのウォレットを共有して使っているイメージ)

AAとして実装されてはいないのでユーザーであるownerは、自分で鍵を所有して署名を行う必要がありますが、実行したいトランザクションデータをコントラクトウォレットに登録しておき、その後実行指示を出して送金用のトランザクションを実行しています。(ETHが出るのはコントラクトウォレットから！)

外からみると個人のウォレット(EOA)と何ら変わらないように振る舞っていますが、通常のウォレットと異なる点を整理すると下記の通りです。

個人のウォレット(EOA)のように秘密鍵が存在しないこと
承認が一定数得られた後宛先のアドレスにETHを送るという機能を持っていること
deposit機能を持っていること

コントラクトウォレットの考え方については下記の記事とスライドがわかりやすくまとめてくれています！

AAについてさらに深く知りたいという方は、CryptoGamesのYukiさんがわかりやすく解説してくれている記事があるのでこちらも参照をおすすめします！

ERC-4337で実装されたシステムがどのように動くのか実際に手を動かしてみたいという方は、StackUp社がサンプルのリポジトリを公開してくれているのでお手軽にAAを利用した送金の仕組みを体験することができます！

https://github.com/mashharuki/AA-dapp

送金処理の実行例

MATICの送金処理

Signed UserOperation: {
  "sender": "0x100cD9e97EdAEe0950d97f75251313e45213C8Fb",
  "nonce": "0x0",
  "initCode": "0xe19e9755942bb0bd0cccce25b1742596b8a8250b3bf2c3e700000000000000000000000078d4f01f56b982a3b03c4e127a5d3afa8ebee68600000000000000000000000051908f598a5e0d8f1a3babfa6df76f9704dad0720000000000000000000000000000000000000000000000000000000000000000",
  "callData": "0x80c5c7d00000000000000000000000001431ea8af860c3862a919968c71f901aede1910e000000000000000000000000000000000000000000000000006a94d74f43000000000000000000000000000000000000000000000000000000000000000000600000000000000000000000000000000000000000000000000000000000000000",
  "callGasLimit": "0x5580",
  "verificationGasLimit": "0x129727",
  "maxFeePerGas": "0xa2c22e83",
  "maxPriorityFeePerGas": "0xa2c22e65",
  "paymasterAndData": "0x",
  "preVerificationGas": "0xc644",
  "signature": "0xff954fe43538bf8fff0f928aa03f58c62b7c28d9b14912c4e1b452853124bd622053de4915a85e55697f714e80bf7668670e043467d2116df33979a1c2fd2f551b"
}
UserOpHash: 0x854c14b08bd913b7960edc3d4cbef6d65666e20e1494c4a0831a46cb18829fd1
Waiting for transaction...
Transaction hash: 0xc561b6a5410ffc8c10bd36b4102a08e57dc92040e4706526c3acedc42143d20d
✨  Done in 13.44s.

ERC20規格トークンの送金処理

Transferring 0.04 LINK...
Signed UserOperation: {
  "sender": "0x100cD9e97EdAEe0950d97f75251313e45213C8Fb",
  "nonce": "0x1",
  "initCode": "0x",
  "callData": "0x80c5c7d0000000000000000000000000326c977e6efc84e512bb9c30f76e30c160ed06fb000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000600000000000000000000000000000000000000000000000000000000000000044a9059cbb0000000000000000000000001431ea8af860c3862a919968c71f901aede1910e000000000000000000000000000000000000000000000000008e1bc9bf04000000000000000000000000000000000000000000000000000000000000",
  "callGasLimit": "0xe6fc",
  "verificationGasLimit": "0x186a0",
  "maxFeePerGas": "0xca0f4bb3",
  "maxPriorityFeePerGas": "0xca0f4b95",
  "paymasterAndData": "0x",
  "preVerificationGas": "0xc37c",
  "signature": "0x06bcf3dcded028a8c42ef90c72f4fea98e54ecd4da2366288cb50851ee60ee0512d6f74a998633109d9352ad0453e3665aa3171147bcf8a876676449499eeef61b"
}
UserOpHash: 0xade156da0c2b036926618ed914b2f87dca006d14ba4de29e949326be89cc4096
Waiting for transaction...
Transaction hash: 0xdc695a878c6bbfa8e149ea19fddcaad782f98707971d81201d4954113810dd2c
✨  Done in 13.16s.

MATICの送金処理(複数の一括送金)

Signed UserOperation: {
  "sender": "0x100cD9e97EdAEe0950d97f75251313e45213C8Fb",
  "nonce": "0x0",
  "initCode": "0x",
  "callData": "0x80c5c7d0000000000000000000000000100cd9e97edaee0950d97f75251313e45213c8fb000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000600000000000000000000000000000000000000000000000000000000000000204d0cb75fa000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000000a00000000000000000000000000000000000000000000000000000000000000002000000000000000000000000100cd9e97edaee0950d97f75251313e45213c8fb000000000000000000000000100cd9e97edaee0950d97f75251313e45213c8fb0000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000000c00000000000000000000000000000000000000000000000000000000000000044a9059cbb00000000000000000000000051908f598a5e0d8f1a3babfa6df76f9704dad07200000000000000000000000000000000000000000000000003782dace9d90000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000044a9059cbb0000000000000000000000001431ea8af860c3862a919968c71f901aede1910e00000000000000000000000000000000000000000000000003782dace9d900000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
  "callGasLimit": "0xe31a",
  "verificationGasLimit": "0x186a0",
  "maxFeePerGas": "0x7d7a574e",
  "maxPriorityFeePerGas": "0x7d7a5730",
  "paymasterAndData": "0x",
  "preVerificationGas": "0xd56c",
  "signature": "0x804964cc35c21fcb0fd1b4c4fe854a9deb5c7ea9117d68c31b4948914d282fdc53812ebb003ee542e35af8793b60917b0600be54fd05192598a6df396c6c47a81b"
}
UserOpHash: 0x77b6dd28dbd8691ea0ae23cc63bbd32f18889723e1c31f04cf534ae7e47569e5
Waiting for transaction...
Transaction hash: 0x381f4d559a033559d38370b24280ecad09017bf657f41e6eb277a0691cf5f248
✨  Done in 16.04s.

ERC20規格トークンの送金処理(複数の一括送金)

Batch transferring 0.04 LINK to 2 recipients...
Signed UserOperation: {
  "sender": "0x100cD9e97EdAEe0950d97f75251313e45213C8Fb",
  "nonce": "0x2",
  "initCode": "0x",
  "callData": "0x80c5c7d0000000000000000000000000100cd9e97edaee0950d97f75251313e45213c8fb000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000600000000000000000000000000000000000000000000000000000000000000204d0cb75fa000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000000a00000000000000000000000000000000000000000000000000000000000000002000000000000000000000000326c977e6efc84e512bb9c30f76e30c160ed06fb000000000000000000000000326c977e6efc84e512bb9c30f76e30c160ed06fb0000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000000c00000000000000000000000000000000000000000000000000000000000000044a9059cbb0000000000000000000000001431ea8af860c3862a919968c71f901aede1910e000000000000000000000000000000000000000000000000008e1bc9bf040000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000044a9059cbb00000000000000000000000051908f598a5e0d8f1a3babfa6df76f9704dad072000000000000000000000000000000000000000000000000008e1bc9bf0400000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
  "callGasLimit": "0xea85",
  "verificationGasLimit": "0x186a0",
  "maxFeePerGas": "0x99adc148",
  "maxPriorityFeePerGas": "0x99adc12a",
  "paymasterAndData": "0x",
  "preVerificationGas": "0xd560",
  "signature": "0x9efbbce4eedb58268350032f6033db120bfe54d34ca920bb15ff72c46f681a2032b2609cb910b646abb5cd87b65a5e1d1e86205bcc64e60d971fff210e72cd611c"
}
UserOpHash: 0x856e6d3741c710a76eb4e300fee208b8a33f93425f59be5ed3fea4a35ace9db9
Waiting for transaction...
Transaction hash: 0xab22e6bf970c6784aa6d9aa0e44a19adf428999b28370fbe4390fdcc63a31c63
✨  Done in 16.64s.

残課題にも記載した通り、秘密鍵を必要としないウォレットアプリ(その代わりKYCには厳格な仕様が求められるはず)の開発にも繋げられそうです！!

今の状態ではセキュリティを意識した仕組みになっていますが、様々なユースケースにも応用が効きそうな気がしています！

先日、ETHIndiaで1st prizeを獲得したFireWalletでもAAの考え方が採用されており、今後は使いやすく且つ安全なウォレットを躍起になって開発する動きが活発化していくと考えられるのでやはりこの設計パターンはマスターしたい・・！

秘密鍵の管理は、Web3のマスアダプションを妨げている大きな要因の一つだと考えており、AIやクラウドなどの様な世の中に受け入れられる汎用的な技術に昇華するためにはこの課題解決が必須！！

ただ、中にはAAが浸透していくことについて疑問視する方もいるので、どのようなウォレットがもっとも受け入れられていくかは、引き続きアンテナを貼って情報を収集しつつ、ハッカソンなどに出てプロトタイプを作っていくことが重要だと考えています！！

和組DAOのukishimaさんのツイートは参考になりました！！

6. マルチシグ VS MPC

マルチシグと並んで、Web3領域で注目されている技術が MPC(マルチパーティ計算)を活用した署名の仕組みです!!

また用語の整理として、秘密計算・秘密分散・MPCの意味を整理します！

この秘密計算の仕組みを実現させるために主要な方法が2種類存在する！🚀🚀🚀🚀🚀🚀🚀

準同型暗号方式
秘密分散方式

秘密計算と秘密分散について詳しく知りたい方は、下記リンクを確認してください！

↓ 秘密分散を利用して秘密鍵を分散し、そこから再度秘密鍵を復元⇨ アドレス復元 ⇨ 送金までをテストできる簡易スクリプトを作成してみましたので興味ある方はぜひこちらも！！

秘密鍵のデータをそのまま使うマルチシグに比べて、単体では意味のないデータに分割して管理することになるMPCの方がよりセキュアだと考えてられています。(万が一、一箇所で漏れてもダメージはMPCの方が小さいはずです。)

比較表

	マルチシグ(ここでは比較のため、スマコンによるマルチシグを想定)	MPC
署名処理の実行場所	オンチェーン	オフチェーン
実装難易度	中	高
応用の幅	ビットコインとイーサリアムの様に対応するチェーンの仕様によってプログラムが変わるので複数チェーンに対応させるのは至難の技だと考えている。	ブロックチェーンプロトコルの影響を受けにくいので多数のチェーンに応用が効きやすいと考えられている。

実装難易度は、圧倒的にMPCの方が高いですが実装できれば応用が効くものです！

マルチシグの方は、EVM対応のチェーンであればマルチシグコントラクトを使いまわせば行けるかもしれませんが、ビットコインやNEARなどのチェーンなどに対応するとなるとまた違うので対応が大変です。プロトコルレイヤーによって左右されてしまうのは骨が折れるところ。

https://www.fireblocks.com/

もっと知りたい！！という方は下記の記事がおすすめです！

7. 最後に

ウォレットコントラクトの考え方と合わせるとめちゃめちゃセキュアなウォレットアプリが作れるかも？？　(KYCはゼロ知識証明や生体認証などを活用して厳格化iは必須ですね！！)

結局どこかに必ずトラストポイントが生まれるので、そこを如何に守りながら魅力的なアプリを提供していけるかが重要なポイントになりそうです！(一般ユーザーが全員公開鍵暗号方式のことを理解できれば良いのですが、実現できたとしてもとんでもない時間がかかりそうです・・。)

あとは、MetaMaskだとUX的にも少しハードルが高いのでもっとシンプルなプロダクトにする必要がありそうです。下のツイートは面白いと思った一例ですが、指輪の中に署名鍵を入れておいてそれで署名とかできたら見た目的にもオシャレだし使いやすいので世の中に浸透しそうですね！

ウォレットの話になるとソフトウェアだけでなくハード面も考えなくてはいけないので難しいですが最後はここを握ったところが勝ちそうですね！!

長文となりましたが、最後まで読んでいただきありがとうございました！
2023年もよろしくお願いいたします！！

参考文献

Discussion

ログインするとコメントできます