Uma coisa me fez parar de rolar. Não era o próprio bug. Era a frase dizendo que a janela de corrida só existe entre uma leitura de banco de dados e uma gravação de banco de dados. Isso parecia um detalhe de implementação pequeno até eu começar a pensar no que isso diz sobre o modelo de execução do Babylon.
Eu parei de procurar um atacante e comecei a procurar o fluxo. Voltei para comparar o caminho de validação e passei um tempo rastreando onde as mudanças de estado realmente se tornam definitivas. Depois eu peguei um café e reli a sequência novamente. Quanto mais eu olhava, menos isso parecia ser apenas um problema de segurança. Parecia mais uma escolha de design sobre quanto risco de temporização o protocolo está disposto a tolerar.
O que aos poucos ficou óbvio é que a proteção não é construída em torno de tornar a corrida impossível. Ela é construída em torno de tornar a oportunidade extremamente pequena. Essas são duas ideias diferentes. A primeira remove a condição. A segunda reduz a probabilidade. A diferença é fácil de perder porque as duas podem parecer seguras por fora.
Essa é a parte que ninguém coloca no slide. O Babylon depende de validadores e serviços processando o estado em uma ordem previsível, ao mesmo tempo em que aceita que ainda existe uma pequena lacuna de execução. O protocolo, na prática, está dizendo que o custo operacional de remover todas as corridas possíveis é maior do que o risco restante de deixar uma única janela estreita.
Talvez esse seja o trade-off certo para desempenho. Talvez a exposição restante seja tão pequena que adicionar mais sincronização criaria problemas maiores em outro lugar.
O que eu ainda não consigo decidir é onde o Babylon traça a linha entre uma suposição de temporização aceitável e uma garantia de protocolo que nunca deveria depender de temporização.
@BabylonLabs_io
#baby $BABY
Eu parei de procurar um atacante e comecei a procurar o fluxo. Voltei para comparar o caminho de validação e passei um tempo rastreando onde as mudanças de estado realmente se tornam definitivas. Depois eu peguei um café e reli a sequência novamente. Quanto mais eu olhava, menos isso parecia ser apenas um problema de segurança. Parecia mais uma escolha de design sobre quanto risco de temporização o protocolo está disposto a tolerar.
O que aos poucos ficou óbvio é que a proteção não é construída em torno de tornar a corrida impossível. Ela é construída em torno de tornar a oportunidade extremamente pequena. Essas são duas ideias diferentes. A primeira remove a condição. A segunda reduz a probabilidade. A diferença é fácil de perder porque as duas podem parecer seguras por fora.
Essa é a parte que ninguém coloca no slide. O Babylon depende de validadores e serviços processando o estado em uma ordem previsível, ao mesmo tempo em que aceita que ainda existe uma pequena lacuna de execução. O protocolo, na prática, está dizendo que o custo operacional de remover todas as corridas possíveis é maior do que o risco restante de deixar uma única janela estreita.
Talvez esse seja o trade-off certo para desempenho. Talvez a exposição restante seja tão pequena que adicionar mais sincronização criaria problemas maiores em outro lugar.
O que eu ainda não consigo decidir é onde o Babylon traça a linha entre uma suposição de temporização aceitável e uma garantia de protocolo que nunca deveria depender de temporização.
@BabylonLabs_io
#baby $BABY