Blockchain technology: 7 features you should know about

A blockchain network maintains shared records under validation rules. Its properties depend on the protocol, participants and permissions. Assessing a project means asking how each property is implemented, rather than assuming every chain offers the same capabilities. The assessment should also explain how the system responds when participants disagree about the state of the ledger.

1. Replicated records

Multiple nodes retain and verify network information, allowing records to be checked without relying exclusively on one copy. This does not mean every node stores identical historical data or every application has the same availability.

Identify which nodes the client can operate, which information it needs to retain and how service would recover after an access provider fails. Protocol distribution does not eliminate an application's single points of failure.

2. Shared consensus rules

Consensus agrees the order and validity of operations under network rules. It does not prove that an input from the physical world is true. A false certificate can be recorded consistently if its origin is not checked.

Ethereum's consensus overview distinguishes the purpose of consensus from its implementations. Participation and finality conditions need assessment on the particular network.

3. Cryptographic integrity

Signatures provide evidence of authorisation associated with keys, while hashes help detect changes. This is useful for checking documents or sequences of operations. It does not, by itself, prevent stolen keys, contract bugs or incorrect inputs.

Practical questions include who holds keys, how accounts recover and which controls apply before signing. A sound algorithm does not compensate for a poorly defined operating process.

4. Traceability

A shared history supports tracking state changes and reconstructing operations. Its usefulness depends on having identifiers, events and enough data to interpret them. Linking a token to a physical product requires additional controls over that association.

Define what an audit must establish and how long supporting documents will remain available to explain each record.

5. Transparency with privacy boundaries

Public networks expose much of their activity; permissioned networks can restrict access and participation. Hyperledger Fabric, for example, uses identities and policies to determine who can act on the network.

Publishing data does not make it anonymous. Personal or confidential information needs a specific architecture: minimise what is recorded and keep information off-chain when it must be corrected, restricted or deleted.

6. Resistance to historical changes

Confirmation and finality help explain the cost and conditions under which accepted history might change. “Immutable” should not be read as an absolute guarantee independent of consensus, governance or network security.

History and application logic are also different layers. A system may preserve past transactions while allowing its implementation to be upgraded under defined permissions.

7. Explicit operating costs

Network use consumes resources and may require fees. There is no universal property of free transactions or permanently low costs. Ethereum gas measures execution work; its price and the operation performed influence the amount paid.

Compare infrastructure, fees, integration, support and compliance together. A suitable network meets the use case's requirements with understandable costs and responsibilities. At Metlabs, this guides our blockchain solution design.