LOVE: a New Smart Contract Language for the Dune Network

David Declerck

Published in

Dune Network

5 min readJan 22, 2020

By De Oliveira Steven & David Declerck

Context

Released a few months ago, the Dune Network is focused on security, safety, and usability. To achieve this, it was decided to offer several native programming languages to smart contract developers. The first one, Michelson, is inherited from Tezos. Today, we briefly introduce the first brand-new language for Dune: Love. A more thorough article will follow in the next weeks.

In a few words, Love is designed to be expressive for fast development, efficient in execution time and cheap in storage, and readable for auditability of smart contracts. Yet, it has a clear and formal semantics and a strong type system to detect bugs. It allows contracts to use other contracts as libraries, and to call viewers on other contracts. Contracts developed in Love can also be formally verified.

Why Love ?

Designing a smart contract language is a matter of choosing the right balance between various (possibly incompatible) criteria.

At one end of the scale, we have very low-level languages such as Michelson: it has a limited expressiveness due to its reduced set of instructions and does not allow code sharing, rendering the writing of even simple contracts a time consuming and error-prone task. Its lack of readability makes smart contract auditing difficult. However, it has been designed with formal verification in mind, which helps writing formal analysis tools for smart contracts — although we may argue that formal verification of low-level code is not an easy task.

At the other end of the scale, we have very high-level languages like Solidity: it is an expressive and feature-rich language, allowing to easily write a broad range of smart contracts, but does not offer strong safety guarantees. Moreover, the code running on the blockchain is not the Solidity code itself, but the result of its compilation to EVM bytecode: once deployed, it is hard to tell what a contract really does.

Love has been designed to be in between: sufficiently high-level and expressive, yet also low-level in the sense that it is directly executed on the blockchain. This allows writing and reviewing/auditing smart contracts easily, and opens the door to a wide range of formal verification methods.

A comparison of smart contracts in Michelson, Solidity and Love

To illustrate the differences between the three languages, we’ll use a very basic smart contract that simply counts how many times it has been called and how much money it has received.

Love version

In Love, all contracts start with a #love directive, followed by the type of data that will be manipulated by the contract, i.e. its storage. We use a record type with two fields to store the two pieces of information we need: the total amount of money received (in DUN) and the total number of calls (a natural number). Then, a storage initializer indicates the initial value of each storage field — 0 in our case. Finally, contract actions are expressed as entry points, which are functions that take as input the storage, the amount of DUN received, and an arbitrary parameter and returns the updated storage and a (possibly empty) list of operations to be performed after the contract has finished running. In our case, we have a single entry point main that simply returns a new storage with updated totals.

#lovetype storage = {
  total : dun;
  calls : nat;
}val%init storage (_ : unit) = {
  total = 0.0dn;
  calls = 0p;
}val%entry main (s : storage) (amount : dun) (_ : unit) =
  let total = s.total +$ amount in
  let calls = s.calls ++ 1p in
  [][:operation], { total; calls }

This code is stored and executed under this form on the blockchain. Love contracts are both readable and efficient.

Michelson version

With Michelson, the contract is expressed as a series of low-level instructions operating on a stack. The stack initially contains the storage at the start of execution, and the resulting stack must contain only the output at the end of the execution.

parameter unit;
storage (pair mutez nat);
code { CDR ;
       PUSH nat 1 ;
       DUUP ;
       CDR ;
       ADD ;
       AMOUNT ;
       DUUUP ;
       DIIIP { DROP } ;
       CAR ;
       ADD ;
       PAIR ;
       NIL operation ;
       PAIR };

A notable aspect of this language is the ubiquitous use of DIP, DUP and SWAP to manipulate the stack. Despite targeting formal verification, its lack of readability makes contract auditing a nightmare.

Solidity (source) version

With Solidity, the contract is expressed in an object-oriented style. Storage are simply variables of the contract , and entry points are methods manipulating these variables.

pragma solidity >=0.4.0;contract Count {uint total = 0;
uint calls = 0;function main() public payable {
        total += msg.value;
        calls += 1;
    }
}

Despite its popularity, Solidity trades simplicity and expressiveness for safety and reliability, which is illustrated by tens of stories of huge losses due to bugs.

EVM bytecode generated for the Solidity version (excerpt)

While the Solidity code is easier to read, it is compiled down to EVM bytecode so that it can be executed on the blockchain. The following is an excerpt of the EVM bytecode generated for the above Solidity contract:

JUMPDEST
CALLVALUE
PUSH1 0x00
DUP1
DUP3
DUP3
SLOAD
ADD
SWAP3
POP
POP
DUP2
SWAP1
SSTORE
POP
PUSH1 0x01
DUP1
PUSH1 0x00
DUP3
DUP3
SLOAD
ADD
SWAP3
POP
POP
DUP2
SWAP1
SSTORE
POP
*JUMP

EVM is even harder to read than Michelson and provides no formal basis guarantees.

Comparison of Space Usage

The cost of originating a smart contract is proportional to its size on the chain. In Love, we put the emphasis on compressing the contract representation in the storage of the Dune Node. Using custom compression optimizations, Love contracts are twice smaller than Michelson contracts, hence twice cheaper to deploy (62 % smaller on average)

Key differences between LOVE and other languages

The table below sums of the main differences between LOVE and the language cited in this article.

Going Further

As stated in the introduction, a more detailed (technical) article will follow in the next weeks. Meanwhile, the Love tutorial is an excellent place to start learning Love: https://docs.dune.network/dune-node-next/love-doc/tutorial/tutorial.html.

EDITED: check our next article on Love: The Love Smart Contract Language: Introduction & Key Features — Part I

These are some of the resources you might find interesting in building your own smart contracts: