Diálogo en profundidad con el científico jefe de Mysten Labs: de la teoría a la práctica, ¿cómo resuelve Sui el problema de la escalabilidad de la red?

Recientemente, entrevistamos a George Danezis para analizar la complejidad y escalabilidad de la infraestructura de Sui y cómo el sistema de procesamiento de transacciones de Sui permite una red de alto rendimiento. George Danezis es cofundador y científico jefe de Mysten Labs (y colaborador original de Sui) y profesor en el campo de ingeniería de seguridad y privacidad en la UCL.

El siguiente es el contenido de esta entrevista:

**P1: Usted pertenece al campo académico, ¿puede presentar su enfoque de investigación? **

Soy profesor en el University College London (UCL) y mi investigación se centra en la seguridad y la privacidad en un sentido amplio. A principios del siglo XX, investigué bastante sobre sistemas peer-to-peer y anónimos, muchos de los cuales eran grandes sistemas distribuidos centrados en el almacenamiento. A medida que toda la cadena de bloques se volvió más orientada a la ejecución, especialmente representada por Ethereum, me interesé en los libros de contabilidad distribuidos y las cadenas de bloques y en cómo ejecutar contratos inteligentes. La naturaleza sin permiso me resulta familiar gracias a mi trabajo en los primeros sistemas peer-to-peer. Así que mi grupo de investigación en la UCL se propuso descubrir cómo construir sistemas de mayor rendimiento. Creamos Chainspace para comercializar algunas de nuestras ideas y Facebook adquirió el equipo. Luego ayudamos a Facebook a encontrar una solución para escalar la cadena de bloques Libra/Diem. Pero cuando la propuesta no avanzó, la dejé y seguí buscando otras oportunidades para implementar el concepto de blockchain de alto rendimiento.

**P2: Todavía eres profesor, entonces, ¿cuál crees que es la diferencia entre aplicación e investigación? **

Realmente no hay mucha diferencia. Cuando realizamos una investigación, 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, a la hora de construir una blockchain o elegir una función específica para usar en un sistema real, tenemos que elegir una de estas posibilidades. Tenemos que tomar decisiones constantemente, de todas estas buenas ideas, ¿cuáles son en realidad las más útiles para las personas? ¿Qué es lo que busca la gente? ¿Cuáles son los obstáculos en la adopción de blockchain? ¿Qué impide que las personas logren lo que quieren hacer? Al construir un sistema, todavía se consideran todas las posibilidades, se intenta comprender lo que es posible a partir de la literatura académica y luego se elige lo que es más relevante. No se trata sólo de interés intelectual, sino de creación de valor para los usuarios.

**P3: Al pasar de la teoría a la aplicación práctica, ¿cómo se determina qué problemas resolver? **

El principal problema que abordo en mi investigación es cómo escalar las diferentes funciones de blockchain. Me concentro en los aspectos del sistema de blockchain, es decir, cómo aumentar el rendimiento de las transacciones y reducir la latencia. El problema a este respecto es obvio: cada vez que vemos que un determinado contrato en Ethereum se vuelve muy popular, la plataforma Ethereum no puede soportar un volumen de transacciones tan grande, se produce congestión en las transacciones y las tarifas se disparan. Cada vez que una cadena de bloques ha logrado el éxito, la hemos visto manejar más transacciones de las que tiene actualmente. Claramente el problema es que no hay suficiente capacidad para lo que la gente quiere hacer en estas cadenas de bloques. No está sólo en nuestras mentes, lo hemos visto suceder una y otra vez. Durante un tiempo, esto fue reconocido como un desafío digno, no solo en mi grupo, sino que de hecho toda la comunidad académica estaba trabajando en blockchain, cada uno estaba resolviendo este problema de diferentes maneras. Ahora, se han desarrollado bastantes tecnologías para ampliar las capacidades de blockchain y abordar estos desafíos. Pero en aquella época, como todos sabemos, mucha gente lo abordaba de diferentes maneras.

**P4: La red L2 es una forma propuesta por la gente para resolver el problema de escala. ¿Cuál es la diferencia y el beneficio de construir una nueva red L1 como Sui? **

L2 es una solución para escalar en el ecosistema Ethereum. Pero para los desarrolladores de aplicaciones, trabajar con redes L2 es un poco complicado. Cuando una red L2 intenta interactuar con Ethereum, debe ocurrir una actividad de puente, aunque esto es cierto para cualquier relación L2/L1. El estado que representa una moneda, activo u otro contenido en L1 debe reflejarse en L2 y viceversa. Más allá de eso, L2 debe tener algún mecanismo para que L1 pueda verificar todo lo que sucede en él. Pero eso es sólo la primera parte, cualquier activo que exista en L1 debe transferirse a L2, alguna actividad debe ocurrir en L2 y luego, de alguna manera, transferir el activo de regreso a L1. Esto es muy problemático.

Para activos fungibles como los tokens, esta actividad puente es relativamente fluida, porque las personas tienen dos cuentas y un middleware puente. Pero para activos más generales, no funciona tan bien. Para utilizar realmente la red L2 en Ethereum para desarrollar aplicaciones más complejas que los tokens, es necesario tener contratos inteligentes en ambos lados, uno para acuñar (mint) y otro para quemar (burn). Tienen que desplazarse entre dos ecosistemas diferentes, lo cual es una actividad personalizada para cada contrato. No se puede decir simplemente: voy a crear una red L2 y quitaré todos los activos y haré lo que quiera y los traeré de vuelta; no existe tal concepto. Este es un proceso manual y muy propenso a errores. Entonces no es una gran experiencia. Imagine que tiene activos en varias redes L2 diferentes y tiene estos contratos inteligentes personalizados en diferentes redes L2. Cada vez que desee operar en algún estado que esté en otra red L2, debe hacer un puente hasta L1 y luego regresar a L2. No se puede decir fácilmente: acabo de hacer algo en esta cadena de bloques y luego voy a hacer otra cosa en otra cadena de bloques, y no necesito pensar en en qué L1 o L2 está. Está todo aquí y lo tengo en mis manos ahora mismo, listo para realizar más transacciones en cualquier estado que quiera visitar. Es por eso que difundir el estado a través de una red L2 es una mala experiencia. Mover activos entre diferentes cadenas es complicado y obvio para los usuarios. Es por eso que las redes L2 nunca despertaron mi interés.

Otro ejemplo es Cosmos, que tiene un ecosistema muy interesante que adopta otro enfoque de escalamiento mediante el uso de diferentes cadenas de bloques para diferentes aplicaciones. Podemos tener diferentes velocidades de transacción en diferentes cadenas y unir activos entre cadenas cuando necesitamos operar entre diferentes aplicaciones, pero también enfrenta el mismo problema. Cada vez que desee utilizar una aplicación diferente, primero debe realizar una operación de puente, que es sutil y obvia para el usuario, y luego puede usar esa aplicación y volver a conectarla. Te encontrarás pasando más tiempo moviendo activos de una cadena a otra que haciendo lo que realmente quieres hacer.

En Sui, nuestra solución es crear una base de datos grande que, de hecho, contenga todo el estado replicado por los validadores. Una vez que completa una transacción, todo el estado en la misma base de datos se puede usar para realizar la siguiente transacción sin que los usuarios tengan que mover constantemente los estados de los activos entre L1 y L2.

**P5: Sui Lutris es la base del protocolo Sui. ¿Cuáles son sus innovaciones clave que permiten a Sui tener un alto rendimiento y baja latencia? **

Sui Lutris consta de dos ideas clave: (1) para muchas operaciones en la cadena de bloques, en realidad no se requiere consenso; (2) cuando se necesita consenso, existe un método de muy alto rendimiento que combinará estos dos métodos. Sui Lutris es el núcleo del sistema distribuido de Sui, lo que garantiza que dos nodos de verificación diferentes que siguen el protocolo nunca estarán en un estado inconsistente al realizar transacciones en la red distribuida. No existe una situación en la que un validador piense que usted gastó una moneda y se la envió a Alice, mientras que otro validador piense que la misma moneda en realidad se envió a Bob.

🌟 Auto nutria:

Dos caminos diferentes, uno que no requiere consenso (camino rápido) y otro que requiere consenso (camino del consenso). Cuando el objeto que quieres manipular te pertenece solo a ti, como tu propio personaje NFT y el sombrero que quieres combinar para que tu personaje pueda usar el sombrero, en teoría nadie más debería poder manipularlos. En estos casos, Sui utiliza la ruta rápida, lo que significa que puede manipular sus propios objetos, obtiene la finalidad de la transacción sin esperar el consenso, se garantiza que la transacción se realizará y el sombrero está en su cabeza NFT.

