This is something I’ve wanted to understand for ages.
3 Likes
If you are talking of the section token balances and a system to make them claim it, then there is nothing there for Apps. Simply for security and the fact Apps are running on client computers. Apps are not for nodes to run.
Fundamentally Apps are a client based layer.
3 Likes
Did you see my posts above? There could be techniques to limit node involvement to the genesis node burying the coins with an age lock and move the discovery of them to layer 2 apps. A (section) age lock would need implementing for wallets, but the rest could be left to an app.
Likewise, PtP could be handled by Medium like apps, where provider submits their content through an app and they are collated and distributed to subscribers who pay to access them. The payments are then distributed to the providers, based on subjective popularity with subscriber base (e.g. likes/claps).
Hardening and maintaining the core must surely be as important as providing some of these style of features in the core?
And where are these Apps running. That is the issue, Apps are for clients on a client computer. To push it to a node to run the App then its just another name for a core routine.
They can run anywhere. Maybe the same boxes as the nodes. Maybe people’s phones.
In past conversations @mav raised the point that section elders shouldn’t have giant section wallets at their disposal. @dirvine also indicated that large section wallets are not to his liking. @mav suggested a system of POW where elders brute force the keys to known cold storage wallets to unlock more funds in an incremental fashion. IIRC I suggested an alternate approach where the keys are already owned by the section but the locations of the cold storage wallets are unknown. The brainstorming above hashed that concept out a bit more.
Yes, that is the basic idea. The thoughts above simply explored coupling that process to section splits. Coupling the hunt to section splits slows down the rate at which a section has access to new funds rather then allowing it access to a new cold token as soon as the “hot” section wallet gets below a threshold. This stop-gate or phase-gate approach has interesting implications for divisibility, malice detection, and fiat volatility since the rules for section splits are distinct from the reward system.
To clarify, the work comes from real network activity, not from brute force (as understood for the standard ‘blockchain’ use of brute force which separates mining activity from user activity). The proof aspect is the signature generated by the elders during normal operation, and the work aspect is the normal network GET and/or PUT operations by clients that lead to the signature being generated in the first place. The clarification I want to make is the term POW usually implies single-purpose ‘wasteful’ work, but the work I propose is not wasteful, it’s derived from the essential original purpose of the network so would be integral to both user experience and to farmer rewards.
It’s really cool to see more ideas in this space. It’s a fascinating conversation. Hopefully it leads us to an extremely robust reward mechanism.
9 Likes
I completely disagree in that its a security issue. Section tokens should always be under complete control of the section and any other section doing a check/authorisation. Basic security.
Also what if no one runs the App.
Its not POW or anything like that requiring huge compute power. Personally I would not refer to @mav explaination above as POW since that suggests waste and his is just proof of action.
1 Like
Maybe I’m not explaining my point well. The unclaimed tokens wouldn’t belong to a section. They would simply be unclaimed coins that any user can attempt to claim when circumstances permit.
In this scenario, section wallets would only hold the PUT fees, which would then be paid out as rewards when the section splits.
Increasing token supply does not need to be coupled to rewards. Imo, they are separate concerns and can be treated as such.
2 Likes
Just want to point out that I think this is elegant.
The interesting part then is how the increase of supply is deviced.
As simple as possible…
3 Likes
At this time the only reason to delve into “unused” tokens is for rewards. I cannot see the reason behind “Increasing token supply does not need to be coupled to rewards”. Rewards are the only reason it would be needed.
Also security in Safe dictates that tokens not owned by a user is by definition owned by the network, be it a section or some undefined locked up system and thus tokens owned by the network should be controlled by the network. Not be allowed for some App to unlock. This is not a block chain technology were miners unlock new tokens. All the tokens exist from the start.
1 Like
Here’s a play on the threshold relay idea borrowed from Dfinity that I linked to above. You’d still have section wallets as currently envisioned, but they wouldn’t hold significant funds, only transient funds. Significant / long term funds would be held in a network-wide wallet that is managed by network-wide elders who are randomly selected from different sections throughout the network.
The network-wide elder group would expire and control of the network wallet passed to a new random group according to some network metric, growth, member status change, etc. With a sufficiently large group with well-randomized participants, the probability should be practically nil that an attacker can take over the network wallet without taking over the entire network really. This network wallet can then send funds to section wallets throughout the network to distribute to their respective nodes for work prior to every transition.
The approach is consensus-less and would allow for separation of concerns where funds security can be optimized separately from network performance and at different levels of granularity. There are some caveats and potential downsides of course.
1 Like
Would you see a section request tokens when its own wallet is running low? I cannot see every section always having sufficient funds from purchases.
I doubt it would be a good use of resources for a section to access the network wide balance for every reward payout. What amount would you consider a sensible amount to be given to a section that needs more tokens. A fixed amount or an algorithm to figure out an amount. Say current farming reward amount * number nodes in section * 32 (or 128 or 1024). The 32 represent an approx amount of clients access chunks from the section.
2 Likes
Yes, this would be one of the caveats that could lead to edge cases if not properly modeled and designed for ahead of time.
No. The network wallet should never send funds to a single section. This is to prevent bad sections from falsely reporting low funds so they can steal. The network wallet would only fund all sections at the same time.
This is precisely the issue that this idea is trying to prevent, i.e., section funds having access to far more funds than they need to reward work done within a split interval (defining a split interval as the intervening time between a split and the next split). So if a network wallet can supply about the necessary amount required for a split interval, it’d give time to catch bad sections as well as reduce the impact of any theft from any such bad section.
Which takes us to:
Good question. I don’t know. In addition to your formula, simulations could be run to estimate how much funds a section would need on average within a split interval as a function of network size. That amount would be provided along with a small buffer to account for slight deviations from the expected equilibrium.
There are other caveats still. For instance:
-
Split interval’s will not be the same for every section so you might end up with situations where a section is accumulating funds from the network wallet because it hasn’t split. This particular example would depend on the design for rewarding section nodes (e.g., only on split?) and can be mitigated. -
Potential security risks to providing such a bird eye view of the network to the (temporary and random) members of the network wallet. I can’t think of any right now since elders already have a full sense of the network based on recent changes (no neighbors).
The network is nothing more than a group of sections. A second layer of elders adds complexity for no reason. You are proposing the creation of a centralized weakness that already works fine in parallel as a decentralized mechanism.
There is no reason to do this. The same thing already occurs at the section level during a churn when section elders need to get get reassigned. IIUC dirvine’s section chain will handle or has handled all of this quite nicely.
They won’t. That’s why we have divisibility. There are pros/cons to coupling the section splits with the ability to access new unused tokens vs. letting a section have a new “cold” token once it has almost spent the balance in its “hot” wallet. I think coupling new access to the reserve with splits could be more “fun”, and it slows down a bad section giving more time to dilute the bad nodes in later splits.
It’s not a second layer of elders. Same old elders, but additional layer of duties outside of their section at times. There’s a nuance.
Why do you think the idea is “for no reason” or that it’d be “a centralized weakness"? Otherwise, yes, it’s added complexity (which idea in this thread to ensure the security of section funds isn’t?).
Yeh I think there’s a lot to this in terms of securing against a bad section. If a section runs low, then payouts are lower for a while in that section only. Worse things could happen…
If the “new wallet creation” step (for some limited amout; 1SNT eg) is linked to a certain network age as suggested (prefix length), and/or certain amount of churn (not sure how you’d check this reliably at the mo though… the section chain doesn’t guarantee different elders… at least at the moment it doesn’t; it should though when there’s malice detection around DKG steps). Well, at this point you’d encourage churn.
If there’s a max elders age (which has been punted elsewhere). This chirn might be come about naturally as they top out eg. Or perhaps some other type of churn, moving the youngest still if no max age was reached + we have no tokens… The main thing is, this would avoid elder stagnation in the section (which I’m not entirely sure how desireable that’d be… but it perhaps we avoid collusion oportunity with such shifting elders?)
I get the impression it’d be more beneficial to work well, churn out some elders and get the next section payout unlocked than try to hang around + and misspend what’s in the section wallet.
4 Likes
I think the initial point might have been forgotten here: we’re looking for ways to distribute network funds because we don’t want to leave them all in the sections - because a large increase in fiat value could create massive incentives to attack a section.
So we lack a solution to this: how to prevent individual section funds becoming “too valuable”.
6 Likes
Also what “stuff” can sections do if they are bad. So this is SectionAuthority i.e. a valid and cryptographically valid group of nodes who can sign something.
Removing the bad they can do is important.
Using CRDT client data and clients/owners signing then the section cannot counterfeit and that’s great. This was a big fight for us years ago when the client sigs were removed from data (insanely IMO) as this gave section complete control. In any case they don’t now and cannot counterfeit clients actions. We should never lose this function.
So what does SectionAuthority do for client data. Well as a section is part of a DAG (in reality) we call that NetworkAuthority when looking at the whole network (i.e. we don’t care what section signed, only that it was crypto valid in the DAG). In any case all this does is say, yip as a network we seen this change/store etc. So gives us validation the client/owner stored the op on the network at some point. (i.e. paid for it or whatever).
So what can SectionAuthority mutate on the network?
This is network created money. So section wallets and really limited to that so far. (it can vandalise the network though, by denying data / clients etc. but I think we can see that and act on it, so keeping the vandalism attacks as separate for now)
I know most folk know this but I thought I would throw it into the conversation again, just to be clear.
8 Likes
In other words, they could possibly steal the money from the network pool, but not the money of clients?
Sidenote: I think it is cool how this resonates with the idea of data being the valuable thing, not the money.
6 Likes