Las 4 Etapas o Fases de Ethereum

Para llevar a buen término un proyecto, sea éste grande o pequeño, se debe definir una hoja de ruta, definiendo los pasos y las fases a seguir, las cuales serán su particular brújula en el camino hacia el éxito.

Aún y así, siempre que se camina sobre un terreno que no se ha andado antes, se dan periodos de dudas e incertidumbre. Por lo tanto, la necesidad de adaptarse a los cambios que vienen en el futuro es vital.

El proyecto Ethereum en ese aspecto no es diferente a otros.

Desde su creación se han tomado su particular hoja de ruta muy en serio. Si bien es verdad que no había fechas específicas marcadas para avanzar en dicha hoja de ruta, se han ido dando los pasos necesarios conforme se creía oportuno, siempre desde el punto de vista de la viabilidad, la sensatez y la estabilidad.

Desde que se empezó la escritura del código de Ethereum, su fundador, Vitalik Buterin, sabía perfectamente lo que quería crear.

Tenía claro que su objetivo era lanzar una plataforma para descentralizar las interacciones entre seres humanos en campos en los que se requería de una tercera parte para dar el visto bueno a una acción.

El ‘cómo’ lo iba a crear y los pasos a seguir vendrían después en forma de etapas.

La evolución de Ethereum se iba a dar en cuatro etapas, cada una de ellas con un objetivo claro y a la vez necesarias para el mantenimiento y correcto funcionamiento de Ethereum en el futuro.

Estas fases representan actualizaciones de protocolo dentro de la plataforma de Ethereum, o dicho de otro modo, cambios en las reglas bajo las que funciona Ethereum.

Estas nuevas reglas que se dan en cada actualización afectan a la funcionalidad de la plataforma y/o a sus estructuras de incentivos o recompensas.

Con cada etapa, Ethereum «sube de nivel» incorporando más y más propiedades, haciendo que su sistema sea más robusto y sin fisuras.

Estas cuatro etapas se llaman Frontier, Homestead, Metropolis y Serenity.

Pasamos a explicarlas en detalle a continuación:

Las cuatro etapas de Ethereum

Ethereum fue lanzado de forma oficial el 30 de Julio de 2015 y con él Frontier, la primera de las cuatro etapas de la hoja de ruta de la plataforma.

Se podría decir que Frontier fue la forma más básica de Ethereum ya que su función principal era la de hacer que la minería y el intercambio de Ether funcionasen. En otras palabras, “dar vida” al proyecto.

Esto se lograría principalmente a través de que la comunidad Ethereum cumpliera con las siguientes tareas:

• Iniciar plataformas de minería, adquiriendo el hardware (tarjetas gráficas -GPUs- y procesadores -CPUs-) y el software (clientes de minería como Geth) necesario.
• Probar aplicaciones descentralizadas -ÐApps- en el sistema.
• Obtener sus primeros Ether y usarlos para crear software propio. El crear estos programas propios basados en Ethereum tenía un coste.

Frontier era un software completo pero con un riesgo amplio de recibir comportamientos inesperados que puedan poner en peligro la plataforma.

Aparte de los mismos desarrolladores de Ethereum, toda la comunidad podía crear contratos, realizar intercambios de valor o minar la criptomoneda, y cualquiera de esos componentes que se pudiera estropear causaría impactos negativos a muchos usuarios y al sistema en general.

Por otro lado, la parte positiva que se daba en esta etapa para contrarrestar estos posibles sucesos era que Frontier era una fase reversible, lo que quiere decir que se podía volver atrás en la cadena de bloques y modificar información si se percibían fallos en el sistema.

A pesar de ello, no era recomendable por las vulnerabilidades de la plataforma en ese momento.

Al llegar a esta etapa, el mundo estará preparado para dar el siguiente gran salto, como lo dió con la introducción de Internet.

Dada la inestabilidad de esta primera etapa, tampoco era recomendable el uso de Ether en esta fase excepto para experimentar con contratos inteligentes y crear software en el sistema. Ese Ether había sido adquirido o bien comprándolo en la preventa al público, o bien como recompensa de la minería, que por aquel entonces se daba a razón de 5 Ethers por bloque minado.

Pese a las condiciones no favorables para su uso, los usuarios empleaban ese Ether que habían adquirido para realizar transacciones e intercambiarlos por otras criptomonedas como el Bitcoin.

Menos de un mes después de la entrada de Frontier, se dio un “hard fork”, que no es ni más ni menos que una modificación del protocolo que se venía usando hasta entonces, o dicho de otro modo, un cambio en las reglas para mejorar el sistema.

En este hard fork se introdujo lo que se denomina “Bomba de dificultad”. Esta bomba de dificultad fue introducida con la intención de incrementar exponencialmente la dificultad de la minería en Ethereum hasta el final de la tercera etapa en la hoja de ruta de Ethereum, llamada Metropolis.

Este incremento de la dificultad explicado de forma sencilla viene a decir que, con los mismos equipos que se utilizaban en Frontier para el minado de Ether, en las futuras etapas de Homestead y Metropolis funcionarán más lentos, o mejor dicho, no darán el mismo rendimiento que han venido dando anteriormente. Por lo tanto se necesitarán cada vez equipos más potentes para conseguir los mismos resultados que antes.

Un ejemplo de esto en la vida real se daría cuando sacan una actualización para el sistema operativo de nuestro teléfono móvil: las actualizaciones están preparadas para los últimos móviles sacados al mercado, no tanto para las versiones anteriores.

Si actualizas el sistema operativo de un móvil que no es nuevo, ese sistema operativo necesitará más potencia, pero como la potencia de nuestro móvil es limitada, hace que funcione más lento de lo que lo hacía antes con la versión anterior.

La bomba de dificultad tiene como objetivo pasar de un sistema de prueba de trabajo (PoW, del inglés Proof-of-Work) a un sistema prueba de participación (PoS, del inglés Proof-of-Stake).

Explicado de otra forma, esta bomba de dificultad está pensada para que en vez de que los mineros reciban Ethers según la potencia a la que trabajen sus máquinas, los reciban de forma directamente proporcional a los Ether que ya tienen.

Esto tiene sentido ya que, si alguien tiene Ether significa que está interesado en la supervivencia y el buen funcionamiento del sistema Ethereum, por lo tanto los que más Ether tienen son los más indicados en asegurar el sistema contra posibles ataques.

Como consecuencia de ello, son los que tendrán menos dificultad para obtener Ethers en el proceso de minería.

Una vez aclarado el concepto de la bomba de dificultad, continuaremos con la idea general, que era ir mejorando Frontier entre toda la comunidad, haciéndolo cada vez más estable y más seguro a ojos de los principales desarrolladores de software.

Una vez fuera estable se moverían hacia la siguiente etapa marcada en la hoja de ruta: Homestead.

De esta forma Frontier se cerraría por completo, garantizando el valor de los Ether adquiridos por cada usuario en dicha etapa, pero perdiendo los cambios realizados en los contratos inteligentes.

El cambio de Frontier a Homestead se dió el 14 de Marzo de 2016, justo a partir de que el bloque número 1.150.000 de la blockchain de Ethereum fuera minado.

Como se dijo desde el mismo equipo que forma Ethereum,

“Homestead marca la salida de un producto beta (Frontrier) a una versión estable (Homestead)”.

Admitieron también que ya podían añadir la calificación de “seguro” a su proyecto.

Esta mudanza hacia esta nueva etapa llevaba también consigo una actualización de Geth y otros clientes Ethereum (también conocidos como nodos de la red Ethereum).

La consecuencia de no actualizar a tiempo a esta nueva etapa sería que los nodos seguirían anclados en Frontier, es decir, no estarían sincronizados con el resto de la red y estarían minando en una cadena de bloques anticuada y, por tanto, inservible.

Uno de los cambios significativos en esta nueva actualización fue el incremento del coste para la creación de contratos inteligentes. Como hemos mencionado, crear contratos inteligentes basados en Ethereum o realizar transacciones dentro de la plataforma tenía un coste.

Este coste se llama ‘gas’ y es variable: depende directamente de lo que cueste realizar dicha acción en el sistema. El gas es el equivalente a las comisiones que se cobran hoy en día en los bancos.

Por ejemplo: Si mandar un Ether de una cuenta a otra tiene un gasto de computación -en gas- equivalente a 0.0001 Ether, entonces realizar dicha transacción costará 1.0001 Ether (1 Ether enviado + 0.0001 de comisión).

Aparte de este incremento de las comisiones en las transacciones de Ethereum, con Homestead se consiguieron corregir errores que podrían dar lugar a transacciones maliciosas para el sistema.

También se aseguró que los nodos de Ethereum, esos ‘clientes’ como el anteriormente mencionado Geth, pudieran hacer frente a futuras actualizaciones de protocolo. Pero sin duda uno de los principales añadidos de esta actualización es la introducción de ‘Mist’.

Mist es un navegador muy potente basado en Ethereum. Se podría decir que es como el Google Chrome de Ethereum pero con propósitos especiales, como poder interactuar con los elementos de la cadena de bloques (los contratos inteligentes, el Ether, etc).

Además ofrece la posibilidad de ejecutar y gestionar ÐApps en la cadena de bloques para gente que no es muy amiga de los aspectos técnicos de Ethereum, o en otras palabras, que no maneja la línea de comandos.

Pese al añadido de Mist, en Homestead se sigue usando de forma mayoritaria la programación en línea de comandos, al igual que se hacía en Frontier. Mist es solo una versión beta de esa interfaz gráfica que tiene como objetivo acercar Ethereum, no solo a los que dominan los aspectos técnicos de la plataforma, sino al resto de público.

Al igual que había cosas que se mantenían como la programación en línea de comandos, otro aspecto que seguía igual que en la anterior fase es la recompensa por cada bloque minado, que era de 5 Ether.

Esta etapa de la hoja de ruta estaba pensada para que durase menos del tiempo que duró. Desde el equipo de Ethereum han ido solventando problemas y mejorando el sistema hasta que se estabilizó, tal y como pasó con Frontier.

Mientras todo esto se iba llevando a cabo, también se preparaban para dar el siguiente salto en su hoja de ruta preestablecida: Metropolis.

Tardó en llegar pero llegó. El 16 de Octubre de 2017, a la altura del bloque 4.370.000 comenzó la nueva etapa de Ethereum: Metrópolis. Esta etapa estará marcada por dos sub-etapas llamadas Byzantium y Constantinople.

Estas dos sub etapas son dos hard fork, que como ya sabemos, son modificaciones de esas reglas por las que se rige el sistema, llamadas protocolo.

El comienzo de Metrópolis viene de la mano con ese primer hard fork, Byzantium, el cual nos trae varias características principales que separaremos en secciones y explicaremos detalladamente.

Una de ellas es la reducción de la “Bomba de dificultad” introducida en la etapa de Frontier.

Como hemos explicado anteriormente, esta bomba de dificultad tiene como objetivo el aumento de dificultad en la minería a través del sistema ‘prueba de trabajo’, es decir, por la vía en la que lo más importante es la potencia de los equipos que utilicemos para el minado de Ether.

Esta reducción traerá como consecuencias directas las siguientes:

• Al reducir la dificultad del minado, también se reduce el tiempo de creación de bloques de 24.5 segundos a unos 14 segundos. Menos dificultad en el proceso nos lleva a mayor rapidez del proceso.
• Junto con esta reducción del tiempo por bloque, también se reducen las recompensas recibidas por los mineros de cada bloque, que pasa de los 5 Ether por bloque minado a 3 Ether. Esto es un cambio significativo porque la recompensa llevaba siendo 5 Ether desde el principio de Ethereum.

La reducción de la bomba de dificultad será de 18 meses aproximadamente desde la fecha de entrada de Metrópolis, dicho desde el equipo de desarrollo de Ethereum.

Se espera que, pasados esos 18 meses, se vuelva a incrementar la dificultad como estaba previsto, poniendo en marcha la transición al sistema de minado por prueba de participación, y a la última etapa de la hoja de ruta: Serenity.

Otra de las características añadidas de Metropolis en su fase Byzantium es la actualización del lenguaje de programación Solidity. Este lenguaje de programación está orientado a la creación de smart contracts y ÐApps en cadenas de bloques como Ethereum.

De hecho, fue creado por varios desarrolladores que también participaron en la creación de Ethereum.

La idea principal es la de simplificar este lenguaje para que programadores menos experimentados puedan también desarrollar contratos inteligentes y aplicaciones descentralizadas de una forma más simple y sencilla.

Los Zk-Snarks son las siglas de “Zero-Knowledge Succint Non-interactive Argument of Knowledge”, que de forma resumida, viene a significar en castellano “Prueba de Cero Conocimiento” (PCC).

Estos Zk-Snarks son un conjunto de reglas mediante las cuales una parte (el probador) puede demostrar a otra parte (el verificador) que una información es verdadera, sin que el verificador sepa de qué información se trata, solamente sabiendo que es verdadera.

Explicaremos esto con una historia, a modo de ejemplo:

Carlos (el probador) y Pablo (el verificador) están en el centro de un laberinto, al cual se puede llegar por dos caminos diferentes, A y B. Solo existe una única salida del laberinto, la cual está protegida por una puerta con contraseña.

