The security of the current account structure being used by Evernode Hosts

[wojake]

Proposal: New XRPL account structure for hosts

The current account structure of Evernode Hosts is simple and direct, each Evernode Host has 1 XRPL account which it uses to manage its host registration, offer up its instances and receive payment.

I'm concerned about this structure as the host's XRPL account could be considered a hot wallet as its private key is stored in the server's filesystem and it's being used to sign transactions on an hourly basis (minimum).

I propose a new structure in which the host operator could optionally decide to automatically transfer funds to a certain account that the host doesn't manage or hold its keys, but the host's operator has control over it outside of the server. This structure is much more secure as the host doesn't hold the account's private key and the account could be setup and stored in a much more secure environment / way.

In technicality, the host operator could code a script which does this without needing any changes to evernode-host or introduce a new structure. It should be easy.

[ravinsp]

@wojake Good point. Yeah, if you know what you're doing, you could set up something on your own to make it safe. But architecturally we need to think about this as a generic problem (not just maintaining a cold wallet) since there could be many other custom account management activities the owner might want to perform.

I can see how such an external application/script might interfere with Sashimono as well. If there are multiple applications signing transactions periodically, sometimes they will conflict with account sequence of they try executing different transactions at the same time. There has to be retries or some sort of coordination between the applications to overcome this.

Approaches I can think of:

1. A hook that can be installed on the host XRPL account. I think this is the best way to automate account management, but the owner must have the knowledge to program the hook as they wish and install it on the account.
2. A "script" that can be plugged into Sashimono so it will automatically execute your script in a way that doesn't conflict with Sashimono's own transaction activities.

[wojake]

I'm in favor of Approach ~1 and oppose ~2 since that may interfere with Sashimono. I'm sure this is do-able as the logic behind the Hook shouldn't be too complex compared to the registry hook (i.e. https://gist.github.com/muzam1l/953662b22d065449f8ab6f69bc2afe41)

I'll keep this issue open until we implement this 😄