Qual a diferença entre SegWit e Native SegWit? Tanto os endereços SegWit quanto os endereços Native Segwit (Bech32) nasceram com a atualização da SegWit em 2017. Eles são fáceis de distinguir, pois um começa com o número 3 e o outro, com bc1.
No entanto, existem algumas diferenças significativas entre cada um deles, as quais é importante entendermos.
Portanto, quando a atualização da SegWit foi implementada, surgiram dois tipos de endereços.
O primeiro foi o endereço SegWit, ainda com uma codificação semelhante à dos endereços anteriores. O segundo foi o Native SegWit, também chamado de Bech32, por utilizar esse novo formato de codificação.
Neste artigo, vamos entender cada um deles, suas diferenças e como funcionam.
Quais os tipos de endereço SegWit?
Com a implementação da SegWit na rede em 2017, uma proposta do desenvolvedor Pieter Wuille, surgiram dois tipos de endereços: Nested SegWit (P2SH) e Native SegWit (Bech32).
Esta atualização visava melhorar a escalabilidade, a maleabilidade e as taxas de transação da rede, que na época enfrentava altas taxas e lentidão na confirmação das transações.
A solução adotada pela SegWit foi separar os dados de assinatura das transações, que tornavam as transações pesadas e ocupavam muito espaço nos blocos, contribuindo para as altas taxas.
Assim, os dados de assinatura foram alocados em outra camada, resultando em transações mais leves.
Portanto, a partir dessa atualização, dois endereços surgiram:
- Nested SegWit (P2SH), que mantém alguma compatibilidade com sistemas mais antigos
- Native SegWit (Bech 32), que utiliza um formato de codificação mais eficiente e oferece taxas ainda menores.
Bora entender mais sobre eles?
O que são endereços Nested SegWit (P2SH)?
Os endereços Nested SegWit são endereços Bitcoin que combinam funcionalidades do SegWit com compatibilidade com endereços mais antigos, utilizando um script “Pay to Script Hash” para maior segurança e privacidade nas transações.
Eles foram introduzidos de maneira que a SegWit pudesse ser utilizada mesmo com endereços no formato antigo. Por isso, eles são denominados “Nested” (aninhados).
Isso significa basicamente que, em um endereço comum, existem algumas configurações SegWit para que ele possa ser compatível com esse novo formato.
Os endereços P2SH utilizam um script “Pay to Script Hash“, no qual o pagamento é direcionado para o hash (identificador) do endereço e não para a chave pública diretamente. Isso impede que a chave privada seja descoberta através da chave pública e confere mais privacidade à transação.
O Bitcoin funciona por meio de scripts, que são códigos que determinam como algo funcionará na rede. Nesse caso, o P2SH especifica como a transação funcionará e como os bitcoins transacionados podem ser gastos.
Características de endereços SegWit (P2SH)
Os endereços SegWit (P2SH) caracterizam-se pelo uso da codificação de base 58, excluindo caracteres confundíveis como 0, O, I, l, e os símbolos “+” e “/” e começam com o número 3.
Portanto, esses tipos de endereços ainda utilizam a codificação padrão introduzida por Satoshi Nakamoto, que é a base 58.
As codificações em computação servem para representar números grandes e longos, de maneira alfanumérica. Ou seja, essa codificação representa de uma forma legível os endereços de bitcoin que conhecemos hoje.
Sendo assim, elas possuem algumas características, como:
- Utilização de letras maiúsculas e minúsculas do alfabeto;
- Omissão de caracteres que podem ser confundidos, como o 0 (zero), O (letra O maiúscula), I (letra i maiúscula) e l (letra L minúscula), além dos símbolos “+” e “/”;
- Facilidade de leitura;
- Representação compacta;
- Detecção de erros;
- Prevenção de erros.
Além disso, como vimos acima, os endereços SegWit começam com o número 3.
Apesar de os endereços introduzidos pela SegWit terem melhorado diversos aspectos em comparação aos endereços anteriores, eles ainda possuíam algumas limitações. Por isso, surgiram os endereços Bech32 (ou Native SegWit).
O que são endereços Native SegWit (Bech 32)?
Endereços Native SegWit (Bech32) são um tipo de endereço Bitcoin, identificados por começarem com “bc1”, que oferecem eficiência aprimorada, taxas mais baixas e maior segurança de transação.
Esse é um dos endereços mais recentes da rede Bitcoin e é o endereço nativo da SegWit. Ou seja, ele foi desenvolvido especificamente para a atualização SegWit.
É por meio dele que as transações se tornaram mais leves, com taxas menores e menor risco de erro. Esse endereço possui uma função que permite identificar se há algum erro de digitação e, até mesmo, localizar onde o erro ocorreu.
Portanto, para que a SegWit fosse implementada com sucesso e os problemas a que se propôs resolvessem de fato, foi necessária a criação de um endereço completamente novo.
Foi a partir dessa necessidade da rede que surgiu o endereço Native SegWit, com a codificação Bech32.
Características de endereços Native SegWit (Bech 32)
A principal característica de um endereço Native SegWit é que ele utiliza a codificação Bech32. Essa nova forma de codificar endereços no Bitcoin permitiu que a SegWit fosse extremamente eficiente.
A Bech32 foi desenvolvida para resolver alguns problemas da codificação base 58, como:
- Ocupar muito espaço em QR Codes;
- Ser difícil de digitar devido ao uso de letras maiúsculas e minúsculas;
- Não ser totalmente eficiente na identificação de erros;
- A decodificação de base 58 é lenta e complicada.
Assim, a Bech32 resolve todos esses problemas, sendo mais eficiente na identificação de erros de digitação e tornando as transações ainda mais leves e rápidas.
Além disso, essa implementação também possibilitou a codificação de faturas Lightning.
Endereços NativeSegwit começam com “bc1…” e os endereços Lightning geralmente começam com “ln1…”.
Qual a diferença entre SegWit e Native SegWit (Bech 32)?
As principais diferenças entre os dois são que o SegWit (P2SH) usa codificação base 58, começa com 3 e ocupa 267 vBytes, já o Native SegWit usa codificação Bech32, começa com “bc1”, ocupa 211 vBytes e tem melhor detecção de erros.
Portanto, apesar de os dois endereços (P2SH e Bech32) fazerem parte da mesma atualização (SegWit), eles possuem algumas diferenças bem significativas.
Endereços SegWit (P2SH)
- Utilizam codificação de base 58;
- Possuem caracteres alfanuméricos com letras maiúsculas e minúsculas;
- Começam com o número 3;
- São menores que os endereços anteriores (Legacy);
- São um formato aninhado em outros endereços que usam um script SegWit;
- Ocupam 267 vBytes de espaço no bloco.
Endereços Bech 32 (Native SegWit)
- Utilizam codificação Bech32;
- Possuem apenas caracteres alfanuméricos com letras minúsculas;
- Começam com “bc1…”;
- Conseguem identificar erros de digitação e onde ocorreram;
- São menores, ocupando menos espaço no bloco;
- Ocupam 211 vBytes de espaço no bloco.
Leia também: o que é Taproot?
Conclusão
Como vimos, ambos os endereços são parte da atualização SegWit. O endereço Nested SegWit (P2SH) foi implementado em endereços já existentes para que pudessem ter um script SegWit e fossem mais eficientes.
Já os endereços Native SegWit foram o formato introduzido por padrão na atualização SegWit. Esse endereço permitiu as melhorias que a rede possui hoje em termos de escalabilidade, maleabilidade e redução de taxas.
É importante ressaltar que os endereços Native SegWit ainda são muito novos e nem todas as carteiras e aplicações suportam esse formato. No entanto, eles são os mais seguros e eficientes atualmente.
Com a ampla adoção do Bitcoin ao longo do tempo, é provável que mais carteiras, exchanges e outras aplicações passem a suportar endereços Bech32.
Além disso, novas atualizações podem surgir a partir desses endereços, por isso é importante entender como funcionam hoje e como podem evoluir no futuro.
Espero que este artigo tenha sido útil. Não deixe de compartilhá-lo com um amigo e até a próxima!
Compartilhe em suas redes sociais:
Fundadora da Area Bitcoin, um dos maiores projetos de educação de Bitcoin do mundo, publicitária, apaixonada por tecnologia e mão na massa full time. Já participou das principais conferências de Bitcoin como Adopting, Satsconf, Surfin Bitcoin e Bitcoin Conference.
Curtiu esse artigo? Considere nos pagar um cafezinho para continuarmos escrevendo novos conteúdos! ☕
