Scalable, secure, efficient, and adaptable distributed digital ledger transaction network

Abstract

The present disclosure relates to systems, methods, and non-transitory computer readable storage media for implementing a scalable, secure, efficient, and adaptable distributed digital ledger transaction network. Indeed, the disclosed systems can reduce storage and processing requirements, improve security of implementing computing devices and underlying digital assets, adapt to a variety of different digital programs (or "smart contracts"), and scale to accommodate billions of users and associated digital transactions. For example, the disclosed systems can utilize a number of features that improve storage, account / address management, digital transaction execution, consensus, and synchronization processes. The disclosed systems can also utilize a new programming language that improves the efficiency and security of the distributed digital ledger transaction network.

Description

[0001] Cross-references to related applications

[0002] This application claims priority to U.S. Application No. 16 / 442,470, filed June 15, 2019; U.S. Application No. 16 / 442,472, filed June 15, 2019; U.S. Application No. 16 / 442,473, filed June 15, 2019; U.S. Application No. 16 / 442,474, filed June 15, 2019; U.S. Application No. 16 / 442,475, filed June 15, 2019; and U.S. Application No. 16 / 442,476, filed June 15, 2019. For all purposes, the contents of U.S. Applications 16 / 442,470, 16 / 442,472, 16 / 442,473, 16 / 442,474, 16 / 442,475 and 16 / 442,476 are incorporated herein by reference in their entirety. background

[0003] In recent years, significant progress has been made in hardware and software platforms for managing distributed ledger databases across networks of computing devices. In fact, so-called "blockchain" systems can manage consensus ledgers via networks of entities distributed around the world without a central entity that could be compromised or otherwise manipulated, thus weakening the security and performance of the digital ledger. Specifically, traditional blockchain systems decentralize control by maintaining the digital ledger on many replicated servers or validator nodes. Algorithms, cryptography, and incentive mechanisms enable such networks of validator nodes to maintain a collective, tamper-proof ledger of transactions or other digital information. However, despite these advances, traditional blockchain systems still suffer from several technical drawbacks that weaken the efficiency, scalability, flexibility, and security of the implementing computing devices and corresponding distributed databases. For example, traditional blockchain systems often require considerable processing and storage for validator nodes and client devices interacting across the implementing network. As mentioned above, many traditional blockchain systems maintain replica databases across replicated servers storing the history of digital transactions. Furthermore, many traditional blockchain systems analyze transactions sequentially across validator nodes to reach consensus and ultimately update a distributed and duplicated ledger. This approach can place excessive storage and processing demands on computing devices. In fact, the demand for certain processing equipment has surged in recent years in proportion to the increased computational requirements of traditional blockchain systems in storing and analyzing transactions across distributed computer networks.

[0004] The inefficiencies of traditional blockchain systems also hinder their scalability. For example, the processing and storage burdens imposed by traditional blockchain systems reduce transaction throughput across the network, thus limiting the rate and number of transactions that traditional systems can manage. Therefore, traditional blockchain systems typically lack the scalability to provide a globally distributed computing solution for managing digital transactions. In fact, to date, traditional blockchain systems have often been limited to a small niche user base, excluding billions of users from accessing and utilizing blockchain technology.

[0005] Besides efficiency and scalability concerns, traditional blockchain systems are also rigid and inflexible. For example, traditional blockchain systems offer limited choices regarding different programs, transactions, contracts, assets, and / or resources that can be adapted or executed via a distributed database. Furthermore, traditional blockchain systems offer limited control over storage at validator nodes, limited flexibility in executing transactions at validator nodes, and limited choices regarding authentication keys and verification methods used by account holders and client devices to access the network.

[0006] As mentioned above, traditional blockchain systems are also vulnerable to inaccuracy and / or digital security attacks. For example, validator node groups can reach consensus on different versions of the digital ledger, leading to inaccuracies, hard forks, and insecurity in the underlying digital information. Some traditional systems perform consensus on transaction blocks, assuming that transaction execution is deterministic; therefore, any non-deterministic execution can lead to inaccurate results at individual devices (or inaccuracies propagating across the digital ledger). Furthermore, many traditional systems utilize Bloom filters when providing transaction details in response to queries, risking false positives and failing to provide the ability to verify the accuracy of account data with negative proofs. Additionally, traditional blockchain systems often provide unrestricted access to the digital assets stored in user accounts, exposing all assets to malicious attacks if the private keys associated with user accounts are lost. Moreover, because many traditional systems perform reference security analysis on the source code when the program is executed at the machine code level, many such systems inaccurately identify reference security issues and / or introduce vectors for malicious attacks.

[0007] Regarding traditional blockchain systems, there are these, as well as additional issues and points of contention. Overview

[0008] The one or more embodiments described herein utilize systems, methods, and non-transitory computer-readable storage media for implementing scalable, secure, efficient, and adaptable distributed digital ledger transaction networks to provide benefits and / or solve one or more of the foregoing or other problems in the art. In fact, the disclosed systems can reduce storage and processing requirements, improve the security of implementing computing devices and underlying digital assets, adapt to a wide variety of digital programs (or "smart contracts"), and scale to accommodate billions of users and associated digital transactions, wherein the digital assets involved in this application comply with the relevant laws and regulations of the People's Republic of China.

[0009] For example, the disclosed system can make data storage more scalable and efficient by treating the consensus-reaching blockchain as a single data structure that records the history of transactions and states over time. This implementation simplifies the work of computing devices accessing the blockchain, allowing them to read data from any point in time and verify integrity using a unified framework. Similarly, to reach consensus among validator nodes, the disclosed system can utilize a unique Byzantine-fault-tolerant consensus protocol. Compared to other blockchains, this approach offers high transaction throughput, low latency, and a more computationally efficient method for reaching consensus.

[0010] Furthermore, the disclosed system can utilize novel programming languages ​​to implement smart contracts on the blockchain. In particular, these novel programming languages ​​make writing code to fulfill user intent inherently easier, thereby avoiding unintentional bugs or security incidents (e.g., preventing asset cloning). Specifically, the disclosed system can utilize programming languages ​​that enable linear data types, which constrain digital assets to the properties of physical assets (e.g., single owner, consumption only once, restrictions on creating new resources). In some embodiments, the disclosed system also utilizes an implementation programming language with a tree-structured memory model to improve reference security analysis. Using such a programming language, the disclosed system can implement static-dynamic reference security analysis at the bytecode level, which reduces the vectors for malicious attacks.

[0011] Furthermore, the disclosed system offers numerous additional features for improved storage, account / address management, digital transaction execution, consensus, and synchronization processes. For example, regarding storage, the disclosed system can implement flexible storage deletion and / or storage merging strategies, allowing individual computer nodes to delete distributed data structures while retaining sufficient ledger information to accurately reach consensus across the distributed digital ledger transaction network. The disclosed system can also implement a lazy account eviction policy, allowing for more flexible storage management based on individual preferences and / or the availability of computer memory or processing power on individual computing devices. The disclosed system can also utilize a unique scratchpad data structure, which flexibly tracks changes to the digital ledger while awaiting consensus.

[0012] Similarly, the disclosed system can provide various improvements regarding user accounts, addresses, and account data accessible on the digital ledger. For illustration, the disclosed system can utilize re-encrypted sub-addresses to avoid tracing account activity across the network. The disclosed system can reduce barriers to initiating transactions by using email addresses (or other user identifiers) to determine and encrypt the main address and sub-address identifiers corresponding to the distributed ledger. Furthermore, the disclosed system can separate smart contract code from smart contract data within user accounts, allowing individual accounts to store multiple smart contracts, delegate account permissions to other user accounts on the digital ledger, and decouple account addresses from cryptographic keys (allowing accounts to flexibly rotate authenticated keys to improve network-wide security).

[0013] Furthermore, the disclosed system can improve the execution of digital transactions across a distributed digital ledger transaction network. For example, the disclosed system can use arbitrary transaction scripts and configurable smart contracts to manage tasks surrounding transaction execution to implement transactions on the network. For illustration, in some embodiments, the disclosed system can leverage configurable smart contracts to accept / reject transactions, deduct gas payments, increment sequence numbers, and allocate gas to computer nodes (and flexibly modify these processes via consensus as the needs of the distributed digital ledger transaction network change over time). In some embodiments, the disclosed system further improves transaction execution by performing speculative parallel execution of transactions to reduce the time and computational overhead required to execute transaction blocks, utilizing access restrictions to reduce the exposure of digital assets due to the theft or loss of access keys, and using transaction event counters to accurately identify transaction event details and perform reverse proofs.

[0014] In addition to improvements in digital transaction execution, the disclosed system can also improve the consensus process relative to traditional systems. For example, the disclosed system can improve accuracy by performing consensus on a state data structure that reflects the execution results (rather than on potentially nondeterministic transactions). The disclosed system can also implement consensus pipeline rules to ensure that the submitted ledger accurately reflects the state of the digital ledger. In some embodiments, the disclosed system further implements a system restart protocol to maintain network consensus security (e.g., even when all nodes experience a shutdown). Furthermore, the disclosed system can effectively, flexibly, and accurately control the validator nodes participating in consensus by managing the epochs of voting rights via smart contracts.

[0015] In addition to the aforementioned improvements, the disclosed system can also improve the synchronization process across distributed digital ledger transaction networks. For example, the disclosed system can improve the efficiency of synchronization across distributed digital ledger transaction networks by implementing incremental and parallel verification at each computer node synchronized with the network. Furthermore, in some embodiments, the disclosed system utilizes waypoints (e.g., published indicators of a specific ground-truth reference state) to facilitate the synchronization of computer nodes with the network (e.g., correcting conflicting digital ledger states, generating hard forks, or implementing genesis blocks).

[0016] The present invention relates to a first method comprising: generating an authenticated data structure for a distributed digital ledger transaction network, wherein the authenticated data structure includes a data tree comprising nodes having data representations of entries mapped to a database; and performing lazy deletion of data from the authenticated data structure by: accessing the data representation from a node of the data tree to determine the expiration date of an eviction date associated with the node, and in response to determining the expiration date, deleting one or more entries corresponding to that node from the database while maintaining the data representation within the data tree.

[0017] In an embodiment of the first method according to the invention, the method may further include deleting one or more entries corresponding to the node from the database without a transaction event request for deleting one or more entries on the distributed digital ledger transaction network.

[0018] In another embodiment of the first method according to the invention, the method may further include: receiving a request from a client device prior to deleting one or more entries corresponding to the node from the database, the request requesting the use of one or more entries; in response to receiving the request from the client device, accessing a data representation from a node in the data tree to determine the expiration date; and processing the request as if one or more entries had already been deleted.

[0019] In another embodiment of the first method according to the present invention, the database may include a state database, one or more entries may include account data corresponding to a user account, the data tree may include a state tree, and the nodes may include an account state representation corresponding to the account data of the user account.

[0020] In another embodiment of the first method according to the invention, the method may further include: in response to receiving a transaction referencing a user account, accessing an account status representation corresponding to the user account from a state tree to determine the expiration date; and processing the transaction as if the user account had already expired.

[0021] In another embodiment of the first method according to the invention, the method may further include: identifying an account reinstatement request associated with a user account, wherein the account reinstatement request includes proposed account data of the user account; and verifying the proposed account data of the user account based on an account state representation in a state tree.

[0022] In another embodiment of the first method according to the invention, the method may further include re-caching the proposed account data associated with the user account in the state database of the distributed digital ledger transaction network based on the proposed account data that verifies the user account.

[0023] In another embodiment of the first method according to the invention, the method may further include updating the eviction date associated with the node based on recaching the proposed account data associated with the user account.

[0024] In another embodiment of the first method according to the invention, the method may further include generating an account state representation by: applying a hash function to account data corresponding to a user account in a state database to generate a hash value of the account data corresponding to the user account; and combining the hash value of the account data with an eviction date associated with the user account to generate an account state representation corresponding to the user account.

[0025] In another embodiment of the first method according to the invention, the method may further include determining the expiration date based on at least one of the following: the rental storage amount, the time of the last access to the user account, the time of the transaction in which digital assets were transferred from the user account, or the time of the transaction in which digital assets were transferred to the user account.

[0026] The present invention also relates to a first non-transitory computer-readable medium having instructions stored thereon, which, when executed by at least one processor, cause a computing device to: generate an authenticated data structure for a distributed digital ledger transaction network, wherein the authenticated data structure includes a data tree comprising nodes having data representations of entries mapped to a database; and perform lazy deletion of data from the authenticated data structure by: accessing the data representation from a node of the data tree to determine the expiration date of an eviction date associated with the node, and in response to determining the expiration date, deleting one or more entries corresponding to that node from the database while maintaining the data representation within the data tree.

[0027] In an embodiment of the first non-transitory computer-readable medium according to the invention, the non-transitory computer-readable medium may further include instructions that, when executed by at least one processor, cause a computing device to delete one or more entries corresponding to a node from a database without a transaction event request for deleting one or more entries on a distributed digital ledger transaction network.

[0028] In another embodiment of the first non-transitory computer-readable medium according to the invention, the non-transitory computer-readable medium may further include instructions that, when executed by at least one processor, cause a computing device to: receive a request from a client device, the request requesting the use of one or more entries, before deleting one or more entries corresponding to a node from the database; in response to receiving the request from the client device, access a data representation from a node of a data tree to determine the expiration date; and process the request as if one or more entries had already been deleted.

[0029] In an embodiment of the first non-transitory computer-readable medium according to the invention, the database may include a state database, one or more entries may include account data corresponding to a user account, the data tree may include a state tree, and the nodes may include an account state representation corresponding to the account data of the user account.

[0030] In an embodiment of the first non-transitory computer-readable medium according to the invention, the non-transitory computer-readable medium may further include instructions that, when executed by at least one processor, cause a computing device to: identify an account recovery request associated with a user account, wherein the account recovery request includes proposed account data of the user account; verify the proposed account data of the user account based on an account state representation within a state tree; re-cach the proposed account data associated with the user account in a state database of a distributed digital ledger transaction network based on the verification of the proposed account data of the user account; and update the eviction date associated with the node based on the re-caching of the proposed account data associated with the user account.

[0031] In an embodiment of the first non-transitory computer-readable medium according to the invention, the non-transitory computer-readable medium may further include instructions that, when executed by at least one processor, cause a computing device to generate an account status representation by: applying a hash function to account data corresponding to a user account in a status database to generate a hash value of the account data corresponding to the user account; and combining the hash value of the account data with an eviction date associated with the user account to generate an account status representation corresponding to the user account.

[0032] The present invention also relates to a first system comprising: at least one processor; and at least one non-transitory computer-readable medium having instructions stored thereon, which, when executed by the at least one processor, cause the system to: generate an authenticated data structure for a distributed digital ledger transaction network, wherein the authenticated data structure includes a data tree comprising nodes having data representations of entries mapped to a database; and perform lazy deletion of data from the authenticated data structure by: accessing the data representation from a node of the data tree to determine the expiration date of an eviction date associated with the node, and in response to determining the expiration date, deleting one or more entries corresponding to that node from the database while maintaining the data representation within the data tree.

[0033] In an embodiment of the first system according to the invention, the system may further include instructions that, when executed by at least one processor, cause the system to delete one or more entries corresponding to a node from the database without any transaction event request on the distributed digital ledger transaction network for deleting one or more entries.

[0034] In another embodiment of the first system according to the invention, the system may further include instructions that, when executed by at least one processor, cause the system to: receive a request from a client device for using one or more entries corresponding to a node before deleting them from the database; in response to receiving the request from the client device, access a data representation from a node of the data tree to determine the expiration date; and process the request as if one or more entries had already been deleted.

[0035] In another embodiment of the first system according to the invention, the database may include a state database, one or more entries may include account data corresponding to user accounts, the data tree may include a state tree, and the nodes may include account state representations corresponding to the account data of user accounts; and the system may further include instructions that, when executed by at least one processor, cause the system to: identify an account recovery request associated with a user account, wherein the account recovery request includes proposed account data of the user account; and verify the proposed account data of the user account based on the account state representation in the state tree; based on the verification of the proposed account data of the user account, re-cach the proposed account data associated with the user account in the state database of the distributed digital ledger transaction network; and based on the re-caching of the proposed account data associated with the user account, update the eviction date associated with the node.

[0036] The present invention relates to a second method comprising: generating a request for a transaction between a first user account and a second user account in a distributed digital ledger transaction network by: identifying a primary public address identifier corresponding to the second user account, a sub-address identifier corresponding to the second user account, and a public encryption key; generating a transaction-unique encrypted sub-address by applying the public encryption key to the sub-address identifier; and submitting the request for the transaction between the first user account and the second user account using the primary public address identifier and the transaction-unique encrypted sub-address for execution via the distributed digital ledger transaction network.

[0037] In an embodiment of the second method according to the present invention, generating a unique encrypted sub-address for a transaction may include: adding a nonce value to the sub-address identifier; and applying a public encryption key to the sub-address identifier having a random value.

[0038] In another embodiment of the second method according to the present invention, identifying the main public address identifier corresponding to the second user account, the sub-address identifier corresponding to the second user account, and the public encryption key may include scanning the digital visual codes encoded by the main public address identifier, the sub-address identifier, and the public encryption key.

[0039] In an embodiment of the second method according to the present invention, the method may further include identifying a primary public address identifier, a sub-address identifier, and a public encryption key based on the email address of the user corresponding to the second user account.

[0040] In another embodiment of the second method according to the invention, identifying the primary public address identifier, the sub-address identifier, and the public encryption key may include: identifying a domain name and a personal email identifier from the email address of the user corresponding to the second user account; determining the primary public address identifier based on the domain name from the email address; and determining the sub-address identifier based on the personal email identifier from the email address.

[0041] In another embodiment of the second method according to the invention, determining the primary public address identifier based on the domain name may include accessing the DNS record corresponding to the domain name to identify at least one of the following: the primary public address identifier or the public encryption key.

[0042] In another embodiment of the second method according to the invention, the method may further include using DNSSEC to verify the main public address identifier or public encryption key identified by accessing the DNS record corresponding to the domain name.

[0043] In another embodiment of the second method according to the invention, generating an encrypted sub-address may include applying a public encryption key determined by accessing a DNS record to a sub-address identifier determined based on a personal email identifier.

[0044] In another embodiment of the second method according to the invention, identifying the main public address identifier, the sub-address identifier, and the public encryption key may include receiving the public encryption key from the remote server corresponding to the domain name in response to providing a personal email identifier from the email address to the remote server corresponding to the domain name.

[0045] In another embodiment of the second method according to the invention, the method may further include identifying the main public address identifier, the sub-address identifier, and the public encryption key based on at least one of the following: the phone number of the user corresponding to the second user account or the user ID of the user.

[0046] The present invention also relates to a second non-transitory computer-readable medium having instructions stored thereon, which, when executed by at least one processor, cause a computing device to: generate a request for a transaction between a first user account and a second user account in a distributed digital ledger transaction network by: identifying a primary public address identifier corresponding to the second user account, a sub-address identifier corresponding to the second user account, and a public encryption key; generating a transaction-unique encrypted sub-address by applying the public encryption key to the sub-address identifier; and submitting the request for the transaction between the first user account and the second user account using the primary public address identifier and the transaction-unique encrypted sub-address for execution via the distributed digital ledger transaction network.

[0047] In an embodiment of the second non-transitory computer-readable medium according to the present invention, generating a cryptographic sub-address unique to the transaction may include:

[0048] Add a random value to the sub-address identifier; and apply the public encryption key to the sub-address identifier with the random value.

[0049] In an embodiment of the second non-transitory computer-readable medium according to the present invention, identifying the main public address identifier corresponding to the second user account, the sub-address identifier corresponding to the second user account, and the public encryption key may include scanning digital visual codes encoded with the main public address identifier, the sub-address identifier, and the public encryption key.

[0050] In another embodiment of the second non-transitory computer-readable medium according to the invention, the non-transitory computer-readable medium may further include instructions that, when executed by at least one processor, cause a computing device to identify a primary public address identifier, a sub-address identifier, and a public encryption key based on an email address of a user corresponding to a second user account; and wherein identifying the primary public address identifier, the sub-address identifier, and the public encryption key may include: identifying a domain name and a personal email identifier from an email address of a user corresponding to a second user account; determining the primary public address identifier based on the domain name from the email address; and determining the sub-address identifier based on the personal email identifier from the email address.

[0051] In another embodiment of the second non-transitory computer-readable medium according to the invention, determining the primary public address identifier based on the domain name may include accessing a DNS record corresponding to the domain name to identify at least one of the primary public address identifier or a public encryption key; and generating an encrypted sub-address includes applying the public encryption key determined by accessing the DNS record to a sub-address identifier determined based on a personal email identifier.

[0052] In yet another embodiment of the second non-transitory computer-readable medium according to the invention, identifying the main public address identifier, the sub-address identifier, and the public encryption key may include receiving the public encryption key from the remote server corresponding to the domain name in response to providing a personal email identifier from the email address to the remote server corresponding to the domain name.

[0053] The invention also relates to a second system comprising: at least one processor; and at least one non-transitory computer-readable medium having instructions stored thereon, which, when executed by the at least one processor, cause the system to: generate a request for a transaction between a first user account and a second user account in a distributed digital ledger transaction network by: identifying a primary public address identifier corresponding to the second user account, a sub-address identifier corresponding to the second user account, and a public encryption key; generating a transaction-unique encrypted sub-address by applying the public encryption key to the sub-address identifier; and submitting the request for the transaction between the first user account and the second user account using the primary public address identifier and the transaction-unique encrypted sub-address for execution via the distributed digital ledger transaction network.

[0054] In an embodiment of the second system according to the present invention, identifying the primary public address identifier corresponding to the second user account, the sub-address identifier corresponding to the second user account, and the public encryption key may include scanning the digital visual codes encoded with the primary public address identifier, the sub-address identifier, and the public encryption key.

[0055] In another embodiment of the second system according to the invention, the system may further include instructions that, when executed by at least one processor, cause the system to identify a primary public address identifier, a sub-address identifier, and a public encryption key based on the email address of a user corresponding to a second user account.

[0056] In another embodiment of the second system according to the invention, the system may further include instructions that, when executed by at least one processor, cause the system to identify a primary public address identifier, a sub-address identifier, and a public encryption key based on an email address corresponding to a user of a second user account; and wherein identifying the primary public address identifier, the sub-address identifier, and the public encryption key may include: identifying a domain name and a personal email identifier from an email address corresponding to a user of a second user account; determining the primary public address identifier based on the domain name from the email address; and determining the sub-address identifier based on the personal email identifier from the email address.

[0057] The present invention relates to a third method comprising: determining a first state data structure of a distributed digital ledger transaction network, wherein the first state data structure represents the account status of multiple user accounts of the distributed digital ledger transaction network; identifying multiple transactions including transactions associated with user accounts among the multiple user accounts; performing pre-execution of the transactions in parallel with respect to the first state data structure to determine the results of the multiple transactions and the dependencies of the transactions on the user accounts; and modifying the first state data structure into a second state data structure by applying the results of the multiple transactions based on the dependencies of the transactions.

[0058] In an embodiment of the third method according to the present invention, the second state data structure can be equivalent to executing multiple transactions serially against the first state data structure.

[0059] In another embodiment of the third method according to the invention, the transaction includes a first transaction and a second transaction, and performing the pre-execution may include: determining a first transaction result reflecting the application of the first transaction with respect to a first state data structure; determining a second transaction result reflecting the application of the second transaction with respect to the first state data structure; and determining that the second transaction is independent of the first transaction and the first transaction is independent of the second transaction.

[0060] In yet another embodiment of the third method according to the invention, the method may further include applying the first transaction result and the second transaction result to the first state data structure based on determining that the second transaction is independent of the first transaction and the first transaction is independent of the second transaction.

[0061] In another embodiment of the third method according to the present invention, the method may further include generating an intermediate state data structure by applying a first transaction result to a first state data structure.

[0062] In another embodiment of the third method according to the invention, the transaction may include a third transaction, and performing prior execution includes: determining a third transaction result that reflects the application of the third transaction with respect to the first state data structure; and determining that the third transaction depends on the first transaction.

[0063] In yet another embodiment of the third method according to the invention, the method may further include, in response to determining that a third transaction depends on a first transaction, performing a third transaction on an intermediate state data structure to generate a second state data structure.

[0064] In another embodiment of the third method according to the invention, determining the third transaction depends on the first transaction, which includes determining that the third transaction and the first transaction are associated with the same user account from the user account.

[0065] In another embodiment of the third method according to the invention, the method may further include: receiving dependency indicators of a plurality of transactions from a validator node; and identifying a first subset and a second subset of the plurality of transactions based on the dependency indicators, wherein performing pre-execution of transactions includes performing pre-execution of the first subset of the plurality of transactions based on the dependency indicators.

[0066] In another embodiment of the third method according to the invention, the method may further include: generating an intermediate state data structure based on transaction results obtained from the prior execution of a first subset of a plurality of transactions; and generating a second state data structure by executing a second subset of the plurality of transactions with respect to the intermediate state data structure.

[0067] The present invention also relates to a third non-transitory computer-readable medium having instructions stored thereon that, when executed by at least one processor, cause a computing device to: determine a first state data structure of a distributed digital ledger transaction network, wherein the first state data structure represents the account status of a plurality of user accounts of the distributed digital ledger transaction network; identify a plurality of transactions including transactions associated with user accounts among the plurality of user accounts; perform pre-execution of the transactions in parallel with respect to the first state data structure to determine the results of the plurality of transactions and the dependencies of the transactions on user accounts; and modify the first state data structure into a second state data structure by applying the results of the plurality of transactions based on the dependencies of the transactions.

[0068] In an embodiment of the third non-transitory computer-readable medium according to the invention, the second state data structure can be equivalent to executing multiple transactions serially against the first state data structure.

[0069] In an embodiment of the third non-transitory computer-readable medium according to the invention: a transaction may include a first transaction and a second transaction; and instructions, when executed by at least one processor, cause a computing device to perform pre-execution by: determining a first transaction result reflecting the application of the first transaction with respect to a first state data structure; determining a second transaction result reflecting the application of the second transaction with respect to the first state data structure; and determining that the second transaction is independent of the first transaction and the first transaction is independent of the second transaction.

[0070] In an embodiment of the third non-transitory computer-readable medium according to the invention, the non-transitory computer-readable medium may further include instructions that, when executed by at least one processor, enable a computing device to apply the results of the first transaction and the second transaction to a first state data structure based on the determination that the second transaction is independent of the first transaction and the first transaction is independent of the second transaction.

[0071] In another embodiment of the third non-transitory computer-readable medium according to the invention, the non-transitory computer-readable medium may further include instructions that, when executed by at least one processor, cause a computing device to generate an intermediate state data structure by applying a first transaction result to a first state data structure.

