Notary collateral staking and incentives with FVM

[panges2]

Note: In this discussion, we will refer to smart contracts as "actors" as it is the terminology used within the FVM ecosystem.

Context 💡

As the notary community continues to grow and concerns about fraud increase, it is important to find ways to hold notaries accountable, encourage good behavior, and discourage bad behavior. One promising solution is to leverage the capabilities of the FVM ecosystem to enable notaries to stake collateral. This idea is becoming increasingly viable thanks to the advent of FVM actors.

The aim is to incentivize notaries to perform thorough due-diligence and refrain from fraudulent behavior by requiring them to stake collateral. The process would be as follows:

• A client applies for an LDN application.
• A notary conducts proper due-diligence on the client and vouches for the client by sending a specific amount of FIL (x) to the notary incentive actor.
  • If the client is not fraudulent, the notary will receive a reward (y) in FIL.
  • If the client is fraudulent, a portion (z) of the notary's collateral will be slashed.
• The notary can retrieve their collateral once all tranches of datacap have been sent to the client.

By staking collateral, notaries are motivated to conduct thorough due-diligence and avoid fraudulent behavior, as they risk losing a portion of their FIL if they deviate from this process. Additionally, notaries may be incentivized to provide a higher quality of service as they will be rewarded with FIL for vouching for legitimate clients.

Next steps 🥩

Currently, Fabri from the Keyko team is creating a prototype actor for the Spacewarp hackathon that will allow notaries to stake collateral to vouch for certain LDN applications. The actor will have the following state and functions:

1. Store a list of notary addresses and the amount they each staked.
2. Store a list of notaries and the amount rewarded to those notaries.
3. Store the address of the admins.
4. A function to stake collateral. Parameters will include the address of the notary staking, the amount staked, and the LDN application that it is staking.
5. A function to retrieve rewards that have been granted to an address. The rewards should be calculated based on current time, time collateral staked, and amount staked.
6. A function to slash collateral of a certain notary. In the future, when we have oracle services feeding data to the actor, we could make slashing of collateral part of the "crank" function.
7. A function to add funds for the reward pool.

Please note that the state and functions outlined above are preliminary specifications and may be subject to change as the development process continues and feasibility is further evaluated. Technical details regarding the structure may also be altered as necessary.

This prototype will be initially tested with small amounts of FIL and already approved LDNs, using existing 4th round notaries. Participation in this prototype will be optional for notaries and will be in addition to the existing LDN application process. The prototype aims to provide a secure and reliable mechanism for notaries to endorse LDN applications and to be rewarded for their participation.

details to be discussed❓

The idea of utilizing FVM to promote accountability among notaries is an exciting prospect, but it requires careful consideration of several practical details in order to be successfully implemented. The following are the details to be discussed and possible ways to implement them.

How do we decide when to slash a notary's collateral?

Determining when to slash a notary's collateral is a crucial and complex aspect of this project. To effectively implement slashing functionality, it is essential to establish clear and appropriate requirements for notary behavior.

One approach to implementing these requirements is to distinguish between two types: hard and soft requirements.

Hard requirements are technical requirements that are clearly defined and can be objectively measured. Examples of these include:

• Ensuring clients store copies in at least six different storage providers in an evenly distributed manner
• Conducting random retrieval checks on clients and reporting the results. This could be supplemented by other parties also doing retrieval checks on clients.
• Not approving clients that are sharing CIDs (Content Identifiers)
• Meeting engagement SLA governance standards

Soft requirements are more subjective and on trust and transparency within the community. Examples of these include:

• Finding fraud through investigations by the trust and transparency working group
• Discovering evidence of notary collusion or fraud through community feedback

Both types of requirements have their advantages and disadvantages. Hard requirements allow for a more scalable and objective system of accountability, but if not carefully implemented, they may result in false positives or false negatives. Good notaries may be penalized for not being careful, while malicious notaries can find ways to manipulate. Soft requirements can be useful in catching edge cases but are susceptible to bias and subjectivity. A balance between the two types of requirements must be struck in order to ensure the proper functioning of the incentive mechanism.

Where does the FIL reward come from?

The reward for notaries can be provided through various means, each with its own advantages and disadvantages.

• One method is to provide a reward from the Filecoin Foundation through grants and other means. This would provide notaries with a significant amount of FIL, which would motivate them to perform their work. However, this method would also add extra FIL into the circulating supply, which could have unintended consequences and could potentially motivate notary client collusion.
• Another method is to pool FIL from client fees. This method is in synergy with the idea of charging clients for their applications through a standard fee or priority fee. The main purpose of the fee would be to reduce the number of low-quality applications, but the fees collected could also be used to reward good notaries.
• A third method is to provide a reward from previously slashed notary collateral. This would motivate notaries to hold each other accountable. However, depending on the size of the collateral and the number of fraudulent notaries, the size of the reward could be small. Additionally, notaries should not be rewarded only as a result of another notary being punished, as this could create an adversarial community.

How much FIL should be staked (x)?

• One potential method for determining the amount of FIL to be staked by notaries is to make it proportional to the amount of datacap being requested by the client in the LDN application. This approach aligns the interests of the notary and the client, as the notary is motivated to ensure the client receives the necessary datacap.
• To ensure an economically correct amount, the amount of FIL staked should outweigh the potential profit from the datacap received by the client, taking into account fluctuating prices of FIL and datacap. However, this approach could present challenges such as requiring a large amount of FIL to stake, which could disincentivize smaller notaries from participating in LDN applications due to the current low liquidity environment.
• A more practical approach may involve staking a feasible amount of FIL that is large enough to disincentivize fraudulent behavior while still allowing smaller notaries to participate in the process. This approach would need to be carefully balanced to ensure that it effectively discourages fraudulent behavior without unduly burdening legitimate notaries.

How much FIL should be rewarded (y)?

• This amount should be proportional to the amount of datacap being issued to the client in that given week.
• This amount should be enough to compensate for the notary's time doing due diligence that week.
• Depending on where the FIL comes from, the amount should be low enough to be practical, as in this low-liquidity environment, it is difficult to gain large amounts of FIL.
• The reward could be compounding, but this would increase the amount of FIL needed, again raising the concerns of low FIL liquidity.

How much FIL should be slashed (z) if fraud is found?

• The simplest option is to impose a penalty on notaries participating in the actor by slashing all their collateral. However, this approach may discourage notaries from participating due to the high level of risk involved.
• A less severe approach is to proportionally reduce the collateral based on the amount of Datacap issued to the fraudulent client. For example, if the client received 40% of their requested Datacap in the LDN, then 40% of the notaries' collateral would be slashed.
• A more economically precise amount should outweigh the amount that can be gained by the already issued datacap. However, it is important to note that this approach assumes that notaries are staking collateral that exceeds this amount. In a low liquidity environment, this may not be feasible.

Engineering pitfalls ⚠️

• Improper implementation of the actor could result in high gas costs, which would increase the demand on the FVM and slow down transactions overall. To mitigate this, one solution could be to move the actor to a Layer 2 solution/ an app-specific chain. However, this would increase the engineering cost as there is currently no standardized way to implement this within the Filecoin ecosystem.
• Security is a crucial aspect to consider when implementing the actor as the actor will be responsible for holding Notaries' FIL stake. A security breach could result in the loss of user funds, and therefore it is important to ensure that the actor is as secure as possible.

Related posts

#581

[NSC-FIL]

I think this proposal is on the right path. Incentives and penalties should be instituted to improve notary diligence in the allocation of datacap. IMO, this suggestion is worth exploring:
"Another method is to pool Fil from client fees. This method is in synergy with the idea of charging clients for their applications through a standard fee or priority fee. The main purpose of the fee would be to reduce the number of low-quality applications, but the fees collected could also be used to reward good notaries."
Any methodology to incentivize "good and fair" behavior by awarding FIL should have a net neutral or deflationary effect on the overall circulating supply of FIL. Mechanisms to govern this or any verified deal initiative should NOT add extra FIL into the circulating supply IMO.
Also I agree with gradually phasing in penalties and periodically assessing the effectiveness when executed in actual cases of fraud. So start with the option of "A less severe approach is to proportionally reduce the collateral based on the amount of Datacap issued to the fraudulent client. For example, if the client received 40% of their requested Datacap in the LDN, then 40% of the notaries' collateral would be slashed."

[NSC-FIL]

And it might be prudent to discuss how DataDao's might become a platform for electing notaries and/or financing their collateral. Parallel development might enhance the overall governance of our Filecoin ecosystem.

[panges2]

I understand your concern about how it would be difficult for notaries to obtain Fil to stake, especially in this low liquidity environment. But I'm not sure if building a system to finance notaries would be the way to go, as that undermines the purpose of staking:

