Linkis Core: Reference Implementation of Linkis protocol

Table Of Content

• Introduction
• Quick Start
  • Overview
  • Validator Nodes
    • Install Linkis
    • Initialize the Validator Node
    • Start the Validator Node
    • Send Transactions
    • Transaction Fees
  • Worker Nodes
  • Minimum Requirements
• Linkis Tokens
  • Overview
• Versioning
  • Semantic Versioning
  • Upgrades
  • Supported Versions
• Resources
  • Research
• Contribution

Introduction

Tendermint Core includes both Layer-1 (L1) and Layer-2 (L2) implementations. L1 coordinates and records network activities, securely replicating them across many machines. Meanwhile, L2 contracts handle the storage and transportation of value, including coins and tokens in all kinds of types and formats.

Figure 1: Overview of the decentralized AI service network components and their interactions.

For protocol details, refer to the Linkis WhitePaper.

For a detailed analysis of the consensus framework in the L1 layer, including BFT safety and liveness proofs, refer to the paper, "The latest gossip on BFT consensus" and its corresponding Tendermint GitHub repo.

NOTE: This is only the dev version of Linkis core, both in the L1 and L2 implementations, for testnet purposes. As the project progresses, we are excited to include more features in both layers and anticipate major upgrades compared to the current versions. We warmly welcome any kind of contributions! For more information, see our contribution policy.

Quick Start

Overview

The network is composed of validators, service providers (miners), and clients. To earn network rewards, you need to either participate as a service provider or a validator.

Validator nodes

Validators are responsible for securing the network by proposing and validating new blocks. To set up a validator node, follow these steps:

Install Linkis:

git clone https://github.com/DeAI-Artist/Linkis.git
cd Linkis
make build
make install

Initialize the validator node:

linkis init

Start the validator node:

linkis node

From here your validator node is up and running :)

Note: The current implementations listen to all incoming transactions through the p2p module. To run a local node for testing purposes, modify the configuration file located at .linkis/config/.config.toml. Inside the file, change laddr = "tcp://0.0.0.0:26656" to tcp://127.0.0.1" to restrict network access to localhost only.

Send transactions:

The general transaction format in the Linkis network is:

curl -s 'RPC_laddr:26657/broadcast_tx_commit?tx="TX_CONTENT"'

For example, if we register a client with the client_name field set to Client1, have one of the validators' RPC_laddr as 134.209.85.94, and set TX_CONTENT as 0000003b7b22636f6e74..., then:

curl -s '134.209.85.94:26657/broadcast_tx_commit?tx="0000003b7b22636f6e74656e74223a2265794a6a62476c6c626e5266626d46745a534936496b4e73615756756444456966513d3d222c2274797065223a317dffef7045be04d7de12b68871a6837c67e26a0d89ca4af124bf0b449041f12a6b25f4d388962f0f7e704cfc93f8a47ba0dc9b15118819cf2067ecd9542b17b4251c"'

with the expected output as follows:

{"jsonrpc":"2.0","id":-1,"result":{"check_tx":{"code":0,"data":null,"log":"","info":"","gas_wanted":"0","gas_used":"0","events":[],"codespace":"","sender":"","priority":"0","mempoolError":""},"deliver_tx":{"code":0,"data":null,"log":"","info":"","gas_wanted":"0","gas_used":"0","events":[{"type":"app","attributes":[{"key":"dHJhbnNhY3Rpb24gc2VuZGVy","value":"MHg2YzI1YjcyQ0Q2ODA3RDEwNjc4QjQ1N0I2RTYzRkI3OTNhZTAzMEVi","index":true}]}],"codespace":""},"hash":"39EB7DB89963695E683D862C48C1EB167C757E74E435D6B0C3505A12FE4B4686","height":"88083"}}

If check_tx and deliver_tx have a code of 0, then the transaction is successfully validated and processed, with its content being included in the global states. We can validate this by using the query API on another validator in the network with the command below:

curl -s '178.128.168.223:26657/abci_query?data="clientRegistration_0x6c25b72CD6807D10678B457B6E63FB793ae030Eb"'

To send transactions that can be passed into the mempool, one needs to formulate the transaction according to the message type and transaction format specified in this doc.

Transaction fees:

Unlike interacting with mainnets like Solana or Ethereum, Linkis L1 transactions are completely free of gas fees, allowing clients to navigate the network without any economic friction. One can refer to the Linkis protocol to understand how this is accomplished in a secure and robust manner.

Worker nodes

The Linkis protocol coordinates services by routing clients' requests to workers (miners) in the network. Participating as a worker can help one earn network rewards based on the amount of services they have accepted and completed (through network transactions). To start with a certain RPCENDPOINT:

linkis service-start --rpc-endpoint ${RPCENDPOINT}

It will prompt the user for some registration info and wallet generation.

Note: The service-start command is still under development and will become fully functional with the launch of the testnet. This command aims to simplify the process for anyone with the necessary resources to set up a worker node.

Minimum requirements

Linkis tokens

Overview

The Linkis token (LISA) is the primary utility token supporting network participants such as clients, workers, and validators. Participants are required to hold a certain amount of tokens to be accepted into the Linkis network. Clients must hold tokens to use AI and ML services on the network, while validators need to stake tokens to gain the voting power necessary for recording network activities. Consequently, the Linkis token should have the following considerations: - Security: Mainnets supporting LISA should be secure, typically characterized by a large Total Value Locked (TVL) and a broad community base. - Upgradability: LISA utilizes proxy contracts, allowing for updates to system logic and design without impacting the underlying database. - Cross-chain Capability: Cross-chain functionality improves accessibility, enabling holders of various cryptocurrencies to engage with the Linkis network and utilize AI and ML services. - User Experience: LISA should operate on chains known for low transaction fees and fast confirmation times, ensuring a smooth user experience.

| Feature\Mainnets | BSC

| Ethereum

| Polygon

| Solana

| Near

| Tron

| |-----------------------------|---------------------------------------|-------------------------------------|-------------------------------------|------------------------------------------------|-----------------------------------------|--------------------------------------------| | Security | ✅ Large TVL, Large User Base | ✅ Large TVL, Large User Base | ✅ Growing community size | ✅ Large TVL, Large User Base ⚠️Fair robustness | ⚠️ Fair TVL and moderate community base | ✅ Large TVL, Large User Base | | Upgradability | ✅ Proxy contracts patterns | ✅ Proxy contracts patterns | ✅ Proxy contracts pattern | ✅ Upgradable by upgrad authority | ✅ Upgradable contracts | ✅ Proxy contracts patterns | | Developer Tools | ✅ Many frameworks and tools available | ✅ Many frameworks and tools available | ✅ Well-supported development tools | ✅ Growing ecosystem of tools | ✅ Well-supported development tools | ✅ Many frameworks and tools available | | Transaction Efficiency | ✅ Low fees, fast times | ❌ Extremely high fees, slower times | ⚠️ Low fees, but slow speed | ✅✅ Super-fast, Super low fees | ✅ Low fees, fast times | ✅ Low fees, fast times |

Based on the analysis of different main chains, we decided to use the ERC-20 protocol on Binance Smart Chain using proxy contract patterns. AI is an industry subject to high evolution speed, and all token and utility contracts should be upgradable except the database contracts. Given the growing size of the Linkis network, cross-chain features will also be gradually supported so that LISA can be transferred between chains such as Solana and Tron.

Versioning

Semantic Versioning

Linkis uses Semantic Versioning to determine when and how the version changes. According to SemVer, anything in the public API can change at any time before version 1.0.0

To provide some stability to users of 0.X.X versions of Linkis, the MINOR version is used to signal breaking changes across Linkis's API. This API includes all publicly exposed types, functions, and methods in non-internal Go packages as well as the types and methods accessible via the Linkis RPC interface.

Breaking changes to these public APIs will be documented in the CHANGELOG.

Upgrades

In an effort to avoid accumulating technical debt prior to 1.0.0, we do not guarantee that breaking changes (i.e., bumps in the MINOR version) will work with existing Linkis blockchains. In these cases, you will have to start a new blockchain or write something custom to get the old data into the new chain. However, any bump in the PATCH version should be compatible with existing blockchain histories.

Supported Versions

Because we are a small core team, we only ship patch updates, including security updates, to the most recent minor release and the second-most recent minor release. Consequently, we strongly recommend keeping Linkis up-to-date when joining as validator or worker nodes. We will try our best to ensure that every major upgrade will be technically supported to the extent that the validator node restart will be as smooth as possible.

Resources

Research

• Linkis Protocol
• Proof of Training
• DeAI Overview
• The latest gossip on BFT consensus
• Master's Thesis on Tendermint

Contribution

We appreciate your interest in contributing to our open-source initiative. We'll provide a document of contribution guidelines soon, outlining the steps for contributing to Linkis. We welcome contributions from anyone on the internet and are grateful for even the smallest of fixes🤝!