Opinión: Propuestas para la gestión de escala estatal en Ethereum (Parte 1)

Uno de los desafíos más persistentes y sin resolver que enfrenta el protocolo Ethereum es el problema causado por el tamaño creciente de los datos estatales. Muchas operaciones en la cadena de bloques de Ethereum (crear una cuenta, escribir en una ranura de almacenamiento de contrato, enviar ETH a una nueva cuenta...) agregarán contenido de estado a Ethereum (es decir, agregarán objetos de datos a datos de estado) y todos los nodos completos. debe almacenar una cantidad completa de datos de estado para verificar nuevos bloques y crear nuevos bloques. Estas operaciones solo requieren que el remitente de la transacción pague una tarifa única que se mide de acuerdo con la cantidad de gas utilizada, pero causará costos permanentes y continuos a toda la red, porque los nodos necesitan almacenar estos nuevos datos (y los nodos que se unirán en el futuro también necesitan ser sincronizados Descargar estos datos durante el proceso).

Este es un desequilibrio significativo en el diseño del sistema y podría hacer que el sistema Ethereum sea cada vez más difícil de usar, ya que el estado está lleno de "datos basura" que ya no son útiles. El propósito de este artículo es explicar en detalle el origen del problema y algunas formas de resolverlo. Si podemos lograr una solución, esto allanará el camino para aumentar de manera segura y sustancial el límite de gas del bloque.

El campo de investigación discutido en este artículo aún está avanzando, y es probable que surjan en cualquier momento nuevas, mejores ideas y compensaciones más elegantes.

"Estado" se refiere a la información que debe tener un nodo para procesar bloques y transacciones recién generados. El estado es distinto del "historial", que es información sobre el tiempo pasado que los nodos pueden guardar para retransmitir o archivar en una fecha posterior, pero no se requiere para procesar la cadena de bloques.

En el protocolo Ethereum, la información de estado incluye:

Saldo ETH de la cuenta y nonce (número de serie)

Código de contrato inteligente

Artículo de almacenamiento de contrato inteligente (almacenamiento)

Datos relacionados con el mecanismo de consenso (hashes de bloque recientes, bloques de tío; los datos de consenso de prueba de participación también incluyen la clave pública del validador y su actividad registrada en la cadena de balizas, etc.)

La información histórica consiste en bloques y recibos antiguos. No hay códigos de operación en el EVM que le den acceso a bloques antiguos, transacciones antiguas y contenido y salidas de recibos, por lo que los nodos descartan esos datos y aún validan nuevos bloques, por lo que esta es información histórica.

La red Filecoin produjo casi 350 000 FIL en 24 horas: según los informes de IPFS100, los datos del navegador Filfox muestran que la altura de bloque actual de la red Filecoin es 1009065, la potencia informática efectiva de toda la red es 8.854EiB y la cantidad total prometida es alrededor de 99,66 millones de FIL. El número de mineros activos es 2904, la recompensa por bloque es 24.4615FIL, la producción en las últimas 24 horas es 345953FIL, el ingreso minero promedio en 24 horas es 0.0375FIL/TiB y la circulación actual de FIL es 156866288.

Las tres principales potencias informáticas efectivas actuales son: f0127595 (Space-Time Cloud) ocupa temporalmente el primer lugar con 132,70 PiB, f0123261 (LDPool) ocupa el segundo lugar con 115,11 PiB y f0142720 (RRM-Athena) ocupa el tercer lugar con 109,32 PiB. [2021/8/10 1:45:50]

El último elemento de la lista de información estatal anterior (datos relacionados con el mecanismo de consenso) se ha diseñado cuidadosamente para que tenga un tamaño limitado, por lo que no es necesario que nos preocupemos por él. Pero los tres primeros elementos son un gran problema. La escala de estos tres tipos de información estatal seguirá aumentando con el tiempo, porque nuevos usuarios seguirán uniéndose a la red, crearán nuevas cuentas, nuevos contratos, se unirán a contratos, recibirán tokens, etc.

Lo complicado es que gran parte del estado simplemente se queda allí después de ser usado (no tocado nuevamente); una vez que un usuario desactiva una aplicación, se generará un "estado basura"; ya no es útil, pero siempre estará allí.

En teoría, los usuarios pueden lograr que "la basura no caiga al suelo". Los usuarios solo pueden publicar contratos con condiciones de AUTODESTRUCCIÓN, y cuando ya no necesiten este contrato, llamar a este código de operación para eliminar este contrato y borrar su saldo de token; también pueden usar billeteras de contrato inteligente para pasar una cuenta de retención externa (EOA) existente para enviar transacciones sin generar un nuevo EOA (el estado de EOA no se puede eliminar).

