Lending Protocol Liquidation

[leotons]

This is a proposal to add termination sector on FEVM

Motivation

Building Filecoin nodes requires a large amount of pledging, which has become one of the bottlenecks in the growth of the Filecoin network, and the FIL lending market has been created to a certain extent. The built nodes themselves have a lot of value, including pledged FILs, future rewards, and linear vesting, making them ideal collateral.

With the upcoming launch of the FVM, which opens up the space for a collateralized lending market, we now have the opportunity to use smart contracts and market-based mechanisms to complete the performance process in a secure and trustworthy manner, with investors contributing liquidity and node-owning builders gaining momentum for continued growth.

Proposal

Pledged coins are very high quality assets that can be pledged to get FIL to create more nodes. This will not only promote the development of Filecoin, but also increase the liquidity of Fil.
However, during the pledging process, if SP cannot maintain the nodes well, it is possible to deduct the pledged coins, and in extreme cases, all the pledged coins will be deducted, so before deducting all the pledged coins, the sector needs to be terminated.
Terminating the sector, on the one hand, can urge SP to maintain the node better, and on the other hand, can stop the loss in time to avoid the loss of the lending agreement

[anorth]

I think this is asking for a similar thing to that discussed in #334. I understand the desire, although it's a bit complex to work out the right policies at a network level. I continue to think that this is a subset of a general idea of access control lists (ACLs) for miner actor operations.

The question then becomes (1) should we implement ACLs in the built-in actor code directly, or (2) can we provide just enough public API for ACLs (and similar business logic) to be implemented in a user-programmed actor outside of the built-ins, as a kind of miner owner delegate. This second option is preferable for keeping the built-in actors simple, and enabling maximum innovation rate. The exported API #401 is not yet sufficient, but I think we should aim that way.

[leotons]

@anorth

In view of the two implementation methods, I think each has its advantages and disadvantages:
The first provides access control to user-defined Actors in a built-in contract, with the goal of ensuring that only authorized users can perform Actor operations. This approach requires determining which users are authorized to perform which operations and writing the logic to respond for each operation. When there is an operation is requested, the Actor will check whether the user has permission to perform the operation, and if not, the Actor will reject the request and return an error code.
However, the implementation of ACL logic needs to consider the balance between security and flexibility. On the one hand,it is necessary to ensure that the ACL is generic and flexible enough to meet the needs of different users. On the other hand, it is necessary to ensure that ACLs are secure and effective enough to prevent unauthorized users from performing dangerous operations.

Another challenge in implementing ACLs is how to manage ACL rule updates. For example, ACL rules need to be added, deleted or modified, and there is a need to ensure that these changes are security and do not compromise the integrity of the system. Therefore, when implementing ACL logic, a reasonable mechanism needs to be designed to manage the changes of ACL rules.

In the second way, a proxy Actor is added and access control lists (ACLs) and other business logic are implemented in this Actor. The proxy Actor will have access to the built-in Actor and can control the access rights of other Actors and miners.

It is important to note that this approach requires that the proxy Actor itself is trusted, as it has a decisive influence on the other Actors' access control. Therefore the security and reliability of the proxy Actor must be ensured. Also, since the proxy Actor is user-written, the flexibility and generality of the ACL logic needs to be considered.

The advantage of this approach is that the ACL logic can be written and managed freely, thus enabling more flexible access control policies, and it also makes the system more modular and keeps the simplicity of the built-in Actors. However, this approach requires more technical and time investment, so it may take longer to implement.

I think at this stage, if we can make the debit and credit association faster to be put into use, probably the first way: implementing in the built-in contract may be more ideal, which lowers the threshold for users.

[anorth]

You did a good job outlining the complexity and range of considerations necessary to implement ACLs. Which is exactly why I think we should do it outside the built-in actors. It will not be faster to implement internally, and a built-in implementation also has to await network governance (months), as would any subsequent change to it. I disagree that the external approach would require more technical and time investment. Further, the external approach can be done by anyone, including someone who just wants it for their own miner, while the built-in approach realistically requires the time of a small-handful of high-demand experts. I fear that if we put it on their backlog, it will never make it to the top.

[leotons]

@anorth
According to what you said, I agree that it may be faster to advance through the second way. But I have some questions:

• By advancing in this way, I can't accurately determine the development boundary and advancement of the built-in Actor and the proxy Actor, because the proxy Actor needs to interact with and depend on the built-in contract, so if the proxy Actor is developed, does the built-in contract need to be changed? If so, how big is the workload? Will this change be officially prioritized?
• The second question is: Is the proxy Actor implemented through Rust and must it be implemented in lotus? Can it be implemented through Solidity? Can you provide a little bit about how the proxy Actor is implemented and deployed?

[anorth]

I can't accurately determine the development boundary and advancement of the built-in Actor and the proxy Actor, because the proxy Actor needs to interact with and depend on the built-in contract, so if the proxy Actor is developed, does the built-in contract need to be changed? If so, how big is the workload? Will this change be officially prioritized?

Right, the exported APIs of the built-in actors are very high stakes because on-chain deployed code will depend on it, and can't generally be updated by us. We are thus quite conservative about what to export, see #401.

Yes the built-in miner actor will need some changes, at least to export the various maintenance methods (like termination) to be called by user-programmed actors. They're not exported yet because we expect the syntax and semantics of those methods to change. You'll just have to wait for that, because it was deemed more valuable to let smart contract authors be able to do some things sooner, rather than wait until we could let them do all the things at a (much later) FVM launch.

I expect that work to safely export methods to be called by user-programmed actors will be much more enthusiastically prioritized than work to add new features into the built-ins themselves. But in some cases (including sector termination), there's some actual work to be done before we can export.

Is the proxy Actor implemented through Rust and must it be implemented in lotus? Can it be implemented through Solidity?

There is no fundamental reason why such a proxy can't be written in Solidity and run on the FEVM.

[leotons]

I agree with what you said.
Can you tell me what needs to be done if I want to drive or participate in the development of clearing sectors and ACL rules? We have various technology stacks of Rust, solidity and our own node O&M team, we would like to get involved and speed up this thing

[anorth]

Great to hear, I have responded in Slack.