feat(rpc/vccv2): enhanced vcc data aggregator

[IzioDev]

This PR is a follow-up to @D-Stacks initial effort here.

It is not in final state, take it as a base of discussion for future efforts.

What?

It allows gathering more data than the current vcc endpoint in a non-breaking change way, in particular acceptance_data. It is a way for network observers to solely follow vccv2 without having to keep a parallel listener on added block (and potential sender resolver on top of it). Example, end-users can now rely on vccv2 and get: accepted DAA score, accepting block, sender address for each transaction that gets accepted.

Since the endpoint can become chatty, @D-Stacks introduced a granular verbosity selector (at field level). We found it could be difficult to manipulate as an end-users so we introduced verbosity level instead.

Example usage:

let response = client
        .get_virtual_chain_from_block_v_2(
            RpcHash::from_str("5f04a7525c0bc96959b32e6862893181a3f22d7403e3a549063762a2fc4bac78").unwrap(),
            // None, Low, High, Full
            Some(RpcDataVerbosityLevel::None),
        )
        .await?;

To avoid user confusion about populated fields, comment documentations have been added. It is yet to be determined how to translate this for wasm users.

Identified Flaws

1. This endpoint returns duplicated transactions, as they live on-DAG. Yet, it has be debated that only accepted transaction could matter from a network consumer perspective
2. With the freshly introduced verbosity selector, the response could contains "unexpected" non-empty properties such as response.added_acceptance_data[n].mergeset_block_acceptance_data[m].accepted_transactions[k].verbose_data which should instead be equal to None in case verbosity is set to None (none of verbose_data fields are showed on such verbosity level)

Verbosity Level

They are incremental, meaning a verbosity level of 2 (High) would include every fields defined at a verbosity level of 1 (Low).

To get a detailed view, I suggest two entry-point:

• per field definition
• struct fields documentation (valid in other files, this is one of those)

Use-case

As a network observer needing acceptance data tracking at a transaction level, I can now solely rely (see identified flaws 1.) on this endpoint given the fact i have a block hash checkpoint (last scanned/ingested block).
In such case, I'd call the new endpoint with a verbosity level fitting my requirements, in this example i'll provide "Low":

// get vcc with acceptance data
let response = client.get_virtual_chain_from_block_v_2(dag_info.pruning_point_hash, Some(RpcDataVerbosityLevel::Low)).await?;

for acd in response.added_acceptance_data.iter() {
    // print accepting block info
    println!(
        "mergeset of {} {}",
        acd.accepting_chain_header.as_ref().unwrap().hash.unwrap(),
        acd.accepting_chain_header.as_ref().unwrap().daa_score.unwrap()
    );

    // iterate mergeset
    for bad in acd.mergeset_block_acceptance_data.iter() {
      // print block info
      println!(
          "\tblock {} {}",
          bad.merged_header.as_ref().unwrap().hash.unwrap(),
          bad.merged_header.as_ref().unwrap().daa_score.unwrap()
      );

      // iterate through accepted transactions
      for tx in bad.accepted_transactions.iter() {
        // get id for example
        let id = tx.verbose_data.as_ref().unwrap().transaction_id.unwrap();
      }
    }
}

An example of usage is provided here. With its current state, consider it a playground.

Open questions

• UtxoInquierer has been heavily modified. I'm still learning the underlying architecture and component interactions and I'm currently unable to properly review the introduced changes by @D-Stacks. Does it seems correct to you? I see artifact comments that let us suggest it has not been totally finalized/polished.

Future possibilities

• While having an on-demand endpoint can be sufficient, reactive (as in react to events) applications might prefer using a notification system (pub/sub model). This endpoint could serve as a base for a notification system: NotifyVirtualChainChangedV2

[coderofstuff]

Comments from Michael:

1. remove merged blocks headers from high verbosity (we can always add it with an even higher verbosity)
2. support min confirmation count feature on v2 as well
3. rename v_2 to v2
4. evaluate performance costs of this api under TPS stretch and if required, decide how to keep it under control

---

Additional: Ensure that the new RPC, it's arguments and everything that goes in there is added into WASM. There must be an rpc.getVirtualChainFromBlockV2 that can be used through wasm

[IzioDev]

Comments from Michael:

1. remove merged blocks headers from high verbosity (we can always add it with an even higher verbosity)

2. support min confirmation count feature on v2 as well

3. rename v_2 to v2

4. evaluate performance costs of this api under TPS stretch and if required, decide how to keep it under control

Additional: Ensure that the new RPC, it's arguments and everything that goes in there is added into WASM. There must be an rpc.getVirtualChainFromBlockV2 that can be used through wasm

All of the point but performance evaluation have been addressed.

Still some cleaning tasks to be done and some change in low-level utxo inquirer (panic-safe related). Other than that, it's in a testable state.