AuxiliaryData encoding is not using uint keys

[SebastienGllmt]

The line here uses the type transaction_metadata: &KeyValuePairs<Metadatum, Metadatum> which doesn't match the Cardano binary spec. While Metadatum uses int, the spec has a special type for top-level keys called transaction_metadatum_label which uses uint instead.

Concretely, you can see in this transaction that the metadata representation used by Oura ends up being 82a21b12127f810d7dcee28264594554491907e53b08ef38d198e051b4a080 which gives the following cbor.me representation:

82                        # array(2)
   A2                     # map(2)
      1B 12127F810D7DCEE2 # unsigned(1302243434517352162)
      82                  # array(2)
         64               # text(4)
            59455449      # "YETI"
         19 07E5          # unsigned(2021)
      3B 08EF38D198E051B4 # negative(643795744601428404)
      A0                  # map(0)
   80                     # array(0)

As you can see, instead of the expected 17802948329108123211 key, we instead get -643795744601428404

You can see, for example, Cardano Multiplatform Lib uses the special label type here

[scarmuega]

thanks @SebastienGllmt. Nice catch, the metadatum label should indeed be a uint instead of the current representation.

Regardless of the required change, is it possible that you're using an old version of Oura / Pallas to generate the CBOR? The current version of the lib represents INT metadatum using a minicbor struct that allows up to 2^64, which should be able to accommodate the mentioned value.

I've downloaded the block and decoded it. The rust representation of the auxiliary data shows me:

[
    (
        Int(
            Int {
                neg: false,
                val: 1302243434517352162,
            },
        ),
        Array(
            Def(
                [
                    Text(
                        "YETI",
                    ),
                    Int(
                        Int {
                            neg: false,
                            val: 2021,
                        },
                    ),
                ],
            ),
        ),
    ),
    (
        Int(
            Int {
                neg: false,
                val: 17802948329108123211,
            },
        ),
        Map(
            Def(
                [],
            ),
        ),
    ),
],

[SebastienGllmt]

I'm using Oura 1.3 (using pallas-primitives 0.6.4)

Here are all the steps more concretely:

let event = input.recv()?;
let data = event.data.clone();
match data {
  EventData::Block(block_record) => {
    let block = alonzo::BlockWrapper::decode_fragment(block_record);
    let aux_data = block
            .auxiliary_data_set
            .iter()
            // get the specific tx mentioned in this issue from the block
            .find(|(index, _)| *index as usize == idx);
    let auxiliary_data = aux_data.map(|(_, a)| {
        let auxiliary_data_payload = a.encode_fragment().unwrap();
        println!("{:?}", hex::encode(auxiliary_data_payload));
    }
  }
}

I noticed the fix is included in this commit, but it's just not part of Oura 1.3