Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add ERC827 Token #518

Merged
merged 14 commits into from Jan 17, 2018
Merged

Add ERC827 Token #518

merged 14 commits into from Jan 17, 2018

Conversation

AugustoL
Copy link
Contributor

@AugustoL AugustoL commented Oct 26, 2017

Fix #494

add missing public identifier in approveData in SmartToken contract

remove constact from showMessage function in message helper contract

move Message helper contract to mocks folder

move SmartTokenMock contract to mocks folder
@AugustoL AugustoL changed the title Add SmartToken contract with tests and documentation Add ERC827 Token Jan 11, 2018
Copy link
Contributor

@spalladino spalladino left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awesome work. I left a few comments, the most important one on whether we want to support _data versions of increase and decrease approval.

Also: should we have an interface version of the contract, as we are doing with ERC20?


@return true if the call function was executed successfully
*/
function approve(address _spender, uint256 _value, bytes _data) public returns (bool) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given that we have increase and decrease approval methods in ERC20, should we add the same to ERC827?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

increase and decrease approval mitigate the race condition in the approve method right?
I think it makes sense to add it if it solves a problem in the standard, but if we add it we should add it with the _data parameter too. To follow the same idea for the rest of the functions, that you can call it with or without _data.
Lets propose it in the ERC827 standard for now and bring the discussion there.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure if we should add it as part of the standard. Today, the increase and decrease approval (which help mitigate the approve race condition, as you say) are present in our ERC20 implementation, but are not part of the interface or standard.

I'd just add the _data versions of them for completeness here, and keep that out of the standard for the time being.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great, I agree, lets do that, Im going to add them

// Use method #3 approve of the abi to encode the data tx
const approveData = ethjsABI.encodeMethod(token.abi[3],
[message.contract.address, 100, extraData]
);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I understand that the encoding must be done manually due to truffle's limitations for function overloading. That being said, I'd rather find the desired function from the ABI array rather than relying on the ordering, as it is quite brittle; if we add another function later, these tests may break (or worse, may inadvertently test other functions)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You are right! im going to change it :)

return true;
}

}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can't believe how simple the code for this contract ended up. Congrats for the awesome work. 👏

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks to community and maintainers 🎉

@AugustoL
Copy link
Contributor Author

@spalladino how do you think we should have the interface?
What about if we rename the actual contract to ERC827Token.sol and in the ERC827.sol we have:

pragma solidity ^0.4.18;


import './ERC20.sol';
/**
 * @title ERC827 interface
 * @dev see https://github.com/ethereum/EIPs/issues/827
 */
contract ERC827 is ERC20 {
  function allowance(address owner, address spender, bytes _data) public view returns (uint256);
  function transferFrom(address from, address to, uint256 value, bytes _data) public returns (bool);
  function approve(address spender, uint256 value, bytes _data) public returns (bool);
}

@spalladino
Copy link
Contributor

spalladino commented Jan 12, 2018

What about if we rename the actual contract to ERC827Token.sol and in the ERC827.sol we have:

Sounds good! @frangio WDYT?

function increaseApproval(address _spender, uint _addedValue, bytes _data) public returns (bool) {
require(_spender != address(this));

super.approve(_spender, _addedValue);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should be super.increaseApproval, not approve

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm a bit worried that the tests did not catch this one. Maybe make sure that the increase approval test works on a spender that already has a certain approval set?

function increaseApproval(address _spender, uint _addedValue, bytes _data) public returns (bool) {
require(_spender != address(this));

super.approve(_spender, _addedValue);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems I made a comment on this line on a previous commit and github is now showing it as on an outdated diff. Copying it here just in case it goes missing:

Should be super.increaseApproval, not approve
I'm a bit worried that the tests did not catch this one. Maybe make sure that the increase approval test works on a spender that already has a certain approval set?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

my bad! Yes, it is weird that the tests are still passing, im going to add a check before increase/decrease approval with data are executed.

spalladino
spalladino previously approved these changes Jan 16, 2018
@spalladino
Copy link
Contributor

LGTM! @facuspagnuolo what have we agreed about naming of interfaces vs impls? Is ERC827 for the interface and ERC827Token for the impl ok?

@facuspagnuolo
Copy link
Contributor

@spalladino yes! I followed that same approach

@AugustoL AugustoL merged commit b0522b9 into OpenZeppelin:master Jan 17, 2018
@AugustoL AugustoL deleted the add-smart-token branch January 17, 2018 14:59
ProphetDaniel pushed a commit to classicdelta/Smart-Contracts that referenced this pull request Mar 9, 2018
@vittominacori
Copy link
Contributor

vittominacori commented Apr 9, 2018

Hi all, if I try to use the increaseApproval methods (the one without _data) I receive the following error.

Error: Invalid number of arguments to Solidity function.

Any Idea?
Why the ERC20 increaseApproval method in ERC827 tests (here the commit) has been changed respect to the same test on ERC20?

Update: it seems that web3 (0.20.6) is not able to return right method if overloaded with different params number.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants