Gavins erste Entscheidung nach seiner Rückkehr: Parity wird nicht mehr nur an der Basis arbeiten, sondern auch Produkte entwickeln!

In den letzten zwei Jahren stand Polkadot vor einem grundlegenden Dilemma: Die Blockchain-Technologie ist weltweit führend, aber tatsächlich funktionierende Anwendungen sind äußerst rar.

DeFi funktioniert, aber andere Web3-Anwendungsfälle stagnieren nahezu. Externe Entwickler haben nicht wie erwartet „auf Polkadot Anwendungen gebaut“, das Ökosystem stößt an Expansionsgrenzen.

Als Gavin dann zu Parity zurückkehrte und wieder die Richtung vorgab, wurde eines so klar wie nie zuvor – wenn niemand Web3-Anwendungen baut, dann muss Parity eben selbst damit anfangen.

Das ist nicht einfach nur „ein paar Demos machen“. Es ist eine strategische Neuausrichtung – weg von „Parity baut die Infrastruktur, die Anwendungen kommen aus dem Ökosystem“ hin zu „Parity entwickelt selbst Prototypen von Anwendungen, die Web2 wirklich ersetzen können, und beweist damit den Wert der Polkadot-Technologie“.

In diesem ausführlichen Interview der Reihe „Space Monkeys“ erklärt Vice President Engineering Pierre erstmals systematisch:

• Warum das Modell mit externen Entwicklern gescheitert ist 
• Warum man wieder eigene Produkte entwickelt 
• Warum Polkadot Hub unbedingt „erst EVM, dann PVM“ braucht 
• Warum Gavin auf „zweiwöchige Iterationen“ drängt 
• Warum Polkadot gerade den gesamten Anwendungsstack für dezentrale Berechnung, Speicherung, Benachrichtigung und Identität neu aufbaut 

Man erkennt klar, dass Parity gerade eine „dezentrale AWS + Web2-Ersatzschicht“ baut. Das wird darüber entscheiden, ob Polkadot in der zweiten Ära wieder an die Spitze zurückkehrt.

Warum baut Parity jetzt selbst Anwendungen?

Jay: Willkommen zur neuesten Ausgabe von „Space Monkeys“! Unser heutiger Gast ist Pierre Aubert, Vice President Engineering bei Parity. Es ist ein Glück, ihn wieder begrüßen zu dürfen – seit seinem letzten Besuch ist einige Zeit vergangen. Damals war er noch nicht lange bei Parity. Heute sprechen wir über seine Erfahrungen, Beobachtungen und die zukünftige Richtung. Willkommen zurück, Pierre!

Pierre: Danke, hallo zusammen!

Jay: Du hast früher bei Google gearbeitet und dich schon damals mit Web3-Netzwerksystemen beschäftigt und überlegt, welche Rolle du darin spielen könntest. Was hast du inzwischen gelernt?

Pierre: Jetzt habe ich ein klareres Bild davon, wie das System funktioniert, und einige gute Ideen, was wir tun können. Das Potenzial ist riesig, es gibt viele Möglichkeiten, aber die Umsetzung ist nicht einfach.

Der aktuelle Stand von Web3 ist, dass außerhalb von DeFi (dezentrale Finanzen) die Fortschritte eher langsam sind. Kürzlich ist Gav zurückgekehrt und hat die Führung übernommen. Er hat entschieden, dass wir uns stärker auf Produkte konzentrieren – das halte ich für absolut richtig.

Vor zwei Jahren war unser Ansatz, dass Parity die Blockchain-Infrastruktur bereitstellt und die Anwendungen von externen Entwicklern gebaut werden. Aber das hat sich nicht wie erwartet entwickelt. Jetzt ist unsere Strategie, selbst Hand anzulegen und zunächst kleine Prototypen zu bauen, um zu zeigen, wie man dezentrale Systeme nutzen kann und dass diese Architektur tatsächlich zu brauchbaren Produkten führt.

