Flint for safer smart contracts

The Ethereum blockchain platform supports the execution of decentralised applications or smart contracts. These typically hold and transfer digital currency to other parties on the platform; however, they have been subject to numerous attacks due to the unintentional introduction of bugs. Over a billion dollars worth of currency has been stolen since its release in July 2015. As smart contracts cannot be updated after deployment, it is imperative that the programming language supports the development of robust contracts. We propose Flint, a new statically-typed programming language specifically designed for writing robust smart contracts. Flint's features enforce the writing of safe and predictable code. To encourage good practices, we introduce protection blocks. Protection blocks restrict who can run code and when (using typestate) it can be executed. To prevent vulnerabilities relating to the unintentional loss of currency, Flint Asset traits provide safe atomic operations, ensuring the state of contracts is always consistent. Writes to state are restricted, simplifying reasoning about smart contracts

Dissecting Smart Contract Languages: A Survey

Blockchain is a distributed ledger technology that gained popularity for enabling the transformation of cryptocurrency among peers without mediation by a centralized third-party authority. Smart contracts expand the applications of blockchain technology and have played a role in its widespread adoption. Smart contracts are immutable digital programs that are deployed on blockchains to codify agreements between parties. Existing smart contract implementations have faced challenges, including security vulnerabilities, leading to significant losses and concerns. This has stimulated a wave of attempts to improve Smart Contract Languages (SCLs) to overcome implementation challenges and ensure code quality, producing many languages with diverse features. Scholars have made some attempts to classify SCLs and clarify the process of selecting an SCL, but to the best of our knowledge, no comprehensive survey of existing SCLs has been published. Our work surpasses earlier efforts by evaluating a significantly larger set of SCLs, in greater depth, to ease the process of SCL selection for blockchain research and implementation. In this paper, we (1) propose a robust framework for comparing existing SCLs, (2) analyze and discuss 36 SCLs, addressing issues beyond those used to construct the comparison framework, and (3) define new parameters for future research and development of SCLs. The survey provides a guide for those who intend to select or use an SCL to implement smart contracts, develop new SCLs, or add new extensions to the existing SCLs

Formalisation of Smart Contract Languages

Smart contracts automatically verify and enforce contractual agreements without the need of a trusted intermediary, as potential conflicts are resolved by the network’s consensus protocol. Since "code is law", contracts should be correct, but bugs and vulnerabilities, often exploited by attackers, allow erroneous or even fraudulent behaviour. These days smart contracts are still mostly being written in general purpose programming languages, without proper specifications, let alone correctness proofs. Immutability is one of its selling points, but it is also one of its major problems, as once a contract is deployed to the blockchain it cannot be amended. Additionally, many vulnerabilities come from the misimplementation of contracts’ intended behaviour, as developers struggle to grasp the behavioural impact that the contract has in the blockchain. It is thus crucial to achieve correct implementations of smart contracts. In order to aid developers to promote the design of safer contracts that follow the protocols they are supposed to implement, we propose the use of behavioural types in smart languages. We believe that the use of typestates, for dynamic checking, and session types, for static checking, can ensure the intended behaviour of the contract before and during its execution. To better understand a contract’s behaviour throughout its execution, we took advantage of Racket (and PLT Redex), to have a visualisation of a step-by-step execution graph. By formally defining the syntax and reduction rules of a "core" smart contract language, and how each rule affects the statements and the programs configuration, this visualisation tool allows programmers to check and adjust the language’s formal semantics. This is a successful proof-of-concept exercise, confirming the suitability of Racket to develop program semantics which can be analysed throughout its execution. In the context of smart contract languages, these are important features (to be combined with formal verification with proof assistants). Furthermore, we also implemented a typechecker in OCaml that provides a type derivation tree of the program, in addition to preventing the occurrence of execution errors. To illustrate the usefulness of this approach, we took two different smart contract languages, one completely formalised with syntax, operational semantics and type system (Featherweight solidity, FS), and another only with its natural language semantics (Flint). We formalised FS in Racket and OCaml, where we were able to detect an inaccuracy; and we repeated this process with Flint, formalising its operation semantics and type system. The latter was much more challenging as it incorporated the use of typestates. Throughout this thesis, we present many examples on how the use of visual tools can help in the developing states of contracts and better understand the correct execution of programs, as well as how the use of behavioural types can prevent many execution errors even before running. The framework we define herein not only finds defects in the contracts, but also, crucially, detects vulnerabilities in a language construction, as we demonstrate with our use-cases. Therefore, this approach is very valuable not only for the programmer as visual debugging, but also for the language designer to test the effects of definitions

Advanced typing for asset-aware programming languages

