I have a ton of questions…sorry to have missed the presentation.
-
This seems to be mostly talking about Ingress messages. Is that true? So the boundary nodes are the bottleneck and they will need to order the messages according to fee? Does this then carry through to the replica? Are they also ordering by the extra fee?
-
This leads me to a deeper question that maybe I should have asked a long time ago, but the current assumptions make it irrelevant and I always assumed that it would come up eventually as we moved to decentralized boundary nodes and/or nodes running custom replicas. We currently don’t have to worry(much) about MEV on the IC, but should we start worrying about it? If a boundary node can order by fee, what is to keep it from ordering by whatever metric it wants including inspecting the incoming message and sliding a message in front of it that front runs a trade? Is there anything currently that is keeping node providers from running a forked replica that may have their own custom code running on it? If we do implement this do we perhaps get a handhold to start doing some kind of slashing if a message is misordered?
-
If this is just an ingress issue, then what about inter-canister? Does this system need to exist there? I actually expect most of the traffic on the IC to eventually be inner canister. Building an application is already hard enough. With the upcoming addition of non-guaranteed message delivery, we’re going to have more failure conditions to handle for inter-canister calls and this seems like another addition. It is a lot easier for a user to decide if they want to boost their message than for a hard-coded canister to do so.
-
Who gets this extra fee? Is it always cycles? Is it burned? Can we pay in ICP or ckBTC? If so how will the node calculate the exchange rate? If the end application gets the fee then that seems like a fairly cool feature. Do they have to update their code to accept it or will it just get deposited automatically?
-
If it is an inter-canister, should we be looking at an application-level solution instead of adding to the replica? (I have a utility that I’ve been working on that seems to do something like this and it is going to get frustrating if every problem we run into keeps migrating down into the replica after someone burns a couple thousand hours of dev time…see some of the comments on today’s ‘enable canister to hold neurons’ thread…not saying this is one of those times, but that I’m concerned it might be…and moving to the replica might be the right answer but it still sucks if you’ve built something that becomes irrelevant).
-
If everyone moves to canister-based wallets does this get easier?
I can probably think of 10 or so more questions, but I’ll stop there and try to get up to speed before I ask any more.