[fastx adapter] choose gas costs

[sblackshear]

There are two kinds of costs for us to reflect: computation, and storage. Some decisions to be made:

Storage

1. How much do we charge per byte of storage?
2. Do we charge only for the storage of the order itself, or also for the storage of the objects it creates?
3. What should the upper limit on the size of transactions be?
4. What should the upper limit on the total size of objects created by a transaction be?
5. What should the upper limit on the size of an individual object be?

Computation

1. The Move VM allows us to configure the gas costs of individual bytecode instructions. What values should we choose?
2. What should we choose for the gas costs of native order types (e.g., transfer)?

[gdanezis]

These are all great questions. But they have no principled technical answers, since they are resource allocation problems based on the (potentially diverging) preferences of validators.

So I think the overall questions could be:

• How do we determine, in any epoch / at any point in time, what the costs should be?
• What mechanisms do we need to coordinate this determination?
• Do all need to agree on these costs? (I think yes? Hm, maybe.)
• How dynamically can we modify these costs? Per-validator, per-epoch, more frequently?

This is a place where I would loop in our economist while they join. Right now lets just use placeholder defaults.

[gdanezis]

I would also add to the items for which we should charge:

• We should include a charge in gas according to the length of the mutable inputs of a transaction.

[gdanezis]

We are now coordinating all econ related questions with alonso, here, including gas: https://docs.google.com/presentation/d/1LM5zVtLG64Ny4Q8oxSf9R3tfGsxmdKGbPIUSEaH-f3E/edit?usp=sharing

[666lcz]

related: #248

[bholc646]

Can this be closed @oxade?

[bholc646]

I'm guessing most of this has to be figured out or is captured directly in #1122

[oxade]

Can this be closed @oxade?

@bholc646 I'll consolidate all the issues