A network upgrade will be coming up toward the end of April. Currently, it is being prepared for Constantine. Phi Labs protocol core contributors will be putting up details below on the upcoming upgrade.
2 Likes
Upgrade Features
This upgrade adds the following features:
x/callback
This module enables CosmWasm based smart contracts to receive callbacks at the end of a desired block. This is useful for scheduling actions to happen at an expected time by reserving execution in advance.
x/cwfees
This module marks a significant advancement in how transaction fees are handled within the protocol. Any smart contract can now register itself as a feegranter and have custom logic for approving a tx for feegrant.
x/cwica
This module enables Cosmwasm based smart contracts to register ICA accounts and submit transactions to be executed on counterparty chains.
x/cwerrors
This module is the error handling mechanism for the protocol to let the contract know of errors encountered during the contract execution by the protocol. The contracts which leverage the funcationality of x/callback and x/cwica will benefit from this.
See the Full Change Log here.
2 Likes
Following the testing on Constantine, ETA for mainnet upgrade proposal to go live is Thursday 25.04.2024
Please join our governance call tomorrow for further details → Discrod Event
1 Like
How the existing fees model—comprising Block Reservation Fees and Future Reservation Fees—can be refined through the use of priority and delay queue data structures, and how the Priority and ExecuteAt attributes of callbacks can be utilized to optimize callback handling based on their context and urgency.
Refining Fees with Priority and Delay Queues
-
Dynamic Fee Adjustment Based on Queue State:
-
Queue Length: If the priority queue for a particular block is already nearing its limit, the fees for adding another callback to the same block can increase dynamically. Conversely, if the delay queue has ample space, adding a callback with a future
ExecuteAttime can be cheaper, encouraging users to schedule non-urgent tasks for later times. -
Priority Consideration: Callbacks with higher priority (lower numerical value) could be charged a premium, reflecting their need for quicker processing. This could be particularly useful for high-stakes applications like trading platforms, where timing can significantly impact outcomes.
-
Enhanced Callback Semantics
Using the Priority and ExecuteAt parameters effectively can allow differentiating callback handling based on the application’s context:
-
High-Priority Immediate Execution: For applications like DeFi, where immediate execution can protect or gain significant financial value, callbacks should have high priority and short
ExecuteAtintervals. These would incur higher fees but would be processed preferentially. -
Low-Priority Deferred Execution: For less time-sensitive applications, such as gaming, callbacks can be set with lower priority and longer
ExecuteAtintervals. These callbacks would be cheaper to schedule and could typically run when the system is less busy, thus conserving resources during peak times.
By refining the fees model and enhancing the semantics of callback scheduling, callback module can achieve more efficient resource utilization, better user satisfaction, and higher overall system performance. This approach also kindly allows for a more flexible Dapp development environment, where developers can optimize cost versus performance based on the specific needs of their applications.
Fee Calculation Algorithms
Block reservation fee = base fee * ( 1 + number of scheduledcallbacks/max block fee)
Future reservation fee = base fee * ( distance to execution block/max future limit)
Priority fee = maximum priority fee * ( 1 - priority level/highest priority level)
Interesting Technical Proposal…
Would you mind please re-posting this in our GitHub Discussions as an RFC; this will ensure our engineers and greater developer community get better visibility of this proposal.
Thank you for your contribution!
1 Like