This week, we’ll take a bit of a deeper look at the whys and wherefores of a potential payment network.
@qi_ma and @davidrusu have been battling some nasty memory bugs in
sn_consensus and their knock on effects which have been delaying the integration of some membership improvements. That work is looking good, and is almost in.
@roland has been continuing to improve tests alongside learning more about OpenSearch, so we can leverage that tool for upcoming test networks.
The new consensus algorithm integration has begun. This should speed and shore up network decision making.
@bochaco has been working on establishing patterns for node interaction from the user. For example, allowing remote procedure calls to be made to do fun things like provide network analytics, as well some more test-network specific functionality like causing byzantine faults (pausing a node), restarting nodes and more.
We thought it might be useful for us to probe a bit more into what we mean when we talk about a payments only Network, how it relates to the test network we talked about a few weeks ago, and why we are looking at the potential of a launch strategy that starts at payments, and then adds features as we go.
First off, when we are talking about a payments network, we are still talking about the very same Safe Network. It’s the same underpinnings: same nodes, same codebase, consensus and everything else. It’s just in this case, we are looking at that data network only utilising those mechanisms to support the transfer of payments, storage of data relating to those transactions, the management, transmission and security of data around them, and other data processes that support the user experience and utility of the transactions.
The utility token at the centre of this is the Safe Network Token (SNT). This is the engine oil of the Network itself, and is necessary to run the underlying economy of the Network whether or not the Network is dealing with specific payments data, or any and every data as the full Network will.
So this SNT system, and its shiny new protocol utilising Digital Bearer Certificates (DBCs), needs to be complete, robust, and most importantly understood, adopted, and integrated into the wider economy in order for the full data Network to be broadly accessible, resilient and as useful as possible.
There are real advantages in launching in an incremental, iterative way, and why a payment focused network is an excellent candidate, worthy of exploring. It allows us to forge some resilience to the network and its economy ahead of when it will be needed most, and it enables us to directly demonstrate the power and potential of what we have all invested so much of our time and energy into. It’s creating something genuinely useful and getting there faster than we might otherwise with minimal—if any—duplicate work.
Just as an example of the value that it could bring if done right…
We see real potential in this payment network bringing the advantages of DBC to not only the underlying utility token, SNT; but to allow having it handle multiple currencies on top which could be natively atomic swappable… including to the SNT that handles the data payment and node rewards. Then layer this with, say, a global Network wide NRS system for usernames and addresses… and well, you can see how exciting things could get from a UX perspective.
It’s worth noting that the challenges of developing and launching a project as complex as this is strongly chain-linked. Where it all must work, or nothing will work. So finding strategic solutions where groups of these links can be taken as discrete elements, finding advantage, and reducing risk over all, is worthy of deep and close consideration. So that is just what we are doing.
You’ll be pleased to know that we have no concerns from a legal or administrative point of view, and none from the various test networks and test tokens required either. So part one of the evaluation is complete!
The rest looks a bit like:
- Technical Scoping
- Live Payment Testnet(s)
- Testing MAID Airdrop/Redemption
- Getting Ready for Go-Time!
We’ve said before, and don’t mind repeating, that the vision and objectives of the Safe Network and the project as a whole remain the same. But launching them is unlikely to be punching down on a big red button and putting our feet up. There are many moving parts, both technical and human, and external factors to consider too. So we can anticipate an incremental and iterative approach that steps towards that vision, in as sure-footed a manner as possible. And before you know it, we’ve reached the summit.
The full Safe Network will rely on the payments for storing data as well as transacting. The payments however do not rely on the data types
registers of the Safe Network. The payments are stored into their own, separate, data type.
So when we code the payments network, at a high level what we do is simply choose not to expose the APIs of
payments APIs however are still exposed, and those are the APIs that we are currently focusing on developing. The focus allows us to complete that part faster, and since we can see a way to run the network with only payments, it also means that we can see a running network with a functioning feature, faster.
That’s feature in singular, counting
payments as a single feature. It’s the essential feature without which the other features of
registers cannot function in a real network, since they need to be paid for.
Now, the network relies on resource usage to drive rewards and growth, and the resource usage we measure is storage space. However, the network doesn’t care what type of data we fill that storage space with…
payments. It’s all data.
We have generally been talking of only
registers as data, and considered
payments something else, which is not entirely correct under the hood. And that’s perhaps why many have been wondering how the network can be secure “without data”. The answer is that it’s still running with data, but it’s the transaction data only.
So, when we have a payment network, it’s the same network, same code that stores data, expands when more space (nodes) are needed, same membership with Elders and Adults.
It’s just that it only has the bare essentials exposed to make payments. So we can focus on that aspect first… with the aim to expand into the full
register storage and payment thereafter.
Feel free to reply below with links to translations of this dev update and moderators will add them here:
As an open source project, we’re always looking for feedback, comments and community contributions - so don’t be shy, join in and let’s create the Safe Network together!