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.

Sign up for GitHub

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

CIP-0076? | Hash-Checked Data #363

Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
258751c
partial initial
zygomeb Oct 25, 2022
eb55c93
initial version
zygomeb Oct 25, 2022
5a03cc9
cleanup
zygomeb Oct 25, 2022
c0e20c0
incorporate feedback
zygomeb Oct 26, 2022
4d2e4b0
incorporate suggested cip number
zygomeb Nov 24, 2022
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
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,45 @@
---
CIP: 76
Title: Hash-Checked Data
Author: Maksymilian 'zygomeb' Brodowicz <zygomeb@gmail.com>
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