Actualités du développement Safe 🇫🇷 21 octobre 2021

Dimitar · Novembre 7, 2021, 10:25

Ceci est une traduction automatique. L’original en anglais est ici: Update 21 October, 2021

Pourquoi utiliser des coupures fixes dans une monnaie numérique alors que vos paiements pourraient utiliser des montants arbitraires ? Après tout, nous parlons ici de chiffres, pas de morceaux de métal et de bouts de papier. La réponse est la confidentialité. Si vous effectuez une transaction 4589234127 SNT, ce chiffre est très probablement unique et donc traçable.

Cependant, même si l’on accepte les dénominations comme moyen de mutualiser l’anonymat, se pose aussi la question de l’efficacité. Un petit nombre de dénominations possibles (disons 1 et 10) rendrait les transactions extrêmement difficiles à relier et maximiserait la fongibilité, mais au prix d’un travail supplémentaire inacceptable pour le réseau.

L’étude de @mav sur les transactions bitcoin montre qu’une granularité de 8 décimales significatives est courante, probablement parce que les paiements Btc sont calculés sur la base des devises fiduciaires et soumis au taux de change. Ce sera la même chose pour SNT, nous ne pouvons donc pas nous attendre à des montants parfaitement égaux.

L’équipe a mis au point une approche du juste milieu qui permet une divisibilité massive, s’accorde avec les transactions du monde réel et ne devrait pas exercer de pression excessive sur les monnaies.

C’est un résumé. Pour ceux qui veulent approfondir, @danda expose ci-dessous notre pensée actuelle dans toute sa splendeur mathématique.

Progrès général

@chriso a travaillé dur pour fusionner l’api et le cli. Du point de vue du code, tout est dedans, mais la fusion de ces dépôts nous a obligés à adapter nos flux d’intégration continue et de remplacement de version. Des solutions acceptables ont été trouvées, ce qui devrait signifier que chaque version de safe_network aura toutes les caisses attachées, mais avec leurs propres versions distinctes (notre ancien flux aurait signifié une seule version, et beaucoup de confusion probable là-bas). Alors maintenant, il travaille à la mise en œuvre de ces changements.

@Chris.Connelly a continué à fouiller dans qp2p et a confirmé que l’envoi de nombreux messages entre deux nœuds est beaucoup plus rapide sur une seule connexion que sur de nombreuses connexions. Cela découle de l’utilisation de TLS par QUIC, ce qui signifie que chaque connexion doit exécuter un protocole de prise de contact. Heureusement, QUIC prend également en charge de nombreux flux logiquement indépendants sur une seule connexion, il n’y a donc pas de réel inconvénient ici – moins de connexions, moins de problèmes. Cela informera les dernières étapes de la suppression du pool de connexions de qp2p, où nous devrons prendre certaines précautions pour nous assurer que nous sommes toujours efficaces avec les connexions.

@Lionel.Faber a travaillé sur l’amélioration du processus de déploiement des testnets sur Digital Ocean, avec une approbation désormais requise pour chaque étape du déploiement et de la suppression du testnet, nous permettant de redémarrer chaque étape ou d’utiliser le testnet en externe au lieu de le détruire automatiquement. .

Nous avons également affiné le démarrage nœud/client. Avec @yogesh implémentant l’écriture du préfixe du réseau sur le disque, de sorte qu’il puisse être partagé, et ainsi les clients et les nœuds peuvent commencer avec un minimum de connaissances en réseau. Et nous avons ajouté et amélioré certaines inspections des journaux locaux pour pouvoir identifier et localiser plus facilement les problèmes.

Bonne nouvelle des labos DBC. Spentproofs fonctionne maintenant dans l’environnement de test et devrait être prêt à fusionner bientôt.

Contexte des dénominations

Un DBC Mint utilisant des signatures aveugles est incapable de voir le contenu d’un DBC de sortie avant de le signer, mais il doit vérifier que sum(inputs) == sum(outputs). La Monnaie ne peut pas faire confiance à la partie émettrice pour spécifier un montant avec la sortie car cela pourrait être un mensonge. Des schémas d’engagement sont possibles mais les rééditions qui en résultent deviennent associables, allant à l’encontre de l’objectif des signatures aveugles.

Une solution consiste donc pour la Monnaie à traiter chaque DBC signé avec une clé donnée comme étant égal à chaque autre DBC signé avec la même clé. En prolongeant cela, nous pouvons définir un ensemble de dénominations fixes, chacune avec une clé de signature unique. La dérivation de clé nous permet d’avoir une seule clé de menthe, mais de dériver de manière déterministe une clé de dénomination en utilisant la dénomination elle-même comme indice de dérivation. Cela signifie que nous pourrions aller jusqu’à avoir une dénomination unique pour chaque valeur possible d’un u128 !

Mais il s’avère que cela serait très mauvais pour la confidentialité et la fongibilité. Des montants uniques comme 4589234127 permettent de lier une réédition à une autre. Pensez à l’argent liquide un instant. En USD, nous payons en coupures papier de 1,2,5,10,50,100. Et aussi des pièces : .01, .05, .10, .25, .50. Lorsque vous achetez quelque chose avec un prix de 365,23 $, vous pouvez payer avec trois 100, un 50, un 10, un 5, deux .20 et trois .01. Chacun de ces billets ou pièces est très difficile à associer à d’autres transactions, car de nombreuses autres personnes utilisent exactement les mêmes montants. Pourtant, si vous pouviez produire une facture papier d’une valeur de 365,23, eh bien, c’est assez unique et fait que votre facture se démarque vraiment.

Par conséquent, nous pouvons dire que chaque dénomination représente un ensemble d’anonymat, ou un pool dans lequel votre transaction peut se cacher. Plus nous avons de dénominations (ou pools), plus chaque pool est petit. Donc, en termes de confidentialité/fongibilité, nous viserions le plus petit nombre possible de pools, ce qui est en fait1, c’est-à-dire la plus petite unité disponible.

Cependant, nous devons également considérer l’efficacité. Ceci est mesuré par le nombre de « pièces » (billets ou pièces) nécessaires pour rendre la monnaie pour un montant donné. En utilisant notre exemple de prix USD de 365,23 $, nous avions besoin de 11 pièces individuelles. De plus, considérez que dans une réémission DBC typique, il y aura deux montants de sortie logiques : 1 : le paiement du destinataire et 2 : le changement pour l’expéditeur. La création, la signature et la validation des pièces DBC représentent du travail pour les nœuds de la monnaie et un trafic réseau important implique également la dépense de chaque DBC. Nous devons donc essayer de minimiser le nombre de pièces de monnaie requises pour tout montant transactionnel.

Il devient donc clair qu’il existe une tension entre l’optimisation de la fongibilité et l’optimisation de l’efficacité. La fongibilité optimale serait de n’avoir qu’une seule dénomination. L’efficacité optimale serait d’avoir une dénomination unique pour chaque montant possible.

Montants négociables vs dénominations

Lorsque l’on pense aux coupures, nous devons faire attention à faire la distinction entre les « montants négociables » et les « montants des coupures ».

Un « montant négociable » est un prix ou un montant de paiement qui est en cours de transaction. Un ou plusieurs montants de dénomination peuvent être combinés/ajoutés pour former un « montant négociable ».

À l’avenir, nous appellerons simplement « dénomination » le « montant de la dénomination ».

Nous utiliserons le terme « pièce » pour désigner une instance particulière d’une dénomination.

Notre approche des premières dénominations

Remarque : le code est ici.

Initialement, nous avons défini un « montant négociable » comme un entier de 128 bits (u128).

Nous avons ensuite défini une série de dénominations basées sur des puissances de dix, par exemple :

enum {
    Un, deux, trois, quatre, cinq, six, sept, huit, neuf,
    Dix, vingt, trente, quarante, cinquante, soixante, soixante-dix, huit, quatre-vingt-dix,
    Cent, deux cents, trois cents, quatre cents, cinq cents, six cents, sept cents, huit cents, neuf cents,
    Mille deux mille trois mille quatre mille cinq mille six mille sept mille huit mille neuf mille
    Dix mille, vingt mille, trente mille, quarante mille, cinquante mille, soixante mille, soixante-dix mille, quatre-vingts mille, quatre-vingt-dix mille
}

Et ainsi de suite, jusqu’à 10^38, ce qui approche la limite d’un u128. Le nombre total de dénominations était d’environ 340.

Nous avons également proposé des noms abrégés pour chaque puissance de dix, sur la base des noms des grands nombres.

tau → taus
mil → mils
bil → bil
tril → trils
quad → quad
quinte → quintes
sic → sics
ensemble → ensembles
ott → ott
non → non
det → det
unt → unt

