oDAO Membership Interest - Patches

[Patches]

After Mav called for interested parties to “throw their hat in the ring”, I’ve decided to put myself forward for consideration to run an oDAO node. I’m going to borrow the interview questions from Wander (whose candidacy I support!)

---

What is your history of involvement with Rocket Pool?

Most of you probably know me well already, but in brief:

I started following Rocket Pool’s development before the prater betas in 2021 and joined the community in September. I run a Rocket Pool node and have staked from home since November. In March the team assigned me the Rocket Scientist role with encouragement from the community.

Since joining, I have contributed as much to the community as I can manage. Some highlights:

• Almost 15k messages in #support, the vast majority of which have been helping Node Operators in whatever ways I am able.
• Assumed responsibility for the administration and development of faucet-bot, which dispenses Goerli and Ropsten ETH in #faucet.
• Contributed a smattering of commits to rocket-watch, smartnode, the docs.rocketpool.net repositories, and to Ken’s encryption guides.
• Wrote and maintained a list of supplemental guides for Node Operators.
• Optimized the smartnode vanity miner, and then wrote a stand-alone vanity miner with even more performance gains.
• Worked with @hanniabu and others to flesh out https://rocketpool.support
• Wrote a script to audit the guardian wallet’s activities during deploy to help dispel some concerns from Maker governance.
• Identified medium-to-high priority bugs in smartnode, or pathological dependency interactions with smartnode (such as the infamous snap docker runtime issue).

What do you see as the oDAO’s role in the protocol?

The most immediately obvious role is the most utilitarian one- the oDAO submits balance and price data to the execution layer for use by the stack of Rocket Pool contracts. While this functionality is automated, it’s my view that oDAO node operators should treat this work as an on-call rotation, and ensure that it is reliably completed, even if it means sacrificing some sleep now and then.

Beyond that, the oDAO is responsible for making proposals related to certain internal levers such as the length of the scrub period, and adjusting its own parameters by proposing to invite or expel other oDAO members or adjust the bond size. My approach to these decisions will be to prioritize the health and growth of the network and the platform above other concerns. I’m currently in favor of ongoing discussions to reexamine the inflation distribution. I hold the opinion that oDAO members should be compensated beyond just gas reimbursement, as participating in the oDAO constitutes a certain amount of skilled labor, but that the current compensation may prove to be on the high side. I’d like to see the team’s income decoupled from their participation in the oDAO, so that the topic of oDAO compensation can be independently addressed.

Ultimately I believe the oDAO should pursue the means to render itself redundant, though given the current platform design, I understand this may not be achievable in the near term.

What are your priorities for Rocket Pool?

I don’t think it is the role of the oDAO nor pDAO to try and prioritize the development team’s backlog. That said, their current priorities around the upcoming merge feel correctly triaged. In a more steady state I’d like to see pDAO bootstrap disabled as soon as convenient, but with security and stability prioritized. We’re at a weird point in history at the moment where rEth demand and node operator supply have suddenly swapped from too high / too low respectively to too low / too high, but I don’t think that will be the case indefinitely, and am supportive of short term efforts to improve rEth demand and longer term efforts to scale node operator supply, e.g., through the SaaS work and collateral revisions that are ongoing. I believe Rocket Pool’s growth has only just begun, but also believe we should aim to capture as much of the staking market as we can without damaging the security of Ethereum, and no more.

How do you secure your node and keys?

I currently run a node on hardware in my apartment, and use Ken’s hardware security key guide to protect they keys, as well as all the standard security tools that the guides outline (2fa, ssh keys, ufw). If selected, I would likely keep the oDAO node at a mid-sized collocation facility with a focus on security and uptime guarantees, and expand my security posture to include things like network intrusion detection systems and physical two-factor authentication providers. I wouldn’t run anything co-tenant on the instance, and only use open source software with verifiable security practices.

The colocation facility will be able to provide better uptime guarantees than my home internet, which is just fast enough to run a node, and allow me to have a fallback in place, which is not something I have bothered with for my home staking node.

Can you disclose your identity publicly for the purpose of accountability?

I have been onymous from pretty much day one of my involvement in Rocket Pool. My name is Jacob Shufro; I’m an engineer with over 10 years of industry experience and the official title of ‘Staff Software Engineer’. I work at a crash data aggregation and analytics company. My background has traditionally focused on developing and maintaining low-latency, high-throughput, real-time systems in C, with a bit of additional experience in the fields of embedded software and cloud-based distributed systems. In my free time I make pizza and foster cats with a rescue organization.

[Wander]

So glad you decided to throw your hat in, too, @Patches!

Patches has gone far above and beyond as a positive contributor to the RP ecosystem and is an excellent choice. I wholeheartedly support him as an oDAO member, as well.

[Assunzio]

