feat: add draft of arc-3 #3
Conversation
|
I do not fully comprehend the purpose of the coordinator contract but when talking about it from the context of amplifiers state, my understanding is that if I want to discover all related contracts for a particular chain by its name, coordinator is (or should be) the place to go to. Having said that, I am a bit concerned about consolidating queries for ALL information into a single contract. I see each contract as a self contained unit which should make available, all data/state, through queries contained within it. This approach seems to be creating an API contract of sorts. This would mean that if you add more state to contract x, you would now have to rollout a new version of coordinator with support for providing that state in a query used by others. I don't think this is a great idea. |
As far as the scope of this arc is concerned, the idea is not to consolidate all queries for all information into the coordinator contract. Rather, the goal is to provide a few (as few as possible for maintainability, not ONE) endpoints on the coordinator contract to provide two functions:
|
| ### Detailed Risk Analysis | ||
|
|
||
| #### Query Performance | ||
| **Risk**: The coordinator contract needs to aggregate data from multiple sources to fulfill queries, which could lead to poor performance if data needs to be collected (pullled) during query execution. |
There was a problem hiding this comment.
| **Risk**: The coordinator contract needs to aggregate data from multiple sources to fulfill queries, which could lead to poor performance if data needs to be collected (pullled) during query execution. | |
| **Risk**: The coordinator contract needs to aggregate data from multiple sources to fulfill queries, which could lead to poor performance if data needs to be collected (pulled) during query execution. |
| **Mitigation**: | ||
| - Implement a push-based state update system where contracts update their state in the coordinator | ||
| - Each contract pushes relevant state changes to the coordinator when they occur | ||
| - Coordinator maintains an up-to-date cache of all required data in its state | ||
| - Queries can be served directly from coordinator state without cross-contract communication |
There was a problem hiding this comment.
this would add a massive amount of complexity to the system. Do we have evidence that it is necessary?
| // Pagination | ||
| struct PageConfig { | ||
| // Start after this key (None for first page) | ||
| start_after: Option<String>, |
There was a problem hiding this comment.
you have start_after and next_key. That sounds like the key itself would never be queried
No description provided.