You are viewing a single comment's thread from:
RE: Why doesn't Bitshares dominate Ethereum?
The value proposition of Ethereum is that anyone can add new smart contract logic without a hard fork blessed by token holders. On one hand I want to criticize bitshares for this abuse of the term "smart contract", but on the other hand the word is so meaningless and diluted to begin with that it doesn't matter.
To follow up: true network effects come from emergent complexity - ethereum enables this on a much richer level because logic updates do not have to go through a centralized processing point.
Hard fork approval voting is as de-centralized as project funding voting in "the DAO" .. or am I missinterpreting the centralized processing point you are talking about?
Anyway, I agree that Ethereum is much much better for prototyping "smart contracts" (what ever that means).
What is left be be proven is that both Ethereum and BitShares can actually scale up for mass adoption with a slight advantage for BitShares as it does not process everyones' smart contract state, and input.
"The DAO" is one app. I can make another app that talks to the DAO, without their permission.
A new
opin bitshares can talk to the whole bitshares database/current state aswell, can it not? A new op could also execute a trade, do a transfer and some other nasty stuff if it was only coded to do so.what's an op in bitshares, and how do I make one?
I think the point is that on Ethereum a new smart contract/DApp can be added to the network without the approval of anyone but the author of the code.
This is not possible on BitShares. And it isn't just a technical difference (AOT-compiled code vs interpreted or JIT-compiled bytecode) but a policy difference. The Graphene toolkit is well-designed for blockchains that choose to not allow arbitrary user-submitted code to be executed on their network. The cost in resources to run any particular logic on their network is explicitly approved by stakeholders for each new piece of logic added to the system rather than generalizing that cost to some sort of "gas" that must be paid per unit of computational resource consumed.
This policy decision comes with trade-offs. On one hand, through explicit approval by stakeholders, the computation costs can be tailored to the specific logic in commercially smart ways. For example, you gain the flexibility to not even charge a fee for certain transactions, e.g. posting comments or voting on Steem. As far as I am aware, that sort of no-fee structure isn't even possible to do with the current Ethereum design (although perhaps it can be approximated if you provide a "deposit" fee in your transaction that is returned to you from the DApp fund pool if your transaction successfully completes without running of gas).
The downside is that requiring explicit approval from a decentralized group of stakeholders to actually realize your code on a live network adds further uncertainty to the success of your business. It definitely tends to weed out any non-serious additions to the code. But by discouraging a lot of small devs from trying to build cool new projects experimenting with high-risk concepts that could turn out to be really big and valuable, that policy might be hurting the platform in the long-run.
Of course, even going beyond the policy difference, technical differences can also account for a lot of the difference in dev involvement in the BitShares and Ethereum communities. C++ is pretty intimidating for the average coder. Making sure your changes don't end up accidentally screwing up other people's code in the BitShares/Steem codebase is also pretty intimidating. It is nice to have a dev environment that sandboxes your code to provide everyone with guarantees that this won't happen, and also allows you to code in a more user-friendly (even if less efficient) language accessible to more developers.
Edit: By the way, I think there might be some potential of adapting the concept of rate-limited free transactions (i.e. your fraction of stake in the system determines your fraction of the dynamic bandwidth available) to the concept of Ethereum gas. In other words, your fraction of the stake in the system determines the fraction of the currently allocated computation resources your transaction is allowed to consume (perhaps with safeguards included in the transaction to not even bother running it, which would avoid consuming from the submitter's daily resource allotment, if the network cannot guarantee some minimum amount of computational resources for computing that transaction). Then you simply inflate the stake like Steem to pay block producers, thus requiring users to continually buy more of the stake to maintain their same resource allotment fraction. This could be a clever way to get around the transaction-fee cognitive burden.
I think so