Expertos en Sui explican el diseño de cadenas de bloques de alto rendimiento: aplicación innovadora de la ruta rápida y la ruta de consenso

Recientemente, entrevistamos a un experto en cadena de bloques para discutir la complejidad y escalabilidad de la infraestructura de Sui, así como cómo el sistema de procesamiento de transacciones de Sui facilita una red de alto rendimiento. Este experto es profesor en el campo de la seguridad y la privacidad en una conocida universidad.

A continuación se presentan los contenidos de esta entrevista:

Q1：¿Viene del ámbito académico, puede contarnos sobre su enfoque de investigación?

Soy profesor en una universidad, y mi área de investigación se centra, en términos generales, en la seguridad y la privacidad. A principios del siglo XX, realicé una cantidad considerable de investigación en sistemas peer-to-peer y sistemas anónimos, muchos de los cuales eran grandes sistemas distribuidos enfocados en el almacenamiento. A medida que toda la Cadena de bloques se volvió más centrada en la ejecución, especialmente representada por Ethereum, me interesé por los libros de contabilidad distribuidos y la Cadena de bloques, así como por cómo ejecutar contratos inteligentes. Estaba muy familiarizado con su característica de ser sin permiso, ya que trabajé en sistemas peer-to-peer en sus inicios. Así que en el grupo de investigación de la universidad comenzamos a investigar cómo construir sistemas de mayor rendimiento. Fundamos una empresa para comercializar algunas de nuestras ideas, y luego el equipo fue adquirido por una gran empresa tecnológica. Luego, ayudamos a la empresa a proponer soluciones para escalar la Cadena de bloques. Pero cuando la solución no avanzó, me fui, buscando otras oportunidades para realizar la idea de una Cadena de bloques de alto rendimiento.

Q2: Aún eres un profesor, ¿cuál crees que es la diferencia entre la aplicación y la investigación?

En realidad, no hay una gran diferencia. Cuando estamos investigando, consideramos todas las posibilidades para alcanzar objetivos específicos, como construir una Cadena de bloques de alto rendimiento o funciones específicas. Por supuesto, al construir una Cadena de bloques o elegir las funciones específicas que se utilizarán en un sistema real, debemos elegir una de las posibilidades. Debemos estar constantemente tomando decisiones sobre cuál de todas estas buenas ideas es realmente la más útil para la gente. ¿Cuál es la que la gente está buscando? ¿Qué cuellos de botella existen en la adopción de la Cadena de bloques? ¿Qué impide que las personas logren lo que desean hacer? Al construir un sistema, todavía considerarás todas las posibilidades y tratarás de entender las situaciones posibles a partir de la literatura académica, y luego elegirás lo más relevante. No se trata solo de interés en el conocimiento, sino de crear valor para los usuarios.

Q3: ¿Cómo determinó qué problemas resolver al pasar de la teoría a la aplicación práctica?

El principal problema que estoy abordando en mi investigación es cómo expandir las diferentes funciones de la Cadena de bloques. Me enfoco en los aspectos del sistema de la Cadena de bloques, como aumentar el rendimiento de las transacciones y reducir la latencia. Los problemas en este aspecto son evidentes, cada vez que vemos que un contrato en una plataforma se vuelve muy popular, esa plataforma no puede soportar tal volumen de transacciones, lo que provoca congestión en las transacciones y un aumento vertiginoso de las tarifas. Cada vez que la Cadena de bloques tiene éxito, vemos que el volumen de transacciones que puede manejar supera la capacidad existente. Por lo tanto, es evidente que el problema radica en la falta de capacidad para satisfacer lo que las personas quieren hacer en estas Cadenas de bloques. Esto no es solo una cuestión de nuestras opiniones, hemos visto esta situación ocurrir una y otra vez. Durante un tiempo, esto se consideró un desafío valioso, no solo en mi equipo, de hecho, toda la comunidad académica está investigando la Cadena de bloques, y todos están abordando este problema de diferentes maneras. Ahora, ya se han desarrollado bastantes tecnologías para ampliar la capacidad de la Cadena de bloques y abordar estos desafíos. Pero en ese momento, era bien conocido que muchas personas estaban tratando de resolverlo de diferentes maneras.

Q4: ¿Cuál es la diferencia y los beneficios de las redes L2, que son una forma propuesta por las personas para resolver el problema de escalabilidad, con respecto a la creación de nuevas redes L1 como Sui?

