Polkadot Deployment Portal: Warum sollten Projekte sich für eine Deployment auf Polkadot entscheiden, anstatt ein L2 zu werden?

Früher war das Deployment eines Rollups auf Polkadot nie eine einfache Angelegenheit. Denn je flexibler ein System ist, desto komplexer ist in der Regel auch der Deployment-Prozess: Von SDK-Updates über Slot-Auktionen bis hin zu Governance und Runtime-Upgrades – jeder Schritt konnte für Teams zur Herausforderung werden.

Um diesen Zustand zu ändern, hat Parity dieses Jahr das Polkadot Deployment Portal (PDP) eingeführt – einen „One-Stop-Shop“ für Build, Deployment und Integration. Das Ziel ist klar: Die Einstiegshürden senken, Prozesse vereinfachen und es jedem Team ermöglichen, schnell und stabil ein eigenes Rollup auf Polkadot zu starten und zu betreiben.

In diesem Artikel führt uns Santi Balaguer, Head of Product Development bei Parity, durch die Entwicklung der Deployment-Erfahrung auf Polkadot in den letzten Jahren, erläutert die Designprinzipien hinter dem PDP und teilt, wie dieses Tool Schritt für Schritt die Art und Weise verändert, wie Rollups gestartet werden.

Deployment-Erfahrung auf Polkadot: Je flexibler das System, desto komplexer

Jay: Willkommen bei Space Monkeys! Heute haben wir Santi Balaguer eingeladen, der bei Parity für die Produktentwicklung verantwortlich ist. Heute sprechen wir über PDP. Wofür steht PDP eigentlich?

Santi: Das steht für Polkadot Deployment Portal – das Polkadot Deployment-Portal.

Jay: Was waren in den letzten vier, fünf Jahren deine Hauptaufgaben bei Parity, bevor du mit PDP angefangen hast?

Santi: Ich war immer sehr eng mit der Entwickler-Community verbunden, hauptsächlich um ihnen zu helfen, Parachains und Rollups auf Polkadot zu starten. Wie du sagst, ich war schon bei Parity, bevor die Parachains überhaupt live gingen.

Jay: Welche der Projekte, mit denen du häufig zu tun hattest, sind uns besonders bekannt?

Santi: Ich war früher für das Substrate Builders-Programm verantwortlich, darin sind viele bekannte Projekte. Besonders in Erinnerung geblieben ist mir das Hydration-Team. Ich erinnere mich noch, wie Jakub bei einer Präsentation ihre Omnipool-Idee und die Probleme, die Hydration lösen will, vorgestellt hat. Er zeigte ein legendäres Meme „money printer goes brrrr“, um zu erklären, warum sie eine neue Lösung vorschlagen. Bis heute mache ich mit Jakub darüber Witze.

Jay: Haha, großartig. Du hast sicher viele Projekte gesehen, die auf Polkadot erfolgreich umgesetzt wurden, aber bestimmt auch viele ihrer Schmerzpunkte gehört. Was waren in den letzten Jahren die größten Kopfschmerzen beim Deployment auf Polkadot?

Santi: Natürlich. Polkadot ist ein sehr komplexes System, man muss es wirklich verstehen, damit ein Projekt reibungslos läuft. Diese Komplexität kommt eigentlich von der Flexibilität – je flexibler das System, desto komplexer ist es auch.

In der Anfangszeit musste man sich zunächst mit den zahlreichen „breaking updates“ des SDK auseinandersetzen. Damals gab es noch kein Polkadot SDK, nur Substrate, das war noch ganz anders als heute. Nachdem man die Entwicklungsumgebung eingerichtet hatte, musste man in der Community Stimmen sammeln und an der Slot-Auktion teilnehmen. Die Auktion selbst war auch eine Herausforderung, man brauchte genügend Unterstützer, und das Ergebnis stand erst in letzter Minute fest. Selbst wenn man gewonnen hatte, musste man noch drei Monate warten, bis die Parachain wirklich live ging. Und der Slot wurde nur für zwei Jahre vermietet. Damals musste man also sowohl technisch als auch in der Community alles geben, um sich auf Polkadot zu etablieren.

Jay: Ja, stimmt. In den letzten Jahren hat sich die Erfahrung aber deutlich verbessert. Kannst du etwas über diesen Wandel erzählen?

Santi: Natürlich. Ich finde, Parity hat große Anstrengungen unternommen, insbesondere um disruptive Updates beim Polkadot SDK zu reduzieren.

Obwohl es immer noch Updates gibt, ist es jetzt viel stabiler als früher und die Kompatibilität zwischen den Versionen ist viel besser. Entwickler können sich jetzt viel mehr auf die SDK-Version verlassen, die sie nutzen. Manche Parachains laufen sogar noch auf alten Substrate-Versionen, funktionieren aber trotzdem problemlos auf Polkadot.

Außerdem wurde Cortime eingeführt (auch wenn es selbst eine gewisse Komplexität mitbringt), aber es hat die Einstiegshürde für Entwickler deutlich gesenkt. Es macht es viel einfacher, Polkadot auszuprobieren, und hat die Barrieren für den Einstieg stark reduziert. Ich finde, wir sollten das so gut wie möglich nutzen.

Warum sollten Projekte heute auf Polkadot deployen und nicht als Ethereum L2?

Jay: Obwohl es damals viele Herausforderungen gab, sind heute viele davon gelöst. Warum sollte ein Projekt heute auf Polkadot deployen? Warum nicht als Ethereum L2 oder gleich eine eigene L1 starten? Was sind die Gründe?

Santi: Das ist eine sehr interessante Frage. Ich finde, wir als Community sollten hier noch mehr kommunizieren und aufklären. Meiner persönlichen Meinung nach ist Polkadot die einzige Blockchain, die von Anfang an dafür konzipiert wurde, Rollups nativ zu unterstützen. Es bietet Entwicklern viele Infrastrukturen, die es anderswo nicht gibt.

• Zum Beispiel bietet Polkadot eine sehr große Data Availability-Schicht für Rollups, während man auf Ethereum L2 auf externe Systeme oder „Blobs“ angewiesen ist.

• Oder die native Nachrichtenübermittlung zwischen Parachains (Cross-Chain Communication), die es bei anderen Rollups nicht gibt. Fehlt diese Funktion, leidet die Sicherheit des Systems.

• Auch bei der Performance: Spamming hat bereits gezeigt, dass die TPS-Werte der Polkadot-Rollups branchenweit herausragend sind.

• Und was die elastische Skalierung angeht: Polkadot ist derzeit das einzige System, das die Infrastruktur je nach Bedarf jederzeit erweitern oder verkleinern kann. Ein Beispiel: Wenn Mythical plötzlich ein neues Spiel launcht und in der ersten Woche mit einem zehnfachen Nutzeranstieg rechnet, können sie das fast ohne Änderungen sofort unterstützen.

Ich denke, wir haben in der Vergangenheit bei der Diskussion über „Parachains und Rollups“ verpasst, Polkadot ins Rampenlicht zu stellen. Aber es ist noch nicht zu spät, wir haben immer noch die Chance, es wieder ins Zentrum zu rücken.

Jay: Ja, du hast mir schon mal gesagt, dass Polkadot von der Architektur her von Anfang an für Rollups gedacht war. Wir haben es nur damals nicht so genannt.

Santi: Genau. Und noch etwas, das wir oft übersehen: Shared Security. Wenn man sich die Entwicklung der Blockchain anschaut: Erst kam Bitcoin, dann Ethereum. Später haben viele neue „Ethereums“ behauptet, ihre Chain sei besser, weil sie A, B, C Features hat. Das Problem ist aber, die Sicherheit einer neuen Chain zu gewährleisten, ist extrem schwierig. Man braucht eine ausreichend große und starke Validatorenmenge – das ist nicht einfach.

Damals dachte Gavin: Warum biete ich Sicherheit nicht als Service an, direkt in der Basisschicht? Das ist das Besondere an Polkadot. Es bietet nicht nur Shared Security, sondern ermöglicht auch effiziente Kommunikation zwischen diesen Rollups – darin ist Polkadot besonders stark.

Wie entstand die Idee zum PDP?

Jay: Großartig. Wenn ein Rollup native Data Availability in großem Maßstab will, ohne auf andere Projekte angewiesen zu sein, dazu hohe TPS und Durchsatz sowie nahtlose Kommunikation mit anderen Rollups, dann ist Polkadot wirklich attraktiv. Aber vor PDP war das Deployment einer Parachain immer noch sehr komplex und zeitaufwendig. Wie entstand die Idee für das PDP?

Santi: Die Idee gibt es schon eine Weile, auch wenn wir erst letzten November wirklich damit angefangen haben.

Unser Team arbeitet seit etwa März/April dieses Jahres Vollzeit an dem Projekt, und wir machen schnelle Fortschritte. Die Idee gibt es schon länger, und es gibt auch schon ähnliche Lösungen in der Branche. Im Ethereum-Ökosystem gibt es zum Beispiel Conduit und Gelato; auf Polkadot gab es Tanssi, aber die sind inzwischen auch hauptsächlich zu Ethereum gewechselt, mit ähnlichem Ansatz.

Wir haben gesehen, dass es auf Polkadot noch keine Umsetzung gab, also haben wir beschlossen, es selbst in die Hand zu nehmen, um sicherzustellen, dass es klappt. Schließlich verstehen wir Polkadot am besten und wissen, wie wir es Entwicklern leichter machen können, Projekte zu deployen – das ist das Ziel von PDP.

Wir treffen keine Entscheidungen für Entwickler, sondern bieten Guidance und Auswahl

Jay: Für wen ist das PDP eigentlich gedacht? Ich erinnere mich, dass es bei Polkadot früher das Problem gab, dass manche Projekte gleich ein Rollup machen wollten, obwohl ein Smart Contract gereicht hätte. Für welche Projekte ist ein eigenes Rollup wirklich sinnvoll?

Santi: Das ist eine gute Frage, aber ich glaube, es gibt keine feste Antwort. Auch heute sehen wir noch Projekte, bei denen ein Contract auch Sinn machen würde. Aber manchmal brauchen Teams Unabhängigkeit, sie wollen nicht von der Infrastruktur anderer Chains abhängig sein; manchmal erwarten sie in Zukunft sehr hohen Durchsatz und entscheiden sich deshalb gleich für ein Rollup. Solche Gründe führen dazu, dass sie eine eigene Chain oder mehr Unabhängigkeit auf der Infrastruktur-Ebene brauchen.

Ein weiteres Beispiel ist Hydrations Omnipool – man könnte diskutieren, ob das nicht auch ein Contract sein könnte, aber ich finde, als eigene Chain ist das sinnvoll. Auf der anderen Seite: Uniswap auf Ethereum war anfangs ein Contract, später haben sie eine eigene Chain gemacht – brauchen sie die wirklich? Vielleicht nicht, aber sie haben ihre eigenen geschäftlichen Überlegungen.

Es gibt also kein Absolut, es ist immer ein Zusammenspiel aus Technik und Business. Für mich ist das Wichtigste: Wir treffen keine Entscheidungen für Entwickler, sondern bieten Guidance, damit sie selbst wählen können. Egal ob Rollup oder Contract – sie sollten es einfach ausprobieren und experimentieren können.

PDP Full-Process Experience: Von Build über Deployment bis Access – so einfach ist der Rollup-Start

Jay: Angenommen, ein Team hat sich entschieden – egal ob selbst oder durch Guidance von Magenta Labs oder dem BD-Team – und will ein Rollup auf Polkadot deployen. Was erwartet sie im PDP? Wie läuft der Deployment-Prozess heute ab?

Santi: Im PDP haben wir den Prozess in drei Hauptphasen unterteilt: Build – Deploy – Access, die alle miteinander verbunden sind.

