Main Page

From twiki
Jump to navigation Jump to search

Welcome to Twiki -- A Toichain wiki

This is the unofficial Toichain wiki site. Content on this site is subject to frequent changes.

Introduction

The blockchain protocol was introduced via a paper entitled "Bitcoin: A peer-to-peer Electronic Cash System" [1] by Satoshi Nakamoto in 2008. Although there were other peer-to-peer file-sharing projects before this time, such as Napster [2] and Bittorrent [3], and other electronic currency attempts, the Bitcoin project demonstrated the strongest staying power compared even to the currently running 23,000+ other blockchains. Unlike the new cryptocurrencies, the Bitcoin is often referred to as "digital gold" for its scarcity, there are only 21 million hard-coded Bitcoins in the protocol. Other protocols (and associated currencies) have different token supply amount and monetary policies.

The most attractive common blockchain features are the decentralized consensus-driven decision making process and step-by-step cryptographic proving system. In addition to cryptocurrencies, there are many applications that can benefit from such a secure store of value with transaction ledger design without any central authority.


Before trying to understand the Blockchain protocol and its variants, it is important to understand the differences between an algorithm and a protocol.


In general, an algorithm is a program that runs on a single computer solving a single problem. A protocol, however, is a program that runs on all computers in parallel solving a single problem. An algorithm must be transformed to run on all computers in parallel solving the same problem before it to be called a protocol. Therefore, protocol development is significantly more difficult than algorithms.

Consensus Protocols

There are two popular types of consensus protocols: Proof of Work (POW) [4] or Proof of Stake (POS) [5]. Others include Proof of Possession(POP)[6], Proof of History(POH)[7]. The design goal of the consensus protocol is to eliminate double-spending, unfairness and code tampering, since most protocols are Open Source. For cryptocurrency applications, hacking and code tampering are difficult to avoid if not impossible. To date, the Bitcoin network using POW has suffered criticism on escalating electricity consumption [8]. The POH network Solana suffered multiple single-point-failure incidents [9]. All consensus protocols are susceptible to 51% attacks [10]. However, since 2009, Bitcoin has been proven the strongest against the common hacks [11]. As the POW difficulty has increased over the years, the probability of 51% attack on the Bitcoin network becomes more difficult. POS protocols can save more than 90% energy consumption compared to POW chains. According to Forbes, there are 80 cryptocurrencies use POS protocols at the time of this writing.

There are approximately 1,000 blockchains in four types: public, private, consortium, and permissioned [12].

Cryptographic Proofs

The Blockchain protocol relies on UTXO (unspent transaction output) model and lock-step cryptographic proofs to authenticate every transaction. Once spent, the UTXO is destroyed. Double-spending is theoretically impossible. Each proof step must be executed on a script engine running the same protocol on all nodes. The concurrently produced results are confirmed by the consensus protocol mentioned above and committed to the chain.

Blockchain Trilemma

Blockchain protocols have three common aspects: security, decentralization and scalability -- the three terms that do not have precise definitions but intuitively understood [13]. To date, the existing cryptographic tools have been proven effective for transaction security before the introduction of smart contracts. Decentralization is given by the nature of the protocols. In theory, there should be no service downtimes unless the entire network is down and all nodes crash at the same time. The scalability challenge eludes to deliverable performance and transaction finality which remained unclear.


The trilemma was first introduced by Vitalik Buterin[14], one of the co-founders of Ethereum network. The problems are real. There seems no obvious solutions to accomplish all three goals using known methods. Therefore, all proposed solutions revolve around reducing "opportunity costs" focusing only on partial goals.


Treating the blockchain network as an infrastructure for transaction processing, one would find the trilemma was only an extension of the legacy infrastructure scaling performance and reliability dilemma, where "infrastructure reliability" also does not have a commonly accepted definition. Fortunately all these metrics, although important, are non-functional. Every proposed solution can be a feasible solution with varying "opportunity costs". There was also no obvious solutions to overcome the dilemma.

