Implementing account abstraction as part of eth1.x

[vbuterin]

@danfinlay

Just curious how you came up with the 400k gas limit suggestion for the verification stage. Since the current ECRECOVER cost is only 3k, this does seem to increase the cost of verifying a transaction significantly, which in theory could create a DDoS vector if too high.

Good question! I was setting that to be high enough to be able to verify a SNARK in the verification step (I’ve heard numbers around 200-300k gas). Unfortunately SNARK-verification isn’t really trancheable in the way that you describe so just running up to 400k gas pre-inclusion-guarantee may be the only approach…

I think I lean towards removing the hash invariant, since nonces introduce a real choke point, but I’d love to enumerate the drawbacks more (hard to look up a tx with shared hashes).

Makes sense! Though it’s client devs that would have to do a bunch of hard work if the hash invariant gets removed, so would be good to hear from them on this point.

I’d also note that another way to get around the issue is to have separate “publication-time identifiers” (hash(tx)) and “inclusion-time identifiers” (hash(target, nonce, tx)), where the former are not guaranteed to be unique but the latter are. Then in the normal case, you can predict the inclusion-time identifier at publication time, but in special cases where that’s not true application devs could come up with other techniques.