Securify: Practical Security Analysis of Smart Contracts
Petar Tsankov
ETH Zurich
petar.tsankov@inf.ethz.ch
Andrei Dan
ETH Zurich
andrei.dan@inf.ethz.ch
Dana Drachsler-Cohen
ETH Zurich
dana.drachsler@inf.ethz.ch
Arthur Gervais
∗
Imperial College London
a.gervais@imperial.ac.uk
Florian Bünzli
ETH Zurich
fbuenzli@student.ethz.ch
Martin Vechev
ETH Zurich
martin.vechev@inf.ethz.ch
ABSTRACT
Permissionless blockchains allow the execution of arbitrary pro-
grams (called smart contracts), enabling mutually untrusted entities
to interact without relying on trusted third parties. Despite their
potential, repeated security concerns have shaken the trust in han-
dling billions of USD by smart contracts.
To address this problem, we present Securify, a security ana-
lyzer for Ethereum smart contracts that is scalable, fully automated,
and able to prove contract behaviors as safe/unsafe with respect to
a given property. Securify’s analysis consists of two steps. First, it
symbolically analyzes the contract’s dependency graph to extract
precise semantic information from the code. Then, it checks com-
pliance and violation patterns that capture sucient conditions
for proving if a property holds or not. To enable extensibility, all
patterns are specied in a designated domain-specic language.
Securify is publicly released, it has analyzed
>
18
K
contracts
submitted by its users, and is regularly used to conduct security
audits by experts. We present an extensive evaluation of Securify
over real-world Ethereum smart contracts and demonstrate that it
can eectively prove the correctness of smart contracts and discover
critical violations.
KEYWORDS
Smart contracts; Security analysis; Stratied Datalog
1 INTRODUCTION
Blockchain platforms, such as Nakamoto’s Bitcoin [
43
], enable the
trade of crypto-currencies between mutually mistrusting parties.
To eliminate the need for trust, Nakomoto designed a peer-to-peer
network that enables its peers to agree on the trading transactions.
Buterin [
24
] identied the applicability of decentralized computa-
tion beyond trading, and designed the Ethereum blockchain which
supports the execution of programs, called smart contracts, written
in Turing-complete languages. Smart contracts have shown to be
applicable in many domains including nancial industry [
8
], public
sector [11] and cross-industry [9].
The increased adoption of smart contracts demands strong se-
curity guarantees. Unfortunately, it is challenging to create smart
contracts that are free of security bugs. As a consequence, critical
vulnerabilities in smart contracts are discovered and exploited ev-
ery few months [
2
,
3
,
6
,
7
,
10
,
26
]. In turn, these exploits have led to
losses reaching millions worth of USD in the past few years: 150M
were stolen from the popular DAO contract in June 2016 [
6
], 30M
were stolen from the widely-used Parity multi-signature wallet in
∗
Work done while at ETH Zurich
July 2017 [
10
], and few months later 280M were frozen due to a bug
in the very same wallet [
13
]. It is apparent that eective security
checkers for smart contracts are urgently needed.
Key Challenges.
The main challenge in creating an eective secu-
rity analyzer for smart contracts is the Turing-completeness of the
programming language, which renders automated verication of
arbitrary properties undecidable. To address this issue, current auto-
mated solutions tend to rely on fairly generic testing and symbolic
execution methods (e.g., Oyente [
39
] and Mythril [
16
]). While use-
ful in some settings, these approaches come with several drawbacks:
(i) they can miss critical violations (due to under-approximation),
(ii) yet, can also produce false positives (due to imprecise modeling
of domain-specic elements [
30
]), and (iii) they can fail to achieve
sucient code coverage on realistic contracts (Oyente achieves
only 20
.
2% coverage on the popular Parity wallet [
17
]). Overall,
these drawbacks place a signicant burden on their users, who must
inspect all reports for false alarms and worry about unreported vul-
nerabilities. Indeed, many security properties for smart contracts
are inherently dicult to reason about directly. A viable path to
addressing these challenges is building an automated verier that
targets important domain-specic properties [
15
]. For example, re-
cent work [
31
] focuses solely on identifying reentrancy issues in
smart contracts [5].
Domain-Specic Insight.
A key observation of this work is that
it is often possible to devise precise patterns expressed on the
contract’s data-ow graph in a way where a match of the pattern
implies either a violation or satisfaction of the original security
property. For example, 90
.
9% of all calls in Ethereum smart contracts
can be proved free of the infamous DAO bug [
6
] by matching a
pattern stating that calls are not followed by writes to storage.
The reason why it is possible to establish such a correspondence
is that violations of the original property in real-world contracts
tend to often violate a much simpler property (captured by the
pattern). Indeed, in terms of verication, a key benet in working
with patterns, instead of with their corresponding property, is that
patterns are substantially more amenable to automated reasoning.
Securify: Domain-specic Verier.
Based on the above in-
sight, we developed Securify, a lightweight and scalable security
verier for Ethereum smart contracts. The key technical idea is to
dene two kinds of patterns that mirror a given security property:
(i) compliance patterns, which imply the satisfaction of the property,
and (ii) violation patterns, which imply its negation. To check these
patterns, Securify symbolically encodes the dependence graph of
the contract in stratied Datalog [
50
] and leverages o-the-shelf
1
arXiv:1806.01143v2 [cs.CR] 24 Aug 2018
contract
bytecode
semantic facts (§4) compliance and
violation patterns (§5)
security
report
00:60
01:07
02:5b
03:56
04:10
...
MemTag(0x20,Const)
MemVal(0x40,Caller)
Eq(x, MLoad(0x40))
SStore(02, Gas, y)
Call(04, x, y)
...
exists Call(_, _, y)
!MayDep(y,Gas)
all SStore(_, x, _)
DetBy(x,Caller)
...
Figure 1: Securify’s approach is based on automatic infer-
ence of semantic program facts followed by checking of
compliance and violation security patterns over these facts.
scalable Datalog solvers to eciently (typically within seconds)
analyze the code. To ensure extensibility, all patterns are expressed
in a designated domain-specic language (DSL).
In Fig. 1, we illustrate the analysis ow of Securify. Starting
with the contract’s bytecode (or source code, which can be compiled
to bytecode), Securify derives semantic facts inferred by analyzing
the contract’s dependency graph and uses these facts to check a set
of compliance and violation patterns. Based on the outcome of these
checks, Securify classies all contract behaviors into violations (
_
),
warnings (
▲
), and compliant (
■
), as abstractly illustrated in Fig. 2.
Here, the large box depicts all contract behaviors, partitioned into
safe (which satisfy the property) and unsafe ones (which violate
it). Securify reports as violations (
_
) all behaviors matching the
violation pattern, and as warnings (
▲
) all remaining behaviors not
matched by the compliance pattern.
Reduced Manual Eort.
Compared to existing symbolic ana-
lyzers for smart contracts, Securify reduces the required eort to
inspect reports in two ways. First, existing analyzers do not report
denite violations (they conate
_
and
▲
), and thus require users
to manually classify all reported vulnerabilities into true positives
(found in the
red box
) or false positives (found in the
green box
).
In contrast, Securify automatically classies behaviors guaranteed
to be violations (marked with
_
). Hence, the user only needs to
manually classify the warnings (▲) as true or false positives.
As we show in our evaluation, the approach of using both viola-
tion and compliance patterns reduces the warnings a user needs
to inspect manually by 65
.
9%, and even up to 99
.
4% for some prop-
erties. Second, existing analyzers fail to report unsafe behaviors
(sometimes up to 72
.
9%), meaning users may have to manually
inspect portions of the code that are not covered by the analyzer.
In contrast, Securify reports all unsafe behaviors.
Auditing Smart Contracts.
Securify is publicly available at
https://securify.ch and has analyzed
>
18
K
contracts submitted
by its users. Over the last year, we have also extensively used Secu-
rify to perform 38 detailed commercial audits of smart contracts
(other auditors have also used Securify), iteratively improving the
approach and adding more patterns. Indeed, the design and imple-
mentation of Securify have greatly beneted from this experience.
In terms of the actual audit process, our approach (and we believe
that of other auditors) has been to run all available tools and then
to manually inspect the reported vulnerabilities so to assess their
severity. For instance, while Securify covers a number of impor-
tant properties (the full version supports 18 properties), symbolic
unsafe behaviors safe behaviors
violation
pattern
compliance
pattern
warning
violation
no violation
all behaviors
Figure 2: Securify uses compliance and violation patterns
to guarantee that certain behaviors are safe and, respe c-
tively, unsafe. The remaining behaviors are reported as
warnings (to avoid missing errors).
execution tools have better support for numerical properties (e.g.,
overow). Our nding was that Securify was particularly help-
ful in auditing larger contracts, which are challenging to inspect
with existing solutions for the reasons listed earlier. Overall, we
believe Securify is a pragmatic and valuable point in the space of
analyzing smart contracts due to its careful balance of scalability,
guarantees, and precision.
Main Contributions.
To summarize, our main contributions are:
–
A decompiler that symbolically encodes the dependency
graph of Ethereum contracts in Datalog (Section 4).
–
A set of compliance and violation security patterns that
capture sucient conditions to prove and disprove practical
security properties (Section 5).
–
An end-to-end implementation, called Securify, which fully
automates the analysis of contracts (Section 6).
– An extensive evaluation over existing Ethereum smart con-
tracts showing that Securify can eectively prove the cor-
rectness of contracts and discover violations (Section 7).
2 MOTIVATING EXAMPLES
In this section, we motivate the problem we address through two
real-world security issues that aected
≈
200 millions worth of USD
in 2017. We describe the underlying security properties and the
challenges involved in proving whether a contract satises/violates
them. We also describe how Securify discovers both vulnerabilities
with appropriate violation patterns.
2.1 Stealing Ether
In Fig. 3, we show an implementation of a wallet. The code is written
in Solidity [
18
], a popular high-level language for writing Ethereum
smart contracts. We remark that this wallet is a simplied version
of Parity’s multi-signature wallet, which allowed an attacker to
steal 30 million worth of USD in July 2017.
The wallet has a eld
owner
, which stores the address of the
wallet’s owner. Further, the contract has a function
initWallet
,
which takes as argument an address
_
owner
and initializes the eld
owner
with it. This function is called by the constructor (not shown
in Fig. 3), and was assumed not to be accessible otherwise [
10
].
Finally, the contract has a function
withdraw
, which takes as ar-
gument an unsigned integer
_
amount
. The function checks if the
transaction sender’s address (returned by
msg.sender
) equals that
2
contract OwnableWallet {
address owner;
// called by the constructor
function initWallet(address _owner) {
owner = _owner; // any user can change owner
// more setup
}
// function that allows the owner to withdraw ether
function withdraw(uint _amount) {
if (msg.sender == owner) {
owner.transfer(_amount);
}
}
// ...
}
Figure 3: A vulnerable wallet that allows any user to with-
draw all ether stored in it.
of the contract’s owner (stored in the eld
owner
). If this check suc-
ceeds, it transfers
_
amount
ether to the owner with the statement
owner.transfer(
_
amount)
; otherwise, no ether is transferred. The
withdraw
function ensures that only the owner can withdraw ether
from the wallet.
Attack.
The wallet shown in Fig. 3 has a critical security aw:
any user could actually call the
initWallet
function and store an
arbitrary address in the eld
owner
. An attacker can, therefore, steal
all ether stored in the wallet in two steps. First, the attacker calls the
function
initWallet
, passing her own address as argument. Second,
the attacker calls the function
withdraw
, passing as argument the
amount of ether stored in the wallet. We remark that in the attack
on Parity’s wallet, to perform the rst step the attacker exploits a
fallback mechanism to call the
initWallet
function; we omit these
details for simplicity and refer the reader to [
10
] for details on the
actual attack.
Security Property.
The underlying security problem that allowed
the attacker to steal ether is that the security-critical eld
owner
is universally writable by any Ethereum user. This security issue
mirrors a more general property stipulating that the write to the
owner
eld is restricted, in the sense that not all users can make
a transaction that writes to this eld. To show that this property
is satised, we need to demonstrate that some user cannot send
a transaction that modies the
owner
eld. Conversely, to show a
violation, we need to prove that all users can send a transaction that
modies the
owner
eld. Proving both satisfaction and demonstrat-
ing violations of this property is nontrivial due to the enormous
space of possible users and transactions that they can make.
Detection.
To discover this security issue, Securify provides a
violation pattern that is matched if the execution of the assignment
owner =
_
owner
, highlighted in
red
in Fig. 3, does not depend
on the value returned by the
caller
instruction (which returns the
address of the transaction sender). To check this pattern, Securify
infers data- and control-ow dependencies by analyzing the con-
tract’s dependency graph; cf. [
35
]. Here, Securify infers that the
contract Wallet {
// fixed address of the wallet library
address constant walletLibrary = ...;
// function that receives ether
function deposit() payable {
log(msg.sender, msg.value);
}
// function for withdrawing ether
function withdraw() {
walletLibrary.delegatecall(msg.data);
}
// ...
} // No guaranteed ether transfer
Figure 4: A wallet that delegates functionality to a library
contract walletLibrary.
assignment
owner =
_
owner
does not depend on the
caller
instruc-
tion, which implies that the assignment is reachable by any user.
In Section 3, we provide more details on this violation pattern and
further details on how Securify uses it to detect the vulnerability.
We remark that some symbolic checkers perform imprecise
checks of similar properties, which result in both false positives and
false negatives. For instance, as we show in Fig. 13 of our evaluation
later, Mythril [
16
] has about 65% false negatives when checking a
similar property stipulating that not all users may trigger a particu-
lar ether transfer.
2.2 Frozen Funds
In Fig. 4, we show a wallet implementation which suers from a
security issue that froze millions worth of USD in November 2017.
This wallet has a eld,
walletLibrary
, which stores the address of a
contract implementing common wallet functionality. Further, it has
a function
deposit
, marked as payable, which means users can send
ether to the contract by calling this function. The function
deposit
logs the amount of ether (identied by
msg.value
) sent by the trans-
action sender (identied by
msg.sender
). Finally, the contract has
a function
withdraw
, which delegates all calls to the wallet library.
That is, the statement
walletLibrary.delegatecall(msg.data)
results in executing the
withdraw
method of the wallet library in
the context of the current wallet.
Attack.
Ethereum contracts can be removed from the blockchain
using a designated
kill
instruction. If an attacker can remove the
wallet library from the blockchain, then the funds in the wallet
cannot be extracted from the wallet. This is because the wallet
relies on the library smart contract to withdraw ether. In November
2017, a popular wallet library was removed from the blockchain,
eectively freezing ≈ 280 million worth of USD [7].
Security Property.
The underlying security problem with this
wallet is that it allows users to deposit ether, but it cannot guarantee
that the ether can be transferred out of the contract, since the
transfer depends on a library. To discover that the wallet has this
problem, we must prove two facts: (i) users can deposit ether and
3
EVM code
Matched pattern
00: 60 04
02: 35 60
04: 08 56
06: 5B 00
08: 5B 60
0A: 00 56
0C: 60 00
0E: 55 56
// entry
L1 a = 0x04
L2 b = dataload(a)
L3 ABI_9DA8(b)
L4 stop()
// method
ABI_9DA8(b) {
L5 c = 0x00
// write owner
L6 sstore(c, b);
}
00: push 0x04
02: dataload
03: push 08
05: jump
06: jumpdest
07: stop
08: jumpdest
09: push 0x00
0B: sload
0C: push 0x00
0E: sstore
0F: jump
...
!MayDepOn(c, Caller)
&& !MayDepOn(6, Caller)
Restricted write
violation pattern
MustFollow(L2, L1)
VarTag(a, const)
MayDepOn(b, dataload)
Eq(c, 0x00)
Parsed code Decompiled code
Semantic facts
...
// entry
L1 a = 0x04
L2 b = dataload(a)
L3 ABI_9DA8(b)
L4 stop()
// method
ABI_9DA8(b) {
L5 c = 0x00
// write owner
L6 sstore(c, b);
}
(1) (2)
(3)
(4)
Figure 5: High-level ow illustrating how Securify nds the unrestricted write to the owner eld of the contract from Fig. 3.
The input (EVM bytecode and security patterns) is highlighted in green , the output (in our example, a violated instruction)
is highlighted in red , and gray boxes represent intermediate analysis artifacts. Securify proceeds in three steps: (1) it
decompiles the contract’s EVM bytecode into a static-single assignment form, (2) it infers semantics facts about the contract,
and (3) it matches the violation pattern of the restricted write property on the sstore instruction that writes to the owner eld.
(ii) the contract has no ether transfer instructions (i.e.,
call
) with
non-zero amount of ether. Note that if the contract only transfers
out ether through libraries, the second requirement is met.
Detection.
To discover this vulnerability, Securify’s violation
pattern checks the conjunction of two facts. First, to prove that
users can deposit ether, Securify checks whether there is a
stop
in-
struction whose execution does not depend on the ether transferred
being zero. Assuming that the
stop
instruction is reachable for some
transaction, this implies that a user can reach it with a positive ether
amount, resulting in a deposit of ether to the contract. Second, Se-
curify checks whether for all
call
instructions, the amount of ether
extracted from the contract is zero. The conjunction of these two
facts implies that ether can be locked in the contract.
3 THE SECURIFY SYSTEM
In the previous section, we illustrated that while security issues in
smart contracts are complex, they can be often captured with se-
mantic facts inferred from the code. In this section, we describe the
Securify system, which builds on this idea to prove and disprove
security properties of smart contracts. We accompany this section
with the example of how Securify detects the unrestricted write
to the
owner
eld in the wallet contract (Fig. 3). Fig. 5 summarizes
the main steps.
Inputs to Securify.
The input to Securify is the EVM bytecode
of a contract and a set of security patterns, specied in our desig-
nated domain-specic language (DSL). Securify can also take as
input contracts written in Solidity (not shown in Fig. 5), which are
compiled to EVM bytecode before proceeding with the analysis.
There are two kinds of security patterns: compliance and violation
patterns, which capture sucient conditions to ensure that a con-
tract satises and, respectively, violates a given security property.
Fig. 5 illustrates the input to Securify in
green
boxes, which
show part of the EVM bytecode of the wallet contract (only the part
necessary to illustrate the vulnerability) and the violation pattern
of the restricted write property. Intuitively, the pattern is matched
if there is a write that is not restricted.
To discover the unrestricted write in the contract, Securify
proceeds with the following three steps.
Step 1: Decompiling EVM Bytecode.
Securify rst transforms
the EVM bytecode provided as input into a stackless representation
in static-single assignment form (SSA). For example, in Fig. 5, for the
stack expression
push 0x04
, Securify introduces a local variable
a
and an assignment statement
a = 4
. In addition to removing
the stack, Securify identies methods. For example, the method
ABI
_
9DA8
, shown in Fig. 5, corresponds to the
initOwner
method of
the wallet contract, shown in Fig. 3. After decompilation, Securify
performs partial evaluation to resolve memory and storage osets,
jump destinations, all of which are important for precisely analyzing
the code statically. We describe these optimizations in Section 6.
Step 2: Inferring Semantic Facts.
After decompilation, Secu-
rify analyzes the contract to infer semantic facts, including data-
and control-ow dependencies, which hold over all behaviors of
the contract. For example, the fact
MayDepOn(b, dataload)
, shown
in Fig. 5, captures that the value of variable
b
may depend on the
value returned by the instruction
dataload
. Further, the fact
Eq(c,
0
)
captures that variable c equals the constant 0.
Securify’s derivation of semantic facts is specied declaratively
in stratied Datalog and is fully automated using existing scalable
engines [
36
]. Key benets of the declarative approach are: (i) in-
ference rules concisely capture abstract reasoning about dierent
components (e.g., contract storage), (ii) more facts and inference
rules can be easily added, and (iii) inference rules are specied in a
modular way (e.g., memory analysis is specied independently of
contract storage analysis). We list the semantic facts that Securify
derives, along with the inference rules, in Section 4.
Step 3: Checking Security Patterns.
After obtaining the seman-
tics facts, Securify checks the set of compliance and violation
security patterns, given as input. These patterns are written in a
specialized domain-specic language (DSL), which enables secu-
rity experts to extend our built-in set of patterns with their cus-
tomized patterns. Our DSL is a fragment of logical formulas over
4
the semantic facts inferred by Securify. To detect the vulnerability
in the contract of Fig. 3, Securify matches the violation pattern
(given as input) on the
sstore(c, b)
instruction at label l6 in Fig. 5.
In
sstore(c, b)
,
c
is the storage oset of the
owner
eld, and
b
is the
value to store. The violation pattern matches if there exists some
sstore
instruction for which both the storage oset, denoted
X
,
and the execution of this instruction, identied by its label
L
, do
not depend on the result of the
caller
instruction in any possible
execution of the contract. Since the instruction
caller
retrieves the
address of the transaction sender, matching this pattern implies
that any user can reach this
sstore
and change the value of
owner
.
In our DSL, where negation is encoded by
¬
and conjunction by
∧
,
this pattern is encoded as:
some sstore(L, X, _). ¬MayDepOn(X, caller)∧¬MayDepOn(L, caller)
Securify’s DSL is important for extensibility: adding new secu-
rity patterns amounts to specifying them in this DSL. To illustrate
the expressiveness of the DSL, in Section 5, we present a range of
security patterns for important properties, such as restricted writes,
exception handling, ether liquidity, input validation, and others.
We remark that contract-specic patterns are sometimes added
by security experts while conducting security audits. For exam-
ple, it is often required to check for the absence of undesirable
dependencies, such as: only the owner can modify certain values
in the storage, or to ensure that the result of a specic arithmetic
expression does not depend on the division instruction (which may
cause undesirable integer rounding eects). We illustrate how such
contract-specic patterns are specied in the DSL in Section 5.
Output of Securify.
For any match of a violation pattern, Secu-
rify outputs the instruction that caused the pattern to match. In our
example, it highlights the instruction
sstore(c, b)
. We remark that
the oset of this instruction can be easily mapped to its correspond-
ing line in the Solidity code, if the source code is provided. Further,
for any property for which neither the violation nor the compliance
pattern is matched, Securify outputs a warning, indicating that it
failed to prove or disprove the property.
Limitations.
We briey summarize several limitations of Secu-
rify. First, the current version of Securify cannot reason about
numerical properties, such as overows. To address this limitation,
we plan to extend Securify with numerical analysis (e.g., using
ELINA [
48
]), which would not only improve the precision of Secu-
rify but also enable the checking of numerical properties.
Second, Securify does not reason about reachability, and as-
sumes that all instructions in the contract are reachable. This as-
sumption is necessary to establish a formal correspondence between
the security properties supported by Securify and the patterns
used to prove and disprove them. For instance, in our example,
Securify assumes that the matched
sstore
instruction is reachable
by some execution (otherwise, there is no violation).
Finally, the properties we consider capture violations that can of-
ten, but not always, be exploited by attackers. For example, there are
elds in the contract that must be universally writable by all users.
To address this, security experts can write contract-specic patterns
in Securify’s DSL (e.g., to specify which elds are sensitive).
4 SEMANTIC FACTS
In this section, we present the automated inference of control- and
data-ow dependencies that Securify employs. The facts inferred
in this process are called semantic facts and are later used for check-
ing security properties. We begin with the background necessary
for understanding this analysis: the EVM instruction set and strat-
ied Datalog. We then introduce the semantic facts derived by
Securify and the declarative inference rules, specied in stratied
Datalog, used to derive them.
4.1 Background
In this section, we provide the necessary background.
4.1.1 Ethereum Virtual Machine (EVM). Smart contracts are exe-
cuted on a blockchain. A contract executes when a user submits a
transaction that species the contract, the method to run, and the
method’s arguments (if any). When the transaction is processed,
it is added to a new block, which is appended to the blockchain.
Contracts can access a volatile memory and non-volatile storage.
The EVM instruction set (over which contracts are written) sup-
ports a few dozen opcodes. Securify handles all EVM opcodes;
we present the most relevant ones below. Note that many of the
opcodes (such as
push
,
dup
, etc.) are eliminated when Securify
decompiles the EVM bytecode to its stackless representation. The
relevant instructions are:
–
Arithmetic operations and comparisons: e.g.,
add
,
mul
,
lt
,
eq
.
In the rest of the paper, we write
op
to denote any of these
operations.
– Cryptographic hash functions: e.g., sha3.
–
Environmental information: e.g.,
balance
returns the balance
of a contract,
caller
is the identity of the transaction sender,
callvalue
is the amount of ether specied to be transferred
by the transaction.
– Block information: e.g., number, timestamp, gaslimit.
–
Memory and storage operations:
mload
,
mstore
,
sstore
,
sload
load/store data from the memory/contract storage.
–
System operations: e.g.,
call
, which transfers ether, and takes
two arguments: receiver address and amount of ether to
transfer (in fact,
call
takes seven arguments; we consider
here only those that are relevant for the rest of the paper).
–
Control-ow instructions: e.g.,
goto
, which encodes condi-
tional jumps across instructions.
For the complete set of instructions, along with their formal
description, we refer the reader to [52].
4.1.2 Stratified Datalog. Stratied Datalog is a declarative logic
language, which enables to write facts (predicates) and rules to infer
facts. We next briey overview its syntax and semantics.
Syntax.
We present Datalog’s syntax in Fig. 6. A Datalog program
consists of one or more rules, denoted
r
. A rule
r
consists of a
head
a
, and a body,
l
, consisting of literals, separated by commas.
The head, also called an atom, is a predicate over zero or more
terms, denoted
t
, comma-separated. A literal
l
is a predicate or its
negation. As a convention, we write Datalog variables in upper case
and constants in lower case. A Datalog program is well-formed if
5
