Tempo 提案 TIP-1061 導入協議層ネイティブマルチ署名口座で、Safe などのコントラクトをデプロイする必要はありません

Stripe と Paradigm が共同開発したレイヤー1 ブロックチェーン Tempo は、5月31日に TIP-1061 のネイティブ多重署名（マルチシグ）アカウント提案を提出し、多重署名を協議層（アグリゲーション層）の主要なアカウント種別としてネットワークに導入することを想定している。Safe などのスマートコントラクトウォレットをデプロイせずに、多重署名による制御を実現する。TIP-1061 は、DAO、機関、検証ノードなどの利用シーンを主な対象としており、なお草案段階である。

確認済みの技術仕様

TIP-1061 のコア設計には、以下の確認済みの技術的詳細が含まれる。多重署名アカウントのアドレスは初期設定（config_id）ハッシュから派生し、その後にメンバー名簿、署名権限（ウェイト）、または閾値を調整しても、アカウントアドレスは不変のままである。

対応する署名タイプは3種類である：Secp256k1、P256、WebAuthn。M-of-N 平面多重署名（各オーナー weight=1）と、加重多重署名（非対称の委任）をサポートする。たとえば、高権限のオーナー（weight=100）は単独で承認でき、または2人の中程度の権限のオーナー（それぞれ weight=50）が共同で承認する。各多重署名アカウントには最大10名のオーナーまで許可される（MAX_MULTISIG_OWNERS=10）。

設計上の制約：AccountKeychain と EIP-7702 をサポートしない

TIP-1061 では、ネイティブ多重署名アカウントは AccountKeychain による鍵の参照をサポートしないことを明確に規定している。msg.sender がネイティブ多重署名アカウントである場合、AccountKeychain 修飾子（modifier）の呼び出しは拒否されなければならない。提案の設計理由は次のとおりである：単一の委任用鍵を親アカウントとして呼び出し可能にすると、元の秘密鍵が、あらゆる委任の範囲において多重署名アドレスとして永続的に機能する能力になってしまい、「法定人数（法定の人数）による制御を備えたアイデンティティ」という設計原則に合致しないからだ。

さらに、ネイティブ多重署名アカウントはブートストラップ（Bootstrap）後、EVM バイトコードまたは EIP-7702 委任コードをインストールしてはならない。

草案のステータス：未確定事項あり

提案は現在も草案であり、ガス計量方式（文書上は「未定事項」）と、多重署名のプリコンパイル済みコントラクトアドレス（提案が草案から脱する前に割り当てられる）が、いずれも最終確定していない。提案では、TIP-1061 の起動および発効前に、TempoSignature::Multisig を含むすべての取引は拒否されなければならない。また、multisig_init フィールドを含むすべての取引も、提案の起動前に拒否されなければならない。

よくある質問

TIP-1061 のネイティブ多重署名は、Safe などのコントラクトウォレットと何が本質的に違うのか？

TIP-1061 は、多重署名の検証を協議層（アグリゲーション層）へ引き上げることで、チェーン上に Safe などのコントラクトウォレットをデプロイせずとも、同等の閾値（しきい値）による制御能力を実現する。これによりコントラクトデプロイのコストがなくなり、またアカウントアドレスは初期設定から派生した後は安定し、メンバー更新によって変化しない。

多重署名アカウントのアドレスが、メンバー更新後も不変でいられるのはなぜか？

多重署名アカウントのアドレスは config_id のハッシュから派生し、config_id は初期のオーナー集合（アドレス、署名タイプ、ウェイト）および閾値の計算結果として求められる。アカウントが存続している間は変わらない。以後の updateMultisigConfig の呼び出しは、保存されている現在の設定を更新するだけであり、config_id 自体、または派生するアカウントアドレスを変更しない。

TIP-1061 の主な目標となる利用シーンは何か？

提案の動機の部分で明確に述べられているように、目標となるシーンは「単一の秘密鍵では資金を単独で移転したり、操作の設定を変更したりできない」必要のあるユーザーであり、具体的にはチーム（Teams）、財務部門（Treasury）、検証ノード（Validators）、機関運営者（Institutional Operators）が含まれる。