In past post about Elrond available [here](https://steemit.com/elrond/@bob-elr/vital-components-of-elrond-s-chain-secure-proof-of-stake-spos-series-3), I received question paramount to how security is instill in Elrond's network against known attack and possible future ones. So i decided to prepare this post to answer the very vital questions I received from friends. This part is technical aspect of Elrond's [WhitePaper](https://elrond.com/files/Elrond_Whitepaper_EN.pdf). There is need to gain insight into how exactly the architecture works so as to fully understand it's potentials.

Question

Answer

--------------------------- | ------------------------ By **@Jully3722** **[[Lnk]](https://steemit.com/elrond/@bob-elr/vital-components-of-elrond-s-chain-secure-proof-of-stake-spos-series-3#@jully3722/re-bob-elr-2019722t12266970z)** After reading your other articles about elrond,my question here is what if a shard fails to come up or there are some majority of the nodes are offline, would that affect the entire system? | This in particular is resolved through a method termed **Shard Redundancy** *(ie a part of the shards, etc., that has the same function as another shard and that exists so that the entire system, will not fail if the main part fails)*. A pattern of Sharding called *State Sharding* attributable to Blockchain is prone to failure. That is, where exist an insufficient nodes in shards online to reach consensus (ie where more than 1/3 of nodes are non-responsive). There, is possibility of high risk that the whole design depends majorly on super-full nodes that download in full every block of all shards in existence and verify everything. See as depicted in image below. Considering all of this, Elrond protocol comes with a protection mechanism that introduces a barter **in the state holding structure by enforcing the shards from the last tree level to also hold the state from their siblings.** By this, there is reduction in the communication flow and thus eliminating the bootstrapping when sibling shards are merging since they already have the data. **Question 2.** Is there possibility of members of the consensus to form a malicious set and launch an attack compromising the system? And what is the way out if this happens? | This, although rare, may happen. To soften it, a system was introduced to preserve security in sharded permissionless blockchains (public blockchains) which reshuffles and reallocations active nodes between shards at a fixed time interval using a designed random criteria. This approach is termed **context switching** which is an improvement in the security state. As good as it is, it poses complexity in structure required to maintain consistency between multiple states. **`The state transition has the biggest footprint on performance since the movement of active nodes requires to resync the state, blockchain and transactions along-side the eligible nodes in the new shard.`** Beginning of each epoch, only less than one-third of these nodes will be uniformly re-distributed across shards. This happens to maintain liveness of nodes in Shards. And is proven to effectively form a shield against malicious formation. **** ![Screenshot_20190722-112014.png](https://cdn.steemitimages.com/DQmPMeSMKW8rJbQ7i12vpyfgkhY6Uo4fHudhVagC8np5qdo/Screenshot_20190722-112014.png) ****

For More information

**** **[YOUTUBE](https://www.youtube.com/channel/UCRLKQHcjuWW_-JOZ-DqQTXw)** | **[TWITTER](https://twitter.com/elrondnetwork)** | **[MEDIUM](https://medium.com/elrondnetwork)** | **[TELEGRAM](https://t.me/ElrondNetwork)** ------------------------------------------------------------------------------ | ----------------------------------------------------------------------------- | ---------------------------------------------------------------------- | -------------------------------------------------------------------------------------- **** **[WEBSITE](https://elrond.com)** | **[WHITEPAPER](https://elrond.com/files/Elrond_Whitepaper_EN.pdf)** | **[ROADMAP](https://elrond.com/technology#roadmap)** -------------------------------------------------------- | ------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------- **** *All right reserved. This article is originally created by **@Bob-elr**. None of the contents of this post shall be used except for the images without the express permission of the Author* **** **@Bob-elr** . TG username: **@cryptopreach** **** ****