This is part 3 of 4 from a series about Byteball. Part 1 covers the why of Byteball, part 2 explains how the DAG works. So if you missed those, read them now and then come back to this one.
Rather watch a video than read a story? Then watch the YouTube link below. If not, just keep on reading.
So having a fancy crypto platform is nice and all, but what good is it without demand? To create demand you need to have something unique. The unique thing that Byteball provides are smart contracts.
Smart contracts are just plain regular legal contracts, except their terms are stored on the distributed ledger and they are machine readable, which enables their automatic verification by all peers.
OK, so not so plain. Let’s have a closer look.
Smart contracts are not unique, you say? Maybe not, but what good is a smart contract if you have to study a programming language to understand what it says? For a useful, thriving economy we need smart contracts that are accessible to the widest possible audience. That’s why in Byteball smart contracts are written in a simple declarative language that can very easily be translated to human readable form.
The contracts consist of simple constraints that say which of the parties of the contract can spend the money locked on it, and under which circumstances. And you don’t need to be a developer to understand or compose these contracts, you don’t need to trust a developer either. Everybody can easily see what the contract means, just like a regular legal contract.
This is what makes Byteball unique. But let’s take a look at an example.
Case: Flight Delay Insurance
Let’s say that we want to make a flight delay insurance contract.
Both the insured and the insurer pay their respective shares to the contract, for example, the insurer pays 90% of the total, while the insured pays 10%. You can look at the 10% as the insurance premium.
Now the smart contract only says who can unlock the contract if the flight is delayed. The insured if the delay is more than one hour and the insurer in any other case. No need for a claims department, financial department, terms and conditions, etc. etc. We do need one thing though.
The contract also specifies a trusted third party — we call it an Oracle. This Oracle’s only job is to provide true and accurate data about the delay of this specific flight. We only have to trust the oracle about this, the data.
It doesn’t have to know anything about the parties or amounts involved.
It doesn’t even have to know anything about whether the contract actually exists!
The terms of the contract can be represented in human readable form, like I said before.
And a contract like this can be created by anybody by just using the standard wallet, no special tools or skills required. So that “Smart contracts made simple.” tagline is surely well deserved, isn’t it?
The nice thing about these contracts is that you can 100% trust them to be executed exactly as agreed upon. There is just no way that the other party doesn’t pay or doesn’t deliver. It’s literally impossible. The terms of the contract are on the distributed ledger, and they are verified by multiple impartial participants.
Flight Delay Insurance is LIVE since April 2017, try it out in the wallet!
So, to sum it all up, what makes Byteball’s smart contract enforcement different is:
- No reputation required
- No real names required
- Automatic
- Inexpensive
- Fast
- P2P friendly
Which takes us back to the contract enforcement picture from part 1.
Because now we have 4 options to enforce contracts!
Byteball smart contracts will help to lower the barriers to entry to any economy and they will enable value creation where it was just not possible before.
Smart contracts give you the freedom to safely transact with anybody, anywhere, peer-to-peer …
Which was the whole point of crypto right from day one ….
Thanks for reading, 4th and last part here:
Introduction to Byteball — Part 4: Adoption
