Klaster is a blockchain protocol aimed at providing superior blockchain user experience through advanced network abstraction technology. This document aims to provide a high-level overview on how Klaster would achieve this functionality, as well as provide a glimpse into the user experince of blockchain, with a production version of Klaster available.
The name for Klaster protocol comes from the word "cluster", as in "computer cluster" - which is usually defined as "a set of computers that work together so that they can be viewed as a single system". This is the end goal of Klaster, but for blockchains - to enable multiple, independent blockchain networks to work as a single system.
Some of the key outcomes of Klaster protocol & SDK which we will discuss in thsi document are:
- Paying for transactions with a single token, no matter which network the transaction is being executed on.
- Paying for transactions with stablecoins.
- Contracts owning "remote accounts" on blockchains they're not deployed to
- Synchronizing state of independent blockchains through Chainlink CCIP
The core of how Klaster achieves the goals set in the beginning of this documnet is by splitting blockchain accounts into two distinct categories - Controller Accounts & Worker Accounts. The Controller Accounts are Smart Account Wallets (Smart Contracts) which have the authority to control one or more Worker Accounts across multiple blockchains.
The structure of Controller / Worker Accounts is illustrated below.
The way the Controller / Worker dynamic is achieved is through the use of singleton smart contracts, deployed on all supported blockchain networks. These singleton smart contracts are the
owners of all worker accounts on deployed blockchains. Being an "owner" of the Worker Accounts gives the signleton contracts a single privilege - to invoke the execute() function on the
Worker Accounts.
The execute() function accepts blockchain transaction data as an input parameter and triggers the Worker Account to call a certain smart contract or execute any other blockchain action. Only the singleton contract can call the excute() function.
However, before the singleton contract will call the execute() function, it must perform certain checks. Each Worker Account has an associated Transaction Ruleset smart contract. This smart
contract defines the terms by which the Worker Account executes the transactions. The Transaction Ruleset contract is synchronized across all blockchains and controlled by the Controller Account.
Synchronizing the Transaction Ruleset across blockchains is done by invoking arbitrary message calls with Chainlink CCIP.
The Klaster singleton contracts on all blockchains have a public execute() function on them. This entire system allows a user to execute a transaction by simply signing an offchain message. How?
This is where the concept of Agents appears. An Agent, in the Klaster system - can be anyone. For a transaction to be executed on the Klaster network, the following order of operations happen:
- The user signs an off-chain message, containing the transaction data & the chain on which the message should be executed. Other conditions may be required, such as multiple signers, time delays, etc... These are defined in the Transaction Ruleset smart contract
- The user publishes the signed message to the Klaster Mempool
- An agent "picks up" the signed message & calls the public
execute()function on the Klaster Singleton contract - The Singleton contracts check the Worker Account for which the transaction is signed & runs the
validate()function on the associated Transaction Ruleset contract. If the contract returns false, the transaction is declined. - If the Transaction Ruleset contract returns true, the singleton contract calls the
execute()function on the Worker Account & the worker account executed the transaction.
Key points of this system:
- Liveness & Censorship Resistance - Since the
execute()function on the Klaster singleton contracts is public, it can be called by absolutely anyone. If the system is completely shut down, it can be called by the user themselves - ensuring liveness even in the worst case scenario. Similarily, if no Agent is willing to sign the message, the user can execute it themselves - ensuring censorship resistance. - Security - Since the Transaction Ruleset contract will verify some cryptographic truth (usually that the owner of the Controller Account has signed the message) the user is free to distribute the signed message on unsecure connections - as it can only ever result in the transaction they signed themselves.
The core premise of the Klaster protocol is that the Transaction Ruleset is the defining contract for each Worker Account which defines the cryptographic & other conditions for transactions to be executed. This means that the biggest security vulnerability of Klaster is the synchronization of the Transaction Ruleset contracts on all blockchains.
One example of a Klaster implementation (which is actually a product the Klaster team is working on).
Controller Account is a Gnosis Safe smart contract - deployed on Ethereum mainnet. It has three signers and a defined two out of three signer structure. This Controller Account controlles a Worker Account which is deployed on the same address on Ethereum, Optimism, Arbitrum, Base & BSC. The Transaction Ruleset contract for the Worker Account is set to be an exact copy of the Gnosis Safe validation function, which checks that two of three signers have signed the transaction data.
The users execute transactions by signing transaction data (e.g. send 20 USDC on Arbitrum from Worker Account to some other address). An Agent picks up this signed transaction data from the
Klaster mempool and calls the execute() function on the Arbitrum Klaster singleton. The Arbitrum Klaster singleton passes the signed transaction data through the Transaction Ruleset contract
associated with the Worker Account which is being invoked. The Transaction Ruleset contract verifies that at least two of the three signers have signed the off-chain message. It allows the
transaction to proceed & the Klaster Arbitrum Singleton calls the execute() function on the Arbitrum Worker Account.
This works perfectly well, while the signers remain the same. However, when deploying the contract for the first time or when changing the signers, we need to ensure a way for the Transaction Ruleset to change, without forcing the user to execute transactions on multiple blockchains. We can't allow Agents to change the Transaction Ruleset contract, since their functions use that same Transaction Ruleset contract to validate the transactions.
However, what we can do - is leverage a cross-chain communication protocol to pass a validated message from the Controller Account on Ethereum Mainnet, that a Transaction Ruleset change is needed. Our security model, in that case, moves from Agents to (in the case of Klaster) - Chainlink CCIP.
The process is simple - the signers sign & execute a messsage on the Ethereum mainnet, which is then propagated by CCIP through the Klaster Transaction Ruleset destination contracts.
Everything described here was for executing "single chain tranasations" - transactions which change the state of only one chain. Irrespective of the fact that the Controller Account is not deployed on the chain on which we wish to execute our transaction, the transaction itself will only change the state of one blockchain network.
For cross-chain transactions, which need to rely on message-passing between blockchains, the Klaster protocol elegantly falls-back onto Chainlink CCIP. A transaction requrest is flagged as
cross-chain & signed as such and the Klaster Agent executes the crossChainExecute() function on the Klaster signleton contract on the source chain, with all the required info for a cross-chain
transaction.
The Klaster system is tightly integrated with Chainlink CCIP so it intelligently executes this transaction as a cross-chain transaction, without any additional input from the user. The only difference being, that the transaction (in this case) will take longer to execute - as CCIP needs to wait for the finality of the source chain to execute the transaction on the destination chain.
Klaster Worker Accounts act just the same as any other Smart Account or Account Abstraction Wallet and should be compatible with the entire EVM (and potentially non-EVM) ecosystem.
In fact, the first version of the Klaster protocol, has no Agents or Transaction Rulesets. It only has Controller Accounts & Worker Accounts and relays every single message through CCIP. This makes it slower & more expensive than the V2, but has the added benefit of significantly reduced engineering complexity.
The V1 of the Klaster protocol is live on Ethereum, Polygon, Optimism, Arbitrum, Base, BSC and Avalanche C-Chain.
You can use it and read the docs here: https://klaster.gitbook.io/gateway/introduction/overview
The first product built on the Klaster V1 platform is live already and you can access it at: https://safe.klaster.io - it's a Gnosis Safe extension, which allows users to have cross-chain Safes. Klaster V2 will make this app faster and cheaper as well as add CCIP powered cross-chain swaps.