udap / udap-core Goto Github PK

As we are dealing with everyone's asset on the blockchain or on open ledgers, privacy is the paramount concern that the network must have a solid answer for. Privacy protection is the sine qua non for storing and trading assets public shared ledgers.

No people or organizations while their data to be visible by everyone. They want to use the blockchain the same way as they use their personal safe. But the first and second generation of open Ledger technologies have not been particularly good at privacy protections. In fact with the support of decent tools, check sections at different times can be cross-linked together for authorities to track the asset flows and ownerships.

If we are looking further into the next 15 years, resistance to quantum computing Will gradually become another major concern for open blockchain-based based asset management.

While we probably don't need to design quantum computing resistance into the first draft of our security design, we'lll need a practical and effective privacy protection in our first public release of of the platform.

The requirement of privacy is not just about hiding sensitive data from prying eyes, it's about protecting the fair mechanism of financial trading game. Many Financial operations designs will fall apart without strict transaction protections.

We have a few targets for the protection of privacies:

1. Nobody should know how much asset any other people have. There are two levels of detail involved:

• the asset of the blockchain must not be linked to with real-world people.
• ideally, addresses of the chain should also be decoupled from the assets each of the addresses possesses, meaning no one knows how much an address owns and what asset they own.

2. The details of transactions should not be revealed to public until the moment it's been set to do so.

Let's start by digesting some analysis from Vitalik Buterin:

"Many people talk about consortium chains where data is encrypted so that only people who need to see a piece of data can see the data, though I think people who want this really want a combination of state channels and proof-of-existence anchoring."

Ethereum API does not give client finality. It requires confirmation.

How is UDAP going to shield dApps from the uncertainty of probabilistic model of consensus model?

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.

2. rework the gas mechanism. Remove the fine grained metering in favor of coarse grained usage metering. Gas mechanism must still exist against DOS attack.
3. 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 ethereum/EIPs#648. Since we
4. 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.
5. Choose proper POS implementations for UDAP. Options includes Casper(s) and Tendermint, or Ouroboros