4

I have more of a high level question about the way we design a system using smart contracts.

Imagine a system that people can purchase products, now we build this contract using Solidity so that the seller says he has this product that wants to sell it for X dollars. and buyer comes in and says he is interested and pays the money and done.

My questions:

Are we supposed to "deploy" only 1 contract (or a set of related contracts) that holds the information of all the sellers and all the stuff they sell and all the transactions that happens between buyers and sellers?

Or are we supposed to "deploy" 1 contract for each user that is going to be a seller in this system?

Or are we supposed to "deploy" 1 contract each time a seller has a new product that is putting out for sale?

6

Like everything you build, it's all about tradeoffs. In this case, the trade is cost vs. safety/audibility.

If you choose to deploy a contract each time a seller has a new product, they will be spending a large amount of gas (and therefore money) reimplementing the same smart contract logic that exists elsewhere, so depending on what goods are being sold, this may not be worth it (in the case where houses are being sold, the cost of deploying a new contract would be insignificant, but if it's stickers that are being sold, it might become a large portion of the price).

If you choose to have one large contract that keeps track of all sellers, goods, and transaction logic, you are going to have a massive contract that becomes very hard to audit and therefore very hard to keep safe. Furthermore, the larger the contract is, the larger a target it becomes for any evil-doer.

Most large contracts that exist today are fairly modular and have different contracts for logic, storage, and control, which makes them easier to audit and upgrade. The goal is to find a happy medium between cost, safety, and upgradability.

0

The answer is only the first choice: You should consider: "deploy" only 1 contract (or a set of related contracts) that holds the information of all the sellers and all the stuff they sell and all the transactions that happens between buyers and sellers.

To make things clear, let us speak about the "Sellers". Think about you have a database and you want to create tables. You will create a table for Sellers. You will never create a table for each Seller. Similarly, you will create a Smart Contract for your Sellers and store there information inside that Contract. You should not deploy a contract instance for each Seller! This is the main idea that answer your question.

Additionally, you should not think about a contract as exactly an object in OOP. As proposed by Ethereum, Solidity is a Contract-Oriented Programming Language. Check its name at: https://github.com/ethereum/solidity. So, your should not just adapt your OOP in solidity. As some concept are applicable (like inheritance) and the others should differ (like the way we design the communication between contracts).

Another consideration to be added. If you will go with your second or third proposed approach, you will need more significantly much more gas to operate your system. Note that the "gas" required to deploy a contract is much much more than the one needed to communicate with another existing contract. Additionally, the gas needed to interact with a different contract is much much more than the gas needed to do some internal operation within the same contract.

The last consideration that should come to your mind is the management overhead needed to manage the contracts. If you go with the second or third approach, you should think about how much headache you will have if you will need, for example, to change the secondary owner of the contract; For example, in case you set a secondary owner (could be also a multi-sig contract) that is managed by you and not by the end user. And that you will need to use in case the end user (the seller) lost his private key for example!

However, after putting in mind the mentioned points, you may decide to organize your logic in separate classes and libraries to ensure maintainability and ease upgrading. In such a case you may decide to have contracts for:

  • People: To contain people information (because every buyer may sell something and therefore be a seller, this contract will save both Buyers & Sellers)
  • Products: To save products information.
  • Market: To maintain your logic (This smart contract could handle and process the purchases)

Actually, you can still save the data of People and Products in the same Market contract. But this may complicate the future updates of your system. But you can also maintain both People and Products data in the same smart contract.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.