Is your feature request related to a problem? Please describe.
Currently the TicketParams expiration is set to 5 blocks which forces relatively strict sync between Orchestrators and Broadcasters in terms of their view of the canonical Ethereum chain.
|
var paramsExpirationBlock = big.NewInt(5) |
It's also possible for the TicketParams to expire when a segment is in flight, while this is an edge case because input segments are capped in size it is still possible to occur, especially since Ethereum blocktime is not fixed.
The propasal is to double this duration to 10 blocks , which would be 2 minutes on average. This seems to be a reasonable balance between sync requirements between nodes and staleness of values such as ticket faceValue, which depends on the gas price.
Additional context
We also want to refresh ticket params before they expire at e.g. 10% before that in #1852. At the current expiration this would involve frequent refreshes, at 10 blocks this seems more reasonable.
Is your feature request related to a problem? Please describe.
Currently the
TicketParamsexpiration is set to 5 blocks which forces relatively strict sync between Orchestrators and Broadcasters in terms of their view of the canonical Ethereum chain.go-livepeer/pm/recipient.go
Line 24 in 1e5154a
It's also possible for the
TicketParamsto expire when a segment is in flight, while this is an edge case because input segments are capped in size it is still possible to occur, especially since Ethereum blocktime is not fixed.The propasal is to double this duration to 10 blocks , which would be 2 minutes on average. This seems to be a reasonable balance between sync requirements between nodes and staleness of values such as ticket faceValue, which depends on the gas price.
Additional context
We also want to refresh ticket params before they expire at e.g. 10% before that in #1852. At the current expiration this would involve frequent refreshes, at 10 blocks this seems more reasonable.