1
BiblePay Current Discussion / Re: BiblePay | 10% to Orphan-Charity | RANDOMX MINING | Sanctuaries (Masternodes)
« Last post by Rob Andrews on October 09, 2024, 05:49:23 AM »Without going into all the boring technical details, we adopted CockroachDB as our back-end decentralized database in hopes that Temples could run an instance of CockroachDB, and that would be the storage engine of choice for us to host the sidechain.
Most of the hurdles were solved, like the HTTPS certificates, the automatic syncing, the install, the data format, the blocks, the content, etc.
However, one thing ended up killing the project in the end (and it is very similar to other non decentralized clustered databases): It does not gracefully handle the loss of nodes during volatile periods. We had 3 nodes in the cluster for months without a problem but after some expirimentation, I found that if BBP temples would join/unjoin sporadically, it would corrupt the database, and after spending an exorbitant amount of time to try to restore the db in those situations, I realized its just not going to work for us long term.
So Im back to creating our own flavor of decentralized dbase, one that the Users own (I wont even be required in this project once I check in the code); all the keys are going to belong to the Temples who run this dbase. Im migrating cockroach data down to JSON first. Working on this in the background.
So to keep this decentralized it looks something like this:
- You host a temple
- Your temple runs this BBPDB
- Keys and configuration are embedded in the program, so Im not required
A second project is required for our Phone and Storj storage:
- Since Storj hosts our video content
- Since our PBX provides phone service
- We need a generic layer that will allow more than one, preferably 3, users to "volunteer" to run a "service type" (like phone or storage),
and the code will encrypt the keys, and use them in the temple. Then when people drop off who no longer host a PBX or a Storj account,
they will get replaced with the other keys automatically. This would be similar to a decentralized "market making" service.
This way I will not be needed for that particular function, and its keys can be used and protected by a temple (node).
So that is the plan for the time being and Im actively working on the BBPDB.
Most of the hurdles were solved, like the HTTPS certificates, the automatic syncing, the install, the data format, the blocks, the content, etc.
However, one thing ended up killing the project in the end (and it is very similar to other non decentralized clustered databases): It does not gracefully handle the loss of nodes during volatile periods. We had 3 nodes in the cluster for months without a problem but after some expirimentation, I found that if BBP temples would join/unjoin sporadically, it would corrupt the database, and after spending an exorbitant amount of time to try to restore the db in those situations, I realized its just not going to work for us long term.
So Im back to creating our own flavor of decentralized dbase, one that the Users own (I wont even be required in this project once I check in the code); all the keys are going to belong to the Temples who run this dbase. Im migrating cockroach data down to JSON first. Working on this in the background.
So to keep this decentralized it looks something like this:
- You host a temple
- Your temple runs this BBPDB
- Keys and configuration are embedded in the program, so Im not required
A second project is required for our Phone and Storj storage:
- Since Storj hosts our video content
- Since our PBX provides phone service
- We need a generic layer that will allow more than one, preferably 3, users to "volunteer" to run a "service type" (like phone or storage),
and the code will encrypt the keys, and use them in the temple. Then when people drop off who no longer host a PBX or a Storj account,
they will get replaced with the other keys automatically. This would be similar to a decentralized "market making" service.
This way I will not be needed for that particular function, and its keys can be used and protected by a temple (node).
So that is the plan for the time being and Im actively working on the BBPDB.