-
Notifications
You must be signed in to change notification settings - Fork 289
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
Conversation
@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. |
@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
|
@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. 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. |
I see its a spacing issue, thanks for fixing it @gupadhyaya. |
core/vm/contracts.go
Outdated
@@ -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{}, |
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.
since we already have vrf at 255. How about going backward from there like 254 and 253?
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.
@rlan35 changed the address as suggested.
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.
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
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.
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).
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 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 |
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.
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?
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.
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.
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.
ok, looks good.
core/vm/contracts.go
Outdated
// 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 |
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.
How is this gas formula determined?
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.
@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)
.
we will change this to the values as shown above, agree?
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.
hi, @rlan35 , waiting for your goahead for the above as well as the epoch numbers as per previous conversation.
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.
Yes, 30 and 6 seems more reasonable here.
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.
Hi @rlan35 , Done with these changes, please review it
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
Operational Checklist
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
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.
Describe how the plan was tested.
How much minimum baking period after the last flag epoch should we allow on Pangaea before promotion onto mainnet?
What are the planned flag epoch numbers and their ETAs on Pangaea?
What are the planned flag epoch numbers and their ETAs on mainnet?
Note that this must be enough to cover baking period on Pangaea.
What should node operators know about this planned change?
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
Does the existing
node.sh
continue to work with this change?What should node operators know about this change?
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