Aquí tienes un breve resumen sobre los avances recientes en los protocolos de resistencia a la censura (CR). En general, hay 4 tipos de CR de los que la gente parece hablar: > CR a corto plazo (STCR): si un tx alcanza la pipeline de inclusión honesta antes de un corte, entonces cualquier siguiente bloque comprometido lo incluye. Un censor solo puede excluir retrasando la viveza de la propia cadena. > CR selectivo (SCR): el atacante no puede señalar un solo test específico (o un pequeño conjunto) para censura mientras permite que todo lo demás pase normalmente. > CR de largo plazo (LHCR): un tx no puede mantenerse fuera para siempre. tanto STCR como SCR importan para DeFi sensible al tiempo, pero STCR trata sobre la velocidad a la que entras, mientras que SCR trata sobre si un atacante puede elegir que seas lento. El LHCR importa para las escotillas de escape enrolladas y las retiradas. --------------------------------------- Mi mapeo actual de protocolos recientes: > BigDipper da el STCR explícito más fuerte, puede integrarse en un consenso al estilo PBFT > propuesta MCP se dirige a SCR + ocultación al tener k proponentes concurrentes y una capa DA intermedia basada en relés > Sedna es un plugin de envío de difusión de transmisiones para MCPs en el lado del usuario, con el fin de aliviar la tensión entre coste de replicación y CR en los diseños MCP > Mysticeti mejora la inclusión práctica mediante concurrencia, pero no da garantías explícitas a nivel STCR/SCR de tx > FOCIL: LHCR mediante listas de inclusión forzadas por elección de fork, pero depende de que el comité sea altruista + los atestiguadores observen las ILs, y tiene una estrategia inestable para la inclusión de tx > AUCIL mejora FOCIL haciendo que la producción de IL sea compatible con incentivos, haciendo que los miembros del comité sean racionales y los atestiguadores solo tengan que comprobar pruebas de validez para la inclusión en IL, pero asumiendo una sincronización global de mempool. en cuanto a límites de imposibilidad, el reciente artículo "The latency cost of censor resistance" sostiene que el CR multiproponente añade un coste de latencia de al menos 2 rondas al BFT base. sin embargo, su definición de CR está más alineada con STCR que con SCR/LHCR. ¿Etiquetar @ittaia para confirmar si esa era la intención de este artículo?

@_julianma Ah, veo que los atestiguadores se niegan a atestiguar el bloqueo del proponente equivocado si no incluyen listas de IL, lo que hace que ese bloqueo ni siquiera se confirme, lo cual cumple con STCR.