Blockchains para supply chain - Lección 4.21

00:00 Introducción
02:01 Resolviendo el consenso bizantino
09:35 Requisitos rigurosos de una blockchain libre
20:31 La historia hasta ahora
22:44 Enriquecerse rápidamente hoy
24:03 Mini Bitcoin 1/3 - Hashing y Firmado
29:23 Mini Bitcoin 2/3 - Transacciones
34:44 Mini Bitcoin 3/3 - Bloques y Prueba de Trabajo
44:47 Escalando la blockchain 1/2 - Panorama aplicable
49:07 Escalando la blockchain 2/2 - Bloques más grandes
57:11 Acelerando la blockchain 1/2
59:30 Acelerando la blockchain 2/2
01:06:54 Empoderando la blockchain
01:14:51 Caso de uso: pagos
01:19:25 Caso de uso: trazabilidad pasiva
01:25:33 Caso de uso: trazabilidad activa
01:32:47 Caso de uso: reciclaje incentivado
01:35:40 Caso de uso: seguridad incentivada
01:41:30 Suavizando los requisitos
01:44:53 Conclusión
01:49:35 4.21 Blockchains para supply chain - ¿Preguntas?

Descripción

Las criptomonedas han atraído mucha atención. Se hicieron fortunas. Se perdieron fortunas. Los esquemas piramidales estaban a la orden del día. Desde una perspectiva corporativa, el blockchain es el eufemismo cortés utilizado para introducir ideas y tecnologías similares, mientras se establece una distancia con esas criptomonedas. Existen casos de uso de supply chain para el blockchain, pero también abundan los desafíos.

Transcripción completa

Bienvenidos a esta serie de conferencias de supply chain. Soy Joannes Vermorel, y hoy presentaré “Blockchains for Supply Chain.” Las criptomonedas capturaron la imaginación del público, se hicieron fortunas y se perdieron fortunas, algunos villanos han sido capturados y encarcelados, y vendrán más. En medio de toda esta agitación, el término criptomoneda se volvió demasiado cargado para las grandes empresas promedio, que tienden a ser bastante conservadoras. Así, se adoptó el término blockchain como una manera de distanciar la innovación de toda la locura que ocurre en el mundo cripto. Sin embargo, fundamentalmente, las blockchains y las criptomonedas son lo mismo.

El objetivo de esta conferencia es adquirir una comprensión técnica, una comprensión técnica en profundidad, de lo que sucede con las blockchains. Si tienes algunas habilidades de programación, al final de esta conferencia, deberías ser capaz de reimplementar tu propia blockchain de juguete si así lo deseas. Basándonos en esta nueva comprensión técnica del blockchain, comenzaremos a revisar casos de uso de supply chain y evaluar su viabilidad como tecnologías para resolver problemas y su valor añadido en términos de lo que pueden hacer por los supply chains. Comencemos.

El origen de Bitcoin es simplemente extraño. En 2008, bajo el seudónimo de Satoshi Nakamoto, que probablemente fue un esfuerzo en equipo, se publicó un white paper llamado “Bitcoin: A Peer-to-Peer Electronic Cash System.” Este documento presenta un sistema y un enfoque para un nuevo tipo de moneda electrónica. Es un documento relativamente corto con algunas partes matemáticas, e incluso las partes matemáticas son en parte incorrectas.

El documento original establece que el sistema se supone que es seguro si al menos la mitad del poder de hash está del lado bueno. Sin embargo, se demostró más tarde en un documento posterior publicado en 2013, “Majority is Not Enough: Bitcoin Mining is Vulnerable,” que para mantener la red segura, no necesitas que la mitad del poder de hash sea honesta; en realidad, se requiere más de dos tercios del poder de hash.

No obstante, existe un white paper y un piece of software. El software es open source, y es una implementación de muy baja calidad. El cliente Satoshi es de muy baja calidad, y durante el primer año tras la publicación del software, los colaboradores del open source arreglaban apresuradamente toneladas de bugs e incidencias. Algunos de estos problemas fueron difíciles de solucionar debido al diseño original y tuvieron un efecto duradero en toda la comunidad. Muchas de las criptomonedas que existen hoy en día son forks del cliente original de Satoshi y, en cierta medida, aún cargan muchos de los problemas que no pudieron haberse solucionado a lo largo de los años.

Así, se trata de una situación muy desconcertante en la que tienes un documento que no es de la mejor calidad y un software que, indiscutiblemente, es de muy baja calidad, y sin embargo, el equipo de Satoshi Nakamoto realizó un descubrimiento asombroso. Fundamentalmente, el problema era conocido como el problema del consenso bizantino. Es un problema de computación distribuida. Imagina que tienes participantes, y todos esos participantes pueden ver lo que se supone que es el estado del sistema, que en el mundo digital puede pensarse como una larga serie de ceros y unos, una carga de datos. Los participantes pueden actualizar el estado del sistema, invertir algunos bits, añadir un bit, eliminar un bit, y pueden hacer todo eso al mismo tiempo. Los participantes pueden comunicarse entre sí, y el problema del consenso bizantino es lograr que todos los participantes honestos estén de acuerdo en un momento específico sobre cuál es el estado del sistema, hasta el último bit.

El problema es muy difícil si tienes participantes bizantinos que actúan como adversarios, tratando de confundir a los demás participantes. El descubrimiento asombroso de Bitcoin es que, si retrocedemos a 2008 y preguntamos a los expertos, probablemente habrían dicho que no parece posible resolver el problema del consenso bizantino de manera totalmente descentralizada sin una autoridad central. Sin embargo, el descubrimiento de Satoshi Nakamoto, el consenso Nakamoto, es que encontraron una manera de resolver este problema.

La solución es muy sorprendente. Parece un problema algorítmico, pero la esencia de la solución detrás de Bitcoin es que Satoshi Nakamoto resolvió este problema añadiendo incentivos monetarios, un incentivo financiero. No es solo una solución algorítmica; es literalmente un algoritmo que solo funciona porque, dentro del sistema, los incentivos monetarios están entrelazados, ofreciendo a los participantes incentivos para actuar de cierta manera.

Si queremos que esos incentivos estén en su lugar, necesitamos una moneda electrónica de algún tipo, para poder diseñar esos incentivos en primer lugar. Eso es exactamente lo que se hace en Bitcoin. Si quieres tener una moneda electrónica, al menos tienes dos problemas muy difíciles. El primer problema es el double spending. Si tienes cierta cantidad de dinero digital representado por algunos bits de información, ¿qué te impide hacer una copia de este dinero digital y gastar el dinero una vez para pagar algo y luego volver a gastar el mismo dinero con tu copia para pagar otra cosa? Este problema se conoce como double spending, y es un problema muy difícil que aborda Bitcoin.

El segundo problema es la emisión de monedas. ¿De dónde viene este dinero? Lo interesante es que, típicamente, cuando tienes un problema muy difícil que deseas abordar, adoptas un enfoque de divide y vencerás, subdividiendo tu gran problema en subproblemas que son más simples y pueden resolverse por separado. Luego, el problema total puede resolverse. Lo interesante de Bitcoin es que hay dos problemas distintos y muy difíciles: el double spending y la emisión de monedas. En lugar de utilizar un enfoque de divide y vencerás, Bitcoin emplea un enfoque de unificar y entrelazar, que era novedoso en ese momento, para resolver ambos problemas simultáneamente. La solución, como veremos más adelante en esta conferencia, es sorprendentemente simple.

Esta conferencia no trata principalmente de lo que hace que una moneda digital sea una buena moneda, ya que eso merecería una charla por sí sola. No obstante, las blockchains no operan sin los incentivos financieros diseñados a través de las monedas digitales que sustentan la propia blockchain. Cuando decimos que las criptomonedas y las blockchains son prácticamente lo mismo, la idea es que, si deseas tener una blockchain, transmitirás mensajes, y esos mensajes serán transacciones con un flujo de dinero involucrado. La perspectiva de las criptomonedas es que el enfoque principal está en el aspecto monetario, mientras que la perspectiva del blockchain se interesa más por los metadatos que se superponen a las transacciones.

Recuerda que todo el modelo de seguridad de estos sistemas de blockchain/criptomonedas se basa en los incentivos económicos diseñados sobre el sistema. No se pueden separar completamente los objetivos económicos y de criptomonedas del blockchain. Es solo una cuestión de perspectiva.

Ahora, echemos un vistazo rápido a los requisitos que conlleva un sistema de blockchain/criptomonedas, y cómo podemos potencialmente relajar esos requisitos. El primero es el no repudio. No repudio significa que, como participante, nadie puede impedirte transmitir una transacción. Nadie puede impedir que una transacción válida ocurra. Esto es muy importante, ya que si existe un participante capaz de hacer eso, entonces, esencialmente, tienes una autoridad central. Por el contrario, ningún participante puede impedir que se produzca una transacción válida, pero tampoco hay ningún participante que pueda negarte la posibilidad de realizar una transacción porque puedan consumir tu propia moneda o hacer que una transacción inválida tenga éxito. Ese es el primer requisito.

El segundo requisito es el anonimato. Técnicamente, Bitcoin es una red seudonónima, pero fundamentalmente, cuando hablo del requisito de anonimato, significa que no existe una lista de participantes. En una blockchain verdadera, los participantes pueden aparecer o abandonar el sistema en cualquier momento, sin un portero. Dado que los participantes pueden unirse o salir libremente, no hay nadie que rastree su identidad. Esto no significa que tenga que ser anónimo; solo significa que, si tienes una blockchain canónica verdadera, se debe cumplir el requisito de anonimato, en el que los participantes pueden unirse y salir como deseen.

