Unlimited macro invocations can make cost of reading exponential in size of data

[alexanderkjeldaas]

In certain use-cases, such as for blockchain data parsing, it can be important that the cost of writing and reading data are linearly correlated.

For example, if ion is used as an interchange format between smart contracts, then if one contract writes X amount of data, then it is useful if the consumer of the data knows that it can consume the data by having Y = k * X amount of gas available.

Without macros, this is relatively easy to ensure, or even at the system level, some cost relative to X can be charged for reading data.

Even with one level of macros, it would be possible to use look at the biggest macro expansion in the symbol table, and charge the cost of the largest possible expansion of the input data.

However, with arbitrary nested macros, the possible output size from reading data becomes exponential and this breaks down.

I would ask to consider adding a hint or optional requirement or standard exception / error or something on the reader side where:

1. A reader can refuse to read data using macros, so it's not only up to the writer whether to use macros.
2. A reader can refuse to read data using more than 1 level of macros.
3. Encourage reader libraries to allow control over resource usage (number of recursions, maybe callbacks on macros or similar) related to macro use while reading data.

Or, as a more minimal approach, add a note in the spec that letting the reader know that macros can create an exponential relation between input and output sizes.

[zslayton]

Thank you for taking the time to write this up! We agree that this is a substantive risk, and have tried to speak to it in the Security Considerations section. Could you please take a look and let us know if this addresses your concern? If so, we'll add a link to the security section from the macro section to make it easier to discover.