Addresses in events should be in lisk32 address format

[ishantiw]

Expected behavior

Addresses in emitted events should be in Lisk32 address format

Actual behavior

Currently in events addresses are in hex format

[
  {
    data: '0a14b2f75b6968f687b495b69e1fec51d06fa8ae9d8d1208000000000000000018f09532221426290318e2fdfb75bdf345c8f5de7db61eb93ad82800',
    index: 0,
    module: 'token',
    name: 'transferEvent',
    topics: [
      '0baf7e7c9bbbcd6c1d91b7fcfb75b5e9dbb8f5e559b8b58d63374b142b343d0d',
      'b2f75b6968f687b495b69e1fec51d06fa8ae9d8d', // address in hex format
      '0000000000000000',
      '26290318e2fdfb75bdf345c8f5de7db61eb93ad8'// // address in hex format
    ],
    height: 9
  }
]

Steps to reproduce

Run a node and call chain_getEvents

Which version(s) does this affect? (Environment, OS, etc...)

6.0.0-alpha.4

[shuse2]

topics are currently defined as bytes array, and the schema is common schema for the engine. It is quite difficult to know what each topic means in the application.

One idea to resolve this is to expose type information in the metadata, and resolve in the external system. To achieve this, we need a way to define schema for tuple and feature to decode the schema

[sameersubudhi]

@shuse2 In such case, Lisk Service should be able to manage the conversion of the addresses to proper format if the application metadata already supplies the necessary information in a standardised format.