2018
DOI: 10.48550/arxiv.1803.09029
|View full text |Cite
Preprint
|
Sign up to set email alerts
|

Blockclique: scaling blockchains through transaction sharding in a multithreaded block graph

Abstract: Decentralized crypto-currencies based on the blockchain architecture under-utilize available network bandwidth, making them unable to scale to thousands of transactions per second. We define the Blockclique architecture, that addresses this limitation by sharding transactions in a block graph with a fixed number of threads. The architecture allows the creation of intrinsically compatible blocks in parallel, where each block references one previous block of each thread. The consistency of the Blockclique protoc… Show more

Help me understand this report

Search citation statements

Order By: Relevance

Paper Sections

Select...
2
2
1

Citation Types

0
7
0

Year Published

2018
2018
2024
2024

Publication Types

Select...
3
3
1

Relationship

0
7

Authors

Journals

citations
Cited by 7 publications
(7 citation statements)
references
References 17 publications
(21 reference statements)
0
7
0
Order By: Relevance
“…A more recent work shows that this approach, which has been designed to avoid sharding, may work well even paired with it. This model, called blockclique [8], prescribes a division of nodes into "threads", which work in parallel, producing blocks that are organized in a DAG. This graph has to respect two internal rules: the blocks produced by a single thread constitute a proper blockchain ("thread incompatibility") and new blocks take into accounts blocks recently produced by other threads ("grandpa incompatibility") by referring to their parent's hashes.…”
Section: Blockcliquementioning
confidence: 99%
“…A more recent work shows that this approach, which has been designed to avoid sharding, may work well even paired with it. This model, called blockclique [8], prescribes a division of nodes into "threads", which work in parallel, producing blocks that are organized in a DAG. This graph has to respect two internal rules: the blocks produced by a single thread constitute a proper blockchain ("thread incompatibility") and new blocks take into accounts blocks recently produced by other threads ("grandpa incompatibility") by referring to their parent's hashes.…”
Section: Blockcliquementioning
confidence: 99%
“…For keeping only partial order, we can use a DAG (directed acyclic graph). For example, each of [17,13,18,8,3] uses some sort of a DAG (implicitly or explicitly).…”
Section: Related Workmentioning
confidence: 99%
“…A simple solution is that transactions of the same "type", that might be conflicting, are allowed to be introduced only at a specific location in the graph, so they cannot appear concurrently at different locations. E.g., if our graph is indeed a set of parallel blockchains, then we can divide the transactions according to their source accounts, such that transactions of a specific account are allowed to appear only in blocks of a specific blockchain [13,8,6,9].…”
Section: Related Workmentioning
confidence: 99%
“…Because of this sequential block production, the throughput of sequential blockchains is limited by the block propagation times. In order to solve this scalability issue, many projects such as [YNHS20] or [FVLF18] have adopted a parallel architecture. The idea is to have several parallel instances of a sequential blockchain and a reconciliation mechanism that guarantees consistency among the parallel chains.…”
Section: Introductionmentioning
confidence: 99%