Sobre (de)centralização e (definindo) latência: Primeiro, existem dois tipos de centralização: física vs. lógica. Exemplos: X(.com) é logicamente centralizado, mas logicamente descentralizado. Uma rede PoS pode ser logicamente descentralizada, mas fisicamente centralizada (como a Hyperliquid, cujos validadores estão predominantemente em ou perto de Tóquio, Japão). Qual é a relação entre centralização e latência? A resposta curta é que a centralização *lógica* pode sempre fornecer (potencialmente) latências mais baixas de muitos tipos diferentes, à custa da resistência à censura. Como exatamente definimos a latência de forma mais precisa? Esta é a minha estrutura: para especificar a latência, precisamos de três parâmetros: (1) início da medição, (2) fim da medição e (3) garantia fornecida. Por exemplo, o início da medição pode ser quando um usuário envia uma transação para um nó ou pode ser quando um sequenciador recebeu essa transação. No final, as garantias para os participantes do sistema e usuários são as mais importantes. Aqui estão algumas latências que são de interesse: 1. Latência de confirmação de inclusão: o início é quando um usuário envia a transação, o fim é quando um usuário recebe uma confirmação de que a transação será incluída com alguma garantia. 2. Latência de execução de ponta a ponta: o início é quando um usuário envia a transação, o fim é quando o usuário recebe o efeito total da transação (por exemplo, preço de execução de uma troca de mercado DeFi). 3. Latência de execução de ponta a ponta e finalidade: como o 2 acima, mas o fim é medido quando a transação também é finalizada por consenso. Novamente, todas essas medições de latência poderiam ser menores para sistemas logicamente centralizados, mas fisicamente descentralizados, à custa da resistência à censura (e outras propriedades que vêm com a descentralização).