[Feature Request] Maintain a human-readable file for project status

[bernieblume]

🚀 Feature Request

Maintain a human-readable file for overall project status

Motivation

It is impossible for me to figure out where this project stands. Is there a loader for Move programs on Solana? Can we run a demo program? How can we access Solana Accounts from Move? Can we use the canonical Move Global Storage Structure (https://move-language.github.io/move/global-storage-structure.html) for that? How is Sealevel integrated? What concept is being contemplated as a replacement for the cross-module invocations mentioned in https://docs.solana.com/proposals/embedding-move ?

I would love to contribute, and also use this repo for our own project. I would appreciate if I could get some intro on where we currently are.

Pitch

Describe the solution you'd like

Let add and maintain a file BigPicture.md in the root dir, that describes the overall progress we're making, and the road ahead. It can also serve as an entry point for aspiring contributors.

Describe alternatives you've considered

I tried googling project status, DMed Richard Patel from Jump who tweeted about Move on Solana before, asked on Solana Tech Discord only t get an extremely generic response from Trent, etc. Tough to find out where we are with this. We need Move for Solana for our own project (see xandeum.com), and would love to contribute here rather than starting from scratch with our own team.

Are you willing to open a pull request? (See CONTRIBUTING)
Yes, of course.

Additional context

[ksolana]

We have https://github.com/solana-labs/move/milestones
Our discord channel is: https://discord.com/channels/428295358100013066/1022546078811291708 where all the solana-move developers are active.

[ksolana]

Documentation to setup move-llvm compiler and run e2e rbpf tests are provided here: https://github.com/solana-labs/move/tree/llvm-sys/language/tools/move-mv-llvm-compiler

[Lichtso]

Additionally, as the current program runtime can not support Move, a new one is being developed, which is tracked here: solana-labs/solana#28755

[ksolana]

@bernieblume do you need additional information?

[bernieblume]

Thanks for all the great background info, as well as for asking if I need more info, @ksolana!!! Since we are building stuff utilizing all the great things you guys are working on, my only question at this would be what the time plan. Of course I understand much of this hasn't been done before, and the timeline cannot be predicted like clockwork :-) But if someone can give me a rough estimate on when we can expect something like a "working prototype" of PRv2 in the Labs client, that would be awesome. We will be adding own "delegated" storage layer dubbed EGGS (External Global Grouped Storage, where data is stored on a network of potentially millions of storage provider nodes, as opposed to on each validator), so our EGGS accounts will be passed to the runtime for each tx / instruction (in addition to the Solana accounts) as an additional, scalable storage layer. We will also harness Move to just have a second "global storage struct" in Move - one for Solana accounts and one for EGGS. Sorry for the quick pitch (LOL) - just wanted to make clear why we desire early access to PRv2. Would also love to discuss our endeavor with the Labs team working on this. If you can help schedule a call it would be just awesome.

[ksolana]

As we are still trying to understand how move object types will map to Solana storage, it is hard to give an estimated timeline at the moment. We can update you once we have a defined path to integrate move with prv2.

@Lichtso has already shared the prv2 issue tracker above which will get updated as soon as we have everything in place.

You may also ask questions at the virtual-machine discord channel.