Solidity 0.5: when typed does not mean type safe

07/05/2019
by   Silvia Crafa, et al.
0

The recent release of Solidity 0.5 introduced a new type to prevent Ether transfers to smart contracts that are not supposed to receive money. Unfortunately, the compiler fails in enforcing the guarantees this type intended to convey, hence the type soundness of Solidity 0.5 is no better than that of Solidity 0.4. In this paper we discuss a paradigmatic example showing that vulnerable Solidity patterns based on potentially unsafe callback expressions are still unchecked. We also point out a solution that strongly relies on formal methods to support a type-safer smart contracts programming discipline, while being retro-compatible with legacy Solidity code.

READ FULL TEXT

page 1

page 2

page 3

page 4

research
09/25/2020

A formal model of Algorand smart contracts

We develop a formal model of Algorand stateless smart contracts (statele...
research
04/13/2019

Flint for Safer Smart Contracts

The Ethereum blockchain platform supports the execution of decentralised...
research
03/12/2020

ÆGIS: Shielding Vulnerable Smart Contracts Against Attacks

In recent years, smart contracts have suffered major exploits, costing m...
research
08/04/2022

Deductive Verification of Smart Contracts with Dafny

We present a methodology to develop verified smart contracts. We write s...
research
09/08/2019

Obsidian: Typestate and Assets for Safer Blockchain Programming

Blockchain platforms are coming into broad use for processing critical t...
research
09/02/2020

zkay v0.2: Practical Data Privacy for Smart Contracts

Recent work introduces zkay, a system for specifying and enforcing data ...
research
02/14/2019

Smart contracts meet quantum cryptography

We put forward the idea that classical blockchains and smart contracts a...

Please sign up or login with your details

Forgot password? Click here to reset