Luego, enumero la escalabilidad masiva como un requisito, lo cual es particularmente difícil para las blockchains porque, como veremos, este tipo de sistemas distribuidos no son intrínsecamente fáciles de escalar. Por el contrario, escalar una blockchain es notablemente difícil. Fundamentalmente, hay un conflicto: si permites que cualquier participante transmita un número arbitrariamente grande de mensajes, transacciones o actualizaciones al sistema, un participante puede inundar toda la red y, esencialmente, enviar spam a toda la red. Así, todas las blockchains deben enfrentar este problema de escalabilidad, que se resuelve mediante el diseño de incentivos financieros.

La idea es mantener el costo de una transacción, que es el mensaje elemental transmitido en la blockchain, en algo como una décima de centavo. Esto es muy barato – imagina que tuvieras que pagar una décima de centavo para enviar un correo electrónico. No es gratis, pero sigue siendo de muy bajo costo. Entonces, si tienes un uso regular y deseas tener una transacción asociada, por ejemplo, al movimiento de un producto en un warehouse, está bien; el costo sigue siendo muy bajo. Sin embargo, al mantener el costo en 0.1 centavo, haces que esas transacciones sean demasiado caras para un atacante que quisiera inundar la red con miles de millones de transacciones, lo cual es muy fácil de hacer si no hay tarifas. Cada transacción tiene que pagar una tarifa por existir y para soportar su transmisión; de lo contrario, un atacante podría inundar el sistema distribuido sin obstáculos.

Así, las tarifas de transacción son otro ángulo en términos de ingeniería económica para mantener viable la blockchain. Quieres poder mantener esta tarifa de 0.1 centavo a cualquier escala porque otro problema que niega la escalabilidad masiva es que, si tenemos millones de transacciones, el costo de las transacciones se disparará. Este es un gran problema que no queremos. No queremos tener una situación donde tengamos un autobús con 100 personas que deseen tomarlo en cierto momento, pero solo hay 50 asientos. Si esto sucede, entonces habrá algún tipo de mecanismo de subasta, y el precio de los boletos se disparará. En términos de blockchain, esto significa que el costo de las transacciones se disparará. Por cierto, este tipo de problemas están ocurriendo con múltiples blockchains en la actualidad. Por ejemplo, en la red Bitcoin Core, es muy frecuente que el costo de una transacción supere los diez dólares, y esto es un gran problema.

Ahora, también queremos tener una latencia bastante baja. Lo que Satoshi Nakamoto descubrió en 2008, el consenso Nakamoto, funciona muy bien, pero fundamentalmente, es un proceso muy lento. Cuando digo muy lento, significa que para que los participantes converjan en el estado del sistema, toma aproximadamente una hora. No es dramáticamente lento, pero tampoco es muy rápido. Si queremos hacer algo relacionado con supply chain, donde queremos efectuar pagos o rastrear el movimiento de mercancías, sería mucho mejor si pudiéramos mantener la latencia del sistema en algo como tres segundos o menos – el mismo tipo de latencias que esperarías de un pago rápido con tarjeta de crédito.

Finalmente, uno de los últimos requisitos es la infraestructura. Cuando hablo de la infraestructura de software que soporta el blockchain o la criptomoneda, debe ser un bien público que se financie con algún tipo de contrato social acordado. Eso es algo que creo que Satoshi Nakamoto no previó en 2008. Si deseas operar un sistema mundialmente distribuido y muy complejo, hay una tonelada de infraestructura de software que debe ponerse en marcha y mantenerse. El problema es que, si no tienes alguna forma socialmente aceptada de financiar todos esos esfuerzos, surgen adversarios, no solo como adversarios bizantinos en la red que tratan de confundir a otros participantes sobre el estado de la red, sino que también surgen como adversarios que se harán cargo de la base de código en sí y harán cosas con la infraestructura de software que antagonicen los intereses de la comunidad en general. Ha ocurrido en la historia de las criptomonedas que se produzcan adquisiciones hostiles de un equipo a otro, haciendo que los nuevos equipos tengan intereses completamente desalineados con los intereses de la comunidad en general. Esta es una clase de ataques, más bien de ingeniería social, que Satoshi Nakamoto no vio claramente en 2008. Sin embargo, después de una década de operación, estos tipos de ataques son ahora mucho más evidentes para los observadores del mundo cripto.

Ahora, la historia hasta ahora: esta es una serie de conferencias sobre supply chain. Somos parte del cuarto capítulo. En el primer capítulo, presenté mis puntos de vista sobre supply chain como campo de estudio y como práctica, y hemos visto que requiere metodologías muy específicas. Todo el segundo capítulo está dedicado a metodologías de supply chain que son adecuadas para operar en este espacio. La mayoría de las metodologías ingenuas no sobreviven al contacto con la realidad, especialmente cuando existen conflictos de interés. Por cierto, muchos de los aspectos del segundo capítulo, en los que trato los conflictos de interés, son muy relevantes para la conferencia de hoy, así que invito al público, si aún no han visto las conferencias del segundo capítulo, a que les eche un vistazo. El tercer capítulo está dedicado a supply chain problems, que son literalmente conferencias en las que me concentro exclusivamente en problemas de supply chain, no en soluciones. La idea es entender realmente el problema antes de empezar a conjurar soluciones.

El cuarto capítulo es esencialmente una colección de ciencias auxiliares. Blockchain es un tema marginal que estoy añadiendo al final de este capítulo, pero, fundamentalmente, las ciencias auxiliares son disciplinas que realmente respaldan las prácticas modernas de supply chain. Así como esperarías que un médico moderno tuviera algunos conocimientos de química, no es necesario ser un químico brillante para ser un médico brillante. El consenso general sería que, desde una perspectiva moderna sobre la ciencia médica, si no sabes nada de química, no puedes ser un buen médico según los estándares modernos. Lo mismo ocurre con supply chain, en mi opinión. Existe una serie de ciencias auxiliares en las que necesitas tener algún conocimiento de esos temas si quieres tener una práctica de supply chain razonablemente moderna.

Ahora, para la conferencia presente, primero presentaré Mini Bitcoin, que es una implementación de toy blockchain. Debería arrojar luz sobre cómo funcionan las criptomonedas y cuál fue el insight clave que descubrió Satoshi Nakamoto en 2008. También debería aclarar los tres desafíos muy grandes que enfrentamos al diseñar blockchains, que son, a saber, escalabilidad, latencia y expresividad. Estos tres desafíos tienen un impacto significativo en el tipo de casos de uso de supply chain que podemos tener basados en blockchain. Es esencial entender las limitaciones que vienen con las blockchains porque, esencialmente, limitan lo que podemos hacer en términos de supply chain y el tipo de valor que podemos crear. Finalmente, como segunda parte de la conferencia, revisaré una serie de casos de uso de supply chain en los que, en diversos grados, supply chain tiene algo que aportar.

El objetivo de Mini Bitcoin es construir un toy blockchain, una versión simplificada de Bitcoin desde cero. No prestaremos demasiada atención a todas las tecnicidades involucradas porque, en la vida real, diseñar una blockchain implica prestar atención a toneladas de detalles. Aquí, solo quiero exponer la estructura general para mantenerla dramáticamente simplificada en comparación con la cosa real, de modo que podamos captar en unas pocas diapositivas lo que está sucediendo, cómo se está diseñando y cómo funciona.

En este ejemplo muy simple, vamos a diseñar una moneda en la que cada moneda vale exactamente un bitcoin. Tienes un conjunto de monedas, cada una vale exactamente un bitcoin, y lo único que se puede hacer es, esencialmente, transferir una moneda de un participante a otro. Si un participante posee muchas monedas, puede transferir todas, pero solo estamos considerando una moneda muy simple en la que no existen cantidades fraccionarias ni otros elementos.

Para construir este Mini Bitcoin, solo necesitamos tres funciones especiales: una función hash, una función de firma y una función de verificación. Estas funciones ya eran estándar en 2008, así que cuando se inventó Bitcoin, todos los bloques de construcción criptográficos ya estaban en su lugar. Satoshi Nakamoto no inventó ninguna de estas herramientas. Estas funciones criptográficas especiales, también conocidas como trapdoor functions, eran bien conocidas, estándar y ampliamente utilizadas en 2008. La innovación clave de Satoshi Nakamoto fue usar estas funciones de una manera muy especial, que veremos a continuación.

Tenemos estas tres funciones: la función de hash, sobre la cual no entraré en detalles aquí, pero ya la he comentado en una conferencia anterior. Esta es una versión criptográfica de la función de hash, que puede tomar cualquier mensaje, una serie de bits de longitud arbitraria, y crear un resumen de 256 bits. La función no puede, en la práctica, invertirse. Si tienes un resumen, la única manera de identificar un mensaje que lo produzca es conocer el mensaje de antemano.

La función de firma puede tomar un mensaje, una llave privada y producir una firma, que nuevamente es de 256 bits. La función de firma funciona en pareja con una función de verificación. Para aquellos que quizás no estén familiarizados con la criptografía asimétrica, la idea es que puedes tener mecanismos en los que existan pares de llaves públicas y privadas. Con la llave privada, puedes producir una firma y publicar un mensaje sin revelar tu llave privada. Cualquier participante puede usar la función de verificación para tomar el mensaje, tu firma y tu llave pública y verificar que el mensaje ha sido firmado por la llave privada asociada a dicha llave pública.

Estas funciones trampa no pueden invertirse, así que si no conoces el mensaje original, no puedes retroceder desde la función de hash, desde el resumen, hasta el mensaje original. Lo mismo ocurre si no posees la llave privada; no puedes producir una firma por tu cuenta si tienes un mensaje nuevo.

Estas tres funciones especiales están disponibles en prácticamente todos los entornos de programación modernos, ya sea C++, Python, Java, C# u otros. Es parte del entorno estándar tener acceso a estas clases de funciones criptográficas.

