InitVerse Technical White Paper

InitVerse Labs

Abstract
The Internet is undergoing a significant revolution, with centralized proprietary services
giving way to decentralized open services. Trusted centers are being replaced by verifiable
computing, and fragile location addresses are being substituted with elastic content addresses.
Inefficient monolithic services are being superseded by peer-to-peer algorithmic marketplaces.
The success of blockchain networks like Bitcoin[1] and Ethereum[2] has demonstrated the
effectiveness of decentralized transaction ledgers. These public ledgers facilitate complex
smart contract applications and facilitate the trade of cryptocurrency assets worth billions
of dollars. These systems operate as decentralized networks, providing efficient payment
services without the need for centralized management or trust centers. They represent the first
examples of open services on the Internet. In the midst of this ongoing Internet revolution,
Kubernetes[3] (k8s) plays a crucial role in enabling the deployment of decentralized and
open services. By automating the deployment, scaling, and management of containerized
applications, k8s empowers developers to focus on writing code rather than worrying about
infrastructure. The emergence of blockchain technology has unlocked new opportunities for
decentralized services, and cloud computing is no exception. InitVerse, an open network, aims
to revolutionize the landscape of cloud computing by offering secure and efficient computing
resource purchase and sale services specifically tailored for public utilities. By harnessing the
power of decentralization, InitVerse transforms cloud computing into a decentralized market.
The primary objective of InitVerse is to create a platform that connects cloud service providers
with customers, fostering a mutually beneficial relationship. The network operates on the
principle of incentivizing both parties to actively participate. Cloud service providers can
offer their computing resources to customers in exchange for Ini, the native cryptocurrency
of the InitVerse network. In turn, customers can utilize their Ini tokens to hire cloud service
providers and deploy cloud services. This two-sided marketplace ensures that both providers
and customers benefit from their participation. To guarantee the security and integrity of
the network, InitVerse implements a competitive mining process. Cloud service providers
have the opportunity to mine Ini tokens based on the effective resources they offer and the
deposit they pledge. This unique design incentivizes providers to accumulate and offer a wide
range of cloud resources for renting out to customers. The more resources they provide, the
higher their mining efficiency and potential rewards. By combining the benefits of blockchain
technology, decentralization, and a competitive mining process, InitVerse creates a platform
that enhances the efficiency and accessibility of cloud computing services. Through this
innovative approach, InitVerse paves the way for a future where cloud computing is more
transparent, secure, and decentralized.

K eywords Decentalized Computing Network · Blockchain · Proof of Resources

 CONTENTS

Contents

1 Introduction 1
1.1 Basic Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Target Users of Ini . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Protocol Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Definition of Decentralized Cloud Service Platform 3

2.1 UDS Scheme Composition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Faults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2.1 False Reporting of Faults by Service Providers . . . . . . . . . . . . . . . . . . . . . . 3
2.2.2 Service Provider Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.3 SDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.3.1 Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3.2 Version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3.3 Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3.4 Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3 POR (Proof of Resources) 8

3.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2 Proof of Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.1 Role of Consensus Participation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.2 Challenges of POR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3 Application in InitVerse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.4 Token Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

4 Verifiable Market 13
4.1 Order Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1.1 Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1.2 Data Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2 Certificate Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2.1 Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2.2 Data Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

5 Smart Contract Module 16

5.1 Role Contract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2
 CONTENTS

5.1.1 ProviderFactory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.1.2 AuditorFactory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.1.3 ValidatorFactory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.2 Functional Contract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.2.1 Order Contract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.2.2 Certificate Contract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.3 Stack-Based Virtual Machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.3.1 Computation and Turing Completeness: . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.3.2 Contract Instruction Set and Instruction Gas Fee (EVM compatible): . . . . . . . . . 19
5.3.3 Contract Compilation and Deployment Tools . . . . . . . . . . . . . . . . . . . . . . . 25

6 Efficient Proof of Resources Consensus Mechanism 26

6.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
6.2 InitVerse Consensus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.3 Penalties for Consensus Participants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
6.3.1 Cloud Service Provider . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
6.3.2 Validator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

7 Future Roadmap 29

3
 1 Introduction

1 Introduction

Ini is a groundbreaking protocol that operates on a new proof mechanism known as "POR" (Proof of
Resources). This innovative blockchain protocol incorporates the collaborative efforts of service providers and
validators to jointly create blocks. The Ini protocol aims to deliver secure, efficient, and cost-effective services
by effectively coordinating the resources of service providers.

The Ini ecosystem encompasses various participants, each playing a vital role in ensuring the pro-
tocol’s success. Firstly, users utilize tokens to access and utilize cloud resources provided by service providers.
Secondly, validators contribute to the network by providing POR proofs and, in return, earn tokens for
their valuable contributions. Thirdly, cloud service providers earn tokens by offering cloud resources and
pledging tokens to the ecosystem. Lastly, auditors play a crucial role in ensuring the integrity and quality of
the services provided by cloud service providers and receive community reward tokens for their auditing efforts.

Through the collaborative efforts of all participants, the Ini protocol creates an ecosystem where
users can access reliable and affordable cloud services, validators are incentivized to maintain the network’s
security, service providers are rewarded for their resource contributions, and auditors ensure the transparency
and trustworthiness of the entire system.

1.1 Basic Components

The Ini protocol is comprised of five key components that work together to form a robust and efficient system:

1. Decentralized Cloud Service Platform (UDS): I ni operates as a decentralized cloud service

platform that organizes cloud service providers to deliver cloud computing resource services. This
platform ensures the seamless provision of resources to meet the diverse needs of users.

2. Proof of Work for Resources (POR): the Ini protocol introduces a novel Proof of Work for
Resources mechanism. This mechanism verifies the existence of claimed resources by challenging the
cloud service provider to perform workload tests. By doing so, the protocol ensures the authenticity
and reliability of the resources offered.

3. Verifiable Market: to access cloud computing resources, users create service orders through the
decentralized market provided by IniChain. Within a limited time, service providers automatically
provide resource quotations. Users have the freedom to select their preferred provider, and the system
guarantees secure and stable payment transfers to the chosen provider. Furthermore, users retain the
flexibility to terminate orders as per their requirements.

4. Effective Resource Proof: the Ini protocol eliminates the need for additional computing resources
for mining blocks by incorporating resource proof. Both validators and providers are required to
demonstrate an adequate number of cloud computing resources, ensuring the integrity and efficiency
of the protocol.

5. Smart Contract: by leveraging the capabilities of smart contract technology, the Initverse protocol
enables unlimited scalability and facilitates decentralized trust and value transfer. This feature allows
for secure and seamless transactions while ensuring the flexibility and adaptability of the protocol.

Through these five components, the Ini protocol revolutionizes the cloud computing landscape by providing a
decentralized platform that guarantees efficient resource allocation, verifies the authenticity of resources, and
facilitates secure transactions and value transfer.

1
 1 Introduction

1.2 Target Users of Ini

InitVerse is a decentralized cloud computing market that aims to revolutionize the cloud industry by offering
cost-effective, flexible, secure, and reliable cloud computing services. The platform specifically targets users
who require cloud computing services, with a focus on those who prioritize affordability, flexibility, security,
and reliability. Some key user groups who can benefit from InitVerse’s offerings include:

1. Web3[4] Users : web3 users often rely on decentralized computing infrastructure to deploy and
operate their decentralized applications. InitVerse’s decentralized cloud computing marketplace
serves as an ideal solution to meet their needs and provide the necessary computing resources.
2. AI and Machine Learning Users : users involved in AI and machine learning applications
often demand substantial computing resources for training and running complex models. InitVerse’s
low-cost and highly flexible approach simplifies access to the required resources, facilitating efficient
development and deployment.
3. Developers : InitVerse also caters to developers by providing an open-source cloud computing
platform that offers a secure and highly flexible environment for building and deploying decentralized
applications. Specifically, InitVerse targets developers who are working on blockchain applications, as
the decentralized cloud computing marketplace aligns well with the requirements of such applications.
Additionally, open-source developers seeking an open and flexible environment for application
development may find InitVerse an appealing choice.

In summary, InitVerse’s target users encompass both those in need of cloud computing services and developers
aiming to build and deploy decentralized applications. These users typically seek affordable, flexible, secure,
and reliable cloud computing services, while also desiring an open and flexible development environment to
support their application-building efforts.

1.3 Protocol Overview

The InitVerse protocol is a decentralized cloud platform that leverages blockchain technology and native
tokens to facilitate its operations. Within the InitVerse ecosystem, users utilize tokens to access and utilize
cloud resources, while providers earn tokens by offering these resources, and validators are rewarded with
tokens for maintaining consensus within the network.

The InitVerse’s User Demand Service (UDS) plays a crucial role in managing users’ requests for cloud
resources through a verifiable market. Providers within the network offer quotes for cloud resources to users,
who then choose the most suitable quote and submit it to the blockchain. Once the provider successfully al-
locates the specified resources, users can access and utilize the cloud resources by utilizing personal certificates.

To ensure the integrity of the marketplace, the InitVerse network employs Proof of Resources (POR) proofs.
These proofs serve as a verification mechanism, guaranteeing that providers fulfill their commitments and
deliver the promised amount of cloud resources to users.
Furthermore, validators and providers actively participate in the creation of new blocks within the blockchain.
The influence a provider has on the subsequent block is determined by the volume of resources they provide
to the network and the number of tokens they have pledged. This system incentivizes providers to contribute
more resources and tokens, thereby enhancing the overall efficiency and reliability of the InitVerse protocol.
In summary, the InitVerse protocol operates as a decentralized cloud platform, utilizing blockchain technology
and native tokens to enable users to access cloud resources, providers to offer these resources, and validators
to maintain consensus. Through its verifiable market and Proof of Resources mechanism, InitVerse ensures
transparency and reliability in the allocation and utilization of cloud resources.

2
 2 Definition of Decentralized Cloud Service Platform

2 Definition of Decentralized Cloud Service Platform

We introduce the concept of a decentralized cloud service platform (UDS) solution. The UDS brings together
a multitude of cloud service providers, allowing them to quickly join the network and offer cloud service
support as long as they have available resources. This coordination is decentralized and eliminates the need
for a trusted intermediary. Through the use of agreements to regulate and verify the resources of cloud
service providers, the UDS helps users mitigate the risks associated with fraud by cloud service providers.

2.1 UDS Scheme Composition

The UDS scheme consists of a protocol tuple executed by providers and users:
(Order, Cert, Manage)

• Order(): users can freely create orders using the order protocol.

• Cert(): users can securely access cloud service resources through the certificate protocol[5].

• Manage(): network participants coordinate through the Manage protocol, which involves controlling
available resources, auditing services provided by suppliers, and addressing possible failures. The
Manage protocol is typically operated by the provider in collaboration with validators or auditors.

2.2 Faults

2.2.1 False Reporting of Faults by Service Providers

We define false reporting of faults by service providers as instances where providers inaccurately report the
number of resources they possess, deviating from the actual count. False reporting of resources by providers
can result in scenarios where users encounter resource allocation issues when creating orders. To mitigate
this situation, the protocol automatically detects and verifies the available resources of the provider. If this
fault is detected, the protocol automatically adjusts the total number of resources that the service provider
can provide.

2.2.2 Service Provider Failure

We define service provider service faults as failures in the services delivered by providers to users. The fault
is highly concealed. We assume that users can identify them within a short timeframe. Users have the ability
to promptly terminate the instances they created and can also apply for the role of auditor to participate in
the auditing process. If the audit is successful, users may be eligible for a certain amount of compensation.

2.3 SDL

Customers/tenants define deployment services, data centers, requirements, and pricing parameters in a
"manifest" file called [Link]. This file uses a declarative language known as a Service Definition
Language (SDL). SDL is a user-friendly data standard for specifying deployment properties. An SDL file
serves as a "form" for requesting network resources. SDL is compliant with the YAML standard and is similar
to Docker Compose files.

Configuration files can have either .yml or .yaml extensions.

3
 2 Definition of Decentralized Cloud Service Platform

2.3.1 Network

Networks, which enable connectivity to and between workloads, can be configured using the Service Definition
Language (SDL) files for deployment. By default, workloads in a deployment group are isolated, preventing
any connections from outside. However, this restriction can be relaxed.

2.3.2 Version

Indicates the version of the InitVerse configuration file. Currently, only "2.0" is accepted.

2.3.3 Service

The top-level "services" entry contains a mapping of workloads to be executed within the InitVerse deployment.
Each key represents a service name, and the corresponding value is a map that includes the following keys.

Name Required Significance

Docker image best practices for containers.

image yes
Avoid using the latest image tag, as the InitVerse provider caches heavily
depends-on no Note - Fields are marked for future use and currently have no impact on deployment.
command no When executing the container, the custom command uses.
args no Parameters used by custom commands when executing containers.
env no Environment variables to set in the running container.
expose no An entity that is allowed to connect to the service.

Table 1: Service name keys

[Link]
Under the "[Link]" section, there is a list of environment variables that will be made available to the
running container.

1 env:
2 - API_KEY=U4cafebabe
3 - CLIENT_ID=U4deadbeef

Figure 1: Service Environment Variables

[Link]
The "[Link]" section contains the ports to expose and related configurations. In InitVerse deployments,
HTTPS is supported. However, self-signed certificates will be generated. If the application is capable of
handling HTTP/HTTPS, ports other than 80 can be exposed as entry ports (HTTP, HTTPS) using the
"as:80" directive. Here is an example of exposing a React web application using this approach:
In SDL, the web application only requires port 80 to be exposed. However, according to this specification,
both port 80 and port 443 are exposed. The "expose" field is a list that defines the entities or resources that
can establish connections with the service. Each entry in the list is a map that can contain one or more of
the following fields: The "as" value determines the default protocol, as outlined below:
Notes

1. If the "as" value is not specified, it will default to the value defined by the port coercion directive.

4
 2 Definition of Decentralized Cloud Service Platform

1 -port: 3000
2 as: 80
3 to:
4 - global: true
5 accept:
6 - [Link]

Figure 2: Example of exposing a React web application

Name Required Meaning

port yes Container port to expose.

as no The port number to expose the container port.
accept no List of hosts that accept connections.
proto no protocol type (tcp, udp, or http).
to no A list of entities that are allowed to connect.

Table 2: Expose fields meaning

Port Number Default Protocol

80 HTTP, HTTPS
other TCP

Table 3: Port - Default Protocol mapping

2. When exposing a service on port: 80 (HTTP), the Kubernetes ingress controller automatically enables
access to the application via HTTPS as well. However, please note that this default configuration
uses a self-signed certificate.

[Link]
The "[Link]" field is a list of clients that can establish connections. Please refer to the table below for
detailed parameters:

Name Meaning Default Describe

service services in this deployment Allow the given service to connect.

global true or false false If true, connections from outside the data center are allowed.

Table 4: [Link] parameters

If no service name is specified and the "global" flag is set to true, clients from any location can establish
connections (typically necessary for web servers). If a service name is provided and the "global" flag is set
to false, only services within the current data center can connect. However, if a service name is provided
and the "global" flag is set to true, connections can be made to services in other data centers within this
deployment. Please note that if the "global" flag is set to false, a service name must be provided.

5
 2 Definition of Decentralized Cloud Service Platform

2.3.4 Profiles

This section includes the configuration of resource bundles and the names of computer resources intended for
deployment.
[Link]
The "[Link]" field is a map consisting of named compute profiles. Each profile defines the computing
resources allocated to service instances associated with that profile. For instance, the following snippet
illustrates the "web" profile, which requires 2 vCPUs, 2 GB of memory, and 5 GB of storage capacity.

1 web:
2 cpu: 28
3 memory: "2Gi"
4 storage: "5Gi"

Figure 3: Computing resource configuration profile example

The "cpu" unit denotes the share of virtual CPUs (vCPUs), and it can be expressed as a decimal value. When
no suffix is included, the value represents a fraction of the total CPU share. Values suffixed with "m" indicate
the number of milli-CPU shares, which is equivalent to 1/1000th of a CPU share. Here is an example:

Quantity CPU share

1 1
0.5 1/2
"100m" 1/10
"50m" 1/20

Table 5: Example of CPU Suffixes

Memory and storage units are measured in bytes. The following suffixes are permitted for simplification:

Suffix Value

k 1000
Ki 1024
m 1000^2
Mi 1024^2
G 1000^3
Gi 1024^3
T 1000^4
Ti 1024^4
P 1000^5
Pi 1024^5
E. 1000^6
Ei 1024^6

Table 6: Suffixes for Memory and Storage

6
 2 Definition of Decentralized Cloud Service Platform

[Link]
The [Link] section consists of a map of named datacenter profiles. Each profile defines the desired
properties of a data center and the pricing configuration for each compute profile within that data center.
Additionally, it allows specifying an optional list of signatures that tenants are expected to audit for data
center properties. Here is an example:

1 westcoast:
2 attributes:
3 region: us-west
4 signedBy:
5 allOf:
6 - "U44SVjKVEYqStBjaKH1ZnHEArNoHiHdqspDKp6EM4qWEMhNafe4QoZfdx"
7 anyOf:
8 - "U44SVjKVEYqStBjaKH1ZnHEArNoHiHdqspDKp6EM4qWEMhNafe4QoZfdx"
9 pricing:
10 web:
11 denom: Ini
12 amount: 8
13 db:
14 denom: Ini
15 amount: 100

Figure 4: Data center and pricing configuration profile example

This defines a profile called "westcoast" with the required attribute region="us-west". The profiles "web"
and "db" compute profiles, and each block has a maximum price of 8 Ini and 15 Ini, respectively. It is
also required that the provider’s attributes have been taken into account. Please audit and sign using
the following signatures: U44SVjkVEYqStBjaKH1ZnHEArNoHiHdqspDKp6EM4qWEMhNafe4QoZfdx and
U43k5jMPq87K2RbtTGGEgajhh2JWWNhLyc2Lo3BpcZdkK83fo5XUq8uoE.
[Link]
The "[Link]" section enables you to specify the address of an approved auditor, which
restricts the acceptance of quotations to certain cloud service providers. This ensures that your deployment
receives a certified endorsement from a trusted third party.
Deployment
The deployment section specifies the deployment process for the service. It involves mapping service names
to deployment configurations. Each service is defined within a deployment entry, which maps the datacenter
profile to the compute profile. This mapping creates the desired configuration, encompassing the necessary
resources for the service.

1 web:
2 westcoast:
3 profile: web
4 count: 20

Figure 5: Deployment entry maps datacenter profile to compute profile

This specifies the deployment of 20 instances of the web service to the datacenter that matches the westcoast
datacenter configuration. Each web instance will have access to the resources defined in the corresponding
compute profile.

7
 3 POR (Proof of Resources)

3 POR (Proof of Resources)

In the InitVerse protocol, incentivizing providers to offer sufficient server resources requires verifying and
validating their claims. Providers must demonstrate to the network that they possess the stated resources.
To achieve this, they generate resource proofs that are subsequently verified by the blockchain network and
its validators. This chapter presents the implementation scheme for resource proof.

3.1 Motivation

The Influence Consensus (POA) [6] scheme employs a group of validators, known as "authority nodes," to
validate the legitimacy of transactions. On the other hand, Proof-of-Stake (POS) consensus [7] schemes
do not require extensive computational puzzles for transaction verification. Instead, POS selects the next
validator based on their coin holdings and duration of possession. Participants in POS are required to stake a
certain amount of currency, which is utilized for transaction verification and earning rewards.
While POA and POS solutions ensure orderly transaction processing and the smooth functioning of cloud
resource services, the InitVerse protocol aims to incentivize cloud resource service providers and promote
network growth during the early stages.

Consequently, stronger guarantees are necessary to prevent providers from cheating and obtaining
rewards without genuinely contributing resources. Possible forms of cheating include:

1. Sybil Attack: Malicious providers may create multiple fake identities (Sybils) to deceive the network
into believing they offer more cloud resources than they actually possess.

2. Outsourcing Attack: Dishonest providers may falsely promise larger volumes of resources than what
they can actually provide, exploiting the lack of effective inspection mechanisms.

3. Selfish Attack: In the blockchain’s consensus mechanism, the longest chain is considered valid. An
attacker can engage in selfish mining by mining blocks privately without broadcasting them. When
the attacker’s hidden chain surpasses the publicly known longest chain, it is broadcasted, causing
a reorganization of the blockchain and enabling attacks like double-spending. Selfish miners gain
greater benefits compared to honest nodes. For example, assuming mining is based on block 1, the
selfish node mines 2 and 3 but does not broadcast them. It continues mining on top of 3 while
withholding 2. When other nodes mine 2, the selfish node broadcasts 2 to create a fork in the chain.
This process continues until the selfish node discovers a longer chain, at which point it broadcasts it,
claiming all mining rewards from 2 to the latest block. The diagram below illustrates this situation:

Figure 6: Blockchain Attacks

8
 3 POR (Proof of Resources)

3.2 Proof of Resources

Proof of Resources (POR) is a novel variation of the Proof of Resources concept. It involves the collaborative
operation of validators and providers to generate blocks. Our scheme utilizes an interactive protocol where
the prover, denoted as ρ , (a) commits to supplying a specified quantity of cloud computing resources and (b)
convinces the validator, through a challenge protocol, that ρ has genuinely delivered the declared amount
of cloud computing resources. The validator then submits the outcome to the blockchain, demonstrating
to other validators that the provider has indeed fulfilled the declared amount of cloud computing resources.
This scheme effectively mitigates Sybil Attacks, outsourcing attacks, and selfish mining.

3.2.1 Role of Consensus Participation

Cloud Service Provider

InitVerse is a decentralized cloud network that operates on blockchain technology. Within this network,
cloud service providers assume the responsibility of supplying InitVerse with servers that meet the official
requirements. These servers must undergo verification by the validator before being admitted into the
InitVerse network. The decentralized architecture of InitVerse enhances network security and reliability by
ensuring that no single entity has complete control.

In addition to their role as server providers, cloud service providers also have the opportunity to
participate in block mining through the InitVerse client. During the mining process, they have the option to
pledge tokens, which increases their chances of successful mining. The number of tokens pledged is directly
proportional to the probability of achieving successful mining outcomes, serving as a motivating factor for
cloud service providers to contribute further to the InitVerse network.

Validator
Validators play a critical role in the InitVerse network and have a wide range of responsibilities, including:

1. Auditing cloud service provider servers: Validators are responsible for auditing the servers
provided by cloud service providers to ensure their reliability and security. Only servers that pass
the audit can be selected by users, thereby safeguarding against malicious attacks and unreliable
servers that could impact user experience.
2. Participating in chain consensus verification: Validators actively engage in chain consensus
verification to uphold the stability and security of the blockchain. During this process, they verify
new transactions and blocks to ensure compliance with the chain’s rules and standards. Only verified
transactions and blocks are added to the chain.
3. Maintaining the chain and generating blocks: Validators maintain the operation of the chain to
ensure its stability and security. This involves producing blocks, creating new blocks, and appending
them to the chain. This requires validators to possess certain computing power and technical
expertise.
4. Participating in community governance: With the open-source nature of the official code,
validators become key participants in community governance. They engage in discussions, decision-
making processes, and help shape the development direction and governance model of the blockchain.
Additionally, validators take responsibility for ongoing maintenance, promotion, and other tasks to
ensure the healthy growth of the blockchain.
5. Autonomous decision-making by verification nodes: Validators hold the authority for au-
tonomous decision-making. This means that all decision-making rights ultimately lie with the

9
 3 POR (Proof of Resources)

verification nodes. Through this self-governing approach, validators collectively determine the di-
rection and governance of the blockchain. This decentralized and democratic framework aligns the
blockchain with the needs and expectations of society.

Auditor
An auditor is a tool designed to audit all cloud server providers, aiming to assist users in making informed
decisions when selecting a suitable cloud server provider. The auditor conducts a comprehensive evaluation
of all providers and assigns labels to them based on identified issues or characteristics, such as security,
performance, and stability. Users have the option to filter providers based on specific tags, enabling them to
choose cloud server providers that best align with their requirements.
For providers with significant issues, the auditor prepares an audit report to be submitted to the platform.
This report serves as a basis for the platform to apply targeted penalties to the respective cloud server
provider. This ensures that providers offer high-quality services and safeguard the interests of users.
The auditing process of the auditor is automated, utilizing various tools and techniques to assess the
quality and reliability of cloud server providers. It examines different aspects, including infrastructure,
network, security measures, and more, generating detailed reports. Users can access these reports to gain a
comprehensive understanding of providers and make informed choices.
Cloud Service Tenant (Customer)
The Ini network is a decentralized cloud computing platform built on Ethereum that offers a wide range of
functions and services for ordinary users. These include the ability to create and deploy smart contracts,
perform transfers, and more. Additionally, Ini features a cloud marketplace where users can purchase their
preferred cloud servers to fulfill various application requirements.

To facilitate application deployment for users, the Ini platform provides Stack Definition Language
(SDL). SDL is a language based on the YAML format that allows users to describe the deployment
environment and configuration of their applications. By utilizing SDL files, users can define the necessary
resources, services, and dependencies for their applications. Subsequently, they can deploy the applications
using Ini’s command-line tools or web interface.
Alongside these features and services, Ini offers additional tools and services to aid users in effectively
managing and monitoring their applications.

3.2.2 Challenges of POR

The POR algorithm consists of a preparation phase, a calculation phase, and a verification phase.

Preparation Phase:

