Introducción:

Este artículo proporciona una introducción prospectiva a un paradigma de diseño de infraestructura Web3 algo no convencional: el Paradigma de Consenso Basado en Almacenamiento (SCP). Este modelo de diseño diverge significativamente de soluciones de blockchain modular de corriente principal como los Rollups de Ethereum en teoría. Sin embargo, demuestra una alta viabilidad en términos de simplicidad en la implementación e integración con plataformas Web2. SCP no pretende limitarse a un camino estrecho de realización como los Rollups. En cambio, tiene como objetivo adoptar un marco más amplio y abierto para fusionar plataformas Web2 con la infraestructura Web3. Este enfoque se puede ver como altamente imaginativo e innovador.

Imaginemos una solución de escalabilidad de blockchain público con las siguientes características:

• Tiene velocidades comparables a las aplicaciones o intercambios tradicionales de Web2, superando con creces cualquier blockchain pública, Capa 2 (L2), rollups, sidechains, etc.

• No hay tarifas de gas y el costo de uso es casi cero.

• Alta seguridad financiera, superando a las instalaciones centralizadas como intercambios, inferior a Rollups pero mayor o igual a sidechains.

• Una experiencia de usuario idéntica a Web2, sin necesidad de conocimientos sobre claves públicas y privadas de blockchain, monederos, infraestructura, etc.

Una solución así es realmente emocionante: por un lado, ha alcanzado esencialmente la cima en cuanto a escalabilidad; por otro lado, sienta una base sólida para la adopción masiva de Web3, en esencia cerrando la brecha entre las experiencias de usuario de Web2 y Web3. Sin embargo, parece que tenemos pocas soluciones integrales como esta, ya que las discusiones y prácticas principales son realmente demasiado pocas.

Utilizamos el conocido tema de la escalabilidad como introducción anteriormente, pero SCP no se limita a los casos de uso de escalabilidad. Su inspiración de diseño realmente proviene de las soluciones de escalabilidad y las discusiones comunitarias de blockchains públicos como Bitcoin y Ethereum. Su visión y aplicación práctica es construir una nueva generación de infraestructura sin confianza, incluso plataformas computacionales que no se basan en estructuras de blockchain.

Componentes básicos y principios de funcionamiento de SCP

En general, SCP, como el "blockchain modular" mencionado por las comunidades de Ethereum y Celestia, tiene varios módulos como una capa de disponibilidad de datos, capa de ejecución, capa de consenso y capa de liquidación.

• Capa de Disponibilidad de Datos: Manejada por una cadena de bloques pública ampliamente reconocida y bien probada, o instalaciones de almacenamiento que sirven como capa de disponibilidad de datos, como Ethereum, Arweave, Celestia, etc.

• Capa de ejecución: Un servidor, utilizado para recibir transacciones de usuarios y ejecutarlas, mientras también envía por lotes los datos de transacciones firmados a la capa DA, similar a los secuenciadores en Rollups. Sin embargo, la capa de ejecución no necesita necesariamente una estructura de cadena estilo blockchain; puede ser completamente un sistema de base de datos + computación Web2, pero todo el sistema de computación debe ser de código abierto, con transparencia.

• Capa de consenso: Compuesta por un grupo de nodos que extraen datos enviados a la capa DA por la capa de ejecución y utilizan el mismo algoritmo que la capa de ejecución para procesar estos datos, confirmando si la salida de la capa de ejecución es correcta y puede servir como redundancia de recuperación de desastres para la capa de ejecución. Los usuarios también pueden leer los datos devueltos por los nodos de la capa de consenso para asegurarse de que no haya comportamiento fraudulento en la capa de ejecución.

• Capa de Liquidación: Compuesta por un grupo de nodos y contratos o direcciones en otras cadenas, responsable de manejar los depósitos de usuarios en SCP, o retiros de SCP, algo similar a la operación de puentes entre cadenas. Los nodos de la capa de liquidación controlan la función de retiro de la dirección de depósito a través de contratos multisig o direcciones basadas en TSS. Para los depósitos, los usuarios transfieren activos a una dirección designada en su cadena; para los retiros, envían una solicitud, y después de que los nodos de la capa de liquidación lean los datos, liberan los activos a través de multisig o TSS. El nivel de seguridad de la capa de liquidación depende del mecanismo entre cadenas utilizado.

Marco de práctica SCP

Podemos entender el paradigma de SC a través del siguiente marco. Un producto que cumple con el marco de SC puede tener características principales como depósito, transferencia, retiro, intercambio, etc., y puede expandirse aún más. A continuación se muestra un diagrama esquemático de dicho producto:

• La capa DA de este proyecto utiliza la instalación de almacenamiento permanente Arweave, representada por el círculo grande en el diagrama.
• El Coordinador, o la capa de ejecución, es donde los usuarios envían sus transacciones. El Coordinador ejecuta cálculos, muestra los resultados y luego agrupa los datos de entrada originales de los usuarios y los envía a la capa DA.
• El Detector extrae los datos originales de transacción enviados por el Coordinador desde Arweave, y utilizando el mismo algoritmo que el Coordinador, valida los datos y resultados. El cliente del Detector también es de código abierto, lo que permite que cualquiera lo ejecute.
• Los Watchmen, un grupo de Detectores, gestionan el sistema de firma múltiple del sistema de retiro. Validan y autorizan solicitudes de retiro basadas en datos de transacciones. Además, los Watchmen son responsables de firmar propuestas.

Podemos ver que el consenso logrado por todo el sistema es completamente fuera de la cadena, que es el núcleo del paradigma de consenso de almacenamiento. Abandona el sistema de consenso de nodos típico de las blockchains, liberando la capa de ejecución de los pesados procesos de comunicación y confirmación de consenso. Esto le permite funcionar de manera eficiente como un solo servidor, logrando así casi ilimitadas TPS y rentabilidad. Este aspecto es muy similar a los Rollups, pero SCP (Paradigma de Consenso de Almacenamiento) toma un camino diferente a los Rollups. SCP intenta hacer la transición de un caso de uso específico de escalabilidad a un nuevo modo de transición de Web2 a Web3. El Coordinador mencionado anteriormente es un servidor, pero esto no significa que el Coordinador pueda actuar arbitrariamente. Similar al secuenciador en los Rollups, después de enviar por lotes los datos originales de los usuarios en Arweave, cualquiera puede ejecutar el programa Detector para verificarlo y compararlo con el estado devuelto por el Coordinador. En ciertos aspectos, esto se asemeja al enfoque de las aplicaciones de tipo inscripción. En esta arquitectura, un servidor o base de datos centralizada no representa un desafío fundamental. Este es otro punto del paradigma de SCP: desacopla los conceptos de “centralización” y “entidad única” — en un sistema sin confianza, puede haber componentes centralizados, incluso un componente central, sin afectar la falta de confianza general del sistema.

Podemos gritar este lema: 'La próxima generación de infraestructura sin confianza no necesariamente tiene que depender de protocolos de consenso, pero debería ser un sistema de código abierto con una red de nodos Peer-to-Peer (P2P).' La intención original de inventar y usar blockchain era lograr la descentralización, la consistencia del libro mayor, la inmutabilidad y la trazabilidad, como se establece explícitamente en el libro blanco de Bitcoin. Sin embargo, después de Ethereum, ya sea las soluciones de expansión de las antiguas cadenas públicas, Rollups o blockchains modulares, ha existido una mentalidad fija: lo que estamos creando debe ser o bien una blockchain (compuesta por protocolos de consenso de nodos) o algo como Rollup (que parece ser una cadena con estructuras de datos de blockchain, pero sin intercambios directos de mensajes de consenso entre nodos). Ahora, bajo el marco basado en el SCP (Protocolo de Consenso Estelar), es evidente que incluso sin ser una blockchain, es posible lograr la descentralización, la consistencia del libro mayor, la inmutabilidad y la trazabilidad, siempre que haya más detalles de implementación explícitos.

Capa de ejecución

La capa de ejecución es crucial en todo el sistema, ya que se encarga de los procesos computacionales del sistema y determina los tipos de aplicaciones que pueden ejecutarse en el sistema.

Infinitas Posibilidades en el Entorno de Ejecución

Teóricamente, el entorno de ejecución en la capa de ejecución puede tomar cualquier forma, con posibilidades infinitas, dependiendo de cómo los desarrolladores del proyecto posicionen su proyecto:

1. Intercambios. Utilizando SCP, se puede construir un intercambio público y transparente con altas tasas de Transacciones Por Segundo (TPS), combinando las características rápidas y sin costos de un Intercambio Centralizado (CEX) y la descentralización de un Intercambio Descentralizado (DEX). Aquí, la distinción entre CEX y DEX se vuelve borrosa.

2. Redes de pago. Similar a Alipay, PayPal, etc.

3. Máquinas virtuales/Cadenas de bloques que admiten programas/contratos cargables. Cualquier desarrollador puede implementar cualquier aplicación en ella, compartiendo todos los datos de usuario con otros programas y operando según las instrucciones del usuario.

El patrón de diseño de SCP, que admite cualquier entorno de ejecución, tiene sus ventajas únicas: no es necesario depender de componentes con carga histórica, especialmente conceptos como la "abstracción de cuentas" única en la comunidad de Ethereum. Para SCP, el concepto de abstracción de cuentas es inherentemente innecesario. En la arquitectura de SCP, no hay concepto de abstracción de cuentas, se pueden adoptar libremente cuentas estándar de Web2 y cuentas de blockchain, etc. Desde esta perspectiva, muchos casos de uso maduros de Web2 no necesitan ser repensados y reconstruidos para ser directamente aplicables a SCP. Este aspecto podría ser donde SCP tiene ventaja sobre Rollups.

Transparencia y Asimetría

El sistema de cuentas se mencionó anteriormente, y los lectores perceptivos podrían haber notado que mientras el SCP (Protocolo de Consenso Estelar) puede utilizar el sistema de cuentas Web2, usarlo tal como está parece problemático. ¡Esto se debe a que todo el sistema es completamente transparente! Emplear directamente el modelo de interacción usuario-servidor de Web2 conlleva serios problemas de seguridad, lo que hace que el sistema sea completamente inseguro. Revisemos cómo funciona el modelo tradicional de servidor-usuario:

1. Registro de cuentas: Los usuarios introducen un nombre de usuario y una contraseña en la página de registro de la aplicación. Para proteger la contraseña del usuario, el servidor la procesa a través de una función hash al recibirla. Para aumentar la complejidad del hash y defenderse contra ataques de tablas arcoíris, una cadena generada aleatoriamente (conocida como 'salt') suele añadirse a la contraseña de cada usuario antes de hacer el hash. El nombre de usuario, el salt y el hash se almacenan en texto plano en la base de datos del proveedor de servicios y no se hacen públicos. Sin embargo, aun así, el salting y el procesamiento seguro son necesarios para prevenir amenazas internas y ataques.

1. 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 hash de la contraseña procesada con el hash almacenado en la base de datos. Si los dos hashes coinciden, indica que el usuario ha proporcionado la contraseña correcta y el proceso de inicio de sesión continúa.

2. Autenticación de operaciones : Después de la verificación exitosa del inicio de sesión, el sistema crea una sesión para el usuario. Por lo general, la información de la sesión se almacena en el servidor, y el servidor envía un identificador (como una cookie o token) al navegador o la aplicación del usuario. Durante operaciones posteriores, los usuarios ya no necesitan volver a ingresar su nombre de usuario y contraseña repetidamente: el navegador o la aplicación guarda el identificador de la cookie y lo incluye en cada solicitud, indicando que tienen el permiso del servidor asociado con la cookie.

Veamos el sistema típico de interacción usuario-blockchain de Web3:

1. Registro de cuenta: En realidad, no hay un proceso de registro de cuenta ni un sistema de usuario y contraseña. Las cuentas (direcciones) no necesitan ser registradas; existen inherentemente y quien controle la clave privada controla la cuenta. La clave privada se genera de forma aleatoria localmente por la cartera y no implica un proceso en línea.

2. Inicio de sesión del usuario: Usar la cadena de bloques no requiere iniciar sesión. La mayoría de las dApps no tienen un proceso de inicio de sesión, sino que se conectan a una billetera en su lugar. Algunas dApps, después de conectarse a una billetera, pueden requerir que los usuarios firmen una verificación para asegurarse de que realmente poseen la clave privada, en lugar de simplemente haber enviado una dirección de billetera al frontend.

3. Autenticación de operaciones: Los usuarios envían directamente los datos firmados a los nodos. Después de la validación, los nodos difunden la transacción a toda la red blockchain. Una vez que la operación es confirmada por el consenso de la red blockchain, se finaliza.

La diferencia entre estos dos modos es causada por factores simétricos y asimétricos. En una arquitectura servidor-usuario, ambas partes poseen el mismo secreto. En una arquitectura blockchain-usuario, solo el usuario posee el secreto. Aunque la capa de ejecución de SCP (Plataforma de Contratos Inteligentes) puede no ser una cadena de bloques, todos los datos deben sincronizarse con una capa de DA (Disponibilidad de Datos) públicamente visible. Por lo tanto, los métodos de inicio de sesión y verificación de operaciones de SCP deben ser asimétricos. Sin embargo, para evitar acciones engorrosas como administrar claves privadas y usar billeteras, que podrían obstaculizar la adopción generalizada debido a una mala experiencia del usuario, hay una fuerte demanda de identificaciones tradicionales y contraseñas o inicios de sesión de autenticación de terceros de OAuth en aplicaciones construidas en SCP. Entonces, ¿cómo combinamos los dos? Debido a la naturaleza asimétrica de la criptografía y las pruebas de conocimiento cero, visualizo dos posibles soluciones:

• Si se desea un sistema de ID-contraseña, el módulo de guardado de contraseñas podría ser excluido de SCP, haciéndolo invisible para otros. Internamente, la capa de ejecución de SCP sigue utilizando las cuentas de clave pública-privada y la lógica operativa de la cadena de bloques, sin registro ni inicio de sesión. El ID del usuario realmente correspondería a una clave privada. Esta clave privada, por supuesto, no debería ser almacenada por el lado del proyecto. Una solución factible es utilizar 2-3 MPC (Cómputo Multi-Partes) para resolver el problema de almacenamiento centralizado sin cargar al usuario con el uso de una clave privada.
• Al depender del inicio de sesión de OAuth, JWT (Token web JSON) se puede utilizar como un medio de autenticación de identidad. Este método es ligeramente más centralizado que el anterior, ya que básicamente depende de los servicios de inicio de sesión de terceros proporcionados por los gigantes de Web2 para la verificación de identidad.
• La primera vez que se utiliza el inicio de sesión de un tercero, los campos JWT que representan las identidades de usuario y proveedor de servicios se registran en el sistema. En operaciones de usuario posteriores, el comando de operación se trata como entrada pública, mientras que el JWT en su conjunto es un testigo secreto, utilizando ZKP (Prueba de conocimiento cero) para verificar cada una de las transacciones del usuario.
• Cada JWT tiene un límite de vencimiento, y los usuarios solicitarán un nuevo JWT la próxima vez que inicien sesión, por lo que no es necesario un almacenamiento permanente. Además, este sistema se basa en JWK (Clave Web JSON), que puede entenderse como la clave pública proporcionada por los gigantes para la verificación de JWK. Cómo se introduce JWK descentralizadamente en el sistema y los métodos para futuras rotaciones de la clave privada también merecen ser explorados.

Independientemente del método utilizado, ambos son más costosos en términos de desarrollo y operación que los métodos tradicionales, pero este es un precio necesario a pagar por la descentralización. Por supuesto, si el proyecto no considera la descentralización extrema necesaria, o tiene hitos diferentes en diferentes etapas de desarrollo, es posible proceder sin estos diseños, ya que la descentralización no es blanco y negro, sino que existe en un área gris.

Problemas de privacidad

Los problemas de transparencia mencionados anteriormente no solo afectan el paradigma de interacción del usuario, sino que también impactan en los datos del usuario. Los datos del usuario se exponen directamente. Si bien esto no es un problema en la cadena de bloques, es inaceptable en algunas aplicaciones. Por lo tanto, los desarrolladores también pueden construir sistemas de transacciones privadas.

Tarifas

Cómo cobra comisiones la capa de ejecución es otro punto de interés. Enviar datos a la capa de Disponibilidad de Datos (DA) también conlleva costos, incluida la operación de sus propios servidores. El propósito principal de cobrar comisiones de gas en blockchains tradicionales es evitar que los usuarios saturen la red con numerosas transacciones redundantes, siendo secundario el ordenamiento de transacciones basado en comisiones de gas. En Web2, no existen preocupaciones similares, solo conceptos básicos como inundaciones y ataques DDoS. La capa de ejecución puede personalizar diversas estrategias de cobro, como ser completamente gratuitas o parcialmente cargadas, o beneficiarse de otras actividades como el Valor Extraíble Máximo (MEV), que ya es muy maduro en secuenciadores y actividades de mercado.

Resistencia a la censura

La capa de ejecución no posee resistencia a la censura y teóricamente puede rechazar las transacciones de los usuarios indefinidamente. En los Rollups, la resistencia a la censura puede garantizarse mediante la función de agregación obligatoria del contrato L1, mientras que las cadenas laterales o cadenas públicas son redes blockchain distribuidas completas, lo que dificulta la censura. Actualmente, no hay una solución clara para abordar el problema de la resistencia a la censura, que es un problema en el paradigma SCP.

Capa de consenso

