Replies: 9 comments 22 replies
-
|
Let me provide some examples of module specific economics.
More examples to come. |
Beta Was this translation helpful? Give feedback.
-
|
Points 2 and 3 are very valid. Point 1, however, I'm not sure. If the swaps in pool |
Beta Was this translation helpful? Give feedback.
-
|
We need to introduce a normative expectation that Module developers will provide economic, normative prioritization and back pressure guidance in their modules. Decisions like burn, community pool and other allocations of funds might be best left custom antehandlers but we also want to normalize most Cosmos chains to have a custom antehandler. |
Beta Was this translation helpful? Give feedback.
-
|
Dealing with MultiMsgs MultiMsgs complicate the prioritization picture a bit. If a MultiMSG includes a prioritized transaction should the entire Msg benefit from the priority or not? I'd lean towards nullifying any prioritization other than just paying a higher gas price for MuliMsgs unless they are all the same time. |
Beta Was this translation helpful? Give feedback.
-
|
I don't think multi-messages should go into it's own queue. There can be literally any transaction in a multi message. Both important one and a rubbish one. Hence putting them in a general queue would make more sense unless we will have some more sophisticated mechanism for managing queue (dynamic assignment?) -> #9348 (comment) |
Beta Was this translation helpful? Give feedback.
-
|
After speaking with Zaki today I think what we ultimately want is typed messages + polymorphic MultiMsgs. We then provide routing middleware that allows application developers to direct specific messages types or composites to different queuing systems. These abstractions are clean can be used to design fee models with any level of simplicity or sophistication. |
Beta Was this translation helpful? Give feedback.
-
|
With polymorphic MultiMsgs do you mean something else to what we already have? |
Beta Was this translation helpful? Give feedback.
-
|
We treat multi messages as row typed polymorphic entities. Single messages are single typed values. |
Beta Was this translation helpful? Give feedback.
-
|
Sorry, but I don't follow. Are you writing about something we don't have in SDK? |
Beta Was this translation helpful? Give feedback.
-
|
Expectations for in consensus min fee. I expect that module based backpressure/min fee mechanisms will largely mitigate the need for a baseline in consensus min fee. |
Beta Was this translation helpful? Give feedback.
-
|
Sorry for the lack of technical depth, but can you clarify how easy it would be to run this pre-processing in a separate set of machines than are doing actual transaction processing if it's implemented this way? |
Beta Was this translation helpful? Give feedback.
-
|
This is consensus critical behavior. It needs to be implemented in the state machine. |
Beta Was this translation helpful? Give feedback.
-
|
Why is it consensus critical? Isn't prioritization usually a mempool thing? |
Beta Was this translation helpful? Give feedback.
-
|
The liquidity module and like other DeFi modules are going to need in consensus base fee behavior. Also if a proposer violates the consensus rules for block composition I would want it be slashable. |
Beta Was this translation helpful? Give feedback.
-
|
For fee calculation that makes sense, but there's more to prioritization than fee calculation. My sense is that for Pylons because it has free transactions I'm going need a mempool prioritizer that's outside consensus one way or another, to do traditional spam mitigation stuff, and while I'd prefer to make that stuff slashable, I think it's more important that it's possible. |
Beta Was this translation helpful? Give feedback.
-
|
How is this different from writing a custom antehandler? The examples you outline, dex swaps and IBC transfer, can easily be done this way. I was going to start a tutorial and blog post on how to do these things to educate people. Many of these things can use the param store to control changes, but a way to inject custom fee handling from the module level should be added and is something I have been advocating for months. |
Beta Was this translation helpful? Give feedback.
-
|
The problem with requiring a custom antehandler is that to handler all the examples is that requires the author of antehandler to have deep domain experience on every module they bring in. It doesn't allow for the seperations of concerns that we have tried to maintain in the SDK where zones can use modules without being deeply aware of their internal semantics. Transaction prioritization and rate limiting are going to become core to the expected properties of the IBC module for instance. |
Beta Was this translation helpful? Give feedback.
-
|
The whole Antehandler design needs a ground up rework. It's pretty centralized - it seams it was designed to collect fees after transaction and then patched with few other mechanisms (other middlewares). One approach we are looking at are hooks - to allow assigning hooks at multiple levels (router, service). |
Beta Was this translation helpful? Give feedback.
-
|
+1 to middleware. |
Beta Was this translation helpful? Give feedback.
-
|
I support middleware as well |
Beta Was this translation helpful? Give feedback.
-
|
fair enough ;) But will still try to draft a hook mechanism - for modules. |
Beta Was this translation helpful? Give feedback.
-
|
@marbar3778 was just asking about this. does anyone have a specific design in mind for the middleware. might be able to work on this sooner than later if so. |
Beta Was this translation helpful? Give feedback.
-
|
We already have a middleware interface (antehandler). It's not a hook for a specific module, but it will "listen" on all transactions. |
Beta Was this translation helpful? Give feedback.
This comment was marked as spam.
This comment was marked as spam.
-
|
@okwme could you ban this account? It randomly will comment or approve prs across the org repos |
Beta Was this translation helpful? Give feedback.
-
|
Done. |
Beta Was this translation helpful? Give feedback.
-
Risks of having too many queuesWe still don't have the design for the queue.
If we don't have good answer for (2.) and 1 = yes, then having too many queues will partition the block space in a badly way. We can end up with badly managed a block space, yielding too much empty space. Or making a spam attack easier (now an attacker can create many cheap transaction for each queue). Dynamic queue assignmentWe could consider a 2-step mechanism for fulfilling queues:
|
Beta Was this translation helpful? Give feedback.
-
Typed Transactions and Economics
Context:
Prioritization and flow control are an important part of any blockchain protocol. Protocol designers want to control over the composition of blocks and the economic mechanisms that incentivize users to delay their transactions.
Goals:
The Cosmos SDK should provide flexible mechanisms for protocol designers to rate limit transaction and provide incentive alignments between users, validators and token holders.
Current Status:
The Economic logic of the Cosmos SDK is currently sandboxed in the default Antehandler provided by the Auth module. The Antehandler validates transactions during CheckTx and the Antehandler extracts fees based on a single metric applied by each transaction.
Industry Context:
Ethereum originally implemented a transaction fee model similar to the current Cosmos SDK. Miners determined what transactions to put into each block and transactions were paid for in fees to miners. Ethereum has found itself hosting numerous DeFi applications. These applications have provided new revenue for block producers while decreasing alignment with Eth holders.
Cosmos SDK developers are starting to deploy DeFi applications on their chains. For Ethereum protocol developers, the precise application that is being accessed is opaque to the protocol and they have no choice to use gas consumption as the only metric. Cosmos SDK messages are typed by what applications they interface with. The Cosmos SDK should enable application developers to encode.
Improvements to ABCI
Forthcoming improvements to the ABCI in future Tendermint releases will increase the opportunities for Cosmos developers to provide application specific prioritization information.
Tendermint is introducing a prioritized mempool into a forthcoming Tendermint release. The prioritized mempool will allow the application to ensure return a priority value for each transaction. The Cosmos SDK must provide a mechanism for module authors to customize the priority behavior.
Further out on the Tendermint roadmap, Tendermint will enable applications to customize how blocks are constructed by reaping the mempool with PrepareBlock. This will provide more application specific prioritization logic.
Beta Was this translation helpful? Give feedback.
All reactions