=Paper= {{Paper |id=Vol-2215/paper12 |storemode=property |title=From the Blockchain to Logic Programming and Back: Research Perspectives |pdfUrl=https://ceur-ws.org/Vol-2215/paper_12.pdf |volume=Vol-2215 |authors=Giovanni Ciatto,Roberta Calegari,Stefano Mariani,Enrico Denti,Andrea Omicini |dblpUrl=https://dblp.org/rec/conf/woa/CiattoC0DO18 }} ==From the Blockchain to Logic Programming and Back: Research Perspectives == https://ceur-ws.org/Vol-2215/paper_12.pdf

From the Blockchain to Logic Programming
and Back: Research Perspectives
Giovanni Ciatto∗ , Roberta Calegari∗ , Stefano Mariani† , Enrico Denti∗ , Andrea Omicini∗
∗ Department of Computer Science and Engineering (DISI)

A LMA M ATER S TUDIORUM–Università di Bologna, Italy
Email: roberta.calegari@unibo.it, giovanni.ciatto@unibo.it, enrico.denti@unibo.it, andrea.omicini@unibo.it
† Department of Sciences and Methods for Engineering (DISMI)

Università degli Studi di Modena e Reggio Emilia, Italy
Email: stefano.mariani@unimore.it

Abstract—The blockchain is a novel approach to support We suggest that the choice of OOP may have hindered the
distributed systems enabling a common, consistent view of a full realisation of the expectations related to third generation
shared state among distributed nodes. There, smart contracts BCTs. In fact, smart contracts were originally conceived as
are computer programs that allow users to deploy arbitrary
computations, in charge of automatically regulate state transi- a means to automatically enforce the conditions defined in a
tions and enforce properties. In this paper we speculate on how contract, and to guarantee invariants and properties despite
the blockchain and smart contracts could take advantage of a the ever-changing state of the blockchain [8], [9], [10].3 Not
logic programming approach, and, complementarily, on how logic exactly what OOP is best for.
programming can benefit from the blockchain infrastructure. So, there seems to be a mismatch between the computational
Accordingly, we discuss some possible research directions and
open questions for future research. model chosen for Ethereum’s smart contracts and the one ac-
Index Terms—blockchain, logic programming, smart contracts. tually fitting their original requirements and intended purpose.
Among the many programming languages and computational
models available – as Solidity4 for Ethereum, Go for the Hy-
I. I NTRODUCTION perledger Fabric5 , or Java for Corda6 – a declarative language
The blockchain technology (BCT henceforth) gained atten- backed by a logic programming computational model could
tion as the backbone of cryptocurrencies such as Bitcoin [1]. be best suited for both (i) expressing high level policies in
Yet, its capabilities extend far beyond that, enabling on the one an unambiguous and human-readable way, and (ii) supporting
hand existing applications to be improved – such as the Do- inference and sound demonstration of properties of interest.
main Name System 1 , identity or copyright management [2] –, In turn, as a distributed ledger technology, the blockchain
on the other hand novel ones to be conceived and deployed— could bring to distributed logic programming more than a
such as DAOs [3] or crytocurrencies [4] themselves. A lot of few desirable features, such as consistency, accountability, and
expectations lie around such a novel approach to distributed fault tolerance.
systems [2], mostly concerning the way financial transactions, Accordingly, in this paper we identify the research opportu-
identity management, or asset property tracking are performed. nities arising from re-interpreting the blockchain from a logic-
A popular categorisation of blockchain models orders them based perspective: on the one hand, how logic programming
in three generations [5]: the first limited to cryptocurrencies, can improve the capabilities of the blockchain and, especially,
the second generalising to any sort of asset tracking, and the of smart contracts; on the other hand, how logic programming
third introducing smart contracts [6]. Smart contracts are com- may benefit from the blockchain, either as a distributed com-
puter programs deployed “on the blockchain”, meant to reify puting model or as an infrastructure.
agreements between mutually distrusting participants automat- The reminder of the paper is therefore organised as follows:
ically enforced by the blockchain consensus mechanism— Section II provides an overview about the main elements of
without resorting to a trusted centralised authority. BCTs and the smart contract abstraction, Section III introduces
The implementation of smart contracts offered by nowadays our vision of logic-based smart contracts, describing how
BCT constrains users to express their business logic by means logic programming would provide some useful properties, in
of object-oriented programming (OOP) abstractions and an Section IV we discuss how the BCT introduces novel ways to
imperative programming style—both strictly bound to the face well-known issues of the distributed logic programming
underlying BCT. In the following we take Ethereum2 as research area, and, finally, Section V concludes the paper.
our reference as the most well-known framework for smart 3 As detailed in the next section despite the similar name, our notion of
contracts currently available [7]. logic-based smart contracts differs from the one proposed in [8].
4 http://solidity.readthedocs.io
1 http://www.namecoin.org/ 5 http://www.hyperledger.org/projects/fabric
2 http://www.ethereum.org 6 http://www.corda.net/

69
II. B LOCKCHAIN AND S MART C ONTRACTS : OVERVIEW and therefore the resulting state is valid from that moment on.
The blockchain is essentially a means for distributed nodes Blocks implement the timestamping schema described in [16],
to consistently perceive a common shared state of the system: providing untamperability of the history about the past.
essentially, it provides a novel way to address the problem In fact, locks are replicated on all the nodes thanks to the
of state machine replication [11], focusing on making some blockchain protocol, which is in charge of ensuring that the
distributed processes expose the very same dynamics, given last block – containing the most recent transactions – is the
that they share the same program and initial state. As such, same for each node.
the blockchain provides a way to solve (or, at least, mitigate) D. Consensus
some well known problems of distributed systems, such as
the CAP [12] and FLP [13] theorems, the Sybil attack [14], The distributed consensus protocol makes sure that the
Lamport’s Byzantine Generals Problem [15]. distributed nodes – the miners – achieve a common view of
The key point is that the blockchain endows applications the sequence of blocks, and, consequently, of the ordering
with highly desirable properties such as immutability and of transactions: in short, its task is to guarantee consistency
untamperability of the past, consistency among nodes of the in spite of system state replication. While several consensus
system state, fault tolerance of both data and computations. mechanisms exist, their detail is outside the scope of this
In the following, we describe the elements actually enabling paper: we forward the interested reader to [11].
these features, which are: For what concerns the following discussion it is sufficient
to understand that BCTs supporting cryptocurrencies (such as
• the system (or world) state
Ethereum) usually employ the Proof-of-Work consensus ap-
• the transactions describing state transitions
proach, which (i) endows the cryptocurrency with its econom-
• the blocks forming an ordered ledger containing all the
ical value, (ii) provides probabilistic and eventual consistency
events that occurred within the system
of the system state, and (iii) makes the blockchain resistant
• the consensus mechanism (or protocol)
against Byzantine nodes and Sybil attacks.
• smart contracts (3rd generation blockchain only)

A. States E. Smart contracts
States represent what is true for the system at a given instant Smart contracts consist of stateful processes that can react to
in time. All nodes composing the system must eventually the publication of a particular kind of transaction: invocation
perceive the same system state. Generally speaking, it is a transactions. For an invocation transaction to be valid, the trig-
mapping between the entities’ identifiers – i.e. users – and gered computation must terminate without errors: otherwise,
some arbitrary data associated to and controlled by that entity, its effects are reverted, leaving the system state unaltered.
there including smart contracts data and code, or user balances. Smart contracts can be conceived (and usually are) as
objects in the OOP sense, thus their invocations as method
B. Transactions calls. Nevertheless, deployment is quite peculiar: their pro-
Transactions encode the state variations yet to be performed. grams are written and published by end users by means of
A transaction can apply to a state producing a new state. Nodes deployment transactions, publishing the compiled source code
may issue (publish) transactions in order to produce an effect (or, bytecode) of a smart contract. In Ethereum, smart contracts
on the system state. Transactions may represent money transfer are usually programmed with Solidity, which is indeed an
from an entity to another, the deployment of a smart contract, object-oriented language. The Solidity code is compiled into
or the invocation of an already-deployed smart contract. the Ethereum Virtual Machine (EVM) bytecode before deploy-
When a transaction is published, it is replicated over the ment and the latter is deployed on the blockchain network.
whole system, thus making every node aware of it. However, Thanks to transaction signatures and blocks hash links, the
a transaction can be applied only if it is valid, that is, code of smart contracts is immutable after publication. This
well formed and correctly signed by the issuer. Otherwise, is what makes them amenable of trust in, e.g., handling
it is simply dropped, thus preventing unauthorised actions to financial transactions: indeed, since the source code is publicly
carry on. Furthermore, to produce an effect on the system inspectable and immutable, anyone can check the bytecode
state, transactions must be executed without errors, otherwise obtained (i.e. via a disassembler).
their modifications to the system are simply reverted. As an
F. Miners
example, suppose an entity is trying to transfer more money
than it currently owns, by means of a transaction. Such a Miners are the peer nodes composing the backbone of
transaction would eventually throw an error provoking the the blockchain network by participating into the consensus
money transfer and any other side effect to be reverted. mechanism. They locally store a copy of the whole blockchain
– there included a copy of each smart contract – and execute
C. Blocks all transactions. Since the system state must be kept consistent
Blocks are timestamped lists of transactions. As such, they among all the miners, each of them locally executes smart con-
certify (i) the ordering of edits applied to the system state, and tracts upon reception of invocation transactions. Therefore, the
(ii) that each transaction occurred at a specific instant in time, execution of non-terminating computations must be prevented,

70
since it would imply a deadlock of the whole blockchain • the system state maps smart contract identifiers into some
network. The most notable solution is the one introduced data structure, including at least a balance to enable
by the Ethereum platform, where each computational step smart contracts to handle money, a static KB made of
is paid by the initiator of the transaction in terms of gas— an immutable list of logic facts and rules, to be set upon
converted from the initiator balance. Executions running out deployment, and an initially empty dynamic KB which
of gas invalidate their invoking transactions but still consume may be modified via assert/1 and retract/1
the initiator’s money. • money transfer transactions retain their semantics,
These money can be redeemed by the first miner producing whereas smart contract invocations become goal-oriented
the next block of the blockchain, as a compensation for the computations as described in the following
computational effort. So, long/infinite computations become • blocks and consensus retain their semantics
economically unsustainable. This mechanism highlights the
aspect of the economical cost model of computations, which As a second step, we need to define the behaviour of logic
is currently instruction-based [17]. based smart contracts, that is, how they react to transactions.
III. L OGIC P ROGRAMMING FOR S MART C ONTRACTS While money transfer transactions retain their semantics, in-
vocation transactions can be supposed to specify a logic term,
We now introduce the idea of logic-based smart contracts as
say Message, that triggers a goal-oriented computation Goal
an intriguing research perspective, highlighting its challenges
if the KB of the invoked smart contract contains a rule such
and possible benefits. It is worth remarking that we do not
as receive(+Message, +Guard):- Goal. provided
mean to produce “yet another compiler” for a logic language
that Guard is true. If no such a rule is found, the transaction
to EVM, but to replace the EVM itself with a logic engine
is considered invalid and it produces no effect.
and related computational model, so that smart contracts can
be expressed in a logic language—e.g., Prolog. The computation (Goal) is performed according to the
usual SLD resolution process [19]: the side effects (assertion
A. Motivations
or retraction of terms) possibly performed affect only the dy-
We see three major motivations for doing so: (i) the declara- namic KB of the smart contract. However, for the transaction
tive nature of the source code, (ii) observability of the business to be considered valid and, consequently, its side effects to
logic, and (iii) controlled mutability of behaviour. be persisted on the blockchain, the resolution process should
Adoption of a declarative language with a goal-oriented terminate producing a proof for Goal: this is persisted along
semantics could ease both developers’ work and readers’ with the invocation transaction. The issuer of the transaction
understanding in general: the former would be able to ex- (or possibly any other interested party) may later inspect its
plicitly state the business goals the smart contracts should local copy of the blockchain seeking for such a proof, if
pursue – which could in turn be able to share them or interested. In essence, the possibly many receive/2 rules
reason about how to reach them –, while for the latter would are the only access point to the smart contract code – i.e., its
be easier to understand the functioning of already-deployed API –, while other clauses are considered an implementation
smart contracts. Furthermore, since Prolog is an interpreted detail of the smart contract and cannot be accessed by users.
language, it could also help strengthening trust via improved Such a mechanism would let the programmers be free to allow
inspectability: in fact the source code may be deployed with no (or deny) the injection of some new behaviour into the smart
need of compilation, and it would not require any disassembler contract by means of, e.g., the assertion of some new rule.
for being inspected later on. This is ultimately what we mean by “controlled mutability”.
By endowing logic-based smart contracts with a static
knowledge base (KB) containing immutable rules and terms, The third step should focus on inter-smart contract inter-
alongside a dynamic KB containing the mutable ones, smart action. As the reader may expect, a send(+Recipient,
contracts could be structured in such a way to partially modify ?Message, ?Money) primitive has been conceived too,
their behaviour in a controllable way. A practical example which can be used by a smart contract to send a Message to
of such an interesting feature is extensively described in another one (namely Recipient), possibly including some
Subsection III-C. This helps mitigating the problems caused by Money, therefore triggering one of its receive(Message,
buggy smart contracts that are deployed and, being immutable, Guard) entry points. An interesting aspect which may be
cannot be fixed—anyway, a practice considered harmful [18]. worth of further investigation is whether the send/2 primitive
Again, the fact that both the static and dynamic KBs can be should have a synchronous or an asynchronous communication
easily inspected would be an added value, possibly paving semantics. In the first case, the inter-smart contracts interaction
the way towards cryptographically secured, while human- semantics would redeem their OOP-like nature, along with its
readable, contracts. well known re-entrancy issues [20], [21]. We speculate that
the second case may mitigate the aforementioned issues and
B. A possible roadmap open new opportunities related to the engineering of smart
As a first step towards our vision we need to re-interpret contracts interaction patterns, but further research is needed to
the blockchain elements summarised in Section II according prove this claim. To complete the picture, some convenience
to a logic-based perspective. To this end, let us suppose that predicates could be built-in into all static KBs, mimicking

71
Solidity’s “Globally Available Variables”7 like: 3) cancelling a reservation while getting a refund, possibly
• now(?Time) may enable a smart contract to inspect the with a fee if cancellation occurs later than 3 days before
current time, or activate a given prove rule if the current expected departure:

time is after/before a given instant receive(cancel(Id), (sender(Customer), reservation(
• sender(?EntityID) may enable a smart contract to Customer, flight(Id, ExpDeparture, _, _, Price)))
) :-
inspect the identity of the issuers of the transaction now(CurrentTime),
• value(?Money) may enable a smart contract to know retract(reservation(Customer, flight(Id, _, _, _, _)
)),
how much money it received along with the last message compute_refund(CurrentTime, ExpDeparture, Price,
Such predicates essentially provide context awareness in the Money),
send(Customer, _, Money).
sense that they allow the smart contract to reason and act
taking into account the informations contained (i) within the
where computation of the amount to refund is encapsu-
lastly received transaction – such as the sender identity –,
lated by the compute_refund/4 predicate, assumed
(ii) within the lastly published block—e.g., the last commonly
to be in the dynamic KB of the smart contract:
accepted global time, etc. Examples showcasing the utility of
these predicates are described in Subsection III-C. compute_refund(CancellationTime, DepartureTime, Price,
Price) :-
The semantics of blocks and of the consensus algorithm DepartureTime - CancellationTime > days(3).
remain unchanged: this implies no interference while a reso-
compute_refund(CancellationTime, DepartureTime, Price,
lution process is being executed, since transactions are totally ToBeRefunded) :-
ordered and sequentially executed. The miners’ role, too, DepartureTime - CancellationTime =< days(3),
ToBeRefunded is Price / 2.
remains unchanged: simply, in this vision they are in charge
of the SLD resolution process. However, removing the EVM
4) automatically getting a refund in case of delays longer
bytecode from the picture opens up the possibility of defining
than some given amount of time:
a more coarse-grained computation cost model, taking into
account the specific features of the logic-based computational receive(landing(flight(Id, ExpDeparture, Dur, _),
ActualTime), true) :-
model—with the usual aim of discouraging long computations. setof(
For instance, should users pay for the proofs to their queries? refund(Customer, Price),
(reservation(Customer, flight(Id, ExpDeparture,
Should they pay for unification of clauses and facts? What Dur, _, _, Price)), too_late(ExpDeparture, Dur,
about paying for backtracking? These questions have no trivial ActualTime)),
CustomersToBeRefunded
answer at the moment, thus deserve further research. ),
refund_all(CustomersToBeRefunded).
C. Case study
As an illustrative example, consider a scenario where the where refund_all/1 is a simple broadcast:
flight company ACME Inc. exploits smart contracts for regu-
refund_all([]).
lating costumer management. The company handles purchase refund_all([refund(Customer, Price) | Rs]) :-
of tickets through its ACMEPortal smart contract, which send(Customer, _, Price),
refund_all(Rs).
provides a number of functionalities, among which:
1) looking up for flights towards a given destination (To) To support functionality §4, airports are assumed to deploy
within a given timespan (Day): a AirportNotification contract in charge of notifying

receive(look_up(Day, From, To), (now(Now), after(Day, ACMEPortal about the actual departure and landing times,
Now))) :-
setof(
by sending messages in the form:
flight(Id, Time, Duration, From, To, Price),
(flight(Id, Time, Duration, From, To, Price), departure(flight(Id, ExpDeparture, Duration, FromAirport),
within(Time, Day)), ActualDepatureTime)
Flights
), landing(flight(Id, ExpDeparture, Duration, ToAirport),
sender(Customer), ActualLandingTime)
send(Customer, Flights, _).

Functionality §1 collects all flights information matching a
where within(+TimeSpan, ?Instant) simply custom filter. For instance, users may ask for all the flights
checks whether Instant is within TimeSpan. departing from a given place on a given day by providing an
2) reserving a seat paying the corresponding Price: unbounded To variable as input. The operation also shows

receive(reserve(Id), (flight(Id, Time, Dur, From, To, how contextual predicates may be useful to implement user-
Price), value(X), X >= Price)) :- and time-aware operations.
sender(Customer),
assert(reservation(Customer, flight(Id, Time, Dur, Functionality §2 shows how to add new data to the dynamic
From, To, Price))). KB of the smart contract. Notice that, since functionailities are

wrapped within the receive/2 primitive, no entity except
7 http://solidity.readthedocs.io/en/latest/units-and-global-variables.html the smart contract itself can add (or remove) information to its

