Modify fee of System.Runtime.GetNotifications #2748
Conversation
erikzhang
commented
May 21, 2022
•
erikzhang
commented
- Fixed GAS price for GetNotifications is cheap #2725
- Added a benchmark.
|
Really happy to see we finally have a benchmark project. it would be better if we could use |
If the project become more complex in the future, we can consider it. Currently I don't think it's needed much. |
|
Maybe we should charge per-element here? Sending notifications is naturally charged per-element, maybe getting them should also be, it'd be more fair. |
|
The problem with per-element charges is that when you create a transaction it is impossible to know how many notifications the contract will receive when it executes. |
|
Transaction scripts are test-executed usually and I don't think this problem is any different from any other test/real invocation GAS/state difference that can happen in lots of other scenarios. |
We should try to avoid this situation. |
Sure, but here it will depend on the number of emitted notifications. To me it's not very likely to change unless the expected transaction outcome changes significantly anyway (like some transfer or asset mint fails). Even if it is to change, it's more likely that some notifications will be omitted rather than created (which costs additional GAS already). |
|
@roman-khimov What about neo-project/neo-vm#473? |
Unexpected. What's the execution time for #2725 with this? In some ways it feels like this problem shouldn't require changing the VM, but at the same time it can be effective and not very restrictive (it's hard to imagine normal contract trying to reuse (referenced) event items after notification). |
|
Immutability can be very useful, not only in the notification's scenario, but also for calling between contracts. We can open this function to contracts in the future, such as adding a new |
|
Merge? |
Fix DoS, follow neo-project/neo#2748.
update GetNotifications fee neo-project/neo#2748
