Time-Sensitive Event Relay Payouts
Last updated
Last updated
Prompt Delivery
For event relay, it is not enough that messages eventually get delivered - the speed of reliablity delivery is also important. This depends on Seeker Nodes running sufficient infrastructure to deliver relay requests as soon as possible, and therefore on the level of investment that nodes make in their infrastructure - something Nodes are naturally inclined to minimise.
The current blockchain block number is included in each Sylo Ticket when the ticket is issued, and signed by the ticket's sender. This block number defines the start of the ticket's valid duration, and is used to measure time. This trustless measure of elapsed time is then used to modify the ticket's probability of winning, decreasing the ticket's expected value as time goes on.
To incentivise relays to be delivered as soon as possible, the mechanism that pays out winning Sylo Tickets is modified, so that the probability of a Ticket winning decreases as the time since the relay request was made increases.
This creates a direct incentive for Seeker Nodes to perform relay as soon as possible, to maximise their income from performing the service. It similarly incentivises them to invest in throughput and uptime improvements.
Reliable Delivery and Spam Prevention
When a user of the Sylo network sends a relay, they need to be confident that the node will faithfully attempt to deliver that relay packet until it expires - even if that packet is unlikely to be collected. This means that paying nodes only once the relay packet is delivered is not sufficient, for two reasons:
"Cold relays", sent to addresses that may never come to collect their relay packet from the node, have a very low value to the node. This is because the longer a ticket is in flight, the higher the ticket’s total memory costs are to the node. Also, the longer it has been in flight , and the lower the prospective value of redeeming that ticket is - both because of the decaying win probability, and because of the reduced likelihood that the recipient will ever come to collect it.
Without residual ticket value, it’s likely that rational nodes would choose to discard "close to expiry" tickets to make room in memory for newer relay payloads, rather than invest in additional storage to claim the unreliable payout associated with these relays.
If an attacker knows that a particular recipient will not arrive to collect their relay packets, then the attacker could send a large volume of relay to that recipient as spam. These relays would appear to the node as potential income, but the attacker would know that none of those relays would ever be delivered, and therefore know that they would never have to pay the node for any of it.
The solution is to compensate the node for holding a relay packet until expiry, even if that relay packet is never delivered - payments for expired tickets.
This is technically challenging, because unlike with relay payments, the relay receiver cannot unlock a random number from the sender to authorise the release of their funds from escrow. A new mechanism is needed to generate this randomness in a trustless way.