Building in the Open and MEV #288
Replies: 2 comments 12 replies
-
🫶
To avoid frustration with the monorepo (see the laundry list of complaints on any blockchain GitHub repo where a great dev implements something cool but the maintainers don't have the bandwidth/context to take ownership), my guidance has thus far been for teams looking to implement novel functionality (like a "mempool" dialect) to create a "primitive repository" under their control where they can experiment with the idea (likely building on some of the crates in this repo). They can keep all conversation about their work in the discussions on this repository to avoid a fracture of focus but can move at their own speed on development wherever they see fit. At some point in the future (for any number of reasons), said primitive(s) can be migrated into the monorepo (where we would continue to maintain and audit). I think we could create an "awesome commonware" section on the README that links out to other work people are taking on (for things that are not in the monorepo).
For both SMR and DSMR, pre-consensus dissemination IMHO is still shockingly underexplored given its importance. For finance-focused applications, enshrining MEV extraction can avoid a lot of other undesired side effects (as you've mentioned). However, use cases with minimal MEV opportunity (like posting on a social network) can achieve higher throughput with optimizations that may exacerbate those unintended outcomes in a finance-focused context. We do strive to work in the open as much as possible, so it isn't that we have some big internal chat room where we are harboring our mempool ideas. Rather, we opted to focus our energy on things below the mempool first.
It should definitely be possible to build something like this with Commonware primitives. If you are so inclined, our initial work will likely veer more towards throughput prioritization over "fairness".
Thus far, we've tried to extensively document how primitives work (such that the mod.rs at the base of a primitive or primitive dialect should provide a pretty good idea of what's going on). I'm still pondering how to adapt this concept to something like this repository where there isn't meant to be agreement on tradeoffs in a given primitive (per se). What you are seeing so far is just a first set of opinionated things we wanted but we may build out "replacements" that could be used instead of what we have now (like a p2p that isn't encrypted). In the meantime, I was hoping that we could use these discussions for pending conversations and as a rallying point for like-minded folks and use the primitives themselves to track architectural details.
If you scheduled something, I for one would be happy to attend. We haven't yet put together our "eng call" strategy but could imagine having an open call each week for contributors to join? If that sounds interesting, lmk! |
Beta Was this translation helpful? Give feedback.
-
|
Calendar Invite as promised! |
Beta Was this translation helpful? Give feedback.
-
|
I didn't know you could post an open invite. Very cool. For this first call, I think we should just focus on the topics in this thread. When the time comes to setup an "broad engineering call," we'll handle scheduling/planning on that one. |
Beta Was this translation helpful? Give feedback.
-
|
Is the call open to everyone? |
Beta Was this translation helpful? Give feedback.
-
|
Definitely! The more input the better imo. |
Beta Was this translation helpful? Give feedback.
-
Yes, the meeting link is open to everyone. You can simply click the link and use your Google account to schedule an appointment. |
Beta Was this translation helpful? Give feedback.
-
|
A Personal Suggestion: Could we consider holding our meeting on X (Twitter)? Since X is an open platform, it allows any interested developers and users to join the conversation at any point during the meeting. By leveraging the content sharing features of the platform, followers of the participants will also receive relevant notifications. Plus, after the meeting, X automatically generates a record of the discussion, making it easy for those who missed it to catch up later. I think this is definitely worth considering. That's my personal opinion. |
Beta Was this translation helpful? Give feedback.
-
|
I'm open to it, but it's up to Patrick and the team about the best platform for Commonware. Let's stick with Google for this one and then we can talk about Twitter and get everyone's feedback and if everyone thinks it's a good idea then move the next one to Twitter. |
Beta Was this translation helpful? Give feedback.
-
|
Nice👍 |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Hey everyone,
Great work in getting Commonware to such a high level in such a short amount of time.
Since Discord won't be used for communication, can I suggest that major pieces of work get their own project so that discussions can be focused and semi contained. For example I'm looking for more information about how Commonware aims to tackle the mempool.
I saw Patrick mention it in a discussion, but currently there's no way, that I'm aware of, whereby I can see the current thought process around how it will be implemented. I've been doing a lot of research into MEV and it will become a reality for any chain that reaches a modicum of success. As such these primitives should treat MEV as a first class principle.
As per Bert Miller, your chain will then get either:
As such the Mempool design needs to take into account these tradeoffs.
From my perspective, if I may be so bold, I'd like the ability to outsource MEV protection to Buildernet via Rollup-Boost https://writings.flashbots.net/introducing-rollup-boost
This will be great for EVM buidlers. However the mempool needs to be VM agnostic and Rollup-Boost should be optional. A competitor to Rollup-Boost should be able to build it with Commonware primitives.
All of this is a very long winded way to say that the design decisions for the mempool and indeed the broader Commonware ecosystem should be documented in the open. I like Celestia's approach with their Architectural Decision Records https://github.com/celestiaorg/celestia-node/tree/main/docs/adr and think something like that would be really beneficial.
Then the other suggestion would be to establish some form of working group that holds these discussions via a virtual meetup. I'm a bit biased here but I'd love it if these could occur 4pm ET as I've found that works best for Asia, Europe and the America's.
The mempool is going to be absolutely fascinating to see how Commonware builds it and I believe could be one of the most important parts of the stack.
Beta Was this translation helpful? Give feedback.
All reactions