Safe Network Entwickler Update đŸ‡©đŸ‡Ș 21. Oktober 2021

Dies ist eine maschinelle Übersetzung. Das Original in Englisch ist hier: Update 21 October, 2021

Warum feste StĂŒckelungen in einer digitalen WĂ€hrung verwenden, wenn Ihre Zahlungen beliebige BetrĂ€ge umfassen können? Schließlich reden wir hier von Zahlen, nicht von Metallfetzen und Papierfetzen. Die Antwort ist PrivatsphĂ€re. Wenn Sie 4589234127 SNT tĂ€tigen, ist diese Zahl höchstwahrscheinlich eindeutig und daher rĂŒckverfolgbar.

Aber auch wenn wir Konfessionen akzeptieren, um AnonymitĂ€t zu bĂŒndeln, stellt sich auch die Frage der Effizienz. Eine geringe Anzahl möglicher StĂŒckelungen (z. B. 1 und 10) wĂŒrde die VerknĂŒpfung von Transaktionen extrem erschweren und die FungibilitĂ€t maximieren, jedoch auf Kosten einer inakzeptablen Mehrarbeit fĂŒr das Netzwerk.

Die Studie von @mav zu Bitcoin-Transaktionen zeigt, dass eine GranularitĂ€t von 8 signifikanten Dezimalstellen ĂŒblich ist, vermutlich weil Btc-Zahlungen auf Basis von Fiat-WĂ€hrungen berechnet werden und dem jeweiligen Wechselkurs unterliegen. Dies wird auch fĂŒr SNT gelten, sodass wir keine vollkommen gleichmĂ€ĂŸigen BetrĂ€ge erwarten können.

Das Team hat einen Happy-Medium-Ansatz entwickelt, der eine massive Teilbarkeit ermöglicht, mit realen Transaktionen ĂŒbereinstimmt und die MĂŒnzstĂ€tten nicht ĂŒbermĂ€ĂŸig belasten sollte.

Das ist eine Zusammenfassung. FĂŒr diejenigen, die tiefer graben möchten, legt @danda unten unser aktuelles Denken in all seiner mathematischen Pracht dar.

Allgemeiner Fortschritt

@chriso hat hart daran gearbeitet, die API und die cli zusammenzufĂŒhren. Codetechnisch ist alles drin, aber die ZusammenfĂŒhrung dieser Repos hat dazu gefĂŒhrt, dass wir unsere AblĂ€ufe fĂŒr kontinuierliche Integration und Versions-Bumping anpassen mussten. Es wurden akzeptable Lösungen gefunden, was bedeuten sollte, dass an jede safe_network-Version alle Crates angehĂ€ngt sind, jedoch mit ihren eigenen unterschiedlichen Versionen (unser alter Ablauf hĂ€tte nur eine Version bedeutet und eine Menge wahrscheinlicher Verwirrung dort). Jetzt arbeitet er daran, diese Änderungen umzusetzen.

@Chris.Connelly hat weiter in qp2p gestöbert und bestĂ€tigt, dass das Senden vieler Nachrichten zwischen zwei Knoten ĂŒber eine einzelne Verbindung viel schneller ist als ĂŒber viele Verbindungen. Dies ergibt sich aus der Verwendung von TLS durch QUIC, was bedeutet, dass jede Verbindung ein Handshake-Protokoll ausfĂŒhren muss. GlĂŒcklicherweise unterstĂŒtzt QUIC auch viele logisch unabhĂ€ngige Streams ĂŒber eine einzige Verbindung, sodass es hier keinen wirklichen Nachteil gibt – weniger Verbindungen, weniger Probleme. Dies informiert ĂŒber die letzten Phasen des Entfernens des Verbindungspoolings von qp2p, bei denen wir einige Sorgfalt walten lassen mĂŒssen, um sicherzustellen, dass wir mit Verbindungen weiterhin effizient sind.

@Lionel.Faber hat daran gearbeitet, den Prozess fĂŒr die Bereitstellung von Testnetzen in Digital Ocean zu verbessern, wobei jetzt fĂŒr jeden Schritt bei der Bereitstellung und Deaktivierung des Testnetzes eine Genehmigung erforderlich ist, sodass wir jeden Schritt neu starten oder das Testnetz extern verwenden können, anstatt es automatisch zu zerstören .

Wir haben auch den Start von Knoten/Clients verfeinert. Mit @yogesh, das das Schreiben der NetzwerkprĂ€fixkarte auf die Festplatte implementiert, sodass sie gemeinsam genutzt werden kann, sodass Clients und Knoten mit einem Minimum an Netzwerkkenntnissen beginnen können. Und wir haben einige lokale Protokollinspektionen hinzugefĂŒgt und verbessert, um Probleme leichter identifizieren und aufspĂŒren zu können.

Gute Nachrichten aus den DBC-Labors. Spentproofs arbeiten jetzt in der Testumgebung und sollten bald fusionsbereit sein.


Hintergrund der Konfessionen

Eine DBC-Mint, die blinde Signaturen verwendet, kann den Inhalt einer Ausgabe-DBC nicht sehen, bevor sie sie signiert, aber sie muss ĂŒberprĂŒfen, ob sum(inputs) == sum(outputs). Die MĂŒnzstĂ€tte kann der Neuausgabestelle nicht vertrauen, einen Betrag mit der Ausgabe anzugeben, da dies eine LĂŒge sein könnte. Verpflichtungsschemata sind möglich, aber die resultierenden Neuausgaben werden verknĂŒpfbar, wodurch der Zweck der Blindsignaturen zunichte gemacht wird.

Eine Lösung besteht dann darin, dass die MĂŒnzprĂ€geanstalt jeden DBC, der mit einem bestimmten SchlĂŒssel signiert ist, als jeden anderen DBC, der mit demselben SchlĂŒssel signiert ist, gleich behandelt. DarĂŒber hinaus können wir einen Satz fester StĂŒckelungen definieren, jede mit einem eindeutigen SignaturschlĂŒssel. Die SchlĂŒsselableitung ermöglicht es uns, einen einzelnen MĂŒnzschlĂŒssel zu haben, aber deterministisch einen NennwertschlĂŒssel abzuleiten, indem der Nennwert selbst als Ableitungsindex verwendet wird. Dies bedeutet, dass wir so weit gehen könnten, fĂŒr jeden möglichen Wert eines u128 einen eindeutigen Nennwert zu haben!

Aber es stellt sich heraus, dass dies sehr schlecht fĂŒr die PrivatsphĂ€re und die FungibilitĂ€t wĂ€re. Einmalige BetrĂ€ge wie 4589234127 ermöglichen es, eine Neuauflage mit einer anderen zu verknĂŒpfen. Denken Sie kurz an Bargeld. Mit USD zahlen wir mit PapierstĂŒcken von 1,2,5,10,50,100. Und auch MĂŒnzen: .01, .05, .10, .25, .50. Wenn Sie etwas mit einem Preis von 365,23 $ kaufen, können Sie mit drei 100, einer 50, einer 10, einer 5, zwei 0,20 und drei 0,01 bezahlen. Jeder dieser Scheine oder MĂŒnzen ist sehr schwer mit anderen Transaktionen zu verknĂŒpfen, da so viele andere Leute genau die gleichen BetrĂ€ge verwenden. Wenn Sie jedoch irgendwie eine Papierrechnung im Wert von 365,23 erstellen könnten, ist das ziemlich einzigartig und hebt Ihre Rechnung wirklich hervor.

Daher können wir sagen, dass jede StĂŒckelung einen AnonymitĂ€tssatz oder einen Pool darstellt, in dem sich Ihre Transaktion verstecken kann. Je mehr StĂŒckelungen (oder Pools) wir haben, desto kleiner ist jeder Pool. In Bezug auf Datenschutz/FungibilitĂ€t wĂŒrden wir also die kleinstmögliche Anzahl von Pools anstreben, was tatsĂ€chlich so ist1, also die kleinste verfĂŒgbare Einheit.

Wir mĂŒssen jedoch auch die Effizienz berĂŒcksichtigen. Dies wird durch die Anzahl der „MĂŒnzen“ (Scheine oder MĂŒnzen) gemessen, die erforderlich sind, um einen bestimmten Betrag zu wechseln. Bei unserem USD-Beispielpreis von 365,23 USD benötigten wir 11 einzelne Coins. Bedenken Sie außerdem, dass es bei einer typischen DBC-Neuausgabe zwei logische AusgabebetrĂ€ge gibt: 1: die Zahlung des EmpfĂ€ngers und 2: Wechselgeld fĂŒr den Absender. Das Erstellen, Signieren und Validieren von DBC-Coins bedeutet Arbeit fĂŒr die MĂŒnzknoten und es gibt auch einen erheblichen Netzwerkverkehr, der mit der Ausgabe jedes DBC verbunden ist. Wir mĂŒssen also versuchen, die Anzahl der erforderlichen WechselgeldmĂŒnzen fĂŒr jeden umsetzbaren Betrag zu minimieren.

Es wird also deutlich, dass ein SpannungsverhĂ€ltnis zwischen Optimierung auf FungibilitĂ€t und Optimierung auf Effizienz besteht. Die optimale FungibilitĂ€t wĂ€re, nur eine einzige Denomination zu haben. Die optimale Effizienz wĂ€re, fĂŒr jeden möglichen Betrag einen eindeutigen Nennwert zu haben.

###TransaktionsfĂ€hige BetrĂ€ge vs. StĂŒckelungen

Wenn wir ĂŒber StĂŒckelungen nachdenken, mĂŒssen wir sorgfĂ€ltig zwischen „umsetzbaren BetrĂ€gen“ und „StĂŒckelungsbetrĂ€gen“ unterscheiden.

Ein „umsetzbarer Betrag“ ist ein Preis oder ein Zahlungsbetrag, der abgewickelt wird. Ein oder mehrere StĂŒckelungsbetrĂ€ge können zu einem „umsetzbaren Betrag“ kombiniert/hinzugefĂŒgt werden.

In Zukunft werden wir den „StĂŒckelungsbetrag“ einfach als „StĂŒckelung“ bezeichnen.

Wir verwenden den Begriff „MĂŒnze“, um sich auf eine bestimmte Instanz einer Denomination zu beziehen.

###Unser erster Konfessionsansatz

Hinweis: Code ist hier.

AnfĂ€nglich haben wir einen „transaktionsfĂ€higen Betrag“ als 128-Bit-Ganzzahl (u128) definiert.

Wir haben dann eine Reihe von Denominationen basierend auf Zehnerpotenzen definiert, zB:

aufzÀhlen {
    Eins, Zwei, Drei, Vier, FĂŒnf, Sechs, Sieben, Acht, Neun,
    Zehn, Zwanzig, Dreißig, Vierzig, FĂŒnfzig, Sechzig, Siebzig, Acht, Neunzig,
    Hundert, Zweihundert, Dreihundert, Vierhundert, FĂŒnfhundert, Sechshundert, Siebenhundert, Achthundert, Neunhundert,
    Tausend, Zweitausend, Dreitausend, Viertausend, FĂŒnftausend, Sechstausend, Siebentausend, Achttausend, Neuntausend,
    Zehntausend, zwanzigtausend, dreißigtausend, vierzigtausend, fĂŒnfzigtausend, sechzigtausend, siebzigtausend, achtzigtausend, neunzigtausend
}

Und so weiter, bis zu 10^38, was sich der Grenze eines u128 nÀhert. Die Gesamtzahl der Konfessionen betrug rund 340.

Wir haben uns auch Kurznamen fĂŒr jede Zehnerpotenz ausgedacht, basierend auf Namen großer Zahlen.

tau → tau
mil → mil
bil → bils
tril → tril
quad → quads
quint → quint
sic → sics
Set → Sets
ott → otts
non → nons
det → dets
unt → unts

Die Grundidee ist, dass „One“ die kleinste Einheit darstellt, zum Beispiel wird das Äquivalent in Bitcoin als Satoshi bezeichnet. Wir wĂŒrden ĂŒberhaupt keine (beliebige) Dezimalstelle definieren, sondern der Markt wĂŒrde kurz nach der EinfĂŒhrung entscheiden, welche Einheiten fĂŒr alltĂ€gliche Transaktionen am besten geeignet sind von großen Einheiten zB Sets bis hin zu kleineren Einheiten zB Quads.

Wie auch immer, ein Dezimalpunkt ist nur eine benutzerorientierte (Anzeige) Sache, da der Wert als u128 dargestellt wird. Daher werden wir hier nicht weiter darauf eingehen.

Dieser Ansatz hat einige nette Eigenschaften. Indem wir 1-9 fĂŒr jede Zehnerpotenz definieren, können wir jede Ziffer eines „umsetzbaren Betrags“ mit einer einzelnen MĂŒnze darstellen, oder weniger, wenn Nullen vorhanden sind.

Wenn wir zum Beispiel den „transaktionsfĂ€higen Betrag“ 55034 haben, können wir das darstellen mit: 1 FiftyTau, 1 FiveTau, 1 Thirty und 1 Four. Der Betrag hat also 5 Stellen, eine davon ist Null, und wir wechseln ihn mit nur 4 MĂŒnzen.

Dieser Ansatz hat auch einige Nachteile.

  1. Der erste ist etwas unbedeutend. Der Code zum Implementieren einer Enumeration mit mehr als 340 Varianten und zugeordneten Namen ist riesig und schwer zu warten. Am Ende haben wir ein Skript geschrieben, um die Quellcodedatei denominations.rs zu generieren. Dies war zwar praktikabel, aber eine ungeschickte, umstÀndliche Lösung.

  2. große Anzahl von WechselgeldmĂŒnzen. In unseren Tests betrug die durchschnittliche Anzahl von MĂŒnzen, die erforderlich war, um Wechselgeld fĂŒr zufĂ€llig generierte u128 „umsetzbare BetrĂ€ge“ zu tĂ€tigen, 38-39. Und das ist fĂŒr eine einzige logische Ausgabe. Denken Sie daran, dass eine typische Neuauflage zwei logische AusgĂ€nge hat, vielleicht mehr. Im Durchschnitt könnten wir also mehr als 76 Ausgabe-DBCs pro Neuauflage und eine vergleichbare Anzahl von Eingaben betrachten. Das ist eine Menge Arbeit fĂŒr die MĂŒnzanstalt und das Netzwerk und bringt die Blind Sig-Implementierung auch einen erheblichen Effizienznachteil im Vergleich zur Amount-Hiding-Implementierung (aber nachvollziehbar) mit sich.

Nehmen wir zum Beispiel u128::MAX:

$ ber. 2^128
        340282366920938463463374607431768211456

Wir haben eine Nennwertvariante fĂŒr jede [0
9] jeder Zehnerpotenz. Diese Zahl hat 40 Stellen. Zwei Ziffern sind Null, wir können sie ignorieren. Wir brauchen also 38 „MĂŒnzen“, um die Zahl darzustellen. Z.B:

3*10^38
4*10^37
2*10^35
8*10^34


und so weiter


Was ist, wenn wir u64 anstelle von u128 verwenden? Nun das istein bisschen besser.

$ ber. 2^64
        18446744073709551616

Aber es sind immer noch 20 Stellen. Und jetzt haben wir nur noch 19 Zehnerpotenzen, mit denen wir arbeiten können, also ist unsere potenzielle Teilbarkeit begrenzter.

Nun könnte man argumentieren, dass Benutzer in der Praxis mehr ganzzahlige BetrĂ€ge mit vielen Nullen senden wĂŒrden. Das scheint jedoch nicht zu stimmen. @mav fĂŒhrte eine Analyse der gesamten Bitcoin-Blockchain durch und stellte fest, dass die meisten TransaktionsbetrĂ€ge eine Genauigkeit von 8 Stellen mit hauptsĂ€chlich Zufallszahlen verwendeten. Wir glauben, dass dies daran liegt, dass die Leute immer noch hauptsĂ€chlich Zahlungen auf der Grundlage von Fiat-BetrĂ€gen (z. B. USD) vornehmen und den entsprechenden BTC-Betrag berechnen, der zu einer Zahl mit vielen signifikanten Stellen wird. Das gleiche Verhalten scheint fĂŒr unsere DBCs zu gelten.

In jedem Fall sollte das System so ausgelegt sein, dass es selbst im schlimmsten Fall ausreichend gut/effizient arbeitet.

Also mussten wir einen besseren Weg finden.

Unser zweiter (aktueller) Ansatz

