As some people I know in this space were unaware of my original post for this flipstarter, I've re-posted it to pitch it to the BCH community. Some additional Q/A provided below.
Flipstarter: CashSQL - an SQL backend for BCH.
Q. Why is this product relevant?
A. Simple answer is that raw UTXO databases by themselves are too "low-level" for anything useful. This is by design, as the data is maximally normalized and compressed for storage and transmission efficiency.
To make use of a UTXO database for a layer-2 p2p applications (gambling, social media, etc) it requires de-normalization and processing of this blockchain data. If every single project needs to get kneck-deep in these complexities, it's going to stop a great many of them in their tracks due to cost and time (I've seen this happen personally).
This product alleviates this burden significantly which means layer-2 applications can be rapidly developed for BCH. Lowering the entry-barrier for outsider developers also means more (non-protocol) developers can enter eco-system.
Note that other eco-systems have comparable projects (e.g. BSV's Planaria which is what most of their projects are using).
Q. Why 6-12 months?
A. The existing MVP took 6 months to develop and another 6-12 months are needed for the enterprise-grade finish. For example:
-
Need to support multiple DBMS's using an abstraction layer for more DBMS's later.
-
There are all sorts of problems encountered at this scale of data. I call it doing "big data on small data infrastructure". Try out the MVP, cross-join on the TXO table and see if you can break it -- you cannot. It's fully stable and responds even for crash-able queries.
-
During import, the data is parsed directly from raw BLK files speed up installation process, and this requires LevelDB integration and all sorts of custom core stuff (e.g. they use a different compact integer format in storage than in chain).
-
Blockchain data tends to be maximally efficient and normalized, however applications consume denormalized data. For example, getting the "fee" of a transaction is a transitive calculation based on input/outputs. Getting the "fee" in USD is then a join to another table. All these things are data-transformations which need to be applied during import. Whilst a node can give you the "fee" there's other things they don't give. Real-world use cases need to parse OP_DATA payloads for Dapps whichl require custom transforms during import (you can't search for this stuff retrospectively in the chain).
-
The complexities pile on, but nothing that can't be solved.
Q. What guarantees do we get for delivery? Can't you just run off with the raise?
A. If this flipstarter is funded, I will deliver no matter what. The fact that a substantial MVP is provided is evidence of competence and delivery. Also, I am raising through a company structure and publicly identified myself so it's possible for any contributor to launch litigation should I fail to deliver (and I have no problem with that).
[link] [comments]
source https://www.reddit.com/r/btc/comments/j0nifo/flipstarter_cashsql_a_database_backend_for_bch/
No comments:
Post a Comment