Interprete la nueva idea del puente ZKP: utilice el modelo de separación entre solicitante y probador ZKP para crear un puente entre cadenas descentralizado más seguro

PANews

2023-11-04 03:33:36

原文标题:Modelo de separación entre solicitante y probador ZKP para admitir ZK completo y ZK optimista

Autor original: 0x3d18, ZKPool

Compilador: Qianwen, ChainCatcher

Hay muchos casos de uso para las pruebas de conocimiento cero, incluidos los rollups, los puentes y los oráculos. Esto llevó al desarrollo de proyectos como ZK-Rollup, ZK-bridge y ZK-oracle.

Recientemente se han aplicado diseños híbridos y optimistas a la tecnología ZKP. Por ejemplo, Orbiter Finance ha propuesto el protocolo puente Optimistic ZK, mientras que Taiko ha propuesto una solución de rollup híbrido progresivo.

La ZK optimista asume que todas las transiciones de estado son correctas y no requiere una prueba inmediata de validez. Pero establece una ventana de impugnación predeterminada durante la cual cualquier participante puede disputar la actividad fraudulenta presentando una prueba de validez o una prueba de fraude.

Este diseño reduce el costo total de la prueba para los proyectos ZKP al tiempo que garantiza la seguridad al incentivar un sistema descentralizado de monitoreo de retadores y desafiar el fraude.

Protocolo de puente ZK optimista

Orbiter Finance es uno de los proyectos cross-rollup más conocidos. Propone “Protocolo Cross-Rollup de Orbiter: Optimista sobre la Mayoría Obediente, Arbitraje Duro para la Minoría Maliciosa”.

! [Interpretación de la nueva idea de puente ZKP: uso del modelo de separación entre solicitante y probador ZKP para crear un puente de cadena cruzada descentralizado más seguro] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-1b60a8b1ca-dd1a6f-cd5cc0.webp)

Proceso de Trading Cruzado Optimistic Rollup (de Orbiter Finance)

Define un diseño cross-rollup descentralizado, seguro y rentable, respaldado por la tecnología ZKP.

Diseño descentralizado de Orbiter

Hay varios factores importantes a tener en cuenta para un diseño de este tipo:

En primer lugar, el proyecto del puente en el pasado ha experimentado múltiples problemas de seguridad, que han causado pérdidas significativas a los usuarios. La centralización también conlleva riesgos de seguridad. Por lo tanto, la descentralización es esencial para tender puentes.

En segundo lugar, debe existir un mecanismo que garantice la precisión del flujo de transacciones entre la cadena de origen/rollup y la de destino.

Además, es esencial encontrar una forma rentable de generar dichas pruebas. En comparación con los árboles Merkle on-chain, ZKP es una opción viable con menos tarifas de gas.

En particular, para los puentes transversales, el costo es una consideración primordial y el objetivo de todo el diseño es minimizar los gastos. Esto significa que es fundamental reducir las transacciones en cadena y minimizar la cantidad de gas por transacción en cadena.

En el diseño de Orbiter, además del esquema de pago puente, hay otro esquema que requiere ZKP. En este escenario, un rol llamado “remitente” agrega información de transacciones agregadas cruzadas y la envía a L1 para garantizar que el distribuidor descentralizado reciba recompensas precisas.

Diseño de committer descentralizado de Orbiter

El protocolo de Orbiter asume que la mayoría de los participantes son infalibles y maneja con optimismo los eventos cross-rollup para garantizar una ejecución oportuna. Si se requirieran pruebas para cada transacción de acumulación cruzada, la ejecución de toda la transacción puente sería lenta. Como resultado, no es necesario generar pruebas en ausencia de comportamiento malicioso, lo que ahorra costos. Sin embargo, si el creador o el remitente detectan un comportamiento malicioso, el impugnador puede generar una prueba, y el remitente impugnado también debe presentar la prueba.

Diseño del puente Orbiter Optimistic zk

Modelo de separación de probadores de solicitantes ZKPool

Cuando se trata de utilizar la tecnología ZKP, hay diferentes modos disponibles:

Zk completo: En este modo, se requiere un ZKP para cada conversión. Esto se puede lograr a través de proyectos como ZK-bridge (por ejemplo, Polyheddra) o ZK-Rollup (por ejemplo, Scroll).
Zk optimista: En este modo, ZKP solo es necesario cuando se cuestiona la conversión. Taiko y Orbiter son un ejemplo de este patrón.

Zk completo y zk optimista

Al definir modelos abstractos, está claro que ZK-bridge y ZK-Rollup comparten algunas similitudes. En concreto, esta diferencia se refleja en la relación entre el solicitante de ZKP y el demostrador de ZKP, como se muestra en el siguiente diagrama. Aquí, el solicitante de ZKP hace referencia a un módulo que tiene la necesidad de generar un ZKP.

El escenario es el siguiente:

En el proyecto ZK-Rollup:

En el modo zk completo, el secuenciador funciona como un solicitante ZKP.
En el modo zk optimista, el retador actúa como solicitante de ZKP.

En el proyecto ZK-bridge:

En el modo all-zk, el creador actúa como solicitante de ZKP.
En el modo zk optimista, el retador actúa como solicitante de ZKP.

Solicitante de ZKP y probador de ZKP

Como se mencionó anteriormente, en un zk optimista, es posible que no siempre haya una tarea de prueba. Como resultado, si los solicitantes de ZKP y el probador de ZKP se combinan en el mismo módulo, el probador puede estar inactivo y es posible que su potencia de cálculo no se utilice por completo.

Si diseñamos un modelo de separación entre el solicitante y el probador y convertimos el probador en un grupo compartido, podemos aumentar la utilización del demostrador. Cuando el escenario optimista no se cuestiona, el probador puede asumir la tarea de prueba de otros proyectos ZKP. Esto significa que ZKPool juega un papel importante en el proyecto zk-bridge, especialmente cuando se combina Optimistic con otros.

ZKPool comparte el papel de probador de ZKP entre los solicitantes de ZKP

El modelo de separación suplicante-probador de ZKP se aplica no solo a los rollups y puentes, sino también a los oráculos y a todos los demás proyectos de ZKP.

Resumen

A partir de la información aportada, podemos extraer las siguientes conclusiones:

La tecnología ZKP es esencial para el proyecto ZKP, incluidos los rollups, puentes, oráculos y otros proyectos relacionados.
ZKPool nos permite tratar al creador/remitente de ZK-bridge y al secuenciador de ZK-Rollup como el mismo rol, denominados colectivamente solicitante ZKP
Al utilizar el modelo de separación entre solicitante y probador ZKP de ZKPool, puede mejorar la tasa de utilización de su probador. Este modelo también promueve la descentralización de todos los proyectos de ZKP.

Ver originales

Esta página puede contener contenido de terceros, que se proporciona únicamente con fines informativos (sin garantías ni declaraciones) y no debe considerarse como un respaldo por parte de Gate a las opiniones expresadas ni como asesoramiento financiero o profesional. Consulte el Descargo de responsabilidad para obtener más detalles.

1 me gusta