Style Guide: Modular or Monolith Files?

[liam-ot]

Hello,

I have a decentralized system in mind that i envision requiring three contracts:

• Contracts A, B, and C
• An app which communicates with them

A, B, and C are similar contracts, they store information about aType, bType, and cType items in the respective contracts through getters and setters, and some special logic per contract this means the app needs to communicate with multiple contracts but they remain very simple and contained

In general is this modular approach the correct design to envision, or is it better to build one God Contract which is a conglomerate of all three contracts? What are the tradeoffs to consider at this level?

[fubuloubu]

Think of contracts as first class citizens of the EVM execution environment (because they are), akin to object instances of classes (class : contract :: instance : address). If A, B, and C all perform one set of functionality (such as depositing assets into a pool and trading against them a la Uniswap), and the only reason you want to make the code modular is to reduce mental overhead of writing it, then yes it makes the most sense to make it monolithic because the tradeoff is the increased mental overhead of reading it (i.e. tracing logic through multiple files)

If instead, you have separate functionality that each contract is performing (let's say that A and B are two different types of interactions, and C is a router that works with A and B to coordinate the higher level workflow of the application) then yes it makes more sense to keep them separate.

Until modules are implemented the current best practice is to re-write all of the types and interfaces you are using in each file that is using them, which will add some additional overhead for writing it (but again not for reading it since each file stands by itself as monolithic code, which makes it easier to audit). Once modules are implemented, my recommendation would be to put re-usable types, functions, and interfaces into a common library module that all of A, B, and C can use, and then build out each separate functionality into separate contracts that use the common library module to implement them (remember, class : contract :: instance : address), so as you deploy them in your on-chain hierarchy, they stay easy to audit since you only have to look at two modules (one of A/B/C and the common library module) to understand each individual on-chain component (e.g. contract deployment at a specific address)

[liam-ot]

This is very helpful, thank you for taking the time to explain this to me. Sorry for the late acknowledgement I went on a long vacation and had to get back into the flow of my job before picking up my vyper project again.

For now I will take your suggestion of condensing my contracts into one monolith. While I am opposed to this style in general, the limitations of vyper not yet having modules (#2431) implemented means it's the best available route for my application.

One thing I am not clear on is what this means: class : contract :: instance : address, my understanding which I think is incorrect is that classes should be viewed as contracts and instances of contracts as addresses. Is this correct?

[fubuloubu]

One thing I am not clear on is what this means: class : contract :: instance : address, my understanding which I think is incorrect is that classes should be viewed as contracts and instances of contracts as addresses. Is this correct?

A contract is like a class definition, and a deployed contract located at a specific address is like an instance of that class, in the traditional object-oriented programming paradigm

[liam-ot]

Yes, okay that makes sense.

If instead, you have separate functionality that each contract is performing … it makes more sense to keep [the individual contracts] separate

As I re-read your post I think it makes most sense to keep them separate. I can give an example, this is not my application because I'd like to keep that private but it is akin to what I want to do:

If I wished to have a decentralized high school, there may be a few simple things to represent. To keep it very simple let's say there are Students, Faculty, and Tests. In this case, my idea would be to make a School contract, which then uses the Students, Faculty, and Tests contracts, which each have their own special functionalities, to facilitate the workings of a School.

Does this design make sense? I'm coming from an AWS serverless microservices background which is why I want to break things into small pieces and have one center of coordination using each little piece to facilitate the application's functionality.

[fubuloubu]

It makes more sense to think of them as having interfaces, basically the concept of the "School" doesn't exist, or only exists in the context of how the Students, Faculty, and Tests interact with each other.

It would be really hard to comment further without seeing the code, but it sounds like Tests exist solely during an action context, meaning that they are the scenario that you want to create specific interaction rules between the Students and the Faculty (who are both in the "School", but that doesn't matter if we consider the concept of the "School" exists whenever the Students and Faculty interact during the Tests... which is why we're just gonna ignore it lol)

Such rules might include:

1. Tests are started when the Faculty agree to start it
2. After a Test is started, a Student may submit an encrypted proof of their solution
3. After a time period has elapsed since starting, no more Students may submit a solution
4. After the Test is over (time period has elapsed), the Faculty can evaluate the unencrypted solutions (off-chain?) against a pre-existing rubric and submit a score for each solution that is revealed
5. A student may dispute a score, and if it mismatches with the pre-defined rubric, the student can submit proof of mis-evaluation and have the Faculty member fired.

Again, I don't really know your use case, but it's helpful to think of what interaction(s) you're trying to model, what Actors are involved in each interaction (actually kind of similar to microservice architecture design), and what the (positive and negative) incentives they have for performing these interactions according to your design encoded in your modeled ruleset

[liam-ot]

Thanks so much @fubuloubu your comments have been very very helpful here!