openLa rilevazione di errori nei linguaggi di programmazione è sempre stata importante nel ridurre la presenza di bug e vulnerabilità del software e lo sviluppo di strumenti che aiutino i programmatori in tal senso sono cruciali per le aziende del settore. Nei programmi è possibile riscontrare diverse tipologie di errori che possono causare comportamenti inaspettati da parte del software o addirittura al crash. Fortunatamente, alcuni di questi errori possono essere individuati usando sistemi di tipi e compilatori. Tuttavia, i moderni compilatori potrebbero non essere più abbastanza: infatti, lo spettro di possibili errori introdotti dai programmatori si è molto ampliato insieme alla complessità dei sistemi informatici odierni, come ad esempio le blockchain. I linguaggi per questi ambienti dovrebbero considerare una nuova categoria di errori correlata agli asset: infatti, in questi casi la loro duplicazione, creazione o perdita arbitraria dovrebbe essere evitata. Queste tipologie di errori sono strettamente correlati al concetto di stato di un oggetto, il quale è un’istanza di uno smart contract. In questa tesi, vengono discussi due linguaggi di programmazione typestate-oriented progettati per lo sviluppo di smart contracts, Stipula e Obsidian, vengono messi a confronto in termini di espressività e proprietà. In questa analisi, si può notare che Stipula adotta un approccio più safe e flessibile di Obsidian nella scrittura di legal contracts, grazie alla disponibilità di determinate primitive di linguaggio. Queste funzionalità permettono una realizzazione più semplice e comprensibile dei contratti e costringe il programmatore a un approccio più safe nello sviluppo. D’altro canto, Stipula non possiede altre funzionalità, come tipi user-defined e strutture dati, tipiche dei linguaggi di programmazione a oggetti: in particolare, non supporta un sistema di tipi completo e che permetta di assicurare proprietà di safety per gli asset. Successivamente, viene fornita e discussa una realizzazione in Obsidian delle currencies e dei tokens usati in Stipula allo scopo di trovare un modo di aggiungere in questo nuovo linguaggio un sistema di ownership, il quale potrebbe aiutare nella rilevazione di errori per riferimenti ad asset. Vengono, dunque, fornite le dimostrazioni che gli statement presi in considerazione sono ben tipati: gli strumenti teorici usati nelle dimostrazioni forniscono effettivamente delle indicazioni su come l’ownership dovrebbe funzionare in Stipula. Questa tesi si concentra sulla ricerca di funzionalità e pratiche per migliorare l’espressività dei linguaggi typestate-oriented. Obsidian è un linguaggio staticamente tipato e typestate-oriented con una particolare attenzione alla safety, alla security e all’usabilità. Queste caratteristiche fanno parte anche dei principali obiettivi di Stipula, un nuovo linguagggio typestate-oriented per i legal contracts. L’inserimento di tali funzionalità in Stipula potrebbe essere un buon modo per migliorarne le proprietà di safety e l’esperienza d’uso del programmatore.Error detection in programming languages has always been important in reducing bugs and vulnerabilities in programs and tools that help programmers in this task are crucial for the industry. Several kinds of error may occur in programs that can cause unexpected behaviours and lead to crashes. Fortunately, some of them can be detected using type systems and compilers. However, modern compilers may not be enough anymore: in fact, the range of mistakes that programmers may introduce is widely spread with the increasing complexity of today’s systems, such as blockchains. Languages for these environments should consider new classes of errors related to assets: in fact, in this context arbitrary duplication, creation or loss of assets should be avoided. These new kinds of error are strictly related to the concept of the state of objects, which are in blockchains smart contract instances. In this thesis, we discuss two typestated-oriented programming languages designed for smart contracts development, Stipula and Obsidian, and compare their expressiveness and main properties. In this analysis, we notice that Stipula adopts a safer and more flexible approach than Obsidian in legal contract writing, due to the primitives available for programmers. These features enable a simpler and more readable implementation of contracts and enforce a safer approach to development. On the other hand, Stipula lacks typical functionalities, such as user-defined data and data structures, that other object-oriented programming languages have: in particular, it does not support a full-fledged type system that ensures safety properties on asset operation. Then, an Obsidian implementation for currencies and tokens used in Stipula is provided and discussed in order to find hints to add in this new language ownership, which would help in error detection for asset references. Proofs that they are well-typed are provided: the tools used in these demonstrations give us some hints, especially on how ownership should work in Stipula statements. This thesis focused on the search for features and practises to improve the expressiveness of typestate-oriented programming languages. Obsidian is a statically-typed and typestate-oriented with careful attention to safety, security and usability. These features fall within the main goals of Stipula, a newborn typestate-oriented language for legal contracts. The insertion of such features in Stipula may be a good way to improve its safety and users’ experience

Short Paper: Blockcheck the Typechain

Recent efforts have sought to design new smart contract programming languages that make writing blockchain programs safer. But programs on the blockchain are beholden only to the safety properties enforced by the blockchain itself: even the strictest language-only properties can be rendered moot on a language-oblivious blockchain due to inter-contract interactions. Consequently, while safer languages are a necessity, fully realizing their benefits necessitates a language-aware redesign of the blockchain itself. To this end, we propose that the blockchain be viewed as a typechain: a chain of typed programs-not arbitrary blocks-that are included iff they typecheck against the existing chain. Reaching consensus, or blockchecking, validates typechecking in a byzantine fault-tolerant manner. Safety properties traditionally enforced by a runtime are instead enforced by a type system with the aim of statically capturing smart contract correctness. To provide a robust level of safety, we contend that a typechain must minimally guarantee (1) asset linearity and liveness, (2) physical resource availability, including CPU and memory, (3) exceptionless execution, or no early termination, (4) protocol conformance, or adherence to some state machine, and (5) inter-contract safety, including reentrancy safety. Despite their exacting nature, typechains are extensible, allowing for rich libraries that extend the set of verified properties. We expand on typechain properties and present examples of real-world bugs they prevent

Semantic understanding of smart contracts: Executable operational semantics of solidity

Ministry of Education, Singapore under its Academic Research Funding Tier 2; National Research Foundation (NRF) Singapor

Detection of Vulnerabilities in Smart Contracts Specifications in Ethereum Platforms

Ethereum is the principal ecosystem based on blockchain that provides a suitable environment for coding and executing smart contracts, which have been receiving great attention due to the commercial apps and among the scientific community. The process of writing secure and well performing contracts in the Ethereum platform is a major challenge for developers. It consists of the application of non-conventional programming paradigms due to the inherent characteristics of the execution of distributed computing programs. Furthermore, the errors in the deployed contracts could have serious consequences because of the immediate linkage between the contract code and the financial transactions. The direct handling of the assets means that the errors can be more relevant for security and have greater economic consequences than a mistake in the conventional apps. In this paper, we propose a tool for the detection of vulnerabilities in high-level languages based on automatized static analysis