ChainSafe lanzó una herramienta de desarrollo de productos de almacenamiento distribuido, ChainSafe Storage, versión de prueba: el 27 de julio, la compañía de tecnología canadiense ChainSafe lanzó una herramienta de desarrollo de productos de almacenamiento distribuido, ChainSafe Storage, versión de prueba, ChainSafe Storage es el backend de su servicio de almacenamiento anterior ChainSafeFiles, utilizando Write in Go idioma. ChainSafe Storage permite a los usuarios anclar o desanclar archivos públicamente a IPFS y hacer una copia de seguridad de ellos en Filecoin. El servicio también expone su API al proporcionar claves de API a pedido para respaldar la creación de productos basados ​​en Filecoin e IPFS. Además, ChainSafe Storage también es compatible con Amazon S3 para la integración con las soluciones de almacenamiento Web2 existentes. El producto se encuentra actualmente en fase de prueba. [2021/7/27 1:18:20]

Pero en la práctica, existen muy pocos incentivos de este tipo, y la complejidad técnica de una limpieza estatal adecuada es demasiado grande. Otorgar permiso a cualquier persona para llamar a SELFDESTRUCT de esta manera sería inapropiado en muchos contratos (¡lo que la gente quiere son aplicaciones "no rescindibles"!) y agregaría mucha complejidad a la experiencia del usuario y al código. De hecho, dado que SELFDESTRUCT tiene una utilidad extremadamente limitada y tiene muchos efectos secundarios, preferiría eliminar este código de operación para siempre. Si realmente queremos controlar el tamaño de los datos de estado, lo que necesito es una forma de que los nodos de la red descarten el "estado basura" que ya no se usa de manera predeterminada.

Una clase de soluciones a este problema se basa en el concepto de "clientes apátridas" (este artículo es la fuente de este concepto, y aquí está el video de la conferencia). La razón es hacer que la verificación de bloques ya no se base en mantener el estado global. En cambio, los bloques llevan evidencia (o "testigo") que demuestra el valor del estado al que acceden. Al igual que el diseño actual, el bloque contendrá una "raíz de estado", y el valor al que se accede se puede probar que corresponde a la raíz de estado (Nota del traductor: la prueba de Merkle es una técnica de prueba común). El esquema de árbol de estado actual de Ethereum (árbol de Merkel Patricia) admite una técnica de prueba de este tipo, al igual que esquemas más eficientes como árboles binarios o Verkle Tries. Los datos de testigos también dan fe de la corrección de la nueva raíz de estado después de que se haya procesado el bloque.

La apatridia viene en dos sabores:

Apatridia débil: el productor del bloque todavía necesita un estado completo para generar datos testigo para el bloque (producido por él mismo), pero la etapa de verificación del bloque puede ser apátrida;

Apatridia fuerte: ningún nodo necesita un plato giratorio completo. A su vez, es el remitente de la transacción quien debe proporcionar datos testigo, y el productor de bloques puede agregar estos datos. Los propios remitentes de transacciones son responsables de almacenar la parte del árbol de estado necesaria para generar datos testigo para la cuenta de interés.

La apatridia fuerte es una solución muy "elegante" porque transfiere completamente la responsabilidad al usuario, aunque para garantizar una buena experiencia de usuario en la práctica necesitamos crear algún tipo de protocolo para ayudar a los usuarios que no ejecutan nodos personales a mantener el estado y manejar situaciones en las que el usuario necesita interactuar con una cuenta inesperada. Forjar tal acuerdo es muy difícil.

Además, todos los tipos de apatridia aumentan el ancho de banda de datos requerido por la red; la apatridia fuerte también requiere transacciones para declarar las claves de las cuentas y los elementos de almacenamiento con los que interactúan (conceptualmente llamados "listas de acceso").

Una solución más suave se reduce a una forma diferente de esquema de "caducidad estatal". Un estado al que se debe seguir accediendo puede permanecer "activo"; un estado que no se ha visitado durante mucho tiempo se volverá "inactivo" (o "caducado"). Hay muchas opciones sobre qué mecanismo usar exactamente para actualizar el estado (como pagar el "alquiler" por adelantado o simplemente tener acceso a ese estado), pero el principio general es que, a menos que un objeto de estado se actualice explícitamente, está en alguna forma de falla estado en vivo. Por lo tanto, cualquier actividad de creación de nuevos objetos de estado (y actualización de objetos de estado existentes) solo puede convertirse en una carga para el nodo durante un período de tiempo, no una carga permanente como lo es ahora.

