Gas price issue in Quorum

[rohitgkr]

I have created a few accounts in Quorum which are dedicated solely for the purpose of offline transaction sign & raw transaction submission. While the contract is deployed via Truffle these accounts will be the from address in the sendTransaction. So I had to seed them with ether as below. Option 1 (see comment) doesn't work whereas Option 2 works. Option1 throws exception "Gas Price not 0" in the line where the encoded transaction is sent as raw transaction. EstimateGasAsync returns a gas value of 21000 which is non zero when submitted as transaction. So I don't understand why #2 works and #1 fails. Also, is there a way to turn off gas concept in Quorum? Will it work if I rebase the genesis file and restart all nodes using the new file?

var inp = new Nethereum.RPC.Eth.DTOs.CallInput { From = coinbaseAddress, To = toAddress, Value = new Nethereum.Hex.HexTypes.HexBigInteger(amountInWei) };
var gas = await web3.TransactionManager.EstimateGasAsync(inp); // OPTION 1
gas = await web3.Eth.GasPrice.SendRequestAsync(); // OPTION 2

		var encodedSignature = web3.OfflineTransactionSigner.SignTransaction(coinbasePvtKeyUnEncrypted, toAddress, amountInWei, nonce, gas, 300000);
		Assert.IsTrue(web3.OfflineTransactionSigner.VerifyTransaction(encodedSignature));
		var txId = await web3.Eth.Transactions.SendRawTransaction.SendRequestAsync(encodedSignature);
		var receipt = await web3.Eth.Transactions.GetTransactionReceipt.SendRequestAsync(txId);

[cicorias]

While quorum requires the sender to have an ETH balance, no ETH is ever deducted for including a TX in a block.

[juanfranblanco]

@rohitgkr Whilst not related directly to Quorum, maybe this will help you creating the accounts and seed them with some Ether. https://github.com/Nethereum/MultipleAccountTransferSample/blob/master/Program.cs

[juanfranblanco]

Oh and what @cicorias says

[rohitgkr]

Interesting point #cicorias. You are right. The gas price parameter must be set to zero. However I see that EstimateGas() returns 21000. Also GasUsed from receipt once the transaction gets mined also returns 21000. So both are non zero which contradicts the gas price zero concept.
Gas used : 21000
Cumulative Gas used : 207317

Also I used Web3 and Web3Quorum classes. Both produce the above result.
Gas Limit parameter of zero doesn't work either. Can you please suggest how to deal with gas limit in Quorum, when gas price is always set to zero?

[juanfranblanco]

@rohitgkr check this issue Consensys/quorum#38
it provides the design decision.

"The use of gas (with gasPrice = 0) is the intended design. We want to prevent infinite loops in the EVM and want DApp developers to be aware of the computation costs associated with their designs, but we don't see cost/benefit justification for reducing balances in a permissioned/consortium network. One future change we've discussed is to automatically pre-fund newly created accounts with an amount of Ether to make things easier since an account with a zero balance cannot send transactions (even though gasPrice = 0). In the mean time you can just do a value transfer from a funded account to new accounts that need to be created."

Hence the pointer to a way to create accounts and give them some Ether.

[rohitgkr]

Thanks. Yes they are enforcing gas price 0
The default gas limit in 7nodes is quite high - 0x2FEFD800 so I believe 804247552 transactions will try to be squeezed into each block. Maybe I will check in the Quorum forum but I am interested in the optimum value for gas limit. I see this as equivalent to a database page fragmentation parameter. Although this being a logical parameter, it is independent of the byte size of each transaction row that gets written in the block.

I have written an extension method to TransactionSigner where I query the latest block and getting it's gas limit. Does anyone see a potential problem with this approach? The assumption is that this is the block gas limit as per the API below -
SignTransaction(string key, string to, BigInteger amount, BigInteger nonce, BigInteger gasPrice, BigInteger gasLimit)

Alternatively if this is the transaction gas, I could call TransactionManager.EstimateGasAsync to set it as transaction gas. I notice that CallInput sets transaction gas to a default of 90000. So it appears that the SignTransaction is using gasLimit as transaction gas instead of the block gas limit?? So I believe I should rather call EstimateGas?

[juanfranblanco]

@rohitgkr Great points,, gas limit and estimates, it all varies on what your contract is doing, and of course storage etc. In a consortium, you have far much control if you a limited set of contracts, together with optimisation of block size. etc.

There is a block size gas limit, and also a gas limit per transaction, estimate gas attempts to calculate the gas usage of the transaction but it is yet to be optimised in geth (as far of my latest tests) so results may vary at the moment. The default value was set to try to force an optimised estimation. ethereum/go-ethereum#1590

[juanfranblanco]

Already a default to 0 https://github.com/Nethereum/Nethereum/blob/master/src/Nethereum.Quorum/Web3Quorum.cs#L27