Pero en algunos casos, las transacciones no involucran sólo objetos que le pertenecen a usted, sino que son compartidos por muchas personas. Por ejemplo, si hay una subasta que vende sombreros pequeños, este tipo de subasta se representaría en Sui como un objeto compartido. La gente puede pujar y el mejor postor gana el sombrero. Este tipo de subasta es un objeto que no pertenece a una sola entidad. Todos deben poder ofertar, compartir y actualizar el estado sobre la última oferta. Este tipo de operaciones requieren un consenso adicional. Sui Lutris le permite poseer objetos compartidos y realizar transacciones con ellos, lo que le permite poseer otros objetos, cambiar el estado de los objetos compartidos o crear nuevos objetos compartidos. Permite que ambos caminos coexistan e interactúen entre objetos exclusivos propiedad de un individuo en particular u objetos compartidos por varias personas.

Estos dos caminos diferentes tienen diferentes ventajas. La ruta rápida para objetos exclusivos tiene una latencia extremadamente baja, tarda menos de un segundo, es muy rápida y se escala ampliamente. La ruta de consenso tiene una latencia más alta, generalmente superior a un segundo, y una capacidad bastante alta; sin embargo, es más difícil de escalar que la primera ruta. En Sui, los que realmente impulsan aplicaciones en cadena con millones de transacciones por día generalmente usan la primera ruta y estructuran sus aplicaciones en gran medida para tener la mayor cantidad de transacciones principalmente en objetos exclusivos, aunque no es un acuerdo de acciones. Por otro lado, los protocolos que realizan trabajos complejos (como DeFi) suelen practicar el segundo tipo de transacción, porque deben combinar ofertas o liquidez de muchas personas diferentes para realizar las operaciones.

**P6: ¿Pueden los desarrolladores de aplicaciones en Sui diseñar sus aplicaciones para aprovechar la vía rápida? **

Si, absolutamente. Creo que este es el trabajo principal de un diseñador de aplicaciones de extensión. Los desarrolladores de contratos inteligentes tienen control total sobre si los objetos que manipulan dentro del contrato son objetos exclusivos o compartidos de una sola entidad en un momento dado. Uno de los trucos para escalar su aplicación en Sui es asegurarse de que la mayoría de las operaciones se realicen básicamente en objetos exclusivos, porque Sui puede administrar tantas operaciones como desee con una latencia muy baja, lo cual es una experiencia agradable. Las operaciones necesarias para el juego deben realizarse en esta categoría y su latencia es muy baja en comparación con las operaciones que deben mediarse a través de estados y objetos compartidos. Una vez que se hace clic, la transacción se puede completar instantáneamente en la red.

El diseñador de contratos inteligentes tiene control total sobre esto y básicamente puede especificar exactamente cuáles son las transacciones en cada categoría. Por supuesto, la primera versión del contrato puede tratar todo como un estado compartido, y todo irá por el camino de consenso de mayor latencia, pero como es necesario escalar, los desarrolladores deben considerar hasta dónde pueden hacerlo. .

**P7: ¿Cómo juega un papel el bloque de transacciones programable en esto? **

Los bloques de transacciones programables pueden funcionar tanto en la vía rápida como en la vía de consenso. Si un bloque de transacciones programables solo involucra su objeto exclusivo, significa que puede realizar múltiples operaciones en una sola operación en cadena. Por ejemplo, supongamos que tiene una aplicación CEX donde muchas personas compran y venden diferentes monedas. Puede realizar una transacción en la cadena, que conceptualmente corresponde a lo que la gente está comprando y vendiendo. Pero como usted es un intercambio, todas le pertenecen, por lo que se pueden liquidar mil transacciones al mismo tiempo, que es el camino más rápido. Por otro lado, si se comparten algunos objetos en el bloque de transacción programable, entonces se ingresa a la ruta de consenso y la latencia será ligeramente mayor, no menos de un segundo sino varios segundos.

**P8: La red principal ha estado en línea durante más de 100 días. ¿El desempeño de Sui ha confirmado su hipotética teoría de investigación? ¿Hay algo que te haya sorprendido? **

