Soluciones de escalabilidad - Token-Economy-Book/2ndEdition-Spanish GitHub Wiki

Uno de los mayores retos de un consenso distribuido como la Prube de Trabajo o “Proof-of-Work” es que, aunque hace que la red sea segura, no es escalable. Esto se debe al equilibrio entre descentralización, seguridad y escalabilidad.

Advertencia: La investigación y el desarrollo en torno a las soluciones de escalabilidad están sujetos a la actualidad. Este capítulo ofrecerá una visión general, pero no es ni mucho menos completo en cuanto a la descripción de todas las soluciones posibles y/o sus compensaciones.

El "trilema de la escalabilidad" describe el compromiso en el consenso distribuido entre descentralización, seguridad y escalabilidad. La descentralización es la premisa de una red distribuida, la seguridad es el aspecto más importante cuando la red implica a un conjunto de actores no confiables, y la escalabilidad se refiere al número de transacciones que un sistema puede procesar por segundo. Para permitir un alto grado de inclusión de nodos computacionalmente más débiles, el tamaño de los bloques en una red Trabajo de Prueba o “Proof-of-Work” es limitado y los bloques se crean con un retraso. De lo contrario, como los bloques más grandes son más difíciles de procesar, la latencia de la red impediría a los nodos más débiles participar en el proceso de creación de bloques. Sin embargo, estas limitaciones reducen la cantidad de transacciones que se pueden validar en un plazo determinado, por lo que los mecanismos de prueba de trabajo son seguros, pero no son escalables. En los primeros días de las redes de blockchain, la comunidad de desarrolladores apenas se ocupaba de la escalabilidad, ya que el tráfico en esas redes era todavía bajo. Hoy en día, la escalabilidad de las redes públicas de blockchain es uno de los principales cuellos de botella de la adopción masiva y también una de las cuestiones de I+D más trabajadas.

La escalabilidad de Blockchain es comparable a la de los primeros días de Internet, en los que teníamos que pasar cables telefónicos por nuestros apartamentos para conectar nuestros ordenadores a Internet. En cuanto a la conexión, el ancho de banda era escaso y la comunicación era lenta; había que esperar a que las páginas se acumularan píxel a píxel. La introducción de los módems de 56k se consideró una gran mejora respecto al módem de 28k, pero la transmisión de vídeo se consideraba un sueño lejano. Aunque el rendimiento de los datos era un problema, estos problemas se resolvieron finalmente, y ciertamente no impidieron que Internet evolucionara hasta convertirse en lo que es hoy. En el contexto de las redes de cadenas de bloques, se han propuesto muchas soluciones para que las transacciones sean más rápidas y baratas, manteniendo al mismo tiempo la seguridad y un cierto nivel de descentralización. Las soluciones de escalabilidad pueden abordar estos problemas a (i) nivel de protocolo, o a (ii) nivel de segunda capa.

Cuando se abordan a nivel de protocolo, a menudo conducen a la centralización. Un mayor volumen de transacciones por segundo suele requerir la concesión de más poderes a determinados nodos, lo que aumenta el nivel de centralización. Los mecanismos de consenso alternativos intentan resolver el problema de la escalabilidad introduciendo algún tipo de capa de permisos para garantizar la confianza. El capítulo "Bitcoin, Blockchain & Other Distributed Ledgers" que aparece en la primera parte de este libro, tiene todo un subcapítulo dedicado a una lista de soluciones alternativas de libros de contabilidad distribuida y protocolos de consenso que intentan - entre otras cosas - resolver las cuestiones de rendimiento. Las soluciones más populares para lograr mayores niveles de rendimiento son los protocolos de consenso alternativos, como la prueba de participación delegada (dPoS), la tolerancia a fallos bizantina práctica (pBFT) o las redes con permisos. La fragmentación del libro mayor o los algoritmos criptográficos alternativos son otros medios para abordar el problema de la escalabilidad a nivel de protocolo y se describirán en este capítulo.

Como alternativa, se han hecho varios esfuerzos para trasladar las soluciones de escalabilidad a una segunda capa, como las "cadenas laterales" o los "canales de estado". En ambos casos, las interacciones de los usuarios se trasladan de la capa de la blockchain a una segunda capa, al tiempo que se garantizan las transacciones P2P sin riesgo entre los participantes.

Canales estatales

