Ein inoffizieller Leitfaden zum Schreiben von Qubic Smart Contracts

Dieser inoffizielle Leitfaden bietet einen Überblick über die Entwicklung von Qubic Smart Contracts und beschreibt wesentliche Funktionen, Speicherzuweisung und Testverfahren, um eine robuste und effiziente Bereitstellung zu gewährleisten.

Qsilver · 27. Juni 2024.

Einführung

Willkommen zum inoffiziellen Leitfaden zum Schreiben von Qubic Smart Contracts (SC). Dieser Leitfaden soll einen klaren und prägnanten Überblick darüber geben, wie Smart Contracts im Qubic-Ökosystem entwickelt und implementiert werden, basierend auf der Kern-QPI-Dokumentation.

Überblick über Qubic Smart Contracts

Derzeit ist die Hauptdokumentation für das Schreiben von SCs die QPI-Datei auf GitHub. QPI steht für Qubic Programming Interface, analog zu einer API (Application Programming Interface), jedoch spezifisch für Qubic.

Die QPI-Datei umfasst:

• Verbotene Zeichen: Keine Multiplikations- oder Divisionsoperatoren, keine Präprozessordirektiven.
• Kerncode-Struktur:
• 5000 Codezeilen: Definiert jede Art von Variablengröße von einzelnen Bits bis hin zu Arrays mit Millionen von Elementen.
• 1000 Codezeilen: Verwalten verschiedene Warteschlangen und zugehörige Datentypen für eine effiziente Datenverarbeitung.
• Die letzten wenigen Hundert Zeilen: Ermöglichen den Zugriff auf den Qubic-Netzwerkstatus.

Wichtige Funktionen in QPI

Hier sind einige der wesentlichen Funktionen, die in der QPI bereitgestellt werden:

id arbitrator() const;
id computor(uint16 computorIndex) const; // [0..675]
uint8 day() const; // [1..31]
uint8 dayOfWeek() const; // [0..6]
uint16 epoch() const; // [0..9'999]
bit getEntity() const; // Gibt "true" zurück, wenn die Entität gefunden wurde, andernfalls "false"
uint8 hour() const; // [0..23]
sint64 invocationReward() const;
id invocator() const; // Gibt die ID des Benutzers/Vertrags zurück, der diesen Vertrag ausgelöst hat; gibt NULL_ID zurück, wenn keiner
template <typename T> id K12(const T& data) const;
uint16 millisecond() const; // [0..999]
uint8 minute() const; // [0..59]
uint8 month() const; // [1..12]
id nextId(const id& currentId) const;
sint64 numberOfPossessedShares() const;
id originator() const; // Gibt die ID des Benutzers zurück, der die gesamte Kette von Aufrufen ausgelöst hat; gibt NULL_ID zurück, wenn keiner
uint8 second() const; // [0..59]
bit signatureValidity() const;
uint32 tick() const; // [0..999'999'999]
uint8 year() const; // [0..99] (0 = 2000, 1 = 2001, …, 99 = 2099)

Was bedeutet das?

Qubic Smart Contracts sind Turing-vollständig, was bedeutet, dass man praktisch jede Rechenlogik implementieren kann. Bestimmte Einschränkungen sorgen jedoch dafür, dass SCs in einer stark abgeschotteten und sicheren Umgebung ausgeführt werden.

Speicherzuweisung

SCs verwenden ein statisches Speicherzuweisungsmodell, bei dem der gesamte Speicher vorab zugewiesen werden muss. Dieses Design ist entscheidend für die effiziente Verwaltung von Datenstrukturen innerhalb eines 1GB-RAM-Limits. Obwohl dieses Limit in Zukunft verdoppelt werden soll, bleibt es eine feste Zuordnung, die eine sorgfältige Planung der Speichernutzung erfordert.

Bibliotheksnutzung

Derzeit können in SCs keine externen Bibliotheken verwendet werden; alle erforderlichen Codes müssen direkt in die Quelle aufgenommen werden. Mit der Zeit, wenn mehr SCs verschiedene Bibliotheken einbeziehen, könnten diese für die öffentliche Nutzung in anderen SCs verfügbar werden.

Transaktionen und RCF-Netzwerknachrichten

Jeder SC hat eine eindeutige Adresse, die von einem öffentlichen Schlüssel abgeleitet ist, wobei die Vertrags-ID die niedrigsten 64 Bits ist. SCs werden durch Transaktionen auf diese Adresse aufgerufen, wobei inputData die Operation spezifiziert. Zusätzlich kann der Status eines SCs mit RCF-Netzwerknachrichten abgefragt werden.

Beispiel: Airdrop SC

Ein Airdrop-SC könnte durch einen Datensatz iterieren und QU oder Token an jede Adresse in einem Tick pro SC-Transaktion verteilen. Mit einem derzeitigen Limit von 1024 Transaktionen pro Tick könnte dies zu bis zu 500 Millionen Übertragungen pro Tick führen. Der tatsächliche Durchsatz hängt von der Komplexität des SC ab.

Wie testet man seinen SC

1. Entwickeln Sie Ihren SC: Schreiben und debuggen Sie Ihren Smart Contract-Code.
2. Aktualisieren Sie qubic-cli: Stellen Sie sicher, dass Ihre SC-Transaktionen und RCF-Funktionen integriert sind.
3. Erstellen Sie ein Testnet-Core-Update: Integrieren Sie Ihren SC in eine Testnet-Umgebung.
4. Tests durchführen: Verwenden Sie qubic-cli, um Ihren Testnet-Knoten abzufragen und die SC-Leistung zu validieren.
5. Stresstests: Führen Sie Lasttests und automatisierte Tests durch, um die Stabilität zu gewährleisten.
6. Zur Genehmigung einreichen: Sobald das Debuggen abgeschlossen ist, reichen Sie Ihren SC zur Quorum-Genehmigung ein und fahren dann mit dem IPO fort.

Indem Sie diese Schritte befolgen, können Sie sicherstellen, dass Ihre Smart Contracts robust, effizient und bereit für die Bereitstellung im Qubic-Netzwerk sind. Viel Spaß beim Programmieren!

Lesen Sie Qsilvers „Inoffizielle“ Serie

• 🇩🇪Ein inoffizielles Qubic Zwischenpapier
• 🇩🇪Qubic-Krypto-Details
• 🇩🇪Ein inoffizieller Leitfaden zur Integration von Qubic-Diensten
• 🇩🇪Ein inoffizieller Leitfaden zum Schreiben von Qubic Smart Contracts

Für die neuesten Updates, treten Sie dem Valis Discord bei, folgen Sie uns auf X und setzen Sie ein Lesezeichen für unseren Blog.

Auf dieser Seite

• Ein inoffizieller Leitfaden zum Schreiben von Qubic Smart Contracts
• Einführung
• Überblick über Qubic Smart Contracts
• Wichtige Funktionen in QPI
• Was bedeutet das?
• Speicherzuweisung
• Bibliotheksnutzung
• Transaktionen und RCF-Netzwerknachrichten
• Beispiel: Airdrop SC
• Wie testet man seinen SC
• Lesen Sie Qsilvers „Inoffizielle“ Serie