# Cheqd Interview Task

## Node Setup

### Task 1 - Initial thoughts

* Node setup process is dead simple
* Got the deb installer, and followed the guide, it just worked
* However some of the sed command didn't work, probably because the substitute command didn't find anything to substitute

### Node Info

* Node Endpoint - https://cheqd.jsdp.dev
* Node ID - `f378f6b0f839c6a506f6e85ea792abba33200e89`
* Moniker - `subzero`
* Status - Caught Up :heavy_check_mark:

Node is fully synced: 

### What are TWO questions you would like to dig deeper into, as a developer who has gone through the process of using the repo with a brief explanation on why?

Quite frankly, I couldn't find much so far. You guys have debs, bins, docker for distribution, which I think is already much much better than a lot of the cosmos based projects out there. However I do have few things I'd like to dig deep into:

1. Why build with starport? I know it's supposed to be well audited, standarised code but I believe that the cosmos ecosystem need a little time to mature.
2. And why Cosmos?
3. Also well aware of the fact that the cosmos ecosystem does not amazing support for testing but it does have `simulations` which lets you do sort of fuzzing testing on the chain, but I couldn't find any simulation integrations in cheqd node code

### Is there anything in the installation process or documentation that you would change?
The installation process was dead simple, much simpler than the ones i've used before, so i'd say no for now. 10/10.

## Task 2 - Build/Test/Release/CI-CD/Infra Improvement

For build and release, I'd say using PPAs/AUR/snap would be a nice way to go. It gives slight trust factor into the distribution. If I had to build a build/release/UX for the cheqd backend (CLI) or just the installtion process, I'd do it exactly like Tailscale.

Following are the few points that I thing would help cheqd improve their build, release and deployment lifecycles:

1. The number one thing that I believe that Cheqd is missing right now from a blockchain perspective is **Simulations**. A brief is shared here on [Official Cosmos Docs Page](https://docs.cosmos.network/master/building-modules/simulator.html). This can help perform fuzz testing and also testing testing for detecting on-chain behaviour, and since simulations are test scripts scritten in Go, they help with overall coverage and third party audits.
2. The build process for container images is already pretty slick. I've seen that we're already using multi-stage build process so container images must be smaller and performent, and they expose very less attack surface. Since Go's cross platform support is amazing, deb and bins work just good enough
3. **Linting and Code Quality** - I've seen that we're using `golangci-lint` but only with default options, it supports wide array of linters, static analysis tools, complexity measuring plugins and much more. Maybe we can use a configuration to make it fit to our needs and set a stricter rule set for it. Also github has a **CodeQL Action** (completely free), that identifies any CVEs and general security vulnerabilities, like adding two int64's can lead to an integer overflow and it's easy to miss out. Having CodeQL or something similar to avoid such scenarios
4. Finally, building a testing suite (which is not my speciality but in Go it'll be super easy) using any of the popular libs like testify or Is to build e2e scenes would be easy enough, but I believe going with simulations would be a better decision for testing on-chain behaviour.
5. I've also taken a look at the HCL code for cheqd-infra. I see that **ECS /w Fargate** is being used but maybe we can improve a lot of the pricing and visibility prospect of it. The last time i worked on ECS, I remeber fargate being **30% expensive** for managing the same workload than regular EC2 instances. maybe we can add an option to add EC2+Fargate to bring the pricing down a little bit. Also letting the configuration decide something like system architecture **(like graviton2 on AWS) would give 40% better price performance** than regular amd64 (x86) systems.
7. A tiny thing to notice but we should add support for setting custom tags for each resource that would be deployed using Terraform. This would help tracking the billing and resource utilization.

I understand this document has steered away from the original question but this is something that I could come up with from my very brief understanding of the Cheqd github repos (node and infra).