Scripting
Starting with the scripting language, transactions between addresses in a ledger require some form of a script to execute and be proven valid. Ideally, one would not want Eve to access Alice’s money, nor would one want a poorly designed script to accidently send value to a dead address making the funds irretrievable.
Systems such as Bitcoin provide an extremely inflexible and draconian scripting language that is difficult to program bespoke transactions in, and to read and understand. Yet the general programmability of languages such as Solidity introduce an extraordinary amount of complexity into the system and are useful to only a much smaller set of actors.
Therefore, we have chosen to design a new language called Simon6 in honor of its creator Simon Thompson and the creator of the concepts that inspired it, Simon Peyton Jones. Simon is a domain-specific language that is based upon Composing contracts: an adventure in financial engineering.
The principal idea is that financial transactions are generally composed from a collection of foundational elements7. If one assembles a financial periodic table of elements, then one can provide support for an arbitrarily large set of compound transactions that will cover most, if not all, common transaction types without requiring general programmability.
The primary advantage is that security and execution can be extremely well understood. Proofs can be written to show correctness of templates and exhaust the execution space of problematic transaction events, such as the creation of new money out of thin air or transaction malleability. Second, one can leave in extensions to add more elements by way of soft forks if new functionality is required.
That said, there will always be a need to connect CSL to overlay protocols, legacy financial systems, and special purpose servers. Thus we have developed Plutus as both a general purpose smart contract language and also a special purpose DSL for interoperability.
Plutus is a typed functional language based on concepts from Haskell, which can be used to write custom transaction scripts. For CSL, it will be used for complex transactions required to add support for other layers we need to connect, such as our sidechains scheme.
Footnotes
6: Specifics will be released in an upcoming specification. The full language will be supported in the Shelley CSL release planned for Q4 of 2017.
7: Project ACTUS has an in-depth elaboration.