Cartesi Linux-Appchains: Wann sie sinnvoll sind

Warum mit Cartesi Linux-Appchains entwickeln?

Kevin Hallo zusammen. Heute spreche ich mit João Garcia, Developer Advocate bei Cartesi, einer Infrastruktur für Linux-basierte Appchains, mit der ihr spezifische Anwendungen entwickeln könnt, die durch ein Rollup verifiziert werden. Das Beste daran ist, dass ihr praktisch jede universelle Bibliothek oder Sprache nutzen könnt, die auch unter Linux verfügbar ist. Eine spannende Folge, auch ein bisschen technisch. Aber wenn ihr ein neues Projekt bauen wollt oder nach einer guten Infrastruktur sucht, ist das eure Folge. Was sind die drei wichtigsten Gründe, warum Entwickler eure Plattform, eure Lösung wählen sollten?

João Drei Hauptgründe. Der erste ist definitiv, dass sie mehr Möglichkeiten bekommen. Sie können mehr tun und mehr Werkzeuge nutzen, oder? Sie können Anwendungen entwickeln, die sich von anderen Web3-Projekten unterscheiden. Alles, was unter Linux läuft, läuft auch auf einem mit Cartesi erstellten Rollup. Der zweite Grund ist die großartige Unterstützung durch die Community. In unserem Discord ist alles für jeden zugänglich. Alle Mitwirkenden sind dort aktiv und wir bieten wirklich gute Unterstützung. Und der dritte ist Absicherung und Sicherheit. Mit unseren Werkzeugen könnt ihr den bestmöglichen Fraud Proof nutzen. Wir haben gerade Dave entwickelt, den L2BEAT als einen großartigen Fraud Proof anerkannt hat. Darüber hinaus ist alles, was wir machen, Open Source. Unsere Diskussionen sind öffentlich, ebenso unsere Entwicklung. Jeder kann im Discord sehen, woran wir bauen. Deshalb können die Leute darauf vertrauen, dass wir etwas Gutes tun. Das sind drei gute Gründe.

Wie vermeiden anwendungsspezifische Rollups das Noisy-Neighbor-Problem?

Kevin Großartig. Die Vision passt also zu den Endnutzern, zu den Entwicklern. Gehen wir etwas tiefer. Das war schon sehr hilfreich, aber rein aus Entwicklersicht: Angenommen, ich baue etwas. Welchen Nutzen erhoffe ich mir von der Technik selbst? Warum sollte ich diesen Linux-basierten Rollup-Ansatz wählen, statt einfach Smart Contracts oder etwas anderes einzusetzen?

João Das ist eine sehr gute Frage. Es gibt zwei Hauptgründe, die wir aufteilen können. Erst Punkt A, dann Punkt B. Mit unserem Rollups-Framework erstellt ihr bei Cartesi ein anwendungsspezifisches Rollup. Das bedeutet, dass jeder, der einen Node betreibt und eine Anwendung ausführen möchte, genau diese Anwendung ausführt. Natürlich entwickeln wir Mechanismen, mit denen ihr mehr als eine Anwendung auf einem einzelnen Node ausführen könnt. Die Grundidee bleibt aber gleich: Ihr betreibt nur die Anwendungen, die ihr wollt. Ihr verschwendet keine Ressourcen für andere Anwendungen und verhindert gleichzeitig, dass Anwendungen einander Ressourcen wegnehmen. In einem gemeinsamen Rollup, in dem alle Anwendungen zusammen auf den Nodes laufen, verbraucht eine Anwendung dieselben Ressourcen wie die anderen. Bekommt eine sehr viele Anfragen und Eingaben, fehlt den anderen Rechenleistung. Bei uns bekommt jede Anwendung in diesem Sinne eine ganze CPU. Keine Anwendung bekommt also wegen einer anderen Probleme. Jede arbeitet unabhängig. Der zweite Grund ist Linux selbst. Wenn wir nur Linux sagen, verstehen die Leute oft nicht, welche Vorteile das bringt. Es gibt viele Vorteile. Fast alles, was für Computer entwickelt wurde, wird zuerst für Linux entwickelt. Manche Spiele vielleicht nicht, aber der Dienst, den ein Spiel nutzt, der Server, das Backend, läuft wahrscheinlich unter Linux. Banksoftware, soziale Netzwerke, die Server, die die Daten halten und die Verarbeitungslogik ausführen, laufen unter Linux. Bibliotheken für maschinelles Lernen, Spiele und Mathematik werden zuerst für Linux entwickelt. Damit könnt ihr nutzen, was schon in der Vergangenheit entwickelt wurde. Ihr seid nicht auf die Bibliotheken von Solidity beschränkt. Ihr könnt Bibliotheken aus Python, JavaScript, Rust, Go oder einer anderen Sprache verwenden. Schreibt euren Code, wie ihr wollt, mit der Sprache eurer Wahl. Das bringt Rückwärtskompatibilität, weil Bestehendes funktioniert, aber auch Vorwärtskompatibilität, weil zukünftige Entwicklungen zuerst für Linux entstehen werden. Das ist großartig. Ich denke, das deckt es ab.

Was bietet Linux zusätzlich zu einer RISC-V-Laufzeit?

Kevin Gut. Damit ich es vollständig verstehe: Appchains lösen grundsätzlich das sogenannte Noisy-Neighbor-Problem, oder? Ihr seid von anderen, unabhängigen Projekten getrennt und werdet nicht durch deren CPU-Nutzung oder Ausführung beeinflusst. Das ist der erste Vorteil. Der zweite ist, dass ich keine neue Programmiersprache lernen muss, weil ich auf das Linux-Ökosystem und universelle Sprachen wie Python zugreifen kann. Im Gegensatz zu vielen anderen Appchains, die oft domänenspezifische Sprachen haben.

João Genau. Noch etwas, das ich vergessen habe und das relevant ist: Wir haben diesen RISC-V-Emulator entwickelt und Linux darauf gesetzt. Theoretisch könnten wir die Sprachen direkt auf RISC-V ausführen, sie einfach dafür kompilieren und starten. Dann würden wir aber dasselbe machen wie einige andere Protokolle. Um den Begriff aus C zu verwenden: Wir würden eine freistehende Sprache ausführen, mit dem absoluten Minimum, das zum Ausführen nötig ist. Dabei verliert ihr Ressourcen wie ein Dateisystem und bestimmte Standardbibliotheken, mit denen ihr Informationen auf unterschiedliche Weise verarbeiten könnt. Ein Betriebssystem darin gibt euch noch mehr Flexibilität und Möglichkeiten.

Kann Cartesi verifizierbare KI und LLMs ausführen?

Kevin Das ist oft das Problem, wenn Projekte sagen: Ihr könnt C++, C, Python oder was auch immer nutzen, aber dann ist es stark eingeschränkt. Richtig. Deshalb ist es wirklich gut, wenn man Zugang zum ganzen Ökosystem hat, und technisch ziemlich beeindruckend. Ein Anwendungsfall auf eurer Website, natürlich ein aktuelles Thema, ist verifizierbare KI. Könntest du das etwas erläutern?

João Natürlich. Verifizierbare KI ist etwas sehr Interessantes, mit dem wir uns schon eine Weile beschäftigen. Aber ich denke auch, dass die Leute etwas überschätzen, was das Wort KI bedeutet. Wenn jemand KI sagt, denken alle an KI-Agenten und sofort an LLMs, weil ChatGPT so viel Aufmerksamkeit erzeugt hat, dann DeepSeek und alle anderen. KI ist aber viel mehr. Sie beginnt mit Grundkonzepten wie linearer Regression und KNNs. Es gibt viele KI-Algorithmen. Wir haben mit einfachen Beispielen begonnen und bestimmte Techniken verwendet, weil das Kompilieren von Bibliotheken für RISC-V anfangs nicht so einfach war. Heute ist es das, aber wir begannen mit KNNs und linearer Regression. Dabei brauchten wir einen Mechanismus, den ein Freund von mir umgesetzt hat, Marcos, Grüße an ihn, namens [Werkzeug zur Modellumwandlung in Code; Name unklar]. Man wandelt das Machine-Learning-Modell in direkten Python-Code um, und das funktionierte gut. Dann konnten wir Machine-Learning-Bibliotheken wie PyTorch und scikit-learn für unsere Maschine cross-kompilieren. Ihr könnt diese Bibliotheken also vollständig auf RISC-V und Linux in unserer Maschine nutzen. Das ist wirklich cool. Leider brauchen viele Modelle wie LLMs so viele Ressourcen, dass ihr für ihre Verifikation sehr große Computer oder GPUs benötigen würdet. GPUs haben wiederum das Problem, nicht deterministisch zu sein. Man müsste also Umwege finden. Anfangs klangen LLMs sehr komplex, aber wir kommen voran und machen gute Fortschritte. Bei einem internen Hackathon mit unseren Entwicklern und Mitwirkenden hat Eduardo, ein großartiger Entwickler, einen Weg gefunden, Dinge in der Cartesi Machine laufen zu lassen, die komplexen Berechnungen, also die Matrixmultiplikationen für LLMs, aber an die Host-Maschine zu delegieren. Statt nur eine CPU zu nutzen, verwendet ihr eine CPU für den emulierten Teil und delegiert die deterministischen Berechnungen an die Host-Maschine. Das ist ziemlich verrückt. Dadurch haben wir die Rechenleistung deutlich verbessert und können jetzt anfangen, LLMs deterministisch auszuführen. Wir untersuchen, wie wir dabei weiterkommen können.

