In this article, we will explore the concept of Hypermodularity, define what “Modularity” actually means through simple analogies we can find in Web2, and how it relates to modern Web3 decentralized networks and application design. We will also have a closer look at the base layers to understand what happens in the physical world and learn about Metafinality (MF) which will be the stepping stone toward making both the monolithic and modular worlds interoperable between different ecosystems.

TLDR

• Cross-ecosystem roll-app interoperability requires strong assumptions on the finality of external modular chains and base-layer networks

• Light clients in classical “Internet of Blockchains” are insufficient for achieving interoperability because different versions of the same blockchain client application separated in physical network space might observe completely different sequences of blocks or states of the same network or application

• Resolving forks and state transition inconsistencies in external ecosystems is a non-deterministic and non-logical process that does not adhere to anything that can be expressed in classical deterministic code logic making existing bridging and interoperability solutions dependent on light clients unsafe in the context of modular chains

• Instead of having to achieve consensus on hundreds of different modular chains, Metafinality enables any application to simply observe a single network - KIRA, for strong assumptions on the consensus of any other external network or application

Background

“Modular Networks” or a Web3 equivalent of microservices in Web2 are one of the most sustainable and efficient ways for isolating and self-containing independent components of a modern decentralized stack. Web3-era microservices composed together might unlock the forever-promised “mass adoption” of decentralized networks. After all, typical Web2 applications utilize multiple subscription-based API services, whether that is compute, payment processing, mailing, analytics, or more. It is thus not unthinkable that those legacy services could be replaced entirely by their Web3-based modular equivalents.

Ethereum smart contracts are one of the most successful compostable applications to have ever been created and are in constant use despite their cost and limited processing abilities. The success of smart contracts derives from the simple and unified programming language, ease of deployment, and ability to compose - that is, reuse each other's functionality and interoperate.

Internet of Blockchains such as Cosmos and Polkadot took the concept of composability a step further and proposed a unified communication system across their application-specific system-chains/parachains - the IBX/XCMP. Despite this being a brilliant idea enabling decentralized applications to gain even more computing power, the initial solution fell short of expectations due to dependency hell, growing complexity, and even higher time and cost to deploy from hundreds of dollars in the case of smart contracts to millions as well as months to years it takes to develop those complex networks and organize and incentivize network operators.

Modular chains seem to be the answer to the time and cost of deployment dilemma, with roll-ups and roll-downs promising the ultimate solution. If not for the last missing piece of the puzzle - cross-ecosystem composability and bridging, Web3 might be on the brink of a new adoption paradigm. At the end of the day, all our modular networks require settlement and issuance layers, whether that is Ethereum, the Polkadot relay chain, or KIRA. The reason for that is trust which in decentralized networks is often associated with value, “money at stake” or otherwise cost of attack. Solutions such as shared security and ZK are used to ensure that computations are either cryptographically verifiable or can be trusted with sufficient confidence in relation to the assets being locked into them. The issue with assets however is that the most valuable ones often originate from external networks and systems.

Metafinality

To achieve Hypermodularity or in other words “Functional Modularity” we must not only be able to reliably bridge assets to and from external ecosystems not compatible with our desired protocols but also be able to reliably interpret the state of those other networks and systems. If app-chain A is settled on network X and app-chain B is settled on network Y where X and Y are separate ecosystems, how could either of them compose, and use each other's data? The typical answer in the “Internet of Blockchains” ecosystems would be simple - you must either run a light client or otherwise both app-chains must “observe” each other and figure out a common protocol for communication. This however doesn’t scale on-chain considering hundreds or even millions of app-chains each interested in different types of data exchange. The original Cosmos hub-spoke architecture or a Polkadot parachain model was designed for hundreds, not millions of apps communicating, especially applications that are blockchain-less. Supporting hundreds of light clients creates almost unimaginable maintenance costs making the idea of the app-chains that are supposed to “be forever” whimsy or “quick app fashion” at best. If we ask ourselves what the chances of a typical app-chain existing 100 years from now are vs an Ethereum smart contract vs a Bitcoin script or inscription, the answer is that the simpler something is the more likely it is to persist and the odds of something like an app-chain existing long term are close to zero.

What would thus be the simplest way of solving interoperability and bridging that can inspire confidence comparable to our legacy “forever applications”? We believe the answer is Metafinality.

At the core of Metafinality lies an observation that everything in tech is “whimsy”, meaning states of applications don’t follow logic or protocols but rather independent sets of human consensus upgrading those protocols. Networks like Ethereum for example depend on the whim of the founders and not even the community (who originally invested in the “immutable ledger”) deciding which fork is a real Ethereum and which is its “Classic” version. Even Bitcoin changes and constantly has to fight off attacks such as BCash in the past. The only constant that remains regardless of the network is a forever changing “chain of block hashes”. We can also think about it as a linked list of state transitions that our applications go through. In Metafinality we will be using this concept as the ultimate source of truth as long as we can determine which one of those long strings of hashes is real, a temporary fork, or a “whim-chain” that will be rolled back to its previous state.

The main issue with what on-chain “truth” is, is a concept of relativity - what the state of a blockchain or application might seem for one full node or “observer” might be completely different for another one. This can be due to network delays, forks, software implementation issues, or any combination of any other factors. If on the other hand, we are to depend on third parties like Infura in the case of Ethereum to tell us what the truth is, the situation becomes even more grim since we are introducing yet another point of failure - a centralized data center admin with ability to provide you any false information by mocking the RPC response according to his needs.

So what? - One might say. Does it matter if the data provided by RPC is fake or not? Don’t blockchains eventually resolve forks? Well they do, but as we pointed out it might be too late for your bridge or application to figure that out while assets that were supposed to have been bridged in reality never were. Especially the problem becomes even bigger since the fork-choice rule is not even a source of on-chain logic. Whoops. Wait, does it mean all bridges between all large ecosystems today are not as safe as they seem? In short, yes. But don’t worry Metafinality (MF) comes to the rescue.

To deal with “whimsical” software we need a “whimsiness resolver”. The MF deals with it by first enabling the detection of inconsistent block headers for a given block height. In short, if we know that something that should not happen happens we can take immediate action. Step one is thus allowing anyone to run ANY type or implementation of a specific blockchain client and submit on-chain their observation. The word “ANY” is really important here since we have to assume that different versions of the same blockchain client application or even the same version of the application separated in physical networking space might observe completely different chains of block hashes, regardless if that's due to planned attack, network delays or any other unexpected reason. Naturally, we will end up with either a conflicting or not-conflicting state for a given block. If the conflict does not happen we proceed to the first iteration of our algorithm but for the next block and reward one of the submitters, if the conflict happens we need to resolve the issue. The issue is ensuring that conflicts don’t occur on the whim of people trying to disturb the process thus step one requires a bond that can be slashed. With the bond in place, we can proceed with a simple governance proposal to define which block hash is correct for a given conflicting block height and define a penalty (or lack thereof) for submitting a piece of conflicting information. We need a human consensus here since we can’t say if the bond should be slashed or if the submitters of an alternative fork should be rewarded for detecting a legitimate issue!

Pretty simple isn’t it? Well, it is but it also seems very, very slow to have humans involved in the protocol. This means bridging might take days or even weeks… Yes, of course, that is the beauty of our world that we can’t eat a cake and have it too! However, fear not, because to speed up our algorithm we can use the power of an open and free economy and speculation. Why shouldn’t anyone be allowed to bridge with arbitrary speed where it's a third party taking a risk for a sufficiently large fee proportional to the speed of bridging? And that is the finishing touch of  Metafinality - a practical, whimsy-tolerant protocol for cross-ecosystem value and data communication based on human-assisted resolving of external ecosystem forks that don’t follow deterministic logic, something none of the currently existing bridges and communication protocols can handle in both practical and intuitive to understand way.

Conclusions

We hope that in the near future, real bridging and roll-app intercommunication solutions such as Metafinality can be enabled at scale and we work tirelessly to make that possible for the KIRA chain. Practical decentralization is a difficult subject, but should not be an incomprehensible one, or disguised under fancy math equations covering up a reality of just a few centralized provers and verifiers. We wish solutions were as simple and clean as having a validator set run the same version of light-client of another chain or simply plugging in existing IBC-enabled modules. The truth is that someone has to attempt controversial implementations that bring hope to one day deliver solutions that can be intuitive even for those without a strong sense of mathematics.

The implications of MF go far beyond simple bridging, most importantly they enable applications to observe and communicate with millions of other applications across any set of ecosystems by simply observing and establishing consensus on the state of a single blockchain - KIRA. Our goal is driving towards a world in which both Monolithic and Modular architectures meet to enable hyper-performant applications to exist that can for the first time compete with Web2. Join us at our community chat and follow on X to be part of the Hypermodularity movement.