Aunque Sei Network ha realizado muchas optimizaciones e innovaciones para mejorar la velocidad de las transacciones, también ha sacrificado parcialmente la descentralización.

Escrito por: Delphi Digital

Compilado por: Babywhale, Foresight News

El 4 de enero, el exchange de criptomonedas MEXC anunció el lanzamiento de un fondo especial de 20 millones de dólares para apoyar el desarrollo de proyectos clave en Sei Network. Ya el 31 de agosto, Sei Labs anunció que había completado una ronda inicial de financiación de 5 millones de dólares, liderada por Multicoin Capital, con inversores participantes como Coinbase Ventures, GSR, Flow Traders, Hudson River Trading, Delphi Digital, Tangent, etc. Un mes después del anuncio oficial de la finalización de la financiación, Sei Network lanzó un fondo ecológico de 50 millones de dólares para respaldar las aplicaciones DeFi desarrolladas en él.

Como uno de los inversores de Sei Network, Delphi Digital ha escrito un informe para explicar por qué es optimista acerca de Sei Network. El autor resume aquí los contenidos clave del informe para que todos puedan discutirlo.

Una red diseñada para DeFi

Al construir cadenas de bloques, normalmente intentamos clasificarlas en dos categorías diferentes: cadenas de propósito general o cadenas de aplicaciones. Las cadenas universales se utilizan para innovación sin permiso, mientras que las cadenas de aplicaciones se utilizan para casos de uso específicos que requieren permisos. Pero la "cadena de aplicaciones" no es blanca o negra, sino que está determinada por la propia cadena. Sei es una próxima cadena ecológica Cosmos que apunta a convertirse en una cadena de bloques de Capa 1 "diseñada para DeFi".

“Diseñado para DeFi” significa realizar cambios fundamentales (y concesiones) en la capa base para que las aplicaciones DeFi puedan prosperar. Sei tiene un motor de comparación de órdenes incorporado, velocidad de liquidación inferior a un segundo, procesamiento paralelo de órdenes, ejecución de órdenes de bloque único, etc. Todas estas funciones personalizadas se completan en la capa base. Lo que necesitas saber es que Sei no es un DEX, es una cadena de bloques de Capa 1 optimizada para DeFi. Al mismo tiempo, Sei no es una cadena de aplicaciones pura, a diferencia de THORChain, que solo se centra en intercambios entre cadenas, sino una cadena de bloques desarrollada para las características de productos como DEX, contratos y futuros.

Para comprender por qué querríamos realizar estos cambios en la red subyacente, podemos mirar Serum y Solana. Solana es una cadena de bloques de Capa 1 de propósito general promocionada como el "Nasdaq en la cadena" que apunta a tiempos de confirmación de bloques de 400 milisegundos y un rendimiento extremadamente alto. La tesis principal de Solana es que las plataformas de negociación de carteras de órdenes eventualmente se harán cargo de las AMM, y los indicadores de Solana respaldan esta opinión. Serum es una aplicación de libro de pedidos construida en Solana. Es la aplicación más utilizada en el ecosistema de Solana y representa aproximadamente 1/3 de las transacciones en Solana. Serum es la "capa del libro de pedidos" de Solana, utilizada por proyectos como Mango Markets, Zeta, Atrix, Bonfida, Jupiter, etc. Cuando la gente piensa en Solana, normalmente piensa en Serum.

Sin embargo, esta arquitectura también tiene algunas desventajas, en particular porque Solana es una cadena universal, Serum (y las aplicaciones creadas sobre ella) compiten constantemente por los recursos con otras aplicaciones. Las actividades que no tienen nada que ver con Serum, como los juegos y la acuñación de NFT, pueden causar congestión en la cadena, como hemos experimentado antes con las varias "interrupciones" de Solana. Sei decidió “cortarse los pies para que se ajusten a los zapatos” y eliminar de su cadena todas las actividades que no sean DeFi. Una explicación simple es que Sei equivale a que Serum lance su propia cadena de bloques de Capa 1: hacer concesiones específicas para optimizar la capa base para DeFi y brindar a las aplicaciones DeFi construidas sobre ella más ventajas injustas.

La principal compensación aquí es que Sei no estará sin permiso como Solana, ya que el desarrollo de aplicaciones requiere una lista blanca a través de la gobernanza. Si bien se pierden algunas de las ventajas de la innovación sin permiso, se puede crear un entorno más optimizado. El motor de comparación de órdenes nativo, los oráculos de precios, la ejecución de órdenes paralelas y la ejecución de órdenes de un solo bloque son algunas de las cosas que Sei ha construido a nivel de infraestructura. Sei es una cadena de aplicaciones, pero la cartera de pedidos en cadena de Sei crea una arquitectura componible que permite la componibilidad sincronizada entre las aplicaciones CosmWasm en Sei y el intercambio de liquidez a través del motor de comparación de pedidos nativo. Como cadena Cosmos que admite IBC, es inherentemente componible de forma asincrónica.

Sei implementó algunas de sus optimizaciones a través de ABCI++, una próxima actualización de ABCI de Cosmos que hace que cada paso del consenso sea programable. Sei ha estado intentando realizar tres mejoras con ABCI++: producción de bloques optimizada, transmisión de bloques inteligente y ejecución paralela de órdenes.

Optimizando Sei con ABCI++

Para el comercio de libros de órdenes enfocados, el tiempo de producción de bloques, la liquidación comercial y la latencia son lo más importante para los creadores de mercado. Los creadores de mercado necesitan actualizar sus precios en cada bloque, por lo que tiempos de bloque más cortos significan diferencias de precios más pequeñas entre bloques, diferenciales más pequeños y menos riesgo para los creadores de mercado. Cualquier valor superior a unos pocos cientos de milisegundos es inaceptable (y unos pocos cientos de milisegundos aún pueden ser demasiado altos a largo plazo). Una cadena Cosmos estándar tiene un tiempo de confirmación de bloque de aproximadamente 6 segundos, lo que hace que el libro de pedidos sea una solución subóptima. Sin embargo, la belleza de Cosmos es su capacidad de personalización, y Sei se ha centrado en realizar cambios para optimizar el consenso y hacerlo lo más rápido posible (con un objetivo de ~300-600 ms). Las tres áreas principales de enfoque de Sei son:

Optimice la producción de bloques, la transmisión de bloques inteligentes y la ejecución paralela de órdenes.

Sei hace esto aprovechando ABCI++. ABCI es la interfaz entre aplicaciones y consenso. Su función principal es ejecutar bloques determinados por consenso. Con ABCI, las aplicaciones sólo interactúan con el consenso para la toma de decisiones y tienen poco control sobre qué transacciones se seleccionan del mempool. ABCI++ agrega programabilidad a cada paso del consenso, permitiendo que las aplicaciones reordenen, modifiquen, abandonen, retrasen o agreguen transacciones, así como reducir el tiempo de producción de bloques al introducir la capacidad de optimizar la producción de bloques.

Después del paso de propuesta de consenso, las aplicaciones pueden comenzar a optimizar el procesamiento de bloques, en paralelo con las fases previas a la votación y al compromiso previo. Luego, Sei comenzará a cambiar el estado "mediante optimización" a un estado candidato temporal hasta que sea aceptado por consenso. Si no se acepta (raramente), el bloqueo se abandona. En este paso, hay muchos datos que procesar y puede ser bastante lento. Pero al optimizar el procesamiento de cambios de estado, podemos acortar el tiempo de generación de bloques y reducir significativamente la latencia (en aproximadamente 300 ms).​

Además de optimizar la producción de bloques, Sei también está mejorando la transmisión de información en bloques. En Tendermint, cuando un validador propone un bloque, este bloque incluirá todos los detalles de la transacción y la cantidad de datos será muy grande, pero el validador ya ha obtenido aproximadamente el 99,9% de estas transacciones a través de su mempool local, por lo que no es necesario. esperar a recibir nuevamente estos datos del proponente del bloque. En lugar de enviar todos los detalles, los proponentes ahora simplemente enviarán el hash de cada transacción en el bloque, y los validadores podrán reconstruir rápidamente el bloque utilizando su propio mempool local.

Sei nombró a estas dos optimizaciones "Consenso Twin-Turbo" y dijo que al implementar estas dos optimizaciones (producción de bloques optimizada y transmisión de bloques inteligentes), el rendimiento aumentó en un 83%.​

La tercera optimización del proceso de producción de bloques gira en torno a la ejecución de transacciones. El procesamiento de transacciones en la cadena Cosmos utilizando ABCI se realiza de forma secuencial. En este proceso, las transacciones se procesan una por una independientemente del mercado en el que se encuentren, lo que dificulta en gran medida el rendimiento. Y a medida que aumente la carga, la latencia también aumentará exponencialmente. Al utilizar el procesamiento paralelo, se pueden procesar simultáneamente mercados independientes que no se superponen. En lugar de procesar la primera operación en el Mercado B después de la operación en el Mercado A, puede procesarlas simultáneamente. Las transacciones dentro de un mercado específico aún deben procesarse para evitar el no determinismo, que ocurre cuando dos validadores diferentes obtienen resultados diferentes para el mismo estado (por ejemplo, un validador procesa antes que la orden del usuario B, pero otro validador procesa la orden del usuario B). antes de A, provocando que el precio de liquidación del usuario entre en conflicto).​

