No limite do determinismo: ciclo de vida das transações no Solana Sealevel e no runtime de objetos da Sui

O que é o ciclo de vida de uma transação de blockchain?

Blockchains processam transações. As transações afetam o estado, ou seja, a visão atualizada das contas em uma blockchain. Entender o ciclo de vida de uma transação pode ser a expressão mais clara da filosofia de design de uma blockchain, oferecendo às partes interessadas técnicas insights importantes sobre como a rede é otimizada para throughput e segurança, garantias de determinismo, custos relativos de engenharia e possíveis pontos problemáticos em condições reais.

Nas próximas seções, examinaremos as diferentes etapas pelas quais as transações passam, do envio à finalização, e como esse processo afeta a execução em vários níveis dessas redes.

Ciclo de vida das transações da Solana

A blockchain Solana foi criada com um design exclusivo que utiliza Proof-of-Stake (PoS) como mecanismo de consenso e Proof-of-History (PoH) como mecanismo de controle do tempo para ordenar transações com eficiência.

O modelo de design da Solana é centrado em contas, o que equivale a dizer que "tudo na Solana é uma conta".

As contas são usadas para armazenar dados, incluindo estado e binários executáveis, ou seja, código de programas. As transações contêm instruções que modificam o estado das contas. Os nós que participam do consenso na rede e processam transações são chamados de validadores. O processo pelo qual as transações são processadas para modificar uma conta é chamado de pipelining, e os pontos em que a transação se encontra em diferentes momentos do seu ciclo de vida são chamados de etapas.

Uma transação da Solana

Na Solana, uma transação é um conjunto de assinaturas de mensagens serializadas, assinadas pela primeira chave da chave de conta de Message.

A mensagem de uma transação é uma estrutura de dados que contém um cabeçalho, chaves de contas, um blockhash recente e instruções. O cabeçalho contém MessageHeader, que descreve a organização das chaves de contas de Message.

Cada instrução define explicitamente quais contas pode acessar e as permissões necessárias para cada uma. Essas permissões indicam se uma conta é somente leitura ou leitura e gravação, além de informar se ela deve ter assinado a transação que contém a instrução.

pub struct Message {
pub header: MessageHeader,
pub account_keys: Vec<Pubkey>,
pub recent_blockhash: Hash,
pub instructions: Vec<CompiledInstruction>,
}

Cada instrução contém uma lista de todas as contas que pode acessar, além das permissões necessárias para cada conta.

Uma Message contém uma única lista simples e compartilhada de todas as contas necessárias para todas as instruções da transação. Essa lista simples é criada durante a construção de uma Message, e as instruções são convertidas em um conjunto de CompiledInstructions. Essas CompiledInstructions referenciam por índice as contas necessárias da única lista de contas compartilhada.

A lista de contas compartilhada é ordenada de acordo com as permissões exigidas das contas:

• Contas graváveis e signatárias.
• Contas somente leitura e signatárias.
• Contas graváveis e não signatárias.
• Contas somente leitura e não signatárias.

Com base nessa ordenação, os campos de MessageHeader descrevem quais contas de uma transação exigem quais permissões.

pub struct MessageHeader { 
pub num_required_signatures: u8,
pub num_readonly_signed_accounts: u8,
pub num_readonly_unsigned_accounts: u8,
}

Quando várias transações acessam as mesmas contas somente leitura, o runtime pode processá-las em paralelo em uma única entrada de PoH. As transações que acessam as mesmas contas de leitura e gravação são processadas sequencialmente.

As transações são enviadas ao cliente por meio do Gulf Stream, o protocolo de encaminhamento de transações da Solana, e processadas em dois processos multietapas em pipeline no validador, chamados Transaction Processing Unit (TPU) e Transaction Validation Unit (TVU).

Esses processos trabalham em conjunto com o runtime para garantir que as transações que modificam estados de contas diferentes sejam processadas em paralelo, enquanto aquelas que modificam o mesmo estado de conta sejam processadas sequencialmente.

A TPU opera quando o validador está no modo líder, ou seja, produzindo blocos, e a TVU opera quando o validador está no modo validador, ou seja, validando blocos. Nos dois casos, o hardware em pipeline é semelhante: entrada de rede, gravações em discos, saída de rede etc. No entanto, o uso desse hardware é diferente. Em termos simples, a TPU é usada para criar entradas no ledger, enquanto a TVU existe para validar essas entradas.

Em uma visão geral, as transações são enviadas por um cliente e processadas pelo Gulf Stream via QUIC até a TPU de um líder. A transação passa por verificações e, depois, é agendada pela etapa bancária para execução. As atualizações de estado são gravadas de volta no estado em memória do banco. Os validadores votam nos blocos por meio de gossip, e os blocos são finalizados usando Tower BFT, uma variante de PBFT com mecanismos de bloqueio ponderados por stake.

Gulf Stream

Na maioria das blockchains, as transações enviadas pelos usuários ficam em uma "fila" em um mempool, literalmente um "pool de memória", aguardando o processamento pela rede. As transações assinadas podem permanecer no mempool por um longo período, talvez indefinidamente, aguardando a execução caso a rede não esteja em um estado ideal ou as condições de execução não sejam atendidas. Com isso, essas transações podem nunca ser incluídas em um bloco.

A Solana elimina a necessidade de um mempool global usando uma programação determinística de líderes influenciada por um algoritmo ponderado por stake, conhecido como Stake-Weighted Quality of Service (SWQoS), para priorizar mensagens de transações encaminhadas por validadores com stake.

Como todos os nós ativos conhecem antecipadamente a programação de líderes, as mensagens de transações podem ser distribuídas com eficiência. Isso garante que os próximos líderes já tenham transações suficientes para processar antes do momento agendado para produzir um bloco. Esse mecanismo permite que os validadores pré-processem transações, verificando assinaturas e eliminando antecipadamente transações duplicadas ou malformadas.

Outra vantagem do Gulf Stream é que, nas redes tradicionais que usam um mempool, os produtores de blocos também precisam retransmitir as mesmas transações em um bloco. Isso significa que cada transação é propagada pela rede pelo menos duas vezes. A Solana não precisa sobrecarregar o gossip para sincronizar transações pendentes, e as transações não precisam competir por espaço nos blocos por meio de leilões de gas. Em vez disso, elas são distribuídas com base na programação.

Transaction Processing Unit (TPU)

A TPU é a lógica central do validador responsável pela produção de blocos. As transações são obtidas do cliente e encaminhadas em pacotes de dados por um componente chamado QUIC streamer, que aloca a memória dos pacotes e lê os dados do endpoint QUIC, processo conhecido como "Etapa de busca". Cada stream transmite um pacote dentro de uma restrição de transmissão QUIC identificada pelo cliente, por endereço IP e chave pública do nó, e pelo servidor.

Os pacotes são então transmitidos para a Etapa Sigverify, onde são desduplicados por um mecanismo especial de redução de carga para remover pacotes excessivos. Em seguida, os pacotes desduplicados são filtrados para remover aqueles com assinaturas inválidas e encaminhados à etapa bancária.

A etapa bancária é um componente essencial da execução no runtime da Solana. Ela agenda os pacotes recebidos, aplica filtros adicionais para identificar conflitos e avalia se eles devem ser processados, retidos ou encaminhados em lotes. Caso detecte que o nó é o produtor do bloco, ela processa os pacotes retidos e recém-recebidos com o componente Bank. Esse componente é uma representação em memória do estado completo do ledger em determinado slot.

Na etapa bancária e no componente de agendamento, a transação é monitorada em dois estados:

• Um estado não processado, no qual a transação está disponível para agendamento
• Um estado pendente, no qual a transação está sendo agendada ou processada

Quando uma transação termina de ser processada, ela pode ser repetível. Nesse caso, retorna ao estado não processado. Caso contrário, o estado deve ser descartado. As transações válidas processadas são transformadas em uma "Entrada" por meio de ticks de PoH, agrupadas em blocos e transmitidas como shreds para os pares da rede pelo Turbine, o protocolo de propagação de blocos da Solana. O protocolo gera códigos de apagamento para "regenerar" pacotes de dados perdidos antes de transmiti-los ao par de rede apropriado na Etapa de transmissão.

Transaction Validation Unit (TVU)

A TVU é a lógica dos nós validadores que não são líderes, responsável por validar e propagar blocos. Na TVU, os pacotes de dados são processados em etapas multithread antes da finalização. Isso inclui as etapas de obtenção de shreds, verificação de assinaturas, retransmissão e replay.

Na Etapa de busca de shreds e na etapa de verificação da assinatura do líder nos shreds, os nós que não são líderes recebem os shreds de outros nós via UDP e verificam as assinaturas em lote. Os shreds válidos são retransmitidos aos nós pares na Etapa de retransmissão, e cada transação é reproduzida em ordem na Etapa de replay.

Na etapa de replay, o runtime é invocado para reexecutar deterministicamente todas as transações, garantindo que todas as alterações de estado, os atributos dos programas e os hashes dos bancos correspondam exatamente à saída do líder.

Se um bloco for considerado válido, o validador assina uma transação de voto e envia esse voto ao líder para inclusão em blocos posteriores.

Runtime