Hay algunas cosas que confirman el diseño de Sui, pero también hay cosas que dan que pensar. Una es que cuando el volumen de transacciones es particularmente grande, incluso en un momento especial, el volumen de transacciones diarias supera incluso los 60 millones, la mayoría de las cuales están en la vía rápida. Sui Lutris es muy escalable y tiene una latencia muy baja. Hasta entonces, no está claro si alguien usará esta ruta, pero cuando se requieren altos volúmenes de transacciones y baja latencia, se usa y ¡funciona muy bien! Es fácil de ver, ese es el método. En aquellos días, Sui tenía más transacciones que todas las demás cadenas de bloques juntas. Esta es una validación interesante de que el diseño de Sui es sólido.

Mientras tanto, la comunidad Sui encontró este camino rápido un poco complicado. Debido a que los propietarios de objetos tienen que gestionar el orden de las operaciones en sus propios objetos hasta cierto punto, a veces las cosas pueden salir mal. A veces incluso pueden usar una biblioteca que no les ayuda, y la biblioteca misma falla, por lo que a veces los objetos se bloquean. Normalmente se desbloquean al final del día, al final de una época, pero esa no es una gran experiencia. Las personas que diseñan contratos inteligentes pueden sentirse intimidadas por esto, por temor a que se produzcan errores, lo que les impide aprovechar al máximo las funciones de baja latencia y escalabilidad. Se están desarrollando toda una serie de tecnologías para permitir a quienes han bloqueado objetos por error desbloquearlos rápidamente en cuestión de segundos. Entonces, si intenta usar la ruta rápida, ocurre un error y su objeto está bloqueado, puede usar inmediatamente la ruta de consenso para desbloquearlo sin esperar hasta que termine una época.

Y, por extraño que parezca, no se trata sólo de evitar errores, sino que permite a los desarrolladores expresar rápidamente muchas más cosas; existen técnicas potenciales en las que algunos objetos no son propiedad de una sola parte. Tal vez haya un objeto que usted y yo poseemos conjuntamente, porque es compartido y, por lo general, las transacciones sobre ese objeto tienen que pasar por la ruta del consenso. Sin embargo, si Sui tuviera una forma de desbloquear objetos rápidamente, los desarrolladores podrían intentar acelerar las transacciones. En el caso de que usted y yo estemos realizando transacciones sobre el mismo objeto exactamente al mismo tiempo, el sistema se bloqueará, incapaz de decidir qué transacción se realizará a continuación, y luego Sui podrá desbloquearlo y pasar por la ruta de consenso. haciéndolo compartido y resolviéndolo. Pero eso no puede suceder a menos que la gente intente competir deliberadamente. Una vez que Sui tenga la funcionalidad para permitir que se desbloqueen objetos, debería poder acelerar objetos que pertenecen a varias personas. Es un juego que intenta pasar el mayor volumen de transacciones posible a través del camino rápido, que es un tipo de cosa que se está desarrollando para ayudar a la comunidad de creadores.

**P9: ¿Puede compartir con más detalle qué está provocando actualmente el bloqueo de objetos? **

La razón por la que no es necesario pasar por consenso para decirle a Sui la secuencia de operaciones que deben realizarse cuando un objeto es suyo es porque nadie más puede operar con su objeto. Sui depende de que usted le diga al sistema que la acción A ocurrirá primero, la acción B ocurrirá después y la acción C ocurrirá al final. El sistema todavía tiene que comprobar que todos ven los ABC en el mismo orden. El sistema se implementa a través de un protocolo distribuido que simplemente verifica si todos vimos ABC por turno. La pregunta es si usted comete un error o su software comete un error. Por ejemplo, si su teléfono controla su activo y su computadora controla su activo, su teléfono dice que A sucedió primero y su computadora dice que B sucedió primero. Estás clasificando dos cosas diferentes incorrectamente. Esto es una contradicción. En este caso, Sui diría: "Bueno, la persona a la que encargué que me dijera la secuencia parece haberme dado dos cosas contradictorias, así que no sé qué hacer. No sé cómo solucionar esto". Porque Sui Este problema generalmente se resuelve mediante el camino del consenso. Pero aquí estás intentando utilizar el camino rápido. Entonces Sui levantó la mano y dijo: "Está bien, aquí hay un error".

La suposición inicial era que esto no sucedería muy a menudo, pero resulta que sucede con bastante frecuencia cuando las personas usan diferentes dispositivos o intentan realizar múltiples transacciones con el mismo objeto al mismo tiempo. Actualmente, cuando estos objetos están bloqueados, Sui espera hasta el final de una época para desbloquearlos, lo cual es muy preocupante. Imagínese si sus activos estuvieran inutilizables por un día, esto podría ser un problema grave.

