Chain Extension Suite

[deep-ink-ventures]

Project Abstract

Our project focuses on bridging the gap between the Substrate runtime and smart contracts in ink! through the development of the Chain Extension Suite. The primary objective is to automate and streamline the process of exposing runtime methods to smart contracts, addressing the challenges developers face due to the intricacies of low-level communication. The Chain Extension Suite, accompanied by an auto-generating CLI tool, is crafted to simplify this process, reduce boilerplate code, and accelerate the development cycle.

Grant level

• Level 1: Up to $10,000, 2 approvals
• Level 2: Up to $30,000, 3 approvals
• Level 3: Unlimited, 5 approvals (for >$100k: Web3 Foundation Council approval)

Application Checklist

• The application template has been copied and aptly renamed (chain-extension-suite.md).
• I have read the application guidelines.
• Payment details have been provided
• The software delivered for this grant will be released under an open-source license specified in the application.
• The initial PR contains only one commit (squash and force-push if needed).
• The grant will only be announced once the first milestone has been accepted (see the announcement guidelines).
• I prefer the discussion of this application to take place in a private Element/Matrix channel. My username is: @_______:matrix.org (change the homeserver if you use a different one)

[github-actions]

CLA Assistant Lite bot All contributors have signed the CLA ✍️ ✅

[deep-ink-ventures]

I have read and hereby sign the Contributor License Agreement.

[keeganquigley]

Thanks @deep-ink-ventures for the application. The suite would be nice to have, but I will say though that the cost seems pretty high to me, especially considering that we've already paid out 200k to your team for various grants. Did you already try getting treasury funding for this? Since your referendum passed for the hookpoints-cli perhaps the community would be willing to fund this project as well.

[deep-ink-ventures]

Thanks for the Feedback.

We are confused about the nature of this grant structure: Our understanding was that the w3f grant program is for bringing infrastructure, libraries and other reusable building blocks to the polkadot / substrate ecosystem - which is why we thought this is a good fit. Especially because it's unrelated to Genesis Dao and we can keep the things in separate lanes.

Isn't that the case anymore and everything should be go to opengov and if so what kind of grants are you looking for.

Whenever we notice things that are lacking or where we struggled with because of missing tooling, we try to conceptualize it as abstract as possible and to find a solution that helps the ecosystem and this is what we have done here as well.

[keeganquigley]

Thanks for your response @deep-ink-ventures.

The grants program has mostly focused on early-stage PoCs for common-good software development and research, which does include infrastructure, libraries, and other building blocks. That being said, there have been some recent changes within W3F, and the grants program will likely be changing a bit in the coming future. At this time, we don't have a lot of information yet, but hopefully we will learn more in the coming weeks.

In the meantime, it is just the price tag that I am debating here. In my opinion it is rather expensive. We also expect well-established teams to have other revenue sources and not rely solely on grants. Not that this necessarily applies to your team, I'm just stating our policy.

[deep-ink-ventures]

Got ya. Are you up for a quick call to see if there's room for either a smaller price tag or a bigger scope?

[keeganquigley]

@deep-ink-ventures sure thing, feel free to book a slot: https://calendar.app.google/osmD7mQtxyHoBr6o8

[deep-ink-ventures]

Booked :)

[takahser]

@deep-ink-ventures I added a couple of inline-comments. Feel free to have a look.

[takahser]

Suggested change

	| **0c.**| Testing Guide | A detailed guide on how to run the test suites for the CLI Extension tool and a demonstration of the testing coverage. |
	| **1.** | CLI Extension Tool - Part 1: Setup | Establishing the CLI tool to inspect the Substrate runtime and enable code generation capabilities. |
	| **2.** | CLI Extension Tool - Part 2: Substrate-side Chain Extensions Generation | Auto-generation of the Substrate-side chain extension code based on the inspected runtime methods. |
	| **3.** | CLI Extension Tool - Part 3: ink!-side Chain Extension Traits Generation | Auto-generation of ink!-side chain extension traits to facilitate communication with the generated Substrate-side chain extensions. |
	| **4.** | CLI Extension Tool - Part 4: Reference Smart Contract Generation | Generation of a reference smart contract in ink! that interacts with the generated chain extension traits and Substrate-side chain extensions. |
	| **5.** | Medium Article | A Medium article detailing and announcing the CLI Extension tool, explaining how it simplifies the generation of chain extensions and enhances the developer experience within the Substrate ecosystem. |
	| **0c.**| Testing Guide | A detailed guide on how to run the test suites for the CLI Extension tool and a demonstration of the testing coverage. |
	| **0d.** | Medium Article | A Medium article detailing and announcing the CLI Extension tool, explaining how it simplifies the generation of chain extensions and enhances the developer experience within the Substrate ecosystem. |
	| **1.** | CLI Extension Tool - Part 1: Setup | Establishing the CLI tool to inspect the Substrate runtime and enable code generation capabilities. |
	| **2.** | CLI Extension Tool - Part 2: Substrate-side Chain Extensions Generation | Auto-generation of the Substrate-side chain extension code based on the inspected runtime methods. |
	| **3.** | CLI Extension Tool - Part 3: ink!-side Chain Extension Traits Generation | Auto-generation of ink!-side chain extension traits to facilitate communication with the generated Substrate-side chain extensions. |
	| **4.** | CLI Extension Tool - Part 4: Reference Smart Contract Generation | Generation of a reference smart contract in ink! that interacts with the generated chain extension traits and Substrate-side chain extensions. |

[takahser]

Just moving up the Article to the usually mandatory default deliveries here

[takahser]

My thoughts here:

• Will there be any limitations on which pallets are supported by the CLI? Can they be used for any pallet, for any attribute/function/trait/etc.?
• I think you can skip the CLI Extension Tool - Part 1: Setup delivery, as this essentially only describe a CLI tool with very unclearly scoped "code generation capabilities". In any way, the further 3 deliverables cover the same CLI tool.

[deep-ink-ventures]

Will there be any limitations on which pallets are supported by the CLI? Can they be used for any pallet, for any attribute/function/trait/etc.?

The idea is to work with the introspection that is e.g. used by polkadot.js.org and autogenerate contracts based on this. This may prove to be to complicated for some extrinsic, but we should be able to provide boilerplate code that eases development work, which is our main goal.

[takahser]

The idea is to work with the introspection that is e.g. used by polkadot.js.org and autogenerate contracts based on this. This may prove to be to complicated for some extrinsic, but we should be able to provide boilerplate code that eases development work, which is our main goal.

So in other words, the CLI would be usable for any extrinsic in any pallet, except for some unexpected edge cases that might arise, right?

[takahser]

Despite having 3 FTE, there is only 1 contact/team member listed. Could you list the 2 remaining members?

[Noc2]

Just one quick comment from me: I would be interested in learning more about your future plans with this project and if you already have considered treasury funding for this?

[deep-ink-ventures]

As discussed with @keeganquigley we changed the grant to be a Level II proposal and splitting the functionality where it made sense to still have usable software from day 1. Happy to hear your thoughts!

Changes:

• moved PSP-22 support to a subsequent effort
• moved PSP-34 support to a subsequent effort
• moved v5 upgrade of pallet_hookpoints and this piece to a subsequent offers (when v5 is as well officially released)
• reduced the grant to Level 2 (30k)

[deep-ink-ventures]

@keeganquigley Did you have time to take a look?

[takahser]

This deliverable is too vague - it seems like 2-4 already include everything that is specified here. I suggest to either be more specific (if my assumption is wrong) or remove this deliverable.

[deep-ink-ventures]

I'm not sure what you mean here. I've split up the part into four different parts: Architecture, substrate integration, ink integration and code generation. What do you think I'm missing?

[takahser]

You should think of deliverables as parts of a milestone, that you're going to deliver, rather than the specific steps you have to take to complete a milestone. If I understand correctly, the deliverables 1-4 are all about developing a CLI tool, and deliverable 1 seems to overlap with 2-4, since it basically describes the bootstrap process.

[takahser]

Could you move this up to the mandatory deliverables? Also, could you include the mandatory docker deliverable?

[deep-ink-ventures]

I'm not sure I can follow. Aren't those all mandatory? Also, this is a CLI tool, there is no use of docker - what should I add here?

[takahser]

You can find the mandatory deliverables in the application template.
The main reasons we usually require a Docker deliverable is to simplify the testing process and avoid potential dependency & operating system mismatches. If you think that's not applicable in your case, you can just add a comment instead, explaining why you won't add the Docker deliverable.

[takahser]

The idea is to work with the introspection that is e.g. used by polkadot.js.org and autogenerate contracts based on this. This may prove to be to complicated for some extrinsic, but we should be able to provide boilerplate code that eases development work, which is our main goal.

So in other words, the CLI would be usable for any extrinsic in any pallet, except for some unexpected edge cases that might arise, right?

[takahser]

@deep-ink-ventures besides the new inline comments I added, could you address the points I made earlier, regarding:

• this follow-up comment
• the FTE <> team mismatch
• and this

Additional points & questions:

1. I suggest to stick with pallet_nfts_extensions (plural) rather than pallet_nft_extensions for consistency with the naming of the related pallet_nfts pallet
2. While I think this would be a useful tool and the proposal has been improving as well, I was also wondering if you have considered funding through the treasury or the decentralised futures program, as also asked by my colleague earlier.

[keeganquigley]

Hi @deep-ink-ventures are you intending to make further changes to address the above comments?

[deep-ink-ventures]

Yep. We had corona running the team, will update by eow!

[deep-ink-ventures]

Went through it, but didn't get all questions and asked for more details.

[takahser]

@deep-ink-ventures I added follow-up comments. LMK if you have further questions.

[semuelle]

@deep-ink-ventures, are you still planning to submit changes? It seems as if there are still some open questions to be addressed.

[deep-ink-ventures]

Yes! One of our rust devs is getting at this, but he came back from xmas vacation with a cold. We'll finish it this week!

[semuelle]

pinging @deep-ink-ventures

[deep-ink-ventures]

Hey Sebastian, thanks for pinging again. I'm closing it for now so you have it from your list and then we'll reopen it. We are currently in talks with some projects that might want to use it and this might a) give a better argument on why approving this grant and b) might alter the requirements a bit.