Welcome!

Meh,

This proposal is so cheap, and it's an interesting concept that we may as well (at least for the first three months), but at the same time this from my understanding is a completely trusted and centralized system. There is absolutely no proof or guarantee that the site isn't just sending back BS, or data from the wrong network etc. While I guess it's cool from a PoC, no one should use this in production unless they run the backend or have an actually written service agreement with the operator.

Additionally, I don't really see the appeal over APIs provided by services like insight or blockchair, which are both still centralized, but moreso designed to be used as a true API, and not just a wrapper around RPC. As an example: https://insight.dash.org/insight-api/block-index/0. You can see the rest of the endpoints here: https://github.com/dashpay/insight-api#api-http-endpoints

If anything is missing, I think it'd be more valuable to add additional inisght endpoints rather than wrap RPC.

Overall though ¯\(ツ)/¯

Here is the video explaining this proposal. https://youtu.be/Cx6u7mVKZmE

I like the idea, I think the UI looks slick, I like the fact it provides examples you can use right out of the box, I like that it gives the curl and fetch examples and I like the cost.

One consideration I have is that this does directly expose the RPC to the internet and they are not battle tested for such scenarios, eg how does the RPC handle injection attacks and how does it handle heavy load? At MNOwatch, we also need to present similar data to the front end eg for a block height, however we wrap that request safely and only the PHP makes the RPC call eg in the case the cached result is old, or empty and all error checking/validation has been done. I guess I would like to hear a few words about the back end if it just passes the call straight through, or if there is some sanitization to avoid these pitfalls.

Voting YES. I like these proposals that pay for a thing specifically rather than ongoing lumps sums for groups of devs working on a bunch of stuff. At least with this proposal, I know exactly what I am going to get and you get excellent feedback on thing you are doing. Cheers!

In short:

The proxy parses the JSON to determine the method and then forwards the request.

There's also a whitelist for allowed (public) RPCs that can be user edited with changes going into effect in real time to remove a particular RPC (or add a new one), if needed, without needing a new binary.

If the load becomes heavy I can add more nodes, but I think caching is a front-end concern.

In long:

The digitalcash.dev nodes are in isolated containers, so if even if there are security vulnerabilities in DCG's C++ code, and even if it lead to arbitrary execution, I'm not concerned - the risk is essentially 0, or at least no more risk than government-operated spy MNs, which certainly already exist on the network and likely a much lower cost attack vector with higher network privileges.

Since most of the code was written by the Bitcoin devs and Bitcoin RPCs are hosted by various commercial services, and much of the RPC code just repackages and runs the P2P, I'm not too worried about the thin layer between the RPC HTTP and P2P or DB calls introducing new vulnerabilities. The HTTP code will be pretty standard and the P2P code is already parsing addresses, gobjects, and such so the most vulnerable code paths are already exposed.

Also, at the point that there's a path to deploy this directly on MNs, the MNs don't have wallets or keys other than BLS, so again, I don't see much risk of practical attack damage.

And if DCG has such a vulnerability in their code, I think it's realistic to believe that DCG will take it seriously and act promptly.

As for performance, the C++ code is very poor, but if we can find or create code that directly accesses a copy of BDB (and others), we could have something that runs multi-core and much more effectively - or even abstract the storage away such that it could work with SQLite or PostgreSQL.

One of the proposals I have in the works is for adapting the secp256k1 signing and verifying to work directly with JWTs, so that API access can be paid for in DASH, and developers can determine for themselves if they'd rather cache requests or spend more DASH.

Source code is here so you can see how the proxy is handling everything.

https://github.com/digitalcashdev

(AJ is still waiting to get his account restored here on dashcentral so he can’t respond yet)

If you have an issue claiming your budget proposal or have difficulty getting into Dash Central, please contact rango at support@dashcentral.org as i do think it is important you claim ownership of this budget proposal.

I watched your video on digitalcash.dev/proposals/dcd-1-rpc-web-proxy/ and read the details on your budget proposal there and i think it is a good proposal with an acceptable requested amount of dash to fund, to make it more easy for developers to understand Dash rpc commands and get them more quickly up to date with Dash.

Also i am looking forward to seeing your thoughts materialize on getting some profitability on hosting these services on masternodes.

So you have my support, Mr. AJ ONeal