Der erste Schritt ist also, dass wir diese Anwendungen selbst entwickeln und auch selbst nutzen – das sogenannte „dogfooding“ (eigene Produkte testen). Viele der ersten Anwendungen konzentrieren sich auf Tools, die wir täglich brauchen, mit dem Ziel, sie durch dezentrale Systeme zu ersetzen. Wenn diese Anwendungen intern ausgereift sind, bringen wir sie zu den Nutzern. Ein Beispiel: Beim Web3 Summit haben wir unsere eigene Technologie eigentlich gar nicht genutzt – die Tickets wurden über traditionelle Web2-Unternehmen verkauft, bezahlt wurde in Euro, das Zugangssystem war ebenfalls Web2. Das ist ein Szenario, in das wir einsteigen können – wir könnten mit unserer eigenen Technologie ein sichereres und offeneres System bauen.

Jay: Aber diese Systeme sind doch schon sehr effizient und stabil. Was bringt es, sie auf Web3 umzustellen?

Pierre: Wenn du meinst, dass zentrale Systeme ausreichen, ist das okay – gerade bei Tickets. Aber bei Zugangskontrolle sieht man die Vorteile der Dezentralisierung sehr deutlich. Zum Beispiel bekommst du im Hotel eine Zimmerkarte, aber viele Leute im Hotel können diese Karte kopieren und Fremde hereinlassen. Im Web3-System kannst nur du selbst ein exklusives Berechtigungszertifikat „minten“, die Sicherheit ist viel höher.

Es kommt also auf den Anwendungsfall an. In manchen Szenarien ist klar, warum Dezentralisierung besser ist. Ich persönlich mag die traditionellen Webdienste nicht: Alle sechs Monate wird einer gehackt, meine Daten werden geleakt – Adresse, Passwort, Bankdaten usw. Der Grund ist einfach: Diese Systeme sind nicht sicher genug.

Ich möchte, dass Polkadot „standardmäßig sicher“ ist: Die Daten gehören mir. Wenn ich ein Ticket kaufe, muss ich dir nicht meine Adresse geben. Ich kann einen Zero-Knowledge-Beweis liefern, dass ich irgendwo wohne, aber du erfährst meine Adresse nicht. Selbst wenn dein System gehackt wird, werden meine echten Daten nicht geleakt. Ich will nicht, dass meine persönlichen Daten überall gesammelt und geleakt werden – sei es aus Sicherheitsgründen oder einfach wegen der Privatsphäre. Selbst in ausgereiften Systemen kann Dezentralisierung sie besser und sicherer machen.

Wie steigert Parity die Effizienz?

Jay: Ihr habt in den letzten zwei Jahren viel Energie in den Aufbau dezentraler Systeme gesteckt. Seit du Vice President Engineering bist, was läuft bei Parity besonders gut?

Pierre: Eigentlich habe ich vor allem „Management-Basics“ gemacht, nichts Kompliziertes – einfach das Managementsystem geordnet. Das Ergebnis ist sehr gut, die Produktivität ist stark gestiegen. Es geht um grundlegende Dinge wie klare Prozesse. Gerade Ingenieure mögen eine strukturierte, regelbasierte Umgebung. Wenn Prozesse und Verantwortlichkeiten klar sind, entsteht automatisch Fairness. Wir befördern die, die wirklich gute Arbeit leisten, wer besser ist, bekommt mehr Gehalt – und das ist zuverlässig und transparent. Die Ingenieure schätzen diese Fairness: Wenn du mehr verdienst als ich, bist du auch besser. Das wird anerkannt, und ich mag diesen Ansatz auch – so sollte eine gesunde Organisation funktionieren.

Jay: Gibt es praktische Tipps für andere Teamleiter, auch für kleine Teams? Wie bewertet man Mitarbeiter, entscheidet über Beförderungen oder gibt Verantwortung ab? Worauf achtest du bei der Entwicklung von Mitarbeitern?

Pierre: Wir achten mehr auf Ergebnisse als auf Prozesse. Ein Beispiel: Manche arbeiten sehr hart und zeigen das auch, aber am Ende kommt nichts dabei heraus. Andere arbeiten clever, vielleicht nur 20 Stunden pro Woche, aber sie erledigen die Aufgaben und haben echten Impact. Das ist viel wertvoller. Kurz gesagt: Kluges Arbeiten ist wichtiger als hartes Arbeiten.

Jay: Gibt es Gemeinsamkeiten bei Mitarbeitern, die am Ende keine Ergebnisse liefern? Sie sind beschäftigt, aber produzieren nichts. Was fällt dir da auf?

Pierre: Meistens liegt es nicht an den Personen, sondern am Management. Oft wissen sie nicht genau, was ihr Ziel ist, was sie tun sollen. Diese „Unklarheit“ macht die Arbeit schwer. Gerade bei Parity sind die Leute sehr fähig – wenn jemand nichts schafft, liegt es meist an fehlender Richtung.

Deshalb ist es das Wichtigste, Ziele klar und eindeutig zu machen. Ein weiterer Punkt: Manchmal wissen Teammitglieder nicht, an wen sie sich wenden sollen, wenn sie ein Problem haben. Das war früher bei Parity ein Problem, jetzt haben wir das verbessert: Es ist klar, wer für was zuständig ist. Die verantwortliche Person muss entscheiden: „Gehen wir nach links oder rechts?“ Wenn das geklärt ist, läuft das Team reibungslos.

Jay: Ja, das kenne ich. Früher haben viele die Verantwortung abgeschoben: „Das muss jemand anders entscheiden, ich warte, bis sie entscheiden.“ So bleibt die Arbeit liegen.

Pierre: Genau, klare Verantwortung ist entscheidend. Und es ist eigentlich nicht schwer – oft reicht es, Dinge aufzuschreiben und klar zu kommunizieren. Ein weiteres Problem: Manche schreiben Erfolge sich selbst zu, aber bei Misserfolgen sind immer die anderen schuld. Das geht nicht. Man kann nicht den Erfolg für sich beanspruchen und das Scheitern anderen zuschieben.

Die Klarheit bringt also, dass die Organisation reibungsloser läuft. Es ändert nicht den Arbeitsalltag, aber langfristig wird das ganze Unternehmen effizienter.

Die Strategie von Polkadot Hub: Erst EVM, dann PVM

Jay: Lass uns über das Polkadot Hub Projekt sprechen. Ist das Projekt ein Erfolg oder ein Misserfolg?

Pierre: Ich würde sagen: Ja und nein. Aus Produktsicht ist es ein erfolgreiches Projekt, das Endergebnis ist gut.

Aber in der Arbeitsweise gibt es Verbesserungsbedarf. Ein Beispiel: Zu Beginn haben wir uns für PVM-Technologie entschieden, weil sie leistungsfähiger ist. Nach einem Jahr stellten wir fest, dass die meisten großen Ethereum-Smart-Contracts auf PVM gar nicht laufen – das hat uns überrascht. Das hätten wir früher testen müssen, aber wir haben die Komplexität des EVM-Ökosystems unterschätzt. Später haben wir gemerkt, dass wir EVM doch unterstützen müssen. Also haben wir EVM nachträglich integriert, was das Projekt komplexer gemacht hat.

Außerdem haben wir die Komplexität vieler Dinge im Ethereum-Ökosystem unterschätzt, wie Testframeworks (z.B. Anvil), Gas-Mapping usw. Die wichtigste Lehre: Vor Projektstart alles aufschreiben und durchdenken. Gerade bei komplexen Projekten reicht „fühlt sich einfach an“ nicht aus.

In der Kryptobranche sagen viele: „Egal, einfach machen!“ Immer wenn das jemand sagt, verlange ich ein Dokument. Viele scheinbar einfache Dinge sind in der Umsetzung gar nicht einfach, und Projekte dauern und kosten dann viel mehr als gedacht.

Insgesamt ist der Hub in Sachen Leistung und Qualität ein Erfolg, aber unsere Engineering-Praxis ist noch nicht ideal – die Entwicklungszeit war zu lang.

Jay: Verstehe. Hast du an der Umsetzung des Hub-Projekts mitgewirkt? Ich habe gehört, ihr versucht, andere Projekte zum Umzug zu bewegen.

Pierre: Ich war nicht der technische Leiter, aber ich habe das passende Team zusammengestellt und Qualitätsstandards definiert, um den stabilen Betrieb zu gewährleisten. Besonders zufrieden bin ich mit der Asset-Migration – da steckt viel professionelle Arbeit dahinter. Das zeigt, dass Parity jetzt in der Lage ist, große Migrationen durchzuführen, ohne die Nutzer zu beeinträchtigen. Das ist keine „Startup-Qualität“, sondern Engineering auf Konzernniveau. Es hat Zeit und Ressourcen gekostet, aber wir haben bewiesen: Wenn wir uns etwas vornehmen, erreichen wir ein sehr hohes Niveau. Das ist ein positives Signal für die Zukunft: Wenn wir diese Qualität in künftigen Projekten halten, wird die Technik kein Problem sein.

