-
Notifications
You must be signed in to change notification settings - Fork 2.7k
Consider accepting new Phragmén solutions if they are _significantly_ better #6106
Comments
Are all these solutions included in blocks? Isn't that just output of If that is a problem perhaps having a two-phase approach would help, where you first only commit the score and only if you win this on-chain auction are you required to reveal the actual solution? |
That sound sensible as well, since afaiu accepting a solution is quite costly and the score improvement might not be worth the cost of the change. |
I think this is not an issue, I can double check but I'm pretty sure that weak solution are not successful, also including a weak solution is cheap it is just comparing the scores. and with #6032 it won't even consume weight. Having some extrinsic which returns error in pre_dispatch_checks can happen, I don't think this is a bug. EDIT: I doubled check with queryStorage, the queuedscore only change with better score. so the weak submission doesn't change the queued score.
Actually in your data set there is:
I think these number are quite fine already. EDIT: this message has been edited, I mixed myself in my tests but I'm confident with result now |
I scraped the
Yeah, but this will never happen anyhow because we will not propagate anything. In each node's transaction pool, there will ever be the state and potentially one and only one solution transaction that the next block author intends to add to the block.
Maybe, but I first want to decode what is going on here and with the current system.
it might be fine as in it is not burning the chain 😀 but the intention here is that ideally, the validators, unless if they are stuck in some fork or out of sync for any reason, must always submit strictly better solutions, because the code in Preferably we must minimise failure before #5980 I will try and update this next week with scraping some events. Should give more insight. |
I have a new log. Note the block and era numbers to get the ordering correct. The order of logs top to bottom is new to old, but within an era, the line of logs is top to bottom old to new. Prefix meanings:
https://gist.github.com/kianenigma/d331a7de720bb87c96c661d6221c861e and as for the errors, 16 is indeed |
For the comparison function, we can define an improvement parameter x, for instance x = 1.01, and then do the following comparison: IF ( Looking at the log, it looks like most new submissions are only better off by a tiny amount, less than 0.2 percent in one of the scores, with respect to the current best solution. So if we require an improvement of at least 1 percent in one of the scores, we'd have a lot fewer submissions. |
After chatting with @kianenigma we have a theory why this happens.
Now usually, when we push such transaction to a block, we will end up running So it seems that the solution to ❌ transactions is to remove the |
I have some interesting dumps from kusama blocks and the solutions that are being submitted.
Two concerns:
score[3]
should always increase. This is not the case all the time and it could potentially be a bug. Although I can't see how we could have done this wrong:and we run this in the
validate_unsigned
, hence validators can only include this transaction if it is better than the on chain value.. which does not make a lot sense here. Sadly the logs of staking are currently native only and we cannot see them on kusama. I will have to move them to wasm as they make debugging this easier.UPDATE: looking more into the logs, I see even solutions that are submitted but are evidently worse than the ones submitted before (
score[0]
is worse). I should scrape the events of these blocks as well and see of these were successful calls. But I am not sure how they could have failed? maybe due to re-org they were seeing the wrong state? if so, this means that validators could submit wrong solutions and we should be careful and not fix #5980 before we figure out what is going on here.cc @tomusdrw @AlfonsoCev
The text was updated successfully, but these errors were encountered: