We’re considering whether or when Arbitrum should support BLS signatures, on the BLS 12-381 curve, on transactions.
The main advantage is that this allows the sequencer to aggregate signatures so that an entire batch of transactions can carry a single (probably) 48-byte BLS signature, rather than a separate 65-byte ECDSA signature on each transactions. This would lower costs by reducing the L1 data footprint.
The main disadvantage, at this time, is that this would require defining a new transaction format which would not be supported by wallets and other tooling, at least at first. Ethereum may eventually standardize on such a format, but that seems unlikely to happen soon. So we would be implementing in advance of any Ethereum-wide standards process.
Perhaps other teams are willing to work with us on a jointly proposed standard.
This isn’t difficult to implement as a feature in Nitro.
There are references in the various readme files to setup testing for Arbitrum, along with the gas cost savings that can come from these signatures, but the documentation on how to setup the environment is lacking. I Will continue to plug away at configuring the env files to see if I can get the tests running. Maybe others will have more success than I have, or have better testing references, if so please share.
Is my question as well. BLS signatures look like an inevitable but great feature to add. In this testing I am looking to figure out what the upgrade process for current users’ tooling would be, and what could be built with this feature already implemented. Anyone with more insight on how to test and develop for BLS on Arbitrum would be much appreciated!
The main practical barrier to implementing BLS signatures is the lack of support in wallets and other user/developer side tooling. Without that support, there isn’t much urgency to support BLS on the Arbitrum chain side.
We’d be happy to talk to anyone who is interested in changing that.
Creating a custom BLS solution for Arbitrum would indeed get friction, as wallets are very slow to adapt new formats.
My suggestion is to consider using EIP4337 (account abstraction).
We are currently in the process of adding BLS support to it (there is an open PR to add signature aggregation interface and BLS implementation)
There are some significant advantages to having the sequencer do BLS signature aggregation. The biggest one is that the sequencer can wait until it knows exactly which transactions will be in a batch, then aggregate the BLS signatures over the whole batch. That gives the optimal total signature size, of one signature per batch (plus any ECDSA signatures from non-BLS transactions).