-
Notifications
You must be signed in to change notification settings - Fork 689
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
NEP-364 #7165
NEP-364 #7165
Conversation
Absolutely epic work 🙌🏿 For tracking we're missing:
|
As someone with the most context here, assigning self as reviewer here. Once the PR is ready for proper review, will do a detailed review and / or delegate as needed. |
@blasrodri: PTAL: https://near.zulipchat.com/#narrow/stream/295306-pagoda.2Fcontract-runtime/topic/NEP-364. There are some interesting discussions about this PR. |
@akhi3030 I've removed all non signature verification related code. So that hashing related functions are moved onto another NEP (will add it shortly). I'm not sure about #7165 (comment) |
…signature-verif-host-functions
Thanks @blasrodri! This comment in the zulip discussion was particularly interesting: https://near.zulipchat.com/#narrow/stream/295306-pagoda.2Fcontract-runtime/topic/NEP-364/near/289315918. We have to figure out how to make sure that all the validations are deterministic. I recommend having a chat with @evgenykuzyakov to further understand the concerns. |
Co-authored-by: Jakob Meier <mail@jakobmeier.ch> Signed-off-by: Blas Rodriguez Irizar <rodrigblas@gmail.com>
@jakmeier I just ran it on another machine (M1)
|
Yeah that looks about right. Good to see the uncertainty warning is gone now! But let's keep the numbers that you already had. The M1 platform is not suited well for our estimations for a number of reasons. And we will need to do fine-tuning anyway before stabilising this. I think the estimation part is looking good now for this PR. @matklad do you want to take another more holistic look at the code before we merge it? |
@matklad do you mind reviewing this PR again? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, missed all the repated repings here. In general, if I don't respond to a direct @mention within a day or to, please DM me on Zulip,
I think all the infrastructure is setup correctly here, so i suggest landing this. However, the actual implementation I don't think is quite right yet, but I suggest working on that in a follow up PRs.
runtime/near-vm-logic/src/logic.rs
Outdated
self.gas_counter.pay_base(ed25519_verify_base)?; | ||
let num_bytes = msg | ||
.len() | ||
.checked_add(signature_array.len()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
signature has a fixed size, so it doesn't makes sense to charge per-byte cost for it. So:
- don'd so this
check_add
here, use justmsg.len()
to charge per-byte cost. - move signature decoding
Signature::from_bytes(
right after reading the signature.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jakmeier conflicting suggestion here with regards to the byte cost:
/// ed25519_verify_base + ed25519_verify_byte * (num_bytes_signature + num_bytes_message)`
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right. I thought because we have sig_len: u64
as a parameter there is somehow a possibility that the signature length can vary now or maybe in the future. But I guess the function name makes it clear that this is only used with ed25519
which fully defines the signature and public key length.
I would say don't charge per-byte costs for PK and signature. Only for the message. And return Ed25519VerifyInvalidInput
if the input length is not equal to the corresponding constant.
Unfortunately, we still need both sig_len: u64
and pub_key_len: u64
as a parameters to decide on whether to read from a register or from memory. I would love to see something more elegant but cannot think of a simple solution. It's okay to keep them IMO.
runtime/near-vm-logic/src/logic.rs
Outdated
let signature = Signature::from_bytes(&signature_array).map_err(|e| { | ||
VMLogicError::HostError(HostError::Ed25519VerifyInvalidInput { msg: e.to_string() }) | ||
})?; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So this could fail for two reasons:
- wrong lenght of the sgnature
result.0[Signature::BYTE_SIZE - 1] & 0b1110_0000 == 0
condition
I wonder if the latter should lead to HostError
, or to a 0
result? It naively seems that 0
is a better option here? This should be explicitly decided in the NEP.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm wondering if giving a HostError
is better to provide the caller with more context?
@blasrodri sorry, I forgot auto-merge label last time, could you update this, so that we get this in? |
Created a tracking issue for a bunch of unresolved questions we have here: #7567 |
Makes estimations run again (with and) without `--features=nightly`. near#7165 introduced new methods in the estimator contract but we forgot to hide them behind cfg.
Makes estimations run again (with and) without `--features=nightly`. #7165 introduced new methods in the estimator contract but we forgot to hide them behind cfg.
Implementing the following host functions according to the design proposed in [NEP-364](near/NEPs#364) ```rs pub fn ed25519_verify( &mut self, sig_len: u64, sig_ptr: u64, msg_len: u64, msg_ptr: u64, pub_key_len: u64, pub_key_ptr: u64, register_id: u64, ) -> Result<()>; ``` - [x] added unit tests - [x] added costs (this needs to be reviewed, since I'm not sure how to infer the right numbers)
Makes estimations run again (with and) without `--features=nightly`. #7165 introduced new methods in the estimator contract but we forgot to hide them behind cfg.
Implementing the following host functions according to the design proposed in NEP-364