Public keys using G2, real HashToCurve, Python implementation

[HarryR]

There are some improvements I've made:

• Adding a validator requires proof of ownership of the key
• When all validators sign the same message, no key aggregation is required (the aggregate key is computed when validators are added and removed)
• Removed usage of G1Point, G2Point etc. which caused lots of gas overhead
• Reduced gas cost of pairing2 operation

There are still some things which are inefficient:

• Key aggregation is slow, need to move key aggregation into XYZ coordinates with translation back to affine at the end
• Adding a validator costs about 500k gas

And some things which are missing:

• Tests using ethereum.tools.tester is currently broken
• Updated README.md file

I will see if I can add better tests, updated documentation and support for Travis CI etc.

[HarryR]

There may be another method to reduce cost of aggregating keys. You can have a positive bitmask and a negative bitmask.

By keeping track of the aggregate key when adding and removing validators you can avoid having to compute it every time a signature is checked in the special case where all validators sign the message.

But, when not all do, it may be cheaper to subtract the missing keys from the precomputed aggregate than it is to re-compute 'all but 1'. e.g. if you require a 2/3rds majority but there are some times when a validator may be temporarily offline or inactive, then removing just their key(s) will be much cheaper than recomputing all 253 or so keys (assuming the worst case)

[0xAshish]

yes @HarryR, I was thinking of having both bitmasks also looking for alternative ways as well like

• sending bitmask and aggregated pubkey itself( so at that time contract will do just pairing stuff) and will have a challenge period where people can aggregate offline and if it's wrong they can perform on-chain aggregation and slash validator. some other ideas like the delta[] of validator ids(which are unique integers)

[HarryR]

I really think that adding a 'game' here will add an unnecessary window of uncertainty where you could have proven finality, if you are set on that I will extract the useful code into a separate repository so it's not burdened with yet another poorly conceived finality game.

Adding 'slashing' sounds easy, but it really isn't - it introduces many economic problems, such as when the reward for a malicious actor exceeds the value being slashed, and means that the total value of any transfers happening at any given point in time should be at most the amount at-risk by the upstream validators.

In an ideal world, all of the validators sign each message and this eliminates the cost of aggregating keys on-chain, reduces complexity and the overall cost is about as low as it can get (a single pairing operation with two G1,G2 pairs)..

[0xAshish]

@HarryR agreed that's why paying a little bit of extra gas makes more sense, that's why still thinking of going with bitmask with on-chain aggregation. We can keep making some small optimizations if possible.