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

Implementation of SHA3-256 FIPS 202 hash precompile and EcRecover Uncompressed public key precompile to integrate with ICON blockchain #3801

Merged
merged 9 commits into from
Sep 17, 2021

Conversation

simsonraj
Copy link
Contributor

@simsonraj simsonraj commented Jun 24, 2021

Issue

Implementation of SHA3-256 FIPS 202 hash precompile to integrate with ICON blockchain
EcRecover Uncompressed public key precompile to integrate with ICON blockchain

Test

Unit Test Coverage

Test cases done to check the input and output of the functions for the given parameters below

sha3fips
params
data : ‘0x0448250ebe88d77e0a12bcf530fe6a2cf1ac176945638d309b840d631940c93b78c2bd6d16f227a8877e3f1604cd75b9c5a8ab0cac95174a8a0a0f8ea9e4c10bca’
returns : ‘0xc7647f7e251bf1bd70863c8693e93a4e77dd0c9a689073e987d51254317dc704’

ecrecoverPublicKey
params
hash : ‘0xc5d6c454e4d7a8e8a654f5ef96e8efe41d21a65b171b298925414aa3dc061e37’
v : ‘0x00’
r : ‘0x4011de30c04302a2352400df3d1459d6d8799580dceb259f45db1d99243a8d0c’
s : ‘0x64f548b7776cb93e37579b830fc3efce41e12e0958cda9f8c5fcad682c610795’
returns : ‘0x0448250ebe88d77e0a12bcf530fe6a2cf1ac176945638d309b840d631940c93b78c2bd6d16f227a8877e3f1604cd75b9c5a8ab0cac95174a8a0a0f8ea9e4c10bca’

Before:

After:

Test/Run Logs

The Run logs are from the truffle test project

 Using network 'testnet'.


Compiling your contracts...
===========================
> Everything is up to date, there is nothing to compile.



  Contract: Precompiles
    ✓ should execute sha3fips Precompiled fucntion
    ✓ should execute ecrecoverPublicKey Precompiled fucntion


  2 passing (115ms)

Operational Checklist

  1. Does this PR introduce backward-incompatible changes to the on-disk data structure and/or the over-the-wire protocol?. (If no, skip to question 8.)

    NO

  2. Describe the migration plan.. For each flag epoch, describe what changes take place at the flag epoch, the anticipated interactions between upgraded/non-upgraded nodes, and any special operational considerations for the migration.

  3. Describe how the plan was tested.

  4. How much minimum baking period after the last flag epoch should we allow on Pangaea before promotion onto mainnet?

  5. What are the planned flag epoch numbers and their ETAs on Pangaea?

  6. What are the planned flag epoch numbers and their ETAs on mainnet?

    Note that this must be enough to cover baking period on Pangaea.

  7. What should node operators know about this planned change?

  8. Does this PR introduce backward-incompatible changes NOT related to on-disk data structure and/or over-the-wire protocol? (If no, continue to question 11.)

    NO

  9. Does the existing node.sh continue to work with this change?

  10. What should node operators know about this change?

  11. Does this PR introduce significant changes to the operational requirements of the node software, such as >20% increase in CPU, memory, and/or disk usage?
    No

TODO

@gupadhyaya
Copy link
Contributor

@simsonraj thanks for this PR. could you fix the build failure: https://travis-ci.com/github/harmony-one/harmony/jobs/518515627 ? one of your test is throwing nil pointer error.

@simsonraj
Copy link
Contributor Author

@gupadhyaya Hi, I fixed the nil pointer issue, my tests doesn't fail anymore, still the build fails. Can you please let me know if i missed something?

@gupadhyaya
Copy link
Contributor

@gupadhyaya Hi, I fixed the nil pointer issue, my tests doesn't fail anymore, still the build fails. Can you please let me know if i missed something?

thanks @simsonraj looks like goimports failing

goimports FAILED!
1222--- BEGIN goimports ---
1223diff -u core/vm/contracts.go.orig core/vm/contracts.go
1224--- core/vm/contracts.go.orig	2021-06-26 10:03:14.121332438 +0000
1225+++ core/vm/contracts.go	2021-06-26 10:03:14.121332438 +0000
1226@@ -33,6 +33,7 @@
1227 
1228 	//Needed for SHA3-256 FIPS202
1229 	"encoding/hex"
1230+
1231 	"golang.org/x/crypto/sha3"
1232 )
1233 
1234@@ -96,7 +97,7 @@
1235 	common.BytesToAddress([]byte{8}):   &bn256PairingIstanbul{},
1236 	common.BytesToAddress([]byte{9}):   &blake2F{},
1237 	common.BytesToAddress([]byte{255}): &vrf{},
1238-	
1239+
1240 	common.BytesToAddress([]byte{102}): &sha3fip{},
1241 	common.BytesToAddress([]byte{103}): &ecrecoverPublicKey{},
1242 }
1243--- END goimports ---

@simsonraj
Copy link
Contributor Author

simsonraj commented Jul 8, 2021

@gupadhyaya I checked this error, couldn't make sense of it fully, I can run the local tests and can test the changes with an integration tests too.
when I went through the travis build script, the build script fails whenever there is any line added to the imports.

can you please give me more inputs on how to fix this? I don't necessarily think this is a coding issue, thanks.

@gupadhyaya
Copy link
Contributor

@gupadhyaya I checked this error, couldn't make sense of it fully, I can run the local tests and can test the changes with an integration tests too.
when I went through the travis build script, the build script fails whenever there is any line added to the imports.

can you please give me more inputs on how to fix this? I don't necessarily think this is a coding issue, thanks.

small one. so fixed it directly. will review soon.

@simsonraj
Copy link
Contributor Author

I see its a spacing issue, thanks for fixing it @gupadhyaya.

@gupadhyaya gupadhyaya requested a review from rlan35 August 7, 2021 19:23
@@ -74,6 +79,9 @@ var PrecompiledContractsIstanbul = map[common.Address]PrecompiledContract{
common.BytesToAddress([]byte{7}): &bn256ScalarMulIstanbul{},
common.BytesToAddress([]byte{8}): &bn256PairingIstanbul{},
common.BytesToAddress([]byte{9}): &blake2F{},

common.BytesToAddress([]byte{102}): &sha3fip{},
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

since we already have vrf at 255. How about going backward from there like 254 and 253?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@rlan35 changed the address as suggested.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please add a new PrecompiledContractsXXXXX and add a forking epoch to enable it. You can follow the code here: https://github.com/harmony-one/harmony/pull/3703/files

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hi @rlan35, thanks for the reference code, much helpful,
Can I also please ask in this file
https://github.com/harmony-one/harmony/blob/b34d06b2690395ca0ab64c34be72484ed92249d0/internal/params/config.go#L62
what would be the epoch number for the MainnetChainConfig & TestnetChainConfig and for the rest of the configs I assume it is Zero(0).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, missed the thread. You can put "EpochTBD" for mainnet and testnet for now. 0 for other configs. We will decide a number before release.

}

func (c *ecrecoverPublicKey) Run(input []byte) ([]byte, error) {
const ecrecoverPublicKeyInputLength = 128
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are these code from a existing implementation or it's a new implementation by yourself? If it's existing one, can you add the link to the original code?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ecrecover public key function is similar to the "ecrecover" which retrieves the address while the former has one step lesser, converting the public key into an address.

but the sha3fips code implementation is our own using the "golang.org/x/crypto/sha3" crypto library.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok, looks good.

// This method does not require any overflow checking as the input size gas costs
// required for anything significant is so high it's impossible to pay for.
func (c *sha3fip) RequiredGas(input []byte) uint64 {
return uint64(len(input)+31)/32*params.Sha256PerWordGas + params.Sha256BaseGas
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How is this gas formula determined?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@rlan35 the gas price formula is kept the same as that of sha256hash precompiles. Thanks for pointing it out, I did a bit more in-depth research on the gas prices of various hashing functions, since SHA3-256 is the same family as keccak256.
the gas price should be of that as mentioned in the Ethereum yellow paper (appendix G)
image.
we will change this to the values as shown above, agree?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hi, @rlan35 , waiting for your goahead for the above as well as the epoch numbers as per previous conversation.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, 30 and 6 seems more reasonable here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @rlan35 , Done with these changes, please review it

@rlan35 rlan35 merged commit 70d9583 into harmony-one:main Sep 17, 2021
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.

3 participants