Prototype of clinical trials in an untrustworthy environment using blockchain
nature.com
nature.com
A "chaining of hashes of the previous blocks" has other uses than preventing double spending of currency. It also acts as a "incrementing clock" of record-keeping that's resistant to tampering.
E.g. The "blockchain" started by Surety[1][2] in 1995 in The New York Times published hashes that depended on previous hashes. They could have published hashes that were independent of previous hashes but they didn't. It would not provide the same anti-tampering guarantees.
(I'm only replying to your assertion about blockchain's "double spending" use case in isolation and not commenting on whether the thread's article is a good idea.)
[1] https://www.vice.com/en_us/article/j5nzx4/what-was-the-first...
The NYT timestamp system doesn't meet the blockchain definition, at least so long as the word has any real meaning. This point is often debated, but my take is that without also featuring some kind of consensus mechanism to order the writes in a specific manner, thus preventing double spending, then the protocol shouldn't be described as a blockchain at all.
A timestamp service (as opposed to a blockchain) is good enough for the goals described in the article. There's no need to enforce strict ordering of transactions because there's no spending. It's just assertions of some fact at some time. So all that's needed are a few reliable servers run by different parties that will log the data. If one of them cheats, it is detectable.
Knowing who is behind the private keys signing the assertions is a far more important problem in this kind of system, and blockchains don't help that one bit.
My point isn't that Surety is a "formal" blockchain by some rigorous definition. (Obviously the VICE article is taking artistic liberties with the word "blockchain" to retroactively label Surety's published hashes back in 1995.)
The purpose of citing them was only to highlight that dependencies on past hashes accomplishes a different tamper-proof guarantee than your idea of just broadcasting digitally signed assertions.
>There's no need to enforce strict ordering of transactions because there's no spending. It's just assertions of some fact at some time.
Putting extra cryptographic mechanisms around the notion of "at some time" is the motivating reason for a chain of hashes. If Surety didn't chain their hashes and then publish the hash, that's weaker than broadcasting independent hashes.
>Knowing who is behind the private keys signing the assertions is a far more important problem in this kind of system, and blockchains don't help that one bit.
I think I see why you believe focusing on digitally signed assertions is enough security. E.g. the web browser TLS/SSL https security works fine on broadcast assertions with no "blockchain". That's true. It's "trust of a identity hierarchy" rather than "trust of a timeline". The difference is that when users log into "paypal.com" today to withdraw money, they don't care what the private/public certificate authority keys were 3 years ago. However, the users of the database of clinical results do care about past history.
Also, we do care what paypal’s certificate was in the past. That’s why we have CT to catch CAs that mess up. We just don’t need to use a blockchain for it to work.
And to be clear, I wasn't claiming that "chain of hashes" was equivalent to a blockchain. (E.g. bitcoin-like blockchain.) Instead, I extracted one particular property of a blockchain -- the chain of dependent hashes -- to contrast your proposed broadcast solution.
To add to the confusion, it turns out the authors may be implementing your non-Bitcoin suggestion anyway. (See further down in my comment.)
>Also, we do care what paypal’s certificate was in the past.
I understand the nitpick but I mean that web browsers don't care what the particular values were several years ago (especially anything before 2013 since CT didn't exist until then while SSL/TLS existed since 1995). They check existence in a CT log.
>Less like Bitcoin, more like Certificate Transparency.
It looks like the authors propose a architecture more similar to CT than Bitcoin anyway. Excerpt from their proposal:
>We chose to give data storage control to the regulator, as opposed to distributing data storage to nodes across participants in the network like in Bitcoin applications. We preferred this design because the trial regulator is the only party that can and must be trusted, since this party is the one having final approval over success or rejection of the treatment. It is a central authority that cannot be eliminated. We feel implementing distributed storage to everyone in the network (such as that used for Bitcoin) does not fit this regulatory context well, and is also impractical as all parties would also have to locally store data pertinent to the clinical trial on their machines.
I believe this means the remaining issue is that you disagree with the authors calling something "blockchain" that doesn't have a distributed consensus mechanism to prevent double spending.
So publish a git repository then. Still no blockchain needed.
You'd be very surprised, then. It has always been a mystery to me how people plugged most holes in the data that I extract for them.
But the industry is all based on audit trails etc. Tampering is not done on a technical level.
This makes no sense. If your government is in such bad shape you have far bigger problems than keeping track of drug trials.
"Blockchain" just stores the same stuff lots and lots of times in as many places as possible. Extremely wasteful and expensive, with all the overhead of doing that (and updating hat "database"), plus the consensus algorithm which may or may not be reliable/crackable.
Is it a sign of the times, and maybe in some countries more than in others, that there is a hype around mistrust? Trying to build a world where trust is not necessary? I bet that won't work. I think you need to fix the trust issue more directly, working around the trust requirement won't work. It just creates huge complexity and even more points of failure. Especially since you would have to go "all in": What's the point in taking just one thing into the trust-free solution? All those things depend on one another, you would have to do it with all or most of them to get the benefit you are looking for. It may look manageable if you only look at one particular thing, but imagine everything had to be stored in such a way, the incredible effort required, and the more distribution there is the harder it is to understand what's going on.
You really think storing all kinds of data in as many places as possible and then trusting an algorithm to sort it all out, the "truth", works better than trust in a credible entity? At scale (in more than one dimension)?
I agree with the parent but I also agree with this, at the very least with the US government. If you think it's not in bad shape then you're living in a fantasy. All it takes is somebody with an agenda to start changing facts from being science based to being what you personally believe in or what corporations want. One such example of this is Pruitt at the EPA.
No. Blockchain doesn’t have to be wasteful. In general is enough to store the hash of the data in the blockchain and the data itself somewhere where it can be accessed. This prevents manipulation. If at least one trusted party has access to the data it also would not just vanished. If you had an permissioned blockchain signed by the top universities of the world it could be done for very little money.
Adding a semi-public blockchain seems like a neat little tidbit but it mostly adds a formalization of the process (which would of course be a good thing) and buzzword-worthiness, thus warranting the "wasteful" label.
> permissioned blockchain [...] for very little money Is that a solved problem yet?
Do you?
There is no "double spend" possibility. There is necessarily a trusted source. Why not get the benefit of that centralized source and have the government host a plain database?
We also have operational encryption, multi-researcher studies, and soon an end-to-end encrypted chat system between researchers and participants using Matrix.
Your website seems to explain the current problems with clinical research, but I didn't see an explanation of your solution. Can you share here?