Carlos le dice a Pablo que sabe el camino y la contraseña para salir, pero Pablo no le cree. Por eso, ambos establecen un contrato en el que Pablo le pide a Carlos una prueba sobre la existencia de esa puerta y que éste sabe la contraseña para salir del laberinto, sin necesidad de revelar esa contraseña. Pablo quiere que Carlos le traiga su balón, que está fuera del laberinto.

Carlos deberá tomar el camino ‘A’ desde el centro del laberinto, abrir la puerta con la contraseña, coger el balón de Pablo, y volver al centro del laberinto por el camino ‘B’. Si Carlos sale desde el camino ‘B’, deberá volver por el camino ‘A’. De este modo Pablo sabrá que Carlos conoce ambos caminos y la contraseña para salir del laberinto, sin necesidad de saber él ningún camino ni la contraseña.

Para poder ejecutar los zk-Snarks, la transacción tiene que cumplir tres requisitos:

1. Integridad: Si la declaración es verdadera, entonces un verificador íntegro y honesto puede confiar en un probador íntegro y honesto. Ejemplo: Si Carlos conoce el camino, la contraseña y trae el balón a Pablo, Pablo puede confiar en la integridad y honestidad de Carlos.
2. Solidez: Si el probador no es honesto y miente, no puede convencer al verificador de ninguna manera. Ejemplo: Si Carlos dice que sabe el camino y la contraseña, pero no trae el balón a Pablo, éste no podrá confiar en la solidez de las palabras de Carlos. Lo que Carlos afirma saber no es sólido, porque no lo puede demostrar.
3. Cero conocimiento: Si la declaración es verdadera, el verificador no tendrá idea de la declaración en sí. Ejemplo: Si Carlos sabe el camino, la contraseña y trae el balón a Pablo, Pablo seguirá sin saber cual es la contraseña. Tendrá “cero conocimiento” del camino y de la contraseña, pero sabrá que Carlos es de fiar.

Este protocolo de los zk-Snarks ya había sido implementado en ZCash, una criptomoneda cuya característica principal es la que hemos explicado anteriormente: la privacidad.

El añadirlo a la plataforma Ethereum muestra un avance realmente significativo ya que permite realizar transacciones de forma completamente privada, aumentando así el anonimato en la red.

El concepto de abstracción se refiere a que cualquier persona pueda utilizar un sistema sin necesidad de conocer ni entender los detalles técnicos que lo hacen posible.

Explicaremos esto con un ejemplo fácil de entender:

Hoy en día casi todo el mundo utiliza los teléfonos inteligentes basados en aplicaciones. Si se quiere abrir el Whatsapp para mandar un mensaje, simplemente pulsamos en el icono de la aplicación, esta se abre, abrimos una conversación y mandamos un mensaje.

Nadie se para en conocer ni comprender cómo fue programado el Whatsapp ni qué instrucciones necesita seguir el teléfono para hacer eso posible.

O por ejemplo, cuando se quiere hacer una foto, ¿por qué cuando pulsamos en el icono de la cámara se activa la cámara?

Esta pregunta nos puede parecer ridícula ya que nos parece lógico que si pulsamos el icono ‘cámara’ se active la cámara, pero no sabemos qué lo hace posible, ni cómo lo hace posible. Ni siquiera nos interesa saberlo, sólo nos interesa que funcione.

Eso es la abstracción, dar énfasis al concepto “¿qué hace?” en vez de al concepto “¿cómo lo hace?”.

Esto nos trae la posibilidad de hacer accesible para la gente tecnología compleja eliminando esas complejidades y simplificándola al máximo.

Sin ir más lejos, Ethereum y su blockchain: una tecnología avanzada a su tiempo, la cual pretende ser simplificada hasta los límites de que alguien la esté usando sin siquiera saberlo o comprender su funcionamiento.

Ethereum tiene el objetivo de que todos usen aplicaciones descentralizadas (ÐApps) sin que sepan que están basadas en Ethereum, es decir, haciéndolo “desaparecer” de la acción en sí.

El primer paso que se va a dar en esta dirección es lo que se llama “Account Abstraction” o Abstracción de cuenta.

Ethereum, en cuanto a su escritura, tiene dos tipos de cuenta:

• Carteras o Wallets: cuentas externas controladas por llaves privadas conocidas por los usuarios.
• Contratos inteligentes: cuentas internas controladas por código de programación.

La idea de la abstracción de cuenta es que los usuarios puedan configurar sus carteras para que funcionen de forma similar y tan flexible como los contratos inteligentes.

Esto hace que las transacciones sean más seguras y sencillas de ejecutar, dándole a los usuarios más control sobre sus cuentas y contraseñas privadas.

Ya sabemos cómo funcionan los contratos inteligentes al igual que sabemos que ejecutarlos requiere de una comisión.

Recordamos que esta comisión llamada “gas” no es más que un gasto computacional, es decir, el gasto energético que realizan los equipos informáticos por procesar la información.

Este “gas” es variable: será mayor o menor dependiendo de lo que le cueste al equipo procesar la transacción; y se paga en Ether.

Cada contrato inteligente tiene su propio límite de gas, que es fijado por el proveedor del contrato. Esto puede llevar a dos escenarios diferentes:

1. El gas requerido es superior al límite establecido. Si ocurre esto, el contrato no se ejecuta. A pesar de que no haber realizado la acción con éxito, se agota y se paga todo el gas, puesto que el gasto computacional ha sido realizado.
2. El gas requerido es menor que el límite establecido. Si se da este caso, el contrato se completa y el gas sobrante se entrega al proveedor del contrato.

Expliquemos esto con un ejemplo:

Marta fija las condiciones de un contrato inteligente, aceptadas por Juan, en las que el límite que se fija Marta es de 50.000 gas.

• Si el gas requerido para ejecutar ese contrato es de 70.000, entonces el contrato no se ejecutará, y Marta habrá perdido el correspondiente en Ether de los 50.000 gas.
• Si el gas requerido para ejecutar el contrato es de 30.000, entonces el contrato es ejecutado, y los 20.000 gas restantes se entregarán, en forma de Ether, a Marta.

Durante la ejecución de un contrato, si una de las dos partes quiere cancelar una transacción realizada, es decir, si quiere volver uno o varios pasos atrás en el proceso, entonces se tendrá que gastar el doble de gas.

¿Por qué? Porque ya pasan a ser dos transacciones (la que se ha hecho y otra para revertir la que ya se ha hecho), con el correspondiente consumo de gas por cada transacción.

Antes de Metrópolis, para revertir un contrato a su estado original, los desarrolladores usaban la función «throw«. Esta función ayuda al estado del contrato a volver al estado anterior, pero consume todo el gas del contrato, lo cual es un punto negativo.

No obstante, con la introducción de Metropolis, se incorporan dos funciones que ayudarán a contrarrestar estos problemas.

1. Una de ellas es la función “Revert” (revertir), que ayuda a que los contratos vuelvan a su estado inicial sin necesidad de consumir todo el gas del contrato. Además el gas no utilizado en el contrato será devuelto al creador del contrato.
2. La otra función es “Return data” (Devolución de datos), que lo que hace es permitir a los contratos no necesariamente volver a su estado inicial, sino modificar solo pequeños datos que no tengan un consumo de gas tan grande como el de volver al estado inicial del contrato. En otras palabras, si la función “revert” devuelve al estado original el contrato inteligente, la función “return data” solo modifica pequeñas partes de ese contrato.

–

Todas estas nuevas características de Metrópolis son solo el comienzo, ya que, como comentamos al principio, Metropolis entró con la primera de sus dos divisiones: Byzantium.

La siguiente división, Constantinople se dará cuando Byzantium sea 100% estable y fuera de errores, y nos traerá entre otras cosas, la reactivación de la bomba de dificultad como característica más significativa.

Todo ello está por ver.

Hoy en día sabemos que Serenity es la última estación en la hoja de ruta de Ethereum.

También sabemos que con la entrada de Serenity se dará el paso definitivo de PoW (Prueba de trabajo) a PoS (Prueba de participación), paso que hemos explicado de forma breve y con ejemplos en la etapa ‘Frontier’.

Al tratarse de un paso futuro, el cual no tiene una fecha establecida para entrar en vigor, no se conocen muchas más cosas que las ya mencionadas. Al igual que los desarrolladores de Ethereum han ido aprendiendo sobre la marcha, introduciendo modificaciones, variando fechas previstas y demás cambios, el paso a Serenity no estará exento de estas situaciones.

No obstante lo que se busca con Serenity, que viene del inglés ‘Serenidad’, es precisamente eso: encontrar la estabilidad del proyecto, de la comunidad y de su sistema, consiguiendo expandir la tecnología Ethereum a lo largo y ancho del planeta.

Al llegar a esta etapa, el mundo estará preparado para dar el siguiente gran salto, como lo dió con la introducción de Internet.