feat: Migrate SP1Helios

[tbwebb22]

This PR adds the SP1Helios contract, tests, and a Foundry deployment script. The deployment script downloads the appropriate genesis binary from our sp1-helios GitHub releases (detecting macOS vs Linux automatically), verifies the calculated binary checksum against checksums.json, and runs it to generate the initial light client configuration, and then deploys the SP1Helios contract with those parameters.

A new script/universal folder is added here that includes a readme on the full deployment process of SP1Helios & UniversalSpokePool to a new chain.

@bmzig @pxrl when you get a chance, please give a test run through the deployment process outlined in the new readme and lmk if there are any gaps in the described process.

[socket-security]

Warning

Review the following alerts detected in dependencies.

According to your organization's Security Policy, it is recommended to resolve "Warn" alerts. Learn more about Socket for GitHub.

Action	Severity	Alert  (click "▶" to expand/collapse)
Warn		Obfuscated code: npm safer-buffer is 94.0% likely obfuscated Confidence: 0.94 Location: Package overview From: ? → npm/safer-buffer@2.1.2 ℹ Read more on: This package | This alert | What is obfuscated code? Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at support@socket.dev. Suggestion: Packages should not obfuscate their code. Consider not using packages with obfuscated code. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment @SocketSecurity ignore npm/safer-buffer@2.1.2. You can also ignore all packages with @SocketSecurity ignore-all. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.

View full report

[grasphoper]

2 comments on this:

1. This README seems very long and goes into a lot of details about the internals. Do you think we can make this shorter? Think about the dev. who's going to be deploying the system. They want a succinct README they can follow. Also, about the checklist after deployment. Unless that is exhaustive and 100% up-to-date, we shouldn't keep it. "Trust" in a file like this is very important for it to be used properly. We need to make sure it doesn't include details that are redundant / extra / 80% correct
2. Now that we have the SP1Helios contract and deployment script in the contracts repo, do you think it's possible to create a single script that will deploy the full Universal stack for a chain via a single command? Totally fine to do it in a follow-up. We might even complete that script with additional helper commands, like the update-vkey command that would generate a multisig multicall TX to send all of the admin acitons to the target universal spokes(just an idea, the single-deploy script is more important)

[tbwebb22]

1. Yep totally agree, signficantly simplified the readme here: b5282de
2. For sure, definitely should be possible. I'll build a script for this in a followup PR

[grasphoper]

Left a few comments

[socket-security]

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff	Package	Supply Chain Security	Vulnerability	Quality	Maintenance	License
	yargs@​17.7.2

View full report

[grasphoper]

LGTM. Let's hope no downstream repo relies on Helios naming 😄
Ideally all of them should be using UniversalSpokePool.helios() call to find the "true current helios" but you never know