Recientemente, entrevistamos a un experto en el campo de la 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 uno de los primeros contribuyentes de Sui y también es profesor en el campo de la seguridad y privacidad en el University College de Londres.
A continuación se presenta el contenido de esta entrevista:
Q1：¿Puede presentarnos su enfoque de investigación?
Soy profesor en el University College London, y mi enfoque de investigación es la seguridad y la privacidad. En mis primeros trabajos investigué sistemas de igual a igual y sistemas anónimos, centrándome principalmente en grandes sistemas distribuidos con un enfoque en el almacenamiento. Con el desarrollo de la cadena de bloques, especialmente con la aparición de Ethereum, me interesé en los libros de contabilidad distribuidos y los contratos inteligentes. Mi grupo de investigación en UCL comenzó a investigar cómo construir sistemas de mayor rendimiento. Fundamos la empresa Chainspace para comercializar algunas ideas, y más tarde el equipo fue adquirido por otra compañía. Después, ayudamos a proponer soluciones para escalar la cadena de bloques. Cuando las soluciones no progresaron, continué buscando otras oportunidades para realizar la idea de una cadena de bloques de alto rendimiento.
Q2: ¿Cuál es la diferencia entre la aplicación y la investigación?
En realidad, la diferencia no es tan grande. Al investigar, consideramos todas las posibilidades para alcanzar objetivos específicos, como construir una Cadena de bloques de alto rendimiento. Pero al construir un sistema en la práctica, debemos elegir la solución más útil y que mejor se ajuste a las necesidades entre muchas buenas ideas. Necesitamos juzgar qué obstaculiza a las personas para alcanzar sus objetivos, aprender de la literatura académica sobre las situaciones posibles y luego seleccionar el contenido más relevante. Esto no es solo interés por el conocimiento, sino crear valor 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 evidente, cada vez que un contrato inteligente se vuelve muy popular, la plataforma no puede soportar el enorme volumen de transacciones, lo que provoca congestión y un aumento de tarifas. Hemos visto una y otra vez que la capacidad de procesamiento de la Cadena de bloques no puede satisfacer las necesidades de los usuarios. Esto se considera un desafío valioso, y no solo mi equipo, sino toda la comunidad académica está abordando este problema de diferentes maneras. Ahora se han desarrollado muchas tecnologías para expandir las capacidades de la Cadena de bloques.
Q4: ¿Cuáles son las diferencias y ventajas entre la red L2 y el establecimiento de una nueva red L1?
L2 es una solución de escalado en un ecosistema, pero puede ser algo complicado para los desarrolladores. Al interactuar L2 con L1, es necesario hacer un puente, el estado en L1 debe reflejarse en L2 y viceversa. L2 también necesita un mecanismo que permita a L1 verificar todo lo que ocurre en él. Este proceso es engorroso, especialmente para activos complejos. Mover activos entre diferentes L2 también es complicado.
Otra forma es usar diferentes cadenas de bloques para diferentes aplicaciones, pero también enfrenta problemas de puente. Los usuarios necesitan realizar puentes de activos con frecuencia al operar entre diferentes aplicaciones, lo que resulta en una mala experiencia.
Nuestra propuesta es establecer una base de datos grande que contenga el estado replicado de todos los nodos verificados. Una vez que se complete la transacción, todos los estados en la misma base de datos estarán disponibles para la siguiente transacción, de modo que los usuarios no necesiten mover constantemente el estado de los activos entre diferentes redes.
Q5: ¿Cuál es la innovación clave de Sui Lutris y cómo logra un alto rendimiento y baja latencia?
Sui Lutris tiene dos conceptos clave: muchas operaciones no requieren consenso, y cuando se necesita consenso, hay un método de alta capacidad de procesamiento. Asegura que los nodos de validación nunca estén en un estado inconsistente al procesar transacciones.
Sui Lutris tiene dos caminos: el camino rápido (sin necesidad de consenso) y el camino de consenso. Utiliza el camino rápido al operar con tus propios objetos, obteniendo la finalización de la transacción sin esperar el consenso. Las transacciones que implican objetos compartidos requieren el camino de consenso.
La ruta rápida tiene una latencia extremadamente baja, de menos de un segundo, y es ampliamente escalable. La ruta de consenso tiene una latencia más alta, generalmente superior a un segundo, con alta capacidad pero menor escalabilidad. La mayoría de las transacciones diarias utilizan la ruta rápida, mientras que las operaciones complejas de DeFi suelen utilizar la ruta de consenso.
Q6: ¿Pueden los desarrolladores diseñar aplicaciones para aprovechar el camino rápido?
Absolutamente. Los desarrolladores de contratos inteligentes pueden controlar si los objetos de operación son exclusivos o compartidos. La clave para la expansión de la aplicación es garantizar que la mayoría de las operaciones se basen en objetos exclusivos para lograr una baja latencia. Aplicaciones como juegos deberían intentar utilizar este método en lugar de depender de estados compartidos y objetos compartidos. Los desarrolladores pueden especificar con precisión cada tipo de transacción y optimizar el diseño cuando sea necesario expandirse.
Q7：¿Cómo funcionan los bloques de transacción programables?
Los bloques de transacciones programables se pueden utilizar en una ruta rápida o en una ruta de consenso. Si solo se involucran objetos exclusivos, se pueden realizar múltiples operaciones en una única operación de cadena, con una baja latencia. Si se incluyen objetos compartidos, se entra en la ruta de consenso, con una latencia un poco más alta. Esto proporciona flexibilidad para diferentes escenarios.
Q8: ¿La actuación de Sui después del lanzamiento de la red principal ha confirmado su teoría de investigación? ¿Hubo algún hallazgo inesperado?
El diseño de Sui ha sido validado, especialmente durante períodos de alto volumen de transacciones. Un día, el volumen de transacciones superó los 60 millones, la mayoría utilizando rutas rápidas, lo que demuestra la escalabilidad y baja latencia de Sui Lutris.
Pero la comunidad también ha encontrado que el camino rápido es algo sutil. A veces, los objetos pueden ser bloqueados erróneamente, aunque generalmente se desbloquean al final de la epoch, pero esta no es una buena experiencia. Se están desarrollando tecnologías que permiten desbloquear rápidamente los objetos bloqueados.
Estas nuevas tecnologías no solo pueden evitar errores, sino que también podrían permitir a los desarrolladores expresar más operaciones a través de vías rápidas, e incluso manejar ciertas situaciones de objetos compartidos. Esto mejorará aún más el rendimiento y la flexibilidad de Sui.
Q9：¿Puede explicar detalladamente las razones que llevan al bloqueo de un objeto?
Cuando un objeto pertenece a un único usuario, Sui depende de que el usuario informe el orden de las operaciones. El sistema verifica si todos ven estas operaciones en el mismo orden. El problema surge cuando el usuario o el software cometen un error, como cuando diferentes dispositivos presentan un orden de operaciones contradictorio. En este caso, Sui no puede determinar el orden correcto y el objeto se bloqueará.
Esta situación es más común de lo esperado, ya que las personas utilizan múltiples dispositivos o realizan múltiples transacciones sobre el mismo objeto al mismo tiempo. Actualmente, los objetos bloqueados solo se desbloquean al final del epoch, lo que puede causar problemas graves.
Sui está desarrollando un nuevo mecanismo que, cuando se bloquea un objeto, resuelve rápidamente los conflictos a través de consenso, en lugar de esperar a que termine la epoch. Esto se completará en unos pocos segundos, mejorando considerablemente la experiencia del usuario.
Q10：¿Cuál es su opinión sobre cómo las cadenas públicas pueden equilibrar la transparencia, la trazabilidad y la privacidad?
Esto depende en gran medida de la aplicación específica. En una plataforma determinada, los desarrolladores de aplicaciones pueden crear contratos por su cuenta para proteger la privacidad del usuario. Algunas aplicaciones pueden no estar tan preocupadas por la privacidad, mientras que algunas aplicaciones financieras pueden necesitar más protección de la privacidad, teniendo en cuenta también las cuestiones regulatorias.
Para ayudar a construir la protección de la privacidad, la plataforma ofrece un soporte nativo de cifrado, 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 en la cadena.
Los desarrolladores de aplicaciones pueden decidir qué tipo de protección de la privacidad necesitan, y combinar estrategias en cadena, fuera de la cadena y de cifrado para abordar los desafíos de la privacidad.
Q11: ¿Hay más soporte nativo para la privacidad?
La comunidad está considerando proporcionar más soporte de contratos inteligentes amigables con la privacidad para los desarrolladores. Además de las pruebas de conocimiento cero, también pueden ser necesarias más funciones matemáticas o criptográficas generales. Damos la bienvenida a los diseñadores de contratos inteligentes a proporcionar comentarios sobre las funciones que faltan.
Otras tecnologías como el cálculo multipartito o el hardware de confianza también se pueden utilizar para proteger la privacidad, pero requieren sistemas adicionales complejos. Si la comunidad tiene una fuerte necesidad, se pueden agregar nuevos métodos de protección de la privacidad a través del proceso de propuestas.
Q12: ¿Cómo cree que se desarrollará Sui en los próximos 6 a 12 meses?
Las mejoras a corto plazo se centrarán en las necesidades de aplicaciones prácticas. A largo plazo, mejoraremos el protocolo Sui Lutris para lograr una menor latencia, un protocolo más simple y aumentar la escalabilidad. También mejoraremos la eficiencia económica, permitiendo que los nodos de validación operen en hardware más restringido y utilizaremos más el hardware existente para la ejecución práctica de transacciones, en lugar de otros gastos de la Cadena de bloques. Estas son las principales direcciones de desarrollo que esperamos ver.
Esta página puede contener contenido de terceros, que se proporciona únicamente con fines informativos (sin garantías ni declaraciones) y no debe considerarse como un respaldo por parte de Gate a las opiniones expresadas ni como asesoramiento financiero o profesional. Consulte el Descargo de responsabilidad para obtener más detalles.
17 me gusta
Recompensa
17
6
Compartir
Comentar
0/400
PancakeFlippa
· hace6h
También se destaca la velocidad de transacción rápida.
Ver originalesResponder0
BlockchainBard
· 07-29 03:23
El camino aún es largo.
Ver originalesResponder0
CryingOldWallet
· 07-29 03:17
Lo único que entiendo es el alto rendimiento.
Ver originalesResponder0
SocialAnxietyStaker
· 07-29 03:16
¿Las transacciones rápidas pueden mejorar la privacidad?
Ver originalesResponder0
DataBartender
· 07-29 03:06
sui enrollado en el cáñamo
Ver originalesResponder0
CryptoNomics
· 07-29 03:00
*bostezo* sus afirmaciones de rendimiento carecen de validación estadística rigurosa, para ser honesto
El fundador de Sui explica en detalle la complejidad de la infraestructura y la implementación de una cadena de bloques de alto rendimiento.
Recientemente, entrevistamos a un experto en el campo de la 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 uno de los primeros contribuyentes de Sui y también es profesor en el campo de la seguridad y privacidad en el University College de Londres.
A continuación se presenta el contenido de esta entrevista:
Q1：¿Puede presentarnos su enfoque de investigación?
Soy profesor en el University College London, y mi enfoque de investigación es la seguridad y la privacidad. En mis primeros trabajos investigué sistemas de igual a igual y sistemas anónimos, centrándome principalmente en grandes sistemas distribuidos con un enfoque en el almacenamiento. Con el desarrollo de la cadena de bloques, especialmente con la aparición de Ethereum, me interesé en los libros de contabilidad distribuidos y los contratos inteligentes. Mi grupo de investigación en UCL comenzó a investigar cómo construir sistemas de mayor rendimiento. Fundamos la empresa Chainspace para comercializar algunas ideas, y más tarde el equipo fue adquirido por otra compañía. Después, ayudamos a proponer soluciones para escalar la cadena de bloques. Cuando las soluciones no progresaron, continué buscando otras oportunidades para realizar la idea de una cadena de bloques de alto rendimiento.
Q2: ¿Cuál es la diferencia entre la aplicación y la investigación?
En realidad, la diferencia no es tan grande. Al investigar, consideramos todas las posibilidades para alcanzar objetivos específicos, como construir una Cadena de bloques de alto rendimiento. Pero al construir un sistema en la práctica, debemos elegir la solución más útil y que mejor se ajuste a las necesidades entre muchas buenas ideas. Necesitamos juzgar qué obstaculiza a las personas para alcanzar sus objetivos, aprender de la literatura académica sobre las situaciones posibles y luego seleccionar el contenido más relevante. Esto no es solo interés por el conocimiento, sino crear valor 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 evidente, cada vez que un contrato inteligente se vuelve muy popular, la plataforma no puede soportar el enorme volumen de transacciones, lo que provoca congestión y un aumento de tarifas. Hemos visto una y otra vez que la capacidad de procesamiento de la Cadena de bloques no puede satisfacer las necesidades de los usuarios. Esto se considera un desafío valioso, y no solo mi equipo, sino toda la comunidad académica está abordando este problema de diferentes maneras. Ahora se han desarrollado muchas tecnologías para expandir las capacidades de la Cadena de bloques.
Q4: ¿Cuáles son las diferencias y ventajas entre la red L2 y el establecimiento de una nueva red L1?
L2 es una solución de escalado en un ecosistema, pero puede ser algo complicado para los desarrolladores. Al interactuar L2 con L1, es necesario hacer un puente, el estado en L1 debe reflejarse en L2 y viceversa. L2 también necesita un mecanismo que permita a L1 verificar todo lo que ocurre en él. Este proceso es engorroso, especialmente para activos complejos. Mover activos entre diferentes L2 también es complicado.
Otra forma es usar diferentes cadenas de bloques para diferentes aplicaciones, pero también enfrenta problemas de puente. Los usuarios necesitan realizar puentes de activos con frecuencia al operar entre diferentes aplicaciones, lo que resulta en una mala experiencia.
Nuestra propuesta es establecer una base de datos grande que contenga el estado replicado de todos los nodos verificados. Una vez que se complete la transacción, todos los estados en la misma base de datos estarán disponibles para la siguiente transacción, de modo que los usuarios no necesiten mover constantemente el estado de los activos entre diferentes redes.
Q5: ¿Cuál es la innovación clave de Sui Lutris y cómo logra un alto rendimiento y baja latencia?
Sui Lutris tiene dos conceptos clave: muchas operaciones no requieren consenso, y cuando se necesita consenso, hay un método de alta capacidad de procesamiento. Asegura que los nodos de validación nunca estén en un estado inconsistente al procesar transacciones.
Sui Lutris tiene dos caminos: el camino rápido (sin necesidad de consenso) y el camino de consenso. Utiliza el camino rápido al operar con tus propios objetos, obteniendo la finalización de la transacción sin esperar el consenso. Las transacciones que implican objetos compartidos requieren el camino de consenso.
La ruta rápida tiene una latencia extremadamente baja, de menos de un segundo, y es ampliamente escalable. La ruta de consenso tiene una latencia más alta, generalmente superior a un segundo, con alta capacidad pero menor escalabilidad. La mayoría de las transacciones diarias utilizan la ruta rápida, mientras que las operaciones complejas de DeFi suelen utilizar la ruta de consenso.
Q6: ¿Pueden los desarrolladores diseñar aplicaciones para aprovechar el camino rápido?
Absolutamente. Los desarrolladores de contratos inteligentes pueden controlar si los objetos de operación son exclusivos o compartidos. La clave para la expansión de la aplicación es garantizar que la mayoría de las operaciones se basen en objetos exclusivos para lograr una baja latencia. Aplicaciones como juegos deberían intentar utilizar este método en lugar de depender de estados compartidos y objetos compartidos. Los desarrolladores pueden especificar con precisión cada tipo de transacción y optimizar el diseño cuando sea necesario expandirse.
Q7：¿Cómo funcionan los bloques de transacción programables?
Los bloques de transacciones programables se pueden utilizar en una ruta rápida o en una ruta de consenso. Si solo se involucran objetos exclusivos, se pueden realizar múltiples operaciones en una única operación de cadena, con una baja latencia. Si se incluyen objetos compartidos, se entra en la ruta de consenso, con una latencia un poco más alta. Esto proporciona flexibilidad para diferentes escenarios.
Q8: ¿La actuación de Sui después del lanzamiento de la red principal ha confirmado su teoría de investigación? ¿Hubo algún hallazgo inesperado?
El diseño de Sui ha sido validado, especialmente durante períodos de alto volumen de transacciones. Un día, el volumen de transacciones superó los 60 millones, la mayoría utilizando rutas rápidas, lo que demuestra la escalabilidad y baja latencia de Sui Lutris.
Pero la comunidad también ha encontrado que el camino rápido es algo sutil. A veces, los objetos pueden ser bloqueados erróneamente, aunque generalmente se desbloquean al final de la epoch, pero esta no es una buena experiencia. Se están desarrollando tecnologías que permiten desbloquear rápidamente los objetos bloqueados.
Estas nuevas tecnologías no solo pueden evitar errores, sino que también podrían permitir a los desarrolladores expresar más operaciones a través de vías rápidas, e incluso manejar ciertas situaciones de objetos compartidos. Esto mejorará aún más el rendimiento y la flexibilidad de Sui.
Q9：¿Puede explicar detalladamente las razones que llevan al bloqueo de un objeto?
Cuando un objeto pertenece a un único usuario, Sui depende de que el usuario informe el orden de las operaciones. El sistema verifica si todos ven estas operaciones en el mismo orden. El problema surge cuando el usuario o el software cometen un error, como cuando diferentes dispositivos presentan un orden de operaciones contradictorio. En este caso, Sui no puede determinar el orden correcto y el objeto se bloqueará.
Esta situación es más común de lo esperado, ya que las personas utilizan múltiples dispositivos o realizan múltiples transacciones sobre el mismo objeto al mismo tiempo. Actualmente, los objetos bloqueados solo se desbloquean al final del epoch, lo que puede causar problemas graves.
Sui está desarrollando un nuevo mecanismo que, cuando se bloquea un objeto, resuelve rápidamente los conflictos a través de consenso, en lugar de esperar a que termine la epoch. Esto se completará en unos pocos segundos, mejorando considerablemente la experiencia del usuario.
Q10：¿Cuál es su opinión sobre cómo las cadenas públicas pueden equilibrar la transparencia, la trazabilidad y la privacidad?
Esto depende en gran medida de la aplicación específica. En una plataforma determinada, los desarrolladores de aplicaciones pueden crear contratos por su cuenta para proteger la privacidad del usuario. Algunas aplicaciones pueden no estar tan preocupadas por la privacidad, mientras que algunas aplicaciones financieras pueden necesitar más protección de la privacidad, teniendo en cuenta también las cuestiones regulatorias.
Para ayudar a construir la protección de la privacidad, la plataforma ofrece un soporte nativo de cifrado, 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 en la cadena.
Los desarrolladores de aplicaciones pueden decidir qué tipo de protección de la privacidad necesitan, y combinar estrategias en cadena, fuera de la cadena y de cifrado para abordar los desafíos de la privacidad.
Q11: ¿Hay más soporte nativo para la privacidad?
La comunidad está considerando proporcionar más soporte de contratos inteligentes amigables con la privacidad para los desarrolladores. Además de las pruebas de conocimiento cero, también pueden ser necesarias más funciones matemáticas o criptográficas generales. Damos la bienvenida a los diseñadores de contratos inteligentes a proporcionar comentarios sobre las funciones que faltan.
Otras tecnologías como el cálculo multipartito o el hardware de confianza también se pueden utilizar para proteger la privacidad, pero requieren sistemas adicionales complejos. Si la comunidad tiene una fuerte necesidad, se pueden agregar nuevos métodos de protección de la privacidad a través del proceso de propuestas.
Q12: ¿Cómo cree que se desarrollará Sui en los próximos 6 a 12 meses?
Las mejoras a corto plazo se centrarán en las necesidades de aplicaciones prácticas. A largo plazo, mejoraremos el protocolo Sui Lutris para lograr una menor latencia, un protocolo más simple y aumentar la escalabilidad. También mejoraremos la eficiencia económica, permitiendo que los nodos de validación operen en hardware más restringido y utilizaremos más el hardware existente para la ejecución práctica de transacciones, en lugar de otros gastos de la Cadena de bloques. Estas son las principales direcciones de desarrollo que esperamos ver.