System and method for offline payment on a blockchain

Abstract

Computer-implemented methods and a system are presented for offline payments between nodes. The method includes setting up a vouching agreement between a first and a second node and locking a vouched amount of tokens at the first node for use by the second node. An offline transaction is performed between the second and a third node, wherein the offline transaction exceeds a second amount of tokens available to the second node. While offline, the second node uses the vouched amount to perform the offline transaction with the third node. When online again, the second node reconciles the vouched amount with the first node. If the second node does not pay back the vouched amount to the first node, a reputation score of the second node is decreased. If the second node pays back the vouched amount to the first node, reputation scores of the first and the second node are increased.

Description

[0001] System and method for offline payments on a blockchain

[0002] Technical field

[0003] The present disclosure relates to computer-implemented methods, a computer program product and a system for offline payments. More particularly, the present disclosure relates to blockchain based offline payments.

[0004] Background

[0005] In the modern digital age, financial transactions have become heavily reliant on internet connectivity, a reality that overlooks scenarios where such connectivity is lacking, unreliable, or too expensive. This gap highlights a need for robust offline payment solutions to overcome the discrepancies in areas that traditional internetbased systems fail to provide. Although practical, traditional payment methods like cash, checks, postal orders, and bank transfers are loaded by security, speed, and scalability limitations and are insufficient for the demands of a modern, digital economy where high availability is necessary.

[0006] The absence of dependable offline payment mechanisms hinders financial inclusivity and exposes businesses and individuals to operational risks during network congestion or failures. The challenges are most noticeable in remote regions, where the technological gap is most prominent.

[0007] Summary

[0008] A summary of aspects of certain examples disclosed herein is set forth below. It should be understood that these aspects are presented merely to provide the reader with a brief summary of these certain embodiments and that these aspects are not intended to limit the scope of this disclosure. Indeed, this disclosure may encompass a variety of aspects and / or a combination of aspects that may not be set forth.

[0009] The present disclosure aims to overcome the drawbacks identified in the background section. According to an aspect of the present disclosure a computer-implemented method is presented for offline payments between a plurality of nodes. The method may include setting up a vouching agreement between a first node of the plurality of nodes and a second node of the plurality of nodes. The vouching agreement may be stored in a smart contract of a blockchain. The setting up of the voucher agreement may include locking a vouched amount of tokens at the first node for use by the second node. The method may further include performing an offline transaction between the second node and a third node of the plurality of nodes. The offline transaction may exceed a second amount of tokens available to the second node. While offline, the second node may use the vouched amount of tokens to perform the offline transaction with the third node. When online again, the second node may reconcile the vouched amount of tokens with the first node. If the second node does not pay back the vouched amount of tokens to the first node, the method may include decreasing a reputation score of the second node and storing the decreased reputation score in the blockchain 106. If the second node pays back the vouched amount of tokens to the first node, the method may include increasing a reputation score of the first node and increasing a reputation score of the second node and storing the increased reputation score of the first node and the reputation score of the second node in the blockchain.

[0010] In an embodiment, setting up the vouching agreement between the first node and the second node may be performed when the first node and the second node are online. The first node vouches the vouched amount of tokens to the second node by storing data representative of the vouched amount of tokens in the vouching agreement. The vouching agreement may be a data record stored in the smart contract. The method may include updating a first amount of tokens available to the first node by locking the vouched amount of tokens and subtracting a token fee from the first amount of tokens. The updating may further include updating a second amount of tokens available to the second node by subtracting the token fee from the second amount of tokens. When the second node is offline, the method may include performing the offline transaction for an amount of transaction tokens (i.e., the transaction having a value equal to an amount of transaction tokens) between the second node and the third node. If the second amount of tokens is insufficient for the offline transaction, the second node may claim the vouched amount of tokens from the first node and update the second amount of tokens available to the second node by adding the vouched amount of tokens to and subtracting the token fee from the second amount of tokens, and updating the third amount of tokens available to the third node by adding the amount of transaction tokens to the third amount of tokens. When the second node is online again after performing the offline transaction, if the second node does not pay back the vouched amount of tokens to the first node, the method may include decreasing the reputation score of the second node to obtain an updated reputation score of the second node and storing data representative of the updated reputation score in the blockchain; or if the second node pays back the vouched amount of tokens to the first node, the method may include increasing the reputation score of the first node and increasing the reputation score of the second node to obtain an updated reputation scores of the first and second node and storing data representative of the updated reputation scores in the blockchain.

[0011] In an embodiment, if the second node pays back the vouched amount of tokens to the first node, the method may further include performing a FIAT transaction between a Bank node and the second node to increase the second amount of tokens. The second node may pay back the vouched amount of tokens by deducting the vouched amount of tokens from the second amount of tokens and adding the vouched amount of tokens to the first amount of tokens.

[0012] In an embodiment, if the second node pays back the vouched amount of tokens to the first node, an interest in the form of tokens may be added to the amount of tokens to pay back to the first node. The interest may depend on the reputation score of the second node.

[0013] According to an aspect of the present disclosure, a computer-implemented method at a second node is presented for offline payments. The method may include setting up a vouching agreement with a first node of a plurality of nodes. The vouching agreement may be stored in a smart contract of a blockchain and may result in locking a vouched amount of tokens at the first node for use by the second node. The method may further include performing an offline transaction with a third node of the plurality of nodes. The offline transaction may exceed a second amount of tokens available to the second node. While offline, the second node may use the vouched amount of tokens to perform the offline transaction with the third node. When online again, the second node may reconcile the vouched amount of tokens with the first node. If the second node does not pay back the vouched amount of tokens to the first node, the method may include decreasing a reputation score of the second node and storing the decreased reputation score in the blockchain. If the second node pays back the vouched amount of tokens to the first node, the method may include increasing a reputation score of the second node and storing the increased reputation score of the second node in the blockchain.

[0014] In an embodiment, setting up the vouching agreement with the first node is performed when the first node is online. The vouching agreement may be a data record stored in the smart contract. The updating may further include updating a second amount of tokens available to the second node by subtracting a token fee from the second amount of tokens. When the second node is offline, the method may include performing the offline transaction for an amount of transaction tokens (i.e., the transaction having a value equal to an amount of transaction tokens) between the second node and the third node. If the second amount of tokens is insufficient for the offline transaction, the second node may claim the vouched amount of tokens from the first node and update the second amount of tokens available to the second node by adding the vouched amount of tokens to and subtracting the token fee from the second amount of tokens. When the second node is online after performing the offline transaction: if the second node does not pay back the vouched amount of tokens to the first node, the method may include decreasing the reputation score of the second node to obtain an updated reputation score of the second node and storing data representative of the updated reputation score in the blockchain; or if the second node pays back the vouched amount of tokens to the first node, the method may include increasing the reputation score of the second node to obtain an updated reputation score of the second node and storing data representative of the updated reputation score in the blockchain.

