One issue many Aragonians might have noticed is that organisations tend to take a long time to sync up if you haven’t visited the organisation on your current device. This is only exacerbated by time, since the number of blocks the client has to sift through increases.
In this thread I want to discuss a few options for centralised caching solutions we could develop and ship today as a means of decreasing the time it takes to load organisations.
While we all love our decentralisation, it comes with obvious trade-offs, and speed is usually one of them. While I would love to be a master of cryptography and somehow know how to make a decentralised caching solution for Aragon orgs (believe me, I’ve tried), I think having an open-source centralised solution would be a good first step.
With the solution being open source, technical users would be able to deploy their own caching server. This also means that other users can use the caching server of people they trust.
I’ll outline a few different types of caches:
Event caching
This solution might be the least invasive of the two, and also the solution that requires the least amount of development time.
The basic idea is to have a small service that has a list of apps and the events they emit, alongside the core aragonOS events. This service sits between the client and an Ethereum node and mimics the Ethereum JSON-RPC.
Users would be able to use this solution simply by swapping out the Ethereum node in their client, since it would be entirely Web3 compatible.
The service would be fast at responding to crucial “boot-up” RPC calls such as eth_getLogs, and would simply pass any other call it does not care about directly to the external Ethereum node.
The trade-off of this approach is simply that it is not as fast as a full state cache.
Full state cache
A full state caching service would run a copy of aragonAPI that continually runs for a set of organisations. It would expose a simple REST interface or similar to serve up the entire state of the organisation over HTTP.
This is sort of an invasive approach as it requires support directly in aragonAPI and the client.
The pros of this approach, however, is that it is much faster, since the entire state of the organisation would be available in about 1 HTTP request, which would be on par with Web2.
What (if any) of these caching solutions would you be interested in?
- Event cache
- Full state cache
- None
0 voters
As a side note, we intend to develop a solution based on feedback and interest in this thread at 1Hive.
