CROSS-REFERENCE TO RELATED APPLICATION [0001] This application claims priority to U.S. Provisional Patent Application Serial

Number 62/990,679, filed March 17, 2020, the contents of which are incorporated herein by reference.

FIELD OF THE INVENTION

[0002] This invention relates generally to network processing of cryptocurrencies.

More particularly, this invention is directed to techniques to produce notarized append-only memory (NAOM) in a distributed ledger.

BACKGROUND OF THE INVENTION

[0003] UNiCORNs are UN-COntestable Random Numbers; that is to say, random numbers which can be analyzed by any party or judge to satisfy them as to the true randomness of the number and furthermore to guarantee no particular party involved in setting up a UNiCORN could influence the outcome of the number generation.

[0004] Distributed Ledger Technologies (DLTs) are a consensus of replicated, shared, and synchronized digital data geographically spread across multiple sites, counties, or institutions. There is no central administrator or centralized data storage.

[0005] Unicast is communication between a single sender and a single receiver over a network.

[0006] Multicast is communication between a single sender and multiple receivers over a network.

[0007] Group Key Exchange (GKE) is a general term for the process by which a group of individuals establish a secure key which is cryptographically suitable for secure communication and messaging. Where Key Exchange is between two parties, Group Key Exchange must also enable key exchange between three or more parties. Group Key Agreement is one form of Group Key Exchange.

[0008] RAFT consensus is an efficient state-replication algorithm for data integrity across multiple servers or parties. [0009] Application Specific Integrated Circuits (ASICs) are integrated circuit chips that are customized for a particular use, rather than for general purpose use.

[0010] A ledger is a permanent summary of all amounts entered in supporting journals which list individual transactions by date. A register also chronologically records an object or amount against a state but does not necessarily infer transfer, trade, or transaction of the registered object.

[0011] The word "ledger" has functional equivalence with the word "register" for the purposes of this document, as whether or not an entry fulfills the requirements of register or ledger depends on application , law, and can change with time, but the technical requirements of both are met within NAOM. Throughout this document, "ledger" serves as a singular word in detailing the protocol at a technical level, although it should be borne in mind that the utility of the NAOM ledger includes, but is not limited to, registers and ledgers.

[0012] Ledgers have been deployed as far back as Sumerian culture and even further.

Ogham stones serves as an ancient example of land registers. Since their inception, the utility of these records were met through centralized technologies. Centralized records (ledgers and registers) were either written in stone or held physical layer security components in that they were placed into vaults of steel, or in the modem era, restricted access areas/ servers.

[0013] Due to the increase in technical efficiency of applications running over networks and "on the web", centralized record keeping based on labor has become expensive to extend to multiple agents (groups) needing to interact off a singular ledger scalably, although centralized records do offer energy efficiency and governance models.

[0014] The advent of a new data structure and infrastructure of DLTs produced a ledger technology that solved the Byzantine Generals Problem (BGP) so that multiple actors in different times and in different spaces can coordinate a single document using only copies of that document. This technology provided a group-ready secure ledger but, at the same, time, has no governance structure nor energy efficient scheme. Specifically, Proof-of-Work (PoW) DLTs remain BGP secure while proving inefficient for industrial and enterprise level use.

[0015] Contemporary attempts to address the concerns associated with PoW-based

DLTs have taken a silo approach to solve issues specifically and top down, namely:

• To tackle scalability, attempts have been made to use custom hardware, swapping proof-of-work for other "proof-of ' schemes, reducing the number and functionality of validator nodes, or instituting Directed Acyclic Graph based alternatives. Partial governance solutions include Delegated Proof-of- Stake (dPoS) and network shells.

Attempts to address energy inefficiency of DLT networks are numerous from non- PoW schemes, partition algorithms, DAG-based networks and much more.

[0016] Thus, there is need for an improved network architecture for PoW-based

DLTs.

SUMMARY OF THE INVENTION

[0017] A non-transitory computer readable storage medium has instructions executed by processors within a distributed network. The instructions include instructions to perform distributed ledger computations on a first collection of machines forming a first network. Distributed ledger verifications are performed on a second collection of machines forming a second network. The distributed ledger verifications are modulated by a thermodynamic function to equalize computation load across the second network. Distributed ledger storage is performed on a third collection of machines forming a third network.

BRIEF DESCRIPTION OF THE FIGURES [0018] The invention is more fully appreciated in connection with the following detailed description taken in conjunction with the accompanying drawings, in which:

[0019] FIGURE l is a network configured in accordance with an embodiment of the invention.

[0020] FIGURE 2 illustrates processing interactions between different machines utilized in accordance with an embodiment of the invention.

[0021] FIGURE 3 illustrates unicast operations performed in accordance with an embodiment of the invention.

[0022] FIGURE 4 illustrates transaction record multicast performed in accordance with an embodiment of the invention.

[0023] FIGURE 5 illustrates a data structure utilized in accordance with an embodiment of the invention.

[0024] FIGURE 6 illustrates promise-commit operations performed in accordance with an embodiment of the invention.

[0025] FIGURE 7 illustrates a double round structure utilized in accordance with an embodiment of the invention. [0026] FIGURE 8 illustrates a mining process performed in accordance with an embodiment of the invention.

[0027] FIGURE 9 illustrates work cost computations performed in accordance with an embodiment of the invention.

[0028] FIGURE 10 illustrates penalty computations performed in accordance with an embodiment of the invention.

[0029] FIGURE 11 illustrates a thermodynamic function utilized in accordance with an embodiment of the invention.

[0030] FIGURE 12 illustrates mini-puzzles utilized in accordance with an embodiment of the invention.

[0031] Like reference numerals refer to corresponding parts throughout the several views of the drawings.

DETAILED DESCRIPTION OF THE INVENTION [0032] As shown in Figure 1, the disclosed network architecture has three interconnected sub-networks. The invention producesasuperiorledgermemoryby separating out computation, verification and storage into three distinct networks where appropriate security models and efficiency can apply independently.

The computational ring:

[0033] A fixed number of nodes which are connected in a suitable decentralized ring network (set to 20 for narrative purposes) and provide a mostly computational service.

