Daedalus Turbo

Cardano Node Diversity Workshop Update: Promoted Plutus optimizations and compression (CIP-150). Even the Haskell Node team sees those as feasible. Now it’s about priority—could mean not only faster sync but also better tx throughput (10x+) and reduced inter-block times (2–4x). Talk to your DRep if interested.

Amaru will hold a Node diversity workshop this September. DT plans to present the C++ node, highlighting the benefits of parallelization and data compression. Active development remains paused pending alternative funding; updates will shift to a monthly schedule in the interim.

Quick update: Right now, the main focus is securing funding for the C++ node that’s independent of IOG/Catalyst. As a result, code development is minimal at this time: primarily auditing the codebase to identify ways to simplify it and make onboarding new developers easier.

Published experimental server/client code implementing compressed data transfers (CIP-0150) within the Cardano network protocol. 📦 GitHub repo now includes an updated README outlining next steps after the IOG/Catalyst fallout. github.com/r2rationality/…

First tough but necessary cuts due to the breach of contract by IOG/Catalyst: - UI development is stopped; the Local Desktop Explorer feature is now deprecated. - Windows and Mac builds will no longer be provided—upcoming releases of the C++ node will be source-code only.

🚨 Important Update: 1. DT has terminated its collaboration with IOG/Catalyst due to their breach of contract. Final submission with details: bit.ly/43fQTRh 2. Use cases for the C++ Node are re-prioritized to secure alternative funding. 3. Further updates to follow.

DT is on a short pause as it secures financing for 2025. For those following the journey: DT has been operating without Catalyst funding for over 18 months. This is part of why additional use cases for the C++ node are explored. Code updates are on the way!

✅CIP-0150: Block Data Compression has passed initial review and is now directly available from the Cardano Improvement Proposals repo 🔗 github.com/cardano-founda… A POC is being developed using the C++ node to evaluate real-world impact—work is already underway.

An enterprise full wallet is currently the most popular additional use case. There is an ongoing discussion with the Cardano Wallet team, which is also exploring this use case. If this use case is important to you, please share details about your needs: github.com/cardano-founda…

It's in progress, currently discussing the optimal integration strategy with the Cardano Wallet team: github.com/cardano-founda… A key challenge is testing: a new node requires significantly more feedback than the past 7 demo builds produced. That’s why identifying new, feedback-rich use cases is critical.

@TurboDaedalus What about fast and daring full node wallet? 🧐

Published the code implementing Conway governance actions to the public repo. Including other updates, that's over 20,000 lines of code changed. The next few weeks will focus on testing and refinement. The fast and daring C++ node is approaching! 😈🚀 github.com/sierkov/daedal…

🚧 DT is refining code for the next release and exploring new low-risk (non-block production) use cases for the C++ node . Which of these would you find most useful?

@arcter Block Data Compression. See the previous tweet for details.

@TurboDaedalus CIP-0150?

Today, DT synced mainnet to epoch 544 for the first time, verifying its ledger code for Cardano protocol versions 9 & 10. How does this relate to CIP-0150 & the Implementation-Independent Ledger Conformance Tests? All are steps toward a Daedalus build running on DT's stack.

@lacepool_com Lower bandwidth means more retransmission rounds, amplifying the impact of compression. The best way to evaluate CPU usage comprehensively is to build and benchmark it. That’s exactly what the CIP advocates—offering simple methods to do so.

A fascinating read! I truly appreciate the initiative, and the deep dive into ZStandard compression was really intriguing. Regarding the block propagation section, I couldn’t help but feel that it might be simplifying real-world scenarios. Increasing block sizes to, say, 1MB could pose challenges for nodes with limited bandwidth, no compression, and lower CPU power. I wonder whether this approach still leads to higher hardware requirements, despite claims to the contrary. Thoughts, @C1cADA_Markus ?

Block Data Compression is now Cardano Improvement Proposal #0150!🚀 It removes DT’s reliance on compressing proxies, enables Daedalus builds to use DT’s stack, and can boost Cardano’s tx throughput 100x. Join the discussion via the link in the header!⬇️ github.com/sierkov/data-c…

@nalyd88 Correct but any "memory-unsafe" library handling untrusted data requires a security audit and a trust decision. ZStandard’s decoder is ~15,000 lines of code. So a lot to audit. Suggesting to integrate it via a separate process with restricted privileges. That’s just ~300 lines.

@TurboDaedalus The Ed25519 implementation used inside the "Haskell" code is written in C.

Block Data Compression will be discussed on March 4th at 16:00 UTC in the CIP Editor’s Discord: discord.gg/J8sGdCuKhs. Most agree on its benefits—the challenge is the classic Haskell dilemma: Can C code be trusted? :) Prepared a solution using Linux’s seccomp. Join to discuss!

DT relies heavily on data compression. A minor protocol change could potentially scale Cardano’s transaction throughput by 100x while also reducing block-generation intervals. @_KtorZ_, @wolf31o2, @dr_c0d3, could Rust and Go implementations support this? github.com/cardano-founda…

DT historically uses its own CBOR parser for speed and to get byte-offsets of blockchain items for indexing. The new parser is ~1000 lines (so should be easy to adjust/port) has a speed of 1-2 GB/sec per CPU core. It requires raw data to be pre-loaded/memmapped. The primary use cases are mainnet parsing (~200GB) and diffing DT generated ledger snapshots vs Cardano Node ones (~1TB of CBOR data with one snapshot per epoch). No experience with Kotlin, but from experiences of integrating C libraries with other languages, the best performance-wise is most likely to provide a use-case specific "batch API" (parse_blockchain_block, etc.) where Kotlin/Java objects will be constructed by the C/wrapper code to reduce the back-and-forth between Kotlin and C. However, that depends on your use case. Let me know if you have interest in checking the source code.

@TurboDaedalus @_KtorZ_ @wolf31o2 I need a good cbor parser in java or kotlin, but am not opposed to using JNI -> C for it. I built my own in kotlin, but it was slow as dogshit and needed to be abandoned.

Delaying the next release a bit to integrate the new zero-copy CBOR parser. For DT, an implementation-independent Cardano Ledger conformance test suite could simplify many things. @_KtorZ_ , @amw7, @wolf31o2 —could it help Rust and Go implementations too? github.com/IntersectMBO/c…