KRNL Platform Guidebook
KRNL Platformkrnl.xyz
  • Introduction
    • Introduction
    • How Does kOS Work?
  • Setup
    • Getting Started with KRNL
    • Quick Start (CLI)
    • Quick Start (Online IDE)
      • Quick Start (Remix IDE)
      • Quick Start (Atlas IDE)
    • create-krnl-app
    • Platform Registration
  • Kernel
    • What are Kernels?
    • Kernel Registration
      • Kernel Registration (on-chain)
      • Kernel Registration (off-chain)
    • Supported OpenAPI (Off-chain Kernel)
    • Staking
  • Smart Contract
    • Steps for Smart Contract Developers
    • Choosing Kernel(s)
    • Token Authority
      • What is a Token Authority?
      • How to Build a Token Authority?
      • Generic Token Authority
      • How to Deploy a Token Authority on Oasis?
    • Decoding Kernel Responses in Solidity
    • How to Integrate Your Smart Contract with kOS?
    • Smart Contract Registration
  • DApp
    • dApp Registration
    • KRNL SDK Installation
    • Usage
    • KRNL Node RPC
  • Miscellaneous
    • Overview
    • What is the KRNL Platform?
    • What are You Trying to BUIDL?
    • Smart Contract Fundamentals
      • Why Do I Have to Register a Smart Contract?
      • How to Deploy a Smart Contract?
    • Recommended Kernels List
  • Helpful Resources
    • New to Web3?
    • Dictionary
    • Testnet Faucets
    • How to Get Etherscan API Key?
  • Litepaper
    • Litepaper
      • Overview
      • Problem Statement
      • Current State Does Not Solve the Problem
      • Introducing Kernels
      • Ecosystem of Kernels
      • The KRNL Operating System (kOS)
      • Decentralization and Security Considerations
      • Use Cases for KRNL
  • Appendices
    • FAQ
    • Bounty Program
    • Social Medias
    • Thank You
  • Workshop
    • KRNL Workshop
    • Speed's Workshop
Powered by GitBook
On this page
  • Prerequisites (on-chain)
  • How to Choose Kernel(s) for Your Smart Contract?
  • Detailed Explanation
  • On-chain Kernel
  • Off-chain Kernel
  • Explanation
  • Usage

Was this helpful?

  1. Smart Contract

Choosing Kernel(s)

PreviousSteps for Smart Contract DevelopersNextToken Authority

Last updated 29 days ago

Was this helpful?

Prerequisites (on-chain)

  • Foundry - read more about Foundry


How to Choose Kernel(s) for Your Smart Contract?

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)


Detailed Explanation

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.


On-chain Kernel

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.

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.

https://mainnet.optimism.io
https://sepolia.optimism.io

Request

{
  "jsonrpc": "2.0",
  "method": "eth_call",
  "params": [
    {
      "to": "0x456456456", // ABC contract address on Optimism
      "data": "0x<FUNCTION_SELECTOR><ADDRESS>"
    }
    "latest" // optional
  ],
  "id": 1
}

To fill the <FUNCTION_SELECTOR> part, one way is to use Foundry cast, as in the code block below.

cast sig <FUNCTION_NAME>

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.

cast sig "getScore(address)"

The result can be seen below:

0xd47875d0

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:

"data": "0xd47875d0000000000000000000000000<WALLET_ADDRESS>"

The response from sending this request is obtained in the following example:

Response

{
    "jsonrpc": "2.0",
    "result": "0x000000000000000000000000000000000000000000000000000000000008B290",
    "id": 1
}

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.


Off-chain Kernel

Explanation

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.

Name
Description
Risk Score

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.

Name
Risk Score

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.

Usage

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.

Request

{
  "wallet_address": "<WALLET_ADDRESS_TO_CHECK>",
  "id": 112233,
  "service": "KYT check"
}

The response from calling this endpoint can be seen in the example below, using Alice and Bob’s wallet addresses.

Response

{
  "data": {
    "address": "<ALICE_WALLET_ADDRESS",
    "id": 112233,
    "status": "success",
    "risk_score": 25,
    "reason": ""
  }
}
{
  "data": {
    "address": "<BOB_WALLET_ADDRESS>",
    "id": 112233,
    "status": "risky",
    "risk_score": 41,
    "reason": "malicious previous activities"
  }
}

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.

Use recommended kernels (for testing) - we provide recommended kernels list which is specified for testing and exploring how kOS can integrate your smart contract

JSON-RPC information .

here
here
What are Kernels?
here
LogoPlatformsite_account