Welche DeFi- und Onchain-Spiele brauchen diese Rechenleistung?

Kevin An der Spitze der Entwicklung zu arbeiten bedeutet meistens Forschung. Das gehört dazu. Mich interessiert, welche anderen Anwendungsfälle ihr gerade untersucht. Universell bedeutet, dass man viele Dinge machen kann. Und sicher gibt es auch Dinge, die man vielleicht nicht tun sollte oder kann. Das wäre ebenfalls interessant.

João Meinst du allgemeine Anwendungsfälle innerhalb des maschinellen Lernens oder insgesamt?

Kevin Das, worauf du persönlich am meisten gespannt bist.

João DeFi dürfen wir nicht auslassen. Das ist schließlich die Welt, in der wir uns bewegen. Eine Lösung, die ich sehr cool finde, heißt DCA.Monster. Sie setzt die Dollar-Cost-Averaging-Strategie um, aber mit minimaler Granularität. Ihr nehmt die kleinste Einheit, die ein Token hat, etwa 10 hoch 18 oder was auch immer, und tauscht die Assets in sehr kleinen Portionen. Ihr könnt sagen: Ich will diesen Token in Dollar oder USDT tauschen, aber über einen Monat. Dann wird jede Sekunde in diesem Monat dieser kleine Anteil getauscht. Das ist wirklich cool und sonst nicht möglich, wenn ihr keine Maschine habt, die diese Berechnungen so einfach in dieser Genauigkeit durchführen kann. Im Grunde ist es ein Automated Market Maker, der ziemlich gut funktioniert. Diese Lösung finde ich interessant. Und als jemand, der ein bisschen geekig ist, liebe ich natürlich Spiele. Es gibt zwei Spielelösungen, die ich gerne erwähne. Eine heißt RIVES, die Website ist rives.io. Das ist eine individuelle Onchain-Konsole, auf der man Spiele entwickeln, verkaufen und deterministisch spielen kann. Angefangen hat es mit Doom. Die Leute konnten Doom spielen und ihre Gameplay-Logs, also jede Eingabe an das Spiel, an die Blockchain schicken, worauf ihr Spielverlauf verifiziert wurde. Das ist sehr cool für Speedruns, Wettbewerbe und Turniere. Dann gibt es noch eine andere, die kürzlich gestartet ist: World Tycoon. Erinnerst du dich an SimCity? Ja, klar. Wir haben SimCity onchain gebaut. Wir haben gerade diesen Grant abgeschlossen. Ich evaluiere es und mache Code Reviews. Es ist SimCity onchain. Ihr zahlt zuerst eure Assets ein. Wenn ihr mit eurer Stadt Geld verdient, könnt ihr die Assets bekommen, die andere eingezahlt haben, um ihre Stadt zu bauen, wenn diese scheitern. Diese Dynamik mit Tokens in SimCity macht ziemlich viel Spaß.

Wann sollten Entwickler Solidity statt Cartesi nutzen?

Kevin Sehr gut. GameFi ist immer ein großes Thema, ein großer Teil von Blockchain und dem Kryptobereich. Gibt es Dinge, für die Cartesi nicht besonders geeignet oder nicht ideal ist?

João Sehr gute Frage. Wenn wir Anwendungen isoliert betrachten, sehe ich nicht, warum die Leute es nicht verwenden sollten. Aber ich denke nicht, dass sie Cartesi einfach verwenden und etwas bauen sollten. Wenn ihr die Rechenleistung oder bestimmte Bibliotheken nicht braucht, um eure Software und eure Vision umzusetzen, solltet ihr vielleicht einfach bei Solidity bleiben. Cartesi wurde nicht dafür gemacht, zu sagen: „Ich kann das mit Solidity machen, würde es aber lieber in JavaScript tun, also schreibe ich es mit Cartesi.“ Das ist nicht die beabsichtigte Idee. Natürlich könnt ihr das. Jeder kann die Anwendung verwenden, wie er möchte. Aber wenn etwas in Solidity einfacher ist, benutzt es einfach. Das ist kein Problem.