[0015] In an embodiment, if the second node pays back the vouched amount of tokens to the first node, the method may further include performing a FIAT transaction with a Bank node to increase the second amount of tokens. The second node may pay back the vouched amount of tokens by deducting the vouched amount of tokens from the second amount of tokens and adding the vouched amount of tokens to the first amount of tokens.

[0016] In an embodiment, if the second node pays back the vouched amount of tokens to the first node, an interest in the form of tokens may be added to the amount of tokens to pay back to the first node. The interest may depend on the reputation score of the second node.

[0017] In an embodiment, if the second node cannot pay back the vouched amount of tokens to the first node, the method may further include determining if another vouching agreement exists between any one of the plurality of nodes and the second node, possibly recursively, to execute the pay back of the vouched amount of tokens to the first node.

[0018] In an embodiment, the reputation scores may be determined based on a MeritRank enhanced Sybil tolerance.

[0019] In an embodiment, the plurality of nodes may include Sybil nodes.

[0020] In an embodiment, the vouched amount of tokens may be locked for a predefined amount of time.

[0021] In an embodiment, the blockchain may be an Ethereum-based blockchain.

[0022] According to an aspect of the present disclosure, a computer program product is presented. The computer program product, when executed by one or more processors, may include instructions for performing the computer-implemented method having one or more of the above described features.

[0023] In an embodiment, the instructions may be stored in a smart contract.

[0024] According to an aspect of the present disclosure, a system is presented. The system may include a plurality of nodes and a blockchain. The blockchain may be arranged for storing a smart contract. The smart contract may include a plurality of vouching agreements between two nodes of the plurality of nodes. The two nodes may be arranged to perform the computer-implemented method having one or more of the above described features.

[0025] Brief description of the Drawings

[0026] Embodiments of the present disclosure will now be described, by way of example only, with reference to the accompanying schematic drawings in which corresponding reference symbol indicate corresponding parts, in which:

[0027] Fig. 1 shows an example embodiment of a system architecture according to an aspect of the present disclosure; Fig. 2 shows an example embodiment of a payment protocol according to an aspect of the present disclosure;

[0028] Fig. 3 shows another example embodiment of a system architecture according to an aspect of the present disclosure;

[0029] Fig. 4 shows an example embodiment of an algorithm in pseudo-code according to an aspect of the present disclosure;

[0030] Fig. 5A and Fig. 5B are graphs illustrating the effect of reputation and vouching amount on the interest rate;

[0031] Fig. 6 is an example illustrating nodes and voucher agreements operating under a Sybil attack;

[0032] Fig. 7 is an example illustrating two scenarios of nodes and voucher agreements operating under a vouching agreement attack; and

[0033] Fig. 8 is an example embodiment of a computing system for implementing certain aspects of the present technology.

[0034] The figures are intended for illustrative purposes only, and do not serve as restriction of the scope of the protection as laid down by the claims.

[0035] Detailed description

[0036] It will be readily understood that the components of the embodiments as generally described herein and illustrated in the appended figures could be arranged and designed in a wide variety of different configurations. Thus, the following more detailed description of various embodiments, as represented in the figures, is not intended to limit the scope of the present disclosure but is merely representative of various embodiments. While the various aspects of the embodiments are presented in drawings, the drawings are not necessarily drawn to scale unless specifically indicated.

[0037] The described embodiments are to be considered in all respects only as illustrative and not restrictive. The scope of the present disclosure is, therefore, indicated by the appended claims rather than by this detailed description. All changes which come within the meaning and range of equivalency of the claims are to be embraced within their scope. Reference throughout this specification to features, advantages, or similar language does not imply that all of the features and advantages that may be realized with the present disclosure should be or are in any single example of the present disclosure. Rather, language referring to the features and advantages is understood to mean that a specific feature, advantage, or characteristic described in connection with an embodiment is included in at least one embodiment of the present disclosure. Thus, discussions of the features and advantages, and similar language, throughout this specification may, but do not necessarily, refer to the same example.

[0038] Furthermore, the described features, advantages, and characteristics of the present disclosure may be combined in any suitable manner in one or more embodiments. One skilled in the relevant art will recognize, in light of the description herein, that the present disclosure may be practiced without one or more of the specific features or advantages of a particular embodiment. In other instances, additional features and advantages may be recognized in certain embodiments that may not be present in all embodiments of the present disclosure. Reference throughout this specification to "one embodiment," "an embodiment," or similar language means that a particular feature, structure, or characteristic described in connection with the indicated embodiment is included in at least one embodiment of the present disclosure. Thus, the phrases "in one embodiment," "in an embodiment," and similar language throughout this specification may, but do not necessarily, all refer to the same embodiment.

[0039] The reliance on internet connectivity for financial transactions has exposed limitations in scenarios lacking reliable internet access. Traditional offline payment methods, while practical, fall short in availability, speed, and scalability, creating a demand for robust solutions that address the digital economy’s needs. This disclosure introduces a novel offline payment system, emphasizing a reputation-based vouching mechanism that operates seamlessly without continuous internet connectivity. The framework of the present disclosure mitigates double-spending risks in offline transactions by leveraging a reputation-based loan network. The solution of the present disclosure leverages a Web of Trust (WoT) model for offline transactions, while introducing an algorithm that calculates dynamic trust scores based on transaction and vouching histories. Furthermore, the solution of the present disclosure may be used to evaluate a risk of double-spending incidents and establishes a protocol that ensures transaction integrity, authenticity, and non-repudiation without real-time internet access.

[0040] The WoT is a decentralized approach to cryptography and digital certificate management, contrasting with centralized Certificate Authorities (CAs). In a WoT, trust is built on mutual verification among users, providing a flexible and community-driven mechanism for establishing trust.

[0041] A well-known implementation of WoT is found in Pretty Good Privacy (PGP) for email encryption, leveraging a chain of trust formed through mutual public key signatures. However, WoT’s adoption was limited by its complexity, requiring manual verification of public keys and physical meetings for security, which becomes impractical at scale.

[0042] Additionally, managing trust relationships becomes challenging as the network expands. The computational aspect of a WoT involves graph-based algorithms to calculate trust, with nodes representing users and edges indicating trust connections. Addressing the intricacies of trust and distrust within these networks requires specialized or adapted algorithms, complicating the traversal and management of WoT networks.

[0043] An existing offline payment solution can be found in EuroToken. EuroToken is a proposed Central Bank Digital Currency (CBDC) designed as a digital version of the Euro. It is intended to be expandable, scalable, and secure and maintains price stability, facilitating nearly direct transfers globally and offline. Based on a blockchain accounting system, EuroToken can support both offline and online digital payments. Its prototype leverages the IPv8 protocol, showcasing the system’s potential through Android / Kotlin and Python implementations and utilizing TrustChain, a block-DAG ledger technology, with adaptations to effectively address double-spending within the system. EuroToken approaches detection of double-spending by maintaining a HyperSharded block-DAG to track transactions on users’ devices, enabling direct offline transactions without an external network connection. This design allows peer- to-peer communication over Bluetooth or NFC without internet connectivity, emphasizing the system’s offline transaction capabilities. EuroToken tries to counter double-spending by detecting chain forking, where two blocks refer to the same historic block, indicating an attempt at double-spending. The system ensures transaction finality through a network of decentralized trusted validators who confirm the absence of conflicting transactions and verify the sender’s spending ability.

[0044] Another offline payment solution can be found in Payment Channels. Payment Channels, exemplified by Bitcoin’s Lightning Network (LN), address blockchain scalability by enabling high-volume, low-latency transactions off-chain (but not offline), thus reducing the load on the blockchain. These channels utilize multi-signature transactions and lock funds in a shared wallet controlled by both parties without third- party mediation. Establishing a payment channel involves both parties committing funds to a multi-signature wallet, with transactions within the channel recorded in private commitment transactions. These transactions allow instant, private exchanges off the blockchain, possibly broadcasting the final state to the blockchain if the channel is closed. The LN operates as a network of such payment channels, facilitating payments across multiple channels without establishing new ones or relying on intermediaries. This network structure significantly cuts down the number of transactions needing blockchain confirmation and prevents the misappropriation of funds in transit through its channels.

[0045] The LN’s topology is a complex, weighted, undirected multigraph, where nodes represent participants, and edges represent payment channels. This network includes functions that map each channel to its opening and closing dates and capacity. The network is visualized as having a central hub facilitating short-hop connections among most nodes, with additional disconnected small components. This structure demonstrates a trade-off between decentralization and efficiency, with a high degree of centrality indicated by most nodes’ low connectivity. A concept known as ’bouquets’ within the LN highlights nodes that serve as central relay points, emphasizing the network’s reliance on specific nodes for efficient transaction routing.

[0046] The solution of the present disclosure is an improvement over known offline payment solutions, such as EuroToken and Payment Channels.

[0047] The present disclosure presents a novel framework for enabling reputationbased vouching for offline payments. By leveraging the principles of a WoT and integrating it with modern blockchain technology, a system is designed that allows users to conduct transactions without immediate internet connectivity, addressing the challenges of traditional online and offline payment methods. The approach of the present disclosure emphasizes the importance of trust and reputation within a decentralized network, providing a robust mechanism against the risk of doublespending and enhancing transaction security.

[0048] By implementing a smart contract and a sophisticated algorithm for managing vouching agreements, the system of the present disclosure can handle offline transactions efficiently while maintaining the integrity of the network. The introduction of an incentives model further ensures active participation and cooperation among nodes, fostering a healthy ecosystem. The system is scalable and can adapt to varying-sized networks with minimal computational overhead.

[0049] The system of the present disclosure operates within a decentralized network encompassing many devices, including those with intermittent internet connectivity. It is assumed that nodes within this network can communicate directly with each other online and can enter into vouching agreements. The vouching agreements validated and recorded on a blockchain and may be appended into a single smart contract. The network is designed to support dynamic connectivity, allowing nodes to seamlessly transition between online and offline states without disrupting the overall flow of transactions.

[0050] Furthermore, the system of the present disclosure revolves around two main components: a blockchain with a deployed smart contract including vouching agreements, and the nodes participating in transactions. When online, nodes interact with the blockchain to establish vouching agreements via the smart contract; these agreements are essential for facilitating offline transactions, as they specify the terms under which one node can vouch for another, including the amount, duration, and conditions for repayment. Once a node makes an offline transaction and does not have the funds to cover the costs, the smart contract will look at the vouching agreements made with the node to cover it and pay the corresponding nodes back.

[0051] In an example embodiment of the present disclosure, a system may encompass different actors, such as regular nodes, malicious nodes, and central authorities, each engaging with a platform of the system distinctively. Regular nodes are the foundation of the network, conducting transactions and contributing to the system’s integrity through participation and compliance with the established protocols. Malicious nodes, on the other hand, represent the adversarial elements within the network, seeking to exploit vulnerabilities for personal gain, such as through double-spending and Sybil attacks. Central authorities, while not directly involved in the decentralized aspect of the network, may provide oversight or regulatory compliance to maintain trust within the system and allow for a more centralized usage of the system.

[0052] Various adversarial behaviors in the design of the system may be accounted for. For example, adversaries may attempt to double-spend and perform Sybil attacks to abuse the network and gain a monetary advantage. In an example embodiment, the system may implement several defense mechanisms to counteract such threats, including cryptographic signing of transactions, a robust reputation system, and / or a secure smart contract protocol. The reputation system, in particular, may play a crucial role in mitigating the impact of malicious nodes by limiting their ability to influence the network or benefit from fraudulent activities negatively.

[0053] Fig. 1 showcases an example embodiment of a system’s 100 high-level architecture, showing how a connection is formed between online nodes 120, offline nodes 130, smart contract 104 and a blockchain 106. The online and offline nodes may include one or more regular nodes 122, 132, one or more malicious nodes 124, 134 and / or one or more central authority nodes 126, 136. The plurality of nodes together form the nodes of actors (also referred to as parties) 102 participating to the system 100. The blockchain 106 is shown including a chain of blocks 160. Nodes may enter into vouching agreements while online by setting up agreements depicted by action {2}. Thus, vouching agreements 140 may be registered in a smart contract 104. Nodes may then proceed to conduct transactions when offline, depicted by action {6}, or when online, depicted by action {4}, relying on the trust established by these agreements 140. Once a node 132-136 reconnects to the network, the transactions made offline are reconciled, depicted by action {8}, with the blockchain 106, ensuring that all parties 102 are fairly compensated according to the terms of their agreements 140 and adjusting reputation scores.

