dshulyak
dshulyak
i think the actual problem here is that it takes too long to recount votes. and the reason for that is the bug in how state was stored, so that...
this is actually not very clear how to do it efficiently, the brute force will scan all objects. but that would be very slow and will require keeping identities on...
all 4 nodes are running on same hardware? i think to reproduce someone should take latest state, and try to build proposals with different parallelism factor
- [x] provide better debug data (as step by step latency) https://github.com/spacemeshos/go-spacemesh/pull/5130 - [ ] load active set when node boots up, and not on layer timer - [ ]...
i reworked some inefficiencies in that area. also in v1.2.2 there will be a log like: > logger.go:130: 2023-10-18T09:46:21.554+0200 INFO proposal created {"signer": "ea734", "proposal_id": "41510aa9e1", "transactions": 2, "mesh_hash": "0000000000",...
one other thing we can do is to prepare activeset in advance. in the implementation activeset selected in the first layer of the epoch. the process of selecting activeset becomes...
i think we can do something simpler for malfeasance proofs, following the pattern in https://github.com/spacemeshos/go-spacemesh/pull/5599. we can ask 5-10 peers for all equivocating identities every 10-30 minutes. and then download...
proposed protocol: - on node startup check how long ago proofs were synced, if it was in a previous epoch or a quarter of epoch ago download all malfeasance identities...
depends on the improvements in atx propagation