Dia 3/5 ~ Desempacotando confirmações ~ Como as cadeias modelam a finalidade e por que seu aplicativo precisa pensar probabilisticamente ~ Ontem, exploramos como a "confirmação" depende da cadeia. Hoje, vamos desvendar como essas cadeias realmente modelam a finalidade e por que seu aplicativo precisa ir além de uma visão binária de "confirmado versus não" A maioria das redes não oferece uma única resposta limpa. Em vez disso, você está trabalhando com um espectro: 1. finalidade determinística: cadeias usando consenso no estilo BFT (por exemplo, cosms, alguns alt-DAs), liquidação L1 (por exemplo, ethereu após finalidade) e a maioria dos PoS oferecem garantias rígidas - uma vez finalizada, uma transação não pode ser revertida. 2. finalidade probabilística: As cadeias POW (como Bitcoin) e Ethereum "Pre-Finality" oferecem garantias estatísticas. É improvável que um tx enterrado a 12 quarteirões de profundidade seja reorganizado - mas não impossível. quanto mais profundo, mais seguro. 3. Sinais suaves: confirmações de sequenciador, inclusão de mempool, relés de construtor - eles são rápidos, mas trazem riscos. Esses sinais são úteis, mas devem ser tratados com cuidado. Os aplicativos geralmente tratam essas fontes igualmente: → "esperar X blocos" → "confie no sequenciador" → "verificar inclusão" Mas essa abstração quebra assim que você interopera. Um aplicativo de cadeia cruzada pode abranger: ~ Uma cadeia BFT de finalização rápida ~ Um rollup otimista com janelas de fraude de 7 dias ~ Um L1 com finalidade probabilística ~ Uma cadeia com garantias apenas de sequenciador A lógica do aplicativo não pode codificar uma regra de tamanho único. você precisa perguntar: "Qual é a probabilidade de este tx reverter? E quem impõe isso?" == > finalidade não é binária e a compensação entre velocidade e segurança não é linear. (Multisigs, por exemplo, não ganham velocidade ou confiança.) → o que você precisa é de confiança programável e sensível à cadeia == uma maneira de expressar o que "confirmado" significa em cada contexto