Introducing The nSPV and lib-nSPV Blocktech by JL777
The leveraging of notarization for blocktech Superlite clients is achievable through nSPV by applying a simple approach. When it comes to user wallets that do not want the entire wallet on their local address, the implementation of SPV clients is useful for scenarios like this. This is a little bit tricky due to the rapid growth of the blockchain network.
Considering this growth, the number of headers required for this required implementation also grows. With equihash coins, the data size is 2kb. With this effect, the overhead effect becomes larger. It is estimated to get to about 2GB per one million blocks of stored data. This estimated figure represents the header value only.
If the utilization of notarization is being considered as a verified block hash, it is possible to reduce the total number of headers needed that are contained in the blocks near the utxo in a given local wallet. Not less than 10 headers are what could be needed to achieve confirmation while dealing with a particular utxo in a wallet.
Importantly, not less than 10 blocks are required for each notarization to happen. It is also important to note that each notarization is characterized by its height and block hash. Averagely, 5 blocks, prior to the next, have a notarization for a specific utxo. The headers for the next blocks will give enough room for the confirmation that the headers are valid headers before the next notarization.
Provided a validated set of headers, the raw tx bytes is expected to be hashed to the txid while a txproof validates the txid. The txid is mined into the block of the specific Merkle root.
Evolution Of nSPV To Lib nSPV
The evolution of the blocktech nSPV is still in careful development and modifications is still ongoing. The modification of komodod into a –nSPV = 1 mode is achieved to activate this much-needed functionality. With this in place, most of the CC intended transaction being created was made from the nSPV = 1 client. It was also achieved from the full node side protocol which was already becoming stable.
The library called libbtc is also used to implement the things needed while trying to achieve a header-only SPV client while using Bitcoin in C. transferring the nSPV code into libbtc bypasses all the headers only SPV handling. This is due to the fact that the nSPV handling does not, in any way, need to have any local data on disk. Ultimately, it points towards the fact that it can function in a more efficient model. Libsodium is also a good addition to the library for support for signing the sapling tx.
However, Libbtc didn’t seem to have any API handling. The iguana RPC handling could be inserted into Libnspv. This results in a single-threaded model that can be used to make a request to a port. It can curl post request and handle JSON parameter arrays. It can also handle JSON with all the concerned fields.
This is a mini coin daemon containing an executable size of approximately 300kb and corresponding RAM usage of about 3MB. This is also capable of using the enhanced version of the particular coins file stored in the coin repository for the needed parameters required for all the Komodo ecosystem coins.
With these few application of the libnspv, the scaling to millions of the users on the platform and blockchain is now practical.
Why This BlockTech Is Unique
The new technology for the blockchain through the use of nSPV and libnSPV is quite unique with a few unique characteristics that allow it to stand out. Although libnspv is the library version of nSPV, it has some unique applications also. Some of these unique qualities include
- Validation With Txproof
While there are provided set of valid headers, there is a provided txproof that is used for the validation process to the Merkle root for a specific block. Evidently, this will validate that the specific txid was mined into that bock.
- Efficiency In Creating A Minimal Data Set
Here, in order to provide a unique and efficient way of producing minimal data set which is essential for the set up to validate a set of utxo, RPC calls are created to pinpoint the closest notarization. This is usually the closest notarization to all the utxo. In conjunction with the Merkle root tx validation, it will ensure the orders are enabled for less hard magnitude header required for the validation of all utxo wallet.
- Leverage On Existing Notarization
nSPV clients is a way of leveraging on the existing notarizations already achieved to gain up to 10000x reduction in headers in their bandwidth and storage needed. This is for the validation of the set of utxo’s that are in the wallet. It is worthy to note that for relying on the notarized chain, there is a tradeoff. If this tradeoff is acceptable, there is the creation of a way for the implementation of the next generation of useful Superlite nSPV wallets.
- An Enhanced Version Of The Coin File
Using the iguana RPC handling and inserting it into the libnspv provides certain unique benefits. This allows the handling of JSON parameters array with all the other fields. This forms a mini coin daemon for the executable size of approximately 300kb. It is capable of using an enhanced version of the coin file based in the coins repository. This will enable it to access the parameters for all the komodo coins ecosystem.
- Scaling To Millions Of User Wallet
With the development and evolution of nSPV to libnspv, scaling the platform to millions of users is a very practical application. With the implementation of the mechanism and the upgrade to the libnspv, reaching millions of users for these unique blockchain characteristics is now practically possible.
The idea for nSPV and Lib nSPV is truly innovative and revolutionary. The basic functionality is scaling to millions of users and the efficiency in the creation of minimal data set necessary. The simple modification and implementation lead to the Superlite functionality and unique benefits for this blocktech.