Diálogo aprofundado com o cientista-chefe do Mysten Labs: Da teoria à prática, como Sui resolve o problema de escalabilidade da rede?

Recentemente, entrevistamos George Danezis para discutir a complexidade e a escalabilidade da infraestrutura da Sui e como o sistema de processamento de transações da Sui permite uma rede de alto desempenho. George Danezis é cofundador e cientista-chefe do Mysten Labs (e colaborador original de Sui) e professor na área de engenharia de segurança e privacidade na UCL.

A seguir está o conteúdo desta entrevista:

**Q1: Você é da área acadêmica, pode apresentar seu foco de pesquisa? **

Sou professor na University College London (UCL) e minha pesquisa se concentra em segurança e privacidade em sentido amplo. No início do século 20, fiz muitas pesquisas sobre sistemas peer-to-peer e anônimos, muitos dos quais eram sistemas grandes e distribuídos com foco em armazenamento. À medida que todo o blockchain se tornou mais orientado para a execução, especialmente representado pelo Ethereum, fiquei interessado em livros-razão distribuídos e blockchains e em como executar contratos inteligentes. A natureza sem permissão disso é familiar para mim devido ao meu trabalho nos primeiros sistemas ponto a ponto. Assim, meu grupo de pesquisa na UCL decidiu descobrir como construir sistemas de maior desempenho. Iniciamos o Chainspace para comercializar algumas de nossas ideias, e a equipe foi adquirida pelo Facebook. Em seguida, ajudamos o Facebook a encontrar uma solução para dimensionar o blockchain Libra/Diem. Mas quando a proposta não avançou, saí e continuei buscando outras oportunidades para implementar o conceito de blockchain de alto desempenho.

**Q2: Você ainda é professor, então qual você acha que é a diferença entre aplicação e pesquisa? **

Realmente não há muita diferença. Quando conduzimos pesquisas, consideramos todas as possibilidades para atingir um objetivo específico, como construir uma blockchain de alto desempenho ou uma função específica. Claro que ao construir uma blockchain ou escolher uma função específica para usar em um sistema real, temos que escolher uma dessas possibilidades. Temos que fazer julgamentos constantemente. De todas essas boas ideias, quais são realmente as mais úteis para as pessoas? Qual é o que as pessoas procuram? Quais são os gargalos na adoção do blockchain? O que impede as pessoas de alcançarem o que desejam? Ao construir um sistema, você ainda considera todas as possibilidades e tenta entender o que é possível a partir da literatura acadêmica e depois escolhe o que é mais relevante. Não se trata apenas de interesse intelectual, mas de criação de valor para os usuários.

**Q3: Ao passar da teoria à aplicação prática, como você determina quais problemas resolver? **

O principal problema que abordo em minha pesquisa é como dimensionar as diferentes funções do blockchain. Eu me concentro nos aspectos do sistema do blockchain, ou seja, como aumentar o rendimento das transações e reduzir a latência. O problema a este respeito é óbvio: sempre que vemos um determinado contrato no Ethereum se tornar muito popular, a plataforma Ethereum não consegue suportar um volume de transações tão grande, ocorre congestionamento de transações e as taxas disparam. Cada vez que um blockchain alcançou sucesso, vimos ele lidar com mais transações do que atualmente. Então, claramente, o problema é que não há capacidade suficiente para o que as pessoas querem fazer nessas blockchains. Não está apenas em nossas mentes, já vimos isso acontecer repetidas vezes. Por um tempo, isso foi reconhecido como um desafio digno, não só no meu grupo, mas na verdade toda a comunidade acadêmica estava trabalhando no blockchain, todos estavam resolvendo esse problema de maneiras diferentes. Agora, algumas tecnologias foram desenvolvidas para ampliar as capacidades do blockchain para enfrentar esses desafios. Mas na época, como todos sabemos, muitas pessoas abordaram o assunto de maneiras diferentes.

**Q4: A rede L2 é uma forma proposta pelas pessoas para resolver o problema de escala. Qual é a diferença e o benefício de construir uma nova rede L1 como a Sui? **

L2 é uma solução para escalar no ecossistema Ethereum. Mas para desenvolvedores de aplicativos, trabalhar com redes L2 é um pouco complicado. Quando uma rede L2 tenta interagir com Ethereum, a atividade de ponte deve ocorrer, embora isso seja verdade para qualquer relacionamento L2/L1. O estado que representa uma moeda, ativo ou outro conteúdo em L1 deve ser espelhado em L2 e vice-versa. Além disso, L2 deve possuir algum mecanismo para que L1 possa verificar tudo o que acontece nela. Mas isso é apenas a primeira parte, qualquer ativo que exista em L1 precisa ser transferido para L2, alguma atividade tem que acontecer em L2 e então, de alguma forma, transferir o ativo de volta para L1. Isso é muito problemático.

Para ativos fungíveis, como tokens, essa atividade de ponte é relativamente tranquila, porque as pessoas têm duas contas e um middleware de ponte. Mas para ativos mais gerais, não funciona tão bem. Para realmente usar a rede L2 no Ethereum para desenvolver aplicações mais complexas do que tokens, você precisa ter contratos inteligentes em ambos os lados, um para cunhagem (mint) e outro para queima (burn). Eles precisam viajar entre dois ecossistemas diferentes, o que é uma atividade personalizada para cada contrato. Você não pode simplesmente dizer, vou criar uma rede L2 e tirar todos os ativos e fazer o que eu quiser e trazê-los de volta, não existe esse conceito. Este é um processo manual e muito sujeito a erros. Portanto, não é uma ótima experiência. Imagine que você tenha ativos em várias redes L2 diferentes e esses contratos inteligentes personalizados em diferentes redes L2. Toda vez que você quiser operar em algum estado que esteja em outra rede L2, será necessário fazer uma ponte de volta para L1 e depois de volta para L2. Você não pode dizer facilmente: acabei de fazer algo neste blockchain e depois farei outra coisa em outro blockchain, e não preciso pensar em qual L1 ou L2 está. Está tudo aqui e estou com tudo em mãos agora, pronto para fazer mais transações em qualquer estado que eu queira visitar. É por isso que espalhar o estado por uma rede L2 é uma experiência ruim. Mover ativos entre cadeias diferentes é complicado e óbvio para os usuários. É por isso que a rede L2 nunca despertou meu interesse.

Outro exemplo é o Cosmos, que possui um ecossistema muito interessante que adota outra abordagem de escalonamento usando diferentes blockchains para diferentes aplicativos. Podemos ter velocidades de transação diferentes em cadeias diferentes e conectar ativos entre cadeias quando precisamos operar entre aplicativos diferentes, mas isso também enfrenta o mesmo problema. Cada vez que você quiser usar um aplicativo diferente, primeiro você precisa fazer uma operação de ponte, que é sutil e óbvia para o usuário, e então você pode usar esse aplicativo e fazer a ponte de volta. Você acabará gastando mais tempo transferindo ativos de uma rede para outra do que fazendo o que realmente deseja.

No Sui, nossa solução é construir um grande banco de dados que, de fato, contenha todos os estados replicados pelos validadores. Depois de concluir uma transação, todo o estado no mesmo banco de dados pode ser usado para fazer a próxima transação sem que os usuários tenham que mover constantemente os estados dos ativos entre L1 e L2.

**Q5: Sui Lutris é a base do protocolo Sui. Quais são as principais inovações que permitem ao Sui ter alto rendimento e baixa latência? **

Sui Lutris consiste em duas ideias principais: (1) para muitas operações no blockchain, o consenso não é realmente necessário; (2) quando você precisa de consenso, existe um método de alto rendimento que combinará esses dois métodos. Sui Lutris é o núcleo do sistema distribuído da Sui, garantindo que dois nós de verificação diferentes seguindo o protocolo nunca estarão em um estado inconsistente ao conduzir transações na rede distribuída. Não há situação em que um validador pense que você gastou uma moeda e a enviou para Alice, enquanto outro validador pensa que a mesma moeda foi realmente enviada para Bob.

🌟 Auto-lontra:

Dois caminhos diferentes, um que não requer consenso (caminho rápido) e outro que requer consenso (caminho do consenso). Quando o objeto que você deseja manipular 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 ninguém mais deveria ser capaz de manipulá-los. Nesses casos, Sui usa o caminho rápido, o que significa que você pode manipular seus próprios objetos, obter a finalidade da transação sem esperar pelo consenso, a transação tem garantia de acontecer e o chapéu está na sua cabeça do NFT.

Mas em alguns casos, as transações não envolvem apenas objetos que pertencem a você, elas são compartilhadas por muitas pessoas. Por exemplo, se houver um leilão que venda chapéus pequenos, este tipo de leilão seria representado em Sui como um objeto compartilhado. As pessoas podem dar lances e quem fizer o lance mais alto ganha o chapéu. Esse tipo de leilão é um objeto que não pertence a uma única entidade. Todos devem poder licitar, compartilhar e atualizar o estado sobre a última licitação. Esses tipos de operações exigem consenso adicional. Sui Lutris permite que você possua objetos compartilhados e execute transações neles, permitindo que você possua outros objetos, altere o estado de objetos compartilhados ou crie novos objetos compartilhados. Ele permite que ambos os caminhos coexistam e interajam entre objetos exclusivos pertencentes a um determinado indivíduo ou objetos compartilhados por várias pessoas.

Esses dois caminhos diferentes têm vantagens diferentes. O atalho para objetos exclusivos tem latência extremamente baixa, leva menos de um segundo, é muito rápido e pode ser amplamente dimensionado. O caminho de consenso tem uma latência mais alta, geralmente superior a um segundo, e uma capacidade bastante alta; no entanto, é mais difícil de escalar do que o primeiro caminho. No Sui, aqueles que realmente conduzem aplicativos on-chain com milhões de transações por dia geralmente usam o primeiro caminho e estruturam seus aplicativos em grande parte para ter o maior número de transações principalmente em objetos exclusivos, embora não seja um acordo de compartilhamento. Por outro lado, protocolos que realizam trabalhos complexos (como DeFi) muitas vezes praticam o segundo tipo de transação, porque devem combinar ofertas ou liquidez de muitas pessoas diferentes para realizar operações.

**Q6: Os desenvolvedores de aplicativos no Sui podem projetar seus aplicativos para aproveitar as vantagens do caminho rápido? **

Sim absolutamente. Acho que este é o trabalho principal de um designer de aplicativos de extensão. Os desenvolvedores de contratos inteligentes têm controle total sobre se os objetos que manipulam dentro do contrato são objetos exclusivos ou compartilhados de uma única entidade em um determinado momento. Um dos truques para escalar seu aplicativo no Sui é garantir que a maioria das operações sejam basicamente em objetos exclusivos, porque o Sui pode gerenciar quantas operações você quiser com latência muito baixa, o que é uma experiência interessante. As operações necessárias para o jogo devem ser realizadas nesta categoria, e sua latência é muito baixa se comparada às operações que precisam ser mediadas por meio de estado compartilhado e objetos compartilhados. Uma vez clicada, a transação pode ser concluída instantaneamente na rede.

O designer do contrato inteligente tem controle total sobre isso e pode basicamente especificar exatamente quais são as transações em cada categoria. Claro, a primeira versão do contrato pode tratar tudo como um estado compartilhado, e tudo passará pelo caminho de consenso de maior latência, mas como a necessidade de escalar, os desenvolvedores precisam considerar até que ponto eles podem fazer isso. Essas partes são necessárias. .

**Q7: Como o bloco de transação programável desempenha um papel nisso? **

Os blocos de transação programáveis podem funcionar tanto no caminho rápido quanto no caminho de consenso. Se um bloco de transações programáveis envolver apenas o seu objeto exclusivo, isso significa que você pode realizar várias operações em uma operação on-chain. Por exemplo, suponha que você seja um aplicativo CEX onde muitas pessoas compram e vendem moedas diferentes. Você pode realizar uma transação na cadeia, que corresponde conceitualmente ao que as pessoas estão comprando e vendendo. Mas como você é uma exchange, todas elas pertencem a você, então mil transações podem ser liquidadas ao mesmo tempo, o que é o caminho mais rápido. Por outro lado, se alguns objetos no bloco de transação programável forem compartilhados, o caminho de consenso será inserido e a latência será um pouco maior, não menos que um segundo, mas vários segundos.

**Q8: A rede principal está online há mais de 100 dias. O desempenho de Sui confirmou sua hipotética teoria de pesquisa? Há algo que te surpreendeu? **

