Skip to content
This repository was archived by the owner on Jan 20, 2026. It is now read-only.

Validate Concurrent Messages + Update BankSend #76

Merged
BrandonWeng merged 22 commits intomainfrom
bweng-tx-validation-testing
Oct 28, 2022
Merged

Validate Concurrent Messages + Update BankSend #76
BrandonWeng merged 22 commits intomainfrom
bweng-tx-validation-testing

Conversation

@BrandonWeng
Copy link
Contributor

Describe your changes and provide context

  • CacheKv Stores emit an access operation event used to track accesses to resources during runTx, we only need to add it to cacheKv because we branch before runMsgs and ante handlers
  • Adds validation logic

Will also need to add validation for ante handlers

Testing performed to validate your change

Testing part of this PR:
sei-protocol/sei-chain#345

@BrandonWeng BrandonWeng marked this pull request as ready for review October 27, 2022 14:24
{AccessType: AccessType_WRITE, Identifier: "a/b/c/d/e"}: true,
},
},
{
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that we're not checking for extra access ops defined, I think it's harder to check here since the path will not always result in the same set of access ops (e.g if account already exists vs if bank sends needs to create one)

I think this is fine for now as that's less f a priority and may just result in less concurrency but it's safer.

err error
)

msgCtx, msgMsCache := app.cacheTxContext(ctx, []byte{})
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

just to make sure i understand, the reason we take another cache here is so that we can discard the events later?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The messages should not be committed in general as it's not being returned in the Tx result, but this branch allows us to make sure that the events in the CacheKv store only reflects the access ops for this message, so we can compare it per message, since that's how access ops are defined

}

value := mi.Iterator.Value()
mi.eventManager.EmitResourceAccessReadEvent("iterator", key, value)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do we need value?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not for the validation but I found it to be really useful for debugging missing Access Ops as most of the time the keys are not in a readable format.

We're also not committing the events returned from this store so I thought it would be fine to leave it here


// ValidateAccessOperations compares a list of events and a predefined list of access operations and determines if all the
// events that occurred are represented in the accessOperations
func ValidateAccessOperations(accessOps []AccessOperation, events []abci.Event) map[Comparator]bool {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i might have missed it but where do we compare resource type? it doesn't seem like we are consolidating all those different KV resource types

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Addressed in the follow up commits, passing a store key, and defining a mappign of the storekey to the resource types and prefixes to do the matching

@BrandonWeng BrandonWeng force-pushed the bweng-tx-validation-testing branch from 3b24775 to 1e59ce1 Compare October 27, 2022 23:46
return comparators
}

func (c *Comparator) DependencyMatch(accessOp AccessOperation, prefix []byte) bool {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

in the process of adding more unit tests for this method

@BrandonWeng BrandonWeng force-pushed the bweng-tx-validation-testing branch from 81adcfe to 7540df1 Compare October 28, 2022 02:30
@BrandonWeng BrandonWeng merged commit 172cdd9 into main Oct 28, 2022
@BrandonWeng BrandonWeng deleted the bweng-tx-validation-testing branch October 28, 2022 13:09
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants