O debate ;OP_RETURN; em ;2014; foi uma divisão notável dentro da indústria e tem muitas semelhanças com o debate ;Ordinal; de hoje. Olhando para trás, o debate ;OP_RETURN; é particularmente significativo hoje.
Alguns entusiastas de bitcoin e desenvolvedores de bitcoin que simplesmente não querem esse tipo de atividade na blockchain do bitcoin bloquearam com sucesso;OP_RETURN;esse tipo de atividade. Enquanto isso, os promotores de outras cadeias como a Ethereum podem ter aproveitado e exagerado essa aparente postura dos desenvolvedores de Bitcoin para ajudar seu ecossistema a ganhar força.
Visão geral
Muitas vezes nos perguntam: por que Dapps, como trocas descentralizadas, geralmente no Ethereum em vez de Bitcoin? Afinal, é claro que é possível construir Dapps em cima do Bitcoin, como trocas descentralizadas, sistemas de nome de domínio ou tokens alternativos. É claro que existem 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. Os tempos de bloco mais rápidos do Ethereum tornam os Dapps mais fáceis de usar ou iii. Limites de tamanho de bloco mais conservadores do que o Ethereum , resultando em taxas potencialmente mais altas para o Bitcoin. Todos os fatores acima têm um impacto, mas acreditamos que seu impacto é frequentemente superestimado. O fator mais importante é a cultura. Alguns entusiastas de bitcoin e desenvolvedores de bitcoin simplesmente não querem tal atividade na blockchain do bitcoin e a bloquearam com sucesso. Isso parece ter acontecido principalmente por volta de março de 2014, e o que aconteceu nessa época é o assunto deste artigo. Enquanto isso, os promotores de outras cadeias como a Ethereum podem ter aproveitado e exagerado essa aparente postura dos desenvolvedores de Bitcoin para ajudar seu ecossistema a ganhar força.
Protocolo de contraparte
Conforme mencionado em nosso relatório de setembro de 2020, no início de 2014, a Counterparty foi lançada. A contraparte é uma camada de protocolo sobre o Bitcoin que permite recursos como a criação de novos tokens e a negociação desses tokens em trocas distribuídas. O sistema funciona pegando partes dos dados de transação de bitcoin e usando-os em acordos de contraparte como uma função, como criar tokens, enviar tokens ou fazer lances de mercado para tokens em uma bolsa distribuída.
Mais sucintamente, no início, o Counterparty incluiu dados relacionados ao Counterparty no blockchain do Bitcoin usando o opcode do Bitcoin OP_CHECKMULTISIG. Este opcode deve ser usado para verificar a assinatura de uma transação multi-assinatura Payment Script Hash (P;2 SH). Uma amostra de transação da Counterpaty de julho de 2014 pode ser visualizada aqui. A transação envia o bitcoin de volta para o endereço de onde veio e também possui três saídas adicionais, onde o script de saída são dados relacionados ao contrato da contraparte. Neste caso, ele está criando um novo token chamado TICKET. O uso de OP_CHECKMULTISIG pode ser considerado um hack, pois esse não é o uso pretendido do opcode. A contraparte agora usa o opcode OP_Return do Bitcoin para armazenar dados, o que está um pouco mais de acordo com a intenção do desenvolvedor. Por exemplo, veja esta transação de contraparte atualizada que usa OP_Return.
No início de 2014, houve muita experimentação, atividade de desenvolvedores, inovação e empolgação em torno da Counterparty, à frente de uma plataforma rival chamada Mastercoin.
O que é OP_Return?
OP_Return é uma saída de transação comprovadamente não gastável em Bitcoin. Esse recurso pode ser usado para gravar bitcoins ou armazenar dados arbitrários na blockchain do bitcoin. Como os dados não fazem parte do conjunto UTXO, diz-se que armazenar dados dessa maneira ajuda a dimensionar o Bitcoin porque os nós que participam da poda não precisam armazenar dados OP_Return.
As regras de consenso do Bitcoin permitem um tamanho máximo de OP_Return de 10.000 bytes. Por exemplo, em maio de 2013, esse recurso foi explorado na seguinte transação. A saída OP_Return nesta transação contém a letra da música "Never Gonna Give You Up" de Rick Astley, de 1987, que está relacionada ao meme Rickrolling.
Antes de 2014, as transações contendo OP_Return não eram padrão e não eram retransmitidas por nós Bitcoin normais. No entanto, se os mineradores incluírem essas transações, elas serão consideradas válidas. Em março de 2014, foi lançado o Bitcoin Core 0.9.0, que incluiu a função OP_Return como um tipo de transação padrão, portanto, as transações serão retransmitidas por padrão. As notas de lançamento na época eram as seguintes:
Essa mudança não é um endosso ao armazenamento de dados na blockchain. A alteração OP_RETURN cria saídas comprovadamente passíveis de remoção para evitar esquemas de armazenamento de dados (alguns dos quais já implantados) que armazenam dados arbitrários (como imagens) como saídas TX que nunca estão disponíveis, inchando o banco de dados UTXO do Bitcoin. Armazenar dados arbitrários no blockchain ainda é uma má ideia; é mais barato e mais eficiente armazenar dados não monetários em outro lugar.
fonte:
O Bitcoin Core 0.9.0 só retransmitirá transações com OP_Return de 40 bytes ou menos, se os dados forem maiores que isso, ainda será uma transação válida, mas não será retransmitida. O limite original era de 80 bytes, mas depois de muito debate, os desenvolvedores decidiram por 40 bytes.
Em 2016, o Bitcoin Core 0.11.1 finalmente aumentou o limite de retransmissão para 80 bytes e, no final de 2016, no lançamento do Bitcoin Core 0.12.0, aumentou para 83 bytes, nosso limite hoje. Isso significa que se você deseja uma transação com uma saída OP_Return de mais de 83 bytes hoje, você mesmo deve minerar o bloco ou enviá-lo diretamente ao minerador.
OP_Guerra do Retorno
Em 20 de março de 2014, Jeff Garzik, então um dos principais colaboradores do Bitcoin, começou a postar no fórum Counterparty no fórum Bitcointalk. Jeff criticou o uso do espaço blockchain pela Counterparty.
Até o momento, não vi um esquema de despejo de dados blockchain que não possa ser substituído com segurança por um hash simples. Você não precisa armazenar dados no blockchain. Isso é pura preguiça intelectual. Os hashes (dados) com carimbo de data/hora são tão seguros quanto mais eficientes. Além disso, uma cadeia secundária pode ser comprovadamente atrelada ao Bitcoin:
fonte:
Jeff continuou dizendo:
CheckMultiSig obviamente funciona com chaves públicas ECDSA, não com dados arbitrários. Não deveria ser nenhuma surpresa que usar uma operação para algo diferente do propósito pretendido pode ter consequências negativas, possivelmente não intencionais ou desconhecidas. As transações de contraparte não são "de acordo com o protocolo Bitcoin", elas passam porque nunca foi esperado usar o recurso dessa forma.
fonte:
Alguém pode achar estranho que Jeff tenha essa visão, já que ele parece ser um "apoiador do grande bloco" em 2017, e essa visão do uso conservador do espaço do bloco parece estar em desacordo com a visão do grande bloco. No entanto, essa aparente inconsistência não surgiu em 2014. Naquela época, as opiniões de Jeff eram até certo ponto reconhecidas por quase todos os desenvolvedores ativos da época, incluindo aqueles que mais tarde se tornaram chefes de grandes blocos. Tanto quanto sabemos, simplesmente não existe um mapeamento simples entre as percepções das pessoas sobre os limites de tamanho de bloco e esta questão. Jeff era um desenvolvedor muito respeitado na época, e este artigo chamou muita atenção dos desenvolvedores e usuários da Counterparty.
Um desenvolvedor de contraparte com o pseudônimo "BitcoinTangibleTrust" respondeu a Jeff da seguinte forma:
Você está absolutamente certo. Você não precisa armazenar dados no blockchain. Os hashes (dados) com carimbo de data/hora são tão seguros quanto mais eficientes. Uma cadeia secundária pode ser comprovadamente atrelada ao Bitcoin. No entanto, de acordo com [Counterparty co-fundador e desenvolvedor principal] no PhantomPhreak abaixo, Counterparty está usando 256 bytes para armazenar dados no blockchain em uma de cada três transações multisig. Além disso, todas essas transações multisig são processadas por mineradores.
O desenvolvedor passou a criticar os desenvolvedores do Bitcoin por planejarem limitar o OP_Return a 40 bytes em vez de 80:
Se OP_RETURN destina-se a parar/reduzir o comportamento multisig (saídas não gastas) e, assim, reduzir o inchaço do blockchain, temo que, ao reduzir o tamanho de OP_RETURN de 80 bytes para 40 bytes, você inadvertidamente tornará o multisig mais atraente para todos os meta-protocolos, você tornou OP_RETURN menos atraente.
O principal desenvolvedor e cofundador da Counterparty, conhecido como "PhantomPhreak", entrou na conversa:
A ideia é que armazenemos os dados em um segundo blockchain e coloquemos hashes desses dados de carimbo de data/hora no Bitcoin, e esses hashes também terão menos de 40 bytes. A razão pela qual não fizemos isso não foi "preguiça intelectual", mas complexidade de implementação. Counterparty não é um projeto de ciência da computação; ele foi projetado para ser o mais simples possível para aumentar a velocidade de desenvolvimento. Mesmo se tivermos que armazenar dados na saída de assinatura múltipla, não na saída OP_RETURN, que é muito pequena. Neste campo, pior é definitivamente melhor.
Jeff respondeu no dia seguinte:
Isso é pedir carona. Dado que a grande maioria (> 90%;) dos aplicativos de blockchain do Bitcoin são uso de moeda, usar nós completos como terminais de armazenamento de dados estúpidos é apenas um abuso de recursos de rede totalmente voluntários. A rede replica dados de transação, então por que não pegar carona? Em vez de participar da comunidade existente, mastercoin e Counterparty simplesmente apertaram o botão "ligar" e começaram a usar os nós Bitcoin P;2 P como armazenamento de dados desnecessários. As saídas de transações não gastas não devem ser usadas como armazenamento de dados arbitrários. O fato de poder ser abusado não o torna correto, nem remotamente eficaz, ou a melhor solução. O banco de dados UTXO (Unspent Transaction Output) é um banco de dados de acesso rápido para toda a rede. Cada nó precisa que esse banco de dados seja o menor possível para lidar melhor com as transações de rede. Codificar dados arbitrários em saída não consumida é um abuso em toda a rede, pura e simplesmente. Toda a rede carrega esse preço.
fonte:
Devido ao alto status de Jeff na comunidade, a maioria das pessoas na comunidade Counterparty parece interessada em se envolver e resolver o problema. Por exemplo, BitcoinTangibleTrust respondeu:
Obrigado por compartilhar seus pensamentos, Jeff. Então, você pode nos ajudar a começar a interagir com a comunidade de desenvolvimento existente do Bitcoin Core? É do interesse da contraparte agir como um parceiro responsável porque precisamos do blockchain do Bitcoin se quisermos sobreviver. Você pode nos dizer como começar a colaborar nessas questões?
fonte:
Outro desenvolvedor da Counterparty fez outro ponto:
Existe uma maneira de o protocolo Bitcoin parar a maneira como o XCP o usa sem quebrar mais nada?
Se os desenvolvedores do Bitcoin não tivessem como impedir transações relacionadas à contraparte, talvez essa objeção não importasse e a contraparte pudesse continuar a usar o Bitcoin sem permissão. O desenvolvedor de Bitcoin e, em seguida, operador de pool de mineração, Luke-Jr, entrou no debate:
Os mineradores devem filtrar o abuso.
fonte:
Luke-Jr então sugeriu que esses tipos de sistemas poderiam ser construídos usando uma estrutura do tipo sidechain minerada por fusão, o que evitaria o inchaço do blockchain.
O problema não é a nova camada, mas a imposição às pessoas contra sua vontade. Novas camadas podem ser feitas de forma opcional sem poluir o blockchain e forçar os não participantes a armazenar dados.
Luke também foi perguntado por que os desenvolvedores do Bitcoin reduziram o tamanho esperado do relé OP_Return para 40 bytes, em comparação com o limite originalmente proposto de 80 bytes. Lucas respondeu com os seguintes três pontos:
Muitas pessoas pensam que OP_RETURN é uma função e deve ser usada. Nunca foi pensado assim, apenas uma forma de “deixar as janelas destrancadas para não termos de substituir o vidro quando alguém arromba”. Ou seja, reduzindo os danos causados por pessoas que abusam do Bitcoin.
40 bytes são suficientes para todas as necessidades legais de vincular dados a uma transação: você obtém 32 bytes para o hash, mais 8 bytes para algum tipo de identificador exclusivo (o que também não é realmente necessário!).
A proposta original de 80 bytes destinava-se a um hash de 512 bits, mas foi considerada desnecessária.
Lucas Jr continuou:
Esperançosamente, conforme a mineração retornar à descentralização, veremos menos tolerância para transações abusivas/spam, seja a variante OP_RETURN ou outra. Agora, se alguém tiver um caso de uso válido e necessário para realmente armazenar hashes com transações, obviamente os mineradores devem considerar seriamente a mineração.
fonte:
O pool de mineração de Luke na época também começou a filtrar as transações relacionadas à contraparte. Foi quando o medo e a incerteza começaram a crescer na comunidade da Contraparte. Eles precisam que OP_Return tenha 80 bytes, caso contrário, serão forçados a continuar usando o opcode OP_CHECKMULTISIG. Dado o comentário de Luke, parece improvável que chegue a 80 bytes. Além disso, alguns temem que os desenvolvedores reduzam ainda mais o limite, potencialmente tirando o Counterparty da rede. Os desenvolvedores de Bitcoin não parecem ser particularmente amigáveis com a Counterparty, então alguns podem pensar que continuar usando o protocolo Bitcoin pode ser difícil.
Em 25 de março de 2014, Vitalik Buterin, o principal fundador da Ethereum, entrou na conversa, argumentando que o debate deveria girar mais em torno de taxas e que, se você pagar taxas suficientes, sua transação deveria ser legalmente incluída em um bloco. Hoje, o algoritmo de taxas do Ethereum é muito complexo, com diferentes baldes de taxas e taxas para muitos usos diferentes de blockchain, o que fundamentalmente resolve o problema OP_Return. Pode-se argumentar que o SegWit no Bitcoin também alivia esse problema até certo ponto.
Isso é culpa do protocolo, e a luta do OPRETURN é um grande problema. Em um mundo ideal, o conceito de "abuso" não existiria; as taxas seriam obrigatórias e cuidadosamente projetadas para corresponder ao custo real que uma determinada transação impõe à rede", disse ele. "Se você pudesse pagar pelo que é sendo feito, então você deve ser capaz de fazê-lo, sem perguntas. "
fonte:
Em 27 de março de 2014, a Counterparty alterou o método de transação para ignorar o filtro de mineração de Luke-Jr. No entanto, no dia seguinte Lucas comentou:
boas notícias! Em menos de 5 minutos e 1 linha de código, você pode adicionar um filtro para bloquear essas coisas inúteis.
fonte:
Luke-Jr também comparou a contraparte a uma forma de abuso:
Isso é um abuso porque você força outras pessoas a baixar/armazenar seus dados de acordo com sua livre escolha. Cada nó completo deve baixar o blockchain completo (pode ser podado ou não!). Todo nó completo concorda em baixar e armazenar transações financeiras. Nem todo nó completo concorda em armazenar qualquer outra coisa. Para isso, você precisa de 100% de consenso, não apenas de algum subconjunto (ou seja, não mineradores; não desenvolvedores) ou mesmo uma maioria. Além disso, todos são livres para armazenar dados que não estão no blockchain. Não há nenhum benefício em tê-lo no blockchain, é apenas que você está forçando pessoas que não o querem. Você explica como isso não é abuso...
fonte:
Raiva contra desenvolvedores de bitcoin
Como era de se esperar, as preocupações dos desenvolvedores de Bitcoin foram finalmente recebidas com frustração e raiva de alguns desenvolvedores e usuários da contraparte. Incluímos algumas de suas avaliações abaixo. Primeiro, um comentário de um usuário chamado "porqupine" sobre o pool de Luke-Jr bloqueando transações de contraparte:
Isso é bom em comparação com seus desenvolvedores, que estão comprometidos com responsabilidade em encontrar uma solução - você está promovendo um jogo de gato e rato. Você percebeu que estava falando sobre neutralidade da rede também? E tentando colocar em mãos privadas as transações que as pessoas deveriam e não deveriam fazer no blockchain. Qual é o próximo passo para sancionar alguém de quem você não gosta? Sanções para transações de transmissão em nós em países onde você desaprova a política externa do governo?
fonte:
Em 21 de março de 2014, porqupine continuou:
Espere um minuto, quando decidir: Todo nó concorda em armazenar dados do tipo X em vez de dados do tipo Y. Talvez eu também não concorde com o armazenamento de transações para lavagem de dinheiro, drogas e armas ilegais, escravidão humana, etc. Você está basicamente negando a neutralidade do protocolo e decidindo o que o protocolo deve e não deve ser usado para armazenar, não apenas você' Não falando na primeira pessoa, mas usando o pronome Nós, dando a impressão de que você está representando todos os Mineiros ou os usuários do protocolo falam como um todo.
fonte:
Outros expressaram preocupação sobre por que Jeff e Luke têm o poder de contornar outros para bloquear certos casos de uso.
Eu não posso acreditar nesta atitude. Eu não sabia que bitcoins tinham donos. Eu pensei que eu e cerca de um milhão de outras pessoas eram os proprietários
O cofundador da contraparte, PhantomPhreak, disse:
Primeiro, as transações de contraparte são transações financeiras. Em segundo lugar, cada nó completo concorda em baixar e armazenar o blockchain do Bitcoin. Ou seja, as transações que estão em conformidade com o protocolo Bitcoin, as transações de contraparte aparentemente o fazem. Pelo amor de Deus, Satoshi incorporou uma mensagem política no bloco de gênese... você tem uma visão muito mais estreita dos possíveis casos de uso do Bitcoin do que qualquer outra pessoa.
fonte:
Ele ou ela continua:
Bitcoin faz muitas coisas que não deveria fazer. Sim, realmente gostaríamos de usar uma solução mais elegante do que a que temos agora. A contraparte foi originalmente projetada para usar a saída OP_RETURN para armazenar todos os dados de sua mensagem, o que considero muito elegante e tem impacto mínimo no blockchain. Planejamos formatar todas as mensagens em torno do limite de 80 bytes que Gavin anunciou no blog oficial do Bitcoin. Usamos apenas saídas de assinatura múltipla porque não temos escolha. Não queremos estender o protocolo Bitcoin. Queremos fazer algo inteiramente nele, e o mais simples e direto possível, para os benefícios de estabilidade, segurança, etc.
fonte:
Da mesma forma, apenas armazenamos transações financeiras no blockchain e estamos pagando pelo espaço que estamos usando. Transações financeiras em saídas OP_RETURN não são mais uma dor de cabeça para armazenamento de nó completo do que qualquer outra coisa.
fonte:
Outro usuário chamado "bitwhizz" disse:
Se você não quiser armazená-lo, não, muito simples, não use bitcoin, não baixe o blockchain, seu scott é grátis. No entanto, minha concordância significa que acredito que o Bitcoin não apenas tem uma função de transação, mas com base no fato de que ninguém a possui e existe uma função OP_RETURN, não vejo por que essa função deva ser erradicada, porque você não deseja armazenar. Você já pode Dados de livre escolha.
fonte:
"Outroanonlol" disse:
Eu realmente não consigo entender como uma transação da Contraparte não constitui uma transação financeira? Também não consigo entender o ponto de vista, porque, digamos, 1 nó em 1000 não está disposto a aceitar esses dados e deve ser banido por padrão. Após o recente pesadelo do mt.gox e os inúmeros hacks, roubos, paralisações e perdas causadas pelo armazenamento de seus saldos em entidades centralizadas, parece que a Counterparty apresentou uma solução que permite uma solução centralizada e sem confiança para esse problema.
fonte:
"Baddw" disse:
Na verdade, qualquer pessoa pode armazenar dados arbitrários na blockchain a qualquer momento. Ele foi e está sendo usado para esse fim. Todo mundo que executa um nó Bitcoin já deve saber disso e, se não, deve fazer parte da notificação que apareceu quando instalou o Bitcoin-QT (se houver; não me lembro de ter visto). Qualquer transação Bitcoin pode ser um simples movimento de dinheiro, ou uma carta de amor, ou um gatilho para detonar uma bomba. Remover essa possibilidade mataria o Bitcoin.
fonte:
Baddw continuou:
Muitos dos maiores desenvolvimentos na história da computação (e na verdade toda a história da tecnologia humana) foram o resultado de pessoas descobrindo coisas que seus inventores não tinham intenção de usar. O bom é que a maioria dos inventores não protege tanto suas invenções e não se recusa a permitir que outros as usem para coisas novas. Aqueles que o fizeram, viram-se rapidamente superados.
fonte:
A partir desses comentários, fica claro que muitos usuários e desenvolvedores da contraparte estão surpresos e desapontados com a posição dos desenvolvedores do Bitcoin. Enquanto o projeto continua, assim como o Mastercoin, é provável, para o bem ou para o mal, que alguns desenvolvedores tenham deixado o Bitcoin como resultado e construído seus protocolos em outros sistemas blockchain, como o Ethereum. É este momento de 2014 que é mais importante do que qualquer outro em nossa opinião. No entanto, outros podem vê-lo de forma diferente.
Cadeias laterais mineradas por mesclagem
Ao longo do debate OP_Return, a contraparte e os oponentes do inchaço do blockchain normalmente se referem a alguma forma de cadeias laterais de mineração mescladas como uma solução para Dapps. Na verdade, diz-se que Satoshi Nakamoto gostou desse caminho e o endossou para uso no sistema de nomes de domínio em dezembro de 2010:
Eu acho que é possível que o BitDNS seja uma rede completamente separada e um blockchain separado, mas compartilhe o poder da CPU com o Bitcoin. A única sobreposição é a prova de trabalho que permite que os mineradores pesquisem ambas as redes simultaneamente.
fonte:
Existem muitas dificuldades na implementação desses sistemas Dapp como sidechains, e entendemos essas fraquezas melhor do que em 2014, quando muitas pessoas apenas pensavam que poderiam funcionar.
Complexidade - Uma das fraquezas mais importantes é a complexidade da implementação e construção de soluções de sidechain. Para lançar o protocolo antecipadamente e ganhar participação de mercado, esses projetos não têm tempo para construir sidechains e sistemas de mineração mesclados com Bitcoin.
Bitcoin como um ativo nativo - Pode não ser possível usar Bitcoin sem custódia como um ativo operacional em uma sidechain, pois pode não ser possível estabelecer uma peg bidirecional sem confiança. Esta é uma grande fraqueza para muitos Dapps, por exemplo, eles podem querer usar o Bitcoin como o principal par de negociação em uma bolsa distribuída. Essa fraqueza não parece ser bem compreendida em 2014, e muitas pessoas simplesmente assumem que funciona de alguma forma.
Benefícios de dimensionamento limitados - os benefícios do uso de sidechains podem variar de acordo com o caso de uso. Por exemplo, se uma troca distribuída fosse construída, cada lance, oferta e correspondência provavelmente exigiria toda a segurança da cadeia principal. Com tantos usos da cadeia principal, para cada ação possível de cada usuário na bolsa, as vantagens de escala do sistema de cadeia lateral podem ser muito limitadas. O envio de lances localmente na cadeia pode usar apenas cerca de 90 bytes, enquanto armazenar o hash das informações do pedido e a estrutura e a sobrecarga necessárias para identificá-lo pode ser de cerca de 50 bytes na cadeia, portanto, não economizaria muito espaço.
Em março de 2014, o desenvolvedor da Counterparty (xnova) delineou sua oposição às sidechains da seguinte forma.
Além disso, a menos que eu esteja esquecendo algo aqui, ainda precisamos analisar os dados dos blocos no segundo blockchain (pelo menos supondo que seja um bitcoin ou uma implementação derivada de bitcoin) para obter os dados que armazenamos. Portanto: * Não permitirá clientes de contraparte do tipo SPV devido aos recursos de moedas coloridas fornecidos pela contraparte (ou seja, DEx, apostas, callbacks de ativos, dividendos, CFDs, etc.) * Isso reduzirá a segurança das transações da contraparte. Isso aumentaria muito a complexidade da implementação (ou seja, aumentaria as chances de bugs e bugs), com o único benefício duvidoso sendo uma pequena * redução em nossos requisitos de armazenamento para o blockchain (ou seja, talvez 20-40 bytes a menos por transação?) . Eu simplesmente não vejo o que isso significa aqui. Mais um ponto: a contraparte pode trazer enormes benefícios para o Bitcoin, o que se tornará mais aparente se/como o Ethereum (e outras moedas do tipo meta ";2.0;" semelhantes não-Bitcoin) aparecerem. Pelo menos, meu sentimento pessoal é que o Bitcoin provavelmente precisará de produtos com essa funcionalidade no ecossistema para competir efetivamente com o Ethereum e a lista de recursos e apelo da (futura) multidão - ou corre o risco de ser eliminado, pelo menos Isso é verdade entre investidores e operadores do mercado financeiro , e isso fornece a capacidade de trazer bilhões ou até trilhões de dólares para o ecossistema Bitcoin à medida que ganha mais reconhecimento, confiança e compartilhamento de ideias.
fonte:
Parece que algumas pessoas que suportam sidechains como uma solução não estão particularmente interessadas em muitos aplicativos dapp, nem os experimentaram. Portanto, eles nunca consideraram a complexidade de construir uma troca distribuída e a necessidade de segurança para quase todas as ações de todos os usuários. A maioria dos desenvolvedores de Bitcoin parece estar aberta ao que está interessado e tem uma boa ideia do que deseja: dinheiro resistente à censura, dinheiro não político, dinheiro eletrônico, etc.
para concluir
Depois de 2014, a maioria dos desenvolvedores interessados em Dapps se concentrou em construir no Ethereum ou em outros sistemas, não no Bitcoin. Posteriormente, o Ethereum ganhou muito interesse e impulso dos desenvolvedores, enquanto o desenvolvimento do Dapp no Bitcoin foi mínimo. O objetivo deste post é enfatizar que o principal motivador disso não são as taxas necessárias, nem a máquina virtual do Ethereum e os maiores recursos técnicos do Ethereum, é apenas que muitos Bitcoiners e desenvolvedores de Bitcoin não querem Dapps no Bitcoin, eles são não está interessado em Bitcoin. essas funções. Para o bem ou para o mal, alguns Bitcoiners deliberadamente afastaram muitos desses desenvolvedores do Dapp. Alguns proponentes do Bitcoin argumentam que a maioria das atividades dapp está relacionada a golpes insustentáveis, ou que tal atividade é indesejável no Bitcoin por segurança ou outros motivos.
Desde 2014, as opiniões de muitas pessoas mudaram. Bitcoin precisa de taxas de transação para sobreviver. Em um ambiente pós-2016, onde temos muitos bloqueios completos e taxas mais altas, há uma percepção mais geral de que qualquer transação de pagamento é "legítima". Certos Dapps no Ethereum, como trocas como Uniswap, ou protocolos de empréstimo como AAVE e Compound, provaram ser bem-sucedidos e interessantes até certo ponto. Ainda assim, é uma questão em aberto se os Bitcoiners se importam o suficiente com esses protocolos no Bitcoin, e muito menos se alguém realmente os constrói e usa.
Ver original
O conteúdo serve apenas de referência e não constitui uma solicitação ou oferta. Não é prestado qualquer aconselhamento em matéria de investimento, fiscal ou jurídica. Consulte a Declaração de exoneração de responsabilidade para obter mais informações sobre os riscos.
Uma retrospectiva do debate OP_Return de 2014 do debate Ordinals: Dapps vs Bitcoin trading
Fonte original: BitMEX Research
O debate ;OP_RETURN; em ;2014; foi uma divisão notável dentro da indústria e tem muitas semelhanças com o debate ;Ordinal; de hoje. Olhando para trás, o debate ;OP_RETURN; é particularmente significativo hoje.
Visão geral
Muitas vezes nos perguntam: por que Dapps, como trocas descentralizadas, geralmente no Ethereum em vez de Bitcoin? Afinal, é claro que é possível construir Dapps em cima do Bitcoin, como trocas descentralizadas, sistemas de nome de domínio ou tokens alternativos. É claro que existem 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. Os tempos de bloco mais rápidos do Ethereum tornam os Dapps mais fáceis de usar ou iii. Limites de tamanho de bloco mais conservadores do que o Ethereum , resultando em taxas potencialmente mais altas para o Bitcoin. Todos os fatores acima têm um impacto, mas acreditamos que seu impacto é frequentemente superestimado. O fator mais importante é a cultura. Alguns entusiastas de bitcoin e desenvolvedores de bitcoin simplesmente não querem tal atividade na blockchain do bitcoin e a bloquearam com sucesso. Isso parece ter acontecido principalmente por volta de março de 2014, e o que aconteceu nessa época é o assunto deste artigo. Enquanto isso, os promotores de outras cadeias como a Ethereum podem ter aproveitado e exagerado essa aparente postura dos desenvolvedores de Bitcoin para ajudar seu ecossistema a ganhar força.
Protocolo de contraparte
Conforme mencionado em nosso relatório de setembro de 2020, no início de 2014, a Counterparty foi lançada. A contraparte é uma camada de protocolo sobre o Bitcoin que permite recursos como a criação de novos tokens e a negociação desses tokens em trocas distribuídas. O sistema funciona pegando partes dos dados de transação de bitcoin e usando-os em acordos de contraparte como uma função, como criar tokens, enviar tokens ou fazer lances de mercado para tokens em uma bolsa distribuída.
Mais sucintamente, no início, o Counterparty incluiu dados relacionados ao Counterparty no blockchain do Bitcoin usando o opcode do Bitcoin OP_CHECKMULTISIG. Este opcode deve ser usado para verificar a assinatura de uma transação multi-assinatura Payment Script Hash (P;2 SH). Uma amostra de transação da Counterpaty de julho de 2014 pode ser visualizada aqui. A transação envia o bitcoin de volta para o endereço de onde veio e também possui três saídas adicionais, onde o script de saída são dados relacionados ao contrato da contraparte. Neste caso, ele está criando um novo token chamado TICKET. O uso de OP_CHECKMULTISIG pode ser considerado um hack, pois esse não é o uso pretendido do opcode. A contraparte agora usa o opcode OP_Return do Bitcoin para armazenar dados, o que está um pouco mais de acordo com a intenção do desenvolvedor. Por exemplo, veja esta transação de contraparte atualizada que usa OP_Return.
No início de 2014, houve muita experimentação, atividade de desenvolvedores, inovação e empolgação em torno da Counterparty, à frente de uma plataforma rival chamada Mastercoin.
O que é OP_Return?
OP_Return é uma saída de transação comprovadamente não gastável em Bitcoin. Esse recurso pode ser usado para gravar bitcoins ou armazenar dados arbitrários na blockchain do bitcoin. Como os dados não fazem parte do conjunto UTXO, diz-se que armazenar dados dessa maneira ajuda a dimensionar o Bitcoin porque os nós que participam da poda não precisam armazenar dados OP_Return.
As regras de consenso do Bitcoin permitem um tamanho máximo de OP_Return de 10.000 bytes. Por exemplo, em maio de 2013, esse recurso foi explorado na seguinte transação. A saída OP_Return nesta transação contém a letra da música "Never Gonna Give You Up" de Rick Astley, de 1987, que está relacionada ao meme Rickrolling.
Antes de 2014, as transações contendo OP_Return não eram padrão e não eram retransmitidas por nós Bitcoin normais. No entanto, se os mineradores incluírem essas transações, elas serão consideradas válidas. Em março de 2014, foi lançado o Bitcoin Core 0.9.0, que incluiu a função OP_Return como um tipo de transação padrão, portanto, as transações serão retransmitidas por padrão. As notas de lançamento na época eram as seguintes:
Essa mudança não é um endosso ao armazenamento de dados na blockchain. A alteração OP_RETURN cria saídas comprovadamente passíveis de remoção para evitar esquemas de armazenamento de dados (alguns dos quais já implantados) que armazenam dados arbitrários (como imagens) como saídas TX que nunca estão disponíveis, inchando o banco de dados UTXO do Bitcoin. Armazenar dados arbitrários no blockchain ainda é uma má ideia; é mais barato e mais eficiente armazenar dados não monetários em outro lugar.
fonte:
O Bitcoin Core 0.9.0 só retransmitirá transações com OP_Return de 40 bytes ou menos, se os dados forem maiores que isso, ainda será uma transação válida, mas não será retransmitida. O limite original era de 80 bytes, mas depois de muito debate, os desenvolvedores decidiram por 40 bytes.
Em 2016, o Bitcoin Core 0.11.1 finalmente aumentou o limite de retransmissão para 80 bytes e, no final de 2016, no lançamento do Bitcoin Core 0.12.0, aumentou para 83 bytes, nosso limite hoje. Isso significa que se você deseja uma transação com uma saída OP_Return de mais de 83 bytes hoje, você mesmo deve minerar o bloco ou enviá-lo diretamente ao minerador.
OP_Guerra do Retorno
Em 20 de março de 2014, Jeff Garzik, então um dos principais colaboradores do Bitcoin, começou a postar no fórum Counterparty no fórum Bitcointalk. Jeff criticou o uso do espaço blockchain pela Counterparty.
Até o momento, não vi um esquema de despejo de dados blockchain que não possa ser substituído com segurança por um hash simples. Você não precisa armazenar dados no blockchain. Isso é pura preguiça intelectual. Os hashes (dados) com carimbo de data/hora são tão seguros quanto mais eficientes. Além disso, uma cadeia secundária pode ser comprovadamente atrelada ao Bitcoin:
fonte:
Jeff continuou dizendo:
CheckMultiSig obviamente funciona com chaves públicas ECDSA, não com dados arbitrários. Não deveria ser nenhuma surpresa que usar uma operação para algo diferente do propósito pretendido pode ter consequências negativas, possivelmente não intencionais ou desconhecidas. As transações de contraparte não são "de acordo com o protocolo Bitcoin", elas passam porque nunca foi esperado usar o recurso dessa forma.
fonte:
Alguém pode achar estranho que Jeff tenha essa visão, já que ele parece ser um "apoiador do grande bloco" em 2017, e essa visão do uso conservador do espaço do bloco parece estar em desacordo com a visão do grande bloco. No entanto, essa aparente inconsistência não surgiu em 2014. Naquela época, as opiniões de Jeff eram até certo ponto reconhecidas por quase todos os desenvolvedores ativos da época, incluindo aqueles que mais tarde se tornaram chefes de grandes blocos. Tanto quanto sabemos, simplesmente não existe um mapeamento simples entre as percepções das pessoas sobre os limites de tamanho de bloco e esta questão. Jeff era um desenvolvedor muito respeitado na época, e este artigo chamou muita atenção dos desenvolvedores e usuários da Counterparty.
Um desenvolvedor de contraparte com o pseudônimo "BitcoinTangibleTrust" respondeu a Jeff da seguinte forma:
Você está absolutamente certo. Você não precisa armazenar dados no blockchain. Os hashes (dados) com carimbo de data/hora são tão seguros quanto mais eficientes. Uma cadeia secundária pode ser comprovadamente atrelada ao Bitcoin. No entanto, de acordo com [Counterparty co-fundador e desenvolvedor principal] no PhantomPhreak abaixo, Counterparty está usando 256 bytes para armazenar dados no blockchain em uma de cada três transações multisig. Além disso, todas essas transações multisig são processadas por mineradores.
O desenvolvedor passou a criticar os desenvolvedores do Bitcoin por planejarem limitar o OP_Return a 40 bytes em vez de 80:
Se OP_RETURN destina-se a parar/reduzir o comportamento multisig (saídas não gastas) e, assim, reduzir o inchaço do blockchain, temo que, ao reduzir o tamanho de OP_RETURN de 80 bytes para 40 bytes, você inadvertidamente tornará o multisig mais atraente para todos os meta-protocolos, você tornou OP_RETURN menos atraente.
O principal desenvolvedor e cofundador da Counterparty, conhecido como "PhantomPhreak", entrou na conversa:
A ideia é que armazenemos os dados em um segundo blockchain e coloquemos hashes desses dados de carimbo de data/hora no Bitcoin, e esses hashes também terão menos de 40 bytes. A razão pela qual não fizemos isso não foi "preguiça intelectual", mas complexidade de implementação. Counterparty não é um projeto de ciência da computação; ele foi projetado para ser o mais simples possível para aumentar a velocidade de desenvolvimento. Mesmo se tivermos que armazenar dados na saída de assinatura múltipla, não na saída OP_RETURN, que é muito pequena. Neste campo, pior é definitivamente melhor.
Jeff respondeu no dia seguinte:
Isso é pedir carona. Dado que a grande maioria (> 90%;) dos aplicativos de blockchain do Bitcoin são uso de moeda, usar nós completos como terminais de armazenamento de dados estúpidos é apenas um abuso de recursos de rede totalmente voluntários. A rede replica dados de transação, então por que não pegar carona? Em vez de participar da comunidade existente, mastercoin e Counterparty simplesmente apertaram o botão "ligar" e começaram a usar os nós Bitcoin P;2 P como armazenamento de dados desnecessários. As saídas de transações não gastas não devem ser usadas como armazenamento de dados arbitrários. O fato de poder ser abusado não o torna correto, nem remotamente eficaz, ou a melhor solução. O banco de dados UTXO (Unspent Transaction Output) é um banco de dados de acesso rápido para toda a rede. Cada nó precisa que esse banco de dados seja o menor possível para lidar melhor com as transações de rede. Codificar dados arbitrários em saída não consumida é um abuso em toda a rede, pura e simplesmente. Toda a rede carrega esse preço.
fonte:
Devido ao alto status de Jeff na comunidade, a maioria das pessoas na comunidade Counterparty parece interessada em se envolver e resolver o problema. Por exemplo, BitcoinTangibleTrust respondeu:
Obrigado por compartilhar seus pensamentos, Jeff. Então, você pode nos ajudar a começar a interagir com a comunidade de desenvolvimento existente do Bitcoin Core? É do interesse da contraparte agir como um parceiro responsável porque precisamos do blockchain do Bitcoin se quisermos sobreviver. Você pode nos dizer como começar a colaborar nessas questões?
fonte:
Outro desenvolvedor da Counterparty fez outro ponto:
Existe uma maneira de o protocolo Bitcoin parar a maneira como o XCP o usa sem quebrar mais nada?
Se os desenvolvedores do Bitcoin não tivessem como impedir transações relacionadas à contraparte, talvez essa objeção não importasse e a contraparte pudesse continuar a usar o Bitcoin sem permissão. O desenvolvedor de Bitcoin e, em seguida, operador de pool de mineração, Luke-Jr, entrou no debate:
Os mineradores devem filtrar o abuso.
fonte:
Luke-Jr então sugeriu que esses tipos de sistemas poderiam ser construídos usando uma estrutura do tipo sidechain minerada por fusão, o que evitaria o inchaço do blockchain.
O problema não é a nova camada, mas a imposição às pessoas contra sua vontade. Novas camadas podem ser feitas de forma opcional sem poluir o blockchain e forçar os não participantes a armazenar dados.
Luke também foi perguntado por que os desenvolvedores do Bitcoin reduziram o tamanho esperado do relé OP_Return para 40 bytes, em comparação com o limite originalmente proposto de 80 bytes. Lucas respondeu com os seguintes três pontos:
Lucas Jr continuou:
Esperançosamente, conforme a mineração retornar à descentralização, veremos menos tolerância para transações abusivas/spam, seja a variante OP_RETURN ou outra. Agora, se alguém tiver um caso de uso válido e necessário para realmente armazenar hashes com transações, obviamente os mineradores devem considerar seriamente a mineração.
fonte:
O pool de mineração de Luke na época também começou a filtrar as transações relacionadas à contraparte. Foi quando o medo e a incerteza começaram a crescer na comunidade da Contraparte. Eles precisam que OP_Return tenha 80 bytes, caso contrário, serão forçados a continuar usando o opcode OP_CHECKMULTISIG. Dado o comentário de Luke, parece improvável que chegue a 80 bytes. Além disso, alguns temem que os desenvolvedores reduzam ainda mais o limite, potencialmente tirando o Counterparty da rede. Os desenvolvedores de Bitcoin não parecem ser particularmente amigáveis com a Counterparty, então alguns podem pensar que continuar usando o protocolo Bitcoin pode ser difícil.
Em 25 de março de 2014, Vitalik Buterin, o principal fundador da Ethereum, entrou na conversa, argumentando que o debate deveria girar mais em torno de taxas e que, se você pagar taxas suficientes, sua transação deveria ser legalmente incluída em um bloco. Hoje, o algoritmo de taxas do Ethereum é muito complexo, com diferentes baldes de taxas e taxas para muitos usos diferentes de blockchain, o que fundamentalmente resolve o problema OP_Return. Pode-se argumentar que o SegWit no Bitcoin também alivia esse problema até certo ponto.
Isso é culpa do protocolo, e a luta do OPRETURN é um grande problema. Em um mundo ideal, o conceito de "abuso" não existiria; as taxas seriam obrigatórias e cuidadosamente projetadas para corresponder ao custo real que uma determinada transação impõe à rede", disse ele. "Se você pudesse pagar pelo que é sendo feito, então você deve ser capaz de fazê-lo, sem perguntas. "
fonte:
Em 27 de março de 2014, a Counterparty alterou o método de transação para ignorar o filtro de mineração de Luke-Jr. No entanto, no dia seguinte Lucas comentou:
boas notícias! Em menos de 5 minutos e 1 linha de código, você pode adicionar um filtro para bloquear essas coisas inúteis.
fonte:
Luke-Jr também comparou a contraparte a uma forma de abuso:
Isso é um abuso porque você força outras pessoas a baixar/armazenar seus dados de acordo com sua livre escolha. Cada nó completo deve baixar o blockchain completo (pode ser podado ou não!). Todo nó completo concorda em baixar e armazenar transações financeiras. Nem todo nó completo concorda em armazenar qualquer outra coisa. Para isso, você precisa de 100% de consenso, não apenas de algum subconjunto (ou seja, não mineradores; não desenvolvedores) ou mesmo uma maioria. Além disso, todos são livres para armazenar dados que não estão no blockchain. Não há nenhum benefício em tê-lo no blockchain, é apenas que você está forçando pessoas que não o querem. Você explica como isso não é abuso...
fonte:
Raiva contra desenvolvedores de bitcoin
Como era de se esperar, as preocupações dos desenvolvedores de Bitcoin foram finalmente recebidas com frustração e raiva de alguns desenvolvedores e usuários da contraparte. Incluímos algumas de suas avaliações abaixo. Primeiro, um comentário de um usuário chamado "porqupine" sobre o pool de Luke-Jr bloqueando transações de contraparte:
Isso é bom em comparação com seus desenvolvedores, que estão comprometidos com responsabilidade em encontrar uma solução - você está promovendo um jogo de gato e rato. Você percebeu que estava falando sobre neutralidade da rede também? E tentando colocar em mãos privadas as transações que as pessoas deveriam e não deveriam fazer no blockchain. Qual é o próximo passo para sancionar alguém de quem você não gosta? Sanções para transações de transmissão em nós em países onde você desaprova a política externa do governo?
fonte:
Em 21 de março de 2014, porqupine continuou:
Espere um minuto, quando decidir: Todo nó concorda em armazenar dados do tipo X em vez de dados do tipo Y. Talvez eu também não concorde com o armazenamento de transações para lavagem de dinheiro, drogas e armas ilegais, escravidão humana, etc. Você está basicamente negando a neutralidade do protocolo e decidindo o que o protocolo deve e não deve ser usado para armazenar, não apenas você' Não falando na primeira pessoa, mas usando o pronome Nós, dando a impressão de que você está representando todos os Mineiros ou os usuários do protocolo falam como um todo.
fonte:
Outros expressaram preocupação sobre por que Jeff e Luke têm o poder de contornar outros para bloquear certos casos de uso.
Eu não posso acreditar nesta atitude. Eu não sabia que bitcoins tinham donos. Eu pensei que eu e cerca de um milhão de outras pessoas eram os proprietários
O cofundador da contraparte, PhantomPhreak, disse:
Primeiro, as transações de contraparte são transações financeiras. Em segundo lugar, cada nó completo concorda em baixar e armazenar o blockchain do Bitcoin. Ou seja, as transações que estão em conformidade com o protocolo Bitcoin, as transações de contraparte aparentemente o fazem. Pelo amor de Deus, Satoshi incorporou uma mensagem política no bloco de gênese... você tem uma visão muito mais estreita dos possíveis casos de uso do Bitcoin do que qualquer outra pessoa.
fonte:
Ele ou ela continua:
Bitcoin faz muitas coisas que não deveria fazer. Sim, realmente gostaríamos de usar uma solução mais elegante do que a que temos agora. A contraparte foi originalmente projetada para usar a saída OP_RETURN para armazenar todos os dados de sua mensagem, o que considero muito elegante e tem impacto mínimo no blockchain. Planejamos formatar todas as mensagens em torno do limite de 80 bytes que Gavin anunciou no blog oficial do Bitcoin. Usamos apenas saídas de assinatura múltipla porque não temos escolha. Não queremos estender o protocolo Bitcoin. Queremos fazer algo inteiramente nele, e o mais simples e direto possível, para os benefícios de estabilidade, segurança, etc.
fonte:
Da mesma forma, apenas armazenamos transações financeiras no blockchain e estamos pagando pelo espaço que estamos usando. Transações financeiras em saídas OP_RETURN não são mais uma dor de cabeça para armazenamento de nó completo do que qualquer outra coisa.
fonte:
Outro usuário chamado "bitwhizz" disse:
Se você não quiser armazená-lo, não, muito simples, não use bitcoin, não baixe o blockchain, seu scott é grátis. No entanto, minha concordância significa que acredito que o Bitcoin não apenas tem uma função de transação, mas com base no fato de que ninguém a possui e existe uma função OP_RETURN, não vejo por que essa função deva ser erradicada, porque você não deseja armazenar. Você já pode Dados de livre escolha.
fonte:
"Outroanonlol" disse:
Eu realmente não consigo entender como uma transação da Contraparte não constitui uma transação financeira? Também não consigo entender o ponto de vista, porque, digamos, 1 nó em 1000 não está disposto a aceitar esses dados e deve ser banido por padrão. Após o recente pesadelo do mt.gox e os inúmeros hacks, roubos, paralisações e perdas causadas pelo armazenamento de seus saldos em entidades centralizadas, parece que a Counterparty apresentou uma solução que permite uma solução centralizada e sem confiança para esse problema.
fonte:
"Baddw" disse:
Na verdade, qualquer pessoa pode armazenar dados arbitrários na blockchain a qualquer momento. Ele foi e está sendo usado para esse fim. Todo mundo que executa um nó Bitcoin já deve saber disso e, se não, deve fazer parte da notificação que apareceu quando instalou o Bitcoin-QT (se houver; não me lembro de ter visto). Qualquer transação Bitcoin pode ser um simples movimento de dinheiro, ou uma carta de amor, ou um gatilho para detonar uma bomba. Remover essa possibilidade mataria o Bitcoin.
fonte:
Baddw continuou:
Muitos dos maiores desenvolvimentos na história da computação (e na verdade toda a história da tecnologia humana) foram o resultado de pessoas descobrindo coisas que seus inventores não tinham intenção de usar. O bom é que a maioria dos inventores não protege tanto suas invenções e não se recusa a permitir que outros as usem para coisas novas. Aqueles que o fizeram, viram-se rapidamente superados.
fonte:
A partir desses comentários, fica claro que muitos usuários e desenvolvedores da contraparte estão surpresos e desapontados com a posição dos desenvolvedores do Bitcoin. Enquanto o projeto continua, assim como o Mastercoin, é provável, para o bem ou para o mal, que alguns desenvolvedores tenham deixado o Bitcoin como resultado e construído seus protocolos em outros sistemas blockchain, como o Ethereum. É este momento de 2014 que é mais importante do que qualquer outro em nossa opinião. No entanto, outros podem vê-lo de forma diferente.
Cadeias laterais mineradas por mesclagem
Ao longo do debate OP_Return, a contraparte e os oponentes do inchaço do blockchain normalmente se referem a alguma forma de cadeias laterais de mineração mescladas como uma solução para Dapps. Na verdade, diz-se que Satoshi Nakamoto gostou desse caminho e o endossou para uso no sistema de nomes de domínio em dezembro de 2010:
Eu acho que é possível que o BitDNS seja uma rede completamente separada e um blockchain separado, mas compartilhe o poder da CPU com o Bitcoin. A única sobreposição é a prova de trabalho que permite que os mineradores pesquisem ambas as redes simultaneamente.
fonte:
Existem muitas dificuldades na implementação desses sistemas Dapp como sidechains, e entendemos essas fraquezas melhor do que em 2014, quando muitas pessoas apenas pensavam que poderiam funcionar.
Em março de 2014, o desenvolvedor da Counterparty (xnova) delineou sua oposição às sidechains da seguinte forma.
Além disso, a menos que eu esteja esquecendo algo aqui, ainda precisamos analisar os dados dos blocos no segundo blockchain (pelo menos supondo que seja um bitcoin ou uma implementação derivada de bitcoin) para obter os dados que armazenamos. Portanto: * Não permitirá clientes de contraparte do tipo SPV devido aos recursos de moedas coloridas fornecidos pela contraparte (ou seja, DEx, apostas, callbacks de ativos, dividendos, CFDs, etc.) * Isso reduzirá a segurança das transações da contraparte. Isso aumentaria muito a complexidade da implementação (ou seja, aumentaria as chances de bugs e bugs), com o único benefício duvidoso sendo uma pequena * redução em nossos requisitos de armazenamento para o blockchain (ou seja, talvez 20-40 bytes a menos por transação?) . Eu simplesmente não vejo o que isso significa aqui. Mais um ponto: a contraparte pode trazer enormes benefícios para o Bitcoin, o que se tornará mais aparente se/como o Ethereum (e outras moedas do tipo meta ";2.0;" semelhantes não-Bitcoin) aparecerem. Pelo menos, meu sentimento pessoal é que o Bitcoin provavelmente precisará de produtos com essa funcionalidade no ecossistema para competir efetivamente com o Ethereum e a lista de recursos e apelo da (futura) multidão - ou corre o risco de ser eliminado, pelo menos Isso é verdade entre investidores e operadores do mercado financeiro , e isso fornece a capacidade de trazer bilhões ou até trilhões de dólares para o ecossistema Bitcoin à medida que ganha mais reconhecimento, confiança e compartilhamento de ideias.
fonte:
Parece que algumas pessoas que suportam sidechains como uma solução não estão particularmente interessadas em muitos aplicativos dapp, nem os experimentaram. Portanto, eles nunca consideraram a complexidade de construir uma troca distribuída e a necessidade de segurança para quase todas as ações de todos os usuários. A maioria dos desenvolvedores de Bitcoin parece estar aberta ao que está interessado e tem uma boa ideia do que deseja: dinheiro resistente à censura, dinheiro não político, dinheiro eletrônico, etc.
para concluir
Depois de 2014, a maioria dos desenvolvedores interessados em Dapps se concentrou em construir no Ethereum ou em outros sistemas, não no Bitcoin. Posteriormente, o Ethereum ganhou muito interesse e impulso dos desenvolvedores, enquanto o desenvolvimento do Dapp no Bitcoin foi mínimo. O objetivo deste post é enfatizar que o principal motivador disso não são as taxas necessárias, nem a máquina virtual do Ethereum e os maiores recursos técnicos do Ethereum, é apenas que muitos Bitcoiners e desenvolvedores de Bitcoin não querem Dapps no Bitcoin, eles são não está interessado em Bitcoin. essas funções. Para o bem ou para o mal, alguns Bitcoiners deliberadamente afastaram muitos desses desenvolvedores do Dapp. Alguns proponentes do Bitcoin argumentam que a maioria das atividades dapp está relacionada a golpes insustentáveis, ou que tal atividade é indesejável no Bitcoin por segurança ou outros motivos.
Desde 2014, as opiniões de muitas pessoas mudaram. Bitcoin precisa de taxas de transação para sobreviver. Em um ambiente pós-2016, onde temos muitos bloqueios completos e taxas mais altas, há uma percepção mais geral de que qualquer transação de pagamento é "legítima". Certos Dapps no Ethereum, como trocas como Uniswap, ou protocolos de empréstimo como AAVE e Compound, provaram ser bem-sucedidos e interessantes até certo ponto. Ainda assim, é uma questão em aberto se os Bitcoiners se importam o suficiente com esses protocolos no Bitcoin, e muito menos se alguém realmente os constrói e usa.