O runtime é o processador de transações concorrentes da Solana, compartilhado entre a TPU e a TVU. As transações especificam antecipadamente suas dependências de dados, ou seja, as contas das quais desejam ler e/ou nas quais desejam gravar, para permitir a execução explícita em memória dinâmica. Consequentemente, a leitura do estado pode ser bem isolada da execução dos programas, permitindo que o runtime coordene o acesso concorrente.

O runtime da Solana usa um mecanismo de execução chamado Sealevel para garantir que as transações que acessam contas somente leitura sejam executadas em paralelo. Por outro lado, as transações que acessam contas graváveis sobrepostas são serializadas e executadas sequencialmente.

Dentro do runtime, as transações são executadas de forma atômica. Todas as instruções de uma transação precisam ser executadas com sucesso para que ela seja confirmada no banco. Caso contrário, a transação falha.

O runtime interage com determinado programa por meio de um ponto de entrada com uma interface bem definida. Esse ponto de entrada é simplesmente uma função Rust que todos os programas on-chain expõem de forma consistente como ponto inicial da execução e que funciona como interface entre o runtime da Solana e os programas. Seu mecanismo de execução mapeia chaves públicas para contas e as encaminha a esse ponto de entrada. No entanto, ele impõe algumas restrições essenciais para orientar sua lógica de execução, definidas pela arquitetura do conjunto de instruções da máquina virtual:

• Somente o programa proprietário pode modificar o conteúdo de uma conta.
• Os saldos totais de todas as contas são iguais antes e depois da execução de uma transação, mas isso só se aplica de forma agregada. Lamports não são conservados em transferências e queimas do sistema.
• Após a execução da transação, os saldos das contas somente leitura devem ser iguais aos saldos anteriores à transação.
• Todas as instruções da transação são executadas atomicamente. Se uma delas falhar, todas as modificações nas contas serão descartadas.

Os pipelines da TPU e da TVU seguem caminhos um pouco diferentes ao interagir com o runtime. O runtime da TPU garante que as "entradas" sejam registradas, por meio de ticks de PoH, antes que a memória seja confirmada. Já o runtime da TVU garante que as "entradas" sejam verificadas antes que o runtime processe qualquer transação.

Consenso

O consenso é um dos mecanismos mais fundamentais de sistemas complexos de computação distribuída. No ciclo de vida das transações da Solana, o consenso ocorre depois que o bloco é executado e validado pela TVU, mas antes da finalização. A ideia central do consenso é um acordo uniforme que garante que os participantes da rede concordem com o mesmo resultado e, depois de decidirem, não possam mudar sua decisão.

Formalmente, um mecanismo de consenso tolerante a falhas deve atender às seguintes propriedades:

• Acordo uniforme: dois nós não podem tomar decisões diferentes.
• Integridade: nenhum nó toma uma decisão mais de uma vez.
• Validade: se um nó decidir por um valor, esse valor deve ter sido proposto por algum outro nó.
• Término: todo nó que não falhar acaba decidindo por algum valor.

Em uma visão superficial, o objetivo do consenso é fazer com que os nós concordem sobre algo. Na Solana, existem várias situações em que os nós precisam entrar em acordo. Isso predomina em três cenários:

Rotação de líderes

Todos os nós precisam concordar sobre quem é o líder, pois falhas na rede podem interromper a comunicação e causar um cenário de cérebro dividido, no qual vários nós acreditam incorretamente que são o líder ao mesmo tempo.

A programação de líderes é gerada com uma seed predefinida e o seguinte algoritmo: a altura de tick do PoH, ou seja, um contador que aumenta monotonamente, é usada periodicamente como seed para um algoritmo pseudoaleatório estável.

Nessa altura, o banco obtém uma amostra de todas as contas com stake cujas identidades de líder votaram dentro de um número de ticks configurado pelo cluster. Essa amostra é chamada de conjunto ativo e é ordenada pelo peso do stake. A seed aleatória é então usada para selecionar nós ponderados pelo stake e criar uma ordenação ponderada pelo stake, que se torna válida após um número de ticks configurado pelo cluster.

Sincronização

Sem timestamps confiáveis, um validador não consegue determinar a ordem dos blocos recebidos. A Solana usa um mecanismo chamado Proof-of-History como relógio criptográfico para ordenar as transações antes que elas passem pelo consenso. De acordo com a documentação da Anza sobre sincronização:

“Os nós líderes atribuem um "timestamp" aos blocos usando provas criptográficas de que algum tempo passou desde a última prova. Todos os dados adicionados por hash à prova certamente foram gerados antes da criação dela. O nó então compartilha o novo bloco com os nós validadores, que podem verificar essas provas. Os blocos podem chegar aos validadores em qualquer ordem ou até ser reproduzidos anos depois. Com garantias de sincronização tão confiáveis, a Solana pode dividir os blocos em lotes menores de transações chamados entradas. As entradas são então transmitidas aos validadores em tempo real, antes de qualquer noção de consenso de bloco”.

É importante lembrar que, embora Proof-of-History não seja um mecanismo de consenso, ele tem um impacto significativo no desempenho do consenso Proof-of-Stake da Solana.

Confirmação atômica

Outro processo necessário sobre o qual os nós precisam concordar são as confirmações atômicas. Em um sistema de alto desempenho como a Solana, uma transação pode falhar em alguns nós e ter sucesso em outros.

Para evitar a execução parcial, a Solana garante atomicidade dentro do runtime, no sentido de ACID, e também garante que todos os nós concordem com o resultado de uma transação: eles fazem rollback se algo der errado ou confirmam a transação se nada der errado.

O commitment na Solana mede a finalidade de um bloco, ou slot, com base no número de validadores que votaram nele e na profundidade dos votos no mecanismo de bloqueio do Tower BFT. Ele reflete a força do consenso da rede sobre determinado slot com base nos votos dos validadores. Cada validador vota nos slots, mais especificamente nas alturas dos blocos, e se compromete a não votar em forks conflitantes. Os bloqueios do Tower BFT garantem o cumprimento desse mecanismo.

A Solana tem três status de commitment: processado, confirmado e finalizado. Um bloco é considerado confirmado quando uma supermaioria dos validadores com stake (≥66%) vota nele, e é finalizado quando pelo menos 32 blocos confirmados são construídos sobre ele.

Como consequência direta de sua execução paralela otimista e programação assíncrona de líderes, a Solana segue um modelo de "executar primeiro e votar depois": o protocolo não espera que todos os validadores concordem com um bloco recém-produzido antes de produzir o próximo. Isso também pode gerar forks, ou seja, um cenário em que duas ou mais cadeias concorrentes existem simultaneamente. Quando um slot é finalizado, todos os forks concorrentes são abandonados, e esse fork se torna a cadeia canônica.

Alpenglow

No momento da publicação deste artigo, a Solana usa Tower BFT e o ledger de PoH para garantir que a rede alcance um estado de consenso mesmo quando alguns participantes falham.

Recentemente, a equipe de pesquisa da Anza propôs um novo design para um protocolo de consenso mais simples e eficiente chamado Alpenglow. O Alpenglow busca reformular os componentes legados do atual design de consenso, incluindo Proof of History, Tower BFT e o uso de gossip para a propagação de votos.

Em sua essência, o Alpenglow usa Votor e Rotor para acelerar o consenso da Solana:

Votor é um mecanismo de votação em dois níveis, projetado para alcançar a finalidade dos blocos em uma única rodada quando 80% do stake responde e em duas rodadas quando pelo menos 60% do stake responde.

Rotor aprimora o protocolo Turbine existente usando uma única camada de nós de retransmissão para distribuir shreds. O Rotor também aproveita a largura de banda dos nós participantes proporcionalmente ao stake para reduzir os saltos e otimizar o throughput da Solana. 

Sui

Diferentemente da Solana, que usa um modelo centrado em contas, a blockchain Sui utiliza um modelo de dados orientado a objetos, representando os dados de estado como objetos com identificadores, propriedades e métodos exclusivos.

Na Sui, um smart contract também é um objeto, chamado pacote Sui Move, com um identificador exclusivo que manipula objetos. Esses pacotes Sui Move são compostos por um conjunto de módulos de bytecode Move. Cada módulo é identificado exclusivamente por seu nome e pela combinação entre o ID on-chain de um pacote e o nome do módulo.

Embora os detalhes do design e dos metadados dos objetos estejam fora do escopo deste artigo, é fundamental lembrar que todo objeto tem um proprietário que determina como esse objeto pode ser usado em transações.

Os objetos podem ter os seguintes modelos de propriedade:

• Objetos pertencentes a endereços: um objeto desse tipo pertence a um endereço específico de 32 bytes, seja um endereço de conta ou um ID de objeto. Somente seu proprietário pode acessá-lo.
• Objetos imutáveis: um objeto imutável não pode ser alterado, transferido nem excluído. Esses objetos não têm proprietário e estão globalmente disponíveis para uso por qualquer pessoa.
• Objetos compartilhados: um objeto compartilhado é disponibilizado e pode ser acessado por todos.
• Objetos encapsulados: isso envolve encapsular um objeto dentro de outro. Objetos encapsulados não têm independência e só podem ser acessados por meio do objeto que os encapsula.

Uma transação da Sui

Na Sui, as transações são compostas por um grupo de comandos que operam sobre entradas para definir o resultado da transação. Esses grupos de comandos são chamados de blocos de transações programáveis (PTBs) e definem todas as transações de usuários na Sui. Os PTBs permitem que um usuário chame várias funções Move, gerencie seus objetos e administre suas "moedas" em uma única transação, sem precisar publicar um novo pacote Move.

A estrutura de um PTB é definida como:

{
    inputs: [Input],
    commands: [Command],
}

inputs é um vetor de argumentos que podem ser objetos ou valores puros. Esses objetos podem pertencer ao remetente, ser compartilhados ou ser imutáveis. O campo commands é um vetor de instruções de transação de alto nível.

Durante a execução dos PTBs, o vetor de entrada é preenchido pelos objetos de entrada ou pelos bytes de valores puros. Os comandos da transação são então executados em ordem, e os resultados são armazenados em um vetor de resultados. Esse vetor é um array de valores, em que cada valor pode ser qualquer tipo Move arbitrário e específico de cada comando. Ao contrário das entradas, os valores não se limitam a objetos ou valores puros. Por fim, os efeitos da transação são aplicados atomicamente. 

Não discutiremos os detalhes internos dos PTBs da Sui, pois esse é outro tema complexo. No entanto, vale observar que, no início da execução, o runtime do PTB carrega no array de entrada os objetos de entrada já carregados. Esses objetos já foram verificados pela rede segundo regras como existência e propriedade válida. Os bytes de valores puros também são carregados no array, mas só são validados no momento do uso.

Nessa etapa, os efeitos sobre a moeda de gas são extremamente importantes. O orçamento máximo de gas é retirado da moeda de gas. Esse orçamento geralmente é especificado pelo remetente quando a transação é enviada e representa a quantidade máxima de gas que ela pode consumir. Todo gas não utilizado é devolvido à moeda de gas ao fim da execução, mesmo que a moeda tenha mudado de proprietário. Em seguida, cada comando da transação é executado em ordem.

Após o envio, o nó completo certifica todos os metadados fornecidos ao enviar a transação para um nó validador, na etapa de certificação. O nó validador realiza todas as verificações de validade necessárias e assina a transação para confirmar sua validade caso ela seja aprovada. Para que uma transação seja considerada válida por um nó validador, ela deve:

• Ter uma assinatura de usuário válida.
• Garantir que o iniciador da transação tenha acesso a todos os objetos de entrada pertencentes a ele que a transação utiliza.
• Garantir que os objetos de entrada compartilhados usados pela transação existam.
• Conter pelo menos a quantidade de gas especificada no orçamento de gas da transação.

Se todas as verificações forem aprovadas, o validador tentará bloquear todos os objetos inputs pertencentes a um proprietário para o "digest da transação" em questão, garantindo que cada entrada com proprietário só possa ser usada uma vez por vez.

Se o processo de bloqueio for bem-sucedido, o validador assina a transação e devolve a assinatura ao nó completo.

Um nó completo da Sui é essencialmente uma visão somente leitura do estado da rede. Ao contrário dos nós validadores, os nós completos não podem assinar transações, embora possam validar a integridade da cadeia reexecutando transações confirmadas anteriormente por um quórum de validadores. O nó completo não coleta apenas a assinatura de um validador, mas o maior número possível de assinaturas de validadores em paralelo. No entanto, apenas uma supermaioria (⅔+ do stake) é necessária para formar um certificado de transação.

Execução e checkpoints

Depois que as transações recebem um certificado, elas são enviadas para execução por um comitê de validadores, ou seja, um conjunto de validadores independentes definido para cada época. O validador não precisa verificar novamente as transações: ele só precisa verificar as assinaturas do certificado. Se a assinatura do certificado for válida, o validador pode ter certeza de que a transação é válida.

Durante a execução, as transações são divididas em duas categorias: transações de objetos com proprietário e transações de objetos compartilhados:

Transações de objetos com proprietário

As transações de objetos com proprietário não acessam nenhum objeto de entrada compartilhado e são executadas imediatamente. Elas também são conhecidas como transações de caminho rápido, ou seja, são executadas após a validação e confirmadas na cadeia canônica. Essas transações não "passam" pelo consenso. As transações de caminho rápido acabam passando pelo consenso, mas somente para estabelecer uma ordem canônica para inclusão nos checkpoints. Tecnicamente, isso é possível porque não há risco de gravações conflitantes, já que somente o proprietário pode modificar o objeto. 

Transações de objetos compartilhados

As transações de objetos compartilhados acessam objetos compartilhados e, portanto, precisam ser ordenadas por consenso em relação a outras transações que usam e executam os mesmos objetos compartilhados. Elas também são conhecidas como transações de caminho lento. Essas transações precisam passar por todo o processo de consenso para garantir consistência, pois os objetos envolvidos podem ser acessados e modificados por vários usuários. 

Anteriormente, o mempool da Sui, Narwhal, evitava o congestionamento típico ao separar a distribuição das transações de sua ordenação. Ele mantinha transações certificadas e assinadas em um grafo acíclico direcionado (DAG), sem ordená-las por conta própria. O Bullshark fornecia então a ordenação de consenso.

Para melhorar ainda mais o desempenho e a resiliência, o protocolo HammerHead foi introduzido como um aprimoramento do Bullshark, implementando uma seleção dinâmica de líderes baseada em pontuação. Isso reduziu significativamente a latência e aumentou o throughput, sobretudo na presença de líderes com falhas ou inativos.

Com base nesses avanços, o Mysticeti agora substitui tanto o Narwhal quanto o Bullshark, unificando a distribuição e a ordenação de transações em um único protocolo. O Mysticeti organiza as transações em uma ordem total, simplificando ainda mais o processo e alcançando menor latência e maior throughput. Além disso, graças ao modelo de propriedade centrado em objetos da Sui, a maioria das transações continua independente e não precisa competir por uma posição em uma ordenação global.

Após a execução das transações, o validador assina os efeitos da transação e os devolve ao nó completo. Os efeitos de uma transação são essencialmente uma lista de todas as ações realizadas por ela, como todos os objetos alterados, o gas consumido e o status de execução da transação.

As assinaturas dos efeitos formam um conjunto de certificados de efeitos coletados pelo nó completo junto a uma supermaioria de validadores, garantindo que uma transação foi finalizada.

Quando uma transação é incluída em um checkpoint, indicando a etapa final do seu ciclo de vida, as mudanças de estado resultantes dessa transação já foram finalizadas e aplicadas à rede.

Para transações que envolvem somente objetos de entrada com proprietário, os validadores executam e finalizam as transações antes de enviá-las à camada de consenso para ordenação.

Por outro lado, as transações que envolvem objetos de entrada compartilhados são enviadas ao consenso para ordenação antes da execução e não são reenviadas para inclusão em checkpoints.

O validador coleta da camada de consenso blocos completos de transações ordenados por causalidade e constrói um checkpoint. Ele contém tanto a lista de digests das transações quanto os digests correspondentes dos efeitos de cada transação. Assim, os checkpoints funcionam como um registro imutável de todas as transições de estado finalizadas na rede.

Finalidade

Uma transação na Sui alcança a finalidade assim que uma supermaioria (2𝑓 + 1) de validadores aceita e contra-assina um certificado de transação, mesmo antes que o certificado seja ordenado pelo consenso ou executado. Nesse momento, nenhuma transação conflitante pode ocorrer, e a transação não pode ser revogada. Para transações que envolvem apenas objetos com proprietário, o resultado da execução é conhecido imediatamente após a finalidade. Para transações de objetos compartilhados, o resultado só é determinado depois que o certificado é ordenado pelo consenso. A finalidade da transação é alcançada em duas viagens de ida e volta pela rede.

A liquidação ocorre quando a transação é executada por uma supermaioria de validadores e um certificado de efeitos é formado. Para transações de objetos com proprietário, essa execução ocorre imediatamente, sem esperar pelo consenso. Para transações de objetos compartilhados, a execução e a liquidação acontecem logo após o certificado ser ordenado pelo consenso. Nos dois casos, a liquidação não é adiada pela criação de checkpoints, o que resulta em menor latência do que o processo de checkpointing.

Embora um certificado de transação seja um forte indício de finalidade, somente um certificado de efeitos ou a inclusão em um checkpoint certificado fornece uma garantia absoluta, pois esses processos exigem que uma supermaioria de validadores execute e confirme os efeitos da transação.

Em uma visão geral, o ciclo de vida das transações da Sui aproveita um modelo centrado em objetos para maximizar o paralelismo e a eficiência. Quando uma transação é enviada para certificação, os validadores tentam bloquear as versões específicas dos objetos de entrada referenciados por ela.

Para objetos com proprietário, esses bloqueios são obtidos imediatamente durante a certificação, garantindo acesso exclusivo e impedindo gastos duplos. Para objetos compartilhados, os bloqueios só são estabelecidos depois que a transação é ordenada pelo protocolo de consenso da Sui.

