refactor: cleanup ed25519_verify #7955
Conversation
* Align doc comment with other host functions (not that we are super-consistent here) * Align code style with other host functions * Reduce some duplication from tests * Add tricky test-cases where a value of the wrong length is read from the register.
|
cc @blasrodri |
|
After this PR is done merged, I think what's left is only estimator work. @jakmeier sounds like a good chance to write some docs on how to add estimations :) |
LGTM |
| let num_bytes = msg.len(); | ||
| self.gas_counter.pay_per(ed25519_verify_byte, num_bytes as _)?; | ||
| let message = self.get_vec_from_memory_or_register(message_ptr, message_len)?; | ||
| self.gas_counter.pay_per(ed25519_verify_byte, message.len() as u64)?; |
There was a problem hiding this comment.
FWIW, this is something I am not sure about: in which order should we load and charge for things? It seems not unreasonable to, eg, charge this after we load public key, so that we dont' charge if the pk is invalid.
Basically, I see two valid strategies:
- charges at the earliest possible point, as soon as we know parameters
- as late as possible, right before we execute operation which is being charged for
I don't see any important differences between the two, though they are definitely observable.
There was a problem hiding this comment.
That's a good point. I agree that it doesn't matter from a security perspective.
Since the order is part of protocol spec, perhaps the more important question should be which order is more natural for (future) client implementations. But I think here it doesn't matter. We dictate the order in which parameters are read anyway because get_vec_from_memory_or_register charges gas and could fail. So, I don't really see a difference, any choice seems to be fine.
Co-authored-by: Jakob Meier <mail@jakobmeier.ch>
* Align doc comment with other host functions (not that we are super-consistent here) * Align code style with other host functions * Reduce some duplication from tests * Add tricky test-cases where a value of the wrong length is read from the register. #7567
* Align doc comment with other host functions (not that we are super-consistent here) * Align code style with other host functions * Reduce some duplication from tests * Add tricky test-cases where a value of the wrong length is read from the register. #7567
#7567