Historia de Ethereum

Nic0

Ethereum fue originalmente concebido por Vitalik Buterin a finales del 2013, como resultado de sus investigaciones en torno a lo que él consideraba limitaciones intrínsecas de la red Bitcoin. Poco tiempo después, en noviembre de 2013, Vitalik procedería a publicar el Whitepaper, en el que se describía de forma más detallada los diversos aspectos técnicos de Ethereum, así como las motivaciones que lo habían empujado a proponer el desarrollo de un nuevo protocolo con una arquitectura centrada en la ejecución de smart contracts. Y ya en enero de 2014, el concepto sería formalmente anunciado por el propio Vitalik en la North American Bitcoin Conference celebrada en Miami.

Al aprovechar ciertos aspectos técnicos de la blockchain de Bitcoin y combinarlos con la tecnología smart contract, Vitalik pretendía desarrollar una plataforma que no sólo fuera idónea para la transmisión de valor digital de una forma descentralizada, resistente a la censura y hasta cierto punto inmutable; sino que fuera capaz también de añadir programabilidad al concepto de “dinero”. Introduciendo la lógica condicional como ingrediente al descubrimiento de Satoshi Nakamoto, Ethereum abría un enorme abanico de posibilidades en relación con el desarrollo de apps descentralizadas -especialmente, las de tipos financiero.

En torno a esa misma época, Vitalik empezaría a trabajar de forma conjunta con el Dr. Gavin Wood en el desarrollo de la plataforma. Este último publicaría el Ethereum Yellow Paper en 2014, documento que serviría como especificación técnica de la Ethereum Virtual Machine, y que llevaría a la implementación del cliente de la plataforma en 7 lenguajes de programación distintos (C++, Go, Python, Java, JavaScript, Haskell y Rust).

La puesta en marcha de Ethereum no sólo implicaba el desarrollo de un software, sino también el lanzamiento de una nueva criptomoneda y una blockchain propia. Con el objetivo de reunir los recursos necesarios para congregar a una importante comunidad de desarrolladores, mineros e inversores, Ethereum decidió llevar a cabo una preventa de sus tokens nativos, denominados ether, y concebidos como unidad monetaria oficial de la plataforma. La complejidad legal y financiera que entrañaba una recaudación de fondos a través de una preventa condujo a la creación de diversas entidades (inicialmente, la Ethereum Switzerland GmbH; y ya en junio del 2014, la Ethereum Foundation, con base en Zug, Suiza).

La preventa de Ethereum se ejecutaría entre el 22 de julio y el 2 de septiembre de 2014 (es decir, a lo largo de un total de 42 días). El precio inicial de ether se situaría en 2000 unidades del token por cada BTC, y se mantendría estable durante 14 días, tras los cuales, se incrementaría gradualmente hasta alcanzar los 1337 ETH por cada BTC.

En total se crearían 60 millones de ether, de los cuales, un 80% se pondrían a disposición de los creadores, mientras que el 20% restante (12 millones de tokens) serían retenidos por el “fondo de desarrollo” de la Ethereum Foundation -conformado por los contribuidores iniciales del proyecto y los desarrolladores. El proceso de preventa acabaría recaudando unos 31,591 BTC (aproximadamente 18,4 millones de dólares), pero el ether generado no podría ser usado ni transferido hasta el lanzamiento del bloque génesis -que finalmente se produciría el 30 de Julio de 2015.

Tras el exitoso proceso de recaudación de fondos vía preventa de ether, el desarrollo de la plataforma se asignaría a una organización sin ánimo de lucro denominada ETH DEV y que actuaría bajo contrato de la Fundación. El interés de los desarrolladores respecto a Ethereum se incrementaría a lo largo de la segunda mitad del 2014 y, por entonces, el equipo de ETH DEV lanzaría varios proof-of-concept (POC) para que fueran sometidos a escrutinio por la comunidad.

