Un artículo para entender el modelo de proveedor estatal en Ethereum 2.0.

Este artículo fue escrito en colaboración con samwilsn y adietrichs, con gran ayuda de villanuevawill y el equipo de Quilt. Introducción La naturaleza sin estado de Ethereum 2.0 significa que las transacciones deben llevar el estado al que desean acceder. Más precisamente, para los proponentes de bloques (BP), además de contener transacciones, los bloques también deben contener todos los estados y la información testigo correspondiente a la que acceden todas las transacciones. Suponiendo que ni el usuario que creó la transacción ni el BP almacenan datos de estado, entonces la red necesita otro grupo para guardar y proporcionar estos estados. Este rol a menudo se denomina Proveedor de estado (SP). Independientemente de cómo los proponentes de bloques y los proveedores de estado intercambien el estado, es posible que los usuarios necesiten obtener el estado antes de crear transacciones. Por ejemplo, obteniendo el bytecode del contrato, estimando el costo del Gas o consultando el saldo de la cuenta. Esto significa que el proveedor estatal debe exponer una interfaz similar a la extracción para los usuarios. Aunque no hay una capa de incentivos, solo depender de proveedores estatales desinteresados ​​también puede proporcionar a los usuarios un estado (Ethereum 1.0 hace esto), y el pago también se puede realizar a través de canales estatales, agregando una capa de incentivos a los proveedores estatales. Criterios de comparación Se han propuesto varias ideas sobre cómo integrar a los proveedores estatales en el sistema general. En las siguientes secciones, presentaremos brevemente varios esquemas. Además de la descripción general, también compararemos las siguientes propiedades: Restricciones de acceso al estado Debido a que la ejecución de la transacción se basa en el estado en el momento de la ejecución, si el estado subyacente cambia, la ejecución de la transacción también cambiará. En particular, para algunas transacciones, la ubicación del acceso estatal puede cambiar. Esto podría deberse a declaraciones de salto simples (como  if), o la ubicación visitada se calcula en tiempo de ejecución. Nos referimos a ambos casos como Dynamic State Access (DSA). En el modo sin estado, esto complica el proceso de creación de transacciones. El problema es que puede que no sea posible proporcionar el estado a estas transacciones antes de tiempo (ya que no se sabe de antemano a qué estado global accederán estas transacciones). Los diferentes patrones de proveedores estatales se comportan de manera diferente en la medida en que respaldan estas transacciones. Si un modo restringe el acceso al estado dinámico, lo más probable es que Eth1 no se convierta en un entorno de ejecución (EE) de Eth2 y, a menudo, requerirá un manejo especial. Incentivos La remuneración de los proveedores estatales se compara de dos formas: 1. ¿Quién paga la remuneración y cómo se calcula la remuneración? 2. ¿Se apoya inicialmente a los proveedores estatales altruistas y, de ser así, se pueden agregar incentivos más adelante? Riesgo de centralización El riesgo de centralización de cada modelo es diferente: 1. ¿Quién puede revisar las transacciones y en qué medida? 2. ¿Cuánto estado puede almacenar un proveedor estatal? ¿Qué tipo de hardware necesito? 3. ¿Qué nivel de confianza mutua debe lograrse entre los proponentes de bloques y los productores estatales? Restricciones de tiempo Los productores de bloques transmiten bloques en un tiempo fijo. Así que consideramos específicamente cómo funcionan los diferentes modos dentro de ese límite de tiempo. Atribuibilidad del estado perdido En Eth1, una vez que se completan la verificación de la firma y los controles de saldo y nonce para una transacción determinada, los mineros pueden estar seguros de que recibirán la tarifa por incluir la transacción. En Eth2, si se le puede pagar al proponente del bloque depende de si el estado perdido es una falla atribuible. Si es así, incluso si una transacción falla debido a la pérdida de estado, el proponente del bloque aún puede recibir el pago. De lo contrario, la transacción de estado perdido en sí misma no se puede empaquetar, pero es posible que el proponente del bloque no la descubra hasta que se hayan ejecutado todas las transacciones (generalmente muy largas). (Nota del traductor: el pago aquí significa que el proponente del bloque debe cobrar la tarifa de transacción en la transacción empaquetada. Si se trata de un error no atribuible, entonces el proponente del bloque gasta el costo para empaquetar la transacción, pero no obtiene la transacción en el paquete). tarifa de transacción.) Si el proponente del bloque tiene que ejecutar transacciones para encontrar el error, pero estas transacciones no se pueden empaquetar (es decir, no pueden pagar la tarifa de transacción), entonces el proponente del bloque es vulnerable a una denegación de servicio con un costo casi nulo ataque Modo Direct Push Model (Modelo Direct Push) El usuario solicita directamente el estado necesario de uno o más proveedores de estado y luego envía la transacción con el estado a la red. El nodo mantiene el grupo de transacciones a procesar y actualiza la información testigo cada vez que se genera un nuevo bloque en la red. Cuando el proponente del bloque crea un bloque, selecciona un subconjunto de transacciones para empaquetar del conjunto de transacciones y las incluye en el nuevo bloque. El usuario que crea la transacción se convierte esencialmente en el único proveedor estatal de la transacción. En términos generales, no hay forma de garantizar que el estado proporcionado por el usuario pueda satisfacer todas las necesidades de acceso cuando las transacciones estén en cadena en el futuro. Por lo tanto, en el modo Direct Push, solo se pueden ejecutar transacciones con acceso de estado predecible. Debido a que solo se puede acceder a las transacciones utilizando el estado estático, los creadores de contratos también deben diseñar sus contratos para tener un acceso de estado predecible: se pueden usar anotaciones como listas de acceso, que detallan a dónde puede acceder el contrato durante el tiempo de ejecución. Este enfoque, combinado con un patrón que evita el acceso al estado dinámico (consulte esta publicación de blog relacionada de Vitalik en Eth1. Sin embargo, esto sería una desviación significativa del sistema Eth1 actual. Puede frustrar el plan de convertir Eth1 a Eth2. Incentivos Este modelo se basa únicamente en la red general de proveedores del estado. Como se indicó anteriormente, parece posible prescindir de un sistema de incentivos. Los sistemas de incentivos también se pueden agregar a través de canales de pago. Dado que cada usuario debe establecer un canal de pago con uno o más proveedores estatales, este enfoque debería ser particularmente complejo. Un solo proveedor estatal no puede censurar transacciones, ya que los usuarios pueden enviar varias consultas a varios proveedores estatales. Debido a que los proveedores estatales pueden conservar solo una parte del estado, los requisitos de hardware se pueden reducir según sea necesario. Los incentivos monetarios pueden alentar la centralización de algunos proveedores estatales, por lo que cuando los usuarios compran el estado a través de canales de pago, deben confiar en sus oponentes. No hay limitaciones de tiempo. El estado perdido se puede atribuir al usuario. En la mayoría de los casos, los proveedores de bloques pueden empaquetar transacciones con un estado insuficiente y aun así permitir que los usuarios paguen. La única excepción es cuando se pierde el estado requerido para la verificación inicial de la firma o el pago de la tarifa, en cuyo caso no se incluirá la transacción. De forma análoga al caso de Eth1, los nodos de la red pueden descartar dichas transacciones del grupo de transacciones. Para estas partes de la transacción inicial, se deben imponer algunas restricciones para maximizar la utilización del gas. Puntos clave Beneficios clave: Simple. No hay necesidad de proveedores de estatus especializados o sistemas de incentivos. No hay una restricción de tiempo particular. Principal desventaja: solo apto para transacciones en las que se conocen de antemano todas las necesidades de acceso del estado. Esto limita la funcionalidad de todo el sistema. Los problemas de compatibilidad no se pueden resolver, aunque hay algunas mitigaciones disponibles. En particular, bajo este modelo, Eth1 no puede convertirse en el entorno operativo de Eth2. Modelo de retransmisión Push (Relayed Push Model) Los usuarios envían transacciones de forma autónoma a un retransmisor (Relayer, un proveedor de estado profesional). El repetidor agrupa varias transacciones y adjunta el estado de la transacción, y transmite el paquete de transacciones agrupadas a la red. Los nodos mantienen un grupo de paquetes de transacciones pendientes. Cada vez que se genera un nuevo bloque, el repetidor actualizará el estado de la retransmisión del paquete de transacción y todos los nodos actualizarán la información testigo correspondiente. Cuando BP crea un bloque, selecciona los últimos paquetes de transacciones pendientes del grupo de paquetes de transacciones y los incluye en el nuevo bloque. En consecuencia, el sistema aún puede ejecutarse cuando se demuestra que los paquetes de transacciones en el conjunto de paquetes de transacciones no se pueden utilizar. Los repetidores solo anuncian la existencia de paquetes de transacciones. El proponente del bloque contactará directamente al retransmisor, obtendrá el paquete de transacción y lo incluirá en el nuevo bloque. sin límite. Siempre que el repetidor pueda enviar el estado al paquete de transacciones en cada intervalo de tiempo (intervalo) para garantizar que se puedan satisfacer las necesidades de acceso del estado, estará bien. Además, cada bloque nuevo contiene solo un paquete de datos, lo que evita la interferencia entre paquetes de transacciones. En realidad, diseñar un mecanismo de incentivos para los repetidores es bastante complicado, porque una vez que la información del estado y del testigo se hace pública, los usuarios y/o los BP tienen la oportunidad de eludir al testigo y recrear el paquete de transacciones ellos mismos. Dos soluciones posibles: 1. En ausencia de un conjunto de transacciones, el paquete de transacciones no es público. El repetidor vende el paquete de transacción adjunto al estado al proponente del bloque (la tarifa es un poco más baja que la tarifa de transacción), formando así un mercado de paquete de transacción. Existen algunos riesgos para el proponente del bloque: es posible que se haya incluido una transacción en otro bloque, lo que la convierte en una transacción no válida, o que la tarifa de transacción recibida es menor que la que anunció el retransmisor al vender. 2. Alternativamente, las transacciones pueden incluir pagos a un repetidor específico, con o sin un grupo de transacciones. El usuario se compromete a un período de exclusividad (es decir, algunos intervalos de tiempo), durante el cual el usuario no creará otras transacciones. Si el usuario firma dos o más transacciones al mismo tiempo durante el período exclusivo, será sancionado. Para hacer esto, EE debe proporcionar una forma de "cortar" a los usuarios. Pero debido a que los usuarios no bloquean los depósitos, no está claro cómo multar a los usuarios que no tienen suficiente saldo en la cuenta. El riesgo de centralización depende de qué incentivos de retransmisión se utilicen: 1. Dado que fusionar paquetes de transacciones es complejo (debido al acceso dinámico del estado), un mercado de paquetes de transacciones conduciría a una alta centralización y permitiría a los retransmisores individuales revisar las transacciones. Debido a los riesgos que los BP pueden sufrir como se indica arriba, los BP prefieren cooperar con repetidores conocidos y confiables. En comparación con estos retransmisores bien conocidos, los usuarios individuales no pueden proporcionar paquetes de transacciones con tarifas de transacción suficientemente altas. 2. El uso de un período de exclusividad y un grupo de transacciones proporcionará un alto grado de descentralización, pero a expensas de la comodidad del usuario y una implementación más compleja del grupo de transacciones. En teoría, cualquier usuario puede recuperar un paquete de transacciones del grupo de transacciones, agregar sus propias transacciones para expandir el paquete de transacciones y luego transmitir el paquete de transacciones con una tarifa de transacción más alta. Para admitir todos los tipos de transacciones, cualquier paquete de transacciones incluido en un bloque debe contener el estado más reciente. El repetidor debe descargar el bloque anterior, crear y enviar una actualización correspondiente al paquete de transacción al proponente del bloque, y el proponente del bloque incluirá el paquete de transacción actualizado en el nuevo bloque, todas estas acciones deben estar dentro de un intervalo de tiempo completado dentro de . La pérdida de estado se puede atribuir a los repetidores. El proponente del bloque puede pedirle al repetidor (o el repetidor elige voluntariamente) que adjunte una "transacción de reembolso" a una transacción, que se utiliza para reembolsar al proponente del bloque cuando la transacción falla debido a una pérdida de estado. Principal ventaja: Sin restricciones de acceso estatales. Un grupo de paquetes de transacciones por sí solo puede no ser suficiente, ya que los paquetes de transacciones son grandes (a diferencia de un grupo de transacciones único en Eth1) y tienen restricciones de tiempo estrictas. Sin un grupo de transacciones, los paquetes de transacciones no se pueden combinar, por lo que un bloque solo puede contener paquetes de transacciones propuestos por un único repetidor. Los repetidores pueden centralizar e introducir censura. Incluso con un grupo de transacciones, no está claro si la combinación de paquetes de transacciones será suficiente para aliviar por completo el problema de la censura. Los sistemas de incentivos son complejos. Pull Model (Modelo de extracción) Los usuarios envían transacciones a la red y los nodos mantienen un grupo de transacciones pendientes. Antes de crear un bloque, el proponente del bloque selecciona algunas transacciones pendientes del grupo de transacciones, forma un paquete de transacciones y lo envía a un proveedor de estado para solicitar el estado del paquete de transacciones. Después de recibir el estado, el proveedor de bloques empaqueta el paquete de transacciones en un nuevo bloque. Antes de que el proveedor de estado proporcione todo el estado, para permitir que los nodos intermedios y los proponentes de bloques verifiquen la validez de la transacción, el usuario debe adjuntar el mensaje testigo requerido para verificar la firma y la capacidad de pago de la transacción. Por lo tanto, esta parte debe estandarizarse en diferentes entornos de ejecución (EE) y todos los EE deben proporcionar una opción para la función de verificación más simple. Alternativamente, se puede utilizar un EE de retención de valor (VHEE). Cada transacción utiliza este VHEE para pagar tarifas. Los nodos en la red comprenderán VHEE y, por lo tanto, podrán verificar la validez de la transacción. En ambos casos, los nodos de la red necesitan actualizar la información testigo del estado adjunto cuando llegan nuevos bloques. El proponente del bloque no puede predecir el costo real del gas del paquete de transacción. Bajo condiciones especiales, cualquier transacción en el paquete de transacciones puede invalidar todas las transacciones posteriores de esta transacción, como reducir el saldo del remitente a 0. Para aliviar este problema, los proponentes de bloques "sobreagrupan", es decir, envían más transacciones a los proveedores estatales de las que esperan agrupar en un bloque. El proveedor de estado proporcionará el estado de estas transacciones hasta que se alcance el límite de bloques. Si se utiliza VHEE, la transacción puede tener datos adicionales adjuntos, que contienen una lista de direcciones de VHEE y la cantidad máxima que se puede retirar de esas direcciones. De esta forma, los proponentes de bloques pueden evitar que transacciones anteriores invaliden transacciones posteriores. No hay restricciones en las transacciones primarias. El proponente del bloque solo se comunicará con el proveedor del estado al crear el bloque para asegurarse de que el estado devuelto esté actualizado. Más importante aún, al agrupar las transacciones y solicitar el estado en unidades de paquetes de transacciones, el estado se adjunta en el contexto exacto. Este enfoque garantiza que el estado proporcionado sea siempre suficiente. Esto incluye una diferencia clave con el modo Direct Push: en el modo Direct Push, el estado se agrega antes de que se empaquete la transacción, lo que limita el acceso al estado. Debido a que el usuario debe incluir el estado de verificación de la firma y la capacidad de pago de la tarifa, técnicamente, las restricciones en la parte de la transacción son las mismas que se enumeran en el modelo Direct Push. Sin embargo, estas limitaciones son insignificantes en la práctica. Debido a que en Eth1, la verificación de firma y el pago de tarifas son un acceso de estado predecible, la compatibilidad entre Eth1 y Eth2 no se romperá. Además, para VHEE, su diseño garantizará un acceso de estado predecible, de modo que no sean necesarias más restricciones. El proponente del bloque puede pagar el estado proporcionado por el proveedor del estado a través del canal de pago u otros medios. De acuerdo con el grado de confianza de BP y el oponente SP, la tarifa se puede pagar de acuerdo con la cantidad de transacciones (esta es la minimización de la confianza), o la tarifa se puede pagar de acuerdo con el paquete de transacciones (esto es más eficiente). El proveedor debe guardar todos los estados, almacenar El requisito de cantidad es muy grande. También se espera que los proveedores estatales ejecuten paquetes de transacciones rápidamente y, por lo tanto, requieran poder de cómputo. Los proponentes de bloques pueden estar más inclinados a obtener el estado de su grupo de proveedores de estado de confianza, lo que reduce el riesgo de daño malicioso y, por lo tanto, aumenta el grado de centralización. Sin embargo, un solo proveedor estatal no puede revisar las transacciones, porque es el proponente del bloque el responsable de crear y ordenar los paquetes de transacciones

Tags：

SAND