L2 es una solución de escalado en un ecosistema determinado. Sin embargo, para los desarrolladores de aplicaciones, usar una red L2 puede ser un poco complicado. Cuando una red L2 intenta interactuar con L1, debe llevar a cabo actividades de puenteo, aunque esto es cierto para cualquier relación L2/L1. El estado que representa a coin, activos u otros contenidos en L1 debe ser reflejado en L2, y viceversa. Además, L2 también debe tener algún mecanismo para que L1 pueda verificar todo lo que suceda en él. Pero esto es solo la primera parte, es decir, cualquier activo que exista en L1 necesita ser transferido a L2, debe ocurrir alguna actividad en L2, y luego de alguna manera los activos deben ser devueltos a L1. Esto es muy problemático.

Para activos fungibles como los tokens, esta actividad de puente es relativamente fluida, ya que las personas tienen dos cuentas y un middleware de puente. Sin embargo, para activos más generales, la efectividad no es buena. Para utilizar realmente la red L2 en L1 para desarrollar aplicaciones más complejas que los tokens, necesitas tener contratos inteligentes en ambos lados, uno para acuñar (mint) y otro para destruir (burn). Deben transitar entre dos ecosistemas diferentes, lo cual es una actividad personalizada para cada contrato. No puedes simplemente decir que crearé una red L2, luego llevaré todos los activos, operaré a mi manera y luego los traeré de vuelta; no existe tal concepto. Este es un proceso manual y es muy propenso a errores. Por lo tanto, no es una buena experiencia. Imagina que tienes activos en varias redes L2 diferentes, y que en cada red L2 tienes estos contratos inteligentes personalizados. Cada vez que quieras operar sobre un estado que está en otra red L2, debes hacer todo el puenteo de regreso a L1 y luego de regreso a L2. No puedes decir fácilmente que acabas de hacer algo en esta cadena de bloques y que luego quieres hacer algo más en otra cadena de bloques, sin tener que considerar en qué L1 o L2 estás. Todo está aquí, lo tengo en la mano y estoy listo para hacer más transacciones en cualquier estado que quiera acceder. Por eso es que la experiencia de tener estados dispersos en redes L2 no es buena. Mover activos entre diferentes cadenas es muy complicado y es evidente para los usuarios. Esta es la razón por la que las redes L2 nunca han despertado realmente mi interés.

Otro ejemplo es un proyecto conocido que tiene un ecosistema muy interesante, que utiliza un enfoque diferente, que es escalar utilizando diferentes cadenas de bloques para diferentes aplicaciones. Podemos tener diferentes velocidades de transacción en diferentes cadenas, y cuando es necesario operar entre diferentes aplicaciones, se pueden puentear activos entre cadenas, pero también enfrenta el mismo problema. Cada vez que desea usar diferentes aplicaciones, primero debe realizar una operación de puenteo, lo cual es sutil y evidente para los usuarios, y luego puede usar esa aplicación y volver a puentear. Te darás cuenta de que pasas más tiempo transfiriendo activos de una cadena a otra, en lugar de hacer lo que realmente quieres hacer.

En Sui, nuestra propuesta es establecer una gran base de datos que, de hecho, contiene todos los estados replicados por los nodos verificados. Una vez que completes una transacción, todos los estados en la misma base de datos se pueden utilizar para realizar la siguiente transacción, y los usuarios no tienen que mover constantemente el estado de los activos entre L1 y L2.

Q5: Sui Lutris es la base del protocolo Sui, ¿cuál es su innovación clave que permite que Sui tenga características de alta capacidad de procesamiento y baja latencia?

Sui Lutris se compone de dos conceptos clave: (1) para muchas operaciones en la cadena de bloques, en realidad no es necesario alcanzar un consenso; (2) cuando realmente se necesita un consenso, hay un método de muy alto rendimiento que combina estos dos enfoques. Sui Lutris es el núcleo del sistema distribuido Sui, asegurando que al realizar transacciones en una red distribuida, dos nodos de validación diferentes que siguen el protocolo nunca estén en un estado inconsistente. Así, no se dará el caso de que un nodo de validación crea que usted ha gastado un coin y lo ha enviado a Alice, mientras que otro nodo de validación crea que el mismo coin en realidad fue enviado a Bob.

Dos caminos diferentes, uno que no requiere consenso (camino rápido) y otro que requiere consenso (camino de consenso). Cuando el objeto que desea operar pertenece únicamente a usted, como su propio personaje NFT y el sombrero que desea combinar para que su personaje pueda usar el sombrero, teóricamente otras personas no deberían operar con ellos. En estos casos, Sui utiliza el camino rápido, lo que significa que puede operar con sus propios objetos, puede obtener la finalización de la transacción sin esperar un consenso, asegurando que la transacción ocurra y que el sombrero esté en la cabeza de su NFT.

