-
Notifications
You must be signed in to change notification settings - Fork 2.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
refactor(protocol): add an invocation delay #15553
Merged
Merged
Conversation
This file contains 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
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
davidtaikocha
approved these changes
Jan 24, 2024
dantaik
changed the title
refactor(protocol): reuse
refactor(protocol): add an invocation delay
Jan 24, 2024
messageStatus
for recalled messages
auto-merge was automatically disabled
January 24, 2024 02:08
Merge commits are not allowed on this repository
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
The idea is to enhance the Bridge's security by enforcing a delay before a message can be actually invoked. If the invocation delay is set to 0 (by default), the bridge functions the same way as it used to be, but if a non-zero delay is configured,
processMessage
andrecallMessage
must be called twice for each message. The first call will verify the message is indeed received with a merkle proof and timestamp the message; the second call will actually invoke the message.New tests for non-zero invocation delay will be added once we decided to proceed with this feature.