Was ist Paritys ink!?

Von Michi Müller Core Developer @ Parity Technologies auf englisch am 20.09.22 unter Ink!, Parity Substrate, Polkadot, Rust, Wasm im Parity Blog.

ink! ist eine Programmiersprache für Smart Contracts - eine von mehreren, aus denen Blockchains, die mit dem Substrate-Framework erstellt wurden, wählen können. Es ist eine meinungsstarke Sprache, die wir bei Parity entwickelt haben, indem wir die beliebte Programmiersprache Rust um Funktionen erweitert haben, die für die Kompatibilität mit Smart Contracts erforderlich sind.

Vielen Dank, dass Sie ink! geholfen haben, 1.000 GitHub-Sterne zu erreichen!

Das ink! Repository hat vor kurzem die Marke von tausend Sternen auf GitHub überschritten. Es ist nun das drittbeliebteste Parity-Repository auf GitHub, nach Substrate und Polkadot. Wir möchten allen, die dazu beigetragen haben, ein großes Dankeschön aussprechen! In den letzten Jahren haben wir Beiträge in allen Formen gesehen, die das Projekt dorthin gebracht haben, wo es heute steht. Danke, dass Sie Ihre Contracts in ink! geschrieben haben, dass Sie Issues und Pull Requests erstellt haben, dass Sie uns gutes und konstruktives Feedback gegeben haben, dass Sie Fragen auf Substrate StackExchange beantwortet haben, dass Sie Drittanbieter-Tools für ink! erstellt haben, dass Sie Blogbeiträge über uns geschrieben haben und dass Sie Workshops abgehalten haben!

In den letzten Jahren hat sich in der Welt von ink! viel getan. Der erste Commit war im Dezember 2018 und unsere aktuelle Version ist v3.3.1. Wir arbeiten hart daran, die nächste große Iteration mit v4.0 bald auszuliefern. Ein offener Punkt, der regelmäßig auftaucht, ist, dass wir noch nie einen Blogbeitrag geschrieben haben, der von Anfang bis Ende erklärt, was ink! ist und wie es mit Substrate und Polkadot zusammenhängt. Daher ist dieser Anlass eine gute Gelegenheit, genau das zu tun!

Wie hängt ink! mit Substrate zusammen?

Bevor wir über ink! sprechen können, müssen wir zunächst klären, was Substrate und seine Contracts-Palette (pallet-contracts) sind. Substrate ist ein Rahmenwerk für den Aufbau von Blockchains, bei denen es sich um eigenständige Blockchains oder um Blockchains handeln kann, die als sogenannte Parachains mit Kusama oder Polkadot verbunden sind. Substrate enthält eine Reihe von Modulen, die in der Substrate-Terminologie als Paletten bezeichnet werden. Substrate wird mit einer Reihe von Paletten für viele Anforderungen geliefert, die moderne Blockchains typischerweise haben - Staking, fungible Token, nicht-fungible Token, Governance usw.

Substrate wird auch mit einem Modul für Smart Contracts ausgeliefert, der Contracts-Palette. Wenn eine Parachain in Substrate entwickelt wird, kann sie leicht Smart-Contract-Funktionalität hinzufügen, indem sie diese Palette einbindet.

Wie kommt ink! hier ins Spiel? ink! ist eine Programmiersprache, genauer gesagt eine eingebettete domänenspezifische Sprache (eDSL) für die beliebte Programmiersprache Rust. Das bedeutet, dass Sie die gesamte normale Rust-Syntax sowie einige Besonderheiten verwenden können, die wir hinzugefügt haben, um die Sprache für die Welt der Smart Contracts geeignet zu machen. Die Contracts-Palette nimmt diese ink!-Contracts und führt sie auf sichere Weise aus. Also kurz gesagt:

Mit ink! können Sie Smart Contracts in Rust für Blockchains schreiben, die mit Substrate erstellt wurden und die Contracts-Palette enthalten.

Smart Contracts vs. Parachains

Eine der ersten Fragen, die uns typischerweise gestellt wird, wenn jemand etwas über Substrate, Polkadot oder Kusama erfährt, ist die Frage, wann man eine Parachain und wann man einen Smart Contract entwickeln sollte.

