[pallet-contracts] the design of `instantiate_with_code`, maybe we need to recover `put_code`

[atenjin]

Hi @athei
Now, you guys remove put_code and design instantiate_with_code for implementation the rent of code. But just provide instantiate_with_code is very unfriendly for developer to deploy multi-contract.

Just the example for delegator in ink! example, the root contract need to init 3 contract in its constructor function, then pass 3 contract hash when init delegator root contract.

However developer need to put/deploy the 3 contract code before, otherwise the blockchain does not have those wasm codes. Then, if the developer only need to deploy those 3 contract code in the constructor or message function in root contract, he have to deploy the 3 contract before and init them. However in must case, it's useless to init instances for the 3 contract code, init them just for blockchain to store the wasm code in chain.

If you try to deploy the delegator contracts by yourself, no matter through apps or using Redspot to edit a script to deploy the contracts, you would understand what I mean.

Thus I think maybe we need to recover the method put_code for developers, providing them a way to just put the wasm code before initing the root contract, rather than require them must to init/deploy a contract before.

Considering the rent code feature, I think we should re-design the logic of rent code, for example we could design:

1. The first one do a put_code, create a mock contract instance for rent requirement(the mock contract is not a real contract, just hold the ref of code), then the first real contract instance replace the reference of the first code ref, then delete the mock contract.
2. when someone call put_code, he need to pay more fee for this operation, lock this fee, when the code has a reference, he could use another method to unlock the locked fee to get back the fee, or when the code has a reference, and then the contract instance is killed and the contract code reference become zero, the locked fee auto return to the put_code operator account.

[athei]

1. You can just write the delegator in a way where it references an existing contract rather than instantiating a new one.
2. All this "mock contract" stuff sounds complicated when you can just terminate the initial contract to get rid of it.
3. It is the job of UIs and tools to make the development experience pleasant. The contracts module needs to stay as simple as possible. And I see no reason why this setup complexity of a new delegator cannot be hidden behind a UI.

[atenjin]

1. You can just write the delegator in a way where it references an existing contract rather than instantiating a new one.
2. All this "mock contract" stuff sounds complicated when you can just terminate the initial contract to get rid of it.
3. It is the job of UIs and tools to make the development experience pleasant. The contracts module needs to stay as simple as possible. And I see no reason why this setup complexity of a new delegator cannot be hidden behind a UI.

for the point 1, some business could write in a way where it references an existing contract, but there are also many business situation need to instantiate new contract, for example in may defi contract, it need a contract factory or some similar concept which takes charge of initing a contract based on a code hash. But for now, if the contract factory could work, it must need developer to deploy a sub-contract first to store the code on the chain, but this sub-contract is useless and wastes resource.

If the contract inheritance structure under two level, it can barely do this way(I mean deploy a useless contract first to store the code), but if contract inheritance structure more than two level, it would become complex and confusing, and it would cause the developer need to deploy more useless contract, and it would cause developers to re-organize his business and lose the reuseability for contract.

For example, if the developer divide his features into 3 contract like A,B,C, and C needs B, A, and B needs A. In contract C, would init different instance of B and A. But due for pallet-contract limit, he could just deploy a useless A, and a useless B which needs to use the code hash of A, then the C contract could use B and A code hash. Finally the developers will think If I just do a simple feature, I need to do lots of work to deploy many useless contract and waste more money, why not I just design a single contract to cover all features? But if the developer just write a single contract, then the reusability of contract ecology will be greatly reduced. For example if another project need to re-use the instance of contract A?

And finally, if the example delegator in ink! is hard for developer to deploy it, do you think this is a reasonable design?

[athei]

But for now, if the contract factory could work, it must need developer to deploy a sub-contract first to store the code on the chain, but this sub-contract is useless and wastes resource.

As I already said earlier you can write a delegator contract that instantiates from existing contract addresses and let those be instantiated behind the scenes by your tooling. It is not the intention to have a good user experience by sending dispatchables to the chain.

And finally, if the example delegator in ink! is hard for developer to deploy it, do you think this is a reasonable design?

Only for the lack of tooling. There is nothing stopping any UI from instantiating the delegated to contracts behind the scenes and construct the delegator from those contracts. I don't see how adding some scheme of temporary contracts make this any easier without having proper tooling for it.

I am not willing to push complexity into privileged code which can be solved at higher levels.

[atenjin]

sad, this will require developer to create lots of useless contract and waste money... This design cannot attract developers to use.
I think a better way is to re-design the rent model for stored code.

[athei]

sad, this will require developer to create lots of useless contract and waste money... This design cannot attract developers to use.

I stay unconvinced that this is true (see my previous argumentation). The design goal is to make the implementation as efficient and simple as possible. Developer and user convenience can be provided by upper layers as long as the underlying platform allows for it. My standpoint is that it does (at least in your example): I described how a frontend can instantiate the necessary contracts for a delegator and then instantiate the delegator from those contract's account ids.

I think a better way is to re-design the rent model for stored code.

I am open for a better design. But a proper proposal would need to be more than a few bullet points stating what is little more than an idea. There are more aspects than what is most convenient to clients. Removal of state and (temporary) contracts must be properly incentivized.

[stale]

Hey, is anyone still working on this? Due to the inactivity this issue has been automatically marked as stale. It will be closed if no further activity occurs. Thank you for your contributions.