Factom Protocol in Blockchain Environments

CROSS-REFERENCE TO RELATED APPLICATIONS

0001This application claims domestic benefit of U.S. Provisional Application No. 62/714,909 filed Aug. 6, 2018 and incorporated herein by reference in its entirety. This application relates to U.S. application Ser. No. 15/983,572 filed May 18, 2018 and incorporated herein by reference in its entirety. This application also relates to U.S. application Ser. No. 15/983,595 filed May 18, 2018 and incorporated herein by reference in its entirety. This application also relates to U.S. application Ser. No. 15/983,612 filed May 18, 2018 and incorporated herein by reference in its entirety. This application also relates to U.S. application Ser. No. 15/983,632 filed May 18, 2018 and incorporated herein by reference in its entirety. This application also relates to U.S. application Ser. No. 15/983,655 filed May 18, 2018 and incorporated herein by reference in its entirety.

BACKGROUND

0002In today's global economy trust is in rare supply. This lack of trust requires the devotion of a tremendous amount of resources to audit and verify records—reducing global efficiency, return on investment, and prosperity. Moreover, incidents such as the 2010 United States foreclosure crisis demonstrate that in addition to being inefficient, the current processes are also terribly inaccurate and prone to failure.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

The features, aspects, and advantages of the exemplary embodiments are understood when the following Detailed Description is read with reference to the accompanying drawings, wherein:

<figref idref="DRAWINGS">FIGS. 1-8</figref> illustrate a Factom protocol and system, according to exemplary embodiments;

<figref idref="DRAWINGS">FIGS. 9-21</figref> are simplified illustrations of a digital contract in a blockchain environment, according to exemplary embodiments;

<figref idref="DRAWINGS">FIGS. 22-24</figref> are more detailed illustrations of an operating environment, according to exemplary embodiments;

<figref idref="DRAWINGS">FIGS. 25-29</figref> illustrate a blockchain data layer, according to exemplary embodiments;

<figref idref="DRAWINGS">FIGS. 30-32</figref> further illustrate the digital contract, according to exemplary embodiments;

<figref idref="DRAWINGS">FIGS. 33-35</figref> illustrate an access mechanism, according to exemplary embodiments;

<figref idref="DRAWINGS">FIG. 36</figref> illustrates a public entity, according to exemplary embodiments;

<figref idref="DRAWINGS">FIGS. 37-40</figref> illustrate contractual execution, according to exemplary embodiments;

<figref idref="DRAWINGS">FIGS. 41-42</figref> illustrate virtual execution, according to exemplary embodiments;

<figref idref="DRAWINGS">FIG. 43</figref> illustrates cryptographic affinities, according to exemplary embodiments;

<figref idref="DRAWINGS">FIG. 44</figref> illustrates virtual assignments based on the blockchain data layer, according to exemplary embodiments;

<figref idref="DRAWINGS">FIGS. 45-51</figref> illustrate an architectural scheme, according to exemplary embodiments;

<figref idref="DRAWINGS">FIG. 52</figref> illustrates compliance scheme, according to exemplary embodiments;

<figref idref="DRAWINGS">FIGS. 53-59</figref> illustrate a decisional architecture and scheme, according to exemplary embodiments;

<figref idref="DRAWINGS">FIG. 60</figref> is a flowchart illustrating a method or algorithm for executing of digital contracts, according to exemplary embodiments; and

<figref idref="DRAWINGS">FIGS. 61-63</figref> depict still more operating environments for additional aspects of the exemplary embodiments.

DETAILED DESCRIPTION

0020The exemplary embodiments will now be described more fully hereinafter with reference to the accompanying drawings. The exemplary embodiments may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein. These embodiments are provided so that this disclosure will be thorough and complete and will fully convey the exemplary embodiments to those of ordinary skill in the art. Moreover, all statements herein reciting embodiments, as well as specific examples thereof, are intended to encompass both structural and functional equivalents thereof. Additionally, it is intended that such equivalents include both currently known equivalents as well as equivalents developed in the future (i.e., any elements developed that perform the same function, regardless of structure).

0021Thus, for example, it will be appreciated by those of ordinary skill in the art that the diagrams, schematics, illustrations, and the like represent conceptual views or processes illustrating the exemplary embodiments. The functions of the various elements shown in the figures may be provided through the use of dedicated hardware as well as hardware capable of executing associated software. Those of ordinary skill in the art further understand that the exemplary hardware, software, processes, methods, and/or operating systems described herein are for illustrative purposes and, thus, are not intended to be limited to any particular named manufacturer.

0022As used herein, the singular forms “a,” “an,” and “the” are intended to include the plural forms as well, unless expressly stated otherwise. It will be further understood that the terms “includes,” “comprises,” “including,” and/or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof. It will be understood that when an element is referred to as being “connected” or “coupled” to another element, it can be directly connected or coupled to the other element or intervening elements may be present. Furthermore, “connected” or “coupled” as used herein may include wirelessly connected or coupled. As used herein, the term “and/or” includes any and all combinations of one or more of the associated listed items.

0023It will also be understood that, although the terms first, second, etc. may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another. For example, a first device could be termed a second device, and, similarly, a second device could be termed a first device without departing from the teachings of the disclosure.

0024<figref idref="DRAWINGS">FIG. 1</figref> illustrates a distributed, autonomous Factom protocol, according to exemplary embodiments. The Factom protocol cost effectively separates any blockchain (such as the Bitcoin blockchain) from any cryptocurrency (such as the Bitcoin cryptocurrency). The Factom protocol provides client-defined Chains of Entries, client-side validation of Entries, a distributed consensus algorithm for recording the Entries, and a blockchain anchoring approach for security.

0025When Satoshi Nakamoto launched the Bitcoin blockchain he revolutionized the way transactions were recorded. There had never before existed a permanent, decentralized, and trustless ledger of records. Developers have rushed to create applications built on top of this ledger. Unfortunately, they have been running into a few core constraints intrinsic to the original design tradeoffs of Bitcoin.

00261) Speed—because of the design of the decentralized, proof-of-work consensus method used by Bitcoin, difficulty requirements are adjusted to maintain roughly 10 minute confirmation times. For applications that wish greater security, multiple confirmations may be required. A common requirement is to wait for 6 confirmations, which can lead to wait times over an hour. <ul id="ul0001" list-style="none"><li id="ul0001-0001" num="0000"><ul id="ul0002" list-style="none"><li id="ul0002-0001" num="0027">2) Cost—the default transaction cost is around 0.01 mBTC (roughly $0.003 USD in November 2014, and as much as $80 USD per transaction at times in 2017). The exchange price of BTC has been volatile throughout its history. If the price of BTC rises, then the cost of transactions can go up. This can prove to be a serious cost barrier to applications that need to manage very large numbers of transactions. Additionally, many factors including constraints on block size and reward halving could act to increase transaction fees.</li><li id="ul0002-0002" num="0028">3) Bloat—with the Bitcoin blockchain size limit of 1 MB per block, transaction throughput is capped at <b>7</b> transactions per second. Any application that wants to write and store information using the blockchain will add to the traffic. This problem has become politically charged as various parties seek to increase the block size limit and are met with resistance from those concerned about decentralization. <br /> Factom is a protocol designed to address these three core constraints. Factom creates a protocol for Applications that provide functions and features beyond currency transactions. Factom constructs a standard, effective, and secure foundation for these Applications to run faster, cheaper, and without bloating Bitcoin. </li></ul></li></ul>

0029Once the system is set up, including issuance of Factoids (i.e., the cryptocurrency of Factom) and user accounts, token value is transferred among users, Factom, and Bitcoin with the following primary interactions:

00301. Application Owner purchases Entry Credits with Factoid

00312. Application records an Entry

00323. Factom Servers create Entry Blocks and Directory Blocks

00334. Factom secures an anchor (hash of the Directory Block) onto the blockchain

0000Details of these and other interactions are in the upcoming sections.

0034The Factom protocol secures entries. Factom extends Bitcoin's feature set to record events outside of monetary transfers. Factom has a minimal ruleset for adding permanent Entries. Factom pushes most data validation tasks to the client side. The only validation Factom enforces are those required by the protocol to trade Factoids, convert Factoids to Entry Credits, and to ensure Entries are properly paid for and recorded. <ul id="ul0003" list-style="none"><li id="ul0003-0001" num="0000"><ul id="ul0004" list-style="none"><li id="ul0004-0001" num="0035">Factom has a few rules regarding token incentives for running the network and for internal consistency, but Factom may or may not check the validity of statements recorded in the chains used by its users.</li></ul></li></ul>

0036Bitcoin limits transactions to those moving value from a set of inputs to a set of outputs. Satisfying the script required of the inputs (generally requiring certain signatures) is enough for the system to ensure validity. This is a validation process that can be automated, so the auditing process is easy. If Factom were used, for instance, to record a deed transfer of real estate, Factom would be used to simply record the process occurred. The rules for real estate transfers are very complex. For example, a local jurisdiction may have special requirements for property if the buyer is a foreigner, farmer, or part time resident. A property might also fall into a number of categories based on location, price, or architecture. Each category could have its own rules reflecting the validation process for smart contracts. In this example, a cryptographic signature alone is insufficient to fully verify the validity of a transfer of ownership. Factom then is used to record the process occurred rather than validate transfers.

0037Bitcoin miners perform two primary tasks. First, they resolve double spends. Seeing two conflicting transactions that spend the same funds twice, they resolve which one is admissible. The second job miners perform (along with the other full nodes) is auditing. Since Bitcoin miners only include valid transactions, one that is included in the blockchain can be assumed to have been audited. A thin client does not need to know the full history of Bitcoin to see if value they receive has already been spent.

0038Factom splits the two roles that Bitcoin miners do into two tasks: 1—recording Entries in a final order and 2—auditing Entries for validity. <ul id="ul0005" list-style="none"><li id="ul0005-0001" num="0000"><ul id="ul0006" list-style="none"><li id="ul0006-0001" num="0039">1—The Factom servers accept Entries, assemble them into blocks, and fix their order. After 10 minutes, the Entry ordering is made irreversible by inserting an anchor into the Bitcoin blockchain. Factom does this by creating a hash of the data collected over the 10 minutes, then recording the hash into the blockchain.</li><li id="ul0006-0002" num="0040">2—The auditing of Entries is a separate process which can be done either with or without trust. Auditing is critical, since Factom is not able to validate Entries before they are included in the Factom dataset.</li></ul></li></ul>

0041With trust-based auditing, a thin client could trust a competent auditor they choose. After an Entry was entered into the system, an auditor would verify the Entry was valid. Auditors would submit their own cryptographically signed Entry. The signature would show that the Entry passed all the checks the auditor deemed was required. The audit requirements could in fact be part of a Factom Chain as well. In the real estate example from earlier, the auditor would double check the transfer conformed to local standards. The auditor would publicly attest that the transfer was valid.

0042Trustless auditing would be similar to Bitcoin. If a system is internally consistent with a mathematical definition of validity like Bitcoin, it can be audited programmatically. If the rules for transfer were able to be audited by a computer, then an Application could download the relevant data and run the audit itself. The application would build an awareness of the system state as it downloaded, verified, and decided which Entries were valid or not.

0043Mastercoin, Counterparty, and Colored Coins have a similar trust model. These are all client-side validated protocols, meaning transactions are embedded into the Bitcoin blockchain. Bitcoin miners do not audit them for validity; therefore, invalid transactions designed to look like transactions on these protocols can be inserted into the blockchain. Clients that support one of these protocols scan through the blockchain and find potential transactions, check them for validity, and build an interpretation of where the control of these assets lie (usually a Bitcoin address). It is up to the clients to do their own auditing under these protocols.

0044Moving any of these client-side validated protocols under Factom would be a matter of defining a transaction per the protocol and establishing a Chain to hold the transactions. The transaction protocols wouldn't be much different under Factom than under Bitcoin, except where Factom allows an easy expression of the information needed instead of having to encode it in some special way into a Bitcoin transaction.

0045Bitcoin, land registries, and many other systems need to solve a fundamental problem: proving a negative. They prove some “thing” has been transferred to one person, and prove that thing hasn't been transferred to someone else. While proof of the negative is impossible in an unbounded system, it is quite possible in a bounded system. Blockchain based cryptocurrencies solve this problem by limiting the places where transactions can be found. Bitcoin transactions can only be found in the Bitcoin blockchain. If a relevant transaction is not found in the blockchain, it is defined from the Bitcoin protocol perspective not to exist and thus the BTC hasn't been sent twice (double spent).

0046Certain land ownership recording systems are similar. Assume a system where land transfer is recorded in a governmental registry and where the legal system is set up so that unrecorded transfers are assumed invalid (sans litigation). If an individual wanted to check if a title is clear (i.e., that no one else claims the land) the answer would be in the governmental registry. The individual using the government records could prove the negative; the land wasn't owned by a third party. Where registration of title is not required, the governmental registry could only attest to what has been registered. A private transfer might very well exist that invalidates the understanding of the registry.

0047In both of the above cases, the negative can be proven within a context. With Mastercoin the case is very strong. With a land registry, it is limited to the context of the Registry, which may be open to challenge. The real world is messy, and Factom is designed to accommodate not just the precision of digital assets, but the real world's sometimes messy reality.

0048In Factom, there is a hierarchy of data categorization. Factom only records Entries in Chains; the various user-defined Chains have no dependencies that Factom enforces at the protocol level. This differs from Bitcoin, where every transaction is potentially a double-spend, and so it must be validated. By organizing Entries into Chains, Factom allows Applications to have smaller search spaces than if all Factom data were combined together into one ledger.

0049If Factom were to be used to manage land transfers, an Application using a Chain to record such registries could safely ignore Entries in the other Chains, such as those used to maintain security camera logs. Were a governmental court ruling to change a land registration, the relevant Chain would be updated to reflect the ruling. The history would not be lost, and where such changes are actually invalid from a legal or other perspective, the record cannot be altered to hide the order of events in Factom.

0050Factom may or may not validate Entries; Entries are instead validated client-side by users and Applications. As long as an Application understands and knows the rules a Chain should follow, then the existence of invalid Entries doesn't cause unreasonable disruption. Entries in a Chain that do not follow the rules can be disregarded by the Application.

0051Users can use any set of rules for their Chains, and any convention to communicate their rules to the users of their Chains. The first Entry in a Chain can hold a set of rules, a hash of an audit program, etc. These rules then can be understood by Applications running against Factom to ignore invalid Entries client-side.

0052An enforced sequence can be specified. Entries that do not meet the requirements of the specified enforced sequence will be rejected. However, Entries that might be rejected by the rules or the audit program will still be recorded. Users of such chains will need to run the audit program to validate a chain sequence of this type. The Factom servers will not validate rules using the audit program.

0053Validation in the Applications (in combination with user-defined Chains) provides a number of advantages for Applications written on top of Factom: <ul id="ul0007" list-style="none"><li id="ul0007-0001" num="0000"><ul id="ul0008" list-style="none"><li id="ul0008-0001" num="0054">1) Applications can put into Factom whatever Entries make sense for their application. So, a list of hashes to validate a list of account statements can be recorded as easily as exchanges of an asset.</li><li id="ul0008-0002" num="0055">2) Rule execution is very efficient. Where the distributed network must execute your validation rules, then validation requires all nodes to do all validation. Client-side validation only requires the systems that care about those rules to run them. Factom allows a Chain to define its rules in whatever language the designers choose, to run on whatever platform they choose, and to use any external data. None of these decisions on the part of one Application has any impact on another Application.</li><li id="ul0008-0003" num="0056">3) Factom Servers have little knowledge about the Entries being recorded. We use a commitment scheme to limit knowledge, where the commitment to record an Entry is made prior to revealing what the Entry is. This makes Factom's role in recording Entries very simple, and makes individual server processes public. Factom servers accept information from the network of full nodes, and their decisions and behavior are in view. Failure to perform can be audited both from the network outside Factom, and within Factom. It is easy to independently verify that a Factom server is fulfilling its Entry-recording responsibility; Factom can't hide potentially errant behavior.</li><li id="ul0008-0004" num="0057">4) Recording speeds can be very fast, since the number of checks made by the Factom servers are minimal.</li><li id="ul0008-0005" num="0058">5) Proofs against any particular Chain in Factom do not require knowledge of any other Chains. Users then only need the sections of Factom they are using and can ignore the rest.</li></ul></li></ul>

0059At its heart, Factom is a decentralized way to collect, package, and secure data into the Bitcoin blockchain. Factom accomplishes this with a network of Authority servers. Authority Servers are the set of Federated Servers and Audit Servers which share responsibility for different aspects of the system. The Federated Servers actually acknowledge and order entries and transactions in Factom, and Audit Servers duplicate and audit the work done by the Federated Servers and are always ready to replace a Federated Server that might go offline.

0060The design ensures decentralization. No single server is ever in control of the whole system, but only a part of the system. All servers verify and double check the work of all other servers. And no server is permanently in control of any part of the system; the responsibility for each part of Factom cycles among the Federated Servers each minute, and the role of being a Federated Server or an Audit Server shifts among the servers in the Authority Set (the set of all Authority Servers).

0061The Federated servers take a very active role in running the protocol. The Federated servers each take responsibility for a subsection of the user Chains at the beginning of the creation of a Directory Block. The process works like this: <ul id="ul0009" list-style="none"><li id="ul0009-0001" num="0000"><ul id="ul0010" list-style="none"><li id="ul0010-0001" num="0062">1. All servers reset their process lists to empty.</li><li id="ul0010-0002" num="0063">2. The user submits an Entry Payment using a public key associated with Entry Credits</li><li id="ul0010-0003" num="0064">3. Based on the public key used to pay for the Entry, one of the servers accepts the payment.</li><li id="ul0010-0004" num="0065">4. That server broadcasts the acceptance of the payment.</li><li id="ul0010-0005" num="0066">5. The user sees the acceptance and submits the Entry.</li><li id="ul0010-0006" num="0067">6. Based on the ChainID of the Entry, one of the servers adds the Entry to its process list, and adds the Entry to the appropriate Entry Block for that ChainID (creating one if this is the first Entry for that Entry Block).</li><li id="ul0010-0007" num="0068">7. The server broadcasts an Entry confirmation, containing the process list index of the Entry, the hash of the Entry (linked to the payment), and the serial hash so far of the server's process list.</li><li id="ul0010-0008" num="0069">8. All the other servers update their view of the server's process list, validate the list, and update their view of the Entry Block for that ChainID.</li><li id="ul0010-0009" num="0070">9. As long as the user can validate the relevant process list holds their Entry, then they have a fair level of assurance it will be successfully entered into Factom.</li><li id="ul0010-0010" num="0071">10. At the end of the minute, each server confirms the end of their section of the process list. The end of the minute is marked in the process list, and the responsibility for particular chains shifts around the authority set.</li><li id="ul0010-0011" num="0072">11. At the end of the 10th minute, a Directory Block is constructed from all the Entry Blocks defined by the process lists built by all the servers. So, each server has all Entry Blocks, all Directory Blocks, and all Entries.</li><li id="ul0010-0012" num="0073">12. A deterministic method (that can be computed by all nodes in protocol) will shift responsibility for particular ChainIDs among the servers for the next round.</li><li id="ul0010-0013" num="0074">13. At the completion of the Directory Block, the Merkle root of the Directory block is placed in a Bitcoin transaction and submitted to the Bitcoin network for eventual confirmation.</li><li id="ul0010-0014" num="0075">14. Repeat. (Go back to 1)</li></ul></li></ul>

0076The Federated servers for their minute are constructing a process list for the Chains for which they are responsible, as well as constructing the Entry Blocks that will be used to create the Directory Block at the end of the 10 minutes. The process list is important for broadcasting decisions made by a server to the rest of the network.

0077The servers in the authority set are re-ranked on a regular, scheduled basis. The ranking is a function of support by the standing parties, who must create a profile Chain in Factom. The profile contains any number of signed public address Entries. The weight of a standing party's support is determined by various public addresses and entries in their profile. The function computing the weight of a standing party uses a combination of many factors. Such weights may be organized in categories to further distribute influence. Factors that determine an identity's weight include factors that can be measured from the protocol, and audited by the protocol. Examples of factors that might be used to calculate weight include: <ul id="ul0011" list-style="none"><li id="ul0011-0001" num="0000"><ul id="ul0012" list-style="none"><li id="ul0012-0001" num="0078">Weighted Number of Entry Credits purchased.</li><li id="ul0012-0002" num="0079">Weighted Number of Entries used.</li><li id="ul0012-0003" num="0080">Tokens “staked” to a profile Chain, and not moved or transferred.</li><li id="ul0012-0004" num="0081">Tokens used to build infrastructure, support the protocol, provide services</li><li id="ul0012-0005" num="0082">Providing guidance and facilitating the operation of the protocol.</li></ul></li></ul>

0083Support may be specified by the Standing parties at any time. At regular intervals, the support of all the servers in the Authority set will be evaluated, and the membership of the authority set adjusted. The same mechanism can be used to measure support in the protocol for decisions about the protocol.

0084To maintain a position in the authority set, servers must continually demonstrate the ability to maintain their ability to monitor and keep up with the operation of the protocol. The Federated Servers do this by simply doing their job and syncing with the end of minute operations with all other Federated Servers. Performance in the protocol's ecosystem may also factor into decisions to support or not support an authority node. Audit servers may have to issue a heartbeat message, that can be monitored by the network. Other solutions are possible.

0085Managing timeouts and monitoring heartbeats will be done according to the needs and load on the protocol.

Factom System Overview

0086<figref idref="DRAWINGS">FIG. 3</figref> illustrates the Factom protocol as a set of layered data structures, according to exemplary embodiments. Factom is constructed of a hierarchical set of blocks, with the highest being Directory Blocks. They constitute a micro-chain, consisting primarily of compact references. To keep the size small, each reference in the Directory Block is just a hash of the Entry Block plus its ChainID. These Entry Blocks have references which point to all the Entries with a particular ChainID which arrived during a time period. The Entry Block for a Chain ID is also part of a micro-chain. The bulk of the data in Factom is at the leaves, the Entries themselves. These hierarchical data structures are rendered unchangeable by Bitcoin's hashpower. They can be conceptualized as different layers. The layers and concepts in the Factom system are:

00871) Directory Layer—Organizes the Merkle Roots of Entry Blocks

00882) Entry Block Layer—Organizes references to Entries

00893) Entries—Contains an Application's raw data or a hash of its private data

00904) Chains—Grouping of Entries specific to an Application

Directory Layer: How the Directory Layer Organizes Merkle Roots

