Centralised caching solutions

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.

3 Likes

How different are these approaches? Is there a logical path from Event cache to Full state cache?

How significant of an improvement is the Event cache over the status quo?

Is the idea here that organizations would somehow apply to get added to the “set”?

The difference is that one takes almost no time to develop and has no impact on the Aragon client but is potentially only a marginal improvement where the other solution takes a long(ish) time to develop, changes things in the Aragon client and is a huge improvement (“near-instant”).

I suppose that depends on what operational mode caching servers want to run in. We can make it so that caching servers only apply to a set of organisations that the caching server owner decides, and the other operational mode could be that it automatically adds an organisation to the set the first time a request for that organisation is sent to the server.

We are building a framework for addressing exactly this problem at:

We will be doing a workshop at devcon5

2 Likes

Cross posts from Just enough decentralization

3 Likes