Der Unterschied besteht darin, dass im Kontext von Polkadot und Kusama eine Parachain einen Slot für ein paar Monate bis zu zwei Jahren mietet. Der Deal mit einem Mietvertrag ist, dass die Parachain einen festen Slot für die Ausführung ihrer Geschäftslogik (typischerweise als Zustandsübergangsfunktion bezeichnet) erhält und ihren geänderten Zustand in einem Block aufrechterhalten kann. In der Substratterminologie wird diese Zustandsübergangsfunktion als die Laufzeit der Chain bezeichnet.

Der Unterschied zu anderen Ökosystemen besteht darin, dass im Kontext von Polkadot Parachains und Smart Contracts auf verschiedenen Ebenen des Stacks existieren: Smart Contracts liegen über Parachains. Parachains würden normalerweise als Layer-1-Blockchains bezeichnet werden - mit dem Unterschied, dass sie keine eigene Sicherheit aufbauen müssen und aufrüstbar und interoperabel sind.

Es ist bemerkenswert, dass die Zustandsübergangsfunktion einer Parachain nicht weiter validiert wird - es liegt an der Parachain, wie sie ihre Slot-Zeit nutzt. Sobald sich eine Parachain einen Slot durch das Bonding von Token (oder die Beschaffung von Token aus der Community via Crowdloan) gesichert hat, ist der Slot im Wesentlichen vorausbezahlt, ohne dass zusätzliche Gebühren für die Ausführung der Geschäftslogik der Chain anfallen. Das bedeutet, dass die Parachain ihre eigene (Blockchain-)Welt aufbauen kann! Sie kann zum Beispiel entscheiden, wie Transaktionsgebühren erhoben werden, oder sogar, ob überhaupt Transaktionsgebühren erhoben werden. Diese Optionen sind entscheidend für den Aufbau neuer oder benutzerfreundlicherer Geschäftsmodelle.

Andere Unterscheidungsmerkmale zwischen Parachains, die wir in der “freien Wildbahn” beobachten, sind Unterschiede in der Art und Weise, wie die Governance der Chain oder die Kryptoökonomie funktioniert. Es gibt jedoch einige Beschränkungen, wie die Parachain ihre Welt aufbauen kann. Wie die Physik in der realen Welt muss sie sich an bestimmte Grundregeln halten. Für Polkadot und Kusama ist das zum Beispiel der Konsensalgorithmus für die Relay-Chain zur Kommunikation mit der Parachain. Aus diesen Grundregeln ergeben sich die Vorteile von Polkadot und Kusama. Vorteile wie die bereits erwähnte gemeinsame Sicherheit, die chainübergreifende Kommunikation oder die garantierte Ausführungsslotzeit.

Für Smart Contracts hingegen muss eine bestehende Parachain die Contracts-Palette enthalten, damit Nutzer Smart Contracts einsetzen können. Der eingesetzte Smart Contract ist immer ein nicht vertrauenswürdiger Code. Jeder (oder jedes Programm), der/das über Token der Chain verfügt, kann einen Smart Contract hochladen, ohne eine Genehmigung zu benötigen. Smart Contracts ermöglichen den erlaubnisfreien Einsatz von nicht vertrauenswürdigen Programmen auf einer Blockchain. Die Contracts-Palette muss davon ausgehen, dass diese Programme nicht vertrauenswürdig sind, und sie muss eine Reihe von Sicherheitsvorkehrungen treffen, um sicherzustellen, dass der Contract z. B. die Chain nicht abwürgen oder den Zustand anderer Contracts korrumpieren kann. Für die Contracts-Palette umfassen diese Sicherheitspfeiler Mechanismen wie Gasmessung oder Hinterlegungen für die Speicherung von Daten auf der Chain.

Um diesen wichtigen Unterschied noch einmal zu betonen: Die Entwicklung einer Parachain-Laufzeit ist etwas anderes als die Entwicklung eines Smart Contracts - ein Smart Contract sitzt auf einer Parachain.

Der Kompromiss besteht darin, dass man bei einer Parachain die Freiheit hat, über (fast) alle Regeln zu entscheiden, aus denen die Parachain besteht. Bei einem Smart Contract ist man durch das, was die Chain zulässt, und die Sicherheitssäulen, die unbedingt vorhanden sein müssen, eingeschränkt.

Ein Smart Contract hingegen hat weniger Reibungsverluste bei der Entwicklung und dem Einsatz. Die Entwickler müssen sich keine Gedanken über Governance, Kryptoökonomie usw. machen. Man braucht nur ein paar Token und kann sich auf den Weg machen, einen Smart Contract einzurichten. So einfach ist das.

Wie funktioniert die Contracts Palette?

Wir haben die Contracts-Palette absichtlich so konzipiert, dass sie von der Sprache entkoppelt ist, die zum Schreiben der Smart Contracts verwendet wird. Die Palette ist nur die Ausführungsumgebung und nimmt WebAssembly-Dateien als Eingabe. Smart Contracts für diese Palette müssen für die WebAssembly (Wasm)-Zielarchitektur kompiliert werden.

Für Smart Contract Entwickler bedeutet dies, dass sie ink! zum Schreiben von Smart Contracts verwenden können, aber auch andere Sprachen wählen können. Momentan stehen drei Sprachen zur Auswahl:

Paritys ink! für Rust.
ask! für AssemblyScript.
Der Solang Compiler für Solidity.

Es ist nicht schwer, neue Sprachen hinzuzufügen. Es muss nur ein Compiler für die Sprache bis hin zu WebAssembly vorhanden sein, dann ist es möglich, die API der Contracts-Palette zu implementieren. Diese API besteht derzeit aus etwa 15-20 Funktionen für alles, was ein Smart Contract benötigen könnte: Speicherzugriff, kryptografische Funktionen, Umgebungsinformationen wie Blocknummern, Zugriff auf Funktionen zum Erhalt von Zufallszahlen oder zur Selbstbeendigung des Contracts usw. Nicht alle diese Funktionen müssen in der Sprache implementiert werden - Ink! "Hello, World!" erfordert nur sechs API-Funktionen. Das folgende Schema stellt diese Beziehung dar:

Wir sind der Meinung, dass dieses Design zukunftssicherer ist als einige Architekturen, die in konkurrierenden Ökosystemen zu finden sind. Es besteht keine enge Kopplung zwischen Sprache und Ausführungsumgebung. WebAssembly ist ein Industriestandard und eine Vielzahl von Programmiersprachen kann heutzutage in WebAssembly kompiliert werden. Wenn in, sagen wir, zehn Jahren, Forscher eine innovative Sprache zum Schreiben von Smart Contracts (oder eine Teilmenge einer bestehenden Sprache) entwickeln, dann wird es, solange es einen WebAssembly-Compiler gibt, einfach sein, diese Sprache mit der Contracts-Palette kompatibel zu machen.

Warum sollte die Palette Contracts auf einer Parachain enthalten sein?

Es gibt eine Reihe von Anwendungsfällen für die Einbindung von Smart-Contract-Funktionen in eine Parachain. Wir unterscheiden davon drei große:

Anwendungsfall 1: Smart Contracts als "Bürger erster Klasse"

Der offensichtlichste Anwendungsfall ist eine Parachain, die Smart Contracts als "Bürger erster Klasse" anbietet, d. h. Smart Contracts sind das zentrale Wertversprechen der Chain.

Diese Chains nehmen in der Regel die standard Contracts Palette und bauen darauf zusätzliche Innovationen auf. Beispiele hierfür sind:

Astar: eine Schicht über der Contracts Palette aufgebaut, so dass Contract-Entwickler ein passives Einkommen erzielen können, wenn ihre Contracts genutzt werden.
Phala: nutzt die Contracts-Palette in einer vertrauenswürdigen Ausführungsumgebung, die eine vertrauliche Smart-Contract-Ausführung und Interoperabilität ermöglicht.
Aleph Zero: verwendet die Palette Contracts in einem Null-Wissen-Kontext.
t3rn: verwendet die Contracts-Palette als Baustein, um die Multichain-Ausführung von Smart Contracts zu ermöglichen.

Anwendungsfall 2: Smart Contracts als "Bürger zweiter Klasse"

Es gibt einen weiteren, nicht so offensichtlichen Anwendungsfall für die Contracts-Palette: Smart Contracts als "Bürger zweiter Klasse" in einer bestehenden Chain. Damit meinen wir, dass das zentrale Wertversprechen der Chain nichts mit Smart Contracts zu tun hat, sie aber dennoch als Add-on enthalten sind.

Wir bieten eine API (Chainerweiterungen genannt), mit der eine Parachain bestimmte Teile ihrer Geschäftslogik für Smart-Contract-Entwickler zugänglich machen kann. Auf diese Weise können Smart-Contract-Entwickler die Geschäftslogik-Primitive der Chain nutzen, um eine neue Anwendung darauf aufzubauen. Denken Sie zum Beispiel an eine dezentrale Börsen-Blockchain. Diese Chain würde in ihrer einfachsten Form ein Auftragsbuch haben, um Gebote und Anfragen zu platzieren - es besteht keine Notwendigkeit, nicht vertrauenswürdige, turing-komplette Programme von außen zu nehmen. Die Parachain könnte jedoch beschließen, das Orderbuch in Smart Contracts einzubinden, um externen Entwicklern die Möglichkeit zu geben, neue Anwendungen zu erstellen, die das Orderbuch nutzen. Zum Beispiel, um Handelsalgorithmen als Smart Contracts auf die Chain hochzuladen.

Smart Contracts sind hier eine Möglichkeit, das Engagement der Nutzer zu erhöhen. Und die Abrechnung für die Nutzung der Chain ist bereits in die Palette integriert - die Nutzer müssen Gasgebühren für die Ausführung ihres Smart Contracts bezahlen.

Anwendungsfall 3: Smart Contracts als erster Schritt zu Polkadot oder Kusama

Ein dritter wichtiger Anwendungsfall für die Contracts-Palette ist der Prototyp einer Idee als Proof-of-Concept-Smart-Contract, bevor ein dedizierter Parachain-Slot auf Polkadot oder Kusama gemietet wird.

Die Zeit für die Entwicklung eines Smart Contracts und seine Bereitstellung ist kürzer als das Onboarding für eine Parachain. Man kann zunächst einen Proof-of-Concept-Smart-Contract einsetzen, um zu sehen, ob er Anklang findet und die Idee in der realen Welt Bestand hat. Erst später, wenn ein Bedarf für z.B. günstigere Transaktionsgebühren, eine effizientere Ausführung oder einen Governance-Mechanismus für die Gemeinschaft besteht, kann der Smart Contract auf eine dedizierte Parachain-Laufzeit mit eigenem Slot migriert werden. ink! contracts und Substrate-Laufzeiten sind beide in Rust geschrieben und nutzen ähnliche Primitive, was einen klaren Weg für ein Projekt ermöglicht, von einem Smart Contract zu einer eigenen Laufzeit zu gelangen. Entwickler können große Teile ihres Codes, ihrer Tests sowie des Frontend- und Client-Codes wiederverwenden.

Ein einfacher ink! Smart Contract

ink! ist eigentlich nur Rust, das ist unser übergreifendes Ziel. Wir wollen so wenig wie möglich eingreifen und es Entwicklern ermöglichen, alles zu nutzen, was sie auch für "normales" Rust nutzen können - IDEs, cargo fmt, cargo clipy, Code Snippets, das crates.io Ökosystem, etc.

In der folgenden Abbildung sehen Sie einen einfachen ink!-Contract. Der Contract speichert einen booleschen Wert in seinem Speicher. Sobald der Contract erstellt ist, setzt er den booleschen Wert auf true. Der Contract stellt zwei Funktionen zur Verfügung: eine, um den aktuellen Wert des booleschen Wertes zu lesen (fn get()), und eine, um den Wert in seinen entgegengesetzten booleschen Wert zu ändern (fn flip()).

Die farbigen Linien sind ink!-spezifische Annotationen im Code, der Rest ist normale Rust-Syntax. Diese Annotationen abstrahieren von dem, was unter der Haube passieren muss, um das Programm für die Ausführung auf der Chain kompatibel zu machen.

In unserer aktuellen Version 3.3.1 können Unit- und Integrationstests auch wie in "normalem" Rust geschrieben werden:

#[ink::test]

fn default_works() {

let flipper = Flipper::default();

assert_eq!(flipper.get(), false);

}

