Add indexed keyword in events

[mmhh1910]

On which parameters?
What is the use case for this?
How much more expensive will the events be?

[mmhh1910]

https://www.reddit.com/r/ethdev/comments/78ugki/do_indexed_parameters_in_events_cost_more_gas/

375 + unindexedBytes * 8 + indexedTopics * 375

event Deposit(address token, address user, uint amount, uint balance);

375 + (20+20+32+32) * 8 + 0 * 375 = 1207

event Deposit(address indexed token, address indexed user, uint amount, uint balance);

375 + (32+32) * 8 + 2 * 375 = 1637

Difference: ~400 gas units.

Based on current gas of ~ 40000 gas units for depositToken, that's a 1% raise in tx cost.

=> If we see a use case, do it.

[mmhh1910]

Which parameters to index?

Only up to three parameters per event are indexable.

event Order(address tokenGet, uint amountGet, address tokenGive, uint amountGive, uint expires, uint nonce, address user);
event Cancel(address tokenGet, uint amountGet, address tokenGive, uint amountGive, uint expires, uint nonce, address user, uint8 v, bytes32 r, bytes32 s);
event Deposit(address token, address user, uint amount, uint balance);
event Withdraw(address token, address user, uint amount, uint balance);

Trade is harder to decide due to the limit of 3.
event Trade(address tokenGet, uint amountGet, address tokenGive, uint amountGive, address get, address give);
or
event Trade(address tokenGet, uint amountGet, address tokenGive, uint amountGive, address get, address give);

[JonathonDunford]

@betterdelta

Can I also ask you to list out the actual benefits to indexing parameters as well?

[mmhh1910]

https://ethereum.stackexchange.com/questions/40396/can-somebody-please-explain-the-concept-of-event-indexing explains it better than I could.

[mmhh1910]

There's more to indexing parameters. Example for ECR20 token contract 0x9e96604445Ec19fFed9a5e8dd7B50a29C899A10C which defines the event:

event Transfer(address indexed from, address indexed to, uint256 value);

Example tx: https://etherscan.io/tx/0x5fc21564240314ee2cbc87c2a854afc75f6e0692c4325a91226ecf14a7f928fc

where this was called:

Function: transfer(address _to, uint256 _value)

MethodID: 0xa9059cbb
[0]: 0000000000000000000000006e75a7f41832cb6932a98cd0367753cdf80c3ec0
[1]: 000000000000000000000000000000000000000000000010ef18607c1ac53000

So target address is 0x6e75a7f41832cb6932a98cd0367753cdf80c3ec0 and the second parameter is the amount to transfer.

The event log for this tx reads:

[5]	Address	0x9e96604445ec19ffed9a5e8dd7b50a29c899a10c
	Topics	[0] 0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef
		[1] 0x0000000000000000000000000d6b5a54f940bf3d52e438cab785981aaefdf40c
		[2] 0x0000000000000000000000006e75a7f41832cb6932a98cd0367753cdf80c3ec0
	Data	Hex  000000000000000000000000000000000000000000000010ef18607c1ac53000

Now, only the unindexed "uint256 value" data is available as the actual value. The from and to values were hashed and now display as topics.

So if you had a use case where you don't want to search for a value, but you want to see all event values, e.g. for book keeping on all addresses, you could not use indexed attributes.

[JonathonDunford]

So, my thoughts:

Indexing adds filtering on events baked into the contract basically. This seems like it would allow us to save/show all historical orders/trades/etc for certain users in the interface without storing that all in our database.

I think that is worth 1-2%

Deposit and Withdraw should track amount as well.

The 3 parameter limit reeeeeally sucks for trades. It seems like the only things we should index then are user from, user to.