Zcash vai reduzir o tempo de bloco: o que muda para usuários e mineradores?

A atualização NU7 do Zcash reduzirá o tempo-alvo entre blocos de 75 segundos para 25, dando aos depósitos a chance de confirmar mais cedo, enquanto deixa as exchanges decidirem quando creditá-los. A atualização também altera o que os mineradores ganham com transações, com 40% das taxas indo para os mineradores e os 60% restantes reservados para recompensas futuras.

O Zcash agendou sua atualização NU7 para o bloco 3.543.405, quando a rede reduzirá seu tempo-alvo entre blocos de 75 segundos para 25 e começará a reservar a maior parte das taxas de transação para futuras recompensas de mineração.

As notas de lançamento do Zebra 7.0.0 da Zcash Foundation identificam o software que suporta a mudança. Para alguém depositando ZEC em uma exchange que exige seis confirmações, o intervalo mais curto reduz a espera-alvo por esses blocos de sete minutos e meio para dois minutos e meio, assumindo que a exchange mantenha o mesmo requisito.

Para os mineradores, a mudança está em como eles ganham suas recompensas. O Zcash emitirá um subsídio menor em cada bloco para manter estável a emissão diária programada, enquanto os mineradores coletarão 40% das taxas de transação e os 60% restantes irão para uma reserva para reemissão posterior.

O que muda entre enviar ZEC e obter um saldo utilizável

Um pagamento pode passar por vários estágios diferentes mesmo quando ambas as partes usam a mesma moeda. O remetente cria uma transação e a transmite para a rede. Um nó verifica a transação de acordo com suas regras, um minerador a inclui em um bloco, e o software do destinatário reconhece o pagamento. O destinatário então decide quantas confirmações esperar antes de tratar os fundos como disponíveis.

A NU7 altera o espaçamento esperado entre os blocos nessa sequência. Ela não estabelece um tempo garantido para cada uma das outras etapas. Uma carteira que está offline não pode exibir o pagamento até se reconectar, e uma exchange pode manter um saldo pendente enquanto aplica suas próprias verificações. Como o crypto.news relatou, a NU7 define um alvo de 25 segundos para blocos. O efeito sobre um depósito ainda depende do serviço que o recebe.

Uma transferência direta oferece a comparação mais simples. Se a transação do remetente for aceita e os mineradores a incluírem no próximo bloco, o destinatário tem a chance de ver a primeira confirmação mais cedo. Se o destinatário for um comerciante que espera múltiplas confirmações antes de entregar mercadorias, sua política determina quanto do benefício chega ao comprador.

Uma exchange adiciona um sistema de crédito entre a blockchain e a conta do cliente. Ela pode reconhecer a transação onchain e mostrar ao usuário um item pendente, depois creditar a conta após a contagem exigida ter se acumulado. Um trader que quer vender o ZEC não pode usar apenas o primeiro carimbo de tempo para comparar exchanges. A comparação útil é o tempo entre transmitir o mesmo tipo de transação e receber um saldo negociável.

Uma política de seis confirmações também depende de como a exchange define a contagem. Algumas interfaces contam o bloco que contém a transação como a primeira confirmação. O cálculo simples de seis vezes o espaçamento-alvo é uma referência para a produção de blocos, enquanto a espera observada depende de onde no intervalo a transação foi enviada e se o próximo minerador a incluiu. Uma medição deve registrar esses detalhes antes de comparar resultados.

Uma carteira que recebe uma transferência blindada tem outra fonte de trabalho. Ela varre a cadeia para encontrar dados que possa descriptografar com as chaves relevantes. Blocos mais rápidos podem melhorar a experiência de pagamento ao mesmo tempo que criam atualizações mais frequentes para o software processar. A atualização foi executada na testnet da Zcash antes da mudança para a mainnet. Suas regras por bloco limitam tipos específicos de trabalho blindado.

Uma comparação de políticas de confirmação pode ser expressa em minutos sem adivinhar o que qualquer exchange escolherá. No alvo antigo, três blocos representavam 225 segundos de produção esperada. No novo alvo, nove blocos representam a mesma duração alvo. Seis blocos antigos e 18 blocos novos também representam, da mesma forma, 450 segundos.

A tabela multiplica a contagem pelo espaçamento alvo. Ela não consegue medir quanto trabalho protege qualquer transação específica ou o que a equipe de risco de uma exchange considerará equivalente. Duas políticas com a mesma duração esperada podem ter propriedades diferentes se as condições de mineração da rede ou a distribuição dos tempos de bloco mudarem.

