Skip to content

Commit 0bd650d

Browse files
authored
Update scalability.md
This commit suggests a reviewed copy for scalability overview. The copy has been adjusted for clarity, conciseness, grammar, and style issues. We also add layer 1 and layer 2 definitions mentioning to refer to the next section for more details.
1 parent 4c0d213 commit 0bd650d

File tree

1 file changed

+25
-60
lines changed

1 file changed

+25
-60
lines changed

docs/core-concepts/scalability.md

Lines changed: 25 additions & 60 deletions
Original file line numberDiff line numberDiff line change
@@ -4,71 +4,36 @@ sidebar_position: 2
44

55
# Scalability
66

7-
Any decentralized system is fundamentally limited in its scalability. This also
8-
applies to blockchains and is rooted in the fact that security is achieved
9-
through massive global replication of transactions. The more decentralized the
10-
system is, the more time and other resources are used up to process
11-
transactions. This is also often called the blockchain trilemma, where
12-
_decentralization_, _security_ and _scalability_ counter-act each other.
13-
14-
Even though Cardano uses a very efficient consensus algorithm, the fact that
15-
it's distributed globally between thousands of block-producing nodes (with quite
16-
a low bar in system requirements) will have it create a block on average every
17-
20 seconds.
18-
19-
These limitations ultimately mean that any state can only change in discrete
20-
steps of this duration. Besides, given peak hours on the blockchain when there
21-
is a transaction queue, the time required to settle and confirm a transaction
22-
might also be higher, further increasing the effective settlement time. This is
23-
because your transaction might not be added to the next block, but the second or
24-
even third one coming.
25-
26-
## Vertical and horizontal scaling
27-
28-
In general, there are two ways of scaling systems: **vertical** and
29-
**horizontal**. Both try to increase resources available to the system to
30-
achieve better overall performance.
31-
32-
For vertical scaling, the performance of the system is increased by adding
33-
resources available to the already existing instances of the system. For
34-
Cardano, this practically means increasing the block size or reducing the block
35-
time. This is a great way to initially scale the system, but is ultimately
36-
limited by network latency and processing power of block-producing nodes. To
37-
ensure the security of the system, each block has roughly 5 seconds to propagate
38-
through the network, which includes relaying and validating it through multiple
39-
hops. At some point, driving the system requirements up will also reduce the
40-
level of decentralization, as less individuals will be able to run such a node.
41-
42-
Scaling a system horizontally, means to increase performance of the overall
43-
system by adding more individual instances alongside each other. Practically,
44-
this could mean that besides the main chain, multiple side chains are spun up
45-
that do the same thing, each "x" seconds all instances create a block. Unlike
46-
vertical scaling, horizontal scaling does not have a direct limit, there can be
47-
many side chains that are connected to the layer one. A major downside to this
48-
way of scaling is that any state of the system is split into multiple pieces.
49-
Each instance is blind to what is happening on the other instances and moving
50-
state between instances results requires additional work (the state is sharded).
7+
Decentralized systems, including blockchains, face fundamental scalability limitations due to their reliance on global transaction replication to ensure security. This constraint is commonly known as the blockchain trilemma, where _decentralization_, _security_, and _scalability_ counteract each other. Although Cardano employs an efficient consensus algorithm, its global distribution among thousands of block-producing nodes results in block creation approximately every twenty seconds. During peak transaction times, this can lead to increased settlement times as transactions may not be included in the immediate next block.
8+
9+
There are two primary approaches to scaling systems: vertical and horizontal scaling.
10+
11+
## Vertical scaling
12+
13+
Vertical scaling enhances system performance by increasing resources available to existing system instances. For Cardano, this could involve increasing block size or reducing block time. However, vertical scaling is limited by network latency and the processing power of block-producing nodes. Each block requires roughly five seconds to propagate through the network, ensuring security through multiple validation steps. Raising system requirements can reduce decentralization, as fewer individuals may be able to run such nodes.
14+
15+
## Horizontal scaling
16+
17+
Horizontal scaling improves overall system performance by adding more instances alongside each other. This might involve creating multiple sidechains that operate in parallel to the main chain, each producing blocks at regular intervals. Unlike vertical scaling, horizontal scaling has no direct limit, allowing many sidechains to connect to the layer 1 blockchain. However, this method fragments the system state, necessitating additional work to transfer state between instances.
5118

5219
![Horizontal & Vertical scaling](./horizontal-vertical-scaling.png)
5320

54-
## State channels
21+
## Layer 1 and layer 2 solutions
22+
23+
Layer 1 solutions aim to improve scalability by adapting the underlying ledger protocols directly. However, they face inherent limitations due to the complexity of the settlement process, which involves extensive data exchange among a large, dynamic set of participants.
5524

56-
The Hydra Head protocol is a form of state channel and can be mostly classified
57-
as a horizontal scaling solution. While multiple instances of them can be
58-
deployed to off-load and increase the scalability of the overall system, it
59-
provides for a flexible way to decide on the level of decentralization of each
60-
instance and provides a mostly frictionless way to transfer state between the
61-
mainchain and the individual Hydra heads (through it _isomorphic_ nature).
25+
Layer 2 solutions, such as state channels, offer an alternative approach by overlaying new protocols on top of the blockchain. These solutions allow parties to securely transfer funds to an off-chain protocol instance, conduct transactions independently of the blockchain, and return the final state to the blockchain when needed. This method does not require additional trust assumptions beyond those of the underlying blockchain and can be highly efficient when all participants behave as expected.
26+
27+
Read more about layer 2 solutions and their types in the next section.
28+
29+
30+
## State channels and the Hydra Head protocol
31+
32+
The Hydra Head protocol is a form of state channel and can be classified as a horizontal scaling solution. Multiple instances can be deployed to offload transactions and enhance the overall scalability of the system. It provides a flexible way to determine the level of decentralization for each instance and offers a mostly frictionless method to transfer state between the main chain and individual Hydra heads due to its isomorphic nature.
6233

6334
![State Channel](./state-channel.png)
6435

65-
State channels allow to take parts of the state from the layer one blockchain
66-
and validate its progress elsewhere between only those parties who are concerned
67-
about this state. Then, after this computation is done, the parties return the
68-
final state on which all parties agree back to layer one. This construction
69-
means that the 20 second block time limit no longer applies and state can be
70-
evolved as fast as only the involved parties approve.
36+
State channels allow parts of the state from the layer 1 blockchain to be validated off-chain by the concerned parties. Once the computation is complete, the parties return the final agreed-upon state to the layer 1 blockchain. This construction eliminates the 20-second block time limit, enabling state evolution as quickly as the involved parties approve.
37+
38+
In conclusion, the Hydra Head protocol enables operators to balance the trade-off between decentralization, security, and scalability differently from the underlying blockchain, thereby meeting the specific needs of individual applications.
7139

72-
In conclusion, Hydra Head will allow operators to strike the fundamental
73-
trade-off between decentralization, security and scalability different than the
74-
underlying blockchain to serve the needs of individual applications.

0 commit comments

Comments
 (0)