Whitepaper (Libro Blanco) del Ethereum (ETH)

Whitepaper (Libro Blanco) del Ethereum (ETH). Ethereum White Paper: A Next Generation Smart Contract & Decentralized Application Platform (Una nueva generación de Contratos Inteligentes y Plataforma para Aplicaciones Descentralizada), publicado en www.ethereum.org 

Ethereum Whitepaper

Una nueva generación de Contratos Inteligentes y Plataforma para Aplicaciones Descentralizada

El desarrollo de Bitcoin por Satoshi Nakamoto en 2009, a menudo ha sido aclamado como un desarrollo radical en los conceptos de dinero y moneda, siendo el primer ejemplo de un activo digital que posee al mismo tiempo, carencia de “valor intrínseco” o respaldo y la inexistencia de ningún tipo de emisor centralizado o controlador. Sin embargo otra, posiblemente más importante, parte del experimento Bitcoin, es la tecnología subyacente de la cadena de bloques (blockchain), como una herramienta de consenso distribuido, de modo que la atención está empezando a cambiar rápidamente a este otro aspecto de Bitcoin. Son comúnmente citados los usos alternativos de la tecnología blockchain, que incluirían entre otros la representación, dentro de la propia cadena de bloques, de activos digitales, como podrían ser: las monedas personalizadas, los instrumentos financieros (“monedas de colores“), la propiedad de un dispositivo físico subyacente (“propiedad inteligente“), los activos no fungibles, tales como nombres de dominio (“Namecoin“), así como aplicaciones más complejas que implican tener activos digitales controlados directamente por un fragmento de código que implementaría reglas arbitrarias (“contratos inteligentes“) o incluso “organismos autónomos descentralizados” (DAO) que también podrían estar basados en la cadena de bloques. Lo que Ethereum pretende es, proporcionar una cadena de bloques que tenga incorporada un lenguaje de programación del tipo Turing-completo y que se pueda utilizar para crear “contratos”. Estos a su vez pueden utilizarse para codificar funciones de transición entre estados arbitrarios, de modo, que se permitiría a los usuarios crear cualquiera de los sistemas descritos anteriormente, así como muchos otros que aún no han sido imaginados, simplemente escribiendo su lógica en unas pocas líneas de código.

Tabla de Contenidos

• Historia

• Bitcoin como un Sistema de Transición de Estados

• Minería

• Arboles de Merkle

• Aplicaciones Alternativas de la Cadena de Bloques (Blockchain)

• Guiones (Scripting)

• Ethereum

• Cuentas de Ethereum

• Mensajes y Transacciones

• Función de Transición de Estados de Ethereum

• Ejecución de Código

• Cadena de Bloques y Minería

• Aplicaciones

• Sistemas de Testigos (Tokens)

• Derivados Financieros

• Sistemas de Identificación y Reputación

• Almacenamiento de Ficheros Distribuidos

• Organizaciones Autónomas Descentralizadas

• Otras Aplicaciones

• Varios y Preocupaciones

• Implementación Modificada de GHOST

• Tasas (Fees)

• Computación y Turing Completo

• Moneda y Emisión

• Centralización de la Minería

• Escalabilidad

• Conclusiones
• Referencias y Lecturas Adicionales

Introducción al Bitcoin y Conceptos Previos

Historia

El concepto de moneda digital descentralizada, y  sus aplicaciones alternativas como puede ser el registro de propiedad, ha existido durante décadas. Los protocolos anónimos de e-cash de los 80 y la década de 1990, en su mayoría dependen de una primitiva criptográfica conocida como primitiva ciega de Chaum (Chaumian blinding), que proporcionaba una moneda con un alto grado de privacidad, pero que no llegaría a despegar debido a su dependencia de un intermediario centralizado. En 1998, b-Money de Wei Dai, se convirtió en la primera propuesta que introduciría la idea de creación de dinero a través de la resolución de puzzles computacionales, así como el consenso descentralizado, pero la propuesta se mostró escasa en los detalles de cómo podría ser implementado éste consenso descentralizado en la práctica. En 2005, Hal Finney introdujo el concepto de “pruebas reutilizables de trabajo“, un sistema que utilizaba algunas ideas de b-Money junto con, los rompecabezas computacionalmente difíciles de romper de Adam Back de tipo Hashcash, para volver a crear un concepto de criptomoneda, pero que una vez más, se quedaría corta al apoyarse en el uso de informática de confianza en el backend. Fue en 2009,  cuando se implementa por primera vez, en la práctica, una moneda descentralizada por Satoshi Nakamoto, combinando primitivas ya establecidas para la gestión de la propiedad, a través de la criptografía de clave pública, más un algoritmo de consenso para llevar la cuenta de quién es el dueño de las monedas, conocido como “prueba de trabajo”.

El mecanismo detrás de la prueba de trabajo fue un gran avance, ya que resuelve simultáneamente dos problemas. En primer lugar, proporciona un algoritmo de consenso simple y moderadamente eficaz, permitiendo que los nodos de la red, se pongan de acuerdo colectivamente, en un conjunto de actualizaciones perfectas del estado actual del libro contable de Bitcoin. En segundo lugar, proporciona un mecanismo para permitir la entrada libre en el proceso de consenso, resolviendo el problema político de decidir quién va a influir en el consenso, y evitando al mismo tiempo los ataques de tipo Sybil. Lo hace mediante la sustitución de dos barreras: la barrera formal para participar, es decir, el requisito de estar registrado como una entidad única en una lista particular, y la barrera económica – el peso de un solo nodo en el proceso de votación por consenso es directamente proporcional a la potencia de cálculo de la que el nodo dispone. Desde entonces, se ha propuesto un enfoque alternativo, llamado prueba de participación (proof of stake), en donde el peso de un nodo debe ser proporcional a su posesión de moneda y no a sus recursos computacionales; la discusión sobre los méritos relativos de los dos enfoques van más allá del alcance de este documento, pero cabe señalar que ambos pueden ser utilizados y servir como columna vertebral de una criptomoneda.

Bitcoin cómo un Sistema de Transición de Estados

 Desde un punto de vista técnico, el libro contable de una criptomoneda como Bitcoin, puede ser visto  como un sistema de transición de estados, donde hay un “estado” inicial (que consiste en el estado de propiedad de todos los Bitcoin existentes) y una “función de transición de estado” que toma un estado (inicial) y una transacción y emite un nuevo estado, que es el resultado. En un sistema bancario estándar, por ejemplo, el estado es un balance, una transacción es una solicitud para mover X$ de A hasta B, y donde la función de transición de estado reduce el valor en la cuenta de A por X$ y aumenta el valor de la cuenta B en X$. De manera que si la cuenta de A tiene menos de X$, en primer lugar, la función de transición de estado devuelve un error. Por lo tanto, esta operativa se puede definir formalmente como:

APPLY(S,TX) -> S’ o ERROR

En el sistema bancario que se ha definido anteriormente:

APPLY({ Alice: $50, Bob: $50 },”enviar $20 de Alice a Bob”) = { Alice: $30, Bob: $70 }

Pero:

APPLY({ Alice: $50, Bob: $50 },”enviar $70 de Alice a Bob”) = ERROR

El “estado” en Bitcoin es la colección de todas las monedas (técnicamente, “salidas no utilizadas de una transacción” o UTXO o UTXoutput) que han sido acuñadas y todavía no gastadas, cada UTXO tiene una denominación y un propietario (definida por una dirección de 20 bytes que es esencialmente una clave criptográfica pública [1]). Una transacción contiene una o más entradas, cada entrada contiene una referencia a una UTXO existente y una firma criptográfica producida por la clave privada asociada con la dirección del propietario, y una o más salidas, cada salida contiene una nueva UTXO que se añadirá al estado.

El función de transición de estado APPLY(S,TX) -> S’ puede definirse aproximadamente del modo siguiente:

1.- Por cada entrada en TX:

• Si la UTXO referenciada no está en S, devolver un error.

• Si la firma proporcionada no coincide con el propietario de la UTXO, devolver un error.

2.- Si la suma de todas las entradas UTXO es menor que la suma de todas las salidas UTXO, devolver un error. 

3.- Devolver Scon todas las entradas UTXO eliminadas y con todas las salidas UTXO añadidas.

La primera mitad de la primera etapa, impide al remitente de la transacción, gastar monedas que no existen, mientras que la segunda mitad de la primera etapa, impide al remitente de la transacción gastar las monedas de otras personas. El segundo paso sirve para hacer cumplir la conservación del valor. Con el fin de utilizar este mecanismo para el pago, el protocolo funciona del modo siguiente: Supongamos que Alicia quiere enviar 11,7 BTC a Bob. En primer lugar, Alicia buscará un conjunto de transacciones UTXO que estén disponibles y en donde ella sea la propietaria, al menos, de un mínimo de 11,7 BTC. Siendo realistas, Alicia no será capaz de encontrar exactamente 11,7 BTC; supongamos que la cantidad más pequeña que puede conseguir es 6 + 4 + 2 = 12. Lo que a continuación hará, será crear una transacción con esas tres entradas y dos salidas, tales que la primera salida será de 11,7 BTC con la dirección de Bob como propietario, y la segunda salida será de 0,3 BTC, correspondiente al  “cambio” que queda, y que tendrá como dueño a ella misma.

Minería

Si tuviéramos acceso a un servicio centralizado de confianza, este sistema sería trivial de implementar; simplemente podría codificarse exactamente como se describe, usando el disco duro de un servidor centralizado para realizar un seguimiento de los estados. Sin embargo, con Bitcoin, lo que estamos tratando de construir, es un sistema de moneda descentralizada, por lo que tendremos que combinar, por un lado, un sistema para controlar el estado de las transacciones y por otro, un sistema de consenso, con el fin de garantizar que todo el mundo está de acuerdo en el orden de las operaciones. El proceso de consenso descentralizado de Bitcoin, requiere de nodos de red para intentar producir, continuamente, paquetes de transacciones denominados “bloques”. La red está diseñada para crear más o menos un bloque cada diez minutos, de modo que cada bloque contiene un sello de tiempo, y una referencia (un hash) al bloque anterior, así como  una lista de todas las transacciones que se han producido desde el último bloque. Con el paso del tiempo, se va creando una, cada vez mayor, cadena de bloques o “blockchain” persistente, que se actualiza constantemente para representar el último estado del libro contable de Bitcoin.

El algoritmo para comprobar si un bloque es válido, expresado en este paradigma, es el siguiente:

1. Comprobar si el bloque anterior referenciado por el bloque actual existe y es válido.
2. Comprobar que el sello de tiempo del bloque actual es mayor que el del bloque previo pero menor de 2 horas en el futuro.
3. Comprobar que la prueba de trabajo del bloque es válida.
4. Sea S[0]el estado al final del bloque anterior.
5. Supongamos que TX es la lista de transacción del bloque con n  Para todo i en 0…n-1, establecer  S[i+1] = APPLY(S[i],TX[i]). Si alguna devuelve un error, salir y devolver falso (false).
6. Devolver verdadero (true), y registrar S[n] como el estado al final de este bloque.

En esencia, cada transacción dentro del bloque, debe proporcionar una transición de estado válida desde lo que fue su estado original antes de que la transición fuera ejecutada, hasta el nuevo estado. Nótese, que el estado no está codificado en el bloque de ninguna manera; es puramente una abstracción recordada por el nodo de validación y sólo puede (de forma segura) ser calculada, para cualquier bloque, partiendo del estado génesis y aplicando secuencialmente cada transacción a cada bloque. Además, el orden en que el minero incluye las transacciones dentro del bloque importa, es decir, si hay dos transacciones A y B en un bloque, tal que B gasta una UTXO creada por A, entonces el bloque será válido si A viene antes que B, pero no de otra manera.

La única condición de validez presente en la lista de arriba, que no se encuentra en otros sistemas, es el requisito de “prueba de trabajo”. La condición precisa es que el hash doble SHA256 de cada bloque, tratado como un número de 256 bits, debe ser inferior a un valor ajustado dinámicamente, que en el momento de escribir este artículo es de aproximadamente 2187. El objetivo es hacer la creación de un bloque computacionalmente difícil, de este modo, se previene que atacantes de tipo Sybil pudieran rehacer toda la cadena de bloques a su favor. Debido a que SHA256 está diseñado para ser una función pseudoaleatoria completamente impredecible, la única manera de crear un bloque válido es simplemente por ensayo y error, incrementándolo repetidamente solo una vez y ver si el nuevo hash coincide.

Con el objetivo actual de ~2187, la red debe realizar un promedio de ~269 intentos antes de encontrar un bloque válido. En general, el valor objetivo se vuelve a recalibrar cada 2016 bloques, lo que significa que, en promedio, un nuevo bloque se produce por algún nodo de la red, cada diez minutos. Con el fin de compensar a los mineros por este trabajo computacional, el minero de cada bloque tiene derecho a incluir una transacción que le otorga a si mismo 25 BTC sacados de la nada. Además, si cualquier transacción tiene un valor mayor en sus entradas (inputs) que en sus salidas (outputs), la diferencia también va al minero en concepto de “tarifa de transacción” o “transaction fee”. Por cierto, este es el único mecanismo por el cual los BTC se emiten, el estado génesis no contenía monedas.

Con el fin de comprender mejor los efectos de la minería, examinemos lo que sucedería en el caso de un atacante malicioso. Dado que la criptografía subyacente de Bitcoin se conoce por ser segura, un supuesto atacante se centraría en la parte del sistema Bitcoin que no está protegida por la criptografía directamente: el orden de las transacciones. La estrategia del atacante es simple:

1. Enviar 100 BTC a un comerciante a cambio de algún producto (preferiblemente un bien digital de rápida entrega)
2. Esperar a la entrega del producto
3. Producir otra transacción enviando los mismos 100 BTC a sí mismo.
4. Tratar de convencer a la red que la transacción enviada a si mismo fue la que se realizó primero.

Una vez que el paso (1) ha tenido lugar, después de unos minutos, algún minero incluirá la transacción en un bloque, por ejemplo el bloque número 270000. Después de aproximadamente una hora, se habrán añadido cinco bloques más a la cadena después de ese bloque, con cada uno de esos bloques indirectamente apuntado a la transacción y así “confirmando” la misma. En este punto, el comerciante aceptará el pago como finalizado y entregará el producto, y como estamos asumiendo que es un bien digital, la entrega es inmediata. Ahora, el atacante crea otra transacción enviando 100 BTCs a sí mismo. Si el atacante simplemente la libera, la transacción no será procesada; los mineros intentaran ejecutar la función APPLY(S,TX) y observaran que TX consume una  UTXO que no está en el estado que debería ser. La opción del atacante será crear una bifurcación (fork) de la cadena de bloques, comenzando a minar otra versión del bloque 270000 que apuntará al bloque 269999 como padre, pero con la nueva transacción en lugar de la antigua. Dado que los datos del bloque son diferentes, esto requiere rehacer la prueba de trabajo. Por tanto, la nueva versión del bloque 270000 del atacante tiene un hash diferente, por lo que los bloques originales del 270001 al  270005, no estarán apuntando a él. Es decir, la cadena original y la nueva cadena del atacante están completamente separadas. La regla es que cuando hay una bifurcación (fork) se tome la cadena de bloques más larga como verdadera, y así los mineros legítimos trabajaran en la cadena de 270,005 mientras que el atacante solo estará trabajando en la cadena de 270,000. Para que el atacante pudiera hacer de su cadena de bloques la más larga, tendría que tener más poder computacional que el resto de la red combinada con el fin de ponerse al día (es decir, “el ataque del 51%”).

Árboles de Merkle

Izquierda: es suficiente con presentar solamente un pequeño número de nodos en un árbol de Merkle para dar una prueba de la validez de la rama.

Derecha: cualquier intento de cambiar cualquier parte de un árbol de Merkle finalmente dará una inconsistencia en algún lugar de la cadena.

Una característica importante de la escalabilidad en Bitcoin es que los bloques se almacenan en una estructura de datos de múltiples niveles. El “hash” de un bloque actualmente es solamente el hash de la cabecera del bloque, un fragmento de datos de unos 200 bytes que contiene la fecha y hora (sello de tiempo),  el nonce (en criptografía se llama nonce a un número arbitrario que solamente se utiliza una única vez al realizar algún tipo de operación), el hash del bloque anterior y el hash raíz de una estructura de datos llamada árbol de Merkle que almacena todas las transacciones del bloque. Un árbol de Merkle es un tipo de árbol binario, compuesto por un conjunto de nodos con un gran número de nodos hoja en la parte inferior del árbol que contiene los datos subyacentes, un conjunto de nodos intermedios donde cada nodo es el hash de sus dos hijos, y finalmente un único nodo raíz, también formado por el hash de sus hijos, que representa la parte superior (“top”) del árbol. El objetivo de los árboles de Merkle es permitir que los datos de un bloque puedan ser entregados por partes: un nodo puede descargar solamente la cabecera de un bloque desde un fuente, y otra pequeña parte del árbol relevante para él,  desde otra fuente, y todavía asegurar que los datos son correctos. La razón por lo que esto funciona es porque los hashes se propagan hacia arriba: si un usuario malintencionado intenta hacer un cambio en una transacción falsa en la parte inferior del árbol de Merkle, este cambio provocará un cambio en el nodo superior y seguidamente otro cambio en el nodo por encima de este, hasta que finalmente, se produzca un cambio en la raíz del árbol y por tanto en el hash del bloque, haciendo que el protocolo tenga que registrarlo como un bloque completamente diferente (y casi con toda seguridad con una prueba de trabajo inválida).

El protocolo de árbol de Merkle es, sin duda esencial para la sostenibilidad a largo plazo. Un “nodo completo” en la red Bitcoin, que almacena y procesa la totalidad de cada bloque, requiere unos 15 GB de espacio en disco en Abril de 2014, cantidad que está creciendo a un ritmo de un gigabyte al mes. Actualmente, esto es viable para algunos ordenadores de escritorio pero no para móviles, posteriormente solo empresas y aficionados serán capaces de participar. El protocolo conocido como “verificación del pago simplificado” (“simplified payment verification” o SPV) permite que otra clase de nodos puedan existir, los llamados nodos ligeros o “light nodes”, que descargan los encabezados de los bloques, realizan la verificación de la prueba de trabajo en éstos, y luego descargan solamente las “ramas” asociadas a las transacciones que son relevantes para ellos. Esto permite que los nodos ligeros determinar con una fuerte garantía de seguridad cual es el estado de cualquier transacción Bitcoin, y sus balances actuales, descargando solamente una porción muy pequeña de toda la cadena de bloques.

Aplicaciones Alternativas de la Cadena de Bloques (Blockchain)

La idea de coger la tecnología subyacente de la cadena de bloques y aplicarla a otros conceptos también tiene una larga historia. En 2005, Nick Szabo y su “Títulos de propiedad seguros con autorización de propietario”, es un documento que describe cómo “los nuevos avances en la tecnología de base de datos replicada” servirían para que un sistema basado en la cadena de bloques, almacenara un registro de quién es dueño de qué tierra, junto con la creación de un marco elaborado que incluiría conceptos como la prescripción adquisitiva y los impuestos sobre la tierra. Sin embargo y por desgracia, no existía un sistema eficaz de replicación de base de datos en ese momento, por lo que el protocolo nunca fue implementado en la práctica. Después de 2009, sin embargo, una vez que el consenso descentralizado de Bitcoin se desarrolló comenzaron a emerger una serie de aplicaciones alternativas:

• Namecoin – creada en 2010, Namecoin se describe mejor como una base de datos de registro de nombres descentralizada. En los protocolos descentralizados como Tor, Bitcoin y BiMessage, tiene que haber alguna manera de identificar las cuentas para que otras personas puedan interactuar con ellas, pero en todas las soluciones existentes, el único tipo de identificador disponible, es un hash pseudoaleatorio como: 1LW79wp5ZBqaHW1jL5TCiBCrhQYtHagUWy. Lo ideal y lo que a uno le gustaría, es ser capaz de tener una cuenta con un nombre como “George”. Sin embargo, el problema es que si una persona puede crear una cuenta llamada “george”, entonces otra persona puede utilizar el mismo proceso para registrar “george” para sí, y hacerse pasar por la primera persona. La única solución es un paradigma del tipo first-to-file, en donde el primer registrador tiene éxito y el segundo no – un problema perfectamente adecuado para el protocolo de consenso Bitcoin. Namecoin es la implementación más antigua y exitosa, de un sistema de registro de nombres usando esa idea.

• Colored coins – el objetivo de las monedas coloreadas es servir como un protocolo que permita a la gente crear sus propias monedas digitales  o, en el caso trivial (pero importante) de una moneda con una sola unidad, crear fichas digitales (digital tokens) sobre la cadena de bloques de Bitcoin. En el protocolo de las monedas coloreadas, alguien “emite” una nueva moneda asignando públicamente un color determinado a una transacción Bitcoin UTXO específica, así el protocolo definirá, de forma recursiva, el color de otra UTXO para que sea del mismo color que el de las entradas que se pasaron para crearla (aplicándose  algunas reglas especiales en el caso de darse entradas mixtas de color). Esto permite a los usuarios tener carteras que contienen solamente UTXO de un color específico y que pueden enviar de la misma manera que los Bitcoin normales, y además usar la cadena de bloques para determinar el color de cada UTXO que reciben.

• Metacoins – la idea detrás de las Metacoin es tener un protocolo que funciona en la parte superior del protocolo Bitcoin, utilizando las transacciones Bitcoin para almacenar a su vez las transacciones de las Metacoins, las cuales tienen funciones de transición de estado diferentes y que llamaremos, APPLY’. Debido a que en el protocolo Metacoin no se puede impedir que aparezcan transacciones Metacoin no válidas sobre la cadena de bloques de Bitcoin, se añade una regla tal que si APPLY'(S,TX) devuelve un error,  el valor por defecto del protocolo será APPLY'(S,TX) = S. Esto proporciona un mecanismo fácil para la creación de un protocolo arbitrario para una criptomoneda, potencialmente con características avanzadas pero que no se puede implementar en el interior de Bitcoin, y que tendría un coste muy bajo de desarrollo porque las complejidades de la minería y la interconexión en red ya son tratadas por el propio protocolo Bitcoin. Las Metacoins se han utilizado para implementar algunas clases de contratos financieros, registro de nombres e intercambio descentralizado.

En general, hay dos enfoques entorno a la construcción de un protocolo de consenso: la construcción de una red independiente, y la creación de un protocolo en la parte superior de Bitcoin. El primer enfoque, con un éxito razonable en el caso de aplicaciones como Namecoin, es difícil de implementar; cada implementación individual necesita de su propia cadena de bloques independiente, así como construir y probar todas las transiciones de estado necesarias y el código de interconexión de red. Además, podemos predecir que el conjunto de aplicaciones que usaran la tecnología de consenso descentralizado seguirá una distribución de leyes de potencia, en donde la gran mayoría de las aplicaciones serán demasiado pequeñas como para justificar su propia cadena de bloques, por no decir que existen grandes clases de aplicaciones descentralizadas, particularmente las organizaciones autónomas descentralizadas, que necesitan interactuar unas con otras.

Por otro lado, la aproximación basada en Bitcoin tiene el defecto de que no hereda las características de verificación de pago simplificado de Bitcoin. SPV funciona para Bitcoin, porque puede utilizar la profundidad de la cadena de bloques como un sustituto para la validez; en algún momento, alguno de los antecesores de una transacción estarán lo suficientemente lejos en el tiempo, que es seguro decir que legítimamente forman parte del estado. Por otro lado, los meta protocolos basados en la cadena de bloques, no pueden obligar a la cadena de bloques a no incluir las transacciones que no son válidas en el contexto de sus propios protocolos. Por lo tanto, una implementación de un meta protocolo SPV totalmente segura necesitaría retroceder todo el camino, hasta el comienzo de la cadena de bloques de Bitcoin, para determinar si ciertas transacciones son válidas o no. Actualmente, todas las implementaciones “ligeras” de protocolos de metadatos basados en Bitcoin, dependen de un servidor de confianza para proporcionar los datos, lo que posiblemente es un resultado claramente poco óptimo especialmente cuando uno de los propósitos principales de una criptomoneda es eliminar la necesidad de la confianza.

Secuencias de Comandos (Guiones o Scripts)

Incluso sin ninguna extensión, actualmente el protocolo Bitcoin facilita una versión simple del concepto de “contrato inteligente” (smart contracts). En Bitcoin una UTXO puede no solamente pertenecer a una determinada clave, sino también a una complicada secuencia de comandos (o guiones o scripts) expresados en un lenguaje de programación que se basa en el uso de una sencilla pila. En este paradigma, una transacción que haga el gasto de esa UTXO debe proporcionar los datos que satisfagan la secuencia de comandos. De hecho, incluso el mecanismo de propiedad de clave pública básica se implementa a través de una secuencia de comandos: se toma una firma de curva elíptica como entrada, se verifica contra la transacción y la dirección que posee la UTXO, y se devuelve 1 si la verificación es exitosa y 0 en caso contrario.

Existen otras secuencias de comandos más complicadas, para casos de uso adicionales. Por ejemplo, se puede construir una secuencia de comandos que requiera el uso de dos de tres claves privadas dadas para hacer una validación (“multisig”), configuración que es útil para cuentas corporativas, de ahorro o en algunas situaciones de aplicaciones comerciales. Las secuencias de comandos también pueden usarse para pagar recompensas por la solución de problemas computacionales, e incluso uno puede construir una secuencia de comandos que diga algo como “ésta Bitcoin UTXO es tuya si puedes proporcionar una prueba SPV de haberme enviado una transacción Dogecoin con ésta denominación”, lo que en esencia permitiría el intercambio descentralizado entre criptomonedas (cross-cryptocurrency exchange).

Sin embargo, el lenguaje de secuencia de comandos implementado en Bitcoin tiene varias limitaciones importantes:

• No es Turing-completo – es decir, aunque hay un subconjunto de operaciones que el lenguaje de secuencia de comandos de Bitcoin soporta, no lo soporta todo. La categoría principal que falta son los bucles, que no existen para evitar la existencia de bucles infinitos durante la verificación de las transacciones;  teoricamente es un obstaculo superable para los programadores, ya que cualquier bucle puede ser simulado simplemente repitiendo el código subyacente muchas veces con una sentencia if, pero que da lugar a secuencias de comandos ineficientes en cuestión de espacio. Por ejemplo, la implementación de un algoritmo de firma de curva elíptica alternativo, probablemente requeriría de 256 multiplicaciones repetidas incluidas de forma individual en el código.

• Value-blindness – no hay manera de que una secuencia de comandos UTX0 provea un control de grano fino sobre la cantidad que puede ser retirada. Por ejemplo, un caso de uso interesante seria el de un oráculo en un contrato de cobertura, donde dos partes A y B ponen Bitcoin por valor de 1.000$, después de 30 días la secuencia de comandos envía 1.000$ en BTC a A y el resto a B, para poder hacerlo se requiere del oráculo para determinar el valor que tiene 1 BTC en USD. Aunque esta solución demuestra ser una enorme mejora en términos de confianza y requisitos de infraestructura, sobre las soluciones totalmente centralizadas que están disponibles actualmente, deja cuestiones abiertas. Debido a que las UTXO son del tipo o todo o nada, la única manera de lograrlo es a través de un truco muy ineficiente que consiste en tener muchas UTXO con denominaciones diferentes (por ejemplo. una UTXO de 2k para cada k hasta 30) y que habrá que elegir qué UTXO se envia a A y cual a B.

• Ausencia de estado –  Una UTXO puede ser gastada o no, no hay oportunidad para contratos de varias etapas o secuencias de comandos que mantengan cualquier otro estado interno más allá de eso, lo que hace que sea difícil hacer contratos de múltiples estados, ofertas de intercambio descentralizadas o protocolos criptográficos de dos étapas (necesarios para tener primas computacionales seguras). También significa que las UTXO sólo se pueden utilizar para construir contratos simples de un solo uso y no contratos “con estado” más complejos, tales como las organizaciones descentralizadas y haciendo difícil de implementar meta-protocolos adicionales. Este estado binario combinado con el value-blindness anterior, significa que otra aplicación importante, como son los límites de retirada de dinero, son imposibles de realizar.

• Blockchain-blindness – Las UTXO son “ciegas” cara a los datos de la cadena de bloques como puede ser el nonce,  el sello de tiempo o el hash del bloque previo. Esto limita seriamente las aplicaciones en los juegos de azar y otras categorías, al privar al lenguaje de una fuente potencialmente valiosa de aleatoriedad.

Así, vemos tres enfoques para la creación de aplicaciones avanzadas sobre la base de las criptomonedas: construcción de una nueva blockchain, usar secuencias de comandos por encima de  Bitcoin, y construir un meta-protocolo también por encima de Bitcoin. La construcción de una nueva blockchain permite una libertad ilimitada en la construcción de un conjunto de características, pero a costa de tiempo de desarrollo, esfuerzo para ponerlo en marcha y seguridad. El uso de secuencias de comandos es fácil de implementar y estandarizar, pero están muy limitados en sus capacidades y meta-protocolos, siendo además fácil que sufran fallos en escalabilidad. Con Ethereum, tenemos la intención de construir un marco alternativo que proporciona ganancias aún mayores en la facilidad de desarrollo, así como propiedades más fuertes en los clientes ligeros, mientras que al mismo tiempo permite que las aplicaciones compartan un entorno económico y de seguridad en la cadena de bloques.

Ethereum

El objetivo de Ethereum es crear un protocolo alternativo para construir aplicaciones descentralizadas, proporcionando un conjunto diferente de posibilidades que creemos va a ser muy útil para este tipo de aplicaciones, con especial énfasis en situaciones donde son importantes: un tiempo de desarrollo rápido, la seguridad en aplicaciones pequeñas y que rara vez se utilizan, y la capacidad de que aplicaciones diferentes interactuen de manera muy eficiente. Ethereum hace esto mediante la construcción de lo que es esencialmente una capa abstracta funcional definitiva: una cadena de bloques con un lenguaje de programación integrado del tipo Turing-completo, que permite que cualquiera pueda escribir contratos inteligentes y aplicaciones descentralizadas que pueden crear sus propias reglas arbitrarias para la gestión de la propiedad, los formatos de transacción y las funciones de transición de estados. Una versión escueta de Namecoin se puede escribir en dos líneas de código, y otros protocolos como monedas y sistemas de reputación se pueden construir con menos de veinte. Los contratos inteligentes, las “cajas” criptográficas que contienen un determinado valor y que sólo se desbloquean si se cumplen ciertas condiciones, también puede ser incorporadas en la parte superior de la plataforma, con mucho más poder que el que ofrece el lenguaje de secuencias de comandos de Bitcoin, debido a los potencia añadida del Turing-completo, el valor-conocimiento (value-awareness), el blockchain-conocimiento (blockchain-awareness)[1] y el estado.

Cuentas Ethereum

En Ethereum, el estado se compone de objetos llamados “cuentas”, cada una de estas cuentas tiene una dirección y transiciones de estado, que pueden ser transferencias de valor o de información entre cuentas. Una cuenta de Ethereum contiene cuatro campos:

• El nonce, un contador usado para asegurar que cada transacción puede ser procesada solamente una vez.
• El balance actual de éter (ether) de la cuenta
• El código del contrato de la cuenta, si existe
• El almacenamiento de la cuenta (vacio por defecto)

“Ether”  es el principal cripto-combustible de Ethereum, y se utilize para pagar los tasas de la transacción.  En general, hay dos tipos de cuentas: cuentas de propiedad externas (externally owned account o EOAs), controladas por una clave privada, y cuentas de contrato, controladas por un código de contrato. Una cuenta de propiedad externa no tiene código, y se pueden enviar mensajes desde ella mediante la creación y la firma de una transacción; en una cuenta de contrato, cada vez que la cuenta de contrato recibe un mensaje, su código se activa, lo que le permite leer y escribir en el almacenamiento interno y enviar otros mensajes o crear otros contratos de vuelta.

Tenga en cuenta que los “contratos” en Etereum no deben ser vistos como algo que debe ser “cumplidos”; más bien, son más como “agentes autónomos” que viven dentro del entorno de ejecución de Ethereum, siempre ejecutan una pieza específica de código cuando son “empujados” por un mensaje o una transacción, y que tiene un control directo sobre su propio balance de ether y su propia llave/valor (key/value) almacenada para realizar un seguimiento de las variables persistentes.

Mensajes y Transacciones

El término “transacción” se utiliza en Ethereum para referirse a un paquete de datos firmado que almacena un mensaje para ser enviado desde una cuenta de propiedad externa (externally owned account o EOAs). Las transacciones contienen:

• El receptor del mensaje
• Una firma que identifica al remitente.
• La cantidad de éter para transferir desde el emisor al receptor.
• Un campo de datos opcional.
• Un valor STARTGAS, que representa el número máximo de pasos computacionales que se permite tomar a la ejecución de las transacciones.
• Un valor GASPRICE, que representa la cuota que paga el remitente por cada paso computacional.

Los tres primeros se corresponden con campos estándar que se esperan en cualquier criptomoneda. El campo de datos no tiene ninguna función por defecto, pero la máquina virtual tiene un código de operación mediante el cual un contrato puede tener acceso a estos datos; por ejemplo, si un contrato está funcionando como un servicio de registro de dominios en la cadena de bloques, entonces se podría interpretar los datos que se pasan a ella como que contiene dos “campos”, el primer campo sería un dominio a registrar y el segundo campo la dirección IP para registrarlo. El contrato leería estos valores a partir de los datos del mensaje y los colocaría apropiadamente en su sitio.

Los campos STARTGAS y GASPRICE son cruciales en el modelo de servicio anti rechazo de Ethereum. A fin de evitar bucles infinitos accidentales u hostiles u otro desperdicio computacional en el código, se requiere que cada transacción establezca un límite en el número de pasos de cálculo de ejecución que el código puede utilizar. La unidad fundamental de computación es el “gas”; y por lo general, un paso computacional cuesta 1 unidad de gas. Hay algunas operaciones con un mayor costo de gas porque son más caras o bien computacionalmente hablando, o bien porque aumentan la cantidad de datos que deben ser almacenados como parte de su estado. También hay una tarifa de 5 unidades de gas por cada byte de datos de la transacción. La intención del sistema de tasas es exigir a un posible atacante el pago proporcional por todos los recursos que consuma, incluyendo la computación, el ancho de banda y el almacenamiento. Por lo tanto, cualquier transacción que se dirige a la red consume una mayor cantidad de cualquiera de estos recursos y debe tener una cuota de gas más o menos proporcional al incremento.

Mensajes

Los contratos tienen la habilidad de enviar “mensajes” a otros contratos. Los mensajes son objetos virtuales que nunca son serializados y que existen solamente en el entorno de ejecución de Ethereum. Un mensaje contiene:

• El remitente del mensaje (implícito).
• El receptor o beneficiario del mensaje.
• La cantidad de ether a transferir junto con el mensaje.
• Un campo de datos opcional.
• Un valor STARTGAS.

En esencia, un mensaje es como una transacción, excepto porque son originadas por un contrato y no por un actor externo. Un mensaje se produce cuando un contrato que está actualmente ejecutando código ejecuta la llamada CALL opcode, que produce y ejecuta un mensaje. Como una transacción, un mensaje se dirige a un receptor que ejecuta su código. Por lo tanto, los contratos pueden tener relaciones con otros contratos exactamente de la misma manera que los actores externos pueden.

Tenga en cuenta que la cantidad de gas asignada a una transacción o a un contrato, se aplica al total del gas consumido por esa transacción y a todas sus sub-ejecuciones. Por ejemplo, si un actor externo A envía una transacción a B con 1000 unidades de gas y B consume 600 unidades de gas antes de enviar un mensaje a C, y la ejecución interna de C consume 300 unidades de gas antes de finalizar, entonces B podrá gastar otras 100 unidades de gas antes de quedarse sin el.

Función de Transición de Estados de Ethereum

En Ethereum la función de transición de estado, APPLY(S,TX) -> S’ puede ser definida como sigue:

