Safe Network Entwickler Update đŸ‡©đŸ‡Ș 18. August 2022

Dies ist eine maschinelle Übersetzung. Das Original in Englisch ist hier: Update 18 August, 2022

Diese Woche befassen wir uns etwas eingehender mit SNT-Emissionen. So werden nach der anfĂ€nglichen Verteilung von Tokens bei der GrĂŒndung des Netzwerks die verbleibenden 70 % der Durch das langfristige Hochladen von Daten wird eine Gesamtversorgung geschaffen und sicher verteilt. Wir haben ein bisschen tiefer darĂŒber nachgedacht, wie das funktionieren sollte, damit es so einfach und sicher wie möglich ist, und haben ein paar Schritte aus unserem ursprĂŒnglichen Design herausgeschnitten.

Ein Hoch auf @southside fĂŒr das Testen der neuesten Builds und das Bereitstellen von Protokollen :beten:. Sehen Sie sich jetzt diese Spitzen und KnotenausfĂ€lle an.

Allgemeiner Fortschritt

@Davidrusu hat die Protokolle so rationalisiert, dass sie jeweils aus einer einzelnen Zeile bestehen, damit sie leichter analysiert und irrelevante Informationen entfernt werden können. Leider haben wir dabei @happybeing’s Vdash gebohrt - aber hoffentlich nicht auf eine Weise, die zu schwer ist, um wieder zu entborken.

Ein Großteil der restlichen Arbeit ist Testen Testen Testen. Einem Vorschlag von @Chriso folgend nehmen wir einige Änderungen daran vor, wie sich Tests auf den nĂ€chtlichen Build auswirken, fĂŒhren einen Staging-Zweig ein und priorisieren das Beheben von Testfehlern, die dort eine Veröffentlichung verhindern, sodass der Code immer veröffentlichungsreif oder nahe daran ist.

Und @anselme hat ein Problem im BLS-Ephemeral-Key-Broadcast-Schritt in DKG behoben. Sowohl die BLS-SchlĂŒsselĂŒbertragung als auch die DKG-Abstimmungen funktionieren jetzt einwandfrei und alle Mitglieder erhalten alle Stimmen, ein wichtiger Schritt.

SNT-Emissionen

Wenn Benutzer Daten in das Netzwerk hochladen, zahlen sie. Wir möchten nicht, dass jede Zahlung zu SNT-Emissionen fĂŒhrt, sondern nur ein Teil davon, und wir möchten, dass dieser Anteil gemĂ€ĂŸ den Anforderungen des Netzwerks variiert. Wenn das Netzwerk mehr Speicherplatz benötigt, steigt der Anteil der Uploads, die zu einer SNT-Emission fĂŒhren, um mehr Speicherknoten anzuziehen, wenn viel Speicherplatz vorhanden ist, nimmt er ab. Der genaue Mechanismus dafĂŒr wird noch diskutiert, aber wir hoffen, Ihnen in KĂŒrze weitere Einzelheiten mitteilen zu können.

Eine Zahlung, die zur Erstellung eines neuen (‚Genesis‘) DBC fĂŒhrt, wird (vorerst) als ‚Genesis-Ereignis‘ bezeichnet. Das „Genesis-Ereignis“ erfordert einen „GenesisProof“, eine Datei, die Informationen ĂŒber den Wert des DBC und seine EmpfĂ€nger codiert.

Der Wert des Genesis DBC ist einfach genug – es ist ein fester Teil des Wertes der Speichertransaktion (z. B. 90 % der anfĂ€nglichen Zahlung könnten belohnt werden).

Beim EmpfĂ€ngerteil sind die Dinge etwas komplexer. Das „Genesis-Ereignis“ einer Transaktion findet nur in einem Abschnitt statt, und alle Ältesten und die speichernden Knoten werden proportional zu ihrem Knotenalter bezahlt. Aber die Mitgliedschaft einer Sektion Ă€ndert sich stĂ€ndig, woher wissen wir also, welche Knoten zu bezahlen sind?

Informationen ĂŒber SektionsĂ€lteste werden im Section Authority Provider (SAP) gespeichert, aber dieser ist möglicherweise nicht auf dem neuesten Stand, und wĂ€hrend er durch AE aktualisiert wird, kann sich die Mitgliedschaft erneut Ă€ndern.

Ein besserer Weg wĂ€re also, EmpfĂ€nger aus der Zahlung „Genesis-Ereignis“ zu verwenden. Dem Client wird auf der Speicheranforderung (Angebot) mitgeteilt, wer zu zahlen hat, einschließlich der SAP (Älteste) und der Speicherknoten. Aus deren ID lĂ€sst sich das Alter der Nodes zum Zeitpunkt des Angebots berechnen. Auf diese Weise kann jeder der EmpfĂ€nger den DBC jederzeit an sich selbst und die anderen EmpfĂ€nger neu ausstellen, und die Zahlung erreicht sie garantiert, auch wenn sie nicht mehr in der Sektion sind, der Prozess ist deterministisch.

Unsere erste Anlaufstelle fĂŒr die Neuausstellung wird jedoch immer der Kunde (der Zahler) sein, da dies das Netzwerk entlastet. Wir diskutieren, ob einer der DBC-BelohnungsempfĂ€nger der Client selbst sein könnte, was einen Anreiz fĂŒr den Client schafft, die Neuausstellung durchzufĂŒhren, aber wenn das fehlschlĂ€gt, kann es stattdessen jeder der im GenesisProof erwĂ€hnten Netzwerkknoten tun.

Nur fĂŒr das Speichern von Erwachsenen zu bezahlen, anstatt fĂŒr alle Erwachsenen in einem Abschnitt (ein weiteres mögliches Szenario), funktioniert gut, da dies weniger DBCs und weniger Nachrichten bedeutet. Im Laufe der Zeit erfolgen die Zahlungen zufĂ€llig ĂŒber den Abschnitt/das Netzwerk, da die Speicherknoten durch die XOR-Adresse der Datenblöcke bestimmt werden.

Darauf arbeiten wir jetzt hin. Wir mĂŒssen noch herausfinden, wie wir die Speicherkosten festlegen, wie wir das Mining von SNTs fĂŒr Schurkenabschnitte unwirtschaftlich machen und wo wir die GenesisProofs aufbewahren.

Wir sind auch sehr daran interessiert, den Spitznamen „Genesis“ fĂŒr neue DBCs fallen zu lassen, da er verwirrend ist. Ein Vorschlag ist RootDBC - was denkst du, oh Community?


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!