Summary: Aiken Updates – stdlib v3.1.0 and v1.1.22 Preview
In the 59th edition of the Developers Office Hour, host Darlisa Consoni from the Cardano Foundation speaks with Matthias Benkort, Technical Director of Open Source Development at the Cardano Foundation. They discuss the latest technical enhancements in the Aiken ecosystem, specifically the release of the standard library (stdlib) v3.1.0 and a preview of the upcoming compiler version 1.1.22.
Aiken stdlib v3.1.0: Speed and Efficiency
The new standard library focuses heavily on optimization without introducing breaking changes.
- The
expect_ primitives: A major addition is the introduction of expect_ functions for lists, pairs, and dictionaries. Unlike previous functions that return an option type (which requires manual error handling), these new partial functions crash immediately if they fail. Because smart contracts often prefer to fail early rather than handle errors, this approach significantly reduces execution cost, saving up to 50 percent in CPU and memory units during basic operations.
- New built-ins and optimizations: Driven by the CIP-113 standard, a new
contains function allows developers to efficiently check if a subset exists within a superset. Additionally, under-the-hood optimizations have made operations like the union of two dictionaries 15 to 20 percent faster.
Aiken v1.1.22: Developer Experience and Tooling
The upcoming compiler update brings several quality-of-life improvements for developers writing smart contracts.
- Test reporting and benchmarking: Test outputs are much cleaner. Expected failures are no longer confusingly highlighted in red, and trace filters now work consistently. For benchmarking, execution units are now human-readable, and the compiler uses linear regression to quickly estimate the maximum size of a benchmark without needing to run massive, time-consuming samples.
- Smarter code optimization: The compiler now automatically applies “Yoda conditions” for symmetric operations. This means it automatically moves constant arguments to the front of an operation, allowing the optimizer to hoist built-ins and reduce overall script size. In testing, this saved around 100 bytes on a five-kilobyte program without the developer changing their code.
- Improved Language Server Protocol (LSP): A frustrating issue with module pruning has been fixed. The LSP autocomplete will now correctly suggest modules from the standard library, even if they have not yet been manually imported into the file.
- Formatter updates: The code formatter has been tweaked to handle assignments and backpassing more cleanly, bringing the visual style closer to TypeScript.
Open Source Roadmap and Future Compatibility
Looking ahead, Matthias notes that a WebAssembly (WASM) crate is in the works, which will eventually allow the entire Aiken compiler to run natively inside a web browser. Regarding upcoming hard forks and Plutus V4, Matthias assures the community that existing V3 smart contracts will continue to function flawlessly. The Aiken team plans to integrate Plutus V4 features seamlessly, shielding developers from potential breaking changes at the ledger level.
Top Five Q&A (FAQ) about the Aiken Updates
Question 1: What is the main benefit of the new expect_ functions in stdlib v3.1.0?
Answer: The expect_ functions are partial functions designed to fail or crash immediately if an operation (like finding an item in a list) is unsuccessful, instead of returning an error that must be handled. This aligns perfectly with smart contracts, which usually prefer to fail early, and it drastically cuts down on execution costs and memory usage.
Question 2: How does the new compiler update improve code optimization automatically?
Answer: The v1.1.22 compiler automatically applies “Yoda conditions” to symmetric operations by moving constant arguments to the beginning. This allows the internal optimizer to hoist and pre-apply built-ins, reducing both execution units and the final script size without the developer having to manually arrange their code.
Question 3: What improvements have been made to testing and benchmarking?
Answer: The test reports are now cleaner, no longer displaying red text for tests that fail as expected. Furthermore, the benchmarking tool now outputs human-readable execution units and uses linear regression to quickly project the maximum input size, saving developers from running long, resource-intensive benchmark loops.
Question 4: Will the upcoming Plutus V4 upgrade break existing Aiken smart contracts?
Answer: No. Thanks to the backward compatibility of the Cardano ledger, existing Plutus V3 smart contracts will continue to work perfectly. The Aiken team intends to support Plutus V4 features in the future while actively abstracting any underlying ledger changes to prevent breaking the developer API.
Question 5: What is the long-term goal with the Aiken WebAssembly (WASM) crate?
Answer: The experimental WASM crate will eventually allow the entire Aiken compiler to run directly inside a web browser. This opens the door for interactive, executable code snippets in documentation, integrated developer tools, and the ability to compile and validate smart contracts natively in browser-based tools.
Aiken Updates
Friday, 1 May
14:00 – 15:00 UTC