vitalick could you please answer
[1] I don't quite see how the price to execute etherium code will be determined.
there has to be some sort of clever system based on realtime or near realtime demand for, well what ever the limitation is to get things into the next block?
it could be an etheirum fork would set fees lower......
etherium = a bundle of switches, how do you price using a switch? ( iasked the same question of master coin and still don't have an answer....)
[2] I am also wondering if some sort of of chain processing can be done, and results are somehow integrated back into the etherium chain, that can be verified thus reduce bottle necks.....
still no answer to [1]...
Regarding #1, it's something we're currently actively researching and modeling. You can read some of Vitalik's though on the subject at
http://blog.ethereum.org/2014/02/01/on-transaction-fees-market-based-solutions/Ok, so it looks like I hit the nail on the head this is a crucial question, and etherium is a bundle of switches waiting to be arbitraged out by a fork, if fees are too high.
Thinking out loud
Perhaps you need a special attribute of "time" to colour etherium with, So ethreium coins have two core attributes, on of unit of sale like bit coin, that is 1 eth = 1eth, and the current usage of the computational power of ethrium weights in a relative value to each etherium.
that multiplication of the two gives the market rate of etherium.
thus the usage / demand of the network can dynamically colour an attribute of the coin. say the whole processing network is operating at 1000/s Unit, and has a capacity of 10000 units/s then, the number of eth in existence can be weighted by PRactual/PRcapacity *1/Number of eth.
So the code must have some sort of ability to detect execution requests, so that overcapacity can be dealt with, e.g. 1Million / 1000.
this raises the problem of knowing how much a program will request before you execute it......to solve this, the task should be thrown that allows a code to run on vm local cpu of with test net ruthenium, and an execution rate per second, that has its power defined as current ethrium network CPU.
thus your entering into a PID sort of feed forward/Feed back control system, (better brush of those nyquist stably theorems etc). I'm not sure there is any other way around this. The market does exactly the same thing but at a slower pace by simply releasing etherium forks.
A final note maybe that some how to allow all process to be run on an executors own cpu and only results at the interface be verified.Etherium seems to be pose the question of distributed computing needs to be tied together and pooled to solve a single problem in an efficient not cheat able manner.