• If the Fil being staked is borrowed from somewhere/granted to them, it would matter less.
• If it is granted to notaries, then comes the problem of inflationary pressure.

Instead, I think we should pursue the following:

• lower the stake amount to a meaningful yet practical amount
• Make the program opt-in (meaning they don't have to stake if they don't want to)
• add rewards/ other benefits if you stake
  • @raghavrmadya This may be relevant to your point about how you could stake FIL to have a bigger voice during trust and transparency disputes

[fabriziogianni7]

Hey Guys!
I'm trying to build this protocol in the context of the space warp hackathon
I'll post here the MVP video and link so you can play around..

The MVP will be far more simple and a lot of mechanisms will not be there. Then, depending on how the hackathon goes and how people respond to it I can keep working on it following the community feedback!

This is what I'm doing:

1. Notaries do due diligence and present clients to the protocol, staking some FIL as a deposit
2. Once the client is accepted in the protocol, The client can ask for more datacap allocations, making a call to a Smart Notary Actor.
3. The Smart Notary Actor, checks a rule module and if the client is following those rules, then it allocate new datacap
   3a. The client pay a fee everytime he asks for datacap and it is distributed among the notaries and 5% of it goes to the protocol
   3b. The rule module is a smart contract that is defined by the community
4. if the client is not following the rules, he cannot get more datacap and thus, the notaries won't be able to earn their fees

so this is my very, very basic idea of how should be - that is for the hackathon.
many things can be improved and added, and for sure we need to find a way to get a lot of data about the clients on chain through some oracle, for instance.

any feedback is very welcomed!

[flyworker]

Let me try to mock a notary name Kary as a bad notary who wants to participate in the game.

Kary wants:

• Get rewards when he did something right
• Avoid loss when Slash happens

For the Get rewards when he did something right it is easy just get the reward and go.
for Avoid loss when Slash happens

• get the staking from someone who wants him to sign (briber)
• after being elected he received a bribe for each sign
• if a slash occurs, he can either ask the briber to pay or use his bribe fund from the briber.

[fabriziogianni7]

I would say that the rules should be kind of strict. then if the client is not compliant, the stake would be unretrievable and no rewards would be earned.
and then the governance team should be in charge of accepting good notaries in the protocol.
anyway yes, every law has a loophole but our goal is to make life hard to whom is trying to cheat while ease the life to whom is willing to contribute to filecoin and bring new clients

[panges2]

@flyworker one way to get around what you said is have the rewards just a be a pool of Fil from client application Fees. I mentioned in the post here

Another method is to pool Fil from client fees. This method is in synergy with the idea of charging clients for their applications through a standard fee or priority fee. The main purpose of the fee would be to reduce the number of low-quality applications, but the fees collected could also be used to reward good notaries.

This way if the client and notary collude it's fine because were not adding new rewards into the system. They will just be moving Fil back and forth between them.

Even if the notary and client was the same person, what comes out of this is:

• Kary does not get a reward
• gets the application signed
• but has a stake that can be slashed

no way of abusing rewards and Kary is incentivized actually to sign other clients' applications. Then in this case the problem could be that the reward is not enough for anyone to risk staking. In this case we can explore having a hybrid where part of the rewards comes from clients and a small part is from grants.

[Fatman13]

Interesting discussion. 🥩 Maybe we could involve folks from CryptoEconLabs to have a look at the potential incentive structure too?

[DaYouGroup]

I think that only solves part of the problem. From the perspective of the rules, it seems that the problem of dc abuse can be reduced by affecting the notary's direct interest (the pledge). However, I think of some potential problems:

1. Since a notary needs to guarantee the LDN, the notary will tend to refuse to sign any unfamiliar LDN.
2. Notaries, SP and LDN applicants will be united or even the same entity. In this way the potential risk of punishment is reduced.
3. The potential risks arising from the guarantee will be reflected in a certain pricing method. I mean it would make DC selling more common because they would reduce their risk by collecting money.
4. The threshold of unfamiliar LDN applicants is greatly raised, and the notary may transfer the risk by letting the applicants provide collateral.

It could end up being a super node like eos, with notary public directly or indirectly controlling a large number of DC, creating a monopolistic class of notary public, with no newcomers to join, and eventually a backwater. We as notary public also have a vested interest in this proposal, but I don't want to see fil go stale. Maybe we can think about how to deal with credit and abuse while keeping "freedom"

[Aaron01230]

In the current situation where there is no pledge, it is generally difficult for LDN applicants to obtain the signature of the notary, and i think this situation will be exacerbated if the pledge is implemented, so I support your opinion.

[panges2]

@DaYouGroup

1. I agree with this issue that this would cause notaries not to sign unfamiliar LFN applicants. But as @Aaron01230 says, this is already the case, so I doubt that it would make the situation much worse. Instead, we should implement other mechanisms, such as assigning notaries to random applications and incentivizing them to sign them or comment on them to say why they would not want to sign. Similar to what is happening in E-FIL+
2. I disagree with this; I don't think adding the staking mechanism would make them any more united.
3. I don't understand the point here.
4. I don't see why this is a problem. If no notary is willing to stake for the client (assuming that the stake amount is just right), it should be a sign that the client is not worthy of DC. If the notary wants to pass the risk to the client, that's fine, the client will have to pay the price if they are not legitimate.

[Joss-Hua]

As long as the rules are clear, there will be means of catering or avoiding in the community, so my view is to try not to add rules. But I would like to support this issue because I see here that the possibility of multi-stakeholder confrontation is gradually decreasing.

No matter which of the above options is implemented, as long as the governance team, notaries and SPs can accept the results when the above bad situation that everyone is worried about occurs, it is worthwhile to start a small-scale experiment.

[DaYouGroup]

I advocate decentralization of power, another group of people to check dc, notary only give kyc and signature power. They can monitor and control each other, and the checker can be a group of community members or a robot, but not a notary.

[DaYouGroup]

Each round of signature needs to be passed by the inspector, the notary can sign

[stcloudlisa]

I agree your thoughts.

The notary submits the signed application, and the inspector can choose whether to approve it.

The inspector must be an official, For example @panges2 @raghavrmadya @Kevin-FF-USA

[panges2]

If all the inspection is done by the gov team or bots, there will be no point in having notaries. Instead, we want to provide tools for notaries to make it easy to do inspections. We also want to incentivize them to do their work properly.

For now, however, this is not the case, so much of the inspection is still done by the gov team.

[panges2]

Greetings all! I am thrilled to share with you the latest update on our Notary Staking MVP 🚀 We are eager to showcase the hard work and dedication put forth by @fabriziogianni7. He will be presenting tomorrow for the Space Warp Hackathon and has created an MVP demo, which you can view here: https://www.youtube.com/watch?v=CYYsoPYDCes.

Please keep in mind that this is just the beginning, and we welcome any constructive feedback and suggestions to help improve and refine the project. Thank you! 🙏

[Fatman13]

Depend on the reward / slash mechanism, staking may be deterring notaries to sign which in turn reducing the amount of DC a new comer or smaller storage client will get. If the slash is too severe, one likely outcome will be notaries only signing SCs that they are acquainted with and not risking its stake with other applications.

[1ane-1]

Interesting idea！Continue to follow it. Hope it can really do something to LDN.

[stcloudlisa]

Just like E-FIL, this project needs to be test in the early stage. I am happy to see that V4 is already test. I hope that the data of the test can be released in time, the amount of pledge, when the pledge will be returned, how to punish mistakes by customers or SPs, and How to reward.

[TimGuo7]

Agreed with what @Fatman13 and @DaYouGroup mentioned above. Notaries may intentionally avoid signing for the requests that they are not familiar with to prevent potential penalties.
Anyway, that's a great start.

[panges2]

I agree, and I responded to DaYou's point above that we need some other mechanism in place to prevent this.

[caoyoungyoung]

@Fatman13 I think he has a point, that in some degree may harm the growth of the entire ecosystem. Notaries maybe reluctant to sign dataCap for potential risk. Plus, the staking amount is a key factor.

[sxxfuture-official]

How to avoid notaries signing requests they are not familiar with is an issue to consider.

[NewHuoPool]

This will result in notaries refusing to sign unfamiliar LDNs.
Will it lead to the client giving some bribe to the notary when requesting the notary's signature?
And the client as a data provider is without fil, which will end up as pledge coming from the SPs.

[mjroddy]

Whilst having some incentive mechanism for Notaries makes sense, I'm concerned here with the idea of requiring the Notary to stake and for that stake to be proportional to the DC's. how would this be proportionally fair?

is it larger for bigger applications? are smaller staking notaries not able to sign larger applications?