A Guerra do OP_Return de 2014 – Dapps Vs Transações Bitcoin
Examinamos um debate sobre se e como um protocolo Dapp chamado Counterparty deveria usar o blockchain do Bitcoin. Isso foi às vezes chamado de "A Guerra OP_Return". Explicamos o histórico do uso do OP_Return e sidechains no Bitcoin.
Esse assunto foi comentado no EP #474 do Morning Crypto, explicando detalhadamente como se deu esse momento de tensão na comunidade do Bitcoin.
Alguns desejavam desenvolver soluções dentro do protocolo, outros preferiam que isso fosse desenvolvido externamente, seguindo a visão original de Satoshi Nakamoto.
Abaixo, segue a tradução do artigo feito pela Bitmex discutido nesse episódio.
BitMEX Research, 12 Jul 2022
Resumo: Neste artigo, exploramos por que os Dapps geralmente são construídos no Ethereum em vez de Bitcoin, o que nos leva de volta a março de 2014. Examinamos um debate sobre se e como um protocolo Dapp chamado Counterparty deveria usar o blockchain do Bitcoin. Isso foi às vezes chamado de "As Guerras OP_Return". Explicamos o histórico do uso do OP_Return e sidechains no Bitcoin. Concluímos argumentando, quer se goste ou não, que era a cultura na comunidade de desenvolvimento do Bitcoin em 2014 e a visão negativa de usar dados de transação do Bitcoin para casos de uso alternativos, que desempenhou um papel importante em empurrar os desenvolvedores desses Dapps para sistemas alternativos como o Ethereum, juntamente com outros fatores.
Visão Geral
Muitas vezes nos perguntaram: Por que Dapps como exchanges distribuídas estão tipicamente no Ethereum e não no Bitcoin? Afinal, certamente é possível construir Dapps, como exchanges distribuídas, sistemas de nomes ou tokens alternativos no Bitcoin. Existem, claro, várias razões para isso, como: i. A linguagem de script nativa mais flexível do Ethereum facilita a construção de Dapps, ii. O tempo de bloco mais rápido do Ethereum, tornando os Dapps mais amigáveis ao usuário, ou iii. O Bitcoin optando por uma restrição de tamanho de bloco mais conservadora do que o Ethereum, resultando em taxas potencialmente mais altas no Bitcoin. Todas as razões acima tiveram um impacto, mas muitas vezes esse impacto é exagerado em nossa opinião. O fator mais significativo é a cultura. Alguns entusiastas do Bitcoin e desenvolvedores simplesmente não queriam esse tipo de atividade na blockchain do Bitcoin e desencorajaram com sucesso. Isso parece ter ocorrido principalmente por volta de março de 2014, e o que aconteceu nesse período é o assunto deste artigo. Ao mesmo tempo, promotores de outras cadeias, como Ethereum, podem ter explorado e exagerado essa aparente postura dos desenvolvedores do Bitcoin para ajudar suas novas cadeias a ganhar tração.
O Protocolo Counterparty
Conforme mencionamos em nosso relatório de setembro de 2020, no início de 2014, o Counterparty foi lançado. Counterparty é uma camada de protocolo em cima do Bitcoin que permite recursos como a criação de novos tokens e a negociação desses tokens em uma exchange distribuída. O sistema funciona usando partes dos dados de transação do Bitcoin e utilizando isso no protocolo Counterparty, como uma função, como criar um token, enviar um token ou uma oferta de mercado em um token em uma exchange distribuída.
Mais concisamente, no início, o Counterparty usou o opcode do Bitcoin OP_CHECKMULTISIG para incluir dados relacionados ao Counterparty na blockchain do Bitcoin. Esse opcode deveria ser usado para verificar a assinatura de uma transação multi-assinatura de pagamento para script hash (P2SH). Um exemplo de uma transação Counterparty de julho de 2014 pode ser visto [aqui]. A transação envia Bitcoin de volta para o endereço de origem e também possui três saídas adicionais, onde os scripts de saída são dados relacionados ao protocolo Counterparty. Nesse caso, foi a criação de um novo token chamado TICKET. Usar o OP_CHECKMULTISIG pode ser visto como uma gambiarra, pois esse não era o uso pretendido do opcode. Atualmente, o Counterparty usa o opcode OP_Return do Bitcoin para armazenar dados, o que está mais alinhado com o que os desenvolvedores pretendiam, em certa medida. Por exemplo, veja esta transação Counterparty mais recente, que usa o OP_Return.
No início de 2014, houve considerável experimentação, atividade de desenvolvedor, inovação e entusiasmo em torno do Counterparty, que estava à frente de uma plataforma rival chamada Mastercoin.
O que é OP_Return?
OP_Return é uma saída de transação no Bitcoin que é comprovadamente não gastável. A função pode ser usada para "queimar" Bitcoin ou armazenar dados arbitrários na blockchain do Bitcoin. Como os dados não fazem parte do conjunto UTXO, armazenar dados dessa forma é dito ajudar na escalabilidade do Bitcoin, já que os nós que se envolvem na poda não precisam armazenar dados OP_Return.
As regras de consenso do Bitcoin permitem um tamanho OP_Return de até 10.000 bytes. Por exemplo, em maio de 2013, alguém tirou proveito dessa característica na seguinte transação. A saída OP_Return nesta transação contém a letra da música de 1987 “Never Gonna Give You Up” de Rick Astley, a canção relacionada ao meme Rickrolling.
Antes de 2014, transações contendo um OP_Return eram não-padrão e não eram transmitidas por nós ordinários do Bitcoin. No entanto, se um minerador incluísse essas transações, elas seriam consideradas válidas. Em março de 2014, o Bitcoin Core 0.9.0 foi lançado com o recurso OP_Return incluído como um tipo de transação padrão, portanto, as transações seriam transmitidas por padrão. As notas de lançamento na época diziam o seguinte:
Essa mudança não é um endosso ao armazenamento de dados na blockchain. A mudança OP_RETURN cria uma saída comprovadamente podável, para evitar esquemas de armazenamento de dados - alguns dos quais já estavam implantados - que estavam armazenando dados arbitrários, como imagens, como saídas de TX eternamente não gastáveis, inflando o banco de dados UTXO do Bitcoin. Armazenar dados arbitrários na blockchain ainda é uma má ideia; é menos custoso e muito mais eficiente armazenar dados não relacionados à moeda em outro lugar.
O Bitcoin Core 0.9.0 só transmitiria transações com um OP_Return de 40 bytes ou menos, se os dados fossem maiores que isso, ainda seria uma transação válida, mas não transmitida. O limite originalmente era para ser de 80 bytes, no entanto, após muita discussão, os desenvolvedores decidiram por 40 bytes. Para ser claro, o limite de retransmissão OP_Return em uma versão lançada do Bitcoin Core nunca diminuiu.
Em 2016, o Bitcoin Core 0.11.1 finalmente aumentou o limite de retransmissão para 80 bytes, o limite que temos hoje. Isso significa que, se alguém deseja uma transação com uma saída OP_Return de mais de 80 bytes hoje, tem que minerá-la por conta própria ou enviá-la diretamente a um minerador.
As Guerras OP_Return
Em 20 de março de 2014, um dos principais contribuintes do Bitcoin na época, Jeff Garzik, começou a postar no tópico do Counterparty no fórum Bitcointalk. Jeff estava criticando o uso do espaço da blockchain pelo Counterparty.
"Até o momento, não vi um esquema de descarregamento de dados de blockchain que não pudesse ser seguramente substituído por um hash simples. Você não precisa armazenar dados na blockchain. Isso é puramente preguiça intelectual. Carimbar hash(dados) é igualmente seguro, enquanto mais eficiente. Além disso, uma cadeia secundária pode ser comprovadamente vinculada ao bitcoin."
Jeff continuou:
"CheckMultiSig é claramente destinado a chaves públicas ECDSA, não a dados arbitrários. Não deveria ser surpresa que usar uma operação para algo diferente de seu propósito pretendido tenha consequências negativas, talvez não intencionadas ou desconhecidas. As transações do Counterparty não são 'de acordo com o protocolo bitcoin', elas passam porque nunca se esperava que o recurso fosse usado dessa forma."
Pode parecer estranho que Jeff tenha essa visão, dado que em 2017 ele parecia ser um "grande bloqueador" e que essa visão sobre o uso conservador do espaço do bloco não parece se reconciliar com a visão do grande bloco. No entanto, essa aparente contradição não apareceu em 2014. A visão de Jeff na época era compartilhada, em certa medida, por quase todos os desenvolvedores ativos na época, incluindo aqueles que mais tarde se tornaram grandes bloqueadores. Até onde podemos dizer, não havia uma correspondência simples entre a visão de alguém sobre o limite do tamanho do bloco e essa questão. Jeff era um desenvolvedor altamente respeitado na época e esta postagem foi uma grande preocupação para os desenvolvedores e usuários do Counterparty.
Um desenvolvedor do Counterparty, com o pseudônimo "BitcoinTangibleTrust", respondeu a Jeff da seguinte forma:
"Você está absolutamente certo. Você não precisa armazenar dados na blockchain. Carimbar hash(dados) é igualmente seguro, enquanto mais eficiente. Uma cadeia secundária pode ser comprovadamente vinculada ao bitcoin. No entanto, o Counterparty ESTÁ armazenando dados na blockchain usando 256 bytes em cada uma das transações multisig um-de-três, conforme nota de PhantomPhreak [o co-fundador e principal desenvolvedor do Counterparty] abaixo. Além disso, todas essas transações multisig são processadas pelos mineradores."
O desenvolvedor continuou criticando o plano dos desenvolvedores do Bitcoin de limitar o OP_Return a apenas 40 bytes em vez de 80:
"Se OP_RETURN era destinado a parar/limitar o comportamento multisig (Saídas Não Gastas) e reduzir o inchaço da blockchain, então temo que, ao reduzir o tamanho de OP_RETURN de 80 para 40 bytes, você inadvertidamente tornou o multisig MAIS ATRAENTE para todos os metaprotocolos e tornou o OP_RETURN menos atraente."
O principal desenvolvedor e co-fundador do Counterparty, conhecido como "PhantomPhreak", interveio:
"A ideia é que armazenamos os dados em uma segunda blockchain e colocamos hashes desses dados com carimbo de data/hora no Bitcoin, cujos hashes também seriam menores que 40 bytes. A razão pela qual não fizemos algo assim não é uma questão de 'preguiça intelectual', mas sim de complexidade de implementação. O Counterparty não é um projeto de ciência da computação; é projetado para ser o mais simples possível, pelos benefícios na velocidade de desenvolvimento. Mesmo que tenhamos que armazenar nossos dados em saídas multisig em vez das saídas OP_RETURN muito pequenas. Pior é definitivamente melhor neste espaço."
No dia seguinte, Jeff respondeu:
"Isso é chamado de carona. Dado que a vasta maioria — >90% — da aplicação para a blockchain do bitcoin é o uso de moeda, usar nós completos como terminais de armazenamento de dados burros é simplesmente abusar de um recurso de rede totalmente voluntário. A rede replica dados de transação, então por que não aproveitar uma carona? Em vez de envolver a comunidade existente, a mastercoin e o counterparty simplesmente ligaram um interruptor 'ligado' e começaram a usar os nós P2P do bitcoin como lojas de dados indesejadas. Uma saída de transação não gasta nunca foi destinada a ser usada como armazenamento de dados arbitrário. O fato de poder ser abusada como tal não a torna correta, ou remotamente eficiente, ou a melhor solução. O banco de dados UTXO (saída de transação não gasta) é o banco de dados de acesso rápido de toda a rede. Cada nó precisa que esse banco de dados seja o menor possível, para melhor processamento de transações de rede. Codificar dados arbitrários em saídas não gastas é abuso em toda a rede, pura e simplesmente. Toda a rede suporta o custo."
Devido ao alto status de Jeff na comunidade, a maioria das pessoas na comunidade Counterparty parecia disposta a se engajar e resolver o problema. Por exemplo, BitcoinTangibleTrust respondeu dizendo:
"Acho que as preocupações do jgarzik são muito válidas e acho que PhantomPhreak entende muito bem as implicações para o projeto Counterparty se o Bitcoin estabelecer um limite de 40 bytes para OP_RETURN ou pior. PhantomPhreak, não ficaria ofendido se você simplesmente oferecesse ao jgarzik uma recompensa por ajudá-lo a implementar uma solução temporária até que algo mais elegante seja encontrado."
PhantomPhreak, por sua vez, reconheceu a perspectiva de Jeff:
"Claro, a comunidade tem o direito de dizer que não queremos que a blockchain do Bitcoin seja usada dessa maneira, mas pessoalmente, vejo o Counterparty e projetos similares como um benefício líquido para o Bitcoin, já que trazem novos usos e usuários para a rede."
Ao mesmo tempo, muitos na comunidade Counterparty sentiram que estavam sendo injustamente alvo, pois outras práticas, como "dusting attacks" (ataques de poeira, em que pequenas quantidades de bitcoins são enviadas a um grande número de endereços, geralmente com a intenção de desanonimizar os usuários), eram igualmente ineficientes, mas não estavam recebendo o mesmo nível de crítica.
Jeff Garzik respondeu com um argumento econômico:
"As transações Counterparty e similares são freeriders (caronas) no sentido econômico. Eles consomem recursos da rede sem contribuir de volta. Eles tornam o node mais caro de operar, enquanto dão pouco ou nenhum retorno."
Outros usuários, como o membro "brg444", concordaram com Jeff:
"Não posso enfatizar o suficiente como é importante não abusar da blockchain do Bitcoin para fins que não sejam a moeda em si. Por que você não consideraria fazer sua própria blockchain?"
Contudo, o debate em torno do uso de OP_RETURN e a decisão dos desenvolvedores do Bitcoin de limitá-lo a 40 bytes tornou-se muito mais do que uma simples questão técnica. Para muitos, tornou-se um debate filosófico sobre a natureza e propósito da blockchain do Bitcoin.
Algumas semanas após o início desta discussão, os desenvolvedores do Bitcoin lançaram uma nova versão do software que limitava o OP_RETURN a 40 bytes. Para o Counterparty e outros projetos que confiavam no OP_RETURN, isso representou um desafio significativo. Eles tiveram que adaptar-se, seja reduzindo a quantidade de dados que armazenavam no blockchain do Bitcoin, mudando sua abordagem ou buscando outras soluções.
O debate sobre o OP_RETURN destaca uma tensão fundamental no desenvolvimento de blockchain e criptomoedas: a interação entre as considerações técnicas e as filosóficas. O tamanho do OP_RETURN é apenas uma das muitas questões técnicas que os desenvolvedores enfrentam, mas as implicações dessa decisão se estendem muito além do código.
No final, a "guerra" OP_RETURN foi apenas um capítulo em uma história em constante evolução sobre como a tecnologia blockchain deve ser usada e quem deve tomar essas decisões.
Merge Mined Sidechains
Ao longo do debate OP_Return, oponentes do Counterparty e bloat na blockchain normalmente mencionaram alguma forma de sidechains mineradas em conjunto como uma solução para Dapps. De fato, diz-se que Satoshi favoreceu esse caminho e apoiou-o para um sistema de nome de domínio em dezembro de 2010:
"Acredito que seria possível para o BitDNS ser uma rede completamente separada e uma blockchain separada, e ainda assim compartilhar o poder de CPU com o Bitcoin. A única sobreposição é tornar possível para os mineradores procurar provas de trabalho para ambas as redes simultaneamente."
Há muitas dificuldades em implementar esses sistemas Dapp como sidechains e nosso entendimento dessas fraquezas é melhor compreendido hoje do que era em 2014, quando muitas pessoas simplesmente assumiram que eles poderiam funcionar.
Complexidade - Uma das fraquezas mais significativas é a complexidade na implementação e construção de soluções de sidechain. Na corrida para colocar o protocolo em funcionamento e ganhar participação de mercado, esses projetos não tiveram tempo de construir uma sidechain e o sistema de mineração conjunta com o Bitcoin.
Bitcoin como um ativo nativo - Pode não ser possível ter Bitcoin não custodial como um ativo operacional em uma sidechain, porque um peg bidirecional sem confiança pode não ser possível de construir. Esta é uma grande fraqueza para muitos Dapps que talvez queiram usar o Bitcoin como o principal par de negociação em uma bolsa distribuída. Esta fraqueza não parecia ser bem compreendida em 2014, com muitas pessoas apenas supondo que poderia funcionar de alguma forma.
Benefícios de escala limitados - Os benefícios de usar uma sidechain podem variar dependendo do caso de uso. Por exemplo, se alguém quiser construir uma bolsa distribuída, cada lance, oferta e correspondência pode exigir todas as garantias de segurança da cadeia principal. Com este uso tão intenso da cadeia principal, para cada ação possível de cada usuário na bolsa, as vantagens de escala do sistema de sidechain podem ser extremamente limitadas. Enviar um lance na cadeia nativamente pode usar apenas cerca de 90 bytes, enquanto armazenar um hash da informação da ordem e a estrutura e sobrecarga ao redor dela necessária para ser identificada pode ser cerca de 50 bytes na cadeia, então não há muita economia de espaço.
Em março de 2014, o desenvolvedor do Counterparty (xnova) detalhou sua oposição ao ponto de sidechains como segue:
"Além disso, a menos que eu esteja negligenciando algo aqui, ainda precisaríamos extrair os dados dos blocos dessa segunda blockchain (assumindo que é uma implementação Bitcoin ou derivada do Bitcoin) para obter nossos dados armazenados. Portanto:
1 não permitiria clientes Counterparty tipo SPV para o que Counterparty oferece sobre a funcionalidade Colored Coin (ou seja, DEx, Betting, callbacks de ativos, dividendos, CFDs, etc.)
2 diminuiria a segurança das transações Counterparty.
aumentaria muito a complexidade da implementação (ou seja, aumentando a chance de bugs e vulnerabilidades)
3 O único benefício duvidoso seria a ligeira redução de nossos requisitos de armazenamento na blockchain (ou seja, talvez 20-40 bytes a menos por transação?). Eu simplesmente não vejo como isso faria algum sentido aqui."
"Um ponto adicional: o Counterparty pode trazer imensos benefícios para o Bitcoin, e isso se tornará especialmente mais evidente se/à medida que o Ethereum (e outras moedas semelhantes do tipo "2.0" não-meta-Bitcoin) entrar em cena. Meu sentimento pessoal aqui é que o Bitcoin pode muito bem precisar de ofertas no ecossistema com esse tipo de funcionalidade para competir efetivamente com a lista de características e atrações do Ethereum e da (futura) multidão — ou correr o risco de se tornar obsoleto, pelo menos entre investidores e operadores de mercado financeiro, que oferecem a capacidade de trazer bilhões e até trilhões para o ecossistema Bitcoin à medida que ganha mais reconhecimento, confiança e presença de espírito com eles."
É evidente que muitos desenvolvedores e usuários do Counterparty ficaram surpresos e desapontados com a postura dos desenvolvedores do Bitcoin. Embora o projeto tenha continuado, assim como o Mastercoin, é provável que, para melhor ou para pior, alguns desenvolvedores tenham abandonado o Bitcoin como resultado disso e, em vez disso, construído seus protocolos em outros sistemas de blockchain, como o Ethereum. É esse momento de 2014 que foi, em nossa opinião, mais significativo do que qualquer outro. No entanto, outros podem ter uma visão diferente.
Conclusão
Após 2014, a maioria dos desenvolvedores interessados em Dapps focou na construção no Ethereum ou em outros sistemas, e não no Bitcoin. O Ethereum então alcançou uma massa crítica de interesse e impulso dos desenvolvedores, e o desenvolvimento de Dapp no Bitcoin foi mínimo. O ponto principal deste artigo é enfatizar que o principal motor para isso não foi necessariamente taxas ou a máquina virtual do Ethereum e suas capacidades técnicas mais fortes, é simplesmente que muitos Bitcoiners e desenvolvedores do Bitcoin não queriam Dapps no Bitcoin e não estavam interessados nestas funcionalidades. Para melhor ou pior, alguns Bitcoiners deliberadamente afastaram muitos desses desenvolvedores de Dapp. Alguns Bitcoiners acreditam que a maior parte da atividade Dapp está relacionada a golpes insustentáveis ou que essa atividade é indesejável no Bitcoin por razões de segurança ou outras. Ao mesmo tempo, alguns promotores de moedas alternativas (por exemplo, Ethereum) podem ter exagerado o impacto e a importância das chamadas "OP_Return Wars", para impulsionar suas novas cadeias.
As visões de muitas pessoas mudaram desde 2014. Bitcoin precisa de taxas de transação para sobreviver. No ambiente pós-2016, no qual temos muitos blocos completos e taxas um pouco mais altas, é mais amplamente apreciado que qualquer transação que pague uma taxa é "legítima". Certos Dapps no Ethereum, como bolsas como Uniswap, ou protocolos de empréstimo como AAVE e Compound provaram ser bem-sucedidos e interessantes, até certo ponto. Apesar disso, se os Bitcoiners até se importam o suficiente para querer esses protocolos no Bitcoin, e muito menos se alguém realmente vai construí-los e usá-los, permanece uma questão em aberto.
