IT infrastructure is the backbone of all modern societies in business, commerce, finance, healthcare, military, education and social welfare. However, existing infrastructure scaling limitations expose critical services to security and reliability shortcomings that invite ever escalating cyberattacks. This research investigates whether there are ways to decouple overhead growth from performance gains to allow unlimited scaling.

Research Overview

Our research focuses on the use of SMC (Statistical Multiplexed Computing) principles for building infrastructures without scaling limits. The idea is similar to the Internet's statistically multiplexed communication protocols (TCP/IP) that allowed for indefinite network scaling. SMC leverages the TCP/IP protocols to OS kernel extensions for runtime SMC operations to form dynamic SIMD, MIMD and pipelined topologies automatically for high performance, automated load balancing and fault tolerance for generic computing needs from dedicated servers to multi-cloud environments.

We investigate seamless peer-to-peer computing protocols with end-to-end encryption for security and tamper resistance (such as blockchain). We further investigate the feasibility of service "sentience" using the latest formal NARS (non-axiomatic reasoning system) and multiple generative AI tools. The target is to tailor services to real-life needs without unintended consequences.

Experiment Implementation on Chameleon

We need testbeds for NARS to train massive inputs from multiple sources to extract and derive the confidence values of rules. For infrastructure testbeds, we need Python, C, and C++ compilers, mixed GPU cards and interconnects (InfiniBand, regular Ethernet, Gigabit Ethernet and others if available). We need to experiment with seamless integration of decentralized services with both decentralized and centralized authorities.

We rely on Chameleon's host availability browser to find the machines needed. We also run experiments in other platforms that are not available on Chameleon such as Tenstorrent cluster. We primarily need bare-metal machines with optional GPU and interconnection choices. We do need access to the serial console. Eventually, we will need cloud orchestration tools.

If Chameleon was not available, we would have to use AWS, Google or Azure and other cloud providers with less choices. Our hypothesis would not change, but the flexibility and bare-metal access that Chameleon provides is crucial for our low-level infrastructure experiments.

Experiment Artifacts

The most recent artifacts include the paper published by SpringerNature, vol 2261 of Communications in Computer Science Series, Foundations of Computer Science and Frontiers in Education, Chapter 5, "TOIChain(™) "A Proposal for High Performance Tamper Resistant Transactions without Scaling Limits" (DOI:10.1007/978-3-031-85930-4_5, SpringerNature, March 24, 2025).

Related patents include:

• U.S. Patents: #11,588,926 B2 (2023), #5,517,656 (1996), #5,381,533 (1995)
• European Patent: #EP35339261 (2022)

User Interview

Tell us a little bit about yourself

I studied at the University of Pennsylvania from 1980-1985. I have been teaching at Temple University since 1985. My primary research interest is in infinitely scalable fault tolerant high performance distributed and parallel systems. My hobbies include ad hoc "trash to treasure" adventures including children's toy repairs and rebuilds.

Most powerful piece of advice for students beginning research or finding a new research project?

Keep curiosity open and follow up.

How do you stay motivated through a long research project?

Failures are only motivators for future successes. I was lucky to be exposed to mission-critical problems very early.

Are there any researchers you admire?

Elon Musk, for obvious reasons.

What has been a tough moment throughout your career?

All my proposals were rejected. I was the only person who voiced opinions against MPI for it introduces too many single-point failures into an application. Head down, try harder. Find more information. Single-point failures are human induced. It is a programming fallacy not a feature.

Why did you choose this direction of research?

It was given. It stayed unresolved for decades.