Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Scalability #2

Open
branaway opened this issue Feb 3, 2018 · 0 comments
Open

Scalability #2

branaway opened this issue Feb 3, 2018 · 0 comments

Comments

@branaway
Copy link
Member

branaway commented Feb 3, 2018

Almost all the blockchains are suffering from long confirmation and high-flying fees, the others are lying.

As the CAP theorem puts it:

It is impossible for a distributed data store to simultaneously provide more than two out of the following three guarantees: Consistency, Availability and Partition tolerance.

Blockchain architecture must maneuver within the constraint of distributed computing.

Ethereum as of Metropolis (v. Byzantium) (and Bitcoin for the matter) is exemplary of POW consensus mechanism which is borne of bad performance, because:

  1. Mining is a competition and necessarily a waste of huge resources for the interests of security. All the transactions and the backing smart contracts must be replayed on all the nodes to ether build the blocks or to verify the transactions in the blocks. The way that the world state is replicated in all the nodes is to do the computation on all of the nodes. This way of information distribution is unheard of in the traditional centralized or permissioned environment, which offers hundreds of times of better performance.
  2. Data is the blockchain is arranged in a linear way and often mixed with each other. There is no proper partition of different tokens on the chain. Therefore it's very hard to index the transactions for faster access.
  3. All the transactions are processed in a serialized way. The current protocol does not allow parallel processing of the transactions, because there is no way that the nodes knows what accounts are affected by each transactions. This is also the unpleasant result of lacking token-based transaction partitioning and lacking of knowledge of account dependencies in finer detail.

POS (Proof of Stake) has been invented to solve the "All transactions must be processed by all" problem, possibly at the cost of higher risk of security breach. There are three major implementations of POS, each with different goals and maturity. Tendermint and its descendant Ethermint emphasize on finality while Casper the Friendly Finality Gadget and Casper the Friendly Ghost favor data availability over consistence, although consistence will be eventually reached. Terdermint has the limitation of 100 validators. POS uses sophisticated incentives and penalizing mechanism to ensure fault proof and Byzantines are eventually excluded from the network of nodes, at a fractional cost of POW. Tendermint claims 1000-2000 TPS while Casper would probably increase the Ethereum network throughput by 10X. Large scale of POS deployments will take place in late 2008.

Plasma, proposed by Joseph Poon and Vitalik Buterin. has high promise to create a massively scalable blockchain based computation network, aiming at billions of TPS. The idea is to apply Map-Reduce methodology to the blockchain transaction processing. The entire pool of computing power is organized in a hierarchical structure where duplicated computing is minimized and security is ensured recursively. Plasma is inclusive in that many existing blockchain system can be made plasma compatible to join the plasma hierarchy. Together with POS, Plasma appears to be well positioned to become one of the two key solutions to the scalability grief, with Sharding being the other. It's being observed that some of the best talents in the crypto economy industry have started join force to roll out plasma in the next year or two. UDAP is scheduled to work with plasma as the minimally viable plasma technology comes to the stage.

What are the general approaches of making UDAP scalable:

  1. Remove EVM in favor of native "smart contract". The decision to not support custom smart contract in a virtual machine has two advantageous consequences:
  • such that it would greatly reduce the attack surface, thus greatly improve the security factor of UDAP.
  • to save state storage space
  • to run transactions much faster.
  • to allow better parallelism.
  1. rework the gas mechanism. Remove the fine grained metering in favor of coarse grained usage metering. Gas mechanism must still exist against DOS attack.
  2. Run transactions in parallel. Ethereum sharding will probably introduce new transaction types that would allow better parallelism. see https://github.com/ethereum/sharding/blob/master/docs/account_redesign_eip.md and Easy parallelizability ethereum/EIPs#648. Since we
  3. Make UDAP to implement state channel and compatible with Plasma. Ultimately we want to make UDAP a part of Ethereum scalability platform and do not reinvent what Ethereum can offer in improving scalability in the near future. UDAP should focus on making itself the easiest solution for the next waves of Blockchain apps.
  4. Choose proper POS implementations for UDAP. Options includes Casper(s) and Tendermint, or Ouroboros
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant