Revelaciones del fundador de Sui: tecnología y desafíos de una cadena de bloques de alto rendimiento

Recientemente, entrevistamos a un experto conocido en el campo de la Cadena de bloques, donde discutimos 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 cofundador y científico principal de un laboratorio reconocido, y también es profesor en el campo de la seguridad y la privacidad en una universidad famosa.

A continuación se presenta 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 de renombre, y mi enfoque de investigación se centra principalmente en la seguridad y la privacidad. En mis primeros años, realicé una gran cantidad de investigaciones en sistemas de pares y sistemas anónimos, que eran principalmente sistemas distribuidos a gran escala con un enfoque en el almacenamiento. Con el desarrollo de la tecnología de cadena de bloques, especialmente con la aparición de Ethereum, me interesé profundamente en los libros de contabilidad distribuidos y la cadena de bloques, así como en cómo ejecutar contratos inteligentes. Comenzamos a investigar cómo construir sistemas de mayor rendimiento y a intentar comercializar algunas ideas. Más tarde, también participamos en un proyecto de cadena de bloques de una gran empresa de redes sociales, tratando de proponer soluciones de escalabilidad. Cuando el proyecto no logró avanzar, 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?

De hecho, no hay una gran diferencia. Al investigar, consideramos todas las posibilidades para alcanzar objetivos específicos, como construir una Cadena de bloques de alto rendimiento. Sin embargo, en la aplicación práctica, debemos elegir entre muchas buenas ideas y juzgar cuáles son las más valiosas y las que mejor se adaptan a las necesidades de los usuarios. Necesitamos considerar los cuellos de botella en la adopción de la Cadena de bloques y los factores que obstaculizan a las personas para lograr sus objetivos. Al construir sistemas, todavía nos referimos a la literatura académica, pero nos enfocamos más en crear valor práctico para los usuarios.

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

Principalmente me enfoco en cómo expandir las diferentes funciones de la Cadena de bloques, especialmente en aumentar el rendimiento de las transacciones y reducir la latencia. Este problema es muy evidente: cada vez que un contrato se vuelve popular en Ethereum, la plataforma no puede soportar tal volumen de transacciones, lo que lleva a congestión y un aumento explosivo en las tarifas. Hemos visto repetidamente que la capacidad de procesamiento de la Cadena de bloques no puede satisfacer las demandas de los usuarios. Este desafío no solo ha llamado la atención de nuestro equipo, sino que toda la comunidad académica está investigando diferentes soluciones. Hoy en día, se han desarrollado muchas tecnologías para expandir las capacidades de la Cadena de bloques.

Q4: ¿Cuál es la diferencia y los beneficios de la red L2 como una solución al problema de escalabilidad en comparación con el establecimiento de una nueva red L1?

L2 es una solución de escalado en el ecosistema de Ethereum, pero su uso puede ser un poco complicado para los desarrolladores. La transferencia de activos entre L2 y L1 requiere operaciones de puente complejas, lo que afecta negativamente a la experiencia del usuario. Para tokens simples está bien, pero para activos más complejos se vuelve difícil. Mover activos entre diferentes redes L2 también es complicado.

En comparación, nuestra solución es establecer una gran base de datos distribuida que contenga todos los estados. Una vez que se completa la transacción, todos los estados pueden ser utilizados inmediatamente para la siguiente transacción, sin necesidad de transferencias entre diferentes redes. Esto proporciona a los usuarios una experiencia más fluida.

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 ideas clave: primero, muchas operaciones de Cadena de bloques en realidad no requieren consenso; segundo, para los casos que requieren consenso, tenemos un enfoque de alta capacidad de procesamiento. Esto asegura que los nodos de validación que siguen el protocolo nunca se encuentren en un estado inconsistente.

Sui Lutris ofrece dos caminos diferentes: un camino rápido que no requiere consenso y un camino de consenso que sí lo necesita. Para los objetos que son de propiedad del usuario, se puede utilizar el camino rápido, obteniendo la finalización de la transacción sin esperar el consenso. Para los objetos compartidos por múltiples personas, se debe utilizar el camino de consenso.

La latencia del camino rápido es extremadamente baja, generalmente menos de un segundo, y puede escalar ampliamente. La latencia del camino de consenso es más alta, pero su capacidad también es grande. La mayoría de las transacciones diarias pueden usar el camino rápido, mientras que las operaciones complejas de DeFi generalmente requieren el camino de consenso.

Q6: ¿Los desarrolladores de aplicaciones en Sui pueden diseñar sus aplicaciones para aprovechar la ruta rápida?

Absolutamente. Este es uno de los trabajos centrales en el diseño de aplicaciones extendidas. Los desarrolladores pueden controlar completamente si los objetos con los que operan en el contrato son exclusivos o compartidos. Un truco para extender aplicaciones en Sui es asegurarse de que la mayoría de las operaciones se basen en objetos exclusivos, lo que permite lograr una latencia muy baja.

