Interpretación de SCP: Paradigma de infraestructura sin confianza fuera de la fórmula de acumulación

Autor: Wuyue, Geek Web3

**Introducción:**Este artículo presentará prospectivamente un paradigma de diseño de infraestructura Web3 que parece un poco inconformista: Paradigma de consenso de almacenamiento SCP (Paradigma de consenso basado en almacenamiento), aunque este modelo de diseño de producto es teóricamente bastante diferente de las soluciones modulares convencionales de Blockchain como Ethereum Rollup, pero en la simplicidad del aterrizaje y la dificultad de conectarse con la plataforma Web2, la viabilidad es muy alta Debido a que no tenía la intención de limitarse a un camino de implementación estrecho como Rollup desde el principio, quería utilizar un marco más amplio y abierto para fusionar la plataforma Web2 con la infraestructura Web3, lo que puede decirse que es un enfoque imaginativo y que abre el cerebro. Introducción: Este artículo presentará prospectivamente un paradigma de diseño de infraestructura Web3 algo inconformista: el Paradigma de Consenso de Almacenamiento (SCP) Aunque este modelo de diseño de producto es teóricamente bastante diferente de las soluciones modulares convencionales de Blockchain como Ethereum Rollup, es muy factible en términos de simplicidad de implementación y dificultad de conexión con plataformas Web2, porque no tiene la intención de limitarse a un camino de implementación estrecho como Rollup desde el principio, y quiere integrar la plataforma Web2 y las instalaciones Web3 con un marco más amplio y abierto, que se puede decir que es un enfoque imaginativo y que abre el cerebro.

Cuerpo: Imaginemos un esquema de escalado de cadena pública con las siguientes características:

• Tiene una velocidad comparable a las aplicaciones o exchanges tradicionales de Web2, superando con creces cualquier cadena pública, L2, rollup, sidechain, etc.
• No hay tarifa de gas y el costo de uso es casi nulo.
• Alta seguridad de los fondos, mucho más allá de las facilidades centralizadas como los exchanges, inferior a Rollup pero mayor o igual a Sidechain.
• La misma experiencia de usuario que Web2, sin ningún conocimiento de las claves públicas y privadas de la cadena de bloques, billeteras, infraestructura, etc.

Esta solución es realmente muy emocionante: por un lado, básicamente ha logrado lo último en escalado y, por otro lado, ha sentado una base sólida sobre la adopción masiva de Web3, básicamente eliminando la brecha entre la experiencia Web2 y Web3.

Sin embargo, parece que no podemos pensar en muchas soluciones que puedan ser tan completas, porque realmente hay muy poca discusión y práctica general.

Usamos el tema muy familiar del escalado como introducción arriba, de hecho, **SCP no se limita al escalado, **su inspiración de diseño proviene de Bitcoin, Ethereum y otras soluciones de escalado de cadenas públicas y discusiones de la comunidad. Su visión y aplicación práctica es construir una nueva generación de infraestructura Trustless e incluso una plataforma informática con una estructura no Blockchain. **

Componentes básicos de SCP y cómo funcionan

En términos generales, SCP también es como lo que las comunidades de Ethereum y Celestia llaman una “cadena de bloques modular”, con una capa de disponibilidad de datos, una capa de ejecución, una capa de consenso, una capa de liquidación y otros módulos.

Capa de disponibilidad de datos: Realizada por una cadena pública ampliamente reconocida y probada, o instalaciones de almacenamiento como capa de disponibilidad de datos, como Ethereum, Arweave, Celestia, etc. Capa de ejecución: Un servidor que recibe y ejecuta las transacciones de los usuarios, y envía los datos de las transacciones firmadas por los usuarios a la capa DA en lotes, de forma similar al secuenciador de Rollup. Sin embargo, la capa de ejecución no tiene que tener una estructura de lista enlazada al estilo Blockchain, puede ser completamente base de datos Web2 + sistema informático, pero todo el sistema informático debe ser de código abierto y transparente. Capa de consenso: Consiste en un grupo de nodos que extraen los datos enviados a la capa DA por la capa de ejecución y utilizan el mismo algoritmo que la capa de ejecución para calcular los datos para confirmar si la salida de resultados de la capa de ejecución es correcta, y se puede utilizar como redundancia de prevención de desastres de la capa de ejecución. Los usuarios también pueden leer los datos devueltos por cada nodo en la capa de consenso para asegurarse de que no haya fraude en la capa de ejecución. Capa de liquidación: consiste en un grupo de nodos y otros contratos o direcciones en la cadena, que se utiliza para procesar el comportamiento de los usuarios que depositan en SCP o se retiran de SCP, algo similar al modo de operación de los puentes de interacción entre cadenas. El nodo de la capa de liquidación controla la función de retiro de la dirección de depósito a través del contrato multifirma o la dirección basada en TSS. Al depositar, el usuario deposita los activos en la dirección especificada de la cadena, envía una solicitud al retirarlos y el nodo de la capa de liquidación lee los datos y libera los activos a través de multisig o TSS. El grado de seguridad de la capa de asentamiento depende del mecanismo de interacción entre cadenas adoptado.

Marco de práctica del SCP

El paradigma SCP puede entenderse a través del siguiente marco. Un producto que satisface el marco SCP puede tener funciones importantes como depósitos, transferencias, retiros, swaps, etc., y puede ampliarse aún más sobre esta base. El siguiente diagrama es un diagrama esquemático de dicho producto:

• La capa DA del proyecto utiliza la instalación de almacenamiento permanente Arweave, que es el círculo grande del diagrama. Coordinador, es decir, la capa de ejecución. **El usuario envía la transacción al coordinador, quien realiza el cálculo y presenta el resultado, y luego envía los datos de entrada originales del usuario a la capa DA en lotes. Detector, que extrae los datos de transacciones sin procesar enviados por el coordinador de Arweave y valida los datos y resultados utilizando un algoritmo coherente con el coordinador. El cliente del detector también es de código abierto y puede ser ejecutado por cualquier persona.
• **Watchmen, un grupo de detectores que se encargan de la multifirma del sistema de retirada. ** Las solicitudes de retiro se validan y liberan en función de los datos de la transacción. Además, el vigilante también es responsable de firmar la propuesta.

Podemos ver todo el sistema, y el consenso que logran está fuera de la cadena, que es el núcleo del paradigma de consenso de almacenamiento: abandona el sistema NodeConsensus al estilo Blockchain y permite que la capa de ejecución se deshaga del pesado proceso de comunicación y confirmación de consenso, y solo necesita hacer el trabajo de un servidor, para lograr un TPS y una economía casi ilimitados. Esto es muy similar a Rollup, pero SCP ha tomado un camino diferente al de Rollup, tratando de pasar de un caso de uso específico de escala 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. Al igual que el secuenciador de Rollup, después de enviar los datos sin procesar enviados por el usuario a Arweave en lotes, cualquiera puede ejecutar un programa de prueba para verificarlos y compararlos con el estado devuelto por el coordinador. Hasta cierto punto, esta es la misma idea que la aplicación de inscripciones. **

En esta arquitectura, un servidor o base de datos centralizados no supone un reto fundamental. Este es 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 un componente central, pero esto no afecta a los que no tienen confianza en general.

Podemos gritar tal eslogan: “La próxima generación de infraestructura sin confianza no tiene que depender de protocolos de consenso, sino que debe ser sistemas de código abierto y redes de nodos P2P”.

La intención original de las personas para inventar y usar Blockchain es sin confianza, el libro mayor es consistente, no falsificable, rastreable y otros fundamentos clichés, que se establecen claramente en el Libro Blanco de Bitcoin. Pero después de Ethereum, ya sea el esquema de escalado de la antigua cadena pública, o Rollup o Blockchain modular, todo el mundo se ha formado una mentalidad: lo que hacemos debe ser una Blockchain (que consiste en el Protocolo de Consenso del Nodo), o Rollup, que parece ser una solución de cadena (solo hay una estructura de datos de Blockchain, pero el Nodo no tiene un intercambio directo de mensajes de Consenso).

Pero ahora, en base al marco de SCP, aunque no se trate de una Blockchain, se pueden realizar una serie de requisitos como contabilidad sin confianza, consistente, no forge, trazabilidad, etc., por supuesto, la premisa es que haya detalles de implementación más claros.

Capa de ejecución

La capa de ejecución es crucial en el sistema general, lleva a cabo el proceso computacional de todo el sistema y también determina qué tipo de aplicaciones se pueden ejecutar en el sistema.

Infinito entorno de ejecución posible

Teóricamente, el entorno de ejecución en la capa de ejecución se puede realizar de cualquier forma, y las posibilidades son infinitas, dependiendo de cómo el equipo del proyecto posicione su proyecto:

*Intercambiar. Basado en SCP, se puede construir un intercambio abierto, transparente y de alto TPS, que puede tener las características de velocidad CEX y costo cero, manteniendo la descentralización de DEX. La distinción entre CEX y DEX se vuelve borrosa aquí.

• Red de pagos. Similar a Alipay, PayPal, etc.
• Soporte para máquinas virtuales/cargadores de Blockchain/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 patrón de diseño que admite entornos de ejecución arbitrarios, tiene sus propios beneficios únicos: ya no tiene que depender de ciertos componentes con bagaje histórico, especialmente el concepto de “abstracción de cuentas” creado por la comunidad de Ethereum, que es inherentemente indeseable para SCP.

Bajo la arquitectura SCP, no existe el concepto de abstracción de cuentas: puede adoptar libremente cuentas estándar Web2 y cuentas Blockchain. Desde esta perspectiva, muchos casos de uso maduros de Web2 no necesitan ser repensados y construidos para trabajar directamente en SCP. Este puede ser el beneficio de los SCP sobre los Rollups. **

Transparencia y asimetría

El sistema de cuentas mencionado anteriormente, y los lectores sensibles deberían haber notado que, aunque SCP puede aprovechar el sistema de cuentas de Web2, parece ser problemático usarlo tal como está.

Debido a que todo el sistema es completamente transparente, el uso directo del modelo de interacción usuario-servidor causará problemas graves, lo que resultará en ninguna seguridad. Repasemos cómo funciona el modelo tradicional de servidor-usuario:**

1. Registro de cuenta: El usuario ingresa el nombre de usuario y contraseña en la página de registro de la aplicación. Para proteger la contraseña del usuario, el servidor procesará la contraseña a través de una función hash después de recibirla. Para aumentar la complejidad del hash y defenderse de los ataques de la tabla arcoíris, la contraseña de cada usuario suele estar conectada a una cadena de cadenas generadas aleatoriamente (llamadas “sales”) y se hashean juntas. **Los nombres de usuario, las sales y los hashes se almacenan en texto plano en la base de datos del proveedor de servicios y no están disponibles públicamente. Pero aun así, es necesario añadir sal y un tratamiento seguro, uno para evitar fantasmas internos, y el otro para prevenir ataques.

2. Inicio de sesión del usuario: Los usuarios ingresan su nombre de usuario y contraseña en el formulario de inicio de sesión. El sistema compara el hash de contraseña procesado con el valor hash almacenado en la base de datos. Si los dos hashes coinciden, lo que indica que el usuario ha proporcionado la contraseña correcta, el proceso de inicio de sesión continúa.

3. Autenticación de la operación: Después de pasar la verificació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 un servidor y el servidor envía un identificador (por ejemplo, o token) al navegador o la aplicación del usuario. El usuario ya no tiene que volver a introducir el nombre de usuario y la contraseña para el siguiente paso: el navegador o la aplicación guarda el identificador y adjunta un identificador a cada solicitud, lo que indica que tiene permiso del servidor asociado.

Repasemos el típico sistema de interacción entre usuarios y usuarios de Web3 Blockchain:

1. Registro de cuenta: Prácticamente no hay proceso de registro de cuenta y no hay un sistema de nombre de usuario y contraseña. La cuenta (dirección) no requiere registro, existe de forma natural y quien tiene su clave privada controla la cuenta. La clave privada es generada aleatoriamente localmente por la billetera y no implica el proceso de red.

2. Inicio de sesión del usuario: El uso de la cadena de bloques no requiere un inicio de sesión, y la mayoría de las dApps no tienen el proceso de inicio de sesión, sino que se conectan a la billetera. Algunas dApps requerirán que los usuarios firmen y verifiquen después de conectarse a la billetera para asegurarse de que el usuario realmente tenga la clave privada, en lugar de simplemente pasar una WalletAddress a la interfaz.

3. Autenticación de la operación: el usuario envía directamente los datos firmados al nodo, y el nodo transmitirá la transacción a toda la red Blockchain después de la verificación, y la operación del usuario se confirmará después de cumplir con el consenso de la red Blockchain.

La diferencia entre los dos modos es causada por la simetría y la asimetría. En una arquitectura de servidor-usuario, ambas partes tienen los mismos secretos. En la arquitectura Blockchain-User, solo el usuario tiene los secretos.

Aunque la capa de ejecución de SCP no puede ser una cadena de bloques, todos los datos deben sincronizarse con la capa DA visible públicamente, por lo que el método de autenticación de inicio de sesión y operación utilizado por SCP debe ser asimétrico. Sin embargo, debido a que no queremos tener acciones engorrosas y una experiencia deficiente que afecte la adopción masiva, como permitir que los usuarios conserven claves privadas y usen billeteras, las aplicaciones creadas en SCP también tienen una gran necesidad de usar contraseñas de identificación tradicionales o inicios de sesión de autenticación de terceros de OAuth, entonces, ¿cómo combinar los dos?

Debido a la naturaleza asimétrica de la criptografía asimétrica y los pares de prueba de conocimiento cero, imagino dos escenarios posibles:

• Si desea utilizar el sistema ID-contraseña, puede dejar este módulo de almacenamiento de contraseñas fuera del SCP, para que nadie más pueda verlo. La capa de ejecución SCP sigue utilizando las cuentas de clave pública y privada de la cadena de bloques y la lógica de operación, sin registro, inicio de sesión, etc. El ID del usuario corresponde en realidad a una clave privada. ** Por supuesto, esta clave privada no se puede mantener en el lado del proyecto, y la solución más factible es usar 2-3 MPC para resolver el problema del almacenamiento centralizado, sin permitir que los usuarios usen la clave privada. Cuando se confía en el inicio de sesión de OAuth, JWT (Json Web Token) se puede utilizar como medio de autenticación. **Este método estará ligeramente más centralizado que el anterior, porque esencialmente necesita depender del servicio de inicio de sesión de terceros proporcionado por los fabricantes de Web2 como autenticación de identidad.

• Cuando inicie sesión con un tercero 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, la instrucción de operación se utiliza 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 una fecha de vencimiento y los usuarios solicitarán un nuevo JWT la próxima vez que inicien sesión, por lo que no es necesario conservarlo para siempre. Además, este sistema también debe basarse en JWK, que puede entenderse como la clave pública proporcionada por la gran fábrica para verificar JWK. Por lo tanto, también vale la pena explorar cómo introducir la descentralización JWK en el sistema y cómo lidiar con la rotación de claves privadas en el futuro.

De cualquier manera, es más caro de desarrollar y calcular que los métodos tradicionales, pero también es un precio necesario a pagar por la descentralización. ** Por supuesto, si el equipo del proyecto no cree que la descentralización final sea necesaria, o hay diferentes hitos en diferentes etapas de desarrollo, está bien tener estos diseños, porque la descentralización no es blanco o negro, sino que hay un área gris en el medio.

Privacidad

Los problemas de transparencia mencionados anteriormente tienen un impacto no solo en el paradigma de interacción del usuario, sino también en los datos del usuario. Los datos del usuario se exponen directamente. Aunque esto no es un problema en Blockchain, no es muy aceptable en algunas aplicaciones, por lo que los desarrolladores también pueden construir sistemas de transacciones privadas.

Cargo

La forma en que se carga la capa de ejecución es otro punto de preocupación. Esto se debe a que también hay costos asociados con el envío de datos a la capa DA, incluido el funcionamiento de sus propios servidores. El primer propósito principal de la cadena de bloques tradicional para cobrar a los usuarios tarifas de gas es evitar que los usuarios deslicen una gran cantidad de transacciones repetitivas para interrumpir la red de transacciones, y el segundo es clasificar las transacciones según el gas. La Web2 no tiene preocupaciones similares, por lo que sólo hay conceptos básicos como las inundaciones y los DDoS.

La capa de ejecución puede personalizar varias estrategias de carga, como la carga completamente gratuita o parcial, y también puede monetizar otros comportamientos como MEV (que es muy maduro en el secuenciador), actividades de marketing, etc.

Resistencia a la censura

La capa de ejecución no es resistente a la censura y, en teoría, puede rechazar las transacciones de los usuarios indefinidamente. En Rollup, la resistencia a la censura puede estar garantizada por la función de agregación forzada del contrato L1, mientras que la Sidechain o cadena pública es una red Blockchain distribuida completa, que también es difícil de revisar.

