This repository was archived by the owner on Jan 20, 2026. It is now read-only.
Move Parallel TX Signalling to Sei-Chain DeliverTx call #38
Closed
BrandonWeng wants to merge 2 commits intomainfrom
Closed
Move Parallel TX Signalling to Sei-Chain DeliverTx call #38BrandonWeng wants to merge 2 commits intomainfrom
BrandonWeng wants to merge 2 commits intomainfrom
Conversation
BrandonWeng
changed the title
udpatil
reviewed
Oct 7, 2022
| for _, channels := range accessOpsToChannelsMap { | ||
| for _, channel := range channels { | ||
| channel <- struct{}{} | ||
| func WaitForAllSignals(txIndex int, messageIndexToAccessOpsChannelMapping MessageAccessOpsChannelMapping) { |
| for _, channels := range accessOpsToChannelsMap { | ||
| for _, channel := range channels { | ||
| <-channel | ||
| func SendAllSignals(txIndex int, messageIndexToAccessOpsChannelMapping MessageAccessOpsChannelMapping) { |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Same as this PR: sei-protocol/sei-chain#291
Describe your changes and provide context
Previously we were signaling and blocking for each handler in the message - in theory, this is fine as we are supposed to be processed synchronously based on the access operation, however, due to us not having enough granularity, blocking on messages is not sufficient as the ordering for when each message is unblocked (between different TXs) could be different. This results in different gas fees or different bank AVL tree shapes as the node insertion order matters.
Therefore, as we do not have more granular support for per-message concurrency, we should be okay with just blocking on the entire transaction and ensuring that no r/w can occur unless the entire TX is ready to be processed. This is operating on the assumption that the majority of transactions will not have overlapping resources.
Note that the Gas used is based on the size of the data returned, depending on the ordering of the message process it's possible that some may result in the same bank data being returned with less digits, and therefore costing different gas.
Testing performed to validate your change
Ran the 20 iterations of load test with 5 rounds each and saw that the chain didn't get stuck and from previous outputs of the delivered, the messages are being processed sequentially as expected based on the logs. This was in a 5 node cluster
With these PRs merged, we should be able to then define more granular access operations for the message types we want to support e.g Bank Send should have access operations for read to sender, writing to both sender and receiver, and the contractAddr
#35
#37
sei-protocol/sei-chain#287