Pero en ciertos casos, las transacciones no solo implican objetos que le pertenecen a usted, sino que son compartidos por muchas personas. Por ejemplo, si hay una subasta que vende sombreritos, este tipo de subasta se representa en Sui como un objeto compartido. Las personas pueden ofertar, y la persona que haga la oferta más alta gana el sombrero. Esta subasta es un objeto que no pertenece a una sola entidad, todos deben poder ofertar, compartir y actualizar el estado sobre la última oferta, y estos tipos de operaciones requieren un consenso adicional. Sui Lutris le permite poseer objetos compartidos y realizar transacciones sobre ellos, lo que le permite poseer otros objetos, cambiar el estado del objeto compartido o crear nuevos objetos compartidos. Permite la coexistencia de dos caminos e interacción entre objetos exclusivos poseídos por individuos específicos y objetos compartidos poseídos por múltiples personas.

Estos dos caminos diferentes tienen ventajas distintas. La ruta rápida de objetos exclusivos tiene una latencia muy baja, con un tiempo de respuesta de menos de un segundo, lo que la hace muy rápida y ampliamente escalable. La latencia de la ruta de consenso es más alta, generalmente supera un segundo, y su capacidad también es bastante alta, pero, en comparación con la primera ruta, es más difícil de escalar. En Sui, aquellos que realmente impulsan las aplicaciones en la cadena con millones de transacciones diarias suelen utilizar la primera ruta, y en gran medida estructuran sus aplicaciones para realizar la mayoría de las transacciones en objetos exclusivos, en lugar de transacciones compartidas. Por otro lado, los protocolos que realizan trabajos complejos (como DeFi) suelen implementar el segundo tipo de transacción, ya que deben combinar las ofertas o la liquidez de muchas personas diferentes para ejecutar operaciones.

Q6：¿Pueden los desarrolladores de aplicaciones en Sui diseñar sus aplicaciones para aprovechar el camino rápido?

Sí, absolutamente. Creo que este es el trabajo central de los diseñadores de aplicaciones de expansión. Los desarrolladores de contratos inteligentes pueden controlar completamente si los objetos con los que operan en el contrato son objetos exclusivos de una sola entidad o objetos compartidos en un momento determinado. Un truco para expandir aplicaciones en Sui es asegurarse de que la mayoría de las operaciones se realicen esencialmente en objetos exclusivos, ya que Sui puede gestionar muchas operaciones que desea con una latencia muy baja, lo que proporciona una buena experiencia. Las operaciones necesarias para los juegos deben realizarse en esta categoría, y en comparación con las operaciones que requieren mediación a través de estados compartidos y objetos compartidos, su latencia es muy baja. Una vez que se hace clic, la transacción se puede completar de inmediato en la red.

Los diseñadores de contratos inteligentes tienen control total sobre esto, ya que pueden especificar con precisión qué transacciones hay en cada categoría. Por supuesto, la primera versión del contrato puede considerar todo como un estado compartido, y todo pasará a través de una ruta de consenso de mayor latencia, pero a medida que se necesite escalar, los desarrolladores deben considerar hasta qué punto pueden hacerlo sin estas partes.

Q7: ¿Cómo desempeña un papel el Bloquear de transacciones programables en esto?

Los bloques de transacciones programables pueden desempeñar un papel en la ruta rápida o en la ruta de consenso. Si un bloque de transacción programable solo involucra sus objetos exclusivos, esto significa que puede realizar múltiples operaciones en una única operación en la cadena. Por ejemplo, suponga que usted es una aplicación CEX, donde muchas personas compran y venden diferentes coins, puede realizar una transacción en la cadena que conceptualmente corresponde a lo que las personas compran y venden. Pero dado que usted es el intercambio, todos pertenecen a usted, por lo que puede liquidar mil transacciones al mismo tiempo, esa es la ruta rápida. Por otro lado, si algunos objetos dentro del bloque de transacción programable son compartidos, entonces se entra en la ruta de consenso, donde la latencia será un poco más alta, no será menos de un segundo, sino que tomará varios segundos.

Q8: La red principal ha estado en línea durante más de 100 días, ¿ha demostrado Sui la teoría de investigación que usted suponía? ¿Hay algo que le haya sorprendido?

Hay algunas cosas que confirman el diseño de Sui, pero también hay algunas cosas en las que pensar. Una es cuando hay un volumen particularmente alto de transacciones, o incluso en un momento especial, cuando el volumen diario de operaciones supera incluso los 60 millones, la mayoría de las cuales están en el camino rápido. Sui Lutris es muy escalable y tiene una latencia muy baja. Hasta entonces, no estaba claro si alguien usaría esta ruta, pero se usó cuando se requerían muchas transacciones y baja latencia, ¡y fue muy efectiva! Es fácil ver que este es el método. En esos días, el volumen de operaciones de Sui superó: