Smart Contracts - just a buzzword or are they applicable to the real world?

[Gyrsur]

I constantly asking me if Smart Contracts are just a overhyped topic to attract people to Altcoins and ICOs or do/could they have real use cases in our daily life besides the topic of decentralized money and Bitcoin?

A smart contract is a computer protocol intended to digitally facilitate, verify, or enforce the negotiation or performance of a contract. Smart contracts allow the performance of credible transactions without third parties. These transactions are trackable and irreversible.[1] Smart contracts were first proposed by Nick Szabo, who coined the term, in 1994.[2]

Proponents of smart contracts claim that many kinds of contractual clauses may be made partially or fully self-executing, self-enforcing, or both. The aim of smart contracts is to provide security that is superior to traditional contract law and to reduce other transaction costs associated with contracting. Various cryptocurrencies have implemented types of smart contracts.

I'm just interested in resilient examples which are applicable today not in any kind of hocus-pocus scenarios for the next century.

[1715587514]

1715587514

[1715587514]

1715587514

[1715587514]

1715587514

[1715587514]

1715587514

[DooMAD]

As with all new technologies, there will be people trying to cash in on the hype.  But once it becomes more established (or I should probably say if it becomes more established, as there are no guarantees), I can easily see it being part of everyday life.   Ideally people won't even realise they're using them, because the software will be user-friendly enough to do all the "heavy lifting". 

If Lightning Network adoption eventually takes off in the way we hope it will, that's basically underpinned by smart contracts.  So that's probably the prime example at the moment.  Perhaps there will be some other practical use-cases that other developers come up with in the meantime.  It's still early days, though.  "Wait-and-see" territory.   

[aliashraf]

Op, Ethereum's flavor of smart contracts, i.e. as  a Touring complete, universal machine, is vulnerable to decidability problem (hard to be evaluated and decided to sign or not, for human beings) specially.

But more generally, any FSM or very carefully and cautiously designed UM contracts that rely on oracle (like exchange rate of Gold/USD, ... ) suffer form being non deterministic or highly centralized.

I think because of these problems we are ways far from what scammers want us to believe: a serious trend, at least for the next couple of decades when we might have oracle problem in some application areas, solved.

Meanwhile smart contracts are solid when they use only blockchain dependent data like what a simple timelock does in bitcoin.

[HeRetiK]

Overhyped -- maybe. But I think this buzz is mostly based on a misunderstanding which problems a smart contract (and blockchains, for that matter) can and can't solve.

I doubt that smart contracts will ever go beyond decentralized monies and facilitating p2p commerce / trading; however these use cases alone could already prove groundbreaking.

If one could trade classical stocks / securities and handle their dividends with the ease of ICO tokens that would be quite revolutionary, at least in my book. After all there's a massive overhead of brokers and bankers one could get rid of by replacing them with nearly frictionless p2p trading.

On the more futuristic side of things I do think it's imaginable that further down the road one (or even both) of the peers could be replaced by a machine. In the simplest case, this could be a casino script. In a more optimistic case, one could imagine a future iteration of current voice assistants taking care of more complex (financial) tasks. The latter being a more speculative use case, obviously.

