Back to Blog

Sichere das Solana-Ökosystem (6) – Multi-Sig2

April 24, 2022

0. Rückblick

1. Übersicht

Im vorherigen Beitrag haben wir die Implementierung von Multi-Sig besprochen. Die Implementierung geht jedoch davon aus, dass die Signaturen mehrerer Benutzer gleichzeitig off-chain gesammelt werden können. In diesem Beitrag stellen wir ein allgemeineres Multi-Sig-Programm vor, das es Benutzern ermöglicht, vollständig on-chain zu signieren.

2. Design des Testprogramms

Das Multi-Sig-Programm erlaubt es gültigen Unterzeichnern, den Antragsteller separat zu signieren, und jeder kann den Antragsteller ausführen, sobald er genehmigt wurde (genügend Signaturen gesammelt wurden). Der gesamte Testcode ist hier zu finden.

3. Code-Review

Dieses Programm führt zwei weitere Strukturen ein, und zwar TransactionAccount und Transaction. Die Struktur TransactionAccount dient zur Aufzeichnung der Kontoinformationen, die für die vorgeschlagene Transaktion verwendet werden. Die Struktur Transaction wird verwendet, um die Informationen eines Vorschlags aufzuzeichnen. Beachten Sie, dass das Attribut signers verwendet wird, um die Anzahl der gültigen Signaturen aufzuzeichnen. did_execute und is_initialized stellen sicher, dass die Ausführung und die Initialisierung nur einmal erfolgen können.

Das Programm bietet fünf verschiedene Anweisungen. Die Anweisung AllocatePDA zielt darauf ab, ein eindeutiges PDA-Konto zu erstellen und es als multisig-Konto zu verwenden. Es werden alle Informationen der gültigen Unterzeichner aufgezeichnet. In der Anweisung InitializeMultisig legen wir die Anzahl der Signaturen fest, die zur Ausführung der Anweisung erforderlich sind, sowie das Array der öffentlichen Schlüssel der gültigen Unterzeichner. Die Anweisung CreateTransaction wird verwendet, um einen Vorschlag zu erstellen, während der Unterzeichner den Vorschlag über die Anweisung approve genehmigen kann. Sobald die Anzahl der Genehmigungen den in multisig festgelegten Schwellenwert erreicht, kann die Anweisung ExecuteTransaction aufgerufen werden, um die Transaktion auszuführen.

Um einen Vorschlag einzureichen, können Benutzer die Anweisung createTransaction() aufrufen. Sie benötigt drei Konten; das erstellte transaction-Konto und die nächsten beiden Konten, die von der Zieltransaktion verwendet werden. Um zu verhindern, dass das Konto von böswilligen Benutzern neu initialisiert wird, überprüfen wir das Attribut is_initialized (Zeilen 161-163). Danach initialisieren wir die Struktur TransactionAccount mit den angegebenen Daten und serialisieren sie in das Datenkonto (Zeile 188).

In der Funktion Approve() überprüfen wir zuerst, ob das Transaction-Konto und das multisig-Konto vom Programm besessen werden. Beachten Sie, dass Konten, die von anderen Programmen erstellt wurden, hier von böswilligen Benutzern verwendet werden könnten, wenn keine Prüfung durchgeführt wird. Als nächstes vergleichen wir den öffentlichen Schlüssel des Unterzeichners mit den im multisig-Konto gespeicherten Schlüsseln. Wenn sie übereinstimmen, wird Ihre Signatur validiert und der entsprechende Wert auf true geändert.

In der Anweisung ExecuteTransaction() zählen wir die Anzahl der gültigen Signaturen. Wenn die Anzahl den Schwellenwert nicht erreicht, wird das Programm zurückgesetzt.

Danach initialisieren wir die Ziel-Instruction mit den angegebenen Attributen und rufen die Anweisung des Zielprogramms über die Funktion invoke_signed() auf. Wir setzen schließlich das Attribut did_execute auf true, falls der Vorschlag wiederholt ausgeführt wird.

Wir haben das Programm auf dem Testnet bereitgestellt und es kann unter dem folgenden Link gefunden werden.

https://explorer.solana.com/address/CPzn7ptnJntjUB4NGKqQGRai8NFLNwFaspmJ7nEGbMHe?cluster=testnet

4. Transaktion senden

Nach der Bereitstellung erstellen wir zuerst das multisig-Konto und legen das multisig-Konto als Administrator des config-Kontos fest, wenn das config-Konto initialisiert wird. Die zugehörigen Transaktionen sind unten aufgeführt, und die Reihenfolge ist: createMultisig() (in General-Multisig) -> Bereitstellung des PriviligeOwner-Programms -> Allocate() (in PrivligeOwner) -> InitializeConfig() (in PrivligeOwner).

https://explorer.solana.com/tx/2vXHmwbCsARstx8wi4eLACbrb6PuZZMktsqU8VnJLp64fvrpaE62QSTn5QLczzxnTvxRLWMSR3dKLGYXZasGMn69?cluster=testnet
https://explorer.solana.com/tx/2EMq9y6HNnXq1n2XsqrBkJd8RGL27PCj5T4JyJ71ZoA3ipUggT6dF6S6uDv4TtxGGKk8BmiAJHS7BFRgZqWjkWVb?cluster=testnet
https://explorer.solana.com/tx/3UhXKsTubUiPqRtLyNYskxvbyrTKHsbeptxuAfJQ348AU4b8gQET2HAMaqxwud6Wo3MKTYHWBneqa9z2WhCpwV6t?cluster=testnet
https://explorer.solana.com/tx/5NA7Yw23uRf48Q3BYM21dtS7gD9YMECij43ZaRLMPe7svt3bsv2TPWwbCRP5akDmttjLEHWZtpqrZrVLNr9QLyJY?cluster=testnet

