I’d like to record and address some concerns about this SNIP raised on TG. Although we have carefully considered them before working on v0.13, they are not explicitly addressed in writing. Starting this discussion here would benefit the community and allow everyone interested to chime in.
Before diving in, I want to make the high-level clear:
- The STRK token’s intended utility is for using, managing, and securing Starknet (see this post for more details). We want to allow STRK fee payment as another step toward these goals.
- The Starknet operator has inescapable ETH expenses for L1 data and L1 state updates. The operator will allow STRK fee payment and will take on the risk of undercharging users.
- ETH→STRK oracles are a tool for the operator to mitigate risk by minimizing losses.
RS | YAS Starknet:
I’m checking out the upgrades for 0.13. Wouldn’t the use of strk and eth for gas introduce some MEV opportunities?
(The concerns is that price of STRK may change before sequencer can sell it for ETH to cover L1 costs.)
The sequencer does indeed take on this risk. However, since the ETH expenses are inescapable, we consider the risk as an acceptable price for allowing the utility of STRK tokens.
RS | YAS Starknet:
These are some of the questions I have:
- Where can we read more about how will the oracle work? From the SNIP it says that it will be only off-chain. Are there any benchmarks on how is Pragma performing for this task (not the on-chain work they have done so far)?
The oracle will indeed be off-chain. As far as benchmarks and specifics, the lovely Matteo Georges from Pragma mentioned he’s working on some expository material, so I’ll leave that to him (and refer to his post when I have a link).
- How often wil the price be updated? Is it per block?
The exchange rate will be sampled every few seconds. Each block will use the latest rate throughout. In particular, the rate will be uniform throughout each block.
- Isn’t this adding unnecessary complexity? It’s weird that the sequencer resources can be paid directly with a token that needs an oracle to measure against the native resources. This means there will always be an arbitrage opportunity between the asset priced in Starknet and the gas cost.
Depends what you consider as “necessary”, right? We know we want to facilitate STRK fee payments, and we know the operator expenses are in ETH. We could invent our own method of converting ETH→STRK, but I would say that is unnecessary complexity and it’s best to use experts. As far as arbitrage, I agree: there is indeed an inherent opening for it. However, it also affords us a continuity in UX: concurrent support for old tx versions alongside v3 doesn’t require users to own STRK.
- How will this play out with the txs that are confirmed instantly in L2 before going into a block?
I am not sure I understand the question. Currently, one can query about the pending block (the one under construction). For now, once a transaction is included in the pending block, it will remain there. Is this what you mean by “instant confirmation”? If so, there is no threat for UX here: the confirmed transaction will move forward in the flow until L1 finality, possibly at the expense of the sequencer. The risk taken by the sequencer explicitly protects the UX in this flow.
- Will the oracle be run completely by Pragma?
Pragma will provide its oracle service. Switchboard is another oracle provider that we will employ for the same purpose. It will provide a fallback.
- What happens if the off-chain service goes down? Does the whole chain stop or is it only going to affect the v3 txs?
Even in case of both oracles failing, there are fallbacks which will maintain liveness for v3 transactions as well. In particular, oracle faults will not cause the chain to stop.
Oak:
I agree with RJ take on allowing more than one token for tx fee payment. It’s only adding unnecessary complexity on lower levels of the protocol without any clear benefit, and with a high potential for exploiting
Firstly, I disagree with the assertion “without any clear benefit”. The reasons for STRK support are mentioned above and appear in detail e.g here. Concurrent support for ETH and STRK seems to me like a very reasonable way to onboard STRK without ruining UX. What would you propose as a less complex way? As far as exploiting - I don’t follow: the sequencer is taking on the risk, so what sort of exploitation do you have in mind?
lambda_0x:
iiuc once old transaction type is deprecated native way to pay for gas would be STRK if you want to pay with any other token like ETH or USDC that would be done with paymaster?
also would STRK be just another SRC20 token or will there be special rules for it on protocol layer?
Good questions. If I understand the first one correctly, then yes - we definitely want to add support for a paymaster. I think it would do great things for the network. For the second question, even with paymaster, STRK will be still distinguished at least in the decentralized setting because block rewards will be issued in STRK. Thus the security of the network will be intimately coupled to the market for STRK.
RS | YAS Starknet:
I understand the need for the oracle with the two tokens to make that work for the time being. But adding the strk token as a fee mechanism now doesn’t seem to add too much and the risk to making it work seems quite high.
But in general I want to understand more how it will work to re-evaluate my opinion.
I think I addressed these concerns above, but please correct me otherwise!