0

I would like to implement a tracking system .. where i track events between two parties who deliver an item between them .. then the receiver would deliver it to another person and so on...

I would like to create a contract for each transaction (between every two) at the same time , I would like to still be able to track all the chain .. the originator and the previous contract ...

Is there a way to do it ?

0

Preface: If you want to use web3 to create that interaction, the following should work:

If you use the .deploy() method on a constructed contract through web3, it should return the address upon receipt and the instance itself upon confirmation.

myContract.deploy({
  data: '0x12345...',
  arguments: [123, 'My String']
})
.send({
  from: '0x1234567890123456789012345678901234567891', // owner address
  gas: 1500000,
  gasPrice: '30000000000000'
}, function(error, transactionHash){ ... })
.on('error', function(error){ ... })
.on('transactionHash', function(transactionHash){ ... })
.on('receipt', function(receipt){
  console.log(receipt.contractAddress) // contains the new contract address
})
.on('confirmation', function(confirmationNumber, receipt){ ... })
.then(function(newContractInstance){
  console.log(newContractInstance.options.address) // instance with the new contract address
})

Source: https://web3js.readthedocs.io/en/1.0/web3-eth-contract.html#deploy

0

Let's clarify a few conceptual things.

I would like to create a contract for each transaction

Not very likely. Transactions are not contracts. Some transactions deploy contracts because that is their purpose, and other transactions interact with contracts. The closest association I can think of that would possibly be sensible is a contract that records transaction documents of a certain type. That could be one contract that handles all instances of a class.

track events between two parties who deliver an item between them

Here, the language is a little challenging to unpack because "events" has a very specific meaning in Ethereum, as do "transaction" and "contract." I will interpret it like this to reduce confusion:

"track interactions between two parties that participate in the delivery of a product."

Let us unpack that.

Product: Some sort of physical object with a representation in a contract. This is likely best held in a single contract that stores product info and possibly other info. This is probably best treated as rows in (logical) table, or instances of a class, in you prefer. Start here: https://medium.com/robhitchens/solidity-crud-part-1-824ffa69509a or here: Are there well-solved and simple storage patterns for Solidity?

parties that participate in the delivery: This implies there is a business process with steps that flow in a certain way. Absent a better description of the use-case, let's say the two parties have to sign off, and then ownership is transferred, a.k.a. delivery.

This process (whatever it is) is precisely what a contract is for. A contract can hold the product info, including ownership, and enforce a process that strictly restricts how ownership will be transferred.

Contracts can talk to other contracts. So, the transfer process enforced by the products contract can be constrained by a sign off by, say, a delivery service. Consider two "approvers" who get the ball rolling, some custody data to indicate the delivery company that is authoritative for the next step, and a delivery confirmation that concludes the transfer of ownership.

In such a scenario, there is a single products contract that one can consult to discover the status/ownership of any product instance and the history of things that have happened to it.

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.