Back to Blog

Sichere das Solana-Ökosystem (5.0) — Multi-Sig

October 4, 2022
5 min read

0. Übersicht

1. Überblick

Im vorherigen Blogbeitrag haben wir die Kontenvalidierung, die für die Zugriffskontrolle in Solana-Programmen wichtig ist, besprochen. Für eine dezentrale DApp und zum Schutz potenzieller Lecks privater Schlüssel ist Multi-Sig jedoch sehr wichtig. In diesem Beitrag stellen wir die Implementierung von Multi-Sig vor.

2. Konzept von Multi-Sig

Multi-Sig ist ein digitales Signaturschema, das es einer Gruppe von Benutzern ermöglicht, eine einzelne Transaktion zu signieren. Die Transaktion kann ein Aufruf einer privilegierten Funktion (z. B. Minten), eine Anweisung zur Überweisung von Geldern usw. sein. Der Mechanismus von Multi-Sig besteht darin, dass bei n Parteien mit ihren eigenen privaten Schlüsseln mindestens m der privaten Schlüssel signieren müssen, um die Transaktion auszuführen. Dies kann die Gelder in DeFi viel sicherer machen und potenzielle Risiken wie den Diebstahl privater Schlüssel und Rug Pulls abwehren.

3. Verwendung von Multi-Sig

In Solana gibt es ein Multi-Sig-Programm von Serum, das der Logik des von OpenZeppelin entwickelten Multi-Sig sehr ähnlich ist. Dies ermöglicht es mehreren Benutzern, eine Transaktion vollständig on-chain zu signieren. Wenn Sie jedoch alle erforderlichen Signaturen off-chain sammeln können, kann der Prozess einfacher sein. Um dies zu veranschaulichen, fügen wir die Multi-Sig-Funktionalität in den Testcode des letzten Beitrags ein. Der gesamte Testcode ist hier zu finden.

3.1 Code-Review

Im zuletzt vorgestellten Projekt ersetzen wir den Administrator des config-Kontos durch ein multisig-Konto. In diesem Fall muss der Client, um die Anweisung Lock und Unlock auszuführen, genügend Signaturen der gültigen Eigentümer in die Transaktion aufnehmen.

Wir fügen eine Struktur namens Multisig hinzu, die aus vier Attributen besteht. Dies sind die Anzahl der Signaturen, die zum Ausführen der Anweisung erforderlich sind, die Gesamtzahl der gültigen Unterzeichner, der Status des Kontos (ob es initialisiert ist oder nicht) und das Array der öffentlichen Schlüssel der gültigen Unterzeichner.

Dementsprechend fügen wir auch die Anweisung InitializeMultisig in instruction.rs hinzu. Beachten Sie, dass sie das Argument m (u8) von der Client-Seite empfängt. Dieser Wert wird in die Funktion InitializeMultisig() eingespeist.

Die Funktion InitializeMultisig() empfängt die erstellten Konten und den Wert m. Um zu verhindern, dass das Konto von böswilligen Benutzern erneut initialisiert wird, validieren wir, ob das Konto bereits initialisiert wurde (Zeile 385-388). Danach initialisieren wir das Multi-Sig-Konto, indem wir den Wert m, n und den öffentlichen Schlüssel der Unterzeichner zuweisen.

In der Funktion Lock() prüfen wir, ob das Administrator-Konto des config-Kontos ein Multi-Sig-Konto ist. Wenn ja, validiert und zählt es die übergebenen Signaturen (Zeile 151 bis 158). Sobald die Anzahl der gültigen Signaturen den erforderlichen Betrag erreicht oder überschreitet, werden die Türen verriegelt (Zeile 163 bis 168). Die Implementierung von Multi-Sig in der Funktion Unlock() ist der Funktion Lock() ähnlich.

Wir haben das Programm im Testnetz bereitgestellt und es ist unter folgendem Link zu finden:

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

3.2 Transaktion senden

In der Funktion InitializeMultisig() umfasst keys vier Konten. Dies sind das Multi-Sig-Konto und drei gültige Unterzeichnerkonten. Beachten Sie, dass einer der Unterzeichner auch der Gebührenzahler der Transaktion ist. Wir setzen den Wert von m auf 2, was bedeutet, dass zwei der drei Unterzeichnersignaturen erforderlich sind, um privilegierte Funktionen auszuführen.

Wir setzen auch den Administrator des config-Kontos als multisig-Konto, indem wir den öffentlichen Schlüssel des multisig-Kontos in den Anweisungsdaten übergeben.

