# BLS In Ethereum ## Situation Overview ### Every Ethereum client will need to integrate BLS prior to The Merge Ethereum's Proof of Stake system uses BLS, and when The Merge happens every Ethereum client that wants to move over to PoS will need to have a BLS implementation that is used on the critical path to consensus. (TODO: check with experts for details) ### Ethereum client teams do not have in-house BLS/cryptography expertise The current Ethereum clients (Geth, Nethermind, OpenEthereum, etc.) do not have in-house cryptographers who are able to rapidly respond to any BLS related consensus failures that may pop up in production. This creates a problem because production consensus failures require very rapid response and it may not be possible to rapidly find the right people to debug and fix any production BLS bugs. ### There are a number of use cases where BLS would add significant value to Ethereum prior to The Merge * Interaction with Beacon Chain prior to The Merge (TODO: check with experts for details) * Some ZK systems and rollups that would allow for better scaling and privacy protection solutions. (TODO: check with experts for details) ## Assertions ### Client teams must eventually integrate BLS Due to The Merge requiring BLS integration, the only options for client teams are: 1. don't move to PoS 2. try to convince Ethereum 2 to not use BLS 3. integrate BLS into their clients by The Merge at the latest. I don't think any client teams have an intention of dropping PoS and I don't think it is realistic to ask PoS to drop BLS at this point. This only leaves "must integrate BLS eventually" as the only remaining viable option. ## Risk Mitigation Strategy Include BLS as a precompile ASAP (after Berlin?), but as a sort of "beta" where the core developers have the right to disable it for a duration that lasts as long as "until The Merge". If a consensus failure occurs whose root cause is tracked to a problem with one of the clients' BLS implementations, then the core developers retain the "right" to disable the precompile as a short term remedy. After it is disabled, experts can be called in outside of an emergency and we can schedule re-enabling of the BLS precompile in a later hard fork, after the issue has been debugged and fixed. For people building against the precompile, they would need to design systems that are resillient to being offline/unavailable for extended periods (up to years). This does prevent some things from being built such as things with fraud proof windows, but there are plenty of other things that can be built such as wallet contracts and zkRollups. Once The Merge happens, this option to disable the precompile is taken off the table since BLS is required for consensus to progress. This solution gives us a potentially long period of time (between now and The Merge) where we can "test BLS in production" without taking on the risk of having to troubleshoot it in the middle of the night without the appropriate expertise on hand.