馃嚜馃嚫 La escalabilidad de la blockchain y el enfoque de Cardano al respecto

:es: Traducci贸n al espa帽ol de Blockchain scalability and Cardano approach to it

Publicado por Cardanians en el foro de Cardano, el 13 de Enero de 2020.


La blockchain p煤blica lucha con la adopci贸n. Una mayor adopci贸n depende cr铆ticamente de la capacidad del protocolo para escalar. Expliquemos exactamente qu茅 es la escalabilidad, y veamos las diferencias entre PoS y PoW.


La escalabilidad de la caja registradora no es buena aqu铆.

C贸mo definir la escalabilidad

La definici贸n est谩ndar en la wiki podr铆a sonar as铆:

La escalabilidad es la propiedad de cualquier sistema para manejar una cantidad creciente de trabajo a帽adiendo m谩s recursos al sistema.

La escalabilidad es la capacidad de manejar m煤ltiples peticiones a medida que la base de usuarios crece. El crecimiento de los usuarios a menudo alcanza el punto en el que los recursos necesitan ser incrementados para mantener la calidad del servicio en el nivel esperado. El aumento de la escalabilidad a menudo implica costos adicionales.

Son pocos los servicios o protocolos que se construyen desde el principio para su adopci贸n masiva. El 茅xito del servicio es dif铆cil de predecir de antemano. Por lo tanto, el n煤mero de usuarios s贸lo se estima de antemano y el servicio se lanza. A medida que el servicio se hace m谩s popular, los usuarios pueden ver una disminuci贸n en la respuesta, por ejemplo. Esto se debe a que el n煤mero de usuarios est谩 creciendo y el hardware existente est谩 sobrecargado, y no logra manejar las solicitudes de los nuevos usuarios.

Probemos una analog铆a del mundo real. Imagina un empleado en la oficina de correos. El empleado puede manejar 10 clientes por hora. Con un tiempo de trabajo de ocho horas, son 80 clientes al d铆a. Si 50 personas al d铆a vienen a la oficina de correos, el empleado llevar谩 bien su trabajo. Una vez que ingresen 100 clientes por d铆a, el empleado dif铆cilmente se detendr谩. Sin embargo, tan pronto como 200 personas al d铆a visiten la oficina de correos, el empleado no podr谩 soportar la avalancha de trabajo. Los clientes no estar谩n satisfechos y el empleado probablemente se enfermar谩.

DMOb0Nkk74avsyOeDf4IRxgiYaN37IF3sO6_sMVg0eWJpU5I5GLVaAeC2lg4lN1uoOev5KXzm29UXTWwxfQFYL05I7YyHLwQGWahy33Zpa-JN8-sqkiN1YJqlQrp6vohgLs19GOk
Piensa en ello como poner las transacciones en un mem-pool.

Puedes pensar en un empleado como una capacidad de red que puede manejar un cierto n煤mero de usuarios por d铆a. Es una capacidad de oficina de correos en el mundo real. Piensa en los clientes como transacciones. Por lo tanto, el rendimiento de la red puede medirse en t茅rminos del n煤mero de transacciones que se manejan durante un per铆odo de tiempo, como las transacciones por segundo (TPS). En nuestra analog铆a, esto ser铆a el n煤mero de clientes por d铆a (CPD).

En el mundo tradicional de los servicios de red centralizados (cliente-servidor), el hardware puede escalar vertical y horizontalmente. El escalado vertical significa a帽adir m谩s potencia de c谩lculo y memoria al sistema. El escalado horizontal implica a帽adir nuevos nodos al sistema que har谩n el mismo trabajo. Se puede escalar vertical y horizontalmente simult谩neamente.

En nuestra analog铆a, podemos ayudar al oficinista comprando un ordenador m谩s r谩pido, utilizando una base de datos m谩s r谩pida, o sustituyendo una m谩quina de escribir tradicional por un ordenador. Eso ser铆a escalar verticalmente. O podemos escalar horizontalmente, lo que implicar铆a el ingreso de otro empleado. En el caso del escalado horizontal, un empleado podr铆a manejar 20 clientes m谩s por d铆a y llegar铆a hasta 100 clientes satisfechos por d铆a. En el caso del escalado vertical, dos empleados podr铆an manejar 160 clientes por d铆a, tres empleados unos 240 clientes, y as铆 sucesivamente.

Problemas de escalado en la blockchain

La blockchain se apoya en una red distribuida que requiere de un consenso mayoritario para cambiar los datos. Esto complica enormemente la escalabilidad, ya que lo ideal es que la decisi贸n se tome en varios lugares en un per铆odo de tiempo reducido.

Volvamos a nuestra analog铆a. Imagina que todos los empleados tienen que reunirse al final del d铆a en una oficina para validar mutuamente el trabajo que han realizado para los clientes. Todos confirman o rechazan cada documento. En el caso de dos empleados, cada empleado tendr铆a que inspeccionar y aprobar 80 documentos de su colega, adem谩s de su trabajo. Y un error en los documentos resultar铆a en el rechazo del trabajo de todo el d铆a (an谩logo a un bloque de transacciones). Ahora imagina que estos empleados no se sientan en una oficina, sino que tienen que enviarse los documentos unos a otros, y luego enviar una respuesta. El trabajo ser铆a muy lento, y a帽adir un nuevo empleado s贸lo incrementar铆a la complejidad.

A帽adir un nuevo nodo a la red o aumentar su rendimiento puede que no afecte en absoluto el rendimiento de la red. El rendimiento puede incluso deteriorarse ya que se tendr谩 que lograr un consenso entre m煤ltiples entidades, lo cual siempre es m谩s dif铆cil. Los nodos que participan en el consenso est谩n distribuidos globalmente y necesitan datos para tomar una decisi贸n. Lleva tiempo distribuir los datos en todo el mundo. El protocolo debe ser dise帽ado para minimizar los requerimientos de comunicaci贸n.

En el caso de las redes de consenso distribuidas, la capacidad de la red y la velocidad de transferencia de datos son una gran limitaci贸n. Razonablemente, s贸lo unos pocos MB en decenas de segundos pueden ser distribuidos en todo el mundo. Al mismo tiempo, cuanto m谩s grande sea el bloque de datos, m谩s lento se propaga y la velocidad general de la red en un dise帽o dado puede estar limitada por el nodo m谩s lento (el m谩s lejano o con una mala conexi贸n a internet). Si la red va a ser r谩pida (para conseguir una transacci贸n r谩pida y un bloque creado), es necesario tratar de reducir el tiempo por bloque.

Supongamos que una transacci贸n regular puede tener 250 bytes. Por lo tanto, 1 MB puede contener unas 4.000 transacciones. Si el tiempo por bloque es de 10 minutos y lo convertimos en transacciones por segundo, llegamos a 6.66 TPS. Si el tiempo de bloque es de 20 segundos, obtenemos 200 TPS con el mismo tama帽o de bloque.

Algunos protocolos de consenso funcionan votando para a帽adir un bloque dentro de un grupo cerrado. Un nodo aleatorio propone un bloque y el resto de nodos (incluido el proponente) se interesan por lo que otros piensan sobre el bloque propuesto y, en base a los resultados, a帽aden o no el bloque a la blockchain. La complejidad aumenta con el n煤mero de nodos. Por lo tanto, es necesario establecer el l铆mite m谩ximo del n煤mero de nodos involucrados en el consenso. Uno de los otros enfoques es el concepto de un proponente de bloque elegido al azar, siendo los dem谩s como los aprobadores. No hay una comunicaci贸n compleja entre los nodos y, por lo tanto, el n煤mero de nodos no est谩 limitado. Existen otros enfoques, donde algunos ni siquiera trabajan con el concepto de bloques. Los bloques son muy adecuados para la sincronizaci贸n interna del protocolo, pero no son una condici贸n para construir una red distribuida consensuada.

Trilema de la blockchain

El famoso trilema de la blockchain es uno de los mayores obst谩culos para las criptomonedas. El trilema es b谩sicamente un conjunto triple de propiedades por las que podemos juzgar la calidad de una red distribuida. Estas caracter铆sticas son la escalabilidad discutida en este art铆culo, el grado de descentralizaci贸n, y la seguridad.


Trilema de la blockchain.

En el contexto de las redes distribuidas, y especialmente en el caso de la blockchain, los proyectos a menudo utilizan el concepto de una entidad seleccionada aleatoriamente que propone un bloque de transacciones, y todos los dem谩s nodos sirven como cuerpo de control (como mencionamos anteriormente). El derecho a crear un bloque rota aleatoriamente entre nodos o pools.

El grado de descentralizaci贸n puede ser juzgado por el n煤mero de entidades que pueden adquirir el derecho de seleccionar transacciones y ponerlas en un nuevo bloque. Adem谩s, es posible juzgar el n煤mero de nodos que s贸lo validan estos bloques y los agregan en su cadena. Cabe se帽alar que el derecho a crear un nuevo bloque es mucho m谩s importante que el derecho a validar los bloques propuestos, ya que los proponentes de los bloques producen activamente nuevos bloques, mientras que los validadores s贸lo controlan esta tarea y no pueden crear r谩pidamente un bloque en caso de problema.

Para considerar un protocolo como seguro, un protocolo debe ser resistente a corto plazo, e inmutable a largo plazo. El protocolo tiene que ser capaz de prevenir y ser capaz de recuperarse de ataques a corto plazo, sin tener que hacer cambios en los estados previos del ledger distribuido. El ledger debe permanecer inmutable.

C贸mo escalar un proyecto

Como puedes ver, el equipo del proyecto no s贸lo puede mejorar la escalabilidad, sino que tambi茅n debe mantenerlo fuerte en t茅rminos de descentralizaci贸n y seguridad. El equipo tiene que equilibrar bien estas cualidades. Esto hace que sea muy dif铆cil mejorar la escalabilidad. El equipo siempre debe buscar mantener un alto nivel de descentralizaci贸n y seguridad.

Los esfuerzos para incrementar la escalabilidad a menudo resultan en una reducci贸n de la descentralizaci贸n. Un proyecto con una baja descentralizaci贸n dif铆cilmente pueda considerarse seguro. La descentralizaci贸n es una caracter铆stica clave en las redes distribuidas. El derecho a producir bloques no debe fijarse en un n煤mero bajo, como puede verse en los proyectos DPoS (por ejemplo: 21 en EOS, 26 en Tron). O, para decirlo de otra manera, la cuesti贸n es hasta qu茅 punto el sistema puede ser considerado como descentralizado.

Algunos proyectos no tienen un n煤mero limitado de creadores de bloques, pero la red puede tender a ser centralizada al delegar el poder de manera desigual a una entidad (mayormente un pool). Esto se puede observar en los proyectos de PoW y PoS. Si las redes trabajan alrededor del concepto de pool, es decir, con un pool en el que otros participantes del consenso de la red delegan el poder a trav茅s del hash-rate o monedas, es importante que los proyectos se enfrenten de alguna manera al creciente poder de los pools.

Tenemos un aspecto m谩s que exponer. Para conseguir un alto rendimiento, la red necesita un hardware potente y debe ser usado sabiamente. Si el n煤mero de nodos es fijo, como es el caso de DPoS, existen una presi贸n para que los nodos sean muy potentes. Por lo tanto, los nodos son econ贸micamente asequibles para un grupo limitado de personas, y por ende la red puede tender a aumentar la centralizaci贸n. Desde el punto de vista de la descentralizaci贸n, es inteligente abordar el escalado de la red de tal manera que al aumentar el n煤mero de nodos promedio tambi茅n se incremente la capacidad de manejar m谩s transacciones. A medida que la red se utiliza m谩s, es natural escalar mediante la incorporaci贸n de nuevo hardware. La descentralizaci贸n no debe ser sacrificada. Una red distribuida bien dise帽ada deber铆a estar compuesta por un gran n煤mero de nodos independientes y asequibles, y al mismo tiempo ser capaz de aumentar el rendimiento de las transacciones. Esto es un gran desaf铆o.

El PoW y el PoS son sistemas muy similares en el sentido de que las personas delegan el poder a pools seleccionados. Los propietarios de los pools tienen sus propios hash-rates o monedas, por lo que pueden mantener su posici贸n a trav茅s de su riqueza. En general, si tienes poder, puedes fortalecer f谩cilmente tu posici贸n. En el caso de las redes distribuidas, este es el caso, ya que los operadores de los pools reciben comisiones por su servicio.


PoW es seguro, pero su escalabilidad y descentralizaci贸n no son tan buenas.

La incorporaci贸n de un nodo completo a una red PoW no incrementa la capacidad de manejar m谩s transacciones. La mayor铆a de los nodos completos s贸lo validan los bloques que producen los pools. Sin embargo, al agregar un nuevo minero ASIC la red se vuelve m谩s segura en t茅rminos de ataques de hash-rates. La adici贸n de un nodo completo o de un minero ASIC s贸lo aumenta la seguridad del consenso. La descentralizaci贸n o la escalabilidad no aumentan.

En cuanto al modelo econ贸mico, s贸lo las personas que compran mineros ASIC pueden participar en el consenso y en la seguridad de la red, y son recompensadas. Los propietarios de nodos completos no son recompensados econ贸micamente por la red. La motivaci贸n para obtener un nodo completo es simplemente un deseo de mayor libertad financiera. Sin embargo, esta es una buena motivaci贸n, y muchas personas lo hacen.

En PoW, la mayor parte del valor de las nuevas monedas se destina a cubrir el costo de la miner铆a. Hoy en d铆a, la miner铆a est谩 centralizada en grandes salas, y los mineros dom茅sticos son raros. La desventaja de PoW es que el operador del pool est谩 motivado econ贸micamente para aumentar su cuota de potencia, porque cuanto mayor sea el hash-rate del pool, m谩s recompensas obtendr谩. No hay un l铆mite m谩ximo en el tama帽o del pool. Dado que el hash-rate puede crecer continuamente, es dif铆cil definir este l铆mite. En PoW, es muy caro crear un nuevo pool y obtener una cuota del 5% del hash-rate total.

Como probablemente sepas, PoW es muy seguro porque hay que encontrar el hash adecuado, lo que lleva un promedio de 10 minutos. S贸lo podemos considerar aumentar el tama帽o del bloque, pero hay opciones limitadas por la latencia de la red y la equidad del consenso. Por lo tanto, el escalado en la primera capa es casi imposible para las redes PoW. Al mismo tiempo, la descentralizaci贸n no es demasiado alta gracias a la existencia de grandes pools, y a la ausencia de mecanismos para disminuir su potencia.


En este caso, la red no a帽adir铆a un bloque.

En Cardano, la red es propiedad de los tenedores de ADA, es decir, de las partes interesadas. Esto tiene ventajas tanto en t茅rminos de descentralizaci贸n como de escalabilidad. La red est谩 descentralizada por todas las partes interesadas, de modo que cuanto m谩s aumente la distribuci贸n de monedas, m谩s se descentralizar谩 el consenso de la red. Y debido a que el consenso recompensa no s贸lo a los propietarios de los stale pools sino tambi茅n a todos los propietarios de monedas que delegan sus ADA en un stake pool determinado, las personas est谩n econ贸micamente motivadas para adquirir y poseer monedas. Los propietarios de nodos completos tambi茅n son recompensados por la red por su participaci贸n en el consenso si delegan las ADA a un pool.

