You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jun 6, 2023. It is now read-only.
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 for singletons.go.
Pros:
These addresses will probably need to occupy the 100 reserved actor ids reserved for singletons (before FirstNonSingletonActorId). Explicitly reserving them in singletons.go will help avoid future confusion.
Specifying these addresses will ensure consistency across test networks.
Cons:
Unlike other addresses in singletons.go, the actor code will not reference these directly. They will continue to use the addresses configured within the verified registry actor.
Since the addresses are configured, there presence in 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.
The text was updated successfully, but these errors were encountered:
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.
anorth
added
the
P2
Medium priority, beneficial for network functionality and growth
label
Aug 25, 2020
ZenGround0
added
P3
Not urgent or important
and removed
P2
Medium priority, beneficial for network functionality and growth
labels
Apr 7, 2021
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.The text was updated successfully, but these errors were encountered: