É engraçado como criamos meios de justamente ir contra o que acreditamos, às vezes apenas por preguiça.
Durante o boom das Ofertas Iniciais de Moedas (ICOs), surgiu um ‘meme’ que dividia o desenho de um cavalo em três partes.
Da direita para a esquerda o desenho ia mudando subitamente de qualidade — da mais detalhada e profissional à mais infantil possível — onde as divisões seguiam como, Whitepaper, a versão em produção e a versão estável.
Muito se falava a respeito de: “Não confie, verifique”, “Whitepaper aceita qualquer ideia, não confie só em whitepaper”, “Escrever ótimos whitepapers não é algo difícil, entregar um bom projeto é…”, dentre vários outros mantras.
Então onde estão essas pessoas tão racionais e céticas, com a mesma lógica de duvidar de um papel em branco escrito código qualquer coisa, apenas acreditando no que possa ser verificado.
Partindo do princípio acima, eu acredito que apenas falar de whitepaper ou mesmo de questões de regulamentações, torna o debate ao redor do projeto Libra muito pobre.
Não vou entrar no mérito de uma regulamentação ser boa ou não, apenas peço a sua atenção para que possamos nos ater ao que o Projeto Libra era e como ele é hoje.
Não irei entrar em pormenores sobre governança, pois isso pode mudar a qualquer momento, fora o fato que de janeiro a julho muita coisa pode mudar.
Então vamos ao que está no código fonte, não importa o que o CEO diga ou mesmo que o ‘Bob envie Algo para Alice’, não importa o que querem num futuro próximo.
Isso é irrelevante, uma vez que, comumente, ninguém assume a responsabilidade por declarações que os mesmos digam, caso os fundamentos ou as declarações não sejam seguidas.
Diferente das pessoas que acreditam por Fé, Libra tem que dar certo. Eu quero que dê certo. Vamos usar a documentação técnica do site e o whitepaper como contraponto com que está no Github:
Facebook, Libra e Github
O que tem disponível no Github do projeto Libra hoje?
1) seguindo apenas a descrição do Libra Core (o motor do libra ):
“Note to Developers
- Libra Core é um protótipo
- As APIs estão em constante evolução e são projetadas para demonstrar tipos de funcionalidade. Espere mudanças substanciais antes do lançamento
- Lançamos uma testnet que é uma demonstração ao vivo de um protótipo inicial do software Libra Blockchain”
Ou seja, como muitos pensam ‘ah é só o front-end ou só o Back-end’, na verdade não dá pra afirmar quase nada. O ponto é que existe apenas o “protótipo” e as APIS o lance de constante evolução…
Não há nenhuma estrutura além do que está aí, pronto, não ao menos em repositório público. Quer acreditar por fé, ok. Existe pouca coisa além da boa vontade.
O que tínhamos antes de enviar ao Github?
2) O repositório libra no Github não é a única estrutura do Projeto:
Se verificar os “Commit inicial do projeto”, seguido pela ID: 9BD510575CED3E08 feito por Calibra-opensource, feito em 17 de junho de 2019, dá pra ver vários pontos no código-fonte, onde a estrutura já estava sendo testada em um ambiente controlado muito tempo antes de ser enviada ao Github.
Isso não é um problema, o próprio hyperLedger da Linux Foundation e da IBM usa um estrutura assim.
O Github é apenas um “espelho”, os commits e deleções são feitas em outro ambiente, mas ao menos no caso do consórcio HyperLedger eles ao menos divulgam isso.
Não é feita a ladainha de sempre “queremos criar um projeto com a comunidade”, “venha contribuir conosco”… Enfim, saiba onde você está pondo os seus pés ou saiba ao menos qual grau de relevância você tem ao projeto — lembrando que muita gente contribuiu, mas se olharmos a frequência do repositório, as mudanças significativas são feitas pelos mantenedores.
Já no dia 18 junho 2019:
3) Lembra a parte de consenso e descentralização entre os nodes, é algo lindo certo?
Então meu amigo, esse é o ponto onde existe algo que eu chamo de “cobrar intenções, não produtos”.
Como critiquei acima, o projeto Libra tem que ser tratado como uma ICO, sem vergonha que pode prometer a cura do todos os vírus RNA, mas entregar a cura é outro ponto que necessita de diferente.
Logo depois de ter feito o upload dos arquivos no Github, surgiu uma deleção interessante:
“[consensus] remove BlockInserter, com a descrição:
Como temos a execução idempotente agora, não precisamos proteger a execução do bloco simultâneo, removemos o código para simplificar”
Como assim? proteger bloco simultâneo, o conceito acima quer dizer, Block-inserter, ou seja, uma estrutura de Semáforo, algo para controlar o acesso simultâneo de alguns sistemas concorrente onde as alterações são feitas de forma sincronizada, nada simultâneo.
Então o BlockInserter definiu como os testes estão sendo feitos no “repositório privado do facebook ou C/alibra se preferir. Eles não têm usando MasterNodes, nem mesmo gateways como o consórcio Ripple faz com a sua própria moeda”.
4) erros, erros em toda parte:
Muita gente vem apenas elogiando o “timing do consórcio Libra por trazer as moedas criptográficas a 2 bilhões de pessoas”, o que é uma tremenda besteira se olharmos, por exemplo, a quantidade de pagamentos feita apenas na plataforma do Facebook.
Pouquíssimas pessoas usam meios de pagamento para games ou mesmo para impulsionar suas publicações… E o lance do WhatsApp e Instagram também são muito obscuros, pois existe uma alta demanda para criar soluções para usar a API do Whatsapp hoje em dia.
Muitos desenvolvedores mandam e-mails ao projetos, choram no StackOverflow suplicando por suporte a API do Whatsapp, mas é muito difícil achar quem consiga lidar com ela, pois a documentação é bem escassa e desatualizada, comparando com o serviço em produção.
Com o contexto acima, dá pra afirmar que tudo está em dia no Projeto com bilhões de pessoas, certo? Que por sua vez, o Timing para criar uma solução de meios de pagamento, feito perfeito, correto?
Eu mesmo acreditei nisso ao ver alguns pronunciamentos. A documentação especializada por sua vez também passa essa impressão.
Porém, ao se deparar com “Spell check comments and typos in comments” o commit com a verificação: b073451 onde tem dezenas de erros crassos, tais como:
- verison ao invés de version,
- adres ao invés de addres,
- comited ao invés de committed
- greather ao invés de greater
- diretoy ao invés de directory
- dispath ao invés de dispatch
- intance ao invés de instance
- infromation ao invés de information
São várias mensagens com erros toscos em chinês, coisas raras em projetos bem revisados. Qualquer pessoa com o Google translate disponível e o Verbo ‘to be’ e ‘to do’ disponível, dá pra ver que houve uma certa pressa em jogar logo para o Github.
Triste é ver a quantidade. Se fosse um aqui outro alí até que passaria, mas, literalmente, são dezenas, perto de centenas de correções bobas, o que faz pensar: ‘nossa quem será que revisou esse código?. Ou melhor, ‘por que ele foi jogado assim no Github?’.
Tudo bem se você pensar que são apenas mensagens de retorno ao usuário, nenhum parâmetro foi modificado, mas a quantidade é exorbitante.
5) sem Linguagem Move e Masternode.
Conforme a própria documentação do site, não há muita informação sobre a Move, a linguagem de programação do Libra, equivalente ao Solidity do Ethereum, mas diferente dos nossos queridos.
Só temos apenas o Whitepaper, que diz bem pouco, o repositório da mesma ainda não está no Github. Não dá pra afirmar muito do produto ainda.
Agora, o masternode, o buraco é mais embaixo. Caso alguém não saiba, um masternode é nada mais do que um fiador dentro de um projeto descentralizado, auditando uma camada acima da mineração ou provendo serviços como ‘envio instantâneo’ e ‘envio privado’.
Um ponto bem interessante é que por padrão as tx (transações) com masternodes usam uma estrutura diferente de prova de trabalho ou mesmo provada de participação.
Nao da pra implementar tudo da mesma forma, uma vez que não funciona da mesma forma.
Parece óbvio, certo? Mas a correção:
“[Monitoring] Update overview dashboard
Update the variable definition.
Add incoming txn (AC counters) to the top level stats)”
Pode parecer algo inofensivo modificar a visualização da saída padrão do que está na blockchain de um projeto, mas fazer isso, conforme o contexto citado a “DashBoard”, afeta muito mais usuários do que alterar um parâmetro na linha de comando.
Poucas pessoas sabem operar um Nó de um projeto em Blockchain, mas todo mundo sabe consultar o saldo na carteira, ver a cotação, transações pendentes, se o nó está sincronizado ou não, tudo isso compõe o DashBoard.
Ou seja, um parâmetro na Dashboard pode tornar a experiência do usuário completamente nova, por menor que seja, pode causar grandes impactos.
Vale ressaltar que a estrutura atual não tem nenhum código para masternodes, mas se combinarmos a observação número 3 “block-inserter” junto com o trecho de código: e o commit: “[Monitoring] Update overview dashboard”, dá para ver que a estrutura de testes antes do Github tinha um Delay de 1 minuto.
Como tornar a rede do projeto Libra Distribuída, com suporte a Validadores externos e com a possibilidade de serem gerados blocos simultâneos?
A resposta simples é, essa etapa ainda não chegou, ou seja, ainda estamos no whitepaper, ainda não estamos em “produção”. Mas no repositório teste do Facebook, antes do código ir ao Github, a mesma não tem suporte a masternodes, justamente por não implementar parâmetros adequados para replicação de nós.
O “block-inserter” torna o processo de confirmar transação sincronizada e alternada, não simultânea, graças à modificação do Dashboard com um delay de um minuto, para sem tempo de espera.
Isso reforça que haverá uma integração, mas não do código que está no Github, talvez outra estrutura externa, algo bem incomum.
Mas essa é a única forma do projeto seguir a descrição do ciclo de transações descritas na documentação e no whitepaper, essa é a forma que eu vejo do projeto ser algo no máximo descentralizado, não distribuído.
Conclusão
Vale ressaltar que tudo que postei acima está no repositório oficial da Libra no Github, não são opiniões, mas uma análise fundamentalista atrelada ao código fonte do projeto, focando em ver o que estava sendo feito antes do Github e não apenas o agora, mas o antes e durante a inserção do mesmo no repositório oficial.
Por gentileza, verifiquem por si mesmos, não estou aqui para “dizer alegações absolutas”, mas verificar justamente o projeto em si, não apenas guardanapos em branco.
Sobre o autor
Everton Melo é pesquisador de segurança de informação. Contribuiu com mais de 70 projetos de criptomoedas, DLT e BLockchain. Também coordena o Meetup Bitcoin São Paulo e o Comibit.
