Tracking [Who-6] Core and General Development

Chappie

Factomize Bot
This is your grant tracking thread. Below, you will find information from your original grant.

Grant Proposal

Team Member or Entity Forum Username
User: Who
FCT address: FA3WALLETKpcjeneRfQiX8Gv5vQDSugmDTomfc8uahvVgoUiqX3o
FCT: 12000

Total FCT Requested
12000

Start Date
2020-06-01

Completion Date
2020-08-31

Success Criteria
  • Community presence in discord and the forum
  • Adequate amount of pull requests or releases on GitHub
  • At least two blog posts published

Timelines and Milestones
I will be providing twice-monthly updates on my progress in the grant thread to keep the community appraised of my work

Budget
I am asking 12,000 FCT at 1.8 USD ($21,600 USD)
 
Hello!

It's day one and I'll be at the community's disposal for the next 3 months. The easiest way to reach me is on discord: Who#3791. My intended schedule is Mon-Wednesday from roughly 8-16 CEST, and Thursday from 8-12. Feel free to send me messages at other times but I might not get to it until the next work day. I'm okay with asynchronous conversations, too.

Currently I'm working on:
  • A utility library for listening to factom block/minute events to use in other projects and tools
  • Finishing up a discord bot that reports admin chain events to a discord webhook for easier monitoring

Things I'm planning on working on next:
  • Looking at the current state of Wax where progress seems to have paused, to determine what it would take to finish it
 
Last edited:

Chappie

Factomize Bot
@Who

Today is your grant start date! We look forward to regular updates from your team.

When you are ready for the final determination poll, first summarize the grant and self score then go to the thread tools dropdown at the top right and select "Create Final Determination Poll".
 
Hello! Time for the first twice-monthly update. I finished both the things I planned on finishing:

  • Factom Monitor is a utility library that implements a method to poll a factomd api for height and minute updates. Throughout developing utilities, I found myself writing boilerplate code over and over for this, so now i can use this instead
  • Factom Admin Chain Reporter is an app that uses the monitor and listens to new entries being made on the admin chain, reporting them to a discord channel of your choice via discord webhooks:
    1592209926239.png

GitHub activity:

Other work:
  • Worked with Fillip on a minor display issue on Factomize's ANO contributions forum
  • Beta tested the factom.pro explorer and gave extensive feedback to @Anton Ilzheev. The explorer is looking great and I'm excited for its release.

Things I'm working on right now:

I started reviewing the wax code and my first impression isn't that good. Development has been broken up into several modules but many of the modules are unfinished, with continued development uncertain and little documentation available on progress. It also seems to suffer from the same problem the original codebase suffers from, namely lack of consistency and clear structure.

It's a lot of code and I'm still trying to get a handle on how much needs to be done to get it running, but I've already begun work fixing some of the more obvious things and submitted PRs for them. I'm currently working on the Pub/Sub module, which lies at the heart of the Wax rewrite and can be dramatically simplified for easier usability and maintenance.
 
Last edited:
Update time again.

I spent some time benchmarking the existing code to figure out a baseline for testing some of the rewrites in the WAX module:
  • The node-internal p2p system has insignificant performance overhead for regular nodes. I'd still like to factor it out at some point because of the code complexity but it's not a priority anymore
  • I narrowed down the main reason for TPS limitation to message execution, which is currently single-threaded. This was accomplished by building a custom node with debug code and running a couple of load tests on the testnet (thanks @Paul B. ) to track packets from arrival in the network to the eventual usage. The messages arrive and are processed near instantaneously, then sit around and have to wait to be executed, which is an entirely single-threaded process and the main core logic. Theoretically, there's a lot of room for improvement here but it will require significant post-WAX refactor.

While working with @Anton Ilzheev on the new explorer, we discovered several bugs and inconsistencies in the node code which led to a number of PRs and fixes. We're currently working on an oddity that's hard to nail down. Other than that, I spent some time consulting with the new PegNet devs to try and teach them how pegnet works.

GitHub activity:

Plans for the near future:

Still working on wax and wax-related things. Currently working on whether or not I can come up with a better implementation of wax's pubsub module and a simpler, thread-safe replay filter.
 
Top