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
{{ message }}
This repository has been archived by the owner on Mar 28, 2023. It is now read-only.
We have a bunch of testnet keep nodes maintained by the community members. For the random beacon, we have an automatic relay request submitter keeping the testnet nodes busy. The mix of well-configured and misconfigured nodes allowed us to identify and fix some issues in the code.
For tBTC and ECDSA nodes, the vast majority of the network load comes from manual user interactions with the dApp which is great but is not frequent enough to help us find problems we are not aware of.
We should have an automatic process stressing tBTC and ECDSA keeps similar to how the relay request submitter stresses the random beacon.
It does not have shouldn't be something very complex, I think it needs to meet two requirements:
members with misconfigured nodes (e.g. no public IP) are quickly eliminated from the network by seizing their bonds after the timeout and eventually removing them from the sortition pool.
Additionally, the solution should provide us with a clear understanding of the network state. For example, how many deposits were successfully created and how many deposits failed and when. The information should be easily available, without the need of reverse-engineering the logs which is no longer possible given the great community involvement and the number of nodes running.
The text was updated successfully, but these errors were encountered:
We have a bunch of testnet keep nodes maintained by the community members. For the random beacon, we have an automatic relay request submitter keeping the testnet nodes busy. The mix of well-configured and misconfigured nodes allowed us to identify and fix some issues in the code.
For tBTC and ECDSA nodes, the vast majority of the network load comes from manual user interactions with the dApp which is great but is not frequent enough to help us find problems we are not aware of.
We should have an automatic process stressing tBTC and ECDSA keeps similar to how the relay request submitter stresses the random beacon.
It
does not haveshouldn't be something very complex, I think it needs to meet two requirements:tbtc.js
(https://github.com/keep-network/local-setup/blob/master/e2e/e2e-test.js for reference),Additionally, the solution should provide us with a clear understanding of the network state. For example, how many deposits were successfully created and how many deposits failed and when. The information should be easily available, without the need of reverse-engineering the logs which is no longer possible given the great community involvement and the number of nodes running.
The text was updated successfully, but these errors were encountered: