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
The Decentralization Dilemma: Cascading Risk and Emergency Power in the KelpDAO Crisis
Security Insights

The Decentralization Dilemma: Cascading Risk and Emergency Power in the KelpDAO Crisis

This BlockSec deep-dive analyzes the KelpDAO $290M rsETH cross-chain bridge exploit (April 18, 2026), attributed to the Lazarus Group, tracing a causal chain across three layers: how a single-point DVN dependency enabled the attack, how DeFi composability cascaded the damage through Aave V3 lending markets to freeze WETH liquidity exceeding $6.7B across Ethereum, Arbitrum, Base, Mantle, and Linea, and how the crisis forced decentralized governance to exercise centralized emergency powers. The article examines three parameters that shaped the cascade's severity (LTV, pool depth, and cross-chain deployment count) and provides an exclusive technical breakdown of Arbitrum Security Council's forced state transition, an atomic contract upgrade that moved 30,766 ETH without the holder's signature.

Weekly Web3 Security Incident Roundup | Apr 13 – Apr 19, 2026
Security Insights

Weekly Web3 Security Incident Roundup | Apr 13 – Apr 19, 2026

This BlockSec weekly security report covers four attack incidents detected between April 13 and April 19, 2026, across multiple chains such as Ethereum, Unichain, Arbitrum, and NEAR, with total estimated losses of approximately $310M. The highlighted incident is the $290M KelpDAO rsETH bridge exploit, where an attacker poisoned the RPC infrastructure of the sole LayerZero DVN to fabricate a cross-chain message, triggering a cascading WETH freeze across five chains and an Arbitrum Security Council forced state transition that raises questions about the actual trust boundaries of decentralized systems. Other incidents include a $242K MMR proof forgery on Hyperbridge, a $1.5M signed integer abuse on Dango, and an $18.4M circular swap path exploit on Rhea Finance's Burrowland protocol.

Weekly Web3 Security Incident Roundup | Apr 6 – Apr 12, 2026
Security Insights

Weekly Web3 Security Incident Roundup | Apr 6 – Apr 12, 2026

This BlockSec weekly security report covers four DeFi attack incidents detected between April 6 and April 12, 2026, across Linea, BNB Chain, Arbitrum, Optimism, Avalanche, and Base, with total estimated losses of approximately $928.6K. Notable incidents include a $517K approval-related exploit where a user mistakenly approved a permissionless SquidMulticall contract enabling arbitrary external calls, a $193K business logic flaw in the HB token's reward-settlement logic that allowed direct AMM reserve manipulation, a $165.6K exploit in Denaria's perpetual DEX caused by a rounding asymmetry compounded with an unsafe cast, and a $53K access control issue in XBITVault caused by an initialization-dependent check that failed open. The report provides detailed vulnerability analysis and attack transaction breakdowns for each incident.