You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, the price relayers ask is an const number, and when user call the sends_message dispatch call, the call will sort all the ask prices and give a matched price for the message data(order) to deliver.
Even though relayers can update the const number from time to time, but for a specific time, the const price given by relayer is a proposal for all kinds of messages, after the user send and order matched, the relayer must deliver as expected no matter the cost high or low, otherwise he will be slashed for not delivering. This result a difficult problem for relayers to putting ask prices on-chain because the messages are unknown when putting these ask prices. For example, some message might consume huge cost when dispatching on target chain, and this brings large unfavorable risks to relayers, and will disincentive the market.
To enhance the solution, we change change original const price to a function of message, price = f(message), this function will be stored on chain for evaluation, and for each message, the price match will be pre-processed using this evaluation, and sorting using post evaluation prices. The original const price, can be taken as f(message) = c where c is the const number.
Security:
Care must be taken when implementation this, especially for the evaluate function on-chain, e.g. if we use solidity smart contract to express this function, we must pass a max_gas_limit for each evaluation, in case some malicious relayer stall the runtime dispatch call by deploy and set a large gas consume(e.g. large loop) contract/function.
The text was updated successfully, but these errors were encountered:
hackfisher
changed the title
More flexible relay price function express on-chain for relayer market function.
More flexible relay price function express on-chain for relayer fee market.
Sep 10, 2021
This might not be necessary for substrate to substrate brige since most substrate dispatch call on target chain are system controlled and weight fees consumtion are benchmarked. And for substrate to substrate, target fee evaluation can be pre embeded in the runtime of source chain, so source chain can provide helpful strategy for relayers.
But for taget chains like Ethereum which support user contracts, its unlimited various changes will break preset evalution. This enhancement might be necessary.
Prerequisite:
darwinia-network/darwinia-common#776
Enhancement:
Currently, the price relayers ask is an const number, and when user call the sends_message dispatch call, the call will sort all the ask prices and give a matched price for the message data(order) to deliver.
Even though relayers can update the const number from time to time, but for a specific time, the const price given by relayer is a proposal for all kinds of messages, after the user send and order matched, the relayer must deliver as expected no matter the cost high or low, otherwise he will be slashed for not delivering. This result a difficult problem for relayers to putting ask prices on-chain because the messages are unknown when putting these ask prices. For example, some message might consume huge cost when dispatching on target chain, and this brings large unfavorable risks to relayers, and will disincentive the market.
To enhance the solution, we change change original const price to a function of message,
price = f(message)
, this function will be stored on chain for evaluation, and for each message, the price match will be pre-processed using this evaluation, and sorting using post evaluation prices. The original const price, can be taken as f(message) = c where c is the const number.Security:
Care must be taken when implementation this, especially for the evaluate function on-chain, e.g. if we use solidity smart contract to express this function, we must pass a max_gas_limit for each evaluation, in case some malicious relayer stall the runtime dispatch call by deploy and set a large gas consume(e.g. large loop) contract/function.
The text was updated successfully, but these errors were encountered: