0

I'm trying to create a smart contract to buy and sell documents. The truffle has the following token example.

pragma solidity ^0.4.4;

import 'zeppelin-solidity/contracts/token/StandardToken.sol';

contract TutorialToken is StandardToken {
    string public name = 'TutorialToken';
    string public symbol = 'TT';
    uint public decimals = 2;
    uint public INITIAL_SUPPLY = 12000;

    function TutorialToken() {
        totalSupply = INITIAL_SUPPLY;
        balances[msg.sender] = INITIAL_SUPPLY;
    }
}

Is it ok to add the following code to the same contract? Or is there a better way to do it? Is there a complete example? It sounds like a typical example.

contract TutorialToken is StandardToken {
    string public name = 'TutorialToken';
    string public symbol = 'TT';
    uint public decimals = 2;
    uint public INITIAL_SUPPLY = 12000;

    function TutorialToken() {
        totalSupply = INITIAL_SUPPLY;
        balances[msg.sender] = INITIAL_SUPPLY;
    }

    // Doc struct (maybe mapping (address => Doc))
    struct Doc {
        address seller;
        int docId;
        int priceByToken;
    }
    Doc[] Docs;

    function listDoc(int docId, int priceByToken) {
        // Insert into Docs (using sender's address)
    }

    mapping (address => Doc) Transactions;

    function buy(address buyer, address seller, int docId) {
        // Send token from buyer to seller and update Transactions
        transfer(seller, ..., buyer);
    }
}
1

I'd separate it into 2 different contracts.

One would be the token, which will be used in your application as currency to buy / sell these documents.

The other one would handle the documents logic. There, you would build the logic to enable accounts to buy and sell access to these documents and instead of exchanging ethere, the functions would need to be prepared to read balances from the token contract you previously created.

| improve this answer | |
0

Your question is extremely open-ended. But one thing I can tell you is that your buy function is asking for trouble. If you read the Solidity docs you'll see that the recommend pattern for functions like this is the following:

  1. Conditions: i.e. some require statements to validate that a document is currently for sale
  2. Effects: record all the effects before actually making a transfer to avoid problems with reentrancy. In case the transaction fails they'll be rolled back.
  3. Interaction: Making the actual transfer.

While it may not present a problem in your concrete example (hard to tell from the bit of code you posted), I think it'd be better to err on the side of caution and internalizing best practice patterns.

| improve this answer | |

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.