4

These are the two ways I found to track events on the Ethereum blockchain. One of them doesn't contain the data I need. Why not?

Way 1 does NOT contain the data I need Result:

subscription = web3wss.eth.subscribe('logs', {
    address: contractAddress,
    fromBlock: 0 }, 
    function(error, result) {
        if (!error)
            console.log(result);
    }
);

Output 1:

{ address: '0xCa2B2e652c365286184F594...',
  blockHash: '0x7195ed2114efca7563be43ab1aae043b6e830d27bca7073...',
  blockNumber: 8312120,
  data: '0x0000000000000000000000000000000000000000000000....',
  logIndex: 0,
  topics: 
   [ '0x95b743913ef0bd0b7e63223fdcb0589f405eb9b2a853fa328...',
     '0x32303138616263310000000000000000000000000000000...',
     '0x3230313878797a310000000000000000000000000000000000...' ],
  transactionHash: '0x7009093b3c4d6e30628818834f448fd446f4fda027...',
  transactionIndex: 1,
  transactionLogIndex: '0x0',
  type: 'mined',
  id: 'log_bbd6...' }

Way 2 contains everything I need, but also way too much data in general:

myContractwss.events.logName({
    filter: {'orderId': web3.utils.toHex('2018...')}, 
    fromBlock: 0
    })
    .on('data', data => { console.log(data); });

Output 2:

{ address: '0xCa2B2e652c365286184F5945BE...',
  blockHash: '0x0d03a61b4c372008308b5275ff8f39599...',
  blockNumber: 8312159,
  logIndex: 0,
  transactionHash: '0xe545a4b7e7c5b668905860bde6074...',
  transactionIndex: 0,
  transactionLogIndex: '0x0',
  type: 'mined',
  id: 'log_7f6...',
  returnValues: 
   Result {
     '0': '0x323031386162633100000000000000000...',
     '1': '0x3230313878797a310000000000000000...',
     '2': '900',
     '3': '123',
     orderId: '0x32303138616263310000000000000000000000000...',
     responseId: '0x3230313878797a310000000000000000000...',
     orderAmount: '900',
     deliveryDate: '123' },
  event: 'LogOrderResponse',
  signature: '0x95b743913ef0bd0b7e63223fdcb0589f405eb9b2a...',
  raw: 
   { data: '0x000000000000000000000000000000000000000000...',
     topics: 
      [ '0x95b743913ef0bd0b7e63223fdcb0589f40...',
        '0x32303138616263310000000000000000...',
        '0x3230313878797a31000000000000000000...' ] } }
1

I think that the difference is simply specificity. The first example is a parser for all the logs on the chain, without specifying contract address or filter, it would technically return all the logs that are being updated, using a websocket, so subscribe provides a more general interface, which can also be used for pendingTransactions, newBlockHeaders, and syncing.

The second option is the specific way to listen for event changes related to a contract, this option includes a parser for the data that is returned in the logs which is defined by the event in the contracts ABI, hence why you have to instantiate a contract to use this listener. The data source ends up exactly the same, however, in this instance it's naming the different parameters for you to make it easier for you to ascertain what data is relevant. The results object that you want it simply the result of parsing the raw data field of the first example, which is also included in the second example. You could generate the same thing on your own by cutting the raw data into a bytes32[] and parsing and decoding the values of the individual indexes but why do that when this does it for you. Hopes this helps :)

  • Thanks for your answer, but way 1 is also related to a contract address. You can see it in my question: address: contractAddress – saitam Dec 22 '18 at 10:29
  • Oh yeah that is just providing a filter for the logs returned from the subscribe event. It's not instantiating the contract to get the abi and do the log parsing. The true only difference is that the second option adds helper functionality for parsing. Otherwise they are exactly the same. – shkfnly Dec 22 '18 at 12:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.