Service to standardize transactions (receipts resolutions)

[dgarcia360]

tldr; We could have a service to flatten transactions. E.g: Given a set of transactions announced, return them with resolved aliases.

Why?

Namespace alias make accounts and mosaics identifiers easily recognizable. While the feature makes announcing transactions more developer-friendly, it becomes much more complicated when having to process past transactions.

For example, imagine an exchange storing deposits in a database every time they receive a transaction. They query the latest transactions every 10 minutes to process which transactions the accounts of the group have received. Some of them come with the real mosaics identifier, whereas others use the aliases. The fact is that they need to have a way to identify mosaics in a transaction since they cannot trust in the latest alias resolution since the link may vary over time.

While exchanges can retrieve the real identifier behind the aliased assets, they need first to learn about aliases and receipts, raising the learning curve. Note that this problem does not apply only to exchanges (just an example), but to any other use case requiring to process transactions.

Next steps

• Decide if we want to treat this in the SDK level or as a separate library.
• Define the service.

[dgarcia360]

A possible solution. Under Transaction, Namespace, or Receipt Service:

  /**
    * @param transationHashes List of transaction hashes.
    * @returns Observable<Transaction[]>
    */
     public resolveAliases(transationHashes: string[]);

You can see here how to get the resolution behind an aliased mosaicId.

Update: @rg911 I have modified a bit the proposed solution passing transactionHashes instead of Transaction objects, since the transactions we are interested to flatten are already announced.

[rg911]

A possible solution. Under Transaction, Namespace, or Receipt Service:

  /**
    * @param transactions List of transactions.
    * @returns Observable<Transaction[]>
    */
     public resolveAliases(transations: transactions): Observable<Transaction[]>;

You can see here how to get the resolution behind an aliased mosaicId.

Not a fan of this approach (sorry mate). Would it be better to add flag in those transactions (contain alias) to be able to switch between resolved and unresolved (probably will reduce a lot duplicated codes and efforts)?

[dgarcia360]

Not a fan of this approach (sorry mate).

Because the approach is not optimal (having to do lots of calls), or because you don't think it is necessary to be able to get resolutions?

Would it be better to add flag in those transactions I don't see how this solves resolving the real identifier behind an alias with ease. Currently, we can easily detect if a MosaicId or an Address is an alias. Could you please share a possible example of how your proposal would work?

[dgarcia360]

Another similar approach could be accepting single Transaction objects instead of arrays.

/**
 * @param transactionHash string.
 * @returns Observable <Transaction>
 */
public resolveAlias(transationHash: string);

However, this does not solve the problem totally since devs would call resolveAlias many times when processing a big group of transactions. To make it feasible with fewer calls, we might need to come with a proposal to have a new POST endpoint that accepts getting the receipts from multiple blocks.

[rg911]

@dgarcia360 Okay, I think I am a bit misunderstood the problem you raised initially. What my thoughts are:

1. If exchanges for example received transactions, how do they know if there are alias used or not? Assuming they will call your resolveAlias method regardless. probably fine but not ideal IMO.
2. Adding a Flag in the rest callers or services might help above but not 100%. E.g. if having a flag in `Transaction.announce(.., resolveAlias = true) so it flatten the tx down before announce. Or adding the same flag in deserialization (rest endpoint callers ) as well?

[dgarcia360]

1. The SDK currently detects if the bit 0 of the first byte is set. If so, returns a NamespaceId instead of a MosaicId/Address, so the exchange would know if an alias is being used. That's why I think adding a flag does not solve much. If the transaction does not have alias, the service should not do any additional calls.

2. Transaction.announce(.., resolveAlias = true) Note that I'm not concern about transaction announcements, using alias is fine there. The problem comes when you have to read the blockchain, and perform another transaction based on the data read.

Another example: Imagine that, every time you send me a mosaic unit, I send you back the same mosaic units multiplied by two. I cannot just to:

const mosaics = [ new Mosaic(previousTx.mosaics[0].id, previousTx.mosaics[0].value * 2];

because if you were using an alias to define the mosaic id, it could have changed or expired.

Instead, I need to get the resolution of the alias for this given transaction and block, having to query the correspondent mosaic resolution.