You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Since storage nodes will need to answer a lot of read-only queries from clients, it would make sense to support an architecture where a single "storage worker" is actually internally composed of many servers that can distribute the read load.
The major difference to syncing with other untrusted servers is that we can assume that all servers within such a cluster are trusted and speed up syncing (e.g., by using Badger's replication mechanisms).
We should also consider easily supporting configurations that have tiered access with split nodes handling workloads for different classes of users:
Read/write storage access for (staked) committee members. Staked members in the current committees would always have unlimited access as this is needed for normal operation of the network and things like the availability probes.
Read storage access for random users. These could have much stricter usage limits.
Since storage nodes will need to answer a lot of read-only queries from clients, it would make sense to support an architecture where a single "storage worker" is actually internally composed of many servers that can distribute the read load.
The major difference to syncing with other untrusted servers is that we can assume that all servers within such a cluster are trusted and speed up syncing (e.g., by using Badger's replication mechanisms).
cc @ravenac95 @ptrus
The text was updated successfully, but these errors were encountered: