Content uploaded by Ilya Afanasyev
Author content
All content in this area was uploaded by Ilya Afanasyev on Oct 01, 2018
Content may be subject to copyright.
Content uploaded by Ilya Afanasyev
Author content
All content in this area was uploaded by Ilya Afanasyev on Sep 22, 2018
Content may be subject to copyright.
Towards Blockchain-Based Robonomics:
Autonomous Agents Behavior Validation
Konstantin Danilov
Innopolis University
Innopolis, Russia
k.danilov@innopolis.ru
Ruslan Rezin
Innopolis University
Innopolis, Russia
r.rezin@innopolis.ru
Ilya Afanasyev
Innopolis University
Innopolis, Russia
i.afanasyev@innopolis.ru
Alexander Kolotov
Innopolis University
Innopolis, Russia
a.kolotov@innopolis.ru
Abstract—The decentralized trading market approach, where
both autonomous agents and people can consume and produce
services expanding own opportunities to reach goals, looks very
promising as a part of the Fourth Industrial revolution. The
key component of the approach is a blockchain platform that
allows an interaction between agents via liability smart contracts.
Reliability of a service provider is usually determined by a
reputation model. However, this solution only warns future
customers about an extent of trust to the service provider
in case it could not execute any previous liabilities correctly.
From the other hand a blockchain consensus protocol can
additionally include a validation procedure that detects incorrect
liability executions in order to suspend payment transactions to
questionable service providers. The paper presents the validation
methodology of a liability execution for agent-based service
providers in a decentralized trading market, using the Model
Checking method based on the mathematical model of finite
state automata and Temporal Logic properties of interest. To
demonstrate this concept, we implemented the methodology in
the Duckietown application, moving an autonomous mobile robot
to achieve a mission goal with the following behavior validation
at the end of a completed scenario.
Keywords-—multi-agent system, smart contract, Ethereum
blockchain, model checking, validation, Duckietown, ROS, AIRA
robot economy, robonomics
I. INTRODUCTION
During the last decade, autonomous agents have become
more intelligent and efficient in terms of the speed and the
accuracy, demonstrating an impressive performance of various
specific tasks and successful collaboration with each other,
reaching own independent goals. This brings up the concept
of the decentralized trading market where autonomous agents
can consume and produce services with respect to a common
protocol. Since appearance of the blockchain technology, in
particular implementation of Bitcoin [1], which solved the
double-spending attack problem, the decentralized multi-agent
system concept gets started to be viable as far as the agents
do not rely on a single point of failure and their operations
are transparent for monitoring. Although the blockchain was
originally introduced as the cryptocurrency solution, its idea
inspired the developers of the Ethereum platform [2] to suggest
a new concept: smart contract - an algorithmic enforcement
of agreements. Very soon it became the biggest platform for
decentralized applications that gave new pulse to development
of such market services as selling computer’s processing power
and decentralized computation storages [3]. Another example
of a blockchain-based platform is the decentralized network of
autonomous agents IOTA [4] that is oriented to the IoT (Inter-
net of Things) market. The paper [5] proposes the mechanisms
of charging and billing services for Electric Autonomous
Vehicles (EAVs) without involving humans via the use of
Distributed Ledger Technology (DLT) establishing Machine-
to-Machine (M2M) economy with IOTA Tangle transactions.
In spite of the fact that discussed projects become popular,
they are concentrated on specific types of autonomous agents
severely limiting available services. The AIRA project firstly
introduced the concept of the decentralized trading market
where both autonomous agents and people can consume and
provide services. The authors defined the concept as ”robot
economics” (robonomics) [6]. This AIRA approach suggests
rejecting the principle of centralized robot control to provide
decentralized communication between robots and humans,
using blockchain-based smart contracts as a basis of these
communications [7]. Since liabilities depend on real world
processes there is no guarantee that agents will always execute
them correctly. It can be caused by a service provider due to
(1) an intentional fraud or (2) an incorrect behavior because of
malfunctions. For the first problem AIRA developers suppose
that a reputation model can be developed and integrated
into the consensus protocol that will reflect in blockchain
information about the extent of trust to the agent. Thus,
consumers can further rely on this information for selection
of a service provider. For the second problem AIRA project
still requires both technical and theoretical solutions, which
are the focus of the current paper.
In this work we concentrate our attention on the agents
whose behavior can be described by a nondeterministic finite
state automata [8] (further called as agent-based systems). For
these agents we present the novel validation methodology of
liability execution that allows detecting malfunctioned agents.
It works with the assumption that a malfunctioned service
provider produces a result that contradicts its behavioral model
and leads to automatic suspension of purchase. The validation
approach is based on the formal software verification method,
Model Checking [9], [10]. There has been a great body
of research on model checking frameworks for distributed
multi-agent systems, including, but not limited to [11]–[16].
Since mobile robots can be used in the real life, e.g. in
logistics, transportation, etc., we provide the simple prototype
implementation using PRISM model checker [16] and the
Duckietown environment [17], where a mobile robot moves
through the town, oriented by a given tags sequence, to achieve
a mission goal with its behavior validation at the end of a
completed scenario. Our validation approach can be imple-
mented (1) into a consensus protocol directly, or (2) as a part
of a decentralized blockchain application. In the former case
it is assumed that the validation of liability execution could
be done in a decentralized form on validator nodes (miners)
and transactions, confirming that the service was provided in a
proper manner, will be included in the new block. For instance,
it could be implemented with existing solutions supporting
pluggable consensus like Parity or Hyperledger [18]. In the
latter case it is integrated into the AIRA’s approach, where
the validation is performed by a third-part application, which
commits the validation result to the Ethereum smart-contract.
The paper is organized as follows: Section II considers
related works, Section III formalizes our methodology, Section
IV describes the methodology implementation in a scenario
with a mobile robot motion in the Duckietown environment
with the blockchain-based validation of robot’s behavior. Fi-
nally, we present our results in Sections V, discuss the concept
in Section VI and conclude in Section VII.
II. RE LATE D WO RK
In this section we review model formalization and verifi-
cation works, that are helpful for understanding the proposed
solution, which is described in III.
The work [19] considers a formalization of the model as a
tuple (U,B), where Uis the universum set of all possible
outcomes and Bis a behavioral set of allowed outcomes.
The parameterization of models is studied by introducing a
canonical form and invariant notions. Although the work [19]
mostly concentrates on time invariant linear dynamical sys-
tems nevertheless applications of the approach to the discrete-
event systems (DES) are also considered. Moreover, the author
introduces the interconnection approach to study subsystems
separately from the whole system. Finally, the work demon-
strates how models can be built from the observed data through
”most powerful unfalsified models” (MPUM) approach. In the
work [20] authors provide a review for the modeling of the
multi-unmanned vehicle mission, describing the Agent-based
model, Business process model notation (BPMN), Petri Net
(PN), Hidden Markov Models (HMM), State Machine (SM)
and Tree Model (TM). The authors concluded that PN and
HMM are the most appropriate techniques for the modeling
in robotics applications. Nevertheless, as we show in Section
III, agent-based models are also interesting and promising
for multi-robot systems. Another our observation is that al-
though the paper [20] considered BPMN, it did not include
models based on Process calculus such as Communicating
Sequential Processes (CSP) [21], Calculus of Communicating
Systems (CCS) [22] and Pi-Calculus [23]. In the work [24]
an application of the Process calculus for description and
verification of a robot behavior is studied. The advantage of
using Process calculus over Model Checking technique is that
the ”state explosion problem” can be avoided however new
challenges such as checking equivalence between processes
must be considered. The authors also state that in case using
Dynamic Bayesian Network (DBN), the structural equivalence
problem can be reduced to a filtering problem in terms of
DBN.
The blockchain looks very promising as a core technology
to build a service market for autonomous robots. In the paper
[25] it is proposed to use Bitcoin to perform distributed deci-
sion making through voting mechanism, which is implemented
by using agents depositing a ”decision account”. Ethereum
project [26] has introduced more reliable consensus protocol
and smart contracts, allowing to implement more flexible
logic of an interaction between autonomous agents than in
Bitcoin due to the Turing Complete programming language.
Although the scientific community actively works on Bitcoin
improvements, which mostly addressed to disadvantages of the
blockchain technology such as scalability [27], [28]. However,
the decentralized trading market requires an approach that can
validate a liability of the autonomous agents based on one of
the representations of behavior model discussed above or new
one. This can help to expand the blockchain technology from
financial flows to proving events, which occur in real market
like a service placement or consumption.
III. METHODOLOGY
Consumption of services in a decentralized trading mar-
ket is controlled by blockchain-based smart contracts. The
technology connects a customer to a service provider without
any necessity to trust each other. Moreover, communicating
parts can be either humans or autonomous agents. Although
smart contracts are written using the Turing complete lan-
guage, computations related to the validation of the service
execution are not applicable due to high complexity and cost.
Therefore, a third member is introduced in the contract, which
is responsible for the validation. It should be noticed that in
general it is not required: for instance, if the model validation
can be integrated into the consensus mechanism.
The high-level block-scheme of an interaction between parts
via smart contract is shown in Fig. 1. At the first step, a smart
contract is created with an objective from a customer and a
corresponding behavior model from a service provider. After
that the service provider starts executing liability according to
its behavior model. Simultaneously, this provider records a log
(e.g., GPS path). In AIRA concept this log is considered as a
result. When the service is finished, the result is submitted to
the smart contract that confirms its work. Finally, a validator
must check correctness of the liability execution, based on
the behavior model and the result, and only after this step
the service provider will be paid. Usually an objective is a
specific service, therefore a service provider can supply a cus-
tomer with a guide or an interface for objective construction.
However, there is a necessity in a method that formally defines
a behavior model, a liability execution result and a validation
procedure. Due to the requirement that validators must au-
tomatically check any liabilities permitted in the market, the
validation procedure must not depend on service.
Fig. 1. General scheme of interaction between autonomous agents during
the liability lifecycle. A customer orders a service by submitting a transaction
with an objective. A service provider takes the liability to satisfy the objective
and submits the transaction with the execution result on completion. Validators
check the correctness of the liability execution.
In the current work we consider only such service providers
that execute computations based on the finite number of
states. States are defined by values of variables that are
changed as a computation progresses. In general, such services
consist of communicating devices that interact according to a
protocol and can be studied as agent-based systems. We use
the methodology of such systems defined in the work [29].
Although the authors applied this methodology to multiplayer
computer games the idea can be generalized for an arbitrary
finite state protocol. Similarly, we call agent-based system a
tuple G= (A,V,Vinit, c, OP,E V ), where Ais a set of actors;
Vis a set of vectors of attributes; Vinit is a set of possible
initial vectors of attributes; cis a tuple of parameters; OP is a
function that maps set of actions to each actor; and EV is the
evolution operator that defines rules of changes of the system.
The meaning of the definition is following: after fixed period
of time every agent must submit an action. The actions are per-
formed simultaneously changing the attributes that describe the
state of agent-based system. The ctuple is used to parametrize
actions and domain of the attributes. Such parametrization can
help to deal with ”state explosion problem” during verification
at applying formal methods such as Model Checking [9]. The
main advantage of the methodology is a representation of
agent-based system (i.e. a service provider behavior), as a
program in Model Checker language. Such representation is
referred as a model hereafter. Moreover, we contribute with
an extension of the methodology representation that allows
providing a validation of the service liability based on the
model and a result.
Model Checker is a special tool with already implemented
Model Checking algorithm that takes as input a symbolic
representation of finite state automata in a special language
(the model) and Temporal Logic [30] formula as property
of interest. In result, Model Checker answers the question
whether a property holds on the model, meaning that com-
putations providing by the model are correct in some sense.
If a model and a result are submitted to the smart contract
by a service provider, then the task of a validator is to
construct a property and to run the Model Checker. Finally,
the validator either confirms or rejects liability execution
based on Model Checking result. However, there are two
problems that must be solved. Firstly, Model Checker language
requires a representation of automaton’s states and transitions
by formulas in first-order predicate logic. For big agent-based
systems such procedure is not straightforward and error-prone
if a service developer performs it by hand. Secondly, it must
be finalized a format of liability execution result and procedure
of how the validator can generate a property of interest from
it. It was decided that it will be required from agent-based
system to submit a log of its execution as a result. The
log must reflect changes of state of the agent-based system
G= (A,V,Vinit, c, OP,E V ). It can be achieved by providing
values for all variables from Vper row. Hence each row of the
file describes a state. However, a validator still needs a tool
that can automatically generate a property from the log file.
We have developed a framework that includes instruments
to overcome both problems, which will be discussed in details
in the Section IV.
IV. IMPLEMENTATION
To demonstrate our methodology in hardware, we im-
plemented our concept in the Duckietown framework, con-
sidering the whole AIRA robot liability lifecycle: creation,
execution and validation [7]. Thus, our prototype consists
of Duckietown [17], a Duckiebot and software, which helps
a user to create a scenario assigning robots route in the
Duckietown and checking the liability execution. The liability
will be executed by the Duckiebot and verified by a validator,
using the approach, described in III. We used Duckietown
environment with a size of 3x3 meters (or 5x5 tiles in terms
of original Duckietown project), having tiles with 4 turns, 4
T-junctions, a four-way intersection and AprilTag signs [31]
at each intersection that can be seen in Fig. 2.
Since our research does not focus on Duckiebot navigation
and localization, we used a simplified robot behavior control
with tags sequence-based movement. Thus, the following
simple algorithm for Duckiebot movement was applied:
1) Set the tag sequence (e.g. 1 →left, 2 →right, 3 →
forward)
2) Start the robot movement and stand before a stop line
3) Find the rightmost tag and recognize its ID
4) Find it in the sequence. If it exists, execute an assigned
action and go to the step 2.
Fig. 2. Our experiment in Duckietown environment. The Duckiebot executes
a mission, going through ”the city” by following tags’ sequence from the
liability smart contract and recording observed tags into the log, which is
verified after end-of-mission by a validator. Video is available at https://youtu.
be/mmC8jxXWWJw
Using this algorithm, it is possible to create a full-cycle
prototype, since robot is able to perform any user sequences,
recording a log and sending it as the result.
During the prototype creation, we used some ROS (Robot
Operating System) nodes both original for Duckietown and our
own. Developed ROS nodes realize the following behavior:
1) Bot waits for new liability smart-contract by filtering
events of smart contract factory with predefined address.
2) Bot gets new liability and waits an objective to be set.
3) Bot downloads the objective description (tag sequence)
from IPFS and starts moving in accordance with this
sequence, saving all observed tags.
4) When the sequence is finished, the bot saves a result file
to IPFS and publishes its hash to the smart contract.
Several client scripts were developed in order to provide
liability creation and validation. Smart contracts were used
from the AIRA core repository [32]. Additionally one new
contract was developed - RobotLiabilityFactory, which creates
RobotLiability instances and raises the appropriate event.
The ”Make order” script accepts promisor and promisee
addresses (in terms of Ethereum), actions sequence and creates
a liability, an objective as a JSON-file and Model Checker file,
than publishes it to IPFS and its hash to the created contract.
In a such way, the contract between the user and the car is
created. The ”Validator” script checks for any contract, created
by the RobotLiabilityFactory, waits for a result, loads it from
the IPFS and passes to the Model Checker. Depending on the
Model Checking result, liability is either confirmed or rejected.
During the case study the validation framework was de-
veloped in Python language. PRISM [16] Model Checker
was selected to work in conjunction with the framework and
execute Model Checking algorithms. Main purpose of the tool
is to provide not only validation of the liability execution
but also generation of the model for Model Checking from
the template and settings, construction of the Temporal logic
property from the log file and construction of reduced models
of the service behavior. The last feature can be useful to deal
with state explosion problem.
Template file contains code in PRISM language represent-
ing the behavioral model, but explicit values of actions and
parameters are substituted with tags. Tag is a valid identifier
(can contain ascii letters or ) surrounded with @ symbol (for
instance, @moved@). This approach allows to avoid providing
complex formulas for actions by hand and linking parameters
of the model dynamically. Formulas for the tags are generated
by Generator class that is obligated to be written by developer
of the service in Python language. The main advantage is that
traditional test driven development can be utilized to improve
reliability.
Settings file contains text in YAML (YAML Ain’t Markup
Language) [33] format defining arguments needed to generate
values for parameters and actions from the template. Also
settings file can contain a list of (key, value) pairs to provide
default values for parameters and actions. Using the fact that
actions are represented by first order predicate logic formulas
we can provide constant default expression (true or false) for
those actions which we know don’t influence correctness of
the property but from the other hand contribute to the number
of states of the model. The strategy helps to reduce size of the
model and increase verification speed.
The dynamic view of model generation tool that is a part
of validation framework is shown in Fig. 3.
Fig. 3. The dynamic view representation of a model generation tool, which
compiles the final model from a template file taking into account settings.
To construct Temporal Logic properties from a log file an-
other tool was developed as part of the validation framework.
The tool assumes that variables of the agent-based system
are enumerated and named as follows V={v1, v2, . . . , vm}.
The value of i-th attribute at time tis denoted as vi(t).
The log file contains nrows and mcolumns. Each value
is referenced as r(i, j)i= 1, m, j = 1, n.A,G,E,X
are standard operators of Temporal Logic. Based on this
assumption algorithm is implemented and for now allows
construction of two types of properties defined recursively:
S(i) = (c(n−i+ 1) ∧E(X(S(i−1))) 2 < i ≤n
c(n−1) ∧A(G(c(n))) i= 2 (1)
W(i) = (c(n−i+ 1) ∧E(F(W(i−1))) 2 < i ≤n
c(n−1) ∧A(G(c(n))) i= 2 (2)
where c(i) = ^
0<j≤m
vj(i) = r(i, j).
First property is called strong and can be read as follows:
starting from the initial state represented by the first row there
is exist a transition that moves agent-based system to the state
represented by the second row and so on, finally, agent-based
system comes to the state represented by the last row and stay
in it forever.
The second property is called weak and can be read as
follows: starting from the initial state represented by the first
row there is a sequence of intermediate transitions that moves
agent-based system to the state represented by the second
row and so on, finally, agent-based system comes to the state
represented by the last row and stay in it forever. This property
type can be useful in situations when it is not possible for
agent-based system to log each change of state however the
customer is satisfied enough with partial log validation.
V. EX PE RI ME NT A ND RE SU LTS
The experiment was performed using Duckietown infras-
tructure (described in the Section IV) with a Duckiebot and a
desktop computer (with Ubuntu 16.04), which were connected
to each other wirelessly via the Duckietown Wi-Fi.
Regular Duckietown project nodes (e.g. line detector and
line following node) use almost all CPU resources, which
are caused by the fact that Duckiebot is based on Raspberry
Pi3. When we try to start the IPFS Daemon in parallel
with these nodes, the Duckiebot becomes unstable (lost road
marking, passed the stop line, etc.). To eliminate this effect,
both IPFS and Parity services were executed on the desktop
computer, located in the same network. Thus, in the case of
using robots with low-performing hardware, these optimiza-
tion issues should be solved. Another solution is to create an
infrastructure with dedicated IPFS and Ethereum services. In
that case, we should emphasize security-related issues.
Although, there were some performance issues, running on
the bot, several attempts were performed in the configuration
with IPFS, running on the bot. During them it was observed,
that there was time lag between file publication and file
becomes available on other node. Worse yet, current IPFS API
implementation for python has no timeout control mechanism,
making work with IPFS potentially unstable.
The robot was put on the first intersection and the system
started. Messages from meaningful for this experiment nodes,
as well as from demo scripts were displayed. IPFS and Parity
were running on the desktop computer. Parity was started
without a signer module, with 3 different unlocked account
(for client, car and validator) in Ropsten network. Then the
validator script was started and the “Make order“ script was
executed. The tobot got its objective and passed the city,
according to the given sequence. In the end it successfully
uploaded the result to the IPFS, which was checked by the val-
idator, which in its turn issued the confirm() transaction. The
experiment was recorded, the video is available on YouTube
[34]. Although there were some issues, the experiment should
be evaluated as successful. The full liability life-cycle was
shown on real hardware.
VI. DISCUSSION
This work is a proof-of-concept of the full-cycle liability
execution, including the validation stage. Having this proof-
of-concept, now it is important to evaluate existing robonomics
infrastructure and to propose improvements. The important
part of this work is the real life case analysis. In this work we
consider the simple behavior model, which can be evaluated
as the first level of the complex taxi-service prototype and
as the beginning point of the case study research. It is
possible to sequentially increase its complexity by adding new
components. Each component and case are a subject for further
investigations. Open issues are the following:
1) Usually users ask a taxi service to pick them from the
point A and to the point B. It should be defined, what is the
objective for the full cycle (movement to A and then to B)
and how many smart-contracts should we create for this case.
2) In our simple example a user makes a deal directly with
the robocar, that means the user should know car’s location
and its address in advance. However, it is not usually true.
Some kind of an intermediate service is required to connect
to the user and the service provider.
3) With the increasing number of IoT devices and road
infrastructure improvement it is possible to turn them to the
part of robonomic. For instance, a car can make deal with the
infrastructure in order to build an optimal route or even to get
active support from the infrastructure.
4) The AIRA liability validation model assumes that robots
do not forge a log of objective execution intentionally. It
means, that there is an option for service provider to get
payment for not provided service. Possible solution is to
introduce ”recorders”, for instance, which can record to the
blockchain the fact of presence of an agent in the given place
at the given time. This information could be considered during
the log validation process. The full process description should
be developed as well as economic model: someone should pay
for this data.
Obviously, complex agents behavior will require improve-
ments in the modeling and validation framework:
1) The main drawback of the Model Checking approach is
that the number of states of the agent-based system exponen-
tially grows with the number of variables. This means that not
all models can physically be processed and there is a need in
a mechanism that restricts complexity of models.
2) Additional work must be done to expand the approach to
conditions when the probabilistic model is more suitable than
the nondeterministic one. In that case the Probabilistic Model
Checking can be utilized.
3) The validation framework can also be enhanced. In par-
ticular the implementation of the tool that allows generation of
high level code from the Model Checking model automatically
and its integration into the service development project.
4) The property generation tool can be enhanced with new
property types. Moreover, usage of the tool can be extended to
customers allowing them to construct their own properties, for
example, in order to verify that the submitted model satisfies
their needs before allowing liability to be executed by a service
provider.
VII. CONCLUSION
In this work we considered one concept of a model of
the decentralized trading market for autonomous agents called
robonomics. For special agent-based systems the new ap-
proach based on Model Checking formal software verification
technique was introduced to address validation problem of
a liability execution that can help to suspend payments to
malfunctioned service providers and can be integrated together
with a reputation model into a blockchain consensus protocol.
The validation procedure tries to prove that a result submitted
by a service provider after the execution corresponds to the
behavior model submitted beforehand. However, to pass a
property as an input to Model Checker, it must be transformed
to a Temporal Logic formula. Moreover, the construction of a
model for complex systems, which is suitable for an execution
by the Model Checker, is also complex task. Therefore, we
have developed the framework that can help to overcome
both problems. The validation approach was evaluated as a
part of the complex AIRA robonomics prototype, which was
implemented, using the Duckietown project. The prototype
implements the simple real-life case - a robot driving accord-
ing to the given route with the following liability validation.
Finally, we opened the discussion about future implications
for proposed solutions.
VIII. ACKN OWLEDGEMENTS
We would like to thank Innopolis University, Prof. Nikolaos
Mavridis for the possibility to use Duckietown environment at
Innopolis University, and AIRA lab. researchers for valuable
discussions and consulting in AIRA project.
REFERENCES
[1] S. Nakamoto, “Bitcoin: A peer-to-peer electronic cash system,” 2008.
[2] G. Wood, “Ethereum yellow paper.” http://yellowpaper.io, 2014.
[3] SONM, “Supercomputer organized by network mining.” https://sonm.io,
2017. Whitepaper.
[4] S. Popov, “The tangle.” https://iota.org/IOTA Whitepaper.pdf, 2016.
[5] D. Strugar, R. Hussain, M. Mazzara, and V. Rivera, “M2m billing for
electric autonomous vehicles,” arXiv preprint arXiv:1804.00658, 2018.
[6] “Aira: Robot economics doctrine.” http://aira.life/wp-content/uploads/
2017/08/Aira robot economics doctrine 1-3.pdf.
[7] A. Kapitonov, S. Lonshakov, A. Krupenkin, and I. Berman, “Blockchain-
based protocol of autonomous business activity for multi-agent systems
consisting of uavs,” in Workshop on Research, Education and Develop-
ment of Unmanned Aerial Systems (RED-UAS), pp. 84–89, 2017.
[8] M. O. Rabin and D. Scott, “Finite automata and their decision problems,”
IBM J. Res. Dev., vol. 3, pp. 114–125, Apr. 1959.
[9] E. M. Clarke, O. Grumberg, and D. Peled, Model checking. MIT press,
1999.
[10] Y. G. Karpov, “Model checking: Verification of parallel and distributed
program systems,” SPb: BHV-Petersburg. In Russian., p. 560, 2010.
[11] G. J. Holzmann, “The model checker spin,” IEEE Transactions on
software engineering, vol. 23, no. 5, pp. 279–295, 1997.
[12] A. Cimatti, E. Clarke, E. Giunchiglia, F. Giunchiglia, M. Pistore,
M. Roveri, R. Sebastiani, and A. Tacchella, “Nusmv 2: An opensource
tool for symbolic model checking,” in International Conference on
Computer Aided Verification, pp. 359–364, Springer, 2002.
[13] R. H. Bordini, M. Fisher, W. Visser, and M. Wooldridge, “Verifying
multi-agent programs by model checking,” Autonomous agents and
multi-agent systems, vol. 12, no. 2, pp. 239–256, 2006.
[14] A. Lomuscio, H. Qu, and F. Raimondi, “Mcmas: A model checker for
the verification of multi-agent systems,” in International conference on
computer aided verification, pp. 682–688, Springer, 2009.
[15] S. Konur, C. Dixon, and M. Fisher, “Analysing robot swarm behaviour
via probabilistic model checking,” Robotics and Autonomous Systems,
vol. 60, no. 2, pp. 199–213, 2012.
[16] M. Kwiatkowska, G. Norman, and D. Parker, “Prism 4.0: Verification of
probabilistic real-time systems,” in Int. conference on computer aided
verification, vol. 6806, pp. 585–591, Springer, 2011.
[17] L. Paull, J. Tani, H. Ahn, J. Alonso-Mora, L. Carlone, M. Cap, Y. F.
Chen, C. Choi, J. Dusek, Y. Fang, et al., “Duckietown: an open,
inexpensive and flexible platform for autonomy education and research,”
in IEEE Int. Conference on Robotics and Automation (ICRA), pp. 1497–
1504, 2017.
[18] “Hyperledger architecture, volume 1.” www.hyperledger.org/wp-content/
uploads/2017/08/Hyperledger Arch WG Paper 1 Consensus.pdf.
[19] J. C. Willems, “Models for dynamics,” in Dynamics reported, pp. 171–
269, Springer, 1989.
[20] J. J. Rold´
an, J. del Cerro, and A. Barrientos, “A proposal of methodology
for multi-uav mission modeling,” in IEEE Mediterranean Conference on
Control and Automation (MED), pp. 1–7, 2015.
[21] C. Hoare, Communicating Sequential Processes. Prentice-Hall Interna-
tional Series in Computer Science, Prentice Hall, 1985.
[22] R. Milner, “A calculus of communicating systems,” Lecture Notes in
Comput. Sci. 92, 1980.
[23] R. Milner, Communicating and Mobile Systems: The Pi-Calculus. Cam-
bridge University Press, Cambridge, UK, 1999.
[24] D. M. Lyons, R. C. Arkin, S. Jiang, T. M. Liu, and P. Nirmal,
“Performance verification for behavior-based robot missions,” IEEE
Transactions on Robotics, vol. 31, pp. 619–636, June 2015.
[25] E. C. Ferrer, “The blockchain: a new framework for robotic swarm
systems,” arXiv preprint arXiv:1608.00695, 2016.
[26] V. Buterin et al., “Ethereum white paper.” https://github.com/ethereum/
wiki/wiki/White-Paper, 2013.
[27] V. Buterin, “Ethereum sharding faq.” https://github.com/ethereum/wiki/
wiki/Sharding-FAQ, 2017.
[28] J. Poon and V. Buterin, “Plasma: Scalable autonomous smart contracts,”
White paper, 2017.
[29] R. Rezin, I. Afanasyev, M. Mazzara, and V. Rivera, “Model checking
in multiplayer games development,” IEEE International Conference on
Advanced Information Networking and Applications (AINA), 2018.
[30] E. M. Clarke, E. A. Emerson, and A. P. Sistla, “Automatic verification
of finite-state concurrent systems using temporal logic specifications,”
ACM Trans. Program. Languages & Systems (TOPLAS), vol. 8, no. 2,
pp. 244–263, 1986.
[31] E. Olson, “Apriltag: A robust and flexible visual fiducial system,” in
IEEE International Conference on Robotics and Automation (ICRA),
pp. 3400–3407, 2011.
[32] “Aira core repository.” https://github.com/airalab/core.
[33] O. Ben-Kiki, C. Evans, and B. Ingerson, “Yaml aint markup language.”
http://www.yaml.org/spec/1.2/spec.html, 2009.
[34] “Duckietown aira prototype.” https://youtu.be/mmC8jxXWWJw.
