Content
@
0 reply
0 recast
0 reaction
vrypan |--o--|
@vrypan.eth
Signers (rebranded as app keys) are extremely powerful, but I think they are becoming a disaster waiting to happen. Users are not aware how to manage them, and even if they were, there are no reliable tools to do so. Does anyone else share the same concerns? If so, what can we do to improve them?
2 replies
0 recast
8 reactions
Stephan
@stephancill
It’s also not intuitive that all messages get invalidated once a signer is deleted. Like you mentioned as well, easily rebroadcasting messages from an invalidated signer will not be possible with the rate limits introduced by snapchain right? Strong ordering could help with automatic signer expiry and invalidating signers (all messages after invalidation snap are invalid)
2 replies
0 recast
8 reactions
Stephan
@stephancill
cc @v Moving signers off chain onto hubs would also help with being able to iterate on this more easily
1 reply
0 recast
0 reaction
vrypan |--o--|
@vrypan.eth
Why move them off chain? The way I imagine it is that signer approval/removal OnChainEvents will be included in snaps. So you know when they were added and when they were removed, and you don't need to invalidate all their messages.
2 replies
0 recast
2 reactions
Stephan
@stephancill
sure you could build a layer of business logic on top of the key registry contract in hubs, but that further complicates an already complicated system the key registry contract already has a state machine, so i envisioned the implementation to be introducing more states
1 reply
0 recast
0 reaction
vrypan |--o--|
@vrypan.eth
How does it complicate the system? The sequencer(s) will put onchain events in blocks, anyway. Since they are in order, you can add a rule that hubs can not accept any more messages from a signer that was removed in a previous snap. No need to invalidate old messages, and no need for significant changes in smart contracts. (Actually, the is what I thought you suggested)
1 reply
0 recast
1 reaction
Stephan
@stephancill
you're right, this could just be an extension of pruning logic
1 reply
0 recast
1 reaction
vrypan |--o--|
@vrypan.eth
Yes. The reason we can't do it now, is because there is no way to define if a message was before or after an onchain event, so it's all or nothing. But ordering provides two points in time, and messages are valid if they are between these two points (signer add/remove).
0 reply
0 recast
1 reaction
