New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Delegating to non-active transcoders #102
Comments
I think this is something we should think about, but it introduces more overhead for delegators in understanding the protocol and more actions, and I don't think it's necessary to include this in one of the immediate milestones for audit. |
Ah so I originally thought this meant a delegator's bonded stake could count twice, once toward the active transcoder and once toward the non-active transcoder. After talking with someone from Cosmos, I now understand that the commitment is just a signal to the rest of the network that the delegator will bond to the transcoder when the transcoder becomes active, but the commitment does not actually count toward the transcoder's total stake. So, delegators would signal to others using this commitment, and once there is enough committed for a non-active transcoder to kick out an existing active transcoder, all the delegators would convert their commitments to bonded stake towards the non-active transcoder at the same time. I'm curious if this opens up the possibility of malicious behavior by transcoders toward other transcoders. One example might be if the active transcoder observes that its delegators are committing to a non-active transcoder and attacks the non-active transcoder off-chain. On one hand this might not necessarily compromise the cryptoeconomic security of the protocol, on another it might harm the quality of service in the network if a non-active transcoder is being attacked off-chain by an active transcoder that is trying to defend its position. Another example might be a non-active transcoder with resources that are already a sunk cost (since it already paid for the hardware) that it dedicates to attacking active transcoders to degrade their quality of service in an effort to convince delegators to commit towards the non-active transcoder. I agree that this is something we should think more deeply about, but the additional cognitive burden on delegators when making bonding decisions in addition to the uncertainty around how the incentives impact behavior make it something to probably address in a later milestone. |
What do you mean by "active transcoders attacking non-active transcoders
off chain?"
…On Mon, Nov 6, 2017 at 12:32 PM, Yondon Fu ***@***.***> wrote:
Ah so I originally thought this meant a delegator's bonded stake could
count twice, once toward the active transcoder and once toward the
non-active transcoder. After talking with someone from Cosmos, I now
understand that the commitment is just a signal to the rest of the network
that the delegator will bond to the transcoder when the transcoder becomes
active, but the commitment does not actually count toward the transcoder's
total stake. So, delegators would signal to others using this commitment,
and once there is enough committed for a non-active transcoder to kick out
an existing active transcoder, all the delegators would convert their
commitments to bonded stake towards the non-active transcoder at the same
time.
I'm curious if this opens up the possibility of malicious behavior by
transcoders toward other transcoders. One example might be if the active
transcoder observes that its delegators are committing to a non-active
transcoder and attacks the non-active transcoder off-chain. On one hand
this might not necessarily compromise the cryptoeconomic security of the
protocol, on another it might harm the quality of service in the network if
a non-active transcoder is being attacked off-chain by an active transcoder
that is trying to defend its position. Another example might be a
non-active transcoder with resources that are already a sunk cost (since it
already paid for the hardware) that it dedicates to attacking active
transcoders to degrade their quality of service in an effort to convince
delegators to commit towards the non-active transcoder.
I agree that this is something we should think more deeply about, but the
additional cognitive burden on delegators when making bonding decisions in
addition to the uncertainty around how the incentives impact behavior make
it something to probably address in a later milestone.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#102 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAAola3kjnbnJyTseP4sVfrjQ7QtG7m5ks5sz0KcgaJpZM4QJ-5a>
.
|
I'm not totally sure what the details would be, but was just suggesting that if an active transcoder sees its delegators committing to a non-active transcoder, it could be in the active transcoder's interest to take measures to make sure the non-active transcoder is not able to operate effectively on the network to sway delegators into not committing to that transcoder. Just jotting down thoughts. I guess you would need access to the relevant node information as well to stage any type of attack... |
Would it make sense to close this issue and continue this discussion in #191 ? |
@jozanza I can see why they're related, but I think this can be left open since it solves a separate problem. #191 is more about discovery and campaigning of candidate transcoders, and this issue is more about the incentive to actually delegate any stake towards one. Right now you would receive 0 rewards or fees if you delegate towards a non-active transcoder, whereas a solution like the ones suggested in this issue would incentivize you to delegate towards the best up-and-coming transcoders without penalty, increasing the competition and decentralization of the network. |
Ah gotcha! Carry on :) |
I was talking to Sunny from Cosmos, and he suggested a solution to the transitive delegation problem that they may be using.
Delegating to non-active transcoders essentially "commits" your stake to be bonded towards them if they become active. In the meantime, your stake can remain bonded towards an active transcoder if you wish it to.
I suppose if your active transcoder becomes inactivated, you can then proactively rebond towards someone active, and recommit towards the inactive transcoder if you wish.
The text was updated successfully, but these errors were encountered: