RFC: FPGA Routing Architecture

[ben-malbeclabs]

Summary of Changes

• RFC detailing FPGA routing and positioning between outer and inner rings.

[Copilot]

Pull request overview

This PR introduces an RFC detailing the FPGA routing architecture for DoubleZero's edge-filtration (EF) mode, enabling FPGA-based packet filtering for Solana validators while maintaining interoperability with existing IBRL and multicast modes.

Key Changes:

• Introduces a new vrf1-edge-filtration VRF to route traffic through FPGA hardware
• Defines traffic flows between EF users, IBRL users, and non-DZ users with FPGA inline filtering
• Specifies BGP routing policies and DZ-owned IP address space allocation for EF users

Reviewed changes

Copilot reviewed 2 out of 10 changed files in this pull request and generated 5 comments.

File	Description
rfcs/rfc-fpga-routing-architecture.md	New RFC document describing FPGA routing architecture, VRF design, traffic flows, BGP policies, and IP address management for edge-filtration mode
CHANGELOG.md	Added entry for the new FPGA Routing Architecture RFC

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[ben-dz]

From our conversation in Chicago, my understanding was:
Users could in theory be able to subscribe to different types of Edge Filtering. For the moment, the only type we're going to create is Edge Filtering (Solana), but there might be Edge Filtering (SomeOtherChain). Other types of edge filtering would land into a different VRF lite instance for that type of filtering (vrf#-edge-filtration).

With that, EF(Solana)<->EF(Solana) users within a single DZD would still have connectivity, but their connectivity will not flow through the filtering since it won't have to leave the vrf1-edge-filtration.

EF(Solana)<->Any other type of user will go through the FGPAs. In the future this will include EF(solana)<->EF(some other type).

[ben-malbeclabs]

@ben-dz I had only been considering Solana and not other chains as part of the RFC.

Do you expect inter-tenant routing to be required? I am not sure of the use-case. I assume in a multi-tenancy DZ world that each tenant would be kept isolated from each other i.e. there would be no connectivity via DZDs.

If a host/user wants access to both tenants, it would build a Solana EF tunnel and a SomeOtherChain EF tunnel.

[ben-dz]

I think what I was trying to get at here were actually a three separate thoughts that had stuck with me from Chicago:

1. We should include a nod towards future other edge filtering vrfs that transit through the FPGA to some other tenant's equivalent of VRF1. While this RFC is only focused on the Solana filtering application, I would argue it's worth including a little bit about where we saw this going in a multi-tenancy DZ, since we don't want implementation details to preclude it, or make more work for us in the future.

2. EF(Solana) to EF(Solana) is a supported traffic flow, but it does not flow through the FPGA (merely bounces through vrf1-edge-filtration in the DZD) and thus has no filtering. These users can still communicate with each other though! All those other flows described include filtering. As it is right now, it kind of reads to me that EF users can't talk to other EF users.

3. How traffic could flow between EF subscribers who are subscribed to a different category of filtration. This isn't something we're necessarily planning if we're not planning on allowing different tenants to communicate with each other, but would exist if we do allow different tenants to communicate with each other over DZ.