As the blockchain ecosystem is expanding and maturing, a variety of different network architectures are emerging. Over the past few years, simple consensus networks with empty blocks turned into complex systems that rely on layers of infrastructure to enable a functioning and interoperable experience for developers and users alike.

Towards Modularity

A trend towards a modular architecture can be observed both in application-specific blockchain ecosystems like Cosmos, as well as in general purpose smart contract platforms such as Ethereum. Successful applications on Ethereum are historically relying on a variety of additional middlewares to deliver useful products and a superior user experience.

Examples of such middlewares include oracles (e.g. Chainlink), automation (e.g. Gelato), indexing networks (e.g. The Graph), as well as interoperability protocols (e.g. Wormhole). Such tools take on the form of a separate protocol with its own trust network: a set of rules, operators, and in most cases token economics - or are even provided in a centralised manner. An example of a crypto application that found product-market fit are DeFi money markets such as Aave:

A high-level representation of the Aave lending protocol liquidation flow; an exemplary interaction of different stacks interacting with each other.

The Road to Restaking

In addition to middleware, modular architectures can also help scale the throughput of blockchain systems by splitting up core functionality across different layers or simply through horizontally scaling (i.e. launching more chains/rollups). This approach stands in contrast to the original “world computer” vision of a single, composable state machine that handles everything. At this point, an integrated, monolithic design is predominantly being pursued by the Solana ecosystem, which seeks to maximise scaling through various hardware- and software-level optimisations.

Monolithic versus modular architectures.

One of the core problems in a modular blockchain paradigm is that you end up with lots of separate trust networks with their own tokens and security assumptions. This is especially a problem since to compromise an application, an attacker would often only need to compromise the network with the least economic security.

In addition, the complexity of bootstrapping a new trust network and interoperability between them are issues impacting the developer and user experience in the modular paradigm. Thus, we have started to see models emerge that seek to enable developers to leverage the operators of another network in exchange for a fee share and often other incentives. The design space of such shared security models is large and goes back to early sharding designs in Ethereum and the Polkadot parachain auction model. More recent examples include Eigenlayer-championed restaking, Cosmos-based concepts of Interchain Security and Mesh Security, Avalanche subnets, as well as shared sequencing.

At the deepest level, these approaches are comparable and try to achieve a similar outcome, which is lowering the cost of operation and increasing security for application developers by widening the scope of work and adding additional commitments required by node operators to sign off on. Broadly, there exist two ways of how protocols can delegate additional labor to operators:

Forced

A protocol can require operators to operate additional infrastructure (e.g. additional execution layers or middlewares) in order to be able to participate. This article refers to such additional infrastructure as “sub-networks”. An early practical example of this pattern in the crypto space was the Terra network, where validators had to run additional oracle middleware binaries to the consensus binaries already in place. This is also the approach taken by the initial implementation of Interchain (Replicated) Security, where - following a successful governance vote - the entire validator set of a Cosmos chain (with some caveats) has to run and opt into additional slashing penalties concerning a separate so-called consumer chain. Forced approaches lower flexibility and increase the infrastructure cost and strain on node operators. They also provide benefits for interoperability between sub-networks, as well as serve as a value accrual mechanism for the main network token, which is why they are a popular design.

Opt-in

The protocol may allow node operators to opt into specific sub-networks or define specific roles that they can opt into. With this method flexibility for node operators is maintained, thus allowing for improvements in efficiency and allowing for broader participation increasing decentralisation. On the other hand, there are implications for sub-network interoperability and security assumptions in general. Eigenlayer restaking is the prime example of an opt-in design that seeks to expand the functionality provided by Ethereum node operators.

Visualising the different approaches of labor aggregation. In forced models, all 3 operators need to operate infrastructure for network A and B to receive rewards. In an opt-in design like restaking, operators choose the networks/roles they support, in this example operator 1 opts into network B&C, while operator 2 opts into network A&B (AVS in Eigenlayer terminology).

The Operator Perspective

As we have seen, the emerging modular ecosystem has enabled fast paced innovation and brought powerful applications to the crypto space. This expanding ecosystem leads to complex network topologies that present various tradeoffs to infrastructure providers who need to make decisions on which networks they support based on their available resources and network-specific cost and risk/reward calculations.

In the following, I will be exploring the trade-offs inherent in shared security models from the perspective of two types of infrastructure operators: solo stakers and professional staking provider companies.

The Solo Staker View

Solo stakers are defined as individuals that want to participate in securing networks they support by running infrastructure on their own setup and predominantly with their own tokens.

The solo staker view of shared security models.

The Staking Provider View

Professional staking providers are incorporated for-profit entities that operate infrastructure for a variety of Proof-of-Stake networks and rely on delegations from token holders such as foundations, institutional investors, and retail token holders, as well as aggregators such as liquid staking protocols.

The staking provider view of shared security models.

Conclusion

To avoid fragmentation of security, the crypto ecosystem has conceptualised different models of sharing security between blockchain networks. Opt-in models like restaking provide flexibility by allowing operators to specialise and to make more granular economic decisions, while in forced models the network at large is making choices for all of its underlying operators.

This flexibility may help to bring about a more diverse and decentralised ecosystem on the one hand because it becomes feasible for smaller operators to take part and, on the other hand, larger operators are able to provide differentiated staking products based on their sub-network curation.

Finally, liquid (re)staking protocols and other aggregators could in the future play a coordinating role of assigning labor to operators seeking to provide the optimal user experience and risk-adjusted returns to token holders by abstracting away the complexity of sub-network and operator choice.

Disclaimer：

1. This article is reprinted from [mirror]. All copyrights belong to the original author [Felix Lutsch]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.