[0072] In yet another embodiment of the third non-transitory computer-readable medium according to the invention, a transaction may include a third transaction; and instructions, when executed by at least one processor, may cause a computing device to perform pre-execution by: determining a third transaction result reflecting the application of the third transaction with respect to a first state data structure; and determining that the third transaction depends on the first transaction.

[0073] The present invention also relates to a third system comprising: at least one processor; and at least one non-transitory computer-readable medium having instructions stored thereon, which, when executed by the at least one processor, cause the system to: determine a first state data structure of a distributed digital ledger transaction network, wherein the first state data structure represents the account status of a plurality of user accounts of the distributed digital ledger transaction network; identify a plurality of transactions including transactions associated with user accounts among the plurality of user accounts; perform pre-execution of the transactions in parallel with respect to the first state data structure to determine the results of the plurality of transactions and the dependencies of the transactions on user accounts; and modify the first state data structure into a second state data structure by applying the results of the plurality of transactions based on the dependencies of the transactions.

[0074] In an embodiment of the third system according to the invention, the second state data structure can be equivalent to executing multiple transactions serially against the first state data structure.

[0075] In an embodiment of the third system according to the invention, the system may further include instructions that, when executed by at least one processor, cause the system to: receive dependency indicators of a plurality of transactions from a validator node; and identify a first subset and a second subset of the plurality of transactions based on the dependency indicators, wherein the instructions, when executed by at least one processor, cause a computing device to perform pre-execution of the transactions by performing pre-execution of the first subset of the plurality of transactions based on the dependency indicators.

[0076] In another embodiment of the third system according to the invention, the system may further include instructions that, when executed by at least one processor, cause the system to: generate an intermediate state data structure based on transaction results obtained from the prior execution of a first subset of a plurality of transactions; and generate a second state data structure by executing a second subset of the plurality of transactions with respect to the intermediate state data structure.

[0077] The present invention also relates to a fourth method, comprising: generating a state data structure for a distributed digital ledger transaction network, wherein the state data structure includes account data corresponding to a user account, a transaction event counter corresponding to the user account, and an address of the user account within the state data structure; in response to executing a transaction including an event corresponding to the user account in the distributed digital ledger transaction network: modifying the count value of the transaction event counter for the user account within the state data structure; and generating a transaction event within an event data structure, the transaction event within the event data structure reflecting the address, the count value of the transaction event counter for the user account, and details of the event.

[0078] In an embodiment of the fourth method according to the present invention, the state data structure may include an additional transaction event counter corresponding to a user account, the transaction event counter may correspond to a first transaction event type, and the additional transaction event counter may correspond to a second transaction event type.

[0079] In another embodiment of the fourth method according to the present invention, modifying the count value of the transaction event counter of the user account may include: determining that the transaction event corresponds to a first transaction event type; and modifying the count value of the transaction event counter based on determining that the transaction event corresponds to the first transaction event type.

[0080] In another embodiment of the fourth method according to the present invention, the transaction may include an additional event of a second transaction event type, and the method may further include: modifying an additional count value of an additional transaction event counter for a user account within a state data structure; and generating an additional transaction event within an event data structure, the additional transaction event in the event data structure reflecting the address, the additional count value of the additional transaction event counter for the user account, and details of the additional event.

[0081] In another embodiment of the fourth method according to the invention, the event data structure may include an event tree reflecting transaction events generated in response to the execution of a transaction.

[0082] In another embodiment of the fourth method according to the present invention, the method may further include: determining the root value of an event tree reflecting a transaction event corresponding to a transaction; and storing the root value of the event tree in the transaction tree of a distributed digital ledger transaction network.

[0083] In another embodiment of the fourth method according to the present invention, the method may further include: receiving an event counting request from a client device, the event counting request including a reference to a transaction event counter; and in response to receiving the event counting request from the client device, providing a modified count value of the transaction event counter from a state data structure to the client device.

[0084] In another embodiment of the fourth method according to the invention, a reference to the transaction event counter may include an access path that reflects both the address and the transaction event counter.

[0085] In another embodiment of the fourth method according to the present invention, the method may further include: receiving a transaction event details request from a client device, the transaction event details request including a count value of a transaction event counter and an access path including an address and the transaction event counter; and in response to receiving the transaction event details request, providing details of the event from the event data structure together with a Merkle proof corresponding to the transaction event to the client device.

[0086] The present invention also relates to a fourth non-transitory computer-readable medium having instructions stored thereon that, when executed by at least one processor, cause a computing device to: generate a state data structure for a distributed digital ledger transaction network, wherein the state data structure includes account data corresponding to a user account, a transaction event counter corresponding to the user account, and an address of the user account within the state data structure; in response to executing a transaction including an event corresponding to the user account in the distributed digital ledger transaction network: modify the count value of the transaction event counter for the user account within the state data structure; and generate a transaction event within an event data structure, the transaction event within the event data structure reflecting the address, the count value of the transaction event counter for the user account, and details of the event.

[0087] In an embodiment of the fourth non-transitory computer-readable medium according to the present invention, the state data structure may include an additional transaction event counter corresponding to a user account, the transaction event counter may correspond to a first transaction event type, and the additional transaction event counter may correspond to a second transaction event type.

[0088] In another embodiment of the fourth non-transitory computer-readable medium according to the invention, the non-transitory computer-readable medium may further include instructions that, when executed by at least one processor, cause a computing device to modify the count value of a transaction event counter for a user account by: determining that a transaction event corresponds to a first transaction event type; and modifying the count value of the transaction event counter based on the determination that the transaction event corresponds to the first transaction event type.

[0089] In another embodiment of the fourth non-transitory computer-readable medium according to the invention, the transaction may include additional events of a second transaction event type, and the non-transitory computer-readable medium may further include instructions that, when executed by at least one processor, cause a computing device to: modify an additional count value of an additional transaction event counter for a user account within a state data structure; and generate an additional transaction event within an event data structure, the additional transaction event in the event data structure reflecting an address, the additional count value of the additional transaction event counter for the user account, and details of the additional event.

[0090] In another embodiment of the fourth non-transitory computer-readable medium according to the invention, the event data structure may include an event tree reflecting transaction events generated in response to the execution of a transaction, and the non-transitory computer-readable medium may also include instructions that, when executed by at least one processor, cause a computing device to: determine the root value of the event tree reflecting the transaction events corresponding to the transaction; and store the root value of the event tree in the transaction tree of a distributed digital ledger transaction network.

[0091] In another embodiment of the fourth non-transitory computer-readable medium according to the invention, the non-transitory computer-readable medium may further include instructions that, when executed by at least one processor, cause a computing device to: receive an event counting request from a client device, the event counting request including a reference to a transaction event counter; and, in response to receiving the event counting request from the client device, provide a modified count value of the transaction event counter from a state data structure to the client device.

[0092] In yet another embodiment of the fourth non-transitory computer-readable medium according to the invention, the non-transitory computer-readable medium may further include instructions that, when executed by at least one processor, cause a computing device to: receive a transaction event details request from a client device, the transaction event details request including a count value of a transaction event counter and an access path including an address and the transaction event counter; and, in response to receiving the transaction event details request, provide details of an event from an event data structure together with a Merkle proof corresponding to the transaction event to the client device.

[0093] The present invention also relates to a fourth system comprising: at least one processor; and at least one transient computer-readable medium having instructions stored thereon, which, when executed by the at least one processor, cause the system to: generate a state data structure for a distributed digital ledger transaction network, wherein the state data structure includes account data corresponding to a user account, a transaction event counter corresponding to the user account, and an address of the user account within the state data structure; in response to executing a transaction including an event corresponding to the user account in the distributed digital ledger transaction network: modify the count value of the transaction event counter for the user account within the state data structure; and generate a transaction event within an event data structure, the transaction event within the event data structure reflecting the address, the count value of the transaction event counter for the user account, and details of the event.

[0094] In an embodiment of the fourth system according to the invention, the state data structure may include an additional transaction event counter corresponding to a user account, the transaction event counter may correspond to a first transaction event type, and the additional transaction event counter may correspond to a second transaction event type; and wherein, when executed by at least one processor, the instructions cause the system to modify the count value of the transaction event counter of the user account by: determining that a transaction event corresponds to the first transaction event type; and modifying the count value of the transaction event counter based on determining that the transaction event corresponds to the first transaction event type.

[0095] In another embodiment of the fourth system according to the invention, the system may further include instructions that, when executed by at least one processor, cause the system to: receive an event counting request from a client device, the event counting request including a reference to a transaction event counter; and, in response to receiving the event counting request from the client device, provide a modified count value of the transaction event counter from a state data structure to the client device.

[0096] In another embodiment of the first system according to the invention, the system may further include instructions that, when executed by at least one processor, cause the system to: receive a transaction event details request from a client device, the transaction event details request including a count value of a transaction event counter and an access path including an address and the transaction event counter; and, in response to receiving the transaction event details request, provide details of the event from an event data structure together with a Merkle proof corresponding to the transaction event to the client device.

[0097] The present invention also relates to a fifth method, comprising: monitoring a transaction event counter corresponding to a user account and storing a state data structure at a computer node in a distributed digital ledger transaction network; transmitting a request for transaction event details from transaction event data stored in an event data structure at one or more computer nodes in the distributed digital ledger transaction network; and, in response to the request for transmitting transaction event details, receiving, via one or more computer nodes, transaction event data corresponding to a count value determined from the transaction event counter.

[0098] In an embodiment of the fifth method according to the present invention, the method may further include determining the count value of the transaction event counter based on monitoring the transaction event counter, wherein the transaction event details request includes the count value of the transaction event counter and the access path of the transaction event counter corresponding to the user account within the state data structure.

[0099] In another embodiment of the fifth method according to the present invention, monitoring the transaction event counter may include polling the transaction event counter at a computer node, and the method may further include: determining the count value of the transaction event counter at a first time; and determining an additional count value of the transaction event counter at a second time.

[0100] In another embodiment of the fifth method according to the present invention, the method may further include verifying that there is no event corresponding to the user account between the first time and the second time by determining that the count value of the transaction event counter at the first time and the additional count value of the transaction event counter at the second time are the same count value.

[0101] In another embodiment of the fifth method according to the invention, the method may further include determining a sequence of count values ​​indicating that a sequence of events corresponding to a user account has occurred via the distributed digital ledger transaction network, based on comparing the count value of the transaction event counter at a first time and an additional count value of the transaction event counter at a second time.

[0102] In another embodiment of the fifth method according to the present invention: transmitting a request for transaction event details may include transmitting a request for a sequence of transaction events for a sequence of events; and receiving transaction event data may include receiving a set of transaction event data corresponding to multiple events.

[0103] In another embodiment of the fifth method according to the invention, the method may further include: comparing a set of transaction event data corresponding to multiple events with a sequence of count values ​​to determine that: the multiple events are a complete set of event sequences; or the multiple event set is an incomplete set of event sequences.

[0104] In another embodiment of the fifth method according to the invention, the event data structure may include an event Merkle tree, and the state data structure may include a state Merkle tree; and receiving transaction event data may include receiving a Merkle proof from a computer node of a distributed digital ledger transaction network in response to a request to transmit transaction event details.

[0105] In another embodiment of the fifth method according to the invention, the monitoring of the transaction event counter and the request to transmit transaction event details may be part of a combined request to the computer node.

[0106] The present invention also relates to a fifth non-transitory computer-readable medium having instructions stored thereon, which, when executed by at least one processor, cause a computing device to: monitor a transaction event counter corresponding to a user account in a state data structure stored at a computer node in a distributed digital ledger transaction network; transmit a request for transaction event details of transaction event data from an event data structure stored at one or more computer nodes in the distributed digital ledger transaction network; and, in response to the request for transmission of transaction event details, receive, via one or more computer nodes, transaction event data corresponding to a count value determined from the transaction event counter.

[0107] In an embodiment of the fifth non-transitory computer-readable medium according to the invention, the non-transitory computer-readable medium may further include instructions that, when executed by at least one processor, enable a computing device to determine a count value of a transaction event counter, wherein a transaction event details request may include the count value of the transaction event counter and an access path to the transaction event counter corresponding to a user account within a state data structure.

[0108] In another embodiment of the fifth non-transitory computer-readable medium according to the invention, the non-transitory computer-readable medium may further include instructions that, when executed by at least one processor, enable a computing device to monitor a transaction event counter by polling a transaction event counter at a computer node, and the non-transitory computer-readable medium may further include instructions that, when executed by at least one processor, enable the computing device to: determine a count value of the transaction event counter at a first time; and determine an additional count value of the transaction event counter at a second time.

[0109] In yet another embodiment of the fifth non-transitory computer-readable medium according to the invention, the non-transitory computer-readable medium may further include instructions that, when executed by at least one processor, cause a computing device to verify that there is no event corresponding to a user account between the first time and the second time by determining that the count value of the transaction event counter at a first time and the additional count value of the transaction event counter at a second time are the same count value.

[0110] In another embodiment of the fifth non-transitory computer-readable medium according to the invention, the non-transitory computer-readable medium may further include instructions that, when executed by at least one processor, cause a computing device to determine a sequence of count values ​​indicating that a sequence of events corresponding to a user account has occurred via a distributed digital ledger transaction network, based on a comparison of the count value of a transaction event counter at a first time and an additional count value of the transaction event counter at a second time.

[0111] In an embodiment of the fifth non-transitory computer-readable medium according to the invention, the non-transitory computer-readable medium may further include instructions that, when executed by at least one processor, cause a computing device to: transmit a transaction event details request by transmitting a transaction event sequence request for an event sequence; and receive transaction event data by receiving a set of transaction event data corresponding to a plurality of events; and the non-transitory computer-readable medium may further include instructions that, when executed by at least one processor, cause a computing device to compare the set of transaction event data corresponding to a plurality of events with a sequence of count values ​​to determine: that the plurality of events is a complete set of event sequences; or that the plurality of event sets is an incomplete set of event sequences.

[0112] In another embodiment of the fifth non-transitory computer-readable medium according to the invention, the non-transitory computer-readable medium may further include instructions that, when executed by at least one processor, cause a computing device to monitor a transaction event counter and transmit a request for transaction event details as part of a combined request to a computer node.

[0113] The present invention also relates to a fifth system comprising: at least one processor; and at least one non-transitory computer-readable medium having instructions stored thereon, which, when executed by the at least one processor, cause the system to: monitor transaction event counters corresponding to user accounts in state data structures stored at computer nodes of a distributed digital ledger transaction network; transmit a request for transaction event details of transaction event data from event data structures stored at one or more computer nodes of the distributed digital ledger transaction network; and, in response to the request for transmission of transaction event details, receive transaction event data corresponding to count values ​​determined from the transaction event counters via one or more computer nodes.

[0114] In an embodiment of the fifth system according to the invention, the system may further include instructions that, when executed by at least one processor, cause the system to determine a count value of a transaction event counter, wherein the transaction event details request includes the count value of the transaction event counter and an access path to the transaction event counter corresponding to a user account within a state data structure.

[0115] In another embodiment of the first system according to the invention, the instructions, when executed by at least one processor, cause the system to monitor the transaction event counter by polling the transaction event counter at a computer node, and the system may further include instructions, when executed by at least one processor, causing the computing device to: determine a count value of the transaction event counter at a first time; and determine an additional count value of the transaction event counter at a second time.

[0116] In another embodiment of the first system according to the invention, the event data structure may include an event Merkle tree, and the state data structure may include a state Merkle tree; and the instructions, when executed by at least one processor, cause the system to receive transaction event data by receiving Merkle proofs from computer nodes of the distributed digital ledger transaction network in response to a request to transmit transaction event details.

[0117] The present invention also relates to a sixth method comprising: identifying a request for a transaction to transfer digital assets from a first user account on a state data structure to a second user account via a distributed digital ledger transaction network; determining, within the request for the transaction, the linear data type of the digital assets; and executing the transaction utilizing the linear data type by transferring the digital assets from the first user account on the state data structure to the second user account under the constraints of a linear classification rule corresponding to the linear data type.

[0118] In an embodiment of the sixth method according to the invention, the linear fractal rule may be part of a programming language used to control modifications to the state data structure of a distributed digital ledger transaction network.

[0119] In another embodiment of the sixth method according to the invention, the linear fractal rule may include a first linear fractal rule that utilizes a linear data type exactly once in a transaction.

[0120] In yet another embodiment of the sixth method according to the invention, the linear fractal rule includes a second linear fractal rule that opposes the copying of linear data types.

[0121] In an embodiment of the sixth method according to the invention, the method may further include: identifying an additional request for an additional transaction that transfers an additional digital asset represented by a linear data type via a distributed digital ledger transaction network; determining that the additional request for the additional transaction utilizes the additional digital asset represented by the linear data type more than once; and rejecting the additional request for the additional transaction based on the determination that the linear data type of the additional request for the additional transaction violates a first linear fractal rule from the linear fractal rules.

[0122] In another embodiment of the sixth method according to the invention, the method may further include: identifying an additional request for an additional transaction of transferring additional digital assets from a first user account via a distributed digital ledger transaction network, wherein the additional request for the additional transaction fails to identify the recipient user account; and rejecting the additional request for the additional transaction due to a violation of a first linear fractal rule from the linear fractal rules.

[0123] In another embodiment of the sixth method according to the invention, the linear data type of digital assets is divisible and merging according to programming languages ​​and linear fractal rules.

[0124] In another embodiment of the sixth method according to the present invention, the digital assets include digital currency maintained within the state data structure of the distributed digital ledger transaction network, wherein the digital currencies involved in this application all comply with the relevant laws and regulations of the People's Republic of China.

[0125] The present invention also relates to a sixth non-transitory computer-readable medium having instructions stored thereon that, when executed by at least one processor, cause a computing device to: identify a request for a transaction to transfer digital assets from a first user account to a second user account on a state data structure via a distributed digital ledger transaction network; determine, within the request for the transaction, the linear data type of the digital assets; and execute the transaction utilizing the linear data type by transferring the digital assets from the first user account to the second user account on the state data structure under the constraints of a linear classification rule corresponding to the linear data type.

[0126] In an embodiment of the sixth non-transitory computer-readable medium, the linear fractal rule may be part of a programming language used to control modifications to the state data structure of a distributed digital ledger transaction network.

[0127] In another embodiment of the sixth non-transitory computer-readable medium, the linear fractal rule may include a first linear fractal rule that utilizes a linear data type exactly once in a transaction.

[0128] In another embodiment of the sixth non-transitory computer-readable medium, the linear fractal rule includes a second linear fractal rule that opposes copying linear data types.

[0129] In another embodiment of the sixth non-transitory computer-readable medium, the non-transitory computer-readable medium may further include instructions that, when executed by at least one processor, cause a computing device to: identify an additional request for an additional transaction involving the transfer of an additional digital asset represented by a linear data type via a distributed digital ledger transaction network; determine that the additional request for the additional transaction utilizes the additional digital asset represented by the linear data type more than once; and reject the additional request for the additional transaction based on the determination that the linear data type of the additional request for the additional transaction violates a first linear fractal rule from the linear fractal rules.

[0130] In another embodiment of the sixth non-transitory computer-readable medium, the non-transitory computer-readable medium may further include instructions that, when executed by at least one processor, cause a computing device to: identify an additional request for an additional transaction involving the transfer of additional digital assets from a first user account via a distributed digital ledger transaction network, wherein the additional request for the additional transaction fails to identify the recipient user account; and reject the additional request for the additional transaction due to a violation of a first linear fractal rule from the linear fractal rules.

[0131] In another embodiment of the sixth non-transitory computer-readable medium, the linear data type of the digital asset is divisible and merging according to the programming language and linear fractal rules.

[0132] In another embodiment of the sixth non-transitory computer-readable medium, digital assets include digital currency held within a state data structure of a distributed digital ledger transaction network.

[0133] The present invention also relates to a sixth system comprising: at least one processor; and at least one non-transitory computer-readable medium having instructions stored thereon, which, when executed by the at least one processor, cause the system to: recognize a request for a transaction to transfer digital assets from a first user account on a state data structure to a second user account via a distributed digital ledger transaction network; determine, within the request for the transaction, the linear data type of the digital assets; and execute the transaction utilizing the linear data type by transferring the digital assets from the first user account on the state data structure to the second user account under the constraints of a linear classification rule corresponding to the linear data type.

[0134] In an embodiment of the sixth system according to the invention, the linear fractal rule may be part of a programming language for controlling modifications to the state data structure of a distributed digital ledger transaction network; and the linear data type of digital assets is divisible and merging according to the programming language and the linear fractal rule.

[0135] In another embodiment of the sixth system according to the invention, the linear fractal rule may include: a first linear fractal rule that utilizes the linear data type exactly once in a transaction; and a second linear fractal rule that opposes the replication of the linear data type.

[0136] In yet another embodiment of the sixth system according to the invention, digital assets may include digital currency held within a state data structure of a distributed digital ledger transaction network.

[0137] In summary, the disclosed system enables a distributed digital ledger transaction network with high transaction throughput, low latency, and efficient high-capacity storage. Furthermore, the system can securely manage a wide variety of digital assets, flexibly adapt to diverse customizable programs and smart contracts, and scale to execute and manage digital transactions for users worldwide. Brief description of the attached diagram

[0138] This disclosure will describe one or more embodiments of the invention with reference to the accompanying drawings, including additional features and details. The following paragraphs briefly describe these drawings, in which:

[0139] Figure 1 An example distributed digital ledger transaction network in which a ledger transaction system according to one or more embodiments may operate is shown;

[0140] Figure 2 A schematic diagram of components of a validator node device used in processing, executing, and submitting transactions, according to one or more embodiments, is shown.

[0141] Figure 3 The diagram illustrates a state data structure generated and maintained by a ledger transaction system according to one or more embodiments;

[0142] Figure 4 An event data structure generated and maintained by a ledger transaction system according to one or more embodiments is shown;

[0143] Figure 5 The transaction data structure generated and maintained by a ledger transaction system according to one or more embodiments is shown;

[0144] Figure 6 A representation of ledger information for obtaining consensus is shown according to one or more embodiments;

[0145] Figure 7 A ledger transaction system is illustrated, according to one or more embodiments, for deleting a portion of a transaction tree stored at a computer node;

[0146] Figure 8A ledger transaction system is illustrated, according to one or more embodiments, for deleting or merging portions of a state tree stored at a computer node;

[0147] Figure 9 A ledger transaction system is illustrated, according to one or more embodiments, in which a portion of the state tree is deleted when there are state tree components reflecting multiple different state trees;

[0148] Figure 10 A ledger transaction system for performing account eviction according to one or more embodiments is illustrated;

[0149] Figure 11 A block diagram is shown illustrating a ledger transaction system that re-caches account data corresponding to user accounts according to one or more embodiments;

[0150] Figure 12 A state tree from a state data structure, representing the current committed state of a distributed digital ledger transaction network, is shown according to one or more embodiments.

[0151] Figure 13 A block diagram is shown of a transaction block identified by a ledger transaction system according to one or more embodiments;

[0152] Figures 14A-14B A ledger transaction system for tracking execution results using a note-based data structure is illustrated according to one or more embodiments;

[0153] Figure 15 A schematic diagram is shown of the address of a user account corresponding to a distributed digital ledger transaction network according to one or more embodiments;

[0154] Figure 16 A block diagram of a ledger transaction system for identifying the primary public address identifier and sub-address identifier of a user account from digital visual codes, according to one or more embodiments, is shown.

[0155] Figure 17 A block diagram is shown of a ledger transaction system that identifies a primary public address identifier, a sub-address identifier, and an encryption key associated with a user account from digital visual codes, according to one or more embodiments.

[0156] Figure 18 A block diagram of a ledger transaction system that identifies a user account based on an email address, a sub-address identifier, and an encryption key, according to one or more embodiments, is shown.

[0157] Figure 19A schematic diagram of a user account for a storage module and resources according to one or more embodiments is shown;

[0158] Figure 20 A block diagram of a ledger transaction system for transferring licensed resources between user accounts, according to one or more embodiments, is shown;

[0159] Figure 21 A block diagram of a ledger transaction system that rotates authentication keys for user accounts according to one or more embodiments is shown;

[0160] Figure 22 A block diagram illustrating the submission of a transaction to a distributed digital ledger transaction network according to one or more embodiments is shown;

[0161] Figure 23 Modules and corresponding resources stored on a distributed digital ledger transaction network according to one or more embodiments are shown;

[0162] Figure 24 A block diagram of a ledger transaction system that utilizes smart contracts to perform a series of checks on a received transaction request, according to one or more embodiments, is shown.

[0163] Figure 25 A block diagram of a ledger transaction system that utilizes smart contracts to perform execution epilogue tasks, according to one or more embodiments, is shown.

[0164] Figure 26 A block diagram of a ledger transaction system that utilizes smart contracts to distribute gas payments according to one or more embodiments is shown;

[0165] Figure 27 A block diagram of a ledger transaction system that executes transactions in parallel according to one or more embodiments is shown;

[0166] Figure 28 A block diagram of a ledger transaction system that executes transactions based on determined dependencies according to one or more embodiments is shown;

[0167] Figure 29 A ledger transaction system is shown that implements access restrictions on digital assets stored in user accounts according to one or more embodiments;

[0168] Figures 30A-30B A block diagram of a ledger transaction system for generating transaction events according to one or more embodiments is shown;

[0169] Figure 31A series of actions for determining a new transaction event corresponding to a user account, according to one or more embodiments, are illustrated;

[0170] Figure 32 A block diagram illustrating an event detail for retrieving a sequence of events, according to one or more embodiments, is shown.

[0171] Figure 33 A block diagram of a ledger transaction system that utilizes validator node devices to achieve consensus, according to one or more embodiments, is shown.

[0172] Figure 34 A block diagram of a ledger transaction system that performs consensus on the execution results according to one or more embodiments is shown;

[0173] Figure 35 A block diagram of a ledger transaction system that utilizes pipelining to achieve consensus, according to one or more embodiments, is shown.

[0174] Figure 36 A block diagram illustrating the use of consensus state to provide consensus security in the event of a system restart, according to one or more embodiments;

[0175] Figure 37 An illustration is shown of a ledger transaction system that varies the set of validator node devices according to one or more embodiments;

[0176] Figure 38 A block diagram is shown of a ledger transaction system that utilizes incremental verification to download segments of data to computer nodes according to one or more embodiments;

[0177] Figure 39 A block diagram of a ledger transaction system that downloads and verifies data in parallel according to one or more embodiments is shown;

[0178] Figure 40 The timeline and associated path points of the digital ledger are shown according to one or more embodiments;

