Distributed data recording

Abstract

Embodiments create and validate a digital record representing an asset. Embodiments obtain a first public key and a first private key corresponding to a creator of the digital record, and generate one or more parameters for the digital record, where a first parameter of the parameters corresponds to a transaction of the digital record. Embodiments generate one or more rules for the digital record, where a first rule of the rules corresponds to the first parameter and constrains the transaction. Using the first private key, embodiments compute a first digital signature of a totality of the first public key, the parameters, and the rules, and create a first digital record including the first public key, the parameters, the rules, and the first digital signature.

Description

Technical Field

[0001] One embodiment generally relates to data recording, and more specifically to distributed data recording and electronic ledgers. Background Technology

[0002] Traditionally, centralized databases track all assets, owners, transactions, etc., to monitor electronic records or contracts. Digital assets or data records, such as consumer electronics, tokens, points, currencies, titles, event tickets, credentials, coupons, etc., often require peer-to-peer transfers, enabling people to directly negotiate the transfer of ownership of assets using a trusted platform not controlled by a single party. Blockchain, including decentralized and public ledgers, offers a solution, but faces specific challenges such as high computational costs and limited storage space because many nodes must store the complete transaction history. Therefore, projects requiring significant storage space ultimately need to be centralized, rendering public blockchains completely unusable. Summary of the Invention

[0003] The embodiment creates and verifies a digital record representing an asset. The embodiment obtains a first public key and a first private key corresponding to the creator of the digital record, and generates one or more parameters for the digital record, wherein a first parameter is associated with a transaction of the digital record. The embodiment generates one or more rules for the digital record, wherein a first rule corresponds to the first parameter and constrains the transaction. Using the first private key, the embodiment computes a first digital signature of the entirety of the first public key, parameters, and rules, and creates a first digital record including the first public key, parameters, rules, and the first digital signature. Attached Figure Description

[0004] Figure 1 This is an overview diagram of the elements that can implement embodiments of the present invention.

[0005] Figure 2 This is a block diagram of a computer server / system according to an embodiment of the present invention.

[0006] Figure 3A According to one embodiment, when creating a new electronic record / digital certificate, Figure 2 The flowchart shows the functionality of the distributed data recording module.

[0007] Figure 3B According to one embodiment, when a transaction is executed with an electronic record, Figure 2 The flowchart shows the functionality of the distributed data recording module.

[0008] Figure 4 According to one embodiment, when verifying electronic records, Figure 2 The flowchart shows the functionality of the distributed data recording module.

[0009] Figure 5 According to one embodiment, when verifying electronic records using transaction rules, Figure 2 The flowchart shows the functionality of the distributed data recording module.

[0010] Figure 6 According to one embodiment, when a record is verified by a third-party validator, Figure 2 The flowchart shows the functionality of the distributed data recording module.

[0011] Figure 7 According to one embodiment, when creating a new record subject to a third-party validator with additional security, Figure 2 The flowchart shows the functionality of the distributed data recording module.

[0012] Figure 8 According to one embodiment, when parameters are split into multiple sub-records, Figure 2 The flowchart shows the functionality of the distributed data recording module.

[0013] Figure 9 According to one embodiment, when split transaction records are stored in the validator repository, Figure 2 The flowchart shows the functionality of the distributed data recording module. Detailed Implementation

[0014] The embodiments relate to ledger databases composed of independent files rather than a central database. The embodiments provide a system for data recording or certificates where information is not stored in a centralized database instance, but rather maintained separately on individual devices, and each user is responsible for managing their own records. Users are custodians of their individual records and can perform data updates on their records in a manner trusted by all participants.

[0015] In this embodiment, the data record is maintained by each of the various owners / users of the data on their respective devices. The device corresponding to each owner of the data record and used to store the data record may include, for example, a computer device, a smartphone, a Universal Serial Bus (“USB”) memory stick, email or online storage, or even a data record printed on paper or saved as a two-dimensional quick response (“QR”) code image. As disclosed in detail below, each data record in this embodiment contains sufficient information to convey some of the same characteristics provided by conventional centralized database instances, such as: (1) ensuring that the origin of the record is authentic; (2) enforcing which updates are allowed and not allowed; (3) proving the current state of the record (i.e., the current value of each record parameter, including the current owner of the record); (4) maintaining the history of transactions to prove how the current state became so; and (5) providing security so that unauthorized users cannot make changes to the record.

[0016] In this embodiment, each asset tracks itself independently, rather than using expensive record storage systems (such as public databases that are duplicated at each node (i.e., known blockchain systems)). In this embodiment, data records circulate freely in the world, managing their own ownership and state, rather than database nodes managing all record information and transaction history (as in the case of blockchain).

[0017] For example, in this embodiment, if Alice sends digital “coins” (i.e., digitally signed computer files) to Bob, then those coins (or files) maintain their own signature history within themselves, thus proving their true origin and ownership. Regardless of whether the digital assets in question are a sum of coins, tokens, property rights, notes, credentials, coupons, etc., each individual asset carries its own digitally signed history, allowing the digital asset / record to speak for itself without requiring transaction details to be recorded in a master database. The whereabouts of an asset may be completely unknown to the public. There may be no public knowledge about who currently owns what assets. Instead, files likely maintained by their owners are what are used to track assets. However, in this embodiment, encryption makes it extremely difficult to “cheat.” In this embodiment, users are custodians of their own ledgers, but they cannot tamper with them or modify their values ​​in an unauthorized manner.

[0018] The embodiment is implemented using digital signatures, such as the Elliptic Curve Digital Signature Algorithm (“ECDSA”), where record creation and transactions are signed with a secret private key and verified with the associated public key. A record is created and signed with its creator's private key, leaving a signature string that can be used to verify the signature. The next transaction or record update is signed again, resulting in a record signature that includes the previous signature as part of the signed content. Each time a record is updated, it again generates a record signature containing all previous signatures, creating a signature chain on top of the signatures, such that if any part of the history is tampered with, the signature will not match the expected value during verification. Furthermore, the record includes metadata describing which updates are allowed, which are prohibited, or which are required. These rules, written in metadata, are also protected by the signature (i.e., if the rule text is altered, the signature will not pass verification). The embodiment is novel, in part because record verification requires both signature verification and verification of compliance with any predefined transaction rules. A record is only true if both verifications pass.

[0019] Figure 1 This is a schematic diagram of the elements that can implement embodiments of the present invention. The embodiments relate to various devices 101-108 that can communicate with each other on a continuous or intermittent basis via network 110. Each device 101-108 is any type of device, including processors / controllers for executing instructions (or hardware implementations), storage devices for storing files, and communication devices for communicating with other devices. Devices 101-108 may include desktop or laptop computers, servers, smartphones, tablets, watches, etc. Network 110 can be any type of communication mechanism, such as the Internet or a local area network or a combination of different networks. In the embodiments using third-party validators disclosed below, Figure 1 One of the devices is used as a validator.

[0020] Figure 2 This is a block diagram of a computer server / system 10 according to an embodiment of the present invention. Although shown as a single system, the functionality of system 10 can be implemented as a distributed system. Furthermore, the functions disclosed herein can be implemented on separate servers or devices that can be coupled together via a network. Additionally, one or more components of system 10 may not be included. Multiple systems 10 can be... Figure 1 All components provide functionality.

[0021] System 10 includes a bus 12 or other communication mechanism for transmitting information, and a processor 22 coupled to the bus 12 to process information. Processor 22 can be any type of general-purpose or special-purpose processor. System 10 also includes memory 14 for storing information and instructions to be executed by processor 22. Memory 14 can include random access memory (“RAM”), read-only memory (“ROM”), static storage such as a disk or optical disk, or any other type of computer-readable medium, or any combination thereof. System 10 also includes communication devices 20, such as a network interface card, to provide access to a network. Therefore, a user can interface with system 10 directly or remotely via a network or by any other method.

[0022] Computer-readable media can be any available medium accessible to processor 22, and includes volatile and non-volatile media, removable and non-removable media, and communication media. Communication media can include computer-readable instructions, data structures, program modules, or other data in modulated data signals (such as carrier waves or other transmission mechanisms), and includes any information delivery medium.

[0023] The processor 22 is also coupled to the display 24, such as a liquid crystal display (“LCD”), via bus 12. The keyboard 26 and the cursor control device 28 (such as a computer mouse) are also coupled to bus 12 to enable the user to interface with the system 10.

[0024] In one embodiment, memory 14 stores software modules that provide functionality when executed by processor 22. These modules include operating system 15, which provides operating system functionality to system 10. These modules also include distributed data logging module 16, which provides distributed data logging functionality to the corresponding device, as well as all other functions disclosed herein. System 10 may be part of a larger system. Therefore, system 10 may include one or more additional functionality modules 18 to include additional functionality, such as transaction-based systems, digital wallets, or any other type of application utilizing digital assets. File storage device or database 17 is coupled to bus 12 to provide centralized storage for modules 16 and 18, as well as data logging files and any other necessary data, such as digital signatures. In one embodiment, database 17 is a relational database management system (“RDBMS”) that can use Structured Query Language (“SQL”) to manage the stored data.

[0025] In one embodiment, particularly when there are a large number of distributed files on a single device, database 17 is implemented as an in-memory database (“IMDB”). IMDB is a database management system that primarily relies on main memory for computer data storage. This contrasts with database management systems that employ disk-based storage mechanisms. Main-memory databases are faster than disk-optimized databases because memory access is faster than disk access, the internal optimization algorithms are simpler, and fewer CPU instructions are executed. Accessing data in memory reduces search time when querying data, providing faster and more predictable performance than disk-based systems.

[0026] In one embodiment, when implemented as an IMDB, database 17 is based on a distributed data grid. A distributed data grid is a system in which a group of computer servers work together in one or more clusters to manage information and related operations, such as computation, in a distributed or clustered environment. Distributed data grids can be used to manage application objects and data shared across servers. Distributed data grids offer low response times, high throughput, predictable scalability, continuous availability, and information reliability. In certain examples, distributed data grids (such as, for example, the "Oracle Coherence" data grid from Oracle Corporation) store information in memory for higher performance and employ redundancy to keep copies of that information synchronized across multiple servers, thereby ensuring system resilience and continuous data availability in the event of server failure.

[0027] In one embodiment, system 10 is a computing / data processing system that includes a collection of applications or distributed applications for an enterprise organization, and may also implement logistics, manufacturing, and inventory management functions. The application and computing system 10 may be configured to operate with or implemented as a cloud-based networked system, Software as a Service (“SaaS”) architecture, or other type of computing solution.

[0028] As disclosed, the embodiments provide distributed assets / records, where each distributed asset speaks for itself and also carries metadata that controls what types of transactions are permitted. This contrasts with blockchain systems that rely on a shared ledger, which serves as a complete ledger for all assets (rather than just one asset) and is stored by each user. In the embodiments, digital assets are used as distributed data records, and third-party validators are used for verification.

[0029] Distributed digital data records

[0030] Digital records, digital assets, or “certificate files” prove that someone owns something. In the context of embodiments of the invention, a certificate file represents an asset, such as a bill, currency, data, credentials, digital art, electronic devices, tangible objects, or even a service. The certificate file contains an owner’s address associated with a secret private key that can be used to sign the address. Assets are represented as a chain of digital signatures. Transactions are recorded by the owner digitally signing a hash of a previous transaction and parameters of the next state, appending a public key, thereby creating a verifiable chain. In a blockchain-based ledger, this chain of signatures is recorded on a blockchain server. In contrast, in this embodiment, each certificate carries this chain of signatures on the user device.

[0031] As an example, Alice could initiate a pool of 100 authenticity certificates, which would be offered to the buyers of 100 custom guitars she makes. Bob could initiate a pool of 200,000 "BobCoins." Carol could initiate a pool of food and beverage vouchers for gatherings. These assets would be traded peer-to-peer as certificate documents. These items could be acquired, used, gifted, or sold using a wallet app and QR codes, and their certificates could be transferred to new addresses, or even split or merged between other addresses, thus providing a provenance for subsequent certificate documents. Each subsequent certificate document contained a verifiable signature history of its own pedigree.

[0032] Therefore, if Dave owns assets tracked through a distributed data record file, he can store that file wherever he wants. When Dave decides to transfer or redeem the record, his wallet application provides a digital signature authorizing the parameters of the new record file. In practice, once Dave makes the transaction, his old record file must become invalid. A relatively small amount of online digital information will accomplish this, ensuring that Dave can no longer reuse the old record file, as the entire world must know that the old file is no longer acceptable. Otherwise, Dave might be able to double-spend.

[0033] Third-party validator repository

[0034] In this embodiment, digital records / assets / certificates are independent digital files. However, in some embodiments, proof of their integrity may require a relatively small amount of digital information to be online and available over a network (e.g., a validator server) in the form of a cryptographic checksum for each currently valid certificate. A certificate is valid if a checksum digest exists in the repository. This embodiment prevents double-spending by ensuring that the parent certificate's checksum digest is deleted from the repository when a signed transaction is published, along with the insertion of a checksum digest for a new child certificate.

[0035] This implementation does not provide a distributed consensus algorithm. For private or federated ledgers, the validator (or checksum digest store) can be a private distributed database. For decentralized ledgers, the store should operate on top of a decentralized algorithm, such as blockchain smart contracts, hash graphs, or other algorithms. In any case, the entity operating the verification store cannot issue forged certificates because it has no control over the assets, addresses, or keys. The store is not a perfect authority because it only manages obscure checksum hash values. Its sole purpose is to prevent double-spending, and it requires very little storage space to achieve this (regardless of the size of the digital assets in bytes). Privacy is unparalleled because the list of checksum hash digests in the store does not provide any useful information.

[0036] Create and verify electronic data records / assets