Ahora, observemos una situación en la que se supone que soy el propietario de la moneda número uno. ¿Qué significa eso? Significa que, como parte de este consenso bizantino, existe un acuerdo compartido entre todos los participantes en esta red Mini Bitcoin de que, como parte de los UTXO (Unspent Transaction Outputs), esta moneda realmente está presente. Cuando digo esta moneda, me refiero a un mensaje que incluye la llave pública número uno y la firma cero. Simplemente asumo que esto forma parte de un conjunto de monedas y que todos los participantes están de acuerdo en que esta moneda realmente existe y está lista para ser gastada. Ahora, como propietario de esta moneda número uno, ¿cómo gasto realmente esta moneda para transferir su propiedad a otra persona?

La forma de hacerlo es produciendo una firma. La firma se construye de la siguiente manera: estoy usando la función especial sign y voy a firmar un mensaje. Este mensaje será simplemente la llave pública número uno, la firma cero y, a continuación, la llave pública número dos. La llave pública número dos es literalmente la dirección a la que estoy enviando el dinero. Quien posea la llave privada asociada a esta llave pública número dos será el destinatario de mi transacción. Así, firmo esta transacción, y para ello, uso la llave privada número uno. El único participante que puede producir efectivamente esta firma número uno es la persona que tiene el secreto, la llave privada número uno, asociada a la llave pública número uno.

Si quiero que toda la red sepa que se ha realizado esta transacción, necesito difundir una transacción. La transacción será simplemente un mensaje que enumera la llave pública número uno, la firma cero, la llave pública número dos y la firma uno que acabo de producir. Es solo una lista de los elementos que componen la transacción. Cuando publico esta transacción de uno a dos, esencialmente, la moneda número uno sale del conjunto de monedas y la moneda número dos entra en dicho conjunto como parte del sistema. Por eso es crucial tener en juego este consenso bizantino. Necesitamos este consenso bizantino porque, potencialmente, te gustaría poder gastar dinero que no posees y confundir a la red sobre la propiedad de algunas monedas. Sin embargo, si puedes resolver el problema del consenso bizantino, existe un acuerdo firme sobre las monedas que realmente pertenecen al sistema. Una vez que una moneda se gasta, el propietario número dos ahora tiene una moneda. Una moneda puede salir de la red y se crea una nueva que entra en el estado del sistema.

El mecanismo se puede repetir; la moneda número dos puede enviarse a la moneda número tres utilizando el mismo sistema: producir una firma, difundir una transacción, y así sucesivamente.

Por cierto, cada vez que dije que se está utilizando la función “sign”, implícitamente significa que todos los observadores pueden usar la función “verify” para comprobar que la firma es correcta. Fundamentalmente, cuando los participantes van a observar las transacciones, lo primero que harán es usar la función “verify” que introduje previamente para verificar que la transacción es realmente correcta. Hay dos comprobaciones involucradas: cada participante tiene que verificar que la moneda que se está transfiriendo ya formaba parte del estado del sistema, asegurándose de que es una moneda válida, y que la transacción es válida según la firma. Lo que no he abordado aquí es el problema del doble gasto. ¿Cómo impedimos que se realicen dos transacciones conflictivas al mismo tiempo, y cómo evitamos que la red se confunda si un adversario intenta difundir dos transacciones conflictivas simultáneamente, enviando el mismo dinero a dos participantes distintos?

Tampoco he aclarado de dónde provienen estas monedas. ¿Cómo se introducen en el sistema en primer lugar? La clave del descubrimiento de Satoshi Nakamoto y su Nakamoto Consensus es resolver estos dos problemas a la vez.

La proposición de Satoshi Nakamoto es introducir una clase especial de participantes en la red, actualmente apodados “miners.”

Los miners esencialmente escuchan la red y recogen todas las transacciones que han sido difundidas. Recogen estas transacciones difundidas y las colocan en un contenedor llamado “block.” Un block es simplemente una colección de transacciones difundidas por cualquiera en la red peer-to-peer.

La primera transacción de un block será una transacción especial llamada “coinbase.” Una coinbase es una transacción única que crea una nueva moneda en este setup de Mini Bitcoin de la nada. La primera transacción es la coinbase, que crea una nueva moneda de la nada, y luego en el block sigue la lista de transacciones que han sido difundidas, según lo percibido por el miner. Es posible que el miner no pueda capturar todas las transacciones de la red Bitcoin, pero lo intenta.

La coinbase es especial, y explicaré cómo construir esta coinbase porque es una transacción única. Primero, vamos a producir un hash del block, un hash parcial (H1a). Este hash es esencialmente un hash de un mensaje, y este mensaje comienza con un hash del block anterior (H0b), concatenado con todas las transacciones presentes en el block.

La coinbase es entonces una tupla que incluye el hash H1a, seguido de un nonce. Un nonce es un número aleatorio elegido al azar por el miner y tiene su importancia. La coinbase también contiene la llave pública del miner. La coinbase incluye un hash de todo el contenido del block. La coinbase contiene un número aleatorio y la llave pública del miner. Esta llave pública será utilizada por el miner más adelante para reclamar la coinbase como una moneda regular. En este setup de Mini Bitcoin, las monedas se emiten a un ritmo de un Bitcoin por block. En realidad, en la red Bitcoin Core o Bitcoin Cash, el proceso es más complicado, pero la mayor parte de la complejidad puede simplificarse en aras de la claridad.

La idea es que, para que el block sea considerado válido, necesitamos producir una coinbase. Sin embargo, si nos detenemos en este punto, todos los miners podrían afirmar que tienen un block cuando quieran, y todos los miners tendrían interés en decir: “Puedo producir un paquete, un resumen de todas esas transacciones. Puedo producir una coinbase. Por favor, entréguenme este Bitcoin extra.” ¿Cómo organizamos a todos los miners compitiendo para que su versión del block sea seleccionada por la red y considerada el único block verdadero?

Satoshi Nakamoto introdujo el concepto de proof of work. El hash de la coinbase, que es un gran número de 256 bits, tiene que estar por encima de un umbral de dificultad. Este proceso es como resolver un rompecabezas, y la única manera de resolver este rompecabezas es encontrar una coinbase que tenga un hash que cumpla con este objetivo de dificultad. El miner puede probar muchos números aleatorios para el nonce con la esperanza de ser el primero en alcanzar la dificultad y reclamar el block para sí mismo.

En Bitcoin, la dificultad es adaptativa, y la red utiliza un algoritmo de promedio móvil glorificado para mantener la dificultad en torno a 10 minutos por block. Si los blocks se encuentran en promedio a un ritmo más rápido que 10 minutos, la dificultad aumentará hasta que se encuentren blocks cada 10 minutos, en promedio. Si los blocks comienzan a encontrarse cada 11 minutos, la dificultad disminuirá para mantener el tiempo promedio de encontrar un block en 10 minutos.

La propuesta de Satoshi Nakamoto es que los mineros sigan siempre la cadena válida más larga. Una cadena de bloques debe cumplir con el objetivo de dificultad para ser válida. Al construir un bloque, siempre se construye sobre un bloque preexistente, excepto el bloque génesis, que es el punto de partida por defecto. La regla no se trata solo de tener la cadena más larga, sino la cadena válida más larga. Otros mineros verificarán que todas las transacciones listadas en un bloque sean realmente válidas, asegurándose de que las firmas coincidan y de que las monedas que se gastan sean elegibles para ser gastadas. Ellos mantienen este estado, y es precisamente así como Bitcoin puede resolver tanto el problema del doble gasto como el problema de la emisión de monedas. Tenemos todo lo necesario para construir una blockchain.

En realidad, si deseas construir una blockchain de grado producción real, hay toneladas de cosas extra a considerar. Primero, te gustaría tener cantidades fraccionadas. Probablemente no quieras poder tener solo un Bitcoin a la vez; deseas algo en lo que puedas transferir múltiples o cantidades fraccionadas de Bitcoins.

En términos de monedas, te gustaría tener transacciones que puedan consumir muchas monedas como insumos a la vez y luego producir muchas monedas de una sola vez. No se tratará de transacciones uno a uno que conecten una moneda con otra; serán transacciones de muchos a muchos, con muchas monedas de entrada conectándose a muchas monedas de salida. Por cierto, así es como operan actualmente varias redes de Bitcoin.

También están las comisiones de transacción que mencioné. Si permites que las personas transmitan transacciones sin fin, podrían enviar dinero de ida y vuelta entre las mismas direcciones y saturar el mercado. La idea es que una comisión es, fundamentalmente, la noción de que una cierta porción de la transacción se redirige al minero. La forma en que típicamente se hace en la mayoría de las variantes de Bitcoin es decir que la entrada total, en términos de valor monetario, debe ser ligeramente mayor que la salida total. La fracción faltante de valor, la diferencia, es la recompensa pagada al minero.

Ahora hemos completado nuestro mini Bitcoin. Si sabes programar, tienes todos los elementos necesarios para implementar tu propia blockchain. Por cierto, también puedes repetir bloques, y eso es lo que estoy haciendo aquí. Lo que acabas de hacer para un bloque, puedes repetir las mismas fórmulas exactas para otro bloque, con una segunda base de código. Esto es igual que las transacciones; el mismo mecanismo se repite una y otra vez.

Escalar la blockchain es muy desafiante. En un breve white paper de 2018, publiqué un panorama aplicativo de Bitcoin. La idea es que, dependiendo de la cantidad de datos en los que estén involucradas tus blockchains, la cantidad de datos que tienes que procesar y mover varía enormemente según lo que estés haciendo con la blockchain. Esencialmente, varía desde aproximadamente 100 bytes para mover (el orden de magnitud de una clave privada) hasta 10 órdenes de magnitud si tienes que lidiar con toda la blockchain.

Es difícil asimilar el hecho de que, dependiendo de lo que estés haciendo, la cantidad de recursos de cómputo que tendrás que inyectar para realizar el trabajo varía en 10 órdenes de magnitud. Una orden de magnitud significa que multiplicas la cantidad de recursos por un factor de 10, y cuando tienes 10 órdenes de magnitud, puedes pasar de uno a 10 mil millones. Esto es asombroso y enorme. En este panorama aplicativo, verás que hay dos distinciones principales: aplicaciones on-chain y off-chain. Las aplicaciones off-chain son aquellas que solo se ocupan de los datos generados por ti o tus socios cercanos. Si eres una gran empresa, puede que tengas que lidiar con millones de transacciones, pero estas son solo tus propias transacciones. En términos de datos, pueden ser grandes, pero son manejables ya que se relacionan directamente con tu propio negocio.

Por otro lado, las aplicaciones on-chain se ocupan de todas las transacciones transmitidas a través de la red. Esto puede ser enormemente mayor, especialmente si eres un jugador pequeño y necesitas gestionar todas las transacciones en una gran red, que pueden ser millones de veces más que las transacciones que te importan.

Además, necesitamos distinguir entre componentes que son cash cogs y cash lands. Cash cogs son componentes fundamentales que contribuyen a la resolución del problema de consenso. Si los eliminas, la blockchain deja de funcionar porque ya no tienes consenso. Cash lands, por otro lado, son componentes opcionales que se pueden construir sobre la infraestructura de la blockchain. Estos no son estrictamente necesarios para que la blockchain opere.

Típicamente, cuando pensamos en casos de uso de supply chain, nos posicionamos con metadatos en el ámbito de cash lands. Lo que estamos haciendo no es estrictamente necesario para que la blockchain continúe operando; puede seguir funcionando sin nuestro caso de uso específico.

En términos de escalar la blockchain para casos de uso reales de supply chain, debes considerar que la blockchain debería ser capaz de manejar millones de transacciones. Las grandes empresas manejan millones de transacciones semanales, lo cual no es excepcional en el mundo del supply chain. Sin embargo, las blockchains tienen una escalabilidad deficiente, como lo evidencia el hecho de que los mineros deben tratar con todas las transacciones de todos.

Para abordar este problema, se han introducido algunas innovaciones, como las soluciones discutidas anteriormente en la conferencia. El objetivo principal es hacer que la tecnología blockchain sea más escalable y adecuada para manejar el masivo volumen de transacciones típicamente visto en aplicaciones de supply chain. Si quieres que una blockchain se use para fines de supply chain, debe ser capaz de manejar no solo las transacciones de una sola empresa, sino también las de todas las empresas que participan en la iniciativa blockchain. Eso puede volverse extremadamente grande, o en realidad muy grande, tal vez excesivamente. Eso es lo que tenemos que ver, y aquí, al rescate, han surgido esencialmente dos trabajos destacados. Cuando Satoshi Nakamoto publicó su documento, dijo que con el progreso del hardware, este problema se solucionaría, y escalaríamos tanto como fuera necesario. Esto sucedería. Sin embargo, resultó ser difícil, y desde hace más de una década, prácticamente todos los actores en este espacio de blockchain y criptomonedas han estado luchando en cuanto a escalabilidad.

El primer trabajo destacado es ECMH, Elliptic Curve Multiset Hash. Es un documento bastante técnico, pero la conclusión clave es la idea de que no es necesario conservar todas las transacciones; solo se deben conservar las monedas que están listas para gastarse. Esta colección de monedas que pueden ser gastadas se conoce técnicamente en el ecosistema de Bitcoin como el UTXO. Solo a modo de orden de magnitud, el UTXO de la red Bitcoin Core es actualmente un poco inferior a cinco gigabytes. Este es el tamaño del conjunto de datos del UTXO, pero si miras la blockchain de Bitcoin Core, el tamaño de la blockchain es un poco inferior a 350 gigabytes, y la blockchain está creciendo mucho más rápido que el UTXO.

Lo que el artículo ECMH te ofrece es una función hash que tiene afinidad con los multiconjuntos. Esencialmente, es una función hash en la que puedes actualizar tu hash si añades o eliminas elementos a tu colección. No preservas el conjunto o el multiconjunto en sí, sino que simplemente preservas el hash, y puedes añadir o eliminar elementos. Esta propiedad similar a un conjunto significa que puedes hacer esas adiciones o eliminaciones en cualquier orden y aún así obtener el mismo hash. Lo que obtienes a través de ECMH es una manera de tener un compromiso de UTXO, que permite a la comunidad alejarse de la blockchain completa. La mayor parte de la comunidad no tiene que lidiar con la blockchain completa, sino solo con el UTXO. Repito, el tamaño del UTXO en la red Bitcoin Core es de cinco gigabytes, y el tamaño de la blockchain es de 350 gigabytes, así que básicamente ganas dos órdenes de magnitud. Esto es muy significativo. Esencialmente, con ECMH, ganas dos órdenes de magnitud en almacenamiento de datos persistente, lo cual es una victoria masiva.

El segundo trabajo es Graphene, un nuevo protocolo para la propagación de bloques utilizando reconciliación de conjuntos. Graphene te permite ganar esencialmente dos órdenes de magnitud en los requisitos máximos de ancho de banda. En esta configuración de mini Bitcoin que acabo de describir, tienes mineros y transacciones transmitidas al estilo peer-to-peer todo el tiempo en la red. El ancho de banda es probablemente el problema más resuelto de Bitcoin, pero, no obstante, tienes un problema cuando se trata del ancho de banda en el momento en que se encuentra un bloque. El minero, para reclamar el bloque, debe propagar el coinbase, donde dice, “Mira, tengo un coinbase que cumple con mi objetivo de dificultad.” Luego, todos los demás mineros deben descargar el bloque completo, y si se hace de manera ingenua, tienen que validar que el bloque sea efectivamente válido, no solo que el coinbase cumpla con el objetivo de dificultad.

Cada vez que se encuentra un bloque, hay un requisito pico porque quieres que el tiempo que se tarda en transferir un bloque completo, si lo haces de manera ingenua, esté muy por debajo del intervalo de 10 minutos. En Bitcoin, el rompecabezas se ajusta en términos de dificultad de tal manera que el tiempo promedio entre dos bloques consecutivos es, en promedio, de 10 minutos. Así, se desea que la transferencia del bloque sea solo una fracción, digamos menos de 30 segundos, si se quiere mantener la red muy estable. Sin embargo, eso implica que el bloque debe transferirse en 30 segundos, lo que pone un límite a tu ancho de banda pico. La velocidad a la que se transferirá tu bloque estará limitada por tu ancho de banda.

La idea es que con Graphene, una técnica basada en la compresión, no necesitarás transferir el bloque completo porque la mayor parte de lo que contiene el bloque son en realidad las transacciones que ya se han transmitido a través de la red. Lo único que se desea transmitir es un conjunto de reconciliación, solo para dar información a tus pares (otros mineros) sobre qué transacciones han sido incluidas o no en tu bloque, de una manera perfectamente confiable. Si haces eso, puedes reducir nuevamente dos órdenes de magnitud en el ancho de banda pico, lo cual es muy significativo.

Esto es de gran interés, por ejemplo, Graphene funcionaría en redes Bitcoin Cash o en las más recientes redes eCash, debido a completos accidentes técnicos. No funcionaría en la red Bitcoin Core. Esto fue parte de las cosas que Satoshi Nakamoto no anticipó realmente.

El último requisito que mencioné en mi lista de requisitos es que mantener el software implica tener un contrato social en marcha, de modo que cuentes con equipos que puedan hacer el mantenimiento e incorporar descubrimientos posteriores en tu blockchain. De lo contrario, quedas atrapado con el tipo de rendimiento y estabilidad que tenías hace una década o en el momento de la creación de la blockchain.

Ahora tenemos otro problema: acelerar la blockchain. La red clásica de Bitcoin tiene un tiempo promedio entre bloques de 10 minutos, y si quieres tener verdadera confianza en el estado del consenso, necesitas esperar por múltiples bloques. Como regla general, la gente suele estimar que, si deseas tener confianza absoluta, debes esperar por seis confirmaciones, lo que te da un marco de tiempo de una hora. La idea es que podríamos hacer este tiempo entre bloques más corto. Sin embargo, el problema es que, cuanto menor es el tiempo, menores deben ser los bloques, lo que socava la escalabilidad. Los bloques infrecuentes significan que puedes tener bloques muy grandes, lo cual es algo bueno; ayuda a tu red a lidiar con la masa de transacciones.

Considerando los retrasos que tienes en la red global, este objetivo de 10 minutos no es óptimo, pero está dentro del rango de lo que es eficiente para operar este tipo de consenso distribuido con bloques muy grandes, bloques que pueden tener hasta un terabyte de tamaño. Eso suena muy grande, pero en realidad, si observas el caso de uso a escala humana, eso es lo que se necesita. Necesitas mantener los bloques muy espaciados en términos de tiempo si deseas preservar tu escalabilidad. Sin embargo, luego tienes el problema de que la red es lenta. Una hora para confirmar una transacción podría estar bien para un caso de uso de ecommerce, donde está bien si no haces nada después del pago durante 60 minutos, ya que la entrega no se realizará antes de mañana. Pero si quieres que ocurra algo dentro de un almacén o en el punto de venta, esto es demasiado lento. Es como una tarjeta de crédito que tardaría una hora en liquidar el pago, lo cual es muy lento.

Lo que queremos es típicamente un objetivo de algo que sean tres segundos o menos. Esto se debe a que, desde la perspectiva de la experiencia del usuario humano, algo que tarda tres segundos en liquidarse se percibirá como razonablemente rápido. Piénsalo como un pago con tarjeta de crédito; si cuentas uno-dos-tres al hacer un pago, está bien, es razonablemente rápido. Si puedes estar completamente seguro dentro de este marco de tiempo, puedes obtener una experiencia de usuario muy decente para la mayoría de los casos de uso. Sigue siendo demasiado lento para la comunicación máquina a máquina de baja latencia, pero es suficiente para la mayoría de los casos de uso que involucran la percepción humana.

Durante casi una década, se presentaron numerosas soluciones para abordar este problema de latencia. La gran mayoría de esas soluciones no eran muy buenas. Todas tenían diversas limitaciones que socavaban a Bitcoin o su escalabilidad, o eran soluciones ingenuas que surgieron rápidamente una vez que Bitcoin fue publicado. La mayoría de estas soluciones dependían de elegir un líder, y este líder actuaría como una autoridad central temporal por un periodo de tiempo, proporcionando servicios de baja latencia. Sin embargo, el problema de elegir un líder es que, cuando se transita de un líder a otro, el proceso puede ser muy desordenado, y se puede tener una situación en la que, en términos de calidad del servicio, la mayor parte del tiempo sean unos pocos segundos y luego, a veces, en realidad sea una hora. Eso sería percibido por todos como un tiempo de inactividad de la red.

Se tardó una década en que se publicara una solución que, en mi opinión, fuera lo suficientemente buena. Esta solución es una pieza brillante de trabajo de un equipo anónimo llamado Team Rocket, publicado en mayo de 2018: Snowflake to Avalanche, otra familia de protocolos de consenso metastable para criptomonedas. Este documento presenta una serie de tres algoritmos: Snowflake, Snowball y Avalanche. Cada algoritmo se construye sobre el anterior, y por cierto, la verdadera magia se encuentra en el algoritmo Snowball, que es precisamente el que no aparece en el título del documento.

Fundamentalmente, lo que han diseñado es metaestabilidad, y eso es muy interesante. Recuerda, cuando tienes transacciones conflictivas, realmente no importa cuál se elija, porque mejorar la latencia se trata de prevenir el doble gasto o de reducir el periodo durante el cual puede haber ambigüedad sobre el doble gasto. La idea de tener algo que es metaestable es que te gustaría contar con un protocolo en el que los participantes conversen constantemente. El objetivo es que, si hay dos transacciones conflictivas, la red alcance un equilibrio metaestable. La red convergerá rápidamente hacia una única interpretación de la verdad; no importa cuál, solo tiene que ser una. Así que, si existen objetos conflictivos, la red discutirá y resolverá el conflicto.

Snowflake proporciona un proceso de convergencia lento, mientras que Snowball, en este artículo, ofrece un truco que permite una aceleración exponencial, resultando en una convergencia mucho más rápida. Avalanche aporta algunas propiedades de grafos relacionadas con el grafo de transacciones. Sin embargo, mi entendimiento personal es que la contribución de Avalanche es mucho más débil; en realidad, es Snowball lo que hace la magia. Puede que quieras implementar Avalanche, pero solo con Snowball obtendrás aproximadamente el 99% de la metaestabilidad que buscas.

Hay un inconveniente en este enfoque. Con la prueba de trabajo y los bloques de Satoshi Nakamoto, cualquier observador puede intervenir y presenciar lo ocurrido, reproduciendo todo el proceso y verificándolo todo. La seguridad no depende de que el observador esté en línea. El observador puede estar en línea o fuera de línea, y no importa. Este es un gran modelo de seguridad que no depende de una conexión en vivo a la red.

Avalanche, por otro lado, requiere que el observador monitoree constantemente las conversaciones de la red para generar seguridad. No es posible que un observador tardío se una y reevalúe la seguridad de transacciones pasadas. Sin embargo, realmente no nos preocupa este asunto porque, si estás en vivo en la red, evalúas la seguridad de las transacciones que tienen lugar en ese momento. Para lo que sucedió en el pasado cuando no estabas allí, la prueba de trabajo y los bloques siguen proporcionando una forma de validar las transacciones.

Avalanche no está en oposición a Bitcoin; es complementario. Uno de los aspectos débiles de la solución de Snowflake a Avalanche es que no proporciona una solución limpia al problema de la emisión de monedas. Para obtener lo mejor de ambos mundos, sería ideal mantener un diseño similar a Bitcoin con prueba de trabajo y bloques grandes, mientras se superpone esto con seguridad de baja latencia.

Para evitar ciertas clases de ataques Sybil que podrían confundir a Avalanche, se podría emplear proof of stake. Esto introduce capas de enredo económico, que es una forma muy al estilo Bitcoin de pensar. Para lograr la seguridad deseada, se debe crear una red de enredos económicos que asegure que todos se mantengan honestos. Existen maneras de diseñar soluciones para lograr una mejor latencia.

Ahora, aún en el tema de la expresividad, buscamos algo más que transacciones financieras, ya que se trata de supply chain y de usar un blockchain para propósitos de supply chain. Las transacciones financieras son necesarias en el trasfondo, pero queremos poder hacer más. La pregunta es, ¿cómo incorporamos esta lógica extra?

En los círculos de las criptomonedas, muchas criptomonedas han introducido la noción de smart contracts. Un smart contract es fundamentalmente un programa que es operado por los propios mineros en el blockchain. Los mineros verifican la validez de las transacciones, pero si puedes incluir un lenguaje de programación o código assembly como parte de tu transacción, los mineros podrían ejecutar los programas y comprobar que estos verifican ciertas propiedades. Esto es lo que típicamente se hace en Ethereum, y se le conoce como smart contract. Existe el lema “code is law”, lo que significa que confiamos en la ejecución del programa porque es certificado como correcto por los propios mineros.

Sin embargo, creo que este enfoque está profundamente equivocado en dos frentes muy diferentes. El primer problema es que estás empeorando el problema de escalabilidad. Escalar un blockchain ya es muy difícil, ya que tienes que canalizar todas esas transacciones hacia los mineros. Los mineros no tienen que hacer mucho con estas transacciones; solo tienen que verificar la firma. Un minero puede potencialmente procesar una cantidad masiva de transacciones porque la cantidad de verificaciones que se deben realizar por cada transacción es mínima. Ahora, imagina si un minero no solo tiene que validar transacciones, sino también ejecutar programas arbitrarios de todas las compañías. Se vuelve muy difícil, y esto es exactamente lo que ha estado sucediendo durante mucho tiempo en la red de Ethereum y en otras criptomonedas orientadas a contratos complejos.

Aunque criptomonedas posteriores como Ethereum se beneficiaron de una mejor ingeniería, aún enfrentan un problema de escalabilidad enormemente más difícil. Una vez que alcanzan cierto nivel de notoriedad y actividad en la red, todas se enfrentan a problemas masivos de escalabilidad. Todo se reduce al hecho de que tienes que ejecutar todos esos programas.

El segundo gran problema con los smart contracts es que son programas fundamentalmente inmutables. Cuando colocas programas en el blockchain, la idea es que confías en esos programas porque operan de manera autónoma. Con “autónomamente” se entiende que hay mineros con incentivos financieros para ejecutar esos programas para la comunidad, y que todo el proceso es transparente y verificable. Sin embargo, el gran problema de los programas inmutables es que, si hay un error, no se puede corregir.

La historia de los smart contracts ha sido una serie interminable de vulneraciones que han resultado en pérdidas masivas para quienes operan los contratos. Incluso el propio Ethereum tuvo que someterse a un fork masivo, dando lugar a Ethereum y Ethereum Classic, porque un contrato vulnerado fue tan significativo que los operadores decidieron que era mejor revertir los problemas y socavar la propiedad inmutable que se supone debe ofrecer el blockchain. No hay solución alternativa, y si haces algo no trivial en un smart contract, te expones a vulneraciones.

En 2018, publiqué otro enfoque llamado Tokida que muestra cómo puedes tener programas arbitrarios funcionando junto al blockchain. Con Tokida, el programa es de código abierto y opera bajo un modelo de “trust but verify”. Todas las personas que estén interesadas en el resultado del contrato pueden verificarlo si lo desean, y en términos de rendimiento, es más flexible porque el resto de la comunidad no tiene que ejecutar tu programa. Si quieres parchear tu software, aún puedes hacerlo en cualquier momento sin que el resto de la comunidad desconozca lo que has hecho.

Si hay una vulneración, no es un problema significativo porque puedes solucionarlo con un parche, y la comunidad puede evaluar que el parche se hizo de buena fe. La idea es que, en cuanto a un modelo de seguridad para fines de supply chain, basta con trust but verify. Solo necesitas asegurarte de que, si alguien hace trampa, todas las demás personas lo noten, y eso será suficiente. Para la moneda en sí, quieres prevenir que la gente haga trampa desde el principio. Pero para los smart contracts, no se requiere el mismo grado de seguridad que para la moneda. Poder detectar fraudes después del hecho es suficiente. Si alguien comienza a defraudar tu negocio, simplemente no volverás a hacer negocios con ese socio, y ese sería el final de la historia. No necesitas tener algo que prevenga el fraude desde el inicio. La confianza es esencial en el mundo de los negocios, y si trabajas con un socio, mantienes cierto grado de confianza con él.

Ahora, estamos entrando en la segunda parte de la conferencia, que abarca casos de uso. Creo que el caso de uso principal para blockchains sigue siendo el de los pagos. Pagar a los proveedores, especialmente a los del extranjero, aún puede ser un desafío. Liquidar una transferencia bancaria puede ser lento, llegando a tomar hasta dos semanas en algunos casos. Los flujos de pago del sistema bancario están lejos de estar actualizados con el siglo XXI, lo que puede dar lugar a errores como pagos dobles por facturas elevadas.

Creo que hay muchos casos de uso para los pagos, especialmente cuando se trata de implementar mecanismos complejos como pagos diferidos, pagos condicionales o penalizaciones para productos que no cumplen con los requisitos de calidad o los plazos. Con dinero programático, puedes implementar todos estos esquemas de maneras que habrían parecido ciencia ficción.

Sin embargo, hay dos advertencias para este caso de uso. Primero, las criptomonedas aún son increíblemente volátiles en valor, lo que significa que su valor puede fluctuar dramáticamente con el tiempo. Esta volatilidad es un problema constante, pero durante la última década ha ido disminuyendo. La volatilidad era incluso mayor hace diez años, y ha ido disminuyendo gradualmente desde entonces, pero aún permanece fuera de la zona de confort de la mayoría de las grandes empresas. Observar fluctuaciones diarias del 10% en el valor de estas criptomonedas sigue siendo la norma. Hace una década, era alrededor del 50%. El segundo problema para los pagos es la existencia de miles de criptomonedas, lo que crea el problema de elegir una y ponerse de acuerdo con tu socio. Sin embargo, existen sistemas robotizados de cambio de divisas que pueden convertir cualquier criptomoneda en otra, cobrando comisiones muy bajas, como el 0.1%, lo que ayuda a mitigar este problema.