In der Funktion lock() übergeben wir zusätzlich zum config-Konto (Zeile 410) das multisig-Konto (Zeile 411) und zwei (mindestens) gültige Unterzeichnerkonten (Zeile 412 - Zeile 413). Wir setzen das Attribut isSigner für die Unterzeichner auf true. Auch hier ist die Logik der Funktion unlock() ähnlich.

Alle Testtransaktionen sind unten aufgeführt. Der gesamte Prozess lautet: Allocate PDA()-> InitializeMultisig() -> InitializeDoor()-> InitializeConfig()-> Unlock() -> Open() -> Close()-> Lock().

https://explorer.solana.com/tx/2inXLHv34NzkmwmvQ7iimdNbEX2Hj8qWS3MVteAPtwhCAPy1yxXXdvfzMmUL7tESsd4wat4LMcPNiEQav18kQTrZ?cluster=testnet
https://explorer.solana.com/tx/4GErNusHLXpUHBsAJ55c7v1Ur1jfv5hAR88CK8nabLnzc92b1UhDnNRryKVjKmcnJDXppmyk6m5RUdpR2w7MEbrU?cluster=testnet
https://explorer.solana.com/tx/2S8h66oWfh7cn4fwFCVPtgGw1o3NgzyWwU1GyRpDjH4PEBfe8LDMZGAEBYLRJpzL3anH9ENShntjg3q5K8gcZSrN?cluster=testnet
https://explorer.solana.com/tx/nVKxPYegbpH324y57uHDZiajpNA5u4bSSJ2gHFHHRx4GJBy1DcpxnccKh1Ltkv9dah1qJNi9jWuBnXbyHWXCJyw?cluster=testnet
https://explorer.solana.com/tx/3KK5CU88oV59VfdTrNpT4LsiUsetuGdc6qW3sNyyGEWVYtKJfD6XA2Nfknrriwuka9wknHpZs3WZ1WkeduDA1pZX?cluster=testnet
https://explorer.solana.com/tx/3rFo37CrLSsMehLk4kwmMSDnbRfLfoPCWZzRDXhwwLg1uq32gu4ddxkYYB3pJX1yiMN8MofnV1Y9CSaf8bQaNJ9Y?cluster=testnet
https://explorer.solana.com/tx/5yFq4dZAMpccn96jKNkYFVcmhmtrwZYSFEQ6pkNgSMd7e1Vy1ztAM3RdFUZjEtThjFssz1TFytowePPyY59we9rX?cluster=testnet
https://explorer.solana.com/tx/3Ut4DqjCQi1MoCsjRx24DxykyDMsmyRsjJSXS7D4FBeZQwrx4UzxWt2gDe6YRiwUHzFkH3eWkFHub6FNSp2Us4Q7?cluster=testnet

3.3 Testtransaktion

Um zu testen, ob das Multi-Sig tatsächlich funktioniert, modifizieren wir das Skript des Clients.

Wie oben gezeigt, übergeben wir nur ein Unterzeichnerkonto und stellen nur eine gültige Signatur bereit.

Wir stellen fest, dass die Tür aufgrund unzureichender Signaturen nicht entriegelt werden kann.

4. Zusammenfassung

In diesem Artikel stellen wir die einfache Implementierung von Multi-Sig in Solana vor. Dies gilt für Szenarien, in denen Sie Signaturen von mehreren Benutzern off-chain sammeln können. Szenarien, bei denen Transaktionen vollständig on-chain signiert werden müssen, werden später vorgestellt. Bleiben Sie dran, und wir werden in zukünftigen Beiträgen mehr teilen.

Weitere Artikel in dieser Reihe lesen:


Ü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 für die aufstrebende Web3-Welt, um deren Massenadoption zu fördern. Zu diesem Zweck bietet BlockSec Sicherheitsprüfungen für Smart Contracts und EVM-Ketten, die Phalcon-Plattform für die sichere Entwicklung und proaktive Bedrohungsabwehr, die MetaSleuth-Plattform für die Nachverfolgung von Geldern und die Untersuchung sowie die MetaSuites-Erweiterung für Web3-Entwickler, um effizient in der Krypto-Welt zu surfen.

Bis heute hat das Unternehmen über 300 angesehene Kunden wie MetaMask, Uniswap Foundation, Compound, Forta und PancakeSwap betreut und in zwei Finanzierungsrunden zweistellige Millionenbeträge von namhaften Investoren wie Matrix Partners, Vitalbridge Capital und Fenbushi Capital 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.