BitShares Forum
Main => General Discussion => Topic started by: santaclause102 on September 12, 2015, 05:16:59 pm
-
First of all correct me if I am wrong with my termninoloy "virtualized"...
I am asking myself what paramters are affected if you have virtualized vs. native smart smart contracts.
The three parameters I am looking at are: Blocktime, tx/sec (throuput), cost (in terms of tx fees paid in practice).
It would also be interesting to know why each of these paramters is diffent for the two types of systems.
-
If you realize that one is a general purpose computer and the other ASIC you will have all your answers.
In particular that the questions -
Which one consumes more electricity (tr fees)?
Which one is faster (blocktime, tx/sec)?
are somewhat not full. They must be something like:
Which one consumes more electricity (tr fees) per this particular 1Mil instructions?
Which one is faster for this particular kind of transactions?
Hope this helps.
-
If you realize that one is a general purpose computer and the other ASIC you will have all your answers.
In particular that the questions -
Which one consumes more electricity (tr fees)?
Which one is faster (blocktime, tx/sec)?
are somewhat not full. They must be something like:
Which one consumes more electricity (tr fees) per this particular 1Mil instructions?
Which one is faster for this particular kind of transactions?
Hope this helps.
That is an explanation by analogy. I am looking for an explanation by (first) principles.
-
There's no reason "virtualized" (user-submitted scripts?) can't be almost as fast as native contracts. This tradeoff concept exists because ethereum made some design decisions which are good for thin clients but bad for performance (there are sequential crypto operations everywhere, in and out of transaction logic. Every state change requires computing several hashes).
In graphene you see some places where the opposite decision is made. Graphene's databases could be exposed to a fast scripting environment where users could submit code.
So to answer the question, I think blocktime is almost completely independent, while throughput and cost favor native contracts only by as much as compiled code is slightly faster than advanced VM tech like java
-
because ethereum made some design decisions which are good for thin clients [...] In graphene you see some places where the opposite decision is made.
Isn't Graphene entirely built for thin clients?
while throughput and cost favor native contracts only by as much as compiled code is slightly faster than advanced VM tech like java
That sounds like a contract that is written with a scripting language on Bitshares (in case Bitshares had one and could interpret it), which is what I meant by virtualized (is there a more suitable term?), would consume maybe 10% (ballpark figure) more ressources resulting in 10% more cost and 10% less throughput. Doesn't this contradict what you said here https://www.reddit.com/r/ethereum/comments/3jvo9k/bitshares_says_it_will_be_able_to_complete_100000/
If that is the case why then BM's decision to go native? There must be other aspects to it?
And does "virtualized" have other benefits than the externalization of feature/application development and the competition of apps and maybe more flexilibity / individuality with respect to what a contract can do?
-
Doesn't this contradict what you said here https://www.reddit.com/r/ethereum/comments/3jvo9k/bitshares_says_it_will_be_able_to_complete_100000/
I don't see the contradiction, I think I said almost the same thing in both
-
Doesn't this contradict what you said here https://www.reddit.com/r/ethereum/comments/3jvo9k/bitshares_says_it_will_be_able_to_complete_100000/
I don't see the contradiction, I think I said almost the same thing in both
Ethereum cannot go this fast, but bitshares cannot change its behavior as easily.
What is meant by "fast"?
So if the disruptor is open-source, if it becomes an important crypto-component down the line, could an Ethereum dApp mimic this behavior, or no? [...] No, because it would be running inside the ethereum VM instead of on bare metal.
-
VMs in general can be nearly as fast as bare metal. The EVM specifically cannot.
-
I like the VCPU approach over eth's EVM approach