Smart contracts aren't really smart and they're still have little bit problems

A contract usually connects the two parties or parties to something in the future, such as buying and selling real estate, car insurance, etc.
The difference between a smart contract and an ordinary contract is that all the execution conditions in a smart contract are evaluated and completed by computer code.
In real life, when our contracts go wrong, we rely on trusted third parties such as lawyers and courts to uphold justice; in smart contracts, there is no trust in a third party, because the computer code can objectively help us execute all the terms of the contract, which is the equivalent of a good judge.
It sounds like the " smart contract " seems to be big, and it should be " smart " like artificial intelligence.
But that is not the case.
A qualified smart contract should include all possible scenarios.
Because the core of smart contracts is that " even in the darkest of circumstances, the fairest decisions are to be made. "
However, in the current situation, the smart contracts we are exposed to are following a set of rules set by the programmer.
It doesn't take into account factors other than the rules.
This means that there is no room for indecision and a lack of discipline outside the rules.
And that leads us to the next question.

Smart contracts are really hard to guarantee
This can be seen from the ether.
Because ethereum itself is a smart contract platform, many people believe that only ethereum can implement smart contracts.
But this is a cognitive error, since the concept of smart contracts existed before bitcoin was invented, and in 2009 bitcoin developed a fairly extensive " Script " ( Script ) of the intelligent contract language.
The difference between ethereum and bitcoin is that the ethereum is turing complete, with more and more complex contracts through the platform, and of course the cost of complex contracts makes it even more difficult to analyze.
In general, complexity is proportional to the probability of a vulnerability; the higher the complexity, the greater the chance of a vulnerability.
It can be tricky to execute such a contract in the case of turing, because if you want to prove that your contract is secure, it is equivalent to proving that there are no bugs in a computer program.
But there's no such thing as a bug-free computer program in this world!
It takes at least a few years of study to become a qualified judge, but the threshold for writing smart contracts is so low that many programmers are new and don't really know how to keep them safe.
As recently as early November, a newcomer to Github, devops199, accidentally deleted the library function of a smart contract, causing about $ 300 million of the ethereum to be locked up, and it hasn't been thawed yet.

The way ethereum deals with this problem is that it puts the onus of code security on the programmer to solve the security problems that the code might have, and the devops199 example shows that not all programmers can take on this task.
In addition, the idea of ethereum is that " code is law, " and the ethereum contract is the ultimate authority, and no one can veto the contract.
But when The Dao event rolled back The trading record, The code itself was attacked by hackers, and it was no different than a brain-dead cpa to find loopholes in The tax code to help his clients save money.
It's the code itself that cracks the " code is the law ".
This led to the division of ethereum, and it also led many developers to suggest avoiding turing-complete to ensure the safety of smart contracts.
The two most popular smart contract standards for ethereum are ERC20 and ERC721, both of which are not supported by turing-complete.
Unlike ethereum, bitcoin initially chose to solve the problem by giving up turing complete to reduce the complexity of the smart contract to improve the contract's accessibility, thus improving the security of the contract.
Because in a non-turing condition, the state of the program can be listed as an enumeration, which makes it easier to verify.

Smart contracts really don't trust
Even without turing, a smart contract sounds fine, since there is no need for intermediaries such as courts and lawyers to be automated without the need to trust a third party, which is bound to be far more efficient than a regular contract.
But here are two more questions:
None-third party is a core feature of smart contracts.
But even if the smart contracts themselves are to be trusted, the execution of contracts still depends on third parties;
In a decentralized environment, where smart contracts really work, there has to be a strong correlation between the virtual world and the real world;
Consider buying a house: if the house is the equivalent of the ETH token in the world of ethereum, then in the virtual world A will transfer the ownership of the house to the name of B, in exchange for A certain number of ETH, while in the real world, B should also believes that these are actually equivalent to the ownership of the house.
So they still need a third party to prove that when he hands over the ETH he will be able to legally get the ownership of the house.
There is a problem with the " oracle ", which is the only way for intelligent contracts to interact with the external environment, where external data is entered into the intelligent contract process as input parameters for smart contracts.
It is only by prophecy that you can determine whether your state in the virtual world and the real world is consistent with the performance of the contract.
In essence, you still need to trust that the data flowing into the oracle machine is objective and accurate, which goes against the idea of none-thrid party smart contract.
And if you think about it a little bit further, even when the authorities say that this token is actually a real estate, what if these tokens are stolen?
So the house belongs to the thief?
What if the token is lost?
Can't this house be sold again?
Can you get a new token in exchange for the ownership of the house?
If so, who will do these things?

In the absence of a oracle machine, the only thing that works is the digital anonymous tool.
Essentially, the " digital anonymous tool " means that the ownership of tokens can not be attached to any dependent relationship outside the platform of the smart contract.
As a result, smart contracts are most likely to be trusted only in the form of endogenous tokens such as bitcoin ( which do not require input from external data ).
We certainly hope that smart contracts will be more effective than regular contracts, but unfortunately many of the contracts in real life involve a set of assumptions and established legal systems, and it turns out that turing completed smart contracts can easily lead to unintended consequences.