Sobre (des)centralização e (definição) 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* sempre pode fornecer latência (potencialmente) menor de muitos tipos diferentes, às custas da resistência à censura. Como exatamente definimos a latência com mais precisão? 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 recebe essa transação. Em última análise, as garantias para os participantes e usuários do sistema 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 um swap de mercado defi). 3. Execução de ponta a ponta e latência de finalidade: como 2 acima, mas o final é medido quando a transação também é finalizada por consenso. Novamente, todas essas medidas de latência podem ser menores para sistemas logicamente centralizados, mas fisicamente descentralizados, com perda de resistência à censura (e outras propriedades que vêm com a descentralização).