Open acruikshank opened 4 years ago
I concur these should be singletons. By specifying these addresses in singletons.go
, we increase the likelihood that the software generating the genesis block will in fact use the addresses we record there.
I'm happy enough to bake in the somewhat arbitrary addresses that have been used in testnets to date.
Problem
The verified registry must be initialized root account to authorizes verifiers. Since verified registry is a singleton required by market actor, it must be constructed early in genesis meaning at the very least the root's address must be defined even earlier. In mainnet, the root will be a multisig actor requiring a ceremony to initialize, but it's possible to use a standard account actor for the root in other networks. The verified registry currently has no way to alter the root address. That the root is a singular dependency of a singleton, suggests it is itself a singleton and it's address should be defined in
singletons.go
. The need to verify pre-sealed data in genesis also requires a single verifier account be registered in genesis, so this is another candidate forsingletons.go
.Pros:
FirstNonSingletonActorId
). Explicitly reserving them insingletons.go
will help avoid future confusion.Cons:
singletons.go
, the actor code will not reference these directly. They will continue to use the addresses configured within the verified registry actor.singletons.go
will be, at most, a suggestion. The addresses of record will be determined by the software generating the genesis block and the network will remain consistent no matter the choice.Alternatives: Require genesis block builders to use standard
init.Actor.Exec
to produce these accounts. This will result in standard id addresses outside the singleton range.