I'm looking at ink! contracts and chain extensions. Two questions that came up that I did not find an answer by browsing the docs. Both questions are related to the design of integrating ink! with parachain runtimes.
Why are chain extensions explicitly defined vs. giving ink! by default read access to all pallets' storage items and dispatchable functions? It seems quite the overhead to maintain both chain extensions and the pallets themselves. Both, storage and dispatchable functions are publicly accessible anyway so I was surprised, ink! needs to have explicitly stated chain extensions. What was the reason for this design decision?
Why do chain extensions use function ids? In
construct_runtimepallets already get an id, plus the pallets' storage items and dispatchable functions have explicit names. Using function ids in the chain extensions, I see two down sides: (1) ink! contract developers need to look up a potentially very long list of chain extension function ids that makes it error-prone during development and review as one might easily confuse function
1011that might have different functionality. (2) For runtime engineers, there seems to be an extra burden to ensure that chain extension function ids are maintained in parallel to the rest of the runtime code. What was the reason for this design decision?