In the beginning you stated how the blockchain kept a history and that it’s also inefficient.
As history advances does the transaction size become bigger and bigger?
If it does, how is that handled? Is it handled by headroom?
What the salesman tells you and what you get can be quite different.
I know that your not a salesman.
The size that it takes to store the entire database does steadily become larger as time passes. The time that it takes to verify the entire chain also increases, though you can do that sporadically whenever it is convenient, and don't have to constantly do it in real time.
The processing time per transaction does not increase as time passes, however. And the memory requirements to process the data (as in DDR4, not SSDs) don't increase unless the amount of active data does, which would force any database to need more memory.
It's also important to realize that the amount of storage available for a given price will tend to increase faster than the storage capacity needed for a blockchain database. For example, if someone had started a blockchain database in 2000 that was increasing in size by 10 GB per year, then 10 GB in 2001 or 20 GB in 2002 was a significant amount of space. Today, 220 GB isn't much.
In the beginning you stated how the blockchain kept a history and that it’s also inefficient.
As history advances does the transaction size become bigger and bigger?
If it does, how is that handled? Is it handled by headroom?
What the salesman tells you and what you get can be quite different.
I know that your not a salesman.
The size that it takes to store the entire database does steadily become larger as time passes. The time that it takes to verify the entire chain also increases, though you can do that sporadically whenever it is convenient, and don't have to constantly do it in real time.
The processing time per transaction does not increase as time passes, however. And the memory requirements to process the data (as in DDR4, not SSDs) don't increase unless the amount of active data does, which would force any database to need more memory.
It's also important to realize that the amount of storage available for a given price will tend to increase faster than the storage capacity needed for a blockchain database. For example, if someone had started a blockchain database in 2000 that was increasing in size by 10 GB per year, then 10 GB in 2001 or 20 GB in 2002 was a significant amount of space. Today, 220 GB isn't much.
I would also recommend looking into proof of history. It's a feature that works in conjunction with proof of stake to increase transaction speed.
The speed of transactions is only a temporary limitation, but some blockchains are finding ways to increase the amount of transactions and the speed of them pretty quickly.
Reminds me of Object Orientation when that first came out. It was gonna change the way everyone coded and revolutionize everything digital.
Now, it's still around, but it hardly revolutionized anything; a lot of cases have been found where ~not~ using it and going the old ways was better after all.
Makes sense to me for financial transactions, logistics tracking, health care records, a few other things where chain of custody is important. Video games, not so much.
Reminds me of Object Orientation when that first came out. It was gonna change the way everyone coded and revolutionize everything digital.
Now, it's still around, but it hardly revolutionized anything; a lot of cases have been found where ~not~ using it and going the old ways was better after all.
Makes sense to me for financial transactions, logistics tracking, health care records, a few other things where chain of custody is important. Video games, not so much.
Object oriented programming did change programming quite a lot. It's not the solution to everything, but it is the solution to quite a lot of things. Blockchain is never going to replace the sort of databases where the storage capacity forever growing would be a problem. It's not at all clear whether it will ever be usable for databases that need thousands of database edits per second. But its prospects are much better in situations where you want a complete log of all database edits that have ever been made, or when you need a database to be decentralized and tolerant of any arbitrary copy of the database simply vanishing at arbitrary times.
Reminds me of Object Orientation when that first came out. It was gonna change the way everyone coded and revolutionize everything digital.
Now, it's still around, but it hardly revolutionized anything; a lot of cases have been found where ~not~ using it and going the old ways was better after all.
Makes sense to me for financial transactions, logistics tracking, health care records, a few other things where chain of custody is important. Video games, not so much.
Object oriented programming did change programming quite a lot. It's not the solution to everything, but it is the solution to quite a lot of things. Blockchain is never going to replace the sort of databases where the storage capacity forever growing would be a problem. It's not at all clear whether it will ever be usable for databases that need thousands of database edits per second. But its prospects are much better in situations where you want a complete log of all database edits that have ever been made, or when you need a database to be decentralized and tolerant of any arbitrary copy of the database simply vanishing at arbitrary times.
Now your almost describing a PDM system. When you have engineered drawings, you need an accounting of every single edit.
Thank you @Quizzical for your overview. However, Blockchain is nothing new, but falls into the category of append-only data structures. A special feature of Blockchain is that a cryptographic function is applied to logs to make transactions verifiable. However, there are other immutable and verifiable solutions. Thus one of the reasons why private Blockchains, where the group of authorised parties is quite limited and thus very transparent, are not very interesting is that there are almost always better solutions. IMO all the big publishers are following the hype rather than the need.
You could think of blockchain as being an append-only database that uses hash functions for data security. I'm skeptical that you're going to be able to offer the same degree of data security without using a hash function. A simpler checksum would be fine if you're only trying to guard against random bit errors, but that's not going to be robust against a malicious actor actively trying to corrupt the logs.
Right now, the computational requirements of computing the hashes is a big problem, so blockchain really isn't useful for very much. If the CPU vendors add good hardware acceleration for some secure hash function as I think they will, then the problem of computing hashes will go away.
If your CPU can compute a full blockchain hash per clock cycle while also doing whatever other CPU work you want it to do, then computing the hashes might use a fraction of a watt, but is otherwise effectively free.
"Compute a hash" is going to be a high-latency instruction, of course, but it wouldn't take that much die space. One full iteration of 256-bit SHA-2 takes 14592 bits of integer addition, 4096 bits of xoring together three values, 2048 bits of a majority vote on three bits, and 2048 bits of bitselect. I don't know how many transistors it would take to fully unroll that so that you could get an output per clock, but I'd bet that it's well under a million, as compared to tens of billions of transistors in a modern CPU.
If hardware gets to the point that computing the hashes is effectively free, then why wouldn't you want to use them if you're making an append-only database? Sure, some weaker form of data security is good enough for a lot of cases, but why not use a stronger version if it's not really any more expensive?
Comments
The processing time per transaction does not increase as time passes, however. And the memory requirements to process the data (as in DDR4, not SSDs) don't increase unless the amount of active data does, which would force any database to need more memory.
It's also important to realize that the amount of storage available for a given price will tend to increase faster than the storage capacity needed for a blockchain database. For example, if someone had started a blockchain database in 2000 that was increasing in size by 10 GB per year, then 10 GB in 2001 or 20 GB in 2002 was a significant amount of space. Today, 220 GB isn't much.
The speed of transactions is only a temporary limitation, but some blockchains are finding ways to increase the amount of transactions and the speed of them pretty quickly.
Now, it's still around, but it hardly revolutionized anything; a lot of cases have been found where ~not~ using it and going the old ways was better after all.
Makes sense to me for financial transactions, logistics tracking, health care records, a few other things where chain of custody is important. Video games, not so much.
"Be water my friend" - Bruce Lee
Right now, the computational requirements of computing the hashes is a big problem, so blockchain really isn't useful for very much. If the CPU vendors add good hardware acceleration for some secure hash function as I think they will, then the problem of computing hashes will go away.
If your CPU can compute a full blockchain hash per clock cycle while also doing whatever other CPU work you want it to do, then computing the hashes might use a fraction of a watt, but is otherwise effectively free.
"Compute a hash" is going to be a high-latency instruction, of course, but it wouldn't take that much die space. One full iteration of 256-bit SHA-2 takes 14592 bits of integer addition, 4096 bits of xoring together three values, 2048 bits of a majority vote on three bits, and 2048 bits of bitselect. I don't know how many transistors it would take to fully unroll that so that you could get an output per clock, but I'd bet that it's well under a million, as compared to tens of billions of transistors in a modern CPU.
If hardware gets to the point that computing the hashes is effectively free, then why wouldn't you want to use them if you're making an append-only database? Sure, some weaker form of data security is good enough for a lot of cases, but why not use a stronger version if it's not really any more expensive?
I find that surprising.
"Be water my friend" - Bruce Lee