=Paper=
{{Paper
|id=Vol-3676/BISEC_paper_5
|storemode=property
|title=Deep Blockchain to Enable ScalableWeb Applications
|pdfUrl=https://ceur-ws.org/Vol-3676/article_05.pdf
|volume=Vol-3676
|authors=Yajna Pandith
|dblpUrl=https://dblp.org/rec/conf/bisec/Pandith23
}}
==Deep Blockchain to Enable ScalableWeb Applications==
https://ceur-ws.org/Vol-3676/article_05.pdf
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.