Ruby One V2
  • Ruby One V2 - Your Complete Ruby One Wallet Guide
  • General Introduction
    • Vision of Ruby One
    • What is Ruby One V2?
    • What is MPC technology?
    • Is MPC technology secure?
    • What are the benefits of MPC technology?
  • Why Use Ruby One
    • High-Security Wallet Access Through MPC
    • Contract Accounts for Secure and User-Friendly Blockchain Interaction
    • Third-Party DApp Integration with the Ruby DApp Bridge
    • Bridging the Web2-Web3 Gap
  • Tech Introduction
    • MPC-Secret Sharing
    • MPC-Threshold Signature Scheme
    • Social Recovery - DKIM
    • Contract Account Dynamic Upgrade
    • DApp Bridge
    • Ruby One V2 Upgrade Log
  • How to Use Ruby One V2
    • Launch App
    • Sign Up
    • Login Via Google
    • Login Via Email
    • Set Local Password
    • Backup Key Fragments
    • Three Test Networks
    • Send & Receive Crypto
    • Social Recovery Your Account
    • Sign Out & Clear Data
  • Term of Use
    • Welcome to Ruby Protocol
    • About the Website
    • Intellectual Property
    • Acceptable Use of the Website
    • Wallet Address, Private Key, and Backup Capabilities
    • Accuracy of Information Provided by User
    • Your Use of Ruby’s Services
    • Privacy Policies
    • Disclosure of Information
    • Changes and Availability
    • Contacting us via the Website
    • Age Restriction and Eligibility
    • Disclaimer of Warranty
    • Limitation of Liability
    • Changes to the Terms
    • Contact Us
  • Ruby One - MPC Wallet
Powered by GitBook
On this page
  1. Tech Introduction

Contract Account Dynamic Upgrade

As we all know, Ethereum smart contracts do not inherently support upgrading or modifying the contract's code once deployed. This is because one of the key features of blockchain, and Ethereum in particular, is the immutability of the contract code once it is deployed on the blockchain. Obviously, this is not good news for us to do abstract accounts.

We are compatible with ERC-4337, but there may be situations similar to onERC721Received in the future, so we need to add the ability to upgrade our AA dynamically.

We designed a plug-in mechanism for adding plug-ins to AA.

The first to bear the brunt is Plug-in Registry and Wallet Factory. Wallet Factory is used to create AA, and Plug-in Registry is used to register plug-ins. When the Contract Account created by Wallet Factory cannot find the corresponding interface, it will find the corresponding plug-in through the Plug-in Registry. In addition, we also allow AA to register its own separate Plug-in.

Since we have the Plug-in mechanism, we can upgrade the contract dynamically. We believe this is a huge step forward for AA.

PreviousSocial Recovery - DKIMNextDApp Bridge

Last updated 1 year ago