Resumiendo el avance en MonadBFT Ayer, Category Labs publicó el documento de MonadBFT, que describe el mecanismo de consenso que impulsará a Monad en la red principal. MonadBFT es un avance significativo en la investigación de consenso, ya que es la primera vez que Pipelined HotStuff se vuelve resistente a la bifurcación de cola. La bifurcación de cola se produce cuando una ranura perdida hace que la propuesta anterior se descarte y se vuelva a minar. Es un problema grave en las formulaciones anteriores de Pipelined HotStuff, ya que abre ataques MEV multibloque que desestabilizan el consenso. Aliviar este problema es un gran problema porque nos brinda todos los beneficios de Pipelined HotStuff (bloques frecuentes, baja latencia, grandes conjuntos de validadores) mientras evita el mayor inconveniente. MonadBFT también ofrece una gran mejora para la finalidad. Presenta una finalidad especulativa de una sola ranura (500 ms) y una finalidad dura de dos ranuras (1s). "Finalidad especulativa" significa "finalidad que se revertirá solo en caso de equívoco (doble firma) por parte de la mayoría de los validadores". El equívoco es una ofensa importante en la mayoría de los sistemas de blockchain y comúnmente se penaliza con cortes; Cuanto mayor sea la penalización por el equívoco, más cerca se puede pensar en la "finalidad especulativa" de la finalidad. La finalidad especulativa de una ranura es un gran desbloqueo para aplicaciones de alto rendimiento, que pueden mostrar con confianza el estado actualizado del mundo inmediatamente después de recibir el siguiente bloque. Estas propiedades hacen de MonadBFT un gran avance en el consenso, y un complemento digno para otras mejoras compuestas en Monad, incluyendo la Ejecución asíncrona, la Ejecución Paralela Optimista y MonadDb. El resto de este artículo sirve como un resumen de cómo las sucesivas mejoras en HotStuff se han construido unas sobre otras, con el fin de explicar el problema que resuelve MonadBFT. En resumen: 1. HotStuff nos da complejidad de comunicación lineal para que podamos tener grandes conjuntos de validadores, pero no es muy eficiente 2. Pipelined HotStuff nos da eficiencia y baja latencia al proponer bloques en cada ranura, pero sufre el problema de las bifurcaciones de cola 3. MonadBFT nos da la resistencia de la horquilla de cola y la finalidad especulativa de una ranura --- HotStuff: La complejidad de la comunicación lineal permite grandes cantidades de nodos Los algoritmos de HotStuff se completan en el transcurso de varias rondas de comunicación, que generalmente toman la forma de comunicación de "salida de abanico de salida, de entrada de ventilación" directamente de los líderes a los validadores y de vuelta a los líderes. Cada ronda comienza con el líder enviando un mensaje directamente a otros validadores, cada uno de los cuales envía un mensaje firmado que atestigua haber recibido el mensaje. Siempre que una supermayoría (2/3) de los validadores envíe una certificación, cada ronda termina con el líder agregando las certificaciones firmadas en un Certificado de Quórum (QC), que sirve como prueba de que la supermayoría atestiguó el mensaje anterior. Los algoritmos de HotStuff tienen múltiples rondas de comunicación como esta. - El primer mensaje del líder es una propuesta de bloque - El segundo mensaje es el control de calidad de esa propuesta de bloque - El tercer mensaje es un control de calidad sobre el control de calidad anterior (es decir, un control de calidad sobre control de calidad) - y así sucesivamente Si el procedimiento se interrumpe en cualquier momento antes de la finalización, el bloque no finaliza y se descarta; Las transacciones de ese bloque tendrán que volver a incluirse en el siguiente bloque. El protocolo HotStuff original no tiene canalización y tiene 3 rondas de comunicación antes de la finalización; El mismo validador desempeña el papel de líder en cada ronda. --- Pipelined HotStuff: Un nuevo bloque en cada ranura aumenta la eficiencia La canalización es lo que todos hacemos intuitivamente cuando tenemos dos cargas de ropa para completar. En lugar de esperar a que la carga 1 termine el ciclo completo antes de comenzar la carga 2, en la tubería colocamos la carga 1 en la secadora al mismo tiempo que la carga 2 entra en la lavadora. Puede pensar en el HotStuff original como ese enfoque ingenuo para lavar la ropa (no comience con la carga 2 hasta que la carga 1 esté completamente terminada), mientras que Pipelined HotStuff realiza el comportamiento intuitivo de progresar varias cargas de ropa de manera escalonada. En Pipelined HotStuff escalonamos las propuestas, de modo que haya un nuevo bloque propuesto en cada ronda, con el nuevo bloque superpuesto al mensaje que lleva el control de calidad del bloque anterior. Las propuestas en bloque avanzan hacia la finalidad en el transcurso de múltiples rondas. Los beneficios de la canalización son significativos. La canalización aumenta la densidad de las propuestas de bloques, ya que se realiza una propuesta de bloque en cada ranura, lo que aumenta el rendimiento y reduce el tiempo de finalización. Sin embargo, hay un inconveniente importante de la tubería, que se ilustra mejor con un ejemplo. Supongamos que los líderes de los bloques N, N+1 y N+2 son Alice, Bob y Charlie. Si Bob pierde su espacio, entonces la propuesta de Alice también será invalidada, porque el mensaje de Bob lleva tanto su propuesta como un QC para la propuesta de Alice. Cuando esto sucede, Charlie termina siendo llamado para producir un bloque como si la propuesta de Alice nunca hubiera existido. Nos referimos a este comportamiento como "bifurcación de cola", y se puede considerar como una mini-reorganización de profundidad 1. La posibilidad de bifurcación de la cola tiene consecuencias significativas, porque las ranuras perdidas no son necesariamente accidentales. Si existe la oportunidad de extraer valor volviendo a minar el bloque de Alice mientras se reordenan u omiten algunas de las transacciones, entonces Bob y Charlie pueden confabularse para que Bob pierda intencionalmente su ranura, lo que desencadena una oportunidad para que Charlie vuelva a minar el bloque de Alice. Este ha sido un inconveniente significativo de los protocolos Pipelined HotStuff (algunos de los cuales están en la red principal hoy en día). --- MonadBFT cambia esto MonadBFT es el primer protocolo que habilita la canalización al tiempo que hace que el algoritmo sea resistente a las horquillas de cola. Esta resistencia de la horquilla de cola proviene del procedimiento alternativo cuando Bob pierde su ranura, lo que permite a los validadores reconstruir su conocimiento colectivo de la propuesta de Alice y su nivel de consenso dentro del conjunto de validadores. En particular, bajo MonadBFT, si Bob pierde su ranura, entonces el procedimiento alternativo hace que los validadores se comuniquen entre sí con atestaciones firmadas que indiquen si vieron el bloqueo de Alice. Si la supermayoría atestigua el bloqueo de Alice, entonces Charlie se ve obligado a volver a proponer el bloqueo de Alice. Si Charlie desea proponer un bloqueo diferente, debe proporcionar una declaración jurada firmada por la mayoría de los validadores que atestigüe que no vio el bloqueo de Alice a tiempo. En el caso típico en el que Charlie vuelve a proponer el bloqueo de Alice, luego puede proponer su bloqueo en la ronda siguiente. El resultado son dos propiedades importantes: la resistencia a la bifurcación de la cola y la finalidad especulativa de una sola ranura. Ya hemos hablado de la resistencia a la bifurcación de la cola, pero entendamos el impacto en la finalidad. Al igual que antes, supongamos que los líderes de los bloques N, N+1 y N+2 son Alice, Bob y Charlie. En Pipelined 2-Phase HotStuff - es decir, antes de MonadBFT - como validador (o un nodo completo), no puedes finalizar la propuesta de bloque de Alice hasta que veas la propuesta de bloque de Charlie. ¿Por qué? Porque si finalizas tan pronto como veas la propuesta de Bob, es posible que Bob se esté metiendo contigo al SOLO reenviarte su propuesta, y en realidad planea no enviar su propuesta a todos los demás, perdiendo así su espacio. Pero en MonadBFT, tan pronto como veas la propuesta de Bob, puedes finalizar "especulativamente" la propuesta de Alice porque la propuesta de Bob incluye un control de calidad sobre la propuesta de Alice, que es una prueba de que 2/3 de la red atestiguó la propuesta de Alice. Incluso si Bob se está metiendo contigo al reenviarte SOLO su propuesta, y va a terminar perdiendo su espacio, sabes que una supermayoría de la red vio la propuesta de Alice y, cuando participen en el procedimiento alternativo, firmarán la propuesta de Alice nuevamente. La única forma de que el bloqueo de Alice no se finalice es si los validadores se equivocan y firman diciendo que no vieron el mensaje de Alice. Esta falla es fácilmente demostrable: hemos firmado mensajes contradictorios de ellos. Si la penalización por el equívoco es sustancial -y debería serlo-, esta finalidad "especulativa" en realidad no es realmente tan especulativa. --- Conclusiones MonadBFT es un desarrollo extremadamente emocionante para el consenso, y es un complemento digno de otras mejoras compuestas en Monad, incluyendo la Ejecución asíncrona, la Ejecución paralela optimista y MonadDb. Muchísimas felicidades a @MohammadMJalal1 y a @KushalBabel por este importante avance. MonadBFT se implementará en breve en Monad Testnet, que actualmente implementa Pipelined 2-Phase HotStuff. Para obtener más información, consulte la publicación del blog y el documento vinculados en el próximo tweet.