Kevin Es geht also mehr darum, Entwickler zu informieren: Wenn ihr einen dieser gewöhnlichen Solidity-Smart-Contracts bauen wollt, etwas, das ständig gebaut wird, folgt den Best Practices, statt mit Python das Rad neu zu erfinden.

João Genau. Die ganze Idee von Cartesi, Linux und all diesen Bibliotheken besteht darin, das Rad nicht neu zu erfinden. Versucht nicht, extrem komplexe Machine-Learning-Bibliotheken in Solidity nachzubauen. Nutzt, was ihr habt. Verwendet das Rollup, das euch das ermöglicht. Und auch das Gegenteil stimmt: Es gibt bereits Dinge, die für die normale Token-Erstellung sehr gut funktionieren. Versucht nicht, das Rad neu zu erfinden und das vollständig auf Cartesi neu zu bauen. Die Dinge sollen [unklar] zusammenwirken, statt miteinander zu konkurrieren. Nutzt den besten Anwendungsfall für jedes Werkzeug.

Welche ungewöhnlichen Spiele haben Entwickler gebaut?

Kevin Gefällt mir. Wir haben schon über interessante oder nützliche Anwendungsfälle gesprochen. Habt ihr in eurer Community verrückte oder besonders lustige entdeckt, bei denen ihr sagt: Ich bin nicht sicher, ob das nützlich ist, aber interessant ist es?

João Entschuldigung, was meinst du genau?

Kevin Kennst du verrückte Lösungen oder Anwendungsfälle, die Leute auf eurer Plattform gebaut haben, oder bisher nur nützliche Dinge?

João Nein, es gibt verrückte, lustige Dinge. Eines liebe ich besonders. Ich glaube, es ist nicht mehr auf dem Mainnet, vielleicht doch. Es war ein Meme-Kampf. Die Leute haben auf ein Meme gewettet. Zum Beispiel [Figurenname unklar] gegen Sonic. Man simuliert einen Kampf zwischen den beiden und sieht, wie sie gegeneinander kämpfen. Die Leute konnten auf ihren Lieblingskämpfer wetten. Es war etwas verrückt und durch KI automatisiert, also eine Art Zero-Player-Game. Sehr lustig. Und noch eines war so degeneriert, ich glaube, es läuft tatsächlich. Es heißt Bubble Wars. Ihr investiert Assets und werdet zu einer Blase, deren Größe von der Anzahl eingezahlter Tokens abhängt. Dann bewegt ihr die Blase mit Onchain-Physik, schiebt sie in eine Richtung. Wenn sie eine andere Blase berührt, stiehlt sie die Assets dieser Person. [Unklar]. Ihr wachst und eure Blase wird größer. Es ist wirklich degeneriert, aber sehr lustig.

Kevin Wow, das klingt sehr schmerzhaft. Stell dir vor, du hast so viel gesammelt und dann kommen diese großen Blasen, wie in diesem Spiel, ich glaube, es hieß [Spielname unklar]. Wie heißt das ursprüngliche Spiel? [Kurzer Austausch über den unklaren Spielnamen]. Verrückt. Das könnte ich mir vorstellen, wenn es richtig vermarktet wird. Das kann viral gehen. Das macht Spaß.

Was macht die Entwicklung von Fraud Proofs schwierig?

Kevin Ich bin nicht sicher, es klingt danach, aber wie tief warst du in die eigentliche Infrastrukturarbeit eingebunden? Kannst du ein paar zentrale Erkenntnisse aus der anfänglichen Entwicklung teilen? Was waren die Hauptprobleme und welche sind es heute, um das verifizierbarer zu machen?

João Ich war bei Cartesi nicht von Anfang an dabei. Die Idee entstand, glaube ich, 2018, als das erste Whitepaper geschrieben wurde. Ich bin erst vor ungefähr zwei Jahren gekommen. Okay. Aber anhand dessen, was ich jetzt lerne und was ich im Team sehe, war die Entwicklung der Fraud Proofs etwas sehr Heikles und sehr Schönes. Wie sie entwickelt und vorgeschlagen wurden. All die kleinen Dinge, die ihr bei einem Fraud-Proof-Algorithmus bedenken müsst: die Liveness der Chain, die Kosten einer Teilnahme, was ihr staken müsst, um am Fraud Proof teilzunehmen. Alles wird gemeinsam entschieden, bis der Algorithmus zusammenpasst. Verrückt. Zuerst hatten wir einen Fraud Proof namens PRT. Bald veröffentlichen wir eine praktische Version und wir haben bereits das Paper für Dave, eine verbesserte Version. Es war sehr interessant, die Schwierigkeiten und Schwachstellen jedes Fraud Proofs zu sehen und wie wir alle angehen mussten. Gabriel Coutinho, der die Entwicklung dieser Algorithmen leitet, hat sie mir während ihrer Entstehung erklärt. Ich war jedes Mal verblüfft: Sie stießen an eine Wand und diese genialen Köpfe konnten sie durchbrechen. Er erzählte mir von den Meetings: „Hey, Augusto, ich habe gerade einen Fehler gefunden. Das funktioniert nicht.“ Augusto, einer der Gründer von Cartesi, sagte dann: „Ich brauche Zeit zum Nachdenken“, ging zum Whiteboard, zeichnete etwas und kam mit einer Lösung zurück. Das war großartig. Ich denke, das war der heikelste Teil.

Wo liegen die Grenzen von Appchains und der Nutzen der Modularität?

Kevin Sehr gut. Kryptografie, wenn ich es aussprechen kann, ist immer ein sehr anspruchsvolles Thema. Schön, dass ihr eine gute Teamdynamik habt. Eine letzte Frage: Welche drei wichtigsten Erkenntnisse hast du selbst aus der Arbeit am Projekt gewonnen, oder möchtest du Entwicklern mitgeben, die Cartesi kennenlernen und nutzen wollen?

João Die wichtigsten Erkenntnisse: Es gibt kein Allheilmittel. Kein einzelnes Protokoll, kein Stack kann alles. Jeder hat Grenzen. Auch Cartesi hat Grenzen, obwohl ihr Linux ausführt und alles machen könnt, was in Web2 möglich ist. Manche Dinge müsst ihr umgehen. Wenn ihr etwa Interoperabilität zwischen Rollups wollt, müsst ihr das gut durchdenken. Deshalb haben wir weitere Lösungen wie den Coprocessor entwickelt, die andere Vorteile bieten. Er liefert keinen Rollup-Mechanismus, sondern eine Coprocessor-Lösung mit schneller Finalität. Das ist sehr gut. Erstens also: Es gibt kein Allheilmittel. Zweitens geraten Leute, die das Rad neu erfinden, in eine Falle. Sie versuchen so lange, etwas Neues zu bauen, statt Bestehendes zu nutzen, dass sie die Chance verpassen, etwas wirklich Relevantes zu schaffen. Drittens sollten Protokolle zusammenarbeiten. Das ist am wichtigsten. Wir hatten großartige Partnerschaften mit [Name unklar] für unseren Coprocessor, mit Espresso und mit Avail. Wenn zwei Teams, die auf bestimmte Dinge spezialisiert sind, ihr Wissen zusammenbringen, entstehen noch bessere Lösungen. Seht euch etwa unsere Espresso-Integration an: Ihr verwendet unsere Ausführungsumgebung mit deren Datenverfügbarkeit und Sequenzierung und baut etwas, das sich von allem bisher Bekannten unterscheidet. Wählt jeweils das Beste, um die perfekte Lösung für euch zu bauen. Zusammenarbeit sollte das Motto des gesamten Ökosystems sein.

Kevin Das gefällt mir. Das ist der Geist von Web3. Wie die Leute sagen: Es geht um Community und darum, etwas zu bauen, das die Menschen wirklich wollen. Genau. Großartig.

Wie können Entwickler mit Cartesi anfangen?

Kevin Noch ein Schlusswort? Was sollten die Leute nach dieser Folge tun?

João Kürzlich bekam ich das Feedback, dass wir wirklich gute Dokumentation haben. Probiert Cartesi aus, experimentiert und spielt damit. Tretet unserer Community bei. Auch wenn ihr nicht programmieren wollt, kommt dazu und seht, was dort gebaut wird und entsteht. So könnt ihr mehr darüber lernen. Wenn ihr reden möchtet oder Fragen habt, erreicht ihr mich auf Discord oder Twitter. Ich bin dort. Bis bald.

Kevin Gut. Die Links kommen auf jeden Fall in die Videobeschreibung. Danke nochmals für deine Flexibilität und deine Zeit. Es war toll, mit dir zu sprechen. Viel Neues, das ich weiter erkunden möchte. Noch etwas für alle Entwickler und Nichttechniker: Gute Dokumentation wird so unterschätzt. Dafür ein großes Lob an euch. Cool.

João Das stimmt absolut.

Kevin Sehr gut. Danke, Mann. Schön, mit dir zu sprechen. Hab noch einen schönen Tag.

João Bis bald. Bis bald.

Kevin Wavect, das Web3-Softwareunternehmen, das versteht, was ihr wollt.