openethereum / pwasm-tutorial

A step-by-step tutorial on how to write contracts in Wasm for Kovan
GNU General Public License v3.0
229 stars 34 forks source link

Unable to send transaction to wasm dev chain #30

Closed maurelian closed 6 years ago

maurelian commented 6 years ago

Summary

I'm running into issues with the dev chain config given in this tutorial.

  1. Sending a normal txn times out.
  2. Deploying the wasm code gets an error.

Version: Parity/v1.10.7-stable-ba79cad-20180619/x86_64-macos/rustc1.26.1

Steps to repro:

  1. I run parity with parity --chain ./wasm-dev-chain.json --jsonrpc-apis=all from the root dir of this repo.

  2. In step-4, I work through the deploy script in the node repl.

  3. I verify that I'm connected to this dev chain from the node repl:

> web3.eth.getAccounts().then(console.log)
> [ '0x004ec07d2329997267Ec62b4166639513386F32E' ] //matches the address in the config file. 
  1. When I run the last line, web3.eth.personal.unlock..., I get:
    at Object.ErrorResponse (/Users/primary/Projects/pwasm-tutorial/step-4/node_modules/web3-core-helpers/src/errors.js:29:16)
    at /Users/primary/Projects/pwasm-tutorial/step-4/node_modules/web3-core-requestmanager/src/index.js:140:36
    at XMLHttpRequest.request.onreadystatechange (/Users/primary/Projects/pwasm-tutorial/step-4/node_modules/web3-providers-http/src/index.js:77:13)
    at XMLHttpRequestEventTarget.dispatchEvent (/Users/primary/Projects/pwasm-tutorial/step-4/node_modules/xhr2/lib/xhr2.js:64:18)
    at XMLHttpRequest._setReadyState (/Users/primary/Projects/pwasm-tutorial/step-4/node_modules/xhr2/lib/xhr2.js:354:12)
    at XMLHttpRequest._onHttpResponseEnd (/Users/primary/Projects/pwasm-tutorial/step-4/node_modules/xhr2/lib/xhr2.js:509:12)
    at IncomingMessage.<anonymous> (/Users/primary/Projects/pwasm-tutorial/step-4/node_modules/xhr2/lib/xhr2.js:469:24)
    at emitNone (events.js:110:20)
    at IncomingMessage.emit (events.js:207:7)
    at endReadableNT (_stream_readable.js:1045:12)
    at _combinedTickCallback (internal/process/next_tick.js:138:11)
    at process._tickDomainCallback (internal/process/next_tick.js:218:9)
  1. Also, when I try sending a simple transaction from my account to another, the promise never seems to resolve, and remains pending until I kill the parity process, at which point I get:

> (node:4489) UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 2): Error: Invalid JSON RPC response: ""

maurelian commented 6 years ago

It seems to be gas related (again #10) :)

I increased the config file's gas limit to 2540be400 (10000000000), and then on the last line of the deploy script I get:

> Error: The contract code couldn't be stored, please check your gas limit.

So I increase the gas amount in the transaction quite high, but I then have the same issue that the promise just never resolves.

maurelian commented 6 years ago

I think it has something to do with the parity signer. When I opened the UI, I had a bunch of notifications to approve transactions.

Need to dig in further.

lexfrl commented 6 years ago

yes, that's the default behavior: if you send a transaction from some locked account you'll be asked to sign transaction from the UI. To avoid it you need to unlock the account first. There is a snippet from https://github.com/paritytech/pwasm-tutorial#deploy :

// Will create TokenContract with `totalSupply` = 10000000 and print a result
web3.eth.personal.unlockAccount(web3.eth.defaultAccount, "user").then(() => TokenDeployTransaction.estimateGas()).then(gas => TokenDeployTransaction.send({gasLimit: gas, from: web3.eth.defaultAccount})).then(contract => { console.log("Address of new contract: " + contract.options.address); TokenContract = contract; }).catch(err => console.log(err));

We do web3.eth.personal.unlockAccount(web3.eth.defaultAccount, "user") first and only then we send a transaction.

maurelian commented 6 years ago

Sorry, I had deleted that account on my end for some reason. I'm still having strange issues with gas once the account is unlocked.

I'm working with a slightly modified version of your deploy script:

var Web3 = require("web3");
var fs = require("fs");
var web3 = new Web3(new Web3.providers.HttpProvider("http://localhost:8545"));
web3.eth.defaultAccount = "0x004ec07d2329997267ec62b4166639513386f32e";
var abi = JSON.parse(fs.readFileSync("./target/json/TokenContract.json"));
var codeHex = '0x' + fs.readFileSync("./target/pwasm_tutorial_contract.wasm").toString('hex');
var TokenContract = new web3.eth.Contract(abi, { data: codeHex, from: web3.eth.defaultAccount })
var TokenDeployTransaction = TokenContract.deploy({data: codeHex, arguments: [10000000]});

web3.eth.personal.unlockAccount(web3.eth.defaultAccount, "user")
  .then(() => {
    console.log("estimateGas");  
    TokenDeployTransaction.estimateGas()
  }).then(gas => {
    console.log("deploying");
    TokenDeployTransaction.send({gasLimit:9999999999999, from: web3.eth.defaultAccount})
  }).then(contract => {
    console.log(contract)
  }).catch(err => console.log(err));

I've set an arbitratrily high gasLimit, and also increased the gasLimit in /wasm-dev-chain.json.

No matter how high I go, I still get:

(node:92622) UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 1): Error: Returned error: Transaction execution error.
(node:92622) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
(node:92622) UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 2): Error: The contract code couldn't be stored, please check your gas limit.
lexfrl commented 6 years ago

If transaction couldn't be sent, could you please attach the log output? You can enable trace logs using -l parameter e.g.:

RUST_LOG=warn parity --datadir=/tmp/dev2 --jsonrpc-apis all --chain ../pwasm-tutorial/wasm-dev-chain.json  -lsync,own_tx=trace,txqueue=trace,contract=trace,executive=trace,client=trace,external_tx=trace,miner=trace,wasm=trace
maurelian commented 6 years ago

Here's the log, I can't see what the issue is. log.txt

lexfrl commented 6 years ago

I see no problems in the log either. What getTransactionReceipt for 89feaf5ae350a6ce724495385e0de36e6bc6e3d70dc546443edad5076657835f tells?

maurelian commented 6 years ago
{ blockHash: '0xff1dde6e0aa36d4ffb673d55d637e96c4091c78e6612d6692514416b6d7e11d7',
  blockNumber: 5,
  contractAddress: '0xEf6c9341e27C23E205f5Da6c3e80F0b38603b1a8',
  cumulativeGasUsed: 9999999999999,
  gasUsed: 9999999999999,
  logs: [],
  logsBloom: '0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000',
  root: null,
  status: null,
  transactionHash: '0xa81f01f119e682a8e31b7ca855d645faa21329beb73b9e009d7a99bd18a565f6',
  transactionIndex: 0 }
lexfrl commented 6 years ago

Good, we have a contract address. What web3.eth.getCode('0xEf6c9341e27C23E205f5Da6c3e80F0b38603b1a8') returns?

maurelian commented 6 years ago

0x

In the above receipt the gas limit was reached.

maurelian commented 6 years ago

So, it seems to me like something in the deploy function is either:

  1. running an infinite loop
  2. includes an invalid opcode (similar to 0xfe) in the evm.

The build was run with rustc 1.26.0-nightly (2789b067d 2018-03-06)

lexfrl commented 6 years ago

Also that's could be a problem related to the size of Wasm binary (the limit is about 24 kb). What is the size you've got? Could you please try to deploy a Wasm from the step-0? It should be small enough.

maurelian commented 6 years ago

Same result with the binary from step-0 (uses full gas limit).

The step-4 binary is 20K.

lexfrl commented 6 years ago

@maurelian could you attach that .wasm binary?

maurelian commented 6 years ago

Here's the binary from step-4: pwasm_tutorial_contract.wasm.txt

I had to change the file type to attach it.

lexfrl commented 6 years ago

take a look, maybe the problem related to the specific parity-ethereum build: https://github.com/paritytech/pwasm-tutorial/issues/33#issuecomment-406810623

zqzqz commented 6 years ago

Parity version: parity-ethereum master commit 7e6a571cbaa164a7d17824a1a40dc357e8dbcf13 Error: Error: The contract code couldn't be stored, please check your gas limit. pwasm-tutorial step-4 works. pwasm-repo-contract and my costum contract don't work. (I directly use compiled wasm binary in compiled directory) gas: 100000000, gasLimit: 1000000000 which must be enough. log:

2018-07-23 05:28:01  IO Worker #0 INFO own_tx  Transaction mined (hash 0x7c1ce1474f28d5bf915bd90e01ed8ee90df849f93c0d3d08711f9b4ef856becd)
2018-07-23 05:28:01  IO Worker #0 DEBUG txqueue  [0x7c1ce1474f28d5bf915bd90e01ed8ee90df849f93c0d3d08711f9b4ef856becd] Mined.
2018-07-23 05:28:01   INFO import  Imported #37 0xe5c9…a917 (1 txs, 100.00 Mgas, 17 ms, 26.58 KiB)
2018-07-23 05:28:01   TRACE miner  update_sealing: imported internally sealed block
2018-07-23 05:28:01  IO Worker #0 DEBUG txqueue  Removed 1 stalled transactions. Pool: 0/8192 (0 senders; 0/4096 kB) [minGasPrice: 0 Mwei, maxGas: 398941699972198896]

web3.eth.getTransactionReceipt returns an address. web3.eth.getCode returns “0x” wasm binary of my costum contract: costum.wasm.txt Still no idea what happens.

lexfrl commented 6 years ago

@zqzqz could you please share a signature of the method you're calling in your contract? There could be a chance that it's a problem with ABI decoding.

lexfrl commented 6 years ago

@zqzqz @maurelian the issue is still actual?

zqzqz commented 6 years ago

No problem now. It seems my build options were wrong. Thank you.

maurelian commented 6 years ago

@fckt which version of parity should I be testing in?

lexfrl commented 6 years ago

hey @maurelian! I’ve tested today on the latest stable. It should work on the master too (I was using the final code from step-5)

lexfrl commented 6 years ago

going to close it for now

maurelian commented 6 years ago

I just haven't been able to find time to test, but I'm sure it's fine. Thanks for the help on this @fckt