From cbe5af763cebb834f3e8d74a538b802747fcc605 Mon Sep 17 00:00:00 2001 From: William Banfield Date: Wed, 4 May 2022 18:13:04 -0400 Subject: [PATCH] add section on light client changes, circl, and current considerations --- docs/rfc/rfc-018-bls-agg-exploration.md | 66 +++++++++++++++++++++++-- 1 file changed, 62 insertions(+), 4 deletions(-) diff --git a/docs/rfc/rfc-018-bls-agg-exploration.md b/docs/rfc/rfc-018-bls-agg-exploration.md index 7997be965..e60c7ecb4 100644 --- a/docs/rfc/rfc-018-bls-agg-exploration.md +++ b/docs/rfc/rfc-018-bls-agg-exploration.md @@ -239,6 +239,11 @@ I cannot find support listed for Google Cloud, although perhaps it exists. ## Feasibility of implementation +This section outlines the various hurdles that would exist to implementing BLS +signature aggregation into Tendermint. It aims to demonstrate that we _could_ +implement BLS signatures but that it would require breaking changes for a +reasonably unclear benefit. + ### Can aggregated signatures be added as soft-upgrades? In my estimation, yes. With the implementation of proposer-based timestamps, @@ -307,7 +312,16 @@ being upgraded to parse and verify BLS. If chains upgrade without their counterparties first updating, they will lose the ability to interoperate with non-updated chains. -### Rogue key attack prevention +### New attack surfaces + +BLS signatures and signature aggregation comes with a new set of attack surfaces. +Additionally, it's not clear that all possible major attacks are currently known +on the BLS aggregation schemes since new ones have been discovered since the ietf +draft standard was written. The known attacks are manageable and are listed below. +Our implementation would need to prevent against these but this does not appear +to present a significant hurdle to implementation. + +#### Rogue key attack prevention Generating an aggregated signature requires guarding against what is called a [rogue key attack][bls-ietf-terms]. A rogue key attack is one in which a @@ -337,7 +351,7 @@ to proceed more quickly, since all signatures are over identical data and can therefore be checked using an aggregated public key instead of one at a time, public key by public key. -### Summing Zero Attacks +#### Summing Zero Attacks [Summing zero attacks][summing-zero-paper] are attacks that rely on using the '0' point of an elliptic curve. For BLS signatures, if the point 0 is chosen as the private @@ -391,9 +405,14 @@ At the moment, there is one candidate, `blst`, that appears to be the most mature and well vetted. While this library is undergoing continuing auditing and is supported by funds from the Ethereum foundation, adopting a new cryptographic library presents some serious risks. Namely, if the support for the library were -to be discontinued, Tendermint may become saddle with the requirement of supporting +to be discontinued, Tendermint may become saddled with the requirement of supporting a very complex piece of software or force a massive ecosystem-wide migration away -from BLS signatures. +from BLS signatures. + +This is one of the more serious reasons to avoid adopting BLS signatures at this +time. There is no gold standard library. Some projects look promising, but no +project has been formally verified with a long term promise of being supported +well into the future. #### Go Standard Library @@ -414,12 +433,50 @@ initial audit by NCC group, a firm I'd never heard of. cryptography. It is not audited and is documented as 'as-is', although development appears to be active so formal verification may be forthcoming. +#### CIRCL + +[CIRCL][circl] is a go-native implementation of several cryptographic primitives, +bls12-381 among them. The library is written and maintained by Cloudflare and +appears to receive frequent contributions. However, it lists itself as experimental +and urges users to take caution before using it in production. + +### Light Client Change + +Implementing BLS signature aggregation in Tendermint would pose issues for the +light client. The light client currently validates a subset of the signatures +on a block when performing the verification algorithm. This is no longer possible +with an aggregated signature. Aggregated signature verification is all-or-nothing. +The light client could no longer check that a subset of validators from some +set of validators is represented in the signature. Instead, it would need to create +a new aggregated key with all the stated signers for each height it verified where +the validator set changed. + +This means that the speed advantages gained by using BLS cannot be fully realized +by the light client since the client needs to perform the expensive operation +of re-aggregating the public key. + ## Open Questions * *Q*: Can you aggregate a signature twice and still verify? * *Q*: If so, how much cost may be imposed by re-including signatures into the same * *Q*: Can you aggregate Ed25519 signatures in Tendermint? +## Current Consideration + +Adopting a signature aggregation scheme presents some serious risks and costs +to the Tendermint project. It requires multiple backwards-incompatible changes +to the code, namely a change in the structure of the block and a new backwards-incompatible +signature and key type. It risks adding a new signature type for which new attack +types are still being discovered _and_ for which no industry standard, battle-tested +library yet exists. + +The gains boasted by this new signing scheme are modest: Verification time is +marginally faster and block sizes shrink by a few kilobytes. These are relatively +minor gains in exchange for the complexity of the change and the listed risks of the technology. +We should take a wait-and-see approach to BLS signature aggregation, monitoring +the up-and-coming projects and consider implementing it as the libraries and +standards develop. + ### References [line-ostracon-repo]: https://github.com/line/ostracon @@ -448,3 +505,4 @@ development appears to be active so formal verification may be forthcoming. [eth-2-adoption]: https://notes.ethereum.org/@GW1ZUbNKR5iRjjKYx6_dJQ/Skxf3tNcg_ [bls-weil-pairing]: https://www.iacr.org/archive/asiacrypt2001/22480516.pdf [summing-zero-paper]: https://eprint.iacr.org/2021/323.pdf +[circl]: https://github.com/cloudflare/circl