Sobre la (de)centralización y la (definición de) latencia: Primero, hay dos tipos de centralización: física vs. lógica. Ejemplos: X(.com) está lógicamente centralizado, pero lógicamente descentralizado. Una red PoS puede estar lógicamente descentralizada pero físicamente centralizada (como Hyperliquid, cuyos validadores están predominantemente en o cerca de Tokio, Japón). ¿Cuál es la relación entre centralización y latencia? La respuesta corta es que la *centralización* lógica puede siempre proporcionar (potencialmente) una latencia más baja de muchos tipos diferentes, a expensas de la resistencia a la censura. ¿Cómo definimos la latencia de manera más precisa? Este es mi marco: para especificar la latencia necesitamos tres parámetros: (1) inicio de la medición, (2) fin de la medición y (3) garantía proporcionada. Por ejemplo, el inicio de la medición podría ser cuando un usuario envía una transacción a un nodo o podría ser cuando un secuenciador ha recibido esa transacción. En última instancia, las garantías para los participantes del sistema y los usuarios son lo más importante. Aquí hay algunas latencias que son de interés: 1. Latencia de confirmación de inclusión: el inicio es cuando un usuario envía la transacción, el fin es cuando un usuario recibe una confirmación de que la transacción será incluida con alguna garantía. 2. Latencia de ejecución de extremo a extremo: el inicio es cuando un usuario envía la transacción, el fin es cuando el usuario recibe el efecto completo de la transacción (por ejemplo, el precio de ejecución de un intercambio en un mercado DeFi). 3. Latencia de ejecución de extremo a extremo y finalización: como el 2 anterior, pero el fin se mide cuando la transacción también es finalizada por consenso. Nuevamente, todas estas medidas de latencia podrían ser más bajas para sistemas lógicamente centralizados pero físicamente descentralizados, a costa de la resistencia a la censura (y otras propiedades que vienen con la descentralización).