[TASK] Separate BlueprintManager from InstanceManager

[drewstone]

Overview

We should have separate contracts for dealing with blueprints and service instances. This will likely help when dealing with slashing reports on a specific service instance. It will also allow us to store data related to service instances separate from the blueprint manager contract to keep that more lightweight.

Checklist

• [ ] When a service instance is created on-chain, a Service Instance contract should be deployed / created.
• [ ] When an operator is slashed, this should be handled by the Instance contract. #777

[shekohex]

I've conducted thorough research on this topic, and I'm convinced that keeping them separate is a good approach. Here's what I've discovered:

1. BlueprintManager deploys a new contract for each service instance.
   • No modifications are required on the Services pallet; it functions seamlessly since Blueprint Manager will route calls to the correct service instance.
   • Blueprint Manager maintains a map of all service instances' IDs and their corresponding contract addresses.
   • However, this approach introduces complexity when considering upgrades, as the implementation is not singleton-based.
   • It also results in wasted space, as the same contract is deployed multiple times (with only the service instance ID differing).
2. BlueprintManager deploys a proxy contract for each service instance.
   • This enables effortless upgrades to service instances, as they're all proxies to the same implementation.
   • The implementation is shared among all service instances, while each proxy has its own storage.
   • Blueprint Manager routes calls to the correct service instance.
   • Blueprint Manager maintains a comprehensive map of all service instances' IDs and their corresponding proxy contract addresses.
   • This approach optimizes code space, as the same contract is deployed only once.

keep in mind that neither of these solutions, even the original idea of making them separate) addresses access control issues. In fact, I firmly believe we don't need to resolve this problem, as it's not a concern for us. Slashing should be combined with reporting; Blueprint Manager will handle both. To slash an operator in a service instance, the caller to the slashing precompile should be the BlueprintManager contract, with the service instance ID and any slashing conditions as arguments.

[drewstone]

2nd option seems good here. I do think the bulk of the work here (given blueprint developers can actually choose 1 or 2 and we are just leading them down a path) is actually to figure out how slashing should work.

I would aim to get the slashing precompile and logic spec'd out as well, since a Blueprint developer can choose to use routes 1 or 2 (since it doesn't require any runtime change).

[drewstone]

Note, we should aim to not have slashing integrated until even after services are live. We simply need that work to begin. Proxy's seem like a good way to allow service instances to upgrade to contain slashing capabilities / reports.