El estado muerto, como sugiere el nombre, no es parte del "estado"; un nodo que quiere procesar un bloque o crear un bloque no necesita almacenar el estado muerto. Sin embargo, ¡el estado inactivo no se elimina por completo! En todo tipo de propuestas de caducidad de estados se presupone alguna forma de “resucitar” un estado desactivado.

El principio general es que el estado activo se usa igual que en la actualidad, mientras que el estado inactivo se usa a través del mecanismo descrito anteriormente para clientes sin estado. Una transacción que revive un objeto en un estado caducado debe proporcionar una prueba (datos de testigos) de que el objeto formaba parte del estado desactivado. Para poder generar dichas pruebas, el propio usuario necesita almacenar y mantener al menos una parte del estado de inactivación (correspondiente a la parte del objeto de estado de inactivación que le interesa).

También hay muchos diseños para determinar las condiciones de caducidad. Los tipos más comunes son:

Renta Directa: La "Renta" se cobra bloque por bloque y se paga directamente con el saldo de cada cuenta (u otro objeto de estado); el saldo del objeto de estado cae a cero y la cuenta vence.

Valor de tiempo de vida restante: cada objeto de estado almacena un valor de "tiempo de vida restante", que se puede aumentar mediante el pago de una tarifa

Actualizar al llegar: cada objeto de estado almacena un valor de "tiempo de vida restante", y este valor se incrementa cada vez que se lee o escribe la cuenta

Todos los objetos de estado vencen periódicamente (por ejemplo, cada 6 meses): también conocida como la propuesta ReGenesis (traducción al chino)

Yo mismo prefiero cada vez más el esquema de "actualizar al tocar", porque (1) evita la necesidad de que las aplicaciones creen modelos económicos complejos para hacer que los usuarios paguen la renta estatal; y (2) asegura que la escala del estado activado tenga una claro Límite superior (límite superior de gas del bloque/consumo de gas del objeto en el estado de alcance × duración del estado de supervivencia). Un esquema que vence una gran cantidad de estados a intervalos regulares (también conocido como ReGenesis) tiene el mismo beneficio, pero tiene algunas compensaciones interesantes: el beneficio clave es que el esquema de vencimiento es más simple (no es necesario atravesar todo el árbol de estado para desactivar estados uno por uno), pero el problema clave es que cuando activa su propio objeto de estado después de pasar un punto de vencimiento, la cantidad de datos testigo que necesita estará relacionada con el punto de tiempo cuando alcance el objeto de estado.

La lógica de caducidad del estado se puede operar a nivel de cuenta o a nivel de una única ranura de almacenamiento. Actualmente, estoy totalmente a favor de implementar un esquema de vencimiento estatal a nivel de tragamonedas. Debido a que la cantidad de espacios de almacenamiento de muchas cuentas de contrato es ilimitada, cualquier usuario puede unirse al contrato y aumentar la cantidad de espacios de almacenamiento bajo el nombre del contrato (por ejemplo, Airdrops es un caso que ha ocurrido). Independientemente del esquema de vencimiento a nivel de cuenta utilizado, para limitar realmente el tamaño del estado, el monto del alquiler debe ser proporcional a la cantidad de espacios de almacenamiento en el contrato (o inversamente proporcional a la vida útil). Como resultado, los usuarios aún pueden imponer costos continuos permanentes al contrato y sus usuarios pagando solo una tarifa única.

Para resolver este problema, el contrato debe agregar una lógica interna compleja para "pasar" el alquiler de las operaciones de almacenamiento al usuario, o rediseñar su propio modelo de contrato para usar el código de operación CREATE2 para crear nuevos contratos y usar estos contratos para actuar como almacenamiento. tragamonedas No importa qué método se utilice, eventualmente se convertirá en un esquema de caducidad equivalente al nivel de ranura de almacenamiento. Por lo tanto, personalmente creo que solo deberíamos implementar esquemas de vencimiento estatales a nivel de espacio de almacenamiento de contrato.

Sin embargo, el esquema de caducidad en el nivel de la ranura de almacenamiento también tiene sus propias desventajas: cada ranura de almacenamiento debe agregar metadatos que indiquen cuándo caduca (o si se ha desactivado), lo que también significa que el "problema de conflicto de resurrección" (ver más abajo) afecta no solo cuentas, sino también ranuras de almacenamiento.

Tags：

MATIC