FVM — About FIL-Peggy being ETHGlobal Hack FEVM finalist and using Actor as Owner
When I first learned about FVM, I applied for FVM Foundry F/1 with the simple pragmatism of wondering to host all the management of Miner to the contract (that’s to say, use a smart contract as Miner’s Owner), in which I read Jim Pick’s article and with help from a series of core developers, community experts, gradually understand what FVM can and cannot do, and do a series of functionality validation. But these validation are all based on the pragmatic direction of wanting to implement contract to manage Miner. The details have been described in detail in the previous articles, and won’t be repeated. Later, when we verified, we deepened our understanding of FVM, and we became clearer about what we wanted, which led to the formation of the FIL-Peggy project.
About FIL-Peggy itself, we will describe it in detail in the following paragraphs. Let me first talk about the Hack FEVM in ETHGlobal that I participated in this time by accident. The purpose of my participation this time is mainly to gain experience since the products we are developing now will participate in various Hackathons in the future, so it is essential to be familiar with the complete process. People who don’t know the truth will think I’m showing off but that’s what I really thought when I first participated in this Hackathon because it was my first time participating in such an event. From the time we started to verify the FVM function, to the time when we formed the R&D direction and planning of FIL-Peggy, it was actually very close to the start of Hack FEVM, and we have been verifying the function and design but did not start Coding. When I signed up, I saw that the time was only two days on weekends. I think there are always many firsts in life, so I would try to gain experience first. But to be honest, the organizer stated that the old project could not be used (I don’t have any old projects!), only the projects started from scratch in the past two days. I can’t even imagine I am going to make FIL-Peggy an MVP in two days. In addition, from the name, I think Hack FEVM is more concerned with the application at the FEVM level, and we are doing things based on the capabilities of FVM (of course, there may be FEVM implementation in the future, but now we can only focus on doing one thing), and then Combined with the level of what we have achieved now, I really think that we are participating in this competition now, and it is definitely a pragmatic attitude to get experience.
But the results were pleasantly surprising. The judges are Sarah and Zak, Sarah is the spokesperson of the FVM community, and Zak is the core developer of FVM. They are all very nice people. I once described the FIL-Peggy scene with Sarah on slack, and Sarah replied “sounds like a good use case”. During the review, I don’t fully get what Zak mean by his question many times, and Zak was always very patient to re-explain. For Sarah’s “client interacts with users”, I didn’t get her meaning since I didn’t think in that direction at the moment, she also wrote it in the chat for me to answer. In general, the entire review process was not silky due to my poor English, but it gives me a very comfortable feeling. What’s more? When Sarah mentioned FIL-Peggy on Twitter, she used Chinese exclusively. I couldn’t be more grateful. So from that moment on Filecoin & FVM, no matter how hacked by others, I must have been a fan all my life.
Although the process is comfortable, I still don’t think I have the slightest chance to be selected. After all, in two days, I haven’t even built the most basic project structure. I just wrote the basic peggy-cli at the very first beginning and completed the offline wallet generation. And the initial code for creating the miner, the reason why it is said to be the initial code is that the miner creation still did not return correctly, and I have not had time to solve it. During the waiting process, I also received an email from the organizer to participate in the Finale, but I think it should be received by all participants, so I did not prepare anything until I was told on discord and asked if I could do a 15-minute demo, I was stunned for a while. I even asked the organizer, “Can I use that kind of demo as the final demo when I was judging?” After the stumbling demo was completed, I saw a message from Juan Benet (I can’t be sure it was him, and Sarah told be that’s him! Amazing!) that said “Very cool! FIL Peggy is solving a lot of hard problems — keep it up.” I can feel a lot of encouragement and support whether this and Sarah’s previous comment “good use case” was genuinely approving or has some politeness since a person groping forward in the dark often find surprises, he is somewhat helpless and in pain. As far as I am concerned, FIL-Peggy is just trying to solve our own problems. If it can help others and also help improve the ecosystem and functions of FVM, it will be perfect. I can’t make something huge, but it’s good to be small, beautiful, and useful.
What is FIL-Peggy? We can describe FIL-Peggy as a set of tools for managing miners. The original miners all need private keys to manage. No matter multi-signature or not, there always has a problem of key loss. For miners who need to cooperate with investors, as long as the relationship of mutual trust between people is unequal, it is difficult to be truly restrained, and it can only rely on the offline trust relationship. FIL-Peggy hopes to host all the miners’ management logic to the contract through the tools on the host and the on-chain contract so that the logic is transparent, the power can be audited, and the multiple parties no longer need to rely on who holds the private key.
For the verification of FVM capabilities in the implementation process, we already know in the previous chapter that actors are incapable of creating their own miners, so is there any way we can host miners in Actors? In practice, we verified that the power actor cannot support the creation of miners from user-defined actors, because the caller is checked to be the account, but we can change the owner to the user-defined actor address after creating the miner, and then set the worker and control addresses through the actor. However, in the process of setting up the worker, the power actor will still check whether the worker is the account (I don’t know whether this restriction will be resolved in the future), so the worker can still only be the account. If this restriction cannot be resolved in the future, it will reduce the transparency of the contract to a certain extent and fairness. But we can still prevent the risk of collateral damage in the contract by limiting the amount transferred into the package every day in the contract and providing a way to lock the operation through governance means.
FVM will realize the upgrade of the contract in the future, so is it possible to leave a loophole in the contract, upgrade it temporarily, and embezzle assets? From the current FVM and state store capability support, we can implement voting governance on the chain. When an upgrade operation needs to be initiated, the upgrade requester needs to deploy the new contract first, request the old contract to upgrade to the new contract ID, and wait for the contract participants’ vote. The pass threshold was set in the old contract. The contract will be upgraded only after the vote is passed. In this way, the risk of assets being embezzled by a certain party is eliminated, and the trust problem in the process of off-chain cooperation is solved in a fair way on the chain. People can’t always be trusted, but code can be trusted, which is the most important spirit of decentralization (I didn’t fully understand this spirit until the concept and design of FIL-Peggy took shape).
Finally, our special thanks to Sarah Thiam@truckerfling, Hack FEVM organizer ETHGlobal, and other friends who helped us during our FIL-Peggy process, congratulations to all participants, submitters, winners, and those who left FIL-Peggy relevant information. We don’t have a community yet, and we’re not going to build a community until FIL-Peggy is complete and practical.
