The Cadence Language working group is focused on all things related to the smart contract language experience on Flow, including interactions with the account storage, security, and scalability of the network. Focus areas are designing, developing, and optimizing smart contract language and Flow virtual machine (FVM).

Long-term support: write once, run forever

One of the top priorities for Cadence is to design and implement the first stable and long-term-supported release of Cadence (aka Stable Cadence). This would be a long-term process in which Cadence achieves feature completeness, the core smart contracts are sufficiently battle-tested, and the economics of the system are sufficiently understood to provide long-term support without suffering from any breaking changes and maintenance issues. Based on the feedback from the community so far, this milestone was separated into two phases:

• Secure Cadence: focused on security hardening, which unlocked permissionless smart contract deployment
• Long-term support: focused on usability improvements that will require breaking changes. For example, he changes may include streamlined token standards, improved capabilities, and removal of reentrancy “foot-guns.”
  

If you have any thoughts or questions about the overall idea of Stable Cadence, please comment on the blog post or participate in Cadence FLIPs on GitHub.

Performance improvements

The Cadence Language working group is collaborating with the Core Protocol working group to achieve the goal of 1000 transactions per second (TPS). There are several workstreams currently under development or consideration:

• Cadence external value encoding optimizations will include adding an alternative to the existing JSON-based encoding for external Cadence values. This new encoding will improve the speed of encoding/decoding, reduce the size of payloads that transfer Cadence values, and unlike the JSON-based encoding, will have a canonical form. It will also enable storing type information on-chain, avoiding repeated parsing and type-checking of Cadence types during execution
• FVM programs cache optimizations will improve the performance of loading contracts during execution. Number of optimizations are being evaluated, including cache invalidation and storing parsed and type-check contracts on-chain
• FVM pre-execution pipelining can improve the speed of execution by parsing and type-checking transactions in parallel while a transaction is executed, and following transactions are already parsed and type-checked
• Elaboration optimizations will include finding a better representation for elaborations, as well as making elaborations serializable so they can be stored on-chain

Support for Compilation

Cadence compilation will be a long-term investment that we will build in stages to deliver several benefits, including

• Performance improvements
• Currently, transaction execution is implemented using a tree-walking interpreter, which is not designed for high performance. Switching to compilation has the potential to unlock performance improvements orders of magnitude above current levels.
• Allow the language to evolve independently of the VM so changes to the language can be rolled out more quickly in a backwards compatible manner.

The first few milestones should focus on the performance benefits of on-chain compilation, specifically the execution of pre-compiled contracts and evaluation of potential performance impacts of a parallel compilation of transactions.

If you have any thoughts, use cases, or questions regarding the Cadence experience, please participate in the open design meeting or use this Discord channel.

‍The current chair of the Cadence working group is Bastian Müller and the core contributors are Dapper Labs, NCC Group, Halborn and other independent contributors. The working group is building in public and coordinating via monthly public language design meetings, GitHub, and community FLIPs.‍