Skip to main content

Was ist eine non-EVM-Blockchain

Hinweis: Dieses Dokument ist eine automatische Übersetzung des englischen Originals.

Was ist eine non-EVM-Blockchain

Eine non-EVM-Blockchain ist jede Blockchain, die nicht die Ethereum Virtual Machine als ihre Ausführungs-Engine verwendet. Anstatt Solidity-Bytecode auszuführen, verwenden non-EVM-Chains andere virtuelle Maschinen, andere Programmiersprachen und andere Ausführungsmodelle. Beispiele sind Solana (SVM/Sealevel), Cosmos-basierte Chains (CosmWasm, anwendungsspezifische Module), NEAR (WebAssembly-basierte Laufzeit), Sui und Aptos (MoveVM) sowie Bittensor (benutzerdefinierte Substrate-basierte Laufzeit).

Die Unterscheidung ist wichtig, weil die Wahl der virtuellen Maschine bestimmt, welche Programmiersprachen Entwickler verwenden, wie sich Smart Contracts verhalten, welches Tooling verfügbar ist und wie einfach ein Projekt mit anderen Chains interagieren kann. Ein auf einer non-EVM-Chain aufgebautes Projekt kann nicht einfach Solidity-Contracts von Ethereum kopieren und einfügen — es benötigt eine andere Codebasis, andere Entwicklerfähigkeiten und einen anderen Satz von Infrastruktur-Tools.

Kurz gesagt: non-EVM-Blockchains verwenden andere Ausführungsumgebungen als die Ethereum Virtual Machine. Das bedeutet andere Programmiersprachen, anderes Tooling und andere architektonische Kompromisse — aber auch das Potenzial für Leistungsmerkmale, die die EVM nicht erreichen kann.

Wie sich die non-EVM-Ausführung von der EVM unterscheidet

Die EVM ist eine stack-basierte virtuelle Maschine, die Solidity-Bytecode sequenziell ausführt, 256-Bit-Ganzzahlen verwendet und Berechnung über Gas misst. non-EVM-Chains weichen auf verschiedene Weise von diesem Modell ab:

Unterschiedliche virtuelle Maschinen

Chain / Ökosystem Virtuelle Maschine Primäre Sprache Wesentlicher architektonischer Unterschied
Solana SVM (Sealevel) Rust Parallele Transaktionsausführung über deklarierten Zustandszugriff
Cosmos-Chains CosmWasm / native Module Rust (CosmWasm), Go (Module) Anwendungsspezifische Blockchain mit eingebauter Cross-Chain-Kommunikation (IBC)
NEAR WebAssembly (Wasm) Rust, AssemblyScript Sharded Execution mit asynchronen Cross-Shard-Aufrufen
Sui MoveVM Move Objektzentriertes Zustandsmodell, das parallele Ausführung ermöglicht
Aptos MoveVM Move Block-STM-Parallelausführungs-Engine
Bittensor Substrate runtime Rust KI-spezifische Koordination; Subnets als Ausführungseinheiten

Jede virtuelle Maschine geht andere Kompromisse ein. Solanas SVM erfordert, dass Transaktionen im Voraus deklarieren, auf welchen Zustand sie zugreifen werden, was es der Laufzeit ermöglicht, nicht-konfliktierende Transaktionen parallel auszuführen — etwas, das die EVM nativ nicht kann. Cosmos-Chains tauschen das Modell der geteilten Ausführung vollständig: Jede Anwendung erhält ihre eigene Chain mit benutzerdefinierter Logik, die über das IBC-Protokoll mit anderen Chains verbunden ist. Move-basierte Chains (Sui, Aptos) verwenden ein ressourcenorientiertes Programmiermodell, das bestimmte Klassen von Bugs (wie Reentrancy) auf Sprachebene verhindert.

Unterschiedliche Programmiersprachen

Das EVM-Ökosystem wird von Solidity dominiert — einer Sprache, die speziell für Ethereum-Smart-Contracts konzipiert wurde. non-EVM-Chains verwenden Allzwecksprachen oder zweckgebaute Alternativen:

  • Rust — verwendet von Solana (über das Anchor-Framework), Cosmos (über CosmWasm), NEAR und Substrate-basierten Chains einschließlich Bittensor. Rusts Speichersicherheitsgarantien und Leistung machen es für On-Chain-Programme geeignet.
  • Move — ursprünglich bei Facebook/Diem entwickelt, jetzt von Sui und Aptos verwendet. Move behandelt On-Chain-Vermögenswerte als erstklassige Ressourcen, die nicht dupliziert oder versehentlich zerstört werden können, was eine Kategorie häufiger Smart-Contract-Schwachstellen reduziert.
  • Go — verwendet für die Entwicklung nativer Module in Cosmos-SDK-Chains. Validatoren führen Go-kompilierte Binaries direkt aus.
  • AssemblyScript — eine TypeScript-ähnliche Sprache, die zu WebAssembly kompiliert und als alternative Sprache für die NEAR-Entwicklung verwendet wird.

Diese Sprachenvielfalt bedeutet, dass Entwickler Solidity-Fähigkeiten nicht direkt auf non-EVM-Chains übertragen können. Ein Projekt, das auf Solana baut, benötigt Rust-Ingenieure; ein Projekt, das auf Sui baut, benötigt Move-Ingenieure. Der Pool an Entwicklertalent für jede Sprache beeinflusst, wie schnell ein Projekt bauen und iterieren kann.

Unterschiedliche Leistungsmerkmale

non-EVM-Chains erreichen oft andere Leistungsprofile:

  • Parallele Ausführung — Solana, Sui und Aptos führen nicht-konfliktierende Transaktionen parallel aus, was höheren Durchsatz liefern kann als das sequenzielle Ausführungsmodell der EVM.
  • Niedrigere und vorhersehbarere Gebühren — einige non-EVM-Chains haben Gebührenstrukturen, die von Anfang an für hohen Durchsatz konzipiert sind, und vermeiden so die volatilen Gebührenmärkte, die EVM-Chains während Überlastungen erleben können.
  • Benutzerdefinierte Zustandsmodelle — non-EVM-Chains können Zustandsmodelle verwenden, die für bestimmte Zugriffsmuster optimiert sind. Suis objektzentriertes Modell ermöglicht beispielsweise Eigentum pro Objekt und parallele Verarbeitung, deren Implementierung auf der EVM komplex wäre.

Diese Leistungsvorteile gehen mit Kompromissen einher: kleinere Entwickler-Ökosysteme, weniger ausgereiftes Tooling, weniger Audit-Firmen mit relevanter Expertise und geringere Komponierbarkeit mit dem großen EVM-basierten DeFi- und Token-Ökosystem.

Warum es für Krypto-KI-Projekte wichtig ist

Die Wahl der virtuellen Maschine hat praktische Auswirkungen auf KI-bezogene Blockchain-Projekte:

  • Ausführungsflexibilität — non-EVM-Chains können Ausführungsmodelle unterstützen, die besser für KI-Koordinations-Workloads geeignet sind. Parallele Ausführung, benutzerdefinierte Zustandsmaschinen und Instruktionssätze mit geringerem Overhead können hochfrequente KI-bezogene Transaktionen (Zuweisungen von Compute-Aufgaben, Ergebniseinreichungen, Aktualisierungen von Modellregistern) besser bedienen.
  • Sprachpassung — Rust-basierte Chains passen gut zu KI/ML-Infrastruktur, da viel KI-Tooling (leistungskritische Komponenten, GPU-Koordination, Systemprogrammierung) in Rust geschrieben ist oder gut mit Rust-Code zusammenspielt.
  • Anwendungsspezifisches Design — Cosmos-Appchains und Bittensor-Subnets ermöglichen es KI-Projekten, benutzerdefinierte Ausführungslogik auf Chain-Ebene zu bauen, ohne die Einschränkungen des Opcode-Sets und des Gas-Modells der EVM.
  • Ökosystem-Kompromisse — non-EVM-Projekte können nicht einfach auf das große EVM-Ökosystem von DeFi-Protokollen, Token-Bridges und Wallet-Infrastruktur zugreifen. KI-Projekte auf non-EVM-Chains müssen diese Infrastruktur entweder selbst bauen, sich auf Cross-Chain-Bridges verlassen oder ein kleineres anfängliches Ökosystem akzeptieren.