En noviembre de 2014 se celebraría la primera convención mundial de desarrolladores de Ethereum en Berlín, la DEVCON 0. Un evento de enorme trascendencia, puesto que algunas de las presentaciones de los asistentes acabarían convirtiéndose en importante desarrollos o implementaciones de la red.

Otro hito sería la puesta en marcha del DEVgrants program en abril del 2015, encargado de ofrecer financiación para desarrollos de la propia plataforma o a proyectos basados en la misma. Por entonces, también se establecería un programa de recompensas para aquellos que encontraran vulnerabilidades en el software de la plataforma.

Tras la testnet Olympic (mayo de 2015), se procedería al lanzamiento de la red Frontier el 30 de julio de ese mismo año. En poco tiempo, numerosos desarrolladores empezarían a crear smart contracts y dapps que desplegarían en la misma. A ello, hay que sumar un importante número de mineros que se unirían a la red para asegurar la blockchain y ser recompensados con ether por su trabajo. A pesar de que Frontier se consideraba una versión beta de Ethereum, acabaría resultando más fiable y presentando unas prestaciones mayores de lo que todo el mundo esperaba.

En noviembre de 2015, se celebraría en Londres la segunda convención mundial de desarrolladores de Ethereum, la DEVCON 1, que atraería a más de 400 participantes llegados de todos los rincones del planeta. La presencia de importante multinacionales como IBM y Microsoft representaba, sin duda, un punto de inflexión respecto a la difusión de la tecnología blockchain. Microsoft anunciaría un acuerdo para incluir a Ethereum en la nueva oferta de Blockchain-as-a-service de su plataforma en la nube Azure.

El 14 de marzo de 2016 se lanzaría, tras Frontier, la primera versión ya en fase productiva de la plataforma Ethereum, denominada Homestead. Esto significaba que por primera vez la red pasaba a considerarse segura por parte de los desarrolladores. Poco después, en mayo de ese mismo año, se llevaría a cabo el crowdfunding del DAO -una organización autónoma descentralizada según sus siglas en inglés, que debía funcionar como un nuevo modelo de fondo de capital riesgo. En junio, un atacante desconocido explotaría una vulnerabilidad del smart contract en que descansaba el DAO y retiraría 50 millones de dólares -lo que representaba por entonces, un 15% del total de ETH.

El hackeo del DAO marcaría un punto de inflexión en la historia de Ethereum. tras una serie de acaloradas deliberaciones, que no se verían exentas de polémica, la comunidad decidiría llevar a cabo un hard-fork para recuperar todos los fondos del contrato original. Una parte minoritaria de la comunidad, disconforme con la decisión, decidiría mantenerse en la cadena original, no bifurcada, dando lugar al nacimiento de Ethereum Classic.

En septiembre de 2016 se celebraría la DEVCON 2 en Shanghai, y en octubre, se ejecutaría un nuevo hard-fork para actualizar la plataforma. Para la nueva versión se escogería el nombre Tangerine Whistle. El objetivo de esta nueva actualización era incrementar el coste del gas para ciertas operaciones computacionales que hasta entonces había resultado ser demasiado baratos, con el objetivo de encarecer enormemente la posibilidad de llevar a cabo ataques de tipo DoS -ataques de denegación de servicio.

Un segundo hard-fork, denominado Spurious Dragon, sería implementado en noviembre de ese mismo año para adelgazar el estado de la blockchain y combatir otro tipo de ataques DoS -concretamente, los relacionados con la generación de múltiples cuentas vacías.

La tercera fase de la hoja de ruta para el desarrollo de la plataforma Ethereum se denominaría Metropolis y se dividiría, a su vez, en dos etapas: Byzantium y Constantinople.