Existem algumas coisas que confirmam o design de Sui, mas também há coisas que dão o que pensar. Uma delas é que quando o volume de transações é particularmente grande, mesmo em um momento especial, o volume diário de transações ultrapassa até 60 milhões, a maioria dos quais estão no caminho rápido. Sui Lutris é muito escalável e tem latência muito baixa. Até então, não está claro se alguém usará esse caminho, mas quando são necessários altos volumes de transações e baixa latência, ele é usado e funciona muito bem! É fácil ver, esse é o método. Naquela época, Sui tinha mais transações do que todas as outras blockchains juntas. Esta é uma validação interessante de que o design de Sui é sólido.

Enquanto isso, a comunidade Sui achou esse caminho rápido um pouco complicado. Como os proprietários de objetos precisam gerenciar até certo ponto a ordem das operações em seus próprios objetos, às vezes as coisas podem dar errado. Às vezes, eles podem até usar uma biblioteca que não os ajuda, e a própria biblioteca apresenta erros, então às vezes os objetos ficam bloqueados. Geralmente eles são desbloqueados no final do dia, no final de uma época, mas isso não é uma ótima experiência. As pessoas que concebem contratos inteligentes podem ficar intimidadas com isto, temendo que possam ocorrer erros, o que os impede de tirar o máximo partido das facilidades de baixa latência e escalabilidade. Uma série de tecnologias estão sendo desenvolvidas para permitir que aqueles que bloquearam objetos por engano os desbloqueiem rapidamente em segundos. Portanto, se você tentar usar o caminho rápido, ocorrer um erro e seu objeto for bloqueado, você poderá usar imediatamente o caminho de consenso para desbloqueá-lo, sem esperar até que uma época termine.

E, curiosamente, não se trata apenas de evitar bugs, permite que os desenvolvedores expressem rapidamente muito mais coisas, existem técnicas potenciais em que alguns objetos não pertencem a apenas uma parte. Talvez haja um objeto que você e eu possuímos em conjunto, porque é compartilhado, e geralmente as transações nesse objeto precisam passar pelo caminho do consenso. No entanto, se Sui tivesse uma maneira de desbloquear objetos rapidamente, os desenvolvedores poderiam realmente tentar acelerar as transações. No caso de você e eu estarmos transacionando no mesmo objeto exatamente ao mesmo tempo, o sistema será bloqueado, incapaz de decidir qual transação acontecerá a seguir, e então Sui poderá desbloqueá-la e passar pelo caminho do consenso, tornando-o compartilhado e resolvendo-o. Mas isso não pode acontecer a menos que as pessoas tentem competir deliberadamente. Uma vez que Sui tenha a funcionalidade para permitir o desbloqueio de objetos, ele deverá ser capaz de acessar objetos pertencentes a várias pessoas. É um jogo que tenta passar o máximo de volume de transações possível pelo caminho rápido, que é um tipo de coisa que está sendo desenvolvida para ajudar a comunidade de construtores.

**Q9: Você pode compartilhar com mais detalhes o que está causando o bloqueio de objetos no momento? **

A razão pela qual não é necessário passar por consenso para dizer a Sui a sequência de operações que devem acontecer quando um objeto é seu é porque ninguém mais pode operar em seu objeto. Sui depende de você dizer ao sistema que a ação A acontecerá primeiro, a ação B acontecerá a seguir e a ação C acontecerá por último. O sistema ainda precisa verificar se os ABCs são vistos por todos na mesma ordem. O sistema é implementado através de um protocolo distribuído que apenas verifica se todos vimos o ABC por sua vez. A questão é: se você cometer um erro ou se seu software cometer um erro. Por exemplo, se o seu telefone controla o seu ativo e o seu computador controla o seu ativo, o seu telefone diz que A aconteceu primeiro e o seu computador diz que B aconteceu primeiro. Você está classificando duas coisas diferentes incorretamente. Isto é uma contradição. Nesse caso, Sui diria: "Bem, a pessoa que contratei para me contar a sequência parece ter me dado duas coisas contraditórias, então não sei o que fazer. Não sei como consertar isso." Porque Sui Esse problema geralmente é resolvido pelo caminho do consenso. Mas aqui você está tentando usar o caminho mais rápido. Então Sui levantou a mão e disse: “Ok, há um erro aqui”.

