Nostr, ein wachsendes Zentrum für die Bitcoin-Community, steht vor einigen Herausforderungen, wenn es eine bedeutende Größenordnung erreichen soll.
Dies ist ein Meinungsleitartikel von Shinobi, einem autodidaktischen Pädagogen im Bitcoin-Bereich und technisch orientierten Bitcoin-Podcast-Moderator.
Ich habe einen Artikel über die Grundlagen geschrieben, was Nostr ist und was „Events“ sind und wie sie funktionieren, sowie einen über einige der wichtigsten Verwaltungsprobleme, die die Plattform lösen muss. Lassen Sie uns nun einige der Probleme durchgehen, die Relay-Server langfristig angehen müssen.
Das gesamte Nostr-Protokoll hängt von Leuten ab, die irgendwo einen Relay-Server betreiben. Es gibt kein “Nostr-Netzwerk”, es gibt nur Relais und Clients, die sich mit Relais verbinden. Es muss Anreize für die Leute geben, Staffeln zu leiten, und auf lange Sicht wird dies letztendlich einen großen Teil dazu beitragen, wie weit Staffeln skalieren können. Es wird niemals Nostr-Relays in der Größenordnung von Twitter-Servern geben, es sei denn, sie können rentabel betrieben werden oder zumindest genug Geld einbringen, um die Kosten für den eigenen Betrieb zu bezahlen.
Werbung
Es wäre sehr trivial, Werbung vollständig zu blockieren, was es angesichts der Funktionsweise von Nostr als Protokoll zu einer nicht praktikablen Lösung macht. Ein Relay-Server könnte versuchen, Werbung als Einnahmemodell zu verwenden, es ist offensichtlich das vorherrschende Einnahmemodell für so ziemlich jeden kostenlosen Dienst, den es online gibt, aber das Problem dabei ist, dass die Benutzer sich im Wesentlichen dafür entscheiden müssten. Relays könnten einfach Werbung in die Ereignisse einfügen, die sie an Clients senden, aber Clients könnten diese auch einfach aus der Benutzeroberfläche herausfiltern, wenn die Ankündigungsereignisse nicht durch einen öffentlichen Schlüssel erstellt wurden, den sie absichtlich abonniert haben.
Selbst wenn ein Relay-Operator einen Client erstellt hat, der dies nicht getan hat, gibt es keine Möglichkeit, Benutzer daran zu hindern, andere Clients zu verwenden, die dies getan haben, um Daten von ihrem Relay abzurufen. Sie würden nicht einmal wirklich wissen, ob jemandes Kunde Anzeigen vor den Benutzern versteckt oder nicht, und aufgrund dieses Mangels an Einsicht ist dieses Modell bei der Ankunft so gut wie tot, es sei denn, die Benutzer haben sich absichtlich dafür entschieden. Und selbst dann hätte der Relay-Betreiber keine solide Grundlage, um den Werbetreibenden etwas über das Engagement zu zeigen.
Mikrozahlungen
Mikrozahlungen sind eine weitere naheliegende Lösung, insbesondere angesichts der aktuellen Versuche, Lightning enger in Nostr-Anwendungen zu integrieren. Dieses Modell würde viel Flexibilität in Bezug auf das Aufladen bieten. Relays könnten Gebühren erheben, wenn sie Ereignisse dort veröffentlichen, sie könnten Gebühren für das Herunterladen von Ereignissen zum Lesen erheben, sie könnten eine Kombination aus beidem durchführen und den Preis für jedes einzelne abhängig davon anpassen, wie viel ihrer Ressourcen von dem einen oder anderen verbraucht werden. Ich persönlich bin jedoch etwas skeptisch, dass dieses Modell auf die Größe von so etwas wie Twitter skalieren könnte. Content-Mikrozahlungen erweisen sich in vielen Nischenprodukten, die auf Lightning basieren, als tragfähig, aber es gibt zwei grundlegende Probleme bei der Skalierung auf eine globale Größe.
Erstens gibt es dafür derzeit einfach nicht genug Bitcoin-Akzeptanz. Selbst wenn jeder auf magische Weise damit einverstanden wäre, für jede kleine Serviceinteraktion über Nostr zu bezahlen, gibt es nicht genug Leute, die Bitcoin in einem so massiven Umfang wie Twitter halten. Relays könnten Abonnements per Fiat berechnen, aber diese Zahlungsschienen werden keine Zahlung von einem Bruchteil eines Cents für jedes gepostete oder heruntergeladene Ereignis unterstützen. Zweitens sind die Menschen buchstäblich daran gewöhnt, dass solche Dienste kostenlos sind. Es ist genau das, was die Leute erwarten. Mikrozahlungen allein werden meiner Meinung nach auch nicht wirklich ausreichen, um Relais in großem Maßstab zu unterstützen.
Es könnte eine Möglichkeit geben, Mikrozahlungen „fester“ oder nachhaltiger zu gestalten, ohne sie buchstäblich jeder Klasse von Benutzern aufzuzwingen, die Ihr Relais verwenden. Es wurde viel darüber diskutiert, neben einem Twitter-Klon alle Arten von Anwendungen auf Nostr aufzubauen: GitHub, Wikipedia, sogar dezentralisierte Gig-Worker-Apps wie Uber. Letzteres ist hier der Schlüssel. Etwas wie Twitter oder Google ist nur ein Dienst, den die Menschen ihr ganzes Leben lang als selbstverständlich für kostenlos gehalten haben. Wirtschaftlicher Handel ist kein Ort, an dem diese Annahmen tief in ihnen verwurzelt sind. Die Menschen sind es sehr gewohnt, eine Gebühr zu zahlen, um irgendwo eine Stellenanzeige zu schalten, oder einem Marktplatzbetreiber einen Anteil zu zahlen, wenn sie etwas online bestellen. Sie gehen einfach davon aus und erwarten es von Anfang an. Dies könnte Relais eine Möglichkeit bieten, ein zuverlässiges Einkommensrückgrat von ihren Benutzern zu schaffen, ohne große Reibungspunkte zu schaffen oder die Erwartungen des durchschnittlichen potenziellen Benutzers zu brechen.
Wenn auch Mikrozahlungen eine Rolle spielen, muss der Relay-Betreiber einen Lightning-Knoten betreiben, um überhaupt Gelder von Benutzern zu erhalten. Dies könnte diese Einnahmen potenziell verstärken, wenn es richtig mit dem von einem Relais implementierten Mikrozahlungsmodell synergetisch kombiniert wird. Je größer ein Relay-Server in Bezug auf die Einnahmen ist, die er einbringt, desto mehr Liquidität wird er im Lightning Network benötigen, um dies zu ermöglichen. Wenn die Betreiber richtig planen, wie sie diese Liquidität im gesamten Netzwerk einsetzen oder zuweisen, dann könnte allein der Betrieb eines Routing-Knotens möglicherweise eine nicht unbedeutende Einnahmequelle sein, zusätzlich zu den Gebühren, die sie für die Annahme oder Lieferung von Daten über ihr Netz erheben Relais.
Kann Nostr Relais skalieren?
Aber selbst wenn man all dies zusammenklebt, können diese unterschiedlichen Einnahmemodelle ein Relais im Twitter-Maßstab unterstützen? Vielleicht könnte eine Gig-Work-Staffel das, aber wäre es nicht vernünftig, sich nur auf diese Art von Veranstaltungen zu spezialisieren? Was ist mit anderen Anwendungsfällen, wie Social Media? Vielleicht ist ein einzelnes Relais, das in dieser Größenordnung für bestimmte Anwendungsfälle von Nostr betrieben wird, einfach nicht wirtschaftlich. Die Grundstruktur des Protokolls wurde auf sehr einfache Weise erstellt, damit es nicht leicht zensiert oder seine Ereignisinhalte auf nicht offensichtliche Weise manipuliert werden können. Diese Struktur ist jedoch mit Overhead verbunden.
Das macht Nostr überhaupt nicht kaputt, wenn es sich als wahr herausstellt. Schließlich können sich Clients mit beliebigen Relays verbinden. Clients sind nicht mit einem einzelnen Relay verbunden, sie können Ereignisse von Dutzenden von Relays gleichzeitig abrufen. Auf einem Relais gespeicherte Ereignisse können sogar auf Ereignisse verweisen, die auf völlig anderen Relais gespeichert sind. Das Protokoll kann dennoch für jeden Anwendungsfall in der Praxis funktionieren, selbst wenn einzelne Relay-Server harte Grenzen haben, die sie in Bezug auf Benutzerzahlen oder die Anzahl der von ihnen gespeicherten und bereitgestellten Ereignisse nicht überschreiten können.
Allerdings … diese Dynamik wirft selbst Probleme auf, wie all diese Daten, die über verschiedene Server verstreut sind, indiziert und verfolgt werden können. Haben Sie eine vollständige Übersicht über eine Reihe von Ereignissen, die aufeinander verweisen? Fehlt etwas?
Ein verteiltes Netz kleinerer Relais wird genauso auf Skalierungsprobleme stoßen wie ein einzelnes Relais, das versucht, massiv zu sein. Aber das hebe ich mir für ein anderes Mal auf.
Dies ist ein Gastbeitrag von Shinobi. Die geäußerten Meinungen sind ausschließlich ihre eigenen und spiegeln nicht unbedingt die von BTC Inc oder Bitcoin Magazine wider.
