As seções abaixo são exclusivamente voltadas para quem tem interesses técnicos no novo blockchain. Caso não seja o seu caso, ignore.
Uma nova linguagem chamada Move
O grande destaque técnico do Libra é a linguagem computacional que inaugura, chamada Move, a qual promete ser mais robusta, flexível e confiável do que as demais. No Libra, o Move serve apenas à execução de contratos inteligentes, todo o resto do blockchain está escrito em Rust, tal como o Ethereum, Zcash e outros.
A análise do código em Move, em associação à leitura do documento técnico, sugere a existência de fortes equivalências entre os principais componentes da nova linguagem (módulos/recursos/procedimentos) e os padrões das demais linguagens orientadas a objetos (classes/objetos/métodos), sugerindo que o Facebook optou por não correr riscos técnicos.
As novidades introduzidas são modestas e se limitam a aspectos secundários da execução de contratos como, por exemplo, a limitação de que um recurso (objeto) criado por um módulo (classe) nunca possa ser copiado ou implicitamente descartado, mas apenas movido entre diferentes armazenamentos de programas e o fato de que operações críticas em certo recurso apenas podem ser feitas de dentro do módulo em que tal é definido. Do mais, o Move exibe forte "tipagem" e parte da definição de métodos exclusivos para cada classe (ou "módulo", na sua designação).
"É como se tivéssemos um JavaScript fortemente tipado, em que procedimentos devem ser definidos para cada recurso e não podem ser genericamente utilizados, com o aditivo de que ponteiros e endereços de memória são amplamente utilizados no desenvolvimento dos chamados scripts de transação dentro do Libra", diz Pedro Forntini, físico (USP) e desenvolvedor de blockchain no Grupo WeMind (wemind.com.br).
Sequencing
Dentro do Libra, cada conta tem um número de sequência, identificando quantas transações já realizou. Quando uma nova transação é lançada, esta leva tal registro entre seus parâmetros. Durante a verificação de validade, uma transação com número de sequência diferente do número da conta origem não é executada.
Byzantine Fault Tolerant Consensus
O sistema de consenso do Libra usa uma lógica comum a outros blockchain, onde é aceito que podem existir f de validadores falhos (que falharam em executar a transação ou têm intenções maliciosas) e, para evitar que eles tenham um impacto nas operações, o sistema precisa incluir sempre no mínimo 3f+1 validadores. Desse modo, se até f validadores discordarem da maioria, a transação ocorrerá normalmente, ao passo que se existirem mais de f discordantes, a transação não será realizada.
Após o consenso aprovar um bloco, este é enviado para a memória permanente onde aguarda até a confirmação de pelo menos mais dois blocos sequenciais, derivados dele (o bloco k só é registrado após confirmar a existência e validade dos blocos k+1 e k+2).
Desempenho transacional no Libra Blockchain
Inicialmente, o Libra tem como objetivo ser capaz de realizar 1.000 transações por segundo com um tempo total de 10 segundos entre iniciar a transação e armazená-la na memória permanente. Os recursos necessários para este nível de performance são amplamente acessíveis e poderão ser utilizados conforme aumente o número de nós validadores. Simultaneamente, é esperado que o nó central seja hospedado em servidores de maior capacidade.
Considerando que a memória histórica pode, eventualmente, exceder a capacidade dos validadores foi introduzida uma função de descarte que beneficia as execuções dos contratos recentes neste blockchain.
Partindo destes princípios, rodamos uma série de chamadas, começando por transações que servem para a criação de tokens (mint). O procedimento para tanto parte dos comandos "account create" e "account mint", que devem ser executados sequencialmente. O primeiro retorna o endereço da conta criada, assim como um índice para facilitar a referência da carteira criada em outros comandos utilizados; o segundo recebe como parâmetros o índice da carteira em que as moedas serão criadas e a quantidade a ser gerada: "account mint 0 10" gerará 10 moedas na carteira de índice 0.
Outro tipo de transação elementar é a transferência, a qual passa tokens de uma carteira para outra. O procedimento é similar ao anterior. Um exemplo de comando para esse tipo de transação seria "transfer 0 1 10", que pede pela transferência de 10 tokens, da carteira de índice 0 para a de índice 1.
A despeito da propalada capacidade de processamento de 1000 transações por segundo, fato é que, na versão atual, o envio consecutivo de apenas duas transações do tipo mint é suficiente para a geração de erros.
A mensagem informa-nos que muitas requisições foram enviadas, sobrecarregando a rede, de modo que é preciso esperar um intervalo para poder voltar a utilizá-la. Este intervalo de descanso cresce proporcionalmente ao número de transações consecutivas enviadas. Tal limitação não deve ser tomada como permanente, sendo característica deste momento embrionário da rede.
Já para transações de transferência, os testes mostram que o número de requisições consecutivas que a rede aceita gira em torno de 30. Ao enviarmos um número maior, deparamo-nos com um erro semelhante ao anterior.
Considerações técnicas finais
O Facebook optou por uma abordagem conservadora, arriscando pouco do ponto de vista computacional. A despeito dos seus contratos inteligentes rodarem em Move, a estrutura geral do Ethereum.
A rede de testes disponibilizada não permite saber se a velocidade de transações propalada irá se verificar na prática, mas certamente sugere que o código ainda está em evolução. Isso vai de encontro ao fato de que existem pequenas discrepâncias entre coisas que estão no site e nos papers técnicos.
À primeira vista, um dos aspectos de maior elegância e potencial do Libra é o seu sistema de produção de consenso, chamado HotStuff (paper científico pode ser encontrado aqui).
Porém, visto em detalhes, este replica algumas das principais soluções matemático-computacionais em voga e se sustenta em Byzantine Fault Tolerance (BFT), conforme previamente descrito.
Fica a dúvida se, na prática, teremos novos mecanismos de aprovação de blocos, tal como vem sendo o caso nos blockchains mais avançados. A depender do time envolvido, é provável que sim.