Die Annotation #[ink::test] bewirkt, dass dieser Test in einer gespiegelten Blockchain-Umgebung ausgeführt wird. Dies ermöglicht es Entwicklern, z. B. den Wert, der an einen Contract übertragen wird, den Aufrufer, der einen Contract ausführt, die Blocknummer usw. zu mocken. Sie können zum Beispiel ink_env::test::set_value_transferred innerhalb eines #[ink::test] verwenden, um den Wert (d. h. Token) zu simulieren, der an einen Contract gesendet wird. Die vollständige Liste der ink_env-Funktionen finden Sie in unserer Crate-Dokumentation.

cargo-contract ‒ das Schweizer Taschenmesser für ink! Smart Contracts

Für die Erstellung von Ink! Smart Contracts könnte man einfach den normalen cargo build Workflow für die Erstellung von Rust-Programmen verwenden. Sie müssten allerdings eine Reihe von Argumenten für den Befehl hinzufügen, damit er auf der Chain funktioniert. Wir haben ein Tool entwickelt, das bereits den optimalen Satz an Flags für Sie auswählt: cargo-contract. Es ist ein Kommandozeilen-Tool, das cargo widerspiegelt. Man kann es als eine Art Schweizer Taschenmesser für Ink! Smart Contracts betrachten. Es kann viel mehr als nur einen Smart Contract erstellen, aber darüber sprechen wir später.

Zum Erstellen von Contracts verwenden Sie cargo contract build. Beachten Sie, dass das typische Rust cargo build Verhalten darin besteht, dass Sie --release angeben müssen, wenn Sie die kleinstmögliche Binärgröße haben wollen; dasselbe gilt für cargo contract build --release. Wenn Sie diesen Befehl ausführen, werden Sie sehen, dass cargo-contract den "normalen" cargo build für Ihren Contract ausführt, aber zusätzlich einige weitere Schritte durchführt. Die drei wichtigsten zusätzlichen Schritte sind:

Es läuft ein Interpreter für ink! Contracts. Dieser Interpreter arbeitet analog zu Rust's clippy, er prüft Ihren Contract auf idiomatische Verwendung von ink! Wir sind ständig dabei, dieses Interpreter-Tool zu verbessern und werden in der Zukunft Erkennungen von häufigen Sicherheitslücken hinzufügen.
Es verarbeitet und komprimiert die Binärdateien Ihres Contracts nach. Dies geschieht, um die Kosten für Benutzer, die einen Contract einsetzen, sowie die Gebühren für Benutzer, die mit dem Contract interagieren, zu senken. Die Größe des Contracts steht auch im Zusammenhang mit dem Durchsatz, den eine Chain erreichen kann, und trägt zum Fußabdruck der Chain bei.
Sie erzeugt Metadaten für den Contract. Mit dem Begriff Metadaten bezeichnen wir alle Informationen, die für die Interaktion mit der Binärdatei des Contracts benötigt werden. Die Binärdatei selbst ist nur ein WebAssembly-Blob - ein Bytecode des Contracts, mit dem ohne weitere Informationen nicht interagiert werden kann. Um z.B. zu wissen, welche Funktionen der Contract bereitstellt und welche Argumente diese Funktionen benötigen, benötigt man die Metadaten. Sie kennen dieses Konzept vielleicht auch unter dem Begriff ABI von anderen Blockchains. In unserem Fall enthalten die Metadaten jedoch etwas mehr als nur die ABI, sie enthalten z.B. auch Informationen darüber, wie der Contract seine Daten speichert, was für Off-Chain-Tools (z.B. einen Block-Explorer) oder eine menschenlesbare Dokumentation über die Contract-Funktionen.

Als Ergebnis der Ausführung von cargo contract build werden drei Dateien erstellt:

my_contract.contract: eine JSON-Datei, die den WebAssembly-Blob des Contracts in Hex-Kodierung sowie die Metadaten des Contracts enthält.
metadata.json: eine JSON-Datei, die nur die Metadaten des Contracts enthält, ohne den WebAssembly-Blob.
my_contract.wasm: der WebAssembly-Blob des Contracts.

Jede dieser Dateien hat einen anderen Anwendungsfall:

Die WebAssembly ist die einzige Datei, die tatsächlich On-Chain gespeichert wird. Die Speicherung von Daten in der Chain sollte nur für Daten erfolgen, die unbedingt in der Chain gespeichert werden müssen. Alles, was nicht in der Chain gespeichert werden muss, würde Kosten für die Benutzer verursachen und den Fußabdruck der Chain aufblähen. Die Metadaten müssen nicht unbedingt auf der Chain sein, eine App oder ein Frontend kann die hart kodierten Metadaten enthalten, um zu bestimmen, wie mit dem Contract zu interagieren ist.

