14,331 research outputs found

    Formal Semantic Approach to Detect Smart Contract Vulnerabilities Using KEVM

    Get PDF
    Smart contracts are self-executing programs that run on blockchain platforms. While smart contracts offer a range of benefits, such as immutability and transparency, they are not immune to vulnerabilities. Malicious actors can exploit smart contract vulnerabilities to execute unintended actions or access sensitive data[1]. One approach to mitigating smart contract vulnerabilities is formal verification. Formal verification is a method of verifying the correctness of software using mathematical techniques. It involves mathematically proving that a program conforms to a set of specifications. Formal verification can help detect and eliminate vulnerabilities in smart contracts before they are deployed on the blockchain. KEVM (K Framework-based EVM) is a framework that allows for formal verification of smart contracts on the Ethereum Virtual Machine (EVM). KEVM uses the K Framework, a formal semantics framework, to specify the behavior of the EVM. With KEVM, smart contract developers can verify the correctness of their contracts before deployment, reducing the risk of vulnerabilities. In this paper, we have studied smart contract vulnerabilities such as Over usage of Gas, Signature Replay attack, and misuse of fallback function. We have also written the formal specification for these vulnerabilities and executed it using KEVM

    Model-Checking of Smart Contracts

    Get PDF
    International audienceDAO attack showed that formal verification of smart contracts is an important issue that should be addressed to prevent irreversible consequences due to design faults activation in Blockchain applications. This paper proposes a modeling method of an Ethereum application based on smart contracts, with the aim of applying a formal method, namely Model-Checking, to verify that the application implementation complies with its specification, formalized by a set of temporal logic propositions. NuSMV tool has been chosen to support this first approach. The proposed model template is shaped by three layers capturing respectively the behavior of Ethereum blockchain, the smart contracts themselves and the execution framework. The approach is illustrated by a case study coming from energy market field

    Money Grows on (Proof-)Trees: The Formal FA1.2 Ledger Standard

    Get PDF
    Once you have invented digital money, you may need a ledger to track who owns what - along with an interface to that ledger so that users of your money can transact. On the Tezos blockchain this implies: a smart contract (distributed program), storing in its state a ledger to map owner addresses to token quantities; along with standardised entrypoints to query and transact on accounts. A bank does a similar job - it maps account numbers to account quantities and permits users to transact - but in return the bank demands trust, it incurs expense to maintain a centralised server and staff, it uses a proprietary interface ... and it may speculate using your money and/or display rent-seeking behaviour. A blockchain ledger is by design decentralised, inexpensive, open, and it won\u27t just decide to bet your tokens on risky derivatives (unless you want it to). The FA1.2 standard is an open standard for ledger-keeping smart contracts on the Tezos blockchain. Several FA1.2 implementations already exist. Or do they? Is the standard sensible and complete? Are the implementations correct? And what are they implementations of? The FA1.2 standard is written in English, a specification language favoured by wet human brains but notorious for its incompleteness and ambiguity when rendered into dry and unforgiving code. In this paper we report on a formalisation of the FA1.2 standard as a Coq specification, and on a formal verification of three FA1.2-compliant smart contracts with respect to that specification. Errors were found and ambiguities were resolved; but also, there now exists a mathematically precise and battle-tested specification of the FA1.2 ledger standard. We will describe FA1.2 itself, outline the structure of the Coq theories - which in itself captures some non-trivial and novel design decisions of the development - and review the detailed verification of the implementations
    • …
    corecore