One of the most common pros of blockchains/smart contract that I see is the guarantee of certain action (most commonly money transfers). However, I don't quite understand how it is guaranteed? Smart contracts are basically pieces of code where the author can write them in anyway they want, so how is it different from standard applications?


We could argue that the difference between Fintech and smart contracts is that the former is software managing money while the latter is money executing software. This is a way to approach an answer to your question.

Unfortunately there is some confusion between the word transaction and the actual meaning. A transaction in Ethereum is often a command payload signed by some private key that basically states

dear contract 0xsomething 
do someAction( ) which changes your internal state 
-- signed by 0xsomeone

The transaction actually is the change of state which is on/off (for instance a variable x=1 changes to x=2) , and it is more the outcome of the command above.

A smart contract is basically an amount of money (I know, this is oversimplification) reacting to transactions (or transaction commands) as defined above, issued to it.

do someAction( ) can be very complex logic, with many different internal state change and interactions with many other instantiated contracts. Assume we have a contract with 2 variable x=0 and y=0, and a balance of 10ETH; in pseudo code let's see a call to doSomething() like:

x = x + 1;
send 1 ETH to 0x999...
y = x + y;

if, for some reason, the execution flow throws an exception between start and stop then the state is just rolled back to the previous state

{x: 0, y: 0, balance: 10ETH}. 

In case of success the new state would be:

{x: 1, y: 1, balance: 9 ETH}

Transaction are for their very nature something articulated and complex but they eventually succeed or don't. There is not a partially completed transaction. If it fails everything is just rolled back like the transaction never happened.

How this happens? Here is the magic of the blockchain, but in reality it is the same for any transactional system, even a centralized one. The code is executed in some sandboxed environment or better in a scope and a boolean success condition is evaluated. In case of success the transaction is sealed and inserted in the blockchain with the "new" state, otherwise is not.


Smart contracts are basically pieces of code where the author can write them in anyway they want, so how is it different from standard applications?

Yes. The author can write a smart contract in any way they want. However, in order to convince others to use the app, the code would have to be open, such that users can verify the smart contract will function as what it's claimed to.

The main difference from standard applications is, again, eliminating the need for a centralized third-party. Users don't have to trust a middleman that the application would be running as expected. This also helps to lower the transaction cost.


Expanding on longcc's answer.

Consider traditional software.

Alice and Bob have data and software and that software may be open or closed. Their software may have been consistently executed, or not. They may be using the same software, or not. They may have witnessed the same events, or not. They may have altered the data, or not. Their data may agree, or not.

The traditional solution to this problem is to rely on record keepers of one form or another. Alice & Bob can't be sure of anything without consulting Carol, and Carol is largely concerned with running a tight ship to maintain Alice and Bob's confidence in her records.

Consider a smart contract.

There is one source of data. This data is a shared set of facts the contract author thinks everyone needs to agree on at all times. The contract describes the only processes that will ever update the shared facts.

All transactions start with a signature. Someone signs a transaction and invokes a function in a contract. The contract function defines what must happen. The contract has no choice. It simply must run as written.

This forms an auditable description of history. All observers can agree on everything that happened. Since they can agree on everything that happened, they can also agree on the result.

Authority is potentially replaced by a process. This leads to some interesting design issues, often centered around what processes, exactly, need to be observed without exception.

Practical Example.

A contract can prevent counterparty failure. Start with two assets - something for sale, and something to trade. Both need to be represented by assets on a blockchain as a precondition.

A contract can function as a simple escrow that briefly takes possession of both assets. When both parties are seen to have delivered what they promised, ownership of both assets is transferred. If the contract expires before one of the parties fulfills their side of the trade, then everything is returned to original owners.

A contract can be written so there is no practical possibility of either party being cheated.

Hope it helps.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.