Ability to track non-tracing scripts

[SeungheonOh]

From my very brief go-over of the code, it looks like it's only looking for some of the framework-specific trace messages on traced scripts. For more accurate metric, we can add some kind of small markers onto each script all scripts. Something as small as \ctx -> (\_ -> (actual script)) "Plutarch" will be enough to track both traced and un traced scripts. Cost of one extra lambda abstraction will be near negligible. The actual "tag" can be chosen more carefully so that it can be as small and with minimal overlap.

At least for frameworks that implement something similar, we can grab more accurate metric.

[KtorZ]

Note that we have such marker for both Aiken and Plu-ts (since recently).

• Aiken uses delay [ (error) (force (error)) ]
• Plu-ts uses: (case (constr 0 ) <actual contract> (con integer 42)) (still have to integrate that one)

For other framework, that's indeed a best effort based on framework-specific trace messages and structure; through the frontier between Plutarch and Plutus-Tx (especially with Plutonomy) is quite blurry. So, more than happy to see more framework supporting a compiler-specific marker.

[SeungheonOh]

Ah neat. I'll try to get some clear marker in on the next release. This would've been nicer if we made some unified format for the markers but I guess this works too

[KtorZ]

A CIP is still an option. I talked to the Plutus Core team a while back about adding a 1 byte marker as part of the header for UPLC program reserved to compilers (e.g. instead of the 3 digit Plutus version that has arguably any benefit 😬 ...); but the idea was rejected.

[KtorZ]

Also note that with the way Michele did his on Plu-ts, we can now simply all follow the same approach and reserve specific numbers for each compiler. (42 being now, Plu-ts).

[SeungheonOh]

(\qsrxlF0Y7 xF -> 10) 1 5
CPU: 112100
MEM: 800
SIZE: 13
 
(Case ((Constr 0 ()) ((\xF -> 10)) (1))) 5
CPU: 96100
MEM: 700
SIZE: 15

Ah neat, sop is slightly more cheaper. I thought wrapping in lambda would be cheaper. I feel like this is negligible enough to be not bother to do a dedicated CIP for. Michele's way looks pretty neat. We can just follow it I think.

edit: if anyone want 42, you can still have it : D

(Case ((Constr 0 ()) ((\xF -> 10)) (addInteger 4 2))) 5
CPU: 96100
MEM: 700
SIZE: 19

[KtorZ]

I guess for what it's worth, I just have us all commit to a bytestring identifier 😅 ...!

case ((constr 0 ()) (...) (con bytestring "Aiken")

case ((constr 0 ()) (...) (con bytestring "Plutarch")

case ((constr 0 ()) (...) (con bytestring "Plu-ts")

etc..

[KtorZ]

cc @christianschmitz @nielstron @nau @michele-nuzzi

[nielstron]

is this optimized away by uplc level optimizers (i.e the one in Aiken)? should maybe add a case there to preserve the string or replace it with "... "

[KtorZ]

Good point @nielstron, it probably would, unless we make optimizers aware of it. Which should be pretty straightforward as this should be the first node we ever encounter in the program. Although there's also the case of parameterized validators, for which we could, by convention, always apply below the "compiler header". This would mean that for analytics, we wouldn't even need to deserialise the entire program but merely the first node.

[nau]

Why not simply [(lam compiler validator) (con string "Scalus")]?

That would work for Plutus V1/V2, not just only V3. It's extra 3 nodes, 300 memory, 48000 cpu. Same as constr/case but more versatile.

[KtorZ]

I am happy with both @nau. I don't see reasons to compile to V1/V2 now that V3 is available, so I am not to bothered with the marker to be a V3-exclusive features (if anything, it might encourage everyone to upgrade :)). But, the lambda also works well, and since it's a one time cost; the benefits of a more "optimized" call here are really negligible.

[nau]

I'll add this to Scalus then

[michele-nuzzi]

I just have us all commit to a bytestring identifier

@KtorZ if we are going to use it as standard I will comply, is not a big deal.

however I would still prefer to use constant integers due to how bad bytestring encoding in comparison.

But I repeat, we are talking about details

[michele-nuzzi]

Why not simply [(lam compiler validator) (con string "Scalus")]?

One thing I don't like about this is that is not semantically null.

If in an hypothetical future we allow "inline uplc" (just like solidity has inline assembly) (that could turn useful for shared libs), people might want to use variables outside the scope assuming some additional parameter application offchain.

is not safe, and in theory only expert would use it, but theory is not reality.