A frase que mudou o Midnight para mim foi direta: uma transação pode falhar na fase falível e ainda deixar efeitos garantidos para trás.
Uma vez que li isso, não consegui voltar ao modelo mental normal de criptomoeda. Os documentos do Midnight dizem que as transações passam por uma verificação de conformidade, depois uma fase garantida, e então uma fase falível. Se ocorrer uma falha na fase garantida, a transação não é incluída. Mas se a falha ocorrer depois, os efeitos garantidos ainda se aplicam e o livro-razão registra um sucesso parcial. Os documentos também dizem que as taxas para todas as fases são coletadas na fase garantida e são perdidas se a fase falível falhar. Isso significa que a falha no Midnight nem sempre é um retrocesso. Às vezes, é resíduo.
Isso é um fato de produto muito maior do que parece à primeira vista.
Muitas pessoas ainda pensam sobre a falha de transação em termos simples. Funcionou, ou falhou e nada realmente aconteceu. O Midnight enfraquece esse atalho. Suas semânticas são escalonadas. Algumas partes da ação podem se tornar reais antes que as partes posteriores possam falhar. Os documentos deixam claro que a execução de fase pode incluir coisas como inserir compromissos, inserir anuladores, verificar raízes passadas e atualizar o conjunto de raízes passadas. Portanto, quando uma condição falível quebra, a transação pode já ter mudado o estado do livro-razão de maneiras que o aplicativo não pode fingir que não aconteceu.
A taxa já se foi também.
Essa combinação é o que torna o modelo sério. Uma falha tardia não é apenas uma mensagem de erro. Pode ser um plano falhado em cima de um prefixo bem-sucedido.
A maneira mais clara de ver o problema é com um fluxo de acesso privado. Imagine um aplicativo Midnight onde um usuário tenta exercer alguma permissão privada. O aplicativo quer que a ação pareça simples. O usuário pressiona uma vez e espera uma resposta clara. Por trás da tela, no entanto, a transação pode passar na conformidade, entrar na fase garantida, coletar taxas e aplicar os efeitos que pertencem a ela. Então, uma condição falível posterior falha. Talvez alguma regra de negócios não tenha sido satisfeita. Talvez um ramo posterior não pôde ser concluído. Do ponto de vista do usuário, a ação falhou. Do ponto de vista do Midnight, a falha chegou depois que o livro-razão já havia se movido.
Isso não é um pequeno caso de borda semântica. Isso é comportamento do produto.
E o Midnight não trata esse desvio como acidental. Os documentos dizem que se uma chamada de contrato contém seções garantidas e falíveis, a seção falível deve começar com ckpt. Eu gosto desse detalhe porque torna a arquitetura honesta. A linha entre “isso deve sobreviver” e “isso pode ainda abortar” é explícita. Os construtores não estão apenas decidindo o que sua lógica privada faz. Eles estão decidindo o que o sistema pode manter se a intenção completa nunca chegar.
É aí que a pressão de design começa.
Um construtor pode olhar para um contrato do Midnight, ver que as provas estão corretas e ainda assim perder a pergunta mais difícil. Se essa ação falhar tardiamente, o que já se tornou verdade. Se a resposta for “alguns compromissos, alguns anuladores, a taxa e um registro de sucesso parcial,” então o aplicativo não pode falar sobre falha da mesma forma que um sistema de rollback normal faria. A lógica de retry muda. A comunicação com o usuário muda. O suporte muda. Um estado de erro vermelho não pode mais significar “nada aconteceu.”
Esse é o verdadeiro trade-off. O Midnight obtém um modelo de transação mais expressivo. O trabalho garantido pode ser separado do trabalho falível posterior. Isso é útil. Dá aos construtores mais controle sobre a estrutura de execução. Mas o preço é que os aplicativos têm que projetar em torno do sucesso parcial como um estado de primeira classe. Não é um bug. Não é um acidente de implementação. É um estado.
Se eles não o fizerem, o produto começa a mentir.
O usuário vê “falhou.” O livro-razão diz “parcialmente concluído.” A taxa se foi de qualquer forma. Essa diferença é onde a confusão começa. Uma equipe pode facilmente interpretá-la mal também. Eles podem tratar o problema como uma falha normal de tempo de execução, quando o verdadeiro problema é que o modelo de transação permitiu que alguns efeitos sobrevivessem por design. O Midnight não escondeu isso deles. Os documentos disseram a eles. O erro é fingir que a experiência do usuário pode permanecer tudo ou nada depois que a semântica deixou de ser tudo ou nada.
É por isso que eu acho que o modelo de execução do Midnight merece mais atenção do que recebe. As pessoas vão falar sobre privacidade, divulgação seletiva e o que pode ficar escondido. Tudo bem. Mas um produto sério não é definido apenas pelo que pode esconder. É também definido pelo que permite que a falha signifique. O Midnight muda esse significado de uma maneira muito exata. Uma ação privada falhada ainda pode ter uma metade frontal irreversível.
Portanto, o verdadeiro padrão de revisão não pode parar em “o comprovante verifica.” Também deve perguntar: quais efeitos foram colocados na fase garantida, o que sobrevive a uma falha tardia, e o aplicativo explica isso honestamente ao usuário. No Midnight, esses não são detalhes secundários de UX. Eles fazem parte da semântica.
Os aplicativos Midnight mais fortes serão aqueles que tratam o sucesso parcial como um estado real do produto desde o primeiro dia. Os mais fracos continuarão chamando isso de falha e esperando que ninguém perceba que o livro-razão já se moveu.
@MidnightNetwork $NIGHT #night