Otro caso de uso es la trazabilidad pasiva. La trazabilidad es esencial en muchas industrias, como la aeroespacial, farmacéutica y automotriz, ya que puede ser cuestión de vida o muerte. Las piezas de automóvil falsificadas, por ejemplo, pueden provocar accidentes fatales si fallan bajo estrés. Los non-fungible tokens (NFTs) se pueden utilizar para llevar la trazabilidad a un nuevo nivel. Un NFT es como un número de serie transferible. Con transacciones seguras, solo el propietario de este número, con sus claves privadas, tiene el poder de transferir dicho número a otro participante. El uso de NFTs puede prevenir falsificaciones, incluso por parte de los emisores originales.

Para implementar la trazabilidad basada en NFTs, solo necesitas códigos QR y un smartphone, lo que lo convierte principalmente en una solución basada en software. La tecnología blockchain ofrece una forma de mantener una trazabilidad transparente desde la producción hasta el consumidor. Sin embargo, existen desafíos. Primero, todos deben ponerse de acuerdo en un único formato y en un solo blockchain. El blockchain transporta cargas útiles binarias, por lo que si deseas utilizarlo para fines de trazabilidad, el formato debe ser consensuado. Esto se convierte en un asunto complejo, ya que muchas industrias y empresas tienen sus propios formatos y estándares únicos.

Lo que la gente no se da cuenta necesariamente es cuán flexibles tienden a ser las supply chains en el mundo real. Por ejemplo, incluso en la industria aeroespacial, donde la trazabilidad es absolutamente excelente, notarás que en el punto A, el documento que acompaña a una pieza es un PDF. En la siguiente etapa, es el mismo PDF pero escaneado, y tal vez en la etapa siguiente, es el mismo escaneo pero con anotaciones y vuelto a escanear. Fundamentalmente, se asume que un humano puede intervenir y descifrar los documentos. Sin embargo, si deseas operar en un blockchain, no puedes tener un proceso tan laxo. Debes especificar completamente el formato binario para todos los datos que deseas exponer a través del blockchain; de lo contrario, pierdes el ángulo programático que te permite trabajar con herramientas programáticas.

Unificar todos los estándares es difícil, y tienes que escoger un único blockchain porque, para que la trazabilidad funcione, necesitas elegir un blockchain que sea compartido por todos los participantes, al menos para un sector y una región. El problema es que, a la hora de escoger un blockchain, existen enormes conflictos de interés. Dado que un blockchain nunca puede estar completamente desvinculado de su criptomoneda subyacente, si inviertes en una criptomoneda, te vuelves conflictivo en el sentido de que tienes un interés personal en asegurarte de que la compañía elija el blockchain asociado a la criptomoneda que posees.

Estos conflictos de interés son generalizados y difíciles de evaluar, ya que los blockchains son típicamente anónimos. Si deseas probar y obtener retroalimentación sobre qué blockchain elegir, debes considerar los potenciales conflictos de interés que puedan surgir entre tu personal. Las empresas que operan grandes supply chains suelen tener a muchas personas involucradas, y estos problemas se magnifican.

Ahora, consideremos un ejemplo más adversarial. Imagina compañías farmacéuticas que operan en países muy pobres, como algunos países africanos, donde enfrentan problemas significativos con medicamentos falsificados. El problema es que, en estos países pobres, todos los intermediarios son corruptos hasta cierto punto. Los intermediarios corruptos pueden tomar una caja real con productos auténticos, cambiar los medicamentos reales por otros falsificados, y luego vender la caja en el mercado. Las personas que compran medicamentos falsificados pueden tener una condición que ponga en riesgo su vida y realmente necesiten el medicamento. Este es un problema muy serio en los países pobres, y reproducir el empaque de medicamentos falsificados es algo trivial. Una solución potencial es usar blockchains y tokens para una trazabilidad activa, lo que recuerda al funcionamiento del impuesto al valor agregado (IVA) en Europa. El IVA es un impuesto difícil de defraudar porque crea un esquema de ingeniería social en el que las empresas se enredan con sus proveedores honestos.

La idea es tomar el mismo concepto y aplicarlo al blockchain. Por ejemplo, supongamos que eres una compañía farmacéutica que produce un medicamento. Vendes un paquete del medicamento a un intermediario o mayorista a un precio más alto, por ejemplo, $15 en lugar del precio real de $10. Se produce la transferencia de propiedad del token, y el mayorista puede canjear $1 del valor, reduciendo su costo a $14. Luego, el mayorista vende el paquete de medicamentos al distribuidor, y nuevamente, se produce una transferencia de propiedad del token. Una vez que el distribuidor reclama el token, puede canjear $1 del valor que acaba de comprar, y así sucesivamente, hasta el consumidor final.

Cuando el consumidor final recibe la caja de medicamentos, paga $11, y al escanear el código QR con un smartphone, puede canjear $1, que le retorna a él. La aplicación hace dos cosas: primero, permite al consumidor final recuperar su dólar extra, y lo más importante, verifica toda la trazabilidad y se la muestra al cliente. Se le informa al consumidor final que acaba de recuperar el dólar extra, y el número de serie se declara como consumido.

Al final, el consumidor final no puede transferir el token a nadie más, y la persona que acaba de recibir la caja puede ver en su aplicación móvil que se ha verificado toda la cadena de trazabilidad, y esta es una caja real. La idea es que con estos incentivos financieros se vuelve muy difícil hacer trampa, ya que distribuir los medicamentos sin el número de serie asociado se vuelve imposible. Al final de la cadena, las personas pueden ser pobres, pero aún así quieren asegurarse de poder comprobar si el medicamento es legítimo, especialmente si se trata de una condición que pone en riesgo la vida. Esto es lo que yo llamaría trazabilidad activa, donde se tiene un token no fungible (NFT) con un mecanismo financiero superpuesto que da incentivos a todos los participantes para realizar ciertas acciones.

En el caso del ejemplo de medicamentos, cada consumidor final tiene un incentivo financiero para reclamar el número de serie. Sin este incentivo, las personas podrían no declarar la caja como consumida, y medicamentos falsificados podrían ser reintroducidos en la red. Al marcar el número de serie como consumido, nadie puede reutilizarlo. Sin embargo, este enfoque requiere alineación y participación de todos los participantes, y todos los intermediarios tendrán que jugar este juego financiero. Aunque es un caso de uso válido, requiere una coordinación significativa entre muchas partes.

Otra aplicación potencial es incentivar el reciclaje mediante sistemas de reembolso de depósitos. Estos sistemas han existido por mucho tiempo y son más o menos prevalentes dependiendo del país. El fabricante original suele ser el participante mejor posicionado en la red para reutilizar, reciclar o reparar el equipo que se desplaza a lo largo del supply chain. Sin embargo, existe una fricción para implementar estos sistemas, y el desafío es reducir aún más dicha fricción. Blockchain y criptomonedas ofrecen una forma de disminuir la fricción en los micropagos y potencialmente reducir la infraestructura necesaria para garantizar que las operaciones no sean manipuladas.

Por ejemplo, si se devolvieran 20 centavos cada vez que las personas devuelven una botella de vidrio, los adversarios podrían potencialmente gamificar el sistema produciendo botellas falsificadas y cobrando el margen que obtienen al vender las partes recuperadas. Blockchains pueden proporcionar una forma sencilla de mitigar algunas de estas trampas, pero es fundamentalmente algo de naturaleza incremental. No estoy afirmando que los sistemas de reembolso de depósitos sean nuevos; han existido durante mucho tiempo. Se trata simplemente de reducir un poco la fricción para que puedan haber más casos de uso.

Otro caso de uso interesante es la seguridad, ya que las supply chains son vulnerables a los ciberataques. Las supply chains están distribuidas geográficamente por diseño, lo que significa que los sistemas informáticos y dispositivos están esparcidos por todas partes. Por diseño, la superficie de ataque es grande, y es difícil que sea de otra manera. Una supply chain debe estar conectada a clientes, proveedores, socios y proveedores logísticos de terceros, creando una vasta superficie de ataque. Aunque la integración de sistemas, como EDI, puede ser valiosa para realizar pedidos a proveedores y mejorar los tiempos de respuesta, una integración más estrecha también conlleva más problemas de seguridad.

Un ejemplo de esta vulnerabilidad es el incidente de Colonial Pipeline, donde un servicio aparentemente menor relacionado con la facturación fue hackeado, impidiendo que toda la pipeline operara durante una semana y poniendo en peligro la infraestructura crítica en EE.UU. ¿Cómo puede ayudar blockchain en este contexto? Un enfoque sería tener una pequeña cantidad de Bitcoin, valorada en alrededor de $100, en cada sistema y dispositivo, incluso en dispositivos IoT. Al publicitar que todos los sistemas y dispositivos tienen esta reserva, se crea un incentivo para que los hackers intenten penetrar en sus sistemas y robar el dinero.

Sin embargo, esto no es robo; se considera una recompensa para que los hackers penetren en su sistema. Si un hacker logra vulnerar, por ejemplo, un dispositivo IoT, puede reclamar la cantidad de dinero que contiene. Adicionalmente, si se presenta a usted y le explica cómo lo hizo y cómo solucionar el problema, podría pagar una segunda parte de la recompensa, valorada en alrededor de $300 en Bitcoin. Al crear un incentivo, financia el trabajo de hackers éticos que prueban su seguridad. Si solo los actores malintencionados tienen un incentivo para atacar sus sistemas, se descubrirá una brecha con un actor malintencionado, lo cual puede ser muy desagradable, como ocurrió con Colonial Pipeline. Sin embargo, si ofrece un incentivo a hackers honestos y éticos para ingresar a su sistema, lo más probable es que las personas que accedan sean individuos honestos que luego le dirán cómo arreglar su sistema para prevenir problemas futuros. Lo interesante es que estas reservas son públicas, por lo que si las integra en su red, puede monitorear de manera transparente si ha sido vulnerado o no. También puede monitorear externamente todos los dispositivos, incluso si el dispositivo IoT no está conectado a Internet. Si ve que las monedas que estaban dentro de este dispositivo se mueven, significa que de alguna manera este dispositivo fue vulnerado de una forma u otra, y eso es crítico saberlo.

Recuerde que en aquellas brechas de alto perfil que se publicitan, usualmente lo que sucede es que los actores estaban en los sistemas durante meses antes de decidir finalmente reclamar su rescate. Al utilizar este sistema de seguridad basado en blockchain, se crea un mecanismo de alerta temprana. Incluso si hackers poco éticos logran ingresar al sistema, podrían simplemente tomar el dinero y huir, sin pasar por el engorroso proceso de rescate.

Esta es una forma diferente de pensar sobre la seguridad y probablemente no sea el caso de uso que tenía en mente para el blockchain en su supply chain. Pero, como puede ver, los casos de uso interesantes para el supply chain siempre incluyen algún tipo de incentivo monetario, lo cual es muy Bitcoin-esque en cuanto a la forma de abordar el blockchain en relación con los casos de uso en el supply chain.

Ahora, como mencioné, blockchains son muy difíciles de diseñar en comparación con casi cualquier solución alternativa. Se puede esperar que sea al menos dos órdenes de magnitud más difícil desarrollar una solución blockchain. Así que, cada vez que piense que podría resolver un problema dedicando una semana del tiempo de un ingeniero de software, multiplique ese número por 100, y eso le dará una idea del esfuerzo requerido para hacer lo mismo con el blockchain. Hay situaciones en las que tiene sentido; no es porque sea caro que no pueda ser rentable, sino que es fundamentalmente difícil, y debe tenerse en cuenta. Los costos también son mucho más altos cuando se trata de recursos informáticos. Normalmente, el blockchain es muy difícil de escalar, y en comparación con una configuración que no sea blockchain, acaba gastando 100 veces más recursos informáticos para lo que quiera hacer con el blockchain. En algunas situaciones, puede que no le importe, pero en muchas otras, un aumento de 100 veces en el costo de su hardware informático es significativo.

La pregunta es, ¿cómo intentamos alternativas? En casi todas las situaciones donde interviene un blockchain, existe una alternativa que no utiliza blockchain. Típicamente, esto se logra suavizando los requisitos. En términos de valor añadido, si está dispuesto a renunciar a la propiedad de no-repudio que describí al inicio de esta conferencia, puede nombrar un consorcio de algún tipo. Este consorcio utilizará una base de datos de puntos de control, publicará logs que pueden ser verificados por cualquier tercero dentro del consorcio o potencialmente por empresas o entidades que estén fuera del consorcio. Uno de los puntos críticos será tener formatos binarios muy claramente especificados para que sea posible que las partes operen de forma programática. Con ello, obtendrá la mayor parte del valor que de otro modo obtendría de un blockchain.

Un gran ejemplo de supply chain de esto sería GS1 para los códigos de barras. GS1 es una entidad que asigna códigos de barras, y lo ha estado haciendo durante décadas. Esta organización fue creada como una entidad separada, por lo que en ese momento no era IBM directamente quien gestionaba los códigos de barras. GS1 ofrece el valor añadido de un blockchain sin usar realmente un blockchain. Sin embargo, este enfoque requiere una autoridad central o un consorcio en el que se pueda confiar. En muchas industrias que están muy concentradas, como la farmacéutica, establecer un consorcio donde ya exista una cuota de mercado significativa puede no ser demasiado difícil.

Para concluir, el consenso de Satoshi Nakamoto es un descubrimiento impresionante. En 2008, si le hubieran preguntado a expertos en sistemas distribuidos si era posible resolver el problema del consenso bizantino sin recurrir a una autoridad central, la mayoría habría dicho que no, ya que no parecía posible. La idea estaba tan fuera del ámbito de lo que la gente creía posible que ni siquiera miraban en esa dirección. En ese sentido, fue un descubrimiento impresionante. Como presenté con el mini Bitcoin, es una idea muy simple que tiene usos más allá del dinero, siendo éste el caso de uso principal.

Lo que debemos tener en cuenta es que para cada caso de uso de blockchain, típicamente existe una alternativa sin blockchain que es muchísimo más simple de operar. Realmente debemos evaluar si la sobrecarga extra asociada con un blockchain vale todo el lío que conlleva. Como reflexión final, nunca olvide que un blockchain está fundamentalmente entrelazado con su moneda subyacente, y esto genera la madre de todos los conflictos de interés.

En una de mis conferencias anteriores sobre investigación de mercado adversarial, presenté mis opiniones sobre cómo elegir proveedores empresariales y discutí los problemas relacionados con las reseñas. Muchas formas intuitivas de abordar estos problemas se ven socavadas debido a conflictos de interés. Con blockchains y criptomonedas, el problema es mil veces peor. Todos tienen incentivos masivos si poseen Bitcoin, Bitcoin Cash, eCash u otras criptomonedas. Tendrán un sesgo significativo debido a sus inversiones, y si su empresa toma una dirección favorable a un blockchain específico, también podría ser favorable para sus inversiones.

No tengo una buena solución para este problema, pero aconsejo estar consciente y preparado. La mayor parte de la información encontrada en línea sobre criptomonedas es poco confiable, ya que muchas personas tienen un conflicto de interés al promover su moneda preferida. No confíe en nadie, excepto en colegas en quienes confíe con su vida. Dependa de su propio juicio o del juicio de colegas que entiendan lo que ocurre. Los conflictos de interés con blockchains conducen a comportamientos inesperados, especialmente en el supply chain, donde típicamente hay relaciones duraderas y un alto grado de confianza presente.

Las organizaciones que operan grandes supply chains pueden no estar preparadas para el nivel de desconfianza que se encuentra en el ámbito de las criptomonedas. Esto concluye la conferencia. Veamos las preguntas.

Pregunta: Blockchain y Bitcoin no son lo mismo; uno es único mientras que el otro es una tecnología básica.

Sí, la semántica y la terminología son importantes. Sabía cuando estaba haciendo esta conferencia que habría personas que señalarían que no son exactamente lo mismo. Sin embargo, si se quiere examinar un blockchain puro en el sentido técnico, entonces un repositorio Git, como GitHub, es un blockchain. Los repositorios Git han existido durante unos 15 años, y no han vuelto loco al mundo. No hay miles de millones de euros y dólares fluyendo dentro y fuera de estos repositorios Git.

La cuestión es que el blockchain solo funciona en términos del valor añadido que crea. Lo que diferencia a Bitcoin de Git, a pesar de que ambos son blockchains, es que Bitcoin tiene incentivos financieros incorporados que desbloquean ciertos aspectos de la tecnología. Ese es el truco. Si se eliminan todos los aspectos monetarios e incentivos que se han diseñado, entonces se tiene algo que es solo una estructura de datos técnica, pero que no tiene ningún interés. Sí, es una buena estructura de datos – Git es una buena estructura de datos – pero no volvió loco al mercado, y ciertamente las personas no se volverían locas diciendo, “Oh, este repositorio Git vale miles de millones.” Hay algo diferente. Dejando de lado las minucias de la terminología, creo que la razón principal por la que muchas empresas optaron por la terminología blockchain fue para introducir cierta distinción en el discurso respecto a aquellas criptomonedas que se veían como el completo salvaje oeste.

Pregunta: Blockchain es la tecnología que permite el consenso descentralizado pero con un costo – retraso, escalabilidad, etc., y contaminación.

Absolutamente. Por cierto, también puedo abordar el caso de uso de la contaminación. La cuestión es que cada vez que se tiene un proceso de emisión de dinero, sin importar cómo se emita el dinero – ya sea el banco central para el euro, la Fed para el dólar, o lo que sea – si los actores económicos pueden invertir para beneficiarse de esta emisión de dinero, invertirán hasta el costo marginal. Así que, si el banco central imprime 100 y puedo invertir 90 para recuperar esos 100, lo haré.

No importa cómo se tenga un proceso de emisión de dinero, la gente va a gastar hasta el costo marginal para igualar la utilidad. Resultó que, debido a que Bitcoin Core ha estado inflándose en valor, la gente está dispuesta a pagar mucho en términos de electricidad para adquirir esos Bitcoins recién acuñados. Sin embargo, el proceso está disminuyendo exponencialmente, lo que significa que dentro de unas pocas décadas, la cantidad de Bitcoins recién acuñados se reducirá a casi nada, y por lo tanto la cantidad que la gente estará dispuesta a pagar por la prueba de trabajo será casi nula. Este es un problema transitorio, y en este momento se está utilizando principalmente la capacidad eléctrica sobrante no utilizada.

Estoy de acuerdo con su conclusión; le proporciona consenso descentralizado desde la perspectiva del consenso bizantino, y sí, existen sobrecostes masivos asociados. Absolutamente, esta es la conclusión correcta.

Pregunta: ¿Por qué utilizarlo en la industria del supply chain? ¿Qué resuelve el paradigma descentralizado? ¿Qué problema trae?

Presenté varios casos de uso en mi conferencia. Tener descentralización le exime de la necesidad de diseñar un consorcio. El problema es que si cuenta con una autoridad central en la que confíe y esta autoridad es honesta, entonces bien – no necesita un blockchain. El truco es, ¿qué hace cuando no tiene eso?

