Blockchain combina múltiples disciplinas como pueden ser la informática, teoría de juegos, política monetaria, antropología o psicología, por citar algunos de los ejemplos más recurrentes. Desde el nacimiento de Ethereum, en diciembre de 2013, no han faltado las comparaciones entre esta otra Blockchain pública y Bitcoin incidiendo mucho en un aspecto concreto que las diferencia notablemente. Ethereum es Turing completo mientras que en Bitcoin no lo es. Todos los lenguajes de programación son Turing completos y por eso todo lo que se pueda programar con un lenguaje se puede hacer con otros, sólo cambia el rendimiento y el código. El concepto de Turing completo viene de la informática.
La explicación breve de Turing completo es que permite que un ordenador pueda llegar a programarse para realizar cualquier tipo de operación, pero para profundizar más en este concepto vamos a preguntar a Santiago Márquez Solís, CTO de CLLUC del Grupo Barrabes, coautor del libro 'Blockchain: la revolución industrial de internet' y pionero del ecosistema Bitcoin en España además de Nodo Vídeojuegos con Blockchain España.
¿Qué es el test de inteligencia artificial de Turing?
Es otra de las ideas que salieron de la cabeza de Alan Turing, pero aplicada a la inteligencia artificial (IA). El test de Turing sirve para identificar si una IA puede considerarse como humana. Se basa en el principio de que si un interlocutor humano, habla contra una máquina y no es capaz de discernir si ésta lo es, esa máquina podría considerarse que exhibe un comportamiento inteligente y comparable al de un ser humano.
¿Qué significa Turing completo en un contexto informático?
Este concepto entra dentro de la teoría de los lenguajes formales y fue ideado también por Alan Turing. Por Turing completo se entiende a aquel lenguaje que tiene un poder computacional equivalente a lo que se denomina Máquina de Turing Universal. Dicho de otro modo, Alan Turing ideó un sistema que en teoría podría realizar cualquier tipo de cálculo si se disponía de recursos físicos ilimitados. Aplicado este concepto a la tecnología Blockchain y fundamentalmente a los smart contracts, se refiere a la capacidad que tiene un lenguaje con esta característica de poder aplicarse para resolver cualquier problema computacional e implementar estructuras complejas como son los bucles (loops en inglés).
¿Qué es un bucle en informática? ¿Qué relevancia tiene en el contexto Bitcoin y Ethereum?
Un bucle en informática es una instrucción de repetición que se ejecuta mientras las condiciones de salida del mismo no se cumplan. Este tipo de instrucciones son muy útiles porque nos permiten que los programas puedan realizar, como su nombre indica, tareas repetitivas por código. Por ejemplo, supongamos que necesitamos preguntar el salario de 10 empleados y hacer un incremento del 10% sobre el mismo. Estas dos preguntas (pedir el salario y hacer el incremento) se pondrían dentro de un bucle que se ejecutaría 10 veces (la condición de salida del bucle), sin necesidad de tener que escribir 10 veces el código para hacer dicha operación. Antiguamente, cuando los lenguajes de programación no estaban tan avanzados, este tipo de instrucciones se tenían que implementar utilizando saltos de instrucciones en código (los viejos del lugar dedicados a la programación recordarán los famosos GOTO y GOSUB) que hacían que el código fuera muy difícil de leer y de mantener, y se convertía en un 'spaghetti code' que daba más de un dolor de cabeza.
Con esta idea en la cabeza vemos que tenemos dos proyectos con dos concepciones y contextos muy diferentes. Bitcoin se diseñó para no cumplir con esta propiedad, y fue una de las razones que motivaron a Vitalik Buterin a crear el proyecto Ethereum, al considerar que el lenguaje que opera las transacciones en la red Bitcoin, el Bitcoin Transaction Language, era insuficiente y a su juicio, si se quería evolucionar, tenía que incorporarlo. La falta de respuesta por parte de la comunidad de desarrollo de Bitcoin, entorno a esta propuesta, estaría entre el conjunto de razones para que finalmente Ethereum saliera a la luz.
¿Cómo se construye una transacción en Bitcoin en formato de script en stack? ¿Qué significa script y stack en el contexto de Bitcoin?
El código que Bitcoin ejecuta cuando se produce una transacción está hecho usando el Bitcoin Transaction Language. Es decir, mover dinero de una dirección A hacia otra dirección B, implica un poco más de trabajo que hacer una simple actualización de saldos. Para la gente que no sabe como funciona la tecnología de Bitcoin, es bastante común que lo visualice como el movimiento de dinero en una cuenta corriente bancaria al uso, donde los saldos de una cuenta (origen) se decrementan, mientras que los de otra (destino) se incrementan en la misma proporción. Sin embargo, esto no es así, y este "trabajo extra" se codifica en un lenguaje muy parecido -por buscar un ejemplo-, al lenguaje ensamblador, y que se basa en una estructura de tipo pila para funcionar. Es decir, las instrucciones que se quieren ejecutar, se introducen en una estructura de datos (una pila o stack) de modo que solamente se puede operar con los elementos que están en la cima de la pila. Pongamos un ejemplo, si quiero hacer una suma, introduciría en la pila, primero el operador A, luego el B y luego la operación SUMA. El sistema al procesar la pila, sacaría de la cima de la pila, primero la instrucción SUMA. Como esta instrucción la conoce, sabe que lo siguiente que tiene que hacer es sacar de la pila los dos siguientes elementos, A y B. Y una vez que los ha desapilado, realiza la operación, y guarda el resultado otra vez dentro de la pila. Como en ese momento, no hay ni A, ni B, ni SUMA, en la pila (por que se desapilaron), la nueva cima de la pila, contiene ahora el resultado, sobre el que se pueden apilar, nuevas instrucciones y seguir operando.
Las transacciones en Bitcoin se componen de entradas y salidas, de manera que se conectan unas con otras. Una salida siempre está conectada a una entrada posterior, y una entrada estará conectada siempre a una salida anterior. Sucede además que cada una de ellas está asociada a una función codificada en un script de Bitcoin Transaction Language. Para permitir que el dinero pueda moverse desde una entrada a una salida, es necesario que se ejecute este código porque es el que se encargará de liberarlos y, entre otras cosas, también de verificar las firmas que bloquean una cierta cantidad realmente están autorizadas a ello. Si quisiéramos implementar un contrato inteligente sobre Bitcoin, aquí sería uno de los puntos en donde tendríamos que tener especial cuidado en la codificación de este script. Y como se puede observar es un proceso muy complejo que convierte a este tipo de lenguajes en muy difíciles de programar y depurar.
¿Qué desventajas o ventajas supone para Bitcoin que no sea Turing completo?
La Blockchain de Bitcoin en su totalidad es Turing completo, pero sus scripts - los pequeños programas que ejecutan las transacciones- no los son porque no permiten bucles. Hay un amplio debate sobre si esto es o no así, con distintas opiniones al respecto pero todas muy interesantes de seguir. Cuando se dice que la Blockchain en su conjunto sí es Turing completo se refiere a que con un sistema que mantiene un registro que crece de manera continua y que no se detiene, sería posible transformar las N iteraciones de un bucle, en N iteraciones secuenciales que se necesiten, es decir, estaríamos ante una de las condiciones iniciales que se presuponen para que un sistema sea Turing completo, es decir, un sistema que dispone de recursos ilimitados. Igual no es muy eficiente o muy cómodo de programar pero en teoría es factible. Como comentaba anteriormente, esta visión de lo que se entiende que es (o debería ser) Turing completo, es la base que ha propiciado que Ethereum apareciera en escena.
La ventaja que tiene Bitcoin al no ser Turing completo, desde el punto de vista de su estructura transaccional, está en su sencillez. y del mismo modo implica que está más limitado de cara a poder realizar tareas complejas, como los smart contracts sin elementos adicionales. Sin embargo, los trabajos del proyecto RSK van en este sentido, e intentan añadir a Bitcoin, esta característica. Por otro lado, al no permitirse el uso de bucles, en Bitcoin no es necesario introducir un elemento como es el concepto del gas de Ethereum, que de no existir, nada impediría que una aplicación mal programada (no tiene porque ser a mala idea ni maliciosa) pudiera dejar el sistema tostado (conocido como halting problem) e inservible.
¿Qué desventajas o ventajas supone para Ethereum que sea Turing completo?
Básicamente lo que ya hemos estado comentando, la posibilidad de utilizar estructuras de codificación repetitivas que permiten crear aplicaciones más complejas y de una manera más simple y eficiente, aunque eso implica el tener que disponer de un mecanismo como el Gas para evitar que el sistema pueda ser colapsado. Si comparamos un lenguaje de alto nivel como Solidity de Ethereum, con el BTL de Bitcoin, enseguida nos damos cuenta de las dificultades que presenta el segundo frente al primero, y sin contar que las herramientas de desarrollo distan mucho de ser las mejores.
¿Qué relación tiene el robo de TheDAO (USD 150.000.000) o los problemas de los últimos meses con los contratos inteligentes en la cartera de Parity (USD 150.000.000 - USD 200.000.000) con que Ethereum sea Turing completo? ¿Puedes describir cada uno de estos incidentes y su relación?
TheDAO fue un robo que se produjo por una serie de hechos fatídicos concatenados. Por un lado el poder usar la función split para crear un DAO hijo de manera recursiva, la pobre implementación que se hizo del código y, por último, el poco interés demostrado ante los avisos que se dieron de las malas prácticas que se estaban llevando en la codificación y que los responsables de TheDAO no tuvieron en demasiada consideración. El caso de Parity es un poco diferente, aunque también relacionado con el nivel de maduración de cómo se implementan los contratos. Aquí parece que, por error, se congeló el acceso a los fondos de la billetera que estaban controlados por un contrato específico que presentaba un fallo de programación.
En cualquiera de los casos lo que vemos es una serie de problemas que se producen por la inmadurez de la tecnología, algo que se tiende a olvidar una y otra vez, independientemente de que las plataformas sean o no Turing completos. Los contratos inteligentes están dando sus primeros pasos, hay que ver cuales son los patrones de diseño que mejor se adecuan a los casos de uso que se quieren resolver y que no están del todo definidos. Los problemas están apareciendo como no podía ser de otra manera. Es más, yo estoy convencido que no serán los últimos casos que veremos. Y es lógico que estén apareciendo en primer lugar en Solidity porque es la plataforma más extendida y usada, y en la que más interés actualmente hay. Pero yo más que verlo como un problema, prefiero verlo como una oportunidad, con el tiempo madurará y dispondremos de una herramienta para hacer grandes cosas. Podemos compararlo con los algoritmos de cifrado, su fortaleza reside justamente en que hay mucha gente tratando de romperlos y su código es público.
Algunos argumentan que el lenguaje de programación Solidity sólo tiene a dos personas trabajando activamente en su desarrollo y que eso afecta negativamente la seguridad de Ethereum ¿Qué opinas tú?
Bueno siempre hay que ver las cosas con un poco de perspectiva. Ethereum, Bitcoin o cualquier otra cripto que examinemos son todavía muy jóvenes, y sin embargo se les está exigiendo que tengan unos niveles de desempeño muy por encima de lo que hoy son capaces de proporcionar, y en el caso de Solidity no es una excepción. Nos olvidamos que estamos ante experimentos que nadie nos asegura que mañana no puedan encontrarse con un error crítico que pueda resultar fatal para su supervivencia. Es por eso que los proyectos sobre Blockchain, siempre deben de desarrollarse bajo esta perspectiva. Gavin Wood fue quien desarrolla Solidity en sus comienzos y pasa el testigo una vez que éste presenta una cierta madurez. De todos modos no es raro en desarrollo informático que haya programadores principales, responsables de mantener el código en general (y que siempre destacan en los gráficos) y que coordinan lo que se llaman pull request, esas peticiones de cambio que otros desarrolladores formulan para integrarlas en el código principal. Habría que hacer una análisis más profundo para poder ser tan categóricos, viendo cuales son las actuales incidencias que están abiertas, cuáles son relativas a seguridad, quien las está abordando (y cómo lo hacen) y el roadmap que se sigue en cada caso.
Santiago Márquez Solís es CTO de CLLUC del Grupo Barrabes, Nodo Vídeojuegos con Blockchain España. coautor del libro 'Blockchain: La revolución industrial de Internet' publicado por Ediciones Gestión 2000 (Grupo Planeta) ya disponible a la venta en Amazon.es y en la Casa del Libro, cuyas novedades se pueden seguir en @LibroBlockchain y LibroBlockchain.com
Alex Preukschat es autor coordinador del libro 'Blockchain: La revolución industrial de Internet', autor de la novela gráfica 'Bitcoin: la caza de Satoshi Nakamoto', @BitcoinComic y Nodo Coordinador de BlockchainEspana.com, @BlockchainES.
Edición por Iñigo Molero @Imolman