In DecAIHub-Projektkarten verrät Type: non-EVM dem Leser, dass das Projekt Solidity nicht verwendet, ohne Neuschreiben nicht auf EVM-kompatible Chains deployen kann und in einem anderen technischen Ökosystem operiert.

Wo es in DecAIHub-Projektkarten erscheint

In DecAIHub-Projektkarten erscheint die non-EVM-Bezeichnung in:

  • Type — non-EVM gibt an, dass die Smart Contracts oder die On-Chain-Logik des Projekts eine andere virtuelle Maschine als die EVM verwenden. Dies beeinflusst, welches Tooling, welche Sprachen und welche Standards gelten.
  • Main chain — die spezifische non-EVM-Chain wird aufgeführt (Solana, Bittensor, eine Cosmos-Chain, Sui usw.). Jede Chain hat ihre eigene VM, Sprache und ihr eigenes Ökosystem.
  • Token standard — non-EVM-Chains haben ihre eigenen Token-Standards. Solana verwendet SPL-Token; Cosmos-Chains verwenden native Denominationen oder CW-20 (CosmWasm); Move-basierte Chains verwenden Coin-/Fungible-Asset-Ressourcen. Diese sind nicht mit ERC-20 austauschbar.
  • Smart contracts / On-Chain-Logik — die Programmiersprache und das Framework unterscheiden sich von EVM-Projekten. Solana-Programme werden in Rust (Anchor) geschrieben, Cosmos-Contracts in Rust (CosmWasm) oder Go usw.

Was eine non-EVM-Klassifizierung allein nicht beweist

  • non-EVM bedeutet keine bessere Leistung. Während einige non-EVM-Chains parallele Ausführung oder niedrigere Gebühren bieten, hängt die Leistung von der spezifischen Chain, ihrer Validatoren-Infrastruktur und der aktuellen Last ab — nicht nur von der VM-Wahl.
  • non-EVM beweist keine technische Raffinesse. Die Wahl einer non-EVM-Chain ist eine Infrastrukturentscheidung. Sie weist nicht auf die Qualität der KI-Komponente des Projekts, seines Codes oder seines Produkts hin.
  • non-EVM bedeutet nicht, dass das Projekt nicht mit EVM-Chains interagieren kann. Viele non-EVM-Projekte verwenden Bridges, Oracles oder Wrapped Tokens, um sich mit Ethereum und anderen EVM-Ökosystemen zu verbinden. Cross-Chain-Interaktion ist möglich; sie erfordert nur zusätzliche Infrastruktur.
  • Eine andere VM bedeutet keine anderen Sicherheitsgarantien. Smart-Contract-Bugs, Logikfehler und Zentralisierungsrisiken existieren auf allen Chains unabhängig von der virtuellen Maschine. non-EVM-Sprachen wie Rust und Move eliminieren einige Bug-Klassen, führen aber andere ein.
  • Ein non-EVM-Label erklärt nicht, warum das Projekt diese Chain gewählt hat. Die Wahl könnte durch Leistungsanforderungen, die Expertise des Entwicklerteams, Ökosystemanreize oder einfach dadurch bestimmt sein, wo das Gründungsteam begonnen hat. Ohne zusätzlichen Kontext ist das Label allein informativ, nicht evaluativ.

Nicht verwechseln mit

  • EVM — die EVM ist die Ethereum Virtual Machine. non-EVM ist im Gegensatz dazu definiert: Jede Chain, die nicht die EVM verwendet, fällt in die non-EVM-Kategorie.
  • Ethereum — Ethereum ist die ursprüngliche EVM-Chain. non-EVM zu sein bedeutet, dass die Chain nicht Ethereum ist und nicht Ethereums Ausführungs-Engine verwendet — aber sie kann dennoch über Bridges oder Cross-Chain-Protokolle mit Ethereum interagieren.
  • Solana — Solana ist eine spezifische non-EVM-Blockchain mit ihrer eigenen virtuellen Maschine (SVM). "non-EVM" ist eine breite Kategorie, die Solana, Cosmos, Sui, Aptos, NEAR, Bittensor und viele andere umfasst.
  • "Anti-Ethereum" — non-EVM zu sein ist keine Aussage gegen Ethereum. Viele non-EVM-Chains koexistieren mit Ethereum und profitieren von gebridgeter Liquidität. Die VM-Wahl spiegelt unterschiedliche Designprioritäten wider, keine ideologische Opposition.
  • Inkompatibel — non-EVM-Chains können EVM-Bytecode nicht nativ ausführen, aber das bedeutet nicht, dass sie isoliert sind. Cross-Chain-Bridges, Messaging-Protokolle (wie IBC, LayerZero, Wormhole) und Wrapped Tokens ermöglichen Interoperabilität zwischen EVM- und non-EVM-Ökosystemen.

Häufig gestellte Fragen

Was sind die häufigsten non-EVM-Chains, die von Krypto-KI-Projekten verwendet werden?

Solana und Bittensor gehören zu den am häufigsten anzutreffenden non-EVM-Chains im Krypto-KI-Bereich, der von DecAIHub verfolgt wird. Solanas hoher Durchsatz und Rust-basiertes Ökosystem ziehen KI-Projekte an, die schnelle, kostengünstige On-Chain-Koordination benötigen. Bittensor ist zweckgebaut für dezentrale KI, mit Subnets, die spezifischen KI-Aufgaben gewidmet sind. Cosmos-basierte Appchains sind ein weiteres Muster, insbesondere für Projekte, die eine vollständig benutzerdefinierte Ausführungsumgebung mit eingebauter Cross-Chain-Kommunikation über IBC wünschen.

Kann ein non-EVM-Projekt auch auf EVM-Chains deployen?

Ja, aber es erfordert eine separate Codebasis. Ein für Solana in Rust geschriebenes Projekt kann nicht unverändert auf Ethereum deployt werden — es müsste in Solidity neu geschrieben werden (oder eine separate Solidity-Implementierung haben). Einige Projekte unterhalten Contracts sowohl auf EVM- als auch auf non-EVM-Chains, aber jedes Deployment erfordert unabhängige Entwicklung, Auditierung und Wartung. Cross-Chain-Bridges können es non-EVM-Projekten auch ermöglichen, Token-Repräsentation auf EVM-Chains zu haben (z. B. Wrapped SPL-Token als ERC-20 auf Ethereum).

Ist non-EVM besser für KI-Anwendungen?

Es gibt keine universelle Antwort. non-EVM-Chains können Vorteile für bestimmte KI-Anwendungsfälle bieten — Solanas parallele Ausführung eignet sich für hochdurchsatzfähige Koordination, Bittensors Subnet-Architektur ist zweckgebaut für KI-Anreize, und Cosmos-Appchains erlauben vollständig benutzerdefinierte Ausführungslogik. EVM-Chains bieten jedoch ein größeres Entwickler-Ökosystem, ausgereifteres Tooling, tiefere DeFi-Liquidität und breitere Wallet-Unterstützung. Die beste Wahl hängt von den spezifischen Anforderungen des Projekts ab: welche Workloads On-Chain laufen, welche Leistung benötigt wird, welches Ökosystem das Team bevorzugt und wo sich die Zielnutzer befinden.

Haben non-EVM-Chains Token-Standards wie ERC-20?

Ja, aber andere. Solana verwendet SPL-Token. Cosmos-Chains verwenden native Denominationen oder CW-20-Token (über CosmWasm). Sui und Aptos verwenden Moves Coin- und Fungible-Asset-Ressourcen. NEAR verwendet NEP-141. Jeder Standard definiert, wie Token auf dieser Chain erstellt, transferiert und verwaltet werden. Diese Standards sind nicht mit ERC-20 austauschbar — ein als SPL auf Solana gebauter Token kann ohne Wrapping oder Bridging nicht direkt auf einer EVM-Chain verwendet werden.

Externe Referenzen

Siehe auch

No comments to display

Back to top