Publisher-Subscriber design pattern in Plutus

Developers Smart Contracts
,
1

Hi everyone!

I have been developing a small mechanism for communicating arbitrary data in Plutus by writing data and reading it back from the blockchain (in this case from the emulator, as no testnet exists yet).

https://github.com/javcasas/plutus-pubsub-paper/blob/master/paper.pdf

If you have some time, please have a look at it and post me your thoughts.

3 Likes
2

This is an impressive work, but please note that you’re chasing a moving target here, because

  1. the set of builtin types (integer, bytestring, size, string) is going to change, because we want to at least remove string which was added in order to allow easy logging, but we’re working on a more principled approach. We’re also considering adding a natural type for unsigned integer arithmetic. Finally, we may also decide to allow chain-specific extensions to the set of builtins and remove the currently hardcoded types
  2. unlifting values is what we are working on as well, except we want to support unlifting in Plutus Core itself and implement it in the user-facing Plutus Tx in terms of what we have in Plutus Core. There is some work already done (you can read a few consequent notes here and look at an example instances here), but we’re changing a lot of stuff there right now

So yeah, the code is in prealpha, it is not yet ready for other people to depend on it, because everything constantly changes there and we have not even settled on the final design of the implementation yet.

1 Like
3

Very interesting :+1:

4

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 :smiley:), 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.