Quelle / Source: Introducing Decentralized Pub/Sub Based on NKN
Was ist Pub/Sub?
Eine Grundfunktion des NKN-Clients (z.B. https://github.com/nknorg/nkn-client-js) ist die Bereitstellung eines dezentralen Nachrichtensystems, das Unicast, Multicast und Anycast umfasst. Das ist ziemlich ausreichend, wenn der Nachrichtensender weiĂ, wer die EmpfĂ€nger sind. In vielen gĂ€ngigen Szenarien sollte der EmpfĂ€nger jedoch logisch vom Sender entkoppelt sein. Wenn ich zum Beispiel eine Nachricht an einen Chatroom schicke, möchte ich nicht genau wissen, wer sich im Chatroom befindet, ich möchte nur, dass jeder im Chatroom meine Nachricht erhĂ€lt. Hier kommt der Pub/Sub ins Spiel.
GrundsĂ€tzlich ist pub/sub (kurz fĂŒr publish/subscribe) ein Modell, das Nachrichtensender (Publisher) und EmpfĂ€nger (Subscriber) entkoppelt. Publisher veröffentlichen Nachrichten zu Themen (wir betrachten hier nur themenbasierte Veröffentlichungen/Subs), ohne zu wissen, wer das Thema abonniert hat und erhalten die Nachricht. Abonnenten abonnieren Themen und erhalten Nachrichten, die an abonnierte Themen gesendet werden. Pub/Sub ist ein grundlegender Baustein fĂŒr moderne Anwendungen und ist in der Infrastrukturebene (z.B. Load Balancing) sowie in der Anwendungsebene (z.B. Chatroom/Messenger) weit verbreitet.
Das folgende Diagramm aus der Google Cloud (https://cloud.google.com/pubsub/docs/overview) zeigt die Beziehung zwischen Publisher, Abonnent und Thema.
Herausforderungen des dezentralen Pub/Sub
Cloud-Anbieter wie Google Cloud, AWS bieten Cloud-basierte Pubs/Subs, aber ihre zentrale Struktur macht es schwierig (wenn nicht unmöglich), sie in dezentralen Anwendungen zu nutzen.
Andererseits ist der Aufbau eines dezentralen Pubs/Subs auch eine Herausforderung, da die meisten bestehenden dezentralen Systeme (z.B. Ethereum) fĂŒr Echtzeit-Nachrichten nicht gut geeignet sind â wenn das Senden einer einzelnen Nachricht mehr als einen Cent in USD und fast eine Minute kosten wĂŒrde, ganz zu schweigen von der Frage der Skalierbarkeit, wie könnten man erwarten, dass sie praktisch nĂŒtzlich ist?
Im Allgemeinen gibt es einige Herausforderungen beim Aufbau eines dezentralen Pub/Sub auf der Grundlage eines bestehenden dezentralen Systems (basiert höchstwahrscheinlich auf der Blockchain):
- Die Nachricht muss in Echtzeit ĂŒbermittelt werden.
- Die Zustellung von Nachrichten muss bezahlbar sein.
- Der Nachrichtendurchsatz muss horizontal skalierbar sein.
Wenn Sie aus einem Nicht-Blockchain-Hintergrund kommen, lachen Sie wahrscheinlich darĂŒber, wie trivial die oben genannten âHerausforderungenâ sind. Nun, die RealitĂ€t ist, wenn wir uns auf eine On-Chain-Transaktion verlassen, um Informationen zu ĂŒbertragen, ist es immer noch sehr schwierig, die oben genannten Probleme zu lösen.
Eine Lösung fĂŒr diese Probleme ist die Verwendung von Off-Chain-Nachrichtenzustellung. Deshalb glauben wir, dass NKN perfekt geeignet ist, die Infrastruktur eines dezentralen Pub/Sub-Systems zu sein: Die NachrichtenĂŒbermittlung in NKN erfolgt sofort (in Millisekunden von Ende zu Ende), frei und horizontal skalierbar (mehr Knoten â höherer Durchsatz), da es sich um eine reine Off-Chain-Lösung handelt.
Herstellung eines dezentralen Pub/Sub
Um ein Pub/Subsystem aufzubauen, mĂŒssen wir zwei grundlegende Probleme lösen: wie man Themen-Abonnementinformationen speichert und abruft und wie man Nachrichten liefert. WĂ€hrend NKN natĂŒrlich das letztere löst, mĂŒssen wir noch entscheiden, wo die Teilnehmerinformationen gespeichert werden.
Nach reger Diskussion entscheiden wir uns, die Informationen zum Thema und Abonnent on-chain (= auf der Blockchain) zu speichern. Als Ergebnis muss die Anmeldung in einer Transaktion durchgefĂŒhrt werden, die zuverlĂ€ssig, aber nicht horizontal skalierbar ist. Damit sollte das Abonnement eine viel weniger hĂ€ufige Aktion sein als das Publizieren (das off-chain und horizontal skalierbar sein wird), also sollte es zu keinem Bottleneck â Effekt (âFlaschenhals â Effektâ) kommen.
Nach einigen Arbeiten und Tests können wir nun mit Freude sagen, dass unser Pub/Sub recht gut funktioniert. Da Publishing hauptsÀchlich Off-Chain-Nachrichten sendet, ist es in den NKN-Client integriert (z.B. https://github.com/nknorg/nkn-client-js 1). Das Abonnement hingegen ist in das NKN-Wallet (z.B. https://github.com/nknorg/nkn-wallet-js) integriert, da es Transaktionen signieren und senden muss. Beide sind in das NKN SDK (z.B. https://github.com/nknorg/nkn-sdk-go) integriert, das sowohl den NKN-Client als auch das NKN-Wallet enthÀlt.
Verwendung von Pub/Sub
Details zur Verwendung von pub/sub finden Sie in der Dokumentation verschiedener NKN-Client-/Wallet/SDK-Implementierungen. Die API ist im Allgemeinen recht einfach. In der JavaScript-Implementierung ist das Abonnieren eines Themas beispielsweise so einfach wie folgt
wallet.subscribe(topic, bucket, duration)
Der Grund, warum wir das Bucket-Konzept haben, ist die Vermeidung von (versehentlicher) Nachrichtenflutung im Falle massiver Abonnenten und kann durch ĂŒbergeordnete APIs wie SubscribeToFirstAvailableBucket verborgen werden. Ăhnlich einfach ist die Veröffentlichung zu einem Thema
client.publish(topic, bucket, message)
und die Anzahl der Buckets eines Themas kann ĂŒber APIs wie GetTopicBucketsCount ermittelt werden. Kunden, die sich fĂŒr das Thema angemeldet haben, können Nachrichten durch
client.on(âmessageâ, (src, payload, payloadType) => {});
erhalten.
AnwendungsfÀlle und Zusammenfassung
Pub/Sub ist in vielen Systemen und Anwendungen weit verbreitet. ZusĂ€tzlich zu den bestehenden AnwendungsfĂ€llen möchte ich in eine neue Klasse eintauchen, die fĂŒr dezentrale Anwendungen geeigneter und einzigartiger ist.
Die meisten zentralisierten Anwendungen sind nicht Open Source, und das Protokoll ist oft nur an die Anwendung gebunden. Dezentrale Anwendungen hingegen sind höchstwahrscheinlich Open-Source-Anwendungen, und das Protokoll ist von der Implementierung entkoppelt, um eine plattformĂŒbergreifende Kommunikation zu ermöglichen. Dies reduziert ProblemfĂ€lle bei der Entwicklung und Implementierung anwendungsĂŒbergreifender Protokolle erheblich. Wenn mehrere Anwendungen den gleichen Informationsfluss nutzen wollen, ist eine dezentrale, anwendungsneutrale und sprachneutrale Pub/Sub-Plattform unerlĂ€sslich.
Hier sind einige Beispiele:
- Verschiedene Dienstanbieter möchten den gleichen Mechanismus zur Dienstentdeckung nutzen.
- Mehrere Anwendungen möchten sich das gleiche Bewertungssystem teilen.
- Anwendungen möchten Daten an nachgelagerte Anwendungen weitergeben, die das Protokoll gemeinsam nutzen.
Um diese Ziele zu erreichen, könnte unser dezentraler Pub/Sub genutzt werden. Generell stellt dies eine der interessantesten Eigenschaften (meiner Meinung nach) dezentraler Anwendungen dar â die Trennung von Anwendung, Protokoll und Daten. Die Technologie von NKN ist einzigartig positioniert und wurde speziell entwickelt, um diese Chance zu nutzen. Wir werden in KĂŒrze etwas veröffentlichen, das auf unserem dezentralen Pub/Sub-Framework basiert.
