A decentralised application, or dApp, can look just like any other website. It may have buttons, forms, charts, and a familiar login screen. The difference is not mainly visual; it lies in where the important rules and records live.
A typical dApp has three layers. The frontend is the website or mobile interface. A wallet connects the user’s account and signs instructions. Smart contracts on a blockchain hold the shared state and enforce the core rules. The interface might say Swap, but the contract determines what assets move and under which conditions.
Reading from a dApp can be almost invisible. The website asks a node for contract data and displays balances or prices. Writing is different: changing blockchain state requires a transaction. Your wallet shows what is being requested, you sign it, the network executes it, and gas is paid even if the transaction later fails.
Decentralisation is not an all-or-nothing label. A contract may be immutable while its website is hosted by one company. Its data may depend on a centralised server, or an administrator may retain an upgrade key. A useful evaluation asks which parts can be censored, changed, or switched off—and by whom.
Wallet-based access removes the need to create a new username and password for every service, but it changes the security model. A signature can authorise a harmless login, a token approval, or a valuable transfer. Users must understand the request because there may be no support desk capable of reversing a mistaken signature.
Good dApps make these boundaries clear: they show contract addresses, transaction details, risks, and the source of external data. Open contracts can be inspected and reused, but open code does not mean bug-free code. Audits help; they never turn software into a guarantee.
One puzzle remains. A smart contract can read blockchain data, but how can a lending app learn the rupee price of ether or whether it rained in Delhi? Tomorrow we meet the bridge called an oracle.
An ordinary token is designed so that one unit can replace another. An NFT does the opposite: it gives each item a distinct identity. NFT stands for non-fungible token, and its most important feature is usually a unique token ID recorded by a smart contract.
Think of cinema tickets. Two tickets may have the same price, but seat A1 is not the same as seat F12. An NFT contract can record that wallet 0xABC owns token number 42, while another wallet owns token number 43. Transferring the NFT updates that ownership record on the blockchain.
The artwork, video, or document associated with an NFT is often not stored directly on Ethereum because large files are expensive to keep on-chain. The token usually points to metadata, and that metadata may point to a file on IPFS or a conventional server. This distinction matters: the blockchain can preserve the ownership record while the linked media may still depend on outside storage.
Owning an NFT also does not automatically mean owning the copyright. A token can prove that a wallet controls a particular on-chain item, but intellectual-property rights depend on the licence or agreement provided by the creator. Buying a digital collectible is not necessarily permission to reproduce its artwork commercially.
NFTs can represent more than profile pictures. They can act as event tickets, game items, membership passes, certificates, or records tied to physical goods. Whether blockchain adds value depends on whether public transferability and shared verification are actually useful for that case.
The risks are familiar but easy to overlook: copied artwork, misleading collections, malicious approvals, changing metadata, and thin markets. A visible image is not proof of authenticity. Users should verify the contract address, collection history, storage method, and permissions they are signing.
A token can therefore become a portable piece of state that many applications recognise. Tomorrow, let us examine those applications themselves: what makes a dApp decentralised when its website can still look completely ordinary?
Open a crypto wallet and you may see ether, stablecoins, governance tokens, and dozens of other assets. It is natural to assume that every token runs on its own blockchain. In reality, many of them are programs living on an existing network such as Ethereum.
A token is usually a smart contract that maintains a ledger. The contract records how many units each address owns and contains rules for transferring those units. When Priya sends ten tokens to Arjun, no separate coin travels through the internet. Ethereum executes the token contract, subtracts ten from Priya’s recorded balance, and adds ten to Arjun’s.
Most fungible Ethereum tokens follow a common interface called ERC-20. It specifies familiar actions such as checking a balance, transferring tokens, and allowing another contract to spend a limited amount. Because wallets and exchanges understand the same interface, a newly created token can be displayed and handled without every application learning an entirely new language.
Fungible means one unit is intended to be interchangeable with another, like one ₹10 coin for another ₹10 coin. Such tokens can represent voting power, access to a service, a claim on collateral, or simply a speculative asset. The code defines the mechanics, but it does not guarantee that the story or value behind the token is genuine.
Creating a token is easy; trusting one is not. Two tokens may share the same name and symbol, so the contract address is the reliable identifier. Before interacting, it is worth checking who can mint more supply, pause transfers, blacklist addresses, or upgrade the contract. Those permissions can matter more than the logo.
Token transfers also use the underlying network. On Ethereum, users still need ether to pay gas even when they are sending a different token. The token depends on Ethereum for ordering, security, and execution; it is not an independent blockchain.
But what if every unit should not be identical? Tomorrow we will look at NFTs, where ownership is tracked by a unique token ID rather than only by a quantity.
Bitcoin and Ethereum both move value, but they keep score in very different ways. Bitcoin uses unspent transaction outputs, usually called UTXOs. You can imagine them as digital notes in your wallet: if you own a ₹500 note and want to pay ₹300, the whole note is spent and a new ₹200 note comes back as change.
Ethereum uses an account-based model. Instead of tracking separate notes, the network maintains a shared map of accounts and their current state. An account can hold ether, and the balance changes when a valid transaction is processed. This feels closer to a bank ledger, although no bank controls the ledger.
There are two main kinds of Ethereum accounts. An externally owned account is controlled by a private key—the kind your wallet creates for you. A contract account is controlled by code deployed on Ethereum. Both have addresses and can hold ether, but only an externally owned account can begin a transaction by signing it.
An externally owned account stores a balance and a nonce. The nonce counts how many transactions that account has sent, which helps the network reject replayed or duplicated transactions. A contract account can additionally hold code and persistent storage, allowing it to remember rules, balances, votes, loans, or almost any other structured state.
Suppose Rahul sends one ether to Sneha. Ethereum does not search for a uniquely numbered coin and move it. Validators check Rahul’s signature, balance, nonce, and gas, then reduce Rahul’s balance and increase Sneha’s. Every node applies the same state transition and arrives at the same updated ledger.
This model makes smart contracts practical. A lending contract can remember deposits and debts; a game can remember who owns an item; a token contract can maintain thousands of balances. The trade-off is that this growing shared state must be stored and verified by the network, so storage is deliberately expensive.
That leads to a surprising question for tomorrow: if your wallet shows ten different tokens, are those ten separate blockchains—or are they entries inside smart contracts on Ethereum?
A crypto wallet looks a little like a banking application, but the similarity can be misleading. The wallet does not contain coins, and a blockchain does not keep a private password database for its users. What the wallet protects is a cryptographic secret that allows its owner to authorise changes on the public ledger.
This secret is called a private key. From it, software can derive a public key and an address that other people may safely know. When you send ether or interact with a smart contract, the wallet uses the private key to create a digital signature. The private key itself does not leave the wallet. The signature travels with the transaction.
A digital signature acts like a seal tied both to the signer and to the exact message being signed. Ethereum nodes can use public information to verify that the signature could only have been produced by the corresponding private key. If even one detail of the transaction changes, the old signature will no longer match.
This gives the network proof without requiring identity. Ethereum does not need to know your name, email address or face. It needs to know that the holder of a particular key approved a particular instruction. Control of the key therefore becomes control of the account, which is why ‘not your keys, not your coins’ is more than a slogan.
Wallets often represent the key through a recovery phrase made from a list of words. That phrase can recreate the wallet’s keys, so anyone who obtains it may gain the same control as the owner. There is usually no central help desk capable of reversing the theft. A wallet interface can be replaced; a compromised recovery phrase cannot be made secret again.
Signatures remove the need to share passwords with every application, but they create a new responsibility: understanding what is being signed. A malicious website may ask for approval that looks harmless while granting broad control over tokens. Good wallet security includes reading transaction details, limiting approvals and keeping recovery information offline.
Now we can prove who authorised a transaction. But what exactly does an Ethereum account own? Bitcoin speaks about individual unspent outputs, while Ethereum often shows a simple balance. The two systems organise ownership in very different ways.
We now know that Ethereum nodes repeat the instructions inside a smart contract so that the network can agree on one result. That shared execution creates a new problem. Computation is not free. If anybody could ask every node to perform unlimited work, a careless program or an attacker could keep the network busy forever.
Ethereum solves this with gas. Gas is a unit used to measure the amount of computational work a transaction requires. Adding two numbers costs a small amount. Reading or changing stored data costs more. Deploying a large smart contract may require much more. Gas is not a separate coin; it is the meter that counts the work, while the fee is paid in ether.
Think of it like taking a taxi. Distance is not money, but it helps calculate the fare. In the same way, gas measures the journey through a program. A user sets a limit on how much gas the transaction may consume. If the contract finishes within that limit, unused capacity is not charged. If it runs out, execution stops so that the program cannot consume resources endlessly.
The final fee also depends on what the network is charging for each unit of gas. When many people want their transactions included, block space becomes more competitive and fees can rise. A user can also offer an additional priority fee to encourage faster inclusion. This is why two identical actions performed at different times may cost different amounts.
Gas protects the network, but it can surprise beginners. A transaction that fails may still consume a fee because nodes already performed work before discovering the failure. Paying for computation does not guarantee that the intended result will succeed; it pays the network for checking and executing the attempt.
This system turns computation into a scarce resource and discourages spam. It also explains why developers try to write efficient contracts and why scaling Ethereum matters so much. Before we reach scaling, however, we need to understand who is authorising these paid instructions.
When a website sees a password, it asks a company’s server whether the password is correct. Ethereum has no such account desk. So how can a wallet prove that a transaction truly came from you without sending a password to the network? The answer lies in digital signatures.
Yesterday we described Ethereum as a blockchain that can hold both value and logic. That description sounds impressive, but it also hides a practical problem. A program cannot execute itself. On a normal website, code runs on a server owned by a company. If Ethereum has no central server, which computer actually runs a smart contract?
The answer is not one special machine. Ethereum defines a small, standardised computing environment called the Ethereum Virtual Machine, usually shortened to the EVM. Developers write smart contracts and compile them into instructions that the EVM understands. Those instructions are stored on the blockchain along with the contract’s address and data.
A useful way to imagine the EVM is as a calculator whose design has been copied onto thousands of computers. Give every copy the same starting numbers and the same operation, and each should produce the same answer. When someone sends a transaction to a smart contract, Ethereum nodes execute the relevant instructions and calculate the resulting changes. One node may be in Mumbai and another in London, but the rules of the virtual machine are the same.
The result is a shared state. This state includes account balances, contract storage and other information that Ethereum currently recognises as true. A transaction proposes a change to that state. The network checks the signature, executes the contract, and agrees on the new result before it becomes part of a block. A person cannot simply change the answer on their own computer because their version would disagree with everyone following the protocol.
For this agreement to work, the EVM has to be deterministic. The same input must always lead to the same output. A smart contract therefore cannot casually ask one computer for its local time, read a private file, or browse a website while it is running. Different machines might receive different answers. Contracts operate inside a controlled sandbox and can use only information supplied in a form the network can verify.
This repetition sounds wasteful because many computers perform the same work. In one sense it is. Ethereum deliberately trades ordinary server efficiency for independent verification. The benefit is that no single server owner can secretly change the program’s result, switch off the database or rewrite a balance. The cost is that shared computation is scarce.
That leads to the next question. If thousands of machines may need to check a computation, what prevents someone from submitting an enormous program or an infinite loop and making everybody work for free? Ethereum’s answer is a meter attached to every instruction: gas.
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.
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?
By this point a natural question has begun to arise in the minds of the reader.
If the Bitcoin system has no governing body, no bank, and no company running the show, then who is keeping the network alive and verifiable?
Initially, it may seem that there must be some unseen hand secretly orchestrating things. This is far from the case however, Bitcoin’s maintenance is achieved through a collection of independent actors, from all over the world, each with different roles and different motivations.
To properly understand this, we can break down Bitcoin participants into two key groups: nodes and miners.
Nodes are the bedrock of the Bitcoin network. A node is simply a computer running the Bitcoin software which keeps a full or partial copy of the blockchain. Every time a new transaction is broadcast, it is independently checked against the network rules by a number of nodes around the world. The checks are made to ensure that the sender has the correct balance to make the transaction, that the transaction is properly signed, and that the same bitcoins are not being spent again. If any of these checks fail, then the transaction is rejected.
What is fascinating about these nodes is that they gain no direct financial reward from checking transactions. This obviously begs the question why any individual would run a node at all.
The motivation comes from ownership and trust. A node allows an individual to not have to rely on another party to verify the validity of transactions. They are then able to check the state of the network independently to ensure it is being governed correctly. For people, and organisations, who may own a significant amount of bitcoin this independence provides value because they are able to receive the ‘truth’ directly rather than through a third party.
Thus, nodes act as the regulators of the network. They do not compete with each other or even necessarily know other participants, but they act to enforce the rules of Bitcoin. Any miner trying to submit an invalid block will find their attempt is rejected, no matter how much computational effort has gone into its creation, by nodes worldwide.
Miners on the other hand are a different story. Whilst they run nodes to verify transactions and are required to do so for the system to function, their goal is different: they need to collect verified transactions into a block to present to the network and receive bitcoins in return. The miners have to do this by solving the computationally intensive problem that was discussed previously.
Unlike nodes, miners do it for profit. They invest money in expensive computing hardware and have huge energy costs because the reward in Bitcoin and transaction fees is great enough to warrant such expenditure. This creates a competitive atmosphere, in which each miner will strive to be the first one to solve the computational puzzle in order to claim the next block.
It is important to realise here that it does not matter if an individual’s computer is the fastest, the geographically closest, or has the best internet connection to solve the problem. Mining is a contest for the solution to a particular problem where each miner submits a ‘guess’ for the solution; with no knowledge of other people’s attempts. If your ‘guess’ is correct you win. Hence the higher the computational power of the computer the higher the number of guesses you can make and the more likely your answer is to be correct. Obviously smaller players can sometimes win as there is an element of chance involved.
This leads us to an elegant balance in the network. Miners work hard to generate the coins and the rewards give them an incentive to spend a vast amount of energy. This in turn creates new blocks and transaction fees, but the network can still function with nodes even without them getting direct payment; their role is purely validation. Neither of these two groups controls the network and as long as people have an incentive, both miners and nodes will continue to exist and maintain the system.
This is the process by which Bitcoin can exist without a central bank and without a managing body, by distributing power and by making money out of being involved with the system. But as a reward is given for mining a block, this suggests that a small amount of powerful actors will dominate the network. How will this impact the overall decentralization?
