My name is Perryn Gordon, I am an information technologist focused on developing, deploying and sustaining secure cloud solutions. I am interested in submitting a grant proposal to implement multi-region highly-available Zebra and Lightwallet infrastructure. I’d like to validate that using this template RFP - Zcash Lightwalletd Infrastructure Development and Maintenance is still the best way to develop a successful proposal, or if there is something newer I should be looking at. I would be grateful for any advice anyone might have for my process leading up to submitting an infrastructure proposal. I am encouraged by the excitement, creativity, and depth of engagement I’ve seen reading through various topics here. I am looking forward to becoming a helpful member of this community.
Running lightwalletd across multiple regions is exactly the reliability work wallets have been missing. When a wallet fails over between regions, does one operator end up seeing that user’s whole request pattern, or does the design keep each region’s view partial?
The infrastructure design that has been whomped up thus far is using Cloudflare to frontend all user requests to the nearest node, all of the nodes being under my operator “zinfra.xyz”, this kind of visibility being the same as if this were a single-node system, until Cloudflare routes to a different node due to the closest being not healthy/available, and so then spreading some of the pattern between nodes, albeit under the same operator.
This single-operator exposure is mitigated by configuring Cloudflare to mask user’s info , so there is nothing to use as original identity/finger printing information or any session like data coming through from Cloudflare, and consequently nothing to corelate in the session data between nodes either.
I am looking to provide a means of ongoing and real-time verification that the Cloudflare implementation feeding these nodes is always set so that no user data ever comes through.
Please let me know if that answers your question, if that sounds good like a good approach, and/or if I can clarify anything. Please do correct my understanding and/or ask for any particular design desires, the input is very much appreciated.
I think the best way would be for independent verification; ill look into setting it up so that designated community security auditors would have admin access to this and would get notified for any configuration changes.
Could that config instead be exposed as a public endpoint any user or wallet reads directly, so trust does not concentrate in the auditor set either? Giving auditors change alerts is a real step up from zinfra attesting its own setup.