Add Preimages precompile

[LucasGrasso]

Is there an existing issue?

• I have searched the existing issues

Experiencing problems? Have you tried our Stack Exchange first?

• This is not a support question.

Motivation

In views of the development of the Governance Precompile, a Preimages precompile might turn out to be useful in order to keep the whole flow of submitting referenda on the smart-contract side.

Request

Development of a pallet_preimage precompile

Solution

Develop a preimage-precompiles crate that implements a precompile for the following interface (or something similar):

interface Preimage {
    /// @dev Register a preimage on-chain.
    /// @param preImage The preimage to be registered on-chain
    /// @return hash The hash of the preimage
    function notePreimage(bytes memory preImage)
        external
        returns (bytes32 hash);

    /// @dev Clear an unrequested preimage from storage.
    /// @param hash The preimage to be cleared from storage
    function unnotePreimage(bytes32 hash) external;
}

Are you willing to help with this request?

Yes!

[franciscoaguirre]

It makes sense to expose this functionality to smart contracts. @pgherveou @athei what do you think?

[athei]

I think this is useful. The main concern is the deposit. If you are just using pallet_preimage naively the deposit would be held on the contracts account. This might make using it a bit annoying as the contract would need to make sure to have enough free balance. This might be the right approach as it is most flexible. Contracts could decide how to raise those funds.

An alternative approach to tap into the storage deposit system of pallet_revive: Use env.charge_storage in your pre-compile to automatically collect or refund a deposit from the origin as held balance into your pre-compiles account. This makes it transparent for the contract. But the contract also does not receive the balance.

Not sure what is the right approach. Needs some use cases and prototypes. But my gut feeling is to start with the first as it's the most flexible.

[pgherveou]

dumb question, can't the preImage just be stored directly in the contract?

[LucasGrasso]

Thanks everyone for their comments.

Not sure what is the right approach. Needs some use cases and prototypes. But my gut feeling is to start with the first as it's the most flexible

I personally think that it will be the most used in DAO-like smart contracts, so the first approach makes the more sense.
In my mind, if there is a way to handle allowances natively, maybe we can extend the interface for allowing deposits to be payed by the original caller. (Something like transfer and transferFrom in ERC20).
I can investigate a bit more and come up with a design doc, but I think that starting with the first is good as is the biggest use case that comes to mind.

dumb question, can't the preImage just be stored directly in the contract?

Not a dumb question. Pallets like pallet_referenda need to check stored preimage lengths against pallet_preimages, which ussualy implements the Preimages trait, so I think it isn't possible.