Wir haben eine einfachere, mÀchtigere Darstellung von Denominationen entwickelt. Wir codieren den Zehnerpotenzen-Exponenten in der Denomination-AufzÀhlung als ganze Zahl mit Vorzeichen. Anstelle der riesigen AufzÀhlung mit 300+ Varianten haben wir also dies:

Pub-Typ PowerOfTen = i8;

pub enum Bezeichnung {
    Eins (PowerOfTen),
    Zwei (PowerOfTen),
    Drei (PowerOfTen),
    Vier (PowerOfTen),
    FĂŒnf (PowerOfTen),
    Sechs (PowerOfTen),
    Sieben (PowerOfTen),
    Acht (PowerOfTen),
    Neun (PowerOfTen),
}

Mit einem i8 können wir also 9*10^-128
9*10^127 darstellen. Denken Sie daran, dass das u128, das bereits als riesig gilt, uns nur 10^38 in Bezug auf die Teilbarkeit lieferte. FĂŒr praktische Zwecke ist diese Darstellung also nahezu grenzenlos. (Wir könnten leicht noch weiter gehen, indem wir einen i16 oder i32 anstelle eines i8 verwenden, aber es scheint ĂŒbertrieben zu sein.)

Anmerkung: Das Folgende ist nicht als Erörterung der geldpolitischen PlÀne des SNT gedacht. Es ist rein hypothetisch zur Veranschaulichung.

Dieser Ansatz fĂŒr den Nennwert macht den Nennwert „Eins“ nicht gleich dem kleinstmöglichen Betrag, wie es bei unserem ersten Ansatz der Fall war. Stattdessen kann „Eins“ unsere beste StartschĂ€tzung darstellen, beispielsweise bei 1 DBC = 1 USD. Wir könnten darauf abzielen, dass „One“ eine gewisse nĂŒtzliche Kaufkraft in Bezug auf reale GĂŒter hat, aber nicht viel. zB Man sollte eine Dose Limonade oder vielleicht einen Kaugummi kaufen, kein Haus.

Es ist auch interessant, darĂŒber nachzudenken, wie unsere gesamte Geldmenge aussehen könnte. Nehmen wir als hypothetischen Ausgangspunkt den Genesis DBC-Betrag, indem wir die aktuelle SNT-Marktkapitalisierung nehmen und einen Genesis-Betrag berechnen, so dass 1 DBC = 1 USD. Ich habe nicht berechnet, wie hoch der Genesis-Betrag mit dieser Methode wĂ€re, aber nehmen wir einfach an, es wĂ€ren 50 Millionen. Ok, also starten wir mit dem Denom One (1*10^0) = ~1 USD und dem Genesis DBC = 50 Millionen. kĂŒhl. Wir werden die Verteilungs-/Farming-Effekte vorerst ignorieren, außer um zu sagen, dass sie die WĂ€hrung vorĂŒbergehend aufblĂ€hen/abwerten könnten.

Ok, dies ist also eine deflationĂ€re WĂ€hrung (mit fester Geldmenge) und mit der Zeit wird jede Einheit in Bezug auf den realen Wert mehr wert (oder das Projekt scheitert wahrscheinlich). Wenn dies geschieht, werden Benutzer allmĂ€hlich dazu ĂŒbergehen, mehr 10^-1-Denoms zu verwenden. dann 10^-2 und so weiter. Wir können 128 solcher 10-fach-Erweiterungen unterbringen. Wir können auch das Senden von 3 Millionen SNT in einer dbc unterbringen, zB indem wir die StĂŒckelung 3*10^6 verwenden. Oder viel, viel, viel mehr, wenn wir zB den Genesis-Betrag viel höher definieren, bis hin zu 9*10^127.


Benennung

Wir hatten uns zuvor einige Namen fĂŒr große Zahlen ausgedacht, aber sie waren etwas umstĂ€ndlich und ungewohnt. Wir haben sie gekĂŒrzt und verĂ€ndert, damit sie aussprechbar sind. Auch deckten sie keine negativen Exponenten ab. Aber keine Sorge, die SI-Skala hat uns abgedeckt, mit Kurznamen, die die Leute bereits meistens kennen.

Die SI-Skala benennt 10^-24 
 10^24. Nun, nicht jede Zehnerpotenz, sondern alle 10^3, was gut genug ist. Wenn wir diese in Code einbinden, können wir Folgendes generieren:

10^-24 -- 1 Yocto
10^-23 -- 10 yocto
10^-22 -- 100 yocto
10^-21 -- 1 zepto
10^-20 -- 10 zepto
10^-19 -- 100 Zepto
10^-18 -- 1 Atto
10^-17 -- 10 Atto
10^-16 -- 100 Atto
10^-15 -- 1 Femto
10^-14 -- 10 Femto
10^-13 -- 100 Femto
10^-12 -- 1 Pico
10^-11 -- 10 Pico
10^-10 -- 100 Pico
10^-9 -- 1 Nano
10^-8 -- 10 Nano
10^-7 -- 100 Nano
10^-6 -- 1 Mikro
10^-5 -- 10 Mikro
10^-4 -- 100 Mikro
10^-3 -- 1 Milli
10^-2 -- 1 Centi
10^-1 -- 1 dezi
1 -- 1
10^1 -- 1 Deka
10^2 -- 1 Hekto
10^3 -- 1 Kilo
10^4 -- 10 Kilo
10^5 -- 100 Kilo
10^6 -- 1 Mega
10^7 -- 10 Mega
10^8 -- 100 Mega
10^9 -- 1 Giga
10^10 -- 10 Giga
10^11 -- 100 Giga
10^12 -- 1 Tera
10^13 -- 10 Tera
10^14 -- 100 Tera
10^15 --1 Peta
10^16 -- 10 Peta
10^17 -- 100 Peta
10^18 -- 1 PrĂŒfung
10^19 -- 10 Beispiele
10^20 -- 100 Beispiele
10^21 -- 1 Zetta
10^22 -- 10 Zetta
10^23 -- 100 Zetta
10^24 -- 1 Jotta
10^25 -- 10 Yotta
10^26 -- 100 Yotta

Wenn wir jemals Konfessionen erreichen, die kleiner als Yocto sind, können wir Namen fĂŒr sie finden. Das ist fĂŒr eine ferne Zukunft. Im Moment gibt es eine Amount::to_si_string()-Funktion, die nur die Exponentendarstellung fĂŒr unbenannte Werte ausspuckt.


Darstellung von transaktionsfÀhigen BetrÀgen

FrĂŒher haben wir einen u128 verwendet, um „umsetzbare BetrĂ€ge“ darzustellen. Aber wie gehen wir mit BetrĂ€gen um, wenn unsere neue Denomination-AufzĂ€hlung Werte zulĂ€sst, die viel grĂ¶ĂŸer sind als u128 (10^38), und sie können auch negative Exponenten sein, d. h. Zehntel, Hundertstel, Tausendstel usw.?

Okay, hier wird es etwas knifflig.

Wir haben sn_dbc::Amount von einem u128-Alias ​​in Folgendes geĂ€ndert:

Pub-Typ PowerOfTen = i8;
Pub-Typ AmountCounter = u32;

pub struct Betrag {
    Kneipenanzahl: AmountCounter,
    Pub-Einheit: PowerOfTen,
}

Hinweis: Dies kann in Zukunft in „TransactableAmount“ umbenannt werden.

Mit dieser Struktur können wir GeldbetrĂ€ge als Zehnerpotenz (die einen einzelnen Nennwert oder MĂŒnze darstellt) plus eine ZĂ€hlung darstellen, die die Anzahl dieser MĂŒnzen darstellt.

AmountCounter ist ein u32, daher können wir weit ĂŒber eine Milliarde jeder StĂŒckelung darstellen. Derzeit begrenzen wir es auf genau 1 Milliarde (10^9).

Wir sind zu dieser Zahl gekommen, indem wir ĂŒber typische Transaktionen heute nachgedacht haben. Einzelpersonen leisten regelmĂ€ĂŸig Barzahlungen von bis zu einigen tausend Dollar, kaufen ein Haus fĂŒr eine Million Dollar usw. Aber 100 Millionen tx sind ziemlich selten. Und Milliarden-Dollar-Tx sind sehr selten – wir sprechen von riesigen Konzernen und Regierungen. Wir wollten vermeiden, dass Menschen gezwungen werden, ihre (mentale) Preiseinheit fĂŒr regulĂ€re Transaktionen zu Ă€ndern. Aber wenn wir eine Differenz von 10^9 Einheiten erreichen, sind wir irgendwie in einer anderen finanziellen Liga.