Los canales de estado ofrecen una segunda capa en la parte superior de una red de cadenas de bloques, permitiendo que las transacciones que podrían ocurrir en la cadena se liquiden fuera de ella, manteniendo la seguridad de todos los participantes de la red. En este proceso, las liquidaciones de las transacciones se subcontratan a un canal de estado privado, que podría describirse como una vía bidireccional entre dos usuarios. Estos canales de estado se formalizan y procesan mediante un contrato inteligente. Los "canales de estado" permiten la transferencia de cualquier estado para cualquier tipo de aplicación descentralizada. Los "canales de pago" sólo permiten la transferencia de pagos. Son útiles si dos partes, Alice y Bob, tienen una relación comercial en curso con pagos continuos de ida y vuelta.

Los tokens se bloquean temporalmente como mecanismo de seguridad en caso de disputas: (i) Los tokens pueden enviarse de Alice a Bob y viceversa utilizando canales de estado en los que se bloquean a través de un esquema de firmas múltiples o un contrato inteligente durante un periodo de tiempo predefinido. (ii) Tanto Alice como Bob firman cada transacción con su clave privada, pero las transacciones se mantienen privadas y no se difunden a la red de blockchain. (iii) Una vez transcurrido el periodo, el saldo de todas las transacciones bilaterales se transmite a la red de blockchain, que cierra el canal de estado.

Supongamos que Alice tiene 200 ETH y Bob tiene 100 ETH. En un periodo de tiempo determinado, Alice envía diez pagos de 10 ETH y Bob envía a Alice dos pagos de 25 ETH. Si todas las transacciones se liquidaran en la red Ethereum directamente, todos los nodos de la red registrarían doce transacciones individuales. Esto no sólo aumentaría el número de transacciones y ralentizaría la red, sino que también sería más caro tanto para Alice como para Bob, ya que cada transacción individual incurriría en una tasa de transacción. Utilizando un canal de estado para liquidar estas transacciones bilaterales, sólo es necesario liquidar el saldo de todas las transacciones directamente en la blockchain una vez que haya pasado el tiempo predefinido. Esto significa que la red sólo registrará dos transacciones: la de apertura y la de cierre del canal.

Mantener las transacciones fuera de la cadena y exclusivamente entre ambas partes no sólo es más barato y rápido, sino que también preserva más la privacidad. Todo ocurre dentro de un canal, en lugar de ser transmitido públicamente a toda la red. Las únicas transacciones que se registran en la cadena y son visibles para el público son las de apertura y cierre. El inconveniente de este proceso: los canales estatales necesitan la plena disponibilidad de todos los participantes implicados. De lo contrario, si el cierre final del canal, y por lo tanto la presentación final del estado, fuera presentado por un actor malicioso, los tokens podrían estar en riesgo. Para rebatir los ataques malintencionados, el contrato inteligente puede retener los tokens bloqueados para penalizar al actor malintencionado. Esto requiere una supervisión y podría subcontratarse a proveedores de servicios, los llamados contratos de juez, a cambio de una tarifa. Por lo tanto, los canales de estado sólo son útiles en los casos en los que los participantes intercambian muchas actualizaciones de estado durante un largo periodo de tiempo, para mitigar el coste inicial de crear un canal y desplegar un contrato de juez.

El contrato inteligente utilizado para bloquear el estado debe conocer de antemano a los participantes de un determinado canal. Los canales de estado funcionan bien con un conjunto definido de participantes, pero añadir y eliminar participantes requiere un cambio en el contrato inteligente, o la creación de un nuevo canal. Proyectos como Lightning Network (Bitcoin) o Raiden Network (Ethereum) han ideado soluciones basadas en una malla de participantes, creando una red de todos los canales de forma que no hay que crear un nuevo canal para cada nuevo participante. Ahora las transacciones pueden dirigirse a través de los canales de otras personas, pero sólo mientras haya alguna conexión de canal directa a través de la red. He aquí una lista seleccionada de soluciones de canales estatales para varias redes de blockchain con diferentes grados de madurez y éxito: “Celer,” “Counterfactual,” “Fun Fair,” “Liquidity,” “Lightning” “Machinomy,” “Perun,” “Raiden,” “Spankchain,” or “Trinity.” La mayoría de las soluciones están especializadas en una red blockchain -como Bitcoin, Ethereum o Neo-, otras son agnósticas a la red.

State Channels

Cadenas Laterales

Las cadenas laterales son redes de blockchain independientes, compatibles con la cadena principal. Las cadenas laterales tienen su propio mecanismo de consenso, su propio nivel de seguridad y sus propios tokens. La cadena lateral no tiene por qué ser pública y también puede ser un libro de contabilidad de gestión privada. Si la seguridad de una red de cadena lateral se ve comprometida, el daño no afectará a la cadena principal ni a otras cadenas laterales. Ambas redes están vinculadas entre sí a través de una "conexión bidireccional" y pueden transferir cualquier estado. De este modo, los tokens pueden intercambiarse a un ritmo predeterminado entre la cadena principal y la cadena lateral. La cadena principal garantiza la seguridad general y la resolución de disputas, y las transacciones que se externalizan a la cadena lateral pueden sacrificar la descentralización a cambio de la escalabilidad.

A diferencia de las cadenas estatales, las transacciones que se producen en una cadena lateral no son privadas entre los participantes de una transacción. Se publican en la red de la cadena lateral y, por tanto, son visibles para cualquiera que tenga acceso al libro mayor. Alice y Bob no tienen que estar disponibles todo el tiempo, y no hay costes administrativos adicionales al añadir o eliminar participantes. Sin embargo, la creación de una cadena lateral supone un gran esfuerzo, ya que implica la construcción de toda una infraestructura desde cero.

Sidechains

La cadena lateral interactúa con la capa de cálculo de la cadena principal y requiere que los tokens estén bloqueados para facilitar las disputas. Un grupo de servidores (federación) media entre una cadena principal y sus cadenas laterales y determina cuándo se bloquean y liberan los tokens que un usuario ha utilizado. Esto añade otra capa de seguridad entre la cadena principal y la cadena lateral. La federación es seleccionada por los desarrolladores de la cadena lateral. Sin embargo, dicha federación añade otra capa entre la cadena principal y la cadena lateral y podría introducir más vectores de ataque. A continuación se presenta una lista seleccionada de soluciones de cadena lateral para varias redes de blockchain con diferentes grados de madurez y éxito:“Bitcoin Codex,” “Bitcoin Extended,” “Elements Projects,” “Hivemind,” “Loom,” “Liquid,” “Mimblewimble,” “Plasma,” “Poa Network,” or “Rootstock.”

Interoperabilidad de la Blockchain

El número de redes de cadenas de bloques y otros libros de contabilidad distribuidos está creciendo. Sin embargo, todos estos sistemas de libro mayor distribuido son, en su mayor parte, sistemas aislados y funcionan como un silo. Las redes no tienen conocimiento del estado de los tokens gestionados en otras redes. Tampoco tienen idea de si otras redes tienen capacidad ociosa para liquidar transacciones. Las cadenas laterales podrían considerarse un primer paso hacia la interoperabilidad y escalabilidad completas de la blockchain. Una solución más eficaz y global podría ser proporcionada por redes de interoperabilidad, como “Cosmos,” “Polkadot,” o “Wanchain,” que podrían resolver el problema de la escalabilidad para múltiples redes simultáneamente.

La interoperabilidad, en el contexto de los libros de contabilidad distribuidos, se refiere a la capacidad de compartir libremente los tokens y los datos relacionados a través de diferentes redes. En un entorno totalmente interoperable, un usuario de la red A podría enviar tokens a otro usuario de la red B sin necesidad de un intermediario, como un intercambio centralizado. La interoperabilidad de las cadenas de bloques es una idea contraria a lo que algunos proponen que podría ocurrir: una situación en la que el ganador se lo lleva todo y en la que, debido a los efectos de la red, sólo una red de cadenas de bloques sobrevivirá a largo plazo. La idea de "una cadena para gobernarlos a todos" es contraria a la idea central de la descentralización. El futuro de la Web3 podría, por tanto, depender de la capacidad de las redes de cadenas de bloques para interactuar entre sí.

Fragmentaciòn

Algunos desarrolladores proponen que la fragmentación del estado de la red podría ser una solución al problema de escalabilidad de las redes de cadenas de bloques. La fragmentación es un concepto adoptado de las bases de datos distribuidas, que aún no se ha probado a escala global en el contexto de las redes de cadenas de bloques. La fragmentación podría resolver las limitaciones de escalabilidad de los actuales protocolos de consenso, en los que cada nodo tiene que actualizar su libro de contabilidad regularmente y mantener el historial completo, desde el bloque de génesis hasta el día de hoy. Se sugiere que el historial del libro mayor se divida en partes separadas, cada una de las cuales tendría su propio "fragmento" del estado de la red. Múltiples shards mantenidos por diferentes nodos de la red en paralelo, mejorando así la escalabilidad general de la red. Los fragmentos serían "subestados" que formarían parte del estado de la red en su conjunto. La red en su conjunto seguiría funcionando bajo un único estado, pero cada fragmento tendría que ser coherente en sí mismo. La comunicación entre fragmentos se gestionaría mediante reglas de protocolo. En este proceso, las direcciones de la blockchain, los balances y el estado general estarían contenidos en los fragmentos. Los fragmentos proporcionan pruebas a la cadena principal y pueden comunicarse con otros fragmentos a través del protocolo de fragmentación. Ejemplos de proyectos que trabajan en soluciones de fragmentación: “Prysmatic Labs,” “Drops of Diamond,” “Status,” and “PegaSys.”

Algoritmos Criptográficos Alternativos

Uno de los mayores retos de la red Bitcoin y redes similares es la gestión de las transacciones no gastadas. Estas transacciones no gastadas contribuyen al crecimiento exponencial del libro mayor. En Bitcoin, por ejemplo, se denominan UTXOs, y contribuyen a una mayor carga útil, a transacciones más caras y a un menor rendimiento por segundo. Cuando se crea una nueva transacción en bruto y se valida posteriormente, antes de firmarla, las entradas sólo pueden provenir de salidas no gastadas de transacciones anteriores. Por lo tanto, para la validación de la creación de transacciones y la firma, las transacciones no gastadas son más importantes que las transacciones gastadas (salidas). Para la consistencia del libro de contabilidad, las transacciones no gastadas son importantes para cosas como el sellado de tiempo, la prueba de existencia, el almacenamiento de datos, y también la creación de bloques y la minería. Las redes de blockchain orientadas a las transacciones se centran en las transacciones no utilizadas. Por ello, el desborde o agotamiento del libro mayor está muy relacionado con ellas. La gestión del tamaño de la carga útil de los UTXO, la cantidad de UTXO en el libro mayor y el grado hasta el que es posible mantenerlos fuera de la cadena remedia la hinchazón de la cadena como tal. De hecho, todo lo que mantiene la carga de pago más pequeña tiene como consecuencia el desborde o agotamiento del mismo.

Los algoritmos criptográficos alternativos utilizados en las firmas colectivas, como las multifirmas, las firmas en anillo, las firmas de umbral o las firmas Schnorr, podrían resolver ciertos problemas de escalabilidad, por ejemplo, reduciendo la información añadida al libro de contabilidad, o eliminando esa información con las multifirmas, y redimiendo las escrituras. Con las transacciones multifirma, por ejemplo, las direcciones del receptor se agregan en una dirección del receptor multifirma y hacen que el script de canje que la acompaña se almacene fuera de línea. También se reduce el número de salidas y el tamaño del script dentro de la transacción. Lo mismo ocurre con las firmas en anillo, las firmas de umbral y las firmas colectivas.

Las firmas múltiples se dividen en una transacción de financiación, que se convierte en una UTXO y una transacción de gasto, y da lugar a una transacción de gasto. En el caso de las transacciones de financiación UTXO, la agregación de varios receptores en una sola dirección de recepción y el uso de menos salidas, además de la desconexión del script de redención, normalmente da como resultado una carga útil más pequeña. Los esquemas de firma alternativos pertenecen al conjunto de herramientas anti-bloat, pero en comparación con la transacción media no multisig, la reducción de la carga útil no es siempre el caso y depende del caso de uso específico. "Mimblewimble", por ejemplo, es una propuesta para que Bitcoin utilice un enfoque diferente para la construcción de transacciones. Elimina la mayor parte de los datos históricos de la blockchain, incluidos los resultados de las transacciones gastadas, al tiempo que permite a los usuarios verificar completamente la cadena. También permite una mayor privacidad que las implementaciones actuales de Bitcoin. "Dfinity" y “Hyperledger Fabric” utilizan firmas de umbral para lograr el mismo objetivo.

Referencias del capítulo & lecturas adicionales