Verida Research Report: Implementing Micropayments on NEAR
Verida is building a protocol that gives users greater control and privacy over their own data. Our users can realise value from their data based on their decisions and choices.
Our mission is to help enable developers to easily build applications and abstract away the complexities of encryption, permissioning, schema enforcement, and user management.
The Verida protocol facilitates secure, auditable message interactions between accounts to facilitate consensual data sharing, querying, and messaging. Providing micro-payments around these data transfers is an integral part of creating an equitable data economy for user-owned data.
Overview
Verida recently completed work with blockchain development company 4ire labs to implement a proof of concept (PoC) assessing the viability of the NEAR protocol to operate as a micropayments solution for peer-to-peer data transfers — known as message interactions on the Verida network.
The PoC dived into the practical real-world challenges in linking data movement between users with NEAR blockchain transactions. Chief requirements included cryptographic provability and an economically-stable currency. The PoC also provided a deeper understanding of the performance capabilities and implementation specifics for a future micropayment solution on the NEAR protocol, and is the first of our research reports into what is possible on decentralized data networks.
PoC goals and objectives
The technical goal of this PoC was to demonstrate the viability of processing micropayments on the NEAR protocol. The team designed a system architecture enabling micropayments, aiming to meet the following objectives:
- Support stable fiat pricing using a single Verida token (VRD)
- Measure the real-world performance on the NEAR protocol to determine the viability of achieving secure sub-second payments and transfers of ownership of data assets.
- Model and estimate the expected real-world cost of micro-payments on NEAR protocol as the number of micro-transactions increase across the network and the NEAR token price increases due to demand.
- Evaluate platform scalability by conducting at least 10,000 NEAR testnet transactions that validate real-world metrics.
- Assess potential information security risks and economic attack vectors on the proposed micropayments architecture.
Several areas were identified for further technical investigation and are listed further in this document. In particular, the characteristics of NEAR’s storage scalability in the context of micropayments at scale, and the associated costs, are left to future work.
Architectural requirements
Data transfer micropayments require on-chain transactions for each data transfer. Users who wish to transfer data require a NEAR address and VRD. The data sender (the seller) provides a prepared data transaction hash to the receiver (the buyer), who in turn makes a payment and adds the payment transaction hash to the data transaction.
Once the receiver completes making the payment, the sender will confirm the transaction and provide the requested data. Settlement for the trade will be made in VRD, while NEAR tokens are required to pay the blockchain network to commit the transactions (“gas”). The data sender can hold, use, transfer, or sell their VRD after the transaction.
Below is an architecture diagram that summarizes this flow.
Nature of transactions
Given our main objective to support micropayments in an open data market, the value of each trade is likely to range considerably (e.g. from $0.01 to $100). The Verida payment flow consists of three parts: the main payment to the data owner and a protocol fee that is distributed to app developers and community token holders.
NEP-141 is the NEAR fungible token standard and has a decimal precision of 24 digits. As such, the minimum value transfer of 1 * 10^-24 provides excellent precision and values below this threshold are considered negligible.
Rate provider
As is the case with all forms of currency, the market price for VRD is subject to market conditions of supply and demand. Nonetheless, we propose a stability mechanism in this PoC to price settlement micropayments in USD using stablecoin natively provided on NEAR. A pricing Oracle¹ is used by the smart contract to provide an instantaneous exchange rate for VT/USD for all calculations. The oracle smart contract monitors the rate on several platforms simultaneously to ensure the soundness of the USD peg, and creates new “update transaction” requests as appropriate. In the PoC, we also built a system to emulate an external rate provider, returning the current exchange rate using a buffer of preset rates to simulate price volatility.
Solution: Using Verida tokens and a dynamic rate provider
Our PoC confirms the viability of using VRD and a dynamic rate provider as a practical solution to establish a stable and frictionless micropayments infrastructure on the NEAR blockchain.
The advantage of implementing this architecture as our solution is that there’s only one token in the ecosystem — the VRD, which supports organic demand. This provides incentives for the data sender (seller) to hold the Verida token as the project grows. However, for it to work efficiently, the oracle must remain available and accurate².
Cost analysis
Account creation
The NEAR blockchain provides two ways of creating accounts — explicitly and implicitly. For explicit (standard) NEAR account creation on the main net or test net, users will require 0.0006 Ⓝ. Using the current exchange rate of $5.10 at the time of writing (25th August 2021), this equates to 0.00306 USD (0.0006 Ⓝ*5.10 USD/Ⓝ).
If we consider a conservative cost for the NEAR Protocol token price of $8 (being the all-time high), the highest cost of creating a standard account at the time of writing would have been 0.0048 USD (0.0006 Ⓝ * 8 USD/Ⓝ).
For implicit accounts, the cost of connecting to a NEAR smart contract is 0.00019 Ⓝ. Compared to the standard account, which costs 0.0006 Ⓝ, users save around 0.0004 Ⓝ or 0.00204 USD given the current exchange rate of 5.10 USD/Ⓝ at the time of writing. Although using an implicit account is cheaper, using standard accounts provides the benefit of a human-readable address which is an important consideration in end-user experience.
Transaction cost
The transaction cost is determined by the price of the NEAR token and the gas price. Gas represents the unit cost of securely processing blockchain transactions; each transaction requires a certain amount of gas for successful execution. Every gas unit has a price in NEAR that is driven by market factors. To determine end-user gas costs to send transactions on NEAR, we multiply the gas units used by the gas price. Gas prices are relatively predictable but not fixed. Each block automatically adjusts the gas price based on demand. If gas prices increase significantly due to transaction demand, the NEAR protocol will respond with resharding³.
Given the current contract complexity and gas price (0.0001Ⓝ/Tgas), the average cost of one transaction is 0.00089 Ⓝ. This translates to 0.004539 USD per transaction using the current exchange rate (0.00089 Ⓝ * 5.10 USD/Ⓝ) and around 0.00712 USD using the NEAR protocol all-time high price (8 USD/Ⓝ). This is based on the price of NEAR in USD at the time of testing on August 21st, 2021.
Impact of NEAR price volatility on transaction costs
A key element of our PoC was to consider the impact on transaction fees (gas) as a result of NEAR token price volatility. When modelling NEAR prices and transaction fees, the following assumptions were made:
- The gas price and contract complexity remains constant.
- The minimum transaction value on the Verida network is $0.05 (5 USD cents).
- The empirically calculated fee value remains 0.00089 Ⓝ
The table below shows how the transaction fee changes as the price of NEAR increases, starting from $0.52, the all-time minimum price of NEAR. In the third column, we have the transaction fee as a percentage of the minimum transaction value ($USD 0.05).
When the value of NEAR rises above 19 USD/Ⓝ, the transaction fee becomes a third of the reward. Losing over 30% of the network rewards to transaction fees will have a significant detrimental impact on the viability of the network to provide meaningful rewards to participants in the network.
The following graph depicts the effect of increasing NEAR prices on the transaction fee as a percentage of the minimum transaction to the NEAR price.
Network sharding and fees
At the moment, the main network is configured to use only one shard, however, the network will automatically spawn new shards as the number of transactions increases⁴. It’s expected the cost of NEAR gas fees will reduce once sharding is enabled. This will help maintain low transaction fees in USD.
Further information from NEAR and additional modelling is required to assess the viability of sub 0.01 USD gas fees to facilitate micropayments long term. While it’s anticipated sharding will help keep gas fees low, there’s currently limited information available to validate the extent to which this will be effective.
Performance analysis
The performance of the Verida micropayments solution depends on a number of factors, including the blockchain confirmation time, maximum transactions per second, and network capacity. The NEAR protocol is a sharded blockchain, but currently running on a single shard. Shard throughput is expected to range between 400–2000 TPS⁵, with up to 8 shards supported, helping improve performance and total transaction throughput.
Once a transaction is broadcast to the network, it will take a certain amount of time to execute⁶. In this PoC, we determined that the transaction speed depends significantly on how the Verida application connects to the NEAR blockchain. It’s important the NEAR node used by the application to connect to the blockchain is stable and can support a high throughput of transactions.
On the test network used for validating the PoC, the NEAR node was running on a separate network from our application. The time taken to perform a transaction was between 6 and 16 seconds. We could improve this speed by running transactions in concurrent threads and separate nodes.
Real-world results executed on the NEAR Testnet
Throughput testing was conducted to understand the overall operating capacity of the Verida micropayments solution on NEAR, creating 99,719 transactions and exceeded 100,000 calls⁷ on the NEAR testnet over 4.5 hours. We used 50 concurrent threads on the local client application machine, a single target node, and a single runner node when performing the tests. The overall processing time for running the test on our application was 4 hours and 27 minutes. During the tests, we transferred 313,553 VRD and spent 88.75 NEAR in transaction fees.
Creating 100 accounts with 50 threads took less than 4 minutes 28 seconds on the first run and less than 90 seconds on subsequent runs⁸. Various combinations of thread count and total transactions were executed up to 4 times each to determine average values.
The table below summarizes our results.
The graph below illustrates the relationship between the time needed to perform 100 transactions by thread count.
Like the 100-transactions graph above, the time required to perform 1,000 transactions reduces as the number of concurrent connections (threads) increases.
Although increasing the number of threads improves the network throughput initially, our results suggest maintaining concurrent connections per node to between 20 and 50 given the small incremental improvement in throughput above 50 threads. These recommendations are dependent on server capacities and network bandwidth.
Key performance issues observed
- Count of the parallel connections
Our test results indicate that the maximum number of parallel connections on the test node is around 50 to 60 connections. Our node appeared to saturate approaching 100 connections, resulting in a significant number of dropped connections. Monitoring of node network health and connection liveness in particular is recommended in production to ensure the server is optimised.
- Network connection issues
When performing Verida PoC tests, we placed the test node on the Internet. The stability of the Internet connection was, therefore, a point of concern since we experienced about ten minutes of unstable connection over the 4.3 hours test duration.
We could optimize the system architecture by providing additional NEAR nodes and ensuring they are as close as possible to Verida applications submitting blockchain transactions.
- Client-side validation
The micropayments solution should ensure client libraries perform as many possible validation checks before submitting transactions to the blockchain. These include verifying sender/receiver addresses and ensuring adequate account balances. This will minimize the chance of the smart contract failing a transaction and spending unnecessary gas fees.
Typically, the smart contract treats each sender as a client, which means we should enforce strict client-side validation. This could be achieved by performing duplicative validation on the client-side. Here’s an example transaction validation on the test net that fails since the sender and receiver are the same entity.
- Smart contract monitoring and run-time errors
The system would need to deal with possible miscalculations or lost connections between the NEAR blockchain and the Verida application. While every effort will be made to ensure the smart contract is working as expected, additional ongoing auditing and monitoring of the on-chain activity is strongly recommended to identify any unexpected issues.
For example, a weekly check of all transactions to identify discrepancies between the number of transactions in the NEAR blockchain and a specific Verida application.
- Transaction cost and user experience
The solution could benefit from JSON serialization since serialized records consume less storage space, which ultimately reduces the costs. Another way of reducing the costs would be allowing users who do not plan to spend funds in the application to use implicit accounts. This would be a valid option since they would not need a human-readable address or use their NEAR account directly.
For an even better user experience, the contract could implement a pre-paid gas model to pay the gas fee or return fee compensation. If this is used, we’d need a protection mechanism against spamming transactions.
Security considerations
The security of the micropayments systems on NEAR using VRD is based on the following main factors:
1. Security of smart contracts
Most security vulnerabilities in smart contract-based applications stem from gaps introduced during the coding and development phase. An example security flaw would be contract phishing, where an adversary creates a proxy contract for Verida and uses it to exploit some users. To mitigate such an attack, we should add functionality that declines all unexpected proxied calls. Besides this, it is essential to adhere to best practice; perform exhaustive code reviews, penetration tests, and third-party audits.
2. Providing a secure price oracle
The price oracle, which will serve as the rate provider, is also a security concern. We should monitor it continuously to ensure the oracle is consistently and reliably providing accurate prices to the smart contract. It’s important that prices are being sourced from multiple exchanges.
3. Connecting to the NEAR blockchain
The micropayments system will need to enable applications to connect to nodes on the NEAR blockchain. It may be necessary for projects to run a full NEAR node, depending on their requirements. Verida may need to consider providing node infrastructure and a list of recommended nodes for end-users of the micropayments system.
4. Burning the commission
If the server delegates gas for a fee, we need to protect the project from creating an empty transaction or a transaction with a validation error. This will ensure users do not bear any cost.
Summary of risks and issues
The table below summarizes the risks associated with Verida Micropayments on the NEAR protocol.
Conclusion
The development of this PoC is a huge step forward in Verida’s journey of successfully enabling micropayments. We’ve demonstrated that it is possible to implement rapid and frictionless micropayments using VRD on the NEAR protocol. However, there is some concern about the NEAR token price growing ahead of on-chain transaction volume, resulting in high gas prices. Additional modeling and information from the NEAR protocol team would be helpful to assess this potential risk.
We would also like to thank 4IRE Labs, NEAR, and the Open Web Collective for their immense support throughout this initiative. Although we’re super excited about the progress, there’s still much more to do. We shall continue to conduct further research over the coming months and keep our community updated on new developments.
The NEAR ecosystem is facilitating successful development of user-centric applications for the next generation. As a developer, you can leverage the NEAR blockchain and Verida datastore to build powerful applications that give users control over their data. Register your project here and the Verida developer success team will help you get started.
Development references
- Implicit accounts: https://explorer.testnet.near.org/transactions/J3DPDFyXdwREFHoaZcfwBYvpkiJh2DP7S4HxW4Tmdj8T
- Client-side validation: https://explorer.testnet.near.org/transactions/ApPCzEgqBcBbnvbebGRJaj9EDgR9jrQzPAVxQQSZj5CJ
- Synchronization and run-time errors: https://explorer.testnet.near.org/transactions/5DcFCWJy3SPL2iV3xiptTyL8VxdNfPPPcJ622Rqksw8f
Citations
[1] A price oracle is used to provide a trusted price to smart contracts. https://docs.uniswap.org/protocol/V2/concepts/core-concepts/oracles
[2] This will likely use a service such as Chainlink
[3] https://near.org/papers/the-official-near-white-paper/
[4] https://gov.near.org/t/protocol-development-roadmap/2903
[5] https://near.org/papers/the-official-near-white-paper/
[6] Transaction latency
[7] We excluded network calls that had connectivity issues to only provide stable connection results
[8] Further work could investigate the underlying cause of this large discrepancy
