Deep Blockchain to Enable Scalable Web Applications Yajna Pandith1,* 1 Bengaluru, Karnataka, India Abstract The work delves into the exploration of deep blockchain architecture involving the introduction of higher-layer blockchains, which summarize their blocks through anchor transactions integrated into the blocks of lower-layer blockchains. The architecture is structured as follows: (I) Layer 1 - MainNet: This layer serves as the repository for registered Layer 3 blockchain roots and Layer 2 Block Merkle roots. (II) Layer 2 - Plasma Cash chain: This layer facilitates the storage of Plasma tokens, which can be redeemed for bandwidth, along with Layer 3 Block hashes. (III) Layer 3 - Multiple blockchains: These blockchains leverage the storage and bandwidth capabilities provided by Layer 2, enabling seamless packaging of NoSQL/SQL transactions and similar database operations. Sparse Merkle Trees is employed extensively, demonstrating their efficacy in delivering provable data storage through the use of Deep Merkle Proofs. Our objective is to present results highlighting re-markable throughput and low latency for Layer 3 blockchains built upon economically secure Layer 2 Plasma Cash blockchains. Collectively, these advancements lay a solid foundation for the development of scalable web applications. Our research paves the way for innovative solutions in various industries that can scale modern web applications successfully, ensuring unwavering data integrity, enhanced security, and optimized efficiency. Keywords deep blockchain, data storage, web applications 1. Introduction into blocks, which are interlinked through a parent hash within each block to reference the preceding block. To- Layer 1 blockchains such as Ethereum and Bitcoin, on gether, these blocks serve as a ledger, with block hashes their own, cannot support the latency and throughput employed to spot the ultimate state: needs for modern web applications [1]. Attempting to support higher throughput or lower latency with naive 𝑖 πœŽπ‘‘+1 ≑ Π𝑖 (πœŽπ‘‘π‘– , 𝐡𝑗𝑖 ) (2) 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 sacri- 𝐡𝑗𝑖 ≑ (. . . , (𝑇𝑗𝑖0 , 𝑇𝑗𝑖1 , . . .)) (3) fices 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 Π𝑖 (πœŽπ‘‘π‘– , 𝐡𝑗𝑖 ) ≑ Ω𝑖 (𝐡𝑗𝑖 , Ξ₯𝑖 (Ξ₯𝑖 (πœŽπ‘‘π‘– , 𝑇𝑗𝑖0 ), 𝑇𝑗𝑖1 , . . .)) (4) be stored there. This can be done in layers, where Layer i+1 blockchain’s state is stored in Layer i blockchains and where Ω𝑖 is the block finalization state transition func- each blockchain uses a well-motivated consensus engine tion for layer 𝑖, 𝐡𝑗𝑖 is the 𝑗th block of layer 𝑖 (which to achieve Byzantine fault tolerance [3]. Using this lay- collates transactions and other components), and Π𝑖 is ered approach, the key elements of a deep blockchain ar- the block-level state transition function for layer 𝑖. chitecture can be specified. The blockchain paradigm [4] In a deep blockchain system, a blockchain layer 𝑖 is that forms the backbone of all decentralized consensus- said to be connected to layer 𝑖 + 1 if: based transaction systems to date is as follows. A valid 1. there exists a transaction mapping function Λ𝑖+1 state transition for a blockchain of Layer 𝑖 is one which mapping blocks at layer 𝑖 + 1 into transactions comes about through a transaction 𝑇𝑗𝑖 : π‘‡π‘˜π‘– at layer 𝑖 for all layer 𝑖 + 1 blocks 𝐡𝑗𝑖+1 𝑖 πœŽπ‘‘+1 = Ξ₯𝑖 (πœŽπ‘‘π‘– , 𝑇𝑗𝑖 ) (1) π‘‡π‘˜π‘– ≑ Λ𝑖+1 (𝐡𝑗𝑖+1 ) (5) where Ξ₯ is the Layer 𝑖 blockchain state transition func- 𝑖 tion, while πœŽπ‘‘π‘– enables components to retain arbitrary 2. there exists a mapping function Ξžπ‘– (π‘˜) retrieving state between transactions. Transactions are organized from blockchain layer 𝑖 a mapping 𝑓 (π΅π‘˜π‘–+1 ) of the blocks state of layer 𝑖 + 1 for all blocks π΅π‘˜π‘–+1 BISEC’2023: 14th International Conference on Business Information Security, November 24, 2023, NiΕ‘, Serbia Ξžπ‘– (π‘˜) ≑ 𝑓 (π΅π‘˜π‘–+1 ) (6) * Corresponding author. $ yajnanpandith@gmail.com (Y. Pandith) A natural choice for transaction mapping Λ𝑖+1 (𝐡𝑗𝑖+1 ) Β© 2024 Copyright for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0). may be to include a block hash 𝑏𝑖+1 of the block π΅π‘˜π‘–+1 CEUR Workshop Proceedings http://ceur-ws.org ISSN 1613-0073 CEUR Workshop Proceedings (CEUR-WS.org) π‘˜ CEUR ceur-ws.org Workshop ISSN 1613-0073 Proceedings 2. Layer 2: Plasma Cash Blockchain Seminal insights on multi-layer blockchains were put forth by [8], which have inspired many β€œPlasma” de- signs, and specifically motivated our implementation of what has been termed β€œPlasma Cash” for tracking stor- age 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, Al- ice deposits some Layer 1 currency πœ†π‘‘π‘’π‘ (.01 ETH or 1 WLK) in a Layer 1 contract function (createBlockchain); the deposit event results in Alice owning a Layer 2 token 𝜏 through a Layer 2 Deposit transaction included in a Layer 2 block. β€’ User Transfer: When Alice wishes to transfer her Layer 2 token 𝜏 to another user Bob or the Figure 1: Deep Blockchains: In the deep blockchain archi- Plasma operator Paul, Alice signs a Layer 2 token tecture explored here, each layer 𝑖 + 1 is connected to layer 𝑖 transfer transaction specifying the recipient and with transactions submitted to layer 𝑖 for every block at layer the previous block. This Layer 2 transaction is 𝑖 + 1. Typically, block hashes and Merkle roots are submitted in transactions as key attributes of the block. included on the Layer 2 blockchain by Paul. β€’ Layer 2 Block Connection: The operators of the Layer 2 blockchain mints new Layer 2 blocks 𝐡𝑗2 with a collation of Layer 2 transactions π‘‡π‘˜2 as a transaction π‘‡π‘˜π‘– [5], and for the lower layer to pro- (with a consensus protocol such as Quorum RAFT vide the block hash back (see Figure 1 (left)). This paper, and POA in permissioned networks or Ethereum demonstrates a deep blockchain system for provable stor- Casper for permissionless networks) from the age, situating a β€œPlasma Cash” design [6] in a Layer 2 User Deposit and User Transfer transactions. Blockchain and NoSQL/SQL/File Storage for any number Each Layer 2 block π΅π‘˜2 has its Merkle Root 𝑏2π‘˜ of Layer 3 Blockchains (see Figure 2). submitted to Layer 1 with a transaction π‘‡π‘˜2 = Historically, the low-throughput high-latency of Layer submitBlock(𝑏2π‘˜ , π‘˜) recorded in a Layer 1 block 1 blockchains resulted in immediate pressure to drive ac- 𝐡𝑙1 . The recipient Bob of a token transfer must tivities off-chain [7], but only a few β€œoff-chain” attempts receive the full history of all transactions from can be considered deep blockchains because they lack Alice and verify it against these Merkle Roots 𝑏2π‘˜ the connected blockchains. Layer 𝑖 + 1 and layer 𝑖 may stored in Layer 1, all the way to the original de- be explicitly connected in a deep blockchain system for posit. If any transaction in the history cannot be many different reasons: verified by Bob, Bob cannot accept Alice’s token 1. Higher throughput services at layer 𝑖 + 1 may be as payment. paid for using the value held in layer 𝑖 currency β€’ User Exit: When Alice wishes to withdraw her 2. Storing a limited set of information in layer 𝑖 + 1 token 𝜏 for Layer 1 cryptocurrency, she calls in layer 𝑖 may support the security and prove- startExit function with the last 2 transactions1 nance of layer 𝑖 which can be verified against and Merkle proofs 3. Proof of fraud at layer 𝑖 + 1 can be used for eco- that must match the stored Merkle roots to be nomic consequences at layer 𝑖 a valid exit; if no one challenges the exit, Alice receives the outstanding token balance within a The nascent label β€œLayer 2” encompasses many newly short time period when exits are finalized. developing notions ranging from state channels to almost β€’ User Challenges: If the operator Bob or another any approach that may help Layer 1 scale (e.g. bigger user Charlie notices that Alice’s exit attempt is blocks), but the term β€œdeep blockchain” is not used for all invalid, it submits a Merkle proof and rewarded Layer 2 notions but specifically for any situation where when a valid challenge indicates a invalid exit. one or more blockchains are connected in the above way. 1 As to why two, two is indicative, but not conclusive concerning Alice’s ownership, therefore a user challenge process is required. Remarkably, users of the Layer 2 blockchain can conduct their business securely even when the Layer 2 operator has 100% control over the Layer 2 blockchain! Any sign of malicious operator Paul and the Layer 2 users can exit, and all Layer 2 token values remain secure. How can practitioners reconcile instincts to pursue this objective: Blockchain 1.0 Objective: Maximize decentralization. with an obviously centralized operator? The answer is to pursue a more nuanced objective of Blockchain 2.0 Objective: Maximize the cost of successful attacks. With the Plasma Cash construct, the Blockchain 2.0 Objective is achieved with: Figure 2: Deep Blockchain for Storage: Users of 1. Layer 1 Smart Contracts supporting a Layer 2 NoSQL/SQL/Storage Layer 3 blocks createBlockchains on Connection to Layer 1 storage that collectively Layer 1, and use Layer 2 Plasma Cash to operate their blockchain. Layer 3 blocks are submitted to the Layer 2 make the cost of attacking the Layer 2 blockchain Blockchain with block transactions and chunks are insured. the same as the cost of attacking the Layer 1 Plasma Tokens are used for bandwidth. Cloudstore combines blockchain – for Ethereum and Bitcoin Layer 1 major computing platforms with Ethereum SWARM for both blockchains, this is the famous β€œ51% attack”, for resilience and speed. others it might be whatever is required to control the state of that Layer 1 Blockchain. 2. Layer 1 Cryptocurrency being used for value β€’ A chunk of bytes 𝑣 is stored in Cloudstore using transfer of services between users of the Layer 256-bit hash π‘˜ = 𝐻(𝑣) as the key to retrieve 𝑣. 2 Blockchain and the Layer 2 operator mediated Nodes that request a chunk by key π‘˜ can verify through deposits, token transfers and exits medi- correctness of the value 𝑣 returned from Cloud- ated by Layer 1 constructs store simply by checking if π‘˜ = 𝐻(𝑣). With the Layer 2 Block Connection and trust primitives β€’ Insurers of chunks can earn Layer 1 currency in place, Layer 2 can operate at much higher throughput with valid Merkle proofs; Failure to provide valid than Layer 1 because of its reduced consensus, but con- proofs result in severe insurance payouts tinuing to inherit Layer 1’s cost of attack and achieving β€’ Bandwidth consumed by a node, when hitting the the more fundamental objective. Therefore practitioners nodes threshold must result in signed payments of deep blockchain engineering must develop different instincts, incorporating different software trust primi-Layer 1 blockchains were initially developed without the concern for storage models being competitive with cloud tives between different constructed layers to achieve the same objective depending on the structure of between computing platforms or even a passing concern for band- layers and the value unlocked in each. width; the birth of Bitcoin and Ethereum Layer 1 focused on birthing trustless payments and trustless computa- tion mediated by a peer-to-peer network, rather than 3. Deep Blockchains for Provable about nodes providing decentralized storage [10]. In con- Data Storage trast, decentralized storage networks, as manifested in Ethereum SWARM and many other systems, promises to The specific deep blockchain system that has developed have a large peer-to-peer network of nodes sharing the re- extends the Blockchain 2.0 Objective up one more layer sponsibility to keep a portion of the world’s data and com- by incorporating trust primitives (Block transactions, pensated proportionately for the commodity storage and Sparse Merkle Trees) in provable NoSQL, SQL and Stor- bandwidth they provide. In these networks, a distributed age services, shown in Figure 2: Layer 3 NoSQL, SQL and hash table (typically, with Kademlia routing layers) is Storage blockchains rest on the storage and bandwidth used for logarithmic look ups of chunks, but in practice, services of Layer 2, which supervene on the decentral- 𝑂(π‘™π‘œπ‘”2 (𝑛)) retrieval times are just not competitive with ized computation and payment services of Layer 1. Our modern UI expectations or typical developer expecta- work follows Ethereum SWARM’s foundational work on tions. Nevertheless, decentralized storage networks have storage and bandwidth [9] which outlines the following a critical role to play in providing censorship-resistance. ideas that is situated in multiple layers: Rather than layer 3 rest solely on a decentralized stor- age network (which is slow but resilient and censorship- operation (approximately every 24 hours), pass- resistant), layer 3 can rest on both decentralized storage ing on Cloudstore costs to Layer 3 blockchains. networks and mature modern cloud computing platforms. Notably, Layer 3 blocks themselves are recorded Again, the Blockchain 1.0 Objective must be displaced in with storeChunk(π‘˜, 𝑣, 𝜏, πœ”) to store the layer 3 favor of the Blockchain 2.0 Objective: in this sense, more block in Cloudstore and then results in a call to storage variety increases the cost of attack. submitBlock(𝑏3𝑗 , 𝑗): Putting the elements together in a deep blockchain system for provable storage: 𝑇𝑗3 ≑ submitBlock(𝑏3𝑗 , 𝑗) (7) β€’ Layer 1 blockchain: When a developer Because the block storage is signed and because wishes to have a Layer 3 blockchain for the block transactions are signed, Layer 2 oper- NoSQL/SQL/Storage, they send Layer 1 currency ators collect storage payments with the layer 3 into createBlockchain(blockchainName blockchain operator consent, forming a kind of string) on MainNet; this can be refunded β€œstate channel” within the deep blockchain. Taken with a dropBlockchain(blockchainName together, this is the Layer 3 Block Connection, as string) operation (taking place of startExit). seen in Figure 1. The Layer 2 block consists of: When storage is used in blockchainName – the transaction root πœƒπ‘˜2 that utilizes the through the activities of Layer 3 blockchains (as SMT structure to represent just the tokens recorded by the Layer 2 blockchain below), this 𝜏1 , 𝜏2 , . . . spent in block π‘˜ balance goes down. Balances can added to and πœƒπ‘˜2 ≑ KT((𝜏1 , π‘‡πœ21 ), (𝜏2 , π‘‡πœ22 ), ...) (8) withdrawn by the owner of the blockchain. β€’ Layer 2 Plasma Cash Blockchain: The storage and – the token root πœπ‘˜ for all tokens πœπ‘— , ... retrieval of chunks in Cloudstore are exposed to πœπ‘˜ ≑ KT((𝜏1 , π‘‡πœ21 ), (𝜏2 , π‘‡πœ22 ), ...) (9) Layer 3 blockchains with the following 2 APIs (see Appendix A): – array of token transactions π‘‡π‘˜2 2 – storeChunk(π‘˜, 𝑣, 𝜏, πœ”) - stores a key- – array of block transactions π‘‡Λœ π‘˜ from all value pair mapping (π‘˜, 𝑣) in Cloudstore, Layer 3 blockchain operators using Layer backed by Layer 2 token 𝜏 (signed with πœ”) 2 services received from the Layer 1 transaction. – an account root, using an SMT to store an – retrieveChunk(π‘˜, 𝜏, πœ”) - retrieves a accounts β€œbalance” and a list of tokens held key-value pair mapping (π‘˜, 𝑣) in Cloud- by that account. store, backed by Layer 2 token 𝜏 (again, β€’ Layer 3 blockchains: Any number of Layer 3 signed with πœ”), and returning the balance blockchains that utilize storage and bandwidth of 𝜏 used so far can be layered on top of the Layer 2 blockchain, The Layer 2 operator will store via Cloudstore regularly submitting lists of chunks based on the in as many regions and cloud providers as structure of the Layer 3 blockchain. necessary to insure the chunk as follows: A new – For NoSQL + File Storage, there is a key type of Layer 2 block transaction insures a set for each row of NoSQL or File, and a value of chunks recorded through storeChunk calls. for the row (a JSON record) or raw file The cause of these chunks are from any Layer contents. The root hash changes when any 3 blockchain needing storage and bandwidth, table is added/removed or when any table where bandwidth is used in retrieveChunk schema is updated, and where each table calls. When a Layer 3 blockchain mints Layer 3 has a root hash that changes when any blocks, the Layer 3 blocks themselves contain a record of the table is changed; any new Cloudstore key that references a list of chunks database content results in new chunks, written in the Layer 3 block. The block itself is where the chunk is referenced by the hash stored in Cloudstore with another storeChunk of its content. call, signed by the Layer 3 blockchain owner, – For SQL, there is a root hash for each and the block hash 𝑏3π‘˜ is submitted by the Layer database, where the root hash changes 3 blockchain to the Layer 2 blockchain via a when any table schema is updated, and submitBlock(𝑏3π‘˜ , π‘˜) block transaction. This where each table has a root hash that enables the Layer 2 blockchain to meter the cumu- changes when any record of the table is lative storage of blockchainName and deduct changed; any new database content results from the balance originally deposited in the in new chunks, where the chunk is refer- createBlockchain(blockchainName string) enced by the hash of its content. Both NoSQL and SQL Blockchains is described in β€’ delete(π‘˜) - deletes the key by inserting the null Section 5. value for π‘˜ into the SMT β€’ get(π‘˜) - gets the value from the SMT through Just as with Layer 1 blockchain nodes, running Layer node / chunk traversal 2 and Layer 3 blockchains consists of running a node within the framework of a decentralized system, retriev- Typically, block proposals with SMTs as a core data struc- ing and relaying messages about new transactions and ture involve bulk combinations of the above, with many new blocks. Wolk’s blockchain implementations of the inserts and deletes mutating the content of many chunks, Layer 2 and Layer 3 originated from Ethereum’s go- and the Merkle root only being computed as a final step. ethereum and JPMorgan’s Quorum RAFT code bases, Sparse Merkle Trees are best suited for a core primitive written in Golang. RAFT is used for both Layer 2 and over more familiar Binary Merkle Trees (BMTs) because: Layer 3 implementations due to its simple model of fi- β€’ when an id (a tokenID, a document key in NoSQL, nality. For each blockchain, Golang package is created a URL in File storage, a table root in SQL) is containing each of the interfaces specified in Appendix mapped to a value, you can guarantee that the id A, and adapted Quorum RAFT code to conform to these has exactly one position in the tree, which you interfaces. There is no explicit assumption that permis- don’t get with BMTs. sioned consensus algorithms be used, however. The β€’ when an id is NOT present in the SMT, you can choice of RAFT was made purely out of simplicity, its also prove it with the same mechanism. This maturity as a code base, and its capacity for high through- approach proves beneficial in situations where put – any consensus protocol that achieves finality can Bloom filters produce erroneous matches. fit within this deep blockchain architecture. For both the β€’ A Merkle proof for the id mapped to a specific Layer 2 and Layer 3 blockchains, Sparse Merkle Tree is value is straightforward, and because of sparse- used to support provable data storage. ness the number of bytes required is much less than the depth of the tree 4. Sparse Merkle Trees and The key concept behind SMTs is the efficient representa- Provenance tion of included IDs using 𝑛 hashes at 𝑛 out of 2π‘ž leaves. Each ID, represented as a π‘ž-bit number, is associated with The Sparse Merkle Tree (SMT) is a persistent data struc- either a null value or its corresponding hash at a leaf node. ture that map fixed π‘ž-bit keys to 256-bit values in an Instead of using a Merkle proof consisting of 64 32-byte abstract tree of height π‘ž with 2π‘ž leaves for any set I: hashes from the leaf to the root, a compact represen- tation can be achieved using proofBits, a π‘ž-bit value I = {(k0 ∈ Bπ‘ž , v0 ∈ B256 ), (k1 ∈ Bπ‘ž , v1 ∈ B256 ), . . .} (e.g., uint64). Each bit in proofBits indicates whether (10) the sisters on the path to the root use default hashes The function of the SMT is to provide a unique Merkle (0) or non-default hashes stored in proofBytes. The root hash that uniquely identifies a given set of key-value proofBytes array exclusively consists of non-default pairs I, a set containing pairs of byte sequences. Each key hashes, while the value stored at the leaf level is the stored in the SMT defines a Merkle branch down to one 32-byte RLP hash. of 2π‘ž leaves, and the leaf holds only one possible value for For the Layer 2 Block Connection, a call to that key in I. The bits of the π‘ž-bit key define the path to checkMembership(bytes32 leaf, bytes32 root, be traversed, with the most significant bit at height π‘ž βˆ’ 1 uint64 tokenID, uint64 proofBits, bytes and least significant bit at height 0. Following [11] and proofBytes helper function in Ethereum MainNet can [12], to compute the Merkle root of any SMT in practice take proofBits and proofBytes and prove that a exit and allow for the ideal computation of Merkle branches or challenge is valid if it matches the Merkle roots pro- for the 𝑛 Merkle branches, it is useful pre-compute a set vided by the Plasma operator in a call to of default hashes 𝑑(β„Ž) for all heights h from 0 . . . π‘ž βˆ’ 1 levels: (shown in Figure 3) submitBlock(bytes32 root) β€’ At level 0, 𝑑(0) ≑ 𝐻(0) Similarly, when a user receives a token from another β€’ At level β„Ž, 𝑑(β„Ž) ≑ 𝐻(𝑑(β„Ž βˆ’ 1), 𝑑(β„Ž βˆ’ 1)) user, they must obtain the tokenID, along with 𝑑 raw transaction bytes and 𝑑 Merkle proofs. Each Merkle proof Logarithmic insertion, deletion and retrieval operations corresponds to a specific block and verifies the token on the SMT are defined with elemental operations: spend. It’s important to note that a non-spend can also β€’ insert(π‘˜, 𝑣) - inserts the key by traversing be proven, where the leaf is represented by 𝐻(0). chunks using the bytes of π‘˜ In the optimal scenario, an SMT representing a sin- gle key-value mapping (𝑛 = 1) reduces the proof size 6 transactions per Layer 2 block (500 Γ— 10 Γ— 86400Γ— 10 365 ). 15 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 in- stead of uint256) β€’ less gas is spent in checkMembership on all 0 bits in proofBits β€’ smaller 64-element array of default hashes com- puted instead of 256 hashes Reducing the frequency of hashing leads to decreased gas Figure 3: Sparse Merkle Tree Illustration: Merkle branches consumption and increased user satisfaction, particularly for 2 64-bit keys π‘˜1 = 001..00 and π‘˜2 = 101.. hold in the Level 2 block connection. In this context, it ensures 𝐻(𝑉1 ) and 𝐻(𝑉2 ) in a unique SMT root 𝑅 for a 2 key set that collisions between circulating tokenIds can be defini- I = {(𝐾1 , 𝑉1 ), (𝐾2 , 𝑉2 )}. Since there are only keys in this tively ruled out during deposit events. Moreover, you can tree, the default hashes 𝑑(β„Ž) (outlined in red) appear starting combine the fixed length proofBits and variable length at level 62, so the branches 𝐾1 , 𝐾2 (shown in blue circles) proofBytes into a single proof bytes input for exits, i.e. have Sparse Merkle proofs using default hashes from level 0 startExit(uint64 tokenID, bytes txBytes1, to level 62, which can be specified in a proofBits parameter. bytes txBytes2, bytes proof1, bytes proof2, This makes for very tiny proofs and lower gas costs on Main- int blk1, int blk2) The analogous challenge inter- Net. faces will then have fewer argument inputs in the same way. The sparseness of the SMT derives from the observa- significantly. Instead of a 64 Γ— 32 byte proof, the en- tion that keys will extremely rarely share paths at in- tire path from level 0 to level 63 consists of default creasingly lower heights and naturally will share paths hashes, and proofBits is a 64-bit value filled with zeros at increasingly higher paths. This lends itself to a repre- (0x0000000000000000). In this case, proofBytes is sentation where the SMT is chunked by byte k , where 𝑖 empty, and the uint64 value is 0, resulting in the most traversing the SMT from a root chunk (representing a compact proof size possible: 8 bytes. range of keys from 0 to 264 -1) down to an intermediate In the following favorable scenario, considering 2 chunk with just one leaf involves processing one addi- ids (for example, 0x01234... and 0x89abc...), the tional byte, which each chunk of data storage having proof of spend for each token would include a sin- up to 256 child chunks specifying a range of keys each gle non-default hash at the topmost level 63, and child posessing a range that is 1 smaller. Just as with a proofBits would consist of the value 1 followed by 256 radix tree, the SMT is traversed from root to leaf, with an 63 zeros (0x8000000000000000). The resulting proof additional byte of the key causing a read of a chunk that size would be 40 bytes. represents up to 256 branches and the hashes of all the In typical scenarios, SMTs exhibit high node density branches, utilizing default hashes. Golang "smt" pack- in the upper levels, ranging from level π‘ž βˆ’ 1 down to age is implemented and a "cloud" package to map SMT approximately level π‘™π‘œπ‘”2 (𝑛). To illustrate this, consider operations into Cloudstore. 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 5. Layer 3 Blockchains tokens annually. Assuming a Layer 2 block frequency of 15s/block, these 5B transactions would be distributed With the foundations of Layer 2 providing storage and across 2.1MM blocks per year, with an average of 2,378 bandwidth paid for with Layer 2 tokens, any number of Layer 3 blockchains may be constructed. The con- 𝑉1 = 0x778899..)] struction of a NoSQL and SQL blockchain is detailed SetKey(𝐾2 , 𝑉2 )] here. At a high level, Layer 3 blockchains collate SQL and NoSQL transactions in Layer 3 blocks submit block which results in a set of SMT primitive operations: transactions to Layer 2, and Layer 2 collate token and block transactions with Merkle Roots of token root and insert(𝐻(𝐾1 ), 𝐻(π‘’π‘›π‘π‘Ÿπ‘¦π‘π‘‘(𝑉1 , πœ‹))), blocks submitted and included in transactions to Layer 1 insert(𝐻(𝐾2 ), 𝐻(π‘’π‘›π‘π‘Ÿπ‘¦π‘π‘‘(𝑉2 , πœ‹))) blockchain. It then becomes possible to aggregate multi- ple proof of inclusions at the highest layers all the way to resulting in Layer3KeyRoot = 0x83fc.... MainNet with Deep Merkle Proofs, which is illustrated The chunks for both documents 𝐻(𝑉1 ) and here. 𝐻(𝑉2 ) along with chunk of the previous block 301 (e.b. storeChunk(0b001.., ...)) are in- 5.1. Layer 3 NoSQL Blockchain and Deep cluded in Layer 3 Block 302 in the ChunkIDs and insured with a call to Merkle Proofs To support Layer 3 NoSQL transactions in a NoSQL submitBlock(0b101..11, 302) blockchain, the Layer 3 blockchain has a layer 3 block structure defined as collating a set of NoSQL records submitted to the Layer 2 blockchain. along with a Layer3KeyRoot of a Sparse Merkle Tree β€’ When the Layer 2 blockchain processes the managing a set of key-value pairs of β€œdocuments”. block transactions from this new Layer 3 block All NoSQL records are encrypted using counter mode (and many other Layer 3 blockchains) to build (CTR) encryption defining operations π‘’π‘›π‘π‘Ÿπ‘¦π‘π‘‘(𝑑, πœ‹) and Layer 2 Block 2002, it will build a SMT with π‘‘π‘’π‘π‘Ÿπ‘¦π‘π‘‘(𝑑, πœ‹) and utilizing a database encryption key πœ‹ insert(concat(blockchainName, 302), known only to the layer 3 blockchain user. Three opera- 0b001..00 (and other inserts) to generate a tions are defined, each of which map into the SMT data BlockRoot (e.g. 0x4d69..). As is standard, structure: the new BlockRoot uses the previous blocks BlockRoot as a starting point. Packaging the β€’ SetKey(π‘˜, 𝑣) - stores arbitrary π‘˜, 𝑣, block transactions together with any token trans- through a storeChunk(k, v) Layer 2 oper- actions (balance updates, transfers, deposits, ation and a Layer 3 SMT operation on πœ… etc.), the new layer 2 block 2002 with hash (insert(𝐻(π‘˜), 𝐻(π‘’π‘›π‘π‘Ÿπ‘¦π‘π‘‘(𝑣, πœ‹)))) 0xe8db.. will be stored in Cloudstore with a β€’ GetKey(π‘˜) - retrieves the value 𝑣 stored in the call to storeChunk(0xe8db...) Txs and sub- SetKey(π‘˜, 𝑣) operation, through Layer 3 opera- mitted to Layer 1 with a call to tion on πœ… get(H(k)) which returns π‘£β„Ž followed by π‘‘π‘’π‘π‘Ÿπ‘¦π‘π‘‘(retrieveChunk(π‘£β„Ž ), πœ‹) submitBlock(0xe8db..., 2002). β€’ DeleteKey(π‘˜) - removes π‘˜ from the NoSQL database, by storing (𝐻(π‘˜), 0) in the SMT; subse- β€’ Finally, a Layer 1 Block (e.g. 10,000,002) will quent calls to GetKey(k) will not return a value. be proposed by some MainNet miner including the above Layer 2 submitBlock transaction and The minting of a new Layer 3 NoSQL Block con- eventually be finalized by the Layer 1 consensus sists of taking each of the Layer 3 transactions protocol. (SetKey, DeleteKey), executing storeChunk Layer 2 API calls for its users. Unless two transactions operate A Deep Merkle Proof is formed through the aggre- over the same key π‘˜, all transactions can be executed ingation of each proof of inclusion across each layer of parallel. If multiple transactions operate over the sameblockchain connections in a deep blockchain down to key, only the last received transaction will have its muta- Layer 1. In our 3 layer deep blockchain with the Layer tion succeed. 3 NoSQL blockchain layered on the Layer 2 Storage / example (shown in Figure 4) Plasma Cash blockchain, there is a Layer 2-3 connection and a Layer 1-2 connection. So a full Deep Merkle Proof β€’ In Layer 3 Block 302, the user wishes store doc- that a NoSQL document 𝐾1 , 𝑉1 is included in the deep ument ID 1 with key 𝐾1 mapped to encrypted blockchain all the way up to MainNet consists of: value 𝑉1 and document ID 2 mapped to encrypted value 𝑉2 . The user can submit 2 Layer 3 NoSQL 1. Layer 3 proof of inclusion of (𝐻(𝐾1 ), 𝐻(𝑉1 )) in transactions: Layer 3 block Layer3KeyRoot – in our example, this would be that the value 𝐻(𝑉1 ) hashes up to SMT root 𝑅302 = 0x83fc... [SetKey(𝐾1 = 0b001...00, Figure 4: Deep Merkle Proof illustrated: The hashes key-value pair is recorded in a Layer 3 Sparse Merkle Tree, the root of which is kept in Layer3KeyRoot in the Layer 3 block. When the Layer 3 operator uses submitBlock to submit a block transaction to Layer 2, Layer 3 Block hash 302 is included in another SMT maintained by the Layer 2 operator storing all Block hashes of all Layer 3 blockchains. When the Layer 2 block 2002 is minted, the BlockRoot is set and included in Layer 1 Block 10,000,002. The individual proof of inclusion from the 2 SMTs and the portions of the raw Layer 3 and Layer 2 block form a Deep Merkle Proof for inclusion a specific record in the deep blockchain, from the highest layer to Layer 1. 2. Layer 2 proof of inclusion of Layer3KeyRoot, which are shown to match (𝐻(concat(blockchainName, k))) in 𝐻(𝐾), 𝐻(𝑉 ) Layer 3 block Layer3KeyRoot – in our ex- β€’ Layer 2 Block, which includes BlockRoot ample, this would be that the Layer 3 block β€’ proofBits and proofBytes for the hash 0b101..11 hashes up to SMT root BlockRoot, which are shown to match 𝑅2002 = 0x4d69.. the Layer 2 Block Hash 3. Layer 1 proof of inclusion of the Layer 2 block β€’ Layer 1 blockHash record of the Layer 2 block hash in the blockHash array of the Layer 1 number Smart Contract – in our example, this is that blockHash(2002) = 0xe8db The concept of a deep Merkle Proof is not limited to 3 layer deep blockchains, nor is the concept only applicable In our implementation, deep Merkle proofs are provided to NoSQL blockchains – the concept applies to multiple in response to GetKey(𝐾, 𝑉 ) to the layer 3 blockchain layers of proof of inclusion enabled through the general users as an optional deep boolean parameter and when layering processes of deep blockchain systems generally. true, returns the full combination of: β€’ Layer 3 Block, which includes Layer3KeyRoot β€’ proofBits and proofBytes for the 5.2. Layer 3 SQL Blockchain In our SVM Golang implementation, all opcodes are mapped into Layer 2 storeChunk and receiveChunk To support Layer 3 SQL operations in a SQL blockchain, calls, manipulating the following chunk types: the Layer 3 block has a structure defined as hav- ing as packing a set of encrypted SQL transactions β€’ Database Schema chunk: represents up to 32 ta- (insert/update/delete statements) along with a bles belonging to the β€œblockchainName”. Each Layer3KeyRoot of a Sparse Merkle Tree representing table is identified by name (up to 32 bytes) and a set of table root hashes. has a table chunk; In our implementation, Quorum RAFT is adopted as β€’ Table chunk: represents up to 32 columns belong- the consensus layer for our layer 3 SQL blockchain (again, ing to a specific β€œtable”. Each column is identified following Appendix A), which collectively follow a con- by name (up to 27-bytes) and additional informa- sensus protocol where once a leader has been identified, tion: its column type (integer, string, float, etc.), the leader mints a new Layer 3 block based on: whether it is a primary key, and any index infor- mation; a 32-byte chunk ID points to a potential β€’ An array of SQL transactions that is mapped into index chunk, if the column is indexed A table must newly created chunks (created via storeChunk have at least one primary key. for table root hashes) β€’ Index chunk: a B+ tree, composed of intermediate β€’ An array of table root hashes, key-value pairs β€œX” chunks and data β€œD” chunks. Each X chunk written to Layer3KeyRoot, based on the execu- has 32-byte pointers to additional X chunks or D tion of the above SQL Transactions chunks. D chunks form a ordered doubly linked The minting a layer 3 block consists of the leader com- list, and contain pointers to record chunks. piling each SQL transaction into a set of instructions β€’ Record chunk: a 4K chunk of data that holds a to executed by a β€œSQL Virtual Machine” (SVM) based JSON record for a keyed value. off of the widely used SQLite’s virtual machine. In this Our current implementation has a full implementation model, a virtual machine has a program counter that in- of single table operations thus far, but with relational crements or jumps to another line after the execution of database operations approachable with the same dynam- each opcode instruction. For example, a SQL statement ics: of "Select * from person" received by a node is mapped into a interpretable set of opcodes like this: β€’ When the owner of a Layer 3 blockchain creates a new database, the owner chunk is updated and {"n":0,"opcode":"Init","p2":8,"p4" database chunk is created and the owner chunk ":"select * from person"} is updated with the new database chunk informa- tion. If this is the first database created by the {"n":1,"opcode":"OpenRead","p2" owner, the root hash of the owner is set for the :2,"p4":"2"} first time. The root hash of the database is set for the first time. {"n":2,"opcode":"Rewind","p2":7} β€’ When the owner of a Layer 3 blockchain creates a new table, the database chunk is updated and {"n":3,"opcode":"Column","p3":1} table chunk is created and the database chunk is updated with the new table information. This {"n":4,"opcode":"Column","p2" also causes the owner chunk to be updated with :1,"p3":2} the new database chunk information. The root hash of the table is set for the first time in the {"n":5,"opcode":"ResultRow","p1" child chain. :1,"p2":2} β€’ When the owner of a Layer 3 blockchain creates or updates a table, this creates or changes the {"n":6,"opcode":"Next","p2" database schema chunk. The database chunk is :3,"p5":1} then updated with the new schema information, {"n":7,"opcode":"Halt"} which in turn causes the owner chunk to be up- dated with the new database chunk information. {"n":8,"opcode":"Transaction","p3" β€’ When an owner creates a new record in a table :3,"p4":"0","p5":1} with a SQL statement such as {"n":9,"opcode":"Goto","p2":1} insert into account (id, v)") values (42, "minnie@ethmail.com") the index chunks (X chunks and D chunks) are which proceeds just as in the NoSQL blockchain, with updated with new primary key information and the analogously structured Deep Merkle Proof. Where in a record chunk is created in JSON form the NoSQL chain, each NoSQL document / row updated resulted in an updated leaf in the SMT for the newly {"id":42, "v":"minnie@ethmail.com"} updated document, now with the SQL chain, each SQL Because the index chunk changes, the table chunk statement supports a new table root hash change in an changes. The root hash of the table is set for the update leaf in the SMT. first time in the child chain. When an owner updates a record in a table with a SQL statement lie 6. Paying for Storage and update account set v = Bandwidth "minnie@mail.eth" where id = 42 The Layer 3 blockchain users who store NoSQL/SQL/File the record has a new chunkID because of the new data with storeChunk operations give the Layer 2 op- JSON content erator permission to charge for bandwidth and storage in two different ways: {"id":42, "v": "minnie@mail.eth"} and so one or more index chunks are updated 1. Bandwidth is paid for through (1) users sign- with a new chunkID. ing retrieveChunk(π‘˜, 𝜏, πœ”) calls to retrieve β€’ When an owner drops a database, the owner data and obtaining recent balances, where chunk is updated globally. Additionally, any ta- each call uses up a tiny amount of bandwidth bles associated with the database at the time of backed for with a token 𝜏 originated by the createBlockchain call; (2) users signing a new deletion should have their root hashes updated. updateBalance(𝜏, , πœ”) request originated by β€’ When an owner deletes a table, the root hash of operator and agreeing to making a payment for the table is updated, the schema chunk is updated, incurred bandwidth usage and the latest token and the database chunk is updated with the new owner balance. An updateBalance response by schema chunk info and removing the table name. users is mapped into layer2 transaction, where in- The owner chunk is then updated with the new curred bandwidth cost is deducted from token’s database chunk info.. owner balance (𝜏 ) and added to operator’s al- When the leader node of a Layer 3 SQL blockchain mints lowance 𝛾(𝜏 ). a Layer 3 block, it must include in its Layer 3 block: 2. Storage is paid for through Block Transactions β€’ the SQL transactions – where for each table ref- submitBlock(𝑏3π‘˜ , π‘˜) signed by the Layer 3 erenced in the SQL, the leader must retrieve the blockchain operator - because chunks are identi- previous root hash of the table in the SMT and fied directly inside Layer 3 blocks, a tally of the execute the SVM operations for that table against number of bytes used in each new layer 3 block that SMT’s data. is added to the SMT. The Layer 1 contract then β€’ the Chunks newly written through the execution exposes storageCharge interface to the Layer of the SQL transactions, where chunks are only 2 operator where a recently signed Layer 2 block created, and never β€œupdated”. transaction (containing a tally of the number of β€’ a new Layer3KeyRoot transactions and calls bytes, signed by the Layer 3 blockchain operator) submitBlock(𝑏3π‘˜ , π‘˜): for all tables updated from is used to deduct the layer 3 operator’s balance the SQL transactions, each table has a new root since the last time it was called. This is detailed hash. Using the Layer3KeyRoot, any layer 3 below. node can respond to a SQL SELECT query by re- In this way Layer 3 Blockchains pay for the services of the trieving the the previous hash of any table from Layer 2 blockchain. The lifecycle of a short lived Layer 3 the SMT. Using the Layer3KeyRoot, any layer blockchain is shown in Figure 5, which is expounded in 3 node can respond to a SQL SELECT query by the next section. retrieving the the previous hash of any table from the SMT 6.1. Layer 2 Plasma Tokens for Bandwidth With a newly minted Layer 3 block π‘˜, the Layer 3 SQL Payments blockchain can submit a layer 2 block transaction π‘‡π‘˜3 for the Layer 3 Block 𝑏3π‘˜ In this section it is explained how Layer 2 Tokens can 3 form a unidirectional payment channel, where each signed submitBlock(π‘π‘˜ , π‘˜) Figure 5: Samples of a Layer 3 NoSQL Blockchain User in the Deep Blockchain architecture presented here. A Layer 3 user creates a Layer 3 Blockchain by sending 1 ETH to createBlockchain and receives a Plasma token (1 pETH) which is included as a deposit in Layer 2 block 2000. The Layer 3 user does 2 SetKey operations included in Layer 3 block 300, which result in the Layer 3 blockchain signing 2 storeChunk for each key-value pair. The Layer 3 blockchain mints Layer 3 Block 300 and stores it again with 3rd signed storeChunk call, finally calling Layer 2’s submitBlock with the hash of Block 300. The Layer 2 operator includes this block transaction in Layer 2 Block 2001, stores it in Cloudstore, and submits it the Layer 1 blockchain with a Smart Contract call to submitBlock. 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 owner as a condition of looking up the chunk. in a Layer 2 block (and has no nonce to increment) but The Layer 2 operator must have tally aggregation capa- simply indicative of "permission to return some data and bility that can aggregate numerous signed calls together decrement my token balance"; where the Layer 2 operator and compute that token 𝜏 has some new balance (𝜏 ). In can check the signature against its record of the current our implementation simple minute-wise Hadoop job is proof of storage then it may deduct from this deposit. On used to tally periodic flushes of retrieveChunk oper- the other hand, if the layer 3 blockchain has reason to ations grouped by different 𝜏 , keeping as a short-term believe that some chunk is lost, it can submit its claim output (TTL=3600s) log that each minutewise change to Layer 1 smart contract and demand Merkle proofs of 𝜏 was caused by specific signed operations; this bal- in response. The CRASH patterns of [9] specify this ance update log is exposed to the user. When this in- challenge-response system in detail, which is extended ternal tally reaches a critical threshold Ξ£π‘šπ‘Žπ‘₯ , responses to our deep blockchain in the following way: to retrieveChunk halts and can only resume with a Layer 2 updateBalance transaction submitted and in- β€’ Insurance Request. Each Layer 3 block 𝐡𝑗3 ( sub- cluded in the Layer 2 block directly in the SMT root mitted to the Layer 2 operator in the block trans- Layer2TokenRoot. The threshold Ξ£π‘šπ‘Žπ‘₯ in the con- action submitBlock(𝑏3𝑗 , 𝑗) calls ) includes (1) a seed hash 𝛾, where the seed 𝜈 (𝛾 = 𝐻(𝜈)) is tract. To minimize disruptions from halting in this way, held solely by the layer 3 operator and revealed it is the responsiblity of the Layer 3 blockchain to peri- when the layer 3 operator wishes to challenge odically submit updateBalance, signing recent token the Layer 2 operator with storageChallenge balances provided in the retrieveChunk. (see below); (2) the hash of an SMT Merkle root Moreover, as the token has considerable usage ac- 𝐻(Ξ) for all the chunks specified in the layer 3 cumulated, and as users regularly submit sufficient block using 𝜈; (3) the total collection size in bytes updateBalance transactions to Layer 2, the value of πœŽπ‘‘π‘œπ‘‘π‘Žπ‘™ in all Layer 3 blocks; (4) a Ω parameter, the the balance may accumulate to a great enough level that amount of layer 1 currency required to hold 1 GB the Layer 2 operator may wish to withdraw the balance per month (e.g. if market conditions for keeping accumulated directly in the Layer 1 contract. To sup- data in 8 places in Cloudstore is $.25 GB/mo and port this,the SMT state is expanded to include the token Layer 1 currency is $500/𝐸𝑇 𝐻, then Ω would balance and the operator withdrawal amounts. be 5 Γ— 101 4 wei). The Layer 2 operator uses πœ… If users wish to transfer the token to another user of to fetch the list of chunks the Layer 3 operator the layer 2 blockchain by submitting a token transfer op- wishes to insure, verifies that all chunks in the eration, the updateBalance must be executed to β€œclose” list are in fact available, and checks that πœŽπ‘‘π‘œπ‘‘π‘Žπ‘™ the token-based state channel. matches the Layer 2 operators own tally closely. Finally, users who wish to withdraw token 𝜏 for Layer If the chunks are missing, or the tally is not rea- 1 currency can do so by calling startExit with the sonable, the Layer 2 operator may reject the block. last 2 transfers and this last updateBalance, which will Otherwise, the Layer 2 blockchain will include redeem the denomination less the tally of what has been the Layer 3 block hash in the BlockRoot of the withdrawn by the operator. Others may challenge this next Layer 2 block. In this way, the block trans- exit, but only with a valid proof of user double spending action is taken as a signed request to insure the 𝜏. entire Layer 3 blockchain’s storage. β€’ Storage Charges. Under ordinary conditions, the 6.2. Layer 1 Storage Insurance layer 2 operator can submit the most recent proof Because every single write of a Layer 3 blockchain is of any signed block transaction to the Layer 1 included in sequentially ordered layer 3 blocks (each of smart contract function: storageCharge(blockchainName string, which identify a set of Chunk IDs) the layer 3 blockchain txbytes bytes, storagecost uint64, forms an itemized list of signed insurance requests that sig bytes) Since txbytes contains πœŽπ‘‘π‘œπ‘‘π‘Žπ‘™ form a Layer 1 unidirectional state channel initiated by the deposit into createBlockchain. Assuming no chal- and Ω, the storageCharge function can lenges exist, if the Layer 2 operator that receives a Layer deduct from balance originally deposited 3 block identifying a set of chunks can provide a recent via createBlockchain since the last time storageCharge was called. 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. 7. Discussion There have been many approaches scaling blockchain architecture to support higher throughput and lower la- Figure 6: Three-layer deep blockchain model. tency: β€’ Changing the security model of Layer 1 β€’ Storage Challenge-Response: CRASH proofs. If blockchains (c.f. NEO, EOS’s approach) at any time, the Layer 3 blockchain wishes β€’ Incremental improvements to Layer 1 or Layer to challenge Layer 2’s inept storage (due to a 0 that don’t change security model (c.f. larger missing block or missing chunk included in the blocks) block), it may do so by demanding a CRASH β€’ Having many separate chains, using sharding proof of a specific layer 3 block, revealing 𝜈 β€’ State Channels (which must match the 𝛾 in txbytes) by calling: β€’ Layer 2 Plasma solutions ] storageChallenge(blockchainName string, blockNumber uint64, seed This paper focussed on the last approach, and de- bytes32) A valid CRASH-proof response must scribed how using the core ideas behind Layer 2 Plasma be provided by the layer 2 operator within Cash can be extended to a deep blockchain system, form- some time period (e.g. 3 to 7 days) or the ing the basis for provable data storage for widely used challenger layer 3 user will obtain a payout pro- NoSQL + SQL developer interfaces. The concept of Deep portional to πœŽπ‘‘π‘œπ‘‘π‘Žπ‘™ contained in txbytes. Merkle proof for a 3 layer deep blockchain system is storageResponse(blockchainName illustrated here and shown its conceptual viability, bor- string, blockNumber uint64, rowing state channel concepts for Layer 3 NoSQL and proofBits uint64, proofBytes bytes) SQL blockchains to pay for storage and bandwidth. This payout must come from a registered balance Deep learning architectures have advanced numerous held in the Layer 1 Smart Contract. The response high-scale applications in every industry in a way that must be a valid proof whose root Ξ that matches is not about one specific deep learning algorithm – and 𝐻(Ξ) originally supplied for the block. Finally, instead about an approach that could not be achieved to guard against the situation that some layer through dogmatic faith in single-layer β€œneural” networks. 3 operator supplies a bogus 𝐻(Ξ) in the block In an analogous way, deep blockchain architectures could transaction to claim this payout, the layer 2 have the potential to enable a wide range of high-scale operator can supply a small number (e.g. 5) of applications in a way that might not be achieved through Merkle branches resolving to πœ…. The economic dogmatic faith in Layer 1 scaling innovations alone. incentives of this challenge-response system Blockchain practitioner instincts are to be wary of is refined to balance the layer 2 and layer 3 centralized consensus protocols and centralized storage. operators in this challenge-response pattern to However, our use of non-local storage can be rational- be reasonable relative to Layer 1 Ethereum gas ized, not by demanding that every component be dog- costs. matically decentralized, but by considering how attack With the above mechanism in place, the layer 2 operator vectors are reduced through judicious use of some not- can charge the layer 3 operator when transaction fees are so-decentralized components. The attacks on storage are negligible. In regular conditions, the Layer 3 blockchain limited in nature due to: β€’ verifiability of chunks, where all π‘˜, 𝑣 pairs re- node devolves into a dumb storage layer with some fail- trieved from non-local storage are verifiable ei- ure or attack probability (𝑝21 ..𝑝2𝑁2 for layer 2 blockchains, ther due to (a) π‘˜ being verified to the hash of the 𝑝11 ..𝑝1𝑁1 for layer 1 blockchains) – depending on this value 𝑣 returned (b) π‘˜ being directly included and probabilistic model, the cost of attack may be divined. signed by a trusted party. In this sense the attack However, it seems most likely that motivated parties vector is limited to the private key would attack the centralized control behind each layer β€’ the use of Ethereum SWARM (currently in POC3) (c.f. via EIP999, mining pools arewedecentralizedyet.com, as a censorship-resistant cloud storage provider. governments asking the Cloudstore providers to block In the event that the Layer 2 blockchain provider Layer 2 operator’s accounts) – in this sense the probabilis- loses access to its Cloud Storage backend, higher tic independence in concentrated efforts to attack layer layer backends can simply request chunks using 1 and 2 would be highly suspect. For this reason, our the Kademlia-based DHT of Ethereum SWARM. true faith relies in Ethereum SWARM’s resource updates Generally this censorship-resistance comes at the ([9]), where chunks may be keyed not by the hash of cost of higher latency responses. their content but with a resource key, which can be used β€’ cryptoeconomic incentives, wherein if a data for the block data without an index mechanism; all re- storer can prove (with a Merkle branch) that a source updates are signed so the reader can authenticate. piece of data can no longer be accessed but has Ethereum SWARM, because of its use of Kademlia-like been included on chain through a valid Merkle protocol, is not naturally as fast as other components in branch Cloudstore, but kicks in when all Layer 2 blockchains Cloudstore fail or when Layer 1 itself is attacked (via 51% It is believed the combination of decentralized stor- attacks, or unknown POS failures). If other decentral- age and cloud computing storage increases the cost of ized storage services provided similar provable storage attack and that the Blockchain 1.0 Objective of Maxi- as Ethereum SWARM’s resource update, so long as Layer mize decentralization must be altered in favor of the more 3 blockchain does not go Byzantine, only one answer can nuanced Blockchain 2.0 Objective Maximize cost of at- surface, making for unstoppable layer 3 blockchains. tack, which ultimately will lead to more secure and re- The Layer 3 NoSQL and SQL blockchains developed liable blockchain systems. One gets the best of both in this paper operated under an assumption that the worlds: from centralized storage one gets low-latency, NoSQL + SQL transactions should be private data se- high-throughput infrastructure, and from decentralized cured by an encryption key known only to the operators storage one gets resilience and censorship resistance. of the Layer 3 blockchain. This protects the Layer 3 Concerning the use of a single centralized Layer 2 op- blockchain from operators of Layer 2 blockchain and any erator, it is highlighted that in all cases where Layer 1 cur- Cloudstore. However, the same problem as with standard rency is deposited (in createBlockchain), because use databases (MySQL, MongoDB, DynamoDB, etc.) exists of the β€œPlasma Cash” design pattern, the owner of the to- with our current implementation of NoSQL/SQL Layer kens may withdraw its balance on the Layer 1 blockchain. 3 blockchains: once someone gets access to a Layer 3 This is a surprising result: that checks and balances on to- blockchain node holding the database encryption key or ken ownership are possible through the use of the Layer private key, the entire database is compromised. There- 1 blockchain despite the Plasma operator being in 100% fore, provenance and immutability of the NoSQL/SQL control; if users discover that the Layer 2 blockchain op- database state changes, as manifested in Deep Merkle erators are malicious, they can be certain they can get Proofs, differentiate a Layer 3 blockchain from standard the value of their tokens back, and if the data is kept in databases. The small latency incurred with permissioned resilient Ethereum SWARM (or if they have kept their protocols (RAFT, POA) and negligible cost should be data locally), they can move to another Layer 2 operator welcomed when provenance and immutability are of using the same protocol. paramount concern. This shows a deep blockchain that has a higher cost of Many other Layer 3 blockchains can be constructed attack than the deep blockchain illustrated in Figure 2, uti- using the Layer 2 storage and bandwidth infrastructure: lizing 𝑁2 Layer 2 blockchains (each with their own Cloud- a chain that represents the evolving state of ERC721 to- store) and 𝑁1 Layer 1 blockchains, each receiving the kens, a chain that represents a cryptocurrency exchange same Layer 3 submitBlock and Layer 2 submitBlock where your money can never be stolen, and so forth. The transactions respectively: state of the Layer 3 blockchain is not stored locally but Because the retrieval of layer 𝑖 + 1 data from layer 𝑖 can instead kept in Cloudstore with storage and bandwidth be verified by layer 𝑖 + 1 (checking block data: does the costs properly accounted for using the Layer 2 tokens, block hash match the block content? is it signed? does it themselves based on Layer 1. Layer 3 and Layer 2 nodes have a parent hash? etc.; checking chunks: does the hash are therefore β€œlight nodes” in that they can quickly catch of the chunk data equal the chunk key), each lower layer up to the latest state by asking the layer 2 and layer 1 blockchains for the most recent finalized block. This [2] Y. Meshcheryakov, A. Melman, O. Evsutin, V. Mo- is not possible to do for the Layer 1 blockchain, how- rozov, Y. Koucheryavy, On performance of ever. However, it is possible, and interesting to adapt a pbft blockchain consensus algorithm for iot- Layer 1 blockchain of Ethereum and make it a Layer 3 applications with constrained devices, IEEE Access blockchain. Computation (Ethereum gas costs) can con- 9 (2021) 80559–80570. sume Layer 2 token balances in state channels along with [3] J. Yoo, Y. Jung, D. Shin, M. Bae, E. Jee, Formal bandwidth, contract storage can use SMTs mapped to modeling and verification of a federated byzantine Cloudstore (instead of Patricia Merkle Tries kept in local agreement algorithm for blockchain platforms, in: store) submitted in blocks to the Layer 2 blockchain, and 2019 IEEE International Workshop on Blockchain the consensus machinery can be put in a modern sharded Oriented Software Engineering (IWBOSE), IEEE, Proof-of-Stake framework to achieve high-throughput 2019, pp. 11–21. low-latency ambitions of Ethereum 2.0, with all layer 3 [4] G. Wood, et al., Ethereum: A secure decentralised nodes. The expectation would be that a Layer 3 Ethereum generalised transaction ledger, https://karl.tech/ blockchain would have massively lower costs due to ra- plasma-cash-simple-spec/, 2014. tional models of storage and bandwidth. Other deep [5] U. Rahardja, A. N. Hidayanto, N. Lutfiani, D. A. blockchain systems can be developed with different com- Febiani, Q. Aini, Immutability of distributed hash putational primitives than the EVM, such as Amazon’s model on blockchain node storage, Sci. J. Informat- Lambda or Apache Hadoop. ics 8 (2021) 137–143. It is believed that there can be many deep blockchain [6] K. Floersch, Plasma cash simple spec, https://karl. systems developed with higher layers resting on many tech/plasma-cash-simple-spec, 2018. Layer 1 blockchains, even to the point where multiple [7] E. Gaetani, L. Aniello, R. Baldoni, F. Lombardi, Layer 1 systems are dropped and many more added to pro- A. Margheri, V. Sassone, Blockchain-based database vide more or less Layer 2 security. The same can be said to ensure data integrity in cloud computing envi- for any layer to benefit higher layers. If the blockchain ronments (2017). at layer 𝑖 changes its consensus algorithm from Quorum [8] J. Poon, V. Buterin, Plasma: Scalable autonomous RAFT to pBFT or Casper Proof-of-Stake, the layer 𝑖 + 1 smart contracts, http://plasma.io/plasma.pdf, 2017. benefits; higher layer blockchains are supervenient on [9] V. TrΓ³n, A. Fischer, D. A. Nagy, Swarm: a decen- Layer 1, so innovations on Layer 1 are inherited by all tralised peer-to-peer network for messaging and deep blockchain systems. It is hoped that many deep storage (2018). Forthcoming. blockchain systems can explore high throughput low la- [10] S. K. Panda, A. A. Elngar, V. E. Balas, M. Kayed, tency scale through some of the design patterns explored Bitcoin and blockchain: history and current appli- here. cations, CRC Press, 2020. [11] B. Laurie, E. Kaspe, Revocation transparency, https: //www.links.org/files/RevocationTransparency. References pdf, 2017. [12] R. Dahlberg, T. Pulls, R. Peeters, Efficient sparse [1] M. Gracy, B. R. Jeyavadhanam, A systematic review merkle trees: Caching strategies and secure (non-) of blockchain-based system: Transaction through- membership proofs, in: Secure IT Systems: 21st put latency and challenges, in: 2021 Interna- Nordic Conference, NordSec 2016, Oulu, Finland, tional Conference on Computational Intelligence November 2-4, 2016. Proceedings 21, Springer, 2016, and Computing Applications (ICCICA), IEEE, 2021, pp. 199–215. pp. 1–6.