This post explores a way for the network to never own anything, not even the unrewarded tokens.
The problem with section wallets is the section owns the tokens, and if the section colludes or is hacked then those tokens can be stolen.
The aim of the idea in this post is to not have the section responsible for any tokens at any time. If anyone tried to steal unrewarded tokens it would be seen as an invalid operation and rejected.
Taking inspiration from bitcoin script, particularly the transaction puzzle (notice the transaction does “not contain any signatures”). We can see the power of extending beyond only using signature verification for transaction validity. If you’re not familiar with P2SH, I recommend reading Pay To Script Hash Explained and miniscript since an understanding of this will make the rest of this post much simpler to understand (I wrote this post to be understood as-is so the background knowledge should be a nice-to-have rather than essential, hopefully!).
The idea is to create a bunch of reward wallets where the secrets needed to transfer the funds are unknown but can be discovered after some amount of work/time.
For a simple example, create 232 distinct reward wallets containing 1 token each. Instead of having those wallets require a signature for a valid transfer, each wallet has a unique puzzle as the condition for valid transfer. Those reward wallets can only be spent by solving a puzzle. Eg the puzzle might be to concatenate a section-signed PUT and the recipient node id, then hash that and see if it starts with a certain number of zeros; if it does then the transfer is valid and the reward will be transferred to the recipient node wallet (ie these inputs form a solution to this puzzle). If the PUT data is not signed by a valid section, or the recipient node id is not currently part of the network, or the hash of all those values does not start with the right number of leading zeros, or <any of the conditions expressed in the puzzle being invalid>… the transfer would be invalid.
Let’s look at a reward wallet that specifically requires 5 leading zeros. This would mean after about 25 uploads we’d expect one of those uploads to have a high chance of forming a solution to that puzzle. We could have other wallets with a puzzle requiring ten leading zeros, some with twenty leading zeros, etc to have varying levels of difficulty to claim the reward and spread them out over time.
Reward wallets are not owned by anyone in particular (the puzzle is the owner) and each reward can only be claimed after some predefined number of network operations (statistically speaking).
That’s the simple version. There’s lots of design considerations. But the idea is lots of different puzzle-owned reward wallets with varying degrees of difficulty to claim them so that they’re spread out over time. Make sure the solution to the puzzle depends on some verifiable network activity.
Some benefits:
It can be set up in a verifiable way. A simple example, the first reward wallet is at address hash(“Safe Network Rewards Wallet 0”) with 1 token and puzzle difficulty of 10. The second reward wallet is at hash(“Safe Network Rewards Wallet 1”) with 1 token and puzzle difficulty 11. The third reward wallet is at hash (“Safe Network Rewards Wallet 2”) with 1 token and puzzle difficulty 12. Keep iterating until all 232 reward wallets (minus ICO tokens) are created. Choosing the reward amounts and puzzle difficulties will need some consideration (discussed more later). Anyone can take the initial wallet creation conditions and iterate to check those wallets really exist on the network.
Everyone can know exactly how many rewards have been claimed (and unclaimed) at any point in time. Look through all the reward wallets starting from the start and when we find the first unclaimed one we can know how many prior rewards have been claimed.
Different reward wallets might contain different amounts and different difficulties. Not sure exactly how to approach this. Maybe uniform amount with varying difficulty is best? Maybe having some amounts be large and some small might be better? (discussed more later)
Some drawbacks:
We need to change the mutation mechanism to go beyond just verify(signature) for validity and move toward a blockchain style scripting system. Luckily we may get away with having very few operations, but it would need to be more than just the single verify signature operation. I don’t see this as a drawback, I see it as a necessary feature from the start, but it will require more design and dev time. If we expand our definition of ‘ownership’ beyond ‘signatures’ toward ‘scripts’ the idea seems doable.
Going a bit deeper into the puzzles.
I’ve been using leading zeros as the proxy for difficulty-to-claim-the-reward. In reality this is actually just a big number exactly like how bitcoin difficulty works (it looks visually like leading zeros when binary encoded but actually it’s about the whole number being less than the target difficulty, not just the leading zeros). This gives a fine-grained resolution on the rate of rewards.
It’s worth chaining the rewards so they must be claimed one-after-the-other rather than multiple rewards at the same time. Say we have 10 reward wallets with puzzles that range from 1 leading zero to 10 leading zeros. Say the wallets needing 1 and 2 leading zeros have already been claimed. Everyone is now aiming to claim the 3 leading zeros reward. Someone flukes on a 9 leading zeros solution. We want them only to be able to claim the 3 leading zeros solution, not 3 4 5 6 7 8 and 9. Maybe we can prevent this by requiring the previous reward solution to be one of the inputs to the puzzle, so we can’t use the solution to the 3 leading zeros puzzle to claim the 7 leading zeros reward (we’d need the solution to 6 leading zeros).
We could set the puzzle to use various network events as inputs. There might be puzzles requiring section-signed PUT data as the input (reward on PUT). Other puzzles might require section-signed GET data as the input (reward on GET). Some puzzles might be based on section-signed relocation data (reward on relocate). Or based on joining. Or departing. Or section split. Or any signed network event. These could be parallel reward tracks (eg claim the next PUT reward only by supplying the previous PUT reward, and simultaneously the next GET reward could be claimed by supplying the previous GET reward, so there’s a chain of PUT rewards and a separate chain of GET rewards operating simultaneously); or the rewards could be completely sequential (eg the next reward is based on GET but it depends on the previous reward which was based on PUT).
How can we design the puzzle difficulties so the rate of claiming rewards is not too fast and not too slow? This is a tough question. As a first take, we can look at current potential network bandwidth and potential upload rates and design the reward difficulties around that. Assuming bandwidth will improve maybe 10x over 10 years but not 1000x over 10 years we have some idea of what sort of range the difficulty of the puzzles should lie. If we end up rewarding slightly faster or slower than we predicted that’s not so bad. Just so long as it’s not 1000x faster or slower.
Another option for the difficulties might be to have an ‘escape’ clause in the puzzle. You can either solve the zeros puzzles to claim the reward, OR if the network is a certain age let maidsafe set a new difficulty for any unclaimed rewards. Allowing an adjustment after a certain amount of network time has passed allows rewards that are too difficult to be made easier if needed. I think this is not a great idea, it makes that adjustment key too valuable, but it’s part of the conceptual toolbox so might be handy in some other form.
If multiple nodes come up with a solution simultaneously and try to claim the same reward at the same time, how is this dealt with? This is like the problem of orphan blocks in bitcoin. Is it also like the problem of many people in an office simultaneously trying to edit the same document?
I think this idea might solve the ownership problem and make the network really not own anything, just be a notary. Have I missed some aspect that would make this idea not work well?
But I agree with your main point, time is irrelevant here as something to code into an algorithm and perhaps even as a thing to measure, unless we can look back in time and say, hey that took X days.
