KLYNTAR Virtual Machines. Part 2: Account abstraction 2.0
Preface
Hello everybody 👋👋👋
After a break, we are finally bringing our blog back to life!
A lot of work has been done recently, the project has acquired many improvements and we are happy to tell you about this in a series of articles that will now be published on a regular basis.
Enjoy reading 😄
Intro
While working on the project, we wanted to implement and add to it all those features that we ourselves lacked when interacting with other existing projects — Ethereum, Solana, TON, Avalanche, Near and others.
In an effort to improve the user experience when interacting with our network, as well as to open up new opportunities for DApps (DEXes, landing protocols, NFT marketplaces, etc.), we decided to radically change the classic course of transactions in the cryptocurrency network.
Further in the article you will learn about account abstraction 2.0 — what it is, why it was created and what new opportunities it offers.
Origins
Co-authored by Vitalik Buterin (@vbuterin), Yoav Weiss (@yoavw), Dror Tirosh (@drortirosh), Shahaf Nacson (@shahafn), Alex Forshtat (@forshtat), Kristof Gazso (@kristofgazso), Tjaden Hess (@tjade273), ERC-4337 introduces account abstraction which, in short, allows transactions with some improvements, for example:
- Fees in ERC-20
- Custom signature schemes
- Sponsored transactions
And some other improvements. Find out more in the Ethereum EIPs tracker.
Let’s finally figure out what prompted us to create v2 account abstraction on KLY.
Nativeness
Classic EIP was designed with the emphasis that the forkless path would be chosen. That is, backward compatibility will be maintained and no changes will be made to the virtual machine level.
It is this problem that gives rise to the complexity of EIP-4337. Just take a look at the diagram:
With this architecture, 2 actors are added to the system — a bundler and a paymaster.
This makes things more difficult for you as a user and for smart contract developers.
In addition, you need to pay additional fees — for example, for using tokens as a fee when you do not have the network’s native coins. The bundler also receives part of the fees for the performance of its services.
But don’t you want to simplify everything?)
In our network, everything comes down to a single smart contract that is responsible for all the logic of the transaction. Besides:
No bundlers, no extra fees, no need in native currency at all and complicated logic — just straightforward logic, full decentralization and control
High level explanation
To make everything as simple as possible, we introduce only 1 step between you and the transaction — this is a paymaster smart contract that you bind to your account and the logic of which will be called when the network tries to get a fee from you
- As you can see, the entire transaction life cycle logic is programmed in one contract
- When a user (Account1 in this case) sends a transaction, the network takes from the binding table the address of the contract that will pay for gas (ContractA in this case) and checks how many funds can be withdrawn in order to limit the gas limit for this transaction
- After completing a transaction (be it a regular transaction or calling a contract), the logic is launched that will pay the network a fee
In this smart contract it will be possible to describe a variety of logic, for example:
- Program the logic for distributing fees — send the full fee to the block creator, send part to charities, distribute rewards between several validators and much more!
- Program the logic for paying for different parts of the transaction in different currencies(tokens). For example, like this in the diagram
In technical terms, the paymaster’s smart contract will be able to receive various transaction details from the network via the API — its call stack, raw transaction object, access to logs, and so on.
Based on this data, you will be able, for example, to pay part of the commissions in stablecoins, part — in wrapped tokens (or NFTs in general), and part of the gas will be forgiven to you thanks to the system of subscriptions and boosts (more on this later)
No need in native currency — at all
Whether in EIP-4337 or in RIP-7560, the problem remains that in any case the actors (bundler and paymaster in EIP-4337 and paymaster in RIP-7560) you need to have the native currency of the network, which will be paid to validators as a commission.
Account Abstraction 2.0 proposed by the KLY project removes the need for a native currency altogether. That is, not only you no longer need to own the native currency of the network, but also the paymaster.
Instead, validators will be paid a commission directly into the account — in stablecoins, wrapped assets, ERC-X tokens, and so on.
We consider this innovation extremely important and are glad that you will be able to put it into practice)
The first L1 XVM with account abstraction support
Account abstraction support has started to gain popularity in EVM networks, but the situation is a little worse with WASM-compatible virtual machines.
We are pleased to announce that KLYNTAR will become:
The first XVM with improved account abstraction support!
Here is the high level architecture of XVM
The account abstraction 2.0 in KLY will extend to both virtual machines and even have support for bi-directional cross-VMs calls. This will allow you, for example, to pay in smart contract tokens on EVM (for example USDT) when working with smart contracts inside WASM.
Summary
It’s time for a conclusion.
Working on our project, we want to give you the highest quality user experience, as well as make innovations for the crypto industry.
We hope that you, as a user and/or developer, can learn about the benefits of our features from your own experience.
We will be releasing many articles about the project and the ecosystem — so stay tuned and see you soon! 😊😊😊
