Add context to CIP124 EventIDs #148
Conversation
| * `blockNumber` is the ETH blockNumber from the after header or a prev time event. | ||
| * If the after header is not present then follow the prev cain to a time event. | ||
| * If there is no time event in the chain then use 0 |
There was a problem hiding this comment.
Can we use block_timestamp instead of blockNumber? This would give us flexibility in the future if we wanted to support other ways than ethereum blocks as a source of truth for this value.
| * `separator_value` is the value in the field specified by the separator_key | ||
| * `context_key` is the header field that has the context_value in it. | ||
| * `context_value` is the first 8 bytes of the value in the field specified by the context_key. | ||
| * `blockNumber` is the ETH blockNumber from the after header or a prev time event. |
There was a problem hiding this comment.
"after header" isn't really defined yet (CIP is pending) does it make sense to mention it here? Maybe we need to merge the after CIP before this PR?
| * `init_event_cid_bytes` is the CID of the first Event of the this stream. | ||
| * `event_height` is the "height" of the event InitEvent. For InitEvents this value is `0` else `prev.event_height + 1`. |
There was a problem hiding this comment.
Given that we are removing event_height, is init_event_cid_bytes still relevant? Seems like this would sort multiple events from the same stream next to each other given that they happen at the same ethereum block. There would be no specific logic to the order between these events though.
Seems to me that having the InitEvent hash here adds marginal value given that we sort by controller before that?
No description provided.