Con PoS casi no hay necesidad de pagar por la energ铆a, por lo que si la red es 煤til y maneja un gran n煤mero de transacciones, la red cubrir谩 f谩cilmente sus costos. Adem谩s, tambi茅n habr谩 suficiente financiamiento para recompensar a los participantes. Mantener monedas puede ser muy conveniente.

Para evitar el problema de crear s贸lo unos pocos grandes pools, existe el concepto de saturaci贸n de los mismos. La saturaci贸n es la capacidad de un protocolo para definir el n煤mero requerido (no obligatorio) de pools, y para fomentar ese requerimiento mediante est铆mulos econ贸micos. Si el requerimiento se fija en 1000, el sistema funcionar谩 mejor econ贸micamente si hay 1000 pools de igual tama帽o. La gente puede elegir activamente un pool de acuerdo con las comisiones del pool, su reputaci贸n, tama帽o y otros par谩metros.

Una entidad podr谩 comprar grandes cantidades de monedas y crear m煤ltiples pools a trav茅s de su propio patrimonio (sin necesidad de depender de los delegantes y sus monedas). Esto no se puede prevenir y lo veremos en la pr谩ctica. Sin embargo, gracias al concepto de saturaci贸n, ser谩 relativamente f谩cil crear un nuevo pool. Por ejemplo, con s贸lo una mil茅sima parte del n煤mero de monedas delegadas ser谩 suficiente para crear un nuevo pool de pleno rendimiento.


PoS no requiere tanta energ铆a. La criptograf铆a moderna puede hacer bien el mismo trabajo de otra manera.

Como se ver谩 con m谩s detalle a continuaci贸n, en t茅rminos de escalabilidad, el protocolo se dise帽a en su primera fase de manera que la red da derecho a uno de los 1000 pools de producir un nuevo bloque. El bloque se propaga entonces s贸lo a otros nodos para que lo validen. La distribuci贸n del bloque aprueba as铆 el bloque a trav茅s de la red. No hay un debate complicado entre los nodos sobre la aceptaci贸n del bloque. En realidad es muy similar al sistema PoW. La 煤nica diferencia es que la propia red de Cardano decide qui茅n se encargar谩 de la creaci贸n de los bloques (determinando el l铆der del slot). Esto puede reducir el tiempo del bloque a segundos (20 segundos en la red de prueba de Shelley). El ajuste del punto de saturaci贸n puede ser cambiado y puede ser f谩cilmente incrementado. Es posible fijarlo en 2000 o 5000, por lo que ser谩 econ贸micamente ventajoso para detectar m谩s pools. Esto puede dar al sistema la potencia de c谩lculo necesaria. Adem谩s, con este elevado n煤mero de entidades independientes, puede haber fragmentaci贸n y no se sacrificar谩 la descentralizaci贸n.

El sharding es la capacidad de un protocolo para llegar a un consenso paralelo distribuido. Imagina, por ejemplo, que la red se divide en m煤ltiples fragmentos (partes) en los que las transacciones ser谩n aprobadas y, finalmente, la red se asegura de que todos los fragmentos hayan alcanzado un consenso honesto. El fragmento puede ser una elegante soluci贸n de escalabilidad de primera capa. El sharding se describir谩 en nuestro otro art铆culo.

El consenso de Cardano

