-
Notifications
You must be signed in to change notification settings - Fork 278
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
adds evm_client wait for transaction confirmation to QGB #354
adds evm_client wait for transaction confirmation to QGB #354
Conversation
ec.logger.Info("ValSetUpdate", tx.Hash().String()) | ||
|
||
// TODO put this in a separate function and listen for new EVM blocks instead of just sleeping | ||
for i := 0; i < 60; i++ { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why the magic 60
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It was 6 at the beginning to wait for a minute. However, I am testing against rinkeby/ropsten, and they take a lot of time to include transactions in blocks. So, I changed it to 10 minutes of wait time.
In the future, when we have the worker pool design, we will change this by listening to new blocks and waiting for a number of confirmations before moving to the next attestation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a QGB contract in action:
https://ropsten.etherscan.io/address/0x820a20eb3c8f7789557595874b89dd71fea11a0e
I am generating a new valset every 15 Celestia blocks.
Don't mind the failing transactions, as those are duplicates (will be fixed when we implement the new design)
PS: We still don't use the latest nonce => height
change, and we're deploying an older version
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
makes sense for a temporary solution
👍
// TODO put this in a separate function and listen for new EVM blocks instead of just sleeping | ||
for i := 0; i < 60; i++ { | ||
ec.logger.Debug(fmt.Sprintf("waiting for valset %d to be confirmed: %s", nonce, tx.Hash().String())) | ||
lastNonce, err := ec.StateLastValsetNonce(&bind.CallOpts{Context: ctx}) | ||
if err != nil { | ||
return err | ||
} | ||
if lastNonce == nonce { | ||
ec.logger.Info(fmt.Sprintf("relayed valset %d: %s", nonce, tx.Hash().String())) | ||
return nil | ||
} | ||
time.Sleep(10 * time.Second) | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
as stated in the todo, I like the idea of a separate evm client method that waits for a specific update or something similar
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
let's write that down in an issue if we haven't already tho
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can create a generic method that subscribes to new blocks and checks if a transaction hash is included or not.
Could be something like:
func (ec *EvmClient) waitForConfirmations(txHash string, numberOfConfirmations int) error
I wrote some snippets, but it would take much time debugging and making it work. Especially that subscribing to events requires using a web socket connection and that needs to be added to the config which itself needs to be updated to reflect the different commands.
Thus, I decided to leave it for later and do this instead.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
issue: #356
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let me know if we can merge.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Adds a simple waiting mechanism to wait for evm client transaction confirmation before sending the next transaction.
Closes #319