Thanks for your comments @Roman_Kireev . As I say in the paper, Plutus is in heavy evolution. This implies the library and paper I wrote makes sense for the version of Plutus that I targeted, and probably only for that version. This is expected, and it’s not surprising that further updates of Plutus may (and will break) backwards compatibility.
Because Plutus is a programming language, it must have a finite set of builtin values (unless we go to the hassle of implementing natural numbers from Peano, and the rest of the universe from natural numbers). My library uses and targets whatever builtin values are defined. Today it’s
(integer, bytestring, size, string). Tomorrow, the set may change, and the library should change as a consequence of it.
Now, if the Plutus team implements chain-specific extensions, this may complicate everything a little bit (or a whole lot more ), but there is an implicit in every unlifting: the program put whatever data in the blockchain with the intention of reading it back, so it must assume some kind of compatibility to exist. The builtins used by the publisher program should be the same builtins used by the subscriber program (or at least compatible) and the data schema should be compatible, in the same sense that the validator put by a program must be compatible with what the node validating the transaction can process, so, in more humane terms, the validator must be written in Cek because the node understands Cek.
Finally, I’m going to read what you have implemented in the code, and I’ll try to jump to the conversation there. I’m developing a prototype based in Plutus for a client, and I think unlifting is a part we need, so at the end of the day I’ll have to use unlifting: either my implementation or what the Plutus team provides.