Main Page

Welcome to Toi-Twiki -- A Toichain Wiki

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

---

Introduction

The blockchain protocol was introduced in a seminal paper entitled "Bitcoin: A peer-to-peer Electronic Cash System" by Satoshi Nakamoto in 2008. Although there were previous peer-to-peer file-sharing projects such as Napster , BitTorrent 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 supply is limited to 21 million Bitcoins by the protocol. 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 and other properties offered by this technology.

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:

1. Fault tolerance to defend failures caused by natural disasters and human hacks or accidents
2. Byzantine failure tolerance to defend exploitation by colluding parties
3. Centralization avoidance to prevent corruptions in the decision making process
4. 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) or Proof of Stake (PoS) . Others include Proof of Possession(PoP) and Proof of History(PoH). 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 . Other blockchain systems have experienced shortcomings. For example, the PoH network Solana suffered multiple single-point-failure incidents . Also, all protocols are susceptible to 51% attacks .

Since 2009, Bitcoin has proven to be the strongest and least susceptible to common hacks . 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. 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 .

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 . 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 small nodes in the network. There are workarounds by limiting the amount of data stored and exploiting the network to retrieve required information. An example would be Limited/Light Node in Bitcoin network. They're connected to Full Node to independently verify transactions. Even though, this solves the storage aspect of scaling to some extend, there are other aspects to be addressed. 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. 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, one of the co-founders of Ethereum network. The problems he identified are real. There seem to be no obvious solutions that accomplish all three goals using known methods. 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. 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 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.

1. Infrastructure Reliability: MTBF (mean time between failure) = ${\frac {\sum ((Start-Of-Downtime)-(Start-of-uptime))}{No-of-failures}}$
2. Infrastructure Performance: ${\frac {No-of-Transactions}{Second}}$
3. Infrastructure Scalability: Expanding the infrastructure in number of processors, networks or storage should have incrementally better impacts on application reliability and performance.
4. 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 crashes . The laws of physics regarding component reliability 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 . 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 , 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" 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 and Gustafson's Law . The problem is that these two "laws" seem to yield complete opposite performance predictions.

Amdahl's Law Speedup Predictions

The Amdahl's Law seems to predict parallel performances following the economic law of diminishing of returns while Gustafson's Law seems to lead infinite speedups. Gustafson's Law was used to argue for Massively Parallel Computing (MPC) experiments and Amdahl's Law was used to argue for bigger supercomputer constructions. In the last three decades, these laws have been used to build parallel computing systems and multi-processor operating systems and computing clouds.

Gustafson's Law

A careful examination revealed that the two laws are mathematically dependent where Amdahl's formulation has a tight peak performance bound $\left({\frac {1}{x}}\right)$ 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 $\left({\frac {1}{x}}\right)$, when $x\Rightarrow 0$, the performance will asymptotically approach to $\infty$, when $x\Rightarrow 1$ the speedup $\Rightarrow$ 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 $\Rightarrow$ 0, thus speedup $\Rightarrow$ $\infty$. 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 $\chi$ 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 $\chi$ 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.

Amdalh's Law and Peak Parallel Performance

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 .

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.

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 .

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 .

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 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) . 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.

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.

SMC Architecture with ACAN

ACAN supports three simple APIs:

1. 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".
2. get(&key, &value): Same as the "read()" API, except that the matching tuple is removed from the "tuple space".
3. 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.

Pipeline Parallel Processing

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

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.

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 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, all transactions will be processed promptly under any network scale.

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

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