Blockchain Scalability - Themes, Tools and Techniques

B L O C K C H A I N S C A L A B I L I T Y
A L G O R I T H M S A N D A R C H I T E C T U R E S

W H AT I S T H E S C A L A B I L I T Y
C H A L L E N G E I N B L O C K C H A I N ?

– V I TA L I K B U T E R I N
“Currently, all blockchain consensus protocols that are actively in use
have an important limitation: every fully participating node in the
network must process every transaction. ”

I N T E R P R E TAT I O N S
• This gives the blockchain a
high amount of security
because of how much
validation goes into each block
• At the same time it means that
an entire blockchain is only as
fast as its individual nodes and
not the sum of their parts.

B L O C K C H A I N
T R I L E M M A
• A Blockchain can have at most two of
these three properties :
• Decentralisation
• Scalability
• Security

B L O C K C H A I N T R I L E M M A : I M P L I C AT I O N S

B L O C K C H A I N S C A L A B I L I T Y R O A D M A P

B L O C K C H A I N S C A L A B I L I T Y A R C H I T E C T U R E S

E T H E R E U M E C O S Y S T E M

E T H E R E U M S TAT E M A C H I N E

E T H E R E U M B L O C K S T R U C T U R E

H Y P E R L E D G E R FA B R I C A R C H I T E C T U R E

H Y P E R L E D G E R S A W T O O T H C O M P O N E N T S

H Y P E R L E D G E R S A W T O O T H A R C H I T E C T U R E

H Y P E R L E D G E R S A W T O O T H C O N S E N S U S

H Y P E R L E D G E R S A W T O O T H A P P M O D E L

H Y P E R L E D G E R I R O H A A R C H I T E C T U R E

C O R D A A P P L I C AT I O N A R C H I T E C T U R E

C O R D A R E F E R E N C E A R C H I T E C T U R E

D E C E N T R A L I S AT I O N , T R A N S PA R E N C Y A N D
S C A L A B I L I T Y H A S B E C O M E M E A S U R E S O F VA L U E

H O W D O Y O U M E A S U R E
T H E P E R F O R M A N C E O F
D I S T R I B U T E D S Y S T E M S ?

S P E E D U P, E F F I C I E N C Y & S C A L A B I L I T Y

S P E E D U P, E F F I C I E N C Y
A N D S C A L A B I L I T Y
• Speedup measures how the
rate of doing work increases
with the number of processors
• Efficiency E measures the work
rate per processor
• Scalability ψ(k1,k2) from one
scale k1 to another scale k2 is the
ratio of the efficiency figures

U N D E R S TA N D I N G S C A L A B I L I T Y
T H E N U M B E R O F T R A N S A C T I O N S P E R U N I T Y T I M E T H AT T H E S Y S T E M C A N P R O C E S S

– K E N N E T H B I R M A N
“The ability of a system to continue operate correctly even as some
aspect is scaled to a larger size. Scalability has many dimensions; a
scalable system would normally specify the dimensions in which it
achieves scalability and the degree of scaling it can sustain”

S C A L E C U B E F R O M A R T O F S C A L A B I L I T Y

S C A L E C U B E A N D T H E C O N T O U R S O F S C A L A B I L I T Y

P E R F O R M A N C E C O N S I D E R AT I O N S F R O M S C A L E
C U B E

S C A L E C U B E A N D T H E S E R V I C E D E S I G N
P E R S P E C T I V E

C H A L L E N G E S F O R A
S C A L A B L E B L O C K C H A I N
• High Throughput
• Fast confirmation times

D E C E N T R A L I S E D S C A L I N G
C O S T & C O N S T R A I N T S
• It should be noted that scaling
does not imply a decrease in
the latency of transactions.
• Indeed, improvements to
scaling may sometimes come
at the cost of increased
latency.

S T R AT E G I C A P P R O A C H
T O S C A L A B I L I T Y A C R O S S
C O N S E N S U S
• Systems that achieve greater
scalability with different consensus
mechanisms do so almost universally
by reducing the size of the set of
block producers.
• If the root cause of the scalability
problem is that every transaction
must be validated by every node,
one way forward is to simply reduce
the number of nodes on the network

U N D E R S TA N D I N G
D E C E N T R A L I S AT I O N
• A system is decentralised if
and only if it is:
• Distributed
• Trustless
• Permissionless

B L O C K C H A I N
S C A L A B I L I T Y
• Size of transactions
• Size of a block
• How many transactions in a block
• How often blocks get added to the
chain
• How nodes collaborate in the chain
• How nodes add transactions to the
chain

B L O C K C H A I N S C A L E I N
C O M PA R I S O N W I T H V I S A
B I T C O I N - 9 0 , 0 0 0 T R A N S A C T I O N S / D AY
V I S A - 1 5 0 M I L L I O N T R A N S A C T I O N S / D AY

B L O C K C H A I N
A R C H I T E C T U R E
C O N S T R A I N T S
• In a Blockchain, every fully participating
node in a network must process every
transaction
• Every blockchain protocol that works in
this way is forced to choose between
either limiting itself to a low maximum
transaction throughput, with a resulting
high per-transaction cost, or allowing a
high degree of centralisation.

U N D E R S TA N D I N G
C O N S T R A I N T S
• Physical resource constraints and
software constraints
• Data communication is limited by the
speed of light, bandwidth transmission
limits, CPU processing capacity,
network consistency, network
availability, network partition tolerance
• Network latency is at the very base of
the constraints. It measures how long
it takes for data to travel

B L O C K S I Z E
C O M P U TAT I O N I N
B I T C O I N N E T W O R K
• At this theoretical rate of transactions that
means the nodes in the network must be
able to process 500 bytes x 2,000 tps = 1
MB amount of transactions per second.
• Processing a transaction involves hashing
and ECDSA signature verifications.
RIPEMD-160 and SHA256 (both hash
algorithms) run at about 100 megabytes
per second, so 2,000 transactions could be
processed in about 10 milliseconds, so fast
enough that we don’t need to worry about
it.

B L O C K G A S L I M I T
C O M P U TAT I O N I N
E T H E R E U M
• Ethereum is a little different in that it doesn’t have
a traditional block size but a per block gas limit.
• Gas is the payment unit used to pay for the
computations required to process the transaction.
• This is a consistently reevaluated value based on
the current processing, storage and bandwidth
conditions of the network.
• This is important because not every transaction is
just used for transferring an asset but may be
used to signal a contract or carry data to it which
requires the network to do some level of extra
computation.

C H A L L E N G E S O F
I N C R E A S I N G B L O C K C H A I N
T R A N S A C T I O N R AT E
• If the rate of transactions increases by
way of block size increase or block
generation rate, the blockchain would
grow at a corresponding rate.
• Currently, the Bitcoin blockchain grows
at a max rate of about 1 GB a week
(max rate of about 4 GB for SegWit
enabled Bitcoin). If the block size is
doubled, that rate would be 2 GB a
week, tripled it would be 3 GB a week
and so on.

C O M M O N A P P R O A C H E S
F O R B L O C K C H A I N
• Off chain computations
• Side Chains
• State Channels
• Sharding Protocols
• Simple Payment Vehicles
• New Consensus Protocols
• Reducing the Block size

L AY E R 1 - L AY E R 2
S C A L I N G A P P R O A C H E S
• The class of proposals to properly scale
decentralised blockchains currently
revolve around not having each node
in the network validate every
transaction.
• This is accomplished by either sharding
the base blockchain (so-called layer-1
scaling) or having separate chains
running alongside the base chain that
only a subset of users need to fully
validate (so-called layer-2 scaling).

M E A S U R E S
• Maximum throughput - maximum rate at
which the blockchain can confirm
transactions
• Latency - time for a transaction to be
confirmed. The transactions are confirmed
once they are included in a block, which is
roughly 10 minutes for bitcoin.
• Bootstrap time - The time it takes for a
new computer node to download the
history necessary to validate a new
transaction

S C A L A B I L I T Y -
H A R D T R U T H S
• In all blockchain protocols, each node
stores all states with account balances,
contract code, and entire transaction
history, in order to verify a transaction’s
validity for each transaction in the
network without a trusted third party.
• This provides a large amount of
security but limits scalability to not
being able to process more
transactions than any single node in
the network can.

D I M E N S I O N S
• Node Identity Management
• Consensus Finality
• Node Scalability
• Client Scalability
• Performance throughput
• Performance latency
• Power consumption
• Tolerated power of an adversary
• Network synchrony
• Correctness proofs

N O D E I D E N T I T Y
M A N A G E M E N T
• How nodes are identified in a consensus
protocol in a network through a unique
identifier
• In a proof of work based network, anyone
can participate and contribute to the system
• In a BFT consensus, every participating
node need to identify to participate in the
transactions
• This results in a centralised identity
management requirement in a BFT protocol
implementation

C O N S E N S U S
F I N A L I T Y
• Consensus Finality is the property that ensures
that a valid block added to the blockchain is
not removed
• PoW violates this property when two nodes
append a block to the same block which result
in a fork
• In the case of Bitcoin the forks are handled by
the longest chain rule, thus breaking the
consensus finality by removing the shorter
chain or the GHOST rule
• BFT satisfies consensus finality with immediate
confirmation

C L I E N T
• When it comes to scalability
with the number of clients,
both PoW and BFT support
thousands of clients all
connected at once with good
concurrency and parallelism

N O D E S C A L A B I L I T Y
• Scalability in Proof of Work
• Scalability in BFT
• Scalability in DAG
• Scalability in PoS
• Scalability in DPoS
• Scalability in DPoW

I S S U E S I N P O W
• PoW scalability is reliant on the block
size and the rate of the block
creations
• If the block size is increased,
potential trees are created in the
blockchain leading to double spend
attacks

I S S U E S I N P O S
• Constrained Resources of nodes that
are selected for transaction
verification and block proposing
( Computation, Bandwidth, Memory )
• Limitations of underlying P2P
networks which results in high
information propagaten latency due
to dynamic network topologies and
huge blocks with a large number of
transactions

E A R LY P R O P O S A L S F O R
B I T C O I N S C A L A B I L I T Y
• Removing old transactions from Blockchain and a
database is used to hold the non-empty address
trees
• In this way, nodes that are validating the
transactions do not have to store the previous
transactions that are not relevant to them
• Bitcoin Next Generation is another proposal where
the blocks are decoupled and there are leader
blocks and micro blocks that handle transactions
• Miners would complete for the leader block, these
would be the ones in charge of generation of new
micro blocks

D O U B L E S P E N D AT TA C K S
O N B L O C K C H A I N L E D G E R
• Double spend attacks is a method to
override the main chain to reverse
transactions
• The attacker pays a person and in secrecy
builds a chain of blocks where the
payment is not included.
• By releasing the chain the attacker can
cause a replacement in the ledger where
the payments are erased or redirects the
payment to somewhere else

D O U B L E S P E N D AT TA C K
O N B I T C O I N N E T W O R K
• This requires a lot of computational power which
makes the attack unlikely since the honest nodes
have a lot of computational power, however there
was a case of a mining pool in Bitcoin having over
40% of the total computational power.
• If the attacker has a lot of computational power there
is a possibility that the attacker can generate blocks
that could replace the honest longest chain and that
enables the attacker to replace the main chain at will.
• When the attacker has more computational power
than the honest nodes, it is called the 51% attack
(also known as the majority attack)

D O U B L E S P E N D AT TA C K
A N D B I T C O I N
S C A L A B I L I T Y A S P E C T S
• The Bitcoin protocol becomes more
susceptible to double-spend attacks
when it scales upwards and tries to
meet the demand.
• If we assume that the attacker creates
blocks at a rate that is faster than the
rate of the honest main chain, the
attacker will always be successful with
these types of attacks regardless of the
length of the chain it aims to replace .

S TAT E C H A N N E L S C A L A B I L I T Y M O D E L

S TAT E C H A N N E L S
A P P R O A C H T O
• State channels are the general
form of payment channels,
applying the same idea to any
kind of state-altering operation
normally performed on a
blockchain.

P R O M I N E N T S TAT E
C H A N N E L
I M P L E M E N TAT I O N S
• Lightning Network
• Raiden Network
• Trinity
• Spankchain
• Perun
• Counterfactual
• Celer Network
• Machinomy
• Fun Fair
• Liquidity
• Connext Network

L I G H T N I N G N E T W O R K S I M P L I F I E D

B I T C O I N S C A L A B I L I T Y &
L I G H T N I N G N E T W O R K
• The Lightning Network is
supported by numerous smart
contracts put together in a
system built on the topmost
tier of the Bitcoin Blockchain.
• The protocol allows very fast
transactions speeds that are
accompanied by very low
transitioning fees.

B U I L D I N G B L O C K S O F
L I G H T N I N G N E T W O R K
• Unconfirmed Transactions
• Double Spend Protection
• Multi signature Addresses
• Time Locks
• Hash values and Secrets

L I G H T N I N G
N E T W O R K L I F E C Y C L E
• Set up a wallet with a multi-signature feature with some amount in
BTC. Upload the Wallet’s address into the public Bitcoin
Blockchain.
• This is accompanied by a smart contract that clearly states what
amount of BTC belongs to whom.
• Once the pay channel is instantiated, it opens up an avenue for the
parties therein to undertake unlimited transactions amongst
themselves.
• The information in the wallet set is not updated onto the main
Blockchain. The transactions occur off-chain.
• Upon completion of every transaction, a balance is signed up by
both parties, and this is reflected on the balance sheet.
• At any given time, the multi-signature wallet will show the balances
owed to each party.
• In case of a dispute or should the payment channel be locked, the
contractual obligations terminate there and the involved parties
pay each other as per the balances reflected as a share in the Multi-
signature wallet.

U N C O N F I R M E D
T R A N S A C T I O N S
• The Lightning Network is built up
from more or less regular Bitcoin
transactions.
• These transactions are typically not
actually broadcast over the Bitcoin
network.
• Instead, they are stored locally, on the
nodes of users - but they can be
broadcast over the network at any
time.

D O U B L E S P E N D
P R O T E C T I O N
• If two transactions (or: inputs)
rely on the same output, only
one can confirm.
• Even unconfirmed transactions
can be conflicting, meaning
only one can ever confirm.

M U LT I S I G ( P 2 S H )
A D D R E S S E S
• Multisig addresses are Bitcoin
addresses that require multiple
private keys to “unlock” and spend
bitcoins from.
• The Lightning Network often uses
two out of two (2-of-2) multisig set-
ups. Unlocking bitcoins from 2-of-2
multisig addresses requires two
signatures, from two dedicated
keys.

T I M E L O C K S
• Time-locks can “lock bitcoins up” in an output, to
make them spendable (to be included in a
subsequent input) only at some point in the future.
• There are two different types of time-locks: the
absolute type, called CheckLockTimeVerify (CLTV),
and the relative type, CheckSequenceVerify (CSV).
• CLTV locks bitcoins up until a (more or less)
concrete time in the future: an actual time and
date, or a specific block height. CSV, instead, uses
relative time.
• Once a CVS-output is recorded on the blockchain,
it takes a specific amount of blocks from that point
on before the bitcoins can be spent again.

H A S H VA L U E S A N D
S E C R E T S
• In a bitcoin transactions, a
hash can be included in an
output, and require the
subsequent input to include
the corresponding value in
order to be spendable.

L I G H T N I N G N E T W O R K - S E C U R I T Y A N D S C A L E

L I G H T I N G N E T W O R K - T R A N S A C T I O N M O D E L

S I D E C H A I N
A P P R O A C H
• A sidechain is a separate
blockchain that is attached to
its parent blockchain using a
two-way peg.
• In other words, you can move
assets to the sidechain and
then back to the parent chain.

S I D E C H A I N S C A L A B I L I T Y M O D E L

S I D E C H A I N
I M P L E M E N TAT I O N S
• Ethereum Plasma
• Rootstock
• Alpha
• Liquid
• Loom
• POA Network
• Bitcoin Extended
• Hivemind
• MimbleWimble
• Elements Project
• Bitcoin Codex

E T H E R E U M P L A S M A A P P R O A C H
T O B L O C K C H A I N S C A L A B I L I T Y
Plasma is a series of contracts that run on top of a root chain (Ethereum main chain) and consists of a network of
“child chains” connected to a root chain in a hierarchical, tree-like structure.

P L A S M A L I F E C Y C L E
• Initially, smart-contracts are created on the Ethereum
main-chain. These smart contracts serve as the “root”
of the Plasma child-chain.
• This main chain entry contains the basic rules of the
child-chain, records state hashes of the child-chain,
and allows users to move assets between the
Ethereum main-chain and the child-chain.
• After rooting the child-chain in the main chain, a
child-chain is created. This child-chain features its
own consensus algorithm, independently from the
Ethereum main-chain.
• Once the child-chain is up and running, the block
creators periodically commit a validation to the main-
chain, essentially proofing that the current state of
the child-chain is valid according to the consensus
rules.

P L A S M A
C O N S E N S U S
• The consensus mechanism for this proof of stake system, is
again, enforced in an on- blockchain smart contract.
• Instead of enforcement of an incrementing nonce state (via
revocations), a system of fraud proofs is enforced for balances
and state transitions of these chain hierarchies.
• In effect, we are able to create state transitions which are only
periodically committed to parent chains (which then flows to the
root blockchain).
• Constructs computation in a MapReduce format to more easily
design computation and state transitions in a hierarchical tree.
• This creates economically enforceable computation at scale,
with only one block header/hash committed on the root chain to
encompass very high amount of data and work.
• It is only if a block is faulty that proof of invalidity is published,
otherwise extremely minimal amounts of data is submitted on
the root chain periodically.

P L A S M A C O N T R A C T I N T E R A C T I O N S

P L A S M A C O N S E N S U S I N T E R A C T I O N S

P L A S M A T R A N S A C T I O N D Y N A M I C S

E T H E R E U M S H A R D I N G A P P R O A C H
T O B L O C K C H A I N S C A L A B I L I T Y

E T H E R E U M S H A R D I N G M O D E L

S H A R D I N G D ATA
S T R U C T U R E
Sharding is often referred to as a Layer 1 scaling solution because it
is implemented at the base-level protocol of ethereum itself..
Ethereum breaks down the network into specific shards.
Each shard is assigned a specific group of transactions that is
determined by grouping specific accounts (including smart
contracts) into a shard. Each transaction group has the following
structure.
• Header
• The shard ID of the transaction group
• Assignment of validators through random sampling
• State Root (state of the merkle root of the shard before
and after transactions)
• Body
• All of the transactions that belong to the transaction
group that are part of the specific shard.

S H A R D I N G A N D
T R A N S A C T I O N S
• Transactions are specific to each shard and occur between
accounts native to that shard.
• When transactions are verified, the state of the network changes
and account balances, storage, etc are updated.
• In order for the transaction group to verify as valid, the pre-state
root of the transaction group must match the shard root in the
global state.
• If they match, the transaction group is validated and the global
state is updated through the particular shard ID state root.
• Instead of only containing a state root, each block of the
Ethereum blockchain now contains both a state root and the
transaction group root.
• Basically, there is a merkle root of all of the different shards that
contain the updated and verified transaction groups. This root is
stored in the blockchain along with the updated state root.

C R O S S S H A R D
C O M M U N I C AT I O N
• The cross-shard communication is achieved through
applying the concept of transaction receipts.
• The receipt for a transaction is stored in a merkle root
that can be easily verified but that is not part of the
state root.
• The shard receiving a transaction from another shard
checks the merkle root to ensure that the receipt has
not been spent.
• Essentially, the receipts are stored in a shared memory
that can be verified by other shards, but not altered.
• Therefore, through a distributed storage of receipts,
shards are able to communicate with each other.

S H A R D I N G A N D 1 %
AT TA C K
• A major problem is the idea of a Single-Shard
Takeover Attack, where an attacker takes over
the majority of collators in a single shard to create
a malicious shard that can submit invalid
collations.
• In a 100 shard system, it takes only 1% of network
hash rate to dominate the shard
• As a solution, random sampling of validators in
each shard is recommended
• Every shard will get assigned a bunch of
validators and the ones that will actually be
validating will be randomly sampled from that set.

S H A R D I N G A N D VA L I D AT O R M A N A G E R C O N T R A C T

I F T H E B L O C K C H A I N S C A L A B I L I T Y D E M A N D S L A R G E R
C O M P U TAT I O N A L M A C H I N E S , I T W I L L R E S U LT I N
C E N T R A L I S AT I O N O F N E T W O R K A M O N G T H E M A C H I N E S
W I T H B E T T E R C O M P U TAT I O N P O W E R A N D C A PA C I T Y

D E T E R M I N A N T S O F
B L O C K C H A I N
T H R O U G H P U T
• The throughput of the blockchain can be
affected by two elements, the size of the
block and the block creation rate.
• The difficulty of the computational problem
to create a valid block can also be lowered
so that the creation of blocks is accelerated.
• Increasing the block size or increasing the
rate of creation of blocks influence the
blockchain in a negative way by introducing
more forks which in turn reduces the
security threshold of the blockchain.

