Introduction

Layer 1 blockchains such as Ethereum and Bitcoin, on their own, cannot support the latency and throughput needs for modern web applications [1]. Attempting to support higher throughput or lower latency with naive solutions (e.g. larger blocks, lower security consensus algorithms, etc.) sacrifices the core benefits of layer 1 blockchains [2]. It is unnecessary to make these sacrifices in the name of scalability for blockchains: when one blockchain is capable of storing and retrieving state, then another blockchain's summary state variables may be stored there. This can be done in layers, where Layer i+1 blockchain's state is stored in Layer i blockchains and each blockchain uses a well-motivated consensus engine to achieve Byzantine fault tolerance [3]. Using this layered approach, the key elements of a deep blockchain architecture can be specified. The blockchain paradigm [4] that forms the backbone of all decentralized consensusbased transaction systems to date is as follows. A valid state transition for a blockchain of Layer 𝑖 is one which comes about through a transaction 𝑇 𝑖 𝑗 :

𝜎 𝑖 𝑡+1 = Υ 𝑖 (𝜎 𝑖 𝑡 , 𝑇 𝑖 𝑗 )(1)

where Υ 𝑖 is the Layer 𝑖 blockchain state transition function, while 𝜎 𝑖 𝑡 enables components to retain arbitrary state between transactions. Transactions are organized into blocks, which are interlinked through a parent hash within each block to reference the preceding block. Together, these blocks serve as a ledger, with block hashes employed to spot the ultimate state:

𝜎 𝑖 𝑡+1 ≡ Π 𝑖 (𝜎 𝑖 𝑡 , 𝐵 𝑖 𝑗 )(2)

𝐵 𝑖 𝑗 ≡ (. . . , (𝑇 𝑖 𝑗 0 , 𝑇 𝑖 𝑗 1 , . . .))

Π 𝑖 (𝜎 𝑖 𝑡 , 𝐵 𝑖 𝑗 ) ≡ Ω 𝑖 (𝐵 𝑖 𝑗 , Υ 𝑖 (Υ 𝑖 (𝜎 𝑖 𝑡 , 𝑇 𝑖 𝑗 0 ), 𝑇 𝑖 𝑗 1 , . . .)) (4) where Ω 𝑖 is the block finalization state transition function for layer 𝑖, 𝐵 𝑖 𝑗 is the 𝑗th block of layer 𝑖 (which collates transactions and other components), and Π 𝑖 is the block-level state transition function for layer 𝑖.

In a deep blockchain system, a blockchain layer 𝑖 is said to be connected to layer 𝑖 + 1 if:

1. there exists a transaction mapping function Λ 𝑖+1 mapping blocks at layer 𝑖 + 1 into transactions 𝑇 𝑖 𝑘 at layer 𝑖 for all layer 𝑖 + 1 blocks 𝐵 𝑖+1 𝑗

𝑇 𝑖 𝑘 ≡ Λ 𝑖+1 (𝐵 𝑖+1 𝑗 )(5)

2. there exists a mapping function Ξ 𝑖 (𝑘) retrieving from blockchain layer 𝑖 a mapping 𝑓 (𝐵 𝑖+1 𝑘 ) of the blocks state of layer 𝑖 + 1 for all blocks 𝐵 𝑖+1 𝑘 Ξ 𝑖 (𝑘) ≡ 𝑓 (𝐵 𝑖+1 𝑘 )

