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á.
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:
- 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.
- Se acaba de añadir el último bloque. La red se desplaza a otro slot para que un nuevo nodo pueda producir un bloque.
- 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.
- 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.
- 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.
- 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.
- 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: Telegram: Contact @cardanians
Facebook: Cardano CZ/SK: Cardano [ADA] CZ/SK | Facebook