DApp Deployment: GitHub, Filecoin, Safe & ENS Integration

by SLV Team 58 views
DApp Deployment Automation: GitHub, Filecoin Pin, Safe Multisig, and ENS

Hey guys! Let's dive into an automated dApp deployment system that's triggered by Git commits. This system leverages GitHub Actions to upload new dApp versions to IPFS via Filecoin Pin. But that's not all! It also creates a Safe multi-sig proposal to update the ENS contenthash. This ensures a secure and decentralized deployment process. We will explore the components, triggers, and workflow of this innovative system, focusing on how it enhances dApp deployment security and efficiency. This approach not only streamlines the development pipeline but also integrates robust security measures through multi-signature approvals.

What We're Building: Automated dApp Deployment

The core idea here is to build an automated dApp deployment system that kicks into action whenever a developer pushes updates to the repository. Imagine this: you make a change, push it, and bam! The system takes over. GitHub Actions steps in to automatically upload the new version to IPFS using Filecoin Pin. This ensures your dApp is stored in a decentralized manner, making it resilient to censorship and single points of failure.

But we're not stopping there. To ensure security and control, the system then creates a Safe multi-sig proposal. This proposal suggests updating the ENS contenthash, which is essentially the pointer to your dApp's latest version. This means that instead of a single entity updating the dApp's address, a group of signers (as defined in your Safe setup) needs to approve the change. This adds a crucial layer of security, preventing unauthorized updates and ensuring that only vetted changes go live.

You can check out the reference implementation here: https://github.com/FIL-Builders/filecoin-pin-ens-demo. The target repository for this integration is https://github.com/safe-global/safe-wallet-monorepo. By integrating these technologies, the system not only automates deployments but also enhances the overall security and reliability of dApp updates. This approach marks a significant step forward in how decentralized applications are managed and deployed, blending efficiency with top-tier security protocols.

The Trigger: Git Push Event

The magic starts when a developer commits and pushes dApp updates to the main branch. Think of this as the green light for the entire process. This event is the trigger that sets off a chain reaction, initiating the automated deployment sequence. It’s a seamless integration that aligns perfectly with the development workflow, ensuring that updates are handled promptly and efficiently.

Upon detecting this push, a GitHub Actions workflow springs into action. This workflow is pre-configured to execute a series of steps that automate the deployment process. First, it builds the updated dApp. This involves compiling the code, bundling assets, and preparing everything for deployment. The result is a deployable artifact, which is then ready for the next stage.

Next, the workflow uploads this artifact to IPFS (InterPlanetary File System) via Filecoin Pin. IPFS is a decentralized storage network that ensures your dApp is hosted in a resilient and censorship-resistant manner. Filecoin Pin, in this context, provides a reliable way to keep the dApp's data available on IPFS. This step is crucial for maintaining the decentralized nature of the application.

Finally, the workflow doesn't just stop at deployment. It goes a step further by creating a Safe proposal containing the new CID (Content Identifier). This proposal is sent to the Safe multi-signature wallet, requiring a threshold of approvals before the update can be applied. This multi-sig approval process is a key security feature, ensuring that only authorized changes make it to the live dApp. The Safe signers receive this proposal and can review the changes before approving, adding an essential layer of human oversight to the automated process.

Current Demo Flow (Single Wallet)

Let’s break down the current demo flow, which uses a single wallet for ENS updates. This will help us understand the contrast with the new multi-sig approach. In the existing setup, the process is more streamlined but less secure. It’s like having a single key to the kingdom versus a vault with multiple locks.

Here’s how it works:

  1. Developer Pushes to Main Branch: The journey begins when a developer pushes their code changes to the main branch of the repository. This is the initial trigger, the same as in the new flow.
  2. .github/workflows/build-site.yml (Triggered on Push): This workflow file is automatically triggered by the push event. Its primary job is to build the dApp. It takes the latest code, compiles it, and creates an artifact named site-dist. Think of site-dist as the ready-to-deploy package of your dApp.
  3. .github/workflows/upload-to-filecoin-and-update-ens.yml (workflow_run trigger): Once the site-dist artifact is ready, this workflow kicks in. It’s triggered by the successful completion of the build workflow.
  4. Download site-dist Artifact: The first thing this workflow does is download the site-dist artifact, which contains the compiled dApp.
  5. filecoin-project/filecoin-pin/upload-action@v0.9.2 → CID: This step is where the magic of decentralized storage happens. The workflow uses the filecoin-pin action to upload the site-dist artifact to IPFS. This action returns a CID, which is a unique identifier for the uploaded content on IPFS. The CID is like the address of your dApp on the decentralized web.
  6. scripts/update-ens.mjs: This script is responsible for updating the ENS (Ethereum Name Service) record with the new CID. ENS is like the DNS of the decentralized world, mapping human-readable names (like my-dapp.eth) to blockchain addresses or, in this case, IPFS CIDs.
  7. wallet.sendTransaction(resolver.setContenthash()): Inside the update-ens.mjs script, a transaction is sent to the Ethereum network to update the ENS resolver. This transaction calls the setContenthash() function, which associates the new CID with the ENS name. This step is crucial for pointing the ENS domain to the latest version of the dApp.
  8. ENS Contenthash Updated Immediately: The final result is that the ENS contenthash is updated immediately after the transaction is confirmed on the blockchain. This means that anyone accessing the dApp through its ENS name will now be directed to the new version.

The key takeaway here is the immediate update of the ENS contenthash. While this is efficient, it also means that any compromised wallet or script could potentially update the dApp to a malicious version. This is where the new flow with Safe multi-sig comes in to add a layer of security.