**Actualmente no hay una solución clara al problema de la resistencia a la censura, que es un problema con el paradigma SCP. **

Capa de consenso

Esta capa se compone de nodos sueltos, y estos nodos no forman activamente la red, por lo que no es estrictamente una capa de consenso, 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 salud de estos nodos, puede descargar su cliente detector, que ejecuta el mismo código de programa que el coordinador. **

Sin embargo, esto es similar a Rollup, ya que debido a que los datos se envían en lotes, la capa de ejecución siempre devuelve un estado más reciente al usuario que la capa DA. Esto implica un problema de confirmación previa:

La capa de ejecución proporciona al usuario el resultado de la confirmación previa y la finalización suave, ya que aún no se ha enviado a la capa DA;

** La capa de consenso proporciona a los usuarios una finalidad dura. Es posible que a los usuarios esto no les importe especialmente, pero para aplicaciones como los puentes de interacción entre cadenas, se debe seguir la finalidad estricta. Por ejemplo, el sistema de depósito y retiro del exchange no confiará en los datos transmitidos por el serializador Rollup fuera de la cadena, y debe esperar a que estos datos se carguen en Ethereum antes de ser reconocidos.

Además de utilizarse para confirmar los resultados, la capa de consenso también desempeña un papel importante, que es la redundancia ante desastres como capa de ejecución. ** Si la capa de ejecución ataca permanentemente y causa un mal grave, en este momento, teóricamente cualquier capa de consenso puede hacerse cargo del trabajo de la capa de ejecución y recibir solicitudes de los usuarios. Si se produce una situación tan grave, la comunidad debe elegir un nodo estable y fiable como servidor para la capa de ejecución.

Capa de asentamiento

Dado que SCP no es un Rollup, no puede lograr retiros sin confianza basados completamente en criptografía y código de contrato inteligente sin intervención humana como la capa de liquidación de retiros de Rollup. Los puentes de interacción entre cadenas SCP son los mismos que los puentes de interacción entre cadenas laterales o testigos de terceros, y deben depender de administradores de firmas múltiples autorizados para liberar activos, lo que llamamos modelo testigo.

La descentralización del puente testigo en la medida de lo posible es objeto de muchos estudios de interacción entre cadenas. Debido a limitaciones de espacio, no me extenderé aquí. Una plataforma SCP bien diseñada también debe contar con socios multifirma de Decentralization Bridge de buena reputación en la práctica.

Uno podría preguntarse ¿por qué SCP no usa cadenas con contratos inteligentes como una capa DA? Esto puede hacer una capa de liquidación que da contratos y es completamente confiable.

A largo plazo, siempre y cuando se superen algunas dificultades técnicas, si la capa DA se coloca en una capa DA con contratos como Ethereum, y se puede construir el contrato correspondiente para la verificación, SCP también puede obtener la misma seguridad de liquidación que Rollup, sin necesidad de utilizar multifirma.

Pero en la práctica esto no es necesariamente óptimo:**

1. Ethereum no se utiliza específicamente para la preservación de datos, y el precio es demasiado alto en comparación con la cadena pública de almacenamiento de datos puros. Para el paradigma SCP, un costo de almacenamiento suficientemente bajo o fijo es crucial. Solo de esta manera se puede admitir el rendimiento a nivel de Web2.

2. Demostrar que el sistema es muy difícil de desarrollar, porque SCP no solo puede simular EVM, sino también implementar cualquier lógica. ** Teniendo en cuenta el hecho de que equipos como Optimism todavía no están en línea para las pruebas de fraude, y la dificultad del desarrollo de zkEVM, podemos imaginar que es extremadamente difícil implementar las pruebas de varios sistemas en Ethereum.

Por lo tanto, la solución Rollup solo es más práctica en situaciones específicas, y si planea implementar un enfoque más amplio y abierto que se aleje del sistema EVM y se adentre en más funciones Web2, la idea de Ethereum Rollup no es apropiada.

**SCP no es un esquema de escalado de cadena pública, sino una arquitectura de plataforma informática Web3 más grande, por lo que obviamente no hay necesidad de seguir la idea de la capa 2 de Ethereum. **

Un diagrama comparando SCP con otros paradigmas