Ethereum’s ERC-4337 and What Does it Mean for Ruby Protocol?

Making The Best of ERC-4337 to Redefine Web3 User Experience

Ruby Protocol
5 min readJul 28, 2023

Let us begin this post by stating that the ERC-4337 standard is one of the most innovative ERC standards to date. If you dive deep into it, it is not hard to come to the conclusion that the ERC-4337 standard, just like its many preceding Ethereum standards, will likely help Ethereum remain one of the most used and most developed blockchains as the enhanced functionality and user-friendliness will benefit all of the connected niches within the broader Ethereum ecosystem.

Well, in this post, we will, as always, cut the convoluted technicalities and try to illustrate what ERC-4337 is, what Account Abstraction means, what it will do to crypto, and how it can push Ruby Protocol to a different trajectory.

What is ERC-4337?

Simply said, it’s a series of proposals trying to improve the user experience of Ethereum-based applications and make them accessible to more non-crypto-savvy users.

At its core, ERC-4337 introduces a higher-layer pseudo-transaction object called a UserOperation (you may consider this as an operating environment where you are enabled to do certain things), which allows users to use smart contract wallets containing arbitrary verification logic (it can support multi-sig and any signature scheme, which is an advantage over an EOA) instead of externally owned accounts (EOAs) as their primary account.

Key takeaway: code defines what contract accounts can do while the user defines what an EOA can do.

This new approach completely avoids the need for consensus-layer protocol changes and offers a range of benefits, including the ability to achieve account abstraction (more on this later), decentralization, and the ability to support other use cases like privacy-preserving applications, atomic multi-operations, and sponsored transaction use cases.

If fully implemented, it will allow users and developers to customize how they want to design and use their accounts.

ERC-4337 vs Account Abstraction

Although ERC-4377 has its significance, allowing users to execute functions and have more flexibility over how transaction fees are processed, it does not achieve true account abstraction.

Vitalik Buterin stated, “The big really valuable, and necessary thing that ERC-4337 provides for account abstraction is a decentralized fee market for user operations going into smart contract wallets.”

Unlike true account abstraction, ERC-4337 functions more as a transaction relayer, offering an off-chain order book for organizing transactions before relaying them to the blockchain.

True account abstraction envisions a broader transformation in how Externally Owned Accounts (EOAs) interact with the Ethereum blockchain. Achieving this level of abstraction necessitates a significant upgrade to Ethereum’s entire consensus mechanism, a difficult task that is beyond the scope of ERC-4337.

While other EIPs for account abstraction had already been published, they required some protocol changes in the consensus layer. ERC-4337 aims to provide account abstraction without requiring any changes to the consensus layer. It is an important step in the right direction.

What does it mean for Ruby Protocol?

Those who follow Ruby Protocol closely know we are en route to build a set of products that aim to render the crypto user experience seamless and effortless. If bad user experience has resulted in countless cases of lost and stolen seed phrases, misplaced private keys, and a huge mental load for new users in crypto, the whole crypto community will likely face a stark future.

Our live products now include Ruby One, an MPC wallet that aims to deliver users the most user-friendly wallet experience; Ruby Connect, a private payment method that offers the most private way to send and receive crypto; and finally, Ruby SDK, a lite, efficient, and privacy-centric developer tool for whoever is interested in rebuilding Web3.

There was no clear standard for developers to build custom user accounts in a truly decentralized and secure manner until EIP-4337 was implemented and became the ERC-4337 standard.

ERC-4337, fortunately, is a new approach for us to improve the wallet user experience on Ethereum today. Account Abstraction functions as a “smart contracts wallet,” allowing users to interact with the Ethereum network without having their own private keys or having to keep Ether on hand for transaction costs.

In the coming months, we will initiate a number of technical developments based on Ethereum’s ERC-4337 standard, which includes but not limited to the followings:

  • Build a “smart contract account system and gradually move toward Account Abstraction
  • Refine the existing social recovery methods and eradicate the risk of losing private keys
  • Improve user experience by enabling seedless wallet creation
  • Start connecting DeFi, Games, and DAO to sponsor users and achieve Gasless transactions

The implementation of ERC-4337 in the Ethereum ecosystem and the introduction of account abstraction are significant milestones in the evolution of blockchain technology.

It enables us to create smart accounts to provide improved functionality, a streamlined user experience, enhanced security, and quantum-resistant cryptography. Although ERC-4337 does not achieve complete account abstraction, it does introduce a number of features that could significantly improve user experience and pave the way for widespread adoption.

About Us

Ruby Protocol is a privacy centric access control protocol, building an interoperable, scalable and privacy-preserving infrastructure as the ultimate gateway to Web3.

Our solutions and products include a private payment bridge (Ruby Connect), MPC wallet (Ruby One), and Account Abstraction & Access Control developer tools (Ruby SDK), with more to come.

Contact

Telegram | Discord | Twitter | Github | Email

--

--

Ruby Protocol
Ruby Protocol

Written by Ruby Protocol

Building a programmable privacy & access control middleware framework encrypted with zero-knowledge proofs (zkp) algorithms.

No responses yet