Sei realizó algunas pruebas de carga en torno a la paralelización (al mismo tiempo que alojaba los validadores) para ver qué mejoras se podían realizar en términos de tiempos de bloqueo, latencia y rendimiento. En términos generales, mediante la ejecución en paralelo, los tiempos de bloque se pueden reducir entre un 75 y un 90 % en comparación con el procesamiento secuencial, con latencias paralelas de 40 a 120 ms y latencias secuenciales de 200 a 1370 ms. Con 10.000 órdenes/bloque y 20 contratos (mercados) diferentes, el paralelismo puede reducir el tiempo de bloque de 1,33 a 0,81 segundos, el retraso de 371 ms a 48 ms y el rendimiento de 7.500 órdenes/s a 12.200 órdenes/s. Se observan mejoras significativas en todos los niveles de carga (órdenes/bloques), con una mayor optimización marginal a medida que aumenta el tamaño de la carga.​

Además de las tres mejoras principales mencionadas anteriormente, Sei también agrega otras características a la capa base, como:

Oráculo de precios nativo. Un oráculo está integrado en la capa base; los validadores deben acordar un precio al producir un bloque. Los bloques no se crean hasta que los validadores acuerdan un precio. Permita que otros módulos obtengan información confiable de precios del mercado en cadena.

Ejecución de órdenes de un solo bloque. Permite la colocación y ejecución de órdenes en un solo bloque (requiere múltiples bloques en Serum).

Agrupación de pedidos. Los creadores de mercado pueden actualizar los precios en múltiples mercados en una sola transacción.

Subastas de lotes frecuentes. Las órdenes de mercado se pueden agregar al final del bloque para su liquidación a un precio único; el objetivo es intentar minimizar la ejecución anticipada.

Además de las mejoras de software, Sei también ha estado probando estructuras de validadores más pequeñas y requisitos de hardware más altos. Si bien existen compensaciones en la descentralización, estas conllevan importantes mejoras de rendimiento y una vez más resaltan lo que hace que Cosmos sea único: la personalización.​

Configuración de validadores utilizando hardware de alto rendimiento

En la primera versión de la documentación del proyecto Sei, las especificaciones recomendadas eran similares a las de la cadena Cosmos estándar. Luego se aumentaron los requisitos de hardware y, en determinadas pruebas de carga, se aumentaron aún más. El modelo de libro de pedidos tiene altos requisitos de hardware y las máquinas de bajo rendimiento reducirán el rendimiento general de la red. Si bien no es un requisito del nivel de Solana, Sei ha dejado en claro que quieren que su validador supere a las cadenas de bloques comunes. Además, están presionando para que se centralicen las geografías de los validadores para reducir aún más la latencia.

¿Por qué la colocación? Si los validadores están dispersos geográficamente, la información tardará más en transmitirse, lo que provocará mayores retrasos para llegar a un consenso y generar bloques. Las plataformas de negociación de libros de órdenes deben reducir la latencia tanto como sea posible. Sei ha publicado una vez más algunos de los resultados de sus pruebas en torno a la colocación:

1. La colocación reduce la latencia en aproximadamente un 46 % en comparación con la dispersión geográfica.

2. 50 validadores es el límite de latencia aceptable.

Existen ventajas obvias al tener todos los validadores en la misma área geográfica, pero la mejora del rendimiento es difícil de ignorar. Cuando Sei lance la red principal, probablemente avanzarán hacia este conjunto de validadores más pequeños y centralizados. En el cuadro siguiente, p50/p75/p95 se refiere a la probabilidad de que el x% de las solicitudes sean más rápidas que un valor específico. Por ejemplo, p50 significa que el 50 % de las solicitudes serán más rápidas que el valor de p50 para esa prueba. Entonces p95 significa que el 95% de las solicitudes serán más rápidas que el valor de p95.

Resumir

El informe de Delphi Digital también incluye contenido sobre ecología, tokens, etc. Este artículo los omitirá temporalmente y solo mostrará las innovaciones de Sei Network en tecnología y mecanismos. Lo que se puede ver es que Sei ha realizado innovaciones en el procesamiento paralelo y la transmisión en bloque para mejorar la velocidad de confirmación de las transacciones de la red, pero por otro lado, Sei requiere validadores con una configuración de hardware de alto rendimiento y una ubicación geográfica de estos validadores relativamente centralizados. Para satisfacer aún más su apoyo a la plataforma de negociación modelo de cartera de pedidos, Delphi también admitió el problema de centralización de la solución en el informe, pero afirmó que no se puede ignorar la mejora de su rendimiento.

El autor cree que, como se menciona en el artículo, la cadena de aplicaciones ecológicas de Cosmos es extremadamente personalizable y Web3 debería ser lo suficientemente inclusiva para la ideología de cómo debe presentarse la cadena de bloques. Podemos apoyar proyectos con un alto grado de descentralización. También se puede aceptar sacrificar cierta descentralización en aras de la eficiencia. Sin embargo, si Sei Network puede ser tan "rápido" como dice, aún necesitamos usar datos reales para dar la respuesta después de que la red principal esté en línea.