Sketch of a subtype judgment on contract specs

[graydon]

This is a sketch of a subtype relationship on soroban contract specs. The idea here is to support the host function that updates / overwrites contracts with a judgment it can make that a new contract is compatible with the spec (type signature) of an old contract, such that anyone using the old contract will continue to be able to use the new contract.

Of course it's just "spec-level" compatibility, not like "does the contract do the same thing" -- we can't judge that -- but I think it'll prevent a fairly wide class of upgrade mistakes if we can at least catch spec mismatches.

The subtyping relationship here is intended to be extremely textbook and hopefully corresponds to the same rules (covariant returns, contravariant arguments, record extensions, union restrictions) you'll find in any standard treatment of immutable structural types and functions.

We haven't 100% decided we're going to do this yet, I don't think, but I suspect something like this (possibly strengthened or weakened somewhat) will prevent a lot of errors, and I wanted to sketch it out as part of discussing the lifecycle, evolution and versioning of contracts in the field (eg. as part of stellar/rs-soroban-sdk#1095 though that bug somewhat mixes up issues of contract compatibility and SDK compatibility, I think the spec mechanism is likely to be at least part of how we express SDK versioning anyways)

cc @sisuresh, @MonsieurNicolas, @dmkozh and @leighmcculloch

[leighmcculloch]

I think this functionality could live in the soroban-cli. I can imagine the soroban-cli having a subcommand for checking the compatibility of two contracts, either two on disk, or one deployed and one on disk.

I'm hesitant about this living in the host because other than this the host has no knowledge about SDK types or contract interfaces. Adding this logic to the host itself would as far as I can tell make this a part of the protocol proper, rather than being details external to the protocol.

cc @paulbellamy @tsachiherman What do you think about a command in the soroban-cli evaluating the backwards compatibility of two contracts?

[tsachiherman]

I think that these are very strong "language features" that would be great to add to the cli.
Moreover, for implementing dynamic cross contract calls, I think that these would become useful.
Reading your description, it sounds like a linked list of specEntries. I'm wondering if these could get to a tree like or circular list. ( Since the cli would need to avoid these )