Eine andere Denkweise ist, dass, wenn Sally 1 Milliarde USD sendet, es ihr wahrscheinlich egal ist, ob sie keine 1-Dollar-Schritte verwenden kann. Sally konnte 1 Milliarde + 10 neu ausgeben, aber sie konnte nicht 1 Milliarde + 1 (oder 2, 3, 4
) neu ausgeben. Damit könnte Sally wohl leben. Wenn wir hingegen das Limit auf 100 setzen und sie nur 110, 120, aber nicht 101, 102 neu auflegen könnte, könnte das fĂŒr sie und die meisten Leute ein grĂ¶ĂŸeres Problem sein.

Denken Sie jetzt daran, dass die Anzahl der Ziffern des Betrags die maximale Anzahl der erforderlichen WechselgeldmĂŒnzen definiert. Indem wir also 1 Milliarde als unser Limit verwenden, sind wir von 40 MĂŒnzen auf 9 (max.) gesunken. Ziemlich gut!

Wir könnten das weiter fallen lassen. 1 Million = 10^6 oder sechs MĂŒnzen. Das könnte eine vernĂŒnftige Wahl sein. 1 Million ist immer noch eine ziemlich hohe Zahl fĂŒr das tĂ€gliche Senden. Wir könnten weiter nach unten gehen, mit dem Nachteil, dass die Leute anfangen mĂŒssen, Mengen/Preise mit höheren Einheiten anzugeben.

Diese counter_limit()-Funktion ist also ein Drehknopf, den wir drehen können, um die Systemeffizienz und die GranularitĂ€t der ‚umsetzbaren BetrĂ€ge‘ auszubalancieren. Leistungstests können/werden uns hier fĂŒhren, wenn wir ein bisschen weiter kommen.


Berechnung mit Betrag

Es ist wichtig, im Voraus zu beachten, dass Amount immer noch nur ganzzahlige Mathematik verwendet. Es sind keine Gleitkommazahlen beteiligt.

Die MĂŒnzprĂ€geanstalt muss ĂŒberprĂŒfen, ob Summe(EingĂ€nge) == Summe(AusgĂ€nge). Wir haben einige mathematische Operatoren implementiert: check_sub(), check_add() und check_sum(). Diese funktionieren, indem sie BetrĂ€ge in eine gemeinsame Basiseinheit umwandeln und dann deren Anzahl addieren oder subtrahieren. Das Ergebnis jeder Operation ist entweder ein Betrag oder Error::AmountIncompatible. BetrĂ€ge sind nicht kompatibel, wenn die Einheiten zu weit auseinander liegen, um die Anzahl in Amount::counter_max() (1 Milliarde) darzustellen.

Amount macht die regulĂ€ren ungeprĂŒften Add-, Sub-, Sum-Operatoren ĂŒberhaupt nicht verfĂŒgbar, daher ist es unmöglich, ungeprĂŒfte Operationen auszufĂŒhren. Auch der RĂŒckgabewert ist ein Ergebnis, keine Option wie bei eingebauten Typen.

Der Mint-Code ruft jetzt Amount::checked_sum() anstelle von sum() auf. Mit dieser einfachen Änderung erzwingt die MĂŒnzprĂ€geanstalt nun, dass alle Ein- und AusgĂ€nge kompatibel sein mĂŒssen, sonst schlĂ€gt die Neuausgabe fehl.

Es ist auch möglich, einen Betrag in eine rationale Zahl und zurĂŒck umzuwandeln. Dies wurde implementiert, kommt aber in eine separate Kiste, da es fĂŒr Mint- oder Client-Operationen nicht erforderlich ist.

Auswirkungen auf die Verwendung von Eingaben

Die 10^9 „NĂ€hegrenze“ fĂŒr BetrĂ€ge gilt sowohl fĂŒr Eingaben als auch fĂŒr Ausgaben bei einer Neuauflage.

EingĂ€nge und AusgĂ€nge werden jedoch getrennt summiert. So könnte es sein, dass ein einzelner Input und Output fĂŒr sich genommen nicht kompatibel wĂ€ren, die Summe der Inputs und die Summe der Outputs aber dennoch gleich sind. Hier ist ein Beispiel dafĂŒr:

EingÀnge:
    9*10^8, 1*10^8, 9*10^0, 1*10^0
AusgÀnge:
    1*10^9,1*10^1

$ ber. 9*10^8+1*10^8+9*10^0+1*10^0
        1000000010
$ Berech. 1*10^9+1*10^1
        1000000010

Damit die Neuauflage gelingen wĂŒrde.

Trotzdem schrĂ€nkt die NĂ€herungsgrenze ein, dass Eingaben und Ausgaben nicht zu weit voneinander entfernt sein dĂŒrfen, insbesondere wenn wir imbegrenzen die Anzahl der Ein- und AusgĂ€nge. Somit kann man es sich Ă€hnlich wie das (unscharfe) Staublimit vorstellen in Bitcoin, außer dass es bei der Neuauflage immer relativ zu den anderen BetrĂ€gen ist, sodass es nirgendwo eine feste Grenze gibt, was erfreulich ist. :wink:

Diese Nahgrenze sollte Menschen dazu anregen, mit anderen unter Verwendung der am hĂ€ufigsten verwendeten Konfessionen GeschĂ€fte zu machen. Weil die MĂŒnzstĂ€tte mir nicht erlauben wĂŒrde, Sie fĂŒr eine Soda mit einem One DBC plus einem 1 Pico DBC (10^-12) zu bezahlen. Wir erzwingen derzeit keine maximale Anzahl von Eingabe-DBCs fĂŒr eine Neuauflage, aber das wĂ€re auch zu berĂŒcksichtigen, was es unmöglich machen wĂŒrde, mit Hunderten oder Tausenden winziger MĂŒnzen statt mit einigen vernĂŒnftigen MĂŒnzen zu bezahlen.


Abschließende Gedanken

Die Tatsache, dass unser ursprĂŒnglicher StĂŒckelungsansatz eine große Anzahl von MĂŒnzen erfordert, um willkĂŒrliche BetrĂ€ge darzustellen, war ein schwerwiegender Nachteil, der behoben werden musste, damit eine blinde MĂŒnzprĂ€geanstalt eine Chance hat, annĂ€hernd so effizient zu sein wie eine nicht blinde MĂŒnzprĂ€geanstalt.

Dieses neue Design ist eine Verbesserung gegenĂŒber dem ursprĂŒnglichen Nennwertsystem in Bezug auf Effizienz, Klarheit und (wohl) Code-Einfachheit.

Auch wenn das TransactableAmount-Konzept auf den ersten Blick ungewöhnlich erscheinen mag, sollte es fĂŒr die Benutzer weitgehend transparent sein. AnfĂ€nglich wĂ€ren alle TransaktionsbetrĂ€ge unter 1 Milliarde DBC einfach als ganze Zahl ausdrĂŒckbar (unter Verwendung der Basis 10^0). Nur wenn man diesen Betrag ĂŒberschreitet oder unter 1 DBC fallen muss, muss man eine andere Einheit wĂ€hlen, um den Betrag auszudrĂŒcken, und die Wallet-Software könnte dies automatisch tun.

Tiefe Teilbarkeit ist eine schöne Eigenschaft, die winzige Mikrozahlungen ermöglicht, und etwas, das dieses Design als eine Art glĂŒcklicher Zufall liefert. Die Teilbarkeit von 128 Stellen ist enorm, und wir könnten mit einem i16 noch viel weiter gehen, wenn wir wollten. Im Vergleich dazu hat Bitcoin 8 Dezimalstellen der Teilbarkeit und die meisten KryptowĂ€hrungen sind heute Ă€hnlich. 12 Nachkommastellen gelten als groß.

Die Nahgrenze ist ein neuartiges Konzept, das dazu beitragen soll, Staub zu minimieren und die FungibilitĂ€t zu erhöhen, ohne dass eine Staubgrenze mit fester GrĂ¶ĂŸe erforderlich ist. Es ist auch ein Knopf, den wir leicht drehen können, um zwischen Effizienz und Transaktionsmenge-GranularitĂ€t abzustimmen.

Wer an weiteren Details interessiert ist, kann den Quellcode lesen. number.rs enthĂ€lt einen ausfĂŒhrlichen Kommentar/ErklĂ€rung.

Code:


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!