00:00 Introducción
02:01 Resolviendo el consenso bizantino
09:35 Requisitos estrictos de una blockchain libre
20:31 La historia hasta ahora
22:44 Enriqueciéndose rápidamente hoy
24:03 Mini Bitcoin 1/3 - Hashing y Firma
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 aplicativo
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 Potenciando 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 desenfrenados. Desde una perspectiva corporativa, la “blockchain” es el eufemismo cortés utilizado para introducir ideas y tecnologías similares mientras se establece una distanciación con esas criptomonedas. Existen casos de uso de supply chain para la 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 para Supply Chain”. Las criptomonedas capturaron la imaginación del público, se hicieron y se perdieron fortunas, algunos villanos han sido atrapados y encarcelados, y seguirán más. En medio de toda esta agitación, el término criptomoneda se volvió un poco demasiado cargado para las grandes empresas promedio que tienden a ser bastante conservadoras. Por lo tanto, se adoptó el término blockchain como una forma de distanciar la innovación de toda la locura que ocurre en el mundo cripto. Sin embargo, fundamentalmente, las blockchains y las criptomonedas son una y la misma cosa.
El objetivo de esta conferencia es obtener una comprensión técnica, una comprensión técnica en profundidad, de lo que está sucediendo con las blockchains. Si tienes algunas habilidades de programación, al final de esta conferencia, deberías poder volver a implementar tu propia blockchain de juguete si lo deseas. Basándonos en esta nueva comprensión técnica de la blockchain, comenzaremos a revisar los casos de uso de supply chain y evaluaremos su viabilidad como tecnologías para resolver problemas y su valor agregado en términos de lo que pueden hacer por las supply chains. Comencemos.
El origen de Bitcoin es simplemente extraño. En 2008, bajo un seudónimo, Satoshi Nakamoto, que probablemente es un esfuerzo de equipo, se publicó un documento técnico llamado “Bitcoin: un sistema de efectivo electrónico de igual a igual”. Este documento presenta un sistema y 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 de la potencia de hash está del lado bueno. Sin embargo, se demostró más tarde en un documento posterior publicado en 2013, “La mayoría no es suficiente: la minería de Bitcoin es vulnerable”, que para mantener la red segura, no necesitas que la mitad de la potencia de hash sea honesta; en realidad necesitas dos tercios más de la potencia de hash.
Sin embargo, hay un documento técnico y un software. El software es de código abierto, y es una implementación de muy baja calidad. El cliente Satoshi es de muy baja calidad, y durante el primer año después de la publicación del software, los contribuyentes de código abierto estaban arreglando apresuradamente toneladas de errores y problemas. 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 son bifurcaciones del cliente original de Satoshi y, en cierta medida, aún llevan muchos de los problemas que no se pudieron solucionar a lo largo de los años.
Por lo tanto, esta es una situación muy desconcertante donde tienes un documento que no es de la mejor calidad y un software que es de muy baja calidad, y sin embargo, el equipo de Satoshi Nakamoto hizo un descubrimiento asombroso. Fundamentalmente, el problema se conocía como el problema del consenso bizantino. Es un problema de computación distribuida. Imagina que tienes participantes, y todos esos participantes pueden ver cuál 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, cambiar algunos bits, agregar 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 hacer 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 todos los demás participantes. El asombroso descubrimiento de Bitcoin es que si volvemos a 2008 y preguntamos a los expertos, probablemente habrían dicho que no parece posible resolver el problema del consenso bizantino de una manera completamente descentralizada sin una autoridad central. Sin embargo, el descubrimiento de Satoshi Nakamoto, el consenso de Nakamoto, es que encontraron una forma 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 agregando 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, dando a los participantes incentivos para actuar de cierta manera.
Si queremos tener esos incentivos 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, tienes al menos dos problemas muy difíciles. El primer problema es el gasto doble. Si tienes una cierta cantidad de dinero digital representada 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 algo más? Este problema se conoce como gasto doble, y es uno de los problemas muy difíciles que Bitcoin aborda.
El segundo problema es la emisión de monedas. ¿De dónde viene este dinero? Lo interesante es que normalmente, cuando tienes un problema muy difícil que quieres abordar, adoptas un enfoque de dividir y conquistar, subdividiendo tu gran problema en subproblemas que son más simples y pueden resolverse por separado. Luego, se puede resolver el problema total. Lo interesante con Bitcoin es que hay dos problemas distintos y muy difíciles: el gasto doble y la emisión de monedas. En lugar de usar un enfoque de dividir y conquistar, 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 sobre lo que hace que una moneda digital sea una buena moneda, ya que eso merecería una charla propia. Sin embargo, las blockchains no operan sin los incentivos financieros diseñados a través de las monedas digitales que soportan la propia blockchain. Cuando decimos que la criptomoneda y las blockchains son muy parecidas, la idea es que si quieres tener una blockchain, transmitirás mensajes, y esos mensajes serán transacciones con un flujo de dinero involucrado. La perspectiva de la criptomoneda es que el enfoque principal está en el aspecto monetario, mientras que la perspectiva de la blockchain está más interesada en los metadatos que se superponen a las transacciones.
Recuerda que todo el modelo de seguridad de estos sistemas de blockchain/criptomoneda se basa en los incentivos económicos diseñados en el sistema. No puedes separar completamente los objetivos económicos y de criptomoneda de la blockchain. Es solo una cuestión de perspectiva.
Ahora, echemos un vistazo rápido a los requisitos que vienen con un sistema de blockchain/criptomoneda, y cómo podemos relajar potencialmente esos requisitos. El primero es la no negación. La no negación significa que como participante, nadie puede impedirte transmitir una transacción. Nadie puede impedir que ocurra una transacción válida. Esto es muy importante, ya que si hay un participante capaz de hacer eso, entonces esencialmente tienes una autoridad central. A la inversa, ningún participante puede impedir que ocurra una transacción válida, pero tampoco hay ningún participante que pueda negarte la posibilidad de realizar una transacción porque pueden 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 pseudo-anónima, pero fundamentalmente, cuando digo el requisito anónimo, significa que no hay una lista de participantes. En una verdadera blockchain, los participantes pueden aparecer o abandonar el sistema en cualquier momento, sin un guardián. Como los participantes pueden unirse o salir libremente, no hay nadie rastreando su identidad. No significa que tenga que ser anónimo; solo significa que si tienes una verdadera blockchain canónica, el requisito de anonimato, donde los participantes pueden unirse y abandonar como deseen, necesita ser cumplido.
Luego, estoy listando la escalabilidad masiva como un requisito, que es particularmente difícil para las blockchains porque, como veremos, estos tipos 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 dejas 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 saturar toda la red. Por lo tanto, todas las blockchains tienen que lidiar con este problema de escalabilidad, que se resuelve mediante incentivos financieros de ingeniería.
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 aún es de muy bajo costo. Entonces, si tienes un uso regular y quieres tener una transacción asociada con, por ejemplo, el movimiento de un producto en un almacén, está bien; el costo sigue siendo muy bajo. Sin embargo, al tener 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, que son muy fáciles de hacer si no tienes tarifas. Cada transacción tiene que pagar una tarifa por su existencia y para apoyar su transmisión; de lo contrario, un atacante podría inundar el sistema distribuido sin obstáculos.
Entonces, las tarifas de transacción son otro ángulo en términos de ingeniería económica para mantener la blockchain viable. Quieres poder mantener esta tarifa de 0.1 centavo a cualquier escala porque otro problema de negar 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 en la que tengamos un autobús con 100 personas que quieren tomarlo en un cierto momento, pero solo hay 50 asientos. Si esto sucede, entonces habrá algún tipo de mecanismo de subasta en marcha, 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 de Bitcoin Core, es muy frecuente que el costo de una transacción supere los diez dólares, y este es un problema muy grande.
Ahora, también queremos tener una latencia bastante baja. Lo que Satoshi Nakamoto descubrió en 2008, el consenso de 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, se tarda aproximadamente una hora. No es dramáticamente lento, pero tampoco es muy rápido. Si queremos hacer algo relacionado con la supply chain, donde queremos hacer pagos o rastrear el movimiento de bienes, sería mucho mejor si podemos mantener la latencia del sistema en algo como tres segundos o menos, la misma clase 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 digo la infraestructura de software que soporta la blockchain o criptomoneda, debe ser un bien público que se financia con algún tipo de contrato social acordado. Eso es algo que creo que Satoshi Nakamoto no previó en 2008. Si quieres operar un sistema distribuido mundial 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 intentan confundir a otros participantes sobre el estado de la red, sino que también surgen como adversarios que se apoderarán del código base y harán cosas con la infraestructura de software que antagonizan los intereses de la comunidad en general. Ha ocurrido en la historia de las criptomonedas tener tomas de control hostiles de un equipo a otro, con los nuevos equipos teniendo intereses que están completamente desalineados con los intereses de la comunidad en general. Esta es una clase de ataques, más de un tipo de ingeniería social, que no fueron claramente vistos por Satoshi Nakamoto en 2008. Sin embargo, después de una década de operación, estos tipos de ataques son ahora mucho más claros 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 la 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 las 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 hay conflictos de interés en juego. Por cierto, muchos de los aspectos en el segundo capítulo, donde trato con conflictos de interés, son muy relevantes para la conferencia de hoy, por lo que invito a la audiencia, si aún no han visto las conferencias del segundo capítulo, a echar un vistazo a eso. El tercer capítulo está dedicado a problemas de supply chain, que son literalmente conferencias donde me enfoco 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 apoyan las prácticas modernas de supply chain. Al igual que esperarías que un médico moderno tuviera algunos conocimientos sobre química, no tienes que ser un químico brillante para ser un médico brillante. El acuerdo general sería que, desde una perspectiva moderna sobre la ciencia médica, si no sabes nada sobre química, no puedes ser un buen médico según los estándares modernos. Lo mismo es cierto para la supply chain, en mi perspectiva. Hay una serie de ciencias auxiliares donde necesitas tener algunos antecedentes sobre esos temas si quieres tener una práctica de supply chain razonablemente moderna.
Ahora, para la conferencia de hoy, presentaré primero Mini Bitcoin, que es una implementación de blockchain de juguete. Debería arrojar luz sobre cómo funcionan las criptomonedas y cuál fue el descubrimiento clave de Satoshi Nakamoto en 2008. También debería aclarar los tres grandes desafíos que enfrentamos al diseñar blockchains, que son la escalabilidad, la latencia y la 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 limitan esencialmente 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 donde, en diferentes grados, la supply chain tiene algo que aportar a la mesa.
El objetivo de Mini Bitcoin es construir un blockchain de juguete, una versión simplista de Bitcoin desde cero. No prestaremos demasiada atención a todas las tecnicidades involucradas porque, en la vida real, diseñar un blockchain es un trabajo que requiere prestar atención a toneladas de detalles. Aquí, solo quiero presentar la estructura general para mantenerla dramáticamente simplificada en comparación con la realidad, para que podamos entender en unas pocas diapositivas qué está pasando, cómo se está diseñando y cómo funciona.
En este ejemplo muy simple, vamos a diseñar una moneda donde cada moneda vale exactamente un bitcoin. Tienes un conjunto de monedas, cada moneda vale exactamente un bitcoin, y lo único que puedes hacer es transferir una moneda de un participante. Si un participante posee muchas monedas, puede transferir todas las monedas, pero solo estamos mirando una moneda muy simple donde no tenemos cantidades fraccionales y otros elementos.
Para construir este Mini Bitcoin, solo necesitamos tres funciones especiales: una función de hash, una función de firma y una función de verificación. Estas funciones ya eran estándar en 2008, por lo 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 funciones de trampa, 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.
Tenemos estas tres funciones: la función de hash, de la cual no entraré en detalles aquí, pero he discutido 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 ser, en la práctica, invertida. Si tienes un resumen, la única forma de identificar un mensaje que produce el resumen es conocer el mensaje de antemano.
La función de firma puede tomar un mensaje, una clave 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 donde tienes pares de claves públicas y privadas. Con la clave privada, puedes producir una firma y publicar un mensaje sin revelar tu clave privada. Cualquier participante puede usar la función de verificación para tomar el mensaje, tu firma y tu clave pública para verificar que el mensaje ha sido firmado por la clave privada asociada con esta clave pública.
Estas funciones de trampa no pueden ser invertidas, por lo que si no conoces el mensaje original, no puedes retroceder desde la función de hash, desde el resumen al mensaje original. Lo mismo se aplica si no tienes la clave privada; no puedes producir una firma por tu cuenta si tienes un nuevo mensaje.
Estas tres funciones especiales están disponibles en esencia en 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, veamos 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, hay un acuerdo compartido entre todos los participantes para esta mini red de Bitcoin que, como parte de los UTXO (Unspent Transaction Outputs), esta moneda está realmente presente. Cuando digo esta moneda, me refiero a un mensaje que incluye la clave pública número uno y la firma cero. Solo asumo que esto es parte de un conjunto de monedas y 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 la propiedad de esta moneda a otra persona?
La forma en que hago eso es produciendo una firma. La firma se construye de la siguiente manera: estoy usando la función especial de “firma” y voy a firmar un mensaje. Este mensaje solo va a ser la clave pública número uno, la firma cero y luego la clave pública número dos. La clave pública número dos es literalmente la dirección a la que estoy enviando el dinero. Quien sea que posea la clave privada asociada con esta clave pública número dos va a ser el destinatario de mi transacción. Entonces, firmo esta transacción y, para firmarla, estoy usando la clave privada número uno. El único participante que puede producir esta firma número uno es la persona que tiene el secreto, la clave privada número uno, asociada con la clave pública número uno.
Si quiero que toda la red sepa que se ha realizado esta transacción, necesito transmitir una transacción. La transacción solo va a ser un mensaje que enumera la clave pública número uno, la firma cero, la clave pública número dos y la firma uno que acabo de producir. Es solo una lista de los elementos que contribuyen a la transacción. Cuando publico esta transacción de uno a dos, esencialmente, la moneda número uno sale del grupo de monedas y la moneda número dos entra al grupo de monedas como parte del sistema. Por eso es crucial tener este consenso bizantino en juego. 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, hay un acuerdo firme sobre las monedas que realmente pertenecen al sistema. Una vez que se gasta una moneda, el propietario número dos ahora tiene una moneda. Una moneda puede salir de la red y se crea una nueva moneda que entra al estado del sistema.
El mecanismo puede repetirse; la moneda número dos puede enviarse a la moneda número tres utilizando el mismo sistema: producir una firma, transmitir una transacción, y así sucesivamente.
Por cierto, siempre que dije que se está utilizando la función “sign”, implícitamente, significa que todos los observadores pueden usar la función “verify” para verificar 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 anteriormente para verificar que la transacción es efectivamente correcta. Hay dos verificaciones involucradas: cada participante tiene que verificar que la moneda que se está transfiriendo ya era parte del estado del sistema, asegurándose de que es una moneda válida, y que la transacción es válida de acuerdo con la firma. Lo que no he abordado aquí es el problema del doble gasto. ¿Cómo prevenimos que se realicen dos transacciones en conflicto al mismo tiempo y cómo prevenimos que la red se confunda si un adversario intenta transmitir dos transacciones en conflicto 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 esencia del descubrimiento de Satoshi Nakamoto y su Consenso de Nakamoto es resolver estos dos problemas a la vez.
La propuesta de Satoshi Nakamoto es introducir una clase especial de participantes en la red, hoy en día apodados “mineros”.
Los mineros esencialmente escuchan la red y recogen todas las transacciones que se han transmitido. Recogen estas transacciones transmitidas y las ponen en un contenedor llamado “bloque”. Un bloque es simplemente una colección de transacciones transmitidas por cualquier persona en la red peer-to-peer.
La primera transacción de un bloque va a ser una transacción especial llamada “coinbase”. Un coinbase es una transacción única que crea una nueva moneda en esta mini configuración de Bitcoin de la nada. La primera transacción es el coinbase, creando una nueva moneda de la nada, y luego en el bloque sigue la lista de transacciones que se han transmitido, según lo percibido por el minero. El minero puede no ser capaz de capturar todas las transacciones de la red Bitcoin, pero intentan hacerlo.
El coinbase es especial, y explicaré cómo construir este coinbase porque es una transacción única. Primero, vamos a producir un hash del bloque, un hash parcial (H1a). Este hash es esencialmente un hash de un mensaje, y este mensaje comienza con un hash del bloque anterior (H0b), concatenado con todas las transacciones presentes en el bloque.
El 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 minero y tiene su importancia. El coinbase también contiene la clave pública del minero. El coinbase incluye un hash de todo el contenido del bloque. El coinbase contiene un número aleatorio y la clave pública del minero. Esta clave pública será utilizada por el minero más adelante para reclamar el coinbase como una moneda regular. En esta mini configuración de Bitcoin, las monedas se emiten a una tasa de un Bitcoin por bloque. En realidad, en la red de Bitcoin Core o Bitcoin Cash, el proceso es más complicado, pero la mayoría de la complejidad puede ser simplificada para mayor claridad.
La idea es que para que el bloque sea considerado válido, necesitamos producir un coinbase. Sin embargo, si nos detenemos en este punto, todos los mineros podrían afirmar que tienen un bloque cuando quieran, y todos los mineros tendrían interés en decir, “Puedo producir un paquete, un resumen de todas esas transacciones. Puedo producir un coinbase. Por favor, dame este Bitcoin extra”. ¿Cómo ordenamos a todos los mineros compitiendo para que su versión del bloque sea seleccionada por la red y considerada el único bloque verdadero?
Satoshi Nakamoto introdujo el concepto de prueba de trabajo. El hash del coinbase, que es un número grande de 256 bits, tiene que estar por encima de un umbral de dificultad. Este proceso es como resolver un rompecabezas, y la única forma de resolver este rompecabezas es descubrir un coinbase que tenga un hash que cumpla con este objetivo de dificultad. El minero puede intentar muchos números aleatorios para el nonce con la esperanza de ser el primero en alcanzar la dificultad y reclamar el bloque para sí mismo.
En Bitcoin, la dificultad es adaptable, y la red utiliza un algoritmo de media móvil glorificado para mantener la dificultad alrededor de 10 minutos por bloque. Si los bloques se encuentran en promedio a un ritmo más rápido que 10 minutos, la dificultad aumentará hasta que los bloques se encuentren cada 10 minutos en promedio. Si los bloques comienzan a encontrarse cada 11 minutos, la dificultad disminuirá para mantener el tiempo promedio para encontrar un bloque en 10 minutos.
La propuesta de Satoshi Nakamoto es que los mineros siempre sigan 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 lo construyes encima de un bloque preexistente, excepto para el bloque de génesis, que es el punto de partida predeterminado. La regla no es solo tener la cadena más larga, sino la cadena válida más larga. Otros mineros verificarán que todas las transacciones enumeradas en un bloque son de hecho válidas, asegurando que las firmas coinciden y las monedas que se gastan son elegibles para ser gastadas. Mantienen este estado, y eso es exactamente cómo 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 quieres construir una blockchain de grado de producción real, hay toneladas de cosas extra a considerar. Primero, te gustaría tener cantidades fraccionales. Probablemente no quieras poder tener solo un Bitcoin a la vez; quieres algo donde puedas transferir múltiples o cantidades fraccionales de Bitcoins.
En términos de monedas, te gustaría tener transacciones que puedan consumir muchas monedas como entradas a la vez y luego producir muchas monedas a la vez. No van a ser transacciones uno a uno que conecten una moneda con una moneda; van a ser transacciones de muchos a muchos, con muchas monedas de entrada conectando con muchas monedas de salida. Por cierto, así es como operan varias redes de Bitcoin hoy en día.
También tienes las tarifas de transacción que mencioné. Si dejas que las personas transmitan transacciones sin cesar, podrían enviar dinero de un lado a otro entre las mismas direcciones e inundar el mercado. La idea es que una tarifa es fundamentalmente la noción de que una cierta porción de la transacción se redirige al minero. La forma en que se hace típicamente en la mayoría de las variantes de Bitcoin es decir que la entrada total debería ser, en términos de valor monetario, ligeramente mayor que la salida total. La fracción de valor que falta, la brecha, es la recompensa que se paga al minero.
Ahora hemos completado nuestro mini Bitcoin. Si sabes cómo programar, tienes todos los elementos que necesitas 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 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 documento técnico de 2018, publiqué un panorama aplicativo de Bitcoin. La idea es que, dependiendo de la cantidad de datos en los que tus blockchains están involucrados, la cantidad de datos que tienes que procesar y mover varía enormemente dependiendo de 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 entender el hecho de que, dependiendo de lo que estés haciendo, la cantidad de recursos informáticos que tendrás que inyectar para hacer el trabajo varía en 10 órdenes de magnitud. Un 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 en cadena y fuera de la cadena. Las aplicaciones fuera de la cadena son aquellas que solo tratan con los datos generados por ti o tus socios cercanos. Si eres una gran empresa, es posible que tengas que lidiar con millones de transacciones, pero estas son solo tus propias transacciones. En términos de datos, puede ser grande, pero es manejable ya que se relaciona directamente con tu propio negocio.
Por otro lado, las aplicaciones en cadena tratan con todas las transacciones transmitidas por la red. Esto puede ser mucho más grande, especialmente si eres un pequeño jugador y necesitas manejar 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 “engranajes de efectivo” y “tierras de efectivo”. Los engranajes de efectivo 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. Las tierras de efectivo, 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 funcione.
Típicamente, cuando pensamos en casos de uso de supply chain, nos posicionamos con metadatos en el reino de las tierras de efectivo. 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, tienes que 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 de supply chain. Sin embargo, las blockchains son poco escalables, como lo demuestra el hecho de que los mineros tienen que lidiar 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 enorme volumen de transacciones que se ve típicamente en las aplicaciones de supply chain. Si quieres que una blockchain se utilice para fines de supply chain, debe ser capaz de manejar no solo las transacciones de una sola empresa sino también todas las empresas que participan en la iniciativa de blockchain. Eso puede llegar a ser extremadamente grande, o en realidad muy grande, tal vez excesivamente. Eso es lo que tenemos que ver, y aquí, al rescate, ha habido esencialmente dos documentos notables. Cuando Satoshi Nakamoto publicó su documento, dijo que con el progreso del hardware, este problema se resolvería, y escalaríamos tanto como fuera necesario. Esto sucedería. Sin embargo, resultó ser difícil, y durante más de una década, prácticamente todos los jugadores en este espacio de blockchain y criptomonedas han estado luchando cuando se trata de escalabilidad.
El primer documento notable es ECMH, Elliptic Curve Multiset Hash. Es un documento bastante técnico, pero la idea clave es que no tienes que mantener todas las transacciones; solo tienes que mantener las monedas que están listas para gastar. Esta colección de monedas que se pueden gastar se conoce técnicamente en el ecosistema de Bitcoin como el UTXO. Solo como un orden de magnitud, el UTXO de la red Bitcoin Core es actualmente ligeramente inferior a cinco gigabytes. Este es el tamaño del conjunto de datos de UTXO, pero si miras la blockchain de Bitcoin Core, el tamaño de la blockchain es ligeramente inferior a 350 gigabytes, y la blockchain está creciendo mucho más rápido que el UTXO.
Lo que el documento ECMH te proporciona es una función hash que tiene afinidad con los multiconjuntos. Esencialmente, es una función hash donde puedes actualizar tu hash si agregas o eliminas elementos a tu colección. No conservas el conjunto o el multiconjunto en sí, sino que solo conservas el hash, y puedes agregar o eliminar elementos. Esta propiedad de tipo conjunto significa que puedes hacer esas adiciones o eliminaciones en cualquier orden y aún así llegar al mismo hash. Lo que puedes obtener a través de ECMH es una forma de tener un compromiso de UTXO, lo que permite a la comunidad alejarse de la blockchain completa. La mayoría de la comunidad no tiene que lidiar con la blockchain completa, sino que solo puede lidiar con UTXO. Repito, el tamaño del UTXO de la red Bitcoin Core es de cinco gigabytes, y el tamaño de la blockchain es de 350 gigabytes, por lo que básicamente estás ganando 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 gran victoria.
El segundo documento es Graphene, un nuevo protocolo para la propagación de bloques utilizando la 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 mini de Bitcoin que acabo de describir, tienes mineros y transacciones transmitidas en estilo peer-to-peer todo el tiempo para la red. El ancho de banda es probablemente el problema más resuelto de Bitcoin, pero aún así, tienes un problema cuando se trata de ancho de banda en el momento en que se encuentra un bloque. El minero, para reclamar el bloque, tiene que propagar el coinbase, donde dice: “Mira, tengo un coinbase que cumple con mi objetivo de dificultad”. Luego, todos los demás mineros tienen que descargar el bloque completo, y si se hace de manera ingenua, tienen que validar que el bloque es efectivamente válido, no solo que el coinbase cumple con el objetivo de dificultad.
Cada vez que se encuentra un bloque, hay un requisito máximo porque quieres mantener la cantidad de tiempo que se tarda en transferir un bloque completo, si lo estás haciendo de manera ingenua, 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. Por lo tanto, quieres que la transferencia del bloque sea solo una fracción, digamos menos de 30 segundos, si quieres mantener la red muy estable. Sin embargo, eso significa que el bloque tiene que ser transferido en 30 segundos, lo que pone un límite en tu ancho de banda máximo. La velocidad a la que vas a transferir tu bloque va a estar limitada por tu ancho de banda.
La idea es que con Graphene, una técnica basada en compresión, no necesitarás transferir el bloque completo porque la mayoría de lo que el bloque contiene son en realidad las transacciones que ya se han transmitido a través de la red. Lo único que quieres transmitir es un conjunto de reconciliación, solo para dar información a tus pares (otros mineros) sobre qué transacciones se han incluido o no en tu bloque, de una manera que sea perfectamente confiable. Si haces eso, puedes reducir nuevamente dos órdenes de magnitud en el ancho de banda máximo, lo cual es muy significativo.
Esto es de gran interés, por ejemplo, Graphene funcionaría en redes de Bitcoin Cash o las más recientes redes de eCash, debido a accidentes técnicos completos. No funcionaría en la red de Bitcoin Core. Esto fue parte de las cosas que no fueron realmente anticipadas por Satoshi Nakamoto.
El último requisito que mencioné en mi lista de requisitos es que mantener el software significa que necesitas tener un contrato social en su lugar, para que tengas equipos que puedan hacer el mantenimiento e incorporar descubrimientos posteriores en tu blockchain. De lo contrario, te quedas atascado 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 varios bloques. Como regla general, las personas suelen estimar que si quieres tener absoluta confianza, necesitas esperar 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 la cantidad de tiempo, más pequeños tienen que ser los bloques, lo que socava la escalabilidad. Los bloques infrecuentes significan que puedes tener bloques muy grandes, lo cual es bueno; ayuda a tu red a lidiar con la masa de transacciones.
Teniendo en cuenta los retrasos que tienes en la red global, este objetivo de 10 minutos no es óptimo, pero está dentro de lo que es eficiente para operar este tipo de consenso distribuido con bloques muy grandes, bloques que pueden llegar a tener un terabyte de tamaño. Eso suena muy grande, pero en realidad, si miras el caso de uso a escala humana, eso es lo que se necesita. Necesitas mantener los bloques muy separados en términos de tiempo si quieres preservar tu escalabilidad. Sin embargo, entonces tienes el problema de que la red es lenta. Una hora para confirmar una transacción puede estar bien para un caso de uso de ecommerce, donde está bien si empiezas a no hacer nada después del pago durante 60 minutos ya que la entrega no se realizará antes de mañana de todos modos. Pero si quieres tener algo que suceda 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 ser aprobada el pago, lo cual es muy lento.
Lo que queremos es típicamente un objetivo de algo que sería de tres segundos o menos. Esto se debe a que, desde una perspectiva de experiencia de usuario humano, algo que tarda tres segundos en aclararse será percibido 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. Todavía es demasiado lento para la comunicación de baja latencia de máquina a máquina, 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 varias limitaciones que socavaban a Bitcoin o su escalabilidad, o eran soluciones ingenuas que surgieron rápidamente una vez que se publicó Bitcoin. La mayoría de estas soluciones se basaban en elegir un líder, y este líder actuaría como una autoridad central temporal durante un punto de tiempo, proporcionando servicios de baja latencia. Sin embargo, el problema con la elección de un líder es que cuando se pasa de un líder a otro, el proceso puede ser muy complicado, y puedes tener una situación en la que, en términos de calidad de servicio, la mayoría de las veces son unos segundos y luego a veces es en realidad una hora. Eso sería percibido por todos como un tiempo de inactividad de la red.
Pasó una década para que se publicara una solución que, en mi opinión, era lo suficientemente buena. Esta solución es un brillante 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 está en el algoritmo Snowball, que es precisamente el que no aparece en el título del documento.
Fundamentalmente, lo que diseñaron es la metaestabilidad, y eso es muy interesante. Recuerda, cuando tienes transacciones en conflicto, realmente no importa cuál se elija porque mejorar la latencia se trata de prevenir el doble gasto o en realidad reducir el marco de tiempo en el que puedes tener ambigüedad sobre el doble gasto. La idea de tener algo que es metaestable es que te gustaría tener un protocolo donde los participantes charlen constantemente entre sí. El objetivo es que si hay dos transacciones en conflicto, la red alcanzará un equilibrio metaestable. La red convergerá rápidamente hacia una interpretación de la verdad; no importa cuál, solo tiene que ser una. Entonces, si hay objetos en conflicto, la red discutirá y resolverá el conflicto.
Snowflake proporciona un proceso de convergencia lento, mientras que Snowball, en este documento, ofrece un truco que permite una aceleración exponencial, lo que resulta en una convergencia mucho más rápida. Avalanche aporta algunas propiedades del gráfico relacionadas con el gráfico de transacciones. Sin embargo, mi entendimiento personal es que la contribución de Avalanche es mucho más débil; realmente es Snowball el que está haciendo la magia. Es posible que quieras implementar Avalanche, pero solo Snowball te dará alrededor del 99% de la metaestabilidad que buscas.
Hay una desventaja en este enfoque. Con la prueba de trabajo y los bloques de Satoshi Nakamoto, cualquier observador puede intervenir y presenciar lo que ha sucedido, reproduciendo todo el proceso y comprobando 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 los chats de la red para generar seguridad. No es posible que un observador tardío se una y reevalúe la seguridad de las transacciones pasadas. Sin embargo, realmente no nos importa este problema porque si estás en vivo en la red, evalúas la seguridad de las transacciones que ocurren en ese momento. Para las cosas que sucedieron en el pasado cuando no estabas allí, la prueba de trabajo y los bloques aún proporcionan una forma de validar las transacciones.
Avalanche no se opone 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 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 la prueba de participación. Esto introduce capas de enredo económico, que es una forma muy parecida a Bitcoin de pensar. Para lograr la seguridad deseada, se debe crear una red de enredos económicos para asegurar que todos se mantengan honestos. Hay formas de diseñar soluciones para lograr una mejor latencia.
Ahora, aún en el tema de la expresividad, estamos buscando algo más que solo transacciones financieras, ya que esto se trata de supply chain y el uso de una blockchain para fines de supply chain. Las transacciones financieras son necesarias en segundo plano, pero queremos poder hacer más. La pregunta es, ¿cómo incorporamos esta lógica extra?
En los círculos de criptomonedas, muchas criptomonedas han introducido la noción de contratos inteligentes. Un contrato inteligente es fundamentalmente un programa que es operado por los propios mineros en la blockchain. Los mineros verifican la validez de las transacciones, pero si puedes incluir lenguaje de programación o código de ensamblaje como parte de tu transacción, los mineros podrían ejecutar los programas y verificar que los programas verifican ciertas propiedades. Esto es lo que se hace típicamente en Ethereum, y se conoce como un contrato inteligente. Existe este lema de que “el código es ley”, lo que significa que confiamos en la ejecución del programa porque está 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 mucho el problema de escalabilidad. Escalar una 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 procesar potencialmente una gran cantidad de transacciones porque la cantidad de verificaciones a realizar para 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 empresas. Se vuelve muy difícil, y esto es exactamente lo que ha estado sucediendo durante mucho tiempo en la red Ethereum y otras criptomonedas orientadas a contratos complejos.
Aunque las criptomonedas posteriores como Ethereum se beneficiaron de una mejor ingeniería, todavía enfrentan un problema mucho más difícil en términos de escalabilidad. Una vez que alcanzan cierto nivel de notoriedad y actividad en la red, todos enfrentan problemas masivos de escalabilidad. Todo se reduce al hecho de que tienes que ejecutar todos esos programas.
El segundo problema importante con los contratos inteligentes es que son programas fundamentalmente inmutables. Cuando pones programas en la blockchain, la idea es que confías en esos programas porque operan de forma autónoma. Por “autónomamente”, se entiende que hay mineros con incentivos financieros para ejecutar esos programas para la comunidad, y todo el proceso es transparente y verificable. Sin embargo, el gran problema con los programas inmutables es que si hay un error, no puedes solucionarlo.
La historia de los contratos inteligentes ha sido una serie interminable de violaciones que resultan en pérdidas masivas para aquellos que operan los contratos. Incluso Ethereum tuvo que pasar por un fork masivo, que llevó a Ethereum y Ethereum Classic, porque un contrato violado fue tan significativo que los operadores decidieron que era mejor retroceder los problemas y socavar la propiedad inmutable que se supone que ofrece la blockchain. No hay solución alternativa, y si haces algo no trivial en un contrato inteligente, te estás exponiendo a violaciones.
En 2018, publiqué otro enfoque llamado Tokida que muestra cómo puedes tener programas arbitrarios funcionando junto a la blockchain. Con Tokida, el programa es de código abierto y opera en un modelo de “confiar pero verificar”. Todas las personas que están interesadas en el resultado del contrato pueden verificar si quieren, 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 esté al tanto de lo que has hecho.
Si hay una violación, no es un problema significativo porque puedes parchearlo, y la comunidad puede evaluar que el parche se hizo de buena fe. La idea es que la mayoría de lo que necesitas en términos de un modelo de seguridad para fines de supply chain es simplemente confiar pero verificar. Solo necesitas asegurarte de que si alguien engaña, todas las demás personas se darán cuenta, y eso será suficiente. Para la moneda en sí, quieres evitar que las personas engañen en primer lugar. Pero para los contratos inteligentes, no necesitas el mismo grado de seguridad que con la moneda en sí. Ser capaz de detectar el fraude después del hecho es suficiente. Si alguien comienza a defraudar tu negocio, simplemente no vas a hacer negocios con ese socio nuevamente, y eso sería el fin de la historia. No necesitas tener algo que evite que el fraude ocurra en primer lugar. La confianza es esencial en los negocios, y si estás trabajando con un socio, tienes un cierto grado de confianza con ellos.
Ahora, estamos entrando en la segunda parte de la conferencia, que cubre los casos de uso. Creo que el caso de uso principal para las blockchains sigue siendo los pagos. Pagar a los proveedores, especialmente a los del extranjero, todavía puede ser un desafío. La compensación de una transferencia bancaria puede ser lenta, tardando hasta dos semanas en algunos casos. Los flujos de trabajo de pago del sistema bancario están lejos de estar al día con el siglo XXI, lo que puede llevar a errores como pagos dobles por facturas grandes.
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 por productos que no cumplen con los requisitos de calidad o plazos. Con el dinero programático, puedes implementar todos estos esquemas de formas que habrían parecido ciencia ficción.
Sin embargo, hay dos advertencias para este caso de uso. Primero, las criptomonedas todavía 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 estado disminuyendo. La volatilidad era incluso mayor hace diez años, y ha ido disminuyendo gradualmente desde entonces, pero todavía está más allá 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 acordar con tu socio. Sin embargo, existen clases de sistemas de cambio de divisas robotizados que pueden convertir cualquier criptomoneda en otra, tomando tarifas 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óviles falsificadas, por ejemplo, pueden llevar a accidentes fatales si fallan bajo estrés. Los tokens no fungibles (NFTs) se pueden usar 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 el número a otro participante. El uso de NFTs puede prevenir falsificaciones, incluso de los emisores originales.
Para implementar la trazabilidad basada en NFT, solo necesitas códigos QR y un teléfono inteligente, lo que lo convierte principalmente en una solución basada en software. La tecnología blockchain ofrece una forma de mantener la trazabilidad transparente desde la producción hasta el consumidor. Sin embargo, hay desafíos. Primero, todos deben acordar un formato y una blockchain. La blockchain lleva cargas binarias, por lo que si quieres usarla para fines de trazabilidad, se debe acordar el formato. Esto se convierte en un problema complejo ya que muchas industrias y empresas tienen sus propios formatos y estándares únicos.
Lo que la gente no necesariamente se da cuenta es de 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 sigue a una pieza es un PDF. Para la siguiente etapa, es el mismo PDF pero escaneado, y tal vez para la siguiente etapa, es el mismo escaneo pero anotado y reescaneado. Fundamentalmente, asumes que un humano puede intervenir y descifrar los documentos. Sin embargo, si quieres operar en una blockchain, no puedes tener un proceso tan laxo. Necesitas especificar completamente el formato binario para todos los datos que quieres exponer en la blockchain; de lo contrario, pierdes el ángulo programático donde puedes trabajar con herramientas programáticas.
Unificar todos los estándares es difícil, y tienes que elegir una blockchain porque, para que la trazabilidad funcione, necesitas elegir una blockchain que sea compartida por todos los participantes, al menos para un vertical y una región. El problema es que cuando se trata de elegir una blockchain, tienes conflictos de interés masivos. Dado que una blockchain nunca puede estar completamente desvinculada de su criptomoneda subyacente, si inviertes en una criptomoneda, te conviertes en un conflicto en el sentido de que tienes un interés adquirido en asegurarte de que la empresa elija la blockchain asociada con la criptomoneda que posees.
Estos conflictos de interés son generalizados y difíciles de evaluar ya que las blockchains suelen ser anónimas. Si quieres probar las aguas y obtener comentarios sobre qué blockchain elegir, debes considerar los posibles conflictos de interés que pueden 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 empresas farmacéuticas operando 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 están corruptos hasta cierto punto. Los intermediarios corruptos pueden tomar una caja real con productos reales, cambiar los medicamentos reales de la caja, poner medicamentos falsificados en su lugar y luego vender la caja al mercado. Las personas que compran medicamentos falsificados pueden tener una condición que amenaza la vida y realmente necesitan el medicamento. Este es un problema muy serio en los países pobres, y reproducir el empaque para medicamentos falsificados es trivial. Una solución potencial es usar blockchains y tokens para la trazabilidad activa, que recuerda cómo funciona el impuesto al valor agregado (IVA) en Europa. El IVA es un impuesto difícil de defraudar porque crea un esquema de ingeniería social donde las empresas están enredadas con sus proveedores honestos.
La idea es tomar el mismo concepto y aplicarlo a la blockchain. Por ejemplo, digamos que eres una empresa farmacéutica que produce un medicamento. Vendes un paquete del medicamento a un intermediario o mayorista a un precio más alto, como $15 en lugar del precio real de $10. Se produce la transferencia de propiedad del token, y el mayorista puede canjear $1 en el valor, reduciendo su costo a $14. Luego, el mayorista vende el paquete de medicamentos al distribuidor, y nuevamente, hay una transferencia de propiedad del token. Una vez que el distribuidor reclama el token, pueden canjear $1 del valor que acaban 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 teléfono inteligente, pueden canjear $1, que les es devuelto. 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 la muestra al cliente. Se informa al consumidor final que acaba de recuperar el dólar extra, y el número de serie ahora 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 comprobado toda la cadena de trazabilidad, y que 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 quieren asegurarse de poder verificar si el medicamento es legítimo, especialmente si es para una condición que amenaza la vida. A esto es a lo que llamaría trazabilidad activa, donde tienes un token no fungible (NFT) con un mecanismo financiero superpuesto que da incentivos a todos los jugadores para realizar ciertas acciones.
En el caso del ejemplo del medicamento, 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 los medicamentos falsificados podrían reintroducirse en la red. Al marcar el número de serie como consumido, no puede ser reutilizado por nadie. 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 este es un caso de uso válido, requiere una coordinación significativa entre muchas partes.
Otra aplicación potencial es incentivar el reciclaje a través de sistemas de devolución de depósitos. Estos sistemas existen desde hace 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 envía a lo largo de la supply chain. Sin embargo, hay fricción para poner en marcha estos sistemas, y el desafío es reducir aún más esa fricción. La blockchain y las criptomonedas ofrecen una forma de reducir la cantidad de fricción para los micropagos y potencialmente reducir la infraestructura necesaria para garantizar que las operaciones no sean manipuladas.
Por ejemplo, si devolvieras 20 centavos cada vez que las personas devuelven una botella de vidrio, los adversarios podrían potencialmente manipular el sistema produciendo botellas falsas y obteniendo beneficios con el margen que obtienen al vender las partes recuperadas. Las 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 devolución de depósitos sean nuevos; han existido durante mucho tiempo. Se trata simplemente de reducir un poco la fricción para que pueda haber más casos de uso.
Otro caso de uso de interés 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 y dispositivos de TI están dispersos por todas partes. Por diseño, el área de superficie de ataque es grande, y es difícil hacerlo de otra manera. Una supply chain debe estar conectada a clientes, proveedores, socios y proveedores de logística de terceros, creando un vasto área de superficie de ataque. Si bien la integración de sistemas, como EDI, puede ser valiosa para pedir a los proveedores y mejorar los tiempos de respuesta, una integración más estrecha también trae 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 tubería operara durante una semana y poniendo en peligro la infraestructura crítica en los EE. UU. ¿Cómo puede ayudar la 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 este alijo, creas un incentivo para que los hackers intenten penetrar en tus sistemas y robar el dinero.
Sin embargo, esto no es un robo; se considera una recompensa para los hackers que violan tu sistema. Si un hacker logra violar, digamos, un dispositivo IoT, pueden reclamar la cantidad de dinero dentro. Además, si vuelven a ti y te dicen cómo lo hicieron y cómo solucionar el problema, podrías pagar una segunda parte de la recompensa, valorada en alrededor de $300 en Bitcoin. Al crear un incentivo, financias el trabajo de los hackers éticos que prueban tu seguridad. Si solo los actores malintencionados tienen un incentivo para atacar tus sistemas, descubrirás una violación con un actor malintencionado, lo cual puede ser muy desagradable, como sucedió con Colonial Pipeline. Sin embargo, si das un incentivo a los hackers honestos y éticos para entrar en tu sistema, entonces lo más probable es que las personas que entrarán en tu sistema serán individuos honestos que luego te dirán cómo arreglar tu sistema para prevenir problemas. Lo interesante es que estos alijos son públicos, por lo que si los pones en tu red, puedes monitorear de manera transparente si has sido violado o no. También puedes monitorear externamente todos los dispositivos, incluso si el dispositivo IoT no está conectado a internet. Si ves que las monedas que estaban dentro de este dispositivo se mueven, entonces significa que de alguna manera este dispositivo fue violado de una forma u otra, y eso es fundamental saberlo.
Recuerda que en esas violaciones de alto perfil que se publicitan, generalmente lo que sucede es que los actores estuvieron en los sistemas durante meses antes de que finalmente decidieran reclamar su rescate. Al usar este sistema de seguridad basado en blockchain, creas un mecanismo de alerta temprana. Incluso si los hackers no éticos entran en el sistema, podrían simplemente tomar el dinero y huir, sin pasar por el proceso de rescate complicado.
Esta es una forma diferente de pensar sobre la seguridad y probablemente no sea el caso de uso que estabas pensando para la blockchain en tu supply chain. Pero como puedes ver, los casos de uso interesantes para la supply chain siempre incluyen algún tipo de incentivo monetario, que es muy Bitcoin-esque en términos de pensar en cómo abordar la blockchain con respecto a los casos de uso de supply chain.
Ahora, como mencioné, las blockchains son muy difíciles de diseñar en comparación con prácticamente cualquier solución alternativa. Puedes esperar que sea al menos dos órdenes de magnitud más difícil diseñar una solución blockchain. Entonces, cada vez que pienses que podrías abordar un problema pasando una semana del tiempo de un ingeniero de software, multiplica ese número por 100, y eso te dará el tipo de esfuerzo que se necesita para hacer lo mismo con la blockchain. Hay situaciones en las que tiene sentido; no es porque sea caro que no pueda ser rentable, pero es fundamentalmente difícil, y tienes que tener eso en consideración. Los costos también son mucho más altos cuando se trata de recursos informáticos. Típicamente, la blockchain es muy difícil de escalar, y en comparación con una configuración sin blockchain, terminas gastando 100 veces más recursos informáticos para lo que quieras hacer con la blockchain. En algunas situaciones, es posible que no te importe, pero en muchas otras situaciones, un aumento de 100 veces en tu costo de hardware informático es significativo.
La pregunta es, ¿cómo probamos alternativas? En casi todas las situaciones en las que se involucra una blockchain, existe una alternativa sin blockchain. Típicamente, esto se logra suavizando los requisitos. En términos de valor agregado, si estás dispuesto a renunciar a la propiedad de no negación que describí al principio de esta conferencia, puedes nombrar a un consorcio de algún tipo. Este consorcio utilizará una base de datos de puntos de control, publicará registros que pueden ser verificados por terceros 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 manera programática. Con eso en su lugar, obtendrás la mayor parte del valor que de otro modo obtendrías de una blockchain.
Un gran ejemplo de supply chain de esto sería GS1 para códigos de barras. GS1 es una entidad que asigna códigos de barras, y lo han estado haciendo durante décadas. Esta organización fue creada como una entidad separada, por lo que en ese momento no fue IBM directamente quien administró los códigos de barras. GS1 ofrece el valor agregado de una blockchain sin realmente usar una blockchain. Sin embargo, este enfoque requiere una autoridad central o un consorcio en el que puedas confiar. En muchas industrias que están muy concentradas, como la farmacéutica, establecer un consorcio donde ya existe una participación de mercado significativa puede no ser demasiado difícil.
Para concluir, el consenso de Satoshi Nakamoto es un descubrimiento asombroso. En 2008, si hubieras preguntado a los expertos en sistemas distribuidos si era posible resolver el problema del consenso bizantino sin recurrir a ninguna autoridad central, la mayoría de ellos habría dicho que no, ya que no parecía posible. La idea estaba tan fuera del ámbito de lo que la gente pensaba que era posible que ni siquiera estaban buscando en esa dirección. En ese sentido, fue un descubrimiento asombroso. Como presenté con el mini Bitcoin, es una idea muy simple que tiene usos más allá del dinero, siendo el dinero el caso de uso principal.
Lo que tenemos que tener en cuenta es que para cada caso de uso de blockchain, normalmente hay una alternativa sin blockchain que es mucho más simple de operar. Realmente tenemos que evaluar si el sobrecosto asociado con una blockchain vale todo el problema que obtendrás. Como pensamiento final, nunca olvides que una blockchain está fundamentalmente entrelazada con su moneda subyacente, y esto genera el conflicto de intereses más grande de todos.
En una de mis conferencias anteriores sobre investigación de mercado adversarial, presenté mis puntos de vista sobre cómo elegir proveedores empresariales y discutí los problemas que rodean las revisiones. Muchas formas intuitivas de abordar estos problemas se ven socavadas debido a conflictos de interés. Con las blockchains y las 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 tu empresa toma una dirección que es favorable a una blockchain específica, puede ser favorable para sus inversiones también.
No tengo una buena solución para este problema, pero aconsejo estar consciente y preparado. La mayoría de la información que se encuentra en línea sobre criptomonedas no es confiable, ya que muchas personas tienen un conflicto de interés en promover su moneda preferida. No confíes en nadie, excepto en los colegas en quienes confiarías con tu vida. Confía en tu propio juicio o en el juicio de los colegas que entienden lo que está sucediendo. Los conflictos de interés con las blockchains conducen a comportamientos inesperados, especialmente en supply chain, donde normalmente existen relaciones duraderas y un alto grado de confianza.
Las organizaciones que operan grandes supply chains pueden estar despreparadas para el nivel de desconfianza que se encuentra en el espacio 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 dando esta conferencia que habría personas señalando que no son exactamente lo mismo. Sin embargo, si quieres examinar una blockchain pura en el sentido técnico, entonces un repositorio Git, como GitHub, es una blockchain. Los repositorios Git existen desde hace 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.
El punto es que la blockchain solo funciona en términos del valor agregado 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 eliminas todos los aspectos monetarios e incentivos que están diseñados, entonces tienes algo que es solo una estructura de datos técnica, pero no tiene ningún interés en absoluto. Sí, es una bonita estructura de datos – Git es una bonita estructura de datos – pero no volvió loco a todo el mercado, y ciertamente la gente no se volvería loca y diría: “Oh, este repositorio Git vale miles de millones”. Hay algo diferente. Dejando de lado la terminología, creo que la razón principal por la que muchas empresas optaron por la terminología de blockchain fue para introducir alguna distinción en el discurso de aquellas criptomonedas que se veían como el salvaje oeste completo.
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. Lo que pasa es que siempre que tienes un proceso de emisión de dinero, no importa 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. Entonces, si el banco central imprime 100 y puedo invertir 90 para recuperar esos 100, lo haré.
No importa cómo tengas un proceso de emisión de dinero, las personas van a gastar hasta el costo marginal para igualar la utilidad. Resultó que debido a que Bitcoin Core ha estado inflando en valor, las personas están dispuestas 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 unas pocas décadas a partir de ahora, la cantidad de Bitcoins recién acuñados se reducirá a casi nada, y por lo tanto, la cantidad que las personas estarán dispuestas a pagar por la prueba de trabajo será casi nada. Este es un problema transitorio, y en este momento, se está utilizando principalmente capacidad de electricidad de repuesto no utilizada.
Estoy de acuerdo con tu conclusión; te da un consenso descentralizado en la perspectiva del consenso bizantino, y sí, hay gastos generales masivos asociados. Absolutamente, esta es la conclusión correcta.
Pregunta: ¿Por qué usarlo en la industria de supply chain? ¿Qué resuelve el paradigma descentralizado? ¿Qué problema trae?
Proporcioné varios casos de uso en mi conferencia. Tener descentralización te libera de la necesidad de diseñar un consorcio. El problema es que si tienes una autoridad central en la que confías y esta autoridad central es honesta, entonces bien, no necesitas una blockchain. El truco es, ¿qué haces cuando no tienes eso?
Incluso áreas que tenían autoridades centrales, como por ejemplo las transferencias bancarias para pagos, están bajo el control de autoridades centrales, hay guardianes que son los bancos y luego los bancos centrales. No estamos, diría yo, en una escasez de autoridades centrales, pero aún así, en 2021, liquidar un pago con mis clientes en el extranjero todavía tarda dos semanas. Este es el siglo XXI; puedo enviar un correo electrónico, y es recibido en segundos por esos clientes, pero enviar una transferencia bancaria tarda semanas. Entonces, obviamente, hay algunos problemas que a veces son muy difíciles de resolver porque tal vez el problema no es que no tienes autoridades centrales, sino que tienes demasiadas autoridades centrales, o tienes problemas complejos donde no puedes reunir a las personas para llegar a una solución.
He descrito algunos casos de uso, por ejemplo, la trazabilidad activa, donde operas en un país pobre donde todos los intermediarios son corruptos. Este es otro problema donde no puedes confiar en nadie. Cuando tienes corrupción epidémica, estos problemas son muy difíciles de abordar. Esa es una situación en la que la blockchain descentralizada puede darte una forma de diseñar la honestidad de los participantes. Ese es el truco: no se espera que los participantes sean honestos; están diseñados para permanecer honestos mientras operan la supply chain. Si todo el mundo ya es muy honesto y las autoridades centrales están impuestas, entonces hay muy poco valor añadido.
Pregunta: ¿Cómo lidias con la existencia de ASICs (Circuitos Integrados Específicos de Aplicación) 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 eso? 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 que uses tu dispositivo, ya que eso llevaría a reparaciones y la eliminación del malware.
En términos de seguridad, el panorama en el que estamos es que las organizaciones criminales tienen a su disposición literalmente decenas de millones de computadoras gratis. Estas organizaciones que operan botnets, si miras las actualizaciones de seguridad de Microsoft, verás que un par de veces al año, Microsoft ha eliminado absolutamente masivas botnets en el pasado. Comunicarían, digamos, “Pasamos esta actualización de Windows, y por cierto, acabamos de eliminar, aniquilar esta botnet de 50 millones de máquinas”. Eso es impresionante. Entonces, los ASICs significan que no tiene sentido jugar este juego con hardware regular como el de tus computadoras regulares. Por lo tanto, los criminales que operan botnets no pueden usar esas botnets para minar criptomonedas, lo que elimina un ángulo para monetizar esas botnets. Obliga a los mineros a comprometerse con la moneda.
Ves, los ASICs no son un problema; son, por el contrario, el tipo de solución que asegura que este poder de procesamiento extra no cause estragos o aproveche el tipo de poder de procesamiento que está disponible a través de las botnets. Las botnets ya son un problema masivo para todos, y no queremos empoderar aún más a esas botnets.
Pregunta: ¿Cuáles son tus pensamientos sobre la Red Abierta de Telegram que no pudo ver la luz debido a los tribunales de EE.UU? ¿Cuáles son tus pensamientos en general sobre las criptomonedas emitidas por mensajeros? ¿Aporta algo nuevo?
Bueno, creo que la situación es muy predecible para Telegram y lo mismo para Facebook, y cualquier empresa que quiera operar como una empresa pública. Hay regulaciones generales que dicen que si eres una empresa, hay requisitos de KYC (Conoce a Tu Cliente), y no voy a entrar demasiado en detalles. Básicamente, si eres una gran empresa, puedes esperar que en muchas jurisdicciones, habrá requisitos de KYC. No estoy aquí para discutir si las regulaciones son adecuadas o no; solo estoy diciendo que las regulaciones de 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 aquí van los requisitos de KYC. Si quieres operar una blockchain, tienes que estar de acuerdo en preservar algún tipo de pseudo-anonimato de quien sea que participe en esta red, lo que significa que en términos de requisitos de KYC, estás completamente fuera.
No estaba muy seguro de lo que estas empresas estaban pensando, pero no puedo ver a una empresa que quiera ser tanto pública como responder a autoridades como la SEC en los EE.UU. o la AMF en Francia, mientras pueda participar en un esquema que obviamente va completamente en contra del tipo de regulaciones de KYC que son muy prevalentes para las grandes empresas. Mi opinión es que, fundamentalmente, probablemente estaban probando las aguas para ver si tal vez los reguladores relajarían las regulaciones solo para ellos, solo porque eran grandes. Puede que no haya salido a su manera, y por lo tanto están retrocediendo en eso. Fundamentalmente, aparte de eso, creo que, por ejemplo, Telegram o Facebook, si aceptan que solo promoverían una criptomoneda pero no la operarían, podrían dar un impulso masivo a esta criptomoneda. Sin embargo, el problema es que porque solo estarían promoviendo, no operando, tendrían poco que ganar para ellos mismos, excepto si han diseñado un conflicto de intereses donde se benefician del crecimiento de la moneda. Por cierto, Elon Musk, te estoy mirando cuando empiezas a tuitear sobre Bitcoin y el hecho de que tu empresa tiene una posición en eso. Este es literalmente el juego que se puede jugar: primero adquieres una participación en una criptomoneda y luego literalmente inflas esta criptomoneda simplemente haciendo declaraciones muy visibles al respecto. Deja que la valoración suba y luego, una vez que es más alta, véndela. Por cierto, este proceso se llama pump and dump. Probablemente Telegram y Facebook se dieron cuenta de que la única forma en que podrían beneficiarse simplemente promoviendo una moneda pero no operándola era pump and dumps, y no querían que su reputación se viera dañada por hacer este tipo de travesuras.
Pregunta: Hace siete años, vi a muchas startups trayendo tecnología blockchain a campos relacionados con la supply chain. Ninguno de ellos tuvo éxito, al menos a gran escala. ¿Conoces alguno que haya tenido éxito y demostrado que funciona a gran escala?
Buena pregunta. Quiero decir, primero, no creo que nadie tenga, en el planeta, una blockchain que sea demostrablemente escalable y que realmente funcione a gran escala. Si miramos el experimento de Bitcoin Core, no va bien. La red está completamente saturada; ha estado saturada ahora durante cuatro años. Esto es realmente lo opuesto a la escalabilidad. Si miras a Bitcoin Cash, esa es otra blockchain. Han avanzado algo, pero nunca tuvieron tiempo; tuvieron algunos disensos internos, y por lo tanto nunca hicieron todos los bits finales en términos de ingeniería para hacerlo funcionar. Hay otra, como mencioné, bifurcación recién creada llamada eCash que es básicamente una bifurcación de Bitcoin Cash, donde están intentando de nuevo hacer todas las cosas que no se hicieron en el cliente original de Satoshi porque la mayoría de los problemas de escalabilidad se pueden rastrear hasta el cliente original de Satoshi. Hay alguna 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 hay algo que, en el día de hoy, funciona a hiperescala, aunque tenemos razones para creer que es, hasta cierto punto, posible. He publicado sobre eso, por cierto, si quieres ver mi publicación sobre bloques de tamaño de terabyte para Bitcoin.
Ahora, no hay nadie que haya tenido éxito en llevar esas 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 quieren hacer algo que sea aún más avanzado. Necesitan tener la capa base que pueda escalar, y luego quieren hacer algo que sea supply chain a gran escala también. Creo que ninguno de ellos tuvo éxito porque, como estaba describiendo, sí, hay casos de uso para supply chain, y sí, hay espacio para agregar valor, pero primero, tienes que resolver esos problemas muy difíciles de escalabilidad y latencia. Puede que no haya salido a su manera, y puedes ver 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 todavía son bastante recientes, y todavía llevará mucho tiempo. Para escalar, tienes que hacer avances a nivel de algoritmos teóricos, lo cual es muy difícil de avanzar.
Los algoritmos que describí, como Avalanche, son terriblemente difíciles de implementar correctamente. Hay muchos detalles que puedes hacer mal, y en términos de blockchain, si haces algo mal, significará que serás violado, asaltado, y se perderá dinero. La gravedad de tener errores y problemas cuando operas en el mundo de la blockchain es muy severa. Esto no es como tu software empresarial común y corriente donde si se bloquea, puedes reiniciar, corregir manualmente los bits de datos que se han afectado, y simplemente seguir desde allí. Con las blockchains, una vez que tienes una corrupción masiva, el daño puede ser permanente, y ese es un lugar muy difícil para operar.
Creo que muchas de las startups que entraron en este espacio estaban absolutamente despreparadas en términos de la mentalidad de ingeniería necesaria para enfrentar los desafíos de operar en el reino de la blockchain. La buena ingeniería no es suficiente; necesitas una ingeniería realmente excelente para tener éxito.
Esto concluye la sección de preguntas y respuestas para 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é un tiempo de vacaciones. Por cierto, la optimización matemática, a diferencia de la blockchain, se utiliza diariamente 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 la toma de las mejores decisiones de supply chain. Nos vemos la próxima vez.
