Smart Contracts in der Programmiersprache Rust

Wie wäre es, Rust in Kombination mit WebAssembly zu nutzen, um Smart Contracts zu entwickeln, die gegebenenfalls Millionen von Krypto-Tokens verwalten können?

In Pocket speichern vorlesen Druckansicht 59 Kommentare lesen
Smart Contracts in der Programmiersprache Rust

(Bild: phive/Shutterstock.com)

Lesezeit: 12 Min.
Von
  • Lars Hupel
Inhaltsverzeichnis

Die öffentliche Kryptoplattform Ethereum hat das Konzept der Smart Contracts popularisiert. Doch die hierfür gängige Programmiersprache Solidity leidet unter systematischen Problemen, die des Öfteren zu spektakulären Sicherheitslücken führen. Eine neue Generation von Sprachen schickt sich an, diese Mankos auszugleichen. Besonders interessant ist dabei die – derzeit noch experimentelle – Möglichkeit, WebAssembly als Bytecode-Format für Smart Contracts zu benutzen. Passend dazu eignet sich Rust als Hochsprache, die WASM-Code erzeugen kann.

Young Professionals schreiben für Young Professionals

Dieser Beitrag ist Teil einer Artikelserie, zu der die Heise-Redaktion junge Entwickler:innen einlädt – um über aktuelle Trends, Entwicklungen und persönliche Erfahrungen zu informieren. Bist du selbst ein "Young Professional" und willst einen (ersten) Artikel schreiben? Schicke deinen Vorschlag gern an die Redaktion: developer@heise.de. Wir stehen dir beim Schreiben zur Seite.

Ethereum ist eine erstmals 2015 von Vitalik Buterin, Gavin Wood und Jeffrey Wilcke vorgestellte Kryptowährung und Applikationsplattform. Die zeitweilig genutzte markige Bezeichnung als "World Computer" deutet darauf hin, dass die Kryptowährung nur eine Nebensache ist und der Hauptfokus den Smart Contracts gilt. Im Gegensatz zu Bitcoin (und Derivaten), in denen nur eine primitive Stack-basierte Skriptsprache zur Verfügung steht, verfügt Ethereum über eine vollwertige virtuelle Maschine, die eine spezielle Assembler-Sprache auszuführen vermag.

Ein Smart Contract ist dabei vergleichbar zu einem Objekt in gängigen Programmiersprachen – eine Ansammlung an aufrufbaren Methoden –, das in der Blockchain gespeichert ist und seinen eigenen Zustand verwaltet. Während sich der Zustand durch Methodenaufrufe ändern kann, bleibt der Code stets fix.

Prinzipiell kann jeder Mensch so einen Smart Contract auf der Ethereum-Blockchain aufrufen, solange er der Transaktion genügend Honorar mitschickt: das sogenannte Sprit. Es wird in Ether, der eingebauten Kryptowährung von Ethereum, gemessen. Er sorgt dafür, dass die Ausführung von Code endlich ist, das heißt niemand gratis Berechnungen ausführen kann. Ganz ähnlich wie ein Notar, der schließlich Gebühren für das Ausführen von Verträgen verlangt.

Die Ethereum-VM versteht eine Reihe von Assemblerbefehlen, sodass Verträge auf der untersten Ebene etwa so aussehen:

PUSH1 0x80
PUSH1 0x40
MSTORE
CALLVALUE
DUP1
ISZERO

Solchen Code möchte aber niemand von Hand schreiben. Daher gibt es Programmiersprachen, die sich mehr oder weniger an bekannte Sprachen anlehnen, aber eben zu Ethereum-Bytecode kompilieren. Der Platzhirsch ist die Sprache Solidity, deren Syntax an JavaScript angelehnt ist:

pragma solidity >=0.4.22 <0.6;

contract Wallet {
    uint256 balance;
    address payable owner;
    constructor () public {
        balance = 0;
        owner = msg.sender;
    }
    function addfund() payable public returns (uint256) {
        require (msg.sender == owner);
        balance += msg.value;
        return balance;
    }
    function withdraw() public {
        require (msg.sender == owner);
        selfdestruct(owner);
    }
}

Auffällig ist zunächst, dass Solidity im Gegensatz zu JavaScript ein Typsystem besitzt. Außerdem sind bestimmte Methoden speziell annotiert. Im obigen Beispiel steht etwa payable dafür, dass sich mit der Methode Ether (abzüglich Sprit) in den Vertrag einzahlen lässt.

Ganz genau messbar ist es zwar nicht, aber Solidity hat sich mittlerweile als Standard für die Programmierung auf Ethereum durchgesetzt. Das zeigt sich auch daran, dass ein Tooling-Ökosystem um die Sprache herum entstanden ist. Allerdings ruft die Vielzahl an öffentlichen Verträgen mit teils hohen Kontoständen auch kriminelle Akteure auf den Plan. Ein Smart Contract, einmal programmiert und ausgerollt, kann keine Bugfixes mehr enthalten, was es umso wichtiger macht, dass sie hohen Qualitätsansprüchen genügen.

Doch Solidity fällt dabei als nicht besonders solide auf. Eine Forschergruppe an der University of Texas hat in einer Untersuchung 44 Fehlerklassen festgestellt, von denen fünf auf Solidity zurückgehen. In der Vergangenheit wurden einige spektakuläre Fehler in Solidity-Verträgen ausgenutzt, um acht- bis neunstellige Dollarbeträge abzuzweigen.

Während sich Probleme in Programmiersprachen oftmals durch eine neue Version ausgleichen lassen, wiegen Designfehler in der Ethereum-VM deutlich schwerer. Aufgrund von Abwärtskompatibilität lässt sich Laufzeitverhalten nur schwer ändern, denn die gesamte Basis an Smart Contracts muss lauffähig bleiben.

Alles in allem erinnert das Problem stark an die Debatte, die die Community der Systemprogrammierer*innen schon seit geraumer Zeit führt: Liegen Sicherheitslücken an schlampiger Programmierung oder sind die Ursachen in der Programmiersprache zu finden? Aus dieser Beobachtung ist die Programmiersprache Rust geboren, die etliche Sicherheitsprobleme durch besseres Sprachdesign beseitigen möchte.