changed 2 years ago  
Linked with GitHub

Lido Validator Dashboard RFP Bid

Proposal submitted by @henridf, who will execute the project with possible involvement of a designer/FE dev, depending on the chosen FE option (redash vs custom).

Bidder background

I (@henridf) am a CS researcher and software engineer, with product and tech experience all over the infrastructure stack, including data analytics, devops, and monitoring. Since early 2021, I have switched to working exclusively in the Ethereum ecosystem, with a primary interest in applying my data analytics background to chain data.

Some relevant prior open source prior work includes:

Proposal

Scope of work

The scope of this proposal is to deliver and operate a complete system meeting and exceeding the requirements of the RFP, and consisting of:

  1. A near real-time data ingestion process, based on an extended version of chaind (more info below).
  2. A publicly-queryable database containing all data gathered by the ingestion process. This includes raw data and aggregated/ETL'd data.
  3. A web front-end displaying per-operator metrics. Each of these metrics will be shown in a table, and it should be possible to chart metrics over time where relevant.
    • Balance
    • Attestation percentage
    • Attestation inclusion delay
    • Block proposal percentage
    • Income earned (average daily/last week/last month/since live)
    • Other useful metrics which will suggest themselves as the project progresses.
  4. Deployment, and hosting/operation of the entire system (including a beacon node to read from, if necessary).

All software developed as part of this project will be open-source and hosted at GitHub. Changes to existing open-source projects (notably chaind) will be upstreamed or maintained in a separate fork if the upstream maintainers do not accept these changes.

Dashboard options: redash or custom

Leaning on experience and lessons learned monitoring systems and with sandwiched.wtf, the goal will be to have a simple, readable layout. This dashboard will require some interactivity including (at the least) a date-picker and possibly some other drop-downs/selectors.

The dashboard could be done using a dashboarding system (redash), or implemented "custom" from scratch.

In case of a "custom" dashboard, one inspiration could be l2beat.com, which could serve as a starting point (imagine replacing the L2s by node operators). The pros/cons of the two options are:

Redash front-end:

  • + faster to develop
  • + more flexible and easier to modify/extend by third parties
  • - less room to design a visually distinctive solution, possibly less ergonomic

Custom front-end:

  • + more aesthetically distinct, potentially more ergonomic (but keep in mind that redash and grafana already make it quite easy to get ergonomic results)
  • - more work to develop
  • - less amenable to layout modifications/updates

Note that in the case of doing the project with a redash front-end, it would be possible to subsequently extend it to add a custom front-end. Conversely, in the case of doing the project with a custom front-end, we would certainly develop grafana dashboards along the way.

We recommend the former route (start with a redash frontend) as we could then design the custom front-end with more experience at hand - if we we think that is worth doing, after using the redash solution. But ultimately, this is of course LEGO's decision :slightly_smiling_face:.

Bid

We propose to break down the bid into a development fee and a subsequent monthly operations and hosting fee.

Development fee

For the development phase, we propose:

  • A first payout corresponding to 25% of the development fee would be made at the start of the engagement
  • A second payout corresponding to 50% of the development fee after delivery of the online production system, would be made, following a 5 day review period.
  • A third payout corresponding to 25% of the development fee two months after the delivery of the online review period. This is the "iteration" period for bug fixes and minor tweaks/enhancement based on user feedback.

The development fee is $35000, assuming a redash frontend. If LEGO prefers to go immediately with a custom frontend, the development fee will be $42000.

Monthly operations and hosting fee

The operations/hosting fee is $1400 per month and covers all hosting, monitoring, and maintenance (including bug fixes) of the system to keep it up and running. It starts upon delivery of the online production system (payout 2 above). We are willing to commit to this for an extended period and propose to start off with one year (renewable).

As part of operations, we wil use a website monitoring tool (such as pingdom). We can give LEGO access to the output of this tool to verify uptime.

The uptime SLA is 99% (as determined by the monitoring tool). The support SLA is same-day response (in EU working hours) for outages and next-day response for degraded service (such as slowdowns, stale data). A failure to meet the SLA will lead to the monthly fee being halved; a second failure in the same month will lead to the monthly fee being entirely waived.

I am available to start work on this within a week of getting a positive response the project, assuming that response is received by August 15th. At this stage I believe that the initial version with redash can be brought online in approximately 6 weeks time.

Payment method

Invoices will be issued by 12th Ave Labs Sàrl (@henridf's consulting LLC) and can be denominated in ETH or LIDO depending on LEGO's preference. The conversion value of ETH or LIDO described under the agreement will be the value in USD at NYSE closing time (4 PM EST) on the day prior to the due date (as described at https://www.coingecko.com).

Appendix

Some early thoughts on architecture and implementation

  1. chaind extensions. From a first look, chaind is a solid base for this project. My current inclination is to extend it to do in-process ETL as well. This is largely motivated by Adrian Sutton's blog post, which requires complex SQL for attestation handling notably. The resulting database will be far easier to use this way. This can use the summarizer module that was added to chaind a few months after Adrian's post. While the goal will be to upstream these changes; we will maintain a public fork until/if they are merged.
  2. The database will likely be a public dataset in BigQuery. It should contain all the tables in tables.md, as well as any additional ETL'd tables and fields.
Select a repo