The Dark Side of Smart Contracts
businesstechguides.co
businesstechguides.co
I don't see how this makes sense at all. The big problem when handling insurance claims is determining the facts and then interpreting the insurance conditions. None of these can happen on the blockchain, so this information would have to come from an oracle, and in the end you still need to do pretty much exactly the same thing. This would be really more like an unnecessarily complex way to add a mandatory arbitration clause to the insurance. That would result in the same result, another entity chosen by the insurer will judge claims and decide on them. Adding a blockchain here doesn't seem to provide any value at all.
They haven't continued with it, so it may have had problems, and I don't know if it required proof that you actually had a ticket (not doing so could create various problems), but actually I think the blockchain is a great option for this.
The reason is that many people do not trust insurance companies. There is a feeling that they will find any excuse to avoid paying out. To have a blockchain solution where payout is according to a smart contract that is transparent and public is a way to build trust with your customers.
Blockchains have very few very specific usecases, and nobody wants to admit that their usecase isn't one of them.
My point is about the idea of using a blockchain to increase transparency and verifiability of a process that makes payments.
This is one of the 'very few, very specific' use cases that blockchains are good at.
Given that you seem to think that it's not that hard, I wonder if we have a different understanding of the requirements here.
We're trying to make the payment process more transparent and verifiable as a way of increasing trust. You say that we can do that with a database that allows some open access. I don't really see how.
For example - who runs that database? If it's the company that offers the insurance, it's a nonstarter - it doesn't help with trust. If it's some third party, then it's precisely as useful as the trust the customer has in that third-party. Such an approach could work, but in my opinion brings with it more difficulties than a blockchain solution in most cases.
Even if we do find someone trusted to run the 'database with some open access', there's still the question of being confident that payments are made according to the data in the database, and that the data in the database is updated according to the appropriate rules.
Don't oracles have the same issue?
Great point. And yes, there's a trust issue around oracles. I do think that these are dramatically less problematic than some of the other options though.
An organisation that publishes flight data and charges for it, is incentivised to produce accurate, timely data about flights.
If instead we have an insurance organisation keeping a database storing information about claims, its incentives are much more muddy.
I think this is another example of how trust isn't just a full on / full off thing, but that you can make meaningful improvements in trust that can have useful economic consequences even without solving it perfectly.
Depends on who pays, right? If their only consumers are insurance companies, they are incentivized to keep data in a way which is favorable to insurance companies (there are lies, big lies and statistics kind of deal). I believe this is what lead to the sub prime mortgage crisis.
I remember asking someone about this in the early days at the Bitcoin meetup in SF. This was when Ethereum was an idea, not a reality.
I pondered, "Will Ethereum have a way to query the Web in a transaction?". I never got a straight answer from anyone about how that would work well. Later, I discovered that Bitcoin script doesn't have loops, but is still somehow "Turing Complete" according to the inventor, who may or may not be the inventor.
My take then and my take now is that cryptocurrencies have some value for transitory things and imaginary value for more permanent things.
Blockchains are providing no value here, as the parent keeps saying.
Well yes, but I'm looking for something substantive rather than just repeated disagreement [Edit: this was unfair, Fabian2k's comments are all thoughtful and substantive, even if I disagree with where the balance falls].
My claim is that smart contracts can provide value by providing a payment process that is more transparent and verifiable.
I'm still not clear whether the disagreement is based on
* believing that having a more transparent and verifiable payment process is not valuable,
* or that smart contracts don't provide more transparent and verifiable payment processes than the typical insurance industry approach,
* or that smart contracts do provide more transparent and verifiable payment processes, but that there are other technologies that would be better at doing that (in which case, what are they?)
If the payment also is handled via the blockchain, there is a large number of potential concerns here. For me, I don't see how the really minor benefit here would be worth the rather big unknown risks. One important aspect here is that in fully automated systems like this, exploits are also much more efficient and can affect many more people at once.
It is also not clear to me how this would work for insurance at all. For automated and verifiable payment you need to deposit the funds into the contract somehow, and that is simply not how insurance works. If the insurance companies had do lock down funds like this, that business model simply would not exist. So in practice this would have to be some mechanism that only deposits a fraction of the funds. And then I, as a consumer that bought some insurance there would also be vulnerable if someone cleaned out that pool of money, e.g. by exploiting a flawed oracle or risk estimation process.
I don't understand enough of the details here to actually judge the risk, but to me that is a point against the entire thing.
And the problematic cases are the ones with enough ambiguity in facts or insurance conditions to make things messy, and those are pretty much impossible to automate.
How many of the said customers are even remotely capable of grokking the pile of Solidity which actually make the smart contract?
Software engineer don't even review code for their npm packages these days, and you expect random people to audit their insurance smart contract?!
Additionally, we all know how be company marketing work: after a bit of time their will be hundreds of different contracts, with completely different guaranties and undecipherable naming schemes which would make it really hard even for the most motivated solidity programmer to actually know what he's bought.
They could just get flight data from API's which already exists. For example in the EU all flight and all flight passenger data are stored in a DB.
Just call that API check against it and pay out the cash.
No need for a smart contract
Cheaper, faster and as secure as any smart contract.
Your point seems to be that having an automated payment for this case is easy. Yes, it is, but if it's running in a datacenter somewhere on hardware you control, the user cannot inspect or ask someone else to inspect the program that controls that payment. They can't see when it changes. They cannot be sure that a published claim that the payment is automatic will really be held to, or even that a trade reviewer will get the same treatment as them so it doesn't help address the deficit of trust.
A smart contract gives you another way of making a publicly verifiable claim about your payments process. It's an additional tool in building trust.
If nobody trust AXA they will go out of business.
I don't understand that logic.
Why do I need more trust?
Why should I care about the inner workings? At the end I want the money on my bank account
Everybody should have there own data center? Even my 80 year old grandma? In what strange world do you live in?
It sounds to me like your living in a trustless world were everybody has access to a datacenter and fast internet...
Your trust issues are the problem here and smart contracts are not solving them
One of the huge challenges of the insurance industry at the moment is that while research shows that 60% of people think insurance is important, only 30% have a positive view of the industry. https://www.nsinsurance.com/analysis/the-geneva-association-...
This leads to people still buying insurance, but buying much less of it than they or the industry would like. So yes, this lack of trust is leading to bad outcomes for both the industry and the individuals, but the argument I worry you're making - that the industry exists and so therefore is fully trusted is not a valid one.
I think you've misunderstood my data center point. The point is that if our hypothetical insurance company has a brilliant automated payment system, but it's running in a place that it cannot be verified, then there's little benefit to trust. A smart contract solution on the other hand can be public and verified (without your grandma running a datacenter). None of this requires fast internet or even datacenters.
Trust issues absolutely are the problem here, and a deficit in trust is leading to bad outcomes. Smart contracts are a tool that can be used to help, because they act as a public, transparent, verifiable statement of what the payments process actually is.
Far from the only way, unless you restrict the "only" to the ability to verify the software before it runs.
if you allow the more general case, and the one I think most customers would care about, the concern is a verifiable guarantee that if their flight is cancelled, the insurance will pay out within X hours of the official cancellation of the flight.
However, this is already verifiable by the dumb contract. Noting that this "dumb" contract can be enforced by law.
The law (and the regulations on the insurance industry) are a publicly verifiable claim about the payments process. Yes, the public verification stops at the interface layer (and hides the application layer), but we usually accept this as a good principle of software design, don't we?
This is generally true, AFAICT, in pretty much all situations.
Blockchain/Smart Contracts are a solution were we first have to find a problem they are really solving or solving better.
But yes, a human or a group of humans still need to be in the loop somewhere along the automation line, but depending on the insurance type, this sort of activity can be partially automated by automatic data feeds from oracles, such as what Etherisc does with crop insurance and flight insurance: https://etherisc.com/#products
Etherisc's crop insurance product, in particular, is aimed at developing nations that do not have robust legal systems or mature, reliable, trustworthy insurance companies. They can, however, get some level of protection by blending weather disaster reports from oracles (drought, hurricane, flood, etc) along with geolocation data with automatic payouts.
So in that scenario it's actually a big improvement over the existing system, which is no crop insurance at all. And a smart contract that is provably solvent is far better than a fleeting promise from a local company that may steal your money with no legal recourse due to the jurisdiction.
However, parametric insurance policies in no way need a blockchain to provide the service. Western Union does a great job of getting money to unbanked regions.
Which makes me wonder one more thing about blockchain based solutions. What currency is the payout made in?
How is blockchain an advantage if the payout is to be in USD? or local currency? If it is instead in crypto, how do you manage the FX risk? Or the legal risk? or the simple "I don't have an easy way to convert crypto to local" risk?
Wat. It’s been provided by the federal government since 1938 [1]. It’s basically free for catastrophic. (It’s true that it’s not available for all crops in all counties. But that’s usually for a good reason. And private insurance fills the gaps.)
[1] https://legacy.rma.usda.gov/aboutrma/what/history.html
[2] https://en.m.wikipedia.org/wiki/Agricultural_Adjustment_Act_...
Because I'd buy that theory.
(Less so a blockchain solution to anything)
Genuine question: since land ownership rests on said legal system, what prevents me from taking out insurance on the whole of Kenya?
My contract with my power company is pretty smart in that they have an API with the current rate that lets certain devices switch themselves on and off. Same with cloud provider with APIs to programmatically add and remove resources.
This thing with oracles doesn’t sound all that different from going to the courts or to arbitration.
On the contrary, the "blockchain part" is the bit that prevents the contract from being modified after the fact. It's an essential property of any contract, and immutability is core feature provided by a blockchain.
In fact their very term blockchain arises from the need to provide that immutability. A blockchain is a series of statements, each relying on the ones before it. That means if you want to modify history you must also modify all the statements that came after and since a lot of other unrelated transactions depend on those statements, you would attract a lot of flak if you attempted it.
It's true we've been providing that immutability in other ways for literally millennia. However, none of those are as difficult to change as something bitcoin puts in it's blockchain, and it provides that service for a fairly small mining fee.
I get that, but I fail to see the relevance in practice. If someone wants to go and commit fraud they can just do it, ignoring what it says in the immutable contract just as they ignore what it says in the law against fraud.
A smart contract, even a mutable one, is incredibly useful. It is a state machine that can be programmed arbitrarily to receive funds, distribute funds based on particular rules, etc. Like a DAO, for an example, should be thought of as an LLC-like arrangement. Organizations necessarily evolve and need to be able to change their current framework from time to time, or they're calcified against necessary change.
That being said, the rules for conducting an upgrade can still be tightly controlled or placed into a 5 of 8 multisig or a full DAO vote with 10% minimum token supply participating if need be. It's all completely arbitrary and fully programmable. That is, to say, it's incredibly powerful.
A mutable contract is clearly not a violation of the contract, as it must be intentionally programmed in that way in the first place, and so it should be clear to any party reading the code of that particular contract that mutability is a feature of the contract and under what conditions mutability is able to be executed.
Some contracts you want to be immutable, some contracts you want to be configurable. It's just as simple as that. No need to overthink it, just understand what type of contract you're interacting with and under what terms. That's all.
The supplier will provide incremental versions of its contract, and the customer has the freedom of upgrading or not to the latest version. At least that's how clean contracts are deployed.
The Gnosis Safe is a good example of this pattern.
The proxy contract and the actual contract is immutable. The references and variables are not, as it is meant to be programmable.
Per contract law, any party can sue in court if the other fails to satisfy their part of the bargain. Contracts allow people who may or may not trust themselves to do business since there's a trusted intermediary (the court) to enforce the agreements."
(I admit being n00b here, and this piqued my curiosity.)
Has there been any cases where the validity of smart contracts has been judged in courts?
The article talks about removing the third party arbitration and the vending machine. But I don't see the mapping of the vending machine example, over to the landlord, rent payment - where one or the other party actually breaks the agreement. How is that solved with smart contracts? For example paying for something that turns out to be something else (an orgiginal drawing of a monkey, a container supposedly filled with high value, non-counterfeit Nike shoes.)
You pay the money
Landlord refuses to give keys
My gut says that the smart contract should then return the money automatically.
But what if you are lying and did receive the keys.
The only way to solve that is through independent / judicial? verification?
In which case, what's the big deal about smart contracts? They're just digital manifestations of what's already taking place?
Feel free to annhialate my karma. It's probable I just don't understand.
That said, you could imagine using smart locks that are connected to the blockchain and using smartcards for keys. Then at least key management is "solved". I put it in quotes because again, it's the physical world so there's still the issue that the smart lock could be broken and blockchain can't do anything about it.
I don't think it makes sense for rentals because that field is heavily regulated and in a lot of jurisdictions you can't just lock out tenants when they're a day late on payment.
It could make sense for something like standardizing gym access. For 24 hour gyms there's already systems to get access when no staff is present. You could imagine a blockchain based solution to manage that in a standardized way that could work across different gym chains.
The advantage would be that pay-per-use is handled in an automatic way, gyms that want to join the network just need some hardware for access and they're good to go. As a user you wouldn't have to sign up for a different gym every time you move. The big issue is that most gyms don't want pay per use, they want to sell subscriptions knowing that most people end up not going after a few times.
The above solution could also obviously be implemented by a centralized provider without using blockchain. Blockchain would be a marketing angle I guess and might help convince investors to give you money.
Or any trusted third party...
The only way it can be "automatically" verified is if there is a way to programmatically work out if the keys have been delivered to the right person. In ebay terms, signed delivery is enough, because the delivery company provides a signature.
But for a landlord situation its much harder. You need to some how verify the receipt of keys went to the correct person stated in the "smart" contract. The traditional way is getting the estate agent to look at the ID of the person and get them to sign a form.
There are two, broad ways for smart contracts to be useful. Either, there's some way of interacting with real world objects. Or, the contracts pertain to something completely digital that can be encompassed in a blockchain, like exchanging other digital assets.
The former also requires outside realities (eg a court orders that a smart contract is void) to be reflected back to the blockchain. The latter, at least in theory, can be code only, and therefore plausibly decentralised.
If your entire service is a very thin wrapper around a smart contract, the market may decide that a fork with equivalent functionality and lower fees is more worth using.
On the other hand, if your service also provides other features on top of the contract (web/native interfaces, UX, hosting, ongoing development, customer support, and so on) then it may be hard to build a competitor simply by forking the underlying contract.
Why would anyone trust a smart contract that doesn't provide readable source for auditing purposes?
While only byte code is stored on chain, generally the source is available on github.
Yes decompilers exist I'm sure at some level of reasonable output. That's a problem that has existed in all paid software.
Or like my sibling said you supplement the contract with a good UI, additional tools, good branding, etc.
But then on the other hand open source exists with contracts too.
Almost every defi swap on multiple chains (evm compatible) is based off Uniswap. There's multiple versions and the clones have upgraded as needed and it's all accepted. Makes integration with existing explorers and wallets easier as well. Most support these uniswap-compatible contract clones because the API is the same.
But others said the same, so it may be true. Perhaps for saving storage/bandwidth, and you can simply verify that it is the contract corresponding to some source code that has been published elsewhere?
Saving bandwidth is definitely a reason. The EVM call to create the contract charges a gas fee per byte.
Currently etherscan and other chain explorer sites will recompile your provided source (and compiler options) and ensure your deployed bytecode matches their results. If so they publicly provide the source and a nice verification checkbox. Some also give you (the public) tools to make read/write API calls to the contract directly by introspecting the API.
If smart contracts were to lock up all assets required for fulfillment prior to execution and completion, then they could get around some of the issue sometimes encountered in normal contracts, but then their use would be massively liquidity reducing/require huge additional liquidity in most cases. Whether the latter is desirable on a larger scale is at least debatable.
- Reliance on external data is the same problem for any program.
- Smart contracts can be upgraded
- confidentiality is being adressed with ZKP
- to discuss about the legal status is to miss the main point of Smart Contracts.
- Any code has bugs and security flaws. The mitigation must combine traditional security and financial backstops. This is the consequence of relying on code
- Smart contracts execution is one of the most secure you can achieve. It comes with tradeoffs.
No.
Contracts only work because they are backed by a law court, allowing judgement by a (supposedly) neutral third party. That third party is able to rectify any points of law that might have been bent/broken.
That means that if someone commits fraud on the basis of a dodgy contract, you have _some_ chance of recovering your money/property and putting that person in jail.
Smart contracts basically allow people to hide gotchas in badly written/obfuscated code. So now you need to be really good at both legalese and which ever language the "smart" contract is written in. Its not like there are many accessible test suites out there to help a mortal.
I get the promise, but if I was moving serious amounts of money/goods/services, I sure as hell would be paying for a lawyer to draft a contract. Because if someone is going to destroy my livelihood, I want to make sure they go the fuck to jail.
The word Fun is in fundamental, doesn't make it fun.
Contracts are written in specific ways, either because they are directed by law, or because they are trying to reference law to make something happen (or not happen).
Convention, rulings and specific laws have been built over time to make sure that certain practices are stopped or encouraged.
In the UK(and therefore possible common law), there is the concept of a verbal contract, which is implied or sealed when money is exchanged. For example when I buy something physical from a website, its distance selling, which means that regardless of what the site says, I am entitled to send the item back within 14 days and get a refund(with some conditions).
Smart contracts are not either smart or a contract. its an implied contract at best, which means the legal outcome is undefined. the onus is on you to prove that it was a contract, and that your contract complied with the relevant implied laws for the transaction you are doing.
You could perhaps have a legal contract that goes along with the smart contract, and which refers to the smart contract, and this legal contract could be enforced through law stuff.
But, I think that's a different idea than the law backing smart contracts.
- Upgraded... so can a traditional contract as well.
- Confidentiality... I keep my traditional contract in a safe box.
- Legal status... if smart contracts aren't (mainly) concerned with legality then they're not really contracts, are they.
- Mitigation... must combine traditional backstops (like traditional contracts) PLUS code analysis and such novel topics, so it gets more difficult with smart contracts.
- Execution... I don't even know how that translates in the traditional contracts world, so I guess it wasn't needed traditionally.
They certainly do that.