Replies: 1 comment 4 replies
-
While I don't fully understand everything involved in the proposals here, I don't yet see any strong reason why a subnet coordinator actor should be a built-in actor in the main Filecoin chain.
For both implicit message application and a new built-in actor, I would expect that we (stewards of FIlecoin) would want to see a robust argument about why you can't achieve similar outcomes without adding complexity to Filecoin's consensus rules (which includes built-in actors), and if such argument was robust we'd put some real thought into what minimal facility we could add that would resolve whatever was blocking it (e.g. a new VM syscall). |
Beta Was this translation helpful? Give feedback.
4 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
In the MVP implementation of hierarchical consensus (HC), the SCA is a
builtin-actor
that implements the core logic of the protocol. One of the things the SCA is responsible for is the execution of cross-net messages. The reasons why we decided to make the SCA abuiltin-actor
(apart from the fact that when we started working on HC there was no FVM and we had to implement everything asspec-actors
over theLegacyVM
) is:f064
) like the rest of builtin-actors.After skimming through the protocol spec, @ZenGround0 (and others) have been wondering if we could make the SCA a user-defined actor (it can simplify many things). If we remove the need for 3. to execute cross-net messages (as proposed here), and we force for the SCA to be a singleton with a well-known and specific address we may be able to have SCA as a user-defined actor (although from my I don't know the best way to do this over the FVM for user-defined actors).
The goal of this discussion is to raise the various options and agree on the best way going forward. According to the outcome we may require an update to the spec and a significant update to the implementation.
Beta Was this translation helpful? Give feedback.
All reactions