[0054] The system 100 employs a concise and practical approach to calculating node reputation, i.e., that of the nodes 122-126, 132-136, by integrating a Sybil tolerant reputation system with a decentralized ledger mechanism.

[0055] A Sybil tolerant reputation system employs a decentralized approach where peers within a network actively observe and evaluate each other’s contributions, which are recorded in a local log. This process may be conceptualized within a directed feedback graph, where the peers are represented as nodes, and the weighted edges are the feedback accumulated over time between peers. The system assigns reputation scores to each node based on aggregated feedback, utilizing epochs to capture the dynamic nature of contributions. This combination evaluates both the quantity and quality of node interactions, where the ledger meticulously tracks each node’s successful and failed transactions. By focusing on the nature of failed transactions, this model discerns each node’s risk to the network. This ensures that reputation scores are based on transaction volume and reflect nodes’ actual reliability and trustworthiness, accommodating failures beyond their control and providing a transparent, secure basis for trust assessment within the network.

[0056] The system 100, by combining such Sybil tolerant reputation system with a decentralized ledger mechanism, evaluates both the quantity and quality of node interactions, where the ledger meticulously tracks each node’s successful and failed transactions. By focusing on the nature of failed transactions, the model of the present disclosure discerns each node’s risk to the network. This ensures that reputation scores are based on transaction volume and reflect nodes’ actual reliability and trustworthiness, accommodating failures beyond their control and providing a transparent, secure basis for trust assessment within the network.

[0057] In the system 100, the smart contract 104 is a foundational tool for establishing trust and facilitating transactions without immediate payment in an automated way. The smart contract 104 may include multiple vouching agreements 140 binding between nodes, which may be crucial for the integrity and functionality of the network. In the example of Fig. 1 , the vouching agreement is shown to be binding between two nodes depicted “A” and “B”, which are two nodes from the parties 102. More than two nodes may be included in the vouching agreement, with all nodes of the vouching agreement vouching for another node. All of the agreements 140 between nodes may be established into a single smart contract 104, which helps distribute the fees for opening and maintaining the main contract to all parties in the network.

[0058] In an example embodiment, a vouching agreement 140 for use in a system 100 may include one or more of the data fields shown in Table 1 below.

[0059] Table 1: Example of data fields in a vouching agreement 140

[0060] Creating {2} a vouching agreement 140 is a bilateral process, with one node (also referred to as the voucher) proposing a vouching contract to another node (also referred to as the vouchee). This agreement 140 is created in a block 160 with a predetermined opening time, which allows nodes of the parties 102 to decide whether or not to consider it in their confidence computation. Upon acceptance by the vouchee, the agreement 140 becomes binding and is stored within the smart contract 104. This mutual agreement initiates a token-locking mechanism for the agreed amount. Should the vouchee reject the proposal, the agreement 140 is nullified, and any locked tokens are released back to the voucher. This ensures that all parties 102 have a clear understanding and agreement before committing. Once this agreement 140 has been made, the vouchee can use these vouched tokens in scenarios where the balance is insufficient and utilize these tokens in an offline payment setting.

[0061] An important feature of the smart contract 104 is the token locking mechanism, which may be crucial for the execution and enforcement of vouching agreements 140. This mechanism ensures that tokens committed by a voucher are inaccessible, thereby guaranteeing the availability of funds for the vouched transactions. For instance, if node A of voucher agreement 140, holding a balance of 100 tokens, vouches 50 tokens for node B, node A’s effective balance remains at 100 tokens, yet only 50 are freely usable. On the contrary, node B, initially with 0 tokens, gains the ability to have the smart contract collect the 50 vouched tokens from node A for offline transactions within the network. The token locking mechanism may counteract a Sybil attack.

[0062] When nodes 132-136 re-establish online connectivity, the reconciliation process {8} may be essential for updating the blockchain 106 with all offline transactions and ensuring all parties 102 are accurately compensated. Upon reconnecting to the blockchain 106, nodes reconcile {8} offline transactions with the main network. This process involves updating the blockchain 106 with all offline transactions while the node has been disconnected. To facilitate this, the smart contract 104 goes through the vouching agreements 140 to claim the balance from the vouchers based on the offline transactions conducted and pay back the nodes on the receiving end. Furthermore, the vouching agreement 140 is set to inactive, and the smart contract 104 may automatically initiate the repayment process for the corresponding agreements 140. This requires the vouchee to pay back the voucher nodes for their vouched amount, and the accrued interest rate within a predetermined payback window. After this amount has been paid back, the allocation mechanism will alter reputation scores of the agreement parties.

[0063] In an embodiment of the present disclosure, the token locking mechanism may be governed by a method 200 implementing a payment protocol, such as shown in Fig. 2. In the example of Fig. 2, four nodes are involved in transactions on a blockchain 106: a first node referred to as Alice, a second node referred to as Bob, a third node referred to as Charlie, and a fourth node referred to as Bank. Alice, Bob and Charlie are examples of nodes 122, 124, 132, 134. The Bank is an example of a central authority node 126, 136. Also shown is the smart contract (SC). It will be understood that other nodes may be involved and that all token values, including fees and interest, are non-limiting examples.

[0064] In step 210, the parties 102 are online. In step 212 all parties 102 make sure that they have the latest state of the blockchain 106. Alice then has 100 tokens (T:100) and a reputation score of 0.8 (R:0.8). Bob then has 10 tokens (T:10) and a reputation score of 0.6 (R:0.6). Charlie then has 50 tokens (T:50) and a reputation score of 0.3. The Bank then has 100000 tokens (T:100,000) and a maximum reputation score of 1 (R:1).

[0065] In step 214, a voucher agreement 140 is set up {2} between Alice and Bob, with Alice (voucher) vouching 20 tokens to Bob (vouchee). The fee price (also referred to as token fee) is 2 tokens. In step 216 the tokens from Alice are locked and the fee price is paid by Alice and Bob, resulting in Alice having a usable balance of 78 tokens (T:78) and a total balance of 98 tokens, and Bob having 8 tokens (T:8) available. Reputation scores are not changed.

[0066] In step 220, one or more parties 102 are offline. In particular, Bob is offline. In step 222, Bob performs an offline transaction of 20 tokens (i.e., the transaction tokens) with Charlie. Bob does not have enough tokens (i.e., Bob only has 8 tokens) and will therefore use the vouched tokens from Alice.