1. The validator sends a challenge request to the provider, including the random number seed (seed),
the number of fragments (SCount), the submitted URL (url), and the preparation end time (Etime).
2. Upon receiving the challenge request, the provider calculates whether the number of shards is
reasonable. If it is unreasonable, the provider submits the task order receipt credential and requests
a recalculation of the number of shards. If reasonable, the process continues.
3. The provider generates an SDL file within the specified time period (40s), determining the Count of
Docker containers. The seed and url are passed into the container as the random number seed +
container Index, along with the preparation end time (Etime).
4. Once the container is started, the Merkle tree is generated based on the provided seed, following
these steps:

10
 3 POR (Proof of Resources)

R 50331648
(a) Use the formula: 1
f (x) = (sha3(f (x − 1)))5 to generate 50,331,648 256-bit leaf nodes.
(b) Arrange all leaf nodes in order, duplicating the last data block if the number of data blocks is
odd to ensure an even number of blocks.
(c) For each pair of adjacent data blocks, calculate their hash value and use it as their parent node.
Repeat step 3 until only one node remains, which represents the root node of the Merkle tree.
(d) Submit the root of the Merkle tree and the container Index to the validator.
5. Once all containers have submitted the Merkle root within the specified time, the calculation phase
begins.

Calculation Phase:

1. The validator sends query tasks to SCount containers, including the query index number (index).
2. Upon receiving the task, each container needs to submit the index leaf node and its adjacent nodes
from the Merkle tree within 10 seconds. If the node is odd-numbered, it provides the current node
and the next node. If the node is even-numbered, it provides the current node and the previous node.
Additionally, the left and right nodes of each layer need to be submitted, totaling 51 hashes, to the
validator.

Verification Phase:

1. The validator collects the submitted results from each container, calculates the Merkle root according
to the Merkle tree calculation rules, and verifies if the calculated Merkle root matches the one
submitted by the container.
2. A 10% sampling is performed to verify the legality of the leaf nodes in the submitted results. This
involves using the seed to generate the leaf with the specified index and comparing it with the
submitted leaves for consistency.
3. The validator generates a Merkle tree using all the Merkle roots submitted by the provider, and
submits the seed, number of fragments (SCount), and the newly generated Merkle root to the
blockchain. As shown below:

3.3 Application in InitVerse

InitVerse utilizes resource certificates to evaluate the resources offered by cloud service providers. To
incentivize providers to offer more resources, it employs a mechanism where providers can earn higher returns
through resource provision and pledged tokens. By leveraging resource certificates, InitVerse ensures that
cloud service providers are unable to engage in fraudulent activities. Additionally, the validator acts as the
consensus carrier on the blockchain, mitigating the risk of 51% attacks that could arise from a single provider
offering an excessive amount of resources.

3.4 Token Distribution

Tokens in the system are generated through Proof of Resources (POR) mining, an algorithm that ensures
network security by considering participants’ resources and staked amounts to determine reward entitlement.
This algorithm not only prevents malicious behavior by attackers but also enhances network scalability.
Each block’s reward is divided into three parts: 86% is allocated to the provider selected by the POR
algorithm, 10% goes to the block validator, and 4% is allocated to the technical team. This distribution

11
 3 POR (Proof of Resources)

Figure 7: Merkle Tree

Figure 8: Application in InitVerse

12
 4 Verifiable Market

method ensures that all participants in the blockchain network receive benefits, incentivizing their continued
involvement in network construction and maintenance. 50% of the rewards are immediately released,
meaning participants receive their share as soon as a new block is produced. This approach ensures timely
benefits and boosts motivation and participation. The remaining 50% of rewards are released gradually,
with 1% distributed daily. This ongoing distribution keeps participants engaged and motivated while
preventing excessive reward concentration during specific periods, reducing network fluctuations and instability.

Transaction handling fees are sent directly to a black hole address, permanently destroying the to-
kens. This practice gradually reduces the total token supply, thereby maintaining their scarcity and value.
Token halving occurs at regular intervals based on block height. The first halving occurs one year after the
first block, followed by subsequent halvings every three years. During each halving event, the block reward is
halved.
Specifically, assuming the reward for a single block is "reward," the allocated rewards for each role are as
follows:
P100 Days
Validator reward ∗10/200 + reward ∗10/20000
Pi=1
100 Days
Provider reward ∗86/200 + i=1 reward ∗86/20000
P100 Days
Team reward ∗4/200 + i=1
reward ∗4/20000

Table 7: Rewards for each role

According to the POR mining rules, the validator adopts the average block method, and as long as they
consistently contribute to the network, they will receive rewards of limn=1→61 reward/n. The provider, on
the other hand, needs to meet a certain probability to obtain rewards.

4 Verifiable Market

The verifiable market is a contractual service agreement that allows users to select cloud computing resources
in a decentralized market. It serves as a platform for facilitating transactions between users and cloud
computing resource providers. Our objective is to ensure that transactions are verifiable, meaning that a
decentralized network of participants can validate transactions between users and cloud computing resource
providers.
We propose the concept of a verifiable market, where there is no centralized entity managing the exchange.
Transactions are transparent and open for anonymous participation by anyone. The verifiable market protocol
enables fully decentralized transactions between user needs and cloud computing services. The process of
user order creation, order settlement, and correct service execution is independently verified by node partici-
pants such as validators and providers. We present a simplified architecture for the verifiable market as follows.

4.1 Order Module

4.1.1 Function

The order module supports users in creating orders, selecting suppliers, making server payments, obtaining
server access information, and releasing resources on the blockchain. The following provides a detailed
introduction to the functions of this module:

1. Order creation function: users can create an order contract through the order factory, transfer
the prepaid amount, upload the SDL file, and provide basic resource information (CPU, memory,

13
 4 Verifiable Market

storage, etc.). When creating an order, users need to provide a sufficient prepaid amount to cover
the resource usage.
2. Supplier selection function: after the user completes the order creation, they can query the
resource list of all suppliers using auxiliary tools. The system identifies the suppliers that meet the
resource requirements and calculates the optimal solution based on the supplier’s resource price.
The options are then presented to the user for selection. Users have the flexibility to choose their
preferred suppliers and submit the supplier’s address to the order contract.
3. Server payment function: once the supplier address is submitted, the existing user of the supplier
can invoke the contract’s fee deduction interface upon server creation. The fees are deducted based
on the resource scale and unit price set by the supplier.
4. Server access information retrieval function: after receiving the successful order event, the
supplier can use the provider program to create a container based on the SDL file and certificate file
submitted by the user. The supplier assigns a publicly accessible domain name to the server and
submits the server’s access information to the order contract. The contract’s query interface is then
opened for wallet access.
5. Resource release function: both users and suppliers can utilize the resource release interface to
perform final settlement. Once the settlement is completed, the order contract enters an idle state,
ready for subsequent reuse. It is important to note that the provider can only invoke the resource
release interface when the user balance falls below the 10% threshold.

The above provides an overview of the functionalities offered by the order module. Through this module,
users can easily create orders, select suppliers, make payments, obtain server access information, and release
resources.

4.1.2 Data Structure

Based on the resources required in the order contract, the cloud computing resource provider compares its
available resources. If it can provide the services, it reports the price in its own configuration to the order.
Therefore, the order module incorporates the following data structure in the contract:

• Provide_quotes: a list of quotes from cloud computing resource providers.

• Owner: the address of the order owner.
• O_cpu: CPU usage of the order.
• O_memory: memory usage of the order.
• O_storage: storage usage of the order.
• O_order_number: order number.
• O_cert: order certificate key.
• O_sdl_trx_id: SDL transaction hash submitted by the order.
• O_pending_sdl_trx_id: SDL transaction hash for order update.
• Order_status: order status, where 0 means created, 1 means available for quotation, 2 means in
progress, and 3 means completed.
• Final_price: final price of the quotation after aggregate calculation.
• Final_choice: the selected final offer number.
• Last_pay_time: last payment time.

14
 4 Verifiable Market

• Server_uri: server URI.

• Totalspent: total cost.

The above data structure is implemented in the order contract to facilitate the exchange of information and
ensure efficient handling of order-related data.

4.2 Certificate Module

4.2.1 Function

The certificate module serves as a mechanism provided by cloud computing resource providers to ensure
user identity security. Before utilizing cloud computing resources, users are required to obtain corresponding
certificates. Providers can utilize these certificates to offer cloud computing resource services to users who
possess valid certificates. The main functions of this module encompass certificate creation, querying, and
cancellation.
The certificate contract is employed as a technical means to realize these functionalities. It is a smart
contract that utilizes blockchain technology to execute operations such as certificate creation, querying, and
cancellation. Specifically, the certificate contract encompasses the following functions:

1. Create Certificate: users can generate new certificates using a specific method. These certificates
contain information such as the user’s identity details and relevant encryption keys. The public
key information within the certificate is then uploaded to the blockchain via the certificate creation
interface.

2. Query Certificate: users can retrieve their own certificate information by invoking the query
certificate function within the certificate contract. Providers can also verify the user’s identity
information by utilizing the query certificate function.

3. Cancel Certificate: when a user no longer requires access to cloud computing resources, they can
revoke their certificate by calling the cancel certificate function within the certificate contract. Once
canceled, the certificate becomes invalid and cannot be used further.

The certificate module is implemented through the certificate contract, ensuring the security and immutability
of the certificates. This, in turn, guarantees user identity security and data privacy.

4.2.2 Data Structure

The data structure associated with the certificate module is as follows:

• CreateTime: the timestamp indicating the creation time of the certificate.

• RemainTime: the remaining validity period of the certificate.

• User: the address of the user to whom the certificate belongs.

• Index: the index value assigned to the certificate.

• State: the status of the certificate, which can be either obsolete or in use.

The aforementioned data structure facilitates efficient management and tracking of certificate-related infor-
mation within the certificate contract.

15
 5 Smart Contract Module

5 Smart Contract Module

InitVerse offers solidity-based smart contracts to users, delivering scalable functions that cater to their needs.
With a focus on InitVerse’s operational requirements and key functionalities, several contracts are essential
within the blockchain network.

5.1 Role Contract

Among these contracts are the ProviderFactory, AuditorFactory, and ValidatorFactory. These contracts serve
as identity contracts that actively maintain the chain’s integrity and participate in its seamless operation.

5.1.1 ProviderFactory

The providerFactory contract specifically addresses cloud computing resource providers who offer vital services
such as computing resources. In the blockchain ecosystem, providers must disclose their identities and the
resources they can contribute to the chain. To ensure service stability and increase their chances of generating
blocks, providers are also required to pledge tokens. Summarily, the providerFactory contract encompasses
the following essential functions:

1. Creating a Provider Identity: through this contract, providers can establish their unique identities
and report the cloud computing resources they are capable of providing.
2. Reporting Resources: providers must actively report the cloud computing resources they can
offer through the providerFactory contract. This includes both additions and reductions in resources.
Notably, the more resources a provider reports, the higher their probability of receiving mining
rewards becomes.
3. Pledging Tokens: providers are obligated to pledge an adequate amount of tokens when creating
their provider identity. The number of tokens pledged should correspond to the amount of resources
reported by the provider. This practice ensures the security and stability of the chain. Providers
who pledge a larger number of tokens increase their likelihood of receiving mining rewards.
4. Security Deposit: the pledged tokens, also known as the security deposit, serve as a safeguard to
prevent providers from violating the established rules while delivering their services. In cases of rule
violations, this contract allows for punitive deductions from the provider’s security deposit.

By implementing the providerFactory contract, InitVerse enables cloud computing resource providers to
actively participate in the blockchain ecosystem, maintain transparency, and foster a secure and stable
environment.

5.1.2 AuditorFactory

The AuditorFactory contract focuses on cloud computing resource auditors who play a crucial role in ensuring
the seamless provision of services like cloud computing resources. In the blockchain ecosystem, auditors are
required to disclose their identities, the providers they have audited, and the details of their audits to the
chain. The AuditorFactory contract encompasses the following key functions:

1. Creating an Auditor Identity: through this contract, auditors can establish their unique identities,
enabling them to contribute to the audit process effectively.
2. Reporting Audit Information: auditors can utilize the AuditorFactory contract to report
information about the providers they have audited. This includes sharing details about the audited
providers and the specific content of the audit.

16
 5 Smart Contract Module

3. Querying Audit Information: the contract also provides a mechanism for querying audit informa-
tion. Users can access comprehensive details regarding audited providers, including which auditors
have conducted the audits and the specific audit content.

By utilizing the AuditorFactory contract, InitVerse ensures transparency and accountability in the auditing
process, enhancing the overall reliability of the blockchain ecosystem.

5.1.3 ValidatorFactory

The validatorFactory contract focuses on validators, the entities responsible for maintaining the InitVerse
chain’s operation. Validators play a vital role in ensuring the stability and proper functioning of the entire
InitVerse chain. The validatorFactory contract provides the following essential functions:

1. Creating Validator Identity: through this contract, validators can establish their unique identities,
enabling them to actively participate in maintaining the InitVerse chain.
2. Pledging Tokens: to ensure the long-term operation and stability of the chain, validators are
required to pledge tokens. This token pledge serves the purpose of maintaining both the validator’s
stable operation and the overall stability of the chain. In cases where a validator fails to operate
reliably, the contract includes provisions for punitive deductions from the pledged tokens.

By incorporating the validatorFactory contract, InitVerse strengthens the InitVerse chain’s integrity, ensuring
its sustained and secure operation.

5.2 Functional Contract

Within the InitVerse ecosystem, there are fundamental contracts that enable users to leverage cloud computing
resources effectively. These contracts include the order contract and the certificate contract, both of which
play crucial roles in facilitating user interactions with cloud services.

5.2.1 Order Contract

The order contract is designed to support users in various aspects of their cloud computing resource usage. It
enables users to create orders, select suppliers, make server payments, obtain server access information, and
release resources securely on the blockchain. The functions of the order contract are as follows:

1. Order Creation: users can create orders through the order contract, specifying their required cloud
computing resources and making advance payments.
2. Provider Quotations: orders are made public on the blockchain, allowing all operational providers
to access order information. Providers can then choose whether to provide quotations based on their
remaining resources.
3. Supplier Selection: users have the flexibility to choose a cloud computing resource provider that
best meets their requirements by evaluating the quotations and provider information provided by the
providers.
4. Access Information Reporting: upon selection, the chosen provider retrieves its Service Descrip-
tion Language (SDL) file based on the order information. The provider then creates an instance
according to the SDL file and reports the access information to the user.
5. Server Payment: cloud computing resource providers periodically interact with this contract to
obtain server fees from users.

17
 5 Smart Contract Module

Through the order contract, InitVerse empowers users to easily navigate the process of obtaining and utilizing
cloud computing resources, ensuring transparency and efficiency.

5.2.2 Certificate Contract

The certificate contract serves as a mechanism provided by cloud computing resource providers to safeguard
user identities and enhance security. The key functions of the certificate contract are as follows:

1. Certificate Registration: Users can register their credentials and obtain a level of user certificate
through this contract, ensuring the verification of their identity within the ecosystem.

2. Certificate Query: The certificate contract allows users to query their own certificates, providing a
means to validate and verify their identities.

3. User Status Modification: This contract also enables the modification of user statuses, ensuring
that relevant changes or updates can be made as required.

By implementing the certificate contract, InitVerse ensures the integrity and security of user identities,
establishing a trustworthy environment for leveraging cloud computing resources.

5.3 Stack-Based Virtual Machine

The stack-based virtual machine embodies the core characteristics of a virtual machine while employing a
stack-based memory structure for data storage. Leveraging the stack’s First-In-First-Out (FIFO) operation
mode, data is popped from the stack to perform operations, and the resulting values are pushed back onto
the stack. This unique memory structure allows the stack to accommodate multiple inputs and produce
multiple results, enabling a wide range of computations. In stack machine code, instructions typically consist
only of opcodes that dictate the operations, without additional fields to identify constants or handle branches.
Immediate loads, load/store instructions, and branching instructions require only a single parameter field.

The stack-based virtual machine architecture boasts several advantages, primarily due to its re-
liance on PUSH and POP operations. The stack pointer facilitates the retrieval of operands stored in the
stack. Consequently, the virtual machine does not need to know the specific addresses of operands; it can
simply access the stack and perform a POP operation to obtain the next operand.

Within the stack-based virtual machine architecture, all arithmetic and logical operations are exe-
cuted by manipulating the stack—values are popped and pushed to perform calculations, and the results are
ultimately stored back in the stack.
Instructions that involve memory addresses or calculate addresses based on stack values typically exist in
stack machines. Real stack machines feature load-store opcodes that provide access to local variables and
formal parameters without requiring explicit address calculations. These opcodes employ offsets relative to
the current top-of-stack address or a stable frame base register.

The instruction set of a stack-based virtual machine utilizes suffix operations (Reverse Polish Nota-
tion) to execute most Arithmetic Logic Unit (ALU) operations. The ALU performs arithmetic and logical
operations in the computer instruction set. In some processors, the ALU comprises separate Arithmetic
Units (AU) and Logic Units (LU). However, these operations exclusively manipulate the expression stack and
do not directly affect data registers or main storage units. This feature proves highly advantageous when
executing high-level languages, as most arithmetic expressions can be readily converted into postfix notation.

18
 5 Smart Contract Module

Figure 9: Stack Based Virtual Machine

The expression A*(BC) + (D+E) can be represented by a binary syntax tree. For instance, when written in
reverse Polish notation as ABC-*DE++, the expression can be compiled and executed on a simple imaginary
stack machine in the following manner.

Arithmetic operations such as "subtract," "multiply," and "add" are performed on the top two operands of the
stack. The computer retrieves the two operands from the topmost value on the stack, replaces them with the
calculated difference, sum, or product, and pushes the result back onto the stack. In essence, an instruction’s
operand is "popped" from the stack, and the resulting value is "pushed" onto the stack, ready for the next
instruction. Stack machines can have separate expression stacks and call-return stacks or integrate them
into a single structure. Separating them allows for pipelining the stack machine’s instructions, reducing
interaction and design complexity, resulting in faster execution.

5.3.1 Computation and Turing Completeness:

it is important to note that the virtual machine is Turing complete, which means that the EVM[8] code can
encode any computation, including infinite loops. The EVM code allows for looping in two ways. First, the
JUMP instruction enables the program to jump back to a previous location in the code. Additionally, the
JUMPI instruction facilitates conditional jumps, enabling constructs like "while x < 27: x = x * 2." Second,
contracts can call other contracts, potentially enabling looping through recursion. However, this raises a
question: Can a malicious user halt miners and full nodes by forcing them into an infinite loop? This issue
stems from the halting problem in computer science, where, in the general case, it is impossible to determine
if a given program will halt. As mentioned in the state transition section, our solution addresses this by
requiring transactions to set a maximum limit on computational steps allowed (via a larger GASLIMIT). If
the execution exceeds the allocated gas and the GASLIMIT is insufficient, the transaction will fail due to gas
exhaustion.

5.3.2 Contract Instruction Set and Instruction Gas Fee (EVM compatible):

each instruction in the contract instruction set corresponds to a callback method that executes the decoded
instruction within the VM. Additionally, gas consumption requirements are established, and the sum of the

19
 5 Smart Contract Module

gas consumption for a contract call is determined as the fee. A corresponding stack detection method is also
set, which checks whether the number of operands on the stack and the stack size exceed the maximum limit.

Table 8: Instruction Gas Fee

Opcode Name Description Gas

0x00 STOP Halts execution 0
0x01 ADD Addition operation 3
0x02 MUL Multiplication operation 5
0x03 SUB Subtraction operation 3
0x04 DIV Integer division operation 5
0x05 SDIV Signed integer division operation (truncated) 5
0x06 MOD Modulo remainder operation 5
0x07 SMOD Signed modulo remainder operation 5
0x08 ADDMOD Modulo addition operation 8
0x09 MULMOD Modulo multiplication operation 8
0x0a EXP Exponential operation 10*
0x0b SIGNEXTEND Extend length of two’s complement signed inte- 5
ger
0x0c - 0x0f Unused Unused
0x10 LT Less-than comparison 3
0x11 GT Greater-than comparison 3
0x12 SLT Signed less-than comparison 3
0x13 SGT Signed greater-than comparison 3
0x14 EQ Equality comparison 3
0x15 ISZERO Simple not operator 3
0x16 AND Bitwise AND operation 3
0x17 OR Bitwise OR operation 3
0x18 XOR Bitwise XOR operation 3
0x19 NOT Bitwise NOT operation 3
0x1a BYTE Retrieve single byte from word 3
0x1b SHL Shift Left 3
0x1c SHR Logical Shift Right 3
0x1d SAR Arithmetic Shift Right 3
0x20 KECCAK256 Compute Keccak-256 hash 30*
0x21 - 0x2f Unused Unused
0x30 ADDRESS Get address of currently executing account 2
0x31 BALANCE Get balance of the given account 700
Continued on next page

20
 5 Smart Contract Module

Opcode Name Description Gas

0x32 ORIGIN Get execution origination address 2
0x33 CALLER Get caller address 2
0x34 CALL VALUE Get deposited value by the instruction/transac- 2
tion responsible for this execution
0x35 CALL DATA LOAD Get input data of current environment 3
0x36 CALL DATA SIZE Get size of input data in current environment 2*
0x37 CALLDATACOPY Copy input data in current environment to mem- 3
ory
0x38 CODESIZE Get size of code running in current environment 2
0x39 CODECOPY Copy code running in current environment to 3*
memory
0x3a GASPRICE Get price of gas in current environment 2
0x3b EXT CODE SIZE Get size of an account’s code 700
0x3c EXTCODECOPY Copy an account’s code to memory 700*
0x3d RETURN DATA SIZE Pushes the size of the return data buffer onto 2
the stack
0x3e RETURNDATACOPY Copies data from the return data buffer to mem- 3
ory
0x3f EXTCODEHASH Returns the keccak256 hash of a contract’s code 700
0x40 BLOCKHASH Get the hash of one of the 256 most recent 20
complete blocks
0x41 COINBASE Get the block’s beneficiary address 2
0x42 TIMESTAMP Get the block’s timestamp 2
0x43 NUMBER Get the block’s number 2
0x44 DIFFICULTY Get the block’s difficulty 2
0x45 GASLIMIT Get the block’s gas limit 2
0x46 CHAINID Returns the current chain’s EIP-155 unique 2
identifier
0x47 - 0x4f Unused -
0x48 BASEFEE Returns the value of the base fee of the current 2
block it is executing in.
0x50 POP Remove word from stack 2
0x51 MLOAD Load word from memory 3*
0x52 MSTORE Save word to memory 3*
0x53 MSTORE8 Save byte to memory 3
0x54 SLOAD Load word from storage 800
0x55 SSTORE Save word to storage 20000**
Continued on next page

21
 5 Smart Contract Module

Opcode Name Description Gas

0x56 JUMP Alter the program counter 8
0x57 JUMPI Conditionally alter the program counter 10
0x58 GETPC Get the value of the program counter prior to 2
the increment
0x59 MSIZE Get the size of active memory in bytes 2
0x5a GAS Get the amount of available gas, including the 2
corresponding reduction for the cost of this in-
struction
0x5b JUMPDEST Mark a valid destination for jumps 1
0x5c - 0x5f Unused -
0x60 PUSH1 Place 1 byte item on stack 3
0x61 PUSH2 Place 2-byte item on stack 3
0x62 PUSH3 Place 3-byte item on stack 3
0x63 PUSH4 Place 4-byte item on stack 3
0x64 PUSH5 Place 5-byte item on stack 3
0x65 PUSH6 Place 6-byte item on stack 3
0x66 PUSH7 Place 7-byte item on stack 3
0x67 PUSH8 Place 8-byte item on stack 3
0x68 PUSH9 Place 9-byte item on stack 3
0x69 PUSH10 Place 10-byte item on stack 3
0x6a PUSH11 Place 11-byte item on stack 3
0x6b PUSH12 Place 12-byte item on stack 3
0x6c PUSH13 Place 13-byte item on stack 3
0x6d PUSH14 Place 14-byte item on stack 3
0x6e PUSH15 Place 15-byte item on stack 3
0x6f PUSH16 Place 16-byte item on stack 3
0x70 PUSH17 Place 17-byte item on stack 3
0x71 PUSH18 Place 18-byte item on stack 3
0x72 PUSH19 Place 19-byte item on stack 3
0x73 PUSH20 Place 20-byte item on stack 3
0x74 PUSH21 Place 21-byte item on stack 3
0x75 PUSH22 Place 22-byte item on stack 3
0x76 PUSH23 Place 23-byte item on stack 3
0x77 PUSH24 Place 24-byte item on stack 3
0x78 PUSH25 Place 25-byte item on stack 3
0x79 PUSH26 Place 26-byte item on stack 3
Continued on next page

22
 5 Smart Contract Module

Opcode Name Description Gas

