Convert user constraint to Pointer

[JesseAbram]

• User's will not set constraints at register, rather they will point to an already set constraint
• They can pre set it or choose it
• The storage of programs will use the hash of the bytecode as the key

Next Steps

• The registered struct will hold the pointer which will be a string for now but can be converted to a bounded vec when we implement program linking
• A global struct controlled by some form of governance (this will be free storage and won't be able to get pulled, plus it will be more vetted)

[JesseAbram]

A question that came up was how to price bytecode, weather to charge once upfront and store forever, or to let people remove programs and charge a deposit for removal, currently the deposit method is implemented

[HCastano]

Problem Statement

To make sure I understand what's going on here, let me first define what I understand the
be the problem.

Right now users are required to upload a full program during registration. This can cause
friction, especially if they just want to reference a program that already exists on
chain.

We want to figure out a way to simplify this process for users.

Open Questions

On top of the original problem statement from above, here are some of the current open
questions:

• How do we want to charge users for uploading programs?
• Do we want to allow or disallow program termination?
• Should we have a global, vetted, program registry?

Current Solution

A solution to the above is to split the code upload and registration flows. This makes
the registration flow a bit simpler since users just need to know where the program they
want to use is on-chain.

Additionally it decouples the program upload step from registration.

My Take

I'm a fan of splitting out the program upload flow from the registration flow. It makes
sense to me that not every user that registers would be required to upload a program.

The only changes required for this first step are:

• In the Program pallet:
  • Add upload_program dispatchable which takes some bytecode and returns a
    code_hash
• In the Relayer pallet:
  • Caller passes in code_hash instead of program

This is all we really need in #536. The other things can be figured out in follow-up PRs.

On the open questions, here are my thoughts:

Charging a storage deposit

We should continue to charge program uploaders a storage deposit to upload programs
on-chain. Storing The bytecode is real cost that the chain and its validators have to
bare over time.

Program termination

I also believe we should allow contract termination. One concern here was around
references to programs.

One solution here would be to add a reference counter (u32) to the ProgramInfo
struct. When there is a registration request we can update the reference count on the
program behind the given code_hash. We would also need to charge the registering user a
deposit for this.

The program would not be able to get terminated unless its reference count is zero. This
ensures that no dangling references exist. Once the reference count reached zero the
original uploader would then be able to call a terminate extrinsic and get their deposit
back.

We'd need to add some sort of unregister extrinsic to the Relayer pallet so that we
could decrease a program's reference count.

Global registry

I don't think we need to have this. It adds complexity and bias. We should instead be
relying on economics to keep important programs on-chain.