1.- Comprobar si la transacción está bien formada (es decir, tiene el número correcto de valores), la firma es válida, y el valor del nonce coincide con el valor del nonce en la cuenta del remitente. Si no se produce, devuelve un error.

2.- Calcula la tarifa de la transacción como STARTGAS * GASPRICE, y determina la dirección de envío de la firma. Resta esta tarifa del balance de la cuenta del remitente e incrementa el valor del nonce. Si no hay balance suficiente para gastar, devuelve un error.

3.- Inicializa GAS = STARTGAS, y saca una cierta cantidad de gas por byte a pagar por los bytes de la transacción.

4.- Transfiere el valor de la transacción desde la cuenta del remitente a la cuenta del destinatario. Si la cuenta de destino no existe todavía, la crea. Si la cuenta de destino es un contrato, ejecuta el código del contrato hasta su finalización o hasta que la ejecución agote la cantidad de gas.

5.- Si el valor de la transferencia falla porque el remitente no tiene suficiente dinero, o porque la ejecución del código agote el gas, se revierten todos los estados excepto el del pago de la tasa, que se añade a la cuenta del minero.

6.- En otro caso, devolver la cuota del gas restante al remitente, y enviar la tarifa por el pago del gas consumido al minero.

Por ejemplo, supongamos que el código del contrato es el siguiente:

if !self.storage[calldataload(0)]:

   self.storage[calldataload(0)] = 

calldataload(32)

En realidad, el código del contrato está escrito en código de bajo nivel de la EVM (Ethereum Virtual Machine); el siguiente ejemplo escrito en Serpent (uno de nuestros lenguajes de alto nivel) para mayor claridad, puede ser compilado a código EVM. Supongamos que el almacenamiento del contrato comienza vacío, y una transacción se envía con un valor de 10 unidades de ether, 2.000 unidades de gas, 0.001 unidades de precio del gas ether, y 64 bytes de datos, donde los bytes del  0 al 31 representan el número 2 y los bytes del 32 al 63 representan la cadena CHARLIE. En este caso, el proceso que sigue la función de transición de estado es el siguiente:

1.- Comprobar que la transacción es válida y está bien formada.

2.- Comprobar que el remitente de la transacción tiene al menos 2000 * 0.001 = 2 unidades de ether. Si esto es así, restar estas 2 unidades de ether de la cuenta del remitente.

3.- Inicializa gas = 2000; asumiendo que la longitud de la transacción es de 170 bytes y la tarifa por byte es de 5 unidades, restar 850 (170 x 5) lo que deja 1150 unidades de gas.

4.- Restar 10 unidades más de ether de la cuenta del remitente, y añadirlos a la cuenta del contrato.

5.- Ejecutar el código. En este caso, es simple: comprueba si el almacenamiento del contrato con índice 2 está siendo usado, observa que no lo está y lo establece con el valor de CHARLIE. Suponiendo que esto consume 187 unidades de gas, la cantidad de gas restante que queda es de 1150 – 187 = 963

6.- Añadir 963 * 0.001 = 0.963 unidades de ether de vuelta a la cuenta del remitente, y devolver el estado resultante.

Si no había ningún contrato en el extremo receptor de la transacción, la tasa total de la transacción simplemente sería igual al GASPRICE proporcionado multiplicado por la longitud de la transacción en bytes, los datos que se envían junto con la transacción serían irrelevantes.

Tenga en cuenta que los mensajes funcionan de forma equivalente a las transacciones en términos de reversión: si la ejecución de un mensaje se queda sin gas, entonces la ejecución de ese mensaje, junto con todas las demás ejecuciones desencadenados por éste, se revierten, pero no asi las ejecuciones de los padres que no tienen porque hacerlo. Esto significa que es “seguro” para un contrato llamar a otro contrato, por ejemplo si A llama a B con G unidades de gas, entonces la ejecución de A, tiene garantizado que cómo máximo, podría perder esta cantidad de G unidades de gas, pero no más. Por último, hay un código de operación, CREATE, que crea un contrato; su mecánica de ejecución es generalmente similar a CALL, con la excepción de que al finalizar la ejecución se devuelve el código de un contrato de nueva creación.

Ejecución de Código

El código en los contratos de Ethereum, está escrito en un lenguaje de códigos de bytes (o bytecode) de bajo nivel y basado en el uso de una pila (stack-based bytecode language), y que es conocido como “Código de Máquina Virtual de Ethereum” o “código EVM[2]“. El código consta de una serie de bytes, donde cada byte representa una operación. En general, la ejecución de código es un bucle infinito que consiste en realizar repetidas veces la operación que se encuentra en el contador de programa actual (que comienza en cero) y que se va incrementando en uno, hasta que se alcanza o bien el final del código, o un error, o una instrucción STOP o se detecta la instrucción RETURN. Las operaciones tienen acceso a tres tipos de espacios donde almacenar datos:

• La pila (stack), es un contenedor donde el último elemento en entrar es el primero en salir y donde los valores pueden meterse y sacarse.
• Memoria (Memory), una matriz de bytes que es infinitamente ampliable,
• Almacenamiento (storage) a largo plazo del contrato del tipo clave/valor (key/value store). A diferencia de la pila y la memoria, que se limpian después de finalizar la ejecución, el almacenamiento persiste en largo plazo.

El código también puede acceder al valor, el remitente y a los datos del mensaje entrante, así como a los datos de la cabecera del bloque. El código puede también devolver una matriz de bytes de datos como salida.

El modelo formal de ejecución de código EVM es sorprendentemente simple. Mientras la máquina virtual de Ethereum está en ejecución, su estado completo puede ser definido por la tupla (block_state, transaction, message, code, memory, stack, pc, gas), donde block_state es el estado global que contiene todas las cuentas e incluye los saldos y almacenamientos. Al inicio de cada étapa de ejecución, la instrucción en curso se encuentra  en el pc-esimo byte de code (o 0 ifpc >= len(code)), cada instrucción tiene su propia definición en términos de cómo afecta a la tupla. Por ejemplo, la instrucción ADD saca dos elementos de la pila e introduce en ella su suma, reduce el gas en 1 e incrementa el pc también en 1. La instrucción SSTORE empuja hacia abajo los dos primeros elementos de la pila e inserta el segundo elemento en el índice especificado por el primer elemento. Aunque hay muchas maneras de optimizar la ejecución sobre la máquina virtual de Ethereum a través de la compilación just-in-time, la implementación básica de Ethereum puede hacerse con unos cientos de líneas de código.

Cadena de Bloques y Minería

La cadena de bloques de Ethereum es similar a la de Bitcoin en muchas cosas, aunque también tiene algunas diferencias. La diferencia principal entre Ethereum y Bitcoin respect a la arquitectura de la cadena de bloques es que, a diferencia de Bitcoin, los bloques de Ethereum contienen una copia tanto de la lista de transacciones como del estado más reciente. A parte de eso, otros dos valores, el número de bloques y la dificultad, también están almacenados en el bloque. El algoritmo básico de validación de bloque en Ethereum es el siguiente:

1.- Comprueba si el bloque previo referenciado existe y es válido.

2.- Comprueba que el sello de tiempo del bloque es mayor que el bloque previo referenciado y menor de 15 minutos en el futuro.

3.- Comprueba el número de bloque, la dificultad, la transacción raiz, la raíz tía y el límite de gas (varios conceptos de bajo nivel específicos de Ethereum) son válidos.

4.- Comprueba que la prueba de trabajo del bloque es válida.

5.- Establece S[0]como el estado al final del bloque previo.

6.- Establece TXcomo la lista de transacciones del bloque, con n transacciones. Para todo i en ..n-1, establece S[i+1] = APPLY(S[i],TX[i]). Si alguna aplicación devuelve un error, o si la cantidad de gas consumido por el bloque hasta este momento exceed el GASLIMIT, devuelve un error.

7.- EstableceS_FINAL como S[n], pero añadiendo al bloque la recompense pagada por el minero.

8.- Comprueba si la raiz del árbol de Merkle del estado S_FINAL es igual a la raiz del estado final proporcionada por la cabecera del bloque. Si esto es así, el bloque es válido, en otro caso, no lo es..

El enfoque puede parecer muy ineficiente a primera vista, porque necesita almacenar el estado completo de cada bloque, pero en realidad la eficiencia debería ser comparable a la de Bitcoin. La razón es que el estado se almacena en una estructura de árbol, y después de cada bloque sólo una pequeña parte del mismo necesita ser cambiada. Así, en general, entre dos bloques adyacentes la gran mayoría del árbol debe ser el mismo, y por tanto, los datos pueden ser almacenados una vez y referenciarse dos veces usando punteros (es decir, hashes de subárboles). Un tipo especial de árbol, conocido como un “árbol Patricia”, se utiliza para lograr esto, incluyendo una modificación en el concepto de árbol de Merkle que permite a los nodos ser insertados y borrados, y no sólo cambiados, de manera eficiente. Además, dado que toda la información de estado es parte del último bloque, no hay necesidad de almacenar toda la historia de la cadena de bloques – una estrategia que, si se pudiera aplicar a Bitcoin, se puede calcular que proporcionaría un ahorro en espacio de 5 a 20 veces.

Una de las preguntas más frecuentes es “donde” se ejecuta el código del contrato, en términos de hardware físico. Esto tiene una respuesta simple, el proceso de ejecución del código del contrato es parte de la definición de la función de transición, que a su vez forma parte del algoritmo de validación del bloque, por tanto si una transacción se añade dentro del bloque B, el código generado por esa transacción será ejecutado por todos los nodos, ahora y en el futuro, que descarguen y validen el bloque B.

Aplicaciones

En general, hay tres tipos de aplicaciones que pueden implementarse en la capa superior de Ethereum. La primera categoría son las aplicaciones financieras, que proporcionan a los usuarios formas más poderosas de administrar y gestionar los contratos usando su dinero. Esto incluye submonedas, derivados financieros, contratos de cobertura, carteras de ahorro, testamentos, y en última instancia, incluso algunos tipos de contratos de trabajo. La segunda categoría son aplicaciones semifinancieras donde el dinero está involucrado pero hay un lado no monetario de peso; un ejemplo perfecto de esto son las recompensas por la solución de problemas computacionales. Por ultimo, hay aplicaciones como  el voto online y el gobierno descentralizado que no son aplicaciones financieras en absoluto.

Sistema de Testigos (Tokens[3])

Un sistema de testigos (tokens) construido sobre la cadena de bloques tiene un rango de aplicaciones muy amplio, que van desde las submonedas que pueden representar activos como el dólar o el oro, hasta acciones de empresas, testigos individuales que representan propiedad inteligente, cupones seguros infalsificables e incluso sistemas de testigos simbólicos, sin vínculos con un valor convencional y que pueden usarse como sistemas de incentivación. Los sistemas de testigos son sorprendentemente fáciles de implementar en Ethereum. El punto clave a entender, es que toda monada, o sistema de testigos, fundamentalmente es una base de datos con una operación: substraer X unidades de A y dar X unidades a B, con la condición que (1) A tiene al menos X unidades antes de la transacción y (2) la transacción está aprobada por A. Todo lo que se necesita para poner en la práctica un sistema de testigos es implementar ésta lógica en un contrato.

El código básico para implementar un sistema de testigos (tokens) en Serpent se parece a lo siguiente:

def send(to, value):

if self.storage[msg.sender] >= value:

    self.storage[msg.sender] = 

self.storage[msg.sender] – value

    self.storage[to] = self.storage[to] + value

Lo anterior, es esencialmente la implementación literal de la función de transición de estado de un  “sistema bancario” descrita más arriba en este documento. Unas pocas de líneas de código adicionales se añadirían para la etapa inicial de distribución de las unidades monetarias o de algunos casos extremos, lo ideal sería añadir una función que dejara a otros contratos consultar el balance de una dirección. Pero eso es todo lo que hay que hacer. Teoricamente, el sistema de testigos de Ethereum actuando como submonedas puede potencialmente incluir otra característica importante de las que carecen las metamonedas basadas en la cadena de Bitcoin: la capacidad de pago de comisiones por transacción directamente en esa moneda. La forma en la que esto sería implementado es que el contrato mantendría el balance de ether que reembolsaría para pagar las comisiones al remitente, y rellenando su balance recogiendo las unidades de moneda interna de las comisiones que revendería en una subasta de ejecución contínua. Los usuarios tendrían la necesidad de “activar” sus cuentas con ether, pero una vez que el ether está alli volvería a ser reutilizable porque el contrato se lo devolverá cada vez.

