
Many Smart Contract Use Cases Are Impossible (2016) - flaviojuvenal
https://www.coindesk.com/three-smart-contract-misconceptions/
======
Animats
This article outlines the basic problem. If you want smart contracts that do
anything off chain, there have to be connections to trusted services that
provide information and take actions. If you have trusted services available,
you may not need a blockchain.

The article points out that you can't construct an ordinary loan on chain,
because you have no way to enforce paying it back short of tying up the loaned
funds tor the duration of the loan. Useful credit fundamentally requires some
way of making debtors pay up later. It's possible to construct various
speculative financial products entirely on chain, and that's been done, but
it's mostly useful for gambling, broadly defined.

~~~
lbradstreet
I'm not a huge proponent on smart contracts, and I agree that it's a big
problem enforcing payback, but that's no worse than regular loans. At least
the ownership/transfership and payback of loans could be tracked, which is a
far cry from the current method of debt ownership. It's extremely common for
spreadsheets full of loans to be passed from owner to owner with no real
ownership trail, accounting, etc, which I find disgusting.

Often fighting these loans is as simple as asking the owner to show proof of
the loans in court, at which point they often evaporate, however it can be a
long winding road to get there and often people just don't show up in court,
or don't know, and get judgements against them that they might not otherwise
owe. If the debt status was easily verifiable, it would be better for all
sides (other than the bad actors) when it ends up in court.

~~~
habitue
> but that's no worse than regular loans

If the blockchain isn't enforcing payback, then it's just a normal transfer of
money from one party to another. There's no smart contract needed.

~~~
vasilipupkin
it's not needed, but transfers using smart contracts could be more convenient
than in other ways. It doesn't have to be a zero or 1 proposition. It's like
saying cloud is not needed because we can do it on the desktop

~~~
runeks
> it's not needed, but transfers using smart contracts could be more
> convenient than in other ways.

Can you provide an example of this?

~~~
vasilipupkin
ok, so say I need to distribute payments. If I transfer money to a wallet and
then a smart contract automatically takes care of sending the right amounts to
the right wallets, it could be more convenient than current payment
distribution solutions, no?

~~~
clappski
I think that's a poor example for the following reasons;

* if it's a one off payment to all recipients, why not just send it manually? * what happens when you need to add or remove recipients? Compared to just phoning up the bank to amend a standing order. * what happens if you accidentally pay someone the wrong amount? * what happens if you lose your wallet and you can't continue paying?

I would rather have a bank handle all of the edge cases and provide the
consumer protections I want out of a payments/account system than some random
script that I (or someone I have to pay) has to maintain that could be
responsible for vast amounts of funds.

~~~
vasilipupkin
Sure, you can use the bank. Internally, the bank could do this on the chain
though and give you all those protections, so you don't even need to do know
the details

~~~
clappski
But why would the bank use the chain, the financial web of trust is already
there and doesn't need to use a chain to facilitate internal or external
transfers of monies. It would be a huge time sink with no real benefit to the
consumer or the shareholders.

~~~
vasilipupkin
And yet banks are experimenting with blockchains, no?

~~~
lambdadmitry
They do, it's just that the way they do that has nothing to do with ETH or BTC
[http://www.r3cev.com/blog/2016/4/4/introducing-r3-corda-a-
di...](http://www.r3cev.com/blog/2016/4/4/introducing-r3-corda-a-distributed-
ledger-designed-for-financial-services)

------
libertymcateer
I have been saying this for quite sometime on this forum - contracts have to
deal with ambiguous circumstances and expressly contemplate being resolved in
courts. Ambiguity of contracts is a _feature_ , not a bug, as it is in the
interest of _both_ parties to be able to argue about certain unanticipated
events when they occur.

Quoting my own comments from a while back:

> The vast majority of contracts do not have syntactically testable
> conditions. They just don't. Whether the conditions in a contract have been
> met is very often a matter of huge debate - this is what "law suits" are
> about. Unless you can create a condition that is testable by code, you
> cannot have a contract that self-enforces with the block chain. The
> conditions set forth in contracts are extremely complex and reasonable
> people can differ. I cannot imagine how you would have a contract be
> triggered on the insolvency of a privately held corporation - good luck
> defining insolvency and good luck getting access to the underlying books.
> Copyright infringement is also a preposterous idea - the amount of semantic
> judgment that must be made to determine if a work is infringing is enormous.
> Only the very simplest of conditions - comparing numbers, checking the time,
> can be reliably automated, and if you are getting a lawyer to write your
> contracts, odds are there is substantially more complexity in the agreements
> than this, which is why you hired the lawyer in the first place. In
> addition, a fair portion of contracts that can actually be set up to work
> this already are - and the blockchain is not necessary. They are things like
> credit cards and they work pretty good without the blockchain.

~~~
empath75
Don't worry, if the developers don't like the ways contract turned out for
them, they can always for the chain and revert it. Which is sort of like a
court, right?

