Our MVP for encrypted transaction inputs on the validator added an admin service which essentially allows introspection of the validator's transaction set, and requesting a decryption share for a specific one.
This worked for the MVP, but now needs to be properly designed and stabilized. As an example, listing transactions is not paginated and therefore OOMs/breaks on validators with any non-trivial history.
Part of this task is to decide what we actually need to support decrypting a transaction's inputs. For example, it may not be necessary to list transactions at all - but perhaps we do want that so that its a self-contained system and doesn't need additional services.
This is an admin only endpoint, and it should therefore be secured externally and not be accessible by the public. Also consider that we may want to extend this service with things like runtime configuration changes e.g. dynamic log levels.
Our MVP for encrypted transaction inputs on the validator added an admin service which essentially allows introspection of the validator's transaction set, and requesting a decryption share for a specific one.
This worked for the MVP, but now needs to be properly designed and stabilized. As an example, listing transactions is not paginated and therefore OOMs/breaks on validators with any non-trivial history.
Part of this task is to decide what we actually need to support decrypting a transaction's inputs. For example, it may not be necessary to list transactions at all - but perhaps we do want that so that its a self-contained system and doesn't need additional services.
This is an admin only endpoint, and it should therefore be secured externally and not be accessible by the public. Also consider that we may want to extend this service with things like runtime configuration changes e.g. dynamic log levels.