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.

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

Di Pirro, Matteo
2018/2019

Abstract

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.
2018-09
211
type Safety, Ethereum, Solidity, smart contracts, type systems
File in questo prodotto:
File Dimensione Formato  
tesi_Di_Pirro.pdf

accesso aperto

Dimensione 1.32 MB
Formato Adobe PDF
1.32 MB Adobe PDF Visualizza/Apri

The text of this website © Università degli studi di Padova. Full Text are published under a non-exclusive license. Metadata are under a CC0 License

Utilizza questo identificativo per citare o creare un link a questo documento: https://hdl.handle.net/20.500.12608/23606