Replies: 3 comments 2 replies
-
|
@ariznode thanks for taking the time to write this up; I'll attempt to address your questions but please bear in mind that some of this is subject to change as Miden and its requirements progress. aka these are just our/my current thoughts on these topics. I'm going to give a brief overview of our current implementation and our short-medium term goal in terms of architecture and then I'll answer your questions and requests directly afterwards (there will be some overlap). Our node implementation consists of several distinct components that communicate with each other using gRPC:
These components can be run separately, or as a single process for convenience/testing purposes. The prover is implemented as a separate binary. You can find an infrastructure architecture diagram here: https://docs.miden.xyz/miden-node/operator/architecture. Notably the RPC component can be scaled horizontally. Miden is currently centralized, and will likely remain so in the short-medium term. The long term decentralization plan is quite vague while we focus on getting the core technical details figured out. No formal decisions on consensus or p2p etc have been made. Q&A
There isn't a short term need to fully sync state since users/dApps/clients should really only need the state they rely on. And this can be sync'd using the miden client which in turn fetches the data from the node's RPC component. Or put differently, in the short-medium term we don't see a need for additional RPC throughput given the client side focus of Miden, and the current centralized nature. We do provide full raw block data via gRPC if anyone does wish to mirror the public state or build an indexer. Some additional discussion here: #1369.
As mentioned above, this is already mostly the case. At present components can be run separately and communicate via gRPC.
The prover is currently CPU only, e.g. our testnet prover runs on a ~64 core machine and produces reasonable sized proofs in around 1s. I'm not entirely sure about GPU support; not really my field of expertise :) @bobbinth? |
Beta Was this translation helpful? Give feedback.
-
The current prover is CPU-only - but there are two points worth mentioning:
|
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the detailed reply, that clears up a lot. I just have a few follow-ups based on what you explained.
A couple of things I wanted to clarify:
One thing I’d like to confirm:
And regarding the prover:
Happy to help draft proposals or test infrastructure if needed. |
Beta Was this translation helpful? Give feedback.
-
Correct; or rather its not high on our priority list unless there is a compelling argument to have it soon. An RPC mirror would require a copy of the store/database as backend and an RPC frontend. The latter already exists since this is what we use ourselves; the former would require some (hopefully) minor changes to fetch, parse and ingest the raw blocks from our official node. This would get you most of the way there I think. The downside of doing this now would be that we're still frequently making breaking changes to both the database and gRPC api. So it feels a bit wasteful spending energy on something that requires constant upkeep.
I think the intention is that this is done via the Rust or web-client. Note that it can be used as an SDK/library so that's how the current wallets and dApps are implemented. The client SDK takes care of managing the transactions and state sync for the accounts and notes that your app is interested in.
That is possible and is how the block explorer is implemented for example. You do miss out on merkle paths and proofs unless you assemble those manually. Some of the validator ideas here might also be of interest in this context for verifying authenticity of data from unofficial sources in the future.
Yes; with the caveat that they're currently buggy because we don't run them separately at the moment. For example, some of the components assume some order of operations and cannot be started or restarted in isolation yet. These aren't design flaws but rather just hacks/todos that we still have to patch. These components are actually all part of the > miden-node --help
Miden node binary
Usage: miden-node <COMMAND>
Commands:
store Commands related to the node's store component
rpc Commands related to the node's RPC component
block-producer Commands related to the node's block-producer component
bundled Commands relevant to running all components in the same process
help Print this message or the help of the given subcommand(s)
Options:
-h, --help Print help
-V, --version Print versionwhere we currently use > miden-node rpc start --help
Starts the RPC component
Usage: miden-node rpc start [OPTIONS] --url <URL> --store.url <URL>
Options:
--url <URL>
Url at which to serve the gRPC API
[env: MIDEN_NODE_RPC_URL=]
--store.url <URL>
The store's RPC service gRPC url
[env: MIDEN_NODE_STORE_RPC_URL=]
--block-producer.url <URL>
The block-producer's gRPC url. If unset, will run the RPC in read-only mode, i.e. without a block-producer
[env: MIDEN_NODE_BLOCK_PRODUCER_URL=]
--enable-otel
Enables the exporting of traces for OpenTelemetry.
This can be further configured using environment variables as defined in the official OpenTelemetry documentation. See our operator manual for further details.
[env: MIDEN_NODE_ENABLE_OTEL=]
--grpc.timeout <DURATION>
Maximum duration a gRPC request is allocated before being dropped by the server.
This may occur if the server is overloaded or due to an internal bug.
[default: 10s]
-h, --help
Print help (see a summary with '-h')
Yes, though at the moment we only support a transaction prover (batch and block prover are still wip). Our own testnet setup is a large CPU machine which does the proving (worker) with a small proxy in front of it to do rate-limiting and request queuing. The prover worker is pretty dumb - it has no concurrency or queue i.e. it only handles a single request at a time. So a proxy is required to load-balance etc, where the idea is this would be the architecture for multiple workers with a single proxy handling the request/response stuff. The prover stuff is actually completely separate from the node instance. The prover is publicly accessible and has no relation to the node aka the node sends its proof requests to the prover and not the other way around. |
Beta Was this translation helpful? Give feedback.
-
|
Appreciate the insights! That answers all my questions for now. Closing the discussion. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
1. Background
Currently, the Miden node operates as a bundled, monolithic node that performs all core functions locally: block production, validation, state updates, and proof generation.
For broader ecosystem development, scaling, and decentralization, there is a growing need for:
Supporting these capabilities would greatly improve flexibility, performance, and the ability to distribute workloads.
2. Current Limitations
No state synchronization mechanism
A new node must bootstrap from genesis, which becomes increasingly expensive as the chain grows.
There is currently no:
Node roles cannot be separated
A single Miden node instance performs all functions. For scalable infrastructure, a more modular design would be useful:
3. Questions & Feature Requests
4. Why This Matters
Introducing state sync and modular roles would enable:
5. Request to the Miden Team
Could you please clarify:
If documentation or drafts exist, the community would be glad to contribute.
(edited by @Mirko-von-Leipzig - only structural markdown edits i.e. using bullet points and headings, no content/text was altered - I hope you don't mind @ariznode, I thought it would be easier to address your points this way)
Beta Was this translation helpful? Give feedback.
All reactions