yes it would make them better but doesn’t solve our question about full decentralization.
2 Likes
at this point full decentralization and needed fast work is posible only if client hold all metadata on his side. then it can work realy fast. but until someone hold it it will work slow or centralized.
Sure, try to hire me, and I will write 
Blueprint for Storj Labs it really out of this topic.
Anyone does not push you to use your own satellite, but you can try to forget about your use case, and open your mind for how to improve the current situation.
I don’t see why it’s out of topic. It does not need to be very granular or perfect in any stretch.
Making proposals is always appreciated, especially since we are open source and value every contribution.
Complains in a forum are by far not the best way to get the problem solved 
2 Likes
As you can, I did not have any complaint, I realize the current situation and understand the reasons why he has the current situation.
Also, as you can see, I share my opinion and propositions, you can use any of these propositions or not use anything. But writing a blueprint is not a single person job, it requires to collect all other opinions and propositions, have requirements, have current statistic information. So, everything that I can at this moment just a share, my opinion and propositions and try to find the best way
1 Like
I wasn’t advocating for deploying Storj payment systems and node selection processes on Steem…
I was simply giving an example of a different type of blockchain that is actually used “in-th-wild” which is much faster than PoW Ethereum.
I would advocate for Quorum. I’ve played around with it a little. It’s an Ethereum based private blockchain along with an entire ecosystem developed by JP Morgan, which is all open source. As far as I remember it’s also used by Microsoft for Azure.
Quorum: https://consensys.net/quorum/developers
A consensus satellite model based on blockchain would allow anyone to run a “satellite” without needing the designation of “3rd party” or a list of trusted nodes. If the blockchain is Ethereum based, an SNO could simply signup by logging in with their Ethereum wallet set on the Storj blockchain rather than mainnet. The consensus blockchain would simply supply blockchain tokens for the transaction traffic across the network. These tokens would have zero monetary value and not have any need for electricity to be used to mint them… Instant generation of worthless tokens… something like generating a few million UUIDs.
Payments would still be in STORJ on mainnet Ethereum after a settlement process between the satellites at the end of a month.
If the above was implemented… a lot of development time and money would be needed… but the Storj network would grow very rapidly. Since anyone could run a satellite consensus node, satellites would pop up where ever there are high traffic areas.
The following would be the same:
- No need for SNOs to buy tokens up front (avoiding Sia type problems)
- Payments to SNOs would be in STORJ ERC-20 tokens
- Moderate centralization with metadata – however that data is distributed rather than siloed
- P2P user data traffic
I still see no solution for the issues outlined in the whitepaper. @Alexey already linked to it and mentioned one chapter, but there is actually a larger appendix that goes into this. I suggest readin Appendix A from the whitepaper. If you have a solution, I think there is a massive blockchain and distributed software community that will kiss your feet.
- Storj Whitepaper:
A.3 Why we’re avoiding Byzantine distributed consensus
We are excited about and look forward to a fast, scalable Byzantine fault tolerant solution. The building blocks of one may already be listed in the previous discussion. Until it is clear that one has arisen, we are reducing our risk by avoiding the problem entirely.
- Microsoft Azure Quorum use:
https://docs.microsoft.com/en-us/azure/blockchain/service/overview
Azure Blockchain Service is designed to support multiple ledger protocols. Currently, it provides support for the Ethereum Quorum ledger using the Istanbul Byzantine Fault Tolerance (IBFT) consensus mechanism.
- Quorum is fast and scalable:
https://blockgeeks.com/guides/quorum-a-blockchain-platform-for-the-enterprise/
In an independent performance evaluation study, the transaction per second (TPS) speed is reported as high as approx. 2500 TPS. This study is available on the link here:
In another study, the transaction throughput of private contract deployments is measured as high as approx. 700 TPS and performance of normal transactions have been measured up to approx. 2000 TPS. This paper is available here
This degree of enhanced performance makes Quorum a suitable choice for enterprise use cases.
- Conclusion:
I’m not needed. JP Morgan already did it. And the solution is open source, freely downloadable, well documented, and in use in the corporate enterprise world.
Of course, adapting the technology takes a lot of work. And Storj works fine the way it is now. However, the thread is about how to create a more decentralized Storj network.
Not even close to good enough… My node on average has about 4 transfers per second that would need to be settled on the blockchain. And that’s assuming that one transaction can take care of the entire process. Even in these early days there are over 8000 nodes doing this every second. So something that is several orders of magnitude faster would be required. This is also a measure of throughput, not latency. 2500 TPS doesn’t mean those transactions are actually settled within miliseconds. It just means a lot of them can be settled simultaneously.
It also doesn’t solve the problem of messages being lost.
2 Likes
You misunderstand where the transactions are occurring in my hypothetical architecture.
Blockchain transactions would be orders sent… not pieces transferred. The data pieces are transferred through the peer-to-peer network. The satellite is currently not involved and continues to not be involved.
In my hypothetical less centralized satellite network the transactions between the Storj nodes and the Consensus satellite nodes would ride over a private Ethereum based blockchain. Since the metadata would be held in a consensus network, less centralization would be achieved. No single satellite could knock out a customer’s access to stored data.
SNOs could run almost exactly the same as they currently do. Orders are only transmitted to the satellite every few minutes. So, worst case scenario 10,000 nodes send orders at the precise same second resulting in a SNO waiting about 4 seconds for the order to complete the send transaction.
Satellite operators would flip their installation into a consensus node and be required to fund their Ethereum mainnet wallets with STORJ.
Every month, the Quorum private blockchain is queried for SNO payments. The values of those payments gets pulled from Ethereum mainnet satellite operators’ wallets and sent to SNOs via Ethereum mainnet… just like now.
If such an architecture were implemented, it would open very exciting areas such as extensibility to the Consensus network… for example, SNOs could volunteer to create a ETH pool for donating some initial ETH to help onboard new SNOs. Since SNOs would essentially be using a wallet address to signup to be an operator, new SNOs could easily be identified and tracked by the Consensus network. Also… analytics would be easier and more open… etc.
You want decentralized piece metadata do you not?
The satellite is absolutely involved with every transfer to update that segments metadata and store which nodes hold pieces for that segment. If you don’t store that metadata on the blockchain then what’s the point of this excercise?
This metadata is not updated by the nodes sending orders. The order sending process is only for settling the payout, which can be delayed without issue. Metadata needs to be updated in real time as the transfer happens otherwise data isn’t accessible right after upload. So you can’t just bundle these updates and send them out later. They need to happen right away and the customer needs confirmation right away because lost metadata means lost data. That’s where latency becomes vital as well.
So yeah, great in concept, but never going to work in practice with currently available stuff.
1 Like
Best to wait until scalable ETH 2.0 frameworks and decentralized compute imo. Then the vision of an unstoppable, truly decentralized cloud we will be achievable.
In the meantime, we can work toward decentralization through metadata export and have third party satallites
3 Likes