B L O C K S I Z E
I N C R E M E N TAT I O N A N D
• BIP 100 is about changing the 1 MB
block size to a new floating block size
which is determined by the
consensus mechanism of the miners.
• Another suggestion is to increase the
block size by 4.4% each 97 days until
the year 2063 which is a 17.7%
increase per year.

S E G R E G AT E D
W I T N E S S
• SegWit is a protocol to increase the block capacity
and to provide protection from transaction
malleability
• Segregated witness approach does not increase the
block size limit, but it increases the amount of
transactions that can be stored in a block. This
approach in the best case scenario increases the
throughput by four times.
• The segregated witness approach resolves the
transaction malleability problem and thus allows new
mechanisms to be implemented which could provide
powerful tools for the scalability issues in blockchain
implementations

T H E G R E E D Y H E AV I E S T
O B S E R V E D S U B T R E E
• The basic concept behind the protocol is that
blocks that are off the main chain can still
contribute to its weight
• It offers performance benefits over the
standard longest chain protocol as is
implemented in Bitcoin
• This allows the network to set higher rates for
block creation and increase the block size
without worrying about the 51% attacks
which means a higher transaction throughput
can occur within the network

W H AT H A P P E N S I F Y O U
S P L I T T H E D ATA I N T O
S U B C H A I N S
• It has the two fundamental problems
• it decreases security, to the point where the
security of each individual blockchain on
average does not grow at all as total usage of
the ecosystem increases,
• It massively reduces the potential for
interoperability, as applications no longer have
the ability to talk to each other with zero latency
and total security over a single ledger
• Alternatively we can use cumbersome ”atomic
cross-chain” interaction protocols

M E R G E M I N I N G
• Proof of work miners mining multiple
chains simultaneously which could best
offer a linear trade off between a
thousand chains and a single chain
extreme
• If each chain is mined by only one in a
thousand miners, then it is vulnerable to
very cheap attacks
• If each chain is mined by every miner
then the consensus participant must
process every transaction anyway

C H E C K P O I N T I N G
• Techniques involving
“checkpointing” a smaller
blockchain inside a larger one also
fail to provide security, as they do
not prevent an attacker with
majority participation in the smaller
blockchain’s consensus process
from creating a checkpoint of fake
or unavailable data.

S C A L A B I L I T Y A N D
I M P L I C I T VA L I D AT I O N
P R O C E S S E S
• The problem of simultaneously
achieving the best of both
worlds: having only a small
portion of consensus participants
explicitly participate in validating
each transaction, but have the
entire weight of the network
implicitly stand behind each one,
has proven surprisingly hard.

L I G H T C L I E N T S A N D T H E
L I K E L I H O O D O F
S C A L A B L E VA L I D AT I O N S
• Nodes must necessarily employ
statistical and economic means in
order to make sure that other blocks
are secure
• In essence, every node can only fully
keep track of at most a few parts of the
entire “state”, and must therefore be a
“light client”, downloading only a small
amount of header data and not
performing full verification checks,

D ATA AVA I L A B I L I T Y I S S U E S
A N D I M PA C T O N
• It is entirely possible for a block
to appear that looks valid, and
is valid, but for which the
auxiliary data is unavailable,
leading to a situation where no
other validator can effectively
validate transactions or produce
new blocks since the necessary
data is unavailable to them.

PA R A L L E L P R O C E S S I N G
A N D S TAT E T R A N S I T I O N
F U N C T I O N S
• When transactions are processed
by different nodes in parallel, it is
not possible to parallelise
arbitrary computation quite easily
• We must determine the set of
restrictions to a state transition
function that will best balance
parallelisability and utility.

B L O C K C H A I N S C A L A B I L I T Y :
N E E D F O R C O N V E R G E N C E !

Blockchain Scalability - Themes, Tools and Techniques

Blockchain Scalability - Themes, Tools and Techniques

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Blockchain Scalability - Themes, Tools and Techniques

Semelhante a Blockchain Scalability - Themes, Tools and Techniques (20)

Mais de Gokul Alex

Mais de Gokul Alex (20)

Último

Último (20)

Blockchain Scalability - Themes, Tools and Techniques