Consensys / UniversalToken

Implementation of Universal Token for Assets and Payments
Apache License 2.0
347 stars 189 forks source link

Deploy on a private network with gasPrice set to 0 ? #130

Closed soragXYZ closed 2 years ago

soragXYZ commented 2 years ago

Hi!

I'm trying to deploy all the contracts from your repo on a private network (IBFT2), where the gas price is set to 0, but I'm unable to deploy the ERC1400

At first, I needed to change the 2_erc1820_registry.js because the rawTx in the file was built presuming that the gas price is NOT 0 ( pasted the rawTx in here to decode: https://www.ethereumdecoder.com/)

So I built my own custom rawTx with these parameters:

const deployerAddress = '0xF90aCf91BdAB539aAC3093E5C5b207b562354401';

module.exports = async function (deployer, network, accounts) {
  if (network == "test") return; // test maintains own contracts

  // await web3.eth.sendTransaction({
  //   from: accounts[0], to: deployerAddress, value: web3.utils.toWei('0.1'),
  // });

  var rawTx;
  await web3.eth.signTransaction(
    {
      from: "0xF90aCf91BdAB539aAC3093E5C5b207b562354401",
      gas: 0,
      gasLimit: "0x0c3500",
    }
  ).then((result) => {
    console.log("Signed Transaction result: \n");
    console.log(result);
    rawTx = result.raw;
  });

  await web3.eth.sendSignedTransaction(rawTx).then((res) => {
    console.log("Res send signed: \n");
    console.log(res);
    console.log('\n   > ERC1820 deployment: Success -->', res.contractAddress);
  }).catch((err) => {
    // eslint-disable-next-line no-useless-escape
    if (err.message.search(/the tx doesn\'t have the correct nonce|Nonce too low/g) >= 0) {
      console.log('\n   > ERC1820 deployment: Invalid nonce, probably already deployed');
    } else {
      console.log('\n   > ERC1820 deployment: Unknown error', err);
    }
  });

};

With this code I'm able to deploy the ERC1820 on ganache and my private network where the gasPrice is set to 0

However, I have an issue deploying the next contract, ie ERC1400 On ganache, the error is Method eth_signTransaction not supported And on my private network, the error is different: "ERC1400" hit an invalid opcode while deploying

My custom ERC1820 doesn't seem to be the problem because I have no issue deploying the custom ERC1820 and the other contracts to rinkeby or kovan (which by the way shouldn't be working since the gasPrice is NOT 0)

I'm deploying with truffle

Do you have any idea how I can solve this issue ?

Thanks

gauthierpetetin commented 2 years ago

Hi @soragXYZ , The ERC1820 deployment transaction shall not be modified otherwise, its address won't be "0x1820a4B7618BdE71Dce8cdc73aAB6C95905faD24" anymore. As "0x1820a4B7618BdE71Dce8cdc73aAB6C95905faD24" is hardcoded, it shall not be different. The only way we've managed to deploy ERC1820 on private networks with gas price set to 0, is to include erc1820 directly in the genesis block.

gauthierpetetin commented 2 years ago

The problem with your custom ERC1820 is that the ERC1400 inherits ERC1820Client which still expects ERC1820 address to be "0x1820a4B7618BdE71Dce8cdc73aAB6C95905faD24". Consequently, deployment of your ERC1400 will fail in the constructor when calling ERC1820Client.

soragXYZ commented 2 years ago

Hi @ecp4224 and @gauthierpetetin

I included the ERC1820 directly in the genesis block, but I'm still unable to deploy the ERC1400 on my private network using Truffle, either with Besu or Qorum (but is does work on Ganache)

I still have the same error On quorum: ERC1400 hit an invalid opcode while deploying On besu: ERC1400 Internal error

My private network was deployed using this repo https://github.com/ConsenSys/quorum-kubernetes

Do you have an another idea ?

ecp4224 commented 2 years ago

This may be related to #123 specifically the chainId opcode being used by DomainAware

Will need to confirm if Besu or Qorum support this opcode

soragXYZ commented 2 years ago

Hi!

DomainAware was indeed the issue here

I can deploy the 3_ERC1400_token.js by removing the is DomainAware in ERC1400.sol

It is working fine with Besu and quorum, but the deployment fails in step 5 (5_ERC1400_holdable.js)

soragXYZ commented 2 years ago

Hi @ecp4224 !

Any updates on why DomainAware is causing issues on Besu/Quorum ?

soragXYZ commented 2 years ago

I found my issue, the opcode was indeed not supported with my version of besu

Upgrading to Berlin did the trick! Thanks

errorfourten commented 2 years ago

@gauthierpetetin Hi, are you able to share how you managed to pre-deploy the ERC1820 contract in the genesis block?

I have included both the deployer account and contract code in the genesis block of my private Besu network

"a990077c3205cbDf861e17Fa532eeB069cE9fF96": { "comment": "Account that deploys ERC1820", "balance": "80000000000000000" }, "0x1820a4B7618BdE71Dce8cdc73aAB6C95905faD24": { "comment": "ERC1820 pre-deployed", "balance": "0", "code": "0x60806...6c0029" }

I was able to deploy ERC1400 with no problem, however when it came to calling issueByPartition, it just returned an empty error. It seems like the problem arises in _callTokenExtension > interfaceAddr > ERC1820REGISTRY.getInterfaceImplementer, but I am not sure why. I assume it is due to ERC1820 not being deployed correctly.

I was able to deploy it normally (by sending in the signed transaction) so it should be a problem with the pre-deployment in genesis.

Thanks!

MajdT51 commented 2 years ago

@gauthierpetetin Hi, are you able to share how you managed to pre-deploy the ERC1820 contract in the genesis block?

I have included both the deployer account and contract code in the genesis block of my private Besu network

"a990077c3205cbDf861e17Fa532eeB069cE9fF96": { "comment": "Account that deploys ERC1820", "balance": "80000000000000000" }, "0x1820a4B7618BdE71Dce8cdc73aAB6C95905faD24": { "comment": "ERC1820 pre-deployed", "balance": "0", "code": "0x60806...6c0029" }

I was able to deploy ERC1400 with no problem, however when it came to calling issueByPartition, it just returned an empty error. It seems like the problem arises in _callTokenExtension > interfaceAddr > ERC1820REGISTRY.getInterfaceImplementer, but I am not sure why. I assume it is due to ERC1820 not being deployed correctly.

I was able to deploy it normally (by sending in the signed transaction) so it should be a problem with the pre-deployment in genesis.

Thanks!

Hi, Did you find out why the Get calls are not working correctly? I have the same problem.

And how were you able to send the signed transactions, without changing the gas?

thanks :D

hiromaily commented 2 years ago

I'm using GoQuorum and faced same issue. But I found workaround from ERC1820-QUORUM. This repository works on zero gasPrice.