L’idée de base est que « One » représente la plus petite unité, par exemple, l’équivalent en bitcoin est appelé Satoshi. Nous ne définirions pas du tout un emplacement de point décimal (arbitraire), mais le marché déciderait plutôt quel est le bon ensemble d’unités à utiliser pour les transactions quotidiennes peu de temps après le lancement, et au fil du temps, à mesure que la «capitalisation boursière» augmente, cela progresserait. des grandes unités, par exemple des ensembles, aux unités plus petites, par exemple des quads.

Quoi qu’il en soit, un point décimal n’est qu’un élément (affichage) destiné à l’utilisateur, car la valeur est représentée par un u128. Nous n’en discuterons donc pas davantage ici.

Cette approche a quelques propriétés intéressantes. En définissant 1-9 pour chaque puissance de dix, nous pouvons représenter chaque chiffre d’un « montant négociable » avec une seule pièce, ou moins s’il y a des zéros.

Par exemple, si nous avons le « montant négociable » 55034, nous pouvons le représenter avec : 1 CinquanteTau, 1 CinqTau, 1 Trente et 1 Quatre. Le montant a donc 5 chiffres, l’un d’eux est zéro, et nous le changeons avec seulement 4 pièces.

Cette approche présente également quelques inconvénients.

Le premier est quelque peu mineur. Le code pour implémenter une énumération avec plus de 340 variantes et noms mappés est énorme et difficile à maintenir. Nous avons fini par écrire un script pour générer le fichier de code source denominations.rs. Bien que réalisable, c’était une solution maladroite et maladroite.
grand nombre de pièces de monnaie. Dans nos tests, le nombre moyen de pièces nécessaires pour rendre la monnaie pour les « montants négociables » générés aléatoirement u128 était de 38 à 39. Et c’est pour une seule sortie logique. N’oubliez pas qu’une réédition typique aura deux sorties logiques, peut-être plus. Ainsi, en moyenne, nous pourrions envisager plus de 76 DBC de sortie par réédition et un nombre comparable d’entrées. C’est beaucoup de travail pour la monnaie et le réseau, et cela met également l’implémentation Blind Sig dans une situation très désavantageuse en termes d’efficacité par rapport à l’implémentation Amount Hiding (mais traçable).

Par exemple, utilisons u128::MAX :

$ calc 2^128
        340282366920938463463374607431768211456

Nous avons une variante de dénomination pour chaque [0…9] de chaque puissance de dix. Il y a 40 chiffres dans ce numéro. Deux chiffres sont nuls, nous pouvons les ignorer. Nous avons donc besoin de 38 « pièces » pour représenter le nombre. Par exemple:

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

…etc…

Et si nous utilisions u64 au lieu de u128 ? Eh bien, c’estun peu mieux.

$ calc 2^64
        18446744073709551616

Mais c’est toujours 20 chiffres. Et maintenant, nous n’avons que 19 puissances de dix avec lesquelles travailler, notre divisibilité potentielle est donc plus limitée.

Maintenant, on pourrait soutenir qu’en pratique, les utilisateurs choisiraient d’envoyer davantage de nombres entiers avec beaucoup de zéros. Cependant, cela semble ne pas être vrai. @mav a effectué une analyse de l’ensemble de la blockchain bitcoin et a constaté que la plupart des montants de transaction utilisaient 8 chiffres de précision avec principalement des nombres aléatoires. Nous pensons que cela est dû au fait que les gens effectuent encore principalement des paiements sur la base de montants fiduciaires (par exemple, USD) et calculent le montant équivalent en BTC, qui devient un nombre avec de nombreux chiffres significatifs. Le même comportement semble s’appliquer à nos DBC.

Dans tous les cas, le système doit être conçu de telle sorte qu’il fonctionne de manière adéquate/efficace, même dans le pire des cas.

Nous avons donc dû trouver un meilleur moyen.

Notre deuxième approche (actuelle)

Nous avons proposé une représentation plus simple et plus puissante des dénominations. Nous codons l’exposant puissance de dix dans l’énumération Denomination sous la forme d’un entier signé. Ainsi, au lieu de l’énumération énorme avec plus de 300 variantes, nous avons ceci :

type de pub PowerOfTen = i8 ;

pub enum Dénomination {
    Un (PowerOfTen),
    Deux (PowerOfTen),
    Trois (PowerOfTen),
    Quatre (PowerOfTen),
    Cinq (PowerOfTen),
    Six (PowerOfTen),
    Sept (PowerOfTen),
    Huit (PowerOfTen),
    Neuf (PowerOfTen),
}

Donc avec un i8, on peut représenter 9*10^-128…9*10^127. Rappelez-vous que le u128, qui est déjà considéré comme énorme, ne nous a donné que 10^38, en termes de divisibilité. Donc, à des fins pratiques, cette représentation est presque illimitée. (Nous pourrions facilement aller encore plus loin en utilisant un i16 ou un i32 au lieu d’un i8, mais cela semble exagéré.)

remarque : ce qui suit ne se veut pas une discussion sur les plans de politique monétaire de la SNT. C’est purement hypothétique à des fins d’illustration.

Cette approche des dénominations ne rend pas la dénomination « Un » égale au montant le plus petit possible, contrairement à notre première approche. Au lieu de cela, « Un » peut représenter notre meilleure estimation de départ à, par exemple, 1 DBC = 1 USD. Nous pourrions viser à ce que « One » ait un certain pouvoir d’achat utile en termes de biens du monde réel, mais pas beaucoup. par exemple, « On » devrait acheter une canette de soda ou peut-être une boule de gomme, pas une maison.

Il est également intéressant de réfléchir à ce que pourrait être notre masse monétaire totale. Comme point de départ hypothétique, disons que nous obtenons le montant Genesis DBC en prenant la capitalisation boursière SNT actuelle et en calculant un montant Genesis tel que 1 DBC = 1 USD. Je n’ai pas calculé ce que serait le montant de Genesis par cette méthode, mais faisons comme si c’était 50 millions. Ok, donc nous lançons avec le dénominateur One (1*10^0) = ~1 USD et le Genesis DBC = 50 millions. frais. Nous allons ignorer les effets distribution/agriculture pour le moment, sauf pour dire qu’ils pourraient temporairement gonfler/dévaluer la devise.

D’accord, il s’agit donc d’une monnaie déflationniste (une masse monétaire fixe) et au fil du temps, chaque unité gagne en valeur en termes de valeur réelle (sinon le projet échoue probablement). Au fur et à mesure que cela se produit, les utilisateurs passeront progressivement à l’utilisation de plus de denoms 10^-1. puis 10^-2, et ainsi de suite. Nous pouvons accueillir 128 de ces extensions 10x. Nous pouvons également accepter l’envoi de 3 millions de SNT dans un dbc, par exemple en utilisant la dénomination 3*10^6. Ou beaucoup, beaucoup, beaucoup plus que cela, si nous définissons par exemple le montant Genesis comme étant beaucoup plus élevé, jusqu’à 9*10^127.

Dénomination

Nous avions déjà trouvé des noms pour les grands nombres mais ils étaient un peu maladroits et inconnus. Nous nous sommes retrouvés à les raccourcir et à les modifier pour qu’ils soient prononçables. De plus, ils ne couvraient aucun exposant négatif. Mais ne vous inquiétez pas, l’échelle SI nous couvre, avec des noms courts que les gens connaissent déjà pour la plupart.

L’échelle SI nomme 10^-24 … 10^24. Eh bien, pas toutes les puissances de dix, mais toutes les 10^3, ce qui est assez bon. Lorsque nous les insérons dans le code, nous pouvons générer :

10^-24 -- 1 an
10^-23 -- 10 ans
10^-22 -- 100 yo
10^-21 -- 1 zepto
10^-20 -- 10 zeptos
10^-19 -- 100 zeptos
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 picos
10^-10 -- 100 picos
10^-9 -- 1 nano
10^-8 -- 10 nano
10^-7 -- 100 nano
10^-6 -- 1 micro
10^-5 -- 10 micro
10^-4 -- 100 microns
10^-3 -- 1 millième
10^-2 -- 1 centi
10^-1 -- 1 déci
1 -- 1
10^1 -- 1 déca
10^2 -- 1 hecto
10^3 -- 1 kilo
10^4 -- 10 kilos
10^5 -- 100 kilos
10^6 -- 1 méga
10^7 -- 10 méga
10^8 -- 100 méga
10^9 -- 1 giga
10^10 -- 10 giga
10^11 -- 100 giga
10^12 -- 1 téra
10^13 -- 10 téra
10^14 -- 100 téra
10^15 --1 péta
10^16 -- 10 péta
10^17 -- 100 péta
10^18 -- 1 exemple
10^19 -- 10 exemples
10^20 -- 100 exa
10^21 -- 1 zetta
10^22 -- 10 zetta
10^23 -- 100 zetta
10^24 -- 1 yotta
10^25 -- 10 yotta
10^26 -- 100 yotta

