First of all, thank you to the ZCG for the thoughtful feedback on our SA-SMS proposal. The concerns raised about the current form of our solution are valid, and I’d like to follow up on Hanh’s suggestion to involve the community in designing a more robust architecture.
The goal of this post is to collaborate with the community to design a Shielded Aid Gateway system that aligns with the Foundation’s SAI principles. Our mission remains unchanged: building a decentralized, censorship-resistant, and privacy-preserving distribution network.
Our core constraint is clear the system must function in regions with zero internet connectivity at the point of transaction.
@Hanh , I’d really value more insight into the “proper solution” you envision for users with no internet access.
Is it primarily FROST-based? Does it require a ZK-ID layer for sybil resistance?
We’re eager to work with the community to design a tool that can genuinely serve this need.
That’s a great suggestion @decentrathai, thank you. I just did a quick research and it. Just so I’m clear on your vision: are you suggesting we explore integrating with an existing service (like a Blockstream API bridge), or are you envisioning the community building a native Zcash broadcast layer?
A satellite broadcast would definitely solve the downlink problem (knowing you received funds). However, my concern remains the ‘Uplink’ problem and the Z3 data requirements:
The Triangulation Risk: From my understanding Zcash requires a Witness like the borrow checker in WASM so even if a user can receive data from space, they still have to ‘shout back’ to spend it. In high-risk zones, any active satellite or radio transmission creates a physical triangulation risk that could compromise the user’s location.
Z3/NU7 State Size: With the move to the Z3 stack, a wallet needs to stay synced with a significant amount of shielded data to create valid proofs. Broadcasting this volume of data over narrow-band satellite might be too slow for practical aid distribution.
This brings me back to my current understanding of FROST v3 (ZIP-312). If we can’t trust the ‘uplink’ (Satellite or SMS) because of signal tracking, perhaps the solution is ‘Delayed Relay.’ The user signs a transaction fragment offline, and that fragment is carried out of the danger zone physically or via a low-power mesh. I wonder if the community see FROST as the primary solution for this ‘last mile’ in the SAI? Specifically, a theoretical design where viewing keys never leave the device, even when using an untrusted relay?
Could we utilize FROST Pre-processing (generating the Round 1 nonces in advance while the user does have a moment of connectivity) so that the ‘Offline’ part only requires a single round?
regarding ‘Secure Channels,’ if we use the Noise Protocol (like the Foundation’s reference implementation) to encrypt the fragments before they are sent via the gateway, would that satisfy the security concerns for an untrusted relay?
What if we’ll use not pure satellite but more like hybrid: satellite for downlink only (passive receive, no RF from user and no triangulation), and something like LoRa mesh (Meshtastic) for uplink. There’s a project called btcmesh that relays Bitcoin raw transactions over Meshtastic. Interesting as a concept, but Zcash shielded transactions are way bigger than BTC (Orchard proofs and coming ZIPs are thousands of bytes, LoRa packets max around 228 bytes). The chunking overhead might make it impractical. Would need someone to actually run the numbers.
Seems like we are getting close to a solution. The hybrid model definitely solves the triangulation worry for the downlink, but you’re also spot on about the ‘Zcash is too fat’ problem. One concern with the LoRa mesh is the hardware barrier. Since phones don’t have native LoRa support, every aid recipient would need a secondary node (like a Meshtastic device) paired via Bluetooth.
If a single Orchard spend is ~3KB-9KB, trying to chunk that into 200-byte LoRa packets over a multi-hop mesh is a recipe for high packet-loss and frustration. Which keeps bringing me back to FROST v3, hahaha. I believe If we use the ‘Delayed Relay’ model then we won’t just be sending raw transactions. It would be with FROST signature fragments.
Then the ‘fragment’ size can be optimize to fit inside a few LoRa packets, we might solve the chunking overhead. Plus, with the Z3 stack and Zaino, the user only needs to receive the specific data for their coins from the satellite, not the whole chain.
To be honest I believe requiring extra individual hardware would be a kiss of death for a a project like this for the primary demographics.