En el PoS de Cardano, podemos observar la siguiente secuencia de consenso:

  1. Al inicio de cada epoch, la red decide qui茅nes ser谩n los l铆deres de los slots. La selecci贸n se basa en las monedas ADA delegadas. La red apunta a alg煤n Lovelace que tiene un pool determinado (el pool en el que el Lovelace est谩 delegando). El proceso se ejecuta por adelantado.
  2. Se acaba de a帽adir el 煤ltimo bloque. La red se desplaza a otro slot para que un nuevo nodo pueda producir un bloque.
  3. Los nodos consultan si han adquirido el derecho de producir un bloque en un slot determinado. Si es as铆, el nodo obtiene la prueba de haber ganado el derecho.
  4. El pool seleccionado (l铆der del slot) puede producir un bloque y firmarlo de manera que el resto de los nodos puedan aceptarlo. El nodo seleccionado puede fallar en la creaci贸n de un bloque, por lo que el slot puede quedar vac铆o. Ning煤n otro nodo puede producir un bloque v谩lido en un slot determinado, ya que no puede firmarlo correctamente.
  5. Si el nodo seleccionado produjo el bloque, lo distribuye a otros nodos. La prueba de haber ganado el derecho a la producci贸n del bloque se incluye en el bloque.
  6. Otros nodos reciben el bloque y pueden validar que el bloque fue producido por el nodo correcto, y en base a eso pueden decidir si el bloque ser谩 incluido en la blockchain.
  7. El proceso contin煤a a partir del paso 2 en un epoch determinado.


Determinaci贸n de los l铆deres de los slots.

Como puedes apreciar, a diferencia de PoW, durante el proceso de creaci贸n del bloque, no se pierde tiempo en determinar qui茅n crear谩 el bloque. Todo est谩 claro de antemano en el epoch, por lo que el pool s贸lo averigua si se le dio el derecho de producir el bloque en cada slot, y si es as铆, lo har谩 inmediatamente. A continuaci贸n se distribuye el bloque, que es la fase de su aceptaci贸n por la red. Debido a la brevedad del tiempo del bloque, al pool no le preocupa que alg煤n nodo tome su derecho de producir el bloque.

Resumen

Cardano trabajar谩 en su escalabilidad dentro del consenso de Ouroboros Hydra. Sin embargo, puede ser necesario construir segundas capas para que podamos escalar globalmente a mil millones de usuarios. Sin embargo, la descentralizaci贸n a煤n debe ser considerada en la segunda capa. Las segundas capas son buenas para transacciones frecuentes entre dos usuarios. Es imposible construir un futuro descentralizado en una infraestructura centralizada. No funcionar谩. La descentralizaci贸n es importante no s贸lo como defensa contra el enemigo externo, sino tambi茅n contra el enemigo dentro del sistema. El poder excesivo del enemigo dentro de la red puede significar la recolecci贸n de datos de los usuarios, el aumento de las comisiones o la censura en las transacciones. La mejor soluci贸n a estos problemas es la descentralizaci贸n, sin m谩s.

La descentralizaci贸n, de la mano del escalado, puede traer nuevas personas a la blockchain. Para una mayor adopci贸n, se requieren transacciones r谩pidas y econ贸micas. La gente est谩 acostumbrada a sistemas centralizados que ofrecen rapidez y facilidad de uso. Blockchain tambi茅n debe hacer esto, de lo contrario, la gente no la usar谩.


Considera la posibilidad de delegar tus ADA en Cardanians, ticker CRDNS.
Nuestro equipo est谩 relacionado con el desarrollo de Adapools.org.

Si te gustan nuestros art铆culos, puedes apoyarnos con una donaci贸n:

[ADA] DdzFFzCqrhsp2Qsit7VGq5jpjehGFmVt9rvJzSRnWJ8S5HaMqpXxg7kguevE7jvxhPgmHbrKGtRXGGF7jVHjcnSBfQ5sEGKB7HVvDNyR

[BTC] 3GvKDw7GWfyawMo3QcHkVJCUjGvbyUqboA

Embajadores de Cardano: Jaromir Tesar y Lukas Barta.

V铆as de contacto

Web: https://cardanians.io
Twitter: @Cardanians_io
Twitter de AdaPools: @AdapoolsO
Email: hello@cardanians.io
Telegram: https://t.me/cardanians
Facebook: Cardano CZ/SK: https://www.facebook.com/groups/cardanoczsk

1 Like