This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionLast revisionBoth sides next revision | ||
qort_hosting_-_previous_model_on_qora [09/10/2020 07:52] – gfactor | qort_hosting_-_previous_model_on_qora [08/16/2021 15:19] – gfactor | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | ====QORA Hosting Model==== | + | ====== QORA Original Data Hosting Model ====== |
- | + | {{: | |
QORA had a model that was based on uploading data to the chain itself. In order to place data upon the QORA hosting, a user would have to register a name to use as a ' | QORA had a model that was based on uploading data to the chain itself. In order to place data upon the QORA hosting, a user would have to register a name to use as a ' | ||
Line 12: | Line 13: | ||
** | ** | ||
Pretty neat, right?** | Pretty neat, right?** | ||
- | |||
- | \\ | ||
====QORA Hosting Model ' | ====QORA Hosting Model ' | ||
- | |||
- | \\ | ||
Now, at first glance, one may say 'wow, that's incredible!', | Now, at first glance, one may say 'wow, that's incredible!', | ||
- | |||
- | \\ | ||
===Issue #1 - Bloating The Chain=== | ===Issue #1 - Bloating The Chain=== | ||
- | \\ | ||
The first issue with the QORA model, is the fact that the data is actually ON CHAIN, which means in order to be sync'd fully with the network, every node must HOLD THE DATA. | The first issue with the QORA model, is the fact that the data is actually ON CHAIN, which means in order to be sync'd fully with the network, every node must HOLD THE DATA. | ||
- | \\ | ||
This is good in theory, but bad in practice, when dealing with data actually on the blockchain. As when the system ends up getting a lot of users, the data would quickly become too large for the computers of the users to hold... making it eventually inevitable that the system would need a total rework once the data got to a point that it was filling the largest hard drives itself... So the long-term potential of this model is lacking. | This is good in theory, but bad in practice, when dealing with data actually on the blockchain. As when the system ends up getting a lot of users, the data would quickly become too large for the computers of the users to hold... making it eventually inevitable that the system would need a total rework once the data got to a point that it was filling the largest hard drives itself... So the long-term potential of this model is lacking. | ||
- | |||
- | \\ | ||
The bloat, is the main issue that Qortal didn't use the on-chain storage model. | The bloat, is the main issue that Qortal didn't use the on-chain storage model. | ||
- | ===Issue#2 - Data uploads in transactions | + | ===Issue #2 - Data Uploads In Transactions |
- | QORA's upload feature, was both coded incorrectly, | + | QORA's upload feature, was both coded incorrectly, |
- | \\ | + | This caused all kinds of issues for users, when they attempted to upload too much data for a single tx, got an error, and assumed that websites could only be the size of a single tx which wasn't the case. |
- | + | ||
- | This caused all kinds of issues for users, when they attempted to upload too much data for a single tx, got an error, and assumed that websites could only be the size of a single tx... which wasn't the case. | + | |
- | + | ||
- | \\ | + | |
Another portion that was an issue, even if the upload DID make use of multiple transactions to upload larger pieces and such more easily.. The uploads were still done in transactions, | Another portion that was an issue, even if the upload DID make use of multiple transactions to upload larger pieces and such more easily.. The uploads were still done in transactions, | ||
- | |||
- | \\ | ||
That's all for now, I will continue this page at a later date. | That's all for now, I will continue this page at a later date. | ||
--- // | --- // |