✓ SubscribeSubscribers: 274
RG Analitics 🟢 [PRIVATE CHANNEL🔒]
What Is Replicated Security?
Replicated Security (RS) is a new technology that lets a Cosmos blockchain share its economic security with another using the Inter-Blockchain Communication protocol (IBC). Replicated Security recently launched on the Cosmos Hub, and has already attracted applications from Neutron and Stride, two projects looking to secure their respective blockchains using replicated security.
As opposed to the Ethereum ecosystem, where every application is a set of smart contracts on a shared blockchain, in Cosmos, every application can have its own dedicated appchain. This approach allows developers to tailor the blockchain to the needs of their applications. It can not only help improve performance and user experience but also makes appchains responsible for their own security.
As a result, launching applications as appchains can be difficult or costly. It requires attracting a set of validators with inflationary token rewards while ensuring that the value of the staked token remains sufficiently high to deter attacks.
Replicated security provides a solution to this challenge by enabling developers to leverage the Cosmos Hub’s established validator set and its staking token, $ATOM while retaining the ability to customize their blockchain.
How Does Replicated Security Work?
Cosmos blockchain is secured by Proof-of-Stake, a consensus mechanism in which computers, called validators, compete for the right to propose the next block of a blockchain (and earn the associated reward) by staking valuable native tokens. If a validator misbehaves, the blockchain can punish them by slashing a portion of their tokens.
Replicated security adds to this mechanism, but across multiple blockchains: the Provider Chain provides the validator set and staking token, and the Consumer Chain provides rewards and checks that validators are not misbehaving.
This requires communications between the Provider and Consumer chains, which are handled by sending messages over IBC. For example, the Provider chain regularly sends information about validators and their stake to the Consumer chains. If a validator misbehaves, the Consumer chain sends a message to the Provider chain to trigger the slashing of their tokens.
Replicated Security (RS) is a new technology that lets a Cosmos blockchain share its economic security with another using the Inter-Blockchain Communication protocol (IBC). Replicated Security recently launched on the Cosmos Hub, and has already attracted applications from Neutron and Stride, two projects looking to secure their respective blockchains using replicated security.
As opposed to the Ethereum ecosystem, where every application is a set of smart contracts on a shared blockchain, in Cosmos, every application can have its own dedicated appchain. This approach allows developers to tailor the blockchain to the needs of their applications. It can not only help improve performance and user experience but also makes appchains responsible for their own security.
As a result, launching applications as appchains can be difficult or costly. It requires attracting a set of validators with inflationary token rewards while ensuring that the value of the staked token remains sufficiently high to deter attacks.
Replicated security provides a solution to this challenge by enabling developers to leverage the Cosmos Hub’s established validator set and its staking token, $ATOM while retaining the ability to customize their blockchain.
How Does Replicated Security Work?
Cosmos blockchain is secured by Proof-of-Stake, a consensus mechanism in which computers, called validators, compete for the right to propose the next block of a blockchain (and earn the associated reward) by staking valuable native tokens. If a validator misbehaves, the blockchain can punish them by slashing a portion of their tokens.
Replicated security adds to this mechanism, but across multiple blockchains: the Provider Chain provides the validator set and staking token, and the Consumer Chain provides rewards and checks that validators are not misbehaving.
This requires communications between the Provider and Consumer chains, which are handled by sending messages over IBC. For example, the Provider chain regularly sends information about validators and their stake to the Consumer chains. If a validator misbehaves, the Consumer chain sends a message to the Provider chain to trigger the slashing of their tokens.