Das *.contract-Bündel wird nur benötigt, wenn Sie einen Smart Contract entwickeln, dann können Sie diese Datei mit einer Developer UI verwenden. Entwickler-UIs bieten die Möglichkeit, Contracts zu implementieren, mit ihnen zu interagieren und sie zu debuggen.

Entwicklungsumgebungen

Eine Reihe von Parachains hat benutzerdefinierte Werkzeuge entwickelt, die einen kontextspezifischen Blickwinkel bieten, in dem sie die Contracts Palette und ink! verwenden. Wir haben einige dieser Teams am Anfang dieses Beitrags erwähnt. Weitere Informationen finden Sie in unserem awesome-ink Repository.

Wir, das Team, das ink! und die Contracts-Palette entwickelt, stellen ebenfalls einige praktische Tools zur Verfügung:

substrate-contracts-node: Dieses Repository enthält das node-template von Substrate, das so konfiguriert ist, dass es pallet-contracts enthält. Dieser Knoten verfolgt den master -Zweig von Substrate und wurde so verändert, dass er sich hervorragend für Entwicklung und Tests eignet. Er hat zum Beispiel keine feste Blockzeit, alles wird sofort verarbeitet. Dies hat den Nachteil, dass der Node nicht für die Produktion geeignet ist, aber er eignet sich hervorragend für Skripte, Tests oder eine Continuous Integration (CI) Umgebung. Wenn Sie auf der Suche nach Produktionsvorlagen sind, werfen Sie einen Blick auf den Substrate-Node oder die Anleitung in der Substrate-Dokumentation zum Hinzufügen der pallets-contracts (Link hier).
Wir unterhalten ein Testnetz mit dem schlichten Namen Contracts on Rococo. Rococo ist ein Testnetz für alles, was Polkadot und Kusama betrifft. Viele Parachains sind mit ihren eigenen Testnetzen mit Rococo verbunden. Sie können in unserer Dokumentation mehr darüber lesen, wie Sie unser Testnetz nutzen können.

Es gibt auch eine Reihe von Community-Testnetzen, von denen Sie einige in unserem awesome-ink-Repository finden können.

Für Developer UI's gibt es derzeit drei Möglichkeiten:

Contracts UI: Ideal für Anfänger, gibt hilfreiche Tipps und unterstützt die Entwickler.
polkadot.js: Fortschrittliche Schnittstelle, die Entwicklern Flexibilität auf Kosten der Benutzerfreundlichkeit bietet.
ink! playground: Eine Spielwiese zum Ausprobieren von ink! im Browser oder zum Teilen von permanenten Links zu Code-Snippets. Eine sehr praktische Anwendung ist, wenn Sie Fragen auf dem Substrate StackExchange stellen: Sie können Code mit z.B. einem Problem teilen, das Sie haben.
cargo-contract: Wenn Sie Contracts über die Befehlszeile bereitstellen, sie aufrufen, Ihre Ausgabe dekodieren usw. möchten, bietet dieses Tool eine praktische Option, um all dies über eine Befehlszeilenschnittstelle zu tun. Das Tool eignet sich auch perfekt für die Skripterstellung oder CI-Integrationen.

Warum sollte man sich für diesen Weg entscheiden und nicht für eine Ethereum-Kompatibilitätsschicht als Substrate?

Neben der Contracts-Palette gibt es zwei weitere beliebte Optionen für Smart Contracts in Substrate: pallet-evm und Frontier. Beide sind Ethereum-Kompatibilitätsschichten für Substrate.

Es gibt eine Reihe von Vorteilen für die Wahl der Route von ink! und der Contracts-Palette über die EVM-Variante. Um einige davon zusammenzufassen, die in diesem Artikel ausführlich beschrieben wurden:

