WO2020008218A1

WO2020008218A1 - Method for conditional blockchain transactions

Info

Publication number: WO2020008218A1
Application number: PCT/IB2018/000709
Authority: WO
Inventors: Giotto De Filippi
Original assignee: Chain IP Holdings, Inc.
Priority date: 2018-07-03
Filing date: 2018-07-03
Publication date: 2020-01-09

Abstract

The present invention relates to a method for executing conditional transactions in a network implementing a distributed ledger, the network comprising a plurality of transaction addresses and at least one certifying address, the method comprising the steps of: issuing a conditional transaction, by a first transaction address, wherein the conditional transaction comprises an amount and a condition, reading the conditional transaction, by the certifying address and certifying the conditional transaction, by the certifying address, with respect to a second transaction address. The invention furthermore relates to a corresponding conditional transaction.

Description

Method for conditional blockchain transactions

The present invention generally relates to a method for performing conditional transactions in a network implementing a distributed ledger. Moreover, the invention relates to the introduction of a certifying node, thanks to which conditional transactions among addresses can be executed.

Prior art

Distributed ledgers are becoming a more common technology for certifying and tracking several kinds of assets, such as cryptocurrencies, contracts, but also documents such as certifications, medical records, identify documents, etc. The distributed ledgers also provide means for recording transactions related to assets or documents. Namely modification to the asset or documents, be it a modification to its content or to its owner, can be recorded in a reliable manner by a distributed ledger.

Several kinds of distributed ledgers are available, based on different technologies, such as blockchain, Hashgraph, etc. In general they all share the common concept that the network implementing the distributed ledger comprises a plurality of transaction addresses and a plurality of ledger computing nodes. The transactions among the transaction addresses are recorded by the ledger computing nodes with a computationally intensive approach, which provides the security of the distributed ledgers with respect to brute force hacker attacks.

Figure 1 schematically illustrates a network 1000 implementing a distributed ledger in accordance with the state of the art, comprising a plurality of transaction addresses 1 10S- 1103 and a plurality of ledger computing nodes 1201-1202. The ledger computing nodes 1201 -1202 are configured to run one or more smart contracts for allowing any of the transaction addresses 1 101 -1 103 to perform several kinds of transactions which are then recorded in the distributed ledger.

In general, in distributed ledgers such as the one illustrated in figure 1 , any transaction address 1 101 -1 103 can perform transactions with any other transaction address 1 101 - 1103. A given transaction is initiated by a transaction address 1101 -1 103 and is issued, that is, rendered known, to the network 1000 or at least to the ledger computing nodes 1201 -1202 for recording into the distributed ledger. Once the transaction is recorded into the distributed ledger it cannot be modified or otherwise withdrawn. The distributed ledger is updated with a predetermined frequency. In the case of a network implementing a blockchain approach, a new block is computed with a given frequency in time.

As schematically illustrated by the arrows in figure 1 , transaction address 1 101 may issue a transaction toward any of transaction addresses 1 102, 1 103. For instance, transaction address 1 101 may decide to transfer funds from its own account to transaction address 1 102 by issuing a respective transaction. The recording of the transaction in the distributed ledger by means of the ledger computing nodes 1 101 and/or 1 102 allows the transaction to be recorded and thus complete the transfer of funds.

This approach works well in cases where the transaction address 1 101 and one knows the address of the other transaction address to which a transfer of funds is intended. However, there may be cases in which the owner of transaction address 1 101 intends to transfer funds to another person without knowing the transaction address corresponding to this other person. Moreover, there may be even cases in which the owner of transaction address 1 101 intends to transfer funds to a non-specified person for carrying out a pre defined task.

For instance, the owner of transaction address 1 101 may be a private person living in country A and seeing news on the television about an earthquake in a country B. The owner of transaction address 1 101 is thus informed that several households in country B are left without drinking water and intends to do something to help them. However, the owner of transaction address 1 101 does not know any person in country B, let alone anyone owning a transaction address within network 1000. Due to the general anonym approach of distributed ledgers, even if a person owning one of the remaining transaction addresses 1 102-1 103 of the network 1000 would actually live in country B, this information would generally not be retrievable from the network 1000.

Assuming, for instance, that a person living in country B owns transaction address 1 103, the owner of transaction address 1 101 knowing this information could transfer funds to the transaction address 1 103 via a known transfer functionality of network 1000. As mentioned above, however, it is impossible for the owner of transaction address 1 101 to know who owns the remaining transaction addresses in the network 1000.

