Actualización de Safe Network Dev 🇪🇸 21 de octubre de 2021

Esta es una traducción automática. El original en inglés está aquí: Update 21 October, 2021

¿Por qué utilizar denominaciones fijas en una moneda digital cuando sus pagos podrían utilizar cantidades arbitrarias? Después de todo, aquí estamos hablando de números, no de trozos de metal y trozos de papel. La respuesta es privacidad. Si realiza la transacción 4589234127 SNT, es muy probable que esa cifra sea única y, por lo tanto, rastreable.

Sin embargo, incluso si aceptamos las denominaciones como una forma de poner en común el anonimato, también está la cuestión de la eficiencia. Una pequeña cantidad de denominaciones posibles (digamos 1 y 10) haría que las transacciones fueran extremadamente difíciles de vincular y maximizaría la fungibilidad, pero a costa de hacer un trabajo adicional inaceptable para la red.

El estudio de @mav sobre las transacciones de bitcoin muestra que una granularidad de 8 lugares decimales significativos es algo común, presumiblemente porque los pagos de Btc se calculan en base a monedas fiduciarias y están sujetos a cualquier tipo de cambio. Esto será lo mismo para SNT, por lo que no podemos esperar cantidades perfectamente uniformes.

El equipo ha ideado un enfoque medio feliz que permite una divisibilidad masiva, está de acuerdo con las transacciones del mundo real y no debe ejercer una presión indebida sobre las casas de moneda.

Eso es un resumen. Para aquellos que quieran profundizar, @danda presenta nuestro pensamiento actual en todo su esplendor matemático a continuación.

Progreso general

@chriso ha estado trabajando duro para fusionar api y cli. En lo que respecta al código, todo está incluido, pero la fusión de estos repositorios ha significado que tenemos que adaptar nuestra integración continua y los flujos de cambio de versiones. Se han encontrado soluciones aceptables, lo que debería significar que cada versión de safe_network tendrá todas las cajas adjuntas, pero con sus propias versiones distintas (nuestro flujo anterior habría significado solo una versión, y mucha confusión probable allí). Así que ahora está trabajando en la implementación de estos cambios.

@Chris.Connelly ha seguido hurgando en qp2p y ha confirmado que enviar muchos mensajes entre dos nodos es mucho más rápido a través de una sola conexión que a través de muchas conexiones. Esto se deriva del uso de TLS por parte de QUIC, lo que significa que cada conexión debe realizar un protocolo de reconocimiento. Afortunadamente, QUIC también admite muchas transmisiones lógicamente independientes a través de una sola conexión, por lo que no hay ningún inconveniente real aquí: menos conexiones, menos problemas. Esto informará las últimas etapas de la eliminación de la agrupación de conexiones de qp2p, donde tendremos que tener cuidado para asegurarnos de que seguimos siendo eficientes con las conexiones.

@Lionel.Faber ha estado trabajando para mejorar el proceso de implementación de redes de prueba en Digital Ocean, y ahora se requiere aprobación para cada paso en la implementación y eliminación de la red de prueba, lo que nos permite reiniciar cada paso o usar la red de prueba externamente en lugar de que se destruya automáticamente. .

También hemos estado refinando el inicio de nodos / clientes. Con @yogesh implementando la escritura del mapa de prefijos de red en el disco, de modo que se pueda compartir, y así los clientes y los nodos puedan comenzar con un mínimo de conocimiento de la red. Y hemos estado agregando y mejorando algunas inspecciones de registros locales para poder identificar y rastrear problemas más fácilmente.

Buenas noticias de los laboratorios DBC. Spentproofs ahora está trabajando en el entorno de prueba y debería estar listo para fusionarse pronto.


Antecedentes de las denominaciones

Un DBC Mint que utiliza firmas ciegas no puede ver el contenido de un DBC de salida antes de firmarlo, pero debe verificar que suma (entradas) == suma (salidas). La Casa de Moneda no puede confiar en que la parte reemitida especifique una cantidad con la salida porque podría ser una mentira. Los esquemas de compromiso son posibles, pero las reediciones resultantes se vuelven vinculables, frustrando el propósito de las firmas ciegas.

Entonces, una solución es que la Casa de la Moneda trate cada DBC firmado con una clave dada como si fuera igual a todos los demás DBC firmados con la misma clave. Ampliando esto, podemos definir un conjunto de denominaciones fijas, cada una con una clave de firma única. La derivación de clave nos permite tener una clave de ceca única, pero derivar determinísticamente una clave de denominación utilizando la denominación en sí como índice de derivación. ¡Esto significa que podríamos llegar a tener una denominación única para cada valor posible de un u128!

Pero resulta que esto sería muy malo para la privacidad y la fungibilidad. Cantidades únicas como 4589234127 permiten vincular una reedición con otra. Piense en efectivo por un momento. Con USD, pagamos utilizando denominaciones de papel de 1, 2, 5, 10, 50, 100. Y también monedas: .01, .05, .10, .25, .50. Cuando compras algo con un precio de $ 365.23, podrías pagar con tres de 100, uno de 50, uno de 10, uno de 5, dos de .20 y tres de .01. Cada uno de esos billetes o monedas es muy difícil de vincular con otras transacciones porque muchas otras personas están usando exactamente las mismas cantidades. Sin embargo, si de alguna manera pudiera producir una factura impresa por valor de 365.23, bueno, eso es bastante único y hace que su factura realmente se destaque.

Por lo tanto, podemos decir que cada denominación representa un conjunto de anonimato, o grupo para que su transacción se oculte. Cuantas más denominaciones (o grupos) tengamos, más pequeño será cada grupo. Entonces, en términos de privacidad / fungibilidad, apuntaríamos a la menor cantidad posible de grupos, que en realidad es1, es decir, la unidad más pequeña disponible.

Sin embargo, también debemos considerar la eficiencia. Esto se mide por el número de “monedas” (billetes o monedas) necesarias para hacer el cambio por una cantidad determinada. Usando nuestro precio de ejemplo en USD de $ 365.23, necesitábamos 11 monedas individuales. Además, tenga en cuenta que en una reemisión de DBC * típica *, habrá dos cantidades de salida lógicas: 1: el pago del destinatario y 2: cambio para el remitente. Crear, firmar y validar monedas DBC representa trabajo para los nodos de menta y también hay un tráfico de red significativo involucrado en el gasto de cada DBC. Por lo tanto, debemos tratar de minimizar la cantidad de monedas de cambio requeridas para cualquier monto transaccional.

Por tanto, queda claro que existe una tensión entre optimizar la fungibilidad y optimizar la eficiencia. La fungibilidad óptima sería tener una sola denominación. La eficiencia óptima sería tener una denominación única para cada monto posible.

Cantidades transables frente a denominaciones

Al pensar en denominaciones, debemos tener cuidado de distinguir entre “cantidades transables” y “cantidades de denominación”.

Un “monto negociable” es un precio o monto de pago que se está negociando. Se pueden combinar / agregar una o más * cantidades de denominación * para hacer una “cantidad negociable”.

En el futuro, nos referiremos a la “cantidad de denominación” simplemente como “denominación”.

Usaremos el término “moneda” para referirnos a una instancia particular de una denominación.

Nuestro primer enfoque de denominaciones

nota: el código es aquí.

Inicialmente, definimos una “cantidad negociable” como un número entero de 128 bits (u128).

Luego definimos una serie de denominaciones basadas en potencias de diez, por ejemplo:

‘’
enum {
Uno, dos, tres, cuatro, cinco, seis, siete, ocho, nueve,
Diez, veinte, treinta, cuarenta, cincuenta, sesenta, setenta, ocho, noventa,
Cientos, Doscientos, Trescientos, Cuatrocientos, Quinientos, Seiscientos, Setecientos, Ochocientos, Novecientos,
Mil dos mil tres mil cuatro mil cinco mil seis mil siete mil ocho mil nueve mil
Diez mil veinte mil treinta mil cuarenta mil cincuenta mil sesenta mil setenta mil ochenta mil noventa mil
}
‘’

Y así sucesivamente, hasta 10 ^ 38, que se acerca al límite de un u128. El número total de denominaciones fue de alrededor de 340.

También creamos nombres cortos para cada potencia de diez, basados ​​en nombres de números grandes.

‘’
tau → taus
mil → mils
bil → bils
tril → trils
quad → quads
quint → quints
sic → sics
set → sets
ott → otts
no → no
det → dets
unt → unts
‘’

La idea básica es que “Uno” representa la unidad más pequeña, por ejemplo, el equivalente en bitcoin se llama * Satoshi *. No definiríamos una ubicación de punto decimal (arbitrario) en absoluto, sino que el mercado decidiría cuál es el conjunto correcto de unidades que se utilizará para las transacciones diarias poco después del lanzamiento y, con el tiempo, a medida que aumente la “capitalización de mercado”, progresará. desde unidades grandes, por ejemplo, conjuntos a unidades más pequeñas, por ejemplo, quads.

De todos modos, un punto decimal es solo una cosa de cara al usuario (pantalla) ya que el valor se representa como u128. Así que no lo discutiremos más aquí.

Este enfoque tiene algunas propiedades interesantes. Al definir de 1 a 9 para cada potencia de diez, podemos representar cada dígito de una “cantidad negociable” con una sola moneda, o menos si hay ceros.

Por ejemplo, si tenemos el “monto transable” 55034, podemos representarlo con: 1 FiftyTau, 1 FiveTau, 1 Thirty y 1 Four. Entonces, la cantidad tiene 5 dígitos, uno de ellos es cero, y le cambiamos con solo 4 monedas.

Este enfoque también tiene un par de inconvenientes.

  1. El primero es algo menor. El código para implementar una enumeración con más de 340 variantes y nombres asignados es enorme y difícil de mantener. Terminamos escribiendo un script para generar el archivo de código fuente denominations.rs. Si bien era factible, esta fue una solución torpe e incómoda.

  2. gran cantidad de monedas de cambio. En nuestras pruebas, el número medio de monedas necesarias para realizar cambios en las “cantidades transables” de u128 generadas aleatoriamente fue de 38 a 39. Y eso es para una única salida lógica. Recuerde que una reedición típica tendrá dos salidas lógicas, tal vez más. Entonces, en promedio, podríamos estar viendo más de 76 DBC de salida por reedición y un número comparable de entradas. Eso es mucho trabajo para la menta y la red, y también coloca a la implementación de Blind Sig en una desventaja de eficiencia severa en comparación con la implementación de Amount Hiding (pero rastreable).

Por ejemplo, usemos u128 :: MAX:
‘’
$ calc 2 ^ 128
340282366920938463463374607431768211456
‘’

Tenemos una variante de denominación para cada [0…9] de cada potencia de diez. Hay 40 dígitos en ese número. Dos dígitos son cero, podemos ignorarlos. Entonces necesitamos 38 “monedas” para representar el número. P.ej:
‘’
3 * 10 ^ 38
4 * 10 ^ 37
2 * 10 ^ 35
8 * 10 ^ 34
‘’
…etcétera…

¿Qué pasa si usamos u64 en lugar de u128? Bueno eso esUn poco mejor.
‘’
$ calc 2 ^ 64
18446744073709551616
‘’

Pero sigue siendo de 20 dígitos. Y ahora solo tenemos 19 potencias de diez para trabajar, por lo que nuestra divisibilidad potencial es más limitada.

Ahora bien, se podría argumentar que, en la práctica, los usuarios elegirían enviar más cantidades de números enteros con muchos ceros. Sin embargo, eso parece no ser cierto. @mav realizó un análisis de toda la cadena de bloques de bitcoin y descubrió que la mayoría de los montos de las transacciones usaban 8 dígitos de precisión con números en su mayoría aleatorios. Creemos que esto se debe a que la mayoría de las personas todavía realizan pagos basados ​​en montos fiduciarios (por ejemplo, USD) y calculan el monto equivalente de BTC, que se convierte en un número con muchos dígitos significativos. El mismo comportamiento parecería aplicarse a nuestros DBC.

En cualquier caso, el sistema debe diseñarse de manera que funcione adecuadamente o de manera eficiente incluso en el peor de los casos.

Así que teníamos que encontrar una forma mejor.

Nuestro segundo enfoque (actual)

Se nos ocurrió una representación más simple y poderosa de las denominaciones. Codificamos el exponente de potencia de diez en la enumeración Denomination como un entero con signo. Entonces, en lugar de la enumeración * enorme * con más de 300 variantes, tenemos esto:

‘’
pub type PowerOfTen = i8;

pub enum Denominación {
Uno (PowerOfTen),
Dos (PowerOfTen),
Tres (PowerOfTen),
Cuatro (PowerOfTen),
Cinco (PowerOfTen),
Seis (PowerOfTen),
Siete (PowerOfTen),
Ocho (PowerOfTen),
Nueve (PowerOfTen),
}
‘’

Entonces, con un i8, podemos representar 9 \ * 10 ^ -128…9 \ * 10 ^ 127. Recuerde que el u128, que ya se considera * enorme *, nos dio solo 10 ^ 38, en términos de divisibilidad. Entonces, para propósitos * prácticos *, esta representación es casi ilimitada. (Podríamos ir aún más lejos usando un i16 o i32 en lugar de un i8, pero parece una exageración).

  • nota: Lo siguiente no pretende ser una discusión de los planes de política monetaria de SNT. Es puramente hipotético con fines ilustrativos. *

Este enfoque de las denominaciones no hace que la denominación “Uno” sea igual a la cantidad más pequeña posible como lo hizo nuestro primer enfoque. En su lugar, “Uno” puede representar nuestra mejor suposición inicial, por ejemplo, 1 DBC = 1 USD. Podríamos aspirar a que “Uno” tenga algún poder adquisitivo útil en términos de bienes del mundo real, pero no mucho. por ejemplo, “Uno” debería comprar una lata de refresco o quizás un chicle, no una casa.

También es interesante pensar en cuál podría ser nuestra oferta monetaria total. Solo como un punto de partida ** hipotético **, digamos que obtenemos la cantidad de Genesis DBC tomando la capitalización de mercado actual de SNT y calculando una cantidad de Genesis tal que 1 DBC = 1 USD. No he calculado cuál sería la cantidad de Génesis con este método, pero supongamos que son 50 millones. Ok, lo lanzamos con denom One (1 * 10 ^ 0) = ~ 1 USD y Genesis DBC = 50 millones. frio. Ignoraremos los efectos de distribución / agricultura por ahora, excepto para decir que podrían inflar / devaluar temporalmente la moneda.

De acuerdo, esta es una moneda deflacionaria (oferta monetaria fija) y, a medida que pasa el tiempo, cada unidad se vuelve más valiosa en términos de valor en el mundo real (o, de lo contrario, el proyecto probablemente fracasará). A medida que esto suceda, los usuarios pasarán gradualmente a utilizar más denominaciones de 10 ^ -1. luego 10 ^ -2, y así sucesivamente. Podemos acomodar 128 expansiones de este tipo 10x. También podemos acomodar el envío de 3 millones de SNT en un dbc, por ejemplo, usando la denominación 3 \ * 10 ^ 6. O mucho, mucho, mucho más que eso, si, por ejemplo, definimos la cantidad de Génesis como mucho más alta, hasta 9 \ * 10 ^ 127.


Naming

Anteriormente habíamos creado algunos nombres para números grandes pero eran un poco incómodos y desconocidos. Nos encontramos acortándolos y modificándolos para que pudieran ser pronunciados. Además, no cubrieron ningún exponente negativo. Pero no se preocupe, la escala SI nos tiene cubiertos, con nombres cortos con los que la gente ya está familiarizada.

La escala SI nombra 10 ^ -24 … 10 ^ 24. Bueno, no todas las potencias de diez, sino cada 10 ^ 3, que es lo suficientemente bueno. Cuando los conectamos al código, podemos generar:

‘’
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 micro
10 ^ -5-10 micro
10 ^ -4 - 100 micro
10 ^ -3 - 1 mili
10 ^ -2 - 1 centi
10 ^ -1 - 1 deci
1 - 1
10 ^ 1 - 1 decá
10 ^ 2 - 1 hecto
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 exa
10 ^ 19 - 10 exa
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 alguna vez llegamos a denominaciones más pequeñas que yocto, podemos encontrar nombres para ellas. Eso es para un futuro lejano. Por ahora, hay una función Amount :: to_si_string () que simplemente escupe la representación del exponente para valores sin nombre.


Representando montos transables

Anteriormente utilizamos un u128 para representar los “importes transables”. Pero, ¿cómo manejamos las cantidades cuando nuestra nueva enumeración de Denominación permite valores mucho más grandes de lo que permite u128 (10 ^ 38), y también pueden ser exponentes negativos, es decir, décimas, centésimas, milésimas, etc.?

Ok, aquí es donde las cosas se ponen un poco complicadas.

Lo que hemos hecho es cambiar sn_dbc :: Amount de un alias u128 a:

‘’
pub type PowerOfTen = i8;
tipo de pub AmountCounter = u32;

pub struct Amount {
recuento de pubs: AmountCounter,
unidad de pub: PowerOfTen,
}
‘’

  • nota: Es posible que se cambie el nombre a TransactableAmount en el futuro. *

Con esta estructura, podemos representar cantidades monetarias como una potencia de diez (que representa una única denominación o * moneda *) más una cuenta, que representa el número de esas monedas.

AmountCounter es un u32, por lo que podemos representar más de mil millones de cualquier denominación. Actualmente lo limitamos a exactamente mil millones (10 ^ 9).

Llegamos a este número pensando en las transacciones típicas de hoy. Las personas regularmente hacen pagos en efectivo de hasta unos pocos miles de dólares, compran una casa por un millón de dólares, etc. Pero 100 millones de tx son bastante raros. Y los tx de mil millones de dólares son muy raros: estamos hablando de grandes corporaciones y gobiernos. Queríamos evitar obligar a las personas a cambiar su unidad de precio (mental) para transacciones regulares. Pero cuando llegamos a una diferencia de 10 ^ 9 en unidades, estamos en una liga financiera diferente.

Otra forma de pensar es que si Sally está enviando mil millones de dólares, probablemente no le importe mucho si no puede usar incrementos de 1 dólar. Sally podría volver a emitir 1 billón + 10, pero no pudo volver a emitir 1 billón + 1 (o 2, 3, 4…). Sally probablemente podría vivir con eso. Mientras que si establecemos el límite en, digamos, 100, y ella solo podría volver a emitir 110, 120, pero no 101, 102, eso podría ser un problema mayor para ella … y para la mayoría de la gente.

Ahora recuerde que la cantidad de dígitos en la cantidad define la cantidad máxima de monedas de cambio requeridas. Entonces, al usar mil millones como nuestro límite, hemos bajado de 40 monedas de cambio a 9 (máximo). ¡Bastante bien!

Podríamos dejar esto más lejos. 1 millón = 10 ^ 6, o seis monedas. Esa podría ser una opción razonable. 1 millón sigue siendo un número bastante alto para la transmisión diaria. Podríamos seguir bajando, con la compensación de que las personas deben comenzar a especificar cantidades / precios utilizando unidades más altas.

Así que esta función counter_limit () es una perilla que podemos girar para equilibrar la eficiencia del sistema y la granularidad de las “cantidades transables”. Las pruebas de rendimiento pueden guiarnos / nos guiarán aquí a medida que avancemos un poco.


Calculando con Monto

Es importante tener en cuenta desde el principio que Amount todavía usa solo matemáticas enteras. No hay puntos flotantes involucrados.

La menta necesita verificar que suma (entradas) == suma (salidas). Hemos implementado algunos operadores matemáticos: Check_sub (), Check_add () y Check_sum (). Estos funcionan convirtiendo Cantidades a una unidad base común y luego sumando o restando el recuento de cada una. El resultado de cada operación es Amount o Error :: AmountIncompatible. Las cantidades son incompatibles si las unidades están demasiado separadas para que el recuento se represente dentro de Amount :: counter_max () (mil millones).

Amount no expone los operadores Add, Sub, Sum que no están marcados en absoluto, por lo que es imposible realizar operaciones sin marcar. Además, el valor de retorno es un resultado, no una opción, como ocurre con los tipos integrados.

El código Mint ahora llama a Amount :: check_sum () en lugar de sum (). Con este simple cambio, la Casa de la Moneda ahora impone que todas las entradas y salidas deben ser compatibles, de lo contrario, la reedición falla.

También es posible convertir una cantidad en un número racional y viceversa. Esto se ha implementado, pero entrará en una caja separada, ya que no es necesario para las operaciones de Mint o del cliente.

Implicaciones para el uso de entradas

El “límite de proximidad” de 10 ^ 9 para Cantidades se aplica tanto a las entradas como a las salidas en una reedición.

Sin embargo, las entradas y salidas se suman por separado. Por lo tanto, podría ser que una entrada y una salida individuales no fueran compatibles por sí mismas; sin embargo, la suma de las entradas y la suma de las salidas siguen siendo iguales entre sí. A continuación, se muestra un ejemplo de esto:

‘’
entradas:
9 * 10 ^ 8, 1 * 10 ^ 8, 9 * 10 ^ 0, 1 * 10 ^ 0
salidas:
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
‘’
Para que la reedición tuviera éxito.

Aun así, el límite de proximidad restringe que las entradas y las salidas no puedan estar demasiado alejadas, especialmente si estamosimponen un límite en el número de entradas y salidas. Por lo tanto, se puede considerar similar al (difuso) límite de polvo en bitcoin, excepto que siempre es relativo a las otras cantidades en la reedición, por lo que no hay un límite fijo en ninguna parte, lo cual es agradable. :wink:

Este límite de proximidad debería incentivar a las personas a realizar transacciones con otras personas utilizando las denominaciones más utilizadas. Porque la casa de la moneda no me permitía pagarte un refresco con un One DBC más un 1 Pico DBC (10 ^ -12). Actualmente no aplicamos ningún número máximo de DBC de entrada a una reedición, pero eso sería algo a considerar también, lo que haría imposible pagar con cientos o miles de monedas diminutas, en lugar de unas pocas monedas de tamaño razonable.


Pensamientos concluyentes

El hecho de que nuestro enfoque de denominación original requiera una gran cantidad de monedas para representar cantidades arbitrarias fue un serio inconveniente que fue necesario abordar para que una ceca de firma ciega tuviera la oportunidad de ser tan eficiente como una ceca sin cegar.

Este nuevo diseño es una mejora del sistema de denominación original, en términos de eficiencia, claridad y (posiblemente) simplicidad de código.

Si bien el concepto TransactableAmount puede parecer inusual al principio, debería ser transparente para los usuarios. Inicialmente, todos los montos de transacciones por debajo de mil millones de DBC simplemente se podrían expresar como un número entero (usando la base 10 ^ 0). Solo si uno supera esa cantidad o necesita caer por debajo de 1 DBC, entonces debe elegir una unidad diferente para expresar la cantidad, y el software de billetera podría hacerlo automáticamente.

La divisibilidad profunda es una propiedad agradable que permite pequeños micropagos, y algo que este diseño ofrece como una especie de feliz accidente. 128 dígitos de divisibilidad es enorme, y podríamos ir mucho más lejos con un i16 si quisiéramos. En comparación, bitcoin tiene 8 dígitos decimales de divisibilidad y la mayoría de las criptomonedas actuales son similares. 12 lugares decimales se consideran grandes.

El límite de proximidad es un concepto novedoso que debería ayudar a minimizar el polvo y aumentar la fungibilidad sin requerir ningún límite de polvo de tamaño fijo. También es una perilla que podemos girar fácilmente para sintonizar entre eficiencia y * cantidad transaccional * granularidad.

Cualquier persona interesada en más detalles puede leer el código fuente. amount.rs contiene un extenso comentario / explicación.

código:


Enlaces útiles

No dude en responder a continuación con enlaces a las traducciones de esta actualización para desarrolladores y los moderadores las agregarán aquí.

Como proyecto de código abierto, siempre estamos buscando retroalimentación, comentarios y contribuciones de la comunidad, así que no sea tímido, únase y creemos la red segura juntos.