blog.alankrit.net

Tag: bitcoin vs ethereum

  • Day 8 — What If Money Could Follow Instructions?

    A smart contract running on a blockchain as a shared programmable agreement

    Yesterday, we reached a boundary in Bitcoin’s design. Bitcoin is exceptionally good at recording ownership and moving value without a bank, but its rules are deliberately narrow. It can answer questions such as “Does this person own these coins?” and “Has this money already been spent?” What if a blockchain could answer a more interesting question: “Should this money move only when a particular condition becomes true?”

    Imagine that you and your friend Rahul make a small bet on a cricket match. Ordinarily, one of you would hold the money, or both of you would trust a third person to pay the winner. That third person could disappear, take a fee, choose a side, or simply make a mistake. Now imagine placing the money inside a transparent digital box. The box contains a rule: after the match ends, release the entire amount to whoever won. Nobody can quietly change the rule, and the box does not need to like or trust either person.

    This is the basic idea behind a smart contract. A smart contract is a small program stored on a blockchain. It receives information, checks the rules written into its code, and changes the blockchain’s state when those rules are satisfied. It can hold digital assets, send them, exchange them, or record a result. Once deployed, the same program is visible to the network and every participant can verify what it is supposed to do.

    The name can be slightly misleading. A smart contract is not necessarily smart, and it is not automatically a legal contract. It does not understand intention, fairness, or the spirit of an agreement. It follows instructions. If the code says that money should move after a certain digital signature appears, then that is the condition it checks. It behaves less like a lawyer and more like a vending machine: provide the required input, and a predictable output follows.

    Bitcoin already has a limited scripting system, but it was intentionally designed to remain simple and cautious. In 2015, Ethereum took a broader approach. Instead of building a blockchain mainly around one kind of digital asset, Ethereum was designed as a shared platform on which developers could publish many different programs. Its native currency, ether, is used to pay for activity on this network, but the larger idea is that the blockchain can store both value and logic.

    That small change opens a surprisingly large door. A lending program can release funds when enough collateral has been deposited. A marketplace can exchange a token and a payment in one operation so that neither side has to move first. A group can keep funds in a shared treasury that only moves after several members approve. A game can record ownership of an item outside the company that created it. Each of these systems can be built from smart contracts that interact with one another.

    Applications built in this manner are usually called decentralized applications, or dApps. They may still look like ordinary websites on the surface. There can be buttons, forms, profiles and colourful dashboards. The difference lies underneath. Instead of sending every important instruction to one company’s private server, the application sends transactions to smart contracts on a public network. The rules and resulting changes can be independently checked.

    This does not remove trust completely. It changes where trust is placed. Users no longer need to trust a company to follow hidden database rules, but they must trust that the public code was written correctly. A mistake in an ordinary website can often be repaired quietly by an administrator. A mistake in a smart contract can be much harder to undo, particularly if the program controls valuable assets. Transparency helps people inspect the rules, but visible code is not the same as flawless code.

    There is another puzzle. If a smart contract is a program, some computer must run it. A normal application usually has a server owned by one company. Ethereum claims to run programs without giving one server or one company control. Does every computer execute every instruction? Who decides the result, and what prevents someone from changing it on their own machine?

    To answer that, we need to look inside Ethereum’s shared computer: the Ethereum Virtual Machine.

  • Day 7 — If a Few People Control Mining, Is Bitcoin Still Decentralized?

    It might look like, from what has been discussed up to now, that Bitcoin is the perfectly balanced, fair and secure system. All transactions are verified by nodes, the miners compete to get their blocks added and their block reward, and this mechanism seems to keep the entire system running without anyone controlling it. But, if we look a little deeper, a problem can be spotted. The mining is a not easy operation. Specialized hardware and a lot of electricity is required for a process that, over time, becomes very competitive and exclusive. This begs the question, if mining becomes too expensive, won’t a small group of powerful miners take over?

    We can analyze the history of Bitcoin mining to understand how this came to be. When the Bitcoin system was launched, ordinary computers were enough for the mining activity. Everyone was able to run mining software on their PC and, eventually, gain a prize in BTC. Over time, with more participants involved, the difficulty of the cryptographic puzzle used to add blocks grew considerably. This made mining equipment very specialized and increasingly efficient machines, dedicated only to the Bitcoin mining. Gradually, mining went from a fun activity, or an extra income opportunity, to an industrial, large scale production process.

    As the race to mine bitcoins became more competitive, miners started to gather together, forming what are called “mining pools.” A mining pool consists of several miners who combine their computing resources and cooperate to solve the puzzle and achieve the mining of a new block. By pooling resources together, miners reduce the variability in their revenue, and can be paid more frequently than they could achieve alone. All mining pool members share the same amount of computing power that the pool has. When a block is successfully mined by the mining pool, the bitcoins obtained by that block reward are distributed proportionally among the members who provided the computer power.

    However, as more people join mining pools, we again see a problem: an increase of centralization of mining power. In fact, a single mining pool can easily possess a huge share of the Bitcoin network hash power and thus the capability of influencing the selection of the transactions to include into the block, or worse, the capability of launching a 51% attack on the network. An attack based on the 51% of the network computational power can even enable a user to rewrite the recent history of the Bitcoin block-chain. Fortunately enough, it’s nearly impossible to achieve a 51% attack due to its extreme cost. But the threat is still there and that might represent a weakness for the Bitcoin system itself.

    Although this tendency towards centralization does not completely ruin the system it must be said that, in fact, Bitcoin cannot become a centrally controlled system by few mining pools since any node of the network, no matter if he is a mining pool participant or not, is able to decide whether to consider a block valid or not, and if one mining pool starts to mine invalid block (by trying to fork the chain, for example) all the other nodes are supposed to stop mining it and continue to build up on a valid chain.

    We can thus observe that Bitcoin is a resilient system, resistant to external control thanks to the mechanism of independent nodes which validates blocks and miners which compete against each other. While the efficiency argument may make you think that Bitcoin could easily become a system controlled by few large organizations, its fundamental principles as well as economic reasons assure the decentralization that was at the heart of the project.

    This reveals us something important about Bitcoin. Despite the strength of its core design, it’s a system built to serve a purpose: transferring and storing value. As such, it does not support complex processes such as programmable agreements or distributed applications.

    The existence of such limitations opens a new question: would it be possible for the blockchain to do more than simply transfer value? Could it be used as a development platform to automate logic and build applications?