Assisti à mesma equação sendo verificada duas vezes hoje e quase deixei passar por quê.

Ao ler um relatório de segurança do Dusk, uma fórmula de taxas: multiplicar o limite de gás pelo preço do gás equivale à taxa máxima. Isso é aplicado duas vezes: uma ao entrar no mempool e outra durante a execução dentro da VM.

Na primeira leitura, pensei que fosse redundância. Correia e suspensórios, nada para investigar.

Não sobreviveu ao próximo parágrafo. A aplicação apenas no mempool não foi suficiente; um proponente malicioso não é obrigado a incluir apenas a versão “honesta no mempool” dos campos de uma transação.

Esse é o problema real. Um valor provado ou assinado em uma parte de uma transação não vincula todas as camadas que depois o consomem. Alguém pode se comprometer com uma taxa legítima antecipadamente e ainda assim fornecer uma taxa diferente para a execução, a menos que a execução recuse confiar na verificação anterior.

Assine e comprove a taxa máxima, o mempool verifica; o proponente monta o bloco sem obrigação de preservar isso. A VM executa a lógica de reembolso com base no que realmente chegou.

Volta sempre a isso: a maior parte da confiança recai sobre o proponente permanecer honesto entre os pontos de verificação — justamente a suposição para a qual existe a segunda checagem porque não dá para confiar.

Não sei quantos outros campos nesse pipeline recebem só uma camada dessa proteção.

O que acontece com essa checagem sob congestão real, quando os proponentes estão sob pressão para construir rápido? 👍
#dusk $DUSK @Dusk