ink! ist nur Rust - Sie können alle normalen Rust-Werkzeuge verwenden: clippy, crates.io, IDE’s, etc.
Rust ist eine Sprache, in die jahrelange Sprachforschung eingeflossen ist, sie ist sicher und schnell. Darüber hinaus haben wir wichtige Erkenntnisse aus älteren Smart-Contract-Sprachen (wie Solidity) in das Design von ink! integriert. Wir haben uns für ein vernünftigeres Standardverhalten entschieden, wie z. B. die standardmäßige Deaktivierung von Reentrancy oder die standardmäßige Privatisierung von Funktionen.
Rust ist eine erstaunliche Sprache, mit der man arbeiten kann. Auf StackOverflow wurde sie sieben Jahre in Folge zur beliebtesten Programmiersprache gekürt (Quelle).
Wenn Sie ein Unternehmen sind und Entwickler für Smart Contracts suchen, können Sie aus dem Rust-Ökosystem anheuern, das viel größer ist als die Nische von z. B. Solidity-Entwicklern.
ink! ist nativ für Substrate, wir verwenden ähnliche Primitive, wie das gleiche Typensystem.
Es gibt einen klaren Migrationspfad, um von einem Contract zu einer Parachain überzugehen. Da ink! und Substrate beide Rust sind, können Entwickler große Teile ihres Codes, ihrer Tests sowie des Frontend- und Client-Codes wiederverwenden.
WebAssembly ist ein Industriestandard, der nicht nur in der Blockchain-Welt verwendet wird. Er wird von großen Unternehmen wie Google, Apple, Microsoft, Mozilla und Facebook kontinuierlich verbessert. In Zukunft werden wir von allen Verbesserungen des Standards und seiner Implementierungen profitieren. Das ist eine große Sache. WebAssembly wird hauptsächlich für das Web verwendet, das ähnliche Anforderungen wie Blockchains hat - sicher und schnell.
WebAssembly erweitert die Familie der Sprachen, die Entwicklern von Smart Contracts zur Verfügung stehen, um Rust, C/C++, C#, Typescript, Haxe, Kotlin usw. Das bedeutet, dass Sie Smart Contracts in jeder Sprache schreiben können, mit der Sie vertraut sind. Wir glauben, dass dieses Design zukunftssicherer ist als eine enge Kopplung von Sprache und Ausführungsarchitektur.

Wir unterstützen die Interoperabilität mit älteren Solidity-Codebasen: Das HyperLedger-Projekt Solang kompiliert Solidity für die Contracts-Palette.

Wo kann man mehr lernen?

Unser Dokumentationsportal finden Sie unter use.ink, es enthält die umfassendsten Informationen zu ink!
Da ink! nur Rust ist, können Sie sich auch die Crate-Dokumentation ansehen. Wir haben relevante Crate-Dokumente in unserer Readme hier verlinkt, z.B. die Crate-Dokumentation für Datenstrukturen ist dort verlinkt.
Wir haben eine Reihe von Contractbeispielen in unserem Repository hier. Diese decken eine große Anzahl von typischen Anwendungsfällen ab: ERC-20, aufrüstbare Contracts, usw.
Wenn Sie nach einem Schnellstart suchen, bietet das Guided Tutorial for Beginners von ink! einen guten Ausgangspunkt.
Falls Sie sich für die innere Funktionsweise von ink! interessieren, erklären wir diese in unserer ARCHITECTURE.md Datei.
Für die Contracts Palette bietet die Datei README.md einen Ausgangspunkt.

Ausblick

Mit diesem Artikel wollten wir ein vollständiges Bild davon vermitteln, was ink! ausmacht. Der nächste große Schritt für ink! ist v4.0.0 - unsere nächste große Iteration, für die wir bereits eine Alpha-Version veröffentlicht haben. Diese Version wird wesentliche Verbesserungen bei den Contractgrößen, der Entwicklererfahrung und nativen End-to-End-Tests bringen. Außerdem sind einige Parachain-Teams kurz davor, die Contracts-Palette und ink! nach Kusama oder Polkadot zu bringen. Es bleibt spannend und wir freuen uns schon auf die nächsten tausend Sterne.

Sollten Sie noch Fragen haben, zögern Sie bitte nicht, sich an uns zu wenden. Am besten fragen Sie auf Substrate StackExchange oder über https://info.polkadot.network/contact. Wenn Sie bereits bauen, öffnen Sie ein Problem in dem entsprechenden Repository.

Sind Sie daran interessiert, auf Polkadot zu bauen? Kontaktieren Sie uns!

Übersetzt in Kooperation mit WagMedia.

Twitter: @thatmediawag