For Rosetta, blockchain teams are expected to create and maintain a single Dockerfile (referencing any number of build stages) that starts the node runtime and all of its dependent services without human intervention.
Some blockchain nodes rely on a number of dependent services to function correctly. It is often the case that these nodes require an explicit startup and shutdown sequence to function correctly or prevent state corruption. With distributed services (in multiple running containers), this sequencing of operations can require a custom deployer for each blockchain.
With a single Dockerfile, blockchain teams can explicitly specify how services should be started and stopped using scripts. They can also easily test for issues in various scenarios, as all services are confined to a single container instead of being spread across some set of systems.
Middleware vs Embedded
Blockchain teams that do not wish to extend a core node to comply with the Rosetta API specifications can implement a middleware server that transforms native responses to the Rosetta format. However, this additional service's startup and shutdown must be coordinated by the Docker implementation.
Single Volume Mounting
When a deployment is started from a single Dockerfile, it is straightforward to mount a single volume to the new container and manage all of its state. Node deployments can be easily scaled by duplicating this volume to any number of new hosts without sophisticated tooling.
Stateful Data API Implementations are OK
Additional caches (those outside of what is stored by the node) can be used in a Data API implementation. The only expectation is that the state must be stored in the
/data directory (as mentioned previously).
Stateful implementations of the Construction API, however, are prohibited. Clients accessing a Construction API implementation will provide all information necessary to construct a valid transaction.
Was this helpful?