[review] MIP-92: Move Stack #92
Conversation
apenzk
requested review from
0xmovses,
Primata,
andygolay,
franck44,
l-monninger and
musitdev
franck44
added
Ready to Review
|
|
||
| The Move Stack is organized into first-order and second-order categories: | ||
|
|
||
| ```mermaid |
There was a problem hiding this comment.
I still think the second order distinction between logic and services is the clearest in my mind. This might actually be something that is good to talk to marketing or BD a bit about, to be honest.
| 1. **Move Stack Core (protocol units)**: Core components required for the operation of a Move-based Chain, as well as principal components. | ||
| 1. **Move Stack Binder (protocol units)**: Components to which the Move-based chains can connect and that provide a greater environment for the chains to operate in. Such as cross-chain communication, FFS Validators, and decentralized shared sequencing: | ||
| 1. **Services**: Modular components providing network or dApp remote APIs. | ||
| 1. **Clients**: Interfaces for low-level interaction and components providing network or dApp remote APIs. |
There was a problem hiding this comment.
There are some challenges here:
coreandbinderlikely are not going to have particularly neat lines during dev and maybe never. If we want to actually achieve this ontology, we are going to have to be quite strict and clear in our specifications.- Clients are going to be so tightly involved in parts of
coreandbinderthat it won't make sense to distinguish them unless we have a set of clients that are essentially SDK-type. That is, clients that are the entrypoints we intend for users of the Move Stack. Is that the intent here?
There was a problem hiding this comment.
- yes, i also lake clarity on how to separate this meaningful. The separation was decided in SF. What is your impression from our discussion in SF how to separate this better?
- no intent. this is RFC1 and i have not introduced anything new here. if clients are sdk tooling maybe they should be classed under sdk? is your proposal to remove the subclass clients from RFC-1?
|
|
||
| **Movement SDK** | ||
|
|
||
| 1. **CLI**: Command-line interfaces. |
There was a problem hiding this comment.
Is the intent for this to be a living MIP wherein we are constantly updating the list? Otherwise, the challenge as always would be splitting the universe via a clear ontology that actually covers all subcategories. There are some things I can suggest, but they're not really worth it if we want this to be more of a living document.
There was a problem hiding this comment.
yes, I think this MIP has to evolve with the stack. We may migrate certain content lateron to a different location and use this as a summary, but currently the MIP seems the best public place.
| 1. **Compiler**: Smart contract compilers for the Move language (e.g., Move LLVM). | ||
| 1. **Execution**: Virtual machines and block executors (e.g., Aptos Block Executor). | ||
|
|
||
| **Move Stack Binder (protocol units)** |
There was a problem hiding this comment.
Binder is a little interesting to me here. I would suggest that as a DLT company consensus and related components are really core. I would think instead, if anything makes sense for binder, it's units that allow you to plug one abstract subsystem into another.
There was a problem hiding this comment.
Here's an example:
utilis really the binder: https://github.com/movementlabsxyz/movement/tree/main/protocol-units/sequencing
memseqis where binding occurs between themempoolimplementer and the sequencing util: https://github.com/movementlabsxyz/movement/tree/main/protocol-units/sequencing
There was a problem hiding this comment.
So would the following be correct?
Shared Sequencers --> Binder
DA --> Binder
Consensus --> Core
Networking --> Core
Settlement: Settlement mechanisms (e.g., R0M ETH Settlement). --> Binder
Or are you suggesting to go into the subfolders? (which would seem a bit extreme to me)
|
|
||
| The Movement SDK provides: | ||
|
|
||
| 1. A unified interface for interacting with Movement technologies. |
There was a problem hiding this comment.
Yeah, so insofar as "Clients" are distinct, I think they should be brought up here.
Summary
MIP-92