What Can We Learn from the US Blockchain Reference Architecture?
This article analyzes the US‑submitted blockchain reference architecture, outlines its six‑layer design, and offers practical guidance for domestic blockchain architects on infrastructure, security, data services, ledger, development tools, and interoperability.
In recent years, the United States has made continuous breakthroughs in FinTech, especially in blockchain, with major IT and financial firms creating alliances such as Hyperledger, R3, and EEA, and launching open‑source projects that have been piloted in finance, government, insurance, healthcare, IoT, supply chain, and ICT.
To promote blockchain development while mitigating emerging risks, industry standards are urgently needed. In this context, the Ministry of Industry and Information Technology’s China Electronics Standardization Institute led the drafting of the “Reference Architecture for Blockchain and Distributed Ledger Technologies” standard.
The author, who participated in the ISO/IEC TC307 blockchain international standards meeting (April 3‑5), provides a brief analysis of the US‑submitted blockchain reference architecture and reflects on its design philosophy for domestic reference architecture.
1. Position of the Reference Architecture
(1) Describe blockchain and distributed ledger technology in plain language.
(2) Present an ideal prototype structure for the technology.
(3) Define the scope of standards applicable to blockchain.
2. Perspectives of the Reference Architecture
The architecture can be viewed from business, legal, or technical perspectives.
a) Business view: a network that enables value, asset, or entity transfer among mutually recognized participants.
b) Legal view: transactions on the ledger are verified, non‑repudiable, immutable, and do not require intermediaries.
c) Technical view: a distributed ledger that replicates ledger data across nodes.
3. Design Philosophy
From the viewpoint of distributed‑application architects and developers, a blockchain platform reference architecture is proposed (see figure).
Figure 3.1 – One design of a blockchain platform reference architecture.
The architecture consists of six layers: Infrastructure, Security, Data, Ledger, Development, and Distributed Application.
(1) Infrastructure Layer
It comprises a set of server nodes that run the distributed ledger and should exhibit cloud‑computing characteristics such as virtualization and scalability. The reference architecture stresses that the ledger must not rely on a single infrastructure provider; in consortium‑chain scenarios, multiple cloud providers should be used, which poses a challenge for domestic enterprises that often prefer a single public‑cloud or private‑cloud provider.
(2) Security Layer
Security management includes identity management, permission control, and pluggable cryptographic services.
Identity management – maintaining digital identities for different roles in the blockchain network.
Permission – access control based on contracts, users, or blockchain levels, supporting hierarchical governance and regulatory compliance.
Pluggable cryptographic services – allowing users to select and upgrade encryption algorithms to address future threats such as quantum‑computing attacks on ECDSA.
(3) Data Layer
The data layer is standardized and provides three major services:
Secure (trusted) data access – enabling distributed applications to store and query data safely.
Cross‑chain services – allowing smart contracts to exchange data between blockchains.
On‑chain / off‑chain services – securely accessing off‑chain data via trusted sources or certification techniques.
(4) Ledger Layer
Distributed ledger – a verified, consensus‑based transaction record shared among all nodes.
Pluggable consensus services – letting users choose appropriate consensus algorithms for their use cases.
(5) Development Layer
Smart‑contract services – integrating data‑management logic, business rules, and contract terms into distributed applications, with support for multiple programming languages.
Development tools – for writing, testing, deploying, and monitoring distributed applications.
SDKs / APIs – simplifying access to the ledger, smart contracts, and other services.
Programming interfaces – enabling external systems to interact with smart contracts and platform data.
Summary
From a developer’s perspective, the reference architecture aims to enable blockchain interoperability, trusted data exchange, modular enterprise‑grade design, open IaaS, and cross‑platform portability. Most mainstream blockchains and distributed ledgers are built with Go or JavaScript, making platforms that support these languages advantageous.
Design Guidance for Blockchain Architects
Select blockchain or distributed ledger technology when the business requires added trust.
Implement identity management with a weak‑centralized authentication hub (e.g., sovereign IDs).
Adopt secure data‑access services that meet global sharing requirements.
Provide cross‑chain services to enable fine‑grained sub‑chains and parent‑child smart contracts.
Offer on‑chain/off‑chain data access to integrate with traditional databases.
Ensure smart‑contract services are portable across multiple blockchain platforms.
Expose familiar APIs for traditional developers to call smart‑contract functions.
Source: http://www.infoq.com/cn/articles/technology-selection-as-blockchain-architector
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
ITFLY8 Architecture Home
ITFLY8 Architecture Home - focused on architecture knowledge sharing and exchange, covering project management and product design. Includes large-scale distributed website architecture (high performance, high availability, caching, message queues...), design patterns, architecture patterns, big data, project management (SCRUM, PMP, Prince2), product design, and more.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