Incluso en áreas que tenían autoridades centrales, como por ejemplo las transferencias bancarias para pagos, están bajo el control de autoridades centrales – existen guardianes que son los bancos y luego los bancos centrales. No estamos, diría, en desabastecimiento de autoridades centrales, pero no obstante, en 2021, liquidar un pago con mis clientes en el extranjero aún toma dos semanas. Este es el siglo XXI; puedo enviar un correo electrónico, y es recibido en cuestión de segundos por esos clientes, pero enviar una transferencia bancaria toma semanas. Así que, obviamente, hay algunos problemas que a veces son muy difíciles de resolver, porque quizá el problema no es que no tengas autoridades centrales, sino que tienes demasiadas autoridades centrales, o tienes problemas complejos en los que no se puede reunir a la gente para encontrar una solución.

He descrito algunos casos de uso, por ejemplo, la trazabilidad activa, en la que operas en un país pobre donde todos los intermediarios son corruptos. Este es otro problema en el que no se puede confiar en nadie. Cuando existe una corrupción epidémica, estos problemas son muy difíciles de abordar. Esa es una situación en la que la blockchain descentralizada puede ofrecerte una forma de diseñar la honestidad de los participantes. Ese es el truco: no se espera que los participantes sean honestos; se les diseña para que se mantengan honestos mientras operan la supply chain.

Pregunta: ¿Cómo se enfrenta a la existencia de ASICs (Circuitos Integrados de Aplicación Específica) hardware especializado en minería y granjas para asegurar que nadie pueda tener fácilmente el 51% del poder de las redes?

Históricamente, los ASICs han sido una fuerza positiva para la seguridad de la red Bitcoin Core. ¿Por qué es así? Porque hay otro problema en el panorama moderno: las botnets. Las botnets son vastas flotas de computadoras comprometidas controladas por organizaciones criminales que literalmente toman el control de millones de dispositivos cotidianos, como computadoras, impresoras y cámaras de seguridad. Estas organizaciones no quieren impedirte usar tu dispositivo, ya que eso llevaría a reparaciones y a la eliminación del malware.

En términos de seguridad, el panorama en el que nos encontramos es que las organizaciones criminales tienen a su disposición, literalmente, decenas de millones de computadoras de forma gratuita. Estas organizaciones que operan botnets, si observas las actualizaciones de seguridad de Microsoft, verás que un par de veces al año, Microsoft ha eliminado botnets absolutamente masivas en el pasado. Ellos comunicaban, por ejemplo, “Hemos lanzado esta actualización de Windows, y por cierto, acabamos de eliminar esta botnet de 50 millones de máquinas.” Eso es impresionante. Entonces, los ASICs significan que no tiene sentido jugar este juego con hardware común, como el de tus computadoras habituales. Así, los criminales que operan botnets no pueden utilizar esas botnets para minar criptomonedas, lo que elimina un ángulo para monetizar esas botnets. Obliga a los mineros a comprometerse con la moneda.

You see, ASICs are not a problem; they are, on the contrary, the sort of solution that makes sure that this extra processing power doesn’t wreak havoc or leverage the sort of processing power that is available through botnets. Botnets are already a massive problem for everybody, and we don’t want to further empower those botnets.

Pregunta: ¿Cuáles son tus opiniones sobre la Telegram Open Network que no pudo ver la luz debido a los tribunales de EE. UU.? ¿Qué opinas, en general, sobre las criptomonedas emitidas por mensajeros? ¿Aportan algo nuevo?

Bueno, creo que la situación es muy predecible para Telegram y lo mismo para Facebook, y para cualquier empresa que quiera operar como empresa pública. Existen regulaciones generales que indican que, si eres una empresa, hay requisitos KYC (Conoce a tu cliente), y no voy a profundizar demasiado en los detalles. Básicamente, si eres una empresa grande, puedes esperar que en muchas jurisdicciones existan requisitos KYC. No estoy aquí para discutir si las regulaciones son adecuadas o no; solo digo que las regulaciones KYC son prevalentes en muchos países.

Si vuelves a lo que hace que una blockchain sea una blockchain, como describí en la lista de requisitos, el punto número dos es que los participantes son anónimos. Así que, ahí están los requisitos KYC. Si quieres operar una blockchain, debes estar de acuerdo en preservar algún tipo de pseudo-anonimato de quienes participan en esta red, lo que significa que, en términos de requisitos KYC, estás completamente descartado.

No estaba muy seguro de lo que esas empresas estaban pensando, pero no puedo ver una empresa que quiera ser tanto pública como responder a autoridades como la SEC en EE. UU. o la AMF en Francia, mientras que pueda participar en un esquema que obviamente va completamente en contra de las regulaciones KYC, tan prevalentes en las grandes empresas. Mi opinión es que, fundamentalmente, probablemente estaban tanteando el terreno para ver si quizá los reguladores relajarían las normativas solo para ellos, simplemente porque eran grandes. Puede que no les haya salido como esperaban, y por ello se están retractando de ello. Fundamentalmente, aparte de eso, creo que, por ejemplo, Telegram o Facebook, si aceptaran que solo promoverían una criptomoneda pero no la operarían, en realidad podrían dar un impulso masivo a esa criptomoneda. Sin embargo, el problema es que, al solo estar promoviendo y no operando, ganarían poco para sí mismos, salvo que hubieran diseñado un conflicto de intereses en el que se beneficien del crecimiento de la moneda. Por cierto, Elon Musk, te estoy mirando cuando empieces a tuitear sobre Bitcoin y el hecho de que tu empresa tiene una posición al respecto. Este es, literalmente, el juego que se puede jugar: primero adquieres una participación en una criptomoneda y luego, literalmente, bombeas esta criptomoneda haciendo declaraciones muy visibles sobre ella. Dejas que la valoración suba y, una vez que es mayor, la vendes. Por cierto, a este proceso se le llama pump and dump. Probablemente, Telegram y Facebook se dieron cuenta de que la única forma en que realmente podían beneficiarse solo promoviendo una moneda, pero sin operarla, era a través de pump and dumps, y no querían que su reputación se viese dañada por hacer este tipo de travesuras.

Pregunta: Hace siete años, vi muchas startups llevando la tecnología blockchain a campos relacionados con la supply chain. Ninguna de ellas tuvo éxito, al menos a escala. ¿Conoces alguna que haya tenido éxito y demostrado funcionar a escala?

Buena pregunta. Quiero decir, primero, no creo que nadie en el planeta tenga una blockchain que sea comprobablemente escalable y que realmente funcione a escala. Si miramos el experimento de Bitcoin Core, no está yendo bien. La red está completamente saturada; ha estado saturada durante cuatro años. Esto es realmente lo opuesto a la escalabilidad. Si miras Bitcoin Cash, esa es otra blockchain. Hicieron algunos avances, pero nunca tuvieron realmente tiempo; surgieron algunas disensiones internas, y por ello nunca completaron todos los aspectos finales en términos de ingeniería para hacerla funcionar. Existe otro fork recién creado llamado eCash, que es básicamente un fork de Bitcoin Cash, en el que nuevamente están tratando de hacer todas las cosas que no se hicieron en el cliente original de Satoshi, ya que la mayor parte de los problemas de escalabilidad se pueden rastrear hasta ese cliente original. Hay cierta esperanza de que puedan lograr una escalabilidad masiva, pero, de nuevo, esto es más una perspectiva teórica. Esto no está probado en el sentido de que exista algo que, en la actualidad, funcione a hiperescalas, aunque tenemos razones para creer que es, hasta cierto punto, posible. He publicado al respecto, por cierto, si quieres ver mi publicación sobre bloques de tamaño terabyte para Bitcoin.

Ahora, no hay nadie que haya logrado llevar ese tipo de cosas a escala. Es muy difícil. Escalar la capa base es el primer desafío y, luego, obviamente, las startups que quieren hacerlo para supply chain pretenden hacer algo aún más avanzado. Necesitan tener una capa base que pueda escalar, y luego quieren hacer algo que sea supply chain a escala también. Creo que ninguna ha tenido éxito, porque, como estaba describiendo, sí existen casos de uso para supply chain, y sí, hay cierto margen para un valor añadido, pero primero hay que resolver esos problemas tan difíciles de escalabilidad y latencia. Puede que no les haya salido como esperaban, y puedes observar que los documentos que cité no son tan antiguos. Quiero decir, los documentos sobre Avalanche tienen literalmente solo unos pocos años. Ha habido algunos avances que aún son bastante recientes, y tomará mucho tiempo. Para poder escalar, hay que lograr avances a nivel de algoritmia teórica, lo cual es muy difícil de conseguir.

Los algoritmos que describí, como Avalanche, son increíblemente difíciles de implementar correctamente. Hay muchos detalles en los que se puede fallar, y en términos de blockchain, si algo sale mal, significará que serás vulnerado, atacado y se perderá dinero. La gravedad de tener errores y problemas al operar en el mundo de la blockchain es muy alta. Esto no es como el software empresarial común, donde, si se bloquea, puedes reiniciarlo, corregir manualmente los datos afectados y continuar a partir de ahí. Con las blockchains, una vez que hay una corrupción masiva, el daño puede ser permanente, y ese es un entorno muy complicado en el que operar.

Creo que muchas de las startups que incursionaron en este campo estaban absolutamente despreparadas en términos de la mentalidad de ingeniería requerida para enfrentar los desafíos de operar en el ámbito de la blockchain. Una buena ingeniería no es suficiente; necesitas una ingeniería realmente excelente para tener éxito.

Esto concluye la sección de preguntas y respuestas de esta conferencia. La próxima conferencia será sobre optimización matemática para supply chain y se llevará a cabo el miércoles 25 de agosto. Me tomaré unos días de vacaciones. Por cierto, la optimización matemática, a diferencia de blockchain, se utiliza a diario en muchas supply chains. Las aplicaciones son enormes y los casos de uso son muy prácticos. No estamos hablando de casos de uso de nicho; las aplicaciones son masivas.

La optimización matemática está muy relacionada con el aprendizaje estadístico y con tomar las mejores decisiones de supply chain. Nos vemos la próxima vez.