Derivados Financieros y Monedas de Valor Estable

Los derivados financieros son la aplicación más común de un “contrato inteligente” y uno de los más simples de implementar en código. El principal desafío que entrañan su implementación es que la mayoría de ellos requieren una referencia a un precio externo, por ejemplo, una aplicación muy deseable sería un contrato inteligente (contrato de cobertura en este caso) que cubriera contra la volatilidad del ether (u otra criptomoneda) con respecto al dólar estadounidense, pero para poder hacer esto se requiere que el contrato sepa cuál es el valor entre ETH/USD. La forma más simple de hacer esto es a través de un contrato de “fuente de datos” mantenido por una parte específica designada (por ejemplo NASDAQ) de manera que esa parte tiene la habilidad de actualizar el contrato cuando es necesario y proporcionando un interface que permite a otros contratos enviar un mensaje a éste y obtener una respuesta de vuelta con el precio.

Teniendo en cuenta este ingrediente crítico, el contrato de cobertura se vería de la siguiente manera:

1.- Esperar una entrada de la parte A de 1000 ether.

2.- Esperar una entrada de la parte B de 1000 ether.

3.- Registrar el valor en USD de 1000 ether, calculado mediante la consulta de un contrato de fuente de datos, que devuelve que el valor es de $x.

4.- Después de 30 días, permitir que A o B “reactiven” el contrato a fin de enviar $x unidades de ether (calculado consultando otra vez el contrato de la fuente de datos para obtener el nuevo precio) a A y el resto a B.

Tal contrato tendría un potencial significativo en el criptocomercio. Uno de los principales problemas citados al hablar de criptomonedas es de hecho su volatilidad; y es que aunque muchos usuarios y comerciantes pueden ver la seguridad y conveniencia de tratar con activos criptográficos, muchos no desean enfrentar la perspectiva de perder el 23% del valor de sus fondos en un solo día. Hasta ahora, la solución más comúnmente propuesta ha sido la de emisión de activos con respaldo, es decir, la idea es que un emisor crea una sub-moneda para la que tiene derecho de emisión y revocación de unidades, además de asignarlas a cualquier persona que les proporcione (de manera offline) una unidad de un activo subyacente especificado (por ejemplo, el oro, o el dólar americano). El emisor se compromete a proporcionar a su vez, una unidad del activo subyacente a cualquier persona que envía una unidad del cripto-activo. Este mecanismo permite que cualquier activo no criptográfico sea “elevado” a la categoría de cripto-activo, siempre que se pueda confiar en el emisor.

En la práctica sin embargo, los emisores no son siempre confiables, y en algunos casos, la infraestructura bancaria es demasiado débil o demasiado hostil, para que estos servicios puedan existir. Los derivados financieros son una alternativa. Aquí, en lugar de un único emisor que proporcione los fondos para respaldar un activo, hay un mercado descentralizado de especuladores que juegan este papel, apostando a que el precio de un activo criptográfico de referencia (por ejemplo, ETH) va a subir. A diferencia de los emisores, los especuladores no tienen la opción de dejar de pagar su parte del trato debido a que el contrato de cobertura mantiene sus fondos en fideicomiso. Tenga en cuenta que este enfoque no es totalmente descentralizado, ya que una fuente de confianza sigue siendo necesaria para proporcionar el precio de referencia, aunque podría decirse que incluso todavía se trata de una enorme mejora en términos de reducción de las necesidades de infraestructura (a diferencia de un emisor, la emisión de un indicador de precios no requiere de licencias y es probable que se pueden clasificar como libertad de expresión) y reduce la posibilidad de fraude.

Sistemas de Identificación y Reputación

La criptomoneda alternativa más antigua de todas, Namecoin, intentó utilizar una cadena de bloques como la de  Bitcoin para proporcionar un sistema de registro de nombres, donde los usuarios pueden registrar sus nombres en una base de datos pública junto a otros datos. El principal caso de uso citado sería el sistema de DNS, donde se mapearían los nombres de dominio como “bitcoin.org” (o en el caso de Namecoin, “bitcoin.bit”) a una dirección IP. Otros casos de uso incluyen la autenticación de correo electrónico y sistemas de reputación potencialmente más avanzados. Aquí vemos el contrato básico para proporcionar un sistema de registro de nombres del tipo Namecoin sobre Ethereum:

def register(name, value):

if !self.storage[name]:

   self.storage[name] = value

El contrato es muy simple; es una base de datos dentro de la red Ethereum donde se puede agregar, pero no modificar o eliminar. Cualquier persona puede registrar un nombre con algún valor y ese registro queda para siempre. Un contrato más sofisticado de registro de nombres también podría tener “cláusulas de función” que permitirían que otros contratos pudieran realizar consultas, así como un mecanismo para el “propietario” (es decir, el primero que registró) de un nombre que le habilitaría para cambiar los datos o transferir la propiedad. Incluso en la parte superior se podría agregar funcionalides asociadas a la reputación o a confianza en la web.

Almacenamiento Descentralizado de Ficheros

En los últimos años, han surgido una serie de nuevas empresas de almacenamiento de archivos en línea muy populares (siendo Dropbox  la más prominente de todas) y que buscan permitir a los usuarios subir una copia de seguridad de su disco duro a la que puede acceder a cambio de una cuota mensual. Sin embargo, en este momento el mercado de almacenamiento de archivos es a veces relativamente ineficiente y una mirada superficial a diferentes soluciones existentes muestra que, sobre todo en el “valle inquietante” que se situaría en el nivel de los 20 a los 200 GB y en donde no entran en juego ni las opciones gratuítas ni los descuentos de nivel empresarial, los precios mensuales son más de lo que estaríamos pagando por el disco duro en un solo mes. Los contratos de Ethereum pueden permitir el desarrollo de un ecosistema de almacenamiento de archivos descentralizado, donde los usuarios individuales pueden ganar pequeñas cantidades de dinero por el alquiler de sus propios discos duros y el espacio no utilizado, lo que se puede utilizar para impulsar costos de almacenamiento de archivos más bajos.

La pieza clave de un dispositivo de este tipo sería lo que hemos denominado el “contrato Dropbox descentralizada”. Este contrato funciona como sigue. En primer lugar, divide los datos deseados en bloques, que se cifran para garantizar su privacidad, y a partir de ahí se construye un árbol de Merkle sobre ellos. Luego se crea un contrato con la regla siguiente,  cada N bloques, el contrato escoge un índice al azar en el árbol de Merkle (utilizando el hash del bloque anterior, accesible desde el código del contrato, como fuente de aleatoriedad), y dando X cantidad de ether a la primera entidad que suministre una transacción con verificación de pago simplificado como prueba de la propiedad del bloque en ese índice en particular del árbol. Cuando un usuario desea volver a descargar su archivo, puede utilizar un protocolo de canal de micropagos para recuperarlo (por ejemplo, pagar 1 szabo por 32 kilobytes.); el método más eficiente de pago para el pagador sería no publicar la transacción hasta el final, y sustituyéndola con una un poco más lucrativa, con el mismo nonce, después de cada 32 kilobytes.

Una característica importante del protocolo es que, a pesar de que puede parecer que uno está confiando en muchos nodos aleatorios que podrían decidir olvidar el archivo, se puede reducir ese riesgo hasta casi cero al dividir el archivo en muchos pedazos a través de la compartición de secretos y usando los contratos para ver que fragmento se encuentra todavía en posesión de alguno de los nodos. Si un contrato todavía está pagando dinero, esto proporciona una prueba criptográfica que alguien por ahí fuera sigue almacenando el archivo.

Organizaciones Autónomas Descentralizadas

El concepto general de una “organización autónoma descentralizada” es el de una entidad virtual que tiene un cierto conjunto de socios o accionistas que, tal vez con una mayoría del 67%, tienen el derecho de gastar los fondos de la entidad y modificar su código. Los miembros decidirán colectivamente sobre cómo la organización debe asignar sus fondos. Los métodos para la asignación de los fondos de una DAO[4] podrían variar y ser del tipo de: recompensas, sueldos o incluso mecanismos aún más exóticos, tales como una moneda interna para recompensar el trabajo. Esto esencialmente replica las trampas legales de una empresa tradicional o sin ánimo de lucro pero utilizando la tecnología criptográfica de la cadena de bloques para su ejecución. Hasta ahora la mayor parte de la charla alrededor de las DAOs ha sido sobre un modelo “capitalista” de “corporación autónoma descentralizada” (DAC) con acciones negociables y accionistas que reciben dividendos; o también sobre otra alternativa descrita como “comunidad autónoma descentralizada”, donde todos los miembros tienen una participación igual en la toma de decisiones y que requiere que al menos el 67% de los miembros existentes estén de acuerdo para añadir o eliminar miembros. El requisito para que una persona pueda estar afiliada necesitaría entonces ser impuesta colectivamente por el grupo.

Un esquema general de cómo codificar una DAO es el siguiente. El diseño más simple sería un fragmento de código que se cambiaría a si mismo si dos tercios de los miembros están de acuerdo con el cambio. Aunque el código es teóricamente inmutable, se puede conseguir esto fácilmente y tener la mutabilidad de facto, teniendo trozos de código en contratos separados, y guardando en el almacenamiento modificable la dirección del contrato que tiene que invocarse. En una sencilla implementación de dicho contrato DAO, habría tres tipos de transacciones, que se distinguen por los datos que proporcionan:

• [0,i,K,V] para registrar una propuesta con índice I  para cambiar la dirección del almacenamiento de índice K al valor V
• [0,i] para registrar un voto a favor de la propuesta i
• [2,i] para finalizar la propuesta i si se han realizado suficientes votos

El contrato tendría entonces cláusulas para cada una de ellas. Se mantendría un registro de todos los cambios en el almacenamiento abiertos, junto con una lista de quien votó por ellos. También se tendría una lista de todos los miembros. Cuando cualquier cambio en el almacenamiento consigue que dos tercios de los miembros con derecho a voto voten por él, entonces una transacción de finalización podría ejecutar el cambio. Un esqueleto más sofisticado, también habría incorporado en esta capacidad de voto, otras características como el envío de una transacción, la adición o eliminación de miembros, e incluso podría proporcionar un estilo de voto por delegación del estilo de la Democracia Líquida[5] (es decir, cualquiera puede asignar a otro para que vote por él, teniendo en cuenta que la asignación es transitiva y que si A asigna a B y B asigna a C, entonces C determinaría la votación de A). Este diseño permitiría al DAO crecer orgánicamente como una comunidad descentralizada, dejando a las personas delegar eventualmente en miembros especialistas, aunque a diferencia de los especialistas “del sistema actual”, ahora estos pueden aparecer o desaparecer en el tiempo  a medida que los miembros individuales de la comunidad cambian sus posiciones[6].

Un modelo alternativo podría servir para una sociedad descentralizada donde cualquier cuenta puede tener cero o más acciones, y donde se requieren dos tercios de las acciones para tomar una decisión. Un esqueleto completo implicaría funcionalidad para la gestión de activos, la capacidad de hacer una oferta para comprar o vender acciones, y la capacidad de aceptar las ofertas (preferiblemente con un mecanismo de emparejamiento de las órdenes dentro del contrato). La delegación también existiría al estilo de una Democracia Líquida, generalizando el concepto de un “consejo de administración”.

Otras Aplicaciones

1. Carteras de Ahorro. Supongamos que Alicia quiere guardar sus fondos a salvo, pero está preocupada porque ella pueda perder o alguien pueda hackear su clave privada. Ella pone ether en un contrato con Bob, que es un banco, como sigue:

• Alicia solamente puede retirar un máximo del 1% de sus fondos cada día.
• Bob solo puede retirar un máximo de 1% de los fondos por día, pero Alicia tiene la capacidad de hacer una transacción con su clave que anule esta capacidad.
• Alicia y Bob juntos pueden retirar cualquier cantidad.

