Support Scott-Encoded validators parameters

[KristianBalaj]

What is your idea? Provide a use case.

I'm trying to use Aiken written validator in Plutus and when trying to apply parameters in Plutus, the expected params format differs.
Based on the discussion I've had with Plutus maintainer, aiken expects Data encoded parameters and Plutus works with Scott encoded params.

From the discussion:

it's just super extra inefficient to encode data using Data

Supposedly, Aiken currently uses inefficient parameter application and should be changed to Scott encoding version.

Here's the discussion in Plutus issue - IntersectMBO/plutus#5414

Why is it a good idea?

Optimisation reasons + interoperability with Plutus.

What is the current alternative and why is it not good enough?

Currently, Aiken provides just a single way to application parameters.

[KtorZ]

This is actually untrue and a slightly misleading statement.

Let me clarify.

Aiken does not encode anything. That's kind of the point and the reason why Aiken can be an order of magnitude more efficient in number of cases. In fact, validators inputs are provided are Data by the ledger; so they're already encoded. Aiken data-types are isomorphic to Data (or other primitives) and thus, there's no on-chain operation required to operate on Data values.

PlutusTx does indeed encode every value using Scott-Encoding. And this is done as part of the compiled on chain program; because as just explained, inputs to the validator (datum, redeemer and script context) are received encoded as Data and there's no way around that.

One may think that it's not a big deal but it actually is. Especially when a transaction involves multiple validators. For example on Hydra, a 'collectCom' transaction involve several inputs, each locked by a script. The Scott encoding has to be done EACH time for each input and thus, before any execution logic can happen. When measured, it shows that the Scott encoding alone actually accounts for ~80% of the transaction budget; leaving about 20% only for actual logic.

It is true that for validators parameters, one is free to choose how those are applied and can thus, Scott-encode them right away at compile time. It doesn't change the fact that the script context and other params still need to be encoded at runtime.

It is also true that once encoded, the Scott Encoding is more efficient for manipulating those data, in particular for accessing nested fields. But that's only true once the initial cost of encoding Data has been paid. Think about an affine function where the slope is slightly higher on Aiken but it has no y-axis offset, whereas PlutusTx starts much higher but has a slightly slower slope. The point of intersection of those functions is actually quite far, so much that validators big enough to see the benefits of this Scott Encoding likely do not fit in a transaction (because of maximum budget restrictions). I sadly do not have concrete numbers yet but we'll come to that soon once we start optimising Aiken.

Note also that comparing Data together via equality is actually extremely fast on chain and is one very common operation (checking equality on a datum or an output reference for example). This is arguably also an argument in favour of Data given the how often this happen. But to be frank, the main argument remains that Data needs no encoding, it is already the ABI format.

Hence, I don't think it's quite fair to call for an "optimisation" whereas Aiken is arguably the one optimised for the use case. It is very unlikely that Aiken will ever support applying Scott-encoded parameters, and we will certainly not do Scott-Encoding on chain. I think however that supporting the application of parameters as Data from the Haskell codebase should be pretty trivial. I'd suggest that as a path forward.

[rvcas]

This will never happen.

[KristianBalaj]

Thanks for the thorough clarification 🙌

[KristianBalaj]

I'll try to also ask you for the passing of parameters, since you could maybe know.

when having the following validator:

validator(a: Int, b: Int) {....}

The parameters can be applied on the Haskell side the following:

applyArguments script [ V2.toData param1, V2.toData param2]

Do you have an idea how could I apply the params if I want the params to be a single parameter like following?:

type FooScriptParams {
    a: Int,
    b: Int
}

validator(params: FooScriptParams) {....}

Maybe the following?

applyArguments script [ [V2.toData param1, V2.toData param2] ]

[rvcas]

what's the type signature of applyArguments?

[KristianBalaj]

It's the following:
applyArguments :: Script -> [Data] -> Script

[KtorZ]

Then try:

let param = FooScriptsParam 14 42 in applyArguments script [ V2.toData param ]

The default instance for toData should work just fine for your example.

[KristianBalaj]

Nice, thanks. Will give it a try 🙌

[euonymos]

PlutusTx does indeed encode every value using Scott-Encoding. And this is done as part of the compiled on chain program; because as just explained, inputs to the validator (datum, redeemer and script context) are received encoded as Data and there's no way around that.

What do you mean by "PlutusTx does indeed encode every value using Scott-Encoding". Does it apply to datums, redeemers, and the script context? Should this statement be understood as PlutusTx doesn't use data-encoding? Sorry, I am a bit confused here, I ve never looked into PlutusTx internals.

[KtorZ]

Value from the contract binary interface (i.e. datum, redeemer, context) that are provide by the ledger are encoded as Plutus Data. Each Plutus-Tx program then include a step of "parsing" this data encoding into another (Scott), more efficient, encoding which is well-suited for lambda calculus like Plutus Core.

On the paper it works great, but in practice, the initial cost of encoding from Data to Scott largely throw away the benefits it brings to the program execution. Especially on complex transactions where the script context is larger (and thus, cost a more to Scott-encode).

[KristianBalaj]

Btw. PlutusV3 won't be using Scott encoding anymore - https://iohk.io/en/blog/posts/2024/02/12/unlocking-more-opportunities-with-plutus-v3/