eth_getFilterChanges
, eth_getFilterLogs
both return additional fields: "type" and "polarity"
type
:STRING
-pending
when the log is pending.mined
if log is already mined.polarity
:BOOL
- eithertrue
(the transaction pertaining to this log was mined or arrived as pending compared to the previous notification/notified block) orfalse
(the transaction pertaining to this log was reverted or was deleted compared to the previous notification/notified block).
// Result
{
"id":1,
"jsonrpc":"2.0",
"result": [{
"logIndex": "0x1", // 1
"blockNumber":"0x1b4" // 436
"blockHash": "0x8216c5785ac562ff41e2dcfdf5785ac562ff41e2dcfdf829c5a142f1fccd7d",
"transactionHash": "0xdf829c5a142f1fccd7d8216c5785ac562ff41e2dcfdf5785ac562ff41e2dcf",
"transactionIndex": "0x0", // 0
"address": "0x16c5785ac562ff41e2dcfdf829c5a142f1fccd7d",
"data":"0x0000000000000000000000000000000000000000000000000000000000000000",
+ "type":"mined",
+ "polarity": true,
"topics": ["0x59ebeb90bc63057b6515673c3ecf9438e5058bca0f92585014eced636878c9a5"]
},{
...
}]
}
- logs order
logs should be returned in order, from earliest to latest.
In case of fork, the order should be following:
//
// ......1 - 2 - 3a - 4a
// ...............\- 3b - 4b - 5b
//
// getLogs({fromBlock: 4a, toBlock: 5b}) should return
// 4a, 3a, 3b, 4b, 5b
//
eth_newFilterEx
(new version ofeth_newFilter
)eth_getLogsEx
(new version ofeth_getLogs
)
They expect 'fromBlock', 'toBlock' to be block hash instead of block number.
params: [{
- "fromBlock": "0x1",
+ "fromBlock": "0x599438826541d3e8c29c167fa15b491d91b65e422f8b8a3da69eaa9a43c832e1",
- "toBlock": "0x2",
+ "toBlock": "0x599438826541d3e8c29c167fa15b491d91b65e422f8b8a3da69eaa9a43c832e1",
"address": "0x8888f1f195afa192cfee860698584c030f4c9db1",
"topics": ["0x000000000000000000000000a94f5374fce5edbc8e2a8697c15331677e6ebf0b"]
}]
eth_getFilterChangesEx
(new version ofeth_getFilterChanges
)eth_getFilterLogsEx
(new version ofeth_getFilterLogs
)
eth_getFilterChangesEx
&& eth_getFilterLogsEx
have the same input params as eth_getFilterChanges
&& eth_getFilterLogs
, but different format of returned objects.
// Result
{
"id":1,
"jsonrpc":"2.0",
"result": [{
"blockNumber":"0x1b4" // 436
"blockHash": "0x8216c5785ac562ff41e2dcfdf5785ac562ff41e2dcfdf829c5a142f1fccd7d",
"type": "pending",
"polarity": true,
"logs": [{
"logIndex": "0x1", // 1
"transactionHash": "0xdf829c5a142f1fccd7d8216c5785ac562ff41e2dcfdf5785ac562ff41e2dcf",
"transactionIndex": "0x0", // 0
"address": "0x16c5785ac562ff41e2dcfdf829c5a142f1fccd7d",
"data":"0x0000000000000000000000000000000000000000000000000000000000000000",
"topics": ["0x59ebeb90bc63057b6515673c3ecf9438e5058bca0f92585014eced636878c9a5"]
},{
...
}],
},{
...
}]
}
Fabian: I like it but i would change three things:
polarity: true
->invalidated: true
orinvalid: true
- get rid of the old filter and add
eth_newFilterEx
aseth_newLogFilter
, to make it fit the other filter type names (eth_newBlockFilter
,etH_newPendingTransactionFilter
) - Don't return logs grouped by blocks, as i don't see an advantage besides that it is harder to parse. (Logs don't really care in which block they came, though we need to add the
blockX
properties for reference)