New Flow (Safe Multi-Sig): Enhanced Security

Now, let’s explore the new flow, which incorporates a Safe multi-sig for enhanced security. This approach is like adding a security team to the deployment process, ensuring that no single point of failure can compromise the dApp. It's a significant upgrade from the single-wallet approach, offering a robust layer of protection against unauthorized updates.

Here’s a detailed breakdown of the new flow:

  1. Developer Pushes dApp Updates to Main Branch: Just like in the previous flow, the process starts when a developer commits and pushes updates to the main branch. This action triggers the automated deployment sequence.
  2. .github/workflows/build-site.yml (Triggered on Push): This workflow remains the same as in the single-wallet flow. It builds the dApp and creates the site-dist artifact, which is the deployable package.
  3. .github/workflows/upload-to-filecoin-and-update-ens.yml (workflow_run trigger): This workflow is also triggered by the successful completion of the build workflow. However, it includes some crucial changes to enhance security.
  4. Download site-dist Artifact: The workflow downloads the site-dist artifact, just as in the previous flow.
  5. filecoin-pin action → CID (keep existing): This step uploads the site-dist artifact to IPFS using the filecoin-pin action. However, a key difference is that it aims to keep the existing CID if possible. This is an optimization to avoid unnecessary changes to the ENS record.
  6. scripts/verify-ipfs-gateway.mjs (NEW - verify accessibility): This is a new and critical step in the process. Before creating a Safe proposal, the workflow verifies that the uploaded content is accessible via common IPFS gateways. This ensures that users can actually access the new version of the dApp.
    • Try ipfs.io, gateway.ipfs.io, dweb.link: The script attempts to access the content via these well-known IPFS gateways.
    • Retry up to 10 times with 6s delays: To account for potential network hiccups, the script retries the access attempts up to 10 times, with a 6-second delay between each attempt. This adds resilience to the verification process.
    • Exit 1 if inaccessible → workflow fails: If the content remains inaccessible after all retries, the script exits with an error, causing the workflow to fail. This prevents the creation of a Safe proposal for a potentially broken deployment.
  7. scripts/create-safe-proposal.mjs (NEW - replaces update-ens.mjs): This script replaces the update-ens.mjs script from the single-wallet flow. Instead of directly updating the ENS record, it creates a Safe proposal.
    • Safe API: propose resolver.setContenthash() transaction: The script uses the Safe API to propose a transaction that updates the ENS resolver with the new CID. This transaction requires approval from the Safe signers before it can be executed.
  8. Safe signers review and approve in Safe UI: The Safe signers receive the proposal in the Safe UI. They can review the proposed changes, including the new CID, and test the CID at https://ipfs.io/ipfs/{CID} to verify the new deployment.
  9. Signers can test CID at https://ipfs.io/ipfs/{CID}****: This step allows signers to manually verify that the new version of the dApp is accessible and functioning correctly before approving the proposal.
  10. Safe executes transaction when threshold met: Once the required number of signers have approved the proposal, the Safe executes the transaction, updating the ENS contenthash.
  11. ENS Contenthash Updated: Finally, the ENS contenthash is updated, pointing the ENS domain to the latest version of the dApp. This update is now secured by the multi-sig approval process, significantly reducing the risk of unauthorized changes.

The key changes in this new flow are the addition of gateway verification and the replacement of direct ENS updates with a Safe multi-sig proposal. These changes introduce a robust security layer, ensuring that only verified and approved deployments make it to the live dApp.

Key Changes Summarized

Let's recap the key changes in the new flow compared to the single-wallet approach. These changes are all about enhancing security and reliability in the dApp deployment process.

  1. Add Gateway Verification Before Safe Proposal:

    • In the new flow, before a Safe proposal is created, the system verifies that the uploaded content is accessible via common IPFS gateways. This step is crucial to ensure that the dApp is reachable by users after the deployment.
    • The scripts/verify-ipfs-gateway.mjs script plays a vital role here. It attempts to access the content through gateways like ipfs.io, gateway.ipfs.io, and dweb.link. The script retries up to 10 times with 6-second delays to account for potential network issues.
    • If the content is inaccessible after these attempts, the script exits with an error, and the workflow fails. This prevents the creation of a Safe proposal for a potentially broken deployment, saving time and resources.

  2. Replace update-ens.mjs with create-safe-proposal.mjs:

    • The old flow used update-ens.mjs to directly update the ENS contenthash. This meant that the update was immediate but also lacked a review process, posing a security risk.
    • The new flow replaces this script with create-safe-proposal.mjs. Instead of directly updating the ENS record, this script creates a Safe proposal. This proposal includes a transaction that, when executed, will update the ENS contenthash.
    • The use of a Safe proposal introduces a multi-signature approval process, adding a critical layer of security. It ensures that updates are reviewed and approved by a quorum of signers before they go live.

  3. ENS Update Requires Multi-Sig Approval Instead of Immediate Update:

    • In the single-wallet flow, the ENS contenthash was updated immediately after the transaction was sent. While this was efficient, it also meant that any compromise in the deployment process could lead to a malicious update.
    • With the new flow, the ENS update requires approval from the Safe signers. This multi-sig approval process is a significant security enhancement. It ensures that a threshold of signers must agree on the update before it is applied.
    • Safe signers can review the proposed changes in the Safe UI, including the new CID. They can also manually test the CID to verify the deployment before giving their approval. This human review process adds a layer of trust and security.

By implementing these changes, the new flow significantly improves the security and reliability of dApp deployments. It ensures that updates are verified, reviewed, and approved by multiple parties before they are applied, reducing the risk of unauthorized or malicious changes. This approach aligns with best practices for secure decentralized application management.