O teste antes e depois mais útil usaria o mesmo serviço, carteira e tipo de transação. Um registro de data e hora registraria quando o usuário transmite a transação. Um segundo marcaria a inclusão. Um terceiro registraria quando a exchange ou o comerciante disponibiliza o saldo. Se o primeiro intervalo cair e o segundo permanecer estável, a mudança na rede pode ter melhorado uma parte do processo enquanto o serviço manteve suas verificações existentes.

Um cliente que faz um pagamento também precisa considerar a disponibilidade do software do destinatário. Um comerciante que usa um backend compatível pode conseguir agir assim que sua política permitir. Um cliente que envia para uma carteira que ainda não terminou de sincronizar pode esperar que a carteira se atualize mesmo depois de os mineradores terem confirmado o pagamento. Ambas as experiências podem ser descrições precisas de partes diferentes da mesma transação.

Para os mineradores, mudanças no ritmo dos blocos podem complicar comparações feitas durante a própria transição. Uma amostra curta pode incluir blocos mais lentos ou mais rápidos do que o alvo, e os operadores podem atualizar seu software em momentos diferentes. Uma leitura de uma hora poderia capturar a mudança e a variação comum na chegada de blocos em conjunto. Janelas mais longas dão uma visão melhor de se a produção realizada está se estabilizando perto do alvo.

Um operador que avalia taxas precisa de disciplina semelhante. Comparar o total por bloco pode dar um resultado enganoso porque as transações são distribuídas por mais blocos. Uma comparação baseada em taxas por dia pode mostrar quanto os usuários pagaram no total. O operador pode então calcular quanto desse total está disponível imediatamente e quanto está reservado sob as novas regras.

A capacidade de fazer essas distinções importa mais do que uma simples afirmação de que a rede é três vezes mais rápida. Para a maioria dos usuários, o benefício observável será uma mudança específica em uma rota de pagamento particular. Para os mineradores, a mudança observável será a distribuição de subsídio e taxas ao longo de um período longo o suficiente para levar em conta o maior número de blocos.

O que a estimativa de capacidade do Orchard mede

A estimativa do Orchard da fundação diz respeito à taxa de transações sob um modelo especificado. Transações blindadas podem ter formatos diferentes e exigir quantidades diferentes de trabalho. Duas transações podem contar como duas transferências para as pessoas que as usam e ainda assim impor cargas diferentes à rede por causa do número de ações envolvidas.

Um limite de ações é, consequentemente, diferente de uma cota de pagamentos. Ele estabelece um limite para o que um bloco pode conter para o pool relevante. A rede pode combinar esse limite mais restrito com blocos mais frequentes. Quantas transações realmente cabem depende da composição das transações que os mineradores selecionam e da interação entre os limites específicos do pool e globais.

Para um desenvolvedor de carteira, o valor de um limite é que ele torna algumas cargas de pior caso mais fáceis de raciocinar. Um usuário que sincroniza uma carteira leve depende de o software ser capaz de recuperar e processar os dados necessários para descobrir seus pagamentos. Se blocos excepcionalmente custosos puderem dominar esse trabalho, um usuário pode experimentar uma sincronização mais lenta mesmo quando blocos individuais chegam mais rapidamente.

A estimativa de capacidade deve ser avaliada em conjunto com o desempenho sob tráfego real. Observações úteis incluiriam quais pools respondem pela atividade, o número de ações por transação e quanto tempo uma carteira com um ponto de sincronização mais antigo leva para se atualizar. Uma sincronização mais rápida sob carga cotidiana e uma carga de pior caso menor abordam problemas relacionados, mas diferentes.

Os usuários não podem inferir a demanda por pagamentos a partir do tamanho dos novos limites. A capacidade pode aumentar enquanto o número de pagamentos permanece estável. Por outro lado, uma aplicação pode gerar uma rajada de atividade blindada que torna os limites relevantes mesmo que a média de longo prazo da rede permaneça baixa. Essa distinção importa ao comparar a utilidade da atualização com um movimento de preço em torno da data de ativação.

Por que os mineradores devem comparar a receita ao longo de um dia ou semana

A mudança no subsídio significa que um único bloco é uma unidade ruim para comparar a receita total de mineração ao longo da ativação. Um minerador que recebe um terço do subsídio por bloco ainda pode competir por aproximadamente três vezes mais blocos no mesmo período. Ao longo de um intervalo suficientemente longo, a participação do minerador no poder computacional da rede importa mais para sua parcela esperada do subsídio do que o número de ZEC atribuído a um bloco.

A mudança ainda pode alterar a forma como os pagamentos são distribuídos ao longo do tempo. Um minerador solo vivencia os blocos como eventos discretos e pode passar muito tempo sem encontrar um. Um pool combina o trabalho de muitos mineradores e tem sua própria contabilidade para distribuir os rendimentos. Um fluxo mais frequente de recompensas menores pode alterar o padrão de recebimentos mesmo quando o subsídio agregado programado permanece estável.

Um extrato de pool pode combinar subsídio, taxas e ajustes da fórmula de pagamento do pool. Para isolar o efeito do NU7, um minerador precisaria comparar os componentes de taxas e subsídio separadamente e usar a mesma unidade de tempo. Comparar um pagamento por bloco com um pagamento diário, ou comparar dois períodos com poder computacional substancialmente diferente, obscureceria a parte atribuível às novas regras.

Os custos operacionais introduzem uma distinção adicional. A receita de mineração medida em ZEC não descreve quanto os mineradores mantêm após pagar despesas de eletricidade e hardware. Um pool poderia ganhar uma quantidade semelhante de ZEC ao longo de um período e ver o valor em dólares dessa renda mudar se o preço do token se mover. Uma queda no lucro líquido não mostraria por si só que o cronograma de subsídio por bloco mudou.

As taxas de transação podem variar muito mais do que o subsídio programado. Se a atividade aumentar, as taxas totais ao longo de um dia poderiam aumentar mesmo que os mineradores retenham uma fração menor. Se a atividade permanecer a mesma, a própria divisão reduz sua renda imediata de taxas. Uma comparação precisa tanto da nova porcentagem quanto do valor das taxas ao qual ela é aplicada.

Há um limiar simples para essa comparação restrita. Se o valor pago em taxas subir para duas vezes e meia seu nível anterior, os mineradores que ficam com 40% receberiam o mesmo valor imediato de taxas de antes, mantendo outros fatores constantes. Essa aritmética não prevê o tráfego. Ela mostra por que o efeito sobre os mineradores depende em parte do uso que a atualização possibilita e em parte do nível inicial de taxas.

As políticas de confirmação decidirão o que os clientes realmente percebem

O espaçamento entre blocos informa a uma carteira com que frequência a rede espera criar um novo espaço para transações. Uma carteira ainda precisa construir e transmitir um pagamento, um nó precisa aceitá-lo e um minerador precisa incluí-lo. Se uma transação está competindo por espaço limitado, o intervalo entre blocos sozinho não determina sua espera.

Uma exchange tem uma decisão separada a tomar assim que vê a transação. Ela pode exibir um depósito pendente antes de disponibilizar o saldo para negociação ou saque. Um cliente poderia, portanto, ver o depósito aparecer mais cedo após o NU7 enquanto espera mais tempo para que a exchange aplique sua própria política final de crédito.

As contagens de confirmação também mudam de significado quando os blocos chegam com mais frequência. Seis blocos na nova meta representam um intervalo de tempo decorrido menor do que seis na meta antiga. Uma exchange que deseja preservar aproximadamente a mesma espera poderia passar de seis para 18 confirmações. O trade-off para o cliente depende de a exchange manter sua contagem, alterá-la ou pausar temporariamente os depósitos durante a transição.

Os pagamentos enviados entre carteiras pessoais têm um gargalo prático diferente. A carteira do destinatário precisa verificar a cadeia em busca de transações que consiga descriptografar. Um primeiro bloco mais rápido ajuda, mas alguém que abre uma carteira que ficou offline por dias ainda pode gastar tempo se atualizando. Os limites para ações protegidas abordam essa outra parte da experiência ao limitar a quantidade de trabalho que cada bloco pode impor à carteira.

Essa distinção também importa para as medições após a ativação. Uma amostra de depósitos feitos pouco antes e pouco depois do fork poderia conter indisponibilidade do serviço ou saques retidos para revisão manual. Isso seria uma base fraca para estimar tempos normais de confirmação. Uma amostra mais comparável acompanharia quando os usuários enviaram uma transação, quando ela apareceu pela primeira vez em um bloco e quando um provedor a creditou. Dividir a espera nesses intervalos ajuda a isolar a parte que o consenso realmente altera.

Três vezes mais blocos mudam a aparência dos resultados da mineração

Os mineradores podem comparar as recompensas diárias antes e depois da atualização separando o subsídio do componente de taxas. O subsídio é o valor alocado pelas regras do protocolo. As taxas de transação variam conforme as transações que os usuários enviam e as taxas incluídas nos blocos.

