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

refactor erc721 to use composition instead of inheritance for zos #89

Closed
wants to merge 3 commits into from

Conversation

rdinicut
Copy link
Contributor

@rdinicut rdinicut commented Feb 5, 2019

No description provided.

Copy link
Member

@xmxanuel xmxanuel left a comment

Choose a reason for hiding this comment

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

Is there a way to remove the PaymentObligation wrapper contract?

If we change to composition we can not guarantee the consistency of the stored data
and events inside the payment obligation contract.

I could call the UserMintableERC721 directly without using the PaymentObligation.

* @param _proofs bytes32[][] Documents proofs that are needed
* for proof verification as outlined in precise-proofs library.
*/
function mintAnchor(
Copy link
Member

Choose a reason for hiding this comment

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

If we want to use the PaymentObligation, we need an additional
msg.sender == paymentObligationContract check in the mint method

Copy link
Member

Choose a reason for hiding this comment

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

@manuelpolzhofer what exactly do you mean here?

Copy link
Member

@xmxanuel xmxanuel Feb 5, 2019

Choose a reason for hiding this comment

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

If I understood it correctly, we would have two contracts.

PaymentObligation and ERC721.

The paymentObligation contract calls the mint method on the erc721 contract.
Inside the paymentObligation we are logging the revealed fields and creating events.

We need to prevent that somebody calls the erc721 directly and mint an NFT.
Only the paymentObligation should be allowed to call the mint method on the erc721.

Copy link
Member

Choose a reason for hiding this comment

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

@rdinicut what do you think?

Copy link
Contributor Author

@rdinicut rdinicut Feb 5, 2019

Choose a reason for hiding this comment

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

We do not need an additional check because ERC721 and PO because that will be a ciclic dependancy. So a ERC721 deploy is not used for all NFT types just for POs in this case. you first deploy the ERC721 where you configure what AnchorRepo and define the name and token name. This contract contains centrifuge specific logic. Then you deploy the PO that has a configured ERC721. Composition is used because we want to update them independently(ex: we add new business logic in the mint method of the PO we do not need to push an update to ERC721)

Copy link
Member

Choose a reason for hiding this comment

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

@lucasvo I just discussed it with @rdinicut.
If we use composition the PAY would need to implement all the ERC-721 interface methods to be ERC-721 compatible.
We would have some wrapper which would check if the NFT was minted with the PAY.mint method. The PAY.mint would store additional data, which tokenID's have been minted by PAY.mint -> UM.mint flow.
Every ERC-721 method in PAY would check if the tokenID exists in PAY before calling the UM implemenation.

An alternative could be to use the fallback function in PAY to forward the interface method calls to UM.

Copy link
Member

Choose a reason for hiding this comment

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

Let's discuss it f2f with @pstehlik and @rdinicut later

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@lucasvo At the moment you can not call Pay.ownerOf because it does not exist. You could implement a fallback method but we need to be mindful of methods that should not fallback and be implemented in the PAY contract. ownerOf, like mint and getTokenDetails is one of those methods.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

So I think we will have an Interface and Class that PO would extend and I would also rename UserMIntableERC721 to CentrifugeERC721 but I do not think it's the scope of this PR

Copy link
Member

Choose a reason for hiding this comment

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

@rdinicut but that's extremely confusing, that the contract doesn't actually even implement erc721 but you have this other contract that does. I don't think that's worth saving one transaction.

@rdinicut rdinicut closed this Feb 25, 2019
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

4 participants