A discussão sobre a escalabilidade do Bitcoin ainda não está definida, então muitos defendem e atacam às soluções. Agora é a vez de Jimmy Song (desenvolvedor Bitcoin) que acrescentou ao debate do SegWit sugerindo que a tecnologia entrante torna o tamanho do “peso dos blocos” menos relevante e com isso teríamos no futuro blocos com mais de 2MB. Uma possível confusão nos espera dia 1 de agosto, vamos aqui analisar o que Jimmy quis dizer.
One criticism: Lack of discussion about the -rate of adoption-, which is central to misleading "SegWit = 2M block size" claims.
— Jeff Garzik (@jgarzik) July 4, 2017
O desenvolvedor principal do Bitcoin Luke-jr sinalizou uma forte oposição ao SegWit2x, lançando uma matéria no medium dele. Alguns mineradores e desenvolvedores tomam partido ao invés de aprofundar o lado técnico do que SegWit e SegWit2x significam para o futuro da rede. Vamos aqui abordar do que eles estão falando:
Entendendo tamanho do bloco e soft fork
Para falar com precisão sobre “pesos de blocos”, é importante entender o que é tamanho (peso) do bloco e como ele é calculado. O tamanho do bloco é simplesmente equivalente em bytes do bloco serializado (cabeçalho do bloco, número da transação e as próprias transações).
Como parte das regras de consenso, cada nó (node) na rede Bitcoin verifica atualmente que um bloco é inferior a 1.000.000 de bytes = 1MB. Ou seja, um bloco que é superior a 1MB será rejeitado por esses nós como uma regra de consenso.
Como os legacy nodes (ou “nós legados” – isto é, nós que não se atualizam dia 1º de agosto) rejeitarão um bloco superior a 1.000.000 de bytes, qualquer soft fork deve manter essa regra. Mas como você pode aumentar o peso do bloco e ainda manter essa regra? É possível que o peso dos blocos ficam maiores através de um soft fork? Aí que entra a solução do SegWit.
O fato é que isso pode ser feito como um soft fork e permitir mais transações é um avanço da engenharia. A visão chave é que uma grande parte da transação, o scriptSig (assinatura, pubkey, etc.), não podem ser enviados aos nós legados e ainda serem contados como válidos mas devido ao BIP143 que define novas saídas de transações que fazem exatamente isso. P2wpkh e p2wsh são muito semelhantes aos p2pkh e p2sh, respectivamente, mas movem os dados scriptSig até o final da transação.
As transações sem Segwit (definidas como transações apenas passando saída não Segwit: como p2pk, p2pkh e p2sh) colocam o scriptSig no meio da transação. As transações em Segwit (definidas como transações que gastam pelo menos uma saída p2wpkh ou p2wsh) colocam o scriptSig no final.
Assim a parte das transações que dizem respeito ao SegWit é chamada de “dados da testemunha”. Quando as transações Segwit são enviadas há nós legados, os dados da testemunha são descartados. A chave desse processo é que essas transações mesmo com partes “descartadas” ainda são transações válidas aos legados, o que dá uma economia em relação às transações não SegWit. Assim, mais transações podem caber no bloco enviado aos nós legados sem ultrapassar o limite de 1MB.
Os nós que adotarem o SegWit obtêm transações e blocos Segwit que incluem os dados da testemunha usando mensagens de rede alternativas. As novas mensagens de rede são definidas no BIP144 como parte do Segwit. Os blocos Segwit, que incluem os dados da testemunha, podem ter mais de 1MB. Os nós legados, como mencionado a cima recebem os mesmos blocos e transações, mas com os dados da testemunha despojados. Esta é uma maneira de fazer do Segwit com um soft fork.
Limites dos blocos SegWit
Os criadores da solução SegWit poderiam ter deixado os blocos de Segwit serem tão grandes quanto desejassem e o Segwit ainda seria um soft fork, desde que os peso dos blocos enviados aos nós legados ainda fossem menores que 1MB. Mas ao invés de deixarem aberto, o que parece óbvio para evitar que tenhamos volumes imensos de dados no SegWit muito maiores que os que transitamos nos blocos, eles apresentaram uma restrição diferente baseada em Block Weight (Peso dos Blocos) que é um novo conceito introduzido no Segwit, assim é calculado por transação. Cada transação tem um “peso” definido dessa maneira:
(Tamanho de transação sem dados de testemunha) * 3 + (Tamanho original da transação)
Aplicando o que falamos anteriormente as transações não SegWit têm zero dados de testemunhas, portanto, o peso de uma transação não SegWit é exatamente 4 vezes o tamanho. As transações Segwit possuem alguns dados de testemunhas para que o peso seja menor que 4 vezes o tamanho. Nota as transações Segwit são transmitidas para nós legados sem dados de testemunhas, então esta fórmula sempre resultará em peso dos blocos comunicados aos Números Legados que são menores ou iguais a 1MB. Novamente, é por isso que o Segwit é um soft fork.
Peso dos blocos
Em vez da regra de consenso anterior (legado) que afirmou que um peso dos blocos não pode ser mais de 1MB, a nova e mais apertada regra de consenso é que o peso dos blocos total permitido para qualquer bloco é de 4MB. Observe que, se você preencher um bloco com apenas transações não SegWit.
Assim, podemos dizer que a capacidade de transação do bloco de transações não SegWit é a mesma que antes do SegWit. Ou seja, você não pode preencher blocos Segwit com transações não Segwit e ter mais de 1MB. Isso ocorre porque o peso da transação não SegWit é diretamente proporcional ao seu tamanho. As transações de não Segwit de 1000 bytes terão sempre um peso de 4000, independentemente da composição da transação.
Este não é o caso das transações Segwit. As transações Segwit de 1000 bytes podem ter muitos peso dos blocos diferentes, dependendo de quanto da transação é ocupada pelos dados da Testemunha. Considere duas transações diferentes:
- Uma transação Segwit de 1000 bytes com 500 bytes de dados de testemunha
- Uma transação Segwit de 1000 bytes com 300 bytes de dados de testemunha
O primeiro teria um peso de 500 * 3 + 1000 = 2500, enquanto o segundo teria um peso de 700 * 3 + 1000 = 3100. Do ponto de vista de um mineiro, se ambas as transações tivessem a mesma taxa, eles ganhariam mais dinheiro incluindo a transação anterior, uma vez que ocupa menos peso em um bloco, apesar do mesmo tamanho.
Da mesma forma, as transações de diferentes tamanhos podem ter o mesmo peso. Considere 3 transações diferentes:
- Uma transação Segwit de 800 bytes com 400 bytes de dados da Testemunha
- Uma transação Segwit de 1100 bytes com 800 bytes de dados da Testemunha
- Uma transação sem segmentos de 500 bytes
Todas essas transações têm o mesmo peso exato de 2000. Quando serializados para um nó legado, serão 400 bytes, 300 bytes e 500 bytes, respectivamente (tamanho transação sem dados de testemunhas). Quando serializados para um nó SegWit, eles serão de 800 bytes, 1100 bytes e 500 bytes, assim respectivamente.
Neste ponto, você pode estar se perguntando o quanto a Witness Data estará em uma transação típica da Segwit. Isso depende do número de entradas p2wpkh ou p2wsh, mas a grosso modo, as transações Segwit são cerca de 2/3 dos dados da testemunha.
Segwit2x
O que Segwit2x faz é aumentar o peso máximo do bloco para 8MB. Ao fazê-lo, isso aumenta a Capacidade de transação não Segwit em um determinado bloco para 2MB. Ou seja, basicamente atualiza o tamanho do bloco “legado” para 2MB. Agora, o termo “legado” não faz sentido pois estamos em um cenário de hard fork (cada nó precisa atualizar, portanto, não há mais um ramo “legado”).
Mas os meus manifestantes têm um ponto, o tamanho do peso dos blocos Segwit (o único tamanho de bloco realmente deixado depois de um hard fork, pois não há nós legado) tem um máximo de 8MB após o forquilha planejado no Segwit2x. O caso normal é mais como 4MB.
Conclusão
Concordando com Jeff Garzik, é necessário uma maior discussão sobre o SegWit e SegWit2x, pois muitos mineradores estão sinalizando que vão com o SegWit2x, mas como vimos não existe um SegWit2x sem um hard fork. Relembro que os mineradores tendem a minerar os blocos mais lucrativos primeiros. Pelo visto nada esta 100% definido e muitas discussões virão.
Fiquem ligados aqui no Criptomoedas Fácil para mais novidades sobre esse assunto.