Poll: Does the switch of CodeCIDs to _real_ content-addressing impact you?

[raulk]

Context

This discussion is in the context of FIP-0031 (the atomic activation of the FVM).

The Filecoin state tree is the top-level data structure containing all actors. The type of every actor is identified by a field CodeCID, which holds the CID of the executable code behind that actor.

Currently these CIDs are NOT what they're supposed to be: content-addressed identifiers to their respective code. The reason is that, up until now, actors have had no portable executable bytecode to hash over. Instead, they are synthetic/virtual values picked from an enumerated set. They effectively act as type indicator, which the VM uses to route the call to particular actor.

The synthetic CodeCIDs used in nv15 and actors v7 are:

• fil/7/system
• fil/7/init
• fil/7/cron
• fil/7/account
• fil/7/storagepower
• fil/7/storageminer
• fil/7/storagemarket
• fil/7/paymentchannel
• fil/7/multisig
• fil/7/reward
• fil/7/verifiedregistry

What's changing

With FIP-0031, the Wasm-based FVM will be atomically activated in the Filecoin network, and the built-in actors will start being backed by portable and executable bytecode.

As a result, it will be possible for CodeCIDs to become true content-addressed identifiers over the Wasm bytecode of actors. And we plan to do exactly that: to migrate from synthetic to content-addressed CIDs.

The impact

Real content-addressing results in arbitrary identifiers. Where before we'd used to have fil/7/account to identify an account actor, we now may end up having something like bafy2bzacede323nn3ijzykhl3zbp2xyuhzbjdo4gkcvwyntbgwislnmmaxxrc.

This can impact logic that exchanges, chain explorers, wallets, and other tooling such as Sentinel/Lily, statediff, etc. use to identify actor types. Places where the CodeCID is exposed to users include the following Lotus JSON-RPC operations: StateReadState, StateGetActor.

If users are performing full-value equality comparisons to identify actor types, this shouldn't be much of a problem. They would just change the expected value to a different value, just like they'd have to do with every network release where actors are versioned.

However, if users are relying on the deterministic structure of synthetic CodeCIDs, they would notice a larger change. Examples of potentially affected logic include: parsing the CodeCID, using regular expressions, partial string operations and comparisons (e.g. stripping the prefix, comparing the suffix), etc.

Poll

In order to determine what degree of backwards compatibility to implement, the FVM team would like to poll the Filecoin community. Please reply to this discussion and indicate if:

• A: You're OK with the change, because you're performing full value matches / comparisons, or none at all.
• B: This would break your logic, but you're OK adapting.
• C: This would break your logic, and you want to plead for some backwards compatibility path.
• D: This is irrelevant to you.

[anorth]

Thanks @raulk. You're clearly proposing the "right" way, which will eventually be the only way. So a backwards compatibility path would, I expect, only be a temporary measure before users must adopt the new way anyway.

(For me: A. The actors code just needs the builtin actors lookup table, and equality checks).

[steven004]

Agreed, eventually we will go with this change.
At the same time, in the implementation process, I would think to have backwards compatibility implementation before the gas model changing is good, thus the community can run FIP-0031 together with current network version (should be NV15 soon) to make sure the FVM and rust-actors functioning as expected on main net, and then, the next step is a 'must' step to have the final change with gas model together.
The gray test before the 'must' upgrading helps the quality control especially when the change is very big, and for the first time we adopt FVM and rust-actors in main net.

[jennijuju]

i personally vote for A based on my experience with exchanges and partner integration.

[frrist]

A works fine for Lily.

Will there still be a look-up for deriving human-readable names from the new actor codes? e.g. bafy2bzacede323nn3ijzykhl3zbp2xyuhzbjdo4gkcvwyntbgwislnmmaxxrc -> fil/7/account.
We can always maintain our own, but leaning on the FVM/actor code as a source of truth is generally preferred.

[exp0nge]

From an exchange prospective:

We have no use-case today of identifying what actor types we are interacting with because we only create and interact with a small subset of the ones that the network supports. Since we create the raw message and generate the actors ourselves, we don't re-check the version string.

The deterministic nature is irrelevant to us but it would be extremely helpful if you guys provided an RPC if you plan to change this CID for some reason (for every network upgrade, or some other reason). However, if it's being generated based on some parameters of the creation params or statically defined, we can re-write the spec/copy the static CID.

Aside from changing how we are currently enumerating our SDK, I don't see much dramatic impact.

A.

[raulk]

Thanks all for your responses! Based on the input gathered, it is safe to say that no action needs to be taken to preserve backwards compatibility with the deprecated synthetic nomenclature of Code CIDs.