Towards a Formally Verified Implementation of the MimbleWimble Cryptocurrency Protocol

Abstract

MimbleWimble is a privacy-oriented cryptocurrency technology which provides security and scalability properties that distinguish it from other protocols of its kind. We present and briefly discuss those properties and outline the basis of a model-driven verification approach to address the certification of the correctness of an implementation of the protocol.

Appendices

A Excerpt of a Z Model of a Consensus Protocol

The following are some snippets of a Z model of a consensus protocol based on the model developed by Pîrlea and Sergey [36]. For reasons of space we just reproduce a little part of it.

The time stamps used in the protocol are modeled as natural numbers. Then we have the type of addresses (Addr), the type of hashes (Hash), the type of proofs objects (Proof) and the type of transactions (Tx). Differently from Pîrlea and Sergey’s model⁶ we modeled addresses as a given type instead as natural numbers. In PS the only condition required for these types is that they come equipped with equality, which is the case in Z.

The block data structure is a record with three fields: prev, (usually) points to the parent block; txs, stores the sequence of transactions stored in the block; and pf is a proof object required to validate the block.

The local state space of a participating network node is given by three state variables: as, are the addresses of the peers this node is aware of; bf, is a block forest (not shown) which records the minted and received blocks; and tp, is a set of received transactions which eventually will be included in minted blocks.

The system configuration is represented by two state variables: Delta, which establishes a mapping between network addresses and the corresponding node (local) states (in PS this variable is referred to as the global state); and P, a set of packets (which represent the messages exchanged by nodes).

Packets are just tuples of two addresses (origin and destination) and a message.

The model has twelve state transitions divided into two groups: local and global. Local transitions are those executed by network nodes, while global transitions promote local transitions to the network level. In turn, the local transitions are grouped into receiving and internal transitions. Receiving transitions model the nodes receiving messages from other nodes and, possibly, sending out new messages; internal transitions model the execution of instructions run by each node when some local condition is met. Here, we show only the local, receiving transition named RcvAddr.

As can be seen, RcvAddr receives a packet (p?) and sends out a set of packets (ps!). The node checks whether or not the packet’s destination address coincides with its own address. In that case, the node adds the received addresses to its local state and sends out a set of packets that are either of the form (p?.2, a, ConnectMsg) or $(p?.2,a,AddrMsg~as')$. The former are packets generated from the received addresses and sent to the new peers the node now knows, while the latter are messages telling its already known peers that it has learned of new peers.

B Excerpt of a $\{log\}$ Prototype of a Consensus Protocol

In this section we show the $\{log\}$ code corresponding to the Z model presented in Appendix A. $\{log\}$ code can be seen as both a formula and a program [13]. Thus, in this case we use the code as a prototype or executable model of the Z model. The intention is twofold: to show that passing from a Z specification to a $\{log\}$ program is rather easy, and to show how a $\{log\}$ program can be used as a prototype. The first point is achieved mainly because $\{log\}$ provides the usual Boolean connectives and most of the set and relational operators available in Z. Hence, it is quite natural to encode a Z specification as a $\{log\}$ program.

Given that $\{log\}$ is based on Prolog its programs resemble Prolog programs. The $\{log\}$ encoding of RcvAddr is the following:

As can be seen, rcvAddr is clause receiving the before state (LocState), the input variable (P), the output variable (Ps) and the after state (LocState_). As in Prolog, $\{log\}$ programs are based on unification with the addition of set unification. In this sense, a statement such as LocState = [as,As]/Rest (set) unifies the parameter received with a set term singling out the state variable needed in this case (As) and the rest of the variables (Rest). The same is done with packet P where _ means any value as first component and addrMsg(Asm) gets the set of addresses received in the packet without introducing an existential quantifier.

The set comprehensions used in the Z specification are implemented with $\{log\}$ ’s so-called Restricted Intentional Sets (RIS) [12]. A RIS is interpreted as a set comprehension where the control variable ranges over a finite set (D and As).

Given rcvAddr we can perform simulations on $\{log\}$ such as:

in which case $\{log\}$ returns:

That is, $\{log\}$ binds values for all the free variables in a way that the formula is satisfied (if it is satisfiable at all). In this way we can trace the execution of the protocol w.r.t. states and outputs by starting from a given state (e.g. S) and input values (e.g. |[_,this,addrMsg(a1,a2)]), and chaining states throughout the execution of the state transitions included in the simulation (e.g. S1 and S2).