Back to Blog

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

April 10, 2022
5 min read

0. Rückblick

1. Überblick

Im vorherigen Blog-Artikel haben wir die Kontenvalidierung, die für die Zugriffskontrolle in Solana-Programmen wichtig ist, besprochen. Für eine dezentrale DApp und zum Schutz vor potentiellem Verlust 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 könnte ein Aufruf einer Privilegierungsfunktion (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 unterzeichnet werden müssen, um die Transaktion auszuführen. Dies kann die Gelder in DeFi viel sicherer machen und potenzielle Risiken wie den Verlust privater Schlüssel und Rug Pulls abwehren.

3. Nutzung 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. Zur Veranschaulichung fügen wir die Multi-Sig-Funktionalität in den Testcode aus dem letzten Beitrag ein. Der gesamte Testcode ist hier zu finden.

3.1 Code-Überprüfung

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 zur Ausführung 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.

Entsprechend 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 an die Funktion InitializeMultisig() übergeben.

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 des Multi-Sig in der Funktion Unlock() ist der Funktion Lock() ähnlich.

Wir haben das Programm auf dem Testnet 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() enthält der keys-Abschnitt vier Konten. Dies sind das Multi-Sig-Konto und die Konten von drei gültigen Unterzeichnern. 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 Signaturen der Unterzeichner 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-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 wirklich funktioniert, haben wir das Skript des Clients modifiziert.

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 entsperrt 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 Signaturen von mehreren Benutzern off-chain gesammelt werden 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 den kommenden Beiträgen weitere Informationen teilen.

Lesen Sie andere Artikel dieser Serie:


Ü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 aufstrebenden Web3-Welt, um deren Massenadaption zu erleichtern. Zu diesem Zweck bietet BlockSec Sicherheitsaudits für Smart Contracts und EVM-Ketten, die Phalcon-Plattform für die Entwicklung von Sicherheit und proaktives Blockieren von Bedrohungen, die MetaSleuth-Plattform für die Verfolgung und Untersuchung von Geldern 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 Millionen von US-Dollar von führenden 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
~$15.9M Lost: Trusted Volumes & More | BlockSec Weekly
Security Insights

~$15.9M Lost: Trusted Volumes & More | BlockSec Weekly

This BlockSec bi-weekly security report covers 11 notable attack incidents identified between April 27 and May 10, 2026, across Sui, Ethereum, BNB Chain, Base, Blast, and Berachain, with total estimated losses of approximately $15.9M. Three incidents are analyzed in detail: the highlighted $1.14M Aftermath Finance exploit on Sui, where a signed/unsigned semantic mismatch in the builder-fee validation allowed an attacker to inject a negative fee that was converted into positive collateral during settlement; the $5.87M Trusted Volumes RFQ authorization mismatch on Ethereum; and the $5.7M Wasabi Protocol infrastructure-to-contract-control compromise across multiple EVM chains.

Newsletter - April 2026
Security Insights

Newsletter - April 2026

In April 2026, the DeFi ecosystem experienced three major security incidents. KelpDAO lost ~$290M due to an insecure 1-of-1 DVN bridge configuration exploited via RPC infrastructure compromise, Drift Protocol suffered ~$285M from a multisig governance takeover leveraging Solana's durable nonce mechanism, and Rhea Finance incurred ~$18.4M following a business logic flaw in its margin-trading module that allowed circular swap path manipulatio

~$7.04M Lost: GiddyDefi, Volo Vault & More | BlockSec Weekly
Security Insights

~$7.04M Lost: GiddyDefi, Volo Vault & More | BlockSec Weekly

This BlockSec weekly security report covers eight attack incidents detected between April 20 and April 26, 2026, across Ethereum, Avalanche, Sui, Base, HyperLiquid, and MegaETH, with total estimated losses of approximately $7.04M. The highlighted incident is the $1.3M GiddyDefi exploit, where the attacker did not break any cryptography or use a flash loan but simply replayed an existing on-chain EIP-712 signature with the unsigned `aggregator` and `fromToken` fields swapped out for a malicious contract, demonstrating how partial signature coverage turns any historical signature into a generic permit. Other incidents include a $3.5M Volo Vault operator key compromise on Sui, a $1.5M Purrlend privileged-role takeover, a $413K SingularityFinance oracle misconfiguration, a $142.7K Scallop cross-pool index injection, a $72.35K Kipseli Router decimal mismatch, a $50.7K REVLoans (Juicebox) accounting pollution, and a $64K Custom Rebalancer arbitrary-call exploit.