739 research outputs found

    Formalisation of Smart Contract Languages

    Get PDF
    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

    Mixin Composition Synthesis based on Intersection Types

    Full text link
    We present a method for synthesizing compositions of mixins using type inhabitation in intersection types. First, recursively defined classes and mixins, which are functions over classes, are expressed as terms in a lambda calculus with records. Intersection types with records and record-merge are used to assign meaningful types to these terms without resorting to recursive types. Second, typed terms are translated to a repository of typed combinators. We show a relation between record types with record-merge and intersection types with constructors. This relation is used to prove soundness and partial completeness of the translation with respect to mixin composition synthesis. Furthermore, we demonstrate how a translated repository and goal type can be used as input to an existing framework for composition synthesis in bounded combinatory logic via type inhabitation. The computed result is a class typed by the goal type and generated by a mixin composition applied to an existing class

    Estimating resource bounds for software transactions

    Get PDF
    We present an effect based static analysis to calculate upper and lower bounds on the memory resource consumption in a transactional calculus. The calculus is a concurrent variant of Featherweight Java extended by transactional constructs. The model supports nested and concurrent transactions. The analysis is compositional and takes into account implicit join synchronizations that arise when more than one thread perfom a join-synchronization when jointly committing a transaction. Central for a compositional and precise analysis is to capture as part of the effects a tree-representation of the future resource consumption and synchronization points (which we call joining commit trees). We show the soundness of the analysis

    A Type-Safe Model of Adaptive Object Groups

    Full text link
    Services are autonomous, self-describing, technology-neutral software units that can be described, published, discovered, and composed into software applications at runtime. Designing software services and composing services in order to form applications or composite services requires abstractions beyond those found in typical object-oriented programming languages. This paper explores service-oriented abstractions such as service adaptation, discovery, and querying in an object-oriented setting. We develop a formal model of adaptive object-oriented groups which offer services to their environment. These groups fit directly into the object-oriented paradigm in the sense that they can be dynamically created, they have an identity, and they can receive method calls. In contrast to objects, groups are not used for structuring code. A group exports its services through interfaces and relies on objects to implement these services. Objects may join or leave different groups. Groups may dynamically export new interfaces, they support service discovery, and they can be queried at runtime for the interfaces they support. We define an operational semantics and a static type system for this model of adaptive object groups, and show that well-typed programs do not cause method-not-understood errors at runtime.Comment: In Proceedings FOCLASA 2012, arXiv:1208.432

    Featherweight Generic Confinement

    No full text
    Existing approaches to object encapsulation either rely on ad hoc syntactic restrictions or require the use of specialised type systems. Syntactic restrictions are difficult to scale and to prove correct, while specialised type systems require extensive changes to programming languages. We demonstrate that confinement can be enforced cheaply in Featherweight Generic Java, with no essential change to the underlying language or type system. This result demonstrates that polymorphic type parameters can simultaneously act as ownership parameters and should facilitate the adoption of confinement and ownership type systems in general-purpose programming languages
    • …
    corecore