RGB interfaces: traits or APIs?

[dr-orlovsky]

In RGB a contract may implement as many interfaces as it wants; new implementations may be added after the contract release/creation (but only if the contract has corresponding business logic).

This opens a question for the best practices in interface design. I see two main approaches:

1. "Holistic": use an interface to provide a complete API solving some business case: fungible asset, identity, NFT etc. This is approach currently used with RGB20-25 interface standards, and it results that each interface is quite large and provides a lot of mixed functionality related to the asset name and other operations which, in fact, are shared across different interfaces, repeating over and over again. Thus, there is a second approach:

2. "Trait-based": treat each interface as a certain trait of a contract, exposing very atomic and small piece of functionality - and use interface composition for covering all of the contract business logic. For instance, there may be an interface for asset name; and another for renaming an asset; and another for providing information about supply etc - and they will be all distinct.

I do not have a strong opinion which of the approaches is better. Overall, I prefer atomicity and composability since it simplifies formal analysis, innovation, improves security. However, in case of interfaces, I am not sure that trait approach will not have a severe trade-offs which I do not yet see...

Since interfaces are not part of the consensus layer, and a contract may have multiple interfaces implemented - and can add new interfaces even after release, these approaches can be combined and we can switch between them at any moment...

[cryptoquick]

I agree, I would prefer a trait-based approach.