~~~
miguelrochefort
/s

------
raghavtoshniwal
Even for things that smart contracts are capable of doing, the cost of doing
them on a decentralised blockchain is often prohibitively expensive. For
instace the Oraclize service, that does get external data into the contract,
costs around $0.02, per API call. Which isn't much on its own, but they add up
when compared to the number of API calls an average 'centralized' application
makes.

I've often found that for quite a few applications, the cost of executing the
contract on a blockchain outweigh the benefits of decentralisation.

------
sriku
This article is dated Apr 2016. "Oracles" seem to be the way now to inject
external data. Oraclize[1] can apparently be provably kept trustable. Anyone
with deeper knowledge of this?

[1] [http://www.oraclize.it/](http://www.oraclize.it/)

~~~
sriku
To summarize what oracles appear to do, they capitalize on information served
via https and the verified status of the certificates used by sites, to have
an independent party (the "notary") declare that the information was indeed
produced by the party. So the signed statement is of the form -

    
    
       Entity E verified by certificate C said statement S on date D 
    

You can also get, for example, the TLSNotary [1] to sign a secure page's
contents for you without sending over the contents to the service.

To me, this seems to form enough of a trust network to enable injecting
external world data into blockchains, with certificate authorities as the
linchpins.

Appreciate if any security folks here can take this apart and
explain/validate/trash in detail.

[1]
[https://tlsnotary.org/pagesigner.html](https://tlsnotary.org/pagesigner.html)

~~~
mannykannot
I have not figured out how this would solve the problem of on-blockchain debt:

"If the funds used for coupon payments are controlled by the bond's smart
contract, then those payments can indeed be guaranteed. But this also means
those funds cannot be used by the bond issuer for anything else. And if those
funds aren’t under the control of the smart contract, then there is no way in
which payment can be guaranteed.

In other words, a smart bond is either pointless for the issuer, or pointless
for the investor."

~~~
runeks
> I have not figured out how this would solve the problem of on-blockchain
> debt

There really is no problem, unless you have unrealistic expectations as to
what a blockchain can do.

There’s essentially no difference between lending a company money, with which
it purchases machinery, and lending this machinery directly to the company.
Believing a blockchain can ensure that when I lend you my car (a form of
machinery) I will get it back without a scratch, is simply unreasonable.

~~~
mannykannot
I don't know if you have a valid argument in general, but your specific
example seems to be a bit off the mark. If I buy a conventional bond issued by
a company and hold it until term, and the company does not default, I am owed
coupon payments and a return of the principal. I am taking interest-rate,
inflation and default risks, but not depreciation.

I expect an on-blockchain contract would have to allow for default (which I
suppose it could, given a way to signal external events.) Currently, of
course, this is handled through negotiation, arbitration, or ultimately the
bankruptcy courts. It would certainly seem unrealistic to expect that to be
replaced by smart contracts anytime soon.

~~~
runeks
You’re right. Only if we ignore depreciation of capital goods are the two
examples equivalent.

But I was trying to convey the fact that money is just a replacement for
physical goods, such that if the lender _doesn’t_ purchase something with the
lent funds, the loan would be meaningless. And as soon as the lender spends
the lent funds, there’s a risk that it won’t be able to recover this cost. In
other words, riskless credit makes no sense, since the presence of risk is why
there’s a potential return for the lender in the first place.

------
burritofanatic
It's one of the reasons why the use of the term contract is a misnomer and
leads to awkward expectations as to what is possible.

Legally speaking, a contract is merely a promise enforceable in court.

------
max_
The writer is lagging way behind bleeding edge blockchain research.

>1\. Contacting external services ..Often, the first use case proposed is a
smart contract that changes its behavior in response to some external event.
For example, an agricultural insurance policy which pays out conditionally
based on the quantity of rainfall in a given month.

The imagined process goes something like this: The smart contract waits until
the predetermined time, retrieves the weather report from an external service
and behaves appropriately based on the data received.

This all sounds simple enough, but it’s also impossible. Why? Because a
blockchain is a consensus-based system, meaning that it only works if every
node reaches an identical state after processing every transaction and block.

(see [https://github.com/ethereum/wiki/wiki/Sharding-
FAQ](https://github.com/ethereum/wiki/wiki/Sharding-FAQ))

>3\. Hiding confidential data ..Because even if one smart contract can’t read
another’s data, that data is still stored on every single node in the chain.
For each blockchain participant, it’s in the memory or disk of a system which
that participant completely controls. And there’s nothing to stop them reading
the information from their own system, if and when they choose to do so.

(see [https://blog.ethereum.org/2017/01/19/update-integrating-
zcas...](https://blog.ethereum.org/2017/01/19/update-integrating-zcash-
ethereum/))

------
skilesare
This is a really good article to give to my clients who want the blockchain to
do the impossible.

------
clamprecht
(2016)

