Support DelegatedSending invites from arbitrary stars #17
Conversation
With that, supports receiving invites from any number of stars, rather than just a planet's prefix.
There was a problem hiding this comment.
This looks correct. I may have mentioned it before, but there is an approve-like concern with setPoolSize, which is that if someone in a pool of size N sees in the mempool that the pool size is about to change to M, they can quickly send invites for N planets with a relatively high gas price, hopefully beating the setPoolSize transaction. In this way, they can send N+M invites, when we should be able to restrict them to sending only max(N,M).
The two general approaches to mitigating this are: (1) define changePoolSize as a delta rather than an absolute number or (2) have setPoolSize accept an old-size argument, and we only change the pool size if that matches the current size of the pool. However, because these will generally be used in contexts that have non-zero preexisting trust, I don't think it's a problem.
|
Neither of the proposed solutions account for the "I'm taking away a planet's invites" case, where the "race condition" would still end up with more consumed invites than desired. But, again,
So, agree on leaving this "unsolved". (Though I guess as a defense, stars could temporarily disable Delegated Sending support (by un-setting their spawn proxy) while they make such changes.) |
Currently, stars can only give invites to their child planets. Since most early adopters (among who many star owners) own/use planets somewhere under ~zod, this makes them unable to send out invites as themselves. Instead, they must manually spawn a planet to whoever they want to give invites to, and only from there build out invite trees.
In this PR, we change the logic in the contract to allow planets receiving invites from any amount of arbitrary stars, rather than just their prefix.
The
poolsmapping(uint32 => uint16)becomes amapping(uint32 => mapping(uint16 => uint16)), and we add in both amapping(uint32 => uint16[]) poolStarsand amapping(uint32 => mapping(uint16 => bool)) poolStarsRegisteredto aid in discovering and managing that data respectively.It remains up to client implementations to discover planets that are eligible for sending. This is a bit more work than it used to be, but isn't the end of the world. I will add functionality for this into azimuth-js soon.