Usando apenas as metas de blocos, um dia contém aproximadamente 1.152 blocos a 75 segundos e 3.456 a 25 segundos. Com um terço do subsídio por bloco, isso produz o mesmo subsídio agregado programado ao longo do dia. A contagem realizada de blocos pode variar, então um dia individual ainda pode ficar acima ou abaixo de qualquer um dos parâmetros de referência.

Um operador de pool de mineração, portanto, terá que comparar os retornos no mesmo período de tempo. Um gráfico mostrando o pagamento por bloco cairá na transição por design. Um gráfico mostrando o subsídio agregado ao longo de uma semana faz uma pergunta diferente. As taxas da pool, os custos de hardware, a eletricidade e a parcela do poder computacional da rede que um minerador controla determinam quanto esse minerador mantém.

A divisão das taxas pode ser avaliada com um cálculo separado. Se o subsídio representa 99% das recompensas de um minerador antes da atualização e as taxas representam 1%, cortar a parcela das taxas em 60% reduziria as recompensas totais em 0,6%, assumindo que todas as outras entradas permaneçam constantes. Se as taxas representam 10%, a mesma mudança reduziria as recompensas totais em 6%. Ambos os exemplos são hipotéticos e isolam a regra de taxas das mudanças no uso e na concorrência.

A primeira comparação para pools de mineração é igualmente sensível à janela selecionada. Tomar uma hora de cada lado da ativação pode dar resultados incomuns se uma pool tiver encontrado vários blocos ou algumas transações excepcionalmente grandes caído próximas umas das outras. Medir as taxas totais e o subsídio emitido ao longo do mesmo número de horas dá um resultado mais interpretável. As regras de crédito de uma pool podem separar ainda mais quando a receita é registrada onchain de quando os mineradores individuais veem o saldo em sua conta.

Como ilustração, uma pool que representa uma parcela constante de blocos bem-sucedidos esperaria registrar mais descobertas de blocos em um dia sob o novo cronograma. A recompensa menor associada a cada descoberta muda as unidades nas quais sua renda chega. Se a pool relata recompensas por bloco sem também mostrar quantos encontrou e quanto pagou por unidade de trabalho, um usuário olhando o painel pode confundir uma mudança na distribuição com uma mudança na renda. É por isso que uma comparação diária precisa tanto do subsídio quanto dos componentes de taxas, juntamente com uma medida comparável de participação.

A reserva muda quando as taxas sustentam os mineradores

Sob o Mecanismo de Sustentabilidade da Rede, o protocolo mantém um registro de valor reservado para reemissão posterior. Esse pool dá à rede uma fonte de recompensas futuras que se originaram em taxas ou valores elegíveis não reclamados. O saldo da reserva e as regras para sacá-lo determinam quanto pode ser disponibilizado ao longo do tempo.

Dois períodos podem, portanto, ter relações diferentes entre uso e gasto com segurança. Enquanto as taxas estão sendo acumuladas, os mineradores atuais mantêm apenas a parcela paga imediatamente. Uma vez que a reemissão está programada para começar, os mineradores futuros podem receber recompensas de atividade que aconteceu muito antes. Os participantes que coletaram a parcela original das taxas e aqueles que posteriormente recebem as recompensas financiadas pela reserva podem ser diferentes.

O design preserva uma razão para os mineradores incluírem transações que pagam taxas por meio da parcela que retêm. Também levanta uma questão sobre quanto de demanda de blocos é necessária antes que a reserva se torne economicamente significativa. Se as taxas forem modestas em comparação com o subsídio, uma grande porcentagem das taxas ainda pode equivaler a uma pequena parcela dos fundos que sustentam a mineração.

Uma proposta separada para direcionar uma parcela adicional das recompensas para a reserva ilustra essa distinção. A contribuição já especificada no NU7 e uma proposta para financiamento futuro são escolhas de política separadas. Uma descrição das regras de lançamento deve usar os parâmetros na especificação de atualização e manter as propostas de financiamento posteriores distintas.

A reserva cria uma questão diferente para quem acompanha a emissão. O valor reservado a partir das taxas pode ser contado quando entra na reserva e novamente quando as regras eventualmente o reemitirem. Esses são eventos separados na vida do mesmo valor. Uma visão contábil que trata cada um como oferta nova pode obscurecer quanto está disponível para os usuários em uma determinada altura. O ZIP 259 fornece as datas dos eventos em blocos, o que permite a um observador saber qual regra está em vigor sem extrapolar a partir de uma previsão de relógio de parede.

A transição de software afeta serviços, bem como operadores de nós

