-
Notifications
You must be signed in to change notification settings - Fork 2.7k
Pass topics along with events #2563
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The quadratic check for duplication in topics can be reduced to O(n log n) at the cost of a memory allocation. Additionally, it appears that event delivery is unreliable. If it is, that should be documented.
| let event_idx = { | ||
| let old_event_count = <EventCount<T>>::get(); | ||
| let new_event_count = match old_event_count.checked_add(1) { | ||
| // We've reached the maximum number of events at this block, just |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This means that event delivery is unreliable, which could lead to starvation or deadlock in some protocols.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, this is more related to #2491 or even before that, to #2282.
I believe this code is a mere defending practice and will not be triggered. Here is my reasoning: wasm32 is a 32-bit platform. It can have at most 4GB of memory, that is, 2^32 bytes. Considering an element to be u8, by the time we reach this number of elements the memory will already be full.
If you are still concerned by this issue, I think it would be best to move this discussion into a new issue (or at least to the now closed #2282)
e23224e to
fe64849
Compare
gui1117
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks good
gui1117
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks good to me
* Introduce an IndexedEvent * Plumb topics through the Ext interface. * Add topics to ext_deposit_event * Charging for events. * Check the number of topics. * Check for duplicate topics. * Bump API version. * Move derive(*Eq) under test. * Use sorting for finding duplicates.
This PR builds on top of #2491 and adds an ability for a contract to supply a list of topics along with an event.
ext_deposit_eventnow gets two paramters to supply a buffer with a topic list:topics_ptrandtopics_len. There are some restrictions on this list.Vec<TopicOf<T>>vector.max_event_topics(otherwise, the function traps).There is one exception for 1) - passing
0to thetopics_lenparameter is treated as an empty topics vector. In this case, the value oftopics_ptris ignored. The deduplication check is implemented as two loops: this is ok, as long asmax_event_topicsis small, and doesn't require additional memory.This PR also introduces some fixed gas fee per topic, which is checked before recording the event.
The rest is almost the same, all events are recorded along with their topics and if they made it to the finalization phase, then all the events are deposited with respective topics.