Introdução

Você deve ter ouvido falar sobre a reativação do OP_CAT como uma atualização potencial para a linguagem de script do Bitcoin. Dependendo de onde você obtém suas notícias, OP_CAT foi chamado de “apenas 10 linhas de código”, “a melhor maneira de permitir a experimentação com convênios”, “muito poderoso”, “perigoso e levando à centralização da mineradora” ou “garantido para levar a um soft fork controverso”. Vou argumentar que todas essas perspectivas estão erradas. OP_CAT é muito útil, pode ser usado como um pacto, e não (sozinho) o melhor próximo passo para o bitcoin. Nada mais e nada menos.

Para defender esse caso, explorarei vários tópicos (aparentemente desconexos), alguns dos quais eram novos para mim há poucos meses. Vou tentar organizar isso de uma forma que forneça o histórico necessário em um só lugar.

Como e o que OP_CAT faz

Introspecção com CAT

Vamos abordar a questão candente que muitos têm quando expostos pela primeira vez ao OP_CAT. Como algumas linhas de código que combinam dois itens da pilha em um (AB CAT -> AB) podem permitir algo interessante? Andrew Poelstra explicou eloquentemente em entrevistas recentes, e eu postei uma explicação breve e boba:

Como o script Bitcoin é estritamente uma linguagem de verificação, cada código de operação pode ser usado para frente ou para trás. Um script pode receber um hash e exigir uma pré-imagem, ou receber uma pré-imagem e exigir um hash usando OP_SHA256. Esse insight nos dá as duas primeiras partes de como funcionam os convênios OP_CAT.

Se um script Bitcoin pudesse obter acesso a um hash da transação que está verificando, poderia exigir que a pilha de gastos fornecesse a pré-imagem do hash, dividida da maneira que o script exigir e, em seguida, validasse qualquer parte específica dessa pré-imagem. Isso é exatamente o que é um pacto – validar uma parte da transação gastando algum bitcoin.

Isso é ótimo, mas o bitcoin não possui um opcode como OP_TXHASH para dar ao script acesso ao hash da transação. Aqui, aproveitamos a equação de verificação de assinatura BIP340 Schnorr para exigir que o usuário forneça o hash. Se o usuário fornecer um valor que será um hash de transação válido se o script concatenar o byte 0x00 ao final dele, esse valor também fará parte de uma assinatura BIP340 válida (com alguns outros parâmetros fixos) se o script concatenar o byte 0x01 para ele.

A combinação dessas técnicas permite que o OP_CAT verifique qualquer parte de sua transação de gastos que possa ser assinada e até mesmo analise suas transações principais de algumas maneiras limitadas. Com um código cuidadoso, é possível construir Purrfect Vaults, CatVM e muito mais.

Outros usos para CAT

Mas não deveríamos. Construir essas coisas com OP_CAT resulta em abominações difíceis de manter. Em vez disso, deveríamos usar OP_CAT para o que ele serve, e há muito disso: ele permite o equivalente a OP_CHECKSEPARATESIG, verificando provas de inclusão Merkle, combinando dados para verificação de assinatura com OP_CHECKSIGFROMSTACK e muito mais.

Problemas com CAT

Agora que sabemos o que o CAT faz, qual é o problema? Por que as pessoas (inclusive eu) disseram que é uma fera perigosa? Usando a técnica de introspecção descrita acima, o CAT permite duas construções específicas: garantias de taxa de hash e (supostamente) formadores de mercado automatizados (AMMs). Até recentemente, ambos eram considerados riscos significativos de trazer a centralização do MEV para o bitcoin.

Centralização MEV, MEVil e Mineiro