The mining sub-network:

[0034] Miners produce verification stamps on transaction blocks. In departure from the hash- based block pointer of traditional PoW DLTs, NAOM uses UNiCORN pointers. UNiCORN pointers allow for a more robust blockchain data structure as well as a source of initialization vectors and values for setting up secure and temporal cryptographic functions. The mining nodes retain the basic notion of proof-of-work, extending it thermodynamically through a new hash function. Verification of the ledger and BGP fault tolerance is handled by miners, while block creation is co-produced by the computational ring and the mining network. The storage ring:

[0035] A pre-defmed number of nodes which are connected in a suitable decentralized ring network (set to 20 for narrative purposes) that provide ledger storage facilities. They exist under RAFT consensus to mitigate the increased attack surface introduced by reducing the number of storage nodes.

[0036] Figure 2 illustrates signal exchanges between different network machines utilized in accordance with the invention. Figure 3 illustrates transactions unicast to computational nodes.

New transactions are unicast to a computational node.

[0037] Valid transactions are represented as a tuple in the format (A, B, SDA, TB), which denotes that Alice (A) and Bob (B) are the parties to the transaction whereby Alice transfers smart data SDA ownership to Bob and Bob transfers a Zeno token based payment TB to Alice in exchange.

[0038] There are two methods users can employ to send a transaction to a computational node: synchronous and asynchronous. In the synchronous method, both Alice and Bob sign the tuple synchronously before submitting it to the computational node. Alice and Bob have free choice in which computational node they wish to unicast their transaction. In the asynchronous method Fred (F) commits to transfer ownership of smart data SDFto Georg (G) but expects that George should have produced a token transfer order (within a predetermined threshold time) Expect TG. This half-tuple takes the form:

(F, G, SDF, Expect TG).

[0039] George has produced a counter-signed token transfer half-tuple:

(F, G, Expect SDF, TG)

Fred and George have free choice as to which computational node they submit their individual half-tuples to and can submit these half-tuples on different computational nodes if they choose.

Each computational node multicasts its tuple and half-tuple list to the computational ring.

[0040] If one considers the tuple and half-tuple list residing on the top center computational node after the user round of multiple unicasts, then the top center computational node is aware of (A, B, SDA, TB) (F, G, SDF, Expect TG) which it is responsible for multicasting to the rest of the computational ring.

[0041] Once all nodes have completed their respective multicast, as shown in Figure

4, each node now has the following tuple and half-tuple list:

(A, B, SDA, TB)

(A, C, SDA, TC)

(F, G, SDF, Expect TG)

(F, G, Expect SDF, TG)

[0042] Each computational node performs a provisional check to establish the legitimacy of the pending transaction requests.

[0043] Each computational node will flatten the two half-tuples

(F, G, SDF, Expect TG)

(F, G, Expect SDF, TG) into a single tuple (F, G, SDF, TG) and also recognize the double data spend attempted by Alice.

(A, B, SDA, TB)

(A, C, SDA, TC) whereby Alice's attempt to pass the same smart data asset SDA to both Bob (B) and Charlie (C) will fail to verify. The computational ring will alert the three parties to the conflict, exclude all poisoned tuples and allow members of the transaction to resubmit if they find resolution and a way forward.

The computational ring coordinates with the full mining network to establish 20 (for narrative purposes) partitions.

Each computational node individually places new transactions into blocks.

[0044] Each node within the computational ring places new transactions into blocks according to a predefined set of rules such as user-selected security levels, transaction fee preferences, clearance periods, contract preferences (automated execution preferences), jurisdictional requirements, etc. in order to arrive at the same un-mined blocks independently. A typical block structure is shown in Figure 5. [0045] The entropy seed is a set of values derived from the real world that are not economic in nature, such as, e.g., the hash of the number 1 trending Twitter feed. The purpose of the entropy seed is to inject data tied to real world events and thus increase the total entropy significantly of each block, improving the security behind UNiCORN generation.

The computational node encrypts its block and sends it to a server.

[0046] Once all randomly elected miners E _x and the computational node c _nx have completed GKE the computational node within the partition encrypts its block and passes the encrypted block to a publicly-visible server where E _x miners can use their GKE-derived key to decrypt the block. Miners append personal coin-base transactions based on the ADDR value used in election to the standard block in order to individualize them and begin mining.

The mining proceeds alongside the thermodynamic balancing of the network block processing speed.

[0047] The miners in the partition share the values of their block processing speed along with the recent time-dependent history of the block processing speed with each other. The block processing speed (termed 'heat') is adjusted for each miner based on the pair-wise comparison with the other miners' heat in order to move the partition towards equilibrium on this value. This is done through increasing the time (decreasing the likelihood) for a miner to find a block (to lower the heat) or decreasing the time (increasing the likelihood) for a miner to find a block (to raise the heat). The miners verify the recent time history of the other miners' heat in order to prevent gaming of the system. During this process, but after enough time has passed for the heat to be reasonably communicated to the other miners in the partition, the miners mine for the block.

Miners compute UNiCORN-linked blocks, not hash-linked blocks [0048] A hard cut-off time is set per UNiCORN generation round. The signaling of this cut-off might be generated by Pool A for Pool B (pools explained below) so that cut-offs are miner-determined, or against some external clock.

[0049] Miners in partition P _x have from the mining start time until cut-off to produce a valid proof-of-work. Miners work on the standard block as sent to them from the computational node in their partition cn _x concatenated with their individual secret value ADDRi II SALT generated during partitioning. The computational node cm accepts all PoWs as UNiCORN promises within this time period and timestamps the multiple submissions. [0050] Once cut-off occurs, miners submit ADDRi || SALT as commits to their individual computational node cm. Each computational node confirms the PoW using the standard block and ADDRz || SALT.

[0051] If valid, the compute node informs the larger compute ring of the winning miner. If the PoW is not valid it checks the next time-stamped PoW. If valid, the compute node informs the larger compute ring of the winning miner. This process is continued until either a valid PoW is found or the list is exhausted. If the list is exhausted the compute ring will simply disregard any input from cm towards UNiCORN computation and form the UNiCORN from the remaining 19 participants. If the number of participating partitions in UNiCORN creation is less than a certain threshold (say 11) then the mining round is deemed unsuccessful and is started again with a new partitioning round.