Normalmente, un 1% al día es suficiente para Alicia, y si Alicia quiere retirar más, puede contactar con Bob para que la ayude. Si la clave de Alicia es hackeada,  le pide a Bob que mueva los fondos a otro contrato. Si ella pierde su clave, Bob pondrá eventualmente poner los fondos fuera. Si Bob se vuelve malicioso, Alicia puede anular la capacidad de Bob para retirar sus fondos.

1. Seguros para cosechas. Uno puede fácilmente hacer un contrato para un derivado financiero usando una fuente de datos del tiempo climático en vez del índice de un precio. Si un granjero en Iowa compra un derivado que le paga inversamente basándose en las precipitaciones de lluvia en Iowa, entonces si hay una sequía, el agricultor automáticamente recibirá dinero y del mismo modo si hay suficiente lluvia, estará feliz porque sus cultivos estarán bien. Esto se puede ampliar de manera general a cualquier tipo de seguros por desastres naturales.
2. Fuentes de datos descentralizadas. Para los contratos financieros por diferencia, es actualmente posible descentralizar la fuente de datos mediante un protocolo llamado “SchellingCoin“. SchellingCoin básicamente funciona del siguiente modo: N partes ponen juntas en el sistema el valor de un determinado dato (por ejemplo el precio ETH/USD), los valores están ordenados, y todo el mundo entre el percentil 25 y el 75 obtienen una recompensa. Todos tienen el incentivo de proporcionar la misma respuesta que el resto proporcione, de manera que solamente el valor proporcionado y que tiene un mayor número de apariciones, es el que se considera como verdadero por defecto. Esto crea un protocolo descentralizado que teóricamente proporcionaría cualquier número de valores, incluyendo el precio anterior, la temperatura en Berlin o incluso el resultado particular de una operación computacional muy costosa.
3. Custodia multifirma inteligente. Bitcoin permite contractos con transacciones multifirma donde, por ejemplo, tres de cinco claves dadas pueden gastar los fondos. Ethereum permite más granularidad; por ejemplo, cuatro de cinco pueden gastar todo, tres de cinco pueden gastar hasta un 10% diario, y dos de cinco pueden gastar hasta un 0.5% diario. Adicionalmente, la multifirma en Ethereum es asíncrona, dos partes pueden registrar sus firmas en la cadena de bloques en diferentes momentos y la última de ellas automáticamente enviará la transacción.
4. Computación en la nube. La tecnología de la EVM puede ser usada también para crear entornos de computación verificables, lo que permite que unos usuarios pidan a otros efectuar cálculos computacionales y opcionalmente, en ciertos puntos de control aleatorios y seleccionados, comprobar que estos fueron realizados correctamente. Esto permitiría la creación de un mercado computacional en la nube, donde cualquier usuario puede participar con su ordenador de sobremesa, portátil o servidor especializado, y que junto con los puntos de control y los depósitos de seguridad se puede utilizar para garantizar que el sistema es confiable (es decir, los nodos no pueden engañar de modo rentable). Aunque tal sistema puede no ser adecuado para todo tipo de tareas; tareas que requieren un alto nivel de comunicación entre procesos, por ejemplo, y que no pueden ser realizadas fácilmente en una gran nube de nodos. Otras tareas, sin embargo, son mucho más fáciles de paralelizar; proyectos como SETI @ home, Folding @ home y algoritmos genéticos pueden ser fácilmente implementados en la parte superior de dicha plataforma.
5. Sistemas de juegos y apuestas peer to peer. Cualquier numero de protocolos de juegos peer to peer (de igual a igual), tales como Cyberdicede Richard Clayton, puede implementarse sobre la cadena de bloques de Ethereum. El protocolo de juego más simple, es en realidad un contrato por diferencia con el hash del bloque siguiente, cualquier protocolo más avanzado se puede construir a partir de ahí, creando servicios de juego con tasas cercanas a cero y que no tienen capacidad para hacer trampas.
6. Predicción de Mercados. Proporcionando un oráculo o SchellingCoin, la predicción de mercados es fácil de implementar. La predicción de mercados junto con SchellingCoin puede proporcionar la primera aplicación de futarquía[7] como protocolo de gobierno para organizaciones descentralizadas.
7. Mercados Descentralizados On-chain, usando como base los sistemas de identidad y reputación

Varios y Preocupaciones

Implementación Modificada GHOST

El protocolo “Greedy Heaviest Observed Subtree” (Ghost) es una innovación introducida por primera vez por Yonatan Sompolinsky y Aviv Zohar en diciembre de 2013. La motivación detrás de GHOST es que las cadenas de bloques con tiempos de confirmación más rápidos, actualmente sufren de seguridad reducida debido a una alta tasa de caducidad – es decir, los bloques se toman un cierto tiempo en propagarse a través de la red, si un minero A mina un bloque y seguidamente un minero B mina otro bloque antes que el bloque del minero A se propague a B, el bloque del minero B terminará desaprovechado y no contribuirá a la seguridad de la red. Además, hay un problema de centralización: si el minero A es un grupo (un pool) minero que posee el 30% del poder de hash y B tiene el 10% de este poder, A tendrá un riesgo de producir un bloque caducado solo el 70% del tiempo (ya que el otro 30% de las veces A produjo el último bloque y obtendrá los datos de la minería de inmediato), mientras que B tendrá un riesgo de producir un bloque caducado el 90% de las veces. Por lo tanto, si el intervalo entre bloques es lo suficientemente corto como para que esta tasa de caducidad sea alta, A será sustancialmente más eficiente simplemente en virtud de su tamaño. Con estos dos efectos combinados, las cadenas de bloques que producen bloques más rápidamente, es muy probable que estén siendo generadas, por una piscina de minería que tiene suficiente porcentaje de poder de hash en la red y que de facto, tiene el control sobre el proceso de minería.

Según lo descrito por Sompolinsky y Zohar, GHOST resuelve el primer problema de pérdida de seguridad de la red mediante la inclusión de bloques caducados en el cálculo de cual es la cadena “más larga”; es decir, no sólo los padres y otros antepasados de un bloque, sino también los descendientes caducados de los antepasados del bloque (en la jerga de Ethereum, “tíos”) se añaden al cálculo, asi el bloque tiene la mayor prueba de trabajo que lo respalda. Para resolver el segundo problema de sesgo de la centralización, vamos más allá del protocolo descrito por Sompolinsky y Zohar, y también se ofrecen recompensas por los bloques caducados: un bloque caducado recibe el 87,5% de su recompensa base, y el sobrino, que incluye al bloque caducado, recibe el restante 12,5%. Los gastos de transacción, sin embargo, no se otorgan a los tíos.

Ethereum implementa una versión simplificada de GHOST la cual solamente desciende siete niveles. Específicamente se define del modo siguiente:

• Un bloque debe especificar un padre, y debe especificar 0 o más tios.
• Un tío incluido en un bloque B debe tener las siguientes propiedades:

• Debe ser hijo directo de la k-esima generación antepasada de B, donde 2 <= k <= 7.

• No puede ser un antepasado de B

• Un tio debe tener una cabecera de bloque válida, pero no tiene que ser de un bloque previamente verificado o incluso válido

• Un tio debe ser diferente de todos los tíos incluidos en los bloques previos y de todos los otros tíos incluidos dentro del mismo bloque (no-doble-inclusión)

• Por cada tío U en el bloque B,  el minero de B obtiene un 3.125% adicional que se añade a su recompensa coinbase, el minero de U obtiene el 93.75% de la recompensa coinbase estándar.

Esta versión limitada de GHOST, con tíos incluibles solamente hasta 7 generaciones fue utilizada por dos razones. Primera, un GHOST ilimitado incluiría demasiadas complicaciones en el cálculo de cual tio es válido para un bloque dado. Segundo, un GHOST ilimitado con compensación como se usa en Ethereum elimina el incentivo para que el minero mine en la cadena principal y no en la cadena de un atacante.

Tasas

Debido a que cada transacción publicada en la cadena de bloques impone a la red el costo de tener que descargarla y comprobarla, hay una necesidad de algún mecanismo de regulación, que normalmente implica tasas de transacción, para evitar abusos. El enfoque predeterminado, utilizado en Bitcoin, es tener tasas puramente voluntarias, confiando en los mineros para que actúen como los guardianes y establezcan mínimos dinámicos. Y ha sido recibido particularmente, en la comunidad Bitcoin, muy favorablemente porque está “basado en el mercado”, lo que permite que la oferta y la demanda entre los mineros y los transmisores de transacción determinen el precio. El problema con esta línea de razonamiento es, sin embargo, que el procesamiento de transacciones no es un mercado; aunque es intuitivamente atractivo interpretar el procesamiento de transacciones como un servicio que el minero está ofreciendo al transmisor, en realidad, cada transacción que un minero incluye tendrá que ser procesada por cada nodo de la red, por lo que la gran mayoría de los costes de procesamiento de la transacción se soportan por terceros y no por el minero que está tomando la decisión de si debe o no incluirla. Por lo tanto, la tragedia de los comunes es un problema que es muy probable que pueda ocurrir.

Sin embargo, resulta que este fallo en el mecanismo basado en el mercado, cuando se da un supuesto inexacto simplificado en particular, por arte de magia se cancela a sí mismo. El argumento es el siguiente. Supongamos que:

1. Una transacción conduce a k operaciones, ofreciendo una recompensa de kR a cualquier minero que la incluya y en donde R es fijado por el emisor y k y R son (más o menos) visibles de antemano para el minero.
2. Una operación tiene un costo de procesamiento C para cualquier nodo (es decir, todos los nodos tienen la misma eficacia)
3. Hay N nodos de minería, cada uno con una potencia de procesamiento exactamente igual (es decir 1/N del total).
4. No existen nodos completos no mineros.

Un minero estaría dispuesto a procesar una transacción si la recompensa esperada es mayor que el costo. Por lo tanto, la recompensa esperada es kR/N donde el minero tiene una probabilidad de 1/N de procesar el siguiente bloque, y el costo de procesamiento para el minero es simplemente kC. Según esto, los mineros incluirán las transacciones donde kR/N>KC, o R>NC. Tenga en cuenta que R es la tarifa por operación proporcionado por el emisor, y es por tanto un límite inferior en el beneficio que para el emisor se deriva de la transacción, y NC es el costo para toda la red que en conjunto procesa la operación. Por lo tanto, los mineros tienen el incentivo para incluir sólo aquellas operaciones para las que el beneficio utilitario total exceda el costo.

Sin embargo, hay varias desviaciones importantes de estos supuestos en realidad:

1. El minero hace pagar un costo más alto para procesar la transacción que los otros nodos de verificación, ya que los tiempos adicionales de verificación retarda la propagación del bloque y por tanto aumenta la posibilidad de que éste se convierta en uno caducado.
2. Existen nodos completos no mineros.
3. La distribución de potencia minera puede acabar siendo radicalmente igualitaria en la práctica.
4. Los especuladores, enemigos políticos y locos cuya una única función de utilidad es causar daños a la red, y que hábilmente pueden establecer contratos en los que su coste es mucho menor que el coste pagado por otros nodos de verificación.

(1) conlleva una tendencia a que el minero incluya menos transacciones, y (2) aumenta NC; por lo tanto, estos dos efectos, al menos parcialmente se anulan entre sí. (3) y (4) son el principal problema; para resolverlos basta simplemente con instituir una tapa flotante: ningún bloque puede tener más operaciones que BLK_LIMIT_FACTOR veces el promedio móvil exponencial a largo plazo. Específicamente:

blk.oplimit = floor((blk.parent.oplimit * (EMAFACTOR – 1) + floor(parent.opcount * BLK_LIMIT_FACTOR)) / EMA_FACTOR)

BLK_LIMIT_FACTOR y EMA_FACTOR son constantes que se establecerá en 65.536 y 1,5 por el momento, pero es probable que se cambian después de un análisis más detallado.

Hay otro factor que desincentiva grandes tamaños de bloque de Bitcoin: los bloques que son grandes llevan más tiempo en propagarse, y por tanto tienen una mayor probabilidad de convertirse en caducados. En Ethereum, los bloques con un alto consumo de gas también pueden tomar más tiempo en propagarse tanto porque pueden ser físicamente más grande o debido a que necesitan más tiempo para procesar y validar las transiciones de estado de transacción. Esto retraso descentivador es una consideración importante en Bitcoin, pero no tanto en Ethereum debido al protocolo GHOST; por lo tanto, basándose en los límites regulados de bloque proporciona una base más estable.

