Decentralized Authority (DA) is pleased to present a proposal to construct Gateway Base, an innovative, full-stack, modular gateway, and framework. This project is designed to fulfill both the “Must-have” and the “Nice-to-have” elements, while focusing on two main objectives:
GOAL 1: Develop a customizable, modular framework equipped with all vital components necessary to launch new, multi-region DePIN (Decentralized Physical Infrastructure) gateways.
GOAL 2: Create a framework enabling POKT to become the pioneering DePIN network with distributed gateways. This approach transforms gateways into nodes, facilitating widespread deployment and fostering true decentralization within the POKT network.
GOAL 1: Crafting a Customizable, Modular Framework
Architectural Vision
DA envisions a foundational framework that encapsulates all crucial components for a gateway. This positions POKT as a comprehensive solution for new DePIN initiatives, enabling startups to make their data decentralized using the Pocket protocol, and enabling rapid development of their own gateways to grow users.
Consideration: POKT’s potential for AI integration is widely discussed. However, AI startups currently need to create a separate gateway to facilitate user access to any AI services on POKT. By providing an integrated protocol and gateway architecture, POKT can be the one-stop platform for easily launching a decentralizing data services.
DA proposes a highly modular system, offering developers flexibility in component selection and customization. This approach allows startups to leverage Gateway Base for foundational functionalities, concentrating their efforts on innovative features like:
- Data Analytics: Enhancing endpoint usage data utility.
- Privacy: Developing customer data protection systems.
- Indexing: Optimizing data storage for efficient access.
- Custom APIs: Streamlining data delivery.
- Unique Payment Structures: Offering diverse payment options.
- Project Specific Needs: Focusing on tailored services.
A Proven Architecture
DA’s proposal draws on our experience with designing a similar architecture for Community Chains (CC). Today CC still stands as the first DNS distributed gateway in Web3, connecting POKT nodes to a distributed, global pool of chain nodes directly via DNS.
CC has operated autonomously for six months, handling significant POKT traffic volumes (upwards of 20% at times) and successfully tested at bandwidths of up to 6 billion relays daily. We paused further tests due to the costs associated with multi-region testing.
We advocate for this architectural model for Gateway Base due to its demonstrated modularity, automation, performance, and resilience.
Core Architecture
Gateway Base comprises three primary components:
- Gateway Node(s)
- Gateway Command
- Portals
This diagram provides the applications and modules being built as part of Gateway Base, with their coding languages, and external open-source libraries and dependencies.
1. Gateway Node (GN)
GNs function akin to POKT nodes, primarily processing user relays. These relays are routed via DNS to a GN, where they undergo TLS unpacking and applicable filtering or routing before reaching the POKT network via Gateway Kit. GNs can be globally deployed to ensure worldwide coverage and low latency.
A key feature of GNs is the GController, which manages modules and containers, enhancing Gateway Base’s scalability. This feature allows for custom filtering and routing logic implementation, encouraging innovation in areas like Custom APIs or WebSockets.
FEATURE HIGHLIGHT: Update Cycling
GController includes an “Update Cycling” feature, circumventing the need for costly HAProxy enterprise subscriptions. This design allows for seamless HAProxy configuration updates without downtime, bypassing the limitations of the free version. This feature is part of CC, and allows config changes without losing any relays or logs.
2. Gateway Command (GC)
GC serves as the central management system for the Gateway Base stack, integrating data, logs, automation, and controls. Its modular design enables customization to meet specific gateway requirements.
For instance, Cloud Modules facilitate API interactions between GServer and cloud services. While we provide an AWS-compatible reference implementation, these modules can be adapted to work with various services, offering a versatile “pick your own adventure” approach for gateway owners.
FEATURE HIGHLIGHT: Operational Autonomy
GC’s design ensures GNs maintain user service capabilities, even if GC is offline. This architecture has proven effective in CC operations, allowing uninterrupted user service during major system updates. Even if GC is offline for an extended period of time, GNs will continue serving relays without skipping a beat, and all components will seamlessly resync once GC has been restored.
3. Portals
User-friendly GUI portals are crucial for any service. Besides User Portals, we emphasize the importance of Admin Portals. In CC, our Admin Portal enables comprehensive management of CC Towers (equivalent to GNs in Gateway Base), usage tracking, user management, and payments.
FEATURE HIGHLIGHT: Serverless Portals
We aim to develop portals with a serverless architecture, facilitating scalability and ease of customization through API-driven data retrieval via cloud services connected to GC.
GOAL 2: Enabling Distributed Gateways in the POKT Network
The separation of Gateway Command from Gateway Nodes paves the way for the future development of truly distributed gateways within the POKT network. We envision a scenario where gateway owners manage Gateway Command and Portals, while other hosts operate Gateway Nodes. This model, already successful in CC, ensures maximum decentralization for resilience and global coverage.
Integrating Distributed Gateways as a standard, user-friendly feature requires additional development but is achievable with the Gateway Base foundation. Emphasizing a decentralized approach from the outset positions POKT to lead in gateway technology, alongside the POKT protocol.
Distributed gateway tech is the next evolution of DePIN, and the POKT ecosystem is best suited to be its pioneers.
Submission Details
Team & Background
The project leads are @shane and @AmishBatman, potentially collaborating with contractors and community members as needed. Our track record with the POKT DAO and PNF includes successful deliveries, 100% of the time, across proposals, Sockets, and POPs. This includes the recent POKT wallet, which was completed within two months, with a budget that was 1/4 and 1/10 of past wallet initiatives.
Regarding gateways, the proposed architecture has already been widely battle tested though CC. The team brings direct experience in distributed gateways, and have been a prominent contributor in bringing gateways to the protocol itself.
Timeline & Budget
The project duration is estimated at 8 months, with the following development phases:
- Gateway Node Alpha - Completion in month 2.
- Gateway Command Alpha
a. Cloud Modules - Completion in month 4.
b. GServer - Completion in month 5.
- Gateway Node and Gateway Command Version 1 - Completion in month 7.
- Portals - Completion in month 8.
The budget is set at $25k per month, totaling $200k. This estimate is 40% less than the current Gateway-verse bootstrap initiative (which provided POKT with Gateway Kit), with the added advantage of Gateway Base being a fully open-source initiative. Payments, preferably a 50/50 mix of stables and POKT, will be made at the start of each month. DA is willing to work with PNF to come up with the ideal ratio for their ERA budget.
Progress will be trackable via public repos and public updates directly from the team. DA is very active within the weekly community calls, and is always open to discuss progress and answer questions on-call.
FAQ
Gateway Kit vs. Gateway Base: What’s the Difference?
While Gateway Kit integrates POKT into existing gateways, Gateway Base focuses on establishing new gateways or evolving existing ones into distributed systems. Gateway Base encompasses elements beyond the scope of Gateway Kit.
Gateway Kit covers:
- Handling App Stakes
- Generating App Sessions
- Single Endpoint access to an App Session
- Session level QoS
- POKT traffic logging
Gateway Base covers:
- Geolocation DNS
- TLS
- User generation
- Endpoint generation
- User facing UI
- Admin facing UI
- Load balancing
- Request tracking
- Call Filtering/Routing
- Gateway level QoS
- Payments
- Automations
Gateway Kit and Gateway Base combined creates a full-stack framework for new, POKT enabled, DePIN gateways.
Why Opt for a Full Framework Instead of a Simple Gateway?
A “simple gateway” will likely not drive significant traffic to POKT. World Class gateways require substantial investment and methodical architecture to achieve competitive performance on a global scale and draw user interest. Both Grove and Nodies’ gateways were built with substantial DAO funding and have taken time to build.
Gateway Base aims to use fewer resources than past initiatives, while maximizing efficiency, so new gateways can be quickly created, with enterprise-level performance, using an open-source modular framework. This will give all new gateways the ability to focus on value-add features to drive new users and revenue to the POKT protocol (the north star metric POKT is focused on).
UPDATE:
Today on the Ecosystem Community Call we talked extensively about the purpose of gateways, how they should be seen alongside the protocol, and what the future could look like with distributed gateways.
One of the most important concepts to come out of it, was thinking about how gateways act as an L2 to the POKT ecosystem. They facilitate features and use experiences that aren’t possible with the protocol itself. This is similar to how L2 on Ethereum enable speed, privacy or low costs not possible on ETH itself.
I think it’s important that POKT start thinking about the big picture of gateways and the tech that would be required to make them an approachable L2. The reason many prominent L2s on Ethereum, like BASE, have launched is because OP made a framework stack to make it possible for others to launch their own L2s. The reason we propose a framework for gateways is because it is important that POKT think in the same terms.
Just like OP and other L2 techs are currently working to decentralize their sequencers, I believe POKT should be working towards decentralizing gateways. We need to be pushing gateway tech to new heights in Web3 IMO.
Here is a shortened version to highlight the discussion around decentralizing gateways
Gateway Base Community Discussion (1-4-24 ) - Youtube