Definitions

It helps to define the challenging metrics more precisely as infrastructure protocol design guidelines. For definitions #1 and #2, the word "infrastructure" implies all applications running on the infrastructure.

  1. Infrastructure Reliability: MTBF (mean time between failure) =
  2. Infrastructure Performance:
  3. Infrastructure Scalability: Expanding the infrastructure in number of processors, networks or storage should have incrementally better impacts on reliability and performance.
  4. Record Immutability: For transaction ledgers, all records and changes are final. This is required for blockchain ledger infrastructures.

Protocol Design and Proofs

Before building a robust protocol for infrastructure computing, there are well-known impossibilities and possibilities in physics and computer science that must be thoroughly examined for extreme cases.


The first challenge is infrastructure reliability. A computing infrastructure must deploy multiple components including computing, networking and storage. An infrastructure protocol defines how applications can compute, communicate and store results. A formal proof was found that it is impossible for reliable communication in the face of arbitrary crashes [15]. The laws of physics dictate component reliability [16] that 100% component reliability is not possible. These facts demands the infrastructure protocol (software program) to provide complete component (processing, networking and storage) decoupling from application software. The blockchain protocol proved the feasibility of such protocol.


Computer pioneer von Neumann, in addition to his contribution to computer architecture, also penned a study on building reliable system using unreliable components using probabilistic logics [17]. The pack-switching Internet was built using statistic multiplexed communication protocols. Probabilistic logic is the only possible definition for infrastructure reliability. In literature, this is referred to as the "best effort" reliability.


The Bitcoin protocol exploits multiple anonymous decoupled (or decentralized) computers connected with the Internet protocol. Judging from the Bitcoin network's reliability to date [18], von Neumann's theory seems working well.


The second challenge is infrastructure performance. Since the infrastructure must deploy multiple computing, networking and storage components, unless all components can be fully exploited in any scale, incremental performance delivery is impossible. Thus, von Neumann's statistic multiplexing theory must also apply here. The result is a new computing paradigm: Statistic Multiplexed Computing (SMC). The existing blockchain protocols fall short.

Infrastructure scalability challenge is automatically resolved once the performance challenge is resolved without negatively impacting reliability.


However, monotonically increasing performance may reach some theoretical limits. Thus, the only remaining challenge is Finality -- can any blockchain protocol design practically deliver true ledger finality in perpetuity?

Theoretically, only statistic multiplexed blockchain protocol can meet the scalability challenge.

Scalability Proof

The proof makes two assumptions:

  • The number of computing, networking and storage components has no upper bound over time.
  • The computation problem size can expand without a bound over time.


A formal proof requires a parallel computing model, when taking the number of components to infinity, can yield the maximal performance limit under the assumptions. There are two such models: Amdahl's Law [19] and Gustafson's Law [20]. The problem is that these two "laws" seem to yield complete opposite performance predictions. The Amdahl's Law seems to predict parallel performances following the economic law of diminishing of returns while Gustafson's Law seems to lead infinite speedups. Gustafson's Law was used to argue for Massively Parallel Computing (MPC) experiments and Amdahl's Law was used to argue for bigger supercomputer constructions. In the last three decades, these laws have been used to build parallel computing systems and multi-processor operating systems and computing clouds.

A careful examination revealed that the two laws are mathematically dependent [21] where Amdahl's formulation has a tight peak performance bound when taking the number of parallel processors to infinity, where x = the percentage of serial portion of instructions in a program. This means that the peak performance of every parallel program is above-bounded to , when x -> 0, the performance will asymptotically approach to infinity, when x -> 1 there will be no speedup. If the computing problem's size is fixed, x will eventually approach to 1 as the number of processors increases. If the problem size is open (solving bigger problems), then increasing the number of processors will force x to approach zero. This happens in practice when developers simply increasing the problem size to exploit more parallel processors. A classical example is the TOP500 supercomputer benchmarks that have open problem sizes for manufacturers to compete for the world's fastest supercomputer race [22] . In practical blockchain applications, the number of transactions to be processed can only increase if the infrastructure is useful.

In practical blockchain applications, the number of transactions to be processed can only increase if the infrastructure is useful.

Conclusion

These discussions can conclude that in theory, a statistic multiplexed blockchain protocol can deliver infinitely scalable infrastructure in performance and reliability. Leveraging blockchain's data and processing authenticity guarantee via the lock-step cryptographic proofs, infrastructure security is also feasible.


This surprising result is also applicable to ledger storage. Without multiplexing, the blockchain ledger storage will eventually saturate all nodes. The SMC blockchain protocol promises to hold the true finality of all transactions without size limitation.


There are more details for the protocol implementation, especially for Open Source public chains. This means that the protocol implementation must be code tamper resistant, natural disaster and human accident resistant. A strong decentralized consensus protocol is needed.

Proof of Stake Protocols

There are many POS protocol designs.

- Statistic Multiplexed Computing - Statistic multiplexing method was first proposed in 1952 by von Neumann.

- Statistic Multiplexed Blockchain -

References

  1. ↑ https://bitcoin.org/bitcoin.pdf
  2. ↑ https://www.napster.com/us
  3. ↑ https://www.bittorrent.com/
  4. ↑ https://www.investopedia.com/terms/p/proof-work.asp#:~:text=Proof%20of%20work%20(PoW)%20is,a%20reward%20for%20work%20done.
  5. ↑ https://www.investopedia.com/terms/p/proof-stake-pos.asp
  6. ↑ https://csrc.nist.gov/glossary/term/proof_of_possession#:~:text=Definition(s)%3A,associated%20with%20the%20public%20key.
  7. ↑ https://www.infoworld.com/article/3666736/solana-blockchain-and-the-proof-of-history.html
  8. ↑ https://rmi.org/cryptocurrencys-energy-consumption-problem/#:~:text=Bitcoin%20alone%20is%20estimated%20to,fuel%20used%20by%20US%20railroads.
  9. ↑ https://cryptoslate.com/heres-why-the-recent-solana-outage-took-almost-a-day-to-resolve/#:~:text=25%20%E2%80%94%20the%20first%20interruption%20in,3%20minor%2C%20outages%20in%202022.
  10. ↑ https://originstamp.com/blog/has-there-ever-been-a-51-attack-on-bitcoin/#notable-51-attacks
  11. ↑ https://www.theguardian.com/technology/2014/mar/18/history-of-bitcoin-hacks-alternative-currency
  12. ↑ https://increditools.com/blockchains/
  13. ↑ https://sensoriumxr.com/articles/what-is-the-blockchain-trilemma
  14. ↑ https://en.wikipedia.org/wiki/Vitalik_Buterin
  15. ↑ https://groups.csail.mit.edu/tds/papers/Lynch/jacm93.pdf
  16. ↑ Encyclopedia of Physical Science and Technology, Editor-in-Chief Robert A. Meyers, ISBN 978-0-12-227410-7, 2001
  17. ↑ https://static.ias.edu/pitp/archive/2012files/Probabilistic_Logics.pdf
  18. ↑ https://buybitcoinworldwide.com/bitcoin-downtime/
  19. ↑ https://en.wikipedia.org/wiki/Amdahl%27s_law
  20. ↑ https://en.wikipedia.org/wiki/Gustafson%27s_law
  21. ↑ https://cis.temple.edu/~shi/wwwroot/shi/public_html/docs/amdahl/amdahl.html
  22. ↑ https://www.top500.org/


Consult the User's Guide for information on using the wiki software.

Getting started

Retrieved from "https://smcdev1.ddns.net/twiki/index.php?title=Main_Page&oldid=31"