El objetivo de esta actualización sería lograr una versión de Ethereum más ligera, rápida y segura, que a su vez, proporcionara una mayor flexibilidad a los desarrolladores de smart contracts. Por este motivo, Metropolis representaría la implementación de una serie de hitos relativos a distintos aspectos o prestaciones de la plataforma:

  • Privacidad: por primera vez se pondría a disposición de los desarrolladores la posibilidad de verificar zk-SNARKs de forma eficiente on-chain. Los zk-SNARKs son herramientas de privacidad de tipo “zero-knowledge proof”, que permiten demostrar la posesión de cierta información o conocimiento, sin necesidad de revelar la información o conocimiento en cuestión.
  • Account abstraction: la abstracción es un mecanismo propio de la ingeniería de software, que permite evitar la sobrecarga de detalles sobre el usuario final. En este caso, relativo a la gestión de las cuentas, la idea sería dotar al usuario de un mayor control de sus claves privadas, al tiempo que se añade la posibilidad de que los contratos paguen las comisiones de minado.
  • Bomba de dificultad minera: el objetivo de este mecanismo es incrementar de forma exponencial la dificultad de minado a partir de cierto momento, para así evitar el estancamiento en los progresos hacia el nuevo mecanismo de consenso (Proof of Stake), y que algunos nodos mineros pudieran verse tentados a quedarse en la cadena Proof of Work original, una vez completada la transición. Aquellos nodos que decidieran seguir minando la cadena Proof of Work se encontrarían con lo que los desarrolladores de Ethereum denominan “Edad de Hielo”.

Serenity, también llamado Eth 2.0, es la etapa final de la hoja de ruta de desarrollos de Ethereum. El objetivo de esta actualización, dividida en tres fases, es lograr una adopción generalizada de Ethereum como principal plataforma global de smart contracts. Para ello se reemplazará el actual mecanismo de consenso Proof-of-Work por otro denominado Proof-of-Stake, en el que las labores de creación y validación de nuevos bloques no la realizan nodos mineros sino los denominados validators. En lugar de competir entre sí mediante costosos hardwares de tipo ASIC, el único requisito de los nodos validadores es que mantengan en depósito constante (stake) una cantidad determinada de ETH (que en estos momentos es de 32). Con esto se espera combatir la excesiva centralización minera que se atribuye a Proof-of-Work (por poner un ejemplo, se cree que 5 pools controlan la mayoría del hashrate de Bitcoin).

En Proof-of-Stake, la probabilidad de los nodos validadores de obtener la recompensa de bloque por su trabajo computacional, es proporcional a la cantidad de ETH que tengan en depósito (stake). La introducción de un mecanismo de penalización denominado slashing, evita que los nodos validadores se desconecten de la red o lleven a cabo acciones maliciosas (ya que en ese caso, perderán parte de su depósito). Otras ventajas para Ethereum de Proof of Stake son un menor consumo eléctrico y una considerable disminución de la tasa anual de emisión de ETH (inflación), sin que ello afecte a la seguridad general de la red. Se cree que, una vez desplegadas todas las fases de Serenity, la inflación de Ethereum rondará un 0,5% anual y con el tiempo tenderá a cero. Esto se logra gracias a una recompensa de bloque menor, y otros mecanismos de reducción de la masa monetaria como el ya citado slashing o la quema de comisiones por transacción (fees).

Existen dos versiones del protocolo de consenso Proof-of-Stake de Ethereum:

  • Casper FFG (Friendly Finality Gadget) liderada por Vitalik Buterin y que es la que implementará la fase 0 de Serenity para la finalización de la cadena (lo que en este contexto significa que una vez un registro ha sido grabado en la historia de la blockchain, no puede ser revertido de ninguna manera).
  • Casper CBC, un protocolo muy versátil y abstracto, que permite alcanzar consenso y prácticamente cualquier tipo de estructura de datos, y que ha sido concebido por Vlad Zamfir. La implementación de Casper CBC en la hoja de ruta de Serenity no está confirmada en estos momentos.

Otras de las ventajas asociadas a Serenity, además de la transición a un sistema de consenso Proof-of-Stake, es la adopción de una solución de escalabilidad denominada sharding y el reemplazo de la Ethereum Virtual Machine por un sistema llamado eWasm.

Lo que hace el sharding para escalar la cantidad de transacciones que Ethereum puede procesar por segundo, en resumidas cuentas, es dividir la cadena en porciones más pequeñas y rápidas (denominadas shards). Por su parte, eWasm (Ethereum WebAssembly) es una máquina virtual que presenta numerosas ventajas respecto a la EVM (como por ejemplo, aprovechar herramientas de hardware mejoradas o programar sobre un ecosistema de herramientas y lenguajes más amplio).

Fases de Serenity

  • Fase 0Beacon Chain — Finales de 2019: La fase 0 de Serenity comprende el lanzamiento de la Beacon Chain, espina dorsal que se encarga de controlar el protocolo Proof of Stake Casper para sí misma y todas las cadenas shard. Entre sus funciones se encuentra la administración de los validadores y sus depósitos (stake), la nominación del block proposer escogido para cada shard en cada momento, la organización de los validadores en comités para votar los bloques propuestos, la aplicación de las reglas de consenso y la distribución de recompensas y penalizaciones a los validadores. Asimismo, la Beacon Chain funciona como punto de anclaje en el que las shards registran sus estados para facilitar las transacciones entre ellas. La fase 0 de Serenity implementa Casper the Friendly Finality Gadget para, tal como hemos explicado anteriormente, finalizar los registros que se producen en la cadena. También es importante destacar el hecho de que, a partir de este momento, coexistirán dos ETH, ya que se crea uno nuevo denominado ETH2. Para obtenerlo es necesario depositar cierta cantidad de ETH en el contrato de registro de validadores o bien como recompensa al validar la Beacon Chain. Es importante tener en cuenta que durante la fase 0 no existirá una forma de retirar el ETH2 de la Beacon Chain. Por lo tanto, nos encontramos con que durante esta primera fase coexistirán dos cadenas: la PoW original, a la que llamaremos Eth 1.0 o 1.X, y la Beacon Chain (Eth 2.0).
  • Fase 1 — Cadenas Shard — 2020?: La fase 1 de Serenity, sin una fecha de lanzamiento concreta pero en principio prevista para el año 2020, se ocupará de la construcción, validez y consenso de los datos contenidos en shard chains -arquitectura clave para solucionar los tradicionales problemas de escalabilidad de la plataforma Ethereum. Sin embargo, en la fase 1 no se especifican las ejecuciones de estado de las shard chains o los balances de las cuentas. Podemos considerarla una especie de test de la arquitectura shard. Es importante destacar que el estado actual de cada una de las shard chains será registrado periódicamente en un bloque de la Beacon Chain en forma de crosslink. Esto significa que cuando el bloque de la Beacon Chain esté finalizado, el bloque correspondiente de la shard chain también se considerará finalizado. Los crosslinks son elementos muy importantes para las transacciones entre distintas shards.
  • Fase 2 — Ejecución de Estado — 2021?: En esta fase es cuando por fin la funcionalidad global se alcanza. Las shard chains pasan de ser simples contenedores de datos a cadenas de estado estructuradas. Cada una de ellas gestionará una máquina virtual basada en eWASM. Los smart contracts son introducidos y es posible que se implemente medidas de tipo State Rent (que implica el pago por el almacenamiento de código y datos) para así aliviar la carga de la plataforma. Es importante tener en cuenta que las Dapps deberán escoger en que shard quieren ser desplegadas, una decisión importante ya que la comunicación entre shards será lenta a nivel de la capa base (aunque existirán mecanismos en capas superiores para agilizarla). Todavía se discute de qué forma y cuando se realizará la migración de los contratos y cuentas de Ethereum 1.0 a Ethereum 2.0 (es decir, Serenity). Existen diversos planes pero todavía nada definitivo.

Fuentes: EthHub | Ethereum Wiki

来源

What do you think?

发表评论

电子邮件地址不会被公开。 必填项已用*标注

Loading…

0

Comments

0 comments

Around the Block: Analysis on the bZx Attack, DeFi Vulnerabilities, The State of Debit Cards in…

Kava: a DeFi platform for Crypto Assets