Skip to content

Latest commit

 

History

History
95 lines (52 loc) · 9.26 KB

unified_security.md

File metadata and controls

95 lines (52 loc) · 9.26 KB

A Unified Security Layer

Authors: Don Dall, Firat Sertgoz

Abstract

We are beginning to see a Cambrian explosion of restaked security systems pioneered by Eigenlayer.

These systems aim to improve and bolster the cryptoeconomic security of protocols and applications by facilitating the attestation from networks verifying the blockchain itself.

Each restaking provider has semantics, nuances, and integration guidelines specific to their network.

GQ7_9xbXcAEm34A Reference

For widespread adoption to occur, we need to be able to share security subsystems, pick and experiment with providers, and potentially even join the use of one provider with another, depending on supported features, ideological alignment and appetite for risk.

With each new provider, there are new features and semantics that a higher-level purchaser or delegate would have to understand.

This type of integration becomes a technical burden and requires technical expertise.

The Case for Unification

As the number of restaking protocols grow, the total amount of available security gets fragmented. Without unification, all participants in the restaking ecosystems will suffer from different problems. Unification provides some features we could not innovate with as a single provider. If we accept there is a need for room to experiment in isolation with application-specific use cases, this allows some interesting avenues to solve problems:

  • Not enough stake: A Bank could require a large amount of borrowed security from many operators that require exclusivity to the slashable stake to provide economic security guarantees over a Proof-of-Custody protocol. This exclusivity requirement would be problematic since the total available security to purchase could be reduced to a single service. In EigenLayer, tasks requiring stake are purchased for a finite period, and this introduces some form of 'fair use' policy, as we currently see through whitelist mechanisms. This policy opened avenues for purchasers who want to onboard and experiment quickly.
  • Asset Variety: An institutional operator with multiple assets usually validates many blockchain protocols. This opportunity allows them to attest to many different systems and provide cryptoeconomic security via the unification layer. Some protocols have come to market that have supported other assets that are not canonically supported by others. This unification layer would allow node-operating businesses to delegate once, and the system can support and attest all supported assets from all restaking providers.
  • Missed opportunity: Blockchain protocols that do not have a native restaking layer miss out on the chance to provide restaked security to their builders. To access the systems, they must integrate with them cross-chain and build expertise in each restaking system they want to support. This introduces opportunity cost, risk, and auditing requirements for the protocol. With a system where native delegates lock up their stake, and operators lock their validating keys to a Smart Contract on the native chain, they can delegate to the unification layer to attest for them based on their strategy.
  • Semantics of Restaking Protocols: Every restaking protocol defines its interface that service providers must adapt and integrate. This creates a bottleneck in value generation since service providers want to reach their customers as soon as possible with various assets. Unifying all restaking platforms in a unification layer significantly decreases the time to market for service providers.

Design space

There are a few ways to support unified interoperability with the systems:

  • Provide a common interface for the commissioning and consumption of security attestations for all providers. This approach is likely a long-term solution; however, since we are at an early stage, it would be helpful to have room for innovation and solve problems uniquely.
  • Introduce a unification layer for the agents in each security system to pool their attestations and aggregate them. This system would utilise the expertise of builders who understand the restaking paradigm and limit the burden on the external actors who want to purchase security, freeing them up to concentrate on their value generation. For operators, allowing them to become delegates means they can delegate all of their assets to a trustless operator set. Utilise account abstraction to ensure the attestation is delegated to the unification layer.

Unified Security Layer

We introduce a unified security layer that enables service providers to leverage any crypto-economic security from any restaking platform. Service providers only need to provide the service binary, validation semantics of their service, and their configuration. The unified security layer abstracts the orchestration of the services with different restaking protocols.

High-level Architecture Diagram:

Below is our initial birds eye view of the architecture.

final big

Restaking platform interaction Diagram:

The below diagram is zoomed in to represent the interaction flow for different actors.

final_flow

What is in it for existing users?

The answer to this question depends on the type of participant asking.

Delegators:

Delegators can now delegate all their assets on one unified platform and interact in one place. There is no need to search for services and deal with operators to build trust. Operators can earn trust in a unified system, and you can transparently see an operator's reputation stake and network participation.

Delegators can set adaptive strategies and have power over their assets. As the system is an open market, they can access GTM-style applications and earn the most significant yield, which is usually reserved for Genesis operators.

Service Providers:

Due to the competitive marketplace, an application can now determine its security parameters, the tokens involved, slashing logic, and rewards and then be at ease. You do not need to delve deeper into the specific platform or hire protocol engineers for each re-staking solution.

With this, you can set and forget it, ensure security, and continue innovating.

Operators:

Consider becoming a delegator if the expenses of running all the validator software are unsustainable in the long term or if they operate a node enterprise and aim to cut costs without depending on Infura.

If operators want to continue making money from their existing infrastructure, they have the option to run the infrastructure and also deploy a few components:

  • An Application Oracle: Operators can provide this service and charge based on the number of requests. Other solo stakers may not run a service binary but still wish to act as a superdelegate.
  • A Threshold Signing node: Operators may choose to operate a threshold node and implement various strategies based on their portfolio. They could selectively sign specific service outputs without relying on another oracle.
  • A Keyper Guardian: They might be interested in becoming a keyper and participating in the community. Keypers ensure the system's liveness by running and signing on behalf of all services that the community has reviewed. As keypers, they can earn a reputation and leverage their experience and influence within the community to guide the network.

They can also now use their other nodes' validator stake to participate in restaking subsystems. Keypers could delegate their Cardano Withdrawal Certificate to shared security, and we can bolster additional systems while continuing to stack yield.

Restaking Protocols:

New protocols might not have enough liquidity in their ecosystem for a particular type of application and are struggling to bolster DeFI in the system. With this, protocols can now cherry-pick security from others while bootstrapping a budding DeFI space.

Current customers have to choose restaking protocols to run their services. This creates some lock-in regarding asset variety, and restaking protocols may lose out on the opportunity. If the service providers had the choice to have strategies that would allow using multiple restaking protocols, they would commit to both to increase their service security. With Unified Security, we aim to remove this 'vendor lock-in' for service providers and 'opportunity cost' for restaking protocols.

End-Users

In a world where any restaked asset from any restaking platform can be utilised, users should have the opportunity to have a say in the underlying asset protecting the service they are using. This opportunity is akin to 'choosing a chain', but a lot more flexible since the strategy that secures the service can be changed while keeping the service still alive.

Open platforms bolster innovation. In a world where a service can choose from whatever restaking platform, the speed of innovation will increase, leading to many more dApps that the end-users can participate in.

What is next?

Nuffle Labs is actively researching and incubating a Unified Security Layer that would benefit the whole industry. We aim to introduce new capital opportunities to users and rapidly expand the innovation space for builders. Nuff' Security, Break the silos.