Native vs. virtualized smart contracts

Started by santaclause102, September 12, 2015, 05:16:59 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Print
Go Down Pages1
User actions

jsidhu

#9
September 22, 2015, 08:52:58 PM
I like the VCPU approach over eth's EVM approach
Hired by blockchain | Developer
delegate: dev.sidhujag

toast

#8
September 22, 2015, 03:54:26 PM
VMs in general can be nearly as fast as bare metal. The EVM specifically cannot.
Do not use this post as information for making any important decisions. The only agreements I ever make are informal and non-binding. Take the same precautions as when dealing with a compromised account, scammer, sockpuppet, etc.

santaclause102

#7
September 22, 2015, 09:53:21 AM
Quote from: toast on September 21, 2015, 06:37:56 PM
Quote from: delulo on September 13, 2015, 10:33:50 AM
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

QuoteEthereum cannot go this fast, but bitshares cannot change its behavior as easily.
What is meant by "fast"?

QuoteSo 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.

toast

#6
September 21, 2015, 06:37:56 PM
Quote from: delulo on September 13, 2015, 10:33:50 AM
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
Do not use this post as information for making any important decisions. The only agreements I ever make are informal and non-binding. Take the same precautions as when dealing with a compromised account, scammer, sockpuppet, etc.

santaclause102

#5
September 13, 2015, 10:33:50 AM Last Edit: September 13, 2015, 11:01:46 AM by delulo
Quotebecause 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?

Quotewhile 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?

toast

#4
September 13, 2015, 02:21:07 AM
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
Do not use this post as information for making any important decisions. The only agreements I ever make are informal and non-binding. Take the same precautions as when dealing with a compromised account, scammer, sockpuppet, etc.

santaclause102

#3
September 12, 2015, 05:39:27 PM
Quote from: tonyk on September 12, 2015, 05:28:55 PM
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.

tonyk

#2
September 12, 2015, 05:28:55 PM
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.
Lack of arbitrage is the problem, isn't it. And this 'should' solves it.

santaclause102

#1
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.
Print
Go Up Pages1
User actions