O termo MEV (Miner Extractable Value) é um pouco confuso. Na interpretação mais simples, incluiria taxas de transação, que obviamente queremos que sejam pagas aos mineradores para ajudar a garantir a segurança do bitcoin no futuro. MEV é geralmente usado para significar valor adicional que os mineradores podem extrair de seus blocos além das taxas visíveis na rede pública de retransmissão. Isto poderia vir na forma de pagamentos fora da banda, mineiros participando de contratos e reordenando transações de maneiras que os favoreçam, ou mesmo roubo total de bens e serviços por mineradores que mineram blocos que reorganizam e gastam duas vezes um pagamento confirmado a um comerciante. Todas estas formas de MEV podem ser consideradas geralmente más para os participantes da rede, uma vez que os mineiros estão a utilizar a sua posição na rede em seu próprio benefício, às custas de outros participantes da rede. No entanto, o MEV por si só não apresenta um problema sistémico ao impulsionar a centralização dos mineiros, apenas um problema local para os participantes especificamente afetados.

MEVil é um termo que às vezes é usado para MEV que impulsiona a centralização da mineradora – prefiro o termo centralizando MEV e irei usá-lo daqui para frente. Várias coisas são necessárias para transformar o MEV em MEV centralizador:

  1. Deve ser suficientemente difícil de extrair para que um construtor de modelo de bloco de código aberto não possa extraí-lo razoavelmente
  2. O valor total extraível deve crescer com a taxa de hash de bitcoin do minerador
  3. O valor extraível deve justificar o custo de extração

Se todos estes requisitos forem cumpridos, apenas uma mineradora suficientemente grande terá o incentivo para começar a extrair o MEV. Quando o fizerem, poderão superar o crescimento dos seus pares mais pequenos, graças às receitas adicionais extraídas. Quanto mais caro for extrair o MEV (até o ponto em que não vale a pena para nenhum minerador), pior será a pressão centralizadora que ele cria.

Evitar a centralização do MEV é (em certo sentido) simples: garantir que quaisquer oportunidades de MEV existentes no bitcoin sejam tão fáceis de extrair que todos o façam ou custem mais para extrair do que valem (seja porque são tão pequenos ou porque eles são muito caros).

Para mais informações, confira a postagem recente de @TheBlueMatt.

Cauções de taxa de hash (nascida Drivechains)

Muitos anos atrás (antes da Lightning Network ou de ideias como Ark, Timeout Trees, roll-ups, BitVM ou CatVM) as sidechains eram consideradas a solução de escalonamento definitiva para bitcoin. A ideia era conceitualmente simples: os blocos de bitcoin devem permanecer limitados em tamanho por todas as razões usuais de descentralização, mas podemos anexar cadeias laterais ao bitcoin e elas podem ter blocos mais rápidos, blocos maiores, mais computação ou qualquer outra coisa. Na prática, porém, implementar cadeias laterais não foi tão fácil. A liquidação final do Bitcoin está fundamentalmente ligada à prova de trabalho, um custo infalsificável para reordenar transações. Como uma cadeia lateral herda isso? Além disso, como o bitcoin pode ser transferido de e para a cadeia lateral? A proposta mais conhecida para responder a essas duas questões é chamada de Drivechains (BIPs 300 e 301). Não vou aborrecê-lo com os detalhes dos Drivechains, mas basta dizer que existem apenas dois resultados de tais sistemas sidechain: ou eles são relativamente não utilizados (e, portanto, inúteis) ou são amplamente utilizados e se tornam um tamanho de bloco de fato. aumento para bitcoin. Um aumento de facto do tamanho do bloco deste tipo é uma forma de centralizar o MEV, onde apenas mineradores maiores poderão participar de forma econômica nas oportunidades de receita adicionais oferecidas pelos blocos de cadeia lateral potencialmente grandes e complexos.

Os depósitos de hashrate, que podem ser construídos com OP_CAT, são uma pequena parte das propostas do Drivechains. Este é um sistema de restrição de retiradas de sidechains usando um contador cujo valor só pode ser alterado pelos mineradores, começa em um valor alto e deve chegar a zero antes que uma retirada de sidechain possa ser processada. Afirma-se que isso é uma transferência “sem confiança” de uma cadeia lateral, mas na verdade cria uma federação de mineradores com controle de todos os bitcoins mantidos em cadeias laterais.