0x7a PUSH27 Place 27-byte item on stack 3
0x7b PUSH28 Place 28-byte item on stack 3
0x7c PUSH29 Place 29-byte item on stack 3
0x7d PUSH30 Place 30-byte item on stack 3
0x7e PUSH31 Place 31-byte item on stack 3
0x7f PUSH32 Place 32-byte (full word) item on stack 3
0x80 DUP1 Duplicate 1st stack item 3
0x81 DUP2 Duplicate 2nd stack item 3
0x82 DUP3 Duplicate 3rd stack item 3
0x83 DUP4 Duplicate 4th stack item 3
0x84 DUP5 Duplicate 5th stack item 3
0x85 DUP6 Duplicate 6th stack item 3
0x86 DUP7 Duplicate 7th stack item 3
0x87 DUP8 Duplicate 8th stack item 3
0x88 DUP9 Duplicate 9th stack item 3
0x89 DUP10 Duplicate 10th stack item 3
0x8a DUP11 Duplicate 11th stack item 3
0x8b DUP12 Duplicate 12th stack item 3
0x8c DUP13 Duplicate 13th stack item 3
0x8d DUP14 Duplicate 14th stack item 3
0x8e DUP15 Duplicate 15th stack item 3
0x8f DUP16 Duplicate 16th stack item 3
0x90 SWAP1 Exchange 1st and 2nd stack items 3
0x91 SWAP2 Exchange 1st and 3rd stack items 3
0x92 SWAP3 Exchange 1st and 4th stack items 3
0x93 SWAP4 Exchange 1st and 5th stack items 3
0x94 SWAP5 Exchange 1st and 6th stack items 3
0x95 SWAP6 Exchange 1st and 7th stack items 3
0x96 SWAP7 Exchange 1st and 8th stack items 3
0x97 SWAP8 Exchange 1st and 9th stack items 3
0x98 SWAP9 Exchange 1st and 10th stack items 3
0x99 SWAP10 Exchange 1st and 11th stack items 3
0x9a SWAP11 Exchange 1st and 12th stack items 3
0x9b SWAP12 Exchange 1st and 13th stack items 3
0x9c SWAP13 Exchange 1st and 14th stack items 3
Continued on next page

23
 5 Smart Contract Module

Opcode Name Description Gas

0x9d SWAP14 Exchange 1st and 15th stack items 3
0x9e SWAP15 Exchange 1st and 16th stack items 3
0x9f SWAP16 Exchange 1st and 17th stack items 3
0xa0 LOG0 Append log record with no topics 375
0xa1 LOG1 Append log record with one topic 750
0xa2 LOG2 Append log record with two topics 1125
0xa3 LOG3 Append log record with three topics 1500
0xa4 LOG4 Append log record with four topics 1875
0xa5 - 0xaf Unused -
0xb0 JUMPTO tentative
0xb1 JUMPIF tentative
0xb2 JUMPSUB tentative
0xb4 JUMPSUBV tentative
0xb5 BEGINSUB tentative
0xb6 BEGINDATA tentative
0xb8 RETURNSUB tentative
0xb9 PUTLOCAL tentative
0xba GETLOCAL tentative
0xbb - 0xe0 Unused -
0xe1 SLOAD BYTES Only referenced in pyInitVerse -
0xe2 SSTORE BYTES Only referenced in pyInitVerse -
0xe3 SSIZE Only referenced in pyInitVerse -
0xe4 - 0xef Unused -
0xf0 CREATE Create a new account with associated code 32000
0xf1 CALL Message-call into an account Complicated
0xf2 CALLCODE Message-call into this account with alternative Complicated
account’s code
0xf3 RETURN Halt execution returning output data 0
0xf4 DELEGATE CALL Message-call into this account with an alter- Complicated
native account’s code, but persisting into this
account with an alternative account’s code
0xf5 CREATE2 Create a new account and set creation address
to sha3(sender + sha3(init code)) % 2**160
0xf6 - 0xf9 Unused -
0xfa STATIC CALL Similar to CALL, but does not modify state 40
0xfb Unused -
Continued on next page

24
 5 Smart Contract Module

Opcode Name Description Gas

0xfc TXEXECGAS Not in yellow paper FIXME -
0xfd REVERT Stop execution and revert state changes, with- 0
out consuming all provided gas and providing
a reason
0xfe INVALID Designated invalid instruction 0
0xff SELF DESTRUCT Halt execution and register account for later 5000*
deletion

5.3.3 Contract Compilation and Deployment Tools

• solc
• truffle
• Remix IDE
• ChainIDE

These tools provide functionalities for compiling and deploying contracts efficiently. Implementation Examples
of Various Instruction Types for the Contract Virtual Machine:

1. Arithmetic Instruction Example: ADD. The ADD instruction in the EVM is implemented as
follows. The stack pointer (SP) indicates the position of the stack. The data is retrieved from the
top two positions of the stack (SP[0], SP[1]). After performing the addition operation, the result is
stored in the top position (SPP[0]) of the result stack (SPP).

Algorithm 1 Arithmetic Instruction Example

1: case ADD
2: ON_OP();
3: updateIOGas();
4: m_SPP[] = m_SP[0] + m_SP[1]; ▷ pops two items and pushes their sum mod 2256

2. Jump Instruction Example: JUMP. The JUMP instruction facilitates the transfer of control
between different sections of binary codes. The process involves retrieving the address to be jumped
to from the top of the stack (SP[0]), ensuring that it falls within the valid range. Subsequently, the
address is assigned to the program counter (PC), which directs the execution of the next instruction
starting from the location indicated by PC.

Algorithm 2 Jump Instruction Example

1: case JU M P
2: ON_OP();
3: updateIOGas();
4: m_PC = verifyJumpDest(m_SP[0]);

3. Example of Status Read Command: SLOAD. The SLOAD instruction allows for the retrieval
of state data within the contract. The procedure involves extracting the key to be accessed from
the top of the stack (SP[0]), utilizing the key as a parameter, and invoking the callback function
get_storage() of evmc to query the corresponding value associated with the provided key. Finally,
the retrieved value is written to the top of the result stack (SPP[0]).

25
 6 Efficient Proof of Resources Consensus Mechanism

Algorithm 3 Status Read Command Example

1: case SLOAD
2: m_runGas = m_rev >= EVMC_TANGERINE_WHISTLE ? 200 : 50;
3: ON_OP();
4: updateIOGas();
5: evmc_uint256be key = toEvm(m_SP[0]);
6: evmc_uint256be value;
7: m_context -> fn_table -> get_storage(&value,m_context, &m_message -> destination, &key);

4. Example of Status Write Command: SSTORE. The SSTORE instruction enables the writing
of data to the node’s state. The procedure involves extracting the key and value from the top two
positions (SP[0], SP[1]) of the stack. These key and value parameters are then utilized to invoke the
callback function set_storage() of evmc, resulting in the state of the node being updated with the
provided data.

Algorithm 4 Status Write Command Example

case SST ORE
ON_OP();
m_runGas = m_rev >= EVMC_TANGERINE_WHISTLE ? 200 : 50;
if (m_message → flags & EVMC_STATIC) then
throwDisallowedStateChange();

static_assert(VMSchedule::sstoreResetGas <= VMSchedule::sstoreSetGas, "Wrong SSTORE gas costs");

m_runGas = VMSchedule::sstoreResetGas; ▷ Charge the modification cost up front
updateIOGas();

evmc_uint256be key = toEvm(m_SP[0]);

evmc_uint256be value = toEvmC(m_SP[1]);
auto status = m_context -> fn_table -> set_storage(m_context, &m_message -> destination, &key,
&value);

5. Example of Contract Call Command: CALL. The CALL command allows for the invocation of
another contract based on its address. When the EVM encounters a CALL instruction, it triggers the
caseCall() function. Within caseCall(), the data is extracted from the stack and encapsulated into
msg before invoking the callback function call of evmc as a parameter. Upon the callback, InitVerse
initiates a new EVM instance, processes the call, and returns the execution result to the current
EVM via the call() parameter. The current EVM then writes the result to the result stack (SSP),
thereby concluding the call. The logic behind contract creation follows a similar pattern.

6 Efficient Proof of Resources Consensus Mechanism

The InitVerse Proof of Resource (POR) consensus protocol can be implemented on top of any protocol that
supports proof verification. In this chapter, we will introduce how to bootstrap consensus protocols based on
efficient work, thereby replacing wasteful proof-of-work calculations.

6.1 Motivation

Securing the blockchain is of utmost importance, but traditional proof-of-work schemes often require solving
complex problems that result in non-reusable or wasteful computations. Key points to consider include:

26
 6 Efficient Proof of Resources Consensus Mechanism

Algorithm 5 Contract Call Command Example

case CALL
case CALLCODE
ON_OP();
if m_OP == Instruction::DELEGATECALL &&m_−rev < EVMC_HOMESTEAD then
throwBadInstruction();
if m_OP == Instruction::STATICCALL && m_rev < EVMC_BYZANTIUM then
throwBadInstruction();
if m_OP == Instruction::CALL && m_message -> flags && EVMC_STATIC & & m_SP[2] != 0
then
throwDisallowedStateChange();
m_bounce = &VM ::caseCall;
procedure VM::caseCall()
m_bounce = &VM ::interpretCases;
evmc_message msg = {};
evmc_message msg = {};
bytesRef output;
if (caseCallSetup(msg, output)) then
evmc_result result;
m_context->fn_table->call(&result, m_context, &msg);
m_returnData.assign(result.output_data, result.output_data + result.output_size);
bytesConstRef { &m_returnData }.copyTo(output);
m_SPP[0] = result.status_code == EVMC_SUCCESS ?1 : 0;
m_io_gas + = result.gas_left;
if ([Link]) then
[Link](&result);
else
m_SPP[0] = 0;
m_io_gas += [Link];
++m_PC;

1. Non-reusable work: in most permissionless blockchains, miners are tasked with solving computa-
tionally infeasible problems, such as hash function reversals. However, the solutions to these puzzles
have limited value beyond securing the network. Is there a way to repurpose this work for something
useful?
2. Attempts to reuse work: various attempts have been made in the industry to utilize mining
power for practical computations. Some approaches involve miners performing additional calculations
alongside standard proof-of-work. Yet, replacing proof of work with truly useful problems remains
challenging. For instance, Primecoin repurposes mining power to discover new prime numbers,
Ethereum requires miners to execute small programs alongside proof-of-work, and Permacoin provides
archiving services by requiring miners to invert a hash function while proving the archival of specific
data. While these attempts involve useful work, wasted effort in these computations still occurs.
3. Wasted work: solving puzzles is highly resource-intensive in terms of machine and energy costs,
particularly when relying solely on computing power. While mining algorithms can be parallelized,
computing power remains the primary factor in puzzle-solving.
4. Efforts to reduce waste: ideally, a significant portion of network resources should be dedicated
to useful work. Some attempts have aimed to make mining more energy-efficient. For example,
Spacemint requires miners to utilize hard drives instead of computing power, but even with this
improvement, hard drives still contain unused data. Other approaches propose replacing the puzzle-
solving difficulty with a traditional proof-of-stake-based Byzantine agreement, where the voting power
of stakeholders in the next block is proportional to their share of currency in the system.

27
 6 Efficient Proof of Resources Consensus Mechanism

Building upon these considerations, we have designed an efficient consensus protocol based on resource proof.
This protocol aims to minimize wasteful computations while ensuring the security and effectiveness of the
InitVerse network.

6.2 InitVerse Consensus

InitVerse Consensus is a resource-based proof-of-consensus algorithm that aims to verify the legitimacy of
resources provided by the provider and detect any cheating attempts through the Proof of Resource (POR)
challenge posed by the verifier. The algorithm operates as follows.
Providers can pledge a certain number of tokens that comply with the mining rules based on their available
resources. The pledge must pass a one-day waiting period before being considered for effective mining. This
rule is implemented to prevent providers from staking a large number of tokens within a short timeframe,
thus gaining an unfair mining advantage. The term "conforming rules" here refers to the number of resources
provided by the provider, calculated according to a specific consensus, and able to fulfill required services.
The mining probability of each provider depends on the ratio between the provider’s computed lucky value
and the total lucky values of all providers in the network. In other words, if a provider has more resources
and a higher pledge amount, their proportion within the entire network increases, leading to a higher mining
probability.

The formula for calculating the lucky value of mining is as follows:

• w: Scaling parameter

• T_i: Number of tokens pledged by service provider i

• PoR_i: PoR quota of the service provider

Algorithm 6 Calculation of Lucky Value

procedure calcLuckValue(i, w = 0.6, staket hreshold = 500)
if T_i < stake_threshold or miner_i is not valid then
luckValue_i = 0
else
luckValue_i = (w*T_i + (1-w)*PoR_i)/(w*totalStakedTokens + (1-w)*totalPoR)
return luckValue_i

If the verification of the provider’s Proof of Resource (POR) challenge fails, the corresponding failed POR
quota of the cloud service provider will be deducted. This measure is implemented to ensure the reliability of
the resources provided by the provider. Verification failure indicates potential issues such as cheating or
insufficient resources, and appropriate penalties need to be imposed.

In case of a failed POR challenge verification, the cloud service provider will receive periodic POR
challenges. If the provider successfully meets the challenge, their qualification will be restored. However, if
the challenge is repeatedly failed, a continuous deduction of pledged currency will occur, eventually leading
to expulsion from the network. This ongoing process serves to constantly monitor the resource quality of
providers and ensure their ability to consistently deliver reliable services.

28
 7 Future Roadmap

6.3 Penalties for Consensus Participants

6.3.1 Cloud Service Provider

If the service becomes unavailable or the server resources do not align with the provided instructions, the
system will promptly remove the server provider. The provider will then have a 48-hour adjustment period to
rectify the issue. If the problem remains unresolved after 48 hours, the system will deduct the corresponding
amount of pledged coins and impose a daily interest rate of 1%. The number of pledged coins will be
determined based on the user’s usage during the contract period, which spans 1 year.

6.3.2 Validator

Every validator is required to stake a designated amount of tokens.

The verification node is pledged for a fixed duration of 1 year and can be released in one go after the expiration
of a specified number of blocks, as per the platform’s regulations.
If a validator remains offline for more than 48 consecutive hours, the pledged coins will be deducted at a rate
of 1% per hour.
To prevent validators from going offline due to network or other reasons, it is crucial to ensure the stability
and reliability of the verification node client. The following measures can be implemented to enhance the
performance and reliability of validator clients:

1. Utilize a high-performance server and network environment to ensure prompt response and efficient
handling of a large number of transaction requests.
2. Regularly conduct node maintenance and upgrades to ensure the client operates on the latest version,
capable of supporting the most recent functionalities and protocols.
3. Monitor and proactively address issues with the node client, promptly resolving any problems to
maintain normal operation.
4. The following example demonstrates the deduction of pledged coins: let’s assume a validator has
staked 1,000 coins and remains offline for 50 consecutive hours. In this case, 50% of the pledged
coins, equivalent to 500 coins, will be deducted. If the offline time is less than 1 hour, no coins will
be deducted from the pledge.

7 Future Roadmap

This work presents a clear and cohesive roadmap for the development of the InitVerse ecosystem. However,
we consider it to be just the initial phase of a decentralized cloud platform. In this chapter, we outline several
discussed improvements, including:

• Upgrading the POR resource consensus to incorporate zero-knowledge proofs (ZK)[9].

• Optimizing blockchain storage[10].
• Utilizing SNARK/STARK to enhance blockchain snapshots.
• Introducing a more concise SDL syntax.
• Enabling support for additional features of k8s.
• Implementing k8s container security isolation.
• Introducing a layered consensus protocol that allows users to partition operations or continue
processing transactions in temporary or permanent partitions.
• Enhancing the quote model.

29
 7 Future Roadmap

• Improving the deployment update model.

• Establishing a proof model for user storage resources.
• Ensuring persistence of user storage.
• Developing a solution for selling decentralized storage resources.
• Implementing a security scheme for user containers to verify and prevent illegal providers.
• Conducting game-theoretic analysis of InitVerse incentives.

30
 REFERENCES

References
[1] Nakamoto and Satoshi, “Bitcoin: A peer-to-peer electronic cash system,” Cryptography Mailing list at
[Link] 03 2009.
[2] G. Wood, “Ethereum: A secure decentralised generalised transaction ledger,” 2014. [Online]. Available:
[Link]
[3] L. Vayghan, M. Saied, M. Toeroe, and F. Khendek, “A kubernetes controller for managing the availability
of elastic microservice based stateful applications,” 2021.
[4] N. Dabit, “What is web3? the decentralized internet of the future explained,” 2021. [Online]. Available:
[Link]
[5] V. Mamatha, P. Swami, and D. Rao, “Research on secure distributed online certification authority,”
2012. [Online]. Available: [Link]
[6] K. Toyoda, K. Machi, Y. Ohtake, and A. Zhang, “Function-level bottleneck analysis of private proof-of-
authority ethereum blockchain,” 2020.
[7] B. Iddo, L. Charles, M. Alex, and R. Meni, “Proof of activity: Extending bitcoin’s proof of work via
proof of stake [extended abstract]y,” SIGMETRICS Perform. Eval. Rev., vol. 42, no. 3, p. 34–37, dec
2014. [Online]. Available: [Link]
[8] V. Buterin, “A next-generation smart contract and decentralized application platform. ethereum white
paper,” [Link], 2014. [Online]. Available: [Link]
[9] E. Ben-Sasson, A. Chiesa, D. Genkin, E. Tromer, and M. Virza, “Snarks for c: Verifying program
executions succinctly and in zero knowledge,” Cryptology ePrint Archive, Paper 2013/507, 2013.
[Online]. Available: [Link]
[10] P. Labs, “Filecoin: A cryptocurrency operated file storage network,” Online, 2014. [Online]. Avail-
able: [Link]
[Link]

31