Die von Stripe und Paradigm gemeinsam entwickelte Layer-1-Blockchain Tempo hat am 31. Mai einen TIP-1061-Antrag für native Multi-Signature-Konten eingereicht. Dabei soll die Multi-Signature-Funktion als wichtigste Kontotyp-Klasse auf Protokollebene in das Netzwerk eingeführt werden. Für die Umsetzung ist kein Deployment von Safe- oder anderen Smart-Contract-Wallets erforderlich, um eine Multi-Signature-Kontrolle zu erreichen. TIP-1061 richtet sich primär an Einsatzfälle wie DAOs, institutionelle Akteure und Validator-Nodes und befindet sich weiterhin im Entwurfsstadium.
Bestätigte technische Spezifikationen
Das Kern-Design von TIP-1061 umfasst die folgenden bereits bestätigten technischen Details. Die Multi-Signature-Kontoadresse wird aus der Hash-Ableitung der anfänglichen Konfiguration (config_id) gebildet. Wenn die Mitgliederliste, die Signatur-Gewichte oder der Schwellenwert später angepasst werden, bleibt die Kontoadresse unverändert.
Es werden drei Signaturtypen unterstützt: Secp256k1, P256 und WebAuthn. Unterstützt wird eine M-of-N-Ebene-Multi-Signature (jedem Inhaber weight=1 zugeordnet) sowie gewichtete Multi-Signature (asymmetrische Berechtigungen). Beispielsweise kann ein Inhaber mit hohem Gewicht (weight=100) allein autorisieren, oder zwei Inhaber mit mittlerem Gewicht (jeweils weight=50) können gemeinsam autorisieren. Jedes Multi-Signature-Konto darf maximal 10 Inhaber zulassen (MAX_MULTISIG_OWNERS=10).
Design-Einschränkungen: Keine Unterstützung für AccountKeychain und EIP-7702
TIP-1061 schreibt ausdrücklich vor, dass native Multi-Signature-Konten keinen Zugriff auf AccountKeychain-Schlüssel unterstützen. Falls msg.sender ein natives Multi-Signature-Konto ist, muss der AccountKeychain-Modifier-Aufruf abgelehnt werden. Als Begründung für das Design des Vorschlags wird angeführt: Die Erlaubnis, dass ein einzelner Autorisierungsschlüssel über das Parent-Konto aufruft, würde einen ursprünglichen privaten Schlüssel in eine dauerhafte Fähigkeit verwandeln, die eine Multi-Signature-Adresse innerhalb eines beliebigen Autorisierungsbereichs dauerhaft ersetzt—das entspricht nicht dem Designprinzip „Identität mit gesetzlich festgelegter Anzahl an Personen gesteuert“.
Zusätzlich dürfen native Multi-Signature-Konten nach dem Bootstrapping keine EVM-Bytecodes oder EIP-7702-Delegierungscodes installieren.
Entwurfsstatus: Noch offene Punkte
Der Vorschlag ist derzeit noch ein Entwurf. Sowohl das Gas-Accounting-Konzept (in den Dokumenten als „To-do“ markiert) als auch die vorab kompilierte Multi-Signature-Vertragsadresse (die zugeteilt wird, bevor der Vorschlag aus dem Entwurfsstatus herauskommt) sind noch nicht final festgelegt. Der Vorschlag sieht vor, dass alle Transaktionen, die TempoSignature::Multisig enthalten, vor dem Inkrafttreten des TIP-1061 abgelehnt werden müssen. Ebenso müssen alle Transaktionen, die das Feld multisig_init mitführen, vor dem Start des Vorschlags abgelehnt werden.
Häufige Fragen
Was ist der grundlegende Unterschied zwischen nativen Multi-Signaturen in TIP-1061 und Smart-Contract-Wallets wie Safe?
TIP-1061 hebt die Multi-Signature-Verifikation auf die Protokollebene. Dadurch ist keine On-Chain-Deployment von Smart-Contract-Wallets wie Safe erforderlich, um dieselbe Schwellenwert-Kontrollfähigkeit zu erreichen. Das eliminiert Kosten für Vertragsdeployments, und die Kontoadresse bleibt stabil, nachdem sie aus der anfänglichen Konfiguration abgeleitet wurde. Sie ändert sich nicht mit Updates der Mitglieder.
Warum können die Multi-Signature-Kontoadressen nach Mitglieder-Updates unverändert bleiben?
Die Multi-Signature-Kontoadresse wird aus dem config_id-Hash abgeleitet. config_id wird aus der anfänglichen Inhabergruppe berechnet (einschließlich Adressen, Signaturtypen und Gewichten) sowie dem Schwellenwert. Während die Konten bestehen, ändert sich diese Ableitung nicht. Aufrufe von updateMultisigConfig aktualisieren lediglich die gespeicherte aktuelle Konfiguration, ohne config_id selbst oder die daraus abgeleitete Kontoadresse zu verändern.
Welche sind die wichtigsten Zielnutzungsfälle für TIP-1061?
Der Vorschlag nennt im Abschnitt „Motivation“ als Ziel-Szenarien Nutzer, bei denen „keiner der einzelnen privaten Schlüssel allein Gelder transferieren oder die operative Konfiguration ändern kann“. Konkret umfasst das Teams, Treasury-Einheiten, Validatoren und institutionelle Betreiber.
