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).
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:
zed
, a searchable data lake for semi-structured data (Go
, https://github.com/brimdata/zed/graphs/contributors).The scope of this proposal is to deliver and operate a complete system meeting and exceeding the requirements of the RFP, and consisting of:
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.
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 ergonomicCustom 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/updatesNote 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
We propose to break down the bid into a development fee and a subsequent monthly operations and hosting fee.
For the development phase, we propose:
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.
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.
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).
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.