# Why not EIP-1011 (Hybrid Casper FFG)? EIP 1011 along with the previous version of sharding that utilized the sharding manager contract (SMC) both relied upon adding new _protocol level contracts_ into the existing EVM. There are multiple reasons that these two independent approaches were deprecated in favor of the combined casper+sharding (shasper) design. ### Processing signatures The main bottleneck in designing either of these systems into the existing EVM was going to be signature and tx processing. Each validator interaction with the Casper or SMC contract had to come in as a tx and then be processed by the EVM. The EVM is not so efficient at processing cryptographic signatures so the number of validators that could participate would be limited -- thus, the 1500ETH minimum requirement for EIP-1011 validators. The minimum requirement to participate was to ensure that the system did not have too many validators such that clients couldn't process their signatures in time. This same signature processing issue was also capping the number of validators and the number of shards the SMC could handle. By moving away from EVM signature processing and by utilizing a new BLS aggregate signature scheme, we can greatly reduce the minimum ETH required to participate (32 ETH) and greatly increase the number of participants. The more validators, the more decentralized the network can be. ### Two competing games Having both a Casper contract and an SMC, Ethereum would have had two system level contracts with two different (competing) system level games and sets of validators. These two games would have different requirements and different reward schemes, and would thus run the risk of having large asymmetries between the two. If a disproportionate number of validators showed up for the SMC, then the core consensus would have been less secure. If a disproportionate number of validators showed up for Casper, then the shard security might have been at risk. By combining the two games in one, we get to more cleanly incentivize validators and capture the total security of the ETH deposited for both the core PoS consensus and shard chains. ### Issues in tx parallelization Another less talked about reason for the deprecation of EIP-1011 is the parallelization of casper `vote` txs with normal block txs. The premise of parallelization of vote txs with normal txs was flawed. The Casper contract was going to have to be massively modified to hide certain intermediate state from txs but still expose it to clients (via some read only functions from some privileged addr). The EIP also was going to have to be reworked to have a business logic period and a vote period every epoch. Registration, slashing, logging out, etc would happen during business logic. Voting would happen in other period. All of this would have introduced nontrivial changes to client implementations, but more importantly it was going to require major surgery on the contract which would have thus required an almost fresh start on the formal verification effort which took approximately 4 months. The resulting casper contract would have been made very messy to accommodate these changes and much harder to understand/audit. This also was going to significantly set back development and ultimately the release of EIP-1011.