Desde o desenvolvimento das propostas de Drivechains, tornou-se (em nosso detrimento) comum referir-se a qualquer proposta que possa ser usada para criar uma retirada baseada em um contador controlado por minerador como “Drivechains”. Esperamos que neste ponto esteja claro por que esta abreviação inadequada é inútil – Drivechains são inúteis ou perigosos, mas os depósitos de hashrate são apenas uma forma de transferir o controle do resultado de alguma transação para a federação implícita de mineradores.

Tokens e AMMs

Fichas

Por razões que nunca ficarão totalmente claras para mim, os humanos adoram um token bom (ou um token ruim ou, na verdade, apenas tokens). Quase desde o início do bitcoin, tem-se falado sobre como incorporar outros tokens no protocolo, desde moedas coloridas e contraparte, até os mais recentes ativos e runas Taproot. Todos esses protocolos têm uma coisa em comum: eles exigem um índice externo de transações de bitcoin que tenha conhecimento de dados externos ou processe dados da sequência de transações de bitcoin para determinar as transformações de tokens dentro do protocolo. O ponto importante deste artigo é que os scripts de bloqueio de bitcoin desconhecem completamente a existência dos tokens, e mesmo os nós de bitcoin que validam as transações desconhecem os tokens (ou seja, mesmo que um script de bloqueio de bitcoin tenha acesso total ao conjunto completo de Bitcoin UTXO , não foi possível descobrir o estado de nenhum desses tokens).

Formadores de mercado automatizados (AMMs)

Em outros sistemas blockchain, é comum que contratos conhecidos como AMMs sejam usados ​​para (por exemplo) fixar a relação entre dois tokens, comprando e vendendo a um preço fixo. As regras que podem ser codificadas em um AMM estão além do escopo deste artigo. Basta dizer que os AMMs criam enormes oportunidades para o MEV e, devido às relações de troca privadas necessárias para maximizar os retornos desse MEV, também centralizam o MEV. Isso tem sido frequentemente usado como um argumento contra a construção de scripts bitcoin mais expressivos – nós realmente queremos evitar expor a rede bitcoin aos caprichos da centralização do MEV. No entanto, como descrevi acima, simplesmente não existe uma maneira prática de os scripts Bitcoin, por mais expressivos que sejam, avaliarem o estado de qualquer token que não seja o Bitcoin. Os scripts Bitcoin não conseguem localizar um sat raro. Eles não conseguem encontrar um equilíbrio de runas. Eles não conseguem identificar um ativo Taproot.

Sem acesso a qualquer informação sobre a disposição de ativos não-bitcoin, todo o conceito de um AMM baseado em script bitcoin deixa de fazer sentido. As localizações dos tokens podem ser atestadas por uma assinatura de um oráculo, mas os atestados do oráculo não constituem um AMM. Eles podem ser usados ​​para facilitar negociações manuais específicas, mas não um sistema automatizado durável. Além disso, tal sistema baseado em oráculo poderia ser construído hoje sem alterações no bitcoin.

Conclusão

Como você pode ver, o CAT não é uma fera tão assustadora. Não é realmente uma fera. Não tem capacidade infinita nem poderes mágicos. É apenas um pequeno código de operação que pode ser muito útil. A única coisa que provavelmente queremos evitar é ativar o OP_CAT sem outra maneira de fazer a introspecção da transação, como OP_TXHASH, OP_TX ou ambos. Até mesmo habilitá-lo com LNHANCE é uma melhoria apenas no OP_CAT porque reduz o tamanho e a complexidade dos scripts necessários para alcançar muitos protocolos de introspecção OP_CAT.

Este é um post convidado de Brandon Black. As opiniões expressas são inteiramente próprias e não refletem necessariamente as da BTC Inc ou da Bitcoin Magazine.

Fonte: bitcoinmagazine.com

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *