Author
Translated by:
Der Blockchain-Entwicklungszyklus ist, in den Worten von Tim Reznichenko, einem Senior-Full-Stack-Web3- und TypeScript-Ingenieur und technischen Leiter bei K&C, „länger als bei Web2“. Das bedeutet, dass Blockchain-Entwicklung auch mehr kostet – etwas, das sich dApp-Projektsponsoren bewusst sein müssen, bevor sie ein Blockchain-Entwicklungsprojekt beliebigen Umfangs und beliebiger Komplexität in Angriff nehmen.
Wenn Tim seine Einblicke und Meinungen zur Web3-Entwicklung teilt, lohnt es sich, ihm zuzuhören. Er ist seit Anfang 2023 bei unserem Partner Ajna Labs, einem amerikanischen DeFi-Startup, eingegliedert und gründete zuvor eine Krypto-Börse, LocalRelayer und eine Webentwicklungsfirma.
Er ist ein erfahrener Web3-Entwicklungsleiter.
Bild: Tim spricht auf einer Konferenz über Web3-Entwicklungsthemen
Als wir uns kürzlich über die Herausforderungen bei der Blockchain-Entwicklung unterhielten, kamen wir auf das Thema zu sprechen, warum Web3-Projekte in der Regel einen längeren Entwicklungszyklus (Software Development Life Cycle) haben und mehr kosten als vergleichbare Mainstream-Webentwicklungsprojekte.
Wir beschlossen:
- eine Liste allgemeiner technischer Herausforderungen und Realitäten des Web3-Ökosystems zu erstellen, die seiner Meinung nach „zusammen den Web3-Entwicklungszyklus verlängern“.
- dass er gerne sein Wissen mit uns teilt, wie man die Auswirkungen dieser Faktoren minimiert und kluge Entscheidungen trifft. Dieses Wissen hat er sich im Laufe der Jahre und mehrerer Blockchain-Entwicklungsprojekte angeeignet.
Da das Gehaltsniveau von Web3-/Blockchain-Entwicklern im Vergleich zu dem der Kollegen mit Mainstream-Webentwicklungsstacks bereits sehr hoch ist, bedeuten längere Entwicklungszyklen höhere Kosten.
Die gute Nachricht ist, dass Tim davon überzeugt ist, dass die aktuellen Entwicklungen im Web3-Entwicklungsökosystem den Zeit- und Kostenaufwand für die dApp-Entwicklung in den nächsten Jahren erheblich verringern werden. Außerdem ist er überzeugt, dass die üblichen Einschränkungen im Nutzererlebnis, die sich momentan noch negativ auf die Nutzerzahlen auswirken, überwunden werden können.
Ebenfalls sollte es in Zukunft gemäß ihm Möglichkeiten geben, den Einfluss von vielen der Faktoren, die die dApp-Entwicklung komplizierter machen, zu minimieren.
Die technischen Entscheidungen und Herausforderungen, die den Lebenszyklus der Web3-Entwicklung komplexer machen und verlängern
Dies sind die großen Fragen und spezifischeren technischen Herausforderungen und Stolpersteine, die Tim als Leiter eines Blockchain-Entwicklungsteams erlebt hat.
Wenn man sich nur schon dieser Probleme bewusst ist, hat man einen Vorsprung gegenüber vielen Geldgebern und Entscheidungsträgern von Web3-Entwicklungsprojekten.
Und Tim geht noch einen Schritt weiter – er gibt einen Einblick, wie man über diese Probleme nachdenken und sie minimieren kann, basierend auf seiner Erfahrung in mehreren dApp- und Blockchain-Projekten.
Die Wahl der Blockchain, auf der entwickelt werden soll, ist immer ein Kompromiss zwischen Sicherheit und Skalierbarkeit
Web3-Projekte, die auf Basis der Blockchain-Technologie entwickelt werden, sind laut Tim immer mit Kompromissen zwischen Sicherheit, Skalierbarkeit und Dezentralisierung konfrontiert.
Ethereum ist die beliebteste Blockchain, auf der entwickelt wird, unterstützt aber nur 4-10 Transaktionen pro Sekunde. Alternativen wie Solana und Neo können Transaktionszahlen von Hunderten oder Tausenden pro Sekunde verarbeiten, erreichen dies aber durch Kompromisse bei der Sicherheit und Dezentralisierung, die Ethereum nicht eingeht.
Dies steht im Vergleich zu den Zehntausenden von Transaktionen pro Sekunde, die traditionelle Finanzinfrastrukturanbieter wie Visa und Mastercard verarbeiten können.
Eine der Hauptursachen für die inhärenten Einschränkungen von Ethereum in Bezug auf die Skalierbarkeit ist jedoch, so Tim, dass es „keine Kompromisse bei der Sicherheit eingeht“. Eine der Stärken in Bezug auf Sicherheit der Ethereum-Blockchain ist der hohe Grad an Dezentralisierung, den ihr umfangreiches Netzwerk von Nodes (Knotenpunkten) bietet.
Eine verbesserte Skalierbarkeit bringt die Notwendigkeit mit sich, bei mindestens einem der beiden Aspekte Sicherheit oder Dezentralisierung Kompromisse einzugehen. Dies ist als das „Skalierbarkeits-Trilemma“ der Blockchain bekannt.
Die BNB-Chain zum Beispiel ist beinahe identisch mit der Ethereum-Blockchain. Der einzige wirklich signifikante Unterschied, sagt Tim, ist, dass die Dezentralisierungsseite des Blockchain-Trilemmas weitgehend entfernt wurde, um Skalierbarkeit zu ermöglichen – die Chain wird „im Grunde von Binance-Stakeholdern kontrolliert und ist nicht wirklich dezentralisiert“.
Solana, so Tim, ist dafür bekannt, dass es jedes Jahr „einige Tage lang nicht funktioniert“, weil „sie einige Änderungen implementiert haben, die die Skalierbarkeit und die Sicherheit verbessert haben, was aber bedeutet, dass diese Blockchain jetzt manchmal einfach nicht mehr funktioniert“.
L2-Lösungen wie Polygon, Optimism und Starknet (Tim nennt es „zk-Stark“) sind Blockchains, die auf L1-Blockchains wie Ethereum aufbauen. Sie nutzen den digitalen Ledger (Hauptbuch) der zugrundeliegenden Blockchain, sind aber nicht von Natur aus dezentralisiert, weil sie in der Regel von einer relativ kleinen Anzahl von Stakeholdern kontrolliert werden können.
Er erwähnt die Website L2beat.com, die seiner Meinung nach eine gute Ressource darstellt und L2-Lösungen nach Kriterien wie der Kapazität für Transaktionen pro Sekunde, der Sicherheit und anderen Eigenschaften einstuft.
Um die Bedenken hinsichtlich einer echten Dezentralisierung zu zerstreuen, bieten L2-Blockchains in der Regel eine viel bessere Leistung. Die Sicherheit wird durch die Erstellung regelmäßiger Snapshots des Zustands der zugrunde liegenden Chain gewährleistet.
Das in den USA ansässige DeFi-Projekt, an dem Tim als Teil eines integrierten K&C-Teams arbeitet, stand vor der Herausforderung, einen „Multi-Chain“-Zugang zu seinen Liquiditätspools anzubieten, um den Nutzern die Wahl zu lassen und die Akzeptanz zu erleichtern. Dabei kommt Polygon bereits zum Einsatz, es sind aber noch viele weitere geplant.
Da es keine Interoperabilität zwischen Smart Contracts auf verschiedenen Chains gibt, sind die dApps und Blockchain-Protokolle für jede Chain praktisch unabhängig voneinander. Dazu müssen separate Liquiditätspools existieren – Mittel, die ein Kreditgeber über die Polygon dApp einzahlt, stehen einem Kreditnehmer, der die Ethereum-Anwendung oder eine andere L2 wie Optimism nutzt, nicht zur Verfügung.
Ein Multi-Chain-Ansatz bedeutet, dass die Nutzer ihre eigenen Entscheidungen bezüglich des Blockchain-Trilemmas treffen können. Beispielsweise würde ein Kreditgeber, der Kryptowährungen im Wert von Hunderttausenden oder Millionen von Dollar einbringt, vermutlich der Sicherheit den Vorrang geben und sich für die Ethereum dApp entscheiden.
Kreditgeber und -nehmer mit kleineren Summen könnten jedoch bereit sein, einige Sicherheitskompromisse einzugehen, um die Polygon-Anwendung zu nutzen – denn die L2-Blockchain bietet günstige Transaktionen.
Brücken, die Blockchains verbinden, sind eine sich entwickelnde Lösung für die Interoperabilität zwischen Multichain-dApps, die die Entwicklungskomplexität verringern
Tim beschreibt die Skalierbarkeit von dApps als eng verbunden mit dem sich entwickelnden Ökosystem von „Brücken“, die die Interoperabilität zwischen Multichain-Implementierungen ermöglichen. Brücken, so Tim, bedeuten, dass Multichain dApps durch die Verwendung mehrerer Blockchains skalieren können und trotzdem ein vorteilhaftes Nutzererlebnis bieten.
Tim sagt, dass insbesondere im letzten Jahr viele neue Brücken-Lösungen in das Web3-Entwicklungsökosystem eingeführt wurden. Und dass es jetzt eine Handvoll stabiler SDKs (Software Development Kits) gibt, die einen relativ bequemen Zugang zu Chain-übergreifenden Funktionalitäten und Prozessen bieten.
Eine Entwicklung, die dazu beiträgt, dass die Blockchain-Entwicklung effizienter wird, sind vermehrt sofort einsatzbereite Brücken-Lösungen. Es ist nun häufiger der Fall, dass nur eine bestehende Brückenlösung integriert werden muss, während früher oft komplexes Programmieren und Werkzeuge erforderlich waren, um die gleichen Ergebnisse zu erzielen.
Herausforderungen beim Nutzererlebnis und Überlegungen bei der Blockchain-Entwicklung
Tim nennt die folgenden Quellen für Einschränkungen im Nutzererlebnis, die dApps oft überwinden müssen, um ihre Nutzerbasis erfolgreich zu expandieren:
- Benutzer müssen eine spezielle Browsererweiterung installieren, um dApps zu nutzen.
- Benutzer müssen viele Funktionen, die sie ausführen möchten, manuell genehmigen; und
- Gebühren in einer Blockchain-Währung zahlen, die sie möglicherweise nicht besitzen.
Die Entwicklung einer nativen dApp für Webbrowser und mobile Betriebssysteme erfordert die Integration einer proprietären Wallet. Die Entwicklung einer proprietären Wallet birgt jedoch Sicherheitsrisiken und kann eine Schwachstelle darstellen, wenn sie nicht nach den höchsten Standards erfolgt.
Gibt es eine Möglichkeit, diese häufigen Einschränkungen im Nutzererlebnis in dApps zu minimieren oder ganz zu umgehen?
ERC-4337 account abstraction – ein Vorschlag zur Abstraktion von Konten, der die Notwendigkeit von Consensus-Layer-Protokolländerungen vollständig vermeidet.
Ein Vorschlag für eine Ethereum-Schnittstelle, mit der die Notwendigkeit einer Wallet von der Benutzererfahrung abstrahiert werden kann. Das wiederum ermöglicht es, dass das Nutzererlebnis einer dApp der einer regulären Web2-App entspricht.
Sie ermöglicht es einem Nutzer, sicher mit einer dApp zu interagieren, ohne dass er seinen privaten Zugangsschlüssel verwalten muss, wodurch die Benutzererfahrung nativer wird. Es beinhaltet auch das Konzept der Sponsoring-Gebühren, die stattdessen vom dApp-Besitzer getragen werden. Laut Tim ist dies vergleichbar mit der Art und Weise, wie Einzelhändler Visa- und Mastercard-Transaktionen als Kosten für die Bequemlichkeit von Kartenzahlungen abdecken.
Tim ist jedoch der Meinung, dass die ERC-4337-Lösung „noch nicht ausgereift“ ist und dass die Einschränkungen im Nutzererlebnis der dApp weiterhin so gehandhabt werden müssen, wie sie derzeit sind, so dass der Nutzer gezwungen ist, sie auf möglichst schmerzfreie Weise zu tolerieren.
Tim rechnet damit, dass sich dies in etwa einem Jahr ändern wird. Neue Lösungen wie ERC-4337 werden es dApps ermöglichen, mehr dieser aktuellen Einschränkungen im Nutzererlebnis „unter die Haube“ zu bringen und von den Nutzern zu abstrahieren. ERC-4337 und andere vorgeschlagene Lösungen müssen noch perfektioniert werden, sind aber nahe am Ziel.
Vermeiden Sie katastrophale Nutzererlebnisse von dApps durch den Einsatz von Designern mit vorheriger Erfahrung und einem soliden Verständnis von Blockchain und Web3
Tim hebt hervor, dass es ein potenziell fataler Fehler ist, sich auf UX-Designer zu verlassen, die noch nie an dApps gearbeitet haben oder ein gutes Verständnis von Web3 haben. Er hat erlebt, dass dApps in diesem Fall „kaum benutzbar“ und „nicht zweckdienlich“ sind.
Auf die Frage nach einem konkreten Beispiel dafür, was schief gehen kann, wenn UX-Design die Besonderheiten von Web3 nicht vollständig berücksichtigt, präsentiert Tim stattdessen ein Gegenbeispiel.
Der UX-Designer, mit dem sein Team an unserem Kundenprojekt gearbeitet hat, ist, wie er sagt, „ein großartiger Designer und er versteht Krypto, er versteht es wirklich. Und er versteht etwas von Finanzen, was ebenfalls wichtig ist. Fachwissen, das für einen UX-Designer wichtig ist, ist in vielen Bereichen anwendbar. Aber bei Krypto ist es besonders wichtig“.
„Der Designer muss die technischen Aspekte verstehen – z. B., dass Transaktionen einige Zeit in Anspruch nehmen können, bis sie abgeschlossen sind. Die Benutzeroberfläche sollte also deutlich zeigen und dem Benutzer versichern, dass die Transaktion im Gange ist und nur etwas Zeit benötigt – und dass nichts schiefgegangen ist. Zum Beispiel sollte die UI der dApp eine Art „in Bearbeitung“-Fenster zeigen.“
Das Scheitern von Krypto-Transaktionen, das laut Tim aus verschiedenen Gründen relativ häufig vorkommt, ist ein weiterer Punkt, den das UX-Design berücksichtigen muss, um ein positives Nutzererlebnis zu gewährleisten.
Apps, die traditionelle Finanzdienstleistungen anbieten – Tim nennt als Beispiel den Handel mit ETFs – müssen sich mit ähnlichen Herausforderungen im Nutzererlebnis rund um Verzögerungen und Fehler bei der Transaktionsverarbeitung auseinandersetzen. Jedoch sind diese Probleme im Kontext der Kryptomärkte noch ausgeprägter.
Web3-Entwickler müssen sich mit einem weniger entwickelten Ökosystem auseinandersetzen
Sind Sie alt genug, um sich daran zu erinnern, wie Sie mit dem Auto an einen nicht vertrauten Ort fahren mussten, bevor GPS-Navigation zum Standard wurde? Wir mussten uns auf Straßenschilder verlassen, Passanten aus dem Fenster Fragen zurufen und als letzten Ausweg physische Karten verwenden.
Eine bekannte Sehenswürdigkeit in einer Großstadt zu finden, war in der Regel nicht sehr schwierig. Viel eher verpasste man noch die richtige Ausfahrt auf einer Autobahn. Einen ländlichen Zufluchtsort oder ein neues Restaurant in einem unbekannten Vorort zu finden? Ein Rezept für eine Katastrophe und das Scheitern so mancher Beziehung!
Der Unterschied zwischen Web3 und Mainstream-Webentwicklung ist vergleichbar – in einer lockeren „Bitte seien Sie nett zu meiner Metapher, ich bin sehr stolz darauf“-Art.
Web2-Entwickler können, so Tim, recht einfach Informationen oder Werkzeuge einholen, die sie benötigen, indem sie googeln oder in bekannten Ressourcen wie GitHub oder Stack Overflow suchen.
Im Web3 ist das normalerweise viel schwieriger. Selbst wenn jemand bereits etwas programmiert und freigegeben hat, ist es oft in einer obskuren Ecke des Internets versteckt – wie das Repo eines kleinen Hackathons oder auf GitHub gepostet von einem Forschungsteam, das „nur 2 Sterne“ hat.
Je mehr die Frage einer untergeordneten Nische zugeordnet werden kann, desto schwieriger ist es, eine bereits vorhandene Antwort zu finden. Das ist ein bisschen so, wie wenn man versucht, das Ferienhaus am Ende eines Wegs zu finden, der von einer Dorfstraße abzweigt, bevor es GPS gab.
Neue KI-Tools (LLM) wie ChatGPT und Bard, die den Vorteil haben, dass sie mit dem Internet verbunden sind und eine aktuellere Codebasis haben, sind eine Lösung, die Web3-Entwickler nutzen. Aber insgesamt bedeutet das weniger entwickelte Web3-Ökosystem, dass es länger dauert, bereits existierende Lösungen und Code zu finden, obwohl es sie schon gibt.
Und es ist weitaus häufiger der Fall, dass Lösungen und Funktionen von Grund auf neu programmiert werden müssen – was den Lebenszyklus der Web3-Entwicklung verlängert und die Kosten erhöht.
TypeScript sollte zu Gunsten von JavaScript in der Web3-Frontend-Entwicklung verwendet werden
Abgesehen von „exotischen“ Grenzfällen, wie Tim sagt, läuft die Wahl der Sprache für die Frontend-Entwicklung von dApps auf JavaScript oder Typescript hinaus.
Typescript hat einige Eigenschaften, die dazu beitragen, potenzielle Schwierigkeiten zu umgehen, die bei der Verwendung von JS in der dApp-Entwicklung auftreten können. Dazu gehört die Tatsache, dass es sicherer ist und von anderen Tools und Compilern besser unterstützt wird, da es „stark typisiert“ ist.
Ganz allgemein sagt Tim, dass die Notwendigkeit von Mathematik in der Frontend-Entwicklung, wie sie oft bei JavaScript der Fall ist, bei Finanzanwendungen vermieden werden sollte.
Dies liegt daran, dass dApp-Backends entweder nicht im herkömmlichen Sinne existieren und durch eine Blockchain ersetzt werden, oder sie sind begrenzt und schränken die Möglichkeiten des Entwicklungsteams ein.
Daher müssen die Entwickler einige Dinge wie die Aggregation von Zahlen und Berechnungen, die normalerweise im Backend durchgeführt werden, im Frontend erledigen. Die Benutzer müssen im Frontend echte Zahlen sehen, keine Näherungswerte oder falsche Berechnungen – „und JavaScript ist sehr schlecht in Mathematik“.
Um diese Einschränkung von JavaScript zu umgehen, muss BigNumber.js oder eine andere geprüfte Zahlenbibliothek verwendet werden.
Zusammenfassend lässt sich sagen, dass die Verwendung von TypeScript anstelle von JavaScript für die dApp-Frontend-Entwicklung „mehr Typisierungssicherheit“ bietet.
dApp UI-Entwicklung – React bietet das umfangreichste Ökosystem an Blockchain-spezifischen Bibliotheken und Projekten
Die React-Bibliothek ist die beliebteste Wahl für die Erstellung von UI für dApps und bietet die größte bestehende Sammlung von Blockchain-spezifischen Bibliotheken und Projekten. Allerdings besteht oft die Notwendigkeit, die Präsentations- und Logik-/Datenebenen eines dApp-Frontends zu trennen. In diesem Fall sind Frameworks wie Next.js neben React und TypeScript eine beliebte Wahl, sagt Tim.
End-to-End-Tests sind für Web3-Anwendungen nur schwer zu erstellen
Das Schreiben von Unit-Tests für dApps ist, wie Tim erklärt, für Web3- und Web2-Anwendungen mehr oder weniger gleich – aber umfassende Tests, die auch die korrekte Integration zwischen den Komponenten überprüfen, sind im Web3-Bereich viel schwieriger zu erstellen.
Die Komplikationen beim Schreiben von End-to-End-Tests für dApps ergeben sich aus der Tatsache, dass sie Wallets von Drittanbietern wie MetaMask verwenden müssen. Das bedeutet, dass die Tests auch mit Drittanbieter-Entitäten integriert werden müssen, die nicht Teil der dApp sind.
Dies erfordert einen „speziellen Aufbau“ mit einer privaten Blockchain, da Tests nicht auf öffentlichen Blockchains durchgeführt werden können, da diese unveränderlich sind und es keine Möglichkeit gibt, den Zustand zurückzusetzen. Die Tests müssen also mit einem Snapshot der öffentlichen Blockchain beginnen und die Chain auf einer lokalen Blockchain durchlaufen, die den aktuellen Zustand der zugrunde liegenden öffentlichen Blockchain nachbildet.
End-to-End-Bibliotheken wie Cypress unterstützen dApps nicht von Haus aus. Das bedeutet, dass Plugins für Integrationen mit Web3-Entitäten wie MetaMask von Grund auf neu beschafft oder programmiert und Frameworks erweitert werden müssen, um den Anforderungen gerecht zu werden, was wiederum zeitaufwändig ist.
Ein Großteil der dApps, so Tim, leidet unter einem Mangel an umfassenden End-to-End-Tests, weil der Aufbau dazu so komplex, zeitaufwändig und teuer ist.
Auf die Frage, wie sich das Ökosystem der Web3-Testtools entwickelt, sagt Tim, dass die Kategorie in zwei Bereiche unterteilt werden muss:
- Tests für Smart Contracts
- Tests für dApps
Die Werkzeuge für das Testen von Smart Contracts werden laut Tim derzeit in rasantem Tempo verbessert – „Monat für Monat“. Laut Tim gibt es bereits viele Tools für das Testen von Smart Contracts, einschließlich Testsuiten für seltene Fälle wie „schnelle Tests„ oder extreme Nutzlasten – für Solidity und andere gängige Smart-Contract-Sprachen.
Wenn es um Testwerkzeuge für dApps geht, gibt es jedoch „nicht viel Bewegung“.
Er glaubt, dass es einen klaren Bedarf für eine Bibliothek gibt, die dApp-Tests abdeckt, und dies ist einer seiner persönlichen Interessenpunkte. Auf meine Frage, ob er „ein Gründer einer dApp-Testbibliothek“ wird, antwortet er mit einem Schmunzeln und einem „vielleicht, vielleicht“.
Sicherheit – man muss mit dem Schlimmsten rechnen, denn Hacker haben es auf neue dApps abgesehen
Tim sagt, dass die Sicherheit von dApps, insbesondere im Fall von Finanz-dApps, absolute Priorität haben sollte – denn Hacker haben es auf neue dApps abgesehen, wohl wissend, dass die zusätzliche Komplexität eines umfassenden End-to-End-Tests bedeutet, dass dafür in vielen Fällen nicht genügend Ressourcen zur Verfügung stehen.
Auf die Frage, welche Maßnahmen dApp-Entwicklungsteams ergreifen können, um Sicherheitsrisiken zu minimieren und die in ihren Code und ihre Architektur eingebauten Schutzmechanismen zu erhöhen, merkt Tim an, dass eine gängige Taktik von Hackern darin besteht, Bibliotheken mit schädlichem Code zu injizieren. Wenn Entwickler anschließend kompromittierte Bibliothekskomponenten in einer dApp verwenden, öffnet sich für Hacker eine Hintertür, die sie ausnutzen können.
Um dieses Risiko zu minimieren, rät er:
- Die Verwendung der beliebtesten Open-Source-Bibliotheken wie React, die über die Ressourcen verfügen, um die sichersten Ökosysteme zu gewährleisten, ist eine grundlegende Voraussetzung.
- Die Begrenzung der Anzahl der Bibliotheken ist ein weiterer wichtiger Ratschlag, „denn jede Bibliothek bietet einen neuen Angriffspunkt. Ihre Anzahl zu minimieren bedeutet, die Fronten zu minimieren, die verteidigt werden müssen“.
- Bibliotheken und Software mit den neuesten Patches und Fehlerbehebungen auf dem neuesten Stand zu halten.
Er betont auch, dass die „Leute“, die an einem Softwareentwicklungsprojekt beteiligt sind, unabhängig davon, ob es sich um Web2 oder Web3 handelt, das größte Sicherheitsrisiko darstellen. Vor diesem Hintergrund ist es wichtig, klare Sicherheitsrichtlinien und Sicherheitsnetze festzulegen, die die häufigsten Fälle von menschlichem Versagen abdecken.
Die gute Nachricht gemäß Tim ist jedoch, dass dApp-Angriffe „nicht so häufig“ vorkommen, da Hacker in der Regel zuerst auf Smart Contracts abzielen. Ein anderer Ansatz von Hacker-Angriffen besteht darin, die Nutzung einer dApp zu blockieren und ein Lösegeld für ihre Freigabe zu verlangen.
Die Bereitstellung über Content Delivery Networks (CDNs) und die Sicherstellung, dass alle Ports, die für Dienste im Backend verwendet werden, gesichert sind, sowie das Whitelisting von Domains sind Maßnahmen, die Tim vorschlägt, um diese Risiken zu minimieren.
Die Besetzung von Blockchain-Entwicklungsteams nur mit Full-Stack-Entwicklern erhöht die Effizienz
Tim empfiehlt, Entwicklungsteams zusammenzustellen, die ausschließlich aus Full-Stack-Entwicklern bestehen, die in der Lage sind, im Front- und Back-End eines dApp-Projekts zu arbeiten. Auf die Frage, warum er Full-Stack-Fähigkeiten bei allen Teammitgliedern im Web3-Kontext für besonders wichtig hält, antwortet er, dass dApps in der Regel die Entwicklung eines Frontends, eines SDK (Software Development Kit) und eines separaten Backends „zur Indexierung von Blockchain-Transaktionen“ beinhalten.
Das dApp-Frontend und das SDK sollten in derselben für den Browser zugänglichen Sprache geschrieben sein, normalerweise TypeScript oder JavaScript. Und Backends, die Blockchain-Transaktionen indizieren, verwenden Subgraphen, die in AssemblyScript geschrieben sind, „was im Grunde genommen JavaScript ist – nur eine Variation wie TypeScript“.
Das bedeutet, dass fast alle Werkzeuge und Technologien, die bei der dApp-Entwicklung zum Einsatz kommen, „eng mit JavaScript verbunden“ sind.
Diese JavaScript-zentrierte Qualität der Web3-Entwicklung eignet sich für die Full-Stack-Entwicklung und reduziert den Bedarf an verschiedenen Tech-Stacks.
Ein weiterer Vorteil von Full-Stack-Teams ist, dass sie im Bereich der Blockchain-Entwicklung normalerweise relativ klein sind. Die Tatsache, dass es sich um ein Full-Stack-Team handelt, trägt dazu bei, dass das Team schneller und effektiver miteinander kommunizieren kann und die Ressourcen flexibel dem Backlog zugewiesen werden können – so wird vermieden, dass es zu Engpässen kommt, weil nur ein oder zwei Personen bestimmte Aufgaben übernehmen können.
Blockchain-betriebene dApps haben auch kein „klassisches Backend“, da die Blockchain und Smart Contracts die Rolle der Backend-Schicht übernehmen – oder zumindest einen Großteil davon. Das bedeutet, dass der für das Frontend und SDK geschriebene Code mit der Blockchain interagieren muss und komplexe Logik und Datenaggregation beinhaltet.
Tim weist darauf hin, dass eine kompetente, effiziente Frontend-Entwicklung von dApps ein Full-Stack-Profil erfordert, da das Frontend mehr von der schweren Arbeit übernimmt als bei der herkömmlichen Web-Entwicklung, die so viel wie möglich an das Backend überträgt.
dApp UI-Tests dauern länger, da es mehr Grenzfälle gibt
Tim sagt, dass umfassende UI-Tests für dApps auch ein längerer, komplexerer Prozess sind, da es im Vergleich zu Web2-Apps eine größere Anzahl von typischen Grenzfällen gibt.
Auf die Frage, warum das so ist, erklärt er, dass Smart Contracts nicht für einen einzigen Anwendungsfall geschrieben werden. Vielmehr funktionieren Smart Contracts wie öffentliche APIs, die von vielen unabhängigen dApps als Teil der Smart-Contract-Chains verwendet werden können, die ihre Funktionalitäten ermöglichen.
Infolgedessen sind Smart Contracts sehr allgemein gehalten, was das Risiko unerwarteter Ergebnisse in Grenzsituationen erhöht.
Die Zukunft der Web3- und dApp-Entwicklung – voraussichtliche Trends
Welche Entwicklungen und Trends erwartet Tim im Bereich der Web3-Entwicklung in den nächsten Jahren? Wird sich das Ökosystem so entwickeln, dass der Lebenszyklus der Blockchain-Entwicklung verkürzt wird und die Kosten für die dApp-Entwicklung gesenkt werden können?
Mit einem Wort: Ja.
Null-Wissen-Beweise (Zero-Knowledge-Proofs) werden die Einschränkungen im Nutzererlebnis für dApps reduzieren
Tim geht davon aus, dass die Einführung von verbesserten Null-Wissen-Beweise-Protokollen in zukünftigen Generationen von dApps einen großen Beitrag dazu leisten wird, einige der häufigen Einschränkungen der Web3-Nutzererfahrung zu reduzieren.
Ethereum.org beschreibt Null-Wissen-Beweise als:
„Ein Null-Wissen-Beweis ist eine Methode, mit der eine Partei (der Beweisanführer) einer anderen Partei (dem Verifizierer) die Gültigkeit einer Aussage beweisen kann, ohne irgendwelche Informationen außer der Tatsache, dass diese spezifische Aussage wahr ist, preiszugeben.“
Mit einem Null-Wissen-Protokoll könnte beispielsweise überprüft werden, ob ein Kreditantragsteller die Qualifikationskriterien erfüllt, ohne dass der Kreditgeber weitere Angaben zu dessen Finanzen erhält.
Oder überprüfen, ob jemand über achtzehn Jahre alt ist, ohne dass die Behörde, die das Mindestalter überprüft, genauere Daten erhält oder darauf zugreifen kann.
Null-Wissen-Beweise basieren auf komplexer kryptografischer Mathematik und sind nicht zwangsläufig mit der Blockchain-Technologie verbunden – obwohl sie für L2-Skalierungslösungen von zentraler Bedeutung sind. Wie von Ethereum.org erklärt:
„Null-Wissen-Rollups (ZK-Rollups) sind Layer-2-Skalierungslösungen, die den Durchsatz im Ethereum-Mainnet erhöhen, indem sie Berechnungen und State-Storage außerhalb der Chain verlagern. ZK-Rollups können Tausende von Transaktionen in einem Stapel verarbeiten und dann nur einige minimale zusammenfassende Daten an das Mainnet senden. Diese zusammenfassenden Daten definieren die Änderungen, die am Ethereum-Status vorgenommen werden sollten, sowie einen kryptografischen Beweis, dass diese Änderungen korrekt sind.“
Tim glaubt, dass die Technologie in 5 bis 10 Jahren weit verbreitet sein und die derzeitigen Identitätsüberprüfungsmechanismen wie die 2-Faktor-Authentifizierung ersetzen wird. Sie wird, so Tim, auch als Mittel für Strafverfolgungsbehörden und andere Regierungsstellen dienen, um benötigte Informationen auf eine Art und Weise zu überprüfen, die die Privatsphäre des Einzelnen besser respektiert.
Im Web3-Kontext werden Null-Wissen-Beweise es dApp-Nutzern ermöglichen, Kryptowährungstransaktionen viel bequemer und sicherer durchzuführen. Derzeit müssen die Nutzer ihre privaten Krypto-Wallet-Schlüssel angeben, um Transaktionen zu autorisieren. Das ist sowohl in Bezug auf die Benutzerfreundlichkeit oft ungeschickt als auch ein Sicherheitsrisiko.
Stattdessen, so Tim, werden Null-Wissen-Beweise verwendet, um zu beweisen, dass der Nutzer auf bestimmte Informationen, wie z. B. einen privaten Zugangsschlüssel, zugreifen kann, ohne den Schlüssel selbst preiszugeben.
Weitere Möglichkeiten, wie Null-Wissen-Beweise dazu beitragen können, verschiedene Einschränkungen im Nutzererlebnis in dApps zu beseitigen, sind die Zugangskontrolle und die Art der Identitätsüberprüfung ohne Preisgabe persönlicher Daten, die besonders im Gesundheits- und Finanzwesen sowie bei Behörden nützlich wäre.
Programmiersprachen für Smart Contracts
Tim hebt die wachsende Beliebtheit der Programmiersprache Rust für das Schreiben von Smart Contracts und auch auf Systemebene hervor. Die meisten Blockchains selbst sind in Go(lang) geschrieben und er erwartet, dass dies so bleiben wird, obwohl Rust inzwischen auch als Alternative verwendet wird.
Tim glaubt, dass Solidity auch in Zukunft die am häufigsten verwendete Sprache für die Erstellung von Smart Contracts sein wird. Die Tatsache, dass sie viele Gemeinsamkeiten mit JavaScript und TypeScript aufweist, macht sie für Entwickler mit vorhandenen Kenntnissen in diesen Sprachen relativ zugänglich. Außerdem, so Tim, profitiert sie von dem am weitesten entwickelten Ökosystem.
Er sagt, dass, wenn eine dApp auf der Ethereum-Blockchain oder einer EVM (Ethereum Virtual Machine)-kompatiblen Blockchain wie Polygon oder BNB Chain entwickelt wird, die Wahl der Sprache für Smart Contracts Solidity sein wird – es sei denn, es gibt einen klaren Grund für eine alternative Wahl.
Wenn eine dApp auf Solana entwickelt wird, müssen die Smart Contracts in Rust geschrieben werden, da dies die einzige Sprache ist, die die Blockchain unterstützt. Allerdings hat die Blockchain nun ein Tool entwickelt, um in Solidity geschriebene Smart Contracts in Solana-kompatiblen Bytecode zu konvertieren.
Er erwartet, dass in den kommenden Jahren mehr und bessere Tools zur Konvertierung von in einer Sprache geschriebenen Smart Contracts in andere Sprachen für andere Blockchains ein Trend im Web3-Entwicklungsökosystem werden.
Tim erwähnt auch, dass er erwartet, dass in Zukunft mehr Smart Contracts auf der Bitcoin-Blockchain über L2-Layers wie Stacks geschrieben werden. Bitcoin-gehostete Smart Contracts wurden vor ein paar Jahren mit viel Hype und einer Menge Investitionen möglich, aber das Interesse ist seitdem abgeflaut, so Tim.
Wenn Bitcoin in einen neuen Bullenmarkt eintritt, was seiner Meinung nach im nächsten Jahr der Fall sein könnte, erwartet Tim eine neue Welle des Interesses an Bitcoin-Smart-Contract-gestützten dApps.
Tim hält Rust persönlich für eine bessere Sprache zur Programmierung von Smart Contracts als Solidity. Auch wenn letztere speziell für die Programmierung von Smart Contracts entwickelt wurde, ist sie seiner Meinung nach „keine gute Sprache für Smart Contracts“.
Er erklärt dies damit, dass Solidity „einige recht merkwürdige Lösungen im Kontext einer Umgebung darstellt, die ein hohes Maß an Sicherheit bieten muss“.
Obwohl Rust als Sprache auf Systemebene und nicht als Smart-Contract-Sprache entwickelt wurde, bietet es Programmierern einen Low-Level-Zugriff und eine „unglaubliche Leistung“ und ist dank ausgefeilter Typisierungs- und Speichersicherheit sehr sicher. Das erhöht die Sicherheit zusätzlich, denn es bedeutet, dass falsch geschriebener Code nicht kompiliert werden und funktionieren kann. Und wenn er doch funktioniert, bedeutet das an sich, dass er sauber ist.
Rust, so Tim, „erlegt dem Programmierer Disziplin auf“.
Trotzdem glaubt er, dass Solidity aufgrund seines schnell wachsenden Ökosystems weiter an Popularität gewinnen wird. Aus demselben Grund würde er sich auch bei den meisten dApp-Projekten für Solidity entscheiden, selbst wenn die Sicherheit eine Priorität wäre. Er würde diesen Nachteil dadurch ausgleichen, dass er erhebliche Ressourcen in die Erstellung umfassender Testsuiten investiert, um die Sicherheit von Smart Contracts zu gewährleisten.
Außerdem müssen in Rust programmierte Smart Contracts immer noch auf ihre Funktionalität getestet werden, auch wenn sie aufgrund der Eigenschaften der Sprache an sich technisch korrekt kodiert sind. Und die Einrichtung von Tests für Smart Contracts, die auf Solidity basieren, ist viel einfacher.
Er glaubt, dass sich das Ökosystem und die Werkzeuge für die Verwendung von Rust im Kontext der dApp-Entwicklung ebenfalls verbessern werden, vergleicht aber die Dynamik von Solidity mit der von JavaScript in der herkömmlichen Webentwicklung – er glaubt, dass die Tatsache, dass es so viel einfacher zu lesen ist als das komplexere Rust, die Einstiegshürde niedriger macht. Und das wird bedeuten, dass es weiterhin dominieren wird, trotz (wie auch JavaScript nach seiner Meinung) einigen der technischen Mängel, die er sieht.
In dem Maße, wie sich das Rust-Ökosystem verbessert, könnte es die beliebteste Sprache für die Programmierung von Smart Contracts im Kontext von dApps werden, bei denen Sicherheit eine Priorität ist – die höheren Einstiegshürden würden durch die bessere Sicherheit, die sie bietet, ausgeglichen.
Das sich entwickelnde Dev-Ökosystem wird den Lebenszyklus der dApp-Entwicklung erheblich verkürzen
Tim erwartet, dass die rasche Entwicklung des Dev-Tooling-Ökosystems rund um die dApp-Entwicklung und die größere Verfügbarkeit von Vorlagen, die lediglich angepasst oder erweitert werden müssen, den Zeitaufwand für viele Aufgaben in den kommenden Jahren drastisch reduzieren wird.
Er erwartet auch, dass sich der Blockchain-Entwicklungssektor stärker auf Chain-übergreifende Lösungen und L2-Lösungen für die Skalierbarkeitsprobleme konzentrieren wird, mit denen dApps, die auf einen großen Markt abzielen, zu kämpfen haben.
Die gute Nachricht ist jedoch, dass sich der Lebenszyklus der dApp-Entwicklung verkürzen wird und damit die Kosten sinken werden.
Tim Reznichenko – leitender Web3-Entwickler
Tim Reznichenko ist ein erfahrener Full-Stack-Ingenieur und Teamleiter mit über 8 Jahren Erfahrung in der Durchführung von Projekten für US-amerikanische und europäische Kunden in verschiedenen Bereichen wie Blockchain, AdTech, EduTech, LMS, CRM, SaaS, ERP, TMS und Bestandsmanagement.
Er hat Teams von bis zu 20 Mitarbeitern geleitet und seine eigene dezentralisierte Kryptobörse und Mikro-Lernplattform ins Leben gerufen.