Esta capa consiste en nodos conectados de forma laxa que no forman activamente una red, por lo que no es estrictamente una capa de consenso, sino que simplemente confirma el estado actual de la capa de ejecución al mundo exterior (como los usuarios). Por ejemplo, si duda del estado operativo de estos nodos, puede descargar su cliente detector, que ejecuta el mismo código de programa que el coordinador. Sin embargo, similar a los Rollups, dado que los datos se envían en lotes, el estado devuelto por la capa de ejecución a los usuarios siempre está más actualizado que el de la capa DA. Esto implica el problema de la preconfirmación: la capa de ejecución proporciona a los usuarios preconfirmaciones, resultados de finalidad suave, ya que aún no se han enviado a la capa DA; mientras que la capa de consenso proporciona finalidad sólida. Es posible que a los usuarios no les preocupe especialmente esto, pero para aplicaciones como puentes entre cadenas, es necesario adherirse a la finalización sólida. Por ejemplo, el sistema de depósito y retiro de intercambios no confía en los datos transmitidos fuera de la cadena por los secuenciadores de Rollup; esperan a que estos datos estén en Ethereum antes de aceptarlos. Además de confirmar resultados, la capa de consenso también desempeña un papel crucial como redundancia en caso de desastres para la capa de ejecución. Si la capa de ejecución deja de funcionar permanentemente o actúa maliciosamente, teóricamente cualquier capa de consenso puede hacerse cargo del trabajo de la capa de ejecución y aceptar las solicitudes de los usuarios. Si ocurre una situación tan grave, la comunidad debería elegir nodos estables y confiables como servidores de la capa de ejecución.

Capa de Liquidación

Dado que SCP no es Rollup, no puede lograr retiros sin confianza como la capa de liquidación de retiros de Rollup, que se basa enteramente en la criptografía y el código de contrato inteligente sin intervención manual. El nivel de seguridad de los puentes cruzados de SCP es el mismo que el de los puentes cruzados de cadena lateral o de testigo de terceros, que dependen de gerentes autorizados de firma múltiple para liberar activos, conocido como el modo de testigo.

Hacer que el puente de testigos sea lo más descentralizado posible es un tema de investigación para muchos puentes entre cadenas. Debido a limitaciones de espacio, esto no se elaborará aquí. Una plataforma SCP bien diseñada en la práctica también debe tener socios de firma múltiple de puente descentralizado de buena reputación. Algunos podrían preguntarse por qué SCP no utiliza una cadena con contratos inteligentes como capa DA. Esto permitiría capas de liquidación sin confianza basadas en contratos. A largo plazo, superando algunas dificultades técnicas, si la capa DA se coloca en Ethereum u otras capas DA habilitadas para contrato y se pueden construir contratos de verificación correspondientes, SCP también puede lograr la misma seguridad de liquidación que Rollup, sin necesidad de firmas múltiples.

En la práctica, esto puede que no sea la mejor elección:

1. Ethereum no está específicamente diseñado para el almacenamiento de datos, y en comparación con las blockchains dedicadas únicamente al almacenamiento de datos, es bastante caro. Para el paradigma de SCP, un costo de almacenamiento suficientemente bajo o fijo es crucial. Solo así puede admitir el rendimiento del nivel Web2.

2. Desarrollar sistemas de prueba es extremadamente difícil porque, en SCP, uno puede simular no solo EVM (Ethereum Virtual Machine) sino también implementar cualquier lógica. Teniendo en cuenta el estado actual de proyectos como Optimism, donde sus pruebas de fraude aún no se han lanzado, y la complejidad de desarrollar zkEVM (máquina virtual Ethereum de conocimiento cero), uno puede imaginar la inmensa dificultad de implementar varios sistemas de prueba en Ethereum.

Por lo tanto, la solución Rollup solo es más viable en circunstancias específicas. Si planea implementar un sistema más amplio y abierto, alejándose del marco EVM para integrar más características de Web2, entonces el enfoque de Rollup de Ethereum no es adecuado. SCP no es solo un plan de expansión para cierta cadena de bloques pública, sino una arquitectura de plataforma informática Web3 más grande. Por lo tanto, claramente no necesita seguir el enfoque de Capa 2 de Ethereum.

Una ilustración compara SC con otros paradigmas

Descargo de responsabilidad：

1. Este artículo está reimpreso de [极客Web3]. Todos los derechos de autor pertenecen al autor original [雾月，极客Web3]. Si hay objeciones a esta reimpresión, por favor contacte al Gate Learnequipo, y lo manejarán rápidamente.
2. Descargo de responsabilidad: Las opiniones expresadas en este artículo son únicamente las del autor y no constituyen ningún consejo de inversión.
3. Las traducciones del artículo a otros idiomas son realizadas por el equipo de Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.