Back to Blog

Sichern Sie das Solana-Ökosystem (1) — Hallo Solana

March 9, 2022
5 min read

1. Einleitung

Solana ist ein leistungsstarkes, erlaubnisfreies Layer-1-Blockchain-System, das die Entwicklung von Programmen (Smart Contracts) in verschiedenen Sprachen (z. B. Rust, C++ und C) unterstützt. Mithilfe von Tower BFT (Byzantine Fault Tolerant) kann es Tausende von Transaktionen pro Sekunde verarbeiten. Eine der Kerninnovationen von Solana ist Proof of History (PoH), eine global verfügbare, erlaubnisfreie Zeitquelle im Netzwerk, die vor dem Konsens arbeitet. Wir werden PoH in Zukunft detaillierter diskutieren.

2. Unsere Mission

BlockSec ist ein Blockchain-Sicherheitsunternehmen, dessen Mission es ist, „das DApp-Ökosystem zu sichern“. Daher bieten wir nicht nur Audit-Services für Verträge, sondern auch Vorschläge zur sicheren Programmierung von Smart Contracts für die gesamte Community. Angesichts der Popularität, der hohen Leistung und des großartigen Designs von Solana konzentriert sich diese Serie auf die Sicherheit von Smart Contracts in Rust auf Solana.

3. Hello Solana

Bevor wir Solana Smart Contracts aus Sicherheitsperspektive diskutieren, müssen wir zunächst wissen, wie man Solana Smart Contracts schreibt, kompiliert und bereitstellt. Hier verwenden wir Hello World als illustratives Beispiel.

3.1 Code-Review

In Solana wird ein Smart Contract als Programm bezeichnet. Das Hello World-Programm dient dazu, einen Zähler zu verwalten, der die Anzahl der Aufrufe des Zielkontos (das dem Programm gehört) durch den Client aufzeichnet, und gibt diese Zahl als Ausgabe aus.

Gehen wir nun den gesamten Vertrag durch.

Zeile 1 bis Zeile 9 bringen mithilfe des Schlüsselworts use viele Bibliotheken explizit in den Geltungsbereich.

In Zeile 12 wird [derive(BorshSerialize, BorshDeserialize, Debug)] verwendet, um an die Struktur GreetingAccount übergebene Parameter zu serialisieren und zu deserialisieren, die von Zeile 13 bis Zeile 16 definiert ist. Die Struktur enthält ein öffentliches Mitglied namens counter vom Typ u32. Danach, wie auskommentiert, exportiert Zeile 19 den Einstiegspunkt des Programms, nämlich die Funktion process_instruction.

Die Funktion process_instruction akzeptiert drei Parameter (d. h. program_id, accounts und _instruction_data). Beachten Sie, dass program_id der öffentliche Schlüssel (d. h. die Adresse) des bereitgestellten Programms ist, während accounts das Konto enthält, das begrüßt werden soll. _instruction_data ist leer und wird nicht verwendet.

Um mehr über Programme und Konten in Solana zu erfahren, siehe Solana-Dokumentation.

In Zeile 27 wird eine Begrüßungsnachricht ausgegeben. Von Zeile 30 bis Zeile 33 werden die Konten durchlaufen und das spezifische Konto, das begrüßt werden soll, extrahiert. Danach wird der Eigentümer des Kontos überprüft und er muss mit der program_id übereinstimmen, um sicherzustellen, dass das Programm in das Konto schreiben kann. Schließlich wird das greeting_account mit try_from_slice extrahiert und der Zähler um 1 erhöht.

3.2 Programm kompilieren

Um das Programm zu kompilieren, müssen wir die Solana CLI mit dem folgenden Befehl installieren.

sh -c "$(curl -sSfL https://release.solana.com/v1.9.9/install)"

Um zu bestätigen, dass die Solana CLI erfolgreich installiert wurde, können wir ihre Version mit dem folgenden Befehl überprüfen.

solana --version

Beachten Sie, dass Rust und NodeJS ebenfalls erforderlich sind.