[0052] The UNiCORN is calculated as the logical Exclusive-OR (XOR) of the winning ADDRz || SALT values which may be hashed if truncation is required.

[0053] A note on timing within UNiCORN creation and the need for network pools:

• UNiCORN N is calculated from the block (/V-l) and the key used to decrypt the block calculated from UNiCORN (N- 2). This obviously requires a setup of 2 previous blocks before NAOM can produce UNiCORN N. The requirement for UNiCORN (N - 2) and (N- 1) to be available simultaneously for efficient mining is achieved through the construction of pools.

[0054] Pools will appear spontaneously and are not constructed anywhere cm nodes will run a partitioning round at the same time as they distribute an encrypted block. Miners who made a partition election will be busy mining while the excluded miners will naturally immediately begin another election bid round.

Writing mined blocks to the storage ring

[0055] The winning miner gets permission from the computational node cm to write the next block to the storage ring. All nodes within the storage ring are under RAFT consensus management to ensure that all ledgers are kept synchronized.

[0056] In practice the compute node cm writes the standard block to the storage node sm and permits the winning miner to write their individual UNiCORN shard (their ADDR || SALT, PoW nonce number pair) to the UNiCORN table. [0057] The individual miner signals their agreement to the validity of the standard block by writing their ADDR || SALT, PoW nonce number pair to the UNiCORN table. [0058] Each UNiCORN shard is duplicated amongst the compute ring so that all members of the compute ring have an individual copy of the same UNiCORN table.

[0059] All miners update their personal copy of the UNiCORN table to maximize their chances of winning subsequent miner election phases.

Coin-based transactions are loaded into the next block

[0060] The compute nodes all begin to form the skeleton of the next block to be mined by using the information in the ADDR || SALT values from the completed UNiCORN tables to generate valid coin-base transactions to pay successful miners their block reward. [0061] The network is now ready to accept the next batch of transactions from the pending user generated transaction pool and the cycle begins again.

OVERVIEW OF GKE BASED PARTITIONING (GBP)

[0062] Partitioning the mining network into active miners and dormant miners serves many purposes. A partitioned miner network has an inherent energy ceiling on power consumption. Simultaneously, limiting miner participation per round produces a better return on investment for miners. Partitions are most efficiently formed cryptographically. Although the physical network can be publicly accessible by all miners, only members who share a key can meaningfully participate in mining a specific encrypted block using their shared key. [0063] The minimum dual requirements for a partitioning algorithm suitable for

NAOM implementation are:

• Participants within the partitioned network must have reason enough to believe that their entry into the partition is "fair".

• The maximum number of participants selected into the partition is fixed.

When using Group Key Exchange (GKE) as the cryptographic base for partitioning one must:

Randomize participation in key exchange such that a variable number (x) miners can attempt key exchange but only a fixed number (E) miners will succeed.

Integrate a key scheduling mechanism that prevents replay attacks and synchronizes participants effective start time for mining. [0064] There are many existing cryptographic Group Key Exchange (GKE) protocols that could be suitable for a functional GBP implementation, namely:

• Three-party Diffie-Hellman key exchange with one messaging round.

• Group Key Agreement Protocols (GKA)

• Asymmetric Group Key Agreement Protocols (AGKA)

• Authenticated Asymmetric Group Key Agreement Protocols (AAGKA)

• Distributed Collaborative Key Agreement for Dynamic Peer Groups Password- Based Group Key Exchange in a Constant Number of Rounds (PGKE)

• Shamir Shared Secret Key Escrows And many more...

GBP protocol objective

[0065] The computational ring CR is a set of twenty (twenty chosen for narrative purposes) computational nodes cn such that CR = cm, cm, cm ... cm o

[0066] The mining network ( M) is the set of all miners such that

M= mi, m2, mi ... m _*

[0067] Elected miners ( E) eligible for mining a block within a partition is a subset of the total miner population such that E _{x C} M

[0068] The correctly formed network partition ( P _x ) is the union of an individual element of CR (a computational node cm) with a set of elected miners (E _x )

P _x = cn _x U E _x

[0069] It is the number of computational nodes that determines the number of partitions. The objective of the GBP is to form a partition that all participants within the partition can agree is fair and current.

GKE BASED PARTITIONING PROTOCOL

[0070] GBP executes a miner election phase followed by using the results of this election for the group key exchange phase. All suitable GKE candidate protocols can run election phase such that it is a procedural prerequisite to GKE but election phase is not required cryptographically for GKE. Some GKEs such as “password based” and “simple password based” can run election phase as a fundamental cryptographic prerequisite to the GKE. GBP election phase

[0071] GKEs listed above as suitable usually start with a participant Alice, who chooses a secret integer

