Saltar al contenido

eth2 actualización rápida no. 4 4

Bienvenido a la cuarta entrega de actualización rápida de eth2. Hay muchas piezas en movimiento de las que hablar esta semana. Además del desarrollo heroico del cliente eth2, estos son los aspectos más destacados:

tldr;

Subvención diferencial difusa

Sigma Prime ha recibido una subvención para dirigir el esfuerzo diferencial difuso para clientes eth2. Este esfuerzo es crítico para el éxito del lanzamiento de una red multicliente al ayudar a detectar problemas de consenso antes de mainnet.

El acto de "fuzzing" es el acto de arrojar muchas entradas aleatorias a una pieza de software para ver cómo reacciona. Cuando se difunde una sola pieza de software, el objetivo a menudo es encontrar entradas que conduzcan a bloqueos inesperados. Cuando encontramos tales entradas, descubrimos qué salió mal y endurecemos el software a este tipo de entrada.

Diferencial Fuzzing es un poco diferente. En lugar de buscar explícitamente bloqueos, buscamos instancias en las que diferentes implementaciones de un protocolo tengan una salida diferente para la misma entrada. En un contexto de blockchain, usamos el difuminado diferencial para encontrar casos en los que una serie de bloques conduce a un estado resultante diferente en dos clientes diferentes. Idealmente en la producción no existen tales casos.

Equipo de trabajo ligero del cliente

Chainsafe /Estrella polar, los beneficiarios de una subvención de la Fundación Ethereum para investigación y desarrollo en clientes de eth2 light, han formado el Grupo de trabajo de clientes ligeros. Este grupo se ha encargado de garantizar que los clientes ligeros sean ciudadanos de primera clase en eth2. Para este fin, están organizando un llamada mensual destinado a impulsar la investigación, estándares, especificaciones y educación de clientes livianos.

La necesidad de un rico ecosistema de clientes ligeros y servidores de clientes ligeros solo se amplifica en un protocolo fragmentado como eth2. Incluso si un cliente está sincronizando algún subconjunto del protocolo (por ejemplo, solo un par de fragmentos), un usuario necesitará muy a menudo obtener información sobre cuentas, contratos y el estado general de las cosas en otro fragmento. Un cliente podría sincronizar de manera ineficiente todo el fragmento adicional, pero la mayoría de las veces, solicitar la información sobre cuentas específicas en el fragmento con pruebas sucintas será el camino a seguir.

Sintoniza el siguiente Llamada de Light Client Task Force mantenerse actualizado sobre todas las cosas ligeras en eth2.

eth1 -> eth2

En los primeros días de eth2, la transferencia de éter de la cadena etérea existente (eth1) a la nueva cadena de baliza (eth2) será unidireccional. Es decir, el éter movido a la participación en eth2 no será transferible (para comenzar) de regreso a eth1. La elección de una sola transferencia direccional en validación es en un esfuerzo por minimizar el perfil de riesgo que eth2 induce sobre eth1, y permitir un ciclo de desarrollo más rápido en eth2 sin tener que bifurcar eth1 en el proceso. Existe cierto movimiento en torno a la creación de un puente bidireccional, pero guardaré la discusión sobre la mecánica del puente y las compensaciones para una publicación posterior. Hoy me gustaría profundizar cómo esta transferencia unidireccional funciona y cómo se puede implementar de manera segura sin cambiar eth1.

En la cadena PoW ethereum existente, implementaremos el contrato de validación eth2. Este contrato tiene una sola función llamada depositar que toma una serie de parámetros para inicializar un nuevo validador (por ejemplo, clave privada, credenciales de retiro, un depósito ETH, etc.). No hay retirada funcionar en este contrato. Salvo una bifurcación para agregar un puente bidireccional, este ETH depositado ahora solo existe en eth2 en la cadena de baliza.

Entonces es responsabilidad de los validadores en la cadena de balizas llegar a un consenso sobre el estado de este contrato de modo que se puedan procesar los nuevos depósitos. Esto lo hacen los proponentes de bloques eth2 que incorporan datos recientes de eth1 en un campo de bloque de baliza llamado eth1_data. Cuando suficientes proponentes de bloque durante un período de votación acuerdan recientes eth1_data, estos datos están consagrados en el estado de la cadena de balizas permitiendo que se procesen nuevos depósitos.

Una nota importante sobre este mecanismo es que el eth1_data está profundamente en la cadena eth1 PoW – ~ 1000 bloques de "distancia de seguimiento". Esta distancia de seguimiento induce una alta latencia en el procesamiento de nuevos depósitos de validación, pero proporciona un alto grado de seguridad en el acoplamiento de estos dos sistemas. La cadena eth1 tendría que reorganizarse a más de 1000 bloques para romper el enlace, y en tal caso requeriría alguna intervención manual para superarla.

Estamos investigando y creando prototipos de la utilización de la cadena de balizas para finalizar eth1 (es decir, el dispositivo de finalidad). Esto requeriría que eth1 difiera su elección de bifurcación en última instancia a la cadena de balizas, obteniendo seguridad de los validadores de PoS y permitiendo depósitos de eth1 a eth2 mucho más rápidos. El gadget de finalidad también abre otras cosas divertidas como el puente bidireccional y exponer la capa de datos eth2 a eth1. Más sobre todo esto en una publicación posterior: cohete :.

Fuente: https://blog.ethereum.org/2019/11/21/eth2-quick-update-no-4/