Constant reference to script hash / currency symbol

[Quantumplation]

Often, all but the most trivial contracts need to refer to another contract, for example:

• Enforce that funds are paid to a specific script hash (not our own)
• Enforce that a token with a specific policy ID is included

Right now, the only way (that I know of) to achieve this in Aiken is:

• Parameterize your script by this script hash
• Set up a custom build pipeline that compiles each script in the correct order, and then uses that hash or currency symbol to construct the "downstream dependencies"

Given how prevalent this is, it'd be really nice to have built in language support for this, exposing these script hashes as compile time constants to the contract so long as there is no circular dependencies.

For example, this could be achieved via a compiler time built-in:

const outputScript = hash_of(SomeValidator.can_spend)
const settingsPolicy = policy_id_of(SomeValidator.can_mint)

Use of these variables would impose a topological ordering on the validators, and cycle detection could throw a helpful error with some suggested design patterns to unravel the circular dependency.

What are the teams thoughts on this?

[Quantumplation]

@KtorZ I might try to implement this this weekend if I have some free time; Can we have a discussion about what the preferred syntax would be if it could magically be implemented?

• normal method call like in the original post: hash_of(SomeValidator.can_spend)
• keyword like: hash_of SomeValidator.can_spend
• making it all caps so it looks different: HASH_OF(SomeValidator.can_spend)
• making it a property of the method SomeValidator.can_spend.hash
• making a custom syntax, like const outputScript = #{SomeValidator.can_spend}
• Something else?

[rvcas]

Cool no problem. If I think of more options, I'll list it here.

[Quantumplation]

My favorite in the list is something like #{SomeValidator.can_spend}, as it makes it clear that something Different ™️ is happening, perhaps at build time. And the fact that # is called the hash symbol by some lol

[rvcas]

yea agreed. I just don't understand the CapitalCase thing

[Quantumplation]

oh, that's just the module name where the validator is located; it may not be in capital case in practice, I just wrote that by habit

[rvcas]

oh gotcha

[waalge]

Is the idea still alive?

[MicroProofs]

The problem I see with this is it would only work for non-parameterized scripts. So I'm not really seeing the use case since most/all useful scripts are parameterized but a utxo ref/token or a script that was parameterized.

[waalge]

I'd quite like to never parameterize. I know my params at compile time. A bunch of functions then become 0-arg. No handing some oref from the params down some chain of nested function calls

[Quantumplation]

I think the ideal version of this feature would translate it into a validator argument, plus cli tooling for automatically applying arguments in the right order, and only prompting for the arguments that are "external".

[KtorZ]

What we are thinking as a possible first step in the right direction is a way to provide arguments directly in the configuration file (aiken.toml). So you could have different configuration file (for dev, production, or whatever environment really) and aiken build would simply apply parameters specified in the configuration on build.

[perturbing]

Now that this

What we are thinking as a possible first step in the right direction is a way to provide arguments directly in the configuration file (aiken.toml). So you could have different configuration file (for dev, production, or whatever environment really) and aiken build would simply apply parameters specified in the configuration on build.

and other env files are in aiken. Is it time to revisit the idea of const outputScript = hash_of(SomeValidator)? 😄