Readme 20231015 #1
Conversation
|
I split the current RPC calls in domains and define a file for each one. I add an architecture diagram as an example on how domain can be connected. |
Seems like this should be a separate PR? |
musitdev
force-pushed
the
readme-20231015
branch
from
45b627b
to
83dd97d
Compare
|
Done, I create the PR #2 |
| A repository for RPC v2 related specifications & documents. This document is work-in-progress and subject to change. | ||
|
|
||
| ## Objectives | ||
| 1. Discuss changes to the standard RPC API. [https://docs.solana.com/api/http#json-rpc-api-reference] |
There was a problem hiding this comment.
"changes" mean extensions to the API? we want to be backwards compatible?
|
|
||
| ## Overview | ||
| ### Intended User | ||
| Solana developers building the next great web3 app who want to run their own infrastructure. |
There was a problem hiding this comment.
I am looking at three use cases with will not covered by reference implementation yet we should should keep the scope of discussions broad enough to cover all of them:
- RPC API (pool) provider like Triton who operate a bit infrastructure of RPC nodes and give away the API to dapps who do not want to run Solana Nodes
- dapps not running any infrastructure but may need more than what we have now
- dapps who run 1-2 nodes and want to serve RPC for their own dapp (mango)
| They need reference RPC software that scales from localhost up to a single-location, single-tenant mainnet service. | ||
|
|
||
| ### Solution | ||
| The default configuration is suitable for a local test RPC service. There is also documentation illustrating a single-location, single-tenant mainnet service along with recommended hardware & configuration. Teams building Commercial or large-scale applications can use the reference implementation as a guide for their work -- some assembly required. |
There was a problem hiding this comment.
for recommended hardware ,please follow up here question on hardware spec
| The default configuration is suitable for a local test RPC service. There is also documentation illustrating a single-location, single-tenant mainnet service along with recommended hardware & configuration. Teams building Commercial or large-scale applications can use the reference implementation as a guide for their work -- some assembly required. | ||
|
|
||
| ### Value Proposition (how much will this cost?) | ||
| A typical mainnet solution will be possible on a single high-spec bare metal server running in a professional data center. Additional servers will be required for scaling up or add-on services like the Metaplex DAS Read API. |
There was a problem hiding this comment.
This is just an aside - I'd love to see this expanded to include an easier to run compressions component. DAS is much more than a dev needs for compression work in a lot of cases.
There was a problem hiding this comment.
hi, just caught up on what DAS means!
could we please clarify your comment a bit!
you are saying that you want a compression system to be part of this project and optionally provided to anyone who runs the RPC v2.
From what I see the API is not part of the Solana RPC API definition. So it's effectively an extension to that.
Please correct me, if I am wrong!
If the topic is a bigger discussion I would suggest to open an GitHub issue and change the structure of this document (readme) to in scope/out of scope/maybe scope
There was a problem hiding this comment.
It isn't a part of the Solana RPC API yet - but it should become a part of it (whether in its current form or in a revised one). Imo changes to RPC spec/its source of truth should live here as well, so we're in control of adding this.
I can open an issue bc its a bigger discussion
| A typical mainnet solution will be possible on a single high-spec bare metal server running in a professional data center. Additional servers will be required for scaling up or add-on services like the Metaplex DAS Read API. | ||
|
|
||
| ## Details | ||
| ### Model View Controller (MVC) |
There was a problem hiding this comment.
imo the service build for this should be as monolithic as possible, you can argue that it can be tied up in a way that a dev wont notice, but in practice there are always complications when you start splitting everything up.
Either way we should start with an trait in Rust that has each rpc method, we can provide a default impl and then if someone wants to customize/pull out components they can do so by plugging their service into the trait method
There was a problem hiding this comment.
sort of disagree with the first part. need to followup on this one - it's a hard topic!
yet the developer experience (on localhost) should be one goal IMO
There was a problem hiding this comment.
You can of course deploy things separately as microservices if you want, but if for eg. everything is in rust, I don't see why we wouldn't make it a monolith. If you have independent scaling needs for something just deploy the service with only X features enabled
There was a problem hiding this comment.
I quite like the idea of a monolith that can be compiled into separate binaries with separate functions. In the direction that solana started with the splitting up of the RPC api into different levels of functionality. However - as we see with DAS it can also make the design a bit convoluted :)
For dev use we probably really want a single binary to run. If, in the same code base, we can support the generation of different binaries that can be used as smaller services for prod use that's all well and good. In practice, my experience is that we do need to have abiltiy to scale differnet components individually and also run these components at separate locations.
| - Views -- Parse the backend response based on the client request. For example, jsonParsed TX + parsing from Anchor IDL. Requests for the default format of base64 will bypass the view later for better performance. | ||
| - Model -- the backend data servers or validator RPC which will return data in base64 format. | ||
|
|
||
| ### Subject Domains |
There was a problem hiding this comment.
These are logical, but does it make sense to prescribe them now? And what do they mean in practice? Are these separate services?
We may want to add more domains/combine them in the future
There was a problem hiding this comment.
Phil and me we can propose something more detailed soon.
on prescribe vs freestyle: we are hoping to get everybody to agree on the abstractions we see in the vanilla rpc 2.0. no restrictions to extensibility should be imposed imo. the system should be composable and extensible.
There was a problem hiding this comment.
When you say abstractions, what does that mean functionally? Is it defining service boundaries? Code structure?
There was a problem hiding this comment.
hi, sorry for being so late:
wrt abstractions I was thinking of the building block of the architecture on a very high level:
e.g.
- all RPC deployments - small and large - will have a router component
- there will be one or many parsers/mappers not bound to a specific technology or deployment model (i.e. can be a linkable library written in Rust/Typescript, a remote service)
These building blocks should have nice names that explain the purpose (rather the implementation)
There was a problem hiding this comment.
will rip that part out of README and open an issue to discuss that specific proposal -> #11
Would love to see more (subjective + biased) solution design drafts that we can compare and consolidate over time.
| ## Objectives | ||
| 1. Discuss changes to the standard RPC API. [https://docs.solana.com/api/http#json-rpc-api-reference] | ||
| 2. Create a reference implementation that will support the standard API using common open-source software tools. The primary objectives are API compatibility and vendor configurability. Performance is a secondary concern for the reference implementation because vendor-specific infrastructure will ultimately determine performance. | ||
| 3. The reference implementation should provide a base level of service for local testing with modular options to scale up for mainnet. |
There was a problem hiding this comment.
naming (reference implementation) ... let's discuss here what term we want to coin
|
Brian, I have moved generic project topics to a new README-PR and extracted all other topics you mentioned in respective Github Issues or other documents |
Updates the README file with objectives and a high-level overview of the project.