High level summary
On the Plinth side, we added strictness analysis in both UPLC and PIR. This is used by two compiler optimizations: inlining, and the strictification of bindings For example, if a non-strict binding is guaranteed to be evaluated, it can be safely converted to a strict binding. These optimizations reduce both the computational cost and the size of the resulting Plutus scripts, sometimes significantly.
In preparation for the next hard fork, development on UPLC has progressed steadily.
We completed the specification for the dropList primitive and conformance testing for builtin arrays.
Additionally, we advanced work on casing on booleans and the costing of the modular exponentiation primitive - both challenging tasks that we expect to complete in the coming weeks.
On the certified compilation front, we expanded our test coverage, addressed several issues in the decision procedures, and are actively working to resolve the remaining recently identified problems.
Low level summary
Key Pull Requests Merged
- UPLC Optimization: force-ifThenElse-delay
- Specification of dropList
- Reduction semantics for Untyped Plutus Core
- Add certifier tests for UPLC simplifier test inputs
- Restructure certifier test modules; add unit testing capability
- Conformance tests for builtin arrays
- Improve the UPLC inliner to perform more inlining when it's safe
- [Costing](Fix memory usage for polymorphic types)
- Enhance the StrictifyBindings pass with strictness analysis
Issues and Pull Requests In Progress
- Allow casing on booleans
- Costing of builtin functions operating on builtin arrays (in plutus-private)
- Costing of the modular exponentation primitive (in plutus-private)
- Conformance tests for the modular exponentation primitive (in plutus-private)