Los diseñadores de contratos inteligentes tienen control total sobre esto. Pueden especificar con precisión cada tipo de transacción. Aunque la versión inicial del contrato puede considerar todo como un estado compartido, a medida que se necesita expandir, los desarrolladores deben considerar cómo maximizar el uso de rutas rápidas.

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

Los bloques de transacciones programables se pueden utilizar en la ruta rápida o en la ruta de consenso. Si solo se involucran objetos exclusivos, se pueden realizar múltiples operaciones en una única operación en la cadena, con una latencia muy baja. Si se involucran objetos compartidos, se entrará en la ruta de consenso, donde la latencia será un poco más alta. Esto proporciona flexibilidad a los desarrolladores, quienes pueden elegir la ruta adecuada según sus necesidades.

Q8: Han pasado más de 100 días desde el lanzamiento de la red principal, ¿la actuación de Sui ha confirmado su teoría de investigación hipotética? ¿Hay algo que le haya sorprendido?

Ciertamente hay algunas cosas que confirman el diseño de Sui, pero también hay algunas situaciones que hacen reflexionar. Cuando el volumen de transacciones es especialmente alto, Sui maneja más de 60 millones de transacciones al día, la mayor parte a través de rutas rápidas. Esto demuestra la escalabilidad y las características de baja latencia de Sui Lutris.

Sin embargo, también hemos encontrado que el uso de la ruta rápida tiene algunas sutilezas. A veces, los objetos pueden ser bloqueados por error, aunque generalmente se desbloquean al final de un epoch, pero esta no es una experiencia ideal. Estamos desarrollando un conjunto de tecnologías que permiten desbloquear rápidamente los objetos que han sido bloqueados por error.

Además, también estamos explorando cómo permitir que más tipos de objetos utilicen el camino rápido, incluso si son compartidos por múltiples partes. Esto podría mejorar aún más el rendimiento y la flexibilidad de Sui.

Q9: ¿Puede compartir más detalles sobre las razones actuales que están causando el bloqueo de objetos?

El bloqueo de objetos suele ocurrir en la ruta rápida, cuando el sistema recibe una secuencia de operaciones contradictorias. Por ejemplo, si el teléfono móvil y la computadora de un usuario realizan operaciones en el mismo activo en un orden diferente, Sui no podrá determinar la secuencia correcta, lo que resultará en el bloqueo del objeto.

Al principio pensamos que esta situación no ocurriría con frecuencia, pero en realidad es más común de lo que esperábamos. Actualmente, los objetos bloqueados necesitan esperar hasta que termine un epoch para desbloquearse, lo que puede causar problemas graves.

Estamos desarrollando soluciones que, cuando un objeto está bloqueado, el sistema puede resolver rápidamente el problema a través de la ruta de consenso, en lugar de esperar a que termine el epoch. Esto mejorará significativamente la experiencia del usuario.

Q10：¿Cuál es su opinión sobre cómo equilibrar mejor la transparencia, la trazabilidad y la privacidad en una cadena de bloques pública?

En las cadenas de bloques públicas, la necesidad de privacidad depende en gran medida de la aplicación específica. El enfoque de Sui es proporcionar herramientas a los desarrolladores de aplicaciones para que puedan implementar la protección de la privacidad según sea necesario.

Para ello, Sui ofrece un soporte nativo de criptografía, como la capacidad de verificar pruebas de conocimiento cero. Esto permite a los diseñadores de aplicaciones verificar ciertos eventos fuera de la cadena, sin necesidad de revelar detalles específicos en la cadena.

Los desarrolladores de aplicaciones pueden abordar los problemas de privacidad según sus necesidades, combinando estrategias en cadena, fuera de la cadena y de cifrado. Creemos que esta flexibilidad puede satisfacer las necesidades de diferentes tipos de aplicaciones.

Q11: ¿Hay más soporte nativo para la privacidad en Sui?

La comunidad está discutiendo proporcionar más apoyo para la redacción de contratos inteligentes que sean amigables con la privacidad para los desarrolladores. Además de las pruebas de conocimiento cero, también estamos considerando agregar más funciones matemáticas o criptográficas generales.

Damos la bienvenida a los diseñadores de contratos inteligentes para que proporcionen comentarios sobre las funciones que faltan. Además, hay otras tecnologías como el cálculo multipartito o el hardware confiable que también pueden utilizarse para proteger la privacidad. Si la comunidad tiene una fuerte demanda de estas tecnologías, consideraremos realizar ajustes arquitectónicos correspondientes.

Q12: ¿Cómo cree que se desarrollará Sui en los próximos 6 a 12 meses?

El desarrollo de Sui dependerá en gran medida de las aplicaciones desarrolladas en la plataforma. A corto plazo, realizaremos mejoras en función de las necesidades de aplicaciones prácticas. A largo plazo, nos dedicaremos a mejorar el protocolo Sui Lutris para lograr una menor latencia y una estructura de protocolo más simple, mejorando la escalabilidad.

También nos esforzaremos por mejorar la eficiencia económica, permitiendo que los nodos de verificación puedan operar en hardware más restringido y optimizando el uso de recursos de hardware. Estas mejoras harán que Sui sea más eficiente y poderoso.