Compartir este artículo

Blockchain, ¿qué eres? Definición de una palabra de moda en la industria

Dave Hudson, autor del blog Hashingit.com, LOOKS al libro blanco de Satoshi para descubrir qué es una cadena de bloques y qué podría ser...

A medida que nos acercamos a 2016, parece haber un sinfín de debates sobre «blockchain». Es un término que se cita cada vez con más frecuencia, incluso en el periodismo convencional, mientras que, tan solo en el sector de las tecnologías financieras, numerosos potenciales proveedores y usuarios afirman que «blockchain» revolucionará numerosas aplicaciones.

Este uso ahora común sugiere que debe ser algo definido con precisión y bien entendido, pero esto parece ser más una cuestión de mantra que de comprensión.

CONTINÚA MÁS ABAJO
No te pierdas otra historia.Suscríbete al boletín de Crypto for Advisors hoy. Ver Todos Los Boletines

Las cámaras de eco de internet resuenan con muchas opiniones, pero los intentos de encontrar un significado preciso parecen encontrar una desalentadora falta de consenso. Para ser algo más que una simple exageración publicitaria, necesitamos respuestas a algunas preguntas.

¿Qué es? ¿Qué no es? ¿Qué podría ser? ¿Podría ser algo que nos permita construir sistemas nuevos y duraderos? En resumen, ¿cuál es la esencia de blockchain?

El libro blanco de Satoshi

Casi todas las discusiones sobre cadenas de bloques comienzan con laLibro blanco de SatoshiPero es precisamente esta base la que nos lleva a un camino de confusión. Allí no aparecen los términos «blockchain» ni «blockchain»; hay 67 usos de «block» y 27 de «chain», pero ninguno de «blockchain» ni de «blockchain». Dejando esto de lado, veamos adónde nos lleva este origen.

El libro blanco es breve; solo tiene nueve páginas. La primera mención de "bloque" y "cadena" comienza al final de la página 2, sección 3, donde se describe un servidor básico de marcas de tiempo. Previamente, el libro blanco describe una serie de objetivos de diseño asociados con el diseño de Bitcoin , como la capacidad de permitir que dos partes realicen transacciones sin necesidad de confiar en un tercero.

La declaración de los objetivos de diseño es fundamental. Establece las bases para una implementación que los cumpla, donde las características se superponen, pero resulta informativo observar la función de cada nueva capa.

En nuestra búsqueda de la naturaleza de una cadena de bloques, debemos tener cuidado de buscar cosas que sean sus atributos, en lugar de características de esta primera implementación.

Actas

La sección 1 del libro blanco es una introducción, y es en la sección 2 donde vemos algo realmente sustancial. Esta sección presenta el escenario de una moneda digital, pero se describe como una cadena de transacciones en la que la "moneda" se asigna a nuevos propietarios. La moneda es en realidad una metáfora de un historial de transacciones vinculadas.

Curiosamente, la sección 2 también describe cómo un sistema centralizado en realidad no necesita hacer esto.

Bloques y cadenas

En la sección 3, vemos la esencia del patrón de diseño que mejor describe la base de una cadena de bloques. Se define como algo construido a partir de una serie de bloques de datos incrementales, cada uno de los cuales puede identificarse mediante un hash criptográfico sobre su contenido. Además, cada bloque incorpora el hash criptográfico de su bloque predecesor para garantizar la construcción de la cadena.

Los hashes de bloque se publican como evidencia ampliamente documentada que demuestra la existencia tanto de los datos del bloque como del hash predecesor. Modificar el predecesor o cualquier otro dato dentro del bloque resultaría en una firma hash diferente para el bloque, que no coincidiría con la evidencia ampliamente documentada.

Todas estas características son fundamentales, y sin ellas no podemos construir nada interesante. Sin embargo, es igualmente interesante lo que no se considera necesario en este punto. No se mencionan monedas, redes peer-to-peer ni minería, ETC En cambio, se sugiere que publicar hashes en cualquier formato ampliamente difundido sería suficiente; los dos ejemplos se dan como publicación en un periódico o a través de Usenet.

