Forks do protocolo blockchain: Como surgiram Litecoin e Bitcoin Cash

ursula-spaulding-479132-unsplash

Muito se fala, no ecossistema blockchain e de criptomoedas, em Forks – ou garfos em português.

Bitcoin Cash é, tal como a Bitcoin, uma criptomoeda. No entanto, ela resulta de um Fork do protocolo Bitcoin. Algumas pessoas dizem que Litecoin – outra criptomoeda – é também um Fork do protocolo Bitcoin.

Mas afinal o que é um Fork e o que significa na prática?

Antes de lá chegarmos, importa referir que Bitcoin Cash e Litecoin são, à data de hoje, a 4ª e a 5ª criptomoedas com um valor de mercado mais elevado (€21.82Bi e €11.59Bi respetivamente).

Independentemente das suas características, aplicabilidade ou verdadeira diferenciação, tratam-se de protocolos relevantes no ecossistema atual e importantes para o contexto deste artigo.

O tema dos Forks, surge de uma questão muito simples: como se atualiza um protocolo blockchain? Como se implementam novas funcionalidades ou se resolvem bugs?

Num sistema centralizado é claro. Existe um servidor ou, se quisermos, um lugar central que é atualizado ou sobre o qual vamos trabalhar.

Mas os protocolos blockchain são descentralizados. É preciso atualizar a rede inteira e não apenas um servidor central. Como deve então ser feito e porque está isso na origem dos Forks?

(Se ainda têm duvidas sobre a questão da descentralização sugiro que leiam os meus artigos sobre o tema: “A verdadeira inovação do protocolo blockchain: descentralização” e “Afinal porque é o protocolo blockchain descentralizado e porque devo interessar-me?“)

Imaginemos que se quer introduzir uma nova funcionalidade num protocolo blockchain.

A principal dificuldade é convencer a rede, ou neste caso os nodes e as pessoas que gerem esses nodes, que a nova funcionalidade melhora de fato o protocolo. E depois é preciso convence-los a adoptar essa nova versão.

Continuemos com o exemplo. Depois de desenvolvida, a nova funcionalidade é divulgada pela rede. Metade dos nodes adoptou a nova versão e a outra metade preferiu continuar a utilizar a versão anterior.

Estamos perante um situação de Fork.

Um Fork acontece quando existe uma atualização de código do protocolo blockchain que é adoptada apenas por uma parte da rede. A outra parte continua a usar a versão anterior.

É importante saber que existem dois tipos de Forks. Na verdade três, mas já la vamos.

A pergunta que devemos fazer, antes de mais é: será tal situação possível?

Para responder, comecemos por analisar os dois principais tipos de Fork: Soft Forks e Hard Forks. (Em português Soft significa macio ou fácil e Hard significa duro ou difícil).

Soft Forks são atualizações ao protocolo blockchain que são compatíveis com versões anteriores. Isto é, a nova atualização sugerida permite que todos os nodes se continuem a comunicar, independentemente de adoptarem a nova versão ou não.

Assim, todos continuarão a fazer parte da mesma rede ou protocolo e cabe aos nodes decidirem que versão do protocolo preferem continuar a usar.

Para compreendermos melhor, pensemos por exemplo no processador de texto Word da Microsoft. Quando exportamos um documento podemos fazê-lo em vários formatos. Isto porque existem várias versões do software. No entanto, todas são compatíveis umas com as outras.

A ambição de cada atualização aos protocolos blockchain é, naturalmente, que toda a rede adopte essa atualização. No entanto, nem todos os nodes o fazem. Às vezes esquecem-se simplesmente, outras vezes não têm tempo, etc…

Numa situação de Soft Fork, temos nodes na rede que já adoptaram a nova atualização e outros que ainda não. Mas que ainda assim se conseguem comunicar, por isso o protocolo continua intacto e a funcionar normalmente.

Esta situação contrasta com uma situação de Hard Fork.

Hard Forks são atualizações ao protocolo blockchain que não são compatíveis com versões anteriores.

Quando temos um Hard Fork e apenas uma parte dos nodes decide adoptar a nova versão atualizada, temos uma situação em que se geram duas redes diferentes, porque os nodes de um lado e do outro já não se conseguem comunicar.

Os blocos minados na nova rede que adoptou a nova atualização, já não serão aceites na rede antiga e vice-versa.

Esta é uma questão muito sensível quando se fala de atualizações da rede ou do protocolo. Às vezes é necessário fazer um Hard Fork.

Algumas atualizações são de uma natureza tão específica e profunda que não conseguirão comunicar-se com versões anteriores. E então é necessário optar por um Hard Fork.

Hard Forks são naturalmente perigosos. Se por acaso parte da rede, da comunidade, não gostar da atualização, ela não será adoptada por todos. E então temos uma divisão da comunidade e do protocolo.

Algo importante a reter é que, numa situação destas, ambos os protocolos irão partilhar a mesma história até ao momento do Fork.

A partir do momento do Fork, o protocolo que adoptou a nova atualização começará a produzir blocos que são incompatíveis com a versão anterior – agora o antigo protocolo. E vice versa.

Esta situação pode ser comparada ao que aconteceu com o protocolo Bitcoin em Agosto de 2017, quando aconteceu o Hard Fork que gerou o protocolo Bitcoin Cash.

