Satoshi Nakamoto announced Bitcoin in the “Bitcoin Whitepaper” in 2008.
The Bitcoin Whitepaper describes how to create peer-to-peer electronic money.
All of the design decisions discussed in the whitepaper reflect this objective.
The Bitcoin Whitepaper does not mention “blockchain”.
The Bitcoin Whitepaper mentions a “timestamp server” based on validating blocks of transactions that the software it describes uses to establish the order of transactions over time.
Bitcoin does this in order to solve the “double-spend problem” without resort to “trusted third parties”.
Bitcoin must do this in order to function as peer-to-peer electronic money.
The construction of a public ledger of transactions gathered into blocks and validated using a proof-of-work algorithm in return for economic incentives paid in the currency that the system exists to create is a contingent technical element of doing so.
Blockchains and proof of work are not original to Bitcoin, there were more interesting hashing or signature schemes available in 2008, and Nakamoto Consensus does not represent the first solution to the Byzantine Generals problem in computer science.
This use of economic incentives to construct a data structure in an adversarial environment is Bitcoin’s only technical innovation.
We can exploit the contingent technical elements of Bitcoin’s design for peer-to-peer money as primary technical elements if they are appropriate responses to design challenges that we face elsewhere.
They are appropriate responses if they support the instantiation of the project’s stated goal with the same degree of utility that they support Bitcoin’s stated objective of producing peer-to-peer electronic money, or at least to a high degree.
Such instantiations stand a better chance of not being solutions-in-search-of-a-problem or having broken economic incentive structures.
The building blocks of the Bitcoin whitepaper can also be exploited as primary concepts if they represent appropriate responses to the conceptual challenges of a project.
We must be careful not to fetishize or miscast them.
For example “trust” in the Bitcoin Whitepaper appears only in the phrase “trusted third parties”, taken from the writing of Nick Szabo, and refers to the unjust and unavoidable intervention into social relationships of potential opponents that might better be described as “treacherous third parties” in the style of Richard Stallman.
In both the technical and conceptual cases, varying emphasis or adding or removing elements from those present in Bitcoin without sufficiently addressing the impact of doing so or the ideological and economic balance of the resulting system can negatively affect its appropriateness and viability.
It is therefore vital to understanding how each element of Bitcoin contributes to doing the one thing that Bitcoin is actually meant to do and be, and being very careful when seeking to produce systems that exploit elements of it of it for purposes other than that.
All of this means that a better question than “does this project need a blockchain?” would be “what is the conceptual equivalent of peer-to-peer digital money in this domain and if this is an idea worth pursuing how would we go about constructing it?”.
That is a more difficult question though.