Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Gas-efficiency improvements #2

Open
Arachnid opened this issue Jul 19, 2020 · 2 comments
Open

Gas-efficiency improvements #2

Arachnid opened this issue Jul 19, 2020 · 2 comments

Comments

@Arachnid
Copy link

We use this in ENS for verification of P256 signatures on DNSSEC records, and the gas cost of verifying a signature is a significant barrier.

We're interested in offering a bounty for work on improving the gas efficiency of the library. Would this be of interest? If not, do you know anyone else who might have the necessary skill to take such work on?

@tdrerup
Copy link
Owner

tdrerup commented Jul 19, 2020

Hi there,

I have been worried about the cost as well. Unfortunately, I myself do not have the time to work on this right now, nor do I know anyone who might.

One solution to this problem that I thought about was the following: Instead of actively verifying a signature, just publish it on chain alongside a temporary deposit. Add logic that allows anyone to kick off the signature verification on chain. If a signature is found to be invalid / does not pass verification, the deposit goes to whoever called the verification function.

If the deposit exceeds the costs of verification, the equilibrium should be that only valid signatures get posted since all invalid ones will be successfully challenged / invalidated. Once some time has passed without a valid challenge to the signature, the deposit gets refunded to whoever posted the signature. I suspect that the on-chain costs of this scheme should be substantially smaller than actively verifying signatures.

@Arachnid
Copy link
Author

That kind of challenge system will be viable for some applications; however, it adds a significant amount of complexity, and I don't think it's viable in our case.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants