Our previous implementation of SubnetID had two main issues:
As we used strings to internal represent the parent of a subnet, it was dependent of the network type prefix t/f which meant that setting a different network type in Lotus and the actors led to really annoying panics/errors.
We didn't have a way to discern among different IPC trees. For this, instead of using root to identify the root of an IPC hierarchy, we use the ChainID to "uniquely" identify different IPC trees.
Finally, we've decided that instead of supporting Ethereum addressed for subnet actors, these will be included in the path of a SubnetID through their corresponding f4 address (thus supporting any future alternative addressing that comes to the network).
Addresses https://github.com/consensus-shipyard/ipc-actors/issues/78
Our previous implementation of
SubnetIDhad two main issues:t/fwhich meant that setting a different network type in Lotus and the actors led to really annoying panics/errors.rootto identify the root of an IPC hierarchy, we use theChainIDto "uniquely" identify different IPC trees.Finally, we've decided that instead of supporting Ethereum addressed for subnet actors, these will be included in the path of a
SubnetIDthrough their correspondingf4address (thus supporting any future alternative addressing that comes to the network).Next