A natural choice for transaction mapping Λ 𝑖+1 (𝐵 𝑖+1 as a transaction 𝑇 𝑖 𝑘 [5], and for the lower layer to provide the block hash back (see Figure 1 (left)). This paper, demonstrates a deep blockchain system for provable storage, situating a "Plasma Cash" design [6] in a Layer 2 Blockchain and NoSQL/SQL/File Storage for any number of Layer 3 Blockchains (see Figure 2).

Historically, the low-throughput high-latency of Layer 1 blockchains resulted in immediate pressure to drive activities off-chain [7], but only a few "off-chain" attempts can be considered deep blockchains because they lack the connected blockchains. Layer 𝑖 + 1 and layer 𝑖 may be explicitly connected in a deep blockchain system for many different reasons:

1. Higher throughput services at layer 𝑖 + 1 may be paid for using the value held in layer 𝑖 currency 2. Storing a limited set of information in layer 𝑖 + 1 in layer 𝑖 may support the security and provenance of layer 𝑖 3. Proof of fraud at layer 𝑖 + 1 can be used for economic consequences at layer 𝑖 The nascent label "Layer 2" encompasses many newly developing notions ranging from state channels to almost any approach that may help Layer 1 scale (e.g. bigger blocks), but the term "deep blockchain" is not used for all Layer 2 notions but specifically for any situation where one or more blockchains are connected in the above way.

Layer 2: Plasma Cash Blockchain

Seminal insights on multi-layer blockchains were put forth by [8], which have inspired many "Plasma" designs, and specifically motivated our implementation of what has been termed "Plasma Cash" for tracking storage and bandwidth balances. The Layer 2 Plasma Cash blockchain is connected to Layer 1 using the following trust primitives:

• User Deposit: When Alice wishes to use the services enabled by the Layer 2 blockchain, Alice deposits some Layer With the Plasma Cash construct, the Blockchain 2.0 Objective is achieved with:

1. Layer 1 Smart Contracts supporting a Layer 2

Connection to Layer 1 storage that collectively make the cost of attacking the Layer 2 blockchain the same as the cost of attacking the Layer 1 blockchain -for Ethereum and Bitcoin Layer 1 blockchains, this is the famous "51% attack", for others it might be whatever is required to control the state of that Layer 1 Blockchain. 2. Layer 1 Cryptocurrency being used for value transfer of services between users of the Layer 2 Blockchain and the Layer 2 operator mediated through deposits, token transfers and exits mediated by Layer 1 constructs

With the Layer 2 Block Connection and trust primitives in place, Layer 2 can operate at much higher throughput than Layer 1 because of its reduced consensus, but continuing to inherit Layer 1's cost of attack and achieving the more fundamental objective. Therefore practitioners of deep blockchain engineering must develop different instincts, incorporating different software trust primitives between different constructed layers to achieve the same objective depending on the structure of between layers and the value unlocked in each.

Deep Blockchains for Provable Data Storage

The specific deep blockchain system that has developed extends the Blockchain Both NoSQL and SQL Blockchains is described in Section 5.

Just as with Layer 1 blockchain nodes, running Layer 2 and Layer 3 blockchains consists of running a node within the framework of a decentralized system, retrieving and relaying messages about new transactions and new blocks. Wolk's blockchain implementations of the Layer 2 and Layer 3 originated from Ethereum's goethereum and JPMorgan's Quorum RAFT code bases, written in Golang. RAFT is used for both Layer 2 and Layer 3 implementations due to its simple model of finality. For each blockchain, Golang package is created containing each of the interfaces specified in Appendix A, and adapted Quorum RAFT code to conform to these interfaces. There is no explicit assumption that permissioned consensus algorithms be used, however. The choice of RAFT was made purely out of simplicity, its maturity as a code base, and its capacity for high throughput -any consensus protocol that achieves finality can fit within this deep blockchain architecture. For both the Layer 2 and Layer 3 blockchains, Sparse Merkle Tree is used to support provable data storage.

Sparse Merkle Trees and Provenance

The Sparse Merkle Tree (SMT) is a persistent data structure that map fixed 𝑞-bit keys to 256-bit values in an abstract tree of height 𝑞 with 2 𝑞 leaves for any set I:

I = {(k0 ∈ B𝑞, v0 ∈ B256), (k1 ∈ B𝑞, v1 ∈ B256), . . .}(10)

The function of the SMT is to provide a unique Merkle root hash that uniquely identifies a given set of key-value pairs I, a set containing pairs of byte sequences. Each key stored in the SMT defines a Merkle branch down to one of 2 𝑞 leaves, and the leaf holds only one possible value for that key in I. The bits of the 𝑞-bit key define the path to be traversed, with the most significant bit at height 𝑞 − 1 and least significant bit at height 0. Following [11] and [12], to compute the Merkle root of any SMT in practice and allow for the ideal computation of Merkle branches for the 𝑛 Merkle branches, it is useful pre-compute a set of default hashes 𝑑(ℎ) for all heights h from 0 . . . 𝑞 − 1 levels: (shown in Figure 3)

• At level 0, 𝑑(0) ≡ 𝐻(0) • At level ℎ, 𝑑(ℎ) ≡ 𝐻(𝑑(ℎ − 1), 𝑑(ℎ − 1))

Logarithmic insertion, deletion and retrieval operations on the SMT are defined with elemental operations:

• insert(𝑘, 𝑣) -inserts the key by traversing chunks using the bytes of 𝑘

• delete(𝑘) -deletes the key by inserting the null value for 𝑘 into the SMT • get(𝑘) -gets the value from the SMT through node / chunk traversal Typically, block proposals with SMTs as a core data structure involve bulk combinations of the above, with many inserts and deletes mutating the content of many chunks, and the Merkle root only being computed as a final step. Sparse Merkle Trees are best suited for a core primitive over more familiar Binary Merkle Trees (BMTs) because:

• when an id (a tokenID, a document key in NoSQL, a URL in File storage, a table root in SQL) is mapped to a value, you can guarantee that the id has exactly one position in the tree, which you don't get with BMTs. • when an id is NOT present in the SMT, you can also prove it with the same mechanism. This approach proves beneficial in situations where Bloom filters produce erroneous matches. • A Merkle proof for the id mapped to a specific value is straightforward, and because of sparseness the number of bytes required is much less than the depth of the tree

The key concept behind SMTs is the efficient representation of included IDs using 𝑛 hashes at 𝑛 out of 2 𝑞 leaves. Each ID, represented as a 𝑞-bit number, is associated with either a null value or its corresponding hash at a leaf node. Instead of using a Merkle proof consisting of 64 32-byte hashes from the leaf to the root, a compact representation can be achieved using proofBits, a 𝑞-bit value (e.g., uint64). Each bit in proofBits indicates whether the sisters on the path to the root use default hashes (0) or non-default hashes stored in proofBytes. Similarly, when a user receives a token from another user, they must obtain the tokenID, along with 𝑡 raw transaction bytes and 𝑡 Merkle proofs. Each Merkle proof corresponds to a specific block and verifies the token spend. It's important to note that a non-spend can also be proven, where the leaf is represented by 𝐻(0). In the optimal scenario, an SMT representing a single key-value mapping (𝑛 = 1) reduces the proof size

I = {(𝐾 1 , 𝑉 1 ), (𝐾 2 , 𝑉 2 )}.

Since there are only keys in this tree, the default hashes 𝑑(ℎ) (outlined in red) appear starting at level 62, so the branches 𝐾 1 , 𝐾 2 (shown in blue circles) have Sparse Merkle proofs using default hashes from level 0 to level 62, which can be specified in a proofBits parameter. This makes for very tiny proofs and lower gas costs on Main-Net.

significantly. Instead of a 64 × 32 byte proof, the entire path from level 0 to level 63 consists of default hashes, and proofBits is a 64-bit value filled with zeros (0x0000000000000000). In this case, proofBytes is empty, and the uint64 value is 0, resulting in the most compact proof size possible: 8 bytes.

In the following favorable scenario, considering 2 ids (for example, 0x01234... and 0x89abc...), the proof of spend for each token would include a single non-default hash at the topmost level 63, and proofBits would consist of the value 1 followed by 63 zeros (0x8000000000000000). The resulting proof size would be 40 bytes.

In typical scenarios, SMTs exhibit high node density in the upper levels, ranging from level 𝑞 − 1 down to approximately level 𝑙𝑜𝑔2(𝑛). To illustrate this, consider a situation where you have 10MM Layer 2 tokens, and each token undergoes 500 transactions per token per year. This results in a total of 5B transactions for the 10MM tokens annually. Assuming a Layer 2 block frequency of 15s/block, these 5B transactions would be distributed across 2.1MM blocks per year, with an average of 2,378 transactions per Layer 2 block (500 × 10 × When incorporating these 2,378 transactions into an SMT, given that 𝑙𝑜𝑔2(2378) = 11.2, you will have a densely populated set of nodes, mostly consisting of non-default hashes, from levels 63 down to approximately level 53. Below that, you will have only one tokenID extending all the way to level 0. The proof size would amount to 32 bytes per level, resulting in a total of 320 bytes for 10 levels.

𝑞 = 64 is decided instead of 𝑞 = 256 because:

• collisions are still unlikely at q=64 ... until it is around 4B keys • the proofBits are 24 bytes smaller (uint64 instead of uint256) • less gas is spent in checkMembership on all 0 bits in proofBits • smaller 64-element array of default hashes computed instead of 256 hashes

Reducing the frequency of hashing leads to decreased gas consumption and increased user satisfaction, particularly in the Level 2 block connection. In this context, it ensures that collisions between circulating tokenIds can be definitively ruled out during deposit events. Moreover, you can combine the fixed length proofBits and variable length proofBytes into a single proof bytes input for exits, i.e.

startExit(uint64 tokenID, bytes txBytes1, bytes txBytes2, bytes proof1, bytes proof2, int blk1, int blk2) The analogous challenge interfaces will then have fewer argument inputs in the same way.

The sparseness of the SMT derives from the observation that keys will extremely rarely share paths at increasingly lower heights and naturally will share paths at increasingly higher paths. This lends itself to a representation where the SMT is chunked by byte k𝑖, where traversing the SMT from a root chunk (representing a range of keys from 0 to 2 64 -1) down to an intermediate chunk with just one leaf involves processing one additional byte, which each chunk of data storage having up to 256 child chunks specifying a range of keys each child posessing a range that is 1 256 smaller. Just as with a radix tree, the SMT is traversed from root to leaf, with an additional byte of the key causing a read of a chunk that represents up to 256 branches and the hashes of all the branches, utilizing default hashes. Golang "smt" package is implemented and a "cloud" package to map SMT operations into Cloudstore.

Layer 3 Blockchains

With the foundations of Layer 2 providing storage and bandwidth paid for with Layer 2 tokens, any number of Layer 3 blockchains may be constructed. The construction of a NoSQL and SQL blockchain is detailed here. At a high level, Layer 3 blockchains collate SQL and NoSQL transactions in Layer 3 blocks submit block transactions to Layer 2, and Layer 2 collate token and block transactions with Merkle Roots of token root and blocks submitted and included in transactions to Layer 1 blockchain. It then becomes possible to aggregate multiple proof of inclusions at the highest layers all the way to MainNet with Deep Merkle Proofs, which is illustrated here.

Layer 3 NoSQL Blockchain and Deep

Merkle Proofs • Finally, a Layer 1 Block (e.g. 10,000,002) will be proposed by some MainNet miner including the above Layer 2 submitBlock transaction and eventually be finalized by the Layer 1 consensus protocol.

A Deep Merkle Proof is formed through the aggregation of each proof of inclusion across each layer of blockchain connections in a deep blockchain down to Layer 1. In our 3 layer deep blockchain with the Layer 3 NoSQL blockchain layered on the Layer 2 Storage / Plasma Cash blockchain, there is a Layer 2-3 connection and a Layer 1-2 connection. So a full Deep Merkle Proof that a NoSQL document 𝐾1, 𝑉1 is included in the deep blockchain all the way up to MainNet consists of: in Layer 3 block Layer3KeyRoot -in our example, this would be that the Layer 3 block hash 0b101..11 hashes up to SMT root 𝑅2002 = 0x4d69..

Layer 1 proof of inclusion of the Layer 2 block

hash in the blockHash array of the Layer 1 Smart Contract -in our example, this is that blockHash(2002) = 0xe8db

In our implementation, deep Merkle proofs are provided in response to GetKey(𝐾, 𝑉 ) to the layer 3 blockchain users as an optional deep boolean parameter and when true, returns the full combination of:

• Layer 3 Block, which includes Layer3KeyRoot

• proofBits and proofBytes for the The concept of a deep Merkle Proof is not limited to 3 layer deep blockchains, nor is the concept only applicable to NoSQL blockchains -the concept applies to multiple layers of proof of inclusion enabled through the general layering processes of deep blockchain systems generally.

Layer 3 SQL Blockchain

To support Layer 3 SQL operations in a SQL blockchain, the Layer 3 block has a structure defined as having as packing a set of encrypted SQL transactions (insert/update/delete statements) along with a Layer3KeyRoot of a Sparse Merkle Tree representing a set of table root hashes.

In our implementation, Quorum RAFT is adopted as the consensus layer for our layer 3 SQL blockchain (again, following Appendix A), which collectively follow a consensus protocol where once a leader has been identified, the leader mints a new Layer 3 block based on:

• An array of SQL transactions that is mapped into newly created chunks (created via storeChunk for table root hashes) • An array of table root hashes, key-value pairs written to Layer3KeyRoot, based on the execution of the above SQL Transactions

The minting a layer 3 block consists of the leader compiling each SQL transaction into a set of instructions to executed by a "SQL Virtual Machine" (SVM) based off of the widely used SQLite's virtual machine. In this model, a virtual machine has a program counter that increments or jumps to another line after the execution of each opcode instruction. For example, a SQL statement of "Select * from person" received by a node is mapped into a interpretable set of opcodes like this:

{"n":0,"opcode":"Init","p2":8,"p4" ":"select * from person"} {"n":1,"opcode":"OpenRead","p2" :2,"p4":"2"} {"n":2,"opcode":"Rewind","p2":7}

{"n":3,"opcode":"Column","p3":1} {"n":4,"opcode":"Column","p2" :1,"p3":2}

{"n":5,"opcode":"ResultRow","p1" :1,"p2":2} {"n":6,"opcode":"Next","p2" :3,"p5":1} {"n":7,"opcode":"Halt"} {"n":8,"opcode":"Transaction","p3" :3,"p4":"0","p5":1}

{"n":9,"opcode":"Goto","p2":1}

In our SVM Golang implementation, all opcodes are mapped into Layer 2 storeChunk and receiveChunk calls, manipulating the following chunk types:

• Database Schema chunk: represents up to 32 tables belonging to the "blockchainName". Each

Paying for Storage and Bandwidth

The Layer 3 blockchain users who store NoSQL/SQL/File data with storeChunk operations give the Layer 2 operator permission to charge for bandwidth and storage in two different ways:

1. Bandwidth is paid for through (1) users signing retrieveChunk(𝑘, 𝜏, 𝜔) calls to retrieve data and obtaining recent balances, where each call uses up a tiny amount of bandwidth backed for with a token 𝜏 originated by the createBlockchain call; (2) users signing a new updateBalance(𝜏, , 𝜔) request originated by operator and agreeing to making a payment for incurred bandwidth usage and the latest token owner balance. An updateBalance response by users is mapped into layer2 transaction, where incurred bandwidth cost is deducted from token's owner balance (𝜏 ) and added to operator's allowance 𝛾(𝜏 ). 2. Storage is paid for through Block Transactions submitBlock(𝑏 3 𝑘 , 𝑘) signed by the Layer 3 blockchain operator -because chunks are identified directly inside Layer 3 blocks, a tally of the number of bytes used in each new layer 3 block is added to the SMT. The Layer 1 contract then exposes storageCharge interface to the Layer 2 operator where a recently signed Layer 2 block transaction (containing a tally of the number of bytes, signed by the Layer 3 blockchain operator) is used to deduct the layer 3 operator's balance since the last time it was called. This is detailed below.

In this way Layer 3 Blockchains pay for the services of the Layer 2 blockchain. The lifecycle of a short lived Layer 3 blockchain is shown in Figure 5, which is expounded in the next section.

Layer 2 Plasma Tokens for Bandwidth Payments

In this section it is explained how Layer 2 Tokens can form a unidirectional payment channel, where each signed Later, multiple (lots and lots) of signed GetKey calls are done by the Layer 3 User, each executed using retrieveChunk signed calls. At some point, the user hits Σ𝑚𝑎𝑥 = .02𝑝𝐸𝑇 𝐻 and uses updateBalance to agree that its balance is 0.98 pETH, which is included in Layer 2's token transaction block and submitted to Layer 1. Finally, the Layer 3 user can drop its blockchain, which will trigger deletion of chunks and initiate a finalizeExit process that returns the .98 ETH balance to the user.

retrieveChunk call is not a transaction to be included in a Layer 2 block (and has no nonce to increment) but simply indicative of "permission to return some data and decrement my token balance"; where the Layer 2 operator can check the signature against its record of the current owner as a condition of looking up the chunk. The Layer 2 operator must have tally aggregation capability that can aggregate numerous signed calls together and compute that token 𝜏 has some new balance (𝜏 ). In our implementation simple minute-wise Hadoop job is used to tally periodic flushes of retrieveChunk operations grouped by different 𝜏 , keeping as a short-term output (TTL=3600s) log that each minutewise change of 𝜏 was caused by specific signed operations; this balance update log is exposed to the user. When this internal tally reaches a critical threshold Σ𝑚𝑎𝑥, responses to retrieveChunk halts and can only resume with a Layer 2 updateBalance transaction submitted and included in the Layer 2 block directly in the SMT root Layer2TokenRoot. The threshold Σ𝑚𝑎𝑥 in the contract. To minimize disruptions from halting in this way, it is the responsiblity of the Layer 3 blockchain to periodically submit updateBalance, signing recent token balances provided in the retrieveChunk.

Moreover, as the token has considerable usage accumulated, and as users regularly submit sufficient updateBalance transactions to Layer 2, the value of the balance may accumulate to a great enough level that the Layer 2 operator may wish to withdraw the balance accumulated directly in the Layer 1 contract. To support this,the SMT state is expanded to include the token balance and the operator withdrawal amounts.

If users wish to transfer the token to another user of the layer 2 blockchain by submitting a token transfer operation, the updateBalance must be executed to "close" the token-based state channel.

Finally, users who wish to withdraw token 𝜏 for Layer 1 currency can do so by calling startExit with the last 2 transfers and this last updateBalance, which will redeem the denomination less the tally of what has been withdrawn by the operator. Others may challenge this exit, but only with a valid proof of user double spending 𝜏 .

Layer 1 Storage Insurance

Because every single write of a Layer 3 blockchain is included in sequentially ordered layer 3 blocks (each of which identify a set of Chunk IDs) the layer 3 blockchain forms an itemized list of signed insurance requests that form a Layer 1 unidirectional state channel initiated by the deposit into createBlockchain. Assuming no challenges exist, if the Layer 2 operator that receives a Layer 3 block identifying a set of chunks can provide a recent proof of storage then it may deduct from this deposit. On the other hand, if the layer 3 blockchain has reason to believe that some chunk is lost, it can submit its claim to Layer 1 smart contract and demand Merkle proofs in response. The CRASH patterns of [9] specify this challenge-response system in detail, which is extended to our deep blockchain in the following way:

• Insurance Request. Each Layer 3 block 𝐵 3 𝑗 ( submitted to the Layer 2 operator in the block transaction submitBlock(𝑏 3 𝑗 , 𝑗) calls ) includes (1) a seed hash 𝛾, where the seed 𝜈 (𝛾 = 𝐻(𝜈)) is held solely by the layer 3 operator and revealed when the layer 3 operator wishes to challenge the Layer 2 operator with storageChallenge (see below); (2) the hash of an SMT Merkle root 𝐻(Ξ) for all the chunks specified in the layer 3 block using 𝜈; (3) the total collection size in bytes 𝜎 𝑡𝑜𝑡𝑎𝑙 in all Layer 3 blocks; (4) a Ω parameter, the amount of layer 1 currency required to hold 1 GB per month (e.g. if market conditions for keeping data in 8 places in Cloudstore is $.25 GB/mo and Layer 1 currency is $500/𝐸𝑇 𝐻, then Ω would be 5 × 10 1 4 wei). The Layer 2 operator uses 𝜅 to fetch the list of chunks the Layer 3 operator wishes to insure, verifies that all chunks in the list are in fact available, and checks that 𝜎 𝑡𝑜𝑡𝑎𝑙 matches the Layer 2 operators own tally closely. If the chunks are missing, or the tally is not reasonable, the Layer 2 operator may reject the block. Otherwise, the Layer 2 blockchain will include the Layer 3 block hash in the BlockRoot of the next Layer 2 block. In this way, the block transaction is taken as a signed request to insure the entire Layer 3 blockchain's storage. This payout must come from a registered balance held in the Layer 1 Smart Contract. The response must be a valid proof whose root Ξ that matches 𝐻(Ξ) originally supplied for the block. Finally, to guard against the situation that some layer 3 operator supplies a bogus 𝐻(Ξ) in the block transaction to claim this payout, the layer 2 operator can supply a small number (e.g. 5) of Merkle branches resolving to 𝜅. The economic incentives of this challenge-response system is refined to balance the layer 2 and layer 3 operators in this challenge-response pattern to be reasonable relative to Layer 1 Ethereum gas costs.

With the above mechanism in place, the layer 2 operator can charge the layer 3 operator when transaction fees are negligible. In regular conditions, the Layer 3 blockchain can see its storage fees through storageCharge; when the balance approaches zero, the Layer 3 blockchain must deposit additional Layer 1 currency to its blockchain balance at Layer 1. Finally, a call to dropBlockchain must permit the layer 2 operator the opportunity to claim a final storageCharge and close out the bandwidth balance of 𝜏 before finalizing exits (see Figure 5). Since there are two sources of demand (storage charge and bandwidth charges), the layer 2 blockchain must check that the sum of both sources equal the available balance for the layer 3 blockchain.

Discussion

There have been many approaches scaling blockchain architecture to support higher throughput and lower latency:

• Changing the security model of Layer 1 blockchains (c.f. NEO, EOS's approach) • Incremental improvements to Layer 1 or Layer 0 that don't change security model (c.f. larger blocks) • Having many separate chains, using sharding • State Channels • Layer 2 Plasma solutions This paper focussed on the last approach, and described how using the core ideas behind Layer 2 Plasma Cash can be extended to a deep blockchain system, forming the basis for provable data storage for widely used NoSQL + SQL developer interfaces. The concept of Deep Merkle proof for a 3 layer deep blockchain system is illustrated here and shown its conceptual viability, borrowing state channel concepts for Layer 3 NoSQL and SQL blockchains to pay for storage and bandwidth.

Deep learning architectures have advanced numerous high-scale applications in every industry in a way that is not about one specific deep learning algorithm -and instead about an approach that could not be achieved through dogmatic faith in single-layer "neural" networks. In an analogous way, deep blockchain architectures could have the potential to enable a wide range of high-scale applications in a way that might not be achieved through dogmatic faith in Layer 1 scaling innovations alone.

Blockchain practitioner instincts are to be wary of centralized consensus protocols and centralized storage. However, our use of non-local storage can be rationalized, not by demanding that every component be dogmatically decentralized, but by considering how attack vectors are reduced through judicious use of some notso-decentralized components. The attacks on storage are limited in nature due to:

• verifiability of chunks, where all 𝑘, 𝑣 pairs retrieved from non-local storage are verifiable either due to (a) 𝑘 being verified to the hash of the value 𝑣 returned (b) 𝑘 being directly included and signed by a trusted party. In this sense the attack vector is limited to the private key • the use of Ethereum SWARM (currently in POC3) as a censorship-resistant cloud storage provider.

In the event that the Layer 2 blockchain provider loses access to its Cloud Storage backend, higher layer backends can simply request chunks using the Kademlia-based DHT of Ethereum SWARM. Generally this censorship-resistance comes at the cost of higher latency responses. • cryptoeconomic incentives, wherein if a data storer can prove (with a Merkle branch) that a piece of data can no longer be accessed but has been included on chain through a valid Merkle branch

It is believed the combination of decentralized storage and cloud computing storage increases the cost of attack and that the Blockchain 1.0 Objective of Maximize decentralization must be altered in favor of the more nuanced Blockchain 2.0 Objective Maximize cost of attack, which ultimately will lead to more secure and reliable blockchain systems. One gets the best of both worlds: from centralized storage one gets low-latency, high-throughput infrastructure, and from decentralized storage one gets resilience and censorship resistance.

Concerning the use of a single centralized Layer 2 operator, it is highlighted that in all cases where Layer 1 currency is deposited (in createBlockchain), because use of the "Plasma Cash" design pattern, the owner of the tokens may withdraw its balance on the Layer 1 blockchain. This is a surprising result: that checks and balances on token ownership are possible through the use of the Layer 1 blockchain despite the Plasma operator being in 100% control; if users discover that the Layer 2 blockchain operators are malicious, they can be certain they can get the value of their tokens back, and if the data is kept in resilient Ethereum SWARM (or if they have kept their data locally), they can move to another Layer 2 operator using the same protocol.

This shows a deep blockchain that has a higher cost of attack than the deep blockchain illustrated in Figure 2, utilizing 𝑁2 Layer 2 blockchains (each with their own Cloudstore) and 𝑁1 Layer 1 blockchains, each receiving the same Layer 3 submitBlock and Layer 2 submitBlock transactions respectively: Because the retrieval of layer 𝑖 + 1 data from layer 𝑖 can be verified by layer 𝑖 + 1 (checking block data: does the block hash match the block content? is it signed? does it have a parent hash? etc.; checking chunks: does the hash of the chunk data equal the chunk key), each lower layer node devolves into a dumb storage layer with some failure or attack probability (𝑝 2 1 ..𝑝 2 𝑁 2 for layer 2 blockchains, 𝑝 1 1 ..𝑝 1 𝑁 1 for layer 1 blockchains) -depending on this probabilistic model, the cost of attack may be divined. However, it seems most likely that motivated parties would attack the centralized control behind each layer (c.f. via EIP999, mining pools arewedecentralizedyet.com, governments asking the Cloudstore providers to block Layer 2 operator's accounts) -in this sense the probabilistic independence in concentrated efforts to attack layer 1 and 2 would be highly suspect. For this reason, our true faith relies in Ethereum SWARM's resource updates ([9]), where chunks may be keyed not by the hash of their content but with a resource key, which can be used for the block data without an index mechanism; all resource updates are signed so the reader can authenticate. Ethereum SWARM, because of its use of Kademlia-like protocol, is not naturally as fast as other components in Cloudstore, but kicks in when all Layer 2 blockchains Cloudstore fail or when Layer 1 itself is attacked (via 51% attacks, or unknown POS failures). If other decentralized storage services provided similar provable storage as Ethereum SWARM's resource update, so long as Layer 3 blockchain does not go Byzantine, only one answer can surface, making for unstoppable layer 3 blockchains.

The Layer 3 NoSQL and SQL blockchains developed in this paper operated under an assumption that the NoSQL + SQL transactions should be private data secured by an encryption key known only to the operators of the Layer 3 blockchain. This protects the Layer 3 blockchain from operators of Layer 2 blockchain and any Cloudstore. However, the same problem as with standard databases (MySQL, MongoDB, DynamoDB, etc.) exists with our current implementation of NoSQL/SQL Layer 3 blockchains: once someone gets access to a Layer 3 blockchain node holding the database encryption key or private key, the entire database is compromised. Therefore, provenance and immutability of the NoSQL/SQL database state changes, as manifested in Deep Merkle Proofs, differentiate a Layer 3 blockchain from standard databases. The small latency incurred with permissioned protocols (RAFT, POA) and negligible cost should be welcomed when provenance and immutability are of paramount concern.

Many other Layer 3 blockchains can be constructed using the Layer 2 storage and bandwidth infrastructure: a chain that represents the evolving state of ERC721 tokens, a chain that represents a cryptocurrency exchange where your money can never be stolen, and so forth. The state of the Layer 3 blockchain is not stored locally but instead kept in Cloudstore with storage and bandwidth costs properly accounted for using the Layer 2 tokens, themselves based on Layer 1. Layer 3 and Layer 2 nodes are therefore "light nodes" in that they can quickly catch up to the latest state by asking the layer 2 and layer 1 blockchains for the most recent finalized block. This is not possible to do for the Layer 1 blockchain, however. However, it is possible, and interesting to adapt a Layer 1 blockchain of Ethereum and make it a Layer 3 blockchain. Computation (Ethereum gas costs) can consume Layer 2 token balances in state channels along with bandwidth, contract storage can use SMTs mapped to Cloudstore (instead of Patricia Merkle Tries kept in local store) submitted in blocks to the Layer 2 blockchain, and the consensus machinery can be put in a modern sharded Proof-of-Stake framework to achieve high-throughput low-latency ambitions of Ethereum 2.0, with all layer 3 nodes. The expectation would be that a Layer 3 Ethereum blockchain would have massively lower costs due to rational models of storage and bandwidth. Other deep blockchain systems can be developed with different computational primitives than the EVM, such as Amazon's Lambda or Apache Hadoop.

It is believed that there can be many deep blockchain systems developed with higher layers resting on many Layer 1 blockchains, even to the point where multiple Layer 1 systems are dropped and many more added to provide more or less Layer 2 security. The same can be said for any layer to benefit higher layers. If the blockchain at layer 𝑖 changes its consensus algorithm from Quorum RAFT to pBFT or Casper Proof-of-Stake, the layer 𝑖 + 1 benefits; higher layer blockchains are supervenient on Layer 1, so innovations on Layer 1 are inherited by all deep blockchain systems. It is hoped that many deep blockchain systems can explore high throughput low latency scale through some of the design patterns explored here.