Main Page - Revision history

Justin: /* A Scalability Solution */

2024-10-16T14:20:52Z

A Scalability Solution

Justin: /* Definitions */

2024-10-14T15:35:09Z

Definitions

← Older revision		Revision as of 11:35, 14 October 2024
Line 56:		Line 56:
	# '''Infrastructure Scalability''': Expanding the infrastructure in number of processors, networks or storage should have '''incrementally better''' impacts on application reliability and performance.		# '''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.		# '''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.		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 ==		== Protocol Design and Proofs ==

Justin: /* Definitions */

2024-10-14T15:30:35Z

Definitions

← Older revision		Revision as of 11:30, 14 October 2024
Line 50:		Line 50:

	== Definitions ==		== 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 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 Reliability''': MTBF (mean time between failure) = <math>\frac{\sum ((Start-Of-Downtime) - (Start-of-uptime)) }{No-of-failures}</math>

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

2024-10-14T15:29:22Z

Statistic Multiplexed Computing (SMC)

← Older revision		Revision as of 11:29, 14 October 2024
Line 43:		Line 43:
	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).		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) ==		== 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.		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.

	~~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''''']].		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 ==		== Definitions ==

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

2024-10-14T13:06:15Z

Statistic Multiplexed Computing (SMC)

← Older revision		Revision as of 09:06, 14 October 2024
Line 43:		Line 43:
	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).		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) ==		== 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''''']].		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 ==		== Definitions ==

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

2024-10-14T13:03:47Z

Statistic Multiplexed Computing (SMC)

← Older revision		Revision as of 09:03, 14 October 2024
Line 43:		Line 43:
	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).		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) ==		== 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''''']].		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 ==		== Definitions ==

Justin: /* A Scalability Solution */

2024-10-14T13:00:36Z

A Scalability Solution

← Older revision		Revision as of 09:00, 14 October 2024
Line 84:		Line 84:
	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)		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>		</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.		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, ~~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.		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.		In 1988, Gustafson and Barsis at the Sandia National Laboratory conducted parallel computing experiments that seem to suggest potential infinite speedup.
Line 98:		Line 98:
	</div>		</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.		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]]		[[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>:		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>:
Line 106:		Line 106:
	</div>		</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.		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.		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.

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

2024-10-13T18:06:23Z

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

← Older revision		Revision as of 14:06, 13 October 2024
Line 147:		Line 147:

	=== ACAN (Active Content Addressable Network) [U.S. PTO #11,588,926 B2, EPO #3539261] ===		=== 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.		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.		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.

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

2024-10-13T18:05:10Z

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

← Older revision		Revision as of 14:05, 13 October 2024
Line 147:		Line 147:

	=== ACAN (Active Content Addressable Network) [U.S. PTO #11,588,926 B2, EPO #3539261] ===		=== 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.		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.		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.

Justin: /* A Scalability Solution */

2024-10-13T18:03:29Z

A Scalability Solution

← Older revision		Revision as of 14:03, 13 October 2024
Line 98:		Line 98:
	</div>		</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.		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]]		[[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>:		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>:
Line 146:		Line 146:
	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.		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 (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.		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.

← Older revision		Revision as of 10:20, 16 October 2024
Line 83:		Line 83:
	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>.		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.		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;">		<div style="text-align: center;">
Line 90:		Line 90:
	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.		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.		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.		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.		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:		To estimate accomplished speedup, Gustafson's Law states:
Line 102:		Line 102:
	</div>		</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.		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]]		[[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>:		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;">		<div style="text-align: center;">
Line 120:		Line 122:
	[[File:DiminishingReturn2.png\|alt=infinite Speedup Under Amdahl's Law\|center\|thumb\|Infinite Speedup in Amdahl's Law\|400x400px]]		[[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.		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]]		[[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.		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 ==		== Action Plan ==