Computación y Turing-Completo

Una importante característica de la Máquina Virtual de Ethereum es que es Turing completo; esto significa que en el código EVM se puede codificar cualquier cálculo concebible, incluyendo bucles infinitos. El código EVM permite los bucles de dos maneras. En primer lugar, hay una instrucción JUMP que permite al programa volver (saltar) de nuevo a un punto anterior en el código, y una instrucción JUMPI que sirve para hacer saltos condicionales, lo que permitiría declaraciones como: mientras x <27: 2.="" a="" bajo="" bucle="" bucles="" como="" completos="" conduce="" conocido="" contratos="" de="" debido="" detendr="" determinado="" el="" en="" entrar="" esto="" font="" general="" hacer="" halt="" halting="" hay="" infinito="" inform="" la="" llamar="" los="" lugar="" maliciosos="" manera="" mineros="" naturalmente="" ndoles="" no="" nodos="" oblig="" otros="" parada="" permitiendo="" potencialmente="" problem="" problema:="" problema="" programa="" pueden="" recursividad.="" s="" saber="" se="" segundo="" si="" surge="" tica="" tirar="" trav="" un="" usuarios="" x="x" y="">

Como se describe en la sección de transición de estado, nuestra solución funciona requiriendo a las operaciones establecer un número máximo de pasos computacionales que se les permite gastar, de modo que si la ejecución lleva más tiempo de computación que la permitida, ésta se revierte pero las tasas aún se pagan. Los mensajes funcionan de la misma manera. Para mostrar la motivación detrás de nuestra solución, considere los siguientes ejemplos:

• Un atacante crea un contrato que ejecuta un bucle infinito y, a continuación, envía una transacción para activar ese bucle a un minero. El minero procesará la transacción, que ejecuta el bucle infinito, y esperará a que se quede sin gas. A pesar de que la ejecución se queda sin gasolina y se detiene a medio camino, la transacción sigue siendo válida y el minero todavía reclama la cuota del atacante para cada paso de cálculo.
• Un atacante crea un bucle infinito muy largo con la intención de obligar al minero mantener los cálculos durante tanto tiempo, que cuando éste termine unos cuantos bloques más se habrán generado y no va a serle posible incluir la transacción para reclamar la tarifa. Sin embargo, se requerirá al atacante presentar un valor para STARTGAS que limitará el número de pasos de cálculo que esta ejecución puede llevar a cabo, el minero sabe de antemano que el cálculo llevará un número excesivamente grande de pasos.
• Un atacante observa un contrato que tiene un código de la siguiente forma: send(A,contract.storage[A]); contract.storage[A] = 0, y envía una transacción con suficiente gas para ejecutar el primer paso pero no el segundo (por ejemplo, haciendo una retirado pero no dejando que el balance disminuya). El autor del contrato no necesita preocuparse de cómo protegerse contra estos ataques, porque la ejecución se parará a la mitad.
• Un contrato financiero funciona tomando la mediana de nueve fuentes de datos propietarias con el fin de minimizar el riesgo. Un atacante compromete una de estas fuentes de datos, que está diseñado para ser modificables a través del mecanismo de llamada de dirección de variable descrito en el apartado de los DAOs, y la convierte para ejecutar un bucle infinito, intentando de ese modo que cualquier intento de reclamar los fondos de el contrato financiero se quede sin gas. Sin embargo, el contrato financiero puede establecer un límite de gas en el mensaje para evitar este problema.

La alternativa a Turing complete es Turing incompleto o no completo, donde JUMP y JUMPI no existen y solamente una copia de cada contrato tiene permitido existir en la pila de llamadas en cada momento dado. Con este sistema, el sistema de tasas descrito y las incertidumbres alrededor de la eficacia de nuestra solución puede que no sea necesaria, ya que el costo de la ejecución de un contrato sería acotado superiormente por su tamaño. Además, Turing-incompleto ni siquiera es una limitación tan grande; de entre todos los ejemplos de contratos que hemos concebido internamente, hasta ahora sólo uno requiere un bucle, y hasta ese bucle podrían eliminarse al hacer 26 repeticiones de una pieza de una sola línea de código. Teniendo en cuenta las serias implicaciones de ser Turing completo, y el beneficio limitado, ¿por qué no simplemente tener un lenguaje Turing incompleto? En realidad, sin embargo, ser Turing incompleto está lejos de ser una solución ordenada al problema. Para ver por qué, considere los siguientes contratos:

C0: call(C1); call(C1);

C1: call(C2); call(C2);

C2: call(C3); call(C3);

…

C49: call(C50); call(C50);

C50: (ejecuta un paso de un programa y guarda el cambio en el almacén)

Ahora, envía una transacción a A. Así, en 51 transacciones, tenemos un contrato que toma 250 pasos de cálculo (o ejecución). Los mineros podrían tratar de detectar este tipo de bombas lógicas antes, manteniendo un valor, junto a cada contrato, que especifique el número máximo de pasos de cálculo que puede tener, y recalculándolo para contratos que a su vez llaman a otros contratos de forma recursiva, pero esto requeriría de los mineros el prohibir contratos que crearan otros contratos (la creación y ejecución de los 26 contratos anteriores podrían ser fácilmente agrupados en un solo contrato). Otro punto problemático es que el campo de dirección de un mensaje es una variable, por lo que en general, podría incluso no ser posible decir que otros contratos serán llamados desde un contrato determinado. De ahí que, considerándolo todo, tenemos una sorprendente conclusión: manejar el Turing completo es sorprendentemente fácil, y la falta de Turing completo es igualmente sorprendentemente difícil de manejar, a menos que, exactamente los mismos controles estén en su lugar – pero en ese caso ¿por qué no dejar simplemente que el protocolo sea Turing completo?

Moneda y Emisión

La red Ethereum incluye su propio sistema monetario, el ether, que tiene el doble objetivo de proporcionar una capa de liquidez primaria para permitir el intercambio eficiente entre los distintos tipos de activos digitales, y más importante, proporcionar un mecanismo para el pago de las comisiones por transacciones. Para mayor comodidad y evitar debates futuros (véase los debates en Bitcoin sobre el uso de mBTC/uBTC/satoshi), las denominaciones serán pre etiquetadas como:

• 1: wei
• 1012: szabo
• 1015: finney
• 1018: ether

Y que deben ser tomados como una versión ampliada del concepto de “dólares” y “centavos” o “BTC” y “Satoshi”. En un futuro cercano, esperamos que el “ether”  se utilice para transacciones ordinarias, “finney” para microtransacciones y “szabo” y “wei” para discusiones técnicas en torno a los honorarios y aplicación del protocolo; las denominaciones restantes pueden llegar a ser útiles más adelante y no deben ser incluidas en los clientes en este momento.

El modelo de emisión será como sigue:

• El ether se pondrá a la venta a un precio de entre 1000-2000 unidades de ether por BTC, un mecanismo destinado a financiar la organización Ethereum y a pagar el desarrollo. Esta opción ha sido utilizada con éxito por otras plataformas como Mastercoin y NXT. Los primeros compradores se beneficiarán de descuentos más grandes. Los BTC recibidos de esta venta serán utilizados en su totalidad para pagar sueldos y recompensas a los desarrolladores e invertir en diversos proyectos tanto con fines de lucro como sin ellos, dentro del ecosistema de las criptomonedas y Ethereum.
• 0.099x de la cantidad total vendida (60.102.216 ETH) se destinarán a la organización para compensar a los primeros contribuyentes y pagar los gastos denominados en ETH antes del bloque génesis.
• 0.099x de la cantidad total vendida se mantendrá como reserva a largo plazo.
• Después de ese punto, el 0.26x de la cantidad total vendida se destinará a los mineros por año para siempre.

Tasa Crecimiento y Suministro a Largo Plazo (porcentaje)

A pesar de seguir una emisión de moneda lineal, al igual que con Bitcoin, con el tiempo la tasa de crecimiento de la oferta tiende a cero.

Las dos opciones principales del anterior modelo son (1) la existencia y el tamaño de una piscina de dotación, y (2) la existencia de un suministro lineal permanentemente creciente, en oposición a un suministro cerrado como en Bitcoin. La justificación de la piscina de dotación es la siguiente. Si no existiera, y la emisión lineal se redujese a 0.217x para poder proporcionar la misma tasa de inflación, entonces la cantidad total de ether sería un 16,5% menor y entonces cada unidad sería 19,8% más valiosa. Por lo tanto, para mantener el equilibrio es necesario comprar un 19,8% más de ether en la venta, por lo que cada unidad vuelve a ser, una vez más, exactamente tan valiosa como antes. La organización también tendría entonces 1.198x como mucho en BTC, y que puede considerarse que estaría dividido en dos partes: los BTC originales, y el 0.198x adicional. Esta situación es exactamente equivalente a la dotación, pero con una diferencia importante y es que la organización mantiene únicamente BTC, por lo que no está incentivada en apoyar el valor de la unidad de ether.

El modelo permanente de crecimiento lineal de la oferta reduce el riesgo de lo que algunos ven como una concentración excesiva de la riqueza en Bitcoin, y da a los individuos que viven tanto en el presente como en eras futuras, una buena oportunidad para adquirir unidades de moneda, mientras que al mismo tiempo conserva un fuerte incentivo para obtener y mantener ether porque la “tasa de crecimiento de la oferta” como porcentaje tenderá a cero con el tiempo. También teorizamos que, debido a que siempre existen monedas que se pierden con el tiempo debido a negligencias, muerte, etc, esta pérdida puede modelarse como un porcentaje en la oferta total por año, de este modo y con el tiempo, el suministro de divisas totales en circulación, se estabilizará en un valor igual a la emisión anual dividido por la tasa de pérdida (por ejemplo, con una tasa de pérdida del 1%, una vez que el suministro de moneda alcance el 26X entonces, se creará un equilibrio entre el  0,26X que será minado, y los otros 0,26X que se perderían cada año).

Tenga en cuenta que en el futuro, es probable que Ethereum cambie a un modelo de prueba de participación (proof of stake) por seguridad, reduciendo el requisito de emisión hasta algún punto entre cero y 0.05x por año. En el caso de que la organización Ethereum perdiera financiación o por cualquier otra razón desapareciera, se deja abierto un “contrato social” en donde cualquier persona tiene derecho a crear una futura versión candidata de Ethereum, con la única condición de que la cantidad de ether debe ser como máximo igual a 60102216 * (1,198 + 0,26 * n) donde n es el número de años después del bloque génesis. Los creadores son libres de vender, ceder parte o la totalidad de la diferencia entre la expansión de la oferta PoS-accionaríada y la ampliación máxima permisible como pago por el desarrollo. Las actualizaciones candidatas que no cumplan con el contrato social pueden ser bifurcadas justificadamente a versiones compatibles.

Centralización de la Minería

El algoritmo de minería Bitcoin funciona usando mineros que ejecutan la función SHA256, sobre versiones ligeramente modificada de la cabecera de un bloque, millones de veces una y otra vez, hasta que finalmente uno de ellos obtine una versión válida cuyo hash es inferior al objetivo (en la actualidad alrededor de 2192). Sin embargo, este algoritmo de minería es vulnerable a dos formas de centralización. En primer lugar, el ecosistema de la minería ha llegado a ser dominado por ASIC (circuitos integrados de aplicación específica), que son chips de computadora diseñados para este propósito, y por tanto miles de veces más eficientes en la tarea específica de la minería Bitcoin. Esto significa que la minería Bitcoin ya no es una actividad altamente descentralizada e igualitaria, sino que se requiere de millones de dólares de capital para poder participar de manera efectiva. En segundo lugar, la mayoría de los mineros Bitcoin en realidad no realizan una validación del bloque localmente sino que utilizan una piscina (pool) de minería centralizada para proporcionar las cabeceras de los bloques. Este problema es posiblemente peor: en el momento de escribir esto, los tres principales grupos mineros controlan indirectamente aproximadamente el 50% de la potencia de procesamiento de la red Bitcoin, aunque esto se ve mitigado por el hecho de que los mineros pueden cambiar a otras piscinas mineras si una piscina o coalición intentará un ataque de 51%.