Depois que todos os bloqueios necessários são obtidos, a transação é agendada para execução. Esse design permite que transações que operam em conjuntos distintos de objetos sejam executadas de forma independente e em paralelo, reduzindo significativamente a contenção e o congestionamento em partes não relacionadas do estado.

Após uma execução bem-sucedida, os validadores assinam os efeitos da transação. Quando uma supermaioria de assinaturas é coletada, um certificado de efeitos é formado. Esse certificado garante a finalidade da liquidação, indicando que a transação agora é irreversível e que seus efeitos são permanentes.

Os checkpoints não fazem parte do caminho crítico da execução ou da finalidade das transações. Em vez disso, eles são construídos após a execução para fornecer uma ordenação canônica das transações e facilitar a sincronização do estado para nós que não participaram diretamente da execução.

O modelo de objetos da Sui permite monitorar dependências com precisão no nível dos objetos, eliminando a necessidade de sincronização do estado global. Essa arquitetura oferece suporte à execução distribuída e escalável em hardware convencional, em vez de depender de avanços no desempenho do hardware para alcançar um throughput maior.

Insights sobre execução, escalabilidade e concessões de design

Como mencionado anteriormente, entender o ciclo de vida de uma transação pode ser a expressão mais clara da filosofia de design de uma blockchain. As diferenças entre o ciclo de vida das transações da Solana e da Sui revelam filosofias profundas dos modelos de execução em três vetores essenciais: eficiência de execução, limites de escalabilidade e concessões de design.

Execução

Como uma rede centrada em contas, a Solana detecta conflitos entre contas de forma dinâmica por meio do bloqueio de contas durante a Etapa bancária. Isso garante que as transações que não modificam a mesma conta sejam processadas em paralelo, enquanto transações conflitantes são processadas sequencialmente.

Embora esse mecanismo de detecção de contas possa gerar custos adicionais de runtime em cenários intensivos de DeFi, sobretudo quando os programas precisam executar lógica presente em outros programas, mecanismo chamado Cross-Program Invocation, o mecanismo de execução da Solana ainda consegue alcançar um paralelismo enorme graças à detecção dinâmica de conflitos. Isso permite que a rede execute transações quase instantaneamente e com taxas incrivelmente baixas.

A Sui, por outro lado, não precisa se preocupar com transações conflitantes, pois seu paralelismo é inferido durante a compilação graças ao modelo de propriedade centrado em objetos. O modelo de objetos compartilhados e com proprietário permite inferir conflitos estaticamente e alcançar um custo de runtime quase nulo para transações de objetos com proprietário.

Limites de escalabilidade

Em termos de escalabilidade, a Sui alcança escalabilidade horizontal e pode crescer linearmente com as partições de objetos ao processar transações de objetos com proprietário sem consenso global. Isso permite finalidade quase instantânea, em menos de um segundo, e throughput limitado apenas pelo hardware disponível. As transações de objetos compartilhados exigem consenso, mas, com a atualização Mysticeti, agora também alcançam finalidade em menos de um segundo e alto throughput. A arquitetura da Sui permite que tanto a distribuição quanto a execução de blocos sejam escaladas de forma elástica com a adição de mais recursos. Isso permite ao sistema processar cargas de trabalho maiores com eficiência, embora o caminho de consenso não seja tão ilimitado quanto o caminho rápido dos objetos com proprietário.

A Solana, devido à sua abordagem de líder único e à distribuição da execução, limitada pela contenção de contas, parece atingir certo limite de escalabilidade horizontal por causa do modelo de estado global com um único shard e da ingestão de transações centrada no líder em cada slot. No entanto, ela otimiza agressivamente o desempenho dentro desse limite por meio de um pipelining bem definido, complementado pelo PoH. As transações podem ser ordenadas com precisão, processadas em menos de 400 ms e alcançar confirmação otimista em menos de um segundo. Em termos de escalabilidade vertical, a Solana escala significativamente com o hardware dos validadores, sobretudo núcleos de CPU e RAM, pois isso está perfeitamente alinhado ao seu design inerente.

É importante destacar que a Solana opta pela escalabilidade vertical em vez da horizontal e atinge um limite por causa de concessões de design, não de uma falha arquitetônica. Algumas abordagens horizontais, como mercados locais de taxas, sub-redes virtuais e minimização de estado por meio de CMTs, estão em desenvolvimento.

Concessões de design

A Solana garante determinismo por meio de restrições rigorosas no runtime, isolamento de contas e programação determinística de líderes. Sua resolução dinâmica de contenção de contas e seu pipelining bem definido favorecem uma interação profunda entre programas, permitindo alcançar uma alta capacidade de composição.

