The goal of Polkadot is always a multichain project. i.e. While the relaychain is the core of Polkadot, system parachains / common good parachains are also an essential component of the Polkadot. In fact, the end goal of Polkadot is that the realychain should not need to process transactions at all.…

I think the security implications of allowing another chain to take ownership of an on chain account without doing any sort of verification. Hijacking is way too dangerous as there simply is no way to know whether account X is a valid proxy on parachain Y or parachain Y is just maliciously trying to…

Yes hijacking is indeed an issue. We need some proper identity solution to solve that. But for between trusted chains (i.e. relaychain and system parachains), we don’t need to worry about this. System parachains can assume relaychain have performed the necessary verifications about the account befo…

I’d suggest tx contain Merkle proofs into the account state on the other chain, presumably as some fixed moment in time defined by relay chain state root. We then declare the proxy in the account state on the account chain, prove it’s validity and other properties, and then sign using the proxy key…

There not necessarily a way to prepare a tx that require Merkle proofs into some foreign chain state right now, but also how we want to define these matters. In particular, I’ve seemingly said one thing wrong above… We might not want parts of the tx to be detached and shoved into a separate PoV-li…

[image] burdges: I’d suggest tx contain Merkle proofs into the account state on the other chain, presumably as some fixed moment in time defined by relay chain state root. We then declare the proxy in the account state on the account chain, prove it’s validity and other properties, and then sign…

How do we actually use pure proxies? Something needs to be signed somewhere, or else it goes through some on-chain voting process, or else it originates from the block producer. We’d need to generate the cross chain proofs in RPC calls or something. It’s maybe worth having a discussion more focus…

[image] bkchr: When you would require the proxy private key to sign some data. It would make the proxy useless as you would still need the key of the proxied account. Pure proxies also don’t have any known private key, making this completley impossible to sign anything. Thanks for highlightin…

[image] lucasvo: allowing an account from another parachain to transact via XCM directly. This is already supported or maybe I misunderstood you.

One use case that is not supported is to allow Alice on Polkadot to transact Alice on Statemint. In that way pure proxy on Polkadot can access token sent to that address on other parachains.

Multichain friendly account abstraction

Tech Talk

xlc December 1, 2022, 9:31pm 6

This is also critical for Interchain Proof Oracle Network, which could be a foundation for many crosschain use cases including this one

Topic		Replies	Views
Pure Proxy replication on Asset Hub via Root Referendum Ecosystem governance	3	343	November 20, 2024
People Chain Launch and Identity Migration Plan Tech Talk	35	3660	August 29, 2024
Parachain Technical Summit - Next Steps Tech Talk roadmap , frame , polkadot-summit	26	5176	July 17, 2024
Keyless accounts (AIP-61) Tech Talk	44	2058	July 30, 2024
AssetHub Vision Ecosystem	11	2022	April 22, 2024

Multichain friendly account abstraction

Related topics