# Building towards a “99%” Fault Tolerant Sharded System
Article [from](https://preview.redd.it/wgqu31u8smr71.jpg?width=800&format=pjpg&auto=webp&s=84e0bd15e728f3fa9687994be4d3b1a7a4a14b40) ethresear, interview with Robert sasu
The security of our network is of paramount concern to us, thus we are starting a series of posts that discuss our robust design. For a start, this article answers two important questions that came up during our recent interactions with developers.
**Q**: **How do you mitigate if a malicious group creates a signed block with bad cross-shard transactions ?**
I will start with explaining the minimal requirements of our system. At the first day of the launch, Elrond protocol will have at least 800 validators, 400 for a shard and another 400 for metachain. We have a requirement that any shard has to contain at least 400 validators, otherwise the shard will not be created, or it will be merged with another.
A few more highlights:
* BFT requirement / assumption 75% of the total nodes are good actors;
* Probabilities are calculated with the assumption that 25% of nodes are malicious. On shard level we accept a maximum of 33% of malicious nodes. Calculations are done with 10 shards, 4000 nodes from which 1000 are malicious.
* The initial validator to shard allocation is random, randomness source for comes from the metachain. When a new validator comes in, it is allocated at random to an existing shard. At most 30% of the nodes are reshuffled at the end of every epoch;
* The consensus group size in metachain is 400, the leader changes at every round (5 seconds), in order to sign a block ⅔+1 has to sign it, which is 267 validators;
* The consensus group size in a shard is 63, it is selected at random from the 400 buffer, changing at every round. ⅔\*63 + 1 equals 43 — needed validators to sign a block.
* The random seed is a...