Por David Jerry (@digitsu)
Nueva funcionalidad en Bitcoin Cash lo convierte en aspirante a base de contratos inteligentes
Contratos inteligentes. Fue apodado Blockchain 2.0. (Blockchain 1.0 era el dinero en efectivo). Prometía un mundo nuevo, una nueva frontera digital. Anunciaba una era de tratos sin intermediarios, robots que manejan depósitos en garantía, oráculos de inteligencia artificial, y automóviles sin conductor constituyendo sus propias corporaciones como actores autosuficientes en la nueva economía digital. Una economía que no discriminaba entre humanos de pura cepa y autómatas nacidos de código máquina.
Ese fue el sueño. Esa fue la promesa. De eso habló todo el mundo durante los últimos 4 años. Excepto que nunca sucedió. Oh, hubo muchos intentos. Algunos alcanzaron una pizca de éxito, otros no tanto, otros incluso terminaron como auténticos fraudes multimillonarios o robos. (Sí, estoy hablando de la mayoría de los proyectos del espacio Ethereum, especialmente –pero no exclusivamente– de la DAO).
Hablemos un poco sobre Ethereum, ya que es la cadena de bloques con mayor actividad en el espacio Blockchain 2.0. Podría decirse que atrajo a la mayoría de los desarrolladores de Bitcoin tras su lanzamiento en 2015 como cadena de bloques construida para contratos inteligentes y otros usos de dinero programable. Pero al menos la mitad de su éxito se debe al hecho de que, en ese momento, Bitcoin empezaba a sufrir unas limitaciones incapacitantes y autoimpuestas que lo excluían como aspirante a la categoría de dinero programable.
De hecho, Vitalik Buterin, el fundador y líder espiritual del movimiento Ethereum, originalmente era un bitcoiner, y creó Ethereum tan solo porque, en aquel momento, los desarrolladores de Bitcoin Core hicieron deliberadamente todo lo que pudieron para inhabilitar muchas de las funcionalidades que permitían crear un lenguaje de programación para contratos inteligentes en el propio Bitcoin. Así que Vitalik hizo exactamente lo que cualquier buen descentralizador hace al encontrarse con la opresión del régimen establecido. Se fue y se dedicó a lo suyo. Se fue y empezó a diseñar Ethereum. Esto fue en 2013.
Sin embargo, al tener que construirlo desde cero, o quizás porque Vitalik no tenía la misma perspicacia que Satoshi, abordó el diseño de Ethereum de manera bastante ingenua. Quería un lenguaje Turing completo para que a los desarrolladores les resultase fácil escribir contratos inteligentes (Nota del traductor: un lenguaje Turing completo es un lenguaje computacionalmente universal capaz de simular cualquier máquina de Turing. Una máquina de Turing es una máquina hipotética que, a pesar de su simplicidad, puede simular CUALQUIER algoritmo, sin importar cuán complicado sea). Pero un lenguaje Turing completo conlleva la posibilidad de bucles infinitos, algo malo en una cadena de bloques globalmente descentralizada. Así que tomó la decisión de usar un protocolo económico que aplicase un coste a cada paso computacional, de modo que hubiese que pagar por cada operación, para que los programas fuera de control se quedasen en algún momento sin ‘gas’ y detuviesen así su ejecución.
Pero esto trajo consigo toda una nueva clase de complicaciones: ¿cuánto costaría cada operación en relación a otras? ¿Y en relación a la capacidad de cómputo total de la red? ¿Cómo escalaría esto con el paso del tiempo? Procedió entonces a ‘resolver’ este nuevo problema de un modo que añadía aún más complejidad, y así dió paso a una nueva clase de problemas. Decidió que el protocolo simplemente debería cambiar las tasas cada cierto tiempo, por edicto proveniente del mundo exterior. Los mineros debían poder decidir los precios del gas y llegar mágicamente a un consenso haciendo caso del consejo de los principales desarrolladores de Ethereum –la manera en que encararía el problema un banco central–. Económicamente hablando, Ethereum ya se estaba volviendo mucho más complejo que Bitcoin, y escribir y probar contratos inteligentes podía volverse costoso a veces, puesto que, según vas cometiendo errores, tus bugs van quemando tus ETH (la unidad mometaria dentro de la red Ethereum).
Problemas de escalabilidad
Para peor, Ethereum tiene serios obstáculos a su escalabilidad. Puede que hayas oído hablar de cómo una aplicación salvajemente exitosa llamada «Cripto Gatitos» («Crypto Kitties») colapsó toda la red varias veces por inundación de transacciones. ¿Cómo? Es una aplicación de colección y comercio de tarjetas digitales muy adictiva, donde los criadores de criaturas digitales pueden fabricar sus propias y únicas mutaciones de gatitos y venderlas a cambio de ETH. Cuando mucha gente comienza a usar la aplicación al mismo tiempo, la red se inunda de transacciones y toda la cadena de bloques se vuelve más lenta que un caracol. ¿Pero por qué? Porque los diseñadores de Ethereum adoptaron otra estrategia ingenua de cara al problema de STATE (estado) y STORAGE (almacenamiento).
Básicamente, si tienes que ejecutar programas en la cadena de bloques, el código de los programas y su estado intermedio (la memoria del programa según se mueve de instrucción a instrucción) se almacenan completamente en los nodos. Lo cual quiere decir que CADA SERVIDOR ETHEREUM almacena EL ESTADO DE TODOS LOS PROGRAMAS. Un montón de almacenamiento desperdiciado. Sobre todo para las personas que no tienen como pasatiempo la mutación de gatitos digitales. Y lo que es peor, cada servidor Ethereum también hace todos los cálculos para la aplicación descentralizada de Cripto Gatitos, incluso si no la está utilizando.
Cuando Vitalik dice que Ethereum es un «Ordenador Mundial», lo que quiere decir es que es un ordenador muy, muy ineficiente, porque todos los ordenadores del mundo están ejecutando el mismo código, y almacenando los mismos datos, que todos los demás, al mismo tiempo. Sí. No es meramente una propuesta ingenua; es el diseño más ingenuo concebible en computación multipartita descentralizada: ¡que todo el mundo haga cada cómputo! No es de extrañar que se topen con dificultades tan extraordinarias a la hora de intentar escalar Ethereum más allá del punto en que una aplicación popular pueda causar estragos en la red.
Ahora bien, ¿por qué traigo a colación todas estas críticas a Ethereum? No trato de aguarles la fiesta. De hecho, siento un gran respeto por Vitalik y por muchos desarrolladores de contratos inteligentes que he conocido y conozco, ya que están explorando los límites de este espacio, y es sobre los hombros de su duro trabajo como encontraremos el camino hacia la frontera digital del futuro. Sin embargo, quiero llamar la atención sobre los fallos de diseño fundamentales de Ethereum porque pronto tendrá un digno competidor. No, no es otra complicada cadena de bloques de contratos inteligentes nacida del deseo de enriquecerse de sus fundadores (hay muchas en esta categoría). Es, de hecho, el gigante dormido, el original, BITCOIN.
¿Pero cómo?, quizás te preguntes: ¿cómo es posible que ahora sí Bitcoin tenga cimientos sólidos para contratos inteligentes y antes no? ¿Se le escapó algo a Vitalik? No. Porque el Bitcoin que abandonó está todavía atascado exactamente en el mismo lugar en que él lo dejó en 2014. Estamos hablando, por supuesto, de Bitcoin Cash (BCH), el descendiente del legado de Bitcoin que aceptó que los hard forks son un mecanismo de mejora y que es correcto escalar la red y añadirle nuevas funcionalidades o reactivar las viejas.
Es exactamente esto último lo que marcará el comienzo de la nueva era en el desarrollo de contratos inteligentes. Hoy (15 de mayo de 2018), BCH experimentará un hard fork como parte de su proceso de upgrade (actualizaciones que tendrán lugar cada 6 meses), y uno de los cambios más interesantes que serán introducidos en esta oportunidad es la reactivación de algunos de los OP_CODES que los desarrolladores de Core habían desactivado por miedo a que pudieran ser inseguros o abrir nuevos vectores de ataque en la red, en tiempos en que el código base estaba poco maduro y la red era muy pequeña. Para los científicos informáticos que lean esto, las instrucciones más importantes son OP_CAT y OP_XOR (concatenación y XOR lógico). No me meteré en por qué lo son, pero si te interesa puedes leer sobre cómo Bitcoin es, efectivamente, una máquina Turing. Esto quiere decir que pueden hacerse cálculos arbitrarios en Bitcoin, usando un método que separa los DATOS y el CÓDIGO de la prueba de ejecución.
Para los interesados en cuestiones técnicas, la analogía sería que las transacciones de la cadena de bloques de Bitcoin se convierten, de hecho, en una tabla de micro instrucciones, un conjunto de registros de CPU, y el puntero de la pila de un programa. Todos los datos, el código y el almacenamiento están en otra parte. Esto hace que el modelo de Bitcoin sea mucho más simple que el modelo de Ethereum (almacénalo y calcúlalo todo en los nodos). Es una solución tan elegante que uno se pregunta si siempre, desde el momento en que Satoshi creó el diseño original, estuvo predestinada a ser así pero en algún lugar del camino simplemente se descarriló. ¿Y por qué no? Todo en el diseño de Bitcoin es bastante simple y directo. Idearlo requirió varios saltos de intución, pero cuando lo lees la solución es sorprendentemente obvia. Recuerda que el whitepaper (libro blanco) original tiene solamente 9 páginas.
¿Así que en qué lugar deja esto a Ethereum después de Mayo de 2018? Nadie lo sabe. Ethereum todavía le saca varios años de ventaja a Bitcoin Cash. Tiene varios lenguajes de programación a medida que los desarrolladores pueden usar para escribir contratos inteligentes. Bitcoin todavía tiene solamente su SCRIPT original, un lenguaje similar al empleado para programar en una calculadora HP (es similar a FORTH). Pero ahora, cuando se reintroduzcan los OP_CODES, se podrán diseñar lenguajes de nivel más alto que puedan compilar el SCRIPT de bajo nivel de Bitcoin. Preveo que, en los años venideros, se construirá sobre Bitcoin un rico ecosistema de contratos inteligentes y lenguajes para los desarrolladores. Y, por supuesto, cuando digo ‘Bitcoin’ quiero decir Bitcoin Cash, el único Bitcoin que puede ampliar la capacidad de la cadena de bloques.