Behavioral types in programming languages

A recent trend in programming language research is to use behav- ioral type theory to ensure various correctness properties of large- scale, communication-intensive systems. Behavioral types encompass concepts such as interfaces, communication protocols, contracts, and choreography. The successful application of behavioral types requires a solid understanding of several practical aspects, from their represen- tation in a concrete programming language, to their integration with other programming constructs such as methods and functions, to de- sign and monitoring methodologies that take behaviors into account. This survey provides an overview of the state of the art of these aspects, which we summarize as the pragmatics of behavioral types

Preventing Atomicity Violations with Contracts

Software developers are expected to protect concurrent accesses to shared regions of memory with some mutual exclusion primitive that ensures atomicity properties to a sequence of program statements. This approach prevents data races but may fail to provide all necessary correctness properties.The composition of correlated atomic operations without further synchronization may cause atomicity violations. Atomic violations may be avoided by grouping the correlated atomic regions in a single larger atomic scope. Concurrent programs are particularly prone to atomicity violations when they use services provided by third party packages or modules, since the programmer may fail to identify which services are correlated. In this paper we propose to use contracts for concurrency, where the developer of a module writes a set of contract terms that specify which methods are correlated and must be executed in the same atomic scope. These contracts are then used to verify the correctness of the main program with respect to the usage of the module(s). If a contract is well defined and complete, and the main program respects it, then the program is safe from atomicity violations with respect to that module. We also propose a static analysis based methodology to verify contracts for concurrency that we applied to some real-world software packages. The bug we found in Tomcat 6.0 was immediately acknowledged and corrected by its development team

Static Application-Level Race Detection in STM Haskell using Contracts

Writing concurrent programs is a hard task, even when using high-level synchronization primitives such as transactional memories together with a functional language with well-controlled side-effects such as Haskell, because the interferences generated by the processes to each other can occur at different levels and in a very subtle way. The problem occurs when a thread leaves or exposes the shared data in an inconsistent state with respect to the application logic or the real meaning of the data. In this paper, we propose to associate contracts to transactions and we define a program transformation that makes it possible to extend static contract checking in the context of STM Haskell. As a result, we are able to check statically that each transaction of a STM Haskell program handles the shared data in a such way that a given consistency property, expressed in the form of a user-defined boolean function, is preserved. This ensures that bad interference will not occur during the execution of the concurrent program.Comment: In Proceedings PLACES 2013, arXiv:1312.2218. [email protected]; [email protected]

Practical API Protocol Checking with Access Permissions

Reusable APIs often define usage protocols. We previously developed a sound modular type system that checks compliance with typestate-based protocols while affording a great deal of aliasing flexibility. We also developed Plural, a prototype tool that embodies our approach as an automated static analysis and includes several extensions we found useful in practice. This paper evaluates our approach along the following dimensions: (1) We report on experience in specifying relevant usage rules for a large Java standard API with our approach. We also specify several other Java APIs and identify recurring patterns. (2) We summarize two case studies in verifying third-party open-source code bases with few false positives using our tool. We discuss how tool shortcomings can be addressed either with code refactorings or extensions to the tool itself. These results indicate that our approach can be used to specify and enforce real API protocols in practice

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

Linear Haskell: practical linearity in a higher-order polymorphic language

Linear type systems have a long and storied history, but not a clear path forward to integrate with existing languages such as OCaml or Haskell. In this paper, we study a linear type system designed with two crucial properties in mind: backwards-compatibility and code reuse across linear and non-linear users of a library. Only then can the benefits of linear types permeate conventional functional programming. Rather than bifurcate types into linear and non-linear counterparts, we instead attach linearity to function arrows. Linear functions can receive inputs from linearly-bound values, but can also operate over unrestricted, regular values. To demonstrate the efficacy of our linear type system - both how easy it can be integrated in an existing language implementation and how streamlined it makes it to write programs with linear types - we implemented our type system in GHC, the leading Haskell compiler, and demonstrate two kinds of applications of linear types: mutable data with pure interfaces; and enforcing protocols in I/O-performing functions

Modular session types for objects

Session types allow communication protocols to be specified type-theoretically so that protocol implementations can be verified by static type checking. We extend previous work on session types for distributed object-oriented languages in three ways. (1) We attach a session type to a class definition, to specify the possible sequences of method calls. (2) We allow a session type (protocol) implementation to be modularized, i.e. partitioned into separately-callable methods. (3) We treat session-typed communication channels as objects, integrating their session types with the session types of classes. The result is an elegant unification of communication channels and their session types, distributed object-oriented programming, and a form of typestate supporting non-uniform objects, i.e. objects that dynamically change the set of available methods. We define syntax, operational se-mantics, a sound type system, and a sound and complete type checking algorithm for a small distributed class-based object-oriented language with structural subtyping. Static typing guarantees that both sequences of messages on channels, and sequences of method calls on objects, conform to type-theoretic specifications, thus ensuring type-safety. The language includes expected features of session types, such as delegation, and expected features of object-oriented programming, such as encapsulation of local state.Comment: Logical Methods in Computer Science (LMCS), International Federation for Computational Logic, 201

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