twiki - User contributions [en]

Main Page

2024-10-16T14:20:52Z

Justin: /* A Scalability Solution */

= <strong><big>'''Welcome to Toi-Twiki -- A Toichain Wiki'''</big></strong> =
This is the unofficial Toichain wiki site. Content is subject to changes.
---------------------------

= '''Introduction''' =
The blockchain protocol was introduced in a seminal paper entitled "Bitcoin: A peer-to-peer Electronic Cash System" <ref>https://bitcoin.org/bitcoin.pdf</ref> by Satoshi Nakamoto in 2008. Although there were previous peer-to-peer file-sharing projects such as Napster <ref>https://www.napster.com/us</ref>, BitTorrent <ref>https://www.bittorrent.com/</ref> and other electronic currency/file sharing applications, Bitcoin is the most enduring among the 23,000+ blockchains. Unlike other cryptocurrencies, the Bitcoin is often referred to as "digital gold" since the total coin supply is limited to 21 million (hard-coded in all running programs) and the only way to earn coin is to participate in the transaction block validation process. Token(or coin) supply and their disbursement policies differ among protocols.

The most attractive common blockchain features are 1) a decentralized consensus-driven decision making process and 2) a step-by-step cryptographic proving system. While blockchain is best known as a cryptocurrency transaction processing and record-keeping system, there are many other applications that can benefit from the secure storage, reliable transaction ledgers, fault tolerance and tamper resistance features.

== Algorithm vs. Protocol ==
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 ==
A good consensus protocol in a blockchain system has at least four properties:

# Fault tolerance to defend failures caused by natural disasters and human hacks or accidents
# Byzantine failure tolerance to defend exploitation by colluding parties
# Centralization avoidance to prevent corruptions in the decision making process
# Source code tamper resistance to automatically reject malicious attacks

Without assuming all nodes are active at all times, the blockchain relies on "gossip" protocol to communicate with other nodes. There are two popular types of consensus protocols: Proof of Work ('''PoW''') <ref>https://en.wikipedia.org/wiki/Proof_of_work</ref> or Proof of Stake ('''PoS''') <ref>https://www.investopedia.com/terms/p/proof-stake-pos.asp</ref>. Others include Proof of Possession('''PoP''')<ref>https://identityserver4.readthedocs.io/en/latest/topics/pop.html</ref> and Proof of History('''PoH''')<ref>https://www.infoworld.com/article/3666736/solana-blockchain-and-the-proof-of-history.html</ref>. The ultimate goal is to eliminate double-spending. Since most projects are open source, it's easy for a malicious actor to tamper a few nodes. This shouldn't compromise network integrity.

The Bitcoin network uses PoW which forces participating miners to compete for the fastest hashing rate by solving a computational cryptographic puzzle. Although it withstood more than 14 years of use, Bitcoin has been criticized for escalating electricity consumption <ref>https://www.forbes.com/advisor/investing/cryptocurrency/bitcoins-energy-usage-explained/</ref>. Other blockchain designs have experienced different challenges. For example, the PoH network Solana suffered multiple single-point-failure incidents <ref>https://messari.io/report/solana-analyzing-downtimes-statistics-and-ecosystem-development</ref>. All protocols struggle to combat scaling challenges. All are susceptible to 51% attacks <ref>https://originstamp.com/blog/has-there-ever-been-a-51-attack-on-bitcoin/#notable-51-attacks</ref>.

Since 2009, Bitcoin has proven to be the strongest and least susceptible to common hacks <ref>https://www.theguardian.com/technology/2014/mar/18/history-of-bitcoin-hacks-alternative-currency</ref>. As the PoW puzzle difficulty has increased dramatically over the years, the probability of a 51% attack on the Bitcoin network becomes more difficult. PoS protocols can save more than 90% energy consumption compared to PoW chains. But PoS chains have higher risks than PoW chains since a stolen coin will grow in PoS chains (for increased probability to be selected) forever but not in PoW chains (only hash rates count). PoS community governance rules can mitigate the voting power centralization problem. Staking and slashing policies can incentivize good behaviors and punish bad ones. In either case, double-spend is very expensive and difficult. According to Forbes, there are 80 cryptocurrencies that use PoS protocols at the time of this writing.

There are approximately 1,000 blockchains in four types: public, private, consortium, and permissioned <ref>https://increditools.com/blockchains/</ref>.

== Cryptographic Proofs ==
Bitcoin 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.

== Centralized vs. Decentralized Applications ==
The Bitcoin protocol enabled decentralized processing of traditionally centrally processed transactions without any trusted third-party. It inspired many decentralized financial applications, especially for applications with very long payment chains. However for fraud prevention and meeting financial regulatory requirements, many practical applications still require KYC (know your customer) checks. It is not possible to eliminate all trusted third parties, especially for custodial financial applications. There is a clear need for decentralized processing of trusted authority applications.

== Blockchain Trilemma ==
Blockchain protocols have three common aspects (goals): '''security''', '''decentralization''' and '''scalability''' -- these three terms do not have precise definitions but are intuitively understood <ref>https://sensoriumxr.com/articles/what-is-the-blockchain-trilemma</ref>. To date, 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.

A major shortcoming is scalability. Since all nodes verify each transaction independently, they need to store all the information required for it. As the chain grows, this burdens all nodes in the network. There are workarounds by limiting the amount of data stored on some nodes and exploiting the network to retrieve required information, such as the ''Limited/Light Nodes'' in Bitcoin network. Vast majority nodes are still full nodes in the existing Bitcoin network. Transaction processing speed often expressed ''as transactions per second(TPS) of'' blockchain have to exceed TPS ratings of credit card payment systems like VISA or MasterCard to reap the full benefits of blockchain. This is a tough problem and increasing the block size and/or reducing the block time or difficulty isn't a solution<ref>https://medium.com/coinmonks/blockchain-scaling-30c9e1b7db1b</ref>. Since blockchain TPS is very low, the transaction fees is often very high. This discourages public adoption. Layer 2 solution like ''Lightning Network'' or ''ZK-rollups,'' where only final settlement is on the main chain tend to address these issues. However, one could always argue that this often compromises some aspects of security and/or decentralization to achieve high TPS.

The trilemma was first introduced by Vitalik Buterin<ref>https://en.wikipedia.org/wiki/Vitalik_Buterin</ref>, one of the co-founders of Ethereum network. The problems he identified are real. There seem to be no obvious solutions that can accomplish all three goals at the same time. Therefore, all proposed solutions revolve around reducing "opportunity costs" focusing only on satisfying partial goals.

Treating the blockchain network as an infrastructure for transaction processing, the blockchain protocol solved service reliability problem but not performance challenge. The legacy infrastructure scaling dilemma: performance against reliability remains (where "infrastructure reliability" also does not have a commonly accepted definition). Fortunately these metrics, although important, are non-critical. Solutions that have been proposed have had varying opportunity costs. For many years, there were no obvious solutions that addressed all three blockchain goals (security, decentralization and scalability).
== Statistic Multiplexed Computing (SMC) ==
The principle of using unreliable components to build an arbitrarily reliable system was first lectured by von Neumann in the early 1950s<ref>https://static.ias.edu/pitp/archive/2012files/Probabilistic_Logics.pdf</ref>. The original idea was to use probabilistic logic to quantify the arbitrary reliability of a system by multiplexing all components. This theory was applied to the construction of Internet protocols to deliver the "best effort" reliability. Ironically, "best effort reliability" also enabled "best effort" performance which in turn enabled "best effort" scalability of the Internet. The same cannot be said to computing infrastructures.

The critical flaw in existing computing infrastructures is the assumed network and processor's reliability. This is exactly what the blockchain protocols have avoided. Therefore, the Bitcoin network demonstrated unprecedented service reliability and tamper resistance. As will be explained in this space, the SMC principles can also resolve blockchain's scalability challenge. This is a natural extension of the Internet protocol revolution for mission critical service infrastructures. Unlike existing blockchain protocols, the SMC powered blockchain protocol is applicable to centralized and decentralized applications. It paves the path for seamless integration of Web2.0 and Web3.0 infrastructures.

SMC technology was developed based on extensive experiences in fault tolerant high performance computing and rigorous impossibility studies. For details, click [[SMC|'''''here''''']].

== Definitions ==
'''Infrastructure scalability''' does not have a commonly accepted definition. It helps to define the challenging metrics more precisely before the infrastructure protocol design. In the following, the word "'''infrastructure'''" means any '''application running on the infrastructure.'''

# '''Infrastructure Reliability''': MTBF (mean time between failure) = <math>\frac{\sum ((Start-Of-Downtime) - (Start-of-uptime)) }{No-of-failures}</math>
# '''Infrastructure Performance''': <math>\frac{No-of-Transactions}{Second}</math>
# '''Infrastructure Scalability''': Expanding the infrastructure in number of processors, networks or storage should have '''incrementally better''' impacts on application reliability and performance.
# '''Record Immutability''': For transaction ledgers, all confirmed records and changes are final. This is required by the blockchain protocol.
Note that in practice, record immutability is much harder to achieve than expected. There are two challenges, a) 51% attacks can literally wipe out all histories if successful, and b) for protocols require all nodes to hold independently verified ledger, such as the Bitcoin, the storage requirement grows approximately 50GB per month. It is conceivable that the chain would collapse when all nodes' storage capacity is saturated. Dividing the chain into fixed "shards" can mitigate the eventuality for a while but cannot avoid the ultimate demise.

== 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 and considered.

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 crashe'''s <ref>https://groups.csail.mit.edu/tds/papers/Lynch/jacm93.pdf</ref>. The laws of physics regarding component reliability <ref>Encyclopedia of Physical Science and Technology, Editor-in-Chief Robert A. Meyers, [[index.php?title=Special:BookSources/9780122274107|ISBN 978-0-12-227410-7]], 2001</ref> show that '''100% component reliability is not possible.''' These facts require that the infrastructure protocol (program-program communication protocol) provide '''complete component (processing, networking and storage) decoupling''' from application program logics. This decoupling requirement forces the protocol to exploit "decentralized" or "stateless" components that the legacy infrastructure protocols, such as message passing interface (MPI), remote procedure call (RPC) and remote method invocation (RMI), cannot handle. The blockchain protocol is an example of a "best effort" availability protocol.

Quantifying infrastructure reliability can be traced back to the computer pioneer von Neumann. In addition to his contribution to computer architecture, von Neumann also penned a study on building reliable systems using unreliable components using probabilistic logics, in early fifties <ref>https://static.ias.edu/pitp/archive/2012files/Probabilistic_Logics.pdf</ref>. The 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 "best effort" reliability. Ironically, this best effort reliability also enabled the Internet's infinite scalability -- the benefit we enjoy now and into the future.

The Bitcoin protocol exploits multiple anonymous decoupled (or decentralized) computers connected through the Internet protocol. Judging from the Bitcoin network's reliability to date <ref>https://buybitcoinworldwide.com/bitcoin-downtime/</ref>, von Neumann's theory seems working well.

The '''second challenge''' involves infrastructure performance. Since the infrastructure must deploy multiple computing, networking and storage components, unless all components can be fully exploited at 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 lack this capability.

'''The infrastructure scalability challenge''' is automatically resolved once the performance challenge is resolved without negatively impacting reliability -- "best effort" performance" meets "best effort reliability". This requires inductive performance and reliability measures or deliveries.

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, an inductive statistic multiplexed blockchain protocol is needed to meet the scalability challenge. Non-inductive solutions such as fixed chain "sharding" or "Danksharding" <ref>https://ethereum.org/en/roadmap/danksharding/</ref> will only increase protocol development complexity with persistent performance walls.

== A Scalability Solution ==
An effective scalability solution can have two practical assumptions:

* The computation problem size can expand indefinitely, since every useful infrastructure is expected to solve bigger problems.

*Computing and network resources will continue to grow indefinitely, into the future.
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 <ref>https://en.wikipedia.org/wiki/Amdahl%27s_law</ref> and Gustafson's Law <ref>https://en.wikipedia.org/wiki/Gustafson%27s_law</ref>.

The Amdahl's Law assumes (0<= ''s'' <=1), a percentage of serial instructions that cannot be parallelized. Then the ''(1-s)'' percentage of instructions can be accelerated using ''p'' processors. The Speedup can then be expressed as:

<div style="text-align: center;">
Speedup(p) = <math>{1 \over s + {(1-s) \over p}}</math> (1) <br>Speedup(<math>\lim_{p \to \infty}</math>) = <math>\frac{1}{s}</math> (2)
</div>
Taking ''p'' to infinity in equation (1) yields equation (2). But this "scaling" step has two different operational semantics: a) increasing ''p'' for faster acceleration by reducing the value of (''1-s)/p'' solving the same problem. This will result ''s'' asymptotically approaching to 1. Thus the speedup is above bounded to 1. Or b) increasing ''p'' to increase the parallel instruction percentage ''(1-s)'' by solving bigger problems. This will force ''s'' asymptotically approach to 0. Then the speedup is unbounded <math>\infty</math>. This scaling ambiguity has caused more than half century of confusion in the community.

Although quantifying ''s'' requires defining the problem size, equations (1) and (2) are equally applicable to any programs solving any problem size with any percentage ''s''. The limit of speedup (2) also does not depend on problem size. However, since Amdahl originally used fixed problem sizes to argue for the validity of not building parallel machines with too many processors, assuming fixed problem size using ''p'' processors has been the norm in interpreting Amdahl's law in the past. This assumption has led to the dismal speedup predictions.[[File:Amdahl's Law.png|thumb|Amdahl's Law Speedup Predictions|center]]This Amdahl's Law interpretation seems to suggest parallel performances following the economic law of diminishing of returns, even though the mathematics model implies more potentials.

In 1988, Gustafson and Barsis at the Sandia National Laboratory conducted parallel computing experiments that seem to suggest potential infinite speedup.

Gustafson's Law was based on measured sequential and parallel elapsed times using ''p'' (=1024) processors. A new sequential percentage (''0<=x'<=1)'' can be calculated using ''p'' processors. ''(1-x')'' is the parallel percentage using ''p'' processors.

To estimate accomplished speedup, Gustafson's Law states:

<div style="text-align: center;">
<math>Speedup=\frac{Tseq}{Tpar}=\frac{s'+(1-s')p}{1}=s'+(1-s')p </math> (3)
</div>

Scaling ''p'' to <math>\infty</math> for equation (3) cannot be done mathematically since ''s''' is dependent on the values of ''p''. For practical applications, the scaling action also has two operational semantics: a) Keep the problem size fixed, adding processors to further reduce the total parallel processing time, this will push for bigger s' asymptotically to 1. Thus speedup is also bounded to 1. Or b) expanding the problem size to allow the parallel part expanded solving bigger problems by simply multiplying (1-''s')'' by ''p (as shown in the chart below)''. Even though the chart is mathematically incorrect, equation (3) can be translated to find the real serial percentage ''s'' under a single processor. Increasing ''p in equation(3)'' will force the translated s asymptotically approaching to 0. Speedup will be above bounded to ''<math>\infty</math> by Amdahl's equation (2)''.

For some reason, in late 1980's, Gustafson's Law was used to argue for Massively Parallel Computing (MPC) (or ManyCPU) experiments and Amdahl's Law was used to argue for bigger mainframe (or BigCPU) computer architectures. These laws have been used to support two diverging computing system experiments and constructions until recent convergence.
[[File:Gustafson.png|thumb|Gustafson's Law|center]]
It should now be obvious that the two law are identical with Amdahl's Law more succinct. But Gustafson's formula helps to quantify the serial percentages from practical program instrumentation. In fact, the two serial percentages can be related by a simple equation<ref>https://www.researchgate.net/publication/228367369_Reevaluating_Amdahl's_law_and_Gustafson's_law</ref>:

<div style="text-align: center;">
<math>s=\frac{s'}{s'+(1-s')p}</math> (4)
</div>

Both laws actually refer to the same mathematical abstraction. Gustafson's formula assists in quantifying the percentage of serial computing through parallel instrumentation. Amdahl's Law then delivers the ultimate predictions. This should have cleared the half-century myth about scaled-speedup and unscaled-speedup.

In practice, extracting parallelism from an algorithm to use more processors is much harder than simply expanding the already parallelized parts to solve bigger problems. This explanation can be validated in practice when developers routinely increasing the problem size to use more parallel processors.

[[File:Full Range Amdah's Law .png|alt=Full Power of Amdahl's Law|center|thumb|Full Power of Amdahl's Law]]

If we plot the full speedup curves against the number of processors, we will see the missing lines from the previous Amdahl's dismal prediction chart.

[[File:DiminishingReturn2.png|alt=infinite Speedup Under Amdahl's Law|center|thumb|Infinite Speedup in Amdahl's Law|400x400px]]

The TOP500 supercomputer competition provides another proof by a historical log of unrelenting computation power growths where the benchmark (Linpack) having no problem size limit. All manufacturers compete for the world's fastest supercomputer race <ref>https://www.top500.org/</ref> solving the largest possible Linpack problem that can be handled by the hardware. The follow chart illustrates the continuous speed improvements by year.
[[File:Supercomputers-history.png|center|thumb]]
In practical blockchain applications, the number of transactions to be processed will increase without a bound. The ledger storage will continue to grow. In practice, the available computing, networking and storage components will continue to grow without bound enabled by the networking protocols. Therefore it is possible to build an infinitely scalable blockchain with these assumption. In particular, a statistic multiplexed computing blockchain can meet any future application needs given proper economic incentives. The infrastructure no longer has the structural deficiency.

== Action Plan ==

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.

For Toichain protocol design, we choose Bitcoin 24.0.1 as the base line protocol by replacing the PoW consensus by PoS consensus and injecting SMC components into the protocol processing signaling for parallel computing.

This surprising result is also applicable to ledger storage. Without multiplexing, the blockchain ledger storage will eventually saturate all nodes causing the chain to collapse. The SMC blockchain protocol promises to hold the true finality of all transactions in perpetuity by multiplexing all storage resources while keeping the replication factor to a constant.

These discussions follow the inductive logic of the Law of Large Numbers <ref>https://www.sciencedirect.com/topics/mathematics/laws-of-large-number</ref>.

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

= SMC Proof of Stake Protocol =
Existing PoS protocol designs revolved around staking policies and randomness of the selection algorithm. Considering infrastructure scalability will add much complexity to the design. The examples include chain sharding and Danksharding <ref>https://ethereum.org/en/roadmap/danksharding/</ref>.

The challenge is complex -- we must deliver very high performance without compromising security and reliability of the network.

Technically, transaction replication and parallel processing were considered dangerous <ref>https://pages.cs.wisc.edu/~yxy/cs764-f20/papers/replication.pdf</ref> due to the potential race conditions (or double-spend problem). The blockchain protocol resolved the double-spending problem. It did not solve the parallel processing performance problem.

According to Professor Michael Flynn, there are three high-level parallel processing topologies: SIMD (single instruction multiple data), MIMD (multiple instructions multiple data), and pipeline (MISD - multiple instructions single data stream) <ref>https://link.springer.com/referenceworkentry/10.1007/978-0-387-09766-4_2</ref>. However, for eliminating double-spending, all transactions must be serialized, since each block may contain transactions affecting transactions in multiple other blocks. "Race conditions" and non-deterministic results are not allowed. Then the only possible topology entry is pipeline. This means for POS protocol, we must build a pipeline of transaction blocks to be validated without compromising network security and reliability.
[[File:Flynns-Taxonomy-of-Computer-Architectures.png|center|thumb|Parallel Processing Topologies]]
The problem is that the nature of the blockchain protocol is that all nodes run independently in parallel with little communication with other nodes via "gossip" protocols. It is far easier to force all nodes store the entire ledger than forcing them to form any pipeline and store partial chain data.

=== ACAN (Active Content Addressable Network) [U.S. PTO #11,588,926 B2, EPO #3539261] ===
ACAN is a high-level data '''''communication and synchronization protocol''''' with a SMC (statistic multiplexed computing) runtime that completely decouples all hardware components from communicating programs for network-scale high performance computing. The need for complete component decoupling was implemented in the original blockchain protocol via "gossip" protocol. This delivered blockchain's high availability and security. The simple "gossip" implementation in existing protocols is insufficient for parallel processing signaling.

The following figure illustrates the concept of ACAN (active content addressable networking) using UVR (unidirectional virtual ring) architecture. The illustrated implementation uses the Tuple Space resource tagging method and gossip protocol for UVR implementation.
[[File:SMC Architecture with ACAN.png|center|thumb|243x243px|SMC Architecture with ACAN]]

ACAN supports three simple APIs:

# '''read'''(&''key'', &''value''): ''key'' holds a search pattern in a "tuple space" where all nodes are connected. ''value'' holds the matched tuple, if any. This is a blocking call that a requesting program will be blocked until a pattern-matched tuple is found. The matching tuple remains in the "tuple space".
# '''get'''(&key, &value): Same as the "read()" API, except that the matching tuple is removed from the "tuple space".
# '''put'''(key, value): Inserts <key, value> into the "tuple space".

The use of "gossip" protocol can accelerate ACAN network saturation time. Applications running on ACAN will automatically form parallel processing topologies: pipeline, SIMD and MIMD without violating the serialization needs of transaction block validation. Replication factor can also be dynamically controlled to spread replicated blocks in randomly chosen hosts.

The highly parallel nature of the blockchain protocol will automatically implement the SMC principle in real time.

The critical feature of this dynamic SMC pipelined architecture is the inductive scaling feature.
[[File:Pipeline Parallel Processing.png|center|thumb|247x247px|Pipeline Parallel Processing]]

The speed up of a pipeline can be represented as: <math>SpeedUp = \left ( \frac{p\centerdot b}{p + (b-1)} \right )</math>, where p = number of processors in the pipeline, b = total blocks to be processed. Take the number of blocks to infinity:

<div style="text-align: center;">
<math>SpeedUp = \left ( \frac{p\centerdot b}{p + (b-1)} \right )=>\lim (b\Rightarrow\infty)(\frac{p}{\frac{p}{b}+1-\frac{1}{b}}) = p</math>
</div>

This means that as long as there are enough blocks to be processed, the entire chain's performance will be above bounded to the number of nodes in the pipeline.

For illustration purposes, the variation of block processing times was not considered in the above calculations. To see the power of pipeline parallelism, the automobile manufacturing processes illustrate a similar situation. The Hyundai Motor Company's production pipelines can produce 3,835 vehicles per day and 1.4M per year<ref>https://en.wikipedia.org/wiki/List_of_Hyundai_Motor_Company_manufacturing_facilities</ref>.

== Toichain Tokens ==
Toichain token is TOIN. There are 50,000,000,000 TOINs for the Alpha Release. There are air-drop tokens for early adopters, 1,000 TOIN each. Users need to register to download a toichain wallet to receive the payment. Citizenship is checked and verified to ensure that US citizens do not apply. The minimal staking contract is 10 TOINs.

== Non-Fungible Tokens ==
The TestNet Release of toichain protocol will support embedding arbitrary data in an "OP_RETURN" transaction that will be permanently recorded on the chain. Unlike the ordinal NFT <ref>https://blog.chain.link/ordinals-bitcoin-nfts/</ref> or NFT (non-fungible token) on other chains, these transactions cannot be altered or removed.

There are practical applications for these forever NFTs. Once Taproot is enabled on toichain, ordinal NFTs (BRC-20) will also be supported. Unlike the original Bitcoin network where BRC-20 craze has created massive network congestion<ref>https://beincrypto.com/learn/brc-20-token/</ref>, all transactions will be processed promptly in toichain without congestion or scaling problems.
== Toichain TestNet Launch ==
The toichain testnet launch will enable users to interact with one another through simple payments, just like the original Bitcoin network. Forever NFTs are supported. Smart contracts will be supported on a later date.

= References =
<references />

Consult the [[mediawikiwiki:Special:MyLanguage/Help:Contents|User's Guide]] for information on using the wiki software.

Main Page

2024-10-14T15:35:09Z

Justin: /* Definitions */

= <strong><big>'''Welcome to Toi-Twiki -- A Toichain Wiki'''</big></strong> =
This is the unofficial Toichain wiki site. Content is subject to changes.
---------------------------

= '''Introduction''' =
The blockchain protocol was introduced in a seminal paper entitled "Bitcoin: A peer-to-peer Electronic Cash System" <ref>https://bitcoin.org/bitcoin.pdf</ref> by Satoshi Nakamoto in 2008. Although there were previous peer-to-peer file-sharing projects such as Napster <ref>https://www.napster.com/us</ref>, BitTorrent <ref>https://www.bittorrent.com/</ref> and other electronic currency/file sharing applications, Bitcoin is the most enduring among the 23,000+ blockchains. Unlike other cryptocurrencies, the Bitcoin is often referred to as "digital gold" since the total coin supply is limited to 21 million (hard-coded in all running programs) and the only way to earn coin is to participate in the transaction block validation process. Token(or coin) supply and their disbursement policies differ among protocols.

The most attractive common blockchain features are 1) a decentralized consensus-driven decision making process and 2) a step-by-step cryptographic proving system. While blockchain is best known as a cryptocurrency transaction processing and record-keeping system, there are many other applications that can benefit from the secure storage, reliable transaction ledgers, fault tolerance and tamper resistance features.

== Algorithm vs. Protocol ==
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 ==
A good consensus protocol in a blockchain system has at least four properties:

# Fault tolerance to defend failures caused by natural disasters and human hacks or accidents
# Byzantine failure tolerance to defend exploitation by colluding parties
# Centralization avoidance to prevent corruptions in the decision making process
# Source code tamper resistance to automatically reject malicious attacks

Without assuming all nodes are active at all times, the blockchain relies on "gossip" protocol to communicate with other nodes. There are two popular types of consensus protocols: Proof of Work ('''PoW''') <ref>https://en.wikipedia.org/wiki/Proof_of_work</ref> or Proof of Stake ('''PoS''') <ref>https://www.investopedia.com/terms/p/proof-stake-pos.asp</ref>. Others include Proof of Possession('''PoP''')<ref>https://identityserver4.readthedocs.io/en/latest/topics/pop.html</ref> and Proof of History('''PoH''')<ref>https://www.infoworld.com/article/3666736/solana-blockchain-and-the-proof-of-history.html</ref>. The ultimate goal is to eliminate double-spending. Since most projects are open source, it's easy for a malicious actor to tamper a few nodes. This shouldn't compromise network integrity.

The Bitcoin network uses PoW which forces participating miners to compete for the fastest hashing rate by solving a computational cryptographic puzzle. Although it withstood more than 14 years of use, Bitcoin has been criticized for escalating electricity consumption <ref>https://www.forbes.com/advisor/investing/cryptocurrency/bitcoins-energy-usage-explained/</ref>. Other blockchain designs have experienced different challenges. For example, the PoH network Solana suffered multiple single-point-failure incidents <ref>https://messari.io/report/solana-analyzing-downtimes-statistics-and-ecosystem-development</ref>. All protocols struggle to combat scaling challenges. All are susceptible to 51% attacks <ref>https://originstamp.com/blog/has-there-ever-been-a-51-attack-on-bitcoin/#notable-51-attacks</ref>.

Since 2009, Bitcoin has proven to be the strongest and least susceptible to common hacks <ref>https://www.theguardian.com/technology/2014/mar/18/history-of-bitcoin-hacks-alternative-currency</ref>. As the PoW puzzle difficulty has increased dramatically over the years, the probability of a 51% attack on the Bitcoin network becomes more difficult. PoS protocols can save more than 90% energy consumption compared to PoW chains. But PoS chains have higher risks than PoW chains since a stolen coin will grow in PoS chains (for increased probability to be selected) forever but not in PoW chains (only hash rates count). PoS community governance rules can mitigate the voting power centralization problem. Staking and slashing policies can incentivize good behaviors and punish bad ones. In either case, double-spend is very expensive and difficult. According to Forbes, there are 80 cryptocurrencies that use PoS protocols at the time of this writing.

There are approximately 1,000 blockchains in four types: public, private, consortium, and permissioned <ref>https://increditools.com/blockchains/</ref>.

== Cryptographic Proofs ==
Bitcoin 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.

== Centralized vs. Decentralized Applications ==
The Bitcoin protocol enabled decentralized processing of traditionally centrally processed transactions without any trusted third-party. It inspired many decentralized financial applications, especially for applications with very long payment chains. However for fraud prevention and meeting financial regulatory requirements, many practical applications still require KYC (know your customer) checks. It is not possible to eliminate all trusted third parties, especially for custodial financial applications. There is a clear need for decentralized processing of trusted authority applications.

== Blockchain Trilemma ==
Blockchain protocols have three common aspects (goals): '''security''', '''decentralization''' and '''scalability''' -- these three terms do not have precise definitions but are intuitively understood <ref>https://sensoriumxr.com/articles/what-is-the-blockchain-trilemma</ref>. To date, 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.

A major shortcoming is scalability. Since all nodes verify each transaction independently, they need to store all the information required for it. As the chain grows, this burdens all nodes in the network. There are workarounds by limiting the amount of data stored on some nodes and exploiting the network to retrieve required information, such as the ''Limited/Light Nodes'' in Bitcoin network. Vast majority nodes are still full nodes in the existing Bitcoin network. Transaction processing speed often expressed ''as transactions per second(TPS) of'' blockchain have to exceed TPS ratings of credit card payment systems like VISA or MasterCard to reap the full benefits of blockchain. This is a tough problem and increasing the block size and/or reducing the block time or difficulty isn't a solution<ref>https://medium.com/coinmonks/blockchain-scaling-30c9e1b7db1b</ref>. Since blockchain TPS is very low, the transaction fees is often very high. This discourages public adoption. Layer 2 solution like ''Lightning Network'' or ''ZK-rollups,'' where only final settlement is on the main chain tend to address these issues. However, one could always argue that this often compromises some aspects of security and/or decentralization to achieve high TPS.

The trilemma was first introduced by Vitalik Buterin<ref>https://en.wikipedia.org/wiki/Vitalik_Buterin</ref>, one of the co-founders of Ethereum network. The problems he identified are real. There seem to be no obvious solutions that can accomplish all three goals at the same time. Therefore, all proposed solutions revolve around reducing "opportunity costs" focusing only on satisfying partial goals.

Treating the blockchain network as an infrastructure for transaction processing, the blockchain protocol solved service reliability problem but not performance challenge. The legacy infrastructure scaling dilemma: performance against reliability remains (where "infrastructure reliability" also does not have a commonly accepted definition). Fortunately these metrics, although important, are non-critical. Solutions that have been proposed have had varying opportunity costs. For many years, there were no obvious solutions that addressed all three blockchain goals (security, decentralization and scalability).
== Statistic Multiplexed Computing (SMC) ==
The principle of using unreliable components to build an arbitrarily reliable system was first lectured by von Neumann in the early 1950s<ref>https://static.ias.edu/pitp/archive/2012files/Probabilistic_Logics.pdf</ref>. The original idea was to use probabilistic logic to quantify the arbitrary reliability of a system by multiplexing all components. This theory was applied to the construction of Internet protocols to deliver the "best effort" reliability. Ironically, "best effort reliability" also enabled "best effort" performance which in turn enabled "best effort" scalability of the Internet. The same cannot be said to computing infrastructures.

The critical flaw in existing computing infrastructures is the assumed network and processor's reliability. This is exactly what the blockchain protocols have avoided. Therefore, the Bitcoin network demonstrated unprecedented service reliability and tamper resistance. As will be explained in this space, the SMC principles can also resolve blockchain's scalability challenge. This is a natural extension of the Internet protocol revolution for mission critical service infrastructures. Unlike existing blockchain protocols, the SMC powered blockchain protocol is applicable to centralized and decentralized applications. It paves the path for seamless integration of Web2.0 and Web3.0 infrastructures.

SMC technology was developed based on extensive experiences in fault tolerant high performance computing and rigorous impossibility studies. For details, click [[SMC|'''''here''''']].

== Definitions ==
'''Infrastructure scalability''' does not have a commonly accepted definition. It helps to define the challenging metrics more precisely before the infrastructure protocol design. In the following, the word "'''infrastructure'''" means any '''application running on the infrastructure.'''

# '''Infrastructure Reliability''': MTBF (mean time between failure) = <math>\frac{\sum ((Start-Of-Downtime) - (Start-of-uptime)) }{No-of-failures}</math>
# '''Infrastructure Performance''': <math>\frac{No-of-Transactions}{Second}</math>
# '''Infrastructure Scalability''': Expanding the infrastructure in number of processors, networks or storage should have '''incrementally better''' impacts on application reliability and performance.
# '''Record Immutability''': For transaction ledgers, all confirmed records and changes are final. This is required by the blockchain protocol.
Note that in practice, record immutability is much harder to achieve than expected. There are two challenges, a) 51% attacks can literally wipe out all histories if successful, and b) for protocols require all nodes to hold independently verified ledger, such as the Bitcoin, the storage requirement grows approximately 50GB per month. It is conceivable that the chain would collapse when all nodes' storage capacity is saturated. Dividing the chain into fixed "shards" can mitigate the eventuality for a while but cannot avoid the ultimate demise.

== 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 and considered.

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 crashe'''s <ref>https://groups.csail.mit.edu/tds/papers/Lynch/jacm93.pdf</ref>. The laws of physics regarding component reliability <ref>Encyclopedia of Physical Science and Technology, Editor-in-Chief Robert A. Meyers, [[index.php?title=Special:BookSources/9780122274107|ISBN 978-0-12-227410-7]], 2001</ref> show that '''100% component reliability is not possible.''' These facts require that the infrastructure protocol (program-program communication protocol) provide '''complete component (processing, networking and storage) decoupling''' from application program logics. This decoupling requirement forces the protocol to exploit "decentralized" or "stateless" components that the legacy infrastructure protocols, such as message passing interface (MPI), remote procedure call (RPC) and remote method invocation (RMI), cannot handle. The blockchain protocol is an example of a "best effort" availability protocol.

Quantifying infrastructure reliability can be traced back to the computer pioneer von Neumann. In addition to his contribution to computer architecture, von Neumann also penned a study on building reliable systems using unreliable components using probabilistic logics, in early fifties <ref>https://static.ias.edu/pitp/archive/2012files/Probabilistic_Logics.pdf</ref>. The 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 "best effort" reliability. Ironically, this best effort reliability also enabled the Internet's infinite scalability -- the benefit we enjoy now and into the future.

The Bitcoin protocol exploits multiple anonymous decoupled (or decentralized) computers connected through the Internet protocol. Judging from the Bitcoin network's reliability to date <ref>https://buybitcoinworldwide.com/bitcoin-downtime/</ref>, von Neumann's theory seems working well.

The '''second challenge''' involves infrastructure performance. Since the infrastructure must deploy multiple computing, networking and storage components, unless all components can be fully exploited at 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 lack this capability.

'''The infrastructure scalability challenge''' is automatically resolved once the performance challenge is resolved without negatively impacting reliability -- "best effort" performance" meets "best effort reliability". This requires inductive performance and reliability measures or deliveries.

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, an inductive statistic multiplexed blockchain protocol is needed to meet the scalability challenge. Non-inductive solutions such as fixed chain "sharding" or "Danksharding" <ref>https://ethereum.org/en/roadmap/danksharding/</ref> will only increase protocol development complexity with persistent performance walls.

== A Scalability Solution ==
An effective scalability solution can have two practical assumptions:

* The computation problem size can expand indefinitely, since every useful infrastructure is expected to solve bigger problems.

*Computing and network resources will continue to grow indefinitely, into the future.
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 <ref>https://en.wikipedia.org/wiki/Amdahl%27s_law</ref> and Gustafson's Law <ref>https://en.wikipedia.org/wiki/Gustafson%27s_law</ref>.

The Amdahl's Law assumes 0<= ''s'' <=1 percentage of serial instructions that cannot be parallelized. Then the ''(1-s)'' percentage of instructions can be accelerated using ''p'' processors.

<div style="text-align: center;">
Speedup(p) = <math>{1 \over s + {(1-s) \over p}}</math> (1) <br>Speedup(<math>\lim_{p \to \infty}</math>) = <math>\frac{1}{s}</math> (2)
</div>
Taking ''p'' to infinity in equation (1) yields equation (2). But this "scaling" step has two different operational semantics: a) increasing ''p'' for faster acceleration by reducing the value of (''1-s)/p'' solving the same problem. This will result ''s'' asymptotically approaching to 1. Thus the speedup is above bounded to 1. Or b) increasing ''p'' to increase the parallel instruction percentage ''(1-s)'' by solving bigger problems. This will force ''s'' asymptotically approach to 0. Then the speedup is unbounded <math>\infty</math>. This scaling ambiguity has caused more than half century of confusion in the community.

Although quantifying ''s'' requires defining the problem size, equations (1) and (2) are equally applicable to any programs solving any problem size with any percentage ''s''. The limit of speedup (2) also does not depend on problem size. However, since Amdahl originally used programs solving fixed problem sizes to argue the validity of not building parallel machines with too many processors, assuming fixed problem size using ''p'' processors has been the norm in interpreting Amdahl's law in the past. This assumption has led to the dismal speedup predictions.[[File:Amdahl's Law.png|thumb|Amdahl's Law Speedup Predictions|center]]The traditional Amdahl's Law interpretation seems to suggest parallel performances following the economic law of diminishing of returns, even though the mathematic model implies more potentials.

In 1988, Gustafson and Barsis at the Sandia National Laboratory conducted parallel computing experiments that seem to suggest potential infinite speedup.

Gustafson's Law was based on measured sequential and parallel elapsed times using ''p'' (=1024) processors. A new sequential percentage ''0<=x'<=1'' can be calculated using ''p'' processors. ''(1-x')'' is the parallel percentage using ''p'' processors.

To estimate accomplished speedup, Gustafson's Law states:

<div style="text-align: center;">
<math>Speedup=\frac{Tseq}{Tpar}=\frac{s'+(1-s')p}{1}=s'+(1-s')p </math> (3)
</div>

Scaling ''p'' to <math>\infty</math> for equation (3) cannot be done mathematically since ''s''' is dependent on the values of ''p''. For practical applications, the scaling action also has two operational semantics: a) Keep the problem size fixed, adding processors to further reduce the total parallel processing time, this will push for bigger s' asymptotically to 1. Thus speedup is also bounded to 1. Or b) expanding the problem size to allow the parallel part expanded solving bigger problems by simply multiplying (1-''s')'' by ''p (as shown in the chart below)''. Even though the following chart is mathematically incorrect, equation (3) can be translated to find the real serial percentage ''s'' under a single processor. Increasing ''p'' will force s asymptotically approaching to 0. Speedup will be above bounded to ''<math>\infty</math> by Amdahl's equation (2)''. For some reason, in late 1980's, Gustafson's Law was used to argue for Massively Parallel Computing (MPC) (or ManyCPU) experiments and Amdahl's Law was used to argue for bigger mainframe (or BigCPU) computer architectures. These laws have been used to support two diverging computing system experiments and constructions until recent convergence.
[[File:Gustafson.png|thumb|Gustafson's Law|center]]
It is now obvious that the two law are identical with Amdahl's Law more succinct. But Gustafson's formula helps to quantify the serial percentages from practical program executions. In fact, the two serial percentages can be related by a simple equation<ref>https://www.researchgate.net/publication/228367369_Reevaluating_Amdahl's_law_and_Gustafson's_law</ref>:

<div style="text-align: center;">
<math>s=\frac{s'}{s'+(1-s')p}</math> (4)
</div>

Both laws actually refer to the same mathematical abstraction. Gustafson's formula assists in quantifying the percentage of serial computing through parallel instrumentation. Amdahl's Law then delivers the ultimate predictions. This should have cleared the half-century myth about scaled-speedup and unscaled-speedup.

In practice, extracting parallelism from an algorithm to use more processors is much harder than simply expanding the already parallelized parts to solve bigger problems. This explanation can be validated in practice when developers routinely increasing the problem size to use more parallel processors.

[[File:Full Range Amdah's Law .png|alt=Full Power of Amdahl's Law|center|thumb|Full Power of Amdahl's Law]]

If we plot the full speedup curves against the number of processors, we will see the missing lines from the previous Amdahl's dismal prediction chart.

[[File:DiminishingReturn2.png|alt=infinite Speedup Under Amdahl's Law|center|thumb|Infinite Speedup in Amdahl's Law|400x400px]]

The TOP500 supercomputer competition provides another proof by a historical log of unrelenting computation power growths where the benchmarks (linear solvers) having no problem size limit. All manufacturers compete for the world's fastest supercomputer race <ref>https://www.top500.org/</ref> solving the largest possible problem that can be handled by the hardware. The follow chart illustrates the continuous speed improvements by year.
[[File:Supercomputers-history.png|center|thumb]]
In practical blockchain applications, the number of transactions to be processed will increase without a known limit. The ledger storage will continue to grow. In practice, the available computing, networking and storage components will continue to grow without bound enabled by the networking protocols. Therefore a statistic multiplexed computing blockchain can indeed meet any future application needs given proper economic incentives. The infrastructure no longer has the structural deficiency.

== Action Plan ==

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.

For Toichain protocol design, we choose Bitcoin 24.0.1 as the base line protocol by replacing the PoW consensus by PoS consensus and injecting SMC components into the protocol processing signaling for parallel computing.

This surprising result is also applicable to ledger storage. Without multiplexing, the blockchain ledger storage will eventually saturate all nodes causing the chain to collapse. The SMC blockchain protocol promises to hold the true finality of all transactions in perpetuity by multiplexing all storage resources while keeping the replication factor to a constant.

These discussions follow the inductive logic of the Law of Large Numbers <ref>https://www.sciencedirect.com/topics/mathematics/laws-of-large-number</ref>.

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

= SMC Proof of Stake Protocol =
Existing PoS protocol designs revolved around staking policies and randomness of the selection algorithm. Considering infrastructure scalability will add much complexity to the design. The examples include chain sharding and Danksharding <ref>https://ethereum.org/en/roadmap/danksharding/</ref>.

The challenge is complex -- we must deliver very high performance without compromising security and reliability of the network.

Technically, transaction replication and parallel processing were considered dangerous <ref>https://pages.cs.wisc.edu/~yxy/cs764-f20/papers/replication.pdf</ref> due to the potential race conditions (or double-spend problem). The blockchain protocol resolved the double-spending problem. It did not solve the parallel processing performance problem.

According to Professor Michael Flynn, there are three high-level parallel processing topologies: SIMD (single instruction multiple data), MIMD (multiple instructions multiple data), and pipeline (MISD - multiple instructions single data stream) <ref>https://link.springer.com/referenceworkentry/10.1007/978-0-387-09766-4_2</ref>. However, for eliminating double-spending, all transactions must be serialized, since each block may contain transactions affecting transactions in multiple other blocks. "Race conditions" and non-deterministic results are not allowed. Then the only possible topology entry is pipeline. This means for POS protocol, we must build a pipeline of transaction blocks to be validated without compromising network security and reliability.
[[File:Flynns-Taxonomy-of-Computer-Architectures.png|center|thumb|Parallel Processing Topologies]]
The problem is that the nature of the blockchain protocol is that all nodes run independently in parallel with little communication with other nodes via "gossip" protocols. It is far easier to force all nodes store the entire ledger than forcing them to form any pipeline and store partial chain data.

=== ACAN (Active Content Addressable Network) [U.S. PTO #11,588,926 B2, EPO #3539261] ===
ACAN is a high-level data '''''communication and synchronization protocol''''' with a SMC (statistic multiplexed computing) runtime that completely decouples all hardware components from communicating programs for network-scale high performance computing. The need for complete component decoupling was implemented in the original blockchain protocol via "gossip" protocol. This delivered blockchain's high availability and security. The simple "gossip" implementation in existing protocols is insufficient for parallel processing signaling.

The following figure illustrates the concept of ACAN (active content addressable networking) using UVR (unidirectional virtual ring) architecture. The illustrated implementation uses the Tuple Space resource tagging method and gossip protocol for UVR implementation.
[[File:SMC Architecture with ACAN.png|center|thumb|243x243px|SMC Architecture with ACAN]]

ACAN supports three simple APIs:

# '''read'''(&''key'', &''value''): ''key'' holds a search pattern in a "tuple space" where all nodes are connected. ''value'' holds the matched tuple, if any. This is a blocking call that a requesting program will be blocked until a pattern-matched tuple is found. The matching tuple remains in the "tuple space".
# '''get'''(&key, &value): Same as the "read()" API, except that the matching tuple is removed from the "tuple space".
# '''put'''(key, value): Inserts <key, value> into the "tuple space".

The use of "gossip" protocol can accelerate ACAN network saturation time. Applications running on ACAN will automatically form parallel processing topologies: pipeline, SIMD and MIMD without violating the serialization needs of transaction block validation. Replication factor can also be dynamically controlled to spread replicated blocks in randomly chosen hosts.

The highly parallel nature of the blockchain protocol will automatically implement the SMC principle in real time.

The critical feature of this dynamic SMC pipelined architecture is the inductive scaling feature.
[[File:Pipeline Parallel Processing.png|center|thumb|247x247px|Pipeline Parallel Processing]]

The speed up of a pipeline can be represented as: <math>SpeedUp = \left ( \frac{p\centerdot b}{p + (b-1)} \right )</math>, where p = number of processors in the pipeline, b = total blocks to be processed. Take the number of blocks to infinity:

<div style="text-align: center;">
<math>SpeedUp = \left ( \frac{p\centerdot b}{p + (b-1)} \right )=>\lim (b\Rightarrow\infty)(\frac{p}{\frac{p}{b}+1-\frac{1}{b}}) = p</math>
</div>

This means that as long as there are enough blocks to be processed, the entire chain's performance will be above bounded to the number of nodes in the pipeline.

For illustration purposes, the variation of block processing times was not considered in the above calculations. To see the power of pipeline parallelism, the automobile manufacturing processes illustrate a similar situation. The Hyundai Motor Company's production pipelines can produce 3,835 vehicles per day and 1.4M per year<ref>https://en.wikipedia.org/wiki/List_of_Hyundai_Motor_Company_manufacturing_facilities</ref>.

== Toichain Tokens ==
Toichain token is TOIN. There are 50,000,000,000 TOINs for the Alpha Release. There are air-drop tokens for early adopters, 1,000 TOIN each. Users need to register to download a toichain wallet to receive the payment. Citizenship is checked and verified to ensure that US citizens do not apply. The minimal staking contract is 10 TOINs.

== Non-Fungible Tokens ==
The TestNet Release of toichain protocol will support embedding arbitrary data in an "OP_RETURN" transaction that will be permanently recorded on the chain. Unlike the ordinal NFT <ref>https://blog.chain.link/ordinals-bitcoin-nfts/</ref> or NFT (non-fungible token) on other chains, these transactions cannot be altered or removed.

There are practical applications for these forever NFTs. Once Taproot is enabled on toichain, ordinal NFTs (BRC-20) will also be supported. Unlike the original Bitcoin network where BRC-20 craze has created massive network congestion<ref>https://beincrypto.com/learn/brc-20-token/</ref>, all transactions will be processed promptly in toichain without congestion or scaling problems.
== Toichain TestNet Launch ==
The toichain testnet launch will enable users to interact with one another through simple payments, just like the original Bitcoin network. Forever NFTs are supported. Smart contracts will be supported on a later date.

= References =
<references />

Consult the [[mediawikiwiki:Special:MyLanguage/Help:Contents|User's Guide]] for information on using the wiki software.

Main Page

2024-10-14T15:30:35Z

Justin: /* Definitions */

= <strong><big>'''Welcome to Toi-Twiki -- A Toichain Wiki'''</big></strong> =
This is the unofficial Toichain wiki site. Content is subject to changes.
---------------------------

= '''Introduction''' =
The blockchain protocol was introduced in a seminal paper entitled "Bitcoin: A peer-to-peer Electronic Cash System" <ref>https://bitcoin.org/bitcoin.pdf</ref> by Satoshi Nakamoto in 2008. Although there were previous peer-to-peer file-sharing projects such as Napster <ref>https://www.napster.com/us</ref>, BitTorrent <ref>https://www.bittorrent.com/</ref> and other electronic currency/file sharing applications, Bitcoin is the most enduring among the 23,000+ blockchains. Unlike other cryptocurrencies, the Bitcoin is often referred to as "digital gold" since the total coin supply is limited to 21 million (hard-coded in all running programs) and the only way to earn coin is to participate in the transaction block validation process. Token(or coin) supply and their disbursement policies differ among protocols.

The most attractive common blockchain features are 1) a decentralized consensus-driven decision making process and 2) a step-by-step cryptographic proving system. While blockchain is best known as a cryptocurrency transaction processing and record-keeping system, there are many other applications that can benefit from the secure storage, reliable transaction ledgers, fault tolerance and tamper resistance features.

== Algorithm vs. Protocol ==
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 ==
A good consensus protocol in a blockchain system has at least four properties:

# Fault tolerance to defend failures caused by natural disasters and human hacks or accidents
# Byzantine failure tolerance to defend exploitation by colluding parties
# Centralization avoidance to prevent corruptions in the decision making process
# Source code tamper resistance to automatically reject malicious attacks

Without assuming all nodes are active at all times, the blockchain relies on "gossip" protocol to communicate with other nodes. There are two popular types of consensus protocols: Proof of Work ('''PoW''') <ref>https://en.wikipedia.org/wiki/Proof_of_work</ref> or Proof of Stake ('''PoS''') <ref>https://www.investopedia.com/terms/p/proof-stake-pos.asp</ref>. Others include Proof of Possession('''PoP''')<ref>https://identityserver4.readthedocs.io/en/latest/topics/pop.html</ref> and Proof of History('''PoH''')<ref>https://www.infoworld.com/article/3666736/solana-blockchain-and-the-proof-of-history.html</ref>. The ultimate goal is to eliminate double-spending. Since most projects are open source, it's easy for a malicious actor to tamper a few nodes. This shouldn't compromise network integrity.

The Bitcoin network uses PoW which forces participating miners to compete for the fastest hashing rate by solving a computational cryptographic puzzle. Although it withstood more than 14 years of use, Bitcoin has been criticized for escalating electricity consumption <ref>https://www.forbes.com/advisor/investing/cryptocurrency/bitcoins-energy-usage-explained/</ref>. Other blockchain designs have experienced different challenges. For example, the PoH network Solana suffered multiple single-point-failure incidents <ref>https://messari.io/report/solana-analyzing-downtimes-statistics-and-ecosystem-development</ref>. All protocols struggle to combat scaling challenges. All are susceptible to 51% attacks <ref>https://originstamp.com/blog/has-there-ever-been-a-51-attack-on-bitcoin/#notable-51-attacks</ref>.

Since 2009, Bitcoin has proven to be the strongest and least susceptible to common hacks <ref>https://www.theguardian.com/technology/2014/mar/18/history-of-bitcoin-hacks-alternative-currency</ref>. As the PoW puzzle difficulty has increased dramatically over the years, the probability of a 51% attack on the Bitcoin network becomes more difficult. PoS protocols can save more than 90% energy consumption compared to PoW chains. But PoS chains have higher risks than PoW chains since a stolen coin will grow in PoS chains (for increased probability to be selected) forever but not in PoW chains (only hash rates count). PoS community governance rules can mitigate the voting power centralization problem. Staking and slashing policies can incentivize good behaviors and punish bad ones. In either case, double-spend is very expensive and difficult. According to Forbes, there are 80 cryptocurrencies that use PoS protocols at the time of this writing.

There are approximately 1,000 blockchains in four types: public, private, consortium, and permissioned <ref>https://increditools.com/blockchains/</ref>.

== Cryptographic Proofs ==
Bitcoin 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.

== Centralized vs. Decentralized Applications ==
The Bitcoin protocol enabled decentralized processing of traditionally centrally processed transactions without any trusted third-party. It inspired many decentralized financial applications, especially for applications with very long payment chains. However for fraud prevention and meeting financial regulatory requirements, many practical applications still require KYC (know your customer) checks. It is not possible to eliminate all trusted third parties, especially for custodial financial applications. There is a clear need for decentralized processing of trusted authority applications.

== Blockchain Trilemma ==
Blockchain protocols have three common aspects (goals): '''security''', '''decentralization''' and '''scalability''' -- these three terms do not have precise definitions but are intuitively understood <ref>https://sensoriumxr.com/articles/what-is-the-blockchain-trilemma</ref>. To date, 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.

A major shortcoming is scalability. Since all nodes verify each transaction independently, they need to store all the information required for it. As the chain grows, this burdens all nodes in the network. There are workarounds by limiting the amount of data stored on some nodes and exploiting the network to retrieve required information, such as the ''Limited/Light Nodes'' in Bitcoin network. Vast majority nodes are still full nodes in the existing Bitcoin network. Transaction processing speed often expressed ''as transactions per second(TPS) of'' blockchain have to exceed TPS ratings of credit card payment systems like VISA or MasterCard to reap the full benefits of blockchain. This is a tough problem and increasing the block size and/or reducing the block time or difficulty isn't a solution<ref>https://medium.com/coinmonks/blockchain-scaling-30c9e1b7db1b</ref>. Since blockchain TPS is very low, the transaction fees is often very high. This discourages public adoption. Layer 2 solution like ''Lightning Network'' or ''ZK-rollups,'' where only final settlement is on the main chain tend to address these issues. However, one could always argue that this often compromises some aspects of security and/or decentralization to achieve high TPS.

The trilemma was first introduced by Vitalik Buterin<ref>https://en.wikipedia.org/wiki/Vitalik_Buterin</ref>, one of the co-founders of Ethereum network. The problems he identified are real. There seem to be no obvious solutions that can accomplish all three goals at the same time. Therefore, all proposed solutions revolve around reducing "opportunity costs" focusing only on satisfying partial goals.

Treating the blockchain network as an infrastructure for transaction processing, the blockchain protocol solved service reliability problem but not performance challenge. The legacy infrastructure scaling dilemma: performance against reliability remains (where "infrastructure reliability" also does not have a commonly accepted definition). Fortunately these metrics, although important, are non-critical. Solutions that have been proposed have had varying opportunity costs. For many years, there were no obvious solutions that addressed all three blockchain goals (security, decentralization and scalability).
== Statistic Multiplexed Computing (SMC) ==
The principle of using unreliable components to build an arbitrarily reliable system was first lectured by von Neumann in the early 1950s<ref>https://static.ias.edu/pitp/archive/2012files/Probabilistic_Logics.pdf</ref>. The original idea was to use probabilistic logic to quantify the arbitrary reliability of a system by multiplexing all components. This theory was applied to the construction of Internet protocols to deliver the "best effort" reliability. Ironically, "best effort reliability" also enabled "best effort" performance which in turn enabled "best effort" scalability of the Internet. The same cannot be said to computing infrastructures.

The critical flaw in existing computing infrastructures is the assumed network and processor's reliability. This is exactly what the blockchain protocols have avoided. Therefore, the Bitcoin network demonstrated unprecedented service reliability and tamper resistance. As will be explained in this space, the SMC principles can also resolve blockchain's scalability challenge. This is a natural extension of the Internet protocol revolution for mission critical service infrastructures. Unlike existing blockchain protocols, the SMC powered blockchain protocol is applicable to centralized and decentralized applications. It paves the path for seamless integration of Web2.0 and Web3.0 infrastructures.

SMC technology was developed based on extensive experiences in fault tolerant high performance computing and rigorous impossibility studies. For details, click [[SMC|'''''here''''']].

== Definitions ==
'''Infrastructure scalability''' does not have a commonly accepted definition. It helps to define the challenging metrics more precisely before the infrastructure protocol design. In the following, the word "'''infrastructure'''" means any '''application running on the infrastructure.'''

# '''Infrastructure Reliability''': MTBF (mean time between failure) = <math>\frac{\sum ((Start-Of-Downtime) - (Start-of-uptime)) }{No-of-failures}</math>
# '''Infrastructure Performance''': <math>\frac{No-of-Transactions}{Second}</math>
# '''Infrastructure Scalability''': Expanding the infrastructure in number of processors, networks or storage should have '''incrementally better''' impacts on application reliability and performance.
# '''Record Immutability''': For transaction ledgers, all confirmed records and changes are final. This is required by the blockchain protocol.
Note that in practice, record immutability is much harder to achieve than expected. There are two challenges, a) 51% attacks can literally wipe out all histories if successful, and b) for protocols require all nodes to hold independently verified ledger, such as the Bitcoin, the storage requirement grows approximately 50GB per month.

== 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 and considered.

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 crashe'''s <ref>https://groups.csail.mit.edu/tds/papers/Lynch/jacm93.pdf</ref>. The laws of physics regarding component reliability <ref>Encyclopedia of Physical Science and Technology, Editor-in-Chief Robert A. Meyers, [[index.php?title=Special:BookSources/9780122274107|ISBN 978-0-12-227410-7]], 2001</ref> show that '''100% component reliability is not possible.''' These facts require that the infrastructure protocol (program-program communication protocol) provide '''complete component (processing, networking and storage) decoupling''' from application program logics. This decoupling requirement forces the protocol to exploit "decentralized" or "stateless" components that the legacy infrastructure protocols, such as message passing interface (MPI), remote procedure call (RPC) and remote method invocation (RMI), cannot handle. The blockchain protocol is an example of a "best effort" availability protocol.

Quantifying infrastructure reliability can be traced back to the computer pioneer von Neumann. In addition to his contribution to computer architecture, von Neumann also penned a study on building reliable systems using unreliable components using probabilistic logics, in early fifties <ref>https://static.ias.edu/pitp/archive/2012files/Probabilistic_Logics.pdf</ref>. The 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 "best effort" reliability. Ironically, this best effort reliability also enabled the Internet's infinite scalability -- the benefit we enjoy now and into the future.

The Bitcoin protocol exploits multiple anonymous decoupled (or decentralized) computers connected through the Internet protocol. Judging from the Bitcoin network's reliability to date <ref>https://buybitcoinworldwide.com/bitcoin-downtime/</ref>, von Neumann's theory seems working well.

The '''second challenge''' involves infrastructure performance. Since the infrastructure must deploy multiple computing, networking and storage components, unless all components can be fully exploited at 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 lack this capability.

'''The infrastructure scalability challenge''' is automatically resolved once the performance challenge is resolved without negatively impacting reliability -- "best effort" performance" meets "best effort reliability". This requires inductive performance and reliability measures or deliveries.

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, an inductive statistic multiplexed blockchain protocol is needed to meet the scalability challenge. Non-inductive solutions such as fixed chain "sharding" or "Danksharding" <ref>https://ethereum.org/en/roadmap/danksharding/</ref> will only increase protocol development complexity with persistent performance walls.

== A Scalability Solution ==
An effective scalability solution can have two practical assumptions:

* The computation problem size can expand indefinitely, since every useful infrastructure is expected to solve bigger problems.

*Computing and network resources will continue to grow indefinitely, into the future.
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 <ref>https://en.wikipedia.org/wiki/Amdahl%27s_law</ref> and Gustafson's Law <ref>https://en.wikipedia.org/wiki/Gustafson%27s_law</ref>.

The Amdahl's Law assumes 0<= ''s'' <=1 percentage of serial instructions that cannot be parallelized. Then the ''(1-s)'' percentage of instructions can be accelerated using ''p'' processors.

<div style="text-align: center;">
Speedup(p) = <math>{1 \over s + {(1-s) \over p}}</math> (1) <br>Speedup(<math>\lim_{p \to \infty}</math>) = <math>\frac{1}{s}</math> (2)
</div>
Taking ''p'' to infinity in equation (1) yields equation (2). But this "scaling" step has two different operational semantics: a) increasing ''p'' for faster acceleration by reducing the value of (''1-s)/p'' solving the same problem. This will result ''s'' asymptotically approaching to 1. Thus the speedup is above bounded to 1. Or b) increasing ''p'' to increase the parallel instruction percentage ''(1-s)'' by solving bigger problems. This will force ''s'' asymptotically approach to 0. Then the speedup is unbounded <math>\infty</math>. This scaling ambiguity has caused more than half century of confusion in the community.

Although quantifying ''s'' requires defining the problem size, equations (1) and (2) are equally applicable to any programs solving any problem size with any percentage ''s''. The limit of speedup (2) also does not depend on problem size. However, since Amdahl originally used programs solving fixed problem sizes to argue the validity of not building parallel machines with too many processors, assuming fixed problem size using ''p'' processors has been the norm in interpreting Amdahl's law in the past. This assumption has led to the dismal speedup predictions.[[File:Amdahl's Law.png|thumb|Amdahl's Law Speedup Predictions|center]]The traditional Amdahl's Law interpretation seems to suggest parallel performances following the economic law of diminishing of returns, even though the mathematic model implies more potentials.

In 1988, Gustafson and Barsis at the Sandia National Laboratory conducted parallel computing experiments that seem to suggest potential infinite speedup.

Gustafson's Law was based on measured sequential and parallel elapsed times using ''p'' (=1024) processors. A new sequential percentage ''0<=x'<=1'' can be calculated using ''p'' processors. ''(1-x')'' is the parallel percentage using ''p'' processors.

To estimate accomplished speedup, Gustafson's Law states:

<div style="text-align: center;">
<math>Speedup=\frac{Tseq}{Tpar}=\frac{s'+(1-s')p}{1}=s'+(1-s')p </math> (3)
</div>

Scaling ''p'' to <math>\infty</math> for equation (3) cannot be done mathematically since ''s''' is dependent on the values of ''p''. For practical applications, the scaling action also has two operational semantics: a) Keep the problem size fixed, adding processors to further reduce the total parallel processing time, this will push for bigger s' asymptotically to 1. Thus speedup is also bounded to 1. Or b) expanding the problem size to allow the parallel part expanded solving bigger problems by simply multiplying (1-''s')'' by ''p (as shown in the chart below)''. Even though the following chart is mathematically incorrect, equation (3) can be translated to find the real serial percentage ''s'' under a single processor. Increasing ''p'' will force s asymptotically approaching to 0. Speedup will be above bounded to ''<math>\infty</math> by Amdahl's equation (2)''. For some reason, in late 1980's, Gustafson's Law was used to argue for Massively Parallel Computing (MPC) (or ManyCPU) experiments and Amdahl's Law was used to argue for bigger mainframe (or BigCPU) computer architectures. These laws have been used to support two diverging computing system experiments and constructions until recent convergence.
[[File:Gustafson.png|thumb|Gustafson's Law|center]]
It is now obvious that the two law are identical with Amdahl's Law more succinct. But Gustafson's formula helps to quantify the serial percentages from practical program executions. In fact, the two serial percentages can be related by a simple equation<ref>https://www.researchgate.net/publication/228367369_Reevaluating_Amdahl's_law_and_Gustafson's_law</ref>:

<div style="text-align: center;">
<math>s=\frac{s'}{s'+(1-s')p}</math> (4)
</div>

Both laws actually refer to the same mathematical abstraction. Gustafson's formula assists in quantifying the percentage of serial computing through parallel instrumentation. Amdahl's Law then delivers the ultimate predictions. This should have cleared the half-century myth about scaled-speedup and unscaled-speedup.

In practice, extracting parallelism from an algorithm to use more processors is much harder than simply expanding the already parallelized parts to solve bigger problems. This explanation can be validated in practice when developers routinely increasing the problem size to use more parallel processors.

[[File:Full Range Amdah's Law .png|alt=Full Power of Amdahl's Law|center|thumb|Full Power of Amdahl's Law]]

If we plot the full speedup curves against the number of processors, we will see the missing lines from the previous Amdahl's dismal prediction chart.

[[File:DiminishingReturn2.png|alt=infinite Speedup Under Amdahl's Law|center|thumb|Infinite Speedup in Amdahl's Law|400x400px]]

The TOP500 supercomputer competition provides another proof by a historical log of unrelenting computation power growths where the benchmarks (linear solvers) having no problem size limit. All manufacturers compete for the world's fastest supercomputer race <ref>https://www.top500.org/</ref> solving the largest possible problem that can be handled by the hardware. The follow chart illustrates the continuous speed improvements by year.
[[File:Supercomputers-history.png|center|thumb]]
In practical blockchain applications, the number of transactions to be processed will increase without a known limit. The ledger storage will continue to grow. In practice, the available computing, networking and storage components will continue to grow without bound enabled by the networking protocols. Therefore a statistic multiplexed computing blockchain can indeed meet any future application needs given proper economic incentives. The infrastructure no longer has the structural deficiency.

== Action Plan ==

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.

For Toichain protocol design, we choose Bitcoin 24.0.1 as the base line protocol by replacing the PoW consensus by PoS consensus and injecting SMC components into the protocol processing signaling for parallel computing.

This surprising result is also applicable to ledger storage. Without multiplexing, the blockchain ledger storage will eventually saturate all nodes causing the chain to collapse. The SMC blockchain protocol promises to hold the true finality of all transactions in perpetuity by multiplexing all storage resources while keeping the replication factor to a constant.

These discussions follow the inductive logic of the Law of Large Numbers <ref>https://www.sciencedirect.com/topics/mathematics/laws-of-large-number</ref>.

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

= SMC Proof of Stake Protocol =
Existing PoS protocol designs revolved around staking policies and randomness of the selection algorithm. Considering infrastructure scalability will add much complexity to the design. The examples include chain sharding and Danksharding <ref>https://ethereum.org/en/roadmap/danksharding/</ref>.

The challenge is complex -- we must deliver very high performance without compromising security and reliability of the network.

Technically, transaction replication and parallel processing were considered dangerous <ref>https://pages.cs.wisc.edu/~yxy/cs764-f20/papers/replication.pdf</ref> due to the potential race conditions (or double-spend problem). The blockchain protocol resolved the double-spending problem. It did not solve the parallel processing performance problem.

According to Professor Michael Flynn, there are three high-level parallel processing topologies: SIMD (single instruction multiple data), MIMD (multiple instructions multiple data), and pipeline (MISD - multiple instructions single data stream) <ref>https://link.springer.com/referenceworkentry/10.1007/978-0-387-09766-4_2</ref>. However, for eliminating double-spending, all transactions must be serialized, since each block may contain transactions affecting transactions in multiple other blocks. "Race conditions" and non-deterministic results are not allowed. Then the only possible topology entry is pipeline. This means for POS protocol, we must build a pipeline of transaction blocks to be validated without compromising network security and reliability.
[[File:Flynns-Taxonomy-of-Computer-Architectures.png|center|thumb|Parallel Processing Topologies]]
The problem is that the nature of the blockchain protocol is that all nodes run independently in parallel with little communication with other nodes via "gossip" protocols. It is far easier to force all nodes store the entire ledger than forcing them to form any pipeline and store partial chain data.

=== ACAN (Active Content Addressable Network) [U.S. PTO #11,588,926 B2, EPO #3539261] ===
ACAN is a high-level data '''''communication and synchronization protocol''''' with a SMC (statistic multiplexed computing) runtime that completely decouples all hardware components from communicating programs for network-scale high performance computing. The need for complete component decoupling was implemented in the original blockchain protocol via "gossip" protocol. This delivered blockchain's high availability and security. The simple "gossip" implementation in existing protocols is insufficient for parallel processing signaling.

The following figure illustrates the concept of ACAN (active content addressable networking) using UVR (unidirectional virtual ring) architecture. The illustrated implementation uses the Tuple Space resource tagging method and gossip protocol for UVR implementation.
[[File:SMC Architecture with ACAN.png|center|thumb|243x243px|SMC Architecture with ACAN]]

ACAN supports three simple APIs:

# '''read'''(&''key'', &''value''): ''key'' holds a search pattern in a "tuple space" where all nodes are connected. ''value'' holds the matched tuple, if any. This is a blocking call that a requesting program will be blocked until a pattern-matched tuple is found. The matching tuple remains in the "tuple space".
# '''get'''(&key, &value): Same as the "read()" API, except that the matching tuple is removed from the "tuple space".
# '''put'''(key, value): Inserts <key, value> into the "tuple space".

The use of "gossip" protocol can accelerate ACAN network saturation time. Applications running on ACAN will automatically form parallel processing topologies: pipeline, SIMD and MIMD without violating the serialization needs of transaction block validation. Replication factor can also be dynamically controlled to spread replicated blocks in randomly chosen hosts.

The highly parallel nature of the blockchain protocol will automatically implement the SMC principle in real time.

The critical feature of this dynamic SMC pipelined architecture is the inductive scaling feature.
[[File:Pipeline Parallel Processing.png|center|thumb|247x247px|Pipeline Parallel Processing]]

The speed up of a pipeline can be represented as: <math>SpeedUp = \left ( \frac{p\centerdot b}{p + (b-1)} \right )</math>, where p = number of processors in the pipeline, b = total blocks to be processed. Take the number of blocks to infinity:

<div style="text-align: center;">
<math>SpeedUp = \left ( \frac{p\centerdot b}{p + (b-1)} \right )=>\lim (b\Rightarrow\infty)(\frac{p}{\frac{p}{b}+1-\frac{1}{b}}) = p</math>
</div>

This means that as long as there are enough blocks to be processed, the entire chain's performance will be above bounded to the number of nodes in the pipeline.

For illustration purposes, the variation of block processing times was not considered in the above calculations. To see the power of pipeline parallelism, the automobile manufacturing processes illustrate a similar situation. The Hyundai Motor Company's production pipelines can produce 3,835 vehicles per day and 1.4M per year<ref>https://en.wikipedia.org/wiki/List_of_Hyundai_Motor_Company_manufacturing_facilities</ref>.

== Toichain Tokens ==
Toichain token is TOIN. There are 50,000,000,000 TOINs for the Alpha Release. There are air-drop tokens for early adopters, 1,000 TOIN each. Users need to register to download a toichain wallet to receive the payment. Citizenship is checked and verified to ensure that US citizens do not apply. The minimal staking contract is 10 TOINs.

== Non-Fungible Tokens ==
The TestNet Release of toichain protocol will support embedding arbitrary data in an "OP_RETURN" transaction that will be permanently recorded on the chain. Unlike the ordinal NFT <ref>https://blog.chain.link/ordinals-bitcoin-nfts/</ref> or NFT (non-fungible token) on other chains, these transactions cannot be altered or removed.

There are practical applications for these forever NFTs. Once Taproot is enabled on toichain, ordinal NFTs (BRC-20) will also be supported. Unlike the original Bitcoin network where BRC-20 craze has created massive network congestion<ref>https://beincrypto.com/learn/brc-20-token/</ref>, all transactions will be processed promptly in toichain without congestion or scaling problems.
== Toichain TestNet Launch ==
The toichain testnet launch will enable users to interact with one another through simple payments, just like the original Bitcoin network. Forever NFTs are supported. Smart contracts will be supported on a later date.

= References =
<references />

Consult the [[mediawikiwiki:Special:MyLanguage/Help:Contents|User's Guide]] for information on using the wiki software.

Main Page

2024-10-14T15:29:22Z

Justin: /* Statistic Multiplexed Computing (SMC) */

= <strong><big>'''Welcome to Toi-Twiki -- A Toichain Wiki'''</big></strong> =
This is the unofficial Toichain wiki site. Content is subject to changes.
---------------------------

= '''Introduction''' =
The blockchain protocol was introduced in a seminal paper entitled "Bitcoin: A peer-to-peer Electronic Cash System" <ref>https://bitcoin.org/bitcoin.pdf</ref> by Satoshi Nakamoto in 2008. Although there were previous peer-to-peer file-sharing projects such as Napster <ref>https://www.napster.com/us</ref>, BitTorrent <ref>https://www.bittorrent.com/</ref> and other electronic currency/file sharing applications, Bitcoin is the most enduring among the 23,000+ blockchains. Unlike other cryptocurrencies, the Bitcoin is often referred to as "digital gold" since the total coin supply is limited to 21 million (hard-coded in all running programs) and the only way to earn coin is to participate in the transaction block validation process. Token(or coin) supply and their disbursement policies differ among protocols.

The most attractive common blockchain features are 1) a decentralized consensus-driven decision making process and 2) a step-by-step cryptographic proving system. While blockchain is best known as a cryptocurrency transaction processing and record-keeping system, there are many other applications that can benefit from the secure storage, reliable transaction ledgers, fault tolerance and tamper resistance features.

== Algorithm vs. Protocol ==
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 ==
A good consensus protocol in a blockchain system has at least four properties:

# Fault tolerance to defend failures caused by natural disasters and human hacks or accidents
# Byzantine failure tolerance to defend exploitation by colluding parties
# Centralization avoidance to prevent corruptions in the decision making process
# Source code tamper resistance to automatically reject malicious attacks

Without assuming all nodes are active at all times, the blockchain relies on "gossip" protocol to communicate with other nodes. There are two popular types of consensus protocols: Proof of Work ('''PoW''') <ref>https://en.wikipedia.org/wiki/Proof_of_work</ref> or Proof of Stake ('''PoS''') <ref>https://www.investopedia.com/terms/p/proof-stake-pos.asp</ref>. Others include Proof of Possession('''PoP''')<ref>https://identityserver4.readthedocs.io/en/latest/topics/pop.html</ref> and Proof of History('''PoH''')<ref>https://www.infoworld.com/article/3666736/solana-blockchain-and-the-proof-of-history.html</ref>. The ultimate goal is to eliminate double-spending. Since most projects are open source, it's easy for a malicious actor to tamper a few nodes. This shouldn't compromise network integrity.

The Bitcoin network uses PoW which forces participating miners to compete for the fastest hashing rate by solving a computational cryptographic puzzle. Although it withstood more than 14 years of use, Bitcoin has been criticized for escalating electricity consumption <ref>https://www.forbes.com/advisor/investing/cryptocurrency/bitcoins-energy-usage-explained/</ref>. Other blockchain designs have experienced different challenges. For example, the PoH network Solana suffered multiple single-point-failure incidents <ref>https://messari.io/report/solana-analyzing-downtimes-statistics-and-ecosystem-development</ref>. All protocols struggle to combat scaling challenges. All are susceptible to 51% attacks <ref>https://originstamp.com/blog/has-there-ever-been-a-51-attack-on-bitcoin/#notable-51-attacks</ref>.

Since 2009, Bitcoin has proven to be the strongest and least susceptible to common hacks <ref>https://www.theguardian.com/technology/2014/mar/18/history-of-bitcoin-hacks-alternative-currency</ref>. As the PoW puzzle difficulty has increased dramatically over the years, the probability of a 51% attack on the Bitcoin network becomes more difficult. PoS protocols can save more than 90% energy consumption compared to PoW chains. But PoS chains have higher risks than PoW chains since a stolen coin will grow in PoS chains (for increased probability to be selected) forever but not in PoW chains (only hash rates count). PoS community governance rules can mitigate the voting power centralization problem. Staking and slashing policies can incentivize good behaviors and punish bad ones. In either case, double-spend is very expensive and difficult. According to Forbes, there are 80 cryptocurrencies that use PoS protocols at the time of this writing.

There are approximately 1,000 blockchains in four types: public, private, consortium, and permissioned <ref>https://increditools.com/blockchains/</ref>.

== Cryptographic Proofs ==
Bitcoin 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.

== Centralized vs. Decentralized Applications ==
The Bitcoin protocol enabled decentralized processing of traditionally centrally processed transactions without any trusted third-party. It inspired many decentralized financial applications, especially for applications with very long payment chains. However for fraud prevention and meeting financial regulatory requirements, many practical applications still require KYC (know your customer) checks. It is not possible to eliminate all trusted third parties, especially for custodial financial applications. There is a clear need for decentralized processing of trusted authority applications.

== Blockchain Trilemma ==
Blockchain protocols have three common aspects (goals): '''security''', '''decentralization''' and '''scalability''' -- these three terms do not have precise definitions but are intuitively understood <ref>https://sensoriumxr.com/articles/what-is-the-blockchain-trilemma</ref>. To date, 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.

A major shortcoming is scalability. Since all nodes verify each transaction independently, they need to store all the information required for it. As the chain grows, this burdens all nodes in the network. There are workarounds by limiting the amount of data stored on some nodes and exploiting the network to retrieve required information, such as the ''Limited/Light Nodes'' in Bitcoin network. Vast majority nodes are still full nodes in the existing Bitcoin network. Transaction processing speed often expressed ''as transactions per second(TPS) of'' blockchain have to exceed TPS ratings of credit card payment systems like VISA or MasterCard to reap the full benefits of blockchain. This is a tough problem and increasing the block size and/or reducing the block time or difficulty isn't a solution<ref>https://medium.com/coinmonks/blockchain-scaling-30c9e1b7db1b</ref>. Since blockchain TPS is very low, the transaction fees is often very high. This discourages public adoption. Layer 2 solution like ''Lightning Network'' or ''ZK-rollups,'' where only final settlement is on the main chain tend to address these issues. However, one could always argue that this often compromises some aspects of security and/or decentralization to achieve high TPS.

The trilemma was first introduced by Vitalik Buterin<ref>https://en.wikipedia.org/wiki/Vitalik_Buterin</ref>, one of the co-founders of Ethereum network. The problems he identified are real. There seem to be no obvious solutions that can accomplish all three goals at the same time. Therefore, all proposed solutions revolve around reducing "opportunity costs" focusing only on satisfying partial goals.

Treating the blockchain network as an infrastructure for transaction processing, the blockchain protocol solved service reliability problem but not performance challenge. The legacy infrastructure scaling dilemma: performance against reliability remains (where "infrastructure reliability" also does not have a commonly accepted definition). Fortunately these metrics, although important, are non-critical. Solutions that have been proposed have had varying opportunity costs. For many years, there were no obvious solutions that addressed all three blockchain goals (security, decentralization and scalability).
== Statistic Multiplexed Computing (SMC) ==
The principle of using unreliable components to build an arbitrarily reliable system was first lectured by von Neumann in the early 1950s<ref>https://static.ias.edu/pitp/archive/2012files/Probabilistic_Logics.pdf</ref>. The original idea was to use probabilistic logic to quantify the arbitrary reliability of a system by multiplexing all components. This theory was applied to the construction of Internet protocols to deliver the "best effort" reliability. Ironically, "best effort reliability" also enabled "best effort" performance which in turn enabled "best effort" scalability of the Internet. The same cannot be said to computing infrastructures.

The critical flaw in existing computing infrastructures is the assumed network and processor's reliability. This is exactly what the blockchain protocols have avoided. Therefore, the Bitcoin network demonstrated unprecedented service reliability and tamper resistance. As will be explained in this space, the SMC principles can also resolve blockchain's scalability challenge. This is a natural extension of the Internet protocol revolution for mission critical service infrastructures. Unlike existing blockchain protocols, the SMC powered blockchain protocol is applicable to centralized and decentralized applications. It paves the path for seamless integration of Web2.0 and Web3.0 infrastructures.

SMC technology was developed based on extensive experiences in fault tolerant high performance computing and rigorous impossibility studies. For details, click [[SMC|'''''here''''']].

== Definitions ==
'''Infrastructure scalability''' does not have a commonly accepted definition. It helps to define the challenging metrics more precisely before the infrastructure protocol design. In the following, for definitions #1 and #2, the word "'''infrastructure'''" means any '''application running on the infrastructure.'''

# '''Infrastructure Reliability''': MTBF (mean time between failure) = <math>\frac{\sum ((Start-Of-Downtime) - (Start-of-uptime)) }{No-of-failures}</math>
# '''Infrastructure Performance''': <math>\frac{No-of-Transactions}{Second}</math>
# '''Infrastructure Scalability''': Expanding the infrastructure in number of processors, networks or storage should have '''incrementally better''' impacts on application reliability and performance.
# '''Record Immutability''': For transaction ledgers, all confirmed records and changes are final. This is required by the blockchain protocol.
Note that in practice, record immutability is much harder to achieve than expected. There are two challenges, a) 51% attacks can literally wipe out all histories if successful, and b) for protocols require all nodes to hold independently verified ledger, such as the Bitcoin, the storage requirement grows approximately 50GB per month.

== 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 and considered.

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 crashe'''s <ref>https://groups.csail.mit.edu/tds/papers/Lynch/jacm93.pdf</ref>. The laws of physics regarding component reliability <ref>Encyclopedia of Physical Science and Technology, Editor-in-Chief Robert A. Meyers, [[index.php?title=Special:BookSources/9780122274107|ISBN 978-0-12-227410-7]], 2001</ref> show that '''100% component reliability is not possible.''' These facts require that the infrastructure protocol (program-program communication protocol) provide '''complete component (processing, networking and storage) decoupling''' from application program logics. This decoupling requirement forces the protocol to exploit "decentralized" or "stateless" components that the legacy infrastructure protocols, such as message passing interface (MPI), remote procedure call (RPC) and remote method invocation (RMI), cannot handle. The blockchain protocol is an example of a "best effort" availability protocol.

Quantifying infrastructure reliability can be traced back to the computer pioneer von Neumann. In addition to his contribution to computer architecture, von Neumann also penned a study on building reliable systems using unreliable components using probabilistic logics, in early fifties <ref>https://static.ias.edu/pitp/archive/2012files/Probabilistic_Logics.pdf</ref>. The 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 "best effort" reliability. Ironically, this best effort reliability also enabled the Internet's infinite scalability -- the benefit we enjoy now and into the future.

The Bitcoin protocol exploits multiple anonymous decoupled (or decentralized) computers connected through the Internet protocol. Judging from the Bitcoin network's reliability to date <ref>https://buybitcoinworldwide.com/bitcoin-downtime/</ref>, von Neumann's theory seems working well.

The '''second challenge''' involves infrastructure performance. Since the infrastructure must deploy multiple computing, networking and storage components, unless all components can be fully exploited at 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 lack this capability.

'''The infrastructure scalability challenge''' is automatically resolved once the performance challenge is resolved without negatively impacting reliability -- "best effort" performance" meets "best effort reliability". This requires inductive performance and reliability measures or deliveries.

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, an inductive statistic multiplexed blockchain protocol is needed to meet the scalability challenge. Non-inductive solutions such as fixed chain "sharding" or "Danksharding" <ref>https://ethereum.org/en/roadmap/danksharding/</ref> will only increase protocol development complexity with persistent performance walls.

== A Scalability Solution ==
An effective scalability solution can have two practical assumptions:

* The computation problem size can expand indefinitely, since every useful infrastructure is expected to solve bigger problems.

*Computing and network resources will continue to grow indefinitely, into the future.
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 <ref>https://en.wikipedia.org/wiki/Amdahl%27s_law</ref> and Gustafson's Law <ref>https://en.wikipedia.org/wiki/Gustafson%27s_law</ref>.

The Amdahl's Law assumes 0<= ''s'' <=1 percentage of serial instructions that cannot be parallelized. Then the ''(1-s)'' percentage of instructions can be accelerated using ''p'' processors.

<div style="text-align: center;">
Speedup(p) = <math>{1 \over s + {(1-s) \over p}}</math> (1) <br>Speedup(<math>\lim_{p \to \infty}</math>) = <math>\frac{1}{s}</math> (2)
</div>
Taking ''p'' to infinity in equation (1) yields equation (2). But this "scaling" step has two different operational semantics: a) increasing ''p'' for faster acceleration by reducing the value of (''1-s)/p'' solving the same problem. This will result ''s'' asymptotically approaching to 1. Thus the speedup is above bounded to 1. Or b) increasing ''p'' to increase the parallel instruction percentage ''(1-s)'' by solving bigger problems. This will force ''s'' asymptotically approach to 0. Then the speedup is unbounded <math>\infty</math>. This scaling ambiguity has caused more than half century of confusion in the community.

Although quantifying ''s'' requires defining the problem size, equations (1) and (2) are equally applicable to any programs solving any problem size with any percentage ''s''. The limit of speedup (2) also does not depend on problem size. However, since Amdahl originally used programs solving fixed problem sizes to argue the validity of not building parallel machines with too many processors, assuming fixed problem size using ''p'' processors has been the norm in interpreting Amdahl's law in the past. This assumption has led to the dismal speedup predictions.[[File:Amdahl's Law.png|thumb|Amdahl's Law Speedup Predictions|center]]The traditional Amdahl's Law interpretation seems to suggest parallel performances following the economic law of diminishing of returns, even though the mathematic model implies more potentials.

In 1988, Gustafson and Barsis at the Sandia National Laboratory conducted parallel computing experiments that seem to suggest potential infinite speedup.

Gustafson's Law was based on measured sequential and parallel elapsed times using ''p'' (=1024) processors. A new sequential percentage ''0<=x'<=1'' can be calculated using ''p'' processors. ''(1-x')'' is the parallel percentage using ''p'' processors.

To estimate accomplished speedup, Gustafson's Law states:

<div style="text-align: center;">
<math>Speedup=\frac{Tseq}{Tpar}=\frac{s'+(1-s')p}{1}=s'+(1-s')p </math> (3)
</div>

Scaling ''p'' to <math>\infty</math> for equation (3) cannot be done mathematically since ''s''' is dependent on the values of ''p''. For practical applications, the scaling action also has two operational semantics: a) Keep the problem size fixed, adding processors to further reduce the total parallel processing time, this will push for bigger s' asymptotically to 1. Thus speedup is also bounded to 1. Or b) expanding the problem size to allow the parallel part expanded solving bigger problems by simply multiplying (1-''s')'' by ''p (as shown in the chart below)''. Even though the following chart is mathematically incorrect, equation (3) can be translated to find the real serial percentage ''s'' under a single processor. Increasing ''p'' will force s asymptotically approaching to 0. Speedup will be above bounded to ''<math>\infty</math> by Amdahl's equation (2)''. For some reason, in late 1980's, Gustafson's Law was used to argue for Massively Parallel Computing (MPC) (or ManyCPU) experiments and Amdahl's Law was used to argue for bigger mainframe (or BigCPU) computer architectures. These laws have been used to support two diverging computing system experiments and constructions until recent convergence.
[[File:Gustafson.png|thumb|Gustafson's Law|center]]
It is now obvious that the two law are identical with Amdahl's Law more succinct. But Gustafson's formula helps to quantify the serial percentages from practical program executions. In fact, the two serial percentages can be related by a simple equation<ref>https://www.researchgate.net/publication/228367369_Reevaluating_Amdahl's_law_and_Gustafson's_law</ref>:

<div style="text-align: center;">
<math>s=\frac{s'}{s'+(1-s')p}</math> (4)
</div>

Both laws actually refer to the same mathematical abstraction. Gustafson's formula assists in quantifying the percentage of serial computing through parallel instrumentation. Amdahl's Law then delivers the ultimate predictions. This should have cleared the half-century myth about scaled-speedup and unscaled-speedup.

In practice, extracting parallelism from an algorithm to use more processors is much harder than simply expanding the already parallelized parts to solve bigger problems. This explanation can be validated in practice when developers routinely increasing the problem size to use more parallel processors.

[[File:Full Range Amdah's Law .png|alt=Full Power of Amdahl's Law|center|thumb|Full Power of Amdahl's Law]]

If we plot the full speedup curves against the number of processors, we will see the missing lines from the previous Amdahl's dismal prediction chart.

[[File:DiminishingReturn2.png|alt=infinite Speedup Under Amdahl's Law|center|thumb|Infinite Speedup in Amdahl's Law|400x400px]]

The TOP500 supercomputer competition provides another proof by a historical log of unrelenting computation power growths where the benchmarks (linear solvers) having no problem size limit. All manufacturers compete for the world's fastest supercomputer race <ref>https://www.top500.org/</ref> solving the largest possible problem that can be handled by the hardware. The follow chart illustrates the continuous speed improvements by year.
[[File:Supercomputers-history.png|center|thumb]]
In practical blockchain applications, the number of transactions to be processed will increase without a known limit. The ledger storage will continue to grow. In practice, the available computing, networking and storage components will continue to grow without bound enabled by the networking protocols. Therefore a statistic multiplexed computing blockchain can indeed meet any future application needs given proper economic incentives. The infrastructure no longer has the structural deficiency.

== Action Plan ==

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.

For Toichain protocol design, we choose Bitcoin 24.0.1 as the base line protocol by replacing the PoW consensus by PoS consensus and injecting SMC components into the protocol processing signaling for parallel computing.

This surprising result is also applicable to ledger storage. Without multiplexing, the blockchain ledger storage will eventually saturate all nodes causing the chain to collapse. The SMC blockchain protocol promises to hold the true finality of all transactions in perpetuity by multiplexing all storage resources while keeping the replication factor to a constant.

These discussions follow the inductive logic of the Law of Large Numbers <ref>https://www.sciencedirect.com/topics/mathematics/laws-of-large-number</ref>.

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

= SMC Proof of Stake Protocol =
Existing PoS protocol designs revolved around staking policies and randomness of the selection algorithm. Considering infrastructure scalability will add much complexity to the design. The examples include chain sharding and Danksharding <ref>https://ethereum.org/en/roadmap/danksharding/</ref>.

The challenge is complex -- we must deliver very high performance without compromising security and reliability of the network.

Technically, transaction replication and parallel processing were considered dangerous <ref>https://pages.cs.wisc.edu/~yxy/cs764-f20/papers/replication.pdf</ref> due to the potential race conditions (or double-spend problem). The blockchain protocol resolved the double-spending problem. It did not solve the parallel processing performance problem.

According to Professor Michael Flynn, there are three high-level parallel processing topologies: SIMD (single instruction multiple data), MIMD (multiple instructions multiple data), and pipeline (MISD - multiple instructions single data stream) <ref>https://link.springer.com/referenceworkentry/10.1007/978-0-387-09766-4_2</ref>. However, for eliminating double-spending, all transactions must be serialized, since each block may contain transactions affecting transactions in multiple other blocks. "Race conditions" and non-deterministic results are not allowed. Then the only possible topology entry is pipeline. This means for POS protocol, we must build a pipeline of transaction blocks to be validated without compromising network security and reliability.
[[File:Flynns-Taxonomy-of-Computer-Architectures.png|center|thumb|Parallel Processing Topologies]]
The problem is that the nature of the blockchain protocol is that all nodes run independently in parallel with little communication with other nodes via "gossip" protocols. It is far easier to force all nodes store the entire ledger than forcing them to form any pipeline and store partial chain data.

=== ACAN (Active Content Addressable Network) [U.S. PTO #11,588,926 B2, EPO #3539261] ===
ACAN is a high-level data '''''communication and synchronization protocol''''' with a SMC (statistic multiplexed computing) runtime that completely decouples all hardware components from communicating programs for network-scale high performance computing. The need for complete component decoupling was implemented in the original blockchain protocol via "gossip" protocol. This delivered blockchain's high availability and security. The simple "gossip" implementation in existing protocols is insufficient for parallel processing signaling.

The following figure illustrates the concept of ACAN (active content addressable networking) using UVR (unidirectional virtual ring) architecture. The illustrated implementation uses the Tuple Space resource tagging method and gossip protocol for UVR implementation.
[[File:SMC Architecture with ACAN.png|center|thumb|243x243px|SMC Architecture with ACAN]]

ACAN supports three simple APIs:

# '''read'''(&''key'', &''value''): ''key'' holds a search pattern in a "tuple space" where all nodes are connected. ''value'' holds the matched tuple, if any. This is a blocking call that a requesting program will be blocked until a pattern-matched tuple is found. The matching tuple remains in the "tuple space".
# '''get'''(&key, &value): Same as the "read()" API, except that the matching tuple is removed from the "tuple space".
# '''put'''(key, value): Inserts <key, value> into the "tuple space".

The use of "gossip" protocol can accelerate ACAN network saturation time. Applications running on ACAN will automatically form parallel processing topologies: pipeline, SIMD and MIMD without violating the serialization needs of transaction block validation. Replication factor can also be dynamically controlled to spread replicated blocks in randomly chosen hosts.

The highly parallel nature of the blockchain protocol will automatically implement the SMC principle in real time.

The critical feature of this dynamic SMC pipelined architecture is the inductive scaling feature.
[[File:Pipeline Parallel Processing.png|center|thumb|247x247px|Pipeline Parallel Processing]]

The speed up of a pipeline can be represented as: <math>SpeedUp = \left ( \frac{p\centerdot b}{p + (b-1)} \right )</math>, where p = number of processors in the pipeline, b = total blocks to be processed. Take the number of blocks to infinity:

<div style="text-align: center;">
<math>SpeedUp = \left ( \frac{p\centerdot b}{p + (b-1)} \right )=>\lim (b\Rightarrow\infty)(\frac{p}{\frac{p}{b}+1-\frac{1}{b}}) = p</math>
</div>

This means that as long as there are enough blocks to be processed, the entire chain's performance will be above bounded to the number of nodes in the pipeline.

For illustration purposes, the variation of block processing times was not considered in the above calculations. To see the power of pipeline parallelism, the automobile manufacturing processes illustrate a similar situation. The Hyundai Motor Company's production pipelines can produce 3,835 vehicles per day and 1.4M per year<ref>https://en.wikipedia.org/wiki/List_of_Hyundai_Motor_Company_manufacturing_facilities</ref>.

== Toichain Tokens ==
Toichain token is TOIN. There are 50,000,000,000 TOINs for the Alpha Release. There are air-drop tokens for early adopters, 1,000 TOIN each. Users need to register to download a toichain wallet to receive the payment. Citizenship is checked and verified to ensure that US citizens do not apply. The minimal staking contract is 10 TOINs.

== Non-Fungible Tokens ==
The TestNet Release of toichain protocol will support embedding arbitrary data in an "OP_RETURN" transaction that will be permanently recorded on the chain. Unlike the ordinal NFT <ref>https://blog.chain.link/ordinals-bitcoin-nfts/</ref> or NFT (non-fungible token) on other chains, these transactions cannot be altered or removed.

There are practical applications for these forever NFTs. Once Taproot is enabled on toichain, ordinal NFTs (BRC-20) will also be supported. Unlike the original Bitcoin network where BRC-20 craze has created massive network congestion<ref>https://beincrypto.com/learn/brc-20-token/</ref>, all transactions will be processed promptly in toichain without congestion or scaling problems.
== Toichain TestNet Launch ==
The toichain testnet launch will enable users to interact with one another through simple payments, just like the original Bitcoin network. Forever NFTs are supported. Smart contracts will be supported on a later date.

= References =
<references />

Consult the [[mediawikiwiki:Special:MyLanguage/Help:Contents|User's Guide]] for information on using the wiki software.

Main Page

2024-10-14T13:06:15Z

Justin: /* Statistic Multiplexed Computing (SMC) */

= <strong><big>'''Welcome to Toi-Twiki -- A Toichain Wiki'''</big></strong> =
This is the unofficial Toichain wiki site. Content is subject to changes.
---------------------------

= '''Introduction''' =
The blockchain protocol was introduced in a seminal paper entitled "Bitcoin: A peer-to-peer Electronic Cash System" <ref>https://bitcoin.org/bitcoin.pdf</ref> by Satoshi Nakamoto in 2008. Although there were previous peer-to-peer file-sharing projects such as Napster <ref>https://www.napster.com/us</ref>, BitTorrent <ref>https://www.bittorrent.com/</ref> and other electronic currency/file sharing applications, Bitcoin is the most enduring among the 23,000+ blockchains. Unlike other cryptocurrencies, the Bitcoin is often referred to as "digital gold" since the total coin supply is limited to 21 million (hard-coded in all running programs) and the only way to earn coin is to participate in the transaction block validation process. Token(or coin) supply and their disbursement policies differ among protocols.

The most attractive common blockchain features are 1) a decentralized consensus-driven decision making process and 2) a step-by-step cryptographic proving system. While blockchain is best known as a cryptocurrency transaction processing and record-keeping system, there are many other applications that can benefit from the secure storage, reliable transaction ledgers, fault tolerance and tamper resistance features.

== Algorithm vs. Protocol ==
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 ==
A good consensus protocol in a blockchain system has at least four properties:

# Fault tolerance to defend failures caused by natural disasters and human hacks or accidents
# Byzantine failure tolerance to defend exploitation by colluding parties
# Centralization avoidance to prevent corruptions in the decision making process
# Source code tamper resistance to automatically reject malicious attacks

Without assuming all nodes are active at all times, the blockchain relies on "gossip" protocol to communicate with other nodes. There are two popular types of consensus protocols: Proof of Work ('''PoW''') <ref>https://en.wikipedia.org/wiki/Proof_of_work</ref> or Proof of Stake ('''PoS''') <ref>https://www.investopedia.com/terms/p/proof-stake-pos.asp</ref>. Others include Proof of Possession('''PoP''')<ref>https://identityserver4.readthedocs.io/en/latest/topics/pop.html</ref> and Proof of History('''PoH''')<ref>https://www.infoworld.com/article/3666736/solana-blockchain-and-the-proof-of-history.html</ref>. The ultimate goal is to eliminate double-spending. Since most projects are open source, it's easy for a malicious actor to tamper a few nodes. This shouldn't compromise network integrity.

The Bitcoin network uses PoW which forces participating miners to compete for the fastest hashing rate by solving a computational cryptographic puzzle. Although it withstood more than 14 years of use, Bitcoin has been criticized for escalating electricity consumption <ref>https://www.forbes.com/advisor/investing/cryptocurrency/bitcoins-energy-usage-explained/</ref>. Other blockchain designs have experienced different challenges. For example, the PoH network Solana suffered multiple single-point-failure incidents <ref>https://messari.io/report/solana-analyzing-downtimes-statistics-and-ecosystem-development</ref>. All protocols struggle to combat scaling challenges. All are susceptible to 51% attacks <ref>https://originstamp.com/blog/has-there-ever-been-a-51-attack-on-bitcoin/#notable-51-attacks</ref>.

Since 2009, Bitcoin has proven to be the strongest and least susceptible to common hacks <ref>https://www.theguardian.com/technology/2014/mar/18/history-of-bitcoin-hacks-alternative-currency</ref>. As the PoW puzzle difficulty has increased dramatically over the years, the probability of a 51% attack on the Bitcoin network becomes more difficult. PoS protocols can save more than 90% energy consumption compared to PoW chains. But PoS chains have higher risks than PoW chains since a stolen coin will grow in PoS chains (for increased probability to be selected) forever but not in PoW chains (only hash rates count). PoS community governance rules can mitigate the voting power centralization problem. Staking and slashing policies can incentivize good behaviors and punish bad ones. In either case, double-spend is very expensive and difficult. According to Forbes, there are 80 cryptocurrencies that use PoS protocols at the time of this writing.

There are approximately 1,000 blockchains in four types: public, private, consortium, and permissioned <ref>https://increditools.com/blockchains/</ref>.

== Cryptographic Proofs ==
Bitcoin 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.

== Centralized vs. Decentralized Applications ==
The Bitcoin protocol enabled decentralized processing of traditionally centrally processed transactions without any trusted third-party. It inspired many decentralized financial applications, especially for applications with very long payment chains. However for fraud prevention and meeting financial regulatory requirements, many practical applications still require KYC (know your customer) checks. It is not possible to eliminate all trusted third parties, especially for custodial financial applications. There is a clear need for decentralized processing of trusted authority applications.

== Blockchain Trilemma ==
Blockchain protocols have three common aspects (goals): '''security''', '''decentralization''' and '''scalability''' -- these three terms do not have precise definitions but are intuitively understood <ref>https://sensoriumxr.com/articles/what-is-the-blockchain-trilemma</ref>. To date, 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.

A major shortcoming is scalability. Since all nodes verify each transaction independently, they need to store all the information required for it. As the chain grows, this burdens all nodes in the network. There are workarounds by limiting the amount of data stored on some nodes and exploiting the network to retrieve required information, such as the ''Limited/Light Nodes'' in Bitcoin network. Vast majority nodes are still full nodes in the existing Bitcoin network. Transaction processing speed often expressed ''as transactions per second(TPS) of'' blockchain have to exceed TPS ratings of credit card payment systems like VISA or MasterCard to reap the full benefits of blockchain. This is a tough problem and increasing the block size and/or reducing the block time or difficulty isn't a solution<ref>https://medium.com/coinmonks/blockchain-scaling-30c9e1b7db1b</ref>. Since blockchain TPS is very low, the transaction fees is often very high. This discourages public adoption. Layer 2 solution like ''Lightning Network'' or ''ZK-rollups,'' where only final settlement is on the main chain tend to address these issues. However, one could always argue that this often compromises some aspects of security and/or decentralization to achieve high TPS.

The trilemma was first introduced by Vitalik Buterin<ref>https://en.wikipedia.org/wiki/Vitalik_Buterin</ref>, one of the co-founders of Ethereum network. The problems he identified are real. There seem to be no obvious solutions that can accomplish all three goals at the same time. Therefore, all proposed solutions revolve around reducing "opportunity costs" focusing only on satisfying partial goals.

Treating the blockchain network as an infrastructure for transaction processing, the blockchain protocol solved service reliability problem but not performance challenge. The legacy infrastructure scaling dilemma: performance against reliability remains (where "infrastructure reliability" also does not have a commonly accepted definition). Fortunately these metrics, although important, are non-critical. Solutions that have been proposed have had varying opportunity costs. For many years, there were no obvious solutions that addressed all three blockchain goals (security, decentralization and scalability).
== Statistic Multiplexed Computing (SMC) ==
The principle of using unreliable components to build an arbitrarily reliable system was first lectured by von Neumann in the early 1950s<ref>https://static.ias.edu/pitp/archive/2012files/Probabilistic_Logics.pdf</ref>. The original idea was to use probabilistic logic to quantify the arbitrary reliability of a system by multiplexing all components. This theory was applied to the construction of Internet protocols to deliver the "best effort" reliability. Ironically, "best effort reliability" also enabled "best effort" performance which in turn enabled "best effort" scalability of the Internet. The same cannot be said to legacy computing infrastructures.

For emerging web3.0 technologies, it is important to apply the same methodology to both centralized and decentralized computing for seamless technology migration and integration. For historical arguments, click [[SMC|'''''here''''']].

== Definitions ==
'''Infrastructure scalability''' does not have a commonly accepted definition. It helps to define the challenging metrics more precisely before the infrastructure protocol design. In the following, for definitions #1 and #2, the word "'''infrastructure'''" means any '''application running on the infrastructure.'''

# '''Infrastructure Reliability''': MTBF (mean time between failure) = <math>\frac{\sum ((Start-Of-Downtime) - (Start-of-uptime)) }{No-of-failures}</math>
# '''Infrastructure Performance''': <math>\frac{No-of-Transactions}{Second}</math>
# '''Infrastructure Scalability''': Expanding the infrastructure in number of processors, networks or storage should have '''incrementally better''' impacts on application reliability and performance.
# '''Record Immutability''': For transaction ledgers, all confirmed records and changes are final. This is required by the blockchain protocol.
Note that in practice, record immutability is much harder to achieve than expected. There are two challenges, a) 51% attacks can literally wipe out all histories if successful, and b) for protocols require all nodes to hold independently verified ledger, such as the Bitcoin, the storage requirement grows approximately 50GB per month.

== 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 and considered.

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 crashe'''s <ref>https://groups.csail.mit.edu/tds/papers/Lynch/jacm93.pdf</ref>. The laws of physics regarding component reliability <ref>Encyclopedia of Physical Science and Technology, Editor-in-Chief Robert A. Meyers, [[index.php?title=Special:BookSources/9780122274107|ISBN 978-0-12-227410-7]], 2001</ref> show that '''100% component reliability is not possible.''' These facts require that the infrastructure protocol (program-program communication protocol) provide '''complete component (processing, networking and storage) decoupling''' from application program logics. This decoupling requirement forces the protocol to exploit "decentralized" or "stateless" components that the legacy infrastructure protocols, such as message passing interface (MPI), remote procedure call (RPC) and remote method invocation (RMI), cannot handle. The blockchain protocol is an example of a "best effort" availability protocol.

Quantifying infrastructure reliability can be traced back to the computer pioneer von Neumann. In addition to his contribution to computer architecture, von Neumann also penned a study on building reliable systems using unreliable components using probabilistic logics, in early fifties <ref>https://static.ias.edu/pitp/archive/2012files/Probabilistic_Logics.pdf</ref>. The 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 "best effort" reliability. Ironically, this best effort reliability also enabled the Internet's infinite scalability -- the benefit we enjoy now and into the future.

The Bitcoin protocol exploits multiple anonymous decoupled (or decentralized) computers connected through the Internet protocol. Judging from the Bitcoin network's reliability to date <ref>https://buybitcoinworldwide.com/bitcoin-downtime/</ref>, von Neumann's theory seems working well.

The '''second challenge''' involves infrastructure performance. Since the infrastructure must deploy multiple computing, networking and storage components, unless all components can be fully exploited at 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 lack this capability.

'''The infrastructure scalability challenge''' is automatically resolved once the performance challenge is resolved without negatively impacting reliability -- "best effort" performance" meets "best effort reliability". This requires inductive performance and reliability measures or deliveries.

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, an inductive statistic multiplexed blockchain protocol is needed to meet the scalability challenge. Non-inductive solutions such as fixed chain "sharding" or "Danksharding" <ref>https://ethereum.org/en/roadmap/danksharding/</ref> will only increase protocol development complexity with persistent performance walls.

== A Scalability Solution ==
An effective scalability solution can have two practical assumptions:

* The computation problem size can expand indefinitely, since every useful infrastructure is expected to solve bigger problems.

*Computing and network resources will continue to grow indefinitely, into the future.
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 <ref>https://en.wikipedia.org/wiki/Amdahl%27s_law</ref> and Gustafson's Law <ref>https://en.wikipedia.org/wiki/Gustafson%27s_law</ref>.

The Amdahl's Law assumes 0<= ''s'' <=1 percentage of serial instructions that cannot be parallelized. Then the ''(1-s)'' percentage of instructions can be accelerated using ''p'' processors.

<div style="text-align: center;">
Speedup(p) = <math>{1 \over s + {(1-s) \over p}}</math> (1) <br>Speedup(<math>\lim_{p \to \infty}</math>) = <math>\frac{1}{s}</math> (2)
</div>
Taking ''p'' to infinity in equation (1) yields equation (2). But this "scaling" step has two different operational semantics: a) increasing ''p'' for faster acceleration by reducing the value of (''1-s)/p'' solving the same problem. This will result ''s'' asymptotically approaching to 1. Thus the speedup is above bounded to 1. Or b) increasing ''p'' to increase the parallel instruction percentage ''(1-s)'' by solving bigger problems. This will force ''s'' asymptotically approach to 0. Then the speedup is unbounded <math>\infty</math>. This scaling ambiguity has caused more than half century of confusion in the community.

Although quantifying ''s'' requires defining the problem size, equations (1) and (2) are equally applicable to any programs solving any problem size with any percentage ''s''. The limit of speedup (2) also does not depend on problem size. However, since Amdahl originally used programs solving fixed problem sizes to argue the validity of not building parallel machines with too many processors, assuming fixed problem size using ''p'' processors has been the norm in interpreting Amdahl's law in the past. This assumption has led to the dismal speedup predictions.[[File:Amdahl's Law.png|thumb|Amdahl's Law Speedup Predictions|center]]The traditional Amdahl's Law interpretation seems to suggest parallel performances following the economic law of diminishing of returns, even though the mathematic model implies more potentials.

In 1988, Gustafson and Barsis at the Sandia National Laboratory conducted parallel computing experiments that seem to suggest potential infinite speedup.

Gustafson's Law was based on measured sequential and parallel elapsed times using ''p'' (=1024) processors. A new sequential percentage ''0<=x'<=1'' can be calculated using ''p'' processors. ''(1-x')'' is the parallel percentage using ''p'' processors.

To estimate accomplished speedup, Gustafson's Law states:

<div style="text-align: center;">
<math>Speedup=\frac{Tseq}{Tpar}=\frac{s'+(1-s')p}{1}=s'+(1-s')p </math> (3)
</div>

Scaling ''p'' to <math>\infty</math> for equation (3) cannot be done mathematically since ''s''' is dependent on the values of ''p''. For practical applications, the scaling action also has two operational semantics: a) Keep the problem size fixed, adding processors to further reduce the total parallel processing time, this will push for bigger s' asymptotically to 1. Thus speedup is also bounded to 1. Or b) expanding the problem size to allow the parallel part expanded solving bigger problems by simply multiplying (1-''s')'' by ''p (as shown in the chart below)''. Even though the following chart is mathematically incorrect, equation (3) can be translated to find the real serial percentage ''s'' under a single processor. Increasing ''p'' will force s asymptotically approaching to 0. Speedup will be above bounded to ''<math>\infty</math> by Amdahl's equation (2)''. For some reason, in late 1980's, Gustafson's Law was used to argue for Massively Parallel Computing (MPC) (or ManyCPU) experiments and Amdahl's Law was used to argue for bigger mainframe (or BigCPU) computer architectures. These laws have been used to support two diverging computing system experiments and constructions until recent convergence.
[[File:Gustafson.png|thumb|Gustafson's Law|center]]
It is now obvious that the two law are identical with Amdahl's Law more succinct. But Gustafson's formula helps to quantify the serial percentages from practical program executions. In fact, the two serial percentages can be related by a simple equation<ref>https://www.researchgate.net/publication/228367369_Reevaluating_Amdahl's_law_and_Gustafson's_law</ref>:

<div style="text-align: center;">
<math>s=\frac{s'}{s'+(1-s')p}</math> (4)
</div>

Both laws actually refer to the same mathematical abstraction. Gustafson's formula assists in quantifying the percentage of serial computing through parallel instrumentation. Amdahl's Law then delivers the ultimate predictions. This should have cleared the half-century myth about scaled-speedup and unscaled-speedup.

In practice, extracting parallelism from an algorithm to use more processors is much harder than simply expanding the already parallelized parts to solve bigger problems. This explanation can be validated in practice when developers routinely increasing the problem size to use more parallel processors.

[[File:Full Range Amdah's Law .png|alt=Full Power of Amdahl's Law|center|thumb|Full Power of Amdahl's Law]]

If we plot the full speedup curves against the number of processors, we will see the missing lines from the previous Amdahl's dismal prediction chart.

[[File:DiminishingReturn2.png|alt=infinite Speedup Under Amdahl's Law|center|thumb|Infinite Speedup in Amdahl's Law|400x400px]]

The TOP500 supercomputer competition provides another proof by a historical log of unrelenting computation power growths where the benchmarks (linear solvers) having no problem size limit. All manufacturers compete for the world's fastest supercomputer race <ref>https://www.top500.org/</ref> solving the largest possible problem that can be handled by the hardware. The follow chart illustrates the continuous speed improvements by year.
[[File:Supercomputers-history.png|center|thumb]]
In practical blockchain applications, the number of transactions to be processed will increase without a known limit. The ledger storage will continue to grow. In practice, the available computing, networking and storage components will continue to grow without bound enabled by the networking protocols. Therefore a statistic multiplexed computing blockchain can indeed meet any future application needs given proper economic incentives. The infrastructure no longer has the structural deficiency.

== Action Plan ==

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.

For Toichain protocol design, we choose Bitcoin 24.0.1 as the base line protocol by replacing the PoW consensus by PoS consensus and injecting SMC components into the protocol processing signaling for parallel computing.

This surprising result is also applicable to ledger storage. Without multiplexing, the blockchain ledger storage will eventually saturate all nodes causing the chain to collapse. The SMC blockchain protocol promises to hold the true finality of all transactions in perpetuity by multiplexing all storage resources while keeping the replication factor to a constant.

These discussions follow the inductive logic of the Law of Large Numbers <ref>https://www.sciencedirect.com/topics/mathematics/laws-of-large-number</ref>.

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

= SMC Proof of Stake Protocol =
Existing PoS protocol designs revolved around staking policies and randomness of the selection algorithm. Considering infrastructure scalability will add much complexity to the design. The examples include chain sharding and Danksharding <ref>https://ethereum.org/en/roadmap/danksharding/</ref>.

The challenge is complex -- we must deliver very high performance without compromising security and reliability of the network.

Technically, transaction replication and parallel processing were considered dangerous <ref>https://pages.cs.wisc.edu/~yxy/cs764-f20/papers/replication.pdf</ref> due to the potential race conditions (or double-spend problem). The blockchain protocol resolved the double-spending problem. It did not solve the parallel processing performance problem.

According to Professor Michael Flynn, there are three high-level parallel processing topologies: SIMD (single instruction multiple data), MIMD (multiple instructions multiple data), and pipeline (MISD - multiple instructions single data stream) <ref>https://link.springer.com/referenceworkentry/10.1007/978-0-387-09766-4_2</ref>. However, for eliminating double-spending, all transactions must be serialized, since each block may contain transactions affecting transactions in multiple other blocks. "Race conditions" and non-deterministic results are not allowed. Then the only possible topology entry is pipeline. This means for POS protocol, we must build a pipeline of transaction blocks to be validated without compromising network security and reliability.
[[File:Flynns-Taxonomy-of-Computer-Architectures.png|center|thumb|Parallel Processing Topologies]]
The problem is that the nature of the blockchain protocol is that all nodes run independently in parallel with little communication with other nodes via "gossip" protocols. It is far easier to force all nodes store the entire ledger than forcing them to form any pipeline and store partial chain data.

=== ACAN (Active Content Addressable Network) [U.S. PTO #11,588,926 B2, EPO #3539261] ===
ACAN is a high-level data '''''communication and synchronization protocol''''' with a SMC (statistic multiplexed computing) runtime that completely decouples all hardware components from communicating programs for network-scale high performance computing. The need for complete component decoupling was implemented in the original blockchain protocol via "gossip" protocol. This delivered blockchain's high availability and security. The simple "gossip" implementation in existing protocols is insufficient for parallel processing signaling.

The following figure illustrates the concept of ACAN (active content addressable networking) using UVR (unidirectional virtual ring) architecture. The illustrated implementation uses the Tuple Space resource tagging method and gossip protocol for UVR implementation.
[[File:SMC Architecture with ACAN.png|center|thumb|243x243px|SMC Architecture with ACAN]]

ACAN supports three simple APIs:

# '''read'''(&''key'', &''value''): ''key'' holds a search pattern in a "tuple space" where all nodes are connected. ''value'' holds the matched tuple, if any. This is a blocking call that a requesting program will be blocked until a pattern-matched tuple is found. The matching tuple remains in the "tuple space".
# '''get'''(&key, &value): Same as the "read()" API, except that the matching tuple is removed from the "tuple space".
# '''put'''(key, value): Inserts <key, value> into the "tuple space".

The use of "gossip" protocol can accelerate ACAN network saturation time. Applications running on ACAN will automatically form parallel processing topologies: pipeline, SIMD and MIMD without violating the serialization needs of transaction block validation. Replication factor can also be dynamically controlled to spread replicated blocks in randomly chosen hosts.

The highly parallel nature of the blockchain protocol will automatically implement the SMC principle in real time.

The critical feature of this dynamic SMC pipelined architecture is the inductive scaling feature.
[[File:Pipeline Parallel Processing.png|center|thumb|247x247px|Pipeline Parallel Processing]]

The speed up of a pipeline can be represented as: <math>SpeedUp = \left ( \frac{p\centerdot b}{p + (b-1)} \right )</math>, where p = number of processors in the pipeline, b = total blocks to be processed. Take the number of blocks to infinity:

<div style="text-align: center;">
<math>SpeedUp = \left ( \frac{p\centerdot b}{p + (b-1)} \right )=>\lim (b\Rightarrow\infty)(\frac{p}{\frac{p}{b}+1-\frac{1}{b}}) = p</math>
</div>

This means that as long as there are enough blocks to be processed, the entire chain's performance will be above bounded to the number of nodes in the pipeline.

For illustration purposes, the variation of block processing times was not considered in the above calculations. To see the power of pipeline parallelism, the automobile manufacturing processes illustrate a similar situation. The Hyundai Motor Company's production pipelines can produce 3,835 vehicles per day and 1.4M per year<ref>https://en.wikipedia.org/wiki/List_of_Hyundai_Motor_Company_manufacturing_facilities</ref>.

== Toichain Tokens ==
Toichain token is TOIN. There are 50,000,000,000 TOINs for the Alpha Release. There are air-drop tokens for early adopters, 1,000 TOIN each. Users need to register to download a toichain wallet to receive the payment. Citizenship is checked and verified to ensure that US citizens do not apply. The minimal staking contract is 10 TOINs.

== Non-Fungible Tokens ==
The TestNet Release of toichain protocol will support embedding arbitrary data in an "OP_RETURN" transaction that will be permanently recorded on the chain. Unlike the ordinal NFT <ref>https://blog.chain.link/ordinals-bitcoin-nfts/</ref> or NFT (non-fungible token) on other chains, these transactions cannot be altered or removed.

There are practical applications for these forever NFTs. Once Taproot is enabled on toichain, ordinal NFTs (BRC-20) will also be supported. Unlike the original Bitcoin network where BRC-20 craze has created massive network congestion<ref>https://beincrypto.com/learn/brc-20-token/</ref>, all transactions will be processed promptly in toichain without congestion or scaling problems.
== Toichain TestNet Launch ==
The toichain testnet launch will enable users to interact with one another through simple payments, just like the original Bitcoin network. Forever NFTs are supported. Smart contracts will be supported on a later date.

= References =
<references />

Consult the [[mediawikiwiki:Special:MyLanguage/Help:Contents|User's Guide]] for information on using the wiki software.

Main Page

2024-10-14T13:03:47Z

Justin: /* Statistic Multiplexed Computing (SMC) */

= <strong><big>'''Welcome to Toi-Twiki -- A Toichain Wiki'''</big></strong> =
This is the unofficial Toichain wiki site. Content is subject to changes.
---------------------------

= '''Introduction''' =
The blockchain protocol was introduced in a seminal paper entitled "Bitcoin: A peer-to-peer Electronic Cash System" <ref>https://bitcoin.org/bitcoin.pdf</ref> by Satoshi Nakamoto in 2008. Although there were previous peer-to-peer file-sharing projects such as Napster <ref>https://www.napster.com/us</ref>, BitTorrent <ref>https://www.bittorrent.com/</ref> and other electronic currency/file sharing applications, Bitcoin is the most enduring among the 23,000+ blockchains. Unlike other cryptocurrencies, the Bitcoin is often referred to as "digital gold" since the total coin supply is limited to 21 million (hard-coded in all running programs) and the only way to earn coin is to participate in the transaction block validation process. Token(or coin) supply and their disbursement policies differ among protocols.

The most attractive common blockchain features are 1) a decentralized consensus-driven decision making process and 2) a step-by-step cryptographic proving system. While blockchain is best known as a cryptocurrency transaction processing and record-keeping system, there are many other applications that can benefit from the secure storage, reliable transaction ledgers, fault tolerance and tamper resistance features.

== Algorithm vs. Protocol ==
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 ==
A good consensus protocol in a blockchain system has at least four properties:

# Fault tolerance to defend failures caused by natural disasters and human hacks or accidents
# Byzantine failure tolerance to defend exploitation by colluding parties
# Centralization avoidance to prevent corruptions in the decision making process
# Source code tamper resistance to automatically reject malicious attacks

Without assuming all nodes are active at all times, the blockchain relies on "gossip" protocol to communicate with other nodes. There are two popular types of consensus protocols: Proof of Work ('''PoW''') <ref>https://en.wikipedia.org/wiki/Proof_of_work</ref> or Proof of Stake ('''PoS''') <ref>https://www.investopedia.com/terms/p/proof-stake-pos.asp</ref>. Others include Proof of Possession('''PoP''')<ref>https://identityserver4.readthedocs.io/en/latest/topics/pop.html</ref> and Proof of History('''PoH''')<ref>https://www.infoworld.com/article/3666736/solana-blockchain-and-the-proof-of-history.html</ref>. The ultimate goal is to eliminate double-spending. Since most projects are open source, it's easy for a malicious actor to tamper a few nodes. This shouldn't compromise network integrity.

The Bitcoin network uses PoW which forces participating miners to compete for the fastest hashing rate by solving a computational cryptographic puzzle. Although it withstood more than 14 years of use, Bitcoin has been criticized for escalating electricity consumption <ref>https://www.forbes.com/advisor/investing/cryptocurrency/bitcoins-energy-usage-explained/</ref>. Other blockchain designs have experienced different challenges. For example, the PoH network Solana suffered multiple single-point-failure incidents <ref>https://messari.io/report/solana-analyzing-downtimes-statistics-and-ecosystem-development</ref>. All protocols struggle to combat scaling challenges. All are susceptible to 51% attacks <ref>https://originstamp.com/blog/has-there-ever-been-a-51-attack-on-bitcoin/#notable-51-attacks</ref>.

Since 2009, Bitcoin has proven to be the strongest and least susceptible to common hacks <ref>https://www.theguardian.com/technology/2014/mar/18/history-of-bitcoin-hacks-alternative-currency</ref>. As the PoW puzzle difficulty has increased dramatically over the years, the probability of a 51% attack on the Bitcoin network becomes more difficult. PoS protocols can save more than 90% energy consumption compared to PoW chains. But PoS chains have higher risks than PoW chains since a stolen coin will grow in PoS chains (for increased probability to be selected) forever but not in PoW chains (only hash rates count). PoS community governance rules can mitigate the voting power centralization problem. Staking and slashing policies can incentivize good behaviors and punish bad ones. In either case, double-spend is very expensive and difficult. According to Forbes, there are 80 cryptocurrencies that use PoS protocols at the time of this writing.

There are approximately 1,000 blockchains in four types: public, private, consortium, and permissioned <ref>https://increditools.com/blockchains/</ref>.

== Cryptographic Proofs ==
Bitcoin 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.

== Centralized vs. Decentralized Applications ==
The Bitcoin protocol enabled decentralized processing of traditionally centrally processed transactions without any trusted third-party. It inspired many decentralized financial applications, especially for applications with very long payment chains. However for fraud prevention and meeting financial regulatory requirements, many practical applications still require KYC (know your customer) checks. It is not possible to eliminate all trusted third parties, especially for custodial financial applications. There is a clear need for decentralized processing of trusted authority applications.

== Blockchain Trilemma ==
Blockchain protocols have three common aspects (goals): '''security''', '''decentralization''' and '''scalability''' -- these three terms do not have precise definitions but are intuitively understood <ref>https://sensoriumxr.com/articles/what-is-the-blockchain-trilemma</ref>. To date, 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.

A major shortcoming is scalability. Since all nodes verify each transaction independently, they need to store all the information required for it. As the chain grows, this burdens all nodes in the network. There are workarounds by limiting the amount of data stored on some nodes and exploiting the network to retrieve required information, such as the ''Limited/Light Nodes'' in Bitcoin network. Vast majority nodes are still full nodes in the existing Bitcoin network. Transaction processing speed often expressed ''as transactions per second(TPS) of'' blockchain have to exceed TPS ratings of credit card payment systems like VISA or MasterCard to reap the full benefits of blockchain. This is a tough problem and increasing the block size and/or reducing the block time or difficulty isn't a solution<ref>https://medium.com/coinmonks/blockchain-scaling-30c9e1b7db1b</ref>. Since blockchain TPS is very low, the transaction fees is often very high. This discourages public adoption. Layer 2 solution like ''Lightning Network'' or ''ZK-rollups,'' where only final settlement is on the main chain tend to address these issues. However, one could always argue that this often compromises some aspects of security and/or decentralization to achieve high TPS.

The trilemma was first introduced by Vitalik Buterin<ref>https://en.wikipedia.org/wiki/Vitalik_Buterin</ref>, one of the co-founders of Ethereum network. The problems he identified are real. There seem to be no obvious solutions that can accomplish all three goals at the same time. Therefore, all proposed solutions revolve around reducing "opportunity costs" focusing only on satisfying partial goals.

Treating the blockchain network as an infrastructure for transaction processing, the blockchain protocol solved service reliability problem but not performance challenge. The legacy infrastructure scaling dilemma: performance against reliability remains (where "infrastructure reliability" also does not have a commonly accepted definition). Fortunately these metrics, although important, are non-critical. Solutions that have been proposed have had varying opportunity costs. For many years, there were no obvious solutions that addressed all three blockchain goals (security, decentralization and scalability).
== Statistic Multiplexed Computing (SMC) ==
The principle of using unreliable components to build an arbitrarily reliable system was first lectured by von Neumann in the early 1950s<ref>https://static.ias.edu/pitp/archive/2012files/Probabilistic_Logics.pdf</ref>. The original idea was to use probabilistic logic to quantify the arbitrary reliability of a system by multiplexing all components. This theory was applied to the construction of Internet protocols to deliver the "best effort" reliability. Ironically, "best effort reliability" also enabled "best effort" performance which in turn enabled unlimited scalability of the Internet. For emerging web3.0 technologies, it is important to apply the same methodology to both centralized and decentralized computing for seamless technology migration and integration. For historical arguments, click [[SMC|'''''here''''']].

== Definitions ==
'''Infrastructure scalability''' does not have a commonly accepted definition. It helps to define the challenging metrics more precisely before the infrastructure protocol design. In the following, for definitions #1 and #2, the word "'''infrastructure'''" means any '''application running on the infrastructure.'''

# '''Infrastructure Reliability''': MTBF (mean time between failure) = <math>\frac{\sum ((Start-Of-Downtime) - (Start-of-uptime)) }{No-of-failures}</math>
# '''Infrastructure Performance''': <math>\frac{No-of-Transactions}{Second}</math>
# '''Infrastructure Scalability''': Expanding the infrastructure in number of processors, networks or storage should have '''incrementally better''' impacts on application reliability and performance.
# '''Record Immutability''': For transaction ledgers, all confirmed records and changes are final. This is required by the blockchain protocol.
Note that in practice, record immutability is much harder to achieve than expected. There are two challenges, a) 51% attacks can literally wipe out all histories if successful, and b) for protocols require all nodes to hold independently verified ledger, such as the Bitcoin, the storage requirement grows approximately 50GB per month.

== 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 and considered.

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 crashe'''s <ref>https://groups.csail.mit.edu/tds/papers/Lynch/jacm93.pdf</ref>. The laws of physics regarding component reliability <ref>Encyclopedia of Physical Science and Technology, Editor-in-Chief Robert A. Meyers, [[index.php?title=Special:BookSources/9780122274107|ISBN 978-0-12-227410-7]], 2001</ref> show that '''100% component reliability is not possible.''' These facts require that the infrastructure protocol (program-program communication protocol) provide '''complete component (processing, networking and storage) decoupling''' from application program logics. This decoupling requirement forces the protocol to exploit "decentralized" or "stateless" components that the legacy infrastructure protocols, such as message passing interface (MPI), remote procedure call (RPC) and remote method invocation (RMI), cannot handle. The blockchain protocol is an example of a "best effort" availability protocol.

Quantifying infrastructure reliability can be traced back to the computer pioneer von Neumann. In addition to his contribution to computer architecture, von Neumann also penned a study on building reliable systems using unreliable components using probabilistic logics, in early fifties <ref>https://static.ias.edu/pitp/archive/2012files/Probabilistic_Logics.pdf</ref>. The 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 "best effort" reliability. Ironically, this best effort reliability also enabled the Internet's infinite scalability -- the benefit we enjoy now and into the future.

The Bitcoin protocol exploits multiple anonymous decoupled (or decentralized) computers connected through the Internet protocol. Judging from the Bitcoin network's reliability to date <ref>https://buybitcoinworldwide.com/bitcoin-downtime/</ref>, von Neumann's theory seems working well.

The '''second challenge''' involves infrastructure performance. Since the infrastructure must deploy multiple computing, networking and storage components, unless all components can be fully exploited at 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 lack this capability.

'''The infrastructure scalability challenge''' is automatically resolved once the performance challenge is resolved without negatively impacting reliability -- "best effort" performance" meets "best effort reliability". This requires inductive performance and reliability measures or deliveries.

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, an inductive statistic multiplexed blockchain protocol is needed to meet the scalability challenge. Non-inductive solutions such as fixed chain "sharding" or "Danksharding" <ref>https://ethereum.org/en/roadmap/danksharding/</ref> will only increase protocol development complexity with persistent performance walls.

== A Scalability Solution ==
An effective scalability solution can have two practical assumptions:

* The computation problem size can expand indefinitely, since every useful infrastructure is expected to solve bigger problems.

*Computing and network resources will continue to grow indefinitely, into the future.
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 <ref>https://en.wikipedia.org/wiki/Amdahl%27s_law</ref> and Gustafson's Law <ref>https://en.wikipedia.org/wiki/Gustafson%27s_law</ref>.

The Amdahl's Law assumes 0<= ''s'' <=1 percentage of serial instructions that cannot be parallelized. Then the ''(1-s)'' percentage of instructions can be accelerated using ''p'' processors.

<div style="text-align: center;">
Speedup(p) = <math>{1 \over s + {(1-s) \over p}}</math> (1) <br>Speedup(<math>\lim_{p \to \infty}</math>) = <math>\frac{1}{s}</math> (2)
</div>
Taking ''p'' to infinity in equation (1) yields equation (2). But this "scaling" step has two different operational semantics: a) increasing ''p'' for faster acceleration by reducing the value of (''1-s)/p'' solving the same problem. This will result ''s'' asymptotically approaching to 1. Thus the speedup is above bounded to 1. Or b) increasing ''p'' to increase the parallel instruction percentage ''(1-s)'' by solving bigger problems. This will force ''s'' asymptotically approach to 0. Then the speedup is unbounded <math>\infty</math>. This scaling ambiguity has caused more than half century of confusion in the community.

Although quantifying ''s'' requires defining the problem size, equations (1) and (2) are equally applicable to any programs solving any problem size with any percentage ''s''. The limit of speedup (2) also does not depend on problem size. However, since Amdahl originally used programs solving fixed problem sizes to argue the validity of not building parallel machines with too many processors, assuming fixed problem size using ''p'' processors has been the norm in interpreting Amdahl's law in the past. This assumption has led to the dismal speedup predictions.[[File:Amdahl's Law.png|thumb|Amdahl's Law Speedup Predictions|center]]The traditional Amdahl's Law interpretation seems to suggest parallel performances following the economic law of diminishing of returns, even though the mathematic model implies more potentials.

In 1988, Gustafson and Barsis at the Sandia National Laboratory conducted parallel computing experiments that seem to suggest potential infinite speedup.

Gustafson's Law was based on measured sequential and parallel elapsed times using ''p'' (=1024) processors. A new sequential percentage ''0<=x'<=1'' can be calculated using ''p'' processors. ''(1-x')'' is the parallel percentage using ''p'' processors.

To estimate accomplished speedup, Gustafson's Law states:

<div style="text-align: center;">
<math>Speedup=\frac{Tseq}{Tpar}=\frac{s'+(1-s')p}{1}=s'+(1-s')p </math> (3)
</div>

Scaling ''p'' to <math>\infty</math> for equation (3) cannot be done mathematically since ''s''' is dependent on the values of ''p''. For practical applications, the scaling action also has two operational semantics: a) Keep the problem size fixed, adding processors to further reduce the total parallel processing time, this will push for bigger s' asymptotically to 1. Thus speedup is also bounded to 1. Or b) expanding the problem size to allow the parallel part expanded solving bigger problems by simply multiplying (1-''s')'' by ''p (as shown in the chart below)''. Even though the following chart is mathematically incorrect, equation (3) can be translated to find the real serial percentage ''s'' under a single processor. Increasing ''p'' will force s asymptotically approaching to 0. Speedup will be above bounded to ''<math>\infty</math> by Amdahl's equation (2)''. For some reason, in late 1980's, Gustafson's Law was used to argue for Massively Parallel Computing (MPC) (or ManyCPU) experiments and Amdahl's Law was used to argue for bigger mainframe (or BigCPU) computer architectures. These laws have been used to support two diverging computing system experiments and constructions until recent convergence.
[[File:Gustafson.png|thumb|Gustafson's Law|center]]
It is now obvious that the two law are identical with Amdahl's Law more succinct. But Gustafson's formula helps to quantify the serial percentages from practical program executions. In fact, the two serial percentages can be related by a simple equation<ref>https://www.researchgate.net/publication/228367369_Reevaluating_Amdahl's_law_and_Gustafson's_law</ref>:

<div style="text-align: center;">
<math>s=\frac{s'}{s'+(1-s')p}</math> (4)
</div>

Both laws actually refer to the same mathematical abstraction. Gustafson's formula assists in quantifying the percentage of serial computing through parallel instrumentation. Amdahl's Law then delivers the ultimate predictions. This should have cleared the half-century myth about scaled-speedup and unscaled-speedup.

In practice, extracting parallelism from an algorithm to use more processors is much harder than simply expanding the already parallelized parts to solve bigger problems. This explanation can be validated in practice when developers routinely increasing the problem size to use more parallel processors.

[[File:Full Range Amdah's Law .png|alt=Full Power of Amdahl's Law|center|thumb|Full Power of Amdahl's Law]]

If we plot the full speedup curves against the number of processors, we will see the missing lines from the previous Amdahl's dismal prediction chart.

[[File:DiminishingReturn2.png|alt=infinite Speedup Under Amdahl's Law|center|thumb|Infinite Speedup in Amdahl's Law|400x400px]]

The TOP500 supercomputer competition provides another proof by a historical log of unrelenting computation power growths where the benchmarks (linear solvers) having no problem size limit. All manufacturers compete for the world's fastest supercomputer race <ref>https://www.top500.org/</ref> solving the largest possible problem that can be handled by the hardware. The follow chart illustrates the continuous speed improvements by year.
[[File:Supercomputers-history.png|center|thumb]]
In practical blockchain applications, the number of transactions to be processed will increase without a known limit. The ledger storage will continue to grow. In practice, the available computing, networking and storage components will continue to grow without bound enabled by the networking protocols. Therefore a statistic multiplexed computing blockchain can indeed meet any future application needs given proper economic incentives. The infrastructure no longer has the structural deficiency.

== Action Plan ==

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.

For Toichain protocol design, we choose Bitcoin 24.0.1 as the base line protocol by replacing the PoW consensus by PoS consensus and injecting SMC components into the protocol processing signaling for parallel computing.

This surprising result is also applicable to ledger storage. Without multiplexing, the blockchain ledger storage will eventually saturate all nodes causing the chain to collapse. The SMC blockchain protocol promises to hold the true finality of all transactions in perpetuity by multiplexing all storage resources while keeping the replication factor to a constant.

These discussions follow the inductive logic of the Law of Large Numbers <ref>https://www.sciencedirect.com/topics/mathematics/laws-of-large-number</ref>.

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

= SMC Proof of Stake Protocol =
Existing PoS protocol designs revolved around staking policies and randomness of the selection algorithm. Considering infrastructure scalability will add much complexity to the design. The examples include chain sharding and Danksharding <ref>https://ethereum.org/en/roadmap/danksharding/</ref>.

The challenge is complex -- we must deliver very high performance without compromising security and reliability of the network.

Technically, transaction replication and parallel processing were considered dangerous <ref>https://pages.cs.wisc.edu/~yxy/cs764-f20/papers/replication.pdf</ref> due to the potential race conditions (or double-spend problem). The blockchain protocol resolved the double-spending problem. It did not solve the parallel processing performance problem.

According to Professor Michael Flynn, there are three high-level parallel processing topologies: SIMD (single instruction multiple data), MIMD (multiple instructions multiple data), and pipeline (MISD - multiple instructions single data stream) <ref>https://link.springer.com/referenceworkentry/10.1007/978-0-387-09766-4_2</ref>. However, for eliminating double-spending, all transactions must be serialized, since each block may contain transactions affecting transactions in multiple other blocks. "Race conditions" and non-deterministic results are not allowed. Then the only possible topology entry is pipeline. This means for POS protocol, we must build a pipeline of transaction blocks to be validated without compromising network security and reliability.
[[File:Flynns-Taxonomy-of-Computer-Architectures.png|center|thumb|Parallel Processing Topologies]]
The problem is that the nature of the blockchain protocol is that all nodes run independently in parallel with little communication with other nodes via "gossip" protocols. It is far easier to force all nodes store the entire ledger than forcing them to form any pipeline and store partial chain data.

=== ACAN (Active Content Addressable Network) [U.S. PTO #11,588,926 B2, EPO #3539261] ===
ACAN is a high-level data '''''communication and synchronization protocol''''' with a SMC (statistic multiplexed computing) runtime that completely decouples all hardware components from communicating programs for network-scale high performance computing. The need for complete component decoupling was implemented in the original blockchain protocol via "gossip" protocol. This delivered blockchain's high availability and security. The simple "gossip" implementation in existing protocols is insufficient for parallel processing signaling.

The following figure illustrates the concept of ACAN (active content addressable networking) using UVR (unidirectional virtual ring) architecture. The illustrated implementation uses the Tuple Space resource tagging method and gossip protocol for UVR implementation.
[[File:SMC Architecture with ACAN.png|center|thumb|243x243px|SMC Architecture with ACAN]]

ACAN supports three simple APIs:

# '''read'''(&''key'', &''value''): ''key'' holds a search pattern in a "tuple space" where all nodes are connected. ''value'' holds the matched tuple, if any. This is a blocking call that a requesting program will be blocked until a pattern-matched tuple is found. The matching tuple remains in the "tuple space".
# '''get'''(&key, &value): Same as the "read()" API, except that the matching tuple is removed from the "tuple space".
# '''put'''(key, value): Inserts <key, value> into the "tuple space".

The use of "gossip" protocol can accelerate ACAN network saturation time. Applications running on ACAN will automatically form parallel processing topologies: pipeline, SIMD and MIMD without violating the serialization needs of transaction block validation. Replication factor can also be dynamically controlled to spread replicated blocks in randomly chosen hosts.

The highly parallel nature of the blockchain protocol will automatically implement the SMC principle in real time.

The critical feature of this dynamic SMC pipelined architecture is the inductive scaling feature.
[[File:Pipeline Parallel Processing.png|center|thumb|247x247px|Pipeline Parallel Processing]]

The speed up of a pipeline can be represented as: <math>SpeedUp = \left ( \frac{p\centerdot b}{p + (b-1)} \right )</math>, where p = number of processors in the pipeline, b = total blocks to be processed. Take the number of blocks to infinity:

<div style="text-align: center;">
<math>SpeedUp = \left ( \frac{p\centerdot b}{p + (b-1)} \right )=>\lim (b\Rightarrow\infty)(\frac{p}{\frac{p}{b}+1-\frac{1}{b}}) = p</math>
</div>

This means that as long as there are enough blocks to be processed, the entire chain's performance will be above bounded to the number of nodes in the pipeline.

For illustration purposes, the variation of block processing times was not considered in the above calculations. To see the power of pipeline parallelism, the automobile manufacturing processes illustrate a similar situation. The Hyundai Motor Company's production pipelines can produce 3,835 vehicles per day and 1.4M per year<ref>https://en.wikipedia.org/wiki/List_of_Hyundai_Motor_Company_manufacturing_facilities</ref>.

== Toichain Tokens ==
Toichain token is TOIN. There are 50,000,000,000 TOINs for the Alpha Release. There are air-drop tokens for early adopters, 1,000 TOIN each. Users need to register to download a toichain wallet to receive the payment. Citizenship is checked and verified to ensure that US citizens do not apply. The minimal staking contract is 10 TOINs.

== Non-Fungible Tokens ==
The TestNet Release of toichain protocol will support embedding arbitrary data in an "OP_RETURN" transaction that will be permanently recorded on the chain. Unlike the ordinal NFT <ref>https://blog.chain.link/ordinals-bitcoin-nfts/</ref> or NFT (non-fungible token) on other chains, these transactions cannot be altered or removed.

There are practical applications for these forever NFTs. Once Taproot is enabled on toichain, ordinal NFTs (BRC-20) will also be supported. Unlike the original Bitcoin network where BRC-20 craze has created massive network congestion<ref>https://beincrypto.com/learn/brc-20-token/</ref>, all transactions will be processed promptly in toichain without congestion or scaling problems.
== Toichain TestNet Launch ==
The toichain testnet launch will enable users to interact with one another through simple payments, just like the original Bitcoin network. Forever NFTs are supported. Smart contracts will be supported on a later date.

= References =
<references />

Consult the [[mediawikiwiki:Special:MyLanguage/Help:Contents|User's Guide]] for information on using the wiki software.

Main Page

2024-10-14T13:00:36Z

Justin: /* A Scalability Solution */

= <strong><big>'''Welcome to Toi-Twiki -- A Toichain Wiki'''</big></strong> =
This is the unofficial Toichain wiki site. Content is subject to changes.
---------------------------

= '''Introduction''' =
The blockchain protocol was introduced in a seminal paper entitled "Bitcoin: A peer-to-peer Electronic Cash System" <ref>https://bitcoin.org/bitcoin.pdf</ref> by Satoshi Nakamoto in 2008. Although there were previous peer-to-peer file-sharing projects such as Napster <ref>https://www.napster.com/us</ref>, BitTorrent <ref>https://www.bittorrent.com/</ref> and other electronic currency/file sharing applications, Bitcoin is the most enduring among the 23,000+ blockchains. Unlike other cryptocurrencies, the Bitcoin is often referred to as "digital gold" since the total coin supply is limited to 21 million (hard-coded in all running programs) and the only way to earn coin is to participate in the transaction block validation process. Token(or coin) supply and their disbursement policies differ among protocols.

The most attractive common blockchain features are 1) a decentralized consensus-driven decision making process and 2) a step-by-step cryptographic proving system. While blockchain is best known as a cryptocurrency transaction processing and record-keeping system, there are many other applications that can benefit from the secure storage, reliable transaction ledgers, fault tolerance and tamper resistance features.

== Algorithm vs. Protocol ==
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 ==
A good consensus protocol in a blockchain system has at least four properties:

# Fault tolerance to defend failures caused by natural disasters and human hacks or accidents
# Byzantine failure tolerance to defend exploitation by colluding parties
# Centralization avoidance to prevent corruptions in the decision making process
# Source code tamper resistance to automatically reject malicious attacks

Without assuming all nodes are active at all times, the blockchain relies on "gossip" protocol to communicate with other nodes. There are two popular types of consensus protocols: Proof of Work ('''PoW''') <ref>https://en.wikipedia.org/wiki/Proof_of_work</ref> or Proof of Stake ('''PoS''') <ref>https://www.investopedia.com/terms/p/proof-stake-pos.asp</ref>. Others include Proof of Possession('''PoP''')<ref>https://identityserver4.readthedocs.io/en/latest/topics/pop.html</ref> and Proof of History('''PoH''')<ref>https://www.infoworld.com/article/3666736/solana-blockchain-and-the-proof-of-history.html</ref>. The ultimate goal is to eliminate double-spending. Since most projects are open source, it's easy for a malicious actor to tamper a few nodes. This shouldn't compromise network integrity.

The Bitcoin network uses PoW which forces participating miners to compete for the fastest hashing rate by solving a computational cryptographic puzzle. Although it withstood more than 14 years of use, Bitcoin has been criticized for escalating electricity consumption <ref>https://www.forbes.com/advisor/investing/cryptocurrency/bitcoins-energy-usage-explained/</ref>. Other blockchain designs have experienced different challenges. For example, the PoH network Solana suffered multiple single-point-failure incidents <ref>https://messari.io/report/solana-analyzing-downtimes-statistics-and-ecosystem-development</ref>. All protocols struggle to combat scaling challenges. All are susceptible to 51% attacks <ref>https://originstamp.com/blog/has-there-ever-been-a-51-attack-on-bitcoin/#notable-51-attacks</ref>.

Since 2009, Bitcoin has proven to be the strongest and least susceptible to common hacks <ref>https://www.theguardian.com/technology/2014/mar/18/history-of-bitcoin-hacks-alternative-currency</ref>. As the PoW puzzle difficulty has increased dramatically over the years, the probability of a 51% attack on the Bitcoin network becomes more difficult. PoS protocols can save more than 90% energy consumption compared to PoW chains. But PoS chains have higher risks than PoW chains since a stolen coin will grow in PoS chains (for increased probability to be selected) forever but not in PoW chains (only hash rates count). PoS community governance rules can mitigate the voting power centralization problem. Staking and slashing policies can incentivize good behaviors and punish bad ones. In either case, double-spend is very expensive and difficult. According to Forbes, there are 80 cryptocurrencies that use PoS protocols at the time of this writing.

There are approximately 1,000 blockchains in four types: public, private, consortium, and permissioned <ref>https://increditools.com/blockchains/</ref>.

== Cryptographic Proofs ==
Bitcoin 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.

== Centralized vs. Decentralized Applications ==
The Bitcoin protocol enabled decentralized processing of traditionally centrally processed transactions without any trusted third-party. It inspired many decentralized financial applications, especially for applications with very long payment chains. However for fraud prevention and meeting financial regulatory requirements, many practical applications still require KYC (know your customer) checks. It is not possible to eliminate all trusted third parties, especially for custodial financial applications. There is a clear need for decentralized processing of trusted authority applications.

== Blockchain Trilemma ==
Blockchain protocols have three common aspects (goals): '''security''', '''decentralization''' and '''scalability''' -- these three terms do not have precise definitions but are intuitively understood <ref>https://sensoriumxr.com/articles/what-is-the-blockchain-trilemma</ref>. To date, 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.

A major shortcoming is scalability. Since all nodes verify each transaction independently, they need to store all the information required for it. As the chain grows, this burdens all nodes in the network. There are workarounds by limiting the amount of data stored on some nodes and exploiting the network to retrieve required information, such as the ''Limited/Light Nodes'' in Bitcoin network. Vast majority nodes are still full nodes in the existing Bitcoin network. Transaction processing speed often expressed ''as transactions per second(TPS) of'' blockchain have to exceed TPS ratings of credit card payment systems like VISA or MasterCard to reap the full benefits of blockchain. This is a tough problem and increasing the block size and/or reducing the block time or difficulty isn't a solution<ref>https://medium.com/coinmonks/blockchain-scaling-30c9e1b7db1b</ref>. Since blockchain TPS is very low, the transaction fees is often very high. This discourages public adoption. Layer 2 solution like ''Lightning Network'' or ''ZK-rollups,'' where only final settlement is on the main chain tend to address these issues. However, one could always argue that this often compromises some aspects of security and/or decentralization to achieve high TPS.

The trilemma was first introduced by Vitalik Buterin<ref>https://en.wikipedia.org/wiki/Vitalik_Buterin</ref>, one of the co-founders of Ethereum network. The problems he identified are real. There seem to be no obvious solutions that can accomplish all three goals at the same time. Therefore, all proposed solutions revolve around reducing "opportunity costs" focusing only on satisfying partial goals.

Treating the blockchain network as an infrastructure for transaction processing, the blockchain protocol solved service reliability problem but not performance challenge. The legacy infrastructure scaling dilemma: performance against reliability remains (where "infrastructure reliability" also does not have a commonly accepted definition). Fortunately these metrics, although important, are non-critical. Solutions that have been proposed have had varying opportunity costs. For many years, there were no obvious solutions that addressed all three blockchain goals (security, decentralization and scalability).
== Statistic Multiplexed Computing (SMC) ==
The principle of using unreliable components to build an arbitrarily reliable system was first lectured by von Neumann in the early 1950s<ref>https://static.ias.edu/pitp/archive/2012files/Probabilistic_Logics.pdf</ref>. The original idea was to use probabilistic logic to quantify the arbitrary reliability of a system by multiplexing all components. This theory was applied to the construction of Internet protocols to deliver the "best effort" reliability. Incidentally, best effort reliability also enabled "best effort" performance which in turn enabled unlimited scalability of the Internet. For emerging web3.0 technologies, it is important to apply the same methodology to both centralized and decentralized computing for seamless technology migration and integration. For historical arguments, click [[SMC|'''''here''''']].

== Definitions ==
'''Infrastructure scalability''' does not have a commonly accepted definition. It helps to define the challenging metrics more precisely before the infrastructure protocol design. In the following, for definitions #1 and #2, the word "'''infrastructure'''" means any '''application running on the infrastructure.'''

# '''Infrastructure Reliability''': MTBF (mean time between failure) = <math>\frac{\sum ((Start-Of-Downtime) - (Start-of-uptime)) }{No-of-failures}</math>
# '''Infrastructure Performance''': <math>\frac{No-of-Transactions}{Second}</math>
# '''Infrastructure Scalability''': Expanding the infrastructure in number of processors, networks or storage should have '''incrementally better''' impacts on application reliability and performance.
# '''Record Immutability''': For transaction ledgers, all confirmed records and changes are final. This is required by the blockchain protocol.
Note that in practice, record immutability is much harder to achieve than expected. There are two challenges, a) 51% attacks can literally wipe out all histories if successful, and b) for protocols require all nodes to hold independently verified ledger, such as the Bitcoin, the storage requirement grows approximately 50GB per month.

== 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 and considered.

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 crashe'''s <ref>https://groups.csail.mit.edu/tds/papers/Lynch/jacm93.pdf</ref>. The laws of physics regarding component reliability <ref>Encyclopedia of Physical Science and Technology, Editor-in-Chief Robert A. Meyers, [[index.php?title=Special:BookSources/9780122274107|ISBN 978-0-12-227410-7]], 2001</ref> show that '''100% component reliability is not possible.''' These facts require that the infrastructure protocol (program-program communication protocol) provide '''complete component (processing, networking and storage) decoupling''' from application program logics. This decoupling requirement forces the protocol to exploit "decentralized" or "stateless" components that the legacy infrastructure protocols, such as message passing interface (MPI), remote procedure call (RPC) and remote method invocation (RMI), cannot handle. The blockchain protocol is an example of a "best effort" availability protocol.

Quantifying infrastructure reliability can be traced back to the computer pioneer von Neumann. In addition to his contribution to computer architecture, von Neumann also penned a study on building reliable systems using unreliable components using probabilistic logics, in early fifties <ref>https://static.ias.edu/pitp/archive/2012files/Probabilistic_Logics.pdf</ref>. The 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 "best effort" reliability. Ironically, this best effort reliability also enabled the Internet's infinite scalability -- the benefit we enjoy now and into the future.

The Bitcoin protocol exploits multiple anonymous decoupled (or decentralized) computers connected through the Internet protocol. Judging from the Bitcoin network's reliability to date <ref>https://buybitcoinworldwide.com/bitcoin-downtime/</ref>, von Neumann's theory seems working well.

The '''second challenge''' involves infrastructure performance. Since the infrastructure must deploy multiple computing, networking and storage components, unless all components can be fully exploited at 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 lack this capability.

'''The infrastructure scalability challenge''' is automatically resolved once the performance challenge is resolved without negatively impacting reliability -- "best effort" performance" meets "best effort reliability". This requires inductive performance and reliability measures or deliveries.

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, an inductive statistic multiplexed blockchain protocol is needed to meet the scalability challenge. Non-inductive solutions such as fixed chain "sharding" or "Danksharding" <ref>https://ethereum.org/en/roadmap/danksharding/</ref> will only increase protocol development complexity with persistent performance walls.

== A Scalability Solution ==
An effective scalability solution can have two practical assumptions:

* The computation problem size can expand indefinitely, since every useful infrastructure is expected to solve bigger problems.

*Computing and network resources will continue to grow indefinitely, into the future.
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 <ref>https://en.wikipedia.org/wiki/Amdahl%27s_law</ref> and Gustafson's Law <ref>https://en.wikipedia.org/wiki/Gustafson%27s_law</ref>.

The Amdahl's Law assumes 0<= ''s'' <=1 percentage of serial instructions that cannot be parallelized. Then the ''(1-s)'' percentage of instructions can be accelerated using ''p'' processors.

<div style="text-align: center;">
Speedup(p) = <math>{1 \over s + {(1-s) \over p}}</math> (1) <br>Speedup(<math>\lim_{p \to \infty}</math>) = <math>\frac{1}{s}</math> (2)
</div>
Taking ''p'' to infinity in equation (1) yields equation (2). But this "scaling" step has two different operational semantics: a) increasing ''p'' for faster acceleration by reducing the value of (''1-s)/p'' solving the same problem. This will result ''s'' asymptotically approaching to 1. Thus the speedup is above bounded to 1. Or b) increasing ''p'' to increase the parallel instruction percentage ''(1-s)'' by solving bigger problems. This will force ''s'' asymptotically approach to 0. Then the speedup is unbounded <math>\infty</math>. This scaling ambiguity has caused more than half century of confusion in the community.

Although quantifying ''s'' requires defining the problem size, equations (1) and (2) are equally applicable to any programs solving any problem size with any percentage ''s''. The limit of speedup (2) also does not depend on problem size. However, since Amdahl originally used programs solving fixed problem sizes to argue the validity of not building parallel machines with too many processors, assuming fixed problem size using ''p'' processors has been the norm in interpreting Amdahl's law in the past. This assumption has led to the dismal speedup predictions.[[File:Amdahl's Law.png|thumb|Amdahl's Law Speedup Predictions|center]]The traditional Amdahl's Law interpretation seems to suggest parallel performances following the economic law of diminishing of returns, even though the mathematic model implies more potentials.

In 1988, Gustafson and Barsis at the Sandia National Laboratory conducted parallel computing experiments that seem to suggest potential infinite speedup.

Gustafson's Law was based on measured sequential and parallel elapsed times using ''p'' (=1024) processors. A new sequential percentage ''0<=x'<=1'' can be calculated using ''p'' processors. ''(1-x')'' is the parallel percentage using ''p'' processors.

To estimate accomplished speedup, Gustafson's Law states:

<div style="text-align: center;">
<math>Speedup=\frac{Tseq}{Tpar}=\frac{s'+(1-s')p}{1}=s'+(1-s')p </math> (3)
</div>

Scaling ''p'' to <math>\infty</math> for equation (3) cannot be done mathematically since ''s''' is dependent on the values of ''p''. For practical applications, the scaling action also has two operational semantics: a) Keep the problem size fixed, adding processors to further reduce the total parallel processing time, this will push for bigger s' asymptotically to 1. Thus speedup is also bounded to 1. Or b) expanding the problem size to allow the parallel part expanded solving bigger problems by simply multiplying (1-''s')'' by ''p (as shown in the chart below)''. Even though the following chart is mathematically incorrect, equation (3) can be translated to find the real serial percentage ''s'' under a single processor. Increasing ''p'' will force s asymptotically approaching to 0. Speedup will be above bounded to ''<math>\infty</math> by Amdahl's equation (2)''. For some reason, in late 1980's, Gustafson's Law was used to argue for Massively Parallel Computing (MPC) (or ManyCPU) experiments and Amdahl's Law was used to argue for bigger mainframe (or BigCPU) computer architectures. These laws have been used to support two diverging computing system experiments and constructions until recent convergence.
[[File:Gustafson.png|thumb|Gustafson's Law|center]]
It is now obvious that the two law are identical with Amdahl's Law more succinct. But Gustafson's formula helps to quantify the serial percentages from practical program executions. In fact, the two serial percentages can be related by a simple equation<ref>https://www.researchgate.net/publication/228367369_Reevaluating_Amdahl's_law_and_Gustafson's_law</ref>:

<div style="text-align: center;">
<math>s=\frac{s'}{s'+(1-s')p}</math> (4)
</div>

Both laws actually refer to the same mathematical abstraction. Gustafson's formula assists in quantifying the percentage of serial computing through parallel instrumentation. Amdahl's Law then delivers the ultimate predictions. This should have cleared the half-century myth about scaled-speedup and unscaled-speedup.

In practice, extracting parallelism from an algorithm to use more processors is much harder than simply expanding the already parallelized parts to solve bigger problems. This explanation can be validated in practice when developers routinely increasing the problem size to use more parallel processors.

[[File:Full Range Amdah's Law .png|alt=Full Power of Amdahl's Law|center|thumb|Full Power of Amdahl's Law]]

If we plot the full speedup curves against the number of processors, we will see the missing lines from the previous Amdahl's dismal prediction chart.

[[File:DiminishingReturn2.png|alt=infinite Speedup Under Amdahl's Law|center|thumb|Infinite Speedup in Amdahl's Law|400x400px]]

The TOP500 supercomputer competition provides another proof by a historical log of unrelenting computation power growths where the benchmarks (linear solvers) having no problem size limit. All manufacturers compete for the world's fastest supercomputer race <ref>https://www.top500.org/</ref> solving the largest possible problem that can be handled by the hardware. The follow chart illustrates the continuous speed improvements by year.
[[File:Supercomputers-history.png|center|thumb]]
In practical blockchain applications, the number of transactions to be processed will increase without a known limit. The ledger storage will continue to grow. In practice, the available computing, networking and storage components will continue to grow without bound enabled by the networking protocols. Therefore a statistic multiplexed computing blockchain can indeed meet any future application needs given proper economic incentives. The infrastructure no longer has the structural deficiency.

== Action Plan ==

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.

For Toichain protocol design, we choose Bitcoin 24.0.1 as the base line protocol by replacing the PoW consensus by PoS consensus and injecting SMC components into the protocol processing signaling for parallel computing.

This surprising result is also applicable to ledger storage. Without multiplexing, the blockchain ledger storage will eventually saturate all nodes causing the chain to collapse. The SMC blockchain protocol promises to hold the true finality of all transactions in perpetuity by multiplexing all storage resources while keeping the replication factor to a constant.

These discussions follow the inductive logic of the Law of Large Numbers <ref>https://www.sciencedirect.com/topics/mathematics/laws-of-large-number</ref>.

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

= SMC Proof of Stake Protocol =
Existing PoS protocol designs revolved around staking policies and randomness of the selection algorithm. Considering infrastructure scalability will add much complexity to the design. The examples include chain sharding and Danksharding <ref>https://ethereum.org/en/roadmap/danksharding/</ref>.

The challenge is complex -- we must deliver very high performance without compromising security and reliability of the network.

Technically, transaction replication and parallel processing were considered dangerous <ref>https://pages.cs.wisc.edu/~yxy/cs764-f20/papers/replication.pdf</ref> due to the potential race conditions (or double-spend problem). The blockchain protocol resolved the double-spending problem. It did not solve the parallel processing performance problem.

According to Professor Michael Flynn, there are three high-level parallel processing topologies: SIMD (single instruction multiple data), MIMD (multiple instructions multiple data), and pipeline (MISD - multiple instructions single data stream) <ref>https://link.springer.com/referenceworkentry/10.1007/978-0-387-09766-4_2</ref>. However, for eliminating double-spending, all transactions must be serialized, since each block may contain transactions affecting transactions in multiple other blocks. "Race conditions" and non-deterministic results are not allowed. Then the only possible topology entry is pipeline. This means for POS protocol, we must build a pipeline of transaction blocks to be validated without compromising network security and reliability.
[[File:Flynns-Taxonomy-of-Computer-Architectures.png|center|thumb|Parallel Processing Topologies]]
The problem is that the nature of the blockchain protocol is that all nodes run independently in parallel with little communication with other nodes via "gossip" protocols. It is far easier to force all nodes store the entire ledger than forcing them to form any pipeline and store partial chain data.

=== ACAN (Active Content Addressable Network) [U.S. PTO #11,588,926 B2, EPO #3539261] ===
ACAN is a high-level data '''''communication and synchronization protocol''''' with a SMC (statistic multiplexed computing) runtime that completely decouples all hardware components from communicating programs for network-scale high performance computing. The need for complete component decoupling was implemented in the original blockchain protocol via "gossip" protocol. This delivered blockchain's high availability and security. The simple "gossip" implementation in existing protocols is insufficient for parallel processing signaling.

The following figure illustrates the concept of ACAN (active content addressable networking) using UVR (unidirectional virtual ring) architecture. The illustrated implementation uses the Tuple Space resource tagging method and gossip protocol for UVR implementation.
[[File:SMC Architecture with ACAN.png|center|thumb|243x243px|SMC Architecture with ACAN]]

ACAN supports three simple APIs:

# '''read'''(&''key'', &''value''): ''key'' holds a search pattern in a "tuple space" where all nodes are connected. ''value'' holds the matched tuple, if any. This is a blocking call that a requesting program will be blocked until a pattern-matched tuple is found. The matching tuple remains in the "tuple space".
# '''get'''(&key, &value): Same as the "read()" API, except that the matching tuple is removed from the "tuple space".
# '''put'''(key, value): Inserts <key, value> into the "tuple space".

The use of "gossip" protocol can accelerate ACAN network saturation time. Applications running on ACAN will automatically form parallel processing topologies: pipeline, SIMD and MIMD without violating the serialization needs of transaction block validation. Replication factor can also be dynamically controlled to spread replicated blocks in randomly chosen hosts.

The highly parallel nature of the blockchain protocol will automatically implement the SMC principle in real time.

The critical feature of this dynamic SMC pipelined architecture is the inductive scaling feature.
[[File:Pipeline Parallel Processing.png|center|thumb|247x247px|Pipeline Parallel Processing]]

The speed up of a pipeline can be represented as: <math>SpeedUp = \left ( \frac{p\centerdot b}{p + (b-1)} \right )</math>, where p = number of processors in the pipeline, b = total blocks to be processed. Take the number of blocks to infinity:

<div style="text-align: center;">
<math>SpeedUp = \left ( \frac{p\centerdot b}{p + (b-1)} \right )=>\lim (b\Rightarrow\infty)(\frac{p}{\frac{p}{b}+1-\frac{1}{b}}) = p</math>
</div>

This means that as long as there are enough blocks to be processed, the entire chain's performance will be above bounded to the number of nodes in the pipeline.

For illustration purposes, the variation of block processing times was not considered in the above calculations. To see the power of pipeline parallelism, the automobile manufacturing processes illustrate a similar situation. The Hyundai Motor Company's production pipelines can produce 3,835 vehicles per day and 1.4M per year<ref>https://en.wikipedia.org/wiki/List_of_Hyundai_Motor_Company_manufacturing_facilities</ref>.

== Toichain Tokens ==
Toichain token is TOIN. There are 50,000,000,000 TOINs for the Alpha Release. There are air-drop tokens for early adopters, 1,000 TOIN each. Users need to register to download a toichain wallet to receive the payment. Citizenship is checked and verified to ensure that US citizens do not apply. The minimal staking contract is 10 TOINs.

== Non-Fungible Tokens ==
The TestNet Release of toichain protocol will support embedding arbitrary data in an "OP_RETURN" transaction that will be permanently recorded on the chain. Unlike the ordinal NFT <ref>https://blog.chain.link/ordinals-bitcoin-nfts/</ref> or NFT (non-fungible token) on other chains, these transactions cannot be altered or removed.

There are practical applications for these forever NFTs. Once Taproot is enabled on toichain, ordinal NFTs (BRC-20) will also be supported. Unlike the original Bitcoin network where BRC-20 craze has created massive network congestion<ref>https://beincrypto.com/learn/brc-20-token/</ref>, all transactions will be processed promptly in toichain without congestion or scaling problems.
== Toichain TestNet Launch ==
The toichain testnet launch will enable users to interact with one another through simple payments, just like the original Bitcoin network. Forever NFTs are supported. Smart contracts will be supported on a later date.

= References =
<references />

Consult the [[mediawikiwiki:Special:MyLanguage/Help:Contents|User's Guide]] for information on using the wiki software.

Main Page

2024-10-13T18:06:23Z

Justin: /* ACAN (Active Content Addressable Network) [U.S. PTO #11,588,926 B2, EPO #3539261] */

= <strong><big>'''Welcome to Toi-Twiki -- A Toichain Wiki'''</big></strong> =
This is the unofficial Toichain wiki site. Content is subject to changes.
---------------------------

= '''Introduction''' =
The blockchain protocol was introduced in a seminal paper entitled "Bitcoin: A peer-to-peer Electronic Cash System" <ref>https://bitcoin.org/bitcoin.pdf</ref> by Satoshi Nakamoto in 2008. Although there were previous peer-to-peer file-sharing projects such as Napster <ref>https://www.napster.com/us</ref>, BitTorrent <ref>https://www.bittorrent.com/</ref> and other electronic currency/file sharing applications, Bitcoin is the most enduring among the 23,000+ blockchains. Unlike other cryptocurrencies, the Bitcoin is often referred to as "digital gold" since the total coin supply is limited to 21 million (hard-coded in all running programs) and the only way to earn coin is to participate in the transaction block validation process. Token(or coin) supply and their disbursement policies differ among protocols.

The most attractive common blockchain features are 1) a decentralized consensus-driven decision making process and 2) a step-by-step cryptographic proving system. While blockchain is best known as a cryptocurrency transaction processing and record-keeping system, there are many other applications that can benefit from the secure storage, reliable transaction ledgers, fault tolerance and tamper resistance features.

== Algorithm vs. Protocol ==
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 ==
A good consensus protocol in a blockchain system has at least four properties:

# Fault tolerance to defend failures caused by natural disasters and human hacks or accidents
# Byzantine failure tolerance to defend exploitation by colluding parties
# Centralization avoidance to prevent corruptions in the decision making process
# Source code tamper resistance to automatically reject malicious attacks

Without assuming all nodes are active at all times, the blockchain relies on "gossip" protocol to communicate with other nodes. There are two popular types of consensus protocols: Proof of Work ('''PoW''') <ref>https://en.wikipedia.org/wiki/Proof_of_work</ref> or Proof of Stake ('''PoS''') <ref>https://www.investopedia.com/terms/p/proof-stake-pos.asp</ref>. Others include Proof of Possession('''PoP''')<ref>https://identityserver4.readthedocs.io/en/latest/topics/pop.html</ref> and Proof of History('''PoH''')<ref>https://www.infoworld.com/article/3666736/solana-blockchain-and-the-proof-of-history.html</ref>. The ultimate goal is to eliminate double-spending. Since most projects are open source, it's easy for a malicious actor to tamper a few nodes. This shouldn't compromise network integrity.

The Bitcoin network uses PoW which forces participating miners to compete for the fastest hashing rate by solving a computational cryptographic puzzle. Although it withstood more than 14 years of use, Bitcoin has been criticized for escalating electricity consumption <ref>https://www.forbes.com/advisor/investing/cryptocurrency/bitcoins-energy-usage-explained/</ref>. Other blockchain designs have experienced different challenges. For example, the PoH network Solana suffered multiple single-point-failure incidents <ref>https://messari.io/report/solana-analyzing-downtimes-statistics-and-ecosystem-development</ref>. All protocols struggle to combat scaling challenges. All are susceptible to 51% attacks <ref>https://originstamp.com/blog/has-there-ever-been-a-51-attack-on-bitcoin/#notable-51-attacks</ref>.

Since 2009, Bitcoin has proven to be the strongest and least susceptible to common hacks <ref>https://www.theguardian.com/technology/2014/mar/18/history-of-bitcoin-hacks-alternative-currency</ref>. As the PoW puzzle difficulty has increased dramatically over the years, the probability of a 51% attack on the Bitcoin network becomes more difficult. PoS protocols can save more than 90% energy consumption compared to PoW chains. But PoS chains have higher risks than PoW chains since a stolen coin will grow in PoS chains (for increased probability to be selected) forever but not in PoW chains (only hash rates count). PoS community governance rules can mitigate the voting power centralization problem. Staking and slashing policies can incentivize good behaviors and punish bad ones. In either case, double-spend is very expensive and difficult. According to Forbes, there are 80 cryptocurrencies that use PoS protocols at the time of this writing.

There are approximately 1,000 blockchains in four types: public, private, consortium, and permissioned <ref>https://increditools.com/blockchains/</ref>.

== Cryptographic Proofs ==
Bitcoin 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.

== Centralized vs. Decentralized Applications ==
The Bitcoin protocol enabled decentralized processing of traditionally centrally processed transactions without any trusted third-party. It inspired many decentralized financial applications, especially for applications with very long payment chains. However for fraud prevention and meeting financial regulatory requirements, many practical applications still require KYC (know your customer) checks. It is not possible to eliminate all trusted third parties, especially for custodial financial applications. There is a clear need for decentralized processing of trusted authority applications.

== Blockchain Trilemma ==
Blockchain protocols have three common aspects (goals): '''security''', '''decentralization''' and '''scalability''' -- these three terms do not have precise definitions but are intuitively understood <ref>https://sensoriumxr.com/articles/what-is-the-blockchain-trilemma</ref>. To date, 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.

A major shortcoming is scalability. Since all nodes verify each transaction independently, they need to store all the information required for it. As the chain grows, this burdens all nodes in the network. There are workarounds by limiting the amount of data stored on some nodes and exploiting the network to retrieve required information, such as the ''Limited/Light Nodes'' in Bitcoin network. Vast majority nodes are still full nodes in the existing Bitcoin network. Transaction processing speed often expressed ''as transactions per second(TPS) of'' blockchain have to exceed TPS ratings of credit card payment systems like VISA or MasterCard to reap the full benefits of blockchain. This is a tough problem and increasing the block size and/or reducing the block time or difficulty isn't a solution<ref>https://medium.com/coinmonks/blockchain-scaling-30c9e1b7db1b</ref>. Since blockchain TPS is very low, the transaction fees is often very high. This discourages public adoption. Layer 2 solution like ''Lightning Network'' or ''ZK-rollups,'' where only final settlement is on the main chain tend to address these issues. However, one could always argue that this often compromises some aspects of security and/or decentralization to achieve high TPS.

The trilemma was first introduced by Vitalik Buterin<ref>https://en.wikipedia.org/wiki/Vitalik_Buterin</ref>, one of the co-founders of Ethereum network. The problems he identified are real. There seem to be no obvious solutions that can accomplish all three goals at the same time. Therefore, all proposed solutions revolve around reducing "opportunity costs" focusing only on satisfying partial goals.

Treating the blockchain network as an infrastructure for transaction processing, the blockchain protocol solved service reliability problem but not performance challenge. The legacy infrastructure scaling dilemma: performance against reliability remains (where "infrastructure reliability" also does not have a commonly accepted definition). Fortunately these metrics, although important, are non-critical. Solutions that have been proposed have had varying opportunity costs. For many years, there were no obvious solutions that addressed all three blockchain goals (security, decentralization and scalability).
== Statistic Multiplexed Computing (SMC) ==
The principle of using unreliable components to build an arbitrarily reliable system was first lectured by von Neumann in the early 1950s<ref>https://static.ias.edu/pitp/archive/2012files/Probabilistic_Logics.pdf</ref>. The original idea was to use probabilistic logic to quantify the arbitrary reliability of a system by multiplexing all components. This theory was applied to the construction of Internet protocols to deliver the "best effort" reliability. Incidentally, best effort reliability also enabled "best effort" performance which in turn enabled unlimited scalability of the Internet. For emerging web3.0 technologies, it is important to apply the same methodology to both centralized and decentralized computing for seamless technology migration and integration. For historical arguments, click [[SMC|'''''here''''']].

== Definitions ==
'''Infrastructure scalability''' does not have a commonly accepted definition. It helps to define the challenging metrics more precisely before the infrastructure protocol design. In the following, for definitions #1 and #2, the word "'''infrastructure'''" means any '''application running on the infrastructure.'''

# '''Infrastructure Reliability''': MTBF (mean time between failure) = <math>\frac{\sum ((Start-Of-Downtime) - (Start-of-uptime)) }{No-of-failures}</math>
# '''Infrastructure Performance''': <math>\frac{No-of-Transactions}{Second}</math>
# '''Infrastructure Scalability''': Expanding the infrastructure in number of processors, networks or storage should have '''incrementally better''' impacts on application reliability and performance.
# '''Record Immutability''': For transaction ledgers, all confirmed records and changes are final. This is required by the blockchain protocol.
Note that in practice, record immutability is much harder to achieve than expected. There are two challenges, a) 51% attacks can literally wipe out all histories if successful, and b) for protocols require all nodes to hold independently verified ledger, such as the Bitcoin, the storage requirement grows approximately 50GB per month.

== 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 and considered.

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 crashe'''s <ref>https://groups.csail.mit.edu/tds/papers/Lynch/jacm93.pdf</ref>. The laws of physics regarding component reliability <ref>Encyclopedia of Physical Science and Technology, Editor-in-Chief Robert A. Meyers, [[index.php?title=Special:BookSources/9780122274107|ISBN 978-0-12-227410-7]], 2001</ref> show that '''100% component reliability is not possible.''' These facts require that the infrastructure protocol (program-program communication protocol) provide '''complete component (processing, networking and storage) decoupling''' from application program logics. This decoupling requirement forces the protocol to exploit "decentralized" or "stateless" components that the legacy infrastructure protocols, such as message passing interface (MPI), remote procedure call (RPC) and remote method invocation (RMI), cannot handle. The blockchain protocol is an example of a "best effort" availability protocol.

Quantifying infrastructure reliability can be traced back to the computer pioneer von Neumann. In addition to his contribution to computer architecture, von Neumann also penned a study on building reliable systems using unreliable components using probabilistic logics, in early fifties <ref>https://static.ias.edu/pitp/archive/2012files/Probabilistic_Logics.pdf</ref>. The 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 "best effort" reliability. Ironically, this best effort reliability also enabled the Internet's infinite scalability -- the benefit we enjoy now and into the future.

The Bitcoin protocol exploits multiple anonymous decoupled (or decentralized) computers connected through the Internet protocol. Judging from the Bitcoin network's reliability to date <ref>https://buybitcoinworldwide.com/bitcoin-downtime/</ref>, von Neumann's theory seems working well.

The '''second challenge''' involves infrastructure performance. Since the infrastructure must deploy multiple computing, networking and storage components, unless all components can be fully exploited at 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 lack this capability.

'''The infrastructure scalability challenge''' is automatically resolved once the performance challenge is resolved without negatively impacting reliability -- "best effort" performance" meets "best effort reliability". This requires inductive performance and reliability measures or deliveries.

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, an inductive statistic multiplexed blockchain protocol is needed to meet the scalability challenge. Non-inductive solutions such as fixed chain "sharding" or "Danksharding" <ref>https://ethereum.org/en/roadmap/danksharding/</ref> will only increase protocol development complexity with persistent performance walls.

== A Scalability Solution ==
An effective scalability solution can have two practical assumptions:

* The computation problem size can expand indefinitely, since every useful infrastructure is expected to solve bigger problems.

*Computing and network resources will continue to grow indefinitely, into the future.
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 <ref>https://en.wikipedia.org/wiki/Amdahl%27s_law</ref> and Gustafson's Law <ref>https://en.wikipedia.org/wiki/Gustafson%27s_law</ref>.

The Amdahl's Law assumes 0<= ''s'' <=1 percentage of serial instructions that cannot be parallelized. Then the ''(1-s)'' percentage of instructions can be accelerated using ''p'' processors.

<div style="text-align: center;">
Speedup(p) = <math>{1 \over s + {(1-s) \over p}}</math> (1) <br>Speedup(<math>\lim_{p \to \infty}</math>) = <math>\frac{1}{s}</math> (2)
</div>
Taking ''p'' to infinity in equation (1) yields equation (2). But this "scaling" step has two different operational semantics: a) increasing ''p'' for faster acceleration by reducing the value of (''1-s)/p'' solving the same problem. This will result ''s'' asymptotically approaching 1. Thus the speedup is above bounded to 1. Or b) increasing ''p'' to increase the parallel instruction percentage ''(1-s)'' by solving bigger problems. This will force ''s'' asymptotically approach 0. Then the speedup is above bounded by <math>\infty</math>. This scaling ambiguity has caused more than half century of confusion in the community.

Although quantifying ''s'' requires defining the problem size, the model (1) and (2) are applicable to programs solving any problem size with any percentage ''s''. The limit of speedup (2) also does not depend on problem size. However, since Amdahl originally used programs solving fixed problem sizes to argue the validity of not building parallel machines with too many processors, assuming fixed problem size using ''p'' processors has been the norm in interpreting Amdahl's law in the past. This assumption has led to the dismal speedup predictions.[[File:Amdahl's Law.png|thumb|Amdahl's Law Speedup Predictions|center]]The traditional Amdahl's Law interpretation seems to suggest parallel performances following the economic law of diminishing of returns, even though the mathematic model implies more potentials.

In 1988, Gustafson and Barsis at the Sandia National Laboratory conducted parallel computing experiments that seem to suggest potential infinite speedup.

Gustafson's Law was based on measured sequential and parallel elapsed times using ''p'' (=1024) processors. A new sequential percentage ''0<=x'<=1'' can be calculated using ''p'' processors. ''(1-x')'' is the parallel percentage using ''p'' processors.

To estimate accomplished speedup, Gustafson's Law states:

<div style="text-align: center;">
<math>Speedup=\frac{Tseq}{Tpar}=\frac{s'+(1-s')p}{1}=s'+(1-s')p </math> (3)
</div>

Scaling ''p'' to <math>\infty</math> for equation (3) cannot be done mathematically since ''s''' is dependent on the values of ''p''. And the scaling action also has two operational semantics: a) Keep the problem size fixed, adding processors to further reduce the total parallel processing time, this will push for bigger s'. This will make s' systematically approach 1. Thus speedup is also bounded to 1. Or b) expanding the problem size to allow the parallel part expanded solving bigger problems by simply multiplying (1-''s')'' by ''p (as shown in the chart below)''. This will force the real serial percentage ''s'' under a single processor asymptotically approaching 0. Speedup will be above bounded to ''<math>\infty</math> by Amdahl's equation (2)''. For some reason, in late 1980's, Gustafson's Law was used to argue for Massively Parallel Computing (MPC) (or ManyCPU) experiments and Amdahl's Law was used to argue for bigger mainframe (or BigCPU) computer architectures. These laws have been used to support two diverging computing system experiments and constructions until recent convergence.
[[File:Gustafson.png|thumb|Gustafson's Law|center]]
It is now obvious that the two law are identical with Amdahl's Law more succinct. But Gustafson's formula helps to quantify the serial percentages from practical program executions. In fact, the two serial percentages can be related by a simple equation<ref>https://www.researchgate.net/publication/228367369_Reevaluating_Amdahl's_law_and_Gustafson's_law</ref>:

<div style="text-align: center;">
<math>s=\frac{s'}{s'+(1-s')p}</math> (4)
</div>

Both laws actually refer to the same mathematical abstraction. Gustafson's formula assists in quantifying the percentage of serial computing through program experiments. Amdahl's Law delivers the ultimate predictions. This should have cleared the half-century myth about scaled-speedup and unscaled speedup.

In practice, extracting parallelism from an algorithm to use more processors is much harder than simply expanding the already parallelized parts to solve bigger problems. This explanation can be validated in practice when developers routinely increasing the problem size to use more parallel processors.

[[File:Full Range Amdah's Law .png|alt=Full Power of Amdahl's Law|center|thumb|Full Power of Amdahl's Law]]

If we plot the full speedup curves against the number of processors, we will see the missing lines from the previous Amdahl's dismal prediction chart.

[[File:DiminishingReturn2.png|alt=infinite Speedup Under Amdahl's Law|center|thumb|Infinite Speedup in Amdahl's Law|400x400px]]

The TOP500 supercomputer competition provides another proof by a historical log of unrelenting computation power growths where the benchmarks (linear solvers) having no problem size limit. All manufacturers compete for the world's fastest supercomputer race <ref>https://www.top500.org/</ref> solving the largest possible problem that can be handled by the hardware. The follow chart illustrates the continuous speed improvements by year.
[[File:Supercomputers-history.png|center|thumb]]
In practical blockchain applications, the number of transactions to be processed will increase without a known limit. The ledger storage will continue to grow. In practice, the available computing, networking and storage components will continue to grow without bound enabled by the networking protocols. Therefore a statistic multiplexed computing blockchain can indeed meet any future application needs given proper economic incentives. The infrastructure no longer has the structural deficiency.

== Action Plan ==

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.

For Toichain protocol design, we choose Bitcoin 24.0.1 as the base line protocol by replacing the PoW consensus by PoS consensus and injecting SMC components into the protocol processing signaling for parallel computing.

This surprising result is also applicable to ledger storage. Without multiplexing, the blockchain ledger storage will eventually saturate all nodes causing the chain to collapse. The SMC blockchain protocol promises to hold the true finality of all transactions in perpetuity by multiplexing all storage resources while keeping the replication factor to a constant.

These discussions follow the inductive logic of the Law of Large Numbers <ref>https://www.sciencedirect.com/topics/mathematics/laws-of-large-number</ref>.

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

= SMC Proof of Stake Protocol =
Existing PoS protocol designs revolved around staking policies and randomness of the selection algorithm. Considering infrastructure scalability will add much complexity to the design. The examples include chain sharding and Danksharding <ref>https://ethereum.org/en/roadmap/danksharding/</ref>.

The challenge is complex -- we must deliver very high performance without compromising security and reliability of the network.

Technically, transaction replication and parallel processing were considered dangerous <ref>https://pages.cs.wisc.edu/~yxy/cs764-f20/papers/replication.pdf</ref> due to the potential race conditions (or double-spend problem). The blockchain protocol resolved the double-spending problem. It did not solve the parallel processing performance problem.

According to Professor Michael Flynn, there are three high-level parallel processing topologies: SIMD (single instruction multiple data), MIMD (multiple instructions multiple data), and pipeline (MISD - multiple instructions single data stream) <ref>https://link.springer.com/referenceworkentry/10.1007/978-0-387-09766-4_2</ref>. However, for eliminating double-spending, all transactions must be serialized, since each block may contain transactions affecting transactions in multiple other blocks. "Race conditions" and non-deterministic results are not allowed. Then the only possible topology entry is pipeline. This means for POS protocol, we must build a pipeline of transaction blocks to be validated without compromising network security and reliability.
[[File:Flynns-Taxonomy-of-Computer-Architectures.png|center|thumb|Parallel Processing Topologies]]
The problem is that the nature of the blockchain protocol is that all nodes run independently in parallel with little communication with other nodes via "gossip" protocols. It is far easier to force all nodes store the entire ledger than forcing them to form any pipeline and store partial chain data.

=== ACAN (Active Content Addressable Network) [U.S. PTO #11,588,926 B2, EPO #3539261] ===
ACAN is a high-level data '''''communication and synchronization protocol''''' with a SMC (statistic multiplexed computing) runtime that completely decouples all hardware components from communicating programs for network-scale high performance computing. The need for complete component decoupling was implemented in the original blockchain protocol via "gossip" protocol. This delivered blockchain's high availability and security. The simple "gossip" implementation in existing protocols is insufficient for parallel processing signaling.

The following figure illustrates the concept of ACAN (active content addressable networking) using UVR (unidirectional virtual ring) architecture. The illustrated implementation uses the Tuple Space resource tagging method and gossip protocol for UVR implementation.
[[File:SMC Architecture with ACAN.png|center|thumb|243x243px|SMC Architecture with ACAN]]

ACAN supports three simple APIs:

# '''read'''(&''key'', &''value''): ''key'' holds a search pattern in a "tuple space" where all nodes are connected. ''value'' holds the matched tuple, if any. This is a blocking call that a requesting program will be blocked until a pattern-matched tuple is found. The matching tuple remains in the "tuple space".
# '''get'''(&key, &value): Same as the "read()" API, except that the matching tuple is removed from the "tuple space".
# '''put'''(key, value): Inserts <key, value> into the "tuple space".

The use of "gossip" protocol can accelerate ACAN network saturation time. Applications running on ACAN will automatically form parallel processing topologies: pipeline, SIMD and MIMD without violating the serialization needs of transaction block validation. Replication factor can also be dynamically controlled to spread replicated blocks in randomly chosen hosts.

The highly parallel nature of the blockchain protocol will automatically implement the SMC principle in real time.

The critical feature of this dynamic SMC pipelined architecture is the inductive scaling feature.
[[File:Pipeline Parallel Processing.png|center|thumb|247x247px|Pipeline Parallel Processing]]

The speed up of a pipeline can be represented as: <math>SpeedUp = \left ( \frac{p\centerdot b}{p + (b-1)} \right )</math>, where p = number of processors in the pipeline, b = total blocks to be processed. Take the number of blocks to infinity:

<div style="text-align: center;">
<math>SpeedUp = \left ( \frac{p\centerdot b}{p + (b-1)} \right )=>\lim (b\Rightarrow\infty)(\frac{p}{\frac{p}{b}+1-\frac{1}{b}}) = p</math>
</div>

This means that as long as there are enough blocks to be processed, the entire chain's performance will be above bounded to the number of nodes in the pipeline.

For illustration purposes, the variation of block processing times was not considered in the above calculations. To see the power of pipeline parallelism, the automobile manufacturing processes illustrate a similar situation. The Hyundai Motor Company's production pipelines can produce 3,835 vehicles per day and 1.4M per year<ref>https://en.wikipedia.org/wiki/List_of_Hyundai_Motor_Company_manufacturing_facilities</ref>.

== Toichain Tokens ==
Toichain token is TOIN. There are 50,000,000,000 TOINs for the Alpha Release. There are air-drop tokens for early adopters, 1,000 TOIN each. Users need to register to download a toichain wallet to receive the payment. Citizenship is checked and verified to ensure that US citizens do not apply. The minimal staking contract is 10 TOINs.

== Non-Fungible Tokens ==
The TestNet Release of toichain protocol will support embedding arbitrary data in an "OP_RETURN" transaction that will be permanently recorded on the chain. Unlike the ordinal NFT <ref>https://blog.chain.link/ordinals-bitcoin-nfts/</ref> or NFT (non-fungible token) on other chains, these transactions cannot be altered or removed.

There are practical applications for these forever NFTs. Once Taproot is enabled on toichain, ordinal NFTs (BRC-20) will also be supported. Unlike the original Bitcoin network where BRC-20 craze has created massive network congestion<ref>https://beincrypto.com/learn/brc-20-token/</ref>, all transactions will be processed promptly in toichain without congestion or scaling problems.
== Toichain TestNet Launch ==
The toichain testnet launch will enable users to interact with one another through simple payments, just like the original Bitcoin network. Forever NFTs are supported. Smart contracts will be supported on a later date.

= References =
<references />

Consult the [[mediawikiwiki:Special:MyLanguage/Help:Contents|User's Guide]] for information on using the wiki software.

Main Page

2024-10-13T18:05:10Z

Justin: /* ACAN (Active Content Addressable Network) [U.S. PTO #11,588,926 B2, EPO #3539261] */

= <strong><big>'''Welcome to Toi-Twiki -- A Toichain Wiki'''</big></strong> =
This is the unofficial Toichain wiki site. Content is subject to changes.
---------------------------

= '''Introduction''' =
The blockchain protocol was introduced in a seminal paper entitled "Bitcoin: A peer-to-peer Electronic Cash System" <ref>https://bitcoin.org/bitcoin.pdf</ref> by Satoshi Nakamoto in 2008. Although there were previous peer-to-peer file-sharing projects such as Napster <ref>https://www.napster.com/us</ref>, BitTorrent <ref>https://www.bittorrent.com/</ref> and other electronic currency/file sharing applications, Bitcoin is the most enduring among the 23,000+ blockchains. Unlike other cryptocurrencies, the Bitcoin is often referred to as "digital gold" since the total coin supply is limited to 21 million (hard-coded in all running programs) and the only way to earn coin is to participate in the transaction block validation process. Token(or coin) supply and their disbursement policies differ among protocols.

The most attractive common blockchain features are 1) a decentralized consensus-driven decision making process and 2) a step-by-step cryptographic proving system. While blockchain is best known as a cryptocurrency transaction processing and record-keeping system, there are many other applications that can benefit from the secure storage, reliable transaction ledgers, fault tolerance and tamper resistance features.

== Algorithm vs. Protocol ==
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 ==
A good consensus protocol in a blockchain system has at least four properties:

# Fault tolerance to defend failures caused by natural disasters and human hacks or accidents
# Byzantine failure tolerance to defend exploitation by colluding parties
# Centralization avoidance to prevent corruptions in the decision making process
# Source code tamper resistance to automatically reject malicious attacks

Without assuming all nodes are active at all times, the blockchain relies on "gossip" protocol to communicate with other nodes. There are two popular types of consensus protocols: Proof of Work ('''PoW''') <ref>https://en.wikipedia.org/wiki/Proof_of_work</ref> or Proof of Stake ('''PoS''') <ref>https://www.investopedia.com/terms/p/proof-stake-pos.asp</ref>. Others include Proof of Possession('''PoP''')<ref>https://identityserver4.readthedocs.io/en/latest/topics/pop.html</ref> and Proof of History('''PoH''')<ref>https://www.infoworld.com/article/3666736/solana-blockchain-and-the-proof-of-history.html</ref>. The ultimate goal is to eliminate double-spending. Since most projects are open source, it's easy for a malicious actor to tamper a few nodes. This shouldn't compromise network integrity.

The Bitcoin network uses PoW which forces participating miners to compete for the fastest hashing rate by solving a computational cryptographic puzzle. Although it withstood more than 14 years of use, Bitcoin has been criticized for escalating electricity consumption <ref>https://www.forbes.com/advisor/investing/cryptocurrency/bitcoins-energy-usage-explained/</ref>. Other blockchain designs have experienced different challenges. For example, the PoH network Solana suffered multiple single-point-failure incidents <ref>https://messari.io/report/solana-analyzing-downtimes-statistics-and-ecosystem-development</ref>. All protocols struggle to combat scaling challenges. All are susceptible to 51% attacks <ref>https://originstamp.com/blog/has-there-ever-been-a-51-attack-on-bitcoin/#notable-51-attacks</ref>.

Since 2009, Bitcoin has proven to be the strongest and least susceptible to common hacks <ref>https://www.theguardian.com/technology/2014/mar/18/history-of-bitcoin-hacks-alternative-currency</ref>. As the PoW puzzle difficulty has increased dramatically over the years, the probability of a 51% attack on the Bitcoin network becomes more difficult. PoS protocols can save more than 90% energy consumption compared to PoW chains. But PoS chains have higher risks than PoW chains since a stolen coin will grow in PoS chains (for increased probability to be selected) forever but not in PoW chains (only hash rates count). PoS community governance rules can mitigate the voting power centralization problem. Staking and slashing policies can incentivize good behaviors and punish bad ones. In either case, double-spend is very expensive and difficult. According to Forbes, there are 80 cryptocurrencies that use PoS protocols at the time of this writing.

There are approximately 1,000 blockchains in four types: public, private, consortium, and permissioned <ref>https://increditools.com/blockchains/</ref>.

== Cryptographic Proofs ==
Bitcoin 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.

== Centralized vs. Decentralized Applications ==
The Bitcoin protocol enabled decentralized processing of traditionally centrally processed transactions without any trusted third-party. It inspired many decentralized financial applications, especially for applications with very long payment chains. However for fraud prevention and meeting financial regulatory requirements, many practical applications still require KYC (know your customer) checks. It is not possible to eliminate all trusted third parties, especially for custodial financial applications. There is a clear need for decentralized processing of trusted authority applications.

== Blockchain Trilemma ==
Blockchain protocols have three common aspects (goals): '''security''', '''decentralization''' and '''scalability''' -- these three terms do not have precise definitions but are intuitively understood <ref>https://sensoriumxr.com/articles/what-is-the-blockchain-trilemma</ref>. To date, 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.

A major shortcoming is scalability. Since all nodes verify each transaction independently, they need to store all the information required for it. As the chain grows, this burdens all nodes in the network. There are workarounds by limiting the amount of data stored on some nodes and exploiting the network to retrieve required information, such as the ''Limited/Light Nodes'' in Bitcoin network. Vast majority nodes are still full nodes in the existing Bitcoin network. Transaction processing speed often expressed ''as transactions per second(TPS) of'' blockchain have to exceed TPS ratings of credit card payment systems like VISA or MasterCard to reap the full benefits of blockchain. This is a tough problem and increasing the block size and/or reducing the block time or difficulty isn't a solution<ref>https://medium.com/coinmonks/blockchain-scaling-30c9e1b7db1b</ref>. Since blockchain TPS is very low, the transaction fees is often very high. This discourages public adoption. Layer 2 solution like ''Lightning Network'' or ''ZK-rollups,'' where only final settlement is on the main chain tend to address these issues. However, one could always argue that this often compromises some aspects of security and/or decentralization to achieve high TPS.

The trilemma was first introduced by Vitalik Buterin<ref>https://en.wikipedia.org/wiki/Vitalik_Buterin</ref>, one of the co-founders of Ethereum network. The problems he identified are real. There seem to be no obvious solutions that can accomplish all three goals at the same time. Therefore, all proposed solutions revolve around reducing "opportunity costs" focusing only on satisfying partial goals.

Treating the blockchain network as an infrastructure for transaction processing, the blockchain protocol solved service reliability problem but not performance challenge. The legacy infrastructure scaling dilemma: performance against reliability remains (where "infrastructure reliability" also does not have a commonly accepted definition). Fortunately these metrics, although important, are non-critical. Solutions that have been proposed have had varying opportunity costs. For many years, there were no obvious solutions that addressed all three blockchain goals (security, decentralization and scalability).
== Statistic Multiplexed Computing (SMC) ==
The principle of using unreliable components to build an arbitrarily reliable system was first lectured by von Neumann in the early 1950s<ref>https://static.ias.edu/pitp/archive/2012files/Probabilistic_Logics.pdf</ref>. The original idea was to use probabilistic logic to quantify the arbitrary reliability of a system by multiplexing all components. This theory was applied to the construction of Internet protocols to deliver the "best effort" reliability. Incidentally, best effort reliability also enabled "best effort" performance which in turn enabled unlimited scalability of the Internet. For emerging web3.0 technologies, it is important to apply the same methodology to both centralized and decentralized computing for seamless technology migration and integration. For historical arguments, click [[SMC|'''''here''''']].

== Definitions ==
'''Infrastructure scalability''' does not have a commonly accepted definition. It helps to define the challenging metrics more precisely before the infrastructure protocol design. In the following, for definitions #1 and #2, the word "'''infrastructure'''" means any '''application running on the infrastructure.'''

# '''Infrastructure Reliability''': MTBF (mean time between failure) = <math>\frac{\sum ((Start-Of-Downtime) - (Start-of-uptime)) }{No-of-failures}</math>
# '''Infrastructure Performance''': <math>\frac{No-of-Transactions}{Second}</math>
# '''Infrastructure Scalability''': Expanding the infrastructure in number of processors, networks or storage should have '''incrementally better''' impacts on application reliability and performance.
# '''Record Immutability''': For transaction ledgers, all confirmed records and changes are final. This is required by the blockchain protocol.
Note that in practice, record immutability is much harder to achieve than expected. There are two challenges, a) 51% attacks can literally wipe out all histories if successful, and b) for protocols require all nodes to hold independently verified ledger, such as the Bitcoin, the storage requirement grows approximately 50GB per month.

== 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 and considered.

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 crashe'''s <ref>https://groups.csail.mit.edu/tds/papers/Lynch/jacm93.pdf</ref>. The laws of physics regarding component reliability <ref>Encyclopedia of Physical Science and Technology, Editor-in-Chief Robert A. Meyers, [[index.php?title=Special:BookSources/9780122274107|ISBN 978-0-12-227410-7]], 2001</ref> show that '''100% component reliability is not possible.''' These facts require that the infrastructure protocol (program-program communication protocol) provide '''complete component (processing, networking and storage) decoupling''' from application program logics. This decoupling requirement forces the protocol to exploit "decentralized" or "stateless" components that the legacy infrastructure protocols, such as message passing interface (MPI), remote procedure call (RPC) and remote method invocation (RMI), cannot handle. The blockchain protocol is an example of a "best effort" availability protocol.

Quantifying infrastructure reliability can be traced back to the computer pioneer von Neumann. In addition to his contribution to computer architecture, von Neumann also penned a study on building reliable systems using unreliable components using probabilistic logics, in early fifties <ref>https://static.ias.edu/pitp/archive/2012files/Probabilistic_Logics.pdf</ref>. The 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 "best effort" reliability. Ironically, this best effort reliability also enabled the Internet's infinite scalability -- the benefit we enjoy now and into the future.

The Bitcoin protocol exploits multiple anonymous decoupled (or decentralized) computers connected through the Internet protocol. Judging from the Bitcoin network's reliability to date <ref>https://buybitcoinworldwide.com/bitcoin-downtime/</ref>, von Neumann's theory seems working well.

The '''second challenge''' involves infrastructure performance. Since the infrastructure must deploy multiple computing, networking and storage components, unless all components can be fully exploited at 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 lack this capability.

'''The infrastructure scalability challenge''' is automatically resolved once the performance challenge is resolved without negatively impacting reliability -- "best effort" performance" meets "best effort reliability". This requires inductive performance and reliability measures or deliveries.

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, an inductive statistic multiplexed blockchain protocol is needed to meet the scalability challenge. Non-inductive solutions such as fixed chain "sharding" or "Danksharding" <ref>https://ethereum.org/en/roadmap/danksharding/</ref> will only increase protocol development complexity with persistent performance walls.

== A Scalability Solution ==
An effective scalability solution can have two practical assumptions:

* The computation problem size can expand indefinitely, since every useful infrastructure is expected to solve bigger problems.

*Computing and network resources will continue to grow indefinitely, into the future.
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 <ref>https://en.wikipedia.org/wiki/Amdahl%27s_law</ref> and Gustafson's Law <ref>https://en.wikipedia.org/wiki/Gustafson%27s_law</ref>.

The Amdahl's Law assumes 0<= ''s'' <=1 percentage of serial instructions that cannot be parallelized. Then the ''(1-s)'' percentage of instructions can be accelerated using ''p'' processors.

<div style="text-align: center;">
Speedup(p) = <math>{1 \over s + {(1-s) \over p}}</math> (1) <br>Speedup(<math>\lim_{p \to \infty}</math>) = <math>\frac{1}{s}</math> (2)
</div>
Taking ''p'' to infinity in equation (1) yields equation (2). But this "scaling" step has two different operational semantics: a) increasing ''p'' for faster acceleration by reducing the value of (''1-s)/p'' solving the same problem. This will result ''s'' asymptotically approaching 1. Thus the speedup is above bounded to 1. Or b) increasing ''p'' to increase the parallel instruction percentage ''(1-s)'' by solving bigger problems. This will force ''s'' asymptotically approach 0. Then the speedup is above bounded by <math>\infty</math>. This scaling ambiguity has caused more than half century of confusion in the community.

Although quantifying ''s'' requires defining the problem size, the model (1) and (2) are applicable to programs solving any problem size with any percentage ''s''. The limit of speedup (2) also does not depend on problem size. However, since Amdahl originally used programs solving fixed problem sizes to argue the validity of not building parallel machines with too many processors, assuming fixed problem size using ''p'' processors has been the norm in interpreting Amdahl's law in the past. This assumption has led to the dismal speedup predictions.[[File:Amdahl's Law.png|thumb|Amdahl's Law Speedup Predictions|center]]The traditional Amdahl's Law interpretation seems to suggest parallel performances following the economic law of diminishing of returns, even though the mathematic model implies more potentials.

In 1988, Gustafson and Barsis at the Sandia National Laboratory conducted parallel computing experiments that seem to suggest potential infinite speedup.

Gustafson's Law was based on measured sequential and parallel elapsed times using ''p'' (=1024) processors. A new sequential percentage ''0<=x'<=1'' can be calculated using ''p'' processors. ''(1-x')'' is the parallel percentage using ''p'' processors.

To estimate accomplished speedup, Gustafson's Law states:

<div style="text-align: center;">
<math>Speedup=\frac{Tseq}{Tpar}=\frac{s'+(1-s')p}{1}=s'+(1-s')p </math> (3)
</div>

Scaling ''p'' to <math>\infty</math> for equation (3) cannot be done mathematically since ''s''' is dependent on the values of ''p''. And the scaling action also has two operational semantics: a) Keep the problem size fixed, adding processors to further reduce the total parallel processing time, this will push for bigger s'. This will make s' systematically approach 1. Thus speedup is also bounded to 1. Or b) expanding the problem size to allow the parallel part expanded solving bigger problems by simply multiplying (1-''s')'' by ''p (as shown in the chart below)''. This will force the real serial percentage ''s'' under a single processor asymptotically approaching 0. Speedup will be above bounded to ''<math>\infty</math> by Amdahl's equation (2)''. For some reason, in late 1980's, Gustafson's Law was used to argue for Massively Parallel Computing (MPC) (or ManyCPU) experiments and Amdahl's Law was used to argue for bigger mainframe (or BigCPU) computer architectures. These laws have been used to support two diverging computing system experiments and constructions until recent convergence.
[[File:Gustafson.png|thumb|Gustafson's Law|center]]
It is now obvious that the two law are identical with Amdahl's Law more succinct. But Gustafson's formula helps to quantify the serial percentages from practical program executions. In fact, the two serial percentages can be related by a simple equation<ref>https://www.researchgate.net/publication/228367369_Reevaluating_Amdahl's_law_and_Gustafson's_law</ref>:

<div style="text-align: center;">
<math>s=\frac{s'}{s'+(1-s')p}</math> (4)
</div>

Both laws actually refer to the same mathematical abstraction. Gustafson's formula assists in quantifying the percentage of serial computing through program experiments. Amdahl's Law delivers the ultimate predictions. This should have cleared the half-century myth about scaled-speedup and unscaled speedup.

In practice, extracting parallelism from an algorithm to use more processors is much harder than simply expanding the already parallelized parts to solve bigger problems. This explanation can be validated in practice when developers routinely increasing the problem size to use more parallel processors.

[[File:Full Range Amdah's Law .png|alt=Full Power of Amdahl's Law|center|thumb|Full Power of Amdahl's Law]]

If we plot the full speedup curves against the number of processors, we will see the missing lines from the previous Amdahl's dismal prediction chart.

[[File:DiminishingReturn2.png|alt=infinite Speedup Under Amdahl's Law|center|thumb|Infinite Speedup in Amdahl's Law|400x400px]]

The TOP500 supercomputer competition provides another proof by a historical log of unrelenting computation power growths where the benchmarks (linear solvers) having no problem size limit. All manufacturers compete for the world's fastest supercomputer race <ref>https://www.top500.org/</ref> solving the largest possible problem that can be handled by the hardware. The follow chart illustrates the continuous speed improvements by year.
[[File:Supercomputers-history.png|center|thumb]]
In practical blockchain applications, the number of transactions to be processed will increase without a known limit. The ledger storage will continue to grow. In practice, the available computing, networking and storage components will continue to grow without bound enabled by the networking protocols. Therefore a statistic multiplexed computing blockchain can indeed meet any future application needs given proper economic incentives. The infrastructure no longer has the structural deficiency.

== Action Plan ==

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.

For Toichain protocol design, we choose Bitcoin 24.0.1 as the base line protocol by replacing the PoW consensus by PoS consensus and injecting SMC components into the protocol processing signaling for parallel computing.

This surprising result is also applicable to ledger storage. Without multiplexing, the blockchain ledger storage will eventually saturate all nodes causing the chain to collapse. The SMC blockchain protocol promises to hold the true finality of all transactions in perpetuity by multiplexing all storage resources while keeping the replication factor to a constant.

These discussions follow the inductive logic of the Law of Large Numbers <ref>https://www.sciencedirect.com/topics/mathematics/laws-of-large-number</ref>.

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

= SMC Proof of Stake Protocol =
Existing PoS protocol designs revolved around staking policies and randomness of the selection algorithm. Considering infrastructure scalability will add much complexity to the design. The examples include chain sharding and Danksharding <ref>https://ethereum.org/en/roadmap/danksharding/</ref>.

The challenge is complex -- we must deliver very high performance without compromising security and reliability of the network.

Technically, transaction replication and parallel processing were considered dangerous <ref>https://pages.cs.wisc.edu/~yxy/cs764-f20/papers/replication.pdf</ref> due to the potential race conditions (or double-spend problem). The blockchain protocol resolved the double-spending problem. It did not solve the parallel processing performance problem.

According to Professor Michael Flynn, there are three high-level parallel processing topologies: SIMD (single instruction multiple data), MIMD (multiple instructions multiple data), and pipeline (MISD - multiple instructions single data stream) <ref>https://link.springer.com/referenceworkentry/10.1007/978-0-387-09766-4_2</ref>. However, for eliminating double-spending, all transactions must be serialized, since each block may contain transactions affecting transactions in multiple other blocks. "Race conditions" and non-deterministic results are not allowed. Then the only possible topology entry is pipeline. This means for POS protocol, we must build a pipeline of transaction blocks to be validated without compromising network security and reliability.
[[File:Flynns-Taxonomy-of-Computer-Architectures.png|center|thumb|Parallel Processing Topologies]]
The problem is that the nature of the blockchain protocol is that all nodes run independently in parallel with little communication with other nodes via "gossip" protocols. It is far easier to force all nodes store the entire ledger than forcing them to form any pipeline and store partial chain data.

=== ACAN (Active Content Addressable Network) [U.S. PTO #11,588,926 B2, EPO #3539261] ===
ACAN is a high-level data '''''communication and synchronization protocol''''' that completely decouples all hardware components from communicating programs for network-scale high performance computing. The need for complete component decoupling was implemented in the original blockchain protocol via "gossip" protocol. This delivered blockchain's high availability and security. The simple "gossip" implementation in existing protocols is insufficient for parallel processing signaling.

The following figure illustrates the concept of ACAN (active content addressable networking) using UVR (unidirectional virtual ring) architecture. The illustrated implementation uses the Tuple Space resource tagging method and gossip protocol for UVR implementation.
[[File:SMC Architecture with ACAN.png|center|thumb|243x243px|SMC Architecture with ACAN]]

ACAN supports three simple APIs:

# '''read'''(&''key'', &''value''): ''key'' holds a search pattern in a "tuple space" where all nodes are connected. ''value'' holds the matched tuple, if any. This is a blocking call that a requesting program will be blocked until a pattern-matched tuple is found. The matching tuple remains in the "tuple space".
# '''get'''(&key, &value): Same as the "read()" API, except that the matching tuple is removed from the "tuple space".
# '''put'''(key, value): Inserts <key, value> into the "tuple space".

The use of "gossip" protocol can accelerate ACAN network saturation time. Applications running on ACAN will automatically form parallel processing topologies: pipeline, SIMD and MIMD without violating the serialization needs of transaction block validation. Replication factor can also be dynamically controlled to spread replicated blocks in randomly chosen hosts.

The highly parallel nature of the blockchain protocol will automatically implement the SMC principle in real time.

The critical feature of this dynamic SMC pipelined architecture is the inductive scaling feature.
[[File:Pipeline Parallel Processing.png|center|thumb|247x247px|Pipeline Parallel Processing]]

The speed up of a pipeline can be represented as: <math>SpeedUp = \left ( \frac{p\centerdot b}{p + (b-1)} \right )</math>, where p = number of processors in the pipeline, b = total blocks to be processed. Take the number of blocks to infinity:

<div style="text-align: center;">
<math>SpeedUp = \left ( \frac{p\centerdot b}{p + (b-1)} \right )=>\lim (b\Rightarrow\infty)(\frac{p}{\frac{p}{b}+1-\frac{1}{b}}) = p</math>
</div>

This means that as long as there are enough blocks to be processed, the entire chain's performance will be above bounded to the number of nodes in the pipeline.

For illustration purposes, the variation of block processing times was not considered in the above calculations. To see the power of pipeline parallelism, the automobile manufacturing processes illustrate a similar situation. The Hyundai Motor Company's production pipelines can produce 3,835 vehicles per day and 1.4M per year<ref>https://en.wikipedia.org/wiki/List_of_Hyundai_Motor_Company_manufacturing_facilities</ref>.

== Toichain Tokens ==
Toichain token is TOIN. There are 50,000,000,000 TOINs for the Alpha Release. There are air-drop tokens for early adopters, 1,000 TOIN each. Users need to register to download a toichain wallet to receive the payment. Citizenship is checked and verified to ensure that US citizens do not apply. The minimal staking contract is 10 TOINs.

== Non-Fungible Tokens ==
The TestNet Release of toichain protocol will support embedding arbitrary data in an "OP_RETURN" transaction that will be permanently recorded on the chain. Unlike the ordinal NFT <ref>https://blog.chain.link/ordinals-bitcoin-nfts/</ref> or NFT (non-fungible token) on other chains, these transactions cannot be altered or removed.

There are practical applications for these forever NFTs. Once Taproot is enabled on toichain, ordinal NFTs (BRC-20) will also be supported. Unlike the original Bitcoin network where BRC-20 craze has created massive network congestion<ref>https://beincrypto.com/learn/brc-20-token/</ref>, all transactions will be processed promptly in toichain without congestion or scaling problems.
== Toichain TestNet Launch ==
The toichain testnet launch will enable users to interact with one another through simple payments, just like the original Bitcoin network. Forever NFTs are supported. Smart contracts will be supported on a later date.

= References =
<references />

Consult the [[mediawikiwiki:Special:MyLanguage/Help:Contents|User's Guide]] for information on using the wiki software.

Main Page

2024-10-13T18:03:29Z

Justin: /* A Scalability Solution */

= <strong><big>'''Welcome to Toi-Twiki -- A Toichain Wiki'''</big></strong> =
This is the unofficial Toichain wiki site. Content is subject to changes.
---------------------------

= '''Introduction''' =
The blockchain protocol was introduced in a seminal paper entitled "Bitcoin: A peer-to-peer Electronic Cash System" <ref>https://bitcoin.org/bitcoin.pdf</ref> by Satoshi Nakamoto in 2008. Although there were previous peer-to-peer file-sharing projects such as Napster <ref>https://www.napster.com/us</ref>, BitTorrent <ref>https://www.bittorrent.com/</ref> and other electronic currency/file sharing applications, Bitcoin is the most enduring among the 23,000+ blockchains. Unlike other cryptocurrencies, the Bitcoin is often referred to as "digital gold" since the total coin supply is limited to 21 million (hard-coded in all running programs) and the only way to earn coin is to participate in the transaction block validation process. Token(or coin) supply and their disbursement policies differ among protocols.

The most attractive common blockchain features are 1) a decentralized consensus-driven decision making process and 2) a step-by-step cryptographic proving system. While blockchain is best known as a cryptocurrency transaction processing and record-keeping system, there are many other applications that can benefit from the secure storage, reliable transaction ledgers, fault tolerance and tamper resistance features.

== Algorithm vs. Protocol ==
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 ==
A good consensus protocol in a blockchain system has at least four properties:

# Fault tolerance to defend failures caused by natural disasters and human hacks or accidents
# Byzantine failure tolerance to defend exploitation by colluding parties
# Centralization avoidance to prevent corruptions in the decision making process
# Source code tamper resistance to automatically reject malicious attacks

Without assuming all nodes are active at all times, the blockchain relies on "gossip" protocol to communicate with other nodes. There are two popular types of consensus protocols: Proof of Work ('''PoW''') <ref>https://en.wikipedia.org/wiki/Proof_of_work</ref> or Proof of Stake ('''PoS''') <ref>https://www.investopedia.com/terms/p/proof-stake-pos.asp</ref>. Others include Proof of Possession('''PoP''')<ref>https://identityserver4.readthedocs.io/en/latest/topics/pop.html</ref> and Proof of History('''PoH''')<ref>https://www.infoworld.com/article/3666736/solana-blockchain-and-the-proof-of-history.html</ref>. The ultimate goal is to eliminate double-spending. Since most projects are open source, it's easy for a malicious actor to tamper a few nodes. This shouldn't compromise network integrity.

The Bitcoin network uses PoW which forces participating miners to compete for the fastest hashing rate by solving a computational cryptographic puzzle. Although it withstood more than 14 years of use, Bitcoin has been criticized for escalating electricity consumption <ref>https://www.forbes.com/advisor/investing/cryptocurrency/bitcoins-energy-usage-explained/</ref>. Other blockchain designs have experienced different challenges. For example, the PoH network Solana suffered multiple single-point-failure incidents <ref>https://messari.io/report/solana-analyzing-downtimes-statistics-and-ecosystem-development</ref>. All protocols struggle to combat scaling challenges. All are susceptible to 51% attacks <ref>https://originstamp.com/blog/has-there-ever-been-a-51-attack-on-bitcoin/#notable-51-attacks</ref>.

Since 2009, Bitcoin has proven to be the strongest and least susceptible to common hacks <ref>https://www.theguardian.com/technology/2014/mar/18/history-of-bitcoin-hacks-alternative-currency</ref>. As the PoW puzzle difficulty has increased dramatically over the years, the probability of a 51% attack on the Bitcoin network becomes more difficult. PoS protocols can save more than 90% energy consumption compared to PoW chains. But PoS chains have higher risks than PoW chains since a stolen coin will grow in PoS chains (for increased probability to be selected) forever but not in PoW chains (only hash rates count). PoS community governance rules can mitigate the voting power centralization problem. Staking and slashing policies can incentivize good behaviors and punish bad ones. In either case, double-spend is very expensive and difficult. According to Forbes, there are 80 cryptocurrencies that use PoS protocols at the time of this writing.

There are approximately 1,000 blockchains in four types: public, private, consortium, and permissioned <ref>https://increditools.com/blockchains/</ref>.

== Cryptographic Proofs ==
Bitcoin 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.

== Centralized vs. Decentralized Applications ==
The Bitcoin protocol enabled decentralized processing of traditionally centrally processed transactions without any trusted third-party. It inspired many decentralized financial applications, especially for applications with very long payment chains. However for fraud prevention and meeting financial regulatory requirements, many practical applications still require KYC (know your customer) checks. It is not possible to eliminate all trusted third parties, especially for custodial financial applications. There is a clear need for decentralized processing of trusted authority applications.

== Blockchain Trilemma ==
Blockchain protocols have three common aspects (goals): '''security''', '''decentralization''' and '''scalability''' -- these three terms do not have precise definitions but are intuitively understood <ref>https://sensoriumxr.com/articles/what-is-the-blockchain-trilemma</ref>. To date, 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.

A major shortcoming is scalability. Since all nodes verify each transaction independently, they need to store all the information required for it. As the chain grows, this burdens all nodes in the network. There are workarounds by limiting the amount of data stored on some nodes and exploiting the network to retrieve required information, such as the ''Limited/Light Nodes'' in Bitcoin network. Vast majority nodes are still full nodes in the existing Bitcoin network. Transaction processing speed often expressed ''as transactions per second(TPS) of'' blockchain have to exceed TPS ratings of credit card payment systems like VISA or MasterCard to reap the full benefits of blockchain. This is a tough problem and increasing the block size and/or reducing the block time or difficulty isn't a solution<ref>https://medium.com/coinmonks/blockchain-scaling-30c9e1b7db1b</ref>. Since blockchain TPS is very low, the transaction fees is often very high. This discourages public adoption. Layer 2 solution like ''Lightning Network'' or ''ZK-rollups,'' where only final settlement is on the main chain tend to address these issues. However, one could always argue that this often compromises some aspects of security and/or decentralization to achieve high TPS.

The trilemma was first introduced by Vitalik Buterin<ref>https://en.wikipedia.org/wiki/Vitalik_Buterin</ref>, one of the co-founders of Ethereum network. The problems he identified are real. There seem to be no obvious solutions that can accomplish all three goals at the same time. Therefore, all proposed solutions revolve around reducing "opportunity costs" focusing only on satisfying partial goals.

Treating the blockchain network as an infrastructure for transaction processing, the blockchain protocol solved service reliability problem but not performance challenge. The legacy infrastructure scaling dilemma: performance against reliability remains (where "infrastructure reliability" also does not have a commonly accepted definition). Fortunately these metrics, although important, are non-critical. Solutions that have been proposed have had varying opportunity costs. For many years, there were no obvious solutions that addressed all three blockchain goals (security, decentralization and scalability).
== Statistic Multiplexed Computing (SMC) ==
The principle of using unreliable components to build an arbitrarily reliable system was first lectured by von Neumann in the early 1950s<ref>https://static.ias.edu/pitp/archive/2012files/Probabilistic_Logics.pdf</ref>. The original idea was to use probabilistic logic to quantify the arbitrary reliability of a system by multiplexing all components. This theory was applied to the construction of Internet protocols to deliver the "best effort" reliability. Incidentally, best effort reliability also enabled "best effort" performance which in turn enabled unlimited scalability of the Internet. For emerging web3.0 technologies, it is important to apply the same methodology to both centralized and decentralized computing for seamless technology migration and integration. For historical arguments, click [[SMC|'''''here''''']].

== Definitions ==
'''Infrastructure scalability''' does not have a commonly accepted definition. It helps to define the challenging metrics more precisely before the infrastructure protocol design. In the following, for definitions #1 and #2, the word "'''infrastructure'''" means any '''application running on the infrastructure.'''

# '''Infrastructure Reliability''': MTBF (mean time between failure) = <math>\frac{\sum ((Start-Of-Downtime) - (Start-of-uptime)) }{No-of-failures}</math>
# '''Infrastructure Performance''': <math>\frac{No-of-Transactions}{Second}</math>
# '''Infrastructure Scalability''': Expanding the infrastructure in number of processors, networks or storage should have '''incrementally better''' impacts on application reliability and performance.
# '''Record Immutability''': For transaction ledgers, all confirmed records and changes are final. This is required by the blockchain protocol.
Note that in practice, record immutability is much harder to achieve than expected. There are two challenges, a) 51% attacks can literally wipe out all histories if successful, and b) for protocols require all nodes to hold independently verified ledger, such as the Bitcoin, the storage requirement grows approximately 50GB per month.

== 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 and considered.

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 crashe'''s <ref>https://groups.csail.mit.edu/tds/papers/Lynch/jacm93.pdf</ref>. The laws of physics regarding component reliability <ref>Encyclopedia of Physical Science and Technology, Editor-in-Chief Robert A. Meyers, [[index.php?title=Special:BookSources/9780122274107|ISBN 978-0-12-227410-7]], 2001</ref> show that '''100% component reliability is not possible.''' These facts require that the infrastructure protocol (program-program communication protocol) provide '''complete component (processing, networking and storage) decoupling''' from application program logics. This decoupling requirement forces the protocol to exploit "decentralized" or "stateless" components that the legacy infrastructure protocols, such as message passing interface (MPI), remote procedure call (RPC) and remote method invocation (RMI), cannot handle. The blockchain protocol is an example of a "best effort" availability protocol.

Quantifying infrastructure reliability can be traced back to the computer pioneer von Neumann. In addition to his contribution to computer architecture, von Neumann also penned a study on building reliable systems using unreliable components using probabilistic logics, in early fifties <ref>https://static.ias.edu/pitp/archive/2012files/Probabilistic_Logics.pdf</ref>. The 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 "best effort" reliability. Ironically, this best effort reliability also enabled the Internet's infinite scalability -- the benefit we enjoy now and into the future.

The Bitcoin protocol exploits multiple anonymous decoupled (or decentralized) computers connected through the Internet protocol. Judging from the Bitcoin network's reliability to date <ref>https://buybitcoinworldwide.com/bitcoin-downtime/</ref>, von Neumann's theory seems working well.

The '''second challenge''' involves infrastructure performance. Since the infrastructure must deploy multiple computing, networking and storage components, unless all components can be fully exploited at 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 lack this capability.

'''The infrastructure scalability challenge''' is automatically resolved once the performance challenge is resolved without negatively impacting reliability -- "best effort" performance" meets "best effort reliability". This requires inductive performance and reliability measures or deliveries.

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, an inductive statistic multiplexed blockchain protocol is needed to meet the scalability challenge. Non-inductive solutions such as fixed chain "sharding" or "Danksharding" <ref>https://ethereum.org/en/roadmap/danksharding/</ref> will only increase protocol development complexity with persistent performance walls.

== A Scalability Solution ==
An effective scalability solution can have two practical assumptions:

* The computation problem size can expand indefinitely, since every useful infrastructure is expected to solve bigger problems.

*Computing and network resources will continue to grow indefinitely, into the future.
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 <ref>https://en.wikipedia.org/wiki/Amdahl%27s_law</ref> and Gustafson's Law <ref>https://en.wikipedia.org/wiki/Gustafson%27s_law</ref>.

The Amdahl's Law assumes 0<= ''s'' <=1 percentage of serial instructions that cannot be parallelized. Then the ''(1-s)'' percentage of instructions can be accelerated using ''p'' processors.

<div style="text-align: center;">
Speedup(p) = <math>{1 \over s + {(1-s) \over p}}</math> (1) <br>Speedup(<math>\lim_{p \to \infty}</math>) = <math>\frac{1}{s}</math> (2)
</div>
Taking ''p'' to infinity in equation (1) yields equation (2). But this "scaling" step has two different operational semantics: a) increasing ''p'' for faster acceleration by reducing the value of (''1-s)/p'' solving the same problem. This will result ''s'' asymptotically approaching 1. Thus the speedup is above bounded to 1. Or b) increasing ''p'' to increase the parallel instruction percentage ''(1-s)'' by solving bigger problems. This will force ''s'' asymptotically approach 0. Then the speedup is above bounded by <math>\infty</math>. This scaling ambiguity has caused more than half century of confusion in the community.

Although quantifying ''s'' requires defining the problem size, the model (1) and (2) are applicable to programs solving any problem size with any percentage ''s''. The limit of speedup (2) also does not depend on problem size. However, since Amdahl originally used programs solving fixed problem sizes to argue the validity of not building parallel machines with too many processors, assuming fixed problem size using ''p'' processors has been the norm in interpreting Amdahl's law in the past. This assumption has led to the dismal speedup predictions.[[File:Amdahl's Law.png|thumb|Amdahl's Law Speedup Predictions|center]]The traditional Amdahl's Law interpretation seems to suggest parallel performances following the economic law of diminishing of returns, even though the mathematic model implies more potentials.

In 1988, Gustafson and Barsis at the Sandia National Laboratory conducted parallel computing experiments that seem to suggest potential infinite speedup.

Gustafson's Law was based on measured sequential and parallel elapsed times using ''p'' (=1024) processors. A new sequential percentage ''0<=x'<=1'' can be calculated using ''p'' processors. ''(1-x')'' is the parallel percentage using ''p'' processors.

To estimate accomplished speedup, Gustafson's Law states:

<div style="text-align: center;">
<math>Speedup=\frac{Tseq}{Tpar}=\frac{s'+(1-s')p}{1}=s'+(1-s')p </math> (3)
</div>

Scaling ''p'' to <math>\infty</math> for equation (3) cannot be done mathematically since ''s''' is dependent on the values of ''p''. And the scaling action also has two operational semantics: a) Keep the problem size fixed, adding processors to further reduce the total parallel processing time, this will push for bigger s'. This will make s' systematically approach 1. Thus speedup is also bounded to 1. Or b) expanding the problem size to allow the parallel part expanded solving bigger problems by simply multiplying (1-''s')'' by ''p (as shown in the chart below)''. This will force the real serial percentage ''s'' under a single processor asymptotically approaching 0. Speedup will be above bounded to ''<math>\infty</math> by Amdahl's equation (2)''. For some reason, in late 1980's, Gustafson's Law was used to argue for Massively Parallel Computing (MPC) (or ManyCPU) experiments and Amdahl's Law was used to argue for bigger mainframe (or BigCPU) computer architectures. These laws have been used to support two diverging computing system experiments and constructions until recent convergence.
[[File:Gustafson.png|thumb|Gustafson's Law|center]]
It is now obvious that the two law are identical with Amdahl's Law more succinct. But Gustafson's formula helps to quantify the serial percentages from practical program executions. In fact, the two serial percentages can be related by a simple equation<ref>https://www.researchgate.net/publication/228367369_Reevaluating_Amdahl's_law_and_Gustafson's_law</ref>:

<div style="text-align: center;">
<math>s=\frac{s'}{s'+(1-s')p}</math> (4)
</div>

Both laws actually refer to the same mathematical abstraction. Gustafson's formula assists in quantifying the percentage of serial computing through program experiments. Amdahl's Law delivers the ultimate predictions. This should have cleared the half-century myth about scaled-speedup and unscaled speedup.

In practice, extracting parallelism from an algorithm to use more processors is much harder than simply expanding the already parallelized parts to solve bigger problems. This explanation can be validated in practice when developers routinely increasing the problem size to use more parallel processors.

[[File:Full Range Amdah's Law .png|alt=Full Power of Amdahl's Law|center|thumb|Full Power of Amdahl's Law]]

If we plot the full speedup curves against the number of processors, we will see the missing lines from the previous Amdahl's dismal prediction chart.

[[File:DiminishingReturn2.png|alt=infinite Speedup Under Amdahl's Law|center|thumb|Infinite Speedup in Amdahl's Law|400x400px]]

The TOP500 supercomputer competition provides another proof by a historical log of unrelenting computation power growths where the benchmarks (linear solvers) having no problem size limit. All manufacturers compete for the world's fastest supercomputer race <ref>https://www.top500.org/</ref> solving the largest possible problem that can be handled by the hardware. The follow chart illustrates the continuous speed improvements by year.
[[File:Supercomputers-history.png|center|thumb]]
In practical blockchain applications, the number of transactions to be processed will increase without a known limit. The ledger storage will continue to grow. In practice, the available computing, networking and storage components will continue to grow without bound enabled by the networking protocols. Therefore a statistic multiplexed computing blockchain can indeed meet any future application needs given proper economic incentives. The infrastructure no longer has the structural deficiency.

== Action Plan ==

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.

For Toichain protocol design, we choose Bitcoin 24.0.1 as the base line protocol by replacing the PoW consensus by PoS consensus and injecting SMC components into the protocol processing signaling for parallel computing.

This surprising result is also applicable to ledger storage. Without multiplexing, the blockchain ledger storage will eventually saturate all nodes causing the chain to collapse. The SMC blockchain protocol promises to hold the true finality of all transactions in perpetuity by multiplexing all storage resources while keeping the replication factor to a constant.

These discussions follow the inductive logic of the Law of Large Numbers <ref>https://www.sciencedirect.com/topics/mathematics/laws-of-large-number</ref>.

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

= SMC Proof of Stake Protocol =
Existing PoS protocol designs revolved around staking policies and randomness of the selection algorithm. Considering infrastructure scalability will add much complexity to the design. The examples include chain sharding and Danksharding <ref>https://ethereum.org/en/roadmap/danksharding/</ref>.

The challenge is complex -- we must deliver very high performance without compromising security and reliability of the network.

Technically, transaction replication and parallel processing were considered dangerous <ref>https://pages.cs.wisc.edu/~yxy/cs764-f20/papers/replication.pdf</ref> due to the potential race conditions (or double-spend problem). The blockchain protocol resolved the double-spending problem. It did not solve the parallel processing performance problem.

According to Professor Michael Flynn, there are three high-level parallel processing topologies: SIMD (single instruction multiple data), MIMD (multiple instructions multiple data), and pipeline (MISD - multiple instructions single data stream) <ref>https://link.springer.com/referenceworkentry/10.1007/978-0-387-09766-4_2</ref>. However, for eliminating double-spending, all transactions must be serialized, since each block may contain transactions affecting transactions in multiple other blocks. "Race conditions" and non-deterministic results are not allowed. Then the only possible topology entry is pipeline. This means for POS protocol, we must build a pipeline of transaction blocks to be validated without compromising network security and reliability.
[[File:Flynns-Taxonomy-of-Computer-Architectures.png|center|thumb|Parallel Processing Topologies]]
The problem is that the nature of the blockchain protocol is that all nodes run independently in parallel with little communication with other nodes via "gossip" protocols. It is far easier to force all nodes store the entire ledger than forcing them to form any pipeline and store partial chain data.

=== ACAN (Active Content Addressable Network) [U.S. PTO #11,588,926 B2, EPO #3539261] ===
ACAN is a high-level data '''''communication and synchronization protocol''''' that completely decouples all hardware components from communicating programs. The need for complete component decoupling was implemented in the original blockchain protocol via "gossip" protocol. This delivered blockchain's high availability and security. The simple "gossip" implementation in existing protocols is insufficient for parallel processing signaling.

The following figure illustrates the concept of ACAN (active content addressable networking) using UVR (unidirectional virtual ring) architecture. The illustrated implementation uses the Tuple Space resource tagging method and gossip protocol for UVR implementation.
[[File:SMC Architecture with ACAN.png|center|thumb|243x243px|SMC Architecture with ACAN]]

ACAN supports three simple APIs:

# '''read'''(&''key'', &''value''): ''key'' holds a search pattern in a "tuple space" where all nodes are connected. ''value'' holds the matched tuple, if any. This is a blocking call that a requesting program will be blocked until a pattern-matched tuple is found. The matching tuple remains in the "tuple space".
# '''get'''(&key, &value): Same as the "read()" API, except that the matching tuple is removed from the "tuple space".
# '''put'''(key, value): Inserts <key, value> into the "tuple space".

The use of "gossip" protocol can accelerate ACAN network saturation time. Applications running on ACAN will automatically form parallel processing topologies: pipeline, SIMD and MIMD without violating the serialization needs of transaction block validation. Replication factor can also be dynamically controlled to spread replicated blocks in randomly chosen hosts.

The highly parallel nature of the blockchain protocol will automatically implement the SMC principle in real time.

The critical feature of this dynamic SMC pipelined architecture is the inductive scaling feature.
[[File:Pipeline Parallel Processing.png|center|thumb|247x247px|Pipeline Parallel Processing]]

The speed up of a pipeline can be represented as: <math>SpeedUp = \left ( \frac{p\centerdot b}{p + (b-1)} \right )</math>, where p = number of processors in the pipeline, b = total blocks to be processed. Take the number of blocks to infinity:

<div style="text-align: center;">
<math>SpeedUp = \left ( \frac{p\centerdot b}{p + (b-1)} \right )=>\lim (b\Rightarrow\infty)(\frac{p}{\frac{p}{b}+1-\frac{1}{b}}) = p</math>
</div>

This means that as long as there are enough blocks to be processed, the entire chain's performance will be above bounded to the number of nodes in the pipeline.

For illustration purposes, the variation of block processing times was not considered in the above calculations. To see the power of pipeline parallelism, the automobile manufacturing processes illustrate a similar situation. The Hyundai Motor Company's production pipelines can produce 3,835 vehicles per day and 1.4M per year<ref>https://en.wikipedia.org/wiki/List_of_Hyundai_Motor_Company_manufacturing_facilities</ref>.

== Toichain Tokens ==
Toichain token is TOIN. There are 50,000,000,000 TOINs for the Alpha Release. There are air-drop tokens for early adopters, 1,000 TOIN each. Users need to register to download a toichain wallet to receive the payment. Citizenship is checked and verified to ensure that US citizens do not apply. The minimal staking contract is 10 TOINs.

== Non-Fungible Tokens ==
The TestNet Release of toichain protocol will support embedding arbitrary data in an "OP_RETURN" transaction that will be permanently recorded on the chain. Unlike the ordinal NFT <ref>https://blog.chain.link/ordinals-bitcoin-nfts/</ref> or NFT (non-fungible token) on other chains, these transactions cannot be altered or removed.

There are practical applications for these forever NFTs. Once Taproot is enabled on toichain, ordinal NFTs (BRC-20) will also be supported. Unlike the original Bitcoin network where BRC-20 craze has created massive network congestion<ref>https://beincrypto.com/learn/brc-20-token/</ref>, all transactions will be processed promptly in toichain without congestion or scaling problems.
== Toichain TestNet Launch ==
The toichain testnet launch will enable users to interact with one another through simple payments, just like the original Bitcoin network. Forever NFTs are supported. Smart contracts will be supported on a later date.

= References =
<references />

Consult the [[mediawikiwiki:Special:MyLanguage/Help:Contents|User's Guide]] for information on using the wiki software.

Main Page

2024-10-13T17:55:37Z

Justin: /* A Scalability Solution */

= <strong><big>'''Welcome to Toi-Twiki -- A Toichain Wiki'''</big></strong> =
This is the unofficial Toichain wiki site. Content is subject to changes.
---------------------------

= '''Introduction''' =
The blockchain protocol was introduced in a seminal paper entitled "Bitcoin: A peer-to-peer Electronic Cash System" <ref>https://bitcoin.org/bitcoin.pdf</ref> by Satoshi Nakamoto in 2008. Although there were previous peer-to-peer file-sharing projects such as Napster <ref>https://www.napster.com/us</ref>, BitTorrent <ref>https://www.bittorrent.com/</ref> and other electronic currency/file sharing applications, Bitcoin is the most enduring among the 23,000+ blockchains. Unlike other cryptocurrencies, the Bitcoin is often referred to as "digital gold" since the total coin supply is limited to 21 million (hard-coded in all running programs) and the only way to earn coin is to participate in the transaction block validation process. Token(or coin) supply and their disbursement policies differ among protocols.

The most attractive common blockchain features are 1) a decentralized consensus-driven decision making process and 2) a step-by-step cryptographic proving system. While blockchain is best known as a cryptocurrency transaction processing and record-keeping system, there are many other applications that can benefit from the secure storage, reliable transaction ledgers, fault tolerance and tamper resistance features.

== Algorithm vs. Protocol ==
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 ==
A good consensus protocol in a blockchain system has at least four properties:

# Fault tolerance to defend failures caused by natural disasters and human hacks or accidents
# Byzantine failure tolerance to defend exploitation by colluding parties
# Centralization avoidance to prevent corruptions in the decision making process
# Source code tamper resistance to automatically reject malicious attacks

Without assuming all nodes are active at all times, the blockchain relies on "gossip" protocol to communicate with other nodes. There are two popular types of consensus protocols: Proof of Work ('''PoW''') <ref>https://en.wikipedia.org/wiki/Proof_of_work</ref> or Proof of Stake ('''PoS''') <ref>https://www.investopedia.com/terms/p/proof-stake-pos.asp</ref>. Others include Proof of Possession('''PoP''')<ref>https://identityserver4.readthedocs.io/en/latest/topics/pop.html</ref> and Proof of History('''PoH''')<ref>https://www.infoworld.com/article/3666736/solana-blockchain-and-the-proof-of-history.html</ref>. The ultimate goal is to eliminate double-spending. Since most projects are open source, it's easy for a malicious actor to tamper a few nodes. This shouldn't compromise network integrity.

The Bitcoin network uses PoW which forces participating miners to compete for the fastest hashing rate by solving a computational cryptographic puzzle. Although it withstood more than 14 years of use, Bitcoin has been criticized for escalating electricity consumption <ref>https://www.forbes.com/advisor/investing/cryptocurrency/bitcoins-energy-usage-explained/</ref>. Other blockchain designs have experienced different challenges. For example, the PoH network Solana suffered multiple single-point-failure incidents <ref>https://messari.io/report/solana-analyzing-downtimes-statistics-and-ecosystem-development</ref>. All protocols struggle to combat scaling challenges. All are susceptible to 51% attacks <ref>https://originstamp.com/blog/has-there-ever-been-a-51-attack-on-bitcoin/#notable-51-attacks</ref>.

Since 2009, Bitcoin has proven to be the strongest and least susceptible to common hacks <ref>https://www.theguardian.com/technology/2014/mar/18/history-of-bitcoin-hacks-alternative-currency</ref>. As the PoW puzzle difficulty has increased dramatically over the years, the probability of a 51% attack on the Bitcoin network becomes more difficult. PoS protocols can save more than 90% energy consumption compared to PoW chains. But PoS chains have higher risks than PoW chains since a stolen coin will grow in PoS chains (for increased probability to be selected) forever but not in PoW chains (only hash rates count). PoS community governance rules can mitigate the voting power centralization problem. Staking and slashing policies can incentivize good behaviors and punish bad ones. In either case, double-spend is very expensive and difficult. According to Forbes, there are 80 cryptocurrencies that use PoS protocols at the time of this writing.

There are approximately 1,000 blockchains in four types: public, private, consortium, and permissioned <ref>https://increditools.com/blockchains/</ref>.

== Cryptographic Proofs ==
Bitcoin 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.

== Centralized vs. Decentralized Applications ==
The Bitcoin protocol enabled decentralized processing of traditionally centrally processed transactions without any trusted third-party. It inspired many decentralized financial applications, especially for applications with very long payment chains. However for fraud prevention and meeting financial regulatory requirements, many practical applications still require KYC (know your customer) checks. It is not possible to eliminate all trusted third parties, especially for custodial financial applications. There is a clear need for decentralized processing of trusted authority applications.

== Blockchain Trilemma ==
Blockchain protocols have three common aspects (goals): '''security''', '''decentralization''' and '''scalability''' -- these three terms do not have precise definitions but are intuitively understood <ref>https://sensoriumxr.com/articles/what-is-the-blockchain-trilemma</ref>. To date, 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.

A major shortcoming is scalability. Since all nodes verify each transaction independently, they need to store all the information required for it. As the chain grows, this burdens all nodes in the network. There are workarounds by limiting the amount of data stored on some nodes and exploiting the network to retrieve required information, such as the ''Limited/Light Nodes'' in Bitcoin network. Vast majority nodes are still full nodes in the existing Bitcoin network. Transaction processing speed often expressed ''as transactions per second(TPS) of'' blockchain have to exceed TPS ratings of credit card payment systems like VISA or MasterCard to reap the full benefits of blockchain. This is a tough problem and increasing the block size and/or reducing the block time or difficulty isn't a solution<ref>https://medium.com/coinmonks/blockchain-scaling-30c9e1b7db1b</ref>. Since blockchain TPS is very low, the transaction fees is often very high. This discourages public adoption. Layer 2 solution like ''Lightning Network'' or ''ZK-rollups,'' where only final settlement is on the main chain tend to address these issues. However, one could always argue that this often compromises some aspects of security and/or decentralization to achieve high TPS.

The trilemma was first introduced by Vitalik Buterin<ref>https://en.wikipedia.org/wiki/Vitalik_Buterin</ref>, one of the co-founders of Ethereum network. The problems he identified are real. There seem to be no obvious solutions that can accomplish all three goals at the same time. Therefore, all proposed solutions revolve around reducing "opportunity costs" focusing only on satisfying partial goals.

Treating the blockchain network as an infrastructure for transaction processing, the blockchain protocol solved service reliability problem but not performance challenge. The legacy infrastructure scaling dilemma: performance against reliability remains (where "infrastructure reliability" also does not have a commonly accepted definition). Fortunately these metrics, although important, are non-critical. Solutions that have been proposed have had varying opportunity costs. For many years, there were no obvious solutions that addressed all three blockchain goals (security, decentralization and scalability).
== Statistic Multiplexed Computing (SMC) ==
The principle of using unreliable components to build an arbitrarily reliable system was first lectured by von Neumann in the early 1950s<ref>https://static.ias.edu/pitp/archive/2012files/Probabilistic_Logics.pdf</ref>. The original idea was to use probabilistic logic to quantify the arbitrary reliability of a system by multiplexing all components. This theory was applied to the construction of Internet protocols to deliver the "best effort" reliability. Incidentally, best effort reliability also enabled "best effort" performance which in turn enabled unlimited scalability of the Internet. For emerging web3.0 technologies, it is important to apply the same methodology to both centralized and decentralized computing for seamless technology migration and integration. For historical arguments, click [[SMC|'''''here''''']].

== Definitions ==
'''Infrastructure scalability''' does not have a commonly accepted definition. It helps to define the challenging metrics more precisely before the infrastructure protocol design. In the following, for definitions #1 and #2, the word "'''infrastructure'''" means any '''application running on the infrastructure.'''

# '''Infrastructure Reliability''': MTBF (mean time between failure) = <math>\frac{\sum ((Start-Of-Downtime) - (Start-of-uptime)) }{No-of-failures}</math>
# '''Infrastructure Performance''': <math>\frac{No-of-Transactions}{Second}</math>
# '''Infrastructure Scalability''': Expanding the infrastructure in number of processors, networks or storage should have '''incrementally better''' impacts on application reliability and performance.
# '''Record Immutability''': For transaction ledgers, all confirmed records and changes are final. This is required by the blockchain protocol.
Note that in practice, record immutability is much harder to achieve than expected. There are two challenges, a) 51% attacks can literally wipe out all histories if successful, and b) for protocols require all nodes to hold independently verified ledger, such as the Bitcoin, the storage requirement grows approximately 50GB per month.

== 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 and considered.

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 crashe'''s <ref>https://groups.csail.mit.edu/tds/papers/Lynch/jacm93.pdf</ref>. The laws of physics regarding component reliability <ref>Encyclopedia of Physical Science and Technology, Editor-in-Chief Robert A. Meyers, [[index.php?title=Special:BookSources/9780122274107|ISBN 978-0-12-227410-7]], 2001</ref> show that '''100% component reliability is not possible.''' These facts require that the infrastructure protocol (program-program communication protocol) provide '''complete component (processing, networking and storage) decoupling''' from application program logics. This decoupling requirement forces the protocol to exploit "decentralized" or "stateless" components that the legacy infrastructure protocols, such as message passing interface (MPI), remote procedure call (RPC) and remote method invocation (RMI), cannot handle. The blockchain protocol is an example of a "best effort" availability protocol.

Quantifying infrastructure reliability can be traced back to the computer pioneer von Neumann. In addition to his contribution to computer architecture, von Neumann also penned a study on building reliable systems using unreliable components using probabilistic logics, in early fifties <ref>https://static.ias.edu/pitp/archive/2012files/Probabilistic_Logics.pdf</ref>. The 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 "best effort" reliability. Ironically, this best effort reliability also enabled the Internet's infinite scalability -- the benefit we enjoy now and into the future.

The Bitcoin protocol exploits multiple anonymous decoupled (or decentralized) computers connected through the Internet protocol. Judging from the Bitcoin network's reliability to date <ref>https://buybitcoinworldwide.com/bitcoin-downtime/</ref>, von Neumann's theory seems working well.

The '''second challenge''' involves infrastructure performance. Since the infrastructure must deploy multiple computing, networking and storage components, unless all components can be fully exploited at 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 lack this capability.

'''The infrastructure scalability challenge''' is automatically resolved once the performance challenge is resolved without negatively impacting reliability -- "best effort" performance" meets "best effort reliability". This requires inductive performance and reliability measures or deliveries.

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, an inductive statistic multiplexed blockchain protocol is needed to meet the scalability challenge. Non-inductive solutions such as fixed chain "sharding" or "Danksharding" <ref>https://ethereum.org/en/roadmap/danksharding/</ref> will only increase protocol development complexity with persistent performance walls.

== A Scalability Solution ==
An effective scalability solution can have two practical assumptions:

* The computation problem size can expand indefinitely, since every useful infrastructure is expected to solve bigger problems.

*Computing and network resources will continue to grow indefinitely, into the future.
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 <ref>https://en.wikipedia.org/wiki/Amdahl%27s_law</ref> and Gustafson's Law <ref>https://en.wikipedia.org/wiki/Gustafson%27s_law</ref>.

The Amdahl's Law assumes 0<= ''s'' <=1 percentage of serial instructions that cannot be parallelized. Then the ''(1-s)'' percentage of instructions can be accelerated using ''p'' processors.

<div style="text-align: center;">
Speedup(p) = <math>{1 \over s + {(1-s) \over p}}</math> (1) <br>Speedup(<math>\lim_{p \to \infty}</math>) = <math>\frac{1}{s}</math> (2)
</div>
Taking ''p'' to infinity in equation (1) yields equation (2). But this "scaling" step has two different operational semantics: a) increasing ''p'' for faster acceleration by reducing the value of (''1-s)/p'' solving the same problem. This will result ''s'' asymptotically approaching 1. Thus the speedup is above bounded to 1. Or b) increasing ''p'' to increase the parallel instruction percentage ''(1-s)'' by solving bigger problems. This will force ''s'' asymptotically approach 0. Then the speedup is above bounded by <math>\infty</math>. This scaling ambiguity has caused more than half century of confusion in the community.

Although quantifying ''s'' requires defining the problem size, the model (1) and (2) are applicable to programs solving any problem size with any percentage ''s''. The limit of speedup (2) also does not depend on problem size. However, since Amdahl originally used programs solving fixed problem sizes to argue the validity of not building parallel machines with too many processors, assuming fixed problem size using ''p'' processors has been the norm in interpreting Amdahl's law in the past. This assumption has led to the dismal speedup predictions.[[File:Amdahl's Law.png|thumb|Amdahl's Law Speedup Predictions|center]]The traditional Amdahl's Law interpretation seems to suggest parallel performances following the economic law of diminishing of returns, even though the mathematic model implies more potentials.

In 1988, Gustafson and Barsis at the Sandia National Laboratory conducted parallel computing experiments that seem to suggest potential infinite speedup.

Gustafson's Law was based on measured sequential and parallel elapsed times using ''p'' (=1024) processors. A new sequential percentage ''0<=x'<=1'' can be calculated using ''p'' processors. ''(1-x')'' is the parallel percentage using ''p'' processors.

To estimate accomplished speedup, Gustafson's Law states:

<div style="text-align: center;">
<math>Speedup=\frac{Tseq}{Tpar}=\frac{s'+(1-s')p}{1}=s'+(1-s')p </math> (3)
</div>

Scaling ''p'' to <math>\infty</math> for equation (3) cannot be done mathematically since ''s'<nowiki/>'' is dependent on the values of ''p''. And the scaling action also has two operational semantics: a) Keep the problem size fixed, adding processors to further reduce the total parallel processing time, this will push for bigger s'. This will make s' systematically approach 1. Thus speedup is also bounded to 1. Or b) expanding the problem size to allow the parallel part expanded solving bigger problems by multiplying ''s''' by ''p (as shown in the chart below)''. This will force the real serial percentage ''s'' under a single processor asymptotically approaching 0. Speedup will be above bounded to ''<math>\infty</math> by Amdahl's equation (2)''. For some reason, in late 1980's, Gustafson's Law was used to argue for Massively Parallel Computing (MPC) (or ManyCPU) experiments and Amdahl's Law was used to argue for bigger mainframe (or BigCPU) computer architectures. These laws have been used to support two diverging computing system experiments and constructions until recent convergence.
[[File:Gustafson.png|thumb|Gustafson's Law|center]]
It is now obvious that the two law are identical with Amdahl's Law more succinct. But Gustafson's formula helps to quantify the serial percentages from practical program executions. In fact, the two serial percentages can be related by a simple equation<ref>https://www.researchgate.net/publication/228367369_Reevaluating_Amdahl's_law_and_Gustafson's_law</ref>:

<div style="text-align: center;">
<math>s=\frac{s'}{s'+(1-s')p}</math> (4)
</div>

Both laws actually refer to the same mathematical abstraction. Gustafson's formula assists in quantifying the percentage of serial computing through program experiments. Amdahl's Law delivers the ultimate predictions. This should have cleared the half-century myth about scaled-speedup and unscaled speedup.

In practice, extracting parallelism from an algorithm to use more processors is much harder than simply expanding the already parallelized parts to solve bigger problems. This explanation can be validated in practice when developers routinely increasing the problem size to use more parallel processors.

[[File:Full Range Amdah's Law .png|alt=Full Power of Amdahl's Law|center|thumb|Full Power of Amdahl's Law]]

If we plot the full speedup curves against the number of processors, we will see the missing lines from the previous Amdahl's dismal prediction chart.

[[File:DiminishingReturn2.png|alt=infinite Speedup Under Amdahl's Law|center|thumb|Infinite Speedup in Amdahl's Law|400x400px]]

The TOP500 supercomputer competition provides another proof by a historical log of unrelenting computation power growths where the benchmarks (linear solvers) having no problem size limit. All manufacturers compete for the world's fastest supercomputer race <ref>https://www.top500.org/</ref> solving the largest possible problem that can be handled by the hardware. The follow chart illustrates the continuous speed improvements by year.
[[File:Supercomputers-history.png|center|thumb]]
In practical blockchain applications, the number of transactions to be processed will increase without a known limit. The ledger storage will continue to grow. In practice, the available computing, networking and storage components will continue to grow without bound enabled by the networking protocols. Therefore a statistic multiplexed computing blockchain can indeed meet any future application needs given proper economic incentives. The infrastructure no longer has the structural deficiency.

== Action Plan ==

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.

For Toichain protocol design, we choose Bitcoin 24.0.1 as the base line protocol by replacing the PoW consensus by PoS consensus and injecting SMC components into the protocol processing signaling for parallel computing.

This surprising result is also applicable to ledger storage. Without multiplexing, the blockchain ledger storage will eventually saturate all nodes causing the chain to collapse. The SMC blockchain protocol promises to hold the true finality of all transactions in perpetuity by multiplexing all storage resources while keeping the replication factor to a constant.

These discussions follow the inductive logic of the Law of Large Numbers <ref>https://www.sciencedirect.com/topics/mathematics/laws-of-large-number</ref>.

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

= SMC Proof of Stake Protocol =
Existing PoS protocol designs revolved around staking policies and randomness of the selection algorithm. Considering infrastructure scalability will add much complexity to the design. The examples include chain sharding and Danksharding <ref>https://ethereum.org/en/roadmap/danksharding/</ref>.

The challenge is complex -- we must deliver very high performance without compromising security and reliability of the network.

Technically, transaction replication and parallel processing were considered dangerous <ref>https://pages.cs.wisc.edu/~yxy/cs764-f20/papers/replication.pdf</ref> due to the potential race conditions (or double-spend problem). The blockchain protocol resolved the double-spending problem. It did not solve the parallel processing performance problem.

According to Professor Michael Flynn, there are three high-level parallel processing topologies: SIMD (single instruction multiple data), MIMD (multiple instructions multiple data), and pipeline (MISD - multiple instructions single data stream) <ref>https://link.springer.com/referenceworkentry/10.1007/978-0-387-09766-4_2</ref>. However, for eliminating double-spending, all transactions must be serialized, since each block may contain transactions affecting transactions in multiple other blocks. "Race conditions" and non-deterministic results are not allowed. Then the only possible topology entry is pipeline. This means for POS protocol, we must build a pipeline of transaction blocks to be validated without compromising network security and reliability.
[[File:Flynns-Taxonomy-of-Computer-Architectures.png|center|thumb|Parallel Processing Topologies]]
The problem is that the nature of the blockchain protocol is that all nodes run independently in parallel with little communication with other nodes via "gossip" protocols. It is far easier to force all nodes store the entire ledger than forcing them to form any pipeline and store partial chain data.

=== ACAN (Active Content Addressable Network) [U.S. PTO #11,588,926 B2] ===
ACAN is a high-level data '''''communication and synchronization protocol''''' that completely decouples all hardware components from communicating programs. The need for complete component decoupling was implemented in the original blockchain protocol via "gossip" protocol. This delivered blockchain's high availability and security. The simple "gossip" implementation in existing protocols is insufficient for parallel processing signaling.

The following figure illustrates the concept of ACAN (active content addressable networking) using UVR (unidirectional virtual ring) architecture. The illustrated implementation uses the Tuple Space resource tagging method and gossip protocol for UVR implementation.
[[File:SMC Architecture with ACAN.png|center|thumb|243x243px|SMC Architecture with ACAN]]

ACAN supports three simple APIs:

# '''read'''(&''key'', &''value''): ''key'' holds a search pattern in a "tuple space" where all nodes are connected. ''value'' holds the matched tuple, if any. This is a blocking call that a requesting program will be blocked until a pattern-matched tuple is found. The matching tuple remains in the "tuple space".
# '''get'''(&key, &value): Same as the "read()" API, except that the matching tuple is removed from the "tuple space".
# '''put'''(key, value): Inserts <key, value> into the "tuple space".

The use of "gossip" protocol can accelerate ACAN network saturation time. Applications running on ACAN will automatically form parallel processing topologies: pipeline, SIMD and MIMD without violating the serialization needs of transaction block validation. Replication factor can also be dynamically controlled to spread replicated blocks in randomly chosen hosts.

The highly parallel nature of the blockchain protocol will automatically implement the SMC principle in real time.

The critical feature of this dynamic SMC pipelined architecture is the inductive scaling feature.
[[File:Pipeline Parallel Processing.png|center|thumb|247x247px|Pipeline Parallel Processing]]

The speed up of a pipeline can be represented as: <math>SpeedUp = \left ( \frac{p\centerdot b}{p + (b-1)} \right )</math>, where p = number of processors in the pipeline, b = total blocks to be processed. Take the number of blocks to infinity:

<div style="text-align: center;">
<math>SpeedUp = \left ( \frac{p\centerdot b}{p + (b-1)} \right )=>\lim (b\Rightarrow\infty)(\frac{p}{\frac{p}{b}+1-\frac{1}{b}}) = p</math>
</div>

This means that as long as there are enough blocks to be processed, the entire chain's performance will be above bounded to the number of nodes in the pipeline.

For illustration purposes, the variation of block processing times was not considered in the above calculations. To see the power of pipeline parallelism, the automobile manufacturing processes illustrate a similar situation. The Hyundai Motor Company's production pipelines can produce 3,835 vehicles per day and 1.4M per year<ref>https://en.wikipedia.org/wiki/List_of_Hyundai_Motor_Company_manufacturing_facilities</ref>.

== Toichain Tokens ==
Toichain token is TOIN. There are 50,000,000,000 TOINs for the Alpha Release. There are air-drop tokens for early adopters, 1,000 TOIN each. Users need to register to download a toichain wallet to receive the payment. Citizenship is checked and verified to ensure that US citizens do not apply. The minimal staking contract is 10 TOINs.

== Non-Fungible Tokens ==
The TestNet Release of toichain protocol will support embedding arbitrary data in an "OP_RETURN" transaction that will be permanently recorded on the chain. Unlike the ordinal NFT <ref>https://blog.chain.link/ordinals-bitcoin-nfts/</ref> or NFT (non-fungible token) on other chains, these transactions cannot be altered or removed.

There are practical applications for these forever NFTs. Once Taproot is enabled on toichain, ordinal NFTs (BRC-20) will also be supported. Unlike the original Bitcoin network where BRC-20 craze has created massive network congestion<ref>https://beincrypto.com/learn/brc-20-token/</ref>, all transactions will be processed promptly in toichain without congestion or scaling problems.
== Toichain TestNet Launch ==
The toichain testnet launch will enable users to interact with one another through simple payments, just like the original Bitcoin network. Forever NFTs are supported. Smart contracts will be supported on a later date.

= References =
<references />

Consult the [[mediawikiwiki:Special:MyLanguage/Help:Contents|User's Guide]] for information on using the wiki software.

Main Page

2024-10-13T17:27:38Z

Justin: /* A Scalability Solution */

= <strong><big>'''Welcome to Toi-Twiki -- A Toichain Wiki'''</big></strong> =
This is the unofficial Toichain wiki site. Content is subject to changes.
---------------------------

= '''Introduction''' =
The blockchain protocol was introduced in a seminal paper entitled "Bitcoin: A peer-to-peer Electronic Cash System" <ref>https://bitcoin.org/bitcoin.pdf</ref> by Satoshi Nakamoto in 2008. Although there were previous peer-to-peer file-sharing projects such as Napster <ref>https://www.napster.com/us</ref>, BitTorrent <ref>https://www.bittorrent.com/</ref> and other electronic currency/file sharing applications, Bitcoin is the most enduring among the 23,000+ blockchains. Unlike other cryptocurrencies, the Bitcoin is often referred to as "digital gold" since the total coin supply is limited to 21 million (hard-coded in all running programs) and the only way to earn coin is to participate in the transaction block validation process. Token(or coin) supply and their disbursement policies differ among protocols.

The most attractive common blockchain features are 1) a decentralized consensus-driven decision making process and 2) a step-by-step cryptographic proving system. While blockchain is best known as a cryptocurrency transaction processing and record-keeping system, there are many other applications that can benefit from the secure storage, reliable transaction ledgers, fault tolerance and tamper resistance features.

== Algorithm vs. Protocol ==
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 ==
A good consensus protocol in a blockchain system has at least four properties:

# Fault tolerance to defend failures caused by natural disasters and human hacks or accidents
# Byzantine failure tolerance to defend exploitation by colluding parties
# Centralization avoidance to prevent corruptions in the decision making process
# Source code tamper resistance to automatically reject malicious attacks

Without assuming all nodes are active at all times, the blockchain relies on "gossip" protocol to communicate with other nodes. There are two popular types of consensus protocols: Proof of Work ('''PoW''') <ref>https://en.wikipedia.org/wiki/Proof_of_work</ref> or Proof of Stake ('''PoS''') <ref>https://www.investopedia.com/terms/p/proof-stake-pos.asp</ref>. Others include Proof of Possession('''PoP''')<ref>https://identityserver4.readthedocs.io/en/latest/topics/pop.html</ref> and Proof of History('''PoH''')<ref>https://www.infoworld.com/article/3666736/solana-blockchain-and-the-proof-of-history.html</ref>. The ultimate goal is to eliminate double-spending. Since most projects are open source, it's easy for a malicious actor to tamper a few nodes. This shouldn't compromise network integrity.

The Bitcoin network uses PoW which forces participating miners to compete for the fastest hashing rate by solving a computational cryptographic puzzle. Although it withstood more than 14 years of use, Bitcoin has been criticized for escalating electricity consumption <ref>https://www.forbes.com/advisor/investing/cryptocurrency/bitcoins-energy-usage-explained/</ref>. Other blockchain designs have experienced different challenges. For example, the PoH network Solana suffered multiple single-point-failure incidents <ref>https://messari.io/report/solana-analyzing-downtimes-statistics-and-ecosystem-development</ref>. All protocols struggle to combat scaling challenges. All are susceptible to 51% attacks <ref>https://originstamp.com/blog/has-there-ever-been-a-51-attack-on-bitcoin/#notable-51-attacks</ref>.

Since 2009, Bitcoin has proven to be the strongest and least susceptible to common hacks <ref>https://www.theguardian.com/technology/2014/mar/18/history-of-bitcoin-hacks-alternative-currency</ref>. As the PoW puzzle difficulty has increased dramatically over the years, the probability of a 51% attack on the Bitcoin network becomes more difficult. PoS protocols can save more than 90% energy consumption compared to PoW chains. But PoS chains have higher risks than PoW chains since a stolen coin will grow in PoS chains (for increased probability to be selected) forever but not in PoW chains (only hash rates count). PoS community governance rules can mitigate the voting power centralization problem. Staking and slashing policies can incentivize good behaviors and punish bad ones. In either case, double-spend is very expensive and difficult. According to Forbes, there are 80 cryptocurrencies that use PoS protocols at the time of this writing.

There are approximately 1,000 blockchains in four types: public, private, consortium, and permissioned <ref>https://increditools.com/blockchains/</ref>.

== Cryptographic Proofs ==
Bitcoin 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.

== Centralized vs. Decentralized Applications ==
The Bitcoin protocol enabled decentralized processing of traditionally centrally processed transactions without any trusted third-party. It inspired many decentralized financial applications, especially for applications with very long payment chains. However for fraud prevention and meeting financial regulatory requirements, many practical applications still require KYC (know your customer) checks. It is not possible to eliminate all trusted third parties, especially for custodial financial applications. There is a clear need for decentralized processing of trusted authority applications.

== Blockchain Trilemma ==
Blockchain protocols have three common aspects (goals): '''security''', '''decentralization''' and '''scalability''' -- these three terms do not have precise definitions but are intuitively understood <ref>https://sensoriumxr.com/articles/what-is-the-blockchain-trilemma</ref>. To date, 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.

A major shortcoming is scalability. Since all nodes verify each transaction independently, they need to store all the information required for it. As the chain grows, this burdens all nodes in the network. There are workarounds by limiting the amount of data stored on some nodes and exploiting the network to retrieve required information, such as the ''Limited/Light Nodes'' in Bitcoin network. Vast majority nodes are still full nodes in the existing Bitcoin network. Transaction processing speed often expressed ''as transactions per second(TPS) of'' blockchain have to exceed TPS ratings of credit card payment systems like VISA or MasterCard to reap the full benefits of blockchain. This is a tough problem and increasing the block size and/or reducing the block time or difficulty isn't a solution<ref>https://medium.com/coinmonks/blockchain-scaling-30c9e1b7db1b</ref>. Since blockchain TPS is very low, the transaction fees is often very high. This discourages public adoption. Layer 2 solution like ''Lightning Network'' or ''ZK-rollups,'' where only final settlement is on the main chain tend to address these issues. However, one could always argue that this often compromises some aspects of security and/or decentralization to achieve high TPS.

The trilemma was first introduced by Vitalik Buterin<ref>https://en.wikipedia.org/wiki/Vitalik_Buterin</ref>, one of the co-founders of Ethereum network. The problems he identified are real. There seem to be no obvious solutions that can accomplish all three goals at the same time. Therefore, all proposed solutions revolve around reducing "opportunity costs" focusing only on satisfying partial goals.

Treating the blockchain network as an infrastructure for transaction processing, the blockchain protocol solved service reliability problem but not performance challenge. The legacy infrastructure scaling dilemma: performance against reliability remains (where "infrastructure reliability" also does not have a commonly accepted definition). Fortunately these metrics, although important, are non-critical. Solutions that have been proposed have had varying opportunity costs. For many years, there were no obvious solutions that addressed all three blockchain goals (security, decentralization and scalability).
== Statistic Multiplexed Computing (SMC) ==
The principle of using unreliable components to build an arbitrarily reliable system was first lectured by von Neumann in the early 1950s<ref>https://static.ias.edu/pitp/archive/2012files/Probabilistic_Logics.pdf</ref>. The original idea was to use probabilistic logic to quantify the arbitrary reliability of a system by multiplexing all components. This theory was applied to the construction of Internet protocols to deliver the "best effort" reliability. Incidentally, best effort reliability also enabled "best effort" performance which in turn enabled unlimited scalability of the Internet. For emerging web3.0 technologies, it is important to apply the same methodology to both centralized and decentralized computing for seamless technology migration and integration. For historical arguments, click [[SMC|'''''here''''']].

== Definitions ==
'''Infrastructure scalability''' does not have a commonly accepted definition. It helps to define the challenging metrics more precisely before the infrastructure protocol design. In the following, for definitions #1 and #2, the word "'''infrastructure'''" means any '''application running on the infrastructure.'''

# '''Infrastructure Reliability''': MTBF (mean time between failure) = <math>\frac{\sum ((Start-Of-Downtime) - (Start-of-uptime)) }{No-of-failures}</math>
# '''Infrastructure Performance''': <math>\frac{No-of-Transactions}{Second}</math>
# '''Infrastructure Scalability''': Expanding the infrastructure in number of processors, networks or storage should have '''incrementally better''' impacts on application reliability and performance.
# '''Record Immutability''': For transaction ledgers, all confirmed records and changes are final. This is required by the blockchain protocol.
Note that in practice, record immutability is much harder to achieve than expected. There are two challenges, a) 51% attacks can literally wipe out all histories if successful, and b) for protocols require all nodes to hold independently verified ledger, such as the Bitcoin, the storage requirement grows approximately 50GB per month.

== 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 and considered.

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 crashe'''s <ref>https://groups.csail.mit.edu/tds/papers/Lynch/jacm93.pdf</ref>. The laws of physics regarding component reliability <ref>Encyclopedia of Physical Science and Technology, Editor-in-Chief Robert A. Meyers, [[index.php?title=Special:BookSources/9780122274107|ISBN 978-0-12-227410-7]], 2001</ref> show that '''100% component reliability is not possible.''' These facts require that the infrastructure protocol (program-program communication protocol) provide '''complete component (processing, networking and storage) decoupling''' from application program logics. This decoupling requirement forces the protocol to exploit "decentralized" or "stateless" components that the legacy infrastructure protocols, such as message passing interface (MPI), remote procedure call (RPC) and remote method invocation (RMI), cannot handle. The blockchain protocol is an example of a "best effort" availability protocol.

Quantifying infrastructure reliability can be traced back to the computer pioneer von Neumann. In addition to his contribution to computer architecture, von Neumann also penned a study on building reliable systems using unreliable components using probabilistic logics, in early fifties <ref>https://static.ias.edu/pitp/archive/2012files/Probabilistic_Logics.pdf</ref>. The 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 "best effort" reliability. Ironically, this best effort reliability also enabled the Internet's infinite scalability -- the benefit we enjoy now and into the future.

The Bitcoin protocol exploits multiple anonymous decoupled (or decentralized) computers connected through the Internet protocol. Judging from the Bitcoin network's reliability to date <ref>https://buybitcoinworldwide.com/bitcoin-downtime/</ref>, von Neumann's theory seems working well.

The '''second challenge''' involves infrastructure performance. Since the infrastructure must deploy multiple computing, networking and storage components, unless all components can be fully exploited at 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 lack this capability.

'''The infrastructure scalability challenge''' is automatically resolved once the performance challenge is resolved without negatively impacting reliability -- "best effort" performance" meets "best effort reliability". This requires inductive performance and reliability measures or deliveries.

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, an inductive statistic multiplexed blockchain protocol is needed to meet the scalability challenge. Non-inductive solutions such as fixed chain "sharding" or "Danksharding" <ref>https://ethereum.org/en/roadmap/danksharding/</ref> will only increase protocol development complexity with persistent performance walls.

== A Scalability Solution ==
An effective scalability solution can have two practical assumptions:

* The computation problem size can expand indefinitely, since every useful infrastructure is expected to solve bigger problems.

*Computing and network resources will continue to grow indefinitely, into the future.
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 <ref>https://en.wikipedia.org/wiki/Amdahl%27s_law</ref> and Gustafson's Law <ref>https://en.wikipedia.org/wiki/Gustafson%27s_law</ref>.

The Amdahl's Law assumes 0<= ''s'' <=1 percentage of serial instructions that cannot be parallelized. Then the ''(1-s)'' percentage of instructions can be accelerated using ''p'' processors.

<div style="text-align: center;">
Speedup(p) = <math>{1 \over s + {(1-s) \over p}}</math> (1) <br>Speedup(<math>\lim_{p \to \infty}</math>) = <math>\frac{1}{s}</math> (2)
</div>
Taking ''p'' to infinity in equation (1) yields equation (2). But this "scaling" step has two different operational semantics: a) increasing ''p'' for faster acceleration by reducing the value of (''1-s)/p'' solving the same problem. This will result ''s'' asymptotically approaching 1. Thus the speedup is above bounded to 1. Or b) increasing ''p'' to increase the parallel instruction percentage ''(1-s)'' by solving bigger problems. This will force ''s'' asymptotically approach 0. Then the speedup is above bounded by <math>\infty</math>. This scaling ambiguity has caused more than half century of confusion in the community.

Although quantifying ''s'' requires defining the problem size, the model (1) and (2) are applicable to programs solving any problem size with any percentage ''s''. The limit of speedup (2) also does not depend on problem size. However, since Amdahl originally used programs solving fixed problem sizes to argue the validity of not building parallel machines with too many processors, assuming fixed problem size using ''p'' processors has been the norm in interpreting Amdahl's law in the past. This assumption has led to the dismal speedup predictions.[[File:Amdahl's Law.png|thumb|Amdahl's Law Speedup Predictions|center]]The traditional Amdahl's Law interpretation seems to suggest parallel performances following the economic law of diminishing of returns, even though the mathematic model implies more potentials.

In 1988, Gustafson and Barsis at the Sandia National Laboratory conducted parallel computing experiments that seem to suggest potential infinite speedup.

Gustafson's Law was based on measured sequential and parallel elapsed times using ''p'' (=1024) processors. A new sequential percentage ''0<=x'<=1'' can be calculated using ''p'' processors. ''(1-x')'' is the parallel percentage using ''p'' processors.

To estimate accomplished speedup, Gustafson's Law states:

<div style="text-align: center;">
<math>Speedup=\frac{Tseq}{Tpar}=\frac{s'+(1-s')p}{1}=s'+(1-s')p </math> (3)
</div>

Scaling ''p'' to <math>\infty</math> for equation (3) also has two operational semantics: a) Keep the problem size fixed, adding processors to further reduce the total parallel processing time, this will push for bigger s'. This will make s' systematically approach 1. Thus speedup is also bounded to 1. Or b) expanding the problem size to allow the parallel part expanded solving bigger problems. Therefore the serial percentage s' will asymptotically approaching 0. Speedup will be above bounded to ''p''. In late 1980's, Gustafson's Law was used to argue for Massively Parallel Computing (MPC) (or ManyCPU) experiments and Amdahl's Law was used to argue for bigger mainframe (or BigCPU) computer architectures. These laws have been used to support two diverging computing system experiments and constructions until recent convergence.
[[File:Gustafson.png|thumb|Gustafson's Law|center]]
It is now obvious that the two law are identical with Amdahl's Law more succinct. But Gustafson's formula helps to quantify the serial percentages from practical program executions. In fact, the two serial percentages can be related by a simple equation<ref>https://www.researchgate.net/publication/228367369_Reevaluating_Amdahl's_law_and_Gustafson's_law</ref>:

<div style="text-align: center;">
<math>s=\frac{s'}{s'+(1-s')p}</math> (4)
</div>

Both law actually refer to the same mathematical abstraction. Gustafson's formula assisted in quantifying the percentage of serial computing through program experiments. Neither should be directly used for speedup prediction alone.

This explanation can be validated in practice when developers simply increasing the problem size to use more parallel processors.

[[File:Full Range Amdah's Law .png|alt=Full Power of Amdahl's Law|center|thumb|Full Power of Amdahl's Law]]

If we plot the full speedup curves against the number of processors, we will see the missing lines from the previous Amdahl's dismal prediction chart.

[[File:DiminishingReturn2.png|alt=infinite Speedup Under Amdahl's Law|center|thumb|Infinite Speedup in Amdahl's Law|400x400px]]

The TOP500 supercomputer competition provides a clear historical log of growing computation powers where the benchmarks (linear solvers) that have open problem sizes. All manufacturers compete for the world's fastest supercomputer race <ref>https://www.top500.org/</ref> solving the largest possible problem that can be handled by the hardware. The follow chart illustrates the continuous speedup improvements by year.
[[File:Supercomputers-history.png|center|thumb]]
In practical blockchain applications, the number of transactions to be processed will increase without a known limit. The ledger storage will continue to grow. In practice, the available computing, networking and storage components will continue to grow without limits enabled by the networking protocols. Therefore a statistic multiplexed computing blockchain can meet any future application needs given proper economic incentives. The infrastructure no longer has the structural deficiency.

== Action Plan ==

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.

For Toichain protocol design, we choose Bitcoin 24.0.1 as the base line protocol by replacing the PoW consensus by PoS consensus and injecting SMC components into the protocol processing signaling for parallel computing.

This surprising result is also applicable to ledger storage. Without multiplexing, the blockchain ledger storage will eventually saturate all nodes causing the chain to collapse. The SMC blockchain protocol promises to hold the true finality of all transactions in perpetuity by multiplexing all storage resources while keeping the replication factor to a constant.

These discussions follow the inductive logic of the Law of Large Numbers <ref>https://www.sciencedirect.com/topics/mathematics/laws-of-large-number</ref>.

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

= SMC Proof of Stake Protocol =
Existing PoS protocol designs revolved around staking policies and randomness of the selection algorithm. Considering infrastructure scalability will add much complexity to the design. The examples include chain sharding and Danksharding <ref>https://ethereum.org/en/roadmap/danksharding/</ref>.

The challenge is complex -- we must deliver very high performance without compromising security and reliability of the network.

Technically, transaction replication and parallel processing were considered dangerous <ref>https://pages.cs.wisc.edu/~yxy/cs764-f20/papers/replication.pdf</ref> due to the potential race conditions (or double-spend problem). The blockchain protocol resolved the double-spending problem. It did not solve the parallel processing performance problem.

According to Professor Michael Flynn, there are three high-level parallel processing topologies: SIMD (single instruction multiple data), MIMD (multiple instructions multiple data), and pipeline (MISD - multiple instructions single data stream) <ref>https://link.springer.com/referenceworkentry/10.1007/978-0-387-09766-4_2</ref>. However, for eliminating double-spending, all transactions must be serialized, since each block may contain transactions affecting transactions in multiple other blocks. "Race conditions" and non-deterministic results are not allowed. Then the only possible topology entry is pipeline. This means for POS protocol, we must build a pipeline of transaction blocks to be validated without compromising network security and reliability.
[[File:Flynns-Taxonomy-of-Computer-Architectures.png|center|thumb|Parallel Processing Topologies]]
The problem is that the nature of the blockchain protocol is that all nodes run independently in parallel with little communication with other nodes via "gossip" protocols. It is far easier to force all nodes store the entire ledger than forcing them to form any pipeline and store partial chain data.

=== ACAN (Active Content Addressable Network) [U.S. PTO #11,588,926 B2] ===
ACAN is a high-level data '''''communication and synchronization protocol''''' that completely decouples all hardware components from communicating programs. The need for complete component decoupling was implemented in the original blockchain protocol via "gossip" protocol. This delivered blockchain's high availability and security. The simple "gossip" implementation in existing protocols is insufficient for parallel processing signaling.

The following figure illustrates the concept of ACAN (active content addressable networking) using UVR (unidirectional virtual ring) architecture. The illustrated implementation uses the Tuple Space resource tagging method and gossip protocol for UVR implementation.
[[File:SMC Architecture with ACAN.png|center|thumb|243x243px|SMC Architecture with ACAN]]

ACAN supports three simple APIs:

# '''read'''(&''key'', &''value''): ''key'' holds a search pattern in a "tuple space" where all nodes are connected. ''value'' holds the matched tuple, if any. This is a blocking call that a requesting program will be blocked until a pattern-matched tuple is found. The matching tuple remains in the "tuple space".
# '''get'''(&key, &value): Same as the "read()" API, except that the matching tuple is removed from the "tuple space".
# '''put'''(key, value): Inserts <key, value> into the "tuple space".

The use of "gossip" protocol can accelerate ACAN network saturation time. Applications running on ACAN will automatically form parallel processing topologies: pipeline, SIMD and MIMD without violating the serialization needs of transaction block validation. Replication factor can also be dynamically controlled to spread replicated blocks in randomly chosen hosts.

The highly parallel nature of the blockchain protocol will automatically implement the SMC principle in real time.

The critical feature of this dynamic SMC pipelined architecture is the inductive scaling feature.
[[File:Pipeline Parallel Processing.png|center|thumb|247x247px|Pipeline Parallel Processing]]

The speed up of a pipeline can be represented as: <math>SpeedUp = \left ( \frac{p\centerdot b}{p + (b-1)} \right )</math>, where p = number of processors in the pipeline, b = total blocks to be processed. Take the number of blocks to infinity:

<div style="text-align: center;">
<math>SpeedUp = \left ( \frac{p\centerdot b}{p + (b-1)} \right )=>\lim (b\Rightarrow\infty)(\frac{p}{\frac{p}{b}+1-\frac{1}{b}}) = p</math>
</div>

This means that as long as there are enough blocks to be processed, the entire chain's performance will be above bounded to the number of nodes in the pipeline.

For illustration purposes, the variation of block processing times was not considered in the above calculations. To see the power of pipeline parallelism, the automobile manufacturing processes illustrate a similar situation. The Hyundai Motor Company's production pipelines can produce 3,835 vehicles per day and 1.4M per year<ref>https://en.wikipedia.org/wiki/List_of_Hyundai_Motor_Company_manufacturing_facilities</ref>.

== Toichain Tokens ==
Toichain token is TOIN. There are 50,000,000,000 TOINs for the Alpha Release. There are air-drop tokens for early adopters, 1,000 TOIN each. Users need to register to download a toichain wallet to receive the payment. Citizenship is checked and verified to ensure that US citizens do not apply. The minimal staking contract is 10 TOINs.

== Non-Fungible Tokens ==
The TestNet Release of toichain protocol will support embedding arbitrary data in an "OP_RETURN" transaction that will be permanently recorded on the chain. Unlike the ordinal NFT <ref>https://blog.chain.link/ordinals-bitcoin-nfts/</ref> or NFT (non-fungible token) on other chains, these transactions cannot be altered or removed.

There are practical applications for these forever NFTs. Once Taproot is enabled on toichain, ordinal NFTs (BRC-20) will also be supported. Unlike the original Bitcoin network where BRC-20 craze has created massive network congestion<ref>https://beincrypto.com/learn/brc-20-token/</ref>, all transactions will be processed promptly in toichain without congestion or scaling problems.
== Toichain TestNet Launch ==
The toichain testnet launch will enable users to interact with one another through simple payments, just like the original Bitcoin network. Forever NFTs are supported. Smart contracts will be supported on a later date.

= References =
<references />

Consult the [[mediawikiwiki:Special:MyLanguage/Help:Contents|User's Guide]] for information on using the wiki software.

Main Page

2024-10-13T14:20:10Z

Justin: /* ACAN (Active Content Addressable Network) [U.S. PTO #11,588,926 B2] */

= <strong><big>'''Welcome to Toi-Twiki -- A Toichain Wiki'''</big></strong> =
This is the unofficial Toichain wiki site. Content is subject to changes.
---------------------------

= '''Introduction''' =
The blockchain protocol was introduced in a seminal paper entitled "Bitcoin: A peer-to-peer Electronic Cash System" <ref>https://bitcoin.org/bitcoin.pdf</ref> by Satoshi Nakamoto in 2008. Although there were previous peer-to-peer file-sharing projects such as Napster <ref>https://www.napster.com/us</ref>, BitTorrent <ref>https://www.bittorrent.com/</ref> and other electronic currency/file sharing applications, Bitcoin is the most enduring among the 23,000+ blockchains. Unlike other cryptocurrencies, the Bitcoin is often referred to as "digital gold" since the total coin supply is limited to 21 million (hard-coded in all running programs) and the only way to earn coin is to participate in the transaction block validation process. Token(or coin) supply and their disbursement policies differ among protocols.

The most attractive common blockchain features are 1) a decentralized consensus-driven decision making process and 2) a step-by-step cryptographic proving system. While blockchain is best known as a cryptocurrency transaction processing and record-keeping system, there are many other applications that can benefit from the secure storage, reliable transaction ledgers, fault tolerance and tamper resistance features.

== Algorithm vs. Protocol ==
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 ==
A good consensus protocol in a blockchain system has at least four properties:

# Fault tolerance to defend failures caused by natural disasters and human hacks or accidents
# Byzantine failure tolerance to defend exploitation by colluding parties
# Centralization avoidance to prevent corruptions in the decision making process
# Source code tamper resistance to automatically reject malicious attacks

Without assuming all nodes are active at all times, the blockchain relies on "gossip" protocol to communicate with other nodes. There are two popular types of consensus protocols: Proof of Work ('''PoW''') <ref>https://en.wikipedia.org/wiki/Proof_of_work</ref> or Proof of Stake ('''PoS''') <ref>https://www.investopedia.com/terms/p/proof-stake-pos.asp</ref>. Others include Proof of Possession('''PoP''')<ref>https://identityserver4.readthedocs.io/en/latest/topics/pop.html</ref> and Proof of History('''PoH''')<ref>https://www.infoworld.com/article/3666736/solana-blockchain-and-the-proof-of-history.html</ref>. The ultimate goal is to eliminate double-spending. Since most projects are open source, it's easy for a malicious actor to tamper a few nodes. This shouldn't compromise network integrity.

The Bitcoin network uses PoW which forces participating miners to compete for the fastest hashing rate by solving a computational cryptographic puzzle. Although it withstood more than 14 years of use, Bitcoin has been criticized for escalating electricity consumption <ref>https://www.forbes.com/advisor/investing/cryptocurrency/bitcoins-energy-usage-explained/</ref>. Other blockchain designs have experienced different challenges. For example, the PoH network Solana suffered multiple single-point-failure incidents <ref>https://messari.io/report/solana-analyzing-downtimes-statistics-and-ecosystem-development</ref>. All protocols struggle to combat scaling challenges. All are susceptible to 51% attacks <ref>https://originstamp.com/blog/has-there-ever-been-a-51-attack-on-bitcoin/#notable-51-attacks</ref>.

Since 2009, Bitcoin has proven to be the strongest and least susceptible to common hacks <ref>https://www.theguardian.com/technology/2014/mar/18/history-of-bitcoin-hacks-alternative-currency</ref>. As the PoW puzzle difficulty has increased dramatically over the years, the probability of a 51% attack on the Bitcoin network becomes more difficult. PoS protocols can save more than 90% energy consumption compared to PoW chains. But PoS chains have higher risks than PoW chains since a stolen coin will grow in PoS chains (for increased probability to be selected) forever but not in PoW chains (only hash rates count). PoS community governance rules can mitigate the voting power centralization problem. Staking and slashing policies can incentivize good behaviors and punish bad ones. In either case, double-spend is very expensive and difficult. According to Forbes, there are 80 cryptocurrencies that use PoS protocols at the time of this writing.

There are approximately 1,000 blockchains in four types: public, private, consortium, and permissioned <ref>https://increditools.com/blockchains/</ref>.

== Cryptographic Proofs ==
Bitcoin 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.

== Centralized vs. Decentralized Applications ==
The Bitcoin protocol enabled decentralized processing of traditionally centrally processed transactions without any trusted third-party. It inspired many decentralized financial applications, especially for applications with very long payment chains. However for fraud prevention and meeting financial regulatory requirements, many practical applications still require KYC (know your customer) checks. It is not possible to eliminate all trusted third parties, especially for custodial financial applications. There is a clear need for decentralized processing of trusted authority applications.

== Blockchain Trilemma ==
Blockchain protocols have three common aspects (goals): '''security''', '''decentralization''' and '''scalability''' -- these three terms do not have precise definitions but are intuitively understood <ref>https://sensoriumxr.com/articles/what-is-the-blockchain-trilemma</ref>. To date, 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.

A major shortcoming is scalability. Since all nodes verify each transaction independently, they need to store all the information required for it. As the chain grows, this burdens all nodes in the network. There are workarounds by limiting the amount of data stored on some nodes and exploiting the network to retrieve required information, such as the ''Limited/Light Nodes'' in Bitcoin network. Vast majority nodes are still full nodes in the existing Bitcoin network. Transaction processing speed often expressed ''as transactions per second(TPS) of'' blockchain have to exceed TPS ratings of credit card payment systems like VISA or MasterCard to reap the full benefits of blockchain. This is a tough problem and increasing the block size and/or reducing the block time or difficulty isn't a solution<ref>https://medium.com/coinmonks/blockchain-scaling-30c9e1b7db1b</ref>. Since blockchain TPS is very low, the transaction fees is often very high. This discourages public adoption. Layer 2 solution like ''Lightning Network'' or ''ZK-rollups,'' where only final settlement is on the main chain tend to address these issues. However, one could always argue that this often compromises some aspects of security and/or decentralization to achieve high TPS.

The trilemma was first introduced by Vitalik Buterin<ref>https://en.wikipedia.org/wiki/Vitalik_Buterin</ref>, one of the co-founders of Ethereum network. The problems he identified are real. There seem to be no obvious solutions that can accomplish all three goals at the same time. Therefore, all proposed solutions revolve around reducing "opportunity costs" focusing only on satisfying partial goals.

Treating the blockchain network as an infrastructure for transaction processing, the blockchain protocol solved service reliability problem but not performance challenge. The legacy infrastructure scaling dilemma: performance against reliability remains (where "infrastructure reliability" also does not have a commonly accepted definition). Fortunately these metrics, although important, are non-critical. Solutions that have been proposed have had varying opportunity costs. For many years, there were no obvious solutions that addressed all three blockchain goals (security, decentralization and scalability).
== Statistic Multiplexed Computing (SMC) ==
The principle of using unreliable components to build an arbitrarily reliable system was first lectured by von Neumann in the early 1950s<ref>https://static.ias.edu/pitp/archive/2012files/Probabilistic_Logics.pdf</ref>. The original idea was to use probabilistic logic to quantify the arbitrary reliability of a system by multiplexing all components. This theory was applied to the construction of Internet protocols to deliver the "best effort" reliability. Incidentally, best effort reliability also enabled "best effort" performance which in turn enabled unlimited scalability of the Internet. For emerging web3.0 technologies, it is important to apply the same methodology to both centralized and decentralized computing for seamless technology migration and integration. For historical arguments, click [[SMC|'''''here''''']].

== Definitions ==
'''Infrastructure scalability''' does not have a commonly accepted definition. It helps to define the challenging metrics more precisely before the infrastructure protocol design. In the following, for definitions #1 and #2, the word "'''infrastructure'''" means any '''application running on the infrastructure.'''

# '''Infrastructure Reliability''': MTBF (mean time between failure) = <math>\frac{\sum ((Start-Of-Downtime) - (Start-of-uptime)) }{No-of-failures}</math>
# '''Infrastructure Performance''': <math>\frac{No-of-Transactions}{Second}</math>
# '''Infrastructure Scalability''': Expanding the infrastructure in number of processors, networks or storage should have '''incrementally better''' impacts on application reliability and performance.
# '''Record Immutability''': For transaction ledgers, all confirmed records and changes are final. This is required by the blockchain protocol.
Note that in practice, record immutability is much harder to achieve than expected. There are two challenges, a) 51% attacks can literally wipe out all histories if successful, and b) for protocols require all nodes to hold independently verified ledger, such as the Bitcoin, the storage requirement grows approximately 50GB per month.

== 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 and considered.

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 crashe'''s <ref>https://groups.csail.mit.edu/tds/papers/Lynch/jacm93.pdf</ref>. The laws of physics regarding component reliability <ref>Encyclopedia of Physical Science and Technology, Editor-in-Chief Robert A. Meyers, [[index.php?title=Special:BookSources/9780122274107|ISBN 978-0-12-227410-7]], 2001</ref> show that '''100% component reliability is not possible.''' These facts require that the infrastructure protocol (program-program communication protocol) provide '''complete component (processing, networking and storage) decoupling''' from application program logics. This decoupling requirement forces the protocol to exploit "decentralized" or "stateless" components that the legacy infrastructure protocols, such as message passing interface (MPI), remote procedure call (RPC) and remote method invocation (RMI), cannot handle. The blockchain protocol is an example of a "best effort" availability protocol.

Quantifying infrastructure reliability can be traced back to the computer pioneer von Neumann. In addition to his contribution to computer architecture, von Neumann also penned a study on building reliable systems using unreliable components using probabilistic logics, in early fifties <ref>https://static.ias.edu/pitp/archive/2012files/Probabilistic_Logics.pdf</ref>. The 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 "best effort" reliability. Ironically, this best effort reliability also enabled the Internet's infinite scalability -- the benefit we enjoy now and into the future.

The Bitcoin protocol exploits multiple anonymous decoupled (or decentralized) computers connected through the Internet protocol. Judging from the Bitcoin network's reliability to date <ref>https://buybitcoinworldwide.com/bitcoin-downtime/</ref>, von Neumann's theory seems working well.

The '''second challenge''' involves infrastructure performance. Since the infrastructure must deploy multiple computing, networking and storage components, unless all components can be fully exploited at 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 lack this capability.

'''The infrastructure scalability challenge''' is automatically resolved once the performance challenge is resolved without negatively impacting reliability -- "best effort" performance" meets "best effort reliability". This requires inductive performance and reliability measures or deliveries.

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, an inductive statistic multiplexed blockchain protocol is needed to meet the scalability challenge. Non-inductive solutions such as fixed chain "sharding" or "Danksharding" <ref>https://ethereum.org/en/roadmap/danksharding/</ref> will only increase protocol development complexity with persistent performance walls.

== A Scalability Solution ==
An effective scalability solution can have two practical assumptions:

* The computation problem size can expand indefinitely, since every useful infrastructure is expected to solve bigger problems.

*Computing and network resources will continue to grow indefinitely, into the future.
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 <ref>https://en.wikipedia.org/wiki/Amdahl%27s_law</ref> and Gustafson's Law <ref>https://en.wikipedia.org/wiki/Gustafson%27s_law</ref>.

The Amdahl's Law assumes 0<= ''s'' <=1 percentage of serial instructions that cannot be parallelized. Then the ''(1-s)'' percentage of instructions can be accelerated using ''p'' processors.

<div style="text-align: center;">
Speedup(p) = <math>{1 \over s + {(1-s) \over p}}</math> (1) <br>Speedup(<math>\lim_{p \to \infty}</math>) = <math>\frac{1}{s}</math> (2)
</div>
Taking ''p'' to infinity in equation (1) yields equation (2). But this derivation step has two different operational semantics: a) increasing ''p'' to further reduce the value of (''1-s)/p'' solving the same problem. This will result ''s'' asymptotically approaching 1. Thus the speedup is above founded to 1. Or b) increasing ''p'' to increase the parallel percentage ''(1-s)'' by solving bigger problems. This will force ''s'' asymptotically approach 0. Then the speedup is above bounded by <math>\infty</math>. This scaling ambiguity caused more than three decades of confusion in the community.

Although quantifying ''s'' requires additional information, such as the problem size, the model is applicable to programs solving any problem size with any percentage ''s''. The limit of speedup (2) also does not depend on problem size. However, since Amdahl originally used programs solving fixed problem sizes to argue the validity of not building parallel machines with too many processors, assuming fixed problem size using ''p'' processors has been the norm in interpreting Amdahl's law in the past. This assumption has led to the dismal speedup predictions.[[File:Amdahl's Law.png|thumb|Amdahl's Law Speedup Predictions|center]]The traditional Amdahl's Law interpretation seems to suggest parallel performances following the economic law of diminishing of returns, even though the mathematic model implies more potentials.

In 1988, Gustafson and Barsis at the Sandia National Laboratory conducted parallel computing experiments that seem to suggest potential infinite speedup.

Gustafson's Law was based on measured sequential and parallel elapsed times using ''p'' (=1024) processors. A new sequential percentage ''0<=x'<=1'' can be calculated using ''p'' processors. ''(1-x')'' is the parallel percentage using ''p'' processors.

To estimate accomplished speedup, Gustafson's Law states:

<div style="text-align: center;">
<math>Speedup=\frac{Tseq}{Tpar}=\frac{s'+(1-s')p}{1}=s'+(1-s')p </math> (3)
</div>

Take ''p'' -> <math>\infty</math> for equation (3) also has two operational semantics: a) Keep the problem size fixed, adding processors to further reduce the total parallel processing time, thus bigger s'. This will yield s' approaching 1. Thus speedup is also bounded to 1. Or b) expanding the problem size to allow the parallel part expanded solving bigger problems. This will yield s' asymptotically approaching 0. Speedup will be above bounded to ''p''. Gustafson's Law was used to argue for Massively Parallel Computing (MPC) (or ManyCPU) experiments and Amdahl's Law was used to argue for bigger mainframe (or BigCPU) computer architectures. In the past decades, these laws have been used to support two diverging computing system experiments and constructions until recent convergence.
[[File:Gustafson.png|thumb|Gustafson's Law|center]]
It is now obvious that the two law are identical with Amdahl's Law more succinct. But Gustafson's formula helps to quantify the serial percentages from practical program executions. In fact, the two serial percentages can be related by a simple equation<ref>https://www.researchgate.net/publication/228367369_Reevaluating_Amdahl's_law_and_Gustafson's_law</ref>:

<div style="text-align: center;">
<math>s=\frac{s'}{s'+(1-s')p}</math> (4)
</div>

Both law actually refer to the same mathematical abstraction. Gustafson's formula assisted in quantifying the percentage of serial computing through program experiments. Neither should be directly used for speedup prediction alone.

This model can be validated in practice when developers simply increasing the problem size to use more parallel processors.

[[File:Full Range Amdah's Law .png|alt=Full Power of Amdahl's Law|center|thumb|Full Power of Amdahl's Law]]

If we plot the full speedup curves against the number of processors, we will see the missing lines from the previous Amdahl's dismal prediction chart.

[[File:DiminishingReturn2.png|alt=infinite Speedup Under Amdahl's Law|center|thumb|Infinite Speedup in Amdahl's Law|400x400px]]

A classical example is the TOP500 supercomputer benchmarks (linear solvers) that have open problem sizes for all manufacturers to compete in the world's fastest supercomputer race <ref>https://www.top500.org/</ref> .
[[File:Supercomputers-history.png|center|thumb]]
In practical blockchain applications, the number of transactions to be processed will increase without a known limit. The ledger storage will continue to grow. In practice, the available computing, networking and storage components will continue to grow without limits enabled by the networking protocols. Therefore a statistic multiplexed computing blockchain can meet any future application needs given proper economic incentives. The infrastructure no longer has the structural deficiency.

== Action Plan ==

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.

For Toichain protocol design, we choose Bitcoin 24.0.1 as the base line protocol by replacing the PoW consensus by PoS consensus and injecting SMC components into the protocol processing signaling for parallel computing.

This surprising result is also applicable to ledger storage. Without multiplexing, the blockchain ledger storage will eventually saturate all nodes causing the chain to collapse. The SMC blockchain protocol promises to hold the true finality of all transactions in perpetuity by multiplexing all storage resources while keeping the replication factor to a constant.

These discussions follow the inductive logic of the Law of Large Numbers <ref>https://www.sciencedirect.com/topics/mathematics/laws-of-large-number</ref>.

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

= SMC Proof of Stake Protocol =
Existing PoS protocol designs revolved around staking policies and randomness of the selection algorithm. Considering infrastructure scalability will add much complexity to the design. The examples include chain sharding and Danksharding <ref>https://ethereum.org/en/roadmap/danksharding/</ref>.

The challenge is complex -- we must deliver very high performance without compromising security and reliability of the network.

Technically, transaction replication and parallel processing were considered dangerous <ref>https://pages.cs.wisc.edu/~yxy/cs764-f20/papers/replication.pdf</ref> due to the potential race conditions (or double-spend problem). The blockchain protocol resolved the double-spending problem. It did not solve the parallel processing performance problem.

According to Professor Michael Flynn, there are three high-level parallel processing topologies: SIMD (single instruction multiple data), MIMD (multiple instructions multiple data), and pipeline (MISD - multiple instructions single data stream) <ref>https://link.springer.com/referenceworkentry/10.1007/978-0-387-09766-4_2</ref>. However, for eliminating double-spending, all transactions must be serialized, since each block may contain transactions affecting transactions in multiple other blocks. "Race conditions" and non-deterministic results are not allowed. Then the only possible topology entry is pipeline. This means for POS protocol, we must build a pipeline of transaction blocks to be validated without compromising network security and reliability.
[[File:Flynns-Taxonomy-of-Computer-Architectures.png|center|thumb|Parallel Processing Topologies]]
The problem is that the nature of the blockchain protocol is that all nodes run independently in parallel with little communication with other nodes via "gossip" protocols. It is far easier to force all nodes store the entire ledger than forcing them to form any pipeline and store partial chain data.

=== ACAN (Active Content Addressable Network) [U.S. PTO #11,588,926 B2] ===
ACAN is a high-level data '''''communication and synchronization protocol''''' that completely decouples all hardware components from communicating programs. The need for complete component decoupling was implemented in the original blockchain protocol via "gossip" protocol. This delivered blockchain's high availability and security. The simple "gossip" implementation in existing protocols is insufficient for parallel processing signaling.

The following figure illustrates the concept of ACAN (active content addressable networking) using UVR (unidirectional virtual ring) architecture. The illustrated implementation uses the Tuple Space resource tagging method and gossip protocol for UVR implementation.
[[File:SMC Architecture with ACAN.png|center|thumb|243x243px|SMC Architecture with ACAN]]

ACAN supports three simple APIs:

# '''read'''(&''key'', &''value''): ''key'' holds a search pattern in a "tuple space" where all nodes are connected. ''value'' holds the matched tuple, if any. This is a blocking call that a requesting program will be blocked until a pattern-matched tuple is found. The matching tuple remains in the "tuple space".
# '''get'''(&key, &value): Same as the "read()" API, except that the matching tuple is removed from the "tuple space".
# '''put'''(key, value): Inserts <key, value> into the "tuple space".

The use of "gossip" protocol can accelerate ACAN network saturation time. Applications running on ACAN will automatically form parallel processing topologies: pipeline, SIMD and MIMD without violating the serialization needs of transaction block validation. Replication factor can also be dynamically controlled to spread replicated blocks in randomly chosen hosts.

The highly parallel nature of the blockchain protocol will automatically implement the SMC principle in real time.

The critical feature of this dynamic SMC pipelined architecture is the inductive scaling feature.
[[File:Pipeline Parallel Processing.png|center|thumb|247x247px|Pipeline Parallel Processing]]

The speed up of a pipeline can be represented as: <math>SpeedUp = \left ( \frac{p\centerdot b}{p + (b-1)} \right )</math>, where p = number of processors in the pipeline, b = total blocks to be processed. Take the number of blocks to infinity:

<div style="text-align: center;">
<math>SpeedUp = \left ( \frac{p\centerdot b}{p + (b-1)} \right )=>\lim (b\Rightarrow\infty)(\frac{p}{\frac{p}{b}+1-\frac{1}{b}}) = p</math>
</div>

This means that as long as there are enough blocks to be processed, the entire chain's performance will be above bounded to the number of nodes in the pipeline.

For illustration purposes, the variation of block processing times was not considered in the above calculations. To see the power of pipeline parallelism, the automobile manufacturing processes illustrate a similar situation. The Hyundai Motor Company's production pipelines can produce 3,835 vehicles per day and 1.4M per year<ref>https://en.wikipedia.org/wiki/List_of_Hyundai_Motor_Company_manufacturing_facilities</ref>.

== Toichain Tokens ==
Toichain token is TOIN. There are 50,000,000,000 TOINs for the Alpha Release. There are air-drop tokens for early adopters, 1,000 TOIN each. Users need to register to download a toichain wallet to receive the payment. Citizenship is checked and verified to ensure that US citizens do not apply. The minimal staking contract is 10 TOINs.

== Non-Fungible Tokens ==
The TestNet Release of toichain protocol will support embedding arbitrary data in an "OP_RETURN" transaction that will be permanently recorded on the chain. Unlike the ordinal NFT <ref>https://blog.chain.link/ordinals-bitcoin-nfts/</ref> or NFT (non-fungible token) on other chains, these transactions cannot be altered or removed.

There are practical applications for these forever NFTs. Once Taproot is enabled on toichain, ordinal NFTs (BRC-20) will also be supported. Unlike the original Bitcoin network where BRC-20 craze has created massive network congestion<ref>https://beincrypto.com/learn/brc-20-token/</ref>, all transactions will be processed promptly in toichain without congestion or scaling problems.
== Toichain TestNet Launch ==
The toichain testnet launch will enable users to interact with one another through simple payments, just like the original Bitcoin network. Forever NFTs are supported. Smart contracts will be supported on a later date.

= References =
<references />

Consult the [[mediawikiwiki:Special:MyLanguage/Help:Contents|User's Guide]] for information on using the wiki software.

Main Page

2024-10-13T14:16:24Z

Justin: /* ACAN (Active Content Addressable Network) [U.S. PTO #11,588,926 B2] */

= <strong><big>'''Welcome to Toi-Twiki -- A Toichain Wiki'''</big></strong> =
This is the unofficial Toichain wiki site. Content is subject to changes.
---------------------------

= '''Introduction''' =
The blockchain protocol was introduced in a seminal paper entitled "Bitcoin: A peer-to-peer Electronic Cash System" <ref>https://bitcoin.org/bitcoin.pdf</ref> by Satoshi Nakamoto in 2008. Although there were previous peer-to-peer file-sharing projects such as Napster <ref>https://www.napster.com/us</ref>, BitTorrent <ref>https://www.bittorrent.com/</ref> and other electronic currency/file sharing applications, Bitcoin is the most enduring among the 23,000+ blockchains. Unlike other cryptocurrencies, the Bitcoin is often referred to as "digital gold" since the total coin supply is limited to 21 million (hard-coded in all running programs) and the only way to earn coin is to participate in the transaction block validation process. Token(or coin) supply and their disbursement policies differ among protocols.

The most attractive common blockchain features are 1) a decentralized consensus-driven decision making process and 2) a step-by-step cryptographic proving system. While blockchain is best known as a cryptocurrency transaction processing and record-keeping system, there are many other applications that can benefit from the secure storage, reliable transaction ledgers, fault tolerance and tamper resistance features.

== Algorithm vs. Protocol ==
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 ==
A good consensus protocol in a blockchain system has at least four properties:

# Fault tolerance to defend failures caused by natural disasters and human hacks or accidents
# Byzantine failure tolerance to defend exploitation by colluding parties
# Centralization avoidance to prevent corruptions in the decision making process
# Source code tamper resistance to automatically reject malicious attacks

Without assuming all nodes are active at all times, the blockchain relies on "gossip" protocol to communicate with other nodes. There are two popular types of consensus protocols: Proof of Work ('''PoW''') <ref>https://en.wikipedia.org/wiki/Proof_of_work</ref> or Proof of Stake ('''PoS''') <ref>https://www.investopedia.com/terms/p/proof-stake-pos.asp</ref>. Others include Proof of Possession('''PoP''')<ref>https://identityserver4.readthedocs.io/en/latest/topics/pop.html</ref> and Proof of History('''PoH''')<ref>https://www.infoworld.com/article/3666736/solana-blockchain-and-the-proof-of-history.html</ref>. The ultimate goal is to eliminate double-spending. Since most projects are open source, it's easy for a malicious actor to tamper a few nodes. This shouldn't compromise network integrity.

The Bitcoin network uses PoW which forces participating miners to compete for the fastest hashing rate by solving a computational cryptographic puzzle. Although it withstood more than 14 years of use, Bitcoin has been criticized for escalating electricity consumption <ref>https://www.forbes.com/advisor/investing/cryptocurrency/bitcoins-energy-usage-explained/</ref>. Other blockchain designs have experienced different challenges. For example, the PoH network Solana suffered multiple single-point-failure incidents <ref>https://messari.io/report/solana-analyzing-downtimes-statistics-and-ecosystem-development</ref>. All protocols struggle to combat scaling challenges. All are susceptible to 51% attacks <ref>https://originstamp.com/blog/has-there-ever-been-a-51-attack-on-bitcoin/#notable-51-attacks</ref>.

Since 2009, Bitcoin has proven to be the strongest and least susceptible to common hacks <ref>https://www.theguardian.com/technology/2014/mar/18/history-of-bitcoin-hacks-alternative-currency</ref>. As the PoW puzzle difficulty has increased dramatically over the years, the probability of a 51% attack on the Bitcoin network becomes more difficult. PoS protocols can save more than 90% energy consumption compared to PoW chains. But PoS chains have higher risks than PoW chains since a stolen coin will grow in PoS chains (for increased probability to be selected) forever but not in PoW chains (only hash rates count). PoS community governance rules can mitigate the voting power centralization problem. Staking and slashing policies can incentivize good behaviors and punish bad ones. In either case, double-spend is very expensive and difficult. According to Forbes, there are 80 cryptocurrencies that use PoS protocols at the time of this writing.

There are approximately 1,000 blockchains in four types: public, private, consortium, and permissioned <ref>https://increditools.com/blockchains/</ref>.

== Cryptographic Proofs ==
Bitcoin 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.

== Centralized vs. Decentralized Applications ==
The Bitcoin protocol enabled decentralized processing of traditionally centrally processed transactions without any trusted third-party. It inspired many decentralized financial applications, especially for applications with very long payment chains. However for fraud prevention and meeting financial regulatory requirements, many practical applications still require KYC (know your customer) checks. It is not possible to eliminate all trusted third parties, especially for custodial financial applications. There is a clear need for decentralized processing of trusted authority applications.

== Blockchain Trilemma ==
Blockchain protocols have three common aspects (goals): '''security''', '''decentralization''' and '''scalability''' -- these three terms do not have precise definitions but are intuitively understood <ref>https://sensoriumxr.com/articles/what-is-the-blockchain-trilemma</ref>. To date, 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.

A major shortcoming is scalability. Since all nodes verify each transaction independently, they need to store all the information required for it. As the chain grows, this burdens all nodes in the network. There are workarounds by limiting the amount of data stored on some nodes and exploiting the network to retrieve required information, such as the ''Limited/Light Nodes'' in Bitcoin network. Vast majority nodes are still full nodes in the existing Bitcoin network. Transaction processing speed often expressed ''as transactions per second(TPS) of'' blockchain have to exceed TPS ratings of credit card payment systems like VISA or MasterCard to reap the full benefits of blockchain. This is a tough problem and increasing the block size and/or reducing the block time or difficulty isn't a solution<ref>https://medium.com/coinmonks/blockchain-scaling-30c9e1b7db1b</ref>. Since blockchain TPS is very low, the transaction fees is often very high. This discourages public adoption. Layer 2 solution like ''Lightning Network'' or ''ZK-rollups,'' where only final settlement is on the main chain tend to address these issues. However, one could always argue that this often compromises some aspects of security and/or decentralization to achieve high TPS.

The trilemma was first introduced by Vitalik Buterin<ref>https://en.wikipedia.org/wiki/Vitalik_Buterin</ref>, one of the co-founders of Ethereum network. The problems he identified are real. There seem to be no obvious solutions that can accomplish all three goals at the same time. Therefore, all proposed solutions revolve around reducing "opportunity costs" focusing only on satisfying partial goals.

Treating the blockchain network as an infrastructure for transaction processing, the blockchain protocol solved service reliability problem but not performance challenge. The legacy infrastructure scaling dilemma: performance against reliability remains (where "infrastructure reliability" also does not have a commonly accepted definition). Fortunately these metrics, although important, are non-critical. Solutions that have been proposed have had varying opportunity costs. For many years, there were no obvious solutions that addressed all three blockchain goals (security, decentralization and scalability).
== Statistic Multiplexed Computing (SMC) ==
The principle of using unreliable components to build an arbitrarily reliable system was first lectured by von Neumann in the early 1950s<ref>https://static.ias.edu/pitp/archive/2012files/Probabilistic_Logics.pdf</ref>. The original idea was to use probabilistic logic to quantify the arbitrary reliability of a system by multiplexing all components. This theory was applied to the construction of Internet protocols to deliver the "best effort" reliability. Incidentally, best effort reliability also enabled "best effort" performance which in turn enabled unlimited scalability of the Internet. For emerging web3.0 technologies, it is important to apply the same methodology to both centralized and decentralized computing for seamless technology migration and integration. For historical arguments, click [[SMC|'''''here''''']].

== Definitions ==
'''Infrastructure scalability''' does not have a commonly accepted definition. It helps to define the challenging metrics more precisely before the infrastructure protocol design. In the following, for definitions #1 and #2, the word "'''infrastructure'''" means any '''application running on the infrastructure.'''

# '''Infrastructure Reliability''': MTBF (mean time between failure) = <math>\frac{\sum ((Start-Of-Downtime) - (Start-of-uptime)) }{No-of-failures}</math>
# '''Infrastructure Performance''': <math>\frac{No-of-Transactions}{Second}</math>
# '''Infrastructure Scalability''': Expanding the infrastructure in number of processors, networks or storage should have '''incrementally better''' impacts on application reliability and performance.
# '''Record Immutability''': For transaction ledgers, all confirmed records and changes are final. This is required by the blockchain protocol.
Note that in practice, record immutability is much harder to achieve than expected. There are two challenges, a) 51% attacks can literally wipe out all histories if successful, and b) for protocols require all nodes to hold independently verified ledger, such as the Bitcoin, the storage requirement grows approximately 50GB per month.

== 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 and considered.

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 crashe'''s <ref>https://groups.csail.mit.edu/tds/papers/Lynch/jacm93.pdf</ref>. The laws of physics regarding component reliability <ref>Encyclopedia of Physical Science and Technology, Editor-in-Chief Robert A. Meyers, [[index.php?title=Special:BookSources/9780122274107|ISBN 978-0-12-227410-7]], 2001</ref> show that '''100% component reliability is not possible.''' These facts require that the infrastructure protocol (program-program communication protocol) provide '''complete component (processing, networking and storage) decoupling''' from application program logics. This decoupling requirement forces the protocol to exploit "decentralized" or "stateless" components that the legacy infrastructure protocols, such as message passing interface (MPI), remote procedure call (RPC) and remote method invocation (RMI), cannot handle. The blockchain protocol is an example of a "best effort" availability protocol.

Quantifying infrastructure reliability can be traced back to the computer pioneer von Neumann. In addition to his contribution to computer architecture, von Neumann also penned a study on building reliable systems using unreliable components using probabilistic logics, in early fifties <ref>https://static.ias.edu/pitp/archive/2012files/Probabilistic_Logics.pdf</ref>. The 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 "best effort" reliability. Ironically, this best effort reliability also enabled the Internet's infinite scalability -- the benefit we enjoy now and into the future.

The Bitcoin protocol exploits multiple anonymous decoupled (or decentralized) computers connected through the Internet protocol. Judging from the Bitcoin network's reliability to date <ref>https://buybitcoinworldwide.com/bitcoin-downtime/</ref>, von Neumann's theory seems working well.

The '''second challenge''' involves infrastructure performance. Since the infrastructure must deploy multiple computing, networking and storage components, unless all components can be fully exploited at 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 lack this capability.

'''The infrastructure scalability challenge''' is automatically resolved once the performance challenge is resolved without negatively impacting reliability -- "best effort" performance" meets "best effort reliability". This requires inductive performance and reliability measures or deliveries.

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, an inductive statistic multiplexed blockchain protocol is needed to meet the scalability challenge. Non-inductive solutions such as fixed chain "sharding" or "Danksharding" <ref>https://ethereum.org/en/roadmap/danksharding/</ref> will only increase protocol development complexity with persistent performance walls.

== A Scalability Solution ==
An effective scalability solution can have two practical assumptions:

* The computation problem size can expand indefinitely, since every useful infrastructure is expected to solve bigger problems.

*Computing and network resources will continue to grow indefinitely, into the future.
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 <ref>https://en.wikipedia.org/wiki/Amdahl%27s_law</ref> and Gustafson's Law <ref>https://en.wikipedia.org/wiki/Gustafson%27s_law</ref>.

The Amdahl's Law assumes 0<= ''s'' <=1 percentage of serial instructions that cannot be parallelized. Then the ''(1-s)'' percentage of instructions can be accelerated using ''p'' processors.

<div style="text-align: center;">
Speedup(p) = <math>{1 \over s + {(1-s) \over p}}</math> (1) <br>Speedup(<math>\lim_{p \to \infty}</math>) = <math>\frac{1}{s}</math> (2)
</div>
Taking ''p'' to infinity in equation (1) yields equation (2). But this derivation step has two different operational semantics: a) increasing ''p'' to further reduce the value of (''1-s)/p'' solving the same problem. This will result ''s'' asymptotically approaching 1. Thus the speedup is above founded to 1. Or b) increasing ''p'' to increase the parallel percentage ''(1-s)'' by solving bigger problems. This will force ''s'' asymptotically approach 0. Then the speedup is above bounded by <math>\infty</math>. This scaling ambiguity caused more than three decades of confusion in the community.

Although quantifying ''s'' requires additional information, such as the problem size, the model is applicable to programs solving any problem size with any percentage ''s''. The limit of speedup (2) also does not depend on problem size. However, since Amdahl originally used programs solving fixed problem sizes to argue the validity of not building parallel machines with too many processors, assuming fixed problem size using ''p'' processors has been the norm in interpreting Amdahl's law in the past. This assumption has led to the dismal speedup predictions.[[File:Amdahl's Law.png|thumb|Amdahl's Law Speedup Predictions|center]]The traditional Amdahl's Law interpretation seems to suggest parallel performances following the economic law of diminishing of returns, even though the mathematic model implies more potentials.

In 1988, Gustafson and Barsis at the Sandia National Laboratory conducted parallel computing experiments that seem to suggest potential infinite speedup.

Gustafson's Law was based on measured sequential and parallel elapsed times using ''p'' (=1024) processors. A new sequential percentage ''0<=x'<=1'' can be calculated using ''p'' processors. ''(1-x')'' is the parallel percentage using ''p'' processors.

To estimate accomplished speedup, Gustafson's Law states:

<div style="text-align: center;">
<math>Speedup=\frac{Tseq}{Tpar}=\frac{s'+(1-s')p}{1}=s'+(1-s')p </math> (3)
</div>

Take ''p'' -> <math>\infty</math> for equation (3) also has two operational semantics: a) Keep the problem size fixed, adding processors to further reduce the total parallel processing time, thus bigger s'. This will yield s' approaching 1. Thus speedup is also bounded to 1. Or b) expanding the problem size to allow the parallel part expanded solving bigger problems. This will yield s' asymptotically approaching 0. Speedup will be above bounded to ''p''. Gustafson's Law was used to argue for Massively Parallel Computing (MPC) (or ManyCPU) experiments and Amdahl's Law was used to argue for bigger mainframe (or BigCPU) computer architectures. In the past decades, these laws have been used to support two diverging computing system experiments and constructions until recent convergence.
[[File:Gustafson.png|thumb|Gustafson's Law|center]]
It is now obvious that the two law are identical with Amdahl's Law more succinct. But Gustafson's formula helps to quantify the serial percentages from practical program executions. In fact, the two serial percentages can be related by a simple equation<ref>https://www.researchgate.net/publication/228367369_Reevaluating_Amdahl's_law_and_Gustafson's_law</ref>:

<div style="text-align: center;">
<math>s=\frac{s'}{s'+(1-s')p}</math> (4)
</div>

Both law actually refer to the same mathematical abstraction. Gustafson's formula assisted in quantifying the percentage of serial computing through program experiments. Neither should be directly used for speedup prediction alone.

This model can be validated in practice when developers simply increasing the problem size to use more parallel processors.

[[File:Full Range Amdah's Law .png|alt=Full Power of Amdahl's Law|center|thumb|Full Power of Amdahl's Law]]

If we plot the full speedup curves against the number of processors, we will see the missing lines.

[[File:DiminishingReturn2.png|alt=infinite Speedup Under Amdahl's Law|center|thumb|Infinite Speedup in Amdahl's Law|400x400px]]

A classical example is the TOP500 supercomputer benchmarks (linear solvers) that have open problem sizes for all manufacturers to compete in the world's fastest supercomputer race <ref>https://www.top500.org/</ref> .
[[File:Supercomputers-history.png|center|thumb]]
In practical blockchain applications, the number of transactions to be processed will increase without a known limit. The ledger storage will continue to grow. In practice, the available computing, networking and storage components will continue to grow without limits enabled by the networking protocols. Therefore a statistic multiplexed computing blockchain can meet any future application needs given proper economic incentives. The infrastructure no longer has the structural deficiency.

== Action Plan ==

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.

For Toichain protocol design, we choose Bitcoin 24.0.1 as the base line protocol by replacing the PoW consensus by PoS consensus and injecting SMC components into the protocol processing signaling for parallel computing.

This surprising result is also applicable to ledger storage. Without multiplexing, the blockchain ledger storage will eventually saturate all nodes causing the chain to collapse. The SMC blockchain protocol promises to hold the true finality of all transactions in perpetuity by multiplexing all storage resources while keeping the replication factor to a constant.

These discussions follow the inductive logic of the Law of Large Numbers <ref>https://www.sciencedirect.com/topics/mathematics/laws-of-large-number</ref>.

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

= SMC Proof of Stake Protocol =
Existing PoS protocol designs revolved around staking policies and randomness of the selection algorithm. Considering infrastructure scalability will add much complexity to the design. The examples include chain sharding and Danksharding <ref>https://ethereum.org/en/roadmap/danksharding/</ref>.

The challenge is complex -- we must deliver very high performance without compromising security and reliability of the network.

Technically, transaction replication and parallel processing were considered dangerous <ref>https://pages.cs.wisc.edu/~yxy/cs764-f20/papers/replication.pdf</ref> due to the potential race conditions (or double-spend problem). The blockchain protocol resolved the double-spending problem. It did not solve the parallel processing performance problem.

According to Professor Michael Flynn, there are three high-level parallel processing topologies: SIMD (single instruction multiple data), MIMD (multiple instructions multiple data), and pipeline (MISD - multiple instructions single data stream) <ref>https://link.springer.com/referenceworkentry/10.1007/978-0-387-09766-4_2</ref>. However, for eliminating double-spending, all transactions must be serialized, since each block may contain transactions affecting transactions in multiple other blocks. "Race conditions" and non-deterministic results are not allowed. Then the only possible topology entry is pipeline. This means for POS protocol, we must build a pipeline of transaction blocks to be validated without compromising network security and reliability.
[[File:Flynns-Taxonomy-of-Computer-Architectures.png|center|thumb|Parallel Processing Topologies]]
The problem is that the nature of the blockchain protocol is that all nodes run independently in parallel with little communication with other nodes via "gossip" protocols. It is far easier to force all nodes store the entire ledger than forcing them to form any pipeline and store partial chain data.

=== ACAN (Active Content Addressable Network) [U.S. PTO #11,588,926 B2] ===
ACAN is a high-level data '''''communication and synchronization protocol''''' that completely decouples all hardware components from communicating programs. The need for complete component decoupling was implemented in the original blockchain protocol via "gossip" protocol. This delivered blockchain's high availability and security. The simple "gossip" implementation in existing protocols is insufficient for parallel processing signaling.

The following figure illustrates the concept of ACAN (active content addressable networking) using UVR (unidirectional virtual ring) architecture. The illustrated implementation uses the Tuple Space resource tagging method and gossip protocol for UVR implementation.
[[File:SMC Architecture with ACAN.png|center|thumb|243x243px|SMC Architecture with ACAN]]

ACAN supports three simple APIs:

# '''read'''(&''key'', &''value''): ''key'' holds a search pattern in a "tuple space" where all nodes are connected. ''value'' holds the matched tuple, if any. This is a blocking call that a requesting program will be blocked until a pattern-matched tuple is found. The matching tuple remains in the "tuple space".
# '''get'''(&key, &value): Same as the "read()" API, except that the matching tuple is removed from the "tuple space".
# '''put'''(key, value): Inserts <key, value> into the "tuple space".

The use of "gossip" protocol can accelerate ACAN network saturation time. Applications running on ACAN will automatically form parallel processing topologies: pipeline, SIMD and MIMD without violating the serialization needs of transaction block validation. Replication factor can also be dynamically controlled to spread replicated blocks in randomly chosen hosts.

The highly parallel nature of the blockchain protocol will automatically implement the SMC principle in real time.

The critical feature of this dynamic SMC pipelined architecture is the inductive scaling feature.
[[File:Pipeline Parallel Processing.png|center|thumb|247x247px|Pipeline Parallel Processing]]

The speed up of a pipeline can be represented as: <math>SpeedUp = \left ( \frac{p\centerdot b}{p + (b-1)} \right )</math>, where p = number of processors in the pipeline, b = total blocks to be processed. Take the number of blocks to infinity:

<div style="text-align: center;">
<math>SpeedUp = \left ( \frac{p\centerdot b}{p + (b-1)} \right )=>\lim (b\Rightarrow\infty)(\frac{p}{\frac{p}{b}+1-\frac{1}{b}}) = p</math>
</div>

This means that as long as there are enough blocks to be processed, the entire chain's performance will be above bounded to the number of nodes in the pipeline.

For illustration purposes, the variation of block processing times was not considered in the above calculations. To see the power of pipeline parallelism, the automobile manufacturing processes illustrate a similar situation. The Hyundai Motor Company's production pipelines can produce 3,835 vehicles per day and 1.4M per year<ref>https://en.wikipedia.org/wiki/List_of_Hyundai_Motor_Company_manufacturing_facilities</ref>.

== Toichain Tokens ==
Toichain token is TOIN. There are 50,000,000,000 TOINs for the Alpha Release. There are air-drop tokens for early adopters, 1,000 TOIN each. Users need to register to download a toichain wallet to receive the payment. Citizenship is checked and verified to ensure that US citizens do not apply. The minimal staking contract is 10 TOINs.

== Non-Fungible Tokens ==
The TestNet Release of toichain protocol will support embedding arbitrary data in an "OP_RETURN" transaction that will be permanently recorded on the chain. Unlike the ordinal NFT <ref>https://blog.chain.link/ordinals-bitcoin-nfts/</ref> or NFT (non-fungible token) on other chains, these transactions cannot be altered or removed.

There are practical applications for these forever NFTs. Once Taproot is enabled on toichain, ordinal NFTs (BRC-20) will also be supported. Unlike the original Bitcoin network where BRC-20 craze has created massive network congestion<ref>https://beincrypto.com/learn/brc-20-token/</ref>, all transactions will be processed promptly in toichain without congestion or scaling problems.
== Toichain TestNet Launch ==
The toichain testnet launch will enable users to interact with one another through simple payments, just like the original Bitcoin network. Forever NFTs are supported. Smart contracts will be supported on a later date.

= References =
<references />

Consult the [[mediawikiwiki:Special:MyLanguage/Help:Contents|User's Guide]] for information on using the wiki software.

Main Page

2024-10-13T14:13:20Z

Justin: /* A Scalability Solution */

= <strong><big>'''Welcome to Toi-Twiki -- A Toichain Wiki'''</big></strong> =
This is the unofficial Toichain wiki site. Content is subject to changes.
---------------------------

= '''Introduction''' =
The blockchain protocol was introduced in a seminal paper entitled "Bitcoin: A peer-to-peer Electronic Cash System" <ref>https://bitcoin.org/bitcoin.pdf</ref> by Satoshi Nakamoto in 2008. Although there were previous peer-to-peer file-sharing projects such as Napster <ref>https://www.napster.com/us</ref>, BitTorrent <ref>https://www.bittorrent.com/</ref> and other electronic currency/file sharing applications, Bitcoin is the most enduring among the 23,000+ blockchains. Unlike other cryptocurrencies, the Bitcoin is often referred to as "digital gold" since the total coin supply is limited to 21 million (hard-coded in all running programs) and the only way to earn coin is to participate in the transaction block validation process. Token(or coin) supply and their disbursement policies differ among protocols.

The most attractive common blockchain features are 1) a decentralized consensus-driven decision making process and 2) a step-by-step cryptographic proving system. While blockchain is best known as a cryptocurrency transaction processing and record-keeping system, there are many other applications that can benefit from the secure storage, reliable transaction ledgers, fault tolerance and tamper resistance features.

== Algorithm vs. Protocol ==
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 ==
A good consensus protocol in a blockchain system has at least four properties:

# Fault tolerance to defend failures caused by natural disasters and human hacks or accidents
# Byzantine failure tolerance to defend exploitation by colluding parties
# Centralization avoidance to prevent corruptions in the decision making process
# Source code tamper resistance to automatically reject malicious attacks

Without assuming all nodes are active at all times, the blockchain relies on "gossip" protocol to communicate with other nodes. There are two popular types of consensus protocols: Proof of Work ('''PoW''') <ref>https://en.wikipedia.org/wiki/Proof_of_work</ref> or Proof of Stake ('''PoS''') <ref>https://www.investopedia.com/terms/p/proof-stake-pos.asp</ref>. Others include Proof of Possession('''PoP''')<ref>https://identityserver4.readthedocs.io/en/latest/topics/pop.html</ref> and Proof of History('''PoH''')<ref>https://www.infoworld.com/article/3666736/solana-blockchain-and-the-proof-of-history.html</ref>. The ultimate goal is to eliminate double-spending. Since most projects are open source, it's easy for a malicious actor to tamper a few nodes. This shouldn't compromise network integrity.

The Bitcoin network uses PoW which forces participating miners to compete for the fastest hashing rate by solving a computational cryptographic puzzle. Although it withstood more than 14 years of use, Bitcoin has been criticized for escalating electricity consumption <ref>https://www.forbes.com/advisor/investing/cryptocurrency/bitcoins-energy-usage-explained/</ref>. Other blockchain designs have experienced different challenges. For example, the PoH network Solana suffered multiple single-point-failure incidents <ref>https://messari.io/report/solana-analyzing-downtimes-statistics-and-ecosystem-development</ref>. All protocols struggle to combat scaling challenges. All are susceptible to 51% attacks <ref>https://originstamp.com/blog/has-there-ever-been-a-51-attack-on-bitcoin/#notable-51-attacks</ref>.

Since 2009, Bitcoin has proven to be the strongest and least susceptible to common hacks <ref>https://www.theguardian.com/technology/2014/mar/18/history-of-bitcoin-hacks-alternative-currency</ref>. As the PoW puzzle difficulty has increased dramatically over the years, the probability of a 51% attack on the Bitcoin network becomes more difficult. PoS protocols can save more than 90% energy consumption compared to PoW chains. But PoS chains have higher risks than PoW chains since a stolen coin will grow in PoS chains (for increased probability to be selected) forever but not in PoW chains (only hash rates count). PoS community governance rules can mitigate the voting power centralization problem. Staking and slashing policies can incentivize good behaviors and punish bad ones. In either case, double-spend is very expensive and difficult. According to Forbes, there are 80 cryptocurrencies that use PoS protocols at the time of this writing.

There are approximately 1,000 blockchains in four types: public, private, consortium, and permissioned <ref>https://increditools.com/blockchains/</ref>.

== Cryptographic Proofs ==
Bitcoin 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.

== Centralized vs. Decentralized Applications ==
The Bitcoin protocol enabled decentralized processing of traditionally centrally processed transactions without any trusted third-party. It inspired many decentralized financial applications, especially for applications with very long payment chains. However for fraud prevention and meeting financial regulatory requirements, many practical applications still require KYC (know your customer) checks. It is not possible to eliminate all trusted third parties, especially for custodial financial applications. There is a clear need for decentralized processing of trusted authority applications.

== Blockchain Trilemma ==
Blockchain protocols have three common aspects (goals): '''security''', '''decentralization''' and '''scalability''' -- these three terms do not have precise definitions but are intuitively understood <ref>https://sensoriumxr.com/articles/what-is-the-blockchain-trilemma</ref>. To date, 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.

A major shortcoming is scalability. Since all nodes verify each transaction independently, they need to store all the information required for it. As the chain grows, this burdens all nodes in the network. There are workarounds by limiting the amount of data stored on some nodes and exploiting the network to retrieve required information, such as the ''Limited/Light Nodes'' in Bitcoin network. Vast majority nodes are still full nodes in the existing Bitcoin network. Transaction processing speed often expressed ''as transactions per second(TPS) of'' blockchain have to exceed TPS ratings of credit card payment systems like VISA or MasterCard to reap the full benefits of blockchain. This is a tough problem and increasing the block size and/or reducing the block time or difficulty isn't a solution<ref>https://medium.com/coinmonks/blockchain-scaling-30c9e1b7db1b</ref>. Since blockchain TPS is very low, the transaction fees is often very high. This discourages public adoption. Layer 2 solution like ''Lightning Network'' or ''ZK-rollups,'' where only final settlement is on the main chain tend to address these issues. However, one could always argue that this often compromises some aspects of security and/or decentralization to achieve high TPS.

The trilemma was first introduced by Vitalik Buterin<ref>https://en.wikipedia.org/wiki/Vitalik_Buterin</ref>, one of the co-founders of Ethereum network. The problems he identified are real. There seem to be no obvious solutions that can accomplish all three goals at the same time. Therefore, all proposed solutions revolve around reducing "opportunity costs" focusing only on satisfying partial goals.

Treating the blockchain network as an infrastructure for transaction processing, the blockchain protocol solved service reliability problem but not performance challenge. The legacy infrastructure scaling dilemma: performance against reliability remains (where "infrastructure reliability" also does not have a commonly accepted definition). Fortunately these metrics, although important, are non-critical. Solutions that have been proposed have had varying opportunity costs. For many years, there were no obvious solutions that addressed all three blockchain goals (security, decentralization and scalability).
== Statistic Multiplexed Computing (SMC) ==
The principle of using unreliable components to build an arbitrarily reliable system was first lectured by von Neumann in the early 1950s<ref>https://static.ias.edu/pitp/archive/2012files/Probabilistic_Logics.pdf</ref>. The original idea was to use probabilistic logic to quantify the arbitrary reliability of a system by multiplexing all components. This theory was applied to the construction of Internet protocols to deliver the "best effort" reliability. Incidentally, best effort reliability also enabled "best effort" performance which in turn enabled unlimited scalability of the Internet. For emerging web3.0 technologies, it is important to apply the same methodology to both centralized and decentralized computing for seamless technology migration and integration. For historical arguments, click [[SMC|'''''here''''']].

== Definitions ==
'''Infrastructure scalability''' does not have a commonly accepted definition. It helps to define the challenging metrics more precisely before the infrastructure protocol design. In the following, for definitions #1 and #2, the word "'''infrastructure'''" means any '''application running on the infrastructure.'''

# '''Infrastructure Reliability''': MTBF (mean time between failure) = <math>\frac{\sum ((Start-Of-Downtime) - (Start-of-uptime)) }{No-of-failures}</math>
# '''Infrastructure Performance''': <math>\frac{No-of-Transactions}{Second}</math>
# '''Infrastructure Scalability''': Expanding the infrastructure in number of processors, networks or storage should have '''incrementally better''' impacts on application reliability and performance.
# '''Record Immutability''': For transaction ledgers, all confirmed records and changes are final. This is required by the blockchain protocol.
Note that in practice, record immutability is much harder to achieve than expected. There are two challenges, a) 51% attacks can literally wipe out all histories if successful, and b) for protocols require all nodes to hold independently verified ledger, such as the Bitcoin, the storage requirement grows approximately 50GB per month.

== 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 and considered.

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 crashe'''s <ref>https://groups.csail.mit.edu/tds/papers/Lynch/jacm93.pdf</ref>. The laws of physics regarding component reliability <ref>Encyclopedia of Physical Science and Technology, Editor-in-Chief Robert A. Meyers, [[index.php?title=Special:BookSources/9780122274107|ISBN 978-0-12-227410-7]], 2001</ref> show that '''100% component reliability is not possible.''' These facts require that the infrastructure protocol (program-program communication protocol) provide '''complete component (processing, networking and storage) decoupling''' from application program logics. This decoupling requirement forces the protocol to exploit "decentralized" or "stateless" components that the legacy infrastructure protocols, such as message passing interface (MPI), remote procedure call (RPC) and remote method invocation (RMI), cannot handle. The blockchain protocol is an example of a "best effort" availability protocol.

Quantifying infrastructure reliability can be traced back to the computer pioneer von Neumann. In addition to his contribution to computer architecture, von Neumann also penned a study on building reliable systems using unreliable components using probabilistic logics, in early fifties <ref>https://static.ias.edu/pitp/archive/2012files/Probabilistic_Logics.pdf</ref>. The 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 "best effort" reliability. Ironically, this best effort reliability also enabled the Internet's infinite scalability -- the benefit we enjoy now and into the future.

The Bitcoin protocol exploits multiple anonymous decoupled (or decentralized) computers connected through the Internet protocol. Judging from the Bitcoin network's reliability to date <ref>https://buybitcoinworldwide.com/bitcoin-downtime/</ref>, von Neumann's theory seems working well.

The '''second challenge''' involves infrastructure performance. Since the infrastructure must deploy multiple computing, networking and storage components, unless all components can be fully exploited at 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 lack this capability.

'''The infrastructure scalability challenge''' is automatically resolved once the performance challenge is resolved without negatively impacting reliability -- "best effort" performance" meets "best effort reliability". This requires inductive performance and reliability measures or deliveries.

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, an inductive statistic multiplexed blockchain protocol is needed to meet the scalability challenge. Non-inductive solutions such as fixed chain "sharding" or "Danksharding" <ref>https://ethereum.org/en/roadmap/danksharding/</ref> will only increase protocol development complexity with persistent performance walls.

== A Scalability Solution ==
An effective scalability solution can have two practical assumptions:

* The computation problem size can expand indefinitely, since every useful infrastructure is expected to solve bigger problems.

*Computing and network resources will continue to grow indefinitely, into the future.
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 <ref>https://en.wikipedia.org/wiki/Amdahl%27s_law</ref> and Gustafson's Law <ref>https://en.wikipedia.org/wiki/Gustafson%27s_law</ref>.

The Amdahl's Law assumes 0<= ''s'' <=1 percentage of serial instructions that cannot be parallelized. Then the ''(1-s)'' percentage of instructions can be accelerated using ''p'' processors.

<div style="text-align: center;">
Speedup(p) = <math>{1 \over s + {(1-s) \over p}}</math> (1) <br>Speedup(<math>\lim_{p \to \infty}</math>) = <math>\frac{1}{s}</math> (2)
</div>
Taking ''p'' to infinity in equation (1) yields equation (2). But this derivation step has two different operational semantics: a) increasing ''p'' to further reduce the value of (''1-s)/p'' solving the same problem. This will result ''s'' asymptotically approaching 1. Thus the speedup is above founded to 1. Or b) increasing ''p'' to increase the parallel percentage ''(1-s)'' by solving bigger problems. This will force ''s'' asymptotically approach 0. Then the speedup is above bounded by <math>\infty</math>. This scaling ambiguity caused more than three decades of confusion in the community.

Although quantifying ''s'' requires additional information, such as the problem size, the model is applicable to programs solving any problem size with any percentage ''s''. The limit of speedup (2) also does not depend on problem size. However, since Amdahl originally used programs solving fixed problem sizes to argue the validity of not building parallel machines with too many processors, assuming fixed problem size using ''p'' processors has been the norm in interpreting Amdahl's law in the past. This assumption has led to the dismal speedup predictions.[[File:Amdahl's Law.png|thumb|Amdahl's Law Speedup Predictions|center]]The traditional Amdahl's Law interpretation seems to suggest parallel performances following the economic law of diminishing of returns, even though the mathematic model implies more potentials.

In 1988, Gustafson and Barsis at the Sandia National Laboratory conducted parallel computing experiments that seem to suggest potential infinite speedup.

Gustafson's Law was based on measured sequential and parallel elapsed times using ''p'' (=1024) processors. A new sequential percentage ''0<=x'<=1'' can be calculated using ''p'' processors. ''(1-x')'' is the parallel percentage using ''p'' processors.

To estimate accomplished speedup, Gustafson's Law states:

<div style="text-align: center;">
<math>Speedup=\frac{Tseq}{Tpar}=\frac{s'+(1-s')p}{1}=s'+(1-s')p </math> (3)
</div>

Take ''p'' -> <math>\infty</math> for equation (3) also has two operational semantics: a) Keep the problem size fixed, adding processors to further reduce the total parallel processing time, thus bigger s'. This will yield s' approaching 1. Thus speedup is also bounded to 1. Or b) expanding the problem size to allow the parallel part expanded solving bigger problems. This will yield s' asymptotically approaching 0. Speedup will be above bounded to ''p''. Gustafson's Law was used to argue for Massively Parallel Computing (MPC) (or ManyCPU) experiments and Amdahl's Law was used to argue for bigger mainframe (or BigCPU) computer architectures. In the past decades, these laws have been used to support two diverging computing system experiments and constructions until recent convergence.
[[File:Gustafson.png|thumb|Gustafson's Law|center]]
It is now obvious that the two law are identical with Amdahl's Law more succinct. But Gustafson's formula helps to quantify the serial percentages from practical program executions. In fact, the two serial percentages can be related by a simple equation<ref>https://www.researchgate.net/publication/228367369_Reevaluating_Amdahl's_law_and_Gustafson's_law</ref>:

<div style="text-align: center;">
<math>s=\frac{s'}{s'+(1-s')p}</math> (4)
</div>

Both law actually refer to the same mathematical abstraction. Gustafson's formula assisted in quantifying the percentage of serial computing through program experiments. Neither should be directly used for speedup prediction alone.

This model can be validated in practice when developers simply increasing the problem size to use more parallel processors.

[[File:Full Range Amdah's Law .png|alt=Full Power of Amdahl's Law|center|thumb|Full Power of Amdahl's Law]]

If we plot the full speedup curves against the number of processors, we will see the missing lines.

[[File:DiminishingReturn2.png|alt=infinite Speedup Under Amdahl's Law|center|thumb|Infinite Speedup in Amdahl's Law|400x400px]]

A classical example is the TOP500 supercomputer benchmarks (linear solvers) that have open problem sizes for all manufacturers to compete in the world's fastest supercomputer race <ref>https://www.top500.org/</ref> .
[[File:Supercomputers-history.png|center|thumb]]
In practical blockchain applications, the number of transactions to be processed will increase without a known limit. The ledger storage will continue to grow. In practice, the available computing, networking and storage components will continue to grow without limits enabled by the networking protocols. Therefore a statistic multiplexed computing blockchain can meet any future application needs given proper economic incentives. The infrastructure no longer has the structural deficiency.

== Action Plan ==

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.

For Toichain protocol design, we choose Bitcoin 24.0.1 as the base line protocol by replacing the PoW consensus by PoS consensus and injecting SMC components into the protocol processing signaling for parallel computing.

This surprising result is also applicable to ledger storage. Without multiplexing, the blockchain ledger storage will eventually saturate all nodes causing the chain to collapse. The SMC blockchain protocol promises to hold the true finality of all transactions in perpetuity by multiplexing all storage resources while keeping the replication factor to a constant.

These discussions follow the inductive logic of the Law of Large Numbers <ref>https://www.sciencedirect.com/topics/mathematics/laws-of-large-number</ref>.

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

= SMC Proof of Stake Protocol =
Existing PoS protocol designs revolved around staking policies and randomness of the selection algorithm. Considering infrastructure scalability will add much complexity to the design. The examples include chain sharding and Danksharding <ref>https://ethereum.org/en/roadmap/danksharding/</ref>.

The challenge is complex -- we must deliver very high performance without compromising security and reliability of the network.

Technically, transaction replication and parallel processing were considered dangerous <ref>https://pages.cs.wisc.edu/~yxy/cs764-f20/papers/replication.pdf</ref> due to the potential race conditions (or double-spend problem). The blockchain protocol resolved the double-spending problem. It did not solve the parallel processing performance problem.

According to Professor Michael Flynn, there are three high-level parallel processing topologies: SIMD (single instruction multiple data), MIMD (multiple instructions multiple data), and pipeline (MISD - multiple instructions single data stream) <ref>https://link.springer.com/referenceworkentry/10.1007/978-0-387-09766-4_2</ref>. However, for eliminating double-spending, all transactions must be serialized, since each block may contain transactions affecting transactions in multiple other blocks. "Race conditions" and non-deterministic results are not allowed. Then the only possible topology entry is pipeline. This means for POS protocol, we must build a pipeline of transaction blocks to be validated without compromising network security and reliability.
[[File:Flynns-Taxonomy-of-Computer-Architectures.png|center|thumb|Parallel Processing Topologies]]
The problem is that the nature of the blockchain protocol is that all nodes run independently in parallel with little communication with other nodes via "gossip" protocols. It is far easier to force all nodes store the entire ledger than forcing them to form any pipeline and store partial chain data.

=== ACAN (Active Content Addressable Network) [U.S. PTO #11,588,926 B2] ===
ACAN is a high-level data '''''communication and synchronization protocol''''' that completely decouples all hardware components from communicating programs. The need for complete component decoupling was implemented in the original blockchain protocol via "gossip" protocol. This delivered blockchain's high availability and security. The simple "gossip" implementation in existing protocols is insufficient for parallel processing signaling.

The following figure illustrates the concept of ACAN (active content addressable networking) using UVR (unidirectional virtual ring) architecture. The illustrated implementation uses the Tuple Space resource tagging method and gossip protocol for UVR implementation.
[[File:SMC Architecture with ACAN.png|center|thumb|243x243px|SMC Architecture with ACAN]]

ACAN supports three simple APIs:

# '''read'''(&''key'', &''value''): ''key'' holds a search pattern in a "tuple space" where all nodes are connected. ''value'' holds the matched tuple, if any. This is a blocking call that a requesting program will be blocked until a pattern-matched tuple is found. The matching tuple remains in the "tuple space".
# '''get'''(&key, &value): Same as the "read()" API, except that the matching tuple is removed from the "tuple space".
# '''put'''(key, value): Inserts <key, value> into the "tuple space".

The use of "gossip" protocol can accelerate ACAN network saturation time. Applications running on ACAN will automatically form parallel processing topologies: pipeline, SIMD and MIMD without violating the serialization needs of transaction block validation. Replication factor can also be dynamically controlled to spread replicated blocks in randomly chosen hosts.

The highly parallel nature of the blockchain protocol will automatically implement the SMC principle in real time.

The critical feature of this dynamic SMC pipelined architecture is the inductive scaling feature.
[[File:Pipeline Parallel Processing.png|center|thumb|247x247px|Pipeline Parallel Processing]]

The speed up of a pipeline can be represented as: <math>SpeedUp = \left ( \frac{p\centerdot b}{p + (b-1)} \right )</math>, where p = number of processors in the pipeline, b = total blocks to be processed. Take the number of blocks to infinity:

<div style="text-align: center;">
<math>SpeedUp = \left ( \frac{p\centerdot b}{p + (b-1)} \right )=>\lim (b\Rightarrow\infty)(\frac{p}{\frac{p}{b}+1-\frac{1}{b}}) = p</math>
</div>

This means that as long as there are enough blocks to be processed, the entire chain's performance will be abound-bounded to the number of nodes in the pipeline.

For illustration purposes, the variation of block processing times was not considered in the above calculations. To see the power of pipeline parallelism, the automobile manufacturing processes illustrate a similar situation. The Hyundai Motor Company's production pipelines can produce 3,835 vehicles per day and 1.4M per year<ref>https://en.wikipedia.org/wiki/List_of_Hyundai_Motor_Company_manufacturing_facilities</ref>.

== Toichain Tokens ==
Toichain token is TOIN. There are 50,000,000,000 TOINs for the Alpha Release. There are air-drop tokens for early adopters, 1,000 TOIN each. Users need to register to download a toichain wallet to receive the payment. Citizenship is checked and verified to ensure that US citizens do not apply. The minimal staking contract is 10 TOINs.

== Non-Fungible Tokens ==
The TestNet Release of toichain protocol will support embedding arbitrary data in an "OP_RETURN" transaction that will be permanently recorded on the chain. Unlike the ordinal NFT <ref>https://blog.chain.link/ordinals-bitcoin-nfts/</ref> or NFT (non-fungible token) on other chains, these transactions cannot be altered or removed.

There are practical applications for these forever NFTs. Once Taproot is enabled on toichain, ordinal NFTs (BRC-20) will also be supported. Unlike the original Bitcoin network where BRC-20 craze has created massive network congestion<ref>https://beincrypto.com/learn/brc-20-token/</ref>, all transactions will be processed promptly in toichain without congestion or scaling problems.
== Toichain TestNet Launch ==
The toichain testnet launch will enable users to interact with one another through simple payments, just like the original Bitcoin network. Forever NFTs are supported. Smart contracts will be supported on a later date.

= References =
<references />

Consult the [[mediawikiwiki:Special:MyLanguage/Help:Contents|User's Guide]] for information on using the wiki software.

Main Page

2024-10-13T14:09:55Z

Justin: /* A Scalability Solution */

= <strong><big>'''Welcome to Toi-Twiki -- A Toichain Wiki'''</big></strong> =
This is the unofficial Toichain wiki site. Content is subject to changes.
---------------------------

= '''Introduction''' =
The blockchain protocol was introduced in a seminal paper entitled "Bitcoin: A peer-to-peer Electronic Cash System" <ref>https://bitcoin.org/bitcoin.pdf</ref> by Satoshi Nakamoto in 2008. Although there were previous peer-to-peer file-sharing projects such as Napster <ref>https://www.napster.com/us</ref>, BitTorrent <ref>https://www.bittorrent.com/</ref> and other electronic currency/file sharing applications, Bitcoin is the most enduring among the 23,000+ blockchains. Unlike other cryptocurrencies, the Bitcoin is often referred to as "digital gold" since the total coin supply is limited to 21 million (hard-coded in all running programs) and the only way to earn coin is to participate in the transaction block validation process. Token(or coin) supply and their disbursement policies differ among protocols.

The most attractive common blockchain features are 1) a decentralized consensus-driven decision making process and 2) a step-by-step cryptographic proving system. While blockchain is best known as a cryptocurrency transaction processing and record-keeping system, there are many other applications that can benefit from the secure storage, reliable transaction ledgers, fault tolerance and tamper resistance features.

== Algorithm vs. Protocol ==
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 ==
A good consensus protocol in a blockchain system has at least four properties:

# Fault tolerance to defend failures caused by natural disasters and human hacks or accidents
# Byzantine failure tolerance to defend exploitation by colluding parties
# Centralization avoidance to prevent corruptions in the decision making process
# Source code tamper resistance to automatically reject malicious attacks

Without assuming all nodes are active at all times, the blockchain relies on "gossip" protocol to communicate with other nodes. There are two popular types of consensus protocols: Proof of Work ('''PoW''') <ref>https://en.wikipedia.org/wiki/Proof_of_work</ref> or Proof of Stake ('''PoS''') <ref>https://www.investopedia.com/terms/p/proof-stake-pos.asp</ref>. Others include Proof of Possession('''PoP''')<ref>https://identityserver4.readthedocs.io/en/latest/topics/pop.html</ref> and Proof of History('''PoH''')<ref>https://www.infoworld.com/article/3666736/solana-blockchain-and-the-proof-of-history.html</ref>. The ultimate goal is to eliminate double-spending. Since most projects are open source, it's easy for a malicious actor to tamper a few nodes. This shouldn't compromise network integrity.

The Bitcoin network uses PoW which forces participating miners to compete for the fastest hashing rate by solving a computational cryptographic puzzle. Although it withstood more than 14 years of use, Bitcoin has been criticized for escalating electricity consumption <ref>https://www.forbes.com/advisor/investing/cryptocurrency/bitcoins-energy-usage-explained/</ref>. Other blockchain designs have experienced different challenges. For example, the PoH network Solana suffered multiple single-point-failure incidents <ref>https://messari.io/report/solana-analyzing-downtimes-statistics-and-ecosystem-development</ref>. All protocols struggle to combat scaling challenges. All are susceptible to 51% attacks <ref>https://originstamp.com/blog/has-there-ever-been-a-51-attack-on-bitcoin/#notable-51-attacks</ref>.

Since 2009, Bitcoin has proven to be the strongest and least susceptible to common hacks <ref>https://www.theguardian.com/technology/2014/mar/18/history-of-bitcoin-hacks-alternative-currency</ref>. As the PoW puzzle difficulty has increased dramatically over the years, the probability of a 51% attack on the Bitcoin network becomes more difficult. PoS protocols can save more than 90% energy consumption compared to PoW chains. But PoS chains have higher risks than PoW chains since a stolen coin will grow in PoS chains (for increased probability to be selected) forever but not in PoW chains (only hash rates count). PoS community governance rules can mitigate the voting power centralization problem. Staking and slashing policies can incentivize good behaviors and punish bad ones. In either case, double-spend is very expensive and difficult. According to Forbes, there are 80 cryptocurrencies that use PoS protocols at the time of this writing.

There are approximately 1,000 blockchains in four types: public, private, consortium, and permissioned <ref>https://increditools.com/blockchains/</ref>.

== Cryptographic Proofs ==
Bitcoin 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.

== Centralized vs. Decentralized Applications ==
The Bitcoin protocol enabled decentralized processing of traditionally centrally processed transactions without any trusted third-party. It inspired many decentralized financial applications, especially for applications with very long payment chains. However for fraud prevention and meeting financial regulatory requirements, many practical applications still require KYC (know your customer) checks. It is not possible to eliminate all trusted third parties, especially for custodial financial applications. There is a clear need for decentralized processing of trusted authority applications.

== Blockchain Trilemma ==
Blockchain protocols have three common aspects (goals): '''security''', '''decentralization''' and '''scalability''' -- these three terms do not have precise definitions but are intuitively understood <ref>https://sensoriumxr.com/articles/what-is-the-blockchain-trilemma</ref>. To date, 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.

A major shortcoming is scalability. Since all nodes verify each transaction independently, they need to store all the information required for it. As the chain grows, this burdens all nodes in the network. There are workarounds by limiting the amount of data stored on some nodes and exploiting the network to retrieve required information, such as the ''Limited/Light Nodes'' in Bitcoin network. Vast majority nodes are still full nodes in the existing Bitcoin network. Transaction processing speed often expressed ''as transactions per second(TPS) of'' blockchain have to exceed TPS ratings of credit card payment systems like VISA or MasterCard to reap the full benefits of blockchain. This is a tough problem and increasing the block size and/or reducing the block time or difficulty isn't a solution<ref>https://medium.com/coinmonks/blockchain-scaling-30c9e1b7db1b</ref>. Since blockchain TPS is very low, the transaction fees is often very high. This discourages public adoption. Layer 2 solution like ''Lightning Network'' or ''ZK-rollups,'' where only final settlement is on the main chain tend to address these issues. However, one could always argue that this often compromises some aspects of security and/or decentralization to achieve high TPS.

The trilemma was first introduced by Vitalik Buterin<ref>https://en.wikipedia.org/wiki/Vitalik_Buterin</ref>, one of the co-founders of Ethereum network. The problems he identified are real. There seem to be no obvious solutions that can accomplish all three goals at the same time. Therefore, all proposed solutions revolve around reducing "opportunity costs" focusing only on satisfying partial goals.

Treating the blockchain network as an infrastructure for transaction processing, the blockchain protocol solved service reliability problem but not performance challenge. The legacy infrastructure scaling dilemma: performance against reliability remains (where "infrastructure reliability" also does not have a commonly accepted definition). Fortunately these metrics, although important, are non-critical. Solutions that have been proposed have had varying opportunity costs. For many years, there were no obvious solutions that addressed all three blockchain goals (security, decentralization and scalability).
== Statistic Multiplexed Computing (SMC) ==
The principle of using unreliable components to build an arbitrarily reliable system was first lectured by von Neumann in the early 1950s<ref>https://static.ias.edu/pitp/archive/2012files/Probabilistic_Logics.pdf</ref>. The original idea was to use probabilistic logic to quantify the arbitrary reliability of a system by multiplexing all components. This theory was applied to the construction of Internet protocols to deliver the "best effort" reliability. Incidentally, best effort reliability also enabled "best effort" performance which in turn enabled unlimited scalability of the Internet. For emerging web3.0 technologies, it is important to apply the same methodology to both centralized and decentralized computing for seamless technology migration and integration. For historical arguments, click [[SMC|'''''here''''']].

== Definitions ==
'''Infrastructure scalability''' does not have a commonly accepted definition. It helps to define the challenging metrics more precisely before the infrastructure protocol design. In the following, for definitions #1 and #2, the word "'''infrastructure'''" means any '''application running on the infrastructure.'''

# '''Infrastructure Reliability''': MTBF (mean time between failure) = <math>\frac{\sum ((Start-Of-Downtime) - (Start-of-uptime)) }{No-of-failures}</math>
# '''Infrastructure Performance''': <math>\frac{No-of-Transactions}{Second}</math>
# '''Infrastructure Scalability''': Expanding the infrastructure in number of processors, networks or storage should have '''incrementally better''' impacts on application reliability and performance.
# '''Record Immutability''': For transaction ledgers, all confirmed records and changes are final. This is required by the blockchain protocol.
Note that in practice, record immutability is much harder to achieve than expected. There are two challenges, a) 51% attacks can literally wipe out all histories if successful, and b) for protocols require all nodes to hold independently verified ledger, such as the Bitcoin, the storage requirement grows approximately 50GB per month.

== 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 and considered.

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 crashe'''s <ref>https://groups.csail.mit.edu/tds/papers/Lynch/jacm93.pdf</ref>. The laws of physics regarding component reliability <ref>Encyclopedia of Physical Science and Technology, Editor-in-Chief Robert A. Meyers, [[index.php?title=Special:BookSources/9780122274107|ISBN 978-0-12-227410-7]], 2001</ref> show that '''100% component reliability is not possible.''' These facts require that the infrastructure protocol (program-program communication protocol) provide '''complete component (processing, networking and storage) decoupling''' from application program logics. This decoupling requirement forces the protocol to exploit "decentralized" or "stateless" components that the legacy infrastructure protocols, such as message passing interface (MPI), remote procedure call (RPC) and remote method invocation (RMI), cannot handle. The blockchain protocol is an example of a "best effort" availability protocol.

Quantifying infrastructure reliability can be traced back to the computer pioneer von Neumann. In addition to his contribution to computer architecture, von Neumann also penned a study on building reliable systems using unreliable components using probabilistic logics, in early fifties <ref>https://static.ias.edu/pitp/archive/2012files/Probabilistic_Logics.pdf</ref>. The 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 "best effort" reliability. Ironically, this best effort reliability also enabled the Internet's infinite scalability -- the benefit we enjoy now and into the future.

The Bitcoin protocol exploits multiple anonymous decoupled (or decentralized) computers connected through the Internet protocol. Judging from the Bitcoin network's reliability to date <ref>https://buybitcoinworldwide.com/bitcoin-downtime/</ref>, von Neumann's theory seems working well.

The '''second challenge''' involves infrastructure performance. Since the infrastructure must deploy multiple computing, networking and storage components, unless all components can be fully exploited at 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 lack this capability.

'''The infrastructure scalability challenge''' is automatically resolved once the performance challenge is resolved without negatively impacting reliability -- "best effort" performance" meets "best effort reliability". This requires inductive performance and reliability measures or deliveries.

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, an inductive statistic multiplexed blockchain protocol is needed to meet the scalability challenge. Non-inductive solutions such as fixed chain "sharding" or "Danksharding" <ref>https://ethereum.org/en/roadmap/danksharding/</ref> will only increase protocol development complexity with persistent performance walls.

== A Scalability Solution ==
An effective scalability solution can have two practical assumptions:

* The computation problem size can expand indefinitely, since every useful infrastructure is expected to solve bigger problems.

*Computing and network resources will continue to grow indefinitely, into the future.
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 <ref>https://en.wikipedia.org/wiki/Amdahl%27s_law</ref> and Gustafson's Law <ref>https://en.wikipedia.org/wiki/Gustafson%27s_law</ref>.

The Amdahl's Law assumes 0<= ''s'' <=1 percentage of serial instructions that cannot be parallelized. Then the ''(1-s)'' percentage of instructions can be accelerated using ''p'' processors.

<div style="text-align: center;">
Speedup(p) = <math>{1 \over s + {(1-s) \over p}}</math> (1) <br>Speedup(<math>\lim_{p \to \infty}</math>) = <math>\frac{1}{s}</math> (2)
</div>
Taking ''p'' to infinity in equation (1) yields equation (2). But this derivation step has two different operational semantics: a) increasing ''p'' to further reduce the value of (''1-s)/p'' solving the same problem. This will result ''s'' asymptotically approaching 1. Thus the speedup is above founded to 1. Or b) increasing ''p'' to increase the parallel percentage ''(1-s)'' by solving bigger problems. This will force ''s'' asymptotically approach 0. Then the speedup is above bounded by <math>\infty</math>. This scaling ambiguity caused more than three decades of confusion in the community.

Although quantifying ''s'' requires additional information, such as the problem size, the model is applicable to programs solving any problem size with any percentage ''s''. The limit of speedup (2) also does not depend on problem size. However, since Amdahl originally used programs solving fixed problem sizes to argue the validity of not building parallel machines with too many processors, assuming fixed problem size using ''p'' processors has been the norm in interpreting Amdahl's law in the past. This assumption has led to the dismal speedup predictions.[[File:Amdahl's Law.png|thumb|Amdahl's Law Speedup Predictions|center]]The traditional Amdahl's Law interpretation seems to suggest parallel performances following the economic law of diminishing of returns, even though the mathematic model implies more potentials.

In 1988, Gustafson and Barsis at the Sandia National Laboratory conducted parallel computing experiments that seem to suggest potential infinite speedup.

Gustafson's Law was based on measured sequential and parallel elapsed times using ''p'' (=1024) processors. A new sequential percentage ''0<=x'<=1'' can be calculated using ''p'' processors. ''(1-x')'' is the parallel percentage using ''p'' processors.

To estimate accomplished speedup, Gustafson's Law states:

<div style="text-align: center;">
<math>Speedup=\frac{Tseq}{Tpar}=\frac{s'+(1-s')p}{1}=s'+(1-s')p </math> (3)
</div>

Take ''p'' -> <math>\infty</math> for equation (3) also has two operational semantics: a) Keep the problem size fixed, adding processors to further reduce the total parallel processing time, thus bigger s'. This will yield s' approaching 1. Thus speedup is also bounded to 1. Or b) expanding the problem size to allow the parallel part expanded solving bigger problems. This will yield s' asymptotically approaching 0. Speedup will be above bounded to ''p''. Gustafson's Law was used to argue for Massively Parallel Computing (MPC) (or ManyCPU) experiments and Amdahl's Law was used to argue for bigger mainframe (or BigCPU) computer architectures. In the past decades, these laws have been used to support two diverging computing system experiments and constructions until recent convergence.
[[File:Gustafson.png|thumb|Gustafson's Law|center]]
It is now obvious that the two law are identical with Amdahl's Law more succinct. But Gustafson's formula helps to quantify the serial percentages from practical program executions. In fact, the two serial percentages can be related by a simple equation<ref>https://www.researchgate.net/publication/228367369_Reevaluating_Amdahl's_law_and_Gustafson's_law</ref>:

<div style="text-align: center;">
<math>s=\frac{s'}{s'+(1-s')p}</math> (4)
</div>

Both law actually refer to the same mathematical abstraction. Gustafson's formula assisted in quantifying the percentage of serial computing through program experiments. Neither should be directly used for speedup prediction alone.

This model can be validated in practice when developers simply increasing the problem size to use more parallel processors.

[[File:Full Range Amdah's Law .png|alt=Full Power of Amdahl's Law|center|thumb|Full Power of Amdahl's Law]]

If we plot the full speedup curves against the number of processors, we will see the missing lines.

[[File:DiminishingReturn2.png|alt=infinite Speedup Under Amdahl's Law|center|thumb[Infinite Speedup in Amdahl's Law|400x400px]]

A classical example is the TOP500 supercomputer benchmarks (linear solvers) that have open problem sizes for all manufacturers to compete in the world's fastest supercomputer race <ref>https://www.top500.org/</ref> .
[[File:Supercomputers-history.png|center|thumb]]
In practical blockchain applications, the number of transactions to be processed will increase without a known limit. The ledger storage will continue to grow. In practice, the available computing, networking and storage components will continue to grow without limits enabled by the networking protocols. Therefore a statistic multiplexed computing blockchain can meet any future application needs given proper economic incentives. The infrastructure no longer has the structural deficiency.

== Action Plan ==

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.

For Toichain protocol design, we choose Bitcoin 24.0.1 as the base line protocol by replacing the PoW consensus by PoS consensus and injecting SMC components into the protocol processing signaling for parallel computing.

This surprising result is also applicable to ledger storage. Without multiplexing, the blockchain ledger storage will eventually saturate all nodes causing the chain to collapse. The SMC blockchain protocol promises to hold the true finality of all transactions in perpetuity by multiplexing all storage resources while keeping the replication factor to a constant.

These discussions follow the inductive logic of the Law of Large Numbers <ref>https://www.sciencedirect.com/topics/mathematics/laws-of-large-number</ref>.

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

= SMC Proof of Stake Protocol =
Existing PoS protocol designs revolved around staking policies and randomness of the selection algorithm. Considering infrastructure scalability will add much complexity to the design. The examples include chain sharding and Danksharding <ref>https://ethereum.org/en/roadmap/danksharding/</ref>.

The challenge is complex -- we must deliver very high performance without compromising security and reliability of the network.

Technically, transaction replication and parallel processing were considered dangerous <ref>https://pages.cs.wisc.edu/~yxy/cs764-f20/papers/replication.pdf</ref> due to the potential race conditions (or double-spend problem). The blockchain protocol resolved the double-spending problem. It did not solve the parallel processing performance problem.

According to Professor Michael Flynn, there are three high-level parallel processing topologies: SIMD (single instruction multiple data), MIMD (multiple instructions multiple data), and pipeline (MISD - multiple instructions single data stream) <ref>https://link.springer.com/referenceworkentry/10.1007/978-0-387-09766-4_2</ref>. However, for eliminating double-spending, all transactions must be serialized, since each block may contain transactions affecting transactions in multiple other blocks. "Race conditions" and non-deterministic results are not allowed. Then the only possible topology entry is pipeline. This means for POS protocol, we must build a pipeline of transaction blocks to be validated without compromising network security and reliability.
[[File:Flynns-Taxonomy-of-Computer-Architectures.png|center|thumb|Parallel Processing Topologies]]
The problem is that the nature of the blockchain protocol is that all nodes run independently in parallel with little communication with other nodes via "gossip" protocols. It is far easier to force all nodes store the entire ledger than forcing them to form any pipeline and store partial chain data.

=== ACAN (Active Content Addressable Network) [U.S. PTO #11,588,926 B2] ===
ACAN is a high-level data '''''communication and synchronization protocol''''' that completely decouples all hardware components from communicating programs. The need for complete component decoupling was implemented in the original blockchain protocol via "gossip" protocol. This delivered blockchain's high availability and security. The simple "gossip" implementation in existing protocols is insufficient for parallel processing signaling.

The following figure illustrates the concept of ACAN (active content addressable networking) using UVR (unidirectional virtual ring) architecture. The illustrated implementation uses the Tuple Space resource tagging method and gossip protocol for UVR implementation.
[[File:SMC Architecture with ACAN.png|center|thumb|243x243px|SMC Architecture with ACAN]]

ACAN supports three simple APIs:

# '''read'''(&''key'', &''value''): ''key'' holds a search pattern in a "tuple space" where all nodes are connected. ''value'' holds the matched tuple, if any. This is a blocking call that a requesting program will be blocked until a pattern-matched tuple is found. The matching tuple remains in the "tuple space".
# '''get'''(&key, &value): Same as the "read()" API, except that the matching tuple is removed from the "tuple space".
# '''put'''(key, value): Inserts <key, value> into the "tuple space".

The use of "gossip" protocol can accelerate ACAN network saturation time. Applications running on ACAN will automatically form parallel processing topologies: pipeline, SIMD and MIMD without violating the serialization needs of transaction block validation. Replication factor can also be dynamically controlled to spread replicated blocks in randomly chosen hosts.

The highly parallel nature of the blockchain protocol will automatically implement the SMC principle in real time.

The critical feature of this dynamic SMC pipelined architecture is the inductive scaling feature.
[[File:Pipeline Parallel Processing.png|center|thumb|247x247px|Pipeline Parallel Processing]]

The speed up of a pipeline can be represented as: <math>SpeedUp = \left ( \frac{p\centerdot b}{p + (b-1)} \right )</math>, where p = number of processors in the pipeline, b = total blocks to be processed. Take the number of blocks to infinity:

<div style="text-align: center;">
<math>SpeedUp = \left ( \frac{p\centerdot b}{p + (b-1)} \right )=>\lim (b\Rightarrow\infty)(\frac{p}{\frac{p}{b}+1-\frac{1}{b}}) = p</math>
</div>

This means that as long as there are enough blocks to be processed, the entire chain's performance will be abound-bounded to the number of nodes in the pipeline.

For illustration purposes, the variation of block processing times was not considered in the above calculations. To see the power of pipeline parallelism, the automobile manufacturing processes illustrate a similar situation. The Hyundai Motor Company's production pipelines can produce 3,835 vehicles per day and 1.4M per year<ref>https://en.wikipedia.org/wiki/List_of_Hyundai_Motor_Company_manufacturing_facilities</ref>.

== Toichain Tokens ==
Toichain token is TOIN. There are 50,000,000,000 TOINs for the Alpha Release. There are air-drop tokens for early adopters, 1,000 TOIN each. Users need to register to download a toichain wallet to receive the payment. Citizenship is checked and verified to ensure that US citizens do not apply. The minimal staking contract is 10 TOINs.

== Non-Fungible Tokens ==
The TestNet Release of toichain protocol will support embedding arbitrary data in an "OP_RETURN" transaction that will be permanently recorded on the chain. Unlike the ordinal NFT <ref>https://blog.chain.link/ordinals-bitcoin-nfts/</ref> or NFT (non-fungible token) on other chains, these transactions cannot be altered or removed.

There are practical applications for these forever NFTs. Once Taproot is enabled on toichain, ordinal NFTs (BRC-20) will also be supported. Unlike the original Bitcoin network where BRC-20 craze has created massive network congestion<ref>https://beincrypto.com/learn/brc-20-token/</ref>, all transactions will be processed promptly in toichain without congestion or scaling problems.
== Toichain TestNet Launch ==
The toichain testnet launch will enable users to interact with one another through simple payments, just like the original Bitcoin network. Forever NFTs are supported. Smart contracts will be supported on a later date.

= References =
<references />

Consult the [[mediawikiwiki:Special:MyLanguage/Help:Contents|User's Guide]] for information on using the wiki software.

Main Page

2024-10-13T14:04:22Z

Justin: /* A Scalability Solution */

= <strong><big>'''Welcome to Toi-Twiki -- A Toichain Wiki'''</big></strong> =
This is the unofficial Toichain wiki site. Content is subject to changes.
---------------------------

= '''Introduction''' =
The blockchain protocol was introduced in a seminal paper entitled "Bitcoin: A peer-to-peer Electronic Cash System" <ref>https://bitcoin.org/bitcoin.pdf</ref> by Satoshi Nakamoto in 2008. Although there were previous peer-to-peer file-sharing projects such as Napster <ref>https://www.napster.com/us</ref>, BitTorrent <ref>https://www.bittorrent.com/</ref> and other electronic currency/file sharing applications, Bitcoin is the most enduring among the 23,000+ blockchains. Unlike other cryptocurrencies, the Bitcoin is often referred to as "digital gold" since the total coin supply is limited to 21 million (hard-coded in all running programs) and the only way to earn coin is to participate in the transaction block validation process. Token(or coin) supply and their disbursement policies differ among protocols.

The most attractive common blockchain features are 1) a decentralized consensus-driven decision making process and 2) a step-by-step cryptographic proving system. While blockchain is best known as a cryptocurrency transaction processing and record-keeping system, there are many other applications that can benefit from the secure storage, reliable transaction ledgers, fault tolerance and tamper resistance features.

== Algorithm vs. Protocol ==
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 ==
A good consensus protocol in a blockchain system has at least four properties:

# Fault tolerance to defend failures caused by natural disasters and human hacks or accidents
# Byzantine failure tolerance to defend exploitation by colluding parties
# Centralization avoidance to prevent corruptions in the decision making process
# Source code tamper resistance to automatically reject malicious attacks

Without assuming all nodes are active at all times, the blockchain relies on "gossip" protocol to communicate with other nodes. There are two popular types of consensus protocols: Proof of Work ('''PoW''') <ref>https://en.wikipedia.org/wiki/Proof_of_work</ref> or Proof of Stake ('''PoS''') <ref>https://www.investopedia.com/terms/p/proof-stake-pos.asp</ref>. Others include Proof of Possession('''PoP''')<ref>https://identityserver4.readthedocs.io/en/latest/topics/pop.html</ref> and Proof of History('''PoH''')<ref>https://www.infoworld.com/article/3666736/solana-blockchain-and-the-proof-of-history.html</ref>. The ultimate goal is to eliminate double-spending. Since most projects are open source, it's easy for a malicious actor to tamper a few nodes. This shouldn't compromise network integrity.

The Bitcoin network uses PoW which forces participating miners to compete for the fastest hashing rate by solving a computational cryptographic puzzle. Although it withstood more than 14 years of use, Bitcoin has been criticized for escalating electricity consumption <ref>https://www.forbes.com/advisor/investing/cryptocurrency/bitcoins-energy-usage-explained/</ref>. Other blockchain designs have experienced different challenges. For example, the PoH network Solana suffered multiple single-point-failure incidents <ref>https://messari.io/report/solana-analyzing-downtimes-statistics-and-ecosystem-development</ref>. All protocols struggle to combat scaling challenges. All are susceptible to 51% attacks <ref>https://originstamp.com/blog/has-there-ever-been-a-51-attack-on-bitcoin/#notable-51-attacks</ref>.

Since 2009, Bitcoin has proven to be the strongest and least susceptible to common hacks <ref>https://www.theguardian.com/technology/2014/mar/18/history-of-bitcoin-hacks-alternative-currency</ref>. As the PoW puzzle difficulty has increased dramatically over the years, the probability of a 51% attack on the Bitcoin network becomes more difficult. PoS protocols can save more than 90% energy consumption compared to PoW chains. But PoS chains have higher risks than PoW chains since a stolen coin will grow in PoS chains (for increased probability to be selected) forever but not in PoW chains (only hash rates count). PoS community governance rules can mitigate the voting power centralization problem. Staking and slashing policies can incentivize good behaviors and punish bad ones. In either case, double-spend is very expensive and difficult. According to Forbes, there are 80 cryptocurrencies that use PoS protocols at the time of this writing.

There are approximately 1,000 blockchains in four types: public, private, consortium, and permissioned <ref>https://increditools.com/blockchains/</ref>.

== Cryptographic Proofs ==
Bitcoin 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.

== Centralized vs. Decentralized Applications ==
The Bitcoin protocol enabled decentralized processing of traditionally centrally processed transactions without any trusted third-party. It inspired many decentralized financial applications, especially for applications with very long payment chains. However for fraud prevention and meeting financial regulatory requirements, many practical applications still require KYC (know your customer) checks. It is not possible to eliminate all trusted third parties, especially for custodial financial applications. There is a clear need for decentralized processing of trusted authority applications.

== Blockchain Trilemma ==
Blockchain protocols have three common aspects (goals): '''security''', '''decentralization''' and '''scalability''' -- these three terms do not have precise definitions but are intuitively understood <ref>https://sensoriumxr.com/articles/what-is-the-blockchain-trilemma</ref>. To date, 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.

A major shortcoming is scalability. Since all nodes verify each transaction independently, they need to store all the information required for it. As the chain grows, this burdens all nodes in the network. There are workarounds by limiting the amount of data stored on some nodes and exploiting the network to retrieve required information, such as the ''Limited/Light Nodes'' in Bitcoin network. Vast majority nodes are still full nodes in the existing Bitcoin network. Transaction processing speed often expressed ''as transactions per second(TPS) of'' blockchain have to exceed TPS ratings of credit card payment systems like VISA or MasterCard to reap the full benefits of blockchain. This is a tough problem and increasing the block size and/or reducing the block time or difficulty isn't a solution<ref>https://medium.com/coinmonks/blockchain-scaling-30c9e1b7db1b</ref>. Since blockchain TPS is very low, the transaction fees is often very high. This discourages public adoption. Layer 2 solution like ''Lightning Network'' or ''ZK-rollups,'' where only final settlement is on the main chain tend to address these issues. However, one could always argue that this often compromises some aspects of security and/or decentralization to achieve high TPS.

The trilemma was first introduced by Vitalik Buterin<ref>https://en.wikipedia.org/wiki/Vitalik_Buterin</ref>, one of the co-founders of Ethereum network. The problems he identified are real. There seem to be no obvious solutions that can accomplish all three goals at the same time. Therefore, all proposed solutions revolve around reducing "opportunity costs" focusing only on satisfying partial goals.

Treating the blockchain network as an infrastructure for transaction processing, the blockchain protocol solved service reliability problem but not performance challenge. The legacy infrastructure scaling dilemma: performance against reliability remains (where "infrastructure reliability" also does not have a commonly accepted definition). Fortunately these metrics, although important, are non-critical. Solutions that have been proposed have had varying opportunity costs. For many years, there were no obvious solutions that addressed all three blockchain goals (security, decentralization and scalability).
== Statistic Multiplexed Computing (SMC) ==
The principle of using unreliable components to build an arbitrarily reliable system was first lectured by von Neumann in the early 1950s<ref>https://static.ias.edu/pitp/archive/2012files/Probabilistic_Logics.pdf</ref>. The original idea was to use probabilistic logic to quantify the arbitrary reliability of a system by multiplexing all components. This theory was applied to the construction of Internet protocols to deliver the "best effort" reliability. Incidentally, best effort reliability also enabled "best effort" performance which in turn enabled unlimited scalability of the Internet. For emerging web3.0 technologies, it is important to apply the same methodology to both centralized and decentralized computing for seamless technology migration and integration. For historical arguments, click [[SMC|'''''here''''']].

== Definitions ==
'''Infrastructure scalability''' does not have a commonly accepted definition. It helps to define the challenging metrics more precisely before the infrastructure protocol design. In the following, for definitions #1 and #2, the word "'''infrastructure'''" means any '''application running on the infrastructure.'''

# '''Infrastructure Reliability''': MTBF (mean time between failure) = <math>\frac{\sum ((Start-Of-Downtime) - (Start-of-uptime)) }{No-of-failures}</math>
# '''Infrastructure Performance''': <math>\frac{No-of-Transactions}{Second}</math>
# '''Infrastructure Scalability''': Expanding the infrastructure in number of processors, networks or storage should have '''incrementally better''' impacts on application reliability and performance.
# '''Record Immutability''': For transaction ledgers, all confirmed records and changes are final. This is required by the blockchain protocol.
Note that in practice, record immutability is much harder to achieve than expected. There are two challenges, a) 51% attacks can literally wipe out all histories if successful, and b) for protocols require all nodes to hold independently verified ledger, such as the Bitcoin, the storage requirement grows approximately 50GB per month.

== 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 and considered.

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 crashe'''s <ref>https://groups.csail.mit.edu/tds/papers/Lynch/jacm93.pdf</ref>. The laws of physics regarding component reliability <ref>Encyclopedia of Physical Science and Technology, Editor-in-Chief Robert A. Meyers, [[index.php?title=Special:BookSources/9780122274107|ISBN 978-0-12-227410-7]], 2001</ref> show that '''100% component reliability is not possible.''' These facts require that the infrastructure protocol (program-program communication protocol) provide '''complete component (processing, networking and storage) decoupling''' from application program logics. This decoupling requirement forces the protocol to exploit "decentralized" or "stateless" components that the legacy infrastructure protocols, such as message passing interface (MPI), remote procedure call (RPC) and remote method invocation (RMI), cannot handle. The blockchain protocol is an example of a "best effort" availability protocol.

Quantifying infrastructure reliability can be traced back to the computer pioneer von Neumann. In addition to his contribution to computer architecture, von Neumann also penned a study on building reliable systems using unreliable components using probabilistic logics, in early fifties <ref>https://static.ias.edu/pitp/archive/2012files/Probabilistic_Logics.pdf</ref>. The 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 "best effort" reliability. Ironically, this best effort reliability also enabled the Internet's infinite scalability -- the benefit we enjoy now and into the future.

The Bitcoin protocol exploits multiple anonymous decoupled (or decentralized) computers connected through the Internet protocol. Judging from the Bitcoin network's reliability to date <ref>https://buybitcoinworldwide.com/bitcoin-downtime/</ref>, von Neumann's theory seems working well.

The '''second challenge''' involves infrastructure performance. Since the infrastructure must deploy multiple computing, networking and storage components, unless all components can be fully exploited at 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 lack this capability.

'''The infrastructure scalability challenge''' is automatically resolved once the performance challenge is resolved without negatively impacting reliability -- "best effort" performance" meets "best effort reliability". This requires inductive performance and reliability measures or deliveries.

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, an inductive statistic multiplexed blockchain protocol is needed to meet the scalability challenge. Non-inductive solutions such as fixed chain "sharding" or "Danksharding" <ref>https://ethereum.org/en/roadmap/danksharding/</ref> will only increase protocol development complexity with persistent performance walls.

== A Scalability Solution ==
An effective scalability solution can have two practical assumptions:

* The computation problem size can expand indefinitely, since every useful infrastructure is expected to solve bigger problems.

*Computing and network resources will continue to grow indefinitely, into the future.
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 <ref>https://en.wikipedia.org/wiki/Amdahl%27s_law</ref> and Gustafson's Law <ref>https://en.wikipedia.org/wiki/Gustafson%27s_law</ref>.

The Amdahl's Law assumes 0<= ''s'' <=1 percentage of serial instructions that cannot be parallelized. Then the ''(1-s)'' percentage of instructions can be accelerated using ''p'' processors.

<div style="text-align: center;">
Speedup(p) = <math>{1 \over s + {(1-s) \over p}}</math> (1) <br>Speedup(<math>\lim_{p \to \infty}</math>) = <math>\frac{1}{s}</math> (2)
</div>
Taking ''p'' to infinity in equation (1) yields equation (2). But this derivation step has two different operational semantics: a) increasing ''p'' to further reduce the value of (''1-s)/p'' solving the same problem. This will result ''s'' asymptotically approaching 1. Thus the speedup is above founded to 1. Or b) increasing ''p'' to increase the parallel percentage ''(1-s)'' by solving bigger problems. This will force ''s'' asymptotically approach 0. Then the speedup is above bounded by <math>\infty</math>. This scaling ambiguity caused more than three decades of confusion in the community.

Although quantifying ''s'' requires additional information, such as the problem size, the model is applicable to programs solving any problem size with any percentage ''s''. The limit of speedup (2) also does not depend on problem size. However, since Amdahl originally used programs solving fixed problem sizes to argue the validity of not building parallel machines with too many processors, assuming fixed problem size using ''p'' processors has been the norm in interpreting Amdahl's law in the past. This assumption has led to the dismal speedup predictions.[[File:Amdahl's Law.png|thumb|Amdahl's Law Speedup Predictions|center]]The traditional Amdahl's Law interpretation seems to suggest parallel performances following the economic law of diminishing of returns, even though the mathematic model implies more potentials.

In 1988, Gustafson and Barsis at the Sandia National Laboratory conducted parallel computing experiments that seem to suggest potential infinite speedup.

Gustafson's Law was based on measured sequential and parallel elapsed times using ''p'' (=1024) processors. A new sequential percentage ''0<=x'<=1'' can be calculated using ''p'' processors. ''(1-x')'' is the parallel percentage using ''p'' processors.

To estimate accomplished speedup, Gustafson's Law states:

<div style="text-align: center;">
<math>Speedup=\frac{Tseq}{Tpar}=\frac{s'+(1-s')p}{1}=s'+(1-s')p </math> (3)
</div>

Take ''p'' -> <math>\infty</math> for equation (3) also has two operational semantics: a) Keep the problem size fixed, adding processors to further reduce the total parallel processing time, thus bigger s'. This will yield s' approaching 1. Thus speedup is also bounded to 1. Or b) expanding the problem size to allow the parallel part expanded solving bigger problems. This will yield s' asymptotically approaching 0. Speedup will be above bounded to ''p''. Gustafson's Law was used to argue for Massively Parallel Computing (MPC) (or ManyCPU) experiments and Amdahl's Law was used to argue for bigger mainframe (or BigCPU) computer architectures. In the past decades, these laws have been used to support two diverging computing system experiments and constructions until recent convergence.
[[File:Gustafson.png|thumb|Gustafson's Law|center]]
It is now obvious that the two law are identical with Amdahl's Law more succinct. But Gustafson's formula helps to quantify the serial percentages from practical program executions. In fact, the two serial percentages can be related by a simple equation<ref>https://www.researchgate.net/publication/228367369_Reevaluating_Amdahl's_law_and_Gustafson's_law</ref>:

<div style="text-align: center;">
<math>s=\frac{s'}{s'+(1-s')p}</math> (4)
</div>

Both law actually refer to the same mathematical abstraction. Gustafson's formula assisted in quantifying the percentage of serial computing through program experiments. Neither should be directly used for speedup prediction alone.

This model can be validated in practice when developers simply increasing the problem size to use more parallel processors.

[[File:Full Range Amdah's Law .png|alt=Full Power of Amdahl's Law|center|thumb|Full Power of Amdahl's Law]]

If we plot the full speedup curves against the number of processors, we will see the missing lines.

[[File:DiminishingReturn2.png|alt=infinite Speedup Under Amdahl's Law|center|thumb[Infinite Speedup in Amdahl's Law]]

A classical example is the TOP500 supercomputer benchmarks (linear solvers) that have open problem sizes for all manufacturers to compete in the world's fastest supercomputer race <ref>https://www.top500.org/</ref> .
[[File:Supercomputers-history.png|center|thumb]]
In practical blockchain applications, the number of transactions to be processed will increase without a known limit. The ledger storage will continue to grow. In practice, the available computing, networking and storage components will continue to grow without limits enabled by the networking protocols. Therefore a statistic multiplexed computing blockchain can meet any future application needs given proper economic incentives. The infrastructure no longer has the structural deficiency.

== Action Plan ==

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.

For Toichain protocol design, we choose Bitcoin 24.0.1 as the base line protocol by replacing the PoW consensus by PoS consensus and injecting SMC components into the protocol processing signaling for parallel computing.

This surprising result is also applicable to ledger storage. Without multiplexing, the blockchain ledger storage will eventually saturate all nodes causing the chain to collapse. The SMC blockchain protocol promises to hold the true finality of all transactions in perpetuity by multiplexing all storage resources while keeping the replication factor to a constant.

These discussions follow the inductive logic of the Law of Large Numbers <ref>https://www.sciencedirect.com/topics/mathematics/laws-of-large-number</ref>.

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

= SMC Proof of Stake Protocol =
Existing PoS protocol designs revolved around staking policies and randomness of the selection algorithm. Considering infrastructure scalability will add much complexity to the design. The examples include chain sharding and Danksharding <ref>https://ethereum.org/en/roadmap/danksharding/</ref>.

The challenge is complex -- we must deliver very high performance without compromising security and reliability of the network.

Technically, transaction replication and parallel processing were considered dangerous <ref>https://pages.cs.wisc.edu/~yxy/cs764-f20/papers/replication.pdf</ref> due to the potential race conditions (or double-spend problem). The blockchain protocol resolved the double-spending problem. It did not solve the parallel processing performance problem.

According to Professor Michael Flynn, there are three high-level parallel processing topologies: SIMD (single instruction multiple data), MIMD (multiple instructions multiple data), and pipeline (MISD - multiple instructions single data stream) <ref>https://link.springer.com/referenceworkentry/10.1007/978-0-387-09766-4_2</ref>. However, for eliminating double-spending, all transactions must be serialized, since each block may contain transactions affecting transactions in multiple other blocks. "Race conditions" and non-deterministic results are not allowed. Then the only possible topology entry is pipeline. This means for POS protocol, we must build a pipeline of transaction blocks to be validated without compromising network security and reliability.
[[File:Flynns-Taxonomy-of-Computer-Architectures.png|center|thumb|Parallel Processing Topologies]]
The problem is that the nature of the blockchain protocol is that all nodes run independently in parallel with little communication with other nodes via "gossip" protocols. It is far easier to force all nodes store the entire ledger than forcing them to form any pipeline and store partial chain data.

=== ACAN (Active Content Addressable Network) [U.S. PTO #11,588,926 B2] ===
ACAN is a high-level data '''''communication and synchronization protocol''''' that completely decouples all hardware components from communicating programs. The need for complete component decoupling was implemented in the original blockchain protocol via "gossip" protocol. This delivered blockchain's high availability and security. The simple "gossip" implementation in existing protocols is insufficient for parallel processing signaling.

The following figure illustrates the concept of ACAN (active content addressable networking) using UVR (unidirectional virtual ring) architecture. The illustrated implementation uses the Tuple Space resource tagging method and gossip protocol for UVR implementation.
[[File:SMC Architecture with ACAN.png|center|thumb|243x243px|SMC Architecture with ACAN]]

ACAN supports three simple APIs:

# '''read'''(&''key'', &''value''): ''key'' holds a search pattern in a "tuple space" where all nodes are connected. ''value'' holds the matched tuple, if any. This is a blocking call that a requesting program will be blocked until a pattern-matched tuple is found. The matching tuple remains in the "tuple space".
# '''get'''(&key, &value): Same as the "read()" API, except that the matching tuple is removed from the "tuple space".
# '''put'''(key, value): Inserts <key, value> into the "tuple space".

The use of "gossip" protocol can accelerate ACAN network saturation time. Applications running on ACAN will automatically form parallel processing topologies: pipeline, SIMD and MIMD without violating the serialization needs of transaction block validation. Replication factor can also be dynamically controlled to spread replicated blocks in randomly chosen hosts.

The highly parallel nature of the blockchain protocol will automatically implement the SMC principle in real time.

The critical feature of this dynamic SMC pipelined architecture is the inductive scaling feature.
[[File:Pipeline Parallel Processing.png|center|thumb|247x247px|Pipeline Parallel Processing]]

The speed up of a pipeline can be represented as: <math>SpeedUp = \left ( \frac{p\centerdot b}{p + (b-1)} \right )</math>, where p = number of processors in the pipeline, b = total blocks to be processed. Take the number of blocks to infinity:

<div style="text-align: center;">
<math>SpeedUp = \left ( \frac{p\centerdot b}{p + (b-1)} \right )=>\lim (b\Rightarrow\infty)(\frac{p}{\frac{p}{b}+1-\frac{1}{b}}) = p</math>
</div>

This means that as long as there are enough blocks to be processed, the entire chain's performance will be abound-bounded to the number of nodes in the pipeline.

For illustration purposes, the variation of block processing times was not considered in the above calculations. To see the power of pipeline parallelism, the automobile manufacturing processes illustrate a similar situation. The Hyundai Motor Company's production pipelines can produce 3,835 vehicles per day and 1.4M per year<ref>https://en.wikipedia.org/wiki/List_of_Hyundai_Motor_Company_manufacturing_facilities</ref>.

== Toichain Tokens ==
Toichain token is TOIN. There are 50,000,000,000 TOINs for the Alpha Release. There are air-drop tokens for early adopters, 1,000 TOIN each. Users need to register to download a toichain wallet to receive the payment. Citizenship is checked and verified to ensure that US citizens do not apply. The minimal staking contract is 10 TOINs.

== Non-Fungible Tokens ==
The TestNet Release of toichain protocol will support embedding arbitrary data in an "OP_RETURN" transaction that will be permanently recorded on the chain. Unlike the ordinal NFT <ref>https://blog.chain.link/ordinals-bitcoin-nfts/</ref> or NFT (non-fungible token) on other chains, these transactions cannot be altered or removed.

There are practical applications for these forever NFTs. Once Taproot is enabled on toichain, ordinal NFTs (BRC-20) will also be supported. Unlike the original Bitcoin network where BRC-20 craze has created massive network congestion<ref>https://beincrypto.com/learn/brc-20-token/</ref>, all transactions will be processed promptly in toichain without congestion or scaling problems.
== Toichain TestNet Launch ==
The toichain testnet launch will enable users to interact with one another through simple payments, just like the original Bitcoin network. Forever NFTs are supported. Smart contracts will be supported on a later date.

= References =
<references />

Consult the [[mediawikiwiki:Special:MyLanguage/Help:Contents|User's Guide]] for information on using the wiki software.

Main Page

2024-10-13T13:58:39Z

Justin: /* A Scalability Solution */

= <strong><big>'''Welcome to Toi-Twiki -- A Toichain Wiki'''</big></strong> =
This is the unofficial Toichain wiki site. Content is subject to changes.
---------------------------

= '''Introduction''' =
The blockchain protocol was introduced in a seminal paper entitled "Bitcoin: A peer-to-peer Electronic Cash System" <ref>https://bitcoin.org/bitcoin.pdf</ref> by Satoshi Nakamoto in 2008. Although there were previous peer-to-peer file-sharing projects such as Napster <ref>https://www.napster.com/us</ref>, BitTorrent <ref>https://www.bittorrent.com/</ref> and other electronic currency/file sharing applications, Bitcoin is the most enduring among the 23,000+ blockchains. Unlike other cryptocurrencies, the Bitcoin is often referred to as "digital gold" since the total coin supply is limited to 21 million (hard-coded in all running programs) and the only way to earn coin is to participate in the transaction block validation process. Token(or coin) supply and their disbursement policies differ among protocols.

The most attractive common blockchain features are 1) a decentralized consensus-driven decision making process and 2) a step-by-step cryptographic proving system. While blockchain is best known as a cryptocurrency transaction processing and record-keeping system, there are many other applications that can benefit from the secure storage, reliable transaction ledgers, fault tolerance and tamper resistance features.

== Algorithm vs. Protocol ==
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 ==
A good consensus protocol in a blockchain system has at least four properties:

# Fault tolerance to defend failures caused by natural disasters and human hacks or accidents
# Byzantine failure tolerance to defend exploitation by colluding parties
# Centralization avoidance to prevent corruptions in the decision making process
# Source code tamper resistance to automatically reject malicious attacks

Without assuming all nodes are active at all times, the blockchain relies on "gossip" protocol to communicate with other nodes. There are two popular types of consensus protocols: Proof of Work ('''PoW''') <ref>https://en.wikipedia.org/wiki/Proof_of_work</ref> or Proof of Stake ('''PoS''') <ref>https://www.investopedia.com/terms/p/proof-stake-pos.asp</ref>. Others include Proof of Possession('''PoP''')<ref>https://identityserver4.readthedocs.io/en/latest/topics/pop.html</ref> and Proof of History('''PoH''')<ref>https://www.infoworld.com/article/3666736/solana-blockchain-and-the-proof-of-history.html</ref>. The ultimate goal is to eliminate double-spending. Since most projects are open source, it's easy for a malicious actor to tamper a few nodes. This shouldn't compromise network integrity.

The Bitcoin network uses PoW which forces participating miners to compete for the fastest hashing rate by solving a computational cryptographic puzzle. Although it withstood more than 14 years of use, Bitcoin has been criticized for escalating electricity consumption <ref>https://www.forbes.com/advisor/investing/cryptocurrency/bitcoins-energy-usage-explained/</ref>. Other blockchain designs have experienced different challenges. For example, the PoH network Solana suffered multiple single-point-failure incidents <ref>https://messari.io/report/solana-analyzing-downtimes-statistics-and-ecosystem-development</ref>. All protocols struggle to combat scaling challenges. All are susceptible to 51% attacks <ref>https://originstamp.com/blog/has-there-ever-been-a-51-attack-on-bitcoin/#notable-51-attacks</ref>.

Since 2009, Bitcoin has proven to be the strongest and least susceptible to common hacks <ref>https://www.theguardian.com/technology/2014/mar/18/history-of-bitcoin-hacks-alternative-currency</ref>. As the PoW puzzle difficulty has increased dramatically over the years, the probability of a 51% attack on the Bitcoin network becomes more difficult. PoS protocols can save more than 90% energy consumption compared to PoW chains. But PoS chains have higher risks than PoW chains since a stolen coin will grow in PoS chains (for increased probability to be selected) forever but not in PoW chains (only hash rates count). PoS community governance rules can mitigate the voting power centralization problem. Staking and slashing policies can incentivize good behaviors and punish bad ones. In either case, double-spend is very expensive and difficult. According to Forbes, there are 80 cryptocurrencies that use PoS protocols at the time of this writing.

There are approximately 1,000 blockchains in four types: public, private, consortium, and permissioned <ref>https://increditools.com/blockchains/</ref>.

== Cryptographic Proofs ==
Bitcoin 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.

== Centralized vs. Decentralized Applications ==
The Bitcoin protocol enabled decentralized processing of traditionally centrally processed transactions without any trusted third-party. It inspired many decentralized financial applications, especially for applications with very long payment chains. However for fraud prevention and meeting financial regulatory requirements, many practical applications still require KYC (know your customer) checks. It is not possible to eliminate all trusted third parties, especially for custodial financial applications. There is a clear need for decentralized processing of trusted authority applications.

== Blockchain Trilemma ==
Blockchain protocols have three common aspects (goals): '''security''', '''decentralization''' and '''scalability''' -- these three terms do not have precise definitions but are intuitively understood <ref>https://sensoriumxr.com/articles/what-is-the-blockchain-trilemma</ref>. To date, 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.

A major shortcoming is scalability. Since all nodes verify each transaction independently, they need to store all the information required for it. As the chain grows, this burdens all nodes in the network. There are workarounds by limiting the amount of data stored on some nodes and exploiting the network to retrieve required information, such as the ''Limited/Light Nodes'' in Bitcoin network. Vast majority nodes are still full nodes in the existing Bitcoin network. Transaction processing speed often expressed ''as transactions per second(TPS) of'' blockchain have to exceed TPS ratings of credit card payment systems like VISA or MasterCard to reap the full benefits of blockchain. This is a tough problem and increasing the block size and/or reducing the block time or difficulty isn't a solution<ref>https://medium.com/coinmonks/blockchain-scaling-30c9e1b7db1b</ref>. Since blockchain TPS is very low, the transaction fees is often very high. This discourages public adoption. Layer 2 solution like ''Lightning Network'' or ''ZK-rollups,'' where only final settlement is on the main chain tend to address these issues. However, one could always argue that this often compromises some aspects of security and/or decentralization to achieve high TPS.

The trilemma was first introduced by Vitalik Buterin<ref>https://en.wikipedia.org/wiki/Vitalik_Buterin</ref>, one of the co-founders of Ethereum network. The problems he identified are real. There seem to be no obvious solutions that can accomplish all three goals at the same time. Therefore, all proposed solutions revolve around reducing "opportunity costs" focusing only on satisfying partial goals.

Treating the blockchain network as an infrastructure for transaction processing, the blockchain protocol solved service reliability problem but not performance challenge. The legacy infrastructure scaling dilemma: performance against reliability remains (where "infrastructure reliability" also does not have a commonly accepted definition). Fortunately these metrics, although important, are non-critical. Solutions that have been proposed have had varying opportunity costs. For many years, there were no obvious solutions that addressed all three blockchain goals (security, decentralization and scalability).
== Statistic Multiplexed Computing (SMC) ==
The principle of using unreliable components to build an arbitrarily reliable system was first lectured by von Neumann in the early 1950s<ref>https://static.ias.edu/pitp/archive/2012files/Probabilistic_Logics.pdf</ref>. The original idea was to use probabilistic logic to quantify the arbitrary reliability of a system by multiplexing all components. This theory was applied to the construction of Internet protocols to deliver the "best effort" reliability. Incidentally, best effort reliability also enabled "best effort" performance which in turn enabled unlimited scalability of the Internet. For emerging web3.0 technologies, it is important to apply the same methodology to both centralized and decentralized computing for seamless technology migration and integration. For historical arguments, click [[SMC|'''''here''''']].

== Definitions ==
'''Infrastructure scalability''' does not have a commonly accepted definition. It helps to define the challenging metrics more precisely before the infrastructure protocol design. In the following, for definitions #1 and #2, the word "'''infrastructure'''" means any '''application running on the infrastructure.'''

# '''Infrastructure Reliability''': MTBF (mean time between failure) = <math>\frac{\sum ((Start-Of-Downtime) - (Start-of-uptime)) }{No-of-failures}</math>
# '''Infrastructure Performance''': <math>\frac{No-of-Transactions}{Second}</math>
# '''Infrastructure Scalability''': Expanding the infrastructure in number of processors, networks or storage should have '''incrementally better''' impacts on application reliability and performance.
# '''Record Immutability''': For transaction ledgers, all confirmed records and changes are final. This is required by the blockchain protocol.
Note that in practice, record immutability is much harder to achieve than expected. There are two challenges, a) 51% attacks can literally wipe out all histories if successful, and b) for protocols require all nodes to hold independently verified ledger, such as the Bitcoin, the storage requirement grows approximately 50GB per month.

== 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 and considered.

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 crashe'''s <ref>https://groups.csail.mit.edu/tds/papers/Lynch/jacm93.pdf</ref>. The laws of physics regarding component reliability <ref>Encyclopedia of Physical Science and Technology, Editor-in-Chief Robert A. Meyers, [[index.php?title=Special:BookSources/9780122274107|ISBN 978-0-12-227410-7]], 2001</ref> show that '''100% component reliability is not possible.''' These facts require that the infrastructure protocol (program-program communication protocol) provide '''complete component (processing, networking and storage) decoupling''' from application program logics. This decoupling requirement forces the protocol to exploit "decentralized" or "stateless" components that the legacy infrastructure protocols, such as message passing interface (MPI), remote procedure call (RPC) and remote method invocation (RMI), cannot handle. The blockchain protocol is an example of a "best effort" availability protocol.

Quantifying infrastructure reliability can be traced back to the computer pioneer von Neumann. In addition to his contribution to computer architecture, von Neumann also penned a study on building reliable systems using unreliable components using probabilistic logics, in early fifties <ref>https://static.ias.edu/pitp/archive/2012files/Probabilistic_Logics.pdf</ref>. The 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 "best effort" reliability. Ironically, this best effort reliability also enabled the Internet's infinite scalability -- the benefit we enjoy now and into the future.

The Bitcoin protocol exploits multiple anonymous decoupled (or decentralized) computers connected through the Internet protocol. Judging from the Bitcoin network's reliability to date <ref>https://buybitcoinworldwide.com/bitcoin-downtime/</ref>, von Neumann's theory seems working well.

The '''second challenge''' involves infrastructure performance. Since the infrastructure must deploy multiple computing, networking and storage components, unless all components can be fully exploited at 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 lack this capability.

'''The infrastructure scalability challenge''' is automatically resolved once the performance challenge is resolved without negatively impacting reliability -- "best effort" performance" meets "best effort reliability". This requires inductive performance and reliability measures or deliveries.

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, an inductive statistic multiplexed blockchain protocol is needed to meet the scalability challenge. Non-inductive solutions such as fixed chain "sharding" or "Danksharding" <ref>https://ethereum.org/en/roadmap/danksharding/</ref> will only increase protocol development complexity with persistent performance walls.

== A Scalability Solution ==
An effective scalability solution can have two practical assumptions:

* The computation problem size can expand indefinitely, since every useful infrastructure is expected to solve bigger problems.

*Computing and network resources will continue to grow indefinitely, into the future.
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 <ref>https://en.wikipedia.org/wiki/Amdahl%27s_law</ref> and Gustafson's Law <ref>https://en.wikipedia.org/wiki/Gustafson%27s_law</ref>.

The Amdahl's Law assumes 0<= ''s'' <=1 percentage of serial instructions that cannot be parallelized. Then the ''(1-s)'' percentage of instructions can be accelerated using ''p'' processors.

<div style="text-align: center;">
Speedup(p) = <math>{1 \over s + {(1-s) \over p}}</math> (1) <br>Speedup(<math>\lim_{p \to \infty}</math>) = <math>\frac{1}{s}</math> (2)
</div>
Taking ''p'' to infinity in equation (1) yields equation (2). But this derivation step has two different operational semantics: a) increasing ''p'' to further reduce the value of (''1-s)/p'' solving the same problem. This will result ''s'' asymptotically approaching 1. Thus the speedup is above founded to 1. Or b) increasing ''p'' to increase the parallel percentage ''(1-s)'' by solving bigger problems. This will force ''s'' asymptotically approach 0. Then the speedup is above bounded by <math>\infty</math>. This scaling ambiguity caused more than three decades of confusion in the community.

Although quantifying ''s'' requires additional information, such as the problem size, the model is applicable to programs solving any problem size with any percentage ''s''. The limit of speedup (2) also does not depend on problem size. However, since Amdahl originally used programs solving fixed problem sizes to argue the validity of not building parallel machines with too many processors, assuming fixed problem size using ''p'' processors has been the norm in interpreting Amdahl's law in the past. This assumption has led to the dismal speedup predictions.[[File:Amdahl's Law.png|thumb|Amdahl's Law Speedup Predictions|center]]The traditional Amdahl's Law interpretation seems to suggest parallel performances following the economic law of diminishing of returns, even though the mathematic model implies more potentials.

In 1988, Gustafson and Barsis at the Sandia National Laboratory conducted parallel computing experiments that seem to suggest potential infinite speedup.

Gustafson's Law was based on measured sequential and parallel elapsed times using ''p'' (=1024) processors. A new sequential percentage ''0<=x'<=1'' can be calculated using ''p'' processors. ''(1-x')'' is the parallel percentage using ''p'' processors.

To estimate accomplished speedup, Gustafson's Law states:

<div style="text-align: center;">
<math>Speedup=\frac{Tseq}{Tpar}=\frac{s'+(1-s')p}{1}=s'+(1-s')p </math> (3)
</div>

Take ''p'' -> <math>\infty</math> for equation (3) also has two operational semantics: a) Keep the problem size fixed, adding processors to further reduce the total parallel processing time, thus bigger s'. This will yield s' approaching 1. Thus speedup is also bounded to 1. Or b) expanding the problem size to allow the parallel part expanded solving bigger problems. This will yield s' asymptotically approaching 0. Speedup will be above bounded to ''p''. Gustafson's Law was used to argue for Massively Parallel Computing (MPC) (or ManyCPU) experiments and Amdahl's Law was used to argue for bigger mainframe (or BigCPU) computer architectures. In the past decades, these laws have been used to support two diverging computing system experiments and constructions until recent convergence.
[[File:Gustafson.png|thumb|Gustafson's Law|center]]
It is now obvious that the two law are identical with Amdahl's Law more succinct. But Gustafson's formula helps to quantify the serial percentages from practical program executions. In fact, the two serial percentages can be related by a simple equation<ref>https://www.researchgate.net/publication/228367369_Reevaluating_Amdahl's_law_and_Gustafson's_law</ref>:

<div style="text-align: center;">
<math>s=\frac{s'}{s'+(1-s')p}</math> (4)
</div>

Both law actually refer to the same mathematical abstraction. Gustafson's formula assisted in quantifying the percentage of serial computing through program experiments. Neither should be directly used for speedup prediction alone.

This model can be validated in practice when developers simply increasing the problem size to use more parallel processors.

[[File:Full Range Amdah's Law .png|alt=Full Power of Amdahl's Law|center|thumb|Full Power of Amdahl's Law]]

If we plot the full speedup curves against the number of processors, we will see the missing lines.

A classical example is the TOP500 supercomputer benchmarks (linear solvers) that have open problem sizes for all manufacturers to compete in the world's fastest supercomputer race <ref>https://www.top500.org/</ref> .
[[File:Supercomputers-history.png|center|thumb]]
In practical blockchain applications, the number of transactions to be processed will increase without a known limit. The ledger storage will continue to grow. In practice, the available computing, networking and storage components will continue to grow without limits enabled by the networking protocols. Therefore a statistic multiplexed computing blockchain can meet any future application needs given proper economic incentives. The infrastructure no longer has the structural deficiency.

== Action Plan ==

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.

For Toichain protocol design, we choose Bitcoin 24.0.1 as the base line protocol by replacing the PoW consensus by PoS consensus and injecting SMC components into the protocol processing signaling for parallel computing.

This surprising result is also applicable to ledger storage. Without multiplexing, the blockchain ledger storage will eventually saturate all nodes causing the chain to collapse. The SMC blockchain protocol promises to hold the true finality of all transactions in perpetuity by multiplexing all storage resources while keeping the replication factor to a constant.

These discussions follow the inductive logic of the Law of Large Numbers <ref>https://www.sciencedirect.com/topics/mathematics/laws-of-large-number</ref>.

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

= SMC Proof of Stake Protocol =
Existing PoS protocol designs revolved around staking policies and randomness of the selection algorithm. Considering infrastructure scalability will add much complexity to the design. The examples include chain sharding and Danksharding <ref>https://ethereum.org/en/roadmap/danksharding/</ref>.

The challenge is complex -- we must deliver very high performance without compromising security and reliability of the network.

Technically, transaction replication and parallel processing were considered dangerous <ref>https://pages.cs.wisc.edu/~yxy/cs764-f20/papers/replication.pdf</ref> due to the potential race conditions (or double-spend problem). The blockchain protocol resolved the double-spending problem. It did not solve the parallel processing performance problem.

According to Professor Michael Flynn, there are three high-level parallel processing topologies: SIMD (single instruction multiple data), MIMD (multiple instructions multiple data), and pipeline (MISD - multiple instructions single data stream) <ref>https://link.springer.com/referenceworkentry/10.1007/978-0-387-09766-4_2</ref>. However, for eliminating double-spending, all transactions must be serialized, since each block may contain transactions affecting transactions in multiple other blocks. "Race conditions" and non-deterministic results are not allowed. Then the only possible topology entry is pipeline. This means for POS protocol, we must build a pipeline of transaction blocks to be validated without compromising network security and reliability.
[[File:Flynns-Taxonomy-of-Computer-Architectures.png|center|thumb|Parallel Processing Topologies]]
The problem is that the nature of the blockchain protocol is that all nodes run independently in parallel with little communication with other nodes via "gossip" protocols. It is far easier to force all nodes store the entire ledger than forcing them to form any pipeline and store partial chain data.

=== ACAN (Active Content Addressable Network) [U.S. PTO #11,588,926 B2] ===
ACAN is a high-level data '''''communication and synchronization protocol''''' that completely decouples all hardware components from communicating programs. The need for complete component decoupling was implemented in the original blockchain protocol via "gossip" protocol. This delivered blockchain's high availability and security. The simple "gossip" implementation in existing protocols is insufficient for parallel processing signaling.

The following figure illustrates the concept of ACAN (active content addressable networking) using UVR (unidirectional virtual ring) architecture. The illustrated implementation uses the Tuple Space resource tagging method and gossip protocol for UVR implementation.
[[File:SMC Architecture with ACAN.png|center|thumb|243x243px|SMC Architecture with ACAN]]

ACAN supports three simple APIs:

# '''read'''(&''key'', &''value''): ''key'' holds a search pattern in a "tuple space" where all nodes are connected. ''value'' holds the matched tuple, if any. This is a blocking call that a requesting program will be blocked until a pattern-matched tuple is found. The matching tuple remains in the "tuple space".
# '''get'''(&key, &value): Same as the "read()" API, except that the matching tuple is removed from the "tuple space".
# '''put'''(key, value): Inserts <key, value> into the "tuple space".

The use of "gossip" protocol can accelerate ACAN network saturation time. Applications running on ACAN will automatically form parallel processing topologies: pipeline, SIMD and MIMD without violating the serialization needs of transaction block validation. Replication factor can also be dynamically controlled to spread replicated blocks in randomly chosen hosts.

The highly parallel nature of the blockchain protocol will automatically implement the SMC principle in real time.

The critical feature of this dynamic SMC pipelined architecture is the inductive scaling feature.
[[File:Pipeline Parallel Processing.png|center|thumb|247x247px|Pipeline Parallel Processing]]

The speed up of a pipeline can be represented as: <math>SpeedUp = \left ( \frac{p\centerdot b}{p + (b-1)} \right )</math>, where p = number of processors in the pipeline, b = total blocks to be processed. Take the number of blocks to infinity:

<div style="text-align: center;">
<math>SpeedUp = \left ( \frac{p\centerdot b}{p + (b-1)} \right )=>\lim (b\Rightarrow\infty)(\frac{p}{\frac{p}{b}+1-\frac{1}{b}}) = p</math>
</div>

This means that as long as there are enough blocks to be processed, the entire chain's performance will be abound-bounded to the number of nodes in the pipeline.

For illustration purposes, the variation of block processing times was not considered in the above calculations. To see the power of pipeline parallelism, the automobile manufacturing processes illustrate a similar situation. The Hyundai Motor Company's production pipelines can produce 3,835 vehicles per day and 1.4M per year<ref>https://en.wikipedia.org/wiki/List_of_Hyundai_Motor_Company_manufacturing_facilities</ref>.

== Toichain Tokens ==
Toichain token is TOIN. There are 50,000,000,000 TOINs for the Alpha Release. There are air-drop tokens for early adopters, 1,000 TOIN each. Users need to register to download a toichain wallet to receive the payment. Citizenship is checked and verified to ensure that US citizens do not apply. The minimal staking contract is 10 TOINs.

== Non-Fungible Tokens ==
The TestNet Release of toichain protocol will support embedding arbitrary data in an "OP_RETURN" transaction that will be permanently recorded on the chain. Unlike the ordinal NFT <ref>https://blog.chain.link/ordinals-bitcoin-nfts/</ref> or NFT (non-fungible token) on other chains, these transactions cannot be altered or removed.

There are practical applications for these forever NFTs. Once Taproot is enabled on toichain, ordinal NFTs (BRC-20) will also be supported. Unlike the original Bitcoin network where BRC-20 craze has created massive network congestion<ref>https://beincrypto.com/learn/brc-20-token/</ref>, all transactions will be processed promptly in toichain without congestion or scaling problems.
== Toichain TestNet Launch ==
The toichain testnet launch will enable users to interact with one another through simple payments, just like the original Bitcoin network. Forever NFTs are supported. Smart contracts will be supported on a later date.

= References =
<references />

Consult the [[mediawikiwiki:Special:MyLanguage/Help:Contents|User's Guide]] for information on using the wiki software.

Main Page

2024-10-12T22:39:33Z

Justin: /* ACAN (Active Content Addressable Network) [U.S. PTO #11,588,926 B2] */

= <strong><big>'''Welcome to Toi-Twiki -- A Toichain Wiki'''</big></strong> =
This is the unofficial Toichain wiki site. Content is subject to changes.
---------------------------

= '''Introduction''' =
The blockchain protocol was introduced in a seminal paper entitled "Bitcoin: A peer-to-peer Electronic Cash System" <ref>https://bitcoin.org/bitcoin.pdf</ref> by Satoshi Nakamoto in 2008. Although there were previous peer-to-peer file-sharing projects such as Napster <ref>https://www.napster.com/us</ref>, BitTorrent <ref>https://www.bittorrent.com/</ref> and other electronic currency/file sharing applications, Bitcoin is the most enduring among the 23,000+ blockchains. Unlike other cryptocurrencies, the Bitcoin is often referred to as "digital gold" since the total coin supply is limited to 21 million (hard-coded in all running programs) and the only way to earn coin is to participate in the transaction block validation process. Token(or coin) supply and their disbursement policies differ among protocols.

The most attractive common blockchain features are 1) a decentralized consensus-driven decision making process and 2) a step-by-step cryptographic proving system. While blockchain is best known as a cryptocurrency transaction processing and record-keeping system, there are many other applications that can benefit from the secure storage, reliable transaction ledgers, fault tolerance and tamper resistance features.

== Algorithm vs. Protocol ==
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 ==
A good consensus protocol in a blockchain system has at least four properties:

# Fault tolerance to defend failures caused by natural disasters and human hacks or accidents
# Byzantine failure tolerance to defend exploitation by colluding parties
# Centralization avoidance to prevent corruptions in the decision making process
# Source code tamper resistance to automatically reject malicious attacks

Without assuming all nodes are active at all times, the blockchain relies on "gossip" protocol to communicate with other nodes. There are two popular types of consensus protocols: Proof of Work ('''PoW''') <ref>https://en.wikipedia.org/wiki/Proof_of_work</ref> or Proof of Stake ('''PoS''') <ref>https://www.investopedia.com/terms/p/proof-stake-pos.asp</ref>. Others include Proof of Possession('''PoP''')<ref>https://identityserver4.readthedocs.io/en/latest/topics/pop.html</ref> and Proof of History('''PoH''')<ref>https://www.infoworld.com/article/3666736/solana-blockchain-and-the-proof-of-history.html</ref>. The ultimate goal is to eliminate double-spending. Since most projects are open source, it's easy for a malicious actor to tamper a few nodes. This shouldn't compromise network integrity.

The Bitcoin network uses PoW which forces participating miners to compete for the fastest hashing rate by solving a computational cryptographic puzzle. Although it withstood more than 14 years of use, Bitcoin has been criticized for escalating electricity consumption <ref>https://www.forbes.com/advisor/investing/cryptocurrency/bitcoins-energy-usage-explained/</ref>. Other blockchain designs have experienced different challenges. For example, the PoH network Solana suffered multiple single-point-failure incidents <ref>https://messari.io/report/solana-analyzing-downtimes-statistics-and-ecosystem-development</ref>. All protocols struggle to combat scaling challenges. All are susceptible to 51% attacks <ref>https://originstamp.com/blog/has-there-ever-been-a-51-attack-on-bitcoin/#notable-51-attacks</ref>.

Since 2009, Bitcoin has proven to be the strongest and least susceptible to common hacks <ref>https://www.theguardian.com/technology/2014/mar/18/history-of-bitcoin-hacks-alternative-currency</ref>. As the PoW puzzle difficulty has increased dramatically over the years, the probability of a 51% attack on the Bitcoin network becomes more difficult. PoS protocols can save more than 90% energy consumption compared to PoW chains. But PoS chains have higher risks than PoW chains since a stolen coin will grow in PoS chains (for increased probability to be selected) forever but not in PoW chains (only hash rates count). PoS community governance rules can mitigate the voting power centralization problem. Staking and slashing policies can incentivize good behaviors and punish bad ones. In either case, double-spend is very expensive and difficult. According to Forbes, there are 80 cryptocurrencies that use PoS protocols at the time of this writing.

There are approximately 1,000 blockchains in four types: public, private, consortium, and permissioned <ref>https://increditools.com/blockchains/</ref>.

== Cryptographic Proofs ==
Bitcoin 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.

== Centralized vs. Decentralized Applications ==
The Bitcoin protocol enabled decentralized processing of traditionally centrally processed transactions without any trusted third-party. It inspired many decentralized financial applications, especially for applications with very long payment chains. However for fraud prevention and meeting financial regulatory requirements, many practical applications still require KYC (know your customer) checks. It is not possible to eliminate all trusted third parties, especially for custodial financial applications. There is a clear need for decentralized processing of trusted authority applications.

== Blockchain Trilemma ==
Blockchain protocols have three common aspects (goals): '''security''', '''decentralization''' and '''scalability''' -- these three terms do not have precise definitions but are intuitively understood <ref>https://sensoriumxr.com/articles/what-is-the-blockchain-trilemma</ref>. To date, 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.

A major shortcoming is scalability. Since all nodes verify each transaction independently, they need to store all the information required for it. As the chain grows, this burdens all nodes in the network. There are workarounds by limiting the amount of data stored on some nodes and exploiting the network to retrieve required information, such as the ''Limited/Light Nodes'' in Bitcoin network. Vast majority nodes are still full nodes in the existing Bitcoin network. Transaction processing speed often expressed ''as transactions per second(TPS) of'' blockchain have to exceed TPS ratings of credit card payment systems like VISA or MasterCard to reap the full benefits of blockchain. This is a tough problem and increasing the block size and/or reducing the block time or difficulty isn't a solution<ref>https://medium.com/coinmonks/blockchain-scaling-30c9e1b7db1b</ref>. Since blockchain TPS is very low, the transaction fees is often very high. This discourages public adoption. Layer 2 solution like ''Lightning Network'' or ''ZK-rollups,'' where only final settlement is on the main chain tend to address these issues. However, one could always argue that this often compromises some aspects of security and/or decentralization to achieve high TPS.

The trilemma was first introduced by Vitalik Buterin<ref>https://en.wikipedia.org/wiki/Vitalik_Buterin</ref>, one of the co-founders of Ethereum network. The problems he identified are real. There seem to be no obvious solutions that can accomplish all three goals at the same time. Therefore, all proposed solutions revolve around reducing "opportunity costs" focusing only on satisfying partial goals.

Treating the blockchain network as an infrastructure for transaction processing, the blockchain protocol solved service reliability problem but not performance challenge. The legacy infrastructure scaling dilemma: performance against reliability remains (where "infrastructure reliability" also does not have a commonly accepted definition). Fortunately these metrics, although important, are non-critical. Solutions that have been proposed have had varying opportunity costs. For many years, there were no obvious solutions that addressed all three blockchain goals (security, decentralization and scalability).
== Statistic Multiplexed Computing (SMC) ==
The principle of using unreliable components to build an arbitrarily reliable system was first lectured by von Neumann in the early 1950s<ref>https://static.ias.edu/pitp/archive/2012files/Probabilistic_Logics.pdf</ref>. The original idea was to use probabilistic logic to quantify the arbitrary reliability of a system by multiplexing all components. This theory was applied to the construction of Internet protocols to deliver the "best effort" reliability. Incidentally, best effort reliability also enabled "best effort" performance which in turn enabled unlimited scalability of the Internet. For emerging web3.0 technologies, it is important to apply the same methodology to both centralized and decentralized computing for seamless technology migration and integration. For historical arguments, click [[SMC|'''''here''''']].

== Definitions ==
'''Infrastructure scalability''' does not have a commonly accepted definition. It helps to define the challenging metrics more precisely before the infrastructure protocol design. In the following, for definitions #1 and #2, the word "'''infrastructure'''" means any '''application running on the infrastructure.'''

# '''Infrastructure Reliability''': MTBF (mean time between failure) = <math>\frac{\sum ((Start-Of-Downtime) - (Start-of-uptime)) }{No-of-failures}</math>
# '''Infrastructure Performance''': <math>\frac{No-of-Transactions}{Second}</math>
# '''Infrastructure Scalability''': Expanding the infrastructure in number of processors, networks or storage should have '''incrementally better''' impacts on application reliability and performance.
# '''Record Immutability''': For transaction ledgers, all confirmed records and changes are final. This is required by the blockchain protocol.
Note that in practice, record immutability is much harder to achieve than expected. There are two challenges, a) 51% attacks can literally wipe out all histories if successful, and b) for protocols require all nodes to hold independently verified ledger, such as the Bitcoin, the storage requirement grows approximately 50GB per month.

== 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 and considered.

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 crashe'''s <ref>https://groups.csail.mit.edu/tds/papers/Lynch/jacm93.pdf</ref>. The laws of physics regarding component reliability <ref>Encyclopedia of Physical Science and Technology, Editor-in-Chief Robert A. Meyers, [[index.php?title=Special:BookSources/9780122274107|ISBN 978-0-12-227410-7]], 2001</ref> show that '''100% component reliability is not possible.''' These facts require that the infrastructure protocol (program-program communication protocol) provide '''complete component (processing, networking and storage) decoupling''' from application program logics. This decoupling requirement forces the protocol to exploit "decentralized" or "stateless" components that the legacy infrastructure protocols, such as message passing interface (MPI), remote procedure call (RPC) and remote method invocation (RMI), cannot handle. The blockchain protocol is an example of a "best effort" availability protocol.

Quantifying infrastructure reliability can be traced back to the computer pioneer von Neumann. In addition to his contribution to computer architecture, von Neumann also penned a study on building reliable systems using unreliable components using probabilistic logics, in early fifties <ref>https://static.ias.edu/pitp/archive/2012files/Probabilistic_Logics.pdf</ref>. The 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 "best effort" reliability. Ironically, this best effort reliability also enabled the Internet's infinite scalability -- the benefit we enjoy now and into the future.

The Bitcoin protocol exploits multiple anonymous decoupled (or decentralized) computers connected through the Internet protocol. Judging from the Bitcoin network's reliability to date <ref>https://buybitcoinworldwide.com/bitcoin-downtime/</ref>, von Neumann's theory seems working well.

The '''second challenge''' involves infrastructure performance. Since the infrastructure must deploy multiple computing, networking and storage components, unless all components can be fully exploited at 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 lack this capability.

'''The infrastructure scalability challenge''' is automatically resolved once the performance challenge is resolved without negatively impacting reliability -- "best effort" performance" meets "best effort reliability". This requires inductive performance and reliability measures or deliveries.

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, an inductive statistic multiplexed blockchain protocol is needed to meet the scalability challenge. Non-inductive solutions such as fixed chain "sharding" or "Danksharding" <ref>https://ethereum.org/en/roadmap/danksharding/</ref> will only increase protocol development complexity with persistent performance walls.

== A Scalability Solution ==
An effective scalability solution can have two practical assumptions:

* The computation problem size can expand indefinitely, since every useful infrastructure is expected to solve bigger problems.

*Computing and network resources will continue to grow indefinitely, into the future.
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 <ref>https://en.wikipedia.org/wiki/Amdahl%27s_law</ref> and Gustafson's Law <ref>https://en.wikipedia.org/wiki/Gustafson%27s_law</ref>.

The Amdahl's Law assumes 0<= ''s'' <=1 percentage of serial instructions that cannot be parallelized. Then the ''(1-s)'' percentage of instructions can be accelerated using ''p'' processors.

<div style="text-align: center;">
Speedup(p) = <math>{1 \over s + {(1-s) \over p}}</math> (1) <br>Speedup(<math>\lim_{p \to \infty}</math>) = <math>\frac{1}{s}</math> (2)
</div>
Taking ''p'' to infinity in equation (1) yields equation (2). But this derivation step has two different operational semantics: a) increasing ''p'' to reduce (''1-s)'' value while keeping the problem size fixed. This will result ''s'' asymptotically approaching 1. Thus the speedup is above founded to 1. Or b) increasing p to increase the parallel percentage ''(1-s)'' by solving bigger problems. This will force ''s'' asymptotically approach 0. Then the speedup is above bounded by <math>\infty</math>. This ambiguity caused more than three decades of confusion in the community.

Although quantifying ''s'' requires additional information, such as the problem size, the law is applicable to programs solving any problem size with a known ''s''. The limit of speedup (2) also does not depend on problem size. However, since Amdahl used programs solving fixed problem sizes to argue the validity of not building parallel machines with too many processors, assuming fixed problem size using ''p'' processors has been the norm in interpreting Amdahl's law in the past. This assumption has led to the dismal speedup predictions.[[File:Amdahl's Law.png|thumb|Amdahl's Law Speedup Predictions|center]]The traditional Amdahl's Law interpretation seems to suggest parallel performances following the economic law of diminishing of returns, even though the mathematic model implies more potentials.

In 1988, Gustafson and Barsis at the Sandia National Laboratory conducted parallel computing experiments that seem to suggest potential infinite speedup.

Gustafson's Law was based on measured sequential and parallel elapsed times using ''p'' (=1024) processors. A new sequential percentage ''0<=x'<=1'' can be calculated. ''(1-x')'' is the parallel percentage using ''p'' processors.

To estimate accomplished speedup, Gustafson's Law states:

<div style="text-align: center;">
<math>Speedup=\frac{Tseq}{Tpar}=\frac{s'+(1-s')p}{1}=s'+(1-s')p </math> (3)
</div>

Take ''p'' -> <math>\infty</math> for equation (3) also has two operational semantics: a) Keep the problem size fixed, adding processors to further reduce the total parallel processing time, thus bigger s'. This will yield s' approaching 1. Thus speedup is above bounded to 1. Or b) expanding the problem size to allow the parallel part expanded solving bigger problems. This will yield s' asymptotically approaching 0. Speedup will be above bounded to ''p''. However, Gustafson's Law was used to argue for Massively Parallel Computing (MPC) (or ManyCPU) experiments and Amdahl's Law was used to argue for bigger mainframe (or BigCPU) computer architectures. In the past decades, these laws have been used to support two diverging computing system experiments and constructions until recently.
[[File:Gustafson.png|thumb|Gustafson's Law|center]]
It is now obvious that the two law are identical with Amdahl's Law more succinct. But Gustafson's formula helps to quantify the serial percentages from practical program executions. In fact, the two serial percentages can be related by a simple equation<ref>https://www.researchgate.net/publication/228367369_Reevaluating_Amdahl's_law_and_Gustafson's_law</ref>:

<div style="text-align: center;">
<math>s=\frac{s'}{s'+(1-s')p}</math> (4)
</div>

Both law actually refer to the same mathematical abstraction. Gustafson's formula assisted in quantifying the percentage of serial computing through program experiments. Neither should be directly used for speedup prediction alone.

This model can be validated in practice when developers simply increasing the problem size to use more parallel processors.

[[File:Full Range Amdah's Law .png|alt=Full Power of Amdahl's Law|center|thumb|Full Power of Amdahl's Law]]

A classical example is the TOP500 supercomputer benchmarks (linear solvers) that have open problem sizes for all manufacturers to compete in the world's fastest supercomputer race <ref>https://www.top500.org/</ref> .
[[File:Supercomputers-history.png|center|thumb]]
In practical blockchain applications, the number of transactions to be processed will increase without a known limit. The ledger storage will continue to grow. In practice, the available computing, networking and storage components will continue to grow without limits enabled by the networking protocols. Therefore a statistic multiplexed computing blockchain can meet any future application needs given proper economic incentives. The infrastructure no longer has the structural deficiency.

== Action Plan ==

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.

For Toichain protocol design, we choose Bitcoin 24.0.1 as the base line protocol by replacing the PoW consensus by PoS consensus and injecting SMC components into the protocol processing signaling for parallel computing.

This surprising result is also applicable to ledger storage. Without multiplexing, the blockchain ledger storage will eventually saturate all nodes causing the chain to collapse. The SMC blockchain protocol promises to hold the true finality of all transactions in perpetuity by multiplexing all storage resources while keeping the replication factor to a constant.

These discussions follow the inductive logic of the Law of Large Numbers <ref>https://www.sciencedirect.com/topics/mathematics/laws-of-large-number</ref>.

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

= SMC Proof of Stake Protocol =
Existing PoS protocol designs revolved around staking policies and randomness of the selection algorithm. Considering infrastructure scalability will add much complexity to the design. The examples include chain sharding and Danksharding <ref>https://ethereum.org/en/roadmap/danksharding/</ref>.

The challenge is complex -- we must deliver very high performance without compromising security and reliability of the network.

Technically, transaction replication and parallel processing were considered dangerous <ref>https://pages.cs.wisc.edu/~yxy/cs764-f20/papers/replication.pdf</ref> due to the potential race conditions (or double-spend problem). The blockchain protocol resolved the double-spending problem. It did not solve the parallel processing performance problem.

According to Professor Michael Flynn, there are three high-level parallel processing topologies: SIMD (single instruction multiple data), MIMD (multiple instructions multiple data), and pipeline (MISD - multiple instructions single data stream) <ref>https://link.springer.com/referenceworkentry/10.1007/978-0-387-09766-4_2</ref>. However, for eliminating double-spending, all transactions must be serialized, since each block may contain transactions affecting transactions in multiple other blocks. "Race conditions" and non-deterministic results are not allowed. Then the only possible topology entry is pipeline. This means for POS protocol, we must build a pipeline of transaction blocks to be validated without compromising network security and reliability.
[[File:Flynns-Taxonomy-of-Computer-Architectures.png|center|thumb|Parallel Processing Topologies]]
The problem is that the nature of the blockchain protocol is that all nodes run independently in parallel with little communication with other nodes via "gossip" protocols. It is far easier to force all nodes store the entire ledger than forcing them to form any pipeline and store partial chain data.

=== ACAN (Active Content Addressable Network) [U.S. PTO #11,588,926 B2] ===
ACAN is a high-level data '''''communication and synchronization protocol''''' that completely decouples all hardware components from communicating programs. The need for complete component decoupling was implemented in the original blockchain protocol via "gossip" protocol. This delivered blockchain's high availability and security. The simple "gossip" implementation in existing protocols is insufficient for parallel processing signaling.

The following figure illustrates the concept of ACAN (active content addressable networking) using UVR (unidirectional virtual ring) architecture. The illustrated implementation uses the Tuple Space resource tagging method and gossip protocol for UVR implementation.
[[File:SMC Architecture with ACAN.png|center|thumb|243x243px|SMC Architecture with ACAN]]

ACAN supports three simple APIs:

# '''read'''(&''key'', &''value''): ''key'' holds a search pattern in a "tuple space" where all nodes are connected. ''value'' holds the matched tuple, if any. This is a blocking call that a requesting program will be blocked until a pattern-matched tuple is found. The matching tuple remains in the "tuple space".
# '''get'''(&key, &value): Same as the "read()" API, except that the matching tuple is removed from the "tuple space".
# '''put'''(key, value): Inserts <key, value> into the "tuple space".

The use of "gossip" protocol can accelerate ACAN network saturation time. Applications running on ACAN will automatically form parallel processing topologies: pipeline, SIMD and MIMD without violating the serialization needs of transaction block validation. Replication factor can also be dynamically controlled to spread replicated blocks in randomly chosen hosts.

The highly parallel nature of the blockchain protocol will automatically implement the SMC principle in real time.

The critical feature of this dynamic SMC pipelined architecture is the inductive scaling feature.
[[File:Pipeline Parallel Processing.png|center|thumb|247x247px|Pipeline Parallel Processing]]

The speed up of a pipeline can be represented as: <math>SpeedUp = \left ( \frac{p\centerdot b}{p + (b-1)} \right )</math>, where p = number of processors in the pipeline, b = total blocks to be processed. Take the number of blocks to infinity:

<div style="text-align: center;">
<math>SpeedUp = \left ( \frac{p\centerdot b}{p + (b-1)} \right )=>\lim (b\Rightarrow\infty)(\frac{p}{\frac{p}{b}+1-\frac{1}{b}}) = p</math>
</div>

This means that as long as there are enough blocks to be processed, the entire chain's performance will be abound-bounded to the number of nodes in the pipeline.

For illustration purposes, the variation of block processing times was not considered in the above calculations. To see the power of pipeline parallelism, the automobile manufacturing processes illustrate a similar situation. The Hyundai Motor Company's production pipelines can produce 3,835 vehicles per day and 1.4M per year<ref>https://en.wikipedia.org/wiki/List_of_Hyundai_Motor_Company_manufacturing_facilities</ref>.

== Toichain Tokens ==
Toichain token is TOIN. There are 50,000,000,000 TOINs for the Alpha Release. There are air-drop tokens for early adopters, 1,000 TOIN each. Users need to register to download a toichain wallet to receive the payment. Citizenship is checked and verified to ensure that US citizens do not apply. The minimal staking contract is 10 TOINs.

== Non-Fungible Tokens ==
The TestNet Release of toichain protocol will support embedding arbitrary data in an "OP_RETURN" transaction that will be permanently recorded on the chain. Unlike the ordinal NFT <ref>https://blog.chain.link/ordinals-bitcoin-nfts/</ref> or NFT (non-fungible token) on other chains, these transactions cannot be altered or removed.

There are practical applications for these forever NFTs. Once Taproot is enabled on toichain, ordinal NFTs (BRC-20) will also be supported. Unlike the original Bitcoin network where BRC-20 craze has created massive network congestion<ref>https://beincrypto.com/learn/brc-20-token/</ref>, all transactions will be processed promptly in toichain without congestion or scaling problems.
== Toichain TestNet Launch ==
The toichain testnet launch will enable users to interact with one another through simple payments, just like the original Bitcoin network. Forever NFTs are supported. Smart contracts will be supported on a later date.

= References =
<references />

Consult the [[mediawikiwiki:Special:MyLanguage/Help:Contents|User's Guide]] for information on using the wiki software.

Main Page

2024-10-12T22:37:05Z

Justin: /* A Scalability Solution */

= <strong><big>'''Welcome to Toi-Twiki -- A Toichain Wiki'''</big></strong> =
This is the unofficial Toichain wiki site. Content is subject to changes.
---------------------------

= '''Introduction''' =
The blockchain protocol was introduced in a seminal paper entitled "Bitcoin: A peer-to-peer Electronic Cash System" <ref>https://bitcoin.org/bitcoin.pdf</ref> by Satoshi Nakamoto in 2008. Although there were previous peer-to-peer file-sharing projects such as Napster <ref>https://www.napster.com/us</ref>, BitTorrent <ref>https://www.bittorrent.com/</ref> and other electronic currency/file sharing applications, Bitcoin is the most enduring among the 23,000+ blockchains. Unlike other cryptocurrencies, the Bitcoin is often referred to as "digital gold" since the total coin supply is limited to 21 million (hard-coded in all running programs) and the only way to earn coin is to participate in the transaction block validation process. Token(or coin) supply and their disbursement policies differ among protocols.

The most attractive common blockchain features are 1) a decentralized consensus-driven decision making process and 2) a step-by-step cryptographic proving system. While blockchain is best known as a cryptocurrency transaction processing and record-keeping system, there are many other applications that can benefit from the secure storage, reliable transaction ledgers, fault tolerance and tamper resistance features.

== Algorithm vs. Protocol ==
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 ==
A good consensus protocol in a blockchain system has at least four properties:

# Fault tolerance to defend failures caused by natural disasters and human hacks or accidents
# Byzantine failure tolerance to defend exploitation by colluding parties
# Centralization avoidance to prevent corruptions in the decision making process
# Source code tamper resistance to automatically reject malicious attacks

Without assuming all nodes are active at all times, the blockchain relies on "gossip" protocol to communicate with other nodes. There are two popular types of consensus protocols: Proof of Work ('''PoW''') <ref>https://en.wikipedia.org/wiki/Proof_of_work</ref> or Proof of Stake ('''PoS''') <ref>https://www.investopedia.com/terms/p/proof-stake-pos.asp</ref>. Others include Proof of Possession('''PoP''')<ref>https://identityserver4.readthedocs.io/en/latest/topics/pop.html</ref> and Proof of History('''PoH''')<ref>https://www.infoworld.com/article/3666736/solana-blockchain-and-the-proof-of-history.html</ref>. The ultimate goal is to eliminate double-spending. Since most projects are open source, it's easy for a malicious actor to tamper a few nodes. This shouldn't compromise network integrity.

The Bitcoin network uses PoW which forces participating miners to compete for the fastest hashing rate by solving a computational cryptographic puzzle. Although it withstood more than 14 years of use, Bitcoin has been criticized for escalating electricity consumption <ref>https://www.forbes.com/advisor/investing/cryptocurrency/bitcoins-energy-usage-explained/</ref>. Other blockchain designs have experienced different challenges. For example, the PoH network Solana suffered multiple single-point-failure incidents <ref>https://messari.io/report/solana-analyzing-downtimes-statistics-and-ecosystem-development</ref>. All protocols struggle to combat scaling challenges. All are susceptible to 51% attacks <ref>https://originstamp.com/blog/has-there-ever-been-a-51-attack-on-bitcoin/#notable-51-attacks</ref>.

Since 2009, Bitcoin has proven to be the strongest and least susceptible to common hacks <ref>https://www.theguardian.com/technology/2014/mar/18/history-of-bitcoin-hacks-alternative-currency</ref>. As the PoW puzzle difficulty has increased dramatically over the years, the probability of a 51% attack on the Bitcoin network becomes more difficult. PoS protocols can save more than 90% energy consumption compared to PoW chains. But PoS chains have higher risks than PoW chains since a stolen coin will grow in PoS chains (for increased probability to be selected) forever but not in PoW chains (only hash rates count). PoS community governance rules can mitigate the voting power centralization problem. Staking and slashing policies can incentivize good behaviors and punish bad ones. In either case, double-spend is very expensive and difficult. According to Forbes, there are 80 cryptocurrencies that use PoS protocols at the time of this writing.

There are approximately 1,000 blockchains in four types: public, private, consortium, and permissioned <ref>https://increditools.com/blockchains/</ref>.

== Cryptographic Proofs ==
Bitcoin 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.

== Centralized vs. Decentralized Applications ==
The Bitcoin protocol enabled decentralized processing of traditionally centrally processed transactions without any trusted third-party. It inspired many decentralized financial applications, especially for applications with very long payment chains. However for fraud prevention and meeting financial regulatory requirements, many practical applications still require KYC (know your customer) checks. It is not possible to eliminate all trusted third parties, especially for custodial financial applications. There is a clear need for decentralized processing of trusted authority applications.

== Blockchain Trilemma ==
Blockchain protocols have three common aspects (goals): '''security''', '''decentralization''' and '''scalability''' -- these three terms do not have precise definitions but are intuitively understood <ref>https://sensoriumxr.com/articles/what-is-the-blockchain-trilemma</ref>. To date, 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.

A major shortcoming is scalability. Since all nodes verify each transaction independently, they need to store all the information required for it. As the chain grows, this burdens all nodes in the network. There are workarounds by limiting the amount of data stored on some nodes and exploiting the network to retrieve required information, such as the ''Limited/Light Nodes'' in Bitcoin network. Vast majority nodes are still full nodes in the existing Bitcoin network. Transaction processing speed often expressed ''as transactions per second(TPS) of'' blockchain have to exceed TPS ratings of credit card payment systems like VISA or MasterCard to reap the full benefits of blockchain. This is a tough problem and increasing the block size and/or reducing the block time or difficulty isn't a solution<ref>https://medium.com/coinmonks/blockchain-scaling-30c9e1b7db1b</ref>. Since blockchain TPS is very low, the transaction fees is often very high. This discourages public adoption. Layer 2 solution like ''Lightning Network'' or ''ZK-rollups,'' where only final settlement is on the main chain tend to address these issues. However, one could always argue that this often compromises some aspects of security and/or decentralization to achieve high TPS.

The trilemma was first introduced by Vitalik Buterin<ref>https://en.wikipedia.org/wiki/Vitalik_Buterin</ref>, one of the co-founders of Ethereum network. The problems he identified are real. There seem to be no obvious solutions that can accomplish all three goals at the same time. Therefore, all proposed solutions revolve around reducing "opportunity costs" focusing only on satisfying partial goals.

Treating the blockchain network as an infrastructure for transaction processing, the blockchain protocol solved service reliability problem but not performance challenge. The legacy infrastructure scaling dilemma: performance against reliability remains (where "infrastructure reliability" also does not have a commonly accepted definition). Fortunately these metrics, although important, are non-critical. Solutions that have been proposed have had varying opportunity costs. For many years, there were no obvious solutions that addressed all three blockchain goals (security, decentralization and scalability).
== Statistic Multiplexed Computing (SMC) ==
The principle of using unreliable components to build an arbitrarily reliable system was first lectured by von Neumann in the early 1950s<ref>https://static.ias.edu/pitp/archive/2012files/Probabilistic_Logics.pdf</ref>. The original idea was to use probabilistic logic to quantify the arbitrary reliability of a system by multiplexing all components. This theory was applied to the construction of Internet protocols to deliver the "best effort" reliability. Incidentally, best effort reliability also enabled "best effort" performance which in turn enabled unlimited scalability of the Internet. For emerging web3.0 technologies, it is important to apply the same methodology to both centralized and decentralized computing for seamless technology migration and integration. For historical arguments, click [[SMC|'''''here''''']].

== Definitions ==
'''Infrastructure scalability''' does not have a commonly accepted definition. It helps to define the challenging metrics more precisely before the infrastructure protocol design. In the following, for definitions #1 and #2, the word "'''infrastructure'''" means any '''application running on the infrastructure.'''

# '''Infrastructure Reliability''': MTBF (mean time between failure) = <math>\frac{\sum ((Start-Of-Downtime) - (Start-of-uptime)) }{No-of-failures}</math>
# '''Infrastructure Performance''': <math>\frac{No-of-Transactions}{Second}</math>
# '''Infrastructure Scalability''': Expanding the infrastructure in number of processors, networks or storage should have '''incrementally better''' impacts on application reliability and performance.
# '''Record Immutability''': For transaction ledgers, all confirmed records and changes are final. This is required by the blockchain protocol.
Note that in practice, record immutability is much harder to achieve than expected. There are two challenges, a) 51% attacks can literally wipe out all histories if successful, and b) for protocols require all nodes to hold independently verified ledger, such as the Bitcoin, the storage requirement grows approximately 50GB per month.

== 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 and considered.

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 crashe'''s <ref>https://groups.csail.mit.edu/tds/papers/Lynch/jacm93.pdf</ref>. The laws of physics regarding component reliability <ref>Encyclopedia of Physical Science and Technology, Editor-in-Chief Robert A. Meyers, [[index.php?title=Special:BookSources/9780122274107|ISBN 978-0-12-227410-7]], 2001</ref> show that '''100% component reliability is not possible.''' These facts require that the infrastructure protocol (program-program communication protocol) provide '''complete component (processing, networking and storage) decoupling''' from application program logics. This decoupling requirement forces the protocol to exploit "decentralized" or "stateless" components that the legacy infrastructure protocols, such as message passing interface (MPI), remote procedure call (RPC) and remote method invocation (RMI), cannot handle. The blockchain protocol is an example of a "best effort" availability protocol.

Quantifying infrastructure reliability can be traced back to the computer pioneer von Neumann. In addition to his contribution to computer architecture, von Neumann also penned a study on building reliable systems using unreliable components using probabilistic logics, in early fifties <ref>https://static.ias.edu/pitp/archive/2012files/Probabilistic_Logics.pdf</ref>. The 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 "best effort" reliability. Ironically, this best effort reliability also enabled the Internet's infinite scalability -- the benefit we enjoy now and into the future.

The Bitcoin protocol exploits multiple anonymous decoupled (or decentralized) computers connected through the Internet protocol. Judging from the Bitcoin network's reliability to date <ref>https://buybitcoinworldwide.com/bitcoin-downtime/</ref>, von Neumann's theory seems working well.

The '''second challenge''' involves infrastructure performance. Since the infrastructure must deploy multiple computing, networking and storage components, unless all components can be fully exploited at 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 lack this capability.

'''The infrastructure scalability challenge''' is automatically resolved once the performance challenge is resolved without negatively impacting reliability -- "best effort" performance" meets "best effort reliability". This requires inductive performance and reliability measures or deliveries.

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, an inductive statistic multiplexed blockchain protocol is needed to meet the scalability challenge. Non-inductive solutions such as fixed chain "sharding" or "Danksharding" <ref>https://ethereum.org/en/roadmap/danksharding/</ref> will only increase protocol development complexity with persistent performance walls.

== A Scalability Solution ==
An effective scalability solution can have two practical assumptions:

* The computation problem size can expand indefinitely, since every useful infrastructure is expected to solve bigger problems.

*Computing and network resources will continue to grow indefinitely, into the future.
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 <ref>https://en.wikipedia.org/wiki/Amdahl%27s_law</ref> and Gustafson's Law <ref>https://en.wikipedia.org/wiki/Gustafson%27s_law</ref>.

The Amdahl's Law assumes 0<= ''s'' <=1 percentage of serial instructions that cannot be parallelized. Then the ''(1-s)'' percentage of instructions can be accelerated using ''p'' processors.

<div style="text-align: center;">
Speedup(p) = <math>{1 \over s + {(1-s) \over p}}</math> (1) <br>Speedup(<math>\lim_{p \to \infty}</math>) = <math>\frac{1}{s}</math> (2)
</div>
Taking ''p'' to infinity in equation (1) yields equation (2). But this derivation step has two different operational semantics: a) increasing ''p'' to reduce (''1-s)'' value while keeping the problem size fixed. This will result ''s'' asymptotically approaching 1. Thus the speedup is above founded to 1. Or b) increasing p to increase the parallel percentage ''(1-s)'' by solving bigger problems. This will force ''s'' asymptotically approach 0. Then the speedup is above bounded by <math>\infty</math>. This ambiguity caused more than three decades of confusion in the community.

Although quantifying ''s'' requires additional information, such as the problem size, the law is applicable to programs solving any problem size with a known ''s''. The limit of speedup (2) also does not depend on problem size. However, since Amdahl used programs solving fixed problem sizes to argue the validity of not building parallel machines with too many processors, assuming fixed problem size using ''p'' processors has been the norm in interpreting Amdahl's law in the past. This assumption has led to the dismal speedup predictions.[[File:Amdahl's Law.png|thumb|Amdahl's Law Speedup Predictions|center]]The traditional Amdahl's Law interpretation seems to suggest parallel performances following the economic law of diminishing of returns, even though the mathematic model implies more potentials.

In 1988, Gustafson and Barsis at the Sandia National Laboratory conducted parallel computing experiments that seem to suggest potential infinite speedup.

Gustafson's Law was based on measured sequential and parallel elapsed times using ''p'' (=1024) processors. A new sequential percentage ''0<=x'<=1'' can be calculated. ''(1-x')'' is the parallel percentage using ''p'' processors.

To estimate accomplished speedup, Gustafson's Law states:

<div style="text-align: center;">
<math>Speedup=\frac{Tseq}{Tpar}=\frac{s'+(1-s')p}{1}=s'+(1-s')p </math> (3)
</div>

Take ''p'' -> <math>\infty</math> for equation (3) also has two operational semantics: a) Keep the problem size fixed, adding processors to further reduce the total parallel processing time, thus bigger s'. This will yield s' approaching 1. Thus speedup is above bounded to 1. Or b) expanding the problem size to allow the parallel part expanded solving bigger problems. This will yield s' asymptotically approaching 0. Speedup will be above bounded to ''p''. However, Gustafson's Law was used to argue for Massively Parallel Computing (MPC) (or ManyCPU) experiments and Amdahl's Law was used to argue for bigger mainframe (or BigCPU) computer architectures. In the past decades, these laws have been used to support two diverging computing system experiments and constructions until recently.
[[File:Gustafson.png|thumb|Gustafson's Law|center]]
It is now obvious that the two law are identical with Amdahl's Law more succinct. But Gustafson's formula helps to quantify the serial percentages from practical program executions. In fact, the two serial percentages can be related by a simple equation<ref>https://www.researchgate.net/publication/228367369_Reevaluating_Amdahl's_law_and_Gustafson's_law</ref>:

<div style="text-align: center;">
<math>s=\frac{s'}{s'+(1-s')p}</math> (4)
</div>

Both law actually refer to the same mathematical abstraction. Gustafson's formula assisted in quantifying the percentage of serial computing through program experiments. Neither should be directly used for speedup prediction alone.

This model can be validated in practice when developers simply increasing the problem size to use more parallel processors.

[[File:Full Range Amdah's Law .png|alt=Full Power of Amdahl's Law|center|thumb|Full Power of Amdahl's Law]]

A classical example is the TOP500 supercomputer benchmarks (linear solvers) that have open problem sizes for all manufacturers to compete in the world's fastest supercomputer race <ref>https://www.top500.org/</ref> .
[[File:Supercomputers-history.png|center|thumb]]
In practical blockchain applications, the number of transactions to be processed will increase without a known limit. The ledger storage will continue to grow. In practice, the available computing, networking and storage components will continue to grow without limits enabled by the networking protocols. Therefore a statistic multiplexed computing blockchain can meet any future application needs given proper economic incentives. The infrastructure no longer has the structural deficiency.

== Action Plan ==

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.

For Toichain protocol design, we choose Bitcoin 24.0.1 as the base line protocol by replacing the PoW consensus by PoS consensus and injecting SMC components into the protocol processing signaling for parallel computing.

This surprising result is also applicable to ledger storage. Without multiplexing, the blockchain ledger storage will eventually saturate all nodes causing the chain to collapse. The SMC blockchain protocol promises to hold the true finality of all transactions in perpetuity by multiplexing all storage resources while keeping the replication factor to a constant.

These discussions follow the inductive logic of the Law of Large Numbers <ref>https://www.sciencedirect.com/topics/mathematics/laws-of-large-number</ref>.

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

= SMC Proof of Stake Protocol =
Existing PoS protocol designs revolved around staking policies and randomness of the selection algorithm. Considering infrastructure scalability will add much complexity to the design. The examples include chain sharding and Danksharding <ref>https://ethereum.org/en/roadmap/danksharding/</ref>.

The challenge is complex -- we must deliver very high performance without compromising security and reliability of the network.

Technically, transaction replication and parallel processing were considered dangerous <ref>https://pages.cs.wisc.edu/~yxy/cs764-f20/papers/replication.pdf</ref> due to the potential race conditions (or double-spend problem). The blockchain protocol resolved the double-spending problem. It did not solve the parallel processing performance problem.

According to Professor Michael Flynn, there are three high-level parallel processing topologies: SIMD (single instruction multiple data), MIMD (multiple instructions multiple data), and pipeline (MISD - multiple instructions single data stream) <ref>https://link.springer.com/referenceworkentry/10.1007/978-0-387-09766-4_2</ref>. However, for eliminating double-spending, all transactions must be serialized, since each block may contain transactions affecting transactions in multiple other blocks. "Race conditions" and non-deterministic results are not allowed. Then the only possible topology entry is pipeline. This means for POS protocol, we must build a pipeline of transaction blocks to be validated without compromising network security and reliability.
[[File:Flynns-Taxonomy-of-Computer-Architectures.png|center|thumb|Parallel Processing Topologies]]
The problem is that the nature of the blockchain protocol is that all nodes run independently in parallel with little communication with other nodes via "gossip" protocols. It is far easier to force all nodes store the entire ledger than forcing them to form any pipeline and store partial chain data.

=== ACAN (Active Content Addressable Network) [U.S. PTO #11,588,926 B2] ===
ACAN is a high-level data '''''communication and synchronization protocol''''' that completely decouples all hardware components from communicating programs. The need for complete component decoupling was implemented in the original blockchain protocol via "gossip" protocol. This delivered blockchain's high availability and security. The simple "gossip" implementation in existing protocols is insufficient for parallel processing signaling.

The following figure illustrates the concept of ACAN (active content addressable networking) using UVR (unidirectional virtual ring) architecture. The illustrated implementation uses the Tuple Space resource tagging method and gossip protocol for UVR implementation.
[[File:SMC Architecture with ACAN.png|center|thumb|243x243px|SMC Architecture with ACAN]]

ACAN supports three simple APIs:

# '''read'''(&''key'', &''value''): ''key'' holds a search pattern in a "tuple space" where all nodes are connected. ''value'' holds the matched tuple, if any. This is a blocking call that a requesting program will be blocked until a pattern-matched tuple is found. The matching tuple remains in the "tuple space".
# '''get'''(&key, &value): Same as the "read()" API, except that the matching tuple is removed from the "tuple space".
# '''put'''(key, value): Inserts <key, value> into the "tuple space".

The use of "gossip" protocol can accelerate ACAN network saturation time. Applications running on ACAN will automatically form parallel processing topologies: pipeline, SIMD and MIMD without violating the serialization needs of transaction block validation. Replication factor can also be dynamically controlled to spread replicated blocks in randomly chosen hosts.

The highly parallel nature of the blockchain protocol will automatically implement the SMC principle in real time.

The critical feature of this dynamic SMC pipelined architecture is the inductive scaling feature.
[[File:Pipeline Parallel Processing.png|center|thumb|247x247px|Pipeline Parallel Processing]]

The speed up of a pipeline can be represented as: <math>SpeedUp = \left ( \frac{p\centerdot b}{p + (b-1)} \right )</math>, where p = number of processors in the pipeline, b = total blocks to be processed. Take the number of blocks to infinity:

<math>SpeedUp = \left ( \frac{p\centerdot b}{p + (b-1)} \right )=>\lim (b\Rightarrow\infty)(\frac{p}{\frac{p}{b}+1-\frac{1}{b}}) = p</math>

This means that as long as there are enough blocks to be processed, the entire chain's performance will be abound-bounded to the number of nodes in the pipeline.

For illustration purposes, the variation of block processing times was not considered in the above calculations. To see the power of pipeline parallelism, the automobile manufacturing processes illustrate a similar situation. The Hyundai Motor Company's production pipelines can produce 3,835 vehicles per day and 1.4M per year<ref>https://en.wikipedia.org/wiki/List_of_Hyundai_Motor_Company_manufacturing_facilities</ref>.

== Toichain Tokens ==
Toichain token is TOIN. There are 50,000,000,000 TOINs for the Alpha Release. There are air-drop tokens for early adopters, 1,000 TOIN each. Users need to register to download a toichain wallet to receive the payment. Citizenship is checked and verified to ensure that US citizens do not apply. The minimal staking contract is 10 TOINs.

== Non-Fungible Tokens ==
The TestNet Release of toichain protocol will support embedding arbitrary data in an "OP_RETURN" transaction that will be permanently recorded on the chain. Unlike the ordinal NFT <ref>https://blog.chain.link/ordinals-bitcoin-nfts/</ref> or NFT (non-fungible token) on other chains, these transactions cannot be altered or removed.

There are practical applications for these forever NFTs. Once Taproot is enabled on toichain, ordinal NFTs (BRC-20) will also be supported. Unlike the original Bitcoin network where BRC-20 craze has created massive network congestion<ref>https://beincrypto.com/learn/brc-20-token/</ref>, all transactions will be processed promptly in toichain without congestion or scaling problems.
== Toichain TestNet Launch ==
The toichain testnet launch will enable users to interact with one another through simple payments, just like the original Bitcoin network. Forever NFTs are supported. Smart contracts will be supported on a later date.

= References =
<references />

Consult the [[mediawikiwiki:Special:MyLanguage/Help:Contents|User's Guide]] for information on using the wiki software.

Main Page

2024-10-12T22:19:28Z

Justin: /* ACAN (Active Content Addressable Network) [U.S. and Other Patents Pending] */

= <strong><big>'''Welcome to Toi-Twiki -- A Toichain Wiki'''</big></strong> =
This is the unofficial Toichain wiki site. Content is subject to changes.
---------------------------

= '''Introduction''' =
The blockchain protocol was introduced in a seminal paper entitled "Bitcoin: A peer-to-peer Electronic Cash System" <ref>https://bitcoin.org/bitcoin.pdf</ref> by Satoshi Nakamoto in 2008. Although there were previous peer-to-peer file-sharing projects such as Napster <ref>https://www.napster.com/us</ref>, BitTorrent <ref>https://www.bittorrent.com/</ref> and other electronic currency/file sharing applications, Bitcoin is the most enduring among the 23,000+ blockchains. Unlike other cryptocurrencies, the Bitcoin is often referred to as "digital gold" since the total coin supply is limited to 21 million (hard-coded in all running programs) and the only way to earn coin is to participate in the transaction block validation process. Token(or coin) supply and their disbursement policies differ among protocols.

The most attractive common blockchain features are 1) a decentralized consensus-driven decision making process and 2) a step-by-step cryptographic proving system. While blockchain is best known as a cryptocurrency transaction processing and record-keeping system, there are many other applications that can benefit from the secure storage, reliable transaction ledgers, fault tolerance and tamper resistance features.

== Algorithm vs. Protocol ==
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 ==
A good consensus protocol in a blockchain system has at least four properties:

# Fault tolerance to defend failures caused by natural disasters and human hacks or accidents
# Byzantine failure tolerance to defend exploitation by colluding parties
# Centralization avoidance to prevent corruptions in the decision making process
# Source code tamper resistance to automatically reject malicious attacks

Without assuming all nodes are active at all times, the blockchain relies on "gossip" protocol to communicate with other nodes. There are two popular types of consensus protocols: Proof of Work ('''PoW''') <ref>https://en.wikipedia.org/wiki/Proof_of_work</ref> or Proof of Stake ('''PoS''') <ref>https://www.investopedia.com/terms/p/proof-stake-pos.asp</ref>. Others include Proof of Possession('''PoP''')<ref>https://identityserver4.readthedocs.io/en/latest/topics/pop.html</ref> and Proof of History('''PoH''')<ref>https://www.infoworld.com/article/3666736/solana-blockchain-and-the-proof-of-history.html</ref>. The ultimate goal is to eliminate double-spending. Since most projects are open source, it's easy for a malicious actor to tamper a few nodes. This shouldn't compromise network integrity.

The Bitcoin network uses PoW which forces participating miners to compete for the fastest hashing rate by solving a computational cryptographic puzzle. Although it withstood more than 14 years of use, Bitcoin has been criticized for escalating electricity consumption <ref>https://www.forbes.com/advisor/investing/cryptocurrency/bitcoins-energy-usage-explained/</ref>. Other blockchain designs have experienced different challenges. For example, the PoH network Solana suffered multiple single-point-failure incidents <ref>https://messari.io/report/solana-analyzing-downtimes-statistics-and-ecosystem-development</ref>. All protocols struggle to combat scaling challenges. All are susceptible to 51% attacks <ref>https://originstamp.com/blog/has-there-ever-been-a-51-attack-on-bitcoin/#notable-51-attacks</ref>.

Since 2009, Bitcoin has proven to be the strongest and least susceptible to common hacks <ref>https://www.theguardian.com/technology/2014/mar/18/history-of-bitcoin-hacks-alternative-currency</ref>. As the PoW puzzle difficulty has increased dramatically over the years, the probability of a 51% attack on the Bitcoin network becomes more difficult. PoS protocols can save more than 90% energy consumption compared to PoW chains. But PoS chains have higher risks than PoW chains since a stolen coin will grow in PoS chains (for increased probability to be selected) forever but not in PoW chains (only hash rates count). PoS community governance rules can mitigate the voting power centralization problem. Staking and slashing policies can incentivize good behaviors and punish bad ones. In either case, double-spend is very expensive and difficult. According to Forbes, there are 80 cryptocurrencies that use PoS protocols at the time of this writing.

There are approximately 1,000 blockchains in four types: public, private, consortium, and permissioned <ref>https://increditools.com/blockchains/</ref>.

== Cryptographic Proofs ==
Bitcoin 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.

== Centralized vs. Decentralized Applications ==
The Bitcoin protocol enabled decentralized processing of traditionally centrally processed transactions without any trusted third-party. It inspired many decentralized financial applications, especially for applications with very long payment chains. However for fraud prevention and meeting financial regulatory requirements, many practical applications still require KYC (know your customer) checks. It is not possible to eliminate all trusted third parties, especially for custodial financial applications. There is a clear need for decentralized processing of trusted authority applications.

== Blockchain Trilemma ==
Blockchain protocols have three common aspects (goals): '''security''', '''decentralization''' and '''scalability''' -- these three terms do not have precise definitions but are intuitively understood <ref>https://sensoriumxr.com/articles/what-is-the-blockchain-trilemma</ref>. To date, 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.

A major shortcoming is scalability. Since all nodes verify each transaction independently, they need to store all the information required for it. As the chain grows, this burdens all nodes in the network. There are workarounds by limiting the amount of data stored on some nodes and exploiting the network to retrieve required information, such as the ''Limited/Light Nodes'' in Bitcoin network. Vast majority nodes are still full nodes in the existing Bitcoin network. Transaction processing speed often expressed ''as transactions per second(TPS) of'' blockchain have to exceed TPS ratings of credit card payment systems like VISA or MasterCard to reap the full benefits of blockchain. This is a tough problem and increasing the block size and/or reducing the block time or difficulty isn't a solution<ref>https://medium.com/coinmonks/blockchain-scaling-30c9e1b7db1b</ref>. Since blockchain TPS is very low, the transaction fees is often very high. This discourages public adoption. Layer 2 solution like ''Lightning Network'' or ''ZK-rollups,'' where only final settlement is on the main chain tend to address these issues. However, one could always argue that this often compromises some aspects of security and/or decentralization to achieve high TPS.

The trilemma was first introduced by Vitalik Buterin<ref>https://en.wikipedia.org/wiki/Vitalik_Buterin</ref>, one of the co-founders of Ethereum network. The problems he identified are real. There seem to be no obvious solutions that can accomplish all three goals at the same time. Therefore, all proposed solutions revolve around reducing "opportunity costs" focusing only on satisfying partial goals.

Treating the blockchain network as an infrastructure for transaction processing, the blockchain protocol solved service reliability problem but not performance challenge. The legacy infrastructure scaling dilemma: performance against reliability remains (where "infrastructure reliability" also does not have a commonly accepted definition). Fortunately these metrics, although important, are non-critical. Solutions that have been proposed have had varying opportunity costs. For many years, there were no obvious solutions that addressed all three blockchain goals (security, decentralization and scalability).
== Statistic Multiplexed Computing (SMC) ==
The principle of using unreliable components to build an arbitrarily reliable system was first lectured by von Neumann in the early 1950s<ref>https://static.ias.edu/pitp/archive/2012files/Probabilistic_Logics.pdf</ref>. The original idea was to use probabilistic logic to quantify the arbitrary reliability of a system by multiplexing all components. This theory was applied to the construction of Internet protocols to deliver the "best effort" reliability. Incidentally, best effort reliability also enabled "best effort" performance which in turn enabled unlimited scalability of the Internet. For emerging web3.0 technologies, it is important to apply the same methodology to both centralized and decentralized computing for seamless technology migration and integration. For historical arguments, click [[SMC|'''''here''''']].

== Definitions ==
'''Infrastructure scalability''' does not have a commonly accepted definition. It helps to define the challenging metrics more precisely before the infrastructure protocol design. In the following, for definitions #1 and #2, the word "'''infrastructure'''" means any '''application running on the infrastructure.'''

# '''Infrastructure Reliability''': MTBF (mean time between failure) = <math>\frac{\sum ((Start-Of-Downtime) - (Start-of-uptime)) }{No-of-failures}</math>
# '''Infrastructure Performance''': <math>\frac{No-of-Transactions}{Second}</math>
# '''Infrastructure Scalability''': Expanding the infrastructure in number of processors, networks or storage should have '''incrementally better''' impacts on application reliability and performance.
# '''Record Immutability''': For transaction ledgers, all confirmed records and changes are final. This is required by the blockchain protocol.
Note that in practice, record immutability is much harder to achieve than expected. There are two challenges, a) 51% attacks can literally wipe out all histories if successful, and b) for protocols require all nodes to hold independently verified ledger, such as the Bitcoin, the storage requirement grows approximately 50GB per month.

== 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 and considered.

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 crashe'''s <ref>https://groups.csail.mit.edu/tds/papers/Lynch/jacm93.pdf</ref>. The laws of physics regarding component reliability <ref>Encyclopedia of Physical Science and Technology, Editor-in-Chief Robert A. Meyers, [[index.php?title=Special:BookSources/9780122274107|ISBN 978-0-12-227410-7]], 2001</ref> show that '''100% component reliability is not possible.''' These facts require that the infrastructure protocol (program-program communication protocol) provide '''complete component (processing, networking and storage) decoupling''' from application program logics. This decoupling requirement forces the protocol to exploit "decentralized" or "stateless" components that the legacy infrastructure protocols, such as message passing interface (MPI), remote procedure call (RPC) and remote method invocation (RMI), cannot handle. The blockchain protocol is an example of a "best effort" availability protocol.

Quantifying infrastructure reliability can be traced back to the computer pioneer von Neumann. In addition to his contribution to computer architecture, von Neumann also penned a study on building reliable systems using unreliable components using probabilistic logics, in early fifties <ref>https://static.ias.edu/pitp/archive/2012files/Probabilistic_Logics.pdf</ref>. The 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 "best effort" reliability. Ironically, this best effort reliability also enabled the Internet's infinite scalability -- the benefit we enjoy now and into the future.

The Bitcoin protocol exploits multiple anonymous decoupled (or decentralized) computers connected through the Internet protocol. Judging from the Bitcoin network's reliability to date <ref>https://buybitcoinworldwide.com/bitcoin-downtime/</ref>, von Neumann's theory seems working well.

The '''second challenge''' involves infrastructure performance. Since the infrastructure must deploy multiple computing, networking and storage components, unless all components can be fully exploited at 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 lack this capability.

'''The infrastructure scalability challenge''' is automatically resolved once the performance challenge is resolved without negatively impacting reliability -- "best effort" performance" meets "best effort reliability". This requires inductive performance and reliability measures or deliveries.

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, an inductive statistic multiplexed blockchain protocol is needed to meet the scalability challenge. Non-inductive solutions such as fixed chain "sharding" or "Danksharding" <ref>https://ethereum.org/en/roadmap/danksharding/</ref> will only increase protocol development complexity with persistent performance walls.

== A Scalability Solution ==
An effective scalability solution can have two practical assumptions:

* The computation problem size can expand indefinitely, since every useful infrastructure is expected to solve bigger problems.

*Computing and network resources will continue to grow indefinitely, into the future.
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 <ref>https://en.wikipedia.org/wiki/Amdahl%27s_law</ref> and Gustafson's Law <ref>https://en.wikipedia.org/wiki/Gustafson%27s_law</ref>.

The Amdahl's Law assumes 0<= ''s'' <=1 percentage of serial instructions that cannot be parallelized. Then the ''(1-s)'' percentage of instructions can be accelerated using ''p'' processors.

<div style="text-align: center;">
Speedup(p) = <math>{1 \over s + {(1-s) \over p}}</math> (1) <br>Speedup(<math>\lim_{p \to \infty}</math>) = <math>\frac{1}{s}</math> (2)
</div>
Taking ''p'' to infinity in equation (1) yields equation (2). But this derivation step has two different operational semantics: a) increasing ''p'' to reduce (''1-s)'' value while keeping the problem size fixed. This will result ''s'' asymptotically approaching 1. Thus the speedup is above founded to 1. Or b) increasing p to increase the parallel percentage ''(1-s)'' by solving bigger problems. This will force ''s'' asymptotically approach 0. Then the speedup is above bounded by <math>\infty</math>. This ambiguity caused more than three decades of confusion in the community.

Although quantifying ''s'' requires additional information, such as the problem size, the law is applicable to programs solving any problem size with a known ''s''. The limit of speedup (2) also does not depend on problem size. However, since Amdahl used programs solving fixed problem sizes to argue the validity of not building parallel machines with too many processors, assuming fixed problem size using ''p'' processors has been the norm in interpreting Amdahl's law in the past. This assumption has led to the dismal speedup predictions.[[File:Amdahl's Law.png|thumb|Amdahl's Law Speedup Predictions|center]]The traditional Amdahl's Law interpretation seems to suggest parallel performances following the economic law of diminishing of returns, even though the mathematic model implies more potentials.

In 1988, Gustafson and Barsis at the Sandia National Laboratory conducted parallel computing experiments that seem to suggest potential infinite speedup.

Gustafson's Law was based on measured sequential and parallel elapsed times using ''p'' (=1024) processors. A new sequential percentage ''0<=x'<=1'' can be calculated. ''(1-x')'' is the parallel percentage using ''p'' processors.

To estimate accomplished speedup, Gustafson's Law states:

<div style="text-align: center;">
<math>Speedup=\frac{Tseq}{Tpar}=\frac{s'+(1-s')p}{1}=s'+(1-s')p </math> (3)
</div>

Take ''p'' -> <math>\infty</math> for equation (3) also has two operational semantics: a) Keep the problem size fixed, adding processors to further reduce the total parallel processing time, thus bigger s'. This will yield s' approaching 1. Thus speedup is above bounded to 1. Or b) expanding the problem size to allow the parallel part expanded solving bigger problems. This will yield s' asymptotically approaching 0. Speedup will be above bounded to ''p''. However, Gustafson's Law was used to argue for Massively Parallel Computing (MPC) (or ManyCPU) experiments and Amdahl's Law was used to argue for bigger mainframe (or BigCPU) computer architectures. In the past decades, these laws have been used to support two diverging computing system experiments and constructions until recently.
[[File:Gustafson.png|thumb|Gustafson's Law|center]]
It is now obvious that the two law are identical with Amdahl's Law more succinct. But Gustafson's formula helps to quantify the serial percentages from practical program executions. In fact, the two serial percentages can be related by a simple equation:

<div style="text-align: center;">
<math>s=\frac{s'}{s'+(1-s')p}</math> (4)
</div>

Both law actually refer to the same mathematical abstraction. Gustafson's formula assisted in quantifying the percentage of serial computing through program experiments. Neither should be directly used for speedup prediction alone.

This model can be validated in practice when developers simply increasing the problem size to use more parallel processors.

[[File:Full Range Amdah's Law .png|alt=Full Power of Amdahl's Law|center|thumb|Full Power of Amdahl's Law]]

A classical example is the TOP500 supercomputer benchmarks (linear solvers) that have open problem sizes for all manufacturers to compete in the world's fastest supercomputer race <ref>https://www.top500.org/</ref> .
[[File:Supercomputers-history.png|center|thumb]]
In practical blockchain applications, the number of transactions to be processed will increase without a known limit. The ledger storage will continue to grow. In practice, the available computing, networking and storage components will continue to grow without limits enabled by the networking protocols. Therefore a statistic multiplexed computing blockchain can meet any future application needs given proper economic incentives. The infrastructure no longer has the structural deficiency.

== Action Plan ==

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.

For Toichain protocol design, we choose Bitcoin 24.0.1 as the base line protocol by replacing the PoW consensus by PoS consensus and injecting SMC components into the protocol processing signaling for parallel computing.

This surprising result is also applicable to ledger storage. Without multiplexing, the blockchain ledger storage will eventually saturate all nodes causing the chain to collapse. The SMC blockchain protocol promises to hold the true finality of all transactions in perpetuity by multiplexing all storage resources while keeping the replication factor to a constant.

These discussions follow the inductive logic of the Law of Large Numbers <ref>https://www.sciencedirect.com/topics/mathematics/laws-of-large-number</ref>.

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

= SMC Proof of Stake Protocol =
Existing PoS protocol designs revolved around staking policies and randomness of the selection algorithm. Considering infrastructure scalability will add much complexity to the design. The examples include chain sharding and Danksharding <ref>https://ethereum.org/en/roadmap/danksharding/</ref>.

The challenge is complex -- we must deliver very high performance without compromising security and reliability of the network.

Technically, transaction replication and parallel processing were considered dangerous <ref>https://pages.cs.wisc.edu/~yxy/cs764-f20/papers/replication.pdf</ref> due to the potential race conditions (or double-spend problem). The blockchain protocol resolved the double-spending problem. It did not solve the parallel processing performance problem.

According to Professor Michael Flynn, there are three high-level parallel processing topologies: SIMD (single instruction multiple data), MIMD (multiple instructions multiple data), and pipeline (MISD - multiple instructions single data stream) <ref>https://link.springer.com/referenceworkentry/10.1007/978-0-387-09766-4_2</ref>. However, for eliminating double-spending, all transactions must be serialized, since each block may contain transactions affecting transactions in multiple other blocks. "Race conditions" and non-deterministic results are not allowed. Then the only possible topology entry is pipeline. This means for POS protocol, we must build a pipeline of transaction blocks to be validated without compromising network security and reliability.
[[File:Flynns-Taxonomy-of-Computer-Architectures.png|center|thumb|Parallel Processing Topologies]]
The problem is that the nature of the blockchain protocol is that all nodes run independently in parallel with little communication with other nodes via "gossip" protocols. It is far easier to force all nodes store the entire ledger than forcing them to form any pipeline and store partial chain data.

=== ACAN (Active Content Addressable Network) [U.S. and Other Patents Pending] ===
ACAN is a high-level data '''''communication and synchronization protocol''''' that completely decouples all hardware components from communicating programs. The need for complete component decoupling was implemented in the original blockchain protocol via "gossip" protocol. This delivered blockchain's high availability and security. The simple "gossip" implementation in existing protocols is insufficient for parallel processing signaling.

The following figure illustrates the concept of ACAN (active content addressable networking) using UVR (unidirectional virtual ring) architecture. The illustrated implementation uses the Tuple Space resource tagging method and gossip protocol for UVR implementation.
[[File:SMC Architecture with ACAN.png|center|thumb|243x243px|SMC Architecture with ACAN]]

ACAN supports three simple APIs:

# '''read'''(&''key'', &''value''): ''key'' holds a search pattern in a "tuple space" where all nodes are connected. ''value'' holds the matched tuple, if any. This is a blocking call that a requesting program will be blocked until a pattern-matched tuple is found. The matching tuple remains in the "tuple space".
# '''get'''(&key, &value): Same as the "read()" API, except that the matching tuple is removed from the "tuple space".
# '''put'''(key, value): Inserts <key, value> into the "tuple space".

The use of "gossip" protocol can accelerate ACAN network saturation time. Applications running on ACAN will automatically form parallel processing topologies: pipeline, SIMD and MIMD without violating the serialization needs of transaction block validation. Replication factor can also be dynamically controlled to spread replicated blocks in randomly chosen hosts.

The highly parallel nature of the blockchain protocol will automatically implement the SMC principle in real time.

The critical feature of this dynamic SMC pipelined architecture is the inductive scaling feature.
[[File:Pipeline Parallel Processing.png|center|thumb|247x247px|Pipeline Parallel Processing]]

The speed up of a pipeline can be represented as: <math>SpeedUp = \left ( \frac{p\centerdot b}{p + (b-1)} \right )</math>, where p = number of processors in the pipeline, b = total blocks to be processed. Take the number of blocks to infinity: <math>SpeedUp = \left ( \frac{p\centerdot b}{p + (b-1)} \right )=>\lim (b\Rightarrow\infty)(\frac{p}{\frac{p}{b}+1-\frac{1}{b}}) = p</math>

This means that as long as there are enough blocks to be processed, the entire chain's performance will be abound-bounded to the number of nodes in the pipeline.

For illustration purposes, the variation of block processing times was not considered in the above calculations. To see the power of pipeline parallelism, the automobile manufacturing processes illustrate a similar situation. The Hyundai Motor Company's production pipelines can produce 3,835 vehicles per day and 1.4M per year<ref>https://en.wikipedia.org/wiki/List_of_Hyundai_Motor_Company_manufacturing_facilities</ref>.

== Toichain Tokens ==
Toichain token is TOIN. There are 50,000,000,000 TOINs for the Alpha Release. There are air-drop tokens for early adopters, 1,000 TOIN each. Users need to register to download a toichain wallet to receive the payment. Citizenship is checked and verified to ensure that US citizens do not apply. The minimal staking contract is 10 TOINs.

== Non-Fungible Tokens ==
The TestNet Release of toichain protocol will support embedding arbitrary data in an "OP_RETURN" transaction that will be permanently recorded on the chain. Unlike the ordinal NFT <ref>https://blog.chain.link/ordinals-bitcoin-nfts/</ref> or NFT (non-fungible token) on other chains, these transactions cannot be altered or removed.

There are practical applications for these forever NFTs. Once Taproot is enabled on toichain, ordinal NFTs (BRC-20) will also be supported. Unlike the original Bitcoin network where BRC-20 craze has created massive network congestion<ref>https://beincrypto.com/learn/brc-20-token/</ref>, all transactions will be processed promptly in toichain without congestion or scaling problems.
== Toichain TestNet Launch ==
The toichain testnet launch will enable users to interact with one another through simple payments, just like the original Bitcoin network. Forever NFTs are supported. Smart contracts will be supported on a later date.

= References =
<references />

Consult the [[mediawikiwiki:Special:MyLanguage/Help:Contents|User's Guide]] for information on using the wiki software.

Main Page

2024-10-12T22:14:08Z

Justin: /* A Scalability Solution */

= <strong><big>'''Welcome to Toi-Twiki -- A Toichain Wiki'''</big></strong> =
This is the unofficial Toichain wiki site. Content is subject to changes.
---------------------------

= '''Introduction''' =
The blockchain protocol was introduced in a seminal paper entitled "Bitcoin: A peer-to-peer Electronic Cash System" <ref>https://bitcoin.org/bitcoin.pdf</ref> by Satoshi Nakamoto in 2008. Although there were previous peer-to-peer file-sharing projects such as Napster <ref>https://www.napster.com/us</ref>, BitTorrent <ref>https://www.bittorrent.com/</ref> and other electronic currency/file sharing applications, Bitcoin is the most enduring among the 23,000+ blockchains. Unlike other cryptocurrencies, the Bitcoin is often referred to as "digital gold" since the total coin supply is limited to 21 million (hard-coded in all running programs) and the only way to earn coin is to participate in the transaction block validation process. Token(or coin) supply and their disbursement policies differ among protocols.

The most attractive common blockchain features are 1) a decentralized consensus-driven decision making process and 2) a step-by-step cryptographic proving system. While blockchain is best known as a cryptocurrency transaction processing and record-keeping system, there are many other applications that can benefit from the secure storage, reliable transaction ledgers, fault tolerance and tamper resistance features.

== Algorithm vs. Protocol ==
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 ==
A good consensus protocol in a blockchain system has at least four properties:

# Fault tolerance to defend failures caused by natural disasters and human hacks or accidents
# Byzantine failure tolerance to defend exploitation by colluding parties
# Centralization avoidance to prevent corruptions in the decision making process
# Source code tamper resistance to automatically reject malicious attacks

Without assuming all nodes are active at all times, the blockchain relies on "gossip" protocol to communicate with other nodes. There are two popular types of consensus protocols: Proof of Work ('''PoW''') <ref>https://en.wikipedia.org/wiki/Proof_of_work</ref> or Proof of Stake ('''PoS''') <ref>https://www.investopedia.com/terms/p/proof-stake-pos.asp</ref>. Others include Proof of Possession('''PoP''')<ref>https://identityserver4.readthedocs.io/en/latest/topics/pop.html</ref> and Proof of History('''PoH''')<ref>https://www.infoworld.com/article/3666736/solana-blockchain-and-the-proof-of-history.html</ref>. The ultimate goal is to eliminate double-spending. Since most projects are open source, it's easy for a malicious actor to tamper a few nodes. This shouldn't compromise network integrity.

The Bitcoin network uses PoW which forces participating miners to compete for the fastest hashing rate by solving a computational cryptographic puzzle. Although it withstood more than 14 years of use, Bitcoin has been criticized for escalating electricity consumption <ref>https://www.forbes.com/advisor/investing/cryptocurrency/bitcoins-energy-usage-explained/</ref>. Other blockchain designs have experienced different challenges. For example, the PoH network Solana suffered multiple single-point-failure incidents <ref>https://messari.io/report/solana-analyzing-downtimes-statistics-and-ecosystem-development</ref>. All protocols struggle to combat scaling challenges. All are susceptible to 51% attacks <ref>https://originstamp.com/blog/has-there-ever-been-a-51-attack-on-bitcoin/#notable-51-attacks</ref>.

Since 2009, Bitcoin has proven to be the strongest and least susceptible to common hacks <ref>https://www.theguardian.com/technology/2014/mar/18/history-of-bitcoin-hacks-alternative-currency</ref>. As the PoW puzzle difficulty has increased dramatically over the years, the probability of a 51% attack on the Bitcoin network becomes more difficult. PoS protocols can save more than 90% energy consumption compared to PoW chains. But PoS chains have higher risks than PoW chains since a stolen coin will grow in PoS chains (for increased probability to be selected) forever but not in PoW chains (only hash rates count). PoS community governance rules can mitigate the voting power centralization problem. Staking and slashing policies can incentivize good behaviors and punish bad ones. In either case, double-spend is very expensive and difficult. According to Forbes, there are 80 cryptocurrencies that use PoS protocols at the time of this writing.

There are approximately 1,000 blockchains in four types: public, private, consortium, and permissioned <ref>https://increditools.com/blockchains/</ref>.

== Cryptographic Proofs ==
Bitcoin 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.

== Centralized vs. Decentralized Applications ==
The Bitcoin protocol enabled decentralized processing of traditionally centrally processed transactions without any trusted third-party. It inspired many decentralized financial applications, especially for applications with very long payment chains. However for fraud prevention and meeting financial regulatory requirements, many practical applications still require KYC (know your customer) checks. It is not possible to eliminate all trusted third parties, especially for custodial financial applications. There is a clear need for decentralized processing of trusted authority applications.

== Blockchain Trilemma ==
Blockchain protocols have three common aspects (goals): '''security''', '''decentralization''' and '''scalability''' -- these three terms do not have precise definitions but are intuitively understood <ref>https://sensoriumxr.com/articles/what-is-the-blockchain-trilemma</ref>. To date, 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.

A major shortcoming is scalability. Since all nodes verify each transaction independently, they need to store all the information required for it. As the chain grows, this burdens all nodes in the network. There are workarounds by limiting the amount of data stored on some nodes and exploiting the network to retrieve required information, such as the ''Limited/Light Nodes'' in Bitcoin network. Vast majority nodes are still full nodes in the existing Bitcoin network. Transaction processing speed often expressed ''as transactions per second(TPS) of'' blockchain have to exceed TPS ratings of credit card payment systems like VISA or MasterCard to reap the full benefits of blockchain. This is a tough problem and increasing the block size and/or reducing the block time or difficulty isn't a solution<ref>https://medium.com/coinmonks/blockchain-scaling-30c9e1b7db1b</ref>. Since blockchain TPS is very low, the transaction fees is often very high. This discourages public adoption. Layer 2 solution like ''Lightning Network'' or ''ZK-rollups,'' where only final settlement is on the main chain tend to address these issues. However, one could always argue that this often compromises some aspects of security and/or decentralization to achieve high TPS.

The trilemma was first introduced by Vitalik Buterin<ref>https://en.wikipedia.org/wiki/Vitalik_Buterin</ref>, one of the co-founders of Ethereum network. The problems he identified are real. There seem to be no obvious solutions that can accomplish all three goals at the same time. Therefore, all proposed solutions revolve around reducing "opportunity costs" focusing only on satisfying partial goals.

Treating the blockchain network as an infrastructure for transaction processing, the blockchain protocol solved service reliability problem but not performance challenge. The legacy infrastructure scaling dilemma: performance against reliability remains (where "infrastructure reliability" also does not have a commonly accepted definition). Fortunately these metrics, although important, are non-critical. Solutions that have been proposed have had varying opportunity costs. For many years, there were no obvious solutions that addressed all three blockchain goals (security, decentralization and scalability).
== Statistic Multiplexed Computing (SMC) ==
The principle of using unreliable components to build an arbitrarily reliable system was first lectured by von Neumann in the early 1950s<ref>https://static.ias.edu/pitp/archive/2012files/Probabilistic_Logics.pdf</ref>. The original idea was to use probabilistic logic to quantify the arbitrary reliability of a system by multiplexing all components. This theory was applied to the construction of Internet protocols to deliver the "best effort" reliability. Incidentally, best effort reliability also enabled "best effort" performance which in turn enabled unlimited scalability of the Internet. For emerging web3.0 technologies, it is important to apply the same methodology to both centralized and decentralized computing for seamless technology migration and integration. For historical arguments, click [[SMC|'''''here''''']].

== Definitions ==
'''Infrastructure scalability''' does not have a commonly accepted definition. It helps to define the challenging metrics more precisely before the infrastructure protocol design. In the following, for definitions #1 and #2, the word "'''infrastructure'''" means any '''application running on the infrastructure.'''

# '''Infrastructure Reliability''': MTBF (mean time between failure) = <math>\frac{\sum ((Start-Of-Downtime) - (Start-of-uptime)) }{No-of-failures}</math>
# '''Infrastructure Performance''': <math>\frac{No-of-Transactions}{Second}</math>
# '''Infrastructure Scalability''': Expanding the infrastructure in number of processors, networks or storage should have '''incrementally better''' impacts on application reliability and performance.
# '''Record Immutability''': For transaction ledgers, all confirmed records and changes are final. This is required by the blockchain protocol.
Note that in practice, record immutability is much harder to achieve than expected. There are two challenges, a) 51% attacks can literally wipe out all histories if successful, and b) for protocols require all nodes to hold independently verified ledger, such as the Bitcoin, the storage requirement grows approximately 50GB per month.

== 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 and considered.

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 crashe'''s <ref>https://groups.csail.mit.edu/tds/papers/Lynch/jacm93.pdf</ref>. The laws of physics regarding component reliability <ref>Encyclopedia of Physical Science and Technology, Editor-in-Chief Robert A. Meyers, [[index.php?title=Special:BookSources/9780122274107|ISBN 978-0-12-227410-7]], 2001</ref> show that '''100% component reliability is not possible.''' These facts require that the infrastructure protocol (program-program communication protocol) provide '''complete component (processing, networking and storage) decoupling''' from application program logics. This decoupling requirement forces the protocol to exploit "decentralized" or "stateless" components that the legacy infrastructure protocols, such as message passing interface (MPI), remote procedure call (RPC) and remote method invocation (RMI), cannot handle. The blockchain protocol is an example of a "best effort" availability protocol.

Quantifying infrastructure reliability can be traced back to the computer pioneer von Neumann. In addition to his contribution to computer architecture, von Neumann also penned a study on building reliable systems using unreliable components using probabilistic logics, in early fifties <ref>https://static.ias.edu/pitp/archive/2012files/Probabilistic_Logics.pdf</ref>. The 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 "best effort" reliability. Ironically, this best effort reliability also enabled the Internet's infinite scalability -- the benefit we enjoy now and into the future.

The Bitcoin protocol exploits multiple anonymous decoupled (or decentralized) computers connected through the Internet protocol. Judging from the Bitcoin network's reliability to date <ref>https://buybitcoinworldwide.com/bitcoin-downtime/</ref>, von Neumann's theory seems working well.

The '''second challenge''' involves infrastructure performance. Since the infrastructure must deploy multiple computing, networking and storage components, unless all components can be fully exploited at 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 lack this capability.

'''The infrastructure scalability challenge''' is automatically resolved once the performance challenge is resolved without negatively impacting reliability -- "best effort" performance" meets "best effort reliability". This requires inductive performance and reliability measures or deliveries.

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, an inductive statistic multiplexed blockchain protocol is needed to meet the scalability challenge. Non-inductive solutions such as fixed chain "sharding" or "Danksharding" <ref>https://ethereum.org/en/roadmap/danksharding/</ref> will only increase protocol development complexity with persistent performance walls.

== A Scalability Solution ==
An effective scalability solution can have two practical assumptions:

* The computation problem size can expand indefinitely, since every useful infrastructure is expected to solve bigger problems.

*Computing and network resources will continue to grow indefinitely, into the future.
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 <ref>https://en.wikipedia.org/wiki/Amdahl%27s_law</ref> and Gustafson's Law <ref>https://en.wikipedia.org/wiki/Gustafson%27s_law</ref>.

The Amdahl's Law assumes 0<= ''s'' <=1 percentage of serial instructions that cannot be parallelized. Then the ''(1-s)'' percentage of instructions can be accelerated using ''p'' processors.

<div style="text-align: center;">
Speedup(p) = <math>{1 \over s + {(1-s) \over p}}</math> (1) <br>Speedup(<math>\lim_{p \to \infty}</math>) = <math>\frac{1}{s}</math> (2)
</div>
Taking ''p'' to infinity in equation (1) yields equation (2). But this derivation step has two different operational semantics: a) increasing ''p'' to reduce (''1-s)'' value while keeping the problem size fixed. This will result ''s'' asymptotically approaching 1. Thus the speedup is above founded to 1. Or b) increasing p to increase the parallel percentage ''(1-s)'' by solving bigger problems. This will force ''s'' asymptotically approach 0. Then the speedup is above bounded by <math>\infty</math>. This ambiguity caused more than three decades of confusion in the community.

Although quantifying ''s'' requires additional information, such as the problem size, the law is applicable to programs solving any problem size with a known ''s''. The limit of speedup (2) also does not depend on problem size. However, since Amdahl used programs solving fixed problem sizes to argue the validity of not building parallel machines with too many processors, assuming fixed problem size using ''p'' processors has been the norm in interpreting Amdahl's law in the past. This assumption has led to the dismal speedup predictions.[[File:Amdahl's Law.png|thumb|Amdahl's Law Speedup Predictions|center]]The traditional Amdahl's Law interpretation seems to suggest parallel performances following the economic law of diminishing of returns, even though the mathematic model implies more potentials.

In 1988, Gustafson and Barsis at the Sandia National Laboratory conducted parallel computing experiments that seem to suggest potential infinite speedup.

Gustafson's Law was based on measured sequential and parallel elapsed times using ''p'' (=1024) processors. A new sequential percentage ''0<=x'<=1'' can be calculated. ''(1-x')'' is the parallel percentage using ''p'' processors.

To estimate accomplished speedup, Gustafson's Law states:

<div style="text-align: center;">
<math>Speedup=\frac{Tseq}{Tpar}=\frac{s'+(1-s')p}{1}=s'+(1-s')p </math> (3)
</div>

Take ''p'' -> <math>\infty</math> for equation (3) also has two operational semantics: a) Keep the problem size fixed, adding processors to further reduce the total parallel processing time, thus bigger s'. This will yield s' approaching 1. Thus speedup is above bounded to 1. Or b) expanding the problem size to allow the parallel part expanded solving bigger problems. This will yield s' asymptotically approaching 0. Speedup will be above bounded to ''p''. However, Gustafson's Law was used to argue for Massively Parallel Computing (MPC) (or ManyCPU) experiments and Amdahl's Law was used to argue for bigger mainframe (or BigCPU) computer architectures. In the past decades, these laws have been used to support two diverging computing system experiments and constructions until recently.
[[File:Gustafson.png|thumb|Gustafson's Law|center]]
It is now obvious that the two law are identical with Amdahl's Law more succinct. But Gustafson's formula helps to quantify the serial percentages from practical program executions. In fact, the two serial percentages can be related by a simple equation:

<div style="text-align: center;">
<math>s=\frac{s'}{s'+(1-s')p}</math> (4)
</div>

Both law actually refer to the same mathematical abstraction. Gustafson's formula assisted in quantifying the percentage of serial computing through program experiments. Neither should be directly used for speedup prediction alone.

This model can be validated in practice when developers simply increasing the problem size to use more parallel processors.

[[File:Full Range Amdah's Law .png|alt=Full Power of Amdahl's Law|center|thumb|Full Power of Amdahl's Law]]

A classical example is the TOP500 supercomputer benchmarks (linear solvers) that have open problem sizes for all manufacturers to compete in the world's fastest supercomputer race <ref>https://www.top500.org/</ref> .
[[File:Supercomputers-history.png|center|thumb]]
In practical blockchain applications, the number of transactions to be processed will increase without a known limit. The ledger storage will continue to grow. In practice, the available computing, networking and storage components will continue to grow without limits enabled by the networking protocols. Therefore a statistic multiplexed computing blockchain can meet any future application needs given proper economic incentives. The infrastructure no longer has the structural deficiency.

== Action Plan ==

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.

For Toichain protocol design, we choose Bitcoin 24.0.1 as the base line protocol by replacing the PoW consensus by PoS consensus and injecting SMC components into the protocol processing signaling for parallel computing.

This surprising result is also applicable to ledger storage. Without multiplexing, the blockchain ledger storage will eventually saturate all nodes causing the chain to collapse. The SMC blockchain protocol promises to hold the true finality of all transactions in perpetuity by multiplexing all storage resources while keeping the replication factor to a constant.

These discussions follow the inductive logic of the Law of Large Numbers <ref>https://www.sciencedirect.com/topics/mathematics/laws-of-large-number</ref>.

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

= SMC Proof of Stake Protocol =
Existing PoS protocol designs revolved around staking policies and randomness of the selection algorithm. Considering infrastructure scalability will add much complexity to the design. The examples include chain sharding and Danksharding <ref>https://ethereum.org/en/roadmap/danksharding/</ref>.

The challenge is complex -- we must deliver very high performance without compromising security and reliability of the network.

Technically, transaction replication and parallel processing were considered dangerous <ref>https://pages.cs.wisc.edu/~yxy/cs764-f20/papers/replication.pdf</ref> due to the potential race conditions (or double-spend problem). The blockchain protocol resolved the double-spending problem. It did not solve the parallel processing performance problem.

According to Professor Michael Flynn, there are three high-level parallel processing topologies: SIMD (single instruction multiple data), MIMD (multiple instructions multiple data), and pipeline (MISD - multiple instructions single data stream) <ref>https://link.springer.com/referenceworkentry/10.1007/978-0-387-09766-4_2</ref>. However, for eliminating double-spending, all transactions must be serialized, since each block may contain transactions affecting transactions in multiple other blocks. "Race conditions" and non-deterministic results are not allowed. Then the only possible topology entry is pipeline. This means for POS protocol, we must build a pipeline of transaction blocks to be validated without compromising network security and reliability.
[[File:Flynns-Taxonomy-of-Computer-Architectures.png|center|thumb|Parallel Processing Topologies]]
The problem is that the nature of the blockchain protocol is that all nodes run independently in parallel with little communication with other nodes via "gossip" protocols. It is far easier to force all nodes store the entire ledger than forcing them to form any pipeline and store partial chain data.

=== ACAN (Active Content Addressable Network) [U.S. and Other Patents Pending] ===
ACAN is a high-level data '''''communication and synchronization protocol''''' that completely decouples all hardware components from communicating programs. The need for complete component decoupling was implemented in the original blockchain protocol via "gossip" protocol. This delivered blockchain's high availability and security. The simple "gossip" implementation in existing protocols is insufficient for parallel processing signaling.

The following figure illustrates the concept of ACAN (active content addressable networking) using UVR (unidirectional virtual ring) architecture. The illustrated implementation uses the Tuple Space resource tagging method and gossip protocol for UVR implementation.
[[File:SMC Architecture with ACAN.png|center|thumb|243x243px|SMC Architecture with ACAN]]

ACAN supports three simple APIs:

# '''read'''(&''key'', &''value''): ''key'' holds a search pattern in a "tuple space" where all nodes are connected. ''value'' holds the matched tuple, if any. This is a blocking call that a requesting program will be blocked until a pattern-matched tuple is found. The matching tuple remains in the "tuple space".
# '''get'''(&key, &value): Same as the "read()" API, except that the matching tuple is removed from the "tuple space".
# '''put'''(key, value): Inserts <key, value> into the "tuple space".

The use of "gossip" protocol can accelerate ACAN network saturation time. Applications running on ACAN will automatically form parallel processing topologies: pipeline, SIMD and MIMD without violating the serialization needs of transaction block validation. Replication factor can also be dynamically controlled to spread replicated blocks in randomly chosen hosts.

The highly parallel nature of the blockchain protocol will automatically implement the SMC principle in real time.

The critical feature of this dynamic SMC pipelined architecture is the inductive scaling feature.
[[File:Pipeline Parallel Processing.png|center|thumb|247x247px|Pipeline Parallel Processing]]

The speed up of a pipeline can be represented as: <math>SpeedUp = \left ( \frac{p\centerdot b}{p + (b-p)} \right )</math>, where p = number of processors in the pipeline, b = total blocks to be processed. Take the number of blocks to infinity: <math>SpeedUp = \left ( \frac{p\centerdot b}{p + (b-p)} \right )=>\lim (b\Rightarrow\infty)(\frac{p}{\frac{p}{b}+1-\frac{p}{b}}) = p</math>

This means that as long as there are enough blocks to be processed, the entire chain's performance will be abound-bounded to the number of nodes in the pipeline.

For illustration purposes, the variation of block processing times was not considered in the above calculations. To see the power of pipeline parallelism, the automobile manufacturing processes illustrate a similar situation. The Hyundai Motor Company's production pipelines can produce 3,835 vehicles per day and 1.4M per year<ref>https://en.wikipedia.org/wiki/List_of_Hyundai_Motor_Company_manufacturing_facilities</ref>.

== Toichain Tokens ==
Toichain token is TOIN. There are 50,000,000,000 TOINs for the Alpha Release. There are air-drop tokens for early adopters, 1,000 TOIN each. Users need to register to download a toichain wallet to receive the payment. Citizenship is checked and verified to ensure that US citizens do not apply. The minimal staking contract is 10 TOINs.

== Non-Fungible Tokens ==
The TestNet Release of toichain protocol will support embedding arbitrary data in an "OP_RETURN" transaction that will be permanently recorded on the chain. Unlike the ordinal NFT <ref>https://blog.chain.link/ordinals-bitcoin-nfts/</ref> or NFT (non-fungible token) on other chains, these transactions cannot be altered or removed.

There are practical applications for these forever NFTs. Once Taproot is enabled on toichain, ordinal NFTs (BRC-20) will also be supported. Unlike the original Bitcoin network where BRC-20 craze has created massive network congestion<ref>https://beincrypto.com/learn/brc-20-token/</ref>, all transactions will be processed promptly in toichain without congestion or scaling problems.
== Toichain TestNet Launch ==
The toichain testnet launch will enable users to interact with one another through simple payments, just like the original Bitcoin network. Forever NFTs are supported. Smart contracts will be supported on a later date.

= References =
<references />

Consult the [[mediawikiwiki:Special:MyLanguage/Help:Contents|User's Guide]] for information on using the wiki software.

Main Page

2024-10-12T22:10:44Z

Justin: /* A Scalability Solution */

= <strong><big>'''Welcome to Toi-Twiki -- A Toichain Wiki'''</big></strong> =
This is the unofficial Toichain wiki site. Content is subject to changes.
---------------------------

= '''Introduction''' =
The blockchain protocol was introduced in a seminal paper entitled "Bitcoin: A peer-to-peer Electronic Cash System" <ref>https://bitcoin.org/bitcoin.pdf</ref> by Satoshi Nakamoto in 2008. Although there were previous peer-to-peer file-sharing projects such as Napster <ref>https://www.napster.com/us</ref>, BitTorrent <ref>https://www.bittorrent.com/</ref> and other electronic currency/file sharing applications, Bitcoin is the most enduring among the 23,000+ blockchains. Unlike other cryptocurrencies, the Bitcoin is often referred to as "digital gold" since the total coin supply is limited to 21 million (hard-coded in all running programs) and the only way to earn coin is to participate in the transaction block validation process. Token(or coin) supply and their disbursement policies differ among protocols.

The most attractive common blockchain features are 1) a decentralized consensus-driven decision making process and 2) a step-by-step cryptographic proving system. While blockchain is best known as a cryptocurrency transaction processing and record-keeping system, there are many other applications that can benefit from the secure storage, reliable transaction ledgers, fault tolerance and tamper resistance features.

== Algorithm vs. Protocol ==
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 ==
A good consensus protocol in a blockchain system has at least four properties:

# Fault tolerance to defend failures caused by natural disasters and human hacks or accidents
# Byzantine failure tolerance to defend exploitation by colluding parties
# Centralization avoidance to prevent corruptions in the decision making process
# Source code tamper resistance to automatically reject malicious attacks

Without assuming all nodes are active at all times, the blockchain relies on "gossip" protocol to communicate with other nodes. There are two popular types of consensus protocols: Proof of Work ('''PoW''') <ref>https://en.wikipedia.org/wiki/Proof_of_work</ref> or Proof of Stake ('''PoS''') <ref>https://www.investopedia.com/terms/p/proof-stake-pos.asp</ref>. Others include Proof of Possession('''PoP''')<ref>https://identityserver4.readthedocs.io/en/latest/topics/pop.html</ref> and Proof of History('''PoH''')<ref>https://www.infoworld.com/article/3666736/solana-blockchain-and-the-proof-of-history.html</ref>. The ultimate goal is to eliminate double-spending. Since most projects are open source, it's easy for a malicious actor to tamper a few nodes. This shouldn't compromise network integrity.

The Bitcoin network uses PoW which forces participating miners to compete for the fastest hashing rate by solving a computational cryptographic puzzle. Although it withstood more than 14 years of use, Bitcoin has been criticized for escalating electricity consumption <ref>https://www.forbes.com/advisor/investing/cryptocurrency/bitcoins-energy-usage-explained/</ref>. Other blockchain designs have experienced different challenges. For example, the PoH network Solana suffered multiple single-point-failure incidents <ref>https://messari.io/report/solana-analyzing-downtimes-statistics-and-ecosystem-development</ref>. All protocols struggle to combat scaling challenges. All are susceptible to 51% attacks <ref>https://originstamp.com/blog/has-there-ever-been-a-51-attack-on-bitcoin/#notable-51-attacks</ref>.

Since 2009, Bitcoin has proven to be the strongest and least susceptible to common hacks <ref>https://www.theguardian.com/technology/2014/mar/18/history-of-bitcoin-hacks-alternative-currency</ref>. As the PoW puzzle difficulty has increased dramatically over the years, the probability of a 51% attack on the Bitcoin network becomes more difficult. PoS protocols can save more than 90% energy consumption compared to PoW chains. But PoS chains have higher risks than PoW chains since a stolen coin will grow in PoS chains (for increased probability to be selected) forever but not in PoW chains (only hash rates count). PoS community governance rules can mitigate the voting power centralization problem. Staking and slashing policies can incentivize good behaviors and punish bad ones. In either case, double-spend is very expensive and difficult. According to Forbes, there are 80 cryptocurrencies that use PoS protocols at the time of this writing.

There are approximately 1,000 blockchains in four types: public, private, consortium, and permissioned <ref>https://increditools.com/blockchains/</ref>.

== Cryptographic Proofs ==
Bitcoin 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.

== Centralized vs. Decentralized Applications ==
The Bitcoin protocol enabled decentralized processing of traditionally centrally processed transactions without any trusted third-party. It inspired many decentralized financial applications, especially for applications with very long payment chains. However for fraud prevention and meeting financial regulatory requirements, many practical applications still require KYC (know your customer) checks. It is not possible to eliminate all trusted third parties, especially for custodial financial applications. There is a clear need for decentralized processing of trusted authority applications.

== Blockchain Trilemma ==
Blockchain protocols have three common aspects (goals): '''security''', '''decentralization''' and '''scalability''' -- these three terms do not have precise definitions but are intuitively understood <ref>https://sensoriumxr.com/articles/what-is-the-blockchain-trilemma</ref>. To date, 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.

A major shortcoming is scalability. Since all nodes verify each transaction independently, they need to store all the information required for it. As the chain grows, this burdens all nodes in the network. There are workarounds by limiting the amount of data stored on some nodes and exploiting the network to retrieve required information, such as the ''Limited/Light Nodes'' in Bitcoin network. Vast majority nodes are still full nodes in the existing Bitcoin network. Transaction processing speed often expressed ''as transactions per second(TPS) of'' blockchain have to exceed TPS ratings of credit card payment systems like VISA or MasterCard to reap the full benefits of blockchain. This is a tough problem and increasing the block size and/or reducing the block time or difficulty isn't a solution<ref>https://medium.com/coinmonks/blockchain-scaling-30c9e1b7db1b</ref>. Since blockchain TPS is very low, the transaction fees is often very high. This discourages public adoption. Layer 2 solution like ''Lightning Network'' or ''ZK-rollups,'' where only final settlement is on the main chain tend to address these issues. However, one could always argue that this often compromises some aspects of security and/or decentralization to achieve high TPS.

The trilemma was first introduced by Vitalik Buterin<ref>https://en.wikipedia.org/wiki/Vitalik_Buterin</ref>, one of the co-founders of Ethereum network. The problems he identified are real. There seem to be no obvious solutions that can accomplish all three goals at the same time. Therefore, all proposed solutions revolve around reducing "opportunity costs" focusing only on satisfying partial goals.

Treating the blockchain network as an infrastructure for transaction processing, the blockchain protocol solved service reliability problem but not performance challenge. The legacy infrastructure scaling dilemma: performance against reliability remains (where "infrastructure reliability" also does not have a commonly accepted definition). Fortunately these metrics, although important, are non-critical. Solutions that have been proposed have had varying opportunity costs. For many years, there were no obvious solutions that addressed all three blockchain goals (security, decentralization and scalability).
== Statistic Multiplexed Computing (SMC) ==
The principle of using unreliable components to build an arbitrarily reliable system was first lectured by von Neumann in the early 1950s<ref>https://static.ias.edu/pitp/archive/2012files/Probabilistic_Logics.pdf</ref>. The original idea was to use probabilistic logic to quantify the arbitrary reliability of a system by multiplexing all components. This theory was applied to the construction of Internet protocols to deliver the "best effort" reliability. Incidentally, best effort reliability also enabled "best effort" performance which in turn enabled unlimited scalability of the Internet. For emerging web3.0 technologies, it is important to apply the same methodology to both centralized and decentralized computing for seamless technology migration and integration. For historical arguments, click [[SMC|'''''here''''']].

== Definitions ==
'''Infrastructure scalability''' does not have a commonly accepted definition. It helps to define the challenging metrics more precisely before the infrastructure protocol design. In the following, for definitions #1 and #2, the word "'''infrastructure'''" means any '''application running on the infrastructure.'''

# '''Infrastructure Reliability''': MTBF (mean time between failure) = <math>\frac{\sum ((Start-Of-Downtime) - (Start-of-uptime)) }{No-of-failures}</math>
# '''Infrastructure Performance''': <math>\frac{No-of-Transactions}{Second}</math>
# '''Infrastructure Scalability''': Expanding the infrastructure in number of processors, networks or storage should have '''incrementally better''' impacts on application reliability and performance.
# '''Record Immutability''': For transaction ledgers, all confirmed records and changes are final. This is required by the blockchain protocol.
Note that in practice, record immutability is much harder to achieve than expected. There are two challenges, a) 51% attacks can literally wipe out all histories if successful, and b) for protocols require all nodes to hold independently verified ledger, such as the Bitcoin, the storage requirement grows approximately 50GB per month.

== 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 and considered.

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 crashe'''s <ref>https://groups.csail.mit.edu/tds/papers/Lynch/jacm93.pdf</ref>. The laws of physics regarding component reliability <ref>Encyclopedia of Physical Science and Technology, Editor-in-Chief Robert A. Meyers, [[index.php?title=Special:BookSources/9780122274107|ISBN 978-0-12-227410-7]], 2001</ref> show that '''100% component reliability is not possible.''' These facts require that the infrastructure protocol (program-program communication protocol) provide '''complete component (processing, networking and storage) decoupling''' from application program logics. This decoupling requirement forces the protocol to exploit "decentralized" or "stateless" components that the legacy infrastructure protocols, such as message passing interface (MPI), remote procedure call (RPC) and remote method invocation (RMI), cannot handle. The blockchain protocol is an example of a "best effort" availability protocol.

Quantifying infrastructure reliability can be traced back to the computer pioneer von Neumann. In addition to his contribution to computer architecture, von Neumann also penned a study on building reliable systems using unreliable components using probabilistic logics, in early fifties <ref>https://static.ias.edu/pitp/archive/2012files/Probabilistic_Logics.pdf</ref>. The 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 "best effort" reliability. Ironically, this best effort reliability also enabled the Internet's infinite scalability -- the benefit we enjoy now and into the future.

The Bitcoin protocol exploits multiple anonymous decoupled (or decentralized) computers connected through the Internet protocol. Judging from the Bitcoin network's reliability to date <ref>https://buybitcoinworldwide.com/bitcoin-downtime/</ref>, von Neumann's theory seems working well.

The '''second challenge''' involves infrastructure performance. Since the infrastructure must deploy multiple computing, networking and storage components, unless all components can be fully exploited at 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 lack this capability.

'''The infrastructure scalability challenge''' is automatically resolved once the performance challenge is resolved without negatively impacting reliability -- "best effort" performance" meets "best effort reliability". This requires inductive performance and reliability measures or deliveries.

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, an inductive statistic multiplexed blockchain protocol is needed to meet the scalability challenge. Non-inductive solutions such as fixed chain "sharding" or "Danksharding" <ref>https://ethereum.org/en/roadmap/danksharding/</ref> will only increase protocol development complexity with persistent performance walls.

== A Scalability Solution ==
An effective scalability solution can have two practical assumptions:

* The computation problem size can expand indefinitely, since every useful infrastructure is expected to solve bigger problems.

*Computing and network resources will continue to grow indefinitely, into the future.
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 <ref>https://en.wikipedia.org/wiki/Amdahl%27s_law</ref> and Gustafson's Law <ref>https://en.wikipedia.org/wiki/Gustafson%27s_law</ref>.

The Amdahl's Law assumes 0<= ''s'' <=1 percentage of serial instructions that cannot be parallelized. Then the ''(1-s)'' percentage of instructions can be accelerated using ''p'' processors.

<div style="text-align: center;">
Speedup(p) = <math>{1 \over s + {(1-s) \over p}}</math> (1) <br>Speedup(<math>\lim_{p \to \infty}</math>) = <math>\frac{1}{s}</math> (2)
</div>
Taking ''p'' to infinity in equation (1) yields equation (2). But this derivation step has two different operational semantics: a) increasing ''p'' to reduce (''1-s)'' value while keeping the problem size fixed. This will result ''s'' asymptotically approaching 1. Thus the speedup is above founded to 1. Or b) increasing p to increase the parallel percentage ''(1-s)'' by solving bigger problems. This will force ''s'' asymptotically approach 0. Then the speedup is above bounded by <math>\infty</math>. This ambiguity caused more than three decades of confusion in the community.

Although quantifying ''s'' requires additional information, such as the problem size, the law is applicable to programs solving any problem size with a known ''s''. The limit of speedup (2) also does not depend on problem size. However, since Amdahl used programs solving fixed problem sizes to argue the validity of not building parallel machines with too many processors, assuming fixed problem size using ''p'' processors has been the norm in interpreting Amdahl's law in the past. This assumption has led to the dismal speedup predictions.[[File:Amdahl's Law.png|thumb|Amdahl's Law Speedup Predictions|center]]The traditional Amdahl's Law interpretation seems to suggest parallel performances following the economic law of diminishing of returns, even though the mathematic model implies more potentials.

In 1988, Gustafson and Barsis at the Sandia National Laboratory conducted parallel computing experiments that seem to suggest potential infinite speedup.

Gustafson's Law was based on measured sequential and parallel elapsed times using ''p'' (=1024) processors. A new sequential percentage ''0<=x'<=1'' can be calculated. ''(1-x')'' is the parallel percentage using ''p'' processors.

To estimate accomplished speedup, Gustafson's Law states:

<math>Speedup=\frac{Tseq}{Tpar}=\frac{s'+(1-s')p}{1}=s'+(1-s')p </math> (3)

Take ''p'' -> <math>\infty</math> for equation (3) also has two operational semantics: a) Keep the problem size fixed, adding processors to further reduce the total parallel processing time, thus bigger s'. This will yield s' approaching 1. Thus speedup is above bounded to 1. Or b) expanding the problem size to allow the parallel part expanded solving bigger problems. This will yield s' asymptotically approaching 0. Speedup will be above bounded to ''p''. However, Gustafson's Law was used to argue for Massively Parallel Computing (MPC) (or ManyCPU) experiments and Amdahl's Law was used to argue for bigger mainframe (or BigCPU) computer architectures. In the past decades, these laws have been used to support two diverging computing system experiments and constructions until recently.
[[File:Gustafson.png|thumb|Gustafson's Law|center]]
It is now obvious that the two law are identical with Amdahl's Law more succinct. But Gustafson's formula helps to quantify the serial percentages from practical program executions. In fact, the two serial percentages can be related by a simple equation:

<math>s=\frac{s'}{s'+(1-s')p}</math> (4)

Both law actually refer to the same mathematical abstraction. Gustafson's formula assisted in quantifying the percentage of serial computing through program experiments. Neither should be directly used for speedup prediction alone.

This model can be validated in practice when developers simply increasing the problem size to use more parallel processors.

[[File:Full Range Amdah's Law .png|alt=Full Power of Amdahl's Law|center|thumb|Full Power of Amdahl's Law]]

A classical example is the TOP500 supercomputer benchmarks (linear solvers) that have open problem sizes for all manufacturers to compete in the world's fastest supercomputer race <ref>https://www.top500.org/</ref> .
[[File:Supercomputers-history.png|center|thumb]]
In practical blockchain applications, the number of transactions to be processed will increase without a known limit. The ledger storage will continue to grow. In practice, the available computing, networking and storage components will continue to grow without limits enabled by the networking protocols. Therefore a statistic multiplexed computing blockchain can meet any future application needs given proper economic incentives. The infrastructure no longer has the structural deficiency.

== Action Plan ==

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.

For Toichain protocol design, we choose Bitcoin 24.0.1 as the base line protocol by replacing the PoW consensus by PoS consensus and injecting SMC components into the protocol processing signaling for parallel computing.

This surprising result is also applicable to ledger storage. Without multiplexing, the blockchain ledger storage will eventually saturate all nodes causing the chain to collapse. The SMC blockchain protocol promises to hold the true finality of all transactions in perpetuity by multiplexing all storage resources while keeping the replication factor to a constant.

These discussions follow the inductive logic of the Law of Large Numbers <ref>https://www.sciencedirect.com/topics/mathematics/laws-of-large-number</ref>.

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

= SMC Proof of Stake Protocol =
Existing PoS protocol designs revolved around staking policies and randomness of the selection algorithm. Considering infrastructure scalability will add much complexity to the design. The examples include chain sharding and Danksharding <ref>https://ethereum.org/en/roadmap/danksharding/</ref>.

The challenge is complex -- we must deliver very high performance without compromising security and reliability of the network.

Technically, transaction replication and parallel processing were considered dangerous <ref>https://pages.cs.wisc.edu/~yxy/cs764-f20/papers/replication.pdf</ref> due to the potential race conditions (or double-spend problem). The blockchain protocol resolved the double-spending problem. It did not solve the parallel processing performance problem.

According to Professor Michael Flynn, there are three high-level parallel processing topologies: SIMD (single instruction multiple data), MIMD (multiple instructions multiple data), and pipeline (MISD - multiple instructions single data stream) <ref>https://link.springer.com/referenceworkentry/10.1007/978-0-387-09766-4_2</ref>. However, for eliminating double-spending, all transactions must be serialized, since each block may contain transactions affecting transactions in multiple other blocks. "Race conditions" and non-deterministic results are not allowed. Then the only possible topology entry is pipeline. This means for POS protocol, we must build a pipeline of transaction blocks to be validated without compromising network security and reliability.
[[File:Flynns-Taxonomy-of-Computer-Architectures.png|center|thumb|Parallel Processing Topologies]]
The problem is that the nature of the blockchain protocol is that all nodes run independently in parallel with little communication with other nodes via "gossip" protocols. It is far easier to force all nodes store the entire ledger than forcing them to form any pipeline and store partial chain data.

=== ACAN (Active Content Addressable Network) [U.S. and Other Patents Pending] ===
ACAN is a high-level data '''''communication and synchronization protocol''''' that completely decouples all hardware components from communicating programs. The need for complete component decoupling was implemented in the original blockchain protocol via "gossip" protocol. This delivered blockchain's high availability and security. The simple "gossip" implementation in existing protocols is insufficient for parallel processing signaling.

The following figure illustrates the concept of ACAN (active content addressable networking) using UVR (unidirectional virtual ring) architecture. The illustrated implementation uses the Tuple Space resource tagging method and gossip protocol for UVR implementation.
[[File:SMC Architecture with ACAN.png|center|thumb|243x243px|SMC Architecture with ACAN]]

ACAN supports three simple APIs:

# '''read'''(&''key'', &''value''): ''key'' holds a search pattern in a "tuple space" where all nodes are connected. ''value'' holds the matched tuple, if any. This is a blocking call that a requesting program will be blocked until a pattern-matched tuple is found. The matching tuple remains in the "tuple space".
# '''get'''(&key, &value): Same as the "read()" API, except that the matching tuple is removed from the "tuple space".
# '''put'''(key, value): Inserts <key, value> into the "tuple space".

The use of "gossip" protocol can accelerate ACAN network saturation time. Applications running on ACAN will automatically form parallel processing topologies: pipeline, SIMD and MIMD without violating the serialization needs of transaction block validation. Replication factor can also be dynamically controlled to spread replicated blocks in randomly chosen hosts.

The highly parallel nature of the blockchain protocol will automatically implement the SMC principle in real time.

The critical feature of this dynamic SMC pipelined architecture is the inductive scaling feature.
[[File:Pipeline Parallel Processing.png|center|thumb|247x247px|Pipeline Parallel Processing]]

The speed up of a pipeline can be represented as: <math>SpeedUp = \left ( \frac{p\centerdot b}{p + (b-p)} \right )</math>, where p = number of processors in the pipeline, b = total blocks to be processed. Take the number of blocks to infinity: <math>SpeedUp = \left ( \frac{p\centerdot b}{p + (b-p)} \right )=>\lim (b\Rightarrow\infty)(\frac{p}{\frac{p}{b}+1-\frac{p}{b}}) = p</math>

This means that as long as there are enough blocks to be processed, the entire chain's performance will be abound-bounded to the number of nodes in the pipeline.

For illustration purposes, the variation of block processing times was not considered in the above calculations. To see the power of pipeline parallelism, the automobile manufacturing processes illustrate a similar situation. The Hyundai Motor Company's production pipelines can produce 3,835 vehicles per day and 1.4M per year<ref>https://en.wikipedia.org/wiki/List_of_Hyundai_Motor_Company_manufacturing_facilities</ref>.

== Toichain Tokens ==
Toichain token is TOIN. There are 50,000,000,000 TOINs for the Alpha Release. There are air-drop tokens for early adopters, 1,000 TOIN each. Users need to register to download a toichain wallet to receive the payment. Citizenship is checked and verified to ensure that US citizens do not apply. The minimal staking contract is 10 TOINs.

== Non-Fungible Tokens ==
The TestNet Release of toichain protocol will support embedding arbitrary data in an "OP_RETURN" transaction that will be permanently recorded on the chain. Unlike the ordinal NFT <ref>https://blog.chain.link/ordinals-bitcoin-nfts/</ref> or NFT (non-fungible token) on other chains, these transactions cannot be altered or removed.

There are practical applications for these forever NFTs. Once Taproot is enabled on toichain, ordinal NFTs (BRC-20) will also be supported. Unlike the original Bitcoin network where BRC-20 craze has created massive network congestion<ref>https://beincrypto.com/learn/brc-20-token/</ref>, all transactions will be processed promptly in toichain without congestion or scaling problems.
== Toichain TestNet Launch ==
The toichain testnet launch will enable users to interact with one another through simple payments, just like the original Bitcoin network. Forever NFTs are supported. Smart contracts will be supported on a later date.

= References =
<references />

Consult the [[mediawikiwiki:Special:MyLanguage/Help:Contents|User's Guide]] for information on using the wiki software.

Main Page

2024-10-12T22:03:24Z

Justin: /* A Scalability Solution */

= <strong><big>'''Welcome to Toi-Twiki -- A Toichain Wiki'''</big></strong> =
This is the unofficial Toichain wiki site. Content is subject to changes.
---------------------------

= '''Introduction''' =
The blockchain protocol was introduced in a seminal paper entitled "Bitcoin: A peer-to-peer Electronic Cash System" <ref>https://bitcoin.org/bitcoin.pdf</ref> by Satoshi Nakamoto in 2008. Although there were previous peer-to-peer file-sharing projects such as Napster <ref>https://www.napster.com/us</ref>, BitTorrent <ref>https://www.bittorrent.com/</ref> and other electronic currency/file sharing applications, Bitcoin is the most enduring among the 23,000+ blockchains. Unlike other cryptocurrencies, the Bitcoin is often referred to as "digital gold" since the total coin supply is limited to 21 million (hard-coded in all running programs) and the only way to earn coin is to participate in the transaction block validation process. Token(or coin) supply and their disbursement policies differ among protocols.

The most attractive common blockchain features are 1) a decentralized consensus-driven decision making process and 2) a step-by-step cryptographic proving system. While blockchain is best known as a cryptocurrency transaction processing and record-keeping system, there are many other applications that can benefit from the secure storage, reliable transaction ledgers, fault tolerance and tamper resistance features.

== Algorithm vs. Protocol ==
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 ==
A good consensus protocol in a blockchain system has at least four properties:

# Fault tolerance to defend failures caused by natural disasters and human hacks or accidents
# Byzantine failure tolerance to defend exploitation by colluding parties
# Centralization avoidance to prevent corruptions in the decision making process
# Source code tamper resistance to automatically reject malicious attacks

Without assuming all nodes are active at all times, the blockchain relies on "gossip" protocol to communicate with other nodes. There are two popular types of consensus protocols: Proof of Work ('''PoW''') <ref>https://en.wikipedia.org/wiki/Proof_of_work</ref> or Proof of Stake ('''PoS''') <ref>https://www.investopedia.com/terms/p/proof-stake-pos.asp</ref>. Others include Proof of Possession('''PoP''')<ref>https://identityserver4.readthedocs.io/en/latest/topics/pop.html</ref> and Proof of History('''PoH''')<ref>https://www.infoworld.com/article/3666736/solana-blockchain-and-the-proof-of-history.html</ref>. The ultimate goal is to eliminate double-spending. Since most projects are open source, it's easy for a malicious actor to tamper a few nodes. This shouldn't compromise network integrity.

The Bitcoin network uses PoW which forces participating miners to compete for the fastest hashing rate by solving a computational cryptographic puzzle. Although it withstood more than 14 years of use, Bitcoin has been criticized for escalating electricity consumption <ref>https://www.forbes.com/advisor/investing/cryptocurrency/bitcoins-energy-usage-explained/</ref>. Other blockchain designs have experienced different challenges. For example, the PoH network Solana suffered multiple single-point-failure incidents <ref>https://messari.io/report/solana-analyzing-downtimes-statistics-and-ecosystem-development</ref>. All protocols struggle to combat scaling challenges. All are susceptible to 51% attacks <ref>https://originstamp.com/blog/has-there-ever-been-a-51-attack-on-bitcoin/#notable-51-attacks</ref>.

Since 2009, Bitcoin has proven to be the strongest and least susceptible to common hacks <ref>https://www.theguardian.com/technology/2014/mar/18/history-of-bitcoin-hacks-alternative-currency</ref>. As the PoW puzzle difficulty has increased dramatically over the years, the probability of a 51% attack on the Bitcoin network becomes more difficult. PoS protocols can save more than 90% energy consumption compared to PoW chains. But PoS chains have higher risks than PoW chains since a stolen coin will grow in PoS chains (for increased probability to be selected) forever but not in PoW chains (only hash rates count). PoS community governance rules can mitigate the voting power centralization problem. Staking and slashing policies can incentivize good behaviors and punish bad ones. In either case, double-spend is very expensive and difficult. According to Forbes, there are 80 cryptocurrencies that use PoS protocols at the time of this writing.

There are approximately 1,000 blockchains in four types: public, private, consortium, and permissioned <ref>https://increditools.com/blockchains/</ref>.

== Cryptographic Proofs ==
Bitcoin 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.

== Centralized vs. Decentralized Applications ==
The Bitcoin protocol enabled decentralized processing of traditionally centrally processed transactions without any trusted third-party. It inspired many decentralized financial applications, especially for applications with very long payment chains. However for fraud prevention and meeting financial regulatory requirements, many practical applications still require KYC (know your customer) checks. It is not possible to eliminate all trusted third parties, especially for custodial financial applications. There is a clear need for decentralized processing of trusted authority applications.

== Blockchain Trilemma ==
Blockchain protocols have three common aspects (goals): '''security''', '''decentralization''' and '''scalability''' -- these three terms do not have precise definitions but are intuitively understood <ref>https://sensoriumxr.com/articles/what-is-the-blockchain-trilemma</ref>. To date, 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.

A major shortcoming is scalability. Since all nodes verify each transaction independently, they need to store all the information required for it. As the chain grows, this burdens all nodes in the network. There are workarounds by limiting the amount of data stored on some nodes and exploiting the network to retrieve required information, such as the ''Limited/Light Nodes'' in Bitcoin network. Vast majority nodes are still full nodes in the existing Bitcoin network. Transaction processing speed often expressed ''as transactions per second(TPS) of'' blockchain have to exceed TPS ratings of credit card payment systems like VISA or MasterCard to reap the full benefits of blockchain. This is a tough problem and increasing the block size and/or reducing the block time or difficulty isn't a solution<ref>https://medium.com/coinmonks/blockchain-scaling-30c9e1b7db1b</ref>. Since blockchain TPS is very low, the transaction fees is often very high. This discourages public adoption. Layer 2 solution like ''Lightning Network'' or ''ZK-rollups,'' where only final settlement is on the main chain tend to address these issues. However, one could always argue that this often compromises some aspects of security and/or decentralization to achieve high TPS.

The trilemma was first introduced by Vitalik Buterin<ref>https://en.wikipedia.org/wiki/Vitalik_Buterin</ref>, one of the co-founders of Ethereum network. The problems he identified are real. There seem to be no obvious solutions that can accomplish all three goals at the same time. Therefore, all proposed solutions revolve around reducing "opportunity costs" focusing only on satisfying partial goals.

Treating the blockchain network as an infrastructure for transaction processing, the blockchain protocol solved service reliability problem but not performance challenge. The legacy infrastructure scaling dilemma: performance against reliability remains (where "infrastructure reliability" also does not have a commonly accepted definition). Fortunately these metrics, although important, are non-critical. Solutions that have been proposed have had varying opportunity costs. For many years, there were no obvious solutions that addressed all three blockchain goals (security, decentralization and scalability).
== Statistic Multiplexed Computing (SMC) ==
The principle of using unreliable components to build an arbitrarily reliable system was first lectured by von Neumann in the early 1950s<ref>https://static.ias.edu/pitp/archive/2012files/Probabilistic_Logics.pdf</ref>. The original idea was to use probabilistic logic to quantify the arbitrary reliability of a system by multiplexing all components. This theory was applied to the construction of Internet protocols to deliver the "best effort" reliability. Incidentally, best effort reliability also enabled "best effort" performance which in turn enabled unlimited scalability of the Internet. For emerging web3.0 technologies, it is important to apply the same methodology to both centralized and decentralized computing for seamless technology migration and integration. For historical arguments, click [[SMC|'''''here''''']].

== Definitions ==
'''Infrastructure scalability''' does not have a commonly accepted definition. It helps to define the challenging metrics more precisely before the infrastructure protocol design. In the following, for definitions #1 and #2, the word "'''infrastructure'''" means any '''application running on the infrastructure.'''

# '''Infrastructure Reliability''': MTBF (mean time between failure) = <math>\frac{\sum ((Start-Of-Downtime) - (Start-of-uptime)) }{No-of-failures}</math>
# '''Infrastructure Performance''': <math>\frac{No-of-Transactions}{Second}</math>
# '''Infrastructure Scalability''': Expanding the infrastructure in number of processors, networks or storage should have '''incrementally better''' impacts on application reliability and performance.
# '''Record Immutability''': For transaction ledgers, all confirmed records and changes are final. This is required by the blockchain protocol.
Note that in practice, record immutability is much harder to achieve than expected. There are two challenges, a) 51% attacks can literally wipe out all histories if successful, and b) for protocols require all nodes to hold independently verified ledger, such as the Bitcoin, the storage requirement grows approximately 50GB per month.

== 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 and considered.

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 crashe'''s <ref>https://groups.csail.mit.edu/tds/papers/Lynch/jacm93.pdf</ref>. The laws of physics regarding component reliability <ref>Encyclopedia of Physical Science and Technology, Editor-in-Chief Robert A. Meyers, [[index.php?title=Special:BookSources/9780122274107|ISBN 978-0-12-227410-7]], 2001</ref> show that '''100% component reliability is not possible.''' These facts require that the infrastructure protocol (program-program communication protocol) provide '''complete component (processing, networking and storage) decoupling''' from application program logics. This decoupling requirement forces the protocol to exploit "decentralized" or "stateless" components that the legacy infrastructure protocols, such as message passing interface (MPI), remote procedure call (RPC) and remote method invocation (RMI), cannot handle. The blockchain protocol is an example of a "best effort" availability protocol.

Quantifying infrastructure reliability can be traced back to the computer pioneer von Neumann. In addition to his contribution to computer architecture, von Neumann also penned a study on building reliable systems using unreliable components using probabilistic logics, in early fifties <ref>https://static.ias.edu/pitp/archive/2012files/Probabilistic_Logics.pdf</ref>. The 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 "best effort" reliability. Ironically, this best effort reliability also enabled the Internet's infinite scalability -- the benefit we enjoy now and into the future.

The Bitcoin protocol exploits multiple anonymous decoupled (or decentralized) computers connected through the Internet protocol. Judging from the Bitcoin network's reliability to date <ref>https://buybitcoinworldwide.com/bitcoin-downtime/</ref>, von Neumann's theory seems working well.

The '''second challenge''' involves infrastructure performance. Since the infrastructure must deploy multiple computing, networking and storage components, unless all components can be fully exploited at 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 lack this capability.

'''The infrastructure scalability challenge''' is automatically resolved once the performance challenge is resolved without negatively impacting reliability -- "best effort" performance" meets "best effort reliability". This requires inductive performance and reliability measures or deliveries.

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, an inductive statistic multiplexed blockchain protocol is needed to meet the scalability challenge. Non-inductive solutions such as fixed chain "sharding" or "Danksharding" <ref>https://ethereum.org/en/roadmap/danksharding/</ref> will only increase protocol development complexity with persistent performance walls.

== A Scalability Solution ==
An effective scalability solution can have two practical assumptions:

* The computation problem size can expand indefinitely, since every useful infrastructure is expected to solve bigger problems.

*Computing and network resources will continue to grow indefinitely, into the future.
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 <ref>https://en.wikipedia.org/wiki/Amdahl%27s_law</ref> and Gustafson's Law <ref>https://en.wikipedia.org/wiki/Gustafson%27s_law</ref>.

The Amdahl's Law assumes 0<= ''s'' <=1 percentage of serial instructions that cannot be parallelized. Then the ''(1-s)'' percentage of instructions can be accelerated using ''p'' processors.

<div style="text-align: center;">
Speedup(p) = <math>{1 \over s + {(1-s) \over p}}</math> (1) <br>Speedup(<math>\lim_{p \to \infty}</math>) = <math>\frac{1}{s}</math> (2)
</div>
Taking ''p'' to infinity in equation (1) yields equation (2). But this derivation step has two different operational semantics: a) increasing ''p'' to reduce (''1-s)'' value while keeping the problem size fixed. This will result ''s'' asymptotically approaching 1. Thus the speedup is above founded to 1. Or b) increasing p to increase the parallel percentage ''(1-s)'' by solving bigger problems. This will force ''s'' asymptotically approach 0. Then the speedup is above bounded by <math>\infty</math>. This ambiguity caused more than three decades of confusion in the community.

Although quantifying ''s'' requires additional information, such as the problem size, the law is applicable to programs solving any problem size with a known ''s''. The limit of speedup (2) also does not depend on problem size. However, since Amdahl used programs solving fixed problem sizes to argue the validity of not building parallel machines with too many processors, assuming fixed problem size using ''p'' processors has been the norm in interpreting Amdahl's law in the past. This assumption has led to the dismal speedup predictions.[[File:Amdahl's Law.png|thumb|Amdahl's Law Speedup Predictions|center]]The traditional Amdahl's Law interpretation seems to suggest parallel performances following the economic law of diminishing of returns, even though the mathematic model implies more potentials.

In 1988, Gustafson and Barsis at the Sandia National Laboratory conducted parallel computing experiments that seem to suggest potential infinite speedup.

Gustafson's Law was based on measured sequential and parallel elapsed times using ''p'' (=1024) processors. A new sequential percentage ''0<=x'<=1'' can be calculated. ''(1-x')'' is the parallel percentage using ''p'' processors.

To estimate accomplished speedup, Gustafson's Law states:

<math>Speedup=\frac{Tseq}{Tpar}=\frac{s'+(1-s')p}{1}=s'+(1-s')p </math> (3)

Take ''p'' -> <math>\infty</math> for equation (3) also has two operational semantics: a) Keep the problem size fixed, adding processors to further reduce the total parallel processing time, thus bigger s'. This will yield s' approaching 1. Thus speedup is above bounded to 1. Or b) expanding the problem size to allow the parallel part expanded solving bigger problems. This will yield s' asymptotically approaching 0. Speedup will be above bounded to ''p''. However, Gustafson's Law was used to argue for Massively Parallel Computing (MPC) (or ManyCPU) experiments and Amdahl's Law was used to argue for bigger mainframe (or BigCPU) computer architectures. In the past decades, these laws have been used to support two diverging computing system experiments and constructions until recently.
[[File:Gustafson.png|thumb|Gustafson's Law|center]]
It is now obvious that the two law are identical with Amdahl's Law more succinct. But Gustafson's formula helps to quantify the serial percentages from practical program executions. In fact, the two serial percentages can be related by a simple equation:

<math>s=\frac{s'}{s'+(1-s')p}</math> (4)

A careful examination revealed that the Gustafson's Law cannot scale mathematically since the are mathematically dependent <ref>https://cis.temple.edu/~shi/wwwroot/shi/public_html/docs/amdahl/amdahl.html</ref> where Amdahl's formulation has a tight peak performance bound <math>\left ( \frac{1}{x} \right )</math> 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 <math>\left ( \frac{1}{x} \right )</math>, when <math>x \Rightarrow 0</math>, the performance will asymptotically approach to <math>\infty</math>, when <math>x \Rightarrow 1</math> the speedup <math>\Rightarrow</math> 1. Thus, if the computing problem's size is fixed, x will eventually approach to 1 as the number of processors increases -- economic law of diminishing of return. If the problem size is open (solving bigger problems), then increasing the number of processors will force x <math>\Rightarrow</math> 0, thus speedup <math>\Rightarrow</math> <math>\infty</math>. Gustafson's Law uses a recurrence relation based on practical time measurements. It is not possible to derive a mathematical speedup bound.

Applying these laws in practice need to quantify <math>\chi</math> for practical parallel program which has been proven very hard if not impossible. Gustafson's formula was derived from times by running actual parallel programs. Brining the two formulation together makes quantifying <math>\chi</math> in Amdahl's Law possible. Thus, both law actually refer to the same mathematical abstraction. Gustafson's formula assisted in quantifying the percentage of serial computing through program experiments. Neither should be directly used for speedup prediction alone.

This model can be validated in practice when developers simply increasing the problem size to use more parallel processors.
[[File:1overx-function resized.png|thumb|294x294px|Amdalh's Law and Peak Parallel Performance|center]]

A classical example is the TOP500 supercomputer benchmarks (linear solvers) that have open problem sizes for all manufacturers to compete in the world's fastest supercomputer race <ref>https://www.top500.org/</ref> .
[[File:Supercomputers-history.png|center|thumb]]
In practical blockchain applications, the number of transactions to be processed will increase without a known limit. The ledger storage will continue to grow. In practice, the available computing, networking and storage components will continue to grow without limits enabled by the networking protocols. Therefore a statistic multiplexed computing blockchain can meet any future application needs given proper economic incentives. The infrastructure no longer has the structural deficiency.

== Action Plan ==

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.

For Toichain protocol design, we choose Bitcoin 24.0.1 as the base line protocol by replacing the PoW consensus by PoS consensus and injecting SMC components into the protocol processing signaling for parallel computing.

This surprising result is also applicable to ledger storage. Without multiplexing, the blockchain ledger storage will eventually saturate all nodes causing the chain to collapse. The SMC blockchain protocol promises to hold the true finality of all transactions in perpetuity by multiplexing all storage resources while keeping the replication factor to a constant.

These discussions follow the inductive logic of the Law of Large Numbers <ref>https://www.sciencedirect.com/topics/mathematics/laws-of-large-number</ref>.

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

= SMC Proof of Stake Protocol =
Existing PoS protocol designs revolved around staking policies and randomness of the selection algorithm. Considering infrastructure scalability will add much complexity to the design. The examples include chain sharding and Danksharding <ref>https://ethereum.org/en/roadmap/danksharding/</ref>.

The challenge is complex -- we must deliver very high performance without compromising security and reliability of the network.

Technically, transaction replication and parallel processing were considered dangerous <ref>https://pages.cs.wisc.edu/~yxy/cs764-f20/papers/replication.pdf</ref> due to the potential race conditions (or double-spend problem). The blockchain protocol resolved the double-spending problem. It did not solve the parallel processing performance problem.

According to Professor Michael Flynn, there are three high-level parallel processing topologies: SIMD (single instruction multiple data), MIMD (multiple instructions multiple data), and pipeline (MISD - multiple instructions single data stream) <ref>https://link.springer.com/referenceworkentry/10.1007/978-0-387-09766-4_2</ref>. However, for eliminating double-spending, all transactions must be serialized, since each block may contain transactions affecting transactions in multiple other blocks. "Race conditions" and non-deterministic results are not allowed. Then the only possible topology entry is pipeline. This means for POS protocol, we must build a pipeline of transaction blocks to be validated without compromising network security and reliability.
[[File:Flynns-Taxonomy-of-Computer-Architectures.png|center|thumb|Parallel Processing Topologies]]
The problem is that the nature of the blockchain protocol is that all nodes run independently in parallel with little communication with other nodes via "gossip" protocols. It is far easier to force all nodes store the entire ledger than forcing them to form any pipeline and store partial chain data.

=== ACAN (Active Content Addressable Network) [U.S. and Other Patents Pending] ===
ACAN is a high-level data '''''communication and synchronization protocol''''' that completely decouples all hardware components from communicating programs. The need for complete component decoupling was implemented in the original blockchain protocol via "gossip" protocol. This delivered blockchain's high availability and security. The simple "gossip" implementation in existing protocols is insufficient for parallel processing signaling.

The following figure illustrates the concept of ACAN (active content addressable networking) using UVR (unidirectional virtual ring) architecture. The illustrated implementation uses the Tuple Space resource tagging method and gossip protocol for UVR implementation.
[[File:SMC Architecture with ACAN.png|center|thumb|243x243px|SMC Architecture with ACAN]]

ACAN supports three simple APIs:

# '''read'''(&''key'', &''value''): ''key'' holds a search pattern in a "tuple space" where all nodes are connected. ''value'' holds the matched tuple, if any. This is a blocking call that a requesting program will be blocked until a pattern-matched tuple is found. The matching tuple remains in the "tuple space".
# '''get'''(&key, &value): Same as the "read()" API, except that the matching tuple is removed from the "tuple space".
# '''put'''(key, value): Inserts <key, value> into the "tuple space".

The use of "gossip" protocol can accelerate ACAN network saturation time. Applications running on ACAN will automatically form parallel processing topologies: pipeline, SIMD and MIMD without violating the serialization needs of transaction block validation. Replication factor can also be dynamically controlled to spread replicated blocks in randomly chosen hosts.

The highly parallel nature of the blockchain protocol will automatically implement the SMC principle in real time.

The critical feature of this dynamic SMC pipelined architecture is the inductive scaling feature.
[[File:Pipeline Parallel Processing.png|center|thumb|247x247px|Pipeline Parallel Processing]]

The speed up of a pipeline can be represented as: <math>SpeedUp = \left ( \frac{p\centerdot b}{p + (b-p)} \right )</math>, where p = number of processors in the pipeline, b = total blocks to be processed. Take the number of blocks to infinity: <math>SpeedUp = \left ( \frac{p\centerdot b}{p + (b-p)} \right )=>\lim (b\Rightarrow\infty)(\frac{p}{\frac{p}{b}+1-\frac{p}{b}}) = p</math>

This means that as long as there are enough blocks to be processed, the entire chain's performance will be abound-bounded to the number of nodes in the pipeline.

For illustration purposes, the variation of block processing times was not considered in the above calculations. To see the power of pipeline parallelism, the automobile manufacturing processes illustrate a similar situation. The Hyundai Motor Company's production pipelines can produce 3,835 vehicles per day and 1.4M per year<ref>https://en.wikipedia.org/wiki/List_of_Hyundai_Motor_Company_manufacturing_facilities</ref>.

== Toichain Tokens ==
Toichain token is TOIN. There are 50,000,000,000 TOINs for the Alpha Release. There are air-drop tokens for early adopters, 1,000 TOIN each. Users need to register to download a toichain wallet to receive the payment. Citizenship is checked and verified to ensure that US citizens do not apply. The minimal staking contract is 10 TOINs.

== Non-Fungible Tokens ==
The TestNet Release of toichain protocol will support embedding arbitrary data in an "OP_RETURN" transaction that will be permanently recorded on the chain. Unlike the ordinal NFT <ref>https://blog.chain.link/ordinals-bitcoin-nfts/</ref> or NFT (non-fungible token) on other chains, these transactions cannot be altered or removed.

There are practical applications for these forever NFTs. Once Taproot is enabled on toichain, ordinal NFTs (BRC-20) will also be supported. Unlike the original Bitcoin network where BRC-20 craze has created massive network congestion<ref>https://beincrypto.com/learn/brc-20-token/</ref>, all transactions will be processed promptly in toichain without congestion or scaling problems.
== Toichain TestNet Launch ==
The toichain testnet launch will enable users to interact with one another through simple payments, just like the original Bitcoin network. Forever NFTs are supported. Smart contracts will be supported on a later date.

= References =
<references />

Consult the [[mediawikiwiki:Special:MyLanguage/Help:Contents|User's Guide]] for information on using the wiki software.

Main Page

2024-10-12T21:54:11Z

Justin: /* A Scalability Solution */

= <strong><big>'''Welcome to Toi-Twiki -- A Toichain Wiki'''</big></strong> =
This is the unofficial Toichain wiki site. Content is subject to changes.
---------------------------

= '''Introduction''' =
The blockchain protocol was introduced in a seminal paper entitled "Bitcoin: A peer-to-peer Electronic Cash System" <ref>https://bitcoin.org/bitcoin.pdf</ref> by Satoshi Nakamoto in 2008. Although there were previous peer-to-peer file-sharing projects such as Napster <ref>https://www.napster.com/us</ref>, BitTorrent <ref>https://www.bittorrent.com/</ref> and other electronic currency/file sharing applications, Bitcoin is the most enduring among the 23,000+ blockchains. Unlike other cryptocurrencies, the Bitcoin is often referred to as "digital gold" since the total coin supply is limited to 21 million (hard-coded in all running programs) and the only way to earn coin is to participate in the transaction block validation process. Token(or coin) supply and their disbursement policies differ among protocols.

The most attractive common blockchain features are 1) a decentralized consensus-driven decision making process and 2) a step-by-step cryptographic proving system. While blockchain is best known as a cryptocurrency transaction processing and record-keeping system, there are many other applications that can benefit from the secure storage, reliable transaction ledgers, fault tolerance and tamper resistance features.

== Algorithm vs. Protocol ==
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 ==
A good consensus protocol in a blockchain system has at least four properties:

# Fault tolerance to defend failures caused by natural disasters and human hacks or accidents
# Byzantine failure tolerance to defend exploitation by colluding parties
# Centralization avoidance to prevent corruptions in the decision making process
# Source code tamper resistance to automatically reject malicious attacks

Without assuming all nodes are active at all times, the blockchain relies on "gossip" protocol to communicate with other nodes. There are two popular types of consensus protocols: Proof of Work ('''PoW''') <ref>https://en.wikipedia.org/wiki/Proof_of_work</ref> or Proof of Stake ('''PoS''') <ref>https://www.investopedia.com/terms/p/proof-stake-pos.asp</ref>. Others include Proof of Possession('''PoP''')<ref>https://identityserver4.readthedocs.io/en/latest/topics/pop.html</ref> and Proof of History('''PoH''')<ref>https://www.infoworld.com/article/3666736/solana-blockchain-and-the-proof-of-history.html</ref>. The ultimate goal is to eliminate double-spending. Since most projects are open source, it's easy for a malicious actor to tamper a few nodes. This shouldn't compromise network integrity.

The Bitcoin network uses PoW which forces participating miners to compete for the fastest hashing rate by solving a computational cryptographic puzzle. Although it withstood more than 14 years of use, Bitcoin has been criticized for escalating electricity consumption <ref>https://www.forbes.com/advisor/investing/cryptocurrency/bitcoins-energy-usage-explained/</ref>. Other blockchain designs have experienced different challenges. For example, the PoH network Solana suffered multiple single-point-failure incidents <ref>https://messari.io/report/solana-analyzing-downtimes-statistics-and-ecosystem-development</ref>. All protocols struggle to combat scaling challenges. All are susceptible to 51% attacks <ref>https://originstamp.com/blog/has-there-ever-been-a-51-attack-on-bitcoin/#notable-51-attacks</ref>.

Since 2009, Bitcoin has proven to be the strongest and least susceptible to common hacks <ref>https://www.theguardian.com/technology/2014/mar/18/history-of-bitcoin-hacks-alternative-currency</ref>. As the PoW puzzle difficulty has increased dramatically over the years, the probability of a 51% attack on the Bitcoin network becomes more difficult. PoS protocols can save more than 90% energy consumption compared to PoW chains. But PoS chains have higher risks than PoW chains since a stolen coin will grow in PoS chains (for increased probability to be selected) forever but not in PoW chains (only hash rates count). PoS community governance rules can mitigate the voting power centralization problem. Staking and slashing policies can incentivize good behaviors and punish bad ones. In either case, double-spend is very expensive and difficult. According to Forbes, there are 80 cryptocurrencies that use PoS protocols at the time of this writing.

There are approximately 1,000 blockchains in four types: public, private, consortium, and permissioned <ref>https://increditools.com/blockchains/</ref>.

== Cryptographic Proofs ==
Bitcoin 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.

== Centralized vs. Decentralized Applications ==
The Bitcoin protocol enabled decentralized processing of traditionally centrally processed transactions without any trusted third-party. It inspired many decentralized financial applications, especially for applications with very long payment chains. However for fraud prevention and meeting financial regulatory requirements, many practical applications still require KYC (know your customer) checks. It is not possible to eliminate all trusted third parties, especially for custodial financial applications. There is a clear need for decentralized processing of trusted authority applications.

== Blockchain Trilemma ==
Blockchain protocols have three common aspects (goals): '''security''', '''decentralization''' and '''scalability''' -- these three terms do not have precise definitions but are intuitively understood <ref>https://sensoriumxr.com/articles/what-is-the-blockchain-trilemma</ref>. To date, 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.

A major shortcoming is scalability. Since all nodes verify each transaction independently, they need to store all the information required for it. As the chain grows, this burdens all nodes in the network. There are workarounds by limiting the amount of data stored on some nodes and exploiting the network to retrieve required information, such as the ''Limited/Light Nodes'' in Bitcoin network. Vast majority nodes are still full nodes in the existing Bitcoin network. Transaction processing speed often expressed ''as transactions per second(TPS) of'' blockchain have to exceed TPS ratings of credit card payment systems like VISA or MasterCard to reap the full benefits of blockchain. This is a tough problem and increasing the block size and/or reducing the block time or difficulty isn't a solution<ref>https://medium.com/coinmonks/blockchain-scaling-30c9e1b7db1b</ref>. Since blockchain TPS is very low, the transaction fees is often very high. This discourages public adoption. Layer 2 solution like ''Lightning Network'' or ''ZK-rollups,'' where only final settlement is on the main chain tend to address these issues. However, one could always argue that this often compromises some aspects of security and/or decentralization to achieve high TPS.

The trilemma was first introduced by Vitalik Buterin<ref>https://en.wikipedia.org/wiki/Vitalik_Buterin</ref>, one of the co-founders of Ethereum network. The problems he identified are real. There seem to be no obvious solutions that can accomplish all three goals at the same time. Therefore, all proposed solutions revolve around reducing "opportunity costs" focusing only on satisfying partial goals.

Treating the blockchain network as an infrastructure for transaction processing, the blockchain protocol solved service reliability problem but not performance challenge. The legacy infrastructure scaling dilemma: performance against reliability remains (where "infrastructure reliability" also does not have a commonly accepted definition). Fortunately these metrics, although important, are non-critical. Solutions that have been proposed have had varying opportunity costs. For many years, there were no obvious solutions that addressed all three blockchain goals (security, decentralization and scalability).
== Statistic Multiplexed Computing (SMC) ==
The principle of using unreliable components to build an arbitrarily reliable system was first lectured by von Neumann in the early 1950s<ref>https://static.ias.edu/pitp/archive/2012files/Probabilistic_Logics.pdf</ref>. The original idea was to use probabilistic logic to quantify the arbitrary reliability of a system by multiplexing all components. This theory was applied to the construction of Internet protocols to deliver the "best effort" reliability. Incidentally, best effort reliability also enabled "best effort" performance which in turn enabled unlimited scalability of the Internet. For emerging web3.0 technologies, it is important to apply the same methodology to both centralized and decentralized computing for seamless technology migration and integration. For historical arguments, click [[SMC|'''''here''''']].

== Definitions ==
'''Infrastructure scalability''' does not have a commonly accepted definition. It helps to define the challenging metrics more precisely before the infrastructure protocol design. In the following, for definitions #1 and #2, the word "'''infrastructure'''" means any '''application running on the infrastructure.'''

# '''Infrastructure Reliability''': MTBF (mean time between failure) = <math>\frac{\sum ((Start-Of-Downtime) - (Start-of-uptime)) }{No-of-failures}</math>
# '''Infrastructure Performance''': <math>\frac{No-of-Transactions}{Second}</math>
# '''Infrastructure Scalability''': Expanding the infrastructure in number of processors, networks or storage should have '''incrementally better''' impacts on application reliability and performance.
# '''Record Immutability''': For transaction ledgers, all confirmed records and changes are final. This is required by the blockchain protocol.
Note that in practice, record immutability is much harder to achieve than expected. There are two challenges, a) 51% attacks can literally wipe out all histories if successful, and b) for protocols require all nodes to hold independently verified ledger, such as the Bitcoin, the storage requirement grows approximately 50GB per month.

== 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 and considered.

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 crashe'''s <ref>https://groups.csail.mit.edu/tds/papers/Lynch/jacm93.pdf</ref>. The laws of physics regarding component reliability <ref>Encyclopedia of Physical Science and Technology, Editor-in-Chief Robert A. Meyers, [[index.php?title=Special:BookSources/9780122274107|ISBN 978-0-12-227410-7]], 2001</ref> show that '''100% component reliability is not possible.''' These facts require that the infrastructure protocol (program-program communication protocol) provide '''complete component (processing, networking and storage) decoupling''' from application program logics. This decoupling requirement forces the protocol to exploit "decentralized" or "stateless" components that the legacy infrastructure protocols, such as message passing interface (MPI), remote procedure call (RPC) and remote method invocation (RMI), cannot handle. The blockchain protocol is an example of a "best effort" availability protocol.

Quantifying infrastructure reliability can be traced back to the computer pioneer von Neumann. In addition to his contribution to computer architecture, von Neumann also penned a study on building reliable systems using unreliable components using probabilistic logics, in early fifties <ref>https://static.ias.edu/pitp/archive/2012files/Probabilistic_Logics.pdf</ref>. The 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 "best effort" reliability. Ironically, this best effort reliability also enabled the Internet's infinite scalability -- the benefit we enjoy now and into the future.

The Bitcoin protocol exploits multiple anonymous decoupled (or decentralized) computers connected through the Internet protocol. Judging from the Bitcoin network's reliability to date <ref>https://buybitcoinworldwide.com/bitcoin-downtime/</ref>, von Neumann's theory seems working well.

The '''second challenge''' involves infrastructure performance. Since the infrastructure must deploy multiple computing, networking and storage components, unless all components can be fully exploited at 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 lack this capability.

'''The infrastructure scalability challenge''' is automatically resolved once the performance challenge is resolved without negatively impacting reliability -- "best effort" performance" meets "best effort reliability". This requires inductive performance and reliability measures or deliveries.

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, an inductive statistic multiplexed blockchain protocol is needed to meet the scalability challenge. Non-inductive solutions such as fixed chain "sharding" or "Danksharding" <ref>https://ethereum.org/en/roadmap/danksharding/</ref> will only increase protocol development complexity with persistent performance walls.

== A Scalability Solution ==
An effective scalability solution can have two practical assumptions:

* The computation problem size can expand indefinitely, since every useful infrastructure is expected to solve bigger problems.

*Computing and network resources will continue to grow indefinitely, into the future.
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 <ref>https://en.wikipedia.org/wiki/Amdahl%27s_law</ref> and Gustafson's Law <ref>https://en.wikipedia.org/wiki/Gustafson%27s_law</ref>.

The Amdahl's Law assumes 0<= ''s'' <=1 percentage of serial instructions that cannot be parallelized. Then the ''(1-s)'' percentage of instructions can be accelerated using ''p'' processors.

<div style="text-align: center;">
Speedup(p) = <math>{1 \over s + {(1-s) \over p}}</math> (1) <br>Speedup(<math>\lim_{p \to \infty}</math>) = <math>\frac{1}{s}</math> (2)
</div>
Taking ''p'' to infinity in equation (1) yields equation (2). But this derivation step has two different operational semantics: a) increasing ''p'' to reduce (''1-s)'' value while keeping the problem size fixed. This will result ''s'' asymptotically approaching 1. Thus the speedup is above founded to 1. Or b) increasing p to increase the parallel percentage ''(1-s)'' by solving bigger problems. This will force ''s'' asymptotically approach 0. Then the speedup is above bounded by <math>\infty</math>. This ambiguity caused more than three decades of confusion in the community.

Although quantifying ''s'' requires additional information, such as the problem size, the law is applicable to programs solving any problem size with a known ''s''. The limit of speedup (2) also does not depend on problem size. However, since Amdahl used programs solving fixed problem sizes to argue the validity of not building parallel machines with too many processors, assuming fixed problem size using ''p'' processors has been the norm in interpreting Amdahl's law in the past. This assumption has led to the dismal speedup predictions.[[File:Amdahl's Law.png|thumb|Amdahl's Law Speedup Predictions|center]]The traditional Amdahl's Law interpretation seems to suggest parallel performances following the economic law of diminishing of returns, even though the mathematic model implies more potentials.

In 1988, Gustafson and Barsis at the Sandia National Laboratory conducted parallel computing experiments that seem to suggest potential infinite speedup.

Gustafson's Law was based on measured sequential and parallel elapsed times using ''p'' (=1024) processors. A new sequential percentage ''0<=x'<=1'' can be calculated. ''(1-x')'' is the parallel percentage using ''p'' processors.

To estimate accomplished speedup, Gustafson's Law states:

<math>Speedup=\frac{Tseq}{Tpar}=\frac{s'+(1-s')p}{1}=s'+(1-s')p </math> (3)

Take ''p'' -> <math>\infty</math> for equation (3) also has two operational semantics: a) Keep the problem size fixed, adding processors to further reduce the total parallel processing time, thus bigger s'. This will yield s' approaching 1. Thus speedup = 1. Or b) expanding the problem size to allow the parallel part expand solving bigger problems. This will yield s' asymptotically approaching 0. Speedup will approaching ''p''. However, Gustafson's Law was used to argue for Massively Parallel Computing (MPC) experiments and Amdahl's Law was used to argue for bigger mainframe computer architectures. In the past decades, these laws have been used to support two diverging computing system experiments and constructions.
[[File:Gustafson.png|thumb|Gustafson's Law|center]]
A careful examination revealed that the Gustafson's Law cannot scale mathematically since the are mathematically dependent <ref>https://cis.temple.edu/~shi/wwwroot/shi/public_html/docs/amdahl/amdahl.html</ref> where Amdahl's formulation has a tight peak performance bound <math>\left ( \frac{1}{x} \right )</math> 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 <math>\left ( \frac{1}{x} \right )</math>, when <math>x \Rightarrow 0</math>, the performance will asymptotically approach to <math>\infty</math>, when <math>x \Rightarrow 1</math> the speedup <math>\Rightarrow</math> 1. Thus, if the computing problem's size is fixed, x will eventually approach to 1 as the number of processors increases -- economic law of diminishing of return. If the problem size is open (solving bigger problems), then increasing the number of processors will force x <math>\Rightarrow</math> 0, thus speedup <math>\Rightarrow</math> <math>\infty</math>. Gustafson's Law uses a recurrence relation based on practical time measurements. It is not possible to derive a mathematical speedup bound.

Applying these laws in practice need to quantify <math>\chi</math> for practical parallel program which has been proven very hard if not impossible. Gustafson's formula was derived from times by running actual parallel programs. Brining the two formulation together makes quantifying <math>\chi</math> in Amdahl's Law possible. Thus, both law actually refer to the same mathematical abstraction. Gustafson's formula assisted in quantifying the percentage of serial computing through program experiments. Neither should be directly used for speedup prediction alone.

This model can be validated in practice when developers simply increasing the problem size to use more parallel processors.
[[File:1overx-function resized.png|thumb|294x294px|Amdalh's Law and Peak Parallel Performance|center]]

A classical example is the TOP500 supercomputer benchmarks (linear solvers) that have open problem sizes for all manufacturers to compete in the world's fastest supercomputer race <ref>https://www.top500.org/</ref> .
[[File:Supercomputers-history.png|center|thumb]]
In practical blockchain applications, the number of transactions to be processed will increase without a known limit. The ledger storage will continue to grow. In practice, the available computing, networking and storage components will continue to grow without limits enabled by the networking protocols. Therefore a statistic multiplexed computing blockchain can meet any future application needs given proper economic incentives. The infrastructure no longer has the structural deficiency.

== Action Plan ==

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.

For Toichain protocol design, we choose Bitcoin 24.0.1 as the base line protocol by replacing the PoW consensus by PoS consensus and injecting SMC components into the protocol processing signaling for parallel computing.

This surprising result is also applicable to ledger storage. Without multiplexing, the blockchain ledger storage will eventually saturate all nodes causing the chain to collapse. The SMC blockchain protocol promises to hold the true finality of all transactions in perpetuity by multiplexing all storage resources while keeping the replication factor to a constant.

These discussions follow the inductive logic of the Law of Large Numbers <ref>https://www.sciencedirect.com/topics/mathematics/laws-of-large-number</ref>.

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

= SMC Proof of Stake Protocol =
Existing PoS protocol designs revolved around staking policies and randomness of the selection algorithm. Considering infrastructure scalability will add much complexity to the design. The examples include chain sharding and Danksharding <ref>https://ethereum.org/en/roadmap/danksharding/</ref>.

The challenge is complex -- we must deliver very high performance without compromising security and reliability of the network.

Technically, transaction replication and parallel processing were considered dangerous <ref>https://pages.cs.wisc.edu/~yxy/cs764-f20/papers/replication.pdf</ref> due to the potential race conditions (or double-spend problem). The blockchain protocol resolved the double-spending problem. It did not solve the parallel processing performance problem.

According to Professor Michael Flynn, there are three high-level parallel processing topologies: SIMD (single instruction multiple data), MIMD (multiple instructions multiple data), and pipeline (MISD - multiple instructions single data stream) <ref>https://link.springer.com/referenceworkentry/10.1007/978-0-387-09766-4_2</ref>. However, for eliminating double-spending, all transactions must be serialized, since each block may contain transactions affecting transactions in multiple other blocks. "Race conditions" and non-deterministic results are not allowed. Then the only possible topology entry is pipeline. This means for POS protocol, we must build a pipeline of transaction blocks to be validated without compromising network security and reliability.
[[File:Flynns-Taxonomy-of-Computer-Architectures.png|center|thumb|Parallel Processing Topologies]]
The problem is that the nature of the blockchain protocol is that all nodes run independently in parallel with little communication with other nodes via "gossip" protocols. It is far easier to force all nodes store the entire ledger than forcing them to form any pipeline and store partial chain data.

=== ACAN (Active Content Addressable Network) [U.S. and Other Patents Pending] ===
ACAN is a high-level data '''''communication and synchronization protocol''''' that completely decouples all hardware components from communicating programs. The need for complete component decoupling was implemented in the original blockchain protocol via "gossip" protocol. This delivered blockchain's high availability and security. The simple "gossip" implementation in existing protocols is insufficient for parallel processing signaling.

The following figure illustrates the concept of ACAN (active content addressable networking) using UVR (unidirectional virtual ring) architecture. The illustrated implementation uses the Tuple Space resource tagging method and gossip protocol for UVR implementation.
[[File:SMC Architecture with ACAN.png|center|thumb|243x243px|SMC Architecture with ACAN]]

ACAN supports three simple APIs:

# '''read'''(&''key'', &''value''): ''key'' holds a search pattern in a "tuple space" where all nodes are connected. ''value'' holds the matched tuple, if any. This is a blocking call that a requesting program will be blocked until a pattern-matched tuple is found. The matching tuple remains in the "tuple space".
# '''get'''(&key, &value): Same as the "read()" API, except that the matching tuple is removed from the "tuple space".
# '''put'''(key, value): Inserts <key, value> into the "tuple space".

The use of "gossip" protocol can accelerate ACAN network saturation time. Applications running on ACAN will automatically form parallel processing topologies: pipeline, SIMD and MIMD without violating the serialization needs of transaction block validation. Replication factor can also be dynamically controlled to spread replicated blocks in randomly chosen hosts.

The highly parallel nature of the blockchain protocol will automatically implement the SMC principle in real time.

The critical feature of this dynamic SMC pipelined architecture is the inductive scaling feature.
[[File:Pipeline Parallel Processing.png|center|thumb|247x247px|Pipeline Parallel Processing]]

The speed up of a pipeline can be represented as: <math>SpeedUp = \left ( \frac{p\centerdot b}{p + (b-p)} \right )</math>, where p = number of processors in the pipeline, b = total blocks to be processed. Take the number of blocks to infinity: <math>SpeedUp = \left ( \frac{p\centerdot b}{p + (b-p)} \right )=>\lim (b\Rightarrow\infty)(\frac{p}{\frac{p}{b}+1-\frac{p}{b}}) = p</math>

This means that as long as there are enough blocks to be processed, the entire chain's performance will be abound-bounded to the number of nodes in the pipeline.

For illustration purposes, the variation of block processing times was not considered in the above calculations. To see the power of pipeline parallelism, the automobile manufacturing processes illustrate a similar situation. The Hyundai Motor Company's production pipelines can produce 3,835 vehicles per day and 1.4M per year<ref>https://en.wikipedia.org/wiki/List_of_Hyundai_Motor_Company_manufacturing_facilities</ref>.

== Toichain Tokens ==
Toichain token is TOIN. There are 50,000,000,000 TOINs for the Alpha Release. There are air-drop tokens for early adopters, 1,000 TOIN each. Users need to register to download a toichain wallet to receive the payment. Citizenship is checked and verified to ensure that US citizens do not apply. The minimal staking contract is 10 TOINs.

== Non-Fungible Tokens ==
The TestNet Release of toichain protocol will support embedding arbitrary data in an "OP_RETURN" transaction that will be permanently recorded on the chain. Unlike the ordinal NFT <ref>https://blog.chain.link/ordinals-bitcoin-nfts/</ref> or NFT (non-fungible token) on other chains, these transactions cannot be altered or removed.

There are practical applications for these forever NFTs. Once Taproot is enabled on toichain, ordinal NFTs (BRC-20) will also be supported. Unlike the original Bitcoin network where BRC-20 craze has created massive network congestion<ref>https://beincrypto.com/learn/brc-20-token/</ref>, all transactions will be processed promptly in toichain without congestion or scaling problems.
== Toichain TestNet Launch ==
The toichain testnet launch will enable users to interact with one another through simple payments, just like the original Bitcoin network. Forever NFTs are supported. Smart contracts will be supported on a later date.

= References =
<references />

Consult the [[mediawikiwiki:Special:MyLanguage/Help:Contents|User's Guide]] for information on using the wiki software.

Main Page

2024-10-12T21:33:09Z

Justin: /* A Scalability Solution */

= <strong><big>'''Welcome to Toi-Twiki -- A Toichain Wiki'''</big></strong> =
This is the unofficial Toichain wiki site. Content is subject to changes.
---------------------------

= '''Introduction''' =
The blockchain protocol was introduced in a seminal paper entitled "Bitcoin: A peer-to-peer Electronic Cash System" <ref>https://bitcoin.org/bitcoin.pdf</ref> by Satoshi Nakamoto in 2008. Although there were previous peer-to-peer file-sharing projects such as Napster <ref>https://www.napster.com/us</ref>, BitTorrent <ref>https://www.bittorrent.com/</ref> and other electronic currency/file sharing applications, Bitcoin is the most enduring among the 23,000+ blockchains. Unlike other cryptocurrencies, the Bitcoin is often referred to as "digital gold" since the total coin supply is limited to 21 million (hard-coded in all running programs) and the only way to earn coin is to participate in the transaction block validation process. Token(or coin) supply and their disbursement policies differ among protocols.

The most attractive common blockchain features are 1) a decentralized consensus-driven decision making process and 2) a step-by-step cryptographic proving system. While blockchain is best known as a cryptocurrency transaction processing and record-keeping system, there are many other applications that can benefit from the secure storage, reliable transaction ledgers, fault tolerance and tamper resistance features.

== Algorithm vs. Protocol ==
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 ==
A good consensus protocol in a blockchain system has at least four properties:

# Fault tolerance to defend failures caused by natural disasters and human hacks or accidents
# Byzantine failure tolerance to defend exploitation by colluding parties
# Centralization avoidance to prevent corruptions in the decision making process
# Source code tamper resistance to automatically reject malicious attacks

Without assuming all nodes are active at all times, the blockchain relies on "gossip" protocol to communicate with other nodes. There are two popular types of consensus protocols: Proof of Work ('''PoW''') <ref>https://en.wikipedia.org/wiki/Proof_of_work</ref> or Proof of Stake ('''PoS''') <ref>https://www.investopedia.com/terms/p/proof-stake-pos.asp</ref>. Others include Proof of Possession('''PoP''')<ref>https://identityserver4.readthedocs.io/en/latest/topics/pop.html</ref> and Proof of History('''PoH''')<ref>https://www.infoworld.com/article/3666736/solana-blockchain-and-the-proof-of-history.html</ref>. The ultimate goal is to eliminate double-spending. Since most projects are open source, it's easy for a malicious actor to tamper a few nodes. This shouldn't compromise network integrity.

The Bitcoin network uses PoW which forces participating miners to compete for the fastest hashing rate by solving a computational cryptographic puzzle. Although it withstood more than 14 years of use, Bitcoin has been criticized for escalating electricity consumption <ref>https://www.forbes.com/advisor/investing/cryptocurrency/bitcoins-energy-usage-explained/</ref>. Other blockchain designs have experienced different challenges. For example, the PoH network Solana suffered multiple single-point-failure incidents <ref>https://messari.io/report/solana-analyzing-downtimes-statistics-and-ecosystem-development</ref>. All protocols struggle to combat scaling challenges. All are susceptible to 51% attacks <ref>https://originstamp.com/blog/has-there-ever-been-a-51-attack-on-bitcoin/#notable-51-attacks</ref>.

Since 2009, Bitcoin has proven to be the strongest and least susceptible to common hacks <ref>https://www.theguardian.com/technology/2014/mar/18/history-of-bitcoin-hacks-alternative-currency</ref>. As the PoW puzzle difficulty has increased dramatically over the years, the probability of a 51% attack on the Bitcoin network becomes more difficult. PoS protocols can save more than 90% energy consumption compared to PoW chains. But PoS chains have higher risks than PoW chains since a stolen coin will grow in PoS chains (for increased probability to be selected) forever but not in PoW chains (only hash rates count). PoS community governance rules can mitigate the voting power centralization problem. Staking and slashing policies can incentivize good behaviors and punish bad ones. In either case, double-spend is very expensive and difficult. According to Forbes, there are 80 cryptocurrencies that use PoS protocols at the time of this writing.

There are approximately 1,000 blockchains in four types: public, private, consortium, and permissioned <ref>https://increditools.com/blockchains/</ref>.

== Cryptographic Proofs ==
Bitcoin 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.

== Centralized vs. Decentralized Applications ==
The Bitcoin protocol enabled decentralized processing of traditionally centrally processed transactions without any trusted third-party. It inspired many decentralized financial applications, especially for applications with very long payment chains. However for fraud prevention and meeting financial regulatory requirements, many practical applications still require KYC (know your customer) checks. It is not possible to eliminate all trusted third parties, especially for custodial financial applications. There is a clear need for decentralized processing of trusted authority applications.

== Blockchain Trilemma ==
Blockchain protocols have three common aspects (goals): '''security''', '''decentralization''' and '''scalability''' -- these three terms do not have precise definitions but are intuitively understood <ref>https://sensoriumxr.com/articles/what-is-the-blockchain-trilemma</ref>. To date, 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.

A major shortcoming is scalability. Since all nodes verify each transaction independently, they need to store all the information required for it. As the chain grows, this burdens all nodes in the network. There are workarounds by limiting the amount of data stored on some nodes and exploiting the network to retrieve required information, such as the ''Limited/Light Nodes'' in Bitcoin network. Vast majority nodes are still full nodes in the existing Bitcoin network. Transaction processing speed often expressed ''as transactions per second(TPS) of'' blockchain have to exceed TPS ratings of credit card payment systems like VISA or MasterCard to reap the full benefits of blockchain. This is a tough problem and increasing the block size and/or reducing the block time or difficulty isn't a solution<ref>https://medium.com/coinmonks/blockchain-scaling-30c9e1b7db1b</ref>. Since blockchain TPS is very low, the transaction fees is often very high. This discourages public adoption. Layer 2 solution like ''Lightning Network'' or ''ZK-rollups,'' where only final settlement is on the main chain tend to address these issues. However, one could always argue that this often compromises some aspects of security and/or decentralization to achieve high TPS.

The trilemma was first introduced by Vitalik Buterin<ref>https://en.wikipedia.org/wiki/Vitalik_Buterin</ref>, one of the co-founders of Ethereum network. The problems he identified are real. There seem to be no obvious solutions that can accomplish all three goals at the same time. Therefore, all proposed solutions revolve around reducing "opportunity costs" focusing only on satisfying partial goals.

Treating the blockchain network as an infrastructure for transaction processing, the blockchain protocol solved service reliability problem but not performance challenge. The legacy infrastructure scaling dilemma: performance against reliability remains (where "infrastructure reliability" also does not have a commonly accepted definition). Fortunately these metrics, although important, are non-critical. Solutions that have been proposed have had varying opportunity costs. For many years, there were no obvious solutions that addressed all three blockchain goals (security, decentralization and scalability).
== Statistic Multiplexed Computing (SMC) ==
The principle of using unreliable components to build an arbitrarily reliable system was first lectured by von Neumann in the early 1950s<ref>https://static.ias.edu/pitp/archive/2012files/Probabilistic_Logics.pdf</ref>. The original idea was to use probabilistic logic to quantify the arbitrary reliability of a system by multiplexing all components. This theory was applied to the construction of Internet protocols to deliver the "best effort" reliability. Incidentally, best effort reliability also enabled "best effort" performance which in turn enabled unlimited scalability of the Internet. For emerging web3.0 technologies, it is important to apply the same methodology to both centralized and decentralized computing for seamless technology migration and integration. For historical arguments, click [[SMC|'''''here''''']].

== Definitions ==
'''Infrastructure scalability''' does not have a commonly accepted definition. It helps to define the challenging metrics more precisely before the infrastructure protocol design. In the following, for definitions #1 and #2, the word "'''infrastructure'''" means any '''application running on the infrastructure.'''

# '''Infrastructure Reliability''': MTBF (mean time between failure) = <math>\frac{\sum ((Start-Of-Downtime) - (Start-of-uptime)) }{No-of-failures}</math>
# '''Infrastructure Performance''': <math>\frac{No-of-Transactions}{Second}</math>
# '''Infrastructure Scalability''': Expanding the infrastructure in number of processors, networks or storage should have '''incrementally better''' impacts on application reliability and performance.
# '''Record Immutability''': For transaction ledgers, all confirmed records and changes are final. This is required by the blockchain protocol.
Note that in practice, record immutability is much harder to achieve than expected. There are two challenges, a) 51% attacks can literally wipe out all histories if successful, and b) for protocols require all nodes to hold independently verified ledger, such as the Bitcoin, the storage requirement grows approximately 50GB per month.

== 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 and considered.

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 crashe'''s <ref>https://groups.csail.mit.edu/tds/papers/Lynch/jacm93.pdf</ref>. The laws of physics regarding component reliability <ref>Encyclopedia of Physical Science and Technology, Editor-in-Chief Robert A. Meyers, [[index.php?title=Special:BookSources/9780122274107|ISBN 978-0-12-227410-7]], 2001</ref> show that '''100% component reliability is not possible.''' These facts require that the infrastructure protocol (program-program communication protocol) provide '''complete component (processing, networking and storage) decoupling''' from application program logics. This decoupling requirement forces the protocol to exploit "decentralized" or "stateless" components that the legacy infrastructure protocols, such as message passing interface (MPI), remote procedure call (RPC) and remote method invocation (RMI), cannot handle. The blockchain protocol is an example of a "best effort" availability protocol.

Quantifying infrastructure reliability can be traced back to the computer pioneer von Neumann. In addition to his contribution to computer architecture, von Neumann also penned a study on building reliable systems using unreliable components using probabilistic logics, in early fifties <ref>https://static.ias.edu/pitp/archive/2012files/Probabilistic_Logics.pdf</ref>. The 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 "best effort" reliability. Ironically, this best effort reliability also enabled the Internet's infinite scalability -- the benefit we enjoy now and into the future.

The Bitcoin protocol exploits multiple anonymous decoupled (or decentralized) computers connected through the Internet protocol. Judging from the Bitcoin network's reliability to date <ref>https://buybitcoinworldwide.com/bitcoin-downtime/</ref>, von Neumann's theory seems working well.

The '''second challenge''' involves infrastructure performance. Since the infrastructure must deploy multiple computing, networking and storage components, unless all components can be fully exploited at 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 lack this capability.

'''The infrastructure scalability challenge''' is automatically resolved once the performance challenge is resolved without negatively impacting reliability -- "best effort" performance" meets "best effort reliability". This requires inductive performance and reliability measures or deliveries.

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, an inductive statistic multiplexed blockchain protocol is needed to meet the scalability challenge. Non-inductive solutions such as fixed chain "sharding" or "Danksharding" <ref>https://ethereum.org/en/roadmap/danksharding/</ref> will only increase protocol development complexity with persistent performance walls.

== A Scalability Solution ==
An effective scalability solution can have two practical assumptions:

* The computation problem size can expand indefinitely, since every useful infrastructure is expected to solve bigger problems.

*Computing and network resources will continue to grow indefinitely, into the future.
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 <ref>https://en.wikipedia.org/wiki/Amdahl%27s_law</ref> and Gustafson's Law <ref>https://en.wikipedia.org/wiki/Gustafson%27s_law</ref>.

The Amdahl's Law assumes 0<= ''s'' <=1 percentage of serial instructions that cannot be parallelized. Then the ''(1-s)'' percentage of instructions can be accelerated using ''p'' processors.

<div style="text-align: center;">
Speedup(p) = <math>{1 \over s + {(1-s) \over p}}</math> (1) <br>Speedup(<math>\lim_{p \to \infty}</math>) = <math>\frac{1}{s}</math> (2)
</div>
Taking ''p'' to infinity in equation (1) yields equation (2). But this derivation step has two different operational semantics: a) increasing ''p'' to reduce (''1-s)'' value while keeping the problem size fixed. This will result ''s'' asymptotically approaching 1. Thus the speedup is above founded to 1. Or b) increasing p to increase the parallel percentage ''(1-s)'' by solving bigger problems. This will force ''s'' asymptotically approach 0. Then the speedup is above bounded by <math>\infty</math>. This ambiguity caused more than three decades of confusion in the community.

Although quantifying ''s'' requires additional information, such as the problem size, the law is applicable to programs solving any problem size with a known ''s''. The limit of speedup (2) also does not depend on problem size. However, Amdahl used programs solving fixed problem sizes to argue the validity of not building parallel machines with too many processors. Since then assuming fixed problem size using p processors has been the norm in interpreting Amdahl's law in the past. This assumption has led to the dismal speedup predictions.[[File:Amdahl's Law.png|thumb|Amdahl's Law Speedup Predictions|center]]The traditional Amdahl's Law interpretation seems to suggest parallel performances following the economic law of diminishing of returns, even though the mathematic model implies more potentials.

In 1988, Gustafson and Barsis at the Sandia National Laboratory conducted parallel computing experiments that seem to suggest potential infinite speedup.

Gustafson's Law was based on measured sequential and parallel elapsed times using ''p'' (=1024) processors. A new sequential percentage 0<=x'<=1 can be calculated. (1-x') is the parallel percentage.

To estimated accomplished speedup, Gustafson's Law states:

propose to estimate the squential running times byhere was no pure sequential running time measure
Gustafson's while Gustafson's Law seems to lead to 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 mainframe computer architectures. In the past decades, these laws have been used to support computing system experiments and constructions.
[[File:Gustafson.png|thumb|Gustafson's Law|center]]
A careful examination revealed that the Gustafson's Law cannot scale mathematically since the are mathematically dependent <ref>https://cis.temple.edu/~shi/wwwroot/shi/public_html/docs/amdahl/amdahl.html</ref> where Amdahl's formulation has a tight peak performance bound <math>\left ( \frac{1}{x} \right )</math> 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 <math>\left ( \frac{1}{x} \right )</math>, when <math>x \Rightarrow 0</math>, the performance will asymptotically approach to <math>\infty</math>, when <math>x \Rightarrow 1</math> the speedup <math>\Rightarrow</math> 1. Thus, if the computing problem's size is fixed, x will eventually approach to 1 as the number of processors increases -- economic law of diminishing of return. If the problem size is open (solving bigger problems), then increasing the number of processors will force x <math>\Rightarrow</math> 0, thus speedup <math>\Rightarrow</math> <math>\infty</math>. Gustafson's Law uses a recurrence relation based on practical time measurements. It is not possible to derive a mathematical speedup bound.

Applying these laws in practice need to quantify <math>\chi</math> for practical parallel program which has been proven very hard if not impossible. Gustafson's formula was derived from times by running actual parallel programs. Brining the two formulation together makes quantifying <math>\chi</math> in Amdahl's Law possible. Thus, both law actually refer to the same mathematical abstraction. Gustafson's formula assisted in quantifying the percentage of serial computing through program experiments. Neither should be directly used for speedup prediction alone.

This model can be validated in practice when developers simply increasing the problem size to use more parallel processors.
[[File:1overx-function resized.png|thumb|294x294px|Amdalh's Law and Peak Parallel Performance|center]]

A classical example is the TOP500 supercomputer benchmarks (linear solvers) that have open problem sizes for all manufacturers to compete in the world's fastest supercomputer race <ref>https://www.top500.org/</ref> .
[[File:Supercomputers-history.png|center|thumb]]
In practical blockchain applications, the number of transactions to be processed will increase without a known limit. The ledger storage will continue to grow. In practice, the available computing, networking and storage components will continue to grow without limits enabled by the networking protocols. Therefore a statistic multiplexed computing blockchain can meet any future application needs given proper economic incentives. The infrastructure no longer has the structural deficiency.

== Action Plan ==

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.

For Toichain protocol design, we choose Bitcoin 24.0.1 as the base line protocol by replacing the PoW consensus by PoS consensus and injecting SMC components into the protocol processing signaling for parallel computing.

This surprising result is also applicable to ledger storage. Without multiplexing, the blockchain ledger storage will eventually saturate all nodes causing the chain to collapse. The SMC blockchain protocol promises to hold the true finality of all transactions in perpetuity by multiplexing all storage resources while keeping the replication factor to a constant.

These discussions follow the inductive logic of the Law of Large Numbers <ref>https://www.sciencedirect.com/topics/mathematics/laws-of-large-number</ref>.

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

= SMC Proof of Stake Protocol =
Existing PoS protocol designs revolved around staking policies and randomness of the selection algorithm. Considering infrastructure scalability will add much complexity to the design. The examples include chain sharding and Danksharding <ref>https://ethereum.org/en/roadmap/danksharding/</ref>.

The challenge is complex -- we must deliver very high performance without compromising security and reliability of the network.

Technically, transaction replication and parallel processing were considered dangerous <ref>https://pages.cs.wisc.edu/~yxy/cs764-f20/papers/replication.pdf</ref> due to the potential race conditions (or double-spend problem). The blockchain protocol resolved the double-spending problem. It did not solve the parallel processing performance problem.

According to Professor Michael Flynn, there are three high-level parallel processing topologies: SIMD (single instruction multiple data), MIMD (multiple instructions multiple data), and pipeline (MISD - multiple instructions single data stream) <ref>https://link.springer.com/referenceworkentry/10.1007/978-0-387-09766-4_2</ref>. However, for eliminating double-spending, all transactions must be serialized, since each block may contain transactions affecting transactions in multiple other blocks. "Race conditions" and non-deterministic results are not allowed. Then the only possible topology entry is pipeline. This means for POS protocol, we must build a pipeline of transaction blocks to be validated without compromising network security and reliability.
[[File:Flynns-Taxonomy-of-Computer-Architectures.png|center|thumb|Parallel Processing Topologies]]
The problem is that the nature of the blockchain protocol is that all nodes run independently in parallel with little communication with other nodes via "gossip" protocols. It is far easier to force all nodes store the entire ledger than forcing them to form any pipeline and store partial chain data.

=== ACAN (Active Content Addressable Network) [U.S. and Other Patents Pending] ===
ACAN is a high-level data '''''communication and synchronization protocol''''' that completely decouples all hardware components from communicating programs. The need for complete component decoupling was implemented in the original blockchain protocol via "gossip" protocol. This delivered blockchain's high availability and security. The simple "gossip" implementation in existing protocols is insufficient for parallel processing signaling.

The following figure illustrates the concept of ACAN (active content addressable networking) using UVR (unidirectional virtual ring) architecture. The illustrated implementation uses the Tuple Space resource tagging method and gossip protocol for UVR implementation.
[[File:SMC Architecture with ACAN.png|center|thumb|243x243px|SMC Architecture with ACAN]]

ACAN supports three simple APIs:

# '''read'''(&''key'', &''value''): ''key'' holds a search pattern in a "tuple space" where all nodes are connected. ''value'' holds the matched tuple, if any. This is a blocking call that a requesting program will be blocked until a pattern-matched tuple is found. The matching tuple remains in the "tuple space".
# '''get'''(&key, &value): Same as the "read()" API, except that the matching tuple is removed from the "tuple space".
# '''put'''(key, value): Inserts <key, value> into the "tuple space".

The use of "gossip" protocol can accelerate ACAN network saturation time. Applications running on ACAN will automatically form parallel processing topologies: pipeline, SIMD and MIMD without violating the serialization needs of transaction block validation. Replication factor can also be dynamically controlled to spread replicated blocks in randomly chosen hosts.

The highly parallel nature of the blockchain protocol will automatically implement the SMC principle in real time.

The critical feature of this dynamic SMC pipelined architecture is the inductive scaling feature.
[[File:Pipeline Parallel Processing.png|center|thumb|247x247px|Pipeline Parallel Processing]]

The speed up of a pipeline can be represented as: <math>SpeedUp = \left ( \frac{p\centerdot b}{p + (b-p)} \right )</math>, where p = number of processors in the pipeline, b = total blocks to be processed. Take the number of blocks to infinity: <math>SpeedUp = \left ( \frac{p\centerdot b}{p + (b-p)} \right )=>\lim (b\Rightarrow\infty)(\frac{p}{\frac{p}{b}+1-\frac{p}{b}}) = p</math>

This means that as long as there are enough blocks to be processed, the entire chain's performance will be abound-bounded to the number of nodes in the pipeline.

For illustration purposes, the variation of block processing times was not considered in the above calculations. To see the power of pipeline parallelism, the automobile manufacturing processes illustrate a similar situation. The Hyundai Motor Company's production pipelines can produce 3,835 vehicles per day and 1.4M per year<ref>https://en.wikipedia.org/wiki/List_of_Hyundai_Motor_Company_manufacturing_facilities</ref>.

== Toichain Tokens ==
Toichain token is TOIN. There are 50,000,000,000 TOINs for the Alpha Release. There are air-drop tokens for early adopters, 1,000 TOIN each. Users need to register to download a toichain wallet to receive the payment. Citizenship is checked and verified to ensure that US citizens do not apply. The minimal staking contract is 10 TOINs.

== Non-Fungible Tokens ==
The TestNet Release of toichain protocol will support embedding arbitrary data in an "OP_RETURN" transaction that will be permanently recorded on the chain. Unlike the ordinal NFT <ref>https://blog.chain.link/ordinals-bitcoin-nfts/</ref> or NFT (non-fungible token) on other chains, these transactions cannot be altered or removed.

There are practical applications for these forever NFTs. Once Taproot is enabled on toichain, ordinal NFTs (BRC-20) will also be supported. Unlike the original Bitcoin network where BRC-20 craze has created massive network congestion<ref>https://beincrypto.com/learn/brc-20-token/</ref>, all transactions will be processed promptly in toichain without congestion or scaling problems.
== Toichain TestNet Launch ==
The toichain testnet launch will enable users to interact with one another through simple payments, just like the original Bitcoin network. Forever NFTs are supported. Smart contracts will be supported on a later date.

= References =
<references />

Consult the [[mediawikiwiki:Special:MyLanguage/Help:Contents|User's Guide]] for information on using the wiki software.

File:Full Range Amdah's Law .png

2024-10-12T18:36:47Z

Justin:

Full power of Amdahl's Law

Main Page

2024-10-05T19:39:26Z

Justin: /* A Scalability Solution */

= <strong><big>'''Welcome to Toi-Twiki -- A Toichain Wiki'''</big></strong> =
This is the unofficial Toichain wiki site. Content is subject to changes.
---------------------------

= '''Introduction''' =
The blockchain protocol was introduced in a seminal paper entitled "Bitcoin: A peer-to-peer Electronic Cash System" <ref>https://bitcoin.org/bitcoin.pdf</ref> by Satoshi Nakamoto in 2008. Although there were previous peer-to-peer file-sharing projects such as Napster <ref>https://www.napster.com/us</ref>, BitTorrent <ref>https://www.bittorrent.com/</ref> and other electronic currency/file sharing applications, Bitcoin is the most enduring among the 23,000+ blockchains. Unlike other cryptocurrencies, the Bitcoin is often referred to as "digital gold" since the total coin supply is limited to 21 million (hard-coded in all running programs) and the only way to earn coin is to participate in the transaction block validation process. Token(or coin) supply and their disbursement policies differ among protocols.

The most attractive common blockchain features are 1) a decentralized consensus-driven decision making process and 2) a step-by-step cryptographic proving system. While blockchain is best known as a cryptocurrency transaction processing and record-keeping system, there are many other applications that can benefit from the secure storage, reliable transaction ledgers, fault tolerance and tamper resistance features.

== Algorithm vs. Protocol ==
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 ==
A good consensus protocol in a blockchain system has at least four properties:

# Fault tolerance to defend failures caused by natural disasters and human hacks or accidents
# Byzantine failure tolerance to defend exploitation by colluding parties
# Centralization avoidance to prevent corruptions in the decision making process
# Source code tamper resistance to automatically reject malicious attacks

Without assuming all nodes are active at all times, the blockchain relies on "gossip" protocol to communicate with other nodes. There are two popular types of consensus protocols: Proof of Work ('''PoW''') <ref>https://en.wikipedia.org/wiki/Proof_of_work</ref> or Proof of Stake ('''PoS''') <ref>https://www.investopedia.com/terms/p/proof-stake-pos.asp</ref>. Others include Proof of Possession('''PoP''')<ref>https://identityserver4.readthedocs.io/en/latest/topics/pop.html</ref> and Proof of History('''PoH''')<ref>https://www.infoworld.com/article/3666736/solana-blockchain-and-the-proof-of-history.html</ref>. The ultimate goal is to eliminate double-spending. Since most projects are open source, it's easy for a malicious actor to tamper a few nodes. This shouldn't compromise network integrity.

The Bitcoin network uses PoW which forces participating miners to compete for the fastest hashing rate by solving a computational cryptographic puzzle. Although it withstood more than 14 years of use, Bitcoin has been criticized for escalating electricity consumption <ref>https://www.forbes.com/advisor/investing/cryptocurrency/bitcoins-energy-usage-explained/</ref>. Other blockchain designs have experienced different challenges. For example, the PoH network Solana suffered multiple single-point-failure incidents <ref>https://messari.io/report/solana-analyzing-downtimes-statistics-and-ecosystem-development</ref>. All protocols struggle to combat scaling challenges. All are susceptible to 51% attacks <ref>https://originstamp.com/blog/has-there-ever-been-a-51-attack-on-bitcoin/#notable-51-attacks</ref>.

Since 2009, Bitcoin has proven to be the strongest and least susceptible to common hacks <ref>https://www.theguardian.com/technology/2014/mar/18/history-of-bitcoin-hacks-alternative-currency</ref>. As the PoW puzzle difficulty has increased dramatically over the years, the probability of a 51% attack on the Bitcoin network becomes more difficult. PoS protocols can save more than 90% energy consumption compared to PoW chains. But PoS chains have higher risks than PoW chains since a stolen coin will grow in PoS chains (for increased probability to be selected) forever but not in PoW chains (only hash rates count). PoS community governance rules can mitigate the voting power centralization problem. Staking and slashing policies can incentivize good behaviors and punish bad ones. In either case, double-spend is very expensive and difficult. According to Forbes, there are 80 cryptocurrencies that use PoS protocols at the time of this writing.

There are approximately 1,000 blockchains in four types: public, private, consortium, and permissioned <ref>https://increditools.com/blockchains/</ref>.

== Cryptographic Proofs ==
Bitcoin 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.

== Centralized vs. Decentralized Applications ==
The Bitcoin protocol enabled decentralized processing of traditionally centrally processed transactions without any trusted third-party. It inspired many decentralized financial applications, especially for applications with very long payment chains. However for fraud prevention and meeting financial regulatory requirements, many practical applications still require KYC (know your customer) checks. It is not possible to eliminate all trusted third parties, especially for custodial financial applications. There is a clear need for decentralized processing of trusted authority applications.

== Blockchain Trilemma ==
Blockchain protocols have three common aspects (goals): '''security''', '''decentralization''' and '''scalability''' -- these three terms do not have precise definitions but are intuitively understood <ref>https://sensoriumxr.com/articles/what-is-the-blockchain-trilemma</ref>. To date, 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.

A major shortcoming is scalability. Since all nodes verify each transaction independently, they need to store all the information required for it. As the chain grows, this burdens all nodes in the network. There are workarounds by limiting the amount of data stored on some nodes and exploiting the network to retrieve required information, such as the ''Limited/Light Nodes'' in Bitcoin network. Vast majority nodes are still full nodes in the existing Bitcoin network. Transaction processing speed often expressed ''as transactions per second(TPS) of'' blockchain have to exceed TPS ratings of credit card payment systems like VISA or MasterCard to reap the full benefits of blockchain. This is a tough problem and increasing the block size and/or reducing the block time or difficulty isn't a solution<ref>https://medium.com/coinmonks/blockchain-scaling-30c9e1b7db1b</ref>. Since blockchain TPS is very low, the transaction fees is often very high. This discourages public adoption. Layer 2 solution like ''Lightning Network'' or ''ZK-rollups,'' where only final settlement is on the main chain tend to address these issues. However, one could always argue that this often compromises some aspects of security and/or decentralization to achieve high TPS.

The trilemma was first introduced by Vitalik Buterin<ref>https://en.wikipedia.org/wiki/Vitalik_Buterin</ref>, one of the co-founders of Ethereum network. The problems he identified are real. There seem to be no obvious solutions that can accomplish all three goals at the same time. Therefore, all proposed solutions revolve around reducing "opportunity costs" focusing only on satisfying partial goals.

Treating the blockchain network as an infrastructure for transaction processing, the blockchain protocol solved service reliability problem but not performance challenge. The legacy infrastructure scaling dilemma: performance against reliability remains (where "infrastructure reliability" also does not have a commonly accepted definition). Fortunately these metrics, although important, are non-critical. Solutions that have been proposed have had varying opportunity costs. For many years, there were no obvious solutions that addressed all three blockchain goals (security, decentralization and scalability).
== Statistic Multiplexed Computing (SMC) ==
The principle of using unreliable components to build an arbitrarily reliable system was first lectured by von Neumann in the early 1950s<ref>https://static.ias.edu/pitp/archive/2012files/Probabilistic_Logics.pdf</ref>. The original idea was to use probabilistic logic to quantify the arbitrary reliability of a system by multiplexing all components. This theory was applied to the construction of Internet protocols to deliver the "best effort" reliability. Incidentally, best effort reliability also enabled "best effort" performance which in turn enabled unlimited scalability of the Internet. For emerging web3.0 technologies, it is important to apply the same methodology to both centralized and decentralized computing for seamless technology migration and integration. For historical arguments, click [[SMC|'''''here''''']].

== Definitions ==
'''Infrastructure scalability''' does not have a commonly accepted definition. It helps to define the challenging metrics more precisely before the infrastructure protocol design. In the following, for definitions #1 and #2, the word "'''infrastructure'''" means any '''application running on the infrastructure.'''

# '''Infrastructure Reliability''': MTBF (mean time between failure) = <math>\frac{\sum ((Start-Of-Downtime) - (Start-of-uptime)) }{No-of-failures}</math>
# '''Infrastructure Performance''': <math>\frac{No-of-Transactions}{Second}</math>
# '''Infrastructure Scalability''': Expanding the infrastructure in number of processors, networks or storage should have '''incrementally better''' impacts on application reliability and performance.
# '''Record Immutability''': For transaction ledgers, all confirmed records and changes are final. This is required by the blockchain protocol.
Note that in practice, record immutability is much harder to achieve than expected. There are two challenges, a) 51% attacks can literally wipe out all histories if successful, and b) for protocols require all nodes to hold independently verified ledger, such as the Bitcoin, the storage requirement grows approximately 50GB per month.

== 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 and considered.

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 crashe'''s <ref>https://groups.csail.mit.edu/tds/papers/Lynch/jacm93.pdf</ref>. The laws of physics regarding component reliability <ref>Encyclopedia of Physical Science and Technology, Editor-in-Chief Robert A. Meyers, [[index.php?title=Special:BookSources/9780122274107|ISBN 978-0-12-227410-7]], 2001</ref> show that '''100% component reliability is not possible.''' These facts require that the infrastructure protocol (program-program communication protocol) provide '''complete component (processing, networking and storage) decoupling''' from application program logics. This decoupling requirement forces the protocol to exploit "decentralized" or "stateless" components that the legacy infrastructure protocols, such as message passing interface (MPI), remote procedure call (RPC) and remote method invocation (RMI), cannot handle. The blockchain protocol is an example of a "best effort" availability protocol.

Quantifying infrastructure reliability can be traced back to the computer pioneer von Neumann. In addition to his contribution to computer architecture, von Neumann also penned a study on building reliable systems using unreliable components using probabilistic logics, in early fifties <ref>https://static.ias.edu/pitp/archive/2012files/Probabilistic_Logics.pdf</ref>. The 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 "best effort" reliability. Ironically, this best effort reliability also enabled the Internet's infinite scalability -- the benefit we enjoy now and into the future.

The Bitcoin protocol exploits multiple anonymous decoupled (or decentralized) computers connected through the Internet protocol. Judging from the Bitcoin network's reliability to date <ref>https://buybitcoinworldwide.com/bitcoin-downtime/</ref>, von Neumann's theory seems working well.

The '''second challenge''' involves infrastructure performance. Since the infrastructure must deploy multiple computing, networking and storage components, unless all components can be fully exploited at 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 lack this capability.

'''The infrastructure scalability challenge''' is automatically resolved once the performance challenge is resolved without negatively impacting reliability -- "best effort" performance" meets "best effort reliability". This requires inductive performance and reliability measures or deliveries.

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, an inductive statistic multiplexed blockchain protocol is needed to meet the scalability challenge. Non-inductive solutions such as fixed chain "sharding" or "Danksharding" <ref>https://ethereum.org/en/roadmap/danksharding/</ref> will only increase protocol development complexity with persistent performance walls.

== A Scalability Solution ==
An effective scalability solution can have two practical assumptions:

* The computation problem size can expand indefinitely, since every useful infrastructure is expected to solve bigger problems.

*Computing and network resources will continue to grow indefinitely, into the future.
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 <ref>https://en.wikipedia.org/wiki/Amdahl%27s_law</ref> and Gustafson's Law <ref>https://en.wikipedia.org/wiki/Gustafson%27s_law</ref>.

The Amdahl's Law assumes 0<= ''s'' <=1 percentage of serial instructions that cannot be parallelized. Then the ''(1-s)'' percentage of instructions can be accelerated using ''p'' processors.

<div style="text-align: center;">
Speedup(p) = <math>{1 \over s + {(1-s) \over p}}</math> (1) <br>
Speedup(<math>\lim_{p \to \infty}</math>) = <math>\frac{1}{s}</math> (2)
</div>
Although quantifying ''s'' requires additional information, such as the problem size, the law is applicable to programs solving any problem size with a known ''s''. The limit of speedup (2) also does not depend on problem size. However, Amdahl used programs solving fixed problem sizes to argue the validity of not building parallel machines with too many processors. Since then assuming fixed problem size using p processors has been the norm in interpreting Amdahl's law in the past. This assumption has led to the dismal speedup predictions.[[File:Amdahl's Law.png|thumb|Amdahl's Law Speedup Predictions|center]]The traditional Amdahl's Law interpretation seems to suggest parallel performances following the economic law of diminishing of returns.

In 1988, Gustafson and Barsis at the Sandia National Laboratory conducted parallel computing experiments that seem to suggest potential infinite speedup.

Gustafson's while Gustafson's Law seems to lead to 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 mainframe computer architectures. In the past decades, these laws have been used to support computing system experiments and constructions.
[[File:Gustafson.png|thumb|Gustafson's Law|center]]
A careful examination revealed that the Gustafson's Law cannot scale mathematically since the are mathematically dependent <ref>https://cis.temple.edu/~shi/wwwroot/shi/public_html/docs/amdahl/amdahl.html</ref> where Amdahl's formulation has a tight peak performance bound <math>\left ( \frac{1}{x} \right )</math> 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 <math>\left ( \frac{1}{x} \right )</math>, when <math>x \Rightarrow 0</math>, the performance will asymptotically approach to <math>\infty</math>, when <math>x \Rightarrow 1</math> the speedup <math>\Rightarrow</math> 1. Thus, if the computing problem's size is fixed, x will eventually approach to 1 as the number of processors increases -- economic law of diminishing of return. If the problem size is open (solving bigger problems), then increasing the number of processors will force x <math>\Rightarrow</math> 0, thus speedup <math>\Rightarrow</math> <math>\infty</math>. Gustafson's Law uses a recurrence relation based on practical time measurements. It is not possible to derive a mathematical speedup bound.

Applying these laws in practice need to quantify <math>\chi</math> for practical parallel program which has been proven very hard if not impossible. Gustafson's formula was derived from times by running actual parallel programs. Brining the two formulation together makes quantifying <math>\chi</math> in Amdahl's Law possible. Thus, both law actually refer to the same mathematical abstraction. Gustafson's formula assisted in quantifying the percentage of serial computing through program experiments. Neither should be directly used for speedup prediction alone.

This model can be validated in practice when developers simply increasing the problem size to use more parallel processors.
[[File:1overx-function resized.png|thumb|294x294px|Amdalh's Law and Peak Parallel Performance|center]]

A classical example is the TOP500 supercomputer benchmarks (linear solvers) that have open problem sizes for all manufacturers to compete in the world's fastest supercomputer race <ref>https://www.top500.org/</ref> .
[[File:Supercomputers-history.png|center|thumb]]
In practical blockchain applications, the number of transactions to be processed will increase without a known limit. The ledger storage will continue to grow. In practice, the available computing, networking and storage components will continue to grow without limits enabled by the networking protocols. Therefore a statistic multiplexed computing blockchain can meet any future application needs given proper economic incentives. The infrastructure no longer has the structural deficiency.

== Action Plan ==

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.

For Toichain protocol design, we choose Bitcoin 24.0.1 as the base line protocol by replacing the PoW consensus by PoS consensus and injecting SMC components into the protocol processing signaling for parallel computing.

This surprising result is also applicable to ledger storage. Without multiplexing, the blockchain ledger storage will eventually saturate all nodes causing the chain to collapse. The SMC blockchain protocol promises to hold the true finality of all transactions in perpetuity by multiplexing all storage resources while keeping the replication factor to a constant.

These discussions follow the inductive logic of the Law of Large Numbers <ref>https://www.sciencedirect.com/topics/mathematics/laws-of-large-number</ref>.

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

= SMC Proof of Stake Protocol =
Existing PoS protocol designs revolved around staking policies and randomness of the selection algorithm. Considering infrastructure scalability will add much complexity to the design. The examples include chain sharding and Danksharding <ref>https://ethereum.org/en/roadmap/danksharding/</ref>.

The challenge is complex -- we must deliver very high performance without compromising security and reliability of the network.

Technically, transaction replication and parallel processing were considered dangerous <ref>https://pages.cs.wisc.edu/~yxy/cs764-f20/papers/replication.pdf</ref> due to the potential race conditions (or double-spend problem). The blockchain protocol resolved the double-spending problem. It did not solve the parallel processing performance problem.

According to Professor Michael Flynn, there are three high-level parallel processing topologies: SIMD (single instruction multiple data), MIMD (multiple instructions multiple data), and pipeline (MISD - multiple instructions single data stream) <ref>https://link.springer.com/referenceworkentry/10.1007/978-0-387-09766-4_2</ref>. However, for eliminating double-spending, all transactions must be serialized, since each block may contain transactions affecting transactions in multiple other blocks. "Race conditions" and non-deterministic results are not allowed. Then the only possible topology entry is pipeline. This means for POS protocol, we must build a pipeline of transaction blocks to be validated without compromising network security and reliability.
[[File:Flynns-Taxonomy-of-Computer-Architectures.png|center|thumb|Parallel Processing Topologies]]
The problem is that the nature of the blockchain protocol is that all nodes run independently in parallel with little communication with other nodes via "gossip" protocols. It is far easier to force all nodes store the entire ledger than forcing them to form any pipeline and store partial chain data.

=== ACAN (Active Content Addressable Network) [U.S. and Other Patents Pending] ===
ACAN is a high-level data '''''communication and synchronization protocol''''' that completely decouples all hardware components from communicating programs. The need for complete component decoupling was implemented in the original blockchain protocol via "gossip" protocol. This delivered blockchain's high availability and security. The simple "gossip" implementation in existing protocols is insufficient for parallel processing signaling.

The following figure illustrates the concept of ACAN (active content addressable networking) using UVR (unidirectional virtual ring) architecture. The illustrated implementation uses the Tuple Space resource tagging method and gossip protocol for UVR implementation.
[[File:SMC Architecture with ACAN.png|center|thumb|243x243px|SMC Architecture with ACAN]]

ACAN supports three simple APIs:

# '''read'''(&''key'', &''value''): ''key'' holds a search pattern in a "tuple space" where all nodes are connected. ''value'' holds the matched tuple, if any. This is a blocking call that a requesting program will be blocked until a pattern-matched tuple is found. The matching tuple remains in the "tuple space".
# '''get'''(&key, &value): Same as the "read()" API, except that the matching tuple is removed from the "tuple space".
# '''put'''(key, value): Inserts <key, value> into the "tuple space".

The use of "gossip" protocol can accelerate ACAN network saturation time. Applications running on ACAN will automatically form parallel processing topologies: pipeline, SIMD and MIMD without violating the serialization needs of transaction block validation. Replication factor can also be dynamically controlled to spread replicated blocks in randomly chosen hosts.

The highly parallel nature of the blockchain protocol will automatically implement the SMC principle in real time.

The critical feature of this dynamic SMC pipelined architecture is the inductive scaling feature.
[[File:Pipeline Parallel Processing.png|center|thumb|247x247px|Pipeline Parallel Processing]]

The speed up of a pipeline can be represented as: <math>SpeedUp = \left ( \frac{p\centerdot b}{p + (b-p)} \right )</math>, where p = number of processors in the pipeline, b = total blocks to be processed. Take the number of blocks to infinity: <math>SpeedUp = \left ( \frac{p\centerdot b}{p + (b-p)} \right )=>\lim (b\Rightarrow\infty)(\frac{p}{\frac{p}{b}+1-\frac{p}{b}}) = p</math>

This means that as long as there are enough blocks to be processed, the entire chain's performance will be abound-bounded to the number of nodes in the pipeline.

For illustration purposes, the variation of block processing times was not considered in the above calculations. To see the power of pipeline parallelism, the automobile manufacturing processes illustrate a similar situation. The Hyundai Motor Company's production pipelines can produce 3,835 vehicles per day and 1.4M per year<ref>https://en.wikipedia.org/wiki/List_of_Hyundai_Motor_Company_manufacturing_facilities</ref>.

== Toichain Tokens ==
Toichain token is TOIN. There are 50,000,000,000 TOINs for the Alpha Release. There are air-drop tokens for early adopters, 1,000 TOIN each. Users need to register to download a toichain wallet to receive the payment. Citizenship is checked and verified to ensure that US citizens do not apply. The minimal staking contract is 10 TOINs.

== Non-Fungible Tokens ==
The TestNet Release of toichain protocol will support embedding arbitrary data in an "OP_RETURN" transaction that will be permanently recorded on the chain. Unlike the ordinal NFT <ref>https://blog.chain.link/ordinals-bitcoin-nfts/</ref> or NFT (non-fungible token) on other chains, these transactions cannot be altered or removed.

There are practical applications for these forever NFTs. Once Taproot is enabled on toichain, ordinal NFTs (BRC-20) will also be supported. Unlike the original Bitcoin network where BRC-20 craze has created massive network congestion<ref>https://beincrypto.com/learn/brc-20-token/</ref>, all transactions will be processed promptly in toichain without congestion or scaling problems.
== Toichain TestNet Launch ==
The toichain testnet launch will enable users to interact with one another through simple payments, just like the original Bitcoin network. Forever NFTs are supported. Smart contracts will be supported on a later date.

= References =
<references />

Consult the [[mediawikiwiki:Special:MyLanguage/Help:Contents|User's Guide]] for information on using the wiki software.

Main Page

2024-10-05T19:38:39Z

Justin: /* A Scalability Solution */

= <strong><big>'''Welcome to Toi-Twiki -- A Toichain Wiki'''</big></strong> =
This is the unofficial Toichain wiki site. Content is subject to changes.
---------------------------

= '''Introduction''' =
The blockchain protocol was introduced in a seminal paper entitled "Bitcoin: A peer-to-peer Electronic Cash System" <ref>https://bitcoin.org/bitcoin.pdf</ref> by Satoshi Nakamoto in 2008. Although there were previous peer-to-peer file-sharing projects such as Napster <ref>https://www.napster.com/us</ref>, BitTorrent <ref>https://www.bittorrent.com/</ref> and other electronic currency/file sharing applications, Bitcoin is the most enduring among the 23,000+ blockchains. Unlike other cryptocurrencies, the Bitcoin is often referred to as "digital gold" since the total coin supply is limited to 21 million (hard-coded in all running programs) and the only way to earn coin is to participate in the transaction block validation process. Token(or coin) supply and their disbursement policies differ among protocols.

The most attractive common blockchain features are 1) a decentralized consensus-driven decision making process and 2) a step-by-step cryptographic proving system. While blockchain is best known as a cryptocurrency transaction processing and record-keeping system, there are many other applications that can benefit from the secure storage, reliable transaction ledgers, fault tolerance and tamper resistance features.

== Algorithm vs. Protocol ==
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 ==
A good consensus protocol in a blockchain system has at least four properties:

# Fault tolerance to defend failures caused by natural disasters and human hacks or accidents
# Byzantine failure tolerance to defend exploitation by colluding parties
# Centralization avoidance to prevent corruptions in the decision making process
# Source code tamper resistance to automatically reject malicious attacks

Without assuming all nodes are active at all times, the blockchain relies on "gossip" protocol to communicate with other nodes. There are two popular types of consensus protocols: Proof of Work ('''PoW''') <ref>https://en.wikipedia.org/wiki/Proof_of_work</ref> or Proof of Stake ('''PoS''') <ref>https://www.investopedia.com/terms/p/proof-stake-pos.asp</ref>. Others include Proof of Possession('''PoP''')<ref>https://identityserver4.readthedocs.io/en/latest/topics/pop.html</ref> and Proof of History('''PoH''')<ref>https://www.infoworld.com/article/3666736/solana-blockchain-and-the-proof-of-history.html</ref>. The ultimate goal is to eliminate double-spending. Since most projects are open source, it's easy for a malicious actor to tamper a few nodes. This shouldn't compromise network integrity.

The Bitcoin network uses PoW which forces participating miners to compete for the fastest hashing rate by solving a computational cryptographic puzzle. Although it withstood more than 14 years of use, Bitcoin has been criticized for escalating electricity consumption <ref>https://www.forbes.com/advisor/investing/cryptocurrency/bitcoins-energy-usage-explained/</ref>. Other blockchain designs have experienced different challenges. For example, the PoH network Solana suffered multiple single-point-failure incidents <ref>https://messari.io/report/solana-analyzing-downtimes-statistics-and-ecosystem-development</ref>. All protocols struggle to combat scaling challenges. All are susceptible to 51% attacks <ref>https://originstamp.com/blog/has-there-ever-been-a-51-attack-on-bitcoin/#notable-51-attacks</ref>.

Since 2009, Bitcoin has proven to be the strongest and least susceptible to common hacks <ref>https://www.theguardian.com/technology/2014/mar/18/history-of-bitcoin-hacks-alternative-currency</ref>. As the PoW puzzle difficulty has increased dramatically over the years, the probability of a 51% attack on the Bitcoin network becomes more difficult. PoS protocols can save more than 90% energy consumption compared to PoW chains. But PoS chains have higher risks than PoW chains since a stolen coin will grow in PoS chains (for increased probability to be selected) forever but not in PoW chains (only hash rates count). PoS community governance rules can mitigate the voting power centralization problem. Staking and slashing policies can incentivize good behaviors and punish bad ones. In either case, double-spend is very expensive and difficult. According to Forbes, there are 80 cryptocurrencies that use PoS protocols at the time of this writing.

There are approximately 1,000 blockchains in four types: public, private, consortium, and permissioned <ref>https://increditools.com/blockchains/</ref>.

== Cryptographic Proofs ==
Bitcoin 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.

== Centralized vs. Decentralized Applications ==
The Bitcoin protocol enabled decentralized processing of traditionally centrally processed transactions without any trusted third-party. It inspired many decentralized financial applications, especially for applications with very long payment chains. However for fraud prevention and meeting financial regulatory requirements, many practical applications still require KYC (know your customer) checks. It is not possible to eliminate all trusted third parties, especially for custodial financial applications. There is a clear need for decentralized processing of trusted authority applications.

== Blockchain Trilemma ==
Blockchain protocols have three common aspects (goals): '''security''', '''decentralization''' and '''scalability''' -- these three terms do not have precise definitions but are intuitively understood <ref>https://sensoriumxr.com/articles/what-is-the-blockchain-trilemma</ref>. To date, 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.

A major shortcoming is scalability. Since all nodes verify each transaction independently, they need to store all the information required for it. As the chain grows, this burdens all nodes in the network. There are workarounds by limiting the amount of data stored on some nodes and exploiting the network to retrieve required information, such as the ''Limited/Light Nodes'' in Bitcoin network. Vast majority nodes are still full nodes in the existing Bitcoin network. Transaction processing speed often expressed ''as transactions per second(TPS) of'' blockchain have to exceed TPS ratings of credit card payment systems like VISA or MasterCard to reap the full benefits of blockchain. This is a tough problem and increasing the block size and/or reducing the block time or difficulty isn't a solution<ref>https://medium.com/coinmonks/blockchain-scaling-30c9e1b7db1b</ref>. Since blockchain TPS is very low, the transaction fees is often very high. This discourages public adoption. Layer 2 solution like ''Lightning Network'' or ''ZK-rollups,'' where only final settlement is on the main chain tend to address these issues. However, one could always argue that this often compromises some aspects of security and/or decentralization to achieve high TPS.

The trilemma was first introduced by Vitalik Buterin<ref>https://en.wikipedia.org/wiki/Vitalik_Buterin</ref>, one of the co-founders of Ethereum network. The problems he identified are real. There seem to be no obvious solutions that can accomplish all three goals at the same time. Therefore, all proposed solutions revolve around reducing "opportunity costs" focusing only on satisfying partial goals.

Treating the blockchain network as an infrastructure for transaction processing, the blockchain protocol solved service reliability problem but not performance challenge. The legacy infrastructure scaling dilemma: performance against reliability remains (where "infrastructure reliability" also does not have a commonly accepted definition). Fortunately these metrics, although important, are non-critical. Solutions that have been proposed have had varying opportunity costs. For many years, there were no obvious solutions that addressed all three blockchain goals (security, decentralization and scalability).
== Statistic Multiplexed Computing (SMC) ==
The principle of using unreliable components to build an arbitrarily reliable system was first lectured by von Neumann in the early 1950s<ref>https://static.ias.edu/pitp/archive/2012files/Probabilistic_Logics.pdf</ref>. The original idea was to use probabilistic logic to quantify the arbitrary reliability of a system by multiplexing all components. This theory was applied to the construction of Internet protocols to deliver the "best effort" reliability. Incidentally, best effort reliability also enabled "best effort" performance which in turn enabled unlimited scalability of the Internet. For emerging web3.0 technologies, it is important to apply the same methodology to both centralized and decentralized computing for seamless technology migration and integration. For historical arguments, click [[SMC|'''''here''''']].

== Definitions ==
'''Infrastructure scalability''' does not have a commonly accepted definition. It helps to define the challenging metrics more precisely before the infrastructure protocol design. In the following, for definitions #1 and #2, the word "'''infrastructure'''" means any '''application running on the infrastructure.'''

# '''Infrastructure Reliability''': MTBF (mean time between failure) = <math>\frac{\sum ((Start-Of-Downtime) - (Start-of-uptime)) }{No-of-failures}</math>
# '''Infrastructure Performance''': <math>\frac{No-of-Transactions}{Second}</math>
# '''Infrastructure Scalability''': Expanding the infrastructure in number of processors, networks or storage should have '''incrementally better''' impacts on application reliability and performance.
# '''Record Immutability''': For transaction ledgers, all confirmed records and changes are final. This is required by the blockchain protocol.
Note that in practice, record immutability is much harder to achieve than expected. There are two challenges, a) 51% attacks can literally wipe out all histories if successful, and b) for protocols require all nodes to hold independently verified ledger, such as the Bitcoin, the storage requirement grows approximately 50GB per month.

== 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 and considered.

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 crashe'''s <ref>https://groups.csail.mit.edu/tds/papers/Lynch/jacm93.pdf</ref>. The laws of physics regarding component reliability <ref>Encyclopedia of Physical Science and Technology, Editor-in-Chief Robert A. Meyers, [[index.php?title=Special:BookSources/9780122274107|ISBN 978-0-12-227410-7]], 2001</ref> show that '''100% component reliability is not possible.''' These facts require that the infrastructure protocol (program-program communication protocol) provide '''complete component (processing, networking and storage) decoupling''' from application program logics. This decoupling requirement forces the protocol to exploit "decentralized" or "stateless" components that the legacy infrastructure protocols, such as message passing interface (MPI), remote procedure call (RPC) and remote method invocation (RMI), cannot handle. The blockchain protocol is an example of a "best effort" availability protocol.

Quantifying infrastructure reliability can be traced back to the computer pioneer von Neumann. In addition to his contribution to computer architecture, von Neumann also penned a study on building reliable systems using unreliable components using probabilistic logics, in early fifties <ref>https://static.ias.edu/pitp/archive/2012files/Probabilistic_Logics.pdf</ref>. The 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 "best effort" reliability. Ironically, this best effort reliability also enabled the Internet's infinite scalability -- the benefit we enjoy now and into the future.

The Bitcoin protocol exploits multiple anonymous decoupled (or decentralized) computers connected through the Internet protocol. Judging from the Bitcoin network's reliability to date <ref>https://buybitcoinworldwide.com/bitcoin-downtime/</ref>, von Neumann's theory seems working well.

The '''second challenge''' involves infrastructure performance. Since the infrastructure must deploy multiple computing, networking and storage components, unless all components can be fully exploited at 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 lack this capability.

'''The infrastructure scalability challenge''' is automatically resolved once the performance challenge is resolved without negatively impacting reliability -- "best effort" performance" meets "best effort reliability". This requires inductive performance and reliability measures or deliveries.

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, an inductive statistic multiplexed blockchain protocol is needed to meet the scalability challenge. Non-inductive solutions such as fixed chain "sharding" or "Danksharding" <ref>https://ethereum.org/en/roadmap/danksharding/</ref> will only increase protocol development complexity with persistent performance walls.

== A Scalability Solution ==
An effective scalability solution can have two practical assumptions:

* The computation problem size can expand indefinitely, since every useful infrastructure is expected to solve bigger problems.

*Computing and network resources will continue to grow indefinitely, into the future.
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 <ref>https://en.wikipedia.org/wiki/Amdahl%27s_law</ref> and Gustafson's Law <ref>https://en.wikipedia.org/wiki/Gustafson%27s_law</ref>.

The Amdahl's Law assumes 0<= ''s'' <=1 percentage of serial instructions that cannot be parallelized. Then the ''(1-s)'' percentage of instructions can be accelerated using ''p'' processors.

<div style="text-align: center;">
Speedup(p) = <math>{1 \over s + {(1-s) \over p}}</math> (1)
Speedup(<math>\lim_{p \to \infty}</math>) = <math>\frac{1}{s}</math> (2)
</div>
Although quantifying ''s'' requires additional information, such as the problem size, the law is applicable to programs solving any problem size with a known ''s''. The limit of speedup (2) also does not depend on problem size. However, Amdahl used programs solving fixed problem sizes to argue the validity of not building parallel machines with too many processors. Since then assuming fixed problem size using p processors has been the norm in interpreting Amdahl's law in the past. This assumption has led to the dismal speedup predictions.[[File:Amdahl's Law.png|thumb|Amdahl's Law Speedup Predictions|center]]The traditional Amdahl's Law interpretation seems to suggest parallel performances following the economic law of diminishing of returns.

In 1988, Gustafson and Barsis at the Sandia National Laboratory conducted parallel computing experiments that seem to suggest potential infinite speedup.

Gustafson's while Gustafson's Law seems to lead to 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 mainframe computer architectures. In the past decades, these laws have been used to support computing system experiments and constructions.
[[File:Gustafson.png|thumb|Gustafson's Law|center]]
A careful examination revealed that the Gustafson's Law cannot scale mathematically since the are mathematically dependent <ref>https://cis.temple.edu/~shi/wwwroot/shi/public_html/docs/amdahl/amdahl.html</ref> where Amdahl's formulation has a tight peak performance bound <math>\left ( \frac{1}{x} \right )</math> 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 <math>\left ( \frac{1}{x} \right )</math>, when <math>x \Rightarrow 0</math>, the performance will asymptotically approach to <math>\infty</math>, when <math>x \Rightarrow 1</math> the speedup <math>\Rightarrow</math> 1. Thus, if the computing problem's size is fixed, x will eventually approach to 1 as the number of processors increases -- economic law of diminishing of return. If the problem size is open (solving bigger problems), then increasing the number of processors will force x <math>\Rightarrow</math> 0, thus speedup <math>\Rightarrow</math> <math>\infty</math>. Gustafson's Law uses a recurrence relation based on practical time measurements. It is not possible to derive a mathematical speedup bound.

Applying these laws in practice need to quantify <math>\chi</math> for practical parallel program which has been proven very hard if not impossible. Gustafson's formula was derived from times by running actual parallel programs. Brining the two formulation together makes quantifying <math>\chi</math> in Amdahl's Law possible. Thus, both law actually refer to the same mathematical abstraction. Gustafson's formula assisted in quantifying the percentage of serial computing through program experiments. Neither should be directly used for speedup prediction alone.

This model can be validated in practice when developers simply increasing the problem size to use more parallel processors.
[[File:1overx-function resized.png|thumb|294x294px|Amdalh's Law and Peak Parallel Performance|center]]

A classical example is the TOP500 supercomputer benchmarks (linear solvers) that have open problem sizes for all manufacturers to compete in the world's fastest supercomputer race <ref>https://www.top500.org/</ref> .
[[File:Supercomputers-history.png|center|thumb]]
In practical blockchain applications, the number of transactions to be processed will increase without a known limit. The ledger storage will continue to grow. In practice, the available computing, networking and storage components will continue to grow without limits enabled by the networking protocols. Therefore a statistic multiplexed computing blockchain can meet any future application needs given proper economic incentives. The infrastructure no longer has the structural deficiency.

== Action Plan ==

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.

For Toichain protocol design, we choose Bitcoin 24.0.1 as the base line protocol by replacing the PoW consensus by PoS consensus and injecting SMC components into the protocol processing signaling for parallel computing.

This surprising result is also applicable to ledger storage. Without multiplexing, the blockchain ledger storage will eventually saturate all nodes causing the chain to collapse. The SMC blockchain protocol promises to hold the true finality of all transactions in perpetuity by multiplexing all storage resources while keeping the replication factor to a constant.

These discussions follow the inductive logic of the Law of Large Numbers <ref>https://www.sciencedirect.com/topics/mathematics/laws-of-large-number</ref>.

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

= SMC Proof of Stake Protocol =
Existing PoS protocol designs revolved around staking policies and randomness of the selection algorithm. Considering infrastructure scalability will add much complexity to the design. The examples include chain sharding and Danksharding <ref>https://ethereum.org/en/roadmap/danksharding/</ref>.

The challenge is complex -- we must deliver very high performance without compromising security and reliability of the network.

Technically, transaction replication and parallel processing were considered dangerous <ref>https://pages.cs.wisc.edu/~yxy/cs764-f20/papers/replication.pdf</ref> due to the potential race conditions (or double-spend problem). The blockchain protocol resolved the double-spending problem. It did not solve the parallel processing performance problem.

According to Professor Michael Flynn, there are three high-level parallel processing topologies: SIMD (single instruction multiple data), MIMD (multiple instructions multiple data), and pipeline (MISD - multiple instructions single data stream) <ref>https://link.springer.com/referenceworkentry/10.1007/978-0-387-09766-4_2</ref>. However, for eliminating double-spending, all transactions must be serialized, since each block may contain transactions affecting transactions in multiple other blocks. "Race conditions" and non-deterministic results are not allowed. Then the only possible topology entry is pipeline. This means for POS protocol, we must build a pipeline of transaction blocks to be validated without compromising network security and reliability.
[[File:Flynns-Taxonomy-of-Computer-Architectures.png|center|thumb|Parallel Processing Topologies]]
The problem is that the nature of the blockchain protocol is that all nodes run independently in parallel with little communication with other nodes via "gossip" protocols. It is far easier to force all nodes store the entire ledger than forcing them to form any pipeline and store partial chain data.

=== ACAN (Active Content Addressable Network) [U.S. and Other Patents Pending] ===
ACAN is a high-level data '''''communication and synchronization protocol''''' that completely decouples all hardware components from communicating programs. The need for complete component decoupling was implemented in the original blockchain protocol via "gossip" protocol. This delivered blockchain's high availability and security. The simple "gossip" implementation in existing protocols is insufficient for parallel processing signaling.

The following figure illustrates the concept of ACAN (active content addressable networking) using UVR (unidirectional virtual ring) architecture. The illustrated implementation uses the Tuple Space resource tagging method and gossip protocol for UVR implementation.
[[File:SMC Architecture with ACAN.png|center|thumb|243x243px|SMC Architecture with ACAN]]

ACAN supports three simple APIs:

# '''read'''(&''key'', &''value''): ''key'' holds a search pattern in a "tuple space" where all nodes are connected. ''value'' holds the matched tuple, if any. This is a blocking call that a requesting program will be blocked until a pattern-matched tuple is found. The matching tuple remains in the "tuple space".
# '''get'''(&key, &value): Same as the "read()" API, except that the matching tuple is removed from the "tuple space".
# '''put'''(key, value): Inserts <key, value> into the "tuple space".

The use of "gossip" protocol can accelerate ACAN network saturation time. Applications running on ACAN will automatically form parallel processing topologies: pipeline, SIMD and MIMD without violating the serialization needs of transaction block validation. Replication factor can also be dynamically controlled to spread replicated blocks in randomly chosen hosts.

The highly parallel nature of the blockchain protocol will automatically implement the SMC principle in real time.

The critical feature of this dynamic SMC pipelined architecture is the inductive scaling feature.
[[File:Pipeline Parallel Processing.png|center|thumb|247x247px|Pipeline Parallel Processing]]

The speed up of a pipeline can be represented as: <math>SpeedUp = \left ( \frac{p\centerdot b}{p + (b-p)} \right )</math>, where p = number of processors in the pipeline, b = total blocks to be processed. Take the number of blocks to infinity: <math>SpeedUp = \left ( \frac{p\centerdot b}{p + (b-p)} \right )=>\lim (b\Rightarrow\infty)(\frac{p}{\frac{p}{b}+1-\frac{p}{b}}) = p</math>

This means that as long as there are enough blocks to be processed, the entire chain's performance will be abound-bounded to the number of nodes in the pipeline.

For illustration purposes, the variation of block processing times was not considered in the above calculations. To see the power of pipeline parallelism, the automobile manufacturing processes illustrate a similar situation. The Hyundai Motor Company's production pipelines can produce 3,835 vehicles per day and 1.4M per year<ref>https://en.wikipedia.org/wiki/List_of_Hyundai_Motor_Company_manufacturing_facilities</ref>.

== Toichain Tokens ==
Toichain token is TOIN. There are 50,000,000,000 TOINs for the Alpha Release. There are air-drop tokens for early adopters, 1,000 TOIN each. Users need to register to download a toichain wallet to receive the payment. Citizenship is checked and verified to ensure that US citizens do not apply. The minimal staking contract is 10 TOINs.

== Non-Fungible Tokens ==
The TestNet Release of toichain protocol will support embedding arbitrary data in an "OP_RETURN" transaction that will be permanently recorded on the chain. Unlike the ordinal NFT <ref>https://blog.chain.link/ordinals-bitcoin-nfts/</ref> or NFT (non-fungible token) on other chains, these transactions cannot be altered or removed.

There are practical applications for these forever NFTs. Once Taproot is enabled on toichain, ordinal NFTs (BRC-20) will also be supported. Unlike the original Bitcoin network where BRC-20 craze has created massive network congestion<ref>https://beincrypto.com/learn/brc-20-token/</ref>, all transactions will be processed promptly in toichain without congestion or scaling problems.
== Toichain TestNet Launch ==
The toichain testnet launch will enable users to interact with one another through simple payments, just like the original Bitcoin network. Forever NFTs are supported. Smart contracts will be supported on a later date.

= References =
<references />

Consult the [[mediawikiwiki:Special:MyLanguage/Help:Contents|User's Guide]] for information on using the wiki software.

Main Page

2024-10-05T19:36:56Z

Justin: /* A Scalability Solution */

= <strong><big>'''Welcome to Toi-Twiki -- A Toichain Wiki'''</big></strong> =
This is the unofficial Toichain wiki site. Content is subject to changes.
---------------------------

= '''Introduction''' =
The blockchain protocol was introduced in a seminal paper entitled "Bitcoin: A peer-to-peer Electronic Cash System" <ref>https://bitcoin.org/bitcoin.pdf</ref> by Satoshi Nakamoto in 2008. Although there were previous peer-to-peer file-sharing projects such as Napster <ref>https://www.napster.com/us</ref>, BitTorrent <ref>https://www.bittorrent.com/</ref> and other electronic currency/file sharing applications, Bitcoin is the most enduring among the 23,000+ blockchains. Unlike other cryptocurrencies, the Bitcoin is often referred to as "digital gold" since the total coin supply is limited to 21 million (hard-coded in all running programs) and the only way to earn coin is to participate in the transaction block validation process. Token(or coin) supply and their disbursement policies differ among protocols.

The most attractive common blockchain features are 1) a decentralized consensus-driven decision making process and 2) a step-by-step cryptographic proving system. While blockchain is best known as a cryptocurrency transaction processing and record-keeping system, there are many other applications that can benefit from the secure storage, reliable transaction ledgers, fault tolerance and tamper resistance features.

== Algorithm vs. Protocol ==
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 ==
A good consensus protocol in a blockchain system has at least four properties:

# Fault tolerance to defend failures caused by natural disasters and human hacks or accidents
# Byzantine failure tolerance to defend exploitation by colluding parties
# Centralization avoidance to prevent corruptions in the decision making process
# Source code tamper resistance to automatically reject malicious attacks

Without assuming all nodes are active at all times, the blockchain relies on "gossip" protocol to communicate with other nodes. There are two popular types of consensus protocols: Proof of Work ('''PoW''') <ref>https://en.wikipedia.org/wiki/Proof_of_work</ref> or Proof of Stake ('''PoS''') <ref>https://www.investopedia.com/terms/p/proof-stake-pos.asp</ref>. Others include Proof of Possession('''PoP''')<ref>https://identityserver4.readthedocs.io/en/latest/topics/pop.html</ref> and Proof of History('''PoH''')<ref>https://www.infoworld.com/article/3666736/solana-blockchain-and-the-proof-of-history.html</ref>. The ultimate goal is to eliminate double-spending. Since most projects are open source, it's easy for a malicious actor to tamper a few nodes. This shouldn't compromise network integrity.

The Bitcoin network uses PoW which forces participating miners to compete for the fastest hashing rate by solving a computational cryptographic puzzle. Although it withstood more than 14 years of use, Bitcoin has been criticized for escalating electricity consumption <ref>https://www.forbes.com/advisor/investing/cryptocurrency/bitcoins-energy-usage-explained/</ref>. Other blockchain designs have experienced different challenges. For example, the PoH network Solana suffered multiple single-point-failure incidents <ref>https://messari.io/report/solana-analyzing-downtimes-statistics-and-ecosystem-development</ref>. All protocols struggle to combat scaling challenges. All are susceptible to 51% attacks <ref>https://originstamp.com/blog/has-there-ever-been-a-51-attack-on-bitcoin/#notable-51-attacks</ref>.

Since 2009, Bitcoin has proven to be the strongest and least susceptible to common hacks <ref>https://www.theguardian.com/technology/2014/mar/18/history-of-bitcoin-hacks-alternative-currency</ref>. As the PoW puzzle difficulty has increased dramatically over the years, the probability of a 51% attack on the Bitcoin network becomes more difficult. PoS protocols can save more than 90% energy consumption compared to PoW chains. But PoS chains have higher risks than PoW chains since a stolen coin will grow in PoS chains (for increased probability to be selected) forever but not in PoW chains (only hash rates count). PoS community governance rules can mitigate the voting power centralization problem. Staking and slashing policies can incentivize good behaviors and punish bad ones. In either case, double-spend is very expensive and difficult. According to Forbes, there are 80 cryptocurrencies that use PoS protocols at the time of this writing.

There are approximately 1,000 blockchains in four types: public, private, consortium, and permissioned <ref>https://increditools.com/blockchains/</ref>.

== Cryptographic Proofs ==
Bitcoin 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.

== Centralized vs. Decentralized Applications ==
The Bitcoin protocol enabled decentralized processing of traditionally centrally processed transactions without any trusted third-party. It inspired many decentralized financial applications, especially for applications with very long payment chains. However for fraud prevention and meeting financial regulatory requirements, many practical applications still require KYC (know your customer) checks. It is not possible to eliminate all trusted third parties, especially for custodial financial applications. There is a clear need for decentralized processing of trusted authority applications.

== Blockchain Trilemma ==
Blockchain protocols have three common aspects (goals): '''security''', '''decentralization''' and '''scalability''' -- these three terms do not have precise definitions but are intuitively understood <ref>https://sensoriumxr.com/articles/what-is-the-blockchain-trilemma</ref>. To date, 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.

A major shortcoming is scalability. Since all nodes verify each transaction independently, they need to store all the information required for it. As the chain grows, this burdens all nodes in the network. There are workarounds by limiting the amount of data stored on some nodes and exploiting the network to retrieve required information, such as the ''Limited/Light Nodes'' in Bitcoin network. Vast majority nodes are still full nodes in the existing Bitcoin network. Transaction processing speed often expressed ''as transactions per second(TPS) of'' blockchain have to exceed TPS ratings of credit card payment systems like VISA or MasterCard to reap the full benefits of blockchain. This is a tough problem and increasing the block size and/or reducing the block time or difficulty isn't a solution<ref>https://medium.com/coinmonks/blockchain-scaling-30c9e1b7db1b</ref>. Since blockchain TPS is very low, the transaction fees is often very high. This discourages public adoption. Layer 2 solution like ''Lightning Network'' or ''ZK-rollups,'' where only final settlement is on the main chain tend to address these issues. However, one could always argue that this often compromises some aspects of security and/or decentralization to achieve high TPS.

The trilemma was first introduced by Vitalik Buterin<ref>https://en.wikipedia.org/wiki/Vitalik_Buterin</ref>, one of the co-founders of Ethereum network. The problems he identified are real. There seem to be no obvious solutions that can accomplish all three goals at the same time. Therefore, all proposed solutions revolve around reducing "opportunity costs" focusing only on satisfying partial goals.

Treating the blockchain network as an infrastructure for transaction processing, the blockchain protocol solved service reliability problem but not performance challenge. The legacy infrastructure scaling dilemma: performance against reliability remains (where "infrastructure reliability" also does not have a commonly accepted definition). Fortunately these metrics, although important, are non-critical. Solutions that have been proposed have had varying opportunity costs. For many years, there were no obvious solutions that addressed all three blockchain goals (security, decentralization and scalability).
== Statistic Multiplexed Computing (SMC) ==
The principle of using unreliable components to build an arbitrarily reliable system was first lectured by von Neumann in the early 1950s<ref>https://static.ias.edu/pitp/archive/2012files/Probabilistic_Logics.pdf</ref>. The original idea was to use probabilistic logic to quantify the arbitrary reliability of a system by multiplexing all components. This theory was applied to the construction of Internet protocols to deliver the "best effort" reliability. Incidentally, best effort reliability also enabled "best effort" performance which in turn enabled unlimited scalability of the Internet. For emerging web3.0 technologies, it is important to apply the same methodology to both centralized and decentralized computing for seamless technology migration and integration. For historical arguments, click [[SMC|'''''here''''']].

== Definitions ==
'''Infrastructure scalability''' does not have a commonly accepted definition. It helps to define the challenging metrics more precisely before the infrastructure protocol design. In the following, for definitions #1 and #2, the word "'''infrastructure'''" means any '''application running on the infrastructure.'''

# '''Infrastructure Reliability''': MTBF (mean time between failure) = <math>\frac{\sum ((Start-Of-Downtime) - (Start-of-uptime)) }{No-of-failures}</math>
# '''Infrastructure Performance''': <math>\frac{No-of-Transactions}{Second}</math>
# '''Infrastructure Scalability''': Expanding the infrastructure in number of processors, networks or storage should have '''incrementally better''' impacts on application reliability and performance.
# '''Record Immutability''': For transaction ledgers, all confirmed records and changes are final. This is required by the blockchain protocol.
Note that in practice, record immutability is much harder to achieve than expected. There are two challenges, a) 51% attacks can literally wipe out all histories if successful, and b) for protocols require all nodes to hold independently verified ledger, such as the Bitcoin, the storage requirement grows approximately 50GB per month.

== 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 and considered.

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 crashe'''s <ref>https://groups.csail.mit.edu/tds/papers/Lynch/jacm93.pdf</ref>. The laws of physics regarding component reliability <ref>Encyclopedia of Physical Science and Technology, Editor-in-Chief Robert A. Meyers, [[index.php?title=Special:BookSources/9780122274107|ISBN 978-0-12-227410-7]], 2001</ref> show that '''100% component reliability is not possible.''' These facts require that the infrastructure protocol (program-program communication protocol) provide '''complete component (processing, networking and storage) decoupling''' from application program logics. This decoupling requirement forces the protocol to exploit "decentralized" or "stateless" components that the legacy infrastructure protocols, such as message passing interface (MPI), remote procedure call (RPC) and remote method invocation (RMI), cannot handle. The blockchain protocol is an example of a "best effort" availability protocol.

Quantifying infrastructure reliability can be traced back to the computer pioneer von Neumann. In addition to his contribution to computer architecture, von Neumann also penned a study on building reliable systems using unreliable components using probabilistic logics, in early fifties <ref>https://static.ias.edu/pitp/archive/2012files/Probabilistic_Logics.pdf</ref>. The 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 "best effort" reliability. Ironically, this best effort reliability also enabled the Internet's infinite scalability -- the benefit we enjoy now and into the future.

The Bitcoin protocol exploits multiple anonymous decoupled (or decentralized) computers connected through the Internet protocol. Judging from the Bitcoin network's reliability to date <ref>https://buybitcoinworldwide.com/bitcoin-downtime/</ref>, von Neumann's theory seems working well.

The '''second challenge''' involves infrastructure performance. Since the infrastructure must deploy multiple computing, networking and storage components, unless all components can be fully exploited at 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 lack this capability.

'''The infrastructure scalability challenge''' is automatically resolved once the performance challenge is resolved without negatively impacting reliability -- "best effort" performance" meets "best effort reliability". This requires inductive performance and reliability measures or deliveries.

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, an inductive statistic multiplexed blockchain protocol is needed to meet the scalability challenge. Non-inductive solutions such as fixed chain "sharding" or "Danksharding" <ref>https://ethereum.org/en/roadmap/danksharding/</ref> will only increase protocol development complexity with persistent performance walls.

== A Scalability Solution ==
An effective scalability solution can have two practical assumptions:

* The computation problem size can expand indefinitely, since every useful infrastructure is expected to solve bigger problems.

*Computing and network resources will continue to grow indefinitely, into the future.
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 <ref>https://en.wikipedia.org/wiki/Amdahl%27s_law</ref> and Gustafson's Law <ref>https://en.wikipedia.org/wiki/Gustafson%27s_law</ref>.

The Amdahl's Law assumes 0<= ''s'' <=1 percentage of serial instructions that cannot be parallelized. Then the ''(1-s)'' percentage of instructions can be accelerated using ''p'' processors.

<div style="text-align: center;">
* Speedup(p) = <math>{1 \over s + {(1-s) \over p}}</math> (1)
* Speedup(<math>\lim_{p \to \infty}</math>) = <math>\frac{1}{s}</math> (2)
</div>
Although quantifying ''s'' requires additional information, such as the problem size, the law is applicable to programs solving any problem size with a known ''s''. The limit of speedup (2) also does not depend on problem size. However, Amdahl used programs solving fixed problem sizes to argue the validity of not building parallel machines with too many processors. Since then assuming fixed problem size using p processors has been the norm in interpreting Amdahl's law in the past. This assumption has led to the dismal speedup predictions.[[File:Amdahl's Law.png|thumb|Amdahl's Law Speedup Predictions|center]]The traditional Amdahl's Law interpretation seems to suggest parallel performances following the economic law of diminishing of returns.

In 1988, Gustafson and Barsis at the Sandia National Laboratory conducted parallel computing experiments that seem to suggest potential infinite speedup.

Gustafson's while Gustafson's Law seems to lead to 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 mainframe computer architectures. In the past decades, these laws have been used to support computing system experiments and constructions.
[[File:Gustafson.png|thumb|Gustafson's Law|center]]
A careful examination revealed that the Gustafson's Law cannot scale mathematically since the are mathematically dependent <ref>https://cis.temple.edu/~shi/wwwroot/shi/public_html/docs/amdahl/amdahl.html</ref> where Amdahl's formulation has a tight peak performance bound <math>\left ( \frac{1}{x} \right )</math> 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 <math>\left ( \frac{1}{x} \right )</math>, when <math>x \Rightarrow 0</math>, the performance will asymptotically approach to <math>\infty</math>, when <math>x \Rightarrow 1</math> the speedup <math>\Rightarrow</math> 1. Thus, if the computing problem's size is fixed, x will eventually approach to 1 as the number of processors increases -- economic law of diminishing of return. If the problem size is open (solving bigger problems), then increasing the number of processors will force x <math>\Rightarrow</math> 0, thus speedup <math>\Rightarrow</math> <math>\infty</math>. Gustafson's Law uses a recurrence relation based on practical time measurements. It is not possible to derive a mathematical speedup bound.

Applying these laws in practice need to quantify <math>\chi</math> for practical parallel program which has been proven very hard if not impossible. Gustafson's formula was derived from times by running actual parallel programs. Brining the two formulation together makes quantifying <math>\chi</math> in Amdahl's Law possible. Thus, both law actually refer to the same mathematical abstraction. Gustafson's formula assisted in quantifying the percentage of serial computing through program experiments. Neither should be directly used for speedup prediction alone.

This model can be validated in practice when developers simply increasing the problem size to use more parallel processors.
[[File:1overx-function resized.png|thumb|294x294px|Amdalh's Law and Peak Parallel Performance|center]]

A classical example is the TOP500 supercomputer benchmarks (linear solvers) that have open problem sizes for all manufacturers to compete in the world's fastest supercomputer race <ref>https://www.top500.org/</ref> .
[[File:Supercomputers-history.png|center|thumb]]
In practical blockchain applications, the number of transactions to be processed will increase without a known limit. The ledger storage will continue to grow. In practice, the available computing, networking and storage components will continue to grow without limits enabled by the networking protocols. Therefore a statistic multiplexed computing blockchain can meet any future application needs given proper economic incentives. The infrastructure no longer has the structural deficiency.

== Action Plan ==

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.

For Toichain protocol design, we choose Bitcoin 24.0.1 as the base line protocol by replacing the PoW consensus by PoS consensus and injecting SMC components into the protocol processing signaling for parallel computing.

This surprising result is also applicable to ledger storage. Without multiplexing, the blockchain ledger storage will eventually saturate all nodes causing the chain to collapse. The SMC blockchain protocol promises to hold the true finality of all transactions in perpetuity by multiplexing all storage resources while keeping the replication factor to a constant.

These discussions follow the inductive logic of the Law of Large Numbers <ref>https://www.sciencedirect.com/topics/mathematics/laws-of-large-number</ref>.

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

= SMC Proof of Stake Protocol =
Existing PoS protocol designs revolved around staking policies and randomness of the selection algorithm. Considering infrastructure scalability will add much complexity to the design. The examples include chain sharding and Danksharding <ref>https://ethereum.org/en/roadmap/danksharding/</ref>.

The challenge is complex -- we must deliver very high performance without compromising security and reliability of the network.

Technically, transaction replication and parallel processing were considered dangerous <ref>https://pages.cs.wisc.edu/~yxy/cs764-f20/papers/replication.pdf</ref> due to the potential race conditions (or double-spend problem). The blockchain protocol resolved the double-spending problem. It did not solve the parallel processing performance problem.

According to Professor Michael Flynn, there are three high-level parallel processing topologies: SIMD (single instruction multiple data), MIMD (multiple instructions multiple data), and pipeline (MISD - multiple instructions single data stream) <ref>https://link.springer.com/referenceworkentry/10.1007/978-0-387-09766-4_2</ref>. However, for eliminating double-spending, all transactions must be serialized, since each block may contain transactions affecting transactions in multiple other blocks. "Race conditions" and non-deterministic results are not allowed. Then the only possible topology entry is pipeline. This means for POS protocol, we must build a pipeline of transaction blocks to be validated without compromising network security and reliability.
[[File:Flynns-Taxonomy-of-Computer-Architectures.png|center|thumb|Parallel Processing Topologies]]
The problem is that the nature of the blockchain protocol is that all nodes run independently in parallel with little communication with other nodes via "gossip" protocols. It is far easier to force all nodes store the entire ledger than forcing them to form any pipeline and store partial chain data.

=== ACAN (Active Content Addressable Network) [U.S. and Other Patents Pending] ===
ACAN is a high-level data '''''communication and synchronization protocol''''' that completely decouples all hardware components from communicating programs. The need for complete component decoupling was implemented in the original blockchain protocol via "gossip" protocol. This delivered blockchain's high availability and security. The simple "gossip" implementation in existing protocols is insufficient for parallel processing signaling.

The following figure illustrates the concept of ACAN (active content addressable networking) using UVR (unidirectional virtual ring) architecture. The illustrated implementation uses the Tuple Space resource tagging method and gossip protocol for UVR implementation.
[[File:SMC Architecture with ACAN.png|center|thumb|243x243px|SMC Architecture with ACAN]]

ACAN supports three simple APIs:

# '''read'''(&''key'', &''value''): ''key'' holds a search pattern in a "tuple space" where all nodes are connected. ''value'' holds the matched tuple, if any. This is a blocking call that a requesting program will be blocked until a pattern-matched tuple is found. The matching tuple remains in the "tuple space".
# '''get'''(&key, &value): Same as the "read()" API, except that the matching tuple is removed from the "tuple space".
# '''put'''(key, value): Inserts <key, value> into the "tuple space".

The use of "gossip" protocol can accelerate ACAN network saturation time. Applications running on ACAN will automatically form parallel processing topologies: pipeline, SIMD and MIMD without violating the serialization needs of transaction block validation. Replication factor can also be dynamically controlled to spread replicated blocks in randomly chosen hosts.

The highly parallel nature of the blockchain protocol will automatically implement the SMC principle in real time.

The critical feature of this dynamic SMC pipelined architecture is the inductive scaling feature.
[[File:Pipeline Parallel Processing.png|center|thumb|247x247px|Pipeline Parallel Processing]]

The speed up of a pipeline can be represented as: <math>SpeedUp = \left ( \frac{p\centerdot b}{p + (b-p)} \right )</math>, where p = number of processors in the pipeline, b = total blocks to be processed. Take the number of blocks to infinity: <math>SpeedUp = \left ( \frac{p\centerdot b}{p + (b-p)} \right )=>\lim (b\Rightarrow\infty)(\frac{p}{\frac{p}{b}+1-\frac{p}{b}}) = p</math>

This means that as long as there are enough blocks to be processed, the entire chain's performance will be abound-bounded to the number of nodes in the pipeline.

For illustration purposes, the variation of block processing times was not considered in the above calculations. To see the power of pipeline parallelism, the automobile manufacturing processes illustrate a similar situation. The Hyundai Motor Company's production pipelines can produce 3,835 vehicles per day and 1.4M per year<ref>https://en.wikipedia.org/wiki/List_of_Hyundai_Motor_Company_manufacturing_facilities</ref>.

== Toichain Tokens ==
Toichain token is TOIN. There are 50,000,000,000 TOINs for the Alpha Release. There are air-drop tokens for early adopters, 1,000 TOIN each. Users need to register to download a toichain wallet to receive the payment. Citizenship is checked and verified to ensure that US citizens do not apply. The minimal staking contract is 10 TOINs.

== Non-Fungible Tokens ==
The TestNet Release of toichain protocol will support embedding arbitrary data in an "OP_RETURN" transaction that will be permanently recorded on the chain. Unlike the ordinal NFT <ref>https://blog.chain.link/ordinals-bitcoin-nfts/</ref> or NFT (non-fungible token) on other chains, these transactions cannot be altered or removed.

There are practical applications for these forever NFTs. Once Taproot is enabled on toichain, ordinal NFTs (BRC-20) will also be supported. Unlike the original Bitcoin network where BRC-20 craze has created massive network congestion<ref>https://beincrypto.com/learn/brc-20-token/</ref>, all transactions will be processed promptly in toichain without congestion or scaling problems.
== Toichain TestNet Launch ==
The toichain testnet launch will enable users to interact with one another through simple payments, just like the original Bitcoin network. Forever NFTs are supported. Smart contracts will be supported on a later date.

= References =
<references />

Consult the [[mediawikiwiki:Special:MyLanguage/Help:Contents|User's Guide]] for information on using the wiki software.

Main Page

2024-10-05T19:35:51Z

Justin: /* A Scalability Solution */

= <strong><big>'''Welcome to Toi-Twiki -- A Toichain Wiki'''</big></strong> =
This is the unofficial Toichain wiki site. Content is subject to changes.
---------------------------

= '''Introduction''' =
The blockchain protocol was introduced in a seminal paper entitled "Bitcoin: A peer-to-peer Electronic Cash System" <ref>https://bitcoin.org/bitcoin.pdf</ref> by Satoshi Nakamoto in 2008. Although there were previous peer-to-peer file-sharing projects such as Napster <ref>https://www.napster.com/us</ref>, BitTorrent <ref>https://www.bittorrent.com/</ref> and other electronic currency/file sharing applications, Bitcoin is the most enduring among the 23,000+ blockchains. Unlike other cryptocurrencies, the Bitcoin is often referred to as "digital gold" since the total coin supply is limited to 21 million (hard-coded in all running programs) and the only way to earn coin is to participate in the transaction block validation process. Token(or coin) supply and their disbursement policies differ among protocols.

The most attractive common blockchain features are 1) a decentralized consensus-driven decision making process and 2) a step-by-step cryptographic proving system. While blockchain is best known as a cryptocurrency transaction processing and record-keeping system, there are many other applications that can benefit from the secure storage, reliable transaction ledgers, fault tolerance and tamper resistance features.

== Algorithm vs. Protocol ==
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 ==
A good consensus protocol in a blockchain system has at least four properties:

# Fault tolerance to defend failures caused by natural disasters and human hacks or accidents
# Byzantine failure tolerance to defend exploitation by colluding parties
# Centralization avoidance to prevent corruptions in the decision making process
# Source code tamper resistance to automatically reject malicious attacks

Without assuming all nodes are active at all times, the blockchain relies on "gossip" protocol to communicate with other nodes. There are two popular types of consensus protocols: Proof of Work ('''PoW''') <ref>https://en.wikipedia.org/wiki/Proof_of_work</ref> or Proof of Stake ('''PoS''') <ref>https://www.investopedia.com/terms/p/proof-stake-pos.asp</ref>. Others include Proof of Possession('''PoP''')<ref>https://identityserver4.readthedocs.io/en/latest/topics/pop.html</ref> and Proof of History('''PoH''')<ref>https://www.infoworld.com/article/3666736/solana-blockchain-and-the-proof-of-history.html</ref>. The ultimate goal is to eliminate double-spending. Since most projects are open source, it's easy for a malicious actor to tamper a few nodes. This shouldn't compromise network integrity.

The Bitcoin network uses PoW which forces participating miners to compete for the fastest hashing rate by solving a computational cryptographic puzzle. Although it withstood more than 14 years of use, Bitcoin has been criticized for escalating electricity consumption <ref>https://www.forbes.com/advisor/investing/cryptocurrency/bitcoins-energy-usage-explained/</ref>. Other blockchain designs have experienced different challenges. For example, the PoH network Solana suffered multiple single-point-failure incidents <ref>https://messari.io/report/solana-analyzing-downtimes-statistics-and-ecosystem-development</ref>. All protocols struggle to combat scaling challenges. All are susceptible to 51% attacks <ref>https://originstamp.com/blog/has-there-ever-been-a-51-attack-on-bitcoin/#notable-51-attacks</ref>.

Since 2009, Bitcoin has proven to be the strongest and least susceptible to common hacks <ref>https://www.theguardian.com/technology/2014/mar/18/history-of-bitcoin-hacks-alternative-currency</ref>. As the PoW puzzle difficulty has increased dramatically over the years, the probability of a 51% attack on the Bitcoin network becomes more difficult. PoS protocols can save more than 90% energy consumption compared to PoW chains. But PoS chains have higher risks than PoW chains since a stolen coin will grow in PoS chains (for increased probability to be selected) forever but not in PoW chains (only hash rates count). PoS community governance rules can mitigate the voting power centralization problem. Staking and slashing policies can incentivize good behaviors and punish bad ones. In either case, double-spend is very expensive and difficult. According to Forbes, there are 80 cryptocurrencies that use PoS protocols at the time of this writing.

There are approximately 1,000 blockchains in four types: public, private, consortium, and permissioned <ref>https://increditools.com/blockchains/</ref>.

== Cryptographic Proofs ==
Bitcoin 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.

== Centralized vs. Decentralized Applications ==
The Bitcoin protocol enabled decentralized processing of traditionally centrally processed transactions without any trusted third-party. It inspired many decentralized financial applications, especially for applications with very long payment chains. However for fraud prevention and meeting financial regulatory requirements, many practical applications still require KYC (know your customer) checks. It is not possible to eliminate all trusted third parties, especially for custodial financial applications. There is a clear need for decentralized processing of trusted authority applications.

== Blockchain Trilemma ==
Blockchain protocols have three common aspects (goals): '''security''', '''decentralization''' and '''scalability''' -- these three terms do not have precise definitions but are intuitively understood <ref>https://sensoriumxr.com/articles/what-is-the-blockchain-trilemma</ref>. To date, 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.

A major shortcoming is scalability. Since all nodes verify each transaction independently, they need to store all the information required for it. As the chain grows, this burdens all nodes in the network. There are workarounds by limiting the amount of data stored on some nodes and exploiting the network to retrieve required information, such as the ''Limited/Light Nodes'' in Bitcoin network. Vast majority nodes are still full nodes in the existing Bitcoin network. Transaction processing speed often expressed ''as transactions per second(TPS) of'' blockchain have to exceed TPS ratings of credit card payment systems like VISA or MasterCard to reap the full benefits of blockchain. This is a tough problem and increasing the block size and/or reducing the block time or difficulty isn't a solution<ref>https://medium.com/coinmonks/blockchain-scaling-30c9e1b7db1b</ref>. Since blockchain TPS is very low, the transaction fees is often very high. This discourages public adoption. Layer 2 solution like ''Lightning Network'' or ''ZK-rollups,'' where only final settlement is on the main chain tend to address these issues. However, one could always argue that this often compromises some aspects of security and/or decentralization to achieve high TPS.

The trilemma was first introduced by Vitalik Buterin<ref>https://en.wikipedia.org/wiki/Vitalik_Buterin</ref>, one of the co-founders of Ethereum network. The problems he identified are real. There seem to be no obvious solutions that can accomplish all three goals at the same time. Therefore, all proposed solutions revolve around reducing "opportunity costs" focusing only on satisfying partial goals.

Treating the blockchain network as an infrastructure for transaction processing, the blockchain protocol solved service reliability problem but not performance challenge. The legacy infrastructure scaling dilemma: performance against reliability remains (where "infrastructure reliability" also does not have a commonly accepted definition). Fortunately these metrics, although important, are non-critical. Solutions that have been proposed have had varying opportunity costs. For many years, there were no obvious solutions that addressed all three blockchain goals (security, decentralization and scalability).
== Statistic Multiplexed Computing (SMC) ==
The principle of using unreliable components to build an arbitrarily reliable system was first lectured by von Neumann in the early 1950s<ref>https://static.ias.edu/pitp/archive/2012files/Probabilistic_Logics.pdf</ref>. The original idea was to use probabilistic logic to quantify the arbitrary reliability of a system by multiplexing all components. This theory was applied to the construction of Internet protocols to deliver the "best effort" reliability. Incidentally, best effort reliability also enabled "best effort" performance which in turn enabled unlimited scalability of the Internet. For emerging web3.0 technologies, it is important to apply the same methodology to both centralized and decentralized computing for seamless technology migration and integration. For historical arguments, click [[SMC|'''''here''''']].

== Definitions ==
'''Infrastructure scalability''' does not have a commonly accepted definition. It helps to define the challenging metrics more precisely before the infrastructure protocol design. In the following, for definitions #1 and #2, the word "'''infrastructure'''" means any '''application running on the infrastructure.'''

# '''Infrastructure Reliability''': MTBF (mean time between failure) = <math>\frac{\sum ((Start-Of-Downtime) - (Start-of-uptime)) }{No-of-failures}</math>
# '''Infrastructure Performance''': <math>\frac{No-of-Transactions}{Second}</math>
# '''Infrastructure Scalability''': Expanding the infrastructure in number of processors, networks or storage should have '''incrementally better''' impacts on application reliability and performance.
# '''Record Immutability''': For transaction ledgers, all confirmed records and changes are final. This is required by the blockchain protocol.
Note that in practice, record immutability is much harder to achieve than expected. There are two challenges, a) 51% attacks can literally wipe out all histories if successful, and b) for protocols require all nodes to hold independently verified ledger, such as the Bitcoin, the storage requirement grows approximately 50GB per month.

== 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 and considered.

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 crashe'''s <ref>https://groups.csail.mit.edu/tds/papers/Lynch/jacm93.pdf</ref>. The laws of physics regarding component reliability <ref>Encyclopedia of Physical Science and Technology, Editor-in-Chief Robert A. Meyers, [[index.php?title=Special:BookSources/9780122274107|ISBN 978-0-12-227410-7]], 2001</ref> show that '''100% component reliability is not possible.''' These facts require that the infrastructure protocol (program-program communication protocol) provide '''complete component (processing, networking and storage) decoupling''' from application program logics. This decoupling requirement forces the protocol to exploit "decentralized" or "stateless" components that the legacy infrastructure protocols, such as message passing interface (MPI), remote procedure call (RPC) and remote method invocation (RMI), cannot handle. The blockchain protocol is an example of a "best effort" availability protocol.

Quantifying infrastructure reliability can be traced back to the computer pioneer von Neumann. In addition to his contribution to computer architecture, von Neumann also penned a study on building reliable systems using unreliable components using probabilistic logics, in early fifties <ref>https://static.ias.edu/pitp/archive/2012files/Probabilistic_Logics.pdf</ref>. The 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 "best effort" reliability. Ironically, this best effort reliability also enabled the Internet's infinite scalability -- the benefit we enjoy now and into the future.

The Bitcoin protocol exploits multiple anonymous decoupled (or decentralized) computers connected through the Internet protocol. Judging from the Bitcoin network's reliability to date <ref>https://buybitcoinworldwide.com/bitcoin-downtime/</ref>, von Neumann's theory seems working well.

The '''second challenge''' involves infrastructure performance. Since the infrastructure must deploy multiple computing, networking and storage components, unless all components can be fully exploited at 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 lack this capability.

'''The infrastructure scalability challenge''' is automatically resolved once the performance challenge is resolved without negatively impacting reliability -- "best effort" performance" meets "best effort reliability". This requires inductive performance and reliability measures or deliveries.

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, an inductive statistic multiplexed blockchain protocol is needed to meet the scalability challenge. Non-inductive solutions such as fixed chain "sharding" or "Danksharding" <ref>https://ethereum.org/en/roadmap/danksharding/</ref> will only increase protocol development complexity with persistent performance walls.

== A Scalability Solution ==
An effective scalability solution can have two practical assumptions:

* The computation problem size can expand indefinitely, since every useful infrastructure is expected to solve bigger problems.

*Computing and network resources will continue to grow indefinitely, into the future.
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 <ref>https://en.wikipedia.org/wiki/Amdahl%27s_law</ref> and Gustafson's Law <ref>https://en.wikipedia.org/wiki/Gustafson%27s_law</ref>.

The Amdahl's Law assumes 0<= ''s'' <=1 percentage of serial instructions that cannot be parallelized. Then the ''(1-s)'' percentage of instructions can be accelerated using ''p'' processors.

<nowiki><div style="text-align: center;"></nowiki>
* Speedup(p) = <math>{1 \over s + {(1-s) \over p}}</math> (1)
* Speedup(<math>\lim_{p \to \infty}</math>) = <math>\frac{1}{s}</math> (2)
<nowiki></div></nowiki>
Although quantifying ''s'' requires additional information, such as the problem size, the law is applicable to programs solving any problem size with a known ''s''. The limit of speedup (2) also does not depend on problem size. However, Amdahl used programs solving fixed problem sizes to argue the validity of not building parallel machines with too many processors. Since then assuming fixed problem size using p processors has been the norm in interpreting Amdahl's law in the past. This assumption has led to the dismal speedup predictions.[[File:Amdahl's Law.png|thumb|Amdahl's Law Speedup Predictions|center]]The traditional Amdahl's Law interpretation seems to suggest parallel performances following the economic law of diminishing of returns.

In 1988, Gustafson and Barsis at the Sandia National Laboratory conducted parallel computing experiments that seem to suggest potential infinite speedup.

Gustafson's while Gustafson's Law seems to lead to 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 mainframe computer architectures. In the past decades, these laws have been used to support computing system experiments and constructions.
[[File:Gustafson.png|thumb|Gustafson's Law|center]]
A careful examination revealed that the Gustafson's Law cannot scale mathematically since the are mathematically dependent <ref>https://cis.temple.edu/~shi/wwwroot/shi/public_html/docs/amdahl/amdahl.html</ref> where Amdahl's formulation has a tight peak performance bound <math>\left ( \frac{1}{x} \right )</math> 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 <math>\left ( \frac{1}{x} \right )</math>, when <math>x \Rightarrow 0</math>, the performance will asymptotically approach to <math>\infty</math>, when <math>x \Rightarrow 1</math> the speedup <math>\Rightarrow</math> 1. Thus, if the computing problem's size is fixed, x will eventually approach to 1 as the number of processors increases -- economic law of diminishing of return. If the problem size is open (solving bigger problems), then increasing the number of processors will force x <math>\Rightarrow</math> 0, thus speedup <math>\Rightarrow</math> <math>\infty</math>. Gustafson's Law uses a recurrence relation based on practical time measurements. It is not possible to derive a mathematical speedup bound.

Applying these laws in practice need to quantify <math>\chi</math> for practical parallel program which has been proven very hard if not impossible. Gustafson's formula was derived from times by running actual parallel programs. Brining the two formulation together makes quantifying <math>\chi</math> in Amdahl's Law possible. Thus, both law actually refer to the same mathematical abstraction. Gustafson's formula assisted in quantifying the percentage of serial computing through program experiments. Neither should be directly used for speedup prediction alone.

This model can be validated in practice when developers simply increasing the problem size to use more parallel processors.
[[File:1overx-function resized.png|thumb|294x294px|Amdalh's Law and Peak Parallel Performance|center]]

A classical example is the TOP500 supercomputer benchmarks (linear solvers) that have open problem sizes for all manufacturers to compete in the world's fastest supercomputer race <ref>https://www.top500.org/</ref> .
[[File:Supercomputers-history.png|center|thumb]]
In practical blockchain applications, the number of transactions to be processed will increase without a known limit. The ledger storage will continue to grow. In practice, the available computing, networking and storage components will continue to grow without limits enabled by the networking protocols. Therefore a statistic multiplexed computing blockchain can meet any future application needs given proper economic incentives. The infrastructure no longer has the structural deficiency.

== Action Plan ==

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.

For Toichain protocol design, we choose Bitcoin 24.0.1 as the base line protocol by replacing the PoW consensus by PoS consensus and injecting SMC components into the protocol processing signaling for parallel computing.

This surprising result is also applicable to ledger storage. Without multiplexing, the blockchain ledger storage will eventually saturate all nodes causing the chain to collapse. The SMC blockchain protocol promises to hold the true finality of all transactions in perpetuity by multiplexing all storage resources while keeping the replication factor to a constant.

These discussions follow the inductive logic of the Law of Large Numbers <ref>https://www.sciencedirect.com/topics/mathematics/laws-of-large-number</ref>.

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

= SMC Proof of Stake Protocol =
Existing PoS protocol designs revolved around staking policies and randomness of the selection algorithm. Considering infrastructure scalability will add much complexity to the design. The examples include chain sharding and Danksharding <ref>https://ethereum.org/en/roadmap/danksharding/</ref>.

The challenge is complex -- we must deliver very high performance without compromising security and reliability of the network.

Technically, transaction replication and parallel processing were considered dangerous <ref>https://pages.cs.wisc.edu/~yxy/cs764-f20/papers/replication.pdf</ref> due to the potential race conditions (or double-spend problem). The blockchain protocol resolved the double-spending problem. It did not solve the parallel processing performance problem.

According to Professor Michael Flynn, there are three high-level parallel processing topologies: SIMD (single instruction multiple data), MIMD (multiple instructions multiple data), and pipeline (MISD - multiple instructions single data stream) <ref>https://link.springer.com/referenceworkentry/10.1007/978-0-387-09766-4_2</ref>. However, for eliminating double-spending, all transactions must be serialized, since each block may contain transactions affecting transactions in multiple other blocks. "Race conditions" and non-deterministic results are not allowed. Then the only possible topology entry is pipeline. This means for POS protocol, we must build a pipeline of transaction blocks to be validated without compromising network security and reliability.
[[File:Flynns-Taxonomy-of-Computer-Architectures.png|center|thumb|Parallel Processing Topologies]]
The problem is that the nature of the blockchain protocol is that all nodes run independently in parallel with little communication with other nodes via "gossip" protocols. It is far easier to force all nodes store the entire ledger than forcing them to form any pipeline and store partial chain data.

=== ACAN (Active Content Addressable Network) [U.S. and Other Patents Pending] ===
ACAN is a high-level data '''''communication and synchronization protocol''''' that completely decouples all hardware components from communicating programs. The need for complete component decoupling was implemented in the original blockchain protocol via "gossip" protocol. This delivered blockchain's high availability and security. The simple "gossip" implementation in existing protocols is insufficient for parallel processing signaling.

The following figure illustrates the concept of ACAN (active content addressable networking) using UVR (unidirectional virtual ring) architecture. The illustrated implementation uses the Tuple Space resource tagging method and gossip protocol for UVR implementation.
[[File:SMC Architecture with ACAN.png|center|thumb|243x243px|SMC Architecture with ACAN]]

ACAN supports three simple APIs:

# '''read'''(&''key'', &''value''): ''key'' holds a search pattern in a "tuple space" where all nodes are connected. ''value'' holds the matched tuple, if any. This is a blocking call that a requesting program will be blocked until a pattern-matched tuple is found. The matching tuple remains in the "tuple space".
# '''get'''(&key, &value): Same as the "read()" API, except that the matching tuple is removed from the "tuple space".
# '''put'''(key, value): Inserts <key, value> into the "tuple space".

The use of "gossip" protocol can accelerate ACAN network saturation time. Applications running on ACAN will automatically form parallel processing topologies: pipeline, SIMD and MIMD without violating the serialization needs of transaction block validation. Replication factor can also be dynamically controlled to spread replicated blocks in randomly chosen hosts.

The highly parallel nature of the blockchain protocol will automatically implement the SMC principle in real time.

The critical feature of this dynamic SMC pipelined architecture is the inductive scaling feature.
[[File:Pipeline Parallel Processing.png|center|thumb|247x247px|Pipeline Parallel Processing]]

The speed up of a pipeline can be represented as: <math>SpeedUp = \left ( \frac{p\centerdot b}{p + (b-p)} \right )</math>, where p = number of processors in the pipeline, b = total blocks to be processed. Take the number of blocks to infinity: <math>SpeedUp = \left ( \frac{p\centerdot b}{p + (b-p)} \right )=>\lim (b\Rightarrow\infty)(\frac{p}{\frac{p}{b}+1-\frac{p}{b}}) = p</math>

This means that as long as there are enough blocks to be processed, the entire chain's performance will be abound-bounded to the number of nodes in the pipeline.

For illustration purposes, the variation of block processing times was not considered in the above calculations. To see the power of pipeline parallelism, the automobile manufacturing processes illustrate a similar situation. The Hyundai Motor Company's production pipelines can produce 3,835 vehicles per day and 1.4M per year<ref>https://en.wikipedia.org/wiki/List_of_Hyundai_Motor_Company_manufacturing_facilities</ref>.

== Toichain Tokens ==
Toichain token is TOIN. There are 50,000,000,000 TOINs for the Alpha Release. There are air-drop tokens for early adopters, 1,000 TOIN each. Users need to register to download a toichain wallet to receive the payment. Citizenship is checked and verified to ensure that US citizens do not apply. The minimal staking contract is 10 TOINs.

== Non-Fungible Tokens ==
The TestNet Release of toichain protocol will support embedding arbitrary data in an "OP_RETURN" transaction that will be permanently recorded on the chain. Unlike the ordinal NFT <ref>https://blog.chain.link/ordinals-bitcoin-nfts/</ref> or NFT (non-fungible token) on other chains, these transactions cannot be altered or removed.

There are practical applications for these forever NFTs. Once Taproot is enabled on toichain, ordinal NFTs (BRC-20) will also be supported. Unlike the original Bitcoin network where BRC-20 craze has created massive network congestion<ref>https://beincrypto.com/learn/brc-20-token/</ref>, all transactions will be processed promptly in toichain without congestion or scaling problems.
== Toichain TestNet Launch ==
The toichain testnet launch will enable users to interact with one another through simple payments, just like the original Bitcoin network. Forever NFTs are supported. Smart contracts will be supported on a later date.

= References =
<references />

Consult the [[mediawikiwiki:Special:MyLanguage/Help:Contents|User's Guide]] for information on using the wiki software.

Main Page

2024-10-05T19:34:15Z

Justin: /* A Scalability Solution */

= <strong><big>'''Welcome to Toi-Twiki -- A Toichain Wiki'''</big></strong> =
This is the unofficial Toichain wiki site. Content is subject to changes.
---------------------------

= '''Introduction''' =
The blockchain protocol was introduced in a seminal paper entitled "Bitcoin: A peer-to-peer Electronic Cash System" <ref>https://bitcoin.org/bitcoin.pdf</ref> by Satoshi Nakamoto in 2008. Although there were previous peer-to-peer file-sharing projects such as Napster <ref>https://www.napster.com/us</ref>, BitTorrent <ref>https://www.bittorrent.com/</ref> and other electronic currency/file sharing applications, Bitcoin is the most enduring among the 23,000+ blockchains. Unlike other cryptocurrencies, the Bitcoin is often referred to as "digital gold" since the total coin supply is limited to 21 million (hard-coded in all running programs) and the only way to earn coin is to participate in the transaction block validation process. Token(or coin) supply and their disbursement policies differ among protocols.

The most attractive common blockchain features are 1) a decentralized consensus-driven decision making process and 2) a step-by-step cryptographic proving system. While blockchain is best known as a cryptocurrency transaction processing and record-keeping system, there are many other applications that can benefit from the secure storage, reliable transaction ledgers, fault tolerance and tamper resistance features.

== Algorithm vs. Protocol ==
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 ==
A good consensus protocol in a blockchain system has at least four properties:

# Fault tolerance to defend failures caused by natural disasters and human hacks or accidents
# Byzantine failure tolerance to defend exploitation by colluding parties
# Centralization avoidance to prevent corruptions in the decision making process
# Source code tamper resistance to automatically reject malicious attacks

Without assuming all nodes are active at all times, the blockchain relies on "gossip" protocol to communicate with other nodes. There are two popular types of consensus protocols: Proof of Work ('''PoW''') <ref>https://en.wikipedia.org/wiki/Proof_of_work</ref> or Proof of Stake ('''PoS''') <ref>https://www.investopedia.com/terms/p/proof-stake-pos.asp</ref>. Others include Proof of Possession('''PoP''')<ref>https://identityserver4.readthedocs.io/en/latest/topics/pop.html</ref> and Proof of History('''PoH''')<ref>https://www.infoworld.com/article/3666736/solana-blockchain-and-the-proof-of-history.html</ref>. The ultimate goal is to eliminate double-spending. Since most projects are open source, it's easy for a malicious actor to tamper a few nodes. This shouldn't compromise network integrity.

The Bitcoin network uses PoW which forces participating miners to compete for the fastest hashing rate by solving a computational cryptographic puzzle. Although it withstood more than 14 years of use, Bitcoin has been criticized for escalating electricity consumption <ref>https://www.forbes.com/advisor/investing/cryptocurrency/bitcoins-energy-usage-explained/</ref>. Other blockchain designs have experienced different challenges. For example, the PoH network Solana suffered multiple single-point-failure incidents <ref>https://messari.io/report/solana-analyzing-downtimes-statistics-and-ecosystem-development</ref>. All protocols struggle to combat scaling challenges. All are susceptible to 51% attacks <ref>https://originstamp.com/blog/has-there-ever-been-a-51-attack-on-bitcoin/#notable-51-attacks</ref>.

Since 2009, Bitcoin has proven to be the strongest and least susceptible to common hacks <ref>https://www.theguardian.com/technology/2014/mar/18/history-of-bitcoin-hacks-alternative-currency</ref>. As the PoW puzzle difficulty has increased dramatically over the years, the probability of a 51% attack on the Bitcoin network becomes more difficult. PoS protocols can save more than 90% energy consumption compared to PoW chains. But PoS chains have higher risks than PoW chains since a stolen coin will grow in PoS chains (for increased probability to be selected) forever but not in PoW chains (only hash rates count). PoS community governance rules can mitigate the voting power centralization problem. Staking and slashing policies can incentivize good behaviors and punish bad ones. In either case, double-spend is very expensive and difficult. According to Forbes, there are 80 cryptocurrencies that use PoS protocols at the time of this writing.

There are approximately 1,000 blockchains in four types: public, private, consortium, and permissioned <ref>https://increditools.com/blockchains/</ref>.

== Cryptographic Proofs ==
Bitcoin 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.

== Centralized vs. Decentralized Applications ==
The Bitcoin protocol enabled decentralized processing of traditionally centrally processed transactions without any trusted third-party. It inspired many decentralized financial applications, especially for applications with very long payment chains. However for fraud prevention and meeting financial regulatory requirements, many practical applications still require KYC (know your customer) checks. It is not possible to eliminate all trusted third parties, especially for custodial financial applications. There is a clear need for decentralized processing of trusted authority applications.

== Blockchain Trilemma ==
Blockchain protocols have three common aspects (goals): '''security''', '''decentralization''' and '''scalability''' -- these three terms do not have precise definitions but are intuitively understood <ref>https://sensoriumxr.com/articles/what-is-the-blockchain-trilemma</ref>. To date, 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.

A major shortcoming is scalability. Since all nodes verify each transaction independently, they need to store all the information required for it. As the chain grows, this burdens all nodes in the network. There are workarounds by limiting the amount of data stored on some nodes and exploiting the network to retrieve required information, such as the ''Limited/Light Nodes'' in Bitcoin network. Vast majority nodes are still full nodes in the existing Bitcoin network. Transaction processing speed often expressed ''as transactions per second(TPS) of'' blockchain have to exceed TPS ratings of credit card payment systems like VISA or MasterCard to reap the full benefits of blockchain. This is a tough problem and increasing the block size and/or reducing the block time or difficulty isn't a solution<ref>https://medium.com/coinmonks/blockchain-scaling-30c9e1b7db1b</ref>. Since blockchain TPS is very low, the transaction fees is often very high. This discourages public adoption. Layer 2 solution like ''Lightning Network'' or ''ZK-rollups,'' where only final settlement is on the main chain tend to address these issues. However, one could always argue that this often compromises some aspects of security and/or decentralization to achieve high TPS.

The trilemma was first introduced by Vitalik Buterin<ref>https://en.wikipedia.org/wiki/Vitalik_Buterin</ref>, one of the co-founders of Ethereum network. The problems he identified are real. There seem to be no obvious solutions that can accomplish all three goals at the same time. Therefore, all proposed solutions revolve around reducing "opportunity costs" focusing only on satisfying partial goals.

Treating the blockchain network as an infrastructure for transaction processing, the blockchain protocol solved service reliability problem but not performance challenge. The legacy infrastructure scaling dilemma: performance against reliability remains (where "infrastructure reliability" also does not have a commonly accepted definition). Fortunately these metrics, although important, are non-critical. Solutions that have been proposed have had varying opportunity costs. For many years, there were no obvious solutions that addressed all three blockchain goals (security, decentralization and scalability).
== Statistic Multiplexed Computing (SMC) ==
The principle of using unreliable components to build an arbitrarily reliable system was first lectured by von Neumann in the early 1950s<ref>https://static.ias.edu/pitp/archive/2012files/Probabilistic_Logics.pdf</ref>. The original idea was to use probabilistic logic to quantify the arbitrary reliability of a system by multiplexing all components. This theory was applied to the construction of Internet protocols to deliver the "best effort" reliability. Incidentally, best effort reliability also enabled "best effort" performance which in turn enabled unlimited scalability of the Internet. For emerging web3.0 technologies, it is important to apply the same methodology to both centralized and decentralized computing for seamless technology migration and integration. For historical arguments, click [[SMC|'''''here''''']].

== Definitions ==
'''Infrastructure scalability''' does not have a commonly accepted definition. It helps to define the challenging metrics more precisely before the infrastructure protocol design. In the following, for definitions #1 and #2, the word "'''infrastructure'''" means any '''application running on the infrastructure.'''

# '''Infrastructure Reliability''': MTBF (mean time between failure) = <math>\frac{\sum ((Start-Of-Downtime) - (Start-of-uptime)) }{No-of-failures}</math>
# '''Infrastructure Performance''': <math>\frac{No-of-Transactions}{Second}</math>
# '''Infrastructure Scalability''': Expanding the infrastructure in number of processors, networks or storage should have '''incrementally better''' impacts on application reliability and performance.
# '''Record Immutability''': For transaction ledgers, all confirmed records and changes are final. This is required by the blockchain protocol.
Note that in practice, record immutability is much harder to achieve than expected. There are two challenges, a) 51% attacks can literally wipe out all histories if successful, and b) for protocols require all nodes to hold independently verified ledger, such as the Bitcoin, the storage requirement grows approximately 50GB per month.

== 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 and considered.

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 crashe'''s <ref>https://groups.csail.mit.edu/tds/papers/Lynch/jacm93.pdf</ref>. The laws of physics regarding component reliability <ref>Encyclopedia of Physical Science and Technology, Editor-in-Chief Robert A. Meyers, [[index.php?title=Special:BookSources/9780122274107|ISBN 978-0-12-227410-7]], 2001</ref> show that '''100% component reliability is not possible.''' These facts require that the infrastructure protocol (program-program communication protocol) provide '''complete component (processing, networking and storage) decoupling''' from application program logics. This decoupling requirement forces the protocol to exploit "decentralized" or "stateless" components that the legacy infrastructure protocols, such as message passing interface (MPI), remote procedure call (RPC) and remote method invocation (RMI), cannot handle. The blockchain protocol is an example of a "best effort" availability protocol.

Quantifying infrastructure reliability can be traced back to the computer pioneer von Neumann. In addition to his contribution to computer architecture, von Neumann also penned a study on building reliable systems using unreliable components using probabilistic logics, in early fifties <ref>https://static.ias.edu/pitp/archive/2012files/Probabilistic_Logics.pdf</ref>. The 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 "best effort" reliability. Ironically, this best effort reliability also enabled the Internet's infinite scalability -- the benefit we enjoy now and into the future.

The Bitcoin protocol exploits multiple anonymous decoupled (or decentralized) computers connected through the Internet protocol. Judging from the Bitcoin network's reliability to date <ref>https://buybitcoinworldwide.com/bitcoin-downtime/</ref>, von Neumann's theory seems working well.

The '''second challenge''' involves infrastructure performance. Since the infrastructure must deploy multiple computing, networking and storage components, unless all components can be fully exploited at 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 lack this capability.

'''The infrastructure scalability challenge''' is automatically resolved once the performance challenge is resolved without negatively impacting reliability -- "best effort" performance" meets "best effort reliability". This requires inductive performance and reliability measures or deliveries.

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, an inductive statistic multiplexed blockchain protocol is needed to meet the scalability challenge. Non-inductive solutions such as fixed chain "sharding" or "Danksharding" <ref>https://ethereum.org/en/roadmap/danksharding/</ref> will only increase protocol development complexity with persistent performance walls.

== A Scalability Solution ==
An effective scalability solution can have two practical assumptions:

* The computation problem size can expand indefinitely, since every useful infrastructure is expected to solve bigger problems.

*Computing and network resources will continue to grow indefinitely, into the future.
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 <ref>https://en.wikipedia.org/wiki/Amdahl%27s_law</ref> and Gustafson's Law <ref>https://en.wikipedia.org/wiki/Gustafson%27s_law</ref>.

The Amdahl's Law assumes 0<= ''s'' <=1 percentage of serial instructions that cannot be parallelized. Then the ''(1-s)'' percentage of instructions can be accelerated using ''p'' processors.

<nowiki>{{center |</nowiki>
* Speedup(p) = <math>{1 \over s + {(1-s) \over p}}</math> (1)
* Speedup(<math>\lim_{p \to \infty}</math>) = <math>\frac{1}{s}</math> (2)
<nowiki>}}</nowiki>
Although quantifying ''s'' requires additional information, such as the problem size, the law is applicable to programs solving any problem size with a known ''s''. The limit of speedup (2) also does not depend on problem size. However, Amdahl used programs solving fixed problem sizes to argue the validity of not building parallel machines with too many processors. Since then assuming fixed problem size using p processors has been the norm in interpreting Amdahl's law in the past. This assumption has led to the dismal speedup predictions.[[File:Amdahl's Law.png|thumb|Amdahl's Law Speedup Predictions|center]]The traditional Amdahl's Law interpretation seems to suggest parallel performances following the economic law of diminishing of returns.

In 1988, Gustafson and Barsis at the Sandia National Laboratory conducted parallel computing experiments that seem to suggest potential infinite speedup.

Gustafson's while Gustafson's Law seems to lead to 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 mainframe computer architectures. In the past decades, these laws have been used to support computing system experiments and constructions.
[[File:Gustafson.png|thumb|Gustafson's Law|center]]
A careful examination revealed that the Gustafson's Law cannot scale mathematically since the are mathematically dependent <ref>https://cis.temple.edu/~shi/wwwroot/shi/public_html/docs/amdahl/amdahl.html</ref> where Amdahl's formulation has a tight peak performance bound <math>\left ( \frac{1}{x} \right )</math> 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 <math>\left ( \frac{1}{x} \right )</math>, when <math>x \Rightarrow 0</math>, the performance will asymptotically approach to <math>\infty</math>, when <math>x \Rightarrow 1</math> the speedup <math>\Rightarrow</math> 1. Thus, if the computing problem's size is fixed, x will eventually approach to 1 as the number of processors increases -- economic law of diminishing of return. If the problem size is open (solving bigger problems), then increasing the number of processors will force x <math>\Rightarrow</math> 0, thus speedup <math>\Rightarrow</math> <math>\infty</math>. Gustafson's Law uses a recurrence relation based on practical time measurements. It is not possible to derive a mathematical speedup bound.

Applying these laws in practice need to quantify <math>\chi</math> for practical parallel program which has been proven very hard if not impossible. Gustafson's formula was derived from times by running actual parallel programs. Brining the two formulation together makes quantifying <math>\chi</math> in Amdahl's Law possible. Thus, both law actually refer to the same mathematical abstraction. Gustafson's formula assisted in quantifying the percentage of serial computing through program experiments. Neither should be directly used for speedup prediction alone.

This model can be validated in practice when developers simply increasing the problem size to use more parallel processors.
[[File:1overx-function resized.png|thumb|294x294px|Amdalh's Law and Peak Parallel Performance|center]]

A classical example is the TOP500 supercomputer benchmarks (linear solvers) that have open problem sizes for all manufacturers to compete in the world's fastest supercomputer race <ref>https://www.top500.org/</ref> .
[[File:Supercomputers-history.png|center|thumb]]
In practical blockchain applications, the number of transactions to be processed will increase without a known limit. The ledger storage will continue to grow. In practice, the available computing, networking and storage components will continue to grow without limits enabled by the networking protocols. Therefore a statistic multiplexed computing blockchain can meet any future application needs given proper economic incentives. The infrastructure no longer has the structural deficiency.

== Action Plan ==

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.

For Toichain protocol design, we choose Bitcoin 24.0.1 as the base line protocol by replacing the PoW consensus by PoS consensus and injecting SMC components into the protocol processing signaling for parallel computing.

This surprising result is also applicable to ledger storage. Without multiplexing, the blockchain ledger storage will eventually saturate all nodes causing the chain to collapse. The SMC blockchain protocol promises to hold the true finality of all transactions in perpetuity by multiplexing all storage resources while keeping the replication factor to a constant.

These discussions follow the inductive logic of the Law of Large Numbers <ref>https://www.sciencedirect.com/topics/mathematics/laws-of-large-number</ref>.

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

= SMC Proof of Stake Protocol =
Existing PoS protocol designs revolved around staking policies and randomness of the selection algorithm. Considering infrastructure scalability will add much complexity to the design. The examples include chain sharding and Danksharding <ref>https://ethereum.org/en/roadmap/danksharding/</ref>.

The challenge is complex -- we must deliver very high performance without compromising security and reliability of the network.

Technically, transaction replication and parallel processing were considered dangerous <ref>https://pages.cs.wisc.edu/~yxy/cs764-f20/papers/replication.pdf</ref> due to the potential race conditions (or double-spend problem). The blockchain protocol resolved the double-spending problem. It did not solve the parallel processing performance problem.

According to Professor Michael Flynn, there are three high-level parallel processing topologies: SIMD (single instruction multiple data), MIMD (multiple instructions multiple data), and pipeline (MISD - multiple instructions single data stream) <ref>https://link.springer.com/referenceworkentry/10.1007/978-0-387-09766-4_2</ref>. However, for eliminating double-spending, all transactions must be serialized, since each block may contain transactions affecting transactions in multiple other blocks. "Race conditions" and non-deterministic results are not allowed. Then the only possible topology entry is pipeline. This means for POS protocol, we must build a pipeline of transaction blocks to be validated without compromising network security and reliability.
[[File:Flynns-Taxonomy-of-Computer-Architectures.png|center|thumb|Parallel Processing Topologies]]
The problem is that the nature of the blockchain protocol is that all nodes run independently in parallel with little communication with other nodes via "gossip" protocols. It is far easier to force all nodes store the entire ledger than forcing them to form any pipeline and store partial chain data.

=== ACAN (Active Content Addressable Network) [U.S. and Other Patents Pending] ===
ACAN is a high-level data '''''communication and synchronization protocol''''' that completely decouples all hardware components from communicating programs. The need for complete component decoupling was implemented in the original blockchain protocol via "gossip" protocol. This delivered blockchain's high availability and security. The simple "gossip" implementation in existing protocols is insufficient for parallel processing signaling.

The following figure illustrates the concept of ACAN (active content addressable networking) using UVR (unidirectional virtual ring) architecture. The illustrated implementation uses the Tuple Space resource tagging method and gossip protocol for UVR implementation.
[[File:SMC Architecture with ACAN.png|center|thumb|243x243px|SMC Architecture with ACAN]]

ACAN supports three simple APIs:

# '''read'''(&''key'', &''value''): ''key'' holds a search pattern in a "tuple space" where all nodes are connected. ''value'' holds the matched tuple, if any. This is a blocking call that a requesting program will be blocked until a pattern-matched tuple is found. The matching tuple remains in the "tuple space".
# '''get'''(&key, &value): Same as the "read()" API, except that the matching tuple is removed from the "tuple space".
# '''put'''(key, value): Inserts <key, value> into the "tuple space".

The use of "gossip" protocol can accelerate ACAN network saturation time. Applications running on ACAN will automatically form parallel processing topologies: pipeline, SIMD and MIMD without violating the serialization needs of transaction block validation. Replication factor can also be dynamically controlled to spread replicated blocks in randomly chosen hosts.

The highly parallel nature of the blockchain protocol will automatically implement the SMC principle in real time.

The critical feature of this dynamic SMC pipelined architecture is the inductive scaling feature.
[[File:Pipeline Parallel Processing.png|center|thumb|247x247px|Pipeline Parallel Processing]]

The speed up of a pipeline can be represented as: <math>SpeedUp = \left ( \frac{p\centerdot b}{p + (b-p)} \right )</math>, where p = number of processors in the pipeline, b = total blocks to be processed. Take the number of blocks to infinity: <math>SpeedUp = \left ( \frac{p\centerdot b}{p + (b-p)} \right )=>\lim (b\Rightarrow\infty)(\frac{p}{\frac{p}{b}+1-\frac{p}{b}}) = p</math>

This means that as long as there are enough blocks to be processed, the entire chain's performance will be abound-bounded to the number of nodes in the pipeline.

For illustration purposes, the variation of block processing times was not considered in the above calculations. To see the power of pipeline parallelism, the automobile manufacturing processes illustrate a similar situation. The Hyundai Motor Company's production pipelines can produce 3,835 vehicles per day and 1.4M per year<ref>https://en.wikipedia.org/wiki/List_of_Hyundai_Motor_Company_manufacturing_facilities</ref>.

== Toichain Tokens ==
Toichain token is TOIN. There are 50,000,000,000 TOINs for the Alpha Release. There are air-drop tokens for early adopters, 1,000 TOIN each. Users need to register to download a toichain wallet to receive the payment. Citizenship is checked and verified to ensure that US citizens do not apply. The minimal staking contract is 10 TOINs.

== Non-Fungible Tokens ==
The TestNet Release of toichain protocol will support embedding arbitrary data in an "OP_RETURN" transaction that will be permanently recorded on the chain. Unlike the ordinal NFT <ref>https://blog.chain.link/ordinals-bitcoin-nfts/</ref> or NFT (non-fungible token) on other chains, these transactions cannot be altered or removed.

There are practical applications for these forever NFTs. Once Taproot is enabled on toichain, ordinal NFTs (BRC-20) will also be supported. Unlike the original Bitcoin network where BRC-20 craze has created massive network congestion<ref>https://beincrypto.com/learn/brc-20-token/</ref>, all transactions will be processed promptly in toichain without congestion or scaling problems.
== Toichain TestNet Launch ==
The toichain testnet launch will enable users to interact with one another through simple payments, just like the original Bitcoin network. Forever NFTs are supported. Smart contracts will be supported on a later date.

= References =
<references />

Consult the [[mediawikiwiki:Special:MyLanguage/Help:Contents|User's Guide]] for information on using the wiki software.

Main Page

2024-10-05T19:33:19Z

Justin: /* A Scalability Solution */

= <strong><big>'''Welcome to Toi-Twiki -- A Toichain Wiki'''</big></strong> =
This is the unofficial Toichain wiki site. Content is subject to changes.
---------------------------

= '''Introduction''' =
The blockchain protocol was introduced in a seminal paper entitled "Bitcoin: A peer-to-peer Electronic Cash System" <ref>https://bitcoin.org/bitcoin.pdf</ref> by Satoshi Nakamoto in 2008. Although there were previous peer-to-peer file-sharing projects such as Napster <ref>https://www.napster.com/us</ref>, BitTorrent <ref>https://www.bittorrent.com/</ref> and other electronic currency/file sharing applications, Bitcoin is the most enduring among the 23,000+ blockchains. Unlike other cryptocurrencies, the Bitcoin is often referred to as "digital gold" since the total coin supply is limited to 21 million (hard-coded in all running programs) and the only way to earn coin is to participate in the transaction block validation process. Token(or coin) supply and their disbursement policies differ among protocols.

The most attractive common blockchain features are 1) a decentralized consensus-driven decision making process and 2) a step-by-step cryptographic proving system. While blockchain is best known as a cryptocurrency transaction processing and record-keeping system, there are many other applications that can benefit from the secure storage, reliable transaction ledgers, fault tolerance and tamper resistance features.

== Algorithm vs. Protocol ==
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 ==
A good consensus protocol in a blockchain system has at least four properties:

# Fault tolerance to defend failures caused by natural disasters and human hacks or accidents
# Byzantine failure tolerance to defend exploitation by colluding parties
# Centralization avoidance to prevent corruptions in the decision making process
# Source code tamper resistance to automatically reject malicious attacks

Without assuming all nodes are active at all times, the blockchain relies on "gossip" protocol to communicate with other nodes. There are two popular types of consensus protocols: Proof of Work ('''PoW''') <ref>https://en.wikipedia.org/wiki/Proof_of_work</ref> or Proof of Stake ('''PoS''') <ref>https://www.investopedia.com/terms/p/proof-stake-pos.asp</ref>. Others include Proof of Possession('''PoP''')<ref>https://identityserver4.readthedocs.io/en/latest/topics/pop.html</ref> and Proof of History('''PoH''')<ref>https://www.infoworld.com/article/3666736/solana-blockchain-and-the-proof-of-history.html</ref>. The ultimate goal is to eliminate double-spending. Since most projects are open source, it's easy for a malicious actor to tamper a few nodes. This shouldn't compromise network integrity.

The Bitcoin network uses PoW which forces participating miners to compete for the fastest hashing rate by solving a computational cryptographic puzzle. Although it withstood more than 14 years of use, Bitcoin has been criticized for escalating electricity consumption <ref>https://www.forbes.com/advisor/investing/cryptocurrency/bitcoins-energy-usage-explained/</ref>. Other blockchain designs have experienced different challenges. For example, the PoH network Solana suffered multiple single-point-failure incidents <ref>https://messari.io/report/solana-analyzing-downtimes-statistics-and-ecosystem-development</ref>. All protocols struggle to combat scaling challenges. All are susceptible to 51% attacks <ref>https://originstamp.com/blog/has-there-ever-been-a-51-attack-on-bitcoin/#notable-51-attacks</ref>.

Since 2009, Bitcoin has proven to be the strongest and least susceptible to common hacks <ref>https://www.theguardian.com/technology/2014/mar/18/history-of-bitcoin-hacks-alternative-currency</ref>. As the PoW puzzle difficulty has increased dramatically over the years, the probability of a 51% attack on the Bitcoin network becomes more difficult. PoS protocols can save more than 90% energy consumption compared to PoW chains. But PoS chains have higher risks than PoW chains since a stolen coin will grow in PoS chains (for increased probability to be selected) forever but not in PoW chains (only hash rates count). PoS community governance rules can mitigate the voting power centralization problem. Staking and slashing policies can incentivize good behaviors and punish bad ones. In either case, double-spend is very expensive and difficult. According to Forbes, there are 80 cryptocurrencies that use PoS protocols at the time of this writing.

There are approximately 1,000 blockchains in four types: public, private, consortium, and permissioned <ref>https://increditools.com/blockchains/</ref>.

== Cryptographic Proofs ==
Bitcoin 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.

== Centralized vs. Decentralized Applications ==
The Bitcoin protocol enabled decentralized processing of traditionally centrally processed transactions without any trusted third-party. It inspired many decentralized financial applications, especially for applications with very long payment chains. However for fraud prevention and meeting financial regulatory requirements, many practical applications still require KYC (know your customer) checks. It is not possible to eliminate all trusted third parties, especially for custodial financial applications. There is a clear need for decentralized processing of trusted authority applications.

== Blockchain Trilemma ==
Blockchain protocols have three common aspects (goals): '''security''', '''decentralization''' and '''scalability''' -- these three terms do not have precise definitions but are intuitively understood <ref>https://sensoriumxr.com/articles/what-is-the-blockchain-trilemma</ref>. To date, 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.

A major shortcoming is scalability. Since all nodes verify each transaction independently, they need to store all the information required for it. As the chain grows, this burdens all nodes in the network. There are workarounds by limiting the amount of data stored on some nodes and exploiting the network to retrieve required information, such as the ''Limited/Light Nodes'' in Bitcoin network. Vast majority nodes are still full nodes in the existing Bitcoin network. Transaction processing speed often expressed ''as transactions per second(TPS) of'' blockchain have to exceed TPS ratings of credit card payment systems like VISA or MasterCard to reap the full benefits of blockchain. This is a tough problem and increasing the block size and/or reducing the block time or difficulty isn't a solution<ref>https://medium.com/coinmonks/blockchain-scaling-30c9e1b7db1b</ref>. Since blockchain TPS is very low, the transaction fees is often very high. This discourages public adoption. Layer 2 solution like ''Lightning Network'' or ''ZK-rollups,'' where only final settlement is on the main chain tend to address these issues. However, one could always argue that this often compromises some aspects of security and/or decentralization to achieve high TPS.

The trilemma was first introduced by Vitalik Buterin<ref>https://en.wikipedia.org/wiki/Vitalik_Buterin</ref>, one of the co-founders of Ethereum network. The problems he identified are real. There seem to be no obvious solutions that can accomplish all three goals at the same time. Therefore, all proposed solutions revolve around reducing "opportunity costs" focusing only on satisfying partial goals.

Treating the blockchain network as an infrastructure for transaction processing, the blockchain protocol solved service reliability problem but not performance challenge. The legacy infrastructure scaling dilemma: performance against reliability remains (where "infrastructure reliability" also does not have a commonly accepted definition). Fortunately these metrics, although important, are non-critical. Solutions that have been proposed have had varying opportunity costs. For many years, there were no obvious solutions that addressed all three blockchain goals (security, decentralization and scalability).
== Statistic Multiplexed Computing (SMC) ==
The principle of using unreliable components to build an arbitrarily reliable system was first lectured by von Neumann in the early 1950s<ref>https://static.ias.edu/pitp/archive/2012files/Probabilistic_Logics.pdf</ref>. The original idea was to use probabilistic logic to quantify the arbitrary reliability of a system by multiplexing all components. This theory was applied to the construction of Internet protocols to deliver the "best effort" reliability. Incidentally, best effort reliability also enabled "best effort" performance which in turn enabled unlimited scalability of the Internet. For emerging web3.0 technologies, it is important to apply the same methodology to both centralized and decentralized computing for seamless technology migration and integration. For historical arguments, click [[SMC|'''''here''''']].

== Definitions ==
'''Infrastructure scalability''' does not have a commonly accepted definition. It helps to define the challenging metrics more precisely before the infrastructure protocol design. In the following, for definitions #1 and #2, the word "'''infrastructure'''" means any '''application running on the infrastructure.'''

# '''Infrastructure Reliability''': MTBF (mean time between failure) = <math>\frac{\sum ((Start-Of-Downtime) - (Start-of-uptime)) }{No-of-failures}</math>
# '''Infrastructure Performance''': <math>\frac{No-of-Transactions}{Second}</math>
# '''Infrastructure Scalability''': Expanding the infrastructure in number of processors, networks or storage should have '''incrementally better''' impacts on application reliability and performance.
# '''Record Immutability''': For transaction ledgers, all confirmed records and changes are final. This is required by the blockchain protocol.
Note that in practice, record immutability is much harder to achieve than expected. There are two challenges, a) 51% attacks can literally wipe out all histories if successful, and b) for protocols require all nodes to hold independently verified ledger, such as the Bitcoin, the storage requirement grows approximately 50GB per month.

== 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 and considered.

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 crashe'''s <ref>https://groups.csail.mit.edu/tds/papers/Lynch/jacm93.pdf</ref>. The laws of physics regarding component reliability <ref>Encyclopedia of Physical Science and Technology, Editor-in-Chief Robert A. Meyers, [[index.php?title=Special:BookSources/9780122274107|ISBN 978-0-12-227410-7]], 2001</ref> show that '''100% component reliability is not possible.''' These facts require that the infrastructure protocol (program-program communication protocol) provide '''complete component (processing, networking and storage) decoupling''' from application program logics. This decoupling requirement forces the protocol to exploit "decentralized" or "stateless" components that the legacy infrastructure protocols, such as message passing interface (MPI), remote procedure call (RPC) and remote method invocation (RMI), cannot handle. The blockchain protocol is an example of a "best effort" availability protocol.

Quantifying infrastructure reliability can be traced back to the computer pioneer von Neumann. In addition to his contribution to computer architecture, von Neumann also penned a study on building reliable systems using unreliable components using probabilistic logics, in early fifties <ref>https://static.ias.edu/pitp/archive/2012files/Probabilistic_Logics.pdf</ref>. The 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 "best effort" reliability. Ironically, this best effort reliability also enabled the Internet's infinite scalability -- the benefit we enjoy now and into the future.

The Bitcoin protocol exploits multiple anonymous decoupled (or decentralized) computers connected through the Internet protocol. Judging from the Bitcoin network's reliability to date <ref>https://buybitcoinworldwide.com/bitcoin-downtime/</ref>, von Neumann's theory seems working well.

The '''second challenge''' involves infrastructure performance. Since the infrastructure must deploy multiple computing, networking and storage components, unless all components can be fully exploited at 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 lack this capability.

'''The infrastructure scalability challenge''' is automatically resolved once the performance challenge is resolved without negatively impacting reliability -- "best effort" performance" meets "best effort reliability". This requires inductive performance and reliability measures or deliveries.

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, an inductive statistic multiplexed blockchain protocol is needed to meet the scalability challenge. Non-inductive solutions such as fixed chain "sharding" or "Danksharding" <ref>https://ethereum.org/en/roadmap/danksharding/</ref> will only increase protocol development complexity with persistent performance walls.

== A Scalability Solution ==
An effective scalability solution can have two practical assumptions:

* The computation problem size can expand indefinitely, since every useful infrastructure is expected to solve bigger problems.

*Computing and network resources will continue to grow indefinitely, into the future.
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 <ref>https://en.wikipedia.org/wiki/Amdahl%27s_law</ref> and Gustafson's Law <ref>https://en.wikipedia.org/wiki/Gustafson%27s_law</ref>.

The Amdahl's Law assumes 0<= ''s'' <=1 percentage of serial instructions that cannot be parallelized. Then the ''(1-s)'' percentage of instructions can be accelerated using ''p'' processors.

<nowiki>{{center</nowiki>
* Speedup(p) = <math>{1 \over s + {(1-s) \over p}}</math> (1)
* Speedup(<math>\lim_{p \to \infty}</math>) = <math>\frac{1}{s}</math> (2)
<nowiki>}}</nowiki>
Although quantifying ''s'' requires additional information, such as the problem size, the law is applicable to programs solving any problem size with a known ''s''. The limit of speedup (2) also does not depend on problem size. However, Amdahl used programs solving fixed problem sizes to argue the validity of not building parallel machines with too many processors. Since then assuming fixed problem size using p processors has been the norm in interpreting Amdahl's law in the past. This assumption has led to the dismal speedup predictions.[[File:Amdahl's Law.png|thumb|Amdahl's Law Speedup Predictions|center]]The traditional Amdahl's Law interpretation seems to suggest parallel performances following the economic law of diminishing of returns.

In 1988, Gustafson and Barsis at the Sandia National Laboratory conducted parallel computing experiments that seem to suggest potential infinite speedup.

Gustafson's while Gustafson's Law seems to lead to 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 mainframe computer architectures. In the past decades, these laws have been used to support computing system experiments and constructions.
[[File:Gustafson.png|thumb|Gustafson's Law|center]]
A careful examination revealed that the Gustafson's Law cannot scale mathematically since the are mathematically dependent <ref>https://cis.temple.edu/~shi/wwwroot/shi/public_html/docs/amdahl/amdahl.html</ref> where Amdahl's formulation has a tight peak performance bound <math>\left ( \frac{1}{x} \right )</math> 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 <math>\left ( \frac{1}{x} \right )</math>, when <math>x \Rightarrow 0</math>, the performance will asymptotically approach to <math>\infty</math>, when <math>x \Rightarrow 1</math> the speedup <math>\Rightarrow</math> 1. Thus, if the computing problem's size is fixed, x will eventually approach to 1 as the number of processors increases -- economic law of diminishing of return. If the problem size is open (solving bigger problems), then increasing the number of processors will force x <math>\Rightarrow</math> 0, thus speedup <math>\Rightarrow</math> <math>\infty</math>. Gustafson's Law uses a recurrence relation based on practical time measurements. It is not possible to derive a mathematical speedup bound.

Applying these laws in practice need to quantify <math>\chi</math> for practical parallel program which has been proven very hard if not impossible. Gustafson's formula was derived from times by running actual parallel programs. Brining the two formulation together makes quantifying <math>\chi</math> in Amdahl's Law possible. Thus, both law actually refer to the same mathematical abstraction. Gustafson's formula assisted in quantifying the percentage of serial computing through program experiments. Neither should be directly used for speedup prediction alone.

This model can be validated in practice when developers simply increasing the problem size to use more parallel processors.
[[File:1overx-function resized.png|thumb|294x294px|Amdalh's Law and Peak Parallel Performance|center]]

A classical example is the TOP500 supercomputer benchmarks (linear solvers) that have open problem sizes for all manufacturers to compete in the world's fastest supercomputer race <ref>https://www.top500.org/</ref> .
[[File:Supercomputers-history.png|center|thumb]]
In practical blockchain applications, the number of transactions to be processed will increase without a known limit. The ledger storage will continue to grow. In practice, the available computing, networking and storage components will continue to grow without limits enabled by the networking protocols. Therefore a statistic multiplexed computing blockchain can meet any future application needs given proper economic incentives. The infrastructure no longer has the structural deficiency.

== Action Plan ==

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.

For Toichain protocol design, we choose Bitcoin 24.0.1 as the base line protocol by replacing the PoW consensus by PoS consensus and injecting SMC components into the protocol processing signaling for parallel computing.

This surprising result is also applicable to ledger storage. Without multiplexing, the blockchain ledger storage will eventually saturate all nodes causing the chain to collapse. The SMC blockchain protocol promises to hold the true finality of all transactions in perpetuity by multiplexing all storage resources while keeping the replication factor to a constant.

These discussions follow the inductive logic of the Law of Large Numbers <ref>https://www.sciencedirect.com/topics/mathematics/laws-of-large-number</ref>.

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

= SMC Proof of Stake Protocol =
Existing PoS protocol designs revolved around staking policies and randomness of the selection algorithm. Considering infrastructure scalability will add much complexity to the design. The examples include chain sharding and Danksharding <ref>https://ethereum.org/en/roadmap/danksharding/</ref>.

The challenge is complex -- we must deliver very high performance without compromising security and reliability of the network.

Technically, transaction replication and parallel processing were considered dangerous <ref>https://pages.cs.wisc.edu/~yxy/cs764-f20/papers/replication.pdf</ref> due to the potential race conditions (or double-spend problem). The blockchain protocol resolved the double-spending problem. It did not solve the parallel processing performance problem.

According to Professor Michael Flynn, there are three high-level parallel processing topologies: SIMD (single instruction multiple data), MIMD (multiple instructions multiple data), and pipeline (MISD - multiple instructions single data stream) <ref>https://link.springer.com/referenceworkentry/10.1007/978-0-387-09766-4_2</ref>. However, for eliminating double-spending, all transactions must be serialized, since each block may contain transactions affecting transactions in multiple other blocks. "Race conditions" and non-deterministic results are not allowed. Then the only possible topology entry is pipeline. This means for POS protocol, we must build a pipeline of transaction blocks to be validated without compromising network security and reliability.
[[File:Flynns-Taxonomy-of-Computer-Architectures.png|center|thumb|Parallel Processing Topologies]]
The problem is that the nature of the blockchain protocol is that all nodes run independently in parallel with little communication with other nodes via "gossip" protocols. It is far easier to force all nodes store the entire ledger than forcing them to form any pipeline and store partial chain data.

=== ACAN (Active Content Addressable Network) [U.S. and Other Patents Pending] ===
ACAN is a high-level data '''''communication and synchronization protocol''''' that completely decouples all hardware components from communicating programs. The need for complete component decoupling was implemented in the original blockchain protocol via "gossip" protocol. This delivered blockchain's high availability and security. The simple "gossip" implementation in existing protocols is insufficient for parallel processing signaling.

The following figure illustrates the concept of ACAN (active content addressable networking) using UVR (unidirectional virtual ring) architecture. The illustrated implementation uses the Tuple Space resource tagging method and gossip protocol for UVR implementation.
[[File:SMC Architecture with ACAN.png|center|thumb|243x243px|SMC Architecture with ACAN]]

ACAN supports three simple APIs:

# '''read'''(&''key'', &''value''): ''key'' holds a search pattern in a "tuple space" where all nodes are connected. ''value'' holds the matched tuple, if any. This is a blocking call that a requesting program will be blocked until a pattern-matched tuple is found. The matching tuple remains in the "tuple space".
# '''get'''(&key, &value): Same as the "read()" API, except that the matching tuple is removed from the "tuple space".
# '''put'''(key, value): Inserts <key, value> into the "tuple space".

The use of "gossip" protocol can accelerate ACAN network saturation time. Applications running on ACAN will automatically form parallel processing topologies: pipeline, SIMD and MIMD without violating the serialization needs of transaction block validation. Replication factor can also be dynamically controlled to spread replicated blocks in randomly chosen hosts.

The highly parallel nature of the blockchain protocol will automatically implement the SMC principle in real time.

The critical feature of this dynamic SMC pipelined architecture is the inductive scaling feature.
[[File:Pipeline Parallel Processing.png|center|thumb|247x247px|Pipeline Parallel Processing]]

The speed up of a pipeline can be represented as: <math>SpeedUp = \left ( \frac{p\centerdot b}{p + (b-p)} \right )</math>, where p = number of processors in the pipeline, b = total blocks to be processed. Take the number of blocks to infinity: <math>SpeedUp = \left ( \frac{p\centerdot b}{p + (b-p)} \right )=>\lim (b\Rightarrow\infty)(\frac{p}{\frac{p}{b}+1-\frac{p}{b}}) = p</math>

This means that as long as there are enough blocks to be processed, the entire chain's performance will be abound-bounded to the number of nodes in the pipeline.

For illustration purposes, the variation of block processing times was not considered in the above calculations. To see the power of pipeline parallelism, the automobile manufacturing processes illustrate a similar situation. The Hyundai Motor Company's production pipelines can produce 3,835 vehicles per day and 1.4M per year<ref>https://en.wikipedia.org/wiki/List_of_Hyundai_Motor_Company_manufacturing_facilities</ref>.

== Toichain Tokens ==
Toichain token is TOIN. There are 50,000,000,000 TOINs for the Alpha Release. There are air-drop tokens for early adopters, 1,000 TOIN each. Users need to register to download a toichain wallet to receive the payment. Citizenship is checked and verified to ensure that US citizens do not apply. The minimal staking contract is 10 TOINs.

== Non-Fungible Tokens ==
The TestNet Release of toichain protocol will support embedding arbitrary data in an "OP_RETURN" transaction that will be permanently recorded on the chain. Unlike the ordinal NFT <ref>https://blog.chain.link/ordinals-bitcoin-nfts/</ref> or NFT (non-fungible token) on other chains, these transactions cannot be altered or removed.

There are practical applications for these forever NFTs. Once Taproot is enabled on toichain, ordinal NFTs (BRC-20) will also be supported. Unlike the original Bitcoin network where BRC-20 craze has created massive network congestion<ref>https://beincrypto.com/learn/brc-20-token/</ref>, all transactions will be processed promptly in toichain without congestion or scaling problems.
== Toichain TestNet Launch ==
The toichain testnet launch will enable users to interact with one another through simple payments, just like the original Bitcoin network. Forever NFTs are supported. Smart contracts will be supported on a later date.

= References =
<references />

Consult the [[mediawikiwiki:Special:MyLanguage/Help:Contents|User's Guide]] for information on using the wiki software.

Main Page

2024-10-05T19:30:34Z

Justin: /* A Scalability Solution */

= <strong><big>'''Welcome to Toi-Twiki -- A Toichain Wiki'''</big></strong> =
This is the unofficial Toichain wiki site. Content is subject to changes.
---------------------------

= '''Introduction''' =
The blockchain protocol was introduced in a seminal paper entitled "Bitcoin: A peer-to-peer Electronic Cash System" <ref>https://bitcoin.org/bitcoin.pdf</ref> by Satoshi Nakamoto in 2008. Although there were previous peer-to-peer file-sharing projects such as Napster <ref>https://www.napster.com/us</ref>, BitTorrent <ref>https://www.bittorrent.com/</ref> and other electronic currency/file sharing applications, Bitcoin is the most enduring among the 23,000+ blockchains. Unlike other cryptocurrencies, the Bitcoin is often referred to as "digital gold" since the total coin supply is limited to 21 million (hard-coded in all running programs) and the only way to earn coin is to participate in the transaction block validation process. Token(or coin) supply and their disbursement policies differ among protocols.

The most attractive common blockchain features are 1) a decentralized consensus-driven decision making process and 2) a step-by-step cryptographic proving system. While blockchain is best known as a cryptocurrency transaction processing and record-keeping system, there are many other applications that can benefit from the secure storage, reliable transaction ledgers, fault tolerance and tamper resistance features.

== Algorithm vs. Protocol ==
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 ==
A good consensus protocol in a blockchain system has at least four properties:

# Fault tolerance to defend failures caused by natural disasters and human hacks or accidents
# Byzantine failure tolerance to defend exploitation by colluding parties
# Centralization avoidance to prevent corruptions in the decision making process
# Source code tamper resistance to automatically reject malicious attacks

Without assuming all nodes are active at all times, the blockchain relies on "gossip" protocol to communicate with other nodes. There are two popular types of consensus protocols: Proof of Work ('''PoW''') <ref>https://en.wikipedia.org/wiki/Proof_of_work</ref> or Proof of Stake ('''PoS''') <ref>https://www.investopedia.com/terms/p/proof-stake-pos.asp</ref>. Others include Proof of Possession('''PoP''')<ref>https://identityserver4.readthedocs.io/en/latest/topics/pop.html</ref> and Proof of History('''PoH''')<ref>https://www.infoworld.com/article/3666736/solana-blockchain-and-the-proof-of-history.html</ref>. The ultimate goal is to eliminate double-spending. Since most projects are open source, it's easy for a malicious actor to tamper a few nodes. This shouldn't compromise network integrity.

The Bitcoin network uses PoW which forces participating miners to compete for the fastest hashing rate by solving a computational cryptographic puzzle. Although it withstood more than 14 years of use, Bitcoin has been criticized for escalating electricity consumption <ref>https://www.forbes.com/advisor/investing/cryptocurrency/bitcoins-energy-usage-explained/</ref>. Other blockchain designs have experienced different challenges. For example, the PoH network Solana suffered multiple single-point-failure incidents <ref>https://messari.io/report/solana-analyzing-downtimes-statistics-and-ecosystem-development</ref>. All protocols struggle to combat scaling challenges. All are susceptible to 51% attacks <ref>https://originstamp.com/blog/has-there-ever-been-a-51-attack-on-bitcoin/#notable-51-attacks</ref>.

Since 2009, Bitcoin has proven to be the strongest and least susceptible to common hacks <ref>https://www.theguardian.com/technology/2014/mar/18/history-of-bitcoin-hacks-alternative-currency</ref>. As the PoW puzzle difficulty has increased dramatically over the years, the probability of a 51% attack on the Bitcoin network becomes more difficult. PoS protocols can save more than 90% energy consumption compared to PoW chains. But PoS chains have higher risks than PoW chains since a stolen coin will grow in PoS chains (for increased probability to be selected) forever but not in PoW chains (only hash rates count). PoS community governance rules can mitigate the voting power centralization problem. Staking and slashing policies can incentivize good behaviors and punish bad ones. In either case, double-spend is very expensive and difficult. According to Forbes, there are 80 cryptocurrencies that use PoS protocols at the time of this writing.

There are approximately 1,000 blockchains in four types: public, private, consortium, and permissioned <ref>https://increditools.com/blockchains/</ref>.

== Cryptographic Proofs ==
Bitcoin 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.

== Centralized vs. Decentralized Applications ==
The Bitcoin protocol enabled decentralized processing of traditionally centrally processed transactions without any trusted third-party. It inspired many decentralized financial applications, especially for applications with very long payment chains. However for fraud prevention and meeting financial regulatory requirements, many practical applications still require KYC (know your customer) checks. It is not possible to eliminate all trusted third parties, especially for custodial financial applications. There is a clear need for decentralized processing of trusted authority applications.

== Blockchain Trilemma ==
Blockchain protocols have three common aspects (goals): '''security''', '''decentralization''' and '''scalability''' -- these three terms do not have precise definitions but are intuitively understood <ref>https://sensoriumxr.com/articles/what-is-the-blockchain-trilemma</ref>. To date, 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.

A major shortcoming is scalability. Since all nodes verify each transaction independently, they need to store all the information required for it. As the chain grows, this burdens all nodes in the network. There are workarounds by limiting the amount of data stored on some nodes and exploiting the network to retrieve required information, such as the ''Limited/Light Nodes'' in Bitcoin network. Vast majority nodes are still full nodes in the existing Bitcoin network. Transaction processing speed often expressed ''as transactions per second(TPS) of'' blockchain have to exceed TPS ratings of credit card payment systems like VISA or MasterCard to reap the full benefits of blockchain. This is a tough problem and increasing the block size and/or reducing the block time or difficulty isn't a solution<ref>https://medium.com/coinmonks/blockchain-scaling-30c9e1b7db1b</ref>. Since blockchain TPS is very low, the transaction fees is often very high. This discourages public adoption. Layer 2 solution like ''Lightning Network'' or ''ZK-rollups,'' where only final settlement is on the main chain tend to address these issues. However, one could always argue that this often compromises some aspects of security and/or decentralization to achieve high TPS.

The trilemma was first introduced by Vitalik Buterin<ref>https://en.wikipedia.org/wiki/Vitalik_Buterin</ref>, one of the co-founders of Ethereum network. The problems he identified are real. There seem to be no obvious solutions that can accomplish all three goals at the same time. Therefore, all proposed solutions revolve around reducing "opportunity costs" focusing only on satisfying partial goals.

Treating the blockchain network as an infrastructure for transaction processing, the blockchain protocol solved service reliability problem but not performance challenge. The legacy infrastructure scaling dilemma: performance against reliability remains (where "infrastructure reliability" also does not have a commonly accepted definition). Fortunately these metrics, although important, are non-critical. Solutions that have been proposed have had varying opportunity costs. For many years, there were no obvious solutions that addressed all three blockchain goals (security, decentralization and scalability).
== Statistic Multiplexed Computing (SMC) ==
The principle of using unreliable components to build an arbitrarily reliable system was first lectured by von Neumann in the early 1950s<ref>https://static.ias.edu/pitp/archive/2012files/Probabilistic_Logics.pdf</ref>. The original idea was to use probabilistic logic to quantify the arbitrary reliability of a system by multiplexing all components. This theory was applied to the construction of Internet protocols to deliver the "best effort" reliability. Incidentally, best effort reliability also enabled "best effort" performance which in turn enabled unlimited scalability of the Internet. For emerging web3.0 technologies, it is important to apply the same methodology to both centralized and decentralized computing for seamless technology migration and integration. For historical arguments, click [[SMC|'''''here''''']].

== Definitions ==
'''Infrastructure scalability''' does not have a commonly accepted definition. It helps to define the challenging metrics more precisely before the infrastructure protocol design. In the following, for definitions #1 and #2, the word "'''infrastructure'''" means any '''application running on the infrastructure.'''

# '''Infrastructure Reliability''': MTBF (mean time between failure) = <math>\frac{\sum ((Start-Of-Downtime) - (Start-of-uptime)) }{No-of-failures}</math>
# '''Infrastructure Performance''': <math>\frac{No-of-Transactions}{Second}</math>
# '''Infrastructure Scalability''': Expanding the infrastructure in number of processors, networks or storage should have '''incrementally better''' impacts on application reliability and performance.
# '''Record Immutability''': For transaction ledgers, all confirmed records and changes are final. This is required by the blockchain protocol.
Note that in practice, record immutability is much harder to achieve than expected. There are two challenges, a) 51% attacks can literally wipe out all histories if successful, and b) for protocols require all nodes to hold independently verified ledger, such as the Bitcoin, the storage requirement grows approximately 50GB per month.

== 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 and considered.

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 crashe'''s <ref>https://groups.csail.mit.edu/tds/papers/Lynch/jacm93.pdf</ref>. The laws of physics regarding component reliability <ref>Encyclopedia of Physical Science and Technology, Editor-in-Chief Robert A. Meyers, [[index.php?title=Special:BookSources/9780122274107|ISBN 978-0-12-227410-7]], 2001</ref> show that '''100% component reliability is not possible.''' These facts require that the infrastructure protocol (program-program communication protocol) provide '''complete component (processing, networking and storage) decoupling''' from application program logics. This decoupling requirement forces the protocol to exploit "decentralized" or "stateless" components that the legacy infrastructure protocols, such as message passing interface (MPI), remote procedure call (RPC) and remote method invocation (RMI), cannot handle. The blockchain protocol is an example of a "best effort" availability protocol.

Quantifying infrastructure reliability can be traced back to the computer pioneer von Neumann. In addition to his contribution to computer architecture, von Neumann also penned a study on building reliable systems using unreliable components using probabilistic logics, in early fifties <ref>https://static.ias.edu/pitp/archive/2012files/Probabilistic_Logics.pdf</ref>. The 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 "best effort" reliability. Ironically, this best effort reliability also enabled the Internet's infinite scalability -- the benefit we enjoy now and into the future.

The Bitcoin protocol exploits multiple anonymous decoupled (or decentralized) computers connected through the Internet protocol. Judging from the Bitcoin network's reliability to date <ref>https://buybitcoinworldwide.com/bitcoin-downtime/</ref>, von Neumann's theory seems working well.

The '''second challenge''' involves infrastructure performance. Since the infrastructure must deploy multiple computing, networking and storage components, unless all components can be fully exploited at 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 lack this capability.

'''The infrastructure scalability challenge''' is automatically resolved once the performance challenge is resolved without negatively impacting reliability -- "best effort" performance" meets "best effort reliability". This requires inductive performance and reliability measures or deliveries.

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, an inductive statistic multiplexed blockchain protocol is needed to meet the scalability challenge. Non-inductive solutions such as fixed chain "sharding" or "Danksharding" <ref>https://ethereum.org/en/roadmap/danksharding/</ref> will only increase protocol development complexity with persistent performance walls.

== A Scalability Solution ==
An effective scalability solution can have two practical assumptions:

* The computation problem size can expand indefinitely, since every useful infrastructure is expected to solve bigger problems.

*Computing and network resources will continue to grow indefinitely, into the future.
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 <ref>https://en.wikipedia.org/wiki/Amdahl%27s_law</ref> and Gustafson's Law <ref>https://en.wikipedia.org/wiki/Gustafson%27s_law</ref>.

The Amdahl's Law assumes 0<= ''s'' <=1 percentage of serial instructions that cannot be parallelized. Then the ''(1-s)'' percentage of instructions can be accelerated using ''p'' processors.

[
* Speedup(p) = <math>{1 \over s + {(1-s) \over p}}</math> (1)
* Speedup(<math>\lim_{p \to \infty}</math>) = <math>\frac{1}{s}</math> (2)
|center]
Although quantifying ''s'' requires additional information, such as the problem size, the law is applicable to programs solving any problem size with a known ''s''. The limit of speedup (2) also does not depend on problem size. However, Amdahl used programs solving fixed problem sizes to argue the validity of not building parallel machines with too many processors. Since then assuming fixed problem size using p processors has been the norm in interpreting Amdahl's law in the past. This assumption has led to the dismal speedup predictions.[[File:Amdahl's Law.png|thumb|Amdahl's Law Speedup Predictions|center]]The traditional Amdahl's Law interpretation seems to suggest parallel performances following the economic law of diminishing of returns.

In 1988, Gustafson and Barsis at the Sandia National Laboratory conducted parallel computing experiments that seem to suggest potential infinite speedup.

Gustafson's while Gustafson's Law seems to lead to 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 mainframe computer architectures. In the past decades, these laws have been used to support computing system experiments and constructions.
[[File:Gustafson.png|thumb|Gustafson's Law|center]]
A careful examination revealed that the Gustafson's Law cannot scale mathematically since the are mathematically dependent <ref>https://cis.temple.edu/~shi/wwwroot/shi/public_html/docs/amdahl/amdahl.html</ref> where Amdahl's formulation has a tight peak performance bound <math>\left ( \frac{1}{x} \right )</math> 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 <math>\left ( \frac{1}{x} \right )</math>, when <math>x \Rightarrow 0</math>, the performance will asymptotically approach to <math>\infty</math>, when <math>x \Rightarrow 1</math> the speedup <math>\Rightarrow</math> 1. Thus, if the computing problem's size is fixed, x will eventually approach to 1 as the number of processors increases -- economic law of diminishing of return. If the problem size is open (solving bigger problems), then increasing the number of processors will force x <math>\Rightarrow</math> 0, thus speedup <math>\Rightarrow</math> <math>\infty</math>. Gustafson's Law uses a recurrence relation based on practical time measurements. It is not possible to derive a mathematical speedup bound.

Applying these laws in practice need to quantify <math>\chi</math> for practical parallel program which has been proven very hard if not impossible. Gustafson's formula was derived from times by running actual parallel programs. Brining the two formulation together makes quantifying <math>\chi</math> in Amdahl's Law possible. Thus, both law actually refer to the same mathematical abstraction. Gustafson's formula assisted in quantifying the percentage of serial computing through program experiments. Neither should be directly used for speedup prediction alone.

This model can be validated in practice when developers simply increasing the problem size to use more parallel processors.
[[File:1overx-function resized.png|thumb|294x294px|Amdalh's Law and Peak Parallel Performance|center]]

A classical example is the TOP500 supercomputer benchmarks (linear solvers) that have open problem sizes for all manufacturers to compete in the world's fastest supercomputer race <ref>https://www.top500.org/</ref> .
[[File:Supercomputers-history.png|center|thumb]]
In practical blockchain applications, the number of transactions to be processed will increase without a known limit. The ledger storage will continue to grow. In practice, the available computing, networking and storage components will continue to grow without limits enabled by the networking protocols. Therefore a statistic multiplexed computing blockchain can meet any future application needs given proper economic incentives. The infrastructure no longer has the structural deficiency.

== Action Plan ==

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.

For Toichain protocol design, we choose Bitcoin 24.0.1 as the base line protocol by replacing the PoW consensus by PoS consensus and injecting SMC components into the protocol processing signaling for parallel computing.

This surprising result is also applicable to ledger storage. Without multiplexing, the blockchain ledger storage will eventually saturate all nodes causing the chain to collapse. The SMC blockchain protocol promises to hold the true finality of all transactions in perpetuity by multiplexing all storage resources while keeping the replication factor to a constant.

These discussions follow the inductive logic of the Law of Large Numbers <ref>https://www.sciencedirect.com/topics/mathematics/laws-of-large-number</ref>.

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

= SMC Proof of Stake Protocol =
Existing PoS protocol designs revolved around staking policies and randomness of the selection algorithm. Considering infrastructure scalability will add much complexity to the design. The examples include chain sharding and Danksharding <ref>https://ethereum.org/en/roadmap/danksharding/</ref>.

The challenge is complex -- we must deliver very high performance without compromising security and reliability of the network.

Technically, transaction replication and parallel processing were considered dangerous <ref>https://pages.cs.wisc.edu/~yxy/cs764-f20/papers/replication.pdf</ref> due to the potential race conditions (or double-spend problem). The blockchain protocol resolved the double-spending problem. It did not solve the parallel processing performance problem.

According to Professor Michael Flynn, there are three high-level parallel processing topologies: SIMD (single instruction multiple data), MIMD (multiple instructions multiple data), and pipeline (MISD - multiple instructions single data stream) <ref>https://link.springer.com/referenceworkentry/10.1007/978-0-387-09766-4_2</ref>. However, for eliminating double-spending, all transactions must be serialized, since each block may contain transactions affecting transactions in multiple other blocks. "Race conditions" and non-deterministic results are not allowed. Then the only possible topology entry is pipeline. This means for POS protocol, we must build a pipeline of transaction blocks to be validated without compromising network security and reliability.
[[File:Flynns-Taxonomy-of-Computer-Architectures.png|center|thumb|Parallel Processing Topologies]]
The problem is that the nature of the blockchain protocol is that all nodes run independently in parallel with little communication with other nodes via "gossip" protocols. It is far easier to force all nodes store the entire ledger than forcing them to form any pipeline and store partial chain data.

=== ACAN (Active Content Addressable Network) [U.S. and Other Patents Pending] ===
ACAN is a high-level data '''''communication and synchronization protocol''''' that completely decouples all hardware components from communicating programs. The need for complete component decoupling was implemented in the original blockchain protocol via "gossip" protocol. This delivered blockchain's high availability and security. The simple "gossip" implementation in existing protocols is insufficient for parallel processing signaling.

The following figure illustrates the concept of ACAN (active content addressable networking) using UVR (unidirectional virtual ring) architecture. The illustrated implementation uses the Tuple Space resource tagging method and gossip protocol for UVR implementation.
[[File:SMC Architecture with ACAN.png|center|thumb|243x243px|SMC Architecture with ACAN]]

ACAN supports three simple APIs:

# '''read'''(&''key'', &''value''): ''key'' holds a search pattern in a "tuple space" where all nodes are connected. ''value'' holds the matched tuple, if any. This is a blocking call that a requesting program will be blocked until a pattern-matched tuple is found. The matching tuple remains in the "tuple space".
# '''get'''(&key, &value): Same as the "read()" API, except that the matching tuple is removed from the "tuple space".
# '''put'''(key, value): Inserts <key, value> into the "tuple space".

The use of "gossip" protocol can accelerate ACAN network saturation time. Applications running on ACAN will automatically form parallel processing topologies: pipeline, SIMD and MIMD without violating the serialization needs of transaction block validation. Replication factor can also be dynamically controlled to spread replicated blocks in randomly chosen hosts.

The highly parallel nature of the blockchain protocol will automatically implement the SMC principle in real time.

The critical feature of this dynamic SMC pipelined architecture is the inductive scaling feature.
[[File:Pipeline Parallel Processing.png|center|thumb|247x247px|Pipeline Parallel Processing]]

The speed up of a pipeline can be represented as: <math>SpeedUp = \left ( \frac{p\centerdot b}{p + (b-p)} \right )</math>, where p = number of processors in the pipeline, b = total blocks to be processed. Take the number of blocks to infinity: <math>SpeedUp = \left ( \frac{p\centerdot b}{p + (b-p)} \right )=>\lim (b\Rightarrow\infty)(\frac{p}{\frac{p}{b}+1-\frac{p}{b}}) = p</math>

This means that as long as there are enough blocks to be processed, the entire chain's performance will be abound-bounded to the number of nodes in the pipeline.

For illustration purposes, the variation of block processing times was not considered in the above calculations. To see the power of pipeline parallelism, the automobile manufacturing processes illustrate a similar situation. The Hyundai Motor Company's production pipelines can produce 3,835 vehicles per day and 1.4M per year<ref>https://en.wikipedia.org/wiki/List_of_Hyundai_Motor_Company_manufacturing_facilities</ref>.

== Toichain Tokens ==
Toichain token is TOIN. There are 50,000,000,000 TOINs for the Alpha Release. There are air-drop tokens for early adopters, 1,000 TOIN each. Users need to register to download a toichain wallet to receive the payment. Citizenship is checked and verified to ensure that US citizens do not apply. The minimal staking contract is 10 TOINs.

== Non-Fungible Tokens ==
The TestNet Release of toichain protocol will support embedding arbitrary data in an "OP_RETURN" transaction that will be permanently recorded on the chain. Unlike the ordinal NFT <ref>https://blog.chain.link/ordinals-bitcoin-nfts/</ref> or NFT (non-fungible token) on other chains, these transactions cannot be altered or removed.

There are practical applications for these forever NFTs. Once Taproot is enabled on toichain, ordinal NFTs (BRC-20) will also be supported. Unlike the original Bitcoin network where BRC-20 craze has created massive network congestion<ref>https://beincrypto.com/learn/brc-20-token/</ref>, all transactions will be processed promptly in toichain without congestion or scaling problems.
== Toichain TestNet Launch ==
The toichain testnet launch will enable users to interact with one another through simple payments, just like the original Bitcoin network. Forever NFTs are supported. Smart contracts will be supported on a later date.

= References =
<references />

Consult the [[mediawikiwiki:Special:MyLanguage/Help:Contents|User's Guide]] for information on using the wiki software.

Main Page

2024-10-05T04:07:30Z

Justin: /* A Scalability Solution */

= <strong><big>'''Welcome to Toi-Twiki -- A Toichain Wiki'''</big></strong> =
This is the unofficial Toichain wiki site. Content is subject to changes.
---------------------------

= '''Introduction''' =
The blockchain protocol was introduced in a seminal paper entitled "Bitcoin: A peer-to-peer Electronic Cash System" <ref>https://bitcoin.org/bitcoin.pdf</ref> by Satoshi Nakamoto in 2008. Although there were previous peer-to-peer file-sharing projects such as Napster <ref>https://www.napster.com/us</ref>, BitTorrent <ref>https://www.bittorrent.com/</ref> and other electronic currency/file sharing applications, Bitcoin is the most enduring among the 23,000+ blockchains. Unlike other cryptocurrencies, the Bitcoin is often referred to as "digital gold" since the total coin supply is limited to 21 million (hard-coded in all running programs) and the only way to earn coin is to participate in the transaction block validation process. Token(or coin) supply and their disbursement policies differ among protocols.

The most attractive common blockchain features are 1) a decentralized consensus-driven decision making process and 2) a step-by-step cryptographic proving system. While blockchain is best known as a cryptocurrency transaction processing and record-keeping system, there are many other applications that can benefit from the secure storage, reliable transaction ledgers, fault tolerance and tamper resistance features.

== Algorithm vs. Protocol ==
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 ==
A good consensus protocol in a blockchain system has at least four properties:

# Fault tolerance to defend failures caused by natural disasters and human hacks or accidents
# Byzantine failure tolerance to defend exploitation by colluding parties
# Centralization avoidance to prevent corruptions in the decision making process
# Source code tamper resistance to automatically reject malicious attacks

Without assuming all nodes are active at all times, the blockchain relies on "gossip" protocol to communicate with other nodes. There are two popular types of consensus protocols: Proof of Work ('''PoW''') <ref>https://en.wikipedia.org/wiki/Proof_of_work</ref> or Proof of Stake ('''PoS''') <ref>https://www.investopedia.com/terms/p/proof-stake-pos.asp</ref>. Others include Proof of Possession('''PoP''')<ref>https://identityserver4.readthedocs.io/en/latest/topics/pop.html</ref> and Proof of History('''PoH''')<ref>https://www.infoworld.com/article/3666736/solana-blockchain-and-the-proof-of-history.html</ref>. The ultimate goal is to eliminate double-spending. Since most projects are open source, it's easy for a malicious actor to tamper a few nodes. This shouldn't compromise network integrity.

The Bitcoin network uses PoW which forces participating miners to compete for the fastest hashing rate by solving a computational cryptographic puzzle. Although it withstood more than 14 years of use, Bitcoin has been criticized for escalating electricity consumption <ref>https://www.forbes.com/advisor/investing/cryptocurrency/bitcoins-energy-usage-explained/</ref>. Other blockchain designs have experienced different challenges. For example, the PoH network Solana suffered multiple single-point-failure incidents <ref>https://messari.io/report/solana-analyzing-downtimes-statistics-and-ecosystem-development</ref>. All protocols struggle to combat scaling challenges. All are susceptible to 51% attacks <ref>https://originstamp.com/blog/has-there-ever-been-a-51-attack-on-bitcoin/#notable-51-attacks</ref>.

Since 2009, Bitcoin has proven to be the strongest and least susceptible to common hacks <ref>https://www.theguardian.com/technology/2014/mar/18/history-of-bitcoin-hacks-alternative-currency</ref>. As the PoW puzzle difficulty has increased dramatically over the years, the probability of a 51% attack on the Bitcoin network becomes more difficult. PoS protocols can save more than 90% energy consumption compared to PoW chains. But PoS chains have higher risks than PoW chains since a stolen coin will grow in PoS chains (for increased probability to be selected) forever but not in PoW chains (only hash rates count). PoS community governance rules can mitigate the voting power centralization problem. Staking and slashing policies can incentivize good behaviors and punish bad ones. In either case, double-spend is very expensive and difficult. According to Forbes, there are 80 cryptocurrencies that use PoS protocols at the time of this writing.

There are approximately 1,000 blockchains in four types: public, private, consortium, and permissioned <ref>https://increditools.com/blockchains/</ref>.

== Cryptographic Proofs ==
Bitcoin 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.

== Centralized vs. Decentralized Applications ==
The Bitcoin protocol enabled decentralized processing of traditionally centrally processed transactions without any trusted third-party. It inspired many decentralized financial applications, especially for applications with very long payment chains. However for fraud prevention and meeting financial regulatory requirements, many practical applications still require KYC (know your customer) checks. It is not possible to eliminate all trusted third parties, especially for custodial financial applications. There is a clear need for decentralized processing of trusted authority applications.

== Blockchain Trilemma ==
Blockchain protocols have three common aspects (goals): '''security''', '''decentralization''' and '''scalability''' -- these three terms do not have precise definitions but are intuitively understood <ref>https://sensoriumxr.com/articles/what-is-the-blockchain-trilemma</ref>. To date, 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.

A major shortcoming is scalability. Since all nodes verify each transaction independently, they need to store all the information required for it. As the chain grows, this burdens all nodes in the network. There are workarounds by limiting the amount of data stored on some nodes and exploiting the network to retrieve required information, such as the ''Limited/Light Nodes'' in Bitcoin network. Vast majority nodes are still full nodes in the existing Bitcoin network. Transaction processing speed often expressed ''as transactions per second(TPS) of'' blockchain have to exceed TPS ratings of credit card payment systems like VISA or MasterCard to reap the full benefits of blockchain. This is a tough problem and increasing the block size and/or reducing the block time or difficulty isn't a solution<ref>https://medium.com/coinmonks/blockchain-scaling-30c9e1b7db1b</ref>. Since blockchain TPS is very low, the transaction fees is often very high. This discourages public adoption. Layer 2 solution like ''Lightning Network'' or ''ZK-rollups,'' where only final settlement is on the main chain tend to address these issues. However, one could always argue that this often compromises some aspects of security and/or decentralization to achieve high TPS.

The trilemma was first introduced by Vitalik Buterin<ref>https://en.wikipedia.org/wiki/Vitalik_Buterin</ref>, one of the co-founders of Ethereum network. The problems he identified are real. There seem to be no obvious solutions that can accomplish all three goals at the same time. Therefore, all proposed solutions revolve around reducing "opportunity costs" focusing only on satisfying partial goals.

Treating the blockchain network as an infrastructure for transaction processing, the blockchain protocol solved service reliability problem but not performance challenge. The legacy infrastructure scaling dilemma: performance against reliability remains (where "infrastructure reliability" also does not have a commonly accepted definition). Fortunately these metrics, although important, are non-critical. Solutions that have been proposed have had varying opportunity costs. For many years, there were no obvious solutions that addressed all three blockchain goals (security, decentralization and scalability).
== Statistic Multiplexed Computing (SMC) ==
The principle of using unreliable components to build an arbitrarily reliable system was first lectured by von Neumann in the early 1950s<ref>https://static.ias.edu/pitp/archive/2012files/Probabilistic_Logics.pdf</ref>. The original idea was to use probabilistic logic to quantify the arbitrary reliability of a system by multiplexing all components. This theory was applied to the construction of Internet protocols to deliver the "best effort" reliability. Incidentally, best effort reliability also enabled "best effort" performance which in turn enabled unlimited scalability of the Internet. For emerging web3.0 technologies, it is important to apply the same methodology to both centralized and decentralized computing for seamless technology migration and integration. For historical arguments, click [[SMC|'''''here''''']].

== Definitions ==
'''Infrastructure scalability''' does not have a commonly accepted definition. It helps to define the challenging metrics more precisely before the infrastructure protocol design. In the following, for definitions #1 and #2, the word "'''infrastructure'''" means any '''application running on the infrastructure.'''

# '''Infrastructure Reliability''': MTBF (mean time between failure) = <math>\frac{\sum ((Start-Of-Downtime) - (Start-of-uptime)) }{No-of-failures}</math>
# '''Infrastructure Performance''': <math>\frac{No-of-Transactions}{Second}</math>
# '''Infrastructure Scalability''': Expanding the infrastructure in number of processors, networks or storage should have '''incrementally better''' impacts on application reliability and performance.
# '''Record Immutability''': For transaction ledgers, all confirmed records and changes are final. This is required by the blockchain protocol.
Note that in practice, record immutability is much harder to achieve than expected. There are two challenges, a) 51% attacks can literally wipe out all histories if successful, and b) for protocols require all nodes to hold independently verified ledger, such as the Bitcoin, the storage requirement grows approximately 50GB per month.

== 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 and considered.

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 crashe'''s <ref>https://groups.csail.mit.edu/tds/papers/Lynch/jacm93.pdf</ref>. The laws of physics regarding component reliability <ref>Encyclopedia of Physical Science and Technology, Editor-in-Chief Robert A. Meyers, [[index.php?title=Special:BookSources/9780122274107|ISBN 978-0-12-227410-7]], 2001</ref> show that '''100% component reliability is not possible.''' These facts require that the infrastructure protocol (program-program communication protocol) provide '''complete component (processing, networking and storage) decoupling''' from application program logics. This decoupling requirement forces the protocol to exploit "decentralized" or "stateless" components that the legacy infrastructure protocols, such as message passing interface (MPI), remote procedure call (RPC) and remote method invocation (RMI), cannot handle. The blockchain protocol is an example of a "best effort" availability protocol.

Quantifying infrastructure reliability can be traced back to the computer pioneer von Neumann. In addition to his contribution to computer architecture, von Neumann also penned a study on building reliable systems using unreliable components using probabilistic logics, in early fifties <ref>https://static.ias.edu/pitp/archive/2012files/Probabilistic_Logics.pdf</ref>. The 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 "best effort" reliability. Ironically, this best effort reliability also enabled the Internet's infinite scalability -- the benefit we enjoy now and into the future.

The Bitcoin protocol exploits multiple anonymous decoupled (or decentralized) computers connected through the Internet protocol. Judging from the Bitcoin network's reliability to date <ref>https://buybitcoinworldwide.com/bitcoin-downtime/</ref>, von Neumann's theory seems working well.

The '''second challenge''' involves infrastructure performance. Since the infrastructure must deploy multiple computing, networking and storage components, unless all components can be fully exploited at 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 lack this capability.

'''The infrastructure scalability challenge''' is automatically resolved once the performance challenge is resolved without negatively impacting reliability -- "best effort" performance" meets "best effort reliability". This requires inductive performance and reliability measures or deliveries.

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, an inductive statistic multiplexed blockchain protocol is needed to meet the scalability challenge. Non-inductive solutions such as fixed chain "sharding" or "Danksharding" <ref>https://ethereum.org/en/roadmap/danksharding/</ref> will only increase protocol development complexity with persistent performance walls.

== A Scalability Solution ==
An effective scalability solution can have two practical assumptions:

* The computation problem size can expand indefinitely, since every useful infrastructure is expected to solve bigger problems.

*Computing and network resources will continue to grow indefinitely, into the future.
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 <ref>https://en.wikipedia.org/wiki/Amdahl%27s_law</ref> and Gustafson's Law <ref>https://en.wikipedia.org/wiki/Gustafson%27s_law</ref>.

The Amdahl's Law assumes 0< ''s <1 percentage'' of serial instructions that cannot be parallelized. Then the ''(1-s)'' percentage of instructions can be accelerated using ''p'' processors.

Speedup(p) = <math>{1 \over s + {(1-s) \over p}}</math> (1)

Speedup(<math>\lim_{p \to \infty}</math>) = <math>\frac{1}{s}</math> (2)

The problem is that ''s'' is difficult to quantify for practical applications. Although (2) is the limit of speedup that has no assumed problem sizes, assuming fixed problem size using p processors has been the norm in interpreting Amdahl's law in the past. This assumption has led to the dismal speedup predictions.[[File:Amdahl's Law.png|thumb|Amdahl's Law Speedup Predictions|center]]The traditional Amdahl's Law interpretation seems to suggest parallel performances following the economic law of diminishing of returns.

In 1988, Gustafson and Barsis at the Sandia National Laboratory conducted parallel computing experiments that seem to suggest potential infinite speedup.

Gustafson's while Gustafson's Law seems to lead to 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 mainframe computer architectures. In the past decades, these laws have been used to support computing system experiments and constructions.
[[File:Gustafson.png|thumb|Gustafson's Law|center]]
A careful examination revealed that the Gustafson's Law cannot scale mathematically since the are mathematically dependent <ref>https://cis.temple.edu/~shi/wwwroot/shi/public_html/docs/amdahl/amdahl.html</ref> where Amdahl's formulation has a tight peak performance bound <math>\left ( \frac{1}{x} \right )</math> 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 <math>\left ( \frac{1}{x} \right )</math>, when <math>x \Rightarrow 0</math>, the performance will asymptotically approach to <math>\infty</math>, when <math>x \Rightarrow 1</math> the speedup <math>\Rightarrow</math> 1. Thus, if the computing problem's size is fixed, x will eventually approach to 1 as the number of processors increases -- economic law of diminishing of return. If the problem size is open (solving bigger problems), then increasing the number of processors will force x <math>\Rightarrow</math> 0, thus speedup <math>\Rightarrow</math> <math>\infty</math>. Gustafson's Law uses a recurrence relation based on practical time measurements. It is not possible to derive a mathematical speedup bound.

Applying these laws in practice need to quantify <math>\chi</math> for practical parallel program which has been proven very hard if not impossible. Gustafson's formula was derived from times by running actual parallel programs. Brining the two formulation together makes quantifying <math>\chi</math> in Amdahl's Law possible. Thus, both law actually refer to the same mathematical abstraction. Gustafson's formula assisted in quantifying the percentage of serial computing through program experiments. Neither should be directly used for speedup prediction alone.

This model can be validated in practice when developers simply increasing the problem size to use more parallel processors.
[[File:1overx-function resized.png|thumb|294x294px|Amdalh's Law and Peak Parallel Performance|center]]

A classical example is the TOP500 supercomputer benchmarks (linear solvers) that have open problem sizes for all manufacturers to compete in the world's fastest supercomputer race <ref>https://www.top500.org/</ref> .
[[File:Supercomputers-history.png|center|thumb]]
In practical blockchain applications, the number of transactions to be processed will increase without a known limit. The ledger storage will continue to grow. In practice, the available computing, networking and storage components will continue to grow without limits enabled by the networking protocols. Therefore a statistic multiplexed computing blockchain can meet any future application needs given proper economic incentives. The infrastructure no longer has the structural deficiency.

== Action Plan ==

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.

For Toichain protocol design, we choose Bitcoin 24.0.1 as the base line protocol by replacing the PoW consensus by PoS consensus and injecting SMC components into the protocol processing signaling for parallel computing.

This surprising result is also applicable to ledger storage. Without multiplexing, the blockchain ledger storage will eventually saturate all nodes causing the chain to collapse. The SMC blockchain protocol promises to hold the true finality of all transactions in perpetuity by multiplexing all storage resources while keeping the replication factor to a constant.

These discussions follow the inductive logic of the Law of Large Numbers <ref>https://www.sciencedirect.com/topics/mathematics/laws-of-large-number</ref>.

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

= SMC Proof of Stake Protocol =
Existing PoS protocol designs revolved around staking policies and randomness of the selection algorithm. Considering infrastructure scalability will add much complexity to the design. The examples include chain sharding and Danksharding <ref>https://ethereum.org/en/roadmap/danksharding/</ref>.

The challenge is complex -- we must deliver very high performance without compromising security and reliability of the network.

Technically, transaction replication and parallel processing were considered dangerous <ref>https://pages.cs.wisc.edu/~yxy/cs764-f20/papers/replication.pdf</ref> due to the potential race conditions (or double-spend problem). The blockchain protocol resolved the double-spending problem. It did not solve the parallel processing performance problem.

According to Professor Michael Flynn, there are three high-level parallel processing topologies: SIMD (single instruction multiple data), MIMD (multiple instructions multiple data), and pipeline (MISD - multiple instructions single data stream) <ref>https://link.springer.com/referenceworkentry/10.1007/978-0-387-09766-4_2</ref>. However, for eliminating double-spending, all transactions must be serialized, since each block may contain transactions affecting transactions in multiple other blocks. "Race conditions" and non-deterministic results are not allowed. Then the only possible topology entry is pipeline. This means for POS protocol, we must build a pipeline of transaction blocks to be validated without compromising network security and reliability.
[[File:Flynns-Taxonomy-of-Computer-Architectures.png|center|thumb|Parallel Processing Topologies]]
The problem is that the nature of the blockchain protocol is that all nodes run independently in parallel with little communication with other nodes via "gossip" protocols. It is far easier to force all nodes store the entire ledger than forcing them to form any pipeline and store partial chain data.

=== ACAN (Active Content Addressable Network) [U.S. and Other Patents Pending] ===
ACAN is a high-level data '''''communication and synchronization protocol''''' that completely decouples all hardware components from communicating programs. The need for complete component decoupling was implemented in the original blockchain protocol via "gossip" protocol. This delivered blockchain's high availability and security. The simple "gossip" implementation in existing protocols is insufficient for parallel processing signaling.

The following figure illustrates the concept of ACAN (active content addressable networking) using UVR (unidirectional virtual ring) architecture. The illustrated implementation uses the Tuple Space resource tagging method and gossip protocol for UVR implementation.
[[File:SMC Architecture with ACAN.png|center|thumb|243x243px|SMC Architecture with ACAN]]

ACAN supports three simple APIs:

# '''read'''(&''key'', &''value''): ''key'' holds a search pattern in a "tuple space" where all nodes are connected. ''value'' holds the matched tuple, if any. This is a blocking call that a requesting program will be blocked until a pattern-matched tuple is found. The matching tuple remains in the "tuple space".
# '''get'''(&key, &value): Same as the "read()" API, except that the matching tuple is removed from the "tuple space".
# '''put'''(key, value): Inserts <key, value> into the "tuple space".

The use of "gossip" protocol can accelerate ACAN network saturation time. Applications running on ACAN will automatically form parallel processing topologies: pipeline, SIMD and MIMD without violating the serialization needs of transaction block validation. Replication factor can also be dynamically controlled to spread replicated blocks in randomly chosen hosts.

The highly parallel nature of the blockchain protocol will automatically implement the SMC principle in real time.

The critical feature of this dynamic SMC pipelined architecture is the inductive scaling feature.
[[File:Pipeline Parallel Processing.png|center|thumb|247x247px|Pipeline Parallel Processing]]

The speed up of a pipeline can be represented as: <math>SpeedUp = \left ( \frac{p\centerdot b}{p + (b-p)} \right )</math>, where p = number of processors in the pipeline, b = total blocks to be processed. Take the number of blocks to infinity: <math>SpeedUp = \left ( \frac{p\centerdot b}{p + (b-p)} \right )=>\lim (b\Rightarrow\infty)(\frac{p}{\frac{p}{b}+1-\frac{p}{b}}) = p</math>

This means that as long as there are enough blocks to be processed, the entire chain's performance will be abound-bounded to the number of nodes in the pipeline.

For illustration purposes, the variation of block processing times was not considered in the above calculations. To see the power of pipeline parallelism, the automobile manufacturing processes illustrate a similar situation. The Hyundai Motor Company's production pipelines can produce 3,835 vehicles per day and 1.4M per year<ref>https://en.wikipedia.org/wiki/List_of_Hyundai_Motor_Company_manufacturing_facilities</ref>.

== Toichain Tokens ==
Toichain token is TOIN. There are 50,000,000,000 TOINs for the Alpha Release. There are air-drop tokens for early adopters, 1,000 TOIN each. Users need to register to download a toichain wallet to receive the payment. Citizenship is checked and verified to ensure that US citizens do not apply. The minimal staking contract is 10 TOINs.

== Non-Fungible Tokens ==
The TestNet Release of toichain protocol will support embedding arbitrary data in an "OP_RETURN" transaction that will be permanently recorded on the chain. Unlike the ordinal NFT <ref>https://blog.chain.link/ordinals-bitcoin-nfts/</ref> or NFT (non-fungible token) on other chains, these transactions cannot be altered or removed.

There are practical applications for these forever NFTs. Once Taproot is enabled on toichain, ordinal NFTs (BRC-20) will also be supported. Unlike the original Bitcoin network where BRC-20 craze has created massive network congestion<ref>https://beincrypto.com/learn/brc-20-token/</ref>, all transactions will be processed promptly in toichain without congestion or scaling problems.
== Toichain TestNet Launch ==
The toichain testnet launch will enable users to interact with one another through simple payments, just like the original Bitcoin network. Forever NFTs are supported. Smart contracts will be supported on a later date.

= References =
<references />

Consult the [[mediawikiwiki:Special:MyLanguage/Help:Contents|User's Guide]] for information on using the wiki software.

Main Page

2024-10-05T04:01:17Z

Justin: /* A Scalability Solution */

= <strong><big>'''Welcome to Toi-Twiki -- A Toichain Wiki'''</big></strong> =
This is the unofficial Toichain wiki site. Content is subject to changes.
---------------------------

= '''Introduction''' =
The blockchain protocol was introduced in a seminal paper entitled "Bitcoin: A peer-to-peer Electronic Cash System" <ref>https://bitcoin.org/bitcoin.pdf</ref> by Satoshi Nakamoto in 2008. Although there were previous peer-to-peer file-sharing projects such as Napster <ref>https://www.napster.com/us</ref>, BitTorrent <ref>https://www.bittorrent.com/</ref> and other electronic currency/file sharing applications, Bitcoin is the most enduring among the 23,000+ blockchains. Unlike other cryptocurrencies, the Bitcoin is often referred to as "digital gold" since the total coin supply is limited to 21 million (hard-coded in all running programs) and the only way to earn coin is to participate in the transaction block validation process. Token(or coin) supply and their disbursement policies differ among protocols.

The most attractive common blockchain features are 1) a decentralized consensus-driven decision making process and 2) a step-by-step cryptographic proving system. While blockchain is best known as a cryptocurrency transaction processing and record-keeping system, there are many other applications that can benefit from the secure storage, reliable transaction ledgers, fault tolerance and tamper resistance features.

== Algorithm vs. Protocol ==
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 ==
A good consensus protocol in a blockchain system has at least four properties:

# Fault tolerance to defend failures caused by natural disasters and human hacks or accidents
# Byzantine failure tolerance to defend exploitation by colluding parties
# Centralization avoidance to prevent corruptions in the decision making process
# Source code tamper resistance to automatically reject malicious attacks

Without assuming all nodes are active at all times, the blockchain relies on "gossip" protocol to communicate with other nodes. There are two popular types of consensus protocols: Proof of Work ('''PoW''') <ref>https://en.wikipedia.org/wiki/Proof_of_work</ref> or Proof of Stake ('''PoS''') <ref>https://www.investopedia.com/terms/p/proof-stake-pos.asp</ref>. Others include Proof of Possession('''PoP''')<ref>https://identityserver4.readthedocs.io/en/latest/topics/pop.html</ref> and Proof of History('''PoH''')<ref>https://www.infoworld.com/article/3666736/solana-blockchain-and-the-proof-of-history.html</ref>. The ultimate goal is to eliminate double-spending. Since most projects are open source, it's easy for a malicious actor to tamper a few nodes. This shouldn't compromise network integrity.

The Bitcoin network uses PoW which forces participating miners to compete for the fastest hashing rate by solving a computational cryptographic puzzle. Although it withstood more than 14 years of use, Bitcoin has been criticized for escalating electricity consumption <ref>https://www.forbes.com/advisor/investing/cryptocurrency/bitcoins-energy-usage-explained/</ref>. Other blockchain designs have experienced different challenges. For example, the PoH network Solana suffered multiple single-point-failure incidents <ref>https://messari.io/report/solana-analyzing-downtimes-statistics-and-ecosystem-development</ref>. All protocols struggle to combat scaling challenges. All are susceptible to 51% attacks <ref>https://originstamp.com/blog/has-there-ever-been-a-51-attack-on-bitcoin/#notable-51-attacks</ref>.

Since 2009, Bitcoin has proven to be the strongest and least susceptible to common hacks <ref>https://www.theguardian.com/technology/2014/mar/18/history-of-bitcoin-hacks-alternative-currency</ref>. As the PoW puzzle difficulty has increased dramatically over the years, the probability of a 51% attack on the Bitcoin network becomes more difficult. PoS protocols can save more than 90% energy consumption compared to PoW chains. But PoS chains have higher risks than PoW chains since a stolen coin will grow in PoS chains (for increased probability to be selected) forever but not in PoW chains (only hash rates count). PoS community governance rules can mitigate the voting power centralization problem. Staking and slashing policies can incentivize good behaviors and punish bad ones. In either case, double-spend is very expensive and difficult. According to Forbes, there are 80 cryptocurrencies that use PoS protocols at the time of this writing.

There are approximately 1,000 blockchains in four types: public, private, consortium, and permissioned <ref>https://increditools.com/blockchains/</ref>.

== Cryptographic Proofs ==
Bitcoin 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.

== Centralized vs. Decentralized Applications ==
The Bitcoin protocol enabled decentralized processing of traditionally centrally processed transactions without any trusted third-party. It inspired many decentralized financial applications, especially for applications with very long payment chains. However for fraud prevention and meeting financial regulatory requirements, many practical applications still require KYC (know your customer) checks. It is not possible to eliminate all trusted third parties, especially for custodial financial applications. There is a clear need for decentralized processing of trusted authority applications.

== Blockchain Trilemma ==
Blockchain protocols have three common aspects (goals): '''security''', '''decentralization''' and '''scalability''' -- these three terms do not have precise definitions but are intuitively understood <ref>https://sensoriumxr.com/articles/what-is-the-blockchain-trilemma</ref>. To date, 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.

A major shortcoming is scalability. Since all nodes verify each transaction independently, they need to store all the information required for it. As the chain grows, this burdens all nodes in the network. There are workarounds by limiting the amount of data stored on some nodes and exploiting the network to retrieve required information, such as the ''Limited/Light Nodes'' in Bitcoin network. Vast majority nodes are still full nodes in the existing Bitcoin network. Transaction processing speed often expressed ''as transactions per second(TPS) of'' blockchain have to exceed TPS ratings of credit card payment systems like VISA or MasterCard to reap the full benefits of blockchain. This is a tough problem and increasing the block size and/or reducing the block time or difficulty isn't a solution<ref>https://medium.com/coinmonks/blockchain-scaling-30c9e1b7db1b</ref>. Since blockchain TPS is very low, the transaction fees is often very high. This discourages public adoption. Layer 2 solution like ''Lightning Network'' or ''ZK-rollups,'' where only final settlement is on the main chain tend to address these issues. However, one could always argue that this often compromises some aspects of security and/or decentralization to achieve high TPS.

The trilemma was first introduced by Vitalik Buterin<ref>https://en.wikipedia.org/wiki/Vitalik_Buterin</ref>, one of the co-founders of Ethereum network. The problems he identified are real. There seem to be no obvious solutions that can accomplish all three goals at the same time. Therefore, all proposed solutions revolve around reducing "opportunity costs" focusing only on satisfying partial goals.

Treating the blockchain network as an infrastructure for transaction processing, the blockchain protocol solved service reliability problem but not performance challenge. The legacy infrastructure scaling dilemma: performance against reliability remains (where "infrastructure reliability" also does not have a commonly accepted definition). Fortunately these metrics, although important, are non-critical. Solutions that have been proposed have had varying opportunity costs. For many years, there were no obvious solutions that addressed all three blockchain goals (security, decentralization and scalability).
== Statistic Multiplexed Computing (SMC) ==
The principle of using unreliable components to build an arbitrarily reliable system was first lectured by von Neumann in the early 1950s<ref>https://static.ias.edu/pitp/archive/2012files/Probabilistic_Logics.pdf</ref>. The original idea was to use probabilistic logic to quantify the arbitrary reliability of a system by multiplexing all components. This theory was applied to the construction of Internet protocols to deliver the "best effort" reliability. Incidentally, best effort reliability also enabled "best effort" performance which in turn enabled unlimited scalability of the Internet. For emerging web3.0 technologies, it is important to apply the same methodology to both centralized and decentralized computing for seamless technology migration and integration. For historical arguments, click [[SMC|'''''here''''']].

== Definitions ==
'''Infrastructure scalability''' does not have a commonly accepted definition. It helps to define the challenging metrics more precisely before the infrastructure protocol design. In the following, for definitions #1 and #2, the word "'''infrastructure'''" means any '''application running on the infrastructure.'''

# '''Infrastructure Reliability''': MTBF (mean time between failure) = <math>\frac{\sum ((Start-Of-Downtime) - (Start-of-uptime)) }{No-of-failures}</math>
# '''Infrastructure Performance''': <math>\frac{No-of-Transactions}{Second}</math>
# '''Infrastructure Scalability''': Expanding the infrastructure in number of processors, networks or storage should have '''incrementally better''' impacts on application reliability and performance.
# '''Record Immutability''': For transaction ledgers, all confirmed records and changes are final. This is required by the blockchain protocol.
Note that in practice, record immutability is much harder to achieve than expected. There are two challenges, a) 51% attacks can literally wipe out all histories if successful, and b) for protocols require all nodes to hold independently verified ledger, such as the Bitcoin, the storage requirement grows approximately 50GB per month.

== 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 and considered.

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 crashe'''s <ref>https://groups.csail.mit.edu/tds/papers/Lynch/jacm93.pdf</ref>. The laws of physics regarding component reliability <ref>Encyclopedia of Physical Science and Technology, Editor-in-Chief Robert A. Meyers, [[index.php?title=Special:BookSources/9780122274107|ISBN 978-0-12-227410-7]], 2001</ref> show that '''100% component reliability is not possible.''' These facts require that the infrastructure protocol (program-program communication protocol) provide '''complete component (processing, networking and storage) decoupling''' from application program logics. This decoupling requirement forces the protocol to exploit "decentralized" or "stateless" components that the legacy infrastructure protocols, such as message passing interface (MPI), remote procedure call (RPC) and remote method invocation (RMI), cannot handle. The blockchain protocol is an example of a "best effort" availability protocol.

Quantifying infrastructure reliability can be traced back to the computer pioneer von Neumann. In addition to his contribution to computer architecture, von Neumann also penned a study on building reliable systems using unreliable components using probabilistic logics, in early fifties <ref>https://static.ias.edu/pitp/archive/2012files/Probabilistic_Logics.pdf</ref>. The 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 "best effort" reliability. Ironically, this best effort reliability also enabled the Internet's infinite scalability -- the benefit we enjoy now and into the future.

The Bitcoin protocol exploits multiple anonymous decoupled (or decentralized) computers connected through the Internet protocol. Judging from the Bitcoin network's reliability to date <ref>https://buybitcoinworldwide.com/bitcoin-downtime/</ref>, von Neumann's theory seems working well.

The '''second challenge''' involves infrastructure performance. Since the infrastructure must deploy multiple computing, networking and storage components, unless all components can be fully exploited at 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 lack this capability.

'''The infrastructure scalability challenge''' is automatically resolved once the performance challenge is resolved without negatively impacting reliability -- "best effort" performance" meets "best effort reliability". This requires inductive performance and reliability measures or deliveries.

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, an inductive statistic multiplexed blockchain protocol is needed to meet the scalability challenge. Non-inductive solutions such as fixed chain "sharding" or "Danksharding" <ref>https://ethereum.org/en/roadmap/danksharding/</ref> will only increase protocol development complexity with persistent performance walls.

== A Scalability Solution ==
An effective scalability solution can have two practical assumptions:

* The computation problem size can expand indefinitely, since every useful infrastructure is expected to solve bigger problems.

*Computing and network resources will continue to grow indefinitely, into the future.
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 <ref>https://en.wikipedia.org/wiki/Amdahl%27s_law</ref> and Gustafson's Law <ref>https://en.wikipedia.org/wiki/Gustafson%27s_law</ref>.

The Amdahl's Law assumes 0< ''s <1 percentage'' of serial instructions that cannot be parallelized. Then the ''(1-s)'' percentage of instructions can be accelerated using ''p'' processors.

Speedup(p) = <math>{1 \over s + {(1-s) \over p}}</math> (1)

Speedup(<math>\lim_{p \to \infty}</math>) = <math>\frac{1}{s}</math>

The problem is that ''s'' is difficult to quantify for practical applications. Assuming fixed problem size using p processors has been the norm in interpreting Amdahl's law in the past. This assumption has led to the dismal speedup predictions.[[File:Amdahl's Law.png|thumb|Amdahl's Law Speedup Predictions|center]]The traditional Amdahl's Law interpretation seems to suggest parallel performances following the economic law of diminishing of returns while Gustafson's Law seems to lead to 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 mainframe computer architectures. In the past decades, these laws have been used to support computing system experiments and constructions.
[[File:Gustafson.png|thumb|Gustafson's Law|center]]
A careful examination revealed that the Gustafson's Law cannot scale mathematically since the are mathematically dependent <ref>https://cis.temple.edu/~shi/wwwroot/shi/public_html/docs/amdahl/amdahl.html</ref> where Amdahl's formulation has a tight peak performance bound <math>\left ( \frac{1}{x} \right )</math> 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 <math>\left ( \frac{1}{x} \right )</math>, when <math>x \Rightarrow 0</math>, the performance will asymptotically approach to <math>\infty</math>, when <math>x \Rightarrow 1</math> the speedup <math>\Rightarrow</math> 1. Thus, if the computing problem's size is fixed, x will eventually approach to 1 as the number of processors increases -- economic law of diminishing of return. If the problem size is open (solving bigger problems), then increasing the number of processors will force x <math>\Rightarrow</math> 0, thus speedup <math>\Rightarrow</math> <math>\infty</math>. Gustafson's Law uses a recurrence relation based on practical time measurements. It is not possible to derive a mathematical speedup bound.

Applying these laws in practice need to quantify <math>\chi</math> for practical parallel program which has been proven very hard if not impossible. Gustafson's formula was derived from times by running actual parallel programs. Brining the two formulation together makes quantifying <math>\chi</math> in Amdahl's Law possible. Thus, both law actually refer to the same mathematical abstraction. Gustafson's formula assisted in quantifying the percentage of serial computing through program experiments. Neither should be directly used for speedup prediction alone.

This model can be validated in practice when developers simply increasing the problem size to use more parallel processors.
[[File:1overx-function resized.png|thumb|294x294px|Amdalh's Law and Peak Parallel Performance|center]]

A classical example is the TOP500 supercomputer benchmarks (linear solvers) that have open problem sizes for all manufacturers to compete in the world's fastest supercomputer race <ref>https://www.top500.org/</ref> .
[[File:Supercomputers-history.png|center|thumb]]
In practical blockchain applications, the number of transactions to be processed will increase without a known limit. The ledger storage will continue to grow. In practice, the available computing, networking and storage components will continue to grow without limits enabled by the networking protocols. Therefore a statistic multiplexed computing blockchain can meet any future application needs given proper economic incentives. The infrastructure no longer has the structural deficiency.

== Action Plan ==

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.

For Toichain protocol design, we choose Bitcoin 24.0.1 as the base line protocol by replacing the PoW consensus by PoS consensus and injecting SMC components into the protocol processing signaling for parallel computing.

This surprising result is also applicable to ledger storage. Without multiplexing, the blockchain ledger storage will eventually saturate all nodes causing the chain to collapse. The SMC blockchain protocol promises to hold the true finality of all transactions in perpetuity by multiplexing all storage resources while keeping the replication factor to a constant.

These discussions follow the inductive logic of the Law of Large Numbers <ref>https://www.sciencedirect.com/topics/mathematics/laws-of-large-number</ref>.

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

= SMC Proof of Stake Protocol =
Existing PoS protocol designs revolved around staking policies and randomness of the selection algorithm. Considering infrastructure scalability will add much complexity to the design. The examples include chain sharding and Danksharding <ref>https://ethereum.org/en/roadmap/danksharding/</ref>.

The challenge is complex -- we must deliver very high performance without compromising security and reliability of the network.

Technically, transaction replication and parallel processing were considered dangerous <ref>https://pages.cs.wisc.edu/~yxy/cs764-f20/papers/replication.pdf</ref> due to the potential race conditions (or double-spend problem). The blockchain protocol resolved the double-spending problem. It did not solve the parallel processing performance problem.

According to Professor Michael Flynn, there are three high-level parallel processing topologies: SIMD (single instruction multiple data), MIMD (multiple instructions multiple data), and pipeline (MISD - multiple instructions single data stream) <ref>https://link.springer.com/referenceworkentry/10.1007/978-0-387-09766-4_2</ref>. However, for eliminating double-spending, all transactions must be serialized, since each block may contain transactions affecting transactions in multiple other blocks. "Race conditions" and non-deterministic results are not allowed. Then the only possible topology entry is pipeline. This means for POS protocol, we must build a pipeline of transaction blocks to be validated without compromising network security and reliability.
[[File:Flynns-Taxonomy-of-Computer-Architectures.png|center|thumb|Parallel Processing Topologies]]
The problem is that the nature of the blockchain protocol is that all nodes run independently in parallel with little communication with other nodes via "gossip" protocols. It is far easier to force all nodes store the entire ledger than forcing them to form any pipeline and store partial chain data.

=== ACAN (Active Content Addressable Network) [U.S. and Other Patents Pending] ===
ACAN is a high-level data '''''communication and synchronization protocol''''' that completely decouples all hardware components from communicating programs. The need for complete component decoupling was implemented in the original blockchain protocol via "gossip" protocol. This delivered blockchain's high availability and security. The simple "gossip" implementation in existing protocols is insufficient for parallel processing signaling.

The following figure illustrates the concept of ACAN (active content addressable networking) using UVR (unidirectional virtual ring) architecture. The illustrated implementation uses the Tuple Space resource tagging method and gossip protocol for UVR implementation.
[[File:SMC Architecture with ACAN.png|center|thumb|243x243px|SMC Architecture with ACAN]]

ACAN supports three simple APIs:

# '''read'''(&''key'', &''value''): ''key'' holds a search pattern in a "tuple space" where all nodes are connected. ''value'' holds the matched tuple, if any. This is a blocking call that a requesting program will be blocked until a pattern-matched tuple is found. The matching tuple remains in the "tuple space".
# '''get'''(&key, &value): Same as the "read()" API, except that the matching tuple is removed from the "tuple space".
# '''put'''(key, value): Inserts <key, value> into the "tuple space".

The use of "gossip" protocol can accelerate ACAN network saturation time. Applications running on ACAN will automatically form parallel processing topologies: pipeline, SIMD and MIMD without violating the serialization needs of transaction block validation. Replication factor can also be dynamically controlled to spread replicated blocks in randomly chosen hosts.

The highly parallel nature of the blockchain protocol will automatically implement the SMC principle in real time.

The critical feature of this dynamic SMC pipelined architecture is the inductive scaling feature.
[[File:Pipeline Parallel Processing.png|center|thumb|247x247px|Pipeline Parallel Processing]]

The speed up of a pipeline can be represented as: <math>SpeedUp = \left ( \frac{p\centerdot b}{p + (b-p)} \right )</math>, where p = number of processors in the pipeline, b = total blocks to be processed. Take the number of blocks to infinity: <math>SpeedUp = \left ( \frac{p\centerdot b}{p + (b-p)} \right )=>\lim (b\Rightarrow\infty)(\frac{p}{\frac{p}{b}+1-\frac{p}{b}}) = p</math>

This means that as long as there are enough blocks to be processed, the entire chain's performance will be abound-bounded to the number of nodes in the pipeline.

For illustration purposes, the variation of block processing times was not considered in the above calculations. To see the power of pipeline parallelism, the automobile manufacturing processes illustrate a similar situation. The Hyundai Motor Company's production pipelines can produce 3,835 vehicles per day and 1.4M per year<ref>https://en.wikipedia.org/wiki/List_of_Hyundai_Motor_Company_manufacturing_facilities</ref>.

== Toichain Tokens ==
Toichain token is TOIN. There are 50,000,000,000 TOINs for the Alpha Release. There are air-drop tokens for early adopters, 1,000 TOIN each. Users need to register to download a toichain wallet to receive the payment. Citizenship is checked and verified to ensure that US citizens do not apply. The minimal staking contract is 10 TOINs.

== Non-Fungible Tokens ==
The TestNet Release of toichain protocol will support embedding arbitrary data in an "OP_RETURN" transaction that will be permanently recorded on the chain. Unlike the ordinal NFT <ref>https://blog.chain.link/ordinals-bitcoin-nfts/</ref> or NFT (non-fungible token) on other chains, these transactions cannot be altered or removed.

There are practical applications for these forever NFTs. Once Taproot is enabled on toichain, ordinal NFTs (BRC-20) will also be supported. Unlike the original Bitcoin network where BRC-20 craze has created massive network congestion<ref>https://beincrypto.com/learn/brc-20-token/</ref>, all transactions will be processed promptly in toichain without congestion or scaling problems.
== Toichain TestNet Launch ==
The toichain testnet launch will enable users to interact with one another through simple payments, just like the original Bitcoin network. Forever NFTs are supported. Smart contracts will be supported on a later date.

= References =
<references />

Consult the [[mediawikiwiki:Special:MyLanguage/Help:Contents|User's Guide]] for information on using the wiki software.

Main Page

2024-10-05T03:52:14Z

Justin: /* A Scalability Solution */

= <strong><big>'''Welcome to Toi-Twiki -- A Toichain Wiki'''</big></strong> =
This is the unofficial Toichain wiki site. Content is subject to changes.
---------------------------

= '''Introduction''' =
The blockchain protocol was introduced in a seminal paper entitled "Bitcoin: A peer-to-peer Electronic Cash System" <ref>https://bitcoin.org/bitcoin.pdf</ref> by Satoshi Nakamoto in 2008. Although there were previous peer-to-peer file-sharing projects such as Napster <ref>https://www.napster.com/us</ref>, BitTorrent <ref>https://www.bittorrent.com/</ref> and other electronic currency/file sharing applications, Bitcoin is the most enduring among the 23,000+ blockchains. Unlike other cryptocurrencies, the Bitcoin is often referred to as "digital gold" since the total coin supply is limited to 21 million (hard-coded in all running programs) and the only way to earn coin is to participate in the transaction block validation process. Token(or coin) supply and their disbursement policies differ among protocols.

The most attractive common blockchain features are 1) a decentralized consensus-driven decision making process and 2) a step-by-step cryptographic proving system. While blockchain is best known as a cryptocurrency transaction processing and record-keeping system, there are many other applications that can benefit from the secure storage, reliable transaction ledgers, fault tolerance and tamper resistance features.

== Algorithm vs. Protocol ==
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 ==
A good consensus protocol in a blockchain system has at least four properties:

# Fault tolerance to defend failures caused by natural disasters and human hacks or accidents
# Byzantine failure tolerance to defend exploitation by colluding parties
# Centralization avoidance to prevent corruptions in the decision making process
# Source code tamper resistance to automatically reject malicious attacks

Without assuming all nodes are active at all times, the blockchain relies on "gossip" protocol to communicate with other nodes. There are two popular types of consensus protocols: Proof of Work ('''PoW''') <ref>https://en.wikipedia.org/wiki/Proof_of_work</ref> or Proof of Stake ('''PoS''') <ref>https://www.investopedia.com/terms/p/proof-stake-pos.asp</ref>. Others include Proof of Possession('''PoP''')<ref>https://identityserver4.readthedocs.io/en/latest/topics/pop.html</ref> and Proof of History('''PoH''')<ref>https://www.infoworld.com/article/3666736/solana-blockchain-and-the-proof-of-history.html</ref>. The ultimate goal is to eliminate double-spending. Since most projects are open source, it's easy for a malicious actor to tamper a few nodes. This shouldn't compromise network integrity.

The Bitcoin network uses PoW which forces participating miners to compete for the fastest hashing rate by solving a computational cryptographic puzzle. Although it withstood more than 14 years of use, Bitcoin has been criticized for escalating electricity consumption <ref>https://www.forbes.com/advisor/investing/cryptocurrency/bitcoins-energy-usage-explained/</ref>. Other blockchain designs have experienced different challenges. For example, the PoH network Solana suffered multiple single-point-failure incidents <ref>https://messari.io/report/solana-analyzing-downtimes-statistics-and-ecosystem-development</ref>. All protocols struggle to combat scaling challenges. All are susceptible to 51% attacks <ref>https://originstamp.com/blog/has-there-ever-been-a-51-attack-on-bitcoin/#notable-51-attacks</ref>.

Since 2009, Bitcoin has proven to be the strongest and least susceptible to common hacks <ref>https://www.theguardian.com/technology/2014/mar/18/history-of-bitcoin-hacks-alternative-currency</ref>. As the PoW puzzle difficulty has increased dramatically over the years, the probability of a 51% attack on the Bitcoin network becomes more difficult. PoS protocols can save more than 90% energy consumption compared to PoW chains. But PoS chains have higher risks than PoW chains since a stolen coin will grow in PoS chains (for increased probability to be selected) forever but not in PoW chains (only hash rates count). PoS community governance rules can mitigate the voting power centralization problem. Staking and slashing policies can incentivize good behaviors and punish bad ones. In either case, double-spend is very expensive and difficult. According to Forbes, there are 80 cryptocurrencies that use PoS protocols at the time of this writing.

There are approximately 1,000 blockchains in four types: public, private, consortium, and permissioned <ref>https://increditools.com/blockchains/</ref>.

== Cryptographic Proofs ==
Bitcoin 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.

== Centralized vs. Decentralized Applications ==
The Bitcoin protocol enabled decentralized processing of traditionally centrally processed transactions without any trusted third-party. It inspired many decentralized financial applications, especially for applications with very long payment chains. However for fraud prevention and meeting financial regulatory requirements, many practical applications still require KYC (know your customer) checks. It is not possible to eliminate all trusted third parties, especially for custodial financial applications. There is a clear need for decentralized processing of trusted authority applications.

== Blockchain Trilemma ==
Blockchain protocols have three common aspects (goals): '''security''', '''decentralization''' and '''scalability''' -- these three terms do not have precise definitions but are intuitively understood <ref>https://sensoriumxr.com/articles/what-is-the-blockchain-trilemma</ref>. To date, 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.

A major shortcoming is scalability. Since all nodes verify each transaction independently, they need to store all the information required for it. As the chain grows, this burdens all nodes in the network. There are workarounds by limiting the amount of data stored on some nodes and exploiting the network to retrieve required information, such as the ''Limited/Light Nodes'' in Bitcoin network. Vast majority nodes are still full nodes in the existing Bitcoin network. Transaction processing speed often expressed ''as transactions per second(TPS) of'' blockchain have to exceed TPS ratings of credit card payment systems like VISA or MasterCard to reap the full benefits of blockchain. This is a tough problem and increasing the block size and/or reducing the block time or difficulty isn't a solution<ref>https://medium.com/coinmonks/blockchain-scaling-30c9e1b7db1b</ref>. Since blockchain TPS is very low, the transaction fees is often very high. This discourages public adoption. Layer 2 solution like ''Lightning Network'' or ''ZK-rollups,'' where only final settlement is on the main chain tend to address these issues. However, one could always argue that this often compromises some aspects of security and/or decentralization to achieve high TPS.

The trilemma was first introduced by Vitalik Buterin<ref>https://en.wikipedia.org/wiki/Vitalik_Buterin</ref>, one of the co-founders of Ethereum network. The problems he identified are real. There seem to be no obvious solutions that can accomplish all three goals at the same time. Therefore, all proposed solutions revolve around reducing "opportunity costs" focusing only on satisfying partial goals.

Treating the blockchain network as an infrastructure for transaction processing, the blockchain protocol solved service reliability problem but not performance challenge. The legacy infrastructure scaling dilemma: performance against reliability remains (where "infrastructure reliability" also does not have a commonly accepted definition). Fortunately these metrics, although important, are non-critical. Solutions that have been proposed have had varying opportunity costs. For many years, there were no obvious solutions that addressed all three blockchain goals (security, decentralization and scalability).
== Statistic Multiplexed Computing (SMC) ==
The principle of using unreliable components to build an arbitrarily reliable system was first lectured by von Neumann in the early 1950s<ref>https://static.ias.edu/pitp/archive/2012files/Probabilistic_Logics.pdf</ref>. The original idea was to use probabilistic logic to quantify the arbitrary reliability of a system by multiplexing all components. This theory was applied to the construction of Internet protocols to deliver the "best effort" reliability. Incidentally, best effort reliability also enabled "best effort" performance which in turn enabled unlimited scalability of the Internet. For emerging web3.0 technologies, it is important to apply the same methodology to both centralized and decentralized computing for seamless technology migration and integration. For historical arguments, click [[SMC|'''''here''''']].

== Definitions ==
'''Infrastructure scalability''' does not have a commonly accepted definition. It helps to define the challenging metrics more precisely before the infrastructure protocol design. In the following, for definitions #1 and #2, the word "'''infrastructure'''" means any '''application running on the infrastructure.'''

# '''Infrastructure Reliability''': MTBF (mean time between failure) = <math>\frac{\sum ((Start-Of-Downtime) - (Start-of-uptime)) }{No-of-failures}</math>
# '''Infrastructure Performance''': <math>\frac{No-of-Transactions}{Second}</math>
# '''Infrastructure Scalability''': Expanding the infrastructure in number of processors, networks or storage should have '''incrementally better''' impacts on application reliability and performance.
# '''Record Immutability''': For transaction ledgers, all confirmed records and changes are final. This is required by the blockchain protocol.
Note that in practice, record immutability is much harder to achieve than expected. There are two challenges, a) 51% attacks can literally wipe out all histories if successful, and b) for protocols require all nodes to hold independently verified ledger, such as the Bitcoin, the storage requirement grows approximately 50GB per month.

== 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 and considered.

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 crashe'''s <ref>https://groups.csail.mit.edu/tds/papers/Lynch/jacm93.pdf</ref>. The laws of physics regarding component reliability <ref>Encyclopedia of Physical Science and Technology, Editor-in-Chief Robert A. Meyers, [[index.php?title=Special:BookSources/9780122274107|ISBN 978-0-12-227410-7]], 2001</ref> show that '''100% component reliability is not possible.''' These facts require that the infrastructure protocol (program-program communication protocol) provide '''complete component (processing, networking and storage) decoupling''' from application program logics. This decoupling requirement forces the protocol to exploit "decentralized" or "stateless" components that the legacy infrastructure protocols, such as message passing interface (MPI), remote procedure call (RPC) and remote method invocation (RMI), cannot handle. The blockchain protocol is an example of a "best effort" availability protocol.

Quantifying infrastructure reliability can be traced back to the computer pioneer von Neumann. In addition to his contribution to computer architecture, von Neumann also penned a study on building reliable systems using unreliable components using probabilistic logics, in early fifties <ref>https://static.ias.edu/pitp/archive/2012files/Probabilistic_Logics.pdf</ref>. The 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 "best effort" reliability. Ironically, this best effort reliability also enabled the Internet's infinite scalability -- the benefit we enjoy now and into the future.

The Bitcoin protocol exploits multiple anonymous decoupled (or decentralized) computers connected through the Internet protocol. Judging from the Bitcoin network's reliability to date <ref>https://buybitcoinworldwide.com/bitcoin-downtime/</ref>, von Neumann's theory seems working well.

The '''second challenge''' involves infrastructure performance. Since the infrastructure must deploy multiple computing, networking and storage components, unless all components can be fully exploited at 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 lack this capability.

'''The infrastructure scalability challenge''' is automatically resolved once the performance challenge is resolved without negatively impacting reliability -- "best effort" performance" meets "best effort reliability". This requires inductive performance and reliability measures or deliveries.

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, an inductive statistic multiplexed blockchain protocol is needed to meet the scalability challenge. Non-inductive solutions such as fixed chain "sharding" or "Danksharding" <ref>https://ethereum.org/en/roadmap/danksharding/</ref> will only increase protocol development complexity with persistent performance walls.

== A Scalability Solution ==
An effective scalability solution can have two practical assumptions:

* The computation problem size can expand indefinitely, since every useful infrastructure is expected to solve bigger problems.

*Computing and network resources will continue to grow indefinitely, into the future.
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 <ref>https://en.wikipedia.org/wiki/Amdahl%27s_law</ref> and Gustafson's Law <ref>https://en.wikipedia.org/wiki/Gustafson%27s_law</ref>. The Amdahl's Law assumes 0< ''s <1 percentage'' of serial instructions that cannot be parallelized. Then the ''(1-s)'' percentage of instructions can be accelerated using ''p'' processors.

Speedup(p) = <math>{1 \over s + {(1-s) \over p}}</math> (1)

Speedup(<math>\lim_{p \to \infty}</math>) = <math>\frac{1}{s}</math>

The problem is that these two "laws" seem to yield complete opposite performance predictions.[[File:Amdahl's Law.png|thumb|Amdahl's Law Speedup Predictions|center]]The traditional Amdahl's Law interpretation seems to suggest parallel performances following the economic law of diminishing of returns while Gustafson's Law seems to lead to 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 mainframe computer architectures. In the past decades, these laws have been used to support computing system experiments and constructions.
[[File:Gustafson.png|thumb|Gustafson's Law|center]]
A careful examination revealed that the Gustafson's Law cannot scale mathematically since the are mathematically dependent <ref>https://cis.temple.edu/~shi/wwwroot/shi/public_html/docs/amdahl/amdahl.html</ref> where Amdahl's formulation has a tight peak performance bound <math>\left ( \frac{1}{x} \right )</math> 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 <math>\left ( \frac{1}{x} \right )</math>, when <math>x \Rightarrow 0</math>, the performance will asymptotically approach to <math>\infty</math>, when <math>x \Rightarrow 1</math> the speedup <math>\Rightarrow</math> 1. Thus, if the computing problem's size is fixed, x will eventually approach to 1 as the number of processors increases -- economic law of diminishing of return. If the problem size is open (solving bigger problems), then increasing the number of processors will force x <math>\Rightarrow</math> 0, thus speedup <math>\Rightarrow</math> <math>\infty</math>. Gustafson's Law uses a recurrence relation based on practical time measurements. It is not possible to derive a mathematical speedup bound.

Applying these laws in practice need to quantify <math>\chi</math> for practical parallel program which has been proven very hard if not impossible. Gustafson's formula was derived from times by running actual parallel programs. Brining the two formulation together makes quantifying <math>\chi</math> in Amdahl's Law possible. Thus, both law actually refer to the same mathematical abstraction. Gustafson's formula assisted in quantifying the percentage of serial computing through program experiments. Neither should be directly used for speedup prediction alone.

This model can be validated in practice when developers simply increasing the problem size to use more parallel processors.
[[File:1overx-function resized.png|thumb|294x294px|Amdalh's Law and Peak Parallel Performance|center]]

A classical example is the TOP500 supercomputer benchmarks (linear solvers) that have open problem sizes for all manufacturers to compete in the world's fastest supercomputer race <ref>https://www.top500.org/</ref> .
[[File:Supercomputers-history.png|center|thumb]]
In practical blockchain applications, the number of transactions to be processed will increase without a known limit. The ledger storage will continue to grow. In practice, the available computing, networking and storage components will continue to grow without limits enabled by the networking protocols. Therefore a statistic multiplexed computing blockchain can meet any future application needs given proper economic incentives. The infrastructure no longer has the structural deficiency.

== Action Plan ==

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.

For Toichain protocol design, we choose Bitcoin 24.0.1 as the base line protocol by replacing the PoW consensus by PoS consensus and injecting SMC components into the protocol processing signaling for parallel computing.

This surprising result is also applicable to ledger storage. Without multiplexing, the blockchain ledger storage will eventually saturate all nodes causing the chain to collapse. The SMC blockchain protocol promises to hold the true finality of all transactions in perpetuity by multiplexing all storage resources while keeping the replication factor to a constant.

These discussions follow the inductive logic of the Law of Large Numbers <ref>https://www.sciencedirect.com/topics/mathematics/laws-of-large-number</ref>.

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

= SMC Proof of Stake Protocol =
Existing PoS protocol designs revolved around staking policies and randomness of the selection algorithm. Considering infrastructure scalability will add much complexity to the design. The examples include chain sharding and Danksharding <ref>https://ethereum.org/en/roadmap/danksharding/</ref>.

The challenge is complex -- we must deliver very high performance without compromising security and reliability of the network.

Technically, transaction replication and parallel processing were considered dangerous <ref>https://pages.cs.wisc.edu/~yxy/cs764-f20/papers/replication.pdf</ref> due to the potential race conditions (or double-spend problem). The blockchain protocol resolved the double-spending problem. It did not solve the parallel processing performance problem.

According to Professor Michael Flynn, there are three high-level parallel processing topologies: SIMD (single instruction multiple data), MIMD (multiple instructions multiple data), and pipeline (MISD - multiple instructions single data stream) <ref>https://link.springer.com/referenceworkentry/10.1007/978-0-387-09766-4_2</ref>. However, for eliminating double-spending, all transactions must be serialized, since each block may contain transactions affecting transactions in multiple other blocks. "Race conditions" and non-deterministic results are not allowed. Then the only possible topology entry is pipeline. This means for POS protocol, we must build a pipeline of transaction blocks to be validated without compromising network security and reliability.
[[File:Flynns-Taxonomy-of-Computer-Architectures.png|center|thumb|Parallel Processing Topologies]]
The problem is that the nature of the blockchain protocol is that all nodes run independently in parallel with little communication with other nodes via "gossip" protocols. It is far easier to force all nodes store the entire ledger than forcing them to form any pipeline and store partial chain data.

=== ACAN (Active Content Addressable Network) [U.S. and Other Patents Pending] ===
ACAN is a high-level data '''''communication and synchronization protocol''''' that completely decouples all hardware components from communicating programs. The need for complete component decoupling was implemented in the original blockchain protocol via "gossip" protocol. This delivered blockchain's high availability and security. The simple "gossip" implementation in existing protocols is insufficient for parallel processing signaling.

The following figure illustrates the concept of ACAN (active content addressable networking) using UVR (unidirectional virtual ring) architecture. The illustrated implementation uses the Tuple Space resource tagging method and gossip protocol for UVR implementation.
[[File:SMC Architecture with ACAN.png|center|thumb|243x243px|SMC Architecture with ACAN]]

ACAN supports three simple APIs:

# '''read'''(&''key'', &''value''): ''key'' holds a search pattern in a "tuple space" where all nodes are connected. ''value'' holds the matched tuple, if any. This is a blocking call that a requesting program will be blocked until a pattern-matched tuple is found. The matching tuple remains in the "tuple space".
# '''get'''(&key, &value): Same as the "read()" API, except that the matching tuple is removed from the "tuple space".
# '''put'''(key, value): Inserts <key, value> into the "tuple space".

The use of "gossip" protocol can accelerate ACAN network saturation time. Applications running on ACAN will automatically form parallel processing topologies: pipeline, SIMD and MIMD without violating the serialization needs of transaction block validation. Replication factor can also be dynamically controlled to spread replicated blocks in randomly chosen hosts.

The highly parallel nature of the blockchain protocol will automatically implement the SMC principle in real time.

The critical feature of this dynamic SMC pipelined architecture is the inductive scaling feature.
[[File:Pipeline Parallel Processing.png|center|thumb|247x247px|Pipeline Parallel Processing]]

The speed up of a pipeline can be represented as: <math>SpeedUp = \left ( \frac{p\centerdot b}{p + (b-p)} \right )</math>, where p = number of processors in the pipeline, b = total blocks to be processed. Take the number of blocks to infinity: <math>SpeedUp = \left ( \frac{p\centerdot b}{p + (b-p)} \right )=>\lim (b\Rightarrow\infty)(\frac{p}{\frac{p}{b}+1-\frac{p}{b}}) = p</math>

This means that as long as there are enough blocks to be processed, the entire chain's performance will be abound-bounded to the number of nodes in the pipeline.

For illustration purposes, the variation of block processing times was not considered in the above calculations. To see the power of pipeline parallelism, the automobile manufacturing processes illustrate a similar situation. The Hyundai Motor Company's production pipelines can produce 3,835 vehicles per day and 1.4M per year<ref>https://en.wikipedia.org/wiki/List_of_Hyundai_Motor_Company_manufacturing_facilities</ref>.

== Toichain Tokens ==
Toichain token is TOIN. There are 50,000,000,000 TOINs for the Alpha Release. There are air-drop tokens for early adopters, 1,000 TOIN each. Users need to register to download a toichain wallet to receive the payment. Citizenship is checked and verified to ensure that US citizens do not apply. The minimal staking contract is 10 TOINs.

== Non-Fungible Tokens ==
The TestNet Release of toichain protocol will support embedding arbitrary data in an "OP_RETURN" transaction that will be permanently recorded on the chain. Unlike the ordinal NFT <ref>https://blog.chain.link/ordinals-bitcoin-nfts/</ref> or NFT (non-fungible token) on other chains, these transactions cannot be altered or removed.

There are practical applications for these forever NFTs. Once Taproot is enabled on toichain, ordinal NFTs (BRC-20) will also be supported. Unlike the original Bitcoin network where BRC-20 craze has created massive network congestion<ref>https://beincrypto.com/learn/brc-20-token/</ref>, all transactions will be processed promptly in toichain without congestion or scaling problems.
== Toichain TestNet Launch ==
The toichain testnet launch will enable users to interact with one another through simple payments, just like the original Bitcoin network. Forever NFTs are supported. Smart contracts will be supported on a later date.

= References =
<references />

Consult the [[mediawikiwiki:Special:MyLanguage/Help:Contents|User's Guide]] for information on using the wiki software.

SMC

2024-10-01T12:35:39Z

Justin: /* Canary In The Coal Mine */

== Introduction ==

SMC stands for Statistic Multiplexed Computing and Communication. The idea was inspired by von Neumann's 1952 paper on probabilistic logics and synthesis of reliable organisms using unreliable components <ref>https://static.ias.edu/pitp/archive/2012files/Probabilistic_Logics.pdf</ref>. Building fault tolerant mission critical system was the triggering use case.

Modern computer applications must rely on networking services. Every networked application forms its own infrastructure consisting of network, processing, storage and software components. A data center or cloud service can duplex multiple applications on the same hardware. The definition of infrastructure remains with each application.

The challenge of building fault tolerant mission critical application is deciding how the programs should communicate with other programs and devices.

Since every hardware component has finite service life, in theory, mission critical software programs must be completely decoupled from hardware components, such as networking, processing, storage, sensors and other devices. This decoupling affords hardware management freedom without changing programs.

This simple requirement seems very difficult to satisfy in practice.

==Canary In The Coal Mine==
The TCP/IP protocol was an experimental protocol for connecting arbitrary two computers reliably in the world-wide network like the "canary in a coal mine". The OSI model <ref>https://en.wikipedia.org/wiki/OSI_model</ref> is a conceptual model from the ISO (International Organization for Standardization) that provides "a common basis for the coordination of standards development for the purpose of systems interconnection <ref>https://www.iso.org/standard/20269.html</ref>. Today, its 7-layer model is widely taught in universities and technology schools.

For every connection-oriented socket circuit, all commercial implementations guarantees "order-preserved lossless data communication", packet losses, duplicates and errors are automatically corrected in the lower layer protocols. It seems perfectly reasonable to deploy this "hop-to-hop" connected-oriented TCP sockets for mission critical applications.

Unfortunately, the fine-prints in the OSI model specification have not caught any attention. The "order-preserved lossless data communication" is guaranteed only if both the sender and receiver are 100% reliable. If the sender or the receiver can crash arbitrarily, then reliable communication is impossible <ref>https://groups.csail.mit.edu/tds/papers/Lynch/jacm93.pdf</ref>. In practice, we call the TCP/IP protocol the "best effort" reliable protocol for all nodes are indeed try their best to forward packets and repair errors and duplicates. Building mission critical application using these protocols directly is inappropriate.

The problem is that it is impossible to eliminate single-point failures. The "canary" worked well only for communication applications where data losses and service downtimes can be tolerated. For mission critical applications, such as banking, trading, air/sea/land navigation, service crashes can cause irreparable damages and loss of human lives.

Even for banking applications, arbitrary transaction losses cannot be eliminated completely. Banks resort to legal measures to compensate verified customer losses. There are unclaimed funds to be handled by the banks.

In business, the IT professionals simply try to minimize "opportunity costs". Solving the infrastructure scaling problem seems beyond our reach.

==Fruits of Poisonous Tree==
The "hop-to-hop" protocol is the DNA of existing enterprise system program paradigms. These include RPC (remote procedure call), MPI (message passing interface), RMI (remote method invocation), distributed share-memory and many others. These are the only means to communicate and retrieve data from a remote computer.

Applications built using these protocols form infrastructures that have many single-point failures. Every such point failure can bring down the entire enterprise.

The "Achilles Heel" of the legacy enterprise programming paradigms is the lack of "re-transmission discipline". The hop-to-hop protocols provide false hope of data communication reliability. Programmers are at a loss when dealing with timeout events: do we retransmit or not retransmit? If not, data would be lost. If we do, how to handle if duplicates? what is the probability of success from the last timeout?
[[File:Achilles-heel.png|center|thumb|Achilles-heel]]

To eliminate infrastructure single-point failures requires complete program and data decoupling from hardware components -- a programming paradigm shift from the hop-to-hop communication paradigms.

==Active Content Addressable Networking (ACAN)==
Content addressable networks are peer-to-peer(P2P) networks. There are many proposed contend addressable networks (CAN) <ref>https://en.wikipedia.org/wiki/Content-addressable_network</ref>. These include distributed hash table (DHT)<ref>https://en.wikipedia.org/wiki/Distributed_hash_table</ref>, and projects: Chord<ref>https://en.wikipedia.org/wiki/Chord_(peer-to-peer)</ref>, Pastry<ref>https://en.wikipedia.org/wiki/Pastry_(DHT)</ref> and Tapestry<ref>https://en.wikipedia.org/wiki/Tapestry_(DHT)</ref>. These networks focused on information retrieval efficiency.

We need information retrieval efficiency and the freedom of multiplexing hardware components in real time. We call this ACAN (Active Content Addressable Networking).

The idea of ACAN is to enable automated parallel processing based on application's data retrieval patterns without explicitly building parallel SIMD, MIMD and pipeline clusters. This was inspired by the failures from the early-day dataflow machine research <ref>https://en.wikipedia.org/wiki/Dataflow</ref>. The earlier dataflow computer research failed to recognize the importance of parallel processing granularity<ref>https://en.wikipedia.org/wiki/Dataflow_architecture</ref>. The meticulously designed multiprocessor architectures failed to compete against simpler single processors.

The parallel processing granularity optimization problem needs to balance the disparity of processing and communication capabilities in an infrastructure. Conventional wisdom considers communication overheads are the main challenge in parallel computing. In reality, synchronization overheads are the main problem, unless computing speeds are perfectly matched with the communication latencies, optimal parallel performance is not possible. This situation may be visualized as the fastest crossing a muddy area and a hard surface area where the straight line is obviously not optimal:
[[File:BrachistochroneExplained.jpg|center|thumb]]

Depending upon the resistances, the optimal point can be anywhere along the interface between the two medium.

The ancient Brachistochrone problem <ref>https://www.researchgate.net/publication/319996786_Scalability_Dilemma_and_Statistic_Multiplexed_Computing_-_A_Theory_and_Experiment</ref> models this problem in physics, a puzzle solved by Johnann Bernoulli <ref>https://en.wikipedia.org/wiki/Brachistochrone_curve</ref>. The solution is to optimize between two counter-acting forces: gravity and normal force when the gravity changes continuously.
[[File:Petite brachistochrone.gif|alt=Brachistochrone Curve|center|thumb|Brachistochrone Curve]]

For parallel computing, depending on the loads and system scheduling policies, the deliverable computing and communication speeds change dynamically. Precise measures are not possible. Finding the optimal granularity requires the program-to-program communication protocol to allow granularity changes without re-compiling the source programs. Furthermore, the load fluctuations in parallel processing also include potential component failures. The peer-to-peer ACAN protocol was designed to fit both needs: load balancing and fault tolerance.

On surface, parallel computing using P2P network will be slower than direct hop-to-hop networks, such as MPI -- the commonly used TOP500 supercomputer benchmark protocol. The problem is that parallel program built using hop-to-hop protocol such as MPI require explicit partitioning factor programmed before compilation. Changing granularity require re-programming. Tuning for the optimal granularity would be exceedingly laborious.

ACAN used the Tuple Space abstraction for automated data-parallel computing <ref>J. Shi, Statistic Multiplexed Computing System for Network-Scale Reliable High Performance Services, US PTO, #US 11,588,926 B2, granted February 21, 2023 </ref>.

Computing experiments demonstrated that optimal granularity tuning using ACAN can out-perform fixed partitioned MPI program consistently at multiple optimal points<ref>https://www.researchgate.net/publication/319996786_Scalability_Dilemma_and_Statistic_Multiplexed_Computing_-_A_Theory_and_Experiment</ref>.

[[File:OptimalGranularities.jpg|center|thumb]]
The optimal granularities (lowest points on the black-line in the above figure) share the same property as the points on the Brachistochrone curve where all points will have the same shortest traversal time regardless the starting positions on the curve [src="https://www.youtube.com/embed/skvnj67YGmw?start=1354"].

In the parallel computing experiments, the communication capacity is changing by tuning the granularity at regular intervals (smaller granularity has more frequent communication sessions thus more overheads, larger granularity has less communication sessions but larger synchronization overheads).

Similar experiments were conducted on ACAN storage performance against the Hadoop distributed file system <ref>https://www.researchgate.net/publication/285579358_AnkaCom_A_Development_and_Experiment_for_Extreme_Scale_Computing</ref>.

Programs in ACAN are "stateless" programs that can run on any computer in ACAN. Therefore the ACAN infrastructure will have no single-point failures regardless the scale. The ACAN infrastructure can be repaired or resized in real time without interrupting service. Real time granularity change is also possible without interrupting services.

A more remarkable feature of ACAN applications is the ability to deliver unbounded performance as the infrastructure expands in size with open problem sizes. It is theoretically capable to harness multiple quantum computers.

==Blockchain Protocols==
Blockchain protocol also forms P2P network. Although there are different consensus protocols, such as POW (proof of work), POS (proof of stake), POH (proof of history) and POP (proof of possession), etc., the general architecture remains the same: the protocol runs on all computers. Each computer validates transactions subject to the consensus protocol for finality. Once committed to the cryptographically linked chain, the transactions are immutable. The consensus protocol ensures double-spending does not happen.

POW protocol is not environmental friendly that consumes too much electricity for solving the mining puzzles. Other consensus protocols are more energy efficient but all suffer the same scaling challenges: expanding the network and growing the ledger will bring down the network performance gradually. The storage requirements are monotonically increasing. The network will eventually crash when all nodes are storage saturated. Dividing the chain into multiple "shards" can only postpone the eventual saturation at the expense of increased protocol complexity.

The blockchain protocols avoided the hop-to-hop protocol trap by using various "gossip" protocols. In theory, there should be no single-point failure in any blockchain network and applications. Therefore, if it is not for protocol bugs, there should never be a service downtime. The Bitcoin network demonstrated such an excellent uptime record<ref>https://buybitcoinworldwide.com/bitcoin-uptime/</ref> that no legacy infrastructures could match.

Another remarkable feature of the Bitcoin network is that its protocol programs are Open Source. Anyone can download and manipulate it and turn it to attack the network. There has been no successful Bitcoin network attacks since its 2009 launch.

It is also interesting to observe that the blockchain protocols are silent on transaction re-transmission discipline. The blockchain wallets are responsible to check their own transactions' status and retransmit if necessary. Since double-spending is not possible, retransmitting a transaction is a trivial matter and it would most likely find a different route for transaction approval.

However, scalability remains the common challenge to all blockchain protocols. For POW consensus chains, the increasing energy consumption caused serious sustainability concerns. Since the cryptographic proved ledgers are immutable, for POS chains, although more than 99% energy consumption reduction can be achieved, the blockchain network's scalability is still challenged, since the chains will have to shutdown when all nodes storage are saturated.

It is evident that all blockchains should be infinitely scalable to be considered "digital gold". This means that expanding the network (adding nodes) should increase the network's performance, reliability and security. This is the motivation for the SMC Blockchain Protocol.

== SMC Blockchain Protocol ==
SMC blockchain protocol aims to solve the scalability challenge by enabling automated parallel processing while enhancing network security and reliability at the same time. The ACAN concept is a perfect fit for this case. ACAN enables automated SMC by forcing the transaction validation processes to form SIMD, MIMD and pipeline clusters in real time.

Unlike other chains, SMC Blockchain Protocol only maintains (R > 1) copies of the ledger on randomly selected nodes. This enables the overall network storage capacity to grow indefinitely by adding more nodes. The value of R constrains the transaction replication overheads to a constant thus accelerating transaction processing throughput by adding nodes. The actual R value can be determined experimentally without stopping service.

The SMC Blockchain network (TOIchain) supports regular, "staking" and "seed" nodes. A regular node is similar to a "light node" in Bitcoin that only receives transactions and forwards them to "staking" nodes. Unlike a Bitcoin "light node", a regular TOI node can optionally store validated blocks and be paid (need a unique wallet address) for the storage and accesses. A "staking" node is a regular node uniquely associated with another wallet address by a "staking contract", such as "50 TOINs for 3 months starting now". The staking contracts are used by randomly selected "seed" nodes to build random transaction validation committees (Prove of Stake consensus protocol).

A "seed" node is TOI Foundation supported service. They serve as the DNS for TOIchain and have all features as a "staking" node where the "staking contract" and wallet address are owned by TOI Foundation. The TOIchain operates on EPOCHs as heartbeats for the network. Each EPOCH corresponds to a randomly selected "validation committee" of "staking" nodes. A randomly selected "seed" node set decides the formation of committee.

Each "validation committee" can have up to 128 validators. Each validator validates local transactions in parallel against the current best chain state. The committee assembles a block of partially validated transactions for committee-wide validation. A majority agreement will decide the fully validated transactions into the new block. The block is considered "confirmed" but not "finalized".

The new block must be validated against the EPOCH-id -1 block before it is "finalized". This step is skipped for the genesis block. The committees must wait until the EPOCH-id -1 block becomes the chain tip. Thus, multiple validation committees form a virtual pipeline at runtime. Finalized blocks match generated EPOCHs. Transactions fail in any stage are removed from the block. There maybe empty blocks where all transactions fail or the network is idling.

Transactions may be replicated before validation to improve the chance of being included into a block by paying more fees. The redundant transactions will fail except for the first one.

When the network has no "staking" nodes, the "seed" nodes become "staking" nodes to keep the network operational. The TOI Foundation receives the transaction fees and validation rewards.

The TOI Foundation maintains the "seed" nodes and the overall network security and safety via automatic network monitoring and maintenance scripts.

== SMC POS Consensus ==
SMC POS consensus protocol randomly selects staking validators without staking pools to deter centralization attempts. SMC POS protocol also has an adjustable replication factor that the network ledger has a fixed replication factor that can be tuned on demand without service interruptions. Therefore, adding nodes, the SMC POS consensus protocol can deliver:

# Byzantine failure resistance
# Fault tolerance
# Program tamper resistance
# Centralization avoidance
# Incrementally better performance, security and reliability

More nodes in the network expands the network storage capacity without increasing replication overheads. More nodes facilitates longer pipeline and higher parallelism for better performances and better randomness for security. Higher R values improve service reliability. Lower R values deliver better performances. Since the number of nodes can be far greater than R, monotonic performance increase can always be achieved. Most importantly, the native SMC protocol supports all these network parameter adjustments without protocol change.

SMC blockchain protocol is also silent on transaction retransmission discipline. Since it is impossible to "double spend" under SMC protocol, transaction retransmission will enable different approval routes without double-spend risks (multiplexing). This ensures seamless integration with legacy blockchain wallets and infrastructures.

== Summary ==
SMC blockchain protocol is the only statistic multiplexed blockchain protocol to date. The SMC technology development history links the blockchain protocol development to stateless HPC (high performance computing) developments. This is the only known technology that can offer decentralized processing for centralized controls, which is the perfect gateway to integrate web2.0 applications for web3.0 infrastructures.

== References: ==
<references />

SMC

2024-05-30T20:50:11Z

Justin: /* Blockchain Protocols */

== Introduction ==

SMC stands for Statistic Multiplexed Computing and Communication. The idea was inspired by von Neumann's 1952 paper on probabilistic logics and synthesis of reliable organisms using unreliable components <ref>https://static.ias.edu/pitp/archive/2012files/Probabilistic_Logics.pdf</ref>. Building fault tolerant mission critical system was the triggering use case.

Modern computer applications must rely on networking services. Every networked application forms its own infrastructure consisting of network, processing, storage and software components. A data center or cloud service can duplex multiple applications on the same hardware. The definition of infrastructure remains with each application.

The challenge of building fault tolerant mission critical application is deciding how the programs should communicate with other programs and devices.

Since every hardware component has finite service life, in theory, mission critical software programs must be completely decoupled from hardware components, such as networking, processing, storage, sensors and other devices. This decoupling affords hardware management freedom without changing programs.

This simple requirement seems very difficult to satisfy in practice.

==Canary In The Coal Mine==
The TCP/IP protocol was an experimental protocol for connecting arbitrary two computers reliably in the world-wide network like the "canary in a coal mine". The OSI model <ref>https://en.wikipedia.org/wiki/OSI_model</ref> is a conceptual model from the ISO (International Organization for Standardization) that provides "a common basis for the coordination of standards development for the purpose of systems interconnection <ref>https://www.iso.org/standard/20269.html</ref>. Today, its 7-layer model is widely taught in universities and technology schools.

For every connection-oriented socket circuit, all commercial implementations guarantees "order-preserved lossless data communication", packet losses, duplicates and errors are automatically corrected in the lower layer protocols. It seems perfectly reasonable to deploy this "hop-to-hop" connected-oriented TCP sockets for mission critical applications.

Unfortunately, the fine-prints in the OSI model specification have not caught any attention. The "order-preserved lossless data communication" is guaranteed only if both the sender and receiver are 100% reliable. If the sender or the receiver can crash arbitrarily, then reliable communication is impossible <ref>https://groups.csail.mit.edu/tds/papers/Lynch/jacm93.pdf</ref>. In practice, we call the TCP/IP protocol the "best effort" reliable protocol for all nodes are indeed try their best to forward packets and repair errors and duplicates. Building mission critical application using these protocols is inappropriate.

The problem is that it is impossible to eliminate single-point failures. The "canary" worked well only for communication applications where data losses and service downtimes can be tolerated to some extent. For mission critical applications, such as banking, trading, air/sea/land navigation, service crashes can cause irreparable damages and loss of human lives.

Even for banking applications, arbitrary transaction losses cannot be eliminated completely. Banks resort to legal measures to compensate verified customer losses. There are unclaimed funds to be handled by the banks.

In business, the IT professionals simply try to minimize "opportunity costs". Solving the infrastructure scaling problem seems out of reach for most people.

==Fruits of Poisonous Tree==
The "hop-to-hop" protocol is the DNA of existing enterprise system program paradigms. These include RPC (remote procedure call), MPI (message passing interface), RMI (remote method invocation), distributed share-memory and many others. These are the only means to communicate and retrieve data from a remote computer.

Applications built using these protocols form infrastructures that have many single-point failures. Every such point failure can bring down the entire enterprise.

The "Achilles Heel" of the legacy enterprise programming paradigms is the lack of "re-transmission discipline". The hop-to-hop protocols provide false hope of data communication reliability. Programmers are at a loss when dealing with timeout events: do we retransmit or not retransmit? If not, data would be lost. If we do, how to handle if duplicates? what is the probability of success from the last timeout?
[[File:Achilles-heel.png|center|thumb|Achilles-heel]]

To eliminate infrastructure single-point failures requires complete program and data decoupling from hardware components -- a programming paradigm shift from the hop-to-hop communication paradigms.

==Active Content Addressable Networking (ACAN)==
Content addressable networks are peer-to-peer(P2P) networks. There are many proposed contend addressable networks (CAN) <ref>https://en.wikipedia.org/wiki/Content-addressable_network</ref>. These include distributed hash table (DHT)<ref>https://en.wikipedia.org/wiki/Distributed_hash_table</ref>, and projects: Chord<ref>https://en.wikipedia.org/wiki/Chord_(peer-to-peer)</ref>, Pastry<ref>https://en.wikipedia.org/wiki/Pastry_(DHT)</ref> and Tapestry<ref>https://en.wikipedia.org/wiki/Tapestry_(DHT)</ref>. These networks focused on information retrieval efficiency.

We need information retrieval efficiency and the freedom of multiplexing hardware components in real time. We call this ACAN (Active Content Addressable Networking).

The idea of ACAN is to enable automated parallel processing based on application's data retrieval patterns without explicitly building parallel SIMD, MIMD and pipeline clusters. This was inspired by the failures from the early-day dataflow machine research <ref>https://en.wikipedia.org/wiki/Dataflow</ref>. The earlier dataflow computer research failed to recognize the importance of parallel processing granularity<ref>https://en.wikipedia.org/wiki/Dataflow_architecture</ref>. The meticulously designed multiprocessor architectures failed to compete against simpler single processors.

The parallel processing granularity optimization problem needs to balance the disparity of processing and communication capabilities in an infrastructure. Conventional wisdom considers communication overheads are the main challenge in parallel computing. In reality, synchronization overheads are the main problem, unless computing speeds are perfectly matched with the communication latencies, optimal parallel performance is not possible. This situation may be visualized as the fastest crossing a muddy area and a hard surface area where the straight line is obviously not optimal:
[[File:BrachistochroneExplained.jpg|center|thumb]]

Depending upon the resistances, the optimal point can be anywhere along the interface between the two medium.

The ancient Brachistochrone problem <ref>https://www.researchgate.net/publication/319996786_Scalability_Dilemma_and_Statistic_Multiplexed_Computing_-_A_Theory_and_Experiment</ref> models this problem in physics, a puzzle solved by Johnann Bernoulli <ref>https://en.wikipedia.org/wiki/Brachistochrone_curve</ref>. The solution is to optimize between two counter-acting forces: gravity and normal force when the gravity changes continuously.
[[File:Petite brachistochrone.gif|alt=Brachistochrone Curve|center|thumb|Brachistochrone Curve]]

For parallel computing, depending on the loads and system scheduling policies, the deliverable computing and communication speeds change dynamically. Precise measures are not possible. Finding the optimal granularity requires the program-to-program communication protocol to allow granularity changes without re-compiling the source programs. Furthermore, the load fluctuations in parallel processing also include potential component failures. The peer-to-peer ACAN protocol was designed to fit both needs: load balancing and fault tolerance.

On surface, parallel computing using P2P network will be slower than direct hop-to-hop networks, such as MPI -- the commonly used TOP500 supercomputer benchmark protocol. The problem is that parallel program built using hop-to-hop protocol such as MPI require explicit partitioning factor programmed before compilation. Changing granularity require re-programming. Tuning for the optimal granularity would be exceedingly laborious.

ACAN used the Tuple Space abstraction for automated data-parallel computing <ref>J. Shi, Statistic Multiplexed Computing System for Network-Scale Reliable High Performance Services, US PTO, #US 11,588,926 B2, granted February 21, 2023 </ref>.

Computing experiments demonstrated that optimal granularity tuning using ACAN can out-perform fixed partitioned MPI program consistently at multiple optimal points<ref>https://www.researchgate.net/publication/319996786_Scalability_Dilemma_and_Statistic_Multiplexed_Computing_-_A_Theory_and_Experiment</ref>.

[[File:OptimalGranularities.jpg|center|thumb]]
The optimal granularities (lowest points on the black-line in the above figure) share the same property as the points on the Brachistochrone curve where all points will have the same shortest traversal time regardless the starting positions on the curve [src="https://www.youtube.com/embed/skvnj67YGmw?start=1354"].

In the parallel computing experiments, the communication capacity is changing by tuning the granularity at regular intervals (smaller granularity has more frequent communication sessions thus more overheads, larger granularity has less communication sessions but larger synchronization overheads).

Similar experiments were conducted on ACAN storage performance against the Hadoop distributed file system <ref>https://www.researchgate.net/publication/285579358_AnkaCom_A_Development_and_Experiment_for_Extreme_Scale_Computing</ref>.

Programs in ACAN are "stateless" programs that can run on any computer in ACAN. Therefore the ACAN infrastructure will have no single-point failures regardless the scale. The ACAN infrastructure can be repaired or resized in real time without interrupting service. Real time granularity change is also possible without interrupting services.

A more remarkable feature of ACAN applications is the ability to deliver unbounded performance as the infrastructure expands in size with open problem sizes. It is theoretically capable to harness multiple quantum computers.

==Blockchain Protocols==
Blockchain protocol also forms P2P network. Although there are different consensus protocols, such as POW (proof of work), POS (proof of stake), POH (proof of history) and POP (proof of possession), etc., the general architecture remains the same: the protocol runs on all computers. Each computer validates transactions subject to the consensus protocol for finality. Once committed to the cryptographically linked chain, the transactions are immutable. The consensus protocol ensures double-spending does not happen.

POW protocol is not environmental friendly that consumes too much electricity for solving the mining puzzles. Other consensus protocols are more energy efficient but all suffer the same scaling challenges: expanding the network and growing the ledger will bring down the network performance gradually. The storage requirements are monotonically increasing. The network will eventually crash when all nodes are storage saturated. Dividing the chain into multiple "shards" can only postpone the eventual saturation at the expense of increased protocol complexity.

The blockchain protocols avoided the hop-to-hop protocol trap by using various "gossip" protocols. In theory, there should be no single-point failure in any blockchain network and applications. Therefore, if it is not for protocol bugs, there should never be a service downtime. The Bitcoin network demonstrated such an excellent uptime record<ref>https://buybitcoinworldwide.com/bitcoin-uptime/</ref> that no legacy infrastructures could match.

Another remarkable feature of the Bitcoin network is that its protocol programs are Open Source. Anyone can download and manipulate it and turn it to attack the network. There has been no successful Bitcoin network attacks since its 2009 launch.

It is also interesting to observe that the blockchain protocols are silent on transaction re-transmission discipline. The blockchain wallets are responsible to check their own transactions' status and retransmit if necessary. Since double-spending is not possible, retransmitting a transaction is a trivial matter and it would most likely find a different route for transaction approval.

However, scalability remains the common challenge to all blockchain protocols. For POW consensus chains, the increasing energy consumption caused serious sustainability concerns. Since the cryptographic proved ledgers are immutable, for POS chains, although more than 99% energy consumption reduction can be achieved, the blockchain network's scalability is still challenged, since the chains will have to shutdown when all nodes storage are saturated.

It is evident that all blockchains should be infinitely scalable to be considered "digital gold". This means that expanding the network (adding nodes) should increase the network's performance, reliability and security. This is the motivation for the SMC Blockchain Protocol.

== SMC Blockchain Protocol ==
SMC blockchain protocol aims to solve the scalability challenge by enabling automated parallel processing while enhancing network security and reliability at the same time. The ACAN concept is a perfect fit for this case. ACAN enables automated SMC by forcing the transaction validation processes to form SIMD, MIMD and pipeline clusters in real time.

Unlike other chains, SMC Blockchain Protocol only maintains (R > 1) copies of the ledger on randomly selected nodes. This enables the overall network storage capacity to grow indefinitely by adding more nodes. The value of R constrains the transaction replication overheads to a constant thus accelerating transaction processing throughput by adding nodes. The actual R value can be determined experimentally without stopping service.

The SMC Blockchain network (TOIchain) supports regular, "staking" and "seed" nodes. A regular node is similar to a "light node" in Bitcoin that only receives transactions and forwards them to "staking" nodes. Unlike a Bitcoin "light node", a regular TOI node can optionally store validated blocks and be paid (need a unique wallet address) for the storage and accesses. A "staking" node is a regular node uniquely associated with another wallet address by a "staking contract", such as "50 TOINs for 3 months starting now". The staking contracts are used by randomly selected "seed" nodes to build random transaction validation committees (Prove of Stake consensus protocol).

A "seed" node is TOI Foundation supported service. They serve as the DNS for TOIchain and have all features as a "staking" node where the "staking contract" and wallet address are owned by TOI Foundation. The TOIchain operates on EPOCHs as heartbeats for the network. Each EPOCH corresponds to a randomly selected "validation committee" of "staking" nodes. A randomly selected "seed" node set decides the formation of committee.

Each "validation committee" can have up to 128 validators. Each validator validates local transactions in parallel against the current best chain state. The committee assembles a block of partially validated transactions for committee-wide validation. A majority agreement will decide the fully validated transactions into the new block. The block is considered "confirmed" but not "finalized".

The new block must be validated against the EPOCH-id -1 block before it is "finalized". This step is skipped for the genesis block. The committees must wait until the EPOCH-id -1 block becomes the chain tip. Thus, multiple validation committees form a virtual pipeline at runtime. Finalized blocks match generated EPOCHs. Transactions fail in any stage are removed from the block. There maybe empty blocks where all transactions fail or the network is idling.

Transactions may be replicated before validation to improve the chance of being included into a block by paying more fees. The redundant transactions will fail except for the first one.

When the network has no "staking" nodes, the "seed" nodes become "staking" nodes to keep the network operational. The TOI Foundation receives the transaction fees and validation rewards.

The TOI Foundation maintains the "seed" nodes and the overall network security and safety via automatic network monitoring and maintenance scripts.

== SMC POS Consensus ==
SMC POS consensus protocol randomly selects staking validators without staking pools to deter centralization attempts. SMC POS protocol also has an adjustable replication factor that the network ledger has a fixed replication factor that can be tuned on demand without service interruptions. Therefore, adding nodes, the SMC POS consensus protocol can deliver:

# Byzantine failure resistance
# Fault tolerance
# Program tamper resistance
# Centralization avoidance
# Incrementally better performance, security and reliability

More nodes in the network expands the network storage capacity without increasing replication overheads. More nodes facilitates longer pipeline and higher parallelism for better performances and better randomness for security. Higher R values improve service reliability. Lower R values deliver better performances. Since the number of nodes can be far greater than R, monotonic performance increase can always be achieved. Most importantly, the native SMC protocol supports all these network parameter adjustments without protocol change.

SMC blockchain protocol is also silent on transaction retransmission discipline. Since it is impossible to "double spend" under SMC protocol, transaction retransmission will enable different approval routes without double-spend risks (multiplexing). This ensures seamless integration with legacy blockchain wallets and infrastructures.

== Summary ==
SMC blockchain protocol is the only statistic multiplexed blockchain protocol to date. The SMC technology development history links the blockchain protocol development to stateless HPC (high performance computing) developments. This is the only known technology that can offer decentralized processing for centralized controls, which is the perfect gateway to integrate web2.0 applications for web3.0 infrastructures.

== References: ==
<references />

SMC

2024-05-30T20:45:14Z

Justin: /* SMC POS Consensus */

== Introduction ==

SMC stands for Statistic Multiplexed Computing and Communication. The idea was inspired by von Neumann's 1952 paper on probabilistic logics and synthesis of reliable organisms using unreliable components <ref>https://static.ias.edu/pitp/archive/2012files/Probabilistic_Logics.pdf</ref>. Building fault tolerant mission critical system was the triggering use case.

Modern computer applications must rely on networking services. Every networked application forms its own infrastructure consisting of network, processing, storage and software components. A data center or cloud service can duplex multiple applications on the same hardware. The definition of infrastructure remains with each application.

The challenge of building fault tolerant mission critical application is deciding how the programs should communicate with other programs and devices.

Since every hardware component has finite service life, in theory, mission critical software programs must be completely decoupled from hardware components, such as networking, processing, storage, sensors and other devices. This decoupling affords hardware management freedom without changing programs.

This simple requirement seems very difficult to satisfy in practice.

==Canary In The Coal Mine==
The TCP/IP protocol was an experimental protocol for connecting arbitrary two computers reliably in the world-wide network like the "canary in a coal mine". The OSI model <ref>https://en.wikipedia.org/wiki/OSI_model</ref> is a conceptual model from the ISO (International Organization for Standardization) that provides "a common basis for the coordination of standards development for the purpose of systems interconnection <ref>https://www.iso.org/standard/20269.html</ref>. Today, its 7-layer model is widely taught in universities and technology schools.

For every connection-oriented socket circuit, all commercial implementations guarantees "order-preserved lossless data communication", packet losses, duplicates and errors are automatically corrected in the lower layer protocols. It seems perfectly reasonable to deploy this "hop-to-hop" connected-oriented TCP sockets for mission critical applications.

Unfortunately, the fine-prints in the OSI model specification have not caught any attention. The "order-preserved lossless data communication" is guaranteed only if both the sender and receiver are 100% reliable. If the sender or the receiver can crash arbitrarily, then reliable communication is impossible <ref>https://groups.csail.mit.edu/tds/papers/Lynch/jacm93.pdf</ref>. In practice, we call the TCP/IP protocol the "best effort" reliable protocol for all nodes are indeed try their best to forward packets and repair errors and duplicates. Building mission critical application using these protocols is inappropriate.

The problem is that it is impossible to eliminate single-point failures. The "canary" worked well only for communication applications where data losses and service downtimes can be tolerated to some extent. For mission critical applications, such as banking, trading, air/sea/land navigation, service crashes can cause irreparable damages and loss of human lives.

Even for banking applications, arbitrary transaction losses cannot be eliminated completely. Banks resort to legal measures to compensate verified customer losses. There are unclaimed funds to be handled by the banks.

In business, the IT professionals simply try to minimize "opportunity costs". Solving the infrastructure scaling problem seems out of reach for most people.

==Fruits of Poisonous Tree==
The "hop-to-hop" protocol is the DNA of existing enterprise system program paradigms. These include RPC (remote procedure call), MPI (message passing interface), RMI (remote method invocation), distributed share-memory and many others. These are the only means to communicate and retrieve data from a remote computer.

Applications built using these protocols form infrastructures that have many single-point failures. Every such point failure can bring down the entire enterprise.

The "Achilles Heel" of the legacy enterprise programming paradigms is the lack of "re-transmission discipline". The hop-to-hop protocols provide false hope of data communication reliability. Programmers are at a loss when dealing with timeout events: do we retransmit or not retransmit? If not, data would be lost. If we do, how to handle if duplicates? what is the probability of success from the last timeout?
[[File:Achilles-heel.png|center|thumb|Achilles-heel]]

To eliminate infrastructure single-point failures requires complete program and data decoupling from hardware components -- a programming paradigm shift from the hop-to-hop communication paradigms.

==Active Content Addressable Networking (ACAN)==
Content addressable networks are peer-to-peer(P2P) networks. There are many proposed contend addressable networks (CAN) <ref>https://en.wikipedia.org/wiki/Content-addressable_network</ref>. These include distributed hash table (DHT)<ref>https://en.wikipedia.org/wiki/Distributed_hash_table</ref>, and projects: Chord<ref>https://en.wikipedia.org/wiki/Chord_(peer-to-peer)</ref>, Pastry<ref>https://en.wikipedia.org/wiki/Pastry_(DHT)</ref> and Tapestry<ref>https://en.wikipedia.org/wiki/Tapestry_(DHT)</ref>. These networks focused on information retrieval efficiency.

We need information retrieval efficiency and the freedom of multiplexing hardware components in real time. We call this ACAN (Active Content Addressable Networking).

The idea of ACAN is to enable automated parallel processing based on application's data retrieval patterns without explicitly building parallel SIMD, MIMD and pipeline clusters. This was inspired by the failures from the early-day dataflow machine research <ref>https://en.wikipedia.org/wiki/Dataflow</ref>. The earlier dataflow computer research failed to recognize the importance of parallel processing granularity<ref>https://en.wikipedia.org/wiki/Dataflow_architecture</ref>. The meticulously designed multiprocessor architectures failed to compete against simpler single processors.

The parallel processing granularity optimization problem needs to balance the disparity of processing and communication capabilities in an infrastructure. Conventional wisdom considers communication overheads are the main challenge in parallel computing. In reality, synchronization overheads are the main problem, unless computing speeds are perfectly matched with the communication latencies, optimal parallel performance is not possible. This situation may be visualized as the fastest crossing a muddy area and a hard surface area where the straight line is obviously not optimal:
[[File:BrachistochroneExplained.jpg|center|thumb]]

Depending upon the resistances, the optimal point can be anywhere along the interface between the two medium.

The ancient Brachistochrone problem <ref>https://www.researchgate.net/publication/319996786_Scalability_Dilemma_and_Statistic_Multiplexed_Computing_-_A_Theory_and_Experiment</ref> models this problem in physics, a puzzle solved by Johnann Bernoulli <ref>https://en.wikipedia.org/wiki/Brachistochrone_curve</ref>. The solution is to optimize between two counter-acting forces: gravity and normal force when the gravity changes continuously.
[[File:Petite brachistochrone.gif|alt=Brachistochrone Curve|center|thumb|Brachistochrone Curve]]

For parallel computing, depending on the loads and system scheduling policies, the deliverable computing and communication speeds change dynamically. Precise measures are not possible. Finding the optimal granularity requires the program-to-program communication protocol to allow granularity changes without re-compiling the source programs. Furthermore, the load fluctuations in parallel processing also include potential component failures. The peer-to-peer ACAN protocol was designed to fit both needs: load balancing and fault tolerance.

On surface, parallel computing using P2P network will be slower than direct hop-to-hop networks, such as MPI -- the commonly used TOP500 supercomputer benchmark protocol. The problem is that parallel program built using hop-to-hop protocol such as MPI require explicit partitioning factor programmed before compilation. Changing granularity require re-programming. Tuning for the optimal granularity would be exceedingly laborious.

ACAN used the Tuple Space abstraction for automated data-parallel computing <ref>J. Shi, Statistic Multiplexed Computing System for Network-Scale Reliable High Performance Services, US PTO, #US 11,588,926 B2, granted February 21, 2023 </ref>.

Computing experiments demonstrated that optimal granularity tuning using ACAN can out-perform fixed partitioned MPI program consistently at multiple optimal points<ref>https://www.researchgate.net/publication/319996786_Scalability_Dilemma_and_Statistic_Multiplexed_Computing_-_A_Theory_and_Experiment</ref>.

[[File:OptimalGranularities.jpg|center|thumb]]
The optimal granularities (lowest points on the black-line in the above figure) share the same property as the points on the Brachistochrone curve where all points will have the same shortest traversal time regardless the starting positions on the curve [src="https://www.youtube.com/embed/skvnj67YGmw?start=1354"].

In the parallel computing experiments, the communication capacity is changing by tuning the granularity at regular intervals (smaller granularity has more frequent communication sessions thus more overheads, larger granularity has less communication sessions but larger synchronization overheads).

Similar experiments were conducted on ACAN storage performance against the Hadoop distributed file system <ref>https://www.researchgate.net/publication/285579358_AnkaCom_A_Development_and_Experiment_for_Extreme_Scale_Computing</ref>.

Programs in ACAN are "stateless" programs that can run on any computer in ACAN. Therefore the ACAN infrastructure will have no single-point failures regardless the scale. The ACAN infrastructure can be repaired or resized in real time without interrupting service. Real time granularity change is also possible without interrupting services.

A more remarkable feature of ACAN applications is the ability to deliver unbounded performance as the infrastructure expands in size with open problem sizes. It is theoretically capable to harness multiple quantum computers.

==Blockchain Protocols==
Blockchain protocol also forms P2P network. Although there are different consensus protocols, such as POW (proof of work), POS (proof of stake), POH (proof of history) and POP (proof of possession), etc., the general architecture remains the same: the protocol runs on all computers. Each computer validates transactions subject to the consensus protocol for finality. Once committed to the cryptographically linked chain, the transactions are immutable. The consensus protocol ensures double-spending does not happen.

POW protocol is not environmental friendly that consumes too much electricity for solving the mining puzzles. Other consensus protocols are more energy efficient but all suffer the same scaling challenges: expanding the network and growing the ledger will bring down the network performance gradually. The storage requirements are monotonically increasing. The network will eventually crash when all nodes are storage saturated. Dividing the chain into multiple "shards" can only postpone the eventual saturation at the expense of increased protocol complexity.

The blockchain protocols avoided the hop-to-hop protocol trap by using various "gossip" protocols. In theory, there should be no single-point failure in any blockchain network and applications. Therefore, if it is not for protocol bugs, there should never be a service downtime. The Bitcoin network demonstrated such an excellent uptime record<ref>https://buybitcoinworldwide.com/bitcoin-uptime/</ref> that no legacy infrastructures could match.

Another remarkable feature of the Bitcoin network is that its protocol programs are Open Source. Anyone can download and manipulate it and turn it to attack the network. There has been no successful Bitcoin network attacks since its 2009 launch.

It is also interesting to observe that the blockchain protocols are silent on transaction re-transmission discipline. The blockchain wallets are responsible to check their own transactions' status and retransmit if necessary. Since double-spending is not possible, retransmitting a transaction is a trivial matter and it would most likely find a different route for transaction approval.

However, scalability remains the common challenge to all blockchain protocols. For POW consensus chains, the increasing energy consumption caused serious sustainability concerns. Since the cryptographic proved ledgers are immutable, for POS chains, although more than 99% energy consumption reduction can be achieved, the blockchain network's scalability is still challenged, since the chains will have to shutdown when all nodes storage are saturated.

It is evident that all blockchains should be infinitely scalable. This means that expanding the network (adding nodes) should increase the network's performance, reliability and security. This is the motivation for the SMC Blockchain Protocol.

== SMC Blockchain Protocol ==
SMC blockchain protocol aims to solve the scalability challenge by enabling automated parallel processing while enhancing network security and reliability at the same time. The ACAN concept is a perfect fit for this case. ACAN enables automated SMC by forcing the transaction validation processes to form SIMD, MIMD and pipeline clusters in real time.

Unlike other chains, SMC Blockchain Protocol only maintains (R > 1) copies of the ledger on randomly selected nodes. This enables the overall network storage capacity to grow indefinitely by adding more nodes. The value of R constrains the transaction replication overheads to a constant thus accelerating transaction processing throughput by adding nodes. The actual R value can be determined experimentally without stopping service.

The SMC Blockchain network (TOIchain) supports regular, "staking" and "seed" nodes. A regular node is similar to a "light node" in Bitcoin that only receives transactions and forwards them to "staking" nodes. Unlike a Bitcoin "light node", a regular TOI node can optionally store validated blocks and be paid (need a unique wallet address) for the storage and accesses. A "staking" node is a regular node uniquely associated with another wallet address by a "staking contract", such as "50 TOINs for 3 months starting now". The staking contracts are used by randomly selected "seed" nodes to build random transaction validation committees (Prove of Stake consensus protocol).

A "seed" node is TOI Foundation supported service. They serve as the DNS for TOIchain and have all features as a "staking" node where the "staking contract" and wallet address are owned by TOI Foundation. The TOIchain operates on EPOCHs as heartbeats for the network. Each EPOCH corresponds to a randomly selected "validation committee" of "staking" nodes. A randomly selected "seed" node set decides the formation of committee.

Each "validation committee" can have up to 128 validators. Each validator validates local transactions in parallel against the current best chain state. The committee assembles a block of partially validated transactions for committee-wide validation. A majority agreement will decide the fully validated transactions into the new block. The block is considered "confirmed" but not "finalized".

The new block must be validated against the EPOCH-id -1 block before it is "finalized". This step is skipped for the genesis block. The committees must wait until the EPOCH-id -1 block becomes the chain tip. Thus, multiple validation committees form a virtual pipeline at runtime. Finalized blocks match generated EPOCHs. Transactions fail in any stage are removed from the block. There maybe empty blocks where all transactions fail or the network is idling.

Transactions may be replicated before validation to improve the chance of being included into a block by paying more fees. The redundant transactions will fail except for the first one.

When the network has no "staking" nodes, the "seed" nodes become "staking" nodes to keep the network operational. The TOI Foundation receives the transaction fees and validation rewards.

The TOI Foundation maintains the "seed" nodes and the overall network security and safety via automatic network monitoring and maintenance scripts.

== SMC POS Consensus ==
SMC POS consensus protocol randomly selects staking validators without staking pools to deter centralization attempts. SMC POS protocol also has an adjustable replication factor that the network ledger has a fixed replication factor that can be tuned on demand without service interruptions. Therefore, adding nodes, the SMC POS consensus protocol can deliver:

# Byzantine failure resistance
# Fault tolerance
# Program tamper resistance
# Centralization avoidance
# Incrementally better performance, security and reliability

More nodes in the network expands the network storage capacity without increasing replication overheads. More nodes facilitates longer pipeline and higher parallelism for better performances and better randomness for security. Higher R values improve service reliability. Lower R values deliver better performances. Since the number of nodes can be far greater than R, monotonic performance increase can always be achieved. Most importantly, the native SMC protocol supports all these network parameter adjustments without protocol change.

SMC blockchain protocol is also silent on transaction retransmission discipline. Since it is impossible to "double spend" under SMC protocol, transaction retransmission will enable different approval routes without double-spend risks (multiplexing). This ensures seamless integration with legacy blockchain wallets and infrastructures.

== Summary ==
SMC blockchain protocol is the only statistic multiplexed blockchain protocol to date. The SMC technology development history links the blockchain protocol development to stateless HPC (high performance computing) developments. This is the only known technology that can offer decentralized processing for centralized controls, which is the perfect gateway to integrate web2.0 applications for web3.0 infrastructures.

== References: ==
<references />

SMC

2024-05-30T20:33:34Z

Justin: /* SMC Blockchain Protocol */

== Introduction ==

SMC stands for Statistic Multiplexed Computing and Communication. The idea was inspired by von Neumann's 1952 paper on probabilistic logics and synthesis of reliable organisms using unreliable components <ref>https://static.ias.edu/pitp/archive/2012files/Probabilistic_Logics.pdf</ref>. Building fault tolerant mission critical system was the triggering use case.

Modern computer applications must rely on networking services. Every networked application forms its own infrastructure consisting of network, processing, storage and software components. A data center or cloud service can duplex multiple applications on the same hardware. The definition of infrastructure remains with each application.

The challenge of building fault tolerant mission critical application is deciding how the programs should communicate with other programs and devices.

Since every hardware component has finite service life, in theory, mission critical software programs must be completely decoupled from hardware components, such as networking, processing, storage, sensors and other devices. This decoupling affords hardware management freedom without changing programs.

This simple requirement seems very difficult to satisfy in practice.

==Canary In The Coal Mine==
The TCP/IP protocol was an experimental protocol for connecting arbitrary two computers reliably in the world-wide network like the "canary in a coal mine". The OSI model <ref>https://en.wikipedia.org/wiki/OSI_model</ref> is a conceptual model from the ISO (International Organization for Standardization) that provides "a common basis for the coordination of standards development for the purpose of systems interconnection <ref>https://www.iso.org/standard/20269.html</ref>. Today, its 7-layer model is widely taught in universities and technology schools.

For every connection-oriented socket circuit, all commercial implementations guarantees "order-preserved lossless data communication", packet losses, duplicates and errors are automatically corrected in the lower layer protocols. It seems perfectly reasonable to deploy this "hop-to-hop" connected-oriented TCP sockets for mission critical applications.

Unfortunately, the fine-prints in the OSI model specification have not caught any attention. The "order-preserved lossless data communication" is guaranteed only if both the sender and receiver are 100% reliable. If the sender or the receiver can crash arbitrarily, then reliable communication is impossible <ref>https://groups.csail.mit.edu/tds/papers/Lynch/jacm93.pdf</ref>. In practice, we call the TCP/IP protocol the "best effort" reliable protocol for all nodes are indeed try their best to forward packets and repair errors and duplicates. Building mission critical application using these protocols is inappropriate.

The problem is that it is impossible to eliminate single-point failures. The "canary" worked well only for communication applications where data losses and service downtimes can be tolerated to some extent. For mission critical applications, such as banking, trading, air/sea/land navigation, service crashes can cause irreparable damages and loss of human lives.

Even for banking applications, arbitrary transaction losses cannot be eliminated completely. Banks resort to legal measures to compensate verified customer losses. There are unclaimed funds to be handled by the banks.

In business, the IT professionals simply try to minimize "opportunity costs". Solving the infrastructure scaling problem seems out of reach for most people.

==Fruits of Poisonous Tree==
The "hop-to-hop" protocol is the DNA of existing enterprise system program paradigms. These include RPC (remote procedure call), MPI (message passing interface), RMI (remote method invocation), distributed share-memory and many others. These are the only means to communicate and retrieve data from a remote computer.

Applications built using these protocols form infrastructures that have many single-point failures. Every such point failure can bring down the entire enterprise.

The "Achilles Heel" of the legacy enterprise programming paradigms is the lack of "re-transmission discipline". The hop-to-hop protocols provide false hope of data communication reliability. Programmers are at a loss when dealing with timeout events: do we retransmit or not retransmit? If not, data would be lost. If we do, how to handle if duplicates? what is the probability of success from the last timeout?
[[File:Achilles-heel.png|center|thumb|Achilles-heel]]

To eliminate infrastructure single-point failures requires complete program and data decoupling from hardware components -- a programming paradigm shift from the hop-to-hop communication paradigms.

==Active Content Addressable Networking (ACAN)==
Content addressable networks are peer-to-peer(P2P) networks. There are many proposed contend addressable networks (CAN) <ref>https://en.wikipedia.org/wiki/Content-addressable_network</ref>. These include distributed hash table (DHT)<ref>https://en.wikipedia.org/wiki/Distributed_hash_table</ref>, and projects: Chord<ref>https://en.wikipedia.org/wiki/Chord_(peer-to-peer)</ref>, Pastry<ref>https://en.wikipedia.org/wiki/Pastry_(DHT)</ref> and Tapestry<ref>https://en.wikipedia.org/wiki/Tapestry_(DHT)</ref>. These networks focused on information retrieval efficiency.

We need information retrieval efficiency and the freedom of multiplexing hardware components in real time. We call this ACAN (Active Content Addressable Networking).

The idea of ACAN is to enable automated parallel processing based on application's data retrieval patterns without explicitly building parallel SIMD, MIMD and pipeline clusters. This was inspired by the failures from the early-day dataflow machine research <ref>https://en.wikipedia.org/wiki/Dataflow</ref>. The earlier dataflow computer research failed to recognize the importance of parallel processing granularity<ref>https://en.wikipedia.org/wiki/Dataflow_architecture</ref>. The meticulously designed multiprocessor architectures failed to compete against simpler single processors.

The parallel processing granularity optimization problem needs to balance the disparity of processing and communication capabilities in an infrastructure. Conventional wisdom considers communication overheads are the main challenge in parallel computing. In reality, synchronization overheads are the main problem, unless computing speeds are perfectly matched with the communication latencies, optimal parallel performance is not possible. This situation may be visualized as the fastest crossing a muddy area and a hard surface area where the straight line is obviously not optimal:
[[File:BrachistochroneExplained.jpg|center|thumb]]

Depending upon the resistances, the optimal point can be anywhere along the interface between the two medium.

The ancient Brachistochrone problem <ref>https://www.researchgate.net/publication/319996786_Scalability_Dilemma_and_Statistic_Multiplexed_Computing_-_A_Theory_and_Experiment</ref> models this problem in physics, a puzzle solved by Johnann Bernoulli <ref>https://en.wikipedia.org/wiki/Brachistochrone_curve</ref>. The solution is to optimize between two counter-acting forces: gravity and normal force when the gravity changes continuously.
[[File:Petite brachistochrone.gif|alt=Brachistochrone Curve|center|thumb|Brachistochrone Curve]]

For parallel computing, depending on the loads and system scheduling policies, the deliverable computing and communication speeds change dynamically. Precise measures are not possible. Finding the optimal granularity requires the program-to-program communication protocol to allow granularity changes without re-compiling the source programs. Furthermore, the load fluctuations in parallel processing also include potential component failures. The peer-to-peer ACAN protocol was designed to fit both needs: load balancing and fault tolerance.

On surface, parallel computing using P2P network will be slower than direct hop-to-hop networks, such as MPI -- the commonly used TOP500 supercomputer benchmark protocol. The problem is that parallel program built using hop-to-hop protocol such as MPI require explicit partitioning factor programmed before compilation. Changing granularity require re-programming. Tuning for the optimal granularity would be exceedingly laborious.

ACAN used the Tuple Space abstraction for automated data-parallel computing <ref>J. Shi, Statistic Multiplexed Computing System for Network-Scale Reliable High Performance Services, US PTO, #US 11,588,926 B2, granted February 21, 2023 </ref>.

Computing experiments demonstrated that optimal granularity tuning using ACAN can out-perform fixed partitioned MPI program consistently at multiple optimal points<ref>https://www.researchgate.net/publication/319996786_Scalability_Dilemma_and_Statistic_Multiplexed_Computing_-_A_Theory_and_Experiment</ref>.

[[File:OptimalGranularities.jpg|center|thumb]]
The optimal granularities (lowest points on the black-line in the above figure) share the same property as the points on the Brachistochrone curve where all points will have the same shortest traversal time regardless the starting positions on the curve [src="https://www.youtube.com/embed/skvnj67YGmw?start=1354"].

In the parallel computing experiments, the communication capacity is changing by tuning the granularity at regular intervals (smaller granularity has more frequent communication sessions thus more overheads, larger granularity has less communication sessions but larger synchronization overheads).

Similar experiments were conducted on ACAN storage performance against the Hadoop distributed file system <ref>https://www.researchgate.net/publication/285579358_AnkaCom_A_Development_and_Experiment_for_Extreme_Scale_Computing</ref>.

Programs in ACAN are "stateless" programs that can run on any computer in ACAN. Therefore the ACAN infrastructure will have no single-point failures regardless the scale. The ACAN infrastructure can be repaired or resized in real time without interrupting service. Real time granularity change is also possible without interrupting services.

A more remarkable feature of ACAN applications is the ability to deliver unbounded performance as the infrastructure expands in size with open problem sizes. It is theoretically capable to harness multiple quantum computers.

==Blockchain Protocols==
Blockchain protocol also forms P2P network. Although there are different consensus protocols, such as POW (proof of work), POS (proof of stake), POH (proof of history) and POP (proof of possession), etc., the general architecture remains the same: the protocol runs on all computers. Each computer validates transactions subject to the consensus protocol for finality. Once committed to the cryptographically linked chain, the transactions are immutable. The consensus protocol ensures double-spending does not happen.

POW protocol is not environmental friendly that consumes too much electricity for solving the mining puzzles. Other consensus protocols are more energy efficient but all suffer the same scaling challenges: expanding the network and growing the ledger will bring down the network performance gradually. The storage requirements are monotonically increasing. The network will eventually crash when all nodes are storage saturated. Dividing the chain into multiple "shards" can only postpone the eventual saturation at the expense of increased protocol complexity.

The blockchain protocols avoided the hop-to-hop protocol trap by using various "gossip" protocols. In theory, there should be no single-point failure in any blockchain network and applications. Therefore, if it is not for protocol bugs, there should never be a service downtime. The Bitcoin network demonstrated such an excellent uptime record<ref>https://buybitcoinworldwide.com/bitcoin-uptime/</ref> that no legacy infrastructures could match.

Another remarkable feature of the Bitcoin network is that its protocol programs are Open Source. Anyone can download and manipulate it and turn it to attack the network. There has been no successful Bitcoin network attacks since its 2009 launch.

It is also interesting to observe that the blockchain protocols are silent on transaction re-transmission discipline. The blockchain wallets are responsible to check their own transactions' status and retransmit if necessary. Since double-spending is not possible, retransmitting a transaction is a trivial matter and it would most likely find a different route for transaction approval.

However, scalability remains the common challenge to all blockchain protocols. For POW consensus chains, the increasing energy consumption caused serious sustainability concerns. Since the cryptographic proved ledgers are immutable, for POS chains, although more than 99% energy consumption reduction can be achieved, the blockchain network's scalability is still challenged, since the chains will have to shutdown when all nodes storage are saturated.

It is evident that all blockchains should be infinitely scalable. This means that expanding the network (adding nodes) should increase the network's performance, reliability and security. This is the motivation for the SMC Blockchain Protocol.

== SMC Blockchain Protocol ==
SMC blockchain protocol aims to solve the scalability challenge by enabling automated parallel processing while enhancing network security and reliability at the same time. The ACAN concept is a perfect fit for this case. ACAN enables automated SMC by forcing the transaction validation processes to form SIMD, MIMD and pipeline clusters in real time.

Unlike other chains, SMC Blockchain Protocol only maintains (R > 1) copies of the ledger on randomly selected nodes. This enables the overall network storage capacity to grow indefinitely by adding more nodes. The value of R constrains the transaction replication overheads to a constant thus accelerating transaction processing throughput by adding nodes. The actual R value can be determined experimentally without stopping service.

The SMC Blockchain network (TOIchain) supports regular, "staking" and "seed" nodes. A regular node is similar to a "light node" in Bitcoin that only receives transactions and forwards them to "staking" nodes. Unlike a Bitcoin "light node", a regular TOI node can optionally store validated blocks and be paid (need a unique wallet address) for the storage and accesses. A "staking" node is a regular node uniquely associated with another wallet address by a "staking contract", such as "50 TOINs for 3 months starting now". The staking contracts are used by randomly selected "seed" nodes to build random transaction validation committees (Prove of Stake consensus protocol).

A "seed" node is TOI Foundation supported service. They serve as the DNS for TOIchain and have all features as a "staking" node where the "staking contract" and wallet address are owned by TOI Foundation. The TOIchain operates on EPOCHs as heartbeats for the network. Each EPOCH corresponds to a randomly selected "validation committee" of "staking" nodes. A randomly selected "seed" node set decides the formation of committee.

Each "validation committee" can have up to 128 validators. Each validator validates local transactions in parallel against the current best chain state. The committee assembles a block of partially validated transactions for committee-wide validation. A majority agreement will decide the fully validated transactions into the new block. The block is considered "confirmed" but not "finalized".

The new block must be validated against the EPOCH-id -1 block before it is "finalized". This step is skipped for the genesis block. The committees must wait until the EPOCH-id -1 block becomes the chain tip. Thus, multiple validation committees form a virtual pipeline at runtime. Finalized blocks match generated EPOCHs. Transactions fail in any stage are removed from the block. There maybe empty blocks where all transactions fail or the network is idling.

Transactions may be replicated before validation to improve the chance of being included into a block by paying more fees. The redundant transactions will fail except for the first one.

When the network has no "staking" nodes, the "seed" nodes become "staking" nodes to keep the network operational. The TOI Foundation receives the transaction fees and validation rewards.

The TOI Foundation maintains the "seed" nodes and the overall network security and safety via automatic network monitoring and maintenance scripts.

== SMC POS Consensus ==
SMC POS consensus protocol randomly selects staking validators without staking pools to avoid 51% attacks. SMC POS protocol also has an adjustable replication factor that the network ledger has a fixed replication factor that can be tuned on demand without service interruptions. Therefore, adding nodes, the SMC POS consensus protocol can deliver:

# Byzantine failure resistance
# Fault tolerance
# Program tamper resistance
# Centralization avoidance
# Incrementally better performance, security and reliability

More nodes in the network expands the network storage capacity without increasing replication overheads. More nodes facilitates longer pipelines for better performances and better randomness for security. Higher R value improves service reliability.

SMC blockchain protocol is also silent on transaction retransmission discipline. Since it is impossible to "double spend" under SMC protocol, transaction retransmission will enable different approval routes without double-spend risks (multiplexing). This ensures seamless integration with legacy blockchain wallets and infrastructures.

== Summary ==
SMC blockchain protocol is the only statistic multiplexed blockchain protocol to date. The SMC technology development history links the blockchain protocol development to stateless HPC (high performance computing) developments. This is the only known technology that can offer decentralized processing for centralized controls, which is the perfect gateway to integrate web2.0 applications for web3.0 infrastructures.

== References: ==
<references />

SMC

2024-05-30T19:34:26Z

Justin: /* SMC Blockchain Protocol */

== Introduction ==

SMC stands for Statistic Multiplexed Computing and Communication. The idea was inspired by von Neumann's 1952 paper on probabilistic logics and synthesis of reliable organisms using unreliable components <ref>https://static.ias.edu/pitp/archive/2012files/Probabilistic_Logics.pdf</ref>. Building fault tolerant mission critical system was the triggering use case.

Modern computer applications must rely on networking services. Every networked application forms its own infrastructure consisting of network, processing, storage and software components. A data center or cloud service can duplex multiple applications on the same hardware. The definition of infrastructure remains with each application.

The challenge of building fault tolerant mission critical application is deciding how the programs should communicate with other programs and devices.

Since every hardware component has finite service life, in theory, mission critical software programs must be completely decoupled from hardware components, such as networking, processing, storage, sensors and other devices. This decoupling affords hardware management freedom without changing programs.

This simple requirement seems very difficult to satisfy in practice.

==Canary In The Coal Mine==
The TCP/IP protocol was an experimental protocol for connecting arbitrary two computers reliably in the world-wide network like the "canary in a coal mine". The OSI model <ref>https://en.wikipedia.org/wiki/OSI_model</ref> is a conceptual model from the ISO (International Organization for Standardization) that provides "a common basis for the coordination of standards development for the purpose of systems interconnection <ref>https://www.iso.org/standard/20269.html</ref>. Today, its 7-layer model is widely taught in universities and technology schools.

For every connection-oriented socket circuit, all commercial implementations guarantees "order-preserved lossless data communication", packet losses, duplicates and errors are automatically corrected in the lower layer protocols. It seems perfectly reasonable to deploy this "hop-to-hop" connected-oriented TCP sockets for mission critical applications.

Unfortunately, the fine-prints in the OSI model specification have not caught any attention. The "order-preserved lossless data communication" is guaranteed only if both the sender and receiver are 100% reliable. If the sender or the receiver can crash arbitrarily, then reliable communication is impossible <ref>https://groups.csail.mit.edu/tds/papers/Lynch/jacm93.pdf</ref>. In practice, we call the TCP/IP protocol the "best effort" reliable protocol for all nodes are indeed try their best to forward packets and repair errors and duplicates. Building mission critical application using these protocols is inappropriate.

The problem is that it is impossible to eliminate single-point failures. The "canary" worked well only for communication applications where data losses and service downtimes can be tolerated to some extent. For mission critical applications, such as banking, trading, air/sea/land navigation, service crashes can cause irreparable damages and loss of human lives.

Even for banking applications, arbitrary transaction losses cannot be eliminated completely. Banks resort to legal measures to compensate verified customer losses. There are unclaimed funds to be handled by the banks.

In business, the IT professionals simply try to minimize "opportunity costs". Solving the infrastructure scaling problem seems out of reach for most people.

==Fruits of Poisonous Tree==
The "hop-to-hop" protocol is the DNA of existing enterprise system program paradigms. These include RPC (remote procedure call), MPI (message passing interface), RMI (remote method invocation), distributed share-memory and many others. These are the only means to communicate and retrieve data from a remote computer.

Applications built using these protocols form infrastructures that have many single-point failures. Every such point failure can bring down the entire enterprise.

The "Achilles Heel" of the legacy enterprise programming paradigms is the lack of "re-transmission discipline". The hop-to-hop protocols provide false hope of data communication reliability. Programmers are at a loss when dealing with timeout events: do we retransmit or not retransmit? If not, data would be lost. If we do, how to handle if duplicates? what is the probability of success from the last timeout?
[[File:Achilles-heel.png|center|thumb|Achilles-heel]]

To eliminate infrastructure single-point failures requires complete program and data decoupling from hardware components -- a programming paradigm shift from the hop-to-hop communication paradigms.

==Active Content Addressable Networking (ACAN)==
Content addressable networks are peer-to-peer(P2P) networks. There are many proposed contend addressable networks (CAN) <ref>https://en.wikipedia.org/wiki/Content-addressable_network</ref>. These include distributed hash table (DHT)<ref>https://en.wikipedia.org/wiki/Distributed_hash_table</ref>, and projects: Chord<ref>https://en.wikipedia.org/wiki/Chord_(peer-to-peer)</ref>, Pastry<ref>https://en.wikipedia.org/wiki/Pastry_(DHT)</ref> and Tapestry<ref>https://en.wikipedia.org/wiki/Tapestry_(DHT)</ref>. These networks focused on information retrieval efficiency.

We need information retrieval efficiency and the freedom of multiplexing hardware components in real time. We call this ACAN (Active Content Addressable Networking).

The idea of ACAN is to enable automated parallel processing based on application's data retrieval patterns without explicitly building parallel SIMD, MIMD and pipeline clusters. This was inspired by the failures from the early-day dataflow machine research <ref>https://en.wikipedia.org/wiki/Dataflow</ref>. The earlier dataflow computer research failed to recognize the importance of parallel processing granularity<ref>https://en.wikipedia.org/wiki/Dataflow_architecture</ref>. The meticulously designed multiprocessor architectures failed to compete against simpler single processors.

The parallel processing granularity optimization problem needs to balance the disparity of processing and communication capabilities in an infrastructure. Conventional wisdom considers communication overheads are the main challenge in parallel computing. In reality, synchronization overheads are the main problem, unless computing speeds are perfectly matched with the communication latencies, optimal parallel performance is not possible. This situation may be visualized as the fastest crossing a muddy area and a hard surface area where the straight line is obviously not optimal:
[[File:BrachistochroneExplained.jpg|center|thumb]]

Depending upon the resistances, the optimal point can be anywhere along the interface between the two medium.

The ancient Brachistochrone problem <ref>https://www.researchgate.net/publication/319996786_Scalability_Dilemma_and_Statistic_Multiplexed_Computing_-_A_Theory_and_Experiment</ref> models this problem in physics, a puzzle solved by Johnann Bernoulli <ref>https://en.wikipedia.org/wiki/Brachistochrone_curve</ref>. The solution is to optimize between two counter-acting forces: gravity and normal force when the gravity changes continuously.
[[File:Petite brachistochrone.gif|alt=Brachistochrone Curve|center|thumb|Brachistochrone Curve]]

For parallel computing, depending on the loads and system scheduling policies, the deliverable computing and communication speeds change dynamically. Precise measures are not possible. Finding the optimal granularity requires the program-to-program communication protocol to allow granularity changes without re-compiling the source programs. Furthermore, the load fluctuations in parallel processing also include potential component failures. The peer-to-peer ACAN protocol was designed to fit both needs: load balancing and fault tolerance.

On surface, parallel computing using P2P network will be slower than direct hop-to-hop networks, such as MPI -- the commonly used TOP500 supercomputer benchmark protocol. The problem is that parallel program built using hop-to-hop protocol such as MPI require explicit partitioning factor programmed before compilation. Changing granularity require re-programming. Tuning for the optimal granularity would be exceedingly laborious.

ACAN used the Tuple Space abstraction for automated data-parallel computing <ref>J. Shi, Statistic Multiplexed Computing System for Network-Scale Reliable High Performance Services, US PTO, #US 11,588,926 B2, granted February 21, 2023 </ref>.

Computing experiments demonstrated that optimal granularity tuning using ACAN can out-perform fixed partitioned MPI program consistently at multiple optimal points<ref>https://www.researchgate.net/publication/319996786_Scalability_Dilemma_and_Statistic_Multiplexed_Computing_-_A_Theory_and_Experiment</ref>.

[[File:OptimalGranularities.jpg|center|thumb]]
The optimal granularities (lowest points on the black-line in the above figure) share the same property as the points on the Brachistochrone curve where all points will have the same shortest traversal time regardless the starting positions on the curve [src="https://www.youtube.com/embed/skvnj67YGmw?start=1354"].

In the parallel computing experiments, the communication capacity is changing by tuning the granularity at regular intervals (smaller granularity has more frequent communication sessions thus more overheads, larger granularity has less communication sessions but larger synchronization overheads).

Similar experiments were conducted on ACAN storage performance against the Hadoop distributed file system <ref>https://www.researchgate.net/publication/285579358_AnkaCom_A_Development_and_Experiment_for_Extreme_Scale_Computing</ref>.

Programs in ACAN are "stateless" programs that can run on any computer in ACAN. Therefore the ACAN infrastructure will have no single-point failures regardless the scale. The ACAN infrastructure can be repaired or resized in real time without interrupting service. Real time granularity change is also possible without interrupting services.

A more remarkable feature of ACAN applications is the ability to deliver unbounded performance as the infrastructure expands in size with open problem sizes. It is theoretically capable to harness multiple quantum computers.

==Blockchain Protocols==
Blockchain protocol also forms P2P network. Although there are different consensus protocols, such as POW (proof of work), POS (proof of stake), POH (proof of history) and POP (proof of possession), etc., the general architecture remains the same: the protocol runs on all computers. Each computer validates transactions subject to the consensus protocol for finality. Once committed to the cryptographically linked chain, the transactions are immutable. The consensus protocol ensures double-spending does not happen.

POW protocol is not environmental friendly that consumes too much electricity for solving the mining puzzles. Other consensus protocols are more energy efficient but all suffer the same scaling challenges: expanding the network and growing the ledger will bring down the network performance gradually. The storage requirements are monotonically increasing. The network will eventually crash when all nodes are storage saturated. Dividing the chain into multiple "shards" can only postpone the eventual saturation at the expense of increased protocol complexity.

The blockchain protocols avoided the hop-to-hop protocol trap by using various "gossip" protocols. In theory, there should be no single-point failure in any blockchain network and applications. Therefore, if it is not for protocol bugs, there should never be a service downtime. The Bitcoin network demonstrated such an excellent uptime record<ref>https://buybitcoinworldwide.com/bitcoin-uptime/</ref> that no legacy infrastructures could match.

Another remarkable feature of the Bitcoin network is that its protocol programs are Open Source. Anyone can download and manipulate it and turn it to attack the network. There has been no successful Bitcoin network attacks since its 2009 launch.

It is also interesting to observe that the blockchain protocols are silent on transaction re-transmission discipline. The blockchain wallets are responsible to check their own transactions' status and retransmit if necessary. Since double-spending is not possible, retransmitting a transaction is a trivial matter and it would most likely find a different route for transaction approval.

However, scalability remains the common challenge to all blockchain protocols. For POW consensus chains, the increasing energy consumption caused serious sustainability concerns. Since the cryptographic proved ledgers are immutable, for POS chains, although more than 99% energy consumption reduction can be achieved, the blockchain network's scalability is still challenged, since the chains will have to shutdown when all nodes storage are saturated.

It is evident that all blockchains should be infinitely scalable. This means that expanding the network (adding nodes) should increase the network's performance, reliability and security. This is the motivation for the SMC Blockchain Protocol.

== SMC Blockchain Protocol ==
SMC blockchain protocol aims to solve the scalability challenge by enabling automated parallel processing while enhancing network security and reliability at the same time. The ACAN concept is a perfect fit for this case. ACAN enables automated SMC by forcing the transaction validation processes to form SIMD, MIMD and pipeline clusters in real time.

Unlike other chains, SMC Blockchain Protocol only maintains (R > 1) copies of the ledger on randomly selected nodes. This enables the overall network storage capacity to grow indefinitely by adding more nodes. The value of R constrains the transaction replication overheads to a constant thus accelerating transaction processing throughput by adding nodes. The actual R value can be determined experimentally without stopping service.

The SMC Blockchain network supports regular, "staking" and "seed" nodes. A regular node is similar to a "light node" in Bitcoin that only receives transactions and forwards them to "staking" nodes. A regular node can also store validated blocks and be paid for the storage and accesses. A "staking" node is uniquely associated with a wallet address with a staking contract, such as "50 TOINs for 3 months starting now". The staking contracts are used by randomly selected "seed" nodes to build random transaction validation committees (Prove of Stake consensus protocol). Also unlike Bitcoin and other chains, transactions are not replicated before validation.

The TOI Foundation maintains the "seed" nodes that are responsible for generating network heartbeats: EPOCH.

== SMC POS Consensus ==
SMC POS consensus will randomly select staking validators without staking pools. SMC POS protocol also has an adjustable replication factor that the network ledger has a fixed replication factor that can be tuned on demand without service interruptions. Therefore, SMC POS consensus protocol can deliver:

# Byzantine failure resistance
# Fault tolerance
# Program tamper resistance
# Centralization avoidance
# Incrementally better performance, security and reliability

More nodes in the network expands the network storage capacity without adding extra redundancy. More nodes facilitates longer pipelines for better performances.

SMC blockchain protocol is also silent on transaction retransmission discipline. Transaction retransmission will enable different approval routes without double-spend risks. This ensures seamless integration with legacy blockchain wallets.

== Summary ==
SMC blockchain protocol is the only statistic multiplexed blockchain protocol to date. The SMC technology development history links the blockchain protocol development to stateless HPC (high performance computing) developments. This is the only known technology that can offer decentralized processing for centralized controls, which is the perfect gateway to integrate web2.0 applications for web3.0 infrastructures.

== References: ==
<references />

SMC

2024-05-30T18:59:29Z

Justin: /* Blockchain Protocols */

== Introduction ==

SMC stands for Statistic Multiplexed Computing and Communication. The idea was inspired by von Neumann's 1952 paper on probabilistic logics and synthesis of reliable organisms using unreliable components <ref>https://static.ias.edu/pitp/archive/2012files/Probabilistic_Logics.pdf</ref>. Building fault tolerant mission critical system was the triggering use case.

Modern computer applications must rely on networking services. Every networked application forms its own infrastructure consisting of network, processing, storage and software components. A data center or cloud service can duplex multiple applications on the same hardware. The definition of infrastructure remains with each application.

The challenge of building fault tolerant mission critical application is deciding how the programs should communicate with other programs and devices.

Since every hardware component has finite service life, in theory, mission critical software programs must be completely decoupled from hardware components, such as networking, processing, storage, sensors and other devices. This decoupling affords hardware management freedom without changing programs.

This simple requirement seems very difficult to satisfy in practice.

==Canary In The Coal Mine==
The TCP/IP protocol was an experimental protocol for connecting arbitrary two computers reliably in the world-wide network like the "canary in a coal mine". The OSI model <ref>https://en.wikipedia.org/wiki/OSI_model</ref> is a conceptual model from the ISO (International Organization for Standardization) that provides "a common basis for the coordination of standards development for the purpose of systems interconnection <ref>https://www.iso.org/standard/20269.html</ref>. Today, its 7-layer model is widely taught in universities and technology schools.

For every connection-oriented socket circuit, all commercial implementations guarantees "order-preserved lossless data communication", packet losses, duplicates and errors are automatically corrected in the lower layer protocols. It seems perfectly reasonable to deploy this "hop-to-hop" connected-oriented TCP sockets for mission critical applications.

Unfortunately, the fine-prints in the OSI model specification have not caught any attention. The "order-preserved lossless data communication" is guaranteed only if both the sender and receiver are 100% reliable. If the sender or the receiver can crash arbitrarily, then reliable communication is impossible <ref>https://groups.csail.mit.edu/tds/papers/Lynch/jacm93.pdf</ref>. In practice, we call the TCP/IP protocol the "best effort" reliable protocol for all nodes are indeed try their best to forward packets and repair errors and duplicates. Building mission critical application using these protocols is inappropriate.

The problem is that it is impossible to eliminate single-point failures. The "canary" worked well only for communication applications where data losses and service downtimes can be tolerated to some extent. For mission critical applications, such as banking, trading, air/sea/land navigation, service crashes can cause irreparable damages and loss of human lives.

Even for banking applications, arbitrary transaction losses cannot be eliminated completely. Banks resort to legal measures to compensate verified customer losses. There are unclaimed funds to be handled by the banks.

In business, the IT professionals simply try to minimize "opportunity costs". Solving the infrastructure scaling problem seems out of reach for most people.

==Fruits of Poisonous Tree==
The "hop-to-hop" protocol is the DNA of existing enterprise system program paradigms. These include RPC (remote procedure call), MPI (message passing interface), RMI (remote method invocation), distributed share-memory and many others. These are the only means to communicate and retrieve data from a remote computer.

Applications built using these protocols form infrastructures that have many single-point failures. Every such point failure can bring down the entire enterprise.

The "Achilles Heel" of the legacy enterprise programming paradigms is the lack of "re-transmission discipline". The hop-to-hop protocols provide false hope of data communication reliability. Programmers are at a loss when dealing with timeout events: do we retransmit or not retransmit? If not, data would be lost. If we do, how to handle if duplicates? what is the probability of success from the last timeout?
[[File:Achilles-heel.png|center|thumb|Achilles-heel]]

To eliminate infrastructure single-point failures requires complete program and data decoupling from hardware components -- a programming paradigm shift from the hop-to-hop communication paradigms.

==Active Content Addressable Networking (ACAN)==
Content addressable networks are peer-to-peer(P2P) networks. There are many proposed contend addressable networks (CAN) <ref>https://en.wikipedia.org/wiki/Content-addressable_network</ref>. These include distributed hash table (DHT)<ref>https://en.wikipedia.org/wiki/Distributed_hash_table</ref>, and projects: Chord<ref>https://en.wikipedia.org/wiki/Chord_(peer-to-peer)</ref>, Pastry<ref>https://en.wikipedia.org/wiki/Pastry_(DHT)</ref> and Tapestry<ref>https://en.wikipedia.org/wiki/Tapestry_(DHT)</ref>. These networks focused on information retrieval efficiency.

We need information retrieval efficiency and the freedom of multiplexing hardware components in real time. We call this ACAN (Active Content Addressable Networking).

The idea of ACAN is to enable automated parallel processing based on application's data retrieval patterns without explicitly building parallel SIMD, MIMD and pipeline clusters. This was inspired by the failures from the early-day dataflow machine research <ref>https://en.wikipedia.org/wiki/Dataflow</ref>. The earlier dataflow computer research failed to recognize the importance of parallel processing granularity<ref>https://en.wikipedia.org/wiki/Dataflow_architecture</ref>. The meticulously designed multiprocessor architectures failed to compete against simpler single processors.

The parallel processing granularity optimization problem needs to balance the disparity of processing and communication capabilities in an infrastructure. Conventional wisdom considers communication overheads are the main challenge in parallel computing. In reality, synchronization overheads are the main problem, unless computing speeds are perfectly matched with the communication latencies, optimal parallel performance is not possible. This situation may be visualized as the fastest crossing a muddy area and a hard surface area where the straight line is obviously not optimal:
[[File:BrachistochroneExplained.jpg|center|thumb]]

Depending upon the resistances, the optimal point can be anywhere along the interface between the two medium.

The ancient Brachistochrone problem <ref>https://www.researchgate.net/publication/319996786_Scalability_Dilemma_and_Statistic_Multiplexed_Computing_-_A_Theory_and_Experiment</ref> models this problem in physics, a puzzle solved by Johnann Bernoulli <ref>https://en.wikipedia.org/wiki/Brachistochrone_curve</ref>. The solution is to optimize between two counter-acting forces: gravity and normal force when the gravity changes continuously.
[[File:Petite brachistochrone.gif|alt=Brachistochrone Curve|center|thumb|Brachistochrone Curve]]

For parallel computing, depending on the loads and system scheduling policies, the deliverable computing and communication speeds change dynamically. Precise measures are not possible. Finding the optimal granularity requires the program-to-program communication protocol to allow granularity changes without re-compiling the source programs. Furthermore, the load fluctuations in parallel processing also include potential component failures. The peer-to-peer ACAN protocol was designed to fit both needs: load balancing and fault tolerance.

On surface, parallel computing using P2P network will be slower than direct hop-to-hop networks, such as MPI -- the commonly used TOP500 supercomputer benchmark protocol. The problem is that parallel program built using hop-to-hop protocol such as MPI require explicit partitioning factor programmed before compilation. Changing granularity require re-programming. Tuning for the optimal granularity would be exceedingly laborious.

ACAN used the Tuple Space abstraction for automated data-parallel computing <ref>J. Shi, Statistic Multiplexed Computing System for Network-Scale Reliable High Performance Services, US PTO, #US 11,588,926 B2, granted February 21, 2023 </ref>.

Computing experiments demonstrated that optimal granularity tuning using ACAN can out-perform fixed partitioned MPI program consistently at multiple optimal points<ref>https://www.researchgate.net/publication/319996786_Scalability_Dilemma_and_Statistic_Multiplexed_Computing_-_A_Theory_and_Experiment</ref>.

[[File:OptimalGranularities.jpg|center|thumb]]
The optimal granularities (lowest points on the black-line in the above figure) share the same property as the points on the Brachistochrone curve where all points will have the same shortest traversal time regardless the starting positions on the curve [src="https://www.youtube.com/embed/skvnj67YGmw?start=1354"].

In the parallel computing experiments, the communication capacity is changing by tuning the granularity at regular intervals (smaller granularity has more frequent communication sessions thus more overheads, larger granularity has less communication sessions but larger synchronization overheads).

Similar experiments were conducted on ACAN storage performance against the Hadoop distributed file system <ref>https://www.researchgate.net/publication/285579358_AnkaCom_A_Development_and_Experiment_for_Extreme_Scale_Computing</ref>.

Programs in ACAN are "stateless" programs that can run on any computer in ACAN. Therefore the ACAN infrastructure will have no single-point failures regardless the scale. The ACAN infrastructure can be repaired or resized in real time without interrupting service. Real time granularity change is also possible without interrupting services.

A more remarkable feature of ACAN applications is the ability to deliver unbounded performance as the infrastructure expands in size with open problem sizes. It is theoretically capable to harness multiple quantum computers.

==Blockchain Protocols==
Blockchain protocol also forms P2P network. Although there are different consensus protocols, such as POW (proof of work), POS (proof of stake), POH (proof of history) and POP (proof of possession), etc., the general architecture remains the same: the protocol runs on all computers. Each computer validates transactions subject to the consensus protocol for finality. Once committed to the cryptographically linked chain, the transactions are immutable. The consensus protocol ensures double-spending does not happen.

POW protocol is not environmental friendly that consumes too much electricity for solving the mining puzzles. Other consensus protocols are more energy efficient but all suffer the same scaling challenges: expanding the network and growing the ledger will bring down the network performance gradually. The storage requirements are monotonically increasing. The network will eventually crash when all nodes are storage saturated. Dividing the chain into multiple "shards" can only postpone the eventual saturation at the expense of increased protocol complexity.

The blockchain protocols avoided the hop-to-hop protocol trap by using various "gossip" protocols. In theory, there should be no single-point failure in any blockchain network and applications. Therefore, if it is not for protocol bugs, there should never be a service downtime. The Bitcoin network demonstrated such an excellent uptime record<ref>https://buybitcoinworldwide.com/bitcoin-uptime/</ref> that no legacy infrastructures could match.

Another remarkable feature of the Bitcoin network is that its protocol programs are Open Source. Anyone can download and manipulate it and turn it to attack the network. There has been no successful Bitcoin network attacks since its 2009 launch.

It is also interesting to observe that the blockchain protocols are silent on transaction re-transmission discipline. The blockchain wallets are responsible to check their own transactions' status and retransmit if necessary. Since double-spending is not possible, retransmitting a transaction is a trivial matter and it would most likely find a different route for transaction approval.

However, scalability remains the common challenge to all blockchain protocols. For POW consensus chains, the increasing energy consumption caused serious sustainability concerns. Since the cryptographic proved ledgers are immutable, for POS chains, although more than 99% energy consumption reduction can be achieved, the blockchain network's scalability is still challenged, since the chains will have to shutdown when all nodes storage are saturated.

It is evident that all blockchains should be infinitely scalable. This means that expanding the network (adding nodes) should increase the network's performance, reliability and security. This is the motivation for the SMC Blockchain Protocol.

== SMC Blockchain Protocol ==
SMC blockchain protocol aims to solve the scalability challenge by enabling automated parallel processing without negatively impacting the network security and reliability. The ACAN concept is a perfect fit for this case. ACAN enables automated SMC by forcing the transaction validation blocks to form SIMD, MIMD and pipeline clusters in real time.

== SMC POS Consensus ==
SMC POS consensus will randomly select staking validators without staking pools. SMC POS protocol also has an adjustable replication factor that the network ledger has a fixed replication factor that can be tuned on demand without service interruptions. Therefore, SMC POS consensus protocol can deliver:

# Byzantine failure resistance
# Fault tolerance
# Program tamper resistance
# Centralization avoidance
# Incrementally better performance, security and reliability

More nodes in the network expands the network storage capacity without adding extra redundancy. More nodes facilitates longer pipelines for better performances.

SMC blockchain protocol is also silent on transaction retransmission discipline. Transaction retransmission will enable different approval routes without double-spend risks. This ensures seamless integration with legacy blockchain wallets.

== Summary ==
SMC blockchain protocol is the only statistic multiplexed blockchain protocol to date. The SMC technology development history links the blockchain protocol development to stateless HPC (high performance computing) developments. This is the only known technology that can offer decentralized processing for centralized controls, which is the perfect gateway to integrate web2.0 applications for web3.0 infrastructures.

== References: ==
<references />

SMC

2024-05-30T18:58:29Z

Justin: /* Blockchain Protocols */

== Introduction ==

SMC stands for Statistic Multiplexed Computing and Communication. The idea was inspired by von Neumann's 1952 paper on probabilistic logics and synthesis of reliable organisms using unreliable components <ref>https://static.ias.edu/pitp/archive/2012files/Probabilistic_Logics.pdf</ref>. Building fault tolerant mission critical system was the triggering use case.

Modern computer applications must rely on networking services. Every networked application forms its own infrastructure consisting of network, processing, storage and software components. A data center or cloud service can duplex multiple applications on the same hardware. The definition of infrastructure remains with each application.

The challenge of building fault tolerant mission critical application is deciding how the programs should communicate with other programs and devices.

Since every hardware component has finite service life, in theory, mission critical software programs must be completely decoupled from hardware components, such as networking, processing, storage, sensors and other devices. This decoupling affords hardware management freedom without changing programs.

This simple requirement seems very difficult to satisfy in practice.

==Canary In The Coal Mine==
The TCP/IP protocol was an experimental protocol for connecting arbitrary two computers reliably in the world-wide network like the "canary in a coal mine". The OSI model <ref>https://en.wikipedia.org/wiki/OSI_model</ref> is a conceptual model from the ISO (International Organization for Standardization) that provides "a common basis for the coordination of standards development for the purpose of systems interconnection <ref>https://www.iso.org/standard/20269.html</ref>. Today, its 7-layer model is widely taught in universities and technology schools.

For every connection-oriented socket circuit, all commercial implementations guarantees "order-preserved lossless data communication", packet losses, duplicates and errors are automatically corrected in the lower layer protocols. It seems perfectly reasonable to deploy this "hop-to-hop" connected-oriented TCP sockets for mission critical applications.

Unfortunately, the fine-prints in the OSI model specification have not caught any attention. The "order-preserved lossless data communication" is guaranteed only if both the sender and receiver are 100% reliable. If the sender or the receiver can crash arbitrarily, then reliable communication is impossible <ref>https://groups.csail.mit.edu/tds/papers/Lynch/jacm93.pdf</ref>. In practice, we call the TCP/IP protocol the "best effort" reliable protocol for all nodes are indeed try their best to forward packets and repair errors and duplicates. Building mission critical application using these protocols is inappropriate.

The problem is that it is impossible to eliminate single-point failures. The "canary" worked well only for communication applications where data losses and service downtimes can be tolerated to some extent. For mission critical applications, such as banking, trading, air/sea/land navigation, service crashes can cause irreparable damages and loss of human lives.

Even for banking applications, arbitrary transaction losses cannot be eliminated completely. Banks resort to legal measures to compensate verified customer losses. There are unclaimed funds to be handled by the banks.

In business, the IT professionals simply try to minimize "opportunity costs". Solving the infrastructure scaling problem seems out of reach for most people.

==Fruits of Poisonous Tree==
The "hop-to-hop" protocol is the DNA of existing enterprise system program paradigms. These include RPC (remote procedure call), MPI (message passing interface), RMI (remote method invocation), distributed share-memory and many others. These are the only means to communicate and retrieve data from a remote computer.

Applications built using these protocols form infrastructures that have many single-point failures. Every such point failure can bring down the entire enterprise.

The "Achilles Heel" of the legacy enterprise programming paradigms is the lack of "re-transmission discipline". The hop-to-hop protocols provide false hope of data communication reliability. Programmers are at a loss when dealing with timeout events: do we retransmit or not retransmit? If not, data would be lost. If we do, how to handle if duplicates? what is the probability of success from the last timeout?
[[File:Achilles-heel.png|center|thumb|Achilles-heel]]

To eliminate infrastructure single-point failures requires complete program and data decoupling from hardware components -- a programming paradigm shift from the hop-to-hop communication paradigms.

==Active Content Addressable Networking (ACAN)==
Content addressable networks are peer-to-peer(P2P) networks. There are many proposed contend addressable networks (CAN) <ref>https://en.wikipedia.org/wiki/Content-addressable_network</ref>. These include distributed hash table (DHT)<ref>https://en.wikipedia.org/wiki/Distributed_hash_table</ref>, and projects: Chord<ref>https://en.wikipedia.org/wiki/Chord_(peer-to-peer)</ref>, Pastry<ref>https://en.wikipedia.org/wiki/Pastry_(DHT)</ref> and Tapestry<ref>https://en.wikipedia.org/wiki/Tapestry_(DHT)</ref>. These networks focused on information retrieval efficiency.

We need information retrieval efficiency and the freedom of multiplexing hardware components in real time. We call this ACAN (Active Content Addressable Networking).

The idea of ACAN is to enable automated parallel processing based on application's data retrieval patterns without explicitly building parallel SIMD, MIMD and pipeline clusters. This was inspired by the failures from the early-day dataflow machine research <ref>https://en.wikipedia.org/wiki/Dataflow</ref>. The earlier dataflow computer research failed to recognize the importance of parallel processing granularity<ref>https://en.wikipedia.org/wiki/Dataflow_architecture</ref>. The meticulously designed multiprocessor architectures failed to compete against simpler single processors.

The parallel processing granularity optimization problem needs to balance the disparity of processing and communication capabilities in an infrastructure. Conventional wisdom considers communication overheads are the main challenge in parallel computing. In reality, synchronization overheads are the main problem, unless computing speeds are perfectly matched with the communication latencies, optimal parallel performance is not possible. This situation may be visualized as the fastest crossing a muddy area and a hard surface area where the straight line is obviously not optimal:
[[File:BrachistochroneExplained.jpg|center|thumb]]

Depending upon the resistances, the optimal point can be anywhere along the interface between the two medium.

The ancient Brachistochrone problem <ref>https://www.researchgate.net/publication/319996786_Scalability_Dilemma_and_Statistic_Multiplexed_Computing_-_A_Theory_and_Experiment</ref> models this problem in physics, a puzzle solved by Johnann Bernoulli <ref>https://en.wikipedia.org/wiki/Brachistochrone_curve</ref>. The solution is to optimize between two counter-acting forces: gravity and normal force when the gravity changes continuously.
[[File:Petite brachistochrone.gif|alt=Brachistochrone Curve|center|thumb|Brachistochrone Curve]]

For parallel computing, depending on the loads and system scheduling policies, the deliverable computing and communication speeds change dynamically. Precise measures are not possible. Finding the optimal granularity requires the program-to-program communication protocol to allow granularity changes without re-compiling the source programs. Furthermore, the load fluctuations in parallel processing also include potential component failures. The peer-to-peer ACAN protocol was designed to fit both needs: load balancing and fault tolerance.

On surface, parallel computing using P2P network will be slower than direct hop-to-hop networks, such as MPI -- the commonly used TOP500 supercomputer benchmark protocol. The problem is that parallel program built using hop-to-hop protocol such as MPI require explicit partitioning factor programmed before compilation. Changing granularity require re-programming. Tuning for the optimal granularity would be exceedingly laborious.

ACAN used the Tuple Space abstraction for automated data-parallel computing <ref>J. Shi, Statistic Multiplexed Computing System for Network-Scale Reliable High Performance Services, US PTO, #US 11,588,926 B2, granted February 21, 2023 </ref>.

Computing experiments demonstrated that optimal granularity tuning using ACAN can out-perform fixed partitioned MPI program consistently at multiple optimal points<ref>https://www.researchgate.net/publication/319996786_Scalability_Dilemma_and_Statistic_Multiplexed_Computing_-_A_Theory_and_Experiment</ref>.

[[File:OptimalGranularities.jpg|center|thumb]]
The optimal granularities (lowest points on the black-line in the above figure) share the same property as the points on the Brachistochrone curve where all points will have the same shortest traversal time regardless the starting positions on the curve [src="https://www.youtube.com/embed/skvnj67YGmw?start=1354"].

In the parallel computing experiments, the communication capacity is changing by tuning the granularity at regular intervals (smaller granularity has more frequent communication sessions thus more overheads, larger granularity has less communication sessions but larger synchronization overheads).

Similar experiments were conducted on ACAN storage performance against the Hadoop distributed file system <ref>https://www.researchgate.net/publication/285579358_AnkaCom_A_Development_and_Experiment_for_Extreme_Scale_Computing</ref>.

Programs in ACAN are "stateless" programs that can run on any computer in ACAN. Therefore the ACAN infrastructure will have no single-point failures regardless the scale. The ACAN infrastructure can be repaired or resized in real time without interrupting service. Real time granularity change is also possible without interrupting services.

A more remarkable feature of ACAN applications is the ability to deliver unbounded performance as the infrastructure expands in size with open problem sizes. It is theoretically capable to harness multiple quantum computers.

==Blockchain Protocols==
Blockchain protocol also forms P2P network. Although there are different consensus protocols, such as POW (proof of work), POS (proof of stake), POH (proof of history) and POP (proof of possession), etc., the general architecture remains the same: the protocol runs on all computers. Each computer validates transactions subject to the consensus protocol for finality. Once committed to the cryptographically linked chain, the transactions are immutable. The consensus protocol ensures double-spending does not happen.

POW protocol is not environmental friendly that consumes too much electricity for solving the mining puzzles. Other consensus protocols are more energy efficient but all suffer the same scaling challenges: expanding the network and growing the ledger will bring down the network performance gradually. The storage requirements are monotonically increasing. The network will eventually crash when all nodes are storage saturated. Dividing the chain into multiple "shards" can only postpone the eventual saturation at the expense of increased protocol complexity.

The blockchain protocols avoided the hop-to-hop protocol trap by using various "gossip" protocols. In theory, there should be no single-point failure in any blockchain network and applications. Therefore, if it is not for protocol bugs, there should never be a service downtime. The Bitcoin network demonstrated such an excellent uptime record<ref>https://buybitcoinworldwide.com/bitcoin-uptime/</ref> that no legacy infrastructures could match.

Another remarkable feature of the Bitcoin network is that its protocol programs are Open Source. Anyone can download and manipulate it and turn it to attack the network. There has been no successful Bitcoin network attacks since its 2009 launch.

It is also interesting to observe that the blockchain protocols are silent on transaction re-transmission discipline. The blockchain wallets are responsible to check their own transactions' status and retransmit if necessary. Since double-spending is not possible, retransmitting a transaction is a trivial matter and it would most likely find a different route for transaction approval.

However, scalability remains the common challenge to all blockchain protocols. For POW consensus chains, the increasing energy consumption caused serious sustainability concerns. Since the cryptographic proved ledgers are immutable, for POS chains, although more than 99% energy consumption reduction can be achieved, the blockchain network's scalability is still challenged, since the chains will have to shutdown when all nodes storage are saturated.

It is evident that all blockchains should be infinitely scalable. This means that expanding the network (adding nodes) should increase the network's performance, reliability and security.

== SMC Blockchain Protocol ==
SMC blockchain protocol aims to solve the scalability challenge by enabling automated parallel processing without negatively impacting the network security and reliability. The ACAN concept is a perfect fit for this case. ACAN enables automated SMC by forcing the transaction validation blocks to form SIMD, MIMD and pipeline clusters in real time.

== SMC POS Consensus ==
SMC POS consensus will randomly select staking validators without staking pools. SMC POS protocol also has an adjustable replication factor that the network ledger has a fixed replication factor that can be tuned on demand without service interruptions. Therefore, SMC POS consensus protocol can deliver:

# Byzantine failure resistance
# Fault tolerance
# Program tamper resistance
# Centralization avoidance
# Incrementally better performance, security and reliability

More nodes in the network expands the network storage capacity without adding extra redundancy. More nodes facilitates longer pipelines for better performances.

SMC blockchain protocol is also silent on transaction retransmission discipline. Transaction retransmission will enable different approval routes without double-spend risks. This ensures seamless integration with legacy blockchain wallets.

== Summary ==
SMC blockchain protocol is the only statistic multiplexed blockchain protocol to date. The SMC technology development history links the blockchain protocol development to stateless HPC (high performance computing) developments. This is the only known technology that can offer decentralized processing for centralized controls, which is the perfect gateway to integrate web2.0 applications for web3.0 infrastructures.

== References: ==
<references />

Main Page

2024-05-06T12:17:29Z

Justin: /* Action Plan */

= <strong><big>'''Welcome to Toi-Twiki -- A Toichain Wiki'''</big></strong> =
This is the unofficial Toichain wiki site. Content is subject to changes.
---------------------------

= '''Introduction''' =
The blockchain protocol was introduced in a seminal paper entitled "Bitcoin: A peer-to-peer Electronic Cash System" <ref>https://bitcoin.org/bitcoin.pdf</ref> by Satoshi Nakamoto in 2008. Although there were previous peer-to-peer file-sharing projects such as Napster <ref>https://www.napster.com/us</ref>, BitTorrent <ref>https://www.bittorrent.com/</ref> and other electronic currency/file sharing applications, Bitcoin is the most enduring among the 23,000+ blockchains. Unlike other cryptocurrencies, the Bitcoin is often referred to as "digital gold" since the total coin supply is limited to 21 million (hard-coded in all running programs) and the only way to earn coin is to participate in the transaction block validation process. Token(or coin) supply and their disbursement policies differ among protocols.

The most attractive common blockchain features are 1) a decentralized consensus-driven decision making process and 2) a step-by-step cryptographic proving system. While blockchain is best known as a cryptocurrency transaction processing and record-keeping system, there are many other applications that can benefit from the secure storage, reliable transaction ledgers, fault tolerance and tamper resistance features.

== Algorithm vs. Protocol ==
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 ==
A good consensus protocol in a blockchain system has at least four properties:

# Fault tolerance to defend failures caused by natural disasters and human hacks or accidents
# Byzantine failure tolerance to defend exploitation by colluding parties
# Centralization avoidance to prevent corruptions in the decision making process
# Source code tamper resistance to automatically reject malicious attacks

Without assuming all nodes are active at all times, the blockchain relies on "gossip" protocol to communicate with other nodes. There are two popular types of consensus protocols: Proof of Work ('''PoW''') <ref>https://en.wikipedia.org/wiki/Proof_of_work</ref> or Proof of Stake ('''PoS''') <ref>https://www.investopedia.com/terms/p/proof-stake-pos.asp</ref>. Others include Proof of Possession('''PoP''')<ref>https://identityserver4.readthedocs.io/en/latest/topics/pop.html</ref> and Proof of History('''PoH''')<ref>https://www.infoworld.com/article/3666736/solana-blockchain-and-the-proof-of-history.html</ref>. The ultimate goal is to eliminate double-spending. Since most projects are open source, it's easy for a malicious actor to tamper a few nodes. This shouldn't compromise network integrity.

The Bitcoin network uses PoW which forces participating miners to compete for the fastest hashing rate by solving a computational cryptographic puzzle. Although it withstood more than 14 years of use, Bitcoin has been criticized for escalating electricity consumption <ref>https://www.forbes.com/advisor/investing/cryptocurrency/bitcoins-energy-usage-explained/</ref>. Other blockchain designs have experienced different challenges. For example, the PoH network Solana suffered multiple single-point-failure incidents <ref>https://messari.io/report/solana-analyzing-downtimes-statistics-and-ecosystem-development</ref>. All protocols struggle to combat scaling challenges. All are susceptible to 51% attacks <ref>https://originstamp.com/blog/has-there-ever-been-a-51-attack-on-bitcoin/#notable-51-attacks</ref>.

Since 2009, Bitcoin has proven to be the strongest and least susceptible to common hacks <ref>https://www.theguardian.com/technology/2014/mar/18/history-of-bitcoin-hacks-alternative-currency</ref>. As the PoW puzzle difficulty has increased dramatically over the years, the probability of a 51% attack on the Bitcoin network becomes more difficult. PoS protocols can save more than 90% energy consumption compared to PoW chains. But PoS chains have higher risks than PoW chains since a stolen coin will grow in PoS chains (for increased probability to be selected) forever but not in PoW chains (only hash rates count). PoS community governance rules can mitigate the voting power centralization problem. Staking and slashing policies can incentivize good behaviors and punish bad ones. In either case, double-spend is very expensive and difficult. According to Forbes, there are 80 cryptocurrencies that use PoS protocols at the time of this writing.

There are approximately 1,000 blockchains in four types: public, private, consortium, and permissioned <ref>https://increditools.com/blockchains/</ref>.

== Cryptographic Proofs ==
Bitcoin 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.

== Centralized vs. Decentralized Applications ==
The Bitcoin protocol enabled decentralized processing of traditionally centrally processed transactions without any trusted third-party. It inspired many decentralized financial applications, especially for applications with very long payment chains. However for fraud prevention and meeting financial regulatory requirements, many practical applications still require KYC (know your customer) checks. It is not possible to eliminate all trusted third parties, especially for custodial financial applications. There is a clear need for decentralized processing of trusted authority applications.

== Blockchain Trilemma ==
Blockchain protocols have three common aspects (goals): '''security''', '''decentralization''' and '''scalability''' -- these three terms do not have precise definitions but are intuitively understood <ref>https://sensoriumxr.com/articles/what-is-the-blockchain-trilemma</ref>. To date, 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.

A major shortcoming is scalability. Since all nodes verify each transaction independently, they need to store all the information required for it. As the chain grows, this burdens all nodes in the network. There are workarounds by limiting the amount of data stored on some nodes and exploiting the network to retrieve required information, such as the ''Limited/Light Nodes'' in Bitcoin network. Vast majority nodes are still full nodes in the existing Bitcoin network. Transaction processing speed often expressed ''as transactions per second(TPS) of'' blockchain have to exceed TPS ratings of credit card payment systems like VISA or MasterCard to reap the full benefits of blockchain. This is a tough problem and increasing the block size and/or reducing the block time or difficulty isn't a solution<ref>https://medium.com/coinmonks/blockchain-scaling-30c9e1b7db1b</ref>. Since blockchain TPS is very low, the transaction fees is often very high. This discourages public adoption. Layer 2 solution like ''Lightning Network'' or ''ZK-rollups,'' where only final settlement is on the main chain tend to address these issues. However, one could always argue that this often compromises some aspects of security and/or decentralization to achieve high TPS.

The trilemma was first introduced by Vitalik Buterin<ref>https://en.wikipedia.org/wiki/Vitalik_Buterin</ref>, one of the co-founders of Ethereum network. The problems he identified are real. There seem to be no obvious solutions that can accomplish all three goals at the same time. Therefore, all proposed solutions revolve around reducing "opportunity costs" focusing only on satisfying partial goals.

Treating the blockchain network as an infrastructure for transaction processing, the blockchain protocol solved service reliability problem but not performance challenge. The legacy infrastructure scaling dilemma: performance against reliability remains (where "infrastructure reliability" also does not have a commonly accepted definition). Fortunately these metrics, although important, are non-critical. Solutions that have been proposed have had varying opportunity costs. For many years, there were no obvious solutions that addressed all three blockchain goals (security, decentralization and scalability).
== Statistic Multiplexed Computing (SMC) ==
The principle of using unreliable components to build an arbitrarily reliable system was first lectured by von Neumann in the early 1950s<ref>https://static.ias.edu/pitp/archive/2012files/Probabilistic_Logics.pdf</ref>. The original idea was to use probabilistic logic to quantify the arbitrary reliability of a system by multiplexing all components. This theory was applied to the construction of Internet protocols to deliver the "best effort" reliability. Incidentally, best effort reliability also enabled "best effort" performance which in turn enabled unlimited scalability of the Internet. For emerging web3.0 technologies, it is important to apply the same methodology to both centralized and decentralized computing for seamless technology migration and integration. For historical arguments, click [[SMC|'''''here''''']].

== Definitions ==
'''Infrastructure scalability''' does not have a commonly accepted definition. It helps to define the challenging metrics more precisely before the infrastructure protocol design. In the following, for definitions #1 and #2, the word "'''infrastructure'''" means any '''application running on the infrastructure.'''

# '''Infrastructure Reliability''': MTBF (mean time between failure) = <math>\frac{\sum ((Start-Of-Downtime) - (Start-of-uptime)) }{No-of-failures}</math>
# '''Infrastructure Performance''': <math>\frac{No-of-Transactions}{Second}</math>
# '''Infrastructure Scalability''': Expanding the infrastructure in number of processors, networks or storage should have '''incrementally better''' impacts on application reliability and performance.
# '''Record Immutability''': For transaction ledgers, all confirmed records and changes are final. This is required by the blockchain protocol.
Note that in practice, record immutability is much harder to achieve than expected. There are two challenges, a) 51% attacks can literally wipe out all histories if successful, and b) for protocols require all nodes to hold independently verified ledger, such as the Bitcoin, the storage requirement grows approximately 50GB per month.

== 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 and considered.

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 crashe'''s <ref>https://groups.csail.mit.edu/tds/papers/Lynch/jacm93.pdf</ref>. The laws of physics regarding component reliability <ref>Encyclopedia of Physical Science and Technology, Editor-in-Chief Robert A. Meyers, [[index.php?title=Special:BookSources/9780122274107|ISBN 978-0-12-227410-7]], 2001</ref> show that '''100% component reliability is not possible.''' These facts require that the infrastructure protocol (program-program communication protocol) provide '''complete component (processing, networking and storage) decoupling''' from application program logics. This decoupling requirement forces the protocol to exploit "decentralized" or "stateless" components that the legacy infrastructure protocols, such as message passing interface (MPI), remote procedure call (RPC) and remote method invocation (RMI), cannot handle. The blockchain protocol is an example of a "best effort" availability protocol.

Quantifying infrastructure reliability can be traced back to the computer pioneer von Neumann. In addition to his contribution to computer architecture, von Neumann also penned a study on building reliable systems using unreliable components using probabilistic logics, in early fifties <ref>https://static.ias.edu/pitp/archive/2012files/Probabilistic_Logics.pdf</ref>. The 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 "best effort" reliability. Ironically, this best effort reliability also enabled the Internet's infinite scalability -- the benefit we enjoy now and into the future.

The Bitcoin protocol exploits multiple anonymous decoupled (or decentralized) computers connected through the Internet protocol. Judging from the Bitcoin network's reliability to date <ref>https://buybitcoinworldwide.com/bitcoin-downtime/</ref>, von Neumann's theory seems working well.

The '''second challenge''' involves infrastructure performance. Since the infrastructure must deploy multiple computing, networking and storage components, unless all components can be fully exploited at 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 lack this capability.

'''The infrastructure scalability challenge''' is automatically resolved once the performance challenge is resolved without negatively impacting reliability -- "best effort" performance" meets "best effort reliability". This requires inductive performance and reliability measures or deliveries.

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, an inductive statistic multiplexed blockchain protocol is needed to meet the scalability challenge. Non-inductive solutions such as fixed chain "sharding" or "Danksharding" <ref>https://ethereum.org/en/roadmap/danksharding/</ref> will only increase protocol development complexity with persistent performance walls.

== A Scalability Solution ==
An effective scalability solution can have two practical assumptions:

* The computation problem size can expand indefinitely, since every useful infrastructure is expected to solve bigger problems.

*Computing and network resources will continue to grow indefinitely, into the future.
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 <ref>https://en.wikipedia.org/wiki/Amdahl%27s_law</ref> and Gustafson's Law <ref>https://en.wikipedia.org/wiki/Gustafson%27s_law</ref>. The problem is that these two "laws" seem to yield complete opposite performance predictions.[[File:Amdahl's Law.png|thumb|Amdahl's Law Speedup Predictions|center]]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.
[[File:Gustafson.png|thumb|Gustafson's Law|center]]
A careful examination revealed that the two laws are mathematically dependent <ref>https://cis.temple.edu/~shi/wwwroot/shi/public_html/docs/amdahl/amdahl.html</ref> where Amdahl's formulation has a tight peak performance bound <math>\left ( \frac{1}{x} \right )</math> 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 <math>\left ( \frac{1}{x} \right )</math>, when <math>x \Rightarrow 0</math>, the performance will asymptotically approach to <math>\infty</math>, when <math>x \Rightarrow 1</math> the speedup <math>\Rightarrow</math> 1. Thus, if the computing problem's size is fixed, x will eventually approach to 1 as the number of processors increases -- economic law of diminishing of return. If the problem size is open (solving bigger problems), then increasing the number of processors will force x <math>\Rightarrow</math> 0, thus speedup <math>\Rightarrow</math> <math>\infty</math>. Gustafson's Law uses a recurrence relation based on practical time measurements. It is not possible to derive a mathematical speedup bound.

Applying these laws in practice need to quantify <math>\chi</math> for practical parallel program which has been proven very hard if not impossible. Gustafson's formula was derived from times by running actual parallel programs. Brining the two formulation together makes quantifying <math>\chi</math> in Amdahl's Law possible. Thus, both law actually refer to the same mathematical abstraction. Gustafson's formula assisted in quantifying the percentage of serial computing through program experiments. Neither should be directly used for speedup prediction alone.

This model can be validated in practice when developers simply increasing the problem size to use more parallel processors.
[[File:1overx-function resized.png|thumb|294x294px|Amdalh's Law and Peak Parallel Performance|center]]

A classical example is the TOP500 supercomputer benchmarks (linear solvers) that have open problem sizes for all manufacturers to compete in the world's fastest supercomputer race <ref>https://www.top500.org/</ref> .
[[File:Supercomputers-history.png|center|thumb]]
In practical blockchain applications, the number of transactions to be processed will increase without a known limit. The ledger storage will continue to grow. In practice, the available computing, networking and storage components will continue to grow without limits enabled by the networking protocols. Therefore a statistic multiplexed computing blockchain can meet any future application needs given proper economic incentives. The infrastructure no longer has the structural deficiency.

== Action Plan ==

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.

For Toichain protocol design, we choose Bitcoin 24.0.1 as the base line protocol by replacing the PoW consensus by PoS consensus and injecting SMC components into the protocol processing signaling for parallel computing.

This surprising result is also applicable to ledger storage. Without multiplexing, the blockchain ledger storage will eventually saturate all nodes causing the chain to collapse. The SMC blockchain protocol promises to hold the true finality of all transactions in perpetuity by multiplexing all storage resources while keeping the replication factor to a constant.

These discussions follow the inductive logic of the Law of Large Numbers <ref>https://www.sciencedirect.com/topics/mathematics/laws-of-large-number</ref>.

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

= SMC Proof of Stake Protocol =
Existing PoS protocol designs revolved around staking policies and randomness of the selection algorithm. Considering infrastructure scalability will add much complexity to the design. The examples include chain sharding and Danksharding <ref>https://ethereum.org/en/roadmap/danksharding/</ref>.

The challenge is complex -- we must deliver very high performance without compromising security and reliability of the network.

Technically, transaction replication and parallel processing were considered dangerous <ref>https://pages.cs.wisc.edu/~yxy/cs764-f20/papers/replication.pdf</ref> due to the potential race conditions (or double-spend problem). The blockchain protocol resolved the double-spending problem. It did not solve the parallel processing performance problem.

According to Professor Michael Flynn, there are three high-level parallel processing topologies: SIMD (single instruction multiple data), MIMD (multiple instructions multiple data), and pipeline (MISD - multiple instructions single data stream) <ref>https://link.springer.com/referenceworkentry/10.1007/978-0-387-09766-4_2</ref>. However, for eliminating double-spending, all transactions must be serialized, since each block may contain transactions affecting transactions in multiple other blocks. "Race conditions" and non-deterministic results are not allowed. Then the only possible topology entry is pipeline. This means for POS protocol, we must build a pipeline of transaction blocks to be validated without compromising network security and reliability.
[[File:Flynns-Taxonomy-of-Computer-Architectures.png|center|thumb|Parallel Processing Topologies]]
The problem is that the nature of the blockchain protocol is that all nodes run independently in parallel with little communication with other nodes via "gossip" protocols. It is far easier to force all nodes store the entire ledger than forcing them to form any pipeline and store partial chain data.

=== ACAN (Active Content Addressable Network) [U.S. and Other Patents Pending] ===
ACAN is a high-level data '''''communication and synchronization protocol''''' that completely decouples all hardware components from communicating programs. The need for complete component decoupling was implemented in the original blockchain protocol via "gossip" protocol. This delivered blockchain's high availability and security. The simple "gossip" implementation in existing protocols is insufficient for parallel processing signaling.

The following figure illustrates the concept of ACAN (active content addressable networking) using UVR (unidirectional virtual ring) architecture. The illustrated implementation uses the Tuple Space resource tagging method and gossip protocol for UVR implementation.
[[File:SMC Architecture with ACAN.png|center|thumb|243x243px|SMC Architecture with ACAN]]

ACAN supports three simple APIs:

# '''read'''(&''key'', &''value''): ''key'' holds a search pattern in a "tuple space" where all nodes are connected. ''value'' holds the matched tuple, if any. This is a blocking call that a requesting program will be blocked until a pattern-matched tuple is found. The matching tuple remains in the "tuple space".
# '''get'''(&key, &value): Same as the "read()" API, except that the matching tuple is removed from the "tuple space".
# '''put'''(key, value): Inserts <key, value> into the "tuple space".

The use of "gossip" protocol can accelerate ACAN network saturation time. Applications running on ACAN will automatically form parallel processing topologies: pipeline, SIMD and MIMD without violating the serialization needs of transaction block validation. Replication factor can also be dynamically controlled to spread replicated blocks in randomly chosen hosts.

The highly parallel nature of the blockchain protocol will automatically implement the SMC principle in real time.

The critical feature of this dynamic SMC pipelined architecture is the inductive scaling feature.
[[File:Pipeline Parallel Processing.png|center|thumb|247x247px|Pipeline Parallel Processing]]

The speed up of a pipeline can be represented as: <math>SpeedUp = \left ( \frac{p\centerdot b}{p + (b-p)} \right )</math>, where p = number of processors in the pipeline, b = total blocks to be processed. Take the number of blocks to infinity: <math>SpeedUp = \left ( \frac{p\centerdot b}{p + (b-p)} \right )=>\lim (b\Rightarrow\infty)(\frac{p}{\frac{p}{b}+1-\frac{p}{b}}) = p</math>

This means that as long as there are enough blocks to be processed, the entire chain's performance will be abound-bounded to the number of nodes in the pipeline.

For illustration purposes, the variation of block processing times was not considered in the above calculations. To see the power of pipeline parallelism, the automobile manufacturing processes illustrate a similar situation. The Hyundai Motor Company's production pipelines can produce 3,835 vehicles per day and 1.4M per year<ref>https://en.wikipedia.org/wiki/List_of_Hyundai_Motor_Company_manufacturing_facilities</ref>.

== Toichain Tokens ==
Toichain token is TOIN. There are 50,000,000,000 TOINs for the Alpha Release. There are air-drop tokens for early adopters, 1,000 TOIN each. Users need to register to download a toichain wallet to receive the payment. Citizenship is checked and verified to ensure that US citizens do not apply. The minimal staking contract is 10 TOINs.

== Non-Fungible Tokens ==
The TestNet Release of toichain protocol will support embedding arbitrary data in an "OP_RETURN" transaction that will be permanently recorded on the chain. Unlike the ordinal NFT <ref>https://blog.chain.link/ordinals-bitcoin-nfts/</ref> or NFT (non-fungible token) on other chains, these transactions cannot be altered or removed.

There are practical applications for these forever NFTs. Once Taproot is enabled on toichain, ordinal NFTs (BRC-20) will also be supported. Unlike the original Bitcoin network where BRC-20 craze has created massive network congestion<ref>https://beincrypto.com/learn/brc-20-token/</ref>, all transactions will be processed promptly in toichain without congestion or scaling problems.
== Toichain TestNet Launch ==
The toichain testnet launch will enable users to interact with one another through simple payments, just like the original Bitcoin network. Forever NFTs are supported. Smart contracts will be supported on a later date.

= References =
<references />

Consult the [[mediawikiwiki:Special:MyLanguage/Help:Contents|User's Guide]] for information on using the wiki software.

Main Page

2024-05-06T12:13:03Z

Justin: /* A Scalability Solution */

= <strong><big>'''Welcome to Toi-Twiki -- A Toichain Wiki'''</big></strong> =
This is the unofficial Toichain wiki site. Content is subject to changes.
---------------------------

= '''Introduction''' =
The blockchain protocol was introduced in a seminal paper entitled "Bitcoin: A peer-to-peer Electronic Cash System" <ref>https://bitcoin.org/bitcoin.pdf</ref> by Satoshi Nakamoto in 2008. Although there were previous peer-to-peer file-sharing projects such as Napster <ref>https://www.napster.com/us</ref>, BitTorrent <ref>https://www.bittorrent.com/</ref> and other electronic currency/file sharing applications, Bitcoin is the most enduring among the 23,000+ blockchains. Unlike other cryptocurrencies, the Bitcoin is often referred to as "digital gold" since the total coin supply is limited to 21 million (hard-coded in all running programs) and the only way to earn coin is to participate in the transaction block validation process. Token(or coin) supply and their disbursement policies differ among protocols.

The most attractive common blockchain features are 1) a decentralized consensus-driven decision making process and 2) a step-by-step cryptographic proving system. While blockchain is best known as a cryptocurrency transaction processing and record-keeping system, there are many other applications that can benefit from the secure storage, reliable transaction ledgers, fault tolerance and tamper resistance features.

== Algorithm vs. Protocol ==
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 ==
A good consensus protocol in a blockchain system has at least four properties:

# Fault tolerance to defend failures caused by natural disasters and human hacks or accidents
# Byzantine failure tolerance to defend exploitation by colluding parties
# Centralization avoidance to prevent corruptions in the decision making process
# Source code tamper resistance to automatically reject malicious attacks

Without assuming all nodes are active at all times, the blockchain relies on "gossip" protocol to communicate with other nodes. There are two popular types of consensus protocols: Proof of Work ('''PoW''') <ref>https://en.wikipedia.org/wiki/Proof_of_work</ref> or Proof of Stake ('''PoS''') <ref>https://www.investopedia.com/terms/p/proof-stake-pos.asp</ref>. Others include Proof of Possession('''PoP''')<ref>https://identityserver4.readthedocs.io/en/latest/topics/pop.html</ref> and Proof of History('''PoH''')<ref>https://www.infoworld.com/article/3666736/solana-blockchain-and-the-proof-of-history.html</ref>. The ultimate goal is to eliminate double-spending. Since most projects are open source, it's easy for a malicious actor to tamper a few nodes. This shouldn't compromise network integrity.

The Bitcoin network uses PoW which forces participating miners to compete for the fastest hashing rate by solving a computational cryptographic puzzle. Although it withstood more than 14 years of use, Bitcoin has been criticized for escalating electricity consumption <ref>https://www.forbes.com/advisor/investing/cryptocurrency/bitcoins-energy-usage-explained/</ref>. Other blockchain designs have experienced different challenges. For example, the PoH network Solana suffered multiple single-point-failure incidents <ref>https://messari.io/report/solana-analyzing-downtimes-statistics-and-ecosystem-development</ref>. All protocols struggle to combat scaling challenges. All are susceptible to 51% attacks <ref>https://originstamp.com/blog/has-there-ever-been-a-51-attack-on-bitcoin/#notable-51-attacks</ref>.

Since 2009, Bitcoin has proven to be the strongest and least susceptible to common hacks <ref>https://www.theguardian.com/technology/2014/mar/18/history-of-bitcoin-hacks-alternative-currency</ref>. As the PoW puzzle difficulty has increased dramatically over the years, the probability of a 51% attack on the Bitcoin network becomes more difficult. PoS protocols can save more than 90% energy consumption compared to PoW chains. But PoS chains have higher risks than PoW chains since a stolen coin will grow in PoS chains (for increased probability to be selected) forever but not in PoW chains (only hash rates count). PoS community governance rules can mitigate the voting power centralization problem. Staking and slashing policies can incentivize good behaviors and punish bad ones. In either case, double-spend is very expensive and difficult. According to Forbes, there are 80 cryptocurrencies that use PoS protocols at the time of this writing.

There are approximately 1,000 blockchains in four types: public, private, consortium, and permissioned <ref>https://increditools.com/blockchains/</ref>.

== Cryptographic Proofs ==
Bitcoin 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.

== Centralized vs. Decentralized Applications ==
The Bitcoin protocol enabled decentralized processing of traditionally centrally processed transactions without any trusted third-party. It inspired many decentralized financial applications, especially for applications with very long payment chains. However for fraud prevention and meeting financial regulatory requirements, many practical applications still require KYC (know your customer) checks. It is not possible to eliminate all trusted third parties, especially for custodial financial applications. There is a clear need for decentralized processing of trusted authority applications.

== Blockchain Trilemma ==
Blockchain protocols have three common aspects (goals): '''security''', '''decentralization''' and '''scalability''' -- these three terms do not have precise definitions but are intuitively understood <ref>https://sensoriumxr.com/articles/what-is-the-blockchain-trilemma</ref>. To date, 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.

A major shortcoming is scalability. Since all nodes verify each transaction independently, they need to store all the information required for it. As the chain grows, this burdens all nodes in the network. There are workarounds by limiting the amount of data stored on some nodes and exploiting the network to retrieve required information, such as the ''Limited/Light Nodes'' in Bitcoin network. Vast majority nodes are still full nodes in the existing Bitcoin network. Transaction processing speed often expressed ''as transactions per second(TPS) of'' blockchain have to exceed TPS ratings of credit card payment systems like VISA or MasterCard to reap the full benefits of blockchain. This is a tough problem and increasing the block size and/or reducing the block time or difficulty isn't a solution<ref>https://medium.com/coinmonks/blockchain-scaling-30c9e1b7db1b</ref>. Since blockchain TPS is very low, the transaction fees is often very high. This discourages public adoption. Layer 2 solution like ''Lightning Network'' or ''ZK-rollups,'' where only final settlement is on the main chain tend to address these issues. However, one could always argue that this often compromises some aspects of security and/or decentralization to achieve high TPS.

The trilemma was first introduced by Vitalik Buterin<ref>https://en.wikipedia.org/wiki/Vitalik_Buterin</ref>, one of the co-founders of Ethereum network. The problems he identified are real. There seem to be no obvious solutions that can accomplish all three goals at the same time. Therefore, all proposed solutions revolve around reducing "opportunity costs" focusing only on satisfying partial goals.

Treating the blockchain network as an infrastructure for transaction processing, the blockchain protocol solved service reliability problem but not performance challenge. The legacy infrastructure scaling dilemma: performance against reliability remains (where "infrastructure reliability" also does not have a commonly accepted definition). Fortunately these metrics, although important, are non-critical. Solutions that have been proposed have had varying opportunity costs. For many years, there were no obvious solutions that addressed all three blockchain goals (security, decentralization and scalability).
== Statistic Multiplexed Computing (SMC) ==
The principle of using unreliable components to build an arbitrarily reliable system was first lectured by von Neumann in the early 1950s<ref>https://static.ias.edu/pitp/archive/2012files/Probabilistic_Logics.pdf</ref>. The original idea was to use probabilistic logic to quantify the arbitrary reliability of a system by multiplexing all components. This theory was applied to the construction of Internet protocols to deliver the "best effort" reliability. Incidentally, best effort reliability also enabled "best effort" performance which in turn enabled unlimited scalability of the Internet. For emerging web3.0 technologies, it is important to apply the same methodology to both centralized and decentralized computing for seamless technology migration and integration. For historical arguments, click [[SMC|'''''here''''']].

== Definitions ==
'''Infrastructure scalability''' does not have a commonly accepted definition. It helps to define the challenging metrics more precisely before the infrastructure protocol design. In the following, for definitions #1 and #2, the word "'''infrastructure'''" means any '''application running on the infrastructure.'''

# '''Infrastructure Reliability''': MTBF (mean time between failure) = <math>\frac{\sum ((Start-Of-Downtime) - (Start-of-uptime)) }{No-of-failures}</math>
# '''Infrastructure Performance''': <math>\frac{No-of-Transactions}{Second}</math>
# '''Infrastructure Scalability''': Expanding the infrastructure in number of processors, networks or storage should have '''incrementally better''' impacts on application reliability and performance.
# '''Record Immutability''': For transaction ledgers, all confirmed records and changes are final. This is required by the blockchain protocol.
Note that in practice, record immutability is much harder to achieve than expected. There are two challenges, a) 51% attacks can literally wipe out all histories if successful, and b) for protocols require all nodes to hold independently verified ledger, such as the Bitcoin, the storage requirement grows approximately 50GB per month.

== 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 and considered.

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 crashe'''s <ref>https://groups.csail.mit.edu/tds/papers/Lynch/jacm93.pdf</ref>. The laws of physics regarding component reliability <ref>Encyclopedia of Physical Science and Technology, Editor-in-Chief Robert A. Meyers, [[index.php?title=Special:BookSources/9780122274107|ISBN 978-0-12-227410-7]], 2001</ref> show that '''100% component reliability is not possible.''' These facts require that the infrastructure protocol (program-program communication protocol) provide '''complete component (processing, networking and storage) decoupling''' from application program logics. This decoupling requirement forces the protocol to exploit "decentralized" or "stateless" components that the legacy infrastructure protocols, such as message passing interface (MPI), remote procedure call (RPC) and remote method invocation (RMI), cannot handle. The blockchain protocol is an example of a "best effort" availability protocol.

Quantifying infrastructure reliability can be traced back to the computer pioneer von Neumann. In addition to his contribution to computer architecture, von Neumann also penned a study on building reliable systems using unreliable components using probabilistic logics, in early fifties <ref>https://static.ias.edu/pitp/archive/2012files/Probabilistic_Logics.pdf</ref>. The 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 "best effort" reliability. Ironically, this best effort reliability also enabled the Internet's infinite scalability -- the benefit we enjoy now and into the future.

The Bitcoin protocol exploits multiple anonymous decoupled (or decentralized) computers connected through the Internet protocol. Judging from the Bitcoin network's reliability to date <ref>https://buybitcoinworldwide.com/bitcoin-downtime/</ref>, von Neumann's theory seems working well.

The '''second challenge''' involves infrastructure performance. Since the infrastructure must deploy multiple computing, networking and storage components, unless all components can be fully exploited at 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 lack this capability.

'''The infrastructure scalability challenge''' is automatically resolved once the performance challenge is resolved without negatively impacting reliability -- "best effort" performance" meets "best effort reliability". This requires inductive performance and reliability measures or deliveries.

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, an inductive statistic multiplexed blockchain protocol is needed to meet the scalability challenge. Non-inductive solutions such as fixed chain "sharding" or "Danksharding" <ref>https://ethereum.org/en/roadmap/danksharding/</ref> will only increase protocol development complexity with persistent performance walls.

== A Scalability Solution ==
An effective scalability solution can have two practical assumptions:

* The computation problem size can expand indefinitely, since every useful infrastructure is expected to solve bigger problems.

*Computing and network resources will continue to grow indefinitely, into the future.
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 <ref>https://en.wikipedia.org/wiki/Amdahl%27s_law</ref> and Gustafson's Law <ref>https://en.wikipedia.org/wiki/Gustafson%27s_law</ref>. The problem is that these two "laws" seem to yield complete opposite performance predictions.[[File:Amdahl's Law.png|thumb|Amdahl's Law Speedup Predictions|center]]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.
[[File:Gustafson.png|thumb|Gustafson's Law|center]]
A careful examination revealed that the two laws are mathematically dependent <ref>https://cis.temple.edu/~shi/wwwroot/shi/public_html/docs/amdahl/amdahl.html</ref> where Amdahl's formulation has a tight peak performance bound <math>\left ( \frac{1}{x} \right )</math> 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 <math>\left ( \frac{1}{x} \right )</math>, when <math>x \Rightarrow 0</math>, the performance will asymptotically approach to <math>\infty</math>, when <math>x \Rightarrow 1</math> the speedup <math>\Rightarrow</math> 1. Thus, if the computing problem's size is fixed, x will eventually approach to 1 as the number of processors increases -- economic law of diminishing of return. If the problem size is open (solving bigger problems), then increasing the number of processors will force x <math>\Rightarrow</math> 0, thus speedup <math>\Rightarrow</math> <math>\infty</math>. Gustafson's Law uses a recurrence relation based on practical time measurements. It is not possible to derive a mathematical speedup bound.

Applying these laws in practice need to quantify <math>\chi</math> for practical parallel program which has been proven very hard if not impossible. Gustafson's formula was derived from times by running actual parallel programs. Brining the two formulation together makes quantifying <math>\chi</math> in Amdahl's Law possible. Thus, both law actually refer to the same mathematical abstraction. Gustafson's formula assisted in quantifying the percentage of serial computing through program experiments. Neither should be directly used for speedup prediction alone.

This model can be validated in practice when developers simply increasing the problem size to use more parallel processors.
[[File:1overx-function resized.png|thumb|294x294px|Amdalh's Law and Peak Parallel Performance|center]]

A classical example is the TOP500 supercomputer benchmarks (linear solvers) that have open problem sizes for all manufacturers to compete in the world's fastest supercomputer race <ref>https://www.top500.org/</ref> .
[[File:Supercomputers-history.png|center|thumb]]
In practical blockchain applications, the number of transactions to be processed will increase without a known limit. The ledger storage will continue to grow. In practice, the available computing, networking and storage components will continue to grow without limits enabled by the networking protocols. Therefore a statistic multiplexed computing blockchain can meet any future application needs given proper economic incentives. The infrastructure no longer has the structural deficiency.

== 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.

For Toichain protocol design, we choose Bitcoin 24.0.1 as the base line protocol by replacing the PoW consensus by PoS consensus and injecting SMC components into the protocol processing signaling for parallel computing.

This surprising result is also applicable to ledger storage. Without multiplexing, the blockchain ledger storage will eventually saturate all nodes causing the chain to collapse. The SMC blockchain protocol promises to hold the true finality of all transactions in perpetuity by multiplexing all storage resources while keeping the replication factor to a constant.

These discussions follow the inductive logic of the Law of Large Numbers <ref>https://www.sciencedirect.com/topics/mathematics/laws-of-large-number</ref>.

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

= SMC Proof of Stake Protocol =
Existing PoS protocol designs revolved around staking policies and randomness of the selection algorithm. Considering infrastructure scalability will add much complexity to the design. The examples include chain sharding and Danksharding <ref>https://ethereum.org/en/roadmap/danksharding/</ref>.

The challenge is complex -- we must deliver very high performance without compromising security and reliability of the network.

Technically, transaction replication and parallel processing were considered dangerous <ref>https://pages.cs.wisc.edu/~yxy/cs764-f20/papers/replication.pdf</ref> due to the potential race conditions (or double-spend problem). The blockchain protocol resolved the double-spending problem. It did not solve the parallel processing performance problem.

According to Professor Michael Flynn, there are three high-level parallel processing topologies: SIMD (single instruction multiple data), MIMD (multiple instructions multiple data), and pipeline (MISD - multiple instructions single data stream) <ref>https://link.springer.com/referenceworkentry/10.1007/978-0-387-09766-4_2</ref>. However, for eliminating double-spending, all transactions must be serialized, since each block may contain transactions affecting transactions in multiple other blocks. "Race conditions" and non-deterministic results are not allowed. Then the only possible topology entry is pipeline. This means for POS protocol, we must build a pipeline of transaction blocks to be validated without compromising network security and reliability.
[[File:Flynns-Taxonomy-of-Computer-Architectures.png|center|thumb|Parallel Processing Topologies]]
The problem is that the nature of the blockchain protocol is that all nodes run independently in parallel with little communication with other nodes via "gossip" protocols. It is far easier to force all nodes store the entire ledger than forcing them to form any pipeline and store partial chain data.

=== ACAN (Active Content Addressable Network) [U.S. and Other Patents Pending] ===
ACAN is a high-level data '''''communication and synchronization protocol''''' that completely decouples all hardware components from communicating programs. The need for complete component decoupling was implemented in the original blockchain protocol via "gossip" protocol. This delivered blockchain's high availability and security. The simple "gossip" implementation in existing protocols is insufficient for parallel processing signaling.

The following figure illustrates the concept of ACAN (active content addressable networking) using UVR (unidirectional virtual ring) architecture. The illustrated implementation uses the Tuple Space resource tagging method and gossip protocol for UVR implementation.
[[File:SMC Architecture with ACAN.png|center|thumb|243x243px|SMC Architecture with ACAN]]

ACAN supports three simple APIs:

# '''read'''(&''key'', &''value''): ''key'' holds a search pattern in a "tuple space" where all nodes are connected. ''value'' holds the matched tuple, if any. This is a blocking call that a requesting program will be blocked until a pattern-matched tuple is found. The matching tuple remains in the "tuple space".
# '''get'''(&key, &value): Same as the "read()" API, except that the matching tuple is removed from the "tuple space".
# '''put'''(key, value): Inserts <key, value> into the "tuple space".

The use of "gossip" protocol can accelerate ACAN network saturation time. Applications running on ACAN will automatically form parallel processing topologies: pipeline, SIMD and MIMD without violating the serialization needs of transaction block validation. Replication factor can also be dynamically controlled to spread replicated blocks in randomly chosen hosts.

The highly parallel nature of the blockchain protocol will automatically implement the SMC principle in real time.

The critical feature of this dynamic SMC pipelined architecture is the inductive scaling feature.
[[File:Pipeline Parallel Processing.png|center|thumb|247x247px|Pipeline Parallel Processing]]

The speed up of a pipeline can be represented as: <math>SpeedUp = \left ( \frac{p\centerdot b}{p + (b-p)} \right )</math>, where p = number of processors in the pipeline, b = total blocks to be processed. Take the number of blocks to infinity: <math>SpeedUp = \left ( \frac{p\centerdot b}{p + (b-p)} \right )=>\lim (b\Rightarrow\infty)(\frac{p}{\frac{p}{b}+1-\frac{p}{b}}) = p</math>

This means that as long as there are enough blocks to be processed, the entire chain's performance will be abound-bounded to the number of nodes in the pipeline.

For illustration purposes, the variation of block processing times was not considered in the above calculations. To see the power of pipeline parallelism, the automobile manufacturing processes illustrate a similar situation. The Hyundai Motor Company's production pipelines can produce 3,835 vehicles per day and 1.4M per year<ref>https://en.wikipedia.org/wiki/List_of_Hyundai_Motor_Company_manufacturing_facilities</ref>.

== Toichain Tokens ==
Toichain token is TOIN. There are 50,000,000,000 TOINs for the Alpha Release. There are air-drop tokens for early adopters, 1,000 TOIN each. Users need to register to download a toichain wallet to receive the payment. Citizenship is checked and verified to ensure that US citizens do not apply. The minimal staking contract is 10 TOINs.

== Non-Fungible Tokens ==
The TestNet Release of toichain protocol will support embedding arbitrary data in an "OP_RETURN" transaction that will be permanently recorded on the chain. Unlike the ordinal NFT <ref>https://blog.chain.link/ordinals-bitcoin-nfts/</ref> or NFT (non-fungible token) on other chains, these transactions cannot be altered or removed.

There are practical applications for these forever NFTs. Once Taproot is enabled on toichain, ordinal NFTs (BRC-20) will also be supported. Unlike the original Bitcoin network where BRC-20 craze has created massive network congestion<ref>https://beincrypto.com/learn/brc-20-token/</ref>, all transactions will be processed promptly in toichain without congestion or scaling problems.
== Toichain TestNet Launch ==
The toichain testnet launch will enable users to interact with one another through simple payments, just like the original Bitcoin network. Forever NFTs are supported. Smart contracts will be supported on a later date.

= References =
<references />

Consult the [[mediawikiwiki:Special:MyLanguage/Help:Contents|User's Guide]] for information on using the wiki software.

Main Page

2023-10-22T22:03:41Z

Justin: /* Welcome to Toi-Twiki -- A Toichain Wiki */

= <strong><big>'''Welcome to Toi-Twiki -- A Toichain Wiki'''</big></strong> =
This is the unofficial Toichain wiki site. Content is subject to changes.
---------------------------

= '''Introduction''' =
The blockchain protocol was introduced in a seminal paper entitled "Bitcoin: A peer-to-peer Electronic Cash System" <ref>https://bitcoin.org/bitcoin.pdf</ref> by Satoshi Nakamoto in 2008. Although there were previous peer-to-peer file-sharing projects such as Napster <ref>https://www.napster.com/us</ref>, BitTorrent <ref>https://www.bittorrent.com/</ref> and other electronic currency/file sharing applications, Bitcoin is the most enduring among the 23,000+ blockchains. Unlike other cryptocurrencies, the Bitcoin is often referred to as "digital gold" since the total coin supply is limited to 21 million (hard-coded in all running programs) and the only way to earn coin is to participate in the transaction block validation process. Token(or coin) supply and their disbursement policies differ among protocols.

The most attractive common blockchain features are 1) a decentralized consensus-driven decision making process and 2) a step-by-step cryptographic proving system. While blockchain is best known as a cryptocurrency transaction processing and record-keeping system, there are many other applications that can benefit from the secure storage, reliable transaction ledgers, fault tolerance and tamper resistance features.

== Algorithm vs. Protocol ==
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 ==
A good consensus protocol in a blockchain system has at least four properties:

# Fault tolerance to defend failures caused by natural disasters and human hacks or accidents
# Byzantine failure tolerance to defend exploitation by colluding parties
# Centralization avoidance to prevent corruptions in the decision making process
# Source code tamper resistance to automatically reject malicious attacks

Without assuming all nodes are active at all times, the blockchain relies on "gossip" protocol to communicate with other nodes. There are two popular types of consensus protocols: Proof of Work ('''PoW''') <ref>https://en.wikipedia.org/wiki/Proof_of_work</ref> or Proof of Stake ('''PoS''') <ref>https://www.investopedia.com/terms/p/proof-stake-pos.asp</ref>. Others include Proof of Possession('''PoP''')<ref>https://identityserver4.readthedocs.io/en/latest/topics/pop.html</ref> and Proof of History('''PoH''')<ref>https://www.infoworld.com/article/3666736/solana-blockchain-and-the-proof-of-history.html</ref>. The ultimate goal is to eliminate double-spending. Since most projects are open source, it's easy for a malicious actor to tamper a few nodes. This shouldn't compromise network integrity.

The Bitcoin network uses PoW which forces participating miners to compete for the fastest hashing rate by solving a computational cryptographic puzzle. Although it withstood more than 14 years of use, Bitcoin has been criticized for escalating electricity consumption <ref>https://www.forbes.com/advisor/investing/cryptocurrency/bitcoins-energy-usage-explained/</ref>. Other blockchain designs have experienced different challenges. For example, the PoH network Solana suffered multiple single-point-failure incidents <ref>https://messari.io/report/solana-analyzing-downtimes-statistics-and-ecosystem-development</ref>. All protocols struggle to combat scaling challenges. All are susceptible to 51% attacks <ref>https://originstamp.com/blog/has-there-ever-been-a-51-attack-on-bitcoin/#notable-51-attacks</ref>.

Since 2009, Bitcoin has proven to be the strongest and least susceptible to common hacks <ref>https://www.theguardian.com/technology/2014/mar/18/history-of-bitcoin-hacks-alternative-currency</ref>. As the PoW puzzle difficulty has increased dramatically over the years, the probability of a 51% attack on the Bitcoin network becomes more difficult. PoS protocols can save more than 90% energy consumption compared to PoW chains. But PoS chains have higher risks than PoW chains since a stolen coin will grow in PoS chains (for increased probability to be selected) forever but not in PoW chains (only hash rates count). PoS community governance rules can mitigate the voting power centralization problem. Staking and slashing policies can incentivize good behaviors and punish bad ones. In either case, double-spend is very expensive and difficult. According to Forbes, there are 80 cryptocurrencies that use PoS protocols at the time of this writing.

There are approximately 1,000 blockchains in four types: public, private, consortium, and permissioned <ref>https://increditools.com/blockchains/</ref>.

== Cryptographic Proofs ==
Bitcoin 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.

== Centralized vs. Decentralized Applications ==
The Bitcoin protocol enabled decentralized processing of traditionally centrally processed transactions without any trusted third-party. It inspired many decentralized financial applications, especially for applications with very long payment chains. However for fraud prevention and meeting financial regulatory requirements, many practical applications still require KYC (know your customer) checks. It is not possible to eliminate all trusted third parties, especially for custodial financial applications. There is a clear need for decentralized processing of trusted authority applications.

== Blockchain Trilemma ==
Blockchain protocols have three common aspects (goals): '''security''', '''decentralization''' and '''scalability''' -- these three terms do not have precise definitions but are intuitively understood <ref>https://sensoriumxr.com/articles/what-is-the-blockchain-trilemma</ref>. To date, 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.

A major shortcoming is scalability. Since all nodes verify each transaction independently, they need to store all the information required for it. As the chain grows, this burdens all nodes in the network. There are workarounds by limiting the amount of data stored on some nodes and exploiting the network to retrieve required information, such as the ''Limited/Light Nodes'' in Bitcoin network. Vast majority nodes are still full nodes in the existing Bitcoin network. Transaction processing speed often expressed ''as transactions per second(TPS) of'' blockchain have to exceed TPS ratings of credit card payment systems like VISA or MasterCard to reap the full benefits of blockchain. This is a tough problem and increasing the block size and/or reducing the block time or difficulty isn't a solution<ref>https://medium.com/coinmonks/blockchain-scaling-30c9e1b7db1b</ref>. Since blockchain TPS is very low, the transaction fees is often very high. This discourages public adoption. Layer 2 solution like ''Lightning Network'' or ''ZK-rollups,'' where only final settlement is on the main chain tend to address these issues. However, one could always argue that this often compromises some aspects of security and/or decentralization to achieve high TPS.

The trilemma was first introduced by Vitalik Buterin<ref>https://en.wikipedia.org/wiki/Vitalik_Buterin</ref>, one of the co-founders of Ethereum network. The problems he identified are real. There seem to be no obvious solutions that can accomplish all three goals at the same time. Therefore, all proposed solutions revolve around reducing "opportunity costs" focusing only on satisfying partial goals.

Treating the blockchain network as an infrastructure for transaction processing, the blockchain protocol solved service reliability problem but not performance challenge. The legacy infrastructure scaling dilemma: performance against reliability remains (where "infrastructure reliability" also does not have a commonly accepted definition). Fortunately these metrics, although important, are non-critical. Solutions that have been proposed have had varying opportunity costs. For many years, there were no obvious solutions that addressed all three blockchain goals (security, decentralization and scalability).
== Statistic Multiplexed Computing (SMC) ==
The principle of using unreliable components to build an arbitrarily reliable system was first lectured by von Neumann in the early 1950s<ref>https://static.ias.edu/pitp/archive/2012files/Probabilistic_Logics.pdf</ref>. The original idea was to use probabilistic logic to quantify the arbitrary reliability of a system by multiplexing all components. This theory was applied to the construction of Internet protocols to deliver the "best effort" reliability. Incidentally, best effort reliability also enabled "best effort" performance which in turn enabled unlimited scalability of the Internet. For emerging web3.0 technologies, it is important to apply the same methodology to both centralized and decentralized computing for seamless technology migration and integration. For historical arguments, click [[SMC|'''''here''''']].

== Definitions ==
'''Infrastructure scalability''' does not have a commonly accepted definition. It helps to define the challenging metrics more precisely before the infrastructure protocol design. In the following, for definitions #1 and #2, the word "'''infrastructure'''" means any '''application running on the infrastructure.'''

# '''Infrastructure Reliability''': MTBF (mean time between failure) = <math>\frac{\sum ((Start-Of-Downtime) - (Start-of-uptime)) }{No-of-failures}</math>
# '''Infrastructure Performance''': <math>\frac{No-of-Transactions}{Second}</math>
# '''Infrastructure Scalability''': Expanding the infrastructure in number of processors, networks or storage should have '''incrementally better''' impacts on application reliability and performance.
# '''Record Immutability''': For transaction ledgers, all confirmed records and changes are final. This is required by the blockchain protocol.
Note that in practice, record immutability is much harder to achieve than expected. There are two challenges, a) 51% attacks can literally wipe out all histories if successful, and b) for protocols require all nodes to hold independently verified ledger, such as the Bitcoin, the storage requirement grows approximately 50GB per month.

== 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 and considered.

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 crashe'''s <ref>https://groups.csail.mit.edu/tds/papers/Lynch/jacm93.pdf</ref>. The laws of physics regarding component reliability <ref>Encyclopedia of Physical Science and Technology, Editor-in-Chief Robert A. Meyers, [[index.php?title=Special:BookSources/9780122274107|ISBN 978-0-12-227410-7]], 2001</ref> show that '''100% component reliability is not possible.''' These facts require that the infrastructure protocol (program-program communication protocol) provide '''complete component (processing, networking and storage) decoupling''' from application program logics. This decoupling requirement forces the protocol to exploit "decentralized" or "stateless" components that the legacy infrastructure protocols, such as message passing interface (MPI), remote procedure call (RPC) and remote method invocation (RMI), cannot handle. The blockchain protocol is an example of a "best effort" availability protocol.

Quantifying infrastructure reliability can be traced back to the computer pioneer von Neumann. In addition to his contribution to computer architecture, von Neumann also penned a study on building reliable systems using unreliable components using probabilistic logics, in early fifties <ref>https://static.ias.edu/pitp/archive/2012files/Probabilistic_Logics.pdf</ref>. The 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 "best effort" reliability. Ironically, this best effort reliability also enabled the Internet's infinite scalability -- the benefit we enjoy now and into the future.

The Bitcoin protocol exploits multiple anonymous decoupled (or decentralized) computers connected through the Internet protocol. Judging from the Bitcoin network's reliability to date <ref>https://buybitcoinworldwide.com/bitcoin-downtime/</ref>, von Neumann's theory seems working well.

The '''second challenge''' involves infrastructure performance. Since the infrastructure must deploy multiple computing, networking and storage components, unless all components can be fully exploited at 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 lack this capability.

'''The infrastructure scalability challenge''' is automatically resolved once the performance challenge is resolved without negatively impacting reliability -- "best effort" performance" meets "best effort reliability". This requires inductive performance and reliability measures or deliveries.

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, an inductive statistic multiplexed blockchain protocol is needed to meet the scalability challenge. Non-inductive solutions such as fixed chain "sharding" or "Danksharding" <ref>https://ethereum.org/en/roadmap/danksharding/</ref> will only increase protocol development complexity with persistent performance walls.

== A Proposed Scalability Solution ==
An effective scalability solution can have two practical assumptions:

* The computation problem size can expand indefinitely, since every useful infrastructure is expected to solve bigger problems.

*Computing and network resources will continue to grow indefinitely, into the future.
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 <ref>https://en.wikipedia.org/wiki/Amdahl%27s_law</ref> and Gustafson's Law <ref>https://en.wikipedia.org/wiki/Gustafson%27s_law</ref>. The problem is that these two "laws" seem to yield complete opposite performance predictions.[[File:Amdahl's Law.png|thumb|Amdahl's Law Speedup Predictions|center]]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.
[[File:Gustafson.png|thumb|Gustafson's Law|center]]
A careful examination revealed that the two laws are mathematically dependent <ref>https://cis.temple.edu/~shi/wwwroot/shi/public_html/docs/amdahl/amdahl.html</ref> where Amdahl's formulation has a tight peak performance bound <math>\left ( \frac{1}{x} \right )</math> 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 <math>\left ( \frac{1}{x} \right )</math>, when <math>x \Rightarrow 0</math>, the performance will asymptotically approach to <math>\infty</math>, when <math>x \Rightarrow 1</math> the speedup <math>\Rightarrow</math> 1. Thus, if the computing problem's size is fixed, x will eventually approach to 1 as the number of processors increases -- economic law of diminishing of return. If the problem size is open (solving bigger problems), then increasing the number of processors will force x <math>\Rightarrow</math> 0, thus speedup <math>\Rightarrow</math> <math>\infty</math>. Gustafson's Law uses a recurrence relation based on practical time measurements. It is not possible to derive a mathematical speedup bound.

Applying these laws in practice need to quantify <math>\chi</math> for practical parallel program which has been proven very hard if not impossible. Gustafson's formula was derived from times by running actual parallel programs. Brining the two formulation together makes quantifying <math>\chi</math> in Amdahl's Law possible. Thus, both law actually refer to the same mathematical abstraction. Gustafson's formula assisted in quantifying the percentage of serial computing through program experiments. Neither should be directly used for speedup prediction alone.

This model can be validated in practice when developers simply increasing the problem size to use more parallel processors.
[[File:1overx-function resized.png|thumb|294x294px|Amdalh's Law and Peak Parallel Performance|center]]

A classical example is the TOP500 supercomputer benchmarks (linear solvers) that have open problem sizes for all manufacturers to compete in the world's fastest supercomputer race <ref>https://www.top500.org/</ref> .
[[File:Supercomputers-history.png|center|thumb]]
In practical blockchain applications, the number of transactions to be processed will increase without a known limit. The ledger storage will continue to grow. In practice, the available computing, networking and storage components will continue to grow without limits enabled by the networking protocols. Therefore a statistic multiplexed computing blockchain can meet any future application needs given proper economic incentives. The infrastructure no longer has the structural deficiency.

== 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.

For Toichain protocol design, we choose Bitcoin 24.0.1 as the base line protocol by replacing the PoW consensus by PoS consensus and injecting SMC components into the protocol processing signaling for parallel computing.

This surprising result is also applicable to ledger storage. Without multiplexing, the blockchain ledger storage will eventually saturate all nodes causing the chain to collapse. The SMC blockchain protocol promises to hold the true finality of all transactions in perpetuity by multiplexing all storage resources while keeping the replication factor to a constant.

These discussions follow the inductive logic of the Law of Large Numbers <ref>https://www.sciencedirect.com/topics/mathematics/laws-of-large-number</ref>.

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

= SMC Proof of Stake Protocol =
Existing PoS protocol designs revolved around staking policies and randomness of the selection algorithm. Considering infrastructure scalability will add much complexity to the design. The examples include chain sharding and Danksharding <ref>https://ethereum.org/en/roadmap/danksharding/</ref>.

The challenge is complex -- we must deliver very high performance without compromising security and reliability of the network.

Technically, transaction replication and parallel processing were considered dangerous <ref>https://pages.cs.wisc.edu/~yxy/cs764-f20/papers/replication.pdf</ref> due to the potential race conditions (or double-spend problem). The blockchain protocol resolved the double-spending problem. It did not solve the parallel processing performance problem.

According to Professor Michael Flynn, there are three high-level parallel processing topologies: SIMD (single instruction multiple data), MIMD (multiple instructions multiple data), and pipeline (MISD - multiple instructions single data stream) <ref>https://link.springer.com/referenceworkentry/10.1007/978-0-387-09766-4_2</ref>. However, for eliminating double-spending, all transactions must be serialized, since each block may contain transactions affecting transactions in multiple other blocks. "Race conditions" and non-deterministic results are not allowed. Then the only possible topology entry is pipeline. This means for POS protocol, we must build a pipeline of transaction blocks to be validated without compromising network security and reliability.
[[File:Flynns-Taxonomy-of-Computer-Architectures.png|center|thumb|Parallel Processing Topologies]]
The problem is that the nature of the blockchain protocol is that all nodes run independently in parallel with little communication with other nodes via "gossip" protocols. It is far easier to force all nodes store the entire ledger than forcing them to form any pipeline and store partial chain data.

=== ACAN (Active Content Addressable Network) [U.S. and Other Patents Pending] ===
ACAN is a high-level data '''''communication and synchronization protocol''''' that completely decouples all hardware components from communicating programs. The need for complete component decoupling was implemented in the original blockchain protocol via "gossip" protocol. This delivered blockchain's high availability and security. The simple "gossip" implementation in existing protocols is insufficient for parallel processing signaling.

The following figure illustrates the concept of ACAN (active content addressable networking) using UVR (unidirectional virtual ring) architecture. The illustrated implementation uses the Tuple Space resource tagging method and gossip protocol for UVR implementation.
[[File:SMC Architecture with ACAN.png|center|thumb|243x243px|SMC Architecture with ACAN]]

ACAN supports three simple APIs:

# '''read'''(&''key'', &''value''): ''key'' holds a search pattern in a "tuple space" where all nodes are connected. ''value'' holds the matched tuple, if any. This is a blocking call that a requesting program will be blocked until a pattern-matched tuple is found. The matching tuple remains in the "tuple space".
# '''get'''(&key, &value): Same as the "read()" API, except that the matching tuple is removed from the "tuple space".
# '''put'''(key, value): Inserts <key, value> into the "tuple space".

The use of "gossip" protocol can accelerate ACAN network saturation time. Applications running on ACAN will automatically form parallel processing topologies: pipeline, SIMD and MIMD without violating the serialization needs of transaction block validation. Replication factor can also be dynamically controlled to spread replicated blocks in randomly chosen hosts.

The highly parallel nature of the blockchain protocol will automatically implement the SMC principle in real time.

The critical feature of this dynamic SMC pipelined architecture is the inductive scaling feature.
[[File:Pipeline Parallel Processing.png|center|thumb|247x247px|Pipeline Parallel Processing]]

The speed up of a pipeline can be represented as: <math>SpeedUp = \left ( \frac{p\centerdot b}{p + (b-p)} \right )</math>, where p = number of processors in the pipeline, b = total blocks to be processed. Take the number of blocks to infinity: <math>SpeedUp = \left ( \frac{p\centerdot b}{p + (b-p)} \right )=>\lim (b\Rightarrow\infty)(\frac{p}{\frac{p}{b}+1-\frac{p}{b}}) = p</math>

This means that as long as there are enough blocks to be processed, the entire chain's performance will be abound-bounded to the number of nodes in the pipeline.

For illustration purposes, the variation of block processing times was not considered in the above calculations. To see the power of pipeline parallelism, the automobile manufacturing processes illustrate a similar situation. The Hyundai Motor Company's production pipelines can produce 3,835 vehicles per day and 1.4M per year<ref>https://en.wikipedia.org/wiki/List_of_Hyundai_Motor_Company_manufacturing_facilities</ref>.

== Toichain Tokens ==
Toichain token is TOIN. There are 50,000,000,000 TOINs for the Alpha Release. There are air-drop tokens for early adopters, 1,000 TOIN each. Users need to register to download a toichain wallet to receive the payment. Citizenship is checked and verified to ensure that US citizens do not apply. The minimal staking contract is 10 TOINs.

== Non-Fungible Tokens ==
The TestNet Release of toichain protocol will support embedding arbitrary data in an "OP_RETURN" transaction that will be permanently recorded on the chain. Unlike the ordinal NFT <ref>https://blog.chain.link/ordinals-bitcoin-nfts/</ref> or NFT (non-fungible token) on other chains, these transactions cannot be altered or removed.

There are practical applications for these forever NFTs. Once Taproot is enabled on toichain, ordinal NFTs (BRC-20) will also be supported. Unlike the original Bitcoin network where BRC-20 craze has created massive network congestion<ref>https://beincrypto.com/learn/brc-20-token/</ref>, all transactions will be processed promptly in toichain without congestion or scaling problems.
== Toichain TestNet Launch ==
The toichain testnet launch will enable users to interact with one another through simple payments, just like the original Bitcoin network. Forever NFTs are supported. Smart contracts will be supported on a later date.

= References =
<references />

Consult the [[mediawikiwiki:Special:MyLanguage/Help:Contents|User's Guide]] for information on using the wiki software.

Main Page

2023-10-22T21:58:43Z

Justin: /* A Proposed Scalability Solution */

= <strong><big>'''Welcome to Toi-Twiki -- A Toichain Wiki'''</big></strong> =
This is the unofficial Toichain wiki site. Content on this site is subject to frequent changes.
---------------------------

= '''Introduction''' =
The blockchain protocol was introduced in a seminal paper entitled "Bitcoin: A peer-to-peer Electronic Cash System" <ref>https://bitcoin.org/bitcoin.pdf</ref> by Satoshi Nakamoto in 2008. Although there were previous peer-to-peer file-sharing projects such as Napster <ref>https://www.napster.com/us</ref>, BitTorrent <ref>https://www.bittorrent.com/</ref> and other electronic currency/file sharing applications, Bitcoin is the most enduring among the 23,000+ blockchains. Unlike other cryptocurrencies, the Bitcoin is often referred to as "digital gold" since the total coin supply is limited to 21 million (hard-coded in all running programs) and the only way to earn coin is to participate in the transaction block validation process. Token(or coin) supply and their disbursement policies differ among protocols.

The most attractive common blockchain features are 1) a decentralized consensus-driven decision making process and 2) a step-by-step cryptographic proving system. While blockchain is best known as a cryptocurrency transaction processing and record-keeping system, there are many other applications that can benefit from the secure storage, reliable transaction ledgers, fault tolerance and tamper resistance features.

== Algorithm vs. Protocol ==
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 ==
A good consensus protocol in a blockchain system has at least four properties:

# Fault tolerance to defend failures caused by natural disasters and human hacks or accidents
# Byzantine failure tolerance to defend exploitation by colluding parties
# Centralization avoidance to prevent corruptions in the decision making process
# Source code tamper resistance to automatically reject malicious attacks

Without assuming all nodes are active at all times, the blockchain relies on "gossip" protocol to communicate with other nodes. There are two popular types of consensus protocols: Proof of Work ('''PoW''') <ref>https://en.wikipedia.org/wiki/Proof_of_work</ref> or Proof of Stake ('''PoS''') <ref>https://www.investopedia.com/terms/p/proof-stake-pos.asp</ref>. Others include Proof of Possession('''PoP''')<ref>https://identityserver4.readthedocs.io/en/latest/topics/pop.html</ref> and Proof of History('''PoH''')<ref>https://www.infoworld.com/article/3666736/solana-blockchain-and-the-proof-of-history.html</ref>. The ultimate goal is to eliminate double-spending. Since most projects are open source, it's easy for a malicious actor to tamper a few nodes. This shouldn't compromise network integrity.

The Bitcoin network uses PoW which forces participating miners to compete for the fastest hashing rate by solving a computational cryptographic puzzle. Although it withstood more than 14 years of use, Bitcoin has been criticized for escalating electricity consumption <ref>https://www.forbes.com/advisor/investing/cryptocurrency/bitcoins-energy-usage-explained/</ref>. Other blockchain designs have experienced different challenges. For example, the PoH network Solana suffered multiple single-point-failure incidents <ref>https://messari.io/report/solana-analyzing-downtimes-statistics-and-ecosystem-development</ref>. All protocols struggle to combat scaling challenges. All are susceptible to 51% attacks <ref>https://originstamp.com/blog/has-there-ever-been-a-51-attack-on-bitcoin/#notable-51-attacks</ref>.

Since 2009, Bitcoin has proven to be the strongest and least susceptible to common hacks <ref>https://www.theguardian.com/technology/2014/mar/18/history-of-bitcoin-hacks-alternative-currency</ref>. As the PoW puzzle difficulty has increased dramatically over the years, the probability of a 51% attack on the Bitcoin network becomes more difficult. PoS protocols can save more than 90% energy consumption compared to PoW chains. But PoS chains have higher risks than PoW chains since a stolen coin will grow in PoS chains (for increased probability to be selected) forever but not in PoW chains (only hash rates count). PoS community governance rules can mitigate the voting power centralization problem. Staking and slashing policies can incentivize good behaviors and punish bad ones. In either case, double-spend is very expensive and difficult. According to Forbes, there are 80 cryptocurrencies that use PoS protocols at the time of this writing.

There are approximately 1,000 blockchains in four types: public, private, consortium, and permissioned <ref>https://increditools.com/blockchains/</ref>.

== Cryptographic Proofs ==
Bitcoin 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.

== Centralized vs. Decentralized Applications ==
The Bitcoin protocol enabled decentralized processing of traditionally centrally processed transactions without any trusted third-party. It inspired many decentralized financial applications, especially for applications with very long payment chains. However for fraud prevention and meeting financial regulatory requirements, many practical applications still require KYC (know your customer) checks. It is not possible to eliminate all trusted third parties, especially for custodial financial applications. There is a clear need for decentralized processing of trusted authority applications.

== Blockchain Trilemma ==
Blockchain protocols have three common aspects (goals): '''security''', '''decentralization''' and '''scalability''' -- these three terms do not have precise definitions but are intuitively understood <ref>https://sensoriumxr.com/articles/what-is-the-blockchain-trilemma</ref>. To date, 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.

A major shortcoming is scalability. Since all nodes verify each transaction independently, they need to store all the information required for it. As the chain grows, this burdens all nodes in the network. There are workarounds by limiting the amount of data stored on some nodes and exploiting the network to retrieve required information, such as the ''Limited/Light Nodes'' in Bitcoin network. Vast majority nodes are still full nodes in the existing Bitcoin network. Transaction processing speed often expressed ''as transactions per second(TPS) of'' blockchain have to exceed TPS ratings of credit card payment systems like VISA or MasterCard to reap the full benefits of blockchain. This is a tough problem and increasing the block size and/or reducing the block time or difficulty isn't a solution<ref>https://medium.com/coinmonks/blockchain-scaling-30c9e1b7db1b</ref>. Since blockchain TPS is very low, the transaction fees is often very high. This discourages public adoption. Layer 2 solution like ''Lightning Network'' or ''ZK-rollups,'' where only final settlement is on the main chain tend to address these issues. However, one could always argue that this often compromises some aspects of security and/or decentralization to achieve high TPS.

The trilemma was first introduced by Vitalik Buterin<ref>https://en.wikipedia.org/wiki/Vitalik_Buterin</ref>, one of the co-founders of Ethereum network. The problems he identified are real. There seem to be no obvious solutions that can accomplish all three goals at the same time. Therefore, all proposed solutions revolve around reducing "opportunity costs" focusing only on satisfying partial goals.

Treating the blockchain network as an infrastructure for transaction processing, the blockchain protocol solved service reliability problem but not performance challenge. The legacy infrastructure scaling dilemma: performance against reliability remains (where "infrastructure reliability" also does not have a commonly accepted definition). Fortunately these metrics, although important, are non-critical. Solutions that have been proposed have had varying opportunity costs. For many years, there were no obvious solutions that addressed all three blockchain goals (security, decentralization and scalability).
== Statistic Multiplexed Computing (SMC) ==
The principle of using unreliable components to build an arbitrarily reliable system was first lectured by von Neumann in the early 1950s<ref>https://static.ias.edu/pitp/archive/2012files/Probabilistic_Logics.pdf</ref>. The original idea was to use probabilistic logic to quantify the arbitrary reliability of a system by multiplexing all components. This theory was applied to the construction of Internet protocols to deliver the "best effort" reliability. Incidentally, best effort reliability also enabled "best effort" performance which in turn enabled unlimited scalability of the Internet. For emerging web3.0 technologies, it is important to apply the same methodology to both centralized and decentralized computing for seamless technology migration and integration. For historical arguments, click [[SMC|'''''here''''']].

== Definitions ==
'''Infrastructure scalability''' does not have a commonly accepted definition. It helps to define the challenging metrics more precisely before the infrastructure protocol design. In the following, for definitions #1 and #2, the word "'''infrastructure'''" means any '''application running on the infrastructure.'''

# '''Infrastructure Reliability''': MTBF (mean time between failure) = <math>\frac{\sum ((Start-Of-Downtime) - (Start-of-uptime)) }{No-of-failures}</math>
# '''Infrastructure Performance''': <math>\frac{No-of-Transactions}{Second}</math>
# '''Infrastructure Scalability''': Expanding the infrastructure in number of processors, networks or storage should have '''incrementally better''' impacts on application reliability and performance.
# '''Record Immutability''': For transaction ledgers, all confirmed records and changes are final. This is required by the blockchain protocol.
Note that in practice, record immutability is much harder to achieve than expected. There are two challenges, a) 51% attacks can literally wipe out all histories if successful, and b) for protocols require all nodes to hold independently verified ledger, such as the Bitcoin, the storage requirement grows approximately 50GB per month.

== 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 and considered.

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 crashe'''s <ref>https://groups.csail.mit.edu/tds/papers/Lynch/jacm93.pdf</ref>. The laws of physics regarding component reliability <ref>Encyclopedia of Physical Science and Technology, Editor-in-Chief Robert A. Meyers, [[index.php?title=Special:BookSources/9780122274107|ISBN 978-0-12-227410-7]], 2001</ref> show that '''100% component reliability is not possible.''' These facts require that the infrastructure protocol (program-program communication protocol) provide '''complete component (processing, networking and storage) decoupling''' from application program logics. This decoupling requirement forces the protocol to exploit "decentralized" or "stateless" components that the legacy infrastructure protocols, such as message passing interface (MPI), remote procedure call (RPC) and remote method invocation (RMI), cannot handle. The blockchain protocol is an example of a "best effort" availability protocol.

Quantifying infrastructure reliability can be traced back to the computer pioneer von Neumann. In addition to his contribution to computer architecture, von Neumann also penned a study on building reliable systems using unreliable components using probabilistic logics, in early fifties <ref>https://static.ias.edu/pitp/archive/2012files/Probabilistic_Logics.pdf</ref>. The 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 "best effort" reliability. Ironically, this best effort reliability also enabled the Internet's infinite scalability -- the benefit we enjoy now and into the future.

The Bitcoin protocol exploits multiple anonymous decoupled (or decentralized) computers connected through the Internet protocol. Judging from the Bitcoin network's reliability to date <ref>https://buybitcoinworldwide.com/bitcoin-downtime/</ref>, von Neumann's theory seems working well.

The '''second challenge''' involves infrastructure performance. Since the infrastructure must deploy multiple computing, networking and storage components, unless all components can be fully exploited at 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 lack this capability.

'''The infrastructure scalability challenge''' is automatically resolved once the performance challenge is resolved without negatively impacting reliability -- "best effort" performance" meets "best effort reliability". This requires inductive performance and reliability measures or deliveries.

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, an inductive statistic multiplexed blockchain protocol is needed to meet the scalability challenge. Non-inductive solutions such as fixed chain "sharding" or "Danksharding" <ref>https://ethereum.org/en/roadmap/danksharding/</ref> will only increase protocol development complexity with persistent performance walls.

== A Proposed Scalability Solution ==
An effective scalability solution can have two practical assumptions:

* The computation problem size can expand indefinitely, since every useful infrastructure is expected to solve bigger problems.

*Computing and network resources will continue to grow indefinitely, into the future.
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 <ref>https://en.wikipedia.org/wiki/Amdahl%27s_law</ref> and Gustafson's Law <ref>https://en.wikipedia.org/wiki/Gustafson%27s_law</ref>. The problem is that these two "laws" seem to yield complete opposite performance predictions.[[File:Amdahl's Law.png|thumb|Amdahl's Law Speedup Predictions|center]]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.
[[File:Gustafson.png|thumb|Gustafson's Law|center]]
A careful examination revealed that the two laws are mathematically dependent <ref>https://cis.temple.edu/~shi/wwwroot/shi/public_html/docs/amdahl/amdahl.html</ref> where Amdahl's formulation has a tight peak performance bound <math>\left ( \frac{1}{x} \right )</math> 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 <math>\left ( \frac{1}{x} \right )</math>, when <math>x \Rightarrow 0</math>, the performance will asymptotically approach to <math>\infty</math>, when <math>x \Rightarrow 1</math> the speedup <math>\Rightarrow</math> 1. Thus, if the computing problem's size is fixed, x will eventually approach to 1 as the number of processors increases -- economic law of diminishing of return. If the problem size is open (solving bigger problems), then increasing the number of processors will force x <math>\Rightarrow</math> 0, thus speedup <math>\Rightarrow</math> <math>\infty</math>. Gustafson's Law uses a recurrence relation based on practical time measurements. It is not possible to derive a mathematical speedup bound.

Applying these laws in practice need to quantify <math>\chi</math> for practical parallel program which has been proven very hard if not impossible. Gustafson's formula was derived from times by running actual parallel programs. Brining the two formulation together makes quantifying <math>\chi</math> in Amdahl's Law possible. Thus, both law actually refer to the same mathematical abstraction. Gustafson's formula assisted in quantifying the percentage of serial computing through program experiments. Neither should be directly used for speedup prediction alone.

This model can be validated in practice when developers simply increasing the problem size to use more parallel processors.
[[File:1overx-function resized.png|thumb|294x294px|Amdalh's Law and Peak Parallel Performance|center]]

A classical example is the TOP500 supercomputer benchmarks (linear solvers) that have open problem sizes for all manufacturers to compete in the world's fastest supercomputer race <ref>https://www.top500.org/</ref> .
[[File:Supercomputers-history.png|center|thumb]]
In practical blockchain applications, the number of transactions to be processed will increase without a known limit. The ledger storage will continue to grow. In practice, the available computing, networking and storage components will continue to grow without limits enabled by the networking protocols. Therefore a statistic multiplexed computing blockchain can meet any future application needs given proper economic incentives. The infrastructure no longer has the structural deficiency.

== 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.

For Toichain protocol design, we choose Bitcoin 24.0.1 as the base line protocol by replacing the PoW consensus by PoS consensus and injecting SMC components into the protocol processing signaling for parallel computing.

This surprising result is also applicable to ledger storage. Without multiplexing, the blockchain ledger storage will eventually saturate all nodes causing the chain to collapse. The SMC blockchain protocol promises to hold the true finality of all transactions in perpetuity by multiplexing all storage resources while keeping the replication factor to a constant.

These discussions follow the inductive logic of the Law of Large Numbers <ref>https://www.sciencedirect.com/topics/mathematics/laws-of-large-number</ref>.

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

= SMC Proof of Stake Protocol =
Existing PoS protocol designs revolved around staking policies and randomness of the selection algorithm. Considering infrastructure scalability will add much complexity to the design. The examples include chain sharding and Danksharding <ref>https://ethereum.org/en/roadmap/danksharding/</ref>.

The challenge is complex -- we must deliver very high performance without compromising security and reliability of the network.

Technically, transaction replication and parallel processing were considered dangerous <ref>https://pages.cs.wisc.edu/~yxy/cs764-f20/papers/replication.pdf</ref> due to the potential race conditions (or double-spend problem). The blockchain protocol resolved the double-spending problem. It did not solve the parallel processing performance problem.

According to Professor Michael Flynn, there are three high-level parallel processing topologies: SIMD (single instruction multiple data), MIMD (multiple instructions multiple data), and pipeline (MISD - multiple instructions single data stream) <ref>https://link.springer.com/referenceworkentry/10.1007/978-0-387-09766-4_2</ref>. However, for eliminating double-spending, all transactions must be serialized, since each block may contain transactions affecting transactions in multiple other blocks. "Race conditions" and non-deterministic results are not allowed. Then the only possible topology entry is pipeline. This means for POS protocol, we must build a pipeline of transaction blocks to be validated without compromising network security and reliability.
[[File:Flynns-Taxonomy-of-Computer-Architectures.png|center|thumb|Parallel Processing Topologies]]
The problem is that the nature of the blockchain protocol is that all nodes run independently in parallel with little communication with other nodes via "gossip" protocols. It is far easier to force all nodes store the entire ledger than forcing them to form any pipeline and store partial chain data.

=== ACAN (Active Content Addressable Network) [U.S. and Other Patents Pending] ===
ACAN is a high-level data '''''communication and synchronization protocol''''' that completely decouples all hardware components from communicating programs. The need for complete component decoupling was implemented in the original blockchain protocol via "gossip" protocol. This delivered blockchain's high availability and security. The simple "gossip" implementation in existing protocols is insufficient for parallel processing signaling.

The following figure illustrates the concept of ACAN (active content addressable networking) using UVR (unidirectional virtual ring) architecture. The illustrated implementation uses the Tuple Space resource tagging method and gossip protocol for UVR implementation.
[[File:SMC Architecture with ACAN.png|center|thumb|243x243px|SMC Architecture with ACAN]]

ACAN supports three simple APIs:

# '''read'''(&''key'', &''value''): ''key'' holds a search pattern in a "tuple space" where all nodes are connected. ''value'' holds the matched tuple, if any. This is a blocking call that a requesting program will be blocked until a pattern-matched tuple is found. The matching tuple remains in the "tuple space".
# '''get'''(&key, &value): Same as the "read()" API, except that the matching tuple is removed from the "tuple space".
# '''put'''(key, value): Inserts <key, value> into the "tuple space".

The use of "gossip" protocol can accelerate ACAN network saturation time. Applications running on ACAN will automatically form parallel processing topologies: pipeline, SIMD and MIMD without violating the serialization needs of transaction block validation. Replication factor can also be dynamically controlled to spread replicated blocks in randomly chosen hosts.

The highly parallel nature of the blockchain protocol will automatically implement the SMC principle in real time.

The critical feature of this dynamic SMC pipelined architecture is the inductive scaling feature.
[[File:Pipeline Parallel Processing.png|center|thumb|247x247px|Pipeline Parallel Processing]]

The speed up of a pipeline can be represented as: <math>SpeedUp = \left ( \frac{p\centerdot b}{p + (b-p)} \right )</math>, where p = number of processors in the pipeline, b = total blocks to be processed. Take the number of blocks to infinity: <math>SpeedUp = \left ( \frac{p\centerdot b}{p + (b-p)} \right )=>\lim (b\Rightarrow\infty)(\frac{p}{\frac{p}{b}+1-\frac{p}{b}}) = p</math>

This means that as long as there are enough blocks to be processed, the entire chain's performance will be abound-bounded to the number of nodes in the pipeline.

For illustration purposes, the variation of block processing times was not considered in the above calculations. To see the power of pipeline parallelism, the automobile manufacturing processes illustrate a similar situation. The Hyundai Motor Company's production pipelines can produce 3,835 vehicles per day and 1.4M per year<ref>https://en.wikipedia.org/wiki/List_of_Hyundai_Motor_Company_manufacturing_facilities</ref>.

== Toichain Tokens ==
Toichain token is TOIN. There are 50,000,000,000 TOINs for the Alpha Release. There are air-drop tokens for early adopters, 1,000 TOIN each. Users need to register to download a toichain wallet to receive the payment. Citizenship is checked and verified to ensure that US citizens do not apply. The minimal staking contract is 10 TOINs.

== Non-Fungible Tokens ==
The TestNet Release of toichain protocol will support embedding arbitrary data in an "OP_RETURN" transaction that will be permanently recorded on the chain. Unlike the ordinal NFT <ref>https://blog.chain.link/ordinals-bitcoin-nfts/</ref> or NFT (non-fungible token) on other chains, these transactions cannot be altered or removed.

There are practical applications for these forever NFTs. Once Taproot is enabled on toichain, ordinal NFTs (BRC-20) will also be supported. Unlike the original Bitcoin network where BRC-20 craze has created massive network congestion<ref>https://beincrypto.com/learn/brc-20-token/</ref>, all transactions will be processed promptly in toichain without congestion or scaling problems.
== Toichain TestNet Launch ==
The toichain testnet launch will enable users to interact with one another through simple payments, just like the original Bitcoin network. Forever NFTs are supported. Smart contracts will be supported on a later date.

= References =
<references />

Consult the [[mediawikiwiki:Special:MyLanguage/Help:Contents|User's Guide]] for information on using the wiki software.

Main Page

2023-10-22T21:52:42Z

Justin: /* A Proposed Scalability Solution */

= <strong><big>'''Welcome to Toi-Twiki -- A Toichain Wiki'''</big></strong> =
This is the unofficial Toichain wiki site. Content on this site is subject to frequent changes.
---------------------------

= '''Introduction''' =
The blockchain protocol was introduced in a seminal paper entitled "Bitcoin: A peer-to-peer Electronic Cash System" <ref>https://bitcoin.org/bitcoin.pdf</ref> by Satoshi Nakamoto in 2008. Although there were previous peer-to-peer file-sharing projects such as Napster <ref>https://www.napster.com/us</ref>, BitTorrent <ref>https://www.bittorrent.com/</ref> and other electronic currency/file sharing applications, Bitcoin is the most enduring among the 23,000+ blockchains. Unlike other cryptocurrencies, the Bitcoin is often referred to as "digital gold" since the total coin supply is limited to 21 million (hard-coded in all running programs) and the only way to earn coin is to participate in the transaction block validation process. Token(or coin) supply and their disbursement policies differ among protocols.

The most attractive common blockchain features are 1) a decentralized consensus-driven decision making process and 2) a step-by-step cryptographic proving system. While blockchain is best known as a cryptocurrency transaction processing and record-keeping system, there are many other applications that can benefit from the secure storage, reliable transaction ledgers, fault tolerance and tamper resistance features.

== Algorithm vs. Protocol ==
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 ==
A good consensus protocol in a blockchain system has at least four properties:

# Fault tolerance to defend failures caused by natural disasters and human hacks or accidents
# Byzantine failure tolerance to defend exploitation by colluding parties
# Centralization avoidance to prevent corruptions in the decision making process
# Source code tamper resistance to automatically reject malicious attacks

Without assuming all nodes are active at all times, the blockchain relies on "gossip" protocol to communicate with other nodes. There are two popular types of consensus protocols: Proof of Work ('''PoW''') <ref>https://en.wikipedia.org/wiki/Proof_of_work</ref> or Proof of Stake ('''PoS''') <ref>https://www.investopedia.com/terms/p/proof-stake-pos.asp</ref>. Others include Proof of Possession('''PoP''')<ref>https://identityserver4.readthedocs.io/en/latest/topics/pop.html</ref> and Proof of History('''PoH''')<ref>https://www.infoworld.com/article/3666736/solana-blockchain-and-the-proof-of-history.html</ref>. The ultimate goal is to eliminate double-spending. Since most projects are open source, it's easy for a malicious actor to tamper a few nodes. This shouldn't compromise network integrity.

The Bitcoin network uses PoW which forces participating miners to compete for the fastest hashing rate by solving a computational cryptographic puzzle. Although it withstood more than 14 years of use, Bitcoin has been criticized for escalating electricity consumption <ref>https://www.forbes.com/advisor/investing/cryptocurrency/bitcoins-energy-usage-explained/</ref>. Other blockchain designs have experienced different challenges. For example, the PoH network Solana suffered multiple single-point-failure incidents <ref>https://messari.io/report/solana-analyzing-downtimes-statistics-and-ecosystem-development</ref>. All protocols struggle to combat scaling challenges. All are susceptible to 51% attacks <ref>https://originstamp.com/blog/has-there-ever-been-a-51-attack-on-bitcoin/#notable-51-attacks</ref>.

Since 2009, Bitcoin has proven to be the strongest and least susceptible to common hacks <ref>https://www.theguardian.com/technology/2014/mar/18/history-of-bitcoin-hacks-alternative-currency</ref>. As the PoW puzzle difficulty has increased dramatically over the years, the probability of a 51% attack on the Bitcoin network becomes more difficult. PoS protocols can save more than 90% energy consumption compared to PoW chains. But PoS chains have higher risks than PoW chains since a stolen coin will grow in PoS chains (for increased probability to be selected) forever but not in PoW chains (only hash rates count). PoS community governance rules can mitigate the voting power centralization problem. Staking and slashing policies can incentivize good behaviors and punish bad ones. In either case, double-spend is very expensive and difficult. According to Forbes, there are 80 cryptocurrencies that use PoS protocols at the time of this writing.

There are approximately 1,000 blockchains in four types: public, private, consortium, and permissioned <ref>https://increditools.com/blockchains/</ref>.

== Cryptographic Proofs ==
Bitcoin 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.

== Centralized vs. Decentralized Applications ==
The Bitcoin protocol enabled decentralized processing of traditionally centrally processed transactions without any trusted third-party. It inspired many decentralized financial applications, especially for applications with very long payment chains. However for fraud prevention and meeting financial regulatory requirements, many practical applications still require KYC (know your customer) checks. It is not possible to eliminate all trusted third parties, especially for custodial financial applications. There is a clear need for decentralized processing of trusted authority applications.

== Blockchain Trilemma ==
Blockchain protocols have three common aspects (goals): '''security''', '''decentralization''' and '''scalability''' -- these three terms do not have precise definitions but are intuitively understood <ref>https://sensoriumxr.com/articles/what-is-the-blockchain-trilemma</ref>. To date, 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.

A major shortcoming is scalability. Since all nodes verify each transaction independently, they need to store all the information required for it. As the chain grows, this burdens all nodes in the network. There are workarounds by limiting the amount of data stored on some nodes and exploiting the network to retrieve required information, such as the ''Limited/Light Nodes'' in Bitcoin network. Vast majority nodes are still full nodes in the existing Bitcoin network. Transaction processing speed often expressed ''as transactions per second(TPS) of'' blockchain have to exceed TPS ratings of credit card payment systems like VISA or MasterCard to reap the full benefits of blockchain. This is a tough problem and increasing the block size and/or reducing the block time or difficulty isn't a solution<ref>https://medium.com/coinmonks/blockchain-scaling-30c9e1b7db1b</ref>. Since blockchain TPS is very low, the transaction fees is often very high. This discourages public adoption. Layer 2 solution like ''Lightning Network'' or ''ZK-rollups,'' where only final settlement is on the main chain tend to address these issues. However, one could always argue that this often compromises some aspects of security and/or decentralization to achieve high TPS.

The trilemma was first introduced by Vitalik Buterin<ref>https://en.wikipedia.org/wiki/Vitalik_Buterin</ref>, one of the co-founders of Ethereum network. The problems he identified are real. There seem to be no obvious solutions that can accomplish all three goals at the same time. Therefore, all proposed solutions revolve around reducing "opportunity costs" focusing only on satisfying partial goals.

Treating the blockchain network as an infrastructure for transaction processing, the blockchain protocol solved service reliability problem but not performance challenge. The legacy infrastructure scaling dilemma: performance against reliability remains (where "infrastructure reliability" also does not have a commonly accepted definition). Fortunately these metrics, although important, are non-critical. Solutions that have been proposed have had varying opportunity costs. For many years, there were no obvious solutions that addressed all three blockchain goals (security, decentralization and scalability).
== Statistic Multiplexed Computing (SMC) ==
The principle of using unreliable components to build an arbitrarily reliable system was first lectured by von Neumann in the early 1950s<ref>https://static.ias.edu/pitp/archive/2012files/Probabilistic_Logics.pdf</ref>. The original idea was to use probabilistic logic to quantify the arbitrary reliability of a system by multiplexing all components. This theory was applied to the construction of Internet protocols to deliver the "best effort" reliability. Incidentally, best effort reliability also enabled "best effort" performance which in turn enabled unlimited scalability of the Internet. For emerging web3.0 technologies, it is important to apply the same methodology to both centralized and decentralized computing for seamless technology migration and integration. For historical arguments, click [[SMC|'''''here''''']].

== Definitions ==
'''Infrastructure scalability''' does not have a commonly accepted definition. It helps to define the challenging metrics more precisely before the infrastructure protocol design. In the following, for definitions #1 and #2, the word "'''infrastructure'''" means any '''application running on the infrastructure.'''

# '''Infrastructure Reliability''': MTBF (mean time between failure) = <math>\frac{\sum ((Start-Of-Downtime) - (Start-of-uptime)) }{No-of-failures}</math>
# '''Infrastructure Performance''': <math>\frac{No-of-Transactions}{Second}</math>
# '''Infrastructure Scalability''': Expanding the infrastructure in number of processors, networks or storage should have '''incrementally better''' impacts on application reliability and performance.
# '''Record Immutability''': For transaction ledgers, all confirmed records and changes are final. This is required by the blockchain protocol.
Note that in practice, record immutability is much harder to achieve than expected. There are two challenges, a) 51% attacks can literally wipe out all histories if successful, and b) for protocols require all nodes to hold independently verified ledger, such as the Bitcoin, the storage requirement grows approximately 50GB per month.

== 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 and considered.

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 crashe'''s <ref>https://groups.csail.mit.edu/tds/papers/Lynch/jacm93.pdf</ref>. The laws of physics regarding component reliability <ref>Encyclopedia of Physical Science and Technology, Editor-in-Chief Robert A. Meyers, [[index.php?title=Special:BookSources/9780122274107|ISBN 978-0-12-227410-7]], 2001</ref> show that '''100% component reliability is not possible.''' These facts require that the infrastructure protocol (program-program communication protocol) provide '''complete component (processing, networking and storage) decoupling''' from application program logics. This decoupling requirement forces the protocol to exploit "decentralized" or "stateless" components that the legacy infrastructure protocols, such as message passing interface (MPI), remote procedure call (RPC) and remote method invocation (RMI), cannot handle. The blockchain protocol is an example of a "best effort" availability protocol.

Quantifying infrastructure reliability can be traced back to the computer pioneer von Neumann. In addition to his contribution to computer architecture, von Neumann also penned a study on building reliable systems using unreliable components using probabilistic logics, in early fifties <ref>https://static.ias.edu/pitp/archive/2012files/Probabilistic_Logics.pdf</ref>. The 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 "best effort" reliability. Ironically, this best effort reliability also enabled the Internet's infinite scalability -- the benefit we enjoy now and into the future.

The Bitcoin protocol exploits multiple anonymous decoupled (or decentralized) computers connected through the Internet protocol. Judging from the Bitcoin network's reliability to date <ref>https://buybitcoinworldwide.com/bitcoin-downtime/</ref>, von Neumann's theory seems working well.

The '''second challenge''' involves infrastructure performance. Since the infrastructure must deploy multiple computing, networking and storage components, unless all components can be fully exploited at 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 lack this capability.

'''The infrastructure scalability challenge''' is automatically resolved once the performance challenge is resolved without negatively impacting reliability -- "best effort" performance" meets "best effort reliability". This requires inductive performance and reliability measures or deliveries.

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, an inductive statistic multiplexed blockchain protocol is needed to meet the scalability challenge. Non-inductive solutions such as fixed chain "sharding" or "Danksharding" <ref>https://ethereum.org/en/roadmap/danksharding/</ref> will only increase protocol development complexity with persistent performance walls.

== A Proposed Scalability Solution ==
An effective scalability solution can have two practical assumptions:

* The computation problem size can expand indefinitely, since every useful infrastructure is expected to solve bigger problems.

*Computing and network resources will continue to grow indefinitely, into the future.
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 <ref>https://en.wikipedia.org/wiki/Amdahl%27s_law</ref> and Gustafson's Law <ref>https://en.wikipedia.org/wiki/Gustafson%27s_law</ref>. The problem is that these two "laws" seem to yield complete opposite performance predictions.[[File:Amdahl's Law.png|thumb|Amdahl's Law Speedup Predictions|center]]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.
[[File:Gustafson.png|thumb|Gustafson's Law|center]]
A careful examination revealed that the two laws are mathematically dependent <ref>https://cis.temple.edu/~shi/wwwroot/shi/public_html/docs/amdahl/amdahl.html</ref> where Amdahl's formulation has a tight peak performance bound <math>\left ( \frac{1}{x} \right )</math> 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 <math>\left ( \frac{1}{x} \right )</math>, when <math>x \Rightarrow 0</math>, the performance will asymptotically approach to <math>\infty</math>, when <math>x \Rightarrow 1</math> the speedup <math>\Rightarrow</math> 1. Thus, if the computing problem's size is fixed, x will eventually approach to 1 as the number of processors increases -- economic law of diminishing of return. If the problem size is open (solving bigger problems), then increasing the number of processors will force x <math>\Rightarrow</math> 0, thus speedup <math>\Rightarrow</math> <math>\infty</math>. Gustafson's Law uses a recurrence relation based on practical time measurements. It is not possible to derive a mathematical speedup bound.

Applying these laws in practice need to quantify <math>\chi</math> for practical parallel program which has been proven very hard if not impossible. Gustafson's formula was derived from times by running actual parallel programs. Brining the two formulation together makes quantifying <math>\chi</math> in Amdahl's Law possible. Thus, both law actually refer to the same mathematical abstraction. Gustafson's formula assisted in quantifying the percentage of serial computing through program experiments. Neither should be directly used for speedup prediction alone.

This model can be validated in practice when developers simply increasing the problem size to use more parallel processors.
[[File:1overx-function resized.png|thumb|294x294px|Amdalh's Law and Peak Parallel Performance|center]]

A classical example is the TOP500 supercomputer benchmarks (linear solvers) that have open problem sizes for all manufacturers to compete in the world's fastest supercomputer race <ref>https://www.top500.org/</ref> .
[[File:Supercomputers-history.png|center|thumb]]
In practical blockchain applications, the number of transactions to be processed will increase until it satisfies all possible requests. The ledger storage will continue to grow. In practice, the available computing, networking and storage components will continue to grow without limits enabled by the networking protocols. Therefore a statistic multiplexed computing blockchain can meet any future application needs given proper economic incentives. The infrastructure no longer has the structural deficiency.

== 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.

For Toichain protocol design, we choose Bitcoin 24.0.1 as the base line protocol by replacing the PoW consensus by PoS consensus and injecting SMC components into the protocol processing signaling for parallel computing.

This surprising result is also applicable to ledger storage. Without multiplexing, the blockchain ledger storage will eventually saturate all nodes causing the chain to collapse. The SMC blockchain protocol promises to hold the true finality of all transactions in perpetuity by multiplexing all storage resources while keeping the replication factor to a constant.

These discussions follow the inductive logic of the Law of Large Numbers <ref>https://www.sciencedirect.com/topics/mathematics/laws-of-large-number</ref>.

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

= SMC Proof of Stake Protocol =
Existing PoS protocol designs revolved around staking policies and randomness of the selection algorithm. Considering infrastructure scalability will add much complexity to the design. The examples include chain sharding and Danksharding <ref>https://ethereum.org/en/roadmap/danksharding/</ref>.

The challenge is complex -- we must deliver very high performance without compromising security and reliability of the network.

Technically, transaction replication and parallel processing were considered dangerous <ref>https://pages.cs.wisc.edu/~yxy/cs764-f20/papers/replication.pdf</ref> due to the potential race conditions (or double-spend problem). The blockchain protocol resolved the double-spending problem. It did not solve the parallel processing performance problem.

According to Professor Michael Flynn, there are three high-level parallel processing topologies: SIMD (single instruction multiple data), MIMD (multiple instructions multiple data), and pipeline (MISD - multiple instructions single data stream) <ref>https://link.springer.com/referenceworkentry/10.1007/978-0-387-09766-4_2</ref>. However, for eliminating double-spending, all transactions must be serialized, since each block may contain transactions affecting transactions in multiple other blocks. "Race conditions" and non-deterministic results are not allowed. Then the only possible topology entry is pipeline. This means for POS protocol, we must build a pipeline of transaction blocks to be validated without compromising network security and reliability.
[[File:Flynns-Taxonomy-of-Computer-Architectures.png|center|thumb|Parallel Processing Topologies]]
The problem is that the nature of the blockchain protocol is that all nodes run independently in parallel with little communication with other nodes via "gossip" protocols. It is far easier to force all nodes store the entire ledger than forcing them to form any pipeline and store partial chain data.

=== ACAN (Active Content Addressable Network) [U.S. and Other Patents Pending] ===
ACAN is a high-level data '''''communication and synchronization protocol''''' that completely decouples all hardware components from communicating programs. The need for complete component decoupling was implemented in the original blockchain protocol via "gossip" protocol. This delivered blockchain's high availability and security. The simple "gossip" implementation in existing protocols is insufficient for parallel processing signaling.

The following figure illustrates the concept of ACAN (active content addressable networking) using UVR (unidirectional virtual ring) architecture. The illustrated implementation uses the Tuple Space resource tagging method and gossip protocol for UVR implementation.
[[File:SMC Architecture with ACAN.png|center|thumb|243x243px|SMC Architecture with ACAN]]

ACAN supports three simple APIs:

# '''read'''(&''key'', &''value''): ''key'' holds a search pattern in a "tuple space" where all nodes are connected. ''value'' holds the matched tuple, if any. This is a blocking call that a requesting program will be blocked until a pattern-matched tuple is found. The matching tuple remains in the "tuple space".
# '''get'''(&key, &value): Same as the "read()" API, except that the matching tuple is removed from the "tuple space".
# '''put'''(key, value): Inserts <key, value> into the "tuple space".

The use of "gossip" protocol can accelerate ACAN network saturation time. Applications running on ACAN will automatically form parallel processing topologies: pipeline, SIMD and MIMD without violating the serialization needs of transaction block validation. Replication factor can also be dynamically controlled to spread replicated blocks in randomly chosen hosts.

The highly parallel nature of the blockchain protocol will automatically implement the SMC principle in real time.

The critical feature of this dynamic SMC pipelined architecture is the inductive scaling feature.
[[File:Pipeline Parallel Processing.png|center|thumb|247x247px|Pipeline Parallel Processing]]

The speed up of a pipeline can be represented as: <math>SpeedUp = \left ( \frac{p\centerdot b}{p + (b-p)} \right )</math>, where p = number of processors in the pipeline, b = total blocks to be processed. Take the number of blocks to infinity: <math>SpeedUp = \left ( \frac{p\centerdot b}{p + (b-p)} \right )=>\lim (b\Rightarrow\infty)(\frac{p}{\frac{p}{b}+1-\frac{p}{b}}) = p</math>

This means that as long as there are enough blocks to be processed, the entire chain's performance will be abound-bounded to the number of nodes in the pipeline.

For illustration purposes, the variation of block processing times was not considered in the above calculations. To see the power of pipeline parallelism, the automobile manufacturing processes illustrate a similar situation. The Hyundai Motor Company's production pipelines can produce 3,835 vehicles per day and 1.4M per year<ref>https://en.wikipedia.org/wiki/List_of_Hyundai_Motor_Company_manufacturing_facilities</ref>.

== Toichain Tokens ==
Toichain token is TOIN. There are 50,000,000,000 TOINs for the Alpha Release. There are air-drop tokens for early adopters, 1,000 TOIN each. Users need to register to download a toichain wallet to receive the payment. Citizenship is checked and verified to ensure that US citizens do not apply. The minimal staking contract is 10 TOINs.

== Non-Fungible Tokens ==
The TestNet Release of toichain protocol will support embedding arbitrary data in an "OP_RETURN" transaction that will be permanently recorded on the chain. Unlike the ordinal NFT <ref>https://blog.chain.link/ordinals-bitcoin-nfts/</ref> or NFT (non-fungible token) on other chains, these transactions cannot be altered or removed.

There are practical applications for these forever NFTs. Once Taproot is enabled on toichain, ordinal NFTs (BRC-20) will also be supported. Unlike the original Bitcoin network where BRC-20 craze has created massive network congestion<ref>https://beincrypto.com/learn/brc-20-token/</ref>, all transactions will be processed promptly in toichain without congestion or scaling problems.
== Toichain TestNet Launch ==
The toichain testnet launch will enable users to interact with one another through simple payments, just like the original Bitcoin network. Forever NFTs are supported. Smart contracts will be supported on a later date.

= References =
<references />

Consult the [[mediawikiwiki:Special:MyLanguage/Help:Contents|User's Guide]] for information on using the wiki software.

Main Page

2023-10-22T21:40:17Z

Justin: /* Blockchain Trilemma */

= <strong><big>'''Welcome to Toi-Twiki -- A Toichain Wiki'''</big></strong> =
This is the unofficial Toichain wiki site. Content on this site is subject to frequent changes.
---------------------------

= '''Introduction''' =
The blockchain protocol was introduced in a seminal paper entitled "Bitcoin: A peer-to-peer Electronic Cash System" <ref>https://bitcoin.org/bitcoin.pdf</ref> by Satoshi Nakamoto in 2008. Although there were previous peer-to-peer file-sharing projects such as Napster <ref>https://www.napster.com/us</ref>, BitTorrent <ref>https://www.bittorrent.com/</ref> and other electronic currency/file sharing applications, Bitcoin is the most enduring among the 23,000+ blockchains. Unlike other cryptocurrencies, the Bitcoin is often referred to as "digital gold" since the total coin supply is limited to 21 million (hard-coded in all running programs) and the only way to earn coin is to participate in the transaction block validation process. Token(or coin) supply and their disbursement policies differ among protocols.

The most attractive common blockchain features are 1) a decentralized consensus-driven decision making process and 2) a step-by-step cryptographic proving system. While blockchain is best known as a cryptocurrency transaction processing and record-keeping system, there are many other applications that can benefit from the secure storage, reliable transaction ledgers, fault tolerance and tamper resistance features.

== Algorithm vs. Protocol ==
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 ==
A good consensus protocol in a blockchain system has at least four properties:

# Fault tolerance to defend failures caused by natural disasters and human hacks or accidents
# Byzantine failure tolerance to defend exploitation by colluding parties
# Centralization avoidance to prevent corruptions in the decision making process
# Source code tamper resistance to automatically reject malicious attacks

Without assuming all nodes are active at all times, the blockchain relies on "gossip" protocol to communicate with other nodes. There are two popular types of consensus protocols: Proof of Work ('''PoW''') <ref>https://en.wikipedia.org/wiki/Proof_of_work</ref> or Proof of Stake ('''PoS''') <ref>https://www.investopedia.com/terms/p/proof-stake-pos.asp</ref>. Others include Proof of Possession('''PoP''')<ref>https://identityserver4.readthedocs.io/en/latest/topics/pop.html</ref> and Proof of History('''PoH''')<ref>https://www.infoworld.com/article/3666736/solana-blockchain-and-the-proof-of-history.html</ref>. The ultimate goal is to eliminate double-spending. Since most projects are open source, it's easy for a malicious actor to tamper a few nodes. This shouldn't compromise network integrity.

The Bitcoin network uses PoW which forces participating miners to compete for the fastest hashing rate by solving a computational cryptographic puzzle. Although it withstood more than 14 years of use, Bitcoin has been criticized for escalating electricity consumption <ref>https://www.forbes.com/advisor/investing/cryptocurrency/bitcoins-energy-usage-explained/</ref>. Other blockchain designs have experienced different challenges. For example, the PoH network Solana suffered multiple single-point-failure incidents <ref>https://messari.io/report/solana-analyzing-downtimes-statistics-and-ecosystem-development</ref>. All protocols struggle to combat scaling challenges. All are susceptible to 51% attacks <ref>https://originstamp.com/blog/has-there-ever-been-a-51-attack-on-bitcoin/#notable-51-attacks</ref>.

Since 2009, Bitcoin has proven to be the strongest and least susceptible to common hacks <ref>https://www.theguardian.com/technology/2014/mar/18/history-of-bitcoin-hacks-alternative-currency</ref>. As the PoW puzzle difficulty has increased dramatically over the years, the probability of a 51% attack on the Bitcoin network becomes more difficult. PoS protocols can save more than 90% energy consumption compared to PoW chains. But PoS chains have higher risks than PoW chains since a stolen coin will grow in PoS chains (for increased probability to be selected) forever but not in PoW chains (only hash rates count). PoS community governance rules can mitigate the voting power centralization problem. Staking and slashing policies can incentivize good behaviors and punish bad ones. In either case, double-spend is very expensive and difficult. According to Forbes, there are 80 cryptocurrencies that use PoS protocols at the time of this writing.

There are approximately 1,000 blockchains in four types: public, private, consortium, and permissioned <ref>https://increditools.com/blockchains/</ref>.

== Cryptographic Proofs ==
Bitcoin 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.

== Centralized vs. Decentralized Applications ==
The Bitcoin protocol enabled decentralized processing of traditionally centrally processed transactions without any trusted third-party. It inspired many decentralized financial applications, especially for applications with very long payment chains. However for fraud prevention and meeting financial regulatory requirements, many practical applications still require KYC (know your customer) checks. It is not possible to eliminate all trusted third parties, especially for custodial financial applications. There is a clear need for decentralized processing of trusted authority applications.

== Blockchain Trilemma ==
Blockchain protocols have three common aspects (goals): '''security''', '''decentralization''' and '''scalability''' -- these three terms do not have precise definitions but are intuitively understood <ref>https://sensoriumxr.com/articles/what-is-the-blockchain-trilemma</ref>. To date, 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.

A major shortcoming is scalability. Since all nodes verify each transaction independently, they need to store all the information required for it. As the chain grows, this burdens all nodes in the network. There are workarounds by limiting the amount of data stored on some nodes and exploiting the network to retrieve required information, such as the ''Limited/Light Nodes'' in Bitcoin network. Vast majority nodes are still full nodes in the existing Bitcoin network. Transaction processing speed often expressed ''as transactions per second(TPS) of'' blockchain have to exceed TPS ratings of credit card payment systems like VISA or MasterCard to reap the full benefits of blockchain. This is a tough problem and increasing the block size and/or reducing the block time or difficulty isn't a solution<ref>https://medium.com/coinmonks/blockchain-scaling-30c9e1b7db1b</ref>. Since blockchain TPS is very low, the transaction fees is often very high. This discourages public adoption. Layer 2 solution like ''Lightning Network'' or ''ZK-rollups,'' where only final settlement is on the main chain tend to address these issues. However, one could always argue that this often compromises some aspects of security and/or decentralization to achieve high TPS.

The trilemma was first introduced by Vitalik Buterin<ref>https://en.wikipedia.org/wiki/Vitalik_Buterin</ref>, one of the co-founders of Ethereum network. The problems he identified are real. There seem to be no obvious solutions that can accomplish all three goals at the same time. Therefore, all proposed solutions revolve around reducing "opportunity costs" focusing only on satisfying partial goals.

Treating the blockchain network as an infrastructure for transaction processing, the blockchain protocol solved service reliability problem but not performance challenge. The legacy infrastructure scaling dilemma: performance against reliability remains (where "infrastructure reliability" also does not have a commonly accepted definition). Fortunately these metrics, although important, are non-critical. Solutions that have been proposed have had varying opportunity costs. For many years, there were no obvious solutions that addressed all three blockchain goals (security, decentralization and scalability).
== Statistic Multiplexed Computing (SMC) ==
The principle of using unreliable components to build an arbitrarily reliable system was first lectured by von Neumann in the early 1950s<ref>https://static.ias.edu/pitp/archive/2012files/Probabilistic_Logics.pdf</ref>. The original idea was to use probabilistic logic to quantify the arbitrary reliability of a system by multiplexing all components. This theory was applied to the construction of Internet protocols to deliver the "best effort" reliability. Incidentally, best effort reliability also enabled "best effort" performance which in turn enabled unlimited scalability of the Internet. For emerging web3.0 technologies, it is important to apply the same methodology to both centralized and decentralized computing for seamless technology migration and integration. For historical arguments, click [[SMC|'''''here''''']].

== Definitions ==
'''Infrastructure scalability''' does not have a commonly accepted definition. It helps to define the challenging metrics more precisely before the infrastructure protocol design. In the following, for definitions #1 and #2, the word "'''infrastructure'''" means any '''application running on the infrastructure.'''

# '''Infrastructure Reliability''': MTBF (mean time between failure) = <math>\frac{\sum ((Start-Of-Downtime) - (Start-of-uptime)) }{No-of-failures}</math>
# '''Infrastructure Performance''': <math>\frac{No-of-Transactions}{Second}</math>
# '''Infrastructure Scalability''': Expanding the infrastructure in number of processors, networks or storage should have '''incrementally better''' impacts on application reliability and performance.
# '''Record Immutability''': For transaction ledgers, all confirmed records and changes are final. This is required by the blockchain protocol.
Note that in practice, record immutability is much harder to achieve than expected. There are two challenges, a) 51% attacks can literally wipe out all histories if successful, and b) for protocols require all nodes to hold independently verified ledger, such as the Bitcoin, the storage requirement grows approximately 50GB per month.

== 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 and considered.

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 crashe'''s <ref>https://groups.csail.mit.edu/tds/papers/Lynch/jacm93.pdf</ref>. The laws of physics regarding component reliability <ref>Encyclopedia of Physical Science and Technology, Editor-in-Chief Robert A. Meyers, [[index.php?title=Special:BookSources/9780122274107|ISBN 978-0-12-227410-7]], 2001</ref> show that '''100% component reliability is not possible.''' These facts require that the infrastructure protocol (program-program communication protocol) provide '''complete component (processing, networking and storage) decoupling''' from application program logics. This decoupling requirement forces the protocol to exploit "decentralized" or "stateless" components that the legacy infrastructure protocols, such as message passing interface (MPI), remote procedure call (RPC) and remote method invocation (RMI), cannot handle. The blockchain protocol is an example of a "best effort" availability protocol.

Quantifying infrastructure reliability can be traced back to the computer pioneer von Neumann. In addition to his contribution to computer architecture, von Neumann also penned a study on building reliable systems using unreliable components using probabilistic logics, in early fifties <ref>https://static.ias.edu/pitp/archive/2012files/Probabilistic_Logics.pdf</ref>. The 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 "best effort" reliability. Ironically, this best effort reliability also enabled the Internet's infinite scalability -- the benefit we enjoy now and into the future.

The Bitcoin protocol exploits multiple anonymous decoupled (or decentralized) computers connected through the Internet protocol. Judging from the Bitcoin network's reliability to date <ref>https://buybitcoinworldwide.com/bitcoin-downtime/</ref>, von Neumann's theory seems working well.

The '''second challenge''' involves infrastructure performance. Since the infrastructure must deploy multiple computing, networking and storage components, unless all components can be fully exploited at 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 lack this capability.

'''The infrastructure scalability challenge''' is automatically resolved once the performance challenge is resolved without negatively impacting reliability -- "best effort" performance" meets "best effort reliability". This requires inductive performance and reliability measures or deliveries.

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, an inductive statistic multiplexed blockchain protocol is needed to meet the scalability challenge. Non-inductive solutions such as fixed chain "sharding" or "Danksharding" <ref>https://ethereum.org/en/roadmap/danksharding/</ref> will only increase protocol development complexity with persistent performance walls.

== A Proposed Scalability Solution ==
An effective scalability solution can have two practical assumptions:

* The computation problem size can expand indefinitely, since every useful infrastructure is expected to solve bigger problems.

*Computing and network resources will continue to grow indefinitely, into the future.
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 <ref>https://en.wikipedia.org/wiki/Amdahl%27s_law</ref> and Gustafson's Law <ref>https://en.wikipedia.org/wiki/Gustafson%27s_law</ref>. The problem is that these two "laws" seem to yield complete opposite performance predictions.[[File:Amdahl's Law.png|thumb|Amdahl's Law Speedup Predictions|center]]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.
[[File:Gustafson.png|thumb|Gustafson's Law|center]]
A careful examination revealed that the two laws are mathematically dependent <ref>https://cis.temple.edu/~shi/wwwroot/shi/public_html/docs/amdahl/amdahl.html</ref> where Amdahl's formulation has a tight peak performance bound <math>\left ( \frac{1}{x} \right )</math> 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 <math>\left ( \frac{1}{x} \right )</math>, when <math>x \Rightarrow 0</math>, the performance will asymptotically approach to <math>\infty</math>, when <math>x \Rightarrow 1</math> the speedup <math>\Rightarrow</math> 1. Thus, if the computing problem's size is fixed, x will eventually approach to 1 as the number of processors increases -- economic law of diminishing of return. If the problem size is open (solving bigger problems), then increasing the number of processors will force x <math>\Rightarrow</math> 0, thus speedup <math>\Rightarrow</math> <math>\infty</math>. Gustafson's Law uses a recurrence relation based on practical time measurements. It is not possible to derive a mathematical speedup bound.

Applying these laws in practice need to quantify <math>\chi</math> for practical parallel program which has been proven very hard if not impossible. Gustafson's formula was derived from times by running actual parallel programs. Brining the two formulation together makes quantifying <math>\chi</math> in Amdahl's Law possible. Thus, both law actually refer to the same mathematical abstraction. Gustafson's formula assisted in quantifying the percentage of serial computing through program experiments. Neither should be directly used for speedup prediction alone.

This model can be validated in practice when developers simply increasing the problem size to use more parallel processors.
[[File:1overx-function resized.png|thumb|294x294px|Amdalh's Law and Peak Parallel Performance|center]]

A classical example is the TOP500 supercomputer benchmarks (linear solvers) that have open problem sizes for all manufacturers to compete in the world's fastest supercomputer race <ref>https://www.top500.org/</ref> .
[[File:Supercomputers-history.png|center|thumb]]
In practical blockchain applications, the number of transactions to be processed will increase until it satisfies all possible requests. The ledger storage will continue to grow. In other words, the available computing, networking and storage components can always cover the needs given economic incentives. The infrastructure no longer has the structural deficiency.

== 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.

For Toichain protocol design, we choose Bitcoin 24.0.1 as the base line protocol by replacing the PoW consensus by PoS consensus and injecting SMC components into the protocol processing signaling for parallel computing.

This surprising result is also applicable to ledger storage. Without multiplexing, the blockchain ledger storage will eventually saturate all nodes causing the chain to collapse. The SMC blockchain protocol promises to hold the true finality of all transactions in perpetuity by multiplexing all storage resources while keeping the replication factor to a constant.

These discussions follow the inductive logic of the Law of Large Numbers <ref>https://www.sciencedirect.com/topics/mathematics/laws-of-large-number</ref>.

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

= SMC Proof of Stake Protocol =
Existing PoS protocol designs revolved around staking policies and randomness of the selection algorithm. Considering infrastructure scalability will add much complexity to the design. The examples include chain sharding and Danksharding <ref>https://ethereum.org/en/roadmap/danksharding/</ref>.

The challenge is complex -- we must deliver very high performance without compromising security and reliability of the network.

Technically, transaction replication and parallel processing were considered dangerous <ref>https://pages.cs.wisc.edu/~yxy/cs764-f20/papers/replication.pdf</ref> due to the potential race conditions (or double-spend problem). The blockchain protocol resolved the double-spending problem. It did not solve the parallel processing performance problem.

According to Professor Michael Flynn, there are three high-level parallel processing topologies: SIMD (single instruction multiple data), MIMD (multiple instructions multiple data), and pipeline (MISD - multiple instructions single data stream) <ref>https://link.springer.com/referenceworkentry/10.1007/978-0-387-09766-4_2</ref>. However, for eliminating double-spending, all transactions must be serialized, since each block may contain transactions affecting transactions in multiple other blocks. "Race conditions" and non-deterministic results are not allowed. Then the only possible topology entry is pipeline. This means for POS protocol, we must build a pipeline of transaction blocks to be validated without compromising network security and reliability.
[[File:Flynns-Taxonomy-of-Computer-Architectures.png|center|thumb|Parallel Processing Topologies]]
The problem is that the nature of the blockchain protocol is that all nodes run independently in parallel with little communication with other nodes via "gossip" protocols. It is far easier to force all nodes store the entire ledger than forcing them to form any pipeline and store partial chain data.

=== ACAN (Active Content Addressable Network) [U.S. and Other Patents Pending] ===
ACAN is a high-level data '''''communication and synchronization protocol''''' that completely decouples all hardware components from communicating programs. The need for complete component decoupling was implemented in the original blockchain protocol via "gossip" protocol. This delivered blockchain's high availability and security. The simple "gossip" implementation in existing protocols is insufficient for parallel processing signaling.

The following figure illustrates the concept of ACAN (active content addressable networking) using UVR (unidirectional virtual ring) architecture. The illustrated implementation uses the Tuple Space resource tagging method and gossip protocol for UVR implementation.
[[File:SMC Architecture with ACAN.png|center|thumb|243x243px|SMC Architecture with ACAN]]

ACAN supports three simple APIs:

# '''read'''(&''key'', &''value''): ''key'' holds a search pattern in a "tuple space" where all nodes are connected. ''value'' holds the matched tuple, if any. This is a blocking call that a requesting program will be blocked until a pattern-matched tuple is found. The matching tuple remains in the "tuple space".
# '''get'''(&key, &value): Same as the "read()" API, except that the matching tuple is removed from the "tuple space".
# '''put'''(key, value): Inserts <key, value> into the "tuple space".

The use of "gossip" protocol can accelerate ACAN network saturation time. Applications running on ACAN will automatically form parallel processing topologies: pipeline, SIMD and MIMD without violating the serialization needs of transaction block validation. Replication factor can also be dynamically controlled to spread replicated blocks in randomly chosen hosts.

The highly parallel nature of the blockchain protocol will automatically implement the SMC principle in real time.

The critical feature of this dynamic SMC pipelined architecture is the inductive scaling feature.
[[File:Pipeline Parallel Processing.png|center|thumb|247x247px|Pipeline Parallel Processing]]

The speed up of a pipeline can be represented as: <math>SpeedUp = \left ( \frac{p\centerdot b}{p + (b-p)} \right )</math>, where p = number of processors in the pipeline, b = total blocks to be processed. Take the number of blocks to infinity: <math>SpeedUp = \left ( \frac{p\centerdot b}{p + (b-p)} \right )=>\lim (b\Rightarrow\infty)(\frac{p}{\frac{p}{b}+1-\frac{p}{b}}) = p</math>

This means that as long as there are enough blocks to be processed, the entire chain's performance will be abound-bounded to the number of nodes in the pipeline.

For illustration purposes, the variation of block processing times was not considered in the above calculations. To see the power of pipeline parallelism, the automobile manufacturing processes illustrate a similar situation. The Hyundai Motor Company's production pipelines can produce 3,835 vehicles per day and 1.4M per year<ref>https://en.wikipedia.org/wiki/List_of_Hyundai_Motor_Company_manufacturing_facilities</ref>.

== Toichain Tokens ==
Toichain token is TOIN. There are 50,000,000,000 TOINs for the Alpha Release. There are air-drop tokens for early adopters, 1,000 TOIN each. Users need to register to download a toichain wallet to receive the payment. Citizenship is checked and verified to ensure that US citizens do not apply. The minimal staking contract is 10 TOINs.

== Non-Fungible Tokens ==
The TestNet Release of toichain protocol will support embedding arbitrary data in an "OP_RETURN" transaction that will be permanently recorded on the chain. Unlike the ordinal NFT <ref>https://blog.chain.link/ordinals-bitcoin-nfts/</ref> or NFT (non-fungible token) on other chains, these transactions cannot be altered or removed.

There are practical applications for these forever NFTs. Once Taproot is enabled on toichain, ordinal NFTs (BRC-20) will also be supported. Unlike the original Bitcoin network where BRC-20 craze has created massive network congestion<ref>https://beincrypto.com/learn/brc-20-token/</ref>, all transactions will be processed promptly in toichain without congestion or scaling problems.
== Toichain TestNet Launch ==
The toichain testnet launch will enable users to interact with one another through simple payments, just like the original Bitcoin network. Forever NFTs are supported. Smart contracts will be supported on a later date.

= References =
<references />

Consult the [[mediawikiwiki:Special:MyLanguage/Help:Contents|User's Guide]] for information on using the wiki software.