En primer lugar, para ayudar a las cadenas de censura que son resistentes, inmutables y sin permiso a tener una amplia adopción en el mercado, deben hacerse muchos cambios. Por lo tanto, cada capa del ecosistema debe ser más usable desde el protocolo base. Todo ello hasta la interfaz del usuario final.
Del mismo modo, estas capas deben aprovechar las propiedades y la usabilidad de blockchain para que pueda producirse una adopción más que significativa. Y esto se debe resolver, debido a que entonces no puede servir el uso de blockchain. Y no puede servir si dicha cadena de bloques es resistente a la censura y a la vez, la interfaz está censurando.
Capas de abstracción de blockchain
Las capas existen como un mecanismo de aislamiento, es decir, cada una de las capas trabajan independientes unas de otras. Es decir, la capa superior, no debería de preocuparse por lo que pueda suceder debajo de la misma. Del mismo modo, a este concepto, es a lo que se llama abstracción completa.
Por lo tanto, la abstracción completa es una práctica evolutiva moderna fundamental. Hace algunos años, los desarrolladores que programaban brazos robóticos, debían saber el tipo de comunicación que tenía un hardware, con el otro. Ahora bien, hoy en día se pueden encontrar API comunes, esto debido a que puede haber reutilización de código.
Esto da como resultado que el desarrollo de aplicaciones y demás variantes de la programación se hagan más rápidamente. Sin embargo, se sacrifica un poco el rendimiento, pero la velocidad es mayor. Y este principio aplica exactamente para blockchain.
Así pues, el diseño de las capas inferiores, pueden tener un impacto con respecto a la facilidad de uso de las capas del nivel superior. Del mismo modo, sin una base segura y sólida, cualquier cosa en las capas superiores va a ser inestable en todo caso. Así pues, los usuarios no van a confiaren un protocolo si su criptografía está rota.
Contexto de la usabilidad de blockchain
Primeramente, y antes de que podamos determinar qué hace que blockchain sea usable, debemos entender los objetivos concretos del protocolo. Entonces, si un protocolo ha sido desarrollado solo para el seguimiento y la administración de activos para el mercado nocturno de los bancos; entonces dicho protocolo puede ser autorizado.
Si bien dicho protocolo está destinado a infraestructuras sin permisos para activos no fungibles, los requisitos de usabilidad son muy diferentes.
Muchos sostienen que el tiempo de baja finalidad de la transacción, el alto rendimiento de la transacción y los bajos costo de la transacción, son esenciales para cualquier blockchain. Sin embargo, la realidad es que son independientes de facilidades de uso, todo ello en función del o los objetivos del protocolo en sí.
De igual manera, ocurre con las reglas de consenso. Es decir, que una cadena de bloques no necesita ser tolerante a errores bizantinos, esto si la red está autorizada o federada. Ahora bien, si ya tienes todo esto en mente, entonces comprenderás que se han discutido solo los atributos comunes de usabilidad que pueden ser importantes en diferentes objetivos.
Se comienza desde el fondo
En primer lugar, comenzando desde abajo, se puede garantizar que las capas construidas en la parte superior. Estas van a tener la capacidad de heredar las funciones de usabilidad que se han integrado de forma nativa con el protocolo base. Es decir, que lo que se crea aquí, en el protocolo base, va a afectar tanto a los desarrolladores, como a los usuarios finales.
Algunas características que un protocolo debe incluir
Para empezar, es poco probable que todos los usuarios de un protocolo vayan a interactuar con blockchain utilizando un nodo completo. Por lo tanto, es más común utilizar un servicio de nodo alojado. Ahora, si usas pruebas SPV o clientes livianos, los usuarios pueden validar y enviar transacciones independientemente, y sin tener que confiar en otros.
Ahora bien, se sabe que el modelo UTXO te ofrece muchos beneficios, el modelo basado en cuentas es más fácil de usar. Ya que solo hay una cuenta de manera “canónica”, la cual hace que la administración de cuentas sea más simple.
Igualmente, queda establecido que un sistema de consenso asíncrono y determinista puede tener como máximo dos de estas tres propiedades: seguridad; en la que los resultados son válidos e idénticos en todos los nodos. Vida; que son nodos que no siempre fallan, y tolerancia a fallos; el sistema puede sobrevivir a fallos en los nodos en cualquier punto.
Por último, debes tener claro que ningún mecanismo de consenso puede tener las tres características. Por lo tanto, cualquier sistema de consenso y que esté distribuido en internet, debe sacrificar una de estas características. Así pues, los desarrolladores deben determinar qué es lo que valoran y cómo afecta la experiencia del usuario.
Características para los mantenedores de red
Una de las características principales, es la de dar incentivos de nodo completo. Por ello, debería haber razones para que los usuarios ejecuten nodos completos. Y esto sea debido a que la red les otorga permisos, o debido a que la red tiene un incentivo económico de cifrado que puede otorgar. Sin nodos completos, las redes tienen menos seguridad.
Por lo tanto, los incentivos deben cubrir las características más importantes de cualquier protocolo. Por ejemplo, en el consenso de Bitcoin, se recompensa al minero que explota el bloque en la cadena más larga. Sin embargo, no hay incentivos para los que propagan los bloques. Esto se conoce como “minería egoísta”.
También, se deben cubrir los detalles de la implementación. Esto debido a que hay muchas maneras de implementar especificaciones para un protocolo, o conjunto de ellos. Así pues, los desarrolladores deben cuidar de verificar algunos casos de seguridad, esto para que no san blanco de ataques informáticos.
Hay que equilibrar visiones
Para finalizar, y como has podido leer en todo el artículo, el desarrollo externo de protocolos es fundamental, pero debe estar equilibrado con la visión del proyecto. Por lo tanto, es necesario que un proyecto tenga sus objetivos claros para que pueda garantizar que todos los desarrollos de la comunidad de usuarios tengan una guía.
Entre tanto, se debate entre confiar en las billeteras propias de la organización, o por parte de terceros. También existe las disconformidades entre los desarrolladores que son de código abierto, y otros que no. Por esto, hay que seguir despejando interrogantes y seguir trabajando conjuntamente.