You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As per changes delivered under #67 it was introduced that the bridge contracts data are used to get required length of the message. The implemented logic assumes that the length is accessed only once when the bridge is being run. And for the case when the bridge contracts are upgraded as so the required length of the message is being changed, all bridge instances needs to be re-run.
Sometimes it is hard to manage restart of several independent application instances, so it will be useful to have an ability to re-read the length without the bridge re-initialization.
One of possible approach is to re-read the length every time when new message is being prepared. But it will introduce huge amount of similar RPC calls and huge amount of the same responses. It could impact the bridge instance performance.
Another approach was described here #67 (comment) and it was agreed that it could be implemented as soon as the work for #24 is finished.
The text was updated successfully, but these errors were encountered:
The problem with the second approach is that the assert will continue to pass: the contract may have changed the required length, but the code is the same. If the code was modified, then the bridge had to be restarted, and re-reading the variable is not necessary.
An alternative approach is this: in the estimateGas function, after all the checks we already have, we add one more checking if the required message length in the contract is different than the one we have. If it is, we throw an error indicating that, and use it to update the variable.
As per changes delivered under #67 it was introduced that the bridge contracts data are used to get required length of the message. The implemented logic assumes that the length is accessed only once when the bridge is being run. And for the case when the bridge contracts are upgraded as so the required length of the message is being changed, all bridge instances needs to be re-run.
Sometimes it is hard to manage restart of several independent application instances, so it will be useful to have an ability to re-read the length without the bridge re-initialization.
One of possible approach is to re-read the length every time when new message is being prepared. But it will introduce huge amount of similar RPC calls and huge amount of the same responses. It could impact the bridge instance performance.
Another approach was described here #67 (comment) and it was agreed that it could be implemented as soon as the work for #24 is finished.
The text was updated successfully, but these errors were encountered: