Architecture best practices for decentralized, multi-seller sales platform

Question

My question revolves around contracts creating subcontracts, and best practices with contract creation.

The Story: I'm creating a tool to help people buy Widgets, Gizmos and Ratchets, all of which are generic commodities. Let's call the tool ACME Industries. Now, ACME doesn't supply the products - other entities send ACME a deposit of ether, along with the prices they charge for each product, and they're listed as sellers. A buyer comes along and clicks on Widgets, chooses from a list of sellers, deposits ether into a contract. Some logic happens and then he gets physical stuff and the seller gets ether and a review with ACME.

The Questions:

• ACME Industries is itself a contract (I think) - it has functions like registerSeller{} that need to be decentralized and transparent. It also needs to hold mappings like uint => address[]. Or can it be just a JS framework for creating contracts (like acmePurchase{})?

• Should Widgets, Gizmos and Ratchets all have a separate address for contract creation, or should that information be appended to the order data?

Example:

// Product type contained in message
{"value": 555, "sender": "0x0...", "data": {"seller": 23, "product": 2}}

// Product and seller defined by address ether is sent to
{"value": 555, "sender": "0x0..."}

I think I'm having trouble wrapping my head around the fundamental differences in architecture here (versus a centralized transaction database).

Answer 1

Data structures are a challenge to grapple with. The data is, in effect, embedded in the program in a stubbornly immutable way.

Easiest ... monolithic contract with structs, arrays and mappings. In practice, I've found a good pattern is to use a mapping to a struct (details), keys in an array (index), plus a function to return the length of the array. That way your client can iterate over the keys and call other functions to work with the structs via the mapping.

Intermediate ... Use a hub and spoke architecture with seller contracts produced in a contract factory in/by the hub. The hub keeps track of the seller contracts it created and "owns". Interactions happen. The seller contract only listens to commands from the "owner" which is the hub. Some functions only listen to the seller, e.g. set the price.

Best ... having data in the contracts (which it always is) also means the contract can't be upgraded or repaired without starting with an empty datastore. Yikes! Separate storage and logic concerns into separate contracts. Let logic contracts "own" the data contracts and make this ownership safely transferable to upgraded logic contracts.

Update: see here for some example patterns: Blog: Simple Storage Patterns in Solidity