A suposição inicial era que isso não aconteceria com muita frequência, mas acontece que acontece com bastante frequência quando as pessoas usam dispositivos diferentes ou tentam fazer múltiplas transações para o mesmo objeto ao mesmo tempo. Atualmente, quando esses objetos são bloqueados, Sui espera até o final de uma época para desbloqueá-los, o que é muito preocupante. Imagine se seus ativos ficassem inutilizáveis por um dia, isso poderia na verdade ser um problema sério.

Então agora Sui precisa evoluir para tomar a ação correta quando algo estiver bloqueado. Se a entidade encarregada de fornecer a ordem correta der uma ordem ambígua, Sui resolverá toda a situação por consenso. Isso acontecerá em segundos, não no final de uma época.

**Q10: Grande parte da sua pesquisa gira em torno da privacidade. O que você acha sobre como os blockchains públicos podem equilibrar melhor transparência, rastreabilidade e privacidade? **

Na cadeia pública, como equilibrar transparência, rastreabilidade e privacidade é uma questão muito relacionada com a aplicação, e o meu ponto de vista sobre privacidade é que o que precisa de ser mantido privado depende em grande parte da própria aplicação. Por exemplo, no Sui, faz sentido que os desenvolvedores de aplicativos desenvolvam contratos que protejam a privacidade de seus usuários. Como algumas pessoas querem apenas desenvolver jogos, talvez as preocupações com a privacidade não sejam uma grande preocupação. Algumas pessoas desejam realizar transações financeiras no blockchain, e a privacidade pode ser uma preocupação maior, mas, ao mesmo tempo, há outros tipos de questões regulatórias envolvidas. Portanto, a atitude de Sui é que iremos fornecer a você uma boa plataforma, e você precisa construir privacidade nesta plataforma.

Para ajudar as pessoas a construir privacidade, Sui fornece suporte cripto-nativo que pode ser útil para elas ao projetar contratos inteligentes. Uma das mais importantes é a capacidade de verificar provas de conhecimento zero em Sui. Existe uma função nativa que verifica um dos esquemas mais utilizados e compreendidos, o esquema Groth16 desenvolvido pelo meu colega Jens Groth. Isso significa que, na verdade, os designers de aplicativos podem verificar certos eventos fora da cadeia sem revelar quais são esses eventos. Este é o alicerce fundamental para a construção de toda uma classe de aplicativos amigáveis à privacidade que mantêm algum estado fora da cadeia, mas na cadeia, você pode verificar se tudo o que acontece fora da cadeia está correto.

Os desenvolvedores de aplicativos decidem que tipo de proteção de privacidade seus aplicativos precisam e usam esses suportes nativos para combinar estratégias de criptografia on-chain, off-chain e on-chain para lidar com os problemas de privacidade que podem encontrar.

**Q11: Há mais suporte nativo para privacidade no Sui? **

A comunidade está pensando no suporte que os desenvolvedores precisam para escrever contratos inteligentes em um ambiente mais favorável à privacidade. A prova de conhecimento zero é um deles. Algumas pessoas podem pensar que Sui precisa de funções matemáticas ou criptográficas mais gerais na cadeia. Adoraríamos ver designers de contratos inteligentes fornecerem feedback sobre o que está faltando, e há toda uma classe de outras técnicas que podem ser usadas para preservar a privacidade, como computação multipartidária ou hardware confiável. Diferentes blockchains foram desenvolvidas nessas direções e requerem sistemas adicionais muito complexos. É necessário que haja provas suficientes na comunidade de que as pessoas desejam estas tecnologias, pois elas representam algumas mudanças fundamentais na arquitetura de Sui. Mas se a comunidade quiser avançar nessa direção, existe um processo para propor formas de adicionar proteções de privacidade.

**Q12: Como você acha que Sui se desenvolverá nos próximos 6 a 12 meses? **

Depende do tipo de aplicativos que as pessoas criam no Sui e, no curto prazo, muitas das melhorias serão para os aplicativos que as pessoas estão realmente construindo. De uma perspectiva de muito longo prazo, sob os padrões de blockchain, 6 a 12 meses podem ser considerados um tempo muito longo. Melhoraremos o protocolo Sui Lutris para obter menor latência, protocolos mais simples e melhorar as escalas Sui. Além disso, tornaria a economia mais eficiente, permitindo que os nós validadores funcionassem em hardware mais restrito e usassem o hardware existente para realmente executar transações, em vez de fazer criptografia ou outra sobrecarga do blockchain. Isto é o que esperamos ver.