Feat/add miner deposit v3

[tediou5]

Fip: FIP-0077
Fip update: FIP-0077 update
Discussions: discussions

Also, should we allow users to use the deposit as an initial pledge? I think i can do this.

[anorth]

I'm reviewing this as a high level implementation proposal rather than in detail yet.

There are two decisions here that cause a much larger impact on code and complexity that I think necessary.

• New state for the deposit. We already have a vesting table capable of representing the idea of funds locked until some epoch. Adding new state representing a new type of locked funds means all the calculations about balances need to take that into account. The chance of introducing an error now or later is very high. It requires a state migration. I can't see any advantage of the separate representation.
• A new method for the deposit. The deposit is required at miner creation. It would be simpler to just pass the funds in the call to the miner constructor (which already happens) and compute the lock in that constructor. The duplication of miner logic code in the power actor will not be acceptable (though we could extract it somewhere to share). The power actor is already calling the miner actor once, there's no point calling a second time. The only parameter is the lock amount, which can be computed at the miner, so we don't need to adjust the miner constructor parameters. The constructor can fail if the balance is insufficient for the lock.

[anorth]

should we allow users to use the deposit as an initial pledge

I don't think this is worth the complexity it will involve to implement it. I suggest not doing that for now.

[tediou5]

@anorth

A new method for the deposit. The deposit is required at miner creation. It would be simpler to just pass the funds in the call to the miner constructor (which already happens) and compute the lock in that constructor. The duplication of miner logic code in the power actor will not be acceptable (though we could extract it somewhere to share). The power actor is already calling the miner actor once, there's no point calling a second time. The only parameter is the lock amount, which can be computed at the miner, so we don't need to adjust the miner constructor parameters. The constructor can fail if the balance is insufficient for the lock.

Yeah, I'm just want an early exit here. I will fix this.

---

New state for the deposit. We already have a vesting table capable of representing the idea of funds locked until some epoch. Adding new state representing a new type of locked funds means all the calculations about balances need to take that into account. The chance of introducing an error now or later is very high. It requires a state migration. I can't see any advantage of the separate representation.

Yes, adding a state makes it a lot more complicated. But its very easy and necessary to use the deposit as an initial pledge, if we have an deposit state.

Maybe we could give it a try ? Or if you're very adamant here, I can remove the code.

[anorth]

Yes, adding a state makes it a lot more complicated. But its very easy and necessary to use the deposit as an initial pledge, if we have an deposit state.

My opinion is that it is not worthwhile to have that feature. I'm open to other opinions, more information etc though. My default stance is that any additional complexity has to bring a lot of benefit.