epoching: API: epoch_msgs/{epoch_num} -> all events during this epoch #108
Conversation
SebastianElvis
changed the title
x/epoching/abci.go
Outdated
| // init epoch msg queue | ||
| k.InitMsgQueue(ctx) | ||
| // if epoch 1, then copy all queued msgs in epoch 0 to epoch 1 | ||
| // TODO: more elegant way to do this? e.g., reject all msgs submitted in epoch 0? |
There was a problem hiding this comment.
As I understand epoch 0 is the genesis block. There the genutil module executes the MsgCreateValidator methods directly, we have no delays. Why is this copying necessary?
There was a problem hiding this comment.
There the genutil module executes the MsgCreateValidator methods directly, we have no delays.
Yeah MsgCreateValidator does not go through the msg queue so is not delayed.
Why is this copying necessary?
Cosmos SDK does not execute BeginBlock and EndBlock for the genesis block. If someone submits a wrapped msg (e.g., MsgWrappedDelegate) at genesis block (i.e., in epoch 0), then it will be put in epoch 0's msg queue. However, since epoch 0 does not have EndBlock invocation, the queued msg will never be handled. This corner case was tested by fuzzing tests in epoch_msg_queue_test.go.
This PR works around this issue by copying all queued msgs in epoch 0 to epoch 1 upon BeginBlock of block 1. Another fix I can think of is to reject all wrapped msgs submitted during epoch 0. Do you have any better alternatives?
There was a problem hiding this comment.
Thanks for the explanation. I just don't understand how anyone can send anything in the genesis block. The genesis block is created purely based on the genesis.json file, isn't it?
There was a problem hiding this comment.
Yeah it's weird that the system handles messages during block 0. So perhaps let's reject validator-related msgs during block 0?
There was a problem hiding this comment.
Maybe it was just an artifact of the simulation? Rejection sounds good to me.
x/epoching/keeper/epoch_msg_queue.go
Outdated
| // InitQueueLength initialises the msg queue length to 0 | ||
| func (k Keeper) InitQueueLength(ctx sdk.Context) { | ||
| store := ctx.KVStore(k.storeKey) | ||
| // InitQueueLength initialises the msg queue length of the current epoch to 0 |
There was a problem hiding this comment.
| // InitQueueLength initialises the msg queue length of the current epoch to 0 | |
| // InitMsgQueue initialises the msg queue length of the current epoch to 0 |
|
Thanks for the comments Akosh! Now this PR rejects any of wrapped msg types during genesis block (i.e., when block height is 0). It also makes a number of minor fixes that do not affect the functionality, and rebases to the latest main branch. Feel free to have a look again. |
Fixes BM-119
This PR provides the API that given an epoch number, outputs the information of queued msgs during this epoch, including the msg type, submitted block height, validator address and amount for each queued msg.
Specifically,
oneoffeatureblock_heightinQueuedMessagemsgofQueuedMessage