Logic Programming with Post-Quantum Cryptographic Primitives for Smart Contract on Quantum-Secured Blockchain

This paper investigates the usage of logic and logic programming in the design of smart contracts. Our starting point is the logic-based programming language for smart contracts used in a recently proposed framework of quantum-secured blockchain, called Logicontract (LC). We then extend the logic used in LC by answer set programming (ASP), a modern approach to declarative logic programming. Using ASP enables us to write various interesting smart contracts, such as conditional payment, commitment, multi-party lottery and legal service. A striking feature of our ASP implementation proposal is that it involves post-quantum cryptographic primitives, such as the lattice-based public key encryption and signature. The adoption of the post-quantum cryptographic signature overcomes a specific limitation of LC in which the unconditionally secure signature, despite its strength, offers limited protection for users of the same node.

A blockchain is a distributed, transparent and append-only chain of cryptographically linked units of data (blocks) stored in a large decentralized network. Due to the mechanisms of introducing new data based on consensus, blockchain can be used by peers who do not trust each other. The data entries can be considered transactions, so a blockchain can be treated as a ledger. Peers in charge of updating the ledger (called often miners) have separated, identical copies of the ledger. This fact makes the system distributed and is crucial for its safety. Recently Bitcoin [1] and other cryptocurrencies made the blockchain technology widely known. Another important and still not fully utilized way of using blockchain is the implementation of smart contracts [2] on their basis. Smart contract is a piece of software that implements an agreement between parties in such a way that terms of the contracts are enforced automatically. Due to registering them in a blockchain, smart contracts are irrefutable, which makes them appropriate for mutually distrusting peers. The main advantage is that a trusted third party is not needed for the affirmation and enforcement of contracts.
The advantages of smart contracts reside in the fact that existing blockchain platforms provide an infrastructure for them. In most cases, procedural languages are supported for smart contracts. However, logic-based languages for smart contracts seem to provide some advantages over the procedural approach [3,4]. The main ones are the following: • Logical programs in general and smart contracts among them are better suited for formal verification than procedural programs. In the case of procedural programs, a usual way to proceed is to construct a formal calculus with rigorous semantics and express a program as a set of expressions of that calculus [5,6]. Logic is formal calculus itself, so there is no need for translation to other systems, and the verification is easier. • Logical contracts are usually more compact. In contrast to their procedural counterparts, they are limited only to what has to be done, without specifying how to achieve it.

Background and Related Work: Programming Language and Formal Models of Bitcoin-like Smart Contract
In this section, we briefly review the existing work on the programming languages and formal models of Bitcoin-like smart contracts. The work on the programming languages and formal models of Ethereum-like smart contracts are also relevant to our paper. However, due to the limitation of space, we will not review them. The interested reader may find a survey of these works by Rouhani [15].

Timed Automata
Andrychowicz et al. [16] proposed a framework for modeling Bitcoin contracts using the timed automata (TA) in the UPPAAL model checker [17]. Their key idea is to use TA to model the behavior of each participant in a contract. The whole system is then modeled as the network constructed by composing these TAs, plus a TA that models the Bitcoin network. The security of the smart contract is then verified in UPPAAL automatically, finding and correcting some subtle errors that are difficult to discover by the manual analysis.

Simplicity
Simplicity [18] is an alternative language for Bitcoin scripts. It is a typed, combinatorbased, functional language without loops and recursion. For a formal verification of Simplicity programs, denotational semantics in Coq, a popular, general-purpose software proof assistant, is defined. An abstract machine constituting operational semantics for Simplicity is also provided. It is possible to statically estimate the resources (e.g., memory) required to execute contracts written in Simplicity. In Valliappan et al. [19], the authors connected Simplicity's primitives with a categorical model. This lifts the language to a more abstract level allowing for extending it by category theory models of computations.

BitML
Bartoletti and Zunino [20] expressed Bitcoin contracts in BitML-a simple process calculus. Contracts are three-phase processes:

1.
Participants broadcast a contract advertisement, which specifies the content of the contract and its preconditions (e.g., depositing a certain amount of bitcoins).

2.
Participants accept the contract and fulfill all the required preconditions. When all the needed participants commit to the contract, the contract is stipulated and can be executed.

3.
Executing the contract eventually results in a transfer of the bitcoins deposited by the participants, according to the logic defined by the contract.

Logical Contract
The logical contract project http://logicalcontracts.com/(accessed on 22 August 2021) developed a logical representation of a legal document that is close to natural, human language and, at the same time, executable by computer. It can be used for the following: • Monitor compliance of the parties to a contract; • Enforce compliance, by automatically performing actions to fulfill obligations, and/or by issuing warnings and remedial actions to respond to violations of obligations; • Explore logical consequences of hypothetical scenarios; • Query and update the Ethereum blockchain.
The theoretic foundation of the logical contract project is a LPS (Logic-based Production System), which is a general-purpose computer language, developed by Kowalski, Sadri and Calejo [21][22][23].

Probabilistic Logic Programs for Blockchain and Smart Contracts
Azzolini et al. [24][25][26] applied probabilistic logic programs to model and analyze the safely and effectiveness of blockchain systems. They presented a method to translate smart contracts into probabilistic logic programs that can be used to analyze the expected values of several smart contract's utility parameters and obtain a quantitative idea on how smart contracts variables changes over time. They have used this method to study several real smart contracts deployed on the Ethereum blockchain.

Logicontract
The programming language for smart contracts on LC [8] is based on the script language of Bitcoin [5,20,27]. The definition of a formula of the language is as follows: e ::= x | k | e + e | Hash(e) φ ::= e = e | e > e | Odd(e) | A f ter(e) | ¬φ | φ ∧ φ where φ is a formula, e is an arithmetic expression, x is a variable ranging over natural numbers, k ∈ N is a constant natural number, Hash is a collision-resistant hash function on natural numbers, and Odd(e) means that e is an odd number. LC uses a global clock.
A f ter(e) means that the current time by the clock is later than e. Propositional operators of negation and conjunction are represented in a usual way by the symbols ¬ and ∧, respectively. The formal definition of the transaction on LC is as follows.
Definition 1 (transaction [8]). A transaction T is a tuple (send, rece, sour, cert, prot) with the following: • T is the name of the transaction. • send stands for the sender of the transaction. • rece stands for the set of ordered pairs and each of the pairs consists of a potential receiver of this transaction and the amount of the currency that the receiver will receive, i.e., rece = {(r 1 , a 1 ), . . . , (r m , a m )}. • sour stands for the source of the transaction, which is a list of names of transactions (T 1 , . . . , T n ) that are redeemed by T. • prot stands for the protection, which is a list of ordered pairs in which each pair consists of a receiver from rece and a formula that has to be fulfilled by the receiver to redeem the transaction, i.e., prot = {(r 1 , φ 1 ), . . . , (r m , φ m )}. In order to redeem T, r i has to provide φ i as the certification of a following transaction. • cert stands for the certification, which is a list of ordered pairs consisting of names of transactions and valuation functions that are supposed to satisfy protections of source transactions, i.e., cert = {(T 1 , V 1 ), . . . , (T n , V n )}. Valuation functions map variables to natural numbers. The list must provide a valuation function for each source transaction.
A transaction T redeems source transactions if and only if the following holds: 1.
The sender of T is one of the receivers in each of its source transactions.

2.
The certification of T evaluates correctly the protections of all sources.

3.
None of the sources has been already redeemed.
A transaction T is redeemed if one of its receivers has redeemed it.
Let us now see how the process of redeeming of one transaction by another on examples.
Example 1 (direct payment). Bob receives the amount of 1 coin from Alice (see Figure 1).

Logic Programming for Smart Contracts
The logic used to specify the protection in LC has strong limits on functions and predicates. It can be straightforwardly generalized to involve more expressive logical formulas from logic programming. More specifically, we will use answer set programming [28][29][30], a modern approach to logic programming, as our underlying logic. In the following, we will first review classical logic programming, then review the answer set programming as an extension of classical logic programming.

Classical Logic Programming
Now, we give a formal definition of notions, such as formula, valuation, satisfactions and entailment. All these notions can be found in the literature of logic programming [31,32].
Let X, Y, Z, . . . stand for variables, a, b, c, . . . for constants p, q, . . . for predicate symbols and f , g, h, . . . for function symbols. Constants can be treated as special cases of functions that have no arguments. A language L of logic programs is determined by the set of its predicates and functions (and constants).
A term is defined inductively as follows: any variable and any constant is a term, and if f is an n-ary function symbol and t 1 , . . . , t n are terms, then f (t 1 , . . . , t n ) is a term. If no variable occurs in a term, then the term is ground. The set of all ground terms that can be formed with the functions and constants of a language in L is called its Herbrand universe U L .
An atomic formula (atom in short) is built from an n-ary predicate and n terms as its arguments, e.g., p(t 1 , . . . , t n ). An atom is ground if all terms t i are ground. The set of all ground atoms that can be formed in L is called Herbrand base B L . Any atom and any negation of an atom is called a literal.
A rule of the following form is called a Horn clause: is an atom. A 0 is called the head of the clause, and the part on the right of ← is called its body. When i = 0, the body of a rule is empty; such a rule, taking the form A 0 ←, is called a fact. A classical logic program is a finite set of Horn clauses. Clauses (including facts) and logic programs containing no variables are called ground. For any logic program P, we can define the language L(P) that consists of the predicates, functions, and constants occurring in P. If there are no constants in P, we add to L(P) a constant to avoid the empty domain. For simplicity, instead of U L(P) and B L(P) , we will write U P and B P , respectively. A Herbrand interpretation of P is any subset I ⊆ B P of its Herbrand base. Intuitively, the atoms in I are true, and all others are false. A Herbrand interpretation of P such that for each rule A 0 ← A 1 , . . . , A m in P, this interpretation satisfies the logical formula ∀X((A 1 ∧ . . . ∧ A m ) → A 0 ) (X being the list of all variables occuring in the rule) is called the Herbrand model of P.
The notions of a Herbrand interpretation and Herbrand model can be generalized, in a natural way, to infinite sets of clauses. Let P be an arbitrary (finite or infinite) set of ground clauses. P defines an operator T P : 2 B P → 2 B P , where 2 B P denotes the set of all Herbrand interpretations of P, by the following: This operator is called the immediate consequence operator; intuitively, it yields all atoms that can be derived by a single application of some rule in P, given the atoms in I. Since T P is monotone, by the Knaster-Tarski theorem, it has the least fixed point, denoted by T ∞ P . It can be proven that T ∞ P is the limit of the sequence T 0 P = ∅, T i+1 P = T P (T i P ). A ground atom A is called a consequence of a set P of clauses if A ∈ T ∞ P (we write P |= A). Additionally, we say that a negated ground atom ¬A is a consequence of P and write P |= ¬A if A / ∈ T ∞ P . The semantics of a set P of ground clauses, denoted as M(P), is defined as the following set consisting of atoms and negated atoms.
For a ground formula φ, built from literals with connective ∧, ∨, we define P |= φ if M(P) |= φ according to the semantics of classical logic. The semantics of logic programs is now defined as follows. Let the grounding of a clause r in a language L, denoted as ground(r, L), be the set of all clauses obtained from r by all possible substitutions of elements of U L for the variables in r. For any logic program P, we define the following: ground(P, L) = r∈P ground(r, L), and we write ground(P) for ground(P, L(P)). The operator T P : 2 B P → 2 B P associated with P is defined by T P = T ground(P) . Accordingly, M(P) = M(ground(P)).

Answer Set Programming
While a rule in classical logic programming is of the form A 0 ← A 1 , . . . , A m , in answer set programming a rule has the following form: where all L i , 1 ≤ i ≤ n are literals (i.e., atoms or the negation of atoms) and 0 ≤ k ≤ l ≤ m ≤ n. Here, ∼ is the default negation (negation as failure). For a rule r of the above form, {L 1 , . . . , ∼ L l } is the head of r and {L l+1 , . . . , ∼ L n } is the body of r. We use Head(r) and Body(r) to denote the head and body of r, respectively.
The notion of an answer set is defined first for ground programs, which do not contain default negation. Let P be such a program and M be a consistent set of literals. We say that M is closed under P if for every rule r ∈ P, Head(r) ∩ M = ∅ whenever Body(r) ⊆ M.
M is an answer set for P if M is minimal (relatively to set inclusion) among the sets of literals that are closed under P. Now, we extend the definition of an answer set to ground programs with default negation. Let P be an arbitrary program and M a consistent set of literals. The reduct P M of P relative to M is the set of the following rule: in P such that M contains all literals L k+1 , . . . , L l but does not contain any of L m+1 , . . . , L n . Thus, P M is a ground program without default negation. We say that M is an answer set for P if M is an answer set of P M .
Finally, for a non-ground program P, the answer set for P is the answer set for ground(P). It can be verified that if a program P in answer set programming is also a classical logic program, then there is a unique answer set of P, and it coincides with the least fixed point of T P . A ground literal L is entailed by a program P, denoted by P |= L, if L is contained in all answer sets of P. For a ground formula φ built from literals with connective ∧, ∨, P |= φ is defined by interpreting ∧, ∨ in the same way as in classical logic.

Transaction and Smart Contracts
Now, we are ready to define a new notion of transaction in which protection and certification are specified by logical programs and its semantics.