Si bien vemos algunas características explícitas, éstas conducen a algunas implícitas:

La publicación de los hashes carece de sentido a menos que un observador externo pueda recalcularlos de forma independiente, con solo los datos de los bloques de la cadena. Esta característica permite a los observadores no tener que confiar en el creador de la cadena de bloques; en cambio, pueden comparar los hashes históricos por sí mismos.

El recálculo de los hashes requiere que el algoritmo de producción de los bloques sea determinista y esté bien especificado. Sin estos, nuestro observador externo no puede recálculo los hashes.

Habilitación de operaciones peer to peer

La siguiente sección, la 4, del libro blanco trata sobre la prueba de trabajo. La primera línea es interesante: «Para implementar un servidor de marcas de tiempo distribuido entre pares (P2P), necesitaremos usar un sistema de prueba de trabajo similar a Hashcash de Adam Back». La prueba de trabajo no es necesaria para construir una cadena de bloques, solo para permitir la implementación entre pares del servidor de marcas de tiempo.

Los diseños de Criptomonedas posteriores han demostrado que potencialmente existen otros enfoques que pueden adoptarse aquí también (por ejemplo, formas de prueba de participación o híbridos de ambos), pero si estamos satisfechos con un enfoque cliente-servidor, entonces ninguno de estos es realmente necesario.

Esto no quiere decir que la prueba de trabajo no pueda tener otros usos dentro del diseño de una cadena de bloques, pero ninguno parece fundamental para nuestra búsqueda.

Red y más allá

La Sección 5 describe las características de implementación de la red Bitcoin . Aquí no se amplía explícitamente el concepto de lo que es una cadena de bloques ni lo que podría requerir. De hecho, ni las secciones 6, 7, 8, 9, 10, 11 ni 12 (la última sección) ofrecen explícitamente nuevas ideas sobre lo que podría ser una cadena de bloques.

Respuestas a nuestras preguntas

Si el libro blanco de Satoshi es el origen del diseño de la cadena de bloques, nos queda una definición bastante limitada, pero quizás ese sea el aspecto más esclarecedor. Es muy explícito sobre las decisiones de diseño específicas y su propósito, lo que tiende a llevarnos a la conclusión de que muchas de las afirmaciones sobre las cadenas de bloques podrían ser, en realidad, una cuestión de implementación más que de arquitectura.

¡Hagamos entonces algunas preguntas específicas!

¿Una cadena de bloques debe tener monedas?

Existe un debate interesante en el libro blanco sobre la necesidad de incentivar a quienes brindan seguridad a la red P2P para que mantengan su honestidad y como medio para introducir monedas en el sistema, pero el debate se centra claramente en el contexto de la red P2P. El concepto de monedas en sí mismo se considera innecesario con una casa de moneda confiable.

Una casa de moneda confiable no es deseable en una Criptomonedas, pero no parece ser necesario contar con monedas si deseamos construir una cadena de bloques vinculados criptográficamente. Hay una pregunta interesante sobre la confianza, pero la abordaremos más adelante.

¿Debe una cadena de bloques implementar contratos inteligentes?

Desde la perspectiva del libro blanco, esto parece improbable. La palabra «contrato» no aparece en ninguna parte.

¿Podría una cadena de bloques posibilitar los contratos inteligentes? Sí, claro que sí, pero también podría posibilitar muchas otras cosas.

¿Debe ser programable una cadena de bloques?

Nuevamente, la respuesta parece ser no. Ni las palabras «programa» ni «script» aparecen en el libro blanco.

Una cadena de bloques debe ser interpretable por ONE o más observadores independientes, por lo que se construye a partir de una o más estructuras de datos bien definidas. La estructura de datos del bloque debe contener un hash de bloque previo, y el hash criptográfico del bloque debe ejecutarse de una manera muy específica; sin embargo, ninguna de estas opciones requiere que la estructura de datos contenga código ejecutable.

¿Puede una cadena de bloques contener algún tipo de código de programa? Esta es una pregunta de implementación y la respuesta es sí. Bitcoin incluye un lenguaje de programación limitado y otros sistemas, como EthereumPosteriormente, se ha intentado dar soporte a modelos de programación más elaborados.

La elección de apoyar tales conceptos parece ser más una cuestión de conveniencia o de objetivos de diseño más ambiciosos, pero parece que una cadena de bloques no necesita ser más "programable" que cualquier otra estructura de datos de lista enlazada.

¿Es una cadena de bloques una base de datos?

Una vez más, la respuesta parece ser no. Como antes, la palabra «base de datos» no aparece en el libro blanco.

En CORE, una cadena de bloques es un tipo especial de estructura de datos. Los bloques dentro de la cadena contienen datos, pero esto no la convierte en una base de datos; en el mejor de los casos, los bloques representan el registro de transacciones de una implementación específica de la base de datos.

De igual manera, no existe semántica para consultar una cadena de bloques, como tampoco la hay para consultar una lista enlazada. Una implementación específica podría permitir consultas en cualquiera de las dos, pero esta no define el objeto en sí.

A modo de comparación, los paquetes IP de los paquetes TCP que contiene este artículo se definen como estructuras de datos en una serie de documentos RFC (Request de Comentarios) del IETF (Grupo de Trabajo de Ingeniería de Internet). Estos documentos describen la forma de los paquetes y su comportamiento durante su transporte. Los destinatarios de estos paquetes pueden determinar su validez por sí mismos, independientemente de la implementación de la red entre ellos y el emisor.

Una implementación de un enrutador/cortafuegos puede ofrecer una función para capturar esos paquetes y analizarlos posteriormente, así como consultas a bases de datos. Sin embargo, la naturaleza de un paquete IP no lo convierte en una base de datos, ni las RFC sugieren lo contrario. Las características de la implementación y las especificaciones son muy diferentes.

¿Es una cadena de bloques sin confianza?

La respuesta también es no, pero se debe a que la pregunta es demasiado amplia. Una cadena de bloques nos permite exigir menos confianza que muchos sistemas tradicionales, pero cualquier implementación aún requiere cierto nivel de confianza.

El receptor de datos de bloques debe confiar en que se han entregado sin ser comprometidos por ningún intermediario. La distribución P2P de bloques dentro de Bitcoin y redes similares busca minimizar la confianza entre pares, pero incluso este modelo presenta posibles puntos débiles. A continuación, se presentan algunos:

  • Confiamos en que el software blockchain que estamos ejecutando no se haya visto comprometido para entregar datos falsificados.
  • Confiamos en que el sistema operativo bajo el cual se ejecuta nuestro software blockchain no se haya visto comprometido para entregar datos falsificados.
  • Confiamos en que los procesadores de red que proporcionan conectividad a nuestro sistema no hayan sido comprometidos para entregar datos falsificados.

"En el código confiamos" es un mantra interesante, pero más de 30 años de malware, spyware, ETC, nos informan que se trata de una estrategia muy discutible.

Un diseño de blockchain dificulta las falsificaciones para un adversario y reduce drásticamente la probabilidad de errores accidentales. Podemos confiar, pero verificar (dentro de ciertos límites), pero esto sigue siendo una mejora significativa respecto a la confianza ciega. Y lo que es más importante, ninguna de estas características que minimizan la confianza es parte del diseño de la red P2P, sino que son intrínsecas a la codificación de bloques.

¿Una cadena de bloques debe ser sin permisos o puede ser sin ellos?

Una cadena de bloques es simplemente una estructura de datos, así que la pregunta no tiene sentido. Quién tiene la capacidad de leer o escribir una estructura de datos es una cuestión completamente distinta.

Ignoremos esta sutil distinción por un momento y asumamos que la pregunta tiene sentido. Consideremos el caso de Bitcoin: ¿quién escribe la cadena de bloques?

La respuesta es que los mineros (o más precisamente, los creadores de bloques, como los operadores de grupos de minería, no aquellos que simplemente procesan bloques) pueden escribir nuevos bloques. Los usuarios de la red pueden proporcionar transacciones candidatas para ser incluidas en bloques, pero esto no garantiza que los bloques las contengan. En Bitcoin, hablamos de esto como "sin permiso" porque nadie necesita un permiso explícito para convertirse en Maker de bloques.

Sin embargo, si consideramos otros usos potenciales del diseño de una cadena de bloques, existe un conjunto de participantes, a menudo muy bien definido, que desearíamos que pudieran escribir datos de bloques. En muchos casos, este puede ser incluso un único participante.

Una crítica a estos posibles usos de una cadena de bloques es que no la convierte en mejor que una base de datos, pero una base de datos convencional requiere una confianza ciega. Su estado interno es generalmente incognoscible. Incluso en sus usos más simples, una cadena de bloques puede al menos proporcionar un medio para verificar el estado de dicho sistema, y hacerlo de forma que permita la validación de historiales. Sin embargo, ¡esto es solo el comienzo de las posibilidades!

¿Es una cadena de bloques la Internet del dinero (o la Internet de cualquier otra cosa)?

Siendo realistas, no, o al menos no por sí solo.

Cuando analizamos la cuestión de "no es una base de datos", también abordamos por qué esta afirmación T de sentido. Superficialmente, el argumento parece seductor. La idea es que podemos desarrollar mucha Tecnología sobre una cadena de bloques, de la misma forma que una pila de red está estructurada en capas.

Esta propuesta presenta muchos problemas, pero el más obvio es que una cadena de bloques es simplemente una estructura de datos. Es una buena candidata para transmitir información a través de internet, pero no permite nada por sí misma.

Sin embargo, separar la cadena de bloques de cualquier transporte de la misma brinda cierta esperanza de que las cadenas de bloques puedan permitir aplicaciones financieras más confiables en internet. Una separación clara también permite la experimentación en cada capa del diseño del sistema, una característica clave que ha permitido el éxito de internet.

Con Internet, es posible probar, reemplazar o modificar candidatos para todas las capas de la pila de red, lo que permite que los mejores diseños WIN. De igual manera, el enfoque basado en estándares ha permitido que implementaciones dispares colaboren sin impedir la búsqueda y monetización de ventajas comerciales.

En el caso de las cadenas de bloques, ya hemos visto que existe un requisito de soporte para observadores externos y esto exige un cierto nivel de interoperabilidad.

Últimos pensamientos

Hemos analizado lo que una cadena de bloques podría ser o no, y quizás hemos visto algunos indicios de lo que podría permitir. La Tecnología que sustenta Bitcoin puede usarse para construir muchas cosas, y el legado de bitcoin no debería ser solo Bitcoin en sí mismo; ha demostrado la viabilidad de algo mucho más fundamental.

El debate sobre qué constituye una cadena de bloques no terminará aquí, pero debemos avanzar en la discusión y resistir la tentación de permitir que se convierta en otra palabra de moda del marketing.

Para que esto suceda, necesitamos una terminología clara y un uso razonado. Debemos evitar la mezcla de ideas diferentes y que las afirmaciones Tecnología sean realistas y alcanzables. Si fracasamos, el término «blockchain» acabará careciendo de sentido y deberá ser reemplazado. Este parece ser el resultado equivocado.

Si tenemos éxito, la idea de una cadena de bloques no será el fin de la historia. En cambio, ocupará su lugar como una capa sobre la que construir sistemas mejores y cada vez más útiles.

Este artículo fue republicado con permiso deHashingit.comPuedes Síguenos a Dave en Twitter en @hashingitcom.

Imagenvía Shutterstock

Nota: Las opiniones expresadas en esta columna son las del autor y no necesariamente reflejan las de CoinDesk, Inc. o sus propietarios y afiliados.

Dave Hudson

Dave Hudson es vicepresidente de arquitectura de software en Peernova y diseñador de sistemas operativos, Stacks de red, compiladores y bases de datos. Por diversión, analiza Bitcoin y los sistemas de contabilidad criptográfica en su blog hashingit.com. Reside en Bangor, Gales, y San José, EE. UU.

Picture of CoinDesk author Dave Hudson