Everyone I asked had a different definition of "smart contract". Below is my smart contract definition.
I've been hearing more and more people talking about "smart contracts" these days. But when you ask them to define the term "smart contract", they can't articulate it, the concept just slips out of their hands.
This is not a new finding: Peter Todd came to a similar conclusion after listening to several seminars.
After many discussions about smart contracts, I came to the conclusion that no one really knows what a smart contract is, and if it were to be implemented, oracles would be needed.
— Peter Todd (@petertoddbtc) December 5, 2014
In fact, I was also one of the people who failed to articulate the concept of smart contracts to Peter.
Now, the simplest answer to the next definition of a smart contract is to quote the definition of visionary scholars who predicted "smart contracts" decades ago. Nick Szabo's 1997 paper on smart contracts is a very concise and useful overview. Also, I really like Grigg's "Ricardian Contract " . Saab's "vending machine" model is also very useful.
However, the ideas of these people were put forward before the emergence of Bitcoin, blockchain and cryptocurrency, so for newcomers in the field of cryptocurrency, their definitions are separated and not obvious enough. To add to the confusion, there are now many platforms that intend to implement smart contracts. In fact, you can think of Bitcoin as a smart contract platform. Therefore, it becomes more difficult to distinguish the difference between the concept and the concrete implementation.
In this post, I try my best to explain why smart contracts can be a great idea, and then come up with my own definition and model of a "smart contract".
The Replicated, Shared Ledger
When I think about blockchain and distributed ledgers, I start with Bitcoin's most core innovation: it taught the world how to transfer value over long distances without trusting a third party. (I know some people will disagree, this statement may not be 100% accurate - but I think it brings an intuition to the train of thought.)
We can certainly transfer physical paper money face-to-face, but, before Bitcoin, we couldn’t: transfer value to someone over long distances without trusting a centralized third party (post office, bank, etc.).
It is as if the infrastructure of the traditional transfer model of banks and payment systems is refactored into a peer-to-peer payment network. This transformation is shown in the figure below:
Bitcoin opened the door to a peer-to-peer electronic value transfer model that is completely different from the current banking system, central bank and payment system.
However, the above diagram does not explain how Bitcoin achieves peer-to-peer value transfer.
The answer: the Bitcoin system is built on what I call a "reproducible, shared ledger." Every participant (full node) in the Bitcoin network has a complete copy of the transaction ledger, and the magic of this system is how it keeps everyone's copy consistent with everyone else's.
So, the correct schematic should be the one below, where every participant is able to get information from the same replicable, shared ledger.
The trick with Bitcoin and other decentralized consensus systems is how they ensure that everyone has a copy of the ledger and that everyone can be confident that their ledger is in sync with everyone else's.
Putting things like scalability aside, we know that architectures work like this: if everyone has the same copy of the ledger, then people no longer need a centralized authority to keep track of who owns what. You know: when your ledger is updated to record a new change in asset ownership, the same change occurs in everyone else's ledger.
We need to distinguish: what is recorded in the ledger and how it is recorded
The debate and competition in the field of cryptocurrency is mainly focused on how the ledger is constructed and secured. Bitcoin mining algorithm? Ethereum's system? Ripple's consensus algorithm? These debates focus only on the "how": how to keep the ledger secure? How does the consensus process work? How to prevent bad guys? Because different cryptocurrencies have different assumptions about the nature of the threats they may face, they are different.
But, in this post, let's ignore these "how" questions for a moment and just ask ourselves one question: what does the ledger record? What can it be used for?
What does the ledger record?
In one of my recent blog posts , I explored how the concept of a "reproducible, shared ledger" can be applied beyond money. My point is this: Once you can know for sure that your view of the world is in line with everyone else's, a "reproducible, shared ledger" opens up new possibilities in completely unrelated fields, such as accounting. Ian Grigg has written about triple entry , and companies like tripleentry are exploring triple entry to revolutionize the accounting profession.
We can conclude that if I knew that everyone "sees" the same thing, then I no longer have to build my own ledger at a huge cost, do a ledger audit and talk to everyone else at a huge cost account book for reconciliation and reconciliation. The ledger itself can do these things for me.
Therefore, a replicable, shared ledger may replace the accounting method in the existing business system.
Which areas require double accounting?
One area is in business logic. In real business, there are countless examples of this: both parties (or parties) to a contract independently run a calculation/bookkeeping system that models the terms of the contract. I'm sometimes used to using the bank as an example, and now there are a few non-bank examples:
Large online retailers may have a system to check that the bills they receive from the courier are correct: have all the negotiated discounts been implemented?
Large grocers have entered into complex contractual agreements with suppliers over discounts. The size of the discount is related to sales volume over a certain period and many other factors. We can be sure that both parties to the contract have developed a very mature contract model and made it into software.
What the above examples have in common is that each party to the contract needs an independent means to calculate the value it owns in the contract. They can't trust each other. So, each party has to build its own calculation/recording system. This will result in waste, and reconciliation, adjustment, etc. will be required.
But back to what I said above: for a replicable, shared ledger, where everyone knows that everyone is seeing the same things, one party doesn't need to trust the other to be honest.
Now imagine that your ledger can also run computer code. What you need to do is:
When you agree to a contract with someone, you also agree to a code version of the contract.
"Which external data source should the contract use and how to resolve disputes?" Both parties need to reach a consensus.
Both parties carefully checked the code and made sure there were no backdoors or malicious vulnerabilities. You can also run a test to see if it produces the correct answer.
After both parties are satisfied with it, it is signed and deployed to the ledger.
Now neither side has to spend the effort to re-implement the terms of the contract in their own systems, both parties know that this code will serve their purpose at the same time. Because it runs on a replicable, shared ledger, both parties can be confident that the output of the program is the same for both.
But we can be more sci-fi
So far, I've described a very common use case: a computer program that represents a contractual agreement between two or more parties.
But remember: we are envisioning a new world where these programs run on a replicable, shared ledger.
What if these programs could interact with the ledger? The program can control the assets on the ledger, and you can even send assets to the program. So, it is no longer just a computer program, but a self-sufficient participant in economic activity.
Going back to the grocery store example mentioned above: a grocery store can pay a supplier by sending a payment (quantity A) to a computer program. The program can calculate the possible amount of discount (quantity B), then send the supplier the amount of AB (A minus B), but hold the amount of discount B for now – because we won’t know the discount for sure until the end of the month Rate. At the end of the month, the contract will correctly calculate and send B in custody to all parties.
The program is no longer just a computer program: it is a participant in itself. It responds to the information it receives, it can receive and store value, and it can send information and value out.
This program is like a person who can be trusted to temporarily keep assets and always act according to the rules in advance.
I think that's what people want to express when they talk about smart contracts.
The following diagram is my smart contract model: a piece of code (smart contract), deployed on a shared, replicated ledger, that maintains its own state, controls its own assets and responds to incoming external information or assets .
My own smart contract model: it's a computer program running on a replicable, shared ledger that processes information, receives, stores, and sends value.
theoretical question
This is the essence of smart contracts. A more formal definition of a smart contract might look like this:
Smart contracts are event-driven, stateful programs that run on a replicated, shared ledger and are able to keep assets on the ledger.
This is just my provisional definition. There are still many theoretical problems with smart contracts that have not been solved. I summarize it for future research.
Import real world information
A smart contract is very dependent on the quality of the information sent to it. The "oracle" and "n-of-m" (n-of-m) schemes can help solve the problem. However, I think it should also be considered: what if sources of information disappear, if previously independent sources of information merge, if new and better sources of information appear?
Build the model
If there are multiple ways (e.g., programs directly as assets on the ledger or as contracts) to model various phenomena of the world, it may be a business question which one to choose. Best practices need to emerge to model different real-world phenomena in the right way.
handler error
Have you ever written bug free programs? After the smart contract is deployed, it is found that it has bugs, which is obviously beneficial to the contract party. How to fix it? Just as lawyers can make a lot of money by finding loopholes in contracts, will there be an "engineer-lawyer" who makes money by finding loopholes in smart contracts?
fluidity
If assets are held by smart contracts, those assets cannot be used by anyone. This will change the economic logic of many business models.
legality
Do smart contracts have the same legal effect as "real" contracts? What if the result of a smart contract violates the law, or if a court finds it has a conflict of contract law?
privacy
Most shared, replicated ledgers are public. I don't know how many retailers agree to disclose their contracts with suppliers.
technical problem
Can the underlying technology meet the needs? Can it be extended? etc
other more questions
However, I'm pretty sure that smart people in the community are paying attention and addressing these issues. So, perhaps there is only one question: what compelling business scenarios will be the first to adopt smart contracts?
If you've seen this and understand what I'm saying, I urge you to study the writings of Saab, Grigg, and other great minds in the field, who explain the smart contract field better than I do.
－－－－
- Original: http://gendal.me/2015/02/10/a-simple-model-for-smart-contracts/
- Author: Richard Brown
- Translator: Ether China - Shaoping
－－－－
If you want to learn Ethereum DApp development efficiently , you can visit the most popular online interactive tutorials provided by Huizhi.com:
1. An introductory tutorial for Ethereum DApps for blockchain newbies
2. Blockchain +IPFS+Node.js+ MongoDB+Express decentralized Ethereum e-commerce application development practice
3. Other more content can also visit this Ethereum blog .