Fundador da Sui analisa a arquitetura de blockchain de alto desempenho: as vantagens do caminho rápido e do caminho de consenso

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

Segue o conteúdo desta entrevista:

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

Sou professor em uma universidade renomada, e minha pesquisa se concentra, de forma ampla, em segurança e privacidade. No início do século 20, realizei uma quantidade considerável de pesquisas em sistemas ponto a ponto e sistemas anônimos, muitos dos quais eram sistemas distribuídos de grande escala com foco em armazenamento. Quando toda a Blockchain começou a se concentrar mais na execução, especialmente representada pelo Ethereum, desenvolvi interesse por livros-razão distribuídos e Blockchain, bem como na execução de contratos inteligentes. Estava muito familiarizado com a característica de permissão irrestrita desde meu trabalho em sistemas ponto a ponto iniciais. Assim, meu grupo de pesquisa na universidade começou a explorar como construir sistemas de maior desempenho. Fundamos uma empresa para comercializar algumas de nossas ideias, que mais tarde foi adquirida por uma grande empresa de tecnologia. Em seguida, ajudamos essa empresa a propor soluções para escalar a Blockchain. Mas quando a proposta não avançou, deixei a empresa, em busca de outras oportunidades para realizar a ideia de uma Blockchain de alto desempenho.

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

Na verdade, não há muita diferença. Quando estamos fazendo pesquisas, consideramos todas as possibilidades para alcançar objetivos específicos, como construir um Blockchain de alto desempenho ou uma funcionalidade específica. Claro, ao construir um Blockchain ou ao escolher quais funcionalidades específicas usar em um sistema real, temos que escolher 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 está impedindo as pessoas de realizar o que desejam? Ao construir um sistema, você ainda considera todas as possibilidades e tenta entender as situações possíveis a partir da literatura acadêmica, para então escolher as mais relevantes. Isso não é apenas 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 pesquisa é como expandir as diferentes funcionalidades do Blockchain. Estou focado nos aspectos sistémicos 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 determinado contrato no Ethereum a tornar-se muito popular, a plataforma Ethereum não consegue suportar um volume tão elevado 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 consegue processar ultrapassa a capacidade existente. Portanto, é claro que o problema reside na falta de capacidade suficiente para satisfazer o que as pessoas querem fazer nesses Blockchains. Não é apenas uma questão da nossa ideia, temos visto essa situação acontecer repetidamente. Durante um certo período, isso foi considerado um desafio valioso, não apenas na minha equipa, mas na verdade em toda a comunidade académica, todos a investigar o Blockchain, tentando resolver esse problema de diferentes maneiras. Agora, já foram desenvolvidas várias tecnologias para expandir a capacidade do Blockchain e enfrentar esses desafios. Mas na altura, era bem conhecido que muitas pessoas estavam a tentar resolvê-lo de diferentes formas.

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

L2 é uma solução de escalabilidade no ecossistema Ethereum. No entanto, para os desenvolvedores de aplicações, usar a rede L2 pode ser um pouco complicado. Quando uma rede L2 tenta interagir com o Ethereum, é necessário realizar atividades de ponte, o que é verdade para qualquer relação L2/L1. O estado que representa moedas, ativos ou outros conteúdos no L1 deve ser espelhado no L2, e vice-versa. Além disso, a L2 deve ter algum mecanismo para que o L1 possa validar tudo o que acontece nela. Mas isso é apenas a primeira parte, ou seja, qualquer ativo existente no L1 precisa ser transferido para a L2, deve haver alguma atividade na L2 e, em seguida, os ativos precisam ser retornados ao L1 de alguma forma. Isso é bastante complicado.

Para ativos fungíveis como tokens, essa atividade de ponte tem sido relativamente tranquila, pois as pessoas possuem duas contas e um middleware de ponte. No entanto, para ativos mais gerais, os resultados não são bons. Para usar realmente redes L2 no Ethereum para desenvolver aplicações mais complexas do que tokens, você precisa de contratos inteligentes em ambos os lados, um para cunhagem e outro para destruição. Eles devem transitar entre dois ecossistemas diferentes, o que é uma atividade personalizada para cada contrato. Não se pode simplesmente dizer: eu vou criar uma rede L2, então vou levar todos os ativos e operar como eu quiser, 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ê tem ativos em várias redes L2 diferentes, e que existem esses contratos inteligentes personalizados em diferentes redes L2. Cada vez que você quiser operar em um estado que está localizado em outra rede L2, você deve fazer a ponte de volta para L1 e depois voltar para L2. Você não pode simplesmente dizer: eu acabei de fazer algo nesta blockchain, e agora eu quero fazer outra coisa em outra blockchain, sem me preocupar em qual L1 ou L2 está. Tudo está aqui, eu tenho isso em mãos, 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 realmente despertaram meu interesse.

Outro exemplo é o Cosmos, que possui um ecossistema muito interessante e adota uma abordagem diferente, expandindo através do uso de diferentes blocos para diferentes apps. Podemos realizar transações com diferentes velocidades em diferentes cadeias, e quando é necessário operar entre diferentes apps, podemos fazer a ponte de ativos entre as cadeias, mas isso também enfrenta os mesmos problemas. Sempre que você quiser usar diferentes apps, primeiro precisa realizar a operação de ponte, o que é sutil e evidente 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 um bloco para outro do que fazendo o que realmente deseja.

No Sui, a nossa proposta é estabelecer 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 poderão ser utilizados para realizar a próxima transação, e os usuários não precisarão estar constantemente a mover o estado dos ativos entre o L1 e o L2.

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

Sui Lutris é composto por duas ideias-chave: (1) para muitas operações na blockchain, na verdade, não é necessário obter consenso; (2) quando você realmente precisa de consenso, existe um método de muito alta taxa de transferência que combina esses dois métodos. 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 um estado inconsistente. Assim, não haverá uma 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 realmente 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 deveriam operar sobre eles. Nesses casos, o Sui utiliza o caminho rápido, que indica que você pode operar seus próprios objetos, podendo 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 a que oferecer o maior lance ganha o chapéu. Esse leilão é um objeto que não pertence a uma entidade única, todos devem ser capazes de fazer lances, compartilhar e atualizar o estado sobre o último lance, e esse tipo de operação requer consenso adicional. O Sui Lutris permite que você possua objetos compartilhados e execute transações sobre eles, permitindo que você possua outros objetos, altere o estado dos objetos compartilhados ou crie novos objetos compartilhados. Ele permite a coexistência de dois caminhos e a interação entre objetos exclusivos pertencentes a indivíduos específicos e objetos compartilhados pertencentes a várias pessoas.

Esses dois caminhos diferentes têm vantagens distintas. O caminho rápido de objetos exclusivos tem uma latência muito baixa, levando menos de um segundo, é muito rápido e pode ser amplamente escalado. A latência do caminho de consenso é mais alta, geralmente superior a um segundo, e a capacidade também é bastante alta, mas, em comparação com o primeiro caminho, é mais difícil de escalar. No Sui, aqueles que realmente impulsionam aplicativos on-chain com milhões de transações diárias geralmente utilizam o primeiro caminho e, em grande medida, estruturam seus aplicativos para realizar a maioria das transações em objetos exclusivos, em vez de transações compartilhadas. Por outro lado, protocolos que realizam trabalhos complexos (como DeFi) normalmente implementam 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 de um designer de apps de extensão. Os desenvolvedores de contratos inteligentes podem controlar totalmente se os objetos que manipulam no contrato são objetos de propriedade exclusiva de uma única entidade ou objetos compartilhados em qualquer momento específico. Uma dica para expandir apps em Sui é garantir que a maioria das operações sejam realizadas basicamente em objetos de propriedade exclusiva, já que Sui pode gerenciar muitas operações que você deseja com uma latência muito baixa, o que proporciona uma ótima experiência. As operações necessárias para jogos devem ser realizadas nessa categoria, pois têm uma latência muito baixa em comparação com aquelas que precisam ser mediadas por estados compartilhados e objetos compartilhados. Uma vez clicado, a transação pode ser concluída instantaneamente na rede.

Os designers de contratos inteligentes têm controle total sobre isso, podendo basicamente especificar com precisão quais transações pertencem a cada categoria. Claro, a primeira versão do contrato pode considerar tudo como um estado compartilhado, e tudo passará por um caminho de consenso com maior latência, mas à medida que há a necessidade de escalar, os desenvolvedores precisam considerar até que ponto podem fazê-lo sem essas partes.

Q7: Como é que os blocos de negociaçã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ê é um aplicativo de plataforma de negociação, onde muitas pessoas compram e vendem diferentes coins. Você pode realizar uma transação na cadeia, que conceitualmente corresponde ao que as pessoas compram e vendem. Mas como você é a exchange, todos pertencem a você, portanto, é possível liquidar simultaneamente mil transações, que é a via rápida. Por outro lado, se alguns objetos dentro do bloco de transação programável forem compartilhados, então entraremos na via de consenso, onde o atraso será um pouco maior, não sendo menos de um segundo, mas sim alguns segundos.

Q8: A mainnet está ativa há mais de 100 dias, a performance do Sui confirmou suas teorias de pesquisa? Houve algo que o surpreendeu?

Há várias coisas que confirmam o design do Sui, mas também há algumas que levam à reflexão. Uma delas é que, em momentos de volume de transações especialmente alto, até mesmo em um momento específico, o volume diário de transações pode ultrapassar 60 milhões, sendo que a maior parte das transações se encontra na via rápida. O Sui Lutris é muito escalável e tem uma latência muito baixa. Antes disso, não estava claro se alguém usaria esse caminho, mas quando há necessidade de muitas 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 superou todos os outros.