Continuo a notar como a aprovação de políticas é tratada com facilidade como prova de que uma transação terá sucesso. Quanto mais leio a documentação do protocolo, mais acho que essas são duas perguntas bem diferentes. Uma pergunta: "Essa ação deve ser permitida?" A outra pergunta: "Ela pode realmente ser concluída?"

Essa distinção importa muito além de um único protocolo. Em sistemas de contratos inteligentes, a execução pode falhar por muitos motivos: o contrato de destino pode reverter, os fundos necessários podem estar ausentes ou condições inesperadas podem surgir após a autorização. Tratar aprovação e execução como o mesmo evento pode ocultar onde o problema real ocorreu.

Ao analisar com mais atenção o fluxo de intenção bruta documentado do Newton Protocol, um detalhe chamou atenção. Se o contrato de destino reverter, a falha é apresentada separadamente, seja ao propagar o motivo original da reversão ou ao retornar um erro de execução. Em outros exemplos, um erro customizado ExecutionFailed() marca que a política foi aprovada, mas a própria transação não foi.

O que me interessou não foi o caminho adicional de falha. Foi o limite claro. Uma atestação válida prova que os operadores aprovaram a intenção de acordo com a política, e não que o contrato de destino tem garantia de executar com sucesso. Até mesmo a documentação do Newton observa que problemas de execução devem ser depurados independentemente, reforçando que autorização e execução resolvem problemas diferentes.

Ainda estou me perguntando se as aplicações vão comunicar essa distinção com clareza aos usuários. Separar a aprovação da política da execução torna os sistemas descentralizados mais fáceis de entender, ou as transações aprovadas-but-failed criarão uma nova confusão?

@NewtonProtocol

$NEWT


$TLM

$SYN

#NEWT