ADR-002 Tokenized Gateways
Opened this issue · 2 comments
Tokenized Gateways
Pocket Network is well on it’s way with tokenizing RPC nodes. However, all of POKT’s RPC requests on the network have gone through a gateway, currently known as the Pocket Portal.
V1 is focused on allowing Pocket’s RPC service to operate without the need of a gateway, which is very much what is needed, but this doesn’t eliminate the market value of gateways for RPC/infrastructure services.
Will gateways be needed in v1?
I believe the network will always have a large part of it’s market using gateways.
Gateways are centralized access points to POKT’s RPC but with QoS and feature addons. Without gateways, POKT users would have to wait for features to be released on the POKT network itself. What could be perceived from customers as “simple features” could require huge reworking of pocket-core to account for DApp needs. Desired features could break consensus or other core elements of the protocol, meaning it could take long periods of time before users can use a feature.
This will mean POKT network will be behind the centralized and marketplace style infrastructure providers. These providers can can quickly add features and address QoS needs instantly since they have centralized components that can be quickly developed upon. While POKT is having to add everything in a decentralized manner, the rest of the market will be able to adjust quickly to DApp needs and new blockchain needs without the burdon of changing the course of an entire network.
Gateways, like the POKT Portal is currently used now, would enable the POKT ecosystem to always add new features quickly for the end user, while protocol teams potentially works to add those features on a protol level. The POKT Portal right now is regularly updated to improve speed, reliability, and transparency. These changes happen quickly and in many cases come from working with DApp developers to understand all their unique needs. Fast and frequent updates to the Portal provide immediate benefit to the node runners because the service is able to improve without the need to change the protocol for each DApp’s needs.
In V1, POKT can offer DApps must more robust features when directly integrate POKT’s SDKs for truely decentralized RPC, but many DApps (and I would argue most) will likely still want more features than what will be on the protocol level. This can include:
- Real time QoS
V1’s Fisherman model can help rate the quality of a node’s past work, but it can’t provide real time QoS during a session. Currently the Portal will realized if a node is struggling and limit the traffic going to that node to reduce the amount of errors the DApp receives. Some QoS features can be handled via a robust SDK, but adding features will require DApps to constantly update their software address any new QoS issues.
With a gateway, realtime QoS can be guaranteed and DApps do not need to worry about changing their software to fix issues… issues can be addressed on the gateway side in real time. Gateways like the Portal provide apps with real-time QoS that so far does not exist in the scope of v1, thus apps could see major issues with large POKT node providers go down or if there are session issues.
- Privacy
From my understanding V1 is not very private. If a customer’s AppID or wallet is revealed to the world, then node runners can know what apps they are serving. This could be a security risk due to targeted attacks. If a node runner is maliciously targeting a specific app to provide it falsified RPC responses, there is now way the app can protect itself. All it would take is some dev to reveal a companies AppID or wallet and anyone on the POKT network could target only that app with bad data and fisherman may struggle to notice. There are many attack vectors I could see opening up if node runners can know which specific apps they are serving at any given time.
Gateways provide a layer of privacy. Node runners are technically submitting RPC requests to the gateway, who is an aggregate of many app requests. Technically gateways could then attack specifics apps (much the same way as any centralized service could try and attack their own customers), but gateways can be established business with binding user agreements and SLAs. A large DApp which is operating with hundred of millions of dollars worth of assets will likely want to trust a public facing service vs anon node runners of which some could secretly be targeting their service.
Privacy is also important because DApps/companies may not want their traffic data exposed to the public. Since AppIDs submit claims, it would be easy for anyone to track how much traffic some apps are doing. While for some this may be seen as a good thing, there are many companies who may not want their traffic public. Gateways provide a way for apps to use POKT with complete anonymity.
- Adding new services
Example: Currently POKT can’t support websockets. While I understand that WS is being considers in the v1 design, it points to the fact that it takes a long time for the Poket Network to adopt to different use-cases that are standard for centralized services. If the protocol itself isn’t able to handle a specific type of blockchain, call, or communication protocol, then gateways can adapt to the needs of developers while those elements are being brought to the protocol itself.
Another example: Indexing. POKT only offers direct RPC services, but much of web3 is adopting indexing as a means to get data fasters and in more logical ways. While POKT can be used for indexing focused RelayChainIDs in the future, gateways can offer these kind of services and be ahead of the market demand, while the protocol is preparing to support it natively.
Decentralized protocols will always move slower than centralized services. POKT is progressively decentralizing more and more aspects that were monopolized by centralized services, but there will always be need in the web3 space for being agile in adding new features to address new challenge and even new types of blockchains. Gateways, like the Portal, bring an element of agile QoS and feature innovation that can keep up with market demand, while offloading the core services to POKT.
With this thought that POKT will always have a prevolent gateway economy, it then makes sense to include the gateway economy in the POKT token ecosystem. I believe it would make sense to have gateways able to operate entirely with the POKT token, in conjunction with the protocol, to offer gateway services via a gateway marketplace. This brings together both market styles… the decentralized protocol (current POKT) and a marketplace. Apps can then come to POKT to choose if they just want the protocol (and fully access it in a decentralized format via an SDK) or access POKT via a gateway marketplace (with added privacy, QoS, and other features).
This means that the POKT token would be used universally, regardless of which model someone chooses to use. The token itself becomes a entry point to all types of infrastructure services and features.
How would tokenized gateways look?
In my mind gateways should be another node type. This means v1 would have validators, nodes, servicers, fisherman, and gateways. Apps would then be able to decide on a protocol level which gateway they want to send their relays to. The gateway could then receive payment on the protocol level per relays send from an app through their service.
Just like the networks mints rewards for services, the network can mint rewards for gateways. They are treated the same with the DAO having control to properly adjust the markets for each. Call wise, DApps can specify a gatewayID in their call so that the call is routed to that gateway. With this, specific calls go to specific gateways.
While servicers SLA’s are governed in a decentralized manner with the use of fisherman, gateway SLA’s are not decentralized and the user knows they are trusting a gateway entity to route their calls to the POKT Network. Users will understand that their SLAs are with a gateway entity and no longer with the decentralized POKT protocol. However, just because the user’s SLA is now with the gateway entity, the POKT token can still be the economic model used. There is no reason for gateways to have to charge other crypto or USD for their services… because they receive everything easily by plugging into the gateway POKT ecosystem.
This would also open the door for other RPC services to launch their service on POKT network. The gateway can operate with their own features and QoS, while using POKT as their RPC backend. This would take engineering to decide on how to ensure that gateways are using POKT as the RPC backend, but there may be way where gateways submit proofs of their RPC traffic in correlation to the traffic that has been sent their way. Or gateways could be whitelisted with PNI, and in extension with the DAO, with an SLA that they will use POKT for their backend RPC. Ultimately the goal is to have gateways use POKT for RPC and other futures calls that are added to the protocol vs just using their own nodes as a fully centralized solution. This is a major point that will have to be discussed and figured out.
Conclusion
I don’t think all blockchain infrastructure needs will be able to be fully offered in a decentralized manner with v1 at launch. No doubt POKT’s core protocol will be able to grow more rapidly in time to address more and more DApp needs, but POKT could use a way to scale faster with trusted gateways (like the Portal offers to 100% of POKT’s current customers). Having a gateway style node as part of the tokenomics helps address the long term need for quick innovation and specialized QoS in a manner that keeps everything in the POKT ecosystem. POKT could not only be a protocol for decentralized RPC, but also for infrastructure services as a whole. Any new infrastructure need can use this gateway model to enable their unique service on the Pocket Network. No doubt there will be challenges to adding a new node type to v1, but some elements of gateway whitelisting and management doesn’t have to fall on the decentralized protocol, as it could start off being a responsibility of the DAO or PNI. There are a number of RPC marketplace techs popping up, and they all use whitelisting as a means to grow. Gateways could have a similar model while also growing the POKT ecosystem. There has been talk of packaging the current Portal in a fashion that can be deployed by others, and by adding gateways to the tokenomics, the network can rapidly scale it’s service, both on and off the protocol. Blockchain infrastructure is a rapidly growing and increasingly competitive market, and incorporating gateways in to the tokenonimcs allows for agile growth while continuing to progressively decentralize more and more features and services through the core POKT protocol.
What is the status of this proposal?
My apologies for being 6 months late to the game, but I was just recently made aware of this proposal. I strongly oppose the idea of tokenized gateways. tl;dr it is a bad architecture choice, confuses the demand side and the supply side of the protocol and could jeopardize the censorship-resistance of the protocol. I will add more detail in a Forum post and paste link here when ready. If work has not begun, it should not go forward. If the code change has already been accomplished, it should be scrubbed and code reverted to previous version without this token pathway (I can create a new proposal to initiate the rollback if need be.)