Eu ficava pensando em como instituições automatizam milhares de transações em blockchain sem ficar quebrando constantemente suas próprias regras de segurança.
No começo, parecia um problema simples de permissões.
Quanto mais eu olhava, mais percebia que era um problema de timing.
As contas inteligentes modernas raramente processam uma única solicitação de forma isolada. Estratégias automatizadas de negociação, operações de tesouraria e sistemas de pagamentos corporativos frequentemente enviam várias transações quase simultaneamente. De fora, cada solicitação parece independente.
No entanto, internamente, elas podem depender exatamente do mesmo estado de permissão.
Isso cria um interessante desafio de engenharia.
Imagine uma conta inteligente com um limite de gastos predefinido.
A transação A chega primeiro.
O mecanismo de autorização verifica se o limite restante é suficiente e aprova a solicitação.
Apenas alguns milissegundos depois, a Transação B entra no pipeline de validação.
Como a Transação A ainda não liquidou on-chain, o mecanismo de validação ainda observa o limite disponível original.
Ele também aprova a Transação B.
Nenhuma transação está tecnicamente incorreta.
As duas decisões foram tomadas usando informações que eram válidas no momento em que cada avaliação começou.
O problema é que as duas aprovações dependeram da mesma capacidade de permissão disponível.
Essa situação é comumente descrita como uma condição de corrida, mas dentro de sistemas de autorização corporativos ela se torna algo ainda mais importante: o intercalamento de permissões.
A própria blockchain não é responsável por criar o problema.
O problema existe antes mesmo de a transação chegar ao consenso.
Ele começa dentro do fluxo de autorização responsável por decidir se a execução deve ser permitida.
À medida que a automação se torna mais sofisticada, essa janela de tempo fica cada vez mais significativa.
Grandes organizações raramente executam ações isoladas.
Sistemas de tesouraria podem distribuir fundos entre vários protocolos ao mesmo tempo.
Os motores de risco podem rebalancear carteiras continuamente.
As estratégias de market-making podem gerar múltiplas intenções em milissegundos.
Sem coordenação adicional, cada solicitação concorrente compete pelo mesmo estado de permissão.
Uma possível solução é o travamento de sequência determinística.
Em vez de permitir que cada solicitação avalie permissões independentemente, a camada de autorização reserva temporariamente a capacidade disponível para a primeira transação aprovada antes de avaliar a próxima.
Isso cria uma ordem de execução previsível mesmo antes da liquidação ocorrer on-chain.
A abordagem reduz um pouco o paralelismo, mas melhora dramaticamente a consistência.
Do ponto de vista da infraestrutura, esse trade-off se torna cada vez mais atraente à medida que os volumes de transações continuam crescendo.
Também destaca uma direção interessante para frameworks de autorização programável como @NewtonProtocol.
À medida que os sistemas de permissão se tornam mais expressivos, apenas validar solicitações rapidamente pode não ser mais suficiente.
A infraestrutura também deve garantir que múltiplas decisões simultâneas permaneçam logicamente consistentes entre si.
A velocidade de execução é importante.
A precisão das permissões é igualmente importante.
A próxima geração de mecanismos de autorização talvez não seja definida apenas por quantas transações eles aprovam a cada segundo.
Elas podem ser definidas pela confiabilidade com que evitam que essas transações aprovem os mesmos recursos duas vezes.
Isso parece menos um problema de escalabilidade de blockchain...
...e muito mais como um problema de sistemas distribuídos.
#Newt #BinanceTurns9 #BinancePickAndWin #ZcashRises1190%OverPastYear #SKHynixSharesFallInSeoulAfterUSDebut @NewtonProtocol $NEWT $ZEC $CL