Outro aspeto importante a reter, é que numa situação de Hard Fork onde se gera uma nova moeda, os detentores da moeda original, recebem a mesma quantidade da nova moeda gerada.

Assim, se eu tivesse 10 BTC (Bitcoins) em Agosto de 2017, passava também a ter 10 BCH (Bitcoin Cash) depois do Fork.

Porquê?

Porque ambos os protocolos partilham a mesma história. E a história dos dois protocolos diz que na altura do Fork eu tinha 10 moedas. O protocolo Bitcoin “pensa” que eu tenho 10 moedas e o protocolo Bitcoin Cash também “pensa” que eu tenho 10 moedas.

Mas lembrem-se que agora eles são isolados e já não se comunicam. O que significa que se eu gastar, por exemplo, as 10 moedas no protocolo Bitcoin, o protocolo Bitcoin Cash não irá saber e continuará a “pensar” que eu ainda tenho 10 moedas. Por isso eu posso também gastar as minhas 10 moedas no protocolo Bitcoin Cash.

Saber isto é fundamental para compreendermos o conceito de Forks e percebermos porque recebemos a mesmo montante de moedas no novo protocolo que tinhamos no protocolo anterior.

Outro aspeto fundamental, é saber que as nossas private keys – as que tinhamos no protocolo inicial – controlam os mesmos addresses (endereços) em ambos os protocolos.

Antes do Fork, tinhamos um set de private e public keys que controlavam os nossos addresses. Bom, no novo protocolo, esses mesmos addresses também existem.

Assim, os addresses que existiam no protocolo Bitcoin antes de Agosto de 2017 passaram também a existir no protocolo Bitcoin Cash. O que significa que a nossa private key pode agora usar e gastar tanto BTC (Bitcoin) como BCH (Bitcoin Cash).

Por este motivo se diz que, se queremos realmente ter ou usar as moedas de um protocolo que surge depois de um Fork, devemos ter as nossas private keys.

Imaginemos que tinhamos 10 BTC numa exchange (bolsa) em Julho de 2017. Quando em Agosto aconteceu o Fork, estaríamos dependentes da “vontade” da exchange nos dar, ou não, as correspondentes 10 moedas Bitcoin Cash (BCH).

Assim, se tivermos a nossa private key e usarmos uma wallet teremos sempre o controle do nosso dinheiro numa situação de Fork.

(Para os que tiveram mais dificuldade em acompanhar esta última parte sobre keys e addresses sugiro que leiam o meu artigo sobre private keys e public keys. Igualmente, este tema será a base de um futuro post sobre Replay Attacks).

Importa reter que tudo o que até aqui foi mencionado sobre Forks se aplica a qualquer protocolo blockchain e não apenas ao protocolo Bitcoin.

Uma situação semelhante de Hard Fork aconteceu por exemplo com o protocolo Ethereum e o protocolo Ethereum Classic em 2015.

É também relevante perceber que nem todos os Hard Forks resultam numa separação da rede e da comunidade. Por vezes, Hard Forks são adoptados por todos e o protocolo evolui naturalmente sem separações.

Vamos agora finalmente abordar o terceiro tipo de Fork. Talvez já se tivessem esquecido.

Algumas pessoas dizem que o protocolo Litecoin é um Fork do protocolo Bitcoin. Não está totalmente errado.

Mas a verdade é que quem tinha BTC na altura do Fork, não recebeu quaisquer LTC (Litecoins).

Isto porque existem duas classes de Fork. A primeira classe foi a que explorámos até aqui. Trata-se de um Blockchain Fork e existem dois tipos como vimos: Hard e Soft Forks.

Como explicado, um Blockchain Fork pega na história inteira do protocolo e o novo protocolo continua a “construir” em cima dessa história.

No entanto, existe a outra classe: Source Code Forks.

Este tipo de Fork, pega no código-fonte (source code em inglês) do protocolo e modifica-o de acordo com as suas necessidades.

Foi isso que aconteceu no protocolo Litecoin. Foi utilizado o código-fonte do protocolo Bitcoin e foram feitas alterações. Não sendo mantida a história de transações do protocolo Bitcoin, ao contrario do que acontece com o protocolo Bitcoin Cash.

4 opiniões sobre “Forks do protocolo blockchain: Como surgiram Litecoin e Bitcoin Cash

  1. Muito boa explicação sobre a diferença entre “distribuído” e “descentralizado”. Para os mais distraídos, refiro que a compreensão desta simples diferença irá contribuir para perceber porque irá mudar o mundo na próxima década (financeiro, económico e político, por esta ordem); No fundo, a transformação do mundo tal como o conhecemos…

    Gostar

Deixe uma Resposta

Preencha os seus detalhes abaixo ou clique num ícone para iniciar sessão:

Logótipo da WordPress.com

Está a comentar usando a sua conta WordPress.com Terminar Sessão /  Alterar )

Google photo

Está a comentar usando a sua conta Google Terminar Sessão /  Alterar )

Imagem do Twitter

Está a comentar usando a sua conta Twitter Terminar Sessão /  Alterar )

Facebook photo

Está a comentar usando a sua conta Facebook Terminar Sessão /  Alterar )

Connecting to %s

search previous next tag category expand menu location phone mail time cart zoom edit close