Design update#153
Conversation
| // ↑ applicationId (selected by contract) | ||
| ``` | ||
|
|
||
| The contract iterates over all per-application queues, compares the block timestamp of each queue's head request, and returns up to `maxCount` requests from the application with the oldest head. The application's state root and `applicationId` are returned alongside the requests. |
There was a problem hiding this comment.
Instead of selecting the application with the oldest head, I would consider to select the application with the oldest lastServed timestamp (where lastServed is a new field, updated in every stateUpdate() / batchStateUpdate() call).
This does not solves the problem that a failing app could block all the others (7.4), but may increase the fairness: if we have an app with a big volume compared to the others, with the "oldest head" method, it might keep the system occopied for most of the time, and the low volume apps could wait for long untill being selected.
what do you think?
There was a problem hiding this comment.
It's a good idea, the "oldest head" kept the orginal order, where there was just one queue for all the apps but this way the execution time is more fairly divided amongst apps. However, instead of lastServed , I would propose a round robin, that needs less storage (just 1 field for keeping track of the last app instead of a timestamp for each app) and it is easier to find the next app.
Jira: https://horizenlabs.atlassian.net/browse/HZN-2931?atlOrigin=eyJpIjoiNzA5YjE2YzEwNTAzNDA4M2EwNWIxYWZhMjhkNzgzMWYiLCJwIjoiaiJ9