More API between user-programmed actors and built-in miner actor for building decentralized staking protocol

[jennijuju]

@Schwartz10 @jennijuju

Abstract

Upon the FEVM launch, FIP-0050 was also introduced with a list of the builtin actor methods that are exposed as callables from user actors. Since then, we’ve seen a number of protocols build lending or leasing applications around Miner Actors collateral & rewards. As common practice in DeFi, protocols often introduce a “liquidation” procedure that liquidates a borrower’s collateral to derisk the liquidity providers from losing lent out funds. In the process of Filecoin leasing applications, a liquidation means termination of a miner’s active sectors, facing a penalty, but recovering pledged collateral to return to liquidity providers. Economic security of applications being built on the FEVM is important for developing trust and attracting outside capital / liquidity / investors, and understanding precise collateral values for any given miner actor is critical for a DeFi protocol’s economic security.

More exported APIs in miner actor are required to support onchain liquidation procedure for decentralized staking protocol.

Change Motivation

As DeFi protocols on Filecoin gain traction and lock larger amounts of value, they will be targets for more attacks. As an ecosystem, we should create the necessary primitives to build secure economic applications that use miner actors as collateral.

There are a few motivations behind the proposals:

• Trustless DeFi - it’s important that users of a DeFi protocol can trust code and not humans to protect their assets. When humans are in the loop, there is necessarily a “judgment call zone”, which violates all aspects of DeFi, it also creates personal safety issues for individuals who are known to process liquidations with no plausible deniability.
• Reduce Liability concern - from the DeFi protocol creator’s perspective, being an external third party that has to process liquidations off chain (rather than creating a keeper network of liquidators) introduces liability and regulatory concern to the protocol, making it harder to operate in certain jurisdictions
• Better Incentive design - by designing their own rulesets for liquidations, application developers can incentivize keepers to protect their protocol in a decentralized manner

Proposed Change

Add the following exported methods:

• TerminateSectors
• GetAvailableBalance
• GetLockedReward
• GetLockedInitialPledge
• GetExpectedRewards

more details in the upcoming FIP Draft.

Open question

Is it possible to get a single maximum termination penalty given a list of the miner actors IDs that are provided?

[jennijuju]

First attempt on fip draft #1035

[Schwartz10]

Thanks for posting @jennijuju ! Allowing programmatic terminations will be quite useful for defi protocols.

I do want to express my strong opinion that the usefulness of this FIP is dependent on finding a solution to the "open question" listed at the bottom of this discussion. I created a new discussion to focus on that here.

There are several reasons for this:

• having the ability to terminate sectors is useful, but knowing exactly when to terminate sectors (and for how much) is the harder part - without understanding the collateral value (aka "liquidation value") of a miner, protocols won't have a good mechanism of triggering when terminations should/should not be allowed
• similar to the above, knowing when to stop terminating sectors is critical for underwriting good programmatic termination - especially when it comes to async termination queues as balances won't become immediately available for making basic balance checks before/after a liquidation
• getting available balance, locked rewards, locked initial pledge is nice, but without understanding termination penalties, its very difficult for a defi protocol to make good use of this information for any underwriting procedure

With this in mind, I'm still a very strong advocate in favor of exposing these methods through the FEVM precompile, as they will be critical in building fully decentralized lending/leasing/staking protocols on fevm. My main point is just in terms of prioritization - computing collateral values on chain (imo) is a precursor to making on-chain sector terminations useful

[sylvanzhang]

I fully agree with @Schwartz10 's comment on the importance of calculating termination fees on-chain. At Parasail, we calculate something called SafePledge, which is essentially the liquidation value for miners as Jon mentioned. Having a method where people can get accurate termination fees for miners will be hugely beneficial to miners, DeFi protocols, centralized lenders, investors, and almost everyone in the community.

[anorth]

TerminateSectors

The draft FIP proposes exposing the current TerminateSectors method.

/// Marks some sectors as terminated at the present epoch, earlier than their
/// scheduled termination, and adds these sectors to the early termination queue.
/// This method then processes up to AddressedSectorsMax sectors and
/// AddressedPartitionsMax partitions from the early termination queue,
/// terminating deals, paying fines, and returning pledge collateral. While
/// sectors remain in this queue:

I'm fine with exposing some sector termination, but the existing method is not good. Not only should we not expose it, but we should deprecate it. Rather than just terminating the sectors, the existing method does a complicated deferral and partial processing of the requested work. It also schedules a cron job to do more of the work, thereby punting the execution cost of large jobs onto the network as a whole. I think this was motivated by not having a proper gas model before the development of the FVM, and the potentially expensive work of terminating an unknown number of deals etc. But none of that is relevant to explicit termination by an SP operator/owner. The caller should specify a set of sectors that can be terminated well within the block gas limit, and the method should just do the work.

For the proposed use case of automated invocation from smart contracts, the existing method will be very hard to use. A simpler one will be much more appropriate.

We should specify a new TerminateSectors2 method that does directly what it is asked to do.

(Note: the termination queue might remain for use when automatically terminating sectors due to missed Window PoST, where unbounded work would still be a problem.)

[anorth]

Note #972 also hints toward a possible change in termination mechanism (for CC sectors) that we might consider concurrently.

[jennijuju]

@anorth in #1035 - I proposed that the exported terminate sectors should immediately terminate sectors in the cron queue before the new sectors submitted. I think remove work from cron is a desired behaviour we would like in general and agree having a TerminateSectors2 that does the same behaviour is a good idea. I was less sure the introduction of TerminateSectors2 should be in the same fip - but happy to add it!

If we can reach the consensus/make progress of #972 it’d make sense to land these two fips tgt, but I prefer to not couple two FIPs, given #972 is a cryptoecon fip that may take longer to design and progress.

[anorth]

I was advocating for a new, simple TerminateSectors2 instead of exporting the current method. And then later deprecating the old one. If we export the existing TerminateSectors then we are locked into its signature and, to a significant extent, its semantics forever. I don't want to export TerminateSectors because it represents a significant amount of unnecessary complexity and I don't think we should commit to maintaining this technical debt forever.

proposed that the exported terminate sectors should immediately terminate sectors in the cron queue before the new sectors submitted

From the code comment I copied above, this is what the existing method already does. However, I can see a problem with only exporting a new TerminateSectors2 that ignores the queue. A miner might have sectors in the queue that were terminated not manually, but by cron. They can't withdraw until those terminates are processed, and that's why the TerminateSectors method processes the queue first. A contract or EOA may want to withdraw.

What we should do is stop using cron for this. But that's a big endeavour and it would be a shame to block the outcome of an exported termination method on that. So ... I guess we have to export something that can process the queue first, which is basically the existing method.

It's worth thinking forward to whether this locks in anything bad. The potential bad thing is when the specified sectors aren't terminated because there was too much either in the queue already, or in the message, so callers have to handle a "false" return value and make repeated calls (initiated from outside the chain).

• We must support partial progress, else the caller can't make any progress if the queue is large
• We want to avoid hard-coding any limits on number of sectors processed, preferring to leave it to whatever gas limits can support
• We want a caller to be able to avoid submitting a set of sectors and getting back a result indicating that they weren't all terminated, if the cron queue was full
• We want a simple way of invoking "terminate exactly these sectors" that will always work once the cron queue is deprecated in the future

The above is design rationale for a new method. It'll probably need a new signature, so it's not the existing method. It's a new method, designed for export, but it necessarily must process the queue while it still exists.

[anorth]

GetAvailableBalance, GetLockedReward, GetLockedInitialPledge

GetAvailableBalance is already exported.

GetLockedReward is already exported (as GetVestingFunds).

A miner's locked initial pledge can be calculated as TotalBalance - (AvailableBalance + LockedReward). I'm not opposed to exporting a GetInitialPledge, but it's absence isn't limiting anyone at the moment.

[anorth]

GetExpectedRewards

Expected rewards for some amount of power is not fundamentally a calculation specific to a miner, but is a general calculation for the network. A miner actor doesn't even know the one key input it would need for this: its power.

Instead, this should probably be a pair of new methods exported from the power actor:

• MinerQAPower(address) -> Power
• ExpectedRewardForPower(power, duration) -> TokenAmount (can be used to calculate for an arbitrary power, not just something a miner actually has right now)

And for symmetry with existing methods, add NetworkQAPower() -> Power too.

[Schwartz10]

@jennijuju want to export 1 more method to get live/faulty sectors of a specific miner, i didnt see this in the list of exported methods

[jennijuju]

What do we wanna know? The total amount? Or the status of a given sector? Or list of sector numbers accordingly?

[Schwartz10]

The same thing as StateMinerSectorCount, it returns:

type MinerSectors struct {
	// Live sectors that should be proven.
	Live uint64
	// Sectors actively contributing to power.
	Active uint64
	// Sectors with failed proofs.
	Faulty uint64
}

[jennijuju]

ack - will add!

[sylvanzhang]

Exposing more API of the builtin actors to smart contracts and enabling sector termination through smart contract will make DeFi protocols more trustless and decentralized. We are supportive of the FIP but would also want to see something like GetTerminationFee first.

[steven004]

I generally support this proposal to export more methods, as it will provide DAPPs with greater flexibility in managing processes, particularly for DeFi.

However, concerning the termination fee, I strongly support proposal #972 to mitigate lending risks. I also proposed #712 to simplify the termination fee calculation, which would further limit lending risk. Additionally, lower risk and capped losses introduce greater certainty into the system, enhancing its power and security.