4:["$","$L23",null,{"categories":["Audits","Company","Cycles","Engineering","Malachite","Quint"],"posts":[{"featureImage":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"6AdqST9tXA4sfnyOa16366","type":"Asset","createdAt":"2024-08-16T06:54:30.873Z","updatedAt":"2024-08-16T06:54:30.873Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":3,"revision":1,"locale":"en-US"},"fields":{"title":"Blog 2","description":"","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/6AdqST9tXA4sfnyOa16366/5674ad634d300fdfc3571943d08a51ed/Blog_2.jpg","details":{"size":564168,"image":{"width":1920,"height":1080}},"fileName":"Blog_2.jpg","contentType":"image/jpeg"}}},"date":"2025-08-26","title":"Why Teams Choose HotStuff: Insights from Reviewing Espresso's Implementation","slug":"why-teams-choose-hotstuff-2025","categories":["Audits"],"authors":["Informal Systems"],"keywords":"HotStuff consensus\nByzantine fault tolerance\nblockchain consensus algorithms\nproof-of-stake consensus\nconsensus protocol implementation\nHotStuff vs PBFT\nlinear communication complexity\noptimistic responsiveness\nvalidator set management\nepoch transitions blockchain\nconsensus algorithm audit\nblockchain protocol review\nHotStuff implementation challenges\ndynamic validator sets consensus\nproof-of-stake threshold calculations\nblockchain consensus security audit\nHotStuff epoch boundary handling\nconsensus protocol production deployment\nByzantine fault tolerant blockchain scaling\nthree-phase consensus protocol\nstake-weighted voting implementation\nconsensus timeout mechanisms\nblockchain validator rotation\ndistributed systems consensus\nconsensus algorithm performance analysis\nEspresso Systems HotShot\nInformal Systems consensus audit\nblockchain security review\nconsensus protocol evaluation\nconsensus algorithm guide\nblockchain technical analysis\nprotocol implementation insights\nconsensus security considerations","excerpt":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Exploring HotStuff benefits through Espresso's real-world implementation insights.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"includeTableOfContents":false,"body":{"nodeType":"document","data":{},"content":[{"nodeType":"paragraph","data":{},"content":[{"nodeType":"text","value":"If you're evaluating consensus algorithms for your blockchain project, ","marks":[],"data":{}},{"nodeType":"hyperlink","data":{"uri":"https://arxiv.org/pdf/1803.05069"},"content":[{"nodeType":"text","value":"HotStuff","marks":[{"type":"underline"}],"data":{}}]},{"nodeType":"text","value":" has likely caught your attention. Its elegant three-phase approach, linear communication complexity, and responsiveness make it attractive for modern proof-of-stake networks.","marks":[],"data":{}}]},{"nodeType":"paragraph","data":{},"content":[{"nodeType":"text","value":"When Espresso Systems asked us to ","marks":[],"data":{}},{"nodeType":"hyperlink","data":{"uri":"https://informal.systems/blog/securing-epoch-transitions-in-espressos-hotshot-protocol-2025"},"content":[{"nodeType":"text","value":"review their consensus protocol","marks":[{"type":"underline"}],"data":{}}]},{"nodeType":"text","value":", which is a custom variant of HotStuff-2 designed to operate in a proof-of-stake environment, we got an in-depth look at how HotStuff works in practice. Their variant handles dynamic validator sets and epoch transitions for their network. Here's what we learned that might help your decision-making process.","marks":[],"data":{}}]},{"nodeType":"heading-2","data":{},"content":[{"nodeType":"text","value":"Why HotStuff Appeals to Development Teams","marks":[{"type":"bold"}],"data":{}}]},{"nodeType":"paragraph","data":{},"content":[{"nodeType":"text","value":"HotStuff offers compelling advantages over traditional Byzantine fault-tolerant protocols:","marks":[],"data":{}}]},{"nodeType":"paragraph","data":{},"content":[{"nodeType":"text","value":"Linear communication complexity","marks":[{"type":"bold"}],"data":{}},{"nodeType":"text","value":": Unlike PBFT's quadratic message overhead, HotStuff requires only O(n) messages per decision. This scales much better as validator sets grow.","marks":[],"data":{}}]},{"nodeType":"paragraph","data":{},"content":[{"nodeType":"text","value":"Optimistic responsiveness","marks":[{"type":"bold"}],"data":{}},{"nodeType":"text","value":": In favorable network conditions, decisions happen in just one round-trip time, regardless of network delays.","marks":[],"data":{}}]},{"nodeType":"paragraph","data":{},"content":[{"nodeType":"text","value":"Pipelined consensus","marks":[{"type":"bold"}],"data":{}},{"nodeType":"text","value":": Multiple proposals can be in flight simultaneously, improving throughput compared to single-slot consensus.","marks":[],"data":{}}]},{"nodeType":"paragraph","data":{},"content":[{"nodeType":"text","value":"Clean safety guarantees","marks":[{"type":"bold"}],"data":{}},{"nodeType":"text","value":": The three-phase commit structure (prepare, pre-commit, commit) provides clear safety boundaries that are easier to reason about.","marks":[],"data":{}}]},{"nodeType":"paragraph","data":{},"content":[{"nodeType":"text","value":"These benefits explain why teams like Espresso, Aptos, and others have built on HotStuff foundations.","marks":[],"data":{}}]},{"nodeType":"heading-2","data":{},"content":[{"nodeType":"text","value":"Real-World HotStuff: Espresso's Dynamic Validator Approach","marks":[{"type":"bold"}],"data":{}}]},{"nodeType":"paragraph","data":{},"content":[{"nodeType":"text","value":"Espresso's ","marks":[],"data":{}},{"nodeType":"hyperlink","data":{"uri":"https://eprint.iacr.org/archive/2024/1189/1721764665.pdf"},"content":[{"nodeType":"text","value":"HotShot variant","marks":[{"type":"underline"}],"data":{}}]},{"nodeType":"text","value":" tackles a challenge many proof-of-stake teams face: validator set changes. Academic HotStuff assumes fixed participants, but production blockchains need dynamic validator sets for decentralization and economic security.","marks":[],"data":{}}]},{"nodeType":"paragraph","data":{},"content":[{"nodeType":"text","value":"Their solution extends HotStuff with epoch transitions every K blocks. The elegant part is how they handle the boundary between epochs e and e+1:","marks":[],"data":{}}]},{"nodeType":"unordered-list","data":{},"content":[{"nodeType":"list-item","data":{},"content":[{"nodeType":"paragraph","data":{},"content":[{"nodeType":"text","value":"Overlapping participation","marks":[{"type":"bold"}],"data":{}},{"nodeType":"text","value":": Both old and new validator sets participate in the final blocks of each epoch","marks":[],"data":{}}]}]},{"nodeType":"list-item","data":{},"content":[{"nodeType":"paragraph","data":{},"content":[{"nodeType":"text","value":"Extended certificates","marks":[{"type":"bold"}],"data":{}},{"nodeType":"text","value":": A special eQC (extended Quorum Certificate) requires signatures from both validator sets","marks":[],"data":{}}]}]},{"nodeType":"list-item","data":{},"content":[{"nodeType":"paragraph","data":{},"content":[{"nodeType":"text","value":"Smooth handoff","marks":[{"type":"bold"}],"data":{}},{"nodeType":"text","value":": The new epoch begins cleanly with the updated validator set","marks":[],"data":{}}]}]}]},{"nodeType":"embedded-asset-block","data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"2SIB9oeTAAPirhmSBum84a","type":"Asset","createdAt":"2025-08-26T20:10:47.866Z","updatedAt":"2025-08-26T20:10:47.866Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":3,"revision":1,"locale":"en-US"},"fields":{"title":"Blog EpochTransitionFlow (2)","description":"","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/2SIB9oeTAAPirhmSBum84a/8fd95642eaea916f1ec21c3932d8dd1f/Blog_EpochTransitionFlow__2_.jpg","details":{"size":530640,"image":{"width":2400,"height":1000}},"fileName":"Blog_EpochTransitionFlow (2).jpg","contentType":"image/jpeg"}}}},"content":[]},{"nodeType":"heading-2","data":{},"content":[{"nodeType":"text","value":"Implementation Insights from Our Review","marks":[{"type":"bold"}],"data":{}}]},{"nodeType":"heading-3","data":{},"content":[{"nodeType":"text","value":"The Devil's in the Thresholds","marks":[{"type":"bold"}],"data":{}}]},{"nodeType":"paragraph","data":{},"content":[{"nodeType":"text","value":"One technical consideration we identified shows how proof-of-stake adds complexity to HotStuff implementations. The original algorithm assumes equal voting weights, but stake-weighted voting requires careful threshold calculations.","marks":[],"data":{}}]},{"nodeType":"paragraph","data":{},"content":[{"nodeType":"text","value":"Espresso's initial approach accumulated votes by stake but calculated thresholds by node count. This could theoretically allow consensus with an incorrect stake distribution. The fix involved making both vote accumulation and threshold validation consistently stake-based.","marks":[],"data":{}}]},{"nodeType":"paragraph","data":{},"content":[{"nodeType":"text","value":"This highlights a broader point: adapting academic protocols for proof-of-stake requires attention to every assumption about participant equality.","marks":[],"data":{}}]},{"nodeType":"heading-3","data":{},"content":[{"nodeType":"text","value":"Event-Driven Architecture Challenges","marks":[{"type":"bold"}],"data":{}}]},{"nodeType":"paragraph","data":{},"content":[{"nodeType":"text","value":"Academic papers describe HotStuff procedurally, but production systems need event-driven architectures for performance. Mapping between these paradigms isn't always straightforward.","marks":[],"data":{}}]},{"nodeType":"paragraph","data":{},"content":[{"nodeType":"text","value":"We found areas where the specification-to-implementation gap created complexity:","marks":[],"data":{}}]},{"nodeType":"unordered-list","data":{},"content":[{"nodeType":"list-item","data":{},"content":[{"nodeType":"paragraph","data":{},"content":[{"nodeType":"text","value":"View synchronization across epoch boundaries","marks":[],"data":{}}]}]},{"nodeType":"list-item","data":{},"content":[{"nodeType":"paragraph","data":{},"content":[{"nodeType":"text","value":"Extended certificate timing and propagation","marks":[],"data":{}}]}]},{"nodeType":"list-item","data":{},"content":[{"nodeType":"paragraph","data":{},"content":[{"nodeType":"text","value":"Concurrent task management with fine-grained locking","marks":[],"data":{}}]}]}]},{"nodeType":"embedded-asset-block","data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"3C8VeX6HwPTQcRVyIAqpkM","type":"Asset","createdAt":"2025-08-26T20:12:21.383Z","updatedAt":"2025-08-26T20:12:21.383Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":3,"revision":1,"locale":"en-US"},"fields":{"title":"Blog AcademicRealityComparison (1)","description":"","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/3C8VeX6HwPTQcRVyIAqpkM/59bf1d41edf7801cd520155ffa1aa5cd/Blog_AcademicRealityComparison__1_.jpg","details":{"size":651262,"image":{"width":2400,"height":1350}},"fileName":"Blog_AcademicRealityComparison (1).jpg","contentType":"image/jpeg"}}}},"content":[]},{"nodeType":"heading-3","data":{},"content":[{"nodeType":"text","value":"Timeout and Recovery Complexity","marks":[{"type":"bold"}],"data":{}}]},{"nodeType":"paragraph","data":{},"content":[{"nodeType":"text","value":"HotStuff's appeal partly comes from its timeout mechanisms, but epoch transitions complicate recovery scenarios. Our threat model analysis explored cases like:","marks":[],"data":{}}]},{"nodeType":"unordered-list","data":{},"content":[{"nodeType":"list-item","data":{},"content":[{"nodeType":"paragraph","data":{},"content":[{"nodeType":"text","value":"Timeouts during extended certificate formation","marks":[],"data":{}}]}]},{"nodeType":"list-item","data":{},"content":[{"nodeType":"paragraph","data":{},"content":[{"nodeType":"text","value":"Partial message delivery across validator sets","marks":[],"data":{}}]}]},{"nodeType":"list-item","data":{},"content":[{"nodeType":"paragraph","data":{},"content":[{"nodeType":"text","value":"View synchronization when some validators are offline","marks":[],"data":{}}]}]}]},{"nodeType":"paragraph","data":{},"content":[{"nodeType":"text","value":"The Espresso team handled these well, but it reinforced that HotStuff variants need robust timeout logic beyond the basic algorithm.","marks":[],"data":{}}]},{"nodeType":"heading-2","data":{},"content":[{"nodeType":"text","value":"Benefits We Observed in Practice","marks":[{"type":"bold"}],"data":{}}]},{"nodeType":"heading-3","data":{},"content":[{"nodeType":"text","value":"What We Found in Espresso's Implementation","marks":[{"type":"bold"}],"data":{}}]},{"nodeType":"paragraph","data":{},"content":[{"nodeType":"text","value":"HotStuff's structure translates well to modular implementations. Espresso's codebase clearly separated:","marks":[],"data":{}}]},{"nodeType":"unordered-list","data":{},"content":[{"nodeType":"list-item","data":{},"content":[{"nodeType":"paragraph","data":{},"content":[{"nodeType":"text","value":"Proposal handling and validation","marks":[],"data":{}}]}]},{"nodeType":"list-item","data":{},"content":[{"nodeType":"paragraph","data":{},"content":[{"nodeType":"text","value":"Vote collection and aggregation","marks":[],"data":{}}]}]},{"nodeType":"list-item","data":{},"content":[{"nodeType":"paragraph","data":{},"content":[{"nodeType":"text","value":"View management and timeouts","marks":[],"data":{}}]}]},{"nodeType":"list-item","data":{},"content":[{"nodeType":"paragraph","data":{},"content":[{"nodeType":"text","value":"Certificate formation and verification","marks":[],"data":{}}]}]}]},{"nodeType":"paragraph","data":{},"content":[{"nodeType":"text","value":"Additional benefits we observed:","marks":[{"type":"bold"}],"data":{}}]},{"nodeType":"unordered-list","data":{},"content":[{"nodeType":"list-item","data":{},"content":[{"nodeType":"paragraph","data":{},"content":[{"nodeType":"text","value":"Graceful degradation","marks":[{"type":"bold"}],"data":{}},{"nodeType":"text","value":": Even with complex epoch transitions, timeouts led to recovery rather than system halts","marks":[],"data":{}}]}]},{"nodeType":"list-item","data":{},"content":[{"nodeType":"paragraph","data":{},"content":[{"nodeType":"text","value":"Predictable performance","marks":[{"type":"bold"}],"data":{}},{"nodeType":"text","value":": Linear message complexity remained evident even during dual-epoch participation","marks":[],"data":{}}]}]},{"nodeType":"list-item","data":{},"content":[{"nodeType":"paragraph","data":{},"content":[{"nodeType":"text","value":"Clear error boundaries","marks":[{"type":"bold"}],"data":{}},{"nodeType":"text","value":": The three-phase structure made debugging and error handling more straightforward","marks":[],"data":{}}]}]}]},{"nodeType":"heading-3","data":{},"content":[{"nodeType":"text","value":"Performance Characteristics","marks":[{"type":"bold"}],"data":{}}]},{"nodeType":"paragraph","data":{},"content":[{"nodeType":"text","value":"The linear message complexity benefit was evident in Espresso's design. Even with dual-epoch participation during transitions, communication overhead remained manageable.","marks":[],"data":{}}]},{"nodeType":"embedded-asset-block","data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"2QxhExqGHUc3IUQ311jRz","type":"Asset","createdAt":"2025-08-26T20:13:25.613Z","updatedAt":"2025-08-26T20:13:25.613Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":3,"revision":1,"locale":"en-US"},"fields":{"title":"Blog MessageScalingAdvantage (1)","description":"","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/2QxhExqGHUc3IUQ311jRz/d0bdb13be8dd2b57e702c899b95b0d3e/Blog_MessageScalingAdvantage__1_.jpg","details":{"size":965444,"image":{"width":2400,"height":1350}},"fileName":"Blog_MessageScalingAdvantage (1).jpg","contentType":"image/jpeg"}}}},"content":[]},{"nodeType":"heading-2","data":{},"content":[{"nodeType":"text","value":"Considerations for Teams Evaluating HotStuff","marks":[{"type":"bold"}],"data":{}}]},{"nodeType":"heading-3","data":{},"content":[{"nodeType":"text","value":"Implementation Complexity","marks":[{"type":"bold"}],"data":{}}]},{"nodeType":"paragraph","data":{},"content":[{"nodeType":"text","value":"While HotStuff's core algorithm is elegant, production implementations involve substantial additional complexity:","marks":[],"data":{}}]},{"nodeType":"unordered-list","data":{},"content":[{"nodeType":"list-item","data":{},"content":[{"nodeType":"paragraph","data":{},"content":[{"nodeType":"text","value":"Robust timeout and view-change mechanisms","marks":[],"data":{}}]}]},{"nodeType":"list-item","data":{},"content":[{"nodeType":"paragraph","data":{},"content":[{"nodeType":"text","value":"Efficient signature aggregation and verification","marks":[],"data":{}}]}]},{"nodeType":"list-item","data":{},"content":[{"nodeType":"paragraph","data":{},"content":[{"nodeType":"text","value":"State management across protocol phases","marks":[],"data":{}}]}]},{"nodeType":"list-item","data":{},"content":[{"nodeType":"paragraph","data":{},"content":[{"nodeType":"text","value":"Network layer optimizations","marks":[],"data":{}}]}]}]},{"nodeType":"paragraph","data":{},"content":[{"nodeType":"text","value":"Budget accordingly for these implementation details.","marks":[],"data":{}}]},{"nodeType":"heading-3","data":{},"content":[{"nodeType":"text","value":"Proof-of-Stake Adaptations","marks":[{"type":"bold"}],"data":{}}]},{"nodeType":"paragraph","data":{},"content":[{"nodeType":"text","value":"If you're building for proof-of-stake, consider how stake weighting affects every aspect of the protocol:","marks":[],"data":{}}]},{"nodeType":"unordered-list","data":{},"content":[{"nodeType":"list-item","data":{},"content":[{"nodeType":"paragraph","data":{},"content":[{"nodeType":"text","value":"Threshold calculations must be stake-aware","marks":[],"data":{}}]}]},{"nodeType":"list-item","data":{},"content":[{"nodeType":"paragraph","data":{},"content":[{"nodeType":"text","value":"Leader election needs stake-weighted randomness","marks":[],"data":{}}]}]},{"nodeType":"list-item","data":{},"content":[{"nodeType":"paragraph","data":{},"content":[{"nodeType":"text","value":"Dynamic validator sets require careful epoch management","marks":[],"data":{}}]}]}]},{"nodeType":"heading-3","data":{},"content":[{"nodeType":"text","value":"Documentation and Specification","marks":[{"type":"bold"}],"data":{}}]},{"nodeType":"paragraph","data":{},"content":[{"nodeType":"text","value":"Maintain clear bridges between academic specifications and implementation details. The complexity gap can surprise development teams.","marks":[],"data":{}}]},{"nodeType":"heading-2","data":{},"content":[{"nodeType":"text","value":"Why This Matters for Your Project","marks":[{"type":"bold"}],"data":{}}]},{"nodeType":"paragraph","data":{},"content":[{"nodeType":"text","value":"HotStuff variants like Espresso's demonstrate the protocol's production viability. The algorithm's theoretical elegance translates reasonably well to real systems, though with implementation complexity that shouldn't be underestimated.","marks":[],"data":{}}]},{"nodeType":"paragraph","data":{},"content":[{"nodeType":"text","value":"For teams considering HotStuff:","marks":[],"data":{}}]},{"nodeType":"unordered-list","data":{},"content":[{"nodeType":"list-item","data":{},"content":[{"nodeType":"paragraph","data":{},"content":[{"nodeType":"text","value":"The performance benefits are real and significant","marks":[],"data":{}}]}]},{"nodeType":"list-item","data":{},"content":[{"nodeType":"paragraph","data":{},"content":[{"nodeType":"text","value":"Proof-of-stake adaptations require careful design","marks":[],"data":{}}]}]},{"nodeType":"list-item","data":{},"content":[{"nodeType":"paragraph","data":{},"content":[{"nodeType":"text","value":"Implementation complexity is manageable with proper planning","marks":[],"data":{}}]}]},{"nodeType":"list-item","data":{},"content":[{"nodeType":"paragraph","data":{},"content":[{"nodeType":"text","value":"The modular structure aids development and maintenance","marks":[],"data":{}}]}]}]},{"nodeType":"heading-2","data":{},"content":[{"nodeType":"text","value":"Our Experience with Consensus Protocol Reviews","marks":[{"type":"bold"}],"data":{}}]},{"nodeType":"paragraph","data":{},"content":[{"nodeType":"text","value":"Reviewing Espresso's HotStuff implementation reinforced how valuable external perspectives can be during consensus development. The interaction between academic protocols and production requirements creates subtle challenges that benefit from experienced review.","marks":[],"data":{}}]},{"nodeType":"paragraph","data":{},"content":[{"nodeType":"text","value":"The Espresso team's responsiveness to technical considerations and their solid engineering practices made this a productive collaboration. Their implementation demonstrates thoughtful adaptation of HotStuff for practical blockchain consensus needs.","marks":[],"data":{}}]},{"nodeType":"paragraph","data":{},"content":[{"nodeType":"text","value":"Building a consensus protocol or module? We'd be happy","marks":[],"data":{}},{"nodeType":"text","value":" ","marks":[],"data":{}},{"nodeType":"hyperlink","data":{"uri":"https://tally.so/r/nrEk4X"},"content":[{"nodeType":"text","value":"to help with your review","marks":[],"data":{}}]},{"nodeType":"text","value":".","marks":[],"data":{}}]}]},"contentfulURL":"https://app.contentful.com/spaces/p79kctcd7ahy/entries/24oxos79tXVz5kVFQImVJL"},{"featureImage":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"6YFdKKnOZa2hfIPHH9Yp2i","type":"Asset","createdAt":"2025-08-15T18:09:47.999Z","updatedAt":"2025-08-15T18:09:47.999Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":3,"revision":1,"locale":"en-US"},"fields":{"title":"X Post Security Celestia","description":"","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/6YFdKKnOZa2hfIPHH9Yp2i/c99298f0340a10e9698118a4b503ef74/X_Post_Security_Celestia.jpg","details":{"size":767726,"image":{"width":1920,"height":1080}},"fileName":"X_Post_Security_Celestia.jpg","contentType":"image/jpeg"}}},"date":"2025-08-19","title":"Securing Celestia's Propagation Reactor: Audit Findings","slug":"securing-celestias-propagation-reactor-audit-findings-2025","categories":["Audits"],"authors":["Martin Hutle","Tatjana Kirda"," Marius Poke"],"excerpt":{"nodeType":"document","data":{},"content":[{"nodeType":"paragraph","data":{},"content":[{"nodeType":"text","value":"Security analysis of Celestia's erasure coding and block propagation protocol.","marks":[],"data":{}}]}]},"includeTableOfContents":false,"body":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"We recently completed a ","nodeType":"text"},{"data":{"uri":"https://github.com/informalsystems/audits/blob/main/Celestia/Celestia%20Q2%202025%20_%20High-Throughput%20Recovery%20Audit%20Report_Final%20v2.pdf"},"content":[{"data":{},"marks":[],"value":"security audit","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" with the Celestia team on their Propagation Reactor This partnership focused on validating and enhancing their innovative approach to blockchain data availability and block propagation, representing a significant advancement in how distributed networks can efficiently share and recover data.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Understanding the Propagation Reactor","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"Celestia's Propagation Reactor addresses a fundamental challenge in blockchain networks: how to efficiently distribute and recover block data across a decentralized network. The system introduces a sophisticated approach that combines local mempool reconstruction, parity-based recovery using erasure coding, and a pull-based tree retrieval mechanism.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The protocol operates through several key components. When a proposer creates a block, it generates a compact block containing transaction metadata and merkle proofs, then announces which block parts it has available. Nodes use this information to pull missing parts from peers through the tree-based retrieval mechanism. Nodes can reconstruct missing parts through multiple pathways, and a catchup mechanism ensures nodes can recover blocks from previous heights when needed.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"15e4aR2GrlcXtAGhm2y8Ic","type":"Asset","createdAt":"2025-08-15T18:10:59.668Z","updatedAt":"2025-08-15T18:10:59.668Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":3,"revision":1,"locale":"en-US"},"fields":{"title":"Blog RecoveryMethodSequence (1)","description":"","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/15e4aR2GrlcXtAGhm2y8Ic/c7d0be4eca8b73dd615414a55d61e636/Blog_RecoveryMethodSequence__1_.jpg","details":{"size":660241,"image":{"width":2400,"height":1000}},"fileName":"Blog_RecoveryMethodSequence (1).jpg","contentType":"image/jpeg"}}}},"content":[],"nodeType":"embedded-asset-block"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Our Collaboration","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"Our partnership with Celestia involved a comprehensive review of both the protocol specification and its implementation. Celestia’s commitment to technical excellence was evident throughout our collaboration, with rapid responses to technical considerations and thoughtful implementation of enhancements.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Protocol Verification and Strengthening","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"Through our systematic analysis, we helped strengthen several aspects of the recovery mechanism. The team enhanced the catchup protocol to better handle height transitions, improved request tracking mechanisms, and refined the validation procedures for incoming recovery parts. These improvements ensure more robust operation under various network conditions.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"52mtmSnj3lJpf5RGY9PGLi","type":"Asset","createdAt":"2025-08-15T18:11:51.912Z","updatedAt":"2025-08-15T18:11:51.912Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":3,"revision":1,"locale":"en-US"},"fields":{"title":"Blog ProtocolVerificationStrengthening (1)","description":"","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/52mtmSnj3lJpf5RGY9PGLi/c41339a66be92966f6cd1233c57c99ad/Blog_ProtocolVerificationStrengthening__1_.jpg","details":{"size":671851,"image":{"width":2400,"height":1350}},"fileName":"Blog_ProtocolVerificationStrengthening (1).jpg","contentType":"image/jpeg"}}}},"content":[],"nodeType":"embedded-asset-block"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"State Management Refinements","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"Our review of the protocol's state management revealed opportunities to strengthen how the system handles concurrent operations and height transitions. Working together, we helped enhance the synchronization between CometBFT's propagation reactor and consensus reactor, ensuring more reliable state consistency during block finalization and catchup operations.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"These improvements also addressed edge cases in peer state management, particularly around the handling of outstanding requests and the coordination between normal propagation and catchup mechanisms. These enhancements contribute to more predictable system behavior under varying network conditions.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Technical Architecture Validation","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"The Propagation Reactor demonstrates sophisticated engineering in its approach to erasure coding and tree-based part distribution. Our analysis validated the correctness of the merkle proof verification system and the integration between parity part generation and recovery mechanisms.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Load Balancing and Distribution Strategy","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"The protocol's approach to distributing block parts across peers represents a thoughtful balance between redundancy and efficiency. Rather than having every peer request every part from the proposer, the system creates multiple broadcast trees where different peers serve as roots for different subsets of parts. This design significantly reduces bandwidth pressure on the proposing node.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Verification and Proof Systems","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"Our analysis validated the robust proof verification system that ensures data integrity throughout the recovery process. The protocol employs merkle proofs to verify both original block parts and parity parts, with separate verification paths depending on whether parts originate from the original block or the erasure-coded parity data.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Catchup Mechanism Validation","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"The catchup protocol represents a critical component for network resilience, allowing nodes to recover blocks from previous heights when they fall behind consensus. Our partnership helped validate this mechanism and identify areas for improvement. Our analysis revealed technical considerations in the catchup system's coordination with the main propagation protocol. These findings help ensure that nodes can more reliably transition between optimistic propagation and catchup recovery as network conditions change. This validation is particularly valuable for maintaining network health when some nodes experience temporary connectivity or performance issues.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Industry Implications and Future Considerations","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"This collaboration highlights several important considerations for the broader blockchain community. The integration of multiple recovery mechanisms within a single protocol demonstrates how modern blockchain networks can achieve both efficiency and resilience through thoughtful protocol design.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The work also emphasizes the importance of comprehensive testing and validation for complex distributed systems. The Propagation Reactor sophistication requires careful attention to state management, concurrency handling, and edge case scenarios that may not be immediately apparent during initial development.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Looking Forward","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"Our partnership with Celestia on the Propagation Reactor represents the kind of approach that strengthens the entire blockchain ecosystem. The team's commitment to technical excellence and their responsiveness to enhancement opportunities demonstrates the value of rigorous protocol development practices.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The enhancements resulting from our collaboration contribute to a more robust and efficient data availability solution, supporting Celestia's goal of providing scalable blockchain infrastructure. These improvements benefit not only Celestia's network but also provide valuable insights for other projects working on similar challenges in distributed data recovery and blockchain scalability.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"As blockchain networks continue to evolve toward greater scalability and efficiency, the Propagation Reactor points toward sophisticated solutions that balance performance, security, and decentralization. The collaborative development approach demonstrated in this partnership serves as a model for how the industry can continue advancing through shared expertise and rigorous validation processes.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"contentfulURL":"https://app.contentful.com/spaces/p79kctcd7ahy/entries/53Nz4g2RvxrCzIwIvtBJI8"},{"featureImage":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"5qts9WOGkDFB5yUjywLFVO","type":"Asset","createdAt":"2025-08-12T16:17:43.737Z","updatedAt":"2025-08-12T16:17:43.737Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":3,"revision":1,"locale":"en-US"},"fields":{"title":"Blog Circle","description":"","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/5qts9WOGkDFB5yUjywLFVO/f57eb1275dfb32db96114d547e229548/Blog_Circle.jpg","details":{"size":883765,"image":{"width":2400,"height":1350}},"fileName":"Blog_Circle.jpg","contentType":"image/jpeg"}}},"date":"2025-08-13","title":"Malachite is Joining Circle to Build Arc ","slug":"malachite-is-joining-circle-to-build-arc","categories":["Company"],"authors":["Arianne Flemming","Ethan Buchman","Zarko Milosevic"],"excerpt":{"nodeType":"document","data":{},"content":[{"nodeType":"paragraph","data":{},"content":[{"nodeType":"text","value":"Circle acquires Informal's Malachite consensus engine to power Arc Layer-1 blockchain.","marks":[],"data":{}}]}]},"includeTableOfContents":false,"introduction":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"\n","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"body":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"At Informal, our mission is to foster trust in software and money. We do this by incubating transformative technologies and partnering with teams who share our vision. Today, we’re thrilled to announce that one of our technologies, Malachite, is joining Circle to help build Arc, a new open Layer-1 blockchain network, purpose-built for stablecoin finance and launching later this year in testnet.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Informal was founded by a team of experts in formal methods and distributed systems. The deep secrets of consensus and verifiability are seared in our DNA. We’ve worked with great teams for years on the frontier of blockchain protocol development. Malachite is a product of that: a high-performance BFT consensus engine built for a new generation of blockchains.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Malachite was born out of real-world demands: the need for a flexible, reusable foundation for building decentralized systems. It implements the Tendermint consensus algorithm in a modular and minimalistic way, with an emphasis on correctness and efficiency, making it a robust base layer for a wide range of applications. We’re especially grateful for an early collaboration with Starkware that proved Malachite’s utility in state-of-the-art blockchain designs. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We believe that technology has the greatest impact when grounded in meaningful, mission-aligned use cases. Circle is a global financial technology firm enabling instant, low cost, and borderless money movement powered by stablecoins. With Malachite, Circle will benefit from greater performance, reliability, and security, helping to deliver trustworthy financial infrastructure to a broader population.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The addition of Malachite to Circle is a strong validation of the technology and of Informal’s incubation model. It allows for Malachite’s use in a high-impact application, and it provides a robust financial foundation for Malachite’s development, with the core remaining open-source (Apache 2.0). Informal will continue to focus on supporting our clients on other use-cases of Malachite, and on working with great teams using Malachite for next-generation chains, including our own incubated projects, like Cycles. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The Malachite acquisition comes as Informal began the process of spinning out some of our incubated projects to facilitate their growth in 2025, including ","nodeType":"text"},{"data":{"uri":"https://cycles.money/"},"content":[{"data":{},"marks":[],"value":"Cycles","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", ","nodeType":"text"},{"data":{"uri":"https://hydro.cosmos.network/"},"content":[{"data":{},"marks":[],"value":"Hydro","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", and Malachite. Informal is also incubating ","nodeType":"text"},{"data":{"uri":"https://quint-lang.org/"},"content":[{"data":{},"marks":[],"value":"Quint,","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" a leading tool for complex distributed systems that was used in Malachite’s development. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We’re excited about Circle making this investment into Malachite’s future, and about the opportunities it creates for our team moving forward. The Malachite repository will be transitioned to Circle while remaining open source, and we’re proud that several members of the Informal team will be joining","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":" ","nodeType":"text"},{"data":{},"marks":[],"value":"Circle to help bring the vision to life. This successful transition reflects Informal’s deep technical strength and our commitment to ensuring that the technologies we build serve the most transformative and purpose-driven outcomes possible. We’re constantly amazed at the density of talent that continues to be nurtured at Informal, and excited about the growing impact of the technologies we develop.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Informal will continue to partner with great teams on the leading edge of protocol design and cross-chain infrastructure, and we’ll continue to support the adoption of Malachite across the industry. If you are considering building on Malachite or securing your systems, we’d love to work with you, please reach out at ","nodeType":"text"},{"data":{"uri":"mailto:hello@informal.systems"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"hello@informal.systems","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"italic"}],"value":"Arc is offered by Circle Technology Services, LLC (“CTS”). CTS is a software provider and does not provide regulated financial or advisory services. You are solely responsible for services you provide to users, including obtaining any necessary licenses or approvals and otherwise complying with applicable laws.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"contentfulURL":"https://app.contentful.com/spaces/p79kctcd7ahy/entries/3hdGYd9mhpDiQPx91vM8Zk"},{"title":"Message Soup: the Secret Sauce for Consensus Specifications","id":"https://quint-lang.org/posts/soup","link":"https://quint-lang.org/posts/soup","date":"2025-08-11","description":"The message soup technique enables more powerful specifications. Featuring MonadBFT.","categories":["Quint"]},{"title":"How to Write Inductive Invariants","id":"https://quint-lang.org/posts/inductive_invariants","link":"https://quint-lang.org/posts/inductive_invariants","date":"2025-07-31","description":"Learn about inductive invariants by defining them interactively with new Quint tools.","categories":["Quint"]},{"title":"Understanding Solana's Alpenglow with Quint","id":"https://quint-lang.org/posts/alpenglow","link":"https://quint-lang.org/posts/alpenglow","date":"2025-07-21","description":"Use the Alpenglow spec to learn about this consensus algorithm in an interactive way.","categories":["Quint"]},{"featureImage":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"3ZzAOzj4eaLCgi0A04a0j7","type":"Asset","createdAt":"2025-07-17T20:44:52.829Z","updatedAt":"2025-07-17T20:44:52.829Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":3,"revision":1,"locale":"en-US"},"fields":{"title":"X Post Security Babylon","description":"","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/3ZzAOzj4eaLCgi0A04a0j7/8f1b1271f758982c0db9bd50a14cd000/X_Post_Security_Babylon.jpg","details":{"size":526415,"image":{"width":1920,"height":1080}},"fileName":"X_Post_Security_Babylon.jpg","contentType":"image/jpeg"}}},"date":"2025-07-08","title":" Babylon Genesis V2 Security Audit Report","slug":"babylon-genesis-v2-upgrade-audit-report-2025","categories":["Audits"],"authors":["Karolos Antoniadis","Mirel Dalcekovic"," Ivan Gavran","Martin Hutle","Aleksandar Ljahovic","Andrija Mitrovic"],"keywords":"Bitcoin staking security\nCross-chain Bitcoin staking\nBabylon Genesis audit\nBlockchain security audit\nEvent-driven delegation monitoring\nIBC callbacks\nPacket forwarding middleware\nToken factory implementation\nRate limiting blockchain\nEOTSD keyring security\nCosmos ecosystem integration\nBlockchain protocol audit\nSmart contract security\nCross-chain composability\nBitcoin staking infrastructure\nDecentralized finance security\nBlockchain code review\nBitcoin staking protocol security\nCross-chain blockchain audit\nCosmos SDK security review\nBlockchain rewards distribution audit\nBitcoin cross-chain bridge security\nBlockchain security firm\nProtocol security audit\nCryptocurrency security review\nDeFi protocol audit\nBlockchain vulnerability assessment","excerpt":{"nodeType":"document","data":{},"content":[{"nodeType":"paragraph","data":{},"content":[{"nodeType":"text","value":"Our comprehensive security review of Babylon's Genesis V2 upgrade.","marks":[],"data":{}}]}]},"includeTableOfContents":false,"body":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"We're excited to share insights from our recent security audit of Babylon Genesis V2 Upgrade. This collaboration exemplifies the thorough, collaborative approach that drives innovation in blockchain security. Over a two-week engagement in May and June 2025, our team worked closely with Babylon Labs’ developers to verify and enhance the robustness of their protocol upgrade.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Audit Overview","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"Babylon Labs engaged Informal Systems to conduct a comprehensive security review of their Genesis V2 Upgrade, a significant enhancement focused on cross-chain composability and ecosystem integration. The upgrade introduces key features including IBC Callbacks, Packet Forwarding Middleware (PFM), Token Factory, and Rate Limiting capabilities.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Our collaborative approach centered on four priority classes of changes:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"High Priority","nodeType":"text"},{"data":{},"marks":[],"value":": Rewards distribution improvements, EOTSD keyring enhancements, and Vigilante BTC staking tracker optimizations","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Medium Priority","nodeType":"text"},{"data":{},"marks":[],"value":": Integration of established Cosmos ecosystem modules with careful attention to IBC behavior and security","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Low Priority","nodeType":"text"},{"data":{},"marks":[],"value":": Minor fixes and adjustments","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Non-Functional","nodeType":"text"},{"data":{},"marks":[],"value":": Refactoring, documentation, and development workflow improvements\n","nodeType":"text"}],"nodeType":"paragraph"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"4EtXmMIiRfdM82Koq5TnnH","type":"Asset","createdAt":"2025-07-07T19:59:46.898Z","updatedAt":"2025-07-07T19:59:46.898Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":4,"revision":1,"locale":"en-US"},"fields":{"title":"Blog LayeredRepositoryView ","description":"","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/4EtXmMIiRfdM82Koq5TnnH/2030011592dbdab09489c3869a684871/Blog_LayeredRepositoryView__1_.jpg","details":{"size":739952,"image":{"width":2400,"height":1350}},"fileName":"Blog_LayeredRepositoryView (1).jpg","contentType":"image/jpeg"}}}},"content":[],"nodeType":"embedded-asset-block"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"","nodeType":"text"}],"nodeType":"heading-2"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Technical Architecture Review","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"The Genesis V2 Upgrade represents a strategic evolution of Babylon Genesis' protocol, enhancing cross-chain functionality while maintaining the core Bitcoin staking security model. Our review focused on three critical areas where technical precision directly impacts protocol security.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Rewards Distribution Enhancement","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"The upgrade introduces a refined mechanism for reward allocation that ensures proper temporal alignment between voting events and reward distribution. Previously, the system used distribution tables from the current height rather than the height when voting occurred. Our collaboration helped verify that the new tracking mechanism correctly captures delegation changes during ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"BeginBlocker","nodeType":"text"},{"data":{},"marks":[],"value":" processing and applies the appropriate historical context during ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"EndBlocker","nodeType":"text"},{"data":{},"marks":[],"value":" reward distribution.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The enhancement maintains the integrity of the existing reward calculation while providing accurate inputs based on the correct block height and voting information. This change strengthens the economic incentives that secure the network.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Event-Based BTC Staking Tracker","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"The Vigilante’s transition from polling-based to event-driven delegation monitoring represents a significant architectural improvement. The new Vigilante implementation reduces data bandwidth usage considerably to a targeted, event-responsive system.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Our review examined the delegation tracking logic across two key structures:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"},{"type":"code"}],"value":"pendingTracker","nodeType":"text"},{"data":{},"marks":[],"value":": Monitors delegations in VERIFIED status for activation processing","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"},{"type":"code"}],"value":"unbondingTracker","nodeType":"text"},{"data":{},"marks":[],"value":": Tracks VERIFIED and ACTIVE delegations for unbonding operations","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"Through our collaborative analysis, we helped ensure that the event processing maintains strict ordering guarantees and handles edge cases gracefully. The system now provides robust delegation state management while dramatically improving performance.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"italic"}],"value":"","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"EOTSD Keyring Security Enhancement","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"The upgrade introduces support for both test and file keyring backend storage options for the EOTS manager. This enhancement enables finality providers to choose encrypted key storage with passphrase protection when using the file backend, addressing production security requirements while maintaining flexibility for different operational circumstances.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Our verification process confirmed that:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Private keys are only loaded into memory with correct passphrase authentication","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"All key material remains encrypted on disk using industry-standard practices","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"The mutex implementation provides proper concurrency protection without introducing deadlock risks","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Collaborative Improvements","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"Through our audit, we identified several areas where the protocol could be strengthened. The Babylon Labs team's responsiveness and technical expertise enabled rapid implementation of enhancements across multiple components.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Protocol Robustness Enhancements","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"Working together, we refined validation logic across genesis initialization, ensuring consistent state verification during chain initialization and migration scenarios. The team implemented comprehensive validation for genesis fields, strengthening the protocol's resilience to configuration errors.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"For the Vigilante component, our collaboration led to improved block processing guarantees, ensuring monotonic height processing and eliminating potential race conditions during bootstrapping. These enhancements provide deterministic behavior during critical initialization phases.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Code Quality Improvements","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"The audit resulted in numerous code quality enhancements, including removal of redundant ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"ValidateBasic ","nodeType":"text"},{"data":{},"marks":[],"value":" calls (leveraging Cosmos SDK v0.50 automatic invocation), improved error handling in governance proposal validation, and strengthened input validation across multiple modules.\n","nodeType":"text"}],"nodeType":"paragraph"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"UZQvulVnUjNpPCUcVD9W6","type":"Asset","createdAt":"2025-07-07T20:01:23.212Z","updatedAt":"2025-07-07T20:01:23.212Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":4,"revision":1,"locale":"en-US"},"fields":{"title":"Blog SecurityBridge ","description":"","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/UZQvulVnUjNpPCUcVD9W6/cd2b821b1b5b3eb690d9e1a2dc8b2d59/Blog_SecurityBridge__1_.jpg","details":{"size":692884,"image":{"width":2400,"height":1350}},"fileName":"Blog_SecurityBridge (1).jpg","contentType":"image/jpeg"}}}},"content":[],"nodeType":"embedded-asset-block"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Integration Verification","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"Our review confirmed that the new Cosmos ecosystem modules integrate seamlessly with Babylon Genesis' architecture. The Token Factory implementation includes appropriate fee structures (10 BABY per token creation) and community pool integration, while the Rate Limiter provides 20% daily transfer limits for UBBN as a default value for channels existing before the upgrade, with rate limits for future channels to be determined on a case-by-case basis.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The IBC middleware integration maintains Babylon Genesis’ security model while enabling enhanced cross-chain functionality. PFM integration accounts for Babylon Genesis’ shorter unbonding period without compromising security guarantees, and ICA modules begin with conservative configurations that can be expanded through governance.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Industry Implications","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"This collaboration demonstrates the maturation of Bitcoin staking infrastructure and the careful integration of battle-tested Cosmos modules. The Genesis V2 Upgrade showcases how established protocols can evolve to support broader ecosystem needs while maintaining their core security properties.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The event-driven architecture improvements pioneered here provide a template for other protocols managing large-scale state tracking. The careful balance between performance optimization and security guarantees offers valuable lessons for the broader blockchain development community.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Looking Forward","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"Our audit of the Babylon Genesis V2 upgrade reinforces the importance of collaborative security reviews in advancing blockchain infrastructure. The Genesis V2 Upgrade positions Babylon Genesis to support expanded cross-chain use cases while maintaining the robust security model that secures Bitcoin staking.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The thorough verification process and responsive development approach demonstrated throughout this engagement exemplify the collaborative spirit driving innovation in decentralized finance. As Babylon Genesis continues expanding its ecosystem integrations, the foundation established through this upgrade provides a solid base for future development.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"For teams interested in the complete technical details, methodology, and comprehensive findings, we encourage reviewing our","nodeType":"text"},{"data":{"uri":"https://github.com/informalsystems/audits/blob/main/Babylon/Babylon%20Q2%202025%20_%20Genesis%20v2%20Upgrade%20Audit%20Report_Final.pdf"},"content":[{"data":{},"marks":[],"value":" ","nodeType":"text"},{"data":{},"marks":[{"type":"underline"}],"value":"full audit report","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", which provides in-depth analysis of all 14 identified areas for enhancement and their resolutions.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We look forward to continued collaboration as Babylon Genesis advances the frontier of Bitcoin staking security and cross-chain infrastructure.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"contentfulURL":"https://app.contentful.com/spaces/p79kctcd7ahy/entries/1xrNmZ5m1ulRuhPPeTc1dp"},{"featureImage":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"6JPKCEb9pROnMP6MUmbGn0","type":"Asset","createdAt":"2025-07-17T20:46:48.074Z","updatedAt":"2025-07-17T20:46:48.074Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":3,"revision":1,"locale":"en-US"},"fields":{"title":"X Post Security Espresso","description":"","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/6JPKCEb9pROnMP6MUmbGn0/c05c2a1c2e3902d4af400385869a14fd/X_Post_Security_Espresso.jpg","details":{"size":698821,"image":{"width":1920,"height":1080}},"fileName":"X_Post_Security_Espresso.jpg","contentType":"image/jpeg"}}},"date":"2025-06-24","title":"Espresso HotShot Epoch Transition Security Audit","slug":"securing-epoch-transitions-in-espressos-hotshot-protocol-2025","categories":["Audits"],"authors":["Tatjana Kirda","Josef Widder"," Martin Hutle","Hernán Vanzetto"],"keywords":"Security Audit\nEspresso\nHotShot\nConsensus Protocol\nProof-of-Stake\nValidator Transitions\nBlockchain Security\nDistributed Systems\nBFT","excerpt":{"nodeType":"document","data":{},"content":[{"nodeType":"paragraph","data":{},"content":[{"nodeType":"text","value":"Our security audit of Espresso's HotShot consensus protocol examines validator set transitions. ","marks":[],"data":{}}]}]},"includeTableOfContents":false,"body":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Introduction to our Espresso Systems Partnership","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"In Q1 2025, we partnered with Espresso Systems to conduct a security audit of its epoch change protocol in HotShot. This collaboration focused on a critical yet often overlooked component of proof-of-stake systems: secure validator set transitions between epochs.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The partnership exemplifies our approach to blockchain security, combining deep protocol analysis with practical code assessment. Working closely with the Espresso team, we examined how its consensus mechanism maintains security guarantees during validator rotations, which represent natural vulnerability points in any distributed system.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"This audit builds on our previous collaboration with Espresso Systems, where we","nodeType":"text"},{"data":{"uri":"https://informal.systems/blog/espresso-hotshot-epoch-changes-in-quint-2025"},"content":[{"data":{},"marks":[],"value":" formalized HotShot's epoch-change protocol in Quint","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", bringing executable specifications to consensus design. Our audit focused on verifying the correctness of the code for this well-established, peer-reviewed consensus algorithm.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"5h7vOQksHatooRKu0af7Ux","type":"Asset","createdAt":"2025-06-20T19:51:35.736Z","updatedAt":"2025-06-20T19:51:35.736Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":3,"revision":1,"locale":"en-US"},"fields":{"title":"Blog EspressoSystemsAuditProcess","description":"","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/5h7vOQksHatooRKu0af7Ux/c9b29e5363952cf7196542ae05a5939b/Blog_EspressoSystemsAuditProcess.jpg","details":{"size":1967089,"image":{"width":4800,"height":2700}},"fileName":"Blog_EspressoSystemsAuditProcess.jpg","contentType":"image/jpeg"}}}},"content":[],"nodeType":"embedded-asset-block"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Understanding HotShot Validator Set Transitions","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"","nodeType":"text"},{"data":{"uri":"https://docs.espressosys.com/network/learn/the-espresso-network/properties-of-hotshot"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"HotShot","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" serves as the consensus protocol powering the Espresso Network, which is L2-native infrastructure that provides chains with fast, BFT-backed confirmations. It's based on a chained version of HotStuff-2, operating in a proof-of-stake environment where validator sets change periodically.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Every K blocks, HotShot initiates a new epoch with a potentially different validator set. This transition creates several unique challenges:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Coordinating two different validator sets (epochs e and e+1) that must reach consensus on the same blocks","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Maintaining safety and liveness during the transition period","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Ensuring the protocol can recover from network failures or timeouts during this critical phase","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Preventing opportunities for malicious validators to disrupt the transition","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"What makes these transitions particularly challenging is that they represent a boundary where two distinct groups must coordinate despite having different stakes in the outcome. Validators leaving the set and those entering have different incentives, making the security guarantees more complex to ensure.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"5DR45dBK7nkJpJ4f4Ox2qf","type":"Asset","createdAt":"2025-06-20T19:53:12.852Z","updatedAt":"2025-06-20T19:53:12.852Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":3,"revision":1,"locale":"en-US"},"fields":{"title":"Blog HotShotTransitions","description":"","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/5DR45dBK7nkJpJ4f4Ox2qf/6c74c03e62da302079e557758ef2ff23/Blog_HotShotTransitions.jpg","details":{"size":2233409,"image":{"width":4800,"height":2700}},"fileName":"Blog_HotShotTransitions.jpg","contentType":"image/jpeg"}}}},"content":[],"nodeType":"embedded-asset-block"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Audit Approach and Threat Modeling","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"Our audit followed a structured approach combining specification analysis, code review, and threat modeling:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"First, we mapped the protocol specification to its code, ensuring the system correctly translates the theoretical protocol into practical software. This process revealed the complexity of turning theoretical consensus guarantees into real-world distributed systems.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Next, we constructed detailed threat models focusing on specific scenarios that could arise during epoch transitions:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Optimal runs where all messages are delivered on time","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Timeout/sync view changes during different phases of the transition","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Network partitions affecting subsets of validators","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Epoch synchronization edge cases","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"ordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"For each scenario, we analyzed potential challenges and verified how the code handled them. This systematic approach enabled us to gain comprehensive insights into the transition mechanism and collaborate on strengthening various aspects of the protocol.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"1DBXqseryXoZv6cL1lDNnn","type":"Asset","createdAt":"2025-06-20T19:54:39.301Z","updatedAt":"2025-06-20T19:54:39.301Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":3,"revision":1,"locale":"en-US"},"fields":{"title":"Blog AuditMethodology","description":"","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/1DBXqseryXoZv6cL1lDNnn/65296cc04ad2a2ea2c2c82b802346ca3/Blog_AuditMethodology.jpg","details":{"size":2641561,"image":{"width":4800,"height":2700}},"fileName":"Blog_AuditMethodology.jpg","contentType":"image/jpeg"}}}},"content":[],"nodeType":"embedded-asset-block"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"How Three-View Consensus Works","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"The core of Espresso's epoch change protocol involves a sophisticated three-view consensus process. When transitioning from epoch e to e+1, the protocol requires:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"In each view, all processes send to the leader of that view, and then the leader sends to all validators.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"In view v, the leader sends the proposal for the last block of e not only to the validators of e but also to the validators of e+1.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"In view v+1, all validators, from e and e+1 sign the proposal and send it to the leader of v+1, which is able to build a certificate for both sets of validators. The leader sends this certificate again to both validator sets.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"In view v+2 all validators sign the proposal again and send it to the leader of v+2, which is able to build the second certificate for the last block. This is sent again to both validator sets.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"In view v+3, the leader of v+3 builds an extended certificate from the signed proposals it received from the both validators sets. The extended certificate allows the validators of e+1 to safely continue the normal protocol.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"ordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"This protocol design ensures that validators from both epochs have participated in securing the transition, preventing a single epoch from controlling the outcome. The code uses threshold signatures to reduce communication complexity, with separate thresholds calculated for each epoch's validator set.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Examining Edge Cases","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"The most interesting insights emerged when examining how the proven HotShot algorithm was coded to handle disruptions during the transition process. Since the underlying algorithm is well-established from peer-reviewed research, our analysis focused on verifying that the code correctly handles various edge cases:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"View changes during early transition stages","nodeType":"text"},{"data":{},"marks":[],"value":": We verified that when timeouts occur in views v or v+1, the system correctly restarts the three-chain process while preserving progress made. This is achieved by maintaining high quorum certificates (highQC) across view changes.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Partial certificate formation","nodeType":"text"},{"data":{},"marks":[],"value":": We examined scenarios where enough validators from one epoch voted, but not from the other. We confirmed the code correctly prevents progress until both validator sets reach their respective thresholds.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Network partitions affecting specific validator subsets","nodeType":"text"},{"data":{},"marks":[],"value":": We analyzed how the protocol handles cases where validators in epoch e+1 cannot communicate with those in epoch e. The system includes view synchronization mechanisms that correctly allow recovery even when communication between epochs is temporarily disrupted.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Epoch synchronization","nodeType":"text"},{"data":{},"marks":[],"value":": We verified the special handling to ensure all validators eventually learn about the completed epoch transition, even if they missed parts of the process.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"These edge cases represent critical boundaries where the translation from theoretical algorithm to practical code requires careful attention, making their correct handling essential for robust consensus.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Key Findings and Broader Implications","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"Our audit identified several important considerations with implications beyond the Espresso Network:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"3JQYJtpZUaXgb9lqkJC1Mb","type":"Asset","createdAt":"2025-06-20T19:55:36.003Z","updatedAt":"2025-06-20T19:55:36.003Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":3,"revision":1,"locale":"en-US"},"fields":{"title":"Blog KeyFindings V2","description":"","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/3JQYJtpZUaXgb9lqkJC1Mb/0981ef05efc015c0eed0d0bfb3a642a3/Blog_KeyFindings_V2.jpg","details":{"size":1545574,"image":{"width":4800,"height":1960}},"fileName":"Blog_KeyFindings_V2.jpg","contentType":"image/jpeg"}}}},"content":[],"nodeType":"embedded-asset-block"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Threshold calculations","nodeType":"text"},{"data":{},"marks":[],"value":": We identified an opportunity to align voting power threshold calculations with stake accumulation, ensuring consistent stake-based calculations in proof-of-stake systems.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Protocol-code alignment","nodeType":"text"},{"data":{},"marks":[],"value":": The code contained subtle differences from the specification, demonstrating the challenges of translating theoretical consensus protocols into practical software.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Edge case handling","nodeType":"text"},{"data":{},"marks":[],"value":": The complexity of handling timeout and view change logic during epoch transitions showed how distributed systems must carefully address all failure modes, particularly at boundary conditions.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Cross-epoch coordination","nodeType":"text"},{"data":{},"marks":[],"value":": The need for validators from two epochs to reach consensus demonstrates a fundamental challenge in proof-of-stake systems that all projects must address.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"ordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"These considerations have broader implications for any blockchain using proof-of-stake with validator rotation. They underscore how challenges often emerge at system boundaries rather than in core algorithms.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Conclusion: Collaborative Success and Looking Forward","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"Our collaboration with Espresso Systems exemplifies effective security partnership, working together to verify correctness and enhance protocol robustness. The Espresso team demonstrated technical excellence in addressing our recommendations promptly.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"This audit highlights how blockchain security requires examining systems holistically, beyond just checking individual components. Validator transitions represent natural boundaries in any proof-of-stake system and deserve particular attention during design and development.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"For teams building similar systems, we recommend:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Extensive threat modeling specifically around validator transition code","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Careful alignment between theoretical protocol descriptions and practical software","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Clear handling of all possible network failure modes at epoch boundaries","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Consistent stake-based calculations for threshold determinations","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"As proof-of-stake systems continue to evolve, secure epoch transition implementation will remain critical to maintaining the security guarantees that blockchain applications depend upon. Through partnerships like this, we continue advancing the state of distributed consensus security.\n\nFor more technical details, you can review the ","nodeType":"text"},{"data":{"uri":"https://github.com/informalsystems/audits/blob/main/Espresso/Espresso%20Q1%202025%20_%20Epoch%20Change%20Protocol%20Audit%20Report_Final.pdf"},"content":[{"data":{},"marks":[],"value":"full audit report","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"\n","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"contentfulURL":"https://app.contentful.com/spaces/p79kctcd7ahy/entries/5iySzUoNB21dgapcR29H8F"},{"featureImage":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"6dsleaY3mQVSm04nVybJkv","type":"Asset","createdAt":"2024-08-16T06:49:26.368Z","updatedAt":"2024-08-16T06:49:26.368Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":3,"revision":1,"locale":"en-US"},"fields":{"title":"Blog 1","description":"","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/6dsleaY3mQVSm04nVybJkv/5d3808127f50b87db77976aad5f4f8d6/Blog_1.jpg","details":{"size":458680,"image":{"width":1920,"height":1080}},"fileName":"Blog_1.jpg","contentType":"image/jpeg"}}},"date":"2025-06-18","title":"Protocol Berg 2025 Insights on Future Development Trends","slug":"what-we-learned-at-protocol-berg-2025","categories":["Audits"],"authors":["Marius Poke","Philip Offtermatt"],"keywords":"protocol development\ndecentralized systems\nblockchain development\nprotocol security\nsmart contract audits\nexecutable specifications\nformal verification\nprotocol design\nblockchain UX\ndecentralized protocols\nprotocol specification tools\nblockchain security testing\ndecentralized vs centralized UX\nprotocol development frameworks\nsmart contract security practices\nProtocol Berg 2025\nblockchain conference insights\ncrypto developer conference\nprotocol engineering\nblockchain infrastructure\nQuint specification language\nMalachite consensus engine\nBFT consensus\nprotocol validation\nblockchain formal methods\n\"how to improve protocol security\"\n\"protocol development best practices\"\n\"decentralized systems challenges\"\n\"blockchain UX problems\"\n\"executable specs vs documentation\"\nCosmos ecosystem development\nEthereum protocol development\ncross-chain infrastructure\ninteroperability protocols","excerpt":{"nodeType":"document","data":{},"content":[{"nodeType":"paragraph","data":{},"content":[{"nodeType":"text","value":"Key takeaways from Protocol Berg 2025 on UX, decentralization, and emerging security practices.","marks":[],"data":{}}]}]},"includeTableOfContents":false,"body":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Last week, our team attended ","nodeType":"text"},{"data":{"uri":"https://protocol.berlin/"},"content":[{"data":{},"marks":[],"value":"Protocol Berg","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", a developer-focused conference that reinforced why we need more technical events like this in our industry. Unlike typical crypto conferences, this one cut through the noise and focused on what matters: building robust protocols.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The Technical Reality Check","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"The conference highlighted three critical insights that align directly with our mission at Informal Systems.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Users prioritize UX over decentralization.","nodeType":"text"},{"data":{},"marks":[],"value":" As ","nodeType":"text"},{"data":{"uri":"https://bsky.app/profile/goat.navy"},"content":[{"data":{},"marks":[],"value":"Edmund Edgar","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" noted in his talk, \"if you don't provide UX through a decentralized solution, the market will provide a centralized solution for you.\" Base's popularity illustrates this principle in action. This applies equally to privacy and security. The challenge isn't choosing between good UX and decentralization – it's delivering both.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Protocol specs remain stuck in English.","nodeType":"text"},{"data":{},"marks":[],"value":" We spoke with multiple teams who face constant issues with outdated specifications. Despite having strong research cultures, they haven't adopted executable specs like Quint due to time constraints and unclear value propositions. This represents a massive opportunity for tools that prove their utility through real-world impact.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Security happens in-house.","nodeType":"text"},{"data":{},"marks":[],"value":" Teams handle security primarily through internal testing, with third-party audits serving as necessary validation steps. This reinforces our approach of helping teams strengthen internal security practices through better tooling and processes.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Technical Evolution on the Horizon","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"Vitalik's timeline for replacing EVM with ZK-friendly VMs like RISC-V (beyond 18 months but inevitable) signals major infrastructure shifts ahead. Teams need to prepare for this transition now, not when it arrives.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The conference featured strong security-focused presentations from companies like ","nodeType":"text"},{"data":{"uri":"https://ackee.xyz/"},"content":[{"data":{},"marks":[],"value":"Ackee","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" (manual fuzzing guidance) and ","nodeType":"text"},{"data":{"uri":"https://phylax.systems/"},"content":[{"data":{},"marks":[],"value":"Phylax","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" (runtime assertions). These align with our conviction that security tooling must integrate seamlessly into development workflows.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Our Path Forward","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"These insights validate our three-pillar strategy: Partner, Invest, and Incubate. Protocol teams need partners who understand both technical excellence and practical constraints. They need tools that prove value quickly rather than requiring lengthy learning curves. Most importantly, they need security approaches that enhance rather than burden their development processes.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Protocol Berg demonstrated that the technical community is ready for tools like Quint and Malachite. Our next step is proving their utility through concrete partnerships and measurable improvements in protocol security and development velocity.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The future belongs to teams that can deliver decentralized solutions with centralized UX quality. That's exactly what we're building toward.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[],"nodeType":"hr"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Ready to strengthen your protocol's security and development process?","nodeType":"text"},{"data":{},"marks":[],"value":" Contact us at ","nodeType":"text"},{"data":{"uri":"mailto:hello@informal.systems"},"content":[{"data":{},"marks":[],"value":"hello@informal.systems","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" to explore how our tools and expertise can help your team build more trustworthy systems.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"contentfulURL":"https://app.contentful.com/spaces/p79kctcd7ahy/entries/10yHiKzDveoGqbcDIImyoR"},{"featureImage":"$4:props:posts:0:featureImage","date":"2025-06-10","title":"Apex Fusion Cross-Chain Bridge Security Audit","slug":"apex-fusion-audit-blog-2025","categories":["Audits"],"authors":["Aleksandar Ignjatijevic","Simon Noetzlin","Carlos Rodriguez"],"keywords":"Cardano bridge security\nmulti-chain bridge audit\nblockchain interoperability audit\nbridge validator consensus\ncross-chain asset security\nbridge security audit\ncross-chain bridge audit\nblockchain bridge security\nmulti-chain architecture audit\ncrypto bridge vulnerability assessment\nByzantine fault tolerance blockchain\ncross-chain security analysis\nbridge consensus mechanisms\nblockchain validator security\nUTXO bridge implementation\nsmart contract security audit\nDeFi bridge audit services\nblockchain infrastructure audit\ncross-chain protocol review\nbridge vulnerability testing","excerpt":{"nodeType":"document","data":{},"content":[{"nodeType":"paragraph","data":{},"content":[{"nodeType":"text","value":"Our security audit of Apex Fusion's multi-chain bridge analyzes BFT consensus mechanisms.","marks":[],"data":{}}]}]},"includeTableOfContents":false,"body":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Understanding the Bridging Challenge","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"Cross-chain communication remains one of blockchain's most complex security challenges. Bridges must maintain consistent state across distinct networks with different consensus mechanisms, while protecting locked assets worth millions. These systems face unique threats, including timing attacks, double-spend attempts, and validator collusion risks.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Our recent audit of Apex Fusion's bridge infrastructure required analyzing how their solution navigates these fundamental challenges while connecting their three-chain architecture (Prime, Vector, and Nexus) with Cardano.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Apex's Approach to Cross-Chain Security","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"Apex implements two distinct bridge solutions: Reactor for internal ecosystem connections, and Skyline for Cardano mainnet integration. Both operate as blockchains with their own validator sets, employing a lock-and-release mechanism.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"4wJ1OnOsDwn5CIUNN9EBDc","type":"Asset","createdAt":"2025-06-09T16:03:59.094Z","updatedAt":"2025-06-09T16:03:59.094Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":3,"revision":1,"locale":"en-US"},"fields":{"title":"Blog CrossChainBridgeArchitecture","description":"","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/4wJ1OnOsDwn5CIUNN9EBDc/a6e0cf9edc9d596c3b7f55e2abaaf168/Blog_CrossChainBridgeArchitecture.jpg","details":{"size":2273912,"image":{"width":4800,"height":2700}},"fileName":"Blog_CrossChainBridgeArchitecture.jpg","contentType":"image/jpeg"}}}},"content":[],"nodeType":"embedded-asset-block"},{"data":{},"content":[{"data":{},"marks":[],"value":"When users initiate a cross-chain transfer, funds are locked in a multisig address on the source blockchain. The bridge then orchestrates the release of an equivalent amount on the destination chain through a series of verified steps:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Oracles monitor bridging activities by observing transactions to bridge multisig addresses","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Batchers create transaction batches when specific conditions are met","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Relayers retrieve confirmed batches and submit them to destination chains","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Smart contracts handle claim verifications through quorum-based validation","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"ordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"This architecture demonstrates thoughtful design in creating a distributed, asynchronous system with multiple safeguards to ensure secure cross-chain transfers.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Validator Consensus and Quorum","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"The core security mechanism within the Apex bridges relies on a Byzantine Fault Tolerant (BFT) quorum system. Validators must reach consensus on:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Valid bridging requests","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Batch formation and execution","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Failed transaction handling","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Refund request processing","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"4zV0r3OCJ3bPJ4zGDJXxLm","type":"Asset","createdAt":"2025-06-09T16:04:57.917Z","updatedAt":"2025-06-09T16:04:57.917Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":3,"revision":1,"locale":"en-US"},"fields":{"title":"Blog BFTConsensusProcess","description":"","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/4zV0r3OCJ3bPJ4zGDJXxLm/c1123a80ea20f48cfa8ba9f94f12dfad/Blog_BFTConsensusProcess.jpg","details":{"size":2231032,"image":{"width":4800,"height":2700}},"fileName":"Blog_BFTConsensusProcess.jpg","contentType":"image/jpeg"}}}},"content":[],"nodeType":"embedded-asset-block"},{"data":{},"content":[{"data":{},"marks":[],"value":"Our review identified opportunities to strengthen the quorum calculation approach. We collaborated with the Apex team to refine the algorithm for determining required signatures, ensuring it precisely matches theoretical BFT requirements across all validator configurations.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The development team demonstrated exceptional responsiveness, implementing optimizations that enhanced the system's Byzantine fault tolerance. This collaborative process strengthened the mathematical foundation of the consensus mechanism, aligning implementation with theoretical security guarantees.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Data Consistency Across Chains","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"A bridge's security relies heavily on deterministic processing of cross-chain data. The Apex implementation includes a sophisticated Cardano block indexer that stores UTXO states and transaction information to support batch generation.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"During our analysis, we identified an opportunity to enhance the UTXO sorting mechanism. By improving the sorting logic for UTXOs with identical parameters, we helped ensure validators consistently create identical batches, strengthening the system's reliability.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"This collaboration highlights a valuable aspect of bridge security: careful attention to deterministic data handling strengthens the overall system liveness and consistency.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Key Technical Considerations","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"Our audit focused on three main components identified as critical to security:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Cardano block indexer","nodeType":"text"},{"data":{},"marks":[],"value":": Responsible for tracking and validating on-chain activity","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Off-chain batcher","nodeType":"text"},{"data":{},"marks":[],"value":": Creates and proposes transaction batches","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Bridge smart contracts","nodeType":"text"},{"data":{},"marks":[],"value":": Verify claims and orchestrate token movements","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"ordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"Through our review, we identified several technical considerations that the Apex team addressed:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Synchronization mechanisms between batchers","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Refund request claim validation processes","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Batch execution claim verification","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"The team's proactive approach to implementing improvements in these areas demonstrates their commitment to building robust cross-chain infrastructure.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Lessons for Cross-Chain System Design","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"The Apex bridge implementation demonstrates a well-thought-out design with high-quality engineering. Our collaborative audit process yielded important insights for cross-chain systems:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"PNMj6hSA8HCGVobfQG3uT","type":"Asset","createdAt":"2025-06-09T16:05:45.531Z","updatedAt":"2025-06-09T16:05:45.531Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":3,"revision":1,"locale":"en-US"},"fields":{"title":"Blog SecurityEnhancementTimeline","description":"","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/PNMj6hSA8HCGVobfQG3uT/786524168b6acd69d038714d4f84d6f5/Blog_SecurityEnhancementTimeline.jpg","details":{"size":1696676,"image":{"width":4800,"height":1960}},"fileName":"Blog_SecurityEnhancementTimeline.jpg","contentType":"image/jpeg"}}}},"content":[],"nodeType":"embedded-asset-block"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"BFT calculations benefit from precise mathematical implementations","nodeType":"text"},{"data":{},"marks":[],"value":" - Ensuring exact alignment with theoretical models","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Deterministic processing is essential for distributed agreement","nodeType":"text"},{"data":{},"marks":[],"value":" - All validators must produce identical results from the same inputs","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Edge case handling deserves special attention","nodeType":"text"},{"data":{},"marks":[],"value":" - Recovery paths require careful consideration","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Trust assumptions should be explicit","nodeType":"text"},{"data":{},"marks":[],"value":" - Clearly documenting reliance on system components enhances security understanding","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"ordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"The Apex team's responsive collaboration throughout the audit process reflects their commitment to security, positioning their bridges as robust infrastructure for their growing ecosystem.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"For more technical details, you can review the","nodeType":"text"},{"data":{"uri":"https://github.com/informalsystems/audits/blob/main/Apex/Apex%20Q1%202025%20_%20Reactor%20&%20Skyline%20Critical%20Path%20Audit%20Report_Final.pdf"},"content":[{"data":{},"marks":[],"value":" full audit report","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"contentfulURL":"https://app.contentful.com/spaces/p79kctcd7ahy/entries/39OdVu9wZo0MUqG0Sj4V4B"},{"featureImage":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"1ug0GaZLhsznvg5JJTyau0","type":"Asset","createdAt":"2025-07-17T20:50:04.836Z","updatedAt":"2025-07-17T20:50:04.836Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":3,"revision":1,"locale":"en-US"},"fields":{"title":"X Post Security Celestia","description":"","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/1ug0GaZLhsznvg5JJTyau0/951ece0cfa456df74bf0d8081c39a2ce/X_Post_Security_Celestia.jpg","details":{"size":688246,"image":{"width":1920,"height":1080}},"fileName":"X_Post_Security_Celestia.jpg","contentType":"image/jpeg"}}},"date":"2025-06-03","title":"Celestia CIP-31 Vesting Mechanism Security Audit","slug":"securing-celestias-vesting-mechanism-2025","categories":["Audits"],"authors":["Tatjana Kirda","Carlos Rodriguez"],"keywords":"crypto security audit\nweb3 security audit\nsolidity audit \nDeFi security audit\ncross-chain security \nsmart contract audit \ncelestia blockchain ","excerpt":{"nodeType":"document","data":{},"content":[{"nodeType":"paragraph","data":{},"content":[{"nodeType":"text","value":"Security review validates lockup account implementation and reward distribution logic.","marks":[],"data":{}}]}]},"includeTableOfContents":false,"body":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Introduction","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"In April 2025, Celestia engaged Informal Systems to conduct a security audit of the","nodeType":"text"},{"data":{"uri":"https://github.com/celestiaorg/CIPs/blob/39544d04c64568f98d0ba984b01f3fb084139df5/cips/cip-031.md"},"content":[{"data":{},"marks":[],"value":" ","nodeType":"text"},{"data":{},"marks":[{"type":"underline"}],"value":"CIP-31","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" proposal and its implementation under the","nodeType":"text"},{"data":{"uri":"https://github.com/celestiaorg/cosmos-sdk/pull/450"},"content":[{"data":{},"marks":[],"value":" ","nodeType":"text"},{"data":{},"marks":[{"type":"underline"}],"value":"provided PR","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The audit primarily focused on verifying that the code implementation aligns with the CIP-31 specification through manual code review. In addition to checking for compliance, the audit also aimed to uncover any potential issues or unintended behaviors introduced by the recent code changes.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Overall, the implementation was well-executed and consistent with the CIP-31 specification. Through our collaborative review process, we identified areas for improvement that strengthened the protocol's security guarantees.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"It's worth noting that while MaxCommissionRate is included in CIP-31, it was not within the scope of this audit. Additionally, any components of the Cosmos SDK not affected by the pull request were assumed to be correctly implemented.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"System Overview: Vesting Rewards in Lockup Accounts","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"CIP-31 outlines the incorporation of staking rewards directly into lockup accounts. When a vesting account earns rewards from staking, the system adds the reward amount to the lockup balance and adjusts the unlock rate based on the remaining lockup duration (","nodeType":"text"},{"data":{"uri":"https://github.com/celestiaorg/CIPs/blob/39544d04c64568f98d0ba984b01f3fb084139df5/cips/cip-031.md#abstract"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"ref","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":").","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"This mechanism ensures that staking rewards earned by locked tokens remain subject to the same vesting conditions as the original tokens, maintaining the integrity of Celestia's token distribution schedule.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Vesting Account Types in Celestia","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"The Cosmos SDK supports","nodeType":"text"},{"data":{"uri":"https://docs.cosmos.network/v0.50/build/modules/auth/vesting"},"content":[{"data":{},"marks":[],"value":" ","nodeType":"text"},{"data":{},"marks":[{"type":"underline"}],"value":"several types of vesting accounts","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", each with different unlocking behaviors:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Continuous vesting accounts","nodeType":"text"},{"data":{},"marks":[],"value":": Tokens unlock linearly between start and end times","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Delayed vesting accounts","nodeType":"text"},{"data":{},"marks":[],"value":": All tokens unlock at once at the end time","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Periodic vesting accounts","nodeType":"text"},{"data":{},"marks":[],"value":": Tokens unlock in discrete periods","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Permanent vesting accounts","nodeType":"text"},{"data":{},"marks":[],"value":": Tokens never fully unlock","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"6sGeUe91bPcfIj81klR6SA","type":"Asset","createdAt":"2025-06-02T20:21:07.872Z","updatedAt":"2025-06-03T20:05:09.668Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":7,"revision":2,"locale":"en-US"},"fields":{"title":"Blog VestingAccountTypes (1)","description":"","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/6sGeUe91bPcfIj81klR6SA/8bef81e93562bed7307044422701fddc/Blog_VestingAccountTypes__2_.jpg","details":{"size":1729495,"image":{"width":4800,"height":2700}},"fileName":"Blog_VestingAccountTypes (2).jpg","contentType":"image/jpeg"}}}},"content":[],"nodeType":"embedded-asset-block"},{"data":{},"content":[{"data":{},"marks":[],"value":"\nCIP-31 is implemented only for continuous and delayed vesting accounts. With this PR, the creation of periodic and permanent vesting accounts has been disabled. Previously created accounts of these types remain valid, but any rewards distributed to them wouldn't be locked.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"How Vesting Calculations Work","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"The vesting account type controls how and when coins become spendable. Each vesting account tracks:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"The original vesting amount for each denomination","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"The amount of unlocked coins that are delegated","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"The amount of locked coins that are delegated","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"An end time when all coins become fully unlocked","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Continuous Vesting Accounts","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"For continuous vesting accounts, unlocking follows a linear schedule:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Before start time","nodeType":"text"},{"data":{},"marks":[],"value":": 0% unlocked, 100% locked","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Between start and end time","nodeType":"text"},{"data":{},"marks":[],"value":": Linear unlocking based on elapsed time","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"After end time","nodeType":"text"},{"data":{},"marks":[],"value":": 100% unlocked, 0% locked","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"xITrvwq8WHRdSCy7ir8rV","type":"Asset","createdAt":"2025-06-02T20:22:54.773Z","updatedAt":"2025-06-02T20:22:54.773Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":3,"revision":1,"locale":"en-US"},"fields":{"title":"Blog TokenVestingTimeline (1)","description":"","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/xITrvwq8WHRdSCy7ir8rV/a3a21ae16d02e935e33be67728df3dce/Blog_TokenVestingTimeline__1_.jpg","details":{"size":1623187,"image":{"width":4800,"height":1960}},"fileName":"Blog_TokenVestingTimeline (1).jpg","contentType":"image/jpeg"}}}},"content":[],"nodeType":"embedded-asset-block"},{"data":{},"content":[{"data":{},"marks":[],"value":"\nThe vested (unlocked) amount increases gradually over time. To determine how much is unlocked at any point, the system calculates what portion of the vesting period has elapsed, then unlocks that same portion of the tokens. For example, if 25% of the time between start and end dates has passed, then 25% of the original tokens will be unlocked.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"For a more detailed example of how this works in practice, see the","nodeType":"text"},{"data":{"uri":"https://github.com/celestiaorg/CIPs/blob/39544d04c64568f98d0ba984b01f3fb084139df5/cips/cip-031.md#continuous-vesting-accounts"},"content":[{"data":{},"marks":[],"value":" ","nodeType":"text"},{"data":{},"marks":[{"type":"underline"}],"value":"continuous vesting accounts example in the CIP-31 documentation","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"This proportional approach ensures a smooth, predictable release of tokens throughout the entire vesting period.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Delayed Vesting Accounts","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"Delayed vesting accounts use a simpler, all-or-nothing approach:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Before end time","nodeType":"text"},{"data":{},"marks":[],"value":": 0% unlocked, 100% locked","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"At or after end time","nodeType":"text"},{"data":{},"marks":[],"value":": 100% unlocked, 0% locked","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Modifying the Original Vesting Amount","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"When rewards are distributed to a vesting account:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"The original vesting amount is updated by adding the reward amount","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"The reward is added to the account's total balance in the banking module","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"If there was no original vesting amount for a denomination, the reward remains unvested","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"This ensures that rewards from locked tokens remain subject to the same vesting schedule as the original tokens.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Technical Considerations and Collaborative Improvements","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"Our review process identified several important technical considerations that helped strengthen the CIP-31 implementation:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"1. Withdrawal Address Configuration Analysis","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Technical Challenge","nodeType":"text"},{"data":{},"marks":[],"value":": The system's architecture allows users to specify custom withdrawal addresses for staking rewards, creating multiple token flow paths. Our analysis revealed that when users direct rewards to non-vesting accounts they control, the standard vesting validation logic doesn't apply to those alternative withdrawal paths.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Specific Issue","nodeType":"text"},{"data":{},"marks":[],"value":": If a user changes their withdrawal address from their vesting account to a regular account under their control, rewards bypass the intended vesting schedule because the system's vesting checks are tied to the receiving account type rather than the originating account's restrictions.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Collaborative Enhancement","nodeType":"text"},{"data":{},"marks":[],"value":": We worked with the Celestia team to ensure that all reward distribution paths properly validate against the source account's vesting properties, regardless of withdrawal address configuration. This strengthened the system's ability to preserve tokenomic integrity across different user configurations.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"2. Outstanding Rewards Handling After Delegation Changes","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Technical Challenge","nodeType":"text"},{"data":{},"marks":[],"value":": The protocol handles accumulated rewards differently based on delegation status, creating a complex state management scenario. Our review identified that \"outstanding rewards\" accumulated before undelegation don't automatically inherit the vesting properties when claimed after delegation ends.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Specific Issue","nodeType":"text"},{"data":{},"marks":[],"value":": When users undelegate tokens from a validator, any accumulated rewards become \"outstanding rewards\" that can be claimed through WithdrawDelegationRewards. However, since the user no longer has active delegation to that validator, the function doesn't apply vesting restrictions to these pre-accumulated rewards.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Collaborative Enhancement","nodeType":"text"},{"data":{},"marks":[],"value":": Our analysis helped identify opportunities to strengthen the consistency of vesting enforcement across all reward claiming scenarios. The Celestia team implemented improvements that ensure rewards maintain their vesting properties regardless of when they're claimed in the delegation lifecycle, closing this gap in the reward handling logic.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Collaborative Development Process","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"The Celestia team demonstrated exceptional responsiveness throughout our review process. When we identified technical considerations, they immediately engaged in collaborative problem-solving to implement enhancements. The improvements were delivered through a","nodeType":"text"},{"data":{"uri":"https://github.com/celestiaorg/cosmos-sdk/pull/458/files"},"content":[{"data":{},"marks":[],"value":" ","nodeType":"text"},{"data":{},"marks":[{"type":"underline"}],"value":"follow-up PR","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" that strengthened the overall security posture.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"2zYOZqSI8GCZSSTP2igCc","type":"Asset","createdAt":"2025-06-02T20:23:53.366Z","updatedAt":"2025-06-02T20:23:53.366Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":3,"revision":1,"locale":"en-US"},"fields":{"title":"Blog CollaborativeSecurityPartnershipProcess","description":"","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/2zYOZqSI8GCZSSTP2igCc/2f39d32519ab23876b853ca1800ad6d7/Blog_CollaborativeSecurityPartnershipProcess.jpg","details":{"size":2524827,"image":{"width":4800,"height":2700}},"fileName":"Blog_CollaborativeSecurityPartnershipProcess.jpg","contentType":"image/jpeg"}}}},"content":[],"nodeType":"embedded-asset-block"},{"data":{},"content":[{"data":{},"marks":[],"value":"This collaborative approach highlights the value of security partnerships in building robust blockchain infrastructure. Rather than viewing security review as a checkpoint, the process became an opportunity to enhance the protocol's design and implementation.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Lessons for Protocol Development Teams","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"Our work on CIP-31 yields several valuable insights for teams implementing similar vesting mechanisms:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Comprehensive flow analysis is essential","nodeType":"text"},{"data":{},"marks":[],"value":": Vesting protocols must account for all possible token flow paths, including edge cases around delegation and reward claiming.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Configuration flexibility requires security consideration","nodeType":"text"},{"data":{},"marks":[],"value":": Features that provide user flexibility (like custom withdrawal addresses) need careful analysis to ensure they don't compromise security guarantees.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"State transition clarity prevents gaps","nodeType":"text"},{"data":{},"marks":[],"value":": Complex protocols benefit from explicit handling of state changes, particularly around delegation lifecycle events.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Collaborative security review strengthens outcomes","nodeType":"text"},{"data":{},"marks":[],"value":": Early engagement with security teams allows for iterative improvement rather than post-implementation fixes.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"ordered-list"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Conclusion","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"Our audit of CIP-31 demonstrated the value of collaborative security review in strengthening blockchain protocols. The implementation showed strong alignment with its specification, and our review process helped identify opportunities for enhancement that further solidified its security guarantees.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The updated vesting mechanism ensures that staking rewards properly maintain lockup guarantees, strengthening Celestia's tokenomic design. This work exemplifies how security partnerships can enhance protocol development while building confidence in complex blockchain mechanisms.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"For teams developing similar vesting or tokenomic protocols, we recommend early security engagement and comprehensive analysis of all token flow scenarios to ensure robust, secure implementations.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"contentfulURL":"https://app.contentful.com/spaces/p79kctcd7ahy/entries/2YATT4L58yQlL8aLc9KrT9"},{"featureImage":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"6Y2MGd6UgxQLwBf7levB9k","type":"Asset","createdAt":"2025-07-17T19:10:07.838Z","updatedAt":"2025-07-17T19:10:07.838Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":3,"revision":1,"locale":"en-US"},"fields":{"title":"Blog Quint Espresso","description":"","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/6Y2MGd6UgxQLwBf7levB9k/9121e95b67ac4bcff9eae5b2cf24e80e/Blog_Quint_Espresso.jpg","details":{"size":372826,"image":{"width":1920,"height":1080}},"fileName":"Blog_Quint_Espresso.jpg","contentType":"image/jpeg"}}},"date":"2025-05-22","title":"Espresso HotShot Epoch Changes in Quint","slug":"espresso-hotshot-epoch-changes-in-quint-2025","categories":["Quint"],"authors":["Yassine Boukhari","Gabriela Moreira"],"keywords":"TLA+\nQuint\nQuintlang\nFormal Methods Audit \nBlockchain Security Audit \n","excerpt":{"nodeType":"document","data":{},"content":[{"nodeType":"paragraph","data":{},"content":[{"nodeType":"text","value":"How we used Quint to formalize Espresso's epoch change protocol with executable specifications. ","marks":[],"data":{}}]}]},"includeTableOfContents":false,"body":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"italic"}],"value":"That’s that Quint Espresso ","nodeType":"text"},{"data":{},"marks":[],"value":"☕🎶","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Introduction","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"One of the last security audits we performed was on the epoch change protocol for the HotShot consensus algorithm developed and used by Espresso. We formed a team to work on this audit, but also an additional team to work on a side quest: Formalizing that protocol in Quint. This blog post will cover how Quint helped the audit process and how the process of formal specification is ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"irreplaceable","nodeType":"text"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The Quint specification is available on ","nodeType":"text"},{"data":{"uri":"https://github.com/informalsystems/hotshot-spec"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"GitHub","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Using Quint for Espresso","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"HotShot is the ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"consensus protocol","nodeType":"text"},{"data":{},"marks":[],"value":" powering the Espresso Network, alongside a data‐availability layer to order transactions for an L2 rollup. It builds on a chained variant of HotStuff-2 and operates over a dynamically changing set of proof-of-stake validators: every ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"K","nodeType":"text"},{"data":{},"marks":[],"value":" blocks, a new ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"epoch","nodeType":"text"},{"data":{},"marks":[],"value":" begins, with a new validator set and stake table. HotShot runs in ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"views","nodeType":"text"},{"data":{},"marks":[],"value":" driven by a pacemaker that handles timeouts, view synchronization, and leader election. The ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"epoch-change","nodeType":"text"},{"data":{},"marks":[],"value":" protocol extends the core consensus to seamlessly transition between epochs.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The main challenge in formally specifying real world systems is to figure out a good ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"scope","nodeType":"text"},{"data":{},"marks":[],"value":" (and stick to it). In this project, we knew the scope: epoch changes. Now, it was a matter of sticking to this scope and keeping everything else as ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"abstracted","nodeType":"text"},{"data":{},"marks":[],"value":" as possible, so the Quint model didn’t get any more complex than it needed to be. Additionally, the main concern with this protocol was about ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"liveness","nodeType":"text"},{"data":{},"marks":[],"value":", which also became part of our scoping strategy and we'll cover later.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Scope Preservation","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"To preserve scope, we ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"abstract","nodeType":"text"},{"data":{},"marks":[],"value":" everything that is not part of the scope. For starters, the ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"block","nodeType":"text"},{"data":{},"marks":[],"value":". The only information this protocol needs from the block is its height, so that’s the only thing we model. ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"Certificates","nodeType":"text"},{"data":{},"marks":[],"value":" need signatures, but we assume that some reliable signing algorithm is used, and only store the ids of nodes who signed that certificate in the model, avoiding any encryption/decryption complexity and sticking to what matters, the protocol logic.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"In leader-based consensus under partial synchrony, the participating nodes may temporarily have different views of the correct leader, preventing progress. HotShot addresses this issue with the ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"Naor–Keidar view‐synchronization protocol, ","nodeType":"text"},{"data":{},"marks":[],"value":"a multi‐phase exchange involving designated relay nodes, relay‐to‐relay gossip, and the formation of view‐sync certificates to guarantee that all honest nodes converge on the same view number and leader despite timeouts or message delays.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Since modeling each protocol round and message exchange would bloat our Quint specifications and significantly expand the scope, we deliberately treat this view synchronization mechanism as a ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"black box","nodeType":"text"},{"data":{},"marks":[],"value":": once it completes, all honest replicas share a synchronized state and can proceed directly to the proposing and voting steps.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"On top of that, we are also careful to structure the Quint code in such a way that ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"network details","nodeType":"text"},{"data":{},"marks":[],"value":" are isolated from the protocol functionality. This helps a lot with reading and understanding the specification, and also enables changing the network easily and trying different set ups. This is something we always do when writing Quint specs, and you will hear more about our framework in the near future.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"To sum it up: we ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"abstract","nodeType":"text"},{"data":{},"marks":[],"value":" the things like the blocks and certificates, the view synchronization process and messaging/network details.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Quint vs. English Specification","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"A general problem with non-formal specifications is the ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"lack of precision","nodeType":"text"},{"data":{},"marks":[],"value":". English, markdown and even pseudocode do not force us to be precise, and being fully precise in those languages is almost impossible, even for the best of us - as Leslie Lamport recognized, by creating a new language to formally and precisely define his algorithms in papers. Imprecise descriptions have ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"ambiguities","nodeType":"text"},{"data":{},"marks":[],"value":" that can lead to wrong interpretations and faulty code.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Thankfully, all imprecisions we found in the HotShot epoch change specifications (paper and pseudocode) were ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"not","nodeType":"text"},{"data":{},"marks":[],"value":" translated into faulty code. Every time we found ambiguity in the specification, our audit team was alerted and they investigated the code carefully to confirm there were ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"no issues","nodeType":"text"},{"data":{},"marks":[],"value":", consulting the HotShot team when clarifications were needed. Having a pseudocode to work with is great, as it gives us an extensive amount of detail. However, it is often imprecise, as it is easy to forget some definitions or mess up the types when there’s no compiler in play. ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"Executable specifications","nodeType":"text"},{"data":{},"marks":[],"value":" solve this problem.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Some examples of ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"inconsistencies","nodeType":"text"},{"data":{},"marks":[],"value":" in the pseudocode are the fields ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"},{"type":"code"}],"value":"justify_cert ","nodeType":"text"},{"data":{},"marks":[],"value":"and ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"},{"type":"code"}],"value":"justify_qc ","nodeType":"text"},{"data":{},"marks":[],"value":"that seemed to be referring to the same value in the ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"proposal","nodeType":"text"},{"data":{},"marks":[],"value":" data structure, and the function ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"},{"type":"code"}],"value":"fetch_proposal ","nodeType":"text"},{"data":{},"marks":[],"value":"that was used but never defined.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Focus on Liveness ","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"The main security concern with the epoch-change protocol was regarding its liveness - that is, whether it always can ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"make progress","nodeType":"text"},{"data":{},"marks":[],"value":" and doesn’t get “stuck” in any ways. Even with our scoped model, epoch-change still requires a lot of states, as multiple nodes have to go through multiple blocks in order for an epoch to change. We didn’t have plans to try and constrain this into a ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"state space","nodeType":"text"},{"data":{},"marks":[],"value":" small enough for the model checkers to verify liveness. That didn’t seem feasible under our short time available, but also not really necessary. We managed to get really good ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"confidence","nodeType":"text"},{"data":{},"marks":[],"value":" about liveness through other means: witnesses and deadlock detection.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Witnesses","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"Even in the first stages of modeling, the very first question we wanted to answer was: can this go into another epoch? This was not really a question about the protocol itself, but about our model. “A state where epoch is 2” is what we call a witness property - something that we ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"expect to hold","nodeType":"text"},{"data":{},"marks":[],"value":" in at least one state in one execution. We can then ask the Quint simulator whether it can find a ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"trace","nodeType":"text"},{"data":{},"marks":[],"value":" that leads to a state that is described by the witness. If so, Quint produces as output a trace that describes step-by-step how the system goes from an initial state to “a state where epoch is 2”. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Simple witnesses like this are often the best way to find small issues when modeling, and using the Quint simulator to check that we can indeed ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"reach the basic scenarios","nodeType":"text"},{"data":{},"marks":[],"value":" is a great way to debug our version of the spec. For example, even the smallest issue on the function that determines whether a proposal is valid can cause the whole model to never accept any proposals, and therefore be “stuck”. Basic witnesses help us be sure we got rid of basic liveness issues.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Cross‐Epoch Extended Vote‐Propagation Witness","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"We defined a witness that checks that whenever an honest node forms the extended quorum certificate for block ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"K","nodeType":"text"},{"data":{},"marks":[],"value":" and enters epoch ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"e+1","nodeType":"text"},{"data":{},"marks":[],"value":", every honest node still in epoch ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"e","nodeType":"text"},{"data":{},"marks":[],"value":" should have extended‐vote messages ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"pending delivery","nodeType":"text"},{"data":{},"marks":[],"value":". We reasoned that without those votes in transit, some nodes would never observe the extended quorum certificate and a malicious leader could exploit this by simply withholding the certificate, halting progress. Quint immediately exposed a ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"trace","nodeType":"text"},{"data":{},"marks":[],"value":" where the spec only sent the extended votes to the next-view leader. So there was a liveness issue on the specification (not present on the code).","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We fixed this by making a change to the protocol so nodes broadcast those extended votes to all nodes in ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"e+1","nodeType":"text"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Deadlock detection","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"A deadlock is one way to ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"break liveness","nodeType":"text"},{"data":{},"marks":[],"value":", so we want to make sure deadlocks cannot occur. As all actions in this protocol are ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"reactions","nodeType":"text"},{"data":{},"marks":[],"value":" to messages (events), a deadlock is simply a state where there are ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"no messages in flight","nodeType":"text"},{"data":{},"marks":[],"value":". We send a message with the genesis block and certificate on the initial state, and from there on, there should always be messages in flight - otherwise, the system would be stuck. We defined this as an ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"invariant","nodeType":"text"},{"data":{},"marks":[],"value":" and tested it on many different samples using the Quint simulator, convincing ourselves that the system cannot hit deadlocks, and getting more confidence that liveness holds.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"While checking this deadlock invariant, Quint uncovered a ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"self-block","nodeType":"text"},{"data":{},"marks":[],"value":" on extended proposals","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"At view ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"v + 1","nodeType":"text"},{"data":{},"marks":[],"value":", the leader gathers quorum votes for block ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"K","nodeType":"text"},{"data":{},"marks":[],"value":" and forms ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"QC₁","nodeType":"text"},{"data":{},"marks":[],"value":". The leader immediately updates its ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"highQC ← QC₁","nodeType":"text"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"It then constructs and broadcasts its extended proposal for view ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"v + 2","nodeType":"text"},{"data":{},"marks":[],"value":", justified by ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"QC₁","nodeType":"text"},{"data":{},"marks":[],"value":". Upon receiving its own proposal, the validity check enforces:","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"ordered-list"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"code"}],"value":"proposal.view – 1 == proposal.certificate.view,","nodeType":"text"},{"data":{},"marks":[],"value":" and","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"code"}],"value":"proposal.certificate.view – 1 == highQC.view","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"blockquote"},{"data":{},"content":[{"data":{},"marks":[],"value":"But since ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"highQC.view","nodeType":"text"},{"data":{},"marks":[],"value":" was already set to ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"v + 1","nodeType":"text"},{"data":{},"marks":[],"value":", the second check fails (","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"v + 1 – 1 ≠ v + 1","nodeType":"text"},{"data":{},"marks":[],"value":"), so the leader rejects its own proposal and the quorum can’t be formed. No new messages get emitted, and the protocol deadlocks. This problem was also only present in the specification and not reflected in the code.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Final Thoughts","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"In conclusion, our experience working on the formal specification of the epoch-change protocol alongside the audit proved to be highly productive. Quint played a key role in uncovering ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"interesting scenarios","nodeType":"text"},{"data":{},"marks":[],"value":" that were then shared with the audit team, facilitating a deeper understanding of the expected behavior as defined by the specification. This collaborative approach not only raised ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"important questions","nodeType":"text"},{"data":{},"marks":[],"value":" but also highlighted the value of the specification itself as a valuable artifact with ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"enforced precision","nodeType":"text"},{"data":{},"marks":[],"value":" and no ambiguities.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"To learn more about Quint and how it can help you define precise and well-scoped parts of your system, visit the ","nodeType":"text"},{"data":{"uri":"https://quint-lang.org/"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Quint website","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". Our specialized team can help you leverage the power of Quint to ensure the security and reliability of your systems, reach out to us at ","nodeType":"text"},{"data":{"uri":"mailto:audits@informal.systems"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"audits@informal.systems","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". Learn more at ","nodeType":"text"},{"data":{"uri":"https://informal.systems/security-and-engineering"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"https://informal.systems/security-and-engineering","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"contentfulURL":"https://app.contentful.com/spaces/p79kctcd7ahy/entries/5r04Kpthe00mmcZcLeJcsn"},{"featureImage":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"38eNO8rr0jj6FgLsivV860","type":"Asset","createdAt":"2025-05-06T18:37:21.136Z","updatedAt":"2025-05-09T16:16:21.361Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":13,"revision":3,"locale":"en-US"},"fields":{"title":"Malachite plans banner","description":"Malachite 2025-2026 Plans","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/38eNO8rr0jj6FgLsivV860/df9547006714e630b93fe15b1ecceba2/Screenshot_2025-05-09_at_18.16.02.png","details":{"size":622068,"image":{"width":1388,"height":773}},"fileName":"Screenshot 2025-05-09 at 18.16.02.png","contentType":"image/png"}}},"date":"2025-05-07","title":"Malachite Consensus Engine 2025-2026 Roadmap","slug":"malachite-roadmap-2025","categories":["Malachite"],"authors":["Adi Seredinschi","Chris Andreola"],"keywords":"Tendermint \nMalachite BFT \nconsensus engine\nRoadmap\nMulti-proposer\nThroughput\nLatency\nTendermint\nBlockchain Performance\nProtocol Development","excerpt":{"nodeType":"document","data":{},"content":[{"nodeType":"paragraph","data":{},"content":[{"nodeType":"text","value":"High-performance consensus engine roadmap: 10x throughput and 30% latency reduction.","marks":[],"data":{}}]},{"nodeType":"paragraph","data":{},"content":[{"nodeType":"text","value":"","marks":[],"data":{}}]}]},"includeTableOfContents":false,"introduction":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Summary of our plans:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"For 2025:","nodeType":"text"},{"data":{},"marks":[],"value":" 5’000+ real TPS, full EVM compatibility, sub-500ms block-times, reliability (via Tendermint in Rust), and actual decentralization (for L1s or L2 sequencers) – this feature set will be available off-the-shelf w/ Malachite this year.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"For 2026:","nodeType":"text"},{"data":{},"marks":[],"value":" We will 1) 10x this throughput w/ multi-proposer design, 2) reduce latency by 30% via a two-phase Tendermint variant, as well as further optimize across the stack - see the roadmap described here-in.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Contact us: ","nodeType":"text"},{"data":{},"marks":[],"value":"If you’re interested in pushing the growth, performance, or differentiation of your application using Malachite, ","nodeType":"text"},{"data":{"uri":"https://calendly.com/chris-informal/malachite-intro"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"reach out to us, we’d love to talk!","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"body":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Introduction","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"Let’s picture this analogy. A consensus library is for a decentralized application as the engine is for a car. The application is like the whole automobile – the chassis, wheels, drivetrain, control systems, and so on.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"In most cars, the engine is an undifferentiated element, albeit a central one. In ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"some","nodeType":"text"},{"data":{},"marks":[],"value":" cars, however, the engine contributes to the uniqueness of the vehicle, setting it apart from other brands or models.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The differentiation and uniqueness of a car can go so far as to create legends. The Ferrari 250 GT Lusso is a good example, with the engine underneath having a songlike, enchanting, high-revving character. It was one the fastest passenger cars of its period.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"1rmPOy8iLsuVgZckC9n8L1","type":"Asset","createdAt":"2025-05-06T18:33:26.566Z","updatedAt":"2025-05-06T18:33:26.566Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":4,"revision":1,"locale":"en-US"},"fields":{"title":"Steve McQueen Ferrari 250GT Lusso","description":"Steve McQueen with a 1963 Ferrari 250 GT Berlinetta Lusso","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/1rmPOy8iLsuVgZckC9n8L1/2341fe597a2765b89a7053a847688002/Steve_McQueen_Ferrari_250GT_Lusso.jpeg","details":{"size":598001,"image":{"width":2118,"height":1644}},"fileName":"Steve McQueen Ferrari 250GT Lusso.jpeg","contentType":"image/jpeg"}}}},"content":[],"nodeType":"embedded-asset-block"},{"data":{},"content":[{"data":{},"marks":[],"value":"With Malachite, we strive for the same kind of excellence that went into the creation of such legendary cars and engines. We aspire to drive the growth and uniqueness of applications. This means the engine has to facilitate the creation of tangible, novel user experiences in the application.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Builders of decentralized applications cannot achieve this today. There is no consensus engine that enhances application performance and is reliable enough to drive stable growth for the application. With Malachite ","nodeType":"text"},{"data":{"uri":"https://informal.systems/blog/malachite-decentralize-whatever"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"we have started changing that","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". Below we describe the two flagship features of Malachite that will keep us busy and excited throughout the rest of this year, aiming to go live in 2026. The technical objectives we're chasing are a 10x in throughput and a ~30% latency reduction.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Plans","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"Priority zero","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"We will be developing the features below in parallel with what we call priority zero: Providing top support for the teams already building or experimenting with Malachite. This includes some of the most talented teams in crypto:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Starknet","nodeType":"text"},{"data":{},"marks":[],"value":" ecosystem, via integration of Malachite in the ","nodeType":"text"},{"data":{"uri":"https://github.com/madara-alliance/madara"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Madara","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" and ","nodeType":"text"},{"data":{"uri":"https://github.com/eqlabs/pathfinder"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Pathfinder","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" clients to enable the first decentralized L2 sequencer.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Farcaster","nodeType":"text"},{"data":{},"marks":[],"value":", via integration of Malachite in their recent sharding-based architecture of ","nodeType":"text"},{"data":{"uri":"https://github.com/farcasterxyz/snapchain/"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Snapchain","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", the data backend for the decentralized social media protocol (","nodeType":"text"},{"data":{"uri":"https://snapchain-docs.vercel.app/"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"docs","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":").","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Zcash ","nodeType":"text"},{"data":{},"marks":[],"value":"ecosystem, via the effort of the ","nodeType":"text"},{"data":{"uri":"https://www.shieldedlabs.net/"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Shielded Labs","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" team to create with Crosslink a novel hybrid PoW/PoS system powering Zcash. ","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"Aside from these three, a range of other teams are in discovery.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"This is priority zero. Just like an engine is nothing without the car, the consensus engine infrastructure such as Malachite is nothing without the great teams building tangible new applications with it.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"naElopF75NPphMVv9nR1I","type":"Asset","createdAt":"2025-05-07T17:22:08.587Z","updatedAt":"2025-05-19T22:34:03.871Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":10,"revision":2,"locale":"en-US"},"fields":{"title":"Malachite Roadmap Overview","description":"An overview of Malachite roadmap for 2025-2026","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/naElopF75NPphMVv9nR1I/e1a2e9f44806a8ab150357b35e71a256/X_Post_Malachite_Roadmap.jpg","details":{"size":2837569,"image":{"width":4800,"height":2700}},"fileName":"X_Post_Malachite_Roadmap.jpg","contentType":"image/jpeg"}}}},"content":[],"nodeType":"embedded-asset-block"},{"data":{},"content":[{"data":{},"marks":[],"value":"Feature 1: 10x throughput via a multi-proposer construction","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"We're introducing a construction that aims to enable Malachite-based applications to achieve superior throughput. Compared to prior consensus engines (e.g. CometBFT) this aims to enable ~100x throughput improvements; compared to Malachite today, it is a 10x improvement. This is achieved through an elegant combination of two techniques: multi-proposer block construction plus compact block support.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We designed the multi-proposer protocol construction directly on top of the original Tendermint in Rust implementation existing today in Malachite. Briefly, it uses the vote extension mechanism, so that each block at a certain height consists of vote extensions from earlier height(s). Each vote extension is a concise reference to one or multiple block parts, and originates from one of the validators at such an earlier height. Each block part comprises application payloads, e.g., user transactions. Therefore, any block at some height H is a combination of parts from a supermajority of nodes from earlier heights, H-1, H-2.., leading to a straightforward multi-proposer design. See also ","nodeType":"text"},{"data":{"uri":"https://x.com/AdiSeredinschi/status/1919790760549089335"},"content":[{"data":{},"marks":[],"value":"this thread","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" for additional context.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Since each vote extension is merely a ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"reference","nodeType":"text"},{"data":{},"marks":[],"value":" to one or multiple block parts -- not the full block itself -- this means that the full block parts never enter in the hot path of Tendermint's consensus pipeline. The application deals directly with full-fledged blocks, as does the broadcast layer (see below), but not the consensus protocol. This is a form of compact blocks support.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"A key building block of this feature is a high throughput dissemination layer which nodes use to broadcast block parts securely. It optionally uses signature aggregation to reduce verification and bandwidth overhead. The multi-proposer construction orchestrates among these three building blocks to build quickly a sequential history of blocks: (i) the dissemination layer, (ii) vote extension construction and validation, (iii) block construction using vote extensions.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We aim to publish the full protocol design in a dedicated post, stay tuned.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Feature 2: Lower latency via a two-phase Tendermint variant","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"We are introducing support in Malachite for a two-phase Tendermint variant. The original Tendermint variant entails three phases, namely Propose, Prevote, and Precommit. In a globally distributed system of nodes, each such stage can take up to 250ms, for a total theoretical latency of up to 750ms across the 3 stages. (Consider, for example, that a typical round-trip time for a packet to travel between, say, San Francisco and Sidney is 150ms-250ms.)","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"By eliminating one of the three phases, we can reduce the latency by roughly 33%. This can lower block production latency to under 500ms in a distributed global setting. For reference, we publish weekly experimental benchmarks for consensus latency and throughput in ","nodeType":"text"},{"data":{"uri":"https://informal.systems/malachite/dashboard"},"content":[{"data":{},"marks":[],"value":"this dashboard","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". Depending on scale and global distribution, latency today can be as low as ~150ms in practice with Malachite, which is not a typical feat in other consensus engines.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"To achieve the above, we adjust the fault-tolerance model underlying Tendermint, making it more strict. Instead of tolerating 1/3 corruption, the new variant tolerates 1/5 corruption. For many application builders, trading fault thresholds for reduced latency is very appealing.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"In the table below, we provide a simple overview on the benefit of the new variant contrasting with other well-known options. Two remarks about this overview. First, it ignores pre-confirmation latency optimizations (sometimes called speculative execution or early confirmations) which are largely orthogonal to the base protocols. Second, pipelining and linear authenticator complexity are important benefits of many HotStuff-family protocols, though they bring practical tradeoffs (e.g., application engineering complexity, increased latency) and for the moment we do not see them as central for high-performance.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Protocol design","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"table-header-cell"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"One-way message delays in the common case","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"table-header-cell"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Fault model","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"table-header-cell"}],"nodeType":"table-row"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Malachite: Tendermint variant with two-stages (new)","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"table-cell"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"2 (1 RTT)","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"table-cell"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"5F+1","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"table-cell"}],"nodeType":"table-row"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Malachite: original Tendermint with three stages (default)","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"table-cell"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"3 (1.5 RTT)","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"table-cell"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"3F+1","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"table-cell"}],"nodeType":"table-row"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"HotStuff: default","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"table-cell"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"7 (3.5 RTT)","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"table-cell"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"3F+1","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"table-cell"}],"nodeType":"table-row"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"HotStuff: optimized","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"table-cell"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"5 (2.5 RTT, e.g. Monad)","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"table-cell"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"3F+1","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"table-cell"}],"nodeType":"table-row"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Simplex","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"table-cell"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"3 (1.5 RTT)","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"table-cell"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"3F+1","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"table-cell"}],"nodeType":"table-row"}],"nodeType":"table"},{"data":{},"content":[{"data":{},"marks":[],"value":"Long-tail of optimizations throughout the engine stack","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"We also have a long-tail of optimizations investigating internally with researchers & engineers (to determine feasibility and viability) and externally with partners (to assess value and priority). We expect to deliver on them over the coming years. Among the most notable optimizations are libp2p improvements and network hardening service, optimization to Engine API for facilitating shorter block times, soft upgrades support, and built-in oracle support.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[],"nodeType":"hr"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Contact us: ","nodeType":"text"},{"data":{},"marks":[],"value":"If you’re interested in pushing the growth, performance, or differentiation of your application using Malachite, ","nodeType":"text"},{"data":{"uri":"https://calendly.com/chris-informal/malachite-intro"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"reach out to us, we’d love to talk!","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"\n","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"contentfulURL":"https://app.contentful.com/spaces/p79kctcd7ahy/entries/6Qa9YL20DL9HplJXpFsJWw"},{"date":"2025-05-01","title":"Our Security Audit Process Explained","slug":"informal-audit-process","categories":["Audits"],"authors":["Carlos Rodriguez","Josef Widder"],"keywords":"Security Audit\nAudit Process\nThreat Modeling\nFormal Verification\nQuint\nBlockchain Security\nProtocol Security\nDistributed Systems\nCode Review\nsmart contract audit ","excerpt":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"How Informal Systems conducts blockchain security audits using threat modeling and formal verification.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"includeTableOfContents":false,"body":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Security isn’t a checklist, it’s a mindset baked into every stage of protocol development. At Informal Systems, we approach blockchain audits not just as a search for bugs, but as a rigorous evaluation of system behavior, edge cases, and long-term resilience. Our background in distributed systems and formal verification allows us to identify vulnerabilities others might miss. Especially in cross-chain protocols, consensus mechanisms, and complex system interactions.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We don't rely on automated tools alone. We build models, define system invariants, and engage closely with engineering teams to ensure the systems we audit are secure by design, not just by convention.\n\n","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"How a Security Audit Works at Informal Systems","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[],"nodeType":"hr"},{"data":{},"content":[{"data":{},"marks":[],"value":"At Informal Systems, our security audits follow a comprehensive methodology grounded in our deep expertise in distributed systems and formal verification. Here's how our process typically unfolds:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"4WqdhQAp01HOx3sdc3prgu","type":"Asset","createdAt":"2025-04-30T21:30:24.345Z","updatedAt":"2025-04-30T21:30:24.345Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":3,"revision":1,"locale":"en-US"},"fields":{"title":"Blog AuditProcessFlowchart (1)","description":"","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/4WqdhQAp01HOx3sdc3prgu/8eae7d92b2a7851aeff34aa32908afde/Blog_AuditProcessFlowchart__1_.jpg","details":{"size":455717,"image":{"width":1920,"height":1080}},"fileName":"Blog_AuditProcessFlowchart (1).jpg","contentType":"image/jpeg"}}}},"content":[],"nodeType":"embedded-asset-block"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"\n\n1. Threat Modeling ","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"We begin by thoroughly understanding the high-level goals of the system – what it should do from the perspective of users and other connected systems. We examine implementation code, specifications, and documentation to reconstruct a mental model of the system, assessing whether the implementation aligns with the intended design.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Based on this understanding, we identify potential threats: unanticipated behaviors that could prevent the system from reaching its goals. For different types of protocols, we leverage domain specific threat families we've developed through years of experience.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"This phase creates a solid foundation of system and threat models that guide our entire audit process and become valuable documentation for development teams.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"2. Threat Analysis and Code Review","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"Our experienced team performs comprehensive threat analysis and code review, employing both static analysis tools and expert manual inspection to identify vulnerabilities.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Our auditors specifically analyze for:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Insufficient input validation","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Improper funds handling","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Mathematical errors and edge cases","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Protocol-level vulnerabilities","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Distributed systems failure modes","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"We're particularly focused on system level properties that are challenging to reason about in distributed systems, where components run in parallel and interact in unexpected ways. Our team pays special attention to edge cases in cross-chain solutions, where engineers often prioritize normal operations over exceptional conditions like timeouts and race conditions.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"3. Reporting","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"After our analysis, we provide a detailed report that:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Identifies all discovered vulnerabilities","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Documents the system model and threat model developed during our analysis","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Classifies issues by severity","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Provides clear recommendations for remediation","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Explains the implications of each finding","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"We don't deliver a report and walk away. We work closely with development teams to ensure they understand each issue and can implement effective fixes.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"4. Verification and Follow-up","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"For critical issues, we verify that the implemented fixes properly address the vulnerabilities we identified. This may involve additional testing or review of the updated code.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Formal Verification and Specialized Testing","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[],"nodeType":"hr"},{"data":{},"content":[{"data":{},"marks":[],"value":"Beyond our standard audit process, Informal Systems offers advanced security services for protocols where correctness is paramount:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Formal Verification with Quint","nodeType":"text"}],"nodeType":"heading-3"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"bi6k35V8rvL7459KvwaVD","type":"Asset","createdAt":"2025-04-22T15:56:11.290Z","updatedAt":"2025-04-22T15:56:11.290Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":5,"revision":1,"locale":"en-US"},"fields":{"title":"Blog QuintVisualization","description":"","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/bi6k35V8rvL7459KvwaVD/1b7f52c4996e5cd1fff07aeef2293484/Blog_QuintVisualization.jpg","details":{"size":387423,"image":{"width":1920,"height":1080}},"fileName":"Blog_QuintVisualization.jpg","contentType":"image/jpeg"}}}},"content":[],"nodeType":"embedded-asset-block"},{"data":{},"content":[{"data":{},"marks":[],"value":" Our formal specification language, ","nodeType":"text"},{"data":{"uri":"https://quint-lang.org/"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Quint","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", allows us to:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Model and verify complex protocol behaviors","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Test invariants that must always hold true","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Simulate potential attack vectors","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Discover edge cases that might be missed in traditional testing","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"Quint is particularly valuable for verifying properties of distributed systems that can't be tested with simple assertions, like ensuring agreement between multiple validators in a consensus protocol. We have been using Quint for internal and client projects, like in ","nodeType":"text"},{"data":{"uri":"https://github.com/informalsystems/malachite/tree/main/specs/quint"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Malachite","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", ","nodeType":"text"},{"data":{"uri":"https://informal.systems/blog/jellyfish-merkle-tree-quint-2025"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Grug’s Jellyfish Merkle Tree","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" and ","nodeType":"text"},{"data":{"uri":"https://informal.systems/blog/model-based-testing-to-secure-neutrons-liquidity"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Neutron’s Liquidity Pool migration","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Fuzz Testing","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"We also develop specialized fuzz testing implementations that generate thousands of randomized inputs to test protocol invariants. This helps identify edge cases and unexpected behaviors that might be missed in conventional testing approaches, especially in systems with complex state transitions or input handling.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"What Sets Informal's Security Approach Apart","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[],"nodeType":"hr"},{"data":{},"content":[{"data":{},"marks":[],"value":"Our security methodology is informed by our unique position as both developers and auditors of critical blockchain infrastructure. Some distinguishing aspects of our approach include:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Cross-Ecosystem Expertise","nodeType":"text"}],"nodeType":"heading-3"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"01iuYfzac3Nhp8lRFuwl5q","type":"Asset","createdAt":"2025-05-01T16:12:48.361Z","updatedAt":"2025-05-01T16:12:48.361Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":3,"revision":1,"locale":"en-US"},"fields":{"title":"Blog EcosystemExpertiseDiagram (2)","description":"","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/01iuYfzac3Nhp8lRFuwl5q/7864370bef27328be4d8efb59eaa425d/Blog_EcosystemExpertiseDiagram__2_.jpg","details":{"size":633822,"image":{"width":1920,"height":1080}},"fileName":"Blog_EcosystemExpertiseDiagram (2).jpg","contentType":"image/jpeg"}}}},"content":[],"nodeType":"embedded-asset-block"},{"data":{},"content":[{"data":{},"marks":[],"value":"Informal Systems has worked across multiple blockchain ecosystems, helping protocols bridge between different technologies securely. Our experience spans:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Cosmos","nodeType":"text"},{"data":{},"marks":[],"value":": Osmosis, Celestia, DyDx, Injective, Namada, Neutron, Stride, and many others","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Bitcoin","nodeType":"text"},{"data":{},"marks":[],"value":": Babylon, interBTC","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Ethereum","nodeType":"text"},{"data":{},"marks":[],"value":": Polygon, Polymer, Espresso","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Others","nodeType":"text"},{"data":{},"marks":[],"value":": Apex, LeftCurve, Ripple, Starknet","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"This cross-ecosystem understanding allows us to provide uniquely valuable insights when auditing bridges, interoperability protocols, and multi-chain applications.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Protocol Design Expertise","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"Rather than simply looking for known vulnerability patterns, we leverage our deep understanding of protocol design to assess whether a system can robustly achieve its goals under adverse conditions. This allows us to identify subtle issues that might be missed in a more mechanical review.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"System-Level Thinking","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"Many security issues in blockchain aren't solely about code bugs but about how different components interact. Having maintained critical infrastructure like CometBFT (formerly Tendermint Core), Malachite, IBC, Hermes, and the Cosmos Hub, we understand the importance of abstraction, modularity, and clear specifications in building secure systems.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Focus on Invariants","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"Instead of just enumerating edge cases, we focus on defining system invariants, properties that should always hold true. By breaking these down into smaller invariants and analyzing their interdependencies, we can develop more convincing arguments about a system's security.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Early Detection Priority","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"Finding vulnerabilities earlier in the development lifecycle saves significant resources. We work with teams throughout the design and implementation process, not only when code is ready for deployment. This approach aligns with our mission to foster trust in software and money.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Benefits of Working with Informal Systems for Security Audits","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[],"nodeType":"hr"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Deep Protocol Understanding","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"We put significant effort into understanding your protocols and their implementation. Security starts with a comprehensive understanding of what a system should do. This is captured in our system model and threat model sections, providing valuable information that teams can leverage long after the audit is completed.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Threat-Driven Approach","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"Our code reviews are grounded in defined threats, making them more effective and focused than \"random walks\" through code. We work backward from security risks, allowing us to concentrate on the most important vulnerabilities rather than collecting low-level and informational issues.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Transparent Security Analysis","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"We prioritize transparency in our work, providing detailed analysis of what has been inspected. This gives development teams clarity on what was checked and the reasoning behind security determinations. This approach is especially valuable for forward-looking security, as conditions that aren't issues now might become problems as the context changes.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Specialized Blockchain Expertise","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"Our team brings together experienced security engineers with broad expertise in designing, developing, and auditing various blockchain projects. This unique perspective combines deep technical knowledge with practical experience in maintaining critical blockchain infrastructure.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Conclusion","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[],"nodeType":"hr"},{"data":{},"content":[{"data":{},"marks":[],"value":"In the rapidly evolving blockchain space, security cannot be an afterthought. A comprehensive security audit from a team with deep protocol engineering expertise is essential for any project that aims to build lasting trust and protect user assets.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"At Informal Systems, we bring a unique combination of protocol design experience, formal verification expertise, and distributed systems knowledge to our security audits. This allows us to identify vulnerabilities that others might miss and provide recommendations that strengthen the fundamental design of blockchain systems.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Whether you're building a new Layer-1 blockchain, a cross-chain bridge, or a DeFi protocol, investing in security early and often is crucial for long-term success. The cost of a thorough audit pales in comparison to the potential losses from a security breach – both financial and reputational.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Ready to ensure your project meets the highest security standards?\n","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"\n","nodeType":"text"},{"data":{"uri":"mailto:audits@informal.systems"},"content":[{"data":{},"marks":[],"value":"Contact our team","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" to learn more about our security audit process and how we can help secure your protocol. Explore our ","nodeType":"text"},{"data":{"uri":"https://informal.systems/security-and-engineering"},"content":[{"data":{},"marks":[],"value":"security and engineering services","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" page and follow us on ","nodeType":"text"},{"data":{"uri":"https://x.com/informalinc"},"content":[{"data":{},"marks":[],"value":"X","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" for the latest updates.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"\n","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"contentfulURL":"https://app.contentful.com/spaces/p79kctcd7ahy/entries/4sYfykvzsaTRbahqyMrXIf"},{"featureImage":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"2ecoKoB8HPEZlogvxbmc9U","type":"Asset","createdAt":"2025-07-17T19:16:00.869Z","updatedAt":"2025-07-17T19:16:00.869Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":3,"revision":1,"locale":"en-US"},"fields":{"title":"Quint Official Launch Deck","description":"","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/2ecoKoB8HPEZlogvxbmc9U/985104a502c54161b4e5ac06243bc667/Quint_Official_Launch_Deck.jpg","details":{"size":1168664,"image":{"width":1920,"height":1080}},"fileName":"Quint Official Launch Deck.jpg","contentType":"image/jpeg"}}},"date":"2025-04-01","title":"Quint Launch Event Follow-Up Q&A and Recap","slug":"quint-launch-event-follow-up-2025","categories":["Quint"],"authors":["Gabriela Moreira"],"keywords":"Quint\nLaunch Event\nFormal Methods\nModel Checking\nQ&A\nCommunity\nSpecification Language\nApalache,\nTLC\nFormal Verification","excerpt":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Recap of our Quint launch event with community Q&A covering formal methods and model checking.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"includeTableOfContents":false,"body":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Quint Launch Event: Follow-Up Q&A and Recap","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We recently held our official launch event for Quint, and it was a fantastic experience! We were thrilled to see such a vibrant turnout and engage with so many enthusiastic community members. For those who couldn't make it, or for those who want a recap, here's a quick overview of what we covered. We also want to address some of the insightful questions raised during the Q&A session.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Event Recap","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"I (","nodeType":"text"},{"data":{"uri":"https://www.linkedin.com/in/bugarela/"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Gabriela Moreira","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", Lead Developer of Quint) shared the journey of Quint this far, including its vision and the problems it aims to solve. ","nodeType":"text"},{"data":{"uri":"https://www.linkedin.com/in/giuliano-losa-08b7b5223/"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Giuliano Losa","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" (Senior Researcher, Stellar Development Foundation) and ","nodeType":"text"},{"data":{"uri":"https://www.linkedin.com/in/juliancp/"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Julian Compagni Portis","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" (Head of Exchange, Neutron) provided valuable insights into how formal methods and Quint are being used in industrial scenarios. We also had a live demo showcasing Quint's capabilities and announced the open-sourcing of Quint’s new Rust core. The demo is available on ","nodeType":"text"},{"data":{"uri":"https://github.com/bugarela/quint-launch-demo"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"GitHub","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", including the Quint code and Quint commands I ran during the event.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Addressing Your Questions","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"We received many excellent questions during the Q&A, and we want to ensure everyone gets the answers they need. Here are the questions and our responses:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Q: Do you think it's a good idea to use Quint outside \"classic\" distributed systems (i.e. not blockchains, consensus etc, but something simpler like client-server)?","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"A: Quint is worth using when we need more confidence about a system. If we are already completely confident, it might be that Quint won’t add any value. If you are concerned that a complex sequence of events involving communication by several components may drive your system into a weird unwanted situation, then the Quint tools might help you to build confidence that such a dangerous sequence doesn’t exist. In the event, I mentioned Hillel Wayne’s rule of thumb for writing a spec: if it takes less than a week to implement it, it might not be worth writing a spec for it. I like to think in terms of confidence/insecurity. If I feel insecure about some part of the system, modeling it is valuable.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Q: Does Quint support asynchronous communication between the finite state machines? Like with buffers, for example?","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"A: All sorts of communication are supported, since Quint is general-purpose, but you have to implement it yourself. On our repository you will find examples for different kinds of communication patterns. Regarding the mentioned buffered communication, we usually abstract the communication in something like a global set of messages that all parties can access. As long as the abstraction follows the same assumptions as the real-world communication, they can be used to detect any issues. For example, if the messaging follows a “delivery at least once” model, we can use a set of messages where we don’t remove the message when consuming it, so behaviors where we consume the same message twice are allowed.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Q: What trends do you see emerging in the field of formal methods, and how does Quint fit into these trends?","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"A: Making formal methods more accessible is something that many people are pursuing, but there are different approaches. PlusCal was made on top of TLA+ to make it more like an imperative language, but it didn’t solve the syntax and the tooling issue, like Quint does.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Some projects aim to take away all of the “burden” from the user: they should not have to write any spec at all and still get the benefits of having a spec (or maybe, some LLM writes the spec for them). I believe that writing the spec is very valuable, and that we can make this experience rich by using a good language, good tools, and leveraging automation/LLMs for any remaining annoying parts. Quint is this tool that helps you think while you are creating or understanding a new system/algorithm/protocol, and our goal is to add more and more value to this process. It’s a matter of reducing cost and increasing value, but we don’t believe that the cost needs to be zero - it is worth writing specs, and Quint makes it even more worthwhile.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Q: Will there be more integrations with languages? Like Haskell?","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"A: We believe that the best way to bridge the gap between specification and implementation currently is Model-Based Testing. Writing the “glue code” to execute Quint traces in any language is quite straightforward, but we can make libraries to help with that in different languages. Currently, we have a library to parse traces produced by Quint in Rust (see the ","nodeType":"text"},{"data":{"uri":"https://docs.rs/itf"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"itf crate","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"), and ","nodeType":"text"},{"data":{"uri":"https://github.com/informalsystems/quint-sandbox/tree/main/SimpleBank"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"here","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"’s an example of how it can be used. A good next target for a lib like that is Python, as recently I have seen a lot of value in graphic visualization of traces, and Python has great tooling for rendering this type of graphics. I’d love to write one for Haskell if people start writing Quint specs for systems in Haskell 😀.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Q: How does Quint check for the counterexample? Is it a bounded checking?","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"A: When running ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"quint verify","nodeType":"text"},{"data":{},"marks":[],"value":", Quint uses Apalache, which performs bounded model checking with the Z3 SMT solver (read more ","nodeType":"text"},{"data":{"uri":"https://quint-lang.org/docs/model-checkers#apalache"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"here","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"). For unbounded model checking, you can use TLC. We are working on having a seamless integration soon (so you can run ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"quint verify --backend=tlc","nodeType":"text"},{"data":{},"marks":[],"value":"), but for now, there is a ","nodeType":"text"},{"data":{"uri":"https://github.com/informalsystems/quint/blob/main/tlc/check_with_tlc.sh"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"shell script","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" to transpile Quint into TLA+ and then call TLC on in with the proper parameters. Note that by “bounded” I mean the length of the execution. While Apalache only checks executions up to a bounded length, it is able to reason about, e.g., unbounded integer variables very efficiently due to SMT. In contrast, TLC forces you to use bounded (small) integers, as it tries to enumerate all evaluations of these variables. So which model checker works better for you will depend on the type of your properties and the data types in your specification.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"If you are asking specifically about how Apalache constructs the counterexample, it is a bit too much to explain here, but it basically constructs the SMT constraints in such a way that, if there is a valuation for the variables that satisfies the constraints, that valuation (the Z3 model) is the counterexample. You can read more about it in the ","nodeType":"text"},{"data":{"uri":"https://dl.acm.org/doi/10.1145/3360549"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Apalache paper at OOPSLA19","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"(Next two questions were combined)","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Q: Is it possible to generate code implementation from high-level specs?","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Q: It would be great to see Quint specs can be transpiled into target languages (e.g., Rust). I assume it would happen in the future. What are your thoughts?","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"A: It is possible in theory. In fact, I wrote a ","nodeType":"text"},{"data":{"uri":"https://github.com/bugarela/tla-transmutation"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"code generation tool","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" from TLA+ specs for my bachelor thesis’ work (back when Quint didn’t exist). Since specifications are more abstract than code, at least on some level, it’s hard to generate code that is actually useful. It can serve as a bootstrap, but you still need to implement many details. I don’t believe that tools like this can be useful in practice, and Model-Based Testing is a much more realistic approach to get some assurance that the implementation matches the specification. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Q: Is Apalache + Z3 the sanctioned way to model-check, going forward?","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"A: Not only, we are integrating TLC and we consider making it the default backend, as its behavior is more predictable and understandable. Apalache and TLC are both great tools and one can out-perform the other in some classes of specifications, so I don’t see us choosing a favorite and sticking with it. You can read about the comparison ","nodeType":"text"},{"data":{"uri":"https://quint-lang.org/docs/model-checkers"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"here","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Q: Is Quint itself formally verified by Quint?","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"A: No. Most model-checking tools are not verified, just like Apalache and TLC are not. The Quint tool itself is mostly a compiler, and verifying compilers is a tough task, usually done with proof assistants like Coq or Lean, which are a better fit at this level of the stack.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Q: Are batteries included? I didn't find examples of several state machines communicating. Can this be included, as it's common when working with real models?","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"A: We are working on having some templates for the most common use-cases, and I’ll also (very soon) improve the documentation about examples to make sure we include examples that are hosted in stand-alone repositories, like ","nodeType":"text"},{"data":{"uri":"https://github.com/informalsystems/malachite"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Malachite","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" and ","nodeType":"text"},{"data":{"uri":"https://github.com/informalsystems/mysticeti-spec"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Mysticeti","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", which cover how you can model communication.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Q: Do you plan to integrate it with Lean?","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"A: Well, my answer would have been “no”, but then I saw this post on X: ","nodeType":"text"},{"data":{"uri":"https://x.com/ilyasergey/status/1912011803753894159"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"https://x.com/ilyasergey/status/1912011803753894159","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Q: Can I use the Quint Rust library to test my actual implementation in Rust? Or do I need to translate the Quint spec into code and accept this translation risk?","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"A: You can use your existing code. You just need to write some “glue code” that reads the traces from Quint and calls the corresponding functions in your Rust code. See an example ","nodeType":"text"},{"data":{"uri":"https://github.com/informalsystems/quint-sandbox/blob/main/SimpleBank/tests/bank_mbt.rs"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"here","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Q: Do you consider having Slack for better structure instead of Telegram?","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"A: We have a ","nodeType":"text"},{"data":{"uri":"https://informal-systems.zulipchat.com/#narrow/stream/378959-quint"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Zulip stream","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", which has the same structure as Slack. I like the structure, but we do have much more messages in Telegram. I’m happy to use whatever the community prefers.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Q: Is there a plan to add more built-in types to Quint or should they be spells based on the existing primitives? For example the BoundedUInt?","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"A: The plan is that the spells become a standard library and eventually we have some package system. The philosophy is that anything that can be written in Quint (i.e. as a spell) doesn’t need to go into the built-ins, as that would just mean more maintenance work. From the user perspective, using the standard library should be as easy as using the built-ins (which is not the case at the moment).","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Q: Does Quint have a type system?","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"A: Yes, it has. You are only required to annotate the types of state variables and constants (constants work as module parameters, not the same as Javascript constants you use all the time), which usually are just a handful of definitions. Everything else is inferred, but you can annotate it if you want. It also has an effect system that makes sure you stay in the right modes and don’t read/update variables where you are not supposed to.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Q: What do I need to use Quint with my Rust project? (Can I do ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"},{"type":"code"}],"value":"cargo quint init?","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":") 😃","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"A: The language of your project only matters if you want to write Model-Based Tests. Before that, you need a Quint model, so you just start a Quint file from scratch - there’s no boilerplate, really. Once you have the model, you can write the “glue code” for the Model-Based Tests by using the ","nodeType":"text"},{"data":{"uri":"https://docs.rs/itf"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"itf","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" library (for Rust), like in ","nodeType":"text"},{"data":{"uri":"https://github.com/informalsystems/quint-sandbox/blob/main/SimpleBank/tests/bank_mbt.rs"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"here","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Q: What is the quickest way to learn Quint?","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"A: I thought a lot about Quint’s website structure and it encapsulates what I think it’s best for learning. I’d start there and then try to write your own spec for something. It can be for a fun game you like, or something like the protocol to follow to clean your cat’s litter box and make sure any cat issues are detected in less than 12 hours. During this process, you can ask questions on ","nodeType":"text"},{"data":{"uri":"https://t.me/quint_lang"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Telegram","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", ","nodeType":"text"},{"data":{"uri":"https://informal-systems.zulipchat.com/#narrow/stream/378959-quint"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Zulip","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" or ","nodeType":"text"},{"data":{"uri":"https://github.com/informalsystems/quint/discussions"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"GitHub","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". Once you have something, you can open a PR to add your example to Quint’s examples folder, and I’ll review your PR and give you feedback. This way, you contribute to the next people learning Quint, and get my (and maybe some more) pair of eyes on your model.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[],"nodeType":"hr"},{"data":{},"content":[{"data":{},"marks":[],"value":"We're excited to see what you build with Quint. If you haven’t started yet, follow our ","nodeType":"text"},{"data":{"uri":"https://quint-lang.org/docs/getting-started"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Getting Started","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" tutorial and tell us what your experience has been on the ","nodeType":"text"},{"data":{"uri":"https://t.me/quint_lang"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Telegram chat","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"! If you want some help from our specialized team to get started, you can find us at ","nodeType":"text"},{"data":{"uri":"mailto:audits@informal.systems"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"audits@informal.systems","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" or ","nodeType":"text"},{"data":{"uri":"https://informal.systems/security-and-engineering"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"https://informal.systems/security-and-engineering","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"contentfulURL":"https://app.contentful.com/spaces/p79kctcd7ahy/entries/1jWO7SAM1viAdyUcJeXPjX"},{"featureImage":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"4nvf9SGIXBsGycEd5QTTW7","type":"Asset","createdAt":"2025-03-19T10:38:56.062Z","updatedAt":"2025-03-19T10:38:56.062Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":4,"revision":1,"locale":"en-US"},"fields":{"title":"Malachite banner","description":"","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/4nvf9SGIXBsGycEd5QTTW7/e90ca1fa1e7b445d5bd7bb0bc3646427/Malachite_Banners__1_.jpg","details":{"size":24742,"image":{"width":1200,"height":675}},"fileName":"Malachite Banners (1).jpg","contentType":"image/jpeg"}}},"date":"2025-03-19","title":"Malachite x Reth, Part 2: Connecting to Ethereum execution clients via Engine API","slug":"malachite-x-reth-part-2-2025","categories":["Malachite"],"authors":["Hernán Vanzetto"],"keywords":"Tendermint BFT consensus algorithm Ethereum blockchain execution client scalable flexible design","excerpt":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"We introduce ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"malaketh-layered","nodeType":"text"},{"data":{},"marks":[],"value":", an MVP of","nodeType":"text"},{"data":{},"marks":[],"value":" Malachite x Reth integration via the Engine API.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"includeTableOfContents":true,"introduction":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Summary","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"We introduce ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"malaketh-layered","nodeType":"text"},{"data":{},"marks":[],"value":", a Malachite x Reth integration MVP.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Malaketh-layered operates with two separate binaries—one for consensus and one for execution—offering the flexibility to leverage any Engine API-compliant client (such as Reth, but also Geth or Nethermind) and retain compatibility with existing Ethereum developer tooling out of the box. The tradeoff for this choice is seemingly in performance, because the two binaries are not vertically integrated and interactions need to pass through Engine API.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"This design stands in contrast with our previous MVP, ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"malaketh-turbo","nodeType":"text"},{"data":{},"marks":[],"value":", which combines Malachite and Reth into a single binary optimised for maximum throughput. See the design for ","nodeType":"text"},{"data":{"uri":"https://informal.systems/blog/malachite-x-reth-conclusions-from-two-mvps"},"content":[{"data":{},"marks":[],"value":"malaketh-turbo here","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"If you're interested in pushing the performance limits of EVM stacks and want to know more about these MVPs and Malachite Engine, let ","nodeType":"text"},{"data":{"uri":"https://t.me/MalachiteEngine"},"content":[{"data":{},"marks":[],"value":"us know","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"!","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"\n","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"body":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Introduction","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"Ethereum's architecture consists of two primary layers: Consensus Layer (CL) and Execution Layer (EL), with Engine API serving as the bridge between both. Malaketh-layered is an MVP to explore how Malachite can function as the consensus engine (CL) for Ethereum execution clients (EL) through Engine API. Our goal is to show how Malachite can act as the consensus engine for Layer 1 blockchains with Ethereum Virtual Machine (EVM) smart contracts, as well as a sequencer for Layer 2 chains.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"By leveraging Malachite's channel-based interface, we built a lightweight shim layer on top that integrates seamlessly with any execution client supporting Engine API. For this MVP we have chosen Reth as the execution client, but the design is agnostic and should work with any Engine API-compliant client, such as Geth or Nethermind.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"7awgQfnktdS4zo2wZtgDAH","type":"Asset","createdAt":"2025-03-19T10:34:40.348Z","updatedAt":"2025-03-19T11:00:31.844Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":21,"revision":4,"locale":"en-US"},"fields":{"title":"malaketh-layered-0-1","description":"Architecture of malaketh-layered, as a shim layer between Malachite (driving consensus), and Ethereum execution client (handling block execution).","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/7awgQfnktdS4zo2wZtgDAH/e97aab3ec35bb7339dfbf1a1a1982af7/Screenshot_2025-03-19_at_11.59.14.png","details":{"size":92079,"image":{"width":754,"height":431}},"fileName":"Screenshot 2025-03-19 at 11.59.14.png","contentType":"image/png"}}}},"content":[],"nodeType":"embedded-asset-block"},{"data":{},"content":[{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"It's worth noting that malaketh-layered is not an Ethereum consensus client. Ethereum's consensus mechanism is based on Gasper, a hybrid of Casper FFG for finality and LMD-GHOST for fork choice, where blocks are confirmed as immutable after two epochs, approximately 12.8 minutes. In contrast, Malachite implements Tendermint, a BFT protocol with instant or single-slot finality. This means malaketh-layered is bringing instant finality to Ethereum execution but it cannot be used as a direct replacement for Ethereum's consensus clients such as Lighthouse or Prysm.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Engine API","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"Engine API plays a central role in Ethereum's post-merge architecture, defining a standardised RPC interface between the Consensus Layer (CL) and Execution Layer (EL). The CL is responsible for agreeing on the canonical chain and finalising blocks, while the EL handles block creation, processing and execution, state management, blockchain storage, mempool management, RPC interfaces, and more.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"From the perspective of Engine API, the CL is a client that makes RPC calls with Engine API methods to the EL, the RPC server. Key methods are:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"code"}],"value":"forkchoiceUpdated","nodeType":"text"},{"data":{},"marks":[],"value":": Updates the execution client with the latest chain head and final block. If called with a ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"PayloadAttributes","nodeType":"text"},{"data":{},"marks":[],"value":" parameter, it instructs the client to build a new block. This method also plays a role in Ethereum's finality mechanism by marking blocks as finalised.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"code"}],"value":"getPayload","nodeType":"text"},{"data":{},"marks":[],"value":": Retrieves a newly constructed block from the execution client after calling ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"forkchoiceUpdated","nodeType":"text"},{"data":{},"marks":[],"value":" with ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"PayloadAttributes","nodeType":"text"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"code"}],"value":"newPayload","nodeType":"text"},{"data":{},"marks":[],"value":": Submits a proposed block to the execution client for validation and inclusion in the chain. Note that it does not change the tip of the chain, which is the job of ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"forkchoiceUpdated","nodeType":"text"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"Malachite as a library","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"Malachite offers three interfaces at different abstraction levels: Low-level, Actors, and Channels. These interfaces range from fine-grained control to ready-to-use functionality.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"In this MVP, we use the Channel-based interface, which prioritises ease of use over customisation. It provides built-in synchronisation, crash recovery, networking for consensus voting, and block propagation protocols. Application developers only need to interact with Malachite through a channel that emits events, such as:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"code"}],"value":"AppMsg::ConsensusReady { reply }","nodeType":"text"},{"data":{},"marks":[],"value":": Signals that Malachite is initialised and ready to begin consensus.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"code"}],"value":"AppMsg::GetValue { height, round, timeout, reply }","nodeType":"text"},{"data":{},"marks":[],"value":": Requests a value (e.g., a block) from the application when the node is the proposer for a given height and round.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"code"}],"value":"AppMsg::ReceivedProposalPart { from, part, reply }","nodeType":"text"},{"data":{},"marks":[],"value":": Delivers parts of a proposed value from other nodes, which are reassembled into a complete block.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"code"}],"value":"AppMsg::Decided { certificate, reply }","nodeType":"text"},{"data":{},"marks":[],"value":": Notifies the application that consensus has been reached, providing a certificate with the decided value and supporting votes.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"Malachite sends additional messages (e.g., for synchronisation), but we focus only on the core events relevant to this integration. Each event includes a ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"reply","nodeType":"text"},{"data":{},"marks":[],"value":" callback, allowing the application to respond to Malachite.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"For more details on Malachite's architecture and its three interfaces, check out the blog post ","nodeType":"text"},{"data":{"uri":"https://informal.systems/blog/the-most-flexible-consensus-api-in-the-world"},"content":[{"data":{},"marks":[{"type":"italic"}],"value":"The Most Flexible Consensus API in the World","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". For a hands-on explanation of the Channels API, see the ","nodeType":"text"},{"data":{"uri":"https://github.com/informalsystems/malachite/blob/13bca14cd209d985c3adf101a02924acde8723a5/docs/tutorials/channels.md"},"content":[{"data":{},"marks":[],"value":"Malachite Channels tutorial","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Connecting Malachite to Engine API","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"Malaketh-layered is an application built on top of Malachite, which is unaware of Engine API and only exposes the Channels interface. The application includes two main components for interacting with the execution client:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"An RPC client with JWT authentication to send Engine API requests to the execution client.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"An internal state to keep track of values such as the latest block and the current height, round, and proposer. It also maintains persistent storage for proposals and block data to support block propagation.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"Our integration revolves around three scenarios: initialising consensus, proposing a block as the proposer, and voting as a non-proposer. Below we outline how Malachite's events map to Engine API calls.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Consensus initialisation","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"When Malachite starts, it sends a ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"AppMsg::ConsensusReady","nodeType":"text"},{"data":{},"marks":[],"value":" event to signal the app that is ready. For simplicity, we assume all nodes begin from a clean state (height one) without needing to sync with an existing network. Each execution client initialises from the same genesis file, producing an initial block (block number 1) with a ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"parent_hash","nodeType":"text"},{"data":{},"marks":[],"value":" of ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"0x0","nodeType":"text"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"2Aj2zT6BV5hUmxFepCUi2h","type":"Asset","createdAt":"2025-03-19T10:35:46.664Z","updatedAt":"2025-03-19T10:35:46.664Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":4,"revision":1,"locale":"en-US"},"fields":{"title":"malaketh-layered-1","description":"Initialization sequence diagram","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/2Aj2zT6BV5hUmxFepCUi2h/8bcb1260310f32e9bcf95e0fdca5668c/malaketh-layered-1.png","details":{"size":68072,"image":{"width":1977,"height":441}},"fileName":"malaketh-layered-1.png","contentType":"image/png"}}}},"content":[],"nodeType":"embedded-asset-block"},{"data":{},"content":[{"data":{},"marks":[],"value":"Malaketh-layered queries the execution client via the ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"eth_getBlockByNumber","nodeType":"text"},{"data":{},"marks":[],"value":" RPC endpoint to fetch the latest committed block (in this case, the genesis block). This block is stored in the application state and serves as the base for building subsequent blocks.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Proposing and committing a block","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"When a node becomes the proposer for a given height and round, the application receives from Malachite a ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"AppMsg::GetValue","nodeType":"text"},{"data":{},"marks":[],"value":"event. The node must propose a new block to the network. Here's how the application drives this process:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"The application calls ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"forkchoiceUpdated","nodeType":"text"},{"data":{},"marks":[],"value":" with ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"PayloadAttributes","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":" to instruct the execution client to build a new block. If the parameters are valid and everything goes as expected, the RPC method will return a ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"payload_id","nodeType":"text"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Immediately, it calls ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"getPayload","nodeType":"text"},{"data":{},"marks":[],"value":" with the ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"payload_id","nodeType":"text"},{"data":{},"marks":[],"value":" of the previous step to retrieve an execution payload (the block).","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"The block is stored in the app’s local state and is sent back to Malachite via the ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"reply","nodeType":"text"},{"data":{},"marks":[],"value":" callback, where it's propagated to other validators.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"ordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"At this moment validators exchange Tendermint votes to reach consensus. Once agreed, Malachite emits ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"AppMsg::Decided","nodeType":"text"},{"data":{},"marks":[],"value":" to the application, which finalises the block in the execution client with the following steps:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Retrieve the stored block and compute its hash.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Call ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"forkchoiceUpdated","nodeType":"text"},{"data":{},"marks":[],"value":" with the block’s hash (no ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"PayloadAttributes","nodeType":"text"},{"data":{},"marks":[],"value":") to set the block as the head of the chain and finalise it.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Update the local state with the new block and certificate. Finally, signal Malachite to proceed to the next height.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"ordered-list"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"4uxmNstJCy27YtEL9FFGXd","type":"Asset","createdAt":"2025-03-19T10:36:28.521Z","updatedAt":"2025-03-19T10:36:28.521Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":5,"revision":1,"locale":"en-US"},"fields":{"title":"malaketh-layered-2","description":"Sequence diagram of proposing and committing a block","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/4uxmNstJCy27YtEL9FFGXd/feca5924fd8dbae9867942e92c52e717/malaketh-layered-2.png","details":{"size":281393,"image":{"width":2103,"height":1434}},"fileName":"malaketh-layered-2.png","contentType":"image/png"}}}},"content":[],"nodeType":"embedded-asset-block"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Voting and committing as a non-proposer","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"As a non-proposer, the application receives ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"AppMsg::ReceivedProposalPart","nodeType":"text"},{"data":{},"marks":[],"value":" events with block fragments. Once all parts are re-assembled, the block is stored locally. Eventually, Malachite concludes consensus by emitting a ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"AppMsg::Decided","nodeType":"text"},{"data":{},"marks":[],"value":" event. The application then calls ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"newPayload","nodeType":"text"},{"data":{},"marks":[],"value":" to submit the decided block to the execution client, followed by","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"forkchoiceUpdated","nodeType":"text"},{"data":{},"marks":[],"value":" to update the chain head and finalise the block.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"5wjRd8cfJ2g8wHnD23I2Dw","type":"Asset","createdAt":"2025-03-19T10:37:10.403Z","updatedAt":"2025-03-19T10:37:10.403Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":6,"revision":1,"locale":"en-US"},"fields":{"title":"malaketh-layered-3","description":"Sequence diagram depicting the process of voting and committing as a non-proposer","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/5wjRd8cfJ2g8wHnD23I2Dw/005c76b2cc0db845aac4421a5b49eb12/malaketh-layered-3.png","details":{"size":220224,"image":{"width":2331,"height":1257}},"fileName":"malaketh-layered-3.png","contentType":"image/png"}}}},"content":[],"nodeType":"embedded-asset-block"},{"data":{},"content":[{"data":{},"marks":[],"value":"Performance evaluation","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"We deployed three nodes on a local network, each pairing a malaketh-layered application with a Reth instance. A separate application generates EIP-1559 token-transfer transactions (approximately 120 bytes each) at a rate of 1000 transactions per second (tps), sending them to one of the node’s mempools for dissemination.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The network processes blocks at an average rate of 6 blocks per second, successfully handling all transaction load. However, a significant number of these blocks are empty, even in the presence of pending transactions in the mempool. This suggests that Reth does not take all available pending transactions when constructing blocks. In the current setting, increasing the transaction load beyond 1000 tps results in mempools getting full. We still need to investigate the exact cause, which could be related to misconfiguration or Reth’s logic for block creation. In any case, we believe that the system can handle much higher throughput once this issue is solved.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Check out the malaketh-layered repo to see how to reproduce these tests -- ","nodeType":"text"},{"data":{"uri":"https://github.com/informalsystems/malaketh-layered"},"content":[{"data":{},"marks":[],"value":"https://github.com/informalsystems/malaketh-layered","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Take-aways","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Malachite's Channels interface integrated smoothly with Engine API. In the past we have briefly attempted to integrate CometBFT via ABCI++ to Reth and that proved to be less straightforward.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Engine API may be too tied to Ethereum, which has a different finality mechanism than Tendermint. For instance, the ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"forkchoiceUpdated ","nodeType":"text"},{"data":{},"marks":[],"value":"method takes three block hashes as arguments: ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"head_block_hash","nodeType":"text"},{"data":{},"marks":[],"value":" for the head to the chain, ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"safe_block_hash","nodeType":"text"},{"data":{},"marks":[],"value":" for the most recent block that is deemed safe from chain reorganisation, and ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"finalized_block_hash ","nodeType":"text"},{"data":{},"marks":[],"value":"for the latest immutable block. For Tendermint, we just need to set all three parameters to the same value. Similarly for instructing the execution client to create a block with ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"code"}],"value":"PayloadAttributes","nodeType":"text"},{"data":{},"marks":[],"value":", which is linked to Ethereum's fee market and how transactions are processed.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"The performance bottleneck is currently in Reth, which often produces empty blocks despite having pending (valid) transactions in the mempool. In more realistic scenarios with hundreds of nodes, we expect Malachite to also start showing edge cases, such as synchronisation issues, missed blocks, higher rounds, or timeouts. For handling these cases, we will probably need to adapt the current interaction with the execution client.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"The design described in the present blog post stands in contrast with our previous MVP, called malaketh-turbo, which combines Malachite and Reth into a single binary optimised for maximum throughput. See the ","nodeType":"text"},{"data":{"uri":"https://informal.systems/blog/malachite-x-reth-conclusions-from-two-mvps"},"content":[{"data":{},"marks":[],"value":"design for malaketh-turbo here","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". To recall, both the ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"layered","nodeType":"text"},{"data":{},"marks":[],"value":" and ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"turbo","nodeType":"text"},{"data":{},"marks":[],"value":" Malaketh MVPs exhibit single slot finality and sub-second block latency.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"7ljiC4H1boblTDiRB34MUi","type":"Asset","createdAt":"2025-03-13T08:20:52.623Z","updatedAt":"2025-03-19T15:00:53.326Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":12,"revision":3,"locale":"en-US"},"fields":{"title":"Malaketh MVPs overview","description":"Tradeoffs and similiarities between the turbo and layered Malaketh designs.","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/7ljiC4H1boblTDiRB34MUi/e29a49db988f08c8cfc362530c51e834/Screenshot_2025-03-13_at_09.20.08.png","details":{"size":702843,"image":{"width":1872,"height":700}},"fileName":"Screenshot 2025-03-13 at 09.20.08.png","contentType":"image/png"}}}},"content":[],"nodeType":"embedded-asset-block"},{"data":{},"content":[{"data":{},"marks":[],"value":"Links","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Malaketh-layered repo: ","nodeType":"text"},{"data":{"uri":"https://github.com/informalsystems/malaketh-layered"},"content":[{"data":{},"marks":[],"value":"https://github.com/informalsystems/malaketh-layered","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Malachite ","nodeType":"text"},{"data":{"uri":"https://github.com/informalsystems/malachite/blob/13bca14cd209d985c3adf101a02924acde8723a5/ARCHITECTURE.md"},"content":[{"data":{},"marks":[],"value":"ARCHITECTURE.md","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Tutorial on ","nodeType":"text"},{"data":{"uri":"https://github.com/informalsystems/malachite/blob/13bca14cd209d985c3adf101a02924acde8723a5/docs/tutorials/channels.md"},"content":[{"data":{},"marks":[],"value":"Malachite’s Channel-based API","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Prior blog on Malachite: ","nodeType":"text"},{"data":{"uri":"https://informal.systems/blog/the-most-flexible-consensus-api-in-the-world"},"content":[{"data":{},"marks":[],"value":"The most flexible Consensus API in the world","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"","nodeType":"text"},{"data":{"uri":"https://github.com/ethereum/execution-apis/tree/main/src/engine"},"content":[{"data":{},"marks":[],"value":"Engine API reference","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Reth repo: ","nodeType":"text"},{"data":{"uri":"https://github.com/paradigmxyz/reth"},"content":[{"data":{},"marks":[],"value":"https://github.com/paradigmxyz/reth","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"contentfulURL":"https://app.contentful.com/spaces/p79kctcd7ahy/entries/93FnSwuOTJhjYU5Z69uXf"},{"featureImage":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"3KEOCteANg5Z0d55JGhA0b","type":"Asset","createdAt":"2025-03-14T21:39:43.986Z","updatedAt":"2025-07-17T19:11:00.488Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":13,"revision":3,"locale":"en-US"},"fields":{"title":"Quint","description":"","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/3KEOCteANg5Z0d55JGhA0b/6b08e13a3206960c6c423b0ed27d0c63/Quint_Backgrounds_1.jpg","details":{"size":920204,"image":{"width":1920,"height":1080}},"fileName":"Quint_Backgrounds_1.jpg","contentType":"image/jpeg"}}},"date":"2025-03-19","title":"Understanding Mysticeti Consensus with Quint","slug":"understanding-mysticeti-consensus-with-quint-2025","categories":["Quint"],"authors":["Gabriela Moreira"],"keywords":"programming language rustlang tla+ tla syntax abci++\n\nmysticeti-consensus\nquint-specification\ndag-consensus\nformal-verification\nblockchain-protocols\nconsensus-algorithms\ndistributed-systems\nprotocol-modeling\ninteractive-specs\nconsensus-testing","excerpt":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"How Quint transforms complex DAG consensus algorithms into interactive, testable models.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"includeTableOfContents":false,"body":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Important Context","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"For this post, it’s important to establish who I am. I’m not a consensus expert - far from it. I work on Quint, a modern specification language, which involves compilers and formal methods. At Informal Systems, we have brilliant consensus experts, but I’m not one of them. My background doesn’t include distributed systems or DAG-based blockchains, so jumping into the ","nodeType":"text"},{"data":{"uri":"https://sui.io/mysticeti"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Mysticeti","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" consensus algorithm was a big leap.\n","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"At Informal, our consensus gurus are already rocking with Quint (check out ","nodeType":"text"},{"data":{"uri":"https://github.com/informalsystems/malachite"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Malachite","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"!), so we decided to see what would happen if a \"Quint expert tried consensus.\" And yes, I started with a complex one.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"It worked. And now I feel an (even bigger) urge to teach everyone about Quint so they can also be empowered to learn in this new awesome way.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Starting with the Algorithm","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"The Mysticeti consensus algorithm is a function that operates on a ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"Directed Acyclic Graph (DAG)","nodeType":"text"},{"data":{},"marks":[],"value":" that is constructed by broadcasting blocks and information about previously seen blocks. The outcome is a sequence in which blocks should be committed to the blockchain. The algorithm doesn’t need to exchange any further messages at this stage - as for all DAG-based algorithms, the decision is made by only processing the DAG.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"In the paper, this function is defined with pseudocode accompanied by some brief descriptions. The hardest part about this project was to understand the paper’s definitions well enough to describe them in Quint (which is not actually understanding the algorithm and how it works). Some of the pseudocode was incomplete, and I found myself juggling terminology from:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"","nodeType":"text"},{"data":{"uri":"https://arxiv.org/abs/2310.14821"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"The paper","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"","nodeType":"text"},{"data":{"uri":"https://www.youtube.com/watch?v=JhhCxyZylx8"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"A youtube video","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"The code (from a ","nodeType":"text"},{"data":{"uri":"https://github.com/MystenLabs/mysticeti"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"prototype","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":")","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"ordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"Since I'm not from the consensus field, there were definitely gaps between the assumed prior knowledge in these resources and what I actually knew. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"My first attempt at translating the algorithm into ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"Quint","nodeType":"text"},{"data":{},"marks":[],"value":" was incorrect. But through iterative refinement -using visualization and testing - I eventually arrived at a version that aligns with the paper’s description. This process showed me how ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"Quint","nodeType":"text"},{"data":{},"marks":[],"value":" isn’t just a tool for experts; it’s a tool for learning.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Visualization: Seeing the DAG","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"A DAG is a graph, and graphs need to be visualized. Even with Quint's clear traces, I couldn't fully grasp what was happening without drawing it out. So, instead of banging my head against Quint traces, I:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Asked ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"Quint","nodeType":"text"},{"data":{},"marks":[],"value":" to export traces to ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"JSON","nodeType":"text"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Used an existing Rust trace parser (","nodeType":"text"},{"data":{"uri":"https://github.com/informalsystems/itf-rs"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"itf-rs","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":").","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Got my AI buddies to help me build a custom visualizer.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"ordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"As I iterated, I realized I was missing some critical information, like ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"certificate patterns","nodeType":"text"},{"data":{},"marks":[],"value":" and ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"certified links","nodeType":"text"},{"data":{},"marks":[],"value":". So, I enhanced my model to track these edges and visualize them alongside the DAG. This turned out to be a game-changer, especially during the testing phase.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"7psGvpGMKCnMNEejN61Kg6","type":"Asset","createdAt":"2025-03-19T14:05:43.728Z","updatedAt":"2025-03-19T14:05:43.728Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":3,"revision":1,"locale":"en-US"},"fields":{"title":"image3","description":"","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/7psGvpGMKCnMNEejN61Kg6/45df1ab2e8b15cf34524f6d99a486f70/image3.png","details":{"size":318876,"image":{"width":1999,"height":1111}},"fileName":"image3.png","contentType":"image/png"}}}},"content":[],"nodeType":"embedded-asset-block"},{"data":{},"content":[{"data":{},"marks":[],"value":"\n","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Testing: Validating Against the Paper","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"I was still lacking some ground. Ok, I wrote my definitions, not sure if I understood things correctly - how can I know if my specification is the same as what the paper describes?","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Luckily for me, Appendix A of the paper included a detailed description of a concrete execution. This is exactly what I like using Quint for, as understanding specific executions is a super important step to understand algorithms. So I wrote a ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"Quint","nodeType":"text"},{"data":{},"marks":[],"value":" run that:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Took the DAG from the paper’s example as input.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Executed my function step-by-step.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Compared the results at each step with the paper’s description.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"ordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"As I was collecting additional data, I could also compare how the result was obtained - either through ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"direct decision","nodeType":"text"},{"data":{},"marks":[],"value":" or ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"indirect decision","nodeType":"text"},{"data":{},"marks":[],"value":", and which block was used as the ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"anchor","nodeType":"text"},{"data":{},"marks":[],"value":" in indirect decisions.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"1xarEWbi92EpnGretql7iw","type":"Asset","createdAt":"2025-03-19T14:07:08.023Z","updatedAt":"2025-03-19T14:07:08.023Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":3,"revision":1,"locale":"en-US"},"fields":{"title":"image4","description":"","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/1xarEWbi92EpnGretql7iw/ba794641d268286b7f1776cf474aee71/image4.png","details":{"size":111370,"image":{"width":1148,"height":539}},"fileName":"image4.png","contentType":"image/png"}}}},"content":[],"nodeType":"embedded-asset-block"},{"data":{},"content":[{"data":{},"marks":[],"value":"This test didn’t pass initially, and debugging was tricky. But with the help of my visualizer, I could compare my DAG with the paper’s diagrams and identify where I’d gone wrong. Iterating with the visualizer was not only effective but also incredibly satisfying. It transformed a frustrating process into an engaging one, and this part of the process is what taught me the most. Quint's ability to generate traces for visualization was essential to this iterative learning process – a consistent benefit I've found when using Quint to understand distributed algorithms (see ","nodeType":"text"},{"data":{"uri":"https://x.com/bugarela/status/1899063950781612516"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"this","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" for another example).","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Checking a property in the test","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"While I could validate my model against the paper’s example, I wanted to go further. The most important property of the Mysticeti protocol is the ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"total order property","nodeType":"text"},{"data":{},"marks":[],"value":": all correct validators must commit a consistent sequence of proposer blocks. In other words, the committed sequence of one validator should be a prefix of another’s.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"To test this, I:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Added two new blocks to the example DAG non-deterministically.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Calculated the commit order for three scenarios:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"DAG with only the first block.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"DAG with only the second block.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"DAG with both blocks.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Verified that the results of the first two scenarios were prefixes of the third.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"ordered-list"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"4eV9V1fgUKw12TGRA0u1c6","type":"Asset","createdAt":"2025-03-19T14:08:04.630Z","updatedAt":"2025-03-19T14:08:04.630Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":3,"revision":1,"locale":"en-US"},"fields":{"title":"image5","description":"","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/4eV9V1fgUKw12TGRA0u1c6/1480aaf591e96d3fb61dc8ed3170acbc/image5.png","details":{"size":71024,"image":{"width":963,"height":540}},"fileName":"image5.png","contentType":"image/png"}}}},"content":[],"nodeType":"embedded-asset-block"},{"data":{},"content":[{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"This was the first non-determinism introduced to this model, and it was in the form of a ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"property-based test","nodeType":"text"},{"data":{},"marks":[],"value":". I used quint test to fuzz this and it couldn’t find any violation - it seemed like my model was on the right track.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"A State Machine for DAG Evolution","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"Testing on a single example DAG wasn’t enough. I wanted to check the total order property on ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"arbitrary DAGs","nodeType":"text"},{"data":{},"marks":[],"value":", but I didn’t yet understand the rules for creating a valid DAG. This led me to collaborate with my colleague ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"Martin Hutle","nodeType":"text"},{"data":{},"marks":[],"value":", a consensus expert, during Informal’s team retreat in Paris.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Together, we defined a ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"state machine","nodeType":"text"},{"data":{},"marks":[],"value":" called ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"DAG evolution","nodeType":"text"},{"data":{},"marks":[],"value":", which describes how a DAG can grow over time. The model includes:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Some defined number of validators, each with their own local version of the DAG.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Messages between validators that update the DAG.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Byzantine nodes that can send malicious messages (the trickiest part to define).","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"This state machine is reusable, and while we haven’t yet applied it to other DAG-based consensus algorithms, it’s a promising foundation for future work.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Putting it all together","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"With the state machine in place, I could now check the ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"total order property","nodeType":"text"},{"data":{},"marks":[],"value":" across all states. For each state, I evaluated the consensus function for each correct validator’s local DAG and compared the resulting commit orders, ensuring that all commit orders were prefixes of one another.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"3uqXPWvxbUe34Atu0Mu1YP","type":"Asset","createdAt":"2025-03-19T14:08:52.665Z","updatedAt":"2025-03-19T14:08:52.665Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":3,"revision":1,"locale":"en-US"},"fields":{"title":"image2","description":"","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/3uqXPWvxbUe34Atu0Mu1YP/88b00ae07402ec429c0f6a6109a6e209/image2.png","details":{"size":80940,"image":{"width":1351,"height":545}},"fileName":"image2.png","contentType":"image/png"}}}},"content":[],"nodeType":"embedded-asset-block"},{"data":{},"content":[{"data":{},"marks":[],"value":"\n\nI ran a few thousand simulations with both the existing Quint simulator in Typescript and the ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"new Rust simulator ","nodeType":"text"},{"data":{},"marks":[],"value":"(see ","nodeType":"text"},{"data":{"uri":"https://informal.systems/blog/quint-deserves-rust"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Quint Deserves Rust","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":")","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":" ","nodeType":"text"},{"data":{},"marks":[],"value":"- none of them could find violations.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Quint: A Tool for Understanding","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"The biggest takeaway from this journey is that ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"Quint","nodeType":"text"},{"data":{},"marks":[],"value":" is more than a formal specification tool—it’s a ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"tool for understanding","nodeType":"text"},{"data":{},"marks":[],"value":". Its ability to formalize concepts, facilitate interactive exploration, and enhance precision makes it invaluable for tackling complex systems. Whether you’re a researcher, engineer, or just someone curious about how things work, ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"Quint","nodeType":"text"},{"data":{},"marks":[],"value":" can help you uncover the mysteries beneath the surface.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Beyond Papers: The Power of Interactive Artifacts","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"One of ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"Quint","nodeType":"text"},{"data":{},"marks":[],"value":"’s standout features is its ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"interactive nature","nodeType":"text"},{"data":{},"marks":[],"value":". Unlike traditional research papers, which often leave room for ambiguity, ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"Quint","nodeType":"text"},{"data":{},"marks":[],"value":" provides a hands-on, explorable artifact. This is especially valuable for complex protocols, where static descriptions can fall short.\n","nodeType":"text"}],"nodeType":"paragraph"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"5mf90NVNbc12LJvZiBJM37","type":"Asset","createdAt":"2025-03-19T14:09:29.273Z","updatedAt":"2025-03-19T14:09:29.273Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":3,"revision":1,"locale":"en-US"},"fields":{"title":"image1","description":"","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/5mf90NVNbc12LJvZiBJM37/4c4c2fdfd322c7babdb6619a08d11f25/image1.png","details":{"size":976019,"image":{"width":1200,"height":675}},"fileName":"image1.png","contentType":"image/png"}}}},"content":[],"nodeType":"embedded-asset-block"},{"data":{},"content":[{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"“Writing is nature's way of letting you know how sloppy your thinking is.” --Dick Guindon","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"blockquote"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"“If you're thinking without writing, you only think you're thinking. […] Everyone thinks they think. If you don't write down your thoughts, you are fooling yourself.” -- Leslie Lamport","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"blockquote"},{"data":{},"content":[{"data":{},"marks":[],"value":"\nLamport created TLA+ to help people define their algorithms precisely, and we created Quint to make this more accessible and help people get the most value out of these precise descriptions. Writing in Quint forced me to think about Mysticeti much more precisely, and anyone who uses this Quint specification to learn about Mysticeti will have a significant head start.\n","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"All this work is ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"open source","nodeType":"text"},{"data":{},"marks":[],"value":" and available at ","nodeType":"text"},{"data":{"uri":"https://github.com/informalsystems/mysticeti-spec"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Informal’s GitHub","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", including:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Specification of Mysticeti consensus","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Specification of a DAG evolution state machine","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Visualization tool","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Embrace Quint for Your Next Challenge","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"So, if you find yourself grappling with a complex system like the Mysticeti consensus algorithm, and you're seeking a deeper understanding - why not give Quint a shot?\n","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Quint's blend of interactive exploration and unwavering precision could be your key to unlocking clarity and insights that other methods simply can't offer. It takes learning, but it is worth it.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"\nCheck out Quint at ","nodeType":"text"},{"data":{"uri":"http://quint-lang.org"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"quint-lang.org","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"! And if you are looking for a precise specification of your own algorithm or protocol, reach us at ","nodeType":"text"},{"data":{"uri":"mailto:audits@informal.systems"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"audits@informal.systems","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", or find us on our ","nodeType":"text"},{"data":{"uri":"https://informal.systems/security-and-engineering"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"website","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"contentfulURL":"https://app.contentful.com/spaces/p79kctcd7ahy/entries/2C0VlDl8vgYV8s9MPPCdOU"},{"featureImage":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"7h4ZBvLNs8UaWCeDby2r8o","type":"Asset","createdAt":"2024-12-17T13:46:53.225Z","updatedAt":"2025-01-17T21:48:01.058Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":11,"revision":2,"locale":"en-US"},"fields":{"title":"Malachite","description":"","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/7h4ZBvLNs8UaWCeDby2r8o/8840d229ddbade2f5e99434eb5f22a71/Banner_Background_Corners.jpg","details":{"size":362466,"image":{"width":1920,"height":1080}},"fileName":"Banner_Background_Corners.jpg","contentType":"image/jpeg"}}},"date":"2025-03-13","title":"Malachite x Reth: Conclusions from two MVPs","slug":"malachite-x-reth-conclusions-from-two-mvps","categories":["Malachite"],"authors":["Jehan Tremback","Adi Seredinschi"],"keywords":"malachite-reth\nconsensus-performance\nblockchain-mvp\n ethereum-execution\n tendermint-integration\nconsensus-benchmarks\nblockchain-architecture\nevm-stack\nreth-consensus\nperformance-optimization","excerpt":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Performance analysis of single binary vs Engine API integration architectures.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"includeTableOfContents":true,"introduction":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Summary","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"We are very excited to introduce two Malachite x Reth integration MVPs. Each MVP demonstrates interesting tradeoffs in performance & flexibility.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"The first MVP integrates ","nodeType":"text"},{"data":{"uri":"https://reth.rs/"},"content":[{"data":{},"marks":[],"value":"Reth","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" with ","nodeType":"text"},{"data":{"uri":"https://github.com/informalsystems/malachite"},"content":[{"data":{},"marks":[],"value":"Malachite","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" in a single binary. It has a lazy execution model and early experiments show a throughput of 42'000 tps on a local testnet, or equivalently 10 MB/s. We call this MVP ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"malaketh-turbo, ","nodeType":"text"},{"data":{},"marks":[],"value":"with details in the blog below.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"The second MVP is called ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"malaketh-layered","nodeType":"text"},{"data":{},"marks":[],"value":", consisting of two binaries that interface via Engine API: a consensus client based on Malachite, and Reth for execution. We will publish details about this MVP in a separate blog post soon.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"We draw 3 lessons from the explorations with these MVPs:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"(a) Consensus is ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"not","nodeType":"text"},{"data":{},"marks":[],"value":" the bottleneck in Malachite-based EVM stacks.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"(b) Integration of Malachite x Reth into a single process as in the malaketh-turbo MVP is easier to tune for performance, and in the long term, easier to tweak for vertical integration and scalability. This architecture prioritizes performance.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"(c) Integration via the Engine API RPC (using two separate binaries) exhibits better decoupling and reusability. Compared to the single binary MVP, malaketh-layered may have lower performance, but it comes at the benefit of enabling the mixing of execution clients, as well as compatibility and simpler reusability of current developer tooling.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"If you're a builder interested in pushing the performance limits of EVM stacks and want to know more about these MVPs and Malachite Engine, let ","nodeType":"text"},{"data":{"uri":"https://t.me/MalachiteEngine"},"content":[{"data":{},"marks":[],"value":"us know","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" !","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"body":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Background on the two MVPs","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"At Informal, we’ve been exploring how to integrate ","nodeType":"text"},{"data":{"uri":"https://informal.systems/malachite"},"content":[{"data":{},"marks":[],"value":"Malachite","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" -- our cutting-edge consensus engine -- with Reth, one of the leading Ethereum execution clients. Earlier experiments with such an integration ","nodeType":"text"},{"data":{"uri":"https://x.com/AdiSeredinschi/status/1875987621215961283"},"content":[{"data":{},"marks":[],"value":"exist","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", but are very naive. So we wanted to go a step further and build integration MVPs that could be tested with real workload and full networking stack.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We have explored two architectures for integrating Malachite x Reth:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Detailed in this blog post, we describe an in-process integration. Both Reth execution stack and Malachite consensus engine are compiled into a single Rust binary. The resulting architecture is straightforward and very promising in terms of performance. We call this MVP ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"malaketh-turbo.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Detailed in a separate blog post soon, we will describe an integration consisting of two binaries. The execution client (Reth-based) runs separately from the consensus and finalization client (Malachite-based) and are interfacing with one another via the standard Engine API JSON-RPC. We call this MVP ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"malaketh-layered","nodeType":"text"},{"data":{},"marks":[],"value":". Given the layered architecture of this MVP, it facilitates mixing of execution clients, as well as compatibility and simpler reusability of current developer tooling around Eth clients.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"ordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"Both MVPs have single-slot finality design and achieve sub-second blocks without specific optimizations.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{"target":"$4:props:posts:15:body:content:39:data:target"},"content":[],"nodeType":"embedded-asset-block"},{"data":{},"content":[{"data":{},"marks":[],"value":"Design of malaketh-turbo","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"This MVP starts from the observation that both the Malachite and Reth codebases are in Rust, so integration of the two should be natural.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Malachite provides consensus, and so far has been benchmarked at a throughput of 13.5MB/s in a 100 validator network (although improvements far beyond this are under development). The concept is pretty simple. There is a validator set which controls the network. Every block, one of the validators is chosen to act as the proposer. This proposer creates a block and streams it to the rest of the validators in the network. Once a validator receives and reconstructs the block, they follow the Tendermint consensus protocol to vote on their approval of the block and propagate the vote to the other validators and clients. When a client or validator sees that a given block has received votes from at least 2/3s of the validator set, the block is considered final. When a full node with RPC turned on sees that a block has been finalized, it puts the block's transactions into Reth's execution libraries, executing the transactions and updating the application state.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Running the demo","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"\nFirst, generate blocks of transactions and stores them on disk for nodes to propose:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"129Mama6wB1yWIYFFOblVq","type":"Entry","createdAt":"2025-03-14T14:06:02.374Z","updatedAt":"2025-03-14T14:06:02.374Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":2,"revision":1,"contentType":{"sys":{"type":"Link","linkType":"ContentType","id":"codeSnippet"}},"locale":"en-US"},"fields":{"language":"Shell","code":"cargo run --bin utils -- generate"}}},"content":[],"nodeType":"embedded-entry-block"},{"data":{},"content":[{"data":{},"marks":[],"value":"Then clean up any old testnet and start a new one with three nodes, with node 0 executing blocks and acting as an RPC node:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"5Gz1k5Uvisjv3LP1MHDKBT","type":"Entry","createdAt":"2025-03-14T14:06:46.700Z","updatedAt":"2025-03-14T14:07:07.343Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":4,"revision":2,"contentType":{"sys":{"type":"Link","linkType":"ContentType","id":"codeSnippet"}},"locale":"en-US"},"fields":{"language":"Shell","code":"rm -rf ./nodes;\ncargo build --release;\ncargo run --release --bin malaketh-turbo -- testnet --nodes 3 --home nodes --runtime multi-threaded:4;\nbash scripts/spawn.bash --nodes 3 --home nodes --rpc-node 0"}}},"content":[],"nodeType":"embedded-entry-block"},{"data":{},"content":[{"data":{},"marks":[],"value":"To view the logs, run:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"sxmUfRBF0IeDHclD8Stuu","type":"Entry","createdAt":"2025-03-14T14:07:23.380Z","updatedAt":"2025-03-14T14:07:23.380Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":2,"revision":1,"contentType":{"sys":{"type":"Link","linkType":"ContentType","id":"codeSnippet"}},"locale":"en-US"},"fields":{"language":"Shell","code":"tail -f nodes/0/logs/node.log"}}},"content":[],"nodeType":"embedded-entry-block"},{"data":{},"content":[{"data":{},"marks":[],"value":"To verify that the blocks are being executed correctly, wait for 11 or 12 blocks to be produced, then run ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"cargo run --bin utils -- verify","nodeType":"text"},{"data":{},"marks":[],"value":". This script will check that balance changes indicate that blocks have been executed properly.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Architecture","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"Malachite provides a relatively easy interface to the consensus protocol using a ","nodeType":"text"},{"data":{"uri":"https://github.com/informalsystems/malachite/blob/main/docs/tutorials/channels.md"},"content":[{"data":{},"marks":[],"value":"channel abstraction with message handlers","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". To integrate Reth’s execution libraries with Malachite, we wrote message handlers for a few main message types. There are other messages as well, but we will omit them here for brevity.\n","nodeType":"text"}],"nodeType":"paragraph"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"51O24fzBHTTXqUJpLHbEvD","type":"Asset","createdAt":"2025-03-12T08:52:08.656Z","updatedAt":"2025-03-12T08:52:08.656Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":5,"revision":1,"locale":"en-US"},"fields":{"title":"meth-single architecture","description":"","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/51O24fzBHTTXqUJpLHbEvD/6b33050dc7335c3205aab42842e89621/architecture.png","details":{"size":53206,"image":{"width":1850,"height":618}},"fileName":"architecture.png","contentType":"image/webp"}}}},"content":[],"nodeType":"embedded-asset-block"},{"data":{},"content":[{"data":{},"marks":[],"value":"While the diagram above depicts separate nodes for the proposer, validator, and full node roles, they are all handled in the same codebase, and it is possible for one node to perform all three roles at once.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"You can see all the message handlers in ","nodeType":"text"},{"data":{"uri":"https://github.com/informalsystems/malaketh-turbo/blob/main/app/src/app.rs"},"content":[{"data":{},"marks":[{"type":"code"}],"value":"app/src/app.rs","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"1. AppMsg::GetValue","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"This relates to proposing blocks. Malachite is literally asking the application to get a value to propose. Traditionally this has been done by reaping from a shared mempool, but many modern high performance blockchains do not get blocks this way, instead relying on 3rd party builders like Ethereum, or direct submission of transactions to the next proposer, like Solana. To keep things simple, the nodes in our example app just read transactions from disk.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"From here, the proposer does two things. First, it sends the block’s hash into the consensus protocol, to get the round started, while simultaneously streaming block parts to all the other validators.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"2. AppMsg::ReceivedProposalPart","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"Malachite sends this message to the application whenever a part of a streamed block is received from the proposer. The application reassembles the parts in order and when the full block has been received, replies to Malachite to let it know it is OK to finalize the block. Malachite then handles execution of the Tendermint consensus protocol and communicates with the other validators to circulate its vote.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"It’s important to note that in the example as currently written, the validators do not execute the block, and so are not validating the correctness of the transactions, but just their order. I would describe this as a “lazy ledger” approach, and has the benefit potential increased throughput and not tying validators to any one block execution implementation.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The lazy ledger approach has the downside of requiring every client to re-run transactions themselves instead of being able to trust the validators about execution results.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"In any case, to switch to a validator execution approach, we would simply need to have validators execute the block in this step after reconstructing it.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"3. AppMsg::Decided","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"Malachite sends this message to tell the application that a block has been finalized because more than 2/3 of validators have voted for it.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"At this step, most of the Reth integration comes into play. By importing Reth’s internal libraries, we were able to create a BlockExecutor which runs transactions in the block through the EVM to produce a final application state, and commits that application state to a database. The RPC server is then able to serve queries against that state to clients.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Performance","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"This demo achieves a throughput of 10MB/s second by finalizing one 10MB block per second. The blocks contain 42,000 send transactions. The Reth libraries in the client node are able to handle execution of these transactions quite quickly, but if we were using normal EVM traffic with contract calls, the client might fall behind consensus.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"These numbers are from a local network run with 3 validators on a Macbook. However, given that Malachite has been benchmarked in a ","nodeType":"text"},{"data":{"uri":"https://informal.systems/blog/malachite-decentralize-whatever"},"content":[{"data":{},"marks":[],"value":"large distributed network at 13.5MB per second","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", it is likely that this demo's speed would hold up in that scenario as well.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Concluding thoughts","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"This malaketh-turbo MVP show a very interesting potential architecture amenable in case optimizations for performance and scalability are important for an EVM-based chain. Check the source code on Github here: ","nodeType":"text"},{"data":{"uri":"https://github.com/informalsystems/malaketh-turbo/"},"content":[{"data":{},"marks":[],"value":"https://github.com/informalsystems/malaketh-turbo/","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". The next MVP, malaketh-layered, will be the subject of a blog post soon.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"If you're a builder interested in pushing the performance limits of EVM stacks and want to know more about these MVPs and Malachite Engine, let ","nodeType":"text"},{"data":{"uri":"https://t.me/MalachiteEngine"},"content":[{"data":{},"marks":[],"value":"us know","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" !","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"contentfulURL":"https://app.contentful.com/spaces/p79kctcd7ahy/entries/2rWfN0z7cAbhx8vb71pwie"},{"featureImage":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"6Z2ZQ0fjWpQohQ55f4xbBg","type":"Asset","createdAt":"2024-08-16T06:26:01.721Z","updatedAt":"2024-08-16T06:26:01.721Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":3,"revision":1,"locale":"en-US"},"fields":{"title":"Blog Interchain","description":"","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/6Z2ZQ0fjWpQohQ55f4xbBg/032a287ecc191206f560dc82e94f6dca/Blog_Interchain.jpg","details":{"size":251430,"image":{"width":1920,"height":1080}},"fileName":"Blog_Interchain.jpg","contentType":"image/jpeg"}}},"date":"2025-03-05","title":"Case Study: Formalizing Grug’s Jellyfish Merkle Tree with Quint","slug":"jellyfish-merkle-tree-quint-2025","categories":["Quint","Audits"],"authors":["Aleksandar Ignjatijevic","Gabriela Moreira","Josef Widder"],"keywords":"Quint\nFormal Verification\nCase Study\nMerkle Tree\nLeft Curve\nGrug\nSpecification Language\nModel Checking\nBlockchain Security","excerpt":{"nodeType":"document","data":{},"content":[{"nodeType":"paragraph","data":{},"content":[{"nodeType":"text","value":"Case study on using Quint to formally specify and verify Left Curve's Jellyfish Merkle Tree implementation.","marks":[],"data":{}}]}]},"includeTableOfContents":true,"introduction":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"In Q4 2024, Informal Systems partnered with ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"Left Curve","nodeType":"text"},{"data":{},"marks":[],"value":" to formally specify their Rust implementation of the ","nodeType":"text"},{"data":{"uri":"https://github.com/informalsystems/left-curve/tree/grug-jellyfish-spec/grug/jellyfish-merkle"},"content":[{"data":{},"marks":[{"type":"underline"},{"type":"bold"}],"value":"Jellyfish Merkle Tree","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[{"type":"bold"}],"value":" (JMT)","nodeType":"text"},{"data":{},"marks":[],"value":" using ","nodeType":"text"},{"data":{"uri":"https://quint-lang.org/"},"content":[{"data":{},"marks":[{"type":"underline"},{"type":"bold"}],"value":"Quint","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", our in-house specification language. The JMT is a core component of ","nodeType":"text"},{"data":{"uri":"https://grug.build"},"content":[{"data":{},"marks":[{"type":"underline"},{"type":"bold"}],"value":"Grug","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", Left Curve’s novel blockchain execution environment.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Verifying the correctness of such a complex algorithm is no small feat. Bugs can lurk undetected even after extensive testing, potentially leading to catastrophic failures. That’s where ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"Quint, our in-house specification language,","nodeType":"text"},{"data":{},"marks":[],"value":" came in. By enabling automated simulations across a vast range of scenarios, we not only specified the algorithm but also uncovered a subtle bug in the tree formation. Left Curve fixed the issue, and we validated the fix using Quint.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"You can explore the complete Quint specification and documentation in ","nodeType":"text"},{"data":{"uri":"https://github.com/left-curve/left-curve"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Left Curve’s GitHub repository","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"body":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Why Formal Specification Matters","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"In blockchain systems, trust is everything. But how can you trust an algorithm you don’t fully understand? And how do you even begin to understand distributed systems, protocols and data structures?","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Formal specification bridges this gap. It makes complex protocols easier to grasp and provides a foundation for rigorous verification. An English specification alone isn’t enough—it explains ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"what","nodeType":"text"},{"data":{},"marks":[],"value":" the protocol does, but typically doesn’t show ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"how reliably","nodeType":"text"},{"data":{},"marks":[],"value":" it does it. That’s where ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"executable specifications","nodeType":"text"},{"data":{},"marks":[],"value":" shine. They allow for automated checks at scale, uncovering hidden flaws that regular testing might miss.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"For Left Curve, this was critical. The JMT is central to Grug’s ability to reach consensus over a distributed state machine. Inspired by Diem’s Jellyfish Merkle Tree, adapted to Left Curve’s unique use cases. However, given the algorithm’s critical role in ensuring data integrity, even a small bug could have significant consequences for the system’s reliability and security.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The Quint Approach: Specification, Simulation, and Verification","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"Our collaboration with Left Curve followed a three-step process.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"1. Specification","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"The goal was to create a Quint model faithful to the Rust implementation, including all its algorithmic optimizations. The JMT applies batches of operations (inserts and deletes) on a binary tree, recursing from root to leaves while updating the tree in place.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"The Algorithm’s Complexity\n","nodeType":"text"},{"data":{},"marks":[],"value":"The JMT algorithm is designed to apply a batch of operations on a tree in an optimal way. It does so by recursing over the tree from root to leaves, splitting the batch into operations relevant to each subtree. Between recursive calls, the algorithm updates the mutable tree, introducing two computation flows in the same functions:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Recursion Flow","nodeType":"text"},{"data":{},"marks":[],"value":": Resolves operations from leaves to the root.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Mutation Flow","nodeType":"text"},{"data":{},"marks":[],"value":": Updates the tree from root to leaves.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"ordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"This dual flow is the main source of complexity. Modeling it in Quint was challenging because Quint doesn’t natively support recursion. However, this exercise forced us to deeply understand the implementation’s behavior, including edge cases that might have been overlooked - including one that caused a bug.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We also specified ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"proof generation","nodeType":"text"},{"data":{},"marks":[],"value":" (Grug’s own algorithm) and ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"proof verification","nodeType":"text"},{"data":{},"marks":[],"value":" (from ","nodeType":"text"},{"data":{"uri":"https://ibc.cosmos.network/main/ibc/light-clients/proofs/"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"ICS23","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"). This allowed us to check properties like completeness and soundness for both membership and non-membership proofs.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"2. Twin-Testing","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"To ensure our model was correct, we took a ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"twin-testing approach","nodeType":"text"},{"data":{},"marks":[],"value":". We created two versions of the specification:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Simple","nodeType":"text"},{"data":{},"marks":[],"value":": A straightforward algorithm that rebuilds the tree from scratch after each operation.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Fancy","nodeType":"text"},{"data":{},"marks":[],"value":": A faithful reproduction of the optimized Rust implementation.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"The “simple” version served as a reference model, while the “fancy” version included all the optimizations. We ran tens of thousands of simulations, comparing the results of consecutive applications using both versions to ensure they behaved identically.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Here’s how the twin-testing worked:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"code"}],"value":"val reference = simple::apply(tree, version - 1, version, ops)","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"code"}],"value":"val result = fancy::apply(tree, version - 1, version, ops)","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"code"}],"value":"assert(reference == result)","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Where ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"ops","nodeType":"text"},{"data":{},"marks":[],"value":" is a list of randomly generated tree operations, and ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"tree","nodeType":"text"},{"data":{},"marks":[],"value":" and ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"version","nodeType":"text"},{"data":{},"marks":[],"value":" are cumulative results from applying these operations.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"This approach gave us confidence that the optimizations weren’t introducing errors, and that our modeling of the algorithm was correct.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"3. Simulations and Verification","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"With the model validated, we turned to simulations and verification to obtain confidence about the algorithm’s correctness. We defined ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"17 invariants","nodeType":"text"},{"data":{},"marks":[],"value":"—properties that must hold true for the JMT to function correctly.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Here are some of the most interesting invariants we defined:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"1. Version Consistency","nodeType":"text"},{"data":{},"marks":[],"value":":","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"italic"}],"value":"Versions of predecessors in the path should be >= node version.","nodeType":"text"},{"data":{},"marks":[],"value":"\nWhen nodes are updated (inserted or deleted), they are assigned a new version, as are all their predecessors in the tree. Subtrees untouched by an update retain their version. This means that, in a properly maintained tree, a parent node’s version should always be greater than or equal to its child’s version.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"2. Internal Node Validity","nodeType":"text"},{"data":{},"marks":[],"value":":","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"italic"}],"value":"Internal nodes have at least one child.","nodeType":"text"},{"data":{},"marks":[],"value":"\nIf an internal node has no children, it’s effectively a leaf with no value, which violates the tree’s structure.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"3. Orphaned Nodes","nodeType":"text"},{"data":{},"marks":[],"value":":","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"italic"}],"value":"Orphans should not appear in trees after they are orphaned.","nodeType":"text"},{"data":{},"marks":[],"value":"\nOrphaned nodes are used for state pruning. The intuition is that orphaned nodes can be safely pruned because they’re no longer needed for tree operations (including proof construction or verification) after they’re orphaned. This invariant makes it explicit why it is safe to prune orphans.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"4. Completeness and Soundness of Proofs","nodeType":"text"},{"data":{},"marks":[],"value":":","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"\nWe also defined invariants for the completeness and soundness of both membership and non-membership proofs. A deeper dive into completeness and soundness invariants can be found on ","nodeType":"text"},{"data":{"uri":"https://github.com/left-curve/left-curve/blob/main/grug/jellyfish-merkle/spec/docs/invariants.md#completeness-and-soundness"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Left Curve’s GitHub repository","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"5. Simulation Methodology:\n","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"To validate these invariants, we used two tools:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Quint Simulator","nodeType":"text"},{"data":{},"marks":[],"value":": Runs a Depth-First Search (DFS) on the state space, exploring many samples up to a specified depth (--max-steps).","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"TLC Model Checker","nodeType":"text"},{"data":{},"marks":[],"value":": Runs a Breadth-First Search (BFS) on the ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"complete state space","nodeType":"text"},{"data":{},"marks":[],"value":", requiring a refined model to keep the state space manageable.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"We ran millions of simulations, iterating over the model and invariants to spot issues as soon as they appeared. After iteration, final checks were run for a total of ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"66 hours","nodeType":"text"},{"data":{},"marks":[],"value":" using 6 parallel instances. Checking a total of samples of:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"1.8 million samples","nodeType":"text"},{"data":{},"marks":[],"value":" for invariants related to tree manipulation","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"2.3 million samples","nodeType":"text"},{"data":{},"marks":[],"value":" for proof-related invariants","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"On top of that, we managed to ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"formally verify","nodeType":"text"},{"data":{},"marks":[],"value":" those properties in two different scenarios of reduced scope, by leveraging the Quint to TLA+ transpilation and running the TLC model checker.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"This massively increased our confidence in the model’s correctness. Quint’s simulations were a game-changer, as we would never have been able to write so many interesting scenarios by ourselves, and we could have missed the one that resulted in a bug.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Uncovered Bug","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"During simulations, Quint found a scenario that violated several invariants, including the mentioned version consistency and internal node validity. When we looked at the scenario produced by Quint, we observed that in this run a leaf node was saved in two locations (bit 0 and bit 010). ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"To confirm the bug was not a modeling mistake, we reproduced the test in Rust—and the bug persisted. Left Curve promptly fixed the issue 💜, and we updated the Quint specification to reflect the corrected behavior. After the fix, no further invariant violations were found.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Lessons Learned","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"This project highlighted great benefits of Quint modeling and simulations for complex systems (and auditing them):","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Deep Understanding","nodeType":"text"},{"data":{},"marks":[],"value":": Writing a formal specification forced us to deeply understand the algorithm’s behavior, including edge cases that might have been overlooked.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Scalable Testing","nodeType":"text"},{"data":{},"marks":[],"value":": Quint’s simulations allowed us to test millions of scenarios, far beyond what regular testing could achieve.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Properties Find Bugs","nodeType":"text"},{"data":{},"marks":[],"value":": Defining and checking properties is an effective way to find bugs, as we don’t have to come up with corner cases ourselves.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"ordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"Conclusion","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"Formal methods like Quint are transforming how we build and verify blockchain systems. By specifying and simulating the Jellyfish Merkle Tree, we checked its correctness and robustness, helping Left Curve push the boundaries of blockchain scalability.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"If you’re working on a project that demands the highest level of confidence, let’s talk. Reach out to us at ","nodeType":"text"},{"data":{"uri":"mailto:audits@informal.systems"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"audits@informal.systems","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", or find us on our ","nodeType":"text"},{"data":{"uri":"https://informal.systems/security-and-engineering"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"website","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"If you would like to try out Quint yourself, check out the rich set of examples and tutorials on the ","nodeType":"text"},{"data":{"uri":"https://quint-lang.org/"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Quint website","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". Come to us with any questions, we are happy to help.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Now, it’s time to ship. 🚀","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"References","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"","nodeType":"text"},{"data":{"uri":"https://grug.build/whitepaper.html"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Grug Whitepaper","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"","nodeType":"text"},{"data":{"uri":"https://developers.diem.com/docs/technical-papers/jellyfish-merkle-tree-paper/"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Diem’s Jellyfish Merkle Tree","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"","nodeType":"text"},{"data":{"uri":"https://ibc.cosmos.network/main/ibc/light-clients/proofs/"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"IBC Proofs","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"ordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"contentfulURL":"https://app.contentful.com/spaces/p79kctcd7ahy/entries/2sgx5rarkxsCbYdmv8djsl"},{"featureImage":"$4:props:posts:0:featureImage","date":"2025-03-03","title":"Go Supply Chain Attack Impact Investigation","slug":"go-supply-chain-attack-2025","categories":["Audits"],"authors":["Arianne Flemming "],"keywords":"blockchain audit\nblockchain security audit\nblockchain technology in auditing\ncrypto audit companies\naudit and blockchain\naudit crypto\naudit for crypto\naudit in crypto\naudit of blockchain\nauditing blockchain technology\nauditors crypto\nblockchain and audit\nblockchain audit companies\nblockchain audit firm\nblockchain audit services\nblockchain for auditing\nblockchain in audit\nblockchain technology auditing\ncrypto auditing\ncrypto security audit\nsecurity audit crypto\nsecurity audit for blockchain","excerpt":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"How we investigated the boltdb-go supply chain attack and assessed impact across Cosmos partner projects.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"includeTableOfContents":false,"body":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Go Supply Chain Attack: How We Investigated Its Impact on Developers","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"A few weeks ago, a critical Go vulnerability surfaced—a malicious package, ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"boltdb-go","nodeType":"text"},{"data":{},"marks":[],"value":", was found impersonating the legitimate ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"boltdb","nodeType":"text"},{"data":{},"marks":[],"value":" in a Go mirror site. This backdoored package went undetected for three years before security researchers uncovered it. You can read more about the details in ","nodeType":"text"},{"data":{"uri":"https://arstechnica.com/security/2025/02/backdoored-package-in-go-mirror-site-went-unnoticed-for-3-years/"},"content":[{"data":{},"marks":[],"value":"Ars Technica's report","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"As a security auditing team at Informal Systems, this raised an important question: How many developers might have unknowingly pulled in this compromised package?","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We immediately conducted a review across all of our Cosmos partner projects to assess any exposure. Our investigation confirmed that none of our partners were impacted— relying on a legitimate fork of the library, ","nodeType":"text"},{"data":{"uri":"https://github.com/etcd-io/bbolt"},"content":[{"data":{},"marks":[],"value":"bbolt","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", which is imported as a dependency through the Cosmos SDK.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Why This Matters","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"Supply chain attacks like this highlight the risks of third-party dependencies in open-source ecosystems. Malicious actors continue to find ways to exploit trust in widely used libraries, and detection isn't always immediate. A package sitting undetected for three years is a stark reminder of how deep these threats can go.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Stay Secure with Informal Security","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"If you're building in any blockchain or open-source ecosystem and want to proactively assess your dependencies, secure your codebase, or get a security audit, we can help. Work with a team that stays ahead of threats and ensures your project is resilient.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"","nodeType":"text"},{"data":{"uri":"https://tally.so/r/nrEk4X"},"content":[{"data":{},"marks":[],"value":"📩 ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"Contact Us","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[{"type":"bold"}],"value":" to discuss how we can help secure your project.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"contentfulURL":"https://app.contentful.com/spaces/p79kctcd7ahy/entries/7Ir7npLblDl4RbaqT4nc47"},{"date":"2025-02-25","title":" Informal Systems' Rust Development Journey","slug":"informal-systems-rust-history","categories":["Audits","Malachite","Engineering"],"authors":["Arianne Flemming"],"keywords":"rust lang\ntla + \ndistributed systems \nblockchain audit \nblockchain security audit \n\nRust, Malachite, Hermes, IBC, Quint, Distributed Systems, Consensus Engine, Programming Language, Security, Performance","excerpt":{"nodeType":"document","data":{},"content":[{"nodeType":"paragraph","data":{},"content":[{"nodeType":"text","value":"How Informal Systems uses Rust across Hermes, Malachite, and Quint for secure distributed systems development.","marks":[],"data":{}}]}]},"includeTableOfContents":true,"introduction":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"A History Rooted in Security and Correctness","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"From its inception, Informal Systems has been dedicated to advancing the security, correctness, and verifiability of distributed systems. Our early work focused on formal verification, particularly within the Cosmos ecosystem, where we set out to formally specify and implement critical protocols in Rust. This commitment to Rust was driven by its ability to offer memory safety, performance, and reliability—essential qualities for building robust and trustworthy distributed systems.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Before Informal officially spun out from the Interchain Foundation in 2020, our team had already begun developing key components of Cosmos in Rust. This work provided not only an additional implementation of core components but also strengthened the ecosystem by fostering a growing Rust developer community. We recognized the language’s potential to deliver the guarantees needed to support the next generation of blockchain and distributed computing technologies.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"body":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Hermes & IBC-rs","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"Informal has also been at the forefront of improving interoperability in decentralized networks through our Rust-based implementations of IBC since our founding.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Hermes: A Rust-Based IBC Relayer","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"Hermes is an open-source Rust implementation of a relayer for the IBC protocol. It is widely used in production by relayer operators, offering powerful logging and debugging options. Based on usage and performance, it is the state of the art IBC relayer. As a critical piece of infrastructure in the Cosmos ecosystem, Hermes helps ensure reliable and secure cross-chain communication.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"IBC-RS: A Flexible Rust Library for IBC","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"In addition to Hermes, we developed ibc-rs, a Rust library that implements the IBC protocol. Designed to be consensus-independent, ibc-rs allows developers to integrate IBC with various blockchain platforms—whether it's CometBFT, Near, or even Solana. See ","nodeType":"text"},{"data":{"uri":"https://github.com/informalsystems/ibc-rs?tab=readme-ov-file#ibc-rs-in-the-wild"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"here","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" for a list of apps and app-chains using ibc-rs.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Malachite: Breaking New Grounds in Flexible Consensus with Rust","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"Today, our dedication to Rust is exemplified in Malachite, our newly open-sourced, high-performance BFT consensus engine. Malachite fills a critical gap in the market by providing a flexible, reusable distributed systems foundation that prioritizes correctness and efficiency. Built in Rust from the ground up, Malachite implements the Tendermint consensus algorithm in a minimalistic and modular way, ensuring that it remains highly adaptable to diverse decentralized applications.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Malachite has already demonstrated impressive performance metrics, achieving an average finalization latency of 780 ms with 100 validators handling 1MB blocks. Its ability to finalize up to 13.5 MB/s—equating to approximately 50,000 transactions per second—positions it as a leading consensus engine for high-throughput applications. Projects such as Starknet’s decentralized sequencer and Farcaster’s Snapchain have chosen Malachite as their consensus foundation. Read more about the performance and principles behind Malachite ","nodeType":"text"},{"data":{"uri":"https://informal.systems/blog/malachite-decentralize-whatever"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"here","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"One of Malachite’s key differentiators is its strict separation of concerns. The core consensus library—comprising the Vote Keeper, Round State Machine, and Driver—is a pure state machine, making it highly modular and portable. This architectural choice was informed by our prior experience maintaining CometBFT (Tendermint in Go), where we encountered significant challenges related to code complexity and long-term maintainability. By implementing Malachite in Rust, we not only improved security and reliability but also made it easier for developers to build on top of a clean and well-structured consensus library. Read more ","nodeType":"text"},{"data":{"uri":"https://informal.systems/blog/the-most-flexible-consensus-api-in-the-world"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"here","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Formal Methods and the Rust Rewrite of Quint","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"$24","nodeType":"text"},{"data":{},"marks":[],"value":" rewrite ","nodeType":"text"},{"data":{"uri":"https://informal.systems/blog/quint-deserves-rust"},"content":[{"data":{},"marks":[],"value":"here","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Looking Ahead","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"At Informal Systems, our commitment extends beyond just Rust as a programming language—it is about ensuring the security, correctness, and reliability of the entire distributed systems ecosystem. We are dedicated to helping teams build verifiable, robust, and high-performance decentralized applications. As we continue advancing Malachite, refining Quint, and collaborating with industry leaders, we remain focused on delivering best-in-class solutions for the most demanding applications.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"If you are a project building in Rust and want to partner with us to secure and verify your systems, get in touch at ","nodeType":"text"},{"data":{"uri":"mailto:hello@informal.systems"},"content":[{"data":{},"marks":[{"type":"underline"},{"type":"bold"}],"value":"hello@informal.systems","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". We are excited to work together to build a more secure and decentralized future.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"For more info, check out:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Malachite on GitHub:","nodeType":"text"},{"data":{"uri":"https://github.com/informalsystems/malachite"},"content":[{"data":{},"marks":[],"value":" ","nodeType":"text"},{"data":{},"marks":[{"type":"underline"}],"value":"https://github.com/informalsystems/malachite","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Join the Malachite Telegram channel:","nodeType":"text"},{"data":{"uri":"https://t.me/MalachiteEngine"},"content":[{"data":{},"marks":[],"value":" ","nodeType":"text"},{"data":{},"marks":[{"type":"underline"}],"value":"https://t.me/MalachiteEngine","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Follow ","nodeType":"text"},{"data":{"uri":"https://x.com/bugarela"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"@bugarela","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" on X for sneak peaks on the development of Quint in Rust","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"contentfulURL":"https://app.contentful.com/spaces/p79kctcd7ahy/entries/4Cn1TEhpzZ8rZTYMfKircn"},{"featureImage":"$4:props:posts:16:featureImage","date":"2025-02-18","title":"Quint Deserves Rust","slug":"quint-deserves-rust","categories":["Audits","Quint"],"authors":["Gabriela Moreira"],"keywords":"programming language rustlang tla+ tla syntax abci++\n\nQuint, Rust, Performance, Simulator, Formal Verification, Specification Language, Model Checking, Protocol Testing, Software Development","excerpt":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Why we're rewriting Quint's simulator in Rust for improved performance and more comprehensive testing.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"includeTableOfContents":true,"introduction":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"We're excited to announce that we've embarked on a new project: developing a Quint simulator in Rust! This decision comes in response to community feedback and our ongoing commitment to improving Quint's performance and scalability. We are hitting bottlenecks from having the simulator in Typescript and are ready to move on to the next level with this core performance-sensitive component of Quint.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"body":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Why Rust?","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"Our current Quint simulator, written in Typescript, has served us well. Although performance has never been a primary concern (over user experience and extensibility), we can now see how much the simulator speed impacts our day-to-day job and the main Quint goal of ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"giving us confidence","nodeType":"text"},{"data":{},"marks":[],"value":". The more we use the Quint simulator, the more apparent it becomes that faster simulation speeds would allow us to run ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"more simulations","nodeType":"text"},{"data":{},"marks":[],"value":" in the same amount of time. ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"More simulations means more confidence","nodeType":"text"},{"data":{},"marks":[],"value":" because we get to explore a larger number of different traces and potential ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"edge cases","nodeType":"text"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We have plenty of in-house expertise in Rust and have built amazing Rust products (see ","nodeType":"text"},{"data":{"uri":"https://github.com/informalsystems/hermes"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Hermes","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" and ","nodeType":"text"},{"data":{"uri":"https://github.com/informalsystems/malachite"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Malachite","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"). And - in case you haven’t heard - Rust is the best language out there for performance-sensitive apps. This is the main motivation for choosing Rust. As language designers ourselves, we also recognize and heavily appreciate the expressiveness of the language and enthusiastic community of Rust, which ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"align perfectly","nodeType":"text"},{"data":{},"marks":[],"value":" with our goals for Quint.\n","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Good News for Us","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"Before starting this project, we conducted a preliminary research to answer the question: what is the most performant way to write an interpreter in Rust? We ran benchmarks for ","nodeType":"text"},{"data":{"uri":"https://github.com/romac/qnt-interpreter"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"five different approaches","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" and the winner was an approach using a form of partial evaluation of the program into native Rust ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"closures","nodeType":"text"},{"data":{},"marks":[],"value":". And that was ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"really really cool","nodeType":"text"},{"data":{},"marks":[],"value":", since the current implementation in Typescript uses the same approach! We really were hitting a bottleneck in Typescript and had already optimized the code a lot. This means we can re-implement the simulator in Rust using the ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"same approach","nodeType":"text"},{"data":{},"marks":[],"value":", making this rewrite much more ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"efficient ","nodeType":"text"},{"data":{},"marks":[],"value":"and","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":" predictable","nodeType":"text"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We also found a Cloudflare article, \"","nodeType":"text"},{"data":{"uri":"https://blog.cloudflare.com/building-fast-interpreters-in-rust/"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Building fast interpreters in Rust","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":",\" which explored various options and ultimately chose an approach with ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"dynamic dispatch and closures","nodeType":"text"},{"data":{},"marks":[],"value":". This approach aligned with ours and reinforced our confidence in our chosen direction.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Objectives","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"We won’t rewrite all of Quint in Rust, ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"at least not now","nodeType":"text"},{"data":{},"marks":[],"value":". Many parts of Quint are not sensitive to performance, especially since Quint projects will never have thousands of files - it is a specification language where we tackle parts of a system at a time. It doesn’t really matter if the parser or the typechecker are sub-optimal: the ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"bottleneck","nodeType":"text"},{"data":{},"marks":[],"value":" will always be the ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"simulator","nodeType":"text"},{"data":{},"marks":[],"value":", which we want to use to run ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"as many simulations as possible","nodeType":"text"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Therefore, we'll only rewrite the simulator. Quint tooling already interacts with Apalache, which is written in Scala, by exchanging JSON through an RPC connection. The Rust simulator can use that very ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"same JSON format","nodeType":"text"},{"data":{},"marks":[],"value":" as input and output. We don’t want to add any complexity to Quint users - it will be all set up automatically like it is done for the Apalache integration. ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"They will just notice it is faster","nodeType":"text"},{"data":{},"marks":[],"value":" 😎.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We also want to move eagerly for ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"benchmarks","nodeType":"text"},{"data":{},"marks":[],"value":". Even though we strongly believe that the performance benefits will be worth our time spent in this rewrite, we want to have that information as soon as possible. We will prioritize work paths that will result in us knowing whether it is worth continuing.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Anticipated Benefits","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"These are the reasons why we are so excited:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Improved Performance","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"Rust’s amazing memory management lets us ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"control","nodeType":"text"},{"data":{},"marks":[],"value":" how memory gets copied and allocated, which we couldn’t in Typescript. For example, our current implementation in Typescript defines interfaces to act as pointers as a workaround for that lack of control where it is absolutely necessary (to avoid running out of memory when simulating millions of samples). We won’t have that problem in Rust, where we can choose when to pass around and mutate data ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"by reference","nodeType":"text"},{"data":{},"marks":[],"value":" or","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":" by value","nodeType":"text"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"On top of eliminating this ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"bottleneck","nodeType":"text"},{"data":{},"marks":[],"value":" of memory management imposed by Typescript, Rust itself is ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"already faster","nodeType":"text"},{"data":{},"marks":[],"value":" - we expect that a ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"direct rewrite","nodeType":"text"},{"data":{},"marks":[],"value":" will already make the performance better, while unlocking more optimizations we can do in the future.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"More Maintainable Code","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"I probably don’t need to dive into how amazingly expressive Rust is in this post, so I’ll just mention ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"pattern matching","nodeType":"text"},{"data":{},"marks":[],"value":", ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"traits ","nodeType":"text"},{"data":{},"marks":[],"value":"and the ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"question mark operator","nodeType":"text"},{"data":{},"marks":[],"value":". We are already leveraging those so much in the first lines of code, resulting in a code that is much easier to read and maintain. Future us (Quint maintainers) will be grateful.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"5BdVPux92bI1caOslHPsRt","type":"Asset","createdAt":"2025-02-14T19:32:08.382Z","updatedAt":"2025-02-14T19:32:08.382Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":4,"revision":1,"locale":"en-US"},"fields":{"title":"Quint Blog ","description":"","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/5BdVPux92bI1caOslHPsRt/b057f8c96f38276e2db7727ab8fad586/image.png","details":{"size":142678,"image":{"width":1512,"height":936}},"fileName":"image.png","contentType":"image/png"}}}},"content":[],"nodeType":"embedded-asset-block"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"\nExpanded Community","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"One of our initial motivations to write Quint in Typescript was to maximize the number of people who could collaborate on the project or extend it. We wanted people to feel empowered to dive into the code, and Typescript was (and still is) a very popular language, and a language that people wouldn’t be scared by.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"italic"}],"value":"We didn’t take communities enough into consideration","nodeType":"text"},{"data":{},"marks":[],"value":". So far, we haven’t found a lot of natural overlap between the Typescript community and the (potential) ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"community of Quint","nodeType":"text"},{"data":{},"marks":[],"value":" (protocol designers, compiler engineers, formal methods learners/users, security auditors, ...). Rust’s community, however, has a bigger intersection. By embracing Rust, we hope to engage with a broader community of developers and researchers interested in formal specification and verification.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Project Milestones","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"We have started this work in 2025 and things are moving quickly. Here are the milestones we have planned","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"[DONE] Deserialization:","nodeType":"text"},{"data":{},"marks":[],"value":" Parse the Quint IR (Intermediate Representation) JSON in Rust.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Done! Thank you serde.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"[DONE] Evaluation for built-ins:","nodeType":"text"},{"data":{},"marks":[],"value":" Write translation into closures for all the stateless built-in operators. Benchmark.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"With lots of help from AI code assistants for the boring parts of a direct rewrite (including a big suite of unit tests we imported from the Typescript implementation), this was done in a couple of weeks! ","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"The hardest part was to figure out the lifetimes of some closures, especially for the interpretation of Quint lambda expressions, which re-use the same memory space for different evaluations.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Benchmarks at this point are not very reliable, but we’ve seen some great numbers in preliminary experiments 👀","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Statefulness:","nodeType":"text"},{"data":{},"marks":[],"value":" Store state and modify it with steps and assignments. Benchmark.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Nondeterminism:","nodeType":"text"},{"data":{},"marks":[],"value":" Implement the oneOf operator for different values (which includes a bunch of optimizations - we won’t enumerate big complicated sets just to pick a single value out of it). Benchmark.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Simulation: ","nodeType":"text"},{"data":{},"marks":[],"value":"“For N in number of samples, for S in number of steps, run init then step (S times), checking invariants and witnesses at every state”. Benchmark a lot.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"At this point, we have all the benchmarks we need, and everything from here is just polishing. We plan on starting to use this internally already at this point, wiring things together manually while the integrations are not complete.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Simulator integration:","nodeType":"text"},{"data":{},"marks":[],"value":" Call the Rust simulator from the Typescript CLI.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Evaluator integration:","nodeType":"text"},{"data":{},"marks":[],"value":" Evaluate REPL expressions and definitions through the Rust evaluator.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Support for multiple modules and constants:","nodeType":"text"},{"data":{},"marks":[],"value":" Handle the manipulation of namespaces and constants required for multiple modules.\n","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Stay Tuned!","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"This is a very exciting project for us and will continue to share updates as we progress. We believe that a Rust-based Quint simulator will be a valuable addition to the Quint ecosystem and are eager to see the benefits it will bring. Follow ","nodeType":"text"},{"data":{"uri":"https://x.com/bugarela"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"@bugarela","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" on X for sneak peaks!","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"contentfulURL":"https://app.contentful.com/spaces/p79kctcd7ahy/entries/6vS2CIapyABrSRq8sa60F2"},{"date":"2025-02-03","title":"Expanding Horizons: Looking Into 2025","slug":"expanding-horizons-looking-into-2025","categories":["Company"],"authors":["Arianne Flemming","Ethan Buchman","Zarko Milosevic"],"keywords":"Company Strategy, 2025 Roadmap, Partnership, Investment, Incubation, Blockchain Infrastructure, Cross-ecosystem, Business Development, Protocol Design","excerpt":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Informal Systems' 2025 strategy focuses on three pillars: Partner, Invest, and Incubate across ecosystems.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"includeTableOfContents":true,"introduction":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"At Informal Systems, our mission has always been to foster trust in software and money. Over the years, we have been recognized for our contributions to the Cosmos ecosystem, pioneering advancements in interoperability, security, and decentralized infrastructure. However, given the recent changes in the Cosmos ecosystem, with ","nodeType":"text"},{"data":{"uri":"https://informal.systems/blog/skip-to-reunite-the-cosmos-hub-and-stack"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Skip reuniting the Cosmos Hub and Stack","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", our focus is broadening beyond Cosmos.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The world of distributed systems, blockchains, and protocols is evolving rapidly, and so are we. In 2025, Informal is redefining its role as a premier partner in protocol design and cross-chain infrastructure. This shift reflects our commitment to advancing the entire blockchain ecosystem, not just within Cosmos, but across Bitcoin, Ethereum, and emerging networks. Our strategy is rooted in three pillars: ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"Partner","nodeType":"text"},{"data":{},"marks":[],"value":", ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"Invest","nodeType":"text"},{"data":{},"marks":[],"value":", and ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"Incubate","nodeType":"text"},{"data":{},"marks":[],"value":". Here’s how we’re bringing this vision to life in 2025 and beyond.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"body":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Partner: Building Trust Through Collaboration","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"The core of our work continues to be focusing on building decentralized systems that are resilient, scalable, and trustworthy. We do this by partnering with teams across diverse ecosystems. We help teams improve their security, trustworthiness, and operations from the bottom up, from designing fault-tolerant networks to optimizing protocol architectures. Our recent collaborations with projects like Starknet, Babylon, Berachain, and Farcaster highlight our ability to provide support from inception to launch.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We also leverage our expertise in formal verification and adversarial testing to help teams like Celestia, Anoma, DYDX, and Union improve their security. By applying rigorous standards, we ensure protocols can withstand real-world challenges. We are further automating and enhancing our security offering by leveraging tools that enhance security analysis and automate critical aspects of security testing, further strengthening the trustworthiness of decentralized systems.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Finally, as trusted validators and early contributors, we play an important role in supporting emerging networks like Espresso, Namada and Lombard from their earliest stages. Beyond signing blocks, our services include relayers, dashboards, and white-label offerings, ensuring robust and secure decentralized infrastructure.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Invest: Catalyzing Early-Stage Teams","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"This year Informal is also doubling down on early-stage investments. By strategically deploying capital and expertise, we support teams working on transformative ideas that align with our mission. Our venture activities focus on projects pushing the boundaries of decentralized systems. Recent investments include teams like Plaza, Babylon and Espresso.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Incubate: Nurturing the Next Gen ","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"One of Informal’s most exciting avenues is our internal incubator where we identify and develop promising ideas that can be spun out into independent ventures.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Cycles:","nodeType":"text"},{"data":{},"marks":[],"value":" Our flagship project, an open clearing protocol, aims to redefine payments and credit across the interchain.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Hydro:","nodeType":"text"},{"data":{},"marks":[],"value":" A liquidity provisioning protocol rooted in Cosmos but with potential far beyond.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Quint:","nodeType":"text"},{"data":{},"marks":[],"value":" An executable specification language designed to streamline development of distributed systems.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Malachite: ","nodeType":"text"},{"data":{},"marks":[],"value":"The world’s most flexible BFT consensus engine.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"Informal’s incubated projects emerge directly from the work we do every day, inspired by our expertise and mission-driven approach, transcending individual ecosystems. These are big-picture, ambitious ideas designed to solve foundational challenges and unlock the full potential of decentralized systems.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Looking Ahead","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"2025 is shaping up to be a transformative year for Informal Systems. Our strategy—to ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"Partner","nodeType":"text"},{"data":{},"marks":[],"value":", ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"Invest","nodeType":"text"},{"data":{},"marks":[],"value":", and ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"Incubate","nodeType":"text"},{"data":{},"marks":[],"value":"—reflects our belief that the future of blockchain lies in cross-ecosystem collaboration. By leveraging our expertise in protocol design, security, and distributed systems, we’re excited to contribute to building the secure foundational infrastructure of tomorrow.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Join us on this journey! Whether you’re looking for a partner, exploring investment opportunities, or interested in collaborating on groundbreaking projects, we’re here to help. Together, we can create the systems people can truly depend on.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Want to partner with Informal? Email us at hello@informal.systems. Looking to join our team? Check out our careers page for open roles: ","nodeType":"text"},{"data":{"uri":"https://informal.systems/careers"},"content":[{"data":{},"marks":[],"value":"https://informal.systems/careers","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"contentfulURL":"https://app.contentful.com/spaces/p79kctcd7ahy/entries/72iaNtCEBh2AU778gIOLpQ"},{"featureImage":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"4GsIMOPrgoZrYBKjdVix6u","type":"Asset","createdAt":"2024-12-20T13:32:22.547Z","updatedAt":"2025-01-09T10:03:41.174Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":17,"revision":4,"locale":"en-US"},"fields":{"title":"Malachite - flexible banner","description":"","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/4GsIMOPrgoZrYBKjdVix6u/83260ae1fff3ebf643cae4d0f61e7a2f/Malachite_Banners.jpg","details":{"size":26958,"image":{"width":1200,"height":675}},"fileName":"Malachite Banners.jpg","contentType":"image/jpeg"}}},"date":"2025-01-28","title":"The Most Flexible Consensus API in the World","slug":"the-most-flexible-consensus-api-in-the-world","categories":["Malachite"],"authors":["Adi Seredinschi","Romain Ruetschi","Greg Szabo"],"keywords":"BFT consensus, Tendermint, Rust, API, decentralization, Malachite Consensus Engine\n\nMalachite, Consensus API, Flexible Design, Tendermint, Rust, Decentralized Applications, Protocol Development, Blockchain Infrastructure, Software Architecture","excerpt":{"nodeType":"document","data":{},"content":[{"nodeType":"paragraph","data":{},"content":[{"nodeType":"text","value":"Deep dive into Malachite's core consensus API design enabling extreme flexibility for decentralized applications.","marks":[],"data":{}}]}]},"includeTableOfContents":true,"introduction":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Summary:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"We detail the API of the core consensus library in Malachite, which implements Tendermint in Rust.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"The API provides application builders with extreme levels of flexibility and portability.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"It is ","nodeType":"text"},{"data":{"uri":"https://informal.systems/blog/malachite-decentralize-whatever"},"content":[{"data":{},"marks":[],"value":"amenable","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" to building decentralized sequencers, as needed for Starknet L2, or for decentralized social networks, such as Farcaster.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Beside this powerful API, we are exploring higher level primitives. Whether you take decentralized infrastructure seriously, you're advancing the state of modular designs, or dreaming big with your app-chain mission, we would love to speak with you!","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"For technical conversations, please ","nodeType":"text"},{"data":{"uri":"https://github.com/informalsystems/malachite/discussions"},"content":[{"data":{},"marks":[],"value":"open a discussion","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" on GitHub if you have proposals or ideas, and join the ","nodeType":"text"},{"data":{"uri":"https://t.me/MalachiteEngine"},"content":[{"data":{},"marks":[],"value":"Telegram group","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" dedicated to developing with Malachite.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"body":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"},{"type":"italic"}],"value":"What If?","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"},{"type":"italic"}],"value":"If you were to design a consensus engine from scratch, what would it look like?","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"This is the question we asked ourselves in late 2023, upon starting to work on Malachite. We mainly knew we would use the Malachite consensus engine to implement the Starknet L2 decentralized sequencer. But how should it look like? Which team would build the sequencer on top of the engine? What execution model and environment they would use? These were big unknowns. We therefore needed to make the API to the Malachite core consensus libraries extremely supple and lean.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Here we document the answer we arrived at: The API of the core libraries in Malachite consensus engine, which implements Tendermint in Rust. It is the story of the most flexible and general API that exists to date for interfacing with a consensus algorithm.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Objectives","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"We have two goals with publishing this description:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"First, we provide insights into what we believe is the most powerful — i.e., flexible — API design for a “decentralization gadget” or engine such as Malachite.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"This API is very general, lending itself to highest levels of customization possible. The most advanced teams will use this API in their search to build the most specialized application. Some builders, however will find the API too low-level. For instance, CometBFT offers the ABCI interface, a high-level API that is simple and intuitive. ABCI is a ","nodeType":"text"},{"data":{"uri":"https://www.educative.io/courses/grokking-the-api-design-interview/the-narrow-waist-of-the-internet"},"content":[{"data":{},"marks":[],"value":"“thin waist”","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" to the engine for application builders to use. Similarly, Malachite also incorporates various supporting layers that are more thin, high level, and simplified.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Our second objective with this post is to prompt discussions with application builders about the higher-level primitives they envision in Malachite. What should the “ABCI of Malachite” look like? We end the article with providing some pointers to our current explorations into such higher level primitives and invite further discussions.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Malachite core consensus API: Decentralize Whatever","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"The Malachite consensus engine comprises a core library that implements Tendermint in Rust. This library is pure, i.e. it does not perform any input/output nor result in side-effects. The library is also stateless, i.e., it expects the caller to provide any state relevant as input to any call. This is what allows such high levels of portability and enables Malachite to be flexible to deployment in a very wide variety of environment or applications.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"From the perspective of Malachite, the application is called the Host. Since the core of Malachite is a simple library, it needs to be hosted in an actual execution environment, hence the name Host. We use the term Host and application interchangeably.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"High level architecture of the consensus library","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"The Malachite API consists of two sets of interfaces which the Host can use to run the library and build a meaningful application. Each interface is a set of messages. The first interface represents the set of input messages. The second one is the set of output messages. We call the former ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"Inputs","nodeType":"text"},{"data":{},"marks":[],"value":" and the latter ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"Effects","nodeType":"text"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"14cnodqTup1MqsvriwaiRJ","type":"Asset","createdAt":"2025-01-27T08:17:10.205Z","updatedAt":"2025-01-27T08:17:10.205Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":6,"revision":1,"locale":"en-US"},"fields":{"title":"Malachite high-level architecture","description":"Malachite high-level architecture","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/14cnodqTup1MqsvriwaiRJ/e66330cde31fb00a91ec5da41961d1e7/Screenshot_2025-01-27_at_09.15.56.png","details":{"size":242505,"image":{"width":1250,"height":606}},"fileName":"Screenshot 2025-01-27 at 09.15.56.png","contentType":"image/png"}}}},"content":[],"nodeType":"embedded-asset-block"},{"data":{},"content":[{"data":{},"marks":[],"value":"The sketch above shows the design at the highest level of the architecture.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"At this level, the Host application invokes Malachite with a certain Input message, and Malachite yields potentially an Effect to the Host. Readers familiar with either the Actor model or with a REPL will see a similarity in the pattern between the Host and Malachite library. In such interactions, there is a loop which the Host controls the flow (or the ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"supervisor","nodeType":"text"},{"data":{},"marks":[],"value":" in the Actor model; or the ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"human","nodeType":"text"},{"data":{},"marks":[],"value":" in a REPL instance). The loop consists of input/effect (or, equivalently, command/response) so that the Host and library incrementally rely on each other to progress towards a goal.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The current design represents the first iteration on this approach as published with release ","nodeType":"text"},{"data":{"uri":"https://github.com/informalsystems/malachite/tree/v0.0.1"},"content":[{"data":{},"marks":[],"value":"v0.0.1","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". To simplify the management of the Host/Malachite interaction, the library exports a macro ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"process!","nodeType":"text"},{"data":{},"marks":[],"value":" that can be used as follows:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"4naEqKSMMwQUShsZqB9vZk","type":"Entry","createdAt":"2025-01-08T15:56:17.623Z","updatedAt":"2025-01-08T16:05:35.457Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":4,"revision":2,"contentType":{"sys":{"type":"Link","linkType":"ContentType","id":"codeSnippet"}},"locale":"en-US"},"fields":{"language":"Rust","code":"malachite_consensus::process!(\n\tinput: input,\n\tstate: &mut state.consensus,\n\tmetrics: &self.metrics,\n\twith: effect => {\n\t self.handle_effect(myself, &mut state.timers, &mut state.timeouts, effect).await\n\t}\n)"}}},"content":[],"nodeType":"embedded-entry-block"},{"data":{},"content":[{"data":{},"marks":[],"value":"The Host calls ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"process!","nodeType":"text"},{"data":{},"marks":[],"value":" with a certain ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"input","nodeType":"text"},{"data":{},"marks":[],"value":" and implements the ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"handle_effect","nodeType":"text"},{"data":{},"marks":[],"value":" method. We can think of this method as the top-level loop — or controller — of the application. Before we dive into this behavior in the Host, we’ll first describe in more detail the Inputs and Effects.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"What do Inputs and Effects look like?","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"We define the set of all the possible Inputs that the Malachite library supports as an ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"enum","nodeType":"text"},{"data":{},"marks":[],"value":". There are ","nodeType":"text"},{"data":{"uri":"https://github.com/informalsystems/malachite/blob/73da44a1525b6ef24f8d75bbf45753a0be168f5f/code/crates/core-consensus/src/input.rs#L13"},"content":[{"data":{},"marks":[],"value":"several possible inputs","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" and in a slightly simplified way they look like this:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"19YstRrzKRayJwLFp5OEgL","type":"Entry","createdAt":"2025-01-08T16:03:58.539Z","updatedAt":"2025-01-08T16:05:14.696Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":5,"revision":2,"contentType":{"sys":{"type":"Link","linkType":"ContentType","id":"codeSnippet"}},"locale":"en-US"},"fields":{"language":"Rust","code":"pub enum Input\n{\n /// Start a new height with the given validator set\n StartHeight(Ctx::Height, Ctx::ValidatorSet),\n\n /// Process a vote\n Vote(SignedVote),\n\n /// Process a proposal\n Proposal(SignedProposal),\n\n /// Propose a value\n Propose(ValueToPropose),\n\n /// A timeout has elapsed\n TimeoutElapsed(Timeout),\n\n /// Received the full proposed value corresponding to a proposal.\n /// The origin denotes whether the value was received via consensus or Sync.\n ProposedValue(ProposedValue, ValueOrigin),\n\n /// Received a commit certificate from Sync\n CommitCertificate(CommitCertificate),\n\n // ..\n}"}}},"content":[],"nodeType":"embedded-entry-block"},{"data":{},"content":[{"data":{},"marks":[],"value":"It’s probably not straightforward to see that this library implements the Tendermint consensus algorithm in Rust. We have not applied this interface to other consensus algorithms, so it is too early to say how general this part of the API is. Our intuition tells us to follow a (potentially unorthodox) path to generality, however. Instead of designing this API to cater to different underlying implementations (i.e., different consensus engines), we are validating the API against different expectations from the caller, i.e. the Host. If the API satisfies callers with wildly differing assumptions (Starknet L2 decentralized sequencer, Farcaster data backend, CometBFT’s ABCI, Ethereum Reth, a plain KV store) then we validate it as general enough. Put differently, we believe it is the task of the consensus sub-system to mold itself to application requirements, not the other way around. We’ll see how this plays out in practice over the next years of experimentation.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"enum","nodeType":"text"},{"data":{},"marks":[],"value":" that captures the possible variations of an Effect is more verbose than the inputs. ","nodeType":"text"},{"data":{"uri":"https://github.com/informalsystems/malachite/blob/73da44a1525b6ef24f8d75bbf45753a0be168f5f/code/crates/core-consensus/src/effect.rs#L48"},"content":[{"data":{},"marks":[],"value":"Here","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" it is in a slightly simplified way:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"37Ki68MjbpAYBJ1pEPRXCk","type":"Entry","createdAt":"2025-01-08T16:09:26.581Z","updatedAt":"2025-01-08T16:09:26.581Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":5,"revision":1,"contentType":{"sys":{"type":"Link","linkType":"ContentType","id":"codeSnippet"}},"locale":"en-US"},"fields":{"language":"Rust","code":"$25"}}},"content":[],"nodeType":"embedded-entry-block"},{"data":{},"content":[{"data":{},"marks":[],"value":"The ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"resume","nodeType":"text"},{"data":{},"marks":[],"value":" parameter in each variant is context that encapsulates a response that the library expects from the host towards progressing to reach consensus on a value. In most cases, the library expects no response, i.e., ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"resume::Continue","nodeType":"text"},{"data":{},"marks":[],"value":"; in this case, there is nothing the library needs. In the case of verification effects, for example, the library expects a certain response from the host. This can be seen with the ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"resume::SignatureValidity","nodeType":"text"},{"data":{},"marks":[],"value":" type.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Here are some variants of Effects that are interesting:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Publish: the library instructs the Host to broadcast to other peers in the network a certain consensus message. The type ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"SignedConsensusMsg","nodeType":"text"},{"data":{},"marks":[],"value":" is also an ","nodeType":"text"},{"data":{"uri":"https://github.com/informalsystems/malachite/blob/73da44a1525b6ef24f8d75bbf45753a0be168f5f/code/crates/core-consensus/src/types.rs#L13"},"content":[{"data":{},"marks":[],"value":"enum of two variants","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", simplified in the code snippet here:","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"7fIoPQ4LR1oINXAn55VA9v","type":"Entry","createdAt":"2025-01-08T16:11:01.135Z","updatedAt":"2025-01-27T08:28:04.114Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":4,"revision":2,"contentType":{"sys":{"type":"Link","linkType":"ContentType","id":"codeSnippet"}},"locale":"en-US"},"fields":{"language":"Rust","code":"/// A signed consensus message, ie. a signed vote or a signed proposal.\npub enum SignedConsensusMsg {\n Vote(SignedVote),\n Proposal(SignedProposal),\n}"}}},"content":[],"nodeType":"embedded-entry-block"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"GetValue: Using this variant, Malachite asks the Host to provide a value to serve as a proposal to the consensus protocol. Put differently, this value is the next block the peers will try to agree on.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"SignProposal: Malachite asks the Host to sign a value to be proposed.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"SignVote: Malachite asks the Host to sign a vote that votes on a value received from another peer.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Decide: With this variant, Malachite communicates to the Host that the network of peers (validators) have finalized a new value — e.g., a block — and therefore the application can process it.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"Regarding the ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"SignProposal","nodeType":"text"},{"data":{},"marks":[],"value":" variant, something interesting to note is that ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"Ctx::Proposal","nodeType":"text"},{"data":{},"marks":[],"value":" is an associated type. Malachite is unaware of the specific implementation of a Proposal; it only constraints that any implementation satisfies the ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"Ctx::Proposal","nodeType":"text"},{"data":{},"marks":[],"value":" trait. Furthermore, this trait is generic over a type which we call a ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"Context","nodeType":"text"},{"data":{},"marks":[],"value":". The full definition of ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"Ctx::Proposal","nodeType":"text"},{"data":{},"marks":[],"value":" ","nodeType":"text"},{"data":{"uri":"https://github.com/informalsystems/malachite/blob/73da44a1525b6ef24f8d75bbf45753a0be168f5f/code/crates/core-types/src/proposal.rs#L6"},"content":[{"data":{},"marks":[],"value":"trait looks like this","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":":","nodeType":"text"}],"nodeType":"paragraph"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"2a2q4ZZC3FedGQX8kqPCcZ","type":"Entry","createdAt":"2025-01-08T16:11:18.709Z","updatedAt":"2025-01-08T16:11:18.709Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":2,"revision":1,"contentType":{"sys":{"type":"Link","linkType":"ContentType","id":"codeSnippet"}},"locale":"en-US"},"fields":{"language":"Rust","code":"/// Defines the requirements for a proposal type.\npub trait Proposal\nwhere\n Self: Clone + Debug + Eq + Send + Sync + 'static,\n Ctx: Context,\n{\n /// The height for which the proposal is for.\n fn height(&self) -> Ctx::Height;\n\n /// The round for which the proposal is for.\n fn round(&self) -> Round;\n\n /// The value that is proposed.\n fn value(&self) -> &Ctx::Value;\n\n /// The value that is proposed.\n fn take_value(self) -> Ctx::Value;\n\n /// The POL round for which the proposal is for.\n fn pol_round(&self) -> Round;\n\n /// Address of the validator who issued this proposal\n fn validator_address(&self) -> &Ctx::Address;\n}"}}},"content":[],"nodeType":"embedded-entry-block"},{"data":{},"content":[{"data":{},"marks":[],"value":"Proposals are just Blocks","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"The Proposal trait above shows that the core library is unaware of what should the structure of blocks look like. In fact, in the design we tried to avoid the name “block” and instead preferred “value” as it is more generic. Not all applications will want to build blocks. The ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"value","nodeType":"text"},{"data":{},"marks":[],"value":" getter function in this trait returns a reference to a ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"Ctx::Value","nodeType":"text"},{"data":{},"marks":[],"value":", which is also an associated type. The ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"Context","nodeType":"text"},{"data":{},"marks":[],"value":" ","nodeType":"text"},{"data":{"uri":"https://github.com/informalsystems/malachite/blob/73da44a1525b6ef24f8d75bbf45753a0be168f5f/code/crates/core-types/src/context.rs#L9"},"content":[{"data":{},"marks":[],"value":"trait","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" is the one that assembles together all the different associated types into one coherent whole, which the Host instantiates with specific types.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Inputs, Effects, and the Context are the three key types that make up the Malachite consensus library.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Host behavior","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"Back to the top-level loop in the Host: How does the ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"handle_effect","nodeType":"text"},{"data":{},"marks":[],"value":" method look like in practice? This depends on the Host application architecture. Most applications will likely have a control flow construct based on a ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"match","nodeType":"text"},{"data":{},"marks":[],"value":" statement, which orchestrates between the underlying consensus library and higher level sub-systems, eg mempool, execution, signing, timeouts.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Malachite comes bundled with support for building applications built with the Actor model, specifically the ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"ractor","nodeType":"text"},{"data":{},"marks":[],"value":" framework (","nodeType":"text"},{"data":{"uri":"https://docs.rs/ractor/latest/ractor/index.html"},"content":[{"data":{},"marks":[],"value":"docs.rs","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"). For instance, in the snippet below we show a segment of the ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"handle_effect","nodeType":"text"},{"data":{},"marks":[],"value":" method for handling a key function that most decentralized application built on top of Malachite will have: ","nodeType":"text"},{"data":{"uri":"https://github.com/informalsystems/malachite/blob/6a40b6299e1618210d9fa972d656ecb14943bb6d/code/crates/engine/src/consensus.rs#L838"},"content":[{"data":{},"marks":[],"value":"verification of a signature","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"37tzauT0ILherwZokUFTim","type":"Entry","createdAt":"2025-01-08T16:11:38.471Z","updatedAt":"2025-01-08T16:11:38.471Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":2,"revision":1,"contentType":{"sys":{"type":"Link","linkType":"ContentType","id":"codeSnippet"}},"locale":"en-US"},"fields":{"language":"Rust","code":"Effect::VerifySignature(msg, pk, r) => {\n use malachitebft_core_consensus::ConsensusMsg as Msg;\n\n let start = Instant::now();\n\n let valid = match msg.message {\n Msg::Vote(v) => {\n self.ctx\n .signing_provider()\n .verify_signed_vote(&v, &msg.signature, &pk)\n }\n Msg::Proposal(p) => {\n self.ctx\n .signing_provider()\n .verify_signed_proposal(&p, &msg.signature, &pk)\n }\n };\n\n self.metrics\n .signature_verification_time\n .observe(start.elapsed().as_secs_f64());\n\n Ok(r.resume_with(valid))\n}"}}},"content":[],"nodeType":"embedded-entry-block"},{"data":{},"content":[{"data":{},"marks":[],"value":"The match arm for signature verification includes support for telemetrics, and otherwise it is a dispatch to a ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"verify_signed_*","nodeType":"text"},{"data":{},"marks":[],"value":" method that the Context provides.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Another important effect is handling of ","nodeType":"text"},{"data":{"uri":"https://github.com/informalsystems/malachite/blob/6a40b6299e1618210d9fa972d656ecb14943bb6d/code/crates/engine/src/consensus.rs#L873"},"content":[{"data":{},"marks":[],"value":"publication of a message","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" to other peers in the network.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"6lBZsOxRtx8Avm0sq9Qb78","type":"Entry","createdAt":"2025-01-08T16:12:03.631Z","updatedAt":"2025-01-08T16:12:03.631Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":2,"revision":1,"contentType":{"sys":{"type":"Link","linkType":"ContentType","id":"codeSnippet"}},"locale":"en-US"},"fields":{"language":"Rust","code":"Effect::Publish(msg, r) => {\n // Sync the WAL to disk before we broadcast the message\n // NOTE: The message has already been append to the WAL by the `PersistMessage` effect.\n self.wal_flush(phase).await?;\n\n // Notify any subscribers that we are about to publish a message\n self.tx_event.send(|| Event::Published(msg.clone()));\n\n self.network\n .cast(NetworkMsg::Publish(msg))\n .map_err(|e| eyre!(\"Error when broadcasting gossip message: {e:?}\"))?;\n\n Ok(r.resume_with(()))\n}"}}},"content":[],"nodeType":"embedded-entry-block"},{"data":{},"content":[{"data":{},"marks":[],"value":"The match arm for Publish effect consists simply of delegating the responsibility for broadcast to the network sub-system of the Host. It also includes a call to the write-ahead-log (WAL) to persist any pending state to disk, since the broadcast message may be a Vote. This is because in case the peer crashes after broadcasting, it will need to later avoid broadcasting a different Vote (which would be an instance of equivocation), so it will need to be aware of the present Vote.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Higher-level APIs for Malachite","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"Beside the extremely flexible API described above, there are two more ways to decentralize an application using Malachite. We briefly describe these here.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Channel-based interface","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"The first one is to make us of the high-level channel-based interface to the consensus engine that is provided by the ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"malachite-app-channel","nodeType":"text"},{"data":{},"marks":[],"value":" crate. Using the high-level interface will provide the application with all the features built into Malachite, such as synchronization, crash recovery and networking. The downside is that the application cannot choose a different networking layer or define its own synchronization protocol.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"","nodeType":"text"},{"data":{"uri":"https://github.com/informalsystems/malachite/blob/v0.0.1/docs/tutorials/channels.md"},"content":[{"data":{},"marks":[],"value":"See the corresponding tutorial","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" for a detailed walkthrough of this interface.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Actor-based interface","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"The other way is to make use of the slightly lower level actor-based interface, which allows application developers to switch one actor implementation for another, in order to for instance use a different networking layer than the libp2p-based one. It will then be up to the application to spawn and wire the actors together, which is more complex than using the channel-based interface, but allows for more flexibility.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"There is no tutorial for doing this at the moment. But if you’re brave and curious about this, you can see an application we have built for a prototyping and testing a Starknet sequencer using Malachite in the crate ","nodeType":"text"},{"data":{"uri":"https://github.com/informalsystems/malachite/blob/v0.0.1/code/crates/starknet/app/src/main.rs"},"content":[{"data":{},"marks":[],"value":"starknet-app","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Closing Thoughts","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"Whether it is for channel-based, actor-based, or a different pattern, please join the ","nodeType":"text"},{"data":{"uri":"https://t.me/MalachiteEngine"},"content":[{"data":{},"marks":[],"value":"Telegram dev group","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" to ask any question such as how to swap parts of the engine in and out. You may also consider ","nodeType":"text"},{"data":{"uri":"https://github.com/informalsystems/malachite/discussions"},"content":[{"data":{},"marks":[],"value":"opening a discussion","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" on GitHub.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We are interested to gather opinions and perspective from a broad range of builders. The aim is to discover innovative and impactful primitives to decentralize whatever. Whether you take decentralized infrastructure seriously or dreaming big with the mission of your application, please ","nodeType":"text"},{"data":{"uri":"hello@informal.systems"},"content":[{"data":{},"marks":[],"value":"reach out","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", we would love to speak with more teams!","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"contentfulURL":"https://app.contentful.com/spaces/p79kctcd7ahy/entries/5niGXkfnZUAI9dJ8lOy3kM"},{"featureImage":"$4:props:posts:17:featureImage","date":"2024-12-19","title":"Malachite: Decentralize Whatever","slug":"malachite-decentralize-whatever","categories":["Malachite"],"authors":["Adi Seredinschi"],"keywords":"Tendermint Consensus Algorithm. BFT Consensus in Rust. Starknet. Farcaster Malachite, Consensus Engine, Open Source, BFT, Rust, High Performance, Decentralized Applications, Tendermint, Blockchain Infrastructure","excerpt":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Open-sourcing Malachite, a flexible BFT consensus engine in Rust with high performance and reliability.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"includeTableOfContents":true,"introduction":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Summary:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"We announce the open sourcing of Malachite, ","nodeType":"text"},{"data":{},"marks":[],"value":"a new, flexible, reliable, and high-performance consensus engine in Rust.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Malachite addresses a particular void in the market: The lack of reusable distributed systems foundations, such as BFT consensus libraries, performing at the highest levels.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"It includes a Rust library with a state-of-the-art implementation of Tendermint, an optimistically responsive consensus algorithm.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Malachite addresses numerous points of technical debt in the design of consensus engines, inspired from many years of lessons & experiences in this field. Early experiments show average finalization latency of 780 ms at a scale of 100 validators with 1MB blocks. Depending on setup, Malachite can clear up to 2.5 blocks per second, or can finalize up to 13.5 MB/s, which is ~50,000 transactions per second.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"We are collaborating with Starknet and Farcaster, who are publicly building on Malachite. Thanks to its flexibility, Malachite is amenable to a broad range of environments, with a numbers of other teams building in private. Please reach-out if interested, we would love to speak with more teams.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"We invite contributions in the spirit of open source. Give the ","nodeType":"text"},{"data":{"uri":"https://github.com/informalsystems/malachite "},"content":[{"data":{},"marks":[],"value":"repo","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" a star, and start building with it to decentralize whatever. ","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[],"nodeType":"hr"},{"data":{},"content":[{"data":{},"marks":[],"value":"Today we are thrilled to announce the open-sourcing of ","nodeType":"text"},{"data":{"uri":"https://github.com/informalsystems/malachite"},"content":[{"data":{},"marks":[],"value":"Malachite","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", a flexible consensus engine in Rust with Byzantine fault-tolerant (BFT) guarantees. Malachite includes a state of the art library that implements the Tendermint consensus algorithm, and it represents a flexible building block for decentralizing whatever.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The initial use case driving the design and implementation of Malachite is the Starknet L2 decentralized sequencer. It will serve as the core consensus library in the ","nodeType":"text"},{"data":{"uri":"https://github.com/madara-alliance/madara"},"content":[{"data":{},"marks":[],"value":"Madara","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" and ","nodeType":"text"},{"data":{"uri":"https://github.com/eqlabs/pathfinder"},"content":[{"data":{},"marks":[],"value":"Pathfinder","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" Starknet clients. Malachite is also being used for Farcaster’s newest backend layer called ","nodeType":"text"},{"data":{"uri":"https://github.com/farcasterxyz/snapchain-v0/"},"content":[{"data":{},"marks":[],"value":"Snapchain","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". A numbers of others are building and exploring in private. We have furthermore prototyped example applications with Malachite to test drive it and explore its performance.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"All the above is possible because we designed the core consensus modules in Malachite with the guiding principle of obtaining a flexible and lean library. It enables teams to decentralize layer 1s, data availability networks, social network, sequencers, prover networks, marketplaces of any kind — and whatever the future may bring.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"body":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Why Malachite?","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"Decentralized applications represent some of the most complex software systems in existence. Launching and maintaining such an application is a very difficult task. The “elephant in the room” when it comes to building these applications is the lack of flexible and secure distributed systems foundations.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Our mission at Informal is to fix this. We are accelerating the evolution of decentralized applications towards mature technologies. Malachite is a key part of our plan: It makes it easy for builders to decentralize whatever systems or applications they are launching.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"\"the future is already here, it is just not evenly distributed”\n— William Gibson","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"blockquote"},{"data":{},"content":[{"data":{},"marks":[],"value":"Design","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"The Core Library: Tendermint in Rust","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"As a BFT consensus engine, Malachite comprises one core component: the ","nodeType":"text"},{"data":{"uri":"https://arxiv.org/abs/1807.04938"},"content":[{"data":{},"marks":[],"value":"Tendermint algorithm","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" implemented in Rust. This algorithm is used for driving a network of peers to agreement on a decision without a trusted intermediary, that is, decentralized consensus.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Early on in the design, roughly a year ago, we made the deliberate design choice to separate this core from everything else that we may bundle with the engine. This separation was important for three reasons.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"First, it was a natural way to scope our work for engineering the Starknet decentralized sequencer. Our team focuses on the core library to obtain a state of the art implementation of Tendermint in Rust, while other teams in Starknet ecosystem who are experts in full node development focus on that.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Second, it was a difficult lesson we learned from the experience of maintaining ","nodeType":"text"},{"data":{"uri":"https://cometbft.com"},"content":[{"data":{},"marks":[],"value":"CometBFT","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" (Tendermint in Go) for multiple years. Consensus codebases have to cover numerous corner cases that are difficult to recreate, and that makes the code extremely costly to maintain. So whatever we could decouple, mark as non-essential, cut down, or simplify, was a win. The core of Malachite is, therefore, an exercise in minimalism and comprises three basic modules:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"a Vote Keeper (for aggregating votes from peers and keep track of quorums),","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"a Round State Machine (implementing the Tendermint algorithm logic within a round), and","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"a Driver (which operates the state machine across multiple rounds).","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"ordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"These three modules make up what we call the ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"library","nodeType":"text"},{"data":{},"marks":[],"value":" part of Malachite. The library makes no assumptions about the environment in which it runs or what kind of applications are built with it. It represents the most flexible consensus API in the world to the best of our knowledge.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Three, a clear separation allowed us to formally model the Tendermint protocol in ","nodeType":"text"},{"data":{"uri":"https://quint-lang.org/"},"content":[{"data":{},"marks":[],"value":"Quint","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" and to co-design the implementation with its formal specification and model checking. This led to a more secure implementation and a clearer understanding of the algorithm. See ","nodeType":"text"},{"data":{"uri":"http://quint-lang.org"},"content":[{"data":{},"marks":[],"value":"quint-lang.org","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" to learn more about the Quint language.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The Engine around the Core Library","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"We implemented the core consensus component as a pure state machine and focused initially on its correctness. This ensures the core is a library that anyone can use for implementing application on top of a battle-tested BFT consensus. This was great. But the core is not useful on its own.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"To put the core library to use and validate its design, we also provide supporting layers that make this core library amenable to benchmarking under realistic conditions, and for the building of full fledged nodes for production systems. These additional components allow our team and builders to also experiment with the library, though the modules were primarily focused on meeting the demands of an initial, specific real-world application, the decentralized sequencer for Starknet L2. Additionally, we have also taken into consideration valuable feedback we have received from numerous other teams.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"A high level sketch of the Malachite engine, including both the core library and other components can be seen below.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"3A8wv0nTDNNvyJmxC3YJWe","type":"Asset","createdAt":"2024-12-17T13:50:49.992Z","updatedAt":"2024-12-18T17:55:33.199Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":13,"revision":3,"locale":"en-US"},"fields":{"title":"Malachite Overview","description":"","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/3A8wv0nTDNNvyJmxC3YJWe/53bd87b1ba56634f543a4dc91e8104b9/Screenshot_2024-12-18_at_18.54.56.png","details":{"size":283124,"image":{"width":738,"height":446}},"fileName":"Screenshot 2024-12-18 at 18.54.56.png","contentType":"image/png"}}}},"content":[],"nodeType":"embedded-asset-block"},{"data":{},"content":[{"data":{},"marks":[],"value":"To instantiate the different components together into a coherent application, we chose the actor model. The core consensus algorithm is un-opinionated and supports many other architectures, but this is the one we used to build our first testing and example applications.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"In the actor model there is no shared state among different components, and all modules communicate with a clearly defined API of input and output messages. This was another key takeaway from working with the CometBFT codebase: The actor model promotes better de-coupling and separation, which in turn greatly facilitates performance diagnostics, bottleneck identification, and debugging.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Some Practical Matters","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"Quint, Model-based Testing, and E2E Testing","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"We already mentioned we used Quint to co-design the Rust implementation with its model specification, i.e., a model of the Tendermint algorithm. To further improve our confidence in the code and its stability, we have done an initial round of model-based testing (MBT). By using the specification in Quint, we generated execution traces and used those to perform MBT under a few scenarios on core parts of the library.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We also have end-to-end integration tests, written in a DSL for spawning and controlling nodes. This exercises various features of the library. In terms of overall code coverage there is still room for improvement, and at the moment it stands at around 95% for Driver and State Machine and VoteKeeper; and 80% for the rest. The next couple of months we plan to dedicate to doing MBT on the Driver and the consensus library.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Experiences from Chasing Performance and Stability","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"We prioritized a high-quality architecture and clear separation of concerns to enable easier debugging and performance investigations. It is important to us that applications building on Malachite deliver the highest performance. In our experiments to date, with the prototype Starknet sequencer we have built, Malachite delivers higher throughput and lower latency than CometBFT.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We are currently using libp2p and GossipSub for network transport and gossip capabilities, and it is an open question whether it is worthwhile to bundle a customized p2p layer with Malachite. At the moment, this is not a concern, and initial performance results exceed our expectations.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"To quantify performance and get a sense of practical behavior in the wide-area network, we took a gradual approach to scaling test networks starting with a few nodes. Iterative QA testing weeded out bugs in the implementation until we reached stable results. This iterative process was intense in findings in the first several months. Spring and summer this year in particular were fruitful. A lot of effort was necessary also for parametrizing libp2p/GossipSub correctly.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Once we had a stable network and reproducible metrics, we started adding more nodes to the network and pulled the nodes further apart. First, we ensured the nodes ran stable in a data center and then in two data centers. Finally, we ran 100 nodes worldwide on at least three continents.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We had to consider the network properties among the nodes, like bandwidth, latency, or jitter, and tweak the consensus parameters to overcome limitations. We were able to maintain consensus among the 100 nodes worldwide. Peer catch up was via consensus message buffering and replay. Nodes that slowed down temporarily could catch up, which improved stability. The stricter consensus parameters resulted in improved performance. We now have sync implementation for values (i.e., full decisions finalized by consensus) and votes (i.e., signed messages that nodes exchange to reach consensus on a value), which will allow for shorter timeout parameters and more resilient connections in future experiments.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"In terms of performance, the block finalization latency in the network with 100 validators ranged from 700 ms to 860 ms, with an average of around 780 ms. We used blocks of 1MB. This results in a throughput of approximately 1.3 MB/s, or about 5,128 transactions per second (TPS).","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Below we show four graphs from some of these experiments, demonstrating stability under load.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Experimental results with nodes in the same datacenter. ","nodeType":"text"},{"data":{},"marks":[],"value":"When we deploy nodes in the same data center, the experimental results show consistent output and stable operations across all 100 nodes.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"Dh5anDaEyqB2bugSqOljn","type":"Asset","createdAt":"2024-12-17T13:52:53.952Z","updatedAt":"2024-12-17T13:52:53.952Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":6,"revision":1,"locale":"en-US"},"fields":{"title":"Malachite block production - 1","description":"","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/Dh5anDaEyqB2bugSqOljn/54e8cbc049c5ac8335a838fa0fed3e8d/7__1_.png","details":{"size":66037,"image":{"width":1000,"height":500}},"fileName":"7 (1).png","contentType":"image/png"}}}},"content":[],"nodeType":"embedded-asset-block"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"5004OkWVeJ6KaUtupLZZ1I","type":"Asset","createdAt":"2024-12-17T14:03:30.327Z","updatedAt":"2024-12-17T14:03:30.327Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":5,"revision":1,"locale":"en-US"},"fields":{"title":"Malachite tx production - 1","description":"","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/5004OkWVeJ6KaUtupLZZ1I/eeb6adcc63fab2ca6f6407a937a7990e/3__1_.png","details":{"size":67124,"image":{"width":1000,"height":500}},"fileName":"3 (1).png","contentType":"image/png"}}}},"content":[],"nodeType":"embedded-asset-block"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Experimental results with nodes spread across multiple datacenters. ","nodeType":"text"},{"data":{},"marks":[],"value":"When we deploy nodes that are connected worldwide, we get results with similar characteristics. Delays, jitters, or nodes going offline do not impact stability.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"sDWAOflrZwZbqQdILOMl5","type":"Asset","createdAt":"2024-12-17T14:03:01.813Z","updatedAt":"2024-12-17T14:03:01.813Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":5,"revision":1,"locale":"en-US"},"fields":{"title":"Malachite block production - 2","description":"","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/sDWAOflrZwZbqQdILOMl5/6ff1cd97bbd49966fbc626c597144ae5/7.png","details":{"size":49802,"image":{"width":1000,"height":500}},"fileName":"7.png","contentType":"image/png"}}}},"content":[],"nodeType":"embedded-asset-block"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"7iUNjJrnmBgWwt12FOfmHh","type":"Asset","createdAt":"2024-12-17T14:04:11.385Z","updatedAt":"2024-12-17T14:04:11.385Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":5,"revision":1,"locale":"en-US"},"fields":{"title":"Malachite tx production - 2","description":"","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/7iUNjJrnmBgWwt12FOfmHh/e087c851139992d8595e22df97554aac/3.png","details":{"size":52290,"image":{"width":1000,"height":500}},"fileName":"3.png","contentType":"image/png"}}}},"content":[],"nodeType":"embedded-asset-block"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Experimental results from a smaller deployment. ","nodeType":"text"},{"data":{},"marks":[],"value":"We also experimented with conditions reflective of applications seeking a smaller validator set, specifically using 20 nodes, as with a Proof of Authority (PoA) model. For this network in particular, latency is important. In these experiments, latency of block finalization using Malachite ranged between 330 ms and 490 ms, with an average of 385 ms. This allowed Malachite to order approximately 2.5 blocks per second, resulting in a throughput of 2.5 MB/s. With a transaction size of 256 bytes, this equates to around 10,000 transactions per second (TPS). Note that these values exclude block execution and creation times.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"In this setup we also experimented with larger blocks, 10MB, and 50MB specifically. We found when the block size increased to 10 MB that the latency ranged from 400 ms to 1350 ms, with an average of 745 ms. This results in a throughput of approximately 13.5 MB/s, or around 50,000 transactions per second (TPS). At a block size of 50MB, the latency ranges from 2 to 7.5 seconds, with an average of 4431 ms. This results in a throughput of approximately 11 MB/s, or around 44,000 transactions per second (TPS).","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We plan to chase further “huge blocks” or “ultra low latency” experimentation depending on specific teams that will be building on top of Malachite and their needs. If you have particular requirements for a specialized use case, let us know!","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Roadmap","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"This open-source release is the first step in the broader arc of developing Malachite in a flexible solution for decentralizing various products and services. Over the coming year, we’ll be working towards a general availability release of Malachite.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Towards a General Availability Release","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"We plan to publish a multi-year technical roadmap and key milestones for reaching general availability (v1) stage within the next months. For the moment, we have our eyes on several specific outcomes:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Immediately releasing most of the modules on ","nodeType":"text"},{"data":{"uri":"http://crates.io"},"content":[{"data":{},"marks":[],"value":"crates.io","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" to make them available for teams to build their own Rust applications and integrations with more ease.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Demonstrating decentralization of the Starknet L2 sequencer, by collaborating with core contributors in the Starknet ecosystem to deliver the highest quality BFT consensus library they can integrate for building the sequencer clients.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Continuing to work with the ","nodeType":"text"},{"data":{"uri":"https://www.farcaster.xyz/"},"content":[{"data":{},"marks":[],"value":"Farcaster","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" team on integrating Malachite into Snapchain and ensuring excellent performance and stability for the decentralized social network data layer.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Consolidating QA efforts and deeper performance benchmarks with CometBFT.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Design and publish a comprehensive documentation at ","nodeType":"text"},{"data":{"uri":"https://informal.systems/malachite"},"content":[{"data":{},"marks":[],"value":"https://informal.systems/malachite","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" ","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Aligning on specs and standards across consensus libraries to foster collaboration between Interchain, Starknet, and other ecosystems.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Auditing Malachite to ensure it meets our high security and reliability standards.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Integrating with Reth to demonstrate versatility and flexibility of the core library.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Concluding Thoughts","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"If your team takes web3 innovation & decentralization seriously, let’s talk! Talented teams and ambitious ecosystems such as Farcaster and Starknet are publicly building on Malachite, with a numbers of others building in private. Reach-out if interested, we would love to speak!","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"By open-sourcing Malachite, we’re aiming for a future where application builders don’t have to cut corners, and instead have access to the highest quality foundations for decentralization. We’re excited to see all the use cases that Malachite can transform from centralized operations into a fault-tolerant, decentralized systems.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Let’s decentralize whatever","nodeType":"text"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Telegram channel for developer discussions: ","nodeType":"text"},{"data":{"uri":"https://t.me/MalachiteEngine"},"content":[{"data":{},"marks":[],"value":"https://t.me/MalachiteEngine","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Give the repo a star on Github ","nodeType":"text"},{"data":{"uri":"https://github.com/informalsystems/malachite"},"content":[{"data":{},"marks":[],"value":"https://github.com/informalsystems/malachite","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" !","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"And sign up for the Malachite newsletter at ","nodeType":"text"},{"data":{"uri":"https://mailchi.mp/informal.systems/malachite-newsletter"},"content":[{"data":{},"marks":[],"value":"https://mailchi.mp/informal.systems/malachite-newsletter","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"contentfulURL":"https://app.contentful.com/spaces/p79kctcd7ahy/entries/6Y1kr6bcLKzT4dyLd3rg7t"},{"featureImage":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"1O713dLOUtS3jayLEDbY6U","type":"Asset","createdAt":"2024-08-08T23:59:04.356Z","updatedAt":"2024-08-13T22:16:45.128Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":23,"revision":6,"locale":"en-US"},"fields":{"title":"Blog CometBFT","description":"","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/1O713dLOUtS3jayLEDbY6U/41b6ea8a25be7c12da12c097596de4ce/Blog_CometBFT.jpg","details":{"size":172583,"image":{"width":1920,"height":1080}},"fileName":"Blog_CometBFT.jpg","contentType":"image/jpeg"}}},"date":"2024-12-13","title":"CometBFT DOG Protocol Reduces Mempool Bandwidth by 2.5x","slug":"a-new-mempool-gossip-protocol-for-cometbft","categories":["Engineering"],"authors":["Hernán Vanzetto","Jasmina Malicevic","Sergio Mena"],"keywords":"CometBFT, Mempool, Gossip Protocol, DOG Protocol, Bandwidth Optimization, Byzantine Fault Tolerance, Network Protocol, Performance","excerpt":{"nodeType":"document","data":{},"content":[{"nodeType":"paragraph","data":{},"content":[{"nodeType":"text","value":"Dynamic Optimal Graph gossip protocol cuts transaction redundancy and improves consensus.","marks":[],"data":{}}]}]},"includeTableOfContents":true,"introduction":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"During Q4 of 2024, the CometBFT team at Informal Systems has finalized the work on the Dynamic Optimal Graph (DOG) protocol. First ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/issues/3263"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"announced","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" earlier this year, DOG is a novel gossip protocol that represents a major step forward in transaction dissemination for CometBFT's mempool.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The Dynamic Optimal Graph (DOG) is a novel gossip protocol that represents a major improvement in transaction dissemination for CometBFT's mempool. Currently, mempool traffic comprises numerous duplicate messages, resulting in exponential bandwidth usage. Transaction messages account for nearly half of the total network traffic generated by CometBFT nodes. DOG reduces this bandwidth consumption significantly, with experiments showing a 2.5x reduction in traffic generated, reduction in missed blocks, and improved transaction confirmation latency.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"body":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Overview","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"Currently, in typical CometBFT-based networks, the mempool sub-system generates a large volume of duplicate messages when propagating transactions. DOG reduces this bandwidth consumption significantly, with experiments showing a 2.5x reduction in traffic generated, as illustrated by these metrics:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"5qxsfxOoFMS6pcx0I6CZzg","type":"Asset","createdAt":"2024-12-13T13:50:47.193Z","updatedAt":"2024-12-13T13:56:18.871Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":6,"revision":2,"locale":"en-US"},"fields":{"title":"dog-1","description":"Testnet with 200 nodes and a transaction load of 500 tx/s during 15 minutes. On the left, the current mempool; on the right, with DOG enabled. The yellow line is the volume of transaction messages sent by nodes.","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/5qxsfxOoFMS6pcx0I6CZzg/00a31c4d1cca160f6f7e9db37d20f385/Screenshot_2024-12-13_at_14.49.59.png","details":{"size":224370,"image":{"width":1440,"height":474}},"fileName":"Screenshot 2024-12-13 at 14.49.59.png","contentType":"image/png"}}}},"content":[],"nodeType":"embedded-asset-block"},{"data":{},"content":[{"data":{},"marks":[{"type":"italic"}],"value":"Testnet with 200 nodes and a transaction load of 500 tx/s during 15 minutes. On the left, the current mempool; on the right, with DOG enabled. The yellow line is the volume of transaction messages sent by nodes.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"This substantial improvement is achieved through two key innovations:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"A smart routing mechanism that selectively filters transactions before forwarding them to peers, reducing redundant transactions and improving bandwidth usage without compromising latency. Unlike \"pull\"-based gossip protocols, DOG avoids introducing additional communication steps or delays, thus maintaining (and even improving!) the low latency offered by the current protocol.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"A closed-loop redundancy controller that ensures a minimum level of transaction redundancy, needed for preserving the network's resilience against malicious actors.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"ordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"By optimizing how transactions are forwarded across the network, DOG not only reduces traffic but, as a side-effect, improves the overall system performance, enabling faster consensus and more efficient resource utilization.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"In the following, we’ll dive into the details of how DOG compares to the current protocol, its inner workings, its key properties, and finally some results from our testnet experiments.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Strengths and limitations of the current protocol","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"The current transaction dissemination protocol used in CometBFT's mempool, which we call ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/blob/c451150275612dc4182e4d47f6722f2e49209829/spec/mempool/gossip/flood.md"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Flood","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", has been in use since the early days of the project. Flood is a classic \"push\" gossip protocol. Its mechanism is simple but effective: whenever a node receives and adds a transaction to its mempool, it immediately forwards the transaction to all its peers, except for the peer from which it received the transaction.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Flood excels in two areas. First, it propagates transactions with the minimal possible latency in decentralised P2P networks. Second, by \"flooding\" the network with transaction messages, it ensures resilience against malicious actors attempting to censor or disrupt transaction propagation. However, the simplicity of Flood comes with a significant downside: its broadcast-based approach generates a high degree of redundancy, causing exponential increase in bandwidth consumption.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Dynamic routing","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"At its core, the DOG protocol introduces a routing mechanism that minimizes the propagation of redundant transactions. Like other gossip protocols, DOG nodes exchange messages to confirm whether they have already seen a specific transaction. DOG goes a step further by using this information to dynamically build a routing table at each node.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The key idea of the protocol is the following. Let's assume a network with no Byzantine actors and where each transaction enters the network from a single node (we'll see later how to overcome these limitations). If a node A receives from a peer B a transaction that it has received before, this means that there must exist a cycle in the network topology. Then node A will send a ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"HaveTx ","nodeType":"text"},{"data":{},"marks":[],"value":"message to B to signal that it has this transaction, and B will close one of the \"routes\" that forwards data to `B`, thus cutting the cycle. Over time, this exchange of ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"HaveTx","nodeType":"text"},{"data":{},"marks":[],"value":" messages allows nodes to cut all the routes that cause redundancy. Note that ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"HaveTx","nodeType":"text"},{"data":{},"marks":[],"value":" messages only carry a transaction hash, which makes its size insignificant when compared to full transaction messages.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"When routes stabilize, transactions have a single, optimal path to reach every node. The resulting structure is a superposition of directed spanning trees, which is the ideal topology for efficient data dissemination in peer-to-peer networks. Routes form an implicit overlay of one spanning tree per node. Each node only knows the routes from and to its peers, not relying on routing information of other nodes. Overlay trees are created dynamically and may evolve as the topology of the network changes. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"For example, consider the following network topology with 7 nodes, where only nodes 1 and 7 receive transaction load:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"1tv5nCDE7YTOdWh00dkf94","type":"Asset","createdAt":"2024-12-13T13:58:49.538Z","updatedAt":"2024-12-13T13:58:49.538Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":5,"revision":1,"locale":"en-US"},"fields":{"title":"dog-2","description":"Network topology with 7 nodes, where only nodes 1 and 7 receive transaction load\n","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/1tv5nCDE7YTOdWh00dkf94/fa0f4adee34f048774405456a01f86b9/Screenshot_2024-12-13_at_14.58.20.png","details":{"size":57470,"image":{"width":798,"height":437}},"fileName":"Screenshot 2024-12-13 at 14.58.20.png","contentType":"image/png"}}}},"content":[],"nodeType":"embedded-asset-block"},{"data":{},"content":[{"data":{},"marks":[],"value":"Initially all routes are open, meaning that transactions will be transmitted through those paths. Nodes receiving transactions coming from outside the network forward them to all their peers. As redundant transactions are exchanged, nodes begin to send ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"HaveTx","nodeType":"text"},{"data":{},"marks":[],"value":" messages to signal that certain routes should be closed. Over time, the network converges to an optimized state. Routes marked as red arrows in the diagram represent closed paths.\n","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The result is a superposition of directed spanning trees, where each node has a single, optimal path to reach every other node. For example, transactions entering from node 1 will follow the path 1 → 2 → 4 → 5 → 7, as shown in the spanning tree for node 1 below:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"KxF8j6Zguai2rp9Jxz4XU","type":"Asset","createdAt":"2024-12-13T13:59:52.597Z","updatedAt":"2024-12-13T13:59:52.597Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":6,"revision":1,"locale":"en-US"},"fields":{"title":"dog-3","description":"Transactions entering from node 1 will follow the path 1 → 2 → 4 → 5 → 7\n","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/KxF8j6Zguai2rp9Jxz4XU/48620231fe52988c984566d515e2e904/Screenshot_2024-12-13_at_14.59.22.png","details":{"size":38806,"image":{"width":763,"height":439}},"fileName":"Screenshot 2024-12-13 at 14.59.22.png","contentType":"image/png"}}}},"content":[],"nodeType":"embedded-asset-block"},{"data":{},"content":[{"data":{},"marks":[],"value":"Similarly, transactions originating from node 7 will follow the path 7 → 6 → 4 → 3 → 1, as seen in the spanning tree for node 7:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"2mtgDQy3rrRzu87HhOS2Nn","type":"Asset","createdAt":"2024-12-13T14:00:41.743Z","updatedAt":"2024-12-13T14:01:06.831Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":7,"revision":2,"locale":"en-US"},"fields":{"title":"dog-4","description":"Spanning tree for node 7","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/2mtgDQy3rrRzu87HhOS2Nn/5a44ff30ee0bc0dfb4b60a85c15b7281/Screenshot_2024-12-13_at_15.00.12.png","details":{"size":39368,"image":{"width":818,"height":479}},"fileName":"Screenshot 2024-12-13 at 15.00.12.png","contentType":"image/png"}}}},"content":[],"nodeType":"embedded-asset-block"},{"data":{},"content":[{"data":{},"marks":[],"value":"Byzantine Fault Tolerance","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"\nIn non-Byzantine networks, DOG is able to achieve optimal performance with zero redundant messages. In adversarial environments, as expected, a minimum level of redundancy is necessary to counteract possible attacks and ensure that all transactions reach all nodes.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The DOG protocol implements a Redundancy Controller (effectively a closed-loop mechanism) that periodically measures the level of redundant transactions received and decides whether to request from peers for more or less transactions, thus tuning the redundancy level to a target value.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"For instance, a target redundancy level of 0.5 means that the node accepts one duplicate transaction for two unique transactions received. If the controller detects that redundancy has dropped below this threshold, it sends a ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"ResetRoute","nodeType":"text"},{"data":{},"marks":[],"value":" message to its peers to re-open a previously closed route. This mechanism ensures that all transactions reliably reach their destination, even in the presence of malicious actors or network disruptions, but also to allow nodes to dynamically adapt to changes in the network topology.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Properties","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"The DOG protocol is not limited to the mempool: it is a generic BFT gossip protocol that can be applied to disseminate other types of data as well. We are planning to explore its applicability to other CometBFT messages that consume significant bandwidth, such as block parts or votes.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The protocol implicitly favors faster routes. By cutting routes on peers that send duplicate transactions, which by definition are received at a later time, the protocol naturally optimizes for quicker paths. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Additionally, the protocol preserves the best-effort FIFO ordering for mempool transactions by filtering based on target peers. Even when this ordering is not strictly guaranteed, it is still important for some specific applications, such as IBC, which benefits from a lower rejection rate of IBC packets.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"DOG was designed as an extension to the existing CometBFT mempool. It functions as a node plugin that can be enabled at any time, though the benefits are maximized when all nodes in the network adopt the protocol.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"There are still two minor downsides that we intend to improve in the future:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Convergence time for redundancy: Reaching the optimal routes for the desired levels of transaction redundancy may take each node a time proportional to the number of peers it has, though typically in the order of a few minutes. This should not pose a problem as nodes are expected to run for much longer times.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Traffic fairness: Nodes with high-speed connections and a large number of peers may end up handling higher traffic load compared to other nodes. However, as the network topology evolves dynamically, this imbalance changes over time.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"For more details, check out the protocol ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/blob/c451150275612dc4182e4d47f6722f2e49209829/spec/mempool/gossip/dog.md"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"specification","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". It comes together with a formal spec written in ","nodeType":"text"},{"data":{"uri":"https://quint-lang.org/"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Quint","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", which proved to be invaluable during the design phase of the protocol.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Testnet results","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"We conducted several experiments on our typical 200-nodes testnet with the goal of","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"identifying the optimal default values for the protocol's parameters (","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/issues/4596"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"#4596","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/issues/4597"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"#4597","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/issues/4598"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"#4598","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"), ","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"evaluating the performance in scenarios with nodes having a different number peers (","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/issues/4614"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"#4614","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"), and","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"testing potential vulnerabilities (","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/issues/4606"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"#4606","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"). ","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"In every evaluated scenario, enabling the DOG protocol consistently resulted in improvements across most metrics, with no observed degradation in any area. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Moreover, the reduction in redundant messages has a system-wide positive impact. Continuing with the same experiment from the introduction, we could observe how the whole system operates more efficiently with DOG enabled.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Mempool","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"Mempool size is smaller and the number of cache hits is notably reduced as the routes are being built.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"4CvLISfnuF0fhjiTi0f6Ix","type":"Asset","createdAt":"2024-12-13T14:04:17.680Z","updatedAt":"2024-12-13T14:04:17.680Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":5,"revision":1,"locale":"en-US"},"fields":{"title":"dog-mempool","description":"Mempool size is smaller and the number of cache hits is notably reduced as the routes are being built\n","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/4CvLISfnuF0fhjiTi0f6Ix/76a27dfb2c56c12604c7524c7bddbe33/Screenshot_2024-12-13_at_15.03.52.png","details":{"size":250998,"image":{"width":1434,"height":508}},"fileName":"Screenshot 2024-12-13 at 15.03.52.png","contentType":"image/png"}}}},"content":[],"nodeType":"embedded-asset-block"},{"data":{},"content":[{"data":{},"marks":[],"value":"Consensus","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"We observe:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"More stable block production.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Validators need a second consensus round less often.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"8 times less missing validators during voting.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"About 2.7 times less missed blocks.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"4nxnI29TYcJZfYrgIFpjSv","type":"Asset","createdAt":"2024-12-13T14:05:32.130Z","updatedAt":"2024-12-13T14:05:32.130Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":8,"revision":1,"locale":"en-US"},"fields":{"title":"dog-consensus","description":"Positive side-effects of DOG protocol on consensus (block production)","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/4nxnI29TYcJZfYrgIFpjSv/3a76edf322edeff43a042265c39dac0b/Screenshot_2024-12-13_at_15.04.36.png","details":{"size":401601,"image":{"width":1339,"height":1030}},"fileName":"Screenshot 2024-12-13 at 15.04.36.png","contentType":"image/png"}}}},"content":[],"nodeType":"embedded-asset-block"},{"data":{},"content":[{"data":{},"marks":[],"value":"We also observe:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"More blocks produced and more transactions on chain, as observed after 15 minutes","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"5vCBJPafqBmz3rCnLCXZTk","type":"Asset","createdAt":"2024-12-13T14:06:57.906Z","updatedAt":"2024-12-13T14:06:57.906Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":5,"revision":1,"locale":"en-US"},"fields":{"title":"dog-5","description":"More blocks produced and more transactions on chain, as observed after 15 minutes.","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/5vCBJPafqBmz3rCnLCXZTk/b60fe195fb72614feea544c0f7400044/Screenshot_2024-12-13_at_15.05.59.png","details":{"size":174574,"image":{"width":1438,"height":475}},"fileName":"Screenshot 2024-12-13 at 15.05.59.png","contentType":"image/png"}}}},"content":[],"nodeType":"embedded-asset-block"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"All of the above results in an additional 10% reduction of network traffic generated ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"BlockPart","nodeType":"text"},{"data":{},"marks":[],"value":" messages.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"Resource usage and latency","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"Using DOG can also make nodes more efficient and cost-effective. In terms of resource usage, in these experiments we remarked a 43% lower CPU usage and 10% lower memory usage, as shown in the graph below.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"3dTSACrF6UJxUv0i46Ibtu","type":"Asset","createdAt":"2024-12-13T14:12:02.731Z","updatedAt":"2024-12-13T14:12:02.731Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":5,"revision":1,"locale":"en-US"},"fields":{"title":"dog-6","description":"Resources: 43% lower CPU usage and 10% lower memory usage, making nodes more efficient and cost-effective.\n","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/3dTSACrF6UJxUv0i46Ibtu/a5f3a0ef49075bc00c73fd89c394e5f6/Screenshot_2024-12-13_at_15.07.49.png","details":{"size":155976,"image":{"width":1437,"height":480}},"fileName":"Screenshot 2024-12-13 at 15.07.49.png","contentType":"image/png"}}}},"content":[],"nodeType":"embedded-asset-block"},{"data":{},"content":[{"data":{},"marks":[],"value":"Also in terms of efficiency, there is another side-effect: we notice 10% reduction in total transaction validation time (","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"CheckTx)","nodeType":"text"},{"data":{},"marks":[],"value":", putting less pressure on the application and overall node.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"4p6rYxAk1L7JdCCUoDGpUW","type":"Asset","createdAt":"2024-12-13T14:13:50.372Z","updatedAt":"2024-12-13T14:13:50.372Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":5,"revision":1,"locale":"en-US"},"fields":{"title":"dog-7","description":"Application calls: 10% reduction in total transaction validation time (CheckTx), putting less pressure on the application.","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/4p6rYxAk1L7JdCCUoDGpUW/656466169c34648403ae9273f426c57d/Screenshot_2024-12-13_at_15.12.16.png","details":{"size":122950,"image":{"width":1438,"height":241}},"fileName":"Screenshot 2024-12-13 at 15.12.16.png","contentType":"image/png"}}}},"content":[],"nodeType":"embedded-asset-block"},{"data":{},"content":[{"data":{},"marks":[],"value":"And lastly, one remark on latency. The experiments reveal 15% less transaction latency, as a consequence of the system being less loaded. During this experiment, Flood throughput was 496.9 tx/s on average, and DOG had an almost equal production with 496.6 tx/s. The average latency with Flood was 3.63s, while with DOG it was 3.14s.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Conclusion","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"The DOG protocol is a powerful upgrade for any CometBFT-based network. It is available and ready to be used in CometBFT's ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"main","nodeType":"text"},{"data":{},"marks":[],"value":" branch. The Comet team in Informal Systems fine-tuned this feature to provide:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"An efficient bandwidth usage: its routing mechanism significantly reduces bandwidth in all tested scenarios.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Low Latency: DOG does not introduce delays or extra communication steps that add latency, as other kinds of gossip protocols. Instead, it selectively filters transactions before forwarding them to peers. In our tests, transaction latency is even lower than the current protocol.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Byzantine Fault Tolerance (BFT): DOG keeps a minimum level of transaction redundancy for preserving the resilience needed to mitigate the impact of Byzantine attacks.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Improved system-wide performance: faster consensus and more efficient resource utilization.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"To further improve the latency of transaction propagation, check out ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/blob/c451150275612dc4182e4d47f6722f2e49209829/docs/references/architecture/adr-118-mempool-lanes.md"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Mempool Lanes","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", a new feature we designed for the mempool to offer Quality of Service (QoS) guarantees by allowing applications to prioritize transactions for faster processing and dissemination.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Join us","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"As ","nodeType":"text"},{"data":{"uri":"https://informal.systems/blog/skip-to-reunite-the-cosmos-hub-and-stack"},"content":[{"data":{},"marks":[],"value":"recently announced","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", the Comet team in Informal is stepping down, and Comet maintenance will be transitioned over to the engineering team of Interchain Foundation. Informal Systems has extensive expertise in building and maintaining CometBFT-based networks, however. We therefore remain committed to support builder teams who seek specialized requirements and are building high performance applications. Reach out to us at ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"hello@informal.systems","nodeType":"text"},{"data":{},"marks":[],"value":" and we'd be thrilled to collaborate!","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"contentfulURL":"https://app.contentful.com/spaces/p79kctcd7ahy/entries/57wM6ruvmKANLZC3eYx2vJ"},{"featureImage":"$4:props:posts:0:featureImage","date":"2024-12-11","title":"Model-Based Testing Neutron's Liquidity Pool Migration with Quint","slug":"model-based-testing-to-secure-neutrons-liquidity","categories":["Quint","Audits"],"authors":["Aleksandar Ignjatijevic"," Ivan Gavran"],"keywords":"security \naudit\nresearch\nneutron\nliquidity migration\n\nModel-Based Testing, Quint, Neutron, Liquidity Pool, Migration Testing, Bug Discovery, Formal Verification, Security Testing, DeFi\n","excerpt":{"nodeType":"document","data":{},"content":[{"nodeType":"paragraph","data":{},"content":[{"nodeType":"text","value":"Using Quint for model-based testing to discover critical bugs in Neutron's $23M liquidity pool migration.","marks":[],"data":{}}]}]},"includeTableOfContents":true,"introduction":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"During Q1 2024, Informal Systems audited Neutron’s liquidity pool migration which dealt with ~23 million USD in users’ liquidity, exchanging Astroport’s ","nodeType":"text"},{"data":{"uri":"https://docs.astroport.fi/docs/learn/astro-pools/constant-product-pools"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"XYK","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" liquidity pools for the ","nodeType":"text"},{"data":{"uri":"https://docs.astroport.fi/docs/learn/astro-pools/passive-concentrated-liquidity-pools/passive-concentrated-liquidity-pools-intro"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"PCL","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" pools. Migration edge cases were thoroughly inspected to ensure the highest degree of confidence in the protocol.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We performed model-based testing using ","nodeType":"text"},{"data":{"uri":"https://quint-lang.org/"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Quint","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", our in-house specification language—this enabled us to automatically create tests that explored many different scenarios for the migration protocol.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The scenarios we generated helped us discover critical bugs in the migration process, helping the development team rethink the overall design and implement a more robust solution. We modeled the steps of the migration process and adapted Neutron’s ","nodeType":"text"},{"data":{"uri":"https://github.com/neutron-org/neutron-integration-tests/blob/feat/migrate-to-pcl/src/testcases/run_in_band/tge.auction.test.ts"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"testing suite","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" to execute the scenarios (sequences of steps) generated by Quint. Our model was lightweight and nimble: it only captured certain aspects of the system that our team determined to be the most appropriate. Yet it still proved useful in exploring scenarios that would be impossible to cover with manually written test cases. ","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"body":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Model-Based Testing using Quint","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"Reasoning about large software systems, with all the implementation details, is impossible. This is why security researchers use ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"models ","nodeType":"text"},{"data":{},"marks":[],"value":"— high-level specifications of programs. Once a model has been built, both automated and manual reasoning are easier. On top of that, these models can function as a precise system specification.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Quint is a specification language developed at Informal. Quint comes equipped with a random and symbolic simulator, as well as the model checker, enabling formal verification of models written in Quint. By modeling a software system using Quint, developers can identify potential issues and inconsistencies early in the development process. This proactive approach allows developers to detect design flaws or logical errors even before writing implementation code.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Besides analyzing models, Quint has another important use-case: generating tests from the model that can be run directly against the implementation. Automatically generating tests from the model has two advantages: 1) generated tests will explore scenarios that we as developers would not think of, or would not bother to implement, and 2) any divergence between the implementation and the model will be spotted immediately by a failing test, thus ensuring the specification will always be up to date. This process is called ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"model-based testing","nodeType":"text"},{"data":{},"marks":[],"value":" and is one of the most useful tools in our auditing toolbox.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Quint carries the semantics of ","nodeType":"text"},{"data":{"uri":"https://lamport.azurewebsites.net/tla/high-level-view.html"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"TLA+","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", and therefore is able to make use of many years of research on formal verification tooling for it, while addressing many problems developers face with TLA+ itself. To learn more about applications of Quint, check out how to ","nodeType":"text"},{"data":{"uri":"https://www.youtube.com/watch?v=gUhSK1u7oME&t=134s"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"automate bug finding","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" in CosmWasm contracts, or how to ","nodeType":"text"},{"data":{"uri":"https://youtu.be/OZIX8rs-kOA?si=XWJaD5DJspHjX6jd"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"develop new protocols","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" with the help of Quint.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Neutron’s Liquidity Pool Migration","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"Earlier this year, Neutron DAO passed a proposal to migrate liquidity on ","nodeType":"text"},{"data":{"uri":"https://astroport.fi/en"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Astroport","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", locked during Neutron’s ","nodeType":"text"},{"data":{"uri":"https://docs.neutron.org/neutron/token-generation-event/overview/"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Token Generation Event","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", from the XYK pool to a PCL pool.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"After discussing different approaches, the development team opted for a migration approach that mirrors providing liquidity to the new pool: each locked position would migrate individually, starting from the largest locked position.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Every migration process carries many inherent risks and thus careful planning and rigorous testing is necessary. The Neutron development team aimed to make sure users do not lose value during the migration process and the voting power distribution, derived from the locked assets, is not disturbed. Furthermore, users should obtain their fair share of Astroport rewards — failing to ensure that could damage the reputation of the Neutron chain. Therefore, executing migrations with utmost caution was crucial. With that in mind, the development team created a comprehensive end-to-end testing suite to cover all the aspects of the migration process.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Using Quint for Model-Based Testing on Neutron’s Liquidity Pool Migration ","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"In order to examine the migration implementation, we started by creating a Quint model of the migration specification. Specifically, we focused on modeling paths in the system where users' funds were being handled. That meant modeling these paths:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Claiming rewards from either the XYK or PCL pools","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Withdrawing rewards from one of the pools","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Migrating from one pool to the other","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"ordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"Based on those paths, our modeled contained 5 possible steps, which describe the evolution of the model:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"code"}],"value":"init","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"code"}],"value":"claim_rewards_xyk (w & w/o withdraw)","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"code"}],"value":"migrate","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"code"}],"value":"advance_block","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"code"}],"value":"claim_rewards_pcl (w & w/o withdraw)","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"The ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"advance_block ","nodeType":"text"},{"data":{},"marks":[],"value":"action was performed by the system and, as the name suggests, was used to model the advancing of blocks. This was crucial for earning rewards based on staked assets. Both ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"claim_rewards_*","nodeType":"text"},{"data":{},"marks":[],"value":" actions were executed by users, with or without withdrawing the rewards. If the rewards were withdrawn, they were sent from Astroport’s contract to the user’s address. The ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"migrate","nodeType":"text"},{"data":{},"marks":[],"value":" action is permissionless, meaning that any user can initiate a migration for themselves or others. Since users could have their assets either locked or vested, we decided to differentiate between these two types of assets when performing actions.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"To begin with, the model needs an initial state. We decided to use the usual suspects, ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"Alice, Bob, and Charlie ","nodeType":"text"},{"data":{},"marks":[],"value":"as the users. Each user had either some assets locked or vested, so we modeled the users as a map, mapping the user’s address to the ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"UserData","nodeType":"text"},{"data":{},"marks":[],"value":" structure. The ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"UserData","nodeType":"text"},{"data":{},"marks":[],"value":" structure is shown in the following code snippet, with its associated fields:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"code"}],"value":"type UserData = { \n migrated: bool,\n xyk_liquidity_withdrawn: bool,\n xyk_liquidity_withdrawn_before_migration: bool,\n pcl_liquidity_withdrawn: bool,\n has_xyk_rewards: bool,\n has_pcl_rewards: bool,\n only_vesting: bool\n }","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"code"}],"value":"migration field","nodeType":"text"},{"data":{},"marks":[],"value":" showcased if the migration was performed for that particular user. ","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"code"}],"value":"xyk_liquidity_withdrawn ","nodeType":"text"},{"data":{},"marks":[],"value":"field captures whether the XYK liquidity no longer exists, either due to withdrawal or migration.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"code"}],"value":"pcl_liquidity_withdrawn","nodeType":"text"},{"data":{},"marks":[],"value":" captures whether the PCL liquidity no longer exists, meaning that after the migration, the user has decided to claim the rewards and withdraw the liquidity.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"code"}],"value":"xyk_liquidity_withdrawn_before_migration","nodeType":"text"},{"data":{},"marks":[],"value":" field shows if the user withdrew liquidity before the migration happened.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Fields ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"has_xyk_rewards and has_pcl_rewards","nodeType":"text"},{"data":{},"marks":[],"value":" indicate whether the user has earned some rewards. These fields correspond to the advance_block action, as enough blocks passing will result in rewards to claim.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"code"}],"value":"only_vesting","nodeType":"text"},{"data":{},"marks":[],"value":" field signifies that the user has only vested assets, meaning no rewards will be available to claim.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"To use the Quint model effectively, we had to adapt the existing test suite. The first step was bringing it to the model-defined initial state. We generalized the testing suite to accommodate our defined set of users, set their initial locked or vested asset amounts, and advance the blocks to allow them to earn some rewards. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We decided to explore the scenarios defined by the following two predicates:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"code"}],"value":"fullMigrationHappened","nodeType":"text"},{"data":{},"marks":[],"value":",and","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"code"}],"value":"allPCLLiquidityWithdrawn","nodeType":"text"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"The first predicate tells Quint to generate a large (parameter-defined) number of different scenarios in which all funds from the XYK pool are withdrawn and transferred to the PCL pool. Similarly, the second predicate is used to request scenarios in which all funds that were migrated to PCL pools are subsequently withdrawn. Quint’s simulator explores the state space to give us different scenarios that satisfy our predicate.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Quint generates traces in a JSON-like format called ","nodeType":"text"},{"data":{"uri":"https://apalache.informal.systems/docs/adr/015adr-trace.html"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"ITF","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". Each ITF trace represents a sequence of actions, called ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"steps","nodeType":"text"},{"data":{},"marks":[],"value":". After performing all the steps, the relevant predicate is satisfied (e.g., ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"allPCLLiquidityWithdrawn","nodeType":"text"},{"data":{},"marks":[],"value":").","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"To utilize the traces, we had to load them into the testing suite and parse them according to the previously defined test structures. This required developing some glue code: it loads and parses the traces and then executes the function in the testing suite corresponding to the step defined in the trace. Now we had steps of the testing suite reliably mimicking the steps in the Quint model.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We checked for correctness by adding postconditions for the executed actions. Based on the trace, we implemented checks to confirm that the model was in sync with the tested implementation, and straight away we noticed that some of the traces were failing. This prompted us to dig further, and together with the Neutron’s development team, we discovered hidden bugs in the system. (We note here that using steps’ postconditions is a deviation from the standard model-based conformance testing approach: typically, we would compare the model-predicted state with the system’s state. Using postconditions, however, enabled us to work effectively with a much lighter model.\n\n","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"initializeState()\nfor step in ITF_trace.steps {\n match step:\n \"claim_rewards_xyk\" -> {\n claimRewardsXyk();\n checkClaimRewardsXykPostcondition();\n },\n \"advance_block\" -> {\n advanceBlock();\n checkAdvanceBlockPostcondition();\n },\n \"claim_rewards_pcl\" -> { \n claimRewardsPCL(); \n checkClaimRewardsPCLPostcondition();\n },\n \"migrate\" -> {\n migrate();\n checkMigratePostcondition();\n },\n ...\n}\n","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Model-Based Testing Results","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"In this section, let us examine in a step-by-step manner the process of uncovering one particular bug in the system. This is the most technical part of the post, but bear with us: at the end of it, you will have a pretty good idea of the full bug-discovery process.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The (stripped) test scenario included all three actors and consisted of three actions: ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"Bob migrates Alice, Charlie migrates Bob, ","nodeType":"text"},{"data":{},"marks":[],"value":"and","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":" Alice claims rewards with withdrawal from PCL pool. ","nodeType":"text"},{"data":{},"marks":[],"value":"Implicit in that description is that some time passes between the actions.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"To understand the problem with this scenario, let us outline the behavior we expected from the system. After Alice’s position was migrated from the XYK pool to the PCL pool, a certain amount of time passed before Bob’s position was migrated to the same pool. During that time, Alice should have earned her PCL rewards.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Assume that initially, when Alice was migrated, there was 0 pending rewards for the contract interacting with the PCL pool. After some time has passed, our model says, the contract should have some pending rewards (and they belong to Alice). ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Then, it was Bob’s turn to migrate. We let some more time pass after Bob was migrated, and now some more pending rewards were being generated. The next step showed that one of the key migration properties was broken - after claiming her rewards, Alice got a smaller portion of the rewards than what the model expected, and the test failed. (Indeed, she and Bob got the same amount of rewards.)","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"italic"}],"value":"Why did that happen? ","nodeType":"text"},{"data":{},"marks":[],"value":"Well, the basic idea in calculating the amount of rewards belonging to each lockup position was as follows: every time there is a claim from the pool, a parameter crucial for future calculations, ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"incentives_rewards_per_share, ","nodeType":"text"},{"data":{},"marks":[],"value":"is increased by the fraction of ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"received_amount","nodeType":"text"},{"data":{},"marks":[],"value":" over the ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"total_lp_balance_deposited","nodeType":"text"},{"data":{},"marks":[],"value":". These parameters represent the received amount of tokens and the total balance of deposited ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"LP","nodeType":"text"},{"data":{},"marks":[],"value":" tokens. This operation ensures that each lockup that existed between two claims gets ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"assigned","nodeType":"text"},{"data":{},"marks":[],"value":" its share of rewards.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"It turned out that there was a catch. Each time new liquidity is provided to the pool, the pool also implicitly sends pending rewards to the ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"lockdrop","nodeType":"text"},{"data":{},"marks":[],"value":" contract that works with the PCL pool. However, in that case (unlike when explicitly claiming rewards), the parameter ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"incentives_rewards_per_share ","nodeType":"text"},{"data":{},"marks":[],"value":"did not get updated. Thus, all the rewards corresponding to the time when Alice’s funds were in the PCL pool, but Bob had not yet been migrated, were not assigned to Alice. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"If you would like to see the fix to the described bug, check out Neutron’s ","nodeType":"text"},{"data":{"uri":"https://github.com/neutron-org/neutron-tge-contracts/pull/85"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"PR#85","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Conclusion","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"Our industry leading team of technical experts used Quint to uncover critical vulnerabilities in this protocol. In our experience, manual code review is useful. However, uncovering the really tricky, difficult to find bugs requires a more thorough approach, including tools like Quint. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Are you wondering if your project may benefit from model-based testing or protocol analysis? If you would like to work with us to see how Quint can be used to help your project reach the highest level of confidence possible please get in touch with us at ","nodeType":"text"},{"data":{"uri":"mailto:audits@informal.systems"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"audits@informal.systems","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"If you would like to try out Quint yourself, check out the rich set of examples and tutorials on the ","nodeType":"text"},{"data":{"uri":"https://quint-lang.org/"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Quint website","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". ","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"contentfulURL":"https://app.contentful.com/spaces/p79kctcd7ahy/entries/6RLSdEEeHARh3acCgsbBO9"},{"featureImage":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"2i4b4P42Y7uzQCx00FuN4d","type":"Asset","createdAt":"2024-08-14T02:39:21.666Z","updatedAt":"2024-08-14T02:49:48.184Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":7,"revision":2,"locale":"en-US"},"fields":{"title":"Blog Informal","description":"","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/2i4b4P42Y7uzQCx00FuN4d/92f9b27c37dc9ab3da02aaf44739cabc/Blog_Informal.jpg","details":{"size":233656,"image":{"width":1920,"height":1080}},"fileName":"Blog_Informal.jpg","contentType":"image/jpeg"}}},"date":"2024-12-10","title":"Skip to Reunite the Cosmos Hub and Stack","slug":"skip-to-reunite-the-cosmos-hub-and-stack","categories":["Company"],"authors":["Informal Systems"],"keywords":"cosmos cosmos hub Skip, Cosmos Hub, Ecosystem Transition, Partnership, Blockchain Governance, Interchain, Strategic Partnership, Company Update, Leadership","excerpt":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Supporting Skip's unified leadership role for Cosmos Hub while Informal transitions to broader ecosystem focus.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"includeTableOfContents":false,"body":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"We’re thrilled to support Skip as they step into a unified leadership role for the Cosmos Hub and align the interchain ecosystem portfolio of products to support and benefit the Hub. This is an important and exciting milestone in the Hub’s evolution and a pivotal moment for the broader interchain ecosystem.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Over the past three years, Informal has played a key role in supporting the Cosmos Hub. When we began, the Hub faced significant technical debt, lacked a clear product vision, and was far from its potential. Today, it stands as the reference chain of the Interchain stack, with a strong engineering culture and pioneering products like Forge and Hydro.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"To achieve its full potential, the Cosmos Hub needs to take the next step in order to continue building on this foundation that integrates technical development with product strategy, marketing, and community engagement. Skip’s stewardship promises to deliver the unified vision and execution the Hub requires to thrive.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"What’s next for Informal Systems?","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Following the ","nodeType":"text"},{"data":{"uri":"https://medium.com/the-interchain-foundation/cosmos-is-expanding-skip-joins-the-interchain-foundation-cfd346551dda"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"announcement","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", the development of the Cosmos Hub and Cosmos stack will be consolidated at the ICF and led by Skip. As part of these changes, funding from the ICF for Informal will come to an end. For more on Informal’s history of funding from the ICF, see our ","nodeType":"text"},{"data":{"uri":"https://informal.systems/blog/informal-business"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"previous post","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Late last year, Infomal sought funding directly from the Cosmos Hub for stewardship and R&D. That funding concludes at the end of this year. Informal will provide transitional support as the ICF and Skip teams pick up stewardship of the Cosmos Hub, reuniting it with the Cosmos stack and a unified vision for the Cosmos ecosystem.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"While Informal’s direct role is shifting, our dedication to empowering the broader ecosystem through open-source infrastructure, engineering excellence, and collaboration remains stronger than ever. Informal will continue to contribute to, develop, and maintain critical open-source projects while deepening collaborations with teams across the Cosmos, Ethereum, Bitcoin, and Solana ecosystems through our security, engineering, and validator offerings. While we have much more to share, here’s a short overview of what’s next for some of our projects: ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Comet","nodeType":"text"},{"data":{},"marks":[],"value":": Informal has stewarded Comet since launch on behalf of the ICF. Our stewardship mandate comes to an end this year as Skip steps into the stewardship role. Informal will continue basic maintenance and security response coverage as we assist Skip’s transition and onboard them for long term support and development. Although no longer stewarding, Informal will also continue to contribute to Comet and work directly with projects and partners on Comet related development and support.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Hermes & ibc-rs","nodeType":"text"},{"data":{},"marks":[],"value":": Informal remains dedicated to maintaining critical open-source infrastructure which serve the broader interchain ecosystem like Hermes and ibc-rs. Hermes is the primary relayer for the Cosmos ecosystem, relaying the vast majority of IBC traffic today. We’re eager to see the Rust-based ecosystem continue to grow, and work with partners old and new on exciting developments in that direction. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Malachite","nodeType":"text"},{"data":{},"marks":[],"value":": Malachite is a BFT consensus kernel based on the Tendermint algorithm and implemented in Rust. Funded and developed in ","nodeType":"text"},{"data":{"uri":"https://informal.systems/blog/interchain-meet-starknet"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"collaboration with the Starknet team","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", it’s the result of our multi-year research and engineering experience developing consensus systems. We are thrilled to announce our ","nodeType":"text"},{"data":{"uri":"https://x.com/zarinjo/status/1865418958519570595"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"partnership with Farcaster","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" using Malachite in their new data layer. More to come on Malachite in the following weeks, so stay tuned.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Cycles: ","nodeType":"text"},{"data":{"uri":"https://cycles.money/"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Cycles","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" is a Cosmos based open clearing protocol designed to clear the most debt for the most people with the least money. Cycles introduces a new privacy model to the Cosmos ecosystem with the recently released ","nodeType":"text"},{"data":{"uri":"https://github.com/informalsystems/cycles-quartz"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Quartz","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", a privacy-preserving TEE-sidecar for CosmWasm. To learn more, check out the recently published ","nodeType":"text"},{"data":{"uri":"https://informal.systems/blog/cycles-whitepaper"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Cycles whitepaper","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", and ","nodeType":"text"},{"data":{"uri":"https://x.com/cyclesmoney"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"follow Cycles on X","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". And remember, respect the graph.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Hydro: ","nodeType":"text"},{"data":{"uri":"https://hydro.cosmos.network/"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Hydro","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" was developed by Informal as the first decentralized market-maker for the Cosmos Hub. Hydro’s first pilot round hit its cap in 24 hours, and the second pilot round, launched yesterday, hit its cap in 4 minutes. Hydro improves access to liquidity across Cosmos and further cements ATOM’s role as Interchain Capital. The Hydro team will spin out of informal and work closely with Skip to focus exclusively on Hydro product development and bringing it to market.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We’re proud of what we’ve accomplished and look forward to building even more resilient, innovative systems in 2025 and beyond.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Onward,\nThe Informal Systems Team","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"\n","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"italic"}],"value":"Disclaimer","nodeType":"text"},{"data":{},"marks":[],"value":": Informal Systems made an investment into Skip in 2022. Ahead of the acquisition, Skip repurchased this investment at cost. Informal made no profit from this investment.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"\n","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"contentfulURL":"https://app.contentful.com/spaces/p79kctcd7ahy/entries/5xjvlJ1sdes3jDPyGn9jXb"},{"featureImage":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"6sZMaXTQvanqvTl7P3fjWF","type":"Asset","createdAt":"2025-07-21T20:38:42.273Z","updatedAt":"2025-07-21T20:38:42.273Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":6,"revision":1,"locale":"en-US"},"fields":{"title":"Twitter Post Cycles Whitepaper","description":"","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/6sZMaXTQvanqvTl7P3fjWF/0128b7055cdb4684fcd3854485c17e46/Twitter_Post_Cycles_Whitepaper.jpg","details":{"size":577398,"image":{"width":1920,"height":1080}},"fileName":"Twitter_Post_Cycles_Whitepaper.jpg","contentType":"image/jpeg"}}},"date":"2024-11-21","title":"Announcing the Cycles Whitepaper","slug":"cycles-whitepaper","categories":["Cycles"],"authors":["Cycles"],"keywords":"Cycles, Whitepaper, Clearing System, Payment Protocol, Peer-to-peer, Debt Settlement, Financial Infrastructure, Blockchain Finance, TEE","excerpt":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Introducing Cycles, a peer-to-peer electronic clearing system designed to clear the most debt with least money.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"includeTableOfContents":true,"introduction":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"In 2008, a new whitepaper was released: “Bitcoin: a peer-to-peer electronic cash system.”","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Today, in 2024, a new whitepaper is released: “Cycles: a peer-to-peer electronic clearing system.”","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"","nodeType":"text"},{"data":{"uri":"https://cycles.money/whitepaper.pdf"},"content":[{"data":{},"marks":[],"value":"https://cycles.money/whitepaper.pdf","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Since Bitcoin, blockchain communities have been promising a revolution in money, payments, and finance. Today, Bitcoin has taken its seat at the table of international money, but it feels something is fundamentally missing still. The cryptocurrency community, in its theory and its practice, has overemphasized on the Store of Value function of money, and on the asset side of the balance sheet. Heed the rallying cry: to build permissionless, counterparty free ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"assets","nodeType":"text"},{"data":{},"marks":[],"value":". Important, no doubt, for securing a fundamental human right to transact. But not sufficient to take on the larger problems of modern money and finance.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"5IzXEwOvswUwBuMPqLlgFf","type":"Asset","createdAt":"2024-11-20T19:11:46.213Z","updatedAt":"2024-11-20T19:11:46.213Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":2,"revision":1,"locale":"en-US"},"fields":{"title":"whitepaper-butterfly","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/5IzXEwOvswUwBuMPqLlgFf/536d38efd8a81fe2bb0cc0196586423b/whitepaper-butterfly.png","details":{"size":324088,"image":{"width":556,"height":500}},"fileName":"whitepaper-butterfly.png","contentType":"image/png"}}}},"content":[],"nodeType":"embedded-asset-block"},{"data":{},"content":[{"data":{},"marks":[],"value":"Much of the power of banking comes not from the assets but from the ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"liability","nodeType":"text"},{"data":{},"marks":[],"value":" side of the balance sheet. Specifically, from the coordinated settlement of liabilities through clearing. A peer-to-peer electronic cash system is thus a necessary but not a sufficient basis to re architect finance. What we need is a peer-to-peer electronic clearing system. As we’ll see, we can design a clearing system as a superset or generalization of a cash system. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"6qy73aT9HaRvwggpDnMq79","type":"Asset","createdAt":"2024-11-20T19:11:46.207Z","updatedAt":"2024-11-20T19:11:46.207Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":2,"revision":1,"locale":"en-US"},"fields":{"title":"whitepaper-drake-cash-clearing","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/6qy73aT9HaRvwggpDnMq79/07c163ee6f5668a7de6c314613ae07fa/whitepaper-drake-cash-clearing.png","details":{"size":218191,"image":{"width":500,"height":500}},"fileName":"whitepaper-drake-cash-clearing.png","contentType":"image/png"}}}},"content":[],"nodeType":"embedded-asset-block"},{"data":{},"content":[{"data":{},"marks":[],"value":"For centuries, banks have formed closed clearing clubs to settle huge volumes of debt with little or even no money at all. This results in massive liquidity savings for them. But you and I aren’t privy to those clubs. The rest of us are systematically excluded from the power of clearing and issuance, forced to settle in cold, hard cash. The opportunities for us to perform clearing abound, and yet, we have not the institutional support nor the technology to access them.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Until now. With Cycles, anyone can clear their debts in a private, secure, and accessible way, using any type of currency or credit that works for them. The core insight of Cycles is to take a ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"network ","nodeType":"text"},{"data":{},"marks":[],"value":"view of the graph of liabilities between people, and to operate multilaterally (across multiple individuals at once). This is in contrast to the more standard transactional, individualistic, and bilateral view of payments. The network view opens tremendous opportunities for everyday people and businesses to ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"save liquidity","nodeType":"text"},{"data":{},"marks":[],"value":": save on cash flow stress, working capital costs, late payments, and so on. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Cycles is made uniquely possible by a core property enabled by blockchains: atomic multilateral settlement. This means we can easily run a settlement operation across many people at once, in an all or nothing way, reducing debts and transferring assets across a group of strangers in a way that optimizes to clear the most debt with the least money for all. Blockchains are uniquely good at this, and with modern techniques, can even do it all privately. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Atomic multilateral settlement is used across blockchains today in the form of ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"asset pools","nodeType":"text"},{"data":{},"marks":[],"value":", like those backing automated market makers and lending protocols. But what is the purpose of assets, exchanges, and lending markets if not ultimately to facilitate people making payments? Hence, we need to start from the basics of payment systems. ","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"body":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Payment Systems ","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"So much of finance is actually built on top of or around payments. A most fundamental kind of finance is the simple extension of trade credit itself: I send you goods, you owe me money, in 30 days. These kinds of obligations are fundamental to the monetary and payment systems, and so much of banking arose to enable deferred payments like this to flow. Payments are thus fundamental to what money is. We like to say: “","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"money is where the payments are.","nodeType":"text"},{"data":{},"marks":[],"value":"”","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The design of Cycles is motivated by a brief critique of modern money, payments, and finance. In the whitepaper, we sketch the critique as six key points, indicating how Cycles addresses each. To summarize, a critique of modern finance:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Not designed from first principles, but cobbled together over centuries in response to liquidity crises. Cycles is designed from first principles by asking “how do we clear the most debt for the most people with the least money.”","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Reactive risk management via Central Bank lender-of-last resort compounds moral hazard and systemic risk. Cycles takes a proactive risk-management approach using the network structure of the graph to reduce risk.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Over emphasis on transfer and exchange of assets at the expense of the underlying liabilities that ultimately need to be settled. Cycles makes the liabilities a first class primitive and emphasizes settlement of real world debts.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Counterparty substitution and contract novation (securitization, factoring, etc.) transmutate risk in hard to understand ways. Cycles aims to settle debt using existing credit relationships before deferring to more complex risk transmutations. ","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Fragile dependence on market making dealer intermediaries that extract wealth through liquidity provisioning. Cycles focuses on ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"liquidity saving","nodeType":"text"},{"data":{},"marks":[],"value":" over the graph with minimal or no intermediaries.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Problems of issuance between and across central and commercial banks. Cycles formalizes the problem of issuance in terms of acceptance, and opens new ways to connect issuance to working capital needs and graph structure.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"ordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"TL;DR:\n\n","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"Respect the Graph.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"One of the major goals of Cycles is to provide a clearer conception of how to think about money. As we’ve said, Money is where the Payments Are. Money is fundamentally for payments - for denominating and discharging debt. The three functions of money (Unit of Account, Medium of Exchange, Store of Value) can then be understood simply:\n","nodeType":"text"}],"nodeType":"paragraph"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"4pTwgLzUbJqgmsipcFFvJ7","type":"Asset","createdAt":"2024-11-20T19:11:46.201Z","updatedAt":"2024-11-20T19:11:46.201Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":2,"revision":1,"locale":"en-US"},"fields":{"title":"whitepaper-money-functions","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/4pTwgLzUbJqgmsipcFFvJ7/9a3780cd308c925fa5ae29a69ed3520e/whitepaper-money-functions.png","details":{"size":26424,"image":{"width":843,"height":209}},"fileName":"whitepaper-money-functions.png","contentType":"image/png"}}}},"content":[],"nodeType":"embedded-asset-block"},{"data":{},"content":[{"data":{},"marks":[],"value":"The Store of Value function is obviously important, but not the whole story. The essential problem of payments is actually this. Armed with a Unit of Account, we can denominate unlimited amounts of debt. But how do we know there is enough Medium of Exchange available to settle it all? This is the very question that invokes anxiety in people who are concerned that fractional reserve banking might be a ponzi scheme. If banks create money by making loans with interest, how do they know there’s enough money out there to pay back all the loans and interest? Perhaps there isn’t, and hence why modern banking systems periodically seize up in liquidity crises that require Central Banks to issue more exchange media. \n","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"This is what liquidity is all about: the ability to settle a debt when it’s due. This is what it means to take on a liability and to face the liquidity constraint: some day the liability will be due, and you’ll have to actually pay it. This is what spawns the myriad problems of cash flow, grid lock, and late payments that create so much stress, increased working capital costs, and in the worst cases, bankruptcy. As they say, “you can be insolvent for a long time, but liquidity kills you quick.”","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"\nThus Cycles is motivated by a fundamental goal that responds to the perennial liquidity constraint that bears down on all economic actors:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"italic"}],"value":"How do we clear the most debt, for the most people, with the least money?","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Design","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"How? We start from first principles, introducing basic primitives from which we can express more complex cases. At the heart of Cycles is a simple ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"System of Intents","nodeType":"text"},{"data":{},"marks":[],"value":", containing two kinds of input primitives (","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"obligations","nodeType":"text"},{"data":{},"marks":[],"value":" and ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"acceptances","nodeType":"text"},{"data":{},"marks":[],"value":") and one kind of output primitive (","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"settlement records","nodeType":"text"},{"data":{},"marks":[],"value":"):","nodeType":"text"}],"nodeType":"paragraph"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"59u55LCmLw1rGdcaWr90zv","type":"Asset","createdAt":"2024-11-20T19:11:46.189Z","updatedAt":"2024-11-20T19:11:46.189Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":2,"revision":1,"locale":"en-US"},"fields":{"title":"whitepaper-system of intents","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/59u55LCmLw1rGdcaWr90zv/be30a7212d79c072c94ae9e51766cb5a/whitepaper-system_of_intents.png","details":{"size":111655,"image":{"width":1364,"height":574}},"fileName":"whitepaper-system of intents.png","contentType":"image/png"}}}},"content":[],"nodeType":"embedded-asset-block"},{"data":{},"content":[{"data":{},"marks":[],"value":"\nIn the whitepaper, we develop a graphical model and a language for describing this system. Let’s start with an obligation. If you owe me, that’s an obligation. Notice it’s your liability, but it’s my asset. If you sent me money on a blockchain, we’d see an asset transfer, but the blockchain doesn’t record what the underlying liability is that’s being settled. Cycles makes the underlying liabilities (the obligations) a first class citizen of the system. And of course, obligations don’t exist in bilateral silos. They form a complex multilateral graph: ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"d4BgwOwq5YYTNwyYWhQiQ","type":"Asset","createdAt":"2024-11-20T19:11:46.196Z","updatedAt":"2024-11-20T19:11:46.196Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":2,"revision":1,"locale":"en-US"},"fields":{"title":"whitepaperobligation network","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/d4BgwOwq5YYTNwyYWhQiQ/28a26cb726d14d3861dc8d66b0de6f14/whitepaperobligation_network.png","details":{"size":33974,"image":{"width":626,"height":231}},"fileName":"whitepaperobligation network.png","contentType":"image/png"}}}},"content":[],"nodeType":"embedded-asset-block"},{"data":{},"content":[{"data":{},"marks":[],"value":"\nWhat can you do with a graph of obligations? The first thing you can do is set-off, where obligations in a cycle can be netted off against each other: ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"7emJSehMmCNYs9TypskBA6","type":"Asset","createdAt":"2024-11-20T19:11:46.203Z","updatedAt":"2024-11-20T19:11:46.203Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":2,"revision":1,"locale":"en-US"},"fields":{"title":"whitepaper-setoff","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/7emJSehMmCNYs9TypskBA6/9064b2ce44843a1653bdfe6afc2b82f5/whitepaper-setoff.png","details":{"size":30429,"image":{"width":870,"height":278}},"fileName":"whitepaper-setoff.png","contentType":"image/png"}}}},"content":[],"nodeType":"embedded-asset-block"},{"data":{},"content":[{"data":{},"marks":[],"value":"\nThis is what most people first understand when they think about Cycles. With a set of obligations in a cycle like this, Cycles can produce a settlement record for each obligation that reduces them all, going from Before to After in the figure. But it goes further than this. We can add acceptances.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"\nThe simplest way to understand acceptances is as a willingness to accept a currency for payment. For instance, if Alice has money in the bank, and Alice owes Bob, and Bob is willing to accept bank money. We can actually draw this out as well:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"13YsrYyznltFTYqif2aZje","type":"Asset","createdAt":"2024-11-20T19:11:46.215Z","updatedAt":"2024-11-20T19:12:12.053Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":5,"revision":2,"locale":"en-US"},"fields":{"title":"cycles-whitepaper-assignment","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/13YsrYyznltFTYqif2aZje/b47bf60f232bbed57ebea14e892b5386/whitepaper-assignemnt.png","details":{"size":29262,"image":{"width":850,"height":356}},"fileName":"whitepaper-assignemnt.png","contentType":"image/png"}}}},"content":[],"nodeType":"embedded-asset-block"},{"data":{},"content":[{"data":{},"marks":[],"value":"\nNotice Alice’s money in the bank is represented as an obligation from the bank. But Bob’s acceptance of bank money is shown explicitly as an acceptance intent - a dashed line - from Bob to the bank. And notice this makes a cycle. Which means every single payment is actually a cycle in the graph!","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"When an acceptance is settled, it becomes an obligation going the other way. Bob accepts bank money, so once he has money in the bank, the bank owes him. Of course, we can replace the Bank here with Bitcoin or USDC or any other cryptocurrency, and thus represent ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"any asset ","nodeType":"text"},{"data":{},"marks":[],"value":"as a liability from its issuer. By including the issuer as a node in the graph, the graph can natively include many different sources of liquidity. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"But we can also use acceptances to represent a willingness to lend. Specifically, a credit line. If Alice doesn’t have money in the bank (no obligation from the bank), but the bank will lend to her, we can represent that as an acceptance ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"from","nodeType":"text"},{"data":{},"marks":[],"value":" the bank: ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"61cSzBM9ih1PYXT3oVPOIr","type":"Asset","createdAt":"2024-11-20T19:11:46.198Z","updatedAt":"2024-11-20T19:11:46.198Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":2,"revision":1,"locale":"en-US"},"fields":{"title":"whitepaper-overdraft","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/61cSzBM9ih1PYXT3oVPOIr/08f626b9d9a2b427c885415d957d99be/whitepaper-overdraft.png","details":{"size":35809,"image":{"width":896,"height":356}},"fileName":"whitepaper-overdraft.png","contentType":"image/png"}}}},"content":[],"nodeType":"embedded-asset-block"},{"data":{},"content":[{"data":{},"marks":[],"value":"Finally, we show an example where Alice owes Bob and Bob owes Carol. Alice doesn’t have money, but Carol is actually willing to be owed by Alice instead of Bob: ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"4ZgawJ6kihE1DJdQuVpuiq","type":"Asset","createdAt":"2024-11-20T19:11:46.209Z","updatedAt":"2024-11-20T19:11:46.209Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":2,"revision":1,"locale":"en-US"},"fields":{"title":"whitepaper-assumption","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/4ZgawJ6kihE1DJdQuVpuiq/86e884655284e3ef051ddd9a2921d056/whitepaper-assumption.png","details":{"size":28874,"image":{"width":842,"height":354}},"fileName":"whitepaper-assumption.png","contentType":"image/png"}}}},"content":[],"nodeType":"embedded-asset-block"},{"data":{},"content":[{"data":{},"marks":[],"value":"Again, the whole cycle clears, but in this case, no money was needed at all, and Alice just owes Carol. \n\nWe can express all kinds of graphs using these simple primitives, and the whitepaper offers some further analysis of these four different ways for Alice to settle her debt to Bob. When combined together, we get complex graph structures that we can then optimize over to find the cycles that clear the most debt for the most people with the least money. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The core of Cycles is thus a ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"neutral settlement layer","nodeType":"text"},{"data":{},"marks":[],"value":" above which users and communities can define various optimization strategies for how they clear their debts. We can even combine many kinds of currency types in a single graph, allowing more and more people to benefit, even if they don’t use or accept that currency! ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"4qZruOvAmJZ0umWPvSjOk1","type":"Asset","createdAt":"2024-11-20T19:11:46.211Z","updatedAt":"2024-11-20T19:11:46.211Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":2,"revision":1,"locale":"en-US"},"fields":{"title":"whitepaper-multicurrency","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/4qZruOvAmJZ0umWPvSjOk1/702a29169e6fb0dd7b2728f75afa2780/whitepaper-multicurrency.png","details":{"size":280986,"image":{"width":622,"height":358}},"fileName":"whitepaper-multicurrency.png","contentType":"image/png"}}}},"content":[],"nodeType":"embedded-asset-block"},{"data":{},"content":[{"data":{},"marks":[],"value":"Ultimately, Cycles allows more debt to be cleared for more people with less money, reducing risk, late payments, and working capital costs across the board. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"So, how do we build it?","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Protocol","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"At a technical level, the Cycles Protocol must provide atomic multilateral settlement of private intents in an extensible credit environment. This means:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"all settlements execute simultaneously across many parties at once","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"all debts remain private, including both the amount of the debt and the specific counterparties (who owes who)","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"All kinds of liquidity sources, currency types, and lending protocols can be integrated into the graph\n","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"The architecture of the Cycles Protocol is what we call a ZK-TEE sidecar. It uses a Trusted Execution Environment (TEE) for private off-chain compute, and it uses Zero Knowledge (ZK) proofs to ensure the computation was correct and to reduce the dependence on trusted hardware. The high level architecture looks like this:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"6Ot35sno3J0OrKwJA9M34n","type":"Asset","createdAt":"2024-11-20T19:11:46.205Z","updatedAt":"2024-11-20T19:11:46.205Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":2,"revision":1,"locale":"en-US"},"fields":{"title":"whitepaper-quartz","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/6Ot35sno3J0OrKwJA9M34n/6a132664de8e8bab7f7608dfe4cc54f8/whitepaper-quartz.png","details":{"size":164024,"image":{"width":1728,"height":798}},"fileName":"whitepaper-quartz.png","contentType":"image/png"}}}},"content":[],"nodeType":"embedded-asset-block"},{"data":{},"content":[{"data":{},"marks":[],"value":"Essentially, users encrypt their intents and submit them to the blockchain. At some frequency, the encrypted intents are retrieved by the ZK-TEE sidecar where they are decrypted into a graph. The TEE then runs the graph solver to produce a settlement solution. The solution is encrypted, and a ZK proof is produced attesting to its correctness. Everything is then submitted back to the chain to be verified, before the user sees the final results. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We have implemented this architecture as an open source framework called ","nodeType":"text"},{"data":{"uri":"https://github.com/informalsystems/cycles-quartz"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Quartz","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", that anyone can use for secure communication with TEEs.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Note the importance of the TEE here. When using ZK proofs alone, there is no privacy from the ZK prover, who must have access to all the input data necessary to produce a proof. This is fine for simple asset transfer protocols like ZCash, Penumbra, or Namada, where the prover is the end user operating only on their own data. But in Cycles, we run a multilateral graph algorithm across many users, where no single user has all the data. The most effective way to do that today is via a TEE. At least until Multi Party Computation and Fully Homomorphic Encryption are further advanced.\n\nAnd what about the vulnerabilities of TEEs? There have been numerous vulnerabilities and security issues over the years. But there have also been many improvements. And we can actually use clever protocol design and blockchains themselves to improve TEE security. Specifically, by running a blockchain light client ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"within the TEE","nodeType":"text"},{"data":{},"marks":[],"value":", we can significantly reduce the attack surface area and mitigate many possible vulnerabilities. See the talk from our founder Ethan Buchman, on ","nodeType":"text"},{"data":{"uri":"https://www.youtube.com/watch?app=desktop&v=XwKIt5XYyqw"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"How to Win Friends and TEE-fluence People","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"4NizWK6Rw9nY9vGzGAPrdT","type":"Asset","createdAt":"2024-11-20T19:11:46.193Z","updatedAt":"2024-11-20T19:11:46.193Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":2,"revision":1,"locale":"en-US"},"fields":{"title":"whitepaper-tee-vulns","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/4NizWK6Rw9nY9vGzGAPrdT/f93d7f71584100795904d0fade494edd/whitepaper-tee-vulns.png","details":{"size":391802,"image":{"width":500,"height":560}},"fileName":"whitepaper-tee-vulns.png","contentType":"image/png"}}}},"content":[],"nodeType":"embedded-asset-block"},{"data":{},"content":[{"data":{},"marks":[],"value":"Finally, the Cycles Protocol must support an extensible credit environment. It defines an account model where every node in the graph is a smart contract account that also corresponds to a balance sheet. This makes every node a liquidity source, and every liquidity source a node. Thus, in Cycles, ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"every account is a lending protocol","nodeType":"text"},{"data":{},"marks":[],"value":". This creates an innovative new environment for experimenting with new risk-reduced stablecoins and lending protocols.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Cycles enables countless use cases, from simple trade credit payments and clearing to more advanced financial relationships. Auto repayment of loans, data-based lending and stablecoins, private funding of SMEs, p2p loans with and without capital, mutual credit, Circles UBI, discount ladders for p2p factoring, batched exchanges, and more! ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The Cycles Whitepaper is just the first step in our bringing these powerful new ideas to the world. Our ultimate goal is to build a universal payments and finance engine to clear the most debt for the most people with the least money. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Follow us on twitter ","nodeType":"text"},{"data":{"uri":"https://x.com/cyclesmoney"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"@cyclesmoney","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" to stay up-to-date and learn more about our first products.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"contentfulURL":"https://app.contentful.com/spaces/p79kctcd7ahy/entries/zGB03Iae4riXQfwvcce60"},{"featureImage":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"4M83QRVMZtLNty8XsVYZcy","type":"Asset","createdAt":"2024-08-13T22:06:21.290Z","updatedAt":"2024-08-13T22:17:18.863Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":7,"revision":2,"locale":"en-US"},"fields":{"title":"Blog CosmosHub","description":"","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/4M83QRVMZtLNty8XsVYZcy/61673be883dd56aa320cad2a9054933a/Blog_CosmosHub.jpg","details":{"size":167808,"image":{"width":1920,"height":1080}},"fileName":"Blog_CosmosHub.jpg","contentType":"image/jpeg"}}},"date":"2024-10-21","title":"Cosmos Hub September 2024 Update Key Upgrades and ICS Advancements","slug":"cosmos-hub-september-2024","categories":["Engineering"],"authors":["Marius Poke"],"keywords":"Cosmos Hub update, Gaia v19.2 upgrade, Gaia v20 release, Permissionless ICS, Cosmos blockchain advancements, blockchain security, Cosmos Hub governance, Hydro launch, ICS validators, Cosmos testnet","excerpt":{"nodeType":"document","data":{},"content":[{"nodeType":"paragraph","data":{},"content":[{"nodeType":"text","value":"September 2024 Cosmos Hub developments including v19.2 emergency upgrade, Gaia v20 completion, and Hydro progress.","marks":[],"data":{}}]}]},"includeTableOfContents":false,"body":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Cosmos Hub Update September 2024","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"It’s time for the usual update from the Informal Systems’ Cosmos Hub team. Here are some of the highlights:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Coordinated the Cosmos Hub v19.2 emergency upgrade.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Completed the testnet and governance phases for Gaia v20.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Completed the implementation phase for Permissionless ICS.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Started working on the integration phase for Gaia v21.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Made significant progress towards the Hydro launch.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"Note that we use ","nodeType":"text"},{"data":{"uri":"https://forum.cosmos.network/t/cosmos-hub-improvement-process-chips-revision/13730"},"content":[{"data":{},"marks":[],"value":"CHIPs","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" to track the progress of our work. Hence, throughout this update, we refer to different phases of the CHIPs framework.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Cosmos Hub v19.2 Emergency Upgrade","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"In the first week of September, the Cosmos Hub underwent an emergency upgrade to fix a bug in the ICS provider module. The bug consisted of missing validation of the signer for some of the ICS messages — MsgOptIn, MsgOptOut, MsgAssignConsumerKey, and MsgSetConsumerCommissionRate. As a result, any user could have opted in, opted out, changed the commission rate, or changed what public key a validator uses on a Consumer Chain.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Together with Hypha and Amulet, we coordinated the upgrade to ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/gaia/releases/tag/v19.2.0"},"content":[{"data":{},"marks":[],"value":"Gaia v19.2.0","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". Then, we published a ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/interchain-security/security/advisories/GHSA-7q74-g774-7x3g"},"content":[{"data":{},"marks":[],"value":"security advisory","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" describing the bug and the severity assessment. We thank the validator community for a successful upgrade.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Gaia v20 — Testnet and Governance Phases","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"In September, we completed the testnet and governance phases for Gaia v20, a release that will add the following features to the Cosmos Hub:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"ICS with Inactive Validators (as per ","nodeType":"text"},{"data":{"uri":"https://www.mintscan.io/cosmos/proposals/930"},"content":[{"data":{},"marks":[],"value":"prop 930","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":") enables validators from outside the Hub’s active set to validate on Consumer Chains. This feature brings the following benefits: it reduces the entry barrier for projects to launch as Consumer Chains since more validators will be allowed to opt in; it enables validators outside the Hub’s active set to compete by providing their services to interesting projects; and it reduces the risk of all the validators of a Consumer Chain opting out, which would require the chain to leave ICS.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Permissionless ICS (as per ","nodeType":"text"},{"data":{"uri":"https://www.mintscan.io/cosmos/proposals/945"},"content":[{"data":{},"marks":[],"value":"prop 945","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":") enables users to launch opt-in Consumer Chains on the Cosmos Hub ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"},{"type":"bold"}],"value":"permissionlessly","nodeType":"text"},{"data":{},"marks":[],"value":". Given that validators are free to choose whether they want to run a given opt-in Consumer Chain, it is only natural to also enable projects to launch as opt-in Consumer Chains by simply submitting transactions to the Cosmos Hub and, thus, avoiding the need to go through the process of governance.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Removal of Unbonding Pausing from ICS (as described by ","nodeType":"text"},{"data":{"uri":"https://cosmos.github.io/interchain-security/adrs/adr-018-remove-vscmatured"},"content":[{"data":{},"marks":[],"value":"ADR 018","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":") reduces the complexity of the ICS protocol. It removes the dependency between the liveness of undelegation operations on the Cosmos Hub and the liveness of consumer chains. See the section below for more details.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Bump CosmWasm/wasmd to ","nodeType":"text"},{"data":{"uri":"https://github.com/CosmWasm/wasmd/releases/tag/v0.53.0"},"content":[{"data":{},"marks":[],"value":"v0.53.0","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" fixes two issues with the current CosmWasm deployment.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Bump IBC to ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/ibc-go/releases/tag/v8.5.1"},"content":[{"data":{},"marks":[],"value":"v8.5.1","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"The Cosmos Hub upgraded to v20 on October 2nd. We thank the Cosmos Hub community for participating in the ","nodeType":"text"},{"data":{"uri":"https://forum.cosmos.network/t/proposal-966-passed-gaia-v20-upgrade/14466"},"content":[{"data":{},"marks":[],"value":"forum discussion ","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"and voting on the ","nodeType":"text"},{"data":{"uri":"https://www.mintscan.io/cosmos/proposals/966"},"content":[{"data":{},"marks":[],"value":"software upgrade proposal","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Read more about what the Gaia v20 upgrade unlocks ","nodeType":"text"},{"data":{"uri":"https://informal.systems/blog/gaia-v20-upgrade"},"content":[{"data":{},"marks":[],"value":"here","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"ICS v6.1.0","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"In September, we released ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/interchain-security/releases/tag/v6.1.0"},"content":[{"data":{},"marks":[],"value":"ICS v6.1.0","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", which contains the new ICS features in Gaia v20 — permissionless, inactive provider validators and removal of unbonding pausing. Besides finalizing the implementation and testing of all these features, we completed the following tasks to improve user experience.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"We documented the ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/interchain-security/blob/v6.1.0/CHANGELOG.md#api-breaking"},"content":[{"data":{},"marks":[],"value":"API breaking changes","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" introduced by Permissionless ICS.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"We created a ","nodeType":"text"},{"data":{"uri":"https://cosmos.github.io/interchain-security/integrators/integrating_inactive_validators"},"content":[{"data":{},"marks":[],"value":"guide for integrators","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" on how to use the Inactive Validators feature without affecting their applications.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"We updated the ICS docs with a ","nodeType":"text"},{"data":{"uri":"https://cosmos.github.io/interchain-security/build/modules/overview"},"content":[{"data":{},"marks":[],"value":"description of the existing ICS module","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"We also coordinated and provided support to Zellic during their audit of the Permissionless ICS feature. Once it is finalized, we will publish the audit report.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Gaia v21 — Integration Phase","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"We started the integration phase for Gaia v21, a release that will add the following improvements to ICS on the Cosmos Hub:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Enable Consumer Chains to use the memo field of the IBC transfer packets to tag ICS rewards with the consumer ID. As a result, Consumer Chains can send ICS rewards in any denomination and on any IBC channel. For example, Consumer Chains could send ICS rewards in native USDC from Noble to the Cosmos Hub.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Enable every opt-in Consumer Chain to add up to three denoms that will be accepted as ICS rewards without going through governance. This will make opt-in Consumer Chains truly permissionless.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"We are targeting the Cosmos Hub v21 upgrade on October 30th.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Forge","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"Forge is a comprehensive front-end platform designed to streamline the deployment of new projects such as consumer chains. This initiative aims to dramatically simplify launching and managing Consumer Chains within the Cosmos ecosystem. We connected Forge to the Cosmos Hub testnet throughout the month and refactored the UI/UX.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Hydro","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"","nodeType":"text"},{"data":{"uri":"https://forum.cosmos.network/t/atom-wars-introducing-the-hydro-auction-platform/13842"},"content":[{"data":{},"marks":[],"value":"Hydro","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" is a bidding and governance platform for efficient deployment of liquidity across the Interchain and an essential part of the ","nodeType":"text"},{"data":{"uri":"https://forum.cosmos.network/t/the-atom-wars-a-new-strategy-for-liquidity-injections/13122"},"content":[{"data":{},"marks":[],"value":"ATOM Wars strategy","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". Throughout the last month, we made significant progress towards the Hydro launch.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"We made the ","nodeType":"text"},{"data":{"uri":"https://github.com/informalsystems/hydro"},"content":[{"data":{},"marks":[],"value":"Hydro backend","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" code public. We completed testing the code using the ","nodeType":"text"},{"data":{"uri":"https://github.com/strangelove-ventures/interchaintest"},"content":[{"data":{},"marks":[],"value":"Interchain testing framework","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" and deployed the contract on Neutron for further testing in the final production environment. We also set up the required ICQ relayer infrastructure.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"We got an internal review conducted by the ","nodeType":"text"},{"data":{"uri":"https://informal.systems/services/security-audits"},"content":[{"data":{},"marks":[],"value":"audit team at Informal","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". The review found one high-impact issue around claiming tributes, which we have already fixed.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"We added minor improvements to the Hydro contract to enable better front-end integration (e.g., extra queries). We also started the user testing for the Hydro frontend.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"We set up the DAODAO deployment for the Hydro Committee and created documentation on how they can interact with Hydro. We are also working with the Hydro Committee to sketch out a monitoring plan around the security of the smart contract and the liquidity deployments.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"We started coordinating with external teams to create new protocols, such as vote aggregators or hedging strategies around Hydro.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"What This Enables","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"This month's developments further strengthen the Cosmos Hub's position as the best place to launch a chain:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Enhanced Security: Swift responses to vulnerabilities demonstrate our commitment to maintaining a secure and reliable network.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Streamlined Chain Deployment: Permissionless ICS and Forge lower entry barriers for new projects, fostering innovation within the ecosystem.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Expanded Participation: ICS with Inactive Validators broadens the validator base, improving decentralization and security.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Improved User Experience: Removing Unbonding Pausing from ICS simplifies operations and enhances reliability for ATOM holders.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Optimized Liquidity: Hydro's imminent launch will create a flexible mechanism for efficient liquidity deployment across the Interchain.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"These advancements reinforce the Cosmos Hub's role as the premier platform for launching and managing blockchain projects. We're excited about these new capabilities and the continued growth they will bring to the ecosystem.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"contentfulURL":"https://app.contentful.com/spaces/p79kctcd7ahy/entries/4RYYYwvyYyhLwMnXUXL5tJ"},{"featureImage":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"4KnFtd7l0DBLi47nnjVY4l","type":"Asset","createdAt":"2024-08-16T06:02:51.946Z","updatedAt":"2024-08-16T06:02:51.946Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":3,"revision":1,"locale":"en-US"},"fields":{"title":"Blog CosmosHub 2","description":"","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/4KnFtd7l0DBLi47nnjVY4l/68d62ebe878e498484fc6cac31d6e9a3/Blog_CosmosHub_2.jpg","details":{"size":187238,"image":{"width":1920,"height":1080}},"fileName":"Blog_CosmosHub_2.jpg","contentType":"image/jpeg"}}},"date":"2024-10-02","title":"Gaia v20 Upgrade Easier Entry to Cosmos with Permissionless ICS","slug":"gaia-v20-upgrade","categories":["Engineering"],"authors":["Devashri Kulwal"],"keywords":"Cosmos Hub v20\nupgrade\nblockchain developers\ndapps\ninterchain\nvalidators\ngovernance \nblockchain technology\nchains\nlaunch a chain \nquick launch ","excerpt":{"nodeType":"document","data":{},"content":[{"nodeType":"paragraph","data":{},"content":[{"nodeType":"text","value":"Gaia v20 introduces Permissionless ICS, inactive validator support, and unbonding pause removal for easier entry.","marks":[],"data":{}}]}]},"includeTableOfContents":true,"introduction":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"The Cosmos Hub has successfully upgraded to ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/gaia/releases"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Gaia v20","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", making it easier than ever for new Consumer Chains and validators to join the Cosmos Hub. This release brings three powerful new features that lower the barriers for chains and validators, making it easier to participate in the growing interchain ecosystem. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Permissionless ICS","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"ICS with Inactive Hub Validators","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Removal of Unbonding Pausing from ICS","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"body":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Key features of Gaia v20","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"1.","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":" Permissionless ICS","nodeType":"text"},{"data":{},"marks":[],"value":" (","nodeType":"text"},{"data":{"uri":"https://www.mintscan.io/cosmos/proposals/945"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Prop 945","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":")","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"With Permissionless Interchain Security (ICS), new chains can now launch on the Cosmos Hub without the need for a governance proposal. If a chain is set up as an “opt-in” chain, it can be permissionlessly launched by simply issuing a transaction. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Consumer Chains are registered with a single transaction when underlying parameters are defined. Once the spawn time has been reached and at least one validator has opted in, the consumer chain is launched. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"7KXnxwf6vYlbLviwBInXuW","type":"Asset","createdAt":"2024-10-02T16:19:05.859Z","updatedAt":"2024-10-02T16:19:05.859Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":4,"revision":1,"locale":"en-US"},"fields":{"title":"Permissionless ics","description":"","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/7KXnxwf6vYlbLviwBInXuW/fde7a9183158e7b43c0c36476a7742f6/Screenshot_2024-10-02_at_6.10.22_PM.png","details":{"size":101075,"image":{"width":976,"height":518}},"fileName":"Screenshot 2024-10-02 at 6.10.22 PM.png","contentType":"image/png"}}}},"content":[],"nodeType":"embedded-asset-block"},{"data":{},"content":[{"data":{},"marks":[],"value":"This simplifies the process for new projects and reduces the time it takes to onboard Consumer Chains. Note that governance approval is still needed for chains launching as Top N on the Hub. You can read more about the feature ","nodeType":"text"},{"data":{"uri":"https://cosmos.github.io/interchain-security/features/permissionless"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"here","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"2. ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"ICS with Inactive Hub Validators (","nodeType":"text"},{"data":{"uri":"https://www.mintscan.io/cosmos/proposals/930"},"content":[{"data":{},"marks":[{"type":"underline"},{"type":"bold"}],"value":"Prop 930","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[{"type":"bold"}],"value":")","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"This feature allows validators outside the Cosmos Hub’s active set to participate in validating Consumer Chains. Essentially, even if a validator isn’t part of the top active set (180 currently) on the Hub, they can still contribute to securing new chains. This opens up opportunities for a broader range of validators, as the first 200 validators are eligible to validate Consumer Chains. \n\nBy increasing validator diversity, the feature lowers the entry barriers for both validators and chains, helping distribute risk more evenly across the network.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"3.","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":" Removal of Unbonding Pausing from ICS (ADR 018)","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Previously, the Interchain Security protocol included a feature that paused unbonding in certain situations, tying the liveness of undelegation operations to both the Hub and Consumer Chains. With this new upgrade, the unbonding pause is removed, making the process simpler and eliminating dependencies between the Hub and Consumer Chains. This change streamlines the ICS protocol and improves overall efficiency.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"4. Security and Patch release: The release also bumps CosmWasm/wasmd to ","nodeType":"text"},{"data":{"uri":"https://github.com/CosmWasm/wasmd/releases/tag/v0.53.0"},"content":[{"data":{},"marks":[],"value":"v0.53.0","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" and ibc-go to ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/ibc-go/releases/tag/v8.5.1"},"content":[{"data":{},"marks":[],"value":"v8.5.1","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Why this matters for the interchain? ","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"Gaia v20 upgrade makes it easier for new chains and validators to join the Cosmos ecosystem with less friction. These features are a crucial step toward reducing complexity, increasing validator participation, and accelerating the growth of the interchain. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We are continually making it easier for developers to launch chains as painlessly as possible. With Forge, an upcoming Hub product, we aim to simplify and accelerate the development and onboarding process for Consumer Chains, ensuring a smoother experience for developers.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Whether you're a developer, a validator, or a holder, this upgrade brings tangible benefits that will make the Cosmos Hub more efficient, secure, and ready for the future of blockchain technology.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"For more information on how to get started with it, explore the official ","nodeType":"text"},{"data":{"uri":"https://hub.cosmos.network/main"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"documentation","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" and join the vibrant ","nodeType":"text"},{"data":{"uri":"https://forum.cosmos.network"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"community","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" of developers making a difference in the interchain space.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Welcome to the best place to launch a chain. ","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"contentfulURL":"https://app.contentful.com/spaces/p79kctcd7ahy/entries/3ntXjSpcHG7gKOoolGKZ5c"},{"featureImage":"$4:props:posts:29:featureImage","date":"2024-09-16","title":"Cosmos Hub August 2024 Update: v19 Upgrade, ICS Progress, and Hydro Launch","slug":"cosmos-hub-august-2024","categories":["Engineering"],"authors":["Marius Poke"],"keywords":"Cosmos Hub August 2024 update, Cosmos Hub v19, Gaia v20 testnet, Permissionless ICS, Forge Cosmos Hub, Hydro platform launch, Interchain Security, Cosmos blockchain news","excerpt":{"nodeType":"document","data":{},"content":[{"nodeType":"paragraph","data":{},"content":[{"nodeType":"text","value":"August 2024 Cosmos Hub developments including v19 upgrade, Gaia v20 progress, and Hydro launch preparations.","marks":[],"data":{}}]}]},"includeTableOfContents":false,"body":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"It’s time for the usual update from the Informal Systems’ Cosmos Hub team. Here are some of the highlights:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Cosmos Hub v19 upgrade.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Working on the integration and testnet phases for Gaia v20.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Completed the signaling phase and started the implementation phase for Permissionless ICS.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Completed the signaling phase and continued the implementation phase for Forge.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Made significant progress towards the Hydro launch.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"Note that we use ","nodeType":"text"},{"data":{"uri":"https://forum.cosmos.network/t/cosmos-hub-improvement-process-chips-revision/13730"},"content":[{"data":{},"marks":[],"value":"CHIPs","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" to track the progress of our work. Hence, throughout this update, we refer to different phases of the CHIPs framework.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"ICS Terminology","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"Before going into the updates from the previous month, we want to clarify the ICS terminology. Recently, you might have heard multiple ICS related names / terms used in the community. The following definitions should reduce the confusion:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"},{"type":"italic"}],"value":"Forge ","nodeType":"text"},{"data":{},"marks":[],"value":"(formerly known as the Permissionless ICS Frontend) is the ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"product ","nodeType":"text"},{"data":{},"marks":[],"value":"that makes the ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"Cosmos Hub the best place to launch a chain","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"},{"type":"italic"}],"value":"Interchain Security (ICS) ","nodeType":"text"},{"data":{},"marks":[],"value":"is an IBC ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"protocol ","nodeType":"text"},{"data":{},"marks":[],"value":"for shared security that powers Forge. The ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/interchain-security"},"content":[{"data":{},"marks":[],"value":"cosmos/interchain-security github repo","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" contains an open-source implementation of the ICS protocol.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"},{"type":"italic"}],"value":"Replicated Security ","nodeType":"text"},{"data":{},"marks":[],"value":"is a major ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"feature ","nodeType":"text"},{"data":{},"marks":[],"value":"of ICS that enables Consumer Chains to fully replicate the security of the Provider Chain, i.e., use the entire validator set of the Provider Chain. Replicated Security is in production since the Cosmos Hub v9 upgrade.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"},{"type":"italic"}],"value":"Partial Set Security (PSS) ","nodeType":"text"},{"data":{},"marks":[],"value":"is a major ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"feature ","nodeType":"text"},{"data":{},"marks":[],"value":"of ICS that enables Consumer Chains to use only a subset of the Provider Chain’s validator set. This subset can be determined by the top N% validators by voting power (top-N Consumer Chains) or by validators opting in to validate (opt-in Consumer Chains). PSS allows for more flexible security tradeoffs than Replicated Security. Note that top-N with N=100 is equivalent to Replicated Security. PSS has been in production since the Cosmos Hub v17 upgrade.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Permissionless ICS ","nodeType":"text"},{"data":{},"marks":[],"value":"is a major ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"feature ","nodeType":"text"},{"data":{},"marks":[],"value":"of ICS that enables users to ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"permissionlessly ","nodeType":"text"},{"data":{},"marks":[],"value":"launch an opt-in Consumer Chain on the Provider Chain (i.e., on the Cosmos Hub). Permissionless ICS will be launched in production with the Cosmos Hub v20 upgrade.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"Cosmos Hub v19 Upgrade","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"On August 21st, the Cosmos Hub upgraded to Gaia ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/gaia/releases/tag/v19.1.0"},"content":[{"data":{},"marks":[],"value":"v19.1.0","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" (as per ","nodeType":"text"},{"data":{"uri":"https://www.mintscan.io/cosmos/proposals/948"},"content":[{"data":{},"marks":[],"value":"prop 948","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"). This is a major release that upgraded the Cosmos Hub to the latest versions of the Interchain Stack:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Cosmos SDK v0.50 — the Cosmos Hub will use ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/cosmos-sdk/releases/tag/v0.50.9-lsm"},"content":[{"data":{},"marks":[],"value":"v0.50.9-lsm","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", a special Cosmos SDK branch with support for LSM","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"IBC ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/ibc-go/releases/tag/v8.4.0"},"content":[{"data":{},"marks":[],"value":"v8.4.0","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"CometBFT ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/releases/tag/v0.38.11"},"content":[{"data":{},"marks":[],"value":"v0.38.11","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Interchain Security ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/interchain-security/releases/tag/v5.1.1"},"content":[{"data":{},"marks":[],"value":"v5.1.1","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Packet Forward Middleware ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/ibc-apps/releases/tag/middleware%2Fpacket-forward-middleware%2Fv8.0.2"},"content":[{"data":{},"marks":[],"value":"v8.0.2","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"IBC Rate Limiting ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/ibc-apps/releases/tag/modules%2Frate-limiting%2Fv8.0.0"},"content":[{"data":{},"marks":[],"value":"v8.0.0","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Fee Market ","nodeType":"text"},{"data":{"uri":"https://github.com/skip-mev/feemarket/releases/tag/v1.1.0"},"content":[{"data":{},"marks":[],"value":"v1.1.0","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"CosmWasm/wasmd to ","nodeType":"text"},{"data":{"uri":"https://github.com/CosmWasm/wasmd/releases/tag/v0.51.0"},"content":[{"data":{},"marks":[],"value":"v0.51.0","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"This is part of a larger initiative to make the ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"},{"type":"italic"}],"value":"Cosmos Hub the reference chain for the Interchain Stack","nodeType":"text"},{"data":{},"marks":[],"value":" and is a collaboration with Binary Builders. This initiative aims to improve the upgrade process to newer versions of the Interchain Stack, which will consequently enhance the adoption within the Cosmos ecosystem. Additionally, the Cosmos Hub community will gain access to the new Interchain Stack features sooner, resulting in faster product development. Finally, by being on par with the latest releases of the Interchain Stack, the Cosmos Hub community can more actively contribute to the development of the Interchain Stack by asking for new features to be added in the subsequent releases. You can read more about what the upgrade entails ","nodeType":"text"},{"data":{"uri":"https://informal.systems/blog/cosmos-hub-v19-upgrade"},"content":[{"data":{},"marks":[],"value":"here","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"It is important to recognize that running the latest version of the Interchain Stack is a natural part of the agile development process. While the code may not be as battle-tested yet, this is an expected phase as we move quickly and strategically. Any bugs will be promptly identified and addressed through necessary upgrades, ensuring continuous improvement. This approach allows us to stay ahead while remaining diligent, and rest assured; our goal is to catch every issue to deliver the most robust and reliable system possible.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We thank the Cosmos Hub community for voting on the ","nodeType":"text"},{"data":{"uri":"https://www.mintscan.io/cosmos/proposals/948"},"content":[{"data":{},"marks":[],"value":"software upgrade proposal","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" and the validator community for a smooth upgrade with around 30 minutes of downtime.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Gaia v19.1.0","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"The v19 software upgrade proposal was for upgrading the Cosmos Hub to Gaia ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/gaia/releases/tag/v19.0.0"},"content":[{"data":{},"marks":[],"value":"v19.0.0","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". However, due to a security vulnerability in the Fee Market module, the v19 upgrade used Gaia ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/gaia/releases/tag/v19.1.0"},"content":[{"data":{},"marks":[],"value":"v19.1.0","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", which bumped the Fee Market module to ","nodeType":"text"},{"data":{"uri":"https://github.com/skip-mev/feemarket/releases/tag/v1.1.0"},"content":[{"data":{},"marks":[],"value":"v1.1.0","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". The vulnerability affected both the Cosmos Hub and Neutron chains. Thus, the security fix was coordinated with the Skip, Neutron, and Amulet teams. We thank everybody involved, especially the Cosmos Hub validators who successfully patched both networks.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Gaia v20 — Integration and Testnet Phases","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"Throughout August, we worked on the integration and testnet phases for Gaia v20, a release that will add the following features to the Cosmos Hub:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"ICS with Inactive Validators (as per ","nodeType":"text"},{"data":{"uri":"https://www.mintscan.io/cosmos/proposals/930"},"content":[{"data":{},"marks":[],"value":"prop 930","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":") enables validators from outside the Hub’s active set to validate on Consumer Chains. This feature brings the following benefits: it reduces the entry barrier for projects to launch as Consumer Chains since more validators will be allowed to opt in; it enables validators outside the Hub’s active set to compete by providing their services to interesting projects; and it reduces the risk of all the validators of a Consumer Chain opting out, which would require the chain to leave ICS.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Permissionless ICS (as per ","nodeType":"text"},{"data":{"uri":"https://www.mintscan.io/cosmos/proposals/945"},"content":[{"data":{},"marks":[],"value":"prop 945","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":") enables users to launch opt-in Consumer Chains on the Cosmos Hub ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"permissionlessly","nodeType":"text"},{"data":{},"marks":[],"value":". Given that validators are free to choose whether they want to run a given opt-in Consumer Chain, it is only natural to also enable projects to launch as opt-in Consumer Chains by simply submitting transactions to the Cosmos Hub and, thus, avoiding the need to go through the process of governance.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"The removal of Unbonding Pausing from ICS (as described by ","nodeType":"text"},{"data":{"uri":"https://cosmos.github.io/interchain-security/adrs/adr-018-remove-vscmatured"},"content":[{"data":{},"marks":[],"value":"ADR 018","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":") reduces the complexity of the ICS protocol and removes the dependency between the liveness of undelegation operations on the Cosmos Hub and the liveness of consumer chains. See the section below for more details.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Bump CosmWasm/wasmd to ","nodeType":"text"},{"data":{"uri":"https://github.com/CosmWasm/wasmd/releases/tag/v0.53.0"},"content":[{"data":{},"marks":[],"value":"v0.53.0","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" fixes two issues with the current CosmWasm deployment.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"ICS with Inactive Validators","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"Zellic successfully completed the ","nodeType":"text"},{"data":{"uri":"https://www.mintscan.io/cosmos/proposals/943"},"content":[{"data":{},"marks":[],"value":"audit of the ICS with Inactive Validators feature","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". We fixed all the minor and medium severity issues during the audit, and no major severity issues were found. Next, we will publish the audit report once it is finalized.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Permissionless ICS — Implementation Phase","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"We completed the signaling phase for the Permissionless ICS feature. We thank the Cosmos Hub community for voting on ","nodeType":"text"},{"data":{"uri":"https://www.mintscan.io/cosmos/proposals/945"},"content":[{"data":{},"marks":[],"value":"the signaling proposal","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We also made substantial progress on completing the ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/interchain-security/pull/2171"},"content":[{"data":{},"marks":[],"value":"implementation","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" (the main logic is done) and started the integration into Gaia. This enabled us to begin testing Gaia v20 (with Hypha) and integrating with ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"Forge,","nodeType":"text"},{"data":{},"marks":[],"value":" the front-end platform that allows the Cosmos Hub to be the ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"best place to launch a chain","nodeType":"text"},{"data":{},"marks":[],"value":". Next, we are improving existing e2e tests and adding new ones to increase testing coverage.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Finally, we are working with Simply Staking to source ","nodeType":"text"},{"data":{"uri":"https://www.mintscan.io/cosmos/proposals/954"},"content":[{"data":{},"marks":[],"value":"a third-party audit","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Removal of Unbonding Pausing from ICS","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"At the end of last year, we looked into simplifying ICS by removing one of the three message types – the VSCMaturedPackets. The VSCMaturedPackets are sent by consumer chains to acknowledge that their unbonding period elapses and the corresponding stake on the provider (i.e., the Cosmos Hub) can be unlocked. Consequently, the VSCMaturedPackets add a dependency between the liveness of undelegation operations on the Hub and the liveness of consumer chains. We refer to this as ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"unbonding pausing","nodeType":"text"},{"data":{},"marks":[],"value":". For example, if the VSCMaturedPackets from one of the consumer chains are delayed sufficiently long, then ATOM delegators will need to wait for more than three weeks to undelegate their ATOMs.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"In February, we published a blog post — ","nodeType":"text"},{"data":{"uri":"https://informal.systems/blog/learning-to-live-with-unbonding-pausing"},"content":[{"data":{},"marks":[],"value":"Learning to Live with “Unbonding Pausing”","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" — describing our understanding at that time on why VSCMaturedPackets are necessary for the system's security. In a nutshell, the reasoning was the security model of IBC light clients. However, this analysis overlooked an inconsistency between the original design of the ICS protocol and the ICS implementation. The original ICS protocol guarantees the following property that is needed for IBC client verification:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"The stake securing a consumer chain is locked until the unbonding period of that consumer chain elapses.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"This means that if the consumer chain halts, the unlocking of that stake will be delayed. Moreover, if the chain is removed, the stake can never be unlocked. This is not feasible in practice. Thus, in the ICS implementation, a halted consumer chain is eventually removed from ICS, and once a consumer chain is removed, the stake securing it is eventually unlocked. Note that a consumer chain must be halted for weeks before this happens. The ICS implementation relies on more synchrony assumptions than the ICS protocol. For more details on this inconsistency, check out the Context section of ","nodeType":"text"},{"data":{"uri":"https://cosmos.github.io/interchain-security/adrs/adr-018-remove-vscmatured"},"content":[{"data":{},"marks":[],"value":"ADR 018","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"To address this inconsistency, we split the work in two parts.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"First, we remove the VSCMaturedPackets. The reason is twofold. First, VSCMaturedPackets provides a \"false\" sense of correctness concerning synchrony assumptions. Second, VSCMaturedPackets add considerable complexity to the ICS protocol, i.e., an extra message plus the pausing of unbonding operations that can affect the user experience. The changes necessary for this removal are described in ","nodeType":"text"},{"data":{"uri":"https://cosmos.github.io/interchain-security/adrs/adr-018-remove-vscmatured"},"content":[{"data":{},"marks":[],"value":"ADR 018","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". The Cosmos Hub v20 upgrade will contain the ","nodeType":"text"},{"data":{"uri":"https://cosmos.github.io/interchain-security/adrs/adr-018-remove-vscmatured#provider-changes-r1"},"content":[{"data":{},"marks":[],"value":"provider-side changes","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". Once the Cosmos Hub is upgraded, we are going to release the ","nodeType":"text"},{"data":{"uri":"https://cosmos.github.io/interchain-security/adrs/adr-018-remove-vscmatured#consumer-changes-r2"},"content":[{"data":{},"marks":[],"value":"consumer-side changes","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" that will remove the VSCMaturedPackets completely.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Second, we introduce ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/interchain-security/pull/2250"},"content":[{"data":{},"marks":[],"value":"Consumer Chain IBC clients","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". These are ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/ibc-go/issues/5112"},"content":[{"data":{},"marks":[],"value":"IBC conditional clients","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" that enable a third-party chain to verify the state of a consumer chain by querying the provider (i.e., the Cosmos Hub) for the status of the locked stake that secures the consumer chain. For more details, check out ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/interchain-security/pull/2250"},"content":[{"data":{},"marks":[],"value":"ADR 021","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"Forge — Implementation Phase","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[{"type":"italic"}],"value":"Forge","nodeType":"text"},{"data":{},"marks":[],"value":", is a comprehensive front-end platform designed to streamline the deployment of new projects as Consumer Chains. This initiative aims to dramatically simplify the process of launching and managing Consumer Chains within the Cosmos ecosystem.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We completed the signaling phase for Forge. We thank the Cosmos Hub community for voting on ","nodeType":"text"},{"data":{"uri":"https://www.mintscan.io/cosmos/proposals/947"},"content":[{"data":{},"marks":[],"value":"the signaling proposal","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We also made significant progress towards launching Forge, focusing on the ","nodeType":"text"},{"data":{"uri":"https://forum.cosmos.network/t/proposal-947-voting-chips-signaling-phase-permissionless-ics-frontend/14161"},"content":[{"data":{},"marks":[],"value":"delegator experience","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" that will enable Cosmos Hub users to see the list of validators opted in to each Consumer Chain and delegate their ATOMs to them directly. The plan is to launch Forge together with the release of Permissionless ICS (i.e., the v20 Cosmos Hub upgrade).","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Hydro — Signaling and Implementation Phases","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"","nodeType":"text"},{"data":{"uri":"https://forum.cosmos.network/t/atom-wars-introducing-the-hydro-auction-platform/13842"},"content":[{"data":{},"marks":[],"value":"Hydro","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" is a bidding and governance platform for efficient deployment of liquidity across the Interchain and an important part of the ","nodeType":"text"},{"data":{"uri":"https://forum.cosmos.network/t/the-atom-wars-a-new-strategy-for-liquidity-injections/13122"},"content":[{"data":{},"marks":[],"value":"ATOM Wars strategy","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". Throughout the last month, we made significant progress towards the Hydro launch.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We published a revised version of the ","nodeType":"text"},{"data":{"uri":"https://forum.cosmos.network/t/atom-wars-seeding-hydros-buckets/"},"content":[{"data":{},"marks":[],"value":"forum post on Seeding Hydro’s buckets","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" that takes into account the feedback received from the Cosmos Hub community. The new blog post — ","nodeType":"text"},{"data":{"uri":"https://forum.cosmos.network/t/atom-wars-re-routing-pol-deployments-through-hydro/14269"},"content":[{"data":{},"marks":[],"value":"ATOM Wars: Re-routing PoL deployments through Hydro","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" — is a signaling proposal for rerouting the existing protocol-owned liquidity deployments to the Hydro committee instead of exporting any additional funds from the Cosmos Hub community pool. The new blog post also proposed the following changes to the Hydro contract: dynamic LST buckets based on market demands and locking of ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/cosmos-sdk/blob/v0.50.9-lsm/docs/architecture/adr-061-liquid-staking.md"},"content":[{"data":{},"marks":[],"value":"Liquid Staking Module (LSM) shares","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" (i.e., semi-fungible derivatives of staked ATOMs) instead of stATOM for voting. We submitted the ","nodeType":"text"},{"data":{"uri":"https://www.mintscan.io/cosmos/proposals/955"},"content":[{"data":{},"marks":[],"value":"signaling proposal on-chain","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We completed adapting the Hydro contract to use LSM shares instead of stATOM. A major complexity in this work is that shares from different validators are not fungible, and in particular different validators shares can be worth different amounts of underlying, staked ATOM, depending on whether validators were ever slashed before. We split the work on integrating the LSM shares into the Hydro contract into two parts:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"We adapted the Hydro contract to handle multiple different voting tokens with different weights. This involves storing the individual token-to-power ratios, which we then take into account when computing the voting power of users and the scores of proposals.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"We integrated Neutrons ","nodeType":"text"},{"data":{"uri":"https://docs.neutron.org/neutron/modules/interchain-queries/overview/"},"content":[{"data":{},"marks":[],"value":"Interchain Queries","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" in order to let the Hydro contract (deployed on Neutron) obtain the ratio of shares to underlying staked ATOM from the Cosmos Hub.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"The implementation of both parts and internal testing of the modified contract was successfully completed. As a result, we started testing the contract and the integration with the Hydro front-end platform.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"What This Enables","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"This month's developments further strengthen the Cosmos Hub's position as the cornerstone of the Interchain ecosystem:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Cutting-Edge Technology:","nodeType":"text"},{"data":{},"marks":[],"value":" We've positioned the Cosmos Hub as the reference chain in the Interchain by upgrading to the latest Interchain Stack versions, enabling faster feature adoption across the ecosystem.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Streamlined Chain Deployment","nodeType":"text"},{"data":{},"marks":[],"value":": Permissionless ICS and Forge significantly lower entry barriers for new projects, fostering innovation within the Cosmos ecosystem. Enhanced Participation: ICS with Inactive Validators broadens the validator base, improving decentralization and security.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Improved User Experience: ","nodeType":"text"},{"data":{},"marks":[],"value":"Removing Unbonding Pausing from ICS simplifies operations and enhances reliability for ATOM holders.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Optimized Liquidity: ","nodeType":"text"},{"data":{},"marks":[],"value":"Hydro's imminent launch creates a more flexible mechanism for liquidity deployment across the Interchain.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"These advancements collectively reinforce the Cosmos Hub's role as the premier platform for launching and managing blockchain projects. We're excited about these new capabilities and look forward to continued growth and innovation in the coming months.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"contentfulURL":"https://app.contentful.com/spaces/p79kctcd7ahy/entries/70Q1E1T2IlfPxYBtZZMS8z"},{"featureImage":"$4:props:posts:30:featureImage","date":"2024-08-24","title":"Everything You Need to Know About the Cosmos Hub v19 Upgrade","slug":"cosmos-hub-v19-upgrade","categories":["Engineering"],"authors":["Devashri Kulwal"],"keywords":"Cosmos Hub v19\nupgrade\nblockchain developers\ndapps\ninterchain\nvalidators\ngovernance \nblockchain technology","excerpt":{"nodeType":"document","data":{},"content":[{"nodeType":"paragraph","data":{},"content":[{"nodeType":"text","value":"Cosmos Hub v19 upgrade integrates latest Interchain Stack versions including Cosmos SDK v0.50 and IBC v8.4.0.","marks":[],"data":{}}]}]},"includeTableOfContents":true,"introduction":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"The Cosmos Hub has successfully upgraded to ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/gaia/releases"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Gaia v19","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", making Hub the reference chain for the Interchain Stack's latest and greatest innovations. (You can read the forum post ","nodeType":"text"},{"data":{"uri":"https://forum.cosmos.network/t/proposal-948-voting-gaia-v19-software-upgrade/14134"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"here","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".)\n\nThis update is not just about minor tweaks; it's a comprehensive overhaul to enhance efficiency, security, and functionality of the Cosmos Hub, making it better equipped to handle the demands of the rapidly growing interchain ecosystem.\n\nThe Hub is now integrated with the latest versions of the Interchain Stack:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Cosmos SDK v.0.50","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"IBC v8.4.0","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"CometBFT v0.38.11","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Interchain Security v5.1.1","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"body":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Key changes and features ","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Cosmos SDK v.0.50","nodeType":"text"},{"data":{},"marks":[],"value":"\n\nOne of the most anticipated aspects of this upgrade is the integration of Cosmos SDK v0.50. \n\nIn collaboration with Binary Builders, this version is a major milestone, bringing several performance enhancements and developer focused improvements. It reduces coding efforts, enhances data access speeds, and boosts overall efficiency - critical for developers building on the Cosmos Hub. \n\nIt unlocks a smoother and faster development process, enabling more robust and scalable applications within the Cosmos ecosystem.\n","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"IBC v8.4.0","nodeType":"text"},{"data":{},"marks":[],"value":"\n\nThe Inter-Blockchain Communication (IBC) protocol gets a significant boost with this version.\n\nIBC is a feature of Cosmos that allows blockchains to talk to each other. Chains that speak IBC can share any type of data as long as it's encoded in bytes, enabling the industry’s most feature-rich cross-chain interactions.\n\nThe standout feature of this upgrade is ","nodeType":"text"},{"data":{"uri":"https://ibc.cosmos.network/main/ibc/channel-upgrades/"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"channel upgradability","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", which allows chains to leverage new application and channel features without having to create new channels or perform a network-wide upgrade. This flexibility is particularly beneficial for developers and users, ensuring that the Cosmos network can evolve rapidly without disruptions.\n","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"CometBFT v0.38.11","nodeType":"text"},{"data":{},"marks":[],"value":"\n\nThis update includes ","nodeType":"text"},{"data":{"uri":"https://informal.systems/blog/abci-v2-unlocks-this"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"ABCI++","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" (Application BlockChain Interface), which provides greater consensus flexibility. The inclusion of the Vote Extension feature means that validators can now perform additional actions beyond just validating blocks. \n\nThis is a crucial step towards enhancing the overall security and functionality of the Cosmos Hub, particularly in maintaining network consensus under various conditions.\n","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Interchain Security v5.1.1","nodeType":"text"},{"data":{},"marks":[],"value":"\n\nThis version of ICS is fully compatible with the latest versions of the Cosmos SDK and CometBFT. This ensures smoother integration and operation across the Cosmos ecosystem, thereby enhancing the security and reliability of the interchain services that the Cosmos Hub supports.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"ordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"Why does this upgrade matter? ","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"The Cosmos Hub v19 upgrade is a critical step forward for the Cosmos ecosystem. By integrating the latest versions of its core technologies—Cosmos SDK, IBC, CometBFT, and Interchain Security—the upgrade ensures that the Hub remains at the forefront of innovation. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The ability to upgrade channels without disrupting the network (thanks to IBC v8.4.0) and the added consensus flexibility with CometBFT v0.38.11, is beneficial to developers and projects looking to build and deploy decentralized applications that require both robustness and agility. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"In conclusion, the Cosmos Hub v19 upgrade is not just an incremental update but a substantial enhancement that will drive the next wave of growth and innovation within the Cosmos ecosystem. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Whether you're a developer, a validator, or a holder, this upgrade brings tangible benefits that will make the Cosmos Hub more efficient, secure, and ready for the future of blockchain technology.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Launch your chain today","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"We are continually making it easier for developers to launch chains as painlessly as possible. With Forge, an upcoming Hub product, you can launch your chain within minutes!","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"For more information on how to get started with it, explore the official ","nodeType":"text"},{"data":{"uri":"https://hub.cosmos.network/main"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"documentation","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" and join the vibrant ","nodeType":"text"},{"data":{"uri":"https://forum.cosmos.network"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"community","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" making a difference in the interchain space.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Welcome to the best place to launch a chain. ","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"contentfulURL":"https://app.contentful.com/spaces/p79kctcd7ahy/entries/5U1RPTD2mIaZKrjlY9u9BO"},{"featureImage":"$4:props:posts:29:featureImage","date":"2024-08-17","title":"Cosmos Hub Update July 2024: Forge, Hydro & New ICS Features","slug":"cosmos-hub-update-july-2024","categories":["Engineering"],"authors":["Brian Truax","Marius Poke"],"keywords":"Cosmos Hub update July 2024\nCosmos Hub v18 upgrade\nGaia v19\nPermissionless ICS\nInactive Hub Validators\nICS Fault Resolutions\nPermissionless ICS Frontend\nHydro Liquidity\nCosmos community upgrades\nCosmos governance proposals","excerpt":{"nodeType":"document","data":{},"content":[{"nodeType":"paragraph","data":{},"content":[{"nodeType":"text","value":"July 2024 Cosmos Hub developments including Forge launch, Hydro progress, and new ICS feature implementations.","marks":[],"data":{}}]}]},"includeTableOfContents":false,"introduction":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"It’s time for the usual update from the Informal Systems’ Cosmos Hub team. Here are some of the highlights:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Had our quarterly meeting with the oversight committee.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Coordinated the Cosmos Hub v17.3 emergency upgrade.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Coordinated the Cosmos Hub v18 upgrade.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Completed the integration phase and started the testnet phase for Gaia v19.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Working on the signaling and implementation phases for Permissionless ICS.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Completed the implementation phase for ICS with Inactive Hub Validators.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Started the discussion and signaling phases for ICS with Fault Resolutions.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Working on the signaling and implementation phases for Permissionless ICS Frontend.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Made significant progress towards the Hydro launch.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"Note that we use ","nodeType":"text"},{"data":{"uri":"https://forum.cosmos.network/t/cosmos-hub-improvement-process-chips-revision/13730"},"content":[{"data":{},"marks":[],"value":"CHIPs","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" to track the progress of our work. Hence, throughout this update, we refer to different phases of the CHIPs framework.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"body":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Oversight Committee Quarterly Meeting","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"On July 18th, the Hub teams at Informal and Hypha met with the oversight committee. The purpose of the meeting was to review the work done in Q2 and discuss our Q3 plans. We published a ","nodeType":"text"},{"data":{"uri":"https://forum.cosmos.network/t/informal-hub-team-q2-24-retro-q3-24-plan/14158"},"content":[{"data":{},"marks":[],"value":"summary of the meeting","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" on the Hub forum. We would like to thank the members of the oversight committee for their time and for engaging in discussions. Their feedback is invaluable as it enables us to grow and continue improving.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Cosmos Hub v17.3 Emergency Upgrade","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"In the first week of July, the Cosmos Hub underwent an emergency upgrade to fix a bug in the ICS provider module. The bug consisted of a missing check for the minimum height of double-voting evidence from Consumer Chains. As a result, there was a risk of validators getting slashed for old infractions (e.g., committed one year ago). To mitigate this risk, the binaries with the fix were distributed privately to 1/3+ of the network. Once 1/3+ upgraded and the bug could no longer be triggered, we cut a public release (i.e., Gaia ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/gaia/releases/tag/v17.3.0"},"content":[{"data":{},"marks":[],"value":"v17.3.0","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":") and coordinated with the rest of the network to avoid liveness issues (i.e., we made sure 2/3+ of the network use v17.3.0). We thank the validator community for a successful upgrade.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Cosmos Hub v18 Upgrade","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"On July 17th, the Cosmos Hub upgraded to Gaia ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/gaia/releases/tag/v18.1.0"},"content":[{"data":{},"marks":[],"value":"v18.1.0","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". This is a major upgrade that added the following features to the Cosmos Hub:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Permissioned CosmWasm (as per ","nodeType":"text"},{"data":{"uri":"https://www.mintscan.io/cosmos/proposals/895"},"content":[{"data":{},"marks":[],"value":"prop 895","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":") enables the governance-gated deployment of CosmWasm contracts. See ","nodeType":"text"},{"data":{"uri":"https://forum.cosmos.network/t/discussion-hub-cosmwasm-guidelines/13788"},"content":[{"data":{},"marks":[],"value":"this forum discussion","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" for more details on what contracts should be deployed on the Hub.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Skip's ","nodeType":"text"},{"data":{"uri":"https://github.com/skip-mev/feemarket"},"content":[{"data":{},"marks":[],"value":"feemarket module","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" (as per ","nodeType":"text"},{"data":{"uri":"https://www.mintscan.io/cosmos/proposals/842"},"content":[{"data":{},"marks":[],"value":"prop 842","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":") enables the dynamic adjustment of the base transaction fee based on the block gas utilization. This module replaced the ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"","nodeType":"text"},{"data":{"uri":"https://hub.cosmos.network/v17.1.0/architecture/adr/adr-002-globalfee"},"content":[{"data":{},"marks":[],"value":"x/globalfee module","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"","nodeType":"text"},{"data":{"uri":"https://docs.cosmos.network/v0.50/build/modules/gov#expedited-proposals"},"content":[{"data":{},"marks":[],"value":"Expedited proposals","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" (as per ","nodeType":"text"},{"data":{"uri":"https://www.mintscan.io/cosmos/proposals/926"},"content":[{"data":{},"marks":[],"value":"prop 926","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":") enable governance proposals with a shorter voting period (i.e., one week instead of two), but with a higher tally threshold (i.e., 66.7% of Yes votes for the proposal to pass) and a higher minimum deposit (i.e., 500 ATOMs instead of the 250 for regular proposals). For now, only ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"MsgSoftwareUpgrade ","nodeType":"text"},{"data":{},"marks":[],"value":"and ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"MsgCancelUpgrade ","nodeType":"text"},{"data":{},"marks":[],"value":"can be expedited.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/interchain-security/releases/tag/v4.3.0"},"content":[{"data":{},"marks":[],"value":"ICS v4.3.0","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" adds a series of improvements to ICS including adding the ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"ConsumerModification ","nodeType":"text"},{"data":{},"marks":[],"value":"gov proposal that enables Consumer Chains to update the ","nodeType":"text"},{"data":{"uri":"https://cosmos.github.io/interchain-security/v4.3.0/features/power-shaping"},"content":[{"data":{},"marks":[],"value":"power shaping","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" parameters after launch.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"We thank the Cosmos Hub community for voting on the ","nodeType":"text"},{"data":{"uri":"https://www.mintscan.io/cosmos/proposals/937"},"content":[{"data":{},"marks":[],"value":"software upgrade proposal","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" and the validator community for a smooth upgrade with around 13 minutes of downtime.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Gaia v19 — Integration and Testnet Phases","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"We completed the integration phase for Gaia v19, which will upgrade the Cosmos Hub to the latest versions of the Interchain Stack:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Cosmos SDK v0.50 — the Cosmos Hub will use ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/cosmos-sdk/releases/tag/v0.50.9-lsm"},"content":[{"data":{},"marks":[],"value":"v0.50.9-lsm","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", a special Cosmos SDK branch with support for LSM","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"IBC ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/ibc-go/releases/tag/v8.4.0"},"content":[{"data":{},"marks":[],"value":"v8.4.0","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"CometBFT ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/releases/tag/v0.38.9"},"content":[{"data":{},"marks":[],"value":"v0.38.9","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Interchain Security ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/interchain-security/releases/tag/v5.1.1"},"content":[{"data":{},"marks":[],"value":"v5.1.1","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Packet Forward Middleware ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/ibc-apps/releases/tag/middleware%2Fpacket-forward-middleware%2Fv8.0.2"},"content":[{"data":{},"marks":[],"value":"v8.0.2","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"IBC Rate Limiting ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/ibc-apps/releases/tag/modules%2Frate-limiting%2Fv8.0.0"},"content":[{"data":{},"marks":[],"value":"v8.0.0","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Fee Market ","nodeType":"text"},{"data":{"uri":"https://github.com/skip-mev/feemarket/releases/tag/v1.0.4"},"content":[{"data":{},"marks":[],"value":"v1.0.4","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"CosmWasm/wasmd to ","nodeType":"text"},{"data":{"uri":"https://github.com/CosmWasm/wasmd/releases/tag/v0.51.0"},"content":[{"data":{},"marks":[],"value":"v0.51.0","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"This is part of a larger initiative to make the ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"},{"type":"italic"}],"value":"Cosmos Hub the reference chain for the Interchain Stack","nodeType":"text"},{"data":{},"marks":[],"value":" and is a collaboration with Binary Builders. The goal of this initiative is to improve the upgrade process to newer versions of the Interchain Stack, which will consequently improve the adoption within the Cosmos ecosystem. Additionally, the Cosmos Hub community will gain access to the new Interchain Stack features sooner, resulting in faster product development. Finally, by being on par with the latest releases of the Interchain Stack, the Cosmos Hub community can more actively contribute to the development of the Interchain Stack by asking for new features to be added in the next releases.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We also started the testnet phase. Throughout this month, we cut a series of release candidates for Gaia v19 (","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/gaia/releases/tag/v19.0.0-rc3"},"content":[{"data":{},"marks":[],"value":"v19.0.0-rc3","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" is the latest) that were used to upgrade the public testnets. This work entailed fixing several integration bugs found during testing.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We posted the ","nodeType":"text"},{"data":{"uri":"https://forum.cosmos.network/t/proposal-xxx-draft-gaia-v19-software-upgrade/14134"},"content":[{"data":{},"marks":[],"value":"software upgrade proposal on the Cosmos Hub forum","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", so please join the discussion there. Next, we will submit it on-chain as an expedited proposal (i.e., the voting period will be one week instead of two), and if it passes governance, we will upgrade the mainnet.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Permissionless ICS — Signaling and Implementation Phases","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"Permissionless ICS is the main feature targeted for Gaia v20, and it will enable anyone to ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"permissionlessly","nodeType":"text"},{"data":{},"marks":[],"value":" launch an opt-in Consumer Chain on the Cosmos Hub. Given that validators are free to choose whether they want to run a given opt-in Consumer Chain, it is only natural to also enable projects to launch as opt-in Consumer Chains by simply submitting transactions to the Cosmos Hub and, thus, avoiding the need to go through the process of governance. Note that Top N Consumer Chains will still need to go through governance.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We completed the ","nodeType":"text"},{"data":{"uri":"https://cosmos.github.io/interchain-security/adrs/adr-019-permissionless-ics"},"content":[{"data":{},"marks":[],"value":"ADR","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" detailing the main design decisions and published a ","nodeType":"text"},{"data":{"uri":"https://forum.cosmos.network/t/chips-signaling-phase-permissionless-ics/14215"},"content":[{"data":{},"marks":[],"value":"signaling proposal","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" on the Cosmos Hub forum. Next, we will submit the signaling proposal on-chain.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We have also started working on the ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/interchain-security/tree/feat/permissionless"},"content":[{"data":{},"marks":[],"value":"implementation,","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" and we are looking into a third-party audit.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"ICS with Inactive Validators — Implementation Phase","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"ICS with Inactive Hub Validators is another feature targeted for Gaia v20, and it will enable validators from outside the Hub’s active set to validate on Consumer Chains. This feature brings the following benefits to ICS:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"It reduces the entry barrier for projects to launch as Consumer Chains since more validators will be allowed to opt in.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"It enables validators outside the Hub’s active set to compete by providing their services to interesting projects.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"It reduces the risk of all the validators of a Consumer Chain opting out, which would require the chain to leave ICS.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"We completed the ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/interchain-security/pull/2079"},"content":[{"data":{},"marks":[],"value":"implementation","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" and are working with Simply Staking to source ","nodeType":"text"},{"data":{"uri":"https://www.mintscan.io/cosmos/proposals/943"},"content":[{"data":{},"marks":[],"value":"a third-party audit","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". If you have feedback or questions about the audit, you can join the ","nodeType":"text"},{"data":{"uri":"https://forum.cosmos.network/t/proposal-943-vote-on-chain-funding-ics-with-inactive-validators-3rd-party-audit/14106"},"content":[{"data":{},"marks":[],"value":"discussion on the forum","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"ICS with Fault Resolutions (aka Intersubjective Faults) — Discussion and Signaling Phases","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"We published a ","nodeType":"text"},{"data":{"uri":"https://forum.cosmos.network/t/preventing-intersubjective-faults-in-ics/14103"},"content":[{"data":{},"marks":[],"value":"forum post","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" outlining the concept of Fault Resolutions, also known as Intersubjective Faults (as defined by the ","nodeType":"text"},{"data":{"uri":"https://docs.eigenlayer.xyz/assets/files/EIGEN_Token_Whitepaper-0df8e17b7efa052fd2a22e1ade9c6f69.pdf"},"content":[{"data":{},"marks":[],"value":"EIGEN paper","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"), as a solution for punishing validators misbehaving on Consumer Chains for offenses other than double signing. The approach consists of three steps:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"first, define precisely what constitutes various types of intersubjective faults;","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"second, have a social contract in place that validators committing these faults should be punished by a hard fork that takes away their stake in the worst-case scenario;","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"third, build a governance proposal that slashes and tombstones them without needing a hard fork unless governance is compromised.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"If you have feedback or questions, please join the ","nodeType":"text"},{"data":{"uri":"https://forum.cosmos.network/t/preventing-intersubjective-faults-in-ics/14103"},"content":[{"data":{},"marks":[],"value":"discussion on the forum","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We also started working on an ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/interchain-security/pull/2051"},"content":[{"data":{},"marks":[],"value":"ADR","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" detailing the main design decisions. Next, we plan to publish a signaling proposal on the Cosmos Hub forum and then submit it on-chain.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"ICS v4.4","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"We released ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/interchain-security/releases/tag/v4.4.0"},"content":[{"data":{},"marks":[],"value":"ICS v4.4.0","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", a new version that deprecates the ","nodeType":"text"},{"data":{"uri":"https://cosmos.github.io/interchain-security/adrs/adr-009-soft-opt-out"},"content":[{"data":{},"marks":[],"value":"Soft Opt-out feature","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", which allows the bottom x% of the provider validators to opt out of validating Consumer Chains. With the introduction of ","nodeType":"text"},{"data":{"uri":"https://cosmos.github.io/interchain-security/adrs/adr-015-partial-set-security"},"content":[{"data":{},"marks":[],"value":"Partial Set Security (PSS)","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", validating on opt-in Consumer Chains is discretional, while validators outside of the top N% of the voting power are not required to validate on TopN Consumer Chains. Consequently, the Soft Opt-out feature is no longer required. Note that the deprecation of the Soft Opt-out feature is also part of ICS 5.1.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Permissionless ICS Frontend — Signaling and Implementation Phases","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"On July 7th, at the ","nodeType":"text"},{"data":{"uri":"https://lu.ma/6do92q5o?tk=1kZqzx"},"content":[{"data":{},"marks":[],"value":"Cosmos Hub @ EthCC event","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" during the \"Launching on Interchain Security\" workshop, we successfully demoed ","nodeType":"text"},{"data":{"uri":"https://demo-ics.vercel.app"},"content":[{"data":{},"marks":[],"value":"Permissionless ICS Frontend v0","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", an early Alpha build. Permissionless ICS Frontend is a comprehensive front-end platform designed to streamline the deployment of new projects as Consumer Chains. This initiative aims to dramatically simplify launching and managing Consumer Chains within the Cosmos ecosystem.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We also published a ","nodeType":"text"},{"data":{"uri":"https://forum.cosmos.network/t/chips-signaling-phase-forge-ics-launchpad/14161"},"content":[{"data":{},"marks":[],"value":"forum post","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" describing the issues Permissionless ICS Frontend will address, and the user experiences it will provide — for delegators, validators, and chain developers. Currently, we are focusing on the delegator experience for the launch. This will enable the following functionalities:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Chain listing — users will be able to filter chains by project phase, with additional filtering and search functionality planned for future updates.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Spam filtering — only Consumer Chains with at least one active Hub validator opted in will be listed.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Validators — ATOM delegators will be to see a list of validators opted in to each chain and delegate to them directly.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Badges — ATOM delegators will be able to engage with other applications, such as Hydro, a Cosmos Hub ATOM liquidity platform.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"Hydro","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"","nodeType":"text"},{"data":{"uri":"https://forum.cosmos.network/t/atom-wars-introducing-the-hydro-auction-platform/13842"},"content":[{"data":{},"marks":[],"value":"Hydro","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" is a bidding and governance platform for efficient deployment of liquidity across the Interchain and an important part of the ","nodeType":"text"},{"data":{"uri":"https://forum.cosmos.network/t/the-atom-wars-a-new-strategy-for-liquidity-injections/13122"},"content":[{"data":{},"marks":[],"value":"ATOM Wars strategy","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". Throughout the last month, we made significant progress towards the Hydro launch.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"We fixed the issues in the Hydro contract found during the third-party audit by Oak Security. For details, see the ","nodeType":"text"},{"data":{"uri":"https://github.com/oak-security/audit-reports/blob/main/Hydro/2024-07-30%20Audit%20Report%20-%20Hydro%20v1.0.pdf"},"content":[{"data":{},"marks":[],"value":"audit report","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"We continue developing a front-end platform for Hydro to enable projects to bid for liquidity and users to lock their staked ATOMs to vote on these bids.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"We are coordinating with the DAODAO team to deploy DAODAO on the Cosmos Hub. This will allow the Hydro committee to use DAODAO on the Hub and, consequently, simplify the deployment of liquidity. You can join the ","nodeType":"text"},{"data":{"uri":"https://forum.cosmos.network/t/draft-proposal-authorize-dao-dao-deployment/14143"},"content":[{"data":{},"marks":[],"value":"discussion on the forum","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" or vote on the ","nodeType":"text"},{"data":{"uri":"https://www.mintscan.io/cosmos/proposals/944"},"content":[{"data":{},"marks":[],"value":"governance proposal","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"We published a ","nodeType":"text"},{"data":{"uri":"https://forum.cosmos.network/t/atom-wars-seeding-hydros-buckets/14147"},"content":[{"data":{},"marks":[],"value":"funding proposal","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" on the Cosmos Hub forum to request approval to transfer 1 million ATOMs from the Cosmos Hub community pool to the Hydro committee. The proposal describes how the ATOMs will be used — to seed an ATOM liquidity bucket and a stATOM liquidity bucket — the members of the Hydro committee and their roles. We want to thank everyone who participated in the discussion and provided feedback. We already started adapting the proposal to include the received feedback.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"We started adapting the Hydro contract to allow users to lock ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/cosmos-sdk/blob/v0.50.9-lsm/docs/architecture/adr-061-liquid-staking.md"},"content":[{"data":{},"marks":[],"value":"LSM tokenized shares","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":" (i.e., semi-fungible derivatives of staked ATOMs) instead of stATOMs. This will make Hydro more robust as it will not depend on any liquid staking platform.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"What This Enables","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"This month's developments further solidify the Cosmos Hub's position as the best place to launch a chain, with:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Enhanced Security and Stability: Swift responses to potential vulnerabilities through emergency upgrades demonstrate the community’s commitment to maintaining a secure and reliable network.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"The latest of the Interchain Stack: By upgrading to the latest versions of the Interchain Stack, we're positioning the Cosmos Hub as a reference chain, enabling faster feature adoption across the ecosystem.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Expanded Participation: The implementation of ICS with Inactive Validators broadens the validator base, enhancing decentralization and security.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Streamlined Chain Deployment: Permissionless ICS Frontend and Permissionless ICS significantly lower the barriers to entry for new projects, fostering innovation around the Cosmos Hub.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Optimized Liquidity: With Hydro's imminent launch and the proposed funding, we're creating a powerful mechanism for efficient liquidity deployment. This is a major pain point for projects in Cosmos.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"These advancements collectively reinforce the Cosmos Hub's role as the premier platform for launching and managing blockchain projects. We're excited about the new capabilities these features bring and look forward to continued growth and innovation in the coming months.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"contentfulURL":"https://app.contentful.com/spaces/p79kctcd7ahy/entries/l5X9edjYIk3h6jXlThxub"},{"featureImage":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"6p6I2QEwRoaZsmT7nmHki","type":"Asset","createdAt":"2024-08-13T21:30:04.552Z","updatedAt":"2024-08-13T22:15:55.979Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":9,"revision":3,"locale":"en-US"},"fields":{"title":"Blog Starknet","description":"","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/6p6I2QEwRoaZsmT7nmHki/43f0d9c2695c4c0b22df2145cdce1a52/Blog_Starknet.jpg","details":{"size":461737,"image":{"width":1920,"height":1080}},"fileName":"Blog_Starknet.jpg","contentType":"image/jpeg"}}},"date":"2024-07-24","title":"Interchain, meet Starknet","slug":"interchain-meet-starknet","categories":["Malachite"],"authors":["Adi Seredinschi"],"keywords":"IBC protocol\nStarknet\nblockchain interoperability\ndecentralized sequencer\nTendermint\nEthereum Layer 2\nprotocol integration\ninterchain connectivity\nzero-knowledge proofs\ncross-chain liquidity","excerpt":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Building Starknet's Decentralized Sequencer with Malachite Consensus.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"includeTableOfContents":true,"body":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"What is better than ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"one","nodeType":"text"},{"data":{},"marks":[],"value":" ecosystem of ambitious teams, talented individuals, and bleeding-edge technology? ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"Two","nodeType":"text"},{"data":{},"marks":[],"value":" such ecosystems. In this post, we provide the story of collaboration across the Starknet and interchain ecosystems that has been flourishing for a few months.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The organizations involved in this collaboration include StarkWare Industries, Starknet Foundation, and Informal Systems. At Informal specifically, we are using our expertise in productionizing and operating app-chains toward enabling Starknet to achieve two primary objectives: production-grade (1) decentralization and (2) interoperability.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"In this post, we will cover two main points. First, we provide some background on how this collaboration emerged. Second, we will describe the strategic importance this work has both for the Starknet and interchain ecosystems.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Brief background","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"This collaboration started taking shape in the late spring of 2023 with technical discussions. The topic was trade-offs in the ","nodeType":"text"},{"data":{"uri":"https://arxiv.org/abs/1807.04938"},"content":[{"data":{},"marks":[],"value":"Tendermint consensus algorithm","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", seen from the perspective and requirements for decentralizing Starknet L2. Some of the original designs that the StarkWare team drafted on this topic can be seen on the Starknet forum, e.g., ","nodeType":"text"},{"data":{"uri":"https://community.starknet.io/t/simple-decentralized-protocol-proposal/99693"},"content":[{"data":{},"marks":[],"value":"here","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" and ","nodeType":"text"},{"data":{"uri":"https://community.starknet.io/t/starknet-decentralized-protocol-i-introduction/2671"},"content":[{"data":{},"marks":[],"value":"here","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". We brought to the table our expertise from maintaining ","nodeType":"text"},{"data":{"uri":"https://cometbft.com/"},"content":[{"data":{},"marks":[],"value":"CometBFT","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", which implemented the Tendermint algorithm. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Since then, the overlap in interests between the two teams has expanded, going beyond just the distributed algorithm details of Tendermint. The collaboration slowly grew over time to cover both decentralization protocol design and core engineering contributions for Starknet decentralization.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Presently, beyond the decentralized sequencer, we are also exploring how to apply our expertise in interoperability to expand the reach of Starknet applications and reduce ecosystem fragmentation through the IBC protocol. Let’s go into more detail in both of these areas.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Current status","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"1. Decentralized sequencer","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"We had two guiding properties for the design of the (decentralized) Starknet sequencer: fault-tolerance and censorship-resistance. Sequencer decentralization is an intense area of research across the broader industry, and it is important because it can ensure continuity — i.e., liveness — of transaction inclusion in L2 despite arbitrary failures, including censorship.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"As mentioned above, the work between StarkWare and Informal started by revisiting the Tendermint algorithm to ensure it caters to the needs of a decentralized sequencer in a ZK-based L2. To be more precise, by ZK we mean here validity proofs. We then proceeded to plan for shipping and productionizing such a sequencer. This is still ongoing.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"One key decision was that the most appropriate long-term solution for this sequencer would comprise multiple implementations of the protocol. This is essential for sequencer (node) diversity. Among these implementations, one is undergoing in Informal Systems. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"A core component of each of the sequencer implementations is the Tendermint consensus algorithm, which grants the ability to reach consensus on a value in a Byzantine-fault tolerant (BFT) setup. This is key for fault-tolerance of the sequencer. Another important property is censorship-resistance. This will be the subject of a future technical post, suffice to say that the sequencer is designed with the ability to reconfigure its set of nodes. So even if sequencer nodes might misbehave by censoring transactions, this set of nodes will reconfigure by shedding or adding nodes, as prescribed in the L1, the source of truth. Additionally, Tendermint is a ","nodeType":"text"},{"data":{"uri":"https://informal.systems/blog/tendermint-responsiveness"},"content":[{"data":{},"marks":[],"value":"responsive consensus protocol","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", ensuring that its latency depends on actual network delays, not on preset conservative time-bounds.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The codename for Informal’s implementation is “Malachite”. We have been writing it in Rust. It is feature-wise similar to the consensus reactor in CometBFT. But internal APIs, module boundaries, concurrency model, and testability in Malachite are heavily inspired by the lessons we have learned while contributing to, maintaining, and operating CometBFT (and previously Tendermint Core) in the last years.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We have focused engineering efforts in Malachite so far on iterating fast on a design that is easy to extend and grow, as well as formal modeling, testing, and edge case handling. As with any distributed protocol, the edge cases are the most important ones, and they bring the most complexity. We have modeled the initial system implementation in ","nodeType":"text"},{"data":{"uri":"https://github.com/informalsystems/quint"},"content":[{"data":{},"marks":[],"value":"Quint","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" and adapted the code to run model-based testing based on traces generated from Quint. The main two challenges we faced so far were as follows. First, maintaining Malachite lean and testable throughout the multiple design sprints, ensuring that its various components remain cleanly separated. Second, iterating on the decentralization protocol while maintaining a rigorous understanding of its details.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We have presented some of these ","nodeType":"text"},{"data":{"uri":"https://drive.google.com/file/d/1vs2I6Jayx7ORBgQXrd7asStZg8RN5ydJ/view?usp=sharing"},"content":[{"data":{},"marks":[],"value":"insights","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" and the approaches we took to mitigate these challenges at StarknetCC on July 10th. In that presentation, we have also provided a high-level view of a sequencer node built using Malachite, and an overview of protocol modeling in Quint. The diagram below is from the presentation we gave, and shows Malachite comprising three components: ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"VoteKeeper, Driver, and StateMachine","nodeType":"text"},{"data":{},"marks":[],"value":". These implement the Tendermint consensus algorithm. We call Malachite a ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"sequencer core ","nodeType":"text"},{"data":{},"marks":[],"value":"given its very concise and efficient footprint. The concurrency architecture relies on the actor model.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"5d5R9spPjIWQOf1IduME8g","type":"Asset","createdAt":"2024-07-19T07:18:40.762Z","updatedAt":"2024-07-19T07:18:40.762Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":7,"revision":1,"locale":"en-US"},"fields":{"title":"Starknet Sequencer Testing Node","description":"The implementation of a Starknet Sequencer Testing Node using Malachite.","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/5d5R9spPjIWQOf1IduME8g/23d00c8c9285010e9b7ff81d59a609fa/Screenshot_2024-07-19_at_09.18.03.png","details":{"size":233288,"image":{"width":1148,"height":808}},"fileName":"Screenshot 2024-07-19 at 09.18.03.png","contentType":"image/png"}}}},"content":[],"nodeType":"embedded-asset-block"},{"data":{},"content":[{"data":{},"marks":[],"value":"We plan to open-source Malachite with the sequencer node as it is taking more concrete shape and is ready to be demo-ed.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Side note: Malachite <> CometBFT.","nodeType":"text"},{"data":{},"marks":[],"value":" Malachite is complementary to CometBFT. Consider that CometBFT is the state-of-the-art BFT consensus engine, it is written in Go, and comes with batteries included for an extremely broad range of use-cases. In contrast, Malachite will cover the opposite part of the spectrum: It is an adaptable core enabling the building of a sequencer for highly-specialized modular stacks, with a targeted range of applicability, high-performance, built in Rust, with a small number of moving parts. Despite a smaller footprint, importantly, we are designing Malachite as a lean core that is easy to extend. Whereas CometBFT is akin to Swiss army knife, Malachite will be akin to a surgeon’s scalpel. Both CometBFT and Malachite seek to be reliable and offer long-term maintenance guarantees.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"2. Interoperability","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"The driving purpose of integrating IBC into Starknet is to enable application composability across the broader industry consisting of diverse L2s and L1s. As an open protocol, IBC is rapidly establishing itself as the interoperability standard, being used in ","nodeType":"text"},{"data":{"uri":"https://www.ibcprotocol.dev/"},"content":[{"data":{},"marks":[],"value":"115 chains in production","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" and enabling $30B+ in Annual Value Transfer. IBC will enable the flow of liquidity both ways between Starknet and the wider interchain, opening up avenues for collaboration across ecosystems.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"In this work, we are starting with a focus on the fungible token transfer application (ICS 020). On the Starknet side, we are exploring how to run the Rust IBC modules (","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/ibc-rs"},"content":[{"data":{},"marks":[],"value":"ibc-rs","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":") as a sidecar to the Starknet stack, and trying to identify how much of the IBC machinery exactly needs to be proven in Cairo. We have identified three approaches to integrate IBC, and the sidecar one seems most promising.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"On the interchain side, things are easier. The Cosmos SDK already integrates with IBC modules in Go (","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/ibc-go"},"content":[{"data":{},"marks":[],"value":"ibc-go","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"). Nonetheless, we are scoping carefully and preferring pragmatic choices. We are trying to leverage the solo machine IBC client, which makes it easier to start integrating, and is feasible thanks to the current Starknet sequencer design. As soon as Starknet upgrades to a decentralized sequencer, this light client will need to be migrated to a different model. As the most probable integration counterparties in the interchain, we plan to aim for Osmosis, Neutron, Stride, and/or Cosmos Hub. It is possible a CosmWasm will be a prerequisite, given that we plan to leverage the IBC Wasm client.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"On the relayer side, we plan to use ","nodeType":"text"},{"data":{"uri":"https://github.com/informalsystems/hermes/"},"content":[{"data":{},"marks":[],"value":"Hermes v1 line","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", a state of the art implementation of IBC relayer in Rust by Informal Systems. Eventually, as the integration with the decentralized sequencer will ramp up, we plan to transition to using the ","nodeType":"text"},{"data":{"uri":"https://github.com/informalsystems/hermes-sdk"},"content":[{"data":{},"marks":[],"value":"Hermes SDK","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". This will allow us to instantiate a specialized version of an IBC relayer that is specific to Starknet and meets the performance, stability, and feature criteria needed for this L2.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Conclusion","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"We’re excited about the possibilities to be unlocked with the collaboration we’re working on with Starknet. Feedback is a vital part of any strong development process so please reach out and let us know your thoughts on our work. The StarkWare and interchain team at Informal are committed to building and growing our respective ecosystems for the benefit of both users and developers.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Many thanks to Isabel Chi, Abdel Bakhta, and Josef Widder for insightful comments and suggestions on earlier drafts of this post.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"contentfulURL":"https://app.contentful.com/spaces/p79kctcd7ahy/entries/2RP50HgIvkCj2K6D8ao3ra"},{"featureImage":"$4:props:posts:25:featureImage","date":"2024-07-18","title":"CometBFT: Spam Mitigations and Mempool Improvement Plans","slug":"comet-p2p-spams-mitigations-plans","categories":["Engineering"],"authors":["Adi Seredinschi"],"keywords":"\"CometBFT mempool\nblockchain spam mitigation\nDOG gossip protocol\nquality of service\nByzantine fault tolerance\nTendermint consensus\nP2P networking\ntransaction dissemination\nCosmos SDK\nnetwork congestion\"","excerpt":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"CometBFT Spam Mitigation Strategies and Quality of Service Updates.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"includeTableOfContents":true,"introduction":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Summary:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"We describe the current spam mitigations existing in CometBFT.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"italic"},{"type":"bold"}],"value":"We provide two recommendations","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":": ","nodeType":"text"},{"data":{},"marks":[],"value":"We encourage application developers and node operators to use these existing mitigations for making their networks more resilient to spam or traffic surges. We also strongly recommend developers that use CometBFT v0.37 or older to transition to v0.38 and to plan transitioning to ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/releases"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"v1","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". The CometBFT team is available to actively contribute and support all users on both of these matters. You can find us on Slack, Telegram ","nodeType":"text"},{"data":{"uri":"https://t.me/CometBFT"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"https://t.me/CometBFT","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" or Discord ","nodeType":"text"},{"data":{"uri":"https://discord.gg/interchain"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"https://discord.gg/interchain","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" ","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"We end by describing the ongoing work to implement in future Comet versions: (i) quality of service guarantees, and (ii) a more efficient transaction dissemination algorithm called DOG.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"body":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Applications that build on CometBFT and the Cosmos SDK do not typically have, by default, built-in mitigations to deal with spam traffic. Such situations can lead to a network becoming congested and having unpredictable block times.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"There are various approaches to mitigate such problems today. Below we report on the set of mitigations that apply to CometBFT specifically. We also document our current and ongoing work through which we plan to introduce quality of service guarantees in future CometBFT releases and make the P2P layer more efficient in particular with regards to the transaction dissemination algorithm.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Current mitigations in CometBFT","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"To mitigate the impact of spam or traffic surges such as some chains have experienced in the recent period, CometBFT provides some avenues. Generally, CometBFT is a \"producer-consumer\" consensus engine system. The engine will be able to do advanced things such as treating transactions on a case-by-case basis, like Quality of Service (QoS) guarantees which are being implemented, described below. Even in the presence of such an advanced feature, the bottom line is that the application is the layer that understands how to throttle the production of spammy transactions, and how to differentiate transactions of various kinds by prioritizing among them.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"That being said, the first mitigation for app chains to mitigate spam is by reducing the allowed max block size. There was an advisory we published ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/security/advisories/GHSA-hq58-p9mv-338c"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"ASA-2023-002","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" towards the end of September 2023. Specifically, in that advisory we recommend operators to check the parameter `","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"BlockParams.MaxBytes","nodeType":"text"},{"data":{},"marks":[],"value":"` in the genesis file (","nodeType":"text"},{"data":{"uri":"https://docs.cometbft.com/v0.38/spec/abci/abci++_app_requirements#blockparamsmaxbytes"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"doc ref","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" for v0.38) to a smaller value than the default of 21MB. As a default value in Comet, we have reduced the value from 21 MB to 4 MB. We have also change the `","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"max_gas","nodeType":"text"},{"data":{},"marks":[],"value":"` parameter (","nodeType":"text"},{"data":{"uri":"https://docs.cometbft.com/v0.38/core/using-cometbft"},"content":[{"data":{},"marks":[],"value":"doc ref","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":") by default to a value of 10M (from a previous unbounded value of -1).","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Related to the `","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"BlockParams.MaxBytes","nodeType":"text"},{"data":{},"marks":[],"value":"` parameter, we have also advised in ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/security/advisories/GHSA-hq58-p9mv-338c"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"ASA-2023-002","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" that the `","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"timeout_propose","nodeType":"text"},{"data":{},"marks":[],"value":"` parameter (","nodeType":"text"},{"data":{"uri":"https://docs.cometbft.com/v0.38/core/configuration#consensus-timeouts-explained"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"doc ref","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":") should be computed using the maximum allowed block size as a reference. A larger maximum block size implies that a longer timeout for proposing is necessary.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Separately, we recommend that all nodes in a given network should have consistent values parameterized for the CometBFT mempool capacity and transaction size, across that network. These are the three parameters called `","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"mempool.size","nodeType":"text"},{"data":{},"marks":[],"value":"`, `","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"mempool.max_txs_bytes","nodeType":"text"},{"data":{},"marks":[],"value":"`, and `","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"mempool.max_tx_bytes","nodeType":"text"},{"data":{},"marks":[],"value":"` (","nodeType":"text"},{"data":{"uri":"https://docs.cometbft.com/v0.38/core/configuration"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"doc ref","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"). Without consistent configuration across the different network nodes, some transactions will keep tumbling around in the network for a long time. Side note: This also applies to other settings not related to the mempool, such as `","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"minimum-gas-prices","nodeType":"text"},{"data":{},"marks":[],"value":"` in app.toml configuration for applications built using the Cosmos SDK.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"As a heuristic mitigation, which is more recent and we have not fully corroborated yet, we advise nodes in a network to avoid using large mempools. This tends to have detrimental performance effects. We advise against configuring a `","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"mempool.max_txs_bytes","nodeType":"text"},{"data":{},"marks":[],"value":"` to more than roughly 10 times the chain’s block size (unless there is a good reason for doing so).","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Other mitigations and improvements in CometBFT","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"We have designed and added support so that CometBFT no longer performs transaction dissemination, and instead can delegate the mempool responsibility to the application layer. This is an optional feature called “nop” mempool. For technical description, see ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/blob/v0.38.9/docs/architecture/adr-111-nop-mempool.md"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"ADR 111: nop Mempool","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". Applications are thus able to implement the mempool through a P2P layer that is separate from CometBFT and is potentially optimized for application-specific conditions. This feature is available in v0.37 and newer versions of CometBFT. Documentation reference for v0.37 is here: ","nodeType":"text"},{"data":{"uri":"https://docs.cometbft.com/v0.37/core/mempool#2-nop"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"CometBFT Documentation - Mempool - v0.37","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"There were also numerous, smaller improvements that contribute to achieving better resilience and predictability of a network in the face of transaction surges. Two in particular are relevant and recent. First, we have added a backpressure mechanism so that mempool stops accepting transactions if it cannot keep up with ReCheck calls ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/pull/3314"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"cometbft#3314","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". Second, as a significant contribution from Dev @ Osmosis team, we have added support to make mempool update async from block.Commit ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/pull/3008#issuecomment-2124892339"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"cometbft#3008","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" (this is just one of an impressive array of performance optimizations that Dev has contributed to CometBFT over the last few months!). The former optimization was shipped on CometBFT v0.37 and newer versions. The latter optimization is only on the v1 line a the moment, and we are assessing whether we can backport to v0.38.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Improvements in future CometBFT versions","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"Working closely with users and collaborators, we have identified that a root cause of spam surges in CometBFT-based networks is the fact that the mempool protocol, when overloaded, might make a node progress very slowly in building blocks, affecting itself and possibly the rest of the network. Briefly, CometBFT lacks an internal mechanism to contain the pressure in mempool from spreading to other components. This is largely due to tight coupling between different components in CometBFT, and also due to some limitations of the p2p connection layer (see ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/issues/3053"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"cometbft#3053","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":").","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Quality of Service guarantees in CometBFT Mempool","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"We are adding mechanisms to prevent the above from happening. The cost of these measures is some nodes may drop some transactions in some circumstances, i.e., load-shedding. The trade-off here can be made customizable, and we are trying to do so via the “Mempool Quality of Service” (QoS) design we’re aiming to introduce. Reference: ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/issues/2803"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"cometbft#2803","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We refer to the QoS approach as “mempool lanes” in some of our design documents. This is because the concrete approach to provide quality of service guarantees entails providing a (configurable) set of lanes for the mempool. The lanes are ordered in terms of their priority. Like a highway, some lanes will go faster, while others slower. Transactions that are important or urgent for an application should go in the higher priority lane. Such transactions will have stronger guarantees (predictability, latency) in terms of their propagation and inclusion in a block. It will be up to the application to decide prioritization.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"DOG","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"Besides the QoS design, there is one more exciting feature we are working on. This is based on a simple yet brilliant idea from our colleague Hernan, a Research Engineer in the Comet team. The feature consists of adding a Dynamic Optimal Graph (DOG) gossip protocol for the mempool. We have been designing, testing and stabilizing this novel protocol that improves the efficiency of transaction dissemination and is meant to reduce the number of duplicate gossiped transactions. The outcome is that the system performs more efficiently from a bandwidth perspective and can cope better with high surges of traffic. The algorithm extends the base FLOOD protocol with a mechanism to eliminate cycles in transaction dissemination. In the absence of this extension, the algorithm falls back to the base FLOOD protocol.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"So far, we have obtained compelling performance results. On a 200-node network, with transaction workload close to saturation, we observed a reduction in transaction dissemination bandwidth close to 75%. Those results are obtained with conservative guesses of the protocol's configuration; we believe that fine-tuning the config can provide even further reduction in bandwidth. If you are curious about the details, check the GitHub issue ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/issues/3263"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"cometbft#3263","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" !","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Plans","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"We are currently working on a demonstration of the QoS design. We plan to make steady progress on both the QoS and DOG designs, with QoS taking priority. It is not yet clear if we can backport any of these new features to v0.37 or v0.38 versions of CometBFT. At minimum, we’re planning to make them work with v1.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Conclusion","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"For reference, the Cosmos Hub is using the existing mitigations for several months. They are limiting transactions based on the `","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"max_gas` ","nodeType":"text"},{"data":{},"marks":[],"value":"parameter so that it is low enough to prevent transactions from reaching 2MB or higher. They are also in the process of upgrading to v0.38, slated for the next release.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We strongly recommend developers that use CometBFT v0.37 or older to plan transitioning to v0.38 and then to v1. We understand the transition is not seamless, and upgrades are sometimes difficult. The CometBFT team is available to actively contribute to any network to upgrade and support the transition away from older versions, and also to support all users on mitigating spam or other issues. You can find us on Telegram ","nodeType":"text"},{"data":{"uri":"https://t.me/CometBFT"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"https://t.me/CometBFT","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" or Discord ","nodeType":"text"},{"data":{"uri":"https://discord.gg/interchain"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"https://discord.gg/interchain","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" as well as Slack.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"italic"}],"value":"Many thanks to the CometBFT and Amulet teams for their constructive feedback on earlier versions of this essay. Revised July 22 @Adi: problem statement wording & summary.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"contentfulURL":"https://app.contentful.com/spaces/p79kctcd7ahy/entries/692XOAVLgOQOoYVLIl6hkO"},{"featureImage":"$4:props:posts:29:featureImage","date":"2024-07-09","title":"Cosmos Hub Update June 2024: Gaia v17 Upgrade, ICS Advancements & Hydro Progress","slug":"cosmos-hub-update-june-2024-gaia-v17-upgrade-ics-advancements-and-hydro","categories":["Engineering"],"authors":["Marius Poke","Brian Truax"],"keywords":"ICS Launchpad\npermissionless consumer chains\nCosmos Hub v17\nPartial Set Security\nBabylon integration\nHydro liquidity platform\ninactive Hub validators\nCosmWasm contracts\nBitcoin staking security\ncross-chain deployment","excerpt":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Cosmos Hub v17-v19 upgrades featuring ICS Launchpad and Babylon Bitcoin security.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"includeTableOfContents":true,"introduction":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"It’s time for the usual update from the Informal Systems’ Cosmos Hub team. Here are some of the highlights:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Coordinated the Cosmos Hub v17 upgrade.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Completed the integration and testnet phases for Gaia v18.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Started the integration phase for Gaia v19.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Completed the signaling phase for ICS with Inactive Hub Validators and started the implementation phase.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Started the discussion and signaling phases for Permisionless ICS.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"Note that we use ","nodeType":"text"},{"data":{"uri":"https://forum.cosmos.network/t/cosmos-hub-improvement-process-chips-revision/13730"},"content":[{"data":{},"marks":[],"value":"CHIPs","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" to track the progress of our work. Hence, throughout this update, we refer to different phases of the CHIPs framework.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"body":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Cosmos Hub v17 Upgrade","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"On June 5th, the Cosmos Hub upgraded to ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/gaia/releases/tag/v17.1.0"},"content":[{"data":{},"marks":[],"value":"Gaia v17.1.0","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". This is a major release that added ICS 2.0 to the Cosmos Hub. ICS 2.0, also known as Partial Set Security (PSS), enables consumer chains to join Interchain Security (ICS) as either ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"Top N","nodeType":"text"},{"data":{},"marks":[],"value":" (the top N% of the voting power on the Hub must validate the consumer) or ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"Opt-In","nodeType":"text"},{"data":{},"marks":[],"value":" (validation on the consumer is completely optional) and enables validators to opt-in and out of validating any given consumer chain. For more details on the PSS feature, check out the ","nodeType":"text"},{"data":{"uri":"https://cosmos.github.io/interchain-security/v4.2.0/features/partial-set-security"},"content":[{"data":{},"marks":[],"value":"ICS docs","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"In addition, Gaia v17.1.0 patched a security vulnerability identified in the Liquid Staking Module (LSM). The patch entails adding validation to prevent shares from being tokenized if redelegations are in progress. For more details, check out the ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/gaia/security/advisories/GHSA-r47q-464x-wx5x"},"content":[{"data":{},"marks":[],"value":"public advisory","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We thank the validator community for a smooth upgrade with around 17 minutes of downtime.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Cosmos Hub Halt","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"Around two hours after the v17 upgrade, the Cosmos Hub halted. The halt was due to a bug in the ICS code. The Informal Systems Cosmos Hub team, in coordination with Hypha and Binary Builders*,* provided the fix (as part of ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/gaia/releases/tag/v17.2.0"},"content":[{"data":{},"marks":[],"value":"Gaia v17.2.0","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"), and the chain was back online in under five hours. For more details, check out the ","nodeType":"text"},{"data":{"uri":"https://forum.cosmos.network/t/cosmos-hub-v17-1-chain-halt-post-mortem/13899"},"content":[{"data":{},"marks":[],"value":"post mortem","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" we published on the Cosmos Hub forum.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Gaia v18 — Integration and Testnet Phases","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"Throughout June, we conducted the integration and testnet phases for Gaia v18, a release that will add the following features to the Cosmos Hub:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Permissioned CosmWasm (as per ","nodeType":"text"},{"data":{"uri":"https://www.mintscan.io/cosmos/proposals/895"},"content":[{"data":{},"marks":[],"value":"prop 895","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":") enables the governance-gated deployment of CosmWasm contracts. See ","nodeType":"text"},{"data":{"uri":"https://forum.cosmos.network/t/discussion-hub-cosmwasm-guidelines/13788"},"content":[{"data":{},"marks":[],"value":"this forum discussion","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" for more details on what contracts should be deployed on the Hub.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Skip's ","nodeType":"text"},{"data":{"uri":"https://github.com/skip-mev/feemarket"},"content":[{"data":{},"marks":[],"value":"feemarket module","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" (as per ","nodeType":"text"},{"data":{"uri":"https://www.mintscan.io/cosmos/proposals/842"},"content":[{"data":{},"marks":[],"value":"prop 842","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":") enables the dynamic adjustment of the base transaction fee based on the block utilization (the more transactions in a block, the higher the base fee). This module replaces the ","nodeType":"text"},{"data":{"uri":"https://hub.cosmos.network/v17.1.0/architecture/adr/adr-002-globalfee"},"content":[{"data":{},"marks":[],"value":"x/globalfee module","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"","nodeType":"text"},{"data":{"uri":"https://docs.cosmos.network/v0.50/build/modules/gov#expedited-proposals"},"content":[{"data":{},"marks":[],"value":"Expedited proposals","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" (as per ","nodeType":"text"},{"data":{"uri":"https://www.mintscan.io/cosmos/proposals/926"},"content":[{"data":{},"marks":[],"value":"prop 926","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":") enable governance proposals with a shorter voting period (i.e., one week instead of two), but with a higher tally threshold (i.e., 66.7% of Yes votes for the proposal to pass) and a higher minimum deposit (i.e., 500 ATOMs instead of the 250 for regular proposals). Initially, only ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"MsgSoftwareUpgrade","nodeType":"text"},{"data":{},"marks":[],"value":" and ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"MsgCancelUpgrade","nodeType":"text"},{"data":{},"marks":[],"value":" can be expedited.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"In addition, Gaia v18 bumps IBC to ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/ibc-go/releases/tag/v7.6.0"},"content":[{"data":{},"marks":[],"value":"v7.6.0","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" and ICS to ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/interchain-security/releases/tag/v4.3.0-lsm"},"content":[{"data":{},"marks":[],"value":"v4.3.0","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" (see below). The IBC release adds length limitations to the string fields of several IBC messages, including ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"MsgTransfer","nodeType":"text"},{"data":{},"marks":[],"value":" and, as a result, addresses some of the past spam “attacks” on the Cosmos Hub.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"ICS v4.3","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"In June, we released ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/interchain-security/releases/tag/v4.3.0"},"content":[{"data":{},"marks":[],"value":"ICS v4.3.0","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", which brings a series of improvements to Partial Set Security:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Add the ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"ConsumerModification","nodeType":"text"},{"data":{},"marks":[],"value":" gov proposal that enables consumer chains to update the ","nodeType":"text"},{"data":{"uri":"https://cosmos.github.io/interchain-security/v4.3.0/features/power-shaping"},"content":[{"data":{},"marks":[],"value":"power shaping","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" parameters after launch.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Start distributing ICS rewards to validators only after they have been validating for a given number of blocks (by default, for around 24 hours). The reason for this is to avoid validators opting in on consumer chains just for the rewards without running consumer nodes.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Fix minor issues found during the security review conducted by the ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"","nodeType":"text"},{"data":{"uri":"https://informal.systems/services/security-audits"},"content":[{"data":{},"marks":[],"value":"audit team at Informal","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"Gaia v19 — Integration Phase","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"We started the integration phase for Gaia v19, which will upgrade the Cosmos Hub to the latest versions of Cosmos SDK (","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/cosmos-sdk/releases/tag/v0.50.7"},"content":[{"data":{},"marks":[],"value":"v0.50","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":") and IBC (","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/ibc-go/releases/tag/v8.3.2"},"content":[{"data":{},"marks":[],"value":"v8.3","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"). This is part of a larger initiative to make the Cosmos Hub the reference chain for the Interchain Stack and is a collaboration with Binary Builders. The goal of this initiative is to improve the upgrade process to newer versions of the Interchain Stack, which will consequently improve the adoption within the Cosmos ecosystem. Additionally, the Cosmos Hub community will gain access to the new Interchain Stack features sooner, which will result in faster product development. Finally, by being on par with the latest releases of the Interchain Stack, the Cosmos Hub community can more actively contribute to the development of the Interchain Stack by asking for new features to be added in the next releases.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"For this particular upgrade, we restarted the work on the prerequisites necessary to upgrade Gaia to Cosmos SDK v0.50:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"We finished ","nodeType":"text"},{"data":{"uri":"https://github.com/informalsystems/cosmos-sdk/pull/13"},"content":[{"data":{},"marks":[],"value":"porting the Liquid Staking Module (LSM) to Cosmos SDK v0.50","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". Next, we will cut a special Cosmos SDK release with support for LSM. As a reminder, having LSM on a special branch of Cosmos SDK means that LSM is not being automatically upgraded with mainline Cosmos SDK. Thus, LSM requires continuous maintenance until it gets added to the mainline Cosmos SDK.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"We finished porting PSS to Cosmos SDK v0.50 and we are working on ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/interchain-security/pull/2013"},"content":[{"data":{},"marks":[],"value":"upgrading ICS main to SDK v0.50","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". Next, we will cut an ICS v5.1.0 release that will be at parity with ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/interchain-security/releases/tag/v4.3.0"},"content":[{"data":{},"marks":[],"value":"ICS v4.3.0","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"We started a ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/gaia/tree/spike/gaia-v50-upgrade"},"content":[{"data":{},"marks":[],"value":"spike to upgrade Gaia to Cosmos SDK v0.50","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"As a preliminary timeline for v19, we plan to upgrade the testnet on July 24 and the mainnet on August 7. Note that these dates might change due to issues during the integration phase.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"ICS with Inactive Hub Validators — Signaling and Implementation Phases","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"We completed the signaling phase for the ICS with Inactive Hub Validators that enable validators from outside the Hub’s active set to validate on consumer chains. This feature brings the following benefits to ICS.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"First, it reduces the entry barrier for projects to launch as consumer chains since more validators will be allowed to opt in.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Second, it enables validators outside the Hub’s active set to compete by providing their services to interesting projects.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Third, it reduces the risk of all the validators of a consumer chain opting out, which would require the chain to leave ICS.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We published a ","nodeType":"text"},{"data":{"uri":"https://forum.cosmos.network/t/proposal-930-voting-signalling-proposal-ics-with-inactive-hub-validators/13924"},"content":[{"data":{},"marks":[],"value":"forum post","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" that described the feature and proposed a detailed architecture in the form of an ","nodeType":"text"},{"data":{"uri":"https://cosmos.github.io/interchain-security/adrs/adr-017-allowing-inactive-validators"},"content":[{"data":{},"marks":[],"value":"ADR","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". We also submitted a ","nodeType":"text"},{"data":{"uri":"https://www.mintscan.io/cosmos/proposals/930"},"content":[{"data":{},"marks":[],"value":"signaling governance proposal","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" that already passed. We want to thank everyone who participated in the discussion on the Cosmos Hub forum and voted on the proposal.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Finally, we started implementing the feature. The target is to release it as part of Gaia v20.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"ICS Launchpad","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"We made significant progress on an ICS Launchpad, a comprehensive front-end platform designed to streamline the deployment of new projects as consumer chains. This initiative aims to dramatically simplify the process of launching and managing consumer chains within the Cosmos ecosystem.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The first iteration (version 0) of the platform was developed with a focus on the upcoming \"Launching on Interchain Security\" workshop at the ","nodeType":"text"},{"data":{"uri":"https://lu.ma/6do92q5o?tk=1kZqzx"},"content":[{"data":{},"marks":[],"value":"Cosmos Hub @ EthCC event","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". This early Alpha build was used to gather direct user feedback and showcased key features, including:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"A user-friendly interface for chain configuration and deployment","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Integration with the Cosmos Hub for seamless validator set access","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Tools for managing chain parameters and Interchain Security settings","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"A discovery gallery for new and upcoming consumer chains","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"A validator opt-in (and opt-out) system to facilitate easy participation in new chains","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"We are also ideating on additional features for future releases, such as:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Integration with other Cosmos Hub services like Hydro for liquidity provision","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Delegator discovery of consumer chains and their needs to delegate and redelegate","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"The ICS Launchpad represents a significant step towards our goal of making the Cosmos Hub the best place to launch a chain.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Permissionless ICS — Discussion and Signaling Phases","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"We started working on a new feature for ICS that allows anyone to ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"permissionlessly","nodeType":"text"},{"data":{},"marks":[],"value":" launch an Opt-In consumer chain on the Cosmos Hub. Given that validators are free to choose whether they want to run a given Opt-In consumer chain, it is only natural to also enable projects to launch as an Opt-In consumer chain by simply submitting a transaction to the Cosmos Hub and, thus, avoiding the need to go through the process of governance for their chain launch. Note that Top N consumer chains will still need to go through governance.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We published a ","nodeType":"text"},{"data":{"uri":"https://forum.cosmos.network/t/chips-discussion-phase-permissionless-ics/13955"},"content":[{"data":{},"marks":[],"value":"forum post","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" outlining the motivations behind the feature and describing the high-level design. We want to thank everyone who participated in the discussion. We also started the signaling phase. We are currently working on an ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/interchain-security/pull/2001"},"content":[{"data":{},"marks":[],"value":"ADR","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" that describes the architecture details.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"ATOM Wars / Hydro","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"We are thrilled to announce significant progress on Hydro, a key component of the ATOM Wars strategy. Hydro is a bidding and governance platform designed to enhance liquidity deployment across the Interchain. Here are the highlights:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Audit Completion:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":" Coordinated with Simply Staking, the third-party audit by Oak Security was successfully completed and funded through the community pool. The audit report will be published soon.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Platform Development:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":" We are developing a front-end platform for Hydro, enabling projects to bid for liquidity and users to lock their stATOM tokens to vote on these bids. Locking stATOM provides liquidity and earns tributes as rewards.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Launch Timeline:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":" Hydro, along with its user-friendly front-end, is currently looking to launch sometime in August.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"Key Features of Hydro:","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Voting and Locking:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":" Users lock stATOM to acquire voting power, which they use to vote on projects, providing liquidity and earning tributes.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Bidding and tribute:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":" Projects bid for liquidity and offer tribute as rewards to attract votes.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Robust User Dashboard:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":" Users will be able to manage their lockups, track their voting power, monitor rewards, and view their voting history.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"Hydro aims to optimize liquidity distribution and governance within the Cosmos ecosystem, attracting diverse projects and active participation from the ATOM-holder community.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Babylon Integration","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"In May, we published a ","nodeType":"text"},{"data":{"uri":"https://forum.cosmos.network/t/chips-signaling-phase-babylon-x-cosmos-hub-security-aggregation/13797"},"content":[{"data":{},"marks":[],"value":"signaling proposal","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" for the technical specification to bring Bitcoin security from Babylon to the Cosmos Hub and its consumer chains. In June, we published ","nodeType":"text"},{"data":{"uri":"https://forum.cosmos.network/t/chips-signaling-phase-simplified-babylon-x-cosmos-hub/13932"},"content":[{"data":{},"marks":[],"value":"a significant revision","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" of that technical specification that was a result of the feedback we received from the community about the complexity of the previous design. The new design is much more streamlined as it entails deploying on Cosmos Hub the Babylon CosmWasm contract that enables a second validator set, whose power comes from staked Bitcoin, to provide finality and protect against double signing misbehavior. Note that ICS consumer chains that choose to use Babylon’s Bitcoin security will also need to install this CosmWasm contract.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We also successfully managed to connect the Cosmos Hub persistent testnet to Babylon’s Euphrates devnet.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"What This Enables","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"This month's developments move us further toward our vision of making the Cosmos Hub the best place to launch a chain:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Enhanced Security and Flexibility:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":" The successful implementation of ICS 2.0 (Partial Set Security) gives consumer chains more options for joining Interchain Security, making the Hub an even more attractive platform for new projects.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Faster Innovation:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":" By aligning the Cosmos Hub with the latest versions of the Interchain Stack, we are enabling quicker feature adoption and more efficient upgrades, benefiting both developers and users.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Broader Participation:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":" The upcoming feature allowing inactive Hub validators to participate in consumer chains expands the validator base, enhancing decentralization and security across the ecosystem.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Simplified Chain Deployment:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":" The ICS Launchpad initiative streamlines the process of launching consumer chains, reducing barriers to entry and fostering innovation within the Cosmos ecosystem.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Optimized Liquidity:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":" With Hydro's imminent launch, ATOM holders will gain new capabilities to influence liquidity deployment, addressing a critical ecosystem need.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"These advancements collectively reinforce the Cosmos Hub's role as the best place to launch and manage your project in the Interchain ecosystem. We are excited about the new capabilities these features bring and look forward to continued growth and innovation in the coming months.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"contentfulURL":"https://app.contentful.com/spaces/p79kctcd7ahy/entries/3HXnUvScHaBX7rKb7TOByc"},{"featureImage":"$4:props:posts:29:featureImage","date":"2024-06-11","title":"Cosmos Hub Update May 2024: Gaia v16, v17, v18 Integration & ICS Advancements","slug":"cosmos-hub-update-may","categories":["Engineering"],"authors":["Marius Poke"],"keywords":"ICS 2.0 upgrade\nPartial Set Security\nCosmos Hub validators\nCosmWasm integration\nATOM Wars strategy\nHydro liquidity platform\nIBC rate limiting\nconsumer chain deployment\nGaia protocol\ncross-chain governance","excerpt":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Cosmos Hub v16-v18 upgrades featuring PSS, CosmWasm, and ATOM Wars liquidity.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"includeTableOfContents":true,"introduction":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"It’s time for the usual update from the Informal Systems’ Cosmos Hub team. Here are some of the highlights:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Coordinated the Cosmos Hub v16 upgrade.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Completed the integration, testnet, and governance phases for Gaia v17.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Started the integration phase for Gaia v18","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Started the signaling phase for ICS with Inactive Hub Validators.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Completed the implementation phase for ATOM Wars / Hydro.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Working on the implementation phase of Security Aggregation.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"Note that we use ","nodeType":"text"},{"data":{"uri":"https://forum.cosmos.network/t/cosmos-hub-improvement-process-chips-revision/13730"},"content":[{"data":{},"marks":[],"value":"CHIPs","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" to track the progress of our work. Hence, throughout this update, we refer to different phases of the CHIPs framework.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"body":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Cosmos Hub v16 Upgrade","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"On May 15th, the Cosmos Hub upgraded to ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/gaia/releases/tag/v16.0.0"},"content":[{"data":{},"marks":[],"value":"Gaia v16.0.0","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". This upgrade brings several functionalities that were enabled by the upgrade to Cosmos SDK v0.47:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"The ","nodeType":"text"},{"data":{"uri":"https://github.com/Stride-Labs/ibc-rate-limiting"},"content":[{"data":{},"marks":[],"value":"IBC rate limit module","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" prevents massive inflows or outflows of IBC tokens in a short time frame, adding an extra layer of protection to IBC transfers.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"The ","nodeType":"text"},{"data":{"uri":"https://ibc.cosmos.network/v7/apps/interchain-accounts/overview"},"content":[{"data":{},"marks":[],"value":"ICA controller sub-module","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" enables Hub users to perform actions on other chains using their Hub accounts.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"The ","nodeType":"text"},{"data":{"uri":"https://ibc.cosmos.network/v7/middleware/ics29-fee/overview"},"content":[{"data":{},"marks":[],"value":"IBC fee middleware","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" enables the creation of IBC channels with in-protocol incentivization for relayers.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"In addition, the v16 upgrade introduces ","nodeType":"text"},{"data":{"uri":"https://cosmos.github.io/interchain-security/adrs/adr-014-epochs"},"content":[{"data":{},"marks":[],"value":"ICS epochs","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" that reduce the amount of ICS packets that need to be relayed.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We thank the validator community for a smooth upgrade with less than seven minutes of downtime.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Gaia v17: ICS 2.0 Integration, Testnet, and Governance Phases","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"Throughout May, we conducted the integration, testnet, and governance phases for Gaia v17, a major release that will bring ICS 2.0 to the Cosmos Hub. ICS 2.0, also known as Partial Set Security (PSS), enables consumer chains to join Interchain Security (ICS) as either ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"Top N","nodeType":"text"},{"data":{},"marks":[],"value":" (the top N% of the voting power on the Hub must validate the consumer) or ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"Opt-In","nodeType":"text"},{"data":{},"marks":[],"value":" (validation on the consumer is completely optional) and enables validators to opt-in and out of validating any given consumer chain. In addition, ICS 2.0 introduces the ","nodeType":"text"},{"data":{"uri":"https://cosmos.github.io/interchain-security/v4.2.0/features/power-shaping"},"content":[{"data":{},"marks":[],"value":"power shaping feature","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" that gives consumer chains more flexibility in choosing their validator set. For more details on the PSS feature, check out the ","nodeType":"text"},{"data":{"uri":"https://cosmos.github.io/interchain-security/v4.2.0/features/partial-set-security"},"content":[{"data":{},"marks":[],"value":"ICS docs","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Below are the major milestones we completed last month:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"We released ICS 2.0 as part of ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/interchain-security/releases/tag/v4.2.0"},"content":[{"data":{},"marks":[],"value":"ICS v4.2.0","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"and integrated it into ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/gaia/releases/tag/v17.0.0"},"content":[{"data":{},"marks":[],"value":"Gaia v17.0.0","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Both Cosmos Hub testnets were upgraded to Gaia v17.0.0. Please join the testnet to familiarize yourself with ICS 2.0. If you are a Cosmos Hub validator, please check out the ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"","nodeType":"text"},{"data":{"uri":"https://cosmos.github.io/interchain-security/v4.2.0/validators/partial-set-security-for-validators"},"content":[{"data":{},"marks":[],"value":"PSS guide","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"We submitted a ","nodeType":"text"},{"data":{"uri":"https://www.mintscan.io/cosmos/proposals/924"},"content":[{"data":{},"marks":[],"value":"software upgrade proposal","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" on May 17th, and it passed on May 31st. This means the Cosmos Hub v17 upgrade will occur on June 5th.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"The security review conducted by the ","nodeType":"text"},{"data":{"uri":"https://informal.systems/services/security-audits"},"content":[{"data":{},"marks":[],"value":"audit team at Informal","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" was completed, and no critical bugs were found. As a result, we decided to go ahead with releasing ICS 2.0 in production. We’re currently working on fixing the minor issues found, but the fixes will be in a future release (most likely Gaia v18).","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"Gaia v18 — Integration Phase","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"We started the integration phase for Gaia v18, which will bring the following features:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Permissioned CosmWasm (as per ","nodeType":"text"},{"data":{"uri":"https://www.mintscan.io/cosmos/proposals/895"},"content":[{"data":{},"marks":[],"value":"prop 895","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":") enables the governance-gated deployment of CosmWasm contracts. The forum discussion provides more details on what contracts should be deployed on the Hub. The CosmWasm integration is ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/gaia/pull/3051"},"content":[{"data":{},"marks":[],"value":"in review","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Skip’s ","nodeType":"text"},{"data":{"uri":"https://github.com/skip-mev/feemarket"},"content":[{"data":{},"marks":[],"value":"feemarket module","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" (as per ","nodeType":"text"},{"data":{"uri":"https://www.mintscan.io/cosmos/proposals/842"},"content":[{"data":{},"marks":[],"value":"prop 842","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":") enables the dynamic adjustment of the base transaction fee based on the block utilization (the more transactions in a block, the higher the base fee). The feemarket integration is ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/gaia/pull/3028"},"content":[{"data":{},"marks":[],"value":"in review","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Note that we decided against adding the ","nodeType":"text"},{"data":{"uri":"https://github.com/skip-mev/block-sdk/tree/main"},"content":[{"data":{},"marks":[],"value":"Block SDK","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" (which enables multiple transaction lanes) as there is no existing application for it at the moment. We will add it to a future release once it is clearly needed.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"","nodeType":"text"},{"data":{"uri":"https://docs.cosmos.network/v0.50/build/modules/gov#expedited-proposals"},"content":[{"data":{},"marks":[],"value":"Expedited proposals","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" enable governance proposals with a shorter voting period (i.e., one week instead of two), but with a higher tally threshold (i.e., 66.7% of Yes votes for the proposal to pass). Initially, we want to limit this feature to only software upgrade proposals to make the upgrade process more efficient. However, we could enable it also for client update proposals to shorten the time needed to unfreeze light clients. If you have feedback or questions about this feature, you can join the ","nodeType":"text"},{"data":{"uri":"https://forum.cosmos.network/t/proposal-draft-signaling-proposal-expedite-software-upgrade-proposals/13869"},"content":[{"data":{},"marks":[],"value":"discussion on the forum","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The feature is implemented as part of Cosmos SDK 0.50, so we need to backport it to the ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/cosmos-sdk/tree/feature/v0.47.x-ics-lsm"},"content":[{"data":{},"marks":[],"value":"special branch of Cosmos SDK v0.47","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" used by the Cosmos Hub.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"As a preliminary timeline for v18, we plan to upgrade the testnet on June 19 and the mainnet on July 10. Note that these dates might change due to issues during the integration phase.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"ICS with Inactive Hub Validators","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"We started working on a new feature for Interchain Security (ICS) that would enable validators from outside the Hub’s active set to validate on consumer chains. This feature addresses multiple concerns with ICS 2.0.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"It reduces the entry barrier for projects to launch as consumer chains and more validators will be allowed to opt in.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"It enables validators outside the Hub’s active set to compete by providing their services to interesting projects.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"It reduces the risk of all the validators of a consumer chain opting out, which would require the chain to leave ICS.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"ordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"Currently, we are working on an ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/interchain-security/pull/1879"},"content":[{"data":{},"marks":[],"value":"ADR","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" and a ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/interchain-security/pull/1878"},"content":[{"data":{},"marks":[],"value":"prototype implementation","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" to help us finalize the design. Once the ADR is completed, we will submit a signaling proposal and start a discussion on the forum.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"ATOM Wars / Hydro — Signaling and Implementation Phases","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"We published ","nodeType":"text"},{"data":{"uri":"https://forum.cosmos.network/t/atom-wars-introducing-the-hydro-auction-platform/13842"},"content":[{"data":{},"marks":[],"value":"a post on","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" the Cosmos Hub forum introducing Hydro, a bidding and governance platform for efficient deployment of liquidity across the Interchain and an important part of the ","nodeType":"text"},{"data":{"uri":"https://forum.cosmos.network/t/the-atom-wars-a-new-strategy-for-liquidity-injections/13122"},"content":[{"data":{},"marks":[],"value":"ATOM Wars strategy","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". In a nutshell, Hydro enables ATOM holders to lock up their staked tokens in exchange for decision power on liquidity injections into third-party projects. For more details on how Hydro works, check out the ","nodeType":"text"},{"data":{"uri":"https://drive.google.com/file/d/1BBdjZ7Sw_xSmyxsBVpETnFp0xknrzeap/view"},"content":[{"data":{},"marks":[],"value":"litepaper","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We also completed the implementation of the first version of Hydro (as a CosmWasm contract) and successfully deployed it on the Neutron testnet.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Finally, we are working with Simply Staking to source a third-party audit for Hydro. If you have feedback or questions about the audit, you can join the ","nodeType":"text"},{"data":{"uri":"https://forum.cosmos.network/t/atom-wars-hydro-platform-funding-third-party-audit/13864"},"content":[{"data":{},"marks":[],"value":"discussion on the forum","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Security Aggregation — Implementation Phase","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"In February, we started the ","nodeType":"text"},{"data":{"uri":"https://forum.cosmos.network/t/bringing-bitcoin-security-to-the-cosmos-hub-with-babylon/13280"},"content":[{"data":{},"marks":[],"value":"discussion phase of Babylon integration","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" with the Cosmos Hub, which is part of a larger effort to make the Hub a security aggregator bringing together staked assets from many sources. In May, we published a ","nodeType":"text"},{"data":{"uri":"https://forum.cosmos.network/t/chips-signaling-phase-babylon-x-cosmos-hub-security-aggregation/13797"},"content":[{"data":{},"marks":[],"value":"signaling proposal","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" for the technical specification to bring Bitcoin security from Babylon to the Cosmos Hub and its consumer chains.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We also completed the implementation of the power mixing feature, which is currently under review. This feature enables chains to mix multiple sources of stake to compute the validator set passed to the consensus engine.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"What This Enables","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"This month, we’ve either launched or continued working on new features to make the Cosmos Hub more secure, flexible, and user-friendly:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Better Security","nodeType":"text"},{"data":{},"marks":[],"value":": The Gaia v16 upgrade adds protections to make cross-chain transactions safer and smoother.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"More Control","nodeType":"text"},{"data":{},"marks":[],"value":": Users can now perform actions on other chains using their Hub accounts, making managing assets across the ecosystem easier.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Efficient Governance","nodeType":"text"},{"data":{},"marks":[],"value":": Faster decision-making processes help the community implement important changes more quickly.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Incentives for Relayers","nodeType":"text"},{"data":{},"marks":[],"value":": New incentives ensure those who help facilitate transactions are rewarded, improving overall network reliability.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Economic Growth","nodeType":"text"},{"data":{},"marks":[],"value":": The Hydro platform allows ATOM holders to influence how liquidity is deployed, helping to solve liquidity issues in the ecosystem.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Future Readiness","nodeType":"text"},{"data":{},"marks":[],"value":": Upcoming features like permissioned CosmWasm and support for inactive validators will make the Hub more versatile and inclusive.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"These updates make the Hub a better place to launch and manage projects, ensuring ongoing rewards for validators and a more robust, user-friendly experience for everyone. We’re excited about these features' new capabilities and look forward to continued growth and innovation in the coming months.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"contentfulURL":"https://app.contentful.com/spaces/p79kctcd7ahy/entries/6UdrnfTLKldF1VLdRCENFn"},{"featureImage":"$4:props:posts:29:featureImage","date":"2024-05-13","title":"Cosmos Hub Update - April 2024","slug":"cosmos-hub-update-april-2024","categories":["Engineering"],"authors":["Marius Poke"],"keywords":"ICS 2.0 upgrade\nPartial Set Security\nCosmos Hub validators\nCosmWasm integration\nATOM Wars strategy\nHydro liquidity platform\nIBC rate limiting\nconsumer chain deployment\nGaia protocol\ncross-chain governance","excerpt":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Cosmos Hub v16-v18 upgrades featuring PSS, CosmWasm, and ATOM Wars liquidity.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"includeTableOfContents":false,"body":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"It's time for the usual update from the Informal Systems' Cosmos Hub team. Here are some of the highlights:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Had our quarterly meeting with the oversight committee.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Coordinated the Cosmos Hub upgrade to Gaia v15.2.0.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Completed the testnet phase and started the governance phase for Gaia v16.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Started the integration phase for CosmWasm.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Completed the implementation phase of ICS 2.0.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Completed the signaling phase of ATOM Wars.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"Note that we use ","nodeType":"text"},{"data":{"uri":"https://forum.cosmos.network/t/cosmos-hub-improvement-process-chips-revision/13730"},"content":[{"data":{},"marks":[],"value":"CHIPs","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" to track the progress of our work. Hence, throughout this update, we refer to different phases of the CHIPs framework.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Oversight Committee Quarterly Meeting","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"On April 11, 2024, the Hub teams at Informal and Hypha met with the oversight committee to review the work done in Q1 and discuss our Q2 plans. We published a ","nodeType":"text"},{"data":{"uri":"https://forum.cosmos.network/t/informal-systems-q1-24-retro-q2-24-plan/13749"},"content":[{"data":{},"marks":[],"value":"summary of the meeting","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" on the Hub forum. We want to thank the oversight committee members for their time and engaging discussions. Their feedback is invaluable, enabling us to grow and continue improving.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Cosmos Hub v15.2 Coordinated Upgrade","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"On April 10, the Cosmos Hub underwent a coordinated upgrade to ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/gaia/releases/tag/v15.2.0"},"content":[{"data":{},"marks":[],"value":"Gaia v15.2.0","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". This upgrade was necessary to fix two issues introduced by the upgrade to Cosmos SDK ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/cosmos-sdk/tree/v0.47.10-ics-lsm"},"content":[{"data":{},"marks":[],"value":"v0.47","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" (Gaia ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/gaia/releases/tag/v15.1.0"},"content":[{"data":{},"marks":[],"value":"v15.1.0","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"). First, the metadata length for gov proposals was set to the default of 255, which limited the description field. This limitation inconvenienced users engaging in Hub governance, as proposals needed to use IPFS links in the description. Second, it was no longer possible to query pre-v15 transactions for the Asteroid protocol, which was an issue for block explorers. Thanks to the validator community for a smooth upgrade (around two minutes of downtime).","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Gaia v16 — Testnet and Governance Phases","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"In April, we concluded the testnet phase and started the governance phase for Gaia v16, which brings several features made possible by the upgrade to SDK v0.47:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"The ","nodeType":"text"},{"data":{"uri":"https://github.com/Stride-Labs/ibc-rate-limiting"},"content":[{"data":{},"marks":[],"value":"IBC rate limit module","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" prevents massive inflows or outflows of IBC tokens in a short time frame to add an extra layer of protection on IBC transfers.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"The ","nodeType":"text"},{"data":{"uri":"https://ibc.cosmos.network/v7/apps/interchain-accounts/overview"},"content":[{"data":{},"marks":[],"value":"ICA controller sub-module","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" enables Hub users to perform actions on other chains using their Hub accounts.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"The ","nodeType":"text"},{"data":{"uri":"https://ibc.cosmos.network/v7/middleware/ics29-fee/overview"},"content":[{"data":{},"marks":[],"value":"IBC fee middleware","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" enables the creation of IBC channels with in-protocol incentivization for relayers.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"In addition, Gaia v16 introduces ","nodeType":"text"},{"data":{"uri":"https://cosmos.github.io/interchain-security/adrs/adr-014-epochs"},"content":[{"data":{},"marks":[],"value":"ICS epochs","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" that will reduce the amount of ICS packets that need to be relayed. This is part of the ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/interchain-security/releases/tag/v4.1.0"},"content":[{"data":{},"marks":[],"value":"ICS v4.1.0","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" release.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"For more details, see the ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/gaia/releases/tag/v16.0.0"},"content":[{"data":{},"marks":[],"value":"v16.0.0 release notes","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" or the ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/gaia/blob/v16.0.0/CHANGELOG.md"},"content":[{"data":{},"marks":[],"value":"changelog","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". If you have feedback or questions about this release, you can join ","nodeType":"text"},{"data":{"uri":"https://forum.cosmos.network/t/proposal-xxx-draft-gaia-v16-software-upgrade/13702"},"content":[{"data":{},"marks":[],"value":"the discussion on the forum","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"On April 26, we submitted a ","nodeType":"text"},{"data":{"uri":"https://www.mintscan.io/cosmos/proposals/914"},"content":[{"data":{},"marks":[],"value":"software upgrade proposal","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". If the proposal passes, the validator community will update the Cosmos Hub to Gaia v16 on May 15 (at upgrade height ","nodeType":"text"},{"data":{"uri":"https://www.mintscan.io/cosmos/block/20440500"},"content":[{"data":{},"marks":[],"value":"20440500","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":").","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Refactor Gaia and ICS Docs","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"With the ICS v5 release, we needed to provide versioned documentation for all supported ICS versions so users could continue using and referencing older documentation. The new versioned docs page includes v5.x, v4.x, and historic versions of v3.x and v2.x, which were kept as references. A similar process is underway for the Gaia repo and Gaia documentation, with a target date in early May.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"CosmWasm — Integration Phase","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"In April, ","nodeType":"text"},{"data":{"uri":"https://www.mintscan.io/cosmos/proposals/895"},"content":[{"data":{},"marks":[],"value":"prop 895","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" passed, which means that the Cosmos Hub community decided that they want permissioned CosmWasm on the Hub. First, we thank everyone who participated in the discussion and voted on the proposal. Second, we thank Reece Williams for his work on ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/gaia/pull/3051"},"content":[{"data":{},"marks":[],"value":"CosmWasm integration in Gaia","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". We plan to add CosmWasm to a future release of Gaia (probably v18). In the meantime, we are considering whether or not there should be more detailed guidelines for deploying CosmWasm contracts on the Hub, for which we have ","nodeType":"text"},{"data":{"uri":"https://forum.cosmos.network/t/discussion-hub-cosmwasm-guidelines/13788/4"},"content":[{"data":{},"marks":[],"value":"published a discussion here","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Upgrade ICS to SDK v0.50","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"We cut a ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/interchain-security/releases/tag/v5.0.0-rc0"},"content":[{"data":{},"marks":[],"value":"release candidate","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" of ICS v5 that uses ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/cosmos-sdk/tree/release/v0.50.x"},"content":[{"data":{},"marks":[],"value":"Cosmos SDK v0.50","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". This release has feature parity with ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/interchain-security/releases/tag/v4.1.0"},"content":[{"data":{},"marks":[],"value":"ICS v4.1.0","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" (it includes ICS epochs). Upgrading ICS to SDK v0.50 is a prerequisite for upgrading Gaia to SDK v0.50. This upgrade enables consumer chains to start integrating the ICS consumer module, which increases the adoption of SDK v0.50. We will support consumer chains, such as Neutron, while they are testing the integration of ICS v5. Once we finish testing, we will cut the final release. A stable release of ICS v5 will land in early May.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"ICS 2.0 — Implementation Phase","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"We completed the implementation phase of ICS 2.0, also known as Partial Set Security (PSS). ICS 2.0 enables consumer chains to join Interchain Security (ICS) as either ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"Top N","nodeType":"text"},{"data":{},"marks":[],"value":" (the top N% of the voting power on the Hub must validate the consumer) or ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"Opt-In","nodeType":"text"},{"data":{},"marks":[],"value":" (validation on the consumer is entirely optional) and enables validators to opt-in and out of validating any given consumer chain. For more details on the implementation, see ","nodeType":"text"},{"data":{"uri":"https://cosmos.github.io/interchain-security/adrs/adr-015-partial-set-security"},"content":[{"data":{},"marks":[],"value":"ADR 015","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Next, we will work on the integration phase. We plan to release ICS 2.0 as part of Gaia v17 and target a mainnet upgrade on June 5 (provided that the v17 software upgrade proposal passes).","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"ATOM Wars — Signaling Phase","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"In January, we started the ","nodeType":"text"},{"data":{"uri":"https://forum.cosmos.network/t/the-atom-wars-a-new-governance-platform-for-liquidity-injections/13122?u=thyborg"},"content":[{"data":{},"marks":[],"value":"discussion phase of ATOM Wars","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". This governance platform enables ATOM holders to lock up their staked tokens in exchange for decision power on liquidity injections into third-party projects. We want to thank everyone who participated in the discussion on the forum post for their thoughtful feedback and valuable ideas. Since then, we have worked on the signaling phase:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"We wrote a litepaper that includes the feedback we received and describes an updated version of the system.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"We implemented a prototype of ATOM Wars (as a CosmWasm contract), which allowed us to gain additional insight into the system's feasibility.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"Next, we will publish a signaling proposal on the forum with the litepaper attached.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Security Aggregation: Babylon Integration — Signaling Phase","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"In February, we started the ","nodeType":"text"},{"data":{"uri":"https://forum.cosmos.network/t/bringing-bitcoin-security-to-the-cosmos-hub-with-babylon/13280"},"content":[{"data":{},"marks":[],"value":"discussion phase of Babylon integration","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" with the Cosmos Hub, which is part of a more considerable effort to make the Hub a security aggregator, bringing together staked assets from many sources. We thank everyone who participated in the forum post discussion. Since then, we have worked on the signaling phase:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"We designed the system architecture of ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"CosmoLayer,","nodeType":"text"},{"data":{},"marks":[],"value":" a collection of modules that enables staking tokens from external sources such as Bitcoin to Cosmos chains.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"We drafted an ADR that describes the changes needed to ICS.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"Next, we will publish a signaling proposal on the forum.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Others","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"We published a ","nodeType":"text"},{"data":{"uri":"https://forum.cosmos.network/t/cosmos-hub-improvement-process-chips-revision/13730"},"content":[{"data":{},"marks":[],"value":"revised version of the Cosmos Hub Improvement Process (CHIPs)","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". The goal is to simplify the process and clarify the concerns we are trying to address with this framework. The purpose of CHIPs is twofold: It facilitates collaborative product development within the Cosmos Hub community and standardizes the process of adding new features to the Cosmos Hub. The revised version has three main changes (compared to the ","nodeType":"text"},{"data":{"uri":"https://forum.cosmos.network/t/cosmos-hub-improvement-process-chips/11765"},"content":[{"data":{},"marks":[],"value":"original CHIPs post","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"):","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"We combined the specification, spike, and signaling phases into a single ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"italic"}],"value":"signaling phase ","nodeType":"text"},{"data":{},"marks":[],"value":"because specifications and prototypes are artifacts necessary to provide a complete picture to the Cosmos Hub community to enable engagement in the voting process.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"We combined the voting and deployment phases into a single ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"governance phase","nodeType":"text"},{"data":{},"marks":[],"value":". Once the testnet phase is over, it is up to the Hub governance (and the validator community) to deploy features on the Cosmos Hub.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"We removed the maintenance phase because we believe it deserves its own forum post and requires a deeper discussion.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"What This Enables","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"As always, we're focused on making the Hub the best place to launch a chain and ensure that Hub validators are continually rewarded for their hard work to secure the Hub. In April, we introduced features that enhanced security, provided additional flexibility for Hub users, and increased in-protocol incentivization for relayers. Additionally, we significantly moved forward the engineering and research work on three of the most exciting pillars of our roadmap this year:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"PSS, allowing for new chains to launch with the most battle-tested validators in PoS quickly","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Babylon integration, bringing potentially billions in security from $BTC to the Cosmos Hub, as well as diversifying security options for chains and rewards for validators","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"ATOM Wars, which we believe will solve a significant pain point across Cosmos: low levels of liquidity.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"We're excited about May as we approach the launch of some of these major initiatives in Q2.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"contentfulURL":"https://app.contentful.com/spaces/p79kctcd7ahy/entries/1oKimBwpOqIbX4LmKuOW9m"},{"featureImage":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"2b6uHTnNQrQEQcY7EbTmBN","type":"Asset","createdAt":"2024-08-14T02:32:45.141Z","updatedAt":"2024-08-14T02:32:45.141Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":3,"revision":1,"locale":"en-US"},"fields":{"title":"https images.ctfassets.net p79kctcd7ahy 7e7kKIzEZQJJct5VlZciha fa34c16583d8d5dcbef7cfc288e223f1 Screenshot 2023-10-31 at 16.28.01","description":"","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/2b6uHTnNQrQEQcY7EbTmBN/0e2e3e5e828bcae58b7243ea71127bc9/https___images.ctfassets.net_p79kctcd7ahy_7e7kKIzEZQJJct5VlZciha_fa34c16583d8d5dcbef7cfc288e223f1_Screenshot_2023-10-31_at_1.png","details":{"size":125257,"image":{"width":2048,"height":838}},"fileName":"https___images.ctfassets.net_p79kctcd7ahy_7e7kKIzEZQJJct5VlZciha_fa34c16583d8d5dcbef7cfc288e223f1_Screenshot_2023-10-31_at_16.28.01.png","contentType":"image/png"}}},"date":"2024-04-23","title":"ABCI v2 Unlocks Decentralized Oracles and Cross-Chain Coordination","slug":"abci-v2-unlocks-this","categories":["Engineering"],"authors":["Adi Seredinschi"],"keywords":"ABCI v2 implementation\ndecentralized price oracle\noptimistic block execution\nIBC-Sync protocol\nvote extensions\nCometBFT v0.38\ncross-chain coordination\nCosmos SDK v0.50\nvalidator responsibilities\nblockchain interoperability\nabci-v2, cometbft-vote-extensions, decentralized-oracle, cross-chain-coordination, optimistic-execution, cosmos-sdk, ibc-sync, polygon-pos, slinky-oracle, blockchain-interoperability","excerpt":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Technical examples of CometBFT vote extensions enabling new blockchain features.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"includeTableOfContents":false,"introduction":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"This post provides a curated list of use-cases that ABCI++ unlocks for application builders. To recall, ABCI++ is a codename for ABCI ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"v2","nodeType":"text"},{"data":{},"marks":[],"value":", released in CometBFT ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/releases/tag/v0.38.0"},"content":[{"data":{},"marks":[],"value":"v0.38","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", and integrated in ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/cosmos-sdk/releases/tag/v0.50.0-rc.1"},"content":[{"data":{},"marks":[],"value":"Cosmos SDK v0.50","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"This post is a direct follow-up to our previous story called ","nodeType":"text"},{"data":{"uri":"https://informal.systems/blog/intro-to-abci-v2"},"content":[{"data":{},"marks":[],"value":"“Intro to ABCI v2”","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". We will be reusing some the terminology and context from that post, and encourage reading that before proceeding here.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"body":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"There are 3 broad use-cases we will cover today. This is not a deep dive into engineering aspects, but a high-level design of these uses. Our goal with this post is to encourage further innovation. We will describe:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"","nodeType":"text"},{"data":{"uri":"#decentralized-price-oracle"},"content":[{"data":{},"marks":[],"value":"Decentralized price oracle","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"","nodeType":"text"},{"data":{"uri":"#optimistic-block-execution"},"content":[{"data":{},"marks":[],"value":"Optimistic block execution","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"","nodeType":"text"},{"data":{"uri":"#cross-chain-coordination"},"content":[{"data":{},"marks":[],"value":"Cross-chain coordination","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":": This third use-case actually has three examples, all of which are highly interesting in their own right: ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"","nodeType":"text"},{"data":{"uri":"#polygon-po-s-tracking-staking-information-from-l-1-into-l-2"},"content":[{"data":{},"marks":[],"value":"Polygon use-case of Vote Extensions for coordinating staking information across L1 and L2","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"","nodeType":"text"},{"data":{"uri":"#ibc-sync-co-cage"},"content":[{"data":{},"marks":[],"value":"IBC-Sync for enshrining IBC packet relaying as a validator responsibility","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"","nodeType":"text"},{"data":{"uri":"#ibc-sync-co-cage"},"content":[{"data":{},"marks":[],"value":"CoCage for enabling validators of a network to verify blocks from data publication networks such as Celestia","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"ordered-list"}],"nodeType":"list-item"}],"nodeType":"ordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"For later on, if this post proves to be valuable and stir conversations, we plan to also cover other important use-cases, for example threshold encryption for mempool privacy or ","nodeType":"text"},{"data":{"uri":"https://github.com/rollchains/tiablob"},"content":[{"data":{},"marks":[],"value":"tiablob","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Decentralized price oracle","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"Accurate pricing information is essential for the operation of any financial instrument, decentralized or traditional. In the context of decentralized financial instruments, such as DEX-es, token prices have been traditionally sourced from centralized actors, such as centralized exchanges.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"In a network building with CometBFT v0.38 or newer, it is possible to source token prices using an in-protocol, decentralized approach. The basic sequence of actions is sketched in the diagram below. The general flow involves three steps: (1) validators perform external queries to various actors such as centralized services or decentralized exchanges, to obtain pricing information for certain token pairs; (2) each validator injects the pricing information they obtained into the block via ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"ExtendVote","nodeType":"text"},{"data":{},"marks":[],"value":" and verifies the information that other validators injected; and finally (3) the set of updated pricing pair information is then used in executing transactions in the subsequent block.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"If you’d like to know more, we recommend reading about the ","nodeType":"text"},{"data":{"uri":"https://github.com/skip-mev/slinky"},"content":[{"data":{},"marks":[],"value":"Slinky","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" production-ready implementation of a decentralized price oracle that the Skip team built using CometBFT.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"7e7kKIzEZQJJct5VlZciha","type":"Asset","createdAt":"2024-04-22T14:16:19.457Z","updatedAt":"2024-04-23T11:33:13.552Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":16,"revision":2,"locale":"en-US"},"fields":{"title":"Decentralized price oracle","description":"Sketch of how a decentralized price oracle functions using CometBFT v0.38 (ABCI v2) or newer. In this high-level description, only the proposer is shown to verify vote extensions, but in reality all validators do.","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/7e7kKIzEZQJJct5VlZciha/fa34c16583d8d5dcbef7cfc288e223f1/Screenshot_2023-10-31_at_16.28.01.png","details":{"size":385971,"image":{"width":2208,"height":904}},"fileName":"Screenshot 2023-10-31 at 16.28.01.png","contentType":"image/png"}}}},"content":[],"nodeType":"embedded-asset-block"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"italic"}],"value":"Sketch of how a decentralized price oracle functions using CometBFT v0.38 (ABCI v2) or newer. For simplicity, in this description only the proposer is shown to verify vote extensions, but in reality all validators do.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"blockquote"},{"data":{},"content":[{"data":{},"marks":[],"value":"Optimistic block execution","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"This is one of the most straightforward applications of the powerful ABCI interface features introduced in newer CometBFT versions.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Briefly, this is the ability of the application to execute a block ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"before","nodeType":"text"},{"data":{},"marks":[],"value":" Comet finalizes that block. Without optimistic execution, the normal flow is (1) CometBFT finalizes a block, then (2) the application executes that block, and finally (3) the application gives control back to CometBFT. These 3 steps execute in a sequence. With optimistic execution, roughly speaking, steps (1) and (2) can run in parallel with one another. This enables shorter block production times.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Optimistic block execution is an optimization, and is in the same spirit as ","nodeType":"text"},{"data":{"uri":"https://en.wikipedia.org/wiki/Speculative_execution"},"content":[{"data":{},"marks":[],"value":"speculative execution","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" from conventional computing fields (eg databases or computer architecture).","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The SDK team describes this feature in more detail ","nodeType":"text"},{"data":{"uri":"https://medium.com/the-interchain-foundation/optimistic-execution-landing-in-the-cosmos-sdk-a28fc72af650"},"content":[{"data":{},"marks":[],"value":"here","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" for SDK release v0.50. Notably, the Sei team have been pioneering this feature in production as far back as ","nodeType":"text"},{"data":{"uri":"https://x.com/jayendra_jog/status/1573058066894946305?s=20"},"content":[{"data":{},"marks":[],"value":"September 2022","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Cross-chain coordination","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"The use-cases we discussed above have been anticipated ever since ABCI++ was initially proposed in ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/blob/v0.38.0-alpha.1/docs/rfc/tendermint-core/rfc-013-abci%2B%2B.md#short-list-of-blocked-features--scaling-improvements-with-required-abci-phases"},"content":[{"data":{},"marks":[],"value":"RFC 013","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", and we have been very excited to see teams building them out. This last category of use-cases, which we call “cross-chain coordination,” is completely novel and has emerged in the last several months.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Polygon PoS: tracking staking information from L1 into L2","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"First, let’s introduce the concept of a ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"side transaction","nodeType":"text"},{"data":{},"marks":[],"value":": a transaction that is special because it is not end-users that submit it, but validators themselves. The content, validity, and execution of a side transaction is contingent on state from a different blockchain network relative to the current application. This means that validating such transactions can be tricky, because their validity predicate is non-deterministic (i.e., depends on external state). Note that side transactions are not unlike transactions that update oracle prices in the first use-case we described above.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Second, the architecture here involves two systems: an L1 (Ethereum) and an L2. The L2 is the most interesting element for this discussion, and itself comprises two layers: (i) Bor, a fork of ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"geth","nodeType":"text"},{"data":{},"marks":[],"value":" which is called the \"block production layer\", and (ii) Heimdall, the \"validation layer\", a system built using CometBFT and Cosmos SDK, using vote extensions. We are interested in the validation layer of the L2. The data that goes into side transactions in the L2 comes from the L1 and concerns staking. The action of staking happens on the L1 and determines the voting power of validators in the L2, hence accurate staking data must somehow travel from the L1 to the L2, which is where side transactions — and vote extensions — come into play.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Armed with this knowledge, let’s describe the basic flow:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Suppose the L2 is constructing the block at height ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"H","nodeType":"text"},{"data":{},"marks":[],"value":":","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"code"}],"value":"PrepareProposal","nodeType":"text"},{"data":{},"marks":[],"value":": the block proposer adds side transactions to the proposal. As mentioned before, these transactions include staking information data pulled from the L1.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"code"}],"value":"ProcessProposal","nodeType":"text"},{"data":{},"marks":[],"value":": validators become aware and do basic validation of side transactions in the proposal. We call this step ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"external validation","nodeType":"text"},{"data":{},"marks":[],"value":" of side transactions.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"code"}],"value":"ExtendVote","nodeType":"text"},{"data":{},"marks":[],"value":": validators append a vote extension to their pre-commit; the extension includes the output of the external validation performed on the side transactions.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"The L2 is now constructing block height ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"H+1","nodeType":"text"},{"data":{},"marks":[],"value":":","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"code"}],"value":"PrepareProposal","nodeType":"text"},{"data":{},"marks":[],"value":": Proposer collects vote extensions (which include the output of external validation) from at least 2/3rd of validators (voting-power equivalent) and includes these in the proposal.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"code"}],"value":"ProcessProposal","nodeType":"text"},{"data":{},"marks":[],"value":": Validators verify the vote extensions included in the proposal.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"code"}],"value":"FinalizeBlock","nodeType":"text"},{"data":{},"marks":[],"value":": All full nodes tally up the extensions included in the decision (","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"H+1","nodeType":"text"},{"data":{},"marks":[],"value":") and based on them execute the side transactions included in the previous decision (","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"H","nodeType":"text"},{"data":{},"marks":[],"value":").","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"To recap, notice that validators cannot validate side transactions deterministically based purely on current L2 application state. Validators need input from some oracle, concretely the content of a contract in the L1. Reading from that contract may fail, or different validators may observe different states, hence they will have different views on the validity of side transactions, even without any Byzantine behavior at play. This arises from asynchrony or network failures, for example. Validators cannot simply accept/reject stake updates inside side transactions (inside vote extensions) from a block proposal. But once validators vote and the votes are tallied, they all accept the decision of the group regarding side transactions from height ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"H","nodeType":"text"},{"data":{},"marks":[],"value":" as that appears in ProcessProposal during height ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"H+1","nodeType":"text"},{"data":{},"marks":[],"value":". This happens even if some validators voted against a side transaction in the initial proposal.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"IBC-Sync & CoCage","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"Both of the next two use-cases of ABCI v2 have emerged during the \"ABCI++ track” of ","nodeType":"text"},{"data":{"uri":"https://dorahacks.io/hackathon/hackmos/results"},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Hackmos Istanbul (Oct 2023)","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[{"type":"bold"}],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"The ","nodeType":"text"},{"data":{"uri":"https://github.com/CyberHoward/ibc-sync"},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"IBC-Sync project","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" introduces an insightful new design to IBC packet relaying. In the current model, IBC relaying is a completely permissionless activity: Any user of an IBC-enabled blockchain can consume the IBC events from that blockchain and build appropriate IBC packets which they can subsequently submit to the counterparty IBC chain. This fully permissionless design can be an issue because relaying is performed ad-hoc by arbitrary actors, so no one in particular is responsible for this task. (This is not entirely accurate, as in practice there are professional teams operating relayers. Also, for a more detailed explanation of IBC relaying, see ","nodeType":"text"},{"data":{"uri":"https://www.ibcprotocol.dev/how-ibc-works"},"content":[{"data":{},"marks":[],"value":"here","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".)","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Instead of this current model, the ","nodeType":"text"},{"data":{"uri":"https://x.com/TheCyberHoward/status/1718595658163028027?s=20"},"content":[{"data":{},"marks":[],"value":"IBC-Sync design","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" ensures that validators ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"themselves","nodeType":"text"},{"data":{},"marks":[],"value":" perform the task of IBC packet relaying. This task is included in the normal flow of block construction. Each validator pulls outstanding IBC packets from connected chains and uses ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"ExtendVote","nodeType":"text"},{"data":{},"marks":[],"value":" to inject those packets (alongside appropriate IBC client update) into the block that is being constructed. The IBC packets then become ordinary transactions that are included and executed in the subsequent block.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"The ","nodeType":"text"},{"data":{"uri":"https://github.com/Wondertan/cocage"},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"CoCage project","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" is similar to IBC-Sync in the sense that the goal is the same, to relay IBC packets, i.e., cross-chain messages. It is entirely different from IBC-Sync because in CoCage the model involves a rollup and a Cosmos SDK chain (in contrast, in IBC-Sync the model involved two SDK chains). Beside a rollup and an SDK chain, there is also a third system involved, namely a Data Publication (DP) network such as Celestia.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The goal is for the SDK chain to verify IBC packets that originate from the rollup. To do so, validators are tasked with running a local light node for the DP network and to regularly sample blocks from this network. These blocks are important because they contain rollup transactions (as well as the application root hash). If the SDK chain can obtain reliable data about blocks in the DP, they can correlate that data against IBC packets originating from the rollup, and can therefore trust these packets. The basic steps here are as follows:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Validators use ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"ExtendVote","nodeType":"text"},{"data":{},"marks":[],"value":" to extend their pre-commit with new block height(s) sampled from the DP. Specifically, for each height, the validator inserts data commitments extracted from the DP via their local instance of a light node.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"During ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"PrepareProposal","nodeType":"text"},{"data":{},"marks":[],"value":", the proposer collects the vote extensions and includes them in the proposed block. This only happens for heights that have not been sampled before, and for which there is a minimum threshold (over 2/3 voting power-equivalent) of votes.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"During ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"ProcessProposal","nodeType":"text"},{"data":{},"marks":[],"value":", each validator only accepts the proposed block if they have previously sampled the same block heights as present in the vote extensions and can attest to their validity; otherwise each validator rejects the block proposal. This is also a form of external validation (as in the Polygon L2 use-case), and this validation is also not guaranteed to be deterministic due to RPC failures, for example, or inconsistency due to light client attacks.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"We recommend interested readers to check ","nodeType":"text"},{"data":{"uri":"https://github.com/Wondertan/cocage?tab=readme-ov-file#use-case"},"content":[{"data":{},"marks":[],"value":"detailed architecture","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" and design in the repo directly to understand how the commitments are stored, and how IBC clients can used these commitments for IBC packet proof verification.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Further references","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/blob/v0.38.0-alpha.1/docs/rfc/tendermint-core/rfc-013-abci++.md#rfc-013-abci"},"content":[{"data":{},"marks":[],"value":"RFC 013: ABCI++","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":": The first RFC that proposed ABCI++ has a very ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/blob/v0.38.0-alpha.1/docs/rfc/tendermint-core/rfc-013-abci%2B%2B.md#short-list-of-blocked-features--scaling-improvements-with-required-abci-phases"},"content":[{"data":{},"marks":[],"value":"good table","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" describing improvements that ABCI++ unlocks.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"","nodeType":"text"},{"data":{"uri":"https://docs.polygon.technology/pos/architecture/"},"content":[{"data":{},"marks":[],"value":"Polygon L2 (PoS) architecture documentation","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"contentfulURL":"https://app.contentful.com/spaces/p79kctcd7ahy/entries/13H9rtFsYLm783JLdLHMBR"},{"featureImage":"$4:props:posts:29:featureImage","date":"2024-04-15","title":"Hub Monthly Update - March 2024","slug":"hub-monthly-update-march-2024","categories":["Engineering"],"authors":["Marius Poke"],"keywords":"ICS 2.0 implementation\nPartial Set Security\nmodel-based testing\nCosmos SDK v0.47\nICS epochs\nMegablocks architecture\nvalidator opt-in\nQuint formal verification\nemergency upgrade coordination\nparallel execution","excerpt":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Cosmos Hub v15 SDK upgrade plus ICS epochs and Megablocks parallel execution.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"includeTableOfContents":false,"body":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Cosmos Hub Update - March 2024","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"It’s time for the usual update from the Informal Systems’ Cosmos Hub team. Here are some of the highlights:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Coordinated the Cosmos Hub emergency upgrade to Gaia v14.2.0.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Coordinated the Cosmos Hub v15 upgrade.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Continue working on the integration phase for Gaia v16.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Completed the work on adding Model-Based Testing to ICS.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Completed the implementation of ICS Epochs.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Completed the first draft of the ICS 2.0 implementation.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Completed the spike phase of Megablocks.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"Note that we use ","nodeType":"text"},{"data":{"uri":"https://forum.cosmos.network/t/cosmos-hub-improvement-process-chips/11765"},"content":[{"data":{},"marks":[],"value":"CHIPs","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" to track the progress of our work. Hence, throughout this update, we make several references to different phases of the CHIPs framework.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Cosmos Hub v14.2 Emergency Upgrade","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"At the beginning of March, the Cosmos Hub underwent an emergency upgrade to ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/gaia/releases/tag/v14.2.0"},"content":[{"data":{},"marks":[],"value":"Gaia v14.2.0","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". This emergency upgrade was necessary to fix a vulnerability in the Packet Forward Middleware module. For details, check out the ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/ibc-apps/security/advisories/GHSA-v8p4-qhq4-f7h8"},"content":[{"data":{},"marks":[],"value":"advisory","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". Thanks to the Strangelove team for fixing the issue, Amulet for bringing it to our attention, and the validator community for a smooth upgrade.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Cosmos Hub v15 Upgrade","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"During March, the Cosmos Hub upgraded to ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/gaia/releases/tag/v15.1.0"},"content":[{"data":{},"marks":[],"value":"Gaia v15.1.0","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". This upgrade is a significant milestone for the Hub as it upgraded to Cosmos SDK ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/cosmos-sdk/tree/v0.47.10-ics-lsm"},"content":[{"data":{},"marks":[],"value":"v0.47","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". This upgrade moved the Hub away from SDK v0.45 (marked as end-of-life) and enables a series of new integrations, such as the ","nodeType":"text"},{"data":{"uri":"https://github.com/skip-mev/block-sdk/tree/main"},"content":[{"data":{},"marks":[],"value":"Skip Block SDK","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" (requested by the community in ","nodeType":"text"},{"data":{"uri":"https://www.mintscan.io/cosmos/proposals/842"},"content":[{"data":{},"marks":[],"value":"prop 842","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":").","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"As expected, the upgrade took longer than usual (around 2h) due to the vast amount of state migrations necessary to upgrade from Cosmos SDK v0.45 to v0.47. As the Hub stores a non-trivial amount of data regarding delegations and the number of accounts, any large database migration will take time. Note that software upgrades that use the same version of Cosmos SDK are usually much faster because there are no large database migrations to execute.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"In addition to the state migration, there was confusion regarding the Gaia version required for the update. Due to the v14.2.0 emergency upgrade that happened while the ","nodeType":"text"},{"data":{"uri":"https://www.mintscan.io/cosmos/proposals/885"},"content":[{"data":{},"marks":[],"value":"v15 software upgrade proposal","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" was online, it was necessary to use a different Gaia release (","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/gaia/releases/tag/v15.1.0"},"content":[{"data":{},"marks":[],"value":"v15.1.0","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":") instead of the one mentioned in the proposal (","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/gaia/releases/tag/v15.0.0"},"content":[{"data":{},"marks":[],"value":"v15.0.0","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"). Thanks to the validator community for the upgrade; we appreciate the feedback.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Gaia v15.2.0","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"After the upgrade to SDK v0.47, the metadata length for gov proposals was set to the default of 255, which affects the description field. As a workaround, proposals need to use IPFS links in the description (see the ","nodeType":"text"},{"data":{"uri":"https://www.mintscan.io/cosmos/proposals/897"},"content":[{"data":{},"marks":[],"value":"ICS 2.0 signaling proposal","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" as an example). To fix this issue (and restore the previous behavior), we cut a new release for Gaia v15 (see the release candidate ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/gaia/releases/tag/v15.2.0-rc0"},"content":[{"data":{},"marks":[],"value":"here","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":") and scheduled a coordinated upgrade on April 10th.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Gaia v16 - Integration Phase","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"Throughout the month, we worked on the next major release of Gaia — v16 — which will integrate several features made possible by the upgrade to SDK v0.47.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"First, we finished integrating the ","nodeType":"text"},{"data":{"uri":"https://ibc.cosmos.network/v7/apps/interchain-accounts/overview"},"content":[{"data":{},"marks":[],"value":"ICA controller","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" and adding e2e tests. This first iteration of the ICA controller on the Hub will enable Hub users to perform actions on other chains using their Hub accounts. This is done by creating interchain accounts on other chains (with the ICA host enabled) and using the ICA controller module to send messages directly from the Hub. In a future release, we plan to enable additional use cases, for example, allowing the NTRNs in the community pool to participate in Neutron’s governance.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Second, we finished integrating the Stride Labs’ implementation of the ","nodeType":"text"},{"data":{"uri":"https://github.com/Stride-Labs/ibc-rate-limiting"},"content":[{"data":{},"marks":[],"value":"IBC Rate Limit module","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" and adding e2e tests. This module will add an extra layer of protection to IBC transfer channels in case of an exploited vulnerability. We also devised initial rate limits for the Cosmos Hub, started a ","nodeType":"text"},{"data":{"uri":"https://forum.cosmos.network/t/proposal-890-voting-signaling-proposal-ibc-rate-limiting/13410"},"content":[{"data":{},"marks":[],"value":"discussion","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" on the forum, and submitted a ","nodeType":"text"},{"data":{"uri":"https://www.mintscan.io/cosmos/proposals/890"},"content":[{"data":{},"marks":[],"value":"signaling proposal","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". The proposal passed, and so we’ll work next on adding these initial rate limits to the v16 upgrade handler.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Finally, while working to integrate the ","nodeType":"text"},{"data":{"uri":"https://github.com/skip-mev/block-sdk/tree/main"},"content":[{"data":{},"marks":[],"value":"Skip Block SDK","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" and include the ","nodeType":"text"},{"data":{"uri":"https://github.com/skip-mev/feemarket/tree/main"},"content":[{"data":{},"marks":[],"value":"EIP-1559 fee market lane","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" (cf. ","nodeType":"text"},{"data":{"uri":"https://www.mintscan.io/cosmos/proposals/842"},"content":[{"data":{},"marks":[],"value":"prop 842","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"), we realized that some changes are needed to the fee market module. First, we need to align the implementation of the minimum base fee with Cosmos SDK to avoid a considerable increase in the transaction fees. Second, given that EIP-1559 will change the current behavior — base fees will be collected in a separate pool instead of being distributed to the validators and their delegators — we need to add gov-gated mechanism to either burn or move to the community pool the collected base fees. Depending on the time it takes to make and test these changes, we might push the Skip Block SDK and the fee market module to a future Gaia release.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The work on v16 can be tracked in this ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/gaia/issues/2868"},"content":[{"data":{},"marks":[],"value":"EPIC","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Upgrade ICS to SDK v0.50","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"We cut an ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/interchain-security/releases/tag/v5.0.0-alpha1"},"content":[{"data":{},"marks":[],"value":"alpha release","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" for ICS v5 in March that uses ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/cosmos-sdk/tree/release/v0.50.x"},"content":[{"data":{},"marks":[],"value":"Cosmos SDK v0.50","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". First, upgrading ICS to SDK v0.50 is a prerequisite of upgrading Gaia to SDK v0.50. Second, this enables consumer chains to start integrating the ICS consumer module, which increases the adoption of SDK v0.50.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Model-Based Testing","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"At the end of last year, we enabled the ","nodeType":"text"},{"data":{"uri":"https://informal.systems/blog/model-based-testing-for-the-cosmos-hub"},"content":[{"data":{},"marks":[],"value":"first iteration of Model-Based Testing","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" (MBT) on Interchain Security using ","nodeType":"text"},{"data":{"uri":"https://github.com/informalsystems/quint"},"content":[{"data":{},"marks":[],"value":"Quint","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". This work aims to increase the confidence in our implementation and, consequently, development velocity — the more confidence we have in our releases, the faster we can ship new ICS features. Throughout this last quarter, we expanded the Quint model of ICS by adding existing features that were missing, such as key assignment and consumer-initiated slashing, and new features, such as epochs and partial set security. We are happy to say that we completed this work, and MBT is part of our CI. Next, we want to summarize and apply what we have learned to improve confidence in our releases.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"ICS Epochs","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"We completed the implementation of ICS epochs and released it as part of ICS v4.1.0 (see the release candidate ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/interchain-security/releases/tag/v4.1.0-rc0"},"content":[{"data":{},"marks":[],"value":"here","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"). The main benefit of epochs is reducing the cost of relaying for ICS. In addition, epochs introduce a new functionality — ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"power shaping","nodeType":"text"},{"data":{},"marks":[],"value":" — that allows the manipulation of validator sets and consequently increases the velocity of ICS development. It already proved to facilitate the implementation of partial set security and it also simplified the key assignment logic. We plan to add ICS v4.1.0 (with epochs) to Gaia v16, so it will be part of the next major Cosmos Hub upgrade.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"ICS 2.0 (aka Partial Set Security) - Implementation and Testnet Phases","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"We completed the first draft of the ICS 2.0 implementation that contains the main features described in ","nodeType":"text"},{"data":{"uri":"https://cosmos.github.io/interchain-security/adrs/adr-015-partial-set-security"},"content":[{"data":{},"marks":[],"value":"ADR 015","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":":","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Enable consumer chains to join as either ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"italic"}],"value":"Top N","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":" (the top N% of the voting power on the Hub must validate the consumer) or ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"italic"}],"value":"Opt-In","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":" (validation on the consumer is completely optional).","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Enable validators to opt-in and out of validating any given consumer chain.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Send partial validator sets to the consumer chains.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Distribute consumer rewards only to opted-in validators.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"The code is already running on a devnet that we are running together with Hypha. The devnet is an excellent opportunity to improve UX and minor issues in preparation for the ICS 2.0 incentivized testnet. We also submitted a ","nodeType":"text"},{"data":{"uri":"https://www.mintscan.io/cosmos/proposals/897"},"content":[{"data":{},"marks":[],"value":"signaling proposal","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" to ask the Cosmos Hub community for approval. Next, we will continue coordinating with Hypha on the incentivized testnet and working on addition features, such as fraud proofs.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Megablocks","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"We completed the spike phase of Megablocks. We created a prototype — an ABCI multiplexer shim — that allows multiple Cosmos SDK applications to run on a single instance of CometBFT. This enables parallel execution and is a building block for ","nodeType":"text"},{"data":{"uri":"https://docs.google.com/document/d/1w5HdXVhiR2BRkFIDjNZ1V3BbXTGeA3rqp5J-slj4k6w/edit#heading=h.czj3rkyv6gzn"},"content":[{"data":{},"marks":[],"value":"Atomic IBC","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" (a form of atomic composability). For more details on this architecture, look at this ","nodeType":"text"},{"data":{"uri":"https://forum.cosmos.network/t/chips-discussion-phase-atomic-ibc-megablocks/11767"},"content":[{"data":{},"marks":[],"value":"forum post","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". We also created a screencast showing how Megablocks works, which we’ll publish soon.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Others","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"There were two other achievements, which, although they are not major rocks on our roadmap, we think are significant enough to be mentioned.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"First, we fixed an ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/gaia/issues/2877"},"content":[{"data":{},"marks":[],"value":"issue","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" in the Liquid Staking Module (LSM) — vesting account users could not tokenize already vested delegations and, consequently, could not convert them into liquid stake. Thanks to Billy Rennekamp for bringing this issue to our attention. The ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/cosmos-sdk/pull/19614"},"content":[{"data":{},"marks":[],"value":"fix","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" was added to the ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/cosmos-sdk/releases/tag/v0.47.11-ics-lsm"},"content":[{"data":{},"marks":[],"value":"special Cosmos SDK release","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" used by the Cosmos Hub and will be part of Gaia v16.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Second, we helped resolve a relaying issue on ICS: On the Hub side of the ICS channel between Cosmos Hub and Stride, a lot of ICS packets were pending (not being cleared out by relayers). As a result, the SlashPackets sent by Stride were not acknowledged, which triggered the downtime throttling mechanism and blocked the sending of all ICS packets from Stride. Although this behavior is expected (see ","nodeType":"text"},{"data":{"uri":"https://cosmos.github.io/interchain-security/adrs/adr-008-throttle-retries"},"content":[{"data":{},"marks":[],"value":"ADR 008","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" for more details), if left unchecked, it might affect the UX on the Hub — the delays introduced in VSCMaturedPackets could lead to unbonding operations (e.g., Undelegations) on the Hub to be delayed. Once the Informal Systems validator team started using Hermes with clear_interval enabled all the packets got cleared, and the issue was solved. To facilitate monitoring of such scenarios, we added a new query to ICS — oldest_unconfirmed_vsc — that enables operators to query on the Hub the send timestamp of the oldest unconfirmed VSCPacket by consumer chain ID. We will add the query to Gaia v16.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"What This Enables","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"This month’s increment of work heavily supported the delivery of our long-term roadmap with the following notable highlights:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"We are moving into testnet next for Partial Set Security and looking good to launch ICS 2.0 in Q2, which is an exciting milestone for the future vision of the Hub.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"The equal amount of attention we give to developing and coordinating releases of regular upgrades and rapid vulnerability patching ensures that the Hub remains one of the safest crypto chains on the planet.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"An increased focus on collaboration across multiple customer groups (e.g., validators and partner development organizations) allows us to strengthen the community around the Cosmos Hub and get closer feedback on our product roadmap and plans.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"ordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"Our roadmap for Q2 will be released in April, which will detail our primary objectives for the quarter and how they ladder up to making the Cosmos Hub the best place to launch a chain.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"contentfulURL":"https://app.contentful.com/spaces/p79kctcd7ahy/entries/3seeWdCdVhwyQumcBxM9T9"},{"featureImage":"$4:props:posts:29:featureImage","date":"2024-03-13","title":"Hub Monthly Update - February 2024","slug":"hub-monthly-update-february-2024","categories":["Engineering"],"authors":["Marius Poke "],"keywords":"ICS Epochs implementation\nPartial Set Security\nLiquid Staking Module\nCosmos SDK v0.50\nBabylon Bitcoin staking\nmodel-based testing\nATOM Wars governance\nIBC rate limiting\nQuint formal verification\nMegablocks architecture","excerpt":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Cosmos Hub v15 testnet plus LSM SDK v0.50 upgrade and Babylon Bitcoin staking.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"includeTableOfContents":false,"body":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"It’s time for the usual update from the Informal Systems’ Cosmos Hub team. Here are some of the highlights:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"We completed the testnet phase of Gaia v15.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"We started the preparatory work for Gaia v16.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"We started upgrading the LSM to SDK v0.50 (a prerequisite for upgrading Gaia to SDK v0.50).","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"We started the implementation phase for both ICS Epochs and Partial Set Security.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"We collected, reviewed and implemented community & customers feedback on AtomWars.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"We started the discussion on the Babylon integration with the Cosmos Hub.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"Note that we use ","nodeType":"text"},{"data":{"uri":"https://forum.cosmos.network/t/cosmos-hub-improvement-process-chips/11765"},"content":[{"data":{},"marks":[],"value":"CHIPs","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" to track the progress of our work. Hence, throughout this update we make several references to different phases of the CHIPs framework.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Gaia v15 - Testnet Phase","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"In the last months, we worked on upgrading the Cosmos Hub to use Cosmos SDK v0.47. This upgrade will move the Hub away from SDK v0.45 (which is marked as end-of-life) and enable a series of integrations, such as the ","nodeType":"text"},{"data":{"uri":"https://github.com/skip-mev/block-sdk/tree/main"},"content":[{"data":{},"marks":[],"value":"Skip Block SDK","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" (which was requested by the community in ","nodeType":"text"},{"data":{"uri":"https://www.mintscan.io/cosmos/proposals/842"},"content":[{"data":{},"marks":[],"value":"prop 842","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"). See the Gaia v16 section below for more details in future integrations.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Throughout this month, we cut a series of release candidates for Gaia v15 that were used to upgrade the public testnets - both the release and the replicated security testnets. This work entailed fixing several integration bugs found during testing, upgrading to the ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/cosmos-sdk/releases/tag/v0.47.10"},"content":[{"data":{},"marks":[],"value":"latest point release of SDK 0.47","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", and adding support for ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/gaia/tree/release/v15.x/x/metaprotocols"},"content":[{"data":{},"marks":[],"value":"metaprotocols","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" using the transaction extension options. The support for metaprotocols was necessary as the upgrade to SDK 0.47 was breaking for the ","nodeType":"text"},{"data":{"uri":"https://github.com/astroport-fi/asteroid-protocol/tree/main"},"content":[{"data":{},"marks":[],"value":"Asteroid Protocol","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", a protocol that enables arbitrary inscriptions on Cosmos Hub.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"In addition, we updated both the ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/gaia/blob/release/v15.x/UPGRADING.md"},"content":[{"data":{},"marks":[],"value":"upgrading guide","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" and the ","nodeType":"text"},{"data":{"uri":"https://hub.cosmos.network"},"content":[{"data":{},"marks":[],"value":"docs","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Finally, we started the discussion within the community by posting a ","nodeType":"text"},{"data":{"uri":"https://forum.cosmos.network/t/proposal-draft-gaia-v15-software-upgrade/13302"},"content":[{"data":{},"marks":[],"value":"draft of the v15 software upgrade","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" on the forum.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The next steps for Gaia v15 are the voting and deployment phases. The target upgrade date is March 20th.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Gaia v16","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"We started working on Gaia v16, which will integrate several features that are made possible by the upgrade to SDK 0.47.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"First, we are working together with Skip to adopt the ","nodeType":"text"},{"data":{"uri":"https://github.com/skip-mev/block-sdk/tree/main"},"content":[{"data":{},"marks":[],"value":"Skip Block SDK","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" and include the ","nodeType":"text"},{"data":{"uri":"https://github.com/skip-mev/feemarket/tree/main"},"content":[{"data":{},"marks":[],"value":"EIP-1559 fee market lane","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" (cf. ","nodeType":"text"},{"data":{"uri":"https://www.mintscan.io/cosmos/proposals/842"},"content":[{"data":{},"marks":[],"value":"prop 842","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":").","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Second, we are working towards enabling the ICA controller on the Cosmos Hub, which will enable the Hub to control accounts on remote chains. We are currently working together with the Neutron team to define a first use case — enabling the NTRNs in the community pool to participate in Neutron’s governance. Once we clarify all the details, we’ll post a signaling proposal on the forum and on the Hub.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Finally, we are working together with Stride Labs to integrate their implementation of the ","nodeType":"text"},{"data":{"uri":"https://github.com/Stride-Labs/ibc-rate-limiting"},"content":[{"data":{},"marks":[],"value":"IBC Rate Limit","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" module. This will add an extra layer of protection to IBC transfer channels in case of an exploited vulnerability. The module was already moved to its own repo, making it easier to integrate on other chains than Stride (thanks to the Stride team for this work). We are working on a proposal on the initial rate limits for the Cosmos Hub. We’ll soon post a draft on the forum.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The work on v16 can be tracked in this ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/gaia/issues/2868"},"content":[{"data":{},"marks":[],"value":"EPIC","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Upgrade the Liquid Staking Module to SDK v0.50","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"The Liquid Staking Module (LSM) was added to the Cosmos Hub as part of the v12 upgrade (as requested by the community in ","nodeType":"text"},{"data":{"uri":"https://www.mintscan.io/cosmos/proposals/790"},"content":[{"data":{},"marks":[],"value":"proposal 790","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"). The integration to Gaia required moving the Hub on a special branch of the SDK (i.e., ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/cosmos-sdk/tree/v0.45.16-ics-lsm"},"content":[{"data":{},"marks":[],"value":"v0.45.16-ics-lsm","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" starting with Gaia v12 and ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/cosmos-sdk/releases/tag/v0.47.10-ics-lsm"},"content":[{"data":{},"marks":[],"value":"v0.47.10-ics-lsm","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" starting with Gaia v15). Important to note is that having LSM on a special branch of SDK means that LSM is not being automatically upgraded with mainline SDK. Thus, LSM requires continuous maintenance until it gets added to mainline SDK. For this reason, we started upgrading LSM to SDK v0.50 (as a prerequisite of upgrading Gaia to SDK v0.50). You can follow the progress ","nodeType":"text"},{"data":{"uri":"https://github.com/informalsystems/cosmos-sdk/pull/13"},"content":[{"data":{},"marks":[],"value":"here","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Model-Based Testing","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"In the last months, we have been working on enabling Model-Based Testing (MBT) on Replicated Security, with the purpose of increasing the confidence of our implementation and, consequently, development velocity. Our approach entails using a ","nodeType":"text"},{"data":{"uri":"https://github.com/informalsystems/quint"},"content":[{"data":{},"marks":[],"value":"Quint","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" model of the protocol to generate tests. Check out this ","nodeType":"text"},{"data":{"uri":"https://informal.systems/blog/model-based-testing-for-the-cosmos-hub"},"content":[{"data":{},"marks":[],"value":"blog post","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" for more details.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"This month, we started working on adding ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/ibc/blob/main/spec/app/ics-028-cross-chain-validation/overview_and_basic_concepts.md#consumer-initiated-slashing"},"content":[{"data":{},"marks":[],"value":"consumer initiated slashing","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" to the Quint model and integrated it with MBT. You can follow the work ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/interchain-security/pull/1640"},"content":[{"data":{},"marks":[],"value":"here","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". We also ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/interchain-security/pull/1627"},"content":[{"data":{},"marks":[],"value":"expanded the Quint model","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" to include the Partial Set Security (PSS) logic and built the driver to be able to connect it to MBT once the PSS implementation is ready.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"ICS Backward Compatibility Testing","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"Previously, we ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/interchain-security/pull/1486"},"content":[{"data":{},"marks":[],"value":"updated the ICS e2e test infrastructure","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" to enable backwards compatibility tests. In this month, we finalized this work by ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/interchain-security/pull/1656"},"content":[{"data":{},"marks":[],"value":"adding backward compatibility tests to ICS","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". This means that moving forward, these tests are running in our CI, which will increase our confidence in future ICS releases.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"ICS Epochs – Implementation Phase","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"We started implementing ICS Epochs (cf. ","nodeType":"text"},{"data":{"uri":"https://cosmos.github.io/interchain-security/adrs/adr-014-epochs"},"content":[{"data":{},"marks":[],"value":"ADR 014","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"). The ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/interchain-security/pull/1660"},"content":[{"data":{},"marks":[],"value":"implementation","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" is currently under review and we plan to release it as part of Gaia v16.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"In addition to the initial benefits — reducing the cost of relaying for ICS — the changes made for epochs will facilitate the PSS implementation. Without going into details, the new approach introduces functionalities to manipulate validator sets, such as filtering out validators that are not opted in.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Partial Set Security - Implementation Phase","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"We started the implementation of PSS (cf. ","nodeType":"text"},{"data":{"uri":"https://cosmos.github.io/interchain-security/adrs/adr-015-partial-set-security"},"content":[{"data":{},"marks":[],"value":"ADR 015","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"). We enabled Top-N and Opt-In consumer chains to join via governance proposal, we added messages for validators to opt in and out of PSS, and we adapted the reward distribution protocol so that only opted in validators receive consumer rewards. We also started working on constructing and sending a partial validator set to consumer chains.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The work on PSS can be tracked in this ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/interchain-security/issues/853"},"content":[{"data":{},"marks":[],"value":"EPIC","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Megablocks - Spike Phase","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"We continued the spike phase of ","nodeType":"text"},{"data":{"uri":"https://forum.cosmos.network/t/chips-discussion-phase-atomic-ibc-megablocks/11767"},"content":[{"data":{},"marks":[],"value":"Megablocks","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". We completed the implementation of the multiplexer shim with basic ABCI++ forwarding functionality between CometBFT and the application, including e2e testing. The next step is to add support for the multiplexer shim to handle multiple applications","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"ATOM Wars - Discussion Phase","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"End of January, we posted a ","nodeType":"text"},{"data":{"uri":"https://forum.cosmos.network/t/the-atom-wars-a-new-governance-platform-for-liquidity-injections/13122?u=thyborg"},"content":[{"data":{},"marks":[],"value":"design proposal","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" for the “ATOM wars” governance platform. The forum post received many thoughtful feedbacks and valuable ideas. Several projects contacted us privately to express their interest in participating in the system to receive liquidity injections. We also pro-actively reached out to a handful of major Cosmos chains to understand what we could do to make sure they would take part in the bidding process. We then aggregated & reviewed all the feedbacks & ideas, and made a couple of updates to the original design.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Our goal is now publish an updated version of the system under the form of a litepaper that will be attached to a governance proposal requesting the community pool to allocate some ATOMs to seed the first liquidity bucket.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Babylon - Discussion Phase","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"We posted on the Cosmos Hub forum a ","nodeType":"text"},{"data":{"uri":"https://forum.cosmos.network/t/bringing-bitcoin-security-to-the-cosmos-hub-with-babylon/13280"},"content":[{"data":{},"marks":[],"value":"description of how Babylon will integrate with Cosmos Hub","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". In a nutshell, the idea is to enable Bitcoin holders to secure ICS consumer chains through ","nodeType":"text"},{"data":{"uri":"https://docs.babylonchain.io/assets/files/btc_staking_litepaper-32bfea0c243773f0bfac63e148387aef.pdf"},"content":[{"data":{},"marks":[],"value":"Babylon’s Bitcoin staking protocol","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". This is part of a larger strategy to make the Cosmos Hub a security aggregator, bringing together staked assets from many sources, a battle tested validator set, and innovative consumer chains.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Replicated Security as a read only protocol","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"Last quarter we looked into simplifying the Replicate Security protocol by removing one of the three message types – the VSCMaturedPackets (see the ","nodeType":"text"},{"data":{"uri":"https://informal.systems/blog/cosmos-hub-update-q4-2023"},"content":[{"data":{},"marks":[],"value":"Q4 updates","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"). Although such a simplification would make it easier to iterate and bring improvements, such as Partial Set Security, we believe that VSCMaturedPackets cannot be removed without compromising the security of the system. This month, we published a blog post — ","nodeType":"text"},{"data":{"uri":"https://informal.systems/blog/learning-to-live-with-unbonding-pausing"},"content":[{"data":{},"marks":[],"value":"Learning to Live with “Unbonding Pausing”","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" — with our findings.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"contentfulURL":"https://app.contentful.com/spaces/p79kctcd7ahy/entries/2SORPeTwQCzZcral9x6XT4"},{"featureImage":"$4:props:posts:27:featureImage","date":"2024-03-12","title":"Informal as a Business: Recap & Outlook","slug":"informal-business","categories":["Company"],"authors":["Ethan Buchman"],"keywords":"informal-systems, cosmos-development, cometbft-stewardship, blockchain-audits, cosmos-hub, interchain-security, cycles-payments, validator-services, blockchain-business, cosmos-funding","excerpt":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"How we diversified from Cosmos R&D into security audits, staking, and Cycles.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"includeTableOfContents":false,"body":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Last year, we published ","nodeType":"text"},{"data":{"uri":"https://informal.systems/blog/informal-cosmos"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"a comprehensive overview of Informal’s work and funding","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" over the first three years of our life as a Cosmos public goods R&D organization primarily funded by the ICF. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"In 2023, we continued to ship critical developments in Cosmos, like Interchain Security and ABCI++, both of which have unlocked powerful new capabilities for the ecosystem. See our 2023 recap for the ","nodeType":"text"},{"data":{"uri":"https://informal.systems/blog/informal-systems-hub-team-year-end-recap"},"content":[{"data":{},"marks":[],"value":"Cosmos Hub","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", for ","nodeType":"text"},{"data":{"uri":"https://informal.systems/blog/reflecting-on-our-cometbft-2023-journey-a-retrospective"},"content":[{"data":{},"marks":[],"value":"CometBFT","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", and more on our ","nodeType":"text"},{"data":{"uri":"https://informal.systems/blog"},"content":[{"data":{},"marks":[],"value":"blog","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"\nBut 2023 also marked a significant transition year for us in growing our business and reducing ICF funding. In particular, we: ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"","nodeType":"text"},{"data":{"uri":"https://www.theblock.co/post/233451/informal-systems-funding-round"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Raised our first round","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", $5.3M from a wonderful group of investors","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Audited top projects like Celestia, dYdX, Neutron, Anoma, Polymer, Skip and more","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Co-led (with ","nodeType":"text"},{"data":{"uri":"https://hypha.coop/"},"content":[{"data":{},"marks":[],"value":"Hypha","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":") a","nodeType":"text"},{"data":{"uri":"https://www.mintscan.io/cosmos/proposals/839"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":" groundbreaking $5.7M governance proposal","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" for the Cosmos Hub","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Worked with leading rollup projects to bring Cosmos tech into the modular era (more details coming soon!)","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Grew our amazing delegator community and our relaying services ","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Launched ","nodeType":"text"},{"data":{"uri":"https://insights.informal.systems/"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Insights","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", an IBC monitor","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Began product development on ","nodeType":"text"},{"data":{"uri":"https://twitter.com/cyclesmoney"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Cycles","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[{"type":"underline"}],"value":",","nodeType":"text"},{"data":{},"marks":[],"value":" the future of payments and credit","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"While we remain a core contributor to Cosmos R&D, we're evolving as a business in exciting directions.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"A brief historical recap:","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"Informal spun out from the ICF in 2020 with a convertible note and two years of funding for R&D on Formal Methods and Cosmos in Rust (see more on our ","nodeType":"text"},{"data":{"uri":"https://informal.systems/blog/informal-origins"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"origins","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"). With this bootstrap, Informal intended to build a sustainable business advancing Cosmos in Rust and Formal Methods. However, due to organizational challenges at the ICF and across Cosmos, we put a lot on hold in 2021 and 2022 to better support the ICF with core Cosmos development. This primarily took the form of building new Go development teams at Informal for both the Cosmos Hub and Tendermint (now forked as CometBFT). Ultimately, this culminated in Informal taking over stewardship for both products from the ICF’s internal development teams. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"In 2023, there were significant simplifications and improvements in the formalization of stewardship over core Cosmos components. Essentially, the ICF team was reduced to stewardship of IBC, the Binary Builders team spun out of the ICF to become steward for the Cosmos-SDK, and Informal became the steward for Comet and the Cosmos Hub. Informal also took steps to reduce its formal methods work for the ICF going into 2023 (with funding for this work ending altogether in Q2 2023).","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Overall, Informal’s ICF revenue in 2023 was reduced by over 15% from 2022, and in 2024, Informal reduced its ICF funding by another 60% down to a maximum of $5.5M, which covers stewardship of Comet, Hermes, and ibc-rs. The Hub team at Informal is now funded directly by ","nodeType":"text"},{"data":{"uri":"https://mintscan.io/cosmos/proposals/839"},"content":[{"data":{},"marks":[],"value":"prop839","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"While Informal has significantly reduced funding from the ICF, we are working closely with other partners in and around the Cosmos and Ethereum ecosystems, continuing to advance the interchain.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"What’s next for Informal as a Business? ","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"Throughout the years, Informal has grown and diversified its activities, advancing the state of the art in diverse disciplines, from the infrastructure of the interchain to distributed systems, formal methods, and monetary theory. At our core, we remain a multidimensional company, unified by a common goal—fostering trust in software and money.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Going into 2024, we think of Informal as composed of 5 ventures, falling into three categories of businesses:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Core Development","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Interchain:","nodeType":"text"},{"data":{},"marks":[],"value":" Core development services across the interchain and lead developer for ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/"},"content":[{"data":{},"marks":[],"value":"CometBFT","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", ","nodeType":"text"},{"data":{"uri":"https://github.com/informalsystems/hermes/"},"content":[{"data":{},"marks":[],"value":"Hermes","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", and ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/ibc-rs"},"content":[{"data":{},"marks":[],"value":"ibc-rs","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Cosmos Hub:","nodeType":"text"},{"data":{},"marks":[],"value":" Core contributor to the Cosmos Hub blockchain, per ","nodeType":"text"},{"data":{"uri":"https://mintscan.io/cosmos/proposals/839"},"content":[{"data":{},"marks":[],"value":"prop839","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Services","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Informal Security:","nodeType":"text"},{"data":{},"marks":[],"value":" Security services for Cosmos and beyond: audits, specification, and testing","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Informal Staking:","nodeType":"text"},{"data":{},"marks":[],"value":" Secure and reliable interchain operations: PoS validator, IBC relayer, network operator ","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Products/Protocols","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Cycles:","nodeType":"text"},{"data":{},"marks":[],"value":" Graph-based payments and credit platform. The future of DeFi ","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"Of these, only the Interchain team is still funded (but not entirely) by the ICF, while the Hub team is funded by the community pool via prop839, and the others are funded by our customers and our investors. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"This revenue diversification doesn’t mean we’re reducing our commitment and focus in Cosmos, but rather, we are actively looking for ways to make Cosmos funding more sustainable and to develop and build high-leverage businesses that serve Cosmos and beyond. If you’re interested in working with us through any of our ventures or exploring new ways we could work together, please get in touch by email (","nodeType":"text"},{"data":{"uri":"mailto:hello@informal.systems"},"content":[{"data":{},"marks":[],"value":"hello@informal.systems","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":") or on Twitter (","nodeType":"text"},{"data":{"uri":"https://twitter.com/informalinc"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"@informalinc","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":")! ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Looking ahead to 2024 ","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"2024 is a year of focus and acceleration for Informal. Our Interchain team is focused on bringing Comet and IBC everywhere, with the best performance and capabilities on the market. Our Cosmos Hub team is focused on scaling the Hub’s Interchain Security offering, making it the best place to launch a chain and to access interchain security and interchain capital. Informal Security continues to serve our partners and clients while bringing ","nodeType":"text"},{"data":{"uri":"https://github.com/informalsystems/quint"},"content":[{"data":{},"marks":[],"value":"Quint","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", our powerful specification language, to market with automated testing and bug finding. Informal Staking is scaling our network offerings and monitoring products across the interchain, and launching our Ethereum staking service. And last but not least, Cycles is gearing up to transform the landscape of payments and credits and provide new ways to connect crypto to the real world for the benefit of all.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Here’s to a great 2024! Stay in touch by ","nodeType":"text"},{"data":{"uri":"https://informal.systems/blog#subscribe"},"content":[{"data":{},"marks":[],"value":"subscribing to our blog","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", following us on Twitter ","nodeType":"text"},{"data":{"uri":"https://twitter.com/informalinc"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"@informalinc","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", and following the projects","nodeType":"text"},{"data":{"uri":"https://twitter.com/cyclesmoney"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":" @cyclesmoney","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", ","nodeType":"text"},{"data":{"uri":"https://twitter.com/CometBFT"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"@cometbft","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", and ","nodeType":"text"},{"data":{"uri":"https://twitter.com/CosmosHub"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"@cosmoshub","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"If you’d like to work with us, reach out at ","nodeType":"text"},{"data":{"uri":"mailto:hello@informal.systems"},"content":[{"data":{},"marks":[],"value":"hello@informal.systems","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" or specifically:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Looking for a security audit? ","nodeType":"text"},{"data":{"uri":"mailto:audits@informal.systems"},"content":[{"data":{},"marks":[],"value":"audits@informal.systems","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Discuss options to work with our staking team? ","nodeType":"text"},{"data":{"uri":"mailto:validator@informal.systems"},"content":[{"data":{},"marks":[],"value":"validator@informal.systems","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Interested in joining our team? See our ","nodeType":"text"},{"data":{"uri":"https://informal.systems/careers"},"content":[{"data":{},"marks":[],"value":"open positions","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Cheers 🥂 ","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"contentfulURL":"https://app.contentful.com/spaces/p79kctcd7ahy/entries/2j5sz07Q58gFfPPSBTjIcw"},{"featureImage":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"5rjswywIm8XpRsxJvJR4yP","type":"Asset","createdAt":"2024-08-14T02:57:45.733Z","updatedAt":"2024-08-14T02:57:45.733Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":3,"revision":1,"locale":"en-US"},"fields":{"title":"Blog Tendermint","description":"","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/5rjswywIm8XpRsxJvJR4yP/a68ec303f74c69f7613afe7ab270b85c/Blog_Tendermint.jpg","details":{"size":304438,"image":{"width":1920,"height":1080}},"fileName":"Blog_Tendermint.jpg","contentType":"image/jpeg"}}},"date":"2024-03-11","title":"The Latest View on Tendermint's Responsiveness","slug":"tendermint-responsiveness","categories":["Engineering"],"authors":["Nenad Milosevic"],"keywords":"tendermint-responsiveness, cometbft-consensus, byzantine-fault-tolerance, consensus-latency, optimistic-consensus, blockchain-performance, distributed-systems, consensus-algorithms, network-delays, responsive-protocols","excerpt":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Technical analysis proving Tendermint achieves responsive consensus timing.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"includeTableOfContents":true,"introduction":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"In this article we discuss the ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"responsiveness","nodeType":"text"},{"data":{},"marks":[],"value":" property of consensus algorithms. We first explain what this property is and why it is important. Then, we explain why Tendermint is (optimistically) responsive.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"body":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"","nodeType":"text"},{"data":{"uri":"https://arxiv.org/pdf/1807.04938.pdf"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Tendermint","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" is one of the most widely used Byzantine fault-tolerant (BFT) consensus algorithms. It is currently implemented and maintained as part of the ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"CometBFT","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" engine. CometBFT is deployed in production in ","nodeType":"text"},{"data":{"uri":"https://mapofzones.com/"},"content":[{"data":{},"marks":[],"value":"tens","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" of app-chains in the Cosmos ecosystem, and has also found adoption in various other architectures (e.g. as a sequencer in ","nodeType":"text"},{"data":{"uri":"https://github.com/astriaorg/astria/tree/main"},"content":[{"data":{},"marks":[],"value":"Astria","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", as a data publication layer in ","nodeType":"text"},{"data":{"uri":"https://celestia.org/"},"content":[{"data":{},"marks":[],"value":"Celestia","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", or as part of an L2 stack in ","nodeType":"text"},{"data":{"uri":"https://polygon.technology/"},"content":[{"data":{},"marks":[],"value":"Polygon","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":").","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Despite widespread use, there is some nuance and unclarity whether Tendermint algorithm is responsive. In this article our goal is simply to clarify that Tendermint is (optimistically) responsive.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"What is responsiveness and why is it important? ","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"The term responsiveness was primarily used to differentiate between responsive consensus protocols and non-responsive protocols (see ","nodeType":"text"},{"data":{"uri":"https://eprint.iacr.org/2017/913.pdf"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Thunderella","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"). For the former, the latency of these protocols depends on actual network delays. For the latter, latency depends on conservative time bounds. Conservative time bounds are usually considerably higher than ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"actual","nodeType":"text"},{"data":{},"marks":[],"value":" network delays since they must account for worst-case delays. Consequently, non-responsive protocols tend to be slower than responsive protocols. For this reason, for example, Starknet considers responsiveness a relatively ","nodeType":"text"},{"data":{"uri":"https://community.starknet.io/t/starknet-decentralized-protocol-iii-consensus/5386"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"important","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" property, and Espresso Systems has recently ","nodeType":"text"},{"data":{"uri":"https://medium.com/@espressosys/espresso-hotshot-consensus-designed-for-rollups-b080ba7362d1"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"chosen","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" their consensus protocol based on this property.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The most widely used BFT consensus protocols (Tendermint, ","nodeType":"text"},{"data":{"uri":"https://arxiv.org/pdf/1803.05069.pdf"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"HotStuff","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":") work in a leader-based partially synchronous model. What does this mean? In these protocols, one validator, elected as leader, proposes the next block. The other validators vote to agree on this proposal. If the network is timely and the leader is honest, validators can reach a decision on the next block ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"responsively","nodeType":"text"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"However, the leader can be faulty, or the network may behave asynchronously. These protocols rely on a timeout to detect such behaviour and change the leader. The timeout values are usually conservative. An aggressive value can prevent progress, and may even render honest leaders seem faulty. Consequently, we can see that in the presence of faulty leaders (which includes situations of network asynchrony), these protocols cannot be responsive. This is why they are usually referred to as ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"optimistically","nodeType":"text"},{"data":{},"marks":[],"value":" responsive: Their responsiveness is constrained by some optimistic conditions. This property was first formulated by HotStuff paper and later revisited in ","nodeType":"text"},{"data":{"uri":"https://eprint.iacr.org/2023/397.pdf"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"HotStuff-2","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". In this article, as is common in the distributed computing literature, we assume optimistic conditions when we talk about responsiveness.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Tendermint’s Responsiveness","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"The Tendermint consensus algorithm builds a blockchain by running one instance of consensus for each height of the blockchain. Inside each consensus instance, nodes proceed in rounds where each round has a dedicated leader. The leader proposes a block and validators engage in two all-to-all voting phases to agree on a block. Consequently, if the leader is honest and the network is synchronous, the decision is reached in only three network delays. Moreover, when a node decides in a round, it ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"immediately","nodeType":"text"},{"data":{},"marks":[],"value":" starts with the next consensus instance (i.e., agreeing on the block for the next height).","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"On the other hand, if validators cannot reach a decision in the current round, due to faulty leader or network asynchrony, they move to the next round. Specifically, they change the leader and attempt again to build a block for this height. To ensure that eventually there will be a round with a decision, validators must ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"wait for a timeout","nodeType":"text"},{"data":{},"marks":[],"value":" before moving to the next round. As a result, transitions between rounds are not responsive. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Given the above, we draw the observation that Tendermint is responsive in how it transitions from one consensus instance to another. The transition from one round to another, however, is not responsive. As a result, in scenarios when the network is synchronous, and leaders are honest, Tendermint acts responsively since validators reach a decision on a block in the first round of an instance. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Importantly, some evidence from live networks (see this brief ","nodeType":"text"},{"data":{"uri":"https://github.com/adizere/osmosis-round-history"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"empirical data","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" from Osmosis for a recent example) suggests that this is the case nearly always (in more than 99% of the instances decision was reached in the first round). Furthermore, this is the case Espresso Systems mostly cares about and the one captured by the latest optimistic responsiveness property introduced by HotStuff-2.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Consequently, we conclude that, under optimistic conditions, Tendermint is a responsive consensus protocol.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Conclusion","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"In this post, we have discussed the responsiveness property of BFT consensus protocols. We explained what this property is and why it is important. Lastly, we have shown that the Tendermint consensus algorithm is (optimistically) responsive.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We are grateful for generous feedback on earlier versions of this essay to Dahlia Malkhi (UCSB); Fernando Pedone (USI); Jovan Komatovic (EPFL); Adi Seredinschi and Zarko Milosevic (Informal Systems).","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"References","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"CometBFT: Implementation of Tendermint consensus algorithm: ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"https://github.com/cometbft/cometbft/","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Yin et al., HotStuff: ","nodeType":"text"},{"data":{"uri":"https://arxiv.org/pdf/1803.05069.pdf"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"https://arxiv.org/pdf/1803.05069.pdf","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Malkhi & Nayak, HotStuff-2: ","nodeType":"text"},{"data":{"uri":"https://eprint.iacr.org/2023/397.pdf"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"https://eprint.iacr.org/2023/397.pdf","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Pass & Shi, Thunderella: ","nodeType":"text"},{"data":{"uri":"https://eprint.iacr.org/2017/913.pdf"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"https://eprint.iacr.org/2017/913.pdf","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Buchman et al., Tendermint: ","nodeType":"text"},{"data":{"uri":"https://arxiv.org/pdf/1807.04938.pdf"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"https://arxiv.org/pdf/1807.04938.pdf","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"contentfulURL":"https://app.contentful.com/spaces/p79kctcd7ahy/entries/1iizI0Fflsvdxn2XjVQU8D"},{"featureImage":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"UTz48igoOnuKDsyLrWPgo","type":"Asset","createdAt":"2024-08-14T02:42:33.860Z","updatedAt":"2024-08-14T02:42:33.860Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":3,"revision":1,"locale":"en-US"},"fields":{"title":"https images.ctfassets.net p79kctcd7ahy 7d4eyx0Xovdm94RDrCYCYk d0ecaf4d5af4c420c795cebc52e683c2 image","description":"","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/UTz48igoOnuKDsyLrWPgo/6d0e9d2084c77ac7a9fd14790a228d57/https___images.ctfassets.net_p79kctcd7ahy_7d4eyx0Xovdm94RDrCYCYk_d0ecaf4d5af4c420c795cebc52e683c2_image.png","details":{"size":158424,"image":{"width":2000,"height":726}},"fileName":"https___images.ctfassets.net_p79kctcd7ahy_7d4eyx0Xovdm94RDrCYCYk_d0ecaf4d5af4c420c795cebc52e683c2_image.png","contentType":"image/png"}}},"date":"2024-03-01","title":"ABCI v2 Interface Unlocks Advanced CometBFT Application Control","slug":"intro-to-abci-v2","categories":["Malachite","Engineering"],"authors":["Adi Seredinschi"],"keywords":"abci-v2, cometbft-interface, vote-extensions, optimistic-execution, blockchain-applications, consensus-interface, cosmos-sdk, application-control, block-lifecycle, consensus-engine","excerpt":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"How ABCI v2 enables vote extensions and optimistic execution in CometBFT.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"includeTableOfContents":true,"introduction":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"ABCI v2 (colloquially known as ABCI++) is the flagship feature of CometBFT. This was released as part of ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/releases/tag/v0.38.0"},"content":[{"data":{},"marks":[],"value":"v0.38","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" in September 2023. In this post we describe the power of ABCI v2 and compare it with its predecessor.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"body":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"What is ABCI?","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"ABCI is the separation layer — or interface — between the consensus engine (namely CometBFT) and the application layer of a blockchain system. It is an essential interface that defines the expectations that CometBFT and application have from each other.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Ignoring some of the subtleties of ABCI, we can imagine that the primary information that circulates through this interface is ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"blocks","nodeType":"text"},{"data":{},"marks":[],"value":". Intuitively, CometBFT produces a sequence of blocks, where each block is tagged with a ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"height.","nodeType":"text"},{"data":{},"marks":[],"value":" As soon as CometBFT finishes the production of a block for a new height, it hands off control over that block to the application. In turn, the application can then execute the transactions in the block. This is an oversimplification, but conveys the main idea.\n","nodeType":"text"}],"nodeType":"paragraph"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"7mtrto4qfelevqbc1rUVd5","type":"Asset","createdAt":"2024-03-01T14:59:45.328Z","updatedAt":"2024-03-01T15:08:07.367Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":8,"revision":2,"locale":"en-US"},"fields":{"title":"ABCI block lifecyle","description":"ABCI block lifecyle","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/7mtrto4qfelevqbc1rUVd5/7931ca357271fbacd3e75fa5d1b47879/image.png","details":{"size":249895,"image":{"width":2000,"height":435}},"fileName":"image.png","contentType":"image/png"}}}},"content":[],"nodeType":"embedded-asset-block"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Figure 1. Intuition of block lifecycle under ABCI ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"v0 ","nodeType":"text"},{"data":{},"marks":[],"value":"interface","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"blockquote"},{"data":{},"content":[{"data":{},"marks":[],"value":"The diagram above in Figure 1 sketches this flow. Once CometBFT decides on a block, it hands over control over that block to the application. This happens through a sequence of calls: ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"BeginBlock -> [DeliverTx] -> EndBlock","nodeType":"text"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The diagram in Figure 1 depicts a subsets of the methods of ABCI v0 as they are implemented in CometBFT release v0.34. For a complete descriptions of the methods comprised in ABCI v0, we refer the interested reader to the specification published at ","nodeType":"text"},{"data":{"uri":"https://docs.cometbft.com/v0.34/spec/abci/abci"},"content":[{"data":{},"marks":[],"value":"docs.cometbft.com","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The important part is that, under ABCI v0, the application has no control over the contents of the block. Nor can the application get access to anything related to a block ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"before","nodeType":"text"},{"data":{},"marks":[],"value":" CometBFT decided that block -- only ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"after","nodeType":"text"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Note that the block lifecycle has a few identifiable phases in the Tendermint consensus algorithm as implemented in CometBFT. (For a refresher on Tendermint consensus algorithm, see ","nodeType":"text"},{"data":{"uri":"https://docs.cometbft.com/v0.38/introduction/#consensus-overview.)"},"content":[{"data":{},"marks":[],"value":"https://docs.cometbft.com/v0.38/introduction/#consensus-overview","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".) ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Assuming a failure-free scenario:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"[Phase 1] A block proposer is preparing the block and proposing it to the other nodes in the network.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"[Phase 2] The block is undergoing a voting phase. This phase in fact includes two sub-phases, namely ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"Prevote","nodeType":"text"},{"data":{},"marks":[],"value":" and ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"Precommit","nodeType":"text"},{"data":{},"marks":[],"value":". For the purpose of this introductory post, we can simply assume there that the ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"Precommit","nodeType":"text"},{"data":{},"marks":[],"value":" phase is the more relevant one.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"[Phase 3] The validators finished deciding on the block. Sometimes this phase is called finalization.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"ordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"To bring the discussion back to the topic of ABCI ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"v0","nodeType":"text"},{"data":{},"marks":[],"value":", it is at phase 3 that the application gets access to the block for every height.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Comparison of ABCI ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"vs.","nodeType":"text"},{"data":{},"marks":[],"value":" ABCI++","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"Now let’s discuss ABCI ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"v2","nodeType":"text"},{"data":{},"marks":[],"value":", aka ABCI++. We skip over ABCI ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"v1","nodeType":"text"},{"data":{},"marks":[],"value":" because ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"v2","nodeType":"text"},{"data":{},"marks":[],"value":" supersedes ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"v1","nodeType":"text"},{"data":{},"marks":[],"value":" and is the focus of this post.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"In contrast to ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"v0","nodeType":"text"},{"data":{},"marks":[],"value":", in ABCI ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"v2","nodeType":"text"},{"data":{},"marks":[],"value":" the application is granted access to the block at multiple of the key moment during the block production lifecycle:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"italic"}],"value":"a.","nodeType":"text"},{"data":{},"marks":[],"value":" As part of phase 1: before the block is proposed, the application can manipulate the contents of the block. The application is thus able to control the transactions that go into each block and their relative order. See point d. for a refinement on this.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"italic"}],"value":"b.","nodeType":"text"},{"data":{},"marks":[],"value":" As part of phase 2: the application can append arbitrary data to a block. In CometBFT terminology, we call the arbitrary data \"vote extension.\" Specifically, each validator in a CometBFT network may piggyback vote extensions to each block. The vote extensions are specific per-validator, i.e., each validators appends a different extension.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"italic"}],"value":"c.","nodeType":"text"},{"data":{},"marks":[],"value":" Similar to ABCI ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"v0","nodeType":"text"},{"data":{},"marks":[],"value":", as part of phase 3: the application gets access to the block once this is decided.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"italic"}],"value":"d: refinement on point a.","nodeType":"text"},{"data":{},"marks":[],"value":" As part of phase 1 of the block for the ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"subsequent","nodeType":"text"},{"data":{},"marks":[],"value":" height: before the block for this subsequent height is proposed, the application can manipulate the contents of the block ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"and","nodeType":"text"},{"data":{},"marks":[],"value":" also gains access to vote extensions appended to the prior block.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"As we shall see, the ability of an application to build a block while having data from validators from the prior height is a very powerful feature. We will delve into this in a future post.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The diagram below in Figure 2 gives a graphical intuition of the dance between CometBFT and the application under the ABCI ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"v2","nodeType":"text"},{"data":{},"marks":[],"value":" model. We ignore some of the methods in the ABCI interface; for a detailed description please refer to the specification on ","nodeType":"text"},{"data":{"uri":"https://docs.cometbft.com/v0.38/spec/abci/"},"content":[{"data":{},"marks":[],"value":"docs.cometbft.com","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"7d4eyx0Xovdm94RDrCYCYk","type":"Asset","createdAt":"2024-03-01T15:00:43.438Z","updatedAt":"2024-03-01T15:00:43.438Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":4,"revision":1,"locale":"en-US"},"fields":{"title":"ABCI v2 block lifecycle","description":"","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/7d4eyx0Xovdm94RDrCYCYk/d0ecaf4d5af4c420c795cebc52e683c2/image.png","details":{"size":451991,"image":{"width":2000,"height":726}},"fileName":"image.png","contentType":"image/png"}}}},"content":[],"nodeType":"embedded-asset-block"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Figure 2. Graphical intuition of ABCI ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"v2","nodeType":"text"},{"data":{},"marks":[],"value":" block lifecycle","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"blockquote"},{"data":{},"content":[{"data":{},"marks":[],"value":"We highlight some nuances and details to help understand Figure 2.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"code"}],"value":"PrepareProposal","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":" for block at height H.","nodeType":"text"},{"data":{},"marks":[],"value":" This method executes at the block proposer. It grants the proposer full control over what will go in the block. Importantly, the proposer can also consult the vote extensions that validators in the network appended to the block of the prior height ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"H-1","nodeType":"text"},{"data":{},"marks":[],"value":". More specifically, this is a set of at least ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"2f+1","nodeType":"text"},{"data":{},"marks":[],"value":" vote extensions that the block proposer observed locally as part of committing the block of height ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"H-1","nodeType":"text"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"code"}],"value":"ProcessProposal","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":" for block at height H.","nodeType":"text"},{"data":{},"marks":[],"value":" Each node in the network executes this method to validate the block proposed for height H. As described in this ","nodeType":"text"},{"data":{"uri":"https://medium.com/the-interchain-foundation/optimistic-execution-landing-in-the-cosmos-sdk-a28fc72af650"},"content":[{"data":{},"marks":[],"value":"post","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", this method allows for the implementation of optimistic execution. This method opens up also another possibility for application builders, as follows: In the process of voting for the block at height ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"H","nodeType":"text"},{"data":{},"marks":[],"value":" — what we denoted Phase 2 earlier — a validator may choose to censor this proposed block by voting ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"nil","nodeType":"text"},{"data":{},"marks":[],"value":" on it. This is dangerous because it can lead to degenerate scenarios where block production is no longer guaranteed, i.e., the network may lose liveness.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"code"}],"value":"ExtendVote","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":" and ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"VerifyVoteExtension","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":".","nodeType":"text"},{"data":{},"marks":[],"value":" The former method allows a validator node to append arbitrary data — a vote extension — that will be made available to the proposer of the block in the subsequent height ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"H+1","nodeType":"text"},{"data":{},"marks":[],"value":". The method ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"ExtendVote","nodeType":"text"},{"data":{},"marks":[],"value":" is called during the voting phase for block height ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"H","nodeType":"text"},{"data":{},"marks":[],"value":", specifically before each validator sends their ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"Precommit","nodeType":"text"},{"data":{},"marks":[],"value":" vote; the extension is attached to the ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"Precommit ","nodeType":"text"},{"data":{},"marks":[],"value":"vote. The latter method, called ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"VerifyVoteExtension","nodeType":"text"},{"data":{},"marks":[],"value":", allows each validator to accept or reject every extension in the vote that the other validators cast. Accepting an extension means that the validator will deem the ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"Precommit vote","nodeType":"text"},{"data":{},"marks":[],"value":" for that extension as valid and will count towards forming a quorum to decide on the block height ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"H","nodeType":"text"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"code"}],"value":"FinalizeBlock","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":".","nodeType":"text"},{"data":{},"marks":[],"value":" This method is a consolidation of the three methods we highlighted earlier in Figure 1, namely ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"BeginBlock -> [DeliverTx] -> EndBlock","nodeType":"text"},{"data":{},"marks":[],"value":". It marks the delivery of a block.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"ordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"Key benefits of ABCI++","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"The high-level benefit of the new methods in ABCI ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"v2","nodeType":"text"},{"data":{},"marks":[],"value":" is that the application can exercise more control over the contents of each block that CometBFT produces.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We already mentioned one practical benefit that ABCI ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"v2","nodeType":"text"},{"data":{},"marks":[],"value":" unlocks: The application can implement an optimization called optimistic execution. The Cosmos SDK team describe their experience in this ","nodeType":"text"},{"data":{"uri":"https://medium.com/the-interchain-foundation/optimistic-execution-landing-in-the-cosmos-sdk-a28fc72af650"},"content":[{"data":{},"marks":[],"value":"post","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" with implementing this optimization.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Beside optimistic execution, other practical benefits include:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"The ability to implement decentralized oracles, as demonstrated in Skip's ","nodeType":"text"},{"data":{"uri":"https://github.com/skip-mev/slinky"},"content":[{"data":{},"marks":[],"value":"Slinky","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"The ability to do threshold decryption for mempool privacy.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Bonus: ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/blob/v0.38.0-alpha.1/docs/rfc/tendermint-core/rfc-013-abci++.md#rfc-013-abci"},"content":[{"data":{},"marks":[],"value":"RFC 013: ABCI++","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" is the first RFC that proposed ABCI++ and has a very ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/blob/v0.38.0-alpha.1/docs/rfc/tendermint-core/rfc-013-abci%2B%2B.md#short-list-of-blocked-features--scaling-improvements-with-required-abci-phases"},"content":[{"data":{},"marks":[],"value":"good table","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" describing improvements that ABCI ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"v2","nodeType":"text"},{"data":{},"marks":[],"value":" unlocks for application builders.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":" We may cover some of these benefits of ABCI ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"v2","nodeType":"text"},{"data":{},"marks":[],"value":" in future posts in more detail.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[],"nodeType":"hr"},{"data":{},"content":[{"data":{},"marks":[],"value":"We hope this introductory post raises awareness and provides insights to help understanding of the new ABCI ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"v2","nodeType":"text"},{"data":{},"marks":[],"value":" interface. To reiterate, the full specification of ABCI ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"v2","nodeType":"text"},{"data":{},"marks":[],"value":" can be found on ","nodeType":"text"},{"data":{"uri":"https://docs.cometbft.com/v0.38/spec/abci/"},"content":[{"data":{},"marks":[],"value":"docs.cometbft.com","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"To join the CometBFT builders community or follow along with the development, please find all the details at ","nodeType":"text"},{"data":{"uri":"https://linktr.ee/cometbft"},"content":[{"data":{},"marks":[],"value":"linktr.ee/cometbft","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"contentfulURL":"https://app.contentful.com/spaces/p79kctcd7ahy/entries/4h0rhFs7ZIafqp6Uumegcv"},{"featureImage":"$4:props:posts:25:featureImage","date":"2024-02-26","title":"Introducing Proposer-Based Timestamps (PBTS) in CometBFT","slug":"introducing-proposer-based-timestamps-pbts-in-cometbft","categories":["Engineering"],"authors":["CometBFT Team"],"keywords":"CometBFT\nProposer-Based Timestamps\nPBTS\nBFT consensus\nBlockchain audit\nProtocol security\nValidator signatures\nBlockchain efficiency\nTimestamp validation\nCosmos ecosystem\n\nproposer-based-timestamps, cometbft-pbts, bft-time, block-timestamps, signature-aggregation, light-client-verification, consensus-timing, blockchain-performance, validator-synchronization, time-sensitive-applications","excerpt":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"How PBTS replaces BFT Time to enable signature aggregation and better light clients.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"includeTableOfContents":true,"introduction":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"CometBFT is set to introduce a significant upgrade in the upcoming v1 release that promises to enhance the performance of blockchain operations through Proposer-Based Timestamps (PBTS). ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Historically, CometBFT, like many other BFT consensus engines, has been using BFT time to timestamp blocks. In contrast to the BFT Time approach, PBTS brings many benefits for application developers building on CometBFT. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Adopting Proposer-Based Timestamps (PBTS) in CometBFT will improve efficiency by ensuring an improved correlation between block timestamps and real-world time (UTC). PBTS will benefit light clients by providing more reliable block verification. It will also enable potential optimizations such as validator signature aggregation. PBTS will simplify the timestamping process, and enhance the reliability of time-sensitive applications such as Perpetuals and DEXes.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"body":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Limitations of BFT Time","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"CometBFT currently employs a method of timestamping blocks known as BFT Time. This ensures timestamps in each block are monotonically increasing and progresses within the bounds of the values of clocks of non-byzantine nodes. Upon creation of each new block, the proposer determines the block's timestamp by calculating the weighted median of the timestamps from all received pre-commit messages for the previous block. The weight corresponds to the validator's voting power or stake in the network at that height. This is a good solution allowing the blockchain to be used as a source of time. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"This system's approach to time generation is straightforward in that each validator contributes a timestamp in their pre-commit message. The timestamp provided by a validator reflects either the current Unix time known to the validator or a value one millisecond higher than the time of the previous block, whichever of the two is larger. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"However, the BFT time approach has some limitations. First, there is no requirement for validators to check how far away each received precommit’s timestamp is with respect to their own current Unix time. Thus, there is no strong relation between block timestamps and the ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"actual ","nodeType":"text"},{"data":{},"marks":[],"value":"time at which they were produced. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Second, and more importantly, notice that timestamps are a field in pre-commit messages. This means pre-commit messages from different validators have different payloads (the timestamp), and consequently CometBFT cannot support signature aggregation (BLS) of these votes. In turn, this hinders a potential avenue for improving the scalability of CometBFT with respect to validator set size.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"By using PBTS the above limitations are addressed. Below we describe PBTS and mention other key advantages of this approach.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"What is Proposer-Based Timestamps (PBTS)?","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"Proposer-Based Timestamps (PBTS) is a new algorithm for calculating block timestamps amongst validators for CometBFT based blockchain networks. Briefly, PBTS gives the block proposer – the node that creates a new candidate block – the responsibility of assigning a timestamp to the new block.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Why does PBTS matter?","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"The introduction of PBTS in CometBFT aims to simplify the timestamping process and more closely correlate the block times and the times where the blocks were created. With PBTS, we replace a \"timeless\" validation to a \"timely\" validation.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Key benefits of adopting PBTS:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Improved Reliability for Time-sensitive Applications","nodeType":"text"},{"data":{},"marks":[],"value":": PBTS Provides a more predictable and reliable timestamping mechanism, which is crucial for applications that rely on precise timing for transactions, such as un-bonding staked assets or timeout of IBC packets. In BFT Time, the potential for variance, and the weak enforcement of the skew between block times and actual time, in the selected timestamp may affect applications requiring high time accuracy. This is an important aspect for applications such as perpetuals trading or DEXes (such as Osmosis or dYdX).","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Better Alignment with Light Clients' Needs: ","nodeType":"text"},{"data":{},"marks":[],"value":"Light Clients rely on correspondence between their known time and the block time for block verification. PBTS ensures that timestamps are more closely aligned with real-world time, improving the reliability of block verification by light clients, which rely on accurate and predictable timestamps. Due to the limitations inherent in BFT Time, there can be significant discrepancies between a light client's Unix time and the block timestamp, affecting the reliability of block verification.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Potential for Signature Aggregation: ","nodeType":"text"},{"data":{},"marks":[],"value":"Using PBTS in CometBFT unlocks future optimizations such as aggregation of validator signatures and opens up the possibilities for potential new use cases such as BLS signatures and MPC computations. ","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Simplified Timestamp Agreement and Increased Efficiency","nodeType":"text"},{"data":{},"marks":[],"value":": In PBTS,","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":" ","nodeType":"text"},{"data":{},"marks":[],"value":"the block proposer unilaterally decides the timestamp, so there's no need for complex calculations or agreements among validators to calculate the timestamp. Further, this mitigates the potential introduction of skews when collecting and calculating the median of all validator timestamps.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"How Does PBTS Work?","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"With PBTS, the timestamp of a block is assigned by its proposer, according to its local clock. In other words, the proposer of a block also proposes a timestamp for the block. Validators can accept or reject a proposed block. A block is only accepted if its timestamp is acceptable. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"A proposed timestamp is acceptable if it is received within a certain time window, determined by synchrony-related parameters.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Synchronous Parameters","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"For validating timestamps, PBTS augments the system model considered by the consensus algorithm with synchrony assumptions:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Synchronized clocks: simultaneous clock reads at any two correct validators differ by at most PRECISION;","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Bounded message delays: the end-to-end delay for delivering a Proposal message, broadcast by a proposer, to all correct validators is bounded by MSGDELAY.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"PRECISION","nodeType":"text"},{"data":{},"marks":[],"value":" and ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"MSGDELAY","nodeType":"text"},{"data":{},"marks":[],"value":" are consensus parameters, shared by all validators, that define whether the timestamp of a block is acceptable, according to the introduced timely predicate.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Timestamp Validation","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"The ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"timely predicate","nodeType":"text"},{"data":{},"marks":[],"value":" is defined as follows. Let ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"proposalReceiveTime","nodeType":"text"},{"data":{},"marks":[],"value":" be the time, read from its local clock, at which a validator receives a Proposal message for a block with timestamp ts = block.time. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The proposed timestamp ts is considered timely if both:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"ts <= proposalReceiveTime + PRECISION","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"ts >= proposalReceiveTime - MSGDELAY - PRECISION","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"The following diagram graphically represents the conditions for accepting a proposed timestamp:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"4P2HiicpRPWObsApPDMcWR","type":"Asset","createdAt":"2024-02-26T15:47:57.744Z","updatedAt":"2024-02-26T15:47:57.744Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":4,"revision":1,"locale":"en-US"},"fields":{"title":"PBTS","description":"","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/4P2HiicpRPWObsApPDMcWR/755ace5c55a9913f9ae175e0c29d7320/image1.png","details":{"size":127534,"image":{"width":1999,"height":302}},"fileName":"image1.png","contentType":"image/png"}}}},"content":[],"nodeType":"embedded-asset-block"},{"data":{},"content":[{"data":{},"marks":[],"value":"Looking Ahead","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"The team has been diligently working on adding PBTS functionality to CometBFT. Although there are some minor tasks that still need to be completed, this feature will be included in the upcoming v1 release.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We are thrilled about the potential use cases and opportunities this feature will bring to the ecosystem.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"References:","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"For a refresher on BFT Time please see the reference ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/blob/feature/pbts/spec/consensus/bft-time.md"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"here","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"For more information on PBTS, please see the ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/blob/feature/pbts/spec/consensus/proposer-based-timestamp/README.md"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"spec","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"PBTS master tracking ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/issues/1731"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"issue","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"contentfulURL":"https://app.contentful.com/spaces/p79kctcd7ahy/entries/4Uz6NcDhWj0D9OrUy1I5T4"},{"featureImage":"$4:props:posts:25:featureImage","date":"2024-02-08","title":"CometBFT v1 Development Progress and January 2024 Engineering Updates","slug":"cometbft-engineering-update-january-2024","categories":["Engineering"],"authors":["Andy Nogueira"],"keywords":"cometbft-v1, pbts-development, consensus-engineering, blockchain-storage, security-releases, mempool-optimization, cometbft-updates, cosmos-infrastructure, distributed-consensus, engineering-progress","excerpt":{"nodeType":"document","data":{},"content":[{"nodeType":"paragraph","data":{},"content":[{"nodeType":"text","value":"Monthly development recap covering PBTS progress and security patch releases.","marks":[],"data":{}}]}]},"includeTableOfContents":true,"introduction":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Welcome to the January 2024 update from the CometBFT team at Informal Systems. We'll share our team's latest developments and progress in this update.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"During January 2024, our team continued to focus on completing tasks required for the upcoming ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/issues/578"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"CometBFT v1 release","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We also continued our efforts to optimize storage and worked on issues to reduce technical debt and fix some bugs.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"body":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"CometBFT v1 Alpha 2","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"We have been making progress towards the v1 alpha-2 release. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We have made considerable progress on ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/issues/1731"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"PBTS","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" and are approximately halfway through the work. As mentioned earlier, testing and QA for v1 is still delayed until after PBTS is fully prepared, but we could make some QA improvements, such as the ones in ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/issues/1868"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"#1868","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" and ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/issues/2107"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"#2107","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We have recently ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/issues/1613"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"restructured the v1 documentation","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", updating all existing documents to fit the ","nodeType":"text"},{"data":{"uri":"https://diataxis.fr/"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"diataxis framework","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". The content has been organized into four major categories: references, how-to, guides, and explanations. This restructuring will make it easier for our users to locate the content they need.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Concerning CometBFT-rs one of our wind-down projects, and is also relevant for v1 release, we have recently released the ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft-rs/releases/tag/v0.1.0-alpha.2"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"v0.1.0-alpha.2","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" version of cometbft-rs, which includes adjustments such as ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft-rs/issues/9"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"adapting domain types to support v1.0","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" protos and ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/issues/1834"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"making changes to cometbft-rs","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". We have reached out to impacted teams to give early notifications of potential implications (Penumbra and Hermes), and are collaborating with them to plan the sunsetting of tendermint-rs.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Security releases","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"We have addressed a security concern in the 0.38 line, released ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/releases/tag/v0.38.3"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"v0.38.3","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", and then released a follow-up ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/blob/v0.38.5/CHANGELOG.md#v0384"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"v0.38.4","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" that enables a more straightforward upgrade to the security patch. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We also worked with the Cosmos SDK and Berachain teams to fix a potential regression into how the security patch was used and released ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/blob/v0.38.5/CHANGELOG.md#v0385"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"v0.38.5","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" to address that concern.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Release Support Policy","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"As we work to establish a support policy for CometBFT releases, we recognize the importance of gathering feedback from those who are building on this platform. Your input will help us ensure that we are providing the best possible support for CometBFT users. We appreciate your collaboration and look forward to hearing your thoughts and suggestions ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/discussions/590"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"on this matter","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"CometBFT-DB release","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"We’ve worked on ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft-db"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"cometbft-db","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" and removed some technical debt (RemoteDB) and added support for a new database (","nodeType":"text"},{"data":{"uri":"https://github.com/cockroachdb/pebble"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"PebbleDB","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":") in CometBFT-DB and we’ve made a new release ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft-db/releases/tag/v0.10.0"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"v0.10.0","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Consensus modularity preparation work, to simplify internal modularity","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"We have done an investigation into a requirement by Evmos (and Berachain) for pluggable hash functions and scoped an initial approach towards a fix (","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/issues/342#issuecomment-1888821207"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"comment","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"). This will likely be rolled out post-v1 to avoid scope ballooning.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Efficiency improvements","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"The backport of ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/issues/1420"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"ADR-101 to v0.37.x","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" was paused after gathering feedback, and there are signals from Osmosis that they may use it in the future. We are currently evaluating the feedback and will consider restarting the experiment at a later time.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Other efficiency improvements we’ve made was to ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/issues/1087"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"prototype simple improvements and evaluate in local setup","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" and we ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/knowledge-base/blob/main/protocols/mempool/flooding-protocol.md"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"wrote an abstract description of the mempool propagation protocol","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We also have experimented with an ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/pull/1814"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"“ideal” key layout","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" and ruled out that design. We have prepared a special path of CometBFT for use with an optimized key layout, and we are coordinating with operator teams to gather production metrics and assess the impact of our storage layout optimizations, which continues the work in ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/issues/1041"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"#1041","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" and the tracking issue ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/issues/2058"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"#2058","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Technical Debt & Bug Fixes","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"Related to work we’ve done to reduce technical debt and to fix bugs in order to enable higher velocity for internal and external developers we’ve done many things such as the ones in ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/issues/2154"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"#2154","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/issues/1964"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"#1964","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/issues/1958"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"#1968","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/issues/1902"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"#1902","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/issues/1878"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"#1878","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/issues/1769"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"#1769","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Communications & Community","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"Our team has been actively engaged in promoting the importance of our work, and we have recently collaborated with several other key players in the ecosystem to form a working group focused on enhancing the mempool. By bringing together our collective expertise and resources, we are dedicated to making significant improvements to this vital component of the system.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"🙏 Thank you for taking the time to stay up-to-date with our work!","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"blockquote"},{"data":{},"content":[{"data":{},"marks":[],"value":"If you have any questions or want to discuss anything related to CometBFT, feel free to connect with our team on ","nodeType":"text"},{"data":{"uri":"https://discord.gg/cosmosnetwork"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Discord","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" or ","nodeType":"text"},{"data":{"uri":"https://t.me/CometBFT"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Telegram","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". We are always ready to assist you and provide you with the necessary information. Don't hesitate to reach out and keep the conversation going!","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Stay updated: Follow @cometbft on ","nodeType":"text"},{"data":{"uri":"https://twitter.com/cometbft"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Twitter","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"CometBFT is currently being stewarded by ","nodeType":"text"},{"data":{"uri":"http://informal.systems/"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Informal Systems","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" with support from many contributors across the interchain stack, including the Cosmos SDK and IBC teams.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"contentfulURL":"https://app.contentful.com/spaces/p79kctcd7ahy/entries/2q7OxXEAZymKWgheoY0xvv"},{"featureImage":"$4:props:posts:29:featureImage","date":"2024-02-08","title":"Hub Monthly Update — January 2024","slug":"hub-monthly-update-january-2024","categories":["Engineering"],"authors":["Marius Poke"],"keywords":"\"Cosmos Hub\nGaia v15\nICS v4.0.0\nPartial Set Security\nATOM governance\nModel-Based Testing\nCometBFT\nCosmos SDK\nInterchain Security\nValidator economics\"","excerpt":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Gaia v15 integration, ICS v4 release, PSS ADR, and oversight kickoff.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"includeTableOfContents":true,"introduction":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"It's time for the usual update from the Informal Systems' Cosmos Hub team. Here are some of the highlights:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"We had our kickoff meeting with the oversight committee.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"We are almost done with the integration phase of Gaia v15.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"We released ICS v4.0.0.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"We created an ADR for Partial Set Security.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"We started the discussion on ATOM Wars.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"Note that we use ","nodeType":"text"},{"data":{"uri":"https://forum.cosmos.network/t/cosmos-hub-improvement-process-chips/11765"},"content":[{"data":{},"marks":[{"type":"underline"},{"type":"bold"}],"value":"CHIPs","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" to track the progress of our work. Hence, throughout this update, we make several references to different phases of the CHIPs framework.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"body":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Oversight Committee Kickoff Meeting","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"On January 8, 2024, the Hub teams at Informal and Hypha met with the Oversight committee. The purpose of the meeting was to discuss Informal's and Hypha's Q1 plans. We published a ","nodeType":"text"},{"data":{"uri":"https://forum.cosmos.network/t/hypha-informal-oversight-kickoff-meeting/13069"},"content":[{"data":{},"marks":[{"type":"underline"},{"type":"bold"}],"value":"summary of the meeting","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" on the Hub forum. We thank the Oversight Committee members for their time and engaging discussions.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Upgrade the Liquid Staking Module to SDK v0.47","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"We finished the upgrade of the Liquid Staking Module (LSM) to SDK v0.47. This resulted in a ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/cosmos-sdk/tree/feature/v0.47.x-ics-lsm"},"content":[{"data":{},"marks":[{"type":"underline"},{"type":"bold"}],"value":"special SDK branch that will","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" be used by Gaia, starting with v15. Thanks to Zaki Manian and Sam Pochyly for thorough reviews.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Gaia v15 — Integration Phase","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"We are about to finish the integration phase of Gaia v15 — the release that will upgrade the Cosmos Hub to SDK 0.47 — and move to the testnet phase. A big chunk of the integration work for Gaia v15 consisted of updating Gaia to use the ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/cosmos-sdk/tree/feature/v0.47.x-ics-lsm"},"content":[{"data":{},"marks":[{"type":"underline"},{"type":"bold"}],"value":"SDK 0.47 branch with support for LSM","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". In addition, we added several state migrations that will occur on the v15 upgrade:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Set the min commission rate staking parameter to 5% (cf. ","nodeType":"text"},{"data":{"uri":"https://www.mintscan.io/cosmos/proposals/826"},"content":[{"data":{},"marks":[{"type":"underline"},{"type":"bold"}],"value":"prop 826","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"). In addition, it updates the commission rate for all validators that are below 5%.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Move the unvested funds from the vesting account ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"cosmos145hytrc49m0hn6fphp8d5h4xspwkawcuzmx498 ","nodeType":"text"},{"data":{},"marks":[],"value":"to the community pool (cf. ","nodeType":"text"},{"data":{"uri":"https://www.mintscan.io/cosmos/proposals/860"},"content":[{"data":{},"marks":[{"type":"underline"},{"type":"bold"}],"value":"prop 860","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"). The already vested funds are left in the original account.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Add the missing address to the signing_info state of the slashing module. This fixes an ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/gaia/issues/1734"},"content":[{"data":{},"marks":[{"type":"underline"},{"type":"bold"}],"value":"existing bug","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" i","nodeType":"text"},{"data":{},"marks":[],"value":"n the state of the Cosmos Hub.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Set the min initial deposit ratio governance parameter to 10%. This parameter was added to SDK 0.47 to address the ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/gaia/issues/2246"},"content":[{"data":{},"marks":[{"type":"underline"},{"type":"bold"}],"value":"gov spamming issue","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". Note that this doesn't change the existing behavior as the ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/gaia/pull/2262"},"content":[{"data":{},"marks":[{"type":"underline"},{"type":"bold"}],"value":"gov spam prevention mechanism","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" was already implemented in Gaia as a temporary fix until the 0.47 upgrade.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"In the context of state migrations, we removed the addDenomReverseIndex migration from the bank module as it is prohibitively expensive to run on the Cosmos Hub — it took more than 5h on a machine with 128 GB of RAM. As a consequence, we disabled the DenomOwners query.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Finally, we ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/cosmos-sdk/blob/feature/v0.47.x-ics-lsm/CHANGELOG.md#bug-fixes"},"content":[{"data":{},"marks":[{"type":"underline"},{"type":"bold"}],"value":"backported several fixes","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" for issues discovered during the ","nodeType":"text"},{"data":{"uri":"https://github.com/oak-security/audit-reports/blob/master/Cosmos%20SDK/2024-01-23%20Audit%20Report%20-%20Cosmos%20SDK%20v1.0.pdf"},"content":[{"data":{},"marks":[{"type":"underline"},{"type":"bold"}],"value":"Oak Security audit of SDK 0.47","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". Consequently, deposits must be in the same denoms as those in the min deposit governance parameter (i.e., for Cosmos Hub, that's ATOM). Also, a new governance parameter is added — ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"min deposit ratio","nodeType":"text"},{"data":{},"marks":[],"value":" — that enables the community to set a minimum value for a governance proposal deposit; the default value is 0.01, meaning that for the current value for min deposit of 250 ATOM, a deposit of at least 2.5 ATOM is required. In addition to these backports, we addressed a potential DOS attack by ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/gaia/pull/2912"},"content":[{"data":{},"marks":[{"type":"underline"},{"type":"bold"}],"value":"only allowing votes on governance proposals from accounts with at least one ATOM staked","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"ICS Releases","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"We released ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/interchain-security/releases/tag/v3.3.0"},"content":[{"data":{},"marks":[{"type":"underline"},{"type":"bold"}],"value":"ICS v3.3.0","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" with the ","nodeType":"text"},{"data":{"uri":"https://cosmos.github.io/interchain-security/features/slashing#equivocation-infractions"},"content":[{"data":{},"marks":[{"type":"underline"},{"type":"bold"}],"value":"cryptographic equivocation verification","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" feature. This ICS release is going to be used by Gaia v15.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We also released ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/interchain-security/releases/tag/v4.0.0"},"content":[{"data":{},"marks":[{"type":"underline"},{"type":"bold"}],"value":"ICS v4.0.0","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", which contains the provider-side changes for jail throttling with retries, and, as a result, it fully enables the ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/interchain-security/blob/release/v3.2.x/docs/docs/adrs/adr-008-throttle-retries.md"},"content":[{"data":{},"marks":[{"type":"underline"},{"type":"bold"}],"value":"jail throttling with retries","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" feature. In addition, this ICS release sets the minimum required version of Go to 1.21 and fixes the following two bugs:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"A ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/interchain-security/issues/1517"},"content":[{"data":{},"marks":[{"type":"underline"},{"type":"bold"}],"value":"bug in the soft opt-out protocol","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" which leads to some validators being jailed immediately once they move into the top 95% of voting power and consequently can no longer opt out from validating consumer chains. The fix ensures a warm-up period for validators once they get in the top 95% before they can get jailed for downtime on consumer chains. Thanks to ","nodeType":"text"},{"data":{"uri":"https://github.com/freak12techno"},"content":[{"data":{},"marks":[{"type":"underline"},{"type":"bold"}],"value":"@freak12techno","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" for notifying us of this unexpected behavior.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"A ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/interchain-security/issues/1569"},"content":[{"data":{},"marks":[{"type":"underline"},{"type":"bold"}],"value":"bug in the consumer downtime logic","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" related to marshaling using Bech32. Thanks to the Neutron team for bringing this issue to our attention.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"Although neither of the bugs is a security vulnerability, we recommend all consumer chains upgrade to ICS v4.0.0 as soon as possible.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Model-Based Testing","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"At the end of last year, we enabled Model-Based Testing (MBT) for ICS (it is currently part of our CI). We published a ","nodeType":"text"},{"data":{"uri":"https://informal.systems/blog/model-based-testing-for-the-cosmos-hub"},"content":[{"data":{},"marks":[{"type":"underline"},{"type":"bold"}],"value":"blog post","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" describing our approach to using MBT in the context of Cosmos Hub.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We also added the ","nodeType":"text"},{"data":{"uri":"https://cosmos.github.io/interchain-security/adrs/adr-001-key-assignment"},"content":[{"data":{},"marks":[{"type":"underline"},{"type":"bold"}],"value":"key assignment","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" feature to the Quint model of ICS and integrated it with MBT. Key assignment is a non-trivial feature of ICS; having it covered by MBT increases the confidence of our releases. In addition, this enables us to test how new features, such as ICS epochs (see below), interact with the rest of the protocol. We will continue to expand the MBT functionality — next is adding consumer-initiated slashing to the Quint model, and we are also expanding the model as we continue to spec out Partial Set Security — so stay tuned.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"ICS Backward Compatibility Testing","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"We ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/interchain-security/pull/1486"},"content":[{"data":{},"marks":[{"type":"underline"},{"type":"bold"}],"value":"updated the ICS e2e test infrastructure","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" to enable backward compatibility tests. The new infrastructure supports running the e2e tests against different provider/consumer versions. We also created a ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/interchain-security/issues/1592"},"content":[{"data":{},"marks":[{"type":"underline"},{"type":"bold"}],"value":"GitHub workflow for building and publishing ICS docker images","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". As a final step, we are currently adapting the existing tests to the new framework.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"ICS Epochs — Specification Phase","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"We wrote an ","nodeType":"text"},{"data":{"uri":"https://cosmos.github.io/interchain-security/adrs/adr-014-epochs"},"content":[{"data":{},"marks":[{"type":"underline"},{"type":"bold"}],"value":"ADR for ICS epochs","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" that addresses the high cost of relaying needs for ICS. Currently, in every block that the provider validator set changes, a VSCPacket must be sent to every consumer, and a corresponding VSCMaturedPacket must be returned. Given that the validator powers may often change on the Cosmos Hub, this approach results in a significant workload for relayers. ICS epochs enable the Cosmos Hub to send validator updates to consumer chains only once per ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"epoch","nodeType":"text"},{"data":{},"marks":[],"value":" (which consists of multiple blocks). Next, we plan to add ICS epochs to the Quint model (as part of the spike phase), enabling us to move to the implementation phase. The plan is to deploy ICS epochs on the Hub as part of the Gaia v16 upgrade.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Partial Set Security — Discussion and Specification Phases","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"We continued the discussion on Partial Set Security (PSS) with a series of posts on the Cosmos Hub forum.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"First, we ","nodeType":"text"},{"data":{"uri":"https://forum.cosmos.network/t/chips-discussion-phase-partial-set-security-updated/11775"},"content":[{"data":{},"marks":[{"type":"underline"},{"type":"bold"}],"value":"updated the original post","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" by incorporating feedback from validators, consumer chains, and community members. The outcome is a simplified design that removes the concept of validator delegations.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Second, we started a ","nodeType":"text"},{"data":{"uri":"https://forum.cosmos.network/t/pss-permissionless-vs-premissioned-lite-opt-in-consumer-chains/12984"},"content":[{"data":{},"marks":[{"type":"underline"},{"type":"bold"}],"value":"discussion on how to launch opt-in consumer chains","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" — ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"permissionless ","nodeType":"text"},{"data":{},"marks":[],"value":"vs. ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"permissioned-lite. ","nodeType":"text"},{"data":{},"marks":[],"value":"In the first iteration of PSS, we decided to go with permissioned-lite — using the existing governance interface to launch opt-in consumer chains, and only validators who voted YES would be opted in to run a consumer chain.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Third, we started a ","nodeType":"text"},{"data":{"uri":"https://forum.cosmos.network/t/pss-exclusive-vs-inclusive-top-n/13058"},"content":[{"data":{},"marks":[{"type":"underline"},{"type":"bold"}],"value":"discussion on different types of top-n consumer chains","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" — ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"inclusive top-n","nodeType":"text"},{"data":{},"marks":[],"value":", ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"exclusive top-n","nodeType":"text"},{"data":{},"marks":[],"value":", ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"inclusive top-n plus custom active set","nodeType":"text"},{"data":{},"marks":[],"value":". We decided to go with inclusive top-n — any active Cosmos Hub validator can opt-in on any top-n chain, regardless of their voting power.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"We also wrote an ","nodeType":"text"},{"data":{"uri":"https://cosmos.github.io/interchain-security/adrs/adr-015-partial-set-security"},"content":[{"data":{},"marks":[{"type":"underline"},{"type":"bold"}],"value":"ADR of PSS","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" that describes the steps needed to implement the first iteration of PSS, and have already started with the implementation.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Megablocks — Spike Phase","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"We started the spike phase of ","nodeType":"text"},{"data":{"uri":"https://forum.cosmos.network/t/chips-discussion-phase-atomic-ibc-megablocks/11767"},"content":[{"data":{},"marks":[{"type":"underline"},{"type":"bold"}],"value":"Megablocks","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". We implemented an example of a Comet BFT application and an e2e testing environment. We are currently working on the implementation of an ABCI multiplexer shim.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"ATOM Wars — Discussion Phase","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"We posted a ","nodeType":"text"},{"data":{"uri":"https://forum.cosmos.network/t/the-atom-wars-a-new-governance-platform-for-liquidity-injections/13122"},"content":[{"data":{},"marks":[{"type":"underline"},{"type":"bold"}],"value":"description of ATOM Wars","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" on the Cosmos Hub forum — a new governance platform for liquidity injections. In a nutshell, this feature will allow ATOM holders to lock up their stake for up to one year and, in exchange, get boosted decision power regarding the allocation of liquidity injections into third-party projects.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Minimum Commission as a Function of Voting Power","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"We started a ","nodeType":"text"},{"data":{"uri":"https://forum.cosmos.network/t/chips-discussion-phase-minimum-commission-as-a-function-of-voting-power/12445"},"content":[{"data":{},"marks":[{"type":"underline"},{"type":"bold"}],"value":"discussion on setting the validator minimum commission as a function of the voting power","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". This is a potential solution for the concentration of voting power in the Cosmos Hub validator set. In a nutshell, such an approach would have the following benefits:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Encourages a decrease in voting power concentration.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Shields small validators from intense competition with larger validators.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Does not hinder the ability of small validators to compete.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Mitigates Sybil attacks.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"ordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"contentfulURL":"https://app.contentful.com/spaces/p79kctcd7ahy/entries/1eWqZot2sJs7wBlhTuqLSg"},{"featureImage":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"6XlsXaj34zrpjwnaXe7BZ0","type":"Asset","createdAt":"2024-08-14T03:10:38.881Z","updatedAt":"2024-08-14T03:10:38.881Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":3,"revision":1,"locale":"en-US"},"fields":{"title":"Blog ReplicatedSecurity","description":"","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/6XlsXaj34zrpjwnaXe7BZ0/645c4f450ff7a216c11a8f191992225a/Blog_ReplicatedSecurity.jpg","details":{"size":252511,"image":{"width":1920,"height":1080}},"fileName":"Blog_ReplicatedSecurity.jpg","contentType":"image/jpeg"}}},"date":"2024-02-06","title":"Learning to Live with “Unbonding Pausing”","slug":"learning-to-live-with-unbonding-pausing","categories":["Engineering"],"authors":["Karolos Antoniadis"],"keywords":"replicated-security, unbonding-pausing, ibc-light-clients, vsc-packets, cosmos-hub, interchain-security, validator-set-changes, light-client-attacks, consumer-chains, blockchain-security","excerpt":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Technical analysis of VSCMaturedPackets and light client security constraints.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"includeTableOfContents":true,"introduction":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"For almost a year, ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"Replicated Security","nodeType":"text"},{"data":{},"marks":[],"value":" has been successfully replicating the multi-billion dollar economic security of Cosmos Hub to the Neutron and Stride chains. A potential hindrance, known as ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"unbonding pausing","nodeType":"text"},{"data":{},"marks":[],"value":", of Replicated Security is that, in exceptional cases, the unbonding of tokens on Cosmos Hub could be delayed by more than the expected unbonding period of 21 days. Those potential unbonding delays concern delegators because they might not be able to retrieve their tokens on time.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"At Informal Systems, we investigated whether we can improve Replicated Security by eliminating unbonding pausing to avoid potential unbonding delays. In this blog post, we show the surprising result that it is ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"impossible","nodeType":"text"},{"data":{},"marks":[],"value":" to eliminate unbonding pausing without compromising the security of light clients and hence the security of the Interchain. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"In what follows, we first provide a high-level overview of how light clients operate. We then present Replicated Security and its use of a specific type of packets, namely ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"VSCMaturedPacket","nodeType":"text"},{"data":{},"marks":[],"value":"s, that can cause unbonding pausing. Finally, we show that there is no way to remove ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"VSCMaturedPacket","nodeType":"text"},{"data":{},"marks":[],"value":"s from Replicated Security without compromising the security of light clients.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"body":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"IBC light clients","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"The Inter-Blockchain (IBC) protocol is a general message-passing protocol that allows different chains to communicate with each other. IBC consists of multiple components such as light clients, connections, and channels (for more information, see the ","nodeType":"text"},{"data":{"uri":"https://ibcprotocol.org/"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"official page of IBC","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"). In this section, we provide only a high-level overview of light clients that constitute the core of the IBC protocol.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"IBC light clients, which we refer to simply as ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"light clients","nodeType":"text"},{"data":{},"marks":[],"value":", allow one chain ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"A ","nodeType":"text"},{"data":{},"marks":[],"value":"to send and receive messages to and from another chain ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"B","nodeType":"text"},{"data":{},"marks":[],"value":". Chain ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"A","nodeType":"text"},{"data":{},"marks":[],"value":" can use a light client to verify that indeed a message sent from chain ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"B","nodeType":"text"},{"data":{},"marks":[],"value":" stems from chain ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"B","nodeType":"text"},{"data":{},"marks":[],"value":". Because of this, light clients form the basis on which IBC applications, such as token transfers, are built upon. Note that Replicated Security is in","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":" ","nodeType":"text"},{"data":{},"marks":[],"value":"itself an application of IBC.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"A ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"light client","nodeType":"text"},{"data":{},"marks":[],"value":" on chain ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"A ","nodeType":"text"},{"data":{},"marks":[],"value":"consists of a bounded list of headers (from increasing but not necessarily contiguous heights) of chain ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"B","nodeType":"text"},{"data":{},"marks":[],"value":". We say that chain ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"A ","nodeType":"text"},{"data":{},"marks":[],"value":"tracks chain ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"B ","nodeType":"text"},{"data":{},"marks":[],"value":"because chain ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"A ","nodeType":"text"},{"data":{},"marks":[],"value":"keeps track of the headers of chain ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"B","nodeType":"text"},{"data":{},"marks":[],"value":". A ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"header","nodeType":"text"},{"data":{},"marks":[],"value":" for a specific height ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"H ","nodeType":"text"},{"data":{},"marks":[],"value":"contains, among others, the ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"appHash","nodeType":"text"},{"data":{},"marks":[],"value":" (i.e., hash of the root of all the stores of the chain) at height ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"H","nodeType":"text"},{"data":{},"marks":[],"value":", and a validator set of all the validators that signed the block with this ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"appHash ","nodeType":"text"},{"data":{},"marks":[],"value":"at height ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"H","nodeType":"text"},{"data":{},"marks":[],"value":". Note that in reality, the state of a light client is streamlined and is a list of consensus states (see ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/ibc-go/blob/v8.0.0/proto/ibc/lightclients/tendermint/v1/tendermint.proto#L54"},"content":[{"data":{},"marks":[{"type":"underline"},{"type":"italic"}],"value":"ConsensusState","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":") but for simplicity of presentation, we consider here that a light client consists of a list of headers. Additionally, the list of headers of a light client is bounded because older headers are pruned as is explained later on.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"For example, Cosmos Hub has multiple light clients that track different chains. All those light clients reside in the state of Cosmos Hub. In the figure below we see an example where Cosmos Hub has a light client that tracks Stride, another light client that tracks Osmosis, etc. Creating a light client on any chain is as simple as sending a transaction to the Cosmos Hub to provide an initial header through a ","nodeType":"text"},{"data":{"uri":"https://tutorials.cosmos.network/academy/3-ibc/4-clients.html"},"content":[{"data":{},"marks":[{"type":"underline"},{"type":"italic"}],"value":"MsgCreateClient","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" message.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"2wBrBXzIGh4UJBg1zAfvq4","type":"Asset","createdAt":"2024-01-31T19:41:40.316Z","updatedAt":"2024-02-02T17:36:10.622Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":8,"revision":2,"locale":"en-US"},"fields":{"title":"Light Clients","description":"","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/2wBrBXzIGh4UJBg1zAfvq4/8504eeeedbf548921494880e1e596cf9/1_cosmos_hub_with_light_clients_inside.png","details":{"size":46950,"image":{"width":683,"height":473}},"fileName":"1_cosmos_hub_with_light_clients_inside.png","contentType":"image/png"}}}},"content":[],"nodeType":"embedded-asset-block"},{"data":{},"content":[{"data":{},"marks":[],"value":"If we were to look inside a light client, for example the light client that tracks Stride, we can see that the client contains a list of headers as shown below.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"6F7RXndSgalZMs8walHRIb","type":"Asset","createdAt":"2024-01-31T19:42:32.694Z","updatedAt":"2024-02-02T17:36:39.188Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":8,"revision":2,"locale":"en-US"},"fields":{"title":"internal state of light client that tracks stride","description":"","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/6F7RXndSgalZMs8walHRIb/986ec65b1e98d201e5b1994fdae2bf91/2_internal_state.png","details":{"size":55149,"image":{"width":1361,"height":275}},"fileName":"2_internal_state.png","contentType":"image/png"}}}},"content":[],"nodeType":"embedded-asset-block"},{"data":{},"content":[{"data":{},"marks":[],"value":"Light clients are useful because we can use them to prove that something has happened on the chain they track. In the figure above, we have the header of Stride at height 3129 and hence we know the ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"appHash ","nodeType":"text"},{"data":{},"marks":[],"value":"of Stride at height 3129. Therefore, if a user wants to prove to Cosmos Hub that an action took place on Stride at height 3129 (e.g., tokens were escrowed, a message was sent, etc.), the user just sends to Cosmos Hub the action and the Merkle proof. We can look at the Merkle proof in combination with the action to verify that we end up with the same ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"appHash","nodeType":"text"},{"data":{},"marks":[],"value":" as the one stored in the header at height 3129. If this is the case, then we can be certain that indeed the action took place on Stride. For simplicity, we omit here the off-by-one discrepancy between the ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"appHash","nodeType":"text"},{"data":{},"marks":[],"value":" and the application state, namely that the ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"appHash ","nodeType":"text"},{"data":{},"marks":[],"value":"at height ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"H + 1","nodeType":"text"},{"data":{},"marks":[],"value":" refers to the application state after executing the transactions from block at height ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"H","nodeType":"text"},{"data":{},"marks":[],"value":" (see ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/issues/446"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"discussion","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":").","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"It should be apparent that light clients can be used to form the basis of communication between chains. For example, for two chains ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"A","nodeType":"text"},{"data":{},"marks":[],"value":" and ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"B","nodeType":"text"},{"data":{},"marks":[],"value":" to communicate with each other, we can set up a light client on chain ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"A","nodeType":"text"},{"data":{},"marks":[],"value":" that tracks chain ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"B","nodeType":"text"},{"data":{},"marks":[],"value":" and a light client on chain ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"B","nodeType":"text"},{"data":{},"marks":[],"value":" that tracks chain ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"A","nodeType":"text"},{"data":{},"marks":[],"value":". Now if chain ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"A ","nodeType":"text"},{"data":{},"marks":[],"value":"wants to send a message ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"m","nodeType":"text"},{"data":{},"marks":[],"value":" to chain ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"B","nodeType":"text"},{"data":{},"marks":[],"value":", chain ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"A","nodeType":"text"},{"data":{},"marks":[],"value":" just has to write ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"m","nodeType":"text"},{"data":{},"marks":[],"value":" in its store and send a proof to chain ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"B","nodeType":"text"},{"data":{},"marks":[],"value":". Because chains do not have the ability to actually communicate directly with each other, communication is done through the use of specific messages, for example ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"MsgUpdateClient ","nodeType":"text"},{"data":{},"marks":[],"value":"and ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"MsgReceivePacket","nodeType":"text"},{"data":{},"marks":[],"value":". Those messages can be sent by any user to a chain but are usually sent by off-chain processes, called ","nodeType":"text"},{"data":{"uri":"https://tutorials.cosmos.network/academy/2-cosmos-concepts/13-relayer-intro.html"},"content":[{"data":{},"marks":[{"type":"underline"},{"type":"italic"}],"value":"relayers","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", that connect to multiple chains and monitor their communication. A state of the art IBC relayer is ","nodeType":"text"},{"data":{"uri":"http://hermes.informal.systems/"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Hermes","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". When chain ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"A ","nodeType":"text"},{"data":{},"marks":[],"value":"wants to send a message to another chain ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"B ","nodeType":"text"},{"data":{},"marks":[],"value":"the relayer would pick this up and send transactions with messages, such as ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"MsgReceivePacket","nodeType":"text"},{"data":{},"marks":[],"value":", over to chain ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"B","nodeType":"text"},{"data":{},"marks":[],"value":". Whenever we mention “user”, we mean a “relayer” in practical terms.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Updating light clients","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"A careful reader might wonder how light clients get updated. For example, if a malicious user could update the Stride light client on Cosmos Hub with a bogus ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"appHash","nodeType":"text"},{"data":{},"marks":[],"value":",","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":" ","nodeType":"text"},{"data":{},"marks":[],"value":"then that user could alter reality as seen by Cosmos Hub and “convince” the hub of erroneous things, such as, that an account on Stride has more tokens than they have in reality.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"In practice, ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"updating ","nodeType":"text"},{"data":{},"marks":[],"value":"a client entails appending one header in the list of headers of the client. To append a header, we have to verify that the new header is indeed a ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"valid","nodeType":"text"},{"data":{},"marks":[],"value":" and not a bogus header. To do this, we have to make two assumptions: i) all headers contained in the light client so far are valid, and ii) that at most ⅓ of the validators can be malicious; a classic Byzantine Fault Tolerance (BFT) assumption. Technically, the assumption is that at most ⅓ of the voting power is not malicious but for the sake of clarity we simply assume that at most ⅓ of the validators can be malicious. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Now, for a user to update a client with a new header \$H_n\$, the user has to provide a trusted header \$H_t\$ as well that already exists in the light client. The light client only gets updated with \$H_n\$ if the intersection of \$validatorSet(H_n) \\cap validatorSet(H_t) > ⅓\$. If this is the case, then we know that at least one correct validator that signed \$H_n\$ also signed \$H_t\$ and therefore \$H_n\$ is also a valid header. In practice, to update a light client someone has to send a ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"MsgUpdateClient ","nodeType":"text"},{"data":{},"marks":[],"value":"message to the chain that would contain the client to be updated, the new header to be added and the trusted header.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Note that in order to update a light client, a user can provide as a trusted header any header that is contained in the light client and not necessarily the latest one, something known as ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"skipping verification","nodeType":"text"},{"data":{},"marks":[],"value":". For example, in the figure below, we update the light client that tracks Stride with a new header from Stride at height 3378. When updating the light client we can say that we trust the header at height 89 and if the intersection \$validatorSet(H_{3378}) \\cap validatorSet(H_{89}) > ⅓\$ the header at height 3378 would be included.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"3XD7wJd3s0uUpmlixo5KbO","type":"Asset","createdAt":"2024-01-31T19:43:55.298Z","updatedAt":"2024-02-02T17:36:55.455Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":7,"revision":2,"locale":"en-US"},"fields":{"title":"internal state of light client that tracks Stride #2","description":"","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/3XD7wJd3s0uUpmlixo5KbO/033dd80c3569f7f066b6d5bb2e259412/3_internal_state_with_header.png","details":{"size":142619,"image":{"width":1867,"height":761}},"fileName":"3_internal_state_with_header.png","contentType":"image/png"}}}},"content":[],"nodeType":"embedded-asset-block"},{"data":{},"content":[{"data":{},"marks":[],"value":"After the light client gets updated we would be in the following state.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"38S86fPjICxdYnlBZiTOpJ","type":"Asset","createdAt":"2024-01-31T19:44:32.332Z","updatedAt":"2024-02-02T17:37:21.162Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":7,"revision":2,"locale":"en-US"},"fields":{"title":"internal state of light client that tracks Stride #3","description":"","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/38S86fPjICxdYnlBZiTOpJ/bbf9ff784f99eb6fbedf1f21b8db6fc8/4_internal_state_with_Stride.png","details":{"size":70404,"image":{"width":1745,"height":275}},"fileName":"4_internal_state_with_Stride.png","contentType":"image/png"}}}},"content":[],"nodeType":"embedded-asset-block"},{"data":{},"content":[{"data":{},"marks":[],"value":"Skipping verification is efficient because we do not need to store a header at height ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"X - 1","nodeType":"text"},{"data":{},"marks":[],"value":" to verify a header at height ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"X","nodeType":"text"},{"data":{},"marks":[],"value":" but can use any header stored in the light client. Note that whether we update a light client with ⅓ intersection or more depends on the ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"trustLevel ","nodeType":"text"},{"data":{},"marks":[],"value":"we set when we first create a light client (","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"MsgCreateClient","nodeType":"text"},{"data":{},"marks":[],"value":").","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"As mentioned earlier, we made two assumptions, that all headers contained in the light client so far are valid. We can guarantee that this assumption holds when we first create a client using the ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"MsgCreateClient","nodeType":"text"},{"data":{},"marks":[],"value":" message by providing a valid header in this message. We need some initial proof of trust for this but afterwards by induction, if every header we add is valid then all headers in the light client would be valid (with a caveat – see later on ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"trustingPeriod","nodeType":"text"},{"data":{},"marks":[],"value":"). For the second BFT assumption to hold we need some deterrents so that validators do not act maliciously. Those deterrents in proof-of-stake chains include: i) slashing validators that misbehave (e.g., double sign) by burning their staked tokens, and ii) the concept of ","nodeType":"text"},{"data":{"uri":"https://forum.cosmos.network/t/enabling-opt-in-and-mesh-security-with-fraud-votes/10901"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"token toxicity","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We can see an ","nodeType":"text"},{"data":{"uri":"https://www.mintscan.io/cosmos/tx/51F7DE33A67D9E853D22BA4A430898DEA7C726C94D0F2405AE8171BD4CE58AC0?height=18263602"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"example","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" where an IBC action takes place, where a user first sends a ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"MsgUpdateClient","nodeType":"text"},{"data":{},"marks":[],"value":" message to update a light client with a new header, and then the user sends a ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"MsgReceivePacket","nodeType":"text"},{"data":{},"marks":[],"value":" message that contains a Merkle proof to prove to the chain that it took an action.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"A natural question that might arise is for how long do we keep the headers stored in a light client. The headers of a light client are pruned after a period of time, named ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"trustingPeriod","nodeType":"text"},{"data":{},"marks":[],"value":". The ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"trustingPeriod","nodeType":"text"},{"data":{},"marks":[],"value":" of a light client should be less than the unbonding period of the chain the client tracks and usually, although not necessarily, ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"trustingPeriod ","nodeType":"text"},{"data":{},"marks":[],"value":"is set to 2/3 of the unbonding period. The reason for this is the following: Assume a scenario where a set \$V_m\$ of more than >⅓ malicious validators sign a header on the third of January and update the light client, then \$V_m\$ unbond all their tokens wait for the unbonding period to pass in order to receive their bonded tokens back. After the malicious validators \$V_m\$ receive their tokens back, \$V_m\$ updates the light client using as trusted header the one from the third of January. Suppose this header is still trusted, i.e., ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"trustingPeriod","nodeType":"text"},{"data":{},"marks":[],"value":" > unbonding period. Naturally, there is a more than >⅓ intersection between the validator sets of the two headers because they were both signed by \$V_m\$ and \$V_m\$ consists of more than >⅓ of the malicious validators. Because of this we just added a bogus header on the light client.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"GhC5VCNMRuGI4xSlkQ01Z","type":"Asset","createdAt":"2024-01-31T19:45:24.866Z","updatedAt":"2024-02-02T17:37:49.378Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":7,"revision":2,"locale":"en-US"},"fields":{"title":"internal state of light client that tracks Stride #4","description":"","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/GhC5VCNMRuGI4xSlkQ01Z/c4634f0375d27ecfdf4ad901d5fe69a1/5_internal_state_with_bogus_header.png","details":{"size":149146,"image":{"width":1828,"height":825}},"fileName":"5_internal_state_with_bogus_header.png","contentType":"image/png"}}}},"content":[],"nodeType":"embedded-asset-block"},{"data":{},"content":[{"data":{},"marks":[],"value":"For this reason, it is imperative that the ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"trustingPeriod","nodeType":"text"},{"data":{},"marks":[],"value":" of a light client should be less than the ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"unbondingPeriod","nodeType":"text"},{"data":{},"marks":[],"value":" of the chain that the client tracks. This way, if some validators attempt to introduce a bogus header to the light client, their tokens will still be staked or not yet unbonded and we would be able to punish such a validator by slashing their tokens.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Curious readers can dive deeper into the topic of light clients ","nodeType":"text"},{"data":{"uri":"https://medium.com/tendermint/everything-you-need-to-know-about-the-tendermint-light-client-f80d03856f98"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"here","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"On Replicated Security","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"Replicated Security allows one chain to provide its economic security to other chains. A specific instantiation of Replicated Security launched on Cosmos Hub and has successfully been securing the ","nodeType":"text"},{"data":{"uri":"https://www.mintscan.io/cosmos/proposals/792"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Neutron chain since May of 2023","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" and the ","nodeType":"text"},{"data":{"uri":"https://www.mintscan.io/cosmos/proposals/799"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Stride chain since June of 2023","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Through Replicated Security, Cosmos Hub (known as the ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"provider","nodeType":"text"},{"data":{},"marks":[],"value":" ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"chain","nodeType":"text"},{"data":{},"marks":[],"value":") can provide its multi-billion dollar economic security to other chains (known as ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"consumer chains","nodeType":"text"},{"data":{},"marks":[],"value":") by replicating its validator set to the other chains. In practice, this means that the Cosmos Hub validator set is used to validate transactions on the consumer chains. If a validator misbehaves (e.g., double votes) on a consumer chain, then this validator gets slashed on the provider chain. Effectively, this means that the consumer chain receives the same economic security of billions of dollars of staked ATOM as the provider chain. Additionally, this way, consumer chains can get security without having to bootstrap their own validator sets. The Cosmos Hub validator set in return for its validation work, receives rewards sent from the consumer chain (e.g,. Stride tokens).","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Replicated Security overview","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"The idea behind Replicated Security is rather simple. On a high level, Replicated Security works as follows: Whenever a validator-set change takes place (e.g., undelegations, redelegations, etc.) on the provider chain, the provider chain sends a validator-set-change packet (","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"VSCPacket","nodeType":"text"},{"data":{},"marks":[],"value":") to all the consumer chains that it secures. This ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"VSCPacket","nodeType":"text"},{"data":{},"marks":[],"value":" contains the updated validator set of the provider chain. When a consumer chain receives a ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"VSCPacket","nodeType":"text"},{"data":{},"marks":[],"value":" it applies the changes to its validator set (through the ","nodeType":"text"},{"data":{"uri":"https://docs.cometbft.com/v0.34/spec/abci/abci#endblock"},"content":[{"data":{},"marks":[{"type":"underline"},{"type":"italic"}],"value":"EndBlock","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" of CometBFT). This way, the provider replicates its validator set and hence its security to the consumer chain. We depict the ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"VSCPacket","nodeType":"text"},{"data":{},"marks":[],"value":"s in the figure below. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"6592AjBVos2rWy8ggg1Vbo","type":"Asset","createdAt":"2024-01-31T19:46:40.408Z","updatedAt":"2024-02-02T17:38:09.418Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":7,"revision":2,"locale":"en-US"},"fields":{"title":"Validator V starts unbonding","description":"","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/6592AjBVos2rWy8ggg1Vbo/a6d74a65b4584099d2b465f43aaa317d/6_replicated_security_1.png","details":{"size":103947,"image":{"width":1321,"height":703}},"fileName":"6_replicated_security_1.png","contentType":"image/png"}}}},"content":[],"nodeType":"embedded-asset-block"},{"data":{},"content":[{"data":{},"marks":[],"value":"After a consumer chain receives a ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"VSCPacket","nodeType":"text"},{"data":{},"marks":[],"value":", the consumer chain waits for an unbonding period and then sends back a ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"VSCMaturedPacket","nodeType":"text"},{"data":{},"marks":[],"value":" to the provider chain. The provider chain can only unbond tokens after it has received a VSCMaturedPacket","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":" ","nodeType":"text"},{"data":{},"marks":[],"value":"from all of its consumer chains as seen in the figure below.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"2Wef63h4ArbZiGpI40xuUY","type":"Asset","createdAt":"2024-01-31T19:47:14.912Z","updatedAt":"2024-02-02T17:38:27.212Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":7,"revision":2,"locale":"en-US"},"fields":{"title":"Validator V starts unbonding #2","description":"","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/2Wef63h4ArbZiGpI40xuUY/5d63e946914b7e83a6bbef4e53f6bb26/7_replicated_security_2.png","details":{"size":123633,"image":{"width":1369,"height":1065}},"fileName":"7_replicated_security_2.png","contentType":"image/png"}}}},"content":[],"nodeType":"embedded-asset-block"},{"data":{},"content":[{"data":{},"marks":[],"value":"The ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"VSCMaturedPacket","nodeType":"text"},{"data":{},"marks":[],"value":" was introduced in the protocol to ensure the security of the consumer chain, so that if a malicious validator misbehaves on the consumer chain, the tokens of the malicious validator would not have yet unbonded on the provider chain and hence the malicious validator can still be slashed.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Because of ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"VSCMaturedPackets","nodeType":"text"},{"data":{},"marks":[],"value":", the unbonding of tokens on Cosmos Hub could be delayed more than the usual 21 days. This delay is called ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"unbonding pausing","nodeType":"text"},{"data":{},"marks":[],"value":". This can happen if for example, the ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"VSCMaturedPackets","nodeType":"text"},{"data":{},"marks":[],"value":" is delayed to be sent from a consumer chain, for various reasons, such as the consumer chain is down, relayers are down, etc. Although rare in practice, ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"unbonding pausing","nodeType":"text"},{"data":{},"marks":[],"value":" has ","nodeType":"text"},{"data":{"uri":"https://www.reddit.com/r/cosmosnetwork/comments/13w71ao/unbonded_atom_stuck_in_pending/?utm_source=share&utm_medium=ios_app&utm_name=ioscss&utm_content=1&utm_term=1"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"occurred in the past","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Note that Replicated Security contains many other components such as reward distribution, consumer-key assignments, etc. that we do not describe here because they are not necessary for understanding the inherent limitation of unbonding pausing.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"There are two reasons that we want to remove ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"VSCMaturedPacket","nodeType":"text"},{"data":{},"marks":[],"value":"s from Replicated Security. One is to eliminate unbonding pausing, although it can only occur in exceptional circumstances, it would be better if it could never occur. Additionally, the use of ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"VSCMaturedPackets","nodeType":"text"},{"data":{},"marks":[],"value":" substantially complicates the protocol and its implementation. As a result, if we were to remove ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"VSCMaturedPackets","nodeType":"text"},{"data":{},"marks":[],"value":" we would be able to eliminate thousands-of-lines of code ending up with a simpler protocol and we would be better equipped when working on new protocols, such as ","nodeType":"text"},{"data":{"uri":"https://forum.cosmos.network/t/chips-discussion-phase-partial-set-security/11775"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Partial Set Security","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Can we remove ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"VSCMaturedPacket","nodeType":"text"},{"data":{},"marks":[],"value":"s?","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"In our investigation we found that there is no way to remove ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"VSCMaturedPacket","nodeType":"text"},{"data":{},"marks":[],"value":"s without compromising security. Specifically, we argue that there is no way to remove ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"VSCMaturedPacket","nodeType":"text"},{"data":{},"marks":[],"value":"s without compromising the security of light clients connected to consumer chains.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We first describe a useful inequality when we think about the problem of removing ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"VSCMaturedPacket","nodeType":"text"},{"data":{},"marks":[],"value":"s and then present some assumptions we can make so that the inequality holds. At the end, we present a realistic example of a potential attack in a setting where we do not have ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"VSCMaturedPacket","nodeType":"text"},{"data":{},"marks":[],"value":"s.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Inequality ","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"A nice way to think about the ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"VSCMaturedPacket","nodeType":"text"},{"data":{},"marks":[],"value":"s-removal problem is through the following inequality (for simplicity in what follows we only consider one consumer chain):","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"italic"},{"type":"bold"}],"value":"DeliveryTimeOfVSCPacket ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"+","nodeType":"text"},{"data":{},"marks":[{"type":"italic"},{"type":"bold"}],"value":" ConsumerTrustingPeriod ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"+","nodeType":"text"},{"data":{},"marks":[{"type":"italic"},{"type":"bold"}],"value":" EvidenceSubmissionPeriod ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"<= ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"},{"type":"bold"}],"value":"ProviderUnbondingPeriod","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"where:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"italic"},{"type":"bold"}],"value":"DeliveryTimeOfVSCPacket","nodeType":"text"},{"data":{},"marks":[],"value":" is the time it takes for a ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"VSCPacket ","nodeType":"text"},{"data":{},"marks":[],"value":"to be delivered to the consumer chain from the point the corresponding validator-set updates were generated on the provider chain.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"italic"},{"type":"bold"}],"value":"ConsumerTrustingPeriod","nodeType":"text"},{"data":{},"marks":[],"value":" usually corresponds to ⅔ of the ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"ConsumerUnbondingPeriod","nodeType":"text"},{"data":{},"marks":[],"value":". Naturally this is light-client specific but let us assume for simplicity that all consumer light clients have the same trusting period.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"italic"},{"type":"bold"}],"value":"EvidenceSubmissionPeriod","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":" ","nodeType":"text"},{"data":{},"marks":[],"value":"corresponds to the period of time we would like to have to be able to ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"act","nodeType":"text"},{"data":{},"marks":[],"value":" on evidence. For example, the Cosmos Hub has an unbonding period of 21 days and Cosmos Hub light clients typically have a trusting period of 14 days, which means that we get 7 days to submit and act on light-client-attack evidence. ","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"italic"},{"type":"bold"}],"value":"ProviderUnbondingPeriod ","nodeType":"text"},{"data":{},"marks":[],"value":"is the unbonding period on the provider chain.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"Below, we see a graphical depiction of those variables:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"2JroHiWL6SSykCLjMaAZgE","type":"Asset","createdAt":"2024-01-31T19:47:59.774Z","updatedAt":"2024-02-02T17:38:45.902Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":7,"revision":2,"locale":"en-US"},"fields":{"title":"Validator V starts unbonding #3","description":"","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/2JroHiWL6SSykCLjMaAZgE/73675da4b6a369e79bf6b7778fb12c10/8_inequality.png","details":{"size":167989,"image":{"width":2190,"height":746}},"fileName":"8_inequality.png","contentType":"image/png"}}}},"content":[],"nodeType":"embedded-asset-block"},{"data":{},"content":[{"data":{},"marks":[],"value":"Note that we can slightly adjust ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"},{"type":"bold"}],"value":"EvidenceSubmissionPeriod","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":" ","nodeType":"text"},{"data":{},"marks":[],"value":"and ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"},{"type":"bold"}],"value":"ConsumerTrustingPeriod","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":" ","nodeType":"text"},{"data":{},"marks":[],"value":"but otherwise their values are rather predetermined. For instance, we would probably agree beforehand that we need at least ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"X","nodeType":"text"},{"data":{},"marks":[],"value":" days of time to act on evidence and hence ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"EvidenceSubmissionPeriod","nodeType":"text"},{"data":{},"marks":[],"value":" should be ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"X","nodeType":"text"},{"data":{},"marks":[],"value":". Also, reducing the ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"},{"type":"italic"}],"value":"ConsumerTrustingPeriod","nodeType":"text"},{"data":{},"marks":[],"value":" would make consumer light clients more prone to expirations because it would be harder to guarantee that they are getting updated during their ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"trustingPeriod","nodeType":"text"},{"data":{},"marks":[],"value":". To reactivate an expired light client, a governance proposal is needed, making the reactivation of clients a time-consuming ordeal.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"On the contrary, we have ample wiggle room to adjust ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"},{"type":"bold"}],"value":"ProviderUnbondingPeriod","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":" ","nodeType":"text"},{"data":{},"marks":[],"value":"and ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"},{"type":"bold"}],"value":"DeliveryTimeOfVSCPacket","nodeType":"text"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Why should this inequality hold?","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"The inequality must hold, otherwise the security of 3rd-party-chain light clients connected to a consumer chain would get compromised. We can see this with a couple of examples in which we have fixed ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"ProviderUnbondingPeriod ","nodeType":"text"},{"data":{},"marks":[],"value":"= (21 days), ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"ConsumerTrustingPeriod ","nodeType":"text"},{"data":{},"marks":[],"value":"= (10 days), and ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"EvidenceSubmissionPeriod = (5 days)","nodeType":"text"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"In the following figure we see that in case ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"DeliveryTimeOfVSCPacket = 8 days","nodeType":"text"},{"data":{},"marks":[],"value":", the effective time we actually have to slash a malicious validator on a light client attack (red-shaded area) is just 3 days: Day 19, 20, and 21) compared to the 5 days (= ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"EvidenceSubmissionPeriod","nodeType":"text"},{"data":{},"marks":[],"value":") we want. The green-shared area corresponds to the ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"trustingPeriod ","nodeType":"text"},{"data":{},"marks":[],"value":"of light client ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"LC","nodeType":"text"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"6CR3YR3xTJlGd9wuUWnX1W","type":"Asset","createdAt":"2024-01-31T19:48:43.676Z","updatedAt":"2024-02-02T17:39:06.552Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":7,"revision":2,"locale":"en-US"},"fields":{"title":"Day 1 Validator V starts unbonding","description":"","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/6CR3YR3xTJlGd9wuUWnX1W/94e9be86a5f3323dfac9966be787353c/9_inequality.png","details":{"size":222644,"image":{"width":1932,"height":1204}},"fileName":"9_inequality.png","contentType":"image/png"}}}},"content":[],"nodeType":"embedded-asset-block"},{"data":{},"content":[{"data":{},"marks":[],"value":"If the ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"DeliveryTimeOfVSCPacket ","nodeType":"text"},{"data":{},"marks":[],"value":"is even longer (e.g., 13 days), then we do not have any time to slash for a potential light-client attack and the light clients are not secure. This could happen if a malicious validator ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"V","nodeType":"text"},{"data":{},"marks":[],"value":" with > ⅓ voting power unbonds on Day 1 on the provider, issues a light-client update for 3rd-party-chain light client ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"LC ","nodeType":"text"},{"data":{},"marks":[],"value":"on Day 12 and then after the unbonding has completed on Day 21, issues another light-client update on Day 22 when ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"V ","nodeType":"text"},{"data":{},"marks":[],"value":"has fully unbonded. Because the ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"trustingPeriod","nodeType":"text"},{"data":{},"marks":[],"value":" of ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"LC ","nodeType":"text"},{"data":{},"marks":[],"value":"is 10 days, validator ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"V ","nodeType":"text"},{"data":{},"marks":[],"value":"can successfully issue a bogus client update on Day 22 without getting slashed.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"5dIuleNfy6PJ4tOJYOhXZY","type":"Asset","createdAt":"2024-01-31T19:49:20.191Z","updatedAt":"2024-02-02T17:39:24.755Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":7,"revision":2,"locale":"en-US"},"fields":{"title":"Day 1 Validator V starts unbonding #2","description":"","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/5dIuleNfy6PJ4tOJYOhXZY/6bf77703962ba7cd1d21ec2fa9e4c595/10_inequality.png","details":{"size":241951,"image":{"width":1936,"height":1408}},"fileName":"10_inequality.png","contentType":"image/png"}}}},"content":[],"nodeType":"embedded-asset-block"},{"data":{},"content":[{"data":{},"marks":[],"value":"Possible approaches so that the inequality holds","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"We describe two approaches that guarantee that the inequality holds.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Replicated Security\n","nodeType":"text"},{"data":{},"marks":[],"value":"If ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"ProviderUnbondingPeriod","nodeType":"text"},{"data":{},"marks":[],"value":" is fixed, then a long ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"DeliveryTimeOfVSCPacket","nodeType":"text"},{"data":{},"marks":[],"value":" would violate the inequality. The current Replicated Security approach states that if ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"DeliveryTimeOfVSCPacket","nodeType":"text"},{"data":{},"marks":[],"value":" takes too long, then we increase ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"ProviderUnbondingPeriod","nodeType":"text"},{"data":{},"marks":[],"value":" and hence we have “unbonding pausing.” This way the inequality remains true.\n\nNaturally, in a world where we want to remove ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"VSCMaturedPacket","nodeType":"text"},{"data":{},"marks":[],"value":"s because we want to eliminate “unbonding pausing,” any solution that increases ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"ProviderUnbondingPeriod","nodeType":"text"},{"data":{},"marks":[],"value":" is unsatisfactory. This is because such a “solution” enforces an additional delay on ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"all","nodeType":"text"},{"data":{},"marks":[],"value":" the unbondings on the provider chain by default and hence is not better than the current approach where in some exceptional cases, some unbondings might get delayed.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Bound ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"},{"type":"bold"}],"value":"DeliveryTimeOfVSCPacket\n","nodeType":"text"},{"data":{},"marks":[],"value":"Another ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/interchain-security/pull/712/"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"proposal made by AiB","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" is that when ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"DeliveryTimeOfVSCPacket ","nodeType":"text"},{"data":{},"marks":[],"value":"is too long (i.e., 8 days) then the consumer chain would halt. By doing this we satisfy the above inequality, in the sense that we put an upper limit on what ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"DeliveryTimeOfVSCPacket","nodeType":"text"},{"data":{},"marks":[],"value":" can be.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"\nThe problem with this approach is what happens if ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"DeliveryTimeOfVSCPacket","nodeType":"text"},{"data":{},"marks":[],"value":" takes longer than expected. In such a scenario, 3rd-party-chain light clients connected to the consumer chain would be not secure as previously shown.\n\nFinally, note that halting a chain does not do much to protect light clients connected to this chain. A malicious validator can keep sending bogus updates to a light client tracking that chain even though the chain might have halted or might not be accepting user-generated transactions.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"ordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"Assumptions","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"Naturally, whether the inequality holds or not depends on the protocol and what assumptions we make. In what follows, we describe assumptions starting from the stronger ones.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The stronger the assumptions are, the easier it is to design a protocol that works under such assumptions. However, such a protocol will not be as reliable as one that is designed under weaker assumptions. That is, because when those strong assumptions get violated the protocol does not behave as expected. For instance if we were to assume a setting, let us call it ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"normal operation ","nodeType":"text"},{"data":{},"marks":[],"value":"where the following assumptions hold:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"time for a message to be delivered from a provider to a consumer chain is bounded (e.g., always less than 2 days);","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"there is no significant (e.g., < 60s) clock drift between the provider and the consumer chain when referring to their ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/blob/v0.38.2/spec/consensus/bft-time.md"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"BFT times","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":";","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"chains are live and keep producing blocks at regular intervals (e.g., every 10 seconds).","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"ordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"Effectively the above assumptions combined bound ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"DeliveryTimeOfVSCPacket","nodeType":"text"},{"data":{},"marks":[],"value":". For example, if there is a clock drift and the consumer chain is lagging behind (e.g., 10 days behind), then it could perceive this as being equivalent to a long delay in the delivery of ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"DeliveryTimeOfVSCPacket","nodeType":"text"},{"data":{},"marks":[],"value":". Similarly, if the consumer chain is delayed and produces one block every 5 days, then any ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"DeliveryTimeOfVSCPacket ","nodeType":"text"},{"data":{},"marks":[],"value":"is effectively delayed, etc.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"In such a ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"normal operation","nodeType":"text"},{"data":{},"marks":[],"value":", we could simply remove ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"VSCMaturedPacket","nodeType":"text"},{"data":{},"marks":[],"value":"s from Replicated Security without any issue. Similarly, the ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/interchain-security/pull/712/"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"proposal made by AiB","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" would work fine as well. However such a protocol would break if one of the above assumptions gets violated.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We do ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"not","nodeType":"text"},{"data":{},"marks":[],"value":" believe that those assumptions, at least the first one, are reasonable and we are not really interested in a solution that “fails” when those assumptions do not hold anymore.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"As a matter of fact, Replicated Security works under a weaker set of assumptions where we assume that the time it takes for a message to be delivered from the provider to the consumer is unbounded and that chains can halt for long periods of time. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"An example of a potential attack","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"We present a potential real-world profitable attack in a setting where we do not have ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"VSCMaturedPacket","nodeType":"text"},{"data":{},"marks":[],"value":"s. In this attack, an attacker can convince the Kujira chain that it has an arbitrary number of Neutron tokens (NTRNs) that the attacker then swaps with other tokens on Kujira and therefore makes money out of thin air. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"For this attack to take place we consider the Neutron consumer chain and the light client in Kujira that tracks Neutron. Specifically, the light client with ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"clientId","nodeType":"text"},{"data":{},"marks":[],"value":" ","nodeType":"text"},{"data":{"uri":"https://ping.pub/kujira/ibc/connection"},"content":[{"data":{},"marks":[{"type":"underline"},{"type":"italic"}],"value":"07-tendermint-112","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", that from now on we would refer to as ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"Kujira client","nodeType":"text"},{"data":{},"marks":[],"value":". This Kujira client has a ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"trustingPeriod ","nodeType":"text"},{"data":{},"marks":[],"value":"of 17 days (i.e., 1468800s) and a ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"trustLevel ","nodeType":"text"},{"data":{},"marks":[],"value":"of ⅓ (i.e., to verify a light-client header, this client only needs an intersection with more than ⅓ voting power with a trusted header).","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Additionally, for this attack to be possible, we consider a validator ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"V ","nodeType":"text"},{"data":{},"marks":[],"value":"with > ⅓ voting power on Cosmos Hub. The same attack could be performed by a set of validators that have >⅓ accumulated voting power but for simplicity we only consider a single malicious validator ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"V","nodeType":"text"},{"data":{},"marks":[],"value":" with > ⅓ voting power.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We furthermore assume that Neutron halts for 5 days. It is not unrealistic for a consumer chain to halt for a prolonged period of time and Neutron has ","nodeType":"text"},{"data":{"uri":"https://blog.neutron.org/neutron-halt-post-mortem-927dbe4540c8"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"halted for ~9 hours in the past","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" (see BFT time difference between blocks ","nodeType":"text"},{"data":{"uri":"https://www.mintscan.io/neutron/block/1909053"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"1909053","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" and ","nodeType":"text"},{"data":{"uri":"https://www.mintscan.io/neutron/block/1909054"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"1909054","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":").","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Now consider that when Neutron halts, validator ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"V","nodeType":"text"},{"data":{},"marks":[],"value":" immediately unbonds all its stake on the Cosmos Hub. Additionally, assume that when Neutron is back on Day 6, it decides and executes on a block ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"X ","nodeType":"text"},{"data":{},"marks":[],"value":"that does not yet contain the ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"VSCPacket","nodeType":"text"},{"data":{},"marks":[],"value":" that informs Neutron that ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"V ","nodeType":"text"},{"data":{},"marks":[],"value":"has unbonded. But later, for example at block ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"X + 1","nodeType":"text"},{"data":{},"marks":[],"value":", Neutron picks up this ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"VSCPacket","nodeType":"text"},{"data":{},"marks":[],"value":" change.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"5SBkYFFGyIzHwApExfSood","type":"Asset","createdAt":"2024-01-31T19:50:14.567Z","updatedAt":"2024-02-02T17:39:41.702Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":7,"revision":2,"locale":"en-US"},"fields":{"title":"Day 1 Validator V starts unbonding #3","description":"","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/5SBkYFFGyIzHwApExfSood/44b7728b768ac69c17787c0daf6718ea/11_kujira.png","details":{"size":356113,"image":{"width":2149,"height":1440}},"fileName":"11_kujira.png","contentType":"image/png"}}}},"content":[],"nodeType":"embedded-asset-block"},{"data":{},"content":[{"data":{},"marks":[],"value":"Now, the light client on Kujira that tracks Neutron could be updated with a header from block ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"X","nodeType":"text"},{"data":{},"marks":[],"value":" that contains validator ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"V","nodeType":"text"},{"data":{},"marks":[],"value":" in its header. Later, on Day 22 when ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"V","nodeType":"text"},{"data":{},"marks":[],"value":" has unbonded everything, validator ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"V ","nodeType":"text"},{"data":{},"marks":[],"value":"can create a bogus light-client update using as ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"trustedHeader","nodeType":"text"},{"data":{},"marks":[],"value":" that of block height ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"X","nodeType":"text"},{"data":{},"marks":[],"value":" and update the Kujira client. This client update would get accepted because the ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"trustingPeriod","nodeType":"text"},{"data":{},"marks":[],"value":" since block ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"X","nodeType":"text"},{"data":{},"marks":[],"value":" has not expired yet. This can be seen in the diagram above where the green-shaded area corresponds to the trusting period. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"By being able to send bogus light-client updates to the Kujira client, ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"V","nodeType":"text"},{"data":{},"marks":[],"value":" can now pretend it just sent an arbitrary amount of NTRNs to Kujira by first sending a bogus ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"MsgUpdateClient ","nodeType":"text"},{"data":{},"marks":[],"value":"that contains a bogus ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"appHash ","nodeType":"text"},{"data":{},"marks":[],"value":"and then a ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"MsgRecvPacket ","nodeType":"text"},{"data":{},"marks":[],"value":"that contains a “proof” that an arbitrary number of Neutron was sent over to Kujira. At this point, someone could swap the NTRNs with other tokens on Kujira. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Censoring","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"For the above scenario to take place, a malicious validator would need to start unbonding when Neutron halts but at this stage such a validator cannot possibly know how long Neutron would be down for. For example, if Neutron is only down for 10 hours, then the aforementioned attack on the Kujira client cannot take place.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Note however that a malicious validator with > ⅓ voting power can perform a similar kind-of an attack by unbonding all its tokens on Cosmos Hub and at the same time censor all ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"VSCPackets","nodeType":"text"},{"data":{},"marks":[],"value":" that are sent to Neutron for 5 days. After 5 days it stops censoring ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"VSCPackets","nodeType":"text"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Conclusion","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"In this blog post we gave a high-level overview of how IBC light clients operate. We presented Replicated Security and described unbonding pausing. Finally, we showed why we cannot eliminate unbonding pausing without compromising the security of light clients that are connected to consumer chains. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Acknowledgments","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"Thanks to Jae Kwon for first proposing to remove ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"VSCMaturedPacket","nodeType":"text"},{"data":{},"marks":[],"value":"s. Additionally, many thanks to Marius Poke, Josef Widder, Philip Offtermatt, Jehan Tremback, Aditya Sripal, Albert Le Batteux, and Thomas Bruyelle for all the constructive discussions related to unbonding pausing.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"scripts":["MathJAX for LaTeX support"],"contentfulURL":"https://app.contentful.com/spaces/p79kctcd7ahy/entries/4uvJ2PNgC3KBzzQiPwLrLu"},{"featureImage":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"5g7vMad9hssXelXiUmYW0I","type":"Asset","createdAt":"2024-08-14T03:15:52.326Z","updatedAt":"2024-08-14T03:15:52.326Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":3,"revision":1,"locale":"en-US"},"fields":{"title":"https images.ctfassets.net p79kctcd7ahy 7oybEZkvFnUUXYAJctLwis 872b23fa0d1d56f7d2010cf64bb892c9 Screenshot 2024-01-11 at 8.17.49 PM","description":"","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/5g7vMad9hssXelXiUmYW0I/7b35957faf069c511dc6443d7df46336/https___images.ctfassets.net_p79kctcd7ahy_7oybEZkvFnUUXYAJctLwis_872b23fa0d1d56f7d2010cf64bb892c9_Screenshot_2024-01-11_at_8.png","details":{"size":25103,"image":{"width":1566,"height":838}},"fileName":"https___images.ctfassets.net_p79kctcd7ahy_7oybEZkvFnUUXYAJctLwis_872b23fa0d1d56f7d2010cf64bb892c9_Screenshot_2024-01-11_at_8.17.49_PM.png","contentType":"image/png"}}},"date":"2024-01-12","title":"Model-Based Testing Keeps Cosmos Hub Specifications Synchronized with Code","slug":"model-based-testing-for-the-cosmos-hub","categories":["Engineering"],"authors":["Philip Offtermatt"],"keywords":"model-based-testing, cosmos-hub, quint-specification, interchain-security, formal-verification, specification-testing, protocol-modeling, code-synchronization, automated-reasoning, blockchain-testing","excerpt":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"How Quint models prevent specification drift in Interchain Security development.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"includeTableOfContents":false,"body":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Interchain security is a cornerstone protocol of the Cosmos Hub. We want to iterate on this protocol, to add features and make it more useful, cheaper, and fit changing requirements. However, it is critical that we do not compromise quality or robustness when we iterate, as the protocol is already in active use. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"In the Hub team at Informal Systems, we are utilizing Model-Based Testing (MBT for short) to ensure this development is safe. MBT has successfully been used by other teams at Informal Systems before, for example in the context of ","nodeType":"text"},{"data":{"uri":"https://www.youtube.com/watch?v=zLBl3ouWTWw"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Tendermint","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" and ","nodeType":"text"},{"data":{"uri":"https://github.com/informalsystems/tendermint-rs/tree/master/light-client/tests/support/model_based"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"IBC","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", as ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/ibc-go/blob/main/modules/apps/transfer/keeper/MBT_README.md"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"part of audits","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", and in the ","nodeType":"text"},{"data":{"uri":"https://github.com/informalsystems/atomkraft"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Atomkraft","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" tool. Of course, the ideas themselves are ","nodeType":"text"},{"data":{"uri":"https://dl.acm.org/doi/abs/10.1145/1353673.1353681"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"even older","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The idea behind MBT is to make readable and verifiable reference implementations, called models, a first-class citizen of the development process. These models can augment plain-English specifications and make them useful artifacts instead of maintenance burdens. The advantage of models is that they are less detailed than the implementation, and thus easier to reason about and iterate on.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Our current understanding is that MBT is most useful for established and somewhat stable codebases, particularly when larger additions or adjustments become necessary.\n","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Background","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"\nLet’s outline a common situation for stable codebases, which we recently encountered while working on Interchain Security. The protocol was launched about a year ago and has been running in production without major issues, but we are now planning to make some major adjustments (like ","nodeType":"text"},{"data":{"uri":"https://forum.cosmos.network/t/chips-discussion-phase-partial-set-security/11775"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"partial set security","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"). This presents some challenges:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"When the protocol was originally designed, the team wrote a large plain-English specification. The ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/ibc/blob/main/spec/app/ics-028-cross-chain-validation/README.md"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"specification","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" describes the protocol, outlines correctness properties (such as state invariants), and reasons about why the correctness properties are satisfied by the protocol.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"This initial specification also includes quite a bit of pseudocode, though it isn’t detailed enough to directly translate to implementation code. With the specification in good shape, the team went on to implement the protocol. Over time the ultimate source of truth shifted from the specification to the implementation - what’s in the code is how it’s supposed to work. As the project matures, the specification often lags behind when changes are made, becoming less truthful and less useful over time.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"\nEventually, the plain-English specification had lost a lot of its initial utility, simply because it diverged too much from the implementation to be useful for most things. The pseudocode parts fall out of sync fastest, because they often try to be more detailed than the text around them, so even small changes to the implementation can make them obsolete. As opposed to the actual code, there is no CI that tests the pseudocode. At some point, when a developer wants to understand how something ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"actually","nodeType":"text"},{"data":{},"marks":[],"value":"$26","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Of course, a solution to this might be simply enforcing in our processes that the specification must be updated when changes to the code are made. In fact, we already have such a policy, but it’s not very effective: it is easy to forget to update the specification, and nothing enforces that the specification and implementation align, or even flags if they don’t. This makes it incredibly hard to make sure that the specification is up-to-date.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"In light of this, we would like to find ways to make it easier to align the specification and the implementation, and in particular to detect discrepancies between the two early. This is where MBT comes into play.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Model-Based Testing","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"The cornerstone of MBT is the use of models. Models can be seen as high-level reference implementations. They are supposed to be easy to understand, and to abstract away a lot of the details that an actual implementation would need. The choice of language for this model is important - we should strongly prefer readability over performance. An example of a language that might be suited for this is Python (for example, see the","nodeType":"text"},{"data":{"uri":"https://blog.ethereum.org/2023/08/29/eel-spec"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":" Ethereum Execution Layer Specifications","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"). In the hub team, we instead chose ","nodeType":"text"},{"data":{"uri":"https://github.com/informalsystems/quint"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Quint","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", a domain-specific language purpose-built for specifying distributed systems, which we prefer over a general purpose programming language like Python due to Quint's simpler semantics and higher level of abstraction.\n\nWe believe Quint is readable, as well as reasonably concise. For a rough comparison: the implementation of Interchain Security in Golang has about 13k lines (excluding tests and automatically generated files); the plain-English specification has about 3.5k lines; the Quint model comes in at around 1.8k lines. This is obviously not an apples-to-apples comparison, but it shows that the reference model can be much more concise than the implementation or plain-English specification.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The model is supposed to partially replace, but also enhance, the English specification. For example, pseudocode in the plain-English docs should be linked to the code in the model. There are ","nodeType":"text"},{"data":{"uri":"https://github.com/informalsystems/quint/blob/main/examples/cosmos/bank/cosmos-bank.md"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"also","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" ","nodeType":"text"},{"data":{"uri":"https://github.com/informalsystems/quint/blob/main/doc/literate.md"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"approaches","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" for interweaving the English and model code directly.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The huge advantage of the model over English text is that it is ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"executable","nodeType":"text"},{"data":{},"marks":[],"value":". This is very helpful while writing the model. It’s much easier to keep everything internally consistent when it’s possible to actually run and observe what happens. Despite this, the model remains relatively readable because we can omit unnecessary details by choosing the right level of abstraction. For example, we do not need to worry about how to interact with lower levels in the stack like the consensus layer when we are specifying our application logic.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"\n","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The fact that the model is executable also helps ensure that the model and implementation do not diverge. We can generate possible executions of the model, and then check, for each model execution, whether the same execution visits the same states along the way in the actual implementation. Quint provides a simulator that randomly generates such executions and outputs them in an ","nodeType":"text"},{"data":{"uri":"https://apalache.informal.systems/docs/adr/015adr-trace.html"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"easy-to-parse json format","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". Then we only need to write a driver, which can read these execution traces and execute them against the implementation. If the driver detects a difference between the model state and the actual execution, it flags it. Running this as part of our test suite allows us to detect any differences between the model and the implementation early.\n","nodeType":"text"}],"nodeType":"paragraph"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"7oybEZkvFnUUXYAJctLwis","type":"Asset","createdAt":"2024-01-12T01:21:10.488Z","updatedAt":"2024-01-12T01:21:10.488Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":3,"revision":1,"locale":"en-US"},"fields":{"title":"Screenshot 2024-01-11 at 8.17.49 PM","description":"","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/7oybEZkvFnUUXYAJctLwis/872b23fa0d1d56f7d2010cf64bb892c9/Screenshot_2024-01-11_at_8.17.49_PM.png","details":{"size":143290,"image":{"width":1566,"height":838}},"fileName":"Screenshot 2024-01-11 at 8.17.49 PM.png","contentType":"image/png"}}}},"content":[],"nodeType":"embedded-asset-block"},{"data":{},"content":[{"data":{},"marks":[],"value":"A sketch of our MBT implementation.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Even better, the execution traces serve as a test suite themselves, and can provide good coverage for very little code investment. In the case of Interchain Security, our driver has around 1.7k lines of code, and provides roughly the same line coverage as our integration test suite with around 6k lines of code. (Each provides around 40% coverage. For context, all tests in the repository combined provide around 80% coverage.) Again, this is not an apples-to-apples comparison, but it shows that model-based testing is not only a way to ensure alignment between the model and implementation, but also a way to augment other testing efforts. I would not recommend relying solely on MBT for testing, but instead to see the extra test coverage as the proverbial cherry on the cake. MBTs main advantage is to ensure compliance between the specification and implementation in a way that other approaches have a hard time replicating.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Further, by choosing Quint as our language for the model, we get access to powerful tools for automated reasoning. We can formalize our correctness properties in Quint, and use model-checkers to automatically prove that they hold, or find counterexamples if they do not. Quint is integrated with ","nodeType":"text"},{"data":{"uri":"https://apalache.informal.systems/"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Apalache","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", a symbolic bounded model checker, for this purpose.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Quint is a language that is designed to be verifiable, so it is much more promising to run a model checker on the higher-level Quint model, rather than directly on the implementation. This is an advantage over languages that are meant for producing actual implementations, like Python or Typescript. ","nodeType":"text"},{"data":{},"marks":[],"value":"On the other hand, one of the design principles behind Quint is to use a syntax that intentionally stays close to mainstream programming languages where possible, and in this way Quint aims to improve adoption by engineers without a background in formal methods. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"This is an example of a correctness property of Interchain Security, formalized in Quint:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"6VKjfZs8lgxUMMZoYCcOVp","type":"Asset","createdAt":"2024-01-12T01:13:32.965Z","updatedAt":"2024-01-12T01:13:32.965Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":3,"revision":1,"locale":"en-US"},"fields":{"title":"Screenshot 2024-01-11 at 8.13.09 PM","description":"","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/6VKjfZs8lgxUMMZoYCcOVp/b2de8ad6f8d9bfe3fc791d19ad63c3cf/Screenshot_2024-01-11_at_8.13.09_PM.png","details":{"size":92278,"image":{"width":1380,"height":476}},"fileName":"Screenshot 2024-01-11 at 8.13.09 PM.png","contentType":"image/png"}}}},"content":[],"nodeType":"embedded-asset-block"},{"data":{},"content":[{"data":{},"marks":[],"value":"\nTo conclude this section, model-checking and model-based testing are a very powerful combination. The process is as follows:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"We have model-checked the model, and we are therefore sure that it satisfies the correctness properties. ","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"We have tested that the model and the implementation align and behave equivalently on a large set of executions.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Therefore, we increase our confidence that the implementation also satisfies the correctness properties.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"Limitations","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"$27","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Conclusion","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"Divergence between the specification and implementation of critical systems is a major problem that makes changes slow and painful, and contributes to the loss of knowledge over time.\nModel-based testing is a promising approach to tackle the challenge of keeping the specification and implementation aligned, which can simultaneously improve test coverage for a relatively modest investment in terms of lines of code. It further enables the use of powerful automated reasoning techniques, which ordinarily have difficulties in scaling to complex and large code bases.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"\nIf you want to learn more about the work we do on Model-Based Testing in the Hub team, or about the work we do on Quint at Informal Systems in general, please reach out - we’d love to connect!","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"\n","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"contentfulURL":"https://app.contentful.com/spaces/p79kctcd7ahy/entries/7z11r4gKtHXIJVJ1A2NZo9"},{"featureImage":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"3YlBVGmWzonVdzJ1ZONoYB","type":"Asset","createdAt":"2024-08-16T05:10:44.922Z","updatedAt":"2024-08-16T05:10:44.922Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":3,"revision":1,"locale":"en-US"},"fields":{"title":"Blog IBCrs","description":"","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/3YlBVGmWzonVdzJ1ZONoYB/ff2bdba607ec68ae9e5cbc8593f3b567/Blog_IBCrs.jpg","details":{"size":463467,"image":{"width":1920,"height":1080}},"fileName":"Blog_IBCrs.jpg","contentType":"image/jpeg"}}},"date":"2024-01-10","title":"IBC Engineering Update: December 2023","slug":"ibc-engineering-update-december-2023","categories":["Engineering"],"authors":["Adi Seredinschi"],"keywords":"\nibc-engineering, hermes-relayer, ibc-rs, sovereign-sdk, interchain-protocols, blockchain-interoperability, cosmos-ibc, relayer-updates, ibc-integration, cross-chain-communication","excerpt":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"December 2023 updates on IBC relayer improvements and ibc-rs development.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"includeTableOfContents":true,"introduction":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Welcome to the December update from the IBC unit at Informal Systems. In this update, we'll be sharing the latest developments and progress we’ve made.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"As ","nodeType":"text"},{"data":{"uri":"https://informal.systems/blog/paving-the-way-for-a-v1-release-of-ibc-rs"},"content":[{"data":{},"marks":[],"value":"mentioned before","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", the IBC unit in Informal Systems comprises two teams working closely together: one in charge of the Hermes IBC relayer (or the “relayer” team), and the other developing ibc-rs (which we sometimes call colloquially the “modules” team). This post covers updates from both teams regarding their work in December.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"December was a shorter month than usual. At an organizational level, in Informal System we are pausing operations between Christmas and New Years Eve. We took advantage of this time to recover our strength, spend time with family and friends, reflect, and prepare for the year to come. Nevertheless, we do have numerous interesting developments to report. Buckle up! ","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"body":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Updates on Hermes IBC Relayer","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"On the Hermes side, our key objective was to ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"support the interchain ecosystem","nodeType":"text"},{"data":{},"marks":[],"value":". Pursuing this objective reflected in three major threads of work in December.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"First, we have released Hermes v1.7.4. Important improvements released in this version are in the monitoring subsystem of Hermes, as follows: ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"the ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"broadcast_errors","nodeType":"text"},{"data":{},"marks":[],"value":" metric now correctly batches the same errors together, and ","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"the ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"backlog_*","nodeType":"text"},{"data":{},"marks":[],"value":" metrics now update more accurately whenever Hermes queries pending packets.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"ordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"Beside monitoring improvements, we also enhanced the reliability of the idle worker clean-up and fixed a bug with the ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"evidence","nodeType":"text"},{"data":{},"marks":[],"value":" command which would sometimes prevent the misbehaviour evidence from being reported. See the full changelog for release ","nodeType":"text"},{"data":{},"marks":[],"value":"v1.7.4","nodeType":"text"},{"data":{},"marks":[],"value":" ","nodeType":"text"},{"data":{"uri":"https://github.com/informalsystems/hermes/blob/v1.7.4/CHANGELOG.md"},"content":[{"data":{},"marks":[],"value":"here","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Second, we have added tests for Async Interchain Queries in Hermes, towards supporting the Provenance team's use-case, which relies on this feature. Relevant work here is in the PR ","nodeType":"text"},{"data":{"uri":"https://github.com/informalsystems/hermes/pull/3711"},"content":[{"data":{},"marks":[],"value":"#3711","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Third, we have worked with the Heliax team to add support for relaying Namada chain in the Hermes relayer. Our team has worked on the testing side (specifically, PR ","nodeType":"text"},{"data":{"uri":"https://github.com/heliaxdev/hermes/pull/18"},"content":[{"data":{},"marks":[],"value":"#18","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" in Namada’s fork of Hermes), which was based on the valuable work of Heliax engineers (see PR ","nodeType":"text"},{"data":{"uri":"https://github.com/informalsystems/hermes/pull/3705"},"content":[{"data":{},"marks":[],"value":"#3705","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" in Hermes).","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Updates on IBC-rs","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"On the modules side, we have pursued two key objectives: (i) support chains in adopting ibc-rs, and (ii) scalable design to empower non-Cosmos chains. Both objectives are under the strategic outcome of ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"expanding IBC beyond the Cosmos SDK","nodeType":"text"},{"data":{},"marks":[],"value":". There’s loads of work that happened on these two tracks, so here we will only provide a quick overview. Please reach out to us if you’d like to know more about IBC stack in Rust and our work.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Supporting IBC adoption for Sovereign-based rollups","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"For the first key objective, our work heavily concerned IBC integration for the Sovereign SDK environment. Consequently, all the work here belongs to the ","nodeType":"text"},{"data":{"uri":"https://github.com/informalsystems/sovereign-ibc/"},"content":[{"data":{},"marks":[],"value":"https://github.com/informalsystems/sovereign-ibc/","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" repository. We have enhanced mock testing artefacts for Sovereign SDK integration (","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"sov-ibc-mocks","nodeType":"text"},{"data":{},"marks":[],"value":" crate) to closely emulate real-world scenarios, thereby allowing us to execute a variety of tests. More specifically, we refactored mock rollup to work with generic DA layer (#","nodeType":"text"},{"data":{"uri":"https://github.com/informalsystems/sovereign-ibc/pull/49"},"content":[{"data":{},"marks":[],"value":"49","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"). We also defined the ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"MockTendermint","nodeType":"text"},{"data":{},"marks":[],"value":" struct to mock Celestia as the DA layer for rollups (#","nodeType":"text"},{"data":{"uri":"https://github.com/informalsystems/sovereign-ibc/pull/51"},"content":[{"data":{},"marks":[],"value":"51","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"), among other changes. We have also added tests for Sovereign SDK integration for ICS20 (#","nodeType":"text"},{"data":{"uri":"https://github.com/informalsystems/sovereign-ibc/pull/47"},"content":[{"data":{},"marks":[],"value":"47","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":").","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Working towards scalable APIs for non-Cosmos IBC adoption","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"For the second key objective, our work belongs mostly to the ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/ibc-rs/"},"content":[{"data":{},"marks":[],"value":"https://github.com/cosmos/ibc-rs/","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" repository. In this case, during December we made token transfer context APIs more flexible to better support Sovereign rollups and Composable Finance’s use cases (#","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/ibc-rs/pull/836"},"content":[{"data":{},"marks":[],"value":"836","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", #","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/ibc-rs/pull/986"},"content":[{"data":{},"marks":[],"value":"986","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"). Among other improvements, we also decoupled dependencies between the sub-crates of ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"ibc-rs","nodeType":"text"},{"data":{},"marks":[],"value":" (#","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/ibc-rs/issues/997"},"content":[{"data":{},"marks":[],"value":"997","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"). We have documented these and other associated changes in a blog post early December last year: ","nodeType":"text"},{"data":{"uri":"https://informal.systems/blog/paving-the-way-for-a-v1-release-of-ibc-rs"},"content":[{"data":{},"marks":[],"value":"Paving the way for a v1 release of IBC-rs","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Other news","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"The ICF has approved our funding for 2024 and this can be publicly consulted ","nodeType":"text"},{"data":{"uri":"https://medium.com/the-interchain-foundation/icf-funding-program-2024-3928d3b59e2f"},"content":[{"data":{},"marks":[],"value":"here","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". That post describes our current understanding of the 2024 roadmap for our teams.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We're also excited to announce that we have moved the IBC-rs community call to consolidate it into the IBC Core community call. This call happens biweekly on Tuesdays. The public notes from the call are ","nodeType":"text"},{"data":{"uri":"https://docs.google.com/document/d/1GZBkUt3rNtFAXgEbHs4U-uBGFLvQl4lNsI2E3uLw0TE"},"content":[{"data":{},"marks":[],"value":"here","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", and to join the group see the information ","nodeType":"text"},{"data":{"uri":"https://groups.google.com/g/ibc-community"},"content":[{"data":{},"marks":[],"value":"here","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"contentfulURL":"https://app.contentful.com/spaces/p79kctcd7ahy/entries/CGbWchz6xu8BGxg51obYC"},{"featureImage":"$4:props:posts:25:featureImage","date":"2024-01-10","title":"CometBFT v1 Alpha 2 Progress and December 2023 Engineering Updates","slug":"cometbft-engineering-update-december-2023","categories":["Engineering"],"authors":["Andy Nogueira"],"keywords":"cometbft-v1, pbts-timestamps, storage-optimization, consensus-engineering, alpha-release, blockchain-storage, cometbft-updates, performance-improvements, distributed-consensus, engineering-progress","excerpt":{"nodeType":"document","data":{},"content":[{"nodeType":"paragraph","data":{},"content":[{"nodeType":"text","value":"PBTS development prioritization and storage optimization work in latest release.","marks":[],"data":{}}]}]},"includeTableOfContents":true,"introduction":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Welcome to the December update from the CometBFT team at Informal Systems. In this update, we'll be sharing our team's latest developments and progress.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"During December 2023, our team continued to focus on completing tasks required for the upcoming CometBFT v1 Alpha 2 release.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We also continued our efforts to optimize storage and worked on issues to reduce technical debt and fix some bugs.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"body":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"CometBFT v1 Alpha 2","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"We have been making progress towards the v1 alpha.2 release. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We’ve Identified Proposer-Based Timestamps (PBTS) as a high-priority item to be included in v1-alpha.2, scoped it and initiated ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/issues/1731"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"work on it","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Concerning testing and QA for v1, we’ve decided to delay them until after the work on PBTS is ready. However, we did work on some ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/pull/1829"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"testing improvements","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" related to e2e tests.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Storage Optimization","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"The development team also worked on a few tasks to optimize storage and make it more efficient.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"One of the optimizations was related to improvements in the ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/pull/1755"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"logic of batch saves to storage ","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"based on the block part size.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The team also ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/pull/1764"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"started working on some logic","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" to lexicographically encode the keys in the state store, block store, evidence pool, and light store. Eventually, this will improve data access (lookups) and make compaction more performant.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Testing and Bug Fixes","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"We implemented a range of ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/pulls?q=is%3Apr+is%3Aclosed+merged%3A2023-12-01..2023-12-31+base%3Amain+sort%3Aupdated-desc+-label%3Aautomerge+label%3Ae2e"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"fixes and enhancements","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" to address issues identified during the end-to-end (e2e) testing process. The goal was to ensure that the tests are more comprehensive, accurate, and reliable.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Our team has also ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/pulls?q=is%3Apr+is%3Aclosed+merged%3A2023-12-01..2023-12-31+base%3Amain+sort%3Aupdated-desc+-label%3Aautomerge+label%3Abug"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"addressed some bugs","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" to improve the overall functionality of the system and reduce technical debt","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Thank you for taking the time to stay up-to-date with our work","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"If you have any questions or want to discuss anything related to CometBFT, feel free to connect with our team on ","nodeType":"text"},{"data":{"uri":"https://discord.gg/cosmosnetwork"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Discord","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" or ","nodeType":"text"},{"data":{"uri":"https://t.me/CometBFT"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Telegram","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". We are always ready to assist you and provide you with the necessary information. Don't hesitate to reach out and keep the conversation going!","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Stay updated: Follow @cometbft on ","nodeType":"text"},{"data":{"uri":"https://twitter.com/cometbft"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Twitter","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"CometBFT is currently being stewarded by ","nodeType":"text"},{"data":{"uri":"http://informal.systems/"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Informal Systems","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" with support from many contributors across the Interchain stack, including the Cosmos SDK and IBC teams.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"contentfulURL":"https://app.contentful.com/spaces/p79kctcd7ahy/entries/7L65WYfohfl0iy6J7xsfR2"},{"title":"Holiday protocols: Secret Santa with Quint 🎅","id":"https://quint-lang.org/posts/secret_santa","link":"https://quint-lang.org/posts/secret_santa","date":"2023-12-23","description":"A fun exploration of drawing strategies for Secret Santa and their properties.","categories":["Quint"]},{"featureImage":"$4:props:posts:29:featureImage","date":"2023-12-21","title":"Cosmos Hub 2023 Recap - Replicated Security Launch and LSM Integration","slug":"informal-systems-hub-team-year-end-recap","categories":["Engineering"],"authors":["Brian Truax"],"keywords":"Year-end review of Neutron launch, Stride migration, and testing improvements.","excerpt":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"cosmos-hub-recap, replicated-security, neutron-launch, stride-migration, liquid-staking-module, model-based-testing, cosmos-governance, interchain-security, comet-mock, cosmos-development","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"includeTableOfContents":false,"body":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"2023 has been a big year for the Informal Systems' Hub team and the Cosmos Hub. As we reflect on the communities' achievements, it's evident that our collective efforts have significantly advanced the Cosmos ecosystem. Here's a look at the key milestones and developments that marked this year.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Key Developments","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Launch of Replicated Security","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"The Cosmos Hub witnessed a pivotal moment with the introduction of Replicated Security in the v9 upgrade. This feature marked a leap in blockchain security, enabling consumer chains to leverage the robust security framework of the Cosmos Hub. This shared security system allows consumer chains to launch more quickly with a diverse validator set. Additionally, it enables Cosmos Hub validators to validate multiple consumer chains at once and receive a portion of their transaction fees and inflation as staking rewards in return.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Neutron Launch: The First Cosmos Chain on Replicated Security","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"Neutron marked a major milestone as the first chain to launch within the Cosmos ecosystem using Replicated Security, following extensive testing and community approval via on-chain voting. Successful appchains need security, yet new projects frequently face challenges bootstrapping a diverse set of validators. Neutron enables new projects to deploy as smart contracts within the Atom Economic Zone, allowing them to utilize Replicated Security, sharing the Cosmos Hub's security without bootstrapping their own validator set. Hypha, Neutron, CryptoCrew, and others made this possible through their hard work.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Stride's Launch: A Successful Story","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"In July 2023, the Cosmos Hub achieved a significant milestone with the successful launch of Stride as the Hub's second Consumer Chain. Here, we saw Stride become the first standalone app chain to transition to Replicated Security, a testament to the versatility and adaptability of the Cosmos Hub. The launch, which was meticulously executed, demonstrated the practical efficacy of the standalone-to-consumer migration protocol in action. This accomplishment signified a major step forward for the Cosmos Hub in expanding its Interchain Security capabilities and showcased the collaborative strength and technical sophistication of the teams involved. This launch was made possible by the brilliant teams at Stride, Hypha, and CryptoCrew.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"New Testing Frameworks: Enhancing Development without Compromising Quality","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"This year, the Informal Systems' Hub team made significant advances in ensuring quality and robustness. These efforts include the development of ","nodeType":"text"},{"data":{"uri":"https://informal.systems/blog/cometmock"},"content":[{"data":{},"marks":[],"value":"CometMock","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" and the use of Model-Based Testing (MBT). Our MBT work includes the development of clear, verifiable specifications in Quint, a purpose-built language developed at Informal Systems that enables software developers to take advantage of powerful formal verification tools. CometMock is a mock implementation of CometBFT (the consensus engine powering the cosmos ecosystem) that allows us to test edge cases in our applications easily and quickly.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Our investments in testing and verification have already proven highly useful and will enable us to develop new features for the Cosmos Hub quickly without compromising on quality. Our collaboration with the Informal Systems' ","nodeType":"text"},{"data":{"uri":"https://github.com/informalsystems/quint"},"content":[{"data":{},"marks":[],"value":"Quint team","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" enabled this success and expanded on work that the Informal Security team performed as part of security audits. Another shoutout goes to the ","nodeType":"text"},{"data":{"uri":"https://starship.cosmology.tech/"},"content":[{"data":{},"marks":[],"value":"Starship","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" team at Cosmology for integrating support for CometMock.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Keep an eye on the Informal System blog for a deeper dive into MBT next year.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Integrating the Liquid Staking Module into the Hub","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"The Cosmos Hub v12 upgrade brought the Liquid Staking Module (LSM) to the Hub, which unlocked new dynamics within the ATOM Economic Zone. This upgrade allows users to directly liquid-stake their already staked ATOM without waiting for the unbonding period. This functionality was launched with partnership from Iqlusion, Stride, and Binary Builders. The LSM introduced a new level of DeFi for the Cosmos Hub by quickly unlocking stATOM for numerous ATOM stakers without compromising yields from staking.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The Cosmos Community Funding Development for 2024","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"In November, the Cosmos community voted to pass Prop #839, funding both Informal Systems and Hypha for 2024 to be the core development and testing teams stewarding the Cosmos Hub. We have the entire Cosmos community to thank for the vote of confidence, for deep engagement with the Cosmos governance process, and to all the validators and ATOM holders who voted, regardless of which way they voted. To our knowledge, Prop #839 is the first time that a major L1 ecosystem has funded its own development via a decentralized, governance-led process like this. What a major milestone for the Cosmos Hub!","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"The Importance of Regular Upgrades","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"A notable accomplishment this year has also been the establishment of a strong cadence for regular upgrades of the Cosmos Hub. Upgrading the Hub is a complex process that requires extensive coordination among validators, development teams, and rigorous testing and planning. Successfully shipping these regular updates is a testament to our commitment to continuous improvement and adaptability. It ensures that the Cosmos Hub remains a cutting-edge platform, ready to meet the evolving needs of its users. We thank the Hypha team and the validator community for regular collaboration on these updates.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Looking Back: It All Adds Up","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"For ATOM token holders, validators, and consumer chains, all of the developments this year, taken as a whole, contribute to a more robust, secure, and scalable ecosystem. The improvements in governance and security, along with the introduction of LSM, translate into a more interconnected and efficient network, potentially leading to greater adoption and utility.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Looking Ahead: Our Shared Vision for 2024","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"As we turn the page to 2024, Informal Systems is poised to elevate the Cosmos Hub to new heights. Our plans for the coming year extend beyond technical advancement; they're about creating a more connected, efficient, and user-friendly blockchain universe that resonates with everyone — from ATOM token holders to validators, from consumer chains to our development partners and the broader interchain community.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Our 2024 Roadmap focuses on:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Expanding Interchain Security","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":": Building on the success of Replicated Security, we're diving into the development of Partial Set Security and Mesh Security. These aren't just technical upgrades; it's about making blockchain operations more cost-effective and flexible, allowing for a greater diversity of consumer chains to join us.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Gaia Maintenance and Upgrades","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":": We're committed to keeping the heart of the Cosmos Hub, Gaia, in top shape. Regular updates and strategic improvements mean a more reliable and robust platform, directly translating to a smoother experience for everyone involved.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Focused Research and Development","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":": We will focus on exploring and implementing innovative features like Atomic IBC and IBC routing. These aren't just buzzwords but the pathways to a more accessible and powerful blockchain network. In 2024, we'll enhance this technology to streamline multi-chain interactions further. Imagine a world where complex blockchain processes are simplified, where the barriers between different applications and chains dissolve, creating a seamlessly interconnected ecosystem.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Enhanced Testnets and Validator Support","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":": We understand that the backbone of any blockchain is its community of validators. That's why we're strongly emphasizing advanced testing environments and dedicated support, ensuring the Cosmos Hub runs smoothly and efficiently.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"ordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"Conclusion: A Future Bright with Innovation","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"In 2024, the Informal Systems' Hub team, alongside Hypha's Hub team, will continue our technical excellence journey and deepen our commitment to making the Cosmos Hub an inclusive, user-friendly, and forward-thinking blockchain ecosystem. We're not just building technology; we're shaping a future where the Cosmos Hub is more than a blockchain - it's a thriving community where everyone finds value, connection, and opportunity.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"contentfulURL":"https://app.contentful.com/spaces/p79kctcd7ahy/entries/6fyaKWMOYzqSq59H7RuWT2"},{"featureImage":"$4:props:posts:29:featureImage","date":"2023-12-19","title":"Cosmos Hub Q4 2023 Development - Cryptographic Verification and SDK Upgrades","slug":"cosmos-hub-update-q4-2023","categories":["Engineering"],"authors":["Marius Poke"],"keywords":"cosmos-hub-q4, gaia-upgrades, cryptographic-verification, sdk-upgrade, partial-set-security, ics-development, equivocation-detection, cosmos-testing, backward-compatibility, hub-governance","excerpt":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Quarterly update covering Gaia v14 upgrade and Partial Set Security design.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"includeTableOfContents":false,"body":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"It’s time for the usual update from the Informal Systems’ Cosmos Hub team. As the ","nodeType":"text"},{"data":{"uri":"https://informal.systems/blog/cosmos-hub-update-september-2023"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":" last update","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" was for September, we decided to do a Q4 update including the months of October, November and December. Here are some of the highlights: We released the cryptographic equivocation verification function, which is currently running on the Cosmos Hub since the v14 upgrade. We are close to wrapping up the Gaia upgrade to SDK v0.47, which is targeted for the v15 upgrade planned for January. We upgraded ICS to SDK v0.50. We enabled a first iteration of Model Based Testing (MBT) on Replicated Security. We finalized the design of Partial Set Security, which we plan to implement starting from next quarter. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"v13 upgrade","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"During October, the Cosmos Hub upgraded to ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/gaia/releases/tag/v13.0.0"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Gaia v13.0.0","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". This upgrade completely removes the Gravity DEX module and introduces a ","nodeType":"text"},{"data":{"uri":"https://cosmos.github.io/interchain-security/features/reward-distribution#whitelisting-reward-denoms"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"governance proposal to add consumer reward denominations","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", which was added to give the community more control over what denominations are accepted as ICS rewards. In addition this fixes a small security vulnerability – the previous mechanism to add consumer reward denominations through a transaction was opening a potential DOS attack vector on the Hub. This fix was part of the workflow with Amulet. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"v13.0.1 release ","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"We released ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/gaia/releases/tag/v13.0.1"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Gaia v13.0.1","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" with a fix for a security vulnerability found in the ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/ibc-apps/releases/tag/middleware%2Fpacket-forward-middleware%2Fv4.1.1"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"packet forward middleware module","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". We coordinated with the validator community to ensure that more than 2/3 of the voting power upgraded in order to avoid a potential network halt. This work was part of the workflow with Amulet.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"v14.1.0 release","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"We released ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/gaia/releases/tag/v14.1.0"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Gaia v14.1.0","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" that contains ICS with cryptographic equivocation verification. This release required a few iterations in order to fix some issues related to the ","nodeType":"text"},{"data":{"uri":"https://www.mintscan.io/cosmos/proposals/818"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"818 proposal","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". As a result, ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/gaia/releases/tag/v14.0.0"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Gaia v14.0.0","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" is deprecated and should never be used in production. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"v14 upgrade","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"During December, the Cosmos Hub upgraded to ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/gaia/releases/tag/v14.1.0"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Gaia v14.1.0","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". The upgrade went smoothly with around 12 minutes of downtime. This upgrade brings the ","nodeType":"text"},{"data":{"uri":"https://cosmos.github.io/interchain-security/features/slashing#equivocation-infractions"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"cryptographic equivocation verification","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" feature and deprecates the equivocation proposals. To enable automatic reporting of equivocation infractions on the consumer chains, we recommend all Hermes relayer operators to use ","nodeType":"text"},{"data":{"uri":"https://github.com/informalsystems/hermes/releases/tag/v1.7.3"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Hermes v1.7.3","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". Note that equivocation infractions can be reported also through the CLI. For more details, please refer to the ","nodeType":"text"},{"data":{"uri":"https://cosmos.github.io/interchain-security/features/slashing#report-equivocation-infractions-through-cli"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"ICS documentation","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Gaia SDK v0.47 upgrade","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"We are in the final stages of upgrading Gaia to ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/cosmos-sdk/releases/tag/v0.47.6"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"SDK v0.47","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". The plan is to release it in January as part of Gaia v15. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"\n","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The audit of SDK v0.47 performed by Oak Security was completed with the recommended fixes already added to the code. This was something we wanted to see before putting it on the Hub. Thanks to both Oak Security and Binary Builders for completing this audit.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"\n","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Other two prerequisites for the Gaia upgrade are the Liquid Staking Module (LSM) and the cryptographic equivocation verification feature. We upgraded both to SDK v0.47. For more details, see the sections below.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Upgrade the Liquid Staking Module to SDK v0.47","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"The Liquid Staking Module (LSM) was added to the Cosmos Hub as part of the v12 upgrade (as requested by the community in ","nodeType":"text"},{"data":{"uri":"https://www.mintscan.io/cosmos/proposals/790"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"proposal 790","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"). LSM facilitates users liquid staking their ATOMs by allowing them to be moved to liquid staking without an unbonding period. LSM was developed as a collaboration between Iqlusion and Stride, while the integration to Gaia was a collaboration between Iqlusion, Stride, Binary Builders, and Informal Systems. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"\n","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The integration to Gaia required moving the Hub on a special branch of the SDK (i.e., ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/cosmos-sdk/tree/v0.45.16-ics-lsm"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"v0.45.16-ics-lsm","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"). Note that the Hub has been using a special branch of SDK since the ICS release in the v9 upgrade. Having LSM on a special branch of SDK means though that LSM is not being automatically upgraded with mainline SDK. Thus, LSM requires continuous maintenance until it gets added to mainline SDK. For this reason, we upgraded LSM to SDK v0.47. Currently, the upgrade is in ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/cosmos-sdk/pull/18694"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"review","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" and we are working on Gaia integration. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Cryptographic equivocation verification ","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"We finished the design and implementation of the ","nodeType":"text"},{"data":{"uri":"https://cosmos.github.io/interchain-security/features/slashing#equivocation-infractions"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"cryptographic equivocation verification","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" feature. This is important because it allows the Hub to immediately slash validators who misbehave on consumer chains, instead of the previous governance-gated process, which required a vote to verify the slashing. For more details, please have a look at ","nodeType":"text"},{"data":{"uri":"https://cosmos.github.io/interchain-security/adrs/adr-005-cryptographic-equivocation-verification"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"ADR-005","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" and ","nodeType":"text"},{"data":{"uri":"https://cosmos.github.io/interchain-security/adrs/adr-013-equivocation-slashing"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"ADR-013","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". The cryptographic equivocation feature is a collaboration between the Cosmos Hub, Comet, and Hermes teams at Informal.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"\n","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"As a prerequisite for the Gaia upgrade to SDK v0.47, we ported the cryptographic equivocation verification feature to SDK v0.47. We plan to release it soon as part of ICS v3.3.0. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"ICS upgrade to SDK v0.50","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"We upgraded ICS to ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/cosmos-sdk/releases/tag/v0.50.1"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"SDK v0.50","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" and ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/ibc-go/releases/tag/v8.0.0"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"IBC v8.0.0","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". This upgrade enables consumer chains (like Neutron and Stride) to upgrade to the latest version of SDK. During the update process, we identified and ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/cosmos-sdk/pull/18486"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"fixed","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" a minor issue with the SDK state streaming. This work was done in collaboration with All in Bits. The upgrade is being tested and we plan to cut a final release soon.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"ICS Backward Compatibility Testing","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"We improved the documentation for ICS ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/interchain-security/blob/main/RELEASES.md#version-matrix"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"releases","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/interchain-security/blob/main/RELEASES.md#backwards-compatibility"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"backwards compatibility","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", and ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/interchain-security/blob/main/FEATURES.md"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"existing features","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", in order to facilitate integration (especially on consumer chains) and increase confidence in our releases. In addition, we are working on restructuring our ICS e2e testing infrastructure to enable backwards compatibility tests as part of our CI (for more details, see ","nodeType":"text"},{"data":{"uri":"https://cosmos.github.io/interchain-security/adrs/adr-011-improving-test-confidence"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"ADR-011","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"). Note that this will complement the testing work done by Hypha for every ICS release. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"\n","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"On this note, we already released ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/interchain-security/releases/tag/v3.2.0"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"ICS v3.2.0","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" with the consumer-side changes for Jail Throttling v2 (cf. ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/interchain-security/blob/release/v3.2.x/docs/docs/adrs/adr-008-throttle-retries.md"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"ADR 008","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"). We also plan to release soon ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"ICS v3.3.0 with the ","nodeType":"text"},{"data":{"uri":"https://cosmos.github.io/interchain-security/features/slashing#equivocation-infractions"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"cryptographic equivocation verification","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" feature (which will end up in Gaia v15) ","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"ICS v4.0.0 with the provider-side changes for Jail Throttling v2 (cf. ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/interchain-security/blob/release/v3.2.x/docs/docs/adrs/adr-008-throttle-retries.md"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"ADR 008","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":") – this release will be compatible with consumers >= v3.2.0","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"ICS v5.0.0 with SDK 0.50 ","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"CometMock v0.38","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"We upgraded CometMock to CometBFT v0.38, which contains ABCI++ and is compatible with SDK 0.50. This is a prerequisite for upgrading Replicated Security to SDK 0.50.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Enable MBT on Replicated Security","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"We enabled the first iteration of Model Based Testing (MBT) on Replicated Security. For the last year or so, we were using differential testing to increase the confidence of the Replicated Security implementation. In a nutshell, differential testing consists of a TypeScript reference implementation of Replicated Security that is used to model the protocol and generate traces (i.e., events) that can be provided to a driver in order to generate tests. The name “differential” comes from the fact that the states resulting from executing the reference implementation and the actual implementation were checked against each other. This approach enabled us to find very subtle bugs, especially during the development of Replicated Security v1. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"\n","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The issue is that the TypeScript reference implementation is very detailed. Consequently, it is very hard to maintain and since it lagged behind the actual implementation, we had to disable differential testing. Our solution was to create a ","nodeType":"text"},{"data":{"uri":"https://github.com/informalsystems/quint"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Quint","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" model of Replicated Security. ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/interchain-security/blob/main/tests/difference/core/quint_model/README.md"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"The model","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" is based on a high-level ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/ibc/pull/911"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"TLA+ specification of Replicated Security","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" and we believe it is much easier to maintain. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"\n","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We updated the driver and MBT is currently running in our CI.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Replicated Security as a read only protocol","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"Throughout the quarter, we looked into simplifying the Replicate Security protocol by removing one of the three message types – the VSCMaturedPackets. The idea came from a discussion we had with Jae Kwon a year ago. The benefits are twofold. First, it would simplify the protocol (and consequently the implementation), which would make it easier to iterate and bring improvements, such as Partial Set Security. Second, it would be a necessary step for making Replicated Security a read only protocol – the Cosmos Hub regularly publishes validator updates and consumer chains subscribe to these updates. This would remove the dependency between the liveness of undelegation operations on the Hub and the liveness of consumer chains. For example, it would avoid scenarios where a user has to wait more than 3 weeks for their unstaked ATOMs due to a consumer chain being down.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"\n","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Unfortunately, we believe that VSCMaturedPackets cannot be removed from the Replicated Security protocol without compromising the security of the system. This is due to the security model of IBC light clients. We documented our findings ","nodeType":"text"},{"data":{"uri":"https://docs.google.com/document/d/1LPx_Q8gV3Pmlytty3g126RcGv2NJN91H6n0ayicjnfg/edit"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"here","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" and we plan to post it on the Hub forum for more discussion. Any feedback is more than welcome. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Partial Set Security","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"Throughout the quarter, we worked on the design of Partial Set Security that enables consumer chains to consume only a portion of the security provided by the Cosmos Hub (and consequently, allows only a subset of Hub validators to run physical nodes for consumer chains). We started with a ","nodeType":"text"},{"data":{"uri":"https://forum.cosmos.network/t/chips-discussion-phase-partial-set-security/11775"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"discussion","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" on the Hub forum, as part of the ","nodeType":"text"},{"data":{"uri":"https://forum.cosmos.network/t/cosmos-hub-improvement-process-chips/11765"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Cosmos Hub Improvement Proposals (CHIPs) process","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". The discussion resulted in ","nodeType":"text"},{"data":{"uri":"https://informalsystems.notion.site/Partial-Set-Security-398ca9a1453740068be5c7964a4059bb"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"the refinement of the Partial Set Security design","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", which we plan to implement starting from next quarter. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Other CHIPs","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"In October, we introduced the concept of ","nodeType":"text"},{"data":{"uri":"https://forum.cosmos.network/t/cosmos-hub-improvement-process-chips/11765"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Cosmos Hub Improvement Proposals (CHIPs)","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". This consists of a framework that enables the Hub community to keep track of the progress of different Hub improvements. Since then, we started discussions on several CHIPs, such as ","nodeType":"text"},{"data":{"uri":"https://forum.cosmos.network/t/chips-discussion-phase-atomic-ibc-megablocks/11767"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Megablocks and Atomic IBC","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", ","nodeType":"text"},{"data":{"uri":"https://forum.cosmos.network/t/chips-discussion-phase-partial-set-security/11775"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Partial Set Security","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", ","nodeType":"text"},{"data":{"uri":"https://forum.cosmos.network/t/chips-discussion-phase-optimizing-ics-reward-distribution-with-per-chain-commission/11970"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Optimizing ICS reward distribution with per-chain commission","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", and ","nodeType":"text"},{"data":{"uri":"https://forum.cosmos.network/t/chips-discussion-phase-minimum-commission-as-a-function-of-voting-power/12445"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Minimum Commission as a Function of Voting Power","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". We encourage everyone in the Cosmos Hub community to participate and give us feedback. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"\n\n\n","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"\n\n\n","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"contentfulURL":"https://app.contentful.com/spaces/p79kctcd7ahy/entries/7kSJfxU2LdiMllcsjhuwha"},{"featureImage":"$4:props:posts:25:featureImage","date":"2023-12-15","title":"Reflecting on our CometBFT 2023 Journey: A Retrospective","slug":"reflecting-on-our-cometbft-2023-journey-a-retrospective","categories":["Engineering"],"authors":["CometBFT Team"],"keywords":"cometbft-retrospective, abci-2.0, vote-extensions, consensus-optimization, storage-improvements, bandwidth-optimization, tendermint-fork, blockchain-consensus, performance-tuning, cometbft-v1","excerpt":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Annual review of vote extensions, storage optimization, and v1 pre-release.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"\n","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"includeTableOfContents":true,"body":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"The year 2023 has been an unforgettable year for the CometBFT team, and as the year ends, we would like to reflect on the most important events that took place during this year. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"CometBFT debut","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"At the beginning of the year, we officially announced that Informal Systems would be responsible for ","nodeType":"text"},{"data":{"uri":"https://x.com/informalinc/status/1613580954383040512"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"maintaining a fork of Tendermint Core","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" and ","nodeType":"text"},{"data":{"uri":"https://informal.systems/blog/cosmos-meet-cometbft"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"launching CometBFT","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The team at Informal Systems assigned some of their most experienced engineers from Cosmos to work on this project. Although there were many unknowns and challenges, the team was eager and optimistic about being the project steward. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The Interchain Stack currently hosts almost 100 live blockchains with a combined market capitalization worth billions of dollars, all of which have widely embraced Tendermint consensus and CometBFT as their base layer. Despite the significant responsibility it entails, we are proud to have been chosen as stewards of CometBFT. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Our extensive contributions to the Cosmos Ecosystem have provided us with the knowledge and expertise to ensure that CometBFT continues to thrive under our care.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"First Official Release","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"In February, we announced the first official release, CometBFT ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/blob/v0.34.27/CHANGELOG.md#v03427"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"v0.34","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". Our primary objective was to make it as easy as possible for users to switch from Tendermint Core v0.34 by making it fully compatible with the Tendermint Core v0.34 release series.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"In order to ensure that CometBFT works as expected, we started running more extensive QA with each new major release, starting with v0.34. This allowed us to produce detailed ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/tree/main/docs/qa"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"QA results","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" for each major release, giving developers insight into how those releases perform in 200-node networks, how they perform relative to previous releases, and reducing chances of regression. We also changed our major release process to ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/blob/main/RELEASES.md#pre-releases"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"always include pre-releases","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" such that it is clear to our users as to when a new release has been through QA.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Building blocks of ABCI++ (ABCI 1.0)","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"In March, we achieved another significant milestone, a month after our previous one. We released CometBFT ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/blob/v0.37.0/CHANGELOG.md#v0370"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"v0.37","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", which included ABCI 1.0. This version introduced two new ABCI methods: PrepareProposal and ProcessProposal. With these new methods, we gave application developers more control over how blocks are built.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Full ABCI++ (ABCI 2.0)","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"During the third quarter of this year, we launched ABCI 2.0 - the full implementation of ABCI++. The latest release (v0.38) introduced new ABCI methods which enable ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"vote extensions","nodeType":"text"},{"data":{},"marks":[],"value":" - a powerful new feature that allows application developers to address use cases such as validator-based price oracles and threshold-encrypted transactions. These methods, ExtendVote and VerifyVoteExtension,allow the application to add arbitrary data to pre-commit votes. These vote extensions are available to the proposer(s) of the next block height.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Another significant change was the combination of the BeginBlock, DeliverTx, and EndBlock into a new method called FinalizeBlock. This release also included several other features, changes, bug fixes, and improvements.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"It marked the final release of ABCI++ - a significant evolution of ABCI. This project ","nodeType":"text"},{"data":{"uri":"https://github.com/tendermint/spec/pull/254"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"began as a vision","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" several years ago, is the culmination of many teams’ work, and we are proud to have finally pushed it over the finish line.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Beyond Releases: Highlighting Other Important Work","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"One of our significant accomplishments this year was the work carried out by our \"optimization squads\", with our primary goal being providing operators with ways to control, and ideally reduce, their costs. Since our team is not very big, but is too big for the whole team to work on a single task at a time, we’ve divided into two squads: one to work on bandwidth optimization and another squad to work on storage optimization. Allowing our core developers to concentrate on a particular aspect of the solution was very productive, which enabled us to make ","nodeType":"text"},{"data":{"uri":"https://informal.systems/blog/cometbft-engineering-update-q3-wrapped-up-and-q4-priorities"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"significant progress on these two fronts, especially in Q3","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", by releasing improvements and new features or conducting a series of experiments. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Some of the work here involved backwards-incompatible changes, and is therefore only available in the newest releases of CometBFT (such as the upcoming v1 release, with minor improvements in v0.34, v0.37 and v0.38).","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Another vital achievement to mention was our work in tackling security vulnerabilities. Ensuring ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/blob/main/SECURITY.md"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"security","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" is our top priority, and we were pleased to work with the team responsible for the Interchain Bug Bounty program, successfully addressing a few ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/security/advisories"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"low-severity vulnerabilities ","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"that arose this year.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The first CometBFT v1 pre-release","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"We are delighted to ","nodeType":"text"},{"data":{"uri":"https://informal.systems/blog/cometbft-v1-alpha-release"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"announce","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" the release of the first pre-release version of the highly anticipated v1 release line. This version comes with many exciting features, including significant improvements in bandwidth consumption, new ways of optimizing storage usage, API versioning, enabling greater execution performance through parallelization in the interaction between CometBFT and the application, and a series of refactoring enhancements that aim to improve our team's efficiency. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Teamwork Makes the Dream Work: Acknowledging Our Partners and Collaborators","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"We are deeply grateful for our users' and partners' unwavering support and invaluable feedback. Your contributions have also been pivotal in developing the Interchain Stack and CometBFT. We understand that our progress is only possible because of your trust and collaboration, and we are truly thankful for that.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We recognize that a resilient ecosystem is built on open communication and collective efforts. Your feedback has helped us to adapt and improve continuously, and we cannot thank you enough for your fantastic support and encouragement throughout this year. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Things to improve on a non-technical front: We want to forge closer collaborations with teams that are at the bleeding edge of CometBFT adoption, and which would therefore benefit from closer alignment. There is no magic formula for making this happen, it takes building trust through patience and deliberate, constructive communication.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"As we embark on a new year, we want to continue to work closely with you and strengthen our collaboration. We value your input and would be honored to receive your feedback on how we can continue to improve and grow together.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Looking Ahead: Our Plans for 2024","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"In the short term, our top priority is to finalize the release for v1, and we are working diligently towards that objective. We also have several other improvements in the pipeline, such as Proposer-Based Timestamps (PBTS), improved testing infrastructure, better documentation, a more modular CometBFT, and many other enhancements that will benefit our users as outlined in the ","nodeType":"text"},{"data":{"uri":"https://docs.google.com/document/d/1j_VnHsM0Hsi2so9gf2oLFKhy3wVa7csCa3lTjlMYCsI/edit#heading=h.aazbrhskhzvr"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Interchain Stack Roadmap 2024","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"As the year draws to a close, we look forward to planning for the next year with enthusiasm and optimism. We are committed to providing our users exceptional value and fulfilling our promises. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We are honored to be part of the Interchain and are deeply grateful for the opportunity to play a role in its success.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We extend our warmest wishes to all those involved.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"contentfulURL":"https://app.contentful.com/spaces/p79kctcd7ahy/entries/62mwMP7wQikYtwwtWInNhg"},{"featureImage":"$4:props:posts:50:featureImage","date":"2023-12-13","title":"IBC-rs V1 Release Preparation - Modular Architecture and Dependency Restructuring","slug":"paving-the-way-for-a-v1-release-of-ibc-rs","categories":["Engineering"],"authors":["Sean Chen"],"keywords":"ibc-rs-v1, rust-ibc, modular-architecture, cosmwasm-integration, selective-imports, ibc-modules, dependency-restructuring, blockchain-interoperability, ibc-development, rust-blockchain","excerpt":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"How ADR 008 restructuring enables selective imports and CosmWasm integration.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"includeTableOfContents":true,"introduction":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"The IBC team at Informal Systems comprises two sub-teams who work closely together: the Hermes team and the ibc-rs team. The Hermes team primarily supports relayer operators and those who work “off-chain”. The ibc-rs team, in contrast, primarily supports maintainers of “on-chain” applications who work to integrate IBC into their codebases, enabling those applications to communicate, transfer assets, and interface with other IBC-enabled chains.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"While we’ve published a few ","nodeType":"text"},{"data":{"uri":"https://informal.systems/blog/releasing-hermes-v1-6"},"content":[{"data":{},"marks":[],"value":"posts","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" on the goings-on of the Hermes relayer, the ibc-rs project has received much less time in the spotlight. However, with the release of ibc-rs v1 on the horizon (targeting the first half of 2024), it’s about time we remedy that.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"body":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"What is ibc-rs?","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"In essence, ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/ibc-rs"},"content":[{"data":{},"marks":[],"value":"ibc-rs","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" provides on-chain interfaces (all implemented in Rust) for chains to speak and grok the IBC protocol. The ibc-rs project is also sometimes colloquially referred to as the “modules”, which evokes modular pieces of logic that can be plugged into a blockchain to enable certain kinds of functionality. The ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/ibc/blob/main/spec/app/ics-020-fungible-token-transfer/README.md"},"content":[{"data":{},"marks":[],"value":"ICS-20 fungible token transfer","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"module is perhaps the most commonly-used example. Chains looking to utilize the IBC protocol’s token transfer capabilities to send tokens to and from other IBC-enabled chains can integrate ibc-rs’s ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/ibc-rs/blob/main/ibc-apps/ics20-transfer/src/lib.rs"},"content":[{"data":{},"marks":[],"value":"ICS-20 module","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" in order to achieve this.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"In addition to self-contained pieces of modular business logic like ICS-20, ibc-rs exports many of the core abstractions and primitives that make up the IBC protocol’s core implementation, such as client, connection, and channel abstractions. ibc-rs also makes available all of the foundational domain types and data structures upon which the higher-level abstractions are built. For use-cases that require extensive modifications to IBC, ibc-rs makes available the foundational IBC primitives, abstractions, and data structures to enable those use-cases. On the flip side, ibc-rs also exports ready-made IBC applications that chain developers can simply import and use out-of-the-box if they wish. In this way, ibc-rs allows chain developers to build upon any layer of the IBC stack.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Improving upon ibc-rs’s flexibility and modularity","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"In actuality, there were some wrinkles in ibc-rs’s ability to provide this flexibility in a frictionless and intuitive manner. Chief among these is the fact that the different abstraction layers in ibc-rs were often tangled together through many inter-dependencies, which meant that often a distinct layer of abstraction could not be imported on its own by a chain developer looking to use that layer. This meant that additional dependencies, which were often not relevant to the user, had to be pulled in in order to utilize a certain abstraction layer.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"In light of this, ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/ibc-rs/blob/main/docs/architecture/adr-008-restructure-ibc-crate.md"},"content":[{"data":{},"marks":[],"value":"ADR 008","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" was drafted in order to outline a plan for restructuring the ibc-rs repository. The overarching aim of the restructure is improve the overall usability of ibc-rs by reducing inter-dependence amongst various components and layers within the codebase. This in turn will mitigate potential dependency-related conflicts that might arise in the context of monolithic libraries.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"This restructuring initiative also opens up additional use-cases that were previously unrealistic due to ibc-rs’s more tightly-coupled structure:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"},{"type":"italic"}],"value":"Selective module import","nodeType":"text"},{"data":{},"marks":[],"value":": Users can now import only the necessary components and/or modules that they need for their particular use-case(s). Previously, it was impractical if a user only wanted to import the ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"ics07-tendermint","nodeType":"text"},{"data":{},"marks":[],"value":" module; doing so required importing other modules that the ics07 module itself depended upon.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"},{"type":"italic"}],"value":"Selective types import","nodeType":"text"},{"data":{},"marks":[],"value":": Users can now opt to only import the types from a particular module, without having to also pull in the validation and execution logic. Previously, off-chain consumers of ibc-rs, such as relayers, were unable to only import the domain types that they needed: they would need to also pull in the modules logic that ibc-rs exports, despite the fact that none of this logic was relevant to them. In the case of the Hermes relayer, specifically, this contributed partly to the Hermes team maintaining their own IBC types. With ibc-rs’s new structure, Hermes will be able to depend instead on the types that ibc-rs exports, thus reducing code duplication across the ecosystem.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"},{"type":"italic"}],"value":"Easier development of CosmWasm contracts","nodeType":"text"},{"data":{},"marks":[],"value":": Informal Systems has been working on developing a CosmWasm-based Tendermint light client. This is also happening in the context of the Sovereign IBC integration work. It is another example of a use-case that ibc-rs was not great at catering for, as it necessitated importing the entire ibc-rs codebase and its dependencies. With ibc-rs’s new structure, the light client can now be implemented by pulling in only the relevant dependencies, namely the ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"ics07-tendermint","nodeType":"text"},{"data":{},"marks":[],"value":" and the ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"ibc-core-client","nodeType":"text"},{"data":{},"marks":[],"value":" crates. Additionally, ibc-rs also now supports ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"no-std","nodeType":"text"},{"data":{},"marks":[],"value":" and ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"no-float","nodeType":"text"},{"data":{},"marks":[],"value":" compilation targets, a prerequisite for users working on CosmWasm smart contracts.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"The new structure of ibc-rs","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"The top level of the restructured ibc-rs crate looks like this:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"6czhTRZPKoV9eI937dWHy5","type":"Entry","createdAt":"2023-11-27T17:54:59.989Z","updatedAt":"2024-01-12T01:12:14.059Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":12,"revision":4,"contentType":{"sys":{"type":"Link","linkType":"ContentType","id":"codeSnippet"}},"locale":"en-US"},"fields":{"language":"plaintext","code":"// Every validator set on any consumer chain MUST either be or have been\n// a validator set on the provider chain.\nval ValidatorSetHasExistedInv =\n runningConsumers.forall(chain =>\n getVotingPowerHistory(currentState, chain).toSet().forall(\n validatorSet => \n providerVotingPowerHistory.toSet().contains(validatorSet)\n )\n )"}}},"content":[],"nodeType":"embedded-entry-block"},{"data":{},"content":[{"data":{},"marks":[],"value":"With this new structure, the top-level ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"ibc","nodeType":"text"},{"data":{},"marks":[],"value":" module simply re-exports all of the other top-level modules. This serves to minimize downstream breaking changes on the end user, by allowing them to continue to use ibc-rs’s sub-crates while requiring minimal ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"use","nodeType":"text"},{"data":{},"marks":[],"value":" statement changes.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Each of the sub-crates contained in the ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"ibc-core","nodeType":"text"},{"data":{},"marks":[],"value":", ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"ibc-clients","nodeType":"text"},{"data":{},"marks":[],"value":", and ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"ibc-apps","nodeType":"text"},{"data":{},"marks":[],"value":" export a separate ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"types","nodeType":"text"},{"data":{},"marks":[],"value":" sub-crate, which only contains the types that that particular crate makes use of. This makes it straightforward for a downstream user of ibc-rs to know which sub-crate(s) they need to import in order to pull in the domain types that they need. Additionally, downstream users will no longer need to depend on ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"ibc-proto","nodeType":"text"},{"data":{},"marks":[],"value":" since ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"ibc-rs","nodeType":"text"},{"data":{},"marks":[],"value":" now re-exports all of the necessary proto dependencies from the relevant crates. More specifically, pulling in any ibc-rs crate will automatically pull all of the necessary proto types that are needed such that it is no longer necessary to depend on ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"ibc-proto","nodeType":"text"},{"data":{},"marks":[],"value":", at least not solely for the sake of ibc-rs.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"ibc-core","nodeType":"text"},{"data":{},"marks":[],"value":" crate exports the implementations of the core IBC layers. ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"ibc-clients","nodeType":"text"},{"data":{},"marks":[],"value":" exports the different light client implementations (of which currently only Tendermint exists in the mainline repository, though a CosmWasm light client is in the works), and ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"ibc-apps","nodeType":"text"},{"data":{},"marks":[],"value":" exports the implementation of IBC apps (of which currently only the ICS-20 token transfer app exists). The ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"ibc-primitives","nodeType":"text"},{"data":{},"marks":[],"value":" crate exports commonly-used fundamental types, such as those that belong to the ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"proto","nodeType":"text"},{"data":{},"marks":[],"value":" and ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"alloc","nodeType":"text"},{"data":{},"marks":[],"value":" crates. ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"ibc-testkit","nodeType":"text"},{"data":{},"marks":[],"value":" exports the types and utilities needed to enable rigorous integration tests for ibc-rs, while also aiding host chains to address a broad spectrum of testing scenarios during ibc-rs integration. The ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"ibc-derive","nodeType":"text"},{"data":{},"marks":[],"value":" crate provides a set of procedural macros for deriving IBC-related traits, which serve to reduce the amount of boilerplate code required to implement them. The ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"ibc-query","nodeType":"text"},{"data":{},"marks":[],"value":" crate provides utility traits, query methods, and gRPC query services for each of the IBC core client, connection, and channel layers. Lastly, the ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"ibc-data-types","nodeType":"text"},{"data":{},"marks":[],"value":" crate serves a similar purpose as the top-level ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"ibc","nodeType":"text"},{"data":{},"marks":[],"value":" crate: it re-exports the data structures from all the various ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"types","nodeType":"text"},{"data":{},"marks":[],"value":" crates that each layer exports.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Conclusion","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"Now that this proposed restructuring effort has successfully gone through, ibc-rs is in a much better spot in terms of usability; this was an important and necessary effort in getting ready for ibc-rs’s upcoming v1 launch!","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"If you’re interested in following along with ibc-rs’s development, follow the project’s ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/ibc-rs"},"content":[{"data":{},"marks":[],"value":"repository","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" and consider joining the bi-weekly IBC Core coordination calls, where we update the community on the goings-on of the project. If you’re interested in integrating IBC into your application, please reach out! We’re looking to continue generalizing ibc-rs by working with teams to fit individual use-cases and ensure that ibc-rs is able to provide the smoothest IBC adoption experience possible.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"contentfulURL":"https://app.contentful.com/spaces/p79kctcd7ahy/entries/2KOzp9oZnHEUtFmv07DRlH"},{"featureImage":"$4:props:posts:25:featureImage","date":"2023-12-05","title":"CometBFT v1 Alpha Release - Bandwidth Optimization and Data Companion API","slug":"cometbft-v1-alpha-release","categories":["Engineering"],"authors":["Andy Nogueira"],"keywords":"\ncometbft-v1-alpha, bandwidth-optimization, data-companion-api, protobuf-versioning, mempool-improvements, consensus-engine, blockchain-performance, api-stability, experimental-features, interchain-stack","excerpt":{"nodeType":"document","data":{},"content":[{"nodeType":"paragraph","data":{},"content":[{"nodeType":"text","value":"Major milestone featuring protobuf versioning and mempool improvements.","marks":[],"data":{}}]}]},"includeTableOfContents":true,"body":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"A Milestone for the Interchain","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"We are thrilled to announce that we have just released the highly anticipated first v1 Alpha version (","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/releases/tag/v1.0.0-alpha.1"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"v1.0.0-alpha.1","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":") of CometBFT. This release marks a milestone in the history of CometBFT and the Interchain Stack, and we are excited to share the details of the new features and changes included in this release. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"This version is now available for integration and we are confident it will be valuable for all classes of users. The primary objective of releasing an alpha version is to allow the community to test it out and provide feedback. We value your input and look forward to hearing your thoughts on the new version.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Bumping the version to a major release (v1)","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"As of v1, CometBFT will use an approach to versioning that is described in our ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/blob/v1.0.0-alpha.1/README.md#versioning"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Releases document","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"This alpha-series release is subject to Go API-breaking changes until a release candidate is finalized. Refer to the ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/blob/v1.0.0-alpha.1/RELEASES.md#pre-releases"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"pre-releases section","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" of the releases document to understand stability guarantees on pre-releases.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Important changes in v1","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"The v1 Alpha release is a significant release of CometBFT that includes several substantial changes that aim to reduce bandwidth consumption, enable modularity, improve integrators' experience and increase the velocity of the CometBFT development team.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Bandwidth Consumption","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"Validators now proactively communicate the block parts they already have, so others do not resend them. This reduces network amplification and bandwidth consumption. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"An experimental feature in the mempool allows limiting the number of peers to which transactions are forwarded. This allows operators to optimize gossip-related bandwidth consumption further. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"An opt-in nop mempool is available, which allows application developers to turn off all mempool-related functionality in CometBFT. This enables them to build their transaction dissemination mechanism, such as a standalone transaction mempool-like process that can be scaled independently of the consensus engine/application.This requires application developers to implement their gossip/networking mechanisms. For more details, see ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/blob/v1.0.0-alpha.1/docs/architecture/adr-111-nop-mempool.md"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"ADR 111","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Data Companion","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"The v1 Alpha marks the first official release of the ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/blob/v1.0.0-alpha.1/docs/architecture/adr-101-data-companion-pull-api.md"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Data Companion API","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". This new set of gRPC APIs enables external applications to control the data pruning process of the node. With these APIs, operators and integrators can retrieve data from the node, such as Blocks and Block Results, and transfer it to an external data source. This new approach allows for custom data indexing and reduces node storage through the pruning APIs. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Protobuf versioning","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"We have put in a lot of effort to version both the Protobuf definitions and the RPC. By doing so, we aim to ensure API stability while still allowing significant changes to be rolled out in non-breaking releases of CometBFT. You can refer to ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/blob/v1.0.0-alpha.1/docs/architecture/adr-103-proto-versioning.md"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"ADR 103","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" and ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/blob/v1.0.0-alpha.1/docs/architecture/adr-107-betaize-proto-versions.md"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"ADR 107","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" for more information. We added some information about packages and proto definitions in the ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/tree/v1.0.0-alpha.1/proto#which-cometbft-release-does-each-package-belong-to"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"proto document","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" and we plan in the near future to provide additional information about upgrade paths.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Increasing velocity","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"To increase velocity, the team has moved many publicly accessible Go packages into the `internal` directory. This will allow CometBFT core developers to roll out substantial changes in the future without worrying about causing breakages in users' codebases. The previous versions had a massive Go API surface area, which significantly hampered the team's ability to roll out impactful new changes to users. (Previously, such changes required a new breaking release, which currently takes 6 to 12 months to reach production use for many users.) For more details, please refer to ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/blob/v1.0.0-alpha.1/docs/architecture/adr-109-reduce-go-api-surface.md"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"ADR 109","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"And many more","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"This release includes numerous changes that cannot be listed in a single blog post. Please refer to the ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/blob/v1.0.0-alpha.1/CHANGELOG.md"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Changelog","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" document for a detailed list of ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/blob/v1.0.0-alpha.1/CHANGELOG.md#breaking-changes"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"breaking changes","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/blob/v1.0.0-alpha.1/CHANGELOG.md#bug-fixes"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"bugs","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/blob/v1.0.0-alpha.1/CHANGELOG.md#features"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"features","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", and ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/blob/v1.0.0-alpha.1/CHANGELOG.md#improvements"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"improvements","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Outro","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"We would like to express our gratitude to our wonderful community and partners for their valuable feedback, which was instrumental in driving this effort and achieving this milestone. Thank you for your support and collaboration!","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"If you have any questions or want to discuss anything related to CometBFT, feel free to connect with our team on","nodeType":"text"},{"data":{"uri":"https://discord.gg/cosmosnetwork"},"content":[{"data":{},"marks":[],"value":" ","nodeType":"text"},{"data":{},"marks":[{"type":"underline"}],"value":"Discord ","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" or","nodeType":"text"},{"data":{"uri":"https://t.me/CometBFT"},"content":[{"data":{},"marks":[],"value":" ","nodeType":"text"},{"data":{},"marks":[{"type":"underline"}],"value":"Telegram ","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". We are always ready to assist you and provide you with the necessary information. Don't hesitate to reach out and keep the conversation going!","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Stay updated: Follow @cometbft on","nodeType":"text"},{"data":{"uri":"https://twitter.com/cometbft"},"content":[{"data":{},"marks":[],"value":" ","nodeType":"text"},{"data":{},"marks":[{"type":"underline"}],"value":"Twitter","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"CometBFT is currently being stewarded by","nodeType":"text"},{"data":{"uri":"http://informal.systems/"},"content":[{"data":{},"marks":[],"value":" ","nodeType":"text"},{"data":{},"marks":[{"type":"underline"}],"value":"Informal Systems","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" with support from many contributors across the interchain stack, including the Cosmos SDK and IBC teams.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"contentfulURL":"https://app.contentful.com/spaces/p79kctcd7ahy/entries/36F3pHypqnazYShY9LE1JI"},{"featureImage":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"40G2OUOmtfZN5i2sKdVUtv","type":"Asset","createdAt":"2024-08-14T03:25:47.584Z","updatedAt":"2024-08-14T03:25:47.584Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":3,"revision":1,"locale":"en-US"},"fields":{"title":"image","description":"","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/40G2OUOmtfZN5i2sKdVUtv/665a26cbda133f3a3b16bee743b79c8a/image.avif","details":{"size":118636,"image":{"width":2048,"height":1358}},"fileName":"image.avif","contentType":"image/avif"}}},"date":"2023-11-28","title":"An Introduction to MTCS","slug":"paolos-post","categories":["Cycles"],"authors":["Paolo Dini"],"keywords":"mtcs-algorithm, cycles-platform, debt-clearing, trade-credit, multilateral-clearing, payment-networks, liquidity-optimization, b2b-payments, obligation-networks, financial-algorithms","excerpt":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"How Multilateral Trade Credit Set-off reduces liquidity needs in B2B obligation networks.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"includeTableOfContents":false,"body":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"In this blog I explain the algorithm at the core of Cycles, Multilateral Trade Credit Set-off or MTCS [1], in intuitive terms. MTCS is about multilateral clearing in B2B obligation networks, i.e. networks of invoices or debts. It turns out that a significant portion of the total debt (the sum of all the invoice amounts in the network) can be cleared without any money.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Fig. 1 shows a simple example of three firms, whose mutual obligations form a closed cycle. It turns out that these debts can be cleared using a liquidity amount equal to only 1/2 of the total debt. As shown on the right of the figure, in fact, by subtracting the smallest amount from all three obligations the net position of each company does not change. In other words, the amount that each company has to pay out or that it is receiving is the same before and after the clearing step.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"4tU4Vxp54rhyjMJ5QCPn9Q","type":"Asset","createdAt":"2023-11-28T21:02:36.388Z","updatedAt":"2023-11-28T21:02:36.388Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":6,"revision":1,"locale":"en-US"},"fields":{"title":"Paolo's Blog Post Figure 1","description":"","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/4tU4Vxp54rhyjMJ5QCPn9Q/ef5702a6168c985db51389f2e2e49572/setoff.jpg","details":{"size":272907,"image":{"width":1983,"height":870}},"fileName":"setoff.jpg","contentType":"image/jpeg"}}}},"content":[],"nodeType":"embedded-asset-block"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Figure 1: Example obligation network composed of three firms, showing the partial discharge of the obligations by set-off.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The MTCS algorithm was originally executed by merchant bankers manually at the payment fairs in the Renaissance and late Middle Ages [2][3][4][5]. As the merchant bankers became proper banks, they continued the practice among themselves, to this day, but stopped supporting external networks of companies. With the rise of computing, MTCS algorithms began to emerge in the payment system of Yugoslavia. An early reference to this system is [6], which set the basic approach. Slovenia, roughly since its independence, operated an MTCS system at the national scale [1]. Some version of obligation-clearing is being used also in Romania [7] and Bosnia-Herzegovina [8]. Other work on an MTCS-like algorithm is discussed in [9]. The mathematics of our approach is described in [10]. Here we provide a short intuitive summary.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"$28","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The minimum-cost, maximum-flow algorithm from graph theory [13] that MTCS uses decomposes a given obligation network into two sub-networks: an acyclic component and the cyclic structure. To ensure that the cyclic structure is the largest possible, the acyclic component is defined as the shortest-path acyclic flow that carries the least amount of liquidity needed to settle all the debts from the debtor firms to the creditor firms, i.e. the NID. Since by construction such a flow settles all the debts, the remaining component has no effect on the net positions. Therefore, it must be purely cyclic: it is the cyclic structure and represents the largest possible liquidity savings. 'Maximum flow' in the algorithm’s name refers to the requirement of the acyclic flow to clear all the debts, i.e. it must equal at least the NID; but it can't be greater because we want to use as little liquidity as possible.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"$29","nodeType":"text"}],"nodeType":"paragraph"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"3CwjPj4efavhD8GUWtKK2t","type":"Asset","createdAt":"2023-11-28T21:03:14.709Z","updatedAt":"2023-11-28T21:03:14.709Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":4,"revision":1,"locale":"en-US"},"fields":{"title":"Paolo's Blog Post Figure 2","description":"","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/3CwjPj4efavhD8GUWtKK2t/aff0cc28262003f95de963e4ed4ade29/mcf_viz.jpg","details":{"size":1100791,"image":{"width":2758,"height":1829}},"fileName":"mcf_viz.jpg","contentType":"image/jpeg"}}}},"content":[],"nodeType":"embedded-asset-block"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Figure 2: The red nodes (net debtors) draw from the fictitious source, and the blue nodes (net creditors) deposit to the fictitious source","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"In the very simplified example shown in Fig. 2, the debt that can be cleared without liquidity corresponds topologically to the three cycles shown with dashed green arrows. The weight of each edge belonging to the cyclic structure constitutes the set-off notice, or decrease in obligation amount, that needs to be sent to the two companies defining that edge. This is the amount of liquidity saved or cleared, i.e. which does not have to be paid by the debtor.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Notably, the optimal solution to this minimum-cost maximum-flow problem is not unique. There are in general many optimal paths satisfying the min-cost max-flow problem, thus requiring some means of discerning between them. There are also distinct ways of defining the optimization problem itself (total amount of debt, total number of participants that benefit, etc.). Since we are talking about discharging debts, the solution has real economic consequences, and must thus be treated appropriately. While randomness could be used to pick between solutions, it would be better to enable other solutions to be expressed, for instance through direct governance, or some kind of preference system (e.g. a community could bias the algorithm towards non-profits to benefit from more set-off).","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"[1] ","nodeType":"text"},{"data":{},"marks":[],"value":"Fleischman, Tomasz and Dini, Paolo and Littera, Giuseppe (2020). ","nodeType":"text"},{"data":{"uri":"https://www.mdpi.com/1911-8074/13/12/295"},"content":[{"data":{},"marks":[],"value":"Liquidity-Saving through Obligation-Clearing and Mutual Credit: An Effective Monetary Innovation for SMEs in Times of Crisis","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"Journal of Risk and Financial Management","nodeType":"text"},{"data":{},"marks":[],"value":", ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"13","nodeType":"text"},{"data":{},"marks":[],"value":"(12), 295.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"[2] ","nodeType":"text"},{"data":{},"marks":[],"value":"Amato, Massimo and Fantacci, Luca (2012). ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"The End of Finance","nodeType":"text"},{"data":{},"marks":[],"value":". Cambridge: Polity.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"[3] Boerner, Lars and Hatfield, John William (2017). The Design of Debt-Clearing Markets: Clearinghouse Mechanisms in Preindustrial Europe. ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"Journal of Political Economy","nodeType":"text"},{"data":{},"marks":[],"value":", 125(6): 1991-2037.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"[4] Boyer-Xambeu, Marie-Therese and Deleplace, Ghislain and Gillard, Lucien (1994). ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"Private Money & Public Currencies: The 16th Century Challenge","nodeType":"text"},{"data":{},"marks":[],"value":". London: Routledge.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"[5] Poitras, Geoffrey (2009). ","nodeType":"text"},{"data":{"uri":"https://www.cairn.info/revue-histoire-des-sciences-humaines-2009-1-page-11.htm"},"content":[{"data":{},"marks":[],"value":"From Antwerp to Chicago: the History of Exchange Traded Derivative Security Contracts","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"Revue d'Histoire des Sciences Humaines","nodeType":"text"},{"data":{},"marks":[],"value":", 20(1): 11-50.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"[6] ","nodeType":"text"},{"data":{},"marks":[],"value":"Simic, Slobodan and Milanovic, Vladan (1992). ","nodeType":"text"},{"data":{"uri":"http://pefmath2.etf.bg.ac.rs/files/112/787.pdf"},"content":[{"data":{},"marks":[],"value":"Some Remarks on the Problem of Multilateral Compensation","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"Publikacije Elektrotehnickog fakulteta. Serija Matematika","nodeType":"text"},{"data":{},"marks":[],"value":", 22-33.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"[7] Gavrila, Lucian-Ionut and Popa, Alexandru (2021). ","nodeType":"text"},{"data":{"uri":"https://arxiv.org/pdf/2012.05564.pdf"},"content":[{"data":{},"marks":[],"value":"A novel algorithm for clearing financial obligations between companies","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":": An application within the Romanian Ministry of economy. ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"Algorithmic Finance","nodeType":"text"},{"data":{},"marks":[],"value":", 9(1-2): 49-60.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"[8] ","nodeType":"text"},{"data":{},"marks":[],"value":"Bozic, Milan and Zrnc, Jurica (2022). ","nodeType":"text"},{"data":{"uri":"https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3924908"},"content":[{"data":{},"marks":[],"value":"The Trade Credit Clearinghouse: Liquidity and Coordination","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"SSRN 3924908","nodeType":"text"},{"data":{},"marks":[],"value":", 1-77.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"[9] ","nodeType":"text"},{"data":{},"marks":[],"value":"Gazda, Vladimir and Horvath, Denis and Resovsky, Marcel (2015). A","nodeType":"text"},{"data":{"uri":"http://real-j.mtak.hu/21031/3/APH_2015_12_03_.pdf"},"content":[{"data":{},"marks":[],"value":"n application of graph theory in the process of mutual debt compensation","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"Acta Polytechnica Hungarica","nodeType":"text"},{"data":{},"marks":[],"value":", 12(3): 7-24.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"[10] ","nodeType":"text"},{"data":{},"marks":[],"value":"Fleischman, Tomasz and Dini, Paolo (2021). ","nodeType":"text"},{"data":{"uri":"https://www.mdpi.com/1911-8074/14/9/452"},"content":[{"data":{},"marks":[],"value":"Mathematical Foundations for Balancing the Payment System in the Trade Credit Market","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"Journal of Risk and Financial Management","nodeType":"text"},{"data":{},"marks":[],"value":", ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"14","nodeType":"text"},{"data":{},"marks":[],"value":"(9), 452.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"[11] The weight of each edge corresponds to the component \$b_i\$ of the net position vector \$\\mathbf{b}\$ in [10].","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"[12] To be sure, there can also be firms whose debts exactly balance the credits. Such firms would have a zero net position.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"[13] ","nodeType":"text"},{"data":{},"marks":[],"value":"Kiraly, Zoltan and Kovacs, Peter (2012). ","nodeType":"text"},{"data":{"uri":"https://arxiv.org/pdf/1207.6381.pdf"},"content":[{"data":{},"marks":[],"value":"Efficient implementations of minimum-cost flow algorithms","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"Acta Univ. Sapientiae, Informatica","nodeType":"text"},{"data":{},"marks":[],"value":", 4(1): 67–118.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"scripts":["MathJAX for LaTeX support"],"contentfulURL":"https://app.contentful.com/spaces/p79kctcd7ahy/entries/2LadqhlSXHH2uJQouXFwxW"},{"featureImage":"$4:props:posts:25:featureImage","date":"2023-11-14","title":"CometBFT v1 Alpha Development and October 2023 Engineering Progress","slug":"cometbft-engineering-update-october-2023","categories":["Engineering"],"authors":["Andy Nogueira"],"keywords":"cometbft-october, v1-alpha-development, bandwidth-optimization, experimental-releases, abci-performance, mempool-gossip, consensus-improvements, protobuf-api, engineering-updates, performance-optimization","excerpt":{"nodeType":"document","data":{},"content":[{"nodeType":"paragraph","data":{},"content":[{"nodeType":"text","value":"Monthly update covering bandwidth optimization and experimental release strategy.","marks":[],"data":{}}]}]},"includeTableOfContents":true,"introduction":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Welcome to the October update from the CometBFT team at Informal Systems. In this update, we'll be sharing the latest developments and progress made by our team. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"During October, our team focused on completing tasks required for the upcoming CometBFT v1 Alpha release. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We also continued our efforts to optimize bandwidth and prepared experimental releases. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Additionally, we added new features that allow application developers to improve the application performance by increasing parallelism.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"body":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"CometBFT v1","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"We have been making progress on the v1 alpha release. We’ve been working on renaming and versioning the Protobuf API and have merged some ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/pulls?q=is%3Apr+is%3Aclosed+label%3Aprotobuf+merged%3A2023-10-01..2023-10-31"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"related PRs","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"To enhance the experience of integrators, we are ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/pull/1412"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"versioning the RPC APIs","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We have ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/issues/1484"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"reduced the surface area of the Go API","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", which is available on a feature branch and may be included in v1. Any input from applications developers using CometBFT as a library would be appreciated.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"If you want to know about all the features planned for v1, please refer to this ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/issues/578"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"issue","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Bandwidth optimization","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"The development team ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/pull/1558"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"initiated a new strategy","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" aimed at reducing the mempool transaction gossip bandwidth consumption. The approach involves limiting the number of connections used to gossip transactions, thereby increasing efficiency. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"This promising approach is expected to optimize the transmission of transactions and reduce overall network congestion. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Experimental Releases","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"Starting from the v0.37 and v0.38 release lines, experimental releases will be made available. These releases will include advanced features from v1 that are more prone to risk. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"This means that users who are willing to take higher risks will be able to access new improvements earlier than waiting for an upgrade to v1.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Work on v0.38.x has been completed for ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/issues/1419"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"ADR 101","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[{"type":"bold"}],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Boost application performance with new ABCI clients","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"In Tendermint Core/CometBFT, there has been an ongoing issue where queries could slow down the system's operation. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Unfortunately, operators had no means to address this problem, such as increasing the number of available CPU cores, because the consensus engine's locking mechanism prevented them from doing so when interacting with the application. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"In October, a ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/pull/1141"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"solution was merged","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" into the main branch that targets CometBFT v1. However, it's still uncertain if this functionality will be backported for existing users. We are looking for input whether there is value in backporting this into v0.38.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Team Retreat","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"At the conclusion of the month, the team had the opportunity to participate in an in-person team retreat held in Montreal, Canada.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We were able to discuss our goals, brainstorm ideas and collaborate on various projects that will help us achieve our objectives. In particular, we iterated on our team processes and built shared context about 2024 plans among everyone in the team.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Despite the busy schedule, we also had time to enjoy the beautiful scenery, delicious food and vibrant culture of Montreal.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Outro","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"Thank you for taking the time to stay up-to-date with our work","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"If you have any questions or want to discuss anything related to CometBFT, feel free to connect with our team on ","nodeType":"text"},{"data":{"uri":"https://discord.gg/cosmosnetwork"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Discord","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" or ","nodeType":"text"},{"data":{"uri":"https://t.me/CometBFT"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Telegram","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". We are always ready to assist you and provide you with the necessary information. Don't hesitate to reach out and keep the conversation going!","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Stay updated: Follow @cometbft on ","nodeType":"text"},{"data":{"uri":"https://twitter.com/cometbft"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Twitter","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"CometBFT is currently being stewarded by ","nodeType":"text"},{"data":{"uri":"http://informal.systems/"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Informal Systems","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" with support from many contributors across the interchain stack, including the Cosmos SDK and IBC teams.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"contentfulURL":"https://app.contentful.com/spaces/p79kctcd7ahy/entries/2EeCjljMu1TPsXSspThukh"},{"featureImage":"$4:props:posts:29:featureImage","date":"2023-10-31","title":"FAQ Informal Hypha Proposal 839","slug":"faq-informal-hypha-proposal-839","categories":["Engineering"],"authors":["Jehan (Informal) & Lexa (Hypha)"],"keywords":"osmos-hub-proposal-839, community-funding, governance-proposal, cosmos-development, informal-systems, hypha-coop, cosmos-hub-governance, community-pool, development-funding, decentralized-governance","excerpt":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"FAQ on the Informal and Hypha Cosmos Hub Funding Proposal 839.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"includeTableOfContents":true,"introduction":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Some frequently asked questions about the recent Informal Systems and Hypha Coop funding proposal for the Cosmos Hub.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Links:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"\n- ","nodeType":"text"},{"data":{"uri":"https://forum.cosmos.network/t/last-call-oct-26-fund-2024-hub-development-by-informal-systems-and-hypha-worker-co-op/11597/"},"content":[{"data":{},"marks":[],"value":"Forum post","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"- ","nodeType":"text"},{"data":{"uri":"https://www.mintscan.io/cosmos/proposals/839"},"content":[{"data":{},"marks":[],"value":"On chain proposal","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"body":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Summary","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"What’s the total ask?","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"The requested amount is for $5.7M + 100k in ATOM for Informal and Hypha to staff the core development of the Cosmos Hub. \n","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The budget that Informal and Hypha has proposed is based on the teams’ experience helping to build and maintain the Hub, and is a realistic estimate of what is required to adequately serve the customers of the Cosmos Hub, maintain smooth operations of the Hub, and build ICS momentum. It is a continuation of their work in 2023.\n","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Who is the funding for?","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"The funding is for the Hub teams at Informal and Hypha. Informal and Hypha are larger entities that do other work, but this funding is only for their Hub teams. The Hub teams at Informal and Hypha have taken it upon themselves, as part of an effort to become more independent, to pursue this funding directly from the Cosmos Hub, in order to establish a better direct relationship between their teams and the Cosmos Hub.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Of course, these Hub teams are supported and enabled by their parent companies with additional functions like legal, HR, operations, marketing, etc, as well as their companies’ technical expertise in related areas. It would be difficult to recruit the same caliber of teams for the Hub without these resources and supports. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Finances","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"$$5.7M is only 800k ATOM. Why is the proposal for 1.17M ATOM?","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"The proposal includes the $5.7M budget, plus a 25% buffer to hedge the risk of a drop in ATOM price during the voting period, plus a 100k ATOM potential bonus. Here’s the math, calculated at a $7 ATOM price (the price at the time the proposal was published):","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"$$5.7M USD = 814,285.71 ATOM","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"25% buffer on $5.7M = 1,017,857.14 ATOM","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"100k ATOM bonus = 1,117,857.14 ATOM","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"Upon passing, $4M of ATOM (i.e., 70% of $5.7M) will be converted to USDC immediately and held in vesting accounts, in order to cover most of the dollar denominated costs of the team. The remaining $1.7M of the budget (30% of $5.7M) plus the 100k ATOM bonus will be held in ATOM in vesting accounts, ensuring the teams remain aligned with and incentivized by ATOM. Regardless of ATOM price at the time of liquidation, and excluding the 100k ATOM, the dollar value of the total budget sent to the vesting accounts is not to exceed $5.7M. ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"Any remaining ATOM will be immediately returned to the community pool.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Why $5.7M + 100k ATOM?","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"The bulk of the funding must be denominated in dollars to cover salaries, taxes, overhead, etc. This enables a team size of 15-20 people, which roughly corresponds to the current team. This team is enough to cover necessary improvements and R&D for Interchain Security, as well as ongoing maintenance for the Hub software and testnets. Any unused budget will be returned to the community pool. \n","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The additional 100k ATOM are intended as performance bonuses, subject to decisions by the oversight committee. Bonuses are standard practice in high performance projects. This bonus is denominated in ATOM, to improve incentive alignment between the core dev teams and the Hub. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Does the headcount and budget really equate to $400k/head?","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"No. As detailed in the proposal, the cost is more like ~$325k/year, which is a standard rate for a professional software engineering contract. It is higher than you would expect for a direct employee because it’s not an employee’s salary, it’s a contractor’s rate. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"It’s not possible for the Hub to employ people directly. The Hub has to engage companies. Those companies pay their employees $150-$250k/year, on top of which those companies have to pay taxes and social security (sometimes as high as 40%), as well as their own overhead. Finally, those companies face opportunity cost, and should earn a market rate profit. So the total cost reflects more than just the employee’s take home salary.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The rates quoted take all of this into account. They correspond to market rates for software contracts. Rates for software engineers commonly range from $150-$250/hr. At 40 hours a week, 47 weeks a year (accommodating vacation and holidays), and with a discount to account for it being a stable, longer term contract, we get annual rates of ~$225k-$375k/year. The rates of this proposal fall well within that, and correspond to rates the ICF has been paying. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Why are you draining 20% of the Community Pool? ","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"This proposal would be one of the largest community pool spends in the Hub’s history, and would be the first time the Hub directly funds a full core development and maintenance team. This would mark a major milestone for the Cosmos Hub. At current rates of inflation and community pool tax, the pool would be replenished fully in 2-3 months. This effectively means that it's not just 20% of a fixed supply, it’s ~16-25% of the community pool’s annual potential, which is a not unreasonable percentage for the pool to spend on its core development. Further, the ICF has also pledged to cover more than half of the cost of the proposal (see below). ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"ICF","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"Why is this Hub funding request for less money than the ICF reported spending on the Hub in 2022?","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"The ICF has been funding Hub development since inception. The 2022 report included ~$7.8M for the Hub across 7 teams. Beginning in 2023, the ICF’s funding for the Hub was greatly simplified and streamlined by consolidating into just 2 teams with a smaller budget: Informal and Hypha, for ~$5.7M. Headcount and costs were able to be reduced overall due to increased efficiency in team organization and the associated increase in focus brought by consolidation. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The numbers and structure in this proposal thus represent the recent stabilization of the Hub team in terms of cost, operations, and organizational structure. This proposal continues that structure but makes it accountable to the Hub instead of the ICF. This represents a significant organizational milestone for the Hub, which lacked coherent structure until 2023.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Why are we asking the community pool rather than the ICF?","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"We believe the Hub should be able to fund itself, and that its governance processes should be mature enough to handle it. We would love to have our Hub team directly accountable to the Hub, rather than the ICF.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"\nThat said, we would still like to see the ICF contribute financially. They have already pledged $3.5M for the Hub’s core development in 2024. Ideally, this pledge would be deployed by the community pool directly. However, given that the prop is already live, and considering the legal and time constraints faced by the ICF, we’d like to see the current proposal pass and the $3.5M from the ICF be used to reimburse the community pool. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"This would make the net cost to the community pool $2.2M + 100k ATOM. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Why isn’t the ICF’s $3.5M commitment mentioned in the proposal?","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"The ICF only disclosed the $3.5M pledge after the proposal was already live. Until then, the core teams had no indication of how much the ICF would commit for the Hub in 2024.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Can the Hub team just be funded with the ICF’s $3.5M?","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"No. The $5.7M budget is based on a major reorganization that stabilized the Hub team for the first time in 2023. Cutting that budget again so soon and with so little warning would seriously disrupt the teams and could compromise them altogether.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Given the announcement from ICF, why not make a new proposal?","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"The current proposal has been on the forums for over a month now. Letting this proposal fail and getting a new proposal up means we would not have any certainty over funding until December, which is too late to plan effectively for 2024. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Proposals consume a lot of time and attention from both the community and the team. A new proposal at this stage will only serve to drag things out, create more uncertainty for the ecosystem and team, and divert the team from more valuable work on the Hub itself. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Voting","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"What will happen if proposal 839 fails?","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"This proposal is a request by Informal and Hypha for the community to recognize and ratify Informal and Hypha’s stabilization of the Hub’s core development and to continue it into 2024, but to shift the ownership from the ICF to the Hub itself.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"If the Hub is not willing to accept ownership through this proposal, we may need to start winding down our work, and the ICF and Hub will need to develop a succession plan for the Hub's core development teams.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"So how should validators vote?","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"If you want the current Hub team to continue in 2024, ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"},{"type":"bold"}],"value":"vote yes","nodeType":"text"},{"data":{},"marks":[],"value":".\n\n","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"contentfulURL":"https://app.contentful.com/spaces/p79kctcd7ahy/entries/7IJ2xA8i5uoNlSkFsY4HmO"},{"featureImage":"$4:props:posts:25:featureImage","date":"2023-10-17","title":"CometBFT Q3 Recap - ABCI 2.0 Release and Storage Optimization Progress","slug":"cometbft-engineering-update-q3-wrapped-up-and-q4-priorities","categories":["Engineering"],"authors":["Andy Nogueira"],"keywords":"cometbft-q3, abci-2.0, bandwidth-optimization, storage-optimization, cometbft-v1, consensus-performance, vote-extensions, interchain-stack, cosmoverse-2023, consensus-engine","excerpt":{"nodeType":"document","data":{},"content":[{"nodeType":"paragraph","data":{},"content":[{"nodeType":"text","value":"Quarterly update covering bandwidth experiments and Q4 v1 release planning.","marks":[],"data":{}}]}]},"includeTableOfContents":true,"introduction":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"TLDR;","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"","nodeType":"text"},{"data":{"uri":"http://cometbft.com/"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"CometBFT","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" is a state machine replication engine for the Interchain Stack. In February 2023, it was forked from Tendermint. You can read the initial announcement ","nodeType":"text"},{"data":{"uri":"https://informal.systems/blog/cosmos-meet-cometbft"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"here","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". CometBFT is currently being stewarded by ","nodeType":"text"},{"data":{"uri":"http://informal.systems/"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Informal Systems","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" with support from many contributors across the interchain stack, including the Cosmos SDK and IBC teams.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Key Takeaways:","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"CometBFT has wrapped up an eventful Q3 with a focus on Bandwidth consumption optimization and Storage usage optimization. Check out details on our ","nodeType":"text"},{"data":{"uri":"https://github.com/orgs/cometbft/projects/1/views/19"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"GitHub project","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"We are excited to have released CometBFT v0.38.0. This release includes the second part of ABCI++, called ABCI 2.0. ABCI 2.0 introduces the ABCI methods ‘ExtendVote’ and ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"VerifyVoteExtension","nodeType":"text"},{"data":{},"marks":[],"value":". You can find the announcement on ","nodeType":"text"},{"data":{"uri":"https://x.com/cometbft/status/1702346641741881514?s=20"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Twitter","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" along with release notes ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/blob/v0.38.0/CHANGELOG.md#v0380"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"here","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"During Q4, we aim to reach the significant milestone of ","nodeType":"text"},{"data":{"uri":"https://github.com/orgs/cometbft/projects/1/views/20"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"releasing v1","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" for CometBFT. We are also continuing to work on optimizing storage and bandwidth, and exploring various enhancements that may extend into 2024","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"As we approach the end of the year, we are looking towards 2024 and the priorities highlighted in the ","nodeType":"text"},{"data":{"uri":"https://docs.google.com/document/d/1j_VnHsM0Hsi2so9gf2oLFKhy3wVa7csCa3lTjlMYCsI"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Interchain Stack Roadmap 2024","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". We will ensure that CometBFT continues to evolve and meet the needs of the community.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"body":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Q3 Recap:","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"It feels like just yesterday we announced the forking of CometBFT from Tendermint in February 2023! And now, after intense development for the last 2 years and numerous contributions from various teams we've completed a productive third quarter. Our primary focus areas during this period were Bandwidth and Storage Optimization, and the ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/blob/v0.38.0/CHANGELOG.md#v0380"},"content":[{"data":{},"marks":[],"value":"release of CometBFT v0.38.0","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". The release of v0.38 was strategically timed and aligned with SDK v0.50 release (which in turn was timed with IBC-go v8 release). The interchain stack teams are aligning releases for landing impactful changes across the system in a coordinated way.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"In Q3, the Bandwidth Optimization squad conducted a series of ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/issues/1149"},"content":[{"data":{},"marks":[],"value":"experiments","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" and implemented modifications to the gossip protocol. These experiments led to numerous intriguing discoveries, and the team is excited to further explore these findings. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Additionally, the Bandwidth Optimization squad made significant improvements to the end-to-end testing infrastructure, such as ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/pull/1262"},"content":[{"data":{},"marks":[],"value":"ways to generate random topologies","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", which is expected to improve the accuracy of experimental results and accelerate the QA process on a larger scale.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The Storage Optimization squad was also very busy during Q3. The most significant milestone for the team was the implementation of new gRPC services outlined in the ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/blob/main/docs/architecture/adr-101-data-companion-pull-api.md"},"content":[{"data":{},"marks":[],"value":"ADR-101","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", which introduced new services such as a ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/pull/1142"},"content":[{"data":{},"marks":[],"value":"BlockService","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", a ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/pull/1168"},"content":[{"data":{},"marks":[],"value":"BlockResultsService","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", and a block and indexer ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/pull/1154"},"content":[{"data":{},"marks":[],"value":"PruningService","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" , which allows for better control of Block, Block Results, and indexed data via a Retain Height parameter. These new services give users more fine-grained control over what data remains stored on a CometBFT node. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Another significant milestone from the Storage Optimization Squad was modifying the pruning mechanism from synchronous to asynchronous, thus not blocking consensus on block pruning.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The squad also worked on other storage optimization improvements, such as removing","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/pull/1297"},"content":[{"data":{},"marks":[],"value":" the genesis file from the database","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". Removing the genesis file from the database is essential for our users whose genesis file exceeds the value size limitations of particular databases, thus ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/pull/1017"},"content":[{"data":{},"marks":[],"value":"causing nodes to crash","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Q4 Priorities:","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"As we march into Q4, our biggest priority is the release of v1 for CometBFT. In this major release we plan to include:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/issues/1330"},"content":[{"data":{},"marks":[],"value":"Proto renaming & Proto versioning","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/pull/1292"},"content":[{"data":{},"marks":[],"value":"Introduction of the Data Companion API","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/issues/75"},"content":[{"data":{},"marks":[],"value":"RPC versioning","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/issues/1484"},"content":[{"data":{},"marks":[],"value":"Reduce Go API surface area","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"Releasing a version as significant as v1 comes with its own set of challenges. We recognize the potential implications and are committed to ensuring a smooth transition for our users. Your perspective matters! We'll be inviting users to share their thoughts on what might be breaking for them and how we can assist in the transition.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Beyond the primary goals, we've also identified some \"nice-to-have\" features. While we're passionate about these, some might shift into our 2024 roadmap:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Further Storage optimization","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Versioning sub-packages as separate Go modules","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Continued Bandwidth optimizations","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Proposer Based Timestamp (PBTS)","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"Our immediate upcoming release, v1 will include improvements such as Bandwidth and Storage optimization, the Data Companion API (which will eventually subsume the indexer and RPC sub-systems), and versioning of the .proto files.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Cosmoverse 2023 and Hackathon:","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"Many people from our team had the privilege of attending the ","nodeType":"text"},{"data":{"uri":"https://cosmoverse.org/"},"content":[{"data":{},"marks":[],"value":"Cosmoverse 2023","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" conference in Istanbul. The event was a great success with many developers, builders, and operators from various chains and projects in attendance. We were thrilled to have the opportunity to meet with them and receive valuable feedback on our work, as well as discuss our future priorities. Overall, it was an enriching experience, and we look forward to attending more conferences like this in the future.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We are thankful to the Cosmos SDK team at Binary Builders for teaming up with CometBFT staff in holding a workshop on the topic of ABCI++ and plumbing the depth of this new powerful feature.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The hackathon organized by DoraHacks turned out to be a huge success, with the CometBFT and Cosmos SDK track garnering the most submissions. Our team and Binary Builders were present at the event to assist developers in creating their solutions and provide in-person support on ABCI++. The event saw some great ideas being proposed, and the ","nodeType":"text"},{"data":{"uri":"https://x.com/cometbft/status/1711802346966048796?s=20"},"content":[{"data":{},"marks":[],"value":"winners were announced as well","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Beyond 2023: A Glimpse into 2024:","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"Our journey doesn't stop with the close of 2023. We've already begun laying the groundwork for our 2024 priorities. Our overarching goals include:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Encouraging the adoption of v0.38.0 in production across chains.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Supporting and fostering innovations around ABCI++.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Expanding our application scope to explore realms like Rollkit, OP Stack, and more.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"In the ","nodeType":"text"},{"data":{"uri":"https://docs.google.com/document/d/1j_VnHsM0Hsi2so9gf2oLFKhy3wVa7csCa3lTjlMYCsI"},"content":[{"data":{},"marks":[],"value":"Interchain Stack Roadmap for 2024","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", we have identified our Key Strategic Themes as Use Cases, Efficiency, IBC, Peace of Mind, and UX. Additionally, we have prioritized a list of sub-projects that are expected to drive the desired outcomes for users based on the outputs of these themes.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Our top priority sub-projects will be the Targeted bandwidth optimization, Targeted storage optimization and Modularize the consensus engine. For other sub-projects please check the Roadmap document linked above.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"A Little Plug for Our Community:","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"Our CometBFT community calls have transitioned from bi-weekly to monthly, ensuring richer content and greater convenience for developers. We'd love to have you onboard! Sign up for our calls ","nodeType":"text"},{"data":{"uri":"https://linktr.ee/cometbft"},"content":[{"data":{},"marks":[],"value":"here","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Feel free to connect with our team on Discord and Telegram for any queries or discussions related to CometBFT. We are always ready to assist and provide you with the necessary information. So don't hesitate to reach out - let's keep the conversation going!","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Thank you for being a part of our journey. We're grateful for your continuous support and feedback, and excited for the road ahead. Let's work together to make CometBFT even better! 🚀","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Stay updated: Follow @cometbft on ","nodeType":"text"},{"data":{"uri":"https://twitter.com/cometbft"},"content":[{"data":{},"marks":[],"value":"Twitter","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"contentfulURL":"https://app.contentful.com/spaces/p79kctcd7ahy/entries/6RD3e0AmVSmbgKy1fkjSN3"},{"featureImage":"$4:props:posts:29:featureImage","date":"2023-10-16","title":"Cosmos Hub Update: September 2023","slug":"cosmos-hub-update-september-2023","categories":["Engineering"],"authors":["Jehan Tremback"],"excerpt":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"V12 upgrade, V13 release cut, Gaia SDK 47 upgrade, and more! ","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"includeTableOfContents":false,"body":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"V12 upgrade","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"During September, the Gaia v12 upgrade came out. This upgrade went smoothly, but had around 25 minutes of downtime. This is because the upgrade contained migration scripts which reformatted the database to work with the LSM, and which took some time to run.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"V13 release cut","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"We cut the Gaia v13 release, which is now live. Cryptographic equivocation was originally intended to go into this release, but we decided to push it to v14 to give us more time to communicate to validators about the new way that slashing will work. Read more ","nodeType":"text"},{"data":{"uri":"https://forum.cosmos.network/t/cryptographic-equivocation-slashing-design/11400/7"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"here","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"V13 contains:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"The final full removal of the Gravity DEX module.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Update ICS to ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/interchain-security/releases/tag/v2.1.0-provider-lsm"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"v2.1.0","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". This update adds a governance proposal to allow consumer chains to add new denoms to pay rewards in. This was added to give the community more control over how many denoms rewards are received in, because each additional denom makes claims cost more in gas. This hasn’t been a problem so far, but we thought it would be good to have a governance process around new denoms being added.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"Gaia SDK 47 upgrade","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"We’ve started upgrading the Gaia software to SDK 47. This will enable us to run newer versions of IBC, giving such abilities as an ICA controller. SDK 47 is in the final stages of an audit with Oak Security, which we wanted to see before putting it on the Hub. This upgrade was originally planned to go into the upcoming Gaia v14 upgrade, but due to the fact that the Liquid Staking Module has not yet been upgraded, Gaia’s upgrade to 47 will have to wait until the v15 release.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"ICS SDK 50 upgrade","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"We’ve started work upgrading ICS to SDK 50, bringing many code style and performance improvements. We will publish guides and best practices around upgrading ICS to facilitate collaboration on this project.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Throttling v2","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"We’ve ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/interchain-security/issues/713"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"finished work on v2 of ICS’s downtime packet","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" throttling mechanism, which prevents malfunctioning or malicious consumer chains from causing problems on the Hub, by storing queued downtime packets on the consumer, instead of the provider. This simplifies the code as well as making it so that a flood of downtime packets from a malfunctioning or malicious consumer chain can be slowed in the queue, and then stopped completely by halting the chain in question.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Cryptographic equivocation research and development","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"We worked a lot on research of cryptographic equivocation verification, to define possible edge cases, and implement the actual code. As noted above, the new cryptographic equivocation code will not go into v13, but is finished.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Testing work","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"We finished our refactor of ICS’s e2e (end-to-end) testing suite to accept serialized traces in a ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/interchain-security/blob/ccdd1173f001486453312ffdf8dfa6d5e0e13f1e/tests/e2e/tracehandler_testdata/happyPath.json"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"JSON format to define test cases","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". This step will allow us to connect the testing suite to a ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/interchain-security/pull/1336"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"formal specification of ICS","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" to automatically generate a very large number of test cases, thereby increasing coverage greatly without having to write tests by hand. We also wrote a ","nodeType":"text"},{"data":{"uri":"https://informal.systems/blog/cometmock"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"blog post","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" explaining CometMock.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"contentfulURL":"https://app.contentful.com/spaces/p79kctcd7ahy/entries/HJv5lS4DBYlKXihjaNxCe"},{"featureImage":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"4UOZNiUHeQO3jyLgv0PTPS","type":"Asset","createdAt":"2024-08-16T07:03:29.201Z","updatedAt":"2024-08-16T07:03:29.201Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":3,"revision":1,"locale":"en-US"},"fields":{"title":"image (1)","description":"","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/4UOZNiUHeQO3jyLgv0PTPS/c187318fb8ae57dd652e1a96cb90be1d/image__1_.avif","details":{"size":37811,"image":{"width":2048,"height":1178}},"fileName":"image (1).avif","contentType":"image/avif"}}},"date":"2023-10-02","title":"CometMock Accelerates Cosmos Testing with 90% Faster End-to-End Tests","slug":"cometmock","categories":["Engineering"],"authors":["Philip Offtermatt"],"keywords":"cometmock, cosmos-testing, end-to-end-testing, consensus-testing, blockchain-simulation, validator-testing, test-acceleration, cosmos-development, interchain-security-testing, abci-testing","excerpt":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Mock consensus engine enables time manipulation and validator behavior simulation.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"includeTableOfContents":true,"introduction":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"At Informal Systems, we take software quality seriously. Consequently, when we are iterating on features for the Cosmos Hub, like ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/interchain-security"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Interchain Security","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", we use an extensive suite of tests. An important part of those are our end-to-end tests. In those tests, we spin up a small “Cosmos ecosystem” by running multiple local testnets with a handful of validators each. We submit sequences of transactions to the chains and check that we get correct behavior by inspecting the resulting chain states. These tests are some of our most high-level tests, checking that all components like various Cosmos SDK modules, but also components outside of the application binary like relayers, are behaving well together. and that our implementation matches the intent of the protocol. We run the application binaries just how validators will run them, so we get results that we are pretty sure match the behavior we would see in production for the same inputs.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We were pretty happy with how our test suite was set up and what coverage it gave us, but we noticed a problem that many blockchain projects eventually hit on with end-to-end tests: They are either slow or flakey. For example, imagine we want to test that a governance proposal to change a parameter is executed correctly when it is voted in. For this, we spin up the local testnet, submit a governance proposal, make enough voting power vote ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"yes","nodeType":"text"},{"data":{},"marks":[],"value":" for the proposal to get accepted, then wait until the voting period is over and check that the parameter change was applied correctly.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Our problem with this workflow is that it is slow - we have to wait for the voting period to end. We clearly set the voting duration shorter than on the real chain (no one wants to wait for two weeks for their test results!), but setting it too short also is problematic - if the voting period is over too quickly, we may not have had enough time to make our validators vote ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"yes","nodeType":"text"},{"data":{},"marks":[],"value":" on the proposal, and our governance proposal will sometimes fail unexpectedly.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We have a similar problem with block times in general: If we make the chain produce blocks slowly, our tests take longer, but if we try to make it produce blocks very fast, validators might not be able to respond in time, and rounds of our underlying consensus engine will fail and have to be retried, which erases any time savings.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"It turns out that while a real consensus engine is great for running real blockchains, it’s not great for running local testnets - in these testnets, we control all the validators, so we don’t really need byzantine fault-tolerance.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Enter: CometMock","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"body":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"CometMock","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"For testing, we have very different requirements from a chain running in production, but we still want our application to be executed as close to reality as possible. That is why we created CometMock, which is a stand-in for CometBFT, the consensus engine powering Cosmos.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"You might know that the CometBFT process communicates with the application via the ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"A","nodeType":"text"},{"data":{},"marks":[],"value":"pplication ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"B","nodeType":"text"},{"data":{},"marks":[],"value":"lock","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"C","nodeType":"text"},{"data":{},"marks":[],"value":"hain ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"I","nodeType":"text"},{"data":{},"marks":[],"value":"nterface, or ABCI for short. The CometBFT process, in turn, communicates with the CometBFT instances of other full nodes, and together they ensure that they send their application instances the same blocks in the same order, thus the applications of nodes in the chain have a consistent state. Along the way, CometBFT does a lot of work to be correct even in the presence of malicious participants.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"RIlucLEHo151mUlHm9jrq","type":"Asset","createdAt":"2023-10-01T23:49:08.572Z","updatedAt":"2023-10-01T23:49:08.572Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":5,"revision":1,"locale":"en-US"},"fields":{"title":"CometMock Blog Post Illustration 1","description":"","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/RIlucLEHo151mUlHm9jrq/c20aee5789b0e0c0b6c11121721be103/comet-mock-1.png","details":{"size":41405,"image":{"width":1952,"height":1123}},"fileName":"comet-mock-1.png","contentType":"image/png"}}}},"content":[],"nodeType":"embedded-asset-block"},{"data":{},"content":[{"data":{},"marks":[],"value":"CometMock also communicates with an application via ABCI, but the difference is that one CometMock instance talks to ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"many","nodeType":"text"},{"data":{},"marks":[],"value":" application instances. These are all instances of the same application, so akin to having many full nodes, but without the gossip between them. This means it saves the heavy communication and computation that is done by CometBFT to be byzantine fault tolerant, but to the application everything looks exactly the same as if it was talking to the real consensus engine.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"2pu7VPMny8YI7EeYMcLAT2","type":"Asset","createdAt":"2023-10-01T23:49:36.682Z","updatedAt":"2023-10-01T23:49:36.682Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":4,"revision":1,"locale":"en-US"},"fields":{"title":"CometMock Blog Post Illustration 2","description":"","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/2pu7VPMny8YI7EeYMcLAT2/8522d5dad08ff79a9e36bf5a5b6e880d/comet-mock-2.png","details":{"size":23305,"image":{"width":1984,"height":1024}},"fileName":"comet-mock-2.png","contentType":"image/png"}}}},"content":[],"nodeType":"embedded-asset-block"},{"data":{},"content":[{"data":{},"marks":[],"value":"This allows us to reduce communication overhead and extra work that is necessary on a real blockchain, but not required in a testing environment.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Even better, since CometMock controls what the application receives over ABCI, we can do some things that real CometBFT does not allow. For example, timestamps - applications typically do not use the system clock to determine time, but instead need to reference the current block time that is provided to them via ABCI as part of the block header. But since it is provided via ABCI, CometMock has full control over it, so we can tell the application what time it is. No need to wait for voting periods to end - just tell CometMock to skip ahead, and to the application, it will look like weeks passed, without having to actually wait more than a few milliseconds!","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"There are a few more exciting things that CometMock allows us to do, like causing downtime and double-sign infractions very easily.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Demo","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"Let’s get hands-on with CometMock and see how easy it makes it to manipulate the chain state.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The tutorial has some dependencies, in particular ","nodeType":"text"},{"data":{"uri":"https://jqlang.github.io/jq/"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"jq","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", e.g. via ","nodeType":"text"},{"data":{"uri":"https://brew.sh/"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"homebrew","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":":","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"code"}],"value":"brew install jq","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"…and ","nodeType":"text"},{"data":{"uri":"https://go.dev/"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Go","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":":","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"code"}],"value":"brew install go@1.20","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"You can follow along with this demo by cloning the CometMock repo:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"code"}],"value":"git clone https://github.com/informalsystems/CometMock.git\ncd CometMock\ngit checkout v0.37.2-3-tutorial","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"…and then installing it:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"code"}],"value":"make install","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"To check that CometMock was installed correctly, let’s check it’s version:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"code"}],"value":"$$ cometmock version\nv0.37.2-3-tutorial","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"In this version string, the first part tells us the version of CometMock we are using is interchangeable with CometBFT v0.37.2.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We also assume you have the binary of some CosmosSDK application (using CosmosSDK v0.47) installed. For example, you can use the ‘simapp’ binary that comes with the CosmosSDK:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"code"}],"value":"git clone https://github.com/cosmos/cosmos-sdk.git\ncd cosmos-sdk\ngit checkout v0.47.5\nmake install","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"To check that ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"simd","nodeType":"text"},{"data":{},"marks":[],"value":" was installed correctly, run","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"code"}],"value":"$$ simd version\n0.47.5","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Once we got both a CosmosSDK app and CometMock installed, let’s start a small testnet to interact with. CometMock provides a handy script that initializes a chain with three validators, all talking to one CometMock instance. Inside the CometMock repo, run","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"code"}],"value":"./local-testnet-singlechain.sh simd","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"…replacing ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"simd","nodeType":"text"},{"data":{},"marks":[],"value":" with the name of the app you want to use.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"This runs for about half a minute. Eventually, you should start seeing the output from CometMock, which looks something like","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"code"}],"value":"I[2023-09-11|15:02:01.292] indexed block exents module=txindex height=1\nD[2023-09-11|15:02:01.292] indexed transactions module=txindex height=1 num_txs=0\nD[2023-09-11|15:02:01.312] Unlocking mutex \t \nD[2023-09-11|15:02:02.313] Locking mutex \t \nI[2023-09-11|15:02:02.313] Running block \t \nI[2023-09-11|15:02:02.322] Sending Commit to clients \t \nI[2023-09-11|15:02:02.322] indexed block exents module=txindex height=2\nD[2023-09-11|15:02:02.322] indexed transactions module=txindex height=2 num_txs=0","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"… and shows us that CometMock is producing blocks.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Let’s check the current block time by using our app binary to query the chain state.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Run:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"code"}],"value":"$$ simd q block --node tcp://127.0.0.1:22331 | jq -r '.block.header.time'\n2023-09-11T13:05:55.676911Z","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"… which, in this case, shows us the current year is 2023.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Let’s see what we can do to change that! CometMock uses the underlying system clock to keep track of time, but we can manually tell it to advance time by some amount. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"All CometMock specific functionalities can be accessed via RPC calls, for example via jsonrpc. Advancing time is one of those special functionalities, so let’s run","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"code"}],"value":"curl -H 'Content-Type: application/json' -H 'Accept:application/json' --data '{\"jsonrpc\":\"2.0\",\"method\":\"advance_time\",\"params\":{\"duration_in_seconds\": \"36000000\"},\"id\":1}' 127.0.0.1:22331","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"…which tells CometMock to advance time by 36000000 seconds, or a bit more than a year.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Now, let’s query the current time again,","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"code"}],"value":"$$ simd q block --node tcp://127.0.0.1:22331 | jq -r '.block.header.time'\n2024-11-01T05:42:12.117043Z","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Suddenly it’s 2024. We skipped over a year pretty quickly there!","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Let’s see another example of CometMock specific functionality, this time taking validators down to stop them from signing.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Recall, this testnet has three validators. Let’s double-check this by seeing the signing information:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"code"}],"value":"$$ simd q slashing signing-infos --node tcp://127.0.0.1:22331\n\ninfo:\n- address: cosmosvalcons1z4kl60l3n4ec2fy9mhsrh8z75ddwthchqxgsl4\n index_offset: \"1634\"\n jailed_until: \"1970-01-01T00:00:00Z\"\n missed_blocks_counter: \"0\"\n start_height: \"0\"\n tombstoned: false\n- address: cosmosvalcons1v349k94tkkjtls4qy8fecquk4te4ddnu5aqh3u\n index_offset: \"1634\"\n jailed_until: \"1970-01-01T00:00:00Z\"\n missed_blocks_counter: \"0\"\n start_height: \"0\"\n tombstoned: false\n- address: cosmosvalcons1e23ydew9fplkd7greu6uavxqaxr8pjw5ljfayn\n index_offset: \"1634\"\n jailed_until: \"1970-01-01T00:00:00Z\"\n missed_blocks_counter: \"0\"\n start_height: \"0\"\n tombstoned: false\npagination:\n next_key: null\n total: \"0\"","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"So we have three validators and none are missing blocks or are tombstoned. Let’s change that by telling CometMock to make a validator stop signing.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"First, run this command to put the key address of one of the validators into an env variable:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"code"}],"value":"PRIV_VALIDATOR_KEY_ADDRESS=$(jq -r '.address' ~/nodes/provider/provider-coordinator/config/priv_validator_key.json)","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Then let’s use that key address to tell CometMock to make a validator not sign by setting its signing status to ‘down’:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"code"}],"value":"$$ curl -H 'Content-Type: application/json' -H 'Accept:application/json' --data '{\"jsonrpc\":\"2.0\",\"method\":\"set_signing_status\",\"params\":{\"private_key_address\": \"'\"$PRIV_VALIDATOR_KEY_ADDRESS\"'\", \"status\": \"down\"},\"id\":1}' 127.0.0.1:22331\n\n{\"jsonrpc\":\"2.0\",\"id\":1,\"result\":{\"new_signing_status_map\":{\"CAA246E5C5487F66F903CF35CEB0C0E98670C9D4\":true,\"156DFD3FF19D73852485DDE03B9C5EA35AE5DF17\":false,\"646A5B16ABB5A4BFC2A021D39C0396AAF356B67C\":true}}}","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The result tells us that one of the validators has its signing status as false now, while the other two have it set to true.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Let’s see the result of what we did in the signing info:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"code"}],"value":"$$ simd q slashing signing-infos --node tcp://127.0.0.1:22331\n\ninfo:\n- address: cosmosvalcons1z4kl60l3n4ec2fy9mhsrh8z75ddwthchqxgsl4\n index_offset: \"1674\"\n jailed_until: \"1970-01-01T00:00:00Z\"\n missed_blocks_counter: \"0\"\n start_height: \"0\"\n tombstoned: false\n- address: cosmosvalcons1v349k94tkkjtls4qy8fecquk4te4ddnu5aqh3u\n index_offset: \"1674\"\n jailed_until: \"1970-01-01T00:00:00Z\"\n missed_blocks_counter: \"13\" ⬅️⬅️⬅️\n start_height: \"0\"\n tombstoned: false\n- address: cosmosvalcons1e23ydew9fplkd7greu6uavxqaxr8pjw5ljfayn\n index_offset: \"1674\"\n jailed_until: \"1970-01-01T00:00:00Z\"\n missed_blocks_counter: \"0\"\n start_height: \"0\"\n tombstoned: false\npagination:\n next_key: null\n total: \"0\"","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Notice that the second validator has started to miss blocks! It would take a while for the validator to get punished for downtime and jailed, since we only start punishing validators when they miss many blocks over a window of blocks, but of course CometMock can help us do this quickly. We can use CometMock to very quickly produce a lot of empty blocks without transactions. Run","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"code"}],"value":"curl -H 'Content-Type: application/json' -H 'Accept:application/json' --data '{\"jsonrpc\":\"2.0\",\"method\":\"advance_blocks\",\"params\":{\"num_blocks\": \"1000\"},\"id\":1}' 127.0.0.1:22331","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"…which will quickly produce 1000 blocks. In the terminal window for CometMock, you should see blocks flying by after you execute this. Let’s check the signing info again to see whether our validator was jailed:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"code"}],"value":"$$ simd q slashing signing-infos --node tcp://127.0.0.1:22331\n\ninfo:\n- address: cosmosvalcons1z4kl60l3n4ec2fy9mhsrh8z75ddwthchqxgsl4\n index_offset: \"2833\"\n jailed_until: \"1970-01-01T00:00:00Z\"\n missed_blocks_counter: \"0\"\n start_height: \"0\"\n tombstoned: false\n- address: cosmosvalcons1v349k94tkkjtls4qy8fecquk4te4ddnu5aqh3u\n index_offset: \"0\"\n jailed_until: \"2024-11-01T05:57:12Z\" ⬅️⬅️⬅️\n missed_blocks_counter: \"0\"\n start_height: \"0\"\n tombstoned: false\n- address: cosmosvalcons1e23ydew9fplkd7greu6uavxqaxr8pjw5ljfayn\n index_offset: \"2833\"\n jailed_until: \"1970-01-01T00:00:00Z\"\n missed_blocks_counter: \"0\"\n start_height: \"0\"\n tombstoned: false\npagination:\n next_key: null\n total: \"0\"","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Let’s demonstrate one last functionality that CometMock offers, which is generating evidence that a validator double-signed. Typically, testing double-signing involves starting two nodes with the same consensus key and tricking their CometBFT processes into double-signing (it is built with safety features to avoid just signing the same block twice, after all!).","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"With CometMock, this becomes just another curl command. Let’s make a validator double-sign by running the following commands:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"code"}],"value":"PRIV_VALIDATOR_KEY_ADDRESS=$(jq -r '.address' ~/nodes/provider/provider-alice/config/priv_validator_key.json)","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"…to grab the key address of another validator (the first one is still jailed until they unjail themselves!) followed by","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"code"}],"value":"curl -H 'Content-Type: application/json' -H 'Accept:application/json' --data '{\"jsonrpc\":\"2.0\",\"method\":\"cause_double_sign\",\"params\":{\"private_key_address\": \"'\"$PRIV_VALIDATOR_KEY_ADDRESS\"'\"},\"id\":1}' 127.0.0.1:22331","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"…to make that validator double-sign.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Let’s check the signing status again:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"code"}],"value":"$$ simd q slashing signing-infos --node tcp://127.0.0.1:22331\n\ninfo:\n- address: cosmosvalcons1z4kl60l3n4ec2fy9mhsrh8z75ddwthchqxgsl4\n index_offset: \"2986\"\n jailed_until: \"1970-01-01T00:00:00Z\"\n missed_blocks_counter: \"0\"\n start_height: \"0\"\n tombstoned: false\n- address: cosmosvalcons1v349k94tkkjtls4qy8fecquk4te4ddnu5aqh3u\n index_offset: \"0\"\n jailed_until: \"2024-11-01T05:57:12Z\"\n missed_blocks_counter: \"0\"\n start_height: \"0\"\n tombstoned: false\n- address: cosmosvalcons1e23ydew9fplkd7greu6uavxqaxr8pjw5ljfayn\n index_offset: \"2980\"\n jailed_until: \"9999-12-31T23:59:59Z\" ⬅️⬅️⬅️\n missed_blocks_counter: \"0\"\n start_height: \"0\"\n tombstoned: true ⬅️⬅️⬅️\npagination:\n next_key: null\n total: \"0\"","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We can see our validator got tombstoned (part of the punishment for double-signing) and is jailed forever!","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"How we use CometMock for testing","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"In the Cosmos Hub team at Informal, we are starting to integrate CometMock in our end-to-end tests. It is already running under the hood in some of our end-to-end tests for Interchain Security. Because we can use CometMock to get faster block times and skip waiting times like voting periods, the running time for this test suite went down from 10 minutes to just 1 minute.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"While we probably never want to completely stop running the tests with standard issue CometBFT, we are planning to use CometMock to run a much bigger, partially randomly-generated suite of tests in the future - involving things that are really hard to do in end-to-end tests with the real consensus engine underneath, such as specifically checking edge cases around block numbers and timestamps.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Conclusion","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"We built CometMock to make our end-to-end tests faster and more reliable. In our tests for Interchain Security, we are able to run 90% faster using CometMock than with CometBFT.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"But this is just the beginning - CometMock can be used to tackle scenarios that are very hard to test with a real consensus engine, such as downtime or double-signing, and makes testing them just a single, easy RPC call. And less time spent on fighting with network and node setups means more time to come up with scenarios that test what matters!","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"If you find CometMock intriguing, make sure to check out the repository at ","nodeType":"text"},{"data":{"uri":"https://github.com/informalsystems/CometMock"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"https://github.com/informalsystems/CometMock","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" and give it a try in your tests. The repo also gives some more details behind how CometMock works if you’re interested in the nuts and bolts!","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"contentfulURL":"https://app.contentful.com/spaces/p79kctcd7ahy/entries/5Y0qzHD3uG9Y5JJsZgFVGF"},{"featureImage":"$4:props:posts:29:featureImage","date":"2023-09-08","title":"Cosmos Hub September 2023 Update - Gaia v12 Upgrade and LSM Integration","slug":"cosmos-hub-engineering-update-august-2023","categories":["Engineering"],"authors":["Jehan Tremback"],"keywords":"cosmos-hub-september, gaia-v12-upgrade, liquid-staking-module, sdk-47-upgrade, ics-development, gravity-dex-removal, cryptographic-equivocation, throttling-v2, cosmos-testing, hub-development\n","excerpt":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Monthly development recap covering SDK 47 upgrade progress and ICS improvements.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"includeTableOfContents":true,"introduction":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"It’s time for the August update from the Informal Systems’ Cosmos Hub team. This month, the community upgraded to Gaia v11 which removed the legacy Liquidity module. This set the stage for the Liquid Staking Module addition in Gaia v12, which we cut and put up for voting. We also made substantial progress on cryptographic slashing verification, a long awaited feature that is queued up for release in v13. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Our work on the Cosmos Hub is focused on positioning it to be an industry leader in an increasingly competitive shared security environment, and places the Hub and its community in a strong strategic position to capitalize on the vibrant developer community coordinating around the Cosmos Hub.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"body":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Gaia v11 deployed","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"On August 16th, the Cosmos Hub validators upgraded to ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/gaia/releases/tag/v11.0.0"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Gaia v11","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". This upgrade included the full removal of Gravity DEX and return of remaining tokens to their owners. The module was not actively maintained and had no utility on the Hub. v11 also included ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/interchain-security/releases/tag/v2.0.0"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Replicated Security v2","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" which contains many improvements made since the launch of Replicated Security v1, as well as a refactor of the global fee module.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Gaia v12 release cut and up for voting","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"This release contains the Liquid Staking Module (LSM), which will facilitate users liquid staking their Atoms by allowing them to be moved to liquid staking without an unbonding period. It also contains global limits to make liquid staking safer at launch. Read more ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/cosmos-sdk/blob/v0.45.16-ics-lsm/docs/architecture/adr-061-liquid-staking.md"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"here","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". The release also contains an upgrade to the Packet Forward Middleware.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The proposal is on the forum ","nodeType":"text"},{"data":{"uri":"https://forum.cosmos.network/t/proposal-821-gaia-v12-upgrade"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"here","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", and up for voting ","nodeType":"text"},{"data":{"uri":"https://www.mintscan.io/cosmos/proposals/821"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"here","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", and if the proposal passes, the release will be live on September 13th.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Thanks to Iqlusion, Stride, Binary Builders for their work and review on the LSM!","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Cosmos SDK 0.47 audit coordination","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"As part of our role reviewing the Cosmos Hub’s dependencies for security, we determined that CosmosSDK v0.47 could use a third party audit. We arranged an audit with Oak Security, and are coordinating with Binary Builders and Oak to move the process along, and are recommending spots in the code to focus on.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"CometMock integrated with Interchain Security e2e tests","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"","nodeType":"text"},{"data":{"uri":"https://github.com/informalsystems/CometMock"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"CometMock","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" is a drop-in replacement for CometBFT for use in tests. We have completed CometMock to the point that it can be integrated into Interchain Security’s end to end test suite. These tests run a network of real CometBFT nodes, and CometMock allows the network to run deterministically at extremely high speeds. This integration has made the tests run much more quickly, taking test runtime down from 10 minutes to about 2 minutes. It has also enabled us to programmatically cause infractions like downtime and duplicate votes, and advance blocks and time in our end to end tests, making them simpler and more flexible.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Cryptographic Equivocation Verification","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"We’ve finished ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/interchain-security/tree/feat/ics-misbehaviour-handling"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"the code","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" to verify equivocation evidence cryptographically on the provider chain. This evidence will be submitted automatically by any connected Hermes relayer. This will be ready to deploy in Gaia v13 as soon as we complete the code to slash validators and delegators when this equivocation is detected. This will require some changes to the slashing rules, which are being discussed ","nodeType":"text"},{"data":{"uri":"https://forum.cosmos.network/t/cryptographic-equivocation-slashing-design/"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"here","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". Thanks to the CometBFT and Hermes teams at Informal for doing a large amount of work on this feature.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Downtime jail packet throttling v2","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"We’ve almost completed ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/interchain-security/pull/1230"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"the code","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" for an upgrade to the throttling system for downtime jailing packets. With this new code, if a consumer chain malfunctions and sends a large number of downtime packets, it will not affect the Hub. The packets will be throttled so that they do not take effect all at once, and if the validator set halts the consumer chain, no further packets will be sent. This gets us closer to the “untrusted consumer chain” paradigm, a major goal for 2023.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Neutron halt bug fix coordination","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"We’ve been helping the Neutron team diagnose a bug which ultimately turned out to be caused by inefficient storage of downtime records. This was fixed by Binary Builders in Cosmos SDK 0.50, and the Neutron team backported the fix to SDK 0.47 to solve the problem on Neutron.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Stride state bloat fixed","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"The Hermes team at Informal helped Stride diagnose and fix ","nodeType":"text"},{"data":{"uri":"https://twitter.com/informalinc/status/1699112668135842227?s=20"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"a state bloat bug","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" which was related to IBC relaying. A large number of redundant IBC packets were being created, with over 90% of the packets being redundant. After this was diagnosed, the Hermes team was able to recommend a fix, which was applied by the Notional team to Stride.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"About the Author","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"","nodeType":"text"},{"data":{"uri":"https://twitter.com/JTremback"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Jehan Tremback","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" is the product owner for the Cosmos Hub at ","nodeType":"text"},{"data":{"uri":"https://twitter.com/informalinc"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Informal Systems","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", where he works on exciting new features for the Hub.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"contentfulURL":"https://app.contentful.com/spaces/p79kctcd7ahy/entries/6zOGvQdgmZb1YOjVRQvXd9"},{"featureImage":"$4:props:posts:50:featureImage","date":"2023-09-06","title":"Intro to IBC-rs","slug":"intro-to-ibc-rs","categories":["Engineering"],"authors":["Philippe Laferrière"],"keywords":"ibc-rs, rust-ibc, blockchain-interoperability, consensus-agnostic, validation-context, execution-context, ibc-clients, ibc-applications, namada-integration, cosmos-sdk","excerpt":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"How IBC-rs abstracts validation and execution for flexible blockchain architectures.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"includeTableOfContents":false,"body":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"ibc-rs is a Rust library that implements the Inter Blockchain Communication (IBC) protocol. Ibc-rs was designed from the ground up to be independent from the underlying consensus. Want to use CometBFT? Sure! Near? Of course! Solana? You got it. This is achievable because through our ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"ValidationContext","nodeType":"text"},{"data":{},"marks":[],"value":" and ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"ExecutionContext","nodeType":"text"},{"data":{},"marks":[],"value":" traits, we abstract away how transactions look like, the store, and basically every other detail that is not native to IBC.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"This article is going to be solely about ibc-rs, the implementation of the protocol. Before you keep reading, you might want a refresher on how IBC works. You can read more about IBC on ","nodeType":"text"},{"data":{"uri":"https://ibcprotocol.dev/"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"the website","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", or in the ","nodeType":"text"},{"data":{"uri":"https://ibc.cosmos.network/"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"ibc-go docs","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Clients","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"A core concept in IBC is clients. It is the core abstraction that keeps track of the counterparty chain and verifies proofs. There are many different types of clients. Although currently the most commonly used one is the tendermint light client, IBC's client abstraction is way more flexible than just that. It is not only flexible enough to let you implement light clients for any other consensus protocol; it can also be used to define a multisig protocol, where a set of trusted keys inform IBC of changes to the counterparty chain. In fact, this client exists, and is called the \"solomachine\" client in IBC parlance.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"ibc-rs was architected in a way that lets client implementations live outside the core crate. This way, anyone can implement new light clients and have those live in separate crates. And in fact people are! Octopus Network wrote a ","nodeType":"text"},{"data":{"uri":"https://github.com/octopus-network/ics06-solomachine"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"solomachine client","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". Composable Finance wrote a ","nodeType":"text"},{"data":{"uri":"https://github.com/ComposableFi/centauri/tree/master/light-clients/ics13-near"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Near light client","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", although it is currently written for an older version of ibc-rs. They are working on upgrading it to the latest version; stay tuned!","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Applications","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"Applications are another core concept in IBC. This is where the business logic is meant to live. The most popular application is the token transfer application, also known as ICS 20. As the name suggests, this is the application that lets you send tokens across to other chains. However, IBC doesn't stop there. Applications are actually a quite powerful abstraction. You can define many different protocols, from controlling accounts on other chains (","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/ibc/blob/main/spec/app/ics-027-interchain-accounts/README.md"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"ICS 27","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"), to atomic swaps (","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/ibc/tree/main/spec/app/ics-100-atomic-swap"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"ICS 100","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":").","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"ibc-rs currently only supports the token transfer app out of the box. However, similar to clients, ibc-rs was architected in a way that lets users write applications in separate crates. You simply need to ensure that your app implements the ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"Module","nodeType":"text"},{"data":{},"marks":[],"value":" trait, and you're good to go!","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Separation of validation and execution","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"As a user of ibc-rs, the two primary traits that you will have to implement are ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"ValidationContext","nodeType":"text"},{"data":{},"marks":[],"value":" and ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"ExecutionContext","nodeType":"text"},{"data":{},"marks":[],"value":". The first, ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"ValidationContext","nodeType":"text"},{"data":{},"marks":[],"value":", asks you to implement methods that will be used when performing any validation that core IBC needs to do (achieved by calling ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"validate()","nodeType":"text"},{"data":{},"marks":[],"value":"). For example, one method asks you to retrieve a ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"ClientState","nodeType":"text"},{"data":{},"marks":[],"value":" object associated with a certain client at a given height. The second, ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"ExecutionContext","nodeType":"text"},{"data":{},"marks":[],"value":", exposes additional methods that will be needed for ibc-rs to apply the state changes that executing a given IBC datagram requires (achieved by calling ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"execute()","nodeType":"text"},{"data":{},"marks":[],"value":").","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Now, why bother separating the \"validation\" and \"execution\" of IBC datagrams? It is to enable a larger class of possible chain architectures.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"A great example of this is ","nodeType":"text"},{"data":{"uri":"https://namada.net/"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Namada","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". In a nutshell, for any given transaction, Namada allows users to define multiple validation steps, that they call \"validity predicates\". If any one of these validity predicates fail, then the whole transaction fails. Only if all validity predicates succeed then is the transaction actually executed. In the case of IBC datagrams, the IBC validation is only one of many possible validations that users might want to run. Since all validity predicates are independent, they are run in parallel, leading to a more efficient chain. Before we separated validation and execution, similar architectures would not be able to use ibc-rs; or at least be slowed down by it.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"That is to say, you can still use ibc-rs even if you don't care about separating validation and execution! Internally, we sometimes call such chain architecture \"SDK-like chains\", referring to the Cosmos SDK. All you need to do is implement ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"ValidationContext","nodeType":"text"},{"data":{},"marks":[],"value":" and ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"ExecutionContext","nodeType":"text"},{"data":{},"marks":[],"value":", and use ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"dispatch()","nodeType":"text"},{"data":{},"marks":[],"value":" to process IBC datagrams. This will perform validation, followed by execution.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Hence, the separation of validation and execution enabled a strictly larger set of architectures with no downsides for those who don't need distinction; we thus felt it resulted in a better library.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"What's coming","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"Of course, we're not done improving ibc-rs (will we ever be?). For one, we'd like to add support for middlewares. Middlewares sit between core IBC and an application, and allow developers to tweak how a base application works. A widely used middleware is Strangelove's ","nodeType":"text"},{"data":{"uri":"https://pkg.go.dev/github.com/cosmos/ibc-apps/middleware/packet-forward-middleware/v7#section-readme"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Packet Forward Middleware (PFM)","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", which sits between IBC core and the token transfer app, and allows to send tokens to a destination chain passing through another one. This is sometimes referred to as a \"multi-hop channel\" for tokens only.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Another feature we're considering is to offer an async API. The library currently offers only a synchronous API. If this is something that your team would benefit from, please reach out and let us know!","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"And this is probably the most important. We're building ibc-rs for you. If a feature is missing, or you'd like us to make some tweaks, please reach out! A great way is to ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/ibc-rs/issues"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"open an issue on Github","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". We also hold monthly developer calls, which you can attend by joining our ","nodeType":"text"},{"data":{"uri":"https://groups.google.com/g/ibc-rs-community"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Google group","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". Feel free to jump in and let us know how we can help you.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"contentfulURL":"https://app.contentful.com/spaces/p79kctcd7ahy/entries/Z9nkLFnRGrUZJ4MIRfbhZ"},{"featureImage":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"6TQY7QBJgbaZcdlg0NGnII","type":"Asset","createdAt":"2024-08-14T03:37:39.700Z","updatedAt":"2024-08-14T03:37:39.700Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":3,"revision":1,"locale":"en-US"},"fields":{"title":"https images.ctfassets.net p79kctcd7ahy 5r2JtYjdcu6p2ibWMCFEPa 3fe481c39ca17a6264bf373772f6ff10 image1","description":"","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/6TQY7QBJgbaZcdlg0NGnII/9ecab0a25bde14804cd5dba800c35d3a/https___images.ctfassets.net_p79kctcd7ahy_5r2JtYjdcu6p2ibWMCFEPa_3fe481c39ca17a6264bf373772f6ff10_image1.png","details":{"size":52027,"image":{"width":1918,"height":1034}},"fileName":"https___images.ctfassets.net_p79kctcd7ahy_5r2JtYjdcu6p2ibWMCFEPa_3fe481c39ca17a6264bf373772f6ff10_image1.png","contentType":"image/png"}}},"date":"2023-09-05","title":"Atomic IBC Enables Cross-Chain Composability with Instant Finality","slug":"atomic-ibc","categories":["Engineering"],"authors":["Jehan Tremback"],"keywords":"atomic-ibc, cross-chain-composability, replicated-security, atomic-transactions, megablocks, shared-sequencer, cosmos-hub, interchain-security, defi-automation, atomic-zones","excerpt":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"How atomic transactions across consumer chains create network effects and differentiation.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"includeTableOfContents":true,"introduction":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Many new protocols that use the same basic techniques pioneered by Interchain Security are emerging. Some of these are Mesh Security, Eigenlayer, and Polygon 2.0. In all of these protocols, stake from one blockchain system can be used to secure another. Right now, they are different protocols, but over the long term, interoperability requires nothing more than a little bit of shim code.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The future will be a fluid market of commoditized proof of stake security. What token you choose to stake will have no bearing on which applications you can choose to secure, and what chain/rollup/DA/etc they run on. A market where products are undifferentiated is known as a commoditized market. It is generally considered to be difficult for producers to profit in such a market. The market for shared security seems to be going in this direction.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Conversely, a differentiated product is one that can only be obtained from one source. Even if there are other products of its type that it competes with, it has a unique offering that cannot be obtained elsewhere. There is a good reason for consumers to switch to such a product, and if they are switching away from it, they will have to give something up. The shared security market does not have differentiation, since the thing being bought and sold is a number representing assets at stake, which can come from many different sources.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"In addition to operating in a commoditized market, shared security platforms do not have a strong network effect. A network effect is when the more use a product gets, the more useful it becomes. Many inventions, such as railroads, the telegraph, the power grid, the internet, and social media, all harness strong network effects. Shared security providers do not have such a network effect, since securing a larger number of applications does not, by itself, make the security more effective.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"While commoditized markets are not good for producers, they are good for consumers. Commoditization means quick, scaleable, and inexpensive access to a resource. In the proof of stake security market, this means that any application will be able to get access to exactly as much security as it needs from the security mesh, at a competitive price.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The platforms which will succeed in this security mesh will not rely solely on providing security, but will instead have the following characteristics:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Differentiation:","nodeType":"text"},{"data":{},"marks":[],"value":" Applications joining these platforms will be getting something which they can’t get anywhere else. Applications leaving these platforms will have to sacrifice functionality or resources to do so.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Network effect:","nodeType":"text"},{"data":{},"marks":[],"value":" The more applications join such a platform, the greater the benefits from using the platform.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"body":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Atomic composability: A differentiated offering","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"Atomically composable platforms allow the applications using them to communicate with each other instantly. Transactions between applications on an atomically composable platform can be programmed synchronously, and they don’t have to worry about the state of any of the applications on the platform changing during the time that the transaction is in progress.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Some examples of atomic composability platforms are monolithic smart contract platforms like Ethereum and Solana, shared sequencers like Astria and Espresso, and the subject of this paper, Atomic IBC. Some examples of platforms that do not provide atomic composability are rollups using independent sequencers, Cosmos chains communicating using regular IBC, and shared security platforms such as ICS, mesh security, or Eigenlayer.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Atomic composability platforms are differentiated because they offer the ability to interoperate tightly with a certain set of applications, something that is impossible to get even when switching to another atomic composability platform (they will have a different set of applications). In contrast to selling security, this differentiation means that a platform can build up a lead with a unique offering, without constantly having its market share eroded by competitors who can offer the same amount of security for less.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"As well as being differentiated, atomic composability platforms have strong network effects. The more high quality applications are on an atomic composability platform, the more sense it makes for new applications to join. This dynamic is known as a network effect, and is key to building a durable advantage. Simply providing security does not have such a network effect.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Monolithic smart contract platforms are one of the most common forms of atomically composable platforms. For example, on Ethereum, function calls between contracts happen atomically, and no other state on Ethereum changes while a series of function calls between contracts is in progress. A downside of most monolithic smart contract platforms (but not all, see Solana) is that they tend not to be very scalable. They process transactions sequentially, one at a time, which can be a huge bottleneck during times of high demand. Another downside is that they generally only work with one programming model, and smart contracts don’t offer full flexibility.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Atomic IBC: Atomic composability with multichain scalability","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"Atomic IBC is an evolution of Replicated Security which allows consumer chains (or “atomic zones”) to compose atomically with one another, while still being able to scale infinitely using parallelism. This is accomplished with a protocol called Atomic IBC. Consumer chains can connect to other consumer chains and external chains using normal IBC. This is asynchronous and non-atomic. But for transactions which must compose atomically between consumer chains, atomic IBC can be used. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"An atomic IBC bundle consists of several transactions happening across multiple zones, with communication coordinated by the IBC protocol. Atomic IBC transactions are fully atomic. If one piece of an atomic IBC transaction fails, the whole transaction is rolled back, across all zones. Atomic IBC transactions also preserve isolation- no other state on any zone will change during the atomic IBC transaction, except for state changed by the atomic IBC transaction itself.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Atomic IBC is optional- users decide at runtime whether they want a given transaction to be atomic or not. This will be useful for many things such as arbitrage and flash loans, and works right away with existing applications that support IBC. Atomic IBC combines the scalability of a multichain system with on-demand atomic composability, giving users the best of both worlds.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"It’s likely that Atomic IBC will be finished before the inevitable cross-chain shared security marketplace as envisioned above has fully emerged from separate efforts such as Mesh Security and Eigenlayer. During this time, consumer chains will be secured by the substantial security of the Cosmos Hub.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"As the shared security marketplace becomes more interlinked, the Cosmos Hub will be able to begin consuming security. It will have access to the security of assets staked across many proof of stake chains, which is currently in the hundreds of billions of dollars. The Hub, of course, will be able to sell security from its staked Atoms as well.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"At this point, any blockchain application will have access to the same potential PoS security as any other application. In this world, the market value of a blockchain’s own staking token will not be as important, and there will be a distinct competitive advantage for applications that are able to interoperate atomically with other high quality applications.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Atomic IBC use cases","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"Atomic IBC has the potential to greatly improve the user experience and developer experience on interchain transactions in the AEZ. Atomic IBC should be able to reduce the running time of complicated interchain workflows from minutes to seconds, and reduce the amount of code needed to handle them by up to 90%.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"However, regular IBC will always be critical for bridging between ICS and standalone chains, and between ecosystems. Atomic IBC just makes it so that interactions between chains in the AEZ are faster, smoother, and much easier to build.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Let’s look at an example.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Timewave stATOM-ATOM LP automation","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"A common application type on atomic composability platforms is the orchestration contract. This type of application composes several other DeFi applications to automate an outcome for end users. A good example is Yearn on Ethereum. This application automates complicated DeFi market making positions to generate a return for users, without those users having to do the operations themselves.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"This is also possible asynchronously over IBC, but it can be complicated. Every step of the process which involves an IBC connection can potentially fail or time out, and due to the time that the sequence of steps takes, state on the chain might have changed. Timewave is a project building this type of DeFi automation platform in Cosmos. Let’s look at one of their products, which takes ATOM as an input, liquid stakes it to get stATOM, and then enters an stATOM-ATOM LP position on Astroport.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Steps:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Create interchain account on Hub","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Send Atom to interchain account","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Create interchain account on Stride","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Send half of the Atom to Stride interchain account and convert to stATOM","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Send stATOM to Timewave contract","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Send remaining Atom to Timewave contract","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Timewave contract enters LP position stATOM-ATOM, sending LP tokens to user","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"This is a relatively straightforward sequence of steps, but dealing with the asynchronous nature of IBC makes it more complicated than it appears here. 5 IBC packets are sent in this sequence and each one introduces some latency and a potential timeout. Every time that there is a timeout or other type of failure, the system needs to be able to recover and do the right sequence of steps to get back to a good state, otherwise the user will be left halfway through the process not knowing where their coins are.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"With Atomic IBC, this can be much simpler. It’s still the same sequence of steps as above, but without any code to deal with timeouts or failures. Either the whole sequence completes successfully, or nothing happens. It’s estimated that the amount of code in this contract could be reduced by 90% with Atomic IBC. Also, due to the latency introduced by the IBC packets, this contract currently takes 2-3 minutes to complete. With Atomic IBC, this time goes down to 1 block, or around 6 seconds.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"This is a big developer experience improvement, and developer experience often has a big effect on user experience. While in theory it is possible for developers to deal with all failure modes and edge cases in an asynchronous application, in practice they miss some, and some number of users will be left needing to clean up a half-completed operation. Each IBC packet send incurs at least a block’s worth of latency, and often more. With Atomic IBC, the entire operation either succeeds or fails, and it happens in one block.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Technical implementation","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"Replicated Security currently allows consumer chains to share the Cosmos Hub’s security by sharing the Hub’s validator set. This overlap in the validator set is what makes Atomic IBC possible. There are several ways to take advantage of this overlap. Note: Not all Replicated Security consumer chains will need to use Atomic IBC.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Megablocks","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"Megablocks has participating consumer chains share a mempool and blocks, while maintaining separate state machines. Consumer chains participating in Atomic IBC basically run on one chain. Even though the blocks are shared, transactions of each consumer chain are run in parallel in their own lanes unless they are part of an atomic IBC bundle. This model is comparable to a DA layer plus shared sequencer in one platform.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"This enables IBC to be used in an atomic, isolated, and effectively synchronous mode. This enables deterministic arbitrage, flash loans, rebalancing, and other interactions which are normally only possible across applications on a single chain.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"While transactions of each chain run in parallel for scalability, users can choose that any transaction or bundle of transactions be executed sequentially using Atomic IBC.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Transactions in an Atomic IBC bundle are executed sequentially, at the beginning of each block, even if the bundle includes transactions on many different consumer chains.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"IBC messages in an atomic bundle are “relayed” instantly between chains without the need to generate and verify a light client proof (taking advantage of the fact that the consumer chains share a validator set). ","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Messages can be sent back and forth between consumer chains multiple times in an atomic bundle. ","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"During the time that the atomic bundle is being executed no other state changes on any of the involved chains. ","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Given a particular state at the start of the atomic bundle’s execution, the outcome across all involved chains is deterministic. ","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"If any transaction in the atomic bundle fails, the whole bundle is rolled back.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"Once all atomic bundles have been executed, the rest of the blocks of each consumer chain are executed in parallel.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"5r2JtYjdcu6p2ibWMCFEPa","type":"Asset","createdAt":"2023-09-06T22:37:11.754Z","updatedAt":"2023-09-06T22:37:11.754Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":5,"revision":1,"locale":"en-US"},"fields":{"title":"Atomic IBC","description":"","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/5r2JtYjdcu6p2ibWMCFEPa/3fe481c39ca17a6264bf373772f6ff10/image1.png","details":{"size":136625,"image":{"width":1918,"height":1034}},"fileName":"image1.png","contentType":"image/png"}}}},"content":[],"nodeType":"embedded-asset-block"},{"data":{},"content":[{"data":{},"marks":[],"value":"Other technical attributes","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"Reduction of Replicated Security costs","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"Atomic IBC uses a single Comet process for all participating consumer chains, while sharding most execution. This is analogous to DA layers like Ethereum or Celestia, which use a single consensus process to store data for a large number of rollups. When comparing this model to Replicated Security, ongoing per-chain costs are greatly reduced, since adding a consumer chain does not require running another Comet node. Costs for running consumer chains with Atomic IBC scale smoothly with their transaction volume and storage use.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Single MEV marketplace","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"Atomic IBC functions by processing blocks from all participating consumer chains and atomic bundles in one cadence, and each block has one proposer. This provides a simple and powerful interface for services selling prioritized access to block space, aka MEV. A proposer can sell priority access to blocks across all participating consumer chains, and atomic bundles across the tops of the blocks at once. And since proposers are chosen by amount of staked ATOM, MEV value ultimately accrues back to ATOM.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Atomic IBC compared to shared sequencers and cross chain MEV platforms","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"Atomic IBC has goals similar to shared sequencers and cross chain MEV platforms such as SUAVE. All of these platforms aim to facilitate atomic composability between separate state machines. Most shared sequencers and cross chain MEV platforms offer the following atomicity guarantees:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Atomic inclusion: ","nodeType":"text"},{"data":{},"marks":[],"value":"Given two transactions, if one gets into a block on one chain, the other will get into a block at the same time on another chain.\n\nThis is pretty limited, but things like arbitrage and other types of MEV can be built with it. More sophisticated things like flash loans can get ","nodeType":"text"},{"data":{"uri":"https://x.com/sanjaypshah/status/1686759738996912128?s=20"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"quite complicated","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". While atomic inclusion can be a great starting point to build valuable MEV-harvesting features, it is far from full atomic composability and doesn’t do a lot for user or developer experience.\n\nAtomic IBC, meanwhile, provides full atomic composability. These are the same properties offered by monolithic smart contract platforms, but Atomic IBC does it with more scalability and customizability than most smart contract platforms do. This does not mean that shared sequencers and MEV platforms are a bad idea, it’s simply that they make different tradeoffs. In addition to atomic inclusion, here are the guarantees offered by Atomic IBC:","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Isolation: ","nodeType":"text"},{"data":{},"marks":[],"value":"No state anywhere in the system will change from the beginning of an atomic bundle to the end, other than changes made by transactions in the bundle. This means that, for example, an arbitrage bundle could make several interchain queries for prices at the beginning of the bundle, and have those prices remain completely accurate over the course of the bundle’s execution. In the Timewave example above, this property allows the contract to know exactly how much ATOM to convert to stATOM to get a 50-50 LP position.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Atomic execution: ","nodeType":"text"},{"data":{},"marks":[],"value":"If one transaction in an atomic bundle returns an error, every transaction executed as part of the bundle will be rolled back. Any errors in the bundle make it so that it is as if the bundle never happened. In the Timewave example above, this property means that there doesn’t need to be any error recovery code, greatly reducing the amount of code required.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Multi step and cyclical sequences: ","nodeType":"text"},{"data":{},"marks":[],"value":"The atomic inclusion property offered by shared sequencers and MEV platforms can guarantee at most that a send on one chain and corresponding receive on another chain are both processed. An atomic bundle can contain longer sequences of transactions across multiple chains, and even allow chains to send transactions back and forth (cyclically) between them. In the Timewave example above, this property makes it possible to easily program as many steps as are needed to complete the goal.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Dynamic transaction generation: ","nodeType":"text"},{"data":{},"marks":[],"value":"Atomic IBC allows new transactions to be generated during the execution of a bundle, without the programmer needing to supply every transaction which will be in a bundle.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"ordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"These are the same properties provided by monolithic smart contract platforms (for example, calls between contracts on Ethereum). This means that programming skills honed on smart contract platforms can easily be applied in the AEZ. Regular IBC as it exists today will always be very useful for communication between different ecosystems, and between the AEZ and chains outside of it, but Atomic IBC will provide a faster, simpler, and easier form of composability between chains in the AEZ.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"contentfulURL":"https://app.contentful.com/spaces/p79kctcd7ahy/entries/7zTf5uNzh0XOcGennEnMAp"},{"featureImage":"$4:props:posts:50:featureImage","date":"2023-08-23","title":"Stride Relaying Issue Post Mortem","slug":"stride-relaying-issue-post-mortem","categories":["Engineering"],"authors":["Hermes Dev Team"],"keywords":"stride-relaying, ibc-performance, hermes-relayer, redundant-packets, ante-handler, chainpulse-monitoring, ibc-debugging, stride-upgrade, relayer-efficiency, packet-analysis","excerpt":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Post-mortem analysis of redundant packet issues and Stride v13 upgrade fix.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"includeTableOfContents":false,"body":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"On July 19th, the Hermes team noticed some chatter on Twitter mentioning Hermes being outpaced by Rly when relaying on Stride from several relayers such as ","nodeType":"text"},{"data":{"uri":"https://twitter.com/zanglang/status/1681587089769635842"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"IcyCRO","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", ","nodeType":"text"},{"data":{"uri":"https://twitter.com/lavender_five/status/1681633187682713601?s=20"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"LavenderFive","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" and ","nodeType":"text"},{"data":{"uri":"https://twitter.com/GoldenStaking/status/1681634977950179331"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"GoldenStaking","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"This intrigued us, because in the ","nodeType":"text"},{"data":{"uri":"https://informal.systems/blog/finer-grained-control-over-hermes-performance-with-v1-5"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"v1.5 release of Hermes","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", we made some major performance improvements that greatly improved relaying on virtually all channels. So we decided to take a closer look. Turns out things weren’t quite what they seemed.\n\nWe booted up some tooling to monitor transactions and packets sent to Stride. We used our ","nodeType":"text"},{"data":{"uri":"https://github.com/informalsystems/chainpulse"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"ChainPulse","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" tool, which collects information on IBC packets, the results of their execution, and who relayed them, and exposes it all in a nice Prometheus time series database. Combining that with a Grafana dashboard, we’ve got a full on IBC network analysis station 😎 ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Between July 19th and August 14th, we identified 82 Hermes instances and 15 Rly instances relaying on Stride. Over that same period of time, a total of ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"2,008,945","nodeType":"text"},{"data":{},"marks":[],"value":" IBC packets were sent to Stride by the combined relayer instances of Hermes and Rly.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"But not every sent packet is equal! Sometimes relayers send redundant packets, because relaying is an off-chain race in the mempool. Redundant packets don’t have any effect on the state, so they’re just kind of wasteful. Out of those 2M sent packets during this time, it turned out that around 1.8M were actually redundant (had no effect!). From what we could tell, ~99% of the packets being relayed by Rly, and ~60% of the packets being relayed by Hermes, were redundant. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"⚠️ This means that ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"~90%","nodeType":"text"},{"data":{},"marks":[],"value":" of the IBC packets sent to Stride over that period of time were redundant.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"blockquote"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"💡 For comparison, on Osmosis, over the same period of time, only ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"0.2%","nodeType":"text"},{"data":{},"marks":[],"value":" of the packets sent to Osmosis were redundant.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"blockquote"},{"data":{},"content":[{"data":{},"marks":[],"value":"Clearly something was up.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The Underlying Issue","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"We began to investigate and quickly noticed this issue with an abnormally high amount of redundant packets being sent to Stride. We got in touch with the team at Stride, and with the Strangelove team working on Rly to share what we were seeing.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Ultimately we realized that txs containing only redundant packets were not rejected with an ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"error 22: packet messages are redundant","nodeType":"text"},{"data":{},"marks":[],"value":" by Stride, as they should have been. We were able to confirm our hypothesis using an","nodeType":"text"},{"data":{"uri":"https://github.com/informalsystems/hermes/pull/3505"},"content":[{"data":{},"marks":[],"value":" ","nodeType":"text"},{"data":{},"marks":[{"type":"underline"}],"value":"integration test","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" that Stride v12 does not filter redundant IBC packets.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Meanwhile, we noticed this issue on the Stride repository, opened by Jorge Hernandez on May 29th ","nodeType":"text"},{"data":{"uri":"https://github.com/Stride-Labs/stride/issues/807"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"https://github.com/Stride-Labs/stride/issues/807","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Stride seems to be using the standard ante handler from cosmos sdk, which does not include the ibc ante handler which helps with removing redundant packets.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"blockquote"},{"data":{},"content":[{"data":{},"marks":[],"value":"Aha! Indeed, the Stride app did not use the IBC-go ante handler, which is in charge of rejected txs which only contains redundant packets with an error 22. Instead, it was using the stock Cosmos-SDK AnteHandler.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"So this explained why relayers were submitting many more redundant packets than they would otherwise submit on Stride.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"A patch for this issue was submitted ","nodeType":"text"},{"data":{"uri":"https://github.com/Stride-Labs/stride/pull/882"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"here","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" and the fix has been included in Stride v13.0.0+ We re-targeted our integration test towards Stride v13 and were able to confirm that the bug has been fixed in Stride v13.0.0 and Stride v13.0.1. No more redundant IBC packets!","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Stride v13 Upgrade","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"On August 19th, the Stride network underwent an upgrade to Stride v13.1.0, which includes the fix for the missing IBC ante handler described above.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Since then, the efficiency of both relayers has improved massively, as can be seen on the recent screenshots below from our Chainpulse tool:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"2nvtjoPc5E8b8mLe9aNizy","type":"Asset","createdAt":"2023-08-23T14:58:36.987Z","updatedAt":"2023-09-01T19:18:07.147Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":7,"revision":2,"locale":"en-US"},"fields":{"title":"Stride Downtime Image 1","description":"","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/2nvtjoPc5E8b8mLe9aNizy/0050ee3aaf0bab4b0e845cfc2ffb6551/image6.png","details":{"size":247119,"image":{"width":1999,"height":848}},"fileName":"image6.png","contentType":"image/png"}}}},"content":[],"nodeType":"embedded-asset-block"},{"data":{},"content":[{"data":{},"marks":[{"type":"italic"}],"value":"channel-0 <> Cosmos Hub (ICS-20 transfers)","nodeType":"text"}],"nodeType":"paragraph"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"5UNSU9Lgm75xxtr0g3MG5T","type":"Asset","createdAt":"2023-08-23T14:59:10.650Z","updatedAt":"2023-09-01T19:18:27.482Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":8,"revision":2,"locale":"en-US"},"fields":{"title":"Stride Downtime Image 2","description":"","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/5UNSU9Lgm75xxtr0g3MG5T/11892df1cfc781b92b5ead745b90355a/image3.png","details":{"size":242396,"image":{"width":1999,"height":843}},"fileName":"image3.png","contentType":"image/png"}}}},"content":[],"nodeType":"embedded-asset-block"},{"data":{},"content":[{"data":{},"marks":[{"type":"italic"}],"value":"channel-5 <> Osmosis (ICS-20 transfers)","nodeType":"text"}],"nodeType":"paragraph"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"2YxzlPHlyYdIIAG7Yqcyf3","type":"Asset","createdAt":"2023-08-23T14:59:29.998Z","updatedAt":"2023-09-01T19:18:39.944Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":7,"revision":2,"locale":"en-US"},"fields":{"title":"Stride Downtime Image 3","description":"","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/2YxzlPHlyYdIIAG7Yqcyf3/4259b975b56711f580bc4648ebe8cfdb/image2.png","details":{"size":261137,"image":{"width":1999,"height":850}},"fileName":"image2.png","contentType":"image/png"}}}},"content":[],"nodeType":"embedded-asset-block"},{"data":{},"content":[{"data":{},"marks":[{"type":"italic"}],"value":"channel-146 <> Cosmos Hub (Interchain Security)","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"As can be seen above, the efficiency of the relayers increased massively on these three high-traffic channels. That said, there appears to be some lingering issues with Rly on channel-146. But overall, the numbers look much better already across all three channels for both relayers.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Conclusion","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"What started as a claim that Rly was performing better than Hermes on Stride turned out to be a bug that was causing 99% of packets sent by Rly (and 60% of packets from Hermes) to be redundant.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"This investigation highlights the subtleties of IBC performance and the importance of precisely measuring what happens over the IBC network in order to explain high-level behaviour. We hope our ChainPulse tool will help the IBC community shed more light on interchain activity in order to simplify debugging, gain insights, and create a more transparent IBC ecosystem. \n\nSee you out in the interchain 🫡","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"contentfulURL":"https://app.contentful.com/spaces/p79kctcd7ahy/entries/3lbENEpGMSujfuVF96VV6f"},{"featureImage":"$4:props:posts:29:featureImage","date":"2023-08-17","title":"Cosmos Hub Proposal 818 Post-Mortem - Equivocation Slashing Analysis","slug":"818-post-mortem","categories":["Engineering"],"authors":["Jehan Tremback"],"keywords":"\ncosmos-hub-proposal-818, equivocation-slashing, validator-double-signing, neutron-upgrade, governance-proposals, cryptographic-verification, interchain-security, cosmos-governance, slashing-proposals, validator-slashing","excerpt":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"What went wrong with the first equivocation proposal and preventing future issues.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"includeTableOfContents":true,"introduction":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"There has recently been a lot of discussion about Cosmos Hub proposal #818. This was the first use of the equivocation slashing proposal type, which is intended to slash validators who double sign on consumer chains.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Unfortunately, a lot went wrong with proposal #818, and while no funds were ever at risk, it wasted a lot of time and energy. In this post we will go over what happened, what we should have done differently, and why this won’t happen again.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"It’s important to note that equivocation slashing proposals are a temporary solution which will be retired soon when cryptographic equivocation verification is finished. When this is done, validators who double sign on consumer chains will be slashed immediately and automatically.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"body":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"What happened","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"The double sign","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"On August 1st, a consumer chain called Neutron had an upgrade. This upgrade ","nodeType":"text"},{"data":{"uri":"https://blog.neutron.org/neutron-halt-post-mortem-927dbe4540c8"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"had some issues","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" and resulted in a chain halt, and so validators felt under pressure to upgrade quickly. During this process, two validators deleted a file on their Neutron nodes which is supposed to prevent CometBFT from double signing. While the upgrade was rushed, it needs to be said that if the validators in question were following best practices, they wouldn’t have double signed.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The reason that double signs are not allowed is that by signing off on two alternate versions of history, a group of validators could try to pull off a double spend attack. For there to be any hope of this type of attack succeeding, 33% of validation power must participate. The two validators involved had around 0.2% of the power, and there is no question that the double signs were accidental.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The debate","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"A little bit more than a week later, a community member did a query on their Neutron node and noticed that the two validators had double signed during the upgrade. This community member quickly put up an equivocation slashing proposal, proposal #818.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"This proposal was contentious. Some voters thought that since ICS is new, and there was obviously no attack, validators should be cut some slack. Some thought that the rules are the rules, and changing them on the spur of the moment would set a bad precedent. This debate raged on until a new piece of information entered the arena.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The typo","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"Taking a closer look at the proposal, our team at Informal realized something - the proposal had an incorrect parameter. An equivocation slashing proposal takes a block height parameter, but this is intended to be a block height on the Cosmos Hub, not on the consumer chain. The creator of the proposal used the consumer chain block height. This is in our documentation, but it is also an understandable mistake to make.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The result of this mistake is that even if the proposal passes, it will not result in a slash.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We evaluated what would happen if someone were to create a corrected proposal, and concluded that it would be a bad idea. Due to the length of time that had already passed since the double sign, the math of which delegators to slash would be thrown off. Some delegators who had undelegated after the slash would get off with no slash, while those who remained would be slashed for more. This is because by the time the proposal passed, the unbonding period would have been over for a while.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"What went wrong, and how it could have been prevented","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"Problem: There was a debate about whether or not to slash","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"When we built the governance-gated slashing feature, it was intended to use governance as a filter to prevent consumer chains from going crazy and slashing everyone, since we did not yet have the code to cryptographically verify slashes. Our assumption was that the only slashes that would be voted down by governance would be ones that were obviously fake, and originated from malicious or malfunctioning consumer chain code. This is reflected in our writing about the feature, but we never explicitly stated what it should or shouldn’t be used for.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"However, another valid view is that the governance-gating could be used as “training wheels” while validators get used to the added load of ICS, and possibly be used to forgive accidental slashes. This wasn’t our intention, but it’s not crazy. Many systems, including Ethereum and Anoma try to mitigate the effect of slashing on accidental double signs.\n\nWhat is clear is that the voting period for an equivocation slashing proposal is not the right time to answer these questions. We should have worked more to build clear consensus and understanding about what the feature was to be used for at the time that it was introduced. This could have been done with a “constitution” that would be ratified along with the acceptance of the feature by governance. This could have spell out principles of what the feature was to be used for, as well guidelines of what to do in various scenarios (accidental double sign, attempted attack, malfunctioning consumer chain).","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Problem: Our documentation for how to create a slashing proposal was not as clear as it could have been, and our code did not reject obviously wrong proposals","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"You can read it and decide for yourself, but while our documentation discusses the theory and process for creating a slash proposal, it did not do a good enough job of providing step by step instructions. The issue in proposal #818 is that the proposal’s author used the consumer chain’s block height, not the provider chain’s block height. This is an easy mistake to make, and it could have been prevented by instructions like:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Get the consumer’s time of double signing from the consumer’s evidence.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Find out what the block height was on the provider at this time.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Use this block height and time to create the equivocation slashing proposal.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"ordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"In general, the UX to create an equivocation slashing proposal is not great, and that didn’t help either.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Additionally, our code could have done more validation of the parameters supplied in the proposal. This is not technically a risk, because it is not possible to supply a parameter that can crash the chain or anything. But we could have done some validation for obvious mistakes, like a block height that was far lower than the current block height, as in proposal 818. This is not foolproof, and wouldn’t work if the block heights on provider and consumer were close, but perhaps we could have rejected extremely wrong values to catch obvious mistakes at proposal submission time.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Problem: We did not have a system or procedure in place to create equivocation slashing proposals","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"When we designed the feature, we were thinking about preventing a worst case scenario in an attack. In this dramatic scenario, the submission of equivocation slashing proposals can be taken for granted. We did not think hard enough about ensuring that slash proposals were reliably created for ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"any","nodeType":"text"},{"data":{},"marks":[],"value":" slash, even accidental ones which cause no disruption.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Creating the slashing proposals automatically with complete reliability is difficult, but we (or other teams in the space) could have had a procedure in place to create them manually immediately upon detection of a double sign. This would have ensured that they were created in a timely manner and completely correctly.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Why this won’t happen again","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"There are many technical improvements that we could make to governance-gated slashing to make it more foolproof and give it a better UX. However, we will be focusing on different improvements. Automatic cryptographically verified equivocation slashing is almost ready, and will be deployed in Gaia v13, which should be live in mid-October. At this point, equivocation slashing proposals will be removed.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Making UX and governance improvements to governance-gated slashing couldn’t be deployed much sooner (at least not without delaying Gaia v12, which contains the Liquid Staking Module) so at this point devoting our time to those improvements would not be wise.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"While automatic verified slashing is in development and testing, we will work to prevent another 818-like situation if another validator accidently double signs on a consumer chain. Our team is monitoring for double signing evidence, and we will submit equivocation slashing proposals immediately as we come upon such evidence. By taking on this task we will make sure that any slashing proposals submitted before the feature is sunsetted are submitted properly. That being said, anyone else can submit these proposals as well.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"contentfulURL":"https://app.contentful.com/spaces/p79kctcd7ahy/entries/5aXf2TxkNGHpPR9CnBIKPM"},{"featureImage":"$4:props:posts:29:featureImage","date":"2023-08-09","title":"Cosmos Hub July 2023 Update - Gaia v11 Release and Stride Consumer Launch","slug":"cosmos-hub-engineering-update-july-2023","categories":["Engineering"],"authors":["Jehan Tremback"],"keywords":"cosmos-hub-july, gaia-v11-release, stride-consumer-launch, liquid-staking-module, comet-mock, replicated-security-v2, cryptographic-verification, atomic-ibc, liquidity-module-removal, consumer-chain-migration","excerpt":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Monthly update covering LSM integration progress and CometMock testing tool.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"includeTableOfContents":false,"body":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"It’s time for the July update from the ","nodeType":"text"},{"data":{"uri":"https://twitter.com/informalinc"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Informal Systems’","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" Cosmos Hub team! This month, the team helped ship the v11 release - upgrading Replicated Security and removing the legacy Liquidity module, to prepare for the upcoming Liquid Staking Module. We also supported Stride in launching as the Cosmos Hub’s second Consumer Chain - making history for being the first standalone appchain that migrated over to Interchain Security.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Liquid Staking Module review process","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"We’ve been working with the Stride team, the Cosmos-SDK team, the Iqlusion team, and others to finish ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/cosmos-sdk/pull/16747"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"the review process of the LSM","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", and integrate it for release on the Cosmos Hub in Gaia v12. Pending a few more fixes of issues raised by the Cosmos-SDK team and others, it will be ready to go into the v12 release soon.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Gaia v11 release","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"We cut a release of Gaia v11 and put it up for ","nodeType":"text"},{"data":{"uri":"https://www.mintscan.io/cosmos/proposals/804"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"voting","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". The target upgrade date, if the proposal passes, is ","nodeType":"text"},{"data":{"uri":"https://www.mintscan.io/cosmos/blocks/16596000"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"August 16th 2023","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Gaia v11 contains:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"An update of Replicated Security to v2.0.0","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"A refactored version of the Global Fee module","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Removal of the Liquidity module state with forced withdrawal for all pool coins as preparation to remove the module, in accordance with passed ","nodeType":"text"},{"data":{"uri":"https://www.mintscan.io/cosmos/proposals/801"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Proposal 801","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"You can find the ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/gaia/releases/tag/v11.0.0"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"release binary here","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", and the ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/gaia/blob/v11.0.0/CHANGELOG.md"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"full changelog here","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Launch of the Stride consumer chain","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"The launch of Stride went surprisingly well, considering it was the first time seeing the ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/interchain-security/blob/main/docs/docs/adrs/adr-010-standalone-changeover.md"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"standalone-to-consumer migration protocol","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" in action. The migration took 45 minutes in total and proceeded uneventfully.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The first version of CometMock","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"CometMock is a testing tool that simulates the ","nodeType":"text"},{"data":{"uri":"https://cometbft.com/"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"CometBFT consensus engine","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", but runs much faster and more deterministically, enabling us to dramatically reduce our run time from around 20 minutes to around 1 minute. You can take a look at the code ","nodeType":"text"},{"data":{"uri":"https://github.com/informalsystems/CometMock"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"here","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". We’re also working with ","nodeType":"text"},{"data":{"uri":"https://starship.cosmology.tech/"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Starship","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" to bring it into their Cosmos testing environment.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Cryptographic equivocation verification (double signing slashing)","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"Work continues on the code which will allow the Cosmos Hub to cryptographically verify instances of double signing. This is important because cryptographic verification will allow the Hub to immediately slash validators who misbehave on Consumer Chains, instead of the governance-gated process in use today, which requires a vote to verify the slashing. For more information, you can find the documentation ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/interchain-security/pull/1168"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"here","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", and the code is in progress ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/interchain-security/tree/feat/ics-misbehaviour-handling"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"in this branch","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Atomic IBC","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"We’ve been thinking about how Replicated Security can be used to build a moat, network effects, and differentiate itself in a crowded future of shared security. One possible option is atomic IBC – allowing Replicated Security Consumer Chains to compose seamlessly with one another using a special form of IBC that is instant, atomic (if one part of the transaction fails, it all fails), and isolated (nothing else changes while the transaction is running). There’s a lot of conversation happening about this, but the place to get up to date is the discussion ","nodeType":"text"},{"data":{"uri":"https://twitter.com/informalinc/status/1684579530898575360"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"here","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"About the Author","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"","nodeType":"text"},{"data":{"uri":"https://twitter.com/JTremback"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Jehan Tremback","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" is the product owner for the Cosmos Hub at ","nodeType":"text"},{"data":{"uri":"https://twitter.com/informalinc"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Informal Systems","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", where he works on exciting new features for the Hub.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"contentfulURL":"https://app.contentful.com/spaces/p79kctcd7ahy/entries/3XasQY6AYf0pbedbmzT48S"},{"featureImage":"$4:props:posts:50:featureImage","date":"2023-07-24","title":"Hermes v1.6 Release Adds WASM Relaying Support with Pull-Based Event Mode","slug":"releasing-hermes-v1-6","categories":["Engineering"],"authors":["Sean Chen"],"keywords":"hermes-v1.6, wasm-relaying, ibc-relayer, push-pull-modes, websocket-relaying, rpc-polling, hermes-relayer, neutron-support, event-batching, ibc-events","excerpt":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"New pull mode enables native WASM relaying through RPC polling alternative.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"includeTableOfContents":false,"body":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"The Hermes team has just released Hermes v1.6!","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Compared to the previous v1.5 release, this one is certainly smaller. The main feature included in this release is the addition of a “pull” mode alternative to the pre-existing “push” mode for fetching chain events. This feature allows Hermes to natively support WASM relaying, something that it has been unable to do until now. We’ll go into more detail on what these two modes mean, how they differ, and what their use-cases are.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Push-based relaying vs. pull-based relaying","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"The longstanding method that Hermes has used in order to catch chain events is by subscribing to a WebSocket endpoint that each chain exposes. We call this push-based relaying because the chain is making these events available and pushing them out; Hermes catches them as they become available.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"To go with a simple analogy, you can imagine that the chain’s WebSocket endpoint is like a faucet where water is streaming out; the chain events are analogous to the water coming out of the faucet. The Hermes supervisor, which is the component that is responsible for listening to WebSocket endpoints and catching the relevant events, is a bit like a cup or a bucket that sits under the running stream of water. Note though that there are events emitted from the WebSocket endpoint that the Hermes supervisor is not interested in, so it isn’t catching all of the water per se; this is where this analogy breaks down a bit. In a way, each chain is “pushing” events to Hermes.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"In contrast, pull-based relaying sees Hermes doing the work of polling events from chains’ ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"/block_results","nodeType":"text"},{"data":{},"marks":[],"value":" RPC endpoint. In this mode, the onus is on Hermes to query the chains for the relevant events, hence why it is known as “pulling”.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"From the testing that we’ve done, there doesn’t seem to be any marked difference performance-wise between the two modes. That being said, we have not at this point in time managed to extensively benchmark these two relaying modes against one another with different chain setups and relaying environments, so this assessment should be taken with a grain of salt.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"In general, we recommend continuing to utilize the WebSocket-based relaying mode. The RPC-based mode should be thought of as a backup for situations when Hermes is not picking up all the chain events that it should be, such as when relaying for WASM-enabled chains that emit IBC events that are missing the ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"message","nodeType":"text"},{"data":{},"marks":[],"value":" attribute. Without this attribute, the WebSocket is not able to catch these events to stream to Hermes, so the ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"/block_results","nodeType":"text"},{"data":{},"marks":[],"value":" RPC endpoint must be used instead.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Upgrading to Hermes v1.6","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"Hermes v1.6 introduces breaking changes to the Hermes configuration. In order to upgrade, you’ll need to remove the ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"websocket_addr","nodeType":"text"},{"data":{},"marks":[],"value":" config option from the Hermes ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"config.toml","nodeType":"text"},{"data":{},"marks":[],"value":" in favor of the new ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"event_source","nodeType":"text"},{"data":{},"marks":[],"value":" setting. This needs to be done in every chain configuration section.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"event_source","nodeType":"text"},{"data":{},"marks":[],"value":" parameter receives an inline table of values. In order to maintain the default behavior of receiving events via WebSocket, you can configure the ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"event_source","nodeType":"text"},{"data":{},"marks":[],"value":" setting like so:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"3igULI5PODAhjMPGXFqpaI","type":"Entry","createdAt":"2023-07-24T16:14:43.472Z","updatedAt":"2023-07-24T16:14:43.472Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":2,"revision":1,"contentType":{"sys":{"type":"Link","linkType":"ContentType","id":"codeSnippet"}},"locale":"en-US"},"fields":{"language":"javascript","code":"event_source = { mode = 'push', url = 'ws://127.0.0.1:26657/websocket', batch_delay = '500ms' }"}}},"content":[],"nodeType":"embedded-entry-block"},{"data":{},"content":[{"data":{},"marks":[],"value":"When configuring this mode, you’ll need to specify the URL of the WebSocket endpoint that Hermes listens to. You’ll also need to specify the ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"batch_delay","nodeType":"text"},{"data":{},"marks":[],"value":" parameter, which specifies the maximum amount of time between event batches that Hermes receives. In this mode, Hermes receives a new batch of events from a chain once the ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"batch_delay","nodeType":"text"},{"data":{},"marks":[],"value":" parameter has elapsed, or when a new block has been created on that chain, whichever occurs first.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"If you’d instead like to enable pull-based relaying over the ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"/block_result","nodeType":"text"},{"data":{},"marks":[],"value":" RPC, that can be done like so:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"55CPQN7BXuBHh803e62Gcu","type":"Entry","createdAt":"2023-07-24T16:14:23.035Z","updatedAt":"2023-07-24T16:14:23.035Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":2,"revision":1,"contentType":{"sys":{"type":"Link","linkType":"ContentType","id":"codeSnippet"}},"locale":"en-US"},"fields":{"language":"javascript","code":"event_source = { mode = 'pull', interval = '1s' }"}}},"content":[],"nodeType":"embedded-entry-block"},{"data":{},"content":[{"data":{},"marks":[],"value":"When this mode is enabled, you’ll need to specify the time interval in seconds that you would like Hermes to query the ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"/block_results","nodeType":"text"},{"data":{},"marks":[],"value":" RPC endpoint.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"In summary","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"With Hermes v1.6, Hermes is now able to natively support WASM relaying. Before the addition of this feature, chains that relayed WASM messages, such as Neutron, needed to introduce bespoke ","nodeType":"text"},{"data":{"uri":"https://github.com/neutron-org/wasmd/commit/297bdc7c582365ef60a45def4e7c631cbe5d2836#diff-171d7d96b1521ea0c90ca4c1d112065104dab4d6c1219f84f60a5c2dc3d28d6dR204-R205"},"content":[{"data":{},"marks":[],"value":"logic","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" to work around this limitation in Hermes. Going forward, these sorts of workarounds will no longer be necessary.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"This post certainly did not cover everything that came bundled in the v1.6 release. For the full list of everything included in the v1.6 release, please take a look at the ","nodeType":"text"},{"data":{"uri":"https://github.com/informalsystems/hermes/releases/tag/v1.6.0"},"content":[{"data":{},"marks":[],"value":"changelog","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"If you’d like to keep up with the Hermes team’s work, please follow the project on ","nodeType":"text"},{"data":{"uri":"https://github.com/informalsystems/hermes"},"content":[{"data":{},"marks":[],"value":"GitHub","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". You can also follow Informal System’s twitter account in order to receive updates on what every team at Informal is working on!","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"contentfulURL":"https://app.contentful.com/spaces/p79kctcd7ahy/entries/7kjzHXNZVg2TXgM12oD8U"},{"featureImage":"$4:props:posts:29:featureImage","date":"2023-07-18","title":"Cosmos Hub June 2023 Update - ICS v2 and v3 Releases with SDK 0.47","slug":"cosmos-hub-engineering-update-june-2023","categories":["Engineering"],"authors":["Jehan Tremback"],"keywords":"cosmos-hub-june, ics-v2-release, ics-v3-release, sdk-47-upgrade, gaia-v10-upgrade, stride-launch-support, liquid-staking-module, consumer-chains, cosmos-sdk-upgrade, ics-improvements","excerpt":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Monthly update covering Stride launch support and LSM collaboration progress.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"includeTableOfContents":false,"body":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"In June we finalized a lot of work that has been ongoing and cut several releases.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Released ICS v2","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/interchain-security/releases/tag/v2.0.0"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"ICS v2","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" is a release of ICS which integrates all of the improvements we have made to the protocol since it launched earlier this year, but does not include an upgrade to Cosmos SDK 0.47.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Released ICS v3","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/interchain-security/releases/tag/v3.0.0"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"ICS v3","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" contains all the improvements of ICS v2, but also upgrades the entire library to Cosmos SDK 0.47. This enables consumer chains running 0.47, like Stride, and also is a key step in getting the Cosmos Hub upgraded to Cosmos SDK 0.47 and future versions.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Gaia v10 upgrade","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"We covered some of the work involved in this upgrade in previous updates, but on June 21st, v10 went live. The upgrade was smooth and uneventful and the Cosmos Hub was back up in minutes.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Stride launch and LSM","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"We supported Stride during the preparations for their July launch, as well as working with Stride, Iqlusion, and Binary builders on a long term plan for LSM maintenance.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"contentfulURL":"https://app.contentful.com/spaces/p79kctcd7ahy/entries/7fhNcGgNJtkaTzV1mhdomq"},{"featureImage":"$4:props:posts:25:featureImage","date":"2023-06-20","title":"CometBFT v0.38 Release Candidate and Performance Analysis Results","slug":"cometbft-may-newsletter","categories":["Engineering"],"authors":["Ali Merchant"],"keywords":"cometbft-v0.38, abci-plus-plus, vote-extensions, performance-analysis, qa-testing, bandwidth-optimization, storage-architecture, consensus-performance, release-candidate, cometbft-qa","excerpt":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"QA insights on ABCI++ part 2 and vote extension performance impacts.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"includeTableOfContents":false,"body":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"New Release Candidate: 0.38.rc-1","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"We're thrilled to announce the arrival of CometBFT 0.38's latest release candidate, ","nodeType":"text"},{"data":{},"marks":[{"type":"code"},{"type":"bold"}],"value":"0.38.rc-1","nodeType":"text"},{"data":{},"marks":[],"value":"! This release introduces ABCI++ (part 2) and numerous enhancements and bug fixes to boost system stability and performance. To explore the release and its detailed changelog, visit ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/releases/tag/v0.38.0-rc1"},"content":[{"data":{},"marks":[],"value":"this link","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"QA Insights for 0.38","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"Our team has been hard at work ensuring the quality and reliability of CometBFT 0.38. Through extensive testing, we've compiled a comprehensive QA report, available ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/blob/v0.38.0-rc1/docs/qa/CometBFT-QA-38.md"},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"here","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". If you're new to the QA process conducted by the CometBFT team, we recommend reading our informative ","nodeType":"text"},{"data":{"uri":"https://informal.systems/blog/intro-qa-cometbft-v034"},"content":[{"data":{},"marks":[],"value":"blog post","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" on ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"QA for CometBFT","nodeType":"text"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"italic"}],"value":"Let's delve into some key insights from our QA process:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Performance","nodeType":"text"},{"data":{},"marks":[],"value":": The QA testing confirms that CometBFT 0.38 maintains performance levels without any observed degradation compared to version 0.37.0. This encouraging result assures users that the new release maintains optimal performance.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Impact of Vote Extensions (VE)","nodeType":"text"},{"data":{},"marks":[],"value":": Our evaluation revealed that the use of large vote extensions (VE) can noticeably affect the overall performance of CometBFT. We recommend that teams evaluate this impact based on their specific use cases. The CometBFT team is ready to assist teams in testing QA for VE, should they require support.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Demo App Stability","nodeType":"text"},{"data":{},"marks":[],"value":": The QA testing demonstrated the stability of the demo app, featuring CometBFTs ","nodeType":"text"},{"data":{},"marks":[{"type":"code"},{"type":"bold"}],"value":"PrepareProposal","nodeType":"text"},{"data":{},"marks":[],"value":" and ","nodeType":"text"},{"data":{},"marks":[{"type":"code"},{"type":"bold"}],"value":"ProcessProposal","nodeType":"text"},{"data":{},"marks":[],"value":", which remains unaffected by vote extension signature verification.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[{"type":"italic"}],"value":"These key insights provide an overview of the QA report, emphasizing the performance stability of CometBFT 0.38 while highlighting the potential impact of large vote extensions. We encourage teams to evaluate this impact in their specific use cases, and the CometBFT team is available to assist with testing QA for VE.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Q3 Prioritization","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"As we enter the third quarter, the CometBFT team has identified key problem statements that demand our attention:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"1. ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"Bandwidth consumption:","nodeType":"text"},{"data":{},"marks":[],"value":" We aim to optimize and reduce the expensive bandwidth usage in CometBFT. This optimization aligns with our discovery that Vote Extensions can impact performance. Reducing bandwidth consumption will alleviate this performance impact.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"2. ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"Storage architecture:","nodeType":"text"},{"data":{},"marks":[],"value":" We acknowledge the mismatches between CometBFT's storage backend capabilities and current production use cases. Our focus will be on addressing these issues, aiming to reduce the storage footprint and enhance the RPC capabilities of Comet, specifically the Data Companion API.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"3. ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"Technical Debt:","nodeType":"text"},{"data":{},"marks":[],"value":" Our team is committed to evolving the protos and versioned RPC while improving debuggability by cleaning up logs.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Bug Fixes!","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"While diligently pursuing our Q2 priorities, we've successfully resolved several bugs. Here's a brief summary of the fixes we've implemented:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Unsafe int cast in ","nodeType":"text"},{"data":{},"marks":[{"type":"code"},{"type":"bold"}],"value":"kill","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":" command\n","nodeType":"text"},{"data":{},"marks":[],"value":"We've fixed a critical bug in the kill command that previously caused unintended typecasting, leaving other processes vulnerable. The issue has been rectified, ensuring the security and stability of the system. You can find the fix ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/pull/783"},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"here","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"v0.37 pubsub/kvindexer\n","nodeType":"text"},{"data":{},"marks":[],"value":"An issue was raised regarding the improper parsing of ","nodeType":"text"},{"data":{},"marks":[{"type":"code"},{"type":"bold"}],"value":"BigInts","nodeType":"text"},{"data":{},"marks":[],"value":" in versions 0.34/0.37. We have addressed this problem and improved the handling of ","nodeType":"text"},{"data":{},"marks":[{"type":"code"},{"type":"bold"}],"value":"ints","nodeType":"text"},{"data":{},"marks":[],"value":" and ","nodeType":"text"},{"data":{},"marks":[{"type":"code"},{"type":"bold"}],"value":"floats","nodeType":"text"},{"data":{},"marks":[],"value":" in comparison operations. Previously, floats with fractions were mistakenly treated as integers. You can find the fixes for version 0.37 ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/pull/771"},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"here","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" and for version 0.34 ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/pull/840"},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"here","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".\n","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Community Updates","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"CometBFT has been actively collaborating with the wider engineering community, and we are delighted to share some recent highlights:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Team Comet has been in contact with several projects building on our software, including Vocdoni, dYdX, Vega Protocol, and dWallet. We have been gathering requirements and feedback from them to inform our roadmap.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"italic"}],"value":"If you’re a project building (or planning to build) on Comet, please reach out. We want to know what you’re building!","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"Events","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Gateway to Cosmos","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Adi, our Product Lead, delivered an insightful talk titled ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"\"When Comets Align.\"","nodeType":"text"},{"data":{},"marks":[],"value":" \nIn case you missed it, you can watch the recording of his talk ","nodeType":"text"},{"data":{"uri":"https://www.youtube.com/watch?v=IJRFpaN-Nl8"},"content":[{"data":{},"marks":[],"value":"here","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Feeling the urge to build something great? Ali, our DevRel expert, conducted a workshop on \"","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"Building Apps on ABCI.","nodeType":"text"},{"data":{},"marks":[],"value":"\" You can catch up on the workshop by watching the recording. (To be released soon.)","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"You can also see here in our Wiki a collection of all presentations and recordings related to CometBFT: ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/wiki/CometBFT-presentations"},"content":[{"data":{},"marks":[],"value":"https://github.com/cometbft/cometbft/wiki/CometBFT-presentations","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"ETHCC Paris","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Join us at EthCC, Paris, where Ali will deliver a captivating talk on CometBFT as a public good. Don't miss the opportunity to learn more about our innovative technology.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Other Events","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"CometBFT team members will also be in attendance at ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"Atom Berlin","nodeType":"text"},{"data":{},"marks":[],"value":" and ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"AwesomeWasm","nodeType":"text"},{"data":{},"marks":[],"value":" in July. We are excited to meet the community and learn about the exciting projects you are building.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"Shameless Plug","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Community Calls\n","nodeType":"text"},{"data":{},"marks":[],"value":"We strongly encourage all CometBFT contributors, users, and enthusiasts to join our bi-weekly community calls held on Thursdays. These calls provide an excellent opportunity to engage with our core team and fellow developers. Expect productive discussions and well-researched insights. Subscribe to our community call notifications ","nodeType":"text"},{"data":{"uri":"https://groups.google.com/g/cometbft-community/"},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"here","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Social Media\n","nodeType":"text"},{"data":{},"marks":[],"value":"For real-time updates and engaging content, make sure to follow us on ","nodeType":"text"},{"data":{"uri":"https://twitter.com/cometbft"},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Twitter","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". Stay in the loop and be part of the CometBFT community.\nIf you have any questions or need assistance, feel free to reach out to us on ","nodeType":"text"},{"data":{"uri":"https://t.me/CometBFT"},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Telegram","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" or ","nodeType":"text"},{"data":{"uri":"https://discord.com/invite/cosmosnetwork"},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Discord","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". We are here to help!","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"},{"type":"italic"}],"value":"Thank you for being a part of the CometBFT community. Stay tuned for more exciting updates in the next edition.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"contentfulURL":"https://app.contentful.com/spaces/p79kctcd7ahy/entries/3M9XQFrGLv1DPDYdtkuvSQ"},{"featureImage":"$4:props:posts:29:featureImage","date":"2023-06-14","title":"Cosmos Hub May 2023 Update - Gaia v10 Upgrade and Liquidity Module Removal","slug":"cosmos-hub-engineering-update-may-2023","categories":["Engineering"],"authors":["Jehan Tremback"],"keywords":"cosmos-hub-may, gaia-v10-upgrade, liquidity-module-removal, comet-mock, stride-preparation, sdk-47-upgrade, ics-v2, gravity-dex-removal, documentation-updates, validator-feedback","excerpt":{"nodeType":"document","data":{},"content":[{"nodeType":"paragraph","data":{},"content":[{"nodeType":"text","value":"Monthly development recap covering CometMock testing and Stride preparation.","marks":[],"data":{}}]}]},"includeTableOfContents":true,"body":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Gaia V10 upgrade","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"The v10 upgrade contains no new features, but simply upgrades a number of Gaia’s dependencies. This is to ensure that all the software that goes into Gaia is as up to date as possible. Some of the upgrades:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Upgrade ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/cosmos-sdk"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Cosmos SDK","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" to ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/cosmos-sdk/releases/tag/v0.45.16-ics"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"v0.45.16-ics","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Upgrade ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/ibc-go"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"IBC GO","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" to ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/ibc-go/releases/tag/v4.4.0"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"v4.4.0","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Upgrade ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"CometBFT","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" to ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/releases/tag/v0.34.28"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"v0.34.28","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Upgrade ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/gaia/pull/2499"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Golang prerequisite from 1.18 to 1.20","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Liquidity module removal","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"The liquidity module is the module that enables Gravity DEX, but it has not been used in a long time. Together with developers from Crescent, we made a plan to remove it, while restoring unwithdrawn balances to their owners. Much thanks to the ","nodeType":"text"},{"data":{"uri":"https://crescent.network/"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Crescent Network","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"’s developers for their prompt and well thought out plan and implementation. Proposal appears ","nodeType":"text"},{"data":{"uri":"https://www.mintscan.io/cosmos/proposals/801"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"here","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"CometMock","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"We worked on CometMock, which will allow end to end tests to run much more quickly and predictably by simulating CometBFT deterministically and without network overhead. During May we worked out some of the last kinks to make it ready for the first step of integration into our testing tool. Check it out ","nodeType":"text"},{"data":{"uri":"https://github.com/p-offtermatt/CometMock"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"here","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Stride","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"We’ve been supporting the ","nodeType":"text"},{"data":{"uri":"https://stride.zone/"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Stride team","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" in moving towards their first testnets and launch as a consumer chain.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"SDK 47 upgrades","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"With the help of ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/interchain-security/pull/869"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Notional","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" and ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/interchain-security/pull/970/files"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Thomas Bruyelle","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", we completed an upgrade of Interchain Security to version 47 of the Cosmos SDK. We also started on an upgrade of the Cosmos Hub software, Gaia.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Interchain Security v2","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"We’ve been working on the v2 release of Interchain Security. This consolidates all the work that has been done since v1 was released, including soft opt out, sovereign to consumer migration, and various bugfixes.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Gaia Documentation","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"During Q2 and Q3, the Gaia documentation will be going through a number of updates. To that end, we’ve reached out to a number of validators to understand their documentation needs and to identify any areas that are not sufficiently covered in the current documentation. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The Hub team would like to thank the following validators who participated in the research sessions and provided valuable feedback: ","nodeType":"text"},{"data":{"uri":"https://ccvalidators.com/"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"CryptoCrew","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", ","nodeType":"text"},{"data":{"uri":"https://www.coinbase.com/"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Coinbase","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", ","nodeType":"text"},{"data":{"uri":"https://notional.ventures/"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Notional","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" and ","nodeType":"text"},{"data":{"uri":"https://www.a41.io/"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"A41","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"If you have feedback about the documentation that you would like to share, please fill in the following ","nodeType":"text"},{"data":{"uri":"https://docs.google.com/forms/d/e/1FAIpQLScJg1fs7GKQP82n5W2fNKbRDpQTxUySdGv90oym4PxVy2YSaw/viewform"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"survey","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". The survey will take approximately 5-10 minutes to complete.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"contentfulURL":"https://app.contentful.com/spaces/p79kctcd7ahy/entries/3OEcWhQxyM2xtKLgJ5BjqV"},{"featureImage":"$4:props:posts:50:featureImage","date":"2023-06-08","title":"Hermes v1.5 Performance Tuning - Fine-Grained Control and Batch Optimization","slug":"finer-grained-control-over-hermes-performance-with-v1-5","categories":["Engineering"],"authors":["Sean Chen"],"keywords":"hermes-v1.5, relayer-performance, batch-delay, trusted-node, packet-clearing, osmosis-hub-channel, event-batching, client-updates, relaying-optimization, hermes-tuning","excerpt":{"nodeType":"document","data":{},"content":[{"nodeType":"paragraph","data":{},"content":[{"nodeType":"text","value":"New batch_delay and trusted_node parameters improve relaying throughput.","marks":[],"data":{}}]}]},"includeTableOfContents":false,"body":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"The newest major version of the Hermes relayer has been released! 🎉","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Improving Hermes’ relaying performance was one of the main goals of this release. To that end, the Hermes team did a spectacular job triaging, profiling, ideating, implementing, and testing a number of different ways of improving Hermes’ performance.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"These changes resulted in relayer operators seeing significant increases in the number of packets they were able to relay, especially on well-trafficked channels such as the Osmosis-Hub channel which many transactions are relayed through.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"New Performance-tuning Parameters","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"One realization that cropped up from talking to multiple relayer operators is that every blockchain network presents different characteristics that have an effect on relayer performance. Thus, there is no one-size-fits-all configuration that holds true in every relaying use-case; the relaying environment is a major consideration to take into account when tuning Hermes for relaying on a particular network.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Based off of this fact, Hermes v1.5 introduces some additional configuration parameters that give relayer operators more fine-tuned control over their Hermes instances. The idea is that tuning these parameters will allow operators to further optimize Hermes for their particular relaying use-cases and performance needs.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Eliminating latency variability when broadcasting event batches","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"The first of these parameters is ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"batch_delay","nodeType":"text"},{"data":{},"marks":[],"value":". Prior to introducing this parameter, batches of events were sent to the supervisor in response to every ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"NewBlock","nodeType":"text"},{"data":{},"marks":[],"value":". This introduced a variable amount of latency in the relaying process, as ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"NewBlock","nodeType":"text"},{"data":{},"marks":[],"value":"s were not always received consistently. Hermes v1.5 changes this behavior so that event batches are sent after a specified delay in addition to on ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"NewBlock","nodeType":"text"},{"data":{},"marks":[],"value":" events. This eliminates the variability when sending event batches, as batches are now always broadcast no later than the ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"batch_delay","nodeType":"text"},{"data":{},"marks":[],"value":" period.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"One relayer operator who helped us test the effects of this parameter saw a pronounced increase in the number of packets they were able to relay on the Osmosis-Hub channel 141, one of the most well-trafficked channels in the ecosystem.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"58zuoYSCgEAjUEnDCsZLP6","type":"Asset","createdAt":"2023-06-08T14:51:42.783Z","updatedAt":"2023-06-08T14:51:42.783Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":5,"revision":1,"locale":"en-US"},"fields":{"title":"blog-shawnr-dominating-batch-delay","description":"","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/58zuoYSCgEAjUEnDCsZLP6/bb2da793a63214cc9f3d0b489847b4ee/image_1_.png","details":{"size":542545,"image":{"width":2000,"height":829}},"fileName":"image(1).png","contentType":"image/png"}}}},"content":[],"nodeType":"embedded-asset-block"},{"data":{},"content":[{"data":{},"marks":[],"value":"Decreasing the batch delay value, however, comes with the tradeoff of higher relaying costs in exchange for the benefit of faster event processing. This is because a lower delay value can cause events to be split across multiple batches, rather than including them all within a single batch. More batches being sent means more client updates will need to be performed, thus incurring additional costs that might not have been required if the events were batched together more efficiently.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Currently, the default ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"batch_delay","nodeType":"text"},{"data":{},"marks":[],"value":" is set to ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"500ms","nodeType":"text"},{"data":{},"marks":[],"value":", which provides a good balance between speed and reliability, while still minimizing the number of client updates that need to be sent. In the case of this operator, they found that ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"250ms","nodeType":"text"},{"data":{},"marks":[],"value":" ended up striking the right balance between relaying latency and fees.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"If you prioritize processing speed and can tolerate the potentially higher relaying costs, then setting a lower ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"batch_delay","nodeType":"text"},{"data":{},"marks":[],"value":" value could be beneficial for your use case. In situations where relaying latency is not as important, such as if you’re running a backup relayer instance, then a higher ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"batch_delay","nodeType":"text"},{"data":{},"marks":[],"value":" value would be more suitable.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Again, it should be noted that there is no magic number when it comes to ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"batch_delay","nodeType":"text"},{"data":{},"marks":[],"value":", or indeed any Hermes configuration parameters. It is important to consider the environment in which you are operating within, and to play around with these parameters to see what combination of configuration values yields the desired performance you’re going for.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Configuring whether a node should be trusted","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"Hermes v1.5 also introduces the ability to configure whether the full node that a Hermes instance is connected to should be trusted or not via the ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"trusted_node","nodeType":"text"},{"data":{},"marks":[],"value":" parameter; by default, Hermes does not trust any full node it connects to. If a node is untrusted, that means the light client will perform an extra step to verify the headers included in the ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"ClientUpdate","nodeType":"text"},{"data":{},"marks":[],"value":" message in order to ensure that they are valid.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"This validation step can be skipped by setting ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"trusted_node = true","nodeType":"text"},{"data":{},"marks":[],"value":". This leads to faster processing of ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"ClientUpdate","nodeType":"text"},{"data":{},"marks":[],"value":" messages, though it also comes with some downsides. Most notably, client updates may fail without the validation step. This risk is most prominent after any significant changes in validator sets. More specifically, if more than a third of the validators that validated the last trusted header have been swapped out, then client updates will very likely no longer be valid.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"It should be noted that sending invalid client updates does not present a security vulnerability. The invalid updates will be reverted with future client updates, but this will cost additional fees, as well as incur additional latency on account of more transactions having to be sent.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Ultimately, it is recommended that nodes be considered untrusted except in the case where a Hermes user has full control of the full node that Hermes is connected to such that verifying headers is most likely redundant.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Improving Hermes’ packet clearing latency","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"We also uncovered a bug that occurred when Hermes would query the chain for packet acknowledgements, which happens whenever Hermes clears pending packets (both on-start, and periodically afterwards). Specifically, this query would oftentimes return so much data that it caused an error by overstepping the message decoding limit set by one of Hermes’ dependencies (4MB in this case).","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The packet acknowledgement query asks the chain for an acknowledgement for each packet commitment on the counterparty chain. It turned out that in the case when there were no outstanding packet commitments, the query would actually return ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"all","nodeType":"text"},{"data":{},"marks":[],"value":" packet acknowledgements on the chain. This was what was causing the query to return too much data. Even if this query did not end up overstepping the 4MB message decoding limit, it also resulted in slow start-up times, as Hermes would be fetching a bunch of unnecessary data from the chains.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The query now works correctly, i.e., if there are no outstanding packet commitments on the counterparty chain, then no packet acknowledgements are fetched. This has the effect of speeding up the packet clearing process, and thus the on-start scanning process when Hermes first boots up.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"In Summary","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"Hermes v1.5 also includes a slew of other improvements to how it handles misbehavior evidence, as well as to its profiling capabilities. We won’t be going into details on those. If you’d like to learn more, please take a look at the Hermes v1.5 ","nodeType":"text"},{"data":{"uri":"https://github.com/informalsystems/hermes/blob/v1.5.0/CHANGELOG.md"},"content":[{"data":{},"marks":[],"value":"changelog","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" for a comprehensive list of everything that is included in this exciting release.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"If you’d like to keep up with the Hermes team’s work, please follow the project on ","nodeType":"text"},{"data":{"uri":"https://github.com/informalsystems/hermes"},"content":[{"data":{},"marks":[],"value":"GitHub","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", as well as Informal System’s ","nodeType":"text"},{"data":{"uri":"https://twitter.com/informalinc"},"content":[{"data":{},"marks":[],"value":"twitter","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", where we post updates for what every team, not just Hermes, is working on!","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"contentfulURL":"https://app.contentful.com/spaces/p79kctcd7ahy/entries/41x5AhuZTUNmJkskvc5HPs"},{"featureImage":"$4:props:posts:30:featureImage","date":"2023-06-06","title":"Cosmos Hub Development Roadmap - Replicated Security and Mesh Security Evolution","slug":"cosmos-hub-living-roadmap","categories":["Engineering"],"authors":["Jehan Tremback"],"keywords":"cosmos-hub-roadmap, replicated-security, mesh-security, opt-in-security, cryptographic-verification, fraud-proofs, seamless-onboarding, epochs-feature, interchain-security-future, layered-security","excerpt":{"nodeType":"document","data":{},"content":[{"nodeType":"paragraph","data":{},"content":[{"nodeType":"text","value":"Living roadmap covering cryptographic verification and opt-in security features.","marks":[],"data":{}}]},{"nodeType":"paragraph","data":{},"content":[{"nodeType":"text","value":"","marks":[],"data":{}}]}]},"includeTableOfContents":true,"introduction":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"This is our living roadmap for ongoing work that Informal is doing on the Cosmos Hub. We’ll update this as we complete items, add new items, and remove items that may no longer be necessary. This is intended to give a general overview of our ongoing work and priorities.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"What’s included:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Work that is in the deployment, implementation, or later design phases","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Work that is being done by the Informal Systems Cosmos Hub team","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"What’s not included:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Work that has already been completed","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Ideas that are in the early design phase","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Work on the Cosmos Hub being done by teams outside of Informal","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"body":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Replicated Security improvements","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"There are a long list of improvements that we would like to make to Replicated Security. These range from fundamental changes to the protocol, to minor code cleanup tasks. These improvements will make Replicated Security safer, while also reducing the load on validators and governance. Ultimately, this will let more consumer chains be deployed more quickly and easily, increasing fees going to the Cosmos Hub.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Seamless consumer chain onboarding and offboarding","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"We want it to be possible for standalone chains to onboard smoothly as consumer chains without having to manually update their IBC connections to other chains. We also want it to be possible for consumer chains to offboard to other forms of security without having to manually update IBC connections. Offboarding is a little bit more complicated since we also have to answer the question of what the new validator set will be. Additionally, enabling offboarding to mesh security is a major strategic goal, and something that consumer chains are already expecting.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Cryptographic verification of equivocation evidence","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"As designed, ICS trusts consumer chains to honestly report equivocation by their validators by sending slash packets. This is OK in theory for Replicated Security if consumer chain code is well audited, but if there is an exploit in the code, it could slash validators unfairly. However this doesn’t work at all for opt-in security or mesh security because there is less oversight on what security is being used for. Because of the concerns about this we have several mitigations in place: a throttle that doesn’t let too many slash packets through at once, and we have gated this slashing behind a governance proposal, so that the proposal must pass after the slash packet is received.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"These mitigations prevent any serious issues but it would be nice not to have to rely on them. In theory it is possible to cryptographically verify equivocation evidence on the provider chain. This is not trivial, but much of the work may already be done in IBC-Go and Hermes relayer.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Cryptographic verification of downtime","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"In Replicated Security, validators are jailed on the provider chain if they are down on any consumer chain. Currently, this is also done by trusting a jailing packet from the consumer chain, but this has the same potential for issues as trusting equivocation slashing packets. However, we have implemented a throttling mechanism which should stop a catastrophic attack.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"It would be better to have some form of cryptographic verification of downtime on consumer chains so that no throttling is needed.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Epochs","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"Currently, Replicated Security requires a packet to be sent from the provider to the consumer and back for every block which contains a validator power change caused by a user delegating, undelegating, or redelegating. This is not a huge problem in normal operation, but can become an issue if there is a backlog of packets and can be expensive. It should be possible for the protocol to work with packets sent much less frequently, perhaps around once an hour or even once a day.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Interchain security future","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"We need to keep innovating to ensure that the Cosmos Hub is not only a pioneer of interchain security, but also remains a leader long term. While the ideas in this section are in a defined design stage, they are comparatively less well-defined than previous sections of this document. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Opt-in security","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"The ","nodeType":"text"},{"data":{"uri":"https://informal.systems/blog/replicated-vs-mesh-security#risks-of-opt-in-security-also-known-as-ics-v-2"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"validator opt-in subset problem","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" is avoided if consumer chains are fraud-provable. With fraud proofs, we can be certain that if the validators validating a consumer chain have (for example) $10m staked on the provider, that chain cannot be attacked without that $10m being slashed. This is not the case without fraud proofs.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"By making consumer chains fraud-provable, we can enable opt-in security. Opt-in security allows each validator to decide whether or not to validate a certain consumer chain.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"What is the difference between opt-in security and a rollup settlement layer as envisioned by Celestia, Ethereum, and others? Both use fraud proofs. With rollups, a mandatory waiting period on cross-chain transactions from the rollup allows any fraud to be rolled back with a fraud proof before any assets are permanently stolen.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"This waiting period is a huge complicating factor for any cross-chain application development on a rollup. Opt-in security removes this waiting period by slashing validators who commit fraud instead of making users wait for withdrawals.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Alternatives to fraud proofs","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"Fraud proofs are exciting, but are still an area of ongoing development. There are very few functioning implementations, and nothing that works with Cosmos-SDK yet, as far as we know.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"But there are alternatives to a full and efficient fraud-proving Cosmos-SDK VM. For example, a governance proposal could be used to slash validators who attack a consumer chain. This needs careful consideration. This could allow the Cosmos Hub to ship this valuable technology more quickly, but some may be uncomfortable with such a governance proposal.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Mesh security","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"Mesh security is an elegant solution to enable what we refer to as Layered Security (ICS v3). Given that this has always been a long term goal for interchain security, mesh security should be a key focus for us. Also, mesh security will likely be a big presence in the interchain security space. The Cosmos Hub has the potential to be a leader in providing mesh security, and so we should make sure we are involved from day one to support the adoption of mesh security.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"However: ","nodeType":"text"},{"data":{},"marks":[],"value":"Like Opt-in Security, Mesh Security is not secure without fraud proofs or an alternative to fraud proofs.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Analysis and implementation of mesh security","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"Our team has already informed the creation of mesh security. We did the first and only ","nodeType":"text"},{"data":{"uri":"https://informal.systems/blog/replicated-vs-mesh-security"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"analysis","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" of how much economic security mesh security will actually provide in various scenarios. Given that the *only* thing that mesh security provides is economic security (versus the full-service validator set provided by Replicated Security and Opt-in Security), this analysis is foundational to the concept.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We will stay involved in the design and implementation of mesh security, both to ensure that it is secure enough to run on the Cosmos Hub, and so that we have in-house expertise allowing us to lead adoption.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Display cost to censor and cost to control on block explorers","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"Before we introduced the cost to censor/cost to control analysis of mesh security, nobody had any idea how much security it would even provide. Since the only thing that mesh security provides is economic security, this information is key. The Cosmos Hub also benefits from this key security information being displayed publicly because the Cosmos Hub has so much security to provide. Users having the ability to check the security of mesh secured chains will tend to lead chains to consume security from the Cosmos Hub because it will improve their cost to censor and cost to control by a lot.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"To this end, we will maintain relationships with prominent block explorers, and provide them assistance and code to display the security of mesh secured chains prominently on their dashboards.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Mesh security chain launch platform","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"The Cosmos Hub could be a great platform for mesh-secured chains to launch on. It could leverage its large high stake and mature validator set to get consumer chains started off right. By submitting a governance proposal (or even a transaction) on the Cosmos Hub, a chain could provide a place for validators to sign up to join its validator set and for delegators to delegate to those validators. When the chain launched, it would have a validator set, as well as a large amount of security from all the assets staked on it from the Hub. It could then go out and get mesh security from other chains as well.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"contentfulURL":"https://app.contentful.com/spaces/p79kctcd7ahy/entries/7ApTH3icki8f2VgNs71jtI"},{"featureImage":"$4:props:posts:29:featureImage","date":"2023-06-01","title":"Neutron Consumer Chain Launch Analysis and Engineering Challenges","slug":"hub-engineering-update-april-may-2023","categories":["Engineering"],"authors":["Jehan Tremback"],"keywords":"neutron-launch, first-consumer-chain, multisig-fixes, key-assignment, replicated-security, unbonding-mechanics, vsc-packets, emergency-upgrade, standalone-migration, oak-audit\n","excerpt":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"First ICS chain launch retrospective covering multisig fixes and unbonding mechanics.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"includeTableOfContents":true,"introduction":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Hub Engineering Update & First Consumer Chain Launch","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"It’s time for an engineering update from ","nodeType":"text"},{"data":{"uri":"https://informal.systems/"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Informal Systems’","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" Cosmos Hub team!","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Utilizing Replicated Security for the first time, Neutron officially launched as a consumer chain on May 11th. This update covers the engineering update for the period Apr-May’23 - which included the Neutron launch!","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"body":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"The First ICS Chain! - Neutron Launch Retro","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"Launching consumer chains has been done a huge number of times in testnets and in fact, is done hundreds of times a week in our automated tests. Typically, the technical details of a consumer chain launch are too boring to write about. However, real life is inevitably different from testing. We had a few complications during the Neutron launch, but nothing that caused any permanent issues, and the issues shouldn’t reoccur for future launches. I’ll recap the launch and the complications here.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Note: when I say “we” in this post, I am not referring only to the Informal team. It was an effort of many teams led by Neutron, including us, the ICF, Hypha, Strangelove, CryptoCrew, and of course the entire validator set. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Multisig issues reported and fixed - April 25th - May 4th","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"A couple of weeks before the launch, we began receiving reports that validators were having trouble using multisigs and Ledger devices to sign key assignment transactions. By default, validators use the same keys on consumer chains as they do on the Hub, but it is considered a good security practice to use a different key for consumer chains, and this is what key assignment transactions let you do.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"It turned out that Ledger devices and multisigs were not able to sign key assignment transactions because of complications involving Amino, a data format that has been largely removed from Cosmos, but is still used in Ledger devices and multisigs. Fixing this involved a small change in format of key assignment transactions.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We finished this change around May 4, the week before launch, and sent out notice of an emergency upgrade to be performed on Monday, May 8th, the original scheduled date of the Neutron launch. This upgrade also contained a fix for a bug that could potentially halt the Hub.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Hub emergency upgrade - May 8th","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"The Neutron team wisely decided to postpone their launch for a few days, to Wednesday the 10th, to avoid complicating the upgrade. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The upgrade on Monday went relatively smoothly, with minimal downtime and no major incidents. Immediately after the upgrade, validators were able to use the key assignment transaction from their multisigs and Ledger devices. Thanks to the team at Notional for consulting with Neutron on postponing the launch, and helping to coordinate the upgrade!","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"However, Neutron’s “spawn time” was on Monday, even though their actual launch was delayed. At the spawn time, the IBC client and genesis file for the consumer chain are created on the Hub, and after this point, they cannot be changed. All validators who had not been able to use the key assignment transaction before the fix were in the genesis file with their Hub keys.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"This means that to run Neutron, they would need to put their Cosmos Hub keys on their Neutron validator. This is not a problem for the software, but for operational security, most validators would prefer not to be moving keys around on different computers.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Neutron launch - May 10th - May 11th","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"We did the Hub emergency upgrade so quickly because we didn’t want the validators who weren’t able to assign keys to be unfairly punished for downtime. However, we soon realized that we might have a bigger problem. A very large number of validators had not been able to assign keys before spawn time, and after spawn time, the genesis was locked in. Key assignments could still be done, but they would only take effect after Neutron had started.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"You need at least 67% of the Hub validators to run a replicated security consumer chain in order for it to start. This 67% would need to come from the validators who weren’t using multisigs or Ledgers, or from validators who were willing to temporarily run the consumer chain with their Hub keys. With a lot of outreach over the 10th, we were able to put together enough power to get the chain started, although it took many hours. Thanks to all the validators who helped us out here.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We decided to wait till the next day before starting the relayer though. Once the relayer started, it would start catching up on all the replicated security packets that update the consumer chain’s validator set. These packets would update the keys for validators who had used the consumer key assignment transaction after Monday’s spawn time. This is a good thing, but our concern was that it could be possible for validators who had helped us out by using their Hub key instead of their consumer key could be knocked offline once the keys were updated. Since we were running on such a bare majority, this could cause a halt. We wanted to have as many people as possible online and well-rested to help deal with this.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"On the 11th, we had some difficulties getting relayers to start which are too boring to get into here. But once the relayers were up and running, packets started going through very quickly, and the chain got synced up. Neutron is now the first Replicated Security consumer chain, secured by the Cosmos Hub.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"A note on unbonding ","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"Some users unbonded their staked ATOMs during the Neutron Launch window (May 8th - May 11th). These tokens will be fully unbonded on May 31st. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Neutron officially became a consumer chain on May 8th. This is known as its spawn time. However, it did not start running until May 11th. When it started, it received all the VSC packets for unbondings that happened after the spawn time, and started the unbonding period countdown of 20 days. 20 days after the 11th is the 31st, and so this is when the unbonding period of all VSC packets received on the 11th will complete.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"How does unbonding work with Replicated Security?","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"A core part of the Replicated Security protocol is the preservation of the consumer chain’s unbonding period in all circumstances. This is done in a simple way: ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"When a user sends an unbonding transaction, a record of the pending unbonding operation is created.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"This unbonding operation can complete when two conditions are met:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"21 days have passed on the Cosmos Hub.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Every consumer chain reports that their unbonding periods have also passed.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"ordered-list"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"At the end of the block that the unbonding was begun, a validator set change packet (VSC packet) is sent to all consumer chains. This contains the power change caused by the unbonding, and any other power changes from that block.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Once the consumer chain receives the validator set change packet, it begins its own unbonding period countdown. On Neutron, the unbonding period is 20 days.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"After this period has elapsed, the consumer chain sends a VSC matured packet to the Cosmos Hub.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Now any corresponding unbonding operations can complete, once the Hub’s unbonding period has also passed.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"ordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"This protocol guarantees that no matter what, the consumer chain’s unbonding period is respected.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"How can this be avoided in the future?","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"While this mechanism does guarantee the security of consumer chains to the highest degree, delays in unbonding can be inconvenient and should probably be avoided. It should be noted that a consumer chain cannot delay unbonding forever. If a consumer chain has delayed unbonding for more than 5 weeks, it will be removed from the Cosmos Hub and all unbondings will be released.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"To avoid the type of minor delay discussed here, the easiest way is to reduce the unbonding period on consumer chains. To illustrate, if consumer chain unbonding periods were one week shorter than the Cosmos Hub’s unbonding period, then a consumer chain would need to be stopped for one week before any unbondings were delayed on the Hub. This theoretically reduces the security somewhat, but most likely not in a meaningful way.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We’re also studying the protocol to see if it may be possible to eliminate the mechanism of unbonding pausing altogether. This will likely require making the assumptions that clocks are always synchronized, and making the security of consumer chains harder to quantify exactly, but it may be worth it.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Other Engineering Updates","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"Much of the work in April and May was focused on preparing for and launching the first consumer chain, Neutron. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Soft opt-out","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"Neutron chose to launch with the soft opt out feature discussed in the last update, which allows the smallest 5% of validators on the Hub to opt out of running the consumer chain. We went ahead and implemented it in time for the Neutron launch: ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/interchain-security/pull/833"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"#833","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Completed standalone to consumer migration code","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"The standalone to consumer migration will allow chains who are currently running standalone to become consumer chains. Stride will use this during their launch. We’ve been working on this with Stride over the past few months, but in April we merged it: ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/interchain-security/pull/757"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"#757","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/interchain-security/pull/794"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"#794","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/interchain-security/pull/832"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"#832","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Oak Audit review","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"Oak Security was recently funded to do an audit of Interchain Security by the ","nodeType":"text"},{"data":{"uri":"https://www.mintscan.io/cosmos/proposals/687"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Cosmos Hub community pool","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". We received their initial report, reviewed and discussed it with the audit team. They found some issues where a malicious consumer chain could potentially halt the Cosmos Hub, but this is within the current security model of Replicated Security. We are fixing these issues and others to move towards an “untrusted consumer chain” paradigm, but this work is ongoing.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"One of the issues that Oak Security identified was where an attacker could halt a consumer chain by creating millions of spam denoms (token types). This issue was very similar to one that we had already been investigating on the provider chain side of ICS. We can now confirm that these issues have been addressed and fixed on both the Cosmos Hub and Neutron.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Neutron testnet and fixes","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"In the Neutron testnet, we found a bug where multiple key assignment messages could cause a halt on the consumer (this was also found in the Oak audit a few weeks later). We fixed this issue on both the consumer and the provider: ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/interchain-security/pull/850"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"#850","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/interchain-security/pull/846"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"#846","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Multisig issue","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"At the end of the month, we began receiving reports that key assignment wasn’t working for validators using multisigs and Ledger devices. We began work on a fix for this issue by slightly modifying the format of the key assignment transaction.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Preparing for emergency upgrade","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"We started preparing for an emergency Hub upgrade containing the denom and multisig fixes discussed above. Most of the work on this upgrade happened in May though. We’ve posted about it elsewhere but I won’t cover it here since it will be in the May update. Spoiler alert: it went pretty smoothly.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"contentfulURL":"https://app.contentful.com/spaces/p79kctcd7ahy/entries/3nmmv57NVvDRf4Zi4Z7joU"},{"featureImage":"$4:props:posts:0:featureImage","date":"2023-05-25","title":"Neutron Becomes First Cosmos Hub Consumer Chain Using Interchain Security","slug":"informal-helps-launch-first-consumer-chain","categories":["Engineering"],"authors":["Sean Chen","Matthew McGrath","Tesnim Abdellatif"],"keywords":"neutron-launch, first-consumer-chain, interchain-security, cosmos-hub-validators, protocol-design, hermes-relaying, validator-coordination, security-audit, collaborative-launch, consumer-chain-milestone","excerpt":{"nodeType":"document","data":{},"content":[{"nodeType":"paragraph","data":{},"content":[{"nodeType":"text","value":"Collaborative effort launches ecosystem milestone with protocol design and implementation.","marks":[],"data":{}}]}]},"includeTableOfContents":false,"body":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Wednesday, May 10th marked the launch of","nodeType":"text"},{"data":{"uri":"https://neutron.org/"},"content":[{"data":{},"marks":[],"value":" ","nodeType":"text"},{"data":{},"marks":[{"type":"underline"}],"value":"Neutron","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", the first replicated security consumer chain that is secured by the Cosmos Hub’s entire set of validators. This milestone is the culmination of approximately two years of work on the Interchain Security protocol by many teams collaborating toward the shared goal of making the Cosmos Hub more sustainable. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Interchain Security serves to lower the barrier to entry for new chains into the Cosmos ecosystem by enabling producer chains, i.e., existing Cosmos Hub validators, to produce blocks for consumer chains, i.e., chains that seek the high level of security offered by the Hub’s validators, without having to bootstrap their own validator set.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The launch of Interchain Security was undoubtedly one of the most monumental tasks undertaken by the Cosmos ecosystem; it was certainly a task that required a greater degree of collaboration than any prior undertaking. For that, there are so many people, teams, and parties to acknowledge and thank for the success of this launch. Apart from Informal Systems that led the work, there are many organizations that have contributed to the project: the ICF, the IBC team at Interchain GmbH, the Cosmos SDK team, DCL lab at EPFL, All in Bits, Hypha, Strangelove, CryptoCrew, Notional, Architect Nodes. The Cosmos Hub was built for the community, by the community and we are proud to collaborate with some of the best minds in the space.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Here, we will also take the time to delve a bit more deeply into the respective contributions of the teams at Informal who helped make the launch a success. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Protocol Design Team","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"Everything starts with protocol design.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The Protocol Design team at Informal was responsible for coming up with the initial specification of the Interchain Security protocol. This work was critical for rallying the Cosmos ecosystem around a shared goal: to lay a solid bedrock foundation upon which myriad dev teams in the ecosystem could build the implementation of Interchain Security on top of. As this work gained more traction, it paved the way for many teams of developers within the Cosmos ecosystem to contribute to the success of Interchain Security.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Cosmos Hub Team","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"The hand-off to the Hub team.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The lion’s share of the work was borne by the Informal Systems Cosmos Hub team","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":". As the team that stewards the Hub, the folks on the team worked tirelessly to ensure that the launch of the Hub’s first consumer chain went as smoothly as possible. This involved coordinating amongst the many parties involved in the Neutron launch as well as ensuring that the software powering the Cosmos Hub was primed and ready to handle Neutron’s launch. If you’re interested in the nitty gritty details, the Hub team has their own write-up of how the launch went, which you can find ","nodeType":"text"},{"data":{"uri":"https://medium.com/@Cosmos_Hub/hub-engineering-update-first-consumer-chain-launch-ae680a3020bc"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"here","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". On the whole, the launch went relatively smoothly, thanks in large part to the hard work of the folks on the Informal Systems Cosmos Hub team!","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Hermes Team","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"What are chains if not linked.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"One of the crucial steps required to launch a chain on the Cosmos Hub mainnet is to link it to the other chains on the Hub via the IBC protocol, i.e., create the requisite clients, connections, and channels to facilitate the exchange of IBC packets with other IBC-enabled chains. This linking is performed by operators running relayer software, and once it has been done, the consumer chain must process a backlog of replicated security packets in order to synchronize with the other chains on the Cosmos Hub. In the case of the Neutron launch, the initial linking was performed by Strangelove’s Go relayer (check out their announcement on that","nodeType":"text"},{"data":{"uri":"https://twitter.com/gnudrew25/status/1656698460442345472"},"content":[{"data":{},"marks":[],"value":" ","nodeType":"text"},{"data":{},"marks":[{"type":"underline"}],"value":"here","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"), while Informal’s Hermes relayer was used to relay the backlog of packets in a timely manner.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"To bring us to the finish line.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Validator Team","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"The validator team helped coordinate the launch by providing instructions and helping other validators to get online. They were also instrumental in surfacing and resolving issues around signing transactions with multisigs and Ledger devices that triggered an emergency Gaia upgrade as well. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Security Team","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"The unsung heroes behind the successful debut of Interchain Security and Neutron, our auditors, played a significant role in reinforcing the security and efficiency of these platforms that are set to transform the digital landscape. For an in-depth look into their meticulous work, find the audit reports for Interchain ","nodeType":"text"},{"data":{"uri":"https://github.com/informalsystems/audits/blob/main/InterchainSecurity2023Q1/replicated-security-audit.pdf"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"here","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" and Neutron ","nodeType":"text"},{"data":{"uri":"https://github.com/neutron-org/audits/blob/main/06.04.2023%20Informal%20Systems%20Audit%20Report.pdf"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"here","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Wrapping Up","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"With the successful launch of the Cosmos Hub’s first consumer chain, the way is paved for many more consumer chains to come online, each secured by the Hub’s robust underlying infrastructure. Congratulations to all of the teams and contributors who made this launch a success! Look forward to many more consumer chain launches in the future 🙂","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"contentfulURL":"https://app.contentful.com/spaces/p79kctcd7ahy/entries/7rbn3ZsBLAuvM6Io14IzsT"},{"featureImage":"$4:props:posts:25:featureImage","date":"2023-04-24","title":"CometBFT v0.34 QA Process - Testing Strategies for Tendermint Core Successor","slug":"intro-qa-cometbft-v034","categories":["Engineering"],"authors":["Ali Merchant"],"keywords":"cometbft-v0.34, tendermint-successor, qa-testing, consensus-testing, compatibility-testing, unit-testing, integration-testing, end-to-end-testing, blockchain-qa, performance-testing","excerpt":{"nodeType":"document","data":{},"content":[{"nodeType":"paragraph","data":{},"content":[{"nodeType":"text","value":"Comprehensive testing methodology ensuring compatibility with existing Tendermint networks.","marks":[],"data":{}}]}]},"includeTableOfContents":true,"introduction":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"CometBFT","nodeType":"text"},{"data":{},"marks":[],"value":"™ is a fork and successor of ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"Tendermint Core","nodeType":"text"},{"data":{},"marks":[],"value":" that serves as the official replication engine for powering the Interchain Stack. CometBFT is being built and maintained by the team that previously maintained Tendermint Core. To read more about CometBFT, refer to ","nodeType":"text"},{"data":{"uri":"https://medium.com/the-interchain-foundation/cosmos-meet-cometbft-d89f5dce60dd"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"this article","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Purpose of this blog","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"The purpose of this blog is to describe how the QA process was done for CometBFT v0.34.27 including the methodologies, key learnings, and takeaways. Release v0.34.27 might seem like just a patch (.27) bump, but in fact, this is ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/blob/v0.34.27/CHANGELOG.md#v03427"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"the first-ever release","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" of CometBFT since this repository came to life as a successor to Tendermint Core. In particular, release line v0.34 of CometBFT faces a unique challenge because we want it to be fully compatible and integrate smoothly with networks running on the Tendermint Core v0.34 line, i.e., act as a drop-in replacement for Tendermint Core v0.34.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The blog also highlights the importance of QA for ensuring the quality, reliability, and performance of CometBFT software. Lastly, the blog also sheds light on the features and improvements of CometBFT.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"body":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"QA process for v0.34 & its importance in CometBFT development","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"QA process for v0.34","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"Testing strategies","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"A comprehensive testing strategy is crucial for CometBFT to maintain the integrity of the blockchain network. The strategy for v0.34 includes a combination of different approaches, such as ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"unit testing","nodeType":"text"},{"data":{},"marks":[],"value":", ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"integration testing","nodeType":"text"},{"data":{},"marks":[],"value":", and ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"end-to-end (E2E)","nodeType":"text"},{"data":{},"marks":[],"value":" testing.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Unit testing","nodeType":"text"},{"data":{},"marks":[],"value":" involves writing test cases for every code commit, ensuring that changes do not compromise the system's functionality or break existing code. We track code path testing and run randomly generated tests nightly, with longer runs happening weekly.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Integration testing","nodeType":"text"},{"data":{},"marks":[],"value":" tests the integration of CometBFT components to ensure expected functionality.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"E2E testing","nodeType":"text"},{"data":{},"marks":[],"value":" ensures blockchain network functions correctly and tests different scenarios with varying network conditions while ensuring its performance does not degrade relative to prior releases. A test generator is used for different topologies and configurations while the tests are run with nodes starting at different heights to simulate different network conditions.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Random executions","nodeType":"text"},{"data":{},"marks":[],"value":" test the resilience and isolate issues. If a test fails during nightly testing, the test is rerun locally to isolate the problem. \nThe ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/blob/main/test/e2e/networks/long.toml"},"content":[{"data":{},"marks":[{"type":"underline"},{"type":"bold"}],"value":"manifest file","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" specifies testing conditions and parameters, including permutations such as restarting validators, introducing new validators to perform blocksync and statesync after a large number of heights has been completed, or doing an uncoordinated upgrade of nodes.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Tools used","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"CometBFT 0.34 utilizes standard QA tools such as ","nodeType":"text"},{"data":{"uri":"https://golangci-lint.run/"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Golints","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" and triggered checks to ensure code quality and detect ","nodeType":"text"},{"data":{"uri":"https://vuln.go.dev/"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"vulnerabilities","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". \n","nodeType":"text"},{"data":{"uri":"https://github.com/dependabot"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Dependbot","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" is used to automatically update dependencies, while ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"GitHub actions","nodeType":"text"},{"data":{},"marks":[],"value":" are used for continuous integration to keep the software up to date with the latest changes. \n","nodeType":"text"},{"data":{"uri":"https://prometheus.io/"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Prometheus","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" is used to monitor system performance and prevent potential problems, while ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"load testing","nodeType":"text"},{"data":{},"marks":[],"value":" ensures the system can handle heavy traffic and identify performance issues. Finally, ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"querying the blockchain state","nodeType":"text"},{"data":{},"marks":[],"value":" is essential for QA to ensure CometBFT v0.34 is working correctly and providing insights into system performance.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Importance of QA in CometBFT development","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"QA is critical for each CometBFT release to ensure correctness, compatibility, bug fixing, and prevent performance regressions. It increases confidence in the system's correctness and ensures compatibility with other software components. QA helps identify and fix bugs through manual and automated testing and prevents performance regressions by identifying and resolving potential issues early in the development cycle.\n\nQA also ensures compatibility and seamless integration of CometBFT with other software components in the ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"Interchain Stack","nodeType":"text"},{"data":{},"marks":[],"value":", such as ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"Cosmos SDK","nodeType":"text"},{"data":{},"marks":[],"value":". QA tests were also performed on CometBFT v0.34 to ensure compatibility with nodes running Tendermint Core 0.34.x in the same chain without breaking compatibility.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"CometBFT 0.34.27 Release Overview ","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"Bug Fixes","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"CometBFT v0.34.27 fixed a ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"busyloop","nodeType":"text"},{"data":{},"marks":[],"value":" by adding a ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"sleep mechanism","nodeType":"text"},{"data":{},"marks":[],"value":" when sending a block part failed; resolved crashes related to event values with slashes; introduced a short-term fix for ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"needProofBlock","nodeType":"text"},{"data":{},"marks":[],"value":" not finding the previous block meta; and improved the underlying behavior of the non-blocking ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"TrySendEnvelope","nodeType":"text"},{"data":{},"marks":[],"value":" method.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Features and Improvements","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"CometBFT 0.34 added a \"","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"match_event","nodeType":"text"},{"data":{},"marks":[],"value":"\" query parameter to the RPC; functionality for uncoordinated minor upgrades; appending the commit hash to the version, new metrics in the consensus module; reduced log spam; and reduced bandwidth consumption of consensus votes. These changes contributed to improving CometBFT's performance, stability, and fault tolerance.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"To learn more about CometBFT 0.34 release overview, refer to our ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/blob/v0.34.27/CHANGELOG.md#v03427"},"content":[{"data":{},"marks":[{"type":"underline"},{"type":"bold"}],"value":"changelog","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[{"type":"bold"}],"value":". ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Challenges faced during Development & QA process","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"The migration to CometBFT was challenging as we aimed to ensure that v0.34 of CometBFT can function as a compatible and efficient alternative to Tendermint Core v0.34 without any major disruptions or breaking changes. \nThe team also had to compare and test Tendermint v0.34 with CometBFT v0.34 and rename and rebrand the code. \nAnother challenge was compatibility testing, which involved testing Comet alone, as well as various combinations of Comet and Tendermint. \nDespite these challenges, the team was able to overcome them and release a stable version of CometBFT. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Challenges may also arise during the QA process, One of these challenges faced is identifying all corner cases. Testing on small transactions is one strategy used to identify potential issues, but some corner cases may still be missed. To mitigate this risk, multiple tests are run and automated testing tools are used to streamline the process","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Key Learnings from QA for CometBFT 0.34","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"1. Test close to real-world problems\n","nodeType":"text"},{"data":{},"marks":[],"value":"Testing should simulate real-world scenarios to ensure the software is robust and reliable.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"2. Comprehensive\n","nodeType":"text"},{"data":{},"marks":[],"value":"Thorough testing, including functional, non-functional, and performance aspects, is crucial for identifying and resolving issues during development.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"3. Customer feedback","nodeType":"text"},{"data":{},"marks":[],"value":" \nInvolving customers in the testing process is crucial to ensure the software meets their needs and requirements. Customers like ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"Application Framework Developers","nodeType":"text"},{"data":{},"marks":[],"value":", ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"Application Developers","nodeType":"text"},{"data":{},"marks":[],"value":", ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"Consensus Engine Developers,","nodeType":"text"},{"data":{},"marks":[],"value":" and ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"Integrators ","nodeType":"text"},{"data":{},"marks":[],"value":"are crucial for the success of CometBFT.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"4. Different block sizes\n","nodeType":"text"},{"data":{},"marks":[],"value":"Testing with small, large, and empty blocks helps to identify performance issues with different block sizes.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"5. Learn from customers’ tests\n","nodeType":"text"},{"data":{},"marks":[],"value":"Learning from customer tests can identify issues that may arise during the development process and ensure the software meets customer needs.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"6. Simulate the app in Comet\n","nodeType":"text"},{"data":{},"marks":[],"value":"Simulating the application in Comet helps identify issues that may arise when the software is deployed in a real-world environment.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"To learn more about the QA process in v0.34, be sure to check out our comprehensive ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/tree/v0.34.27/docs/qa/v034#v034x---from-tendermint-core-to-cometbft"},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"QA report","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Future","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"As CometBFT continues to expand its capabilities and serve more use cases in production, the role of Quality Assurance remains critical. In the future, we can expect QA to place a greater emphasis on comprehensive testing, with increased attention given to uncovering corner cases by expanding the scope of testing.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Automation tools will also become more prevalent in the future of CometBFT's QA process, reducing the need for manual intervention and allowing for faster and more efficient testing. This, in turn, will reduce the risk of human error and improve the accuracy of test results.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Pre-release quality will be a major focus for CometBFT, as the platform strives to deliver high-quality software to its users. Rigorous testing will be conducted before each release to identify and resolve any issues or bugs before making the software available to users.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Graphical representations of test results will also become more common in the future of CometBFT's QA process, allowing developers to quickly interpret data and identify any issues or anomalies that may arise during testing.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"While CometBFT's performance has remained consistent between versions 0.34 and 0.37, it is important to run statistical tests multiple times to ensure the accuracy and validity of the results. By continuously evolving its testing processes, CometBFT can ensure that it delivers high-quality software to its users as the platform continues to grow and evolve.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"contentfulURL":"https://app.contentful.com/spaces/p79kctcd7ahy/entries/2JytIMfUWBCjT122wrtFRt"},{"featureImage":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"NT34uJCPRcCUYsgKA8J88","type":"Asset","createdAt":"2024-08-14T03:52:48.245Z","updatedAt":"2024-08-14T03:52:48.245Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":3,"revision":1,"locale":"en-US"},"fields":{"title":"Blog Informal 2","description":"","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/NT34uJCPRcCUYsgKA8J88/652012ce7c7fc2d6632261a9f0532513/Blog_Informal_2.jpg","details":{"size":145269,"image":{"width":1920,"height":1080}},"fileName":"Blog_Informal_2.jpg","contentType":"image/jpeg"}}},"date":"2023-04-13","title":"Informal Systems and Cosmos Collaboration - Three Years of Interchain Stewardship","slug":"informal-cosmos","categories":["Company"],"authors":["Informal Systems"],"keywords":"\ninformal-systems-history, cosmos-development, apalache-formal-methods, tendermint-cometbft, ibc-protocol, cosmos-hub, hermes-relayer, collaborative-finance, interchain-foundation, workers-cooperative","excerpt":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"How Informal became the largest Cosmos core development team building CometBFT and IBC.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"includeTableOfContents":true,"introduction":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"In our ","nodeType":"text"},{"data":{"uri":"https://informal.systems/blog/informal-origins"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"last post","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", we covered the origins and early ambitions of Informal Systems as it spun out from the ICF in January 2020. Informal started as a worker-owned team of 12 people led by Ethan Buchman (CEO), Arianne Flemming (COO), and Zarko Milosevic (CTO). We grew from these humble beginnings in 2020 to become the largest core development entity in Cosmos, with some 40+ people working on interchain focused R&D. In this post, we highlight different areas of Informal's work, add context for each, and outline our plans for 2023. Finally, we present the funding we've received from the ICF for our work over the years.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"body":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Mission","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"Informal's motivating thesis is that interchain technology is foundational to transforming the quality standards of three key, intersecting institutions in society:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Software","nodeType":"text"},{"data":{},"marks":[],"value":" - how it's built and deployed","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Money","nodeType":"text"},{"data":{},"marks":[],"value":" - how it's issued and distributed","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Organizations","nodeType":"text"},{"data":{},"marks":[],"value":" - how they're owned and governed","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"Each of these institutions is supposed to provide certain kinds of guarantees and support to the people that use them, but they constantly fail. The quality standards are abysmal. And together they comprise the modern techno-capitalist system, which is destroying the planet and our souls. It's high time someone tried to do something about it, in a deliberate, consistent, and holistic way.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Enter Informal. Our mission is to transform the quality standards of these institutions. Attention to quality is attention to promise making - what guarantees are provided, how are they tested, what if they fail? Our strategy for upgrading these institutions is united by attention to the structure of the promises inherent in each. So what's the plan? Well:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Software","nodeType":"text"},{"data":{},"marks":[],"value":" - executable specs to guarantee correctness of protocols and software","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Money","nodeType":"text"},{"data":{},"marks":[],"value":" - collaborative financial tools to guarantee the discharge of debts","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Organizations","nodeType":"text"},{"data":{},"marks":[],"value":" - cooperative language and organizational design to guarantee putting people first","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"We believe the Cosmos project, its technology, vision, and the interchain it's brought to life, provides an essential substrate for realizing this mission. Informal is thus deeply dedicated to the success of Cosmos and the interchain, and we seek to build a resilient organization capable of stewarding complex open-source public goods projects, both for the interchain, and for the more general institutions of software, money, and organizations to be built on top. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Informal & Cosmos","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"Since spinning out from the ICF in 2020, Informal has carried a dual focus on formal methods and the Cosmos technology. Our initial contracts were focused on formal methods work (Apalache, protocol design, verification, testing) and the development of Tendermint and IBC in Rust. But with the fallout from All in Bits in early 2020, the responsibility of maintaining the core Cosmos software in Go ","nodeType":"text"},{"data":{"uri":"https://medium.com/the-interchain-foundation/expansion-of-the-cosmos-ff2447c25e5"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"became distributed across a number of companies","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". The ICF created a new subsidiary called ","nodeType":"text"},{"data":{"uri":"https://medium.com/tendermint/an-update-about-the-state-of-all-in-bits-inc-dba-tendermint-inc-e5cdc22661ee"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Interchain GmbH (IG)","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" to bring on engineers that had left All in Bits, to keep working on the main implementations of Tendermint and IBC. Other engineers went elsewhere. Informal's executive team worked to support the ICF as it got new contracts in place to ensure Cosmos development continued uninterrupted. Over time, it became increasingly clear that, despite its initial plans, Informal needed to ","nodeType":"text"},{"data":{"uri":"https://twitter.com/billyrennekamp/status/1605880032269836288"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"pivot to better support the ICF & Interchain GmbH","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", and contribute more deeply to core Cosmos development. Informal's scope would expand as it took on increasing responsibility across Cosmos, notably for Tendermint in Go (and now, CometBFT) and the Cosmos Hub.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Today, Informal works on a number of core Cosmos projects funded by the ICF, including: ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"Tendermint","nodeType":"text"},{"data":{},"marks":[],"value":" (recently forked to ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"CometBFT","nodeType":"text"},{"data":{},"marks":[],"value":"), the world-class BFT consensus engine; ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"IBC","nodeType":"text"},{"data":{},"marks":[],"value":", the dominant blockchain interoperability protocol; and the ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"Cosmos Hub, ","nodeType":"text"},{"data":{},"marks":[],"value":"the anchor blockchain of the Cosmos ecosystem","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":". ","nodeType":"text"},{"data":{},"marks":[],"value":"Informal has also received support for some of its work on ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"Apalache","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":",","nodeType":"text"},{"data":{},"marks":[],"value":" an industry-leading formal methods engine, which is used to secure Cosmos software, and for its work on ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"Collaborative Finance","nodeType":"text"},{"data":{},"marks":[],"value":", a new approach to designing monetary and financial systems that can better connect blockchain tech to the real world.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"In addition, Informal offers highly-acclaimed security audits to projects across the interchain, and we validate on many Cosmos networks, partnering with projects and communities to help them succeed. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We'll take up each of these focus areas, below. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Apalache","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"Informal believes that formal methods can have a transformative impact on software engineering, and the key to getting there is delightful yet powerful tooling for executable specifications. ","nodeType":"text"},{"data":{"uri":"https://apalache.informal.systems/"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Apalache","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" is the engine behind Informal's formal methods work, where it is actively used to support Cosmos protocol design, development, security review, and testing. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Apalache is a symbolic model checker for formal specifications written in TLA+. It allows engineers to formally specify their protocols and verify their properties, enabling them to find bugs early and reason more effectively through complex sections in their protocols and software architecture. TLA+ is used by top tech companies like AWS, where it is widely acclaimed for its utility in security-oriented engineering, and Apalache is seeing enthusiastic adoption in the TLA+ community, including recognition from Leslie Lamport himself (the inventor of both TLA+ ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"and ","nodeType":"text"},{"data":{},"marks":[],"value":"the very field of consensus protocols).","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Apalache grew out of ","nodeType":"text"},{"data":{"uri":"https://dl.acm.org/doi/abs/10.1145/3360549"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"research at TU Vienna and INRIA Nancy","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", led by Igor Konnov and Josef Widder (both founding members of Informal), along with ","nodeType":"text"},{"data":{"uri":"https://en.wikipedia.org/wiki/Helmut_Veith"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Helmut Veith","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", a world renowned computer-scientist. It was industrialized and popularized by Informal, where it is actively developed and maintained with support from the ICF, other research grants (eg. from the City of Vienna), contributions from graduate students, and revenues from Informal's security business. Apalache has been augmented with Model-Based Testing tools (like ","nodeType":"text"},{"data":{"uri":"https://github.com/informalsystems/atomkraft"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Atomkraft","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"), which can auto-generate complex test cases for real software from simple specifications. Members of the Apalache, Model-Based Testing, and Protocol Design teams at Informal have used these tools over the years to find and fix bugs across the Cosmos software and protocols. Informal's formal methods work has helped grow the general understanding of Cosmos protocols and improve the security and robustness of implementations, and continues to serve as a magnet for talent in Cosmos.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Apalache is built to provide more accessible and powerful capabilities and to evolve the TLA+ language to be more user-friendly. The Apalache team introduced a type-checker for TLA+, called ","nodeType":"text"},{"data":{"uri":"https://apalache.informal.systems/docs/tutorials/snowcat-tutorial.html"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Snowcat","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", which allows spec writing to proceed far more smoothly and reliably. The team recently released ","nodeType":"text"},{"data":{"uri":"https://github.com/informalsystems/quint"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Quint","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", a new specification language that improves over TLA+, leveraging the power of Apalache, but designed to be far more accessible and delightful for developers to use. Quint is already being used by community members, with support from Informal, for the ","nodeType":"text"},{"data":{"uri":"https://twitter.com/0xekez/status/1640854657487753216"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"design of new IBC protocols","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". Our goal is to delight developers in their efforts to specify, understand, test, and verify their software and protocols, and to make Quint the gold standard of blockchain specification, to become as accessible as documentation to all those who reason about blockchain protocols - from engineers, product developers, and protocol designers, to executives, investors, journalists, regulators, community organizers, and beyond. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Today, thanks in-part to the support of the ICF, Apalache has matured into a leading open-source formal methods engine, capable of verifying previously unverifiable protocols and finding complex bugs in real software. And Quint, which emerged out of Apalache R&D, holds great promise in successfully nurturing a discipline of delightful, executable specifications, both within Cosmos and beyond. We believe Apalache and Quint are key stepping stones in our journey to change computing.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"In 2023, Informal is working on completing the integration between Quint and Apalache, and on supporting engineers across the Cosmos stack (CometBFT, IBC, Cosmos Hub, Cosmos-SDK, CosmWasm) to write better specifications and tests for their software, enabling them to improve their reliability and develop with more confidence. The team will be especially focused on IBC specification efforts this year, in support of ongoing improvements to IBC's multi-stakeholder standards process.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"If you think about blockchain protocols - even if you're not an engineer - consider getting started with ","nodeType":"text"},{"data":{"uri":"https://github.com/informalsystems/quint#documentation"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Quint","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Tendermint (and CometBFT)","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"Tendermint - the world-leading Byzantine Fault Tolerant (BFT) consensus engine - is a key part of Informal's DNA. Ethan was Tendermint's lead developer for years, and did his Master's thesis on it. Zarko, who has a PhD in BFT systems from EPFL, was its first and lead researcher, finding and fixing a key liveness issue in the protocol back in 2017. And Igor and Josef, computer scientists who have made breakthroughs in the formal verification of BFT systems, were the first to turn their techniques to the verification of blockchains, and to formally verify core safety properties of the Tendermint algorithm.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"When Informal spun out, it was doing ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"Tendermint protocol design and specification","nodeType":"text"},{"data":{},"marks":[],"value":", and it was implementing Tendermint client libraries in Rust. We published papers on the ","nodeType":"text"},{"data":{"uri":"https://arxiv.org/abs/2010.07031"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Tendermint light client","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" and the ","nodeType":"text"},{"data":{"uri":"https://drops.dagstuhl.de/opus/volltexte/2020/13423/pdf/OASIcs-FMBC-2020-10.pdf"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"BlockSync Reactor","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", combining formal specs, verification results, and integrations with the software. The light client work especially was foundational for the security of IBC, as the Tendermint light client is the dominant means for Cosmos chains to verify each other's state. Across the blockchain ecosystem, light client protocol development (colloquially known as the \"security of bridges\") remains an ongoing and complex problem, ripe to benefit from formal modeling and test generation. We look forward to blockchain bridges and light clients being specified in Quint.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Over the years, Informal has continued its protocol design and testing efforts for Tendermint, using its tools and expertise to test and verify protocol specifications and implementations in Go and Rust. We worked on subtle changes to the consensus, like proposer-based time stamps, which allow for a more accurate BlockTime to be produced for applications. And of course, we've been leading the effort to specify and implement ","nodeType":"text"},{"data":{"uri":"https://medium.com/the-interchain-foundation/tendermints-new-application-blockchain-interface-abci-86d46bd6f987"},"content":[{"data":{},"marks":[{"type":"underline"},{"type":"bold"}],"value":"ABCI++","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", unlocking powerful new capabilities for blockchain application developers, but also potential foot guns. With great power comes great responsibility. For more on ABCI++, see ","nodeType":"text"},{"data":{"uri":"https://www.youtube.com/watch?v=cAR57hZaJtM"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"this presentation","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" from Sergio Mena, a Technical Lead at Informal.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Informal's early efforts on ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"Tendermint in Rust","nodeType":"text"},{"data":{},"marks":[],"value":" focused primarily on client libraries to support interacting with the main Tendermint Core node in Go. Chief among these libraries is the Tendermint light client, which is a core part of IBC in Rust, including ibc-rs (the message handlers) and hermes (the IBC relayer). Informal also maintains protobuf files, RPC & websocket clients, and an ABCI client/server system for building out Tendermint-based systems in Rust. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"There were some early efforts to begin a full node in Rust, beginning with a compatible socket peer, but these were ultimately deprioritized in order to better support the full node in Go, whose development had moved from All in Bits to a new team at Interchain GmbH. Informal thus started building a ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"Tendermint in Go","nodeType":"text"},{"data":{},"marks":[],"value":" team in late 2021, which would work closely with the Interchain GmbH team in 2022 before becoming the main steward for the project, forking it, and rebranding to ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"CometBFT","nodeType":"text"},{"data":{},"marks":[],"value":" in 2023.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Moving forward at Informal, CometBFT is now under the extremely strong leadership of Thane Thomson (Project Lead) and Adi Seredinschi (Product Owner, moving over from Hermes), with Sergio Menia (Technical Lead) and other engineers highly experienced in distributed system design and implementation. The team hosts a highly active and regular Community Call and maintains an up-to-date ","nodeType":"text"},{"data":{"uri":"https://github.com/orgs/cometbft/projects/1"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Project Board","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" detailing key priorities.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The team's core focus now is finalizing the release of ABCI++ and supporting users of its methods, which enable new approaches to MEV, oracles, mempool privacy, and other kinds of more advanced network guarantees. In addition, the team is focused on major improvements to the operational overhead of running CometBFT nodes, including storage and bandwidth reductions, and more control over the RPC/indexing system. This will benefit all chains and operators in the ecosystem and enable further innovation in services built around CometBFT chains. They have also begun a formalization of the peer system, the gossip patterns, and the interaction between reactors in preparation for improving Comet's modularity and evolving its core protocols. If Tendermint was the foundation on which the interchain was conceived, CometBFT is here to take the interchain to the next level.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"IBC (and Hermes)","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"IBC has been a key focus for Informal since its inception. We believe IBC is the ideal base protocol for a new kind of internet of community computers, and therefore its security, usability, and performance are critical. Between our work on the IBC protocol design, security auditing, implementation in rust, the Hermes relayer, production relayer operations, and IBC developer relations, we have played, and continue to play, a key role in the development of the IBC protocol and network over its history.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"One of Informal's major achievements was production deployments of ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"Hermes","nodeType":"text"},{"data":{},"marks":[],"value":" with the launch of Osmosis in the summer of 2021. After 1.5 years of developing IBC in Rust - including a complete overhaul of IBC's underlying data structures and formatting in the 2021 Stargate upgrade and many protocol changes - Hermes was in production, contributing significantly to the early success of IBC. While anyone could run Hermes permissionlessly to relay IBC packets between sovereign blockchains, Informal received relaying contracts from Osmosis (and later, others) to provide assurances on IBC service quality for the new IBC connections. Over time, many other relayer operators would come online and service critical infrastructure functions in the interchain ecosystem - and many of them use Hermes. Hermes maintains ongoing collaborations and is complementary to the Go Relayer maintained by Strangelove, which is also widely used across the ecosystem.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"$2a","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Over the years, Informal has played an active role in ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"IBC protocol design and quality assurance","nodeType":"text"},{"data":{},"marks":[],"value":". Members of Informal, like Ethan, Zarko, Anca, and Josef, were all part of the early multi-stakeholder design meetings for IBC led by Chris Goes, and played an active role in the protocol's design as it matured from 2019-2021. In 2020, Informal ","nodeType":"text"},{"data":{"uri":"https://github.com/informalsystems/audits/tree/main/IBC2020"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"audited much of the original IBC implementation","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", resulting in critical fixes, leading up to its launch. Over the years, we would continue to support protocol design, review, and testing of key pieces of IBC as they were developed, like fees, Interchain Accounts, Interchain Security, and more. We've similarly been involved in supporting security reviews and testing of other interoperability modules, like the Gravity Bridge, which has formed the basis for many connections between Cosmos chains and Ethereum.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Informal also maintains ibc-rs, an implementation of the ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"IBC protocol messages and handlers in Rust,","nodeType":"text"},{"data":{},"marks":[],"value":" for use by Rust-based blockchain applications. While historically our primary focus on Rust development has been hermes, the ibc-rs handlers recently matured substantially and are being used actively by teams developing in Rust, like Nomic and Anoma. We intend to continue developing ibc-rs as IBC protocols evolve and development of Rust applications expands, working to ensure the library is generally usable by different application paradigms and that it supports compliance with specifications, extensive testing, and delightful integration experience.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"As a general purpose and increasingly adopted protocol, IBC has seen significant investment from many teams over the years, helping to secure its place as the leading interoperability protocol for blockchains. Informal is among these teams and continues to invest heavily in the growth of IBC, especially in support for hermes development, relayer operations, ibc-rs libraries, protocol specifications, testing of IBC applications, and the general accessibility of IBC as a new technology and paradigm.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Cosmos Hub","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"When Informal spun out from the ICF in Jan 2020, it wasn't focused at all on Cosmos Hub development. We did believe strongly in the vision of a strong and stable Cosmos Hub, but we weren't initially contracted to work on it, other than through our work on general-purpose pieces of the Cosmos stack like Tendermint and IBC, and the tooling we built for protocol design and testing. That said, Informal did strive to take payment for its work when possible in ATOM to encourage incentive alignment.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Over the years, as we observed repeated challenges faced by Cosmos Hub development, predicated primarily around the lack of a consistent, dedicated team, Informal took steps to start building a more focused team directly that could serve the interests of the Cosmos Hub community.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Beginning in 2021, Informal took an active role in leading protocol design for","nodeType":"text"},{"data":{"uri":"https://interchainsecurity.dev/"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":" Interchain Security","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". We believe Interchain Security is the optimal initial approach to scaling the Cosmos Hub's security, enabling the Hub to extend its functionality, build stronger partnership relations with other blockchains, and lay a foundation for further innovation in interchain services and shared security protocols. While Informal worked on protocol design, we did not have the resources to pursue building a product engineering team for the Cosmos Hub, until we hired Jehan Tremback in 2021, who would take leadership over the product development of Interchain Security at Informal Systems and start building a team for it, especially over the course of 2022.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"While there were attempts to grow a Cosmos Hub team at Interchain GmbH in 2021 and 2022, they were ","nodeType":"text"},{"data":{"uri":"https://twitter.com/billyrennekamp/status/1605880035566620672"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"beset by repeated organizational challenges","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", and members of their Cosmos Hub team would ultimately join Informal in 2023. Under Jehan's leadership as Product Owner, along with Marius Poke (Project Lead), Informal built an integrated Cosmos Hub product engineering team of 12+ people, dedicated full-time to working on advancing the Cosmos Hub, and delivering the first version of Interchain Security to usher in a new era of development and ecosystem expansion. The team built out the Interchain Security brand and protocol, integrated it into the Gaia software, ","nodeType":"text"},{"data":{"uri":"https://informal.systems/blog/building-with-interchain-security"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"attracted and supported prospective partner chains","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", and actively researched new protocols like the ","nodeType":"text"},{"data":{"uri":"https://informal.systems/blog/interchain-scheduler-design-update"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Interchain Scheduler","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" and ","nodeType":"text"},{"data":{"uri":"https://informal.systems/blog/replicated-vs-mesh-security"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Mesh Security","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" to support the ongoing advancement of the services offered by the Cosmos Hub.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Of course, the Informal Cosmos Hub team can only succeed through the active cooperation and collaboration of many different stakeholders across the Cosmos Hub community, from validators, to delegators, service providers, other development teams, and more. The community has proven time and again that no single developer team controls the Hub. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"That said, with the support of the ICF, Informal has offered and built a dedicated and effective product engineering team to support the Cosmos Hub. And with the recent launch of Replicated Security, and the upcoming launches of the first partner chains, the Hub community is embarking onto new terrain of collaborative growth. Informal is proud to steward software into this new terrain, and to work towards closer and more transparent funding relationships between core Cosmos Hub development and the Cosmos Hub community.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Starting this year, Jehan began publishing ","nodeType":"text"},{"data":{"uri":"https://informal.systems/blog/category/cosmos"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"regular monthly updates about the Cosmos Hub","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", which you can subscribe to on our ","nodeType":"text"},{"data":{"uri":"https://informal.systems/blog#subscribe"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"blog","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". Working with the Community team at the ICF, we will soon begin hosting Community Calls to better support and engage with the Hub community. Some details on the team's roadmap for 2023 can be found in the ","nodeType":"text"},{"data":{"uri":"https://informal.systems/blog/informal-hub-team-jan-2023-update#2023-cosmos-hub-roadmap"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"January update","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". ","nodeType":"text"},{"data":{"uri":"https://informal.systems/blog#subscribe"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Subscribe to the blog","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" for more!","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Collaborative Finance (CoFi)","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"Informal is motivated to bring Cosmos tech to bear on real-world socioeconomic issues, which is essential to realizing the Cosmos mission. Our latest effort, ","nodeType":"text"},{"data":{"uri":"https://cofi.informal.systems/"},"content":[{"data":{},"marks":[],"value":"Collaborative Finance","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".systems/, is focused on just that, an approach to helping communities develop more sustainable economic relationships by collaborating to reduce their debts.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Ethan Buchman has for years emphasized the importance of a ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"monetary localism ","nodeType":"text"},{"data":{},"marks":[],"value":"that can be realized using the Cosmos philosophy and technology. He's expressed this as ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"the ultimate purpose of Cosmos","nodeType":"text"},{"data":{},"marks":[],"value":". This localism reflects a quality of sustainable systems - the representation of stakeholders in their state machines. The Cosmos design philosophy is precisely oriented to enable experiments in such representation. Modern Proof-of-Stake is one such experiment, which Cosmos pioneered and leveraged to provide a new mode of building, deploying, and operating blockchains. But Proof-of-Stake, and the Decentralized Finance increasingly built above it, while remarkably effective, are not nearly sufficient to stage the intervention necessary to empower a more sustainable monetary and financial system.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Informal has always believed in a more localist orientation to monetary and financial system design. But there seemed to be a catch. While examples of localist monetary systems abound, they often seem to struggle from a problem of scale and financial viability. Perhaps the most successful are the mutual credit systems of the WIR Bank, Sardex, and Grassroots Economics, which have for years or decades enabled businesses to issue credits against their future production. But others, like time banks and LETS, have typically struggled to grow. Scrip currencies, issued by companies and towns, have proven critical and successful but have been quickly stamped out by central authorities. This is all suggestive that blockchains might have something to offer here (indeed, Grassroots Economics is built on Ethereum tech and exploring a move to Cosmos), but it still felt like something was missing.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Enter Fleischman, Dini, and Littera - experts on complementary payments systems - and their paper on ","nodeType":"text"},{"data":{"uri":"https://www.mdpi.com/1911-8074/13/12/295"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Liquidity Saving through Obligation Clearing","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". As a prominent local currency community member put it, ","nodeType":"text"},{"data":{"uri":"https://www.mutualcredit.services/blog/someone-just-turned-the-lights-on"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Someone Just Turned the Lights On","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". The essential idea is that monetary system design must start from the graph of obligations in the credit network. From there, the liquidity needed to discharge debts can be ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"minimized ","nodeType":"text"},{"data":{},"marks":[],"value":"by taking advantage of partial discharge of obligations along credit cycles and chains. Hence, ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"liquidity savings","nodeType":"text"},{"data":{},"marks":[],"value":". This is a profound difference from the way most blockchains projects, and the banking system itself, obsess over the provision of liquidity. But CoFi is unique in that it provides a natural integration point for blockchain and banking liquidity sources. It's effectively a semi-permeable membrane between local and global currency systems.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The Fleischman et al. paper was the key that Ethan and so many others needed to unlock explosive potential for a more collaborative finance. And so, with some initial support from the ICF in 2022, Informal recruited all three authors to found a Collaborative Finance initiative at Informal to expand research in this new approach to monetary design and to support communities using Cosmos tech to realize it. While Informal continues to actively grow the CoFi project, funding for CoFi from the ICF was discontinued in 2023 as part of its ongoing budget cuts.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Collaborative Finance is seeing growing recognition as a unifying approach to many complementary monetary system designs. The academic work is even attracting the attention of Central Banks and their associations, with whom our team members consult on policy and collaborate on research. CoFi offers an alternative direction to the Draconian prospects of CBDCs, one that can simultaneously reduce systemic risk, preserve privacy, and encourage more distributed and sustainable growth.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We've also been working with various communities across the world to support their complementary currency systems and their use of Cosmos tech. We are collaborating on research with groups like Grassroots Economics, Blockscience, and others, and we are preparing for the release of our core graph algorithm and more details on CoFi architecture. Stay tuned. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Informal Security & Informal Staking","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"Throughout its history, Informal has built independent business lines leveraging its expertise and open-source tools and has always aspired to reduce the proportion of its funding from the ICF. In particular, we've seen significant demand for both our ","nodeType":"text"},{"data":{"uri":"https://informal.systems/services/security-audits"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"security auditing","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" and ","nodeType":"text"},{"data":{"uri":"https://informal.systems/staking"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"staking businesses","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", both of which have grown into industry leading offerings acclaimed across the interchain. Informal has become widely acclaimed especially for security audits, which we began offering in 2021. And our validator team, working closely with many others, has been instrumental in enabling and supporting the growth of new networks. We are honoured to work together with amazing teams across the ecosystem to create a more secure and reliable interchain.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Doing justice to our work as security auditor and network operator will require dedicated posts in and of themselves. Suffice it to say here that, historically, we prioritized the Cosmos mission over our own business development goals in order to fill gaps that emerged in core Cosmos development. This meant turning down opportunities and throttling growth. But as those gaps have been increasingly filled over the years by our own work and the work of others, Informal has been expanding its business offerings and is looking forward to working with ever more teams across the interchain. We'll have more to say on all that in future posts.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"ICF Funding","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"In the last post, we mentioned that Informal spun out from the ICF with a $2.5M convertible note investment. We've also been executing against service agreements with the ICF, covering much of the work just reviewed above on formal methods, protocol design, Apalache, testing, Tendermint (and CometBFT), IBC, the Cosmos Hub, and CoFi.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"In 2020, when Informal spun out from the ICF, it was around 12 people. By the end of the year, it had grown to ~18, and almost all efforts were focused on the ICF contracts. In total, for its services over the year, primarily on protocol design & testing, Apalache, IBC security, and initial development of tendermint and IBC in Rust, Informal received ~$4.5M in funding from the ICF.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"In 2021, Informal grew to ~36 people over the year, mostly working on ICF-related contracts. This included growth in its core formal methods and Rust teams, as well as expansion into two new teams: Tendermint in Go, and Interchain Security (Cosmos Hub). In total, for its services over 2021, Informal received ~$6M from the ICF. In addition, the ICF started paying ATOM bonuses on a per-person basis in late 2021 to support incentive alignment, and Informal received 40k ATOM.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"In 2022, Informal grew to ~54 people over the year, with ~45 working on ICF-related contracts - including on Tendermint in Go, the Cosmos Hub, Hermes, protocol design & testing, Apalache, ibc-rs, IBC security, and CoFi. Growth was primarily focused on Tendermint in Go and the Cosmos Hub, as Informal increasingly came to steward both, working to revive development velocity. Informal was also called on for some organizational and operational support at Interchain GmbH. In July of 2022, Informal received a hiring freeze notice from the ICF, responding to market conditions. In total for its services over 2022, Informal received ~$13.4M from the ICF, as well as 279k ATOM in incentive bonus.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Towards the end of 2022, and in anticipation of ICF budget cuts for 2023, Informal took preemptive steps to reduce the size of its formal methods team and to consolidate primarily on CometBFT and the Cosmos Hub, as well as reprioritizing Informal's own business goals (growing its security audit offering). The total contract size with the ICF in 2023 is expected to be roughly similar to 2022, accounted for primarily by growth on the CometBFT and Cosmos Hub teams, and cuts to the formal methods and CoFi teams. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Conclusion","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"Informal's on a mission to transform the quality standards of ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"software","nodeType":"text"},{"data":{},"marks":[],"value":", ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"money","nodeType":"text"},{"data":{},"marks":[],"value":", and ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"organizations","nodeType":"text"},{"data":{},"marks":[],"value":". We believe interchain technology, and secure public blockchains, are critical to achieving that mission. As a cooperatively owned entity, we're committed to high standards of care and performance in our work together and with the larger community as we collectively develop and operate the open-source interchain technology that inspires us all.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Informal is deeply dedicated to the success of Cosmos and the interchain. We have grown to become the largest steward of open-source public goods in the ecosystem, both for the interchain, and the Cosmos Hub. And our services in security auditing and network operations have come to be highly sought after as we partner with an increasing number of projects in the ecosystem.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We look forward to leading components of the Cosmos ecosystem into new eras of development, collaborating with the larger community on their long-term plans, evolution, and sustainability (as well as on other key public goods) as we work to transform the standards of software, money, and organizations the same way Cosmos transformed blockchains.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Moving forward, we plan to publish more regular updates about our teams and funding as we work with the larger interchain community towards a more sustainable and decentralized funding of core public goods.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We're excited to have built an organization capable of balancing open-source public goods development, with deep tech R&D, sustainable service businesses, and a vision for a more delightful future. And we're excited to share more about who we are, what we're up to, and how it works with all of you. 🥂","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"contentfulURL":"https://app.contentful.com/spaces/p79kctcd7ahy/entries/7kDOWE385nrv3OAFeROAAc"},{"featureImage":"$4:props:posts:25:featureImage","date":"2023-04-12","title":"CometBFT Q2 2023 Priorities - ABCI Support and State Sync Improvements","slug":"cometbft-priorities-2023-q2","categories":["Engineering"],"authors":["Adi Seredinschi"],"keywords":"\ncometbft-q2-priorities, abci-plus-plus, state-sync-alternatives, json-rpc-improvements, storage-optimization, bandwidth-reduction, data-companion, consensus-performance, protocol-design, node-operators","excerpt":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Five development streams addressing protocol design and storage optimization.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"body":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Key takeaways:","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"In Q2, team Comet will focus on five streams of work. Each stream aims to nibble away at a major ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"problem","nodeType":"text"},{"data":{},"marks":[],"value":" from our ","nodeType":"text"},{"data":{"uri":"https://github.com/orgs/cometbft/projects/1"},"content":[{"data":{},"marks":[],"value":"priorities backlog","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"The problems we’re tackling have a broader scope than this quarter. Therefore, we expect to continue focusing on these issues throughout the rest of 2023.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"The five problems of focus are, in order of priority:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"CometBFT provides poor protocol design support to application developers.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"There is currently no alternative to network-based state sync.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"The JSON/RPC that CometBFT nodes expose is flaky.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Storage and bandwidth consumption are expensive for operators running CometBFT nodes.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"For specific solutions, see the full post below.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Context","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"We launched CometBFT at the beginning of February 2023. It has been 2 months since then. In this brief time, we have made significant strides in the development of CometBFT. In this post we will first summarize what were our main successes during Q1. Then we will provide an overview of the priorities we plan to tackles as part of Q2, as well as the process we used to arrive at these priorities.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Summary of Q1","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"Q1 was an interesting period for the CometBFT team because the first month (January) was packed with activities related to forking Tendermint Core, renaming that fork into CometBFT, and preparing its public announcement. This work was tedious but very rewarding: It allowed us to restart development and to provide a solid groundwork for continuing to evolve this software towards growing the Interchain. Please read the announcement introducing CometBFT ","nodeType":"text"},{"data":{"uri":"https://informal.systems/blog/cosmos-meet-cometbft"},"content":[{"data":{},"marks":[],"value":"here","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" and in ","nodeType":"text"},{"data":{"uri":"https://twitter.com/informalinc/status/1620825636213526528?s=20"},"content":[{"data":{},"marks":[],"value":"this thread","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"In terms of technical & documentation deliverables, during Q1 we have shipped the following:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Feb 3, 4","nodeType":"text"},{"data":{},"marks":[],"value":": we released ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"v0.34.25","nodeType":"text"},{"data":{},"marks":[],"value":" and ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"v0.34.26","nodeType":"text"},{"data":{},"marks":[],"value":", the former release being a security patch to the ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"v0.34.*","nodeType":"text"},{"data":{},"marks":[],"value":" line. Both of these releases were done from the Informal Systems team's public fork of Tendermint Core.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Feb 27","nodeType":"text"},{"data":{},"marks":[],"value":": we released ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"v0.34.27","nodeType":"text"},{"data":{},"marks":[],"value":", the first official release of CometBFT, a drop-in replacement for Tendermint Core v0.34.x","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Feb 28","nodeType":"text"},{"data":{},"marks":[],"value":": we shipped the official documentation for CometBFT at ","nodeType":"text"},{"data":{"uri":"https://docs.cometbft.com/"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"https://docs.cometbft.com/","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" ","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"March 6","nodeType":"text"},{"data":{},"marks":[],"value":": released ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"v0.37.0","nodeType":"text"},{"data":{},"marks":[],"value":", the first CometBFT release with ABCI 1.0","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"March 29","nodeType":"text"},{"data":{},"marks":[],"value":": released ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"v0.38.0-alpha.1","nodeType":"text"},{"data":{},"marks":[],"value":" a pre-release with ABCI 2.0","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"ordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"Both ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"v0.37.*","nodeType":"text"},{"data":{},"marks":[],"value":" and ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"v0.38.*","nodeType":"text"},{"data":{},"marks":[],"value":" have been in preparation for a long time. We are thankful to all the teams and contributors that have helped design and refine ABCI2.0 over the last ~2 years. It is truly exciting to see all this work come to fruition, and the numerous networks interested to leverage the new features in the ABCI interface.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The last two weeks of March we have been busy managing our backlog and getting our priorities in order so that we have clarity over the work we’ll be doing over the next 3 months.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Priorities for Q2 (April, May, June)","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"We have five streams of research and development lined up for the next quarter. We will first talk about the problem each of this line of work tries to address, and then provide some context on the solution space.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Problem (1) CometBFT v0.34 provides poor support to application developers to address novel use-cases","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"CometBFT ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"v0.34","nodeType":"text"},{"data":{},"marks":[],"value":", used in production today, comprises the ABCI ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"v0.17","nodeType":"text"},{"data":{},"marks":[],"value":" interface. ABCI is the API separating the ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"application","nodeType":"text"},{"data":{},"marks":[],"value":" from the ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"consensus engine","nodeType":"text"},{"data":{},"marks":[],"value":". This is the interface that application developers have at their disposal to interact with CometBFT.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"ABCI ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"v0","nodeType":"text"},{"data":{},"marks":[],"value":" was designed circa 2015-2016. Since then, the broader crypto ecosystem has evolved rapidly. Applications demand more flexibility and control today. Application developers seek to have a more fine-grained control over what CometBFT puts inside blocks and to use CometBFT to exchange information between nodes other than through blocks.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"To address this problem, ABCI++ was proposed circa 2020 (","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/blob/v0.38.0-alpha.1/docs/rfc/tendermint-core/rfc-013-abci%2B%2B.md#short-list-of-blocked-features--scaling-improvements-with-required-abci-phases"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"RFC 013","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"). ABCI++ is being delivered across two versions: ABCI v1 (CometBFT ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"v0.37","nodeType":"text"},{"data":{},"marks":[],"value":"), and ABCI v2 (CometBFT ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"v0.38","nodeType":"text"},{"data":{},"marks":[],"value":"). As mentioned above, we have released ABCI v1, and for v2 we are in the final phases: we have already released an ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"alpha-1","nodeType":"text"},{"data":{},"marks":[],"value":". What is left is to iron out the interface design, to write more comprehensive documentation of ABCI v2, and to do an extensive large-scale QA which typically involves 200-node testnets.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We estimate releasing ","nodeType":"text"},{"data":{},"marks":[{"type":"code"}],"value":"v0.38.0","nodeType":"text"},{"data":{},"marks":[],"value":" to take another 1-2 months of work.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Problem (2) There is currently no alternative to network-based state sync","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"In CometBFT v0.34, synchronizing a fresh node with the rest of the network relies on a protocol that fetches snapshots from the other peers in the network. Some disadvantages of this approach are that it is ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"fragile","nodeType":"text"},{"data":{},"marks":[],"value":" (because peer snapshots might not be immediately available) and ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"bandwidth-intensive","nodeType":"text"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Alternatives to network-based state sync exist. For instance, using a local snapshot, which may have been generated by the node itself or copied from a trusted source, state synchronization could avoid large transfers from remote peers. Such an alternative ","nodeType":"text"},{"data":{"uri":"https://github.com/tendermint/tendermint/blob/cal/local-sync-adr/docs/architecture/adr-083-out-of-band-sync.md"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"has been explored","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" and we plan to bring that work into a future release of CometBFT. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"This problem is particularly interesting because operators employ state syncing of new nodes frequently. They do so because storage consumption of nodes grows over time, so there is a preference to setting up new nodes regularly. The storage growth issue is something we’re aware of and is also a priority (see below). The bottom line is that this is an important problem, and as an important user ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/issues/27#issuecomment-1426140094"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"put it","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" in the tracking issue:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"italic"}],"value":"yes please, every validator would like to have this","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"blockquote"},{"data":{},"content":[{"data":{},"marks":[],"value":"Problem (3) The JSON/RPC that CometBFT nodes expose is flaky","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"There are multiple dimensions to this problem. First, the JSON/RPC implementation is very complex, and second, it is orthogonal to the main task of CometBFT, which is state machine replication (not RPC), hence it inflates unnecessarily the surface area that we need to maintain. Third, we are aware of security concerns, i.e., that the RPC ","nodeType":"text"},{"data":{"uri":"https://docs.cometbft.com/v0.37/core/running-in-production"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"is a potential DDoS vector","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", so we advise defensive measures there. Fourth, the RPC interface can pose a bottleneck to IBC relaying operations; this is from our experience with developing ","nodeType":"text"},{"data":{"uri":"https://hermes.informal.systems"},"content":[{"data":{},"marks":[],"value":"Hermes IBC relayer","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", and running it as part of ","nodeType":"text"},{"data":{"uri":"https://informal.systems/staking"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Informal Staking","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". Fifth, the RPC interface can impose backpressure into other components of CometBFT (e.g., consensus) which can make the node unreliable by falling out-of-sync with the network.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Our approach towards fixing this is still in the exploration phase but we have a promising solution in the form of a Data Companion. We have recently discussed this at our ","nodeType":"text"},{"data":{"uri":"https://groups.google.com/g/cometbft-community/"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"community call","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", and invite feedback directly in the PRs (","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/pull/73"},"content":[{"data":{},"marks":[],"value":"ADR 100","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/pull/82"},"content":[{"data":{},"marks":[],"value":"ADR 101","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":").","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Problem (4) and (5) Storage and bandwidth consumption are expensive for operators running CometBFT nodes","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"On the storage front, the problem is that pruning does not work effectively. This leads to increasing storage costs over time. At a more basic level, CometBFT supports multiple database backends, but there is no documented use-case of the workload characteristics expected of these backends. Consequently, it is not clear which of them is most appropriate from a performance and efficiency perspective. Similarly to the JSON/RPC problem, we want to reduce the surface area under our maintenance, and would therefore prefer to narrow down the supported databases to the one that fits best.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"In terms of bandwidth, we are aware that operators are incurring high costs due to CometBFT-based networks’ bandwidth consumption. To mitigate this, an initial investigation led to a ","nodeType":"text"},{"data":{"uri":"http://tendermint/tendermint#9760"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"reduction","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" by 50% of Precommit votes sent among peers. We are continuing that investigation towards reducing non-vote bandwidth consumption (e.g. block parts or transactions). An important element of this investigation comprises the drawing of specifications for the P2P and consensus modules, which are at the center of attention when it comes to bandwidth usage.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Process","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"We have chosen problems based on the input and feedback we have been gathering from various channels (Slack, Discord, Telegram, Twitter, and community calls).","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The specific elements of feedback we were concerned with where:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Are there specific people that can confirm the problem? Do we have a good understanding of the underlying concerns or root cause?","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Is there an articulation of the impact of the problem, e.g. in terms of money, opportunities, time, or energy? Does that make the problem ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"urgent","nodeType":"text"},{"data":{},"marks":[],"value":", relative to other problems?","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Are there specific users we can work with to bounce our ideas off, to de-risk solutions, and ensure continuous feedback?","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Can we make incremental steps towards a solution?","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"Additionally, we have also given a slight preference to quick win and high-impact problems.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"This led to us categorizing the problems in a table. This shed light and clarity over all problems by comparing them in terms of urgency, impact, users, complexity, and effort. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The table below is a snapshot from our raw notes during the prioritization exercise. It shows the top (most urgent) problems for Q2. Note that the “User” column is non-exhaustive: Some users go unmentioned to avoid swelling the table.\n","nodeType":"text"}],"nodeType":"paragraph"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"5EFRjWats2Idyq4XoMlom3","type":"Asset","createdAt":"2023-04-12T09:37:37.116Z","updatedAt":"2023-04-12T09:37:37.116Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":6,"revision":1,"locale":"en-US"},"fields":{"title":"Snapshot of table with Q2'23 Comet priorities","description":"Snapshot of table with Q2'23 Comet priorities","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/5EFRjWats2Idyq4XoMlom3/a49647534b38e9a7c27233cbb4171c27/Screenshot_2023-04-06_at_19.23.34.png","details":{"size":47374,"image":{"width":896,"height":204}},"fileName":"Screenshot 2023-04-06 at 19.23.34.png","contentType":"image/png"}}}},"content":[],"nodeType":"embedded-asset-block"},{"data":{},"content":[{"data":{},"marks":[],"value":"The following snapshot also shows our current short-listed backlog of problems.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"4OKV7JM5jbYaSBzVc4PsBc","type":"Asset","createdAt":"2023-04-12T09:37:49.420Z","updatedAt":"2023-04-12T09:37:49.420Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":6,"revision":1,"locale":"en-US"},"fields":{"title":"Snapshot of CometBFT Q2'23 backlogs","description":"Snapshot of CometBFT Q2'23 backlogs","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/4OKV7JM5jbYaSBzVc4PsBc/e78b4339f42e29bbf6a712ef013c2394/Screenshot_2023-04-06_at_19.23.45.png","details":{"size":44447,"image":{"width":846,"height":202}},"fileName":"Screenshot 2023-04-06 at 19.23.45.png","contentType":"image/png"}}}},"content":[],"nodeType":"embedded-asset-block"},{"data":{},"content":[{"data":{},"marks":[],"value":"Both the chosen priorities and the backlog are aligned with the ","nodeType":"text"},{"data":{"uri":"https://github.com/orgs/cometbft/projects/1"},"content":[{"data":{},"marks":[],"value":"project board","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". The difference is that in these tables and our internal discussions we have went more deeply into assessing the problem and solution space, while also capturing users & impact.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Final thoughts","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"We are aware that this approach to prioritizing is not entirely objective. If there is feedback or ideas to improve, we would be glad to engage with the community to refine our prioritization.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Finally, we're executing on these priorities in parallel to a multi-quarter research work on forks of Tendermint Core and CometBFT (e.g., forks of Celestia, Sei, Skip, Numia, or Polygon among many others). The aim of this investigation is to uncover which improvements that other teams did in their forks would be appropriate and desirable for upstreaming into CometBFT. For each candidate, we're assessing its complexity and impact. The idea is to work with some of these teams to upstream changes into mainline CometBFT, so that the whole community can benefit from the corresponding improvements.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Follow ","nodeType":"text"},{"data":{"uri":"https://twitter.com/cometbft"},"content":[{"data":{},"marks":[],"value":"@cometbft","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" on Twitter to keep up-to-date with all news related to CometBFT.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"contentfulURL":"https://app.contentful.com/spaces/p79kctcd7ahy/entries/3rsT3ebRsDQlruvF02SlUq"},{"featureImage":"$4:props:posts:29:featureImage","date":"2023-04-11","title":"Cosmos Hub March 2023 Update - Replicated Security V9 Upgrade Launch","slug":"cosmos-hub-team-march-2023-update","categories":["Engineering"],"authors":["Jehan Tremback"],"keywords":"\ncosmos-hub-march, replicated-security-v9, neutron-preparation, soft-opt-out, liquid-staking-module, opt-in-security, sovereign-consumer-transition, equivocation-verification, downtime-verification, validator-outreach","excerpt":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Monthly update covering Neutron preparation and liquid staking module progress.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"body":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"V9 Upgrade went live!","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"The Cosmos Hub v9 upgrade went live on March 15th. This upgrade added the code for Replicated Security to the Cosmos Hub. Due to our renewed focus on validator outreach and communications, v9 went very smoothly, with minimal downtime.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Replicated Security is now enabled on the Cosmos Hub, although it won’t really be used until the first consumer chain launches.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Neutron’s proposal and soft opt out","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"We’ve been supporting the Neutron team as they move towards launch as the first RS consumer chain. They’ve had their ","nodeType":"text"},{"data":{"uri":"https://forum.cosmos.network/t/proposal-draft-launch-neutron-on-replicated-security"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"proposal","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" on the forum for a few weeks, and it will go on chain soon. Our team has been double checking their implementation and the parameters to be used in their on chain governance proposal. We’ve also been assisting them with thinking through the question of how to minimize costs for smaller validators. One solution we’ve been considering is a feature called ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/interchain-security/issues/784"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"soft opt-out","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". With soft opt-out, a percentage of the smallest validators can opt out of validating a consumer chain without affecting the security of the consumer chain (although it might have slightly higher downtime during upgrades). Neutron may use this to allow the smallest 5% of validators to opt out. Given the distribution of the Cosmos Hub validator set, this is actually around 75 validators.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Documentation","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"We’ve been working on some ","nodeType":"text"},{"data":{"uri":"https://cosmos.github.io/interchain-security/"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"documentation","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" for Replicated Security. They are fairly complete, but could probably still use some improvement. Let us know with an ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/interchain-security/issues"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"issue","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" if anything is unclear.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Liquid Staking Module","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"We’ve been helping the Stride team think through the best way to bring secure and user-friendly liquid staking to the Cosmos Hub. One promising approach is to add an additional limit to the existing ","nodeType":"text"},{"data":{"uri":"https://github.com/iqlusioninc/liquidity-staking-module/blob/master/adr/adr-001.md"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"liquid staking module","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", which would enforce a global cap on the percentage of Atoms that can be liquid staked. This would also apply to liquid staking done through Interchain Accounts, which is currently not limited at all.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"This global limit would make the adoption of liquid staking more secure by imposing this limit, while also improving the user experience of liquid staking by making it seamless to adopt.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Initial design of Opt-In Security","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"Opt-in Security is a form of Interchain Security where validators can choose which consumer chains they validate on, as opposed to Replicated Security, which uses the full validator set of the Cosmos Hub for each consumer chain. We’ve sketched out a rough design for a first version of opt-in security ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/interchain-security/issues/788"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"here","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Sovereign to Consumer chain transition","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"The Stride team has been working on a first version of an implementation of our ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/ibc/pull/840"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"protocol","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" enabling Cosmos chains which are currently running as standalone chains to switch to Replicated Security. We’re ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/interchain-security/issues/756"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"currently working","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" on bringing this into mainline Interchain Security, working through all possible edge cases, and testing it in our test suite.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Equivocation Verification","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"Work has been ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/interchain-security/pull/826"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"progressing quickly","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" on code which will allow the Cosmos Hub to detect and slash validators for light client attacks. This is a key component of our move towards an trustless consumer chain model, where faulty or malicious consumer chains cannot cause any disruption to the Cosmos Hub. Once this work is complete, we will be able to remove the ","nodeType":"text"},{"data":{"uri":"https://forum.cosmos.network/t/slashing-updates-in-replicated-security/9571"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"governance-gating","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" of slashing, instead allowing misbehaving validators to be immediately identified, cryptographically verified, and slashed without an extra confirmation from governance,","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Downtime verification","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"We’re also working on code that will allow the Cosmos Hub to detect and verify that a validator has experienced ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/interchain-security/issues/761"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"excessive downtime on a consumer chain","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". Once equivocation verification and downtime verification are complete, the Cosmos Hub will be able to verify all misbehavior of validators on consumer chains, instead of relying on the consumer chains themselves to support it. This will make Replicated Security simpler and more robust.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"contentfulURL":"https://app.contentful.com/spaces/p79kctcd7ahy/entries/6DqHJGbyJBUnuUvAs7VwL4"},{"featureImage":"$4:props:posts:79:featureImage","date":"2023-04-10","title":"Informal Systems Origins - Worker Cooperative Building Verifiable Distributed Systems","slug":"informal-origins","categories":["Company"],"authors":["Informal Systems"],"keywords":"informal-systems-origins, workers-cooperative, cosmos-foundation, employee-ownership, distributed-systems-verification, formal-methods-research, icf-spinout, sustainable-business, verifiable-software, organizational-representation","excerpt":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"How Informal spun out from ICF to become employee-owned Cosmos development company.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"introduction":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"The origin of Informal Systems lies in a vision for a new kind of company. A better kind of company. A company owned by its employees. A company focused resolutely on improving the promises made to us by our software systems and our organizations. A company less likely to move fast and break things; a company that might move slow and fix things. There’s plenty broken out there already - just look around. The entire world system has gone structurally short itself. Shouldn’t we be figuring out how to go long? What else could sustainability possibly mean?","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"body":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Origins","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"Informal’s origins are also deeply tied up in the history of Cosmos; in its philosophy, in its founder conflict, and in its organizational evolution. From the Cosmos philosophy, Informal draws on a core principle that ","nodeType":"text"},{"data":{"uri":"https://www.youtube.com/watch?v=Luh7m7YHRts"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"state machines must better represent their stakeholders","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" - and that in turn, companies must better represent their employees. From the founder conflict, suffice it to say, Ethan and Jae had a strong difference of opinions on how to run a company. And organizationally, Informal spun out of the Interchain Foundation (ICF) right before the ","nodeType":"text"},{"data":{"uri":"https://interchain-io.medium.com/sustainability-of-the-cosmos-network-a-statement-from-the-interchain-foundation-c96ef0975f5"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"fallout at All in Bits","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" (AiB). Informal has persisted in supporting the ecosystem to move forward and rebuild ever since. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The founding leadership team of Informal - Ethan Buchman (CEO), Arianne Flemming (COO), and Zarko Milosevic (CTO) - all worked together at All in Bits in 2017-18. That early history of Cosmos is told ","nodeType":"text"},{"data":{"uri":"https://blog.cosmos.network/cosmos-history-inception-to-prelaunch-b05bcb6a4b2b"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"here","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". But Informal’s history picks up about where that one leaves off. Throughout 2018, Ethan, Arianne, and Zarko felt that a team at the ICF should be built up to develop a grants and research program, and to fund development of Cosmos beyond AiB. By the end of 2018, Zarko had moved to the ICF to better support ","nodeType":"text"},{"data":{"uri":"https://interchain-io.medium.com/past-present-future-icf-r-and-d-introducing-informal-systems-e50d14383f05"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"research collaborations","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" with various universities on cryptography, distributed systems, and formal methods. By early 2019, Ethan and Arianne would leave AiB to join the ICF as well - it was time to build capacity there, to support the ","nodeType":"text"},{"data":{"uri":"https://blog.cosmos.network/open-decentralized-networks-87e6097536a3"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"coming launch of the Hub","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", develop a ","nodeType":"text"},{"data":{"uri":"https://interchain-io.medium.com/ecosystem-expansion-189e9534038"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"grants","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" and ","nodeType":"text"},{"data":{"uri":"https://github.com/interchainio/delegation"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"delegation","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" program, and grow the ecosystem. So that’s ","nodeType":"text"},{"data":{"uri":"https://interchain-io.medium.com/icf-funding-program-2019-year-in-review-587724650938"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"exactly what they did","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Under the leadership of Ethan, Arianne, and Zarko, in 2019, the ICF started to hire some amazing people - people like Anca Zamfir, Josef Widder, Thane Thomson, Adi Seredinschi, Igor Konnov, Andy Nogueira, Greg Szabo (who also moved from AiB) and others, people who are still part of Informal today, and who continue to play key roles in Cosmos. These people have some of the most advanced understandings of the Tendermint and IBC protocols and software in the whole world, and have been instrumental in their development.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"At the ICF, both Ethan and Jae served on the Foundation Council. The history between them made things difficult for the new team there, especially when it came to longer term planning and collaboration on the core Cosmos software with Jae and AiB. So the ICF’s R&D team was motivated and encouraged to instead work on formal methods, the development of key pieces of Cosmos in Rust (like tendermint and IBC), and to think about spinning out. The team was also eager to build a long term sustainable business, and to take a more active role in governing their organization. By the end of 2019, the ICF’s Foundation Council ultimately agreed for most of the team at the ICF, then around 12 people, to spin out into a new, employee-owned company to work on formal specification of the Cosmos protocols and initial implementations in Rust.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"In January 2020, the ","nodeType":"text"},{"data":{"uri":"https://interchain-io.medium.com/past-present-future-icf-r-and-d-introducing-informal-systems-e50d14383f05"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"team spun out of the ICF","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" into the newly incorporated company, Informal Systems. Informal was structured as a ","nodeType":"text"},{"data":{"uri":"https://informal.systems/blog/informal-owners"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"workers cooperative","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", with each employee receiving a single voting share once they had been with the company for 9-months (the gestation period of a human). Informal’s mission was to bring verifiability to distributed systems and organizations, and it set to work on formal methods and rust development within Cosmos.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"At this point, Jae was still running AiB, which had 10% of the ATOM supply and had grown to some 50 people, with contracts from the ICF to lead Cosmos development. The ICF had also been granted 10% of the initial ATOM supply, and was managing its reserves of BTC and ETH from the Cosmos fundraiser. By late 2019, the value of ATOM and the ICF's treasury had appreciated considerably. Ethan, as the other founder of Cosmos, and Arianne, who had been leading the foundation, would thus spin out the R&D team they had built at the ICF into a small new company, owned by its employees, working on formal methods and Rust, with a couple years of funding from the ICF, while AiB continued to lead the core.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"But at the same time Informal was planning to spin out, independent challenges were mounting at All in Bits. By ","nodeType":"text"},{"data":{"uri":"https://interchain-io.medium.com/sustainability-of-the-cosmos-network-a-statement-from-the-interchain-foundation-c96ef0975f5"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Feb 2020","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", less than two months after Informal was born, virtually the entire ","nodeType":"text"},{"data":{"uri":"https://medium.com/tendermint/an-update-about-the-state-of-all-in-bits-inc-dba-tendermint-inc-e5cdc22661ee"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Cosmos engineering team quit AiB","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". While AiB significantly reduced its contributions to core development, the company retained its large ATOM treasury. Still today, more than three years later, while Informal has grown to become the largest core developer in Cosmos and the lead developer of the Cosmos Hub, Informal’s total ATOM holdings represent less than 0.2% of the total ATOM supply. Informal remains committed to improving the health and sustainability of the Cosmos Hub and interchain development ecosystems.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Spin Out","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"Initial funding for Informal came from the ICF, and was structured in three forms: a convertible note investment, a deliverables-based software development agreement, and a research grant. Informal would take payments in a diversity of assets from the ICF, including ATOM, BTC, ETH, and fiat, and would structure its operations to limit the amount of ATOM it sold. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The ICF’s ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"convertible note investment","nodeType":"text"},{"data":{},"marks":[],"value":" in Informal was for $2.5M, and would give the ICF a future stake in Informal, plus interest. As part of the spin-out and investment, Michael Niederer, the CFO of the ICF, was elected to Informal’s Board of Directors. While Informal was intended to develop an independent sustainable business, and has since inception set goals to reduce the proportion of its funding from the ICF, it was important for Informal to be aligned with the Cosmos mission and to support key public goods. Indeed, over the years, as pieces were missing in core Cosmos development, Informal would prioritize the Cosmos mission over its own business development and seek to fill the gaps.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Informal’s ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"software development agreement","nodeType":"text"},{"data":{},"marks":[],"value":" with the ICF included a number of formal protocol specifications and software deliverables, expected to be delivered over the course of two years. Deliverables included formal specs of all IBC and tendermint subprotocols to support their security, verification, understanding, and implementation. They also included a Rust implementation of the IBC relayer (which would become ","nodeType":"text"},{"data":{"uri":"https://github.com/informalsystems/hermes"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"hermes","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"), the ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/ibc-rs"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"IBC handlers","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" (now being used by Anoma, Nomic, and others), as well as pieces of a new consensus engine (a fabled “Tendermint in Rust”). The goal of this development was to increase the security of the Cosmos software and protocols, and to successfully expand the Cosmos ecosystem into Rust - goals which were all achieved, and which continue to be renewed. While Cosmos in Rust is flourishing today, the effort to develop Tendermint in Rust was ultimately put on hold in order to prioritize supporting, and eventually leading, the core Tendermint project in Go, which in 2023 was ","nodeType":"text"},{"data":{"uri":"https://medium.com/the-interchain-foundation/cosmos-meet-cometbft-d89f5dce60dd"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"forked into CometBFT","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"In addition to the software development agreement, Informal received a ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"research grant","nodeType":"text"},{"data":{},"marks":[],"value":" payable over 2 years, to work on protocol design, applied formal methods research, formal verification, and testing of Cosmos software and protocols. The research funding was intended to support a growing team and bootstrap a longer term research function in the Cosmos ecosystem with the potential to meaningfully transform computing - making software more understandable, verifiable, and correct. In this regard, Ethan, Informal, and Cosmos have long been inspired by the Sun Microsystem’s mission: to kick butt, have fun, don’t cheat, love our customers, and change computing forever. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"To change computing, Informal wanted to make formal methods more accessible and useful to software projects and engineers, providing them with a developer friendly specification experience that integrates well into their software development lifecycle. This is a long-term goal, and will take years to fully realize. Informal has from the beginning pursued a strategy that balances longer term R&D on the formal methods toolchain with more direct application to the Cosmos software and protocols. This has allowed us to build open source tools like the ","nodeType":"text"},{"data":{"uri":"https://github.com/informalsystems/apalache"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Apalache","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" formal methods engine and our new specification language ","nodeType":"text"},{"data":{"uri":"https://github.com/informalsystems/quint"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Quint","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", but to also focus on protocol design and audits on core Cosmos protocols and software, formally verifying key protocol properties, techniques to verify IBC in Rust, and open-source tooling to improve specs, testing, understanding, and verifiability across the Cosmos stack. This work has in turn served as an attractor for world class researchers and engineers towards the Cosmos ecosystem.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Up Next","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"Over the years, Informal grew from these humble beginnings to become the largest core development team in Cosmos, leading development of core products like CometBFT, the Cosmos Hub, and Hermes, and contributing to many more. In the next post, we'll go into detail on Informal's work and funding, highlighting essential technologies at the heart of the interchain and what's in store for their future. Stay tuned!","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"contentfulURL":"https://app.contentful.com/spaces/p79kctcd7ahy/entries/2z8BOvuhzUGxVONRW1U0W1"},{"featureImage":"$4:props:posts:8:featureImage","date":"2023-03-14","title":"Cosmos Hub Governance Spam Mitigation - Filtering Proposals with High Veto Rates","slug":"governance-proposal-spam","categories":["Engineering"],"authors":["Jehan Tremback"],"keywords":"cosmos-governance-spam, proposal-filtering, no-with-veto, governance-security, spam-mitigation, block-explorer-filtering, cosmos-hub-governance, malicious-proposals, deposit-period-spam, governance-protection","excerpt":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"How block explorers can filter spam proposals using voting patterns and deposit thresholds.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"body":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Recently, spammers have been targeting the governance system of the Cosmos Hub, as well as other Cosmos chains. They create governance proposals containing malicious links in the hopes that someone will click on them.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"With spam, the name of the game is exposure. Get your malicious content in front of as many people as possible, and some small percentage of them will click on it. Unfortunately, spammers have discovered that they can use the Cosmos governance system to trick prominent websites like block explorers and wallets into displaying spam.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"How does this work? In Cosmos governance, anyone can submit a proposal with any text that they want. There is also a deposit attached to the proposal. If the deposit is below 250 Atom (~$3k), then the proposal is considered to be in the “deposit period”. If the deposit is above 250 Atom, the proposal is in the “voting period”. Once the proposal is in the voting period, if it is vetoed, the deposit is burned.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Cosmos full nodes have an API endpoint called gov/proposals which displays proposals. Wallets and block explorers turn this endpoint into webpages which they display to the public. They will generally allow users to filter to view only deposit period proposals or only voting period proposals.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The intended operation of Cosmos governance is that while spammers could create spam proposals, they will not want to deposit enough Atoms to put them into the voting period. The idea is that although there may be spam proposals in the deposit period, nobody will look at these.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The spammers first tried just creating spam for free in the deposit period. This worked for a short while, but websites just stopped displaying deposit period proposals prominently. Even so, the Cosmos Hub and many other chains are rolling out upgrades to make it so that even deposit period proposals must have a minimum deposit.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"But now, the spammers have started supplying the full deposit amount along with their proposals. Apparently they are making enough money that burning 250 Atoms is worthwhile, or they have some other motivation. We don’t think that raising the deposit amount is a good idea. 250 Atom is already a high bar for community members who want to make their ideas heard, and it’s unclear how high it would need to be raised to make things unprofitable for spammers.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We think there’s a better solution. What is the thing that spammers want to accomplish? They want to get their spam proposal displayed prominently. The key here is that it is not useful to spammers if their proposal is buried on an internal page like ","nodeType":"text"},{"data":{"uri":"https://www.mintscan.io/cosmos/proposals/647"},"content":[{"data":{},"marks":[],"value":"https://www.mintscan.io/cosmos/proposals/647","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". A link to their proposal must be visible on a prominent page like ","nodeType":"text"},{"data":{"uri":"https://www.mintscan.io/cosmos/proposals"},"content":[{"data":{},"marks":[],"value":"https://www.mintscan.io/cosmos/proposals","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"So to fix the spam problem, without impacting the ability for community members to submit legitimate proposals, it is simply necessary for websites to filter their main proposal list. By performing extra filtering on the output of gov/proposals, websites can remove almost all spam proposals. Spam proposals could still be created, and can even still be displayed on their individual pages, but they will not appear in the prominent front page proposals list.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"But what criteria should be filtered by? One thing that spam proposals all have in common is that they have an extremely high rate of “No With Veto” votes. Anyone seeing a spam proposal votes No With Veto immediately. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"To filter out spam proposals it is sufficient to filter the proposals list to remove all proposals with a No With Veto rate of more than 90%. This should probably be calculated differently than it usually is, to exclude “Abstain” votes from the proposal, since many accounts abstain automatically on every proposal. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"This may still allow spam proposals to be visible immediately after they have been created, when there hasn’t been a chance for a lot of people to veto them yet. For this reason, we can add an additional rule, which excludes proposals that have less than 1% of Atoms voting.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We finally filter out proposals that have less than 10 Atoms deposited. These deposit period proposals can still be created, but they won’t be displayed prominently.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We may add these rules directly to the full node API in an upcoming release, but websites can easily implement them right now. Here’s some code showing how:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"7wszHE29YWfAXAkooHpDhJ","type":"Entry","createdAt":"2023-03-14T00:18:39.891Z","updatedAt":"2023-03-14T00:38:31.904Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":7,"revision":2,"contentType":{"sys":{"type":"Link","linkType":"ContentType","id":"codeSnippet"}},"locale":"en-US"},"fields":{"language":"javascript","code":"let proposals_displayed = proposals_loaded.filter((proposal) => {\n // Filter out proposals with more than 90% no with veto votes,\n // excluding abstain from the calculation\n let total_votes =\n proposal.tally.yes +\n proposal.tally.no +\n proposal.tally.no_with_veto;\n\n let percentage_nwv = proposal.tally.no_with_veto / total_votes;\n if (percentage_nwv > 0.9) {\n return false;\n }\n\n // Filter out proposals with less than 1% of Atoms voting\n let percentage_voting = total_votes / bank_atoms;\n\n if (percentage_voting < 0.01) {\n return false;\n }\n\n // Filter out proposals with less than 10 Atoms deposited to\n // deal with deposit period spam\n if (proposal.total_deposit[0].amount < 10000000) {\n return false;\n }\n\n // Otherwise display the proposal\n return true;\n});"}}},"content":[],"nodeType":"embedded-entry-block"},{"data":{},"content":[{"data":{},"marks":[],"value":"Mintscan has implemented these rules, and as a result they are now spam free. Keplr is using a different system (which predates this blog post) to eliminate spam, and that’s also working well. We urge any other websites, apps, and chatbots that display governance proposals to implement these rules to stop spam.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"contentfulURL":"https://app.contentful.com/spaces/p79kctcd7ahy/entries/2XweDbpEecVUiVCm7IoGLz"},{"featureImage":"$4:props:posts:29:featureImage","date":"2023-03-08","title":"Cosmos Hub February 2023 Update - V8 Upgrade and V9 Replicated Security Progress","slug":"february-update-2023","categories":["Engineering"],"authors":["Jehan Tremback"],"keywords":"cosmos-hub-february, gaia-v8-upgrade, replicated-security-v9, cosmovisor-issues, time-drift, equivocation-verification, governance-spam, deposit-period-spam, voting-period-spam, upgrade-coordination\n","excerpt":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Monthly update covering Cosmovisor issues, time drift, and equivocation verification.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"body":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"It’s time for the February update from the Informal Cosmos Hub team! Last month we were busy with the v8 and v9 upgrades, as well as longer term product planning, and dealing with some small issues.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"V8 upgrade went live","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"The V8 upgrade passed and went live in February. It was a smooth upgrade, with zero downtime. However, there were a number of validators that missed the upgrade and so were down for a little while afterwards. It wasn’t enough to actually lead to any downtime of the chain itself, but it did highlight some shortcomings in our process that we have now corrected.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Cosmovisor issues","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"Cosmovisor is a piece of software that validators use to automatically switch the chain to a new binary at the right time to have a successful upgrade. Many validators use Cosmovisor, but some still switch binaries manually. From v1.2.0 onwards, Cosmovisor switched how it deals with capitalization of folders where it looks for the new version of the chain. This caused issues for some validators.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Time drift","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"Due to Cosmos Hub block times speeding up slightly during the voting period, the go-live time of v8 shifted earlier by 13 hours. This is a normal thing that can happen on any Cosmos chain. Some validators did not know about this, and so did not upgrade at the right time. All validators should check block heights to stay aware of shifting upgrade times, but to make things easier, we are proactively reaching out to validators going forward to inform them of the latest time estimates for upgrades.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"V9 upgrade passed","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"Together with our partners at Hypha, who handle testnets and upgrade releases, we got the v9 release with Replicated Security up for voting, and it passed! This has been discussed extensively elsewhere, so I’ll just link to the ","nodeType":"text"},{"data":{"uri":"https://www.mintscan.io/cosmos/proposals/187"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"proposal","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". The new code will go live around March 15th.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"V10 upgrade is under development","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"We are currently putting together the v10 release. We’ll update with further details on what v10 will contain as we get closer to release.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Equivocation verification","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"We’ve been working on the necessary code to allow equivocation (double signing etc.) evidence from consumer chains to be verified cryptographically on the Cosmos Hub. The addition of this code will allow us to remove the governance-gating of slashes from consumer chains discussed ","nodeType":"text"},{"data":{"uri":"https://informal.systems/blog/governance-gated-vs-automatic-equivocation-slashing"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"here","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Working together with the Hermes, Comet, and IBC-Go teams, ","nodeType":"text"},{"data":{"uri":"https://docs.google.com/document/d/1fe1uSJl1ZIYWXoME3Yf4Aodvz7V597Ric875JH-rigM/edit#heading=h.rv4t8i6d6jfn"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"we found","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" that much of the code required to generate equivocation proofs exists already in Hermes, and much of the code required to verify them exists in IBC-Go. Hopefully this will speed implementation. We will update when we have a concrete implementation plan.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Spam issue","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"Unfortunately, there has been some spam created in the Cosmos Hub governance proposals. This has taken place in two ways: deposit period spam, and voting period spam. They are different, and I will cover them separately.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Deposit period spam","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"Before a proposal goes up for voting, it must first receive a deposit of 250 Atoms. This deposit will be burned if the proposal is vetoed by governance. The deposit is meant to prevent spam proposals from entering the voting period, since spam will be vetoed, costing the spammer a lot of money. In the current design of Cosmos-SDK governance, it is intended that spam proposals will stay in the deposit period and never make it into the voting period.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"However, it is possible on many wallets and block explorers to see proposals that are still in the deposit period. Even though part of the intended design of governance originally was there might be spam in the deposit period, it doesn’t look good and there is a little bit more we can do to fix it. By making it so that proposals must be given a certain minimum deposit by the creator of the proposal to even enter the deposit period, we can make it more expensive to submit spam proposals, even in the deposit period. This fix was deployed on Juno and other chains.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"This is a change which must be done as part of a coordinated upgrade. We already have the v9 upgrade rolling out soon, so in consultation with Notional and other core teams, we have decided not to call for an emergency upgrade just to fix the deposit period spam issue.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"However, our team has worked out ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/gaia/pull/2262/files"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"a way to fix the issue without a coordinated upgrade","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". We’ll be releasing a patch soon which can be installed by validators individually without a coordinated upgrade, and will stop the deposit period spam once all validators have installed it.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Voting period spam","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"A spam proposal has recently entered the voting period. This is a completely different matter than what is discussed above. The spammer decided that it was worth paying 250 Atoms ($3000) to get this proposal into the voting period. We encourage you to vote No With Veto on this proposal, so that the spammer loses their funds.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"contentfulURL":"https://app.contentful.com/spaces/p79kctcd7ahy/entries/4jUuQFYEVGi6Pky0Vj6GVF"},{"featureImage":"$4:props:posts:30:featureImage","date":"2023-03-08","title":"Cosmos Hub 2023 Development Roadmap - Replicated Security and Governance Improvements","slug":"cosmos-hub-living-roadmap-2023","categories":["Engineering"],"authors":["Jehan Tremback"],"keywords":"cosmos-hub-roadmap, replicated-security-improvements, opt-in-security, mesh-security, governance-improvements, consumer-chains, soft-opt-out, fraud-proofs, hub-operations, model-based-testing","excerpt":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Comprehensive living roadmap covering customer needs, operations, and interchain security future.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"body":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"This is the roadmap for the Informal Cosmos Hub team for 2023. Not everything in here is totally planned out in full detail and it is subject to change. The items on this list are not arranged in chronological order, but instead by topic.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Understanding our Customers","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"The Hub team is responsible for stewarding the needs of the following five types of users:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Atom holders","nodeType":"text"},{"data":{},"marks":[],"value":". This includes both the wider Atom holding community and also power users. Ordinary users will require clear and concise documentation. Power users will use the Gaia application to perform administrative tasks and therefore will require appropriate detailed documentation and error messages from the application.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Validators","nodeType":"text"},{"data":{},"marks":[],"value":". It is beneficial for the Hub team to understand validators' concerns and processes. This includes understanding best practices for validator deployments, key management issues, hardware/software configurations (arm/intel/linux/windows), operational monitoring and troubleshooting typical issues in production and a knowledge base to help with quick resolution.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Consumer chains","nodeType":"text"},{"data":{},"marks":[],"value":". The Hub team will need to provide development support, testnet guidance and governance support for consumer chains joining the Hub validator set. Updates to Interchain Academy?","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"3rd party integrators.","nodeType":"text"},{"data":{},"marks":[],"value":" (Wallets, Block Explorers and other common infrastructure builders). 3rd party integrators build products and features based on the Hub. A healthy dialogue with these participants will ensure that cutting edge and innovative features are prioritized for the Hub ecosystem.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Open source contributors","nodeType":"text"},{"data":{},"marks":[],"value":" (such as Notional and A42). The Hub team are stewards of the Gaia project. To have a healthy sustainable future, external contributors should be encouraged to contribute both to new features, improved documentation and participation via testnets.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"Hub Operations","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"These are the results having to do with healthy software development and security practices around Cosmos Hub releases, and Cosmos Hub running in production. These results will be the same no matter what priorities are for features further down in this document.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Improve Hub upgrade cadence and speed","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"We’d like to focus on having small and regular Cosmos Hub upgrades. Generally, the smaller and more regular software updates are, the smoother they are. We will keep this objective in mind with everything else we do. A few items related to this are:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Do as much testing as possible on a continuous basis to avoid last minute surprises.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Do “practice releases” on a more frequent cadence that never make it to mainnet but still exercise all of our release processes.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Figure out how to deal with last minute timeline slippage- do we build in a buffer?","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"Continue implementing good production practices","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"Even though the Cosmos Hub is a decentralized network, our team has a big role to play ensuring that any liveness or safety issues are dealt with in a timely manner. A few items related to this are:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Establish a process for technical monitoring, either on our own infrastructure or in collaboration with validators.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Establish a process for social monitoring, providing a way for community members to report current or potential issues to us.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Establish some form of on-call rotation to have knowledgeable personnel available at all times to respond to issues and provide guidance to the validator community.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Establish partnerships with other Cosmos Hub stakeholders to coordinate on the items above.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"Launch and update consumer chains successfully","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"Launching and updating consumer chains will require a great deal of coordination between the chains teams and the Cosmos Hub validator set. We need to be on top of this, because any failures of communication could harm replicated security by giving it the reputation of slowing down upgrade cycles for consumer chains vs standalone chains. Also, confusing or difficult upgrades raise the strain of running replicated security for validators. Items related to this:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Continue to support consumer chain teams with replicated security integration.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Support consumer chains politically through the launch governance process.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Establish a process to support consumer chain teams in the persistent testnet run by Hypha.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Establish a process to notify validators of upgrades in consumer chain governance.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Set guidelines for consumer chain updates to be small and regular, including possibly recommending upgrade windows.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Establish a process to get emergency security upgrades of consumer chains to Hub validators.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"Implement and use MBT techniques","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"Great strides have been made in the testing and release process of the Cosmos Hub in the past year by the teams at IG and Hypha. However, we can continue to build on this using the model based testing expertise at Informal. At the same time we can decrease the testing and verification load on feature developers on the team, and also move the state of the art of model based testing forward. Some items related to this:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Adapt existing MBT-style integration and diff tests in CCV repo to work with Atomkraft","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Adapt existing integration tests in Gaia repo to work with Atomkraft","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Optimize test running speeds with Tendermock etc","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Set up soak test infrastructure","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Set up automated stateful release tests","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"Replicated security improvements","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"There are a long list of improvements that we would like to make to replicated security. These range from fundamental changes to the protocol, to minor code cleanup tasks. These improvements will make replicated security safer, while also reducing the load on validators and governance. Ultimately, this will let more consumer chains be deployed more quickly and easily, increasing fees going to the Cosmos Hub.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Seamless consumer chain onboarding and offboarding","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"We want it to be possible for standalone chains to onboard smoothly to being consumer chains without having to manually update their IBC connections to other chains. We also want it to be possible for consumer chains to offboard to other forms of security without having to manually update IBC connections. Offboarding is a little bit more complicated since we also have to answer the question of what the new validator set will be. Additionally, enabling offboarding to mesh security is a major strategic goal, and something that consumer chains are already expecting.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Soft opt-out","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"In soft opt-out, we allow validators in the bottom 10-20% of the active set to opt out of validating consumer chains. This could be as simple as checking a validator’s position in the set when receiving a downtime jailing packet and not jailing them if they are in the bottom 20% by power.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"This mechanism will alleviate a lot of the concerns about RS not being profitable enough for small validators to be able to run many consumer chains, without changing any core assumptions of RS.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Some quick napkin math: ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The smallest validator in the Hub active set currently (as of early March 2023) has 36,459 atoms delegated to it. At a 5% commission rate, this validator may make 414 Atoms per year in commission. At $12 per atom, that’s around $5000 per year, or $416 per month. With Cosmos nodes having typical operating expenses of $200-$600 per month, running just one consumer chain could make this small validator unprofitable.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The smallest validator in the top 80% has 1,126,938 atoms staked, for an estimated $155,517.44 in annual commissions, or $12,959.78 per month. Running extra consumer chain nodes with this budget is a very different calculation.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Cryptographic verification of equivocation evidence","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"As designed, ICS trusts consumer chains to honestly report equivocation by their validators by sending slash packets. This is OK in theory for replicated security if consumer chain code is well audited, but if there is an exploit in the code, it could slash validators unfairly. It cannot work at all for opt-in security or mesh security. Because of the concerns about this we have several mitigations in place: a throttle that doesn’t let too many slash packets through at once, and we have gated this slashing behind a governance proposal, so that the proposal must pass after the slash packet is received.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"These mitigations prevent any serious issues but it would be nice not to have to rely on them. In theory it is possible to cryptographically verify equivocation evidence on the provider chain. This is not trivial, but much of the work may already be done in IBC-Go and Hermes relayer.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Cryptographic verification of downtime","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"In RS, we jail validators on the provider chain who are down on any consumer chain. Currently, this is also done by trusting a jailing packet from the consumer chain, but this has the same potential for issues as trusting equivocation slashing packets. However, we have implemented a throttling mechanism which should stop a catastrophic attack.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"It would be better to have some form of cryptographic verification of downtime on consumer chains so that no throttling is needed. This is probably possible by looking at the ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Other wishlist features","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"There is a whole backlog of various major and minor other improvements to replicated security which I’m not going to list and prioritize here. There are also general improvements to our Cosmos-SDK programming patterns that we would like to make, especially having to do with database access.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Interchain security future","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"We need to keep innovating to ensure that the Cosmos Hub is not only a pioneer of interchain security, but also remains a leader long term. The ideas here are less well-defined than in other sections of this document.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Opt-in security","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"The ","nodeType":"text"},{"data":{"uri":"https://informal.systems/blog/replicated-vs-mesh-security#risks-of-opt-in-security-also-known-as-ics-v-2"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"validator opt-in subset problem","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" is avoided if consumer chains are fraud-provable. With fraud proofs, we can be certain that if the validators validating a consumer chain have (for example) $10m staked on the provider, that chain cannot be attacked without that $10m being slashed. This is not the case without fraud proofs.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"By making consumer chains fraud-provable, we can enable opt-in security. Opt-in security allows each validator to decide whether or not to validate a certain consumer chain.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"What is the difference between opt-in security and a rollup settlement layer as envisioned by Celestia, Ethereum, and others? Both use fraud proofs. With rollups, a mandatory waiting period on cross-chain transactions from the rollup allows any fraud to be rolled back with a fraud proof before any money is permanently stolen.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"This waiting period is a huge complicating factor for any cross-chain application development on a rollup. Opt-in security removes this waiting period by slashing validators who commit fraud instead of making users wait for withdrawals.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Alternatives to fraud proofs","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"Fraud proofs are exciting, but are still an area of ongoing development. There are very few functioning implementations, and nothing that works with Cosmos-SDK yet, as far as we know.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"But there are alternatives to a full and efficient fraud-proving Cosmos-SDK VM. For example, a governance proposal could be used to slash validators who attack a consumer chain. This needs careful consideration. This could allow the Cosmos Hub to ship this valuable technology more quickly, but many are uncomfortable with such a governance proposal. We’ll be working to gauge the community’s appetite for this type of feature. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Mesh security","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"Mesh security is an elegant solution to enable what we refer to as Layered Security (ICS v3). Given that this has always been a long term goal for interchain security, mesh security should be a key focus for us. Also, mesh security will likely be a big presence in the interchain security space. The Cosmos Hub has the potential to be a leader in providing mesh security, and so we should make sure we are involved from day one to shape and lead the adoption of mesh security.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"However: ","nodeType":"text"},{"data":{},"marks":[],"value":"Like Opt-in Security, Mesh Security is not secure without fraud proofs or an alternative to fraud proofs.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Analysis and implementation of mesh security","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"Our team has already informed the creation of mesh security. We did the first and only ","nodeType":"text"},{"data":{"uri":"https://informal.systems/blog/replicated-vs-mesh-security"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"analysis","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" of how much economic security mesh security will actually provide in various scenarios. Given that the *only* thing that mesh security provides is economic security (versus the full-service validator set provided by replicated security and Opt-in Security), this analysis is foundational to the concept.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We will stay involved in the design and implementation of mesh security, both to ensure that it is secure enough to run on the Cosmos Hub, and so that we have in-house expertise allowing us to lead adoption.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Display cost to censor and cost to control on block explorers","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"Before we introduced the cost to censor/cost to control analysis of mesh security, nobody had any idea how much security it would even provide. Since the only thing that mesh security provides is economic security, this information is key. The Cosmos Hub also benefits from this key security information being displayed publicly because the Cosmos Hub has so much security to provide. Users having the ability to check the security of mesh secured chains will tend to lead chains to consume security from the Cosmos Hub because it will improve their cost to censor and cost to control by a lot.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"To this end, we will maintain relationships with prominent block explorers, and provide them assistance and code to display the security of mesh secured chains prominently on their dashboards.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Mesh security chain launch platform","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"The Cosmos Hub could be a great platform for mesh-secured chains to launch on. It could leverage it’s large market cap and mature validator set to get consumer chains started off right. By submitting a governance proposal (or even a transaction) on the Cosmos Hub, a chain could provide a place for validators to sign up to join its validator set and for delegators to delegate to those validators. When the chain launched, it would have a validator set, as well as a large amount of security from all the assets staked on it from the Hub. It could then go out and get mesh security from other chains as well.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Governance improvements","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"The need for better governance on the Cosmos Hub is great. The ICF’s ongoing funding will not last forever, and it’s time for the Cosmos Hub to be able to fund its own improvements. In 2024 we hope to get a significant amount of the funding of this team from the community pool. This goal also helps us think more deeply about which improvements are needed.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We haven’t spent as much time thinking about these things as we have about the details of Interchain Security, so they will need to be fleshed out more. We’ll release a report and update this roadmap when they are better planned.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Deliberation improvements","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"The current voting system has some shortcomings. Proposals are strictly all-or-nothing affairs and could use some more nuance. Oftentimes, people vote YES on a proposal that could use some changes because they like the overall direction. Or they vote NO on a proposal that they support some parts of but not all. We’ll be talking to different stakeholders, and brainstorming ways to make the governance system more flexible. We’ll then work with the Cosmos-SDK to help implement anything that seems promising. Some initial ideas:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Multiple-choice proposals to allow creators to present a range of options","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"A “Revise and Resubmit” vote with the same effect as No, but demonstrating support of the proposal’s overall direction","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"Funding improvements","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"Currently, community pool funding is clumsy. It consists of funding proposals that go to the entire community for voting and disburse one time grants. This means that funded projects need to request large one time sums, to avoid having to continuously make smaller proposals (fighting for your paycheck every quarter). These large sums either get voted down because voters are worried about accountability, or they indeed are spent without enough accountability. Some initial ideas:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Streamed funding to disburse a percentage of community pool inflation continuously to a group","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Stabilized funding to adjust the amount with the Atom price","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Endowment funding, giving a recipient the ability to stake a number of Atoms and earn staking rewards, without giving them permanent control of the principle\n","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"contentfulURL":"https://app.contentful.com/spaces/p79kctcd7ahy/entries/5LuJx28gHjvjZAuqdTlt45"},{"featureImage":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"1jZbPpD0Ij5tROMU166LJr","type":"Asset","createdAt":"2024-08-16T06:42:17.831Z","updatedAt":"2024-08-16T06:42:17.831Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":3,"revision":1,"locale":"en-US"},"fields":{"title":"Blog Namada","description":"","file":{"url":"//images.ctfassets.net/p79kctcd7ahy/1jZbPpD0Ij5tROMU166LJr/dfaef857a0cf4a520a044350a3e2f175/Blog_Namada.jpg","details":{"size":304071,"image":{"width":1920,"height":1080}},"fileName":"Blog_Namada.jpg","contentType":"image/jpeg"}}},"date":"2023-03-03","title":"Is Namada’s Cubic Proof-of-Stake Secure?","slug":"checking-namada-proof-of-stake","categories":["Audits"],"authors":["Manuel Bravo"],"keywords":"namada-cpos, cubic-proof-of-stake, formal-verification, tla-plus-modeling, apalache-model-checker, epoched-staking, slashing-verification, pos-security, invariant-checking, formal-methods-audit","excerpt":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Formal methods approach to verifying epoched staking and slashing mechanisms.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"body":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Is Namada’s Cubic Proof-of-Stake Secure?","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"This post goes through the work done by Informal to formally model the Proof-of-Stake system of Namada. ","nodeType":"text"},{"data":{"uri":"https://namada.net/"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Namada","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" is a proof-of-stake L1 for interchain asset-agnostic privacy. Namada is built on top of ABCI and enables multi-asset shielded transfers for any native or non-native asset. Namada is the first fractal instance in the Anoma ecosystem.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"First, we introduce Namada’s Cubic Proof-of-Stake (CPoS). We then describe how we use formal methods to automatically check some interesting invariants. We describe the process of modeling Namada’s PoS system in TLA+, and what invariants we decided to check and why. Finally, we present a short tutorial on how to check Namada’s adherence to these invariants using Apalache, our model-checker.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Ultimately, we want you to walk away from this post with:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"A high-level idea of how Namada’s CPoS mechanism works and the major differences with the CosmosSDK’s PoS.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"How we approached the problem of formal modeling a PoS system and checking basic properties.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Which properties are important to check in a PoS system.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"ordered-list"},{"data":{},"content":[],"nodeType":"hr"},{"data":{},"content":[{"data":{},"marks":[],"value":"Namada’s Cubic Proof-of-Stake","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"","nodeType":"text"},{"data":{"uri":"https://specs.namada.net/economics/proof-of-stake.html"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"The proof-of-stake mechanism of Namada","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" is largely modeled after Cosmos’s proof-of-stake but makes significant changes to the bonding mechanism, reward distribution, and slashing. The three mechanisms contribute to securing Namada by incentivizing participants to behave correctly, i.e. follow the protocol. The bonding mechanisms and slashing make misbehavior very expensive while rewarding and incentivizing participation.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"In the remainder of this section, we discuss Namada’s bonding mechanism and slashing approach, which is the focus of our work. Reward distribution is modeled as a variant of the ","nodeType":"text"},{"data":{"uri":"https://drops.dagstuhl.de/opus/volltexte/2020/11974/pdf/OASIcs-Tokenomics-2019-10.pdf"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"F1 fee distribution model","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Epoched staking","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"Namada divides the execution into epochs. The duration of an epoch is determined by a minimum of blocks and time. Namada performs an epoch change when both minima are reached at the current epoch. By default, the duration of an epoch lasts about 24 hours.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"In Namada, actions related to PoS do not happen immediately but at an epoch offset, i.e., a number of epochs into the future. For instance, if a user delegates tokens to a validator, the validator’s voting power is not updated immediately but at the beginning of the epoch resulting from adding an epoch offset to the current epoch. Namada defines two epoch offsets: pipeline and unbonding offsets, and requires the pipeline offset to be less or equal to the unbonding offset. By default, the pipeline offset is 2 epochs and the unbonding offset is 21 epochs.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Bonding mechanism","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"At a given epoch, only the validators with the most voting power (limited up to a configurable parameter) are selected for the consensus validator set. The voting power of a validator is determined by the total bonded tokens, which is a combination of the amount of delegated and self-bonded tokens. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"A user may delegate tokens to any number of validators. When a user has some tokens bonded to a validator, the tokens are locked up: the user cannot use these tokens for other purposes, e.g., delegating them to another validator or transferring them to another address. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"To recover their tokens, a user must first issue an undelegate action to unbond them. Unbonding tokens from a validator implies updating the validator’s voting power and possibly the consensus validator set. Nevertheless, a user does not recover their tokens immediately. A user can recover their tokens only after a fixed number of epochs from the moment they issued the undelegate action (aka the unbonding period). Once this period has passed, the user can claim their unbonded tokens by issuing a withdraw action, which moves the tokens from the PoS account to the user’s personal account.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Updates to validators’ voting power due to delegation and undelegations are effective after the pipeline offset. The unbonding period lasts pipeline offset + unbonding offset epochs.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Validators","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"Any user that is not a validator already and has no delegations may request to become a validator. Fresh validators are initialized in candidate state. That a validator is a candidate implies that it is considered for block creation and can receive delegations. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"A validator may become inactive by issuing a deactivate action. An inactive validator is not considered for block creation and cannot receive any new delegations. An inactive validator may become a candidate again by issuing a reactivate action.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Validator-related actions such as becoming, reactivating, and deactivating a validator become effective at the pipeline offset.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Slashing","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"An important part of the security model of Namada is based on making attacking the system very expensive. This is also a common principle of other Proof of Stake systems. To this end, when a validator’s infraction is detected, a fraction of the validator’s stake is slashed. Namada uses cubic slashing to compute this fraction: the amount of a slash is proportional to the cube of the voting power committing infractions within a particular interval of epochs.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Namada considers two types of offenses: equivocation in consensus and light client attack (as defined by Tendermint). Equivocation in consensus means that a block proposer has created two different blocks for the same height or that a validator has emitted conflicting votes for the same proposal. A light client attack means that a validator has violated the protocol and voted in a way that is not directly equivocation but could have potentially fooled a light client. Unavailability is not considered an offense at the moment.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[],"nodeType":"hr"},{"data":{},"content":[{"data":{},"marks":[],"value":"The process of modeling the proof-of-stake system","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"The first thing we did was to model Namada’s PoS mechanism using language-agnostic pseudocode. The full model can be found ","nodeType":"text"},{"data":{"uri":"https://github.com/informalsystems/partnership-heliax/blob/trunk/2022/Q4/artifacts/PoS-pseudocode/PoS-model.md"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"here","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". It specifies the data structures, transactions, and state machine handling logic of Namada’s PoS module for the bonding mechanism and slashing. Having a specification allowed us to build a common understanding (between Informal’s and Anoma’s teams) of Namada’s PoS system in a structured way. Furthermore, and more importantly, the model allows us to interact with Namada’s engineers and designers in a precise manner.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Our next step was to take the pseudocode model and transform it into a formal specification in TLA+. The main focus of our TLA+ model is to check that Namada’s epoched staking and slashing approaches are secure, e.g., if an infraction is discovered on time, the validator is always slashed. The main concerns are the following. First, due to epoched staking, data structures are updated at different epoch offsets depending on the operation. Second, slashing is scattered throughout the code. For instance, users are only slashed when withdrawing tokens that were delegated to a misbehaving validator, while the validator is slashed as soon as the infraction is discovered. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Simplifications","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"When modeling in TLA+, it is important to model only the essential parts, disregarding implementation details, but still capturing the important aspects of the protocol or system being modeled. In our case, considering the main concerns, our TLA+ model adopts the following simplifications: ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Namada’s PoS allows an arbitrary number of users and validators. Our model allows only a single validator and a bounded number of users. ","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Namada’s PoS allows executing multiple user transactions per epoch. Our model considers that the system executes a single transaction per epoch.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Our model considers that the validator can misbehave only once within an unbonding period and no more than twice in total. While this affects the completeness of the model by restricting the possible set of executions, it still allows us to check the properties we want, as we argue later.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"ordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"The goal of these simplifications is to drastically decrease the state needed to represent the model without changing its behavior in a manner that prevents us from checking the required properties.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"A walk-through the TLA+ model","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"},{"type":"underline"}],"value":"Modeling the state ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"","nodeType":"text"},{"data":{"uri":"https://github.com/informalsystems/partnership-heliax/blob/trunk/2023/Q1/artifacts/PoS-tla/StakingRepeated.tla#L34-L98"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"The main variables","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" defined by our model are: \$balanceOf\$, \$bonded\$, \$unbonded\$, \$totalDeltas\$, \$totalUnbonded\$, \$posAccount\$, \$slashPool\$ and \$slashes\$. Some of these variables are epoched. This means that the data is associated with a specific epoch.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"The variable \$epoch\$ keeps track of the current epoch.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"The variable \$balanceOf\$ keeps track of the balance of each user. ","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"The variable \$bonded\$ keeps track of the tokens that each user has bonded. For each user, the variable stores a set of bond records. A bond record has two fields. An \$amount\$ field that indicates the bonded amount, and the epoch at which the tokens were effectively bonded.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"The variable \$unbonded\$ keeps track of the tokens that each user has unbonded. For each user, the variable stores a set of unbond records. An unbond record includes the amount of unbonded tokens, the epoch at which the unbonded tokens were bonded, and the epoch at which the tokens are effectively unbonded (withdrawable).","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"The variable \$totalDeltas\$ keeps track of the validator’s stake at a given epoch. The stake is the sum of all bonds. This variable encodes the validator’s voting power at a given epoch.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"The variable \$totalUnbonded\$ keeps track of the set of bonds unbonded from the validator at a given epoch.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"The variable \$totalDelegated\$ keeps track of the stake that each user has delegated to the validator.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"The variable \$posAccount\$ keeps track of the balance of the PoS special account.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"The variable \$slashPool\$ keeps track of the total amount of slashed tokens.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"The variable \$slashes\$ keeps track of the already processed slashes. Each slash is represented by a slash record. A slash record includes the epoch of the infraction and a rate indicating how much should be slashed.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"$2b","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"},{"type":"underline"}],"value":"User transactions: the PoS system","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We model three user transactions: delegate, unbond, and withdraw. Following, we describe what each transaction does and how they modify the variables. We also include a simplified version of the TLA+ code that includes only the essentials to understand the transaction’s functionality. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The delegate transaction takes as arguments the user (\$sender\$) delegating the tokens and the \$amount\$ to be delegated. The function first checks that the user has enough tokens. It then takes the following steps:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"It transfers \$amount\$ from the user’s account to the PoS account. This is done by taking \$amount\$ from \$balanceOf[sender]\$ and adding it to \$posAccount\$. ","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Next, a new bond record is created and appended to \$bonded[sender]\$. In Namada’s PoS, delegation only takes effect after the pipeline offset, thus the start field of the bond record is set to the current epoch + the pipeline offset, and the amount field is set to \$amount\$.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Since the validator’s stake increases, we update \$totalDeltas\$ accordingly. ","nodeType":"text"},{"data":{},"marks":[],"value":"This only takes effect at the pipeline offset.","nodeType":"text"},{"data":{},"marks":[],"value":" ","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Finally, we update the sender's entry in \$totalDelegated\$ by adding \$amount\$.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"62TGzDJwkb04sDIx1oY4z7","type":"Entry","createdAt":"2023-03-02T20:52:46.377Z","updatedAt":"2023-03-03T15:55:53.048Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":18,"revision":7,"contentType":{"sys":{"type":"Link","linkType":"ContentType","id":"codeSnippet"}},"locale":"en-US"},"fields":{"language":"plaintext","code":"Delegate(sender, amount) ==\n /\\ amount <= balanceOf[sender]\n /\\ balanceOf' = [ balanceOf EXCEPT ![sender] = @ - amount]\n /\\ posAccount' = posAccount + amount\n /\\ bonded' = [ bonded EXCEPT ![sender] = @ \\union {[ start |-> epoch + PipelineLength,\n amount |-> amount,\n end |-> -1]}]\n /\\ totalDeltas' = [ totalDeltas EXCEPT ![UnbondingLength + PipelineLength] = @ + amount]\n /\\ totalDelegated' = [ totalDelegated EXCEPT ![sender] = @ + amount]"}}},"content":[],"nodeType":"embedded-entry-block"},{"data":{},"content":[{"data":{},"marks":[],"value":"The unbond transaction takes as arguments the user (\$sender\$) unbonding the tokens and the \$amount\$ to be unbonded. The function first checks that the user has enough tokens delegated that have not been unbonded yet. It then takes the following steps:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"It iterates over the bonds until the sum of all iterated bonds hits \$amount\$. This is computed by the \$ComputedUnbonds\$ function.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"The variable \$unbonded[sender]\$ is updated with the unbonds produced when iterating over the \$sender\$ bonds. For each iterated bond, the model creates a new unbond with ending epoch set to \$epoch\$ plus the sum of the pipeline and unbonding offsets. This means that those unbonds cannot be withdrawn until that epoch.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"It removes all the iterated bonds from \$bonded[sender]\$.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"It updates \$totalDeltas\$ and \$totalUnbonded\$ at the pipeline offset to account for the unbonded tokens.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Finally, we update the sender's entry in \$totalDelegated\$ by subtracting \$amount\$.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"2qdHXxcRCq2XFwaa6WrGNb","type":"Entry","createdAt":"2023-03-03T14:09:00.189Z","updatedAt":"2023-03-03T15:55:58.734Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":9,"revision":3,"contentType":{"sys":{"type":"Link","linkType":"ContentType","id":"codeSnippet"}},"locale":"en-US"},"fields":{"language":"plaintext","code":"Unbond(sender, amount) ==\n /\\ amount <= totalDelegated[sender]\n /\\ LET recordComputeUnbonds == ComputedUnbonds(amount, sender) IN\n /\\ unbonded' = [ unbonded EXCEPT ![sender] = @ \\union recordComputeUnbonds.unbondsToAdd ]\n /\\ bonded' = [ bonded EXCEPT ! [sender] = @ \\ recordComputeUnbonds.bonds\n /\\ totalDeltas' = [ totalDeltas EXCEPT ![UnbondingLength + PipelineLength] = @ - recordComputeUnbonds.takeTotalDeltas]\n /\\ totalUnbonded' = [ totalUnbonded EXCEPT ![UnbondingLength + PipelineLength] = recordComputeUnbonds.unbondsToAdd ]\n /\\ totalDelegated' = [ totalDelegated EXCEPT ! [sender] = @ - amount]\n"}}},"content":[],"nodeType":"embedded-entry-block"},{"data":{},"content":[{"data":{},"marks":[],"value":"The withdraw transaction takes as arguments the user (\$sender\$). The function withdraws all tokens that are fully unbonded: those unbonds whose ending epoch has been reached. The function takes the following steps:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"It computes the set of unbonds that meet the criteria.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"For each unbond, it applies any processed slash. This is done by the function \$ComputeAmountAfterSlashing\$, which also sums them all in \$amountAfterSlashing\$.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"It transfers \$amountAfterSlashing\$ from the \$posAccount\$ to the user’s account.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Removes the withdrawn unbonds.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"5a8UYsmO7UTd8MxQ1H9isf","type":"Entry","createdAt":"2023-03-03T14:09:31.447Z","updatedAt":"2023-03-03T15:56:06.768Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":4,"revision":2,"contentType":{"sys":{"type":"Link","linkType":"ContentType","id":"codeSnippet"}},"locale":"en-US"},"fields":{"language":"plaintext","code":"Withdraw(sender) ==\n LET setUnbonds == { unbond \\in unbonded[sender]: unbond.end <= epoch } IN\n LET amountAfterSlashing == ComputeAmountAfterSlashing(setUnbonds, sender) IN\n /\\ balanceOf' = [ balanceOf EXCEPT ![sender] = @ + amountAfterSlashing]\n /\\ posAccount' = posAccount - amountAfterSlashing\n /\\ unbonded' = [ unbonded EXCEPT ![sender] = @ \\ setUnbonds ]"}}},"content":[],"nodeType":"embedded-entry-block"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"},{"type":"underline"}],"value":"Allowed executions","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The behavior of the model is determined by the \$Next\$ operator. Our \$Next\$ operator looks as follows:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{"target":{"metadata":{"tags":[],"concepts":[]},"sys":{"space":{"sys":{"type":"Link","linkType":"Space","id":"p79kctcd7ahy"}},"id":"47leCC2WzbdGWDHM0ycWYz","type":"Entry","createdAt":"2023-03-03T14:09:58.000Z","updatedAt":"2023-03-03T15:56:01.818Z","environment":{"sys":{"id":"master","type":"Link","linkType":"Environment"}},"publishedVersion":4,"revision":2,"contentType":{"sys":{"type":"Link","linkType":"ContentType","id":"codeSnippet"}},"locale":"en-US"},"fields":{"language":"plaintext","code":"Next ==\n IF lastTx.tag \\in TRANSACTIONS\n THEN\n \\* move to the next epoch\n EndOfEpoch\n ELSE\n \\E sender \\in UserAddrs:\n \\E amount \\in Int:\n /\\ amount >= 0 /\\ amount <= MAX_UINT\n \\* e is picked such that it is not in the future or too far in the past.\n /\\ \\/ \\E e \\in Int: e <= epoch /\\ e >= epoch - UnbondingLength /\\ Evidence(e)\n \\/ Delegate(sender, amount)\n \\/ Unbond(sender, amount)\n \\/ Withdraw(sender)"}}},"content":[],"nodeType":"embedded-entry-block"},{"data":{},"content":[{"data":{},"marks":[],"value":"It alternates a user transaction with an \$EndOfEpoch\$ event, which models what happens at the end of an epoch. Furthermore, an \$Evidence\$ event can be scheduled between an \$EndOfEpoch\$ and the execution of a user transaction. Nevertheless, this is not always allowed in order to satisfy Assumption #3.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The \$Evidence\$ event models what happens when an infraction is submitted to the PoS system. The function first checks that the validator did not misbehave recently. Assuming that the infraction was committed at an epoch \$e\$, the function enqueues the evidence to be processed at the end of the epoch determined by adding the unbonding offset to the epoch at which the infraction happened.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"At the end of an epoch, the \$EndOfEpoch\$ event is triggered. The main purpose of this function is to process enqueued evidence and slash the validator. Due to Assumption #3, there can only be one evidence to process at the end of each epoch. This is processed by computing the amount to be slashed, subtracting it from \$totalDeltas\$ (effectively reducing the validator’s voting power), and moving the slashed amount to the slash pool.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[],"nodeType":"hr"},{"data":{},"content":[{"data":{},"marks":[],"value":"Semantic properties to check","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"In this section, we discuss what invariants we decided to check and why: what semantic properties they encode. Bear in mind that some of the following invariants, e.g., Invariant #1, hold given Assumption #3: a validator does not misbehave multiple times within the unbonding period.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"To check these invariants, we have used ","nodeType":"text"},{"data":{"uri":"https://apalache.informal.systems/"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Apalache","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" - Informal’s in-house model checker. Apalache is a symbolic model checker for TLA+ that translates the verification problem to a set of logical constraints. In turn, these constraints are solved by ","nodeType":"text"},{"data":{"uri":"https://www.microsoft.com/en-us/research/project/z3-3/"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Microsoft’s Z3","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" SMT solver. In the default mode, Apalache only analyzes executions of bounded length. This means that the properties below are only checked up to a certain execution length. Although this does not guarantee that these properties are satisfied in longer executions, when using a sufficiently long execution, one can argue it with reasonably high confidence.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Our TLA+ specification contains only 5 transitions: the three user transactions (delegate, unbond, withdraw), the \$EndOfEpoch\$ action and the \$Evidence\$ action. Thus, we check the below properties on executions of up to 15 steps, which we consider that allows Apalache to explore a very large set of transitions’ interleavings already. While 15 steps seems a relatively small number compared to the thousands of steps that can happen during a day of running the system in production, it was enough to find problems in previous implementations; see Invariant #7 below.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Invariant #1: the users' balance cannot become negative.","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"The PoS system should disallow users’ balances to go negative. By Assumption #3, If a user's balance goes negative, then slashing is not well implemented. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Invariant #2: the PoS balance is always greater or equal to zero.","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"Although simple to check: we just need to check that \$PoSAccount\$ is always greater or equal to zero, this is an important invariant. It guarantees that If an infraction is discovered in time and there are no repeated infractions within an unbonding period, then the PoS model guarantees slashing: any user whose bonds (including the validator’s self-bonds) were contributing to the misbehaving validator's voting power is slashed when withdrawing any of those bonds.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The logic is the following. When we slash a validator (reduce its voting power) at the end of an epoch, we move tokens from the \$posAccount\$ to the \$slashPool\$. Thus, in the \$posAccount\$, we only have the bonded tokens that are withdrawable: this means, the bonded tokens minus the slashable amount. If a user is able to withdraw tokens that were contributing to the voting power of the misbehaving validator, then in an execution where all tokens are withdrawn, the \$posAccount\$ should go negative.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Invariant #3: if there are no bonds and all unbonds have been withdrawn, the PoS balance must be equal to zero.","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"This implies that the implementation of the PoS account is correct. Tokens are moved to the PoS account when a user delegates tokens to a validator and taken from it when these are withdrawn. Thus, the PoS balance should be zero if there are no bonds and all unbonds have been withdrawn. Violating this invariant could for instance unveil problems with the slashing implementation. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Invariant #4: the validator's voting power at a given epoch is less or equal to the total amount of tokens delegated to that validator.","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"This invariant may seem to be incorrect. One may think that the validator’s voting power and the total amount of tokens delegated should be equal. This is not the case in Namada’s PoS due to slashing being scattered throughout the implementation. When an infraction is found, the validator is slashed almost immediately, but its delegations are not updated. This is to avoid iterating over all bonds and unbonds, which could be expensive. Instead, users are slashed when withdrawing their tokens The invariant captures this. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Invariant #5: if no slashing occurs, the validator's voting power at a given epoch is equal to the total amount of tokens delegated to that validator.","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"This is a refinement of Invariant #4. In the case that the validator does not misbehave, i.e., no slashing occurs, the validator’s voting powers and the sum of its delegations should match perfectly.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Invariant #6: the total amount of tokens is constant.","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"This implies that tokens cannot be created. The invariant is easy to check. Initially, the total number of tokens is the number of users multiplied by the initial supply. At any point of the execution, the sum of the users’ balances, the PoS balance, and the slash pool should match the initial number of tokens.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Invariant #7: the validator’s voting power is greater or equal to zero.","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"This invariant is the counterpart of Invariant #1: the same way that a user’s balance should not become negative, the validator’s voting power should not either (given Assumption #3).","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"This invariant was key during our checking process and led to finding potential problems in initial versions of Namada’s PoS. For instance, checking this invariant allowed us to catch a ","nodeType":"text"},{"data":{"uri":"https://twitter.com/namadanetwork/status/1554118274471837698"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"subtle issue","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" with a previous version of Namada’s PoS. The issue was the following: From the moment an infraction is submitted to the PoS system, users cannot unbond their tokens from the misbehaving validator until this is slashed. Nevertheless, due to epoched staking, some unbonds may have been already scheduled to be processed in a future epoch. In a previous version of Namada, these scheduled unbonds were not considered when slashing the validator, which causes the PoS system to over-slash the validator. Thus, in some executions, this could make the validator’s voting power become negative (the property that this invariant checks). The issue was fixed by introducing the \$totalUnbonds\$ variable and making sure that scheduled unbonds are considered when slashing a validator.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Invariant #8: a user cannot create money.","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"This invariant complements Invariant #6 by guaranteeing that a user’s account cannot be greater than \$initSupply\$.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[],"nodeType":"hr"},{"data":{},"content":[{"data":{},"marks":[],"value":"Tutorial: Check it yourself!","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"Following, we present a short tutorial that explains how to check Namada’s PoS system using our TLA+ model from scratch. The process is fairly simple, it only includes three simple steps.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Step 1: Install Apalache","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"The installation is very simple from a prebuilt package. Detailed instructions can be found ","nodeType":"text"},{"data":{"uri":"https://apalache.informal.systems/docs/apalache/installation/jvm.html"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"here","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". We recommend installing version 0.30.1, which is the version of Apalache we used to check our TLA+ model.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Step 2: Clone the TLA+ model","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"The TLA+ model is in a ","nodeType":"text"},{"data":{"uri":"https://github.com/informalsystems/partnership-heliax"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"github repository","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". You should clone it locally by following ","nodeType":"text"},{"data":{"uri":"https://docs.github.com/en/repositories/creating-and-managing-repositories/cloning-a-repository"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"these instructions","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Step 3: Let’s check!","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"The model described in this post is composed of three files: ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"","nodeType":"text"},{"data":{"uri":"https://github.com/informalsystems/partnership-heliax/blob/trunk/2023/Q1/artifacts/PoS-tla/StakingRepeated.tla"},"content":[{"data":{},"marks":[],"value":"StakingRepeated.tla","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" specifies the model. ","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"","nodeType":"text"},{"data":{"uri":"https://github.com/informalsystems/partnership-heliax/blob/trunk/2023/Q1/artifacts/PoS-tla/StakingRepeated_typedefs.tla"},"content":[{"data":{},"marks":[],"value":"StakingRepeated_typedefs.tla","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" defines custom types aliases used by the other modules and Apalache.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"","nodeType":"text"},{"data":{"uri":"https://github.com/informalsystems/partnership-heliax/blob/trunk/2023/Q1/artifacts/PoS-tla/MC_StakingRepeated.tla"},"content":[{"data":{},"marks":[],"value":"MC_StakingRepeated.tla","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" instantiates the model in StakingRepeated.tla giving concrete values to \$PipelineLenght\$ and \$UnbondingLength\$. This file also includes the invariants to verify.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"The correct version can be found in the 2023/Q1/artifacts/PoS-tla folder of the repository.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Apalache can be run in two modes: simulate and check. The simulate mode randomly picks a sequence of actions and checks the invariants for the subset of all executions which only admit actions in the selected order. The check mode checks invariants for all executions up to a configurable length. The simulate mode is typically faster, but it does not provide strong guarantees when an invariant is not violated.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"To run Apalachein check mode, one needs to execute the following command:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"code"}],"value":"apalache-mc check --inv=TotalDeltasGreater MC_StakingRepeated.tla","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"which tells Apalache to check if invariant TotalDeltasGreater can be violated by the model specified in StalkingRepeated.tla in an execution of 10 steps.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"To run Apalache in simulate mode, one just needs to substitute check with simulate. To learn how to play with other parameters such as the execution length, please check ","nodeType":"text"},{"data":{"uri":"https://apalache.informal.systems/docs/apalache/running.html#1-model-checker-and-simulator-command-line-parameters"},"content":[{"data":{},"marks":[],"value":"Apalache's documentation","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"\n\n\n","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":" ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"\n\n","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"scripts":["MathJAX for LaTeX support"],"contentfulURL":"https://app.contentful.com/spaces/p79kctcd7ahy/entries/1OUYBn0pOQzct9c0oCklGJ"},{"featureImage":"$4:props:posts:29:featureImage","date":"2023-02-21","title":"Cosmos Hub January 2023 Update - V8 and V9 Release Coordination","slug":"informal-hub-team-jan-2023-update","categories":["Engineering"],"authors":["Jehan Tremback"],"keywords":"cosmos-hub-january, gaia-v8-v9-releases, replicated-security-launch, ibc-bug-fixes, validator-costs, slashing-updates, community-feedback, interchain-accounts, consumer-chain-preparation, hub-roadmap","excerpt":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Monthly team update covering IBC bug fixes and replicated security launch preparation.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"body":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Hi, I’m Jehan Tremback, and I’m the product manager for the Cosmos Hub team at Informal Systems. The Informal Hub team has decided to start doing monthly updates for the Cosmos Hub community. This month we have been focused on:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Getting the V8 and V9 releases of the Cosmos Hub out","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Addressing community feedback on replicated security","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Setting our team’s roadmap for 2023 ","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"v8 and v9 releases","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"You might be wondering- why are they doing two releases at once? Well, v8 contains an update of IBC with a bug fix for Interchain Accounts that we wanted to get out as soon as possible, while v9 contains the much-awaited feature, replicated security. It would have been simple to just put the bug fix and replicated security into the same release and only have one thing to focus on. However, we wanted to get the bug fix out as soon as possible and avoid delaying the bugfix due to delays in v9, or putting undue pressure on the v9 release.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We had some delays due to bugs found at the last stages of pre-release testing of v8, and these delays also cascaded to v9. I’m not going to go into much detail here, but you can ","nodeType":"text"},{"data":{"uri":"https://forum.cosmos.network/t/upcoming-interchain-accounts-bugfix-release/8911/8"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"read about it","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". We’re compiling all the different release-blocking bugs we encountered and will figure out how we can avoid delays in the future. Mostly, this will likely consist of moving many of our final testing practices into more frequent testnets or nightly tests so that we learn about problems in our code and in our dependencies more quickly. Since many of the bugs were in third party modules, we will also be instituting policies for maintainers of these modules to adhere to.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Fortunately we’re mostly past that now. V8 is currently live on the Hub. V9 (with replicated security) has just gone into the final testing stage. If all goes well, replicated security will be live on the Cosmos Hub at the beginning of March.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Community feedback on replicated security","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"We posted a draft proposal for replicated security in mid-December. Since then we have received a lot of feedback on the proposal. Most of this feedback is in two main categories which I’ll summarize below:.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Validator costs","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"Validators will need to run all consumer chains that are approved by governance or face downtime slashing. This is essential to preserve the high security properties of replicated security, at least until we have workable fraud proofs for Cosmos-SDK (more on this some other time).","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Some validators are concerned about the cost of running additional consumer chains. We are taking several steps to address this: ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"First, consumer chains will set their downtime window to 3+ days, meaning that validators can be down for a long time before receiving a downtime jailing. The Hub and many other Cosmos chains have downtime windows of around 16 hours. This increased leniency means that validators can run consumer chains with less redundancy, cutting costs. This will not pose a problem for the reliability of consumer chains.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Second, we will be helping the first consumer chain teams prepare financial projections quantifying the rewards that can be expected by the validators and delegators of the Cosmos Hub. This will help the community decide whether a given consumer chain is worth approving.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Slashing updates","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"Some community members were concerned that a malicious consumer chain could send falsified slashing packets to the Hub, causing validators to be slashed unfairly. This is one of the main reasons that consumer chains need to be audited and approved by governance. Although we judged that this scenario is very unlikely, it is a valid concern and we had already implemented some throttling code to slow down the slashing process to buy time to stop this attack.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"To make things even safer, we made some small changes so that slashes for double signing (the most serious type of consensus offense with the highest punishment) need to go through one additional step of being approved by governance. This will provide extra safety in the early stages of replicated security’s launch.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"This is a temporary measure. We are working on an “untrusted consumer chain” protocol to allow the Hub to cryptographically verify double signing evidence. At this point it will no longer be possible for malicious consumer chain code to falsify a double signing slash packet and we will be able to make it fully automatic again.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"2023 Cosmos Hub roadmap","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"We’ve been working on our roadmap for 2023. I’d like to make it clear that this is our team at Informal’s roadmap. The Cosmos Hub is decentralized and other teams contribute to it as well. We’re still polishing it up for a public release but I can go over the broad categories here:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Replicated Security v1.1: These are the many changes we want to make but could not get to before launch. These include:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Random code cleanups and protocol simplifications","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Untrusted consumer chain protocol: Make it so that there is no way a consumer chain can cause inconvenience or harm to the Cosmos Hub, while bringing back automatic slashing as detailed above.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Soft opt-in: Make it so that the bottom 10-20% of validators on the Hub do not need to validate every consumer chain, making things easier for the smaller validators.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Interchain Security future: Work on the next versions of ICS","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Opt-in security: Make it so that every validator can choose which consumer chains they want to validate. This requires fraud proofs or something similar.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Mesh security: Participate in the design and adoption of Mesh security. This likely also requires fraud proofs. We’ll be releasing an analysis soon.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Hub governance improvements: There are a lot of improvements to the Cosmos SDK governance system that could make deliberation easier and more constructive, and make community pool funding more accountable.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Streaming/vesting funding: Allow a funding recipient to vest their funds over time, subject to claw backs if they don’t perform, or set up a streaming payment of future funds, also subject to clawback.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Stabilized funding: Automatically exchange Atoms from the community pool for a stable asset, or adjust streaming funding amounts over time in response to an Atom price feed.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Multichoice proposals: Allow voters to choose between several acceptable options- this would make it easier to pass proposals that accurately reflect what voters want.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"}],"nodeType":"list-item"}],"nodeType":"unordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"Follow ","nodeType":"text"},{"data":{"uri":"https://twitter.com/informalinc"},"content":[{"data":{},"marks":[],"value":"@informalinc","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" for more monthly Hub updates. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"—\nJehan","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"contentfulURL":"https://app.contentful.com/spaces/p79kctcd7ahy/entries/6KetLekOvqOu2LfoxWBIIj"},{"featureImage":"$4:props:posts:29:featureImage","date":"2023-02-13","title":"Governance-Gated vs Automatic Equivocation Slashing in Replicated Security","slug":"governance-gated-vs-automatic-equivocation-slashing","categories":["Engineering"],"authors":["Jehan Tremback","Josef Widder"],"keywords":"equivocation-slashing, governance-gated-slashing, replicated-security, double-signing, consumer-chains, validator-slashing, cosmos-hub-governance, automatic-slashing, consensus-security, validator-misbehavior","excerpt":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Why governance-gated slashing provides equivalent security to automatic slashing.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"body":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"We recently made a change to replicated security: if a validator commits an equivocation fault (colloquially known as “double signing”) on a consumer chain, they are no longer automatically slashed on the Cosmos Hub. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Instead, evidence of equivocation must now be submitted to Cosmos Hub governance and be voted on. This is an extra safeguard before a validator is slashed. The reason for this move is to prevent a situation where a consumer chain contains exploit code which unfairly slashes a large number of validators.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"While we had already built in several mitigations for this attack, as well as requiring that all consumer chains be well-audited, we ultimately decided that no matter how small the risk of unfair slashing might be, it is such a serious attack that we need to be able to rule it out completely.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Note that replicated security changes nothing about how equivocation is handled on the Cosmos Hub. It only affects how equivocation evidence coming from consumer chains is handled. This article deals only with what happens when validators double sign on consumer chains.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We’d like to take this opportunity to explain how governance-gated slashing compares to automatic slashing and why it provides the same security guarantees.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"What is equivocation slashing","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"Equivocation is when a validator signs off on two alternate, but completely valid versions of history. The attack that is possible with equivocation is one where two different, but completely valid histories are presented to two victims. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"For example, the attacker might show Alice a block where they sent her 5 Atoms, while also showing Bob an alternate history where he was sent those same 5 Atoms. This is known as a “double spend” and is a classic and well-studied blockchain attack scenario. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"There are other more complicated attacks but they can be analyzed under the same lens and we won’t describe them here.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Equivalence of automatic and governance-gated slashing","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"The important thing to understand about equivocation is that in Tendermint/CometBFT ","nodeType":"text"},{"data":{},"marks":[{"type":"bold"}],"value":"an attack can only be carried out successfully if at least ⅓ of the validation power on the chain participates. ","nodeType":"text"},{"data":{},"marks":[],"value":"A single dishonest validator cannot carry out the attack by themselves.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"In the context of governance-gated slashing, you might be wondering- what if validators with ⅓ of the power carry out an attack by equivocation and then the governance proposal to slash them does not pass? Wouldn’t they get off without punishment? Wouldn’t this possibility incentivize such an attack?","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The easiest way to prevent a governance proposal from passing on Cosmos chains is a vote of No With Veto. If ⅓ or more of the validation power votes NWV, the proposal cannot pass. So, yes, that malicious ⅓ who carried out the attack could just veto the slashing proposal and get away without being punished.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"However, this is the case with automatic slashing as well! ⅓ of validation power can censor any transaction and completely prevent it from appearing on the chain. The malicious ⅓ could simply censor evidence of their equivocation and not be slashed. Validation power and governance power are the same power.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"So, if enough validation power participates in an equivocation attack for the attack to succeed, it follows that they will also be able to prevent punishment, whether governance-gated or automatic slashing is used. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Conversely, if an attack is attempted but does not have enough power to succeed, the attackers will also not have enough power to censor automatic slashing transactions or defeat a slashing proposal. They will then be slashed in either case. Automatic slashing and governance-gated slashing are equivalent under this analysis.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Can this governance proposal unfairly slash validators?","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"It is important to note that a simple governance proposal cannot slash any validator any time. The equivocation governance proposal we are introducing can only be created for a validator if the Cosmos Hub has received an equivocation slashing packet for that validator from a consumer chain first. So in order for an innocent validator to be slashed, first a consumer chain would need to contain malicious code that would forge an equivocation slashing packet. Then someone would need to introduce an equivocation slashing proposal. Then governance would need to vote yes on the proposal.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Potential risks","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Voter apathy","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"We have shown above, that given engaged and active voters, equivocating validators have an equal chance to avoid being slashed for an offense under governance-gated slashing and automatic slashing.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"But a “No” or “No with veto” vote is not the only way for a governance proposal to fail. Governance proposals can also fail if they do not reach a defined quorum percentage of token holders voting (40% on the Hub). If a slashing proposal containing evidence of an attack was submitted, and nobody cared enough to verify it and vote, the attackers would not be slashed.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We do not see this as being a risk for a long time. An attack involving equivocation would be an unprecedented event. It has never happened on the Cosmos Hub, and to my knowledge has never happened on any Cosmos chain. Validators have been slashed for double signing, but it has always been as a result of misconfiguration.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"An attempted equivocation attack on a replicated security consumer chain would be a very notable event, and threaten the integrity and reputation of the Cosmos Hub itself. There is no chance in the short term that slashing proposals would be ignored.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"However, in the long term, when we scale to thousands of consumer chains voter apathy might become more of a risk. This is why we are working on bringing back automatic slashing by allowing the Cosmos Hub to completely verify equivocation evidence on its own instead of trusting consumer chains to send correct evidence. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"We don’t foresee any serious need for this until we have at least hundreds of consumer chains","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Governance voting period","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"We have shown above that there is no significant difference in the chances that equivocating validators can avoid punishment under governance-gated or automatic slashing, there is one important difference that we should mention. It has to do with the governance voting period.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Governance proposals must go through a 2 week voting period before they are passed. The unbonding period, after which delegators and validators can unbond their stake is 3 weeks. This means that if malicious validators participate in an equivocation attack and then immediately unbond their stake, and then the governance proposal is not put up for voting for at least a week, the validators could avoid the 5% slashing penalty. They would still be tombstoned, meaning that they could never validate again with the same keys.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"We believe that this is acceptable in the short term. Governance proposals are not generated automatically upon receiving a slash packet from a consumer chain, but the packets are logged and then anyone can create the proposal from this information. Given what a serious matter a real equivocation attack would be, we have no doubt that someone would create the proposal.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"One other concrete change resulting from this has to do with light clients. Due to some complicated factors related to the reduced time available to submit evidence due to the voting period, it is important that IBC connections to consumer chains are updated at least once every 5 days. The IBC trusting period parameter must also be set to 5 days. Relayers already update connections every time they relay a packet, and automatically update connections frequently even when not relaying packets, so this shouldn’t be an issue. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"We should be able to remove this caveat in the next release, bringing things back to the normal state of affairs where relayers must update IBC connections at least once every 2 weeks.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The next step","nodeType":"text"}],"nodeType":"heading-1"},{"data":{},"content":[{"data":{},"marks":[],"value":"Our team is working on some code for a future release that will make it so that the Cosmos Hub can verify double signing evidence from consumer chains cryptographically, allowing automatic slashing to work safely. This is one of our top priorities. This is an ongoing area of research, and we’ll be announcing some updates on it soon. One caveat is that it ties Replicated Security more tightly to Tendermint/Comet, since other consensus protocols will have other equivocation evidence formats which cannot be verified with the same code.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Follow ","nodeType":"text"},{"data":{"uri":"https://twitter.com/informalinc"},"content":[{"data":{},"marks":[],"value":"Informal on Twitter","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" for more info and monthly updates.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"contentfulURL":"https://app.contentful.com/spaces/p79kctcd7ahy/entries/1kz6pctJCPXeUMhffTy19v"},{"featureImage":"$4:props:posts:25:featureImage","date":"2023-02-01","title":"Cosmos, meet CometBFT","slug":"cosmos-meet-cometbft","categories":["Engineering"],"authors":["Adi Seredinschi","Thane Thomson"],"keywords":"cometbft-launch, tendermint-core-successor, interchain-stack, abci-2.0, consensus-engine, state-machine-replication, cosmos-fork, blockchain-consensus, icf-stewardship, modular-consensus","excerpt":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"New consensus engine fork brings ABCI 2.0 and improved quality assurance.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"document"},"body":{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Today we announce the launch of CometBFT, a state machine replication engine for the interchain and beyond! CometBFT is a fork of, and a successor to, ","nodeType":"text"},{"data":{"uri":"https://github.com/tendermint/tendermint/issues/9972"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Tendermint Core","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", and will serve as the official replication engine powering the ","nodeType":"text"},{"data":{"uri":"https://interchain.io/technology"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Interchain Stack","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". The long-term vision for CometBFT is to be the primary choice of replication engine for reliable, secure, large-scale, application-specific blockchains. Commit your blocks with CometBFT today!","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The Interchain Foundation, Informal Systems, the Cosmos SDK team, and numerous other teams in the ","nodeType":"text"},{"data":{"uri":"http://cosmos.network"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Cosmos","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" ecosystem have been working together to prepare this launch. This post tackles some of the most important questions surrounding this launch. Rest assured, we have been working hard to make upgrading to or adopting CometBFT as smooth as possible. We will cover background details, the CometBFT vision and objectives, the teams behind this effort, and next steps in terms of technical implications.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Why Now?","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"We decided to develop the flagship Cosmos consensus engine under this new name to mark multiple important changes sweeping across the ecosystem.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"On the technical side, the interchain has evolved significantly in the last couple of years. We are living in an IBC-native, multi-chain world. ","nodeType":"text"},{"data":{"uri":"https://twitter.com/interchain_io/status/1573273601192738817"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"ABCI 2.0","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" is a critical piece missing from the Interchain Stack, as are design or quality assurance aspects such as modularity, integration, or rigorous testing. Furthermore, the abandoning of the v0.35 and v0.36 releases of Tendermint Core exposed technical limitations on how development was done; see ","nodeType":"text"},{"data":{"uri":"https://medium.com/the-interchain-foundation/discontinuing-tendermint-v0-35-a-postmortem-on-the-new-networking-layer-3696c811dabc"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"here","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" for more details.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"In 2022, the organizations maintaining the Interchain Stack initiated a strategic approach to mitigate the above technical limitations. This approach involved building and dedicating a complete team to Tendermint Core at Informal Systems. Additionally, in preparing releases we started prioritizing quality and integration with the rest of Interchain Stack (i.e., Cosmos SDK, ","nodeType":"text"},{"data":{"uri":"https://ibcprotocol.dev/"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"IBC","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", and the wider interchain building blocks).","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"On the administrative side, we do not own the ","nodeType":"text"},{"data":{"uri":"https://github.com/tendermint/"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"tendermint","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" GitHub organization nor the trademark rights over “Tendermint''. All in Bits (AiB) is the owner. The development of the Tendermint Core software has taken place outside All in Bits for the last three years. However, AiB’s ownership of the trademark posed a continuous risk of trademark action. Without complicated agreements with AiB, it would not be possible to fully mitigate this risk hanging over the heads of the developers of a most critical piece of the Interchain Stack. ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"As we mentioned ","nodeType":"text"},{"data":{"uri":"https://twitter.com/informalinc/status/1613580971592278016"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"earlier on Twitter","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" and per ","nodeType":"text"},{"data":{"uri":"https://github.com/tendermint/tendermint/issues/9972"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"this discussion","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", AiB unilaterally decided to archive the Tendermint Core repository. Thus the way forward to continue the development trajectory, and as encouraged by AiB, was to fork the Tendermint Core repository. CometBFT will build on the foundations laid by Tendermint Core, with renewed development focusing on users, quality, and integration.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"In line with these technical and administrative concerns, the most important changes are in the project’s long-term vision, objectives, and administration. This brings us to the next part of this discussion.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"What’s Next?","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"As a committed steward of the Cosmos and interchain ecosystem, the ","nodeType":"text"},{"data":{"uri":"https://interchain.io/"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Interchain Foundation","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" serves as a reliable host for public goods funding and assets. The ICF has been the owner of the “Cosmos” trademark since inception, and protects its use in the best interests of the wider community. Similarly, the ICF has trademarked the “CometBFT” name and set up the CometBFT GitHub ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"organization","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", and intends to steward both for the long term in the best interests of the growing interchain. CometBFT will remain open-source and licensed Apache2.0. We invite all interested parties to contribute to the growth and development of this software and to promote its open-source values.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"As mentioned earlier, the long-term mandate for CometBFT is to be the primary choice of replication engine for the interchain. The CosmosSDK team, the IBC teams, CometBFT maintainers, and the numerous engineering teams that comprise the interchain, both at the application level as well as public goods, share the common vision of making CometBFT a place where teams can experiment with novel features, build and iterate with optimizations, and ensure a high degree of flexibility for users, while maintaining the integrity and robustness of the stack. If you are a contributor to the Interchain Stack, operating validators or nodes, integrating with other ecosystems, or finding your way around Cosmos as a new user, your help would be greatly appreciated towards making this a reality. See the “References” below on how to get in touch with us.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"What are the objectives for CometBFT?","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"As described above and ","nodeType":"text"},{"data":{"uri":"https://twitter.com/informalinc/status/1613580959806361637"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"previously","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":", this marks a new phase in the interchain. Its consensus engine is evolving to be a building block specialized for a IBC-native world. We seek to continue working closely with the Cosmos SDK team and current users, while facilitating adoption for the growing ecosystem of application developers building above ABCI and with IBC. The underlying, long-term goal for CometBFT is to play a key part in supporting the growth of the interchain.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"More specifically, CometBFT objectives are:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Strong user focus","nodeType":"text"},{"data":{},"marks":[],"value":", with a clearly articulated product strategy that takes its users’ needs first and foremost. This is a strategic choice towards ensuring CometBFT is relevant and provides utility.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Improving quality assurance","nodeType":"text"},{"data":{},"marks":[],"value":" and correctness guarantees, aiming to rigorously specify and test our implementation using advanced techniques like model-based testing. We are bringing our expertise in specifications & formal methods to reinforce existing QA, which was already complemented with large-scale testing efforts.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Modularity","nodeType":"text"},{"data":{},"marks":[],"value":", focusing on the right boundaries of abstraction, allowing the system to be pulled apart if and where necessary, allowing a piece-meal integration in projects that depend on it. We want to allow CometBFT to be used as a library increasingly, and to minimize forks and fragmentation by providing new interfaces to support the ever-growing array of use cases.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"Faster functionality rollout ","nodeType":"text"},{"data":{},"marks":[],"value":"without sacrificing quality by way of progressively updating the architecture of the system to act as a sound platform for change, as well as by smoother project coordination across the entire Interchain Stack.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"ordered-list"},{"data":{},"content":[{"data":{},"marks":[],"value":"An essential tactic towards fulfilling these four objectives is the tight integration across the Interchain Stack; this will serve as a major distinguishing point between CometBFT and other forks of Tendermint Core. By building on the strong foundation that Tendermint Core provides, ABCI 2.0 will be the first iteration of this approach outlined above. We will follow-up with a detailed 2023 roadmap plan in early Q2.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"Who is behind CometBFT?","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"Launching CometBFT was a multi-organizational decision. CometBFT is stewarded by Informal Systems in collaboration with a large number of Cosmos stakeholders. The launch involved work across several teams across the interchain, including Cosmos SDK, IBC, Osmosis, Cosmos Hub, and coordination with Agoric, Axelar, Oasis, Penumbra, Celestia, Anoma, Skip, Umee, Confio, Nomic, Numia, Sei, Evmos, Sommelier, Andromeda, Cronos among many others.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"The CometBFT team at Informal comprises some of the most talented and passionate Cosmos contributors. We will follow-up on Twitter with an introduction of the core team members as well as contributing members from across other interchain teams. For the moment, suffice to say that the core team comprises research engineers, veteran DevOps and software engineers with decades of combined experience, as well as project, product and tech leads with 10+ combined years of experience in Cosmos.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[],"value":"What are the immediate next steps?","nodeType":"text"}],"nodeType":"heading-3"},{"data":{},"content":[{"data":{},"marks":[],"value":"Launching CometBFT is a substantial effort that is still ongoing. Here are a few important things to know.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"italic"},{"type":"bold"}],"value":"If your work depends on CometBFT","nodeType":"text"},{"data":{},"marks":[],"value":", then consider joining the community calls, which are organized every two weeks on Thursdays: ","nodeType":"text"},{"data":{"uri":"https://groups.google.com/g/cometbft-community/"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"https://groups.google.com/g/cometbft-community/","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":". In addition to the GitHub repository, the community call is an important forum for discussing the development of CometBFT. It is the place for developers to gather feedback from you, to answer questions, and for you, as a user, to exchange valuable knowledge with other users.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"italic"},{"type":"bold"}],"value":"If your application is building on the Cosmos SDK:","nodeType":"text"},{"data":{},"marks":[],"value":" New SDK versions for the 0.45, 0.46 and 0.47 lines will be released by the Cosmos SDK team. These releases will use CometBFT v0.34 instead of Tendermint Core 0.34, per agreement among the Interchain Stack contributors and projects. Upgrading to this SDK version does not require a coordinated upgrade, as it is a minor version change. The ","nodeType":"text"},{"data":{"uri":"https://github.com/cosmos/cosmos-sdk/blob/main/CHANGELOG.md"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Cosmos SDK changelog","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" will document the relevant changes for your application.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"italic"},{"type":"bold"}],"value":"If you are building directly on top of Tendermint Core:","nodeType":"text"},{"data":{},"marks":[],"value":" As maintainers, we recommend that you switch from Tendermint Core v0.34 to CometBFT v0.34. We will provide upgrading instructions once we cut our first releases. Keep an eye on the ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Github repo here","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":".","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"italic"},{"type":"bold"}],"value":"If you are maintaining a fork of Tendermint Core: ","nodeType":"text"},{"data":{},"marks":[],"value":"We recommend transitioning to CometBFT as soon as possible, e.g., by rebasing or cherry picking your relevant changes to a fork of CometBFT. We would be glad to assist in this process. Additionally, we will welcome your feedback and information on your specific requirements towards eliminating the need for you to maintain a fork (see the “community” reference below).","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"marks":[{"type":"bold"}],"value":"References","nodeType":"text"}],"nodeType":"heading-2"},{"data":{},"content":[{"data":{},"marks":[],"value":"Here you will find official links and instructions relevant to Comet:","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Where to find the CometBFT consensus engine?","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/cometbft/"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"https://github.com/cometbft/cometbft/","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" ","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Don’t forget to star the repo!","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"How to find support?","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"If you are a developer, the best place for support is the ","nodeType":"text"},{"data":{"uri":"https://discord.gg/cosmosnetwork"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Cosmos Network","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" Discord server, in the ","nodeType":"text"},{"data":{},"marks":[{"type":"italic"}],"value":"`#cometbft`","nodeType":"text"},{"data":{},"marks":[],"value":" channel.","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"We have introduced a Telegram channel to allow for fast feedback and communication, and to handle this period of transition. Please join here: ","nodeType":"text"},{"data":{"uri":"https://t.me/CometBFT"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"https://t.me/CometBFT","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" ","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Link to documentation ","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"","nodeType":"text"},{"data":{"uri":"https://docs.cometbft.com/"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"https://docs.cometbft.com/","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":"","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"}],"nodeType":"unordered-list"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"The new handles for the project are as follows.","nodeType":"text"}],"nodeType":"paragraph"},{"data":{},"content":[{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"GitHub organization: ","nodeType":"text"},{"data":{"uri":"https://github.com/cometbft/"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"https://github.com/cometbft/","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" ","nodeType":"text"}],"nodeType":"paragraph"}],"nodeType":"list-item"},{"data":{},"content":[{"data":{},"content":[{"data":{},"marks":[],"value":"Discord: In the ","nodeType":"text"},{"data":{"uri":"https://discord.gg/cosmosnetwork"},"content":[{"data":{},"marks":[{"type":"underline"}],"value":"Cosmos Network","nodeType":"text"}],"nodeType":"hyperlink"},{"data":{},"marks":[],"value":" server join the ","nodeType":"