1

Nano: Una Criptomoneda Con

Red Distribuida Sin Costos
Colin LeMahieu
[email protected]

Resumen—Actualmente, la alta demanda y la escalabilidad fue la cadena de bloques (blockchain); una estructura de datos
limitada han aumentado el promedio del tiempo de transacciones pública, inmutable y descentralizada que se utiliza como un
y las tarifas en las criptomonedas populares, produciendo libro de contabilidad (ledger) para las transacciones de la
una experiencia insatisfactoria. Aquı́ presentamos a Nano,
una criptomoneda con una arquitectura novedosa llamada moneda. Desafortunadamente, a medida de que el Bitcoin se
Block-lattice (enrejado de bloques) donde cada cuenta tiene su desarrolló, varios problemas en el protocolo hicieron que el
propia blockchain (cadena de bloques), brindando una velocidad Bitcoin tuviera restricciones para muchas aplicaciones:
de transacción casi instantánea e ilimitada escalabilidad.
Al haber una blockchain para cada cuenta, les permite 1. Escalabilidad limitada: Cada bloque en el blockchain
actualizarla de manera asincrónica con el resto de la red, puede almacenar una cantidad de datos limitada, lo
generando transacciones rápidas con una sobrecarga mı́nima. Las que significa que el sistema solo puede procesar tantas
transacciones realizan un seguimiento del balance de las cuentas transacciones por segundo, haciendo de los espacios en
en lugar de los montos transferidos, lo que permite una reducción
agresiva de la base de datos sin comprometer la seguridad. un bloque un producto básico. Actualmente, la tarifa
Hasta la fecha, la red de Nano ha procesado 4.2 millones de promedio de una transacción es de $10.38 [2].
transacciones con un ledger (libro de contabilidad digital) de
solo 1.7 GB, sin reducciones. Las transacciones en fracción de 2. Alta latencia: El tiempo promedio de confirmación es
segundos y sin comisiones hace de Nano la criptomoneda ideal de 164 minutos [3].
para las transacciones del consumidor.
3. Consumo ineficiente: La red del Bitcoin consume un
Palabras Clave—criptomoneda, blockchain, Nano, ledger, estimado de 27.28TWh por año, usando una media de
transacciones, block-lattice, digital 260KWh por transacción [4].

I. I NTRODUCCI ÓN Bitcoin y otras criptomonedas funcionan al lograr un

consenso en sus registros globales para verificar las

D ESDE la implementación del Bitcoin en 2009, ha habido

un cambio cada vez mayor, de las monedas tradicionales
respaldadas por el gobierno y los sistemas financieros, hacia
transacciones legı́timas mientras se resisten a los actores
maliciosos. Bitcoin logra el consenso a través de una medida
económica llamada prueba de trabajo (PoW en inglés). En
sistemas de pagos modernos basados en criptomonedas, que un sistema PoW, los participantes compiten para calcular un
ofrecen la capacidad de almacenar y transferir fondos de número, llamado nonce, de modo que el hash de todo el
manera confiable y sin riesgos. [1]. Para funcionar de manera bloque se encuentre en el rango del objetivo. Este rango
efectiva, una moneda debe ser fácilmente transferible, no válido es inversamente proporcional al poder de cómputo
reversible y tener comisiones limitadas o nulas. El aumento acumulado de toda la red de Bitcoin, con el fin de mantener un
de los tiempos de transacción, las comisiones altas y la tiempo promedio consistente para encontrar un nonce válido.
escalabilidad de la red cuestionable han planteado preguntas Al buscador de un nonce válido se le permite agregar el
sobre la practicidad del Bitcoin como una moneda cotidiana. bloque a la blockchain; por lo tanto, aquellos que agotan más
En este documento, presentamos a Nano, una criptomoneda recursos computacionales para computar un nonce juegan un
de baja latencia construida sobre una innovadora estructura de papel más importante en el estado de la blockchain. El PoW
datos llamada Block-lattice, que ofrece escalabilidad ilimitada proporciona resistencia contra un ataque Sybil, donde una
y sin costos de transacción. Nano, por diseño, es un protocolo entidad se comporta como entidades múltiples para obtener
simple con el único propósito de ser una criptomoneda de energı́a adicional en un sistema descentralizado, y también
alto rendimiento. El protocolo de Nano puede ejecutarse reduce en gran medida las condiciones de carrera que existen
en hardware de baja potencia, lo que le permite ser una inherentes al acceder a una estructura de datos global.
criptomoneda descentralizada y práctica para el uso diario. Un protocolo de consenso alternativo llamado Prueba de
Las estadı́sticas de las criptomonedas informadas en este Participación (PoS en inglés), fue presentado por primera vez
documento son precisas a la fecha de publicación. por Peercoin en 2012 [5]. En un sistema PoS, los participantes
votan con un peso equivalente a la cantidad de riqueza que
II. A NTECEDENTES poseen en una criptomoneda dada. Con este acuerdo, a los
En el 2008, un individuo anónimo bajo el seudónimo que tienen una mayor inversión financiera se les da más poder
de Satoshi Nakamoto publicó un documento técnico que y se les incentiva inherentemente a mantener la honestidad
describe la primera criptomoneda descentralizada del mundo, del sistema o arriesgarse a perder su inversión. El sitema PoS
el Bitcoin. [1]. Una innovación clave provocada por Bitcoin elimina la competencia de poder de cómputo derrochador, solo
 2

