Add spend_redeemer to matches

[perturbing]

Hi,

As per its user documentation, Kupo currently returns for a matched UTxO something like

[
  {
    "transaction_index": 14,
    "transaction_id": "35d8...4e09",
    "output_index": 2,
    "address": "addr1vy3qpx09uscywhpp0ekg9zwmq2yj5vp08husfq6qyh2mpps865j6t",
    "value": {
      "coins": 42,
      "assets": {
        "1220099e5e430475c219518179efc7e6c8289db028904834025d5b086": 231,
        "289db028904834025d5b085d5b08661220099e5e430475c2195181796.08661220099e": 1
      }
    },
    "datum_hash": "3097...b635",
    "datum_type": "hash",
    "script_hash": "3097...9ded",
    "created_at": {
      "slot_no": 51540727,
      "header_hash": "9d09...31bf"
    },
    "spent_at": {
      "slot_no": 51540727,
      "header_hash": "9d09...31bf"
    }
  }
]

Below, I would like to discuss the possible addition of the fields, spend_redeemer and spend_script_context to this response in case an UTxO was witnessed by one when spent.

To start off, the why, in some complex decentralized applications, mutable state is represented succinctly via, for example, merkle tree's or other opaque vector commitment schemes (accumulators or even verkle trees). With the introduction of such data structures, the script checks that state transitions of these possible big data structures are done correctly via small proofs. But with this opaqueness, a bootstrapping problem arises, that is, “how does a new instance that would like to use the application know what the latest succinct data represents?”.

An obvious solution is to publicly communicate via some offchain channel what the latest state is, which then can be checked against the latest commitment onchain. But a concern with this method is that it requires the user to connect to a possible centralized point, revealing the identity of the user (among other infrastructure issues).

Another, more decentralized way would be to bootstrap each user from the initial state when the dApp was created onchain. In this case, a user applies each transaction that it sees happening onchain in the same order to its local initial state, which eventually leads to knowing the latest state.

To do the latter via kupo, we can track the UTxO + some asset that makes the state unique across the slots, and for each transition recover the redeemer + context easily to deduce how the state transitions.

I have no idea on the technical implication of Kupo for this (especially for the context), what do you think?

[nielstron]

I am also adding another use-case here:
In decentralized exchanges you want to display to the user a history of transactions. Often there is a so-called batcher script. The result of the removal of a transaction from the batching script could be a) the user cancelled the order b) the user order was filled by a liquidity pool. In more complex setups, the only reliable way of telling the options apart is by checking the redeemer with which the order was removed from the batching script. In the same spirit, it would also be interesting to know the transaction in which the UTxO was spent (rather than just the block).

I think that this would have a significant impact and propose that either a) this is only implemented to be optionally enabled by users or b) this is not implemented at all and users are advised to implement custom chain indexers for more complex setups using i.e. chain synchronization directly.

[KtorZ]

Knowing the full transaction and being able to fully retrieve the full transaction is kind of already possible with Kupo. This is exactly what the metadata endpoint does, except that it strips out everything else from the transaction.

The only reason I am doing that is because I've been too lazy to write (again) a full JSON serializer for the whole transaction object 😬 ...

Now, with Ogmios v6 being out, I can definitely think about pulling the JSON encoders from Ogmios into a standalone library re-used for Kupo. That would however break the Kupo's API in a non-backward compatible way and result in Kupo v3. Which may be okay, especially if it standardizes the API between Ogmios and Kupo.