Sui especialista explica em detalhes o design de blockchain de alto desempenho: aplicação inovadora de caminhos rápidos e caminhos de consenso

Recentemente, entrevistámos um especialista em Blockchain para discutir a complexidade e escalabilidade da infraestrutura Sui, bem como como o sistema de processamento de transações Sui contribui para uma rede de alto desempenho. Este especialista é professor na área de segurança e privacidade em uma universidade de renome.

Segue o conteúdo da entrevista:

Q1: Você vem da área acadêmica, pode nos falar sobre o seu foco de pesquisa?

Sou professor de uma universidade, e minha pesquisa foca, de maneira ampla, em segurança e privacidade. No início do século 20, fiz uma quantidade significativa de pesquisa em sistemas ponto a ponto e sistemas anônimos, muitos dos quais eram grandes sistemas distribuídos com foco em armazenamento. Quando toda a Blockchain começou a se concentrar mais na execução, especialmente representada pelo Ethereum, fiquei interessado em livros distribuídos e Blockchain, além de como executar contratos inteligentes. Sua característica sem permissão era algo com o qual eu já estava bastante familiarizado em meu trabalho com sistemas ponto a ponto iniciais. Assim, meu grupo de pesquisa na universidade começou a investigar como construir sistemas de maior desempenho. Fundamos uma empresa para comercializar algumas de nossas ideias, e mais tarde a equipe foi adquirida por uma grande empresa de tecnologia. Então, ajudamos essa empresa a propor soluções para escalar a Blockchain. Mas quando as soluções não avançaram, eu saí e continuei em busca de outras oportunidades para realizar a ideia de uma Blockchain de alto desempenho.

Q2: Você ainda é um professor, então o que você acha que há de diferença entre aplicação e pesquisa?

Na verdade, não há grande diferença. Quando fazemos pesquisa, consideramos todas as possibilidades para alcançar objetivos específicos, como construir um Blockchain de alto desempenho ou funcionalidades específicas. Claro, ao construir um Blockchain ou escolher funcionalidades específicas a serem usadas em um sistema real, devemos optar por uma das possibilidades. Precisamos constantemente fazer julgamentos sobre qual dessas boas ideias é realmente mais útil para as pessoas? Qual é a que as pessoas estão buscando? Quais são os gargalos na adoção do Blockchain? O que impede as pessoas de realizarem o que desejam? Ao construir um sistema, você ainda considerará todas as possibilidades e tentará entender as situações possíveis a partir da literatura acadêmica, e depois escolher o que for mais relevante. Isso não é apenas um interesse pelo conhecimento, mas sim criar valor para os usuários.

Q3: Como determinou quais problemas resolver ao passar da teoria para a aplicação prática?

O principal problema que estou a resolver na minha pesquisa é como expandir as diferentes funcionalidades do Blockchain. Estou focado nos aspectos de sistema do Blockchain, como, por exemplo, como aumentar a capacidade de transações e reduzir a latência. Os problemas nesta área são evidentes, sempre que vemos um contrato em uma plataforma tornar-se muito popular, essa plataforma não consegue suportar um volume tão grande de transações, resultando em congestionamento de transações e aumento exorbitante das taxas. Sempre que o Blockchain tem sucesso, vemos que o volume de transações que ele pode processar ultrapassa a capacidade existente. Portanto, é evidente que o problema reside na falta de capacidade suficiente para atender às necessidades das pessoas em relação ao que desejam fazer nessas Blockchains. Isso não é apenas uma questão de nossa percepção, mas vemos essa situação ocorrer repetidamente. Durante um período, isso foi considerado um desafio valioso, não apenas na minha equipe, mas na verdade em toda a academia que está a investigar o Blockchain, todos tentando resolver este problema de diferentes maneiras. Agora, já há uma quantidade considerável de tecnologias desenvolvidas para expandir a capacidade do Blockchain para enfrentar esses desafios. Mas na época, era bem conhecido que muitas pessoas tentavam resolvê-lo de diferentes maneiras.

Q4: A rede L2 é uma forma proposta pelas pessoas para resolver o problema de escalabilidade. Quais são as diferenças e vantagens em relação à criação de uma nova rede L1, como a Sui?

L2 é uma solução de escalabilidade em um determinado ecossistema. No entanto, para os desenvolvedores de aplicativos, usar uma rede L2 pode ser um pouco complicado. Quando uma rede L2 tenta interagir com L1, é necessária uma atividade de ponte, embora isso seja verdade para qualquer relação L2/L1. O estado que representa moedas, ativos ou outras coisas em L1 deve ser espelhado em L2, e vice-versa. Além disso, L2 deve ter algum mecanismo para que L1 possa verificar tudo o que acontece nela. Mas isso é apenas a primeira parte, ou seja, qualquer ativo que exista em L1 precisa ser transferido para L2, algumas atividades devem ocorrer em L2, e então, de alguma forma, os ativos devem ser devolvidos a L1. Isso é bem complicado.

Para ativos fungíveis como tokens, essa atividade de ponte é relativamente tranquila, pois as pessoas possuem duas contas e um middleware de ponte. No entanto, para ativos mais gerais, o efeito não é tão bom. Para realmente usar a rede L2 para desenvolver aplicações mais complexas do que tokens na L1, você precisa ter contratos inteligentes em ambos os lados, um para mintar e outro para queimar. Eles devem transitar entre dois ecossistemas diferentes, o que é uma atividade personalizada para cada contrato. Você não pode simplesmente dizer que vai criar uma rede L2, levar todos os ativos e operar conforme sua vontade, e depois trazê-los de volta; não existe esse conceito. É um processo manual, muito propenso a erros. Portanto, não é uma boa experiência. Imagine que você possui ativos em várias redes L2 diferentes e que possui esses contratos inteligentes personalizados em diferentes redes L2. Cada vez que você quiser operar em um estado localizado em outra rede L2, você deve fazer a ponte de volta para a L1 e depois voltar para a L2. Você não pode simplesmente dizer: 'Acabei de fazer algo nesta blockchain e agora quero fazer outra coisa em outra blockchain, não preciso me preocupar em qual L1 ou L2 está.' Tudo está aqui, eu tenho na mão agora e estou pronto para fazer mais transações em qualquer estado que eu queira acessar. É por isso que a experiência de ter estados dispersos em redes L2 é ruim. Mover ativos entre diferentes cadeias é muito complicado e evidente para os usuários. É por isso que as redes L2 nunca despertaram realmente meu interesse.

Outro exemplo é um projeto conhecido, que possui um ecossistema muito interessante, adotando uma abordagem diferente, que é escalar usando diferentes Blockchains para diferentes apps. Podemos ter diferentes velocidades de transação em diferentes cadeias, e quando é necessário operar entre diferentes apps, é possível fazer a ponte de ativos entre as cadeias, mas também enfrenta o mesmo problema. Sempre que você quiser usar diferentes apps, primeiro precisa realizar a operação de ponte, o que é sutil e óbvio para o usuário, e então você pode usar esse app e voltar a fazer a ponte. Você perceberá que gasta mais tempo transferindo ativos de uma cadeia para outra do que fazendo o que realmente deseja.

Na Sui, a nossa solução é construir uma grande base de dados, que na verdade contém todos os estados replicados pelos nós verificados. Assim que você concluir uma transação, todos os estados na mesma base de dados podem ser usados para realizar a próxima transação, e os usuários não precisam mover constantemente o estado dos ativos entre L1 e L2.

Q5: Sui Lutris é a base do protocolo Sui, qual é a sua inovação chave que permite ao Sui ter características de alta capacidade de processamento e baixa latência?

Sui Lutris é composto por duas ideias fundamentais: (1) para muitas operações na blockchain, na verdade não é necessário alcançar consenso; (2) quando realmente é necessário alcançar consenso, existe um método de muito alta taxa de transferência que combina essas duas abordagens. Sui Lutris é o núcleo do sistema distribuído Sui, garantindo que, ao realizar transações em uma rede distribuída, dois nós de validação diferentes que seguem o protocolo nunca estejam em estado de inconsistência. Assim, não haverá situação em que um nó de validação pense que você gastou um coin e o enviou para Alice, enquanto outro nó de validação acredita que o mesmo coin foi enviado para Bob.

Dois caminhos diferentes, um que não requer consenso (caminho rápido) e outro que requer consenso (caminho de consenso). Quando o objeto que você deseja operar pertence apenas a você, como seu próprio personagem NFT e o chapéu que você deseja combinar para que seu personagem possa usar o chapéu, teoricamente, outras pessoas não devem operar sobre eles. Nesses casos, Sui utilizou o caminho rápido, o que significa que você pode operar seus próprios objetos, pode obter a finalização da transação sem esperar pelo consenso, garantindo que a transação ocorra e que o chapéu esteja na cabeça do seu NFT.

Mas em certas situações, as transações não envolvem apenas objetos que pertencem a você, mas são compartilhados por muitas pessoas. Por exemplo, se houver um leilão para vender pequenos chapéus, esse tipo de leilão é representado como um objeto compartilhado no Sui. As pessoas podem fazer lances, e quem der o maior lance ganha o chapéu. Este leilão é um objeto que não pertence a uma única entidade, e todos devem ser capazes de fazer lances, compartilhar e atualizar o estado sobre o último lance, e esse tipo de operação requer um consenso adicional. O Sui Lutris permite que você tenha objetos compartilhados e execute transações sobre eles, permitindo que você possua outros objetos, altere o estado de objetos compartilhados ou crie novos objetos compartilhados. Ele permite que dois caminhos coexistam e a interação entre objetos exclusivos possuídos por indivíduos específicos ou objetos compartilhados por várias pessoas.

Estas duas rotas diferentes têm vantagens diferentes. O caminho rápido para objetos exclusivos tem uma latência muito baixa, levando menos de um segundo, sendo muito rápido e podendo ser amplamente escalado. A latência do caminho de consenso é mais alta, geralmente superior a um segundo, com uma capacidade também bastante alta, mas, em comparação com o primeiro caminho, é mais difícil de escalar. No Sui, aqueles que realmente impulsionam os apps na blockchain com milhões de transações diárias normalmente utilizam o primeiro caminho e, em grande parte, estruturam seus apps para realizar a maioria das transações principalmente em objetos exclusivos, em vez de transações compartilhadas. Por outro lado, protocolos que realizam trabalhos complexos (como DeFi) geralmente adotam o segundo tipo de transação, pois precisam combinar as ofertas ou liquidez de muitas pessoas diferentes para executar operações.

Q6: Os desenvolvedores de apps na Sui podem projetar seus apps para aproveitar o caminho rápido?

Sim, absolutamente. Eu acho que isso é o trabalho central dos designers de apps de extensão. Os desenvolvedores de contratos inteligentes podem controlar completamente se os objetos que manuseiam em seus contratos são objetos exclusivos de uma única entidade ou objetos compartilhados em qualquer momento específico. Um truque para expandir apps em Sui é garantir que a maioria das operações seja realizada basicamente em objetos exclusivos, pois o Sui pode gerenciar muitas das operações que você deseja com uma latência muito baixa, proporcionando uma ótima experiência. As operações necessárias para jogos devem ser realizadas nesta categoria, pois a latência delas é muito baixa em comparação com as operações que precisam ser mediadas através de estados compartilhados e objetos compartilhados. Assim que clicado, a transação pode ser concluída imediatamente na rede.

Os designers de contratos inteligentes têm controle total sobre isso, podendo basicamente especificar com precisão quais são as transações em cada categoria. Claro que a primeira versão do contrato pode considerar tudo como um estado compartilhado, e tudo será feito através de um caminho de consenso com maior latência, mas à medida que a necessidade de escalabilidade aumenta, os desenvolvedores precisam considerar até que ponto podem fazer isso sem essas partes.

Q7: Como é que os blocos de transação programáveis desempenham um papel aqui?

Os blocos de transação programáveis podem atuar na via rápida ou na via de consenso. Se um bloco de transação programável envolver apenas seus objetos exclusivos, isso significa que você pode executar várias operações em uma única operação na cadeia. Por exemplo, suponha que você seja um aplicativo CEX, onde muitas pessoas compram e vendem diferentes moedas; você pode realizar uma transação na cadeia que corresponde, conceitualmente, ao que as pessoas estão comprando e vendendo. Mas como você é a exchange, todas pertencem a você, portanto, é possível liquidar mil transações ao mesmo tempo, o que é a via rápida. Por outro lado, se alguns objetos dentro do bloco de transação programável forem compartilhados, entramos na via de consenso, onde o atraso será um pouco maior; não será menos de um segundo, mas sim alguns segundos.

Q8: A mainnet está online há mais de 100 dias, o desempenho do Sui confirmou suas teorias de pesquisa? Há algo que o surpreendeu?

Há algumas coisas que confirmam o design do Sui, mas também há algumas questões que provocam reflexão. Uma delas é que, em momentos de volume de transações especialmente alto, mesmo em um momento específico, o volume diário de transações ultrapassa 60 milhões, sendo que a maior parte das transações ocorre através de um caminho rápido. O Sui Lutris é muito escalável e possui uma latência muito baixa. Antes disso, não estava claro se alguém usaria esse caminho, mas quando há necessidade de um grande volume de transações e baixa latência, ele foi utilizado, e de forma muito eficaz! É fácil ver que é esse o método. Naqueles dias, o volume de transações do Sui ultrapassou