Si = A DDR, (I SALT

[0072] Here ADDR is the Zenotta address to which miners are paid for successfully mining a block. The SALT used here is to temporarily obfuscate the address as the secret integer. Later, the SALT can be broadcast to verify that the miner winning the reward (some Zeno tokens) is the participant from election and not some other miner.

[0073] From this secret integer Alice computes a public integer through some derivation function to produce F(SI). She then constructs an election seed,

Aseed ⁼ F(Si) || UNICORN(A-2) || R _cn% , from which she computes a light proof-of-work by incrementing an election nonce (//nonce) until the hash output of

FI (Anonce | | Aseed) has a prefix run of zeros that is less than the prefix run of zeros used to set the difficulty during mining.

[0074] The computational node cn _x maintains a publicly visible open access server running two lists, namely:

• The valid list of Anonce, A _se ed pairs against the timestamp of each hopeful election entry as it was received.

• The invalid list of spoofed Anonce, Aseed pairs whose light proof-of-work is invalid.

[0075] Miners wishing to be elected have free choice of which computational node they submit to and so honest miners will rather submit to computational node cn _x where latency is reduced and faster Anonce || Aseed publishing times are available.

[0076] The UNICORN ( N -2) ties a miner's bid for election to a specific interval of block time. Group keys generated in block time ( N - 2) from GBP are valid to mine block ( N - 1). This gap in blocktime is critical because GKE must be concluded before encrypted blocked are shipped from the computation node cm to the elected miners Ex to prevent delay attacks where cn _x actors attempt to collude with certain miners.

GBP key exchange phase

[0077] Typical 2-party Diffie-Hellman key exchange protocols use the following function to derive public integers from secret integers: [0078] Alice picks a random natural number “a” (secret integer) and computes g ^a mod(p) to send to Bob as her public integer. In GBP the random number “a” is Si = ADDR; || SALT.

[0079] Naive extension of the approach to many participants during GKE introduce computational steps such as:

Carol computes ( g ^ah ) ^c = g ^abc for three parties where exponentiation of three ADDR || SALT constructions fast becomes computationally prohibitive, especially when GKE can entertain as many as 4096 miners per election envelope. Some fixed round multiparty GKEs introduce a work around to multi exponentiation as seen below, for a group of users pid= ( Ui , ..., Un) that are assumed to be in a circular index cycle such that l h, = Un and l ,- 1 = Ui.

Round 1

Computation

Each Ui chooses h £R (0, l} ^k , Xi £R Z _q and computes y, = g ^X .

Each Ui sets M / = H(k,) || y,.

Each Ui computes a signature s[ on M[ \\pidi Broadcast Each U broadcasts M s[

Check Each U checks all signatures aj of incoming messages M- || aj for j ¹ i.

Round 2

Computation

Each Ui computes s/d, = H (pidi II H(ki) || ... || H(k„- 1 ) || H(k _n )).

Each U encrypts their k contribution as ek = k ® tf.

Each U sets

Each U computes a signature s· ¹ on M· ¹ .

Broadcast Each Ui broadcasts M \ \ s· ¹ Check

Each Ui verifies the incoming signatures s· ¹ on the corresponding message M· ¹ for every j ¹ i.

Each Ui also checks that 7 0 ... 0 T _n = 0 and sidi = sid _j.

Each Ui extracts k _j = ek _j ® 7 ₊₁ ® ... ® every j ¹ i.

Each Ui checks the commitment H(kf) sent in Round 1 for the kj extracted.

Key Computation

Each Ui computes the session key ski = Hgipidi | k _\ | ... || k _n ).

[0080] Here the "public value" derived is the compound (concatenated) integer H(ki) || yt where “ _; ” is simple exponentiation from a random “a” value, as in g°, and H(k,) is the hash of key k. Considering that keys are ephemeral and are expired every 30 seconds, the reverse lookup weakness associated with hash functions does not pose a practical attack surface. It is possible therefore to choose k as ADDK || SALT. This also significantly simplifies the computational overhead of verification.

[0081] Such a GKE would continue by setting the message M[ for user U to this public value, and then computing the signature of the message concatenated with the identifier pidi of user l h using a standard public/private key signature scheme. This concatenation is then broadcasted. Each subsequently checks the signatures for all other users other than their own.

[0082] In Round 2, each computes a further exponentation y ^x ‘ for the user on either side of them in the indexed list, and hashes the result. These two left and right values are then XOR-ed together to produce a value Ti for . The user also computes a concatenated string sid of their user identifier together with all the hashes of the keys, and hashes the result. Next, each user encrypts their key by taking the XOR with the hash of the double exponentation y ^Xi from the user to the right in the indexed list. A second-round message Af ^/ is then set as the concatenation between the encrypted key, the XOR-ed left and right hashed double exponentiated values, and the sid concatenated string. Finally, each l h computes the signature s· ¹ of this second-round message.

[0083] The broadcast phase of Round 2 sends the second-round message concatenated with the second-round signature to the other users. The check phase then proceeds by having each user verify the second-round signatures for all other users other than their own, along with confirming that the XOR of all the Ti values comes to zero and that sidi = sidj. Each user then extracts the key for all other users through the process of XOR- ing the T values with the encrypted keys and the left-hand hashed double exponentiated value. Finally, each user checks that the hash of each key just extracted matches the hash previously sent by every user.

[0084] The final step of the procedure is for every user to then compute the session key Ski by concatenating all the keys along with the identifier pidi and hashing the result. [0085] Certain types of GKEs require a setup phase agreed upon prior to the GKE phase. Typically, these technologies are avoided because of the pre-setup requirement, but they do lend themselves to an election phase because the election phase can easily be modified to be the setup phase. In this regard, election becomes a cryptographic prerequisite. SP- and P-type GKEs use a simple password (SP) or password (P) table under a weak security assumption and use these values to compute a strong session key.

[0086] Here, the proof-of-work submitted to the server can be used to compute a

Shamir shared secret curve or SP / P table.

OVERVIEW OF THERMODYNAMIC PROOF-OF-WORK

[0087] The thermodynamic protocol for our blockchain network has two main objectives:

Evolving the block processing speed across the network to a homogeneous and balanced distribution through analogy with heat diffusion;

Recording an aggregate work cost to provide functional Oracle memory and infer how much trust can be placed in the transaction history of an asset under management by the ledger.

Thermodynamic balancing: an analogy with heat

Overview

[0088] Through analogy with heat transfer in nature - specifically, conduction - we have constructed a proof-of-work (PoW) algorithm that allows a relevant quantity to diffuse between mining nodes in the network. Our relevant quantity in this case is the ability (or the probability) of a mining node to find the correct nonce for a block by solving a cryptographic puzzle (in this sense, the standard goal that underpins the majority of PoW cryptocurrencies). For the purposes of this explanation, and because the behavior of this quantity across the network behaves analogously, we call this quantity ‘heat’. [0089] The rate and/or probability at which a mining node is able to mine a block is a function primarily of its hashrate, but also contains secondary terms such as latency, connectivity, etc. Our heat is therefore expressed as a general function which we term eta, and infer and constrain using computer models. In a standard mining network, the distribution of heat is normally very heterogeneous; fast, dedicated processors (e.g., ASICs) and processor farms process blocks at rates that are exponentially higher than those participants mining on slower hardware such as CPUs or GPUs. This is not only inefficient for the network as a whole; it can also be viewed as an attack on decentralization and can compromise the security of the blockchain.

[0090] We move towards a homogeneous distribution of heat across the network by decreasing the block processing ability of the ‘hot’ nodes and increasing it for the ‘cold’ nodes. This is done smoothly, allowing our quantity h to change between nodes pairwise using a simple differential equation. As a result, the algorithm avoids a centralized controller and operates autonomously. The way in which the block processing ability is altered is by dialing up or down the number of iterations within the hash function, together with the addition of a verifiable delay function (VDF) embedded in each iteration to amplify the iterative slow-down if the number of iterations required moves outside of the acceptable range. In this way, those miners that operate the more powerful processors take longer to find a block- they are disadvantaged, while the miners with the less powerful processors are advantaged. After some time, the network will reach 'thermal' equilibrium and the likelihood of mining a block will be equal for all participants.

[0091] While the mining moves towards a state that is equal for all participants, the reward structure can take any distribution, depending on the optimal incentivization approach. Although the protocol encourages participants to run all on similar levels of technology, a miner bringing a substantially higher hashrate than the average can be said to be contributing a higher level of security (both cryptographically, since the ‘capacity’ part of the hash function state memory will be larger for a higher hashrate - see Section 7.2, and in terms of the network providing that the miner in question is not malicious) in the crude sense that the total hashrate of the network is higher (although it should be noted that, as we have specified, the total block processing speed is not as important as the distribution of the same - of course in our system, unlike standard blockchains, the block processing speed is no longer synonymous with the hashrate). Therefore, to incentivize large players to join the network, the block reward can be made a function of the hashrate distribution. Similarities to existing systems

[0092] This approach marks a substantial departure from all previous blockchain network proto- cols, while at the same time keeping the established functionality that underpins PoW cryptocurrencies. Its main departure is that of a peer-to-peer algorithm to maintain mining fairness across the network; in short, the algorithm can move the operation of the network towards a ‘one participant one vote’ model. As a very simple example, when the network is ‘thermodynamically flat’, a participant using an ASIC miner will have the same chance to mine a block as a participant using a single CPU. Note that this distribution can be adjusted to meet certain required standards, whether they be technical, economic, social, or even political. A completely flat distribution across the network may not be viable from an economic or game theoretic perspective, and so alternative distributions can be considered and implemented.

[0093] There are of course some elements of this design that have similarities with particular systems within the crypto space. The most obvious one is that of mining pools, which divide up the mining reward proportional to the hashrate that a participant contributes to the pool. In this way the reward structure is spread over all participants and so the hashrate that each brings must be determined and used to infer the individual reward. This aspect of a pool displays similarities with how we implement the determination of the hashrate and the fact that all participants have a fair chance of a reward. However, in a pool the reward is proportional to hashrate, incentivizing large players in exactly the same way as a standard mining network, and the mining itself - namely, the act of finding a block and securing the network - is still dominated by those participants with the fastest processors.

[0094] There have also been a number of studies and systems developed exploring equilibria and game-theoretic strategy across mining networks. We briefly describe a few examples here and discuss how they relate to our designs. Note that this is not an exhaustive set of similar work but rather a sample to give an idea of how our system fits in within the space.

[0095] Work by Iyidogan (2018) presented 'an equilibrium model of blockchain- based cryptocurrencies that employs strategies such as periodically adjusting the difficulty of the mining puzzle (for the whole network) and dynamically updating the mining reward in order to reach a stable equilibrium that is characterized by the relevant quantities no longer changing in time, after having reached the optimal values for all players. In this study they consider a scenario involving N homogeneous miners all operating with the same hashrate and show that an equilibrium can be reached providing the mining reward stays below a threshold value. The interaction between miners and users in the presence of a low mining reward, or, more pertinently, in a system purely reliant on transaction fees, creates a Nash equilibrium that disincentivizes miners from increasing their computational power and in theory moves the network toward homogeneity. However, this assumes that the miners have the same rate of access to mining technology and that all participants are rational actors. [0096] Such an approach therefore has similarities with our design, however a crucial difference is that in our system we reach equilibrium and mining homogeneity through a thermodynamic approach rather than a game theory approach, eliminating the need for all miners to be similarly advantaged in terms of access to technology. Furthermore, we have no requirement for rational actors, as the balancing of our system proceeds by responding to changing circumstances and behavior on an algorithmic basis rather than a social basis.

[0097] It is also important to note that in our system, the difficulty of the mining puzzle and the difficulty of finding a block are not the same thing. The difficulty of the mining puzzle is a parameter that can be adjusted for the whole network if necessary to respond to changing circumstances e.g., economic, social etc., while the difficulty of finding a block is the quantity that is flattened across the network using our thermodynamic approach and the analogy with heat.

[0098] Bitcoin-NG incorporates strategies that promote decentralization and security, as well as fast transaction processing times, by employing micro-blocks and dividing up the transaction fee between the leader of the current round and the subsequent round to incentivize miners to behave honestly and extend the most secure chain. However, Wang et al. (2019) demonstrate that such a protocol is prone to advanced mining attacks by altering the mining duration length to gain an unfair advantage over an honest miner in terms of mining revenue.

[0099] If all miners adopt the advanced mining approach then the situation becomes a game for which a Nash equilibrium exists and can be reached. In this case, actors are assumed to be rational and attempting to maximize their profit from the mining reward (albeit with a reduced reward from transaction fees). This approach can achieve the optimal processing speed for the network, but does not remove the incentive for increasing one's computational power at the expense of network homogeneity.

[0100] A study by Biais et al. (2018) analyzed the existence of multiple equilibria within the blockchain dynamics of a proof-of-work protocol using a game theoretic approach and considering the strategies of the miners. They find that undesirable equilibria exist, for example one in which forks and orphaned blocks are created due to the interplay between information delays and the vested interests of the miners. In addition, they highlight certain negative externalities as forms of inefficiency in blockchain design, a relevant one being the behavior of a miner in choosing to invest in increasing their computational power, causing other miners to have to over-invest in order to try to keep up. Such an arms race has a further unwanted externality, which is the continual increase in mining difficulty and energy consumption of the network, with no real benefit to either security or efficiency.

[0101] A number of aspects of our system have been developed based on the principle that the vast majority of undesirable equilibria are mitigated by improving decentralization. For example, it can be shown empirically that as network heterogeneity tends towards zero, the number of orphaned blocks tends towards zero and also becomes independent of the communication delay between nodes. Inefficiencies or other negative externalities such as environmental damage are also mitigated by our approach to decentralization that removes incentives to prioritize individual greed over the good of the network.

[0102] Nakahara & Inaba (2018), in a conference proceedings, describe a proof-of- work approach based on adjusting the difficulty for each miner individually to adjust to differences in computational power. In this way the probability of generating a block is approximately equal for all participants. The evaluation of the difficulty is performed by the miner themselves using the computational power, the number of blocks mined, and the length of the mining period. The mining reward is based on the computational power supplied rather than number of blocks mined.

[0103] While this approach obviously bears a number of similarities with our design, it lacks detail and implementation specifics. It also contains several aspects that would invalidate it as a functioning PoW system - first, the computing power is declared and subsequently verified, rather than determined; second, the difficulty adjustment is made based on previously mined blocks and so can be easily gamed, e.g., by choosing to mine at a low level in order to have the difficulty lowered and then mining the next sequence of blocks with the full processing power (and the verification does not prevent such gaming); third , the verification relies on an unreliable , probabilistic assessment of the computing power, back- calculated from a block mined within a certain time.

[0104] In our system these aspects are not present. The block processing ability is deter- mined, rather than declared , and is adjusted on-the-fly based not on historical data but the current 'heat' of the miner - this is continually monitored and verified by the other parts of the network (including the other miners) using sufficiently high time resolution to get an accurate assessment.

[0105] Obviously, there are many implementations of blockchain technology currently in existence, the majority of them possessing some form of economic or monetary value and employing similar underlying technology to our proposed system. Where our design stands apart from previous approaches is in the marriage between the security and efficiency gains that draws on thermodynamic principles. In our system, a form of decentralization pressure is created by the thermodynamic balancing that algorithmically pushes the network to be fully decentralized (pushing the Gini coefficient towards zero). At the same time, the lack of incentive to continually ramp up your processing power and/or design ASICs keeps the energy usage and carbon footprint to a minimum.

Value creation

[0106] Our design therefore provides (i) the user with maximal security - all other aspects being equal, a more decentralized network is more secure than a less decentralized one; (ii) the miner with maximal opportunity for the least cost - no requirement to compete with other miners to purchase or build the fastest equipment; and (iii) the network with maximal efficiency - the best network to maintain a blockchain is not one with the largest processing power but one with the best distribution of processing power.

THERMODYNAMIC WORK: AN APPLICATION OF LAND AUER'S PRINCIPLE

Overview

[0107] An important aspect of a blockchain is its ability to aggregate a work cost when processing a transaction. Deciding how much to trust the value of an asset that is under management and tracked by the ledger can therefore leverage the history of that asset on the blockchain via that work cost. Our blockchain design can be viewed as possessing functioning Oracle memory, providing that this work cost per transaction is irreversible and consistent. Oracle memory is distinct from Turing memory in that it is path-dependent and non-deterministic. This is achieved by including a deliberate thermodynamic penalty to any operation performed in memory, which provides both immutability and a way to measure decision confidence.

[0108] Through the Landauer principle, which states that operations on computational bits have an associated minimum amount of entropy gene ration, this work cost has an actual thermodynamic component. This is distinct from the analogy to thermodynamics that we use to balance the network block processing speed - in this case the operation of the proof-of- work generates a real, aggregate thermodynamic work cost that can be used to measure the validity of the agent-based consensus. In our design, there is a specified thermodynamic work cost to each iteration within the hash function (see Figure 9) which adds up to an aggregate value for each transaction; this value is therefore a function of the amount of work done by the miner in question, and can be tracked and used to codify the work history of an asset traded and managed by the blockchain.

Similarities to existing systems

[0109] The modern computer is based on the work by Alan Turing and Alonso

Church in the 1930s on computable functions. Turing also described the concept of an Oracle machine, which comprises a Turing machine connected to an oracle (an entity capable of solving a decision or a function problem). The oracle is typically thought of as a black box, the internal workings of which are unknown.

[0110] An Oracle machine is in theory able to return the answer to any problem, even if that problem is not computable by a Turing machine or equivalent, by querying the oracle. The concept is largely confined to the academic discipline, but it can be argued that the invention of the blockchain has given us a way to construct a functional approximation to an Oracle machine. Current blockchains allow for consensus to be reached on the validity of a transaction without trusting a third party. Our approach draws on this technology and extends it into the domain of an Oracle machine by allowing the work cost to be tracked and used to determine the answer to a decision problem. Our system therefore has similarities both with theoretical concepts of Oracle machines and with practical implementations of blockchains.

Value creation

[0111] The concept of the Turing machine was one of the most powerful and influential insights of the last century, giving birth to an entire academic discipline and technology that changed the world. While the concept of the Oracle machine was developed at around the same time, its legacy has remained theoretical. However, practical implementations stand to offer a similar paradigm shift and subsequent advancement in a wide range of applications. [0112] As such, the potential of a functional Oracle machine is vast. In the same way as modern computers are approximations to a Turing machine, our system can be viewed as an approximation to an Oracle machine that can solve decision problems. By incorporating a irreversible entropic cost function that can be measured and recorded into the operation of the blockchain network we have designed a form of Oracle memory that allows the network to function as such an approximation. The aggregate work done in the Oracle memory acts as a measure of the validity of the answer to a posed value problem, provided it is achievable through agent-based consensus. In other words, the path taken and the work done is relevant. This is what allows our Oracle memory design to handle decision problems requiring consensus. Together with the creation of smart data, and identity-based digital ownership, this system can be viewed as a general-purpose World Oracle Machine (WOM) that completes digital systems by allowing data to contain both information and value.

THERMODYNAMIC BALANCING PROTOCOL

Proof-of-work (PoW) overview

[0113] Figure 8 shows the mining process for our thermodynamic PoW algorithm.

We detail each aspect below, with reference to two miners, A and B, who are representative of the peer-to- peer communication employed by our thermodynamic balancing scheme.

Each function denoted with a dashed border is a specific part of our design, for which zoom- ins are detailed later on in this Section.

[0114] In all of the following, we use the term 'hea to refer to the block processing speed of a miner that our algorithm attempts to equilibrate across the network.

[0115] The compute nodes in the compute ring (CR) send the ingredients for the next block to miner A. This consists of the unicorn of the previous block, the transactions to be included , and the target difficulty of the cryptographic puzzle.

[0116] The transaction signatures are verified by miner A and together these three ingredients are input into the hash function, along with the incremental nonce counter.

[0117] The hash function communicates the relevant quantities for calculating the heat of miner A’s node and for determining the period over which mining took place to the penalty function.

[0118] The penalty function calculates this heat from a pre-defmed function

(determined, e.g., by computer modelling of the thermodynamic behavior of the network) and sends this, along with the information used to determine the mining period, to the thermodynamic function. We term this heat as 'calculated hea .

[0119] The thermodynamic function takes these quantities as input and sends them to miner B for to perform a verification. Equivalently, the calculated heat from miner B is input to the verify T|B function embedded within the thermodynamic function of miner A. The verify T|B function performs a check on the gradient of the heat to make sure that it has not changed too quickly during either the pre-mining time interval or the mining interval. If the change in heat during these times is sufficiently gradual to allow the change to propagate across the network (and to allow for heat changes from other miners to propagate to miner A) then the function writes a Boolean parameter as true; otherwise this is set to false.

[0120] The calculated heat is used, together with the calculated heat of miner B that has been through the verification process, to calculate via a differential equation the required change in heat for miner A that will move the network closer to thermodynamic balance. We term this the 'updated heaf. This is output from the thermodynamic function, along with the Boolean parameter that is the result of miner B's equivalent verification function in for miner A’s calculated heat. During the interchange, a copy of miner A’s time-dependent heat history is sent (by miner B) along with a copy of miner B's time-dependent heat history (sent by miner A) to either the compute ring or the storage ring (for illustrative purposes we chose to depict these being sent to the storage ring in Figure 8).

[0121] The penalty function takes the updated heat, along with the Boolean verifying that miner A’s heat has not changed too suddenly over the relevant time period, and com pares it to the calculated heat from earlier. This comparison function determines the new value of the 'rate memory' in the sponge construction (marked as r) in the hash function.

Both the new rate memory value and the verification Boolean for A are out- put to the hash function. A copy of the time-dependent history for the calculated heat and a copy of the time-dependent history for the updated heat is sent to either the compute ring or the storage ring; for illustrative purposes we have depicted the storage ring.

[0122] The hash function takes the updated rate memory value and changes the size of the rate memory, altering the number of iterations within the sponge construction and thus increasing or decreasing the block processing speed of miner A, as well as altering the size of the capacity c.

[0123] When a block that satisfies the target difficulty is found by the hash function, it is verified by either the compute ring, the other miners, or both, but only if the verify Boolean for miner A is true. This is in order that a miner must still expend resources even if they decide to cheat by maliciously dialing the heat up or down too quickly, and are subsequently unable to publish a block.

[0124] Once the transaction block has been verified, it is output to either the compute ring or the storage ring (for illustrative purposes we chose this to be the storage ring in Figure 8) via the 'promise - commit' step.

[0125] Along with the valid block of transactions, a second block containing thermodynamic variables is sent to either the compute ring or the storage ring (for illustrative purposes we chose to depict the storage ring).

[0126] The block reward is sent from the compute ring to the miner who produced the

(trans- action) block.

The hash function

[0127] The hash function uses a sponge construction to hash the input ingredients

(consisting of a nonce, the unicorn of the previous block, and transactions). This sponge construction has a partition in state memory that divides it into 'rate memory' (r) and 'capacity memory' (c). In the absorbing phase, these inputs are combined and padded and together with the pad are broken up into blocks of size r. The first block is XOR-ed with r and input into the cryptographic function f (for now we define f in general terms, without specifying its form, although it is likely it will comprise a permutation function as per the original design of the Keccak sponge construction). Subsequent blocks are XOR-ed iteratively with the output of the previous step. After the required amount of iterations which is set by the size of r, the squeezing phase occurs - the outer part of the state is iteratively returned as output blocks, interleaved with applications of the function f. The number of iterations in the squeezing phase is determined by the requested number of bits 1. The size of r and c combined remains constant, and so a smaller value of r (to give a larger number of iterations) means a larger value of c. The size of c determines the cryptographic security of the sponge construction, with a larger value more secure to cryptographic attack.

[0128] The parameters that determine the heat are output from the hash function, as we describe in the signal processes below. It is important to note that such parameters, in particular the hash rate, should be determined rather than reported, as the latter introduces the possibility of misreporting and using such behavior to act maliciously. We make use of zero- knowledge generation of false, randomized mini-puzzles that will indicate a miner's hash rate as a function of time relative to the other miners in the selection based on the speed at which they are solved. These could be randomly-injected and/or switched in and out with the real mining puzzle so that the miner would not know when the real puzzle was being computed, and so be unable to game the system by, e.g., timing the modification of their hash rate. In this way the graph shown in Figure 12 would be built up in increments of these mini-puzzles and the speed at which they were solved. The time resolution of this graph is therefore tunable based on the difficulty of these mini-puzzles.

[0129] Figure 9 shows the design of the hash function. The signal processes are the following:

[0130] The nonce, the unicorn of the previous block, and the transactions are input as the 'message', which is padded and subsequently 'absorbed' by the sponge construction.

[0131] The updated value of the rate memory that has been sent from the penalty function (after having been inferred from the original calculation of the heat and the subsequent updated value of the heat worked out in the thermodynamic function) determines the number of iterations and as such the speed at which miner A is able to solve the puzzle and mine a block.

[0132] The squeezing phase outputs the result which is checked against the target value. If it meets the requirements it is output to the wider system. A second output criterion is the verification Boolean parameter sent from the penalty function after having been determined by miner B.

[0133] A relevant time period (shown for illustrative purposes as the start and end time of mining), as well as the time history of the hash rate and the number of iterations is output to the penalty function. Note that we specify these parameters here for clarity but in general they may be any parameters that allow the penalty function to calculate the 'heat' that we desire to optimize across the network.

[0134] During the operation of the sponge construction, the memory capacity c is operated on at each iteration by a compression function designed to be irreversible and generate entropy (denoted in Figure 9 as f _c ). It is this function that produces the aggregate work cost (denoted in Figure 9 as ptx) that allows the blockchain network to behave as functional Oracle memory. This aggregate work cost is output as part of the thermo dynamic block to either the compute ring or the storage ring.

The penalty function

[0135] The penalty function is a general function that calculates both the heat (the calculated heat) after receiving information from the hash function and the size of the rate memory in the sponge construction after receiving information from the thermodynamic function. Figure 10 shows the design of the penalty function. The signal processes are the following:

• The penalty function receives as input from the hash function the parameters needed to calculate the heat (the calculated heat). For illustrative purposes we have displayed these as the time-dependent hash rate history and the number of iterations in the sponge construction, but in general these parameters could be anything (and the heat function can take any number of parameters). The heat is calculated and output to the thermodynamic function. It is also used to calculate the new value of the rate memory by comparison with the updated heat that is returned to the penalty function after being modified by the thermodynamic function that communicates with miner B.

• The verify parameter returned to the penalty function by the thermodynamic function is passed to the thermodynamic function, along with the updated value of the rate memory.

• The calculated heat and the updated heat are output to either the compute ring or the storage ring to provide a backup for later cross-checks.

The thermodynamic function

[0136] Figure 11 illustrates the thermodynamic function, with inputs and outputs relative to the other components in miner A and from miner B (large arrows) and the paths that these take within the thermodynamic function (smaller arrows) relative to the verify function and the mathematical equations that calculate the updated heat to bring the mining pair closer to thermodynamic balance. Shown also on the left-hand side is a pictorial representation of how the thermodynamic function moves the two mining nodes towards this balance - the colors here represent heat, with red being 'hot' (a high block processing speed) and blue being 'cold' (a low block processing speed) and intermediate colors between. The dots are a representation of the nodes and the graphs demonstrate the two states that are moved towards equilibrium via the action of the equations during the operation of the thermodynamic function, which are solved numerically.

[0137] The thermodynamic function is responsible for exchanging heat with miner B, and updating the heat to move the miner pair closer to thermodynamic balance. Figure 11 shows the design of the thermodynamic function. The signal processes are the following:

• The thermodynamic function takes as input the calculated heat from the penalty function and the start and end time of mining. It passes both to miner B. • The calculated heat of miner A is compared to the calculated heat of miner B and input to a differential equation.

• The differential equation works out the updated heat that moves miner A closer to thermodynamic equilibrium with miner B.

• This updated heat of miner A is output from the thermodynamic function to the penalty function.

The verify function

[0138] Figure 12 illustrates the verify function, with inputs and outputs relative to the other components within the thermodynamic function of miner A (large arrows), along with an example pictoral representation of the heat from miner B as a function of time and the mathematical equations that comprise the verification process of miner B's heat. This example pictorial representation of the behavior of the function is arbitrary and for illustrative purposes only.

[0139] The verify function is responsible for checking the gradient of the heat over the relevant time period and determining whether the heat has changed sufficiently gradually, in order to mitigate malicious behavior. It checks the heat of an external miner, in other words, the verify function in miner A checks the heat of miner B and vice versa. Figure 12 shows the design of the verify function. The signal processes for the verify function of miner A are the following:

• The heat from miner B as a function of time is input along with the start and the end time of a relevant time period (for illustrative purposes this is shown as the start and the end time of mining).

• The heat as a function of t is monitored and the gradient of this function is calculated from the moment that miner A is switched on (denoted as to). We divide this function into two intervals: the pre-mining interval and the mining interval.

• Provided that the gradient of this function during the pre-mining interval does not exceed a certain value, and the gradient during the mining interval does not exceed a certain value, the verify parameter is written as true, otherwise it is written as false.

• The pre-mining interval relative to the mining interval is determined from the propagation time of the heat through the network or a subset of the network. • The verify parameter for miner B is output to be sent back to miner B. The heat as a function of time of miner B is output to the next stage in the verify function of miner A to be used to work out the updated heat that moves miner A closer to thermodynamic balance with miner B.

[0140] An embodiment of the present invention relates to a computer storage product with a computer readable storage medium having computer code thereon for performing various computer-implemented operations. The media and computer code may be those specially designed and constructed for the purposes of the present invention, or they may be of the kind well known and available to those having skill in the computer software arts. Examples of computer-readable media include, but are not limited to: magnetic media such as hard disks, floppy disks, and magnetic tape; optical media such as CD-ROMs, DVDs and holographic devices; magneto-optical media; and hardware devices that are specially configured to store and execute program code, such as application-specific integrated circuits (“ASICs”), programmable logic devices (“PLDs”) and ROM and RAM devices. Examples of computer code include machine code, such as produced by a compiler, and files containing higher-level code that are executed by a computer using an interpreter. For example, an embodiment of the invention may be implemented using JAVA®, C++, or other object- oriented programming language and development tools. Another embodiment of the invention may be implemented in hardwired circuitry in place of, or in combination with, machine-executable software instructions.

[0141] The foregoing description, for purposes of explanation, used specific nomenclature to provide a thorough understanding of the invention. However, it will be apparent to one skilled in the art that specific details are not required in order to practice the invention. Thus, the foregoing descriptions of specific embodiments of the invention are presented for purposes of illustration and description. They are not intended to be exhaustive or to limit the invention to the precise forms disclosed; obviously, many modifications and variations are possible in view of the above teachings. The embodiments were chosen and described in order to best explain the principles of the invention and its practical applications, they thereby enable others skilled in the art to best utilize the invention and various embodiments with various modifications as are suited to the particular use contemplated. It is intended that the following claims and their equivalents define the scope of the invention.