Please enable JavaScript.
Coggle requires JavaScript to display documents.
Week 4 Blcokchain Cryptocurrency Scalability (serving massess) - Coggle…
Week 4 Blcokchain Cryptocurrency Scalability (serving massess)
issues
too slow to be a mainstream of currency
scalability for massive adoption
what means for a blockchain to be scalable
in terms of transaction volume and block time
how to deal with increased transaction volume
function with a higher transaction velocity
higher TPS transaction per second
speed to update the blockchain of distributed ledger
block time
the average time it takes a new block or update or append to the blockchain
block size
keep small to let anyone easier to join with a lower storage
In 2018, 180GB
transaction fee, don't forget
flat network topology
anyone can join
what approach to achieve scalability
fundamental system scaling approaches and tradeoffs
vertical scaling
add more cpu ram power to existing machines
horizontal scaling
add more machines of same computational power
diagonal scaling
combine vertical and horizontal scaling
layer 1 scaling
adjust the block size and block speed and hash puzzle
on chain
layer 2 scaling
smart contract on top of the layer 1
off-chain
computational power
alternative consensus
decentralization vs security vs scalability
vertical scaling
simple solution (block size, transaction size, block rate)
layer 1 scaling solution
propose to reduce the difficulty of PoW
lower hash puzzle difficulty
decrease block time
potential issues
same block height forks
natural forking
grand-uncle
uncle
more blocks become orphaned because more solutions found at the same time
may need to wait for 12 confirmations, rather than 6
may not reach a good probabilistic finality
selfish miner to withhold blocks and publish it later
double spend
constant block size?
avoid wasted computational effort on orphaned blocks
count the most weight rather than just longest chain
Ethereum's Proof-of-Work protocol
GHOST
greedy heaviest observed sub-tree protocol
uncles up to 7 generations deep would get rewarded as well
87.5% reward to uncle blocks
12.5% reward to nephew blocks
for calculating chain weight
but decrease incentives to pools of mining
reduce the competition to be the first block on top of the longest chain
more confirmation required, 40
about 15 second of average block time
block propagation time vs block creation time
on average, Bitcoin blockchain is growing by 5GB by 2 years
increase block size
theoretically, larger block size could fit more transactions in a block
merits
lower transaction fee to users
need miners to agree
implementation issues
hard fork
new blocks of larger size may not be compatible with the old clients
may cause the split of community
lessen transaction fee may not be liked by miners
disadvantages
longer propagation time
longer travel time across networks due to larger data size
efficiency increases linearly only
larger block, take longer to validate
when to end the block size increasing?
reduce transaction size
more transaction in the block of same size
two methods
Segwit = Segregrated Witness
originally solve for malleability
segregate the digital signature from within each transaction
digital signature originally kept in SciptPubKeys
which is used by the recipient of previous transactions to prove he/she is authorized to spend the output of previous transactions
digital signature takes up so much space in each transaction
should be of no use after verification
on average, transaction is about 546 bytes
new nodes by SegWit P2W"
ScriptPubKey: .....
ScriptSig: Empty
WitScript: Signature1
Result: Valid
old nodes by SegWit P2W"
ScriptPubKey: ..... (same as above)
ScriptSig: Empty
Result: Valid
don't know where to look for the ScriptSig
a mirrored merkle tree
one half transactions
one half the transactions' segregated witnesses
maintain tempering
before segwit
transaction ID equals to hash of a transaction that included signatures
hackers may have different ways to change the signature
pros
allows side chain to work
allows soft fork, not hard fork
no slippery slope
one time fix
smaller blockchain size for the same numbers of transactions
efficiency gain
allows Lightning network
cons
one time linear capacity increase
500 lines of code to be somewhat ugly and complicated
wallet have to incorporate with the segwit
segwit is not the only way to fix malleability
recursive SNARKs
concept of zero knowledge proofs
a way to prove someone that you know something but without revealing what exactly you know
similarly, a website store the hash of users' paswords
zk-SNARKS =
ZERO knowledge succinct non-interactive arguments of knowledge
a miner can merely include a single proof that they validated all other proofs and changes to the state of the network and everyone's balances
the components of a block
root hash of the content of the ledger
proofs for all valid transactions that have changed the ledger to the current state
proof that previous block's proof was valid
advantages
allows twice numbers of transactions per block
546 --> 288 bytes
drawbacks
take hours to output the proof;
very time consuming
requires trusted setup between computers
trusted execution environment
violate the trust assumptions particularly in public blockchain
comparisons
shortcomings
strengths
current scaling project
research focus
vertical scaling by off chain
mediator or arbitor
a summary or net result of all off chain transactions
Bitcoin
6 confirmations take 1 hr
transaction fee varies
37 dollars per transaction in 2018
not economical for low value items
a single transaction fee for a month's aggregated transactions
private payment channel between two persons
private payment balance sheet
payment channel
hash timelock contract HTLC
schedule an action (e.g. refunding a transaction) in the future
bi-directional payment channel
pay each other with the guarantees of a contract
off chain instant payment
horizontal scaling
vertical scaling is to increase the performance of individual nodes
modifying protocols
distribute work among nodes
each node does a subset of work
sharding and side chains
diagonal scaling
sharding
partitioning / distributing the data so each node may not have same copy of data
so the state of the database is equal to the union of all data across all the nodes
store the data of west coast users to west coast datacenter
whereas those of east coast users to east coast datacenter
or data of users of id < 500 stores in the upper shards; the others >= 500 in the lower shards
each full node stores all of the state data and processes all transactions
each subset of validators or miners working for its own subset of transactions
increase throughput
a type of parallelism
increasing effective numbers of machines on each portion of the blockchain
distribute data based on an arbitrary key
the system is secure as long as enough validators or miners
on chain or layer 1 scaling solution
Ethereum research
what each node in the network sees
now several levels of nodes that can exist in a system using a sharded blockchain
nodes in 4 categories
sup[er full nodes
store data from all chains
top-level nodes
process all main chain or top-level blocks
light client access to all shards
single shard nodes
store only info from a single shard
light nodes of average users
downloading and verifying block headers of the main chain
challenges or issues
how we can share info correctly and succinctly between shards
how we can maintain correct operation if a single shard has been taken over
side chains
fast and less secure blockchain for small transactions
shortages
suffer from security side as hashing power would be spread over multiple chain
peg
pegged to main chain
the intersection of each of these side chains
pegged blockchains could potentially perform any function
advantages
enable features
smart contracts
micropayments
real-world property registries
key
transfer data reliably between different chains
transfer assets at a deterministic and consistent rate
maintain a stable exchange rate
moving funds between chains
diagonal scaling
Ethereum
main or root chain
Plasma is of side chains attached to main chain
main source of truth within the system
acts as an arbiter
user interactions
deposit ETH into a rootchain smart contract
shown as an unspent transaction output on the sidechain
send transactions around within the Plasma or child chain
at any time, the user could attemp to exit UTXO on the Plasma chain child back to the root chain
the validity of the exit will be verified
double spent?
Vitalik Buterin
Plasma plus sharding complimentary
layer 2 and layer 1 scaling solutions
scale Ethereum transaction speed up by 10k times
Fourth State team
interoperability in Plasma implementation
chose to build their child chain implementation on Cosmos
Plasma a diagonal scaling solution
scale up the number of Ethereum transactions
bring transactions off the main chain onto child chains
extend Ethereum functionality
Plasma thought as of modularity
a component of the larger scalability ecosystem
implement Plasma on Cosmos
open up the door for interoperability
3 main abstraction layers of blockchains
application layer
processing transaction and updates
the state of the system
defines the distributed application you are building
e.g. peer to peer electronic cash
general smart contract computation
consensus layer
ensure transactions and updates agreed by the entire network
network layer
for propagating transactions through the network
make sure all nodes are getting updates within reasonable time
Tendermint
fully modular blockchain middleware
providing networking and consensus layers
so, any applications can be built on top of Tendermint with ABCI
or application blockchain interface
flexible
allows thousands of transactions
100+ validators
Cosmos network
diagonally scaled
vertical scaling
by the speed of Tendermint BFT consensus
horizontal scaling
by the interoperability of Cosmos network
hubs
running Tendermint or data transform layer
connecting multiple zones together
zones
running Tendermint or data transform layer