Jay: Unser Ziel mit diesem Ökosystem ist es, Projekten, die EVM oder Solidity-Smart-Contracts kennen, die Bereitstellung zu erleichtern. Welche Projekte werden in der Anfangsphase einziehen? Wie läuft die Bereitstellung ab – direkt auf EVM oder wird auf PVM migriert?

Pierre: Das kommt darauf an. Große Ethereum-Contracts haben eigentlich keinen Anreiz, auf PVM zu migrieren. Wir lassen sie also erst mal auf EVM deployen, das ist kompatibel und einfach.

Jay: Also die „Blue-Chip“-DeFi-Protokolle, richtig? Die sind ja auf allen großen Chains vertreten.

Pierre: Diese Projekte profitieren kaum von PVM-Performance, sie brauchen keine große Rechenleistung. Ihre Smart Contracts machen meist: Kontostand lesen → etwas Logik ausführen → Ergebnis zurückschreiben. Es gibt keine großen Berechnungen, der Flaschenhals ist das Lesen/Schreiben von Daten – da reicht EVM aus. PVM ist dann im Vorteil, wenn viele Berechnungen nötig sind, etwa Aufgaben, die heute off-chain erledigt werden müssen. Das ist das eigentliche Einsatzgebiet von PVM.

Jay: Was kann man damit konkret machen?

Pierre: Man kann zum Beispiel ZK-SNARKs on-chain berechnen. Auf PVM kann man vieles machen, was auf EVM nicht geht. Das ist gut für das Krypto-Ökosystem: Mehr Logik on-chain reduziert seltsame Off-Chain-Lösungen und die Abhängigkeit von Oracles.

Insgesamt ist es besser, mehr Logik on-chain zu bringen. Wenn die Krypto-Welt Web2 nachahmt, wird die CPU immer ausgelastet; sobald es mehr Rechenressourcen gibt, werden sie genutzt.

Jetzt haben wir mit Polkadot ein Berechnungssystem, bauen ein Speichersystem und ein Benachrichtigungssystem auf

Jay: Okay. Gavin hat bei Parity intern gesagt, sein Ideal sei ein zweiwöchiger Produkt-Iterationszyklus, um schnell viele Produkte zu entwickeln. Werden diese Produkte PVM und Hub nutzen oder auf anderen Stacks laufen?

Pierre: Das hängt vom Produkt ab, aber die meisten werden irgendeine Form von Smart Contract nutzen.

Jay: Die meisten Produkte werden also nicht gleich auf rollup + parachain setzen?

Pierre: Das kommt darauf an, es ist noch zu früh für ein Urteil. Speicher- oder Benachrichtigungsdienste werden wahrscheinlich eigene Parachains, aber Zugangskontrolle kann Smart Contracts gut abdecken.

Jay: Wie läuft das Speicherprojekt? Ich habe das Gefühl, wir haben schon viele Speicherlösungen ausprobiert, aber noch keine einheitliche Lösung.

Pierre: Speicher ist eine unserer komplexesten und wichtigsten Aufgaben: ein brauchbares dezentrales Speichersystem zu bauen. Schon die Definition von „brauchbar“ ist nicht einfach, das braucht mehrere Iterationen. Im Ökosystem arbeitet ein Team daran, Moonbeam macht auch etwas in diese Richtung.

Jay: Meinst du Dinge wie DataHaven?

Pierre: Ja, zum Beispiel DataHaven, auch Eiger (arbeitet an grundlegenden Primitiven). Parity entwickelt intern auch ein on-chain-Speicher; außerdem gibt es Projekte wie JamDA. Viele Teams arbeiten an dezentralem Speicher, mit unterschiedlichen Eigenschaften. Wir werden wahrscheinlich mehr als eine Speicherlösung brauchen: günstigen dezentralen Speicher (z.B. für Fotos, darf nicht zu teuer sein) und schnelleren Speicher für häufige Lese-/Schreibzugriffe, aber ohne riesige Datenmengen.

Es wird also wahrscheinlich mehrere Speicherlösungen geben oder eine Software, die in verschiedenen Modi konfigurierbar ist. Die Idee ist, JamDA als kurzfristigen/temporären Speicher zu nutzen: Daten sind temporär, z.B. nach 28 Tagen abgelaufen.

(JamDA-Schreibweise eventuell falsch, gerne korrigieren)

Jay: Außer du verlängerst aktiv?

Pierre: Genau, du kannst verlängern. Oder wir bauen auf JamDA ein großes, verteiltes dezentrales System, in dem du Daten langfristig speichern kannst. Wenn du z.B. eine Forschungsarbeit schreibst und sie dauerhaft öffentlich speichern willst, nutzt du langfristigen Speicher. Es könnte also ein Zwei-Phasen-System werden: temporär + langfristig.

Jay: Welche Eigenschaften hat dieses System, die IPFS nicht bietet?

Pierre: Zum Beispiel bietet IPFS keine Verfügbarkeitsgarantie. Du kannst ein Dokument hochladen, aber es ist nicht garantiert, dass du es später immer abrufen kannst.

Jay: Werden alle diese Lösungen letztlich durch die Sicherheit von Polkadot geschützt, also auf dem Sicherheitsmodell von Polkadot laufen?

Pierre: Am Ende ja, aber anfangs vielleicht nicht.

Jay: Was meinst du damit?

Pierre: Wir können zum Beispiel zunächst bestehende Systeme wie Filecoin nutzen, darauf eine Schicht aufsetzen und schauen, ob das reicht. Wenn unsere eigene Lösung reif ist, ersetzen wir Filecoin oder andere Lösungen schrittweise. Das ist noch nicht endgültig entschieden.

Der nächste Schritt ist, die on-chain-Funktionalität zu bauen, dann JamDA, dann nach und nach andere Lösungen integrieren – bis zur stabilen Gesamtlösung dauert es noch.

Speicherung ist anders als Berechnung: Wenn bei der Berechnung etwas schiefgeht, kann man sie wiederholen – das kennt jeder (z.B. Browser neu laden). Aber bei Speicherung ist es komplizierter: Wenn du ein verschlüsseltes Foto hochlädst, willst du es später garantiert wieder abrufen können – vielleicht nicht sofort, aber zu 100%. Die Erwartungen an Speicherung sind also höher als an Berechnung.

Jay: Ja. Wir kommen dem Ziel einer dezentralen „Cloud“ oder „Server-Infrastruktur“ immer näher, alle Komponenten werden nach und nach fertig.

Pierre: Genau, Schritt für Schritt. Wir bauen viele Dienste aus Web2 dezentral neu auf – mit anderen Eigenschaften, aber im Kern sind es ähnliche Systeme. Jetzt haben wir mit Polkadot ein Berechnungssystem, bauen ein Speichersystem und ein Benachrichtigungssystem auf.

Jay: Du hast gerade das „Benachrichtigungssystem“ erwähnt – was meinst du damit konkret?

Pierre: Zum Beispiel hast du eine Anwendung, und wenn dir jemand antwortet, ein Dokument kommentiert oder mit dir interagiert, brauchst du eine Benachrichtigung, richtig? Das ist das Benachrichtigungssystem. Das Problem ist: Im Internet sind wir meist hinter Firewalls, können uns also nicht direkt verbinden. Normalerweise läuft das über einen zentralen Server, der die Verbindung herstellt, damit wir dann Peer-to-Peer kommunizieren können.

Jay: So wie wenn wir einen privaten Chatraum erstellen.

Pierre: Genau. Wir wollen jetzt eine dezentrale Lösung bauen, die diesen zentralen Server ersetzt, aber die gleiche Kommunikationsfähigkeit bietet. Das System ist ähnlich, aber komplexer, weil wir zusätzliche Eigenschaften wollen: keine Abhängigkeit von zentralen Instanzen, keine nachvollziehbaren Metadaten. Beispiel: Bei Signal sieht niemand, was wir schreiben, aber dass „ich mit dir chatte“, ist bekannt. In unserem System soll nicht einmal nachweisbar sein, mit wem ich chatte.

Folge PolkaWorld auf WeChat – im nächsten Artikel teilen wir weitere Interviewinhalte mit Pierre!