Add state-fold to rollups

[GMKrieger]

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 and state-fold-types were moved out of the state-fold crate. The state-fold-test contains a contract that needs building and is called inside state-fold, and state-fold-types is called inside state-fold-test, so there would be a loop dependency call.

The state-server-common crate was removed and incorporated inside grpc-interfaces, since they do the same thing and offchain already imported the external repo.

[GCdePaula]

A few comments:

• 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?
• I'm not sure this is the latest version of the state-fold. It was at 0.6.3.
• 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.

What is the purpose of this again?

[GMKrieger]

* 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.

[GCdePaula]

Ok, I'll talk with @gligneul on tomorrow's meeting.

[GCdePaula]

I'll try to summarize our conclusions. Can you verify that I got it right, @gligneul?

• The 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.
• The imported crates will be fully independent and will not generate releases. They are internal components of the node. If there are bug fixes, we'll add them to the "default" state-fold.

[GMKrieger]

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.