_Ted_Hsu_Alamy_.jpg?#)
_Futuristic_overlay_Alamy.jpg?#)
Dolt as a backing database for blockchains
When developing any blockchain system, sooner or later one has to deal with the problem of forks and eventual chain reorganizations. Before Dolt appeared on my radar, I thought this problem was non-trivial, and very difficult to implement: Whenever a fork occurs, or blocks arrive at your node that conflict with your current chain, you have to validate these new blocks against a snapshot of your data at a specific point in time. This point in time is determined by the parent block hash of the incoming blocks. This requirement for "time-travel" has always deterred me from attempting my own blockchain implementation. I know that there are blockchains out there that have (maybe?) solved this, but I'm not as good as a programmer as those guys. If you're anything like me, maybe you can relate. Enter Dolt. Dolt is a versioned MySQL-compatible database that returns a commit hash after every "commit" you perform on your data. To quote the Dolt team: "What git is doing with files, Dolt is doing with tables". That means: In our blockchain system, whenever we create a new block and apply the transactions to our data, Dolt gives us a new commit hash. And now for my theory: If we set block_hash = dolt_commit_hash, we can trivialize this aforementioned "time-travel". Whenever a new block arrives that we have to validate, we can very easily use the parent block hash to check out the parent state, and validate and run our transactions on top of the parent state. I'm not sure if the Dolt developers know this, but as far as my theory goes, they have (maybe accidentally) trivialized a huge chunk of blockchain development. Now somebody just has to make DoltCoin a real thing.
When developing any blockchain system, sooner or later one has to deal with the problem of forks and eventual chain reorganizations.
Before Dolt appeared on my radar, I thought this problem was non-trivial, and very difficult to implement: Whenever a fork occurs, or blocks arrive at your node that conflict with your current chain, you have to validate these new blocks against a snapshot of your data at a specific point in time. This point in time is determined by the parent block hash of the incoming blocks. This requirement for "time-travel" has always deterred me from attempting my own blockchain implementation. I know that there are blockchains out there that have (maybe?) solved this, but I'm not as good as a programmer as those guys. If you're anything like me, maybe you can relate.
Enter Dolt. Dolt is a versioned MySQL-compatible database that returns a commit hash after every "commit" you perform on your data. To quote the Dolt team: "What git is doing with files, Dolt is doing with tables".
That means: In our blockchain system, whenever we create a new block and apply the transactions to our data, Dolt gives us a new commit hash. And now for my theory: If we set block_hash = dolt_commit_hash, we can trivialize this aforementioned "time-travel". Whenever a new block arrives that we have to validate, we can very easily use the parent block hash to check out the parent state, and validate and run our transactions on top of the parent state.
I'm not sure if the Dolt developers know this, but as far as my theory goes, they have (maybe accidentally) trivialized a huge chunk of blockchain development.
Now somebody just has to make DoltCoin a real thing.