[0179] Figure 41 A block diagram of a ledger transaction system utilizing path points associated with FTVM transactions is shown according to one or more embodiments;

[0180] Figure 42 A block diagram is shown of a ledger transaction system implementing linear typing rules corresponding to linear data types, according to one or more embodiments.

[0181] Figure 43A block diagram is shown for performing static and dynamic analysis of a combination according to one or more embodiments to ensure reference safety;

[0182] Figure 44 A flowchart is shown for a series of actions to perform an account expulsion according to one or more embodiments;

[0183] Figure 45 A flowchart is shown, according to one or more embodiments, of a series of actions for generating a cryptographic sub-address unique to a transaction;

[0184] Figure 46 A flowchart is shown illustrating a series of actions for the parallel execution of a transaction according to one or more embodiments;

[0185] Figure 47 A flowchart illustrating a series of actions for generating a transaction event, according to one or more embodiments, is shown;

[0186] Figure 48 A flowchart illustrating a series of actions for receiving transaction event data according to one or more embodiments is shown;

[0187] Figure 49 A flowchart illustrating a series of actions for executing a transaction using a linear data type constrained by linear fractal rules, according to one or more embodiments; and

[0188] Figure 50 A block diagram of an exemplary computing device according to one or more embodiments is shown. Detailed description

[0189] One or more embodiments described herein include ledger transaction systems for implementing scalable, secure, efficient, and adaptable distributed digital ledger transaction networks. For example, a ledger transaction system can manage a programmable database to support low-volatility digital assets (e.g., cryptocurrencies) accessible worldwide. To illustrate, a ledger transaction system can be implemented as part of a decentralized network where a collection of validator node devices collectively maintains a database of programmable resources (e.g., digital assets). The ledger transaction system can utilize certified data structures that map the logical data model of these databases to a collection of tree structures (e.g., Merkle trees). The ledger transaction system can then utilize the validator node devices to execute transactions and communicate via consensus to agree on the state of the certified data structures. In particular, the ledger transaction system can utilize a unique Byzantine fault-tolerant consensus protocol, which allows the network (even in the presence of potentially malicious validators) to maintain a consistent database over time by executing transactions via a new programming language and agreeing on their execution using certified data structures.

[0190] As mentioned above, ledger transaction systems offer several improvements over traditional blockchain systems. For example, in one or more embodiments, ledger transaction systems utilize new programming languages ​​that enhance security, efficiency, and flexibility. In particular, ledger transaction systems can utilize a programming language that enables flexible transactions via arbitrary transaction scripts and allows user-defined code and data types (including "smart contracts") via modules.

[0191] Specifically, programming languages ​​provide the ability to define custom resource types that enforce linearity. For example, ledger transaction systems can utilize linear data types to represent digital assets associated with a distributed digital ledger transaction network. By representing digital assets as linear data types, ledger transaction systems subject these assets to linear classification rules. For instance, digital assets represented as linear data types must be used exactly once within a transaction and cannot be copied. By representing digital assets as linear data types, ledger transaction systems provide more flexible and secure management of digital assets.

[0192] In some embodiments, the ledger transaction system uses a verifiable bytecode language as the executable representation of that programming language. This allows the ledger transaction system to use combined static-dynamic reference security analysis on transaction scripts and modules submitted for execution on a distributed digital ledger transaction network. In effect, the ledger transaction system can use load-time bytecode verification (on a structured memory tree model) to statically perform most of the reference security analysis at the bytecode level, and dynamically execute the remainder of that analysis at runtime. This approach improves security and reduces the vectors for malicious attacks, such as attempts to exploit or bypass the compiler. Compared to higher-level source languages, this approach also results in fewer instructions, a smaller overall footprint, and makes it easier to detect and avoid implementation errors.

[0193] Beyond improvements to the programming language implementation, ledger transaction systems can also enhance various other processes across distributed digital ledger transaction networks. For example, ledger transaction systems can improve storage, addressing and account management, transaction execution, consensus, and synchronization processes. Regarding storage, for instance, ledger transaction systems can implement various features to improve the efficiency, flexibility, and security of data structures maintained across distributed digital ledger transaction networks.

[0194] To illustrate, as mentioned above, a ledger transaction system can maintain multiple certified data structures storing data in a digital ledger. Specifically, certified data structures can include tree data structures (e.g., sparse Merkle trees or Merkle accumulators) with nodes mapped to entries in a versioned database. For example, certified data structures can include state data structures (e.g., state trees mapped to a state database reflecting user account states), event data structures (e.g., event trees mapped to event data for specific transactions), and transaction data structures (e.g., transaction trees reflecting transactions along with the states and events generated by those transactions). By utilizing certified tree data structures, a ledger transaction system can efficiently encode current and historical states, events, and / or transactions reflected in a database storing programmable resources. For example, a ledger transaction system can utilize a transaction tree structure where the root value of the transaction state tree provides a unique representation of the current and historical states, events, and transactions recorded in the corresponding database. Furthermore, the ledger transaction system can refer to this root value to efficiently achieve consensus across a distributed digital ledger transaction network.

[0195] Furthermore, in some embodiments, the ledger transaction system implements a storage deletion rule set and / or a storage merge rule set to manage the storage of computer nodes on a distributed digital ledger transaction network. For example, the ledger transaction system can apply configurable storage deletion rules that allow different computer nodes to identify what (or what part) of a data structure to maintain. Additionally, the ledger transaction system can automatically remove parts of a data structure to reduce storage and processing requirements. For example, the ledger transaction system can delete a subtree of an authenticated tree structure when it identifies that the subtree includes full (e.g., populated) leaf nodes. Similarly, the ledger transaction system can store multiple different versions of a data structure by reusing unchanged parts from previous versions. In particular, the ledger transaction system can generate subtree components (reflecting only modified nodes) along with pointers to unchanged nodes within the historical tree structure. Therefore, the ledger transaction system can efficiently and flexibly manage storage on a distributed digital ledger transaction network.

[0196] In some embodiments, the ledger transaction system can also improve storage by performing lazy account evictions. Specifically, the ledger transaction system can delete account data associated with expired user accounts at the computer node based on user preferences and / or the computing resources available at that computer node. For example, the ledger transaction system can delete expired account data at the computer node without executing a transaction on the distributed digital ledger transaction network. Furthermore, by embedding the eviction date in the certified data structure, the ledger transaction system can maintain consistent query responses to data across the distributed digital ledger transaction network (even simultaneously providing each client device with the flexibility to delete expired data during its idle time). Additionally, in one or more embodiments, the ledger transaction system can securely re-cachise evicted accounts based on the data representation retained in the certified data structure. In this way, ledger transactions can securely and flexibly remove storage at the computer node for more efficient storage management.

[0197] Furthermore, one or more embodiments of the ledger transaction system improve the storage process by utilizing a note-based data structure to track execution results before committing them to storage. Specifically, the ledger transaction system can use a note-based data structure to temporarily store the execution results of conflicting transaction blocks and how these results affect the state of user accounts maintained on the distributed ledger. The ledger transaction system can then commit the execution results stored in the note-based data structure based on a consensus protocol. Therefore, the ledger transaction system can flexibly execute conflicting transaction blocks to ensure that computer nodes accurately reflect the consensus digital ledger.

[0198] In addition to improvements in storage, as mentioned above, ledger transaction systems can also improve the management of addresses and / or accounts within a distributed digital ledger transaction network. For example, in some embodiments, the ledger transaction system generates encrypted sub-addresses unique to specific transactions to securely protect them from being identified by external entities. For instance, the ledger transaction system can use a public encryption key associated with a user account to encrypt the sub-address associated with that user account. In one or more embodiments, the ledger transaction system utilizes public documents (e.g., billboards), digital visual codes, email addresses (and / or DNS records), telephone numbers, or user IDs to identify account addressing information and / or public encryption keys. In this way, the ledger transaction system can flexibly initiate and execute transactions without leaving traceable information on the digital ledger linked to sub-addresses.

[0199] Furthermore, in one or more embodiments, the ledger transaction system can separate smart contract code from smart contract data within a user account (as opposed to conventional systems that use singleton-like objects to execute smart contracts). The ledger transaction system can utilize modules (smart contract code) to define attributes of resources (smart contract data / values) owned by a corresponding user account, where each module defines procedures that can be used to modify, create, delete, or otherwise interact with the resource. The ledger transaction system can utilize this module to generate one or more resources sharing the same attributes and governed by the same set of procedures. Additionally (as opposed to conventional systems that typically store a single smart contract about an account), the ledger transaction system can implement an addressing scheme for storing multiple modules and / or resources under a single user account address.

[0200] Ledger transaction systems can further improve account management by storing and transferring various digital assets. For example, in one or more embodiments, a ledger transaction system can generate resources corresponding to a user account's withdrawal permission. The ledger transaction system can then delegate the withdrawal permission to another user account by executing a transaction that transfers the withdrawal permission (i.e., as a digital asset) from the user account. Therefore, the ledger transaction system can flexibly provide access to a user account's digital assets to another account based on the needs of the user associated with that user account.

[0201] Furthermore, ledger transaction systems can improve account management across distributed digital ledger transaction networks by decoupling the authentication key associated with a user account from the user account's address. For example, a ledger transaction system can replace a user account's authentication key without moving the user account's content to a new address. To illustrate, if one of the encryption keys associated with a user account (e.g., a private encryption key) is compromised, the ledger transaction system can generate a new authentication key for that user account. Therefore, the ledger transaction system can modify the authentication key to provide a flexible security solution for user accounts.

[0202] As mentioned above, in addition to improvements in storage and account / addressing, ledger transaction systems can also improve transaction execution within a distributed digital ledger transaction network. For example, in some embodiments, the ledger transaction system utilizes arbitrary transaction scripts for executing transactions on a distributed digital ledger transaction network. In practice, the ledger transaction system can utilize transaction scripts containing arbitrary bytecode programs that can call multiple procedures from various modules, use conditional logic, and perform local computations within a single script. Transaction scripts can call module procedures to modify, create, destroy one or more resources corresponding to that module, or otherwise interact with one or more resources corresponding to that module. In other words, the ledger transaction system can utilize transaction scripts to interact with resources based on procedures defined in the corresponding module. In practice, in one or more embodiments, the ledger transaction system restricts interaction with resources to the procedures of the corresponding module to provide data abstraction. Therefore, the ledger transaction system can utilize transaction scripts to execute transactions more flexibly on a distributed digital ledger transaction network.

[0203] Ledger transaction systems can further improve transactions by utilizing modules (i.e., smart contracts) as part of the transaction execution process. For example, a ledger transaction system can use smart contracts to check transaction execution and reject transactions if necessary. Furthermore, a ledger transaction system can use smart contracts to implement post-execution tasks, such as incrementing a sequence number stored in a user's account and deducting transaction fees from the user's account. Additionally, a ledger transaction system can use smart contracts to distribute gas payments to computer nodes participating in the distributed digital ledger transaction network. In one or more embodiments, these modules are configurable, allowing them to be replaced or updated as needed. Therefore, a ledger transaction system utilizes smart contracts to execute transactions and flexibly modifies the rules governing transactions over time through consensus.

[0204] In one or more embodiments, the ledger transaction system also improves transaction execution by performing speculative parallel execution of multiple transactions. For example, the ledger transaction system can identify a first-state data structure of the distributed digital ledger transaction network (i.e., the first state of the digital ledger) and multiple transactions associated with user accounts on the distributed digital ledger transaction network. The ledger transaction system can then perform pre-execution of transactions in parallel relative to the first-state data structure to determine the results of multiple transactions and dependencies between transactions concerning user accounts. The ledger transaction system can then modify the first-state data structure into a second-state data structure by applying the results of multiple transactions based on the dependencies. By executing transactions in parallel and submitting them to storage based on the determined dependencies, the ledger transaction system executes transactions more flexibly and efficiently than conventional systems.

[0205] Ledger transaction systems can also enhance the security and flexibility of transaction execution by utilizing access restrictions to control access to digital assets associated with user accounts. For example, in one or more embodiments, the ledger transaction system can implement access restrictions that must be met before granting access to digital assets. In some embodiments, the ledger transaction system may require a threshold number of access keys from a set of keys before granting access to a user account. Furthermore, in some embodiments, the ledger transaction system 106 utilizes rate / value-limited access keys and corresponding key restrictions to limit access to digital assets of a user account granted during transaction execution. For example, the ledger transaction system may restrict the validity period of an access key and / or the number of digital assets (e.g., the value of a cryptocurrency) that the access key can access. Using these access restrictions, the ledger transaction system provides greater security regarding digital assets. In particular, the ledger transaction system can utilize access restrictions to prevent unrestricted access to digital accounts from malicious actors in the event of a compromised or stolen access key.

[0206] Ledger transaction systems can further improve transactions across a distributed digital ledger transaction network by utilizing transaction event counters to track and report transaction event details. For example, when executing a transaction associated with a user account, the ledger transaction system can generate one or more transaction events corresponding to that user account (within an event data structure). The ledger transaction system can then increment the count values ​​of the transaction event counters corresponding to those transaction events (within a state data structure). Client devices implementing the ledger transaction system can monitor (e.g., poll) the transaction event counters to determine when an event occurs, and then use the count values ​​to request and verify transaction details (from the transaction data structure). Therefore, the ledger transaction system can more accurately indicate when transaction events occur and provide event data more efficiently. The ledger transaction system can also poll the transaction event counters to perform counter-proofs that confirm account data has not changed.

[0207] As mentioned above, in addition to improving transaction execution, ledger transaction systems can also improve the consensus process across distributed digital ledger transaction networks. For example, in one or more embodiments, a ledger transaction system utilizes validator node devices of the distributed digital ledger transaction network to perform consensus based on the execution results corresponding to transaction blocks, rather than just on the transactions themselves. In other words, a ledger transaction system can enable validators to jointly sign the complete result state of a block rather than a series of transactions. In this way, the ledger transaction system anticipates nondeterministic execution behavior and ensures that validator nodes submit an accurate representation of the digital ledger to storage when consensus is reached on a transaction block.

[0208] Furthermore, ledger transaction systems can improve the consensus process by utilizing methods that pipeline the consensus protocol. In practice, in one or more embodiments, validator nodes of the distributed digital ledger transaction network vote on these execution results in several rounds before the ledger transaction system submits the execution results of transaction blocks to storage. For example, the ledger transaction system can apply a contiguous 3-chain commit rule by submitting the first state of the digital ledger to storage after consensus has been reached across the distributed digital ledger transaction network in three consecutive rounds (the first state of the digital ledger and two subsequent states of the digital ledger). In this way, the ledger transaction system can ensure the accuracy of the submitted data structure.

[0209] Furthermore, the ledger transaction system can improve consensus security for validator nodes during system restarts. For example, before a validator node submits its vote on a transaction block, the ledger transaction system can store the consensus state (including the last voting round and the preferred block round) at each validator node. Upon system restart, the ledger transaction system can load the consensus state at the validator nodes to continue participating in consensus without issues. In this way, even if all validator nodes are shut down, the ledger transaction system can ensure consensus security during validator node restarts.

[0210] As mentioned above, consensus can include voting on a specific ledger state among multiple validator nodes. In one or more embodiments, the ledger transaction system improves this consensus process by managing the voting rights of validator node devices via smart contracts. For example, the ledger transaction system can implement a proof-of-stake protocol to allow user accounts on the distributed digital ledger transaction network to manage their participation in the set of validator node devices. The ledger transaction system can further manage changes to the set of validator node devices via smart contracts. In one or more embodiments, the ledger transaction system utilizes modules to manage the proof-of-stake protocol and / or changes to the set of validator node devices. In practice, the ledger transaction system can utilize modules to implement changes to the set of validator node devices at time boundaries.

[0211] Beyond consensus, ledger transaction systems can also provide technical benefits regarding the synchronization process of a distributed digital ledger transaction network. For example, in some embodiments, the ledger transaction system uses incremental verification at the computer nodes when synchronizing to the distributed digital ledger transaction network. In practice, synchronizing computer nodes can download data associated with the digital ledger along with data proofs (e.g., Merkle proofs) in segments. The ledger transaction system can then verify the accuracy of the received data at the client devices before downloading more data. Therefore, the ledger transaction system can more efficiently synchronize computer nodes to the distributed digital ledger transaction network.

