Jump to content
Sign in to follow this  
RafOlP

Who Will Pay for Turing-Complete Smart Contracts?

Recommended Posts

http://www.coindesk.com/turing-complete-smart-contracts/

Quote

Another finicky proposition in Turing-complete smart contracts is that of the "oracle".

In a smart contract, data needs to enter the blockchain from an outside source in order to be of use. The source of this information – whether it be the price of a commodity, or the outcome of a sporting event, needs to be broadcast by individuals.

These individuals are called "oracles".

In non-Turing complete smart contract platforms, these oracles are to be found in "multisig" contracts, where one of the parties is the oracle, and the other two parties are the contract participants. In a "two-of-three" multisig operation, for instance, the oracle merely enters a winner onto the blockchain without additional code attached.

In a Turing-complete model, the parties themselves broadcast the code onto the blockchain well in advance, and let the nodes on the blockchain determine the outcome at the time an oracle broadcasts the event outcome 'data'.

So what's the difference? Well, in a Turing-complete model, a secondary contract can be broadcast alongside the primary contract for the sole purpose of 'corrupting' the oracle. This means that participants in the Turing-complete contract can not only engage in a contract, but can also bribe the oracle with impunity, and without repercussion.

(...)

However, as the hype cycle begins in this new phase of blockchain, it's important to remember that as we look back, the question of "Who needs Turing complete smart contracts?" may very well turn out to be "No one".

There are Interesting points in the article and cost/benefit analysis will be key to the success of any distributed solution. Detailed comparisons with centralized equivalents should be a requirement for any idea or venture in the distributed ledger field.

Today, the cost to transact in blockchain-based ledgers is not perceived because these systems receive a constant inflow of money (caused by the growth in the demand for native coins), which pays for the seigniorage incentives that buys security to the network. Once the demand for the coins stabilize, the real cost of a transaction will be pushed to the system's users.

Edited by RafOlP

Share this post


Link to post
Share on other sites

It is very hard to understanding what the author wants to say. For example,

Quote

This overhead reduces the ability for small computers and nodes to run the blockchain with low energy and bandwidth

Small computers and nodes can't run full Bitcoin node either and one has to use light clients,anyway. So what's the point?

Or,

Quote

Well, in a Turing-complete model, a secondary contract can be broadcast alongside the primary contract for the sole purpose of 'corrupting' the oracle.

How can one contract corrupt the oracle?

Or,

Quote

This means that participants in the Turing-complete contract can not only engage in a contract, but can also bribe the oracle with impunity, and without repercussion.

If you have multisig in bitcoin, one can always bribe one of the multisig parties which acts as a "oracle".

Bribing oracle is not without repercussion. If someone bribes oraclize.it, oraclize.it may suffer serious legal consequences.

 

This article is really confusing. A lot of people will not understand it and it will certainly create some level of fear or uncertainty.

Share this post


Link to post
Share on other sites

More cold water on smart-contracts hype:

http://www.coindesk.com/three-smart-contract-misconceptions/

Quote

But in the hype-filled world of blockchains, smart contracts are all the rage, so why ever not? Well, the problem is, while we now know of three strong use cases for permissioned bitcoin-style blockchains (provenance, company recordkeeping and lightweight finance), we've yet to find the equivalent for Ethereum smart contracts.

It's not that people don't understand what they want smart contracts to do. Rather, it's that so many of these ideas are simply impossible. When smart people hear the term "smart contracts", their imaginations tend to run wild. They conjure up dreams of autonomous intelligent software, going off into the world, taking data along for the ride. Unfortunately, the reality of smart contracts is more mundane.

A smart contract is a piece of code that is stored on an blockchain, triggered by blockchain transactions and which reads and writes data in that blockchain's database. That's it. Really.

 

Share this post


Link to post
Share on other sites
16 hours ago, T8493 said:

It is very hard to understanding what the author wants to say. For example,

Small computers and nodes can't run full Bitcoin node either and one has to use light clients,anyway. So what's the point?

Or,

How can one contract corrupt the oracle?

Or,

If you have multisig in bitcoin, one can always bribe one of the multisig parties which acts as a "oracle".

Bribing oracle is not without repercussion. If someone bribes oraclize.it, oraclize.it may suffer serious legal consequences.

 

This article is really confusing. A lot of people will not understand it and it will certainly create some level of fear or uncertainty.

I don't agree with de Rose in many of his articles, but I think the good point in the article is that it compares 2 scenarios, one that uses a simple multisig account with the participation of an "oracle" as a mediator, and another with a "blockchained oracle". In the end, what is the point of "blockchaining" the oracle's verdict and the entire contract? There must be some good cases for that, I just haven't crossed none that is rock-solid yet.

Is throwing a lot of external data into a blockchain necessary?

Why this must be a dapp and not an app? http://dapps.oraclize.it/youtube-escrow/#0x21c653f72ee09bb2c1246b31520dec7f0b58b7da

All functionalities I have seen so far are stuff that are already possible using normal dbs and programming languages, and don't require a decentralized system to work well.

The cost of storing and running applications in systems like ethereum in the long run is not clear to me, do you know if there is a good source for that?

Share this post


Link to post
Share on other sites
6 hours ago, RafOlP said:

Is throwing a lot of external data into a blockchain necessary?

Why this must be a dapp and not an app? http://dapps.oraclize.it/youtube-escrow/#0x21c653f72ee09bb2c1246b31520dec7f0b58b7da

All functionalities I have seen so far are stuff that are already possible using normal dbs and programming languages, and don't require a decentralized system to work well.

What's the problem with throwing a lot of external data into a blockchain? One needs to indicate events that happen in the real worlds somehow. Such events (transactions) don't consume a lot of resources.

I think this contract is actually one of the rare real-world examples where the dapp makes sense.

If this dapp was written as a regular app, who would host this app and run it? Who would guarantee that host executed the app correctly (that it executed code exactly as it was written and did not try to tamper with the code)? Who would guarantee that the host doesn't go rogue and steals funds? Host must have full access to private keys if this app is not decentralized.

6 hours ago, RafOlP said:

The cost of storing and running applications in systems like ethereum in the long run is not clear to me, do you know if there is a good source for that?

This is another problem. For some types of contract which don't do excessive computations and only wait for rare external events, the costs should be negligible.

But the real question is what types of smart contracts will be able to avoid excessive computations. Some cryptographic operations (that involve zero-knowledge proofs) are already too expensive to perform. Execution of DOGE gateway smart contract was estimated to cost several thousands USD per month or something like that (check reddit).

 

Edited by T8493

Share this post


Link to post
Share on other sites
19 hours ago, T8493 said:

What's the problem with throwing a lot of external data into a blockchain? One needs to indicate events that happen in the real worlds somehow. Such events (transactions) don't consume a lot of resources.

Scalability.

19 hours ago, T8493 said:

I think this contract is actually one of the rare real-world examples where the dapp makes sense.

If this dapp was written as a regular app, who would host this app and run it? Who would guarantee that host executed the app correctly (that it executed code exactly as it was written and did not try to tamper with the code)? Who would guarantee that the host doesn't go rogue and steals funds? Host must have full access to private keys if this app is not decentralized.

This risk is inversely proportional to a company's reliability, so, any reliable company could have built and hosted an app with the same functionality.

Someone must host ethereum nodes too.

19 hours ago, T8493 said:

But the real question is what types of smart contracts will be able to avoid excessive computations. Some cryptographic operations (that involve zero-knowledge proofs) are already too expensive to perform. Execution of DOGE gateway smart contract was estimated to cost several thousands USD per month or something like that (check reddit).

This has to do with my point. There are some possibilities to benefit from distributed ledgers when trying to automate a service that includes fiduciary transactions, but they are not very clear yet. Here are some possibilities for building these automations:

  1. Totally centralized systems can do the job, relying on trust (see home brokers);
  2. A centralized "oracle" integrated to a distributed (public or private, permissioned or not) ledger for cryptographic escrows or other fiduciary transactions;
  3. An application that lives entirely in a distributed permissioned contract platform.
  4. An application that lives in the digital wild west, i.e. an ethereum "contract".

I tend to think that that the costs increase from 1 to 4, but what else increases in the same direction to justify the cost? It seems that it is the independence from a known party for the contract to enforce itself, openness, but above all,  the censorship resistance; things that might not be that necessary when building many kinds of applications.

Share this post


Link to post
Share on other sites

Dude is a clown, he overcompensates his thinner points with bluster and false confidence - and that's when he's not accidentally making a case against using bitcoin for anything at all.  It's also clear in general the bitcoinistas are truly afraid of Ethereum's growing community, adoption rate and governance model.

Bitcoin can do it already!

So do it already?

Bitcoin blockchain is too inefficient to store all the data to run smart contracts

Exactly, perhaps it should be becoming obvious why an interoperability approach is more likely than "one chain to rule them all"?

Bitcoin mining acts as an incentive to reward those who may benefit from the utility of the system.

Flat out lie. Miners have no use for the system other than making profit off cheap access to power. Users cannot scale mining to reap any kind of reward, so they only mine "on prinicipal" to support network. These incentives are at cross-purposes and the political differences are already dragging the protocol down.

The question remains whether the value of the difference in [Turing complete] service can pay for the inordinately higher overhead they require.

Same applies to Bitcoin for non-turing complete service, way overpriced and overscaled security for what it provides.

Single source Oracles and on-chain turing complete testimonies can be corrupted!

Isn't decentralized consensus the whole point of bitcoin? Form a reputation index already, Ripple's is already live.

Most financial contracts require that information be asymmetrically held between the involved parties, so that uninvolved traders cannot trade advantageously on these agreements.
This is R3's bag and why they are focused on permissioned/private instant blockchains. Also note he just fell into the classic trap of using "contract" interchangeably between "financial" and "smart" adjectives, but it is not extensible concpet in this context. In "Smart Contract" it is an abstraction/appropriation, just like a Software Architect isn't a program which designs buildings, its an abstracted role for describing a particular designer of software, which is why many are attempting to limit its use since it is causing confusion.

 

tl:dr DeRose is a shortsighted bitcoin maximalist with shallow, selfish reasoning 

 

 

Share this post


Link to post
Share on other sites
15 minutes ago, tommytrain said:

tl:dr DeRose is a shortsighted bitcoin maximalist with shallow, selfish reasoning 

Yes, I agree, I had many disagreements with him in a chat group. I polluted my post quoting his article, shouldn't have done that, it only creates confusion.

But the interesting point is to discuss what are the perspectives for platforms like ethereum, the nuances between it and current systems, and what are the real use cases that will really benefit from it.

Share this post


Link to post
Share on other sites
1 minute ago, RafOlP said:

Yes, I agree, I had many disagreements with him in a chat group. I polluted my post quoting his article, shouldn't have done that, it only creates confusion.

But the interesting point is to discuss what are the perspectives for platforms like ethereum, the nuances between it and current systems, and what are the real use cases that will really benefit from it.

It's always weird how quickly people start using transportation as a potential use case.

Share this post


Link to post
Share on other sites
10 hours ago, RafOlP said:

I tend to think that that the costs increase from 1 to 4, but what else increases in the same direction to justify the cost? It seems that it is the independence from a known party for the contract to enforce itself, openness, but above all,  the censorship resistance; things that might not be that necessary when building many kinds of applications.

Per contract costs for some types of contracts can actually significantly decrease. How would you implement this YouTube dapp that you posted in a traditional model? You will need to find a host, install VM or create docker container and upload it somewhere, etc. Then you'll be billed a hourly rate for running this VM, although this dapp is basically just waiting for some external event to happen.  Some service providers offer event-based computing models (Amazon AWS Lambda), but they're not common and have their own limitations.

Ethereum contract execution may be even cheaper than traditional models because one could use specialized hardware for running Ethereum bytecode. For example, imagine specialized chips that can execute Ethereum opcodes or running Ethereum dapps on GPUs or Nvidia Teslas or Intel Phi coprocessors.

Ethereum could also introduce opcodes that perform complex (cryptographic) operations which can be implemented directly in hardware (akin to Intel AES-NI instruction set, but for more complex crypto operations).

Another factor that could drive the price down is ecosystem. If everyone uses Ethereum, then the cheapest way to develop and deploy dapps will be often Ethereum, because you'll have tools that support it (Visual Studio), you'll have supporting services (oraclize.it), documentation, etc.

We could also see increased reliability. Ethereum should have 100% uptime, while other providers may not have it.

We could also see significantly increased performance in some cases, because anyone can just download the whole "database" and perform any kind of queries locally. 

In addition, Ethereum solves the hosting problem, while other platforms may not. On ethereum you can just "upload" the contract and it should work, while other platform may need additional non-trivial steps (dockerization, etc.).

Edited by T8493

Share this post


Link to post
Share on other sites

There recently was a point from Lisk against Ethereum. While on Lisk every Dapp is on a sidechain, on Ethereum everything runs in one thread. If there is a bug with Solidity/bytecode running, then potentially a fork can be caused for Ethereum as a whole (game over)....

Share this post


Link to post
Share on other sites
13 hours ago, yandel said:

There recently was a point from Lisk against Ethereum. While on Lisk every Dapp is on a sidechain, on Ethereum everything runs in one thread. If there is a bug with Solidity/bytecode running, then potentially a fork can be caused for Ethereum as a whole (game over)....

This is interesting argument but I think even sidechains don't necessarily solve this problem. For example, if there are two conflicting executions of the same contract and if this contract makes some changes outside of its sidechain (because that's the whole point of contract), then this "conflict" will be seen in another ledger and not necessarily correctly resolved. Hardfork at least "resolves" this conflict at the level of one ledger.

 

Share this post


Link to post
Share on other sites

More uncontrollable variables in open networks:

http://cointelegraph.com/news/bitcoins-transaction-fees-skyrocket-as-the-bitcoin-halving-looms

Quote

Having almost tripled since last summer, Bitcoin transaction fees continue to grow. According to a new bitcoin fee estimator from Bitmain, almost 20,000 transactions are currently paying more than 35 cents for a next block confirmation. The current average fee is almost 15 cents per average bitcoin transaction size of approximately 500 bytes.

 

Edited by RafOlP

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×
×
  • Create New...