Dies ist eine maschinelle Übersetzung. Das Original in Englisch ist hier: Update 30 March, 2023
Wenn Sie mit Spitzentechnologie arbeiten, können Sie manchmal nur darauf warten, dass sich anderswo etwas entwickelt. Diese Fortschritte können frustrierend lange auf sich warten lassen, aber wir freuen uns, diese Woche einen bedeutenden Durchbruch an der Netzwerkfront ankündigen zu können. Wir machen auch erhebliche Fortschritte bei DBCs, Tx-Gebühren und der Art und Weise, wie sie von den Ältesten gehandhabt werden. @oetyng erklärt mehr.
Allgemeiner Fortschritt
Diese Woche gibt es viel Positives zu berichten. Zunächst hat einige meisterhafte Detektivarbeit von @qi_ma 
die Ursache eines seit langem bestehenden Netzwerkproblems ans Licht gebracht Start, der CI-Ausfälle verursachte. Erfreut sagen zu können, dass Kopfschmerzen nicht mehr sind.
Nun zu etwas, das von @dirvine sowohl als „Game Changer“ als auch etwas mysteriöserweise als „sehr entspannend“ beschrieben wird. Also, was ist es? Nun, diese Woche haben Protocol Labs, das Team hinter IPFS und Filecoin, ihre libp2p-Bibliothek aktualisiert. Libp2p hat sich beim Multiplexen und Lochen als ziemlich erfolgreich erwiesen, aber bisher hat es nur über TCP funktioniert. Das hat sich jetzt geändert und die Bibliothek arbeitet mit UDP und QUIC, was Safe verwendet, um Verbindungen zwischen Knoten zu verwalten. Libp2p wird von Filecoin, Eth und Avalanche verwendet und hat viele exzellente Ingenieure, die dafür arbeiten.
Noch besser, wir erhalten kostenloses Hole Punching, Erkennung lokaler Knoten, DoS-Schutz und mehr. Es sieht so aus, als ob libp2p jetzt das ist, was es sein sollte und was wir mit qp2p zu schaffen versuchten: eine solide Bibliothek, die sich auf p2p konzentriert. Mit der kürzlichen Aufnahme von QUIC können wir sehen, dass das libp2p-Team erkannt hat, dass ein Großteil ihrer Arbeit (Stream-Multiplexing, Rauschen für die Sicherheit usw.) von QUIC abgedeckt wird.
Wie auch immer, tolle Neuigkeiten rundum. Es sollte bedeuten, dass wir endlich eine große Stabilität in der Netzwerkschicht haben und dass die Netzwerkschicht so funktioniert, wie wir es wollen. Also Hut ab vor den libp2p-Leuten 
Mit ein wenig Feintuning und ein paar PRs sollten wir endlich in der Lage sein, Quinn und qp2p auf Safe zu ersetzen. Die Einschränkungen dieser Bibliotheken haben David viele Monate lang nachts wach gehalten. Endlich kann er sich entspannen. :Sonnenschirm:
@bzee hat es bereits geschafft, einen Prototyp eines Kademlia-Netzwerks mit libp2p und etwas mehr Arbeit herauszubringen, das als Test einsatzbereit sein sollte. @Roland untersucht auch die Dokumentation, um zu sehen, ob wir dies möglicherweise nutzen können.
@bochaco hat dem Node-RPC einige CLI-Befehle hinzugefügt, um Dinge wie Speicherebenenprüfungen, Belohnungsabfragen und Wallet-Mutationen zu ermöglichen.
Und @oetyng war im Zahlungsdienst. Mehr dazu weiter unten.
Update zum Zahlungsnetzwerk
Wir haben einige Schritte in Richtung eines Zahlungsnetzwerks zurückgelegt.
Zunächst einmal, wie einige zuvor bereits beim Betrieb eines lokalen Netzwerks festgestellt haben, haben wir Clients Älteste gegen eine Gebühr (ein fest codierter Wert von 1 Nano) abfragen lassen und ihre Übertragung erweitert, um auch jeweils einen DBC für die Ältesten zu enthalten. Das bedeutete, dass beim Senden von Token jeder ausgegebene DBC 7 Nanos kosten würde, die an die Ältesten gezahlt wurden.
Aber die Zahlung war im Wesentlichen eine Verbrennung. Denn der Älteste konnte weder sehen, dass eine Zahlung an sie erfolgte, noch darauf zugreifen.
Überprüfung des Gebührenbetrags
Der nächste Schritt bestand also darin, das „Blinding“ des Gebührenbetrags einzuführen, damit der Älteste überprüfen konnte, ob A. eine Zahlung für sie da war, und B., dass es ein ausreichender Betrag war . Denn denken Sie daran, ein Außenstehender kann nicht sehen, welchen Betrag ein DBC enthält und für wen es bestimmt ist. Wir müssen einen Weg finden, den Ältesten diese Dinge mitzuteilen.
Clients senden also zusammen mit ihrer Ausgabenanfrage ein Chiffrierpaar – verschlüsselte Informationen. Wenn der Älteste dies erhält, kann er es entschlüsseln und erhält Folgendes:
Ableitungsindex
Der „Ableitungsindex“ wird verwendet, um den öffentlichen Schlüssel (im Wesentlichen die eindeutige Kennung) des neuen DBC abzuleiten, der die Gebührenzahlung enthält. Der Client leitet diese ID aus dem statischen öffentlichen Schlüssel ab, den der Elder zusammen mit dem aktuell erforderlichen Gebührenbetrag auf Anfrage an den Elder sendet.
Der Älteste verwendet denselben Ableitungsindex, um den entsprechenden geheimen Schlüssel abzuleiten, mit dem er den Wert in der DBC freischalten kann, der den Gebührenbetrag für ihn enthält.
Da dieser Ableitungsindex verschlüsselt an den Ältesten gesendet wird, kann niemand sagen, dass es eine Zahlung an diesen Ältesten gibt, und es gibt keine Möglichkeit zu sehen, wie viel es war.
Blindfaktor + Betrag
Zusätzlich sendet der Kunde den verschlüsselten „Blindfaktor“ und den Betrag.
Mit dem „Blindfaktor“ kann der Älteste den Betrag blenden und mit dem Betrag in der DBC-Transaktion vergleichen. Dies liegt daran, dass, wenn derselbe „Blindfaktor“ und dieselbe Menge verwendet werden, genau dasselbe unverständliche Durcheinander erzeugt wird. Deshalb wird auch der „Blindfaktor“ verschlüsselt. Nur der Kunde und der Älteste kennen den Betrag.
Weitere Einzelheiten zum obigen Ablauf finden Sie im Kommentarbereich oben in dieser Datei: safe_network/mod.rs at main · maidsafe/safe_network · GitHub
Endlich gdie Gebühr festlegen
Wenn eine große Mehrheit der Ältesten die Ausgaben unterzeichnet hat, senden sie jeweils einen „SpentProofShare“ an die Dateninhaber im Netzwerk. Bei der Abfrage nach diesen Anteilen kann der „SpentProof“ aus diesen Signaturen aggregiert werden, und es können DBCs erstellt werden, die jeder der Ausgaben in der Transaktion entsprechen. Ein Ältester kann somit das Netzwerk nach diesen abfragen und dann den DBC aufbauen, der die Gebührenzahlung enthält.
Von fest kodierter zu dynamischer Gebühr
Ein Nano pro Gebühr wird nicht viel helfen, also haben wir die Berechnung der erforderlichen Token ausgegraben, um einige Daten zu speichern, die wir bereits in unseren Archiven hatten.
Die Implementierung berechnet die erforderlichen Tokens für Schreiboperationen als eine Anzahl von Tokens, die für eine bestimmte Anzahl von Bytes zu zahlen sind, wobei das aktuelle Abschnittspräfix, die Anzahl der Knoten in dem Abschnitt und der Prozentsatz der Füllung gegeben sind. Dies kann auch zur Berechnung der Gebühr einer Überweisung verwendet werden, da wir sie nur mit einer festen Anzahl von Bytes füttern.
Angesichts der Eingabeparameter und des Kurvendesigns gibt es eine Auswirkung auf den Preis basierend auf Angebot und Nachfrage, wenn auch mit einer gewissen Trägheit. Der berechnete Wert ist höher, wenn weniger Knoten im Abschnitt vorhanden sind, wenn weniger Platz zur Verfügung steht und früher im Netzwerk. Früher im Netz? Sie könnten fragen. Ja, es wird davon ausgegangen, dass ein größeres Netzwerk bedeutet, dass der Token einen höheren Wert hat, da mehr Menschen eine konstante Anzahl von Token teilen. Daher ist auch die benötigte Anzahl an Tokens pro Vorgang geringer, wenn das Netzwerk wächst. Mit anderen Worten, der Preis spiegelt den deflationären Charakter von SNT wider.
Eine weitere Eigenschaft der Kurve ist, dass sie auf niedrigem Niveau sehr flach ist, bis etwa 1/3 Platz verbleibt, wobei sie schnell steiler wird. Der Grund dafür ist, dass die Gebühr so lange wie möglich so niedrig wie möglich bleibt.
Dies ist jedoch kein Ersatz für einen echten Markt. Obwohl wir eine gewisse Kontrolle über Angebot/Nachfrage haben, ist es ziemlich träge, und die darauf basierende Gebührenhöhe ist daher ziemlich starr. Daher ist es für das Netzwerk schwierig, die tatsächlichen Änderungen des Fiat-Werts des Tokens widerzuspiegeln, und das kann zu großen Ungleichgewichten führen – was nie gut ist. Solche Ungleichgewichte können viel zu viele Anfragen oder viel zu wenige sein, da der tatsächliche Wert nicht mit dem aus den Netzwerkparametern berechneten Wert übereinstimmt.
Das bringt uns zu der Option für einen Kunden, seine Ausgaben zu priorisieren, und was uns das eröffnet.
Prioritätswarteschlange ausgeben
Eine mit Ausgaben verbundene „Priorität“ ist ein großer Sprung nach vorne in Richtung eines echten Marktes, wo die Angebots-/Nachfrageeigenschaften des Systems flink und reaktionsschnell sind.
Dies wird von den Ältesten durchgeführt, die eine Prioritätswarteschlange führen, geordnet nach dem Wert der Gebühr, die ihnen gezahlt wird, um die Ausgaben zu unterzeichnen.
Die Vorteile der Implementierung einer Prioritätswarteschlange sind die folgenden:
- Kunden können einen niedrigeren Preis für ihren Speicher erhalten, wenn die Nachfrage gering ist.
- Älteste können eine höhere Belohnung für ihre Dienste erhalten, wenn die Nachfrage hoch ist.
- Anreize für Node-Betreiber, zusätzliche Nodes zu betreiben, steigen, wenn die Nachfrage steigt.
- Das Netzwerk wird reaktionsschneller und kann schneller wachsen (mehr zum Ausführen von Knoten anziehen), wenn die Nachfrage steigt.
- Der kontinuierliche Betrieb von Knoten ist besser vor einer Überlastung der Kundenausgaben geschützt.
- Die Auslastung des Netzwerks wird über die Zeit verteilt, da die Leute Ausgaben zu Zeiten hoher Auslastung aufschieben und sie zu Zeiten mit geringerer Auslastung verschieben.
- Älteste haben die Möglichkeit, schneller auf ihre Belohnungen zuzugreifen, da sie sie sammeln und in einem größeren DBC neu ausstellen können, wenn die Gebühren niedrig sind.
- …und mehr…
Das erste Beispiel verwendet ein paar diskrete „Prioritäts“-Schritte für einen Client, die von der Brieftaschen-Benutzeroberfläche aus verwendet werden, wenn er eine Zahlung durchführt. Dadurch entfällt die Notwendigkeit, Gebührenbeträge manuell festzulegen.
Die Priorität wird in eine Gebühr umgewandelt, die auf den aktuellen Gebühren in der Warteschlange basiert. Eine hohe Priorität würde bedeuten, dass Sie einen ähnlichen Wert zahlen wie diejenigen, die höher in der Warteschlange stehen, und umgekehrt für eine niedrige Priorität. Sie können es auch auf über den höchsten Wert oder unter den niedrigsten Wert setzen, und hier kann der Druck auf den Preis beginnen, basierend auf Angebot und Nachfrage und den Bedürfnissen von Kunden und Node-Betreibern, ein Gleichgewicht zu finden.
Durch die Wahl der Priorität entscheidet der Kunde im Wesentlichen, wie schnell er eine Bearbeitung wünscht. Sie können es mehr oder weniger sofort bearbeiten lassen oder die Gebühr auf ein niedrigeres Niveau festlegen, um es zu einem Zeitpunkt bearbeiten zu lassen, an dem die Nachfrage und die Gebühren niedriger sind.
Beachten Sie, dass es immer noch ein Limit gibt, wie niedrig der Kunde die Gebühr festlegen kann. Darunter würde es gelöscht und ein Fehler an den Client zurückgegeben.
Es sollte einem Kunden auch möglich sein, ausstehende Ausgaben zu aktualisieren, damit er dort nicht hängen bleibt, wenn Gebühren und Nachfrage auf einem höheren Niveau bleiben.
Zusammenfassung
Um es abzurunden, die Grundidee ist also, dass das Ausgeben eines DBC zu vielen Ausgabe-DBCs führen kann. Wenn wir eine Anfrage an Älteste senden, einen DBC auszugeben, hängen wir diese Ausgaben auch an.
Die Ältesten überprüfen dann den Betrag und fahren mit der Verarbeitung der Ausgaben fort.
Der aufmerksame Leser hätte bemerkt, dass die an einen Ältesten gezahlte Gebühr in einem DBC ist, und wenn der Älteste diesen DBC ausgeben möchte, dann würde es eine Gebühr verlangen, um ihn auszugeben, und wenn diezwei sind gleich… dann hast du… nichts?
Genau so ist es. Wenn wir uns also daran erinnern, dass der Preis-Algorithmus niedrigere Werte zurückgibt, je größer das Netzwerk ist, können wir sehen, dass es eine Art Lock-in + Early-Bird-Effekt gibt. Wenn der Nennwert einer Gebühr sinkt, werden zuvor gezahlte Gebühren immer „zugänglicher“.
Auch hier hilft die Prioritätswarteschlange. Gebühren, die während hoher Lasten eingenommen wurden, könnten gesammelt und bei niedrigeren Gebühren neu ausgestellt werden. Ein weiterer Faktor, der dazu beiträgt, die Belastung auszugleichen.
Ich hoffe, das gibt Ihnen allen einen guten Einblick in das, was sich zusammenbraut.
Nützliche Links
Fühlen Sie sich frei, unten mit Links zu Übersetzungen dieses Entwicklungsupdates zu antworten, und die Moderatoren werden sie hier hinzufügen.
Als Open Source-Projekt sind wir immer auf der Suche nach Feedback, Kommentaren und Community-Beiträgen. Seien Sie also nicht schüchtern, machen Sie mit und lassen Sie uns gemeinsam das sichere Netzwerk erstellen!