Ok, I understand that it's a description in code of "if X happens, then state becomes Y". Like a contract but in code. But, someone has to input that X has happened. So is it not trivially manipulated by that person?
The pure (if you like) smart contacts do transactions. You give me 100 apple tokens and I give you 50 pear tokens. The contract ensures nothing else can happen.
They get more sophisticated e.g. automatic market makers. But same idea just swapping.
Voting is also possible e.g. release funds if there is a quorom. Who to release them to could be hard coded or part of the vote.
For external info from the real world e.g. "who got elected" you need an oracle. I.e. you trust someone not to lie and not to get hacked. You can fix the "someone" to a specific address but you still need to trust them.
Just wanted to add that the oracle can have also majority mechanisms, can stop being used if it drifts too much or is unavailable for too long. People running the oracle can be incentivized by staking some amount of money that they lose if they do not meet SLA-like conditions, etc. It requires trust but it is not just all trust or nothing.
That's a great explanation. I'm sure it's a lot deeper than that but I've never really understood the purpose. I'm not a crypto guy at all so it's nice hearing real world applications rather than just "stock market babble".
Smart contracts are actually pretty cool, but the entire ecosystem is made dramatically worse by the tokens having speculative value. It’s necessary for the economics to work out, but it dampens the coolness of the technical aspects because it attracts sleazeballs and enables fraud/crime.
The "worse" part about it is due to our society and what motivates people to do work. It has little to do with the technology and just a reflection of reality.
I think you get that, but I don't see another way to create a high performance trustless network.
Once a contract is deployed on the blockchain, its source code is immutable. So before using a contract, check if it gives permission to its deployer (or any address) to change any state at will.
Note that some contracts act as proxy to other contract and can be made to point to another code through a state change, if this is the case then you need to trust whoever can change the state to point to another contract. Such contract sometime have a timelock so that if such a change occurs, there's a delay before it is actually activated, which gives time to users to withdraw their funds if they do not trust the update.
If you are talking about Oracle contracts, if it's an oracle involving offchain data, then there will always be some trust involved, which is usually managed by having the offchain actors share the responsibility and staking some money with the risk to get slashed if they turn into bad actors. But again, offchain data oracles will always require some level of trust that would have to deal with in non-blockchain apps too.
It's more akin to a compiled executable that optionally has state. The caller pays to make changes to the state. It's up to the programmer who wrote the smart contract to make it so that unwanted changes aren't performed (eg. simple if-elses to check that the caller is in a hardcoded list or ask another smart contract to validate).
Each external from outside the blockchain into the program's functions are atomic., so user wallet initials func1 which calls func2 which calls func3, no matter which smart contract func2 and func3 are in, the whole call stack is 1 atomic operation.
A token is basically a smart contract that has an associate array with the owners as the keys and the values as the balance: [alice: 1, bob: 20].
And then you can imagine how the rest like transfers, swaps etc works.
And then it's kind of a "contract" because of the atomic nature. Since X transfers $1 to Y and Y transfers 1 cat to X for it is 1 atomic transaction.
Unless you know and trust person X, you don't want to authorize and interact with such contracts. Scammers will leave loopholes in code so they can, for example, grab all funds deposited to the contract.
Normal contracts that involve money operations would have safeguards that disallow the owner to touch balance that is not theirs. But there's billion of creative attack vectors to bypass that, either by that person X, or any 3rd party
I’m convinced that there is a reason from blockchain, but it was like 10 years too early - OR - we’ve already passed the problem it solves and didn’t notice.
Well, technically DVCSes like git use "blockchain" (the repo, logically, is pretty much a chain of blocks that incorporate the hash of the previous blocks - just tree instead of linear dependency).
So we are already successfully using blockchain for decades just not as... currency provider.
Forward secure sealing (used in logging) also have similar idea
It's funny that it just re-invented stuff already used for old world finances, and just invented escrow with more moving parts while still requiring non-compromised 3rd party.
Not really. Smart contracts ensure that if all the conditions are met, the contract will be fulfilled. They achieve that through decentralisation: no one person can decide whether or not it will be fulfilled.
No real world contract can replicate that - you have to go to court to enforce a breach of contract and it isn't certain you will succeed. Even if you succeed the other party can refuse to comply, and then you need to try to enforce, which also may or may not work.
> Not really. Smart contracts ensure that if all the conditions are met, the contract will be fulfilled.
Not really. Smart contracts ensure that if all the conditions IN THE CHAIN ITSELF are met, the contract will be fulfilled.
"The product you paid got delivered" is not on chain. It can't be verified without trusted party putting that info in the chain. Sure, it can be made into multiple entities confirming if needed but it is still dependent on "some people" rather than "true state of reality.
> No real world contract can replicate that - you have to go to court to enforce a breach of contract and it isn't certain you will succeed.
The oracle can lie and be unreliable too. It would be great system if you mangaged a video game where the currency system can see the objective state of the world, but ethereum can't, needs oracle(s).
In both cases you basically rely on reputation of oracle, or escrow company in case of old money transaction, to have high degree of safety.
On the contrary, I think many real world contracts replicate the property that a bunch of people have to sign off on it and no one person decides whether it will be fulfilled.
Not sure what you mean that "input that X has happened". You don't directly input the changes, instead, you call a function that creates that state change (or not, if it's invalid), by running its code. This code can include checks on who is the caller, it can check if you're the contract owner, if you're someone who already interacted with the contract (by checking previous state), or any hardcoded address etc.
Yes, this is a problem (look up "the oracle problem"). My understanding is that the conventional solution is to rely on trusted third-party oracles that are outside of the control of the contract's participants and/or require consensus over multiple oracles.
State is globally distributed, and smart contract code executes state transitions on that state. When someone submits a transaction with certain function parameters, anyone can verify that those parameters will lead to that exact state transition.
There's already many replies, but I'm not sure any of them answers your question directly:
You are somewhat correct that contracts take external inputs in some cases, but note that this isn't a given. For example you could have a contract that has the behavior "if someone deposits X scoin at escrow address A, send them Y gcoin from escrow address Y". That someone can only deposit scoins and get gcoins in exchange. They can't just take all the escrow account balances. So there are inputs, but they are subject to some sort of validation and contract logic that limits their power. Blockchain people call this an "on-chain event".
So short answer is: no smart contracts can't be trivially manipulated by someone, including their owner. But not being able to do that depends on there not being any bugs or back doors in the contract code.
If you are asking about a contract that has some bearing on an event in meat-space, such as someone buying a house, or depositing a bar of gold in a room somewhere, then that depends on someone telling the contract it happened. Blockchain people call this an "off-chain event". This is the "oracle problem" that you'll see mentioned in other replies. Anything off-chain is generally regarded by blockchain folks as sketchy, but sometimes unavoidable. E.g. betting markets need some way to be told that the event being bet on happened or didn't happen. The blockchain has no way to know if it snowed in Central London on December 25.
You can create hot air "organizations" with contract rules on the Ethereum blockchain. If the inner circle does not like a contract, they fork everything:
they're like a Trust that self executes distributions
except that they cost a fraction of a cent to create instead of several thousand dollars in lawyer fees for the initial revision, and can be tested in infinite scenarios for free
to your theoretical reservation, the trust similarity continues, as the constraints around the X are also codified. The person that triggers it can only send sanitized information, isn't necessarily an administrator, admins/trustees can be relinquished for it to be completely orphaned, and so on
Ok, I understand that it's a description in code of "if X happens, then state becomes Y". Like a contract but in code. But, someone has to input that X has happened. So is it not trivially manipulated by that person?