· IndieSquare · Updated
About 8 minutes to read
What is blockchain? Start with a shared ledger
Blockchain groups records into linked blocks that multiple computers share and verify. A transaction can represent a payment, but it can also represent a transfer of rights or another change in state.
NIST describes blockchain as a distributed digital ledger with tamper-evident and tamper-resistant properties. A useful starting point is a history that stakeholders can examine under common rules.
Bitcoin is one application. Distinguish the underlying technology from crypto-assets, services and business models built around it. Adopting blockchain does not necessarily mean starting a cryptocurrency trading activity.
An everyday example: three companies tracking equipment
Imagine an equipment owner, a user and a management company keeping separate spreadsheets. Each contract amendment or change in start date requires messages and checks to reconcile their copies.
A shared ledger can record who requested a change, whether the required approval was obtained and the order in which changes were accepted. Blockchain is one way to construct such a ledger.
A jointly managed database might also solve this problem. Before choosing, ask whether the organizations need to verify records independently and whether an acceptable central administrator exists. This example and those below are illustrations of the design choices, not deployed customer systems.
From a request to a shared record
Consider a request to transfer tokens from Company A to Company B. A single button in the application can initiate several underlying steps. The sequence below is conceptual; exact roles and ordering vary between networks.
“Submitted” is not the same as “confirmed enough for the next business action.” Showing pending and confirmed states helps people avoid duplicate submissions or acting prematurely.
A node is a computer participating in the network to exchange or verify data. Different types of nodes retain different information and perform different tasks.
From a submitted request to a shared record
- Submit
Specify the recipient and amount, then sign and send.
- Validate
Check the signature, balance and permissions.
- Agree
Decide which valid records to accept and in what order.
- Share
Participating nodes update their history.
- Request: prepare the recipient and quantity, authorize the operation with the required signature and submit it.
- Validation: check formatting, signatures, balances and permissions against the network’s rules.
- Agreement: use the defined mechanism to establish which valid records are accepted and in what order.
- Sharing: participating nodes reflect the accepted history, and the application reads the result.
Blocks, hashes and consensus in plain language
A block groups records and related information. A hash is a fixed-length value calculated from data, somewhat like a content fingerprint. Changing the data generally changes the result, helping detect differences. Hashing is not encryption and does not establish whether information is true.
Blocks refer to preceding blocks through hashes and other information. Altering history produces inconsistencies in those links. Hashes alone do not protect a ledger: validation, consensus and the network’s participants also matter.
Consensus establishes a shared accepted history. Examples include proof of work, which uses computational work; proof of stake, which uses staked assets in its validator arrangements; and approaches using approved participants. Finality, capacity and operating requirements differ.
Each block references the previous block’s hash
- Block 1
A group of records
- Previous block’s hash
- …
- This block’s hash
- A1
- Block 2
The next group of records
- Previous block’s hash
- A1
- This block’s hash
- B2
- Block 3
A further group of records
- Previous block’s hash
- B2
- This block’s hash
- C3
How does it differ from an ordinary database?
The useful comparison concerns who manages and verifies records, rather than which technology is newer. Databases can also have replication, audit logs and detailed access controls. Blockchain is not the only way to share information.
A conventional database can be suitable for customer information managed by one organization or records requiring frequent updates. Blockchain becomes an option when multiple organizations find value in independently verifying a common history.
| Question | Conventional database | Blockchain |
|---|---|---|
| Who manages updates? | Administrators operate permissions and update rules | The network applies validation and consensus rules |
| How are corrections made? | Updates and deletion can be designed around permissions | Corrections are generally appended rather than rewriting history |
| How is information shared? | APIs (interfaces between systems), replication and logs | Nodes verify history according to common rules |
| What drives cost and performance? | Infrastructure and processing requirements | Also consensus, network fees and node operation |
| When might it fit? | Often when an accepted administrator can manage the process | When independent verification by several parties has value |
Public and permissioned networks
A public network generally allows broad participation. A permissioned arrangement restricts who may participate in functions such as validation or operation. A network operated by several organizations may be called a consortium network.
Reading, writing and validating are separate permissions. A permissioned network does not necessarily mean every participant should see every contract. A token on a public network can also have restrictions on who may receive it.
Look beyond the labels. Define how organizations join and leave, who holds administrative powers, how outages and costs are handled, and how rule changes are agreed. If one company operates the service, identify the dependency that remains on that company.
Tokens, wallets and private keys
A token is a digital unit whose balance or holder can be recorded. A wallet is software or another tool for managing addresses and keys, viewing holdings and authorizing requests. It is not a container holding physical coins.
A private key is sensitive information used to authorize operations. A signature can be checked to establish authorization by that key. It does not by itself establish the real-world company name or the employee’s business authority; those need separate controls.
Decide who safeguards keys, how access changes when an employee leaves and whether approval should be split between people. A model in which users do not handle keys directly still needs a clear operator and allocation of responsibility.
What can smart contracts automate?
A smart contract is a program that changes blockchain state according to defined rules. It can express conditions for accepting a request or calculating quantities from holdings. Despite the name, code is not automatically a legally enforceable contract document.
For example, once a monthly distribution amount and holdings are established, a program can calculate allocations. Participants can examine results based on common rules. Assessing an invoice’s validity or interpreting ambiguous contractual language remains a separate task.
Automation can repeat errors too. Review specifications and test them, define when processing can be suspended, identify who authorizes a correction and establish how to retry safely. Making an actual bank payment may require integration with another system.
Why input data still needs verification: oracles
A record remaining unchanged does not prove that the event it describes actually happened. An incorrect statement that a machine operated for ten hours can remain faithfully recorded.
An oracle connects external information with on-chain processing. It may supply prices, payment information or operating data. It does not automatically guarantee the truth of the information it supplies.
In the equipment example, distinguish raw sensor readings, operating time confirmed by a manager and billable time under the contract. Decide which value drives distributions, who approves it and how a correction is documented. The data connection and the verification process must be designed together.
Verify real-world data before using it on-chain
- Equipment and systemsSource data
Sensor readings or payment information.
- Responsible operatorVerify
Reconcile contracts and billing; approve the input.
- Data connectionOracle
Deliver the checked external data to the application.
- BlockchainRecord or calculate
Apply the defined rules to the received data.
Source: ethereum.org: Oracles
Which records matter for RWA and physical AI?
An RWA arrangement can involve represented rights, holder changes, distribution criteria and results. Physical AI equipment can introduce the need to connect robot operation with contracts and invoices. Combining them does not require putting every piece of data on a blockchain.
Video and detailed sensor streams could stay in operational systems, while stakeholders share equipment IDs, verified summaries and references to supporting evidence. Personal information and confidential contracts require separate decisions about access and retention.
Recording a hash is not a substitute for retaining the original data. Without the original, the content cannot be re-examined. Assign responsibility for source records, formats, access and backups. Blockchain also does not replace robot control or safety mechanisms.
| Information | Storage to consider | Shared-record questions |
|---|---|---|
| Contracts and customer information | Restricted business systems | Which references and approvals are needed? |
| Video and raw sensor data | Equipment and operational data systems | Which IDs, summaries and evidence are appropriate? |
| Rights, holdings and transfers | The selected ledger or blockchain | Identity, permissions, order and transfer restrictions |
| Invoices and bank receipts | Accounting and payment systems | Has reconciliation occurred, and who verified it? |
| Distribution results | Operational systems and shared records | Calculation conditions, execution status and corrections |
Costs and operating work that are easy to miss
Software development is only part of the cost. Include integration, permissions, node or service usage, monitoring, key management and support. Some networks also charge per transaction.
A design that does not require the user to pay gas, a network processing fee, directly is not cost-free to operate. Examine costs at higher usage levels and identify who pays. Software updates and acceptable maintenance windows are business requirements too.
Test congestion, delays, retries, duplicate requests and outages in connected systems, not just average processing time. Evaluate whether staff can understand the system’s state and operate it reliably, alongside whether the technology functions.
Frequently asked questions
Replace absolute claims with questions that can be answered for a particular system.
Is blockchain impossible to alter?
No absolute guarantee applies. Resistance depends on consensus, participants, keys and administrative powers. Application defects and false input are separate problems.
Does everyone in the world see all the information?
That depends on the architecture. Define read, write and validation permissions, and distinguish information held off-chain. Confidential information on public networks needs particular care.
How is an incorrect record corrected?
Many designs append a correction or cancellation instead of deleting history. Link the correction to the original record so the application can show the currently valid state.
Does every blockchain use large amounts of electricity?
Energy use varies with the consensus mechanism and infrastructure. Computational competition differs from processing by approved validators. Do not generalize one network’s characteristics to all others.
Should a company replace all its databases?
Assess each process. Identify where multi-organization sharing and verification are needed, then define the relationship with existing systems.
A checklist for starting a business discussion
A one-page description of what you share, with whom and why is usually more useful than a list of technologies. Establish today’s process and difficulties before deciding whether blockchain is necessary.
IndieSquare explores RWA issuance, distributions, operational records and integration with existing business processes. The hazBase and HAZAMA pages explain our platform approach, technology and patent information. Architecture and service scope are defined against each project’s requirements.
- Separate shared information from data that remains within the organization.
- Identify the people requesting, approving and checking updates.
- Compare a database or API integration as an alternative.
- Plan corrections, access changes, lost keys, suspension and recovery.
- Use a limited dataset to measure reconciliation time, failed processing and staff work.