feature/deprecate dynamic gas price; review gas concept/mechanism

[rgeraldes]

txpool:

• transactions: first come, first served instead of price first - fixed compute unit price.
• it's no longer possible to replace transactions. (Ethereum - network congestion)

miner:

• every transaction is processed by the miner instead of rejecting based on a minimum price - faster propagation.

user:

• the user no longer has to fill in any gas related values for simple transactions (kUSD transfers).
• the user still needs to fill in a compute limit (computational effort estimation - backend.EstimateComputationalEffort) for contract calls.

smart contracts:

• renamed EVM to just VM
• removed opDifficulty; gasprice and gas will not work too because we've replaced the terms with new names.

all:

• modified gas terminology according to John's input.

Closes #24

[JekaMas]

Is a fixed price safe from dos attack, when melicious user spams a network with huge number of transactions?
Maybe we need to do some research about it and other possible security issues.

@rgeraldes @yourheropaul

[rgeraldes]

@JekaMas it's the same model. If the user posts a transaction he pays for it - we just need to make sure that the network can handle the load and maybe make sure that the fee is not extremely low. Worst case scenario, the node's tx pool will not accept more transactions until there's some room for new transactions.

[JekaMas]

@rgeraldes ethereum model prevents dos attack by increasing gas price: the more someone spam the network the more the price of each transaction and whole attack, so we can be sure that at some point the price will be so high that it'd be impossible to continue the attack.

If the price is constant, someone can spam the network paying suitable price, afaik.

I'm only thinking that we should calculate does our gas model have same or even better gaurantees as Ethereum gas model.

[rgeraldes]

"price will be so high that it'd be impossible to continue the attack" - depletes your account balance faster but the attack can continue. Most of Ethereum's problems arise from the fact that they have a slow network > network congestion - it's a totally different scenario for us but some of the problems remain:

For simple kUSD transfers the cost of launching an attack is expensive (15 minutes ~ $10000 given 1000 tx/s) and even if there's an attack you cannot prioritise transactions, which means that the other users' transactions are still going to be accepted anyway as there's a limit of transactions per account on the tx pool (https://github.com/ethereum/go-ethereum/blob/master/core/tx_pool.go#L134). With sharding the price to attack will be much higher simply because you will have a higher tx throughput (think current payment networks).

For contracts it's a different scenario - this part of the code is still a mistery because we are dealing with 1 second confirmations and we're also enforcing a minimum hardware setup (higher gas limit which we don't know yet). With that said, the contracts part is still raw in relation to our use cases but there are several ways of preventing ddos attacks. (caches, higher fees, etc..)

Overall the goal is to make it easier for everyone to use crypto currencies (think bank transfer).

[rgeraldes]

Post: add an issue - fixed compute unit price per currency

[jmatosp]

@rgeraldes you need to rebase this PR