This is false. You’ve not suggested any tangible benefits.
I showed parachain transactions make as much or more sense under the economic scenarios you described.
Complexity is obvious. Bandwidth & CPU time are obvious. You’re spouting bullshit here.
I’ve already address reserving resources above, but again…
We sacrifice “decentralization” by asking higher specs of validators, but bandwidht is a harder limit, so likely specs rise until bandwidth caps them.
We could convert validator CPU time and bandwidth into parachain blocks at roughly some linear factor: Assuming roughly 300 cores on 1000 validaters, if we liberate one parablock worth of processing from all validators, then we’d add roughly 30 cores to the system, thereby increasing system value by 10%.
I’ve mentioned that above too, but it’s worse really…
Memepools are horrifically expensive compared with parablocks:
transaction verification costs 33%-95% less CPU in blocks, depending upon the crypto & storage involved.
memepools inherently double bandwidth costs, but really they waste even more bandwidth on redundent transmission.
Aka it’s much less than a full parablock worth of work that’ll cost that 10% of total system value.
In short, relay chain transactions are expensive and bring nothing of value.
I believe I have, and have also allowed for the fact we are working from different premises and assumptions (DOT>0 assumed not proved) and also allowed for different priorities in the tradeoffs that are made. To my mind these are two tangible benefits:
With respect to the first point I have elaborated on why I prefer the RC option, you disagree on the tradeoff:
And the second point:
No. I asked for a proof (But really a simulation is what is required for the reasons I’ve stated before):
I’ve not disputed that cost, nor the additional costs you then raise. I’ve simply pointed out there are tradeoffs that others might weigh differently.
I understand you don’t consider these benefits (e.g. making user lock-in more difficult) to be worth the cost, or perhaps have a preferred alternative.
This is false. As I argued above, parachains have more options if the relay chain has problems.
If the concern is bad parachain developers or governance, then system parachains have exactly the same upgrade model as the relay chain, so system parachains benefit from any advantage of the relay chain developers or governance.
As stated, this makes no sense: If the parachain turns off messaging, then they’re loosing network effects.
I think the way to express what you want to say is this:
You’re arguing people are not going to build swaps, CEXs, etc because the messaging between parachains is too convenient. I’ve no opinion on CEXs myself, maybe they’re all illegal in 10 years anyways, who knows. As for swaps…
At a technical level it’s kinda easy to build swaps between grandpa chains that’re generic over the tokens, nfts, or whatever, so this only needs to happen once, and what your saying is false tecchnically. At a UX level though, yeah maybe some users become involved using some beautiful UX, which never exists for swaps. This would not help relay chain accounts though, since they have exactly the same concern with respect to messaging dominance.
This is your magical thinking: You think because the relay chain controls finality that it’s accounts are somehow privlidged, or get better devs or better governance or get trusted more by other chain or whatever, but this is all just false. System parachains are a part of the relay chain development and governance process. Bridge parachains are trusted more by other chains. There is no top of the pile here.
Around UX in paritcular: If a parachain has more users, then it’ll have the better BTC swap UX or whatever. If all the good swap UXs depend upon EVM, then you can use them from moonbeam etc, but not from the relay chain, assethub, etc.
None of this is actually relevant. A blockchain is just a public database operating in a reasonable byzantine threat model. Our job is to make that database be fast, cheap, and secure. That’s job one. Anything else is just orthogonal issues about how people use that database.
It’s either just data, or else the parachain has more options for preventing lock-in.
Also…
Keyless accounts make blockchains more hidden behind the application. That’s both intentional and desirable for UX. As such, keyless accounts make user lock-in worse, in the sense that the application now filters access between the users and the chain.
Afaik this is inherent to OIDC, but even if it can be worked around, using risky shit like TEEs or whatever, then keyless accounts cannot help with user lock-in vs say user controlled keys. In particular, if chain A has keyless accounts, and chain B airdrops to chain A, then either keyless accounts cannot benefit form the airdrop, or else chain B needs at least half a bridge, which is a huge task, aka keyless accounts will not generally be recieving airdrops of the current sort. Keyless accounts will recieve gifts from VC who want to lure users into their applciations.
All together, keyless accounts have exactly the opposite effect of what you envisioned when you opened this threat. They’re still a good idea for parachains that want them.
You are correct, a parachain has more options if and only if they decide to allow their users the opportunity to exit (regardless of whether the reason to exit is due to RC failure, or parachain no longer offering utility/value).
I would prefer to remove this choice from the parachain hands.
Can’t the parachain selectively decide what types of x-chain activity (messages) they will permit/support?
No. I’m arguing avoid repeating the Web 2 mistakes: Web 3 should build in functionality that makes it difficult (ideally impossible) for RC, parachains, dapps, etc to lockin users. Here that piece of functionality is allowing a Y-user to create a X-account in a way that Y-network cannot stop or hinder them.
The mechainics of who this happens will vary by network. I have allowed in my comments for the fact that the optimal implementation might be different:
I don’t believe I have ever stated that. If I have I should retract the remark. If you can point out where I gave that impression I’d be grateful if you point it out and I’ll retract and clarify for the benefit of later readers.
I’ve tried to be clear on the thinking driving this:
Again to clarify:
I don’t suggest or care if there is a hierarchy. The critical feature is that a RC, parachain, dapp, etc cannot stop a user creating an account (or any like exit mechanism) on another chain.
This is where we disagree. I would add the (“fundamentally mistaken”) priorities/point-of-view :
A blockchain is just a public database operating in a reasonable byzantine threat model. Our job is to make that database be open to competition and secure. That’s job one. Then make it fast, cheap. That’s job two. Anything else is just orthogonal issues about how people use that database.
Aren’t you begging the question here? That is, if this is not done outside of the control of the parachain, dapp, etc (that means it is done, say, by a RC or system chain, or whatever abstraction is optimal), then how do we ensure a parachain, dapp etc cannot chose to try to build a moat around its users?
It appears to me that you start by assuming the parachain does not want to lock-in its users, then “… the parachain has more options for preventing lock-in”. While that is a category of parachains they are not the challenging/interesting case.
Yes, a protocol that allowed users to create accounts on another network without the permission of a particular application, and then allowed the application to remove that information from the users possession (not just view), would indeed be schizophrenic. Of course an application could suppress the information in the UI it provides. But as long as the competing application could let that user gain access the user still has an exit path.
I believe this depends on how they are implemented by the protocol.
Agreed.
However, I am also interested in the parachains, apps, etc. that do not want their users to have them.
As I’ve remarked a couple of times I’m not suggesting this is easy to give effect to.