Moreover, even if the owner of transaction address 1 101 would be able to retrieve the information concerning the ownership of transaction address 1 103, the person owning transaction address 1 103 is unknown to the person owning transaction address 1 101 and there would be no way for the person owning transaction address 1101 to ensure that the person owning transaction address 1 103 would actually use the transferred funds for the intended purpose. The owner of transaction address 1 101 would have to trust the completely unknown owner of transaction address 1 103. This requirement would severely limit the possibility to carry out such transactions.

The present invention has been developed in view of the above problems and it is an object thereof to provide a manner for allowing a transaction address 1 101 to transfer funds to an unknown transaction address within network 1000, based on a condition dictated by the transaction address 1 101 . With reference to the example above, the present invention allows transaction address 1 101 to transfer a specified amount to any transaction address who could use the funds for providing drinking water in the second country.

Summary of the invention

The present invention generally relies on the principle that an additional kind of entity can be added to the network so as to operate as a certifying address. Moreover, the invention generally provides a second kind of transaction, namely a conditional transaction.

The conditional transaction comprises an amount to be transferred, which is defined by the transaction address issuing the conditional transaction, as in a known non-conditional transaction. Moreover, the conditional transaction comprises a condition which allows the conditional transaction to be completed only if a receiving address fulfils the condition.

The certifying address operates to evaluate whether any of the transaction addresses in the network fulfils the condition. In this role, the certifying address can thus allow the transfer of the amount indicated by the transaction address ' issuing the conditional transaction toward the receiving address, without any input from the transaction address issuing the conditional transaction.

Thus the invention generally allows the transaction address issuing the conditional transaction to issue a conditional transaction for an intended purpose, which is defined by the condition. If any receiving address can be certified by the certifying address as fulfilling the condition, the transaction is completed without any further input by the transaction address issuing the conditional transaction and the funds are transferred. This is particularly advantageous as it solves at once both the trust issue, since now the issuing address only has to trust a limited, likely well known, number of certifying addresses, and the anonymity issue of the receiving addresses, since the issuing address does not need to know who the receiving address is, in order to initiate, or complete, the transaction.

In particular, an embodiment of the invention can relate to a method for executing conditional transactions in a network implementing a distributed ledger, the network comprising a plurality of transaction addresses and at least one certifying address, the method comprising the steps of: issuing a conditional transaction, by a first transaction address, wherein the conditional transaction comprises an amount and a condition, reading the conditional transaction, by the certifying address, and certifying the conditional transaction, by the certifying address, with respect to a second transaction address.

In some embodiments, the certifying step can comprise the steps of: evaluating whether the second transaction address fulfils the condition, by the certifying address, and approving the conditional transaction, by the certifying address, with respect to the second transaction address, if the evaluating step has a positive outcome.

In some embodiments, the approving step further can comprise the steps of: setting, by the certifying address, a destination address of a non-conditional transaction corresponding to the second transaction address, and issuing the non-conditional transaction .

In some embodiments, transfer of the amount from the first transaction address toward the second transaction address can be recorded in the distributed ledger only after the certifying step.

In some embodiments, transfer of the amount from the first transaction address toward the second transaction address can be recorded in the distributed ledger only after the step of issuing the non-conditional transaction.

In some embodiments, the approving step further can comprise the steps of: setting, by the certifying address, a destination address of the conditional transaction corresponding to the second transaction address, and issuing the conditional transaction. An embodiment of the invention can further relate to a data structure implementing a conditional transaction for use in a network implementing a distributed ledger, the network comprising a plurality of transaction addresses and at least one certifying address, the data structure comprising: an issuing address, an amount, and a condition associated to the transfer of the amount.

In some embodiments, the condition can be a text field, preferably of variable length, describing in words a condition which is associated to the transfer of the amount, or the condition can be a hash, which can be converted into a string of text by reference to a database. Short description of the figures

Figure 1 schematically illustrates a network 1000 implementing a distributed ledger in accordance with the state of the art;

Figure 2 schematically illustrates a network 2000 implementing a distributed ledger;

Figure 3 schematically illustrates a method 3000 for executing conditional transactions in a network implementing a distributed ledger;

Figure 4 schematically illustrates a possible implementation of certifying step S3300;

Figure 5 schematically illustrates a possible implementation of approving step S4320;

Figure 6 schematically illustrates a possible implementation of non-conditional transaction 6400 and several possible implementations of conditional transactions 6500, 6600, 6700 and 6800.

Detailed description of preferred embodiments

Figure 2 schematically illustrates a network 2000 implementing a distributed ledger in accordance with an embodiment of the invention. Although only the various elements 1 101 -1 103, 1201 -1202 and 2300 are schematically illustrated, it will be clear that those elements can be connected to each other by means of a network, such as the Internet. The interconnections are however not illustrated, for clarity of representation. The network 2000 differs from network 1000 due to the presence of certifying address 2300. Certifying address 2300 could be, in practice, implemented by any electronic equipment capable of exchanging information within network 2000, for instance, a computer. In general, certifying address 2300 is capable of exchanging information with any other elements in the network 2000, in particular with transaction addresses 1 101- 1 103. It will furthermore be clear that a plurality of certifying addresses 2300 can be present, operating as it will be described for the single certifying address 2300 below.

The presence of certifying address 2300 allows the method 3000, which is schematically illustrated in figure 3, to be implemented. More specifically, method 3000 is a method for executing conditional transactions in the network 2000 implementing a distributed ledger. The method 3000 will be discussed in details in the following. For better understanding of the method 3000, however, the structure of a conditional transaction will be described first.

Figure 6 schematically illustrates the main differences between a non-conditional transaction 6400 and a conditional transaction 6500, 6600, 6700 and 6800.

A non-conditional transaction 6400 is a data structure comprising at least an issuing address 6401 , a destination address 6402 and an amount 6403. In particular, the issuing address 6401 and the destination address 6402 are transaction addresses 1 101 -1 103 of network 2000. The amount 6403 is a numerical value which indicates an amount of funds to be transferred, for instance expressed in terms of cryptocurrency associated to the network 2000.

Conditional transaction 6500, 6600, 6700, 6800 all differ from the non-conditional transaction 6400 due to the additional presence of a condition 6504. The condition 6504 can be a text field, preferably of variable length, describing in words a condition which is associated to the transfer of the amount 6403. For instance, with reference to the example above, the condition 6504 could be formulated as“funds for supplying drinking water to households suffering from earthquake in country B”. Alternatively, in order to reduce the amount of data associated with the conditional transaction which is to be recorded in the distributed ledger, the condition 6504 could be expressed as a hash, which can then be converted into a string of text by reference to an database, possibly external to network 2000. In addition to the condition 6504, different kinds of conditional transactions can comprise further fields, which will be described below. It will be understood that those fields, while independently described with reference to a specific embodiment 6600, 6700, 6800, can be combined to result in new embodiments.

Conditional transaction 6500 comprises the issuing address 6401 , the amount 6403 and the condition 6504. Since the transaction address issuing the conditional transaction 6500, namely the issuing address 6401 does not know the address to which the amount 6403 will be transferred, in order to advantageously reduce the amount of data to be recorded in the distributed ledger, the conditional transaction 6500 does not comprise a destination address 6402. In alternative embodiments, such as the one illustrated by the conditional transaction 6600, the destination address 6402 may nevertheless be present but left empty.

Still alternatively, or in addition, conditional transaction 6700 comprises a certifying address field 6705, corresponding to one or more certifying addresses 2300 of network 2000, which are allowed by the issuing address 6401 to carry out the certifying step S3300, which will be described below. In this manner it is advantageously possible for the issuing address to limit the certifying addresses 2300 which can confirm the transfer of funds to entities which the issuing address trusts, such as the Red Cross or similar.

Still alternatively, or in addition, conditional transaction 6800 comprises a time to live field 6806, indicating the time for which the conditional transaction is valid. That is, after expiry of the time indicated in field 6806, it will not be possible to transfer the funds anymore, even in the presence of a successful certifying step S3300. In this manner it is advantageously possible for the issuing address to limit the time during which transfer of funds may occur. This not only helps the issuing address to control its liquidity, which may otherwise be difficult to plan in case of several pending conditional transactions, but also to ensure that if no one is capable of fulfilling the condition within a reasonable time, the offer to transfer funds represented by the conditional transaction will automatically expire, without any need for action by the issuing address.

It will be clear that the various formats for the conditional transaction 6500, 6600, 6700, 6800 described above can be combined by using one or more fields from one conditional transaction in combination with one or more fields from other conditional transactions, to generate new formats for yet additional conditional transactions. Figure 3 schematically illustrates a method 3000 for executing conditional transactions in a network implementing a distributed ledger. The method 3000 comprises a step S3100 of issuing a conditional transaction 6500, 6600, 6700, by a first transaction address, for instance the transaction address 1101 , wherein the conditional transaction 6500, 6600, 6700 comprises at least an amount 6403 and a condition 6504. In a further reading step

S3200 the conditional transaction 6500, 6600, 6700, is read by the certifying address 2300. Thanks to this step, the certifying address 2300 is informed of the condition 6504 four unlocking the transfer of the amount 6403.

At this point, any second transaction address 1 102, 1 103 of network 2000 which intends to receive the funds specified by the amount of 6403, can do so by providing the certifying address 2300 with proof that the second transaction address fulfills the condition 6504. In other words, in a certifying step S3300, the certifying address 2300 can certify the conditional transaction 6500, 6600, 6700, 6800, with respect to a second transaction address 1 103 fulfilling the condition 6504. In some embodiments, as illustrated in figure 4, the certifying step S3300 can comprise a step S4310 of evaluating whether the second transaction address 1 103 fulfils the condition, by the certifying address 2300 and an approving step S4320 of approving the conditional transaction 6500, 6600, 6700, 6800 by the certifying address 2300, with respect to the second transaction address 1 103, if the evaluating step S4310 has a positive outcome.

It will be clear that the certifying step S3300 can be implemented in many forms, not all of which are necessarily entirely implemented within network 2000.

For instance, with reference to the example above, the owner of second transaction address 1 103 may get in touch with the owner of certifying address 1 102 outside of the network 2000, for instance by exchanging emails or by a personal encounter, and provide the certifying address 1 102 with proof that the second transaction address 1 103 has spent funds for the condition 6504, namely, with reference to the above example, for providing drinking water to the households affected by the earthquake. This would correspond to an implementation of the evaluating step S4310. At this point, provided that the certifying address 2300 is satisfied with the results of the evaluating step S4310, the certifying address 2300 can proceed with the certifying step S3300 resulting in the transfer of the funds from the first transaction address 1 101 to the certified second transaction address 1 103 thus implementing the approving step S4320.

In some embodiments, preferable in the approving step S4320, the certifying address 1 102 can set the amount of funds to be transferred to the second transaction address 1 103. It will be clear, that the amount of funds to be transferred to the second transaction address 1 103 does not necessarily correspond to the entirety of the amount indicated in field 6403. In particular, in some embodiments, if the second transaction address 1 103 can only provide proof that the condition 6504 has been fulfilled for an amount which is lower than the amount 6403, the certifying address 2300 may proceed to certify the transaction only for the amount for which proof of fulfillment of the condition 6504 has been provided by the second transaction address 1 103.

Thanks to this approach, as schematically illustrated in figure 2, a transaction is possible between first transaction address 1 101 and second transaction address 1 103 even if the first transaction address 1 101 was not aware of the second transaction address 1 103 and, in particular, without further intervention from the first transaction address 1 101. In other words, by relying on the certifying function of the certifying address 2300, the first transaction address 1 101 can issue the conditional transaction and rest assured that the amount 6403 will be transferred to the intended recipient.

In some embodiments, the ability of identifying itself as certifying address 2300 on the network 2000 may be restricted. In particular, private persons or legal entities wishing to acquire an address on the network 2000 corresponding to a certifying address 2300 may have to prove their ability of impartially and reliably operate as a certifying agency. In some embodiments, the decision on which private persons or legal entities can operate a certifying address 2300 on network 2000 can be taken by the owner or operator of network 2000.

In some advantageous embodiments, as discussed above, in particular in the presence of a plurality of certifying addresses 2300 on network 2000, the first transaction address and may specify in the conditional transaction 6700 one or more certifying addresses 2300 in the certifying address field 6705. This is particularly advantageous as it gives to the first transaction address control over which entities the first transaction address considers reputable enough to carry out to the certifying step S3300. In some embodiments, the approving step S4320 can comprise a step S5321 of setting, by the certifying address 2300, a destination address of a non-conditional transaction 6400 corresponding to the second transaction address 1 103, and a step of issuing S5322 the non-conditional transaction 6400.

In other words, the transfer of funds from the first transaction address 1 101 to the second transaction address 1 103 can be completed by the creation of the respective can non conditional transaction 6400 by the certifying address 2300. It will be clear that the amount 6403 of the non-conditional transaction 6400 cannot exceed the amount 6403 of the conditional transaction 6500, 6600, 6700.

In this case, the distributed ledger will thus record one conditional transaction 6500, 6600, 6700, 6800 and one or more corresponding non-conditional transactions 6400. The issuing of non-conditional transactions 6400 will be possible until the sum of the amounts in the non-conditional transactions 6400 is smaller than the amount 6403 in the corresponding conditional transaction 6500, 6600, 6700, 6800.