@Patches represents the type of person that we want as involved as much as possible in the RPL ecosystem. He’s technically knowledgable, personable, positive, and always available and contributing in Discord support to help technical and non-technical people. I believe his addition would strengthen the oDAO team and greatly benefit us long term. I would support his membership application.

[astoneta]

i strongly support you as an odao member Patches.

[scoot]

I am in complete support of Patches for oDao. His contribution to the project and community is immense.

[Ments]

Wholeheartedly support Patches in becoming an oDAO member. His dedication and commitment to Rocket Pool is phenomenal in the work and time he has put in helping others.

[Patches]

Given the additional oDAO responsibilities in redstone, I’d like to add that I’d be happy to run an archive node.

[Patches]

Hello again.

A lot has happened since I wrote this post, and much of it has better informed my view of the responsibility of the oDAO and its members’ roles within the ecosystem. I figured I’d post a quick update on what my priorities are for the oDAO.

Note that I am a member of the Rocket Scientists, who have an oDAO seat operated by Ken, but am still interested in operating an oDAO node myself.

• First, to improve our ability to detect bugs, I’d like to build a custom watchtower implementation, with its own suite of tests. This would probably require a formal specification of watchtower duties, similar to Joe’s treegen specification, to truly be a “clean room” alternative.
• Second, I’d like to implement treegen separately. In the interest of breaking up the work, custom watchtower would likely use stock treegen until stable.
• Once stable, I’d like to actually separate the treegen image from the watchtower image- oDAO members should be able to pick which watchtower and which treegen they would like to use independently

Unfortunately, two watchtowers is not much better than one watchtower in terms of consensus, though it does still help us identify bugs with either implementation. So once stable, I’d like to support the development of a third implementation of each of watchtower/treegen by a third party, and would work to encourage oDAO members to coordinate and ensure that no implementation accounts for 50%+ of the vote. This long-term goal would improve the consensus model for the oDAO, as well as the security (a supply chain attack would now have to successfully compromise a majority of software sources, instead of just one).

This work can be carried on to a larger conclusion- the implementation of an alternative smartnode stack- which would provide additional security to the pDAO as well.

My motivations here come from a perception that the team wants a robust oDAO, but isn’t positioned to improve these things themselves, as a second implementation of watchtower from the team itself would have diminished returns in terms of security and decentralization. Instead, the pDAO and oDAO should take the reins on these projects, so I have prioritized this work to start shortly after my responsibilities to the Rescue Node quiet down.

[Patches]

I apologize if it seems like I’m turning this post into a personal blog, but I figured I’d post an update on my priorities, since it has been about a quarter.

1. I put alt-watchtower on the backburner for a couple reasons, but mainly because oDAO constitution drafting took a priority (not that I contributed nearly as much time as @Valdorff but my time is increasingly fragmented), and because the result of the constitution are leaning towards eliminating duties from watchtower over time. I’d like to have a sense of what that will look like before I start implementing them.

2. I have been busy doing this-and-that for Rescue Node- getting the code into good shape to be reused by other protocols, researching methods for allowing solo stakers access, releasing the public metrics dashboard, adding Lodestar support, etc.

3. I have been busy with other activities, specifically helping multiple NOs whose node wallets were compromised re-secure their funds.

4. I probably spent a little too much time on sprocketpool, between optimizing Joe’s treegen implementation and setting up the infrastructure to run the site and generate preview trees 4x a day, building an API for rocketwatch to use, refactoring stand-alone treegen to produce predictable results, and generally just supporting Joe however I can in his tree related work.

At this point I have work to wrap up on all 4 of these bullets before I can start a large project:

1. oDAO constitution is nearing a final draft, hopefully that will pass votes and we can begin talking about which methods to remove duties will be implemented. Some duties will likely become socialized outside the oDAO, and I’d like to implement alternative tooling to participate in those duties, so this doesn’t necessarily reduce the scope of the work

2. I’m in the testing phase of a rescue-proxy refactor that splits out the Rocket Pool-specific logic into its own repository, allowing other protocols to build on the work we’ve already put in. I have a plan to support solo stakers based on signed messages from their 0x01 withdrawal address- either the message will need to contain the appropriate fee recipient, or the fee recipient will need to be the 0x01 address itself, or the solo staker will have to use mev-boost, otherwise we will be unable to prevent mev-theft in a satisfactory way.

3. Hopefully this stops happening . We could benefit from generalized tooling around building and submitting flashbots bundles, though. This would be a large project and not one I have time to seriously consider working on at the moment. I may submit a bounty, though I suspect Saturn will obsolesce the need to use flashbots in most cases.

4. I’m pleased to say that sprocketpool is nearly a completed project, in terms of features I wanted to implement. The last pieces- a bot command/ui to query the api for specific node rewards and grafana public dashboard support for template variables- are out of my hands, for the most part.

Anyway, as these are all side-projects for me, expect slow progress and an update in another several months