We have seen how multiple times HOPR testnets get quickly overwhelmed due to the amount of demand and usage from our users. This is entirely normal, and every time it pushes the team to identify bugs and improve the software.
From a developer’s perspective, this is great. However, I would like to push the protocol and not only the software a bit harder by trying to mimic a HOPR Testnet and use it for an actual application.
This is what I am proposing: a cloud testnet with multi-tenancy support.
What does this mean? It means that HOPR Association supports 10-20 cloud nodes (ie inside one or more data centers) such as they can be used by any developer by exposing their APIs or domains to HOPR Apps developers. In the same way that public RPC endpoints for blockchains expose accessible endpoints (e.g. https://rpc.ftm.tools/), I would like HOPR Association to be the host of ready-to-use HOPR nodes, such as I could point my app to https://node-1.hoprnet.org. This app would be connected to all the other nodes, and could effectively mix packets using the HOPR protocol. By doing so, we will start transferring traffic and testing the privacy capabilities of the protocol, which we currently aren’t fully exposed to until the software and testnets are stable enough.
For this to work, we need HOPR nodes multi-tenancy. This means that a single HOPR node can represent multiple users. Right now, a HOPR node creates a private key, and uses a single database to store the tickets. Nothing stops us to modify the node such as it can load in memory (e.g. within a browser session or service worker) multiple keys, reusing the same database for multiple users ensuring no data can be seen by other users. Heck, by doing so we would even re-use the indexer for multiple sessions, so it might be something we can even flirt with even after the software is stable. I remember some of the original concepts around DEADR had nodes that could be simply used so users don’t need to run a node.
The multi-tenancy part is a little more involved, it would actually require the whole networking stack to be aware of this as you’d want to expose multiple peer ids through a single node. All of ticket handling and data-storage would need to be made aware as well. I think, as you pointed out, the only bit which could be shared is the indexer.
Therefore, quite involved and not applicable to the scope of the DAO round. Nevertheless, an idea worth discussing further.
The data handling and ticket setup can probably be handled with an id. However, you are totally right that the networking stack has no cut-dry option, or at least not one that an external w/o deep understanding of this hand-shaking could do.
This actually left me thinking, whenever the software itself can’t deliver, an application on top could always achieve this. The multi-tenancy part could be achieved by setting up an application that could lock people’s funds within a smart contract and grant transfer access only to the HOPR node private key. A proxy or gateway-like app + smart contract that would work as a tenant, and to the HOPR node this would be invisible and would remain to behave as a single-node single-user.
The node and cloud part still stands, as otherwise the mixing setup would get lost. What I’m suggesting instead is having an app on top of HOPR node which is able to register against it using its API and token, that would in exchange be able to “host” multiple users.
This app (web or desktop) would create a wallet per user (a la Hedgehog - https://hedgehog.audius.org/) and ask users to deposit xHOPR + xDAI funds to it. These would then be forwarded to a smart contract that would grant owner access to specific balances per user to a single HOPR node account. The HOPR node account would effectively work as a “pool” for multiple user funds and the app keep track of balances. When the balance is positive per user, then the user will be able to send a message that will then be forwarded to the HOPR node.
There are two major challenges here: the first one is that the double accounting (user <-> app, app <-> hopr-node) would need to be throughly tested, as to avoid making user_1 be able to use funds from user_2, as to the hopr-node it only has one. The second challenge comes from the ability to allow interaction from the hopr-node to the app, which will likely need to either use a database (yuk) or a smart contract to handle these interactions. The latter would need the hopr-node to have API-like smart contract calls which can be executed on behalf of its underlying private key, which either requires custom work per call. The alternative is adding an API endpoint like /sign-transaction which would take a generic rawTransaction data and sign it, but that would need to have a bunch of security padlocks and whitelists to avoid being abused.
That’s the idea. The debate goes on whether it’s possible as I’m describing it and whether it’s worth it considering the resources.
Thanks for the suggestion! Remember, if you’re finished and would like to make this an official proposal, please edit the title to include “[Proposal]”. It will then be flagged for moderation.
More information on the validity guidelines and submission process can be found here: