Distributed ledger technology enables multiple network nodes to maintain and update their own copies of a ledger, using shared rules to coordinate record order and state. A blockchain is a type of distributed ledger, but not every distributed ledger organizes data as a blockchain.
The underlying mechanism is not a secret piece of code. It is the combination of replication, verification, ordering, and consensus that solves a central problem: without a single database administrator, how can participants form a consistent and verifiable view of the same history?

Participants first submit transactions or state updates to the network. Nodes check whether each transaction complies with identity, signature, and business rules. An ordering service or consensus protocol then determines the processing order. Valid results are committed to each node's local copy, allowing the copies to converge on a consistent state under normal operation.
Consistency here does not mean that every node is identical at every millisecond. Network propagation takes time, and nodes may temporarily go offline. Distributed systems instead focus on how to identify valid updates, resolve conflicts, and ultimately reach a consistent result within the system's tolerated range of faults and delays.

| Comparison | Centralized database | Distributed ledger |
|---|---|---|
| Write control | Usually determined by one organization or administrator | Determined by member permissions and consensus rules |
| Data copies | May use primary-replica replication, but remains centrally managed | Multiple participating nodes maintain verifiable copies |
| Conflict handling | Managed through database and administrative policies | Managed through protocols, ordering, and consensus mechanisms |
| Auditing | Relies on permissions, logs, and organizational processes | Can combine signatures, hashes, and shared history for verification |
| Main costs | Central operations and disaster recovery | Repeated validation, communication, consensus, and governance |
Conventional distributed databases can also replicate data across multiple machines and are often faster. Distributed ledgers focus more specifically on whether nodes operated by different organizations can verify updates under shared rules. The number of servers alone does not determine whether a system is a distributed ledger.
No. Distributed describes components deployed across multiple nodes. Decentralized describes control that is not concentrated in a single entity. Permissionless means participation does not require prior approval from an administrator.
A consortium ledger can be distributed across several institutions while allowing only approved members to write. A public blockchain may allow anyone to submit transactions while validation power remains concentrated among a small number of entities. When analyzing a system, examine node deployment, identity admission, validation authority, and upgrade authority separately.
A blockchain groups transactions into blocks and links them in sequence using the hash of the preceding block. Nodes accept new blocks according to consensus rules and store or verify this chain of history. This data structure makes historical changes easier to detect and provides a clear basis for transaction ordering.
Other distributed ledgers may use directed acyclic graphs, event logs, or different state-replication structures and may not have traditional blocks at all. DLT and blockchain therefore are not interchangeable in every context. For a complete overview of blockchain components, see What Is Blockchain?.
Consensus primarily determines which updates are valid, the order in which they are committed, and which history nodes should select when different candidates exist. Proof of Work, Proof of Stake, and Byzantine fault-tolerant protocols have different participation requirements and fault assumptions; they cannot be reduced to simple voting.
Consensus also cannot guarantee that input data is true. If an authorized participant submits incorrect real-world data to the chain, the network may consistently record that error. Data sources, oracles, and member governance still require separate controls.
If all writes are controlled by one organization and other participants do not need independent verification, a centralized database with audit logs may be more suitable. A distributed ledger is not the default upgrade from a database; it is an architectural choice designed for multi-party coordination problems.
To continue learning how a ledger receives a transaction, read How Does Blockchain Work?.
Not necessarily. Full nodes, light nodes, and archive nodes store different amounts of data, and permissioned networks may divide ledgers by channel or access rights. Whether a node can verify independently depends on the data it holds and the verification method it uses.
No. Multiple copies can improve availability, but client gateways, ordering services, cloud providers, key-management systems, or governance committees may still become single points of failure. Each component must be assessed against the system's actual topology.
It depends on the protocol. Some systems temporarily stop finalizing updates, while others allow different candidate histories to coexist briefly and later converge according to fork-choice rules. Applications should understand the trade-off between consistency and availability.
Instead of directly overwriting committed history, a system will usually append a correction or reversal transaction. Permissioned networks may also define administrative operations, but these depend on specific governance rules and cannot be inferred solely from the term distributed ledger.


