Motivation:
Presently, Fuel uses secp256k1 elliptic signatures for witness verification in Fuel. This requires including 65 byte signatures for each transaction. Ethereum is currently very expensive, and every byte ends up costing users greatly.
Fuel would like to use BLS12-381 when ready with our smart-contract system, this would allow for the removal of a vast majority of signature data in Fuel blocks.
Problem Point:
One issue with using aggregate signatures in the current Fuel architecture is that Fuel uses a system of both block producer included metadata (block number, transaction index, output index, 5-7 bytes) and UTXO hash data (32 bytes) for each input spent. To save data, we remove the UTXO hash data as it is implied by verification reduction from the metadata.
This makes verifying and determining has the witness signed over the provided data straight forward.
- Bring each full transaction proof for each input
- Reduce the hash for that input provided
- Reduce signature over provided transaction data with hashes derived
When we introduce aggregate signatures, this becomes more problematic, because if you remove the transaction data and the signature data, you must provide all data and all public keys for signed over by the aggregate signature. This means bringing the transaction proofs for all inputs spent in all transactions signed over by that aggregate signature proof (potentially 32 * 8 transaction proofs to validate one signature in a single round fraud proof). This would be extremely costly to reduce in one round.
Put simply, you cannot use a single round fraud proof style game to validate signatures for BLS in Fuel.
Proposal:
We would like to use aggregate signatures like BLS12-381 to remove the signature data in Fuel and enforce signature correctness using a very simple interactive verification game, which both allows the removal of UTXO hashes from Fuel transactions and signature data on a per-transaction bases.
One aggregate signature will be provided for groupings of 32 or less transactions (less in the case a block has less than 32 transactions).
One Merkle root will be posted, with the leafs of that tree being the transactionId's for each of the transactions (note, this will be used for the IVG) and a hash of the list of public keys used for that transaction.
Interactive Verification Game:
If an aggregate signature is incorrect in a group:
If any of the committed UTXO data does not derive (invalid internal Merkle root):
- Player 1 (fraud prover) will begin the game, and ask Player 2 (block producer) to reveal any of the requested transaction index leafs within that group.
- Once that leaf is revealed, Player 1 can show that either the transactionId/public keys committed to in the Merkle root is either valid by single round fraud proving or fraudulent (i.e. not what the output specifies)
- This can be used to show a single transaction has not been appropriately witnessed, without having to provide all public keys and UTXO hashes per group on-chain.
If the committed data is now derivable or known and incorrect:
- All public keys, transactionId's and UTXO hashes used for that commitment/group are provided (verified by the Merkle root derivation)
- The aggregate signature is can be deemed valid or invalid to any of the public keys provided
Notes:
Currently, Ethereum only supports a form of BLS via the altbn_128 precompiles with less than 100 bits of security. Which we have deemed not secure enough for Fuel.
BLS12-381 is on the way with more than 100 bits of security, but will likely not be ready for use until end of year 2021 at best.