PEP-29 Pocket Lint (RECINDED)

[shane]

Hey @poktblade,
I’m happy to address your concerns.

@poktblade

I believe the PNF is best for the job and the DAO should fund the PNF for this job if bandwidth allows, because they have all the data needed.

I started a conversation with PNF in December regarding this tool and then provided them with a spec of what node runners need and have been asking for. They said a product like this is not on their roadmap and they did not have any time frame on when they would be begin considering this tool.

I offered to take on this tooling need and bring it to light. It was suggested that this should become a DAO funded tool since it is providing a much asked for community service.

PNF was consulted when needed during the development process and Alex, who is the tech lead for PNF, spoke highly favorable to this product and it’s relevance to node runners. POKT Lint is a tool that PNF actively refers node runners to for checking their node against an accurately replication of the cherry picker.

@poktblade

but it does not show you exactly where you rank or how you’re weighted in the “cherry picker” process.

If I understand your question, I think you are mistaken on how cherry picker ranks. In the POKT Lint instruction we outline the rule of thumb on how the cherry picker ranks:

This is the rule of thumb that was put together with Alex for this project to give nodes runners accurate cherry picker expectations. While each session in POKT is unique, due to the randomness of node selection, this rule of thumb from PNF is accurate.

Thus, POKT Lint is an accurate depiction on where you will rank when in sessions with different Portal locations. The cherry picker derives latency by submitting a current block-height call, which is exactly how POKT Lint works. A rundown from Alex regarding the cherry picker and it’s weighting process can be found here.

@poktblade

A ping/traceroute in my terminal would’ve been sufficient, or a bash script to do so. It’s not the same as a full RPC payload, but it should be far than enough.

@poktblade

Any node runner including Node Pilot should just capture the nginx access logs to see the latency in a real relay scenario rather than a simulate relay test, providing realistic numbers on the average latency end to end (upstream and downstream).

There are indeed many manual/technical ways to get the information that POKT Lint provides. The challenge though is that there are many different ways to run nodes, thus requiring different tests. Doing a manual ping tests can be useful for a simple POKT node setup where everything is hosted on single machine, but for a setup where the chains are on one server or cloud and the POKT nodes are on another server or cloud, then a ping test does not show the full latency picture. There are so many ways that node infrastructure can be setup where a ping would not be accurate.

You are correct that instead of using pocket-core’s simulate relay feature, node runners could just setup their nodes and wait for a mainnet session to find the information in their proxy or networking logs. That kind of process though was seen as a pain point as it can take a user days (due to increasing time between sessions depending on the chain) to gather latency information through raw logs. POKT Lint provides all that information in a few seconds.

While there are manual/technical ways to do every aspect of node running, RFP-7: Node Deployment Tools & RFP-8: Node Monitoring Tools are specific calls from the DAO to automate and simplify node running, which is why we decided to build POKT Lint. The goal was to make node testing available to all, regardless of setup, and create a way for advanced users to automate testing with open APIs.

@poktblade

I’m not saying it didn’t take 5 months of development, but can you justify this more? I looked through the commits and it only dates back to Feb 18th. Since then, it has been mostly sporadic commits with most of the work showing within a week or two.

Noted. Using the term “development” does leave the impression that coding has been going on for 5 months. I’ll edit this proposal to make this more clear. I was thinking more in terms of development of the project as a whole. You are correct in pointing out that coding started February, which was followed by the Github repo being created on Feb 13th and the AWS work shortly after.

Discussions with PNF regarding this tool started in December, followed by research, planning, and securing contractors, which fell through in January, leading to our connecting with @noproblem.

@poktblade

The DAO funded the team for runaway for Node Pilot and Node Runner which was suppose to cover also headcount (@noproblem, i’d assume).

POKT Lint is a completely different tool than Node Pilot hence why we are putting in a separate proposal. This kind of free community tooling, that is focused on all node runners (not just Node Pilot users), was not in the scope of work in our Node Pilot/Node Launcher proposal.

Regarding the team involved, @noproblem was brought on specifically for this product, not Node Pilot. The time that myself and Ryan put into POKT Lint was time away from Node Pilot. I don’t believe that funding for one specific product means that any future open-source projects for the community, from that team, should be pro bono work. This concept would stifle participation by barring teams to only one project.

@poktblade

Furthermore, I don’t feel comfortable even approving this one as we’re still waiting for the team to deliver on one of the awaited asks since the approval of the Node Launcher and what the community needs the most right now, The awaited validator API so other node runners can programmatically run their own Pocket Nodes.

Actually, we do have the Validator API in beta for Fuse. You can see the validator additions in the Node Launcher dev branch for Fuse. Here is a testnet validator that was successfully deployed via Node Launcher the end of March

We are in the process of adding POKT validators in the coming weeks, and we have an outside contractor working on Harmony validation.

Regarding general Node Pilot/Node Launcher updates, we gave a full community update last month. Major architectural changes are underway to improve security and make way for an enterprise API. The reception we have received from the Node Pilot community regarding our development plan and progress has been very positive.

@poktblade

I’ll just end it with that asking for a 40% premium while exchanges are down and the price we are at left a bad taste in my mouth

Now that I’ve operated a company that has worked exclusively within the POKT ecosystem for 6 months now, I’m in-tune with the nuances of being paid in a low volume assets (for a US entity) and the liquidation/taxation challenges. This is necessary to hedge the risk of being paid in crypto, in a volatile market.

@poktblade

if there’s a need for FIAT, then the proposal should use fiat. Bad timing.

The DAO does not pay in FIAT. All DOA funding is paid in POKT which the recipient is responsible for the liquidation, taxes, etc… hence the required safety net.