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

Keccak-256 and Blake2b-224 (PLT-6305, PLT-6306, PLT-6311, PLT-6820) #5431

Merged
merged 26 commits into from
Jul 26, 2023

Conversation

kwxm
Copy link
Contributor

@kwxm kwxm commented Jul 20, 2023

This adds new builtins for keccak_256 (see this proposed CIP), which will help with Ethereum compatiblity, and blake2b_224, which will allow on-chain computation of ledger-compatible PubKeyHash hashes (see #5369, which should also lead to a CIP in the near future). This PR adds these functions to plutus-core, plutus-tx, plutus-metatheory and plutus-ledger-api.

The following remain to be done

  • Proper costing once we have a new benchmarking machine, For the time being I've re-used the cost model for blake2b_256 for blake2b_224 and the one for sha3_256 for keccak_256, which is a variant of sha3_256.
  • Conformance tests. These will be added as part of a revision of the tests for the hash functions to use authoritative standard test vectors.
  • End-to-end tests
  • Adding the functions to the PLC specification.

@@ -1,13 +1,16 @@
-- | Hash functions for lazy [[Data.ByteString.ByteString]]s
{-# LANGUAGE TypeApplications #-}
module Data.ByteString.Hash
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 decided to rename this because the other crypto stuff is in this directory already.

Copy link
Contributor

@michaelpj michaelpj left a comment

Choose a reason for hiding this comment

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

I guess we should probably have a CIP for blake2b-224, alas. Kenneth do you want to draft it?

@@ -21,6 +24,14 @@ sha2_256 = digest (Proxy @SHA256)
sha3_256 :: BS.ByteString -> BS.ByteString
sha3_256 = digest (Proxy @SHA3_256)

-- | Hash a [[BSL.ByteString]] using the Blake2B-256 hash function.
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
-- | Hash a [[BSL.ByteString]] using the Blake2B-256 hash function.
-- | Hash a [[BSL.ByteString]] using the Blake2B-224 hash function.

"blake2b_256-cpu-arguments-intercept": 117366,
"blake2b_256-cpu-arguments-slope": 10475,
"blake2b_256-memory-arguments": 4,
"bls12_381_G1_add-cpu-arguments": 1046420,
Copy link
Contributor

Choose a reason for hiding this comment

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

hmmmm, weird that these were missing before??

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, I wondered about this.

Copy link
Contributor Author

@kwxm kwxm Jul 21, 2023

Choose a reason for hiding this comment

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

Actually I think that's OK. This set of cost model parameters is used by the tests for the code that updates the cost model using the flattened parameters. That's the code that uses the JSON-y stuff and I think that I wrote the tests to convince myself that it was doing the right thing. The tests are self-contained and it doesn't matter exactly what cost model is used as long as it's sensible. It won't do any harm to extend it though.

, testCase "context length" $ do
let defaultCostValues = Map.elems $ fromJust defaultCostModelParams
-- the defaultcostmodelparams reflects only the latest version V3, so this should succeed because the lengths match
assertBool "wrong number of arguments in V2.mkContext" $ isRight $ runExcept $ runWriterT $ V3.mkEvaluationContext defaultCostValues
-- currently v2 args ==v3 args
-- currently v2 args == v3 args
Copy link
Contributor

Choose a reason for hiding this comment

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

Something is funny about these tests, should one of these be failing? @bezirg

Copy link
Contributor Author

@kwxm kwxm Jul 21, 2023

Choose a reason for hiding this comment

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

I think PLT-5390 (which we were talking about yesterday) should cover that. I had to add some stuff to those tests for BLS12-381 a while ago and I wasn't totally confident that I'd got it right.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Oh, that comment's wrong. I corrected the spacing but I should probably just have deleted it.

@kwxm
Copy link
Contributor Author

kwxm commented Jul 21, 2023

I guess we should probably have a CIP for blake2b-224, alas. Kenneth do you want to draft it?

See #5369 (like it says in the PR description!), especially this comment. Maybe we've got the cart before the horse here, but I don't think that'll be too controversial in this case.

Copy link
Contributor

@effectfully effectfully left a comment

Choose a reason for hiding this comment

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

Great, pretty straightforward.

@@ -21,6 +24,14 @@ sha2_256 = digest (Proxy @SHA256)
sha3_256 :: BS.ByteString -> BS.ByteString
sha3_256 = digest (Proxy @SHA3_256)

-- | Hash a [[BSL.ByteString]] using the Blake2B-224 hash function.
Copy link
Contributor

Choose a reason for hiding this comment

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

Pardon my ignorance, what is this [[...]] syntax in Haddock?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ah, I asked about that before and no-one could tell me, then I just copied it without looking.

-- | Hash a [[BSL.ByteString]] using the Blake2B-224 hash function.
blake2b_224 :: BS.ByteString -> BS.ByteString
blake2b_224 = digest (Proxy @Blake2b_224)

-- | Hash a [[BSL.ByteString]] using the Blake2B-256 hash function.
Copy link
Contributor

Choose a reason for hiding this comment

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

Also it's not BSL.ByteString but rather BS.ByteString?

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 just changed it to ByteString. The signature should tell us everything we need to know about the type.

Copy link
Contributor

@mjaskelioff mjaskelioff left a comment

Choose a reason for hiding this comment

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

Great job. I'm happy to see that there seems to be no pain in adding new builtins.

@kwxm
Copy link
Contributor Author

kwxm commented Jul 26, 2023

there seems to be no pain in adding new builtins.

Yes, it's way easier than it used to be, so thanks for that.

@kwxm kwxm merged commit 173dce5 into master Jul 26, 2023
@kwxm kwxm deleted the kwxm/builtins/keccak256 branch July 26, 2023 20:08
@adrian1-dot
Copy link

Are there any updates to blake2b_224?
There is no mention of it in CIP101 where keccak256 is proposed. Does that mean it will not be implemented?

Also, it is wrongly defined. The inline version is exported by PlutusTx.Builtins.

blake2b_224 :: BuiltinByteString -> BuiltinByteString
blake2b_224 = BI.blake2b_256

blake2b_256 is used instead of blake2b_224

blake2b_224 :: BuiltinByteString -> BuiltinByteString
blake2b_224 = BI.blake2b_224

I suspect this is a typo, as it is correctly exported from PlutusTx.Builtins.Internal.

@GeorgeFlerovsky
Copy link

Are there any updates to blake2b_224?
There is no mention of it in CIP101 where keccak256 is proposed. Does that mean it will not be implemented?

Also, it is wrongly defined. The inline version is exported by PlutusTx.Builtins.

blake2b_224 :: BuiltinByteString -> BuiltinByteString
blake2b_224 = BI.blake2b_256

blake2b_256 is used instead of blake2b_224

blake2b_224 :: BuiltinByteString -> BuiltinByteString
blake2b_224 = BI.blake2b_224

I suspect this is a typo, as it is correctly exported from PlutusTx.Builtins.Internal.

@kwxm @michaelpj
Is the above indeed a typo?

@zliu41
Copy link
Member

zliu41 commented Feb 20, 2024

Is the above indeed a typo?

It was a typo and has been fixed.

v0d1ch pushed a commit to v0d1ch/plutus that referenced this pull request Dec 6, 2024
…ntersectMBO#5431)

* WIP

* keccak256 -> keccak_256

* Update plutus-metatheory

* Add blake2b_224

* Add blake2b_224

* Add blake2b_224

* Merge update

* Fix a couple of omissions

* Add missing imports

* Add keccak_256 and blake2b_224 to V3.ParamName

* Add test for keccak_256 and blake2b_224

* Fake cost model for keccak_256 and blake2b_224

* Update json file for CostModelInterface tests

* Add changelog entries

* Add Keccak_256 and Blake2b_224 to Versions.hs in plutus-ledger-api

* Typo in comment

* Typo in comment

* Fix dodgy Haddock

* Fix dodgy Haddock

* Add property test for hash sizes

* Haddock for hash size tests

* Formatting

* Formatting

* Fix some BLS-related comments (unrelated to this PR)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants