Fractal instance architecture notes

[cwgoes]

Here's an idea for explaining by comparison (a bit) the architecture of fractal instances:

Consider blockchain platforms, from the perspective of applications running on top of them, along two dimensions: protocol architecture and security model, and whether they are homogeneous or heterogeneous for different applications running on the platform. Protocol architecture refers to the state layout, virtual machine, language support, sharding mechanisms, cross-contract messaging model, etc. - architecture determines what is required to write an application for a platform. Platforms with a homogeneous architecture require that all applications are written in a certain format (e.g. EVM bytecode or WASM), while platforms with a heterogeneous architecture allow applications to be written in different formats, perhaps with some agreement at the edges (cross-chain communication protocols). Security model refers both to security in theory - fault tolerance properties of the consensus, fork detection & handling, etc. - and security in practice - which miners or validators actually operate deployed instances of these architectures. Platforms with a homogeneous security model have the same security for all applications (more or less), while platforms with a heterogeneous security model have different security characteristics (perhaps both in theory and in practice) for different applications.

This is, of course, a broad characterisation and obscures finer detail, but these design dimensions do exist. Let's situate several platforms on these two axes:

(todo: nice visual)

Platform	Protocol Architecture	Security Model
Ethereum 1	Homogeneous	Homogeneous
Ethereum 2	Homogeneous	Homogeneous
Polkadot	Heterogeneous	Homogeneous
Near	Homogeneous	Homogeneous
Cosmos	Heterogeneous*	Heterogeneous
Multichain**	Heterogeneous	Heterogeneous

*Nominally, though lots of standards have emerged in practice. **i.e., many different blockchains bridged together

As this diagram suggests, these dimensions, so far, are generally quite correlated: homogeneous architectures come with homogeneous security models, and heterogeneous architectures come with heterogeneous security models. It's easier to design a system where they are correlated - if everything is homogeneous, protocols can be fit together neatly, cross-contract communication is easy, etc.; if everything is heterogeneous, protocols just agree on the edges of interaction (IBC) and handling the complexity of security is up to the users.

Anoma's fractal instance architecture is an attempt to decouple these dimensions and build a platform which is architecturally homogeneous (though see below) but with a heterogeneous security model. This is more complicated, but it separates out the question of what is the best protocol architecture, where there may be a "benevolent monopoly" (a la Git or TCP/IP), from the question of what is the best security model, where there is almost certainly not. Applications written for fractal instances can standardise on the architecture Anoma offers, which is sufficiently well-defined to allow for complex interoperability, automatic scaling, etc., without agreeing on any single security model (and, in some cases, this flexibility of choice can be extended all the way to users of the applications, who can choose independently). Interfaces for Anoma instances can support the same applications deployed with different security models, and communicate that latter difference to users in a way which allows them to choose their trust assumptions while retaining the network effects of using the same protocol.

It's worth noting that Anoma's architecture isn't "homogeneous" like a straitjacket - all of the protocols are layered so that fractal instances can pick and choose which parts they participate in - we should do this, but we should also come up with a unified architecture that handles most concerns reasonably well and allows developers and users of Anoma to realise the benefits of standardisation.