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

CIP-0076? | Hash-Checked Data #363

Closed
wants to merge 5 commits into from
Closed
Changes from 4 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
45 changes: 45 additions & 0 deletions CIP-AnyDataIsDatum/README.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,45 @@
---
CIP: ????
zygomeb marked this conversation as resolved.
Show resolved Hide resolved
Title: Hash-Checked Data
Author: Maksymilian 'zygomeb' Brodowicz <[email protected]>
Status: Draft
Type: Standards
Created: 2022-10-25
License: CC-BY-4.0
---

## Simple Summary / Abstract

Hashing data on-chain is quite expensive from a computational perspective. Currently, however, we are forced to use the `serializeData` primitive combined with a hashing function of our choice. It would be computationally beneficial to let the node hash the data before running the smart contracts, giving us only a guarantee that this mapping is correct, just as we do with Datums presently.

Therefore we propose extending the ScriptContext's txInfoData from just a mapping between DatumHash and Datum to a more universal mapping between BuiltinByteString and BuiltinData.

## Motivation / History

We can repeat the same motivation as [CIP 42](https://cips.cardano.org/cips/cip42/), and more broadly emphasizing the want to leverage complex data structures on chain.

When presented with either a datum inside a datum or in general, data behind a hash, we are forced to spend a lot of computational resources to first serialize and then hash and then check for equality. This comes up quite often when implementing counter-double-satisfation measures (payment to script double satisfied).

## Specification

### Extending the ScriptContext

We change the field `txInfoData` to `[(BuiltinByteString, BuiltinData)]`. Nominally, this changes nothing as the `DatumHash` and `Datum` types are equivalent to these. Importantly however, we allow any pair to be pushed to this list, and the node will hash the `BuiltinData` to verify that it matches the `BuiltinByteString`.
Copy link
Contributor

Choose a reason for hiding this comment

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

Are you suggesting we only support Blake2b 256? (ie the hash function currently used for Data). Above it says "hashing function of our choice", but here it looks like you are suggesting just keeping with the status quo.

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 believe that we should have more discussion around how it would be possible to have an arbitrary hashing algorithm used here -- but I'd be happy to have an MVP here of just the blake256 as for the purpose of what this aims to achieve it is entirely sufficient.


It is worth noting that we can keep the types as they are now.

## Rationale

Just as we use nodes to be the source of truth on hash equality for datums we should encourage the use of them for more data, if it can be known statically.

## Backwards compatibility

The change needs a new language version to function safely

## Path to Active

The appropriate changes need to be made to the node code.

## Copyright

This CIP is licensed under Apache-2.0