[0067] In step 224, Bob claims Alice’s vouched tokens, resulting in step 226 of the smart contract (SC) claiming Alice’s vouched tokens for Charlie. Fees are to be paid (i.e., the fee price of 2 tokens) by Bob. Furthermore an interest rate may be payable to Alice, in this example an interest rate of 5 tokens. The interest is preferably paid when the vouched tokens are locked.

[0068] In step 228, Bob pays Charlie the 20 tokens via the smart contract (voucher), resulting in step 228 of Bob having 8-2 = 6 tokens (T:6) and Charlie having 50+20 = 70 tokens (T:70). Reputation scores are not changed.

[0069] In steps 230 and 240, the parties are online again and offline transactions are processed in the blockchain. Note that the parties need not be online at the same time; online transactions may be performed by any node whenever that node is online. There are two scenarios: Bob does not pay Alice back in step 230 or Bob pays Alice back in step 240.

[0070] In step 230, the steps are shown for when Bob does not pay back Alice.

[0071] In step 232, all transactions get reconciled {8} to the blockchain 106.

[0072] In step 234, Bob does not pay Alice back. There may be a repayment period within which Bob has to pay Alice back, which, upon expiring, also results in the determination that Bob does not pay back Alice. At this point in time, Alice still has 78 tokens (T:78) and a reputation score of 0.8 (R:0.8) and Bob still has 6 tokens (T :6) and a reputation score of 0.6 (R:0.6).

[0073] In step 236, the smart contract (SC) may find another vouching agreement with Bob, which may be used to settle the pay back of the vouched tokens, resulting in Alice’s tokens being increased to 78+20 = 98 (T:98). In a worst case scenario, there is no other vouching agreement with Bob and Alice’s amount of tokens cannot be increased with the vouched token amount to Bob.

[0074] As a result of not paying back Alice under the current vouching agreement, in step 238, Bob’s reputation decreases when deemed guilty by the system. The reputation score of Bob then decreases to, e.g., 0.5 (R:0.5). The lower reputation score will have an impact on future, other voucher agreements with any node, as will be further explained. In step 240, the steps are shown for when Bob pays back Alice.

[0075] In step 242, all transactions get reconciled {8} to the blockchain 106.

[0076] In step 243, Bob buys 100 tokens with FIAT from the Bank.

[0077] As a result, in step 244, the Bank’s and Bob’s tokens are updated, resulting in Bob having 106 tokens (T:106). At this step, the reputation scores are unchanged.

[0078] In step 246, Bob clears his dept with Alice by paying back the vouched tokens including the interest rate. I.e., 20+5 = 25 tokens are paid by Bob to Alice under the vouching agreement 140.

[0079] As a result, in step 248, Alice’s and Bob’s tokens and reputation scores are adjusted. Bob now has 106-25 = 81 tokens (T:81) and Alice now has 78+25 = 103 tokens (T: 103). The reputation scores are increased, e.g., by 0.1 , to 0.61 for Bob (R:0.61) and 0.81 for Alice (R:0.81). The higher reputation score will have an impact on future, other voucher agreements with any node, as will be further explained.

[0080] Fig. 3 shows an alternative view of the high-level architecture of the system 100, focusing on the nodes of Alice (depicted user A), Bob (depicted user B), Charlie (depicted user C) and the Bank (depicted Bank), corresponding to the example of Fig. 2. In the example of Fig. 3, before going offline, users must have a local copy of the blockchain 106 to access important data, such as reputation scores and vouching agreements 140, from their transacting partner to get a probabilistic guarantee that they will be able to pay. A vouching agreement 140 need not be directly active once it is registered on the blockchain 106; it may require a minimum opening time before becoming active. This may be implemented to mitigate some possible attacks. Vouched tokens may be locked directly once the vouching agreement 140 has been made. Preferably, a vouching agreement 140 is not indefinitely active. It may expire after a certain amount of time (blocks) if it is not used. Once an offline payment has occurred (see step (2) in Fig. 3), whenever User C regains internet connectivity, they may register that the payment has occurred. Then, the smart contract 104 may go through the vouching agreements 140 of User A and pseudo-randomly select a vouching agreement 140 to cover the transaction cost. This randomness may be determined by several factors, such as the public keys from the user, the current block timestamp, and, e.g., a RANDAO beacon value. RANDAO is a protocol on Ethereum that allows multiple participants to collaboratively generate a random number while preventing any single participant from influencing the outcome. Note that the present disclosure is not limited to Ethereum; Ethereum is mentioned as a non-limiting example of a blockchain. After the payment has been successfully registered, the repayment procedure is started and User A will need to repay the vouched amount plus possibly the interest rate. If this is also successfully repaid, the vouching agreement may be closed and the reputations of all parties will be adjusted accordingly.

[0081] In an embodiment, the payment protocol 200 may be implemented by an algorithm, which aims at estimating the amount a node would be able to pay, either directly or with the help of the nodes that vouched for it (possibly recursively). Based on its estimation a node can decide to accept or decline a payment. Exhaustively searching through all possible combinations from non-paying nodes and their predecessors is an intensive task. However, instead of this computationally heavy task a random walk simulation may be used to go through possible network paths randomly, while lowering the computation complexity. This simulation provides a distribution of the maximum amounts a paying node can transact with the help of its vouching predecessors. The randomized walk may only go through edges once but can come across the same node multiple times. The algorithm will stop unnecessary predecessor look-ups once the random walk amount has equaled or surpassed the transaction amount.

[0082] With recursive vouches, when a node is not able to pay an offline transaction, the smart contract 104 may look into the network of currently active vouching agreements 140 to execute the payment. An example of a recursive random walk algorithm 400 is shown in Fig. 4, where the algorithm 400 is presented in pseudocode. Algorithm 400 initiates by appending the identity (ID) of the current node to the existing path, thereby initializing the current exploration. It assesses whether the current node will fulfill its vouch based on its reputation, employing a weighted coin toss to simulate the decision process. The algorithm 400 immediately returns the vouched amount if the node opts to pay. Conversely, if the node declines to pay, the algorithm sets the collected amount to zero. It proceeds to explore the node’s predecessors, implementing two key optimizations to enhance transaction performance and accuracy.

[0083] A first optimization introduces a decay factor as the exploration diverges from the root node, reducing each predecessor’s reputation to mirror the real-world dynamics where the impact or reliability of a node decreases as the distance from the source increases. This concept is drawn from observations in social and financial networks, where trust or credibility diminishes over distance, thereby ensuring that nodes further away from the original point have lesser influence on the outcome.

[0084] For a second optimization, the algorithm 400 sets a maximum distance threshold for considering vouching nodes. This limitation acknowledges the diminishing nature of direct trust with increased distance, directing the focus towards nearer, more dependable nodes for transaction endorsement.

[0085] To avoid cycles, the algorithm 400 keeps track of previously visited edges and iterates through the predecessors during a random walk, ensuring no self-references and only considering nodes that are not the root. For each valid predecessor, it recursively applies itself, accumulating the vouched amounts. The process persists until all valid paths are explored, returning the total collected amount. Additionally, the algorithm can halt prematurely if the accumulated vouched amount surpasses the required transaction amount or if the maximum hop distance is reached, optimizing efficiency and relevance in the network’s context.

[0086] Mathematical, the algorithm 400 may be represented as follows:

[0087] - / j denote the current node

[0088] - \ / i denote the vouched amount associated with the edge leading to the current

[0089] Node

[0090] - F?( / Vj) denote the reputation of node Ni, which is a value [0, 1] G R (R being the real numbers)

[0091] - D denotes the decay parameter, which is a fixed value between [0, 1] e R

[0092] - H denotes the maximum hop distance, starting at 0, which increases as we hop to the next predecessor of the root node. This value can be fixed to any positive value to indicate the maximum distance allowed.

[0093] - P( / Vj) denote the predecessor nodes of N,

[0094] - Ni) denote the edge from node Nj to N, with a vouched amount. We will define this as E for readability

[0095] - S denotes a set of visited edges. After each visit, an edge E will be added to this set. This set will reset for each iteration of a random walk

[0096] The recursive formula for the amount A collected in a random walk starting from a root node N is then defined as:

[0097] When the random walk is called on the root node Nhthe node that initializes the transaction, there is a probability R( / Vj) that the node will be able to pay, based on its reputation. If the node pays, the function returns the vouched amount \ / j associated with the edge leading to this node, and the recursion will stop. If the node does not pay, which happens with probability 1 - R( / Vj), the function will recursively call itself for each predecessor node / j of A / j. The vouched amount of V(E) associated with each outgoing edge E is passed as an argument to these recursive calls. The function then sums up the amounts returned by these recursive calls, indicating the vouches of the nodes in a randomly selected path. We stop the random walk once the collected amount equals or surpasses the transaction amount.

[0098] In the system 100, nodes can vouch for others, committing a portion of their resources (i.e., tokens) or reputation to support another node. This vouching mechanism fosters trust and is structured similarly to a loan, where the node receiving the vouch typically repays the amount with interest. The interest rate for a vouching agreement 140 may be determined by several factors, including the amount vouched, the duration the vouch remains active and unused, and / or the vouching node’s reputation.

[0099] In an embodiment, the interest rate may be such to encourage participation, discourage malicious behavior, and fairly compensate for risks. In an example, the interest may be defined as follows:

[0100] Herein:

[0101] - I denotes the interest rate with the required input parameters.

[0102] - a denotes the amount vouched.

[0103] - / 3 denotes the vouched percentage rate, which will be used as a power of the a value. / 3 is for example set at 0.75.

[0104] - y denotes the time active and unused by the transacting node in days of the agreement. This activity will gain interest, e.g., every 24 hours. - 5 denotes the annual percentage rate, which will multiply with the y value. 5 is for example set at 5.

[0105] - R denotes the reputation of the transacting node. If reputation is high, we will see a steep increase in the reputation influence function, resulting in a higher interest rate. However, if reputation is lower than the midpoint factor, we will see a drastic decrease in the possible interest rate.

[0106] - Ro denotes the penalizing midpoint constant. This is for example set at 0.5.

[0107] - denotes the steepness factor for the sigmoid function.

[0108] This formula for calculating the interest integrates a reputation influence function to ensure that higher reputation nodes are favored and to prevent exploitation by low- reputation (Sybil) nodes.

[0109] The impact of reputation and the amount vouched on the interest rate is illustrated in Fig 5A and Fig. 5B. Fig. 5A shows an example of how interest rates (y- axis) may vary with reputation (x-axis), highlighting the benefits of maintaining a high reputation. Fig. 5B shows an example of the interest rates (y-axis) for different vouched amounts (x-axis), underlining the incentive for nodes to engage in the vouching process.

[0110] This approach incentivizes nodes to participate in the vouching process and aligns with the principle of locking funds to ensure transaction reliability.

[0111] The system 100 may incorporate the Sybil tolerant way MeritRank computes reputation scores for the nodes in the network. MeritRank enhances Sybil tolerance through three essential modifications in the form of bounds. A parallel report bound addresses vulnerabilities to parallel and cycle attacks limiting the total reputation across all involved Sybil nodes to most that of the first introduced Sybil node.

[0112] The serial report bound prevents the indefinite reputation inflation from serial attacks by capping the total reputation gain from sequentially added Sybil nodes. Finally, the transitivity bound ensures reputation propagation does not exceed the minimum reputation among all nodes on a given path, thereby preventing artificial reputation amplification and reflecting genuine node trustworthiness.

[0113] MeritRank implements decay strategies to enhance Sybil tolerance in networks. It uses an alpha decay parameter to limit reputation score propagation, curbing the influence of fake node chains by reducing the length of influence paths. The beta decay parameter counters structural vulnerabilities by penalizing nodes connected through bridge connections, identified by a significant flow of random walks through a cut vertex. Finally, the gamma decay parameter combats outdated connection exploitation by diminishing the benefits of old attack edges, requiring continuous effort for reputation upkeep. These strategies include transitivity limitation, connectivity penalties, and epoch-based adjustments to strengthen network security.

[0114] Fig. 5 is an example of a Sybil attack which utilizes multiple Sybil nodes and vouching agreements to increase their maximum vouching amount, when in reality they only have a low amount. Horizontal arrows between Sybil nodes SI-SY are transactions. The arrows between Sybil nodes SI-SY and C represents vouches. Sybil nodes in the network can abuse the vouching agreement in our system for their benefit. Fig. 5 shows a possible attack when there are x Sybil nodes, and one Sybil node sets up a vouching agreement with a vouching balance of x tokens. Sybil nodes can continuously vouch for an honest node for a balance x and then send that balance to another Sybil node in order to have a faked vouching total. These nodes can then all vouch for the correct node they want to attack. This would mean that the correct node C would assume it could use all the vouches, x*y tokens, of all the nodes that are vouching for it. However, the balance of the initial Sybil node’s vouching agreement was only x tokens, which means that the C could only use x tokens.

[0115] Nevertheless, since the system 100 is based on reputation, we can assume that these Sybil nodes will have a low reputation and will not be the ideal transaction partner for payment. That way, C will be able to know not to set up a vouching agreement with these nodes. This particular attack can also be considered as a synchronization issue. The core issue arises from the time discrepancy between the moment Sybil nodes initiate vouching with inflated balances and the point at which the network recognizes these balances as invalid due to insufficient funds. This time gap creates an environment where a correct node may be misled into overestimating its available vouching tokens.

[0116] This issue may be solved by only allowing nodes to accept a vouching agreement from another party for an amount that has not been used before in any vouching contracts. Furthermore, with the help of the token locking mechanism, the vouched amount may be locked for a particular amount of time, which makes it impossible for the Sybil node to continue transferring its tokens to its Sybil nodes. Another possible vouching agreement attack is creating multiple Sybil nodes, which all vouch for a node for a fraction of a larger transaction amount. This may give the node that is vouched for the possibility of picking smaller nodes to pay a lower interest rate for the vouched tokens instead of one node that vouches the entire amount at once. Moreover, it provides less risk as more nodes that can pay a part of the transaction amount are available instead of relying on only one node. Fig. 8 shows an example of two possible scenarios. The first scenario A, which can occur, is where two correct nodes C1 and C2 are engaging in a vouching agreement. For scenario B, we have the Sybil nodes voting for the same correct node for the same vouching amount as C2, with them having fractions of the amount and reputation. For the correct node, scenario B is the most enticing as it will have to pay less interest rate and has more nodes that it can rely on, meaning less risk.

[0117] The amount taken into account during the random walk is the reputation times the vouched amount per node. Suppose the vouched amount is split among Sybil nodes. In that case, the risk-reward benefit may only be applicable once the reputation of the Sybil nodes is equal to the original vouching node. Reputation systems make these attacks difficult because Sybil nodes are detected and given a lower reputation.

[0118] In a system 100 where the influence of a node 122-136 on a vouching agreement 140 is determined by the product of its reputation and its vouched amount, splitting this amount among several Sybil nodes, each with a fraction of the original node’s reputation, does not yield a greater total influence, assuming a well-functioning reputation system that penalizes Sybil nodes.

[0119] The system 100 may be built on any suitable blockchain technology. For example, the smart contract 140 may be created using Ethereum’s Solidity programming language.

[0120] Fig. 8 shows an example embodiment of a computing system 800 for implementing certain aspects of the present technology. In various examples, the computing system 800 may be any computing device making up any part of the system architecture 100, such as any one of the nodes 122-136, or any other computing system described herein.

[0121] In some implementations, a computing system 800 may implement the methods described herein, such as method 200 of the present disclosure. The computing system 800 may include any component of a computing system described herein, which components may be in communication with each other using connection 805. The connection 805 may be a physical connection via a bus, or a direct connection into processor 810, such as in a chipset architecture. The connection 805 may also be a virtual connection, networked connection, or logical connection.

[0122] In some implementations, the computing system 800 may be a distributed system in which the functions described in this disclosure may be distributed within a datacenter, multiple datacenters, a peer network, etc. In some embodiments, one or more of the described system components represents many such components each performing some or all of the functions for which the component is described. In some embodiments, the components may be physical or virtual devices.

[0123] The example system 800 includes at least one processing unit (CPU or processor) 810 and a connection 805 that couples various system components including system memory 815, such as read-only memory (ROM) 820 and randomaccess memory (RAM) 825 to processor 810. The computing system 800 may include a cache of high-speed memory 812 connected directly with, in close proximity to, or integrated as part of the processor 810.

[0124] The processor 810 may include any general-purpose processor and a hardware service or software service, such as services 832, 834, and 836 stored in storage device 830, configured to control the processor 810 as well as a special-purpose processor where software instructions are incorporated into the actual processor design. The processor 810 may essentially be a completely self-contained computing system, containing multiple cores or processors, a bus, memory controller, cache, etc. A multi-core processor may be symmetric or asymmetric.

[0125] To enable user interaction, the computing system 800 may include an input device 845, which may represent any number of input mechanisms, such as a microphone for speech, a touch-sensitive screen for gesture or graphical input, keyboard, mouse, motion input, speech, etc. The computing system 800 may also include an output device 835, which may be one or more of a number of output mechanisms known to those of skill in the art. In some instances, multimodal systems may enable a user to provide multiple types of input / output to communicate with the computing system 800. The computing system 800 may include a communications interface 840, which may generally govern and manage the user input and system output. There is no restriction on operating on any particular hardware arrangement, and therefore the basic features here may easily be substituted for improved hardware or firmware arrangements as they are developed.

[0126] A storage device 830 may be a non-volatile memory device and may be a hard disk or other types of computer readable media which may store data that are accessible by a computer, such as magnetic cassettes, flash memory cards, solid state memory devices, digital versatile disks, cartridges, random access memories (RAMs), read-only memory (ROM), and / or some combination of these devices.

[0127] The storage device 830 may include software services, servers, services, etc., that, when the code that defines such software is executed by the processor 810, causes the system to perform a function. In some embodiments, a hardware service that performs a particular function may include a software component stored in a computer-readable medium in connection with the necessary hardware components, such as processor 810, connection 805, output device 835, etc., to carry out the function.

[0128] Other variations to the disclosed embodiments can be understood and effected by those skilled in the art in practicing the claimed invention, from a study of the drawings, the disclosure and the appended claims. In the claims, the word “comprising” does not exclude other elements or steps, and the indefinite article “a” or “an” does not exclude a plurality. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage. Any reference signs in the claims should not be construed as limiting the scope thereof.

Claims

CLAIMS1. A computer-implemented method (200) for offline payments between a plurality of nodes (102), the method comprising: setting up (214, {2}) a vouching agreement (140) between a first node (122) of the plurality of nodes (102) and a second node (122) of the plurality of nodes (102), wherein the vouching agreement (140) is stored in a smart contract (104) of a blockchain (106); the setting up of the voucher agreement comprises locking (216) a vouched amount of tokens at the first node (122) for use by the second node (122); performing (220) an offline transaction between the second node (132) and a third node (122, 132) of the plurality of nodes (102), wherein the offline transaction exceeds a second amount of tokens available to the second node; while offline, the second node (132) using the vouched amount of tokens to perform the offline transaction with the third node; when online again, the second node (122, 132) reconciling (230, 240, {8}) the vouched amount of tokens with the first node, wherein: if the second node (124) does not pay back the vouched amount of tokens to the first node, decreasing a reputation score of the second node (124) and storing the decreased reputation score in the blockchain 106; or if the second node (122) pays back the vouched amount of tokens to the first node, increasing a reputation score of the first node and increasing a reputation score of the second node and storing the increased reputation score of the first node and the reputation score of the second node in the blockchain 106.