Definition 2 (transaction).
A transaction T is a tuple (send, rece, sour, cert, prot), where send, rece, sour are defined in the same way as in LC, and the following: • prot is the protection, which is a list of triples of logic programs, formulas and time locks. The number of triples must be the same as the number of receivers. Formally, prot = {(r 1 , (P 1 , φ 1 , tilo 1 )), . . . , (r m , (P m , φ m , tilo m ))}. P i is a logical program of answer set programming. φ i is either the logical truth or a non-ground formula φ built from literals with connective ∧, ∨. tilo i is the time lock, which is of the form a f ter(k) for some natural number k. • cert is the certification, which is a set of ordered pairs of which the first component is the name of a transaction and the second component is either a set of literals or a valuation function that maps variables to constants. Formally, cert = {(T 1 , V 1 ), . . . , (T n , V n )}. V i satisfies (P i , , tilo i ) if V i is an answer set for P i and the time lock is satisfied by the global clock. V i satisfies (P i , φ i , tilo i ), where φ i is a non-ground formula φ built from literals with connective ∧, ∨, if P i |= V i (φ i ) and the time lock is satisfied by the global clock. When the time lock is ∅, it is vacuously satisfied by the global clock.
Just like in LC, a transaction T redeems its sources if and only if the following holds: 1.
The sender of T is one of the receivers in each of its source transactions.

2.
The certification of T evaluates the protections of all its sources to be true.

None of its source transactions has been redeemed.
A transaction T is redeemed if one of its receivers has redeemed it. We typically include a special predicate A f ter(·) in our language. The atom A f ter(t) is true when the global clock has passed time t. Some primitives of the post-quantum public key infrastructure [33] are also involved in our language. At the current stage, we do not specify which post-quantum algorithm is to be used because the standardization of post-quantum cryptography is still an ongoing procedure. Instead, we give an abstract description of some primitives of post-quantum cryptography in ASP. Those primitives include the encryption, signature and hash function.

•
For encryption, a secret key sk is a constant. The function pk(·) maps sk to the corresponding public key pk(sk). The encryption function enc(·, ·) maps a plain message m and public key pk = pk(sk) to an encrypted message enc(m, pk). • For signature, the signing function sign(·, ·) maps a message m and a secret key sk to the signature sign(m, sk). The atom verSig(σ, m, pk) is true when σ = sign(m, sk) is the signature of m and sk with public key pk = pk(sk).

