Closed GMKrieger closed 1 year ago
A few comments:
state-fold
project are published to a registry and is used elsewhere by Cartesi, including in the upcoming NxN which is in another repo. The goal was to have the state-fold
project as standalone crates which could be used as a public good by the community, as well as us. Are there any plans to maintain this characteristic? Will the state-fold
repo be deprecated?0.6.3
.block-history
. It was an independent crate from state-fold
crate before. For example, the dispatcher does not use the state-fold
, just state-fold-types
. I'll have to think more about this hierarchy, but I think there are other issues as well. I believe it's possible to put everyone in the same crate, it would make more sense to me.What is the purpose of this again?
* The crates under the `state-fold` project are published to a registry and is used elsewhere by Cartesi, including in the upcoming NxN which is in another repo. The goal was to have the `state-fold` project as standalone crates which could be used as a public good by the community, as well as us. Are there any plans to maintain this characteristic? Will the `state-fold` repo be deprecated?
Yes, there are plans to publish the state-fold as a crate, but not from another repository, We plan to publish it as a crate, but keep it inside the rollups-node repo.
* I'm not sure this is the latest version of the state-fold. It was at `0.6.3`.
It is the latest version from the cartesi-corp state-fold repo, on the develop branch. I actually lost quite some time using the cartesi repo version until I realized that it was the 0.5.0 release.
* With this new hierarchy, it's no longer possible to depend just on `block-history`. It was an independent crate from `state-fold` crate before. For example, the dispatcher does not use the `state-fold`, just `state-fold-types`. I'll have to think more about this hierarchy, but I think there are other issues as well. I believe it's possible to put everyone in the same crate, it would make more sense to me.
The new hierarchy is just a stepping stone on the process to use it internally. The issues are thought on a weekly workload basis, so that it doesn't overwhelm whoever is working on it. On this step, specifically, we only aimed to make it work within the rollups repo. There will be subsequent issues to address the hierarchy, as well as update the code, and make it a releasable crate.
Ok, I'll talk with @gligneul on tomorrow's meeting.
I'll try to summarize our conclusions. Can you verify that I got it right, @gligneul?
state-fold
repo will not be deprecated and will be maintained by a different team. It will have its own release cycle, and will be used by other projects in Cartesi like the NxN
.state-fold
.Hey everyone, I reopened this PR on the new repository, you can find it here . Please, add any further comments and reviews there. Closing this PR.
31
Importing state-fold to rollups repository. To do that, several changes had to be made to the original hierarchy of the state-fold.
First, both
state-fold-test
andstate-fold-types
were moved out of thestate-fold
crate. Thestate-fold-test
contains a contract that needs building and is called insidestate-fold
, andstate-fold-types
is called insidestate-fold-test
, so there would be a loop dependency call.The
state-server-common
crate was removed and incorporated insidegrpc-interfaces
, since they do the same thing and offchain already imported the external repo.