search

IntersectMBO / plutus

The Plutus language implementation and tools
Apache License 2.0
1.56k stars 479 forks source link

Assumptions violated by future ledger changes #4753

Open L-as opened 2 years ago

L-as commented 2 years ago

E.g., in my scripts, I assume that values in UTXOs are non-negative, and that the amount of ADA is always positive. With Babel fees, this will cease to be true. In such cases, will a new language version be released?

michaelpj commented 2 years ago

I agree, it's unclear what we should do here.

effectfully commented 1 year ago

@michaelpj any idea on how to move this forward? Should we get Jared or someone else involved? Should someone come up with a list of assumptions one is allowed to make when working with present-day Plutus? Should someone figure out a process for changing assumptions over time? I'm a bit lost with this one.

michaelpj commented 1 year ago

I don't know, there's some kind of conceptual question here.

We've mostly operated on the assumption that we should try and be as backwards-compatible as possible. But recently we started e.g. simply not supporting new transaction features in old ledger languages. I could see that argument for doing the same for new eras that change the semantics significantly. On the other hand, there is a risk that that forces us into more new ledger languages than is strictly necessary, which is problematic in its own way.

I think it's an open question what to do .

L-as commented 1 year ago

If the type of ScriptContext bound it as tightly as possible that would be a good solution, but it would be a very complex type.

L-as commented 1 year ago

A lot of important discussion has happened in #4296

effectfully commented 1 year ago

I believe we need an objective on coming up with a process to figure out

  1. what kinds of things are there to stay (see also the discussion in #4509)
  2. how to handle and report breaking changes (see also the discussion in #5408)

The security of the whole system depends on these things, so it definitely should be prioritized.