Als nächstes rufen wir die Anweisung InitializeMultisig() auf. Wir übergeben vier Konten: das multisig-Konto und die Konten von drei gültigen Unterzeichnern. Wir setzen den Wert von m auf 2, was bedeutet, dass die Signaturen von zwei der drei Unterzeichner erforderlich sind, um privilegierte Funktionen auszuführen.

In der Funktion CreateTransaction() übergeben wir das erstellte Transaction-Konto, den öffentlichen Schlüssel des Zielprogramms (PrivilegeOwner) und den öffentlichen Schlüssel des config-Kontos (Zeile 306 - Zeile 307). Außerdem sollten wir _data auf 3 setzen, was der Anweisung unlock() im PrivilegeOwner-Programm entspricht.

Für den ersten Test genehmigt nur ein Unterzeichner den erstellten Vorschlag. In diesem Fall schlägt ExecuteTransaction() fehl, da nur begrenzte Signaturen gesammelt wurden. Die Konsole gibt die folgende Ausgabe aus.

Ein weiterer Unterzeichner genehmigt den erstellten Vorschlag und ruft ExecuteTransaction() auf. Die Gesamtzahl der Signaturen hat den Schwellenwert erreicht, sodass der Vorschlag erfolgreich ausgeführt werden kann.

https://explorer.solana.com/tx/55Qy93RxybsT7c5v9AFgN8Dt1h3AVJfbsosLbstYVB6paY1wmau5sdtLfGpfryXnZTsBNRauvwLSmAu2nABFxVCe?cluster=testnet
https://explorer.solana.com/tx/4XF4MUhL4oftkDt4sn7NoREmGqcDMVP6HGypvJQMtiAbBKiCuy4B98vhQKtvm4mPv7SprrDDVsiwgb6pNwgJcTwz?cluster=testnet

4. Zusammenfassung

In diesem Artikel stellen wir die allgemeine Implementierung von Multi-Sig in Solana vor. Die Implementierung nutzt die Funktion von PDA, die es dem Programm ermöglicht, die Transaktion automatisch mit PDA zu signieren, wenn die Anzahl der gültigen Signaturen der Anforderung entspricht. Bleiben Sie dran, wir werden in den kommenden Beiträgen mehr teilen.

Lesen Sie andere Artikel dieser Reihe:

Über BlockSec

BlockSec ist ein wegweisendes Blockchain-Sicherheitsunternehmen, das 2021 von einer Gruppe weltweit renommierter Sicherheitsexperten gegründet wurde. Das Unternehmen engagiert sich für die Verbesserung der Sicherheit und Benutzerfreundlichkeit der aufkommenden Web3-Welt, um deren Massenadoption zu fördern. Zu diesem Zweck bietet BlockSec Sicherheitsaudits für Smart Contracts und EVM-Ketten, die Phalcon-Plattform für Sicherheitsentwicklung und proaktive Bedrohungsabwehr, die MetaSleuth-Plattform für Geldverfolgung und -untersuchung sowie die MetaSuites-Erweiterung für Web3-Entwickler, um effizient in der Krypto-Welt zu navigieren.

Bis heute hat das Unternehmen über 300 angesehene Kunden wie MetaMask, Uniswap Foundation, Compound, Forta und PancakeSwap betreut und in zwei Finanzierungsrunden von namhaften Investoren, darunter Matrix Partners, Vitalbridge Capital und Fenbushi Capital, zweistellige Millionenbeträge erhalten.

Offizielle Website: https://blocksec.com/

Offizieller Twitter-Account: https://twitter.com/BlockSecTeam

Sign up for the latest updates
Drift Protocol Incident: Multisig Governance Compromise via Durable Nonce Exploitation
Security Insights

Drift Protocol Incident: Multisig Governance Compromise via Durable Nonce Exploitation

On April 1, 2026 (UTC), Drift Protocol on Solana suffered a $285.3M loss after an attacker exploited Solana's durable nonce mechanism to delay the execution of phished multisig approvals, ultimately transferring administrative control of the protocol's 2-of-5 Squads governance with zero timelock. With full admin privileges, the attacker created a malicious collateral market (CVT), inflated its oracle price, relaxed withdrawal protections, and drained USDC, JLP, SOL, cbBTC, and other assets through 31 rapid withdrawals in approximately 12 minutes. This incident highlights how durable nonce-based delayed execution can decouple signer intent from on-chain execution, bypassing the temporal assumptions that multisig security implicitly relies on.

Weekly Web3 Security Incident Roundup | Mar 23 – Mar 29, 2026
Security Insights

Weekly Web3 Security Incident Roundup | Mar 23 – Mar 29, 2026

This BlockSec weekly security report covers eight DeFi attack incidents detected between March 23 and March 29, 2026, across Ethereum and BNB Chain, with total estimated losses of approximately $1.53M. Incidents include a $679K flawed burn mechanism exploit on the BCE token, a $512K spot-price manipulation attack on Cyrus Finance's PancakeSwap V3 liquidity withdrawal, a $133.5K flash-loan-driven referral reward manipulation on a TUR staking contract, and multiple integer overflow, reentrancy, and accounting error vulnerabilities in DeFi protocols. The report provides detailed vulnerability analysis and attack transaction breakdowns for each incident.

Newsletter -  March 2026
Security Insights

Newsletter - March 2026

In March 2026, the DeFi ecosystem experienced three major security incidents. Resolv Protocol lost ~$80M due to compromised privileged infrastructure keys, BitcoinReserveOffering suffered ~$2.7M from a double-minting logic flaw, and Venus Protocol incurred ~$2.15M following a donation attack combined with market manipulation.