La intención actual en Ethereum es utilizar un algoritmo de minería donde se requiere que los mineros busquen datos aleatorios del estado, calculen algunas transacciones seleccionadas al azar de los últimos N bloques en la cadena de bloques, y devuelvan el hash del resultado. Esto tiene dos beneficios importantes. Primero, los contratos de Ethereum pueden incluir cualquier clase de computación, por tanto, un ASIC Ethereum esencialmente sería un ASIC para computación general, por ejemplo una mejor CPU. Segundo, la minería requiere acceder a toda la cadena de bloques, forzando a los mineros a almacenarla por completo y al menos ser capaces de verificar cada transacción. Esto elimina la necesidad de pools de minería centralizados, y aunque pueden todavía servir para el papel legítimo de la distribución aleatoria de la recompensa, esta función puede ser realizada igualmente bien con una piscina de igual a igual (peer-to-peer) sin ningún control central.

Este modelo no está probado, y puede haber dificultades a lo largo del camino para evitar ciertos tipos de optimizaciones inteligentes como usar la ejecución de un contrato como algoritmo de minería. Sin embargo, una interesante y notable característica de este algoritmo es que permite a cualquiera “envenenar el pozo” mediante la introducción de un gran número de contratos en la cadena de bloques específicamente diseñados para bloquear ciertos ASICS. Los incentivos económicos que existen para los fabricantes ASIC podrían motivar usar tal truco para atacarse unos a otros. Por tanto, la solución que estamos desarrollando es, en última instancia, una solución humana de adaptación económica  más que una puramente técnica.

Escalabilidad

Una preocupación común acerca de Ethereum es el tema de la escalabilidad. Al igual que Bitcoin, Ethereum adolece del defecto de que cada transacción debe ser procesada por cada nodo de la red. Con Bitcoin, el tamaño de la blockchain actual está alrededor de 15 GB, creciendo cerca de 1 MB por hora. Si la red Bitcoin tuviera que procesar 2000 transacciones por segundo del tipo VISA, crecería a razón de un 1 MB cada tres segundos (1 GB por hora, 8 TB por año). Ethereum es probable que sufra un patrón de crecimiento similar, agravada por el hecho de que habrá muchas aplicaciones en la parte superior de la cadena de bloques de Ethereum, en lugar de sólo una moneda como es el caso de Bitcoin, pero mejorada por el hecho de que en Ethereum los nodos completos sólo necesitan almacenar el estado en lugar de toda la historia de la cadena de bloques.

El problema con un tamaño tan grande de la cadena de bloques es el riesgo de la centralización. Si el tamaño de ésta aumentará a, digamos, 100 TB, el escenario más probable sería que sólo un número muy reducido de grandes empresas correría nodos completos, con todos los usuarios regulares utilizando nodos ligeros del tipo SPV. En tal situación, surge la preocupación potencial que estos nodos completos podrían unirse y ponerse de acuerdo para engañar de alguna manera que resultara rentable (por ejemplo, cambiar la recompensa en BTC por bloque que reciben). Los nodos ligeros no tendrían forma de detectar esto inmediatamente. Por supuesto, es probable que exista al menos un nodo completo honesto, y es seguro que después de algunas horas la información sobre el fraude podría aparecer y filtrarse a través de canales como Reddit, pero en ese momento ya sería demasiado tarde: y aunque los usuarios comunes podrían organizarse para crear una lista negra con estos bloques, estaríamos ante un problema que implicaría un movimiento de coordinación masiva y probablemente inviable, con una escala similar a la de un ataque del 51% exitoso. En el caso de Bitcoin, esto es actualmente un problema, aunque existe una modificación para la cadena de bloques sugerida por Peter Todd que lo aliviaría.

En el corto plazo, Ethereum utilizará dos estrategias adicionales para hacer frente a este problema.Primero, debido a los algoritmos de minado basados en la cadena de bloques, cada minero estaría forzado a ser un nodo completo, lo que ya crearía una cota mínima en este número de nodos. En segundo  lugar y más importante, incluiremos un estado intermedio en la raíz del árbol en la cadena de bloques después de procesar cada transacción. Incluso si la validación de un bloque es centralizada, mientras exista un nodo de verificación honesto el problema de la centralización puede eludirse mediante un protocolo de verificación. Si un minero publica un bloque inválido, lo será porque el bloque está o mal formado o el estado S[n] es incorrecto. Dado que se conoce que S[0] es correcto, debería haber algún estado inicial S[i] que es incorrecto pero donde S[i-1] es correcto. El nodo de verificación proporcionaría el indice i, junto con una “prueba de invalidez”  que consistiría en un subconjunto de nodos del árbol Patricia que necesitarían procesar la función APPLY(S[i-1],TX[i]) -> S[i]. Los nodos serían capaces de usar estos nodos para ejecutar esa parte de ejecución y ver que el S[i] generado no coincide con el S[i] proporcionado.

Otro ataque más sofisticado, sería involucrar a mineros maliciosos para que publicaran bloques incompletos, de este modo ni siquiera existiría información completa para determinar si son o no válidos. La solución a esto es un protocolo del tipo desafío-respuesta: los nodos de verificación emitirían “desafíos” en forma de índices de transacción de destino, un nodo ligero trataría el bloque como que no es de confianza hasta que otro nodo, un minero u otro verificador, proporcione un subconjunto de nodos Patricia como prueba de su validez.

Conclusiones

El protocolo Ethereum fue originalmente concebido como una versión actualizada de criptomoneda, proporcionando características avanzadas como: las garantías dentro de la cadena de bloques, los límites de retirada, los contratos financieros, los juegos de azar y aplicaciones similares a través de un lenguaje de programación generalizado. El protocolo Ethereum no “soporta” ninguna de las aplicaciones directamente, pero la existencia de un lenguaje de programación del tipo Turing-completo significa que todo contrato arbitrario puede, teóricamente, crearse para cualquier tipo de transacción o aplicación. Sin embargo lo que es más interesante de Ethereum es que el protocolo va más allá de ser solamente una moneda. Protocolos sobre almacenamiento de archivos descentralizado, computación descentralizada y la predicción de mercados descentralizados, entre otra docena de conceptos, tienen el potencial de incrementar sustancialmente la eficiencia de la industria computacional, y proporcionar un gran impulso a otros protocolos peer-to-peer añadiendo por primera vez una capa económica. Por último, también hay una variedad considerable de aplicaciones que no tienen nada que ver con el dinero en absoluto.

El concepto de una función de transición de estados, arbitraria e implementada como es proporcionada por el protocolo Ethereum, facilita una plataforma con un potencial único. En lugar de ser un protocolo de propósito único y cerrado, destinado a un conjunto específico de aplicaciones en el ámbito del almacenamiento de datos, los juegos de azar o las finanzas, Ethereum es, por diseño, abierto y creemos que puede muy bien adaptarse como una capa fundacional para un gran número de aplicaciones tanto financieras como no financieras que vendrán en los próximos años.

Notas y Lecturas Adicionales

Notas

1. Un lector avanzado notará que de hecho una dirección Bitcoin es el hash de la clave pública de una curva elíptica, y no la clave pública en si misma. Sin embargo, es de hecho perfectamente legítimo en la terminología criptográfica referirse al hash de la pubkey como clave pública. Esto es porque la criptografía de Bitcoin puede ser considerada como un algoritmo de firma digital personalizada, donde la clave pública consiste en el hash de la pubkey ECC. La firma consiste en la pubkey ECC concatenada con la firma ECC, el algoritmo de verificación implica comprobar la pubkey ECC en la firma contra el hash de la pubkey que la ECC proporciona como clave pública y luego verificar la firma ECC contra la pubkey ECC.
2. Tecnicamente, la media de los 11 bloques previos.
3. Internamente, 2 y “CHARLIE” son ambos números, este último representado en formato big-endian base 256. Los numerous pueden estar entre 0 y un máximo de 2256-1.

Lecturas Adicionales

1. Intrinsic value:http://bitcoinmagazine.com/8640/an-exploration-of-intrinsic-value-what-it-is-why-bitcoin-doesnt-have-it-and-why-bitcoin-does-have-it/
2. Smart property:https://en.bitcoin.it/wiki/Smart_Property
3. Smart contracts:https://en.bitcoin.it/wiki/Contracts
4. B-money:http://www.weidai.com/bmoney.txt
5. Reusable proofs of work:http://www.finney.org/~hal/rpow/
6. Secure property titles with owner authority:http://szabo.best.vwh.net/securetitle.html
7. Bitcoin whitepaper:http://bitcoin.org/bitcoin.pdf
8. Namecoin:https://namecoin.org/
9. Zooko’s triangle:http://en.wikipedia.org/wiki/Zooko’s_triangle
10. Colored coins whitepaper:https://docs.google.com/a/buterin.com/document/d/1AnkP_cVZTCMLIzw4DvsW6M8Q2JC0lIzrTLuoWu2z1BE/edit
11. Mastercoin whitepaper:https://github.com/mastercoin-MSC/spec
12. Decentralized autonomous corporations, Bitcoin Magazine:http://bitcoinmagazine.com/7050/bootstrapping-a-decentralized-autonomous-corporation-part-i/
13. Simplified payment verification:https://en.bitcoin.it/wiki/Scalability#Simplifiedpaymentverification
14. Merkle trees:http://en.wikipedia.org/wiki/Merkle_tree
15. Patricia trees:http://en.wikipedia.org/wiki/Patricia_tree
16. GHOST:http://www.cs.huji.ac.il/~avivz/pubs/13/btc_scalability_full.pdf
17. StorJ and Autonomous Agents, Jeff Garzik:http://garzikrants.blogspot.ca/2013/01/storj-and-bitcoin-autonomous-agents.html
18. Mike Hearn on Smart Property at Turing Festival:http://www.youtube.com/watch?v=Pu4PAMFPo5Y
19. Ethereum RLP:https://github.com/ethereum/wiki/wiki/%5BEnglish%5D-RLP
20. Ethereum Merkle Patricia trees:https://github.com/ethereum/wiki/wiki/%5BEnglish%5D-Patricia-Tree
21. Peter Todd on Merkle sum trees:http://sourceforge.net/p/bitcoin/mailman/message/31709140/

—–

NOTAS INCLUIDAS PARA CLARIFICAR LA TRADUCCIÓN

[1] Se estaría refiriendo a la existencia de las propiedades value-blindness y blockchain-blindness que en este caso si estarían incluídas en Ethereum.

[2] Ethereum Virtual Machine

[3] Hay quien traduce los tokens en español por fichas, pero creo que es más correcto definirlos como “testigos” con la idea de que actúa como algo simbólico y representan un testimonio dentro del sistema Ethereum.

[4] Preferimos dejar por claridad las siglas inglesas DAO que su equivalente en español OAD.

[5] La Democracia Líquida también es lo mismo que Democracia Delegativa Revocable

[6] Tal vez en español sería más exacto hablar de roles o capacidades.

[7] He traducido la palabra inglesa “futarchy” como “futarquía”, porque no he encontrado un término en español equivalente, de hecho, dudo que exista. Hace referencia a una forma de gobierno, propuesta por Robin Hanson que utilizan medidas de bienestar y los mercados de predicción nacionales para determinar qué políticas tendrán el efecto más positivo.

[8] Este problema es muy conocido y se aplica a las máquinas de Turing.

Fuente de la Traducción: (Traducción Santiago Márquez Solís @smarquezsolis – smarquezsolis@gmail.com) https://es.linkedin.com/pulse/ethereum-whitepaper-traducido-al-castellano-santiago-m%C3%A1rquez-sol%C3%ADs

La presente es una transcripción de su original. PandectasDigital no se hace responsable por cualquier discrepancia u omisión contenida en ella, ni por los daños o perjuicios que pudieran causarse por su uso, ni por su reproducción total o parcial.

A continuación, su versión en idioma original publicada en www.ethereum.org:

Oprime AQUÍ para descargar el documento

[Instrucciones para la DESCARGA GRATUITA] 

Oprime AQUÍ para descargar el documento

[Instrucciones para la DESCARGA GRATUITA]