Zum Kompilieren des Programms können wir den folgenden Befehl verwenden.

cargo build-bpf --manifest-path=./src/program-rust/Cargo.toml --bpf-out-dir=dist/program

Das kompilierte Programm wird im Verzeichnis generiert, das in --bpf-out-dir angegeben ist, mit dem Namen helloworld.so.

3.3 Vertrag bereitstellen

Um das kompilierte Programm auf Solana bereitzustellen, müssen wir zuerst ein Cluster auswählen. In Solana gibt es vier verschiedene Cluster: mainnet, testnet, devnet und localnet. In diesem Beitrag stellen wir das kompilierte Programm zu Demonstrationszwecken nur auf devnet bereit.

Wir verwenden den folgenden Befehl, um das Cluster anzugeben.

solana config set --url https://api.devnet.solana.com

Danach müssen wir die Wallet für die Bereitstellung generieren. solana-keygen new --force hilft bei der Generierung der Wallet. Weitere Informationen finden Sie in der Solana-Dokumentation.

Da das neu erstellte Konto kein Guthaben zum Bezahlen der Transaktionsgebühren hat, airgroppen wir 1 SOL mit dem folgenden Befehl.

solana airdrop 1 <YourPublicKey> --url https://api.devnet.solana.com

Jetzt sind wir bereit, den Vertrag bereitzustellen.

solana program deploy dist/program/helloworld.so

Benutzer können Programme und Transaktionen im Devnet Explorer einsehen. In dieser Demo finden Sie das bereitgestellte Programm unter diesem Link.

3.4 Transaktion senden

Es wird empfohlen, Skripte, sogenannte Clients, zum Senden von Transaktionen in Solana zu schreiben. Glücklicherweise bietet Solana den Beispielcode. Um den Client auszuführen, müssen wir zuerst die Client-Abhängigkeiten installieren.

npm install

Nach Abschluss der Installation führen wir die Funktion main in der Datei main.ts mit dem folgenden Befehl aus.

npm run start

In der Funktion main stellt der Client zunächst die Verbindung zum angegebenen Cluster (d. h. Devnet) mit der Funktion establishConnection() her, prüft den Zahler, der die Transaktionsgebühren mit der Funktion establishPayer bezahlt, und validiert die Existenz des Programms und des zu begrüßenden Kontos mit der Funktion checkProgram. Beachten Sie, dass das erforderliche Konto erstellt wird, wenn es nicht existiert, indem eine Transaktion gesendet wird. In unserer Demonstration wird das Konto in dieser Transaktion erstellt.

Wenn alles bereit ist, wird die Funktion sayHello aufgerufen, um das Zielkonto zu begrüßen. Die Transaktion besteht aus einer Anweisung. Diese Anweisung empfängt keys, die ein Konto enthalten. Der öffentliche Schlüssel des Kontos (d. h. greetedPubkey) ist das Zielkonto, das begrüßt werden soll. Beachten Sie, dass dieses Konto für die Speicherung verwendet wird und kein Signierer ist. In diesem Fall ist das Attribut isSigner false, während isWritable true ist. programId ist der Eigentümer von greetedPubkey und ist auch die Adresse des bereitgestellten Vertrags. Beachten Sie, dass data leer ist und in dieser Transaktion nicht verwendet wird. In Zeile 208 wird die Funktion sendAndConfirmTransaction aufgerufen und die Transaktion wird an das Cluster gesendet.

Sie können die detaillierte Transaktion hier anzeigen.

4. Fazit

In diesem Artikel haben wir kurz den Hintergrund von Solana vorgestellt und das Beispielprojekt (d. h. Hello World) durchlaufen. Wir haben gelernt, wie man ein Programm auf Solana bereitstellt und wie man den Client verwendet, um mit dem On-Chain-Programm zu interagieren. Bitte folgen Sie weiterhin unserem Blog, wir werden in dieser Serie konsequent weitere Artikel veröffentlichen.

Lesen Sie andere Artikel dieser Serie:

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.