•
The hash function is represent by a collision-resistant function Hash.
Note that we use both an unconditionally secure signature and a post-quantum public key signature (e.g., lattice-based signature). They serve different purposes. The unconditionally secure signature is used to prove that a message from node A to other nodes is indeed sent from node A. Since the computer A may have more than one users, the post-quantum public key signature is used to prove the identity of the users of a computer.
This new format of transaction enables us to design various interesting smart contracts, especially contracts related to knowledge representation, automated planning, constraint solving and other areas in which ASP has proven to be applicable. Now, we use several examples for the demonstration.
Example 5 (authorized payment). Bob receives a coin from Alice if he provides an appropriate signature from Bob 1 (see Figure 5). Here, Bob is a (classical or quantum) computer, which is a node of the underlying quantum-secured permissioned blockchain. Bob 1 is a user of Bob. PK Bob 1 and SK Bob 1 are, respectively, the public and secret key of Bob 1 , and sign("agree", SK Bob 1 ) represents the signature of the message "agree" generated by secret key SK Bob 1 . Similarly, if Alice changes verSig(x, "agree", PK Bob 1 ) to (verSig(x, "agree", PK Bob 1 ) ∨ verSig(y, "agree", PK Bob 2 )) ∧verSig(z, "agree", PK Bob 3 ), then Bob has to provide a signature of Bob 3 and at least one of the signatures of Bob 1 and Bob 2 . . . . prot: {(Bob, (∅, verSig(x, "agree , PK Bob 1 ), ∅))}.  Example 6 (conditional payment with Sudoku). Bob receives 1 coin from Alice on the condition that Bob solves a Sudoku puzzle (see Figure 6). Here, Sudo is a Sudoku puzzle described in logical programs. A detailed formalization of Sudo can be found in Hölldobler and Schweizer [29]. Ans is an answer set for Sudo.  Obviously, we can replace Sudo by any logical program. This means that we can realize various interesting conditional payments, as long as the condition can be expressed by logic programs.

Multi-Party Lottery
Lottery is a part of the gambling industry with a turnover of billions of dollars [34]. Traditionally, a lottery game is organized by a trustworthy authority. In order to enter a lottery game, players buy tickets. Then, the authority organizing the game initiates a random process that determines the winning tickets. The revenue, in many cases, is large enough to induce temptation to cheat. To ensure fairness of a lottery game and trust of the players, several requirements on a lottery protocol were formulated (c.f. [16,[35][36][37][38][39]):

1.
Randomness. All tickets are equally likely to win. 2.
Unpredictability. No player can predict the winning ticket.

3.
Unforgeability. Tickets cannot be forged. In particular, it is impossible to create a winning ticket after the outcome of the random process is known.

4.
Verifiability. The number and the revenue of winning tickets are publicly verifiable.

5.
Decentralization. The random process does not rely on a single authority.
Note that decentralization allows to organize a lottery without the need for an authority that all players trust, replacing it by alternative mechanisms, such as Blockchain.
In [8], a two-party lottery protocol satisfying the above requirements is defined. We extend it to a multi-party lottery protocol.
Example 8 (multi-party lottery). The lottery protocol consists of several steps.

1.
Alice commits a secret to Bob by making a deposit. Bob commits a secret to Charlie by making a deposit. Charlie commits a secret to Alice by making a deposit. (See Figure 8).

2.
Alice sends a conditional transfer to Alice, Bob and Charlie. Bob sends a conditional transfer to Alice, Bob and Charlie. Charlie sends a conditional transfer to Alice, Bob and Charlie. (See Figure 9). Here, AliceWin is specified by (Hash Alice can also redeem her conditional transfer after 20220130. This condition ensures that Alice can get her money back in case any participant aborts the lottery game before the results can be determined. This is similarly the case for Bob and Charlie.

3.
Alice reveals her secret and gets her deposit back. Bob reveals his secret and gets his deposit back. Charlie reveals his secret and gets his deposit back. (See Figure 10). 4. Now, Alice, Bob and Charlie's secrets are public and the winner can be determined. The winner redeems the loser's conditional transfer and his/her own conditional transfer. If Alice is the winner, then she redeems T 3 , T 4 and T 5 . This is similarly true for Bob/Charlie when they are the winner. (See Figure 11).

Legal Service
As in the last example, we show that our logical contracts can be used to provide a legal consultation service on blockchain. This is possible because ASP is able to express legal/normative rules, thanks to the close connection between ASP and default logic, which, in turn, can be used to express legal/normative rules. The connection between ASP and default logic is the following. Let P be a program such that the head of every rule of P is a single literal, as follows: We can transform P into a default theory D(P) in the sense of [40] by turning each rule (1) into the default as follows: The correspondence between P and D(P) is the following: if X is an answer set for P, then the deductive closure of X is a consistent extension for D(P); conversely, every consistent extension for D(P) is the deductive closure of an answer set for P.
In deontic default logic [41], a conditional obligation φ → Oψ, meaning that if φ, then it is obliged to be ψ, and is expressed by a default as follows: Therefore, a conditional obligation L 1 → OL 2 can be expressed as the following rule in ASP: Moreover, since a conditional prohibition φ → Fψ, meaning that if φ, then it is forbidden to be ψ, is defined by φ → O¬ψ, we can express a conditional prohibition L 1 → FL 2 as the following rule in ASP: Now, if the protection of a transaction T includes a logical program P, which consists of some facts, conditional obligations and prohibitions expressed in ASP, then a transaction T redeems T only if it provides an answer set of P. We can view P as a description of a legal situation or a normative system together with some facts. An answer set of P is then a suggestion of actions to be taken. In this sense, legal consultation can be carried out by transactions of blockchain.

Conclusions and Future Work
This paper applies answer set programming, enriched with post-quantum cryptographic primitives, to the design and specification of smart contracts on quantum-secured blockchains. The enrichment of post-quantum cryptographic primitives overcomes the limitation of unconditionally secure signatures in existing quantum-secured blockchains, which do not provide mechanisms for user authentication.
The application of ASP allows us to design various interesting smart contracts. Compared to procedural languages, the smart contracts written in our logical language are easier to be understood and formally verified.
In the future, we plan to systematically explore the usage of our framework in multiparty secure computation. We are also interested in further extending our logical language to include primitives of quantum computation. Such an extension will create a programming language of smart contracts in quantum logic.
Funding: The project is funded by the Minister of Education and Science within the program under the name "Regional Initiative of Excellence" in 2019-2022, project number: 028/RID/2018/19, to the amount: 11,742,500 PLN.