Very high values when eth.estimateGas requested

[gurdeepakjoshi]

Which Aion version?: 0.3.1.46f09bac
Which operating system?: Linux
Which distributor and version?: Ubuntu 16.04 LTS 64 bit
How installed?: binaries
Are you fully synchronized?: yes
Did you try to restart the node?: yes

Actual Behaviour

• Launch aion node
• cd web3/
• node console.js
• aion-127.0.0.1:8545> eth.estimateGas({data: "0x000"})
  13914991129094744000
  It returns a very high estimate which makes the contract deployment infeasible.

Expected Behaviour
estimateGas should return realistic estimate such as 2000000

FYI
If you run same node locally (private) without syncing with external nodes then this issue doesn't occur. This issue is only occuring on fully synced node.

[qoire]

@AionJayT might be important for us to check that we can reproduce this.

From my side:

I was unable to reproduce this issue with a locally synced node (as suggested by Gurdeep). I also was informed by another colleague that it seemed to have to do with his keystore being placed in the keystore folder vs not. I tried this as well and was not able to reproduce the error.

[qoire]

@gurdeepakjoshi Just to be clear, when you say fully synced, are you referring to mainnet or mastery?

[gurdeepakjoshi]

@gurdeepakjoshi Just to be clear, when you say fully synced, are you referring to mainnet or mastery?

@qoire , I meant mastery.

[erik-iglikov]

I was able to reproduce this issue with importing the keystore and config when I apply to a brand new mainnet kernel(aion-v0.3.1.dcaf9e8-2018-08-30)

[arajasek]

I was able to reproduce this on mastery using both v0.3.0.17d0f332, as well as the latest dev. I did not need to sync to completion in order to reproduce the bug.

I stepped through the code, and it looks like the wonky behaviour is happening inside the VM. @AionJayT is following up with the VM team.

[iamyulong]

Was debugging this issue, found the root cause is that the from address of the transaction being empty. The Address#toBytes() returns empty byte array instead of 32 bytes of zeros. After the serialization of the the ExecutionContext, the encoded bytes are interpreted with incorrect offsets.

Code:

1. Where the transaction parameters, with default values, are constructed
   

   aion/modApiServer/src/org/aion/api/server/types/ArgTxCall.java

   Lines 67 to 71 in 8437618

   	public static ArgTxCall fromJSON(final JSONObject _jsonObj, NrgOracle oracle, long defaultNrgLimit){
   	try {
   	Address from = Address.wrap(ByteUtil.hexStringToBytes(_jsonObj.optString("from", "")));
   	Address to = Address.wrap(ByteUtil.hexStringToBytes(_jsonObj.optString("to", "")));
   	byte[] data = ByteUtil.hexStringToBytes(_jsonObj.optString("data", ""));

2. The AionTransaction constructor is taking from, rather than decoding from signature
   

   aion/modAion/src/org/aion/zero/types/AionTransaction.java

   Lines 95 to 99 in 8437618

   	public AionTransaction(byte[] nonce, Address from, Address to, byte[] value, byte[] data, long nrg, long nrgPrice) {
   	super(nonce, to, value, data, nrg, nrgPrice);
   	this.from = from;
   	parsed = true;
   	}

3. Address is designed to be of variable length, zero or 32
   

   aion/modAionBase/src/org/aion/base/type/Address.java

   Lines 88 to 101 in 8437618

   	public Address(final String in) {
   	if (in == null) {
   	throw new IllegalArgumentException();
   	}
   	byte[] hexByte = ByteUtil.hexStringToBytes(in);
   	if (hexByte.length != ADDRESS_LEN && hexByte.length != 0) {
   	throw new IllegalArgumentException();
   	}
   	setupData(hexByte);
   	}

4. Where addresses are serialized, fixed 32 bytes are being expected.
   

   aion/modVM/src/org/aion/vm/ExecutionContext.java

   Lines 119 to 125 in 8437618

   	public byte[] toBytes() {
   	ByteBuffer buffer = ByteBuffer.allocate(getEncodingLength());
   	buffer.order(ByteOrder.BIG_ENDIAN);
   	buffer.put(address.toBytes());
   	buffer.put(origin.toBytes());
   	buffer.put(sender.toBytes());
   	buffer.put(nrgPrice.getData());

[iamyulong]

Quick fix would be updating the AionTransaciton constructor to not set the from variable.

Sine this issue won't affect consensus, put it at low-to-median priority.

[AionJayT]

some of the contract calls do need to verify the sender, therefore, I think the better solution is putting an address when the call doesn't have the sender address or just return an error in the API layer.

[iamyulong]

I thought the transaction would be signed by a random address. If we don't set the from variable, the getFrom() method will decode the address from the signature. Correct me if I'm wrong.

[AionJayT]

that's correct, the problem is if the contract function call requires the sender's address (let assume modifier), but this API doesn't require the sender's signature for the constant call. Then the getfrom() won't work.

[arajasek]

PR #646 adds the Zero Address if no address is provided, resolves the issue.