Ardor Frente a la Competencia, Comentarios Finales

Esta es la entrega final de una serie de artículos que comparan Ardor con otros proyectos blockchain con características u objetivos similares. A continuación puedes encontrar las entradas anteriores de esta serie:

Esta serie comenzó como una breve e informal entrada en Reddit dónde exponía mis reacciones iniciales al paper de Plasma. No supe en ese momento que me estaba embarcando en un viaje por media docena de plataformas más, desde plataformas con cadenas laterales (Lisk, Stratis, de alguna manera Komodo) a plataformas con monedas coloreadas con características exclusivas (NEM, Waves), hasta un proyecto que evita la blockchain y usa una estructura completamente diferente (IOTA). Ahora que ha llegado el momento de concluir la serie, con los dos últimos artículos centrados de nuevo en Ethereum, creo que hemos llegado a un buen sitio para concluir nuestro viaje

En esta serie hemos realizado un gran recorrido y sería imposible resumirlo todo aquí. En su lugar, me gustaría compartir mis reflexiones sobre un tema general que ha surgido recurrentemente al realizar mi investigación sobre estos proyectos.

Escalando con Seguridad

Tal y como he mencionado anteriormente, mi interés principal a lo largo de esta serie ha sido evaluar diferentes maneras de enfrentarse al problema de escalar una blockchain. Lo que he descubierto es que existen diversas estrategias, pero la mayoría tienen como contrapartida que afectan a la seguridad. Ciertamente no soy el primero en hacer esta observación, pero creo que debe ser repetido de nuevo en el contexto de esta serie.

En un extremo del espectro, la forma más seguro para lanzar un nuevo proyecto blockchain es probablemente emitir un token en una blockchain existente que se encargue de ofrecerle la seguridad necesaria. Este es el enfoque que buscan las monedas coloreadas de Nxt, NEM, Waves y Ethereum, por ejemplo. Las transacciones que involucran a estos tokens son almacenadas directamente en la blockchain subyacente y son, por tanto, tan seguras como cualquier otra transacción que tenga lugar en esa blockchain.

La parte negativa de este enfoque es que no permite escalar demasiado bien: cada nodo de la red tiene que procesar todas las transacciones de todos los tokens de la blockchain, incluso si los proyectos a los que esos tokens representan no tienen nada que ver el uno con el otro. Además, todos los datos de las transacciones son almacenados para siempre en la misma blockchain, haciendo que crezca proporcionalmente al volumen combinado de transacciones de los proyectos que corren en ella.

Así que los llamados métodos de escalado “verticales”, que pretenden que cada nodo realice la misma cantidad de trabajo más rápidamente, o se almacene la misma cantidad de datos de manera más eficiente, son la manera natural para escalar en este modelo. El proyecto Catapult de NEM es un buen ejemplo, puesto que se centra en optimizar el código del cliente completo y el protocolo de comunicación usado en la red. Waves NG, una optimización del protocolo de forjado, es otro ejemplo de lo mismo.

No obstante, este enfoque sobre la manera de escalar tiene límites. Llegará un momento en que, conforme se van añadiendo un mayor número de usuarios y transacciones, este diseño se romperá y la única forma viable para su escalado será del tipo “horizontal”, donde cada nodo de la red procese solo una sub-serie de todas las transacciones

Una forma razonable de escalar una plataforma blockchain horizontalmente es trasladar cada proyecto a su propia blockchain independiente, lo que constituye la base de las plataformas de cadenas laterales como Lisk o Stratis. Este enfoque se sitúa en el otro extremo del espectro entre seguridad y escalabilidad: se particiona tanto el poder de computación como el espacio de almacenamiento requerido para ejecutar la plataforma y se permite que existan diferentes nodos para gestionar cada partición, pero este método de escalado implica un descenso de la seguridad. Particularmente, con N proyectos funcionando en una blockchain lateral, la cadena lateral más débil esta protegido como mucho por 1/N del total de los mineros o forjadores, y posiblemente nos encontremos muy por debajo de esa cifra, especialmente en sus primeros momentos.

Ardor se sitúa en una posición intermedia en el espectro seguridad-escalabilidad, consiguiendo reducir el espacio de almacenamiento para dar servicio a los proyectos que funcionan en sus propias child chains sin tener que reducir su seguridad, pero requiriendo todavía que toda la red procese cada transacción. Será interesante ver los detalles del plan de Jelurida para hacer que el procesado de las transacciones de las child chains tenga lugar en subredes dedicadas de la red, lo que ofrecería el escalado computacional y de ancho de banda perdido, pero hasta que llegue este momento, solo podemos especular.

IOTA es un poco un caso especial, puesto que los fundamentos de su diseño son diferentes de los de una blockchain en un par de puntos importantes. Sin volver a explicar todo el mecanismo del “consenso a largo plazo” en el tangle, permitidme afirmar que el tangle de IOTA (tal y como está implementado hoy en día) me parece que es principalmente una forma de escalado vertical, con un elemento de escalado horizontal. Cada nodo ve y almacena cada transacción, y a pesar de que los nodos pueden podar continuamente el tangle conforme pasa el tiempo, reduciendo los requisitos de almacenamiento, los “permanodes” de la red deben almacenar todo el historial del tangle para que los nuevos nodos puedan arrancar sin tener que depositar la confianza en un tercero. Por otro lado, los nodos no necesitan validar cada transacción, puesto que son capaces de aceptar que las transacciones que se realizaron tiempo atrás en el tangle ya han sido confirmadas por otros nodos de la red, puesto que todas las puntas hacen referencia a ellas.

En otras palabras, IOTA particiona el trabajo de computación requerido para validar las transacciones, pero no el ancho de banda requerido para retransmitirlas o los datos que deben ser almacenados.

A largo plazo, IOTA planea introducir los nodos “manada” para dividir las tareas de validación de las transacciones y almacenamiento del tangle. Esto será una manera de partición horizontal, pero todavía no he sido capaz de encontrar los detalles técnicos, así que en mi opinión pertenece a la misma categoría que el Plasma de Ethereum y las propuestas de fragmentación: una idea que suena plausible, pero que necesita mayor desarrollo antes de que pueda ser aceptada como una solución real.

Sobre esto, me gustaría hacer un apunte final acerca del enfoque de Ardor sobre el escalado: aunque no es la panacea, al menos en estas primeras fases, es importante no subestimar el valor de una arquitectura que ya existe y realmente funciona. Quizá no sea necesario decirlo, pero los desarrolladores de Ardor no solo están lanzando hipótesis sobre soluciones teóricas a un problema difícil. Han demostrado que pueden diseñar un diseño ambicioso pero realista, implementándolo en un periodo de tiempo razonable y consiguiendo progresar hacia una blockchain realmente escalable. No todos los equipos puede afirmar lo mismo, ni aún aquellos que sus ideas iniciales sonaban prometedoras.

Reflexiones Finales

Se podría decir mucho más sobre todos estos proyectos, pero esto tendrá que ser suficiente por ahora. Espero que os hayan gustado estos artículos aunque tan solo sea la mitad de lo que he disfrutado yo escribiéndolos. Como nota personal, me gustaría agradeceros el que hayáis leído hasta aquí y por que hayáis compartido estos artículos con otros entusiastas blockchain. Ha sido muy gratificante ver como la gente ofrecía su apoyo, sus comentarios y expresaba todo tipo de reacciones. Me siento honorado y muy agradecido porque os halláis tomado el tiempo para leer mi trabajo.

Si me permitís dejaros con una reflexión de despedida, sería la siguiente: después de todo lo que se ha dicho y hecho, veo un tremendo potencial en varios de estos proyectos, pero estoy especialmente emocionado por Ardor. Su arquitectura de cadena madre / cadena hija solventa simultáneamente dos problemas muy importantes: como enfrentarse al crecimiento desmesurado de la blockchain, y como ofrecer una blockchain como servicio a los clientes que no cuentan con los recursos o experiencia para lanzar su propia blockchain. Nadie sabe que valor económico el mercado asignará a Ardor y a la forma en que soluciona estos problemas pero, en mi humilde opinión, Ardor sale favorecido en las comparaciones con la competencia en ambos puntos. Tengo muchas ganas por ver lo que el futuro nos depara.


Prueba Ardor en la testnet

Sobre la última versión de Ardor para la testnet

View this in: English 简体中文

Deja un comentario