Qwallet is being designed from the ground up to be an easy to use introductory wallet for Qubic users. The overriding goal is to be easy enough to use so that we can onboard a million users.
That is a lot of users and the current Qubic network cannot handle so many direct users of it, so there needs to be some layers in between. It turns out that to make Qwallet, we also need Qserver and Qclient, among other things. This article will discuss the various problems and solutions needed to achieve a million user Qwallet.
Qwallet itself is based on a wasm port of the low level Qubic crypto code derived from my C based port of qubic-cli. All of the seed management and transaction creation is done within the wasm, the UI then interfaces to the wasm module and provides easy to use view. Advanced users could actually use Qwallet in cli mode, but I am told this is only good for <1% of users!
The first version of Qwallet will just support basic function of generating seed and receiving/sending of QU. In the future it will get more and more functionality as we get more and more SC active on Qubic, especially looking forward to Qx trading in the Qwallet.
The first thing the user needs to do is create a seed! It can be a 55char seed like the normal Qubic does but Qwallet also supports the crypto standard 24 word seed. With the goal of 1 million users, even a 0.1% support rate is a lot and I do not want anybody to ever not be able to access their funds. So upon initial account creation it is insisted that the user prove they have a backup of the seed. This is critical as Qwallet does not save the seed anywhere, in fact whenever the seed is decoded and used it is immediately erased from RAM to minimize the chance of seed leakage.
The password is all that is needed to login to the account as long as the hashed seed file is present. If somebody with access to your computer also gets the password, then that is bad, so make sure the password is good enough that people who have access to your computer cannot guess it.
In case the seed file is lost, it can always be recreated with the backup of the seed. For advanced users, pre-existing seeds can be used, derived addresses can be linked to a seed and multiple addresses can be efficiently managed. However for the million users we want a very simple and easy to use single address user experience.
Being wasm + javascript based, it is expected that we can have a crossplatform Qwallet that runs on all desktops and mobile, but we have not confirmed the mobile part yet. The Qwallet gets network information from websockets connecting to Qclient. This is just a small module that runs on the same server as Qserver and uses memory based IPC to directly communicate with the Qserver. Qserver is the only module that actually connects with the Qubic network and it uses persistent connections to optimize network requests. Switching to persistent connections from a connection per request improved performance by 100x or more!
Each Qserver can handle a lot of Qclients that are spawned from websockets with every Qwallet that connects to it. The actual number of Qwallets a single server can handle is not yet known, hopefully tens of thousands. Still it seems we will need dozens of Qserver nodes, if not 100.
Qserver is what has evolved from the sendmany project that I wrote that does 15625 payments in 20 ticks using the QUTIL SC 25 payment call. It monitored thousands of addresses for balance info, this technique was improved and Qserver can monitor 1 million addresses as it is currently configured. It is not known yet what the limit of active addresses that can be monitored is.
As can be seen from the above, even after the initial Qwallet, Qclient, Qserver is completed, in order to scale up, we need to determine the limits of addresses that can be monitored per Qserver and whether that is more or less than the number of Qclients that can be supported. This is a key metric as that determines the number of physical servers that will be needed to support a million users. Of course there is nothing magic about one million, it can easy go above that and we need a system that can grow to accomodate however many users we get.
Now we switch to discussing economics as if we cannot economically support the Qwallet infrastructure, we cannot have a Qwallet for a million users.
As a basic wallet, it should be free to use and this will be the case. However, due to the technical nature of Qubic, it takes constant activity to monitor a wallet in realtime. This is also part of the equation for the number of users that can be supported. Roughly speaking 10x more users can be supported at 1/10th the refresh rate, so at a one minute refresh rate, we can have 10x the users per server than a once per tick refresh rate. As the initial premium offering, it seems reasonable to offer per tick update and full archival access for a nominal fee, something like 10 ticks per QU or about a penny per day.
Of course, the actual price will need to be based on market results and there can be all the various premium services that can be added as time goes on. The realtime update service is just the first one that allows to help scaling to a million users while at the same time providing some initial revenues.
The initial expected revenues will not enough to support the infrastructure costs, so clearly things need to be capitalized. The current thinking is that there will be a Qx asset created that will be used to reward nodes running the Qserver. 100% of revenues would then be distributed to the asset owners.
With the asset being earned by Qserver nodes being tradable on Qx (and via Qwallet itself) it provides immediate incentive to run a Qserver node. Also, if too many people run nodes, it would dilute the node revenues. This is a good market based equilibrium to make sure there are enough Qservers but not too many.
To provide enough funding to make the million user Qwallet/Qclient/Qserver possible to implement, a portion of the asset supply will be given to initial donors. All funds sent in excess of a million QU will go toward calculating the allocation of the asset. This covers the asset transfer cost. If exactly one million QU are donated, then it will not get any assets. If one million and 1 QU are donated, then 1 QU toward the allocation. If two million, then one million toward the allocation.
While the whales with the 1B+ donations will have transfer costs of 0.1% or less, even a 50 million QU donor will have a 2% cost, not horrible. The exact percentage between initial donors, Qserver nodes, team is not yet set and will be discussed in the Qwallet discord channel. Starting point for asset allocation would be 50% for donors, 35% for nodes, 10% for liquidity pool, 5% for discretionary use.
The donors will get their assets immediately, while the Qserver nodes over time and the liquidity pool when the QPOOL SC is ready. The purpose of the crowd funding is to get a self-sustaining infrastructure for a million user Qwallet in place. Whatever happens with the value of the asset is not the concern. Usage of funds will be split between liquidity pool and discretionary usage, let us assume in a 50/50 proportion. In this case, the default result will be that 10% of the asset will be backed by 20% of the funds, which will then be diluted by the assets issued to node operators and donors. If all donors immediately dilute, then only 25% value is left and that will be diluted by the node earnings, so it is important that the donors have a long term view to make sure we keep the node operators properly incentivized.
There are many unresolved issues, from whether it will work as it is on mobile, the number of users per Qserver, Qwallet revenue generation, asset allocation, funds allocation, etc. However the most important hurdle of technical viability is close to being able to be demonstrated and the fund raising will begin with alpha release of Qwallet.
A very important aspect of making this all possible is the QPOOL SC, this is needed to be able to distribute assets to node operators at low cost as the current million QU cost for Qx asset transfer makes it nonviable for small incremental amounts. Until QPOOL SC is ready, only Qx will be available for trading the asset.