In der „Build“-Phase ist die Kernfrage: „Wie fange ich an?“ Unsere Idee ist: Der beste Weg ist über Runtime-Templates. OpenZeppelin entwickelt derzeit entsprechende Templates, das Pop CLI-Team und das ROG-Team arbeiten ebenfalls daran. Pop CLI ist im Grunde ein Tool, das du auf deinem Rechner nutzen kannst, um Rollups zu schreiben. Wir arbeiten mit ihnen zusammen, um es mit den anderen beiden PDP-Phasen (Deployment und Access) zu verbinden.

Wenn du zum Beispiel ein Rollup mit Pop CLI gebaut hast, kannst du es direkt damit ans PDP anbinden und deployen – genau so haben wir es designt und umgesetzt. Entwickler können also den gesamten Prozess per CLI durchlaufen, ähnlich wie bei Heroku oder Vercel in Web2, die auch eigene CLIs haben. Wer das bevorzugt, kann CLI nutzen; natürlich geht auch alles über die grafische Oberfläche. Beides ist möglich.

Jay: Das heißt, man kann nicht nur mit Templates bauen, sondern auch mit Pop CLI und dann deployen. Trifft PDP für Entwickler irgendwelche Entscheidungen oder ist es nur ein Tool, das die Teams selbst bedienen müssen?

Santi: Beides. Wir wollen, dass PDP ein Self-Service-Tool ist, das Entwickler selbst nutzen können. Wenn es aber kritische Probleme gibt, unterstützen wir natürlich und sorgen dafür, dass sie die nötige Hilfe bekommen. Aber wenn jemand einfach selbst ausprobieren will, ist das auch völlig okay, haha.

Jay: Klingt spannend. Kannst du ein paar konkrete Template-Beispiele nennen? Welche gefallen dir besonders?

Santi: Zum Beispiel hat das ROG-Team ein fertiges Pilot Revive-Template, mit dem du direkt starten kannst. OpenZeppelin hat das Frontier-Template – wenn du eine Chain mit EVM-Funktionalität starten willst, kannst du das direkt nutzen.

Jay: Cool, also verschiedene Optionen rund um Smart Contracts.

Santi: Genau. Es gibt auch Templates ohne Smart Contracts. Wenn jemand zum Beispiel nur eine Chain für die Verwahrung von Assets bauen will, insbesondere für Real World Assets (RWA), gibt es dafür passende Templates. Es gibt also zum Start viele Optionen, die du dann weiter ausbauen kannst.

Jay: Kann man bei den Templates eigene Pallets hinzufügen?

Santi: Am Anfang nicht. Die Idee ist, dass du mit einem Template startest, und wir dich dann Schritt für Schritt zu Runtime-Upgrades führen. So wollen wir Teams helfen, nach und nach Product-Market-Fit zu finden. Das ist ein spannendes Design und eines unserer aktuellen Kernfeatures. Wir nutzen gerade ein sehr interessantes Tool vom Puppet-Team, das deine geplanten Runtime-Upgrades mit der aktuellen Runtime vergleicht und einen Bericht erstellt, der zeigt, was sich geändert hat, was Entwickler beeinflussen könnte und worauf sie achten müssen.

Jay: Ja, ich habe gesehen, dass ihr das gerade integriert habt – großartig.

Santi: Genau, das haben wir diese Woche fertiggestellt. So bekommst du einen Bericht zum Runtime-Upgrade, der sicherstellt, dass das, was du deployen willst, auch deinen Erwartungen entspricht. Als nächstes wollen wir eine Funktion hinzufügen, die im Hintergrund ein paar Blöcke mit der neuen Runtime simuliert. Wenn alles passt, bekommst du ein „Go-Live“-Signal; wenn nicht, sagen wir dir, dass der Test fehlgeschlagen ist und du nochmal prüfen solltest. So vermeiden wir Fehler beim Upgrade. Einer der Vorteile von Polkadot ist die Unterstützung flexibler Runtime-Upgrades – Teams können das nutzen, um schnell zu iterieren und Product-Market-Fit zu finden.

Jay: Moment, zählt das schon zur „Deployment“-Phase? Ist das, was wir gerade besprochen haben, schon Deployment?

Santi: Ja, das überschneidet sich etwas. Man kann sagen: Build startet mit dem Template; Deployment betrifft die Infrastruktur darunter. Früher brauchte man ein eigenes DevOps-Team, um Collator-Nodes aufzusetzen und alles zu betreiben – das ist am Anfang jetzt nicht mehr nötig. Wenn das Projekt wächst und Ressourcen da sind, kann man ein eigenes Ops-Team aufbauen, und wir helfen dann beim Umzug. Aber zu Beginn übernehmen wir das für euch.

Jay: Wer macht das aktuell?

Santi: Im Moment stellt Parity das bereit. In Zukunft sollen Entwickler aber frei wählen können, auf welcher Cloud-Plattform sie deployen – vielleicht sogar bei einem IBP (Infrastructure Provider). Das zu abstrahieren dauert noch etwas, deshalb nutzen wir aktuell Paritys Infrastruktur, um die Erfahrung zu sichern. Später wird es mehr Auswahl geben.

Wir haben auch das Konzept der BDU (Basic Deployment Unit) eingeführt. Sobald du ein Rollup im Produktionsnetzwerk deployen willst, stellen wir dir eine standardisierte Infrastruktur bereit – mit drei Collator-Nodes, von denen einer als RPC-Endpunkt dient, und einem Indexer.

Wir arbeiten gerade mit Subscan zusammen, die eine Open-Source-Lösung haben, die wir ins PDP integrieren wollen. So bekommst du nicht nur einen Indexer, sondern auch einen Block Explorer – früher musste das jedes Team selbst aufsetzen, jetzt erledigen wir das alles aus einer Hand. Das ist ein tolles Design.

Jay: Wow, klingt super. Zählt das noch zu Build?

Santi: Das ist Deployment.

Jay: Verstanden. Ist das Rollup an diesem Punkt schon live? Werden schon Blöcke produziert? Kann das Team Runtime-Upgrades machen, um zu iterieren und Product-Market-Fit zu finden? Und dann kommt der letzte Schritt „Access“, richtig? Was ist das?

Santi: Genau! Access ist das Highlight von Polkadot – hier liegt der einzigartige Mehrwert für Rollup-Teams. Build und Deployment – also Runtime und Infrastruktur – kann man sich noch relativ schnell aneignen, aber beim echten Nutzen der Polkadot-Features wird der Unterschied deutlich. Zum Beispiel Coretime – das ist Teil von Access. PDP kauft Coretime im Voraus, sodass Entwickler beim Rollup-Deployment sofort loslegen können, ohne 28 Tage warten zu müssen, bis die Blockproduktion startet. Das ist ein riesiger Vorteil für die User Experience.

Jay: Muss ich als Deploying-Team Coretime selbst im PDP kaufen?

Santi: Wir kaufen das für dich und berechnen dir dann die Kosten. Tatsächlich bieten wir verschiedene Optionen für Coretime an. Wenn du gleich voll einsteigen willst, kannst du einen kompletten Core nutzen. Wir bieten aber auch „geslicete Cores“ an, also nur einen Teil eines Cores – wenn du erst mal testen willst, nicht viel Geld ausgeben willst und schauen möchtest, wie es läuft, kannst du nur einen kleinen Teil nutzen.

Jay: Ist dieses Feature schon verfügbar?

Santi: Im PDP ist es bereits nutzbar. Es läuft aktuell auf den Netzwerken Westend und Paseo. Paseo hat gerade die gesliceten Cores eingeführt, und auf Westend kannst du direkt einen Teil eines Cores handeln. Der Nachteil ist, dass deine Blockzeit länger wird, aber der Vorteil ist, dass die Einstiegshürde extrem niedrig ist – du kannst also sehr günstig testen. Wenn es gut läuft, kannst du auf einen vollen Core upgraden und bekommst sechs Sekunden Blockzeit – und das alles im PDP. Die Anbindung an Polkadot muss aber noch effizienter werden. Der Polkadot Hub als zentrales Feature steht kurz vor dem Launch, wir sind sehr gespannt darauf.