Como sistema distribuido, la Capa 1 requiere altos costos de comunicación para llegar a un consenso, y una gran cantidad de cálculos también consumirá gas costoso. Por lo tanto, como una extensión de Layer1, el diseño de Layer2 puede mejorar efectivamente la eficiencia de Layer1. Pero desde esta perspectiva, el diseño de la Capa 2 todavía enfrenta el mismo gran problema que la Capa 1, que es cómo equilibrar el grado de descentralización y eficiencia.
zkRollup es una solución de expansión de capa 2 muy prometedora, que se realiza moviendo los cálculos fuera de la cadena y proporcionando pruebas de conocimiento cero a la cadena de capa 1. En la solución para realizar zkRollup, el sistema FOX adopta la estructura principal actual y existen principalmente dos tipos de nodos, a saber, secuenciador y carpeta. En términos simples, Sequencer es responsable de clasificar y empaquetar las transacciones enviadas por los usuarios y actualizar el estado en la cadena Layer 2. Folder es responsable de generar pruebas para las transacciones empaquetadas por Sequencer y enviarlas a Layer1.
Una pregunta interesante es si los nodos de la capa 2 deben descentralizarse y, de ser así, cómo diseñar incentivos para garantizarlo. Porque es concebible que la esencia de la baja eficiencia de Layer1 sea que, para lograr la descentralización, cada nodo necesita realizar una gran cantidad de cálculos y comunicaciones. Sin embargo, para desacoplar el proceso de cálculo se usa el sistema de Capa 2. Si todavía se usa en esta parte el modelo descentralizado que es completamente equivalente a la Capa 1, causará la congestión de la Capa 2 por la misma razón, por lo que es necesario realizar una compensación. hacerse aquí.
El diseño del mecanismo de incentivos es para alentar a los nodos a participar en el mantenimiento del sistema Layer2 ajustando la forma en que los nodos Layer2 obtienen tarifas de incentivo y equilibrando las tarifas pagadas a los nodos Layer2. En esencia, la fuente de las tarifas de incentivo recibidas por los nodos Layer2 es la misma que la de Ethereum, que proviene de las tarifas de gas que pagan los usuarios que envían transacciones. Este artículo discutirá en el sistema FOX, cómo los nodos FOX participan en el sistema para cobrar tarifas de transacción y las razones para hacerlo.
El papel del gas
Primero, revisemos el papel de las tarifas de gas en el sistema Ethereum. Los recursos informáticos de Layer1 son limitados. Cuando los usuarios envían una transacción, especificarán la tarifa de gas de transacción. La tarifa de gas está relacionada básicamente con la complejidad de la operación de ejecución de la transacción. Sobre esta base, los usuarios que están dispuestos a pagar una una tarifa de gas más alta puede obtener una implementación de transacción de mayor prioridad. Los incentivos de los mineros provienen de la suma de las tarifas de gas de los bloques empaquetados. Además, el mecanismo de tarifa de gas también puede prevenir contratos maliciosos (como bucles infinitos) y limitar el tamaño del bloque, lo que garantiza la seguridad hasta cierto punto.
Por lo tanto, se puede ver que el uso razonable de las tarifas de gas es esencialmente una programación y asignación razonables de los recursos informáticos en la cadena, y también es un juego de múltiples partes entre las partes del proyecto, los mineros y los usuarios. Un buen diseño del mecanismo de incentivos y el uso y distribución de tarifas son críticos para la operación del sistema.
Proceso de transacción en cadena
Cuando un usuario envía una transacción al grupo de transacciones en el sistema FOX, se agrega una tarifa para motivar al nodo FOX, y luego el nodo Secuenciador en el sistema tomará la transacción del grupo de transacciones para empaquetar y clasificar, donde cada transacción empaquetada constituye bloques de Capa 2, y Sequencer necesita realizar cálculos de transacciones y transmitir los resultados de los cálculos al contrato FOX de Capa 1, y Sequencer también necesita almacenar datos de transacciones en ZK-Ringer para garantizar la disponibilidad de datos. Posteriormente, los resultados de la clasificación y los resultados del cálculo del Secuenciador se pasarán al nodo Carpeta, y la Carpeta calculará correctamente la prueba (incluida la parte de agregación de la prueba) y la pasará al contrato Layer1. En este proceso, el resultado de la ejecución de la transacción por parte del Secuenciador se actualizará directamente a la Capa 2 después de que se complete la ejecución, y el nodo de tiempo en el que la Capa 1 aprueba realmente la transacción puede considerarse como posterior a la verificación de la prueba de la Carpeta.
Se puede observar que en este proceso, la tarifa de manejo inicial adjuntada por el usuario cubre varios propósitos:
Tarifa de manejo pagada a Sequencer
Tarifa de manejo pagada a la carpeta
Tarifa de gas para que Sequencer envíe los resultados de la transacción a Layer1
Cargos del secuenciador por almacenar información en ZK-Ringer
La tarifa de Gas por Carpeta llamando al contrato
Con este fin, debemos diseñar mecanismos específicos para motivar a todas las partes a participar.
Mecanismo de incentivos de FOX
El modelo de incentivos de FOX es relativamente nuevo. Primero, para equilibrar los problemas de descentralización y eficiencia, dividimos las funciones de los nodos en Nodos de secuenciador responsables de clasificar y ejecutar transacciones, y Nodos de carpeta responsables de generar y agregar pruebas de la corrección de la ejecución de transacciones. El nodo Carpeta de FOX adopta un modelo descentralizado, lo que significa que cualquier minero de FOX puede acceder a la red como generador de pruebas. Para alentar a más nodos a participar, la Carpeta que envíe con éxito la prueba correcta al contrato de Capa 1 puede obtener recompensas de tokens. Al mismo tiempo, para evitar desperdiciar poder de cómputo, señalamos que no solo el primer remitente de la prueba puede obtener recompensas, sino que dentro de un período de tiempo y una ventana de cantidad después de que el primer remitente de la prueba envíe con éxito (los parámetros específicos aquí variarán con condiciones del sistema), todos los certificadores correctos pueden ser recompensados.
Figura 1: La versión original del modelo de incentivos
Sin embargo, bajo este mecanismo, una Carpeta maliciosa tendrá un ataque muy astuto.
Cuando una Carpeta maliciosa, denotada como Adv, completa la generación de prueba, envía la prueba al contrato del Verificador en la Capa 1 para su verificación, por un lado, y por otro lado, se confabula con algunos nodos (o nodos controlados por la Carpeta), y will La prueba calculada se divulga a estos nodos, y luego pueden enviar directamente la prueba calculada por Adv sin su propio cálculo, y también pueden recibir una parte de la recompensa, y no han pagado ningún poder de cómputo durante este proceso. Perspectiva En otras palabras, Adv obtiene múltiples beneficios con menos poder de cómputo y dificulta que otros nodos compitan por Adv incluso si generan pruebas correctas.
Figura 2: Método de ataque de Carpeta maliciosa
En este ataque, el motivo del problema es que el Verificador no puede distinguir si la carpeta genera cada certificado de forma independiente, porque el valor del certificado es el mismo. Para evitar este problema, debemos agregar la información de dirección única de la Carpeta al certificado enviado por la Carpeta, de modo que el certificado enviado por cada Carpeta solo pueda generarse de forma independiente por sí mismo y no pueda ser enviado por otros nodos.
El método de incorporar esta información es muy inteligente, utilizando la heurística Fiat-Shamir (los lectores pueden consultar el artículo anterior de FOX "¿Cómo transformar las pruebas interactivas en pruebas no interactivas? ¡Heurística Fiat-Shamir!" para obtener detalles técnicos). Calculado de acuerdo con el proceso de generación de una prueba, uno de los pasos, el probador, es decir, la Carpeta necesita generar un valor de desafío aleatorio a través de una función hash, y solo necesita agregar la dirección de la Carpeta a la entrada de este hash, para que el valor del desafío y la Carpeta correspondan a la dirección, y siga siendo un número aleatorio que la Carpeta no puede predecir ni controlar.
Establecer estrictamente la seguridad de este método requiere el uso de los conceptos de funciones aleatorias teóricamente seguras en criptografía e indistinguibilidad, etc., que no discutiremos en detalle aquí. En términos simples, se puede considerar que debido a la seguridad de la función hash en sí misma y la seguridad de la estructura heurística de Fiat-Shamir, agregar un valor fijo como preimagen del hash no destruirá la imprevisibilidad de la salida, por lo que la la seguridad del algoritmo zkp original todavía está garantizada.
De esta forma, cada Carpeta debe generar pruebas de forma independiente y no puede utilizar directamente los resultados de otros nodos, consiguiendo así nuestro objetivo.
Figura 3: Esquema de incentivos modificado
Conclusión
Desde la perspectiva del importante papel de las tarifas de los nodos, este artículo presenta la conexión entre las tarifas y cómo motivar a los nodos para que participen en el mantenimiento del sistema. Al mismo tiempo, señala que un buen mecanismo de incentivos puede mantener efectivamente la seguridad del sistema. Sobre esta base, discutimos en detalle el mecanismo de incentivo para la carpeta de capa 2 adoptado por FOX, y explicamos la racionalidad de este enfoque y cómo usar hábilmente la heurística Fiat-Shamir para lograrlo.
referencias
"En profundidad｜Iteración y competencia: el camino hacia la expansión de la capa 2 de Ethereum" Guosheng Blockchain Research Institute
Ver originales
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
Hable sobre el mecanismo de incentivos de la Capa 2: otro maravilloso uso de la heurística Fiat-Shamir en FOX
Prefacio
Como sistema distribuido, la Capa 1 requiere altos costos de comunicación para llegar a un consenso, y una gran cantidad de cálculos también consumirá gas costoso. Por lo tanto, como una extensión de Layer1, el diseño de Layer2 puede mejorar efectivamente la eficiencia de Layer1. Pero desde esta perspectiva, el diseño de la Capa 2 todavía enfrenta el mismo gran problema que la Capa 1, que es cómo equilibrar el grado de descentralización y eficiencia.
zkRollup es una solución de expansión de capa 2 muy prometedora, que se realiza moviendo los cálculos fuera de la cadena y proporcionando pruebas de conocimiento cero a la cadena de capa 1. En la solución para realizar zkRollup, el sistema FOX adopta la estructura principal actual y existen principalmente dos tipos de nodos, a saber, secuenciador y carpeta. En términos simples, Sequencer es responsable de clasificar y empaquetar las transacciones enviadas por los usuarios y actualizar el estado en la cadena Layer 2. Folder es responsable de generar pruebas para las transacciones empaquetadas por Sequencer y enviarlas a Layer1.
Una pregunta interesante es si los nodos de la capa 2 deben descentralizarse y, de ser así, cómo diseñar incentivos para garantizarlo. Porque es concebible que la esencia de la baja eficiencia de Layer1 sea que, para lograr la descentralización, cada nodo necesita realizar una gran cantidad de cálculos y comunicaciones. Sin embargo, para desacoplar el proceso de cálculo se usa el sistema de Capa 2. Si todavía se usa en esta parte el modelo descentralizado que es completamente equivalente a la Capa 1, causará la congestión de la Capa 2 por la misma razón, por lo que es necesario realizar una compensación. hacerse aquí.
El diseño del mecanismo de incentivos es para alentar a los nodos a participar en el mantenimiento del sistema Layer2 ajustando la forma en que los nodos Layer2 obtienen tarifas de incentivo y equilibrando las tarifas pagadas a los nodos Layer2. En esencia, la fuente de las tarifas de incentivo recibidas por los nodos Layer2 es la misma que la de Ethereum, que proviene de las tarifas de gas que pagan los usuarios que envían transacciones. Este artículo discutirá en el sistema FOX, cómo los nodos FOX participan en el sistema para cobrar tarifas de transacción y las razones para hacerlo.
El papel del gas
Primero, revisemos el papel de las tarifas de gas en el sistema Ethereum. Los recursos informáticos de Layer1 son limitados. Cuando los usuarios envían una transacción, especificarán la tarifa de gas de transacción. La tarifa de gas está relacionada básicamente con la complejidad de la operación de ejecución de la transacción. Sobre esta base, los usuarios que están dispuestos a pagar una una tarifa de gas más alta puede obtener una implementación de transacción de mayor prioridad. Los incentivos de los mineros provienen de la suma de las tarifas de gas de los bloques empaquetados. Además, el mecanismo de tarifa de gas también puede prevenir contratos maliciosos (como bucles infinitos) y limitar el tamaño del bloque, lo que garantiza la seguridad hasta cierto punto.
Por lo tanto, se puede ver que el uso razonable de las tarifas de gas es esencialmente una programación y asignación razonables de los recursos informáticos en la cadena, y también es un juego de múltiples partes entre las partes del proyecto, los mineros y los usuarios. Un buen diseño del mecanismo de incentivos y el uso y distribución de tarifas son críticos para la operación del sistema.
Proceso de transacción en cadena
Cuando un usuario envía una transacción al grupo de transacciones en el sistema FOX, se agrega una tarifa para motivar al nodo FOX, y luego el nodo Secuenciador en el sistema tomará la transacción del grupo de transacciones para empaquetar y clasificar, donde cada transacción empaquetada constituye bloques de Capa 2, y Sequencer necesita realizar cálculos de transacciones y transmitir los resultados de los cálculos al contrato FOX de Capa 1, y Sequencer también necesita almacenar datos de transacciones en ZK-Ringer para garantizar la disponibilidad de datos. Posteriormente, los resultados de la clasificación y los resultados del cálculo del Secuenciador se pasarán al nodo Carpeta, y la Carpeta calculará correctamente la prueba (incluida la parte de agregación de la prueba) y la pasará al contrato Layer1. En este proceso, el resultado de la ejecución de la transacción por parte del Secuenciador se actualizará directamente a la Capa 2 después de que se complete la ejecución, y el nodo de tiempo en el que la Capa 1 aprueba realmente la transacción puede considerarse como posterior a la verificación de la prueba de la Carpeta.
Se puede observar que en este proceso, la tarifa de manejo inicial adjuntada por el usuario cubre varios propósitos:
Con este fin, debemos diseñar mecanismos específicos para motivar a todas las partes a participar.
Mecanismo de incentivos de FOX
El modelo de incentivos de FOX es relativamente nuevo. Primero, para equilibrar los problemas de descentralización y eficiencia, dividimos las funciones de los nodos en Nodos de secuenciador responsables de clasificar y ejecutar transacciones, y Nodos de carpeta responsables de generar y agregar pruebas de la corrección de la ejecución de transacciones. El nodo Carpeta de FOX adopta un modelo descentralizado, lo que significa que cualquier minero de FOX puede acceder a la red como generador de pruebas. Para alentar a más nodos a participar, la Carpeta que envíe con éxito la prueba correcta al contrato de Capa 1 puede obtener recompensas de tokens. Al mismo tiempo, para evitar desperdiciar poder de cómputo, señalamos que no solo el primer remitente de la prueba puede obtener recompensas, sino que dentro de un período de tiempo y una ventana de cantidad después de que el primer remitente de la prueba envíe con éxito (los parámetros específicos aquí variarán con condiciones del sistema), todos los certificadores correctos pueden ser recompensados.
Figura 1: La versión original del modelo de incentivos
Sin embargo, bajo este mecanismo, una Carpeta maliciosa tendrá un ataque muy astuto.
Cuando una Carpeta maliciosa, denotada como Adv, completa la generación de prueba, envía la prueba al contrato del Verificador en la Capa 1 para su verificación, por un lado, y por otro lado, se confabula con algunos nodos (o nodos controlados por la Carpeta), y will La prueba calculada se divulga a estos nodos, y luego pueden enviar directamente la prueba calculada por Adv sin su propio cálculo, y también pueden recibir una parte de la recompensa, y no han pagado ningún poder de cómputo durante este proceso. Perspectiva En otras palabras, Adv obtiene múltiples beneficios con menos poder de cómputo y dificulta que otros nodos compitan por Adv incluso si generan pruebas correctas.
Figura 2: Método de ataque de Carpeta maliciosa
En este ataque, el motivo del problema es que el Verificador no puede distinguir si la carpeta genera cada certificado de forma independiente, porque el valor del certificado es el mismo. Para evitar este problema, debemos agregar la información de dirección única de la Carpeta al certificado enviado por la Carpeta, de modo que el certificado enviado por cada Carpeta solo pueda generarse de forma independiente por sí mismo y no pueda ser enviado por otros nodos.
El método de incorporar esta información es muy inteligente, utilizando la heurística Fiat-Shamir (los lectores pueden consultar el artículo anterior de FOX "¿Cómo transformar las pruebas interactivas en pruebas no interactivas? ¡Heurística Fiat-Shamir!" para obtener detalles técnicos). Calculado de acuerdo con el proceso de generación de una prueba, uno de los pasos, el probador, es decir, la Carpeta necesita generar un valor de desafío aleatorio a través de una función hash, y solo necesita agregar la dirección de la Carpeta a la entrada de este hash, para que el valor del desafío y la Carpeta correspondan a la dirección, y siga siendo un número aleatorio que la Carpeta no puede predecir ni controlar.
Establecer estrictamente la seguridad de este método requiere el uso de los conceptos de funciones aleatorias teóricamente seguras en criptografía e indistinguibilidad, etc., que no discutiremos en detalle aquí. En términos simples, se puede considerar que debido a la seguridad de la función hash en sí misma y la seguridad de la estructura heurística de Fiat-Shamir, agregar un valor fijo como preimagen del hash no destruirá la imprevisibilidad de la salida, por lo que la la seguridad del algoritmo zkp original todavía está garantizada.
De esta forma, cada Carpeta debe generar pruebas de forma independiente y no puede utilizar directamente los resultados de otros nodos, consiguiendo así nuestro objetivo.
Figura 3: Esquema de incentivos modificado
Conclusión
Desde la perspectiva del importante papel de las tarifas de los nodos, este artículo presenta la conexión entre las tarifas y cómo motivar a los nodos para que participen en el mantenimiento del sistema. Al mismo tiempo, señala que un buen mecanismo de incentivos puede mantener efectivamente la seguridad del sistema. Sobre esta base, discutimos en detalle el mecanismo de incentivo para la carpeta de capa 2 adoptado por FOX, y explicamos la racionalidad de este enfoque y cómo usar hábilmente la heurística Fiat-Shamir para lograrlo.
referencias
"En profundidad｜Iteración y competencia: el camino hacia la expansión de la capa 2 de Ethereum" Guosheng Blockchain Research Institute