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

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

The Challenges of The Implementation of Smart Contracts Related to Consumer Protection in Electronic Transactions

Smart contracts, which are computer code protocolsthat leverage digital contracts in the blockchainnetwork. Smart contracts can make transactions noteasy to change, more permanent, not easily damaged,more efficient, faster, and more secure becauseeverything is recorded in the blockchain system.However, smart contracts are not without challenges.This study uses a normative juridical approach byanalyzing secondary legal materials complemented byrelevant primary legal materials. Challenges related tosmart contracts in consumer protection, namelyprogramming codes, may not guarantee representationof the parties, the inability of smart contracts (to date)to provide flexibility in contractual frameworks, andcomplex programming languages for partiesunfamiliar with coding. In addition, the partiesinvolved in the transaction and do not have a codingbackground, of course, do not easily interpret smartcontracts. In the end, regulation is essential to protectusers, ensure the security and rights of the parties, sothat this technology does not disrupt particularmarkets, but on the other hand, too much regulationwill hinder innovatio

How solid is solidity? An in-dept study of solidity’s type safety.

Blockchain has evolved a lot in the last years: one of the most important features is the possibility, for mutually untrusted parties, to interact with one another without relying on a third party trusted entity. This interaction is made possible by the so-called smart contracts, passive arbitrary programs executed in a decentralized network and usually manipulating money. One of the main platforms in this sense is Ethereum, and a number of programming languages exist in its ecosystem, all with points of strength and flaws. Of these, the most widely used is for sure Solidity. In spite of its high potential, repeated security concerns have undercut the trust in this way of handling money. Bugs and undesired behaviors are worsened by the impossibility of patching a contract once it is deployed on the blockchain. As a consequence, many analysis tools have been developed by researchers. However, those operating on Solidity lack a real formalization of the core of this language. We aim to fill the gap with Featherweight Solidity (FS). To the best of our knowledge, this is the first calculus including the semantics as well as the type system. Thanks to it, we proved the theorem of Type Safety for Solidity (claimed in the official documentation, although not supported by any public proof). We also formalized, and proved, an extended Type Safety statement addressing groups of transactions. During this process, we found out that Solidity's type system is far from being safe with respect to any type of error: in many occasions, contract interfaces are not consulted at compile-time, and this makes the execution raise an exception and the user waste money. Sometimes, in particular when transferring money from one party to another, exceptions can be avoided by simply looking at, at compile-time, contract interfaces. We also propose an extension of the type system, FS+, that targets this undesired behavior. We prove that Type Safety is maintained, but we formalize additional theorems stating new safety properties, too. In particular, but not only, FS+ statically detects, and consequently rules out, ill-formed money transfers made by means of the Solidity's built-in transfer function. We compared it with Solidity, and showed that including this extension does not change radically the way of writing smart contracts, whereas it makes them much safer.ope