Hey All,
Does anyone know if CoreJam will deprecate force transfer? While it probably made sense to include this functionality initially, in my opinion this functionality will become a significant issue at some point in time (in ways I don’t think most yet can appreciate). And when it gets abused (and it will), the trust loss in the system will likely be enormous. Would be interested in what others thoughts are.
I have read this matter of “force transfer is spooky and bad” quite a few times in governance context, so I will make this post be an excuse to explain why I think it is not a big deal:
There are two layers of governance:
First, let’s acknowledge that the latter trumps everything. The latter is the social consensus and is the backbone of everything we do here. I have used this example many times to dispel “Oh bitcoin is great because it has fixed issuance”. No. The moment bitcoin miners decide to run a software that alters this assumption, it no longer has fixed isuance. And if the majority of miners agree on that, that is what Bitcoin now is. So at a meta level, everything can be forced. Be it a “transfer”, or minting tokens.
Second, so long as the onchain holders have access to dispatching system::set_code, they can already set the intention to do anything. I want to emphasize anything. So the fact that something like balances::force_transfer exists is a mere shorthand for what is already possible.
The origin needed to dispatch both is Root, and truth is if someone with bad intent can pass a governance proposal with Root they can already do many bad things to the system.
We could agree that something like balances::force_transfer is so “frowned upon” that we should not even expose this shorthand for it (to which I personally disgaree). But this is a mere discouragement of the usage, and won’t prevent anyone from actually running a force transfer if they can obtain Root.
In other words, the fact that Polkadot exposes balances::force_transfer does’t inherently make it any different from any other blockchain, or a clone of Polkadot that didn’t have balances::force_transfer. It is a shorthand for an operation that might be useful, and was already available because of system::set_code.
I agree with the technical aspects of your comments for the current version of Polkadot (if you have root then it doesn’t matter whether force transfer exists or not because you can achieve the same end effect); however, Gavin Wood alluded to setting a “fixed” inflation rate based on CoreJam. If you are able to set a “fixed” inflation rate, then I am assuming the plan is to split the system in parts that can’t be changed and ones that can. He noted certain changes would require a hard fork (point two of yours above).
If my understanding is correct in that some items can be changed and others cannot, I was curious as where force transfer will fall in CoreJam. Again, I understand the current version by default can’t change.
My concerns for force transfer extend beyond the standard degen type comments you receive from bitcoin or eth folks (most of those comments are generally unintelligible). I am thinking years ahead and under the assumption that Polkadot gains significant success. I believe this functionality will become a much bigger concern than people realize.
Anything that becomes powerful enough will be attempted to be controlled. And if entities can’t control that thing (Polkadot) directly, then they will control (through force or coercion) the people that control that thing (Polkadot). By having two layers of “governance” in this manner, Polkadot has created two attack vectors. And a successful attack only requires the exploit of the weakest vector.
Given the distribution of the tokens, Polkadot will NOT become more robust over time in this area; however, if it achieves network effect, it’s miner/validator level will as they grow in number. I am not saying governance is bad (quite the opposite), but allowing force transfer to operate in CoreJam will create problems that I don’t think anyone in this community can yet fully appreciate.
Right now force transfer is merely an ideological argument among influencers and whales on X and social media, but I assure you, the stakes will be much, much higher in the years to come when new threats emerge.
There is a good chance that there won’t be force transfer feature in the JAM chain. At least, I cannot find it in the current graypaper.
However, this may not be the answer to your actual question.
This is because JAM chain are not to be used directly. People use services powered by JAM chain and one of the service is parachain service and one of the parachain powered by the parachain service will be the asset hub system chain.
There is a good chance there will be force transfer in the asset hub system chain.
There are also many other parachains and non parachain services that may have force transfer.
So the answer is not a simple yes/no. It depends.
Makes sense. I think that if Polkadot wants to partially compete as a currency / transfer of value, which it is clearly in my mind trying to do based on recent proposals of inflation, then I think there has to be somewhere in the Polkadot architecture where DOT can be stored/recorded that is not impacted by that functionality. I get that asset hub or another system chain may need to retain that functionality for various reasons, but again, probably needs to be a safe place to store within the general framework of JAM.