Por que a Pearl mudou o consenso quatro vezes em 27.000 blocos

A Pearl passou do bloco 99.000 da mainnet nesta semana, e com ele veio a quarta mudança de consenso em 27.065 blocos. Duas das quatro foram hard forks e duas foram softforks, o que importa para o que um minerador teve de fazer, mas não para o motivo de qualquer uma delas. Quatro atualizações tão próximas parecem uma cadeia em apuros. É quase o contrário. Lidas em ordem de bloco, não são quatro problemas separados, são um único problema atacado por quatro lados, e a última delas o resolve. Cada altura, regra e versão abaixo foi lida no próprio código-fonte de consenso da cadeia, e não em um anúncio.

O que a Pearl pede a um minerador

Comece pelo que a Pearl pede a um minerador, porque nada do resto faz sentido sem isso. A Pearl lançou sua mainnet em 27 de abril de 2026 como uma camada um que se protege com multiplicação de matrizes em vez de hashing. A multiplicação é a mesma álgebra linear densa em que treinamento e inferência de IA passam quase todo o tempo. Um minerador executa uma multiplicação de matrizes com ruído na GPU, faz o hash do resultado num compromisso e embrulha esse trabalho numa prova de conhecimento zero, para que a rede possa verificá-lo de forma barata. A camada de base por baixo é propositalmente sem graça, um fork do nó btcd do Bitcoin, para que a ideia nova fique sobre uma estrutura antiga e bem conhecida.

Por que o formato do trabalho importa

Agora a parte difícil dessa ideia. Quando o trabalho é um hash, existe exatamente um jeito de fazê-lo e exatamente um número que diz o quanto foi difícil. Quando o trabalho é uma multiplicação de matrizes, o minerador também precisa declarar o formato dela: o tamanho das matrizes e quanto ruído de baixo rank é incorporado. A cadeia nunca vê a GPU. Ela vê uma prova e uma descrição do trabalho de que a prova trata. Cada uma das quatro atualizações é sobre essa descrição, e sobre fazer com que declarar cada parte dela custe alguma coisa.

Bloco 71.935: o certificado mixture of experts

A primeira, um hard fork no bloco 71.935, levou as provas do certificado v1 para o v2. A atualização tem o nome do que o novo certificado consegue descrever: um mixture of experts, o formato que a inferência real em um modelo grande assume, em que só alguns especialistas entre muitos rodam para cada token. Um formato de prova que só descreve uma grande multiplicação densa só consegue descrever parte disso. O certificado v2 também traz um campo que o v1 não tinha, o rank do ruído, e foi esse campo que tornou a terceira atualização possível.

Bloco 91.630: só denso, por enquanto

A segunda, um softfork no bloco 91.630, estreitou a porta que tinha acabado de ser alargada: a partir desse bloco a rede rejeita provas mixture of experts e aceita só as densas. Parece um recuo e não é. O certificado continuou no v2, então o formato manteve tudo o que tinha ganhado; o que mudou foi quais formatos contam enquanto a cadeia é jovem. O projeto não publicou o motivo do momento escolhido, então este é o ponto em que o leitor deve ser avisado disso, e não receber um palpite disfarçado de motivo.

Bloco 96.251: o rank deixa de pagar

A terceira, um softfork no bloco 96.251, é a que tem um número que o minerador sente. O rank define quanto ruído de baixo rank é incorporado à multiplicação, e antes desse fork o alvo que um share precisava superar ficava mais fácil na proporção do tamanho do bloco de matriz vezes o comprimento total do produto escalar. Aumentar o rank, portanto, comprava um alvo proporcionalmente mais fácil sem que a GPU fizesse mais trabalho real: o controle que decide quanto do cálculo é genuíno era também o controle que decidia por quantos shares você era pago. A partir desse bloco, o mesmo limite é escalado pelo tamanho do bloco de matriz vezes o comprimento do produto escalar dividido pelo rank vezes 128, e qualquer rank abaixo de 128 é recusado de imediato. As duas expressões diferem exatamente por 128 dividido pelo rank, então o efeito sobre um minerador que ainda usa a configuração antiga é aritmética, não estimativa: no rank 256 o alvo fica duas vezes mais difícil do que era para o mesmo trabalho, e no rank 1024, oito vezes.

Uma mudança de consenso que aperta o que conta como trabalho real também pode aposentar hardware, porque a regra mais rígida precisa ser reproduzida bit a bit na placa que estiver fazendo o trabalho. Se alguma geração específica de GPU perdeu o suporte à Pearl com esse fork é uma pergunta para as notas de versão de cada programa de mineração, e não para a cadeia, e este artigo não cita nenhuma, porque o código da cadeia não diz nada sobre placas. Ainda assim, é o tipo de coisa que vale conferir antes de comprar uma placa para uma única moeda.

Bloco 99.000: a semente fica presa ao formato

A quarta, um hard fork no bloco 99.000, é a menor mudança e a mais fácil de descrever errado. O ruído contra o qual o minerador multiplica é derivado das duas raízes de Merkle da prova. Antes desse fork, essas raízes entravam na derivação puras, então o ruído não dependia das dimensões de matriz com que a prova se compromete. A partir do bloco 99.000, cada raiz é primeiro misturada com uma dessas dimensões, o número de linhas em uma e o número de colunas na outra, e só então a cadeia de sementes roda. Um dado ruído, portanto, pertence a exatamente um formato declarado. O layout do certificado é byte a byte o que o v2 era e a rede ainda transmite as raízes puras; só o número de versão escolhe qual derivação vale, e por isso a única coisa que isso pediu ao minerador foi um binário novo.

O que as quatro somam

Coloque as quatro em fila e elas dizem uma frase de quatro jeitos. A cadeia não consegue observar a GPU, então tudo o que uma prova afirma sobre si mesma precisa custar algo para ser afirmado. O mixture of experts ampliou o que uma prova pode descrever. O só denso restringiu o que conta enquanto a cadeia é jovem. A penalidade de rank impediu que um controle dentro da declaração comprasse um alvo mais fácil. A semente com sal impediu que um mesmo ruído servisse a mais de um formato declarado. Uma cadeia jovem encontrar essas falhas nos primeiros meses e corrigi-las em menos de 27.000 blocos é um sinal melhor do que uma cadeia jovem que não encontrou nenhuma.

O que isso significa se você minera PRL

A parte prática, para quem minera PRL. As quatro ativaram num bloco fixo, sem período de transição, e as quatro falham do mesmo jeito silencioso: um programa de mineração desatualizado continua mostrando um hashrate perfeitamente saudável enquanto seus shares deixam de contar. O número de hashrate na sua própria tela não é prova de nada num dia de fork. Acompanhe a contagem de shares aceitos e atualize antes do bloco, não depois. Se você faz mineração mesclada, a perda dobra, porque um share da Pearl que não é válido também não leva nenhum bloco auxiliar.

Do nosso lado, cada uma delas já estava pronta antes do bloco do fork, então a única coisa que o minerador precisou mudar foi o binário do programa de mineração. Mesmo endereço, mesma porta, mesma carteira.

De onde vêm estes números

De onde vêm os números, para que qualquer pessoa possa conferi-los em vez de acreditar na nossa palavra: as quatro alturas de ativação, o tempo de bloco e a data e hora do gênesis da mainnet foram lidos nos próprios parâmetros de rede e na definição do gênesis da cadeia; a regra do rank e o valor de 128 dividido pelo rank foram lidos nas verificações de sanidade do verificador de provas, onde o limite antigo e o novo ficam lado a lado; e as versões do certificado e a derivação com sal foram lidas no formato de transmissão e no módulo de sementes. O que o código não diz ficou fora deste artigo em vez de ser preenchido.