Propuestas para la gestión de escala estatal en Ethereum (Parte 2)

Opinión | Propuestas de gestión de la escala estatal de Ethereum (Parte 1) Eliminar del árbol estatal frente a organizar una parte de "retirada" del árbol estatal Otra perspectiva técnica para distinguir las diferentes propuestas de vencimiento estatal es "flujo de un árbol" y "flujo de dos árboles" . En otras palabras, ¿tenemos solo un árbol de estados como ahora, pero marcamos algunos estados como caducados, o eliminamos directamente el estado inactivo del árbol de estados principal y lo transferimos a otro (árbol (u otros datos)) dedicado que solo contiene estados caducados? Un flujo de árbol: los nodos activos están marcados en blanco, los nodos inactivos están marcados en gris; tenga en cuenta que incluso los nodos intermedios en el árbol se marcarán como activos o fallados (o, de manera más realista, cada nodo se marcará con la fecha de desactivación, por lo que su la actividad se puede verificar fácilmente); el trabajo de marcado se puede realizar en cada nodo (nodos de hoja y nodos intermedios) en el árbol de estado. Flujo de dos árboles: el árbol blanco contiene el estado de activación; el árbol gris almacena el estado de inactivación; la ventaja del flujo de un árbol es que, como mínimo, funciona de manera similar al árbol de estado actual y el proceso de desactivación y resurrección también es relativamente simple: el proceso de resurrección solo necesita actualizar el parámetro "fecha de vencimiento" del nodo relevante en el árbol, mientras que la desactivación es automática. Pero tiene las desventajas: requiere una estructura de árbol que pueda almacenar información intermedia de esta manera en los nodos, y no se adapta bien a los árboles de Verkle. Además, requiere un elemento de prueba de Merkle adicional, no solo para poder hundirse en los nodos hoja, sino también para poder detenerse en los nodos intermedios (cuando necesita demostrar que alguna parte del estado ha expirado). La ventaja del flujo de árbol binario es que la forma pura actual del acumulador de estado puede admitir este tipo de esquema, sin agregar metadatos para cada nodo. La desventaja es que requiere algunos cambios más profundos en todo el protocolo y requiere un proceso explícito para desactivar el estado (por lo que la caducidad ya no es automática). Además, no proporciona una solución integrada al dilema del conflicto de la resurrección (consulte la siguiente sección), por lo que se requiere elegir entre dos enfoques. Tenga en cuenta que en un flujo de árbol binario, la estructura de datos para almacenar el estado de inactivación no es necesariamente un árbol. De hecho, es completamente posible tener un diseño de este tipo: cuando se necesita reactivar un objeto de estado, solo es necesario proporcionar un árbol de Merkle que apunte al recibo cuando se desactivó el objeto y adjuntar alguna evidencia criptográfica para probar que el el objeto no ha sido destruido antes. Resucitado (o recientemente caducado), puedes. Conflictos de resurrección Llegamos entonces a una pieza clave del rompecabezas en el esquema de caducidad estatal: los "conflictos de resurrección". El concepto de conflicto de resurrección es el siguiente. Supongamos que una cuenta es generada por la dirección A; esta cuenta caduca; luego, la dirección A crea una nueva cuenta (por ejemplo, use el código de operación CREATE2 para asegurarse de que la dirección de la cuenta generada dos veces sea la misma); finalmente, la dirección A nuevamente Intenta resucitar la cuenta original. ¿Qué pasará en este momento? Aquí hay varias soluciones posibles: Desarrolladores de Ethereum: El uso actual de gas de capa 2 de Ethereum es inferior al 1% de la capa 1: El 22 de noviembre, el desarrollador de Ethereum, Ryan Berckmans, tuiteó que, según los datos de Dune Analytics, la cantidad actual de gas utilizada por el La red de capa 2 de Ethereum representa aproximadamente del 0,5 % al 1 % del gas total de la capa 1, y este valor puede aumentar del 50 % al 99 % en los próximos años. Por lo tanto, incluso si la tarifa de gas utilizada por los usuarios finales disminuye, la tarifa de gas total de la red Ethereum seguirá aumentando rápidamente. [2021/11/22 7:04:36] Proceso explícito de "fusión de cuentas": similar a la regulación "excepto por la acumulación del saldo ETH de las dos cuentas, prevalecerá el estado de la cuenta anterior" o "excepto por la acumulación de ETH Además, prevalecerá el estado de la nueva cuenta”; incluso, el código de contrato de la cuenta anterior puede especificar un proceso de fusión especial para garantizar que no se produzcan conflictos de resurrección al eliminar el despliegue repetido de la misma dirección: es decir, para ajustar la función de CREATE2. Por ejemplo, la hora actual se incluye en la preimagen de datos que finalmente se convierte en una dirección, por lo que incluso si se usan los mismos datos para generarlos en el futuro, la misma dirección no puede ser Añada un "stub" al objeto de estado para evitar que se generen nuevas cuentas en la misma ubicación (el método de flujo de árbol único mencionado anteriormente realiza automáticamente esta función) Al generar una nueva cuenta, la prueba de que la cuenta no ha expirado antes debe adjuntarse: en cierto sentido, es equivalente al esquema de stub, excepto que este método coloca el stub en el estado Una parte separada, por lo que cualquier usuario que desee crear una cuenta de contrato debe rastrear esta parte del estado ( tenga en cuenta que si usamos un esquema de caducidad de ranura, cualquiera de las soluciones anteriores debe extenderse al nivel de ranura individual, no detenerse en la capa de Cuenta) Las principales preocupaciones son: (1) agregará mucha complejidad a la aplicación, necesitan para agregar la lógica de fusión; (2) después de hacer esto, a menos que una dirección esté "registrada" en la cadena, de lo contrario, el usuario ya no puede Es fácil obtener direcciones con las que se puede interactuar y acumular activos (como tokens ERC20 ). Las direcciones no registradas son importantes: cualquier usuario que reciba ETH por primera vez está utilizando una dirección no registrada. La raíz de esta (2) preocupación es que las direcciones no registradas en realidad tienen un límite de tiempo, si un usuario genera una dirección, recibe fondos, pero se olvida de enviar una transacción dentro del próximo año (es decir, se olvida de "Registrarse"), entonces sus fondos estará bloqueado. Tenga en cuenta que EOA no es inmune. Aunque parece posible, porque el proceso de fusión de EOA es relativamente simple (simplemente agregue el antiguo saldo de ETH al nuevo, y hay EIP 169 de inmediato). Sin embargo, también hay dos problemas aquí. En primer lugar, el objetivo de la extracción de cuentas es reemplazar EOA con contratos, y el proceso de fusión de los contratos de extracción de cuentas puede no ser sencillo. En segundo lugar, no solo el EOA en sí se verá afectado por los eventos de caducidad y resurrección, sino también las claves de almacenamiento relevantes (como el saldo del token ERC20) en la aplicación en la que participa el EOA, por lo que aún se requiere una lógica de fusión compleja. Entonces, desde mi punto de vista, lo menos disruptivo es algún tipo de esquema de trozo. Sin embargo, hay un problema de teoría de la información en el esquema de código auxiliar que conduce a algunos resultados extraños. Para evitar que se creen nuevos objetos de estado en las N ubicaciones de objetos de estado vencidos, un conjunto que cubra estas N direcciones (y/o claves de almacenamiento) debe ser parte del estado. Si el conjunto tiene información minimizada (es decir, contiene solo estas direcciones), entonces el tamaño del conjunto será O(N) y, por lo tanto, el tamaño del estado será O(N); entonces, el tamaño del activo El estado será el mismo que el de los discapacitados. El tamaño del estado en vivo es proporcional, por lo que en realidad no resolvemos este problema. La única forma en que Tree rot puede resolver este problema es sobrescribir información más allá de esas N cuentas; de hecho, tendríamos que hacer que todo el árbol sea inaccesible (nuevamente, esta es la esencia de una solución de Tree Rot: si dos cuentas expiran, todos el espacio entre ellas también caduca implícitamente (si dos cuentas caduca, todo el espacio entre ellas también caduca implícitamente)). Y aquí está el problema: esto crea una forma de "podredumbre de árbol" donde, con el tiempo, todas las partes del árbol de estado se vuelven inaccesibles para la creación de nuevas cuentas, al menos para aquellos usuarios que no rastrean el estado vencido de la zona. Y el problema secundario causado por el moho de los árboles también debe resolverse. Como ejemplo: si un contrato es para crear subcontratos, debe poder crear contratos en una región del estado que no esté mohosa o donde el usuario tenga datos de atestación (tal vez requiera una "pista" proporcionada por el usuario). Puede encontrar una solución al problema del moho de los árboles aquí: Nuevas áreas están constantemente abiertas para la creación de cuentas. Otra forma de pensar es que cada usuario selecciona alguna región del estado (digamos 1/256 del estado), realiza un seguimiento de los cambios en esa región (incluidos los estados vencidos) para que se puedan crear certificaciones y solo crea cuentas en esa región. Otro problema con Tree Musty es que requiere una estructura de datos explícita para almacenar y verificar rangos. Es mejor si un árbol tiene datos que se pueden colocar en un nodo que indiquen qué partes debajo de ese nodo han expirado (como usa la solución de transmisión de un árbol), pero un almacén de clave-valor sí. Esto sigue siendo bastante difícil. Muchos de los problemas que surgen del uso de estructuras de árbol en esquemas de caducidad de estado se remontan al hecho de que necesitamos llegar a un consenso sobre qué estados están activos y cuáles están inactivos. En el modelo de flujo de dos árboles, esto es más obvio, pero incluso en el modelo de flujo de un árbol, debe haber una marca explícita en el árbol de estado para que los nodos de Ethereum que hayan descargado recientemente el estado mediante sincronización rápida puedan determinar un intento. Si una transacción que accede a una cuenta sin proporcionar una certificación debería tener éxito o fallar. Entonces, ¿podemos hacerlo sin aclarar esta distinción? Si logramos la apatridia completa, y luego ayudamos a los remitentes de transacciones y a los productores de bloques a obtener de manera confiable el estado requerido para la generación de mensajes de atestación, ¿no resolveríamos este problema? Entonces, ¿qué puede ayudar a los remitentes de transacciones y a los productores de bloques a hacer esto? Un enfoque natural es que cada nodo de la red mantenga solo una parte del árbol de estado, por ejemplo, la parte visitada el año pasado. Simplemente agregue una configuración voluntaria en la configuración del cliente. Si queremos ser más confiables, podemos obligar al menos a los mineros (posteriores verificadores de PoS) a almacenar algunos datos mediante la introducción de un esquema de prueba de custodia. Una cosa a tener en cuenta: si la capa de consenso no puede percibir qué estados están activos y qué estados están inactivos, entonces la sobrecarga de gas para acceder a estados recientes y estados antiguos es la misma. Esto conducirá a dos consecuencias: el costo de gas para acceder al estado reciente también deberá aumentar aún más. El límite superior del tamaño del bloque que contiene el mensaje de atestación puede ser muy grande. Si un bloque está lleno de transacciones que acceden al estado anterior (alrededor de 800 bytes * 12,5 m gas / 2400 gas por acceso ~= 4,1 MB, asumiendo la implementación de EIP-2929, convertido a un árbol binario) Si queremos evitar estas desventajas, necesitamos rastrear qué objetos de estado en el consenso (incluida la región aún no llena del espacio de direcciones) está activo, lo que nos lleva de nuevo a la propiedad de acercarse al esquema de vencimiento del estado. Esto demuestra una vez más que "la apatridia frente a la caducidad del estado (renta estatal)" es un espectro, un espacio de compensación complejo, en lugar de una elección de uno u otro. Una importante solución de escalabilidad a mediano plazo para Ethereum son los rollups (traducción al chino). Sin embargo, el resumen en sí mismo no necesita preocuparse por el tamaño de los datos de estado; de hecho, el tamaño del estado del sistema de resumen es exactamente el mismo que el de la propia cadena Ethereum. Afortunadamente, si podemos encontrar una solución, al menos el resumen de EVM (el esquema de resumen que intenta replicar el tiempo de ejecución de Ethereum tanto como sea posible) puede usar la misma solución para resolver el problema del tamaño de su estado interno. Por lo tanto, la administración del tamaño del estado es complementaria a los paquetes acumulativos, la fragmentación y otras estrategias de escalado. (Nota del traductor: personalmente creo que la palabra "complementario" aquí es muy engañosa). La escala estatal es un problema que empeora, y una solución a la escala estatal también puede allanar el camino para un aumento sustancial en el límite de gas del bloque. Deberíamos acordar alguna forma de expiración del estado e implementarla. Sin embargo, existen compensaciones técnicas significativas entre diferentes soluciones, especialmente si también queremos mantener algunas propiedades importantes del diseño actual. Algunas propiedades que es posible que debamos sacrificar incluyen: los usuarios pueden generar cuentas fuera de línea y recibir fondos en esta dirección, y pueden permanecer en silencio durante cualquier período de tiempo antes de que la dirección sea visible en la cadena. inherentemente puede necesitar cambiar rápidamente por el bien de la resistencia a la colisión) El estado se puede considerar como un atributo de almacenamiento de clave-valor "puro", y no hay necesidad de almacenarlo en cada nodo en el árbol de estado Atributos de metadatos Las aplicaciones existentes necesitan ser reescrito en diversos grados para garantizar que los usuarios puedan generar datos de testigos Consumo de gas sin almacenar todos los estados desactivados o la dificultad de crear nuevos contratos y escribir nuevos espacios de almacenamiento Si hemos preparado Es fácil hacer sacrificios, y algunos programas pueden comenzar implementarse muy rápidamente. Por otro lado, tal vez con el tiempo podamos modificar o agregar mejor estos conceptos, reduciendo los problemas y, especialmente, haciéndolos técnicamente más fáciles de implementar (por ejemplo, permitiendo el uso de almacenes de valores clave "puros"). Deberíamos comprender mejor qué sacrificios estamos más o menos dispuestos a aceptar y seguir trabajando activamente en propuestas de mejora

Tags：

DOGE