Using ZeppelinOs/ZepKit/Truffle to Deploy/Verify Non-Upgradeable Contracts

General
1

Greetings @spalladino and/or @frangio,

Could I use ZeppelinOs/ZepKit/Truffle to Deploy/Verify Non-Upgradeable Contracts? If so, what should be the order/commands/options to use? I have been using the following :point_down:

zos init TheFaustFlick
zos add -all
zos push --network kovan --reset --force

and I get :point_down:

push
push643Ă—963 34.6 KB

Before I could even try
zos verify --network kovan TFF_Token :point_down:
new%20verify

Are those the commands/options that I should use?

PS: I have been able to perform

truffle compile --all
truffle migrate --network network_name --reset

without a problem, but I am unable to verify at https://kovan.etherscan.io/verifyContract2 since I have been informed on this forum that Etherscan won’t be able to resolve the imports, but I could do so with ZeppelinOS’s verify command.

2

Hello @jaureguino! Please don’t tag the team members directly, let me see your problem first before you tag them to make sure we don’t distract them for something simple.

I see you’re using openzeppelin-solidity. I think you should be importing from openzeppelin-eth since those are the contracts that are adapted for ZeppelinOS (initializers and all, as your error message details)

That should solve your problems.

1 Like
3

Dear @IvanTheGreatDev,

I cannot use openzeppelin-eth because they use the initialize functions and as I mentioned on the Topic Subject, this is a non-upgradeable contract, therefore, I must use a constructor; the initialize functions gave me a lot of issues, but non with :point_down:

truffle compile --all
truffle migrate --network network_name --reset

Could zos verify be improved to work with https://kovan.etherscan.io/verifyContract2 ?
verify%20error

I look forward to reading from you guys on this matter,

g.a.

4

I see now, my apologies. I believe zos relies on initializers to function properly. As for deploying contracts that are non-upgradable you can use the standard truffle functions for that. Once spalladino can take a look he should be able to confirm this.

5

I have been working over the last four days on this direction since I have been told on this forum twofold:

  1. It is ok to use ZeppelinOs/Zepkit/Truffle to deply/verify Non-Upgradeable contracts
  2. The ZeppelinOS’s verify command should be able to overcome the limitation of https://kovan.etherscan.io/verifyContract2

Since I could not get zos verify to work, I “figured” that the verifiable contract needs to be in a logical order for it to work against https://kovan.etherscan.io/verifyContract2 , so I re-organized the “flattened” file created by truffle-flattener, in the opposite order in which it was compiled :point_down:
order
excluding of course the Migrations.sol contract.

Then loaded the file at https://kovan.etherscan.io/verifyContract2 against the TFF_Token contract address and it almost worked, since it threw back the following error/exception :point_down:

exception
exception.PNG823Ă—499 37.2 KB

So, there is an issue with the inheritance tree here :point_down:
tee
which was published :point_right: https://github.com/OpenZeppelin/openzeppelin-solidity#install

Since I virtually followed it, with the exception that I replaced ERC721Mintable.sol with ERC721MetadataMintable.sol as follows :point_down:

pragma solidity ^0.5.0;

import 'openzeppelin-solidity/contracts/token/ERC721/ERC721Full.sol';
import 'openzeppelin-solidity/contracts/token/ERC721/ERC721MetadataMintable.sol';
import 'openzeppelin-solidity/contracts/ownership/Ownable.sol';

/**
 * @title TFF_Token http://estudios-amazonia.com/TheFaustFlick_WP.pdf
 * @dev ERC721 metadata minting logic leveraging openzeppelin-solidity v2.1.2
 * @dev ERC721 facilitates preventing: a) double-voting per token and
 * b) disabling trading during voting periods.
 */

contract TFF_Token is ERC721Full, ERC721MetadataMintable, Ownable {
  string private Name = "#TheFaustFlick";
  string private Symbol = "TFF";
  address private Owner;
  string private TokenURI;
  uint256 private Stage;
  uint256 private TokenId;
  uint256[4] private TokensToMint;

**ETC ETC ETC**

I look forward to Zeppelin´s help!

Cheers,

g.a.

1 Like
6

Hello jaureguino!

So for 1. I think in general it’s fine to mix them together for upgradable and non upgradable contracts, but for deploying them you might as well use truffle no?
2. that command by default verifies on etherchain, but you’re looking to verify on etherscan, maybe you can try to pass in your API as described here, let me know if that works.

For the manual verification problem, do you think you can show me the flattened contract you submitted? (if the above verify command doesn’t work)

7

Dear @IvanTheGreatDev,

Would you please move pass the two points which I actually did myself? since

#1 I am indeed using truffle, since it was pointed out with the following messages.
#2 I have already read that link; and if you read the previous message, zos verify it only works with etherchain on mainnet ; I actually had made a kind request for ZeppelinOS to make an improvement on zos verify ; but since I needed to move on with the project, I proceeded as explained further in detail.

AND could you please thoroughly review everything else that followed?

I truly value all your efforts to promptly respond, specially after hours. Please let me know where can I send you the flattened file to since it is fairly large?

I believe that it is for the best interest of Zeppelin to review the issue I have identified with the hierarchical tree. Perhaps @spalladino can pitch in.

Cheers!

g.a.

8

Hello jaureguino,

I referenced the docs because the command that encountered the error was told to verify on the etherchain mainnet, rather than etherscan testnet.

Anyways, feel free to place the flattened file in a GitHub gist, pastebin.com or some other similar site and post the link here.

I feel as if the issue arrives because ERC721Full already imports ERC721Metadata, which is imported again through ERC721MetadataMintable. However the flattener may get around this so I would like to see that :slight_smile:

Spalladino and the team will reply when they’re online, at the current moment they’re hosting a meetup in New York.

9

Dear @IvanTheGreatDev,

The zos verify command that encountered the error was not told to deploy on the etherchain mainnet. Please take a look at it again. :point_down:
verify%20error

I have placed: #1truffle-config.js (for you to review/double-check how kovan was configured) and #2 the a) truffle flattened and b) manually ordered FTFF_Token.sol files here :point_right: https://github.com/estudios-amazonia/TheFaustFlick

I got the same feeling about the double import; a fresh mind like yours could probably nail the issue.

Cool, I read about the NYC meetup…

1 Like
10

Thank you jaureguino,

My bad, I meant etherchain kovan, while you’re trying to manually verify on etherscan kovan, which needs an API key to do through zos.

Looking through the file, I’m not sure what’s going on here, can you try changing ERC721Full to ERC721Enumerable and see if that solves your problem?

Let me know!

11

@IvanTheGreatDev,

Would you please escalate the following question :point_down:

Is contract IERC721Metadata is IERC721 { necessary ?

or can it just be contract IERC721Metadata { ?

If so, it needs to be fixed at [openzeppelin-solidity] level…