Kwxm/signature verification throughput statistics #4883
Conversation
|
Hmmm. It's failing in CI because cabal seems to think that |
|
This is great. Thanks a lot for the benchmarks. They are really helpful to define our strategy in the near future. I guess the decision of merging or not will fall back to the plutus team, but I find these really helpful, and wouldn't be surprised if they'll be helpful in the future. The fact that the script size is the bottleneck gives hopes that we can design the protocol in a way where we optimise the script size by a fraction. However, the CPU usage seems to indicate that the hard limit is at around 130 signatures (this assuming we don't do anything else in the script), which is also very good to know. |
Yeah, this is a weird thing that happens sometimes, just turn off |
| @@ -0,0 +1,213 @@ | |||
| -- editorconfig-checker-disable-file | |||
There was a problem hiding this comment.
I think we probably want to avoid introducing more of this :)
There was a problem hiding this comment.
Oh, I thought we had to put that in. How do we decide if it's necessary or not then?
There was a problem hiding this comment.
Hmph, I thought I had documetned this in CONTRIBUTING but apparently not. You only need this if editorconfig-checker complains at you and you're unwilling to fix it. I mostly put it in to grandfather in old files so I wouldn't have to fix literally everything.
|
|
||
| -- Create a list containing m bytestrings of length n (also terrible) | ||
| listOfSizedByteStrings :: Integer -> Integer -> [ByteString] | ||
| listOfSizedByteStrings m n = unsafePerformIO . G.sample $ |
There was a problem hiding this comment.
Why not use genSample that you just wrote?
There was a problem hiding this comment.
I just copied it in from elsewhere and didn't pay too much attentiion to what it was doing! I'll tidy it up though.
There was a problem hiding this comment.
genSample is unused anyway. I'll just remove it.
| mkInputsAsData :: Integer -> HashFun -> BuiltinData | ||
| mkInputsAsData n hash = Tx.dataToBuiltinData $ toData (mkInputs @Ed25519DSIGN n id hash) | ||
|
|
||
| -- Check conditions (1) and (2) mentioned above. We check these for all of the |
There was a problem hiding this comment.
| -- Check conditions (1) and (2) mentioned above. We check these for all of the | |
| -- | Check conditions (1) and (2) mentioned above. We check these for all of the |
not that it matters, just might as well make actual haddock comments
| verifyInputs hash d = | ||
| case Tx.fromBuiltinData d of | ||
| Nothing -> Tx.error () | ||
| Just (Inputs inputs) -> ver inputs True |
There was a problem hiding this comment.
we have all defined somewhere also, but this is more "bare metal" I guess
| convert it to Data, and feed that to a script which | ||
|
|
||
| 1. Verifies each (V_i, H_i, S_i) to check that the signatures are valid. | ||
| 2. Hashes each P_i to make sure that it matches H_i. |
There was a problem hiding this comment.
Is this something we actually need to do? do we not just work with the hashes normally? question for @iquerejeta probably
| Tx.getPlc $ $$(Tx.compile [|| verifyInputs Tx.sha2_256 ||]) `Tx.applyCode` Tx.liftCode (mkInputsAsData n Hash.sha2_256) | ||
|
|
||
|
|
||
| -- Protocol parameters (November 2022) |
There was a problem hiding this comment.
Maybe we should put this somewhere common in case we want to compare other stuff to it?
There was a problem hiding this comment.
I'm not sure what you mean. Put what somewhere common?
There was a problem hiding this comment.
These numbers corresponding to protocol parameters to test against. E.g. we have some tests that check for script sizes, we might want to also show what fraction of the max size they occupy.
There was a problem hiding this comment.
I see. We'd have to keep them updated. I wonder if there's anywhere we can look them up automatically? I just googled and got them from https://adapools.org/protocol-parameters.
There was a problem hiding this comment.
They don't have to be super up-to-date, it's fine to have some approximately-right numbers for things like this, I think.
There was a problem hiding this comment.
I'll make a ticket for that. I'm not sure where else we might want these and working that out's not very relevant to this PR.
There was a problem hiding this comment.
I moved those to near the top of the file so that they're easier to find.
|
OK, I'm going to merge this. It seems that it's just Cicero that's problematic. |
|
For reference, here are the earlier figures along with ones for verifyEd25519SignatureverifySchnorrSecp256k1SignatureverifyEcdsaSecp256k1Signature |
* WIP * Measuring ed25519 signature verification throughput * Address PR comments * More tidying up * Add test for Haskell version * Defeat short-circuiting in && * Restore editorconfig-checker-disable-file
(PLT-788) @iquerejeta is interested in how many Ed25519 signatures we can verify in a Plutus validation script. This adds a program to test that. I don't know if we want to merge it, but here it is anyway.
It does the following, which I think is roughly what Iñigo's interested in.
Generates n public keys P_1,...,P_n
Hashes them to get n hashes H_1,...,H_n.
Signs all of the hashes with different private keys K_1,...,K_n (with corresponding public keys V_1,...V_n) to get n
signatures S_1,...,S_n.
Creates a list of (V_i, H_i, S_i, P_i) tuples, convert it to Data, and feeds that to a script which
This program does that for varying values of n and prints statistics about the size, cpu cost, and memory cost of the script. The hashes are calculated using
sha2_256; I also triedsha3_256and that left the script sizes unaltered but increased CPU/memory usage by 1 or 2%.The results are shown below, both as absolute values and as percentages of the limits specified in the current protocol parameters. For script size, I've shown the percentage of the
max_tx_sizeparameter: this may include more than just the script, so the percentages may be a little optimistic. Anyway the main limiting factor seems to be the script size: we can get up to 90 or so signatures before we start to hit the limit. The data that we're checking account for most of the size of the script; I may have included too much stuff in the inputs, and if that's the case then it may be possible to squeeze in some more.