A Sui oferece garantias de determinismo por meio de caminhos de execução integrados, determinados pela análise da propriedade dos objetos. Ao mesmo tempo, o modelo centrado em objetos da Sui permite a composição por meio de objetos compartilhados e blocos de transações programáveis (PTBs), possibilitando interações complexas e operações atômicas entre vários contratos e usuários. Isso é possível porque o proprietário de um objeto pode ser outro objeto, permitindo a interoperabilidade no nível dos objetos e sua organização em árvores de propriedade. Essas estruturas são especialmente úteis quando os objetos são usados juntos com frequência ou quando buscas no runtime são necessárias para determinar qual objeto deve ser usado durante a execução.

Resumo

O mecanismo pelo qual as transações são processadas, do envio à finalidade, é a base do incrível desempenho da Solana e da Sui. Ao analisar o ciclo de vida das transações, podemos compreender os pipelines cuidadosamente projetados que garantem baixa latência e alto throughput para as duas redes.

A Solana foi projetada com um modelo centrado em contas, e as transações passam por uma série de processos multithread e pipelines para garantir sua validade. As transações são enviadas ao líder, que executa o pipeline da TPU para garantir que sejam verificadas e agendadas adequadamente: em paralelo quando não há conflitos e sequencialmente quando há. Quando um validador não está produzindo blocos, ele executa o pipeline da TVU para replicar e validar transações. Tanto a TPU quanto a TVU usam o runtime. Com isso, a Solana processa milhares de transações em períodos muito curtos, pois o runtime consegue identificar antecipadamente e de forma determinística contas sem sobreposição e executar em paralelo as transações que não entram em conflito. Isso torna a Solana ideal para casos reais como negociação de alta frequência, DeFi com alta capacidade de composição, dApps com grande demanda de infraestrutura e dApps de consumo com baixa latência.

A Sui, por outro lado, usa um modelo centrado em objetos, no qual cada objeto é monitorado por um identificador exclusivo. Ao inferir a propriedade dos objetos, ela consegue determinar estaticamente se uma transação pode ser executada em paralelo ao operar sobre conjuntos distintos de objetos. Por meio de seu modelo de caminhos duplos de execução, que separa as transações entre objetos com proprietário e objetos compartilhados e usa checkpoints assinados para manter os nós completos sincronizados, ela consegue processar transações leves sem sobrecarregar a camada de consenso. Ao mesmo tempo, mantém uma finalidade confiável e rápida e uma sincronização eficiente para novos nós. Isso permite escalar horizontalmente conforme a carga aumenta e é muito útil para aplicações com interações massivas entre objetos, como DeFi, jogos, exchanges centradas em ativos e ativos programáveis.

Referências

• Documentação oficial da Solana
• Documentação oficial da Anza
• Documentação oficial da Sui
• Gulf Stream: protocolo de encaminhamento de transações sem mempool da Solana
• Sealevel — processamento paralelo de milhares de smart contracts
• Cross-Program Invocations e PDAs: a combinação de dois mecanismos poderosos no Anchor
• Narwhal e Tusk: um mempool baseado em DAG e consenso BFT eficiente
• Escalabilidade horizontal da execução da Sui com Pilotfish
• SUI vs. Solana - TrustWallet
• Tower BFT: a implementação de alto desempenho do PBFT na Solana
• David J DeWitt e Jim N Gray: “Sistemas de bancos de dados paralelos: o futuro dos sistemas de bancos de dados de alto desempenho,” Communications of the ACM, volume 35, número 6, páginas 85–98, junho de 1992. doi:10.1145/129888.129894
• Jim N Gray e Leslie Lamport: “Consenso sobre a confirmação de transações,” ACM Transactions on Database Systems (TODS), volume 31, número 1, páginas 133–160, março de 2006. doi:10.1145/1132863.1132867
• Leslie Lamport: “Tempo, relógios e ordenação de eventos em um sistema distribuído,” Communications of the ACM, volume 21, número 7, páginas 558–565, julho de 1978.
• Michael J Fischer, Nancy Lynch e Michael S Paterson: “Impossibilidade de consenso distribuído com um processo defeituoso,” Journal of the ACM, volume 32, número 2, páginas 374–382, abril de 1985. doi:10.1145/3149.214121
• Kushal Babel, Andrey Chursin, George Danezis, Anastasios Kichidis, Lefteris Kokoris-Kogias, Arun Koshy, Alberto Sonnino, Mingwei Tian: “MYSTICETI: alcançando os limites de latência com DAGs não certificados”, [cs.DC], julho de 2024.
• Giorgos Tsimos, Anastasios Kichidis, Alberto Sonnino, Lefteris Kokoris-Kogias: “HammerHead: reputação de líderes para agendamento dinâmico”, [cs.CR], setembro de 2023.