The above example is pretty straightforward, but it would be what we would usually see in Storm. Ana on the one hand has BTC and will use the same to pay for the storage services you need. Carlos, is part of the Storm network and accepts BTC for their services.
To avoid cheating in this P2P scheme, Storm ensures that the BTC Ana passes to Carlos meet certain requirements. For example, the payment that Ana makes to Carlos is not immediate and complete, but is made in phases to ensure compliance with the conditions.
So 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 net by breaking the initial deal without having to fulfill the points of agreement that she signed. at first.
To achieve this, Storm configures payment-for-services transactions using CSV and HTLC, ensuring that the payment is released as the deadlines are met. If, for example, Ana wants Carlos to offer her a storage space for 1 year, this means that the BTC transaction will go away. releasing in its entirety, in portions of 1/12 each month. The good thing about this system is that the process can be done both in the BTC network and in LN, without difficulties.
Using PSBT and HTLC on the other hand, also avoids other pitfalls, for example, that Carlos ignores the data that Ana has entrusted to him. At that point, Ana and Carlos’ HTLC transaction uses a PSBT scheme to force Carlos to keep his end of the deal, because otherwise, Ana can claim the rest of the reward and Carlos is punished for acting as bad faith.
In any case, payment transactions in Storm are protected against cheating, so it is safe. & Nbsp;
Data-level security and integrity
The other point of Storm is the security and integrity of the data. To achieve this, Dr. Maxim Orlovsky works with the well-known testable probabilistic tests. These tests are responsible for providing security and integrity to the data that Ana has left in the hands of Carlos.
First of all, these tests are a derivation of the well-known ZKP or Zero Knowledge Tests, used in cryptos such as Monero or ZCash. The idea is that the data going to the Storm network can be encrypted in such a way that if Ana wants to know that her data is there Actually, she can request a cryptographic proof from Carlos, and Carlos can give it without having the slightest idea of the data that Ana has left in said network.
In fact, Carlos has not read, nor can he read, nor will he read. said data, because from the beginning Ana has passed them encrypted, and the only thing Carlos can do is pass cryptographic tests that Ana can verify at all times.
To accomplish this, Storm divides the data to be sent over the network into blocks of equal size. At this point, you randomly pick a number of those blocks and go through a double merkle-tree creation process where:
- Random, unencrypted blocks of data are taken to create a merkle root of those blocks.
- The above blocks are encrypted and a second merkle root is created from that encrypted data.
Upon completion of the merkle root creation, the merkle roots are merged to create a cryptographic marker. This bookmark will allow you ask Ana to ask Carlos for proof of storage, without him knowing what data is within the data set that stores, and Ana gives the assurance, that Carlos will only be able to answer with the truth, because if you don’t, it means that Carlos does not have the information that she has given him.
The method does not differ much from networks like Sia and Filecoin, where similar models of protection are used within their networks. Nevertheless, Storm has an additional potential and that is that its cryptographic proofs are much more secure.