Rewarding smart-contract developers in proportion to how much their contract is used is a really good thing but naively tying it to transaction fees does not work for a variety of reasons.
The first thing to understand is that there are no “gas” fees. Transactions do carry a field called “fee” which lets them include a payment in tez to the baker who will include the transaction. When bakers create blocks, they are limited in the number of operations they can include, in the gas those operations can consume, and in the size they can occupy (in bytes), but the bakers are otherwise free to choose the transaction they wish to include. A reasonable, default behavior is for the baker to simply include the transactions that carry the highest fees and use up the least amount of space and gas in the block, but they are not required to do that. In fact, there may be several reasons why a baker may not selecting transactions on that basis. It could be that the baker is being paid off-chain, on-chain, or in some other manner for including these transactions, it could be that the baker only wants to include transactions from certain parties. It can be particularly useful for users who need to make a large number of transactions every day to enter into a long term service agreement with bakers.
All this is to say that attaching tez to the fee field is not something that is programmatically tied to gas consumption but just one way, among others, to pay bakers for the inclusion of transactions.
There are approaches, such as Ethereum’s EIP-1559 that attempt to codify how gas is paid. This approach maintains an optional “tip” field as a way of incentivizing block producers to include transactions, but it also requires a fee, proportional to the gas consumed to be burned. To calibrate the amount of burn required, the block gas limit is rendered elastic, and the burn amount is set by targeting an average block size.
This has the benefit of codifying the bulk of fees being paid and being prescriptive about the way they are paid. There are economic benefits for proof-of-work systems, but these are already captured in a proof-of-stake system. There are important drawbacks to this approach and explaining them in detail would go beyond the scope of this answer but, to take just one important example, this would break the model of bakers selling long-term service agreements.
Assuming an EIP-1559-like system, the fee paid becomes a meaningful number. It cannot be artificially low (due to an off-chain payment) or costlessly high (due to a baker injecting a transaction with large fees in their own blocks). You could decide to take a percentage of the burned fee and give that to the contract but that doesn’t really make sense? Why not just require a payment? Why tie it to gas fees? What if you’d rather refund the user for that amount… it gets messy and it’s not particularly useful.
What does make more sense is a burn discount for contracts on which a lot of fees have been burned. You could count how much fee has been burned since the inception of a contract and apply a multiplier on the burn they require. Obviously this would need to be bounded, but you could imagine that a contract for which 1,000 tez have been burned pays 95% of the fee, one for which 10,000 have been burned pays 90%, of for which 100,000 have been burned pays 85%, etc all the way down to 50%.
The benefit of this approach is that contracts that are initially popular can build a sustainable advantage over copy-cats. (To be sure, I take no credit for this idea at all, it’s one of the thing discussed around EIP-1559 in Ethereum land).
In conclusion:
- Careful, the fee field is more subtle than it looks
- If the point is merely to pay contracts per call, there’s nothing stopping contracts to charge and there’s no particular reason for them to make that cost propertional to the gas used.
- The fee field can look more than what people expect it to be using the approach described in EIP-1559.
- Even when fees are burned, it’s still not a good idea to try and funnel a portion of that to the contract
- What might make sense in this scenario to create a fee discount for popular contracts to let creators enjoy a competitive advantage over clones
