Version 1.2
Existing Internet infrastructure is increasingly unable to cope with the demands placed on it by over 2.4 billion connected people, a number that is predicted to grow to 3.6 billion by 2017. Today's architecture, where central intermediaries (servers) store and provide access to data is expensive and inefficient. Data centres use between 1.1% and 1.5% of the world's electricity (growing at 60% per annum) and represent significant expenditure for data centre owners, providers and businesses, who all have to pay to host user data and maintain the infrastructure. Security of user data has proven to be nearly impossible in today's networks with almost weekly reports of ID and password thefts.
To overcome these challenges a fresh approach is required, a solution that removes these inordinately expensive central points of failure, data leakage and bottlenecks. By developing a fully decentralised replacement for all Internet based services, Secure Access For Everyone (SAFE) will ensure the decentralised Internet is a reality, enabling:
- Autonomous handling of structured and unstructured data types
- Private and secure communications
- Data shared at the filesystem level worldwide, no need for http, smtp, ftp etc.
- Highly encrypted and private data at rest and in transit
- The ability for people to self-authenticate onto the network and join anonymously
- A network resistant to man-in-the-middle attacks or IP address identification
- A network that requires no administrators or human intervention of any kind
- No requirement for forward planning using infrastructure that automatically configures around its users in real-time (no data centres)
- A highly usable and free API that enables a plethora of developers to create the next wave of secure applications not currently possible with today's centralised architecture
- An underlying crypto currency called safecoin that will incentivise all actors in this ecosystem
SAFE is the culmination of 8 years of effort by MaidSafe.net and the continued and growing number of project developers. These developers will include MaidSafe.net and many other decentralised Internet application developers. Please see http://maidsafe.net for an introduction to the technology as well as https://github.com/maidsafe/MaidSafe/wiki for access to project documentation and code.
The inclusion of a crypto currency is not new to the maidsafe core design. It is a logical step included in the initial design many years ago (2006). Importantly, this proposal creates no founders pool or shares but, incentivises funders, developers, users and satisfies existing investors in MaidSafe. This allows MaidSafe to clearly show this network truly belongs to us all and in perpetuity. It is a hugely important step to ensure the network is widely used and worked on by many hundreds of developers who can see the potential for a fully secured, unowned and decentralised Internet. The proposed crowd sale will seed the network, expand the developer base worldwide and push the whole proposition to the wider community in a manner that is extremely clear and logical.
Formed in February 2006 with the intent to decentralise the Internet, the 14-strong team is based in Troon, Scotland. To reach this project stage, MaidSafe has taken investment from close friends and family, as well as supporters and Angel Investors. Further backing and supporters are required to push the platform out to the world and to incentivise network adoption.
It is also worth noting that the founder allocated all of his shares in MaidSafe to an employee share scheme (around 28%) and almost 50% of the business to a registered charity. This charity is the MaidSafe Foundation. The Foundation will be a key player in this proposal and exists to ensure fair distribution of wealth, while helping to foster education and innovation. Based in Scotland, the laws and regulations surrounding such organisations ensure there can be no profit motive for trustees or members of the Foundation. This is an important model for managing many aspects of a decentralised project such as SAFE.
At this time, MaidSafe has completed the foundation libraries and associated code. The API is being finalised in conjunction with application developers to ensure ease of use and this is being supplemented by examples and demonstrations. The network is preparing to go into wide scale testing and MaidSafe are hoping to implement this during the announcement of the funding round. At present, developers can download and run networks for test purposes.
Full public launch of the network will take place in the very near future. Earning capabilities will be added to nodes over a period of several weeks after the initial network testing is carried out and any issues and critical bugs are resolved. MaidSafe will be hosting weekly public Google Hangouts over this period to answer any questions and assist application developers first hand.
In many cryptocurrencies and decentralised networks a proof of something is required to allow the network to validate actions or services via a mathematically verifiable mechanism. In bitcoin this is achieved by a proof of work. This is essentially a hashing technique that requires significant (and growing) computer power to achieve. This technique allows bitcoin to confirm transactions and reward "miners" with a block of coins randomly.
The SAFE network can validate nodes and their value to the network in a very accurate and cryptographically secure manner. The SAFE project will use this to create a proof of resource (see Appendix) which has some significant advantages. The resource in question is a computer's ability to store data chunks, which depends on CPU speed, bandwidth, disk space and on-line time, amongst others. This allows the proof to be a useful, measurable and an immediately verifiable entity. Proof of resource is a very efficient mechanism as its cost is very minimal.
Additionally, as a fully decentralised network, the SAFE approach allows transactions to be made and confirmed at network speed (under a second in some cases). This is due to a distributed Transaction Manager as opposed to a blockchain. In the SAFE network, a transaction management system can be linked or not. Bitcoin uses a linked blockchain (the chain term) that allows traversal of all transactions from the network start. SAFE has chosen an unlinked approach to the blockchain. Each user's account information is held by the group of nodes closest to it (according to the XOR address distance). The Transaction Manager only holds a temporary receipt object during the transaction procedure among users. This temporary receipt can be stored permanently allowing proof of the transaction to be maintained or destroyed immediately after the transaction is completed, leaving no trace on the network. In addition to allowing instant transfers of coins, this mechanism also allows an escrow model (a third party acts as moderator to resolve the payment dispute). This escrow mechanism is a core component of the currency.
For technical implementation details see the Appendix
History has demonstrated that having the most cutting-edge technology does not in itself guarantee wide scale use. To ensure the SAFE network is fully and efficiently utilised, a token-based scheme is proposed where all stakeholder groups have the ability to earn these tokens (safecoins) in a manner that is both fair and equitable.
Safecoin may be earned or purchased. The whole SAFE network is configured and designed to incentivise all parts of the community. The incentivisation is a critical component of a fully decentralised Internet. The MaidSafe code base is a part of this process, other application developers will add to this and be incentivised, users will be rewarded with safecoin for allowing their computer to be part of the network and funders who act as the catalyst will be able to purchase safecoin (via an intermediary MaidSafeCoin) directly, just prior to the full network launch. This will allow sufficient resource to be made available to launch the network worldwide and application developers to release free apps of significant value to us all. This project is simply the beginning of a new Internet, one that we all own and nobody controls, this is the "Internet sans frontieres!"
In essence, safecoin is a fair and transparent way of incentivising developers, backers and end users to use SAFE. As users sell their proof of resource, they are still earning safecoin due to the fact they are continuing to provide valuable network resources. Application developers can now use safecoin as their revenue model, enabling them to concentrate on providing amazing applications and not worry about revenue models and streams. Supporters can help to back a network that is focussed on providing common good while achieving returns that reward their willingness to take financial risk.
It is proposed that safecoin will have a predictable cap (232) with a value that is determined solely by the market. Safecoin will be a virtual currency with SAFE being used to complete transactions.
Many of today's centralised systems use advertising to monetise their existence, or actually charge for resources that are in fact exponentially decreasing in value (CPU, disk space, bandwidth, etc.). MaidSafe proposes an approach that should not only make resources cheaper, but should also provide a crypto currency (safecoin) that will increase in value, facilitating exchange both on and off the SAFE network.
This paper demonstrates the creation of a fixed number of coins over time 232 (~4 billion), which can be further subdivided to facilitate trading. It will be only be possible purchase proof of resources using safecoin on the network. This approach increases reuse of the coins, further incentivising miners. This proof of resource will represent disk space, CPU and bandwidth involved in storing shards of information. These resources will increase over time, creating a much desired increasing value for safecoin holders, while delivering exponential decreases in the cost of resources. The proof of resource algorithm will over time account for additional resources, such as proof of bandwidth, proof of CPU processing, etc.
In essence, this proposal will ensure computing resources are shared amongst all users at the lowest possible cost. MaidSafe believes this approach will provide the most cost-effective and efficient computing platform in the world, realising the company’s vision of an Internet for everyone, free from spying, privacy erosion and data loss.
The SAFE network is fully inclusive and enables everyone to get involved and become a part of the project, whether a supporter, end user, backer or developer.
As end users join the SAFE network anonymously, they will start a vault (a data storage and management location). This vault will add itself automatically to the network and start providing resources. These vaults require no setup and administration, they are a simple download and install. The network is designed to self-manage these resources and reward earners accordingly in a random fashion (uniformly distributed across the network), thereby securing the network’s data.
The earning speed is based on the storage space contributed to and verified by the network. For details of the calculation, please see Appendix ‘Token System on MaidSafe Network’. Note the developer and crowd sale lines are obscured by the IP pool.
If people were to try and game the system by providing earners to store data and then switch them off, they will simply remove their ability to earn. At some time in the future it is envisaged the network will be able to detect such data and remove it from the network. In the meantime, this kind of attack is costly to the perpetrators as their earning potential is adversely affected by their actions. This strategy also allows the network to arbitrate and manage resources mathematically and reduces the effects of the tragedy of the commons type deficiencies, requiring users to provide resources in an honest manner.
Unlike many currencies, the distribution of safecoin is backed by information. This information represents the world’s data and grows exponentially. Unlike gold, which only increases at circa 1.5% per annum, the quantity of safecoin will initially burgeon. This is akin to the California gold rush, where the quantity of gold grew quickly with enthusiastic miners. In safecoin this is mirrored by the network building to the stage where it is protecting all of the world’s data. During that time the mining frequency will be exponentially decreasing.
When all of the world’s data is secured, mining will naturally slow to a pace that just keeps up with the fungibility of the whole system and the increased resources under it's protection. This will be possible as people trade safecoin for network resources. These resources are initially data, but will likely grow to be bandwidth (to allow satellite and mesh networks) and processing power (for decentralised mass calculation work) amongst others.
The number of resources will be calculated by the network dynamically and in perpetuity. The value of individual safecoin will be market determined and this is an important notion. The number of coins in circulation is network led and the individual value is market driven. As people trade safecoin for goods and services this market value will be realised.
MaidSafe's figures forecast an estimated mining rate over time, this forecast is completely dependent on a number of assumptions including; speed of network adoption and the amount of data stored…etc. MaidSafe does not see this as an obstacle, rather a huge opportunity. Competing in today’s market using the SAFE proposition is an enormous advantage to developers (many of which are described in this paper) and to do so in an open network which is owned by no one is very compelling.
To allow distributed ownership of the network, MaidSafe will allocate 15% of the tokens on day 1. The coins allocated are fungible, particularly in the form of resources as backers reach their required returns or simply trade the coins. This allocation of safecoin will allow two separate entities to be rewarded:
The current MaidSafe investors have invested for the past 8 years with complete faith and desire to make a difference. These investors have been the very reason the technology is now developed and this proposal possible. Five percent of the safecoin issue will be laid aside for these investors and as safecoin is increasing in value, current investors will be able to swap their shareholding in MaidSafe.net for the coins. The coins will be held by the MaidSafe Foundation for issuance at the request of each shareholder. The safecoin here will be allocated at the point miners are introduced onto the network.
This allows investors to be rewarded for their help over the years and will also allow MaidSafe equity to return to being owned completely by the Foundation. This approach will ensure that MaidSafe as a company is not in charge of the SAFE network and shareholders are treated with the respect they deserve. When they are allocated safecoin they can hold these as any backer will today.
A crowd sale will enable everyone worldwide to seed and be a part of the SAFE project. This will enable a direct purchase of ten percent of safecoin, these will be issued immediately. Initially this round will value the SAFE project at circa $12M (as only 10% of coins have been released at this point). As miners begin to earn and developers release products, this valuation should very quickly increase. This figure appears reasonable as investors from eight years ago invested at a $15M valuation. These crowd sale participants will purchase MaidSafeCoin, this coin will be issued via the Master protocol suite and will be directly convertible to safecoin as soon as earners (miners) appear online. This allows immediate benefit to the project and will demonstrate the desire of all of seed funders to decentralise the Internet, enabling a plethora of new and exciting companies to emerge and provide us with true value at little cost.
Funds raised from this round will be held by the MaidSafe Foundation and will be utilised to house the MaidSafe core team and provide financial assistance for a period of three years. It is assumed that after three years, the core MaidSafe team will have grown significantly and introduced further innovations into the space. There is no founders pool and the MaidSafe developers and team are not issued any safecoin and must earn these through commits to the code base and further innovation. This is a very important aspect of this project. No team should be rewarded by safecoin who have not provided value in some respect and this is particularly important of any existing development team.
MaidSafe proposes to reward developers in 2 ways. Firstly, safecoin can be earned by contributing bug fixes and code that are accepted into the master branch of the SAFE codebase. Secondly, developers that create apps that do not charge end users and are of benefit to the community will also be rewarded. The issuance mechanism for both groups will come via the MaidSafe Foundation. MaidSafe the company will also generate coins by providing P.O.R when they seed the network with several hundred nodes during final platform testing. This seeding stage will be public and others are welcome to contribute resources. It should be acknowledged that until the network is declared ‘ready for general use’ that the coins may be destroyed from time to time and the network restarted. There will be no private or hidden seeding of the network and announcements will be made at a minimum via the mailing list during these events.
15% of all safecoin earned will be allocated to the developer pool. This will ensure the developer community is highly motivated and rewarded for providing free-to-use applications and improvements to the underlying codebase that utilise safecoin as their revenue model.
It is proposed that code commits and third party projects be chosen by polling the MaidSafe developer mailing list and payments will be allocated from the Foundation to successful projects/code enhancements.
The mining speed per vault is projected as:
| Time | Number of coins |
|---|---|
| first day: | 3 |
| first week: | 28 |
| first month: | 150 |
| first year: | 3600 |
The size of the seeding network is estimated to be around 10,000 vaults, that being the case it is projected that the monthly income will be around 1.5M coins and 36M in total during the first year.
Third party developers will also be incentivised outside of the token scheme. Choosing to develop their applications and businesses on the SAFE network will, when the network reaches critical mass, enable them to outperform all incumbents, while providing privacy and security to all their users. The network code is free to use and there are no upfront charges for API keys or developer programmes. Developers’ customer acquisition costs will be a fraction of the levels compared to traditional architecture due to the lack of infrastructure costs.
The crowd sale will be operated as follows:
- A fixed number of MaidSafeCoin will be issued and purchased in this round.
- Within that period, public funds in the form of bitcoin and mastercoin can be sent to a bitcoin address set up by MaidSafe; this address is called the Origin address.
- Each backer will purchase MaidSafecoin in this round. This will be directly transferable to safecoin on network earner launch.
- A quantity of 399,993,442 coins will be purchased for an initial value of 20,333 per bitcoin or 1,464 per mastercoin. (crowd sale total $12,000,000).
- The corresponding amount of safecoin will then be credited into the MaidSafe account created by the network and convertible directly from MaidSafeCoin on a one to one basis.
- Any unsold MaidSafeCoin will be split 50/50 between the existing investors and the developer pool. These developer coins will be allocated to fully planned out and resourced projects initially, to encourage rapid adoption.
After this stage is complete there will be no further funding of this sort available on the SAFE network with safecoin.
Any funds allocated outside the funding round will be allocated to the MaidSafe Foundation and added to the decentralised application developers pool.
The incentivisation of decentralised application projects that are funded via safecoin should also ensure very active decentralised application participation into a very powerful ecosystem with a pre-prepared revenue model. It is also thought this model will encourage a more decentralised and distributed pool of backers. This model is very much in line with MaidSafe’s core values and decentralisation in general, using logic and fairness with as few ‘magic’ numbers as possible.
It is interesting to note this kick starter does not hold any safecoins for the founders; no founders’ pool is involved. MaidSafe will work with funds raised and commit to continue to develop the internal library code to earn coins in the future, provided the code is accepted by the community (as per the acceptance criteria agreed on at that time by the mailing list participants and Foundation board). It is also the founders’ belief that if MaidSafe or any other group do not continue to innovate, they should not continue to strive as businesses. This allows the community to always be presented with the most efficient code and advancements to the system regardless of which entity makes those advances possible.
In this manner, MaidSafe will ‘eat at the same table’ as all other developers in the SAFE network and all application providers that will earn revenues via the safecoin model. It is envisaged that this approach is a very fresh and healthy model with the appropriate levels of risk and reward for all stakeholders.
The MaidSafe Foundation will initially:
- Hold and distribute safecoin for developer pools.
- Manage issuance of MaidSafeCoin to funders and existing investors
- Hold all patents and use safecoin to pay for the upkeep and further patents for all projects (until this sphere cannot be litigated against, the MaidSafe Foundation will act as the holder of defensive patents, of which there is already a considerable worldwide portfolio, to protect the decentralised Internet).
- House the MaidSafe team in an HQ and provide funding for independent development pods, worldwide
- Provide finances for the core team and development pods for a period of at least three years (we have already started discussions with a person in San Francisco to begin this process immediately on funding, we hope to have at least six such pods, worldwide in year one)
No further actions can be taken by the Foundation, unless the authority is requested by the community to add additional objectives to this list.
Board members will be appointed from the community via polling. This board should be selected from as wide a catchment as possible and include 3rd party developers, core developers and members of other decentralised projects (e.g. Mastercoin, Invictus). The board members will be continually up for election. If the polling shows the community wish a member to be removed then the next meeting will remove that person and they should be replaced by the next in line, selected again via polls.
This group will ensure the correctness of the coin issuance and also that every project that is applicable is included in the polling system for funding of that project. The board can put forward their suggestions and conclusions for any funding for projects. The assurance of developer rewards will also be continuously-monitored and managed. This mandate will be kept as minimal as possible to prevent unfair or inaccurate decisions being made.
An early project on the network will be a decentralised digital voting system. This system will be used to select and continually manage a member’s position on the board.
Version 1.2
Last Updated 19 March 2014
The SAFE network [ref Network] utilises a mathematically complete, peer-to-peer Public Key Infrastructure (PKI) authorisation on an autonomous network [ref Autonomous], secured key-value storage and reliable Kademlia based routing [ref Routing]. The network is designed to be decentralised and has the ability to get rid of Domain Name System (DNS). The PKI solution deployed within the SAFE network validates a user’s identity with mathematical certainty.
Bitcoin [ref BitCoin] has proved the ability of crypto currencies to disrupt the status quo. Bitcoin proposed and executed a very innovative idea, coupled with a well-considered system design based on the block-chain and proof-of-work concepts. In essence, Bitcoin is a partially-decentralised (due to the use of the block chain) digital currency on a centralised network. MaidSafe propose a token based economic system on the SAFE network. In effect, a decentralised digital currency system on decentralised network.
With the SAFE network, it can be assumed that the majority of a close (XOR distance as defined by Kademlia) group of nodes is trustable. While not impossible to generate a majority of malicious nodes in a close group around a particular target, it should be considered computationally unfeasible.
On the SAFE network, the following rules ensure a trusted group:
- It is hard to have a vault with a particular address (the address of a new vault will be defined by the network using the hash of the vault’s credentials). In addition, each time a vault is switched off and then rejoins the network, it will be assigned a new address. Furthermore, the node will not be considered a full functional vault until the verification period is complete.
- When a request is emitted from a group, all group member’s signatures will be attached. On the receiver side, a routing level find closest verification will be carried out to verify the senders are really closest nodes to the target. In addition, the public keys for the nodes will be downloaded from the network to validate signatures.
- The exchange of a vault between different users is not allowed. It is possible for a vault not to be linked to an account (unowned) and then linked to an account later (owned). However, once linked that vault cannot be detached.
Furthermore, there is the RUDP [ref RUDP] layer which encrypts communications between nodes to prevent the message content from being secretly modified by a third party. This ensures the request reflects the real intention of the sender.
Once the majority of the nodes inside the group have sent out a consistent request, it shall be considered valid.
Once the majority of the nodes have decided to perform the same action, the action shall be considered valid.
The Trusted Group feature, delivered by the SAFE network, ensures the system is secure as long as the majority of the nodes are honest and it is computationally / economically expensive to form a malicious node.
On the SAFE network, vaults assume various personas or roles [ref Persona], depending on the requests they receive. For example, the Data Manager persona is responsible for managing the integrity and availability of a given piece of data on the network. A separate persona, the Transaction Manager, is proposed to handle all the token-related transactions. A Transaction Manager group will be a trusted group of nodes which are closest to any given transaction identity. The Transaction Manager is responsible for the business logical to complete a transaction.
Structured Data Versions (SDV) is a data structure which allows the creation and handling of a version tree. The entire version tree is addressed by a randomly-chosen ID. This data type is managed by the Version Handler vault persona. A Version Handler group is the trusted group of nodes closest to the SDV ID. Each entry (version) in the tree will have the format <version_number, immutable data / data_name>. One use for this data structure is to store versions of directories on a Virtual Filesystem offered by Maidsafe-Drive.
Based on the token types, the Transaction Manager persona will be creating variation of SDV types. SDV related to tokens and transactions can only be created and updated by the Transaction Manager group around it. The Random ID associated with the version tree can be directly used as the token name, or can be related to the transaction ID. If the SDV contains different payloads it can be used in different ways; as a transaction, as a token itself, as a wallet.
The Transaction Managers for a token are group of Vaults close to the token name, the same group will also act as Version Handlers for the SDV tree which the Transaction Manager will be handling (or can be separated by introducing an additional layer of Hash(token name)).
The Transaction Manager’s functionality can be further detailed by considering the relationship between the token creation and token exchange mechanism. If a new token is mined, a SDV tree with the same name as the token identity will created by the Transaction Manager.
The first version (root of tree) will be <0 (id with all bits zero), Hash(name of the token holder)> (using Hash of the holder name to prevent leaking user info). As only the Transaction Manager can update the versions, they 'own' the SDV in the network sense, but the current tip-of-tree inside represents the token holder (creditor). The Transaction Manager only authorises the owner of the token to carry out a transaction.
So, say for token "nnn" the current token holder is "abc" and he wants to give the token to "xyz". abc sends a valid request : "Token Transfer Request abc to xyz for token nnn" to the Transaction Managers at "nnn". The Transaction Managers get the tip-of-tree for SDV "nnn" and check it says something like <999, hash(abc)>. If hash(abc) is not the last owner of the token, it doesn't have the right to transfer the token and the request fails. If hash(abc) is listed as the last version of the tree, the transaction will progress and the new version will be created by the Transaction Managers and will be stored on the Version Handler as <1000, hash(xyz)> and xyz is now the token holder(owner). Anyone can get these versions to validate the transaction including abc and xyz themselves.
In this example, the version names represent actual MAID names (or MPID names or whatever). We could of course do the more complicated thing and have abc and xyz represent ImmutableData chunks which the TransactionManagers can create/encrypt/store/get. By doing this, the ImmutableData part becomes the payload part, and SDV can be used as transactions or wallets or anything else.
The transfer mechanism is defined as: ‘allowing a transaction (transfer of credit from A's wallet to B's wallet) between two user's persona groups to be completed’. The transaction shall be open and read only to public (allowing upper layer third party broker app to validate there is transaction happening/completed).
The SAFE wallet is defined as : the place holding the credits (and the credit change history) for an account.
The procedure of a transfer (user_A transfers credit to user_B) can be illustrated as :
-
User A makes a function call : user_A.Transfer(user_B, amount, wallet)
-
When the Maid Manager group of user A receives a request, they :
i) debit the amount from user A's wallet
ii) send a request to the TransactionManager
iii) send a notification to the upper layer API
-
When the Transaction Manager group receives a notification, they :
i) send a notification to user B's persona
ii) create an internal transaction
-
When user B's Maid Manager group receives a valid notification they :
i) send an acknowledgement to the TransactionManager group
ii) credit user B's wallet with the amount
On the SAFE network, a user contributes to the network by running a vault, which will handle requests and store data for others. The following parameters are used to measure a vault and a user account:
-
stored_space: the total size of chunks that have been stored to that vault by the network
-
lost_data: as data is stored on a node it may switch off or be otherwise unavailable, we consider this to be lost data. This is a critically important measure and in no way means the network has actually lost data as replicant copies are always available. This is a common practice for a node on the network.
-
healthy_space (h.s.) : h.s. = stored_space - lost_data ------ ①
-
available_space: the storage space a vault claimed (via the user) it can contribute to the network
-
data_cost: the same user storing the same chunk will only be charged once (at the rate of 4x chunk size for the first time, to cover the initial cost for the network to keep 4 replicant copies). Other users will also be charged for putting the chunk, but at the rate of 1x chunk size. The charge will be capped at 50 users. (The subsequent users paying for the chunk covers the case where the initial storer disappears from the network)
-
used_space: total data_cost of all the chunks that user put to network
The Proof Of Resource (P.O.R) is derived from healthy_space (which is a kind of QoS measurement)
- P.O.R will be updated when healthy_space updated in bi-direction
Δ P.O.R = Δ healthy_space ------ ②
This ensures P.O.R becomes a huge negative when the user transfers out P.O.R and then switches off their vault
- P.O.R will be checked when a user tries to PUT data. (used_space + data_cost ) < P.O.R ------ ③
A user’s initial allowance will be granted by setting used_space to negative claimed available_space. If any cheating is detected, the used_space will be changed to reflect that.
This will also cover for situations when a user’s P.O.R drops low by allowing the user to mutate his free allowance data.
-
P.O.R is transferable among users
-
P.O.R shall be an int in a unit directly derived from size unit KB (MB ...)
-
The Maid Account will be the wallet of the P.O.R, and the Maid Manager group will be responsible for processing any updates.
-
P.O.R shall be considered as a standard unit being recognized by all nodes across the SAFE network.
| User A | User B | ||||
|---|---|---|---|---|---|
| Action | (used_space, stored_space, P.O.R) | Allowance | Action | (used_space, stored_space, P.O.R) | Allowance |
| Create Account | (0, 0, 0) | 0 | Create Account | (0, 0, 0) | 0 |
| Picked by Network To store 50 data | (0, 50, 50) | 50 | Never picked up or don’t have a Vault | (0, 0, 0) | 0 |
| Store 20 data to network | (20, 50, 50) | 30 | Nothing Done | (0, 0, 0) | 0 |
| Sell 20 P.O.R to User B | (20, 50, 30) | 10 | Buy 20 P.O.R from User A | (0, 0, 20) | 20 |
| stored_space decreased by 10. Q.O.S drop or stored chunk removed by network | (20, 40, 20) | 0 | Store 10 data and get picked to store 10 | (10, 10, 30) | 20 |
P.O.R is proposed in order to facilitate the exchange of storage space on the SAFE network. However, as it doesn't have a predictable cap number, it may not be considered a genuine virtual currency. To provide a more robust form of exchange, MaidSafe proposes a token system that is totally independent of P.O.R, called safecoin. Safecoin will have a predicatable cap and will be injected into network using the storage space related mining procedure.
A bridge (converting rate) between P.O.R and safecoin can be established by the market solely. With third party upper layer broker applications, it will be possible to use safecoin to buy P.O.R or vice versa (user_A give safecoin to user_B in exchange for user_B's P.O.R). It is expected that the per unit value of P.O.R will keep decreasing, while the per unit value of safecoin will continue to rise. In this way, it will be possible to buy more and more P.O.R with one safecoin. Safecoin will only be stored in the Maid Account wallet, this can only be updated by the Maid Manager group.
The value one safecoin represents will be recognised by all peers across the network and outside the network. If the economic system works as intended, safecoin will become a ‘virtual currency’ with the SAFE network being used to complete all transactions. Meanwhile, P.O.R will solely be used for exchanging space allowance among users.
A projection of P.O.R. is estimated as :
| Network Wide Total Data | Copies | Traffic | De-Duplication Factor | P.O.R | Nodes | Data Put per Node | P.O.R per Node |
|---|---|---|---|---|---|---|---|
| 1000 | 4 | 1 | 1 | 5000 | 100 | 10 | 50 |
| 3800 | 4 | 0.9 | 0.9 | 17100 | 200 | 19 | 85.5 |
| 10800 | 4 | 0.8 | 0.8 | 43200 | 400 | 27 | 108 |
| 27200 | 4 | 0.7 | 0.7 | 95200 | 800 | 34 | 119 |
| 64000 | 4 | 0.6 | 0.6 | 192000 | 1600 | 40 | 120 |
| 144000 | 4 | 0.5 | 0.5 | 360000 | 3200 | 45 | 112.5 |
| 313600 | 4 | 0.4 | 0.4 | 627200 | 6400 | 49 | 98 |
| 665600 | 4 | 0.3 | 0.3 | 998400 | 12800 | 52 | 78 |
| 1382400 | 4 | 0.2 | 0.2 | 1382400 | 25600 | 54 | 54 |
To prevent a potential shortfall of P.O.R, it is proposed that safecoin can be converted into P.O.R directly (network level). However, to maintain a predictable cap on the number of safecoins, the network will not allow P.O.R to be converted back into safecoin.
The conversion rate (safecoin => P.O.R ) can be established as:
conversion rate (P.O.R / Token) = PT / NT ≈ (PTlocal * (AS / ADlocal ) ) / NT ------ ④
where: PT is the current total of P.O.R across the network
NT is the cap number of token
PTlocal is the current average P.O.R across the local group
AS is the total address space
ADlocal is the average address distance among the local group
given: both data and node_id are evenly distributed
Once a safecoin has been converted into P.O.R, that token will be recycled, i.e. the token will be marked as not occupied, allowing other user to re-mine it.
Safecoin issuance will be capped at 2^32 (4.3 billion). Unlike P.O.R, which is just an integer number held in the Maid Account, each safecoin is represented by an SDV, holding a list of owner history. The data structure of such an SDV can be illustrated as :
| Field | Length | Format |
|---|---|---|
| name | 64 Bytes | See below |
| metadata_field | ||
| version n-1 | 72 Bytes | [version_num, hash(prev_owner)] |
| version n | 72 Bytes | [version_num, hash(cur_owner)] |
The name of a safecoin is 64 bytes long to allow it to be a network-addressable object. However, the name has a particular format:
[ 32 bits: Token ID | 224 bits: ID padding | x bits (x <= 248): Subdivision bits | 248 - x: Random | 8 bits: Value of x ]
The initial part (Token ID) inherently limits the total number of tokens available to 2^32 since each token must have a unique ID.
The second part (ID padding) must be predictable (e.g. it could just be all ‘0’s, or it could be the ID concatenated 7 times). Its purpose is to force all subdivisions of a given coin token the same trusted group of vaults to eliminate the need for network traffic when handling such subdivisions.
The third part defines the subdivision name. For example, if x == 1 (regardless of whether the value of that bit is 0 or 1) then that token represents a half of the original token.
The fourth part is random padding.
The fifth part indicates the level of subdivision of the original token, i.e. it contains the value of x.
This format allows the tokens to be split into 2^248 parts if required. The splitting process will only allow the token (or subdivided token) to be bisected, so e.g. quartering a token would need to be done in 2 steps. When splitting a token, only the name changes; all other parts are copied to the new subdivisions. The split results in 2 SDVs, each representing a half of the original SDV. This procedure is further illustrated in the following diagram.
The following diagram illustrates the transaction structure for RPC requests and data structure in Transaction Manager. It has the capability to support moderator model (like multi-signature [ref Escrow] [ref BIP16/17] proposed for Bitcoin) and third party virtual currency (such as MasterCoin protocol [ref MasterCoin]).
The following table illustrates the evolve of user accounts holding safecoin, together with the transaction and safecoin SDV held by Transaction Manager.
Every mining interval, the Pmid Manager group around a vault will perform the mining for that vault. The Pmid Manager will generate a Random Attempt Target (R.A.T) based on the following calculation:
R.A.T = Hash( (merkle_tree_root + msg_id) XOR R.A.T prev ) ------ ⑤
where : merkle_tree_root is generated from all the chunks stored on that vault
msg_id is the agreed random ID among the Pmid Manager group.
The R.A.T will then be sent to the Transaction Manager as a SDV creation request, claiming the ownership of that SDV on behalf of that vault.
The Transaction Manager will try to create an SDV with that name, and the last owner shall be the hash (maid_name).
If that SDV already existed, the Transaction Manager will then try to update all that SDV's sub-dividents which are not taken yet.
The Maid Manager group of the maid_name will be notified when the Transaction Manager created or updated an SDV successfully, otherwise the request is muted.
The mining interval allowed for a vault is determined by its contribution to the network. The interval is calculated as follows:
when healthy_space is greater than 4GB : mining_interval = 25 - min(24, healthy_space / 4GB) (hour) ------ ⑥
i.e. the quickest mining speed is one attempt per hour and the slowest is one attempt per day (24 hours)
Continuous connection time of each vault is used, i.e. when a vault is switched off / disconnected, the interval timer will is stopped and reset, generating no coins for the offline vault.
Following is the estimation of MaidSafe network size, the average mining attempts and the total attempts along time : (table network projection)
| Number of Nodes | Attempts Per day Per node | Total Attempts along time (years) | ||||
|---|---|---|---|---|---|---|
| 1 | 2 | 5 | 10 | 20 | ||
| 10000 | 6 | 22 million | ||||
| 50000 | 12 | 438 million | ||||
| 100000 | 15 | 2.7 billion | ||||
| 200000 | 20 | 14.6 billion | ||||
| 500000 | 24 | 87.6 billion |
Given the collision probability as : (table collision probability) where N is the total space
| Collision Probability | Num of Attempts |
|---|---|
| 10% | 0.105 N |
| 20% | 0.22 N |
| 30% | 0.36 N |
| 40% | 0.51 N |
| 50% | 0.69 N |
| 60% | 0.92 N |
| 70% | 1.2 N |
| 80% | 1.6 N |
| 90% | 2.3 N |
| 95% | 3 N |
As the issuance of safecoin is capped at 4.3 billion, it is expected that a 50% collision rate will be reached after 5 years. 95% collision rate will be reached after 10 years, as illustrated in the following diagram.
As mentioned in Section 6, when a safecoin is converted into P.O.R, the SDV that represents that token shall have its last owner updated to reflect that it has no owner (set to be hash(kZeroId) ). With this recycling mechanism, it will always be possible to mine safecoins.
To reward investors and developers involved during early stage, it is suggested that certain amount of safecoin is reserved for them. At Day 1 of the network startup, say 10% of safecoin will be injected into network, with the owner to be the investor pool and the developer pool (each has 5% share of total safecoin). As MaidSafe as a company needs to provide the seed network, which makes ourselves a big miner as well, share holders will get rewarded via company mining.
This 10% safecoin will require a storage space of 1TB, given the average SDV size is estimated to be 0.5kB. Vaults holding these SDV will gain P.O.R, which means the same amount of P.O.R also got injected into network. This ensures there is certain amount of P.O.R available across the network for those client only users to startup with, via friends given as gift or purchase from others. As pointed out in the (table POR projection), sufficient POR will be generated via user behaviour during the early stage, it is expected this amount of initial injection will be enough to kick start providing storage service to public.
To conclude, MaidSafe proposed the SAFE network, an economic system that contains two types of token and relies on a trusted group. The transfer mechanism is advantageous in many respects and has the functionality to prevent double-spending, while enabling the verification of transactions immediately. Transaction Managers handling SDV data type are included into the SAFE network to manage tokens and transactions. Proof of Resource (P.O.R) is introduced to smooth the exchange of storage space, while safecoin is introduced to incentivise stakeholders throughout the network. The total cap of safecoin is set to be 4.3 billion. With the proposed mining procedure (and assumptions) it is estimated that half the total volume will issued during the first 5 years, with 95% issued after 10 years. End users will mine coins based on their ability to provide computing resources to the network and, in addition to the other benefits offered by SAFE, this will be their main incentive for contributing storage space. When one safecoin is being converted into P.O.R to gain storage space allowance for the user, that safecoin token is recycled in order that other users can claim it via mining. Such re-mining procedure ensures there is always available empty tokens for mining. The tech stack of the token system is illustrated as .
[ref Network] MaidSafe Network website : www.maidsafe.net
[ref Autonomous] Autonomous Network, David Irvine, Fraser Hutchison, Steve Mucklisch : https://github.com/maidsafe/MaidSafe/wiki/unpublished_papers/AutonomousNetwork.pdf?raw=true
[ref Routing] MaidSafe Routing github site : https://github.com/maidsafe/MaidSafe-Routing/wiki
[ref BitCoin] Bitcoin : A Peer-to-Peer Electronic Cash System, Satoshi Nakamoto, https://bitcoin.org/bitcoin.pdf
[ref RUDP] MaidSafe RUDP github site : https://github.com/maidsafe/MaidSafe-RUDP/wiki
[ref Persona] Vault Documentation : https://github.com/maidsafe/MaidSafe-Vault/wiki/Documentation
[ref Escrow] The Escrow service for Bitcoin : http://btcrow.com/
[ref BIP 16/17] BIP 16/17 in layman's term : https://bitcointalk.org/index.php?topic=61125.0
[ref MasterCoin] Master Coin : http://www.mastercoin.org/