Choosing Kernel(s)
Last updated
Last updated
Foundry - read more about Foundry here
The below bullet points are the methods of exploring kernels of your choice:
Explore on KRNL Platform - see the registered kernels and explore based on your criteria
Explore each kernel's documentation - see how that specific kernel works from the providers themselves
Try it out! - try using their services through RPC calls (on-chain kernels) or API calls (off-chain)
Use recommended kernels (for testing) - we provide recommended kernels list which is specified for testing and exploring how kOS can integrate your smart contract here
When it comes to choosing kernel(s), it is totally up to the smart contract developers to define the quantity and order of kernels they wish to run before executing smart contracts.
Each individual kernel provides a different type of service. Some might be on-chain and some might be off-chain (through APIs). For the on-chain cases, they might have deployed their smart contracts on various chains, such as an L1 blockchain or L2 blockchain, etc.
Some of the chains which you might be interested in could have specific configurations. For the off-chain cases, they might require multiple APIs through several methods of calling. Kernels provide access to additional functionalities in your smart contracts. For example, verifiable random functions, secure and efficient oracles, KYC background check services, or KYT services from their databases.
We recommend you explore each kernel's documentation to fully understand how each one works.
One way to try using a kernel on-chain is to call the smart contract through JSON-RPC calls. Let's assume that the function on Optimism that we are going to call is a read-only function (view function).
In this guide book, we will be using a service called ABC on the Optimism blockchain network as an example. ABC platform provides KYC services by checking the wallet score from a given wallet address.
Since it is a read-only function, we can make an RPC call to utilize their service by sending the wallet address to check the score.
JSON-RPC information here.
The RPC URLs for Optimism mainnet and Optimism Sepolia testnet are shown respectively in the examples below. It is worth mentioning that if kernels are in different blockchain networks, you might have to change the RPC URL accordingly.
To fill the <FUNCTION_SELECTOR> part, one way is to use Foundry cast, as in the code block below.
For example, if we read their smart contract and they have a function such as getScore(address), we are able to use foundry cast to give the result of an encoded function.
The result can be seen below:
This means that we can provide this encoded hash as a function selector.
One thing worth mentioning here is that the data which needs to be sent will need some padding (using zeros). The reason is that the parameter needs to be a 32 byte code, like in the example below:
The response from sending this request is obtained in the following example:
The result shows that the score is in hexadecimal, and the human-readable number after conversion will be 570000.
At this stage, we are able to see how the kernel ABC works. We, as a smart contract developer, can then decide whether we want to choose ABC or not.
Each kernel protocol has different smart contract(s) that could be deployed on other blockchain networks. These smart contracts may be in other structures and languages. We recommend you read and explore the documents from each individual kernel provider.
In this scenario of calling services off-chain, we will use “XYZ”, a fictional web API service, as a mock example. XYZ platform implements KYT services by validating given wallet addresses. They have built and collected data on their databases, which track down the transactions within a blockchain network, such as Ethereum. The indicator from XYZ is in the format of risk score, which is defined by XYZ themselves. For instance, XYZ has a list of malicious wallet addresses that relate to suspicious activities. When someone tries to interact with the malicious addresses, that wallet address will gain a higher risk score. Another case would be whenever malicious actors try to transfer money to other wallets, the recipients will be flagged.
To give a clearer understanding, we will use Alice, Bob, and Charlie as example actors to represent the wallet addresses.
These actors are made-up for illustration purposes only.
Alice
no previous malicious activities.
0
Bob
involved with malicious activities before.
41
Charlie
no previous malicious activities.
0
From the earlier explanation, we can substitute two events that happened here.
Scenario 1 - Bob transfers 0.5 Ether to Charlie.
The result is that the risk score on Charlie’s side will increase by 25.
Scenario 2 - Alice transfers 0.3 Ether to Bob, after scenario 1 has taken place.
The result is that Alice's risk score will increase by 14.
The risk score from all parties will now be in the table below.
Alice
25
Bob
41
Charlie
14
From the example above, we can see that kernels such as the XYZ service could have detected the malicious wallet address, simply by collecting data from past transactions.
In order to use XYZ, we will have to register on the XYZ platform. After registering through their website, we now have the API endpoint and the API-KEY that is generated just for us. Let's assume that the JSON request body for POST method is in the below code block.
The response from calling this endpoint can be seen in the example below, using Alice and Bob’s wallet addresses.
Utilizing KYT kernels like XYZ could help with protect the intention of doing transaction in the blockchain network.
At this stage, we are able to see how the kernel XYZ works. We, as a smart contract developer, can decide whether we want to choose XYZ or not.
Each kernel protocol has different API calling methods. Kernels could charge some fees for executing their services through APIs. It is recommended to read and explore the documentation from each kernel directly.