Billing Mechanism
Last updated
Last updated
On the user experience side, in simple terms, there is one extra step that requires users to take additional action which is the first time setup. After that, the overall method of utilizing kOS is relatively the same. However, it is important to understand how KRNL nodes look after the billing mechanism, and also how developers at KRNL Labs implement the EIP-7702 into the transactions.
Ethereum Improvement Proposals (EIPs) are standards specifying potential new features or processes for Ethereum. EIPs contain technical specifications for the proposed changes and act as the “source of truth” for the community. Network upgrades and application standards for Ethereum are discussed and developed through the EIP process.
source: Ethereum website - Introduction to Ethereum Improvement Proposals (EIPs)
EIP-7702 is a step towards account abstraction, enabling EOAs (Externally Owned Accounts) to have both code and storage.
This enhancement allows EOAs to function as smart contract accounts, unlocking new features such as:
Transaction batching
Gas sponsorship
Delegated actions - Granting other addresses limited access to act on behalf of the EOA
Implementing EIP-7702 requires first time setup from the EOA to be able to utilize new features as the previous section has mentioned. The given diagram shows brief steps of how first time setup would occur.
Firstly, the user must connect their wallet to the dApp. This process will follow the standard wallet connection procedure commonly used across dApps.
EOA will make a request to KRNL SDK which it will have to check if the that specific account has authorized EIP-7702 or not.
The authorization can be checked at this stage, in order to see whether the EOA is already approved the first time setup or not.
The reason why we put asterisk(*) is because this process would be triggered only if the EOA has not set the first time setup yet. If the EOA has already done the first time setup, this step would not occur.
At this step, EOA will be requested to authorize the Set Code Transaction. On the users side, they will have to approve this step through the wallet application that they use.
The function of executeKernels(...) can now be called to KRNL node, along with the authorization from the EOA.
Firstly, EOA will sign the execution request message using EIP-712, and will specify the following parameters.
functionParams
kernelParams
executionFee
nonce
It is worth mentioning that the nonce at this stage is not nonce in the transaction. This nonce is purposely used for kOS.
By utilizing KRNL SDK within the dApp, the function of executeKernels(...) can be performed.
From the dApp side, KRNL SDK will make a call to KRNL node. This means that the execution signature of functionParams, kernelParams, executionFee, and nonce from the previous step will be used, and will be sent to the KRNL node.
The required metadata of transaction through KRNL node such as smart contract ID, kernel ID(s), and also their details will be obtained from the registry smart contracts.
Furthermore, this process is orchestrated by KRNL node fetching information from dApp Registry using entry ID. Then, the KRNL node will be able to identify the smart contract ID, as well as the associated kernel ID(s) and its details from Smart Contract Registry and Kernel Registry.
There is also a registry that we use as a nonce manager to store used nonce from the earlier step.
KRNL node has to verify the execution signature which are functionParams, kernelParams, executionFee, and nonce that have been signed using EIP-712.
KRNL node will send a request to the list of predefined kernels by using GraphQL runtime engine with custom resolver. After every kernel execution is completed, the responses will be sent back to KRNL node to proceed to the next step.
The Attestor in the KRNL architecture serves as a safeguard, responsible for validating and ensuring the seamless execution of the entire transaction. At this process, it will then signs the execution results that the KRNL node obtains after execution of kernel(s). This makes certain that the paymaster in the upcoming step can eventually sign the transaction.
Next, the KRNL node will prepare the transaction, that will be called to smart contract account, including kernel responses and execution signature from earlier.
KRNL will be acting as the Paymaster and will bear the responsibility of sponsoring the transaction gas fees. The Paymaster is also responsible for signing the transaction. Moreover, the Paymaster is a deployed smart contract, that stores public/private key pair, on Oasis Sapphire network.
KRNL node is now able to broadcast the raw transaction with the attached kernel responses. The node will broadcast the transaction to the peer nodes through gossip protocol.
Now, the smart contract account from the EOA will call registered smart contract. The KRNL node also sends out the execution results, also known as responses from kernel(s), to the smart contract. Ultimately, the registered smart contract is the one who makes final decision whether transaction should be allowed or not.
Because of sponsoring from the Paymaster, the gas that was used during step 7 needs to be compensated. The funds needs to be transferred from smart contract account to KRNL Vault.
The nonce generated in the initial step of this transaction flow will be submitted to the registry of nonce manager. This registry guarantees that the nonce cannot be reused, thereby preventing transaction reentrancy.
During step 10, it is apparent that we have step 10.A, 10.B, and 10.C. These steps occur simultaneously, as they are atomic operations that execute independently without interference, ensuring consistency and reliability in the process.
abc
xyz
