0

I want to make a smart-contract for P2P trading. I am wandering if I have to create separate contracts for each bid and agreement between two entities, or I can simply create a single contract that contains all the bids and the agreements between users?

Having only one contract will facilitate the access to it, as I will have to mange only one address, however, if I will have multiple contract, how I can manage them? especially if I will use oracle to allow external devices to provide the contracts with some external data.

Thanks.

0

What I normally use in cases like these is a "master" contract whose owner is the platform and deploys a separate contract for each "detail" contract. In your case, my suggestion is to have each bid in a separate contract, where you can store bidders address and even set a owner which is not the platform, and store the address of each bid contract in a mapping in the master contract.

Using such a scheme would allow the platform to "control" bids and bidders to deal with the bids without going through the platform. In my experience it also keep code easier to write and maintain.

  • Thanks! this is what I am actually looking for. That's mean in case if I want to interact with a specific sub contract I will need to only know the address of the master contract which in turn know the sub contract I need to call in order to get or set specific data, right? – Noureddine Nov 12 '18 at 6:14
  • Actually you can have both. As an example, I have an Event contract that keeps the addresses of all tickets sold (each one a different contract). A buyer receives the address of his ticket contract and can "use" it without even knowing the address of the Event contract. Of course the owner of the event can have access to all single tickets, but what he can do depends on the logic you implement in the contract. – Marco Ottolini Nov 12 '18 at 7:32
  • Thanks, I will start the implementation and get back to u in case of any issue. – Noureddine Nov 13 '18 at 5:01
1

There is no upper limit on complexity or data storage but there are constraints to be aware of.

The main constraint is maximum transaction gas cost a.k.a. block gasLimit, which is a variable network property voted on by the miners. This is an upper bound on the computational complexity of a single atomic transaction. Implicitly, this is a limit on the maximum size of a contract that can be deployed in one gulp.

It can be useful to break up large contracts into systems of smaller contracts that interact to ensure no single component is too large to deploy. As Marco pointed out, you can (and should) strictly control access to each component.

While there is no upper limit on the amount of data that is stored in a contract's state, there are two factors to keep in your top-of-mind.

  1. Avoid iterative processes. You need to ensure that gas cost for all interactions is scale-invariant. See here: Are there well-solved and simple storage patterns for Solidity? and here: https://blog.b9lab.com/getting-loopy-with-solidity-1d51794622ad
  2. Remember that the system is financially constrained. The dataset can be as large as you and your users are willing to finance. So, while it's theoretically possible to fill mappings and arrays with massive amounts of data, affordability tells another story.

Also worth keeping in mind is the idea of amortization of work. I believe that phrase was first put forward by Nick Johnson (reference in the articles linked above). Basically, there is no limit to the complexity of a state transition if it is modeled as multiple smaller atomic transactions, but each atomic transaction must always complete within the gas limit.

Hope it helps.

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.