Registry and automated management method for blockchain-enforced smart contracts
The invention relates to the fields of tokenisation, blockchain and smart contract technologies. It provides a technical arrangement which simplifies the automated management of contracts. The invention comprises a method and system which use a computer-based repository for storage of the contract. The contract is then represented by a transaction on the blockchain. Metadata within the transaction's script includes a hash of the contract and a means of identifying its location within the repository. The transaction also includes an unspent output (UTXO) which indicates its status as an open (ie not terminated) contract. The contract is terminated by spending the output at a later point in time, for example, using nLockTime+CheckLockTimeVerify (CLTV). By combining this concept with other techniques and computing components, the invention can provide a powerful mechanism for implementing various tasks such as renewing or rolling over the contract, or dividing it into sub-contracts or conditions. Furthermore, as the status and existence of the contract is evidence via the blockchain, this provides a permanent, publicly visible and non-alterable record of the contract.
1. A computer-implemented method of controlling visibility and/or performance of a contract, the method comprising:
(a) storing the contract on or in a computer-based repository;
(b) broadcasting a first transaction to a blockchain, the first transaction comprising:
i) at least one unspent output (UTXO); and
ii) metadata comprising an identifier indicative of a location where the contract is stored, wherein the contract is stored in a Distributed Hash Table (DHT), and wherein a hash of the contract is generated and used as a lookup key for referencing the contract from the first transaction;
(c) interpreting the contract as open or valid until the at least one unspent output (UTXO) is spent on the blockchain; and
(d) generating a sub-contract derived from the contract, wherein the sub-contract is associated with a deterministic address and is generated by:
i) using a new public key derived using a seed;
ii) storing the sub-contract in or on the computer-based repository with a reference to the contract, and broadcasting a second transaction to the blockchain comprising a script which includes the reference; and
iii) adding a reference to the sub-contract to the metadata of the contract.
2. The computer-implemented method according to claim 1 , wherein the first transaction to the blockchain further comprises a deterministic redeem script address, wherein the deterministic redeem script address is a pay-to- script-hash (P2SH) address.
3. The computer-implemented method according to claim 2 and further comprising the step of completing the contract by broadcasting a further transaction to the blockchain to spend the at least one unspent output (UTXO);
wherein the further transaction comprises:
an input which is the at least one unspent output (UTXO); and
an unlocking script comprising a signature; the metadata; and a public key.
4. The computer-implemented method according to claim 1 wherein:
i) the contract defines:
a) at least one condition; and
b) at least one action whose performance is dependent upon an evaluation of the at least one condition; and/or
ii) the metadata comprises:
a) an address, or representation of the address, of where the contract is stored in the computer-based repository; and/or
b) a hash of the contract.
5. The computer-implemented method according to claim 1 and comprising:
checking whether the contract has been terminated by determining whether the at least one unspent output (UTXO) is in a list of unspent transaction outputs for the blockchain.
6. The computer-implemented method according to claim 1 and comprising:
broadcasting a transaction to the blockchain comprising an instruction to spend the at least one unspent output (UTXO) at a specified date and/or time, wherein the instruction is a CheckLockTimeVerify instruction.
7. The computer-implemented method according to claim 1 wherein:
i) access to some or all of contents of the contract is restricted to at least one designated authorized party; and/or
ii) the contract comprises a Deterministic Finite Automaton (DFA) to implement the contract;
wherein:
the Deterministic Finite Automaton is defined using a codification scheme; and/or
the Deterministic Finite Automaton is implemented using:
i) at least one blockchain transaction, using a scripting language;
ii) a computing agent arranged to monitor a state of the blockchain; and/or
iii) a set of instructions for a digital wallet.
8. A system, comprising:
one or more processors; and
memory comprising executable instructions that, as a result of execution by the one or more processors, cause the system to:
(a) store a contract on or in a computer-based repository;
(b) broadcast a first transaction to a blockchain, the first transaction comprising:
i) at least one unspent output (UTXO); and
ii) metadata comprising a first identifier indicative of a location where the contract is stored, wherein the contract is stored in a Distributed Hash Table (DHT), and wherein a hash of the contract is generated and used as a lookup key for referencing the contract from the first transaction;
(c) interpret the contract as open or valid until the at least one unspent output (UTXO) is spent on the blockchain; and
(d) generate a sub-contract derived from the contract, wherein the sub- contract is associated with a deterministic address and is generated by:
i) using a new public key derived using a seed;
ii) storing the sub-contract in or on the computer-based repository with a reference to the contract, and broadcasting a second transaction to the blockchain comprising a script which includes the reference; and
iii) adding a reference to the sub-contract to the metadata of the contract.
9. The system of claim 8 , wherein the seed used to generate the new public key for the sub-contract is derived based at least in part on a second identifier associated with the at least one unspent output (UTXO) of the contract.
10. The system of claim 9 , wherein the first transaction to the blockchain further comprises a deterministic redeem script address, wherein the deterministic redeem script address is a pay-to-script-hash (P2SH) address.
11. The system of claim 10 , wherein the executable instructions include further instructions that, as a result of execution by the one or more processors, cause the system to further terminate the contract by broadcasting a further transaction to the blockchain to spend the at least one unspent output (UTXO).
12. The system of claim 11 , wherein the further transaction further comprises:
an input which is the at least one unspent output (UTXO); and
an unlocking script comprising a signature; the metadata; and a public key.
13. The system of claim 8 , wherein the contract defines:
i) at least one condition; and
ii) at least one action whose performance is dependent upon an evaluation of the at least one condition; and/or
wherein the metadata comprises:
i) an address or representation of the address of where the contract is stored in the computer-based repository; and/or
ii) a hash of the contract.
14. A non-transitory computer-readable storage medium storing executable instructions that, as a result of being executed by one or more processors of a computer system, cause the computer system to at least:
(a) store a contract on or in a computer-based repository;
(b) broadcast a first transaction to a blockchain, the first transaction comprising:
i) at least one unspent output (UTXO); and
ii) metadata comprising an identifier indicative of a location where the contract is stored, wherein the contract is stored in a Distributed Hash Table (DHT), and wherein a hash of the contract is generated and used as a lookup key for referencing the contract from the first transaction;
(c) interpret the contract as open or valid until the at least one unspent output (UTXO) is spent on the blockchain; and
(d) generate a sub-contract derived from the contract, wherein the sub-contract is associated with a deterministic address and is generated by:
i) using a new public key derived using a seed;
ii) storing the sub-contract in or on the computer-based repository with a reference to the contract, and broadcasting a second transaction to the blockchain comprising a script which includes the reference; and
iii) adding a reference to the sub-contract to the metadata of the contract.
15. The non-transitory computer-readable storage medium of claim 14 , wherein the seed used to generate the new public key for the sub-contract is derived based at least in part on a redeem script hash of the contract.
16. The non-transitory computer-readable storage medium of claim 14 , wherein the sub-contract is generated by further storing a list of fields from the contract.
17. The non-transitory computer-readable storage medium of claim 14 , wherein:
i) the contract is stored in a Distributed Hash Table (DHT); and/or
ii) the non-transitory computer-readable storage medium includes further instructions that, as a result of execution by the one or more processors of the computer system, further cause the computer system to:
broadcast a third transaction to the blockchain comprising an instruction to spend the at least one unspent output (UTXO) at a specified date and/or time, wherein the instruction is a ChecklockTimeVerify instruction.
18. The non-transitory computer-readable storage medium of claim 14 , wherein:
i) access to some or all contents of the contract is restricted to at least one designated authorized party; and/or
ii) the contract comprises a Deterministic Finite Automaton (DFA) to implement the contract.
19. The non-transitory computer-readable storage medium of claim 18 , wherein:
the DFA is defined using a codification scheme; and/or
the DFA is implemented using:
i) at least one fourth blockchain transaction, using a scripting language;
ii) a computing agent arranged to monitor a state of the blockchain; and/or
iii) a set of instructions for a digital wallet.