(WIP) chore: initial whitepaper structure

[dongwon8247]

The goal of this PR is to do a temperature check on how we want to structure the Gno.land whitepaper.

The technical parts, especially Gno, GnoVM, Realm specifications, TM2, etc., should be filled in by the core engineers who have deep knowledge in each section, and they should be cited in the whitepaper for their contributions. cc @jaekwon @moul @thehowl @ltzmaxwell @zivkovicmilos @mvertes @piux2 @omarsy @notJoon, and more.

@jaekwon should be the chief author of this whitepaper, and I'm initializing the discussion by opening this PR.

I'd love to hear your opinions on how we should form the whitepaper.

[Kouteki]

What about writing a yellow paper instead that outlines the current state of the Gno.land blockchain at its beta launch state? This has a few benefits:

• We can write a new version whenever we have a major change (e.g. once we integrate IBC and figure out the interaction between PHOTON, GNOT and ATONE)
• We avoid the pitfalls of theorizing how some components will work, and losing a lot of time on it
• A yellow paper is shorter, but much more substantial (e.g. 80% of the beta yellow paper would focus on the GnoVM)

I believe Ethereum came up with the concept and it's been very useful.

[moul]

Opened #56 with a litepaper as a starting point. We can write a proper whitepaper (or yellow paper) post-launch.

Let's choose if we prefer to start with white or lite.

EDIT: let's maybe just rename the file in this PR. Closing #56.

[moul]

why partial?

Suggested change

| Determinism | Partial | Partial | Strong | Strong |

[moul]

I’m not sure how to move forward with the current approach. I think having everything in a single PR makes collaboration and alternative proposals harder. Also, the initial commit wasn’t structured enough, as it bundled too many things together, including some incorrect parts.

I’d like to try a different approach: open a small PR that only introduces the basic structure and get that merged first. Then we can open separate PRs per section, so each part can be reviewed and discussed more easily.

[dongwon8247]

@moul please lead in your way. As I mentioned in the description, my goal was to initiate this effort, to encourage everyone relevant to contribute to the whitepaper. I'm happy as long as your suggestion would make everyone easier to contribute.

[moul]

Merged #57. Closing.