El fundador de Sui analiza la arquitectura de cadena de bloques de alto rendimiento: las ventajas de la ruta rápida y la ruta de consenso.

Recientemente, entrevistamos a un conocido experto en el campo de la Cadena de bloques, explorando la complejidad y escalabilidad de la infraestructura 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 privacidad en una conocida universidad.

El siguiente es el contenido de esta entrevista:

Q1: Usted proviene del ámbito académico, ¿puede hablarnos sobre su enfoque de investigación?

Soy profesor en una universidad conocida, y mi enfoque de investigación se llama seguridad y privacidad en un sentido amplio. A principios del siglo XX, realicé bastante investigación en sistemas peer-to-peer y sistemas anónimos, muchos de los cuales eran grandes sistemas distribuidos centrados en el almacenamiento. A medida que toda la Cadena de bloques se centraba más en la ejecución, especialmente representada por Ethereum, me interesé en los libros de contabilidad distribuidos y en cómo ejecutar contratos inteligentes. Estaba muy familiarizado con la característica sin permisos desde mi trabajo en los primeros sistemas peer-to-peer. 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 posteriormente el equipo fue adquirido por una gran empresa tecnológica. Luego, ayudamos a esa empresa a proponer soluciones para escalar la Cadena de bloques. Pero cuando la solución no avanzó, me fui y continué buscando otras oportunidades para realizar la idea de una Cadena de bloques de alto rendimiento.

Q2: Usted sigue siendo un profesor, ¿cuál cree que es la diferencia entre la aplicación y la investigación?

En realidad, no hay mucha diferencia. Cuando realizamos investigaciones, consideramos todas las posibilidades para lograr un objetivo específico, como construir una Cadena de bloques de alto rendimiento o una función específica. Por supuesto, al construir una Cadena de bloques o elegir las funciones específicas que se utilizarán en un sistema real, debemos seleccionar una de esas posibilidades. Debemos tomar decisiones constantemente sobre cuál de todas esas buenas ideas es realmente la más útil para las personas. ¿Cuál es la que la gente está buscando? ¿Cuáles son los cuellos de botella en la adopción de la Cadena de bloques? ¿Qué impide que las personas logren lo que quieren hacer? Al construir un sistema, aún considerarás todas las posibilidades y tratarás de entender los escenarios posibles a partir de la literatura académica, y luego elegirás los más relevantes. Esto no es solo un interés por el conocimiento, sino crear valor para el usuario.

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 cómo 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 Ethereum se vuelve muy popular, la plataforma de Ethereum no puede soportar un volumen tan grande 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 claro que el problema radica en que no hay suficiente capacidad para satisfacer lo que la gente quiere hacer en estas cadenas de bloques. Esto no es solo una idea nuestra, hemos visto esta situación ocurrir una y otra vez. Durante un tiempo, esto fue considerado un desafío valioso, no solo por mi equipo, de hecho, toda la comunidad académica está investigando la cadena de bloques, todos están abordando este problema de diferentes maneras. Ahora, ya se ha desarrollado una cantidad considerable de tecnologías para ampliar la capacidad de la cadena de bloques y abordar estos desafíos. Pero en ese momento, era bien sabido 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, en comparación con el establecimiento de nuevas redes L1 como Sui?

L2 es una solución de escalado en el ecosistema de Ethereum. Sin embargo, para los desarrolladores de aplicaciones, utilizar la red L2 puede ser un poco complicado. Cuando una red L2 intenta interactuar con Ethereum, debe llevar a cabo actividades de puenteo, lo cual es cierto para cualquier relación L2/L1. El estado que representa un coin, activo u otra cosa 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 sucede en él. Pero esta es solo la primera parte, es decir, cualquier activo que exista en L1 necesita ser trasladado a L2, debe ocurrir alguna actividad en L2, y luego de alguna manera, el activo debe ser devuelto a L1. Esto es muy problemático.

Para los tokens, que son activos fungibles, esta actividad de puenteo ha sido relativamente fluida, ya que las personas tienen dos cuentas y un middleware de puenteo. Sin embargo, para activos más generales, no ha funcionado bien. Para usar realmente redes L2 en Ethereum para desarrollar aplicaciones más complejas que los tokens, necesitas contratos inteligentes en ambos lados, uno para acuñar y otro para destruir. Deben transitar entre dos ecosistemas diferentes, lo cual es una actividad personalizada para cada contrato. No puedes simplemente decir: voy a crear una red L2 y luego llevar todos los activos, operar a mi antojo y luego traerlos de vuelta; no hay tal concepto. Es un proceso manual y propenso a errores. Por lo tanto, no es una buena experiencia. Imagina que tienes activos en múltiples redes L2 diferentes, y también tienes estos contratos inteligentes personalizados en diferentes redes L2. Cada vez que quieres operar sobre un estado que está en otra red L2, tienes que puenteo de regreso a L1 y luego de nuevo a L2. No puedes simplemente decir: acabo de hacer algo en esta cadena de bloques y ahora quiero hacer algo más en otra cadena de bloques, sin tener que considerar en qué L1 o L2 está. Todo está aquí, lo tengo en la mano y estoy listo para realizar más transacciones en cualquier estado que quiera acceder. Esta es la razón por la que la experiencia de tener estados dispersos en redes L2 es mala. 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 me han interesado realmente.

