¿Cómo romper con la mentalidad Rollup e integrar la plataforma Web2 con Web3 con un marco más amplio y abierto?
Escrito por Wuyue, Geek Web3
**Introducción: **Este artículo presentará prospectivamente un paradigma de diseño de infraestructura Web3 que parece un poco único: Paradigma de consenso basado en almacenamiento (SCP). Aunque este modelo de diseño de producto, en teoría, es bastante diferente del modular convencional. soluciones blockchain como Ethereum Rollup, pero es muy factible en términos de facilidad de implementación y facilidad de conexión con la plataforma Web2, porque tiene Desde el principio, no tenía la intención de limitarme a un camino de implementación estrecho como Rollup. Quería utilizar un marco más amplio y abierto para ** integrar la plataforma Web2 y las instalaciones Web3 **, que se puede decir que es un cerebro. Un enfoque imaginativo y muy abierto.
Texto: Imaginemos una solución de expansión de cadena pública con las siguientes características:
- Tiene una velocidad comparable a las aplicaciones o intercambios Web2 tradicionales, superando con creces a cualquier cadena pública, L2, rollup, side chain, etc.
- No hay tarifa de gas y el costo de uso es casi 0.
- La seguridad de los fondos es alta, superando con creces la de las instalaciones centralizadas como los intercambios, inferior a Rollup pero mayor o igual a las cadenas laterales.
- La misma experiencia de usuario que Web2, sin ningún conocimiento de las claves públicas y privadas, billeteras, infraestructura, etc. de blockchain.
Esta solución es realmente muy emocionante: por un lado, básicamente ha logrado lo último en expansión de capacidad; por otro lado, también ha sentado una base muy sólida para la adopción masiva de Web3, básicamente eliminando la brecha entre Web2 y Web3. experiencia de uso.
Sin embargo, parece que no podemos imaginar cuántas soluciones pueden ser tan completas, porque de hecho hay muy poca discusión y práctica generalizada.
Usamos la expansión, un tema muy familiar, como introducción anterior. De hecho, SCP no se limita a la expansión. Su inspiración para el diseño proviene de los planes de expansión y las discusiones comunitarias de cadenas públicas como Bitcoin y Ethereum. Su visión y aplicación práctica es construir una nueva generación de infraestructura sin confianza, incluso una plataforma informática que no sea blockchain. **
Componentes básicos y principios de funcionamiento de SCP
En términos generales, **SCP también es como lo que las comunidades de Ethereum y Celestia llaman una “cadena de bloques modular”. **Tiene divisiones de módulos como capa de disponibilidad de datos, capa de ejecución, capa de consenso y capa de liquidación.
- Capa de disponibilidad de datos: La asume una cadena pública o instalaciones de almacenamiento ampliamente reconocidas y probadas como capa de disponibilidad de datos, como Ethereum, Arweave, Celestia, etc.
- Capa de ejecución: Un servidor utilizado para recibir transacciones de usuario y ejecutarlas, y al mismo tiempo enviar datos de transacciones firmadas por el usuario a la capa DA en lotes, similar al secuenciador de Rollup. Pero la capa de ejecución no necesariamente tiene una estructura de lista vinculada estilo blockchain, puede ser una base de datos + sistema informático completamente Web2, pero todo el sistema informático debe ser de código abierto y transparente.
- Capa de consenso: Está compuesta por un grupo de nodos, que extraen los datos enviados por la capa de ejecución a la capa DA y utilizan el mismo algoritmo que la capa de ejecución para operar con estos datos y confirmar si el resultado. La salida de la capa de ejecución es correcta y se puede utilizar como redundancia de prevención de desastres para la capa de ejecución. Los usuarios también pueden leer los datos devueltos por cada nodo en la capa de consenso para garantizar que no haya fraude en la capa de ejecución.
- Capa de liquidación: Está compuesta por un grupo de nodos y contratos o direcciones en otras cadenas. Se utiliza para manejar el comportamiento de los usuarios que recargan en SCP o retiran dinero de SCP. Es algo similar al modo de operación. de un puente de cadenas cruzadas. El nodo de la capa de liquidación controla la función de retiro de la dirección de recarga a través de contratos de firma múltiple o direcciones basadas en TSS. Al recargar, el usuario deposita activos en la dirección designada en la cadena, y al retirar, se envía una solicitud. Después de que el nodo de la capa de liquidación lee los datos, libera los activos mediante firma múltiple o TSS. El nivel de seguridad de la capa de liquidación depende del mecanismo entre cadenas adoptado.
Marco de práctica de SCP
Podemos entender el paradigma SCP a través del siguiente marco. Un producto que cumpla con el marco SCP puede tener funciones principales como recarga, transferencia, retiro, intercambio, etc., y puede ampliarse aún más sobre esta base. La siguiente imagen es un diagrama esquemático de dicho producto:
- La capa DA del proyecto utiliza la instalación de almacenamiento permanente Arweave, el círculo grande en la imagen.
- **Coordinador, la capa de ejecución. ** El usuario envía la transacción al coordinador, el coordinador realiza la operación y muestra los resultados de la operación, y luego envía los datos de entrada originales del usuario a la capa DA en lotes.
- Detector extrae los datos de la transacción original enviados por el coordinador de Arweave y utiliza el algoritmo coherente con el coordinador para verificar los datos y los resultados. El cliente del detector también es de código abierto y cualquiera puede ejecutarlo.
- **Watchmen, un grupo de testers que se encargan de la multifirma del sistema de retiro. **Las solicitudes de retiro se verificarán y liberarán según los datos de la transacción. Además, el vigilante también es responsable de firmar la propuesta.
Podemos ver el sistema completo, y el consenso que alcanzaron está ubicado fuera de la cadena. Este es el núcleo del paradigma de consenso de almacenamiento: abandona el sistema de consenso de nodos estilo blockchain y libera la capa de ejecución del consenso pesado. El proceso de confirmación solo requiere el trabajo de un servidor, logrando así un TPS y una economía casi ilimitados. Esto es muy similar a Rollup, pero SCP ha tomado un camino diferente al de Rollup, convirtiéndolo de un caso de uso dedicado para la expansión de capacidad a un nuevo modelo de transición de Web2 a Web3. **
El coordinador mencionado anteriormente es un servidor, pero esto no significa que el coordinador pueda hacer lo que quiera. De manera similar al clasificador de Rollup, después de que los datos originales enviados por los usuarios se envían en lotes en Arweave, cualquiera puede ejecutar el programa detector para verificarlos y compararlos con el estado devuelto por el coordinador. **Hasta cierto punto, esto es exactamente lo mismo que la idea de las aplicaciones de inscripción. **
Bajo esta arquitectura, un servidor y una base de datos centralizados no plantean un desafío fundamental. Este es también otro punto del paradigma SCP, que une y desacopla los dos conceptos de “centralización” y “entidad única”: **En un sistema sin confianza, puede haber componentes centralizados, **incluso puede ser un componente central. pero esto no afecta la desconfianza general.
Podemos gritar un eslogan de este tipo: “La próxima generación de infraestructura sin confianza no tiene que depender de protocolos de consenso, sino que deberían ser sistemas de código abierto y redes de nodos P2P”.
La intención original de las personas que inventan y usan blockchain es desconfiar de los libros de contabilidad consistentes, infalsificables, rastreables y otros fundamentos comunes, que están claramente establecidos en el libro blanco de Bitcoin. **Pero después de Ethereum, **ya sea el plan de expansión de la antigua cadena pública, o Rollup o blockchain modular, todos han formado una mentalidad: lo que hagamos debe ser una cadena de bloques (Consiste en el protocolo de consenso de los nodos), o una solución como Rollup que parece una cadena (solo tiene la estructura de datos de la cadena de bloques, pero los nodos no intercambian mensajes de consenso directamente).
Pero ahora, bajo el marco basado en SCP, incluso si no es una cadena de bloques, se pueden lograr una serie de requisitos como la falta de confianza, la coherencia del libro mayor, la no falsificación, la trazabilidad, etc. detalles de implementación más claros.
Capa de ejecución
La capa de ejecución es crucial en todo el sistema: lleva a cabo el proceso informático de todo el sistema y determina qué aplicaciones se pueden ejecutar en el sistema.
Infinitos entornos de ejecución posibles
En teoría, el entorno de ejecución en la capa de ejecución puede adoptar cualquier forma y las posibilidades son infinitas, dependiendo de cómo la parte del proyecto posicione su proyecto:
*Intercambio. Sobre la base de SCP, se puede construir un intercambio abierto, transparente y de alto TPS, que no solo puede tener las características de velocidad y costo cero de CEX, sino que también puede mantener la descentralización de DEX. La distinción entre CEX y DEX se vuelve aquí borrosa.
- Red de pagos. Similar a Alipay, PayPal, etc.
- Soporte de máquina virtual/blockchain para cargar programas/contratos. Cualquier desarrollador puede implementar cualquier aplicación en él, compartir todos los datos del usuario con otros programas y operar de acuerdo con las instrucciones del usuario.
**SCP, un modelo de diseño que admite entornos de ejecución arbitrarios, tiene sus beneficios únicos: **Ya no tiene que depender de ciertos componentes con bagaje histórico, especialmente el concepto de “abstracción de cuenta” exclusivo de la comunidad Ethereum, que es muy importante. a SCP Se dice que no es necesario por naturaleza.
Bajo la arquitectura SCP, no existe el concepto de abstracción de cuentas: puede usar cuentas estándar Web2 y cuentas blockchain a voluntad. Desde esta perspectiva, muchos casos de uso maduros de Web2 se pueden utilizar directamente en SCP sin repensar ni construir. Este puede ser el beneficio de SCP en comparación con Rollup. **
Transparencia y Asimetría
El sistema de cuentas se mencionó anteriormente. Los lectores sensibles deberían haber descubierto que aunque SCP puede usar el sistema de cuentas Web2, parece haber problemas al usarlo sin cambios.
¡Porque todo este sistema es completamente transparente! El uso directo del modelo de interacción usuario-servidor causará serios problemas, lo que resultará en una falta de seguridad para todo el sistema. Revisemos primero cómo funciona el modelo tradicional servidor-usuario:
1.Registro de cuenta: El usuario ingresa el nombre de usuario y la contraseña en la página de registro de la aplicación. Para proteger la contraseña del usuario, el servidor procesa la contraseña mediante una función hash después de recibirla. Para aumentar la complejidad del hash y proteger contra ataques a la tabla Rainbow, la contraseña de cada usuario a menudo se concatena con una cadena generada aleatoriamente (llamada “sal”) y se combina con un hash. **El nombre de usuario, el salt y el hash se almacenan en texto claro en la base de datos del proveedor de servicios y no se divulgan al público. **Pero aun así, todavía se necesitan tratamientos de seguridad y salazón para evitar ataques internos.
2. Inicio de sesión de usuario: Los usuarios ingresan su nombre de usuario y contraseña en el formulario de inicio de sesión. El sistema compara el valor hash de la contraseña procesada con el valor hash almacenado en la base de datos. Si los dos hashes coinciden, el usuario proporcionó la contraseña correcta y el proceso de inicio de sesión continúa.
3. Autenticación de operación: Después de pasar la autenticación de inicio de sesión, el sistema creará una sesión para el usuario. Normalmente, la información de la sesión se almacena en el servidor y el servidor envía una identificación (como un token) al navegador o la aplicación del usuario. Los usuarios ya no necesitan volver a ingresar su nombre de usuario y contraseña en operaciones posteriores: el navegador o la aplicación guardarán el identificador y lo incluirán en cada solicitud para indicar que tienen permiso del servidor asociado.
Revisemos el típico sistema de interacción blockchain-usuario de Web3:
1. Registro de cuenta: En realidad, no existe un proceso de registro de cuenta y no existe un sistema de nombre de usuario y contraseña. Las cuentas (direcciones) no necesitan registrarse, existen de forma natural y quien tiene la clave privada controla la cuenta. La clave privada la genera aleatoriamente la billetera de forma local y no implica el proceso de creación de redes.
2. Inicio de sesión del usuario: El uso de blockchain no requiere inicio de sesión. La mayoría de las dApps no tienen el proceso de inicio de sesión, pero se conectan a la billetera. Algunas dApps requerirán que los usuarios realicen una verificación de firma después de conectarse a la billetera para garantizar que el usuario realmente tenga la clave privada, en lugar de simplemente pasar una dirección de billetera al front-end.
** 3. Autenticación de operación: ** El usuario envía directamente los datos firmados al nodo. Después de la verificación, el nodo transmitirá la transacción a toda la red blockchain. Después de cumplir con el consenso de la red blockchain, se confirmará la operación del usuario. .
La diferencia entre los dos modos es causada por la simetría y la asimetría. En una arquitectura servidor-usuario, ambas partes guardan los mismos secretos. En una arquitectura de usuario blockchain, solo el usuario posee el secreto.
Aunque la capa de ejecución de SCP puede no ser una cadena de bloques, todos los datos deben sincronizarse con la capa DA visible públicamente. ** Por lo tanto, los métodos de verificación de operaciones y inicio de sesión utilizados por SCP deben ser asimétricos. **Pero como no queremos que los usuarios conserven claves privadas, usen billeteras y otras acciones engorrosas y malas experiencias que afecten la adopción a gran escala, también existe una fuerte demanda de que las aplicaciones creadas en SCP utilicen contraseñas de identificación tradicionales u OAuth. autenticación de tres partes para iniciar sesión. Entonces, ¿cómo combinar las dos?
Debido a la naturaleza asimétrica de la criptografía asimétrica y las pruebas de conocimiento cero, imaginé dos posibles soluciones:
- Si desea utilizar el sistema ID-contraseña, no puede incluir este módulo para guardar contraseña en el SCP, por lo que no será visible para otros. La capa de ejecución de SCP todavía utiliza las cuentas de clave pública y privada y la lógica de operación de la cadena de bloques, y no hay registro, inicio de sesión, etc. **El ID del usuario en realidad corresponde a una clave privada. ** Por supuesto, esta clave privada no se puede guardar en el lado del proyecto. Una solución más factible es utilizar 2-3 MPC para resolver el problema del almacenamiento centralizado sin permitir que los usuarios tengan la carga de usar claves privadas.
- **Cuando se utiliza OAuth para iniciar sesión, se puede utilizar JWT (Json Web Token) como método de autenticación. **Este método será un poco más centralizado que el anterior, porque esencialmente se basa en el servicio de inicio de sesión de terceros proporcionado por el principal fabricante de Web2 para la autenticación de identidad.
- Cuando utilice un tercero para iniciar sesión por primera vez, registre los campos en el JWT que representan la identidad del usuario y la identidad del proveedor de servicios en el sistema. En las operaciones posteriores del usuario, las instrucciones de operación se utilizan como entrada pública y el JWT en su conjunto se utiliza como testigo secreto para verificar la transacción de cada usuario con ZKP.
- Cada JWT tiene un límite de tiempo de vencimiento y el usuario también solicitará un nuevo JWT la próxima vez que inicie sesión, por lo que no es necesario conservarlo permanentemente. Además, este sistema también debe depender de JWK, que puede entenderse como la clave pública proporcionada por el fabricante para verificar JWK. Entonces, también vale la pena explorar cómo ingresar JWK en el sistema de manera descentralizada y cómo lidiar con la rotación de claves privadas en el futuro.
**No importa qué método se utilice, los costos de desarrollo e informática son más altos que los del método tradicional, pero este también es un precio necesario a pagar por la descentralización. **Por supuesto, si la parte del proyecto no cree que sea necesaria una descentralización extrema, o que hay diferentes hitos en diferentes etapas de desarrollo, está bien sin estos diseños, porque la descentralización no es blanco y negro, sino que hay un área gris. entre.
Privacidad
Los problemas de transparencia mencionados anteriormente no solo afectan el paradigma de interacción del usuario, sino que también afectan los datos del usuario. Los datos del usuario están expuestos directamente. Aunque no es un problema en blockchain, esto no es aceptable en algunas aplicaciones, por lo que los desarrolladores también pueden crear sistemas de transacciones privadas.
PEAJE
La forma en que cobra la capa ejecutiva es otro punto digno de atención. Porque enviar datos a la capa DA también requiere costos, incluida la operación de su propio servidor. El primer propósito principal de la cadena de bloques tradicional que cobra a los usuarios tarifas de gas es evitar que los usuarios dañen la red de transacciones al realizar una gran cantidad de transacciones repetidas, y el segundo es clasificar las transacciones según el gas. Web2 no tiene preocupaciones similares, por lo que solo existen conceptos básicos como inundaciones y DDoS.
**La capa de ejecución puede personalizar varias estrategias de cobro, como completamente gratuito o parcialmente cargado. **También puede beneficiarse de otros comportamientos como MEV (muy maduro en el secuenciador), actividades de mercado, etc.
Resistencia a la censura
La capa de ejecución no es resistente a la censura y, en teoría, puede negar las transacciones de los usuarios sin límite. En Rollup, la resistencia a la censura puede garantizarse mediante la función de recopilación forzada del contrato L1, mientras que la cadena lateral o cadena pública es una red blockchain distribuida completa y es difícil de censurar.
**Actualmente no existe una solución clara al problema de la resistencia a la censura, que es un problema del paradigma SCP. **
Capa de consenso
Esta capa está compuesta por nodos sueltos, que no forman activamente una red, por lo que no es una capa de consenso en sentido estricto, sino que solo se utiliza para confirmar el estado actual de la capa de ejecución al mundo exterior (como los usuarios).
Por ejemplo, si tiene dudas sobre el estado de estos nodos, puede descargar su cliente detector, que ejecutará el mismo código de programa que el coordinador. **
Sin embargo, esto es similar al Rollup: dado que los datos se envían en lotes, el estado devuelto al usuario por la capa de ejecución siempre es más nuevo que el de la capa DA. Esto implica un problema previo a la confirmación:
**La capa de ejecución brinda a los usuarios resultados finales suaves y preconfirmados, **porque aún no se han enviado a la capa DA;
**La capa de consenso proporciona a los usuarios una finalidad definitiva. **Es posible que a los usuarios no les importe especialmente esto, pero para aplicaciones como puentes entre cadenas, se debe seguir una finalidad estricta. Por ejemplo, el sistema de depósito y retiro del intercambio no creerá los datos transmitidos fuera de la cadena por el secuenciador Rollup y debe esperar hasta que los datos se carguen en Ethereum antes de ser reconocidos.
Además de usarse para confirmar resultados, la capa de consenso también juega un papel muy importante, que es como redundancia de prevención de desastres para la capa de ejecución. **Si la capa de ejecución se pone en huelga permanentemente y comete delitos graves, en teoría, cualquier capa de consenso puede hacerse cargo del trabajo de la capa de ejecución y recibir solicitudes de los usuarios. Si ocurre una situación tan grave, la comunidad debe elegir un nodo estable y confiable como servidor de la capa de ejecución.
Capa de asentamiento
Dado que SCP no es un Rollup, no puede lograr retiros sin confianza que no requieran intervención manual y que se basen completamente en criptografía y código de contrato inteligente como la capa de liquidación de retiros de Rollup. **El nivel de seguridad del puente entre cadenas SCP es el mismo que el de la cadena lateral o el del puente entre cadenas testigo de terceros. **Necesita depender de administradores autorizados de firmas múltiples para liberar activos. Lo llamamos modo testigo. .
Hacer que el puente testigo sea lo más descentralizado posible es un tema de muchos estudios de puentes entre cadenas. Debido a limitaciones de espacio, no entraremos en detalles aquí. En la práctica, una plataforma SCP bien diseñada también debe tener un socio acreditado de múltiples firmas de un puente descentralizado.
**Alguien puede preguntar por qué SCP no utiliza una cadena con contratos inteligentes como capa DA. **Esto permite una capa de liquidación basada en contratos y completamente sin confianza.
A largo plazo, siempre que se superen algunas dificultades técnicas, si la capa DA se coloca sobre la capa DA con contratos como Ethereum y se pueden construir los contratos de verificación correspondientes, SCP también puede obtener la misma seguridad de liquidación que Rollup. No es necesario utilizar varias firmas.
Pero en la práctica esta puede no ser la mejor opción:
- Ethereum no se utiliza específicamente para el almacenamiento de datos y el precio es demasiado alto en comparación con una cadena pública de almacenamiento de datos puro. **Para el paradigma SCP, los costos de almacenamiento suficientemente bajos o fijos son cruciales. **Solo de esta manera será posible admitir el rendimiento de nivel Web2.
2.** Esto demuestra que el sistema es muy difícil de desarrollar, porque SCP no solo puede simular EVM, sino también implementar cualquier lógica. **Y cuando miramos a equipos como Optimism, cuyas pruebas de fraude aún no están en línea, y lo difícil que es desarrollar zkEVM, podemos imaginar que es extremadamente difícil implementar pruebas de varios sistemas en Ethereum.
Por lo tanto, ** Rollup es una mejor solución práctica solo en circunstancias específicas ** Si planea implementar una solución más amplia y abierta, elimine el sistema EVM e incorpore más funciones Web2, entonces Ethernet La idea de Fang Rollup no es adecuado.
** SCP no es un determinado plan de expansión de la cadena pública, sino una arquitectura de plataforma informática Web3 más grande, por lo que obviamente no es necesario seguir la idea de Ethereum Layer 2. **
Una imagen que compara SCP y otros paradigmas