0091The Directory layer is the first level of hierarchy in the Factom system. It defines which Entry ChainIDs have been updated during the time period covered by a Directory Block. (ChainIDs identify the user's Chain of Entries; the generation of the ChainID is discussed later.) It mainly consists of a list pairing a ChainID and the Merkle root of the Entry Block containing data for that ChainID.

0092Each Entry Block referenced in the Directory Block takes up 64 bytes (two 32 byte hashes, the ChainID and the Merkle root of the Entry Block). A million such Entries would result in a set of Directory Blocks roughly 64 MB in size. If the average Entry Block had 5 Entries, 64 MB of Directory Blocks would provide the high level management of 5 million distinct Entries. Note that the exact implementation of Directory blocks my vary as we build for greater scale in the future.

0093If an Application only has the Directory Blocks, it can find Entry Blocks it is interested in without downloading every Entry Block. An individual Application would only be interested in a small subset of ChainIDs being tracked by Factom. This greatly limits the amount of bandwidth an individual client would need to use with Factom as their system of record. For example, an Application monitoring real estate transfers could safely ignore video camera security logs.

0094Factom servers collect Merkle roots of Entry Blocks and package them into a Directory Block. Directory Block the Merkle roots are recorded into the Bitcoin blockchain. This allows the most minimum expansion of the blockchain, and still allows the ledger to be secured by the Bitcoin hash power. The process of adding the Merkle root into the Bitcoin blockchain we referred to as “anchoring”. See the section “Appendix: Timestamping into Bitcoin” for further details.

0095Data entered into Directory Blocks is the most expensive, from a bandwidth and storage perspective. All users of Factom wishing to find data in their Chains need the full set of Directory Blocks starting from when their Chain began.

0096Activities that increase the Directory Block size include the creation and first update of individual Chains. These activities externalize costs of Applications attempting finer-grained organization.

0097The Applications must be required to expend more Entry Credits than a simple Entry would necessitate to discourage bloating the Directory Blocks.

Entry Block Layer: How the Entry Block Layer Organizes Hashes and Data

0098<figref idref="DRAWINGS">FIG. 4</figref> illustrates entry blocks of the Factom protocol, according to exemplary embodiments. Entry Blocks are the second level of hierarchy in the system. Individual Applications will pay attention to various ChainIDs. Entry Blocks are the place where an Application looking for Entries can expand its search from a ChainID to discover all possibly relevant Entries.

0099There is one Entry Block for each updated ChainID per Directory Block. The Entry Blocks contain hashes of individual Entries. The hashes of Entries both prove the existence of the data and give a key to find the Entries in a Distributed Hash Table (DHT) network. (See the below explanation of the “Factom Peer-to-Peer Network” for more detail.)

0100The Entry Blocks encompass the full extent of possible Entries related to a ChainID. If an Entry is not referred to in an Entry Block, it can be assumed not to exist. This allows an Application to prove a negative, as described in the section Security and Proofs.

0101The Entry Block intentionally does not contain the Entries themselves. This allows the Entry Blocks to be much smaller than if all the data was grouped together. Separating the Entries from the Entry Blocks also allows for easier auditing of auditors. An auditor can post Entries in a separate chain that approves or rejects Entries in a common chain. The audit can add reasons for rejection in its Entry. If an Application trusts the auditor, they can cross reference that the auditor has approved or rejected every Entry, without knowing what the Entry is. The Application would then only attempt to download the Entries which passed the audit. Multiple auditors could reference the same Entries, and the Entries would only exist once on the Distributed Hash Table (DHT). Entries are expected to be significantly larger than the mere 32 bytes a hash takes up. Lists of things to ignore do not have to have the full object being ignored for an Application to know to ignore it. The exact implementation of entry blocks may vary in the future in response to identified improvements possible in the protocol.

0102An Entry detailing the specifics of a land transfer would be entered into a Chain where land transfers of that type are expected to be found. One or more auditors could then reference the hashes of land transfer in their own Chains, adding cryptographic signatures indicating a pass or fail. The land transfer document would only need to be stored once, and it would be referenced by multiple different Chains.

0103<figref idref="DRAWINGS">FIG. 5</figref> illustrates how entries are created, according to exemplary embodiments. Entries are constructed by users and submitted to Factom. By hashing or encoding information, the user can ensure the privacy of Entries. The Entries can instead be plain text if encoding or obscuring the data isn't necessary. By recording a hash of a document, Factom can provide basic proof of publication. Presenting the document at a later time allows one to create its hash, and compare it to the hash recorded in the past.

0104There is lots of flexibility in the data that is accepted. It can be something short like a hyperlink. It could also be larger, but not too large, since fees limit the size of the data accepted. This is similar to Bitcoin. Large 100 kB+ Bitcoin transactions are possible, but would need to pay a proportionately greater transaction fee. This size, while gigantic in Bitcoin, would be moderately sized for Factom. Since every Bitcoin full node needs the entire blockchain to fully validate, it needs to stay small. In Factom, only the highest level Directory Blocks are required to fully validate a Chain. If someone is not specifically interested in a Chain's data, they would not download it.

0105Take a simple example of an uneditable Twitter-like system. A celebrity would craft an Entry as a piece of text. They would then sign it with a private key to show it came from them. Followers of the celebrity would find which Chain they publish in and would monitor it for updates. Any new signed Entries would be recognized by follower's Application software as a tweet. Others could tweet at the celebrity by adding Entries to the celebrity's Chain.

0106<figref idref="DRAWINGS">FIG. 6</figref> illustrates the complete Factom protocol and system, according to exemplary embodiments. Chains in Factom are sequences of Entries that reflect the events relevant to an Application. These sequences are at the heart of Bitcoin 2.0. Chains document these event sequences and provide an audit trail recording that an event sequence occurred. With the addition of cryptographic signatures, those events would be proof they originated from a known source.

0107Chains are logical interpretations of data placed inside Directory Blocks and Entry Blocks. The Directory Blocks indicate which Chains are updated, and the Entry Blocks indicate which Entries have been added to the Chain. This is somewhat analogous to how Bitcoin full clients maintain a local idea of the UTXO (Unspent Transaction Output) set. The UTXO set is not (currently) in the blockchain itself, but is interpreted by the full client.

The Factom Peer-to-Peer Network

0108Factom will have a peer-to-peer (P2P) network which accomplishes two goals: communication and data preservation.

Factom Peer-to-Peer Communications

0109Factom will have a P2P network very similar to Bitcoin's. It will consist of full nodes which have all the Factom data. The full nodes create a gossip network which will flood fill valid data throughout the network. The Authority servers would be full nodes, but not all full nodes are Authority servers. This is very much like Bitcoin, where miners are full nodes, but not all full nodes are miners. This will limit the ability to DDOS the Authority servers individually. They can connect anywhere inside the network to acquire the data needed to build the data structures.

0110As the servers are coming to consensus and disseminate their signed data, they would publish the data over the P2P network. The P2P flood filling also limits the ability of Authority servers to censor based on IP addresses, since valid traffic is mixed together by the nodes they connect to. It also helps to prevent censorship, since all servers can see the Entries which should be included in the Entry Blocks. Outside organizations campaigning to become Authority servers have an incentive to bring bad behavior to light, so they can gain support and move up into the set of Authority Servers.

Data Preservation and Dissemination

0111Factom data structures (Directory Blocks, Entry Blocks, Entries) are needed for Factom to be useful. They are public and will be preserved in two places. The Authority Servers need to maintain this data to make correct decisions about adding new Entries. Since they have this data, they can provide it as a service, as part of being a full node. As the protocol grows the protocol will be able to support partial nodes, which share only part of the Factom dataset. The partial nodes could share only the data which is relevant to their specific application. Peer discovery for the partial nodes may be handled by any sort of directory service, such as a Distributed Hash Table (DHT).

0112<figref idref="DRAWINGS">FIG. 7</figref> illustrates a read operation, according to exemplary embodiments. This setup allows for efficient peer distribution of data even if the entire Factom dataset grows to unwieldy sizes. The Directory Service also allows the data to be preserved independent of any Authority servers or full nodes. Even if all the full nodes were removed from the network, the data could still be shared by a more numerous set of parties interested in specific subsets of the data.

0113<figref idref="DRAWINGS">FIG. 8</figref> further illustrates the Chain ID, according to exemplary embodiments. Factom groups all Entries under a ChainID. The ChainID is computed from a Chain Name. The ChainID is a hash of the Chain Name. The Chain Name is a byte array arbitrarily long in length. See figure below. Since the conversion from Chain Name to ChainID is a hash operation, it is a simple process. Deriving a Chain Name from a ChainID is not simple, so a lookup table would be needed.

0114The user may provide a Chain Name, or the Chain Name may be auto-generated. Regardless, that the ChainID can be shown to be a hash of something. This prevents unhashed data from being a ChainID, which is stored all the way up to the Directory Blocks. This convention eliminates insertion of obscene plaintext in the block structure.

0115The Chain Name is fairly arbitrary. It could be a random number, a string of text, or a public key. An individual Application could derive meaning from different Chain Names.

0116One possible convention would be to use human readable text for the Chain Name. This would allow for the structuring of Chains in a logical hierarchy, even though Chains are not hierarchical by nature. Users can even use the same naming conventions, but by making simple modifications, ensure that there are no accidental intersections between their Chains and other Chains. Consider the following path: <ul id="ul0013" list-style="none"><li id="ul0013-0001" num="0000"><ul id="ul0014" list-style="none"><li id="ul0014-0001" num="0117">MyFavoriteApp/bin, <br /> where the slash is a convention for another level of hierarchy. The slash separating ASCII strings “MyFavoriteApp” and “bin” represents transitioning to a deeper level. These two strings must be converted to bytes, and there are many options for doing so. The strings could be encoded in UTF-16, UTF-32, ASCII, or even something like IBM's EPCDIC. Each of these encodings would result in entirely different ChainIDs for the same string, since the computation of the ChainID is done from the bytes. Furthermore, the application could utilize a Globally Unique IDentifier (GUID) number as the first byte array in their naming convention. This would eliminate overlap of one Application's ChainID “space” with another, at the expense of just a few more bytes in the Chain creation. </li></ul></li></ul>

Using Factoids to Purchase Entry Credits

0118Factoids are the main internal scarcity token used to moderate and reward the system actors. The right to put Entries into Factom is represented by Entry Credits. Factom separates the two value-holding mechanisms, as they serve different purposes. Factoids can be converted into Entry Credits, but not vice versa.

0119Factoids are implemented in much the same way Bitcoin is implemented, allowing multiple inputs, multiple outputs, etc. where each input requires the proper signature for the transaction to be valid. Other sorts of validation including multisig is possible. Factoid transactions are managed on a special Factoid Chain. This Factoid Chain is handled more restrictively than other Chains. Entries in the Factoid Chain must be valid Factoid transactions, or the Factom Servers will reject the Entries.

0120Factoids are included into the protocol to completely decentralize Factom, and to reduce bloat and spam in both Factom and Bitcoin. Factoids can be converted to Entry Credits in the protocol, and paid out to Factom servers from the protocol. Factoids budgeted but not paid out can remain in a “grant pool”. These tokens can be issued to support and develop the protocol from the protocol.

0121Factoids also help to bind consensus. If consensus is lost, then the Factoids will fall in value, incentivizing the support of the protocol.

0122The conversion of a Factoid to Entry Credits will be done via a special purchase transaction on the Factoid Chain. This purchase transaction will include: <ul id="ul0015" list-style="none"><li id="ul0015-0001" num="0000"><ul id="ul0016" list-style="none"><li id="ul0016-0001" num="0123">An Output directing a Factoid amount to be converted</li><li id="ul0016-0002" num="0124">The public key that is to receive the Entry Credits <br /> The Entry Credits, once purchased, cannot be transferred to another public key. They can only be used to pay for Entries. This greatly reduces their value to thieves, since they cannot be resold. Entry Credit private keys can be held in low security areas with minimal risk. </li></ul></li></ul>

Using Entry Credits to Write Entries

0125Adding Entries into Factom requires giving up a scarce resource. That resource is Entry Credits, which are derived from Factoids. Adding Entries to Factom is a two step process. First the Entry is paid for (committed). The payment accomplishes two things. It decrements the Entry Credits associated with a user's public key. In the same operation, the hash of the Entry is specified. After the Entry is paid for, the server will wait for the unhashed Entry and include it once seen (revealed).

01261. Pay for Entry <ul id="ul0017" list-style="none"><li id="ul0017-0001" num="0000"><ul id="ul0018" list-style="none"><li id="ul0018-0001" num="0127">Decrement Entry Credits owned by a user</li><li id="ul0018-0002" num="0128">User specifies hash of Entry in payment</li></ul></li></ul>

01292. Insert Entry <ul id="ul0019" list-style="none"><li id="ul0019-0001" num="0000"><ul id="ul0020" list-style="none"><li id="ul0020-0001" num="0130">User publishes Entry for inclusion in Entry Block</li></ul></li></ul>

0131There are many benefits of this two step process. One benefit is to separate the payment overhead from the recorded data. Future users will not be forced to download the data generated by payment minutia. They only need to download the minimum data to validate their system. It allows users to safely and easily ignore the payment information.

0132Another benefit is censorship resistance. By committing to accept an Entry before knowing the content makes censorship by the Factom servers obvious. Adam Back has advocated for a similar mechanism for Bitcoin in a post titled “Blind Symmetric Commitment for Stronger Byzantine Voting Resilience” (https://bitcointalk.org/index.php?topic=206303.0). If a user or Audit server can show an Entry which has been properly been paid for, but none of the Federated servers are accepting it, then the censorship is provable.

0133The transactions deducting Entry Credits will be recorded in a special Chain, similar to the Factoid Chain. The Federated servers will only fill the Chain with valid Entry Credit transactions.

0000Setting the Cost of Entries with a Central Server Oracle

0134The conversion rate of Factoids to Entry Credits will be determined by first choosing a target real world value for an Entry Credit. This target will be determined by a distributed and autonomous process. At minimum it will be agreed upon by some process driven by the Authority Set. Other parties might be involved through various auditable processes in Factom to further decentralize the decision.

0135Once a target real world target price of an Entry Credit has been chosen, an Oracle is required to record into Factom the conversion value between Factoids and that EC price. That specification and implementation will also go through a decentralized decision process. The actual implementation of the target price, oracle implementation, and exchange rate adjustment can vary widely, but will be optimized for decentralization, security, and regulatory compliance.

0136Note that fee calculations and rates are subject to change, and don't materially impact the utility of the Factom protocol.

0000Using Factom without Factoids

0137Many users of Factom may not want a wallet, and will not want to hold any cryptocurrency asset. But they will want to create their Chains (ledgers) and add their Entries. Factom's two step recording process allows for the separation of Factoids, Factom's tradable token, from the opportunity to post Entries to Factom, represented by Entry Credits. Servers and other recipients of Factom Tokens can sell Entry Credits to customers for payment via Bitcoin, conventional credit card payments, etc. The user would provide a public key to hold the Entry Credits. The seller would convert the appropriate amount of Factoids to Entry Credits and assign those rights to the user's public key. Users could thus buy Entries Credits for Factom without ever owning the Factoids that drive the Factom servers.

0138From a regulation point of view, this is powerful. The servers earn Factoids from the protocol. The only parties to that transaction are the server and the protocol. Then the server sells Entry Credits to users, who eventually return Factoids to the rest of the system. Entry Credits are non transferable, so the user cannot assign them to another user's public key, and selling private keys isn't practical or useful. In neither transaction is a tradable token (the Factoid) transferred between two parties.

0139Factom is a distributed, autonomous layer residing on top of the Bitcoin blockchain. The goal of Factom is to provide the power of Bitcoin's blockchain to a nearly unlimited range of Applications and uses. Further, Factom is architected such that its users do not need any cryptocurrency whatsoever.

0140A distributed, immutable ledger is the radical, foundational, and unprecedented technology represented by the Bitcoin blockchain. The dream of many is to extend the honesty inherent to an immutable ledger validated by math to chaotic, real-world interactions. By allowing the construction of unbounded ledgers backed by the blockchain, Factom extends the benefits of the blockchain to the real world.

0141<figref idref="DRAWINGS">FIGS. 9-21</figref> are simplified illustrations of a digital contract <b>20</b> in a blockchain environment <b>22</b>, according to exemplary embodiments. The digital contract <b>20</b> is sometimes referred to as a self-executing or “smart” contract between parties to a transaction. The digital contract <b>20</b> may be executable code that runs on a blockchain <b>24</b>. The blockchain <b>24</b> has one or more blocks <b>26</b> of data. A conventional smart contract facilitates, executes, and/or enforces the terms of an agreement. Whatever the terms, the digital contract <b>20</b> may automatically execute the terms once predetermined logical rules, conditions, or code is satisfied. The digital contract <b>20</b> may thus be expressed in a programming language. Smart contracts are generally known, so this disclosure will not dwell on the known aspects.

0142Here, though, the blockchain <b>24</b> need only reference the digital contract <b>20</b>. That is, the actual programming language defining the digital contract <b>20</b> need not be included within or attached to the blockchain <b>24</b>. Instead, the blockchain <b>24</b> need only include or specify a contract identifier <b>28</b> and perhaps one or more contractual parameters <b>30</b>. The contract identifier <b>28</b> is any digital identifying information that uniquely identifies or references the digital contract <b>20</b>. Similarly, the contractual parameters <b>30</b> may digitally identify the parties to the digital contract <b>20</b>, their respective performance obligations and terms, and even consideration. So, instead of the blockchain <b>24</b> carrying or conveying the actual code representing the digital contract <b>20</b>, exemplary embodiments need only specify the contract identifier <b>28</b> and perhaps the contractual parameters <b>30</b>. The blocks <b>26</b> of data within the blockchain <b>24</b> are thus not burdened with the programming code that is required to execute the digital contract <b>20</b>. The blockchain <b>24</b> need only include or specify the contract identifier <b>28</b> and/or the contractual parameters <b>30</b> (or their respective hash values), thus greatly simplifying the blockchain <b>24</b> and reducing its size (in bytes) and processing requirements.

0143<figref idref="DRAWINGS">FIG. 10</figref> further illustrates the blockchain <b>24</b>. Here any entity <b>32</b> may generate the blockchain <b>24</b>. While exemplary embodiments may be applied to any entity <b>32</b>, most readers are thought familiar with financial services. That is, suppose the entity <b>32</b> is a bank, lender, or other financial institution <b>34</b> (such as PIMCO®, CITI, or BANK OF AMERICA®). As the reader likely understands, the financial institution <b>34</b> creates a massive amount of banking records, transaction records, mortgage instruments, and other private data <b>36</b>. The financial institution <b>34</b> thus has a financial server <b>38</b> executing a software application <b>40</b> that encrypts its private data <b>36</b>. While the software application <b>40</b> may use any encryption scheme, <figref idref="DRAWINGS">FIG. 2</figref> illustrates the private blockchain <b>24</b>. That is, the software application <b>40</b> causes the financial server <b>38</b> to cryptographically hash the private data <b>36</b> and to integrate the resulting hash value(s) into the block <b>26</b> of data within the private blockchain <b>24</b>. Moreover, because the private data <b>36</b> may represent contractual obligations between parties, the software application <b>40</b> may further cause the blockchain <b>24</b> to include the contract identifier <b>28</b> and the contractual parameters <b>30</b>. The contract identifier <b>28</b> and the contractual parameters <b>30</b> may be encoded as data or information contained within the block <b>26</b> of data, or the contract identifier <b>28</b> and the contractual parameters <b>30</b> may be data or information that is separate from the block <b>26</b> of data (such as informational content in metadata or in a packet header/body). Regardless, the blockchain <b>24</b> need not include the programming code representing the digital contract <b>20</b>. The blockchain <b>24</b> need only specify the contract identifier <b>28</b> and/or the contractual parameters <b>30</b>.

0144<figref idref="DRAWINGS">FIG. 11</figref> illustrates a contract server <b>42</b>. The contract server <b>42</b> may be responsible for executing the digital contract <b>20</b> referenced by the contract identifier <b>28</b> and/or the contractual parameters <b>30</b>. For example, after the financial server <b>38</b> (executing the software application <b>40</b>) generates the block <b>26</b> of data within the blockchain <b>24</b>, the financial server <b>38</b> may send the blockchain <b>24</b> to the network address (e.g., Internet protocol address) associated with the contract server <b>42</b>. When the contract server <b>42</b> receives the blockchain <b>24</b>, the contract server <b>42</b> inspects the blockchain <b>24</b> to identify the contract identifier <b>28</b> and/or the contractual parameters <b>30</b>. Once the contract identifier <b>28</b> is determined, the contract server <b>42</b> may then consult an electronic database <b>44</b> of contracts. The database <b>44</b> of contracts has entries that map or relate the contract identifier <b>28</b> to its corresponding digital contract <b>20</b>. The database <b>44</b> of contracts, in other words, may identify a computer file <b>46</b> that contains the programming language representing the digital contract <b>20</b> identified by the contract identifier <b>28</b>. So, once the digital contract <b>20</b> is determined, the contract server <b>42</b> may retrieve and locally execute the computer file <b>46</b>, perhaps based on parameters defined or described by the contractual parameters <b>30</b> (such as party names, parameters associated with their respective performance obligations and terms, and consideration). Again, then, the blockchain <b>24</b> need only reference the digital contract <b>20</b> (using the contract identifier <b>28</b> and/or the contractual parameters <b>30</b>). The actual execution of the digital contract <b>20</b> may be offloaded or outsourced to the contract server <b>42</b>.

0145<figref idref="DRAWINGS">FIG. 12</figref> also illustrates the contract server <b>42</b>. Here, though, the contract server <b>42</b> may only manage the execution of the digital contract <b>20</b> referenced by the contract identifier <b>28</b> and/or the contractual parameters <b>30</b>. That is, the contract server <b>42</b> may outsource the execution of the digital contract <b>20</b> to a vendor, a supplier, or a subcontractor process. Again, when the contract server <b>42</b> receives the blockchain <b>24</b>, the contract server <b>42</b> inspects the blockchain <b>24</b> to identify the contract identifier <b>28</b> and/or the contractual parameters <b>30</b>. The contract server <b>42</b> may then consult the database <b>44</b> of contracts. Here, though, the database <b>44</b> of contracts has entries that map or relate the contract identifier <b>28</b> to a network resource <b>50</b> that processes and/or executes the digital contract <b>20</b> as a service (perhaps as a software-as-a-service or “SAAS”). The network resource <b>50</b> may thus be a remote server, a virtual machine, a web page or web server, a client device/machine, or other resource that executes the digital contract <b>20</b>. Once the network resource <b>50</b> is determined, the contract server <b>42</b> may retrieve and send the contractual parameters <b>30</b> to the network resource <b>50</b> for execution. The network resource <b>50</b> (perhaps operated on behalf of a third party) applies the parameters defined or described by the contractual parameters <b>30</b> to the programming code representing the digital contract <b>20</b>.

0146Exemplary embodiments thus only need to identify the digital contract <b>20</b>. The contract identifier <b>28</b> and the contractual parameters <b>30</b> need only be informational content in the private blockchain <b>24</b>. The contract identifier <b>28</b> is any digital identifying information that uniquely identifies or references the digital contract <b>20</b>. The contract identifier <b>28</b> may be an alphanumeric combination that uniquely identifies a vendor and/or version of the digital contract <b>20</b> and/or a processor or executioner of the digital contract <b>20</b>. The contract identifier <b>28</b> may be expressed as a unique hash value that is included within, or specified by, the private blockchain <b>24</b>. Similarly, the contractual parameters <b>30</b> may identify the parties to the digital contract <b>20</b>, their respective performance obligations and terms, and consideration.

0147<figref idref="DRAWINGS">FIG. 13</figref> illustrates consideration. When the digital contract <b>20</b> is executed, the parties to the digital contract <b>20</b> may be compensated (perhaps according to the contractual parameters <b>30</b> describing consideration). Moreover, the contract server <b>42</b> and/or the network resource <b>50</b> may also be compensated. While there are many compensation schemes, this disclosure mostly explains crypto-compensation. That is, when the digital contract <b>20</b> successfully executes, perhaps the parties exchange, trade, or transfer cryptographic currencies. Suppose, for example, that the financial institution <b>34</b> creates its own cryptographic coinage <b>60</b> in the blockchain environment <b>22</b>. The entity <b>32</b>, in other words, may establish entity-specific electronic tokens <b>62</b> to access and/or to use the blockchain environment <b>22</b>. Because the private blockchain <b>24</b> represents hashes of the financial institution's private data <b>36</b>, the private blockchain <b>24</b> may be considered a private resource or property of the financial institution <b>34</b>. That is, the private blockchain <b>24</b> is controlled by, or affiliated with, the financial institution <b>34</b>, so the financial institution <b>34</b> may control who adds and/or writes to the private blockchain <b>24</b> and who reads, accesses, or receives the private blockchain <b>24</b>.

0148The entity-specific tokens <b>62</b> may thus be control mechanisms. While the entity-specific tokens <b>62</b> may have any functional scheme, <figref idref="DRAWINGS">FIG. 5</figref> illustrates a private credit token <b>64</b> and a private tradeable token <b>66</b>. The entity's credit token <b>64</b>, for example, may be acquired and then spent or burned when accessing the financial institution's private blockchain <b>24</b>. The entity's credit token <b>64</b>, in other words, represents any credit-based entry system associated with the financial institution's private blockchain <b>24</b>. The tradeable token <b>66</b>, on the other hand, may be generated for transfer among others. The entity <b>32</b> generates the tradeable token <b>66</b> to be traded and/or spent. The tradeable token <b>66</b>, in other words, may be considered as the entity's specific, private currency to be used as the entity <b>32</b> governs.

0149Exemplary embodiments may thus trade or exchange crypto-compensation. That is, when the digital contract <b>20</b> successfully executes, perhaps the parties exchange, trade, or transfer the credit token <b>64</b> and/or the tradeable token <b>66</b>. When any party, or all the parties, perform their assigned role in the transaction, value is given via the credit token <b>64</b> and/or the tradeable token <b>66</b>. Similarly, the contract server <b>42</b> and/or the network resource <b>50</b> may also be compensated via the credit token <b>64</b> and/or the tradeable token <b>66</b>, perhaps as a “mining” fee for executing the digital contract <b>20</b>.

0150The digital contract <b>20</b> is thus a computer program or code that verifies and/or enforces negotiation and/or performance of a contract between parties. One fundamental purpose of so-called smart contracts is to integrate the practice of contract law and related business practices with electronic commerce protocols between parties or devices via the Internet. Smart contracts may leverage a user interface that provides one or more parties or administrators access, which may be restricted at varying levels for different people, to the terms and logic of the contract. Smart contracts typically include logic that emulates contractual clauses that are partially or fully self-executing and/or self-enforcing. Examples of smart contracts are digital rights management (DRM) used for protecting copyrighted works, financial cryptography schemes for financial contracts, admission control schemes, token bucket algorithms, other quality of service mechanisms for assistance in facilitating network service level agreements, person-to-person network mechanisms for ensuring fair contributions of users, and others. Smart contract infrastructure can be implemented by replicated asset registries and contract execution using cryptographic hash chains and Byzantine fault tolerant replication. For example, each node in a peer-to-peer network or blockchain distributed network may act as a title registry and escrow, thereby executing changes of ownership and implementing sets of predetermined rules that govern transactions on the network. Each node may also check the work of other nodes and in some cases, as noted above, function as miners or validators.

0151<figref idref="DRAWINGS">FIG. 14</figref> further illustrates the contract server <b>42</b>. When the contract server <b>42</b> receives the blockchain <b>24</b>, here the contract server <b>42</b> may generate data records <b>70</b> in a blockchain data layer <b>72</b>, as later paragraphs will explain. The contract server <b>42</b> may thus be termed or called a data layer server <b>74</b>. Moreover, the blockchain data layer <b>72</b> may also add another layer of cryptographic hashing to generate a public blockchain <b>76</b>. The blockchain data layer <b>72</b> acts as a validation service <b>78</b> that validates the digital contract <b>20</b> was executed. Moreover, the blockchain data layer <b>72</b> may generate a cryptographic proof <b>80</b>. The public blockchain <b>76</b> thus publishes the cryptographic proof <b>80</b> as a public ledger <b>82</b> that establishes chains of blocks of immutable evidence.

0152<figref idref="DRAWINGS">FIGS. 15-16</figref> illustrate examples of the entity-specific tokens <b>62</b>. Suppose that a third-party <b>90</b> wishes to receive, read, write to, or otherwise access the financial institution's private blockchain <b>24</b> and/or the digital contract <b>20</b>. As <figref idref="DRAWINGS">FIG. 15</figref> illustrates, exemplary embodiments may require that the third-party <b>90</b> spend or burn one or more of the credit tokens <b>64</b>. The credit token <b>64</b> may thus control access to the financial institution's private blockchain <b>24</b> and/or the digital contract <b>20</b>. The inventor envisions that vendors, service providers, individual users, and other third-parties <b>60</b> may wish to access the hash values of the private data <b>36</b> contained within the financial institution's private blockchain <b>24</b>. Moreover, the third party may want to access, inspect, execute, or verify the digital contract <b>20</b>. The financial institution <b>34</b> may thus require that the third-party <b>90</b> redeem the entity's credit token(s) <b>50</b> before granting read, write, or access permission to the digital contract <b>20</b>. The financial institution <b>34</b> may additionally or alternatively require redemption of the entity's credit token(s) <b>64</b> for using protocols, rules, and application programming interfaces (“APIs”) associated with the private blockchain <b>24</b> and/or the digital contract <b>20</b>. The financial institution <b>34</b> may thus establish or issue its own credit tokens <b>64</b> and even govern their usage restrictions <b>92</b> and value <b>94</b>, as later paragraphs will explain.

0153<figref idref="DRAWINGS">FIG. 16</figref> illustrates the tradeable token <b>66</b>. The financial institution <b>34</b> may establish the tradeable token <b>66</b> and also govern its usage restrictions <b>92</b> and value <b>94</b>. The tradeable token <b>66</b>, in other words, is a cryptocurrency or “coin.” Again, while exemplary embodiments may utilize any functional scheme, the tradeable token <b>66</b> may be earned. That is, anyone (such as the third party <b>90</b>) may earn the tradeable token <b>66</b> according to the usage restrictions <b>92</b>. For example, suppose the data layer server <b>74</b> earns the entity's tradeable token(s) <b>52</b> in exchange for processing and/or managing an execution of the digital contract <b>20</b>. The data layer server <b>74</b> may additionally or alternatively earn the entity's tradeable token(s) <b>52</b> in exchange for the validation service <b>78</b>. That is, a provider of the validation service <b>78</b> is paid, or earns, the entity's tradeable token(s) <b>52</b> for processing or executing the digital contract <b>20</b> and/or for cryptographically hashing the proof <b>80</b> of the digital contract <b>20</b>. The provider of the validation service <b>78</b> may also be paid in the entity's tradeable token(s) <b>52</b> for publishing the proof <b>80</b>. The tradeable token <b>66</b> may thus be transferred as currency according to the usage restrictions <b>92</b> and its value <b>94</b>.

0154<figref idref="DRAWINGS">FIG. 17</figref> illustrates transaction records <b>100</b>. Whenever the entity-specific tokens <b>62</b> are created, owned, or transferred, the transaction record <b>100</b> may be generated. The transaction record <b>100</b> may then be documented in the blockchain environment <b>22</b>. For example, the entity-specific tokens <b>62</b> may be addressable. That is, the credit token <b>64</b> and the tradeable token <b>66</b> may be uniquely associated with a common, single cryptographic address <b>102</b>. The cryptographic address <b>102</b> may represent an owner or holder (e.g., the entity <b>32</b> or the third-party <b>90</b>). When the entity-specific tokens <b>62</b> are created, generated, or assigned, the entity-specific tokens <b>62</b> may be assigned or associated with the cryptographic address <b>102</b>. The cryptographic address <b>102</b> may then be received by, and propagated within, the blockchain data layer <b>72</b> to identify the corresponding data records <b>70</b>. The blockchain data layer <b>72</b> may even hash the cryptographic address <b>102</b> as the cryptographic proof <b>80</b> of the transaction records <b>100</b>. Exemplary embodiments thus publicly document the transaction records <b>100</b> involving the entity-specific tokens <b>62</b>, based on the single cryptographic address <b>102</b>. In simple words, the blockchain data layer <b>72</b> publishes ownership and transfer proofs <b>80</b> of the credit token <b>64</b> and the tradeable token <b>66</b> based on the transaction records <b>100</b> associated with the single cryptographic address <b>102</b>.

0155The transaction records <b>100</b> may also document the digital contract <b>20</b>. Whenever the digital contract <b>20</b> is specified, generated, processed, or even executed, the transaction record <b>100</b> may be generated. The transaction record <b>100</b> may then be documented in the blockchain environment <b>22</b>. For example, the entity-specific tokens <b>62</b> may be earned as payment according to the executable terms of the digital contract <b>20</b>. The entity-specific tokens <b>62</b> may additionally or alternatively be earned or awarded for processing or executing a portion of, or entirely, the digital contract <b>20</b>. The entity-specific tokens <b>62</b> may thus be uniquely associated with a party to the digital contract <b>20</b> and/or with a service provider/processor of the digital contract <b>20</b>. The transaction record <b>100</b> may document the parties to the digital contract <b>20</b>, a transactional description describing a transaction governed by the digital contract <b>20</b>, and any financial or performance terms. The transaction record <b>100</b> may thus document an offer, an acceptance, a consideration, and terms. For simplicity, then, the single cryptographic address <b>102</b> may represent a party to the digital contract <b>20</b> and/or with a service provider/processor of the digital contract <b>20</b>. Regardless, when the entity-specific tokens <b>62</b> are created, generated, or assigned, the entity-specific tokens <b>62</b> may be received by, and propagated within, the blockchain data layer <b>72</b> to identify the corresponding data records <b>70</b>. The blockchain data layer <b>72</b> may thus publish the proofs <b>80</b> of the digital contract <b>20</b> and any entity-specific tokens <b>62</b> paid or exchanged, according to the transaction records <b>100</b>.

0156<figref idref="DRAWINGS">FIG. 18</figref> illustrates a filling station <b>110</b> in the blockchain environment <b>22</b>. Because the tokens <b>62</b> may be consumed by users (such as during or after any processing or execution of the digital contract <b>20</b>), the filling station <b>110</b> allows the third party <b>90</b> to replenish or fill an account <b>112</b>. Recall that the third-party entity <b>32</b> may be required to spend the tokens <b>62</b> to access the financial institution's private blockchain <b>24</b> and/or the digital contract <b>20</b>. Moreover, the tokens <b>62</b> may also be earned or transferred according to the terms of the digital contract <b>20</b>. The account <b>112</b> may thus be established, and the account <b>112</b> maintains a monetary or numerical balance <b>114</b> of the tokens <b>62</b>. As the tokens <b>62</b> are spent, traded, or redeemed, the account <b>112</b> may need filling to continue using or accessing the blockchain <b>24</b> and/or the digital contract <b>20</b>.

0157The filling station <b>110</b> may access both the transaction records <b>100</b> and the blockchain data layer <b>72</b>. Because the blockchain data layer <b>72</b> may document the data records <b>70</b> using the single cryptographic address <b>102</b>, the single cryptographic address <b>102</b> may serve as a common reference or query parameter with the entity's transaction records <b>100</b>. The filling station <b>110</b>, in other words, may use the single cryptographic address <b>102</b> to identify the transaction records <b>100</b> that correspond to the blockchain data layer <b>72</b>. The filling station <b>110</b> may thus present a transaction summary of the account <b>112</b> and the balance <b>114</b>. Because blockchain data layer <b>72</b> may track and/or prove the transaction records <b>100</b>, exemplary embodiments may search the blockchain data layer <b>72</b> for the single cryptographic address <b>102</b>. That is, the filling station <b>110</b> may query the blockchain data layer <b>72</b> for the single cryptographic address <b>102</b>, and the blockchain data layer <b>72</b> may identify the transaction records <b>100</b> that match the single cryptographic address <b>102</b>. Similarly, exemplary embodiments may query the blockchain data layer <b>72</b> for the contract identifier <b>28</b> and/or the contractual parameters <b>30</b>, and the blockchain data layer <b>72</b> may identify the transaction records <b>100</b> that match the contract identifier <b>28</b> and/or the contractual parameters <b>30</b>. The filling station <b>110</b> may then process the transaction records <b>100</b> to provide the transaction summary of the account <b>112</b>, the balance <b>114</b>, and any other transactional data. The filling station <b>110</b> may also allow the user to replenish an amount or value of the tokens <b>62</b>, thus allowing the user to continue exchanging the tokens <b>62</b> for access to the private blockchain <b>24</b>, the blockchain data layer <b>72</b>, and/or the digital contract <b>20</b>. The filling station <b>110</b> may thus be an access mechanism to the blockchain data layer <b>72</b>.

0158<figref idref="DRAWINGS">FIG. 19</figref> further illustrates the filling station <b>110</b>. Here the blockchain data layer <b>72</b> may have its own cryptocoinage <b>120</b>. That is, a provider of the blockchain data layer <b>72</b> may establish its cryptocoinage <b>120</b> for accessing and/or using the validation service <b>78</b>. The cryptocoinage <b>120</b> may thus include a credit token and a tradeable token (not shown for simplicity). The credit token may be required to enter or access the blockchain data layer <b>72</b> to receive the validation service <b>78</b>, and the tradeable token may be earned for participating in the validation service <b>78</b>. Regardless, the filling station <b>110</b> may use the single cryptographic address <b>102</b>. The third party <b>90</b> may use the single cryptographic address <b>102</b> to access the entity's cryptocoinage <b>60</b> and the blockchain data layer's cryptocoinage <b>120</b>. Exemplary embodiments may thus identify and track the transaction records <b>100</b> and the blockchain data layer's cryptocoinage <b>120</b> using the same, single cryptographic address <b>102</b>.

0159Exemplary embodiments thus present elegant solutions. Any entity <b>32</b> may create its own private blockchain <b>24</b> and offer or present the digital contract <b>20</b> for self-execution. The entity <b>32</b> may then establish or create the tokens <b>62</b> for using, accessing, or processing the entity's private blockchain <b>24</b> and/or the digital contract <b>20</b>. The tokens <b>62</b> may have the value <b>94</b>, thus fostering a market for entity-specific tradeable assets in the blockchain environment <b>22</b>. The tradable value <b>94</b> of the tokens <b>62</b> may thus drive demand to use the digital contracts <b>20</b>. Exemplary embodiments may thus provide a two-token system that isolates any use of the entity's private blockchain <b>24</b> from the entity's tradeable token <b>66</b>. Moreover, the credit token <b>64</b> may be associated with the third party <b>90</b> (perhaps via the single cryptographic address <b>102</b>), thus allowing the third party <b>90</b> to retrieve the account balance <b>114</b> from the filling station <b>110</b> and sign entries or other transactions. Moreover, the third party <b>90</b> may also use the single cryptographic address <b>102</b> to access the blockchain data layer <b>72</b> via the filling station <b>110</b>. The filling station <b>110</b> is a single resource or destination (such as a secure website) for managing a user's cryptographic coinage <b>60</b> and defining payments according to the digital contract <b>20</b>.

0160<figref idref="DRAWINGS">FIG. 20</figref> expands the entity concept. Here multiple, different entities <b>32</b><i>a</i>-<i>d </i>provide their respective software applications <b>40</b><i>a</i>-<i>d </i>that encrypt their respective private data <b>36</b><i>a</i>-<i>d </i>as their individual, private blockchains <b>24</b><i>a</i>-<i>d</i>. While exemplary embodiments may be applied to any number of industries or services, <figref idref="DRAWINGS">FIG. 20</figref> illustrates a simple example of four (4) different entities <b>32</b><i>a</i>-<i>d</i>. First entity <b>32</b><i>a</i>, for example, again represents the bank, lender, or other financial institution <b>34</b> that encrypts its private data <b>36</b><i>a </i>as its private blockchain <b>24</b><i>a</i>. Second entity <b>32</b><i>b </i>represents any retailer <b>122</b> (such as HOME DEPOT®, KOHL'S®, or WALMART®) that encrypts its private data <b>36</b><i>b </i>as its private blockchain <b>24</b><i>b</i>. Third entity <b>32</b><i>c </i>represents a website <b>124</b> offering a service <b>126</b> (such as AMAZON®, NETFLIX®, or GOOGLE®) that encrypts its private data <b>36</b><i>c </i>as the private blockchain <b>24</b><i>c</i>. Fourth entity <b>32</b><i>d </i>represents an automotive or other manufacturer or supplier <b>128</b> (such as FORD®, TOYOTA®, or DELPHI®) that encrypts its private data <b>36</b><i>d </i>as the private blockchain <b>24</b><i>d</i>. The entities <b>32</b><i>a</i>-<i>d </i>thus use their respective software applications <b>40</b><i>a</i>-<i>d </i>to provide a first layer <b>130</b> of cryptographic hashing. The entities <b>32</b><i>a</i>-<i>d </i>may also use their respective software applications <b>40</b><i>a</i>-<i>d </i>to issue their own private and entity-specific cryptocoinage <b>60</b><i>a</i>-<i>d</i>. Each entity <b>32</b><i>a</i>-<i>d </i>may then send their respective private blockchains <b>24</b><i>a</i>-<i>d </i>to the blockchain data layer <b>72</b>, and the blockchain data layer <b>72</b> may add a second layer <b>132</b> of cryptographic hashing. The blockchain data layer <b>72</b> thus generates the public blockchain <b>76</b> as a public resource or utility for record keeping. Any entity <b>32</b> that subscribes to the blockchain data layer <b>72</b> (such as by acquiring and/or spending the cryptocoinage <b>120</b>) may thus access, read, and/or store the proofs <b>80</b> of its private data <b>36</b> to the public blockchain <b>76</b>. The blockchain data layer <b>72</b>, in other words, acts as the public ledger <b>82</b> that establishes chain of blocks of immutable evidence.

0161As <figref idref="DRAWINGS">FIG. 20</figref> also illustrates, each entity <b>32</b><i>a</i>-<i>d </i>may establish its own private cryptocoinage <b>60</b><i>a</i>-<i>d</i>. Each entity's private software application <b>40</b><i>a</i>-<i>d </i>may create and/or issue its cryptocoinage <b>60</b><i>a</i>-<i>d </i>(such as respective entity-specific tokens <b>62</b> above explained). Each entity <b>32</b><i>a</i>-<i>d </i>may also establish its own usage restrictions and value (illustrated as reference numerals <b>92</b> and <b>94</b> in <figref idref="DRAWINGS">FIGS. 15-16</figref>) according to rules governing ownership, trade, and other policies. Each entity <b>32</b><i>a</i>-<i>d </i>may generate and sends its respective transaction records <b>100</b><i>a</i>-<i>d </i>which reference each entity's single cryptographic address <b>102</b><i>a</i>-<i>d </i>to the blockchain data layer <b>72</b> for documentation.

0162As <figref idref="DRAWINGS">FIG. 20</figref> further illustrates, each entity <b>32</b><i>a</i>-<i>d </i>may also specify their respective digital contract <b>20</b><i>a</i>-<i>d</i>. When any of the private blockchains <b>24</b><i>a</i>-<i>d </i>is received, the blockchain data layer <b>72</b> may coordinate execution of any digital contract <b>20</b><i>a</i>-<i>d</i>. The blockchain data layer <b>72</b>, for example, may inspect any private blockchain <b>24</b><i>a</i>-<i>d </i>and identify any information associated with the digital contract <b>20</b><i>a</i>-<i>d</i>. The blockchain data layer <b>72</b> may then execute the digital contract <b>20</b><i>a</i>-<i>d</i>, and/or the blockchain data layer <b>72</b> may identify a service provider that executes the digital contract <b>20</b><i>a</i>-<i>d</i>. The blockchain data layer <b>72</b>, in other words, may manage the execution of the digital contracts <b>20</b><i>a</i>-<i>d </i>according to a subcontractor relationship. A provider of the blockchain data layer <b>72</b> may then be compensated via any entity's cryptocoinage <b>60</b><i>a</i>-<i>d </i>and/or the blockchain data layer's cryptocoinage <b>120</b>.

0163As <figref idref="DRAWINGS">FIG. 21</figref> illustrates, the filling station <b>110</b> may be agnostic. Any user (such as the entity <b>32</b><i>a</i>-<i>d </i>or the third party <b>90</b>) may authenticate to the filling station <b>110</b>. Once authenticated, the user need only enter or provide the correct single cryptographic address <b>102</b><i>a</i>-<i>d </i>to access the entity's private cryptocoinage <b>60</b><i>a</i>-<i>d</i>, the blockchain data layer's cryptocoinage <b>120</b>, and/or the entity's digital contract <b>20</b><i>a</i>-<i>d</i>. The single cryptographic address <b>102</b><i>a</i>-<i>d</i>, in other words, allows the user to access her account <b>112</b> and balance <b>114</b> for the entity's private cryptocoinage <b>60</b><i>a</i>-<i>d</i>, the blockchain data layer's cryptocoinage <b>120</b>, and/or the entity's digital contract <b>20</b><i>a</i>-<i>d</i>. The user may thus easily conduct transactions between the entity's private cryptocoinage <b>60</b><i>a</i>-<i>d </i>and the blockchain data layer's cryptocoinage <b>120</b>. The entity <b>32</b><i>a</i>-<i>d</i>, for example, may fuel or replenish its supply of the blockchain data layer's cryptocoinage <b>120</b>, perhaps by redeeming or exchanging the entity's private cryptocoinage <b>60</b><i>a</i>-<i>d </i>(perhaps according to an exchange rate or other value). Similarly, the provider of the blockchain data layer <b>72</b> may fuel or replenish its supply of the entity's private cryptocoinage <b>60</b><i>a</i>-<i>d </i>by purchasing or exchanging the blockchain data layer's cryptocoinage <b>120</b>. The provider of the blockchain data layer <b>72</b> may also earn the entity's private cryptocoinage <b>60</b><i>a</i>-<i>d </i>by processing any portion of, or by executing, the entity's digital contract <b>20</b><i>a</i>-<i>d</i>. Moreover, the respective private blockchains <b>24</b><i>a</i>-<i>d </i>and the blockchain data layer <b>72</b> would contain the data records <b>70</b> confirming the processing and/or execution of the digital contract <b>20</b><i>a</i>-<i>d</i>, so the transaction records <b>100</b><i>a</i>-<i>d </i>thus propagate into the blockchain data layer <b>72</b> for public disclosure via the public blockchain <b>76</b>. Any user that successfully authenticates to the filling station <b>110</b> may access a full accounting of his or her digital cryptocoinages <b>60</b><i>a</i>-<i>d </i>and/or <b>120</b> and any digital contracts <b>20</b>, perhaps according to the respective single cryptographic address <b>102</b><i>a</i>-<i>d</i>. The user may thus buy, sell, trade, and/or redeem any entity-specific cryptocoinages <b>20</b><i>a</i>-<i>d </i>and/or <b>90</b>, all by accessing the filling station <b>110</b>. The user may buy or sell any entity's coins or replenish credits, all by accessing the filling station <b>110</b>. The user may also track performance or obligations defined by the digital contracts <b>20</b><i>a</i>-<i>d </i>and any payments or consideration received or paid.

0164Exemplary embodiments thus present another elegant solution. The filling station <b>110</b> is another service offered by the blockchain data layer <b>72</b>. Because all the transaction records <b>100</b> in the blockchain data layer <b>72</b> are identifiable (perhaps via the single cryptographic address <b>102</b>), the filling station <b>110</b> can present the summary of the user's credit tokens and tradeable tokens. The filling station <b>110</b> may thus provide a single or universal electronic wallet for all of a user's digital coinage and credits, regardless of the issuing entity <b>32</b><i>a</i>-<i>d</i>. The user may thus only perform a single authentication to the blockchain data layer <b>72</b> and access all her cryptofunds.

0165<figref idref="DRAWINGS">FIGS. 22-24</figref> are more detailed illustrations of an operating environment, according to exemplary embodiments. <figref idref="DRAWINGS">FIG. 22</figref> illustrates an entity server <b>140</b> communicating with the data layer server <b>74</b> via a communications network <b>142</b>. The entity server <b>140</b> operates on behalf of the entity <b>32</b> and generates the entity's private blockchain <b>24</b> (such as the financial server <b>38</b> explained with reference to <figref idref="DRAWINGS">FIGS. 10-19</figref>). The entity server <b>140</b>, in other words, has a processor <b>144</b> (e.g., “μP”), application specific integrated circuit (ASIC), or other component that executes the entity's software application <b>40</b> stored in a local memory device <b>146</b>. The entity server <b>140</b> has a network interface to the communications network <b>142</b>, thus allowing two-way, bidirectional communication with the data layer server <b>74</b>. The entity's software application <b>40</b> includes instructions, code, and/or programs that cause the entity server <b>140</b> to perform operations, such as calling, invoking, and/or applying an electronic representation of a hashing algorithm <b>148</b> to the entity's private data <b>36</b>. The hashing algorithm <b>148</b> thus generates one or more hash values <b>150</b>, which are incorporated into the entity's private blockchain <b>24</b>. The entity's software application <b>40</b> then instructs the entity server <b>140</b> to send the private blockchain <b>24</b> via the communications network <b>142</b> to a network address (e.g., Internet protocol address) associated with the data layer server <b>74</b>.

0166The digital contract <b>20</b> may also be identified. The entity's software application <b>40</b> may also instruct the entity server <b>140</b> to specify the digital contract <b>20</b> as informational content in the private blockchain <b>24</b>. For example, the digital contract <b>20</b> may be identified by the contract identifier <b>28</b> and contractual parameters <b>30</b>. The contract identifier <b>28</b> is any digital identifying information that uniquely identifies or references the digital contract <b>20</b>. The contract identifier <b>28</b> may be an alphanumeric combination that uniquely identifies a vendor and/or version of the digital contract <b>20</b> and/or a processor or executioner of the digital contract <b>20</b>. The contract identifier <b>28</b> may also be one of the unique hash values <b>150</b> (perhaps generated by the hashing algorithm <b>148</b>) that is included within, or specified by, the private blockchain <b>24</b>. Similarly, the contractual parameters <b>30</b> may identify the parties to the digital contract <b>20</b>, their respective performance obligations and terms, and consideration.

0167<figref idref="DRAWINGS">FIG. 23</figref> illustrates the blockchain data layer <b>72</b>. The data layer server <b>74</b> has a processor <b>152</b> (e.g., “μP”), application specific integrated circuit (ASIC), or other component that executes a data layer application <b>154</b> stored in a local memory device <b>156</b>. The data layer server <b>74</b> has a network interface to the communications network <b>142</b>. The data layer application <b>154</b> includes instructions, code, and/or programs that cause the data layer server <b>74</b> to perform operations, such as receiving the entity's private blockchain <b>24</b>, the digital contract <b>20</b>, the contract identifier <b>28</b>, and/or the contractual parameters <b>30</b>. The data layer application <b>154</b> then causes the data layer server <b>74</b> to generate the blockchain data layer <b>72</b>. The data layer application <b>154</b> may optionally call, invoke, and/or apply the hashing algorithm <b>148</b> to the data records <b>70</b> contained within the blockchain data layer <b>72</b>. The data layer application <b>154</b> may also generate the public blockchain <b>76</b>. The data layer application <b>154</b> may thus generate the public ledger <b>82</b> that publishes, records, or documents the digital contract <b>20</b>, the contract identifier <b>28</b>, and/or the contractual parameters <b>30</b>. Indeed, if the data layer application <b>154</b> processes and/or manages the digital contract <b>20</b>, the data records <b>70</b> may document any processing or execution, and the data layer application <b>154</b> may optionally apply the hashing algorithm <b>148</b> to the data records <b>70</b> to generate the cryptographic proof <b>80</b> of the digital contract <b>20</b>.

0168<figref idref="DRAWINGS">FIG. 24</figref> illustrates additional publication mechanisms. Once the blockchain data layer <b>72</b> is generated, the blockchain data layer <b>72</b> may be published in a decentralized manner to any destination. The data layer server <b>74</b>, for example, may generate and distribute the public blockchain <b>76</b> (via the communications network <b>142</b> illustrated in <figref idref="DRAWINGS">FIGS. 22-23</figref>) to one or more federated servers <b>160</b>. While there may be many federated servers <b>160</b>, for simplicity <figref idref="DRAWINGS">FIG. 24</figref> only illustrates two (2) federated servers <b>160</b><i>a </i>and <b>160</b><i>b</i>. The federated servers <b>160</b><i>a </i>and <b>160</b><i>b </i>provide a service and, in return, they are compensated according to a compensation or services agreement or scheme.

0169Exemplary embodiments include still more publication mechanisms. For example, the cryptographic proof <b>80</b> and/or the public blockchain <b>76</b> may be sent (via the communications network <b>142</b> illustrated in <figref idref="DRAWINGS">FIGS. 22-23</figref>) to a server <b>162</b>. The server <b>162</b> may then add another, third layer of cryptographic hashing (perhaps using the hashing algorithm <b>148</b>) and generate another or second public blockchain <b>164</b>. While the server <b>162</b> and/or the public blockchain <b>164</b> may be operated by, or generated for, any entity, exemplary embodiments may integrate another cryptographic coin mechanism. That is, the server <b>162</b> and/or the public blockchain <b>164</b> may be associated with BITCOIN®, ETHEREUM®, RIPPLE®, or other cryptographic coin mechanism. The cryptographic proof <b>80</b> and/or the public blockchain <b>76</b> may be publicly distributed and/or documented as evidentiary validation. The cryptographic proof <b>80</b> and/or the public blockchain <b>76</b> may thus be historically and publicly anchored for public inspection and review.

0170Exemplary embodiments may be applied regardless of networking environment. Exemplary embodiments may be easily adapted to stationary or mobile devices having cellular, wireless local area network (WI-FI®), near field, and/or BLUETOOTH® capability. Exemplary embodiments may be applied to mobile devices utilizing any portion of the electromagnetic spectrum and any signaling standard (such as the IEEE 802 family of standards, GSM/CDMA/TDMA or any cellular standard, and/or the ISM band). Exemplary embodiments, however, may be applied to any processor-controlled device operating in the radio-frequency domain and/or the Internet Protocol (IP) domain. Exemplary embodiments may be applied to any processor-controlled device utilizing a distributed computing network, such as the Internet (sometimes alternatively known as the “World Wide Web”), an intranet, a local-area network (LAN), and/or a wide-area network (WAN). Exemplary embodiments may be applied to any processor-controlled device utilizing power line technologies, in which signals are communicated via electrical wiring. Indeed, exemplary embodiments may be applied regardless of physical componentry, physical configuration, or communications standard(s).

0171Exemplary embodiments may utilize any processing component, configuration, or system. Any processor could be multiple processors, which could include distributed processors or parallel processors in a single machine or multiple machines. The processor can be used in supporting a virtual processing environment. The processor could include a state machine, application specific integrated circuit (ASIC), programmable gate array (PGA) including a Field PGA, or state machine. When any of the processors execute instructions to perform “operations,” this could include the processor performing the operations directly and/or facilitating, directing, or cooperating with another device or component to perform the operations.

0172Exemplary embodiments may packetize. When the entity server <b>140</b> and the data layer server <b>74</b> communicate via the communications network <b>142</b>, the entity server <b>140</b> and the data layer server <b>74</b> may collect, send, and retrieve information. The information may be formatted or generated as packets of data according to a packet protocol (such as the Internet Protocol). The packets of data contain bits or bytes of data describing the contents, or payload, of a message. A header of each packet of data may contain routing information identifying an origination address and/or a destination address.

0173<figref idref="DRAWINGS">FIGS. 25-29</figref> further illustrate the blockchain data layer <b>72</b>, according to exemplary embodiments. The blockchain data layer <b>72</b> chains hashed directory blocks <b>170</b> of data into the public blockchain <b>76</b>. For example, the blockchain data layer <b>72</b> accepts input data (such as the entity's private blockchain <b>24</b> illustrated in <figref idref="DRAWINGS">FIGS. 9-21</figref>) within a window of time. While the window of time may be configurable from fractions of seconds to hours, exemplary embodiments use ten (10) minute intervals. <figref idref="DRAWINGS">FIG. 25</figref> illustrates a simple example of only three (3) directory blocks <b>170</b><i>a</i>-<i>c </i>of data, but in practice there may be millions or billions of different blocks. Each directory block <b>184</b> of data is linked to the preceding blocks in front and the following or trailing blocks behind. The links are created by hashing all the data within a single directory block <b>184</b> and then publishing that hash value within the next directory block.

0174As <figref idref="DRAWINGS">FIG. 26</figref> illustrates, published data may be organized within chains <b>172</b>. Each chain <b>172</b> is created with an entry that associates a corresponding chain identifier <b>174</b>. Each entity <b>32</b><i>a</i>-<i>f</i>, in other words, may have its corresponding chain identifier <b>174</b><i>a</i>-<i>d</i>. The blockchain data layer <b>72</b> may thus track any data associated with the entity <b>32</b><i>a</i>-<i>f </i>with its corresponding chain identifier <b>174</b><i>a</i>-<i>d</i>. New and old data in time may be associated with, linked to, identified by, and/or retrieved using the chain identifier <b>174</b><i>a</i>-<i>d</i>. Each chain identifier <b>174</b><i>a</i>-<i>d </i>thus functionally resembles a directory <b>176</b><i>a</i>-<i>d </i>(e.g., files and folders) for organized data entries according to the entity <b>32</b><i>a</i>-<i>f. </i>

0175<figref idref="DRAWINGS">FIG. 27</figref> illustrates the data records <b>70</b> in the blockchain data layer <b>72</b>. As data is received as an input (such as the private blockchain <b>24</b> and/or the digital contract <b>20</b> illustrated in <figref idref="DRAWINGS">FIGS. 9-21</figref>), data is recorded within the blockchain data layer <b>72</b> as an entry <b>180</b>. While the data may have any size, small chunks (such as 10 KB) may be pieced together to create larger file sizes. One or more of the entries <b>180</b> may be arranged into entry blocks <b>182</b> representing each chain <b>172</b> according to the corresponding chain identifier <b>174</b>. New entries for each chain <b>172</b> are added to their respective entry block <b>182</b> (again perhaps according to the corresponding chain identifier <b>174</b>). After the entries <b>180</b> have been made within the proper entry blocks <b>182</b>, all the entry blocks <b>182</b> are then placed within in the directory block <b>184</b> generated within or occurring within a window <b>186</b> of time. While the window <b>186</b> of time may be chosen within any range from seconds to hours, exemplary embodiments may use ten (10) minute intervals. That is, all the entry blocks <b>182</b> generated every ten minutes are placed within in the directory block <b>184</b>.

0176<figref idref="DRAWINGS">FIG. 28</figref> illustrates cryptographic hashing. The data layer server <b>74</b> executes the data layer application <b>154</b> to generate the data records <b>70</b> in the blockchain data layer <b>72</b>. The data layer application <b>154</b> may then instruct the data layer server <b>74</b> to execute the hashing algorithm <b>148</b> on the data records <b>70</b> (such as the directory block <b>184</b> illustrated in <figref idref="DRAWINGS">FIGS. 25-27</figref>). The hashing algorithm <b>148</b> thus generates one or more hash values <b>150</b> as a result, and the hash values <b>150</b> represent the hashed data records <b>70</b>. As one example, the blockchain data layer <b>72</b> may apply a Merkle tree analysis to generate a Merkle root (representing a Merkle proof <b>80</b>) representing each directory block <b>184</b>. The blockchain data layer <b>72</b> may then publish the Merkle proof <b>80</b> (as this disclosure explains).

0177<figref idref="DRAWINGS">FIG. 29</figref> illustrates hierarchical hashing. The entity's private software application <b>40</b> provides the first layer <b>130</b> of cryptographic hashing and generates the private blockchain <b>24</b>. The entity <b>32</b> then sends its private blockchain <b>24</b> (perhaps referencing or specifying the digital contract <b>20</b>) to the data layer server <b>74</b>. The data layer server <b>74</b>, executing the data layer application <b>154</b>, generates the blockchain data layer <b>72</b>. The data layer application <b>154</b> may optionally provide the second or intermediate layer <b>132</b> of cryptographic hashing to generate the cryptographic proof <b>80</b>. The data layer application <b>154</b> may also publish any of the data records <b>70</b> as the public blockchain <b>76</b>, and the cryptographic proof <b>80</b> may or may not also be published via the public blockchain <b>76</b>. The public blockchain <b>76</b> and/or the cryptographic proof <b>80</b> may be optionally sent to the server <b>162</b> as an input to yet another public blockchain <b>164</b> (again, such as BITCOIN®, ETHEREUM®, or RIPPLE®) for a third layer <b>188</b> of cryptographic hashing and public publication. The first layer <b>130</b> and the second layer <b>132</b> thus ride or sit atop a conventional public blockchain <b>164</b> (again, such as BITCOIN®, ETHEREUM®, or RIPPLE®) and provide additional public and/or private cryptographic proofs <b>80</b>.

0178Exemplary embodiments may use any hashing function. Many readers may be familiar with the SHA-256 hashing algorithm. The SHA-256 hashing algorithm acts on any electronic data or information to generate a 256-bit hash value as a cryptographic key. The key is thus a unique digital signature. There are many hashing algorithms, though, and exemplary embodiments may be adapted to any hashing algorithm.

0179<figref idref="DRAWINGS">FIGS. 30-32</figref> are more detailed illustrations of the digital contract <b>20</b>, according to exemplary embodiments. The private entity <b>32</b> sends its private blockchain <b>24</b> to the network address associated with the data layer server <b>74</b> that generates the blockchain data layer <b>72</b>. The private blockchain <b>24</b> may contain information representing the transaction records <b>100</b> associated with the entity's private cryptocoinage <b>60</b> (perhaps as one or more privately hashed blocks of data). The private blockchain <b>24</b> may also specify, or incorporate, information or data representing the single cryptographic address <b>102</b> and/or the digital contract <b>20</b> (e.g., the contract identifier <b>28</b> and the contractual parameters <b>30</b>). The single cryptographic address <b>102</b> and/or the digital contract <b>20</b> (e.g., the contract identifier <b>28</b> and the contractual parameters <b>30</b>) may additionally or alternatively be separately sent from the entity server <b>140</b> to the data layer server <b>74</b> (perhaps via the communications network <b>142</b> illustrated by <figref idref="DRAWINGS">FIGS. 22-23</figref>). Regardless, the entity's private cryptocoinage <b>60</b> may be associated with the digital contract <b>20</b> (e.g., the contract identifier <b>28</b> and the contractual parameters <b>30</b>) and/or the single cryptographic address <b>102</b>. The transaction records <b>100</b> and/or their privately hashed blocks of data may thus specify, include, reference, and/or be associated with, and/or identified by, the single cryptographic address <b>102</b>, the digital contract <b>20</b>, the contract identifier <b>28</b>, and/or the contractual parameters <b>30</b>. Because the contract identifier <b>28</b> (and/or its corresponding hash value) is an identifiable input to the data layer server <b>74</b> generating the blockchain data layer <b>72</b>, the data records <b>70</b> may also carry or reference the contract identifier <b>28</b> and/or the contractual parameters <b>30</b>. So, should the blockchain data layer <b>72</b> create or issue its own cryptocoinage <b>120</b>, the cryptocoinage <b>120</b> may also reference, be identified by, or be associated with the single cryptographic address <b>102</b> and/or the contract identifier <b>28</b> and/or the contractual parameters <b>30</b>. The single cryptographic address <b>102</b>, the contract identifier <b>28</b>, and/or the contractual parameters <b>30</b> may thus common indicators or reference data for tracking both the entity's private cryptocoinage <b>60</b> and the cryptocoinage <b>120</b> issued by the blockchain data layer <b>72</b>, according to the terms of the digital contract <b>20</b>. The transaction records <b>100</b> (representing entity's private cryptocoinage <b>60</b>) may thus be commonly mapped or identified to the cryptocoinage <b>120</b> issued by the blockchain data layer <b>72</b> and to the digital contract <b>20</b>.

0180<figref idref="DRAWINGS">FIG. 31</figref> illustrates a simple illustration. Once the contract identifier <b>28</b> (and/or its corresponding hash value) is received, the contract identifier <b>28</b> may propagate and be recorded within the blockchain data layer <b>72</b>. The contract identifier <b>28</b>, for example, may be recorded in any of the entries <b>180</b>. The entry <b>180</b>, and thus the contract identifier <b>28</b>, may then be recorded and/or arranged as the entry block <b>182</b> and placed within the directory block <b>184</b>. The entry <b>180</b>, the entry block <b>182</b>, and the directory block <b>184</b> may thus reference, specify, or be associated with, the contract identifier <b>28</b>. The contract identifier <b>28</b> has thus propagated as informational content from the private blockchain <b>24</b> and into and through the blockchain data layer <b>72</b>. The contract identifier <b>28</b> thus hierarchically moves through the multiple layers of cryptographic hashing for public publication. The blockchain data layer <b>72</b> thus tracks the transaction records <b>100</b> involving the contract identifier <b>28</b>. In simple words, the blockchain data layer <b>72</b> may track contractual performance of the digital contract <b>20</b> via the transaction records <b>100</b> that reference or contain the contract identifier <b>28</b>. Moreover, the blockchain data layer <b>72</b> may also track ownership and transfer of the entity's private cryptocoinage <b>60</b> and the cryptocoinage <b>120</b> issued by the blockchain data layer <b>72</b>, all via the common single cryptographic address <b>102</b> and/or the contract identifier <b>28</b>.

0181<figref idref="DRAWINGS">FIG. 32</figref> illustrates more details. While the single cryptographic address <b>102</b> and/or the contract identifier <b>28</b> may be any alphanumeric entry or biometric input, <figref idref="DRAWINGS">FIG. 24</figref> illustrates a common authentication mechanism <b>190</b>. Here the same or similar authentication mechanism <b>190</b> is used to access both the entity's private cryptocoinage <b>60</b> and the cryptocoinage <b>120</b> issued by the blockchain data layer <b>72</b>. If a user of the blockchain data layer <b>72</b> satisfies the authentication mechanism <b>190</b>, then exemplary embodiments may access both the private cryptocoinage <b>60</b>, the cryptocoinage <b>120</b>, and/or the data records <b>70</b> associated with the contract identifier <b>28</b>. As a simple example, suppose the user of the authentication mechanism <b>190</b> supplies information or data representing the single cryptographic address <b>102</b> and/or the contract identifier <b>28</b>. The single cryptographic address <b>102</b> and/or the contract identifier <b>28</b> may be any unique alphanumeric entry, biometric input, user identifier, or other authentication credential. For example, most readers are likely familiar with an alphanumeric username and password, which is a common authentication mechanism <b>190</b>. <figref idref="DRAWINGS">FIG. 32</figref>, though, illustrates a passphrase <b>192</b> (such as a multi-word mnemonic). When the entity's private cryptocoinage <b>60</b> is/are created, generated, or assigned, the entity's private cryptocoinage <b>60</b> may be assigned or associated with the passphrase <b>192</b>. The passphrase <b>192</b> is unique to the registered owner, possessor, or user of the entity's private cryptocoinage <b>60</b>. The passphrase <b>192</b> may even be hashed as a hash value and supplied to the blockchain data layer <b>72</b> (as above explained). The passphrase <b>192</b>, in other words, may be hashed as the single cryptographic address <b>102</b> and propagated within the blockchain environment <b>22</b> to document the transaction records <b>100</b> involving the entity's private cryptocoinage <b>60</b>.

0182The passphrase <b>192</b> may also authenticate to the cryptocoinage <b>120</b>. If the user correctly supplies the passphrase <b>192</b>, then the same user may conduct transactions involving the cryptocoinage <b>120</b> issued by the blockchain data layer <b>72</b> and/or involving the contract identifier <b>28</b> associated with the digital contract <b>20</b>. Exemplary embodiments thus allow the user to order transactions and exchanges involving the entity's private cryptocoinage <b>60</b>, the cryptocoinage <b>120</b> issued by the blockchain data layer <b>72</b>, and/or the digital contract <b>20</b>.

0183<figref idref="DRAWINGS">FIGS. 33-35</figref> further illustrate the access mechanism, according to exemplary embodiments. The filling station <b>110</b> may be a public and/or private service for financial transactions involving the entity's private cryptocoinage <b>60</b>, the cryptocoinage <b>120</b> issued by the blockchain data layer <b>72</b>, and/or the digital contract <b>20</b>. <figref idref="DRAWINGS">FIG. 33</figref> illustrates the filling station <b>110</b> as a software-as-a-service offered by the secure data layer server <b>74</b> for accessing the blockchain data layer <b>72</b>. The filling station <b>110</b>, for example, may be a module within, or called by, the data layer application <b>154</b>. A user accesses the filling station <b>110</b> to conduct transactions involving her private cryptocoinage <b>60</b>, the cryptocoinage <b>120</b> (issued by the blockchain data layer <b>72</b>), and/or the digital contract <b>20</b>. While the filling station <b>110</b> may have any user interface, <figref idref="DRAWINGS">FIG. 33</figref> illustrates a web interface <b>194</b>. That is, the filling station <b>110</b> may be accessed via a webpage <b>196</b>. The webpage <b>196</b> prompts the user to input her authentication credentials according to the authentication mechanism <b>190</b> (such as typing the passphrase <b>192</b> into a data field or audibly speaking the passphrase <b>192</b>).

0184<figref idref="DRAWINGS">FIG. 34</figref> further illustrates the web interface <b>194</b>. The user accesses the filling station <b>110</b> using a user device <b>200</b>. While the user device <b>200</b> may be any processor-controlled device, most readers are familiar with a smartphone <b>202</b>. If the smartphone <b>202</b> correctly sends authentication credentials (such as the single cryptographic address <b>102</b> and/or passphrase <b>192</b>, as above explained), then the smartphone <b>202</b> may utilize the web interface <b>194</b> to the data layer server <b>74</b> and/or the blockchain data layer <b>72</b>. The smartphone <b>202</b> executes a web browser and/or a mobile application to send a request <b>204</b> specifying an address or domain name associated with or representing the filling station <b>110</b>. The web interface <b>194</b> to the data layer server <b>74</b> thus sends the webpage <b>196</b> as a response, and the user's smartphone <b>202</b> downloads the webpage <b>196</b>. The smartphone <b>202</b> has a processor and memory device (not shown for simplicity) that causes a display of the webpage <b>196</b> as a graphical user interface (or “GUI”) <b>206</b> on its display device <b>208</b>. The GUI <b>206</b> may generate one or more prompts or fields for specifying the authentication mechanism <b>190</b> and transactional options. For example, the user preferably enters, speaks, or otherwise provides the passphrase <b>192</b>. Exemplary embodiments may or may not hash the authentication passphrase (using the hashing algorithm <b>148</b> above explained) to produce or generate a hashed passphrase. Exemplary embodiments may then search the blockchain data layer <b>72</b> for the data records <b>70</b>. That is, exemplary embodiments may query the blockchain data layer <b>72</b> for a query parameter (such as the contract identifier <b>28</b> and/or its hashed value) and the blockchain data layer <b>72</b> identifies the data records <b>70</b> that match or reference the query parameter. The filling station <b>110</b> may then process the data records <b>70</b> to provide a transactional summary <b>210</b> of the digital contract <b>20</b>. The filling station <b>110</b> may also allow the user to replenish an amount or value of the private cryptocoinage <b>60</b> and/or the cryptocoinage <b>120</b>, even allowing the user to continue exchanging the cryptocoinage <b>60</b> for access to the blockchain data layer <b>72</b>.

0185Exemplary embodiments may thus share the common authentication mechanism <b>190</b>. If the entity's private software application <b>40</b> requires the same passphrase <b>192</b> to establish any terms of the digital contract <b>20</b>, then the passphrase <b>192</b> may have been hashed and recorded within the blockchain data layer <b>72</b>. The single cryptographic address <b>102</b>, the contract identifier <b>28</b>, and/or the passphrase <b>192</b> may be associated with the data records <b>70</b> representing the digital contract <b>20</b>, the private cryptocoinage <b>60</b> (issued by the entity <b>32</b>), and the cryptocoinage <b>120</b> (issued by the blockchain data layer <b>72</b>). The filling station <b>110</b> may thus identify any of the data records <b>70</b> that are commonly associated with the contract identifier <b>28</b>, the private cryptocoinage <b>60</b> (issued by the entity <b>32</b>), and/or the cryptocoinage <b>120</b>. The filling station <b>110</b> thus allows the user to exchange cryptocoinage <b>60</b> and <b>90</b> for access to the private blockchain <b>24</b> and/or the blockchain data layer <b>72</b>.

0186<figref idref="DRAWINGS">FIG. 35</figref> illustrates a query mechanism. Here the data layer server <b>74</b> may access a database <b>220</b> of data layer records. The database <b>220</b> of data layer records provides a referential record of the informational content contained within the blockchain data layer <b>72</b>. <figref idref="DRAWINGS">FIG. 35</figref> illustrates the data layer server <b>74</b> locally storing the database <b>220</b> of data layer records in its local memory device <b>156</b>, but the database <b>220</b> of data layer records may be remotely stored and accessed via the communications network <b>142</b>. Regardless, the data layer server <b>74</b> may query the database <b>220</b> of data layer records for the single cryptographic address <b>102</b> and/or the contract identifier <b>28</b> and identify and/or retrieve any corresponding data records <b>70</b>. While the database <b>220</b> of data layer records may have any logical structure, <figref idref="DRAWINGS">FIG. 35</figref> illustrates the database <b>220</b> of data layer records as a table <b>222</b> that maps, converts, or translates the single cryptographic address <b>102</b> and/or the contract identifier <b>28</b> to its corresponding entry <b>180</b>, entry block <b>182</b>, and/or directory block <b>184</b> within the blockchain data layer <b>72</b>. Whenever the data layer server <b>74</b> generates the entry <b>180</b>, entry block <b>182</b>, and/or directory block <b>184</b>, the data layer server <b>74</b> may add an entry to the database <b>220</b> of data layer records. Over time, then, the database <b>220</b> of data layer tracks a comprehensive historical repository of information that is electronically associated with its corresponding contract identifier <b>28</b>. The data layer server <b>74</b> may then read or retrieve the entry <b>180</b>, entry block <b>182</b>, and/or directory block <b>184</b> containing or corresponding to the contract identifier <b>28</b>.

0187Exemplary embodiments thus present the entity-specific cryptocoinage <b>60</b>. Any entity <b>32</b> may create its own private blockchain <b>24</b>, establish its entity-specific tokens <b>62</b>, and define or offer digital contracts <b>20</b>. The entity-specific tokens <b>62</b> may or may not have the value <b>94</b>. The tradeable token <b>66</b>, for example, may have a market value based on supply and/or demand, thus allowing or causing the value <b>94</b> of the tradeable token <b>66</b> to rise/fall or to increase/decrease, based on market forces. The credit token <b>64</b>, however, may have a constant price or value, perhaps set by the entity <b>32</b>. The entity-specific tokens <b>62</b> may be associated with the contract identifier <b>28</b>, thus allowing a faster and simpler accounting scheme for machine executable contractual terms.

0188Exemplary embodiments may thus create coinage on top of coinage. The hierarchical scheme (explained with reference to <figref idref="DRAWINGS">FIG. 29</figref>) allows the private entity <b>32</b> to establish its private cryptocoinage <b>60</b> hierarchically above the traditional BITCOIN®, ETHEREUM®, or RIPPLE® coinage. The entity's private data <b>36</b> remains private, but the transaction records <b>100</b> may be publicly documented or proved via the traditional BITCOIN®, ETHEREUM®, or RIPPLE® environment. The private entity <b>32</b>, in other words, need to worry about or concern itself with public publication. The private entity <b>32</b> need only subscribe (e.g., pay for write access) to the blockchain data layer <b>72</b>. The digital contract <b>20</b> may also be offered, executed, and documented by the transaction records <b>100</b>.

0189<figref idref="DRAWINGS">FIG. 36</figref> illustrates a public entity <b>230</b>, according to exemplary embodiments. Here exemplary embodiments may be applied to public data <b>232</b> generated by the public entity <b>230</b>. The public entity <b>230</b> may be a city, state, or federal governmental agency, but the public entity <b>230</b> may also be a contractor, non-governmental organization, or other actor that acts on behalf of the governmental agency. The public entity <b>230</b> operates a public server <b>234</b> and applies its software application <b>236</b> to its public data <b>232</b> to generate its governmental blockchain <b>238</b>. The public entity <b>230</b> may further generate/issue its cryptocoinage <b>240</b> and offer digital contracts <b>20</b> for governmental, public services. The data layer server <b>74</b> receives the governmental blockchain <b>238</b> and generates the blockchain data layer <b>72</b>. The data layer server <b>74</b> may then generate the public blockchain <b>76</b> representing any data records <b>70</b> representing the public data <b>232</b> and/or the cryptocoinage <b>240</b>.

0190<figref idref="DRAWINGS">FIGS. 37-40</figref> further illustrate contractual execution, according to exemplary embodiments. When the contract server <b>42</b> (such as the data layer server <b>74</b>) receives the blockchain <b>24</b>, exemplary embodiments inspect the blockchain <b>24</b> to identify the contract identifier <b>28</b> and/or the contractual parameters <b>30</b>. The contract identifier <b>28</b> and/or the contractual parameters <b>30</b> may be contained within the block <b>26</b> of data within the blockchain <b>24</b>. The contract identifier <b>28</b> and/or the contractual parameters <b>30</b> may be additionally or alternatively be metadata contained within the block <b>26</b> of data, and/or the contract identifier <b>28</b> and/or the contractual parameters <b>30</b> may be a data, data field, and/or a file attachment. The contract identifier <b>28</b> and/or the contractual parameters <b>30</b> may be information or data specified by the blockchain <b>24</b> and/or by a packet header or body. Regardless, once the contract identifier <b>28</b> and/or the contractual parameters <b>30</b> are determined, exemplary embodiments may consult the electronic database <b>44</b> of contracts.

0191<figref idref="DRAWINGS">FIG. 38</figref> illustrates the database <b>44</b> of contracts. While the database <b>44</b> of contracts may have any logical structure, a relational database is perhaps easiest to understand. <figref idref="DRAWINGS">FIG. 38</figref> thus illustrates the database <b>44</b> of contracts as an electronic table <b>250</b> that maps, converts, or translates the contract identifier <b>28</b> and/or the contractual parameters <b>30</b> to their corresponding network resource(s) <b>50</b>. The database <b>44</b> of contracts may thus be preconfigured or preloaded with entries that assign or associate different contract identifiers <b>28</b> and/or contractual parameters <b>30</b> to their corresponding network resource <b>50</b> that provides, processes, and/or executes the corresponding digital contract <b>20</b>. As the data layer server <b>74</b> receives any blockchain <b>24</b>, the data layer server <b>74</b> may inspect the blockchain <b>24</b> for the contract identifier <b>28</b> and/or the contractual parameters <b>30</b>. The data layer server <b>74</b> may then query the database <b>44</b> of contracts for the contract identifier <b>28</b> and/or the contractual parameters <b>30</b> to identify the computer file <b>46</b>, server <b>254</b>, virtual machine <b>256</b>, Internet protocol address <b>258</b>, or other network resource <b>50</b> that is responsible for executing the digital contract <b>20</b>. The database <b>44</b> of contracts may optionally contain entries that relate hashed values of the contract identifier <b>28</b> and/or the contractual parameters <b>30</b>. Regardless, once the network resource <b>50</b> is identified, the data layer server <b>74</b> may direct, assign, or outsource the contractual information <b>30</b> to the network resource <b>50</b> for processing.

0192<figref idref="DRAWINGS">FIG. 39</figref> illustrates a simple example. Here the contract identifier <b>28</b> maps to a filename <b>260</b> that is associated with, or that represents, the computer file <b>46</b> that contains the programming language representing the digital contract <b>20</b>. So, once the filename <b>260</b> is determined, the data layer server <b>74</b> may locally retrieve and execute the computer file <b>46</b> that corresponds to, or is associated with, the filename <b>260</b>. The data layer server <b>74</b> may then execute the computer file <b>46</b>, perhaps based on parameters defined or described by the contractual parameters <b>30</b> (such as party names, parameters associated with their respective performance obligations and terms, and consideration). Optionally, the data layer server <b>74</b> may retrieve the computer file <b>46</b> (perhaps via the communications network <b>146</b> illustrated by <figref idref="DRAWINGS">FIGS. 22-23</figref>) from a remote server, database, or other device. Regardless, as the computer file <b>46</b> is executed, the data layer server <b>74</b> may generate the data records <b>70</b> in the blockchain data layer <b>72</b> describing the execution of the computer file <b>46</b>. For example, the data records <b>70</b> may sequentially and/or serially track the execution of the computer file <b>46</b>, perhaps logging or documenting periodic or random updates as the computer file <b>46</b> executes, perhaps along with timestamps toward completion. The data records <b>70</b> may also log or document a final step or outcome of the programming language representing the digital contract <b>20</b>. Again, then, the blockchain <b>24</b> only referenced the digital contract <b>20</b> (using the contract identifier <b>28</b> and/or the contractual parameters <b>30</b>). The actual execution of the digital contract <b>20</b> may be offloaded or outsourced to the data layer server <b>74</b>.

0193<figref idref="DRAWINGS">FIG. 40</figref> illustrates another example. Here the data layer server <b>74</b> may only manage the execution of the digital contract <b>20</b> referenced by the contract identifier <b>28</b> and/or the contractual parameters <b>30</b>. That is, the data layer server <b>74</b> may outsource the execution of the digital contract <b>20</b> to a vendor or supplier as a subcontractor process. Again, when the data layer server <b>74</b> receives the blockchain <b>24</b>, the data layer server <b>74</b> inspects the blockchain <b>24</b> to identify the contract identifier <b>28</b> and/or the contractual parameters <b>30</b>. The data layer server <b>74</b> may then consult the database <b>44</b> of contracts. Here, though, the database <b>44</b> of contracts has entries that map or relate the contract identifier <b>28</b> to a remote server <b>262</b> that executes the digital contract <b>20</b> as a cloud-based service (perhaps as a software-as-a-service or SAAS). The database <b>44</b> of contracts may thus associate the contract identifier <b>28</b> to the Internet protocol address <b>258</b> representing the remote server <b>262</b> that executes the digital contract <b>20</b>. The database <b>44</b> of contracts may additionally or alternatively associate the contract identifier <b>28</b> to a uniform resource locator (or “URL”) <b>264</b> representing the remote server <b>262</b> that executes the digital contract <b>20</b>. Regardless, once the remote server <b>262</b> is determined, the data layer server <b>74</b> may retrieve and send a service request <b>266</b> to the remote server <b>262</b> (via the Internet protocol address <b>258</b> and/or the URL <b>264</b> representing the remote server <b>262</b>). The service request <b>266</b> specifies the contract identifier <b>28</b> and requests an execution of the corresponding digital contract <b>20</b>. The service request <b>266</b> may also specify the contractual parameters <b>30</b>. When the remote server <b>262</b> (perhaps operated on behalf of a third party) receives the service request <b>266</b>, the remote server <b>262</b> applies the parameters defined or described by the contractual parameters <b>30</b> to the programming code (such as the computer file <b>46</b>) representing the digital contract <b>20</b>. Once the digital contract <b>20</b> is executed, the remote server <b>262</b> may then send a service response <b>268</b> back to the data layer server <b>74</b>, and the service response <b>268</b> comprises data or information describing an outcome of the digital contract <b>20</b> (such as consideration, payment, or performance terms).

0194The data layer server <b>74</b> may generate the data records <b>70</b> in the blockchain data layer <b>72</b>. For example, the data records <b>70</b> may document the date and time that the service request <b>266</b> was sent to the remote server <b>262</b>. Moreover, as the remote server <b>262</b> provides the digital contract <b>20</b> as a service, the remote server <b>262</b> may send periodic or random service updates <b>270</b> as the service is provided along with timestamps toward completion. The data layer server <b>74</b> may thus generate the data records <b>70</b> describing the service updates <b>270</b> received from the remote server <b>262</b>. The data layer server <b>74</b> may also generate the data records <b>70</b> describing the service response <b>268</b> sent from the remote server <b>262</b> describing an outcome of the digital contract <b>20</b>.

0195<figref idref="DRAWINGS">FIGS. 41-42</figref> illustrate virtual execution, according to exemplary embodiments. Here the data layer server <b>74</b> may outsource or subcontract the execution of the digital contract <b>20</b> to a virtual machine (or “VM”) <b>280</b>. For example, the data layer server <b>74</b> may implement different virtual machines <b>190</b>, with each virtual machine <b>190</b> processing and/or executing a particular digital contract <b>20</b>, perhaps as a software service. The data layer server <b>74</b> may provide virtual computing and/or virtual hardware resources to client devices, thus lending or sharing its hardware, computing, and programming resources. The data layer server <b>74</b> may thus operate or function as a virtual, remote resource for providing contractual execution as software services. Suppose, for example, that the data layer server <b>74</b> implements four (4) virtual machines <b>280</b><i>a</i>-<i>d</i>. In practice, though, the data layer server <b>74</b> may implement any number or instantiations of different virtual machines <b>280</b> and/or digital contracts <b>20</b>, depending on complexity and resources. Moreover, as a further simplification, assume that each virtual machine <b>280</b><i>a</i>-<i>d </i>executes a different corresponding digital contract <b>20</b><i>a</i>-<i>d</i>. So, when the data layer server <b>74</b> receives the blockchain <b>24</b>, the data layer server <b>74</b> may inspect the blockchain <b>24</b> for each contract identifier <b>28</b><i>a</i>-<i>d </i>and/or the corresponding contractual information <b>28</b><i>a</i>-<i>d </i>and consult the database <b>44</b> of contracts.

0196<figref idref="DRAWINGS">FIG. 42</figref> further illustrates the database <b>44</b> of contracts. Here the database <b>44</b> of contracts may include entries that map the contract identifier <b>28</b> to the corresponding virtual machine <b>280</b>. The database <b>44</b> of contracts may thus be preconfigured or preloaded with entries that assign or associate each virtual machine <b>280</b> to its corresponding contract identifier <b>28</b>. Once the virtual machine <b>280</b> is identified, the data layer server <b>74</b> may then coordinate and/or manage the execution of the corresponding digital contract <b>20</b>, perhaps based on the contract information <b>30</b>. Suppose, for example, that the data layer application <b>154</b> has programming or code that functions or performs as a query handler. The data layer application <b>154</b> inspects the blockchain <b>24</b> for the contract identifier <b>28</b> and queries the database <b>44</b> of contracts (as above explained). The data layer application <b>154</b> thus identifies and/or retrieves the corresponding virtual machine <b>280</b>. Exemplary embodiments may thus determine whether contract identifier <b>28</b> matches or satisfies any of the entries specified by the database <b>44</b> of contracts. <figref idref="DRAWINGS">FIG. 42</figref> illustrates entries that map the contract identifier <b>28</b> to its corresponding virtual machine <b>280</b> (e.g., an address, processor core, identifier, or other indicator).

0197The digital contract <b>20</b> may then be executed. For example, once the contract identifier <b>28</b> and the virtual machine <b>280</b> are determined, the virtual machine <b>280</b> may then call, retrieve, and/or execute the computer file <b>46</b> that provides the digital contract <b>20</b> as a virtual service or process. <figref idref="DRAWINGS">FIG. 42</figref> illustrates the computer file <b>46</b> locally stored and executed by the data layer server <b>74</b>, but the computer file <b>46</b> may be remotely stored, retrieved, and/or executed. Regardless, the virtual machine <b>280</b> may be instructed to retrieve, execute, and/or apply the computer file <b>46</b>, perhaps based on the contractual information <b>30</b>.

0198<figref idref="DRAWINGS">FIG. 42</figref> also illustrates software services. Here the database <b>44</b> of contracts may include entries that map the contract identifier <b>28</b> to a corresponding software service provided by the virtual machine <b>280</b>. Exemplary embodiments, in other words, may relate the contract identifier <b>28</b> to a service identifier <b>282</b>. The service identifier <b>282</b> is any alphanumeric combination, data, or hash value that uniquely identifies a software service <b>284</b> provided by the virtual machine <b>280</b>. Once the contract identifier <b>28</b>, the software service <b>284</b>, and/or the virtual machine <b>280</b> are determined, the virtual machine <b>280</b> may then provide the software service <b>284</b>. The software service <b>284</b> may execute the digital contract <b>20</b>, perhaps based on the contractual information <b>30</b>.

0199<figref idref="DRAWINGS">FIG. 43</figref> illustrates cryptographic affinities, according to exemplary embodiments. Here the data layer server <b>74</b> may create or generate a cryptographic affinity <b>290</b> describing contractual execution. This disclosure above explained how the data layer server <b>74</b> may generate the data records <b>70</b> in the blockchain data layer <b>72</b>. This disclosure also above explained how the data records <b>70</b> may document execution of the digital contract <b>20</b>. Here, then, the cryptographic affinity <b>290</b> may uniquely identify the digital contract <b>20</b> executed by the virtual machine <b>280</b>. For example, once the contract identifier <b>28</b> and the virtual machine <b>280</b> are determined (as above explained), the hashing algorithm <b>148</b> may generate a unique hash value <b>150</b>. That is, the hashing algorithm <b>148</b> may hash the contract identifier <b>28</b> with a virtual machine (“VM”) identifier <b>292</b> to generate the cryptographic affinity <b>290</b>. The virtual machine identifier <b>292</b> is any alphanumeric combination, data, or hash value that uniquely identifies the virtual machine <b>280</b>. The cryptographic affinity <b>290</b> may then be documented by the data records <b>70</b> in the blockchain data layer <b>72</b>, thus evidencing the execution of the digital contract <b>20</b>. Indeed, the cryptographic affinity <b>290</b> may be published via the public blockchain <b>76</b> as the cryptographic proof <b>80</b>, thus further publicly evidencing the execution of the digital contract <b>20</b>.

0200<figref idref="DRAWINGS">FIG. 44</figref> illustrates virtual assignments based on the blockchain data layer <b>72</b>, according to exemplary embodiments. As this disclosure previously explained, exemplary embodiments may generate the data records <b>70</b> representing the blockchain data layer <b>72</b> (such as the entries <b>180</b>, the entry blocks <b>182</b>, and/or the directory blocks <b>184</b> explained with reference to <figref idref="DRAWINGS">FIGS. 25-27</figref>). Exemplary embodiments may thus assign the blockchain <b>24</b> and/or the virtual machine <b>280</b> that executes the digital contract <b>20</b>, based on the number of the entries <b>180</b>, the entry blocks <b>182</b>, and/or the directory blocks <b>184</b> generated within the blockchain data layer <b>72</b>. For example, as the data records <b>70</b> are generated, the data layer server <b>74</b> may determine a rate <b>290</b> of generation. That is, as the data records <b>70</b> are generated when or while executing the digital contract <b>20</b>, exemplary embodiments may sum or count the entries <b>180</b>, the entry blocks <b>182</b>, and/or the directory blocks <b>184</b> that are generated over time (such as per second, per minute, or other interval). Exemplary embodiments, for example, may call or initialize a counter having an initial value (such as zero). At an initial time (such as when the blockchain <b>24</b> is received or when the contract identifier <b>28</b> is determined), the counter commences or starts counting or summing the number of the entries <b>180</b>, the entry blocks <b>182</b>, and/or the directory blocks <b>184</b> (generated within the blockchain data layer <b>72</b>) that are commonly associated with or reference the blockchain <b>24</b> (perhaps according to the chain ID <b>174</b>) and/or the contract identifier <b>28</b>. The counter stops counting or incrementing at a final time and exemplary embodiments determine or read the final value or count. Exemplary embodiments may then calculate the rate <b>290</b> of generation as the sum or count over time and consult or query the electronic database <b>44</b> of contracts for the rate <b>290</b> of generation. Exemplary embodiments may thus define entries that map or associate different rates <b>290</b> of generation and/or ranges to their corresponding contract identifier <b>28</b> and/or virtual machines <b>280</b>. If the database <b>44</b> of contracts has an entry that matches or satisfies the rate <b>290</b> of generation, exemplary embodiments identify the corresponding virtual machine <b>280</b>.

0201The rate <b>290</b> of generation may thus be a feedback mechanism. As the blockchain <b>24</b> is received. the data records <b>70</b> are requested, and/or the digital contract <b>20</b> is executed, the rate <b>290</b> of generation of the data records <b>70</b> may determine the virtual machine <b>280</b> that is assigned adequate capacity or bandwidth. One of the blockchains <b>24</b> and/or virtual machines <b>280</b>, for example, may be reserved for digital contracts <b>20</b> having a heavy, disproportionate, or abnormally large rate <b>290</b> of generation. Another of the blockchains <b>24</b> and/or virtual machines <b>280</b> may be reserved for digital contracts <b>20</b> having a medium, intermediate, or historically average rate <b>290</b> of generation. Still another blockchain <b>24</b> and/or virtual machine <b>280</b> may be reserved for the digital contracts <b>20</b> having a light, low, or historically below average rate <b>290</b> of generation. The rate <b>290</b> of generation may thus be a gauge or measure of which blockchain <b>24</b>, digital contract <b>20</b>, and/or virtual machine <b>280</b> is assigned the resources.

0202Exemplary embodiments thus include a service environment. Exemplary embodiments may manage and/or execute many different digital contracts <b>20</b> offered by many different vendors or suppliers. Indeed, the data layer server <b>74</b> may manage or even execute the digital contracts <b>20</b> while also generating the blockchain data layer <b>72</b> as still another service. The data layer server <b>74</b> may thus acts as a subcontractor or service provider, perhaps in a subscription or other compensation scheme. Any customer or client (such as the entity server <b>140</b> explained with reference to <figref idref="DRAWINGS">FIGS. 22-23</figref>) may thus send or forward its private blockchain <b>24</b> (generated from its private data <b>36</b>) to the data layer server <b>74</b> for management or execution of any digital contract <b>20</b>. The data layer server <b>74</b> may generate the data records <b>70</b> of the blockchain data layer <b>72</b> that document the management or execution of any digital contract <b>20</b>. Moreover, the data layer server <b>74</b> may publicly publish the cryptographic proof <b>80</b> within the public blockchain <b>76</b>, thus further documenting immutable evidence of the management or execution of any digital contract <b>20</b>. Indeed, the entity server <b>140</b> may also generate the blocks <b>26</b> of data within the private blockchain <b>24</b> that also document the date and time that the management or execution of any digital contract <b>20</b> was sent/requested. The entity server <b>140</b> may then pay or reward the data layer server <b>74</b> in exchange for the digital contract <b>20</b> and/or the data records <b>70</b> in the blockchain data layer <b>72</b> (such as granting its crytpocoinage <b>60</b> and <b>120</b>, as explained with reference to <figref idref="DRAWINGS">FIG. 19</figref>).

0203The data layer server <b>74</b> may thus serve many blockchains <b>24</b> requesting many different contractual services. The financial institution <b>34</b>, for example, may send or forward its private blockchain <b>36</b><i>a </i>(as illustrated with reference to <figref idref="DRAWINGS">FIGS. 20-21</figref>) to the data layer server <b>74</b> for application or execution of any digital contract <b>20</b> (by specifying the contract identifier <b>20</b>, as above explained). The retailer <b>122</b> may similarly send or forward its private blockchain <b>36</b><i>b </i>to the data layer server <b>74</b> for application or execution of any digital contract <b>20</b>. The online website <b>124</b> may also send or forward its private blockchain <b>36</b><i>c </i>to the data layer server <b>74</b> for application or execution of any digital contract <b>20</b>. The data layer server <b>74</b> may generate the data records <b>70</b> of the blockchain data layer <b>72</b> that document the management and/or execution of any digital contract <b>20</b>, and the data layer server <b>74</b> may publicly publish each cryptographic proof <b>80</b> within the public blockchain <b>76</b>, thus further documenting immutable evidence of the management and/or execution of any digital contract <b>20</b>. The entity <b>32</b> may then pay or reward the data layer server <b>74</b> via their respective crytpocoinage <b>60</b> and <b>120</b>.

0204Exemplary embodiments thus only need to identify the digital contract <b>20</b>. The contract identifier <b>28</b> and the contractual parameters <b>30</b> need only be informational content in the private blockchain <b>24</b>. The contract identifier <b>28</b> is any digital identifying information that uniquely identifies or references the digital contract <b>20</b>. The contract identifier <b>28</b> may be an alphanumeric combination that uniquely identifies a vendor and/or version of the digital contract <b>20</b> and/or a processor or executioner of the digital contract <b>20</b>. The contract identifier <b>28</b> may be expressed as a unique hash value that is included within, or specified by, the private blockchain <b>24</b>. Similarly, the contractual parameters <b>30</b> may identify the parties to the digital contract <b>20</b>, their respective performance obligations and terms, and consideration.

0205<figref idref="DRAWINGS">FIGS. 45-51</figref> illustrate an architectural scheme, according to exemplary embodiments. This disclosure above explained that the data layer server <b>74</b> may only manage the execution of the digital contract <b>20</b>. The implementation and/or actual execution of the digital contract <b>20</b> may thus be separate from the data layer server <b>74</b> that generates the blockchain data layer <b>72</b>. <figref idref="DRAWINGS">FIG. 45</figref>, for example, illustrates the data layer server <b>74</b> communicating via the communications network <b>142</b> with the remote server <b>262</b>. The data layer server <b>74</b> generates the blockchain data layer <b>72</b>, and the remote server <b>262</b> executes at least some portion of the digital contract <b>20</b>. The remote server <b>262</b> may thus have a hardware processor <b>300</b> (e.g., “μP”), application specific integrated circuit (ASIC), or other component that executes a contract application <b>302</b> stored in a local memory device <b>304</b>. The remote server <b>262</b> has a network interface to the communications network <b>142</b>, thus allowing two-way, bidirectional communication with the data layer server <b>74</b>. The contract application <b>302</b> includes instructions, code, and/or programs that cause the remote server <b>262</b> to perform operations, such as executing at least some portion of the digital contract <b>20</b>.

0206<figref idref="DRAWINGS">FIG. 46</figref> illustrates a request mechanism. The data layer application <b>154</b>, for example, identifies the contract identifier(s) <b>28</b> and/or the contractual parameters <b>30</b> associated with or representing the digital contract <b>20</b>. The contract identifier(s) <b>28</b> and/or the contractual parameters <b>30</b> may be sent to the data layer server <b>74</b> as an input (such as from the entity server <b>140</b>, as explained with reference to <figref idref="DRAWINGS">FIGS. 22-24</figref>), or the contract identifiers <b>28</b> and/or the contractual parameters <b>30</b> may be contained as information in the private blockchain <b>24</b>. Regardless, the data layer server <b>74</b> may then identify the network address, IP address, URL, or other nomenclature representing the remote server <b>262</b> that executes at least some portion of the digital contract <b>20</b> (perhaps via the database <b>44</b> of contracts, as earlier explained). The data layer server <b>74</b> sends the service request <b>266</b> to the remote server <b>262</b>, and the service request <b>266</b> may include or specify the contract identifier <b>28</b> and/or the contractual parameters <b>30</b>. When the remote server <b>262</b> receives the service request <b>266</b>, the remote server <b>262</b> applies the contractual parameters <b>30</b> to the portion of the digital contract <b>20</b> and generates a contractual result <b>306</b>. The remote server <b>262</b> may then send the service response <b>268</b> back to the data layer server <b>74</b>, and the service response <b>268</b> may comprise the contractual result <b>306</b>.

0207Exemplary embodiments may thus exchange inputs and outputs. When the data layer server <b>74</b> sends the service request <b>266</b> to the remote server <b>262</b>, the service request <b>266</b> may include or specify one or more of the contract identifiers <b>28</b> and/or the contractual parameters <b>30</b>. Suppose, for example, that the contract identifiers <b>28</b> and/or the contractual parameters <b>30</b> are represented as hash values. The hash values may be identified from, or specified by, the private blockchain <b>24</b>. The hash values may additionally or alternatively be generated by the data layer application <b>154</b> (such as by calling, invoking, or executing the hashing algorithm <b>148</b>, as above explained). Regardless, the service request <b>266</b> may thus include or specify the hash values representing the contract identifiers <b>28</b> and/or the contractual parameters <b>30</b>. When the remote server <b>262</b> receives the service request <b>266</b>, the contract application <b>302</b> may use or accept the hash values as inputs to generate the contractual result <b>306</b> as an output. The contract application <b>302</b> may further encrypt the contractual result <b>306</b> (such as calling, invoking, or executing the hashing algorithm <b>148</b>) to generate another hash value representing the contractual result <b>306</b>.

0208Exemplary embodiments provide contractual proofs. When the data layer server <b>74</b> sends the service request <b>266</b> to the remote server <b>262</b>, the data records <b>70</b> may document the service request <b>266</b> as one of the cryptographic proofs <b>80</b>. When the data layer server <b>74</b> receives the service response <b>268</b>, the data records <b>70</b> document that receipt and the contractual result <b>306</b> as another one of the cryptographic proofs <b>80</b>. The data records <b>70</b> thus prove that at least the portion of the digital contract <b>20</b> was outsourced to a vendor or supplier as a subcontractor process or assignment. The data records <b>70</b> also prove that at least the portion of the digital contract <b>20</b> was executed to provide the contractual result <b>306</b>. The data layer server <b>74</b> may then compare the contractual result <b>306</b> (such as its hash value) to a predefined or expect value. If the contractual result <b>306</b> matches or equals the predefined or expect value, then the data layer application <b>154</b> may be programmed or coded to infer that the contract successfully executed and/or the vendor or supplier performed as obligated. However, if the contractual result <b>306</b> fails to match or equal the predefined or expect value, then the data layer application <b>154</b> may be programmed or coded to infer that the contract is not satisfied and/or the vendor or supplier failed to perform as obligated.

0209<figref idref="DRAWINGS">FIG. 47</figref> illustrates a layered contractual process. Here the digital contract <b>20</b> may have different or individual components, portions, or sub-parts that cumulatively combine to produce the contractual result <b>306</b>. The different components, portions, or sub-parts may be software modules <b>310</b> that can be separately executed to generate the overall or final contractual result <b>306</b>. A simple digital contract <b>20</b>, for example, may only have a few or several software subroutines or modules <b>310</b>, while a complex or complicated digital contract <b>20</b> may have many or hundreds of different software subroutines or modules <b>310</b>. As the reader likely understands, such a complicated software structure is too difficult to illustrate. For simplicity, then, <figref idref="DRAWINGS">FIG. 47</figref> illustrates the digital contract <b>20</b> having four (4) software modules <b>310</b><i>a</i>-<i>d</i>. The entire contract application <b>302</b>, in other words, may have four (4) different application layers <b>312</b><i>a</i>-<i>d</i>. Each componentry module <b>310</b><i>a</i>-<i>d </i>or layer <b>312</b><i>a</i>-<i>d </i>may have its own corresponding contract identifier <b>28</b><i>a</i>-<i>d</i>. When the remote server <b>262</b> receives the service request <b>266</b>, exemplary embodiments may then feed the contractual parameters <b>30</b> as inputs <b>314</b><i>a</i>-<i>d </i>to the software modules <b>310</b><i>a</i>-<i>d</i>. Each different software module <b>310</b> may thus generate its respective or corresponding output <b>316</b><i>a</i>-<i>d</i>, which may be combined or processed to generate the overall or final contractual result <b>306</b>.

0210<figref idref="DRAWINGS">FIG. 48</figref> illustrates hierarchical execution. Here the different software modules <b>310</b> may be serially or sequentially executed to generate the overall or final contractual result <b>306</b>. For example, the software module <b>310</b><i>a </i>may accept at least some of the contractual parameters <b>30</b> as the input <b>314</b><i>a</i>, execute its respective programming code, and generate its corresponding output <b>316</b><i>a</i>. Here, though, the output <b>316</b><i>a </i>may then be routed or sent to the software module <b>310</b><i>b </i>(illustrated as the application layer <b>312</b><i>b</i>) as its input <b>314</b><i>b</i>. Its respective programming code is then executed to generate its corresponding output <b>316</b><i>b</i>, based on the output <b>316</b><i>a </i>generated by or received from the software module <b>310</b><i>a</i>. Similarly, software module <b>310</b><i>c </i>accepts the output <b>316</b><i>b </i>and generates output <b>316</b><i>c</i>, which is received by software module <b>310</b><i>d </i>as input <b>314</b><i>d </i>and used to generate the output <b>316</b><i>d</i>. While exemplary embodiments may continue processing the outputs <b>316</b><i>a</i>-<i>d </i>to generate any desired outcome, for simplicity <figref idref="DRAWINGS">FIG. 40</figref> illustrates the output <b>316</b><i>d </i>as the final contractual result <b>306</b>. Exemplary embodiments may thus use the software modules <b>310</b><i>a</i>-<i>d </i>as feedback mechanisms to monitor or even enforce contractual rule-based obligations defined or specified by the digital contract <b>20</b>.

0211<figref idref="DRAWINGS">FIG. 49</figref> illustrates the blockchain data layer <b>72</b>. Here the blockchain data layer <b>72</b> may document the processing and/or execution of each software module <b>310</b><i>a</i>-<i>d</i>, its respective input(s) <b>314</b><i>a</i>-<i>d</i>, its respective output(s) <b>316</b><i>a</i>-<i>d</i>, and perhaps a corresponding timestamp (not shown for simplicity). The data records <b>70</b> may further document or record the corresponding contract identifier <b>28</b><i>a</i>-<i>d </i>and/or the chain identifier <b>174</b>. The data layer server <b>74</b> may thus receive the service updates <b>270</b> (via the communications network <b>142</b>) as each software module <b>310</b><i>a</i>-<i>d </i>performs or executes its corresponding contractual service. The data layer server <b>74</b> may then generate the data records <b>70</b> in the blockchain data layer <b>72</b>, thus documenting each software component's contribution toward the overall or final contractual result <b>306</b>. The data records <b>70</b> may also be hashed to generate the cryptographic proofs <b>80</b>, as above explained.

0212<figref idref="DRAWINGS">FIG. 50</figref> also illustrates contractual execution. Here, though, the different software modules <b>310</b> may be executed by different devices. Suppose, for example, that the remote server <b>262</b><i>a </i>locally stores and executes the software module <b>310</b><i>a</i>, while the remote server <b>262</b><i>b </i>locally stores and executes the software module <b>310</b><i>b</i>. Suppose also that the remote server <b>262</b><i>c </i>locally stores and executes the software module <b>310</b><i>c </i>and the remote server <b>262</b><i>d </i>locally stores and executes the software module <b>310</b><i>d</i>. Exemplary embodiments may thus source or subcontract the different portions of the digital contract <b>20</b> to different machines for execution. The remote server <b>262</b><i>a</i>, for example, may specialize in the software module <b>310</b><i>a</i>. The remote server <b>262</b><i>a </i>may thus accept the service request <b>266</b> from clients, execute the software module <b>310</b><i>a</i>, and return send the service response <b>268</b> (as explained with reference to <figref idref="DRAWINGS">FIG. 46</figref>). The remote server <b>262</b><i>a </i>may also send the service update(s) <b>270</b> to the data layer server <b>74</b>, thus allowing the blockchain data layer <b>72</b> to document the contractual service provided by the software module <b>310</b><i>a</i>. The remote servers <b>262</b><i>b</i>-<i>d </i>may similarly specialize in the software modules <b>310</b><i>b</i>-<i>d </i>to provide their respective contractual services.

0213<figref idref="DRAWINGS">FIG. 51</figref> illustrates an overall architectural scheme. As the reader may envision, there may be hundreds, thousands, millions, or even billions of contractual relationships between many different parties. As smart, digital contracts grow in acceptance and usage, the blockchain data layer <b>72</b> is expected to exponentially grow, thus requiring ever-increasing hardware and software resources. In plain words, there may be many data layer servers <b>74</b> generating the data records <b>70</b> in the blockchain data layer <b>72</b>. While there may be hundreds or even thousands of data layer servers <b>74</b>, <figref idref="DRAWINGS">FIG. 51</figref> simply illustrates four (4) data layer servers <b>74</b><i>a</i>-<i>d </i>that cooperate to generate the blockchain data layer <b>72</b>. As the processing load increases or grows (such as according to the rate <b>290</b> of generation, as above explained), the number of data layer servers <b>74</b> may also grow.

0214The blockchain data layer <b>72</b> may thus be separate from an implementation and execution of the digital contract <b>20</b>. The data layer servers <b>74</b>, in other words, may be separately networked and/or addressed from the remote servers <b>262</b> providing the contractual services representing the software modules <b>310</b> of the digital contract <b>20</b>. Any of the data layer servers <b>74</b> may send data or information as inputs to any one of the remote servers <b>262</b>, and the corresponding software module <b>310</b> performs its contractual service and sends its output <b>316</b> back to the blockchain data layer <b>72</b> (perhaps via the service request <b>266</b>, the service response <b>268</b>, and the service update <b>270</b> as earlier explained and illustrated). Some of the remote servers <b>262</b> may provide virtual services, such as a virtual machine (as above explained) that executes any of the software modules <b>310</b>.

0215<figref idref="DRAWINGS">FIG. 52</figref> illustrates compliance scheme, according to exemplary embodiments. As the reader may understand, some smart, digital contracts have jurisdictional requirements. For example, the digital contract <b>20</b> may have programming code that requires an execution or processing in a particular region or country. That is, the digital contract <b>20</b> may have contractual rules and/or provisions that must be enforced in the United States, the European Union, or the Isle of Man. Components or portions of the digital contract <b>20</b> may require execution or location in the Cayman Islands, Idaho, or Hong Kong. The digital contract <b>20</b>, in other words, may have a geographic parameter <b>320</b>. The geographic parameter <b>320</b> may be a locational requirement, restriction, or preference for at least some portion of the digital contract <b>20</b>. The geographic parameter <b>320</b> can be any data, information, field, metadata, or code for enforcing the locational requirement, restriction, or preference. Indeed, the geographic parameter <b>320</b> may even be finely expressed or defined as global positioning system (“GPS”) information or coordinates at which at least some portion of the digital contract <b>20</b> must be processed or executed.

0216The geographic parameter <b>320</b> may be an input value. As <figref idref="DRAWINGS">FIG. 52</figref> illustrates, the geographic parameter <b>320</b> may be read or received via the private blockchain <b>24</b> (perhaps along with the contract identifier <b>28</b> and/or the contractual parameter <b>30</b>). The data layer server <b>74</b>, in other words, may identify the geographic parameter <b>320</b> as data, information, or a hash value contained within the block <b>26</b> of data. However, the geographic parameter <b>320</b> may additionally or alternatively be received and/or identified within a header of body/payload of a packet <b>322</b> of data (packetized according to the Internet Protocol, just as the contract identifier <b>28</b> and/or the contractual parameter <b>30</b> may be identified).

0217Regardless, once the geographic parameter <b>320</b> is determined, exemplary embodiments may again consult the database <b>44</b> of contracts. The database <b>44</b> of contracts may have entries that electronically associate the contract identifier(s) <b>28</b> and/or the contractual parameter(s) <b>30</b> to the geographic parameter <b>320</b>. The data layer application <b>154</b> may instruct the data layer server <b>74</b> to query the database <b>44</b> of contracts for either, any, or all of the contract identifiers <b>28</b>, the contractual parameters <b>30</b>, and/or the geographic parameters <b>320</b> to identify and/or retrieve the corresponding database entries. As a simple example, suppose a file component of the digital contract <b>20</b> must be processed in a particular geographic region (such as the British Virgin Islands or Canada). The corresponding contract identifier <b>28</b>, in other words, may be electronically associated with a particular geographic region, as defined by a tabular entry in the database <b>44</b> of contracts. Once the region is determined, the data layer server <b>74</b> may then route the contract identifier <b>28</b>, the contractual parameter <b>30</b>, and/or the geographic parameter <b>320</b> to the remote server <b>262</b> that is associated with, or even located within, the region. Exemplary embodiments, for example, may implement the service request <b>266</b>, the service response <b>268</b>, and the service update <b>270</b> (as earlier explained). The remote server <b>262</b> may then process or execute the digital contract <b>20</b> using the contract identifier <b>28</b> and/or the contractual parameter <b>30</b> (as this disclosure earlier explained).

0218Other examples explain the geographic parameter <b>320</b>. Suppose that the contract identifier <b>28</b> and/or the contractual parameter <b>30</b> map(s) to a particular server, cluster of servers, and/or a particular virtual machine (“VM”). The data layer server <b>74</b> may then route the contract identifier <b>28</b>, the contractual parameter <b>30</b>, and/or the geographic parameter <b>320</b> to the remote server <b>262</b> that is associated with the cluster of servers and/or the virtual machine. The remote server <b>262</b> may then process or execute the digital contract <b>20</b> using the contract identifier <b>28</b> and/or the contractual parameter <b>30</b> (as this disclosure earlier explained). More likely, though, the contract identifier <b>28</b> and/or the contractual parameter <b>30</b> will relate to a particular IP address or uniform resource locator (“URL”). The data layer server <b>74</b> may then route the contract identifier <b>28</b>, the contractual parameter <b>30</b>, and/or the geographic parameter <b>320</b> to the remote server <b>262</b> that is associated with the IP address or URL for processing (again, as this disclosure earlier explained).

0219Exemplary embodiments may thus implement contractual provisions. Some digital contracts <b>20</b> may require a particular server, perhaps implementing or hosting a particular website, network, authentication scheme, programming, or other geographic parameter <b>320</b>. Some parties to the digital contract <b>20</b> may also require a particular server, perhaps as specified by the geographic parameter <b>320</b>. Some digital contracts <b>20</b> may have compliance obligations, perhaps defined by a particular jurisdiction and expressed as the geographic parameter <b>320</b>. Servers, webpages, networks and other resources may be dedicated to specific jurisdictions, as expressed by the geographic parameter <b>320</b>.

0220<figref idref="DRAWINGS">FIGS. 53-59</figref> illustrate a decisional architecture and scheme, according to exemplary embodiments. Even though the blockchain environment <b>22</b> enables an execution of the smart, digital contract <b>20</b>, some digital contracts may be too complex and/or too cumbersome to implement on the blockchain <b>24</b>. As this disclosure above explains, exemplary embodiments may thus put smaller contractual components of the digital contract <b>20</b> on any blockchain (such as the private blockchain <b>24</b> or the public blockchain <b>76</b>), validate the contractual components (perhaps via the cryptographic proof <b>80</b>), incorporate the cryptographic proof <b>80</b> into a larger component of the digital contract <b>20</b>, and then validate the larger component.

0221Exemplary embodiments may further implement one or more decision tables <b>326</b>. As the reader may understand, the decision table <b>326</b> may be used to implement at least a component of the digital contract <b>20</b>. That is, the decision table <b>326</b> may represent one or more rules or logic conditions <b>328</b>, one or more inputs <b>330</b>, and one or more decisional outputs <b>332</b>. The decision table <b>326</b> may thus be visually represented as a table having rows and columns. In simple words, once the input <b>330</b> is known, a processing or execution engine (such as the entity server <b>140</b> or other device) electronically maps or associates the input <b>330</b> to the appropriate rule or logic condition <b>328</b> and generates the decisional output <b>332</b>. Exemplary embodiments may then log or record the decisional output <b>332</b>, along with its corresponding the input <b>330</b>, rule or logic condition <b>328</b>, and a date/time stamp.

0222Exemplary embodiments may thus document any decision. In general, the smart, digital contract <b>20</b> is an agreement between parties/participants about services, products, and/or money. In order to make the decisional output <b>332</b>, information is provided (such as the input <b>330</b>) and the rule or logic condition <b>328</b> is executed. In an interactive process, each party/participant might contribute data to a single decision. In other words, the parties may exchange data to perform the decisional output <b>332</b>. Exemplary embodiments may thus map each decisional output <b>332</b> (perhaps representing a decision model) to a decision taken by a single party. Each party, in other words, may communicatively exchange the result of its decision such that others can base their decisions on their decisional output <b>332</b>, thus collaboratively executing the different components of the digital contract <b>20</b>.

0223<figref idref="DRAWINGS">FIG. 54</figref> illustrates an impartial, trusted intermediary. When any party or participant to the digital contract <b>20</b> acts or executes, exemplary embodiments may log or archive their respective action(s). For example, the data layer server <b>74</b> may be informed of any decision-making process. Suppose, for example, that the entity <b>32</b> (acting as a party to the digital contract <b>20</b>) wishes to document or prove its contractual performance. That is, the entity server <b>140</b> sends its decisional output <b>332</b> (perhaps via the communications network <b>142</b> illustrated in <figref idref="DRAWINGS">FIGS. 22-23</figref>) to the data layer server <b>74</b> for documentation. The decisional output <b>332</b> may thus be read or received via the private blockchain <b>24</b> (perhaps along with the contract identifier <b>28</b> and/or the contractual parameter <b>30</b>). The data layer server <b>74</b>, in other words, may identify the decisional output <b>332</b>, along with its corresponding input <b>330</b>, its rule or logic condition <b>328</b>, and the date/time stamp, as data, information, or hash values contained within the block <b>26</b> of data (as <figref idref="DRAWINGS">FIG. 53</figref> illustrated). However, the decisional output <b>332</b> (and/or the contract identifier <b>28</b>, the contractual parameter <b>30</b>, the input <b>330</b>, the rule or logic condition <b>328</b>, and the date/time stamp) may additionally or alternatively be received and/or identified within a header of body/payload of the packet <b>322</b> of data (packetized according to the Internet Protocol).

0224Regardless, the data layer server <b>74</b> may then generate the data records <b>70</b> in the blockchain data layer <b>72</b>, as this disclosure above explained. The data records <b>70</b> log or record the decisional output <b>332</b> (sent from the party participant), along with its corresponding input <b>330</b>, the decision table <b>326</b>, the rule or logic condition <b>328</b>, and the date/time stamp of performance. The blockchain data layer <b>72</b>, in other words, provides neutral, documentary evidence that the party executed its transactional portion of the smart, digital contract <b>20</b>. Moreover, the blockchain data layer <b>72</b> may also add another layer of cryptographic hashing to generate the public blockchain <b>76</b> and the cryptographic proof <b>80</b>. The blockchain data layer <b>72</b> thus may again act as the validation service <b>78</b> that validates the party performed its portion of the digital contract <b>20</b>. Exemplary embodiments may thus be used as an audit trail to reconstruct the party's decision-making process and who provided the input <b>330</b>.

0225Exemplary embodiments may even document fine granularity. When the data layer server <b>74</b> receives the decisional output <b>332</b>, the data or information may even identify or pinpoint the network resource <b>250</b>. That is, when entity <b>32</b> (acting as a party to the digital contract <b>20</b>) wishes to document or prove its contractual performance, the decisional output <b>332</b> may even include data or information identifying the particular server <b>254</b> or cluster or virtual machine <b>256</b> that generated the decisional output <b>332</b>. Indeed, the data or information may even identify or pinpoint the particular IP address or uniform resource locator (“URL”). The data records <b>70</b> may thus document the machine, manufacturer, model, and/or chassis hardware inventory that performed the portion of the digital contract <b>20</b>.

0226<figref idref="DRAWINGS">FIG. 55</figref> illustrates contractual management. Here again the data layer server <b>74</b> may manage the execution of the digital contract <b>20</b>. When any party, participant, or subcontractor performs a portion or component of the digital contract <b>20</b>, the data layer server <b>74</b> may coordinate and validate the contractual components. Suppose again that the data layer server <b>74</b> receives the contract identifier <b>28</b> and/or the contractual parameters <b>30</b> (as earlier explained). The contract identifier <b>28</b> may represent a single, large digital contract <b>20</b>. The contract identifier <b>28</b>, however, may represent only a single or a few contractual components of the digital contract <b>20</b>. The contract identifier <b>28</b>, in other words, may map or relate to a sequence or series of one or more table identifiers <b>334</b>. Each table identifier <b>334</b> may be an alphanumeric combination or a unique hash value. Regardless, each table identifier <b>334</b> uniquely identifies the corresponding decision table <b>326</b> that decides a componentry portion of the digital contract <b>20</b>. When the data layer server <b>74</b> receives the one or more contract identifiers <b>28</b>, the data layer server <b>74</b> may then consult the database <b>44</b> of contracts.

0227<figref idref="DRAWINGS">FIG. 56</figref> further illustrates the database <b>44</b> of contracts. Here the database <b>44</b> of contracts may have additional entries that map or relate the contract identifier <b>28</b> to the table identifier <b>334</b> and/or to the network resource <b>250</b> that executes the corresponding componentry portion of the digital contract <b>20</b> (perhaps again as a cloud-based service). The contract identifier <b>28</b>, in other words, may map or relate to a sequence or series of one or more table identifiers <b>334</b>. Each table identifier <b>334</b> may be an alphanumeric combination or a unique hash value. Regardless, each table identifier <b>334</b> uniquely identifies the corresponding decision table <b>326</b> that decides a componentry portion of the digital contract <b>20</b>. When the data layer server <b>74</b> receives the one or more contract identifiers <b>28</b>, the data layer server <b>74</b> may then consult the database <b>44</b> of contracts to determine any corresponding entry (as this disclosure above explains).

0228<figref idref="DRAWINGS">FIG. 57</figref> illustrates outsourcing. Once the network resource <b>50</b> is determined (recall that the network resource <b>50</b> may execute the corresponding componentry portion of the digital contract <b>20</b>), the data layer server <b>74</b> may utilize the request mechanism. Suppose, for example, that the database <b>44</b> of contracts identifies the remote server <b>262</b> as the network resource <b>50</b>. The data layer server <b>74</b> may thus instruct the remote server <b>262</b> to execute the corresponding decision table <b>326</b>. The data layer server <b>74</b>, for example, sends the service request <b>266</b> (as earlier explained), and the service request <b>266</b> may specify the table identifier <b>334</b> and/or the input <b>330</b> as the contractual parameters <b>30</b>. When the remote server <b>262</b> receives the service request <b>266</b>, the remote server <b>262</b> applies the input <b>330</b> to the decision table <b>326</b> representing the digital contract <b>20</b>. Once the decisional output <b>332</b> is determined, the remote server <b>262</b> may then send the service response <b>268</b> back to the data layer server <b>74</b>, and the service response <b>268</b> comprises data or information describing the decisional output <b>332</b>. The data layer server <b>74</b> may generate the data records <b>70</b> in the blockchain data layer <b>72</b> that document the service request <b>266</b> and the service response <b>268</b>, perhaps including any service updates <b>270</b> as the decision table <b>326</b> is executed.

0229<figref idref="DRAWINGS">FIG. 58</figref> illustrates contractual participation. Here the data layer server <b>74</b> may execute at least a componentry portion of the digital contract <b>20</b>. That is, the data layer server <b>74</b> may locally store and/or access one or more of the decision tables <b>326</b> representing the digital contract <b>20</b>. When the data layer server <b>74</b> receives the contract identifier <b>28</b> and/or the contractual parameters <b>30</b> (as earlier explained), the data layer server <b>74</b> may consult the database <b>44</b> of contracts. Here, though, the database <b>44</b> of contracts has one or more entries that map or relate the contract identifier <b>28</b> to the virtual machine <b>280</b> that executes the decision table <b>326</b>. The database <b>44</b> of contracts may thus electronically associate the contract identifier <b>28</b> to the table identifier(s) <b>334</b> and the virtual machine(s) <b>280</b> that locally execute the decision table(s) <b>326</b>. The decisions table <b>326</b> may thus have virtual assignments. Once the virtual machine <b>280</b> and/or the decision table <b>326</b> is determined, the virtual machine <b>280</b> is requested or instructed to apply the input <b>330</b> to the corresponding decision table <b>326</b> to generate the decisional output <b>332</b>. The data layer server <b>74</b> may then generate the data records <b>70</b> in the blockchain data layer <b>72</b> that document the local contractual performance (as earlier explained).

0230As <figref idref="DRAWINGS">FIG. 58</figref> illustrates, feedback may be used. Exemplary embodiments may assign the virtual machine <b>280</b> based on the data records <b>70</b> in the blockchain data layer <b>72</b>. That is, as the decision table <b>326</b> consumes more and more of the data records <b>70</b> (e.g., the number of the entries <b>180</b>, the entry blocks <b>182</b>, and/or the directory blocks <b>184</b> generated within the blockchain data layer <b>72</b>, as earlier explained), the rate <b>290</b> of generation may be used as a feedback mechanism (as this disclosure earlier explained). Highly used or called decision tables <b>326</b>, in other words, may be assigned to virtual machines <b>280</b> having greater capacity or bandwidth. The database <b>44</b> of contracts may thus define entries that map or associate different rates <b>290</b> of generation and/or ranges to their corresponding table identifier <b>334</b> and/or virtual machines <b>280</b>. If the database <b>44</b> of contracts has an entry that matches or satisfies the rate <b>290</b> of generation, exemplary embodiments identify the corresponding virtual machine <b>280</b>. Some virtual machines <b>280</b>, for example, may be reserved for decision tables <b>326</b> having a heavy, disproportionate, or abnormally large rate <b>290</b> of generation. Other virtual machines <b>280</b> may be reserved for decision tables <b>326</b> having intermediate and low rates <b>290</b> of generation. The rate <b>290</b> of generation may thus be a gauge or measure of which virtual machine <b>280</b> is assigned the decision table <b>326</b>.

0231Exemplary embodiments thus include a service environment. Exemplary embodiments may manage and/or execute many different decision tables <b>326</b> offered by many different vendors or suppliers. Indeed, the data layer server <b>74</b> may manage or even execute the digital contracts <b>20</b> while also generating the blockchain data layer <b>72</b> as still another service. The data layer server <b>74</b> may thus acts as a subcontractor or service provider, perhaps in a subscription or other compensation scheme. Any customer or client may thus send or forward its input <b>330</b> and/or its decisional output <b>332</b> to the data layer server <b>74</b> for management or execution of any digital contract <b>20</b>. The data layer server <b>74</b> may generate the data records <b>70</b> of the blockchain data layer <b>72</b> that document the management or execution of any portion of component of the digital contract <b>20</b>. Moreover, the data layer server <b>74</b> may publicly publish the cryptographic proof <b>80</b> within the public blockchain <b>76</b>, thus further documenting immutable evidence of the management or execution of any digital contract <b>20</b>. Any party, participant, or vendor/subcontractor may then pay or reward the data layer server <b>74</b> (such as granting its crytpocoinage <b>60</b> and <b>120</b>, as explained with reference to <figref idref="DRAWINGS">FIG. 19</figref>).

0232The data layer server <b>74</b> may thus provide contractual services. The financial institution <b>34</b>, for example, may send or forward its input <b>330</b> and/or its decisional output <b>332</b> to the data layer server <b>74</b> for contractual documentation. Similarly, the retailer <b>122</b>, the online website <b>124</b>, and the manufacturer <b>128</b> may also send its input <b>330</b> and/or its decisional output <b>332</b> to the data layer server <b>74</b> for contractual documentation. The data layer server <b>74</b> may generate the data records <b>70</b> of the blockchain data layer <b>72</b> that document the management and/or execution of any decision table <b>326</b> representing any portion of the digital contract <b>20</b>. The data layer server <b>74</b> may also publicly publish each cryptographic proof <b>80</b> within the public blockchain <b>76</b>, thus further documenting immutable evidence of the management and/or execution of any digital contract <b>20</b>. The data layer server <b>74</b> may be paid or rewarded via their respective crytpocoinage <b>60</b> and <b>120</b>.

0233Exemplary embodiments may thus create factored decision tables driven by a table engine. Smart, digital contracts are notoriously dangerous. Decision tables are significantly easier to verify and validate. However, decision tables may be large and perhaps cannot be placed on a blockchain. Exemplary embodiments may thus put smaller contractual components of the digital contract <b>20</b> on any blockchain (such as the private blockchain <b>24</b> or the public blockchain <b>76</b>), validate the contractual components (perhaps via the cryptographic proof <b>80</b>), incorporate the cryptographic proof <b>80</b> into a larger component of the digital contract <b>20</b>, and then validate the larger component.

0234Exemplary embodiments thus may separate the blockchain data layer data <b>72</b> from contractual execution. The data layer server <b>74</b> (generating the blockchain data layer data <b>72</b>) may thus accept inputs from the servers (such as the remote server <b>262</b>) executing any component of the digital contract <b>20</b>. The servers (such as the remote server <b>262</b>) executing any component of the digital contract <b>20</b> may also send data to the data layer server <b>74</b>. The data layer server <b>74</b> may thus execute the decision table. The remote server <b>262</b> may additionally or alternatively execute the decision table when processing the digital contract <b>20</b>. The decision table may thus be sent and/or received as an input/output. Even a virtual machine may access and use the decision table.

0235Exemplary embodiments thus establish the digital contract <b>20</b> as an identity. Because only the contract identifier <b>28</b> is needed, the digital contract <b>20</b> may be separated into various smaller components (such as the software modules <b>310</b> and/or layers <b>312</b>, as above explained). Each software module <b>310</b> and/or layer <b>312</b> may have its own contract identifier <b>28</b>. The digital contract <b>20</b> is thus transformed to an identity, which may be easily updated after software bugs are found and consensus is documented by stake holders. Exemplary embodiments thus provide an ability to repair bugs and to claw back or backup spurious results. The separation of the blockchain data layer data <b>72</b> thus isolates and protects the data records <b>70</b>.

0236Exemplary embodiments thus describe a novel smart contract architecture to be run on blockchains. The digital contract <b>20</b>, and/or its contractual components, may each have its own digital identity defined within the blockchain data layer data <b>72</b>. The contract identifier <b>28</b>, in other words, may uniquely identity a version, thus allowing stakeholders (using their digital identities) to approve updates to respond to changes in business, to approve bug resolution, and to accommodate new participants in the digital contract <b>20</b>, without having to dissolve the original version and without redeploying or requiring the blockchain to be reversed and modified to avoid an incorrect, improper, or unacceptable result by perhaps a majority of users. As the reader may understand, modifying a blockchain to resolve an issue involves many more stakeholders with an interest in the blockchain but having no interest in the smart contract. This has been a problem with conventional blockchain architectures.

0237Exemplary embodiments may separate the blockchain data layer data <b>72</b> from the rules engine architecture that executes the digital contract <b>20</b>. Exemplary embodiments allow for light weight, secure, and extendible digital identity. Digital identity can be applied to implementation of the virtual machine that runs the digital contract <b>20</b>. Digital identity can be applied to any smart contract and/or to any stakeholder(s). Stakeholders may thus be paid (perhaps via the cryptocurrencies as explained with reference to <figref idref="DRAWINGS">FIGS. 13 &amp; 15-21</figref>) for who they are, such as to a particular blockchain address, meaning if a stakeholder's address is compromised, then the stakeholder can update the address without having to modify the digital contract <b>20</b>. This virtual address modification is similar to the real world for when a business moves from one geographic location to another, the business does not invalidate all its contracts. In the real world, the business merely informs parties of its new physical address and contact information. Exemplary embodiments allow management of the digital contract <b>20</b> in a flexible fashion, similar to management of contracts in the real world, but with blockchain security and data integrity of the actual digital contract <b>20</b>, automation of provisions in the digital contract <b>20</b>, and cryptopayment support.

0238Exemplary embodiments are also scalable. Layers or modules <b>310</b> and <b>312</b> can be created in the digital contract <b>20</b> and/or in the private blockchain <b>24</b> or the public blockchain <b>76</b> for improved flexibility and management via hardware computers. The data records <b>70</b> in the blockchain data layer data <b>72</b> are safely separated from the servers that execute the digital contract <b>20</b>. Contract servers (e.g., the contractual application layer) may perform a decentralized evaluation of digital contract <b>20</b>, using the proper virtual machine and proper rules, and manage interests of majority or all stakeholders. Values of cryptotokens may be defined and/or distributed, but allowing greater scalability.

0239Exemplary embodiments provide numerous advantages. Because the contractual execution is separate from the blockchain data layer data <b>72</b>, the results of the digital contract <b>20</b> are securely documented and may be exported to other contractual components or to other digital contracts. Exemplary embodiments may thus implement and offer multiple modules <b>310</b>, layers <b>312</b>, or instances of different contractual components that can exchange inputs and outputs to build a networking effect between different layers, modules, and smart contracts. A first server running a first application layer (and perhaps executing a first smart contract) can be entirely separate a second server running a second smart contract and a third server running a third smart contract. The blockchain data layer <b>72</b>, though, exchanges and thus documents their respective inputs and outputs. The various servers may thus manage and/or share the same cryptotokens, or different entity tokens may be exchanged within each layer. Regardless, exemplary embodiments may coordinate exchanges of value for services performed. Great flexibility in defining the value of cryptotokens and the value into and out of smart contract.

0240Exemplary embodiments may also have jurisdictional advantages. Particular servers may be specific to particular jurisdictions and/or particular smart contracts. For example, some application layers may cross jurisdictional servers with different compliances. As another example, suppose that one application layer may require qualified investors with full know your client (or “KYC”) compliance. Another application layer may be anonymous and/or allow all comers. Even if the blockchain data layer <b>72</b> has a small set of users/clients, large smart contracts may be managed, implemented, and/or documented.

0241The digital contract <b>20</b> may utilize conventional programming languages and/or decision tables. In particular, some programming languages and decision tables, like purely functional languages, may mathematically prove contractual algorithms. These mathematical proofs may yield much more secure smart contracts than conventional languages that run on today's blockchains. Previously, smart contracts were often too big in size to execute on a blockchain. The separate blockchain data layer <b>72</b>, though, allows scaling and implementing smart contracts “off chain.” The proof <b>80</b> of the digital contract <b>20</b>, for example, is a hash value, perhaps in association with the contract identifier <b>28</b> and/or the chain identifier <b>174</b>, as documented by the data records <b>70</b> in the blockchain data layer <b>72</b>. The hash value of the proof <b>80</b>, in other words, is a very small value (in relation to the size of the smart contract). The digital contract <b>20</b> may thus be provided to any or all parties and/or any or all stakeholders for validation of its terms, obligations, and performance. The cryptographic proof <b>80</b> thus verifies execution without stuffing large amounts of data onto the private blockchain <b>24</b> or the public blockchain <b>76</b>.

0242Exemplary embodiments may use decision tables for smart contracts. Decision tables are well understood, perform well, and are verifiable relative to brute-force code writing. Simply put, custom programming code introduces many variables and software bugs are inevitable. Decision tables are also very amenable to domain-specific languages. As the reader may understand, domain-specific languages accept near-English statements as inputs and generate computer code as outputs. Subject matter experts may thus define the functionality of the digital contract <b>20</b>, perhaps without relying on the skills of computer programmers (who may not fully understand the subject matter). Decision tables are thus approachable to subject matter experts and easily implemented. Decision tables may also be combined with other decision tables, which allows performance proven and validated functions may be incorporated into smart contracts for many objectives and outcomes. Decision tables may thus be mixed and matched as components to a composite digital contract <b>20</b>, and a collection of decision tables representing the digital contract <b>20</b> may still be validated to ensure correct operation. Decision tables define much smaller numbers of programming paths through the software code representing the digital contract <b>20</b>, which ensures that all contractual combinations may be enumerated and proper results can be expected for a range of values. On blockchains, though, decision tables may be big in size, so some decision tables may not be feasible as a smart contract on a conventional blockchain. But, because the blockchain data layer <b>74</b> is separate from the remote servers <b>262</b> executing the digital contract <b>20</b>, the digital identity (e.g., the contract identifier <b>28</b>) for the digital contract <b>20</b> (that allows the smart contract to exist off chain) provides the servers (each perhaps having its own identity) to certify execution of the digital contract <b>20</b>. Exemplary embodiments may also define the mechanism for cryptotoken-based payments that incentivize the remote server <b>262</b> to perform the digital contract <b>20</b> and to verify and validate the digital contract <b>20</b>. Component and composite performance may be tracked, recorded, and proved. For example, if a virtual machine runs the digital contract <b>20</b> (as above explained), execution in the virtual environment can be tracked. Virtual machines may often have software bugs that affect an interpretation of the decision tables. The virtual machine may thus have its own digital identity, as defined by the database <b>44</b> of contracts (as above explained). Different versions of the virtual machine and/or the decision table may thus be mapped within the database <b>44</b> of contracts, thus allowing redirection after software bugs have been resolved. The database <b>44</b> of contracts, in other words, may be updated with entries that point to different versions for different parties and/or to corrected or improved versions.

0243Digital identities extend to engines and decision tables. The database <b>44</b> of contracts may map or point to servers, domains, decision tables, and their respective versions. The digital contract <b>20</b> (and/or its components, as represented by their respective contract identifiers <b>28</b>) ensures execution, regardless of the environment. Because the blockchain data layer <b>72</b> documents all this component processing, the data records <b>70</b> may prove (via the cryptographic proof <b>80</b>) that the correct contractual component was used, the correct decision table(s) was/were used, the correct virtual machine was used, and the correct input or output data was used. Verification may driven from the contractual components, the data components, and the hardware components at the correct time for the correct time period.

0244Another audit application example is provided. A software application may be a generic term for user-side software that reads from and/or writes to the Factom system. It could be software with a human interface, or could be completely automated. The Application is interested in the data organized by the Chains it needs.

0245Applications are possibly Distributed Applications (DApps) interacting with Factom to provide additional services. For example, one might imagine a trading engine that processes transactions very fast, with very accurate timestamping. Such an Application may nonetheless stream transactions out into Factom chains to document and secure the ledger for the engine. Such a mechanism could provide real-time cryptographic proof of process, of reserves, and of communications.

0246Let us explore two separate applications that could have immediate demand in the current Bitcoin ecosystem.

0247Let us see how to implement a secure and distributed log platform. Log analysis is a complex task. Additionally, logs tend to be easily forgeable and also heterogeneous as they are produced by each system independently and stored in a variety of media (files, databases, cloud services etc.). With Factom and a few uniquely designed crypto-audit tools an entities log analysis can become safer, simpler, and much more powerful. Let's see this with an example. Suppose a Bank (B), a Payment Provider (PP), and a Bitcoin company (BC) are interacting together as follows: <ul id="ul0021" list-style="none"><li id="ul0021-0001" num="0000"><ul id="ul0022" list-style="none"><li id="ul0022-0001" num="0248">1—The User goes to the BC website and wants to buy some bitcoins</li><li id="ul0022-0002" num="0249">2—He asks for a quote, which is valid for 5 minutes</li><li id="ul0022-0003" num="0250">3—Then he is redirected to the PP website</li><li id="ul0022-0004" num="0251">4—Then the PP connects with the B platform so that the money of the user account is debited</li><li id="ul0022-0005" num="0252">5—B notifies PP that the user account has been debited</li><li id="ul0022-0006" num="0253">6—PP notifies BC</li><li id="ul0022-0007" num="0254">7—BC sends the bitcoins to the user <br /> This is the normal scenario for many fixed-rate Bitcoin exchanges globally. But assume now that for some reason the BC receives the payment notification 4 hours after the user transfers via the PP. Who is faulty? The User? The Bank? The Payment Provider? What if a similar payment problem happened for hundreds or thousands of payments over a period of days or weeks before the issue was identified and resolved? Who is “provably” liable for those loses/damages? </li></ul></li></ul>

0255With current techniques a manual auditing of logs would be necessary and would probably require legal authorizations. With Factom and the right audit applications, it would be trivial to detect where the problem came from, and also make the changing of records impossible post-issue. Basically, every system (BB, PP, BC) will publish their relevant traces in the secure broadcast channel (Factom) in real time.

0256Here's another example of how Factom will be useful for Bitcoin exchanges audits. The so-called “Proof of Solvency” method for conducting Bitcoin exchange audits is a growing and important trend. However, there are significant weaknesses to this approach only solved by having the Factom secure broadcast channel functioning properly.

0257In the Merkle tree approach for Solvency Proofs suggested by the Maxwell-Todd proposal, users must manually report that their balances (user's leaf) have been correctly incorporated in the liability declaration of the Financial Institution (FI) (the Merkle hash of the FI's database of user balances). The proposed solution works if enough users verify that their account was included in the tree, and in a case where their account is not included, it's assumed that this instance would be reported. One potential risk with this process is that an exchange database owner could produce a hash that is not the true representation of the database at all; the exchange hashes an incomplete database which would reduce its apparent liabilities to customers, thereby making them appear solvent to a verifying party. Here are some scenarios where a fraudulent exchange could easily exclude accounts: <ul id="ul0023" list-style="none"><li id="ul0023-0001" num="0000"><ul id="ul0024" list-style="none"><li id="ul0024-0001" num="0258">“Colluding Whales” Attack: There is evidence that large Bitcoin traders are operating on various exchanges and moving markets significantly. Such traders need to have capital reserves at the largest exchanges to quickly execute orders. Often, traders choose exchanges that they “trust”. In this way they can be assured that should a hack or liquidity issue arise, they have priority to get their money out first. In this case, the exchange and trader could collude to remove the whales account balance from the database before it's hashed. An exchange's top 10 whales could easily represent 5 to 20% of an exchanges liabilities, so colluding with just a few of them could have a significant impact.</li><li id="ul0024-0002" num="0259">“Site Manipulation” Attack: To date, each Proof of Solvency audit has reported (the hash tree) on the institution's website. This gives no guarantee at all to users, since a malicious exchange could publish different states/balances to different groups of users, or retroactively change the state. Thus it is fundamental to publish this data through Factom's secure broadcast channel, and publish it frequently.</li></ul></li></ul>

0260The second attack is obviously solved by using Factom, while the first is not so obvious. As this paper doesn't focus on the mechanics of exchanges audits, we won't delve in the nitty-gritty details. However, the basic concept is that by having frequent time-stamped copies of the exchanges database Merkle hash, one could detect the inclusion or exclusive of large balances before or after audits. Then, the auditor could simply look into those large inclusions or exclusions, manually. Remember, the trader will ultimately need to get his money on or off the exchange at some point, and that'll show up in either the bank history or the Bitcoin transfer history.

0261There are established process for detecting such fraudulent tactics in the traditional audit industry; however, it all starts with having accurate, verifiable, immutable time-series of the information in question.

0262Other examples are provided of attacks on Factom. The reader, for example, may be familiar with a denial of service from spam. Since Factom is an open system, any user can put Entries into almost any Chain. Bitcoin has a similar phenomenon. In order for an Application to reject those transactions, the Application would first need to download and process them. A large number of bogus Entries could slow down the initial processing of the Application's transactions. This threat is mitigated by an attacker needing to spend money (resources) to carry it out. This is similar to Adam Back's Hashcash solution to email spam.

0263Audits are another useful tool against spam, if the application is willing to trade off security versus convenience. Auditors could post “ignore” lists on the same chain, or create their own audit chains with those lists. An auditor could use a profile chain to develop their reputation, which would also allow review by other auditors. If any auditor made a bad call, it would be easily verifiable and the record of it would be permanent. Some validity processing is gray, in the sense that opinions may vary. Solving that problem would be implementation specific.

0264Another example is a sybil attack of the DHT. Distributed Hash Tables in general are particularly susceptible to sybil attacks. An attacker could create many peers which make it difficult for honest nodes to communicate. In a simplistic DHT architecture, attackers can isolate a required piece of data from honest nodes. Sybil attacks have been observed on the BitTorrent network routing table. The paper “Real-World Sybil Attacks in BitTorrent Mainline DHT” detail these attacks. Fighting this type of attack is an active topic in academic research. One mitigation technique uses complex lookup techniques to find honest nodes among the sybils, studied in “Sybil-resistant DHT routing”. Some sybil mitigation techniques rely on a web-of-trust by adding a social network to the routing table, as explored in “A Sybil-proof one-hop DHT”. Factom will rely on the latest academic and open-source research in this topic to secure its DHT.

0265A dictionary attack is now discussed. In this case, the attacker runs through all the Chain Names deemed to be possible or desirable and creates their ChainIDs, and the hashes of those ChainIDs. Then they watch for someone trying to create those Chains. Now the attacker can front run on a match. Because on a match, they know the ChainID, so they can construct a proper, but malicious Entry of their own, create the proper Chain payment and submit it rather than the users payment. If the attacker gets ahead of the user, then they will win. The defense against a dictionary attack is to avoid common name spaces and to submit your payment to multiple, long standing nodes in the network. In Factom, the flexibility of defining the Chain namespace makes efforts to hog the namespace ineffective.

0266Fraudulent servers are now discussed. All Entries in Factom require signatures from the users, or must match a hash that has been signed by the users. This means that fraudulent Federated servers in the Federation pool have very limited attacks they can make on the protocol. Invalid Entries do not validate, and upon broadcasting an invalid Entry, the honest Federated Servers will immediately broadcast a Server Fault Message (SFM) on the fraudulent server. If a majority detect a fault, the faulty server is removed. As long as the majority do not collude, then the protocol will remain honest. Any Federated server that failed detect the fault likewise risks losing its support from Factom users, and dropping from the Federated server pool.

0267Federated servers can delay recording of Entry payments. But because Entry payments are submitted via a distributed set of Factom Nodes, delaying of Entry payments will be noted. Users may withdraw support from servers without reasonable performance compared to the rest of the network.

0268Federated servers can delay the recording of Entries. Here the payment is accepted (generally by another server) fairly quickly. But for one reason or another, a Federated server refuses to record the Entry. In the next minute, responsibility for that Chain will shift to another server. As long as most servers are honest, the Entry will be recorded. Then the data over time will show that a server is delaying Entries. This will cause them potentially to lose support.

0269Federated servers can at any point send false messages. The other Federated servers then would issue a SFR on the on the rogue server when those messages didn't make sense. A majority of the servers issuing an SFR would boot the rogue server, then the network would ignore their messages and not forward them on.

0270Federated servers can refuse to accept valid Entry payment messages based on the public address, under the assumption that the public address is associated with some party. Again, assuming a majority of servers are honest, the payment will be accepted when the control shifts to an honest server. Furthermore, nodes watching will see the delay, and perhaps a pattern of delays, and support will be lost for the misbehaving servers.

0271<figref idref="DRAWINGS">FIG. 60</figref> illustrates timestamping into Bitcoin, according to exemplary embodiments. The Factom timestamping mechanism secures transaction in the blockchain. Factom data is timestamped and made irreversible by the Bitcoin network. A user's data is as secure as any other Bitcoin transaction, once published to the Bitcoin blockchain. A compact proof of publication is possible for any data entered into the Factom system.

0272As this disclosure above explained, data is organized into block structures, the highest level being Directory Blocks, which are created using Merkle trees. Every 10 minutes, the data set is frozen and submitted to the Bitcoin network. Since Bitcoin has an unpredictable block time, there may be more or fewer than one Factom timestamp per Bitcoin block. Bitcoin internal header block times themselves have a fluid idea of time. They have a 2 hour possible drift from reality. Factom will provide its own internal timestamps, adhering with standard time systems.

0273The user data ordering will be assigned when received at the Federated servers. Factom organizes the submitted Entry references into sets of blocks. The block time for Factom is ten minutes. On closing, the Federated Server network generates consensus and the Entries that are part of that block structure are timestamped to a minute within the block. As a general note, the data could have existed long before it was timestamped. An Application running on top of Factom could provide finer and more accurate timestamping services prior to Entries being recorded in Factom. The Factom timestamp only proves the data did not originate after the Factom timestamp.

0274The Merkle root of the Directory Block is entered into the Bitcoin blockchain with a spending transaction. The spend includes an output with an OP_RETURN. We refer to this as “anchoring” the Directory Block to the Bitcoin blockchain. This method is the least damaging to the Bitcoin network of the various ways to timestamp data.

0275Two possible alternatives to the OP_RETURN data in the blockchain is anchored to the P2Pool headers (as in chronobit) or in the Bitcoin block header coinbase. The P2Pool headers would require several hours of mining to find a block which satisfies the P2Pool rules, and the added complexity to the Factom protocol would not be worth the benefits. Including the Merkle root into the coinbase of a block would require cooperation with miners, above and beyond the transaction processing they are already doing. The coinbase entry would still need to have a crypto signature from the Factom system, so would not save on much space relative to a signed transaction.

0276The first two bytes of the available 40 in the anchor will be a designator tag (2 bytes with the value “Fa”). The Factom anchor (32 bytes) is concatenated onto the tag, then the block height is added (up to 6 bytes, allowing for >500,000 years). The designator tag indicates the transaction could be a Factom anchor. Other qualifiers are required, but the tag and Factom block height eliminates most of the OP_RETURN transactions that would otherwise need to be inspected. The block height in the OP_RETURN helps to fix the order in those cases where the Bitcoin blockchain records the anchors out of order.

0277The anchored data is the Merkle root of list containing the Directory Block's Merkle root. Querying a database or DHT for the anchored data will return the Directory Block which can be used to find the rest of the data in the block. The Merkle root timestamp will be entered into the Bitcoin blockchain by one of the Federated servers. The server delegated to timestamp the federation's collected data creates a Bitcoin transaction. The transaction will be broadcast to the Bitcoin network, and be included in a Bitcoin block. Bitcoin transactions that look like a Factom anchor, but are not spent from an address known as a Factom server would either be junk, or an attempt to fork Factom. Most users/applications would ignore such anchors.

0278Bitcoin blocks are generated with a statistical process, and as such their timing cannot be predicted. This means that the anchors are only roughly time-bound by the OP_RETURNs inserted into the Bitcoin blockchain, and its timestamping mechanism. The real value of anchoring Factom to Bitcoin is to prevent anyone from generating false Factom histories. Due to bad luck of Bitcoin miners, or delayed inclusion of Factom transactions, the time between when the Factom state is frozen for a particular 10 minute period and when the anchor appears in Bitcoin can vary, perhaps significantly.

0279Now the ramifications of federated servers and anchoring verses proof of work is discussed. Proof of Work (PoW) is optimized for permissionless participation and validation of the historical record of a blockchain. The typical implementation of Proof of Work is to repeatedly hash blocks until one of the parties mining finds a hash with the difficulty required by the current requirements of a blockchain. This allows anyone to serve as a miner, to collect and validate transactions, pack them into blocks, and repeatedly hash that block looking for a solution that meets the difficulty requirement.

0280The shortcomings of PoW have been widely discussed in the media as requiring unnecessary amounts of power, when other sorts of problem solving and work could result in benefits to blockchain users, the ecosystem, and society. Such is the goal of various Proof of Stake (PoS) systems used by various blockchains. But Proof of Stake alone makes the historical record hard to validate, and does not work well for a data recording system like Factom. This is because validating the historical Stake of parties involved the entire blockchain, and an understanding of the Stake that existed at each point in time historically. Factom needs small cryptographic proofs that validate sets of data, which PoW provides. Because PoW is validated solely by evaluating the difficulty of a hash.

0281Anchoring is the solution Factom uses to secure the historical record, and at the same time avoid duplicating the massive expenditure of resources required of mining. A system like PoS can be used in the present, while anchoring secures the historical record. The idea of supporting parties allows permissionless participation in the Factom protocol beyond that of the Authority Set.

0282The Authority Set and Anchoring means that running the Authority Servers is less expensive in resources by orders of magnitude compared to mining. Greater efficiency means that the rewards paid out by the Factom protocol can do more for the ecosystem than pay very large utility bills. Factom may use various voluntary but auditable methods to incentivize using the efficiency of the authority set to set aside resources within the protocol for productive real world work. A sort of Proof of Development could be used to receive these rewards using distributed support to identify work to be done, and evaluate the quality of the work that results. Such a system could provide rewards for development alongside the rewards generated for the authority set.

0283A “Proof of Development” comes with its own issues. The main issue is the “Oracle Problem,” where it is very hard to know from within the programming of a blockchain protocol what might be useful development in the real-world and evaluate the quality of such development once it is done. Factom may develop mechanisms to incentivize supporting parties in the protocol to create evaluation processes, audit trails, and certifications at every stage of development to address the Oracle Problem, and allow a self-correcting process to manage a viable “Proof of Development” that is more productive and ecologically friendly than simply rewarding the burning of energy resources for security.

0284The Factom protocol and system are now compared with other blockchain technologies. For example, Factom differs from Bitcoin and Sidechains. Factom is very different from Bitcoin, and in fact very different from any current cryptocurrency project. Cryptocurrencies like Bitcoin implement a strict, distributed method for the validation of transactions, where anyone can validate each transaction, and the validity of every input into a transaction can be verified. Because each transaction is authorized via cryptographic proof, no transaction can be forged. Each transaction can be checked for validity by verifying signatures of each transaction, and the miners hold each other accountable for only including valid transactions.

0285The Bitcoin protocol is transactionally complete. In other words, the creation and distribution of Bitcoins through transactions is completely defined within the Bitcoin protocol. Transactions (which specify movement of bitcoin) and block discovery (which move bitcoin via mining fees and provide block rewards) are the only inputs into the Bitcoin Protocol, and nothing leaves the Bitcoin Protocol. In other words, the 21 million bitcoins that will ultimately exist will always and forever exist within the protocol. Pegged sidechains, when implemented, will provide additional movement of bitcoin value outside the blockchain, while the pegged value is in stasis in the blockchain.

0286The sidechains proposal describes a solution to increase the scalability of Bitcoin by allowing value control to move off the blockchain and onto a sidechain. In the sidechain, many trades can occur. Later, a cryptographic proof (not all the transactions in between) can be recorded in the blockchain which moves the BTC out of stasis in Bitcoin. This proof would have to be available to the Bitcoin miners, but the bulk of the transaction data would be left behind in the sidechain.

0287Factom is in some sense attempting to increase scalability, but not by enabling more value transactions, but by moving non-BTC transactions off blockchain. This would be transactions that are not primarily intended to transfer Bitcoin value. For example transactions could manage domain name registrations, log security camera footage, track the provenance for art work, and even establish the value of show horses by documenting their history. Some of these do not move a value at all, like transactions establishing a proof of publication.

0288Sidechains and Factom are both trying to move transactions off the blockchain, but to achieve similar ends via completely different mechanisms. At some point, Factom may integrate with a Bitcoin sidechain in order to take advantage of the atomic swaps from BTC to Factoids.

0289Factom is also different from other blockchain technologies. Many different groups are looking to find ways to leverage the Bitcoin approach for managing other sorts of transactions besides tracking bitcoin balances. For example, the trading of assets such as houses or cars can be done digitally using Bitcoin extensions. Even the trading of commodities such as precious metals, futures, or securities might be done via clever encoding and inserting of information into the Bitcoin blockchain. Efforts to expand Bitcoin to cover these kinds of trades include Colored Coins, Mastercoin, and Counterparty. Some developers choose to build their own cryptocurrency with a more flexible protocol that can handle trades beyond currency. These include Namecoin, Ripple, Ethereum, BitShares, NXT, and others. Open Transactions (OT) uses Cryptographic signatures, signed receipts and proof of balance for users (i.e., a user does not need the transaction history to prove their balance, just the last receipt). In this way, OT can provide the spend of centralized servers without the risk of a centralized server that can alter client balances. Factom is decentralized, and only records Entries. So Factom can record data that would not meet OT's rules. But Factom will not execute at the rate OT can initially. Factom is distributed, and we expect that some, but not all users will employ cryptographic techniques similar to OT with their records.

0290The great advantage to an independent platform over trying to build upon Bitcoin is found in flexibility. The Bitcoin protocol isn't optimized to allow for recording of arbitrary pieces of data, so the “bookkeeping” necessary for non-Bitcoin type transactions isn't necessarily supported by Bitcoin. Furthermore, Bitcoin's Proof of Work (PoW) based consensus method is not a “one size fits all” solution, given that some transactions must resolve much faster than 10 minutes. Ripple and Open Transactions vastly speed up confirmation times by changing the consensus method.

0291An Application built upon Factom seeks to gain the ability to track assets and implement contracts, by leveraging the blockchain directly. Instead of inserting transactions into the blockchain (viewed as “blockchain bloat” by many), Factom records its Entries within its own structures. At the base level, Factom records what Chains have had Entries added to Factom within the Directory Block time. Scanning these records, Applications can pick out the Chains in which they are interested. Factom records each Chain independently, so Applications can then pull the Chain data they need.

0292Factom is organized in a way that minimizes connections between user Chains. A Chain in Factom can be validated without any of the information held in other, unrelated Chains. This minimizes the information a Factom user has to maintain to validate the Chains they are interested in.

0293Now Factom Consensus Similarities and Differences from Proof of Stake are discussed. The policy and reward mechanism in Factom is similar to Proof of Stake (PoS). Factom differs from most PoS systems in that many subsets of user stake and/or contribution may be recognized. Individual categories of stake can be weighted against each other to further decentralized Factom. This is an attempt to make the servers answerable to the users actively using and contributing to the protocol. The individual users would delegate their support to a server. The Federated servers with the top numbers of support would be responsible for coming to consensus.

0294Some with a deep understand of Bitcoin have recognized that pure PoS consensus mechanisms are fundamentally flawed. There are two attacks that make pure PoS unworkable. The problems are referred to as “Stake Grinding” and “Nothing at Stake”. Although Factom has PoS elements, it does not suffer from these problems.

0295Stake grinding is a problem where an attacker with a sizable (say 10%), but not majority share can formulate false histories. From some point in history, they can costlessly fork the blockchain, choosing to reorder past transactions such that their stake is always selected to create the subsequent blocks. They would be able to present this alternate version of history as part of an attack to steal value by double spending. Bitcoin solves this problem by strongly linking the information domain, where computers make decisions, with the thermodynamic domain, where humans burn energy. Considerable resources are expended in the thermodynamic domain, and is provable in the information domain. Bitcoin makes forming false histories hugely expensive.

0296Factom is unable to create alternate histories after the fact, since it is unable to insert transactions into historical Bitcoin blocks. It is also unable to create parallel histories without being detected, since Factom is linked to Bitcoin with known Bitcoin private keys.

0297The Nothing at Stake problem is more subtle. With a policy disagreement in Bitcoin, miners must choose either one policy or the other. If they choose against the majority, they will be burning lots of electricity without a chance of recouping costs. PoS miners do not face this dilemma. They can hedge their bets and costlessly create forks complying with each side of the policy. They would simultaneously agree with both sides of the disagreement. This would open up the economy to double spend attacks. One of two merchants following different forks will ultimately have that money becomes worthless.

0298Bitcoin solves this problem by having unintelligent unambiguous automatable rules for selecting the correct fork. In Bitcoin, the correct fork is the one with the most Proof of Work (PoW). Factom will also have unintelligent unambiguous automatable rules to select a correct fork, should one arise.

0299<figref idref="DRAWINGS">FIG. 61</figref> is a flowchart illustrating a method or algorithm for processing of the digital contract <b>20</b>, according to exemplary embodiments. The contract identifier <b>28</b>, the contractual parameter <b>30</b>, and/or the table identifier <b>334</b> is/are received (Block <b>340</b>). The network resource <b>50</b> is identified (Block <b>342</b>), and the contract processor may be an IP address, URL, virtual machine, or other network destination representing a vendor, contractor, server, or service that executes the decision table <b>326</b> and/or the digital contract <b>20</b>. The service request <b>266</b> is sent (Block <b>344</b>), the service update <b>270</b> is received (Block <b>346</b>), and the service response <b>268</b> is received (Block <b>348</b>). The data records <b>70</b> in the blockchain data layer <b>72</b> are generated (Block <b>350</b>), and the data records <b>70</b> describe the execution of the digital contract <b>20</b>. The data records <b>70</b> may be hashed (Block <b>352</b>) and incorporated into the public blockchain <b>24</b> (Block <b>354</b>).

0300<figref idref="DRAWINGS">FIG. 62</figref> is a schematic illustrating still more exemplary embodiments. <figref idref="DRAWINGS">FIG. 62</figref> is a more detailed diagram illustrating a processor-controlled device <b>360</b>. As earlier paragraphs explained, the entity's private software application <b>40</b>, the data layer application <b>154</b>, and/or the contract application <b>302</b> may partially or entirely operate in any mobile or stationary processor-controlled device. <figref idref="DRAWINGS">FIG. 62</figref>, then, illustrates the entity's private software application <b>40</b>, the data layer application <b>154</b>, and/or the contract application <b>302</b> stored in a memory subsystem of the processor-controlled device <b>360</b>. One or more processors communicate with the memory subsystem and execute either, some, or all applications. Because the processor-controlled device <b>360</b> is well known to those of ordinary skill in the art, no further explanation is needed.

0301<figref idref="DRAWINGS">FIG. 63</figref> depicts other possible operating environments for additional aspects of the exemplary embodiments. <figref idref="DRAWINGS">FIG. 63</figref> illustrates the entity's private software application <b>40</b>, the data layer application <b>154</b>, and/or the contract application <b>302</b> operating within various other processor-controlled devices <b>360</b>. <figref idref="DRAWINGS">FIG. 63</figref>, for example, illustrates that the entity's private software application <b>40</b>, the data layer application <b>154</b>, and/or the contract application <b>302</b> may entirely or partially operate within a smartphone <b>362</b>, a personal/digital video recorder (PVR/DVR) <b>364</b>, a Global Positioning System (GPS) device <b>366</b>, an interactive television <b>368</b>, a tablet computer <b>370</b>, or any computer system, communications device, or processor-controlled device utilizing any of the processors above described and/or a digital signal processor (DP/DSP) <b>372</b>. Moreover, the processor-controlled device <b>360</b> may also include wearable devices (such as watches), radios, vehicle electronics, clocks, printers, gateways, mobile/implantable medical devices, and other apparatuses and systems. Because the architecture and operating principles of the various devices <b>360</b> are well known, the hardware and software componentry of the various devices <b>360</b> are not further shown and described.

0302Exemplary embodiments may be applied to any signaling standard. Most readers are thought familiar with the Global System for Mobile (GSM) communications signaling standard. Those of ordinary skill in the art, however, also recognize that exemplary embodiments are equally applicable to any communications device utilizing the Time Division Multiple Access signaling standard, the Code Division Multiple Access signaling standard, the “dual-mode” GSM-ANSI Interoperability Team (GAIT) signaling standard, or any variant of the GSM/CDMA/TDMA signaling standard. Exemplary embodiments may also be applied to other standards, such as the I.E.E.E. 802 family of standards, the Industrial, Scientific, and Medical band of the electromagnetic spectrum, BLUETOOTH and any other.

0303Exemplary embodiments may be physically embodied on or in a computer-readable storage medium. This computer-readable medium, for example, may include CD-ROM, DVD, tape, cassette, floppy disk, optical disk, memory card, memory drive, and large-capacity disks. This computer-readable medium, or media, could be distributed to end-subscribers, licensees, and assignees. A computer program product comprises processor-executable instructions for execution of digital contracts, as the above paragraphs explain.

0304While the exemplary embodiments have been described with respect to various features, aspects, and embodiments, those skilled and unskilled in the art will recognize the exemplary embodiments are not so limited. Other variations, modifications, and alternative embodiments may be made without departing from the spirit and scope of the exemplary embodiments.