Si jamais nous atteignons des dénominations plus petites que le yocto, nous pourrons leur trouver des noms. C’est pour un avenir lointain. Pour l’instant, il existe une fonction Amount::to_si_string() qui ne fait que recracher la représentation de l’exposant pour les valeurs sans nom.

Représentation des montants négociables

Auparavant, nous utilisions un u128 pour représenter les « montants négociables ». Mais comment traiter les montants lorsque notre nouvelle énumération Denomination autorise des valeurs beaucoup plus grandes que u128 (10^38), et qu’elles peuvent également être des exposants négatifs, c’est-à-dire des dixièmes, centièmes, millièmes, etc.

Ok, donc c’est là que les choses se compliquent un peu.

Ce que nous avons fait est de changer sn_dbc::Amount d’un alias u128 en :

type de pub PowerOfTen = i8 ;
type de pub AmountCounter = u32;

montant de la structure de pub {
    nombre de pubs : AmountCounter,
    unité de pub : PowerOfTen,
}

remarque : ce nom peut être renommé « TransactableAmount » à l’avenir.

Avec cette structure, nous pouvons représenter les montants monétaires sous la forme d’une puissance de dix (représentant une seule coupure ou pièce) plus un compte, représentant le nombre de ces pièces.

AmountCounter est un u32, nous pouvons donc représenter bien plus d’un milliard de comptes de n’importe quelle dénomination. Actuellement, nous le limitons à exactement 1 milliard (10^9).

Nous sommes arrivés à ce chiffre en pensant aux transactions typiques d’aujourd’hui. Les particuliers font régulièrement des versements en espèces jusqu’à quelques milliers de dollars, achètent une maison pour un million de dollars, etc. Mais 100 millions de tx sont assez rares. Et les milliards de dollars de taxes sont très rares - nous parlons d’énormes sociétés et gouvernements. Nous voulions éviter de forcer les gens à changer leur unité de tarification (mentale) pour les transactions régulières. Mais au moment où nous arrivons à une différence de 10^9 dans les unités, nous sommes en quelque sorte dans une ligue financière différente.

Une autre façon de penser est que si Sally envoie 1 milliard de dollars, elle se fiche probablement de ne pas pouvoir utiliser des incréments de 1 dollar. Sally pouvait réémettre 1 milliard + 10, mais elle ne pouvait pas réémettre 1 milliard + 1 (ou 2, 3, 4…). Sally pourrait probablement vivre avec ça. Alors que si nous fixions la limite à 100, et qu’elle ne pouvait rééditer que 110, 120, mais pas 101, 102, cela pourrait être plus un problème pour elle… et la plupart des gens.

Rappelez-vous maintenant que le nombre de chiffres du montant définit le nombre maximum de pièces de monnaie requises. Ainsi, en utilisant 1 milliard comme limite, nous sommes passés de 40 pièces de monnaie à 9 (max). Assez bien!

Nous pourrions laisser tomber cela plus loin. 1 million = 10^6, ou six pièces. Cela pourrait être un choix raisonnable. 1 million est encore un nombre assez élevé pour les tx quotidiens. Nous pourrions continuer à baisser, le compromis étant que les gens doivent commencer à spécifier des montants/prix en utilisant des unités plus élevées.

Donc, cette fonction counter_limit() est un bouton que nous pouvons tourner pour équilibrer l’efficacité du système et la granularité des « montants négociables ». Les tests de performance peuvent/seront nous guider ici au fur et à mesure que nous avancerons un peu plus loin.

Calculer avec le montant

Il est important de noter d’emblée que Amount n’utilise toujours que des calculs entiers. Aucune virgule flottante n’est impliquée.

La Monnaie doit vérifier que sum(inputs) == sum(outputs). Nous avons implémenté quelques opérateurs mathématiques : check_sub(), check_add() et check_sum(). Ceux-ci fonctionnent en convertissant les montants en une unité de base commune, puis en ajoutant ou en soustrayant le nombre de chacun. Le résultat de chaque opération est soit un Montant, soit une Erreur::MontantIncompatible. Les montants sont incompatibles si les unités sont trop éloignées les unes des autres pour que le nombre soit représenté dans Amount::counter_max() (1 milliard).

Amount n’expose pas du tout les opérateurs Add, Sub, Sum non contrôlés réguliers, il est donc impossible d’effectuer des opérations non contrôlées. De plus, la valeur de retour est un résultat, pas une option comme avec les types intégrés.

Le code Mint appelle maintenant Amount::checked_sum() au lieu de sum(). Avec ce simple changement, la Monnaie impose désormais que toutes les entrées et sorties doivent être compatibles, sinon la réédition échoue.

Il est également possible de convertir un montant en nombre rationnel, et inversement. Cela a été implémenté, mais ira dans une caisse séparée, car ce n’est pas nécessaire pour les opérations de Mint ou du client.

Implications pour l’utilisation des entrées

La « limite de proximité » de 10^9 pour les montants s’applique à la fois aux entrées et aux sorties d’une réédition.

Cependant, les entrées et les sorties sont additionnées séparément. Ainsi, il se pourrait qu’une entrée et une sortie individuelles ne soient pas compatibles par elles-mêmes, mais la somme des entrées et la somme des sorties sont toujours égales. Voici un exemple de ceci :

contributions:
    9*10^8, 1*10^8, 9*10^0, 1*10^0
les sorties:
    1*10^9,1*10^1

$ calc 9*10^8+1*10^8+9*10^0+1*10^0
        1000000010
$ calc 1*10^9+1*10^1
        1000000010

Donc cette réédition réussirait.

Même encore, la limite de proximité contraint que les entrées et les sorties ne peuvent pas être trop éloignées, surtout si nous imlimitent le nombre d’entrées et de sorties. Ainsi, il peut être considéré comme similaire à la (floue) limite de poussière en bitcoin, sauf qu’il est toujours relatif aux autres montants de la réémission, il n’y a donc aucune limite fixe nulle part, ce qui est agréable.

Cette limite de proximité devrait inciter les gens à effectuer des transactions avec d’autres en utilisant les dénominations les plus couramment utilisées. Parce que la menthe ne me permettrait pas de vous payer un Soda avec un One DBC plus un 1 Pico DBC (10^-12). Nous n’appliquons actuellement aucun nombre maximal de DBC d’entrée à une réémission, mais ce serait également quelque chose à considérer, ce qui rendrait impossible le paiement avec des centaines ou des milliers de minuscules pièces, au lieu de quelques pièces de taille raisonnable.

Réflexions finales

Le fait que notre approche de dénomination originale nécessite un grand nombre de pièces pour représenter des montants arbitraires était un inconvénient sérieux qu’il était nécessaire de corriger pour qu’un atelier de monnaie aveugle ait une chance d’être aussi efficace qu’un atelier sans aveugle.

Cette nouvelle conception est une amélioration par rapport au système de dénomination d’origine, en termes d’efficacité, de clarté et (sans doute) de simplicité du code.

Bien que le concept TransactableAmount puisse sembler inhabituel à première vue, il devrait être principalement transparent pour les utilisateurs. Initialement, tous les montants de transaction inférieurs à 1 milliard de DBC seraient simplement exprimables sous forme d’entier (en utilisant la base 10^0). Ce n’est que si l’on dépasse ce montant ou doit descendre en dessous de 1 DBC, alors il faut choisir une unité différente pour exprimer le montant, et le logiciel de portefeuille pourrait le faire automatiquement.

La divisibilité profonde est une propriété intéressante qui permet de minuscules micropaiements, et quelque chose que cette conception offre comme une sorte d’heureux accident. 128 chiffres de divisibilité, c’est énorme, et on pourrait aller beaucoup plus loin avec un i16 si on le souhaitait. En comparaison, le bitcoin a 8 chiffres décimaux de divisibilité et la plupart des crypto-monnaies d’aujourd’hui sont similaires. 12 décimales est considérée comme grande.

La limite de proximité est un nouveau concept qui devrait aider à minimiser la poussière et à augmenter la fongibilité sans nécessiter de limite de poussière de taille fixe. C’est également un bouton que nous pouvons facilement tourner pour régler entre l’efficacité et la granularité transactableamount.

Toute personne intéressée par plus de détails peut lire le code source. montant.rs contient un long commentaire/explication.

code:

Liens utiles

N’hésitez pas à répondre ci-dessous avec des liens vers les traductions de cette mise à jour de développement et les modérateurs les ajouteront ici.

En tant que projet open source, nous sommes toujours à la recherche de commentaires, de commentaires et de contributions de la communauté. Ne soyez donc pas timide, rejoignez-nous et créons ensemble le réseau sécurisé!