Topic: Ethereum 2.0 (Read 93 times)

Eth 2.0 consiste de un conjunto de especificaciones diseñadas para mejorar la eficiencia y el rendimiento de la red; Es un proyecto en continua evolución, que se modifica durante la trayectoria de su trabajo y a veces incluso se modifica drásticamente. Actualmente, la idea compartida entre desarrolladores e investigadores es unificar dos especificaciones técnicas que ciertamente no son nuevas:

Casper: trae un primer cambio al sistema de consenso: de Prueba de trabajo a Prueba de participación. La Prueba de participación tiene un papel muy importante que desempeñar, ya que debería:

● Reducir el número de confirmaciones necesarias para considerar que una transacción realmente se realizó.

● Hacer que un ataque del 51% sea excesivamente caro e inútil.

● Hacer que las agrupaciones de equipos mineros sean innecesarias, ya que conducen a la formación de carteles.

● Permitir que cualquier persona proteja la red sin la necesidad de equipos especiales.

● Desaseare de la prueba de trabajo y poner fin a un alto nivel de consumo de energía.

Sharding: implica la división de la cadena actual en una cadena principal (llamada Beacon Chain) y varias cadenas más pequeñas (shards). Estas subcadenas tienen la tarea de procesar en paralelo más transacciones, comunicándolas solo más tarde a la cadena principal que actúa como un punto de control de seguridad.


Eth2.0 Objetivos:

● Reducir la complejidad de la red.

● Estar constantemente en línea (invulnerabilidad a los ataques DDoS) en las diferentes instancias (shards) de la red y cuando una gran parte de los nodos se desconecta.

● Creación y selección de diferentes componentes para garantizar la resistencia a los ataques de las computadoras cuánticas y garantizar que estos componentes puedan ser reemplazados fácilmente (cuando sea necesario) por otras contrapartes resistentes a los dispositivos cuánticos.

● Permitir que incluso una computadora portátil participe en el consenso de la red.

● Adoptar un diseño que aliente a un gran número de personas a validar las transacciones de la red, logrando así una mayor descentralización del sistema.

Especificaciones técnicas

La actualización de Ethereum 2.0 es un proyecto complejo que requiere de varias intervenciones en diferentes tiempos, por esta razón solo se puede dividir en varias fases. Debemos especificar que el término “actualización” no es formalmente correcto: Eth2.0 / Serenity es la creación de una nueva red, un nuevo Ethereum. No habrá una bifurcación, pero la actualización de Serenity se realizará mediante la migración de los ETH de la cadena actual a Ethereum 2.0.

Fase 0 Prueba de participación + Cadena Beacon: Una cadena llamada Beacon Chain se crea utilizando el protocolo de consentimiento Casper FFG para asegurar el propósito de las transacciones. Esta cadena tendrá como activo BETH, producido mediante la transferencia de ETH desde Ethereum 1.x a la nueva cadena. Esta transferencia es IRREVERSIBLE.

Fase 1 Sharding sin EVM [6]: Tiene la tarea de probar el consenso entre el fragmento y la cadena Beacon; en esta etapa no habrá transacción en los fragmentos. Lo que sucede es que Beacon Chain y Shards están de acuerdo en lo que sucedió, independientemente de los eventos en sí.

Fase 2 EVM: Esta es probablemente la fase más interesante de Eth2.0, es decir, el momento en que los fragmentos podrán ejecutar contratos. En este punto del desarrollo, no hay comunicación entre los diferentes fragmentos, por ejemplo: el contrato de CryptoKitties solo se ejecutará en el fragmento 1, los demás fragmentos no saben lo que sucede en los fragmentos vecinos. Por lo tanto, es correcto decir que la escalabilidad aún no está completamente desbloqueada. También en la fase 2, el EVM será reemplazado por eWASM y habrá un cambio importante: los contratos pagarán una tarifa (tarifa de alquiler) por los datos guardados en la cadena. Esta implementación debería mantener a la cadena, preservándola de una gran cantidad de datos inútiles, de hecho, todos los contratos que no pagan la tarifa de alquiler verán sus datos eliminados permanentemente.

Fase 3 Protocolo Light Client: El propósito de esta actualización es permitir a los usuarios con dispositivos de bajo consumo (teléfonos inteligentes, extensiones de navegador) verificar independientemente la ejecución de las transacciones y el estado de Ethereum. [5]

Fase 4 Transacciones entre los distintos Fragmentos: En esta fase, el potencial de escalabilidad real del Fragmento se desbloquea: los fragmentos finalmente se dan cuenta de la existencia de sus vecinos y cooperan con ellos.