72
KB. This is how encapsulation of smart contracts KBs, i.e., over the blockchain: the blockchain system is so re-interpreted
their states, can be achieved. as an inference engine coordinating a number of processors –
Functionality §3 shows the dual operation, namely, how to the miners – aimed at (i) handling users’ assert, retract, and
remove data, while illustrating what we mean by controlled solve requests, or (ii) carrying on goal proving processes by
mutability. Suppose ACME Inc. wants to adopt a different concurrently exploring different paths of some goal’s proof
policy for cancellations. Assuming the smart contracts exposes tree. We therefore imagine transactions as:
one more functionality: • information creation/consumption, in the form
of logic clauses, to the distributed ledger—e.g.,
receive(compute_refund(C, D, P, T) :- NewPolicy), (sender(S assert(?Clause)/retract(?Clause)
), authorised(S))) :-
retract_all(compute_refund(_, _, _, _) :- _), • inference invocation aimed at triggering a resolution
assert(compute_refund(C, D, P, T) :- NewPolicy). process on a given goal—e.g., solve(?Goal)

At the same time, miners are re-interpreted as the entities in
then it would be easy for the IT department to dynamically charge for repeatedly performing partial explorations of the
inject the novel policy as a replacement of the previous one. proof tree or producing solutions for provable sub-goals. By
In Ethereum, for instance, such a flexibility is not possible keeping track of already proved (sub-)goals too – on the ledger
without carefully engineering some cumber-stone interaction – miners can avoid wasting their computational resources
pattern between two or more smart contracts. proving what has been proved by others.
Finally, functionality §4 illustrates how to compose smart Finally, economical incentives could be designed and tuned
contracts declaratively to give a refund to customers in case to stimulate a particular joint exploration strategy of the proof
of delayed flights, automatically. This is an example of inter- tree. For instance, the blockchain protocol may initially reward
smart contracts interaction through the send and receive the most miners exploring novel branches of the proof tree or
primitives involving more than two smart contracts. finding solutions for unproven (sub-)goals, but, after that, it
may also start encouraging miners to keep exploring the same
IV. T HE B LOCKCHAIN FOR L OGIC P ROGRAMMING
path of the proof tree, in order to minimise the probability of
We now switch perspective w.r.t. previous section, that is, two ones competing to prove the same (sub-)goal.
we explore the idea of exploiting the blockchain technol- Although our vision appears to be feasible in practice, fur-
ogy to face some well-known issues of logic programming ther research is needed when facing the theoretical foundations
in distributed systems—namely, consistency of a distributed, of cooperative reasoning on top of a blockchain. In particular,
possibly dynamic logic theory which evolves over time, and the lesson learned from concurrent logic languages such as
concurrent reasoning. The blockchain may support for instance Concurrent Prolog [23] and Parlog [26] may provide important
cooperative exploration of the proof tree for a given goal, and useful insights: e.g., how shared variables may be handled
while smart contracts may be the key for letting different, along with AND-parallelism, or how to prevent concurrent
para-consistent theories coexist within the same system. As updates to the shared logic theory. Also, the termination of
a first intuition, the blockchain can act as the mediator recursive resolution processes too may be a critical aspect,
giving distributed access to the logical theory representing the since non-termination may imply live-locks between miners.
knowledge to share. As a future work, we plan to study whether the above issues
In the following we discuss two distinct scenarios: in can be mitigated through economic (dis)incentives—similarly
the first, the ledger is re-interpreted as a single distributed to what cryptocurrencies essentially do.
logic theory where nodes may participate to the resolution
process, while in the second, smart contracts are conceived as B. Multiple theories
containers of immutable logic theories. All the above blockchain benefits in guaranteeing properties
like consistency can be re-thought in a multiple theories sce-
A. Single theory nario, where consistency is referred to the local situation, for
Several approaches for distributing logic programming have instance. There, diverse logical theories are scattered around,
been historically explored, in particular towards implicit par- representing the local knowledge of each node situated in
allel evaluation, leading to explore AND-parallelism and OR- space and time [27], [28]. Even if the initial knowledge is the
parallelism [22], [23], [24]. The most relevant results [25] same, the KB is then likely to evolve over time in different
perform well but are not meant to face distributed program- ways, due to space-time situatedness (i.e. the temperature of
ming. Yet, implicit parallelism lacks two important control a room). There, each theory is consistent with its local reality
mechanisms—synchronisation of logic processes, and control while not in contrast with other theories representing truth in
over the non-determinism of schedulers. a different locality—resembling paraconsistent logics [29].
The blockchain model and technology could open up new In this context, each theory would be associated to a group
perspectives in the distribution and parallelisation of the reso- of local agents, and possibly merged with other computations
lution process with respect to a single theory shared between in the system only once the result is computed: there the
different participants of the distributed system. In this vision, blockchain technology could help in integrating data, and
a first intriguing possibility is to distribute the goal to solve guaranteeing properties like local consistency.

73
Indeed, smart contracts could play a key role to guaran- [13] M. J. Fischer, N. A. Lynch, and M. S. Paterson, “Impossibility
tee the consistency (or other relevant properties) of a logic of distributed consensus with one faulty process,” Journal of the
ACM, vol. 32, no. 2, pp. 374–382, 1985. [Online]. Available:
theory replicated on the subset of network nodes in a “logic http://portal.acm.org/citation.cfm?id=214121
neighbourhood”: in fact, a smart contract running every time a [14] J. R. Douceur, “The Sybil attack,” in IPTPS ’01 Revised Papers from
change to the theory is proposed could help deciding whether the First International Workshop on Peer-to-Peer Systems. Springer,
2002, pp. 251–260. [Online]. Available: http://dl.acm.org/citation.cfm?
the change should be accepted or not. There, the smart id=687813
contract could also manage assert/retract on the knowledge [15] L. Lamport, R. Shostak, and M. Pease, “The Byzantine Generals
base, ensuring the (eventual?) consistency of the shared theory. problem,” ACM Transactions on Programming Languages and
Systems, vol. 4, no. 3, pp. 382–401, Jul. 1982. [Online]. Available:
Other examples of properties that could be enforced by such http://dl.acm.org/citation.cfm?id=357176
a mechanism are invariants and computational properties like [16] S. Haber and W. Stornetta, “How to time-stamp a digital document,”
stratification [30]. Journal of Cryptology, vol. 3, no. 2, pp. 99–111, 1991. [Online].
Available: http://link.springer.com/10.1007/BF00196791
[17] G. Wood, “Ethereum: a secure decentralised generalised transaction
V. C ONCLUSION ledger,” Ethereum Project, Yellow Paper 151, 2014. [Online]. Available:
On the one hand, the blockchain could benefit from logic http://ethereum.github.io/yellowpaper/paper.pdf
[18] Q. Dupont, “Experiments in algorithmic governance. a history
programming to obtain system properties like observability, and ethnography of “the dao,” a failed decentralized autonomous
explainability, and evolvability. On the other hand, blockchain organization,” in Bitcoin and Beyond. Cryptocurrencies, Blockchains,
and smart contracts look as promising technologies to exploit and Global Governance, 1st ed. London, UK: Routledge, Nov.
2017, ch. 8. [Online]. Available: https://www.taylorfrancis.com/books/
the full potential of distributed LP. Accordingly, this paper e/9781351814089/chapters/10.4324%2F9781315211909-8
elaborates on how blockchain and smart contracts could mix [19] J. A. Robinson, “A machine-oriented logic based on the resolution
with logic programming, and foresees a number of lines of principle,” Journal of the ACM, vol. 12, no. 1, pp. 23–41, Jan. 1965.
[Online]. Available: http://dl.acm.org/citation.cfm?id=321253
future research on the subject. [20] L. Luu, D.-H. Chu, H. Olickel, P. Saxena, and A. Hobor, “Making smart
contracts smarter,” in 2016 ACM SIGSAC Conference on Computer and
R EFERENCES Communications Security (CCS’16). ACM Press, 2016, pp. 254–269.
[1] S. Nakamoto, “Bitcoin: A peer-to-peer electronic cash system,” 2008. [Online]. Available: http://dl.acm.org/citation.cfm?id=2978309
[Online]. Available: http://bitcoin.org/bitcoin.pdf [21] N. Atzei, M. Bartoletti, and T. Cimoli, “A survey of attacks on
[2] S. X. Zibin Zheng, “Blockchain challenges and opportunities: A survey,” Ethereum smart contracts (SoK),” in Principles of Security and Trust,
International Journal of Web and Grid Services, In press. ser. LNCS. Springer, Jul. 2017, vol. 10204, pp. 164–186. [Online].
[3] U. Chohan, “The decentralized autonomous organization and governance Available: http://link.springer.com/10.1007/978-3-662-54455-6 8
issues,” SSRN Electronic Journal, Dec. 2017. [Online]. Available: [22] L. Monteiro, “A proposal for distributed programming in logic,” in
http://ssrn.com/abstract=3082055 Implementations of Prolog, ser. Artificial Intelligence. Chicester, UK:
[4] I. Bashir, Mastering Blockchain – Distributed ledgers, decentralization Ellis Horwood Limited, 1984, pp. 329–340.
and smart contracts explained. Packt Publishing, 2017. [23] E. Y. Shapiro, Concurrent Prolog – Vol. 1: Collected Papers, ser. Logic
[5] M. Swan, Blockchain: Blueprint for a New Economy. O’Reilly, 2015. Programming. Cambridge, MA, USA: The MIT Press, 1987.
[Online]. Available: http://shop.oreilly.com/product/0636920037040.do [24] K. L. Clark and S. Gregory, “A relational language for parallel
[6] N. Szabo, “Formalizing and securing relationships on public networks,” programming,” in 1981 Conference on Functional Programming
First Monday, vol. 2, no. 9, Sep. 1997. [Online]. Available: Languages and Computer Architecture (FPCA ’81). New York,
http://journals.uic.edu/ojs/index.php/fm/article/view/548 NY, USA: ACM, 1981, pp. 171–178. [Online]. Available: http:
[7] S. Omohundro, “Cryptocurrencies, smart contracts, and artificial //dl.acm.org/citation.cfm?id=806776
intelligence,” AI Matters, vol. 1, no. 2, pp. 19–21, Dec. 2014. [Online]. [25] A. Brogi and R. Gorrieri, “A distributed, net oriented semantics for
Available: http://dl.acm.org/citation.cfm?id=2685334 Delta Prolog,” in TAPSOFT ’89: Proceedings of the International
[8] F. Idelberger, G. Governatori, R. Riveret, and G. Sartor, “Evaluation Joint Conference on Theory and Practice of Software Development
of logic-based smart contracts for blockchain systems,” in Rule Barcelona, Spain, March 13–17, 1989, ser. LNCS. Springer, 1989,
Technologies. Research, Tools, and Applications, ser. LNCS, vol. vol. 351, pp. 162–177. [Online]. Available: http://link.springer.com/10.
9718. Springer, 2016, pp. 167–183. [Online]. Available: http: 1007/3-540-50939-9 131
//link.springer.com/10.1007/978-3-319-42019-6 11 [26] K. L. Clark, “PARLOG: The language and its applications,” in
[9] K. Bhargavan, A. Delignat-Lavaud, C. Fournet, A. Gollamudi, PARLE Parallel Architectures and Languages Europe. Volume II:
G. Gonthier, N. Kobeissi, N. Kulatova, A. Rastogi, T. Sibut-Pinote, Parallel Languages. Eindhoven, The Netherlands, 15–19 Jun. 1987.
N. Swamy, and S. Zanella-Béguelin, “Formal verification of smart Proceedings, ser. LNCS. Springer, 1987, vol. 259, pp. 30–53. [Online].
contracts: Short paper,” in 2016 ACM Workshop on Programming Available: http://link.springer.com/10.1007/3-540-17945-3 2
Languages and Analysis for Security (PLAS ’16). ACM, 2016, pp. [27] R. Calegari, E. Denti, S. Mariani, and A. Omicini, “Logic program-
91–96. [Online]. Available: http://dl.acm.org/citation.cfm?id=2993611 ming as a service in multi-agent systems for the Internet of Things,”
[10] M. P. Andersen, J. Kolb, K. Chen, G. Fierro, D. E. Culler, and International Journal of Grid and Utility Computing, In press.
R. A. Popa, “WAVE: A decentralized authorization system for [28] ——, “Logic Programming as a Service (LPaaS): Intelligence for the
IoT via blockchain smart contracts,” EECS Department, University IoT,” in 2017 IEEE 14th International Conference on Networking,
of California, Berkeley, Technical Report UCB/EECS-2017-234, Sensing and Control (ICNSC 2017). IEEE, May 2017, pp. 72–77.
Dec. 2017. [Online]. Available: http://www2.eecs.berkeley.edu/Pubs/ [Online]. Available: http://ieeexplore.ieee.org/document/8000070/
TechRpts/2017/EECS-2017-234.html [29] H. A. Blair and V. S. Subrahmanian, “Paraconsistent logic
[11] C. Cachin and M. Vukolić, “Blockchain consensus protocols in the programming,” Theoretical Computer Science, vol. 68, no. 2, pp.
wild (keynote talk),” in 31st International Symposium on Distributed 135–154, 1989. [Online]. Available: http://www.sciencedirect.com/
Computing (DISC 2017), ser. Leibniz International Proceedings in science/article/pii/0304397589901266
Informatics (LIPIcs), vol. 91. Dagstuhl, Germany: Schloss Dagstuhl– [30] P. Glasserman, P. Heidelberger, and P. Shahabuddin, “Gaussian
Leibniz-Zentrum fuer Informatik, 2017, pp. 1:1–1:16. [Online]. importance sampling and stratification: Computational issues,” in 1998
Available: http://drops.dagstuhl.de/opus/volltexte/2017/8016 Winter Simulation Conference, vol. 1. IEEE, Dec. 1998, pp. 685–693.
[12] S. Gilbert and N. Lynch, “Brewer’s conjecture and the feasibility [Online]. Available: http://ieeexplore.ieee.org/document/745051/
of consistent, available, partition-tolerant web services,” SIGACT
News, vol. 33, no. 2, pp. 51–59, Jun. 2002. [Online]. Available:
http://dl.acm.org/citation.cfm?id=564601