Implementing Replicated Security for a More Robust and Expansive Ecosystem
Abstract:
This OIP proposes the implementation of replicated security on the Onomy Network, enabling developers to deploy their app chains in Onomy’s ecosystem and be secured by the Onomy Validator Guild (OVG). For more information on appchains, read here. Traditionally, app chains require a team to attract and bootstrap a validator set. The integration of replicated security rids of that hurdle, enhancing Onomy ecosystem’s adoption by attracting new participants and app-chains, growing the number of teams working in the Onomy Ecosystem, diversifying the application set within Onomy, and facilitate seamless cross-chain communication and interoperability amongst all app-chains while providing interoperability with Cosmos IBC, EVM, and more via the Arc Bridge Hub. Validators in the OVG will secure additional app chains, and staking rewards plus fees from consumer app chains may be allocated toward parent chain validators and delegators of NOM.
Motivation:
The motivation behind this OIP is to leverage the replicated security feature to foster innovation and collaboration within the Onomy ecosystem. By simplifying validator management and providing a secure environment, Onomy can attract more developers, expanding its ecosystem and driving the growth and adoption of the Internet Financial System (IFS).
Specification:
- Integrate replicated Security via a chain-upgrade proposal. Develop guidelines and documentation for deploying app chains on Onomy using replicated security.
- Create an onboarding process for developers, including educational resources, support, and dedicated communication channels.
- Establish a mechanism for the Onomy Validator Guild to secure, onboard and monitor new app chains.
- Promote the adoption of replicated security and provide DAO-based incentives for developers to join the Onomy ecosystem.
Rationale:
replicated security offers a more robust and secure environment for app chains without the need for independent validator management. This simplification allows developers to focus on building and refining their applications while benefiting from enhanced security, seamless cross-chain communication, and interoperability.
- Full provider security. At launch, consumer chains are secured by the full validator set and market cap of the provider chain.
- Independent block-space. Transactions on consumer chains do not compete with any other applications. This means that there will be no unexpected congestion, and performance will generally be much better than on a shared smart contract platform such as Ethereum.
- Projects keep the majority of gas fees. Depending on configuration, these fees either go to the project’s community DAO, or can be used in the protocol in other ways.
- No validator search. Consumer chains do not have their own validator sets, and so do not need to find validators one by one. A governance vote will take place for a chain to get adopted by the provider validators which will encourage participation and signal strong buy-in into the project’s long-term success.
- Instant sovereignty. Consumers can run arbitrary app logic similar to standalone chains. At any time in the future, a consumer chain can elect to become a completely standalone chain, with its own validator set.
Validator & Constitute Delegator Benefits
Consumer chains have the option of sharing their block rewards (inflation tokens) and fees with provider chain validators and delegators. In replicated security block rewards and fees are periodically sent from the consumer to the provider according to consumer chain parameters using an IBC transfer channel that gets created during consumer chain initialization.
Reward distribution on the provider is handled by the distribution module - validators and delegators receive a fraction of the consumer chain tokens as staking rewards. The distributed reward tokens are IBC tokens and therefore cannot be staked on the provider chain.
Reference
Security Considerations:
Implementing replicated security onto the Onomy Network requires careful consideration of potential security risks and implications. The Onomy Validator Guild must be prepared to handle the increased workload of securing and monitoring new app chains. Replicated Security does allow for validators to operate consumer app chains on the same machines as the parent chain, however, it is recommended to use additional machines so that a machine failing does not compromise the entire operation. It could be the case that validators choose to host on the same machine, then move to a separate machine as the consumer chain(s) grow larger. Validator opt-out is not currently available, but may be in future. Replicated Security’s code is written by a collection of teams working on decentralized technology in Cosmos. Additionally, guidelines and documentation should outline best practices for developers to minimize potential security risks while deploying their app chains.
STATUS: INTEGRATED ON MAINNET