Soft fork ativado pelos usuários

A ideia inverte a ordem habitual das operações. Em vez de esperar que o poder de hash sinalize que está pronto, os nós que recebem pagamentos anunciam uma data a partir da qual vão recusar qualquer bloco que não esteja em conformidade. O BIP-148 fixou essa data em 1º de agosto de 2017, e a ameaça crível que ela representava é amplamente creditada por ter encerrado um impasse de sinalização que durava desde novembro de 2016.

Como funciona

É na validação, não na mineração, que uma regra acaba sendo imposta, e um soft fork ativado pelos usuários se baseia nesse fato.

Um nó decide por si mesmo quais blocos são válidos. Se uma parte suficiente da economia, as corretoras, os processadores de pagamentos e os custodiantes com quem as pessoas de fato liquidam seus pagamentos, executa software que rejeita blocos não conformes, então um minerador que produz esses blocos é pago em bitcoins que ninguém vai aceitar. A recompensa de bloco só vale alguma coisa se a cadeia em que ela está for a cadeia que os compradores reconhecem, então o incentivo aponta para a conformidade sem que nenhuma votação aconteça.

O mecanismo é uma data, e não um limiar. O BIP-148 exigia que, a partir de 1º de agosto de 2017, todo bloco sinalizasse estar pronto para o SegWit, e instruía os nós a tornar órfãos os blocos que não o fizessem. Isso é um aperto nas regras, então uma cadeia em conformidade continua válida para os nós que nunca foram atualizados. O que isso não elimina é o risco de divisão: se a maior parte do poder de hash continuar minerando blocos não conformes, o lado que impõe a regra tem menos trabalho acumulado, e as duas cadeias coexistem até que um dos lados ceda.

O BIP-8 depois transformou a abordagem em um conjunto geral de parâmetros. Ele conta os sinais do mesmo modo que o BIP-9, mas acrescenta o lockinontimeout, geralmente escrito LOT. Com o LOT em false, a implantação simplesmente expira se os mineradores nunca alcançarem o limiar. Com o LOT em true, ela fica travada na altura do timeout de qualquer maneira, o que é um soft fork ativado pelos usuários expresso como um parâmetro de configuração.

Onde isso aparece

A sequência de 2017 é o único exemplo concluído no bitcoin, e vale a pena conhecê-la em ordem. O BIP-148 foi publicado em março de 2017 por um desenvolvedor que usava o nome Shaolin Fry e foi adotado pelos operadores de nós ao longo da primavera. Diante de um prazo em agosto, os mineradores adotaram o BIP-91 em julho para tornar obrigatória entre eles a sinalização do SegWit. O SegWit então travou no bloco 479.808 em 8 de agosto de 2017 e passou a ser exigível no bloco 481.824 em 24 de agosto de 2017. A data fixa chegou sem uma divisão duradoura porque o resultado que ela exigia já havia sido obtido.

A abordagem ressurgiu antes do Taproot. No fim de 2020 e no início de 2021, a discussão foi inteiramente sobre distribuir o BIP-8 com o LOT em true ou em false, um cliente alternativo com o LOT em true foi publicado, e o acordo foi o Speedy Trial, que definiu uma janela curta e nenhuma ativação forçada. Os mineradores alcançaram o limiar em junho de 2021, então a questão nunca foi posta à prova.

Se você tem bitcoin, a conclusão relevante é que executar seu próprio nó é o que dá peso a tudo isso. Um soft fork ativado pelos usuários conta os usuários que validam, e alguém cujo saldo está inteiramente em uma corretora é representado pelo software dessa corretora, e não pelo próprio.

Soft fork ativado pelos usuários vs hard fork

Um soft fork ativado pelos usuários aperta as regras; um hard fork as afrouxa, e a confusão de 2017 veio do fato de que ambos traziam risco de divisão. Sob o BIP-148, uma carteira antiga continuava funcionando e a cadeia resultante permanecia válida para todas as versões anteriores do software, que é exatamente o que um hard fork não pode prometer. O risco de divisão era temporário e dependia do comportamento dos mineradores, enquanto a divisão de um hard fork já está prevista no projeto desde o primeiro bloco incompatível.