🎁 [Feature Request]: Pallet Abstractions to Improve DX

[4meta5]

templates

• Generic Runtime Template
• Evm Template

Macros PR: OpenZeppelin/openzeppelin-pallet-abstractions#1
Templates PR: #300

Contribution Guidelines

• I agree to follow this project's Contribution Guidelines

[shawntabrizi]

@4meta5

Check out some of the ideas that @kianenigma has been working on

https://github.com/kianenigma/flite

In this example (at the time of writing), he has been able to create a wrapper around frame_system allowing us to define concrete types, and then use those concrete types inside a new pallet.

The example he gives is having AccountId represented concretely rather than with a generic type.

Ideally, we could expand this idea to also include within a single pallet things like Balances, and also a concrete balance type.

At that point, building a new pallet with Flite becomes trivial like a smart contract

You can see that flite has some pretty non-trivial code / tricks inside of it, but the end pallet developed using it is super simple.

[kianenigma]

Update on this: paritytech/polkadot-sdk#5584

[kianenigma]

Draft design seems to be: https://github.com/OpenZeppelin/polkadot-runtime-wrappers/tree/amar-oz-system-wrapper-poc

[kianenigma]

So I see that this is done, but in ways different from what I have proposed here. Can we discuss why?

Note that I don't think there is something very wrong with what is currently done, but it lacks a few features:

1. It is not type-safe: the macros are literally copy-pasting code around. There is still a point of synchronization where in construct_runtime all pallets need to be present.
2. It is not using the power of Rust and its type system.

[4meta5]

Thank you for the feedback! This was indeed our first iteration, and we intentionally kept it minimal to get something functional in place. We are absolutely open to suggestions for improving the macros and share your goal of making them more robust. We’ve already created follow-up issues to address the improvements, especially around type safety and better leveraging Rust’s type system. Our plan is to tackle these issues over the coming months to enhance the macros significantly. Let us know if there are specific adjustments you’d recommend as we iterate.

[ggonzalez94]

@kianenigma appreciate the feedback. As @4meta5 said we know this first iteration is far from perfect, but we hope it still is a significant improvement fro DevEx and simplifies the parachain runtime code.
I'll ping on Elements to find some time to sync this or next week if that works for you.