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

NEP-364 #7165

Conversation

blasrodri
Copy link
Contributor

@blasrodri blasrodri commented Jul 5, 2022

Implementing the following host functions according to the design proposed in NEP-364

    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<()>;
  • added unit tests
  • added costs (this needs to be reviewed, since I'm not sure how to infer the right numbers)

@blasrodri blasrodri requested a review from a team as a code owner July 5, 2022 07:37
@blasrodri blasrodri requested a review from mina86 July 5, 2022 07:37
@seunlanlege
Copy link

seunlanlege commented Jul 5, 2022

Absolutely epic work 🙌🏿

For tracking we're missing:

@akhi3030 akhi3030 requested review from akhi3030 and removed request for mina86 July 11, 2022 14:10
@akhi3030
Copy link
Collaborator

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.

@akhi3030
Copy link
Collaborator

@blasrodri: PTAL: https://near.zulipchat.com/#narrow/stream/295306-pagoda.2Fcontract-runtime/topic/NEP-364. There are some interesting discussions about this PR.

@blasrodri
Copy link
Contributor Author

@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)
What's needed from my side?

@akhi3030
Copy link
Collaborator

@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) What's needed from my side?

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>
@blasrodri
Copy link
Contributor Author

blasrodri commented Aug 22, 2022

@jakmeier I just ran it on another machine (M1)
using

export CARGO_PROFILE_RELEASE_CODEGEN_UNITS=1;
export CARGO_PROFILE_RELEASE_LTO=fat;
     Running `target/release/runtime-params-estimator --accounts-num 20000 --additional-accounts-num 20000 --iters 5 --warmup-iters 1 --metric time --costs Ed25519VerifyBase,Ed25519VerifyByte`
[elapsed 00:00:03 remaining 00:00:00] Writing into storage ████████████████████   20000/20000  
Ed25519VerifyBase                                   73_232_640_700 gas [                 73.233µs]           (computed in 17.18s) 
Ed25519VerifyByte                                      754_106_187 gas [                    754ns]           (computed in 9.14s) 

@jakmeier
Copy link
Contributor

@jakmeier I just ran it on another machine (M1) using

export CARGO_PROFILE_RELEASE_CODEGEN_UNITS=1;
export CARGO_PROFILE_RELEASE_LTO=fat;
     Running `target/release/runtime-params-estimator --accounts-num 20000 --additional-accounts-num 20000 --iters 5 --warmup-iters 1 --metric time --costs Ed25519VerifyBase,Ed25519VerifyByte`
[elapsed 00:00:03 remaining 00:00:00] Writing into storage ████████████████████   20000/20000  
Ed25519VerifyBase                                   73_232_640_700 gas [                 73.233µs]           (computed in 17.18s) 
Ed25519VerifyByte                                      754_106_187 gas [                    754ns]           (computed in 9.14s) 

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?

@jakmeier jakmeier self-requested a review August 22, 2022 12:08
@bowenwang1996
Copy link
Collaborator

@matklad do you mind reviewing this PR again?

Copy link
Contributor

@matklad matklad left a 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.

self.gas_counter.pay_base(ed25519_verify_base)?;
let num_bytes = msg
.len()
.checked_add(signature_array.len())
Copy link
Contributor

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 just msg.len() to charge per-byte cost.
  • move signature decoding Signature::from_bytes( right after reading the signature.

Copy link
Contributor Author

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)`

Copy link
Contributor

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.

Comment on lines 2831 to 2833
let signature = Signature::from_bytes(&signature_array).map_err(|e| {
VMLogicError::HostError(HostError::Ed25519VerifyInvalidInput { msg: e.to_string() })
})?;
Copy link
Contributor

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.

Copy link
Contributor Author

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?

@matklad
Copy link
Contributor

matklad commented Sep 6, 2022

@blasrodri sorry, I forgot auto-merge label last time, could you update this, so that we get this in?

@near-bulldozer near-bulldozer bot merged commit ea96faf into near:master Sep 6, 2022
@matklad
Copy link
Contributor

matklad commented Sep 6, 2022

Created a tracking issue for a bunch of unresolved questions we have here: #7567

jakmeier added a commit to jakmeier/nearcore that referenced this pull request Sep 20, 2022
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.
near-bulldozer bot pushed a commit that referenced this pull request Sep 20, 2022
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.
nikurt pushed a commit that referenced this pull request Nov 9, 2022
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)
nikurt pushed a commit that referenced this pull request Nov 9, 2022
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.
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

Successfully merging this pull request may close these issues.

7 participants