Hey @Ducky,
Could you forward my question to the related devs?
I examine the code related to pDex request actions. In the end, I’ve reached that pDEX is not fair for the trade requests within the same beacon height.
Here is the related code:
func categorizeNSortPDECrossPoolTradeInstsByFee() in beaconstatefulinsts.go
// sort tradable actions by trading fee
sort.Slice(tradableActions, func(i, j int) bool {
firstTradingFee, firstSellAmount := prepareInfoForSorting(
currentPDEState,
beaconHeight,
tradableActions[i],
)
secondTradingFee, secondSellAmount := prepareInfoForSorting(
currentPDEState,
beaconHeight,
tradableActions[j],
)
// comparing a/b to c/d is equivalent with comparing a*d to c*b
firstItemProportion := big.NewInt(0)
firstItemProportion.Mul(
new(big.Int).SetUint64(firstTradingFee),
new(big.Int).SetUint64(secondSellAmount),
)
secondItemProportion := big.NewInt(0)
secondItemProportion.Mul(
new(big.Int).SetUint64(secondTradingFee),
new(big.Int).SetUint64(firstSellAmount),
)
return firstItemProportion.Cmp(secondItemProportion) == 1
})
return tradableActions, untradableActions
How does this code work? Let me go through by an example (trade requests are sorted chronologically and they are in the blocks within the same beacon height):
Time : SellAmount --> MinAcceptableAmount
t0. sec : 100 PRV --> 1 BTC (T1)
t0+10. sec : 1 BTC --> 100 PRV (T2)
t0+20. sec : 100 PRV --> 1 BTC (T3)
t0+30. sec : 100 PRV --> 1 BTC (T4)
The shards of the trades do not matter here.
Currently, since the trading fee is zero (%0 percent), the multiplication of trading and sell amount is always equal to zero. What does it mean?firstItemProportion.Cmp(secondItemProportion)
always returns 0 (https://golang.org/pkg/math/big/#Int.Cmp) since firstItemProportion
and secondItemProportion
are both zero. Then return firstItemProportion.Cmp(secondItemProportion) == 1
always returns false. In that case, someone expects that they would be executed chronologically. If this happens and we assume that the pool size respects our scenario,
T1 is accepted, T2 is accepted, T3 is accepted and then T4 is refunded since it requests more than the minimum acceptable amount.
However, I read the definition of sort.Slice
function and run the example with different scenarios on that page (https://golang.org/pkg/sort/#Slice). Its sorting is not stable by definition. So, the requests may be executed in any order. For example,
T1 (accepted) --> T3 (refunded) --> T2 (accepted) --> T4 (accepted)
On the same page, there is sort.SliceStable
function. However, it is not fair too since it is biased to the order in the array of the trade requests. So the order is determined how the dev fills up the array. For example, if she fills up the array with T1, T3, T4, T2 in a loop, then the requests will be executed in that order.
Finally, here is my question In the absence of the trading fee, to make pDEX fair, is it possible and correct to use LockTime
property of Txs to sort them chronologically?
Regards,