The correspondence between the conditional transaction 6500, 6600, 6700, 6800 and the corresponding non-conditional transactions 6400 can be carried out in several manners, some of which may be known to the skilled person. For instance the conditional transaction 6500, 6600, 6700, 6800 may have an ID in the network 2000 and the non conditional transactions 6400 may comprise a field, not illustrated in figure 6, indicating the ID of the conditional transaction 6500, 6600, 6700, 6800 to which they relate.

In some embodiments, transfer of the amount from the first transaction address 1 101 toward the second transaction address 1 103 is recorded in the distributed ledger only after the certifying step S3300. That is, the conditional transaction 6500, 6600, 6700, 6800 does not result in any transfer of funds until the conditional transaction 6500, 6600, 6700, 6800 has been certified.

In some embodiments, transfer of the amount from the first transaction address 1 101 toward the second transaction address 1 103 is recorded in the distributed ledger only after the step of issuing S5322 the non-conditional transaction 6400, in particular with the recording in the distributed ledger of the non-conditional transactions 6400. Thanks to this approach, certainty on the transfer of funds can be ensured. In some embodiments, the approving step S4320 can further comprise the steps of setting S5321 , by the certifying address 2300, a destination address of the conditional transaction 6600 corresponding to the second transaction address 1 103, and issuing S5322 the conditional transaction 6600. In this case, the conditional transaction 6600 comprising a valid destination address may be recognized by the network 2000 as a non-conditional transaction and thus implement the transfer of funds upon its registration in the network. This approach provides the advantage that the certifying address 2300 does not have to fill in the issuing address and the amount, particularly in those cases where the amount of the certified conditional transaction 6600 corresponds to the amount of the conditional transaction 6600 before the certifying step.

Moreover, this is further advantageous as the condition 6504 may be used to provide a correspondence between the certified conditional transaction 6600 and the conditional transaction 6600 before the certifying step, instead of the transaction ID mentioned above. Although several embodiments have been described above, it will be clear to those skilled in the art that one or more features of any embodiment can be combined with one or more features of any embodiment so as to result in new embodiments of the invention, which is defined not by the described embodiments but rather by the claims.

List of reference numerals

Figure 1

1000: network

1 101 -1 103: transaction address

1201 -1202: ledger computing node

Figure 2

2000: network

2300: certifying address

Figure 3

3000: method for controlling transactions S3100: issuing conditional transaction S3200: reading conditional transaction S3300: certifying conditional transaction Figure 4

S4310: evaluating fulfillment of the condition S4320: approving conditional transaction Figure 5

S5321 : setting destination address

S5322: issuing non-conditional transaction Figure 6

6400: non-conditional transaction

6401 : issuing address

6402: destination address

6403: amount

6500: conditional transaction

6504: condition

6600: conditional transaction

6700: conditional transaction

6705: certifying address

6700: conditional transaction

6806: time to live

Claims

1. A method for executing conditional transactions in a network implementing a distributed ledger, the network comprising a plurality of transaction addresses and at least one certifying address, the method comprising the steps of: issuing a conditional transaction, by a first transaction address, wherein the conditional transaction comprises an amount and a condition, reading the conditional transaction, by the certifying address, and certifying the conditional transaction, by the certifying address, with respect to a second transaction address.

2. The method according to claim 1 , wherein the certifying step comprises the steps of: evaluating whether the second transaction address fulfils the condition, by the certifying address, and approving the conditional transaction, by the certifying address, with respect to the second transaction address, if the evaluating step has a positive outcome.

3. The method according to claim 2, wherein the approving step further comprises the steps of: setting, by the certifying address, a destination address of a non-conditional transaction corresponding to the second transaction address, and issuing the non-conditional transaction.

4. The method according to any previous claim, wherein transfer of the amount from the first transaction address toward the second transaction address is recorded in the distributed ledger only after the certifying step.

5. The method according to claims 3 and 4, wherein transfer of the amount from the first transaction address toward the second transaction address is recorded in the distributed ledger only after the step of issuing the non-conditional transaction.

6. The method according to claim 2, wherein the approving step further comprises the steps of: setting, by the certifying address, a destination address of the conditional transaction corresponding to the second transaction address, and issuing the conditional transaction.

7. A data structure implementing a conditional transaction for use in a network implementing a distributed ledger, the network comprising a plurality of transaction addresses and at least one certifying address, the data structure comprising: an issuing address, an amount, and a condition associated to the transfer of the amount.

8. The data structure according to claim 7, wherein the condition is a text field, preferably of variable length, describing in words a condition which is associated to the transfer of the amount, or wherein the condition is a hash, which can be converted into a string of text by reference to a database.