Así que ahora Sui necesita evolucionar para tomar la acción correcta cuando algo está bloqueado. Si la entidad encargada de proporcionar la orden correcta da una orden ambigua, Sui resolverá toda la situación mediante consenso. Esto sucederá en segundos, no al final de una época.

**P10: Gran parte de su investigación gira en torno a la privacidad. ¿Qué piensa sobre cómo las cadenas de bloques públicas pueden equilibrar mejor la transparencia, la trazabilidad y la privacidad? **

En la cadena pública, cómo equilibrar la transparencia, la trazabilidad y la privacidad es una cuestión muy relacionada con las aplicaciones, y mi punto de vista sobre la privacidad es que lo que debe mantenerse privado depende en gran medida de la aplicación misma. Por ejemplo, en Sui, tiene sentido que los desarrolladores de aplicaciones desarrollen contratos que protejan la privacidad de sus usuarios. Debido a que algunas personas solo quieren desarrollar juegos, tal vez las preocupaciones por la privacidad no sean tan importantes. Algunas personas quieren realizar transacciones financieras en blockchain, y la privacidad puede ser una preocupación mayor, pero al mismo tiempo, existen otros tipos de cuestiones regulatorias involucradas. Entonces, la actitud de Sui es que le brindaremos una buena plataforma y usted necesita generar privacidad en esta plataforma.

Para ayudar a las personas a generar privacidad, Sui brinda soporte criptonativo que puede resultarles útil al diseñar contratos inteligentes. Uno de los más importantes es la capacidad de verificar pruebas de conocimiento cero en Sui. Existe una función nativa que verifica uno de los esquemas más utilizados y comprendidos, el esquema Groth16 desarrollado por mi colega Jens Groth. Esto significa que, de hecho, los diseñadores de aplicaciones pueden verificar ciertos eventos fuera de la cadena sin revelar cuáles son esos eventos. Este es el elemento fundamental para crear toda una clase de aplicaciones respetuosas con la privacidad que mantienen cierto estado fuera de la cadena, pero dentro de la cadena se puede verificar que todo lo que sucede fuera de la cadena es correcto.

Los desarrolladores de aplicaciones deciden qué tipo de protección de privacidad necesitan sus aplicaciones y utilizan estos soportes nativos para combinar estrategias de cifrado dentro, fuera y dentro de la cadena para abordar los problemas de privacidad que puedan encontrar.

**P11: ¿Existe más soporte nativo para la privacidad en Sui? **

La comunidad está pensando en el apoyo que los desarrolladores necesitan para escribir contratos inteligentes en un entorno más respetuoso con la privacidad. La prueba de conocimiento cero es una de ellas. Algunas personas pueden pensar que Sui necesita funciones matemáticas o criptográficas más generales en la cadena. Nos encantaría ver a los diseñadores de contratos inteligentes brindar comentarios sobre lo que falta, y hay toda una clase de otras técnicas que se pueden usar para preservar la privacidad, como la computación multipartita o el hardware confiable. Se han desarrollado diferentes blockchains en esta dirección, que requieren sistemas adicionales muy complejos. Es necesario que haya suficiente evidencia en la comunidad de que la gente quiere estas tecnologías, ya que representan algunos cambios fundamentales en la arquitectura de Sui. Pero si la comunidad quiere avanzar en esa dirección, existe un proceso para proponer formas de agregar protecciones de privacidad.

**P12: ¿Cómo crees que se desarrollará Sui en los próximos 6 a 12 meses? **

Depende de qué tipo de aplicaciones la gente cree en Sui y, a corto plazo, muchas de las mejoras se aplicarán a las aplicaciones que la gente realmente está creando. Desde una perspectiva a muy largo plazo, según los estándares de blockchain, de 6 a 12 meses puede considerarse un tiempo muy largo. Mejoraremos el protocolo Sui Lutris para lograr una latencia más baja, protocolos más simples y mejorar la escala de Sui. Además, haría que la economía fuera más eficiente, permitiendo que los nodos de validación se ejecuten en hardware más restringido y utilicen el hardware existente para ejecutar transacciones en lugar de realizar criptografía u otros gastos generales de la cadena de bloques. Esto es lo que esperamos ver.