diff --git a/doc/fast-sync_ES.md b/doc/fast-sync_ES.md new file mode 100644 index 000000000..d87ab298a --- /dev/null +++ b/doc/fast-sync_ES.md @@ -0,0 +1,19 @@ +# Sincronización rápida + +En Grin, llamamos "sync" al proceso de sincronizar un nuevo nodo o un nodo que no ha estado al día con la cadena durante un +tiempo, y llevarlo hasta el último bloque conocido. La Descarga Inicial de Bloques (o IBD) es usada a menudo por otras cadenas +de bloques, pero esto es problemático para Grin ya que típicamente no descarga bloques completos.. + +En resumen, una sincronización rápida en Grin hace lo siguiente: + +1. Descargar todas las cabeceras de los bloques, por trozos, en la cadena más utilizada, + tal y como lo anuncian otros nodos. +1. Encuentre una cabecera suficientemente alejada del encabezado de la cadena. Esto se denomina horizonte de nodo, ya que es lo + más lejos que un nodo puede reorganizar su cadena en una nueva bifurcación en caso de que ocurriera sin activar otra nueva + sincronización completa. +1. Descargue el estado completo tal y como estaba en el horizonte, incluyendo los datos de salida no utilizados, los datos de + pruebas de rango y del núcleo, así como todos los MMR correspondientes. Este es sólo un gran archivo zip. +1. Validar el estado total. +1. Descarga bloques completos desde el horizonte para llegar a la cabeza de la cadena. + +En el resto de esta sección, nos detendremos en cada uno de estos pasos. diff --git a/doc/intro.md b/doc/intro.md index 1e40bb16a..f1307005b 100644 --- a/doc/intro.md +++ b/doc/intro.md @@ -1,6 +1,6 @@ # Introduction to MimbleWimble and Grin -*Read this in other languages: [English](intro.md), [简体中文](intro.zh-cn.md).* +*Read this in other languages: [English](intro.md), [简体中文](intro.zh-cn.md), [Español](intro_ES.md).* MimbleWimble is a blockchain format and protocol that provides extremely good scalability, privacy and fungibility by relying on strong diff --git a/doc/intro_ES.md b/doc/intro_ES.md new file mode 100644 index 000000000..b2262fd4a --- /dev/null +++ b/doc/intro_ES.md @@ -0,0 +1,399 @@ +# Introducción a MimbleWimble y Grin + +*Lea esto en otros idiomas: [English](intro.md), [简体中文](intro.zh-cn.md).* + +MimbleWimble es un formato y un protocolo de cadena de bloques que proporciona una escalabilidad, privacidad y funcionalidad +extremadamente buenas al basarse en fuertes algoritmos criptográficos. Aborda los vacíos existentes en casi todas las +implementaciones actuales de cadenas de bloques. + +Grin es un proyecto de software de código abierto que implementa una cadena de bloques MimbleWimble y rellena los espacios +necesarios para una implementación completa de la cadena de bloques y moneda criptográfica. + +El objetivo principal y las características del proyecto Grin son: + +* Privacidad por defecto. Esto permite una funcionalidad completa sin excluir la posibilidad de revelar información de forma + selectiva cuando sea necesario. +* Se escala principalmente con el número de usuarios y mínimamente con el número de transacciones (`<100 bytes kernel`), lo + que resulta en un gran ahorro de espacio en comparación con otras cadenas de bloques. +* Criptografía robusta y probada. MimbleWimble sólo se basa en la criptografía de curvas elípticas que ha sido probada y + comprobada durante décadas. +* Simplicidad de diseño que facilita la auditoría y el mantenimiento a lo largo del tiempo. +* Dirigido por la comunidad, utilizando un algoritmo de minería resistente a la ASICs (Cuckoo Cycle) que fomenta la + descentralización de la minería. + +## Tongue Tying para todos + +Este documento está dirigido a lectores con un buen conocimiento de cadenas de bloques y de la criptografía básica. Con +esto en mente, tratamos de explicar el desarrollo técnico de MimbleWimble y cómo se aplica en Grin. Esperamos que este +documento sea comprensible para la mayoría de los lectores con visión técnica. Nuestro objetivo es animarles a interesarse en +Grin y contribuir de cualquier manera posible. + +Para lograr este objetivo, presentaremos los principales conceptos necesarios para una buena comprensión de Grin como +implementación de MimbleWimble. Comenzaremos con una breve descripción de algunas propiedades relevantes de la Criptografía +de Curva Elíptica (ECC) para sentar las bases sobre las que se basa Grin y luego describir todos los elementos clave de las +transacciones y bloques de una cadena de bloques MimbleWimble. + +### Pequeños Bits de Curvas Elípticas + +Comenzamos con una breve introducción a la Criptografía de Curva Elíptica, revisando sólo las propiedades necesarias para +entender cómo funciona MimbleWimbleWimble y sin profundizar demasiado en las complejidades de ECC. Para los lectores que +deseen profundizar en estos supuestos, existen otras opciones para [aprender más](http://andrea.corbellini.name/2015/05/17/elliptic-curve-cryptography-a-gentle-introduction/). + +Una curva elíptica con el objetivo de criptografía es simplemente un gran conjunto de puntos que llamaremos _C_. Estos puntos +pueden sumarse, restarse o multiplicarse por números enteros (también llamados escalares). Dado un entero _k_ y +usando la operación de multiplicación escalar podemos calcular `k*H`, que es también un punto en la curva _C_. Dado otro +entero _j_ también podemos calcular `(k+j)*H`, que es igual a `k*H + j*H`. Las operaciones de suma y multiplicación escalar +en una curva elíptica mantienen las propiedades conmutativas y asociativas de suma y multiplicación: + + (k+j)*H = k*H + j*H + +En ECC, si escogemos un número muy grande _k_ como clave privada, `k*H` se considera la clave pública correspondiente. +Incluso si uno conoce el valor de la clave pública `k*H`, deducir _k_ es casi imposible (o dicho de otra manera, mientras que +la multiplicación es trivial, la "división" por puntos de curva es extremadamente difícil). + +La fórmula anterior `(k+j)*H = k*H + j*H`, con _k_ y _j_ ambas claves privadas, demuestra que una clave pública obtenida de +la adición de dos claves privadas (`(k+j)*H`) es idéntica a la adición de las claves públicas para cada una de esas dos +claves privadas (`k*H + j*H`). En la cadena de bloques Bitcoin, las carteras jerárquicas deterministas se basan en gran +medida en este principio. MimbleWimble y la implementación de Grin también lo hacen. + +### Transacciones con MimbleWimble + +La estructura de las transacciones demuestra un principio crucial de MimbleWimble: +fuertes garantías de privacidad y confidencialidad. + +La validación de las transacciones de MimbleWimbleWimble se basa en dos propiedades básicas: + +* **Verificación de importes nulos.** La suma de las salidas menos las entradas siempre es igual a cero, lo que demuestra que + la transacción no creó nuevos fondos, _sin revelar los importes reales_. +* **Posesión de las claves privadas.** Como con la mayoría de las otras monedas criptográficas, la propiedad de los + resultados de las transacciones está garantizada por la posesión de claves privadas ECC. Sin embargo, la prueba de que una + entidad es propietaria de esas claves privadas no se consigue firmando directamente la transacción. + +Las siguientes secciones sobre el saldo, la propiedad, el intercambio y las verificaciones detallan cómo se logran esas dos +propiedades fundamentales. + +#### Balance + +Basándose en las propiedades de ECC que hemos descrito anteriormente, uno puede ocultar los valores en una transacción. + +Si _v_ es el valor de una transacción de entrada o salida y _H_ una curva elíptica, podemos simplemente insertar `v*H` en +lugar de _v_ en una transacción. Esto funciona porque usando las operaciones ECC, todavía podemos validar que la suma de las +salidas de una transacción es igual a la suma de las entradas: + + v1 + v2 = v3 => v1*H + v2*H = v3*H + +Verificar esta propiedad en cada transacción permite que el protocolo verifique que una transacción no crea dinero de la +nada, sin saber cuáles son los valores reales. Sin embargo, hay un número finito de valores útiles y uno podría intentar cada +uno de ellos para adivinar el valor de su transacción. Además, conocer v1 (de una transacción anterior por ejemplo) y el +resultado `v1*H` revela todas las salidas con valor v1 a lo largo de la cadena de bloques. Por estas razones, introducimos +una segunda curva elíptica _G_ (prácticamente _G_ es sólo otro punto del generador en el mismo grupo de curvas que _H_) y una +clave privada _r_ utilizada como *factor de ocultación*. + +Un valor de entrada o de salida en una operación puede expresarse como: + + r*G + v*H + +Donde: + +* _r_ es una clave privada utilizada como factor de ocultación, _G_ es una curva elíptica y su producto `r*G` es la clave +pública para _r_ en _G_. +* _v_ es el valor de una entrada o salida y _H_ es otra curva elíptica. + +No se puede deducir ni _v_ ni _r_, aprovechando las propiedades fundamentales de la criptografía de curva elíptica. `R*G + v*H` se llama _Compromiso Pedersen_. + +Por ejemplo, supongamos que queremos construir una transacción con dos entradas y una salida. Tenemos (ignorando las cuotas): + +* vi1 and vi2 como valores de entrada. +* vo3 como valores de salida. + +De tal forma que: + + vi1 + vi2 = vo3 +Generando una clave privada como factor de ocultación para cada valor de entrada y sustituyendo cada valor por sus +respectivos Compromisos de Pedersen en la ecuación anterior, obtenemos: + + (ri1*G + vi1*H) + (ri2*G + vi2*H) = (ro3*G + vo3*H) + +Lo cual, requiere como consecuencia que: + + ri1 + ri2 = ro3 + +Este es el primer pilar de MimbleWimble: la aritmética necesaria para validar una transacción se puede hacer sin conocer +ninguno de los valores. + +Como nota final, esta idea se deriva en realidad de Greg Maxwell's +[Transacciones confidenciales](https://www.elementsproject.org/elements/confidential-transactions/), +que a su vez se deriva de una propuesta de Adam Back para valores homomórficos aplicados a Bitcoin. + +#### Propiedad + +En la sección anterior introducimos una clave privada como factor de ocultación para cubrir los valores de la transacción. La +segunda idea de MimbleWimble es que esta clave privada puede ser utilizada para probar la propiedad del valor. + +Alice te envía 3 monedas y para ocultar esa cantidad, elegiste 28 como tu factor de ocultación (nota que en la práctica, +siendo el factor de ocultación una llave privada, es un número extremadamente grande). En algún lugar de la cadena de +bloques, la siguiente salida aparece y sólo debe ser utilizable por usted: + + X = 28*G + 3*H + +_X_, el resultado de la suma, es visible para todos. El valor 3 sólo lo conocen usted y Alice, y el valor 28 sólo lo conocerá usted. + +Para volver a transferir esas 3 monedas, el protocolo exige que se conozcan de alguna manera. Para demostrar cómo funciona +esto, digamos que usted quiere transferir esas 3 mismas monedas a Carol. Es necesario construir una transacción simple como +esa: + + Xi => Y + +Donde _Xi_ es una entrada que utiliza su salida _X_ e Y es la salida de Carol. No hay manera de construir tal transacción y +equilibrarla sin conocer su clave privada de 28. De hecho, si Carol va a equilibrar esta transacción, necesita saber tanto el +valor enviado como su clave privada para poder hacerlo: + + Y - Xi = (28*G + 3*H) - (28*G + 3*H) = 0*G + 0*H + +Comprobando que todo ha sido puesto a cero, podemos asegurarnos de nuevo de que no se ha creado ningún dinero nuevo. + +Espera! para! ahora ya conoces la clave privada en la salida de Carol (que, en este caso, debe ser la misma que la tuya para +equilibrarla) y así podrías robarle el dinero a Carol! + +Para resolver esto, Carol utiliza una clave privada de su elección. +Ella escoge 113, y lo que termina en la cadena es: + + Y - Xi = (113*G + 3*H) - (28*G + 3*H) = 85*G + 0*H + +Ahora la transacción ya no suma cero y tenemos un _exceso de valor_ en _G_ (85), que es el resultado de la suma de todos los +factores de ocultamiento. Pero porque `85*G` es una clave pública válida en la curva elíptica _G_, con clave privada 85, para +cualquier x e y, sólo si `y = 0` es `x*G + y*H` una clave pública válida en _G_. + +Así que todo lo que el protocolo necesita verificar es que (`Y - Xi`) es una clave pública válida en _G_ y que las partes que +realizan la transacción conocen en conjunto la clave privada (85 en nuestra transacción con Carol). La forma más sencilla de +hacerlo es requerir una firma construida con el valor excedente (85), que luego lo valida: + +* Las partes que realizan la transacción conocen colectivamente la clave privada, y +* La suma de las salidas de transacción, menos las entradas, suma a un valor cero (porque sólo una clave pública válida, que +coincida con la clave privada, se comprobará con la firma) + +Esta firma, que se adjunta a cada transacción, junto con algunos datos adicionales (como las tasas de explotación minera), se +denomina _transacción de kernel_ y es comprobada por todos los validadores. + +#### Algunos puntos más precisos + +Esta sección explica con más detalle la creación de transacciones discutiendo cómo se introduce el cambio y el requisito de pruebas de rango para que se demuestre que todos los valores no son negativos. Ninguno de los dos es absolutamente necesario para entender MimbleWimbleWimble y Grin, así que si tienes prisa, no dudes en ir directamente a +[Poniendo todo junto](https://github.com/wimel/grin/blob/master/doc/intro.md#putting-it-all-together). + +##### Cambio + +Digamos que sólo quieres enviar 2 monedas a Carol de las 3 que recibiste de Alice. Para hacer esto enviarías la moneda +restante a ti mismo como cambio. Se genera otra clave privada (digamos 12) como un factor oculto para proteger la salida de +modificación. Carol usa su propia clave privada como antes. + + Change output: 12*G + 1*H + Carol's output: 113*G + 2*H + +Lo que termina en la cadena de bloques es algo muy similar a lo que había antes. +Y la firma se construye de nuevo con el valor excedente, 97 en este ejemplo. + + (12*G + 1*H) + (113*G + 2*H) - (28*G + 3*H) = 97*G + 0*H + +##### Pruebas de recorrido + +En todos los cálculos anteriores, confiamos en que los valores de las transacciones sean siempre positivos. La introducción +de cantidades negativas sería extremadamente problemática, ya que se podrían crear nuevos fondos en cada transacción. + +Por ejemplo, se podría crear una transacción con una entrada de 2 y salidas de 5 y -3 y aún así obtener una transacción bien +equilibrada, siguiendo la definición de las secciones anteriores. Esto no puede ser fácilmente detectado porque incluso si +_x_ es negativo, el punto correspondiente `x.H` en la curva se ve como cualquier otro. + +Para resolver este problema, MimbleWimble utiliza otro concepto criptográfico (también procedente de Transacciones +Confidenciales) llamado pruebas de rango: una prueba de que un número está dentro de un rango dado, sin revelar el número. No +daremos más detalles sobre la prueba de rango, pero sólo necesitas saber que para cualquier `r.G + v.H` podemos construir una +prueba que demuestre que _v_ es mayor que cero y no se sobrecarga. + +También es importante tener en cuenta que para crear una prueba de rango válida a partir del ejemplo anterior, deben +conocerse tanto los valores 113 como 28 utilizados al crear y firmar el exceso de valor. La razón de ello, así como una +descripción más detallada de las pruebas de rango, se detallan en la sección [range proof paper](https://eprint.iacr.org/2017/1066.pdf). + +#### Poniendo todo junto + +Una transacción MimbleWimble incluye lo siguiente: + +* Un conjunto de entradas, que hacen referencia y consumen un conjunto de salidas anteriores. +* Un conjunto de nuevos resultados que incluyen: +* Un valor y un factor oculto (que es sólo una nueva clave privada) multiplicados en una curva + y sumados para ser `r.G + v.H`. +* Una prueba de rango que muestra que v no es negativo. +* Una comisión explícita de transacción, en compensación.. +* Una firma, que se calcula tomando el exceso de valor oculto (la suma de todas las salidas más la tarifa, menos las + entradas) y utilizándolo como clave privada. + +### Bloques y estado de la cadena + +Hemos explicado anteriormente cómo las transacciones de MimbleWimble pueden proporcionar fuertes garantías de anonimato a la +vez que mantienen las propiedades requeridas para una cadena de bloques válida, es decir, una transacción no crea dinero y la +prueba de la propiedad se establece a través de claves privadas. + +El formato de bloques MimbleWimble se basa en esto introduciendo un concepto adicional: _cut-through_. Con esta incorporación, una cadena MimbleWimble gana: + +* Extremadamente buena escalabilidad, ya que la gran mayoría de los datos de las transacciones pueden ser eliminados con el + tiempo, sin comprometer la seguridad. +* Mayor anonimato al mezclar y eliminar datos de transacciones. +* Y la capacidad de los nuevos nodos para sincronizarse con el resto de la red de forma muy eficiente. + +#### Agrupación de transacciones + +Recuerde que una transacción consiste en lo siguiente - + +* un conjunto de entradas que hacen referencia y gastan un conjunto de realizaciones anteriores +* un conjunto de nuevos resultados (compromisos de Pedersen) +* un kernel de transacción, que consta de + * kernel excess (compromiso de Pedersen a cero). + * firma de la transacción (usando el exceso de kernel como clave pública). + +Se firma una tx y se incluye la firma en un _transaction kernel_. La firma se genera utilizando el _kernel excess_ como clave pública, lo que prueba que la transacción suma 0. + + (42*G + 1*H) + (99*G + 2*H) - (113*G + 3*H) = 28*G + 0*H + +La clave pública en este ejemplo es `28*G`. + +Podemos decir que lo siguiente es cierto para cualquier transacción válida (ignorando los cargos por simplicidad) - + + sum(outputs) - sum(inputs) = kernel_excess + +Lo mismo ocurre con los bloques mismos una vez que nos damos cuenta de que un bloque es simplemente un conjunto de entradas, +salidas y núcleos de transacción agregados. Podemos sumar las salidas tx, restar la suma de las entradas tx y comparar el +compromiso resultante de Pedersen con la suma de los excesos del núcleo. - + + sum(outputs) - sum(inputs) = sum(kernel_excess) + +Simplificando un poco, (de nuevo ignorando las tarifas de transacción) podemos decir que los bloques MimbleWimble pueden ser +tratados exactamente como transacciones MimbleWimble. + +#### Kernel Offsets + +Hay un problema leve con los bloques y las transacciones de MimbleWimble como se describe anteriormente. Es posible (y en +algunos casos trivial) reconstruir las transacciones constituyentes en un bloque. Esto es claramente malo para la privacidad. +Este es el problema del "subconjunto" - dado un conjunto de entradas, salidas y núcleos de transacción, un subconjunto de +estos se recombinará para reconstruir una transacción válida. + +Por ejemplo, teniendo en cuenta las dos transacciones siguientes - + + (in1, in2) -> (out1), (kern1) + (in3) -> (out2), (kern2) + +Podemos agregarlos en el siguiente bloque (o transacción agregada) - + + (in1, in2, in3) -> (out1, out2), (kern1, kern2) + +Es relativamente fácil intentar todas las permutaciones posibles para recuperar una de las transacciones +(donde se suma con éxito a cero). - + + (in1, in2) -> (out1), (kern1) + +También sabemos que todo lo que queda puede ser usado para reconstruir la otra transacción válida.- + + (in3) -> (out2), (kern2) + +Para mitigar esto, incluimos un _kernel offset_ con cada transacción del kernel. Este es un factor oculto (clave privada) que +debe añadirse de nuevo al exceso de núcleo para verificar que la suma de los compromisos sea cero. - + + sum(outputs) - sum(inputs) = kernel_excess + kernel_offset + +Cuando agregamos transacciones en un bloque, almacenamos un único offset de agregados en el encabezado del bloque. Y ahora +tenemos una única compensación que no puede descomponerse en las compensaciones del núcleo de transacciones individuales y +las transacciones ya no pueden reconstruirse. - + + sum(outputs) - sum(inputs) = sum(kernel_excess) + kernel_offset + +"Dividimos" la clave `k` en `k1+k2` durante la construcción de la transacción. Para una transacción kernel `(k1+k2)*G` publicamos `k1*G` (el exceso) y `k2` (el offset) y firmamos la transacción con `k1*G` como antes. +Durante la construcción del bloque podemos simplemente sumar las compensaciones `k2` para generar una sola compensación +agregada `k2` para cubrir todas las transacciones en el bloque. La compensación `k2` para cualquier transacción individual es +imposible de recuperar. + +#### Cortado a medida + +Los bloques permiten a los mineros ensamblar múltiples transacciones en un solo conjunto que se añade a la cadena. En las +siguientes representaciones en bloque, que contienen 3 transacciones, sólo se muestran las entradas y salidas de las +transacciones. Los ingresos hacen referencia a las salidas que gastan. Una salida incluida en un bloque anterior está marcada +con una x minúscula. + + I1(x1) --- O1 + |- O2 + + I2(x2) --- O3 + I3(O2) -| + + I4(O3) --- O4 + |- O5 + +Observamos las dos propiedades siguientes: + +* Dentro de este bloque, algunas salidas son gastadas directamente por las entradas incluidas (I3 gasta O2 e I4 gasta O3). +* La estructura de cada transacción no importa realmente. Como todas las transacciones se suman individualmente a cero, la + suma de todas las entradas y salidas de transacciones debe ser cero. + +Al igual que en una transacción, todo lo que hay que comprobar en un bloque es que la propiedad ha sido probada (que proviene +de _núcleos de transacción_) y que todo el bloque no ha añadido ninguna cantidad de fondos (aparte de lo que permite la base +de datos de la moneda). +Por lo tanto, se pueden eliminar las entradas y salidas que coincidan, ya que su contribución a la suma total se anula. Lo +que conduce a los siguientes bloques, mucho más compactos: + + I1(x1) | O1 + I2(x2) | O4 + | O5 + +Tenga en cuenta que se ha eliminado toda la estructura de transacciones y que el orden de las entradas y salidas ya no +importa. Sin embargo, la suma de todas las salidas de este bloque, menos las entradas, sigue siendo cero. + +Un bloque se contruye simplemente a partir de: + +* Una cabecera de bloque. +* La lista de entradas que quedan después del corte. +* La lista de las salidas que quedan después del corte. +* Un único offset del kernel para cubrir todo el bloque. +* Los núcleos de transacción que contienen, para cada transacción: + * La clave pública `r*G` obtenida de la suma de todos los pagos. + * Las firmas creadas utilizando el exceso de valor. + * La tasa minera. + +Con esta estructura, un bloque MimbleWimble ofrece unas garantías de privacidad muy buenas: + +* Las transacciones intermedias (cut-through) estarán representadas únicamente por sus núcleos de transacciones. +* Todas las salidas se ven iguales: sólo números muy grandes que son imposibles de diferenciar entre sí. Si uno quisiera + excluir algunas salidas, tendrían que excluir todas. +* Se ha eliminado toda la estructura de la transacción, lo que hace imposible saber qué salida se correspondía con cada + entrada. + +Y sin embargo, todo esto sigue confirmándose! + +#### Atravesado todo el camino + +Volviendo al bloque de ejemplo anterior, las salidas x1 y x2, gastadas por I1 e I2, deben haber aparecido previamente en la +cadena de bloques. Así que después de la adición de este bloque, esas salidas, así como I1 e I2, también pueden ser +eliminadas de la cadena global, ya que no contribuyen a la suma total. + +Concluimos que, generalizando, el estado de la cadena (excluyendo las cabeceras) en cualquier momento puede ser resumido sólo +por estas piezas de información: + +1. La cantidad total de monedas creadas por la minería en la cadena. +2. El conjunto completo de resultados no utilizados. +3. Los núcleos de transacciones para cada transacción. + +La primera información se puede deducir simplemente usando la altura del bloque (su distancia del bloque génesis). Y tanto +las salidas no utilizadas como los núcleos de transacción son extremadamente compactos. Esto tiene dos consecuencias +importantes: + +* El estado que un nodo dado en una cadena de bloques MimbleWimble necesita mantener es muy pequeño (del orden de unos pocos + gigabytes para una cadena del tamaño de Bitcoin, y potencialmente configurable a unos pocos centenares de megabytes). +* Cuando un nuevo nodo se une a una red formando una cadena MimbleWimble, la cantidad de información que necesita ser + transferida es también muy pequeña.. + +Además, el conjunto completo de resultados no utilizados no puede ser alterado, ni siquiera añadiendo o quitando un +resultado. Hacerlo haría que la suma de todos los factores de ocultación en los núcleos de la transacción difiriera de la +suma de la ocultación, factores que influyen en los resultados. + +### Conclusión + +En este documento tratamos los principios básicos que subyacen a una cadena de bloques MimbleWimble. Utilizando las +propiedades de suma de la Criptografía de Curva Elíptica, somos capaces de construir transacciones que son completamente +opacas pero que todavía pueden ser validadas adecuadamente. Y al generalizar esas propiedades a bloques, podemos eliminar una +gran cantidad de datos de la cadena de bloques, lo que permite una gran escalabilidad y una sincronización rápida de nuevos +participantes.