Back to Blog

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

April 24, 2022
6 min read

0. Rückblick

1. Überblick

Im vorherigen Beitrag haben wir die Implementierung des Multi-Sig diskutiert. 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 (genug Signaturen gesammelt wurden). Der gesamte Testcode ist hier zu finden.

3. Code-Überprüfung

Dieses Programm führt zwei weitere Strukturen ein: TransactionAccount und Transaction. Die Struktur TransactionAccount ist für die Aufzeichnung der Kontoinformationen konzipiert, 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 durchgeführt werden 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 gespeichert. In der Anweisung InitializeMultisig legen wir die Anzahl der für die Ausführung der Anweisung erforderlichen Signaturen und das Array der öffentlichen Schlüssel der gültigen Unterzeichner fest. Die Anweisung CreateTransaction wird verwendet, um einen Vorschlag zu erstellen, während ein 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 neu erstellte transaction-Konto und die beiden folgenden Konten, die von der Zieltransaktion verwendet werden. Um zu verhindern, dass das Konto von böswilligen Benutzern erneut initialisiert wird, überprüfen wir das Attribut is_initialized (Zeile 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 zunächst, ob das Transaction-Konto und das multisig-Konto dem Programm gehören. Beachten Sie, dass von anderen Programmen erstellte Konten hier von böswilligen Benutzern verwendet werden könnten, wenn keine Prüfung stattfindet. Als Nächstes gleichen wir den öffentlichen Schlüssel des Unterzeichners mit den im multisig-Konto gespeicherten Schlüsseln ab. Bei Übereinstimmung 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 folgendem Link gefunden werden:

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

4. Transaktion senden

Nach der Bereitstellung erstellen wir zunächst das multisig-Konto und setzen das multisig-Konto als Administrator des config-Kontos bei der Initialisierung des config-Kontos. Die entsprechenden Transaktionen sind unten aufgeführt, und die Reihenfolge ist: createMultisig() (in General-Multisig) -> Deploy PriviligeOwner-Programm -> 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 zwei der drei Signaturen der 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 müssen wir _data auf 3 setzen, was der Anweisung unlock() im PrivilegeOwner-Programm entspricht.

Beim ersten Test genehmigt nur ein Unterzeichner den erstellten Vorschlag. In diesem Fall schlägt ExecuteTransaction() fehl, da nur wenige 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 des 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 die Anforderung erfüllt. Bleiben Sie dran, wir werden in den kommenden Beiträgen mehr teilen.

Lesen Sie weitere Artikel dieser Serie:

Über BlockSec

BlockSec ist ein führendes Unternehmen für Blockchain-Sicherheit, das 2021 von einer Gruppe weltweit renommierter Sicherheitsexperten gegründet wurde. Das Unternehmen hat sich der Verbesserung der Sicherheit und Benutzerfreundlichkeit für die aufstrebende Web3-Welt verschrieben, um deren massenhafte Akzeptanz zu fördern. Zu diesem Zweck bietet BlockSec Dienstleistungen für die Sicherheitsprüfung von Smart Contracts und EVM-Chains, die Phalcon-Plattform für die sichere Entwicklung und proaktive Abwehr von Bedrohungen, die MetaSleuth-Plattform für die Nachverfolgung und Untersuchung von Geldern sowie die MetaSuites-Erweiterung für Web3-Entwickler, um effizient in der Krypto-Welt zu surfen.

Bisher hat das Unternehmen über 300 angesehene Kunden wie MetaMask, Uniswap Foundation, Compound, Forta und PancakeSwap betreut und in zwei Finanzierungsrunden von namhaften Investoren wie Matrix Partners, Vitalbridge Capital und Fenbushi Capital Millionen von US-Dollar 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.