(image)

Programming Hotmoka
A tutorial on Hotmoka and smart contracts in Takamaka

8.7 Sentry nodes

We have seen that a Node can be published as a Hotmoka service: in a machine my.validator.com we can execute:

TendermintNodeConfig config = TendermintNodeConfigBuilders.defaults().build();


try (Node original = TendermintNodes.init(config);
    NodeService service = NodeServices.of(original, 8001)) {
    ...
}

The service will be published on the internet at ws://my.validator.com:8001. Moreover, in another machine my.sentry.com, that Hotmoka service can be adapted into a remote node that, itself, can be published on that machine:

try (Node validator = RemoteNodes.of(URI.create("ws://my.validator:8001"), 80000);
    NodeService service = NodeServices.of(validator, 8001)) {
    ...
}

The service will be published at ws://my.sentry.com:8001.

We can continue this process as much as we want, but let us stop at this point. Programmers can connect to the service published at ws://my.sentry.com:8001 and send requests to it. That service is just a bridge that forwards everything to the service at ws://my.validator.com:8001. It might not be immediately clear why this intermediate step could be useful or desirable. The motivation is that we could keep the (precious) validator machine under a firewall that allows connections with my.sentry.com only. As a consequence, in case of DOS attacks, the sentry node will receive the attack and possibly crash, while the validator continues to operate as usual: it will continue to interact with the other validators and take part in the validation of blocks. Moreover, since many sentries can be connected to a single validator, the latter remains accessible through the other sentries, if needed. This is an effective way to mitigate the problem of DOS attacks to validator nodes.

The idea of using sentry nodes against DOS attacks is not new for proof-of-stake networks, whose validators are considered as precious resources that must be protected. It is used, for instance, in Cosmos networks [25]. However, note how it is easy, with Hotmoka, to build such a network architecture by using network services and remote nodes.