Recibir Repetir Observar Quórum Confirmar

(a) Cuando no se detecta conflicto, no se requiere una sobrecarga.

Recibir Repetir Observar Conflicto Votar Confirmar

(b) En el evento de una transacción conflictiva, los nodos votan por la transacción válida.
Figura 1. Nano no requiere una sobrecarga adicional para transacciones tı́picas. En el caso de una transacción conflictiva, los nodos deben votar por ella para
mantenerla

requiriendo un software liviano que se ejecuta en hardware de III-C. Ledger

baja potencia. El Ledger es el conjunto global de cuentas donde cada
El documento original de Nano y la primera implementación cuenta tiene su propia cadena de transacciones (Figura 2).
beta se publicaron en Diciembre del 2014, lo que la convierte Este es un componente de diseño clave que cae dentro de la
en una de las primeras criptomonedas basadas en gráficos categorı́a de reemplazar un convenio de tiempo de ejecución
acı́clicos dirigidos (DAG en inglés) [6]. Poco después, otras con un convenio de tiempo de diseño; todos convienen a través
criptomonedas DAG comenzaron a desarrollarse, sobre todo de la comprobación de las firmas que solo el propietario de
DagCoin/Byteball e IOTA [7], [8]. Estas criptomonedas una cuenta puede modificar su propia cadena. Esto convierte
basadas en DAG rompieron el estándar impuesto por el una estructura de datos aparentemente compartida, un ledger
blockchain, mejorando el rendimiento y la seguridad del distribuido, en un conjunto de elementos no compartidos.
sistema. Byteball logra el consenso al basarse en una
çadena principalçompuesta por ”testigos”honestos, con buena
reputación y de confianza del usuario, mientras que IOTA logra III-D. Nodo
el consenso a través del PoW acumulado de transacciones Un nodo es una pieza de software que se ejecuta en una
apiladas. Nano logra el consenso a través de una votación computadora, conformando al protocolo de Nano y participa
ponderada y equilibrada sobre transacciones conflictivas. en la red. El software administra el ledger y cualquier cuenta
Este sistema de consenso proporciona transacciones más que el nodo pueda controlar, si corresponde. Un nodo puede
rápidas y más deterministas, manteniendo un sistema fuerte almacenar todo el ledger o un historial reducido que contiene
y descentralizado al mismo tiempo. Nano continúa este solo los últimos bloques del blockchain de cada cuenta. Al
desarrollo y se ha posicionado como una de las criptomonedas configurar un nuevo nodo, se recomienda verificar todo el
de mayor rendimiento. historial y reducirlo localmente.

III. C OMPONENTES DE NANO IV. D ESCRIPCI ÓN DEL S ISTEMA

Antes de describir la arquitectura global de Nano, definimos A diferencia de las blockchains de otras criptomonedas,
los componentes individuales que integran al sistema. Nano usa una estructura block-lattice. Cada cuenta
tiene su propia Blockchain, equivalente al historial de
III-A. Cuenta
Una cuenta es la porción pública de un par de códigos Cuenta A Cuenta B Cuenta C
de firma digital. El código publico, también conocido como Bloque NA Bloque NB Bloque NC
la dirección, se comparte con otros participantes de la red
mientras que el código privado se mantiene en secreto.
Cuenta A Cuenta B Cuenta C
Un paquete de datos firmado digitalmente asegura que los
Bloque NA − 1 Bloque NB − 1 Bloque NC − 1
contenidos fueron aprobados por el titular de la clave privada.
Un usuario puede controlar muchas cuentas, pero solo puede
.. .. ..
existir una dirección pública por cuenta, por eso lo importante . . .
de los códigos tanto públicos como privados.
Cuenta A Cuenta B Cuenta C
III-B. Bloque/transacción Bloque 1 Bloque 1 Bloque 1
El término bloque y transacción a menudo se usan
indistintamente, donde un bloque contiene una sola Cuenta A Cuenta B Cuenta C
transacción. La transacción se refiere especı́ficamente a Bloque 0 Bloque 0 Bloque 0
la acción mientras que el bloque se refiere a la codificación
digital de la transacción. Las transacciones están firmadas Figura 2. Cada cuenta tiene su propia blockchain, que contiene el balance
por el código privado que pertenece a la cuenta en la que se historico de dicha cuenta. El bloque cero debe ser una transacción abierta
realiza la transacción. (Sección IV-B)
 3

transacciones/saldos de la cuenta (Figura 2). Cada cuenta solo 2. Mantener pequeñas las transacciones, ajustandose al
puede ser actualizada por el titular; esto permite que cada tamaño de un paquede UDP.
blockchain se actualice de forma inmediata y ası́ncrona al
3. Facilitar la reducción del ledger, minimizando las huellas
resto del block-lattice, lo que da como resultado transacciones
de los datos.
rápidas. El protocolo de Nano es extremadamente liviano;
cada transacción se ajusta al tamaño mı́nimo del paquete 4. Aislar las transacciones liquidadas de las no liquidadas.
UDP requerido para ser transmitido a través de Internet. Los
requisitos de hardware para los nodos también son mı́nimos, Más de una cuenta transfiriendo al mismo destino es una
ya que los nodos solo tienen que registrar y retransmitir operación asincrónica; la latencia de la red y las cuentas de
bloques para la mayorı́a de las transacciones (Figura 1). envı́o no están necesariamente en comunicación mutua, lo que
El sistema es iniciado con una cuenta génesis que contiene significa que no existe una forma universalmente aceptable
balance génesis. El balance de génesis es una cantidad fija y de saber qué transacción ocurrió primero. Como la suma es
nunca se puede aumentar. El balance de génesis se divide y asociativa, el orden en que se ordenan las entradas no importa,
se envı́a a otras cuentas a través de transacciones que quedan y por lo tanto, simplemente necesitamos un convenio global.
registradas en el blockchain de génesis. La suma de los saldos Este es un componente de diseño clave que convierte un
de todas las cuentas nunca excederá el saldo inicial de génesis, convenio de tiempo de ejecución en un convenio de tiempo
lo que otorga al sistema un lı́mite superior en cantidad y de diseño. La cuenta receptora tiene el control de decidir qué
elimina su capacidad de aumentar. transferencia llegó primero y se expresa mediante el orden
En esta sección veremos cómo se construyen y propagan firmado de los bloques entrantes.
los diferentes tipos de transacciones en toda la red. Si una cuenta desea realizar una transferencia grande que se
.. .. .. recibió como un conjunto de muchas transferencias pequeñas,
. . . queremos representar esto de una manera que se ajuste dentro
de un paquete UDP. Cuando una cuenta receptora realiza
una secuencia de transferencias de entrada, mantiene el total
acumulado del saldo de su cuenta, de modo que en cualquier
R E R momento tiene la capacidad de transferir cualquier cantidad
con un tamaño fijo de transacción. Esto difiere del modelo
de transacción de entrada/salida utilizado por Bitcoin y otras
criptomonedas.
R E R Algunos nodos no están interesados en gastar recursos
para almacenar el historial de transacciones completo de
una cuenta; solo están interesados en total de su balance
acumulado. Cuando una cuenta realiza una transacción,
E R codifica su balance acumulado y estos nodos solo necesitan
Tiempo

realizar un seguimiento del último bloque, lo que les permite

descartar datos históricos sin perder la precisión.
Incluso con un enfoque en los acuerdos de tiempo
E E
de diseño, hay posibilidad de una demora al validar las
transacciones debido a la identificación y el manejo de
los actores maliciosos en la red. Como los convenios en
A B C Nano se alcanzan rápidamente, del orden de milisegundos
a segundos, podemos presentar al usuario dos categorı́as
Figura 3. Visualización del block-lattice. Cada transferencia de fondos familiares de transacciones entrantes: liquidadas y sin liquidar.
requiere un bloque de envı́o (E) y un bloque de recibo (R), cada uno firmado Las transacciones liquidadas son transacciones donde una
por el propietario de la cadena de cuentas (A, B, C)
cuenta ha generado bloques de recepción. Las transacciones
no liquidadas aún no se han incorporado al saldo acumulativo
del receptor. Este es un reemplazo para la métrica de
IV-A. Transacciones confirmaciones más complejas y desconocidas en otras
Transferir fondos de una cuenta a otra requiere dos criptomonedas.
transacciones: un envı́o que deduce el importe del saldo del
remitente y un recibo que agrega el importe al saldo de la IV-B. Creando una Cuenta
cuenta receptora (Figure 3).
La transferencia de cantidades como transacciones Para crear una cuenta, se debe emitir una transacción open
separadas reflejadas en las cuentas del emisor y del receptor, (abierta) (Figura 4). Una transacción abierta es siempre la
tiene como proposito lo siguiente: primera transacción de cada blockchain y se puede crear con el
primer recibo de fondos. El campo account (cuenta) almacena
1. Secuenciar transacciones entrantes que son el código público (dirección) derivada del código privado que
inherentemente asincrónicas. se utiliza para firmar. El campo source contiene el hash de la
 4

transacción que envió los fondos. En la creación de la cuenta, IV-E. Recibiendo una Transacción
se debe elegir un representante para que vote en su nombre; Para completar una transacción, el destinatario de los fondos
esto se puede cambiar más adelante (Sección IV-F). La cuenta enviados debe crear un bloque de recepción en su propia
puede declararse como su propio representante. blockchain (Figura 6). El campo source hace referencia al hash
de la transacción de envı́o asociada. Una vez que este bloque
open { se crea y se transmite, el saldo de la cuenta se actualiza y los
account: DC04354B1...AE8FA2661B2, fondos se transfieren oficialmente a su cuenta.
source: DC1E2B3F7C...182A0E26B4A,
representative: xrb_1anr...posrs, receive {
work: 0000000000000000, previous: DC04354B1...AE8FA2661B2,
type: open, source: DC1E2B3F7C6...182A0E26B4A,
signature: 83B0...006433265C7B204 work: 0000000000000000,
} type: receive,
signature: 83B0...006433265C7B204
}
Figura 4. Anatomı́a de una transacción abierta

Figura 6. Anatomı́a de una transacción de recibo

IV-C. Balance de la Cuenta

IV-F. Asignando a un Representante
El saldo de la cuenta se registra dentro del ledger. En
lugar de registrar el monto de una transacción, la verificación Los titulares de cuentas que tienen la capacidad de elegir a
(Sección IV-I) requiere verificar la diferencia entre el saldo en un representante para que vote en su nombre es una poderosa
el bloque de envı́o y el saldo del bloque anterior. La cuenta herramienta de descentralización que no tiene un análogo
receptora puede entonces incrementar el saldo anterior medido fuerte en los protocolos PoW o PoS. En los sistemas PoS
en el saldo final dado en el nuevo bloque de recibo. Esto se convencionales, el nodo del propietario de la cuenta debe
hace para mejorar la velocidad de procesamiento al descargar estar ejecutándose para participar en la votación. La ejecución
grandes volúmenes de bloques. Al solicitar el historial de la continua de un nodo no es práctica para muchos usuarios; por
cuenta, los montos ya están dados. lo que dar a un representante el poder de votar en nombre
de una cuenta relaja este requisito. Los titulares de cuentas
tienen la capacidad de reasignar el consenso a cualquier cuenta
en cualquier momento. Una transacción change (cambio)
IV-D. Enviando desde una Cuenta
cambia el representante de una cuenta restando el peso del
Para enviar desde una dirección, la dirección ya debe voto del antiguo representante y agregando el peso al nuevo
tener un bloque abierto existente, y por lo tanto un balance representante (Figura 7). No se transfieren fondos en esta
(Figura 5). El campo previous (previo) contiene el hash transacción, y el representante no tiene el poder de gastar los
del bloque anterior en la blockchain. El campo destination fondos de la cuenta.
(destino) contiene la cuenta para los fondos que se enviarán.
Un bloque de envı́o es inmutable una vez confirmado. Una change {
vez emitidos a la red, los fondos se deducen inmediatamente previous: DC04354B1...AE8FA2661B2,
del saldo de la cuenta del remitente y esperan como pending representative: xrb_1anrz...posrs,
(pendiente) hasta que la parte receptora firme un bloque work: 0000000000000000,
para aceptar estos fondos. Los fondos pendientes no deben type: change,
considerarse como una espera de confirmación, ya que el signature: 83B0...006433265C7B204
remitente no puede revocar la transacción. }

send { Figura 7. Anatomı́a de una transacción de cambio

previous: 1967EA355...F2F3E5BF801,
balance: 010a8044a0...1d49289d88c,
destination: xrb_3w...m37goeuufdp, IV-G. Fork y Votos
work: 0000000000000000,
Se produce un fork (bifurcado en inglés) cuando bloques
type: send,
b1 , b2 , . . . , bj firmados con j reclaman el mismo bloque que su
signature: 83B0...006433265C7B204
predecesor (Figura 8), causando un conflicto sobre el estado de
}
una cuenta. Solo el titular tiene la capacidad de firmar bloques
en su blockchain, por lo que un fork debe ser producto de una
Figura 5. Anatomı́a de una transacción de envı́o programación deficiente o intención maliciosa (double-spend
o doble gasto en español) por parte del titular.
 5

Cuenta A las transacciones parezcan instantáneas para un usuario final,

Bloque i + 2 siempre que el tiempo entre las transacciones sea mayor que
el tiempo requerido para calcular el PoW.
Cuenta A Cuenta A
Bloque i Bloque i + 1
IV-I. Verificación de Transacciones
Cuenta A
Bloque i + 2 Para que un bloque sea considerado como válido, debe
cumplir con los siguietnes atributos:
Figura 8. Un fork ocurre cuando uno o mas bloques firmados hacen referencia
al mismo bloque anterior en el blockchain de una cuenta. Los bloques antiguos 1. El bloque no debe estar en el ledger (transacción
están a la izquierda; los bloques nuevos están a la derecha duplicada).
2. Debe estar firmado por el titular de la cuenta.
Tras la detección de un fork, un representante creará un voto 3. El bloque anterior es el bloque principal del blockchain
haciendo referencia al bloque b̂i en su ledger y lo transmitirá de la cuenta. Si este existe pero no es el principal, es
a la red. El peso del voto de un nodo wi es la suma de los un fork.
saldos de todas las cuentas que lo han nombrado como su
representante. El nodo observará los votos entrantes de los 4. La cuenta debe tener un bloque abierto.
otros representantes en lı́nea de M y mantendrá un recuento 5. El hash computado cumple con el valor lı́mite del PoW
acumulado durante 4 perı́odos de votación, un total de 1 requerido.
minuto, y confirmará el bloque ganador (Ecuación 1).
Si es un bloque de recibo, compruebe si el hash del bloque
M de origen está pendiente, lo que significa que todavı́a no se ha
wi 1b̂i =bj canjeado. Si es un bloque de envı́o, el saldo debe ser menor
X
v(bj ) = (1)
i=1 que el saldo anterior.
b∗ = arg max v(bj ) (2)
bj V. V ECTORES DE ATAQUE
∗
El bloque más popular b tendrá la mayorı́a de los votos y Nano, como todas las criptomonedas descentralizadas,
se mantendrá en el ledger del nodo (Ecuación 2). El bloque(s) puede ser atacada por grupos malintencionados intentando
que pierde el voto se descarta. Si un representante reemplaza obtener ganancias financieras o causar el fallecimiento
un bloque en su ledger, creará un nuevo voto con un número del sistema. En esta sección describimos algunos posibles
de secuencia más alto y transmitirá el nuevo voto a la red. escenarios de ataque, sus consecuencias y cómo el protocolo
Este es el único escenario donde los representantes votan. de RaiBlock toma medidas preventivas ante estos ataques.
En algunas circunstancias, los problemas de conectividad
de red breves pueden causar que un bloque emitido no sea
V-A. Sincronización de bloques vacı́os
aceptado por todos los peers (pares de red). Cualquier bloqueo
posterior en esta cuenta será ignorado como inválido por los En la sección IV-G, discutimos el escenario en el que un
peers que no vieron la transmisión inicial. Los peers restantes bloque puede no ser emitido correctamente, haciendo que la
aceptarán una retransmisión de este bloque y los bloques red ignore los bloques subsiguientes. Si un nodo observa un
subsiguientes se recuperarán automáticamente. Incluso cuando bloque que no tiene de referencia a un bloque anterior, tiene
se produce un fork o un bloque perdido, solo se ven afectadas dos opciones:
las cuentas a las que se hace referencia en la transacción; el
1. Ignorar el bloque, ya que puede ser malicioso.
resto de la red procede con el procesamiento de transacciones
para todas las demás cuentas. 2. Solicitar una resincronización con otro nodo.
En el caso de una resincronización, se debe formar una
IV-H. Prueba de Trabajo (PoW) conexión TCP con un nodo de arranque (bootsrapping node
Los cuatro tipos de transacciones tienen un campo de trabajo para facilitar la mayor cantidad de tráfico que se requiere
que se deben poblar correctamente. El campo de trabajo en una resincronización. Sin embargo, si el bloque era
permite que el creador de la transacción calcule un nonce realmente un bloque malicioso, entonces la resincronización
de modo que el hash del nonce concatenado con el campo era innecesaria y aumentaba innecesariamente el tráfico en la
anterior en las transacciones de recibo/envı́o/cambio o el red. Este es un ataque de amplificación de red y resulta en
campo de la cuenta en una transacción abierta esté por debajo una denegación de servicio.
de un determinado valor lı́mite. A diferencia del Bitcoin, el Para evitar la resincronización innecesaria, los nodos
PoW en Nano se usa simplemente como una herramienta esperarán hasta que se haya observado un determinado lı́mite
antispam, similar a Hashcash, y se puede computar en el orden de votos para un bloque potencialmente malicioso antes de
de segundos [9]. Una vez que se envı́a una transacción, el iniciar una conexión con un nodo de arranque para sincronizar.
PoW para el bloque subsiguiente se puede pre-computar ya Si un bloque no recibe suficientes votos, se puede suponer que
que se conoce el campo del bloque anterior; esto hará que son datos basura.
 6

V-B. Desbordamiento de Transacciones V-F. Ataque >50 %

Una entidad maliciosa podrı́a enviar muchas transacciones La métrica del consenso para Nano es un sistema de
innecesarias pero válidas entre cuentas bajo su control en votación equilibrado. Si un atacante puede ganar más del
un intento de saturar la red. Sin tarifas de transacción, 50 % de la fuerza de votación, puede hacer que el consenso
pueden continuar este ataque indefinidamente. Sin embargo, fluctúe dentro de la red, haciendo que el sistema se rompa. Un
el PoW requerido para cada transacción limita la tasa de atacante puede reducir la cantidad del balance que debe perder
transacción que la entidad maliciosa podrı́a generar sin invertir al impedir que los nodos buenos voten, mediante un DoS en
significativamente en recursos computacionales. Incluso bajo la red. Nano toma las siguientes medidas para prevenir tal
tal ataque en un intento de inflar el libro mayor, los nodos ataque:
que no son nodos históricos completos pueden podar las
transacciones antiguas de su cadena; esto limita el uso de 1. La defensa primaria contra este tipo de ataque es que el
almacenamiento de este tipo de ataque para casi todos los peso del voto está ligado a la inversión en el sistema.
usuarios. El titular de una cuenta está intrı́nsecamente incentivado
a mantener la honestidad del sistema para proteger su
V-C. Ataque Sybil inversión. Intentar voltear el ledger serı́a destructivo para
Una entidad podrı́a crear cientos de nodos de Nano en una el sistema como un todo, lo que destruirı́a su inversión
sola máquina; sin embargo, dado que el sistema de votación en totalidad.
se basa en el saldo de la cuenta, agregar nodos adicionales a
2. El costo de este ataque es proporcional a la
la red no le otorgará votoz extra al atacante. Por lo tanto, no
capitalización de mercado de Nano. En los sistemas
hay ninguna ventaja que se obtenga a través de un ataque de
PoW, se puede inventar tecnologı́a que proporcione
Sybil.
un control desproporcionado en comparación con
la inversión monetaria y, si el ataque es exitoso,
V-D. Ataque Penny-Spend
esta tecnologı́a podrı́a reutilizarse después de que se
Un ataque Penny-Spend (envı́o de centavos) es cuando un complete el ataque. Con Nano, el costo de atacar el
atacante gasta cantidades infinitesimales en una gran cantidad sistema escala con el sistema mismo y, si un ataque
de cuentas para desperdiciar los recursos de almacenamiento tuviera éxito, la inversión hecha en el ataque no se puede
de los nodos. La publicación de bloques está limitada por recuperar.
el PoW, por lo que la creación de cuentas y transacciones
esta limitada hasta cierto punto. Los nodos que no son nodos 3. Para mantener el cuórum máximo de votantes,
históricos por completo pueden reducir las cuentas debajo de la siguiente lı́nea de defensa es la votación de
una métrica estadı́stica donde la cuenta probablemente no sea representantes. Los titulares de cuentas que no pueden
una cuenta válida. Finalmente, Nano está sintonizado para usar participar de manera confiable en la votación por razones
un espacio mı́nimo de almacenamiento permanente, por lo que de conectividad, pueden nombrar a un representante que
el espacio requerido para almacenar una cuenta adicional es pueda votar con el peso de su saldo. Maximizar el
proporcional al tamaño de open block + indexing = 96B + número y la diversidad de representantes aumenta la
32B = 128B. Esto equivale a que 1GB puede almacenar 8 resiliencia de la red.
millones de cuentas Penny-Spend. Si los nodos desean reducir 4. Un fork en Nano nunca es accidental, por lo que los
de forma más agresiva, pueden calcular una distribución en nodos pueden tomar decisiones sobre cómo interactuar
función de la frecuencia de acceso y delegar cuentas de uso con bloques bifurcados. La única forma de que las
poco frecuente a un almacenamiento más lento. cuentas no atacantes sean vulnerables a las bifurcaciones
de bloques es si reciben un saldo de una cuenta atacante.
V-E. Ataque de PoW Pre-Computado Las cuentas que quieran estar seguras de un fork de
Dado que el propietario de una cuenta será la única bloques, pueden esperar un poco o mucho más antes de
entidad que agregue bloques a su blockchain, se pueden recibirlas de una cuenta que generó el fork u optar por no
computar bloques secuenciales, junto con su PoW, antes de recibirlas nunca. Los receptores también pueden generar
ser transmitidos a la red. Aquı́ el atacante genera una gran cuentas separadas para usar cuando reciben fondos de
cantidad de bloques secuenciales, cada uno de valor mı́nimo, cuentas dudosas, con el fin de aislar otras cuentas.
durante un perı́odo prolongado de tiempo. En cierto punto, el 5. Una última lı́nea de defensa que aún no se ha
atacante realiza una denegación de servicio (DoS en inglés) implementado es el block cementing (cementación de
inundando la red con muchas transacciones válidas, que otros bloques). Nano hace todo lo posible para resolver un
nodos procesarán y harán eco lo más rápido posible. Esta fork rápidamente a través de la votación. Los nodos se
es una versión avanzada del desbordamiento de transacciones pueden configurar para cementar bloques, lo que evitarı́a
descrito en la Sección V-B. Tal ataque solo funcionarı́a retrocedan después de un cierto perı́odo de tiempo. La
brevemente, pero podrı́a usarse junto con otros ataques, como red está suficientemente asegurada al enfocarse en un
un ataque >50 % (Sección V-F) para aumentar la efectividad. tiempo de resolución rápido para evitar bifurcaciones
La limitación de la tasa de transacción y otras técnicas se están ambiguas.
investigando actualmente para mitigar los ataques.
 7

Una versión más sofisticada de un ataque > 50 % se detalla VI. I MPLEMENTACI ÓN
en la figura 9. “Offline” es el porcentaje de representantes Actualmente, la implementación de referencia esta en
que han sido nombrados pero que no están en lı́nea para lenguaje C ++ y ha estado produciendo lanzamientos desde
votar. “Stake” es la cantidad de inversión con la que vota 2014 en Github. [10]. A continuación presentamos como esta
el atacante. “Active” es la cantidad de representantes que implementado Nano.
están en lı́nea y votan de acuerdo con el protocolo. Un
atacante puede compensar la cantidad de participación que
debe perder tornando a otros votantes fuera de lı́nea a través VI-A. Caracterı́sticas del Diseño
de un ataque DoS en la red. Si este ataque puede ser sostenido, La implementación de Nano cumple con el estándar de
los representantes atacados pierden la sincronización y esto arquitectura descrito en este documento. Las especificaciones
se demuestra con “Unsync”. Finalmente, un atacante puede adicionales se describen a continuación.
obtener una pequeña ráfaga de fuerza relativa de votación al
cambiar su ataque DoS a un nuevo conjunto de representantes, VI-A1. Algoritmo de Firmas: Nano usa un algoritmo de
mientras que el conjunto anterior vuelve a sincronizar su curva elı́ptica ED25519 modificado con Blake2b hashing para
ledger, esto se demuestra con “Attack”. todas las firmas digitales [11]. El ED25519 fue elegido para
garantizar firmas rápidas, verificación rápida y alta seguridad.
VI-A2. Algoritmo de Hashing: Dado que el algoritmo de
Offline Unsync Attack Active Stake
hash solo se usa para evitar el spam de la red, la elección
del algoritmo es menos importante en comparación con las
Figura 9. Un potencial convenio de votación que podrı́a reducir los requisitos
para un ataque de 51 %.
criptomonedas basadas en la minerı́a. Nuestra implementación
utiliza Blake2b como un algoritmo de asimilación contra el
Si un atacante puede causar que Stake>Active por una contenido del bloque [12].
combinación de estas circunstancias, podrá invertir los votos VI-A3. Función de Derivación de Códigos: En la cartera
en el ledger a expensas de su Stake. Podemos estimar cuánto de referencia, los códigos estan encriptados con una contraseña
podrı́a costar este tipo de ataque examinando el capital de y la contraseña se alimenta a través de una función de
mercado de otros sistemas. Si estimamos que el 33 % de derivación de códigos para protegerse contra los intentos de
los representantes están fuera de lı́nea o atacados a través craqueo ASIC. Actualmente Argon2 [13] es el ganador de la
de un DoS, un atacante tendrı́a que comprar el 33 % de la única competencia pública destinada a crear una función de
capitalización de mercado para atacar el sistema mediante derivación de códigos resistente.
votación.
VI-A4. Intervalos de Bloques: Como cada cuenta tiene
su propia blockchain, las actualizaciones se pueden realizar
V-G. Envenenamiento de Arranque de forma ası́ncrona al estado de la red. Por lo tanto, no hay
intervalos de bloques y las transacciones se pueden publicar
Mientras más tiempo un atacante pueda mantener un código al instante.
privado antiguo balance, mayor será la probabilidad de que los
saldos que existı́an en ese momento no tengan representantes VI-A5. Protocolo de Mensajes UDP: Nuestro sistema
participando porque sus balances o representantes se hayan está diseñado para operar de manera indefinida utilizando la
transferido a cuentas más nuevas. Esto significa que si un cantidad mı́nima de recursos informáticos como sea posible.
nodo se inicia en una representación antigua de la red donde Todos los mensajes en el sistema fueron diseñados encajar
el atacante tiene un quórum de participación de votación dentro de un único paquete UDP. Esto también facilita que
en comparación con los representantes en ese punto en el los peers ligeros con conectividad intermitente participen en
tiempo, podrı́a oscilar las decisiones de votación a ese nodo. Si la red sin restablecer las conexiones TCP a corto plazo. TCP
este nuevo usuario deseara interactuar con cualquier persona se usa solo para los nuevos peers cuando quieren arrancar las
además del nodo atacante, todas sus transacciones serı́an cadenas de bloques de forma masiva.
denegadas ya que tienen diferentes bloques principales. El Los nodos pueden estar seguros de que su transacción fue
resultado es que los nodos pueden desperdiciar el tiempo de recibida por la red al observar el tráfico de transmisión de
los nuevos nodos en la red al proporcionarles información transacciones desde otros nodos, ya que deberı́a ver varias
incorrecta. Para evitar esto, los nodos se pueden emparejar copias repetidas hacia el.
con una base de datos inicial de cuentas y bloques principales
conocidos; este es un reemplazo para la descargar de la base
de datos hasta el bloque de génesis. Cuanto más cerca esté VI-B. IPv6 y Multicast
la descarga de ser la actual, mayor será la probabilidad de Construir encima del UDP sin conexión permite a las
defenderse con precisión contra este ataque. Al final, este implementaciones futuras usar la multidifusión IPv6 como
ataque probablemente no sea peor que alimentar de datos no un reemplazo para los desbordamientos de transacciones y la
deseados a los nodos durante el arranque, ya que no podrı́an transmisión de votos. Esto reducirá el consumo de ancho de
realizar transacciones con nadie que tenga una base de datos banda de la red y dará más flexibilidad polı́tica a los nodos
contemporánea. en el futuro.
 8

VI-C. Desempeño VII-B3. Ligero: Un nodo ligero no conserva datos del

En el momento de escribir estas lı́neas, la red Nano ha ledger local y solo participa en la red para observar la actividad
procesado 4.2 millones de transacciones, lo que deja con un en las cuentas en las que está interesado u opcionalmente crear
tamaño de blockchain de 1,7 GB. Los tiempos de transacción nuevas transacciones con claves privadas que posee.
se miden en el orden de segundos. Una implementación de
referencia actual que opera en SSD de productos básicos
VII-C. CPU
puede procesar más de 10 000 transacciones por segundo,
principalmente en IO. VII-C1. Generación de Transacciones: Un nodo
interesado en crear nuevas transacciones debe producir
un nonce de PoW para pasar el mecanismo de aceleración
VII. U SO DE RECURSOS
de Nano. El cómputo de varios hardwares se compara en el
Esta es una descripción general de los recursos utilizados Apéndice A.
por un nodo de Nano. Además, repasamos ideas para reducir
el uso de recursos para casos especı́ficos de aplicación. Los VII-C2. Representantes: Un representante debe verificar
nodos reducidos se suelen denominar nodos de verificación de firmas para bloques, votos y también producir sus propias
pago simplificado, ligero o reducido (SPV en inglés). firmas para participar en el consenso. La cantidad de recursos
de CPU para un nodo representativo es significativamente
menor que la generación de transacciones y deberı́a
VII-A. Red funcionar con cualquier CPU individual en una computadora
La cantidad de actividad de la red depende de cuánto contemporánea.
contribuye la red para la salud de una red. VII-C3. Observador: Un nodo observador no genera sus
VII-A1. Representativo: Un nodo representativo requiere propios votos. Como la sobrecarga por la generación de firmas
un máximo de recursos de red ya que observa el tráfico de es mı́nima, los requisitos de la CPU son casi idénticos a los
votos de otros representantes y publica sus propios votos. de ejecutar un nodo representativo.
VII-A2. Inconfiable: Un nodo inconfiable es similar a un
nodo representativo pero solo es un observador, no contiene VIII. C ONCLUSI ÓN
una cuenta representativa y no publica sus propios votos. En este documento presentamos el sistema de una
VII-A3. Confiado: Un nodo confiado observa el tráfico criptomoneda de baja latencia, veloz y sin costos, que utiliza
de votos de un representante en el que confı́a para realizar una nueva estructura llamada block-lattice y una convenio de
correctamente el consenso. Esto reduce la cantidad de tráfico votación delegado por PoS. La red requiere recursos mı́nimos,
de votos entrantes de los representantes que van a este nodo. sin hardware de minerı́a de alta potencia y que puede procesar
un alto rendimiento de transacciones. Todo esto se logra
VII-A4. Ligero: Un nodo ligero también es un nodo teniendo cadenas de bloques individuales para cada cuenta,
confiado que solo observa el tráfico de las cuentas en las que eliminando los problemas de acceso e ineficiencias de una
está interesado, lo que permite un uso mı́nimo de la red. estructura de datos global. Identificamos los posibles vectores
VII-A5. De Arranque: Un nodo de arranque sirve partes o de ataque en el sistema y presentamos argumentos sobre cómo
el todo del ledger para nodos que se ponen o intentan ponerse Nano es resistente a estas formas de ataque.
en lı́nea. Esto se realiza a través de una conexión TCP en lugar
de una conexión UDP, ya que implica una gran cantidad de
datos que requieren un control de flujo avanzado.

VII-B. Capacidad de Disco

Dependiendo de las demandas del usuario, diferentes
configuraciones de nodos necesitan diferentes requisitos de
almacenamiento.
VII-B1. Histórico: Un nodo interesado en mantener un
registro histórico completo de todas las transacciones requerirá
la máxima cantidad de almacenamiento.
VII-B2. Actual: Debido al diseño orientado a mantener los
balances acumulados con bloques, los nodos solo necesitan
mantener los bloques más recientes o principales para cada
cuenta a fin de participar en el consenso. Si un nodo no está
interesado en mantener un historial completo, puede optar por
mantener solo los bloques principales.
 9

A P ÉNDICE A
B ENCHMARK DEL H ARDWARE PARA EL P OW
Como se mencionó anteriormente, el PoW en Nano
se utiliza para reducir el spam dentro la red. Nuestra
implementación de nodos proporciona una aceleración que
puede aprovechar las GPUs compatibles con OpenCL. La
tabla I proporciona una comparación real de varios tipos de
hardware. Actualmente, el lı́mite del PoW es fijo, pero se
puede implementar un lı́mite que se adapte a medida que
progresa la potencia de computo promedio.

Cuadro I
D ESEMPE ÑO DE P OW DEL H ARDWARE

Dispositivo Transacciones por segundo

Nvidia Tesla V100 (AWS) 6.4
Nvidia Tesla P100 (Google,Cloud) 4.9
Nvidia Tesla K80 (Google,Cloud) 1.64
AMD RX 470 OC 1.59
Nvidia GTX 1060 3GB 1.25
Intel Core i7 4790K AVX2 0.33
Intel Core i7 4790K,WebAssembly (Firefox) 0.14
Google Cloud 4 vCores 0.14-0.16
ARM64 server 4 cores (Scaleway) 0.05-0.07

R ECONOCIMIENTO
Nos gustarı́a agradecer a Brian Pugh por compilar y
formatear este documento

R EFERENCIAS
[1] S. Nakamoto, “Bitcoin: A peer-to-peer electronic cash system,” 2008.
[Online]. Available: http://bitcoin.org/bitcoin.pdf
[2] “Bitcoin median transaction fee historical chart.” [Online]. Available:
https://bitinfocharts.com/comparison/bitcoin-median transaction fee.
html
[3] “Bitcoin average confirmation time.” [Online]. Available: https:
//blockchain.info/charts/avg-confirmation-time
[4] “Bitcoin energy consumption index.” [Online]. Available: https:
//digiconomist.net/bitcoin-energy-consumption
[5] S. King and S. Nadal, “Ppcoin: Peer-to-peer crypto-currency with
proof-of-stake,” 2012. [Online]. Available: https://peercoin.net/assets/
paper/peercoin-paper.pdf
[6] C. LeMahieu, “Raiblocks distributed ledger network,” 2014.
[7] Y. Ribero and D. Raissar, “Dagcoin whitepaper,” 2015.
[8] S. Popov, “The tangle,” 2016.
[9] A. Back, “Hashcash - a denial of service counter-measure,” 2002.
[Online]. Available: http://www.hashcash.org/papers/hashcash.pdf
[10] C. LeMahieu, “Raiblocks,” 2014. [Online]. Available: https://github.
com/clemahieu/raiblocks
[11] D. J. Bernstein, N. Duif, T. Lange, P. Shwabe, and B.-Y. Yang,
“High-speed high-security signatures,” 2011. [Online]. Available:
http://ed25519.cr.yp.to/ed25519-20110926.pdf
[12] J.-P. Aumasson, S. Neves, Z. Wilcox-O’Hearn, and C. Winnerlein,
“Blake2: Simpler, smaller, fast as md5,” 2012. [Online]. Available:
https://blake2.net/blake2.pdf
[13] A. Biryukov, D. Dinu, and D. Khovratovich, “Argon2: The memory-hard
function for password hashing and other applications,” 2015. [Online].
Available: https://password-hashing.net/argon2-specs.pdf