Skip to content
This repository has been archived by the owner on Nov 11, 2024. It is now read-only.

feat: generate contracts for Dojo events #11

Merged
merged 11 commits into from
Oct 9, 2024

Conversation

remybar
Copy link
Contributor

@remybar remybar commented Oct 1, 2024

At the moment, a Dojo event is tagged with the attributes dojo::event and dojo::model. To avoid that, this PR implements contract management for Dojo events directly with the dojo::event. dojo::model is no more useful for Dojo events.

@remybar remybar force-pushed the feat-contract_for_events branch 2 times, most recently from a62baad to 42d3c47 Compare October 5, 2024 07:27
@remybar remybar force-pushed the feat-contract_for_events branch from 42d3c47 to 03ff137 Compare October 7, 2024 14:48
Copy link
Contributor

@glihm glihm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the good refactoring on the compiler part. Makes it more concise. 👍

event_selector: felt252,
keys: Span<felt252>,
values: Span<felt252>,
historical: bool
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm wondering if the historical should come from the calldata or something we defined when registering the event. @Larkooo could it make sense for the user to toggle this?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

At the moment, the historical flag is provided through the dojo::event attribute. That means, it is readable from the event contract (with historical()). An option would be to call the event contract in the emit() function to get the value of the historical flag. So, no need to provide it when registering the event nor when calling the emit() function.

What do you think ?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since we will add permissions, passing the boolean is effectively the cheapest way to do it, instead of reading additional data from the storage.

So let's keep it like this for the first iteration I think.

values: Span<felt252>,
historical: bool
) {
EventEmitter::emit(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't have permissions check here. It is fair to say that you can only emit an event if you have write access to it? @Larkooo @remybar ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a real safety issue to emit an unexpected event from a "malicious" contract ?
I would say that, as the address of the system which emitted the event is stored in the event data, it's easy to filter out malicious events.
On the other hand, it can be heavy for a project to handle permissions for all its events.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We checked with @Larkooo and it seems we need permissions. The point I feel hard it's the cost.. since permissions checks is expensive. But without permissions, everybody could overwrite some values... which could lead to unexpected client behavior.

@remybar remybar force-pushed the feat-contract_for_events branch from 4a2df9b to 0ce9233 Compare October 8, 2024 04:20
@glihm
Copy link
Contributor

glihm commented Oct 9, 2024

@remybar just added the EventTest trait, and the Emitter trait to do like the Store for the models. 👍

Also added the permissions, let's sync on that when you have a chance.

Thank you again for the great work on that!

@glihm glihm merged commit d4c4d93 into dojoengine:main Oct 9, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants