The example above is pretty simple, but it would be what we would normally see in Storm. On the one hand, Ana has BTC and will use it to pay for the required storage services. Carlos, is part of the Storm network and accepts BTC for their services.
To avoid fraud on this P2P scheme, Storm ensures that the BTC Ana is passed on to Carlos, meets certain requirements. For example, the payment Ana makes to Carlos is not immediate and full, but is made in phases to ensure compliance with the terms.
For example, Carlos cannot ignore Ana’s data because if he does, the payment will be canceled. And Ana, for example, can’t just get the data off the web by breaking the original deal without having to fulfill the agreements she signed at the beginning.
To achieve that, Storm configures the payment for service transactions using CSV and HTLC and ensures that the payment is released if the deadlines are met. For example, if Ana wants Carlos to offer her a storage space for 1 year, this means that the BTC transaction will be released in full, in 1/12 servings per month. The good thing about this system is that the process can be carried out in both the BTC network and LN without any problems.
Using PSBT and HTLC, on the other hand, avoids other pitfalls as well, for example that Carlos ignores the data entrusted to him. At this point, Ana and Carlos’ HTLC transaction uses a PSBT scheme to force Carlos to honor his end of the deal or Ana can claim the rest of the reward and Carlos will be punished for malicious acts. .
In any case, payment transactions in Storm are protected against fraud and are therefore secure.
Data plane security and integrity
Storm’s other point is the security and integrity of the data. To achieve this, Dr. Maxim Orlovsky with the well-known testable probability tests. These tests are responsible for ensuring the security and integrity of the data Ana left in Carlos’ hands.
These tests are initially a derivative of the already known ZKP or Zero Knowledge Tests that are used in cryptos such as Monero or ZCash. The idea is that the data sent to the Storm network can be encrypted so that if Ana wants to know that her data is really there, she can request cryptographic evidence from Carlos, and Carlos can give it without the slightest inkling of the data Ana left on this network.
In fact, Carlos neither read nor can he read the data because Ana passed it on in encrypted form from the start, and Carlos can only pass cryptographic tests that Ana can check at any time.
To do this, Storm divides the data to be sent to the network into blocks of equal size. At this point, you randomly select a number of these blocks and go through a double Merkle tree creation process in which:
- Random, unencrypted data blocks are used to create a Merkle root of these blocks.
- The above blocks are encrypted and a second Merkle root is created from this encrypted data.
At the end of the creation of the Merkle roots, they are connected to create a cryptographic marker. This marker allows Ana to ask Carlos for proof of storage without knowing what data is in the record he has stored, and Ana assures that Carlos can only answer with the truth, because if not, it means Carlos doesn’t have the data she gave him.
The method is not much different from networks like Sia and Filecoin, which use similar protection models in their networks. Nevertheless, Storm has an added potential and that is that its cryptographic evidence is much more secure.