Closed Stebalien closed 1 year ago
I've talked about this a bit with @frrist and @ZenGround0: Sentinel (and chain explorers generally) is another party that reads chain state. I basically think we should do both.
I agree with your assessment here, @anorth. However, I'd expand the scope beyond state access (architecturally equivalent to DAOs for old dogs like me), to cover also method inputs and outputs (architecturally equivalent to DTOs).
There is a whole set of transaction submitters (e.g. wallets, miner management applications, deal-making apps, DataCap/notary management apps, etc.) for whom having parameter and return objects available in their languages to serde to/from is important.
@rllola has been doing some early prototyping, and is feeling the pain of rust serde.
@Stebalien I'm not sure there's any action to take here. The go-state-types repo is where the Go solution goes. Rust users can import this repo (though we should incrementally add better state access functions). Shall we close this?
Yeah. I don't think we're really getting anything from this issue at the moment.
Since we are not releasing the actors themselves, just the bundle, Forest no longer has access to the latest state and DTO objects, so this becomes relevant and necessary again @lemmih
Rust users can import this repo
This won't cut it as we have multiple versions of built-in actor states going forward #835. So in that case I think we should replicate the go-state-types pattern here, copy (not move) the state and param/response definitions out to a new rust repo, and maintain multiple versions in different crates in that repo.
Summary of the discussion in #835:
builtin-actors
repository only exists to create WASM bundles and should not be directly used by anyone.My comments:
As a side note, for me, this discussion is similar to our discussion about semantic versioning. I assured you that violating semantic versioning would cause trouble (which it did) and now again I'm assuring you that copy&pasting the actor logic will cause trouble. Probably not for Lotus but for everyone else in the ecosystem. We managed to get on the same page with respect to semantic versioning so hopefully we'll end up on the same page regarding having a single source of truth.
This summary is my understanding of a discussion that borders on the philosophical. Any misrepresentation is accidental and I genuinely want to understand the full picture.
Thanks @lemmih.
Duplicating the business logic of the actors is unwise
The example of miner_nominal_power_meets_consensus_minimum
is actually just about to be exported as an actor method. I don't know if it's going to be reasonable for you to invoke the VM where you need this value, but duplication at this point will be an optimisation rather than necessity.
Where there is other business logic that is written in actors but invoked via direct state inspection elsewhere, we might also be able to export those as actor methods. Please do let us know what they are as you discover them.
I don't think it's reasonable to expect the developers of the builtin-actors to propagate their changes into the slimmed-down actors
Assuming they're slimmed down to basically just state objects and params/returns, please at least ask us to!
@lemmih is https://github.com/ChainSafe/fil-actor-states sufficient for us to close this issue?
@lemmih is https://github.com/ChainSafe/fil-actor-states sufficient for us to close this issue?
Yes, our fork satisfies our needs. I wouldn't mind if you closed this issue. Might be appropriate to close it as wont-fix
.
Clients need to be able to "read" actor state for:
Currently, clients "decode" the underlying state by importing a struct definition.
Options