More realistically, however, I think the most important role that smart contracts will play, will be the part of the unsexy utility technology, doing the heavy lifting in the back. Prime example being Lightning Network and other protocol layers (eg. token / asset layers, at which point we're back at the question of the viability of smart contracts handling digital assets).

[kryx]

I'd like to have some examples for our everyday life, but I think that we may see it more clearly in the future, ideas will come and they will bring more new ideas (you may call them inovations)

[x3m]

I'd like to have some examples for our everyday life, but I think that we may see it more clearly in the future, ideas will come and they will bring more new ideas (you may call them inovations)

There are some classical examples:
- An airline company that sells tickets online through a smart contract. The client will be refunded by x% if the flight departs or arrives at destination with more than n hours delay.
- A farmer buys an insurance to cover him from bad weather. If the minimum temperature from dayStart to dayEnd will be more than n day below zero degrees C the farmer will cash a certain amount.

As you can see the above examples relies on Oracles in charge to update the "Virtual world" with data coming from the "Real world". And that's another great subject to debate.

[HeRetiK]

There are some classical examples:
- An airline company that sells tickets online through a smart contract. The client will be refunded by x% if the flight departs or arrives at destination with more than n hours delay.
- A farmer buys an insurance to cover him from bad weather. If the minimum temperature from dayStart to dayEnd will be more than n day below zero degrees C the farmer will cash a certain amount.

As you can see the above examples relies on Oracles in charge to update the "Virtual world" with data coming from the "Real world". And that's another great subject to debate.

The problem with these 2 examples is rather straightforward though: What's the benefit of smart contracts in those scenarios?

- When buying an airline ticket from an airline company, you are already relying on a centralized service while not using a middle-man. Except for payments, obviously, but that's where plain old cryptocurrencies would suffice as well. Adding a smart contract into the mix only increases complexity while the benefit is...?

- Same when buying an insurance. The farmer is already dealing with an insurance company directly, so a smart contract would only add complexity. Granted, one could imagine a crowdfunded, free-market type of decentralized insurance, but the viability of such an approach would be a discussion of its own.

The challenge, when applying smart contracts, is that they should not only work -- which is already hard in its own right. Smart contracts need to be applied to use cases where they work better than what already exists.

[x3m]

There are some classical examples:
- An airline company that sells tickets online through a smart contract. The client will be refunded by x% if the flight departs or arrives at destination with more than n hours delay.
- A farmer buys an insurance to cover him from bad weather. If the minimum temperature from dayStart to dayEnd will be more than n day below zero degrees C the farmer will cash a certain amount.

As you can see the above examples relies on Oracles in charge to update the "Virtual world" with data coming from the "Real world". And that's another great subject to debate.

The problem with these 2 examples is rather straightforward though: What's the benefit of smart contracts in those scenarios?

- When buying an airline ticket from an airline company, you are already relying on a centralized service while not using a middle-man. Except for payments, obviously, but that's where plain old cryptocurrencies would suffice as well. Adding a smart contract into the mix only increases complexity while the benefit is...?

- Same when buying an insurance. The farmer is already dealing with an insurance company directly, so a smart contract would only add complexity. Granted, one could imagine a crowdfunded, free-market type of decentralized insurance, but the viability of such an approach would be a discussion of its own.

The challenge, when applying smart contracts, is that they should not only work -- which is already hard in its own right. Smart contracts need to be applied to use cases where they work better than what already exists.

You're not relying on a centralized service but on a SC (decentralized) developed by a centralized service provider (i.e. airline company). The benefit is that the SC acts as an escrow. The airline company will be fully paid if the flight lands within the time interval otherwise the client will be automatically refunded (no forms to fill, no requests to submit, ...). In addition the SC is censorship resistant, no one can modify or cancel it.

[mfyilmaz]

I think smart contracts would make a lot of things in life easier for example you could do more things without a notary as most paper works could be stored digitally and uneditable in the smart contract and nobody could deny it as blockchain technology is not changeable... there are endless ways to use this new technology for a much simpler life but tho it would make some people unemployed and so they would need to do something else... still this was always the way to go, some people will benefit while others will lose.. thats life I guess.

[Samarkand]

...
In a more optimistic case, one could imagine a future iteration of current voice assistants taking care of more complex (financial) tasks. The latter being a more speculative use case, obviously.
...

I´m not sure if I understand your example correctly. Why is a smart contract necessary
for a future iteration of a current voice assistant? This seems like it could be done
without any smart contract and rather with some form of AI.

On an unrelated note, I think that a major problem with smart contracts is the fact
that all eventualities have to be put down in the code right at the beginning.
In reality contracts are constantly evolving, because of unexpected events that
weren´t specified in the contract. This seems like one of the major issues for now.

[LeGaulois]

The challenge, when applying smart contracts, is that they should not only work -- which is already hard in its own right. Smart contracts need to be applied to use cases where they work better than what already exists.

I could agree with you if we were comparing with Ricardian contracts used by Openbazar for example but smart contracts aren't the same as written contracts. It can help to avoid a violation of an agreement, save time, automated process and reduce costs operating etc..
At the end it can be a more efficient way to deal with contracts

[HeRetiK]

You're not relying on a centralized service but on a SC (decentralized) developed by a centralized service provider (i.e. airline company). The benefit is that the SC acts as an escrow. The airline company will be fully paid if the flight lands within the time interval otherwise the client will be automatically refunded (no forms to fill, no requests to submit, ...). In addition the SC is censorship resistant, no one can modify or cancel it.

The benefit of a smart contract acting as an escrow is rather limited from an airline company's perspective though. Sure, as a consumer it would be nice to get an automatic refund in case of flight delays. But there's no incentive for an airline company to (1) spend money on developing a smart contract for (2) keeping money in limbo that they otherwise would have instantly at their disposal while (3) giving up one of their favourite dark patterns (ie. it is not in an airline company's interest to make getting a refund easy). Put differently, smart contracts need to benefit all parties involved to see practical usage.

...
In a more optimistic case, one could imagine a future iteration of current voice assistants taking care of more complex (financial) tasks. The latter being a more speculative use case, obviously.
...

I´m not sure if I understand your example correctly. Why is a smart contract necessary
for a future iteration of a current voice assistant? This seems like it could be done
without any smart contract and rather with some form of AI.

Sorry for being unclear -- I don't think that smart contracts are necessary for future voice assistants. What I mean is that smart contracts could be one of the many interfaces future voice assistants will be interacting with. To give an example: Right now voice assistants are acting on their user's behalf by either calling an API (eg. Alexa calling Spotify's API to play Despacito) or by making a phone call with a human (eg. Google Duplex making a reservation by calling the restaurant of your choosing). In the future such a voice assistant could additionally interact with public smart contracts (eg. placing an order on a DEX).

Come to think of it, it's a rather bad example though. It highlights how one could interact with smart contracts in the future, rather than what the smart contracts themselves would do.

On an unrelated note, I think that a major problem with smart contracts is the fact
that all eventualities have to be put down in the code right at the beginning.
In reality contracts are constantly evolving, because of unexpected events that
weren´t specified in the contract. This seems like one of the major issues for now.

Excellent point that is often overlooked. Laws leave room for interpretation precisely because not all eventualities can be foreseen and not every factor that played part in an outcome can be quantified (eg. trolley problem).

To add to that, code being law adds another unintended side-effect: Unintended side-effects. From a puristic point of view they are of course simply part of the contract, in practice however they are simply bugs that could cost you a lot of money. Computers are less forgiving than human courts.

The challenge, when applying smart contracts, is that they should not only work -- which is already hard in its own right. Smart contracts need to be applied to use cases where they work better than what already exists.

I could agree with you if we were comparing with Ricardian contracts used by Openbazar for example but smart contracts aren't the same as written contracts. It can help to avoid a violation of an agreement, save time, automated process and reduce costs operating etc..
At the end it can be a more efficient way to deal with contracts

What I meant to say is this: From a practical perspective, a new decentralized solution needs to be significantly more convenient and / or cheaper than an established centralized one. Even if both solutions are equally viable, people will rather stick with an established solution rather than trying the new one. Put differently, smart contracts either need to find a business that they can vastly improve upon (like Uber / Lyft did with Taxis) or find an underserved niche (like Bitcoin did with global P2P payments).

[d5000]

I very much agree with HeRetiK that the main use case for smart contracts is the management of "virtual value" in decentralized networks (just like currencies, securities, and tokens; maybe games/gambling). Jimmy Song has written a nice article about smart contracts where he also covers this topic: The Truth about Smart Contracts.

But there is a notable exception, an use case where a smart contract manages a non-financial asset: Storage management. I refer to systems like Siacoin, where a smart contract checks if certain files are hosted by a server "node" - if yes, it rewars the node owner, and if not, it punishes it. It's possible that there are unknown problems with this approach, but until now it seems to work, while it may be not a complete replacement for traditional hosting, it can be a very cheap, a little bit less reliable alternative.

So decentralized storage systems, even maybe more advanced "decentralized web" concepts (like Maidsafe), could be an interesting non-financial use case. The reason for that is that storage systems have to be reachable permanently by online services, via the Internet - just like blockchains. So the smart contract can directly interact with the service, not with a "representation" of it. No oracle is needed.

A "proof of computation" system is another use case that occurs to me - it has similar characteristics.

However, these use cases are relatively simple, and they would very likely not need a Turing complete smart contract language - these functions can be part of the hard-coded "standard feature set" of a cryptocurrency protocol and/or client software.

[trantute2]

A "proof of computation" system is another use case that occurs to me - it has similar characteristics.

Hmm ... but with limited applications, at least as far as I understand the approach: https://en.wikipedia.org/wiki/Verifiable_computing.

It is like hashing or SAT. That is, computing the function is easy but reversing it should be hard.

For instance, I doubt, that computing graphics for games or movies is one of such problems. You need problems for which people are willing to pay lots of money. A big decentralized SAT-solver is too abstract for virtually everyone and, thus, won't work as killer application.

And, imho, computing the same stuff several times for comparison is ugly (SETI@home), or at least inelegant.

However, these use cases are relatively simple, and they would very likely not need a Turing complete smart contract language - these functions can be part of the hard-coded "standard feature set" of a cryptocurrency protocol and/or client software.

Exact! In the worst case, the protocol is extended (slowly and incrementally).

[HeRetiK]

[...]

But there is a notable exception, an use case where a smart contract manages a non-financial asset: Storage management. I refer to systems like Siacoin, where a smart contract checks if certain files are hosted by a server "node" - if yes, it rewars the node owner, and if not, it punishes it. It's possible that there are unknown problems with this approach, but until now it seems to work, while it may be not a complete replacement for traditional hosting, it can be a very cheap, a little bit less reliable alternative.

So decentralized storage systems, even maybe more advanced "decentralized web" concepts (like Maidsafe), could be an interesting non-financial use case. The reason for that is that storage systems have to be reachable permanently by online services, via the Internet - just like blockchains. So the smart contract can directly interact with the service, not with a "representation" of it. No oracle is needed.

[...]

It's a bit nit-picky but I'm not sure if I'd call decentralized storage systems in themselves smart contracts. I'd define a smart contract as a script that is interpreted by a decentralized network but not intrinsic to it (eg. storage management is an intrinsic functionality of decentralized storage systems whereas LN is not intrinsic to Bitcoin).

That being said, I fully agree -- decentralized storage systems are a very interesting use case for smart contracts. For example one could imagine a self-scaling system that buys more storage space on the fly whenever needed. Or extending automated web application deployment with a script that autonomously purchases storage space and CPU cycles. Whether such approaches would be viable in practice though are a different question.

[r1s2g3]

I think smart contracts would make a lot of things in life easier for example you could do more things without a notary as most paper works could be stored digitally and uneditable in the smart contract and nobody could deny it as blockchain technology is not changeable... there are endless ways to use this new technology for a much simpler life but tho it would make some people unemployed and so they would need to do something else... still this was always the way to go, some people will benefit while others will lose.. thats life I guess.

Do you mean blockchain to store the documents? That is too costly. I do not think business will use something that is costly and do not provide them any tangible or intangible benefits just to show that they are tech-savvy.

I think it can be put somewhere in some practical application like distribution of hall ticket to student. Like Department A sent it report for a student that student attendance is ok. Department B sent report there is no pending dues for student and smart contract now send the digital Hall ticket.

So much manual coordination can be saved here that require reading report from multiple departments and deciding the next course of actions.

[Samarkand]

...
That being said, I fully agree -- decentralized storage systems are a very interesting use case for smart contracts.
...

I´d contradict this statement by using your own argument from a previous
post in this thread 

...
What I meant to say is this: From a practical perspective, a new decentralized solution needs to be significantly more
convenient and / or cheaper than an established centralized one. Even if both solutions are equally viable,
people will rather stick with an established solution rather than trying the new one. Put differently, smart contracts
either need to find a business that they can vastly improve upon (like Uber / Lyft did with Taxis) or find an underserved niche (like Bitcoin did with global P2P payments).

People will probably stick with Dropbox, iCloud and similar services for data storage (and
businesses with services like Amazon AWS that are very flexible). These services work
fine for most use cases and the average user is either not aware or not particularly interested
in decentralized, trustless solutions. The fact that a service like iCloud is heavily integrated into
the Apple ecosystem makes it even harder for a decentralized competitor like Sia to gain any traction.

Of course Sia is trying to attract attention by more attractive pricing, but I´m sceptical whether
this will be enough to gain any traction.

Another use case I have been thinking about is related to the hotel industry. E.g. you could
probably automate the booking / check-in process by using a smart contract (a smart contract
checks for availability of the room for the selected dates and releases a code or passphrase
to unlock the room after verifying the successful payment).

[HeRetiK]

...
That being said, I fully agree -- decentralized storage systems are a very interesting use case for smart contracts.
...

I´d contradict this statement by using your own argument from a previous
post in this thread 

...
What I meant to say is this: From a practical perspective, a new decentralized solution needs to be significantly more
convenient and / or cheaper than an established centralized one. Even if both solutions are equally viable,
people will rather stick with an established solution rather than trying the new one. Put differently, smart contracts
either need to find a business that they can vastly improve upon (like Uber / Lyft did with Taxis) or find an underserved niche (like Bitcoin did with global P2P payments).

People will probably stick with Dropbox, iCloud and similar services for data storage (and
businesses with services like Amazon AWS that are very flexible). These services work
fine for most use cases and the average user is either not aware or not particularly interested
in decentralized, trustless solutions. The fact that a service like iCloud is heavily integrated into
the Apple ecosystem makes it even harder for a decentralized competitor like Sia to gain any traction.

[...]

Ha!

Still, I stand by both my statements, as I believe that decentralized storage is easier to solve than some of the other hypothetical scenarios already mentioned in this thread for one simple reason:

[...] So the smart contract can directly interact with the service, not with a "representation" of it. No oracle is needed. [...]

(granted, many use cases that often get hyped in the context of smart contracts are imho close to impossible, so "easier to solve" is a rather relative expression)

[d5000]

A "proof of computation" system is another use case that occurs to me - it has similar characteristics.

Hmm ... but with limited applications, at least as far as I understand the approach: https://en.wikipedia.org/wiki/Verifiable_computing.

You may be right. It was only an example, and I'm not an expert on this topic. I was referring to projects like Gridcoin where the computation is used for medicinal research, which seems an useful application. But maybe there are significant problems with this approach.

Another example which could be possible, where the smart contract could also interact directly with the object, is a "proof of connection" contract, which verifies that nodes of a network are online, and rewards those who are. That could be useful for mesh networks, for example.

It's a bit nit-picky but I'm not sure if I'd call decentralized storage systems in themselves smart contracts. I'd define a smart contract as a script that is interpreted by a decentralized network but not intrinsic to it (eg. storage management is an intrinsic functionality of decentralized storage systems whereas LN is not intrinsic to Bitcoin).

At the end, that depends on the implementation (if it's part of the standard feature set or an additional program written on a "smart contract platform"). Bitcoin itself could also be viewed as a "smart contract".

It would be interesting if a Sia-like contract is possible with the current Bitcoin script feature set.

Of course Sia is trying to attract attention by more attractive pricing, but I´m sceptical whether
this will be enough to gain any traction.

I think a Sia-like storage solution, in the long term, should be drastically cheaper than a centralized product. The reason is that it's - at least partly - using unused space, and that there are potentially billions of providers.

Another use case I have been thinking about is related to the hotel industry. E.g. you could
probably automate the booking / check-in process by using a smart contract (a smart contract
checks for availability of the room for the selected dates and releases a code or passphrase
to unlock the room after verifying the successful payment).

For a single hotel, this is another example where you don't need the whole network to calculate your computation because you need a centralized party "managing" it. As a hotel owner, you could simply create that "smart contract" on your own servers - as a "standard software application". Why would you want thousands of nodes to compute that contract?

It would maybe be useful if you're wanting to create something like a "decentralized AirBNB". But here I think the main problem is the trust issue. You as a buyer would have to be able to trust that the code exists, and that you don't get robbed in your "hotel room". It's exactly the "representation vs. direct interaction" issue I mentioned in my earlier post.

[hatshepsut93]

Smart contracts work best when something is 100% programmable, then they are trustless. I think at the moment the best example is atomic swaps and decentralized exchanges. But often times projects that utilize smart contracts have some central points of failure, and in those scenario smart contracts provide very little improvements. CryptoKitties is the biggest dapp in history of ETH, but it was pretty centralized because a big part of it relied on a centralized website, and this was also pointed out by Vitalik. Same with ideas for using smart contracts for decentralized markets - they require some trusted intermediaries to work.