O Zebra 7.0.0 é a versão estável que suporta a ativação na mainnet. Um serviço que usa um nó mais antigo pode continuar executando o software mesmo quando sua visão da cadeia não segue mais a rede atualizada. Uma exchange, backend de carteira ou pool, portanto, precisa considerar o que sua própria infraestrutura vê na altura de ativação.

A distinção torna-se visível quando diferentes serviços relatam alturas de bloco diferentes. Um front end pode permanecer acessível mesmo que o nó por trás dele pare de rastrear a cadeia que os usuários esperam. Para uma empresa que credita saldos, a questão relevante é se seu sistema interno segue as mesmas regras de consenso que a rede na qual os clientes estão enviando fundos.

Os preparativos de lançamento incluíram correções que afetam a sincronização e a verificação. Essas correções abordam o comportamento operacional juntamente com a atualização de consenso. Para um operador, a troca, portanto, envolve mais do que verificar o intervalo de bloco anunciado. Inclui executar uma versão compatível e garantir que as dependências do serviço continuem a ler e processar a cadeia corretamente.

A testnet proporcionou um lugar para os desenvolvedores exercitarem as regras antes da mudança na mainnet. Ela fornece evidências de que o código pode processar blocos sob as novas configurações em um ambiente de teste. A adoção na mainnet depende dos operadores que suportam carteiras reais, depósitos e mineração. Seu comportamento torna-se observável através da cadeia e de quaisquer avisos de serviço emitidos em torno da ativação.

Uma exchange se preparando para a transição tem que reconciliar dois registros. Seu nó rastreia blocos e as transações neles, enquanto seu livro-razão de clientes registra o que os usuários podem negociar ou sacar. Uma atualização de cadeia pode prosseguir enquanto a exchange mantém esses livros-razão separados por um período, particularmente se o serviço quiser confirmar que os depósitos observados antes da atualização permanecem visíveis para sua infraestrutura atualizada. O tempo que um cliente espera é então governado por quando o serviço reconcilia os livros-razão e retoma o crédito nas contas.

Sprout dá à atualização uma consequência irreversível para alguns fundos

O pool protegido original é uma parte legada da história do Zcash. Pools posteriores deram à rede diferentes maneiras de representar transações protegidas, mas um saldo deixado no Sprout ainda depende dos formatos que podem gastar desse pool. O NU7 altera as versões de transação válidas, o que torna a questão do formato material para o proprietário de um saldo legado.

Um saldo de carteira exibido como ZEC dá ao proprietário o valor em moeda. Pode ser necessário mais informação para identificar o pool e o caminho de gasto disponível. A ação relevante para um detentor legado é mover fundos através de uma rota compatível antes da mudança de consenso. Atualizar o software por si só não pode criar uma transação válida depois que o formato antigo deixa de ser aceito.

Um número público para o saldo em um pool não pode dizer a um observador quantos detentores o estão usando ativamente ou que porção é recuperável com chaves ainda disponíveis. Um pequeno número de grandes saldos e muitos pequenos saldos inativos poderia produzir o mesmo total. A regra se aplica aos fundos remanescentes no pool na ativação, independentemente de como eles chegaram lá.

Essa consequência é separada do limite de oferta monetária e das taxas reservadas para recompensas futuras. O tratamento do protocolo de uma versão de transação antiga remove um caminho de gasto. A regra de reserva contabiliza as taxas que podem ser reemitidas posteriormente de acordo com seu próprio cronograma. A especificação de atualização trata essas como mudanças distintas, com transações de versão 4 inválidas a partir da altura de ativação na mainnet.

O prazo do Sprout é a exceção de uma história que, de outra forma, é medida em intervalos e médias. Carteiras e exchanges podem revisar as regras de confirmação, e a receita de mineração variará com a atividade. A regra que afeta o pool legado é fixada na altura de ativação. Uma vez que a cadeia atualizada aplique a restrição, a disponibilidade de uma carteira mais nova por si só não restaura a capacidade de gastar um saldo deixado ali.

O que observar

• Ativação. A rede atingindo o bloco 3.543.405 e produzindo blocos subsequentes sob as novas regras.
• Políticas de depósito. Exchanges publicando novos limites de confirmação ou reabrindo depósitos pausados.
• Atividade do Orchard. Ações observadas por bloco e tempo decorrido em períodos de maior movimento.
• Receita de mineração. Recebimentos diários de taxas e receita de subsídio comparados em janelas equivalentes.
• Sprout. Avisos de carteira especificando quais saldos legados eram elegíveis para movimentação antes da ativação.

Perguntas frequentes