Fase 5 Tight Coupling: El sistema ahora se convierte en un conjunto de componentes que cooperan de manera dependiente.

Fase 6 Fragmento Super-Quadratic o exponencial: Permite la posibilidad de crear fragmentos dentro de otros fragmentos.

Ethereum tendrá una red de prueba en marzo que implementara la fase 0, pero presumiblemente, para la fase 0 + 1 tendrá que esperar hasta el final del año.


Estado de desarrollo

Para comprender lo complejo que es realizar una actualización de Ethereum, se debe de considerar varios factores. La mejora de ETH es un proceso dividido en dos fases: primero tenemos la investigación llevada a cabo por equipos de investigadores cuya tarea es cambiar las especificaciones de la red, introducir nuevas ideas a nivel económico, criptográfico, seguro, escalable, etc. En segundo lugar, el equipo responsable de las implementaciones entran en juego, donde los desarrolladores tienen la tarea de convertir las nuevas especificaciones en código. Tengan en cuenta que Ethereum es una red con una capitalización de $ 13 mil millones que las empresas recién han comenzado a utilizar para hacer negocios, por lo que incluso la actualización de una sola línea de código implica grandes responsabilidades. Si algo sale mal durante los procesos de actualización, sería un evento que no solo perjudicaría a Ethereum.

Las especificaciones técnicas están cambiando constantemente.

Como ya hemos señalado, la creación de Eth2.0 es el resultado del trabajo de dos equipos: un equipo de investigación y un equipo de implementación. Tras una fase garantizada por las ideas de los investigadores, los programadores tienen la tarea de traducir estas ideas en códigos. Parece ser un proceso lineal que sigue pistas bien definidas, pero no es así: los cambios en el desarrollo del proyecto pueden ocurrir en cualquier momento, a veces esto implica un considerable estrés por parte del equipo de implementación que puede verse obligado a una reorganización completa del trabajo realizado hasta ese momento.

En este sentido, recientemente se han notado algunas mejoras: los cambios en las especificaciones y los grandes cambios técnicos han disminuido con el tiempo. Este es un hecho reconfortante para demostrar que Ethereum 2.0 se está moviendo hacia una forma definitiva.

Finalmente, los distintos equipos comenzaron a colaborar definiendo las partes de las especificaciones que se pueden implementar, al mismo tiempo que minimizan el riesgo de reorganización. De esto se deriva otro aspecto fundamental: cada vez que se realizan cambios en las especificaciones, es necesario evaluar simultáneamente el peso que recaerá sobre los hombros del equipo de implementación, que todavía tiene la oportunidad de expresar su voto (a favor o No) en la aprobación de la modificación.

El desarrollo varía de un equipo a otro

Las implementaciones son dirigidas por diferentes equipos en múltiples lenguajes de programación: el cliente Prysmatic Labs Prysm está escrito en GoLang, mientras que el cliente Lighthouse de Sigma Prime está escrito en Rust. Como se puede ver, los desarrolladores se encuentran programando diferentes partes de la especificación con un solo objetivo común: el testnet de marzo. Aunque permanezcan enfocados en este objetivo común, lo que resulta en diferentes clientes (Nodos) que no han implementado las mismas características. Este es un tema central, que creemos es muy interesante y que podría resumirse en la falta de un líder y un proceso estandarizado.

Los diversos equipos de desarrollo e investigación carecen de un elemento clave que pueda coordinarlos durante el desarrollo. Hay una persona que da pautas y otra que, al mismo tiempo, asume la responsabilidad en caso de que no se logren los objetivos. Esto también se puede considerar en línea con la idea de que el proceso de desarrollo también debe tener lugar de manera descentralizada; sin embargo, la falta de un estándar y la necesidad de definir un sistema único y válido para todos, en relación con la implementación de la tecnología, está empezando a hacerse sentir.

Se trata de expectativas

Las expectativas de la comunidad, los usuarios y los inversores son inevitablemente muy altas, pero siempre debemos considerar los grados de dificultad que implican los cambios tecnológicos de este calibre. Dicho esto, ¿qué podemos esperar de manera realista en el futuro cercano?

Hasta la fecha, las certezas son:

● La fase 0 se actualizara en marzo de 2019.

● La fase 1 no permitirá ejecutar transacciones en la red con un fragmento, pero se usará para probar el enlace entre la cadena Beacon y Shard (cross-linking).

● Los contratos inteligentes no se beneficiarán de la escalabilidad real hasta la Fase 4. De hecho, hasta esta fase, será imposible que los fragmentos se comuniquen entre sí y demuestren todo el potencial del sistema.

Blockchainwhispers para intuitbit