Otro ejemplo es Cosmos, que tiene un ecosistema muy interesante, adoptando un enfoque diferente, es decir, escalando mediante el uso de diferentes cadenas de bloques para diferentes aplicaciones. Podemos realizar 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 el usuario, y luego puede usar esa aplicación y volver a puentear. Te encontrarás gastando 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, en realidad, 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 a Sui tener 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 llegar a un consenso; (2) cuando realmente se necesita 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. De este modo, no habrá una situación en la que un nodo de validación crea que has gastado un coin y lo has enviado a Alice, mientras que otro nodo de validación crea que el mismo coin se envió en realidad 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 el consenso, asegurando que la transacción ocurra y el sombrero esté en la cabeza de su NFT.

Pero en ciertos casos, las transacciones no solo implican objetos que le pertenecen, sino que son compartidos por muchas personas. Por ejemplo, si hay una subasta que vende pequeños sombreros, este tipo de subasta se representa en Sui como un objeto compartido. Las personas pueden hacer ofertas, y la persona que ofrezca más gana el sombrero. Esta subasta es un objeto que no pertenece a una sola entidad, y cada persona debe poder hacer ofertas, compartir y actualizar el estado sobre la última oferta, lo que requiere un consenso adicional. Sui Lutris le permite tener objetos compartidos y realizar transacciones sobre ellos, lo que le permite poseer otros objetos, cambiar el estado de los objetos compartidos o crear nuevos objetos compartidos. Permite la coexistencia de dos caminos y la interacción entre objetos exclusivos poseídos por individuos específicos y objetos compartidos por varias personas.

Estos dos caminos diferentes tienen distintas ventajas. La ruta rápida para objetos exclusivos tiene una latencia muy baja, con un tiempo requerido de menos de un segundo, lo que la hace muy rápida y ampliamente escalable. Por otro lado, la ruta de consenso tiene una latencia más alta, generalmente superior a un segundo, y su capacidad también es bastante alta, pero es más difícil de escalar en comparación con la primera ruta. En Sui, aquellos que realmente impulsan las aplicaciones en cadena a través de millones de transacciones diarias suelen utilizar la primera ruta y, en gran medida, estructuran sus aplicaciones para realizar la mayor parte de las transacciones en objetos exclusivos, en lugar de transacciones compartidas. Por el contrario, 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 llevar a cabo operaciones.

Q6: ¿Los desarrolladores de apps en Sui pueden diseñar sus apps 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 compartidos en un momento específico. Un truco para expandir aplicaciones en Sui es asegurarse de que la mayoría de las operaciones se realicen básicamente en objetos exclusivos, ya que Sui puede gestionar muchas operaciones que desee con una latencia muy baja, lo que ofrece una buena experiencia. Las operaciones necesarias para los juegos deben realizarse en esta categoría, ya que su latencia es muy baja en comparación con las operaciones que requieren mediación a través de estados compartidos y objetos compartidos. 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 son en cada categoría. Por supuesto, la primera versión del contrato puede considerar todo como un estado compartido, y todo se llevará a cabo a través de un camino de consenso de mayor latencia, pero a medida que se necesita escalar, los desarrolladores deben considerar hasta qué punto pueden hacerlo sin estas partes.

Q7: ¿Cómo funcionan los bloques de transacción 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 sola operación en la cadena. Por ejemplo, suponga que usted es una aplicación de plataforma de comercio, donde muchas personas compran y venden diferentes coins, puede realizar una transacción en la cadena, que conceptualmente corresponde al contenido que las personas compran y venden. Pero como usted es el intercambio, todos les pertenecen, por lo que puede liquidar mil transacciones al mismo tiempo, que es la ruta rápida. Por otro lado, si algunos objetos dentro del bloque de transacción programable son compartidos, entonces entramos en la ruta de consenso, momento en el cual la demora será un poco más alta, no será menos de un segundo, sino que tomará algunos segundos.

Q8: La red principal ha estado en línea durante más de 100 días, ¿el rendimiento de Sui ha confirmado sus teorías de investigación? ¿Hay algo que le haya sorprendido?

Hay varias cosas que confirman el diseño de Sui, pero también hay algunas cosas que hacen reflexionar. Una de ellas es que en momentos de gran volumen de transacciones, incluso en un momento específico, el volumen diario de transacciones supera los 60 millones, la mayoría de las cuales se realizan a través de una ruta rápida. Sui Lutris es muy escalable y tiene una latencia muy baja. Antes de eso, no estaba claro si alguien utilizaría esta ruta, pero cuando se necesita un gran número de transacciones y baja latencia, se utilizó y ¡funcionó muy bien! Es fácil ver que es este método. En esos días, el volumen de transacciones de Sui superó al de todos los demás.