[0037] Figure 3A According to one embodiment, when creating a new electronic record / digital certificate, Figure 2 A flowchart illustrating the functions of the distributed data recording module 16. In one embodiment, Figure 3A (and below) Figure 3B and Figure 4-9 The functionality of the flowchart is implemented by software stored in memory or other computer-readable or tangible media and executed by a processor. In other embodiments, these functions may be implemented by hardware (e.g., by using an application-specific integrated circuit (“ASIC”), a programmable gate array (“PGA”), a field-programmable gate array (“FPGA”), or any combination of hardware and software.

[0038] At 302, obtain the record creator's private / public key pair (e.g., an elliptic curve digital signature key pair). At 304, write a new electronic record including at least one parameter, as will be described in more detail below. At 306, using the record creator's private key and the entire record information as the message text (including the creator's public key), calculate the digital signature, which will produce a signature hash value. At 308, append the digital signature value to the record.

[0039] As Figure 3A Examples of its functionality are shown in the following numerical record:

[0040] {

[0041] Message: "Hello world!"

[0042] "creator": "38FBF6P8VT33IV8TDT6APUD1G4UHVTRUN6OYAJPQA4QUTFX7Q6QH49ZDF53FRAUHOR137MY1QSKIVRWYHTLSSQ2NZR9B8 ",

[0043] "signature": "7O6PRLXXB4ZFPPHK9X258SMV4OY2UKQVDR87ZNL9F7PNH06L0O5EZ8WHTZ6UVGZZ1IDPPJ97JV1HGK31MIPJQK7RZU0IQY3T0CV"

[0044] }

[0045] For readability, the above examples of digital records, as well as all other examples in this document, are in JavaScript Object Notation (“JSON”) format. However, records can be in any format, including data records with fields separated by special characters (such as comma-separated or tab-separated files), or data records with fields separated by tags (e.g., Extensible Markup Language (“XML”), or data records with fields separated by fixed widths, or data records with fields numbered by line. Records can be human-readable text or non-human-readable text, such as binary or compressed formats. Records do not have to be represented as computer files, as they can be information read and accessed in memory (“RAM”) or information stored as fragments of a larger dataset (such as the contents of a database). Because JSON is used in the examples disclosed herein, it should be noted that JSON is not ordered by definition. JSON records can have parameters in different orders but are still considered equal. Because the embodiments employ digital signatures and checksum hashes, the records must always be identical for all clients throughout all parts of the processing. This means that if JSON format (or any unordered format) is used, then each participant must process the parameters in the same order and format (indentation, newlines, etc.) to ensure that the signature, checksum, and verification are deterministic, thus always obtaining the same result.

[0046] The digital record above has a parameter "message" with the value "Hello world!". The record shows the "creator's" public key and a digital signature calculated using the creator's private key.

[0047] In the second example below, the record contains more parameters. At creation time, the creator has already assigned ownership of the record to another key pair and then signed it:

[0048] {

[0049] "title": "Pearl Jam live at Radio City", "event_date": "Mar 15, 2022", "row": "W", "seat": "15",

[0050] "creator": "38FBF6P8VT33IV8TDT6APUD1G4UHVTRUN6OYAJPQA4QUTFX7Q6QH49ZDF53FRAUHOR137MY1QSKIVRWYHTLSSQ2NZR9B8 ",

[0051] "transfers": [

[0052] {

[0053] "from": "38FBF6P8VT33IV8TDT6APUD1G4UHVTRUN6OYAJPQA4QUTFX7Q6QH49ZDF53FRAUHOR137MY1QSKIVRWYHTLSSQ2NZR9B8 ",

[0054] "to": "38FBF6P8VT33IV8TDT6APUD1G4UHVTRUN6OYAKOYLBNZOERI12DJAKO2AN2OV944QNENE54UHM495LG19AALB9IKFI1N",

[0055] "signature": "7O6PRLXXB4ZFPPHK9X258SMV4OY2UKQVDR87ZNL9F7PNH06L0O5EZ8WHTZ6UVGZZ1IDPPJ97JV1HGK31MIPJQK7RZU0IQY3T0CV"

[0056] } ]

[0058] }

[0059] A digital signature is calculated using a private key and the entire contents of the record as the message to be signed. The transaction parameter "to" is a portion of the message to be digitally signed. Signature:

[0060] The signature “7O6PRLXXB4ZFPPHK9X258SMV4OY2UKQVDR87ZNL9F7PNH06L0O5EZ8WHTZ6UVGZZ1IDPPJ97JV1HGK31MIPJQK7RZU0IQY3T0CV” is then appended to the record. The record is then either saved or sent to its intended destination.

[0061] Figure 3B According to one embodiment, when executing a transaction with an electronic record, Figure 2 The flowchart shows the functions of the distributed data recording module 16.

[0062] At 310, the relevant record is obtained (i.e., retrieved from storage). At 312, a new transaction (such as a transfer of ownership and / or a change in the value of one or more parameters) is appended to the record. At 314, the modified record is digitally signed using all information on the record (including all previous transactions and signatures, and details about the current transaction) as input messages. At a minimum, the information to be signed (i.e., the input message to the signing algorithm) must include at least the most recent previous signature (as it has proven everything that happened before) and details about the current transaction, such as the modified parameter values ​​or the change in record ownership. However, in some embodiments, all previous transactions and signatures, and even the record's parameter values, may be further included as part of the message to be signed. The current record owner's private key is used to compute the digital signature. At 316, the digital signature value is appended to the record as part of the current transaction.

[0063] As Figure 3B Here's an example of the functionality, assuming the received record already contains a signed transaction. After appending a second and third transaction, both digitally signed, the record looks like this:

[0064] {

[0065] "title": "Pearl Jam live at Radio City, Mar 15, 2022, row W seat 15",

[0066] "issuer":"38FBF6P8VT33IV8TDT6APUD1G4UHVTRUN6OYAJPQA4QUTFX7Q6QH49ZDF53FRAUHOR137MY1QSKIVRWYHTLSSQ2NZR9B8 ",

[0067] "transactions": [

[0068] {

[0069] "transaction_id":1,"type": "transfer",

[0070] "from": "38FBF6P8VT33IV8TDT6APUD1G4UHVTRUN6OYAJPQA4QUTFX7Q6QH49ZDF53FRAUHOR137MY1QSKIVRWYHTLSSQ2NZR9B8 ",

[0071] "to": "38FBF6P8VT33IV8TDT6APUD1G4UHVTRUN6OYAKOYLBNZOERI12DJAKO2AN2OV944QNENE54UHM495LG19AALB9IKFI1N",

[0072] "signature": "7O6PRLXXB4ZFPPHK9X258SMV4OY2UKQVDR87ZNL9F7PNH06L0O5EZ8WHTZ6UVGZZ1IDPPJ97JV1HGK31MIPJQK7RZU0IQY3T0CV"

[0073] },

[0074] {

[0075] "transaction_id":2,

[0076] "type": "change_title",

[0077] "from": "Pearl Jam live at Radio City,Mar 15,2022,row W seat 15",

[0078] "to": "Pearl Jam live at Radio City,Mar 16,2022,row W seat 15",

[0079] "signature": "LKSFD09823KJ4SD98F74K5J6MNFDV8D78FDK4JD8DJRKJLKUY76ZYXCGSVBVG1U76FOSIKD54GJD0F9G09URLJSLDUFO8UDFU9S8D"

[0080] },

[0081] {

[0082] "transaction_id":3,

[0083] "type": "transfer",

[0084] "from": "38FBF6P8VT33IV8TDT6APUD1G4UHVTRUN6OYAKOYLBNZOERI12DJAKO2AN2OV944QNENE54UHM495LG19AALB9IKFI1N ",

[0085] "to": "FGSDF9G8SFDG7652JK3H4KJNXCVSDU987324JK5NKSDJF89D7I3L4J5LI7DF8OI3J4L5KJDF9OUL4KRJLKHFASDFYTSAD761QA",

[0086] "signature": "LKSFD09823KJ4SD98F74K5J6MNFDV8D78FDK4JD8DJRKJLKUY76ZYXCGSVBVG1U76FOSIKD54GJD0F9G09URLJSLDUFO8UDFU9S8D"

[0087] } ]

[0089] }

[0090] In the example above, the record already has one transaction, namely, the transfer of ownership. A second transaction is added to the record to update the "title" parameter, and then a third transaction makes another change to the ownership.

[0091] By repeating the above steps, subsequent transactions can be executed again and again, and the record will increase as each signed transaction is recorded. The value of the most recent signature is the result of a calculation that includes all previous signatures as input. If someone were to modify any part of the document, the last digital signature would become unverifiable or invalid.

[0092] In the example above, the record has undergone multiple transfers of ownership. In this case, the current owner of the record is anyone who controls the private key associated with the public key in the "to" field of the most recent transfer. In this example, the current control of the record is the public / private key pair.

[0093] Some embodiments allow multiple owners to possess a record simultaneously. In this case, the owner of the record can be identified by multiple addresses or public keys (if not derived addresses). For example, an owner can be represented by a comma-separated array of address strings. In this case, the record can require any, some, or all of the owners to sign the transaction. To complete a transaction involving multiple owners, one owner will sign the transaction, generating a digital signature which is then appended to the record. The resulting record is then passed to the next(s) owners(s) to sign the same transaction and append their signatures as well. After all the necessary owners have signed the transaction, the transaction is considered complete. In such embodiments, verifying a transaction will require verifying each of the multiple transactions signed by the multiple owners, individually.

[0094] Figure 4 According to one embodiment, when verifying electronic records, Figure 2 The flowchart shows the functions of the distributed data recording module 16.

[0095] At 402, the electronic record to be verified is obtained. At 404, the first (or next) transaction to be verified is selected. If the record contains multiple transactions, the process can begin with any transaction, as a specific order is not required. At 406, the signature hash value and public key string are extracted from the signed transactions of the record. These two values ​​will be used as inputs to a function to verify the validity of the signature. To verify the signature, the embodiment must obtain the same input message as the input message used at the time of signing. For this purpose, the signature string is removed because it did not exist at the time of signing, and all transactions occurring after the transaction being verified at this point are removed. The functions at 404 and 406 can be performed in any order.

[0096] At point 410, since three crucial pieces of information have been obtained, a signature verification algorithm is invoked / executed to verify the validity of the digital signature. As discussed, these three pieces of information are: (1) a copy of the original signed message, which is in its recorded state at the time of signing; (2) the public key corresponding to the secret private key(pair) used to sign the signer's input message; and (3) the signature hash value recorded on the transaction. With these three elements, a function can be executed that will verify whether the signature was actually generated using the secret private key corresponding to the public key. Thus, the embodiment avoids the need to know the private key of the record's creator or the creator of any subsequent transactions. In one embodiment, the function used is the Elliptic Curve Digital Signature Algorithm, but other algorithms can be used. It is assumed that the signature algorithm is known to all participants. For example, if the record was signed using the Elliptic Curve Digital Signature Algorithm and is being verified, then it is assumed that the curve is known to the program verifying the file (since the curve is not specified in the file).

[0097] At 412, if the function at 410 confirms that the signature was indeed generated using the private key corresponding to the public key using the exact same message, then the function proceeds to 414. If the verification fails, then at 418, the function ends after returning a failure (i.e., the record is not valid).

[0098] At point 414, if there are any additional transactions to be verified, the function continues at point 404. Otherwise, at point 416, it returns that the record is valid (i.e., verification was successful), and then the function ends.

[0099] As Figure 4 For example of functionality, suppose there are two transactions (both are transfers from one record owner to another) in the following sample record:

[0100] {

[0101] "title": "Pearl Jam live at Radio City, Mar 15, 2022, row W seat 15",

[0102] "transfers": [

[0103] {

[0104] "id":1,

[0105] "from": "38FBF6P8VT33IV8TDT6APUD1G4UHVTRUN6OYAJPQA4QUTFX7Q6QH49ZDF53FRAUHOR137MY1QSKIVRWYHTLSSQ2NZR9B8 ",

[0106] "to": "38FBF6P8VT33IV8TDT6APUD1G4UHVTRUN6OYAKOYLBNZOERI12DJAKO2AN2OV944QNENE54UHM495LG19AALB9IKFI1N",

[0107] "signature": "7O6PRLXXB4ZFPPHK9X258SMV4OY2UKQVDR87ZNL9F7PNH06L0O5EZ8WHTZ6UVGZZ1IDPPJ97JV1HGK31MIPJQK7RZU0IQY3T0CV"

[0108] },

[0109] {"id":2,

[0110] "from": "38FBF6P8VT33IV8TDT6APUD1G4UHVTRUN6OYAKOYLBNZOERI12DJAKO2AN2OV944QNENE54UHM495LG19AALB9IKFI1N ",

[0111] "to": "FGSDF9G8SFDG7652JK3H4KJNXC,VSDU987324JK5NKSDJF89D7I3L4J5LI7DF8OI3J4L5KJDF9OUL4KRJLKHFASDFYTSAD761QA",

[0112] "signature": "LKSFD09823KJ4SD98F74K5J6MNFDV8D78FDK4JD8DJRKJLKUY76ZYXCGSVBVG1U76FOSIKD54GJD0F9G09URLJSLDUFO8UDFU9S8D"

[0113] } ]

[0115] }

[0116] To verify the above records, Figure 4 The functionality begins by examining a signed transaction. It can be any transaction (no specific order is required), but in this example, the functionality starts with the first transaction.

[0117] 1) The public key for the first transaction is: "38FBF6P8VT33IV8TDT6APUD1G4UHVTRUN6OYAJPQA4QUTFX7Q6QH49ZDF53FRAUHOR137MY1QSKIVRWYHTLSSQ2NZR9B8"

[0118] 2) The signature hash value on the first transaction is: "7O6PRLXXB4ZFPPHK9X258SMV4OY2UKQVDR87ZNL9F7PNH06L0O5EZ8WHTZ6UVGZZ1IDPPJ97JV1HGK31MIPJQK7RZU0IQY3T0CV"

[0119] 3) The original message input that was signed in the first transaction is:

[0120] {

[0121] "title": "Pearl Jam live at Radio City, Mar 15, 2022, row W seat 15",

[0122] "transfers": [

[0123] {

[0124] "id":1,

[0125] "from": "38FBF6P8VT33IV8TDT6APUD1G4UHVTRUN6OYAJPQA4QUTFX7Q6QH49ZDF53FRAUHOR137MY1QSKIVRWYHTLSSQ2NZR9B8 ",

[0126] "to": "38FBF6P8VT33IV8TDT6APUD1G4UHVTRUN6OYAKOYLBNZOERI12DJAKO2AN2OV944QNENE54UHM495LG19AALB9IKFI1N",

[0127] } ]

[0129] }

[0130] These three pieces of information are used to verify that the signature was indeed generated using the secret private key. If it passes the test, the same operation is performed for all other transactions. However, the transactions are verified using an input message that excludes all subsequent transactions but includes all previous transactions. Therefore, when testing a second transaction, details about the first transaction become part of the input message being signed.

[0131] In one example, the extracted copy of the input message used to verify the second transaction would look like this (unsigned):

[0132] {

[0133] "title": "Pearl Jam live at Radio City, Mar 15, 2022, row W seat 15",

[0134] "transfers": [

[0135] {

[0136] "id":1,

[0137] "from": "38FBF6P8VT33IV8TDT6APUD1G4UHVTRUN6OYAJPQA4QUTFX7Q6QH49ZDF53FRAUHOR137MY1QSKIVRWYHTLSSQ2NZR9B8 ",

[0138] "to": "38FBF6P8VT33IV8TDT6APUD1G4UHVTRUN6OYAKOYLBNZOERI12DJAKO2AN2OV944QNENE54UHM495LG19AALB9IKFI1N",

[0139] "signature": "7O6PRLXXB4ZFPPHK9X258SMV4OY2UKQVDR87ZNL9F7PNH06L0O5EZ8WHTZ6UVGZZ1IDPPJ97JV1HGK31MIPJQK7RZU0IQY3T0CV"

[0140] },

[0141] {"id":2,

[0142] "from": "38FBF6P8VT33IV8TDT6APUD1G4UHVTRUN6OYAKOYLBNZOERI12DJAKO2AN2OV944QNENE54UHM495LG19AALB9IKFI1N ",

[0143] "to": "FGSDF9G8SFDG7652JK3H4KJNXC,VSDU987324JK5NKSDJF89D7I3L4J5LI7DF8OI3J4L5KJDF9OUL4KRJLKHFASDFYTSAD761QA",

[0144] } ]

[0146] Use address

[0147] In embodiments, the address is a hash value derived from the public key or the public portion of a key pair. For example, when ownership of a record is transferred to an "address," in some embodiments, the recipient's public key can be kept secret until a signature is made in the future. This optional security measure may be necessary because, depending on the digital signature algorithm used, it is best to keep the public key secret before use. To improve readability for client applications, the record may also include top-level parameters for the creator's address and the current owner's address, so that client applications do not have to retrieve this information from the transaction history.

[0148] In embodiments using this security measure, the function is similar to Figure 3A , Figure 3B and Figure 4 The difference lies in the fact that the key pair for controlling the record is identified by the hash of the public key rather than the public key itself.

[0149] Trading Rules

[0150] In embodiments, electronic records may include metadata to enforce permitted, prohibited, or required parameter value changes. For example, numeric parameters may need to always satisfy one or more mathematical comparisons, such as equal to, and / or less than, and / or greater than, and / or different from one or more predefined values, or the value of another parameter or function. Text parameters may need to satisfy one or more format or value comparisons, such as having to satisfy a format mask or regular expression, or having to match a value from another field or a predefined list of allowed values. Date parameters may need to have values ​​that are equal to, or greater than, or less than, or different from the value of a specific date or date range, or the value of another date parameter.

[0151] Rules may require updating parameter values. Records can include metadata that forces one or more parameters to be updated in response to certain events. For example, whenever a transaction causes a change in record ownership, the record may require a numeric parameter called "transfer_counter" to increment by a predefined factor of 1. This can be used to enforce a limit on the maximum number of transfers allowed.

[0152] Functions for creating records with parameter constraints, such as... Figure 3A The function shown is the same as creating a "basic" record, except that the record itself includes additional metadata that explains whether one or more parameters must have values ​​that satisfy any condition.

[0153] The following is an example record with parameter constraints:

[0154] {

[0155] Title: "Lionel Messi",

[0156] "parameters": [

[0157] {

[0158] "name": "Speed", "type": "number", "value": 85, "readonly": true

[0159] },

[0160] {

[0161] "name": "Ability", "type": "number", "value": 99, "readonly": true

[0162] },

[0163] {

[0164] "name": "Status", "type": "text", "value": "Active", "readonly": false,

[0165] "allowed": ["Active", "Injured", "Suspended", "Retired" ]

[0166] },

[0167] {

[0168] "name": "Transfers", "type": "number", "value": 0, "readonly":true,

[0169] "auto_increment": 1,

[0170] "when": "owner changes",

[0171] "max": 10

[0172] }

[0173] ],

[0174] "creator_address": "5XA5AH7B0N5FEMGX72KFLRLMOGFWIFSUWMOOSXUO7FUL2SSA7HXU5Q3",

[0175] "owner_address": "CIDK3FPH9SIGJWMEAGXSMBEPCOLFCZSIA1P25DRJSNPFWHAFEAK8NSIU",

[0176] "transactions": [

[0177] {

[0178] "from": "5XA5AH7B0N5FEMGX72KFLRLMOGFWIFSUWMOOSXUO7FUL2SSA7HXU5Q3",

[0179] "to": "CIDK3FPH9SIGJWMEAGXSMBEPCOLFCZSIA1P25DRJSNPFWHAFEAK8NSIU",

[0180] "public_key": "38FBF6P8VT33IV8TDT6APUD1G4UHVTRUN6OYAJPQA4QUTFX7Q6QH49ZDF53FRAUHOR137MY1QSKIVRWYHTLSSQ2NZR9B81TON9QLPCZLQXG363GB0WSXMOS1ZMO5",

[0181] "signature": "7O6PRLXXB4ZFPPHK9X258SMV4OY2UKQVDR87ZNL9F7PNH06L0O5EZ8WHTZ6UVGZZ1IDPPJ97JV1HGK31MIPJQK7RZU0IQY3T0CV"

[0182] } ]

[0184] }

[0185] In the above records, each parameter specifies certain rules. The parameters "Speed" and "Ability" are read-only and cannot be modified. The parameter "Status" can be modified, but must match a predefined list of text values. The parameter "Transfers" is read-only and cannot be intentionally modified by the user, but it needs to be incremented by a factor of 1 each time the owner changes in a transaction, and it also has a maximum value of 10. Therefore, after a record has been transferred 10 times, it cannot be transferred to a new owner again; otherwise, the conditions will not be met during verification.

[0186] These rules, implemented by parameter values, are recorded in a log, and their text is signed by the log creator. Therefore, other users cannot modify the rule definitions, as this would invalidate the creator's signature. The rules are protected by the creator's signature.

[0187] To validate records with parameter constraints, this function is similar to the case without parameters, but with an additional task: when validating a transaction, the parameters of each record with predefined transaction rules must be compared to check if the transaction meets all the rule requirements, and if any transaction produces a parameter value that does not meet the rules defined by the record creator, then invalid will be returned.

[0188] The verification function can be performed in any order, such as (1) first verifying all signatures for all transactions, then verifying all rules for all transactions; (2) first verifying all rules for all transactions, then verifying all signatures; (3) verifying rule compliance and signatures for each transaction one at a time; or (4) verifying signatures and rule compliance for each transaction one at a time. The order is irrelevant as long as all signatures and all rules are verified.

[0189] Figure 5 According to one embodiment, when verifying electronic records using transaction rules, Figure 2 The flowchart shows the functions of the distributed data recording module 16.

[0190] Figure 5 Functions include with Figure 4 The same functionality is implemented, with the following additions. At 502, the metadata is checked for any (or the next) rules to be checked. For example, it could be a parameter with a maximum allowed value. At 504, the rule requirement is compared to the transaction value change. For example, if the rule specifies a maximum allowed transaction value of 10 and the transaction has been updated to a value of 11. At 506, if the rule is violated, the record is invalidated at 418. Otherwise, at 508, the functionality continues from 502.

[0191] Third-party validators

[0192] In this embodiment, when electronic records are updated, it is often necessary to record previous versions that become obsolete and no longer valid. For example, if ownership of a record changes, the older version with the previous owner should become invalid. The system for recording may need to be chronologically stateful to avoid race conditions or "double-spending." This can be addressed by employing a third-party validator. Record creation, transactions, and verification can be routed to a third-party service that can identify whether a record is obsolete or current. An online validator can determine whether a record is current or obsolete by maintaining a list of currently valid records. Its repository (which may be a file, directory, database, or data structure) does not need to maintain a complete copy of every record, as it only needs a checksum for each currently valid record. The checksum can be a very short string. If the checksum of a record exists in the validator's repository, then a record of any size can be verified as valid.

[0193] To create new records subject to third-party validators, implement the creation... Figure 3A The system then introduces the functionality of newly signed records. After the record includes a digital signature (i.e., after a 308 error), it is used as an input message to compute a checksum hash of the record using a hashing algorithm such as MD5, Keccak, or SHA. The checksum is then inserted into an online repository or database, which may require credentials and creation permissions. The checksum in the validator repository will indicate that the record is legitimate.

[0194] Figure 6 According to one embodiment, when a record is verified by a third-party verifier, Figure 2 The flowchart shows the functions of the distributed data recording module 16. Figure 6 The functionality is implemented after a third party (including third-party validator checksums) receives the updated record at 602.

[0195] At position 604, it's necessary to check if the old record receiving the update is actually valid. This is done by checking if a checksum of the old record exists in the repository. To do this, the latest transaction is removed from the record to obtain the older version of the record (i.e., the one preceding that transaction).

[0196] At position 606, calculate the checksum hash of the old version of the record. At position 608, if the checksum of the old record exists in the repository, then the old record is valid. If not at position 608, then the old record is invalid and verification fails. For example, the old record might have expired due to another earlier published transaction.

[0197] If it is true at 608, then use it at 610. Figure 4 and Figure 5 The function verifies new, updated records. This means checking if the transaction signature was indeed signed with the record's current owner's private key, and checking for any potential rule violations. Since the checksum of the old record has already been verified, there is no need to verify the entire transaction history again. Only the new(s) transactions(s) need to be verified.

[0198] At point 612, if the new (updated) record is valid, proceed to point 614. However, if the new transaction signature is invalid or the rule has been violated, the verification fails.

[0199] If the old and new records have been verified, it is safe to remove the checksum of the old file at 614 and insert the checksum of the new file at 616. Depending on the type of database used, 614 and 616 can be combined into a single "update" instead of "removal and insertion". If the remove / insert method is used, the database management system used can provide functionality to ensure atomic changes, meaning that deletion and insertion may succeed or fail simultaneously.

[0200] use Figure 6 With this function, the requester can use a third-party validator to verify the validity of a record by performing two simple steps: (1) calculating the checksum hash of the record; and (2) requesting the third-party validator to confirm whether the checksum is valid (existing) or invalid (not found).

[0201] In one embodiment, particularly when the online validator repository is fully trusted, such as in a private system or a reputable decentralized algorithm (e.g., open-source smart contracts on a reputable decentralized system), the signature chain can be omitted from the record. Since each transaction is verified by the online validator before the repository is updated, the signature chain can be implicit. In other words, if a checksum digest exists in the online repository, then all previous transactions must be honorable; otherwise, no checksum will be found in the repository. This embodiment eliminates the need for records to maintain their complete transaction history. Systems employing this model would have to be designed and developed from the outset to create and update records that do not contain transaction history as part of the record. This prevents the record file from growing excessively large. It also provides ultimate privacy, if desired, since the previous owner of the record will be unknown. However, this is only beneficial when the repository (online validator) is fully trusted (which is not always the case). Furthermore, in some use cases, transaction history may still be required for other reasons, such as verifying that the record has been transferred to the intended owner.

[0202] In some embodiments, the system of records described may operate using specific software, a single online validator, a known creator key, a known signature algorithm, and a known checksum algorithm. However, in other embodiments, a system for creating, transacting, and verifying universal records is used, employing many different software programs (such as different smartphone wallets), many record creators, many algorithms used, and many validator services. Therefore, in embodiments, electronic records may include the following additional parameters to facilitate a universal framework:

[0203] (A) A parameter for the creator's Hypertext Transfer Protocol (“HTTP”) Uniform Resource Locator (“URL”) allows users and client applications to verify the creator's address. For example, if a company, ACME.COM, creates a record, they might publish a page on the ACME.COM domain to allow users and applications to obtain its official address or public key. A wallet application can notify the user that the record being checked was signed using a key whose public portion is provided by ACME.COM.

[0204] (B) Parameters for the HTTP URL used for the validator service (i.e., telling the client application where to verify the records).

[0205] (C) Parameters for the signature algorithm used. For example, if an elliptic curve is used, this parameter indicates what curve is used so that other applications can verify the document.

[0206] Some implementations provide security options to ensure that the creator's key can only be used once. This is desirable if the creator's private key is compromised, or when a user wants to limit the supply by ensuring that the creator cannot use the same key to create additional records. To achieve this, a third-party online validator can add the creator's public key (or address, if an address is used) to a list of previously used keys (or addresses). Before creating any new record, the third-party validator can check whether the creator's key has been previously used to create past records.

[0207] Figure 7 According to one embodiment, when creating a new record subject to a third-party validator with additional security, Figure 2 The flowchart shows the functions of the distributed data recording module 16. Figure 7 The functionality is an addition to the aforementioned disclosed functionality for creating new records subject to third-party validators.

[0208] After receiving a request to insert a new record at point 702, at point 704, it is verified that the newly created record is correctly signed (i.e., the signature is verified against the creator's public key), and at point 706, it is verified that the key has not been used before by querying the creator's key against a list, directory, or database that tracks previously used keys or addresses. Points 704 and 706 can be executed in any order.

[0209] At 708, the creator's key (or address) is inserted into a list, directory, or database that tracks previously used keys or addresses. At 710, a checksum for the new record is created. At 712, this checksum is inserted into a list, directory, or database of valid records.

[0210] Record splitting

[0211] In this embodiment, records may have divisible numerical parameters. For example, a record representing an account may have balances in points, currency, shares, or any divisible number that may be allocated in parts to one or more other owners.

[0212] For example, Alice can control a record with a "Points" parameter and a value of "10". Alice can execute a transaction that allocates 3 "Points" to Bob (his address) and 2 "Points" to Carol (her address). This transaction will create a record that allows Bob's private key to control 3 "Points", Carol's private key to control 2 "Points", and Alice's private key to retain control over 5 "Points". From then on, they don't have to maintain a single copy of the record. Each of them can obtain their own copy and do whatever they want without the other two knowing.

[0213] Recording a split transaction is similar to the transaction disclosed below, except that the transaction details will include details about the allocation of each part, such as the following:

[0214] {

[0215] "Title": "Appreciation Kudos",

[0216] "parameters": [

[0217] {

[0218] "name": "Kudos",

[0219] "type": "number",

[0220] "value": 10,

[0221] "divisible": true

[0222] }

[0223] ],

[0224] "creator_address": "5XA5AH7B0N5FEMGX72KFLRLMOGFWIFSUWMOOSXUO7FUL2SSA7HXU5Q3",

[0225] "transactions": [

[0226] {

[0227] "id":1,

[0228] "type": "transfer",

[0229] "from": "5XA5AH7B0N5FEMGX72KFLRLMOGFWIFSUWMOOSXUO7FUL2SSA7HXU5Q3",

[0230] "to": "CIDK3FPH9SIGJWMEAGXSMBEPCOLFCZSIA1P25DRJSNPFWHAFEAK8NSIU",

[0231] "public_key": "38FBF6P8VT33IV8TDT6APUD1G4UHVTRUN6OYAJPQA4QUTFX7Q6QH49ZDF53FRAUHOR137MY1QSKIVRWYHTLSSQ2NZR9B81TON9QLPCZLQXG363GB0WSXMOS1ZMO5",

[0232] "signature": "7O6PRLXXB4ZFPPHK9X258SMV4OY2UKQVDR87ZNL9F7PNH06L0O5EZ8WHTZ6UVGZZ1IDPPJ97JV1HGK31MIPJQK7RZU0IQY3T0CV"

[0233] },

[0234] {

[0235] "id":2,

[0236] "type": "split",

[0237] "source":"Kudos",

[0238] "quantity": 3,

[0239] "from": "CIDK3FPH9SIGJWMEAGXSMBEPCOLFCZSIA1P25DRJSNPFWHAFEAK8NSIU",

[0240] "to": "SDJF8723I4SMNKSDF912KHJKSDFSDF987DKK2KJ34MSDFHISUDF97234",

[0241] "public_key":"SDF9078ADSFHL34HL5KJ2H98D76SIH435908D7FGJH32459087DSFGLKHJ324598DS7FGLH3245987DSFG79854032LJSDFG987SDFGLK3J2LJDGFDK2JH34K2J3",

[0242] "signature": "KDIJD8D8EYUDNNBZZ76DS234987SDDFD8SJ74SJKHDDFJKSDHF89SDFKJWHERLKJSDLKSLASDMBNXCMNBQIWU987219080USDF0"

[0243] } ]

[0245] }

[0246] In the example above, the creator (5XA5AH...) created a record with 10 "Kudos," where a "Kudos" is a numerical parameter that can be divided and its parts assigned to different owners. The creator recorded the transaction that transferred ownership of the record to Alice (CIDK3...).

[0247] In the second transaction, Alice split the Kudos parameter, thus giving Bob (SDJF8...) 3 "Kudos". From this point on, if the record receives a transaction signed by Alice that does something with 7 or fewer Kudos, then that transaction will be valid. If the record receives a transaction signed by Bob that does something with 3 or fewer Kudos, then that record will also be valid. Therefore, both Alice and Bob can continue with the record on different paths, which will ultimately result in multiple files that are different from each other but still valid.

[0248] The splitting functionality disclosed above is useful when double-spending is not a concern and when the recording system does not require a third-party validator. In other embodiments, splitting is performed to prevent double-spending and verified through a third-party repository. In these embodiments, the split should result in just enough sub-records that are distinct from each other to produce different checksum hash values. For example, if record A is split into two parts, it should result in two new records B and C, where A, B, and C produce different checksum values ​​for the repository. After the split record is stored in the repository, the checksum of record A is removed, and the checksums of records B and C are found in the repository. Records can also be split into more than two parts.

[0249] Figure 8 According to one embodiment, when parameters are split into multiple sub-records, Figure 2 A flowchart illustrating the functions of the distributed data recording module 16. As... Figure 8 For example, assuming the record parameter contains an initial supply of 10, the initial supply will be the minuend. If owner Alice gives Bob 3 units and Carol 2 units, and she keeps 5 units for herself, then the supply has been split with no remainder, as shown below:

[0250] 10 (Minuend = Original Record)

[0251] -3 (minus 1, for Bob = child record 1)

[0252] -2 (subtract 2, for Carol = sub-record 2)

[0253] -5 (minus 3, Alice retains = child record 3)

[0254] = 0 (difference)

[0255] for Figure 8 The function of subtracting each part from the original quantity is called a subtrahend. Each subtrahend will produce a unique child record. The original record (the starting point) will be reused as the starting copy for each child record.

[0256] After obtaining the original record at point 802, at point 804, for each subtrahend (a portion subtracted from the original), a copy of the original record is used as the starting point. At point 806, the transaction is appended to the subrecord, thus assigning control of the subtrahend to the public key or derived address. For example, if Alice gives Bob 3 units, the transaction is appended to the subrecord, indicating that 3 units have been assigned to Bob's public key (or address).

[0257] At point 808, the transaction from point 806 is digitally signed using the secret private key that controls the record. At point 810, the digital signature is appended to the transaction, thus completing the sub-record.

[0258] At 812, determine if there are any further subtractions in the transaction. In other words, are there any additional portions of the original amount that still need to be recorded as sub-records that have been split? If no at 812, the function continues at 804. If yes at 812, the function ends by returning a batch of multiple unique sub-records.

[0259] In an embodiment, when a transaction splits a record into multiple sub-records, recording them in the validator store means removing an old checksum hash and adding many new checksum hashes. Figure 9 According to one embodiment, when a split transaction is recorded in the validator store, Figure 2 The flowchart shows the functions of the distributed data recording module 16.

[0260] At 902, a batch of records is received. At 904, the next record in the batch is selected. At 906, the last transaction is removed from the selected sub-record. This is done to identify the original document (before splitting the transactions) so that the original document can be examined to determine if it is a good starting point.

[0261] At position 908, the checksum and hash of the original record are calculated and stored for later use. At position 910, the checksum and hash are used... Figure 4 or Figure 5 The function verifies the sub-record. If signature verification fails or if transaction rules are violated, the sub-record will be invalid. At 912, if the sub-record is invalid, the record fails. Otherwise, at 914, the checksum hash of the new sub-record is calculated and saved for later use. The checksum of the old original record has already been saved, but the checksum of the new record is also required.

[0262] At 916, if there are more sub-records in the batch, the function continues at 904. Otherwise, at 918, all sub-records in the batch should be a unique continuation of the same original record. The implementation needs to ensure that all sub-records have the same exact origin, or in other words, that the original record portion is identical in all sub-records. There are several ways to do this. One is to compare their text without making a final transaction to ensure they all have the same identical original portion. Figure 9Another approach used in this embodiment is to obtain all checksums generated in step 3 and ensure they all match. For each sub-record, we checksum its original record at 908. If they all produce the same checksum, then they all have the same exact original record as the starting point, and the process can continue. If at least one sub-record has a mismatched "original record" in that sub-record, then the process must fail.

[0263] At 920, determine whether the checksum generated at 908 (which is now known to be the same for all child records) exists in the repository as a valid record. If not at 920, the process fails. If the original record does not have a checksum in the repository, the record is invalid. If yes at 920, then at 922, remove the checksum of the original record from the repository. At 924, insert the checksum of each child record into the repository.

[0264] 908, 910, 912, and 914 can be in a different order. For example, the checksum can be determined after verifying the document. 918 and 920 can be in any order. 922 and 924 should be atomic, in an "all or nothing" manner. All insertions and deletions must succeed; otherwise, all operations must be rolled back to the initial state.

[0265] In this implementation, all sub-records must be unique. For example, if Alice assigns 2 units to Bob, then assigns 2 more units to Bob, and then assigns 2 more units to Bob again, these three subtractions will produce three identical records with the same checksum. Consideration should be given to ensuring that each sub-record has sufficient information, such as a unique partial ID number for each transaction, to ensure that all sub-records are unique by at least one character, thus generating a unique checksum in the repository.

[0266] Furthermore, in embodiments, options may be included for recording split transactions one by one, such that the original document maintains the tally of the transactions. For example, if Alice gives a portion of a quantity to Bob, and then another portion to Carol, and then another portion to Dave, Alice might have a record containing traces of all three different split transactions as a tally. This is useful if Alice needs to prove to Bob that she has paid to his address. The evidence could be her currently valid documents showing the transaction to Bob's address. This makes the record a continuously running ledger of payment history within the record itself.

[0267] As an example, a record can be split into a batch of 3 sub-records. In this example, the creator (5XA5A…) creates a record with a supply of 10 “Kudos” and assigns it to Alice (CIDK3…). Alice then splits these 10 Kudos, assigning 3 Kudos to Bob (SDJF8…), 2 Kudos to Carol (S98DF…), and the remaining 5 Kudos she assigns to herself. This batch of 3 sub-records is represented in JSON format as an array of 3 nested JSON documents, as follows: [

[0269] {

[0270] "Title": "Appreciation Kudos",

[0271] "parameters": [

[0272] {

[0273] "name": "Kudos",

[0274] "type": "number",

[0275] "value": 10,

[0276] "dividible": true

[0277] }

[0278] ],

[0279] "creator_address": "5XA5AH7B0N5FEMGX72KFLRLMOGFWIFSUWMOOSXUO7FUL2SSA7HXU5Q3",

[0280] "transactions": [

[0281] {

[0282] "id": 1,

[0283] "type": "transfer",

[0284] "from": "5XA5AH7B0N5FEMGX72KFLRLMOGFWIFSUWMOOSXUO7FUL2SSA7HXU5Q3",

[0285] "to": "CIDK3FPH9SIGJWMEAGXSMBEPCOLFCZSIA1P25DRJSNPFWHAFEAK8NSIU",

[0286] "public_key": "38FBF6P8VT33IV8TDT6APUD1G4UHVTRUN6OYAJPQA4QUTFX7Q6QH49ZDF53FRAUHOR137MY1QSKIVRWYHTLSSQ2NZR9B81TON9QLPCZLQXG363GB0WSXMOS1ZMO5",

[0287] "signature": "7O6PRLXXB4ZFPPHK9X258SMV4OY2UKQVDR87ZNL9F7PNH06L0O5EZ8WHTZ6UVGZZ1IDPPJ97JV1HGK31MIPJQK7RZU0IQY3T0CV"

[0288] },

[0289] {

[0290] "id": 2,

[0291] "type": "split",

[0292] "source": "Kudos",

[0293] "quantity": 3,

[0294] "from": "CIDK3FPH9SIGJWMEAGXSMBEPCOLFCZSIA1P25DRJSNPFWHAFEAK8NSIU",

[0295] "to": "SDJF8723I4SMNKSDF912KHJKSDFSDF987DKK2KJ34MSDFHISUDF97234",

[0296] "public_key": "SDF9078ADSFHL34HL5KJ2H98D76SIH435908D7FGJH32459087DSFGLKHJ324598DS7FGLH3245987DSFG79854032LJSDFG987SDFGLK3J2LJDGFDK2JH34K2J3",

[0297] "signature": "KDIJD8D8EYUDNNBZZ76DS234987SDFDD8SJ74SJKHDDFJKSDHF89SDFKJWHERLKJSDLKSLASDMBNXCMNBQIWU987219080USDF0"

[0298] } ]

[0300] },

[0301] {

[0302] "Title": "Appreciation Kudos",

[0303] "parameters": [

[0304] {

[0305] "name": "Kudos",

[0306] "type": "number",

[0307] "value": 10,

[0308] "dividible": true

[0309] }

[0310] ],

[0311] "creator_address": "5XA5AH7B0N5FEMGX72KFLRLMOGFWIFSUWMOOSXUO7FUL2SSA7HXU5Q3",

[0312] "transactions": [

[0313] {

[0314] "id": 1,

[0315] "type": "transfer",

[0316] "from": "5XA5AH7B0N5FEMGX72KFLRLMOGFWIFSUWMOOSXUO7FUL2SSA7HXU5Q3",

[0317] "to": "CIDK3FPH9SIGJWMEAGXSMBEPCOLFCZSIA1P25DRJSNPFWHAFEAK8NSIU",

[0318] "public_key": "38FBF6P8VT33IV8TDT6APUD1G4UHVTRUN6OYAJPQA4QUTFX7Q6QH49ZDF53FRAUHOR137MY1QSKIVRWYHTLSSQ2NZR9B81TON9QLPCZLQXG363GB0WSXMOS1ZMO5",

[0319] "signature": "7O6PRLXXB4ZFPPHK9X258SMV4OY2UKQVDR87ZNL9F7PNH06L0O5EZ8WHTZ6UVGZZ1IDPPJ97JV1HGK31MIPJQK7RZU0IQY3T0CV"

[0320] },

[0321] {

[0322] "id": 2,

[0323] "type": "split",

[0324] "source": "Kudos",

[0325] "quantity": 2,

[0326] "from": "CIDK3FPH9SIGJWMEAGXSMBEPCOLFCZSIA1P25DRJSNPFWHAFEAK8NSIU",

[0327] "to": "S98DF7SDFKLJLRKJLSDF098SDFLKJ3LKJSDF09SD8FLK2J3RSD09F8FD",

[0328] "public_key": "SDF9078ADSFHL34HL5KJ2H98D76SIH435908D7FGJH32459087DSFGLKHJ324598DS7FGLH3245987DSFG79854032LJSDFG987SDFGLK3J2LJDGFDK2JH34K2J3",

[0329] "signature": "KJHASDF89A7DSFLJH2309SA7DFOAIHJLJAF9A8UL3J4AD90F8A7UFLADSFLKJADFHA90876FAOIUH2IU32O987AOIUFHAG0A9A8"

[0330] } ]

[0332] },

[0333] {

[0334] "Title": "Appreciation Kudos",

[0335] "parameters": [

[0336] {

[0337] "name": "Kudos",

[0338] "type": "number",

[0339] "value": 10,

[0340] "dividible": true

[0341] }

[0342] ],

[0343] "creator_address": "5XA5AH7B0N5FEMGX72KFLRLMOGFWIFSUWMOOSXUO7FUL2SSA7HXU5Q3",

[0344] "transactions": [

[0345] {

[0346] "id": 1,

[0347] "type": "transfer",

[0348] "from": "5XA5AH7B0N5FEMGX72KFLRLMOGFWIFSUWMOOSXUO7FUL2SSA7HXU5Q3",

[0349] "to": "CIDK3FPH9SIGJWMEAGXSMBEPCOLFCZSIA1P25DRJSNPFWHAFEAK8NSIU",

[0350] "public_key": "38FBF6P8VT33IV8TDT6APUD1G4UHVTRUN6OYAJPQA4QUTFX7Q6QH49ZDF53FRAUHOR137MY1QSKIVRWYHTLSSQ2NZR9B81TON9QLPCZLQXG363GB0WSXMOS1ZMO5",

[0351] "signature": "7O6PRLXXB4ZFPPHK9X258SMV4OY2UKQVDR87ZNL9F7PNH06L0O5EZ8WHTZ6UVGZZ1IDPPJ97JV1HGK31MIPJQK7RZU0IQY3T0CV"

[0352] },

[0353] {

[0354] "id": 2,

[0355] "type": "split",

[0356] "source": "Kudos",

[0357] "quantity": 5,

[0358] "from": "CIDK3FPH9SIGJWMEAGXSMBEPCOLFCZSIA1P25DRJSNPFWHAFEAK8NSIU",

[0359] "to": "CIDK3FPH9SIGJWMEAGXSMBEPCOLFCZSIA1P25DRJSNPFWHAFEAK8NSIU",

[0360] "public_key": "SDF9078ADSFHL34HL5KJ2H98D76SIH435908D7FGJH32459087DSFGLKHJ324598DS7FGLH3245987DSFG79854032LJSDFG987SDFGLK3J2LJDGFDK2JH34K2J3",

[0361] "signature": "KJLHADF09A8DSFLKJHQ39087ADOFHJASDF987A6SDFILKJQH3IAS90D8F7AOSIDFHJAKHJGFS8I76DSAUYGDHKSAJDHFGASDF7A"

[0362] } ]

[0364] } ]

[0366] As disclosed, the embodiments create a ledger database composed of individual files. For example, Alice's bank account is a file on her personal laptop. Bob's bank account is a file on his smartphone. They are the custodians of their own ledger history; however, modern encryption makes cheating impossible. This model virtually eliminates storage space limitations because large amounts of data are offloaded to the customer's own device. The controlled database in the embodiments does not need to store everything, but only a small checksum for each individual file. Therefore, a few bytes of database storage space can represent and verify gigabytes of application data offloaded to the consumer's own device.

[0367] The implementation examples enable the following example use cases:

[0368] 1. Tickets for concerts, sporting events, or ferries, etc. Entry is granted to the ticket holder by presenting a signed QR code image to a scanner. Tickets cannot be used twice. Tickets cannot be forged. Ticket theft is impossible without a private key.

[0369] 2. Tickets for purchasing food, beverages, and events at public gathering places, serving as a digital alternative to paper chain tickets (e.g., red coupons that say "Entry Permit"). This prevents losses caused by the use of invalid tickets. It eliminates the need to exchange tickets for cash, as people can load a credit limit on the tickets into their phone apps using credit cards, PayPal, etc.

[0370] 3. Lottery tickets. Same as above. People buy lottery tickets and receive an unforgeable digital certificate that can only be redeemed by the rightful owner.

[0371] 4. Guest credit at resorts or cruise ships. Guests can deposit their credit into their phones instead of onto a plastic card.

[0372] 5. Supply chain integrity. Pharmaceutical companies can ship drugs to retailers or hospitals and prove the drug's authenticity using a certificate showing a chain of signatures indicating all planned transfers (e.g., trucks, warehouses, etc.). Once sold / consumed, this certificate can no longer be used to identify another vial with a duplicate serial number.

[0373] 6. Video game consumer products, such as ownership of game maps or famous athlete cards in sports video games.

[0374] 7. Digital Securities Trading: Decentralized autonomous companies issue their shares in the form of distributed data records. Parties that can sign with private keys can vote and transfer them. Digital assets, such as data in databases, or token offerings, control of online organizations, or open-source projects, are examples of divisible assets not regulated by the U.S. Securities and Exchange Commission.

[0375] 8. Certificates of authenticity and ownership rights issued with the collectible or souvenir.

[0376] 9. Voting System. Each voter receives a unique certificate as a digital ballot, and then the signed final vote is sent to the polling station. Vote at home.

[0377] 10. Any contractual document that should be signed by the key holder, not an individual.

[0378] Compared to storing data in traditional databases or blockchains, this implementation has the following advantages:

[0379] 1. Complete privacy.

[0380] 2. Portability. Communities can create and record transactions on-site without developing or funding backend database solutions. They only need their smartphones or computers to post the records and trade them. The ability to build a trading system without database costs enables free, open-source work. For example, communities can develop open-source video games where players can exchange in-game consumer goods without developing or funding a backend system for trading items.

[0381] 3. Scalability. Since information is not stored in database nodes, storage allocation is not a challenge.

[0382] 4. Availability. In traditional database models, transactions cannot occur when the database is unavailable or unreachable. In contrast, in this embodiment, transactions occur on the user's own device, and the resulting updated records (with new transaction history and status) can be directly sent to another user.

[0383] 5. Verifiability. Through examples, when a party claims control of a record and lists it for private or public sale or use, other parties can quickly verify the record's integrity and legitimacy. For instance, if a party posts on a website that they are selling records, such as tickets, video game consumer goods, or title deeds, potential buyers will be able to verify the authenticity of the listed record and confirm that the seller does indeed control it—in other words, it is not counterfeit. The record owner can securely allow public inspection of the record and still maintain full control over it because the transaction must be digitally signed using a secret private key. Publicly exposing the record does not expose it to theft. This is a significant advantage because many times when people list digital goods (such as video game consumer goods or event tickets) for sale online, they are counterfeit or scams.

[0384] 6. Guaranteed Value. Users (or technically, their key pairs and addresses) cannot be banned from the system because no instance tracks such entities. Furthermore, administrators cannot alter records to increase or decrease their value because no such instance is exposed to or subject to the administrator's jurisdiction. These restrictions may be desirable protections in some use cases requiring ultimate trust. Optionally, it is also easy to guarantee a limited supply of records, allowing all participants (service providers and consumers) to determine that limited supply restrictions will be enforced (or in other words, that no new additional supply items will ever be released). This guarantee is possible and optional, and is useful for preventing corruption or the injection of counterfeit products into the supply chain. Value is guaranteed as long as the user does not lose the record or the private key controlling it.

[0385] This document specifically illustrates and / or describes several embodiments. However, it will be appreciated that the above teachings cover modifications and variations of the disclosed embodiments without departing from the spirit and intended scope of the invention, and such modifications and variations are within the scope of the appended claims.

Claims

1. A method of creating and verifying a digital record representing an asset, the method comprising: obtaining a first public key corresponding to a creator of the digital record and a first private key; generating one or more parameters for the digital record, wherein a first parameter of the parameters relates to a transaction of the digital record; generating one or more rules for the digital record, wherein a first rule of the rules corresponds to the first parameter and constrains the transaction; computing, using the first private key, a first digital signature of the first public key, the parameters, and the rules collectively; creating a first digital record comprising the first public key, the parameters, the rules, and the first digital signature; creating a checksum hash of the first digital record; and sending the checksum hash to an online repository, wherein the online repository is configured to use the checksum hash to verify that the first private key has not been used previously to create any prior digital records, wherein the inclusion of the rules in the created digital record causes each parameter with a rule to be compared when verifying the transaction of the digital record to check whether the transaction satisfies all rule requirements.

2. The method of claim 1, further comprising: in response to a first transaction transferring ownership of the asset from the creator to a second owner, appending the first transaction to the first digital record, wherein the first transaction includes the first public key and a second public key corresponding to the second owner; computing, using the first private key, a second digital signature of the first digital record and the first transaction collectively; creating a second digital record comprising the first digital record, the first transaction, and the second digital signature; and sending the second digital record to the second owner. The first parameter includes a quantity of transactions and the first rule includes a maximum quantity of transactions.

4. The method of claim 1, further comprising:

3. The method of claim 1, wherein, in response to a first transaction transferring ownership of the asset from the creator to a second owner, appending the first transaction to the first digital record, wherein the first transaction includes the first public key and a second hash value derived from a second public key corresponding to the second owner; computing, using the first private key, a second digital signature of the first digital record and the first transaction collectively; creating a second digital record comprising the first digital record, the first transaction, and the second digital signature; and sending the second digital record to the second owner.

5. The method of claim 1, further comprising a second parameter of the parameters, the second parameter being divisible into a plurality of portions such that ownership of the asset can be allocated to a plurality of different owners.

6. The method of claim 2, further comprising: at the second owner, verifying the first transaction, comprising: extracting the second digital signature and the second public key from the second digital record; removing the second digital signature and any additional transactions occurring after the first transaction from the second digital record to generate an original transaction message; using the second digital signature, the second public key, and the original transaction message as inputs to a verification function to confirm that the second digital signature was generated using the first private key. ​ ​ ​ 7. The method of claim 1, wherein, The online repository is configured to verify that a received second digital record generated in response to at least one transaction of a first digital record is valid by determining that the checksum hash is stored by the online repository using the checksum hash.

8. A computer-readable medium having stored thereon instructions that, when executed by a processor, cause the processor to create and verify a digital record representing an asset, the creating and verifying comprising: obtaining a first public key corresponding to a creator of the digital record and a first private key; generating one or more parameters for the digital record, wherein a first parameter of the parameters corresponds to a transaction of the digital record; generating one or more rules for the digital record, wherein a first rule of the rules corresponds to the first parameter and constrains the transaction; computing a first digital signature of the first public key, the parameters, and the rules collectively using the first private key; creating a first digital record comprising the first public key, the parameters, the rules, and the first digital signature; creating a checksum hash of the first digital record; and sending the checksum hash to an online repository, wherein the online repository is configured to verify that the first private key has not been used previously to create any prior digital records using the checksum hash, wherein including the rules in the created digital record causes each parameter with a rule to be compared when verifying the transaction of the digital record to check whether the transaction satisfies all rule requirements.

9. The computer-readable medium of claim 8, the creating and verifying further comprising: in response to a first transaction transferring ownership of the asset from the creator to a second owner, appending the first transaction to the first digital record, wherein the first transaction includes the first public key and a second public key corresponding to the second owner; computing a second digital signature of the first digital record and the first transaction collectively using the first private key; creating a second digital record comprising the first digital record, the first transaction, and the second digital signature; and sending the second digital record to the second owner.

10. The computer readable medium of claim 8, wherein, The first parameter includes a quantity of transactions and the first rule includes a maximum quantity of transactions.

11. The computer-readable medium of claim 8, the creating and verifying further comprising: in response to a first transaction transferring ownership of the asset from the creator to a second owner, appending the first transaction to the first digital record, wherein the first transaction includes the first public key and a second hash value derived from a second public key corresponding to the second owner; computing a second digital signature of the first digital record and the first transaction collectively using the first private key; creating a second digital record comprising the first digital record, the first transaction, and the second digital signature; and sending the second digital record to the second owner.

12. The computer-readable medium of claim 8, the creating and verifying further comprising a second parameter of the parameters, the second parameter being divisible into a plurality of portions such that ownership of the asset can be allocated to a plurality of different owners.

13. The computer-readable medium of claim 9, the creating and verifying further comprising: At the second owner, the first transaction is verified, including: extracting the second digital signature and the second public key from the second digital record; removing the second digital signature and any additional transactions that occurred after the first transaction from the second digital record to generate an original transaction message; using the second digital signature, the second public key, and the original transaction message as inputs to a verification function to confirm that the second digital signature was generated using the first private key.

14. The computer-readable medium of claim 8, wherein the online repository is configured to verify that a received second digital record generated in response to at least one transaction of the first digital record is valid by determining that the checksum hash is stored by the online repository using the checksum hash.

15. A digital record creation and verification system, the system comprising: a first public key and a first private key corresponding to a creator of the digital record, wherein the digital record represents an asset; a storage device storing one or more parameters for the digital record and storing one or more rules for the digital record, wherein a first parameter of the parameters relates to a transaction of the digital record, wherein a first rule of the rules corresponds to the first parameter and constrains the transaction; a processor adapted to execute instructions to compute a first digital signature of the first public key, the parameters, and the rules en masse using the first private key; create a first digital record comprising the first public key, the parameters, the rules, and the first digital signature; create a checksum hash of the first digital record; and send the checksum hash to an online repository; wherein the online repository is configured to verify that the first private key has not been used previously to create any prior digital records using the checksum hash, wherein including the rules in the created digital record causes each parameter with a rule to be compared when verifying the transaction of the digital record to check whether the transaction satisfies all rule requirements.

16. The system of claim 15, the processor further adapted to: in response to a first transaction transferring ownership of the asset from the creator to a second owner, append the first transaction to the first digital record, wherein the first transaction includes the first public key and a second public key corresponding to the second owner; using the first private key, compute a second digital signature of the first digital record and the first transaction en masse; create a second digital record comprising the first digital record, the first transaction, and the second digital signature; and send the second digital record to the second owner.

17. A system for creating and verifying a digital record representing an asset, comprising: one or more processors; and one or more computer-readable media having instructions stored thereon that, when executed by the one or more processors, cause the one or more processors to perform the method of any one of claims 1-7.

18. An apparatus comprising means for performing the method of any one of claims 1-7. ​ ​

Images