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
~$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.