You are here. See how this question connects to other ideas.
Select a node to open its page · Expand to read within the map
One question
From cryptography to blockchains: a history
Follow public-key cryptography, digital cash and blockchains through the evolution of applications, identity and resource access.
Blockchains combined ideas from cryptography, digital cash and distributed systems, then raised further questions about applications, identity and usability. This timeline starts from Chapter 2 of Blockchain in Practice, checks the historical sources and continues beyond the book’s publication.
ArcBlock product milestones appear alongside industry events to show how we approached these questions. Proposals, standards and product releases are different kinds of progress; each stop links to its sources.
1970s · 1980s · 1990s · 2000s · 2010s · 2020s
1976 · Public-key cryptography: a key you can share
How can two people communicate securely without first meeting to exchange a secret? Diffie and Hellman brought public-key cryptography into open research. Their paper also described a key-exchange method for establishing a shared secret over a public channel.
Digital signatures, later essential to blockchains, belong to this broader field. In a signature system, the holder keeps a private key to sign messages and shares a public key so others can check signatures. A signature lets someone check authorization by a corresponding private key. It does not prove that a claim about the outside world is true.
Diffie & Hellman · New Directions in Cryptography
1982 / 1983 · Blind signatures: privacy in payments
A bank does not normally see every person who later passes one of its paper notes along. Could digital payments preserve a similar kind of privacy? David Chaum proposed blind signatures: a signer can sign a blinded message, leaving a signature that can later be verified without directly linking it to the issuance process.
The work was presented at CRYPTO ’82; the proceedings appeared in 1983. This was an important tool for digital cash, but using it did not remove the need for an issuer or a way to prevent spending the same money twice.
Chaum · Blind Signatures for Untraceable Payments
1991 · Timestamping: resisting backdated records
A file can be edited, and a computer clock can be changed. Haber and Stornetta asked a harder question: how can a record establish that a document already existed at a particular time and resist later backdating?
Their approach used cryptographic digests and linked records to constrain tampering. A digest acts like a content fingerprint: changing the content changes the digest. This is important blockchain prehistory, though the system was not an open transaction network like Bitcoin.
Haber & Stornetta · How to Time-Stamp a Digital Document
1997 · Hashcash: making abuse cost computation
If sending a message requires solving a computational puzzle, sending millions becomes more expensive. Adam Back’s Hashcash made this idea into a verifiable proof of work: producing a proof takes attempts, while checking it is relatively easy.
Bitcoin later used proof of work to compete for block production and help the network choose between conflicting records. Hashcash itself addressed the cost of abuse; it was not yet a digital-currency consensus system.
Adam Back · Hashcash paper (2002 retrospective)
1998 · b-money: imagining a shared ledger
Wei Dai proposed b-money, a system in which participants would maintain balances and identify one another by public keys. The question expanded from issuing digital cash to maintaining accounts among people who do not know one another.
This was a proposal, not a deployed network. Dai explicitly acknowledged unrealistic communication assumptions in the first protocol. Those limits show what later designs still had to solve.
2004 · RPOW: passing a proof of work along
Hal Finney released RPOW, a reusable proof-of-work system that people could try. A user could submit a proof to a server and receive a new token, allowing the result of computation to pass from one person to another.
Preventing reuse depended on a server and verifiable trusted hardware. RPOW was a working experiment that exposed a central design question: where does trust reside?
Hal Finney · RPOW announcement
2005 · Bit gold: computation, time and ownership
Nick Szabo’s Bit gold essay combined computational puzzles, timestamps and an ownership registry. Computation produced a result, a timestamp recorded its existence, and a registry recorded its ownership. It explored how the history of a digital object could be checked rather than resting solely on an issuer’s promise.
This stop uses the archive’s 2005 date for the public essay. Bit gold was a design proposal, not a blockchain already operating at the time.
Nick Szabo · Bit gold (archived essay)
2008-10-31 · Bitcoin’s whitepaper: assembling the pieces
Satoshi Nakamoto announced the Bitcoin whitepaper to a cryptography mailing list. Digital signatures, peer-to-peer networking, proof of work and linked records were assembled into a proposal for preventing double spending.
A batch of transactions can form a block. Each subsequent block references the previous block’s digest, linking the blocks into a chain.
The challenge was not to stop people copying data. It was to let the network resolve conflicting spends under shared rules. This combination made an ongoing shared ledger possible without a central bookkeeper.
Satoshi Nakamoto · original whitepaper announcement
2009-01-03 · The genesis block: a headline in the ledger
Hexadecimal and text representation of Bitcoin genesis-block data, not a newspaper reproduction. Satoshi Nakamoto / Wikimedia Commons · MIT / public-domain data.
Bitcoin’s first block contains this line:
The Times 03/Jan/2009 Chancellor on brink of second bailout for banks
The block contains the text, not a photograph of a newspaper. It connects a verifiable data record to the world in which it was created. On January 8, Satoshi announced version 0.1 of the software on the mailing list. The paper, the genesis block and the software announcement are distinct milestones.
Satoshi Nakamoto · v0.1 announcement
2013 / 2014 · Ethereum: programs on a shared ledger
Vitalik Buterin began drafting Ethereum’s whitepaper in 2013 and introduced the project publicly in 2014. The ambition expanded from recording transfers to executing smart contracts: programs whose resulting state would be maintained under shared network rules.
A smart contract does not understand law or automatically know what happened outside the chain. It is software whose execution the network can verify.
Vitalik Buterin · Ethereum: Now Going Public
2015-07-30 · Frontier: Ethereum goes live
An early Ethereum network dashboard from an official 2016 retrospective, not a photograph of launch day. Ethereum Foundation / Taylor Gerring · CC BY 4.0.
Ethereum launched Frontier, its first live release, and miners and developers began connecting to the network. Transaction processing was tightly restricted at first; subsequent “thawing” updates opened the way for transactions and contract operations. Programs on a shared ledger became infrastructure people could experiment with, bringing questions about tools, interfaces and usability to more developers.
Stephan Tual · Ethereum Launches · Ethereum Protocol Update #1
2017 · ArcBlock: starting with application developers
ArcBlock was founded in 2017. With blockchains presenting different interfaces and development models, its early architecture considered how applications would connect, compose and run, introducing designs including OCAP and Blocklet.
These were architectural proposals at the time. Over the following years, they became tools and products people could use. The 2020 anniversary essay records October 31, 2017 as the birth of the ArcBlock name.
Source: ArcBlock · 2020 anniversary retrospective
2018-06-30 · ArcBlock OCAP: querying chains in a browser
Interface from the 2018 OCAP Playground launch announcement. ArcBlock.
OCAP Playground launched with a browser interface: write a query on the left and inspect data from chains such as Bitcoin and Ethereum on the right. The Open Chain Access Protocol borrowed the division of work used by database drivers, placing chain-specific access behind adapters.
GraphQL let developers describe the data fields they needed. A common querying approach reduced integration work, while each chain’s data meanings and rules still mattered.
Source: ArcBlock · OCAP Playground launch
2019-05-20 · ArcBlock DID: bringing identity into a wallet
Artwork from the 2019 ABT Wallet announcement, retaining the product’s name at the time. ArcBlock.
ArcBlock released ABT Wallet, an early version of the product later known as DID Wallet. Alongside assets, it brought application sign-in, credentials and document signing into the wallet experience.
A DID is a decentralized identifier that can identify a subject and connect it to information needed for verification. The wallet manages the relevant keys so a user can prove control of an identity. A signature can prove control; trusting a certificate still depends on who issued it and what it claims.
Source: ArcBlock · ABT Wallet launch
2020 · ArcBlock Blocklet: composing application components
Interface from ArcBlock’s 2020 Blocklet introduction. ArcBlock.
By 2020, Blocklet had public product documentation and a management interface. A Blocklet could be a service or a complete application. Developers could install, configure and run these software units, combining the capabilities they needed.
The modular design in the early whitepaper now had an interface people could operate. It addressed application delivery: using a blockchain did not remove the need to manage software versions, configuration and runtime environments.
Source: ArcBlock · Introduction to Blocklets
2022-03 · ArcBlock DID Wallet: making identity usable
Historical DID Wallet 4.0 interface from the 2022 release notes. ArcBlock.
DID Wallet 4.0 rolled out in March 2022 with redesigned navigation, wallet creation and scanning interactions. It continued the identity-wallet direction while translating key ownership into everyday actions.
Cryptography provides verification; the interface helps people understand what they are doing. How a wallet presents a request and asks for confirmation matters alongside its underlying algorithms.
Source: ArcBlock · DID Wallet 4.0 release
2022-07-19 · DID Core: a standard for identifiers
W3C published DID Core 1.0 as a Recommendation, defining DID syntax, a data model and related operations. Implementations gained a shared reference.
DIDs do not necessarily require a blockchain, and a standard does not automatically create trust or adoption. It gives systems a common way to discuss identifiers; methods, wallets and applications still have their own work to do.
2022-09-15 · The Merge: changing consensus on a live network
Consensus rules let the network agree on which valid records enter the ledger and in what order. Ethereum completed The Merge, switching from proof of work to proof of stake. Validators lock up ETH and participate in proposing or checking blocks under protocol rules; some violations can lead to a loss of stake. The mechanism for confirming blocks changed while the transaction history continued.
This was a major upgrade to a running system. The change alone did not automatically increase transaction throughput or reduce fees. Network security and scaling are related but distinct questions.
2024-08-13 · Post-quantum standards: preparing to change algorithms
NIST released its first three finalized post-quantum cryptographic standards. ML-KEM establishes shared keys; ML-DSA and SLH-DSA provide digital signatures. A sufficiently capable quantum computer could break some public-key algorithms used today, threatening keys and signatures. These new standards are designed to address that risk.
Publishing standards does not migrate existing wallets or blockchains. Replacing keys, upgrading signature rules and moving accounts safely remain system-design tasks.
NIST · finalized post-quantum standards
2026 · ArcBlock Arc: unified access through AFS
By the Arc generation of the architecture, the access problem behind early OCAP had expanded: applications and AI agents needed files, data and services. AFS, the Agentic File System, organizes resources by paths, with provider modules adapting the underlying systems.
Think of a path as an address in a directory: list the directory, find a file, then read its contents. The same access approach can extend to connected data records; an adapter translates the request into operations the underlying system understands.
OCAP’s access role entered this broader resource model. Callers can discover and read resources through common operations, subject to the resource’s capabilities and authorization. The journey from verifying who signed a message now extends to how people and programs use resources. Identity and permissions remain part of that work.
Source: Robert Mao · OCAP’s three generations
Explore further: Blockchain learning path · Blockchain in Practice and corrections · OCAP’s three generations
Check your understanding
Did blockchain appear as a single sudden invention?
It combined decades of work in cryptography and distributed systems; identity and application tools continued to address different problems.