Skip to content

Extend proxy E2E tests to ecosystem chains #561

@rockbmb

Description

@rockbmb

Extend proxy E2E tests to ecosystem chains

The proxy E2E test suite currently only runs against Polkadot/Kusama relays and system parachains. It should be extended to ecosystem chains that expose the proxy pallet.

This follows the same pattern as #415 (accounts) and #529 (preimages).

Pallet-specific differences to consider

The proxy test suite includes call filtering tests: for each proxy type a chain defines, it tests that:

  • Permitted proxy calls go through (the ProxyExecuted event does NOT contain a CallFiltered error, regardless of the call's semantic value)
  • Forbidden proxy calls are rejected (the ProxyExecuted event MUST contain the CallFiltered error)

Each proxy type's configuration specifies an explicit allowed/disallowed action list, built via ProxyActionBuilder methods (e.g. buildBalancesAction(), buildGovernanceAction(), buildStakingAction(), etc.).

Ecosystem chains differ substantially from relay/system chains:

  1. Proxy type enums are almost entirely disjoint. system parachains have types like Staking, NominationPools, Auction, ParaRegistration, Assets, AssetManager, Fellowship, Ambassador. Ecosystem chains will have their own sets — e.g. DEX-related types, loaning/lending types, liquid staking types — that don't exist elsewhere.

  2. Call filter lists differ because of ecosystem-only pallets. A chain like Hydration has pallets for its Omnipool, LBP, and DCA that no relay or system chain has. Acala has its Honzon CDP module, stablecoin minting, and DEX. These pallets will appear in the allowed/disallowed lists for that chain's proxy types, requiring new ProxyActionBuilder methods or custom action lists.

  3. Shared proxy type names (like Any or NonTransfer) have different filter lists, because the set of pallets they cover is chain-specific.

In short: the current test suite exercises call filtering only for relay/system chain proxy type lattices.

Ecosystem chains have fundamentally different lattices, which will require a redesign of the related proxy action builder interfaces and types.

Current design, and what's needed

The existing ProxyTypeConfig already supports overriding allowed/disallowed action lists per proxy type — each chain test file defines its own config and proxy type enum, then passes them to createProxyConfig() and fullProxyE2ETests(). This design carries over to ecosystem chains without changes.

The missing piece is the ProxyActionBuilder interface: its methods are currently hardcoded to relay/system chain pallets. To support ecosystem chains, the interface needs to be made extensible so that chain-specific builder methods (for pallets like Omnipool, Honzon, etc.) can be defined without modifying the shared interface. With that redesign, adding a new ecosystem chain becomes a matter of defining its proxy types and action lists.

Ref:

/**
* A builder to generate actions for a proxy account to execute, in order to test proxy call filtering.
*
* Each builder method returns a list of actions from a certain pallet that should/should not be valid for a given
* proxy type.
*
* That lists are returned allows for:
* 1. no-ops in the form of empty lists, and
* 2. providing multiple extrinsics of interest per pallet
*
* Each proxy type is then free to combine these lists as required.
*
* Example: allowed `Any` proxy calls could be any selection of the actions below, whereas disallowed actions
* would be an empty list.
*
* Each chain can also implement actions lists for their own proxy types, to test call filtering in those networks.
*/
interface ProxyActionBuilder {
buildAllianceAction(): ProxyAction[]
buildAllianceMotionAction(): ProxyAction[]
// The `Asset, `AssetOwner` and `AssetManager` proxy types rely on the same pallets, but different call filters.
// They are differentiated here to clarify which calls each proxy type can make, and which only some can.
// The same applies to `Uniques` and `Nfts`
buildAmbassadorCollectiveAction(): ProxyAction[]
buildAmbassadorCoreAction(): ProxyAction[]
buildAmbassadorReferendaAction(): ProxyAction[]
buildAmbassadorSalaryAction(): ProxyAction[]
buildAssetsAction(): ProxyAction[]
buildAssetsManagerAction(): ProxyAction[]
buildAssetsOwnerAction(): ProxyAction[]
buildAuctionAction(): ProxyAction[]
buildBalancesAction(): ProxyAction[]
buildBountyAction(): ProxyAction[]
buildBrokerAction(): ProxyAction[]
buildBrokerPurchaseCreditAction(): ProxyAction[]
buildBrokerRenewerAction(): ProxyAction[]
buildCollatorSelectionAction(): ProxyAction[]
buildCrowdloanAction(): ProxyAction[]
buildFastUnstakeAction(): ProxyAction[]
buildFellowshipCollectiveAction(): ProxyAction[]
buildFellowshipCoreAction(): ProxyAction[]
buildFellowshipReferendaAction(): ProxyAction[]
buildFellowshipSalaryAction(): ProxyAction[]
buildGovernanceAction(): ProxyAction[]
buildIdentityAction(): ProxyAction[]
buildIdentityJudgementAction(): ProxyAction[]
buildIdentityNonJudgementAction(): ProxyAction[]
buildMultisigAction(): ProxyAction[]
buildNftsAction(): ProxyAction[]
buildNftsManagerAction(): ProxyAction[]
buildNftsOwnerAction(): ProxyAction[]
buildNominationPoolsAction(): ProxyAction[]
buildParasRegistrarAction(): ProxyAction[]
buildProxyAction(): ProxyAction[]
buildProxyRejectAnnouncementAction(): ProxyAction[]
// The proxy type parameter is used because proxy type hierarchies form a lattice (order); thus,
// a proxy of type A can only remove proxies of type B such that B ≤ A; in other words, the action needs
// to be given an appropriate proxy type to remove.
buildProxyRemovalAction(proxyType?: number): ProxyAction[]
buildSlotsAction(): ProxyAction[]
buildSocietyAction(): ProxyAction[]
buildStakingAction(): ProxyAction[]
buildSystemAction(): ProxyAction[]
buildSystemNonRemarkAction(): ProxyAction[]
buildSystemRemarkAction(): ProxyAction[]
buildVestingAction(): ProxyAction[]
buildUniquesAction(): ProxyAction[]
buildUniquesManagerAction(): ProxyAction[]
buildUniquesOwnerAction(): ProxyAction[]
buildUtilityAction(): ProxyAction[]
}

Candidate chains

  • Acala
  • Hydration
  • Bifrost
  • Moonbeam
  • Astar
  • Phala

Metadata

Metadata

Assignees

Labels

e2e testsRelated to end-to-end testsenhancementNew feature or request

Type

No fields configured for Task.

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions