V God lanzó la primera propuesta de bifurcación dura HF1 de la cadena de balizas ETH2.0, introduciendo un mecanismo de penalización de nodo más justo.

Vitalik, el fundador de Ethereum, presentó la propuesta de actualización de la primera bifurcación dura de Ethereum Beacon Chain (denominada tentativamente "HF1") en Twitter. Según Vitalik, HF1 agrega un soporte ligero al cliente, simplifica la especificación, mejora la eficiencia e introduce un mecanismo de penalización por inactividad menos punitivo. Según el documento, la bifurcación dura permitirá a los desarrolladores realizar algunas actualizaciones clave en la cadena de balizas lanzada recientemente y también servirá como una prueba útil para cambios más profundos en el futuro. Entre ellos, el cliente ligero admite nodos que tienen los requisitos más bajos de recursos y pueden ejecutarse en dispositivos móviles. Esto permitiría que las "carteras de confianza minimizada" verifiquen la cadena de bloques por sí mismas, en lugar de depender de proveedores de servicios externos. "HF1 es el nombre en clave tentativo para la primera actualización de la bifurcación dura de Ethereum Beacon Chain (consulte aquí las ideas de nombres a largo plazo para la bifurcación dura). Los principales objetivos de HF1 son: Agregar soporte de cliente ligero Corrige algunas vulnerabilidades en la baliza cadena. Estas vulnerabilidades se descubrieron demasiado tarde para corregirlas cuando se lanzó la génesis de la cadena de balizas. El mecanismo de actualización de bifurcación dura de la cadena de balizas en un entorno de actualización de cambios menores. Prueba para cambios mayores en el futuro. V God lanzó tres razones por las cuales la capacidad de la cadena aumentó aproximadamente un 9 % después de la actualización de Londres: V God (Vitalik Buterin) publicó un artículo "¿Por qué la capacidad de la cadena aumentó aproximadamente un 9 % después de la actualización de Londres?". V God dijo que hay 3 razones: 1 Retraso de la Edad de Hielo Cuando comenzó la bifurcación de Londres, la Edad de Hielo acababa de comenzar a tener efecto. El tiempo de bloque promedio antes de Londres fue de aproximadamente 13,5 segundos, y el tiempo de bloque promedio después de Londres volvió a su nivel a largo plazo. El nivel normal es de aproximadamente 13,1 segundos. Esta es una diferencia de alrededor del 3 % en la velocidad del bloque, lo que explica el 3 % del aumento del 9 % en el uso de gas en la cadena. 2. El valor objetivo de 15 millones y el máximo de 15 millones antes de la mejora de Londres , el bloque El uso mínimo de gas es de 15 millones, no todos los bloques usan los 15 millones completos, e incluso los productores de bloques más funcionales dejan 0-20999 de gas sin usar porque queda muy poco espacio para acomodar una sola transacción, y más allá de eso , siempre habrá productores de bloques ocasionales que hagan bloques vacíos. Un análisis realizado en abril sugirió que alrededor del 2% de los bloques estaban vacíos. Suponiendo que hubiera alrededor del 2-3% de los bloques antes de Londres Espacio sin usar. Sin embargo, después de Londres, 15 millones no es un máximo, pero un valor objetivo. Esto significa que si el promedio de gas utilizado (incluidos los bloques vacíos) es inferior a 15 millones, la tarifa base se reducirá hasta que el promedio vuelva a 15 millones. Eso es aproximadamente 2-3% nuevamente. 3. Defecto matemático en el ajuste de la tarifa base La fórmula EIP1559 no es perfecta en el objetivo del 50 %. Tomando datos del intervalo de tiempo observado más reciente, el 51,5 % es un bloque completo (bloque completo) (por lo tanto, aproximadamente un 3 % más que el 50 % esperado). [2021/8/15 22:15:37] Los cambios de consenso propuestos en HF1 incluyen: V Dios emitió un plan detallado "Verkle tree and state to" period, la expiración del estado reemplaza un solo árbol estatal con una lista de árboles estatales: Vitalik Buterin dijo que escribió algunos planes más detallados (incluidos los EIP originales) para los árboles de Verkle y la caducidad del estado.Árbol de Verkle: en el presente Se introduce un nuevo árbol de estado de Verkle junto a algunos árboles de Patricia hexarios. ediciones en el estado y una copia de todos los estados de acceso, y el árbol hexadecimal Patricia ya no se puede modificar. Esto depende completamente del árbol Ethereum Verkle para almacenar el primer paso en la ejecución de una transición de estado de varias etapas. Caducidad del estado: reemplaza un solo árbol de estado con una lista de árboles de estado, aproximadamente Un árbol por año. Las ediciones de estado se almacenan en un árbol correspondiente al período actual y los clientes ya no almacenan árboles anteriores a los dos períodos más recientes. Las transacciones que utilizan el estado anterior, que no han sido modificadas en los últimos dos períodos, necesitan proporcionar testigos. [2021/6/18 23:46:59] Agregamos un "comité de sincronización" elegido al azar a la cadena de balizas. El propósito de esto es permitir que los clientes ligeros determinen el encabezado de la cadena con muy poca sobrecarga (alrededor de 20 kilobytes por día como mínimo y alrededor de 500 bytes para verificar un solo bloque). Esto permitirá que los clientes ligeros utilicen realmente la cadena de balizas en casos de uso como dispositivos móviles, navegadores integrados, allanando el camino para un ecosistema de billetera más minimizado en confianza. V God tuiteó y elogió la EIP 1559. Los usuarios cuestionaron que la propuesta dañaría los intereses de los mineros: según las noticias del 20 de octubre, V God tuiteó esta mañana que la EIP 1559 es exactamente lo que el mundo necesita hoy. En este sentido, algunos usuarios objetaron, diciendo que la propuesta debería ser rechazada. Dijo que aunque EIP 1559 es realmente interesante, parece que causará un gran daño a los mineros. Y pensar que si se aprueba la propuesta afectará a grandes mineros y grupos mineros para seguir participando en la minería de redes Ethereum. V Dios aún no ha respondido. Se informa que EIP 1559 fue propuesto por primera vez por V God en 2018, lo que se espera que haga que el mercado de tarifas de la cadena de bloques Ethereum sea más predecible y alivie la congestión. [20/10/2020] En cada período de tiempo (aproximadamente 27 horas), se seleccionan aleatoriamente 1024 validadores como miembros del comité de sincronización. Los nodos de validación en el comité de sincronización emitirán firmas para dar fe del jefe actual. Estas firmas se transmitirán como parte del objeto LightClientUpdate que ayuda a los clientes ligeros a encontrar esta cabeza y se incluirán en la cadena de balizas para obtener recompensas. Más contenido: https://github.com/ethereum/eth2.0-specs/pull/2130 Dynamics | V Shen envió 5 publicaciones de blog para hablar sobre las dificultades que encontrará Ethereum 2.0 en el futuro: según los informes de artículos de Coindesk, en Ethereum Durante la conferencia de Devcon, V God continuó escribiendo y publicó 5 publicaciones de blog seguidas, hablando de las dificultades que encontrará Ethereum 2.0 en el futuro. Está organizado de la siguiente manera: 1. A corto plazo (si se libera ETH2.0), todavía es posible transferir ETH de Ethereum 2.0 a Ethereum 1.0. El desarrollador de Ethereum 2.0, Preston Van Loon, dijo que la complejidad de crear un puente bidireccional entre ETH 2.0 y ETH 1.0 plantea un "riesgo de seguridad" para ambas cadenas. Buterin propuso dos formas posibles de crear un "puente" entre las dos cadenas de bloques. Reconoció que "ambas propuestas requerirían medidas correctivas urgentes en el lado de Ethereum 1.0 si Ethereum 2.0 se viera comprometido". Migración por la red Fang 1.0. Esta sigue siendo una propuesta, y los investigadores no han diseñado un "puente" de migración en ETH 2.0. 2. Antes de que ETH2.0 y ETH1.0 se fusionen por completo, Ethereum 2.0 puede usarse en paralelo con ETH1.0 durante muchos años. El investigador de Blockchain, Mihailo Bjelic, dijo que un sistema complejo como ethereum 2.0 no debería reemplazar la red principal actual de ethereum hasta que los desarrolladores estén seguros de su confiabilidad. Buterin dijo en una publicación de blog que espera que la transición sea fluida. 3. Los datos de llamadas sobre la cadena de bloques Ethereum 2.0 serán más caros que antes. En respuesta a estos problemas, Vitalik sugirió en una publicación de blog que los desarrolladores pueden controlar su escala al escribir validadores. 4. Ethereum perderá la capacidad de transacciones atómicas. ETH 2.0 destruirá la capacidad de las transacciones atómicas en Ethereum, es decir, completará todas las transacciones a la vez (la división de transacciones se completará entre diferentes fragmentos). V God cree que las diferentes aplicaciones pueden tener capacidades de interacción más sólidas, pero también obstaculizarán algunas actividades, lo que dificultará la atracción de comerciantes de criptomonedas. 5. V God propuso en una publicación de blog que la cantidad de fragmentos de ETH 2.0 se reducirá cuando se lance. Anteriormente eran 1024 fragmentos, y ahora se propone que sean 64 fragmentos. La principal ventaja es que los fragmentos de Ethereum 2.0 puede comunicarse más rápido, más simple. [2019/10/25] Reemplazamos el método de cálculo de la recompensa del probador. En lugar de almacenar objetos PendingAttestation y procesarlos al final, optamos por agregar un campo de bits que almacena el estado de cada validador, lo que permite la acumulación de datos en tiempo real sobre quién participó. Los campos de bits se clasifican en "orden aleatorio" para garantizar que los registros de los validadores en el mismo comité aparezcan juntos. El propósito de este cambio es simplificar la implementación del cliente y abaratar la actualización del árbol de Merkle. Dynamics | V God publicó sus puntos de vista sobre si el desarrollo de la dirección de la cadena de bloques debe centrarse en las funciones de la primera capa o de la segunda capa: Según las noticias de AMBCrypto, con respecto a la controversia sobre si el desarrollo de la cadena de bloques debe centrarse en la primera capa o en las funciones de la segunda capa. funciones de la segunda capa, V Dios expresó su propia opinión de compromiso. Teniendo en cuenta el impacto del desarrollo de la cadena de bloques en el futuro, V God dijo: "Realmente creo que la cadena de bloques madurará cada vez más. La primera capa se volverá más estable y la segunda capa asumirá cada vez más la constante". carga de invención y cambio." [2018/8/29] Referencia específica: https://github.com/ethereum/eth2.0-specs/pull/2176 Realizamos cambios en el conjunto de validadores y castigamos Contabilidad solo ocurre cada 64 épocas, no todas las épocas. El propósito de esto es reducir en gran medida la complejidad de tratar con "transiciones de período de brecha"; por ejemplo, hay una cadena con una participación muy baja en la que dos bloques consecutivos están separados por mil ranuras con solo un período de brecha entre ellos. Para manejar tales cadenas, actualmente los clientes necesitan penalizar a los validadores por inactividad recalculando el saldo de cada validador cada época; en la nueva propuesta, solo necesitan hacer esto cada 64 épocas. Además, hicimos dos cambios en el funcionamiento de la penalización por inactividad: la penalización por inactividad se vuelve cuadrática para cada validador. Es decir, si hay una penalización por inactividad durante la cual un validador que estuvo completamente fuera de línea pierde alrededor del 10 % de su saldo, un validador que estuvo en línea el 90 % del tiempo durante este período ahora solo perderá alrededor del 0,1 % de su saldo (en comparación a ~ 1%). Esto intenta enfocar las sanciones en los nodos que realmente se comportan mal y menos en los nodos honestos que están fuera de línea debido a problemas de conectividad de red. Se puede encontrar más discusión aquí: https://github.com/ethereum/eth2.0-specs/issues/2098 La penalización por inactividad del validador se ralentiza gradualmente en lugar de detenerse después de determinarse. Esto garantiza que una vez que se alcanza el estado final, los nodos fuera de línea seguirán perdiendo su equilibrio durante un período de tiempo, lo que garantiza que el porcentaje de tiempo que los validadores están en línea sea significativamente mayor que 2/3, en lugar de solo un poco por encima de ese umbral. https://github.com/ethereum/eth2.0-specs/pull/2192 ‌ https://github.com/ethereum/eth2.0-specs/pull/2194 Un punto para celebrar es que al debilitar las penalizaciones del validador, Podríamos estar un poco (aunque no del todo) fuera de peligro. Haremos cambios a las constantes: INACTIVITY_PENALTY_CUOTIENT: reducido de 2**26 (= 67,108,864) a 3 * 2**24 (= 50,331,648)PROPORTIONAL_SLASHING_MULTIPLIER: aumentado de 1 a 2MIN_SLASHING_PENALTY_CUOTIENT: reducido de 287) **6 (= 64) Selección bifurcada de (bloque, ranura) par (par) Actualmente, si no se ha lanzado ningún bloque en la ranura más cercana, se considera prueba a los efectos de la prueba LMD GHOST durante esa ranura El último bloque de la cadena que el autor admite . Por ejemplo, en esta imagen a continuación, las pruebas en BLANCO cuentan como pruebas en A: <img src="https://img.jinse.com/4715604_image3.png" auto";'> Sin embargo, esto es 34 % El El ataque abre la puerta. Supongamos que se asignan m validadores a cada ranura, de los cuales el atacante malintencionado controla 0,34*m. El atacante también tiene derecho a publicar el bloque B para la ranura n+1. El ataque procede de la siguiente manera: el atacante no publica B, no publica ninguna de sus pruebas. Todos los probadores honestos votarán por la afirmación de que vieron el bloque A en el espacio n y nada en el espacio n+1, y el recuento actual se considera como un voto por A. En el n + 2a ranura, un proponente honesto construirá un bloque C encima de A, en este momento, el proponente malicioso anunciará B a la ranura n + 1 y n + 2 y su prueba de B. La bifurcación superior tiene 0.68*m Los validadores lo respaldan, pero la bifurcación superior solo tiene 0,66 * m de respaldo, por lo que gana la bifurcación inferior. Este ataque se realiza en la sección 3.1 de ese documento. Una descripción más detallada: https://econcs.pku.edu.cn/wine2020 /wine2020/Workshop/GTiB20_paper_8.pdf La solución propuesta es cambiar la forma en que funciona la selección de bifurcación, de modo que sea para (bloque, ranura) Opera en el árbol de pares, no en el árbol de bloques. Entonces, en el diagrama de arriba, honestamente los votos en el espacio n+1 se contarán como votos a favor (EN BLANCO, n+1), por lo que se contarán correctamente. https://github.com/ethereum/eth2.0-specs/pull/2197 Hay un "ataque de equilibrio", el atacante con el 2% de validadores emitirá una pequeña cantidad de prueba en el momento correcto antes del final de un espacio, convenciendo a más del 49% de las personas en la red de que cierto bloque A gana, y más del 49% de la red no lo hará, se considera que ganó el Bloque B. Si cronometraron la transmisión correctamente, cada conjunto de los validadores verán el mensaje dirigido a ellos a tiempo, pero no tendrán tiempo de retransmitir el mensaje a otro grupo de validadores antes de que finalice el espacio.

Tags：

Huobi App