Este é o maior deterioro de servizo para Cardano nos seus 8 anos de operación, e como desenvolvedor clave dentro do ecosistema Cardano, sentín que era unha boa oportunidade para reflexionar sobre o que pasou ben, e o que podemos aprender para mellorar aínda máis a robustez de Cardano. Eu escollín para construír unha carreira e unha empresa en Cardano. Cando algo así ocorre, eu non teño o luxo de bater o meu peito en Twitter ou participar en dunking colectivo. A resposta á que cheguei foi si, absolutamente, con algunhas tarefas. **What happened \ A serialization bug caused a unidirectional soft-fork: one portion of the nodes rejected a transaction that the rest didn't. This was initially triggered in testnet, likely on accident, and a fix was identified and released quickly. Unfortunately, someone with deep familiarity with Cardano was able to reverse engineer how the transaction was constructed, and submitted it to mainnet. (You may see claims this was "vibe-coded"; that appears to refer to using AI to set firewall rules in an attempt to quarantine the transaction, not the attack itself.) Desafortunadamente, isto foi antes de que a corrección alcanzase a adopción xeneralizada, e así a maioría dos nodos (aqueles en versións con o bug) aceptárona, mentres que infraestruturas clave como carteiras, exploradores de cadea e intercambios, rexeitárona. Como os operadores de nodo actualizaron á versión fixa, a cadea que rexeitou a transacción comezou a crecer máis rápido que a que a aceptara, e finalmente superou, levando a unha reorg que reparou a cadea. Como un pequeno punto de orgullo, as ferramentas de diagnóstico construídas rapidamente para clasificar o problema usado código de ), un nodo alternativo que está a ser escrito en Rust que o equipo de Sundae Labs é un contribuínte. \ Real Impact \ In practice, the impact of this chain fork was severe, though not as severe as you might have assumed. The chain continued to produce blocks, and a majority of transactions made it into the surviving fork, though delayed. The monitoring infrastructure run by the CF detected a spike in transaction delays up to 5 minutes, but other users may have seen delays as long as 16-30 minutes, the longest gap between blocks. Some subset of users may also have been unable to submit transactions entirely, though this was due to faulty 3rd party infrastructure that was unable to follow either fork. Unha pequena porcentaxe (3,3%, 479 de 14401) das transaccións fixérono na cadea de fallos, e non a fixeron na cadea de supervivencia. **How I think about Blockchain Outages \ I've developed a personal taxonomy for categorizing large outages, from most serious to least: 1. violacións de soberanía, onde as promesas básicas e a integridade (como as sinaturas criptográficas) dunha blockchain son violadas 2. bugs de rexistro, onde os principios económicos (como a política monetaria) dun blockchain son rotos Violación irrecuperable do consenso, onde unha rede forxa permanentemente Violación de consenso recuperable, onde unha rede ten unha forca de longa duración pero recupérase Explotación grave de contratos intelixentes, onde os fondos do usuario se perden debido a un bug no contrato Paro de consenso completo, onde a cadea debe ser detida e reiniciada, coordinada a través dunha autoridade central Degradación do servizo, onde as transaccións son atrasadas ou a información incorrecta é mostrada aos usuarios O incidente Cardano enfrontou cualificacións como 4: serio, pero recuperable. **What went well \ This incident put Cardano's Ouroboros consensus through its paces: long forks like this are supposed to be exceedingly rare black swan events, but the design of the consensus protocol and networking stack anticipate and account for this. For example, the fact that it was able to self-heal is built into the protocol, and the way time is handled has a self-regulating lamport clock that gave the stake pool operators time to upgrade their nodes. Ademais, a infraestrutura de información e comunicación mantida polas entidades fundadoras realmente brillou, xa que puidemos ver rapidamente o problema e comunicalo amplamente. Finalmente, foi unha gran validación para a elección de linguaxe de Cardano. O erro particular estaba relacionado con algúns límites defectuosos verificando un tampón de entrada non fiable. As garantías de seguridade da memoria de Haskell significaron que este tipo de bug nunca está na mesa. **What broke down \ It became clear from the incident that we need better infrastructure around some wallets, dApps, and chain explorers. Many were unable to follow Nalgúns casos isto puido ser unha consideración de seguridade, pero noutros foi só unha falta de programación defensiva que anticipou este escenario. Do mesmo xeito, especialmente cando Cardano entra nunha era de diversidade de clientes, está claro que necesitamos mellorar os nosos criterios de proba xa rigorosos. Como o nivel de probas en toda a implementación do nodo actual é fenomenal, pero ese mesmo rigor debe ser mellorado e estandarizado en todas as implementacións do nodo. **Conclusion \ Blockchains are not immune to the Normalmente é seguro asumir que todo o software é un paquete de rede lonxe do desastre catastrófico, asumindo que só pode atopar o encanto correcto. Amaro Tipo Tamén Bias de supervivencia Os mesmos tipos de bugs Afortunadamente, a maioría (pero non todos) destes son atopados por investigadores de seguridade conscientes e fixados antes de que poidan causar un impacto xeneralizado. Este incidente foi unha excepción e destacou áreas nas que Cardano pode mellorar ao mesmo tempo que demostra as súas fortalezas. Por Pi Lanningham, Xefe de Tecnoloxía de SundaeSwap Labs. por , Páxina oficial de Pi Lanningham Chief Technology Officer at . Xestión de labores Xestión de labores
