So data stores tend to present interfaces which allow the CRUD operations on each record: Create, Read, Update, and Destroy.
Create: You hit submit on a comment form
Read: Your client app shows the content of the comment
Update: You hit submit on the comment editing form
Destroy: You delete the comment
Well, in some cases it’s very handy to make a data store with only two operations: Create, and Read.
This is called a “log”. A log is an append-only data structure.
One of the benefits of using a log is that two different processes can operate on the data, at different times, and can be confident they’re operating on the same context despite not being in communication with each other.
This “log” structure could be useful for instance in recording the moves of a chess game. Then, a hundred years later, someone can read each move out of a book and deterministically re-create the board state.
Now they know that they are looking at the same chess game that Ben Franklin was in 1775, despite not being in touch with Ben at all.
Really big, distributed systems benefit from this “synchronization without communication” feature of logs.
Relying on a log requires you to trust that nobody else has Update or Destroy access. For it to work correctly and everyone be on the same page, Updates and Destroys need to never happen.
With a coordinated system like people trying to understand historical chess games, or a corporation like LinkedIn seeking its own self interest, there’s no trust issue.
But with other things, like “who’s got how much money”, people don’t want to have to trust that some centralized log owner is modifying the data on the sly.
That’s where blockchain goes beyond a regular log. It’s a log designed to resist tampering, because each “block” in the chain goes through a distributed checking process where many copies of the log are used, and everyone checks each other’s copies to ensure nobody is cheating.
So data stores tend to present interfaces which allow the CRUD operations on each record: Create, Read, Update, and Destroy.
Create: You hit submit on a comment form Read: Your client app shows the content of the comment Update: You hit submit on the comment editing form Destroy: You delete the comment
Well, in some cases it’s very handy to make a data store with only two operations: Create, and Read.
This is called a “log”. A log is an append-only data structure.
One of the benefits of using a log is that two different processes can operate on the data, at different times, and can be confident they’re operating on the same context despite not being in communication with each other.
This “log” structure could be useful for instance in recording the moves of a chess game. Then, a hundred years later, someone can read each move out of a book and deterministically re-create the board state.
Now they know that they are looking at the same chess game that Ben Franklin was in 1775, despite not being in touch with Ben at all.
Really big, distributed systems benefit from this “synchronization without communication” feature of logs.
Excellent article on this data structure and its benefits here: https://engineering.linkedin.com/distributed-systems/log-what-every-software-engineer-should-know-about-real-time-datas-unifying
Blockchain is a log.
Relying on a log requires you to trust that nobody else has Update or Destroy access. For it to work correctly and everyone be on the same page, Updates and Destroys need to never happen.
With a coordinated system like people trying to understand historical chess games, or a corporation like LinkedIn seeking its own self interest, there’s no trust issue.
But with other things, like “who’s got how much money”, people don’t want to have to trust that some centralized log owner is modifying the data on the sly.
That’s where blockchain goes beyond a regular log. It’s a log designed to resist tampering, because each “block” in the chain goes through a distributed checking process where many copies of the log are used, and everyone checks each other’s copies to ensure nobody is cheating.