Keyless accounts (AIP-61)

[taqtiqa-mark]

@burdges

This is false. As I argued above, parachains have more options if the relay chain has problems.

Again we have different things in mind:

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.

@burdges

As stated, this makes no sense: If the parachain turns off messaging, then they’re loosing network effects.

Can’t the parachain selectively decide what types of x-chain activity (messages) they will permit/support?

@burdges

You’re arguing people are not going to build swaps, CEXs, etc because the messaging between parachains is too convenient.

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.

@burdges

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.

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:

@taqtiqa-mark

Perhaps the downstream chain provides a relay that imposes the downstream requirements? Anyway, this is getting into questions of which architecture is optimal wrt the 10% cost you pointed to.

@burdges

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.

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:

@taqtiqa-mark

While here we have been concentrating on the safety motivation/use case. I believe the more common and valuable use case is the “low-friction” provision of cross RC accounts as a way of fostering competition. Here building this into the protocol definition becomes controversial - is only justified if you take a particular opinionated position on the costs vs. benefits.

Again to clarify:

@burdges

There is no top of the pile here.

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.

@burdges

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.

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.

@burdges

It’s either just data, or else the parachain has more options for preventing lock-in.

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.

@burdges

… As such, keyless accounts make user lock-in worse, in the sense that the application now filters access between the users and the chain.

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.

@burdges

All together, keyless accounts have exactly the opposite effect of what you envisioned when you opened this threat.

I believe this depends on how they are implemented by the protocol.

@burdges

They’re still a good idea for parachains that want them.

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.