2. The method according to claim 1 , wherein setting up (214, {2}) the vouching agreement (140) between the first node and the second node when the first node and the second node are online (210), wherein the first node vouches the vouched amount of tokens to the second node by storing data representative of the vouched amount of tokens in the vouching agreement (140), wherein the vouching agreement (140) is a data record stored in the smart contract (104), the method comprising:updating (216) a first amount of tokens available to the first node by locking the vouched amount of tokens and subtracting a token fee from the first amount of tokens, the updating (216) further comprising updating a second amount of tokens available to the second node by subtracting the token fee from the second amount of tokens; when the second node (132) is offline (220), performing (222) the offline transaction (220, {6}) for an amount of transaction tokens between the second node (132) and the third node (122, 132) and, if the second amount of tokens is insufficient for the offline transaction, the second node claiming (224) the vouched amount of tokens from the first node and updating (226) the second amount of tokens available to the second node by adding the vouched amount of tokens to and subtracting the token fee from the second amount of tokens, and updating (228) the third amount of tokens available to the third node by adding the amount of transaction tokens to the third amount of tokens; when the second node is online (230, 240) after performing the offline transaction (220, {6}): if the second node (124) does not pay back the vouched amount of tokens to the first node, decreasing the reputation score of the second node (124) to obtain an updated reputation score of the second node and storing data representative of the updated reputation score in the blockchain (106); or if the second node (122) pays back the vouched amount of tokens to the first node, increasing the reputation score of the first node and increasing the reputation score of the second node (122) to obtain an updated reputation score of the first and second node and storing data representative of the updated reputation scores in the blockchain (106).

3. The method according to claim 1 or claim 2, wherein, if the second node (122) pays back the vouched amount of tokens to the first node, the method further comprises performing a FIAT transaction between a Bank node (126) and the second node (122) to increase the second amount of tokens, and wherein the second node (122) pays back the vouched amount of tokens by deducting the vouched amount of tokens from the second amount of tokens and adding the vouched amount of tokens to the first amount of tokens.

4. The method according to any one of the preceding claims, wherein, if the second node (122) pays back the vouched amount of tokens to the first node, an interest in the form of tokens is added to the amount of tokens to pay back to the first node, and wherein the interest depends on the reputation score of the second node.

5. A computer-implemented method (200) at a second node (122) for offline payments, the method comprising: setting up (214, {2}) a vouching agreement (140) with a first node (122) of a plurality of nodes (102), wherein the vouching agreement (140) is stored in a smart contract (104) of a blockchain (106) and results in locking (216) a vouched amount of tokens at the first node (122) for use by the second node (122); performing (220) an offline transaction with a third node (122, 132) of the plurality of nodes (102), wherein the offline transaction exceeds a second amount of tokens available to the second node; while offline, the second node (132) using the vouched amount of tokens to perform the offline transaction with the third node; when online again, the second node (122, 132) reconciling (230, 240, {8}) the vouched amount of tokens with the first node, wherein: if the second node (124) does not pay back the vouched amount of tokens to the first node, decreasing a reputation score of the second node (124) and storing the decreased reputation score in the blockchain 106; or if the second node (122) pays back the vouched amount of tokens to the first node, increasing a reputation score of the second node and storing the increased reputation score of the second node in the blockchain 106.

6. The method according to claim 5, wherein setting up (214, {2}) the vouching agreement (140) with the first node when the first node is online (210), wherein the vouching agreement (140) is a data record stored in the smart contract (104), the method comprising:the updating (216) further comprising updating a second amount of tokens available to the second node by subtracting a token fee from the second amount of tokens; when the second node (132) is offline (220), performing (222) the offline transaction (220, {6}) for an amount of transaction tokens between the second node (132) and the third node (122, 132) and, if the second amount of tokens is insufficient for the offline transaction, the second node claiming (224) the vouched amount of tokens from the first node and updating (226) the second amount of tokens available to the second node by adding the vouched amount of tokens to and subtracting the token fee from the second amount of tokens; when the second node is online (230, 240) after performing the offline transaction (220, {6}): if the second node (124) does not pay back the vouched amount of tokens to the first node, decreasing the reputation score of the second node (124) to obtain an updated reputation score of the second node and storing data representative of the updated reputation score in the blockchain (106); or if the second node (122) pays back the vouched amount of tokens to the first node, increasing the reputation score of the second node (122) to obtain an updated reputation score of the second node and storing data representative of the updated reputation score in the blockchain (106).

7. The method according to claim 5 or claim 6, wherein, if the second node (122) pays back the vouched amount of tokens to the first node, the method further comprises performing a FIAT transaction with a Bank node (126) to increase the second amount of tokens, and wherein the second node (122) pays back the vouched amount of tokens by deducting the vouched amount of tokens from the second amount of tokens and adding the vouched amount of tokens to the first amount of tokens.

8. The method according to any one of the claims 5-7, wherein, if the second node (122) pays back the vouched amount of tokens to the first node, an interest in the form of tokens is added to the amount of tokens to pay back to the first node,and wherein the interest depends on the reputation score of the second node.

9. The method according to any one of the preceding claims, wherein, if the second node (122) cannot pay back the vouched amount of tokens to the first node, the method further comprises determining if another vouching agreement exists between any one of the plurality of nodes (102) and the second node (122), possibly recursively, to execute the pay back of the vouched amount of tokens to the first node.

10. The method according to claim any one of the preceding claims, wherein the reputation scores are determined based on a MeritRank enhanced Sybil tolerance.

11. The method according to claim 10, wherein the plurality of nodes comprises Sybil nodes.

12. The method according to claim 10 or claim 11 , wherein the vouched amount of tokens is locked for a predefined amount of time.

13. The method according to any one of the preceding claims, wherein the blockchain is an Ethereum-based blockchain.

14. A computer program product, which, when executed by one or more processors, comprises instructions for performing the method according to any one of the claims 1-13.

15. The computer program product according to claim 14, wherein the instructions are stored in a smart contract (104).

16. A system (100) comprising a plurality of nodes (102) and a blockchain 106, wherein the blockchain is arranged for storing a smart contract (104) comprising a plurality of vouching agreements (140) between two nodes (122-136) of the plurality of nodes, wherein the two nodes are arranged to perform the method according to any one of the claims 1-13.

Images