Exploring whether Mosaik -- Flashbots' self-organizing p2p runtime -- could serve as the foundation for a high-performance mempool (in the style of Commonware or CometBFT) that collapses transaction dissemination, order matching, and block production into a single pipeline.
In CometBFT and most blockchain architectures, the pipeline is segmented:
Tx submission -> Mempool gossip (opaque bytes) -> Block proposer selects txs
Analysis of Mosaik (v0.2.1) -- a Rust runtime for self-organizing, leaderless distributed systems built on iroh (QUIC-based p2p networking) -- and how its primitives map onto intent-based orderflow systems like NEAR Intents.
Nodes deployed on plain VMs self-organize into a functioning topology using just a secret key, a gossip seed, and role tags. No orchestration needed. Four subsystems:
NEAR Intents (formerly Defuse Protocol) coordinates intent-based settlement across 18+ chains. The current architecture relies on a centralized Solver Relay (solver-relay-v2.chaindefuser.com) as the sole coordination point between users and solvers. This is a single point of failure, a censorship vector, and a trust assumption on the relay operator.
CometBFT uses flood gossip for mempool propagation: every validator receives every transaction regardless of whether it is the current block proposer. In a 100-validator network, 99 validators maintain redundant copies of the mempool that they will never use to build a block during the current slot. This wastes bandwidth and creates unnecessary load.
The proposer schedule in CometBFT is fully deterministic. All validators independently compute the same proposer for any (height, round) pair using weighted round-robin -- no communication needed. This means we can route transactions preferentially to upcoming proposers without any new consensus messages.
Exploring whether Mosaik -- Flashbots' self-organizing p2p runtime -- could serve as the foundation for a high-performance mempool (in the style of Commonware or CometBFT) that collapses transaction dissemination, order matching, and block production into a single pipeline.
In CometBFT and most blockchain architectures, the pipeline is segmented:
Tx submission -> Mempool gossip (opaque bytes) -> Block proposer selects txs
Analysis of Mosaik (v0.2.1) -- a Rust runtime for self-organizing, leaderless distributed systems built on iroh (QUIC-based p2p networking) -- and how its primitives map onto intent-based orderflow systems like NEAR Intents.
Nodes deployed on plain VMs self-organize into a functioning topology using just a secret key, a gossip seed, and role tags. No orchestration needed. Four subsystems:
From Kris Kowal:
We should probably deny "guests" the use and visibility into identifiers/locators and just make them work in terms of petnames and live values. That may require us to introduce
E(guest).equals(a, b)and to create more methods that operate on values (where the engine looks up the identifier behind the scenes). This would be consistent with MarkM's "distributed confinement" notions, where the confined applications don't get to see swissnums and addresses. This is also consistent with our value proposition: Giving an LLM cryptographic data is bad. Providing fake cryptographic data as a stand-in for real cryptographic data is cute, but why do that when you can give the LLM the ability to choose its own names and never expose them to large, immemorable numbers?
The llm-long-running-tasks branch is our main work spike for LLM agent infrastructure on Endo. It includes a llamadrome package (multi-backend LLM agent with Anthropic/Ollama), conversation persistence across daemon restarts, and a set of new daemon verbs for capability-separated evaluation: define, endow, form, requestEvaluation, and storeValue. The idea is that an LLM guest can propose code with named slots, the host endows those slots with capabilities, and the code runs in a sandbox with host approval.
I've looked at the daemon-reply and daemon-collector branches and want to merge that work into the LLM branch so we're building on the latest daemon internals rather than diverging further.
Ax is a TypeScript DSPy implementation for building production LLM applications. Instead of writing prompts, you define signatures -- declarative input/output contracts -- and Ax handles prompt generation, structured output extraction, validation, retries, and optimization.
Key capabilities:
'review:string -> sentiment:class "positive, negative, neutral"' -- no prompt engineering
Endo is an object-capability runtime for JavaScript built on Hardened JavaScript (SES). It provides a daemon that manages confined guest programs communicating through a durable message system. Guests receive only the capabilities explicitly granted to them by the host -- they cannot reach ambient authority like the filesystem, network, or environment. All state is persisted through a formula store, so the daemon and its guests survive restarts. Capabilities are named via pet names in per-agent directories, and all inter-agent communication flows through a typed mail system (send, request, define, form).