[0212] Furthermore, ledger transaction systems can utilize parallel synchronization methods to improve synchronization efficiency. In practice, a ledger transaction system can download different data segments associated with the digital ledger and their corresponding proofs (e.g., different snapshots of the digital ledger's state) to separate verification devices. The ledger transaction system can then use each verification device to verify the data segments downloaded to that device in parallel with other verification devices. Therefore, a ledger transaction system can more efficiently synchronize computer nodes to a distributed digital ledger transaction network.

[0213] In one or more embodiments, the ledger transaction system also utilizes pathpoints to facilitate synchronization across the distributed digital ledger transaction network. Specifically, the ledger transaction system can generate and use pathpoints to indicate the correct / preferred version of the digital ledger used across the distributed digital ledger transaction network. By utilizing pathpoints, the ledger transaction system can also facilitate the acceptance of certain transactions that might otherwise be rejected (i.e., FTVM transactions). For example, the ledger transaction system can utilize pathpoints to facilitate the acceptance of FTVM transactions that establish a genesis block or create a hard fork on the distributed digital ledger transaction network.

[0214] As illustrated in the foregoing discussion, this disclosure utilizes various terms to describe the characteristics and benefits of a ledger transaction system. Additional details regarding the meaning of these terms are now provided. For example, as used herein, the term "digital ledger" (or "distributed digital ledger" or "public ledger") refers to public data maintained across multiple computing devices. Specifically, a digital ledger may include one or more public data structures maintained by multiple computing devices that reflect state, transaction, event, and / or account data. For illustration, a digital ledger may include one or more data structures reflecting the state of the network (i.e., the state of user accounts on the network), data associated with transactions executed across the network, data corresponding to transaction events, and / or data associated with consensus on the digital ledger. A digital ledger may include, but is not limited to, the following attributes: publicly available (i.e., viewable by anyone), tamper-proof (i.e., data manipulation is detectable), transparent (i.e., anyone can view the history of the data, including executed transactions), and replicated (i.e., each computer node has a copy).

[0215] Additionally, as used herein, the term "distributed digital ledger transaction network" refers to a network of computing devices used to maintain a digital ledger. Specifically, a distributed digital ledger transaction system may include a collection of computing devices, associated peripheral devices, communication protocols, and communication media capable of implementing a digital ledger and / or interacting with a system implementing a digital ledger (e.g., a ledger transaction system). For example, a distributed digital ledger transaction network may include one or more client devices and computer nodes communicating via the network to implement and / or interact with the ledger transaction system. Because a distributed digital ledger transaction network can implement a digital ledger, in one or more embodiments, the terms "state of the distributed digital ledger transaction network" and "state of the digital ledger" are used synonymously.

[0216] Furthermore, as used herein, the term "computer node" refers to a computing device that participates in a distributed digital ledger transaction network. Specifically, a computer node can refer to a computing device that stores and maintains at least a portion of the digital ledger. For example, a computer node can include a full node device (e.g., "full node") or a validator node device (e.g., "validator node").

[0217] Additionally, as used herein, the term "user account" refers to an account on a distributed digital ledger transaction network. Specifically, a user account can refer to a collection of code and / or data (i.e., modules and / or resources) stored within the state data structure of the distributed digital ledger transaction network. User accounts can be associated with, but are not limited to, users on the distributed digital ledger transaction network. For example, user accounts can also include administrative accounts or accounts otherwise used to store code or data not associated with a particular user. Similarly, user accounts can include custodial wallets that act on behalf of their users.

[0218] As used herein, the term "public key" (or "public cryptographic key," "public encryption key," or "asymmetric key") refers to a publicly visible cryptographic key. Specifically, a public key can refer to a cryptographic key associated with a user account that is intended to be sent to and / or used by an entity not associated with the user account. For example, a public key can be sent from a user account to a validator node device in a distributed digital ledger transaction network along with a transaction. A public key may have a corresponding private key.

[0219] As used herein, the term "private key" (or "private cryptographic key" or "private encryption key") refers to an encryption key that is kept privately. Specifically, a private key can refer to an encryption key associated with a user account (and corresponding to the user account's public key), which is kept secret. Example use of a private key includes using the private key corresponding to the user account to sign (e.g., encrypt) transactions sent from the user account.

[0220] Additionally, as used herein, the term "authentication key" refers to a value used to authenticate a user account. Specifically, an authentication key can refer to a value stored in a user account that is used to authenticate the user account when the user account sends data (e.g., a transaction request) across a distributed digital ledger transaction network (e.g., to a validator node device). For example, an authentication key may include the account address of the corresponding user account or a hash of the account address or a hash of the corresponding user account's public key. As described below, in some embodiments, the ledger transaction system creates a modified authentication key that is decoupled from the account address.

[0221] Furthermore, as used herein, the term "primary public address identifier" (or "primary address identifier" or "public address identifier") refers to an identifier of the primary address of a user account on a distributed digital ledger transaction network. Specifically, the primary public address identifier may include the primary public address itself or a value associated with the user account indicating the primary address of the user account. As used herein, the terms "primary public address," "primary address," "public address," or "address" refer to the account address of a user account on a distributed digital ledger transaction network. Specifically, the primary public address may refer to an account address directly associated with and tracked by the digital ledger.

[0222] Accordingly, as used herein, the term "sub-address identifier" refers to an identifier for a sub-address associated with a user account on a distributed digital ledger transaction network. Specifically, a sub-address identifier can refer to the sub-address itself or to a value indicating a sub-account associated with a user account on the distributed digital ledger transaction network. In practice, in one or more embodiments, a user account on the distributed digital ledger transaction network maintains an internal database of one or more sub-accounts. A user account can use a corresponding sub-address to identify a specific sub-account.

[0223] Furthermore, as used herein, the term "consensus" refers to the confirmation of a digital ledger (e.g., the confirmation of a ledger reflecting state and / or transactions). Specifically, consensus can refer to the acceptance of a digital ledger (e.g., reflecting the state of transactions or transaction blocks) via a consensus protocol. In some embodiments, consensus refers to the acceptance of the execution result corresponding to a transaction or transaction block. A variety of different consensus protocols (including various members of the Byzantine Fault-Tolerant consensus protocol family) can be used to determine consensus. For illustration, the HotStuff consensus protocol, proof-of-work consensus protocols, proof-of-stake consensus protocols, and / or delegated proof-of-stake consensus protocols can be used to determine consensus. For example, consensus can be determined based on the number of votes provided by a set of validator nodes confirming that a transaction block (or the execution result corresponding to that transaction block) is valid.

[0224] As used herein, the term "period" refers to the period during which a set of validator node devices participates in consensus. In particular, a period can refer to the minimum delay between changes in the set of validator node devices. For example, a period can be measured by time or the number of transaction blocks that undergo consensus (e.g., the number of voting rounds).

[0225] Furthermore, as used herein, the term "request" refers to a transmission to a computer node in a distributed digital ledger transaction network. Specifically, a request can refer to a transmission to a computer node requesting an action. For example, a request can include a transaction request or a query for information retrieval. Although the following disclosure will generally discuss requests such as those submitted by a client device, requests are not limited thereto. In some embodiments, a request can be sent by a management device of the distributed digital ledger transaction network or another computer node (e.g., in the sharing of request processing among computer nodes).

[0226] Specifically, as used herein, the term "transaction request" (or "transaction event request" or "request for a transaction") refers to a request corresponding to a transaction (e.g., a request to execute a transaction or submit a transaction to the digital ledger). In particular, a transaction request can refer to a transmission received by a computer node requesting the execution of a transaction via a distributed digital ledger transaction network. A transaction request may include the transaction to be executed (e.g., as detailed within the transaction script). In some embodiments, a transaction request includes additional details, such as a sequence number corresponding to the requested transaction, the account address of the sending user account, the public key of the sending user account, etc. While the following disclosure will generally discuss transaction requests such as those submitted by a client device, transaction requests are not limited in this way. Transaction requests may be sent by the administrator device of the distributed digital ledger transaction network or by another computer node (e.g., in the processing of shared transaction requests among computer nodes).

[0227] Specifically, as used herein, the term "account reinstatement request" refers to a transaction request to reactivate a user account. More specifically, an account reinstatement request can refer to a request to re-cachate account data associated with an expired user account within an account state data structure. An account reinstatement request may include proposed account data for the requested re-caching.

[0228] Furthermore, as used herein, the term "transaction" refers to a program or action performed on a distributed digital ledger transaction network. In particular, a transaction may include the execution of at least one operation (e.g., via a computer node) that modifies the state data structure of the distributed digital ledger transaction network. For example, a transaction may include the transfer of one or more digital assets between user accounts or account recovery.

[0229] As used herein, the term “execution” or “transaction execution” refers to one or more actions related to the implementation of a transaction. Specifically, the term execution can refer to running a transaction script that takes its arguments and the current ledger state as input to produce a transaction output. During transaction execution, the ledger transaction system may perform a series of actions, including but not limited to performing initial checks upon receiving a transaction, analyzing the transaction (e.g., verifying the transaction script and modules), publishing modules (e.g., publishing the model corresponding to the transaction within the affected user account), running the transaction script, and running cleanup procedures (e.g., charging used gas and incrementing the user's serial number).

[0230] As used herein, the term "dependency" or "transaction dependency" refers to a relationship between two or more transactions. Specifically, dependency can refer to two or more transactions within the same transaction block that are associated with one or more identical user accounts. More specifically, two or more transactions can be dependent when the execution of one transaction depends on the execution of another. For example, two transactions can be dependent, where one transaction writes to a user account and the other reads from the user account. Dependency can refer to various different relationships corresponding to different granularities of account data. For example, dependency can refer to the utilization of any public resource stored in a user account and identified by two or more transactions.

[0231] Additionally, as used herein, the term "transaction event" or "event" refers to the result of a transaction. Specifically, a transaction event can refer to a side effect (e.g., update or modification) resulting from the execution of a transaction. Examples of transaction events include, but are not limited to, withdrawing digital assets from a user account or depositing digital assets into a user account. As used herein, the term "transaction event details request" refers to a query for information that requests event data corresponding to a transaction event. A transaction event details request can include a request for event data corresponding to a single transaction event or event data. Furthermore, a transaction event details request can include a request for a sequence of transaction events corresponding to event data of a sequence of events.

[0232] Furthermore, as used herein, the terms "event type" or "event category" refer to a category of transaction events. Specifically, an event type can refer to a classification applicable to a group of transaction events having one or more common characteristics. For example, an event type can refer to a transaction event corresponding to a payment received by a user account or a transaction event corresponding to a payment sent by a user account.

[0233] As used herein, the term "event data" or "transaction event data" refers to digital data associated with a transaction event. For example, event data may include details of the transaction event (referred to as "transaction event details"), access paths to transaction event counters corresponding to the transaction event, and sequence numbers corresponding to the count values ​​of the transaction event counters associated with the transaction event.

[0234] As used herein, the term "transaction event counter" refers to a counter (e.g., stored at the user account) that tracks events associated with a user account. For example, a transaction event counter may include a resource stored at the user account that is generated to track events associated with the user account. A transaction event counter may store count values ​​indicating the number (or quantity) of events associated with the user account that have been generated. As used herein, the term "event count request" refers to a query for information about the count values ​​of a transaction event counter.

[0235] Furthermore, as used herein, the term "account state" or "user account state" refers to the status of a user account on a distributed digital ledger transaction network at a specific period, iteration, version, or time. Specifically, account state can refer to a value (e.g., a key-value pair) associated with a user account at a specific time, iteration, or version of the digital ledger. Account state can include any value related to or associated with a user account. For example, account state can include resources (e.g., digital assets) and modules associated with a user account. Account state can also include other values, such as the eviction date associated with a user account.

[0236] Additionally, as used herein, the term "data structure" or "certified data structure" refers to a collection of data. Specifically, a certified data structure can refer to a collection of data that allows a verifier to measure the accuracy of the data. For example, a certified data structure may include one or more tree structures that map to entries in one or more corresponding databases. The verifier can analyze short verifiers of the tree structures to verify the accuracy of the tree structures and / or the corresponding databases. As mentioned above (and described in more detail below), data structures may include, but are not limited to, state data structures, event data structures, transaction data structures, and signature data structures.

[0237] In particular, certified data structures allow validators V Hold short authenticator a The short authenticator a Form a binding commit to data structure D. Hold D Untrusted prover P Calculate and return simultaneously r (for a certain function) F(the result of the calculation) and (Proof of the correct calculation of the verifier's results) F(D) r ). V It can run It is if and only if Returns true if true. As mentioned, certified data structures can include tree structures for storing mappings between integers and string values.

[0238] Furthermore, as used herein, the terms "data tree," "tree structure," or "tree data structure" refer to data represented as a set of linked nodes (with a root node and one or more subtrees containing parent and child nodes), which map to one or more entries in a database (e.g., mapping integers in nodes to string values ​​in the database). Data trees can include, but are not limited to, binary trees. For example, a data tree can include a Merkle tree, such as a sparse Merkle tree or a Merkle accumulator. A tree can refer to a state tree, event tree, or transaction tree.

[0239] For example, in a size of In a Merkle tree, D Each integer key Mapping to string value The authenticator is formed by the root of a full binary tree created from the string, and the leaves are marked as... And mark the internal nodes as ,in H It is a cryptographic hash function (or "hash"). The function the prover wants to authenticate. F Lookups involving key-value pairs, such as ,in . P By returning the node i The proof consists of the tags of each ancestor's brothers. To verify D China vs. Item i The search.

[0240] As used herein, the term "database" or "database structure" refers to a collection of data (e.g., string values). For example, a database may include a versioned database containing account values, event details, transaction details, signatures, or other information. Thus, a database may include, but is not limited to, a state database, an event database, a transaction database, or a signature database. In some embodiments, a ledger transaction system may combine a state database, an event database, a transaction database, and / or a signature database into a single database (e.g., a single digital file).

[0241] Accordingly, as used herein, the term "intermediate state data structure" refers to an uncommitted state data structure. Specifically, an intermediate state data structure can refer to a state data structure that has not yet been written to storage (i.e., permanent storage). For example, an intermediate state data structure may include a state data structure stored in temporary storage as a result of pre-executing transactions in a transaction block before consensus is reached.

[0242] As used herein, the term "data representation" or "account status representation" refers to the node value (e.g., an integer) in a data structure that represents the corresponding entry (e.g., a string) in a database. For example, an account status representation may refer to numeric data stored within a node (e.g., a leaf node) of a state tree that reflects the account data corresponding to that node within the state database. For example, a data representation may include hashes (e.g., account values) of entries stored within entries in a database (e.g., a state database). A data representation may also include the authentication key and / or eviction date of the corresponding user account.

[0243] As used herein, the term "account data" refers to digital data stored in a state database. Specifically, account data can refer to digital data stored within one or more entries in the database, which are associated with a particular user account. Account data can include, but is not limited to, account values ​​(e.g., digital assets owned by a user account) and hashes of those account values ​​that provide a mapping between database entries and a representation of the user account's state.

[0244] Additionally, as used herein, the term "lazy deletion" refers to asynchronous deletion among computer nodes in a distributed digital ledger transaction network. Specifically, lazy deletion may include marking elements as deleted / expired (without deleting the underlying data, until a later time selected during the idle time of the computing device). For example, the deletion may occur based on user preferences set at the computer node or based on the availability of computing resources on the computing node. The deletion may occur independently of when other computer nodes in the distributed digital ledger transaction network delete the corresponding database entries stored at those computer nodes.

[0245] As used herein, the term "notebook data structure" refers to a (temporary) collection of data that stores execution results until the ledger transaction system has determined whether the consensus on those execution results has failed or succeeded. A notebook data structure can store the execution results of multiple transaction blocks, some of which may have conflicts, representing alternative possible additions to the digital ledger.

[0246] Additionally, as used herein, the term "eviction date" refers to the expiration date of a user account. Specifically, the eviction date can refer to the time when a user account is no longer considered active. For illustration, the eviction date may include a timestamp associated with the user account. If the time in the distributed digital ledger transaction network is greater than the time included in the timestamp, then the user account has expired.

[0247] Furthermore, as used herein, the term "rent deposit amount" refers to a payment made for storage on a distributed ledger trading network. Specifically, rent deposit amount can refer to the currency paid for using storage devices on a distributed ledger trading network to store digital data corresponding to user accounts on the network. Rent deposit amount can also refer to the value paid in digital currency (i.e., gas or other digital currencies exchanged on the distributed ledger trading network).

[0248] As used herein, the term "module" refers to smart contract code. Specifically, a module can refer to a code value. More specifically, a module can refer to an object on a distributed digital ledger transaction network that contains code defining and declaring the types and procedures used in implementing the module. For example, a module can define a class of objects that implement that module. For illustration, a module can include bytecode declaring resource types and procedures. In some embodiments, a module is defined by the address of the account that declares the module.

[0249] As used herein, the term "resource" refers to smart contract data. Specifically, a resource can refer to a data value. In practice, a resource can refer to an object that provides a specific instance or implementation of a module, which is constrained by the data type defined within the module and manipulated using procedures defined within the module. For example, a resource may include language features that enable the implementation of digital assets (e.g., digital currencies from a class of digital assets defined within the module), data structures, and logic. In one or more embodiments, a resource includes a record that binds a name field to a simple value (i.e., an integer) or a complex value (i.e., another resource embedded within a particular resource).

[0250] As used herein, the term "digital asset" refers to digital data associated with (e.g., owned by or belonging to) a user account. Specifically, a digital asset can refer to a resource owned by a user account and generated from a module that defines a class of digital assets. For example, a digital asset may include a title representing ownership of a physical asset or another digital asset, or one or more units of a digital currency or a portion of a unit of a digital currency. In one or more embodiments, the ledger transaction system represents digital assets as linear data types under the constraints of associated linear classification rules.

[0251] Additionally, as used herein, the term "linear data type" refers to a programmed value. Specifically, a linear data type can refer to a programmed value used to enforce linearity for resources on a distributed digital ledger transaction network. For example, a linear data type can represent a unit of digital currency or other digital assets on a distributed digital ledger transaction network. Relatedly, as used herein, the term "linear fractal rule" refers to one or more rules associated with a linear data type that enforce linearity. For example, a linear fractal rule may include a linear fractal rule that requires a digital asset of a linear data type to be used exactly once during the transaction in which the digital asset is mentioned. Furthermore, a linear fractal rule may include a linear fractal rule that prohibits the copying (i.e., duplication) of a digital asset.

[0252] As used herein, the term "parallel" (when referring to a process executed by one or more computing devices) means that the processes are executed with some overlap in time (e.g., simultaneously or nearly simultaneously). In particular, the term "parallel" can refer to multiple processes being executed in such a manner that at least two processes overlap in some way so that at least a portion of those at least two processes occur simultaneously. For example, at least two processes can completely overlap so that they start and finish simultaneously. Parallelism can include, but is not limited to, executing transactions, downloading data, or verifying data.

[0253] Furthermore, as used herein, the term "access path" refers to an identifier of the location of digital data within a data structure. Specifically, an access path can refer to the location of a module or resource within a user account on a distributed digital ledger transaction network. For example, an access path may include an address associated with a user account (e.g., a home address) and an identifier corresponding to the resource or module.

[0254] Additionally, as used herein, the term "random number" (or "cryptographic random number") refers to a set of characters. Specifically, a random number can refer to a non-deterministic (e.g., random or pseudo-random) number. For example, a random number can include a single character (e.g., a single numeric value) or a string.

[0255] As used herein, the term "digital visual code" refers to an image that encodes digital data. Specifically, a digital visual code can refer to an image (e.g., a pattern) that can be decoded to obtain digital data associated with a user account on a distributed digital ledger transaction network. For example, a digital visual code may include a Quick Response ("QR") code, but may also include any other image from which digital data can be determined.

[0256] Furthermore, as used herein, the term "DNS record" refers to an entry in the Domain Name System ("DNS"). Specifically, a DNS record can refer to an entry in a DNS database that maps an email address to account identification information (such as a primary public address identifier and / or a public encryption key) of a user account on a distributed digital ledger transaction network. For example, a DNS record can include a DNS text record ("TXT record"). Relatedly, as used herein, the term DNSSEC (or "Domain Name System Security Extensions") refers to a set of security extensions to DNS that can help authenticate or otherwise verify data stored on DNS.

[0257] Furthermore, as used herein, the term "gas" refers to a digital asset used for fee payments. Specifically, gas can refer to digital currency associated with a user account, used to pay for actions taken on a distributed digital ledger transaction network. For example, gas can include digital currency used to pay transaction fees, account activation fees, account recovery fees, or rented storage. Gas can include various digital assets or can be drawn from other digital assets associated with a user account.

[0258] I. System Overview

[0259] A. Computing Environment

[0260] Additional details regarding the ledger transaction system will now be provided with reference to the accompanying diagram. For example, Figure 1 A schematic diagram of a distributed digital ledger transaction network 100 in which a ledger transaction system 106 can be implemented is shown. (See diagram below.) Figure 1 As shown, the distributed digital ledger transaction network 100 includes a communication network 102, computer nodes 114 (which include validator node devices 108a-108b and full node devices 108c-108d) and client devices 112a-112n (with corresponding users 116a-116n).

[0261] although Figure 1 The distributed digital ledger transaction network 100 is described as having a specific number of components, but the distributed digital ledger transaction network 100 can have any number of additional or alternative components (e.g., any number of computer nodes, client devices, or other components communicating with the ledger transaction system 106 via the communication network 102). Similarly, although Figure 1 A specific arrangement of the communication network 102, computer nodes 114, client devices 112a-112n, and users 116a-116n is shown, but various additional arrangements are possible.

[0262] Communication network 102, computer node 114, and client devices 112a-112n can be directly or indirectly (e.g., through the following...) Figure 50 The communication network 102, discussed in more detail, is coupled to each other in a communicative manner. Furthermore, computer nodes 114 and client devices 112a-112n may include computing devices (including those described below). Figure 50 (One or more computing devices discussed in more detail).

[0263] As mentioned above, the distributed digital ledger transaction network 100 includes computer nodes 114. Typically, computer nodes 114 can generate, store, receive, and / or transmit data (including data corresponding to the digital ledger). For example, computer nodes 114 can receive transaction requests and transmit transaction execution results. In one or more embodiments, at least one computer node 114 includes a data server. In some embodiments, at least one computer node 114 includes a communication server or a web hosting server. In other embodiments, one or more computer nodes 114 include a user-operated personal computing device.

[0264] In one or more embodiments, such as Figure 1 As shown, computer nodes can transmit data to each other. For example, a given computer node can transmit data to a specific computer node (i.e., a computer node) using peer-to-peer communication. A given computer node can also transmit data to all other computer nodes using broadcasting techniques. For example, in one or more embodiments, a computer node broadcasts data by transmitting data to a random or semi-random subset of computer nodes with voting rights (e.g., validator node devices). The receiving validator node devices can then reshare (i.e., retransmit) the data to other computer nodes in the same manner until the data known to each computer node (i.e., stored at each computer node) is stable.

[0265] In one or more embodiments, a computer node transmits data to other computer nodes in several steps. For example, in a first step, the transmitting computer node may make the data available (i.e., passively publish the data). The transmitting computer node may then send a notification to each potential receiving computer node indicating that the data is now available. Subsequently, the transmitting computer node may allow the potential receiving computer nodes to connect to the transmitting computer node and retrieve the available data.

[0266] like Figure 1As shown, the computer nodes include validator node devices 108a-108b and full node devices 108c-108d. As will be discussed in more detail below, validator node devices 108a-108b and full node devices 108c-108d may perform different functions; although in some embodiments, validator node devices 108a-108b and full node devices 108c-108d perform at least some overlapping functions. For example, in one or more embodiments, validator node devices 108a-108b and full node devices 108c-108d can both serve queries for information about transactions, events, or statuses of user accounts.

[0267] In addition, such as Figure 1 As shown, computer node 114 includes ledger transaction system 106. Specifically, in one or more embodiments, ledger transaction system 106 utilizes computer node 114 to execute transactions and provide services for queries of information. For example, ledger transaction system 106 may use validator node devices 108a-108b to execute transactions and implement consensus protocols. Furthermore, ledger transaction system 106 may utilize full node devices 108c-108d to receive queries of information and provide services for these queries.

[0268] For example, in one or more embodiments, the ledger transaction system 106 implements a Byzantine fault-tolerant consensus method. Specifically, in some embodiments, validator node devices 108a-108b implement a modified HotStuff consensus protocol. In particular, in one or more embodiments, computer node 114 selects a lead validator node device to drive consensus on transaction blocks. In one or more embodiments, the lead validator node device is selected deterministically (e.g., via round-robin selection from a predefined list). In some embodiments, the lead validator node device is selected non-deterministically (e.g., candidate validator node devices attempt to solve a cryptographic puzzle or participate in a cryptographic lottery, and the winner becomes the lead validator node device). When selected, the lead validator node device may assemble a transaction block containing transactions received from one or more client devices 112a-112n and propose the transaction block to other validator node devices. The other validator node devices execute the transactions within the transaction block and then vote on the execution results.

[0269] For example, suppose that within the current set of validator nodes, there exists a fixed, unknown subset of malicious validator nodes (also known as "Byzantine validator nodes"). Further suppose that all other validator nodes (known as "honest validator nodes") diligently follow the consensus protocol. The total voting power of all validator nodes is called... N And define security thresholds f The ledger transaction system 106 can be operated, enabling... N > 3 f In other words, the ledger transaction system 106 can be manipulated to ensure that the combined voting power of malicious node devices does not exceed a security threshold. f .

[0270] Its combined voting rights M Verify transaction blocks (i.e., M ≥ N – f A subset of nodes in a given resolution can be called the number of legally mandated votes. quorum In some embodiments, the ledger transaction system 106 may further operate under the “BFT assumption”, which indicates that for every two nodes with the same number of statutory votes in the same period, there exists an honest node belonging to those two statutory votes.

[0271] Upon determining the threshold number of votes for which confirmation of execution results has been received, the leading validator node device can finalize the transaction block and transmit the confirmation to other validator node devices. As mentioned above, by utilizing the Byzantine fault model, the ledger transaction system 106 can accommodate validators who arbitrarily deviate from the protocol without constraints. Furthermore, the ledger transaction system 106 can utilize a Byzantine fault-tolerant consensus method to mitigate errors caused by malicious or hacked validators. Specifically, in one or more embodiments, the ledger transaction system 106 utilizes 2... f +1 vote as the threshold number of votes, where f This refers to the number of Byzantine voters (e.g., malicious, fraudulent, or untrusted validators) that the consensus protocol can accommodate. For example, in some embodiments, f The number of Byzantine voters that can be adapted to prevent attacks or other insecure behaviors (e.g., double-spending or forking). In some embodiments, 2 f +1 vote corresponds to exactly more than two-thirds of the validator node devices participating in the consensus.

[0272] Once a transaction block is completed, the validator node device can submit the transaction results to the storage device. In practice, in one or more embodiments, each validator node device generates data structures (e.g., transaction data structures, state data structures, and event data structures) for storing data related to the digital ledger. When consensus is reached on the execution results, the validator node device can update these data structures based on the execution results. Specifically, each validator node device can generate and maintain an independent copy of the data structures, and then update the data structures stored at that validator node device based on the execution results.

[0273] To provide additional examples, in one or more embodiments, a full node device may receive queries for information. In response, the full node device may identify relevant data within a data structure stored at the full node device and transmit the data to the requesting client device. In practice, in one or more embodiments, each full node device may generate and maintain an independent copy of the data structure. The full node device may communicate with validator node devices 108a-108b to identify the results of executed transactions and update the data structure stored at the full node device accordingly. In one or more embodiments, the full node device may further respond to a received query for information by submitting proof (e.g., a Merkle proof) to verify the accuracy of the provided data.

[0274] In one or more embodiments, client devices 112a-112n include computer devices that allow users of the device (e.g., users 116a-116n) to submit transaction requests and query information. For example, client devices 112a-112n may include smartphones, tablets, desktop computers, laptops, or other electronic devices (examples of which are described below). Figure 50 (As described). Client devices 112a-112n may include one or more applications (e.g., client application 110) that allow users 116a-116n to submit transaction requests and query information. For example, client application 110 may include software applications installed on client devices 112a-112n. Additionally or alternatively, client application 110 may include software applications hosted on one or more servers that can be accessed by client devices 112a-112n through another application (e.g., a web browser).

[0275] In some embodiments, a subset of client devices 112a-112n (and / or a subset of computer nodes 104) may have cryptographic keys to modify or manage features of the distributed digital ledger transaction network (referred to as "authorized devices"). Specifically, smart contracts may be implemented that grant authorized devices (or authorized accounts corresponding to authorized devices) permission to make modifications via a consensus protocol (and collective agreements between authorized devices). For example, within the scope of the smart contract used to make modifications, authorized devices may manage changes to the set of validator node devices participating in consensus (i.e., voting rights), changes to the processes used in validation rejection or the allocation of transaction fees (i.e., gas) among computer nodes 114, and / or changes to the tangible monetary reserves (e.g., diversified real-world assets) used to support digital assets (e.g., cryptocurrencies) on the distributed digital ledger transaction network.

[0276] In one or more embodiments, the distributed digital ledger transaction network 100 also includes one or more report managers (not shown). The report managers can track and report actions taken by components of the distributed digital ledger transaction network 100 (e.g., one of the validator node devices 108a-108b), for which rewards or fees should be provided. Some actions that the report managers can track and report include, but are not limited to, client devices submitting transaction requests, lead validator node devices proposing or failing to propose transaction blocks, lead validator node devices proposing incorrectly or malformed transaction blocks, validator node devices participating in consensus, validator node devices submitting transaction blocks to storage, and general information dissemination (whether between computer nodes 114 or to client devices 112a-112n). In one or more embodiments, the report managers report such actions to computer nodes 114 to determine and implement corresponding rewards or fees. The report managers may be... Figure 1 The distributed digital ledger transaction network 100 shown can be implemented by any device (e.g., by computer node 114) or by another computing device.

[0277] The ledger transaction system 106 can be implemented wholly or partially by individual components of the distributed digital ledger transaction network 100. In fact, although... Figure 1 The diagram illustrates a ledger transaction system 106 implemented with respect to computer node 114; however, different components of the ledger transaction system 106 can be implemented in any component of the distributed digital ledger transaction network 100. In particular, part or all of the ledger transaction system 106 can be implemented by client devices (e.g., one of client devices 112a-112n).

[0278] For example, ledger transaction system 106 can utilize client devices 112a-112n to perform various functions. To illustrate, ledger transaction system 106 can use client devices to poll one or more computer nodes 114 for transaction event updates and request data corresponding to the event sequence. Furthermore, ledger transaction system 106 can utilize client devices to generate transaction requests. Specifically, ledger transaction system 106 can use client devices to identify the primary public address identifier and sub-address identifier corresponding to a user account, and then encrypt the sub-address identifier using an encryption key. Ledger transaction system 106 can then use client devices to generate and submit a transaction request associated with that user account using the primary public address identifier corresponding to the user account and the encrypted sub-address.

[0279] B. Validator components and transaction processing

[0280] As mentioned above, a client device can submit a request for a transaction to one of the computer nodes. The validator node devices of the distributed digital ledger transaction network can then execute the transaction (as part of a transaction block) and implement the consensus protocol. If consensus is reached, the validator node devices (and full node devices) can submit the execution results to persistent storage by updating the data structures stored therein (e.g., updating the ledger state). Figure 2 The diagram illustrates the components of the validator node device used in processing received transactions, executing transactions, and submitting transactions to the storage device based on whether consensus has been reached.

[0281] about Figure 2 The following discussion will provide details about the lifecycle of a transaction, as well as additional details in the context of the validator node device components shown in the implementation of the ledger transaction system 106. Validator node device components can communicate with each other using any suitable communication protocol. For example, in one or more embodiments, validator node device components communicate via a GRPC stream with protobuf serialization.

[0282] like Figure 2As shown, client device 202 can utilize client application 204 (e.g., ledger transaction system 106 operating at client device 202, an application accessing ledger transaction system 106, or a third-party wallet application) to generate transaction requests. In one or more embodiments, client application 204 generates transaction requests by generating transaction scripts with various parameters. In one or more embodiments, client application 204 utilizes predefined transaction scripts accessible to client application 204 and inserts desired parameters into the predefined scripts. The resulting transaction script can provide details of the requested transaction, such as the transfer of one or more digital assets from a first user account (i.e., a user account associated with the user of client device 202) to a second user account.

[0283] In one or more embodiments, client device 202 further utilizes client application 204 to add a serial number to a transaction request. In practice, in one or more embodiments, the validator node device rejects a transaction request with an incorrect serial number. In some embodiments, computer nodes of the distributed digital ledger transaction network may store the current serial number associated with a user account. Client application 204 may query one of the computer nodes to identify the current serial number associated with the corresponding user account. Client application 204 may then increment the serial number and add the incremented serial number to the transaction request. The computer node may update the serial number associated with the user account in its storage device based on the application of the transaction (e.g., the execution of the transaction or the acceptance of the transaction into a mempool manager). However, in one or more embodiments, client application 204 tracks the current serial number associated with the user account to avoid querying the computer node.

[0284] Furthermore, client device 202 can utilize client application 204 to sign transaction requests. For example, the client application can use a private key associated with the user of client device 202 (i.e., associated with the sending user account) to apply a signature to the transaction request (e.g., by encrypting the transaction request). Client device 202 can then transmit the signed transaction request to validator node device 206.

[0285] In one or more embodiments, client device 202 submits a transaction to a specific address associated with validator node device 206. For example, client device 202 may submit a transaction to an address associated with an admission control component (e.g., admission control(s) 210) of validator node device 206. In one or more embodiments, client device 202 utilizes client application 204 to identify the address of validator node device 206. For example, client device 202 may utilize client application 204 to contact computer nodes in the distributed digital ledger transaction network and then identify the address of validator node device 206 via a round-robin DNS implementation optimized for reduced latency based on geographic location. In one or more embodiments, upon receiving a transaction request, validator node device 206 (e.g., using a private key stored in privacy signature manager 216) signs the transaction request and returns the signed transaction request to client device 202.

[0286] like Figure 2 As shown, validator node device 206 can receive transaction requests at load balancer 208. Specifically, as... Figure 2 As shown, the validator node device 206 includes an admission controller 210, which may include multiple admission control units. The load balancer 208 can forward tasks to the admission controller 210 to avoid overwhelming the admission control units and improve the efficiency of transaction request processing.

[0287] In practice, the admission controller 210 can manage multiple request types. Specifically, in addition to transaction requests, the admission controller 210 can also manage queries for information. The admission controller 210 can direct a given request to the appropriate component of the validator node device 206 that serves that request. For example, the admission controller 210 can direct transaction requests to the memory pool manager 212 and queries for information to the storage manager 220 to perform the requested read. Therefore, the admission controller 210 can prevent queries for information from interfering with the components serving transaction requests, and vice versa.

[0288] Upon receiving a transaction request, the admission controller 210 may perform a series of initial checks. For example, in one or more embodiments, the admission controller 210 performs a basic spam check to limit the amount of data received from a given IP address. In doing so, the admission controller 210 can provide DDoS protection by blacklisting and filtering out invalid or high-volume inputs, preventing such inputs from wasting the resources of subsequent components. In practice, in some embodiments, the admission controller 210 blacklists IPs / user accounts that generate large amounts of traffic.

[0289] Admission controller 210 can then access virtual machine 222 to perform a series of additional checks to determine whether the transaction request was correctly formed. For example, admission controller 210 can check the input signature on the transaction request to determine if the transaction request was correctly signed; check the authentication key of the user account sending the transaction request (e.g., the address of the user account or a hash of the public key associated with the user account) to confirm that the authentication key corresponds to the public key used to sign the transaction with its private key; verify that the sequence number of the signed transaction is correct; verify that the transaction script included in the transaction request is not malformed; and verify that there are sufficient funds in the account to support the maximum amount of gas that may be consumed when executing the transaction. Once it is determined that the transaction request meets the series of checks, admission controller 210 can forward the transaction request to memory pool manager 212.

[0290] In one or more embodiments, virtual machine 222 can implement a bytecode verifier and a bytecode interpreter for the programming language used by ledger transaction system 106. In fact, in one or more embodiments, ledger transaction system 106 utilizes a programming language with three different program representations: source code, intermediate representation (IR), and bytecode. Programmers can use IR to develop modules and transaction scripts; IR is high enough to write human-readable code, yet low enough to have a direct translation to bytecode. In some embodiments, both the source language and IR are compiled into bytecode.

[0291] For various reasons, the ledger transaction system 106 may use a verifiable bytecode language as the executable representation of a programming language. For example, in some embodiments, the ledger transaction system 106 applies security guarantees to all programs. Implementing these guarantees in the compiler is often insufficient, as an adversary could choose to bypass the compiler by writing malicious code directly in the bytecode language (unless running the compiler is part of transaction execution, but this would make execution slower and more complex). Therefore, the ledger transaction system 106 can avoid trusting the compiler by implementing security guarantees—type safety, reference safety, and resource safety—via bytecode verification.

[0292] Furthermore, the virtual machine 222 can use a stack-based bytecode language, which has fewer instructions compared to higher-level source languages. Moreover, each instruction has semantics that can be expressed via even fewer atomic steps. This reduces the specification footprint of the ledger transaction system 106 and makes it easier to detect implementation errors.

[0293] As mentioned above, Virtual Machine 222 can implement bytecode verifiers and bytecode interpreters for bytecode languages. Bytecode languages ​​can include stack-based virtual machines with procedure-local operand stacks and registers. Unstructured control flow can be encoded via goto and labels.

[0294] Developers can write trading scripts or modules using the Virtual Machine (IR), which are then compiled into a bytecode language. Compilation converts structured control flow structures (such as conditions and loops) into unstructured control flow and transforms complex expressions into a small number of bytecode instructions that manipulate the operand stack. The Virtual Machine 222 can then execute trades by verifying and then running this bytecode.

[0295] Virtual Machine 222 can support various types and values: Boolean values, unsigned 64-bit integers, 256-bit addresses, fixed-size byte arrays, structs (including resources), and references. In some embodiments, struct fields cannot be reference types, which prevents references from being stored in the ledger state. In some embodiments, Virtual Machine 222 does not have a heap (local data is allocated memory on the stack and released when the memory allocation process returns). Persistent data can be stored in the ledger state.

[0296] The memory pool manager 212 can provide an in-memory buffer for transactions. Specifically, the memory pool manager 212 can receive transactions provided by the admission controller 210 of the validator node device 206 and the memory pool managers of other node devices 224 (e.g., other validator node devices). In practice, transactions managed by the memory pool include those that have been committed but not yet executed, as well as those that have not yet been agreed upon through consensus.

[0297] Because the memory pool manager 212 manages multiple transactions (potentially submitted by the same user account), it can perform a series of additional checks. In fact, the memory pool manager 212 can perform additional checks to validate transaction requests against other managed transactions.

[0298] For example, in one or more embodiments, the memory pool manager 212 checks whether a transaction request forwarded by the admission controller 210 conflicts with already stored transactions. To illustrate, if the memory pool manager 212 has already stored one or more transactions sent by the same user account that sent the transaction request forwarded by the admission controller 210, the memory pool manager 212 determines whether the user account has sufficient digital assets to fund both the stored transactions and the transaction request forwarded by the admission controller 210. If the memory pool manager 212 determines that there is a possibility that the stored transactions will consume enough digital assets from the user account to fund the transaction request forwarded by the admission controller 210, then the memory pool manager 212 may reject the input of the transaction request forwarded by the admission controller 210.

[0299] Upon fulfillment of additional checks, the memory pool manager 212 can accept a transaction request (which will now be referred to as a "transaction"). In one or more embodiments, the validator node device 206 may transmit a notification to the client device 202 indicating that a transaction has been added to the memory pool manager 212. In some embodiments, the validator node device 206 also transmits the current version of the digital ledger (e.g., the current version of the transaction database, or more specifically, the transaction Merkle tree). In another embodiment, the validator node device 206 transmits an identifier to the client device 202 that is uniquely associated with the validator node device 206. In fact, in some embodiments, the client device 202 may include the identifier of the validator node device 206 in queries about the status of transactions.

[0300] In one or more embodiments, when a transaction is input into the memory pool manager 212, the validator node device 206 broadcasts (i.e., transmits) the transaction to other node devices 224. In one or more embodiments, the validator node device 206 broadcasts the transaction as soon as it is input into the memory pool manager 212. In some embodiments, the validator node device 206 broadcasts the transaction as part of periodic broadcasts. In one or more embodiments, the validator node device 206 determines the likelihood that the transaction will be included in the next transaction block and broadcasts the transaction to other node devices 224 based on this determination. For example, in some embodiments, the validator node device 206 broadcasts the transaction to other node devices 224 only if the transaction's sequence number is equal to or consecutive to the next sequence number of the corresponding user account (e.g., when the user account's current sequence number is 2, transactions 2, 3, and 4 are broadcast, but transactions with subsequent sequence numbers are not broadcast). In one or more embodiments, the memory pool manager 212 maintains an ordered queue and determines the likelihood that a transaction will be included in the next transaction block based on the ordered queue.

[0301] In one or more embodiments, upon receiving a transaction from one of the other node devices 224, the validator node device 206 performs the same checks performed when a transaction request is received from the client device 202. For example, the validator node device 206 may use the memory pool manager 212 and / or the admission controller 210 to perform the same initial and additional checks. Therefore, the validator node device 206 can prevent malicious validator node devices from sending invalid or otherwise malicious transactions that could interfere with the operation of the validator node device. In some embodiments, upon receiving a transaction from one of the other node devices 224, the validator node device 206 adds the transaction to an ordered queue maintained by the memory pool manager 212.

[0302] In one or more embodiments, the memory pool manager 212 includes a mapping between user account addresses and pending transactions, and builds various indexes on top. For example, as mentioned, the memory pool manager 212 may maintain an index called an ordered queue, which includes transactions ready to be included in the next transaction block. In one or more embodiments, the memory pool manager 212 sorts the transactions in the ordered queue based on gas prices, prioritizing transactions submitted by users willing to pay higher fees per transaction. In some embodiments, although the transactions in the ordered queue are sorted based on gas prices, the memory pool manager 212 may sort transactions submitted by the same account according to their sequence numbers within the mapping between account addresses and pending transactions.

[0303] In one or more embodiments, the memory pool manager 212 includes transactions that are not ready to be included in the next block in a separate index called a parking lot. Once an event indicates that a transaction is ready to be included in a transaction block (e.g., the transaction with the immediately preceding sequence number is broadcast to other node devices 224), the memory pool manager 212 can move the transaction from the parking lot to an ordered queue.

[0304] In one or more embodiments, the memory pool manager 212 limits the total number of transactions stored therein. In some embodiments, the memory pool manager 212 limits the number of transactions stored from the same user account. In this way, the memory pool manager 212 can prevent user accounts from continuously attacking the distributed digital ledger transaction network.

[0305] In one or more embodiments, the memory pool manager 212 applies expiration to transactions stored therein. For example, the memory pool manager 212 may apply time-to-live (TTL) expiration to transactions. The memory pool manager 212 may periodically check the TTL of transactions for expiration. In some embodiments, the memory pool manager 212 applies client-specified expiration to transactions. In fact, in some embodiments, the client device submitting the transaction request may specify the expiration of the transaction. In one or more embodiments, the memory pool manager 212 implements a minimum time on client-specified expiration to prevent clients from overwhelming the validator node device 206 by submitting a large number of transactions with low expiration times. When it is determined that a transaction has expired (i.e., either based on TTL expiration or based on client-specified expiration), the memory pool manager 212 may remove the transaction. In one or more embodiments, the memory pool manager 212 utilizes a separate component (e.g., a system TTL component) to check for expiration and remove transactions accordingly.

[0306] like Figure 2 As shown, validator node device 206 can utilize consensus manager 214 to sort transaction blocks and reach consensus on the results of execution. In other words, consensus manager 214 applies the consensus protocol to transaction blocks either assembled at validator node device 206 or received from one of the other node devices 224. For example, when validator node device 206 is selected as the lead validator node device (i.e., via the consensus protocol), consensus manager 214 can identify transaction blocks that include transactions stored in mempool manager 212 (e.g., transactions included in an ordered queue). Consensus manager 214 can then transmit the transaction blocks to the other node devices 224.

[0307] Subsequently, validator node device 206 can utilize execution engine 218 to execute transactions within the transaction block. Other node devices 224 similarly execute transactions within the transaction block. As will be discussed below... Figures 12-14B In more detail, execution engine 218 can maintain a note-like data structure, which is a portion of the data structure related to transactions in a transaction block and stored in permanent storage. In fact, execution engine 218 can use the note-like data structure to store the execution results before submitting the execution results of a transaction block to permanent storage, until consensus is reached. For example, execution engine 218 can use the note-like data structure to track the execution results of various potential paths (referred to as "parallel transaction blocks") that the distributed digital ledger transaction network might take when adding transaction blocks to the digital ledger. Below (for example, regarding...) Figure 12 It provides additional details about the note-style data structure.

[0308] In one or more embodiments, execution engine 218 utilizes virtual machine 222 to execute transactions within a transaction block. Specifically, virtual machine 222 can verify transaction scripts and modules, publish modules (under the transaction sender's account), run transaction scripts, determine execution results, and run cleanup processes (e.g., charging users gas fees and incrementing their sequence numbers). In one or more embodiments, as will be discussed below... Figures 27-28 In more detail, virtual machine 222 can perform parallel execution of transactions within a transaction block by performing pre-execution and subsequently determining the dependencies between transactions. Virtual machine 222 can then further execute subsets of transactions in parallel based on the determined dependencies.

[0309] Execution engine 218 can use portions of the data structure in the scratch data pad and the execution results of transactions corresponding to those within a transaction block to determine the proposed root value (i.e., the "root hash") of the transaction tree. Consensus manager 214 can then sign the proposed root value using a private key stored at privacy signature manager 216 and attempt to reach agreement with other node devices 224 on the proposed root value. In one or more embodiments, if validator node device 206 is selected as the lead validator node device, validator node device 206 can communicate with other node devices 224 regarding the proposed root value. In practice, in some embodiments, validator node device 206 (as the lead validator node device) communicates with other node devices 224 in a series of messages converging towards a final decision. In one or more embodiments, the lead validator node device participates in the communication but does not vote on the proposed root hash. This decision can include a final decision to accept or reject transactions included in a transaction block.

[0310] If enough votes are given for the same root value (e.g., the proposed root value determined by validator node device 206) (e.g., at least 2 votes) fIf +1 vote), the consensus manager 214 can provide the execution engine 218 with an indication that a transaction block (i.e., the previously determined result from executing the transaction block) is ready to be submitted to the storage device. In one or more embodiments, the lead validator node device receives consensus votes and determines whether the block has been completed (i.e., whether enough votes have been received). The lead validator node can then transmit an indication based on this determination of completion. In one or more embodiments, the indication includes the signature of the validator node device that confirms the consensus of the root value from the votes of the other node devices 224. In response to receiving the indication, the execution engine 218 can send the corresponding execution result stored in the note-like data structure to the storage manager 220 to be written to the permanent storage device. Furthermore, the execution engine 218 can remove values ​​that are no longer needed from the note-like data structure (e.g., parallel transaction blocks that will not be submitted to the storage device, as will be discussed in more detail below).

[0311] Validator node device 206 uses storage manager 220 to add the execution results to the digital ledger. Specifically, storage manager 220 can commit transactions within a transaction block, including changes to the digital ledger based on the execution results. In one or more embodiments, storage manager 220 also stores the signatures of validator node devices that vote to confirm the root value of consensus. When a transaction is committed from a transaction block, storage manager 220 (or execution engine 218) can assign a version to each transaction and store the transaction, root value, and version in a transaction database (e.g., a transaction tree). Storage manager 220 can then increment the version number for assignment to the next transaction. When a transaction is committed to storage, consensus manager 214 can notify mempool manager 212, which can then remove the transaction from its internal storage.

[0312] In one or more embodiments, when a failure occurs while storing a transaction block, the storage manager 220 will "panic" (e.g., disconnect from the execution engine 218). Upon reconnection, the storage manager 220 and / or the execution engine 218 will determine the current state of the distributed digital ledger transaction network. For example, in one or more embodiments, the storage manager 220 sends the root value from the previously committed transaction block to the execution engine 218, and the execution engine 218 continues from there. (The following is an example of...) Figure 36 It provides additional details on consensus security during restart.

[0313] In one or more embodiments, validator node device 206 also includes a state synchronization manager component (not shown). Specifically, the state synchronization manager can perform synchronization operations when validator node device 206 restarts or falls behind the currently proposed state of the distributed digital ledger transaction network. For example, if consensus manager 214 identifies a transaction block based on a version of the digital ledger (i.e., a version of the transaction tree) unknown to validator node device 206, the state synchronization manager can update validator node device 206 to the latest state to allow participation in consensus. For illustration, in one or more embodiments, the state synchronization manager pulls chunks of transactions and (e.g., uses execution engine 218) executes these chunks to determine a ledger state of the distributed digital ledger transaction network that is consistent with the currently agreed-upon ledger state.

[0314] In some embodiments, the validator node device 206 also includes a system state machine manager. Specifically, the system state machine manager can perform general node management operations, such as blacklisting nodes and processing malicious transactions.

[0315] As mentioned above, in addition to servicing transaction requests, the computer nodes of the distributed digital ledger transaction network can also serve as servicing services for information queries. For example, upon receiving a query for information, the admission controller 210 of the validator node device 206 can directly connect to the storage manager 220. The admission controller 210 can receive the requested information and corresponding proof from the storage manager 220. The validator node device 206 can then forward the information to the submitting client device. Although Figure 2 The discussion is presented in the context of validator node device 206, but in one or more embodiments, full node devices of the distributed digital ledger transaction network provide services for querying information.

[0316] In one or more embodiments, validator node device 206 (or other computer nodes in the distributed digital ledger transaction system) will restart upon encountering a technical problem (e.g., a crash). Components of validator node device 206 may respond to the technical problem or act accordingly when a technical problem is anticipated. For example, in one or more embodiments, admission controller 210 loses transactions that are performing initial checks on it (e.g., those submitted by client device 202) upon a crash. Therefore, validator node device 206 may not respond to client device 202 as expected (e.g., it may not notify client device 202 that the transaction has been accepted by mempool manager 212). Client device 202 can then resubmit the transaction.

[0317] The memory pool manager 212 can similarly discard all stored transactions upon a crash. In one or more embodiments, the memory pool manager 212 implements write-ahead logging (WAL) to avoid problems associated with discarding transactions.

[0318] In one or more embodiments, consensus manager 214 stores voting data in the WAL before submitting votes corresponding to transaction blocks. For example, in some embodiments, consensus manager 214 utilizes storage manager 220 to store and delete voting data as needed. After a crash, consensus manager 214 can retrieve the voting data to identify the transaction blocks that were voted on. In some embodiments, consensus manager 214 avoids operating on blocks that conflict with the voting data.

[0319] In one or more embodiments, upon restarting after a crash, execution engine 218 can re-establish a connection with consensus manager 214 and retrieve transaction blocks corresponding to the voting data stored in the WAL by consensus manager 214. Execution engine 218 can then re-execute the transaction blocks, providing an error if the obtained root value does not match the root value stored in the WAL. Furthermore, consensus manager 214 can retrieve the latest committed version of the transaction tree from storage manager 220. If there are sufficient votes for committing another block, consensus manager 214 can request the commit of the transaction block via execution.

[0320] If a crash occurs before adding a transaction block to persistent storage, storage manager 220 can re-establish a connection to execution engine 218. Execution engine 218 can then provide the next transaction block to storage manager 220. Specifically, execution engine 218 can re-execute the transaction block to obtain write-sets. In some embodiments, validator node device 206 implements a callback upon completing the commit of a transaction block or completing a synchronous call from execution engine 218 to storage manager 220, after which execution engine 218 prunes the note-like data structure. Furthermore, when committing a transaction block to persistent storage, storage manager 220 can delete the voting data corresponding to the transaction block stored in the WAL by consensus manager 214.

[0321] about Figures 1-2 Each component of the described computing device may communicate with each other using any suitable communication technology. It will be appreciated that although these components are shown and / or described separately, any of these components may be combined into fewer components, such as a single facility, divided into more components, or configured as different components that may serve a particular embodiment.

[0322] Components may include software, hardware, or both. For example, components 204-222 may include one or more instructions stored on a computer-readable storage medium and executable by a processor of one or more computing devices. When executed by one or more processors, the computer-executable instructions of the ledger transaction system 106 may cause client devices and / or server devices to perform the methods described herein. Alternatively, components 204-222 and their corresponding elements may include hardware, such as dedicated processing equipment for performing specific functions or groups of functions. Additionally, components 204-222 may include a combination of computer-executable instructions and hardware.

[0323] Furthermore, components 204-222 of the ledger transaction system 106 can be implemented, for example, as one or more operating systems, one or more independent applications, one or more modules of an application, one or more plugins, one or more library functions or functions that can be called by other applications, and / or a cloud computing model. Therefore, components 204-222 can be implemented as independent applications, such as desktop or mobile applications. Additionally, components 204-222 can be implemented as one or more web-based applications hosted on a remote server. Components 204-222 can also be implemented within a suite of mobile applications or "apps".

[0324] II. Storage

[0325] A. Overview

[0326] As mentioned above, there are many technical challenges in storing data across computing devices using traditional blockchain systems. In fact, traditional blockchain systems are rigid and inflexible (e.g., they do not offer flexible storage management options for individual computing devices) and consume excessive computing resources. Ledger transaction system 106 can achieve storage procedures across computing devices in a way that improves security and flexibility while reducing storage and processing requirements. Specifically, ledger transaction system 106 can utilize various data structures and storage procedures that reduce sensitivity to tampering, allow computing devices (e.g., validator nodes or full nodes) to flexibly modify the storage of the digital ledger based on local characteristics, and allow for a reduction in computing storage and processing overhead.

[0327] For example, in one or more embodiments, the ledger transaction system 106 generates a single versioned database (e.g., a database reflecting the status of transactions, events, and accounts at any particular iteration). The version number may include an unsigned 64-bit integer timestamp corresponding to the number of transactions the system has executed. In each version... i The database can store (transactions) T i Transaction outputO i Ledger Status S i A tuple. Given an execution function f, a tuple can indicate the state of the ledger. S i-1 Execute transaction T i Output will be generated O i and the new ledger status S i ;Right now, To illustrate, Figures 3-6 The diagram illustrates data structures utilized by ledger transaction system 106 according to one or more embodiments. Specifically, ledger transaction system 106 can classify transactions ( T i ) are stored in the transaction data structure, and the transaction output ( O i ) is stored as an event data structure, and the ledger status ( S i It is stored as a state data structure that can be used to achieve consensus via a distributed digital ledger transaction network.

[0328] In one or more embodiments, the ledger transaction system 106 can, at the client device, re-execute each transaction in the ledger history corresponding to a specific ledger state. T i Then the obtained ledger status is compared with the specific ledger status in the versioned database. S i and transaction output O i The comparison is performed to verify that the specific ledger state is correct. This allows client devices to examine the validator node devices of the distributed digital ledger transaction network to ensure that transactions are executed correctly.

[0329] For example, Figure 3 A state data structure 300 generated and maintained by a ledger transaction system 106 according to one or more embodiments is shown. For example... Figure 3As shown, the state data structure 300 includes a state database 302. In one or more embodiments, the state database 302 includes account data 304 associated with each user account in the distributed digital ledger transaction network. For example, the ledger transaction system 106 can generate account data for a specific user account within the state database 302 by storing the user account's account value and a hash of that account value within the state database 302. The account value of a given user account can include any type of data associated with the user account (e.g., digital assets held by the user account, one or more transaction event counters corresponding to the user account, and other modules and / or resources stored in the user account, etc.). In one or more embodiments, the ledger transaction system 106 generates a hash of the account value by applying a hash function to the account value. As will be discussed, in one or more embodiments, the ledger transaction system 106 uses the account data (e.g., the account value) associated with the user account to generate an account state representation (e.g., a hash within a state Merkle tree) corresponding to that user account.

[0330] For example, as in Figure 3 As further shown, the state data structure 300 also includes a state tree 306. In one or more embodiments, the state tree 306 includes a state Merkle tree. For example, the state tree 306 may include a state Merkle tree with 2... n A state Merkle tree (e.g., a sparse Merkle tree) with leaves, where the path from the root of state tree 306 (i.e., state root 308) to a leaf node (i.e., one of leaf nodes 310a-310e) represents the address corresponding to a user account. n Bit address key. In one or more embodiments, ledger transaction system 106 utilizes n The bit address key serves as the address for the corresponding user account.

[0331] Where the address represented by the address key corresponds to an existing user account, the ledger transaction system 106 may store the account state representation within a leaf node associated with that address key (i.e., as part of a leaf node). In one or more embodiments, the ledger transaction system 106 generates the account state representation of a user account by applying a hash function to the account data associated with the user account to generate a hash value corresponding to the account data. Specifically, the ledger transaction system 106 may apply a hash function to one or more components of the account data. For example, in one or more embodiments, the ledger transaction system 106 applies a hash function to the account value of the user account to generate a hash of the account value (i.e., the same hash value stored as part of the user account's account data). The ledger transaction system 106 may then store the hash of the account value as an account state representation. In some embodiments, the ledger transaction system 106 generates the account state representation by further combining the hash value corresponding to the account data (e.g., the hash of the account value) with additional data (e.g., the user account's eviction date).

[0332] In one or more embodiments, if the address key corresponds to a non-existent user account, the ledger transaction system 106 stores a default value (e.g., an empty string) within the leaf node. Figure 3 As shown, if all child nodes of an internal node correspond to non-existent user accounts, the ledger transaction system can store default values ​​(by...) within that internal node. Figure 3 The default nodes are represented as 312a-312c.

[0333] In one or more embodiments, the ledger transaction system 106 generates the root value of state tree 306 by combining and hashing the node values ​​stored within each pair of nodes in state tree 306. Specifically, for each internal node of state tree 306, the ledger transaction system 106 may combine (e.g., concatenate) the node values ​​stored within their respective child nodes and then apply a hash function to the combined values. In some embodiments, the ledger transaction system 106 hashes the node values ​​stored within child nodes and then combines the hash values ​​to generate the node value for the corresponding internal node. The ledger transaction system 106 may iteratively combine and hash the node values, starting from the bottom and moving towards the top of state tree 306, ultimately generating the root value of state tree 306. The ledger transaction system 106 may then store the root value in state root 308 of state tree 306. Therefore, the root value stored in state root 308 represents the account state of each user account in a specific state of the distributed digital ledger transaction network. As will be discussed below, the ledger transaction system 106 can further store the root value of the state tree 306 within the transaction tree of the distributed digital ledger transaction network.

[0334] Furthermore, in one or more embodiments, the ledger transaction system 106 generates a state tree for each state of the distributed digital ledger transaction network. Specifically, for each transaction (or transaction block) executed across the distributed digital ledger transaction network, the ledger transaction system 106 may generate a new state tree representing the state of the distributed digital ledger transaction network resulting from the transaction (or transaction block). In particular, the new state tree may represent the account state of each user account after the execution of the transaction block (i.e., reflecting how the user accounts associated with those specific transactions have changed). In some embodiments, the ledger transaction system 106 updates the state tree after the execution of each transaction (e.g., by updating the account state representation corresponding to the user accounts associated with the transaction).

[0335] In some embodiments, the ledger transaction system 106 represents the initial state of the distributed digital ledger transaction network as an empty state (e.g., an empty state database). The ledger transaction system 106 can then use special transactions... T 0 Instead of going through the normal transaction process to generate the genesis state, this special transaction... T 0 The specific modules and resources to be created are defined. The ledger transaction system 106 can configure client devices and validator node devices to accept only transactions with specific... T 0 The beginning of the ledger history, that specific T 0 Its cryptographic hash identifier.

[0336] As mentioned above, in some embodiments, the ledger transaction system 106 reduces storage and processing requirements by storing a subset of modified nodes. For example, the ledger transaction system 106 may generate a state tree component with node values ​​corresponding to changed user account states. These node values ​​may point to node values ​​in the previous state tree corresponding to unchanged user account states. In this way, the ledger transaction system 106 can track nodes that have changed in different states without needing to copy the entire state tree. In some embodiments, the ledger transaction system 106 utilizes this method to track multiple states while awaiting consensus and committing the consensus state data structure to memory. Below (e.g., regarding...) Figures 8-9 , Figures 14A-14B It provides additional details about storing a subset of modified nodes to track different states.

[0337] Because both the account data 304 stored in the state database 302 and the account state representations stored in the state tree 306 include hashes of the user account's account value, the state database 302 can include a mapping between the account state representations and the user account's account value. For example, the ledger transaction system 106 can use the corresponding hashes of the account values ​​to index the account values ​​within the account data 304. In practice, the ledger transaction system 106 can then utilize the state tree 306 to find the account value of a given user account. Specifically, the ledger transaction system 106 can find the state root 308 of the state tree 306 and then (e.g., using the user account's address) traverse the state tree 306 to find the leaf node of the user account. The ledger transaction system 106 can then identify the account state representation stored within the leaf node and use the mapping in the state database 302 to find the user account's account value based on that account state representation (i.e., based on the hash of the account value stored as part of the account state representation).

[0338] In addition to generating data structures that store data associated with account status, the ledger transaction system 106 can also generate data structures that store data associated with transaction events generated when transactions are executed across a distributed digital ledger transaction network. Figure 4 An event data structure 400 generated and maintained by a ledger transaction system 106 according to one or more embodiments is shown. For example... Figure 4 As shown, the event data structure 400 includes an event tree 402. In one or more embodiments, the event tree 402 includes an event Merkle tree (e.g., a Merkle accumulator).

[0339] In one or more embodiments, event tree 402 corresponds to a specific transaction executed across the distributed digital ledger transaction network, and leaf nodes 408a-408f correspond to transaction events generated through the execution of that transaction. In other words, when executing a transaction across the distributed digital ledger transaction network, ledger transaction system 106 can generate any number of transaction events (i.e., zero or more). Therefore, ledger transaction system 106 can generate an event tree corresponding to the transaction and representing the transaction events generated during its execution.

[0340] Specifically, when the ledger transaction system 106 generates one or more transaction events during transaction execution, the ledger transaction system 106 can generate a transaction event representation corresponding to each transaction event. The ledger transaction system can then store each transaction event representation in one of the leaf nodes 408a-408f of the event tree 402. The ledger transaction system 106 can generate a transaction event representation corresponding to a given transaction event by applying a hash function to one or more components of the event data associated with the transaction event.

[0341] Furthermore, in one or more embodiments, the ledger transaction system 106 is referenced above. Figure 3 The root value of the event tree 402 is generated from the root value of the state tree 306 (e.g., by iteratively combining node values ​​and calculating a hash). The ledger transaction system 106 can store the root value in the event root 406 of the event tree 402. Therefore, the root value stored within the event root 406 can represent each transaction event associated with a transaction executed across the distributed digital ledger transaction network. As will be discussed below, the ledger transaction system 106 can further store the root value of the event tree 402 within the transaction tree of the distributed digital ledger transaction network.

[0342] In addition, such as Figure 4 As shown, the event data structure 400 also includes an event database 404. In one or more embodiments, the event database 404 includes event data 410 corresponding to transaction events represented by the event tree 402. In practice, in some embodiments, the event data 410 includes event data corresponding to transaction events associated with transactions executed across the distributed digital ledger transaction network (i.e., each transaction event represented by any event tree generated by the ledger transaction system 106). The event data corresponding to a transaction event may include various types of data corresponding to the transaction event (e.g., an address within a state data structure of a user account associated with the transaction event, a count value of a transaction event counter for the user account after the transaction event is generated, details of the transaction event such as the transaction amount, etc.). As mentioned above, in one or more embodiments, the ledger transaction system 106 uses the event data corresponding to a transaction event to generate a transaction event representation (e.g., a hash) corresponding to that transaction event. In one or more embodiments, the event database 404 includes a mapping between transaction event representations and their corresponding event data, and the ledger transaction system 106 utilizes the event database 404 to find event data based on the corresponding transaction event representation and vice versa.

[0343] In addition to data structures that store data associated with user accounts and transaction events, ledger transaction system 106 can also generate data structures that store data associated with transactions executed across a distributed digital ledger transaction network. Figure 5 A transaction data structure 500 generated and maintained by a ledger transaction system 106 according to one or more embodiments is shown.

[0344] like Figure 5As shown, the transaction data structure 500 includes a transaction tree 502. In one or more embodiments, the transaction tree 502 includes a transaction Merkle tree. For example, the transaction tree 502 may include an append-only transaction Merkle tree (e.g., a Merkle accumulator) to which the ledger transaction system 106 appends new leaf nodes for each transaction executed across the distributed digital ledger transaction network. The transaction tree 502 continues to grow as the ledger transaction system 106 adds new leaf nodes. In one or more embodiments, having k The structure of the transaction tree 502 for each object is similar to that of a size of 2 n A full binary tree, in which n Is to make k ≤ 2 n The smallest number. However, as Figure 5 As shown, in some embodiments, the ledger transaction system 106 replaces any empty subtrees with default nodes (such as those represented by default nodes 504a-504b).

[0345] Ledger transaction system 106 can store a transaction representation corresponding to the transaction associated with each leaf node in leaf nodes 506a-506e. In one or more embodiments, ledger transaction system 106 generates a transaction representation corresponding to a specific transaction by combining several data components. For example, as Figure 5 As shown, the ledger transaction system can combine (e.g., connect) signed transactions 508, state tree root value 510, and event tree root value 512.

[0346] A signed transaction 508 includes an authenticated representation of a specific transaction. For example, a signed transaction 508 may include data identifying a transaction signed using a user account's private key (e.g., with a transaction identifier or other transaction details). To illustrate, a user's client device associated with a user account can generate a signed transaction 508 by using the private key corresponding to the user account to verify whether the transaction is authorized.

[0347] As shown, the ledger transaction system 106 can also utilize the state tree root value 510 during the generation of transaction representations within the transaction tree 502. The state tree root value 510 includes the state root (e.g., generated during transaction execution and stored in the state tree) that is stored in the state tree. Figure 3 The root value within the state tree 306 (state root 308). In other words, the state tree root value 510 represents the state of the distributed digital ledger transaction network after the ledger transaction system 106 has executed that particular transaction.

[0348] Furthermore, the ledger transaction system 106 can also utilize the event tree root value 512 during the generation of transaction representations within the transaction tree 502. The event tree root value 512 includes the event root generated during transaction execution and stored in the event tree (e.g., ...). Figure 4 The root value within the event tree 402 (event root 406). In other words, the event tree root value 512 represents an event generated during the execution of a transaction. In one or more embodiments, the ledger transaction system 106 includes less data, different data, or additional data as part of a combined data component. For example, the ledger transaction system 106 may include the execution status of a particular transaction or the gas used in executing a transaction.

[0349] like Figure 5 As further illustrated, the ledger transaction system 106 can apply hash function 514 to the combined data components and store the resulting hash value as a transaction representation in one of the leaf nodes 506a-506e. However, in one or more embodiments, the ledger transaction system 106 can apply hash function 514 individually to each data component and then combine the resulting hash values ​​to generate a transaction representation.

[0350] Furthermore, the ledger transaction system 106 can determine the values ​​of various nodes in the transaction tree 502, including the root value of the transaction root 516. Specifically, the ledger transaction system 106 can combine node values ​​corresponding to child nodes and then apply a hash function to the combined values ​​to determine the node values ​​within the transaction tree 502. The ledger transaction system 106 can iteratively combine node values ​​and apply a hash function (working from the bottom to the top of the tree) to generate the root value of the transaction tree 502.

[0351] By constructing the transaction tree 502 in this way, the root value of the transaction root 516 of the transaction tree 502 represents a combination of events, transactions, and states. In fact, in one or more embodiments, by utilizing the root values ​​of the state tree and the event tree to generate the root values ​​of the transaction tree, the ledger transaction system 106 can generate root values ​​of the transaction tree that uniquely identify transactions, events, and (historical and current) account states throughout the entire lifecycle of the digital ledger. In other words, modifications to events, accounts, or transactions will propagate through various Merkle trees and result in different root values ​​for the transaction tree.

[0352] Despite Figure 5 Not shown, but in one or more embodiments, transaction data structure 500 also includes a transaction database. The transaction database may include transaction data corresponding to transaction representations stored within transaction tree 502. In one or more embodiments, the transaction database may also include a mapping between transaction data and corresponding transaction representations.

[0353] In one or more embodiments, the ledger transaction system 106 utilizes the root value of the transaction data structure within the digital ledger to achieve consensus across the distributed digital ledger transaction network. For example, Figure 6 Representations of ledger information for obtaining consensus are shown according to one or more embodiments. For example... Figure 6 As shown, the ledger transaction system 106 can obtain consensus on ledger information 602, which includes version information 604, transaction tree root value 606, and consensus certificate hash 608.

[0354] like Figure 6 As shown, ledger information 602 may include version information 604. Specifically, version information 604 may include data representing the version of the latest transaction (or transaction block) executed across the distributed digital ledger transaction network. In other words, the data stored within version information 604 may represent the version of the transaction tree at the time the latest transaction was executed.

[0355] like Figure 6 As shown, ledger information 602 may also include a transaction tree root value 606. The transaction tree root value 606 includes the root value of the transaction tree generated by the ledger transaction system 106 as described above (i.e., by combining the node values ​​of the transaction tree and calculating a hash). Figure 5 (The root value of transaction root 516 of transaction tree 502). In one or more embodiments, ledger transaction system 106 uses transaction tree root value 606 as a representation of the digital ledger. In fact, as just mentioned, the root value of transaction root 516 can represent transactions, events, and account states throughout the history of the digital ledger.

[0356] In one or more embodiments, the ledger transaction system 106 may store additional data in the ledger information 602. For example, the ledger transaction system 106 may store the current timestamp of the distributed digital ledger transaction network within the ledger information 602. The ledger transaction system 106 may provide such data (as well as the data described above) to a client device in response to a query received from the client device.

[0357] In one or more embodiments, the validator node devices of the distributed digital ledger transaction network utilize ledger information 602 to generate votes and reach consensus on the current state of the distributed digital ledger transaction network. Figure 6As shown, the ledger transaction system 106 can generate validator signatures (represented by keys 610a-610c) from validator node devices 612a-612c. As mentioned above, when consensus is reached on ledger information 602, the ledger transaction system 106 generates validator signatures corresponding to the validator node devices (e.g., validator node devices 612a-612c) that voted on ledger information 602. For example, the ledger transaction system 106 can generate validator signatures by encrypting the ledger information 602 corresponding to a transaction using the private key associated with validator node devices 612a-612c. Below (for example, regarding…) Figures 32-33 It provides additional details on obtaining consensus from validator nodes.

[0358] In the version for the transaction tree N When generating validator signatures, the ledger transaction system 106 may discard or overwrite validator signatures from previous versions of the transaction tree. However, in some embodiments, if the execution of a transaction indicates a change to the set of validator node devices, the ledger transaction system 106 archives the validator signatures from previous versions of the transaction tree (i.e., those corresponding to the previous set of validator node devices). For example, the ledger transaction system 106 may store validator signatures corresponding to the previous set of validator nodes within a signature data structure.

[0359] Although not shown in the figure, the ledger transaction system 106 can utilize a signature data structure to store the validator set history and signature history associated with the distributed digital ledger transaction network. Specifically, the validator set history may include validator node devices associated with each set of validator node devices capable of voting on transaction blocks (e.g., each set of validator node devices associated with a voting period). In one or more embodiments, the ledger transaction system 106 stores the complete set of validator node devices by storing the public keys associated with each validator node device from that set. In effect, the validator set history includes a history of changes to the set of validator node devices capable of voting on transaction blocks. The signature history may include validator signatures associated with each transaction executed across the distributed digital ledger transaction network before the validator node device set was changed (e.g., before the end of the voting period).

[0360] In addition, such as Figure 6As shown, ledger information 602 may include consensus certificate hash 608. Ledger transaction system 106 can generate consensus certificate hash 608 by applying the hash value to a consensus certificate generated by a leading validator node device when it reaches consensus on a transaction block including the latest transaction by collecting the necessary votes from other validator node devices. The consensus certificate may include a statutory resolution vote count certificate (referring to the "statutory resolution vote count" of the validator node devices that voted to verify the transaction block). Below (for example, regarding...) Figures 31-32 It provides additional details about consensus, validator nodes, voting, and voting periods.

[0361] In one or more embodiments, the ledger transaction system 106 can connect transaction blockchains. Specifically, the ledger transaction system 106 can connect transaction blockchains by including the consensus certificate hash of another transaction block within a transaction block. For example, the ledger transaction system 106 may include the consensus certificate hash of a previous (e.g., immediately preceding) transaction block. In some embodiments, the ledger transaction system 106 may include a fixed consensus certificate hash value.

[0362] In one or more embodiments, each validator node device maintains a local record tree (e.g., transaction tree 502). The initial root of the tree may include a consensus certificate hash agreed upon by the current set of validator nodes as part of the current epoch setup. Specifically, each branch of the local tree may include a chain of records alternating between transaction blocks and consensus certificates. In some embodiments, when selected, a lead validator node device proposes a new transaction block, typically extending the statutory resolution vote certificate of the longest branch (a branch within the longest branch) of the local tree. If the proposal is successfully broadcast, honest validator nodes can verify the data, execute the transaction block, and send a vote back to the lead validator node device. Upon receiving sufficient votes agreeing on the state of the digital ledger resulting from the execution of the transaction block, the lead validator node device can create a consensus certificate for the transaction block and broadcast it to other validator nodes, thereby extending the chain length by one transaction block. Subsequently, the ledger transaction system 106 can select a new lead validator node device to drive another round of consensus, further extending the chain.

[0363] Therefore, the ledger transaction system 106 can utilize data structures to store, verify, and distribute data representing the digital ledger implemented and maintained by the distributed digital ledger transaction network. Specifically, the ledger transaction system 106 can store data within the transaction data structure describing each transaction executed across the distributed digital ledger transaction network, the transaction events generated by these transactions, and how these transaction events change user accounts. Any unauthorized modification to an event, account, or transaction will alter the corresponding data structure, modify the ledger information, and will fail to achieve consensus across the distributed digital ledger transaction network.

[0364] B. Strategies for storing deletion

[0365] As mentioned above, traditional blockchain systems generate and store large amounts of data. For example, traditional systems can generate data about transactions that have been executed across the network, as well as data associated with user accounts on the network. Many of these traditional systems store data on the network (i.e., on the computer nodes participating in the network). Traditional systems can then use the data stored on the network to update the state of the network (i.e., update the digital ledger implemented on the network) and / or provide services for queries of information.

[0366] However, as mentioned above, these traditional blockchain systems suffer from technical drawbacks that lead to inefficiency and inflexibility. For example, traditional blockchain systems are often inefficient because they store all data related to the digital ledger (i.e., the entire history of the digital ledger) on the computer nodes participating in the network. As the digital ledger grows, traditional systems require more computing resources (such as computing memory) from the computer nodes in order to maintain the data corresponding to the digital ledger.

[0367] Besides efficiency concerns, traditional blockchain systems are also inflexible. In particular, many traditional blockchain systems strictly require participating computer nodes to store the entire history of the digital ledger, regardless of the role of that computing device. Thus, traditional systems may require some computer nodes to store more data than necessary to fulfill their respective roles. Therefore, traditional systems often fail to meet the flexible storage requirements that cater to the needs of computer nodes.

[0368] One or more embodiments of the ledger transaction system 106 implement flexible storage deletion and merging to more effectively manage the limited storage resources of computer nodes participating in a distributed digital ledger transaction network. Specifically, the ledger transaction system 106 can utilize configurable data storage deletion rules to remove various data structures (all or part of them) stored across various computer nodes throughout the distributed digital ledger transaction network. In practice, the ledger transaction system 106 can implement different data storage deletion rules across different devices based on user preferences, computing device roles or functions (e.g., validator nodes versus full nodes), or storage capacity (e.g., remaining storage). For example, a user of a computer node can define what data structures (what type, what part, or at what frequency) or for how long (e.g., for how long) are retained. To illustrate, the ledger transaction system 106 can receive user interactions (via the user interface of a computer node) instructing the user to select a specific time of day of the week to identify account balances. The ledger transaction system 106 can traverse data structures (e.g., state databases and / or state trees), identify relevant nodes for the requested information, and remove remaining data. Therefore, the ledger transaction system 106 can flexibly determine what events, transactions, statuses, and / or account data should be maintained and / or deleted at various computing devices in the distributed digital ledger transaction network.

[0369] Ledger transaction system 106 can remove data while still maintaining the ability to verify or accurately determine the consensus of historical or proposed digital ledgers. For example, ledger transaction system 106 can remove underlying data from a database while maintaining the data representation (e.g., hash) within a certified data structure. This approach allows ledger transaction system 106 to verify the validity of historical or proposed data structures without retaining the underlying data used to generate the structure itself.

[0370] In some embodiments, the ledger transaction system 106 may remove different parts of a data structure to reduce the storage burden at computer nodes. For example, in one or more embodiments, the ledger transaction system 106 deletes data stored at the computer node that corresponds to a completed subtree in the transaction tree. In some embodiments, the ledger transaction system 106 may also merge data structures (e.g., structures reflecting different states) to reduce size and memory requirements. To illustrate, when updating the state of the distributed digital ledger transaction network, the ledger transaction system 106 may generate state tree components (rather than the entire state tree) pointing to node values ​​in the previous state tree that correspond to the unchanged user account states.

[0371] In one or more embodiments, the ledger transaction system 106 applies different storage deletion rules to different computing devices (e.g., different rules depending on whether the computer node is a full node device or a validator node device). In some embodiments, the ledger transaction system 106 deletes and / or merges data structures based on the capabilities or preferences of a particular computer node. In this way, the ledger transaction system 106 can flexibly apply different storage deletion and merging rules to improve the efficiency of storage resources.

[0372] For example, Figure 7 A ledger transaction system 106 is illustrated, according to one or more embodiments, for deleting a portion of a transaction tree stored at a computer node. For example... Figure 7 As shown, the ledger transaction system 106 analyzes the transaction tree 702 stored at the validator node device 730. As mentioned above, the leaf nodes 704a-704f of the transaction tree 702 correspond to the various transactions executed across the distributed digital ledger transaction network. In fact, when a new transaction is executed across the distributed digital ledger transaction network, the ledger transaction system 106 appends new leaf nodes corresponding to those transactions to the transaction tree 702.

[0373] However, in one or more embodiments, the ledger transaction system 106 may determine that validator node device 730 will not service queries for information. For example, the ledger transaction system 106 may determine that a sufficient number of full node devices are participating in the distributed digital ledger transaction network to respond to queries for information. In determining that validator node device 730 will not service queries, the ledger transaction system 106 may determine only those nodes that maintain the transaction tree 702 necessary for validator node device 730 to perform its validation role (e.g., maintaining the data stored within those nodes). Therefore, the ledger transaction system 106 may apply a set of storage deletion rules to delete tree nodes that are not necessary for validation (e.g., deleting the data stored within those nodes) in order to reduce the amount of storage used in the storage transaction tree 720.

[0374] For example, in one or more embodiments, the ledger transaction system 106 determines that a subtree is complete and removes child nodes included in the subtree while maintaining the root node of the subtree. In one or more embodiments, the ledger transaction system 106 determines that a subtree is complete when each node in the subtree (excluding leaf nodes) has two child nodes.

[0375] For example, such as Figure 7As shown, ledger transaction system 106 determines that the subtree from internal node 706c is full (e.g., complete or populated). In response, ledger transaction system 106 deletes the leaf nodes 704a-704d and internal nodes 706a-706b (indicated by dashed lines) corresponding to the subtree. It will be appreciated that deleting leaf nodes 704a-704d may also include deleting entries in the database corresponding to transaction tree 702. Ledger transaction system 106 maintains internal node 706c as the root node of this subtree.

[0376] Similarly, ledger transaction system 106 determines that the subtree from internal node 706d is full. In response, ledger transaction system 106 deletes leaf nodes 704e-704f (and / or their corresponding database entries). Ledger transaction system 106 maintains internal node 706d as the root node of that subtree. (As in...) Figure 7 As can be seen, the ledger transaction system 106 maintains a subtree including leaf node 704g, because the subtree is not complete, as indicated by the default node 708 within the subtree.

[0377] As the ledger transaction system 106 continues to attach leaf nodes to the transaction tree 702 in response to transaction execution, it can continue to identify complete subtrees and delete their child nodes while maintaining their root nodes. In one or more embodiments, the ledger transaction system 106 also identifies subtrees consisting of an exact single leaf node and replaces these subtrees with a single node representing the leaf node. In one or more embodiments, the ledger transaction system 106 maintains the root node of the subtree to enable the validator node device 730 to participate in validating transaction blocks. In effect, by maintaining the root node of the subtree, the ledger transaction system 106 can re-evaluate the root value of the root node 710 of the transaction tree 702 after attaching new leaf nodes. By maintaining the root node containing the hash value reflecting the leaf node, the ledger transaction system 106 can still verify the accuracy of the transaction tree without storing the leaf nodes initially used to determine the hash value at the root.

[0378] like Figure 7 Furthermore, the ledger transaction system 106 illustrates the maintenance of the transaction tree 720 stored at the full node device 740. In fact, as shown... Figure 7As shown, the ledger transaction system 106 implements a different storage method for the full node device 740 compared to the validator node device 730. For example, in one or more embodiments, the ledger transaction system 106 determines that the full node device 740 will serve queries for information. Therefore, the ledger transaction system 106 determines that the full node device 740 will store the entire transaction tree 720 (e.g., the entire history of the digital ledger). Therefore, the ledger transaction system 106 can prevent the deletion of the transaction tree 720 or its nodes. More precisely, as Figure 7 As shown, when transactions are executed across a distributed digital ledger transaction network, the ledger transaction system 106 attaches new leaf nodes corresponding to these transactions to the transaction tree 720. Therefore, the transaction tree 720, stored at the full node device 740, grows with newly executed transactions.

[0379] In addition to deleting or merging portions of the transaction data structure, the ledger transaction system 106 can also delete or merge state data structures (or other data structures) stored at computer nodes to reduce the amount of data stored at the computer nodes. For example, Figure 8 A ledger transaction system 106 is shown, which deletes or merges portions of a state tree stored at a computer node according to one or more embodiments.

[0380] like Figure 8 As shown, the ledger transaction system 106 manages a state tree 804 stored at the validator node device 802. As discussed above, the leaf nodes 806a-806f of the state tree 804 store account state representations corresponding to user accounts, and the root value stored in the root node 808 of the state tree 804 represents the state of accounts across the distributed digital ledger transaction network. As further mentioned, when a transaction is executed, one or more user accounts in the distributed digital ledger transaction network are modified. Therefore, the ledger transaction system 106 can generate new state trees to represent the state of the distributed digital ledger transaction network generated by each transaction (or transaction block). Thus, in some embodiments, the ledger transaction system 106 stores each state tree within a state data structure at the computer nodes of the distributed digital ledger transaction network.

[0381] However, the ledger transaction system 106 can reduce the amount of storage used in the stored state data structure. Specifically, in one or more embodiments, the ledger transaction system 106 determines that the validator node device 802 will not serve queries for information and therefore will not store a state tree representing the previous state of the distributed digital ledger transaction network. In fact, because the validator node device 802 only needs the latest state of the distributed digital ledger transaction network to determine the next state, the ledger transaction system 106 can determine that the validator node device 802 will only store the latest state tree (or some other subset of the data structure, such as the first two state trees).

[0382] Therefore, as Figure 8 As shown, when executing a transaction, the ledger transaction system 106 overwrites the state tree 804 to generate the state tree 820. Although Figure 8 State tree 804 and state tree 820 are shown as separate tree structures, but this is only for illustrative purposes to show the changes made to the state tree stored at verifier node device 802.

[0383] Specifically, the ledger transaction system 106 overwrites state tree 804 (and generates state tree 820) by updating the node values ​​modified by the transactions stored in state tree 804. For example... Figure 8 As shown, the execution of the transaction modifies the user account D corresponding to the account state representation stored at leaf node 806d. In response, the ledger transaction system 106 overwrites the state tree 804 by updating the account state representation corresponding to user account D stored at leaf node 806d (now shown as user account D' under state tree 820). The ledger transaction system 106 further updates the node values ​​stored at the nodes from which leaf node 806d originates (i.e., internal node 810 and root node 808). Thus, the ledger transaction system 106 can store a state tree updated with each transaction (or transaction block) at validator node device 802 to reflect the latest state of the distributed digital ledger transaction network.

[0384] In some embodiments, the ledger transaction system 106 can generate state data structure components that reflect changes to previous versions of the state data structure, rather than overwriting the state data structure. In this way, the ledger transaction system 106 can store multiple versions of the state data structure instead of storing the entire state data structure. For example, as... Figure 8 As further shown, the ledger transaction system 106 manages the state tree 832 at the full node device 830. In fact, as... Figure 8 As shown, the ledger transaction system 106 merges two trees in a way that preserves the data representation in different states, rather than storing two full-state trees or overwriting the previous state tree with the subsequent tree.

[0385] For example, in one or more embodiments, the ledger transaction system 106 determines that the full node device 830 will service queries for information. Therefore, the ledger transaction system 106 determines that the full node device 830 will store data corresponding to each state of the distributed digital ledger transaction network within a state data structure.

[0386] like Figure 8 As shown, the ledger transaction system 106 generates a state tree component 834 with node values ​​corresponding to the state of the user account modified by the transaction. In fact, as... Figure 8 As shown, the transaction modifies the user account D corresponding to the account state representation stored at leaf node 836d. In response, the ledger transaction system 106 generates state tree component 834 by generating a node to store the updated node value.

[0387] In particular, such as Figure 8 As shown, the ledger transaction system 106 generates a state tree component 834 by generating leaf nodes 836e and storing in them a modified account state representation of user account D (shown as user account D'). As shown, the ledger transaction system 106 further generates internal nodes 838 and a root node 840. The ledger transaction system 106 stores updated node values ​​in internal nodes 838 (modified from the node values ​​stored at internal node 842 in the previous state) and stores updated node values ​​in root node 840 (modified from the node values ​​stored at root node 844 in the previous state tree). Therefore, the ledger transaction system 106 utilizes the state tree component 834 to store the node values ​​of the state tree 832 that have changed as a result of executing transactions.

[0388] like Figure 8 As shown, the ledger transaction system 106 further associates the nodes of the state tree component 834 with the nodes of the state tree 832 that have not been modified by transactions. Specifically, the internal node 838 of the state tree component 834 points to the leaf node 836c of the state tree 832 (i.e., is associated with the leaf node 836c of the state tree 832). Therefore, the ledger transaction system 106 generates the node value of the internal node 838 of the state tree component 834 based on the unmodified node value stored at leaf node 836c and the modified node value stored at leaf node 836e. Similarly, the root node 840 of the state tree component 834 points to the internal node 846 of the state tree 832. Therefore, the ledger transaction system 106 generates the root value of the root node 840 of the state tree component 834 based on the unmodified node value stored at internal node 846 and the modified node value stored at internal node 838. Figure 8As shown, the unmodified node value stored at internal node 846 is based on the unmodified node values ​​stored at leaf nodes 836a-836b. Therefore, the ledger transaction system 106 tracks the modified and unmodified node values ​​resulting from the execution of transactions without completely replicating the state tree 832.

[0389] In one or more embodiments, the ledger transaction system 106 may utilize a state tree component to store multiple states, and then delete nodes within the state tree to reduce the amount of data stored at the computer nodes. For example, a computer node may decide to shift from storing multiple data structures reflecting multiple states to storing a state data structure reflecting fewer states. Figure 9 A ledger transaction system 106 is shown, according to one or more embodiments, in which a portion of the state tree is deleted when there is a state tree component that reflects multiple different state trees.

[0390] like Figure 9 As shown, the ledger transaction system 106 manages the state tree 904 stored at the full node device 902. Specifically, as... Figure 9 As shown, the ledger transaction system 106 generates a state tree 904 corresponding to the first state (labeled "S0") and a state tree component 906 corresponding to the second state (labeled "S1"). According to the above... Figure 8 The discussion includes a state tree component 906 that includes node values ​​corresponding to user account states that have changed between a first state and a second state. Additionally, the state tree component 906 points to nodes in the state tree 904 that correspond to unchanged user account states.

[0391] like Figure 9 As shown, the ledger transaction system 106 tracks the relationship between a specific node and its latest parent node. In fact, although... Figure 9 Solid lines in the diagram represent parent-child relationships, while dashed lines represent parent-child relationships between a specific node and its most recently associated parent node. For example, ledger transaction system 106 associates leaf node 908a corresponding to an unmodified user account A with root node 912 of state tree component 906. Ledger transaction system 106 further associates leaf node 908b corresponding to an expired user account B with root node 910 of state tree 904, and leaf node 908c corresponding to an updated user account B' with root node 912 of state tree component 906. In one or more embodiments, ledger transaction system 106 tracks the currently associated parent node of a child node by appending a representation of the parent node (e.g., an identifier or reference pointer) to the node value stored at the child node.

[0392] like Figure 9As shown, ledger transaction system 106 can delete nodes (or subtrees) within state tree 904 based on parent-child relationships reflected in state tree component 906. For example, ledger transaction system 106 can determine that full node device 902 is about to run out of storage space. In response, ledger transaction system 106 can clear older data from full node device 902 and free up storage space for newer data (e.g., delete previous states so that the state data structure only reflects the current state).

[0393] like Figure 9 As shown, the ledger transaction system 106 deletes all outdated nodes (i.e., nodes with node values ​​that do not correspond to the current state of the distributed digital ledger transaction network). Specifically, the ledger transaction system 106 identifies which nodes have outdated node values ​​by recognizing nodes that do not have a parent node corresponding to the current state of the distributed digital ledger transaction network. For illustration, to remove data from the full node device 902 that corresponds to the first state but not the second state, the ledger transaction system 106 starts from the root node 910 of the state tree 904. The ledger transaction system 106 checks the two child nodes of the root node 910. As... Figure 9 As shown, because leaf node 908a is associated with root node 912 corresponding to the second state, the ledger transaction system maintains leaf node 908a. However, because leaf node 908b was recently associated with root node 910, the ledger transaction system 106 deletes leaf node 908b. Figure 9 As shown, since the root node 910 of the state tree 904 corresponds only to the first state, the ledger transaction system 106 deletes the root node 910.

[0394] In one or more embodiments, the ledger transaction system 106 stores the total number of associated parent nodes at each node (e.g., by appending the total number of parent nodes to the node value stored at the node). The ledger transaction system 106 can then delete nodes based on the total number of parent nodes. For example, the ledger transaction system 106 can identify nodes with a total number of parent nodes indicating that the node does not correspond to the current state of the distributed digital ledger transaction network. For illustration, a node from a state tree corresponding to a first state is associated with only one parent node (i.e., the root node of the state tree). Therefore, the ledger transaction system 106 can delete that node.

[0395] As mentioned, in one or more embodiments, the ledger transaction system 106 may delete all nodes with outdated node values. However, in some embodiments, the ledger transaction system 106 deletes all nodes with outdated node values ​​corresponding to states earlier than a specified state. In other words, the ledger transaction system 106 may (e.g., via input from a user from the full node device 902 or via input from an authorized device) identify a specified state and delete all nodes corresponding to states prior to the specified state. In this way, the full node device 902 can maintain data corresponding to a desired subset of states of the distributed digital ledger transaction network.

[0396] In one or more embodiments, the ledger transaction system 106 can delete, merge, and store various different data structures to efficiently manage storage at computer nodes. For example, in one or more embodiments, the ledger transaction system 106 uploads data corresponding to the latest state (or some other specified state) to another storage device, and then stores all data corresponding to subsequent states to that storage device. In some embodiments, the ledger transaction system 106 decides to maintain a snapshot of the history of the state of the distributed digital ledger transaction network. For example, the ledger transaction system 106 may decide to maintain data corresponding to one state out of every thousand states or data corresponding to one state from each week. The ledger transaction system 106 can then delete data that does not correspond to those states. Therefore, the ledger transaction system 106 can identify the implementing computer nodes as nodes that can only serve queries for information about at least one maintained state.

[0397] although Figures 7-9 A specific storage implementation for a computer node with a particular category or role is described, but the ledger transaction system 106 can apply various storage configurations to various computer nodes (e.g., validator nodes and / or full nodes). In some embodiments, the ledger transaction system 106 implements specific storage configurations based on preferences at each individual computing device (e.g., based on interaction with user interface elements used to set storage preferences) and / or based on the resources available to that computer node (e.g., memory). Furthermore, although... Figures 7-9 Examples of transaction data structures and state data structures are provided, but the ledger transaction system 106 can similarly manage the storage of various other data structure types, such as event data structures.

[0398] As mentioned, in one or more embodiments, the storage deletion rule set and the storage merge rule set are configurable. Specifically, the ledger transaction system 106 can modify the deletion and merge rules based on the needs of changes in the distributed digital ledger transaction network or based on the needs or preferences of changes in individual computer nodes. In some embodiments, the ledger transaction system 106 configures the storage deletion rule set and / or the storage merge rule set based on input received from users of node devices or from authorized devices. In some embodiments, the ledger transaction system 106 modifies the storage deletion and / or storage merge rules based on consensus (e.g., the process of smart contracts executed across the distributed digital ledger transaction network).

[0399] By implementing a storage deletion rule set and / or a storage merge rule set, the ledger transaction system 106 operates more efficiently than traditional systems. In particular, the ledger transaction system 106 reduces the need for storage devices placed on computer nodes in a distributed digital ledger transaction network. In effect, the ledger transaction system 106 reduces the computing resources utilized by computer nodes while still allowing them to maintain the data corresponding to the digital ledger.

[0400] Furthermore, the ledger transaction system 106 is more flexible than traditional systems. For example, by managing storage based on the classification or role of computer nodes, the ledger transaction system 106 flexibly narrows storage usage to the needs of specific nodes (e.g., providing services for queries or participating in consensus). Moreover, by allowing configurable storage methods, the ledger transaction system 106 can flexibly modify or update storage management to adapt to the changing needs of the distributed digital ledger transaction network.

[0401] C. Account Eradication

[0402] Many traditional blockchain systems store user account data in storage devices managed by the traditional system (e.g., a separate database managed by each computer node participating in the system). As more users create accounts associated with the traditional system, the need for storage increases, exhausting storage resources on individual computing devices. To avoid these problems, many traditional systems remove unwanted (e.g., old) account data from their storage structures. For example, a traditional blockchain system might limit the time account data allocated to a specific user. When the allocated time expires, the traditional system can delete or overwrite the account data in the storage structure, allowing for the reuse of storage resources.

[0403] However, as mentioned above, despite these advancements, traditional blockchain systems still suffer from technical flaws that lead to inflexible and inefficient operation. For example, traditional blockchain systems are often inflexible because they strictly require all participating computer nodes to synchronously delete account data associated with expired user accounts. To illustrate, many traditional blockchain systems delete account data associated with expired user accounts by broadcasting (e.g., originating from the computer nodes) a transaction that triggers the deletion to all computer nodes storing the account data. Thus, a given computer node typically must wait for such a transaction before deleting the account data.

[0404] Besides flexibility concerns, traditional blockchain systems are also inefficient. Specifically, because traditional systems often rely on transactions to trigger the deletion of account data associated with expired user accounts, the computer nodes storing the account data may maintain the data in their databases for longer than necessary. In particular, as mentioned, even after having the computational resources available to find and delete the data (e.g., to handle downtime), computer nodes may still be maintaining account data while waiting for the transaction to trigger deletion. Therefore, traditional systems often utilize significant computational resources (e.g., memory) to accommodate expired user accounts. Furthermore, to delete an account, traditional systems typically broadcast a separate transaction to trigger the deletion of account data, further utilizing computational resources across the distributed digital ledger transaction network in the process of executing the transaction and reaching consensus on it.

[0405] One or more embodiments of the ledger transaction system 106 utilize flexible account eviction to more effectively manage the storage resources of computer nodes within a distributed digital ledger transaction network. Specifically, as mentioned above, the ledger transaction system 106 can generate a state data structure that stores account data corresponding to user accounts and an account state representation of that data. The ledger transaction system 106 can allow lazy deletion of account data across computing devices within the distributed digital ledger transaction network (e.g., marking items as expired or ready for deletion without imposing a requirement to delete the data). For example, the ledger transaction system 106 can store an eviction date associated with each user account. Based on the eviction date, the ledger transaction system can determine the expiration date of a user account and subsequently, for each computing device, delete the account data from the state data structure at a flexible time (e.g., when computing resources become available for that device). In this way, the ledger transaction system 106 enables each computer node in the distributed digital ledger transaction network to flexibly and efficiently delete expired account data.

[0406] As mentioned above, the ledger transaction system 106 can generate a state data structure that stores account data and account status representations corresponding to user accounts in a distributed digital ledger transaction network. Figure 10 A state data structure 1000 for performing account eviction, generated by a ledger transaction system 106 according to one or more embodiments, is shown.

[0407] As mentioned above and as Figure 10 As shown, the state data structure 1000 includes a state database 1002 and a state tree 1004. Specifically, the ledger transaction system 106 generates account data 1006 corresponding to user accounts in the distributed digital ledger transaction network within the state database 1002. Furthermore, the ledger transaction system 106 generates account state representations 1008 corresponding to user accounts within the state tree 1004 (i.e., as part of the leaf nodes of the state tree 1004).

[0408] As described above, in one or more embodiments, the account status representation 1008 includes a hash value 1010 corresponding to the account data 1006 (i.e., the hash of the account value 1016). However, in some embodiments, the account status representation 1008 includes additional data. For example, such as Figure 10 As shown, the account status representation 1008 also includes a key hash value 1012 (e.g., an authentication key corresponding to a user account). In one or more embodiments, the ledger transaction system 106 generates the key hash value 1012 by generating the authentication key (e.g., setting the key hash value 1012 to correspond to the user account's authentication key). n (A bit address key, or applying a hash function to a public key associated with a user account).

[0409] like Figure 10 As shown, the account status representation 1008 may also include an eviction date 1014 associated with the user account. The ledger transaction system 106 may generate the eviction date 1014 based on one or more factors that determine how long a user account should remain active within the distributed digital ledger transaction network. For example, the ledger transaction system 106 may generate the eviction date 1014 based on one or more fees (e.g., rent) paid by the user account, which may include fees for creating the user account and / or fees paid for executing transactions sent by the user account on the distributed digital ledger transaction network.

[0410] In one or more embodiments, the ledger transaction system 106 may update (i.e., modify) the eviction date 1014 associated with a user account. For example, the ledger transaction system 106 may update the eviction date 1014 to extend the user account's active status after detecting activity corresponding to the user account (e.g., after executing a transaction submitted by the user account on the distributed digital ledger transaction network). Additionally, as will be explained in more detail below, the ledger transaction system 106 may update the eviction date 1014 when recaching the account data 1006 associated with the user account. In one or more embodiments, the ledger transaction system 106 sets the eviction date 1014 based on the time of the last user account access (e.g., the time of the user account's last activity on the distributed digital ledger transaction network) and a threshold that includes a predetermined minimum length of time the user account can remain active before its expiration. Similarly, the ledger transaction system 106 may set or update the eviction date based on the leased storage amount, the time of a transaction transferring digital assets from the user account, or the time of a transaction transferring digital assets to the user account.

[0411] When the ledger transaction system 106 decides to delete account data 1006 (e.g., when sufficient computing resources become available), the ledger transaction system can access the account status representation 1008 to determine (or confirm) the expiration date 1014 (i.e., the user account). In response to determining the expiration date 1014, the ledger transaction system 106 can delete account data 1006 (e.g., account value 1016 and corresponding hash 1018) from the status database 1002. However, as Figure 10 As shown, the ledger transaction system 106 can still maintain the account state representation 1008 within the state tree 1004, which allows the ledger transaction system 106 to re-cache the account data 1006 (e.g., when appropriate conditions are met, as discussed below).

[0412] Notably, in one or more embodiments, the ledger transaction system 106 initiates the deletion of account data associated with a given user account without submitting a transaction event request for deleting the account data on the distributed digital ledger transaction network. More precisely, as mentioned, the ledger transaction system 106 can initiate the deletion of account data at any time after the user account expires (e.g., based on the preferences, settings, or capabilities of individual computing devices).

[0413] Ledger transaction system 106 can determine when to clear account data based on various factors. In one or more embodiments, ledger transaction system 106 performs periodic scans to identify expired user accounts and then deletes the corresponding account data (and other associated data) from state database 1002. Ledger transaction system 106 can optimize the frequency of this periodic scan to more effectively manage computing resources available at any given time. In some embodiments, ledger transaction system 106 optimizes the periodic scan independently for each computer node (e.g., a validator node device or a full node device) of the distributed digital ledger transaction network. Specifically, for a given computer node, ledger transaction system 106 can identify the computing resources of the computer node, determine the availability of those computing resources, and then determine how to optimize the frequency of scans used to identify expired user accounts.

[0414] In some embodiments, the ledger transaction system 106 provides selectable options for setting conditions for clearing account data. For example, the ledger transaction system 106 may provide a user interface for selecting the time, frequency, or trigger for removing account data. In other embodiments, the ledger transaction system 106 automatically clears account data based on a predefined schedule or trigger (e.g., based on the current processing power utilized by the computing device falling below a threshold level).

[0415] By deleting account data corresponding to expired user accounts without requiring transaction event requests, ledger transaction system 106 offers greater flexibility in managing expired user accounts compared to traditional systems. Specifically, ledger transaction system 106 can flexibly delete account data based on individual user preferences and / or the availability of computing resources. Furthermore, by optimizing account data deletion independently for each computer node within the distributed digital ledger transaction network, ledger transaction system 106 can extend its flexibility to accommodate the computing resources available to each individual computer node.

[0416] Furthermore, the ledger transaction system 106 operates more efficiently than traditional systems. First, the ledger transaction system 106 avoids wasting computing resources across the distributed digital ledger transaction network by transmitting, analyzing, and executing individual transactions to remove outdated content. In fact, each individual device can remove content without having to execute additional transactions and reach consensus on them. Moreover, by allowing individual computing devices to remove account data during their idle time, the ledger transaction system 106 can efficiently identify and delete account data based on the available computing resources on each individual device. Therefore, the ledger transaction system 106 avoids overwhelming the computing resources of individual devices.

[0417] In some cases, allowing individual computer nodes the flexibility to delete account data can potentially lead to inconsistencies across computer nodes. For example, a request for information from a user account by a client device may produce different responses depending on whether a particular node has already deleted the specific account data. In one or more embodiments, the ledger transaction system 106 provides flexibility while maintaining consistency by restricting access to accounts across the distributed digital ledger transaction network (e.g., even when account data has not yet been deleted from a particular device).

[0418] For example, in one or more embodiments, the ledger transaction system 106 rejects requests (e.g., transactions, queries, etc.) associated with a user account received after the user account has expired and before the account data 1006 has been deleted. Specifically, in some embodiments, upon receiving a request associated with an expired user account, the ledger transaction system 106 may access the account status representation 1008 corresponding to the user account and determine that the eviction date 1014 (i.e., the user account) has expired. The ledger transaction system 106 may then continue processing transactions as if the account had expired. For example, the ledger transaction system 106 may respond to the request by sending an indication that the user account has expired (e.g., to the client device that submitted the request). In other words, even while maintaining the account data 1006 within the state database 1002, if the user account (i.e., the eviction date 1014) has expired, the ledger transaction system 106 may refuse access to the account data 1006 (i.e., refuse access to the user account itself). In this way, the ledger transaction system 106 can give each computer node the flexibility to delete account data (without initiating a separate transaction) while still ensuring consistent behavior (e.g., response to queries) across the entire distributed digital ledger transaction network.

[0419] As mentioned above, in one or more embodiments, the ledger transaction system 106 can re-cache account data that has previously been deleted from the state database. In particular, the ledger transaction system 106 can use transactions to accurately re-cache account data. Figure 11 A block diagram is shown of a ledger transaction system 106 recaching account data corresponding to user accounts according to one or more embodiments.

[0420] like Figure 11 As shown, the ledger transaction system 106 can identify an account recovery request associated with an expired user account within transaction 1102. The account recovery request may include the account address 1104 associated with the expired user account and the proposed account data 1106. Specifically, as... Figure 11 As shown, the proposed account data 1106 may include the proposed account value associated with the expired user account.

[0421] Subsequently, the ledger transaction system 106 can compare the proposed account data 1106 with the account state representation of the user account stored in the state tree. For example, in one or more embodiments, the ledger transaction system 106 performs the action 1108 of generating a hash of the proposed account value. In particular, the ledger transaction system 106 can perform action 1108 by applying a hash function to the proposed account value of the proposed account data 1106.

[0422] like Figure 11 As shown, the ledger transaction system 106 can then perform action 1110 by determining the hash value at the account address based on the state tree. For example, the ledger transaction system 106 can traverse the state tree using the account address 1104 from the account recovery request and find the leaf node associated with the user account. The ledger transaction system 106 can then access the account state representation stored within the leaf node and identify the hash value (i.e., the hash value previously generated by applying a hash function to the account data corresponding to the user account).

[0423] As shown, the ledger transaction system 106 can also perform action 1112 of comparing the proposed account value hash with the hash value at the account address. Specifically, in one or more embodiments, the ledger transaction system 106 determines whether the proposed account value hash is equal to the hash value at the account address. This comparison allows the ledger transaction system 106 to verify or confirm the accuracy of the proposed account data 1106. In practice, if the proposed account value hash matches the hash value at the account address, the proposed account data 1106 matches the data deleted from the account. However, if the proposed account value hash does not match the hash value at the account address, the proposed account data 1106 does not match the data deleted from the account (e.g., the data has been modified or otherwise corrupted).

[0424] like Figure 11As shown, ledger transaction system 106 can perform action 1114 to re-cache the proposed account data based on this comparison. For example, in one or more embodiments, if the hash of the proposed account value is not equal to the hash value at the account address, ledger transaction system 106 rejects the account recovery request (and may reject transaction 1102 entirely). However, if the hash of the proposed account value is indeed equal to the hash value at the account address, ledger transaction system 106 can re-cache the proposed account data in the state database. Specifically, in one or more embodiments, ledger transaction system 106 generates an entry for the proposed account data 1106 in the state database. As mentioned, in some embodiments, based on re-caching the proposed account data 1106, ledger transaction system 106 can update the eviction date associated with the recovered user account. For example, ledger transaction system 106 can update the eviction date when executing transaction 1102, which includes the account recovery request.

[0425] By maintaining account state representations associated with user accounts within the leaf nodes of the state tree, the ledger transaction system 106 manages storage resources more flexibly and efficiently than traditional systems, even after deleting account data corresponding to a user account. Specifically, the ledger transaction system can flexibly delete and recover account data associated with user accounts while maintaining the accuracy and security of the digital ledger.

[0426] D. Tracking multiple writes in memory

[0427] As mentioned above, traditional blockchain systems can receive transaction blocks and (after consensus) execute the transactions within those blocks. In fact, through consensus protocols, such traditional systems can identify which transaction blocks have been agreed upon by other computer nodes in the network. Therefore, traditional systems can add transactions to the digital ledger based on which transaction blocks have reached consensus within the network.

[0428] However, as mentioned above, traditional blockchain systems are often inflexible and inaccurate in determining the order in which transactions (or blocks) are added to the digital ledger. For example, many traditional blockchain systems are often inflexible because they rigidly add blocks to the digital ledger in the order they are received. However, this can cause problems—especially for traditional systems implementing leader-based consensus protocols—where multiple blocks are received at the same time or around the same time (e.g., due to communication delays), or where a new block is received before a previous block is committed to storage. For example, in the case where a new block is received before a previous block is committed to storage, a traditional system might execute the new block based on the previous block and then determine that the previous block has been rejected by the network. This could require the traditional system to generate conflicting ledgers and result in wasted computational resources in correcting inaccurate blocks committed to storage.

[0429] Besides concerns about flexibility, traditional blockchain systems may also operate inaccurately. In particular, many traditional blockchain systems may not accurately represent the digital ledger due to their inability to flexibly accommodate various issues surrounding the order in which transactions are added to the ledger. For example, a computer node participating in the network may add transactions to the digital ledger in a different order than another node in the network. Therefore, the two computer nodes may disagree on the current state of the digital ledger, and at least one of these computer nodes may not accurately represent that current state.

[0430] One or more embodiments of the ledger transaction system 106 utilize a note-based data structure to flexibly track multiple possible changes to the digital ledger while awaiting consensus on one or more transaction blocks. Specifically, the ledger transaction system 106 may utilize the note-based data structure as a temporary storage location for storing possible (e.g., speculative) execution branches. For example, the ledger transaction system 106 may identify multiple transaction blocks containing different transactions. In one or more embodiments, the multiple transaction blocks include conflicting transactions (e.g., at least two of the transaction blocks include transactions to withdraw digital assets from a user account, and the user account does not contain enough digital assets to satisfy both transactions). The ledger transaction system 106 may execute each transaction block and store the results of the execution in the note-based data structure. Specifically, the ledger transaction system 106 may store how the execution of that transaction block modifies the current state of the distributed digital ledger transaction network (i.e., the final state submitted to permanent storage via consensus) for each transaction block, regardless of how the execution of other transaction blocks modifies that state. The ledger transaction system 106 can then submit transaction blocks to permanent storage (or reject transaction blocks outright) based on the consensus outcome. In this way, the ledger transaction system 106 can flexibly track possible consensus outcomes in a way that leads to a more accurate representation of the digital ledger.

[0431] As mentioned above, the ledger transaction system 106 can utilize a note-based data structure to track how the execution of transaction blocks modifies the latest committed state of the distributed digital ledger transaction network. In fact, the ledger transaction system 106 can combine the note-based data structure with a state data structure to track various execution branches. Figure 12 A state tree 1200 from a state data structure is shown according to one or more embodiments, the state tree 1200 representing the latest committed state of a distributed digital ledger transaction network.

[0432] like Figure 12 As shown, state tree 1200 includes similar features to those described above. Figure 3The discussed state tree 306 is a binary tree (e.g., a state Merkle tree). Specifically, state tree 1200 includes leaf nodes 1202a-1202p. Leaf nodes 1202a-1202p correspond to different user accounts in the distributed digital ledger transaction network and store account state representations corresponding to these user accounts. Furthermore, state tree 1200 includes internal nodes 1204a-1204n with node values ​​determined based on the node values ​​of each associated child node. Additionally, state tree 1200 includes a root node with a root value based on the node values ​​of all other nodes within state tree 1200. This root value represents the latest committed state (labeled "S0") of the distributed digital ledger transaction network. The nodes of state tree 1200 are... Figure 12 The text is indexed to simplify the discussion presented below.

[0433] Figure 13 A block diagram is shown illustrating transaction blocks identified by ledger transaction system 106 according to one or more embodiments. Specifically, transaction block 1302 represents the most recently executed and committed transaction block reflected in the state representation and / or transaction representation on the distributed digital ledger transaction network. In practice, Figure 12 State tree 1200 corresponds to the state of the distributed digital ledger transaction network after transaction block 1302 is submitted to the storage device. For example... Figure 13 As shown, after committing transaction block 1302 (within state tree 1200), ledger transaction system 106 identifies additional transaction blocks for modifying the committed transaction block 1302 reflected in the digital ledger.

[0434] Specifically, Figure 13 The ledger transaction system 106 is shown identifying transaction block 1304, which comprises two transactions. As shown, the first transaction 1306 modifies the leaf node corresponding to index "4" in state tree 1200 (i.e., Figure 12 The account of leaf node 1202c). The second transaction 1308 modifies the leaf node corresponding to index "18" in state tree 1200 (i.e., Figure 12 The account of leaf node 1202j. For example... Figure 13 As shown, the ledger transaction system 106 adds transaction block 1304 to the digital ledger after transaction block 1302. In other words, the ledger transaction system 106 modifies the state of the distributed digital ledger transaction network generated by submitting transaction block 1302 based on transaction block 1304.

[0435] like Figure 13As shown, the ledger transaction system 106 also identifies transaction blocks 1310 and 1314. Transaction block 1310 includes a first variant 1312 of a third transaction, whose modification corresponds to the leaf node at index "8" in the state tree 1200 (i.e., Figure 12 The account of leaf node 1202e). Transaction block 1314 includes a second variant 1316 of the third transaction, which modifies the leaf node corresponding to index "30" in state tree 1200 (i.e., Figure 12 The account of leaf node 1202p). Therefore, as... Figure 13 As shown, the ledger transaction system 106 identifies two possible transaction blocks (i.e., two possible execution branches) that can be submitted to the storage device after the direct submission of transaction block 1304.

[0436] Figures 14A-14B This illustrates the use of note-style data structures to track execution according to one or more embodiments. Figure 13 The ledger transaction system 106 shows the various possible outcomes of transaction blocks 1304, 1310, and 1314. Specifically, Figure 14A This demonstrates how to use a note-style data structure to track execution. Figure 13 The transaction results of block 1304 are in the ledger transaction system 106. Figure 14B This demonstrates the use of a note-style data structure to track data from execution. Figure 13 The ledger transaction system 106 represents the possible outcomes of transaction block 1310 or transaction block 1314.

[0437] like Figure 14A As shown, the ledger transaction system 106 generates state tree component 1402 and state tree component 1404. Specifically, state tree component 1402 represents the state tree generated by… Figure 13 The state of the distributed digital ledger transaction network generated by the first transaction 1306 in transaction block 1304 (marked as "S1"). Similarly, state tree component 1404 represents the state of the distributed digital ledger transaction network generated by the first transaction 1306 in transaction block 1304. Figure 13 The state of the distributed digital ledger transaction network generated by the second transaction 1308 in transaction block 1304 (marked as "S2"). As shown, the root node 1408 of state tree component 1404 points to the internal node 1410 of state tree component 1402, indicating that internal node 1410 has a node value that remains unchanged between the execution of the first transaction 1306 and the second transaction 1308 (as referenced above). Figure 8 (For a more detailed explanation).

[0438] like Figure 14AAs shown, state tree components 1402 and 1404 only include those nodes needed to determine the root values ​​of root nodes 1406 and 1408, respectively. In other words, the ledger transaction system 106 does not replicate the state tree corresponding to the most recently committed state within the note-style data structure (e.g., Figure 12 The state tree 1200). More precisely, the ledger transaction system 106 only generates nodes associated with changes in node values ​​(i.e., nodes with changed node values, or nodes whose node values ​​are used to determine the changed node values).

[0439] For illustration, state tree component 1402 includes leaf node 1412a corresponding to the user account modified by the first transaction 1306. State tree component 1402 also includes leaf node 1412b. Although the user account corresponding to leaf node 1412b remains unchanged from the first transaction 1306, ledger transaction system 106 uses the node value of leaf node 1412b to determine the node value of internal node 1414, which is further used to determine the root value of root node 1406. In one or more embodiments, ledger transaction system 106 generates the entire state tree corresponding to the state generated by the transaction within a note-like data structure, rather than generating a state tree component. In one or more embodiments, because the first transaction 1306 and the second transaction 1308 indicate the user accounts modified by those transactions, ledger transaction system 106 can preload the account states corresponding to those user accounts before initiating execution using a virtual machine. In fact, in one or more embodiments, the ledger transaction system 106 preloads account states from storage to the virtual machine in parallel, improving execution time because the virtual machine does not need to wait for account states to execute.

[0440] like Figure 14B As shown, the ledger transaction system 106 also generates state tree component 1420 and state tree component 1422. Specifically, state tree component 1420 represents the state tree generated by the transaction in... Figure 13 The state of the distributed digital ledger transaction network (labeled "S3") resulting from the first variant 1312 of the third transaction included in transaction block 1310. Similarly, state tree component 1422 represents the state of the distributed digital ledger transaction network resulting from the first variant 1312 of the third transaction included in transaction block 1310. Figure 13 The state of the distributed digital ledger transaction network (marked "S3") generated by the second variant 1316 of the third transaction included in transaction block 1314. (Similar to...) Figure 14A Similarly, in Figure 14B The dashed lines shown indicate nodes in the state tree that point to previous state tree components, indicating that the node value remains unchanged since the execution of the corresponding transaction.

[0441] In fact, such as Figure 14BAs shown, state tree components 1420 and 1422 provide alternative states that can represent the state of the distributed digital ledger transaction network, following the state generated by submitting transaction block 1304 to the storage device. In practice, ledger transaction system 106 can (i.e., after recognizing an indication that consensus has been reached on transaction block 1304) identify an indication that consensus has been reached on one of transaction blocks 1310 and 1314. Therefore, ledger transaction system 106 can submit the transaction block to the storage device based on the execution results tracked within the note-like data structure. For example, upon reaching consensus on one of transaction blocks 1310 and 1314, ledger transaction system 106 can generate a vector of transaction values ​​corresponding to the agreed-upon transaction block based on the state tree components stored in the note-like data structure. Ledger transaction system 106 can then use the vector of transaction values ​​to submit the execution results to the storage device by accordingly modifying or updating the state data structure, event data structure, and transaction data structure.

[0442] When a transaction block is committed to the storage device, the ledger transaction system 106 may deallocate the corresponding state tree (e.g., remove it from the note-like data structure). The ledger transaction system 106 may further deallocate any remaining nodes in the note-like data structure that do not have an associated parent node. In one or more embodiments, if one or both of transaction blocks 1310 and 1314 fail to reach consensus, the ledger transaction system 106 may remove the corresponding state tree component from the note-like data structure. In one or more embodiments, the ledger transaction system 106 completely clears the note-like data structure whenever a transaction block is committed to the storage device.

[0443] By using a note-based data structure to track various possible execution branches, the ledger transaction system 106 is more flexible than traditional systems in adapting to the receipt of multiple transaction blocks. Specifically, the ledger transaction system 106 can flexibly execute transaction blocks and then temporarily store the execution results until consensus fails or is reached for at least one block. Furthermore, by temporarily storing execution results, the ledger transaction system 106 can flexibly adapt to the delay between executing transaction blocks and achieving consensus. In fact, by utilizing the note-based data structure, the ledger transaction system 106 can continue executing transaction blocks based on the execution results of a given transaction block awaiting submission to the storage device.

[0444] Furthermore, the ledger transaction system 106 operates more accurately than traditional systems. In fact, due to the flexibility provided by the note-based data structure, the ledger transaction system 106 can represent the digital ledger more accurately. Specifically, because the ledger transaction system 106 can use the note-based data structure to temporarily store the execution results of transaction blocks, it can postpone submitting the execution results to the storage device until consensus on these results is reached. Therefore, the ledger transaction system 106 ensures that computer nodes in the distributed digital ledger transaction network submit transaction blocks in the same order.

[0445] E. Proof and Verification

[0446] As mentioned above, in one or more embodiments, the computer node (e.g., a full node device) responding to a query for information can transmit proof along with the requested information to the requesting client device. In fact, in one or more embodiments, the distributed digital ledger transaction network represents an unreliable system where the client device does not trust the computer nodes from which it receives data. Therefore, the ledger transaction system 106 can provide proof from the computer node as evidence of the accuracy of the data.

[0447] For example, ledger transaction system 106 can provide proof of a signed transaction at a specified version of the transaction data structure. Furthermore, ledger transaction system 106 can use a state data structure to provide proof of the state of a user account at a specific state of the distributed digital ledger transaction network. In another embodiment, ledger transaction system 106 can use an event data structure to provide proof of a specific transaction event emitted as part of the execution of a specific transaction. As discussed above, the transaction data structure, state data structure, and event data structure can each include a tree, such as a Merkle tree. Therefore, in one or more embodiments, the proof provided by ledger transaction system 106 includes a Merkle proof.

[0448] In one or more embodiments, the proof comprises three parts: partial proof, transaction information, and public proof. For the partial proof corresponding to a signed transaction, the ledger transaction system 106 can provide the raw data of the signed transaction. For the partial proof corresponding to a user account state, the ledger transaction system 106 can provide proof from the leaf node to the root node of the state tree corresponding to the user account (including associated intermediate nodes and their sibling nodes) and account data (e.g., account value). For the partial proof corresponding to a transaction event, the ledger transaction system 106 can provide proof from the leaf node to the root node of the corresponding event tree (including associated intermediate nodes and their sibling nodes) and event data (e.g., transaction event details). For the transaction information portion of the proof, the ledger transaction system 106 can provide data stored within the corresponding leaf node of the transaction tree. Furthermore, for the public proof, the ledger transaction system 106 can provide proof from the leaf node to the root node of the transaction tree (including associated intermediate nodes and their sibling nodes).

[0449] Upon receiving proof of the data, the client device (i.e., the ledger transaction system 106 operating at the client device) can, based on the ≥2 signed at the root value of the transaction tree root node, f + 1 verifier node device signature to confirm the root value. For example, ledger transaction system 106 can deserialize data from an applicable data structure. Ledger transaction system 106 can then determine whether the deserialized data matches the expected value. For proofs corresponding to user account states or transaction events, ledger transaction system 106 can then iteratively compute hashes on a list of nodes (i.e., sibling nodes) provided as part of a partial proof to obtain the root value of the corresponding tree. Ledger transaction system 106 can then compare the original data of the signed transaction, the root value of the state tree, or the root value of the event tree (whichever is applicable) with the data stored in the corresponding leaf node of the transaction tree. Ledger transaction system 106 can then iteratively compute hashes on a list of nodes (i.e., sibling nodes) provided as part of a public proof to obtain the root value of the transaction tree. If the determined root value of the transaction tree has at least 2 f If the ledger transaction system 106 receives a signature using the correct set of validator node devices, it can verify the accuracy of the data. However, if these comparisons fail at any step of the verification process, or if the root value of the transaction tree does not have the required signature from the correct set of validator node devices, the ledger transaction system 106 can determine that the proof is invalid.

[0450] III. Addressing and Accounts

[0451] A. Overview

[0452] As mentioned earlier, ledger transaction system 106 uses addresses to specify and identify user accounts on a distributed digital ledger transaction network. For example, ledger transaction system 106 can maintain an authenticated state structure that maps account address keys to account values. Furthermore, ledger transaction system 106 can use addresses (or keys) included in transactions to identify user accounts from which digital assets will be transferred. Ledger transaction system 106 can further use the addresses identified within queries to retrieve appropriate information. Figure 15 A schematic diagram is shown of the address of a user account corresponding to a distributed digital ledger transaction network according to one or more embodiments.

[0453] like Figure 15 As shown, the ledger transaction system 106 can utilize the state tree 1502 to determine the address corresponding to a user account. Specifically, as mentioned above, the leaf nodes of the state tree 1502 can correspond to user accounts in the distributed digital ledger transaction network. Therefore, in one or more embodiments, the address of a user account is at least partially based on the position of the corresponding leaf node within the state tree.

[0454] In some embodiments, the account address is a 256-bit value. To create a new account, the ledger transaction system 106 generates a key pair for the signature scheme. K p , K s ), and use public verification key K p Cryptographic hash as account address a When a transaction sent from an existing account invokes the `create_account(a)` instruction, a new account is created in the ledger state. This is typically done when a transaction attempts to send digital assets to an account address that has not yet been created. a It happens at any time.

[0455] Once in a A new account has been created, and the user can then use the private signing key. K s Sign transactions sent from that account. As outlined below, users can also rotate the key used to sign transactions from an account without changing the account's address.

[0456] like Figure 15 As shown, the address of a user account can include the primary address 1504. Specifically, the primary address 1504 can include the primary public address corresponding to the digital ledger (i.e., the public digital ledger). In effect, the primary address 1504 identifies the user account corresponding to a leaf node on the state tree 1502.

[0457] like Figure 15 As further illustrated, the primary address 1504 can be associated with one or more sub-addresses 1506. Specifically, a sub-address can identify a specific user account in a private digital ledger associated with the user account of the primary address 1504. In other words, in one or more embodiments, user accounts on the public digital ledger (i.e., user accounts associated with the leaf nodes of state tree 1502) manage the private digital ledger. For example, in some embodiments, user accounts on the public digital ledger may include accounts for services, such as a third-party wallet or exchange service that provides services to multiple user accounts specific to that service. The service may maintain an internal database (referred to as a "private digital ledger") that tracks digital assets and transactions associated with user accounts specific to that service. Therefore, a user account associated with the primary address 1504 can utilize sub-addresses to identify a specific user account within the corresponding internal database.

[0458] Therefore, a user account can be associated with a primary address that identifies the user account within the state tree of a distributed digital ledger transaction network. If a user account is associated with a private digital ledger, the user account can include both a primary address and a sub-address, where the primary address provides the address of the account on the public digital ledger (i.e., the account on the private digital ledger), and the sub-address identifies the user account from among multiple user accounts managed by the private digital ledger.

[0459] B. Use encrypted sub-addresses for transaction requests.

[0460] Traditional blockchain systems typically utilize addresses associated with user accounts when generating and executing transactions. Specifically, many traditional systems generate transactions with designated primary and secondary addresses to identify public and private ledger addresses of the associated user accounts, respectively. Therefore, when executing transactions associated with a specific user account, traditional blockchain systems ensure that the correct user account is modified (e.g., digital assets are transferred to / from the correct user account).

[0461] However, traditional blockchain systems have many drawbacks, leading to inflexible and / or insecure operation. For example, traditional blockchain systems generally execute transactions based on addresses associated with user accounts on the network. Therefore, traditional systems are often strict in requiring input including the user account's address in order to generate a request for a transaction via the network. Users attempting to transact using their user accounts may not have access to specific addressing information.

[0462] Furthermore, many traditional blockchain systems may introduce security issues by publishing the addresses of user accounts associated with transactions on the network, allowing external entities to access the network and identify these addresses. For example, even if these sub-addresses are encrypted, traditional systems may publish the same address to the network multiple times (e.g., if the address is associated with multiple transactions), allowing external entities to determine that the same user account has participated in multiple transactions. Traditional systems cannot incorporate privacy measures to resist the tracking and potential manipulation of this information on the network.

[0463] One or more embodiments of the ledger transaction system 106 utilize an encryption key associated with a user account to achieve flexible and secure sub-address encryption when generating a transaction request. For example, the ledger transaction system 106 can generate a request for a transaction pointing to a user account by identifying a primary public address identifier, a sub-address identifier, and an encryption key associated with the user account. The ledger transaction system 106 can then generate a non-deterministic encrypted sub-address unique to the transaction by applying the encryption key to a sub-address with an added random value. Thus, for example, the ledger transaction system 106 can allow a receiving account to receive various different digital assets via a distributed digital ledger transaction network at the same sub-address without publishing duplicate account identifiers on the digital ledger.

[0464] For example, ledger transaction system 106 can execute a transaction that transfers digital assets to the owner of a recipient account corresponding to a master address. The owner of the recipient account can identify that the event and the corresponding transaction have appeared on the digital ledger. The owner of the recipient account can access the encrypted sub-address (e.g., via event details or transaction details stored in an event or transaction data structure). The recipient account can use a private encryption key to decrypt the encrypted sub-address to identify the sub-address corresponding to the transaction. The owner of the recipient account can then attribute the assets to the user (or account) corresponding to the sub-address. Therefore, the owner of the recipient account can identify the user corresponding to the sub-address, but the digital ledger will not include a traceable (or repeatable) reference to the sub-address.

[0465] Furthermore, the ledger transaction system 106 can identify the primary address, sub-address, and / or encryption key from various public sources while still executing secure, anonymous transactions. For example, in one or more embodiments, the ledger transaction system 106 identifies the primary public address identifier, sub-address identifier, and / or encryption key from digital visual codes. Additionally, in some embodiments, the ledger transaction system 106 identifies the primary public address identifier and sub-address identifier from email addresses. In other words, the ledger transaction system 106 can generate a transaction request by receiving an email address associated with a user account. In this way, the ledger transaction system 106 can flexibly and securely generate transaction requests on a distributed digital ledger transaction network using identifiers and encryption keys associated with user accounts.

[0466] As mentioned above, in one or more embodiments, the ledger transaction system 106 uses the primary public address identifier and the secondary address identifier of a user account to generate a request for a transaction on a distributed digital ledger transaction network. Figures 16-18 A ledger transaction system 106, according to one or more embodiments, is illustrated to identify a primary public address identifier and a secondary address identifier for use in transactions. Although Figures 16-18 The ledger transaction system 106 is shown operating on a client device, but the ledger transaction system 106 can similarly function on any device in a distributed digital ledger transaction network.

[0467] Figure 16 A block diagram of a ledger transaction system 106 is shown, which identifies the primary public address identifier and sub-address identifier of a user account (i.e., a payee or recipient account) from digital visual codes according to one or more embodiments. Specifically, Figure 16 The ledger transaction system 106 is shown to identify primary public address identifiers and sub-address identifiers by scanning dynamically generated digital visual codes that encode the primary public address identifiers and sub-address identifiers.

[0468] For example, ledger transaction system 106 can scan the digital visual code 1606 displayed by computing device 1604 at client device 1602. Figure 16 As shown, in one or more embodiments, the digital visual code 1606 includes a quick response (“QR”) code. The ledger transaction system 106 (or a third-party system) may encode the primary public address identifier and sub-address identifiers within the digital visual code 1606. The digital visual code 1606 may include various different types of visual representations capable of encoding data. Furthermore, the computing device 1604 may include various computing devices capable of generating and / or displaying the digital visual code, for example, via the ledger transaction system 106.

[0469] When scanning the digital visual code 1606, the ledger transaction system 106 identifies (e.g., extracts or decodes) the primary public address identifier 1608 and the secondary address identifier 1610 associated with a user account on the distributed digital ledger transaction network. For example... Figure 16 As shown, the primary public address identifier 1608 includes a primary address associated with a user account on the distributed digital ledger transaction network, and the sub-address identifier 1610 includes an encrypted sub-address associated with the user account. In one or more embodiments, the sub-address identifier 1610 includes an unencrypted sub-address associated with the user account.

[0470] By identifying the primary public address identifier 1608 and the sub-address identifier 1610 from the digital visual code 1606, the ledger transaction system 106 can generate a request for a transaction associated with a user account (e.g., a transaction between a user account and another user account). The ledger transaction system 106 can then use the primary public address identifier 1608 and the sub-address identifier 1610 to submit the request for the transaction for execution via a distributed digital ledger transaction network.

[0471] Ledger transaction system 106 can dynamically generate unique digital visual codes for specific transactions (even when transactions involve accounts at the same destination). For example, regarding... Figure 16 As shown, the ledger transaction system 106 can further scan the digital visual code 1614 at the client device 1612. Specifically, the digital visual code 1614 reflects information about the same recipient account, but utilizes a different digital visual code. Specifically, the ledger transaction system 106 (or a third-party system) encodes indicators for the primary address and separate encrypted sub-addresses of the same account within the digital visual code 1614. The client device 1612 may be the same as or different from the client device 1602.

[0472] When scanning the digital visual code 1614, the ledger transaction system 106 can identify the primary public address identifier 1608 and the secondary address identifier 1610 associated with the user account. For example... Figure 16 As shown, while the primary public address identifier 1608 includes the same primary address associated with the user account obtained by scanning the digital visual code 1606, the sub-address identifier 1616 includes a different encrypted sub-address. In fact, both digital visual codes 1606 and 1614 can provide unique encryption for the sub-address associated with the user account. Therefore, by scanning dynamically generated digital visual codes, the ledger transaction system 106 can generate transaction requests using the primary public address identifier associated with the user account and the encrypted sub-address unique to each transaction request.

[0473] Furthermore, by initiating transactions using this method, the digital ledger can avoid duplicate sub-addresses that can be tracked by external entities. In fact, even if multiple transactions on the digital ledger involve the same account, the ledger will reflect two different encrypted sub-addresses, preventing external parties from tracking and manipulating duplicate payments to the same account. Specifically, a transaction executed via the distributed digital ledger transaction network using sub-address identifier 1610 will be untraceable to another transaction executed via the distributed digital ledger transaction network using sub-address identifier 1616 (even if both transactions point to the same account).

[0474] In addition to using dynamically generated digital visual codes that change with each scan, the ledger transaction system 106 can also utilize static digital visual codes when generating a request for a transaction associated with a user account. Furthermore, as mentioned above, the ledger transaction system 106 can utilize an encryption key associated with a user account when generating a request for a transaction associated with that user account. Figure 17 A block diagram of a ledger transaction system 106 is shown, which identifies a primary public address identifier, a sub-address identifier, and an encryption key associated with a user account from digital visual codes, according to one or more embodiments.

[0475] like Figure 17 As shown, the ledger transaction system 106 uses client device 1702 to scan document 1704, which includes a digital visual code 1706. The ledger transaction system 106 generates the digital visual code 1706 by encoding the primary public address identifier, sub-address identifier, and encryption key corresponding to the user account. For example, regarding... Figure 17 Document 1704 reflects billboards seeking public donations of digital assets.

[0476] although Figure 17 Document 1704 is shown as a printed or electronic billboard containing a representation of digital visual code 1706, but document 1704 may include various different physical or electronic documents containing a scannable representation of digital visual code 1706. However, as mentioned above, in one or more embodiments, digital visual code 1706 is static. In other words, digital visual code 1706 remains unchanged on document 1704 (even after being scanned multiple times).

[0477] When scanning the digital visual code 1706, the ledger transaction system 106 can identify (e.g., decode or extract from the digital visual code 1706) the primary public address identifier 1708, the sub-address identifier 1710, and the encryption key 1712 associated with a user account on the distributed digital ledger transaction network. For example... Figure 17As shown, the primary public address identifier 1708 includes a primary address associated with a user account in the ledger transaction system 106, and the sub-address identifier 1710 includes a sub-address associated with the user account. In one or more embodiments, the sub-address identifier 1710 includes a sub-address encrypted for the user account. In one or more embodiments, the encryption key 1712 includes a public key associated with the primary address (i.e., associated with the user account).

[0478] like Figure 17 As shown, after scanning the digital visual code 1706, the ledger transaction system 106 can use the encryption key 1712 to encrypt the sub-address (or encrypted sub-address) 1714. In one or more embodiments, the ledger transaction system 106 adds a random value to the sub-address (or encrypted sub-address) and applies the encryption key 1712 to the sub-address (or encrypted sub-address) with the random value. By adding a random value before applying the encryption key 1712, the ledger transaction system 106 can generate encrypted sub-addresses unique to a specific transaction. In practice, the ledger transaction system 106 can use different random values ​​for subsequent scanning of the digital visual code 1706 (either at client device 1702 or at another client device) to generate different encryptions for the sub-address identifier 1710.

[0479] Therefore, the ledger transaction system 106 can use the primary public address identifier 1708, the sub-address identifier 1710, and the encryption key 1712 to generate a request for a transaction associated with a user account. Specifically, the request for a transaction may include a unique encrypted sub-address for the requested transaction. The ledger transaction system 106 can then submit the request for the transaction for execution via a distributed digital ledger transaction network. Furthermore, by utilizing the encryption key 1712 and a random value, a transaction initiated from the digital visual code 1706 will not duplicate encrypted sub-addresses that can be tracked by entities outside the transaction. Therefore, for recurring payments to the same address that may have the same encrypted sub-address (and can be identified as going to the same place), the ledger transaction system 106 can use a double encryption key (e.g., a re-encryption key).

[0480] As mentioned above, ledger transaction system 106 can also flexibly and securely identify sub-addresses to initiate transactions using a variety of different sources (besides document 1704). Specifically, ledger transaction system 106 can identify addresses to initiate transactions via a distributed digital ledger transac...

Claims

1. A method for lazy deletion of data stored in an authenticated data structure, the method comprising: At computer nodes of a distributed digital ledger transaction network, an authenticated data structure for the distributed digital ledger transaction network is generated, wherein the authenticated data structure includes a data tree, the data tree including nodes with data representations mapped to entries in a database, and wherein the authenticated data structure corresponds to an authenticated data structure maintained in other computer nodes of the plurality of computer nodes; and Lazy deletion of data from the certified data structure is performed at the computer node using the following operations: Accessing data representations from nodes in the data tree to determine the expiration date associated with the node; In response to determining the expiration date and before deleting one or more entries corresponding to the node from the database: At the computer node, a request is received from the client device, the request requesting the use of one or more of the aforementioned entries, and Process the request as if the one or more entries had been deleted; and At the computer node, one or more entries corresponding to the data representation are asynchronously deleted from the database, while the data representation is maintained within the data tree and at least one of the certified data structures maintained by the other computer nodes is maintained, along with the one or more entries.

2. The method of claim 1, further comprising deleting the one or more entries corresponding to the node from the database without any transaction event request for deleting the one or more entries on the distributed digital ledger transaction network.

3. The method according to claim 1, wherein, Processing the request as if the one or more entries had been deleted includes transmitting an indication to the client device that the eviction date has expired.

4. The method according to claim 1, wherein, The database includes a state database, the one or more entries include account data corresponding to a user account, the data tree includes a state tree, and the nodes include an account state representation corresponding to the account data of the user account.

5. The method of claim 4, further comprising responding to receiving a transaction referencing the user account: Access the account status representation corresponding to the user account from the state tree to determine the expiration date; and The transaction is processed as if the user account had expired.

6. The method according to claim 4, further comprising: Identify an account recovery request associated with the user account, wherein the account recovery request includes proposed account data for the user account; and The proposed account data of the user account is verified based on the account state representation within the state tree.

7. The method of claim 6, further comprising re-caching the proposed account data associated with the user account in the state database of the distributed digital ledger transaction network based on the proposed account data used to verify the user account.

8. The method of claim 7, further comprising updating the eviction date associated with the node based on recaching the proposed account data associated with the user account.

9. The method of claim 4, further comprising generating the account status representation by means of the following operations: A hash function is applied to the account data corresponding to the user account in the state database to generate a hash value corresponding to the account data of the user account; and The hash value of the account data is combined with the eviction date associated with the user account to generate the account status representation corresponding to the user account.

10. The method of claim 4, further comprising determining the expiration date based on at least one of the following: the rental storage amount, the time of the last access to the user account, the time of a transaction in which digital assets were transferred from the user account, or the time of a transaction in which digital assets were transferred to the user account.

11. A non-transitory computer-readable medium having instructions stored thereon, the instructions, when executed by at least one processor, causing a computing device to perform the method according to any one of claims 1 to 10 or causing the computing device to perform: At the computer nodes of multiple computer nodes in the distributed digital ledger transaction network, the authenticated data structure of the distributed digital ledger transaction network is generated, wherein, The certified data structure includes a data tree comprising nodes having data representations mapped to entries in a database, and wherein the certified data structure corresponds to a certified data structure maintained in other computer nodes among the plurality of computer nodes; and Lazy deletion of data from the certified data structure is performed at the computer node using the following operations: Accessing data representations from nodes in the data tree to determine the expiration date associated with the node; In response to determining the expiration date and before deleting one or more entries corresponding to the node from the database: At the computer node, a request is received from the client device, the request requesting the use of one or more of the aforementioned entries, and Process the request as if the one or more entries had been deleted; and At the computer node, one or more entries corresponding to the data representation are asynchronously deleted from the database, while the data representation is maintained within the data tree and at least one of the certified data structures maintained by the other computer nodes is maintained, along with the one or more entries.

12. The non-transitory computer-readable medium of claim 11, further comprising instructions that, when executed by the at least one processor, cause the computing device to: delete the one or more entries corresponding to the node from the database, without any transaction event request for deleting the one or more entries on the distributed digital ledger transaction network.

13. The non-transitory computer-readable medium according to claim 11, in, Processing the request as if the one or more entries had been deleted includes transmitting an indication to the client device that the eviction date has expired.

14. The non-transitory computer-readable medium according to claim 11, wherein, The database includes a state database, the one or more entries include account data corresponding to a user account, the data tree includes a state tree, and the nodes include an account state representation corresponding to the account data of the user account.

15. The non-transitory computer-readable medium of claim 14, further comprising instructions that, when executed by the at least one processor, cause the computing device to: Identify the account recovery request associated with the user account, wherein, The account recovery request includes the proposed account data for the user account; as well as The proposed account data of the user account is verified based on the account state representation within the state tree; Based on the proposed account data that verifies the user account, the proposed account data associated with the user account is re-cached in the state database of the distributed digital ledger transaction network; as well as The eviction date associated with the node is updated based on the re-caching of the proposed account data associated with the user account.

16. The non-transitory computer-readable medium of claim 14, further comprising instructions that, when executed by the at least one processor, cause the computing device to generate the account status representation by: A hash function is applied to the account data corresponding to the user account in the state database to generate a hash value corresponding to the account data of the user account; and The hash value of the account data is combined with the eviction date associated with the user account to generate the account status representation corresponding to the user account.

17. A system for lazy deletion of data stored in an authenticated data structure, the system comprising: At least one processor; as well as At least one non-transitory computer-readable medium having instructions stored thereon, which, when executed by the at least one processor, cause the system to perform the method according to any one of claims 1 to 10 or cause the system to perform: At computer nodes of a distributed digital ledger transaction network, an authenticated data structure for the distributed digital ledger transaction network is generated, wherein the authenticated data structure includes a data tree, the data tree including nodes with data representations mapped to entries in a database, and wherein the authenticated data structure corresponds to an authenticated data structure maintained in other computer nodes of the plurality of computer nodes; and Lazy deletion of data from the certified data structure is performed at the computer node using the following operations: Accessing data representations from nodes in the data tree to determine the expiration date associated with the node; In response to determining the expiration date and before deleting one or more entries corresponding to the node from the database: At the computer node, a request is received from the client device, the request requesting the use of one or more of the aforementioned entries, and Process the request as if the one or more entries had been deleted; and At the computer node, one or more entries corresponding to the data representation are asynchronously deleted from the database, while the data representation is maintained within the data tree and at least one of the certified data structures maintained by the other computer nodes is maintained, along with the one or more entries.

18. The system of claim 17, further comprising instructions that, when executed by the at least one processor, cause the system to: delete the one or more entries corresponding to the node from the database without any transaction event request on the distributed digital ledger transaction network for deleting the one or more entries.

19. The system according to claim 17, wherein, Processing the request as if the one or more entries had been deleted includes transmitting an indication to the client device that the eviction date has expired.

20. The system according to claim 17, in, The database includes a state database, the one or more entries include account data corresponding to user accounts, the data tree includes a state tree, and the nodes include account state representations corresponding to the account data of the user accounts; and The system also includes instructions that, when executed by the at least one processor, cause the system to: Identify an account recovery request associated with the user account, wherein the account recovery request includes proposed account data for the user account; and The proposed account data of the user account is verified based on the account state representation within the state tree; Based on the proposed account data that verifies the user account, the proposed account data associated with the user account is re-cached in the state database of the distributed digital ledger transaction network; and The eviction date associated with the node is updated based on the re-caching of the proposed account data associated with the user account.

Images