Welcome to Litheum

In this book we hope to introduce some of the core concepts behind Litheum and help you get started building decentralized applications and infrastructure on Litheum or contributing to the development of our canonical implementation, LitheumCore.

What is Litheum

Litheum is a third generation blockchain incorporating a state machine in the form of an EVM and advanced capabilities for cross chain and third party data validation that enables a new paradigm in capabilities for decentralized application development.

By leveraging a new type of consensus which we call proof of performance Litheum is able to push the cost of blockchain usage down to physical limitations. Because proof of performance uses the blockchain itself as the difficulty, as demand for Litheum increases it both becomes more secure or performant.

In practical terms this means that the block size is determined via supply and demand dynamics rather than by an artificially imposed limitation. For more details you can find the light paper, deep dive, and White paper.

What this means for decentralized application and infrastructure development is that Litheum offers an opportunity to build experiences where gas is a much less troublesome consideration. Although blockchains must be more expensive than centralized solutions by nature of the fact that the state must be maintained by thousands of nodes, the nodes which run Litheum, the runners, are incentivized to deploy the hardware which is needed by users to run decentralized applications.

Because of the fundamental approach which we've taken to design proof of performance, which we call True Decentralization, and our understanding that a consensus is a win win between all players of the network, Litheum thrives under high usage. That is to say, as users and decentralized applications demand more, Litheum becomes more capable and a win win is maintained between the network, the decentralized application, it’s users.

This means that Litheum encourages usage of all sort rather than limiting usage which ultimately prices out the majority of decentralized applications. because the ultimate limits of with Litheum's capability are bound by the price point of deploying and maintaining Hardware, we believe that a new paradigm of decentralized applications can be realized.

Before we discuss the details of how to develop decentralized applications and infrastructure on Litheum we first want to discuss in some detail why we believe that Litheum is able to scale compromising decentralization, which you'll find in the next section.

We believe that this is important for application developers to understand as the concept of true decentralization can be leveraged to impact not only Litheum itself but also the applications which rest upon it.

Light Paper

New Light Paper Coming Soon

Old Light Paper

Light Paper

Litheum's Web3 Vision

The Litheum team believes the scalability problem can be solved in a more fundamental way. The Blockchain Trilemma is only applicable to chains which have only incentivized (and thereby decentralized) a subset of their functionality. These chains rely on volunteers to provide those un-incentivized functions of the network, which is why they can't scale safely.

The Litheum consensus, which we call Proof of Performance, is truly decentralized. This means that the Litheum consensus pays for all the things a blockchain needs to do, including synchronizing wallets, sharing transactions, and peer discovery. Because it is fully decentralized Litheum is able to scale without an issue, even becoming more secure as usage grows.

Micro-Finance and DeFAI

The Litheum team believes that the original vision of Blockchain Technology has been forgotten as we've slowly accepted that the technology cannot scale.

A peer-to-peer system enabled by on-chain scaling will unlock sovereignty, fungibility, privacy, and permissionless innovation in a way which has never been seen before.

Alongside the "traditional" blockchain defi apps including lending protocols, DEX trading, and liquidity pools, Litheum is pioneering a new paradigm focused on microtransactions that can process amounts as small as $0.1 with negligible fees. This represents a fundamental shift from current systems where high gas fees on networks like Ethereum make small transactions impractical.

By optimizing for micro-scale financial operations, Litheum enables novel use cases such as per-second yield generation, micro-lending for everyday purchases (like buying coffee with wrapped BTC or ETH), and rapid sub-$100 USDC transactions with leverage. These capabilities create new opportunities for financial inclusion and efficiency that weren't previously possible due to transaction cost barriers.

The platform's integration with traditional finance (Trad-Fi) through partnerships with institutions like SWIFT, combined with its focus on serving unbanked populations and small-scale farmers, demonstrates how microtransaction capabilities can bridge the gap between conventional banking and blockchain technology. This convergence is further enhanced by Litheum's AI-enabled DeFi layer, which allows for custom protocol solutions that cater to traditional business models while maintaining the benefits of decentralized systems. By making these services accessible at a micro scale, Litheum is working to fulfill blockchain's original promise of creating a truly inclusive, efficient, and permissionless financial system.

Global Scale

An ideal scaling solution would be one in which 10,000 miners were able to provide similar performance to modern Networks Applications (backbone IP switches, DNS root servers, reverse-proxy frontends, etc) at either 1/10,000th the speed or 10,000x the cost while remaining 100% decentralized. This seems like a reasonable expectation but current technology misses this mark by many orders of magnitude.

Bitcoin Miners deploy billions of dollars of infrastructure every year. Bitmain's IPO filings showed revenue of $2.3B between 2016-2018 and public statements have claimed over $5B of revenue in 2021. However, Bitcoin can only process 300M transactions per year. It takes at least $10 of infrastructure, maybe even $100, to deliver just 1 transaction per year.

Ethereum miners spent $15B on GPUs during the 2019-2022 bull market. With Ethereum rarely going above 1.2M transactions per day, this alone is $34 for 1 transaction per year. Currently there is over $50B of staked Ethereum. If we account for electricity, bandwidth, CPUs, harddrives, and other things, again, it would not be surprising if the total capital deployed was over $100 for 1 transaction per year.

It should be possible to have a blockchain that is 100k times more powerful than Bitcoin for the same infrastructure costs.

True Decentralization

Current consensus designs do not decentralize all the functions (Remote Procedure Calls/RPCs) which a blockchain needs.

For example, most blockchains do not provide a way for wallets to read from the chain, which is obviously critical. A wallet cannot make a transaction without first reading data from the chain and a user must be able to read data during every use-case. There are many other critical functions like this which are typically not paid for by the blockchain itself.

At Litheum we recognize that a Blockchain is a Network Application, not only a database or a chain of blocks. There are many functions which must be provided, because Litheum provides them all in a decentralized way, it is the only truly decentralized blockchain. All other blockchain which we're aware of require some amount of volunteerism. True Decentralization means that the network will not rely on any volunteerism or dubiously-motivated 3rd parties to provide any critical functionality.

The Danger of Un-incentivized Functions

When Infura went down on November 11, 2020, it took down the entire Ethereum ecosystem. Infura is an RPC provider that supports the Ethereum ecosystem. ConsenSys, which owns both Infura and Metamask, provides these services for free to Metamask users. Ethereum's so-called "DApps" rely on the services of a centralized service provider.

Infura claims to be "serving over 6 billion API requests per day and transferring roughly 1.6 petabytes of data per month". These RPCs are necessary components of the blockchain that Ethereum's consensus does not pay for.

Of course, a user can configure Metamask to point to their own server, or some other server, which is true, but this shows us why these RPCs stand in the way of scale. Either a user must pay for a 3rd party to run their server or they must run their own. In either case, the DApp developer is burdened with a cost that can't easily be passed to the users in a decentralized way.

"If every single DApp in the world is pointed to Infura, and we decided to turn that off, then we could, and the DApps would stop working. That's the concern and that's a valid concern."

"[We're] effectively supporting the entire Ethereum DApp ecosystem with the RPC traffic."

"Any DApp that uses Metamask also inherently depends on Infura (knowingly, or not). In that sense, nearly all DApps potentially depend on Infura."

"We didn't create the problem, we are just a Band-Aid on the problem. We are just providing a solution that is needed."

– Infura co-founder Michael Wuehler via CoinDesk

This effectively invalidates the value-proposition of decentralization.

"If we don't stop relying on Infura, the vision of Ethereum failed."

– Afri Schoedon, release manager for the Parity Ethereum client

No Blockchain we're aware of has solved this problem or discussed it in a simple or fundamental way.

This is why also Bitcoins blocks must remain so small. With small blocks, these problems are marginal enough that they go unnoticed or can be provided by volunteers.

Scale + Decentralization Synergy

Supporting Web3 scale on a platform that is not truly decentralized is simply impossible. To support global scale Web3 the cost of the unincentivized RPCs would be massive. Under typical consensus rules, any miner providing unincentivized functions is at a disadvantage from extra costs. This is the origin of the Trilemma.

However, when a chain is truly decentralized, the exact opposite is true. Ultimately the chain with the most fees can be the most secure. More fees means the nodes will be willing to post more collateral. More collateral means a more difficult 51% attack.

More fees = more security

Scale is Security

Because volunteers are not needed, i.e. miners do not need to volunteer to provide any extra RPCs not related to block production, there is no danger from scaling. Litheum can scale because it's truly decentralized!

Proof of Performance Details

True Decentralization = Global Scale

Other blockchains only incentivize a subset of the functionality needed. Typically, there is no incentivization for transaction propagation, block propagation, peer discovery, longest chain synchronization, or even wallet synchronization.

Small blocks vs big blocks

Small Blocks vs Big Blocks

The cost of these functions would grow if we made the blocks bigger, overburdening the volunteers who are funding these operations. Since volunteers need to provide these functions to maintain decentralization, these costs must be limited.

The usual solution to the danger of large unincentivized costs is to simply limit those costs. This is why typical Blockchain consensus designs set a maximum block size.

Supply and Demand

Global Scale via True Decentralization

On Litheum all RPC responses include a signature. By using these signatures Litheum can measure a node's participation in block production.

Litheum applies two techniques, input-incentivization and lucky-hash incentivization, to all the RPCs, eliminating all unincentivized costs from the blockchain.

Proof of Performance

Once unincentivized costs are removed, scale can grow freely bound only by the real costs of supply, i.e. the costs to aggregate, validate, verify, and propagate transactions.

Useful Work/Difficulty

All consensus designs require that a node doing out-of-consensus work be penalized, this is what we call the Difficulty. But difficult hashing is only added to the network to create an artificial Difficulty, it serves no other purpose, it does not provide any value to the user directly.

The real "work" that users want done by the network is the aggregation, validation, and propagation of transactions. Litheum simply uses this work, all the things a blockchain does, and uses that as the Difficulty in the consensus. This incentivizes Litheum Runners to deploy bandwidth, computation, and memory.

Litheum TPS

Litheum's throughput, transactions per second (TPS), is dynamic and computed algorithmically as part of the consensus by measuring supply and demand.

The fee paid by the user for a transaction is recalculated by the system as supply and demand changes, it is measured in LTH, we call this the Gas Price.

Additionally, Litheum blocks must contain some minimum total fees which we call the Block Fee. Litheum's Difficulty Adjustment Algorithm targets a block time of 10 seconds, the minimum Block Fee is decreased or increased if a block is produced faster or slower than the target time.

Proof of Performance measures the supply and demand for transactions and balances the Block Fee and Gas Price algorithmically. This determines the TPS of Litheum which is ultimately determined by real physical constraints (the cost of hardware) and the real demand of users.

Unlike other chains which claim to scale without addressing the fundamentals, Litheum allows market dynamics to determine how much a transaction should cost and how much hardware should be deployed in service of TPS.

The Block Fee and the Fee Price are adjusted algorithmically and together determine Litheum's throughput.

More details on this can be found in the whitepaper.

Litheum Nodes (Runners) Details

There are 3 type of nodes which participate in building Litheum's consensus: Block Runners, Transaction Runners, and Data Runners. Additionally, all wallets act as Lucky Hashers, which will be discussed below.

We call the mechanism used by Block Runners and Transaction Runners Input-Incentivization because the RPCs ultimately will produce some input to the chain, i.e. transactions.

Incentives

Input-Incentivized RPCs

In cases where the data being read from the Blockchain is later used as an input, the data being read can simply be signed and the provider can later be rewarded. We call these "Input-Incentivized RPCs".

This mechanism incentivizes Transaction propagation, Block propagation, and Wallet synchronization.

Input Incentivization

Transaction Runners collect transactions from wallets and compile them into Miniblocks which are then sent to Block Runners. Both Blocks and Miniblocks are signed by their sender.

Transaction Running helps the network propagate blocks by requiring that any Runner which wants to serve wallets needs to be synchronized to the latest block.

Transaction Running also improves Litheum's efficiency and allows the network to be more flexible. Some nodes will have different firewall policies or serve different subsets of the users.

Lucky-Hash-Incentivized RPCs

In cases where the data is only read, but never used as an input in a transaction, a lottery-like mechanism is used to create incentives. We call this the Lucky-Hash mechanism.

Lucky Hash Incentivization

Every wallet holding some LTH is a Lucky Hasher. Lucky Hashers are given chances to find a Lucky Hash each block. More LTH gives more chances. The Lucky Hash winner reads data from a chosen Data Runner and both are rewarded. The Data Runner is chosen fairly and randomly using onchain data.

The Lucky Hash and the data from the Data Runner are submitted in a special transaction to collect the rewards.

The Lucky Hasher has 1 week to collect the data from the Data Runner and submit it after a Lucky Hash has been found.

RPC Incentivization Summary

In a Proof-of-Work consensus the block producer wants to share a new block and other miners want to receive it, so these RPCs are incentivized indirectly. But note also that other miners beside the block producer do not want to share it.

RPCs	Non-PoP	Input Incentivized	Lucky-Hash Incentivized
Transaction Propagation	partial	✔	-
Wallet Sync	✗	✔	-
Block Propagation	partial	✔	✔
Peer Sync	partial	✔	✔
Peer Discovery	✗	✗	✔
Arbitrary Data	✗	✗	✔

Smart Contracts

The appeal of an in-chain VM is undeniable. The EVM has become the de-facto standard for smart contracts in the Blockchain space and Litheum will integrate the EVM.

However, the EVM requires permanent storage, the costs of which must be handled properly.

On Litheum LTH must be staked for each per byte of EVM storage. LTH will be locked when EVM storage is used. When the data is removed, the associated LTH will be unlocked.

The LTH-per-byte rate will be set, bounding the storage capabilities required for a Runner. The rate decreases smoothly over time and can be reviewed periodically by the Foundation.

Since only 100% of the available LTH could ever be staked, this gives a predictable upper bound on storage requirements for Runners. Note that the price of LTH does not affect the amount of storage available.

This not only solves the EVM permanent storage problem but also serves as a commodity-like-base for the value of LTH, which may appeal to some.

Staking

All runners must stake LTH for punitive purposes. An important distinction from typical Proof-of-Stake systems is that stake is not used as a means of selecting who participates in consensus. Stake only enables the ability to participate as long as the minimum is met. Its use is purely for punitive purposes. Prioritization of block production is based upon the ability of those participants to make a valid block most quickly.

Hardening Security with Inflation

more utility = more fees = more running = more security

Not only those creating transactions are getting some value from the blockchain, holders are also using the chain in a way.

The Litheum team believes it is fair to collect some kind of fee from holders to help pay the Runners who secure the chain. An inflationary mechanism offers a simple and fair way of collecting a sort of fee from the holders.

To accomplish this, every Lucky Hash Transaction comes with some extra LTH. The extra fee can only enter the system by being included into the block's fees and distributed to the other Runners participating in building consensus. Litheum will target 0.5% inflation per year, which we feel is a fair cost of securing an asset.

Governance

Litheum Labs is committed to establishing a sustainable governance mechanism before the launch of the Mainnet, with the ultimate goal of removing the founders and the Litheum Labs team from control of the project and placing control into the hands of the community.

To achieve this aspect of True Decentralization, Litheum Labs is exploring routes through which to establish a fully on-chain governance mechanism for Litheum. This would mean the full automation of all aspects of the Litheum decision-making process, from a proposal being conceived by the community to the deployment of the proposal.

Litheum Labs is working to develop solutions for the challenges associated with a fully on-chain decision-making process. For example, it is crucial that code proposals are reviewed for security flaws by trusted third parties before implementation. To address this challenge, we are developing mechanisms for allowing trusted auditors to receive compensation through a fully on-chain process while remaining responsible for any mistakes they make.

As we transition to a fully on-chain governance, we will also establish a non-profit foundation to execute the decisions of the community. The Foundation's constitution will prioritize the goal of moving the governance of Litheum entirely to on-chain and truly decentralized mechanisms.

Layer 2

The Litheum team envisions that layer 2 infrastructure such as storage and low-latency transactions will be part of the ultimate Web3 ecosystem. The PoP consensus can easily be tuned to offer these things and much more.

Conclusion

The Litheum team envisions everyone in the world having affordable access to decentralized Financial Freedom.

We believe that privacy and freedom delivered by Truly Decentralized technology can make the world a better place, that True Decentralization is simple and understandable, and that True Decentralization guarantees the ability for everyone access to decentralized technology.

We are committed to make sure that Litheum will enable massive scalability while remaining Reliable, Safe, Secure, and Trustable.

But we can't do any of this without you. Web3 will be a technological disruption, and we believe we have the best solution to the scaling problem. But Litheum is nothing without the community and the support of the people who believe in our vision who will help spread our message and our vision to every corner of the world.

Building DApps

Litheum is an EVM-compatible blockchain, which means that you can use all of the tooling and integration that is possible on other EVM-compatible blockchains.

When we say that a chain is EVM compatible, what we really mean is that it supports not only the EVM, but the standard JSON-RPC interface for wallets to communicate with a node in the network.

There is one very big difference between Litheum and other networks in the way in which wallets connect to the network, but we will address that in another section.

Litheum Testnet

rpc url: https://testnet.litheum.com
explorer url: https://explorer.litheum.com
network id: 1174
currency symbol: LTH

Configuring Hardhat

Hardhat is a development environment for Solidity development, so it is entirely fine to use it as a platform for developing and testing your smart contracts.

Hardhat can also be used to deploy your smart contracts to Litheum.

To install hardhat on your system (within npx), run:

npx hardhat

To create a new hardhat project, run:

mkdir my-hardhat-project
cd my-hardhat-project
npx hardhat init

Install dotenv:

npm install dotenv

Create a .env file and add your private key:

echo "PRIVATE_KEY=your_private_key_here" > .env

Add the following to your hardhat.config.ts file:

import { HardhatUserConfig } from "hardhat/config";
import "@nomicfoundation/hardhat-toolbox";

require('dotenv').config(); // Add this line
const { PRIVATE_KEY } = process.env; // Add this line

const config: HardhatUserConfig = {
  solidity: "0.8.9",
  networks: {
    ...SNIP...
    litheum: {  // Add this line
      url: `https://testnet.litheum.com`, // Add this line
      chainId: 1174, // Add this line
      loggingEnabled: true, // Add this line
      accounts: [`0x${PRIVATE_KEY}`], // Add this line
    },
  }
};

export default config;

Create a script directory:

mkdir script

Create a deploy.ts file in the script directory:

import { ethers } from "hardhat";

async function main() {

  const Lock = await ethers.getContractFactory("Lock");
  const lock = await Lock.deploy();

  await lock.deployed();

  console.log(`Contract deployed to ${lock.address}`);
}

// We recommend this pattern to be able to use async/await everywhere
// and properly handle errors.
main().catch((error) => {
  console.error(error);
  process.exitCode = 1;
});

npx hardhat run script/deploy.ts --network litheum

This will deploy your smart contracts to the Litheum testnet.

Connecting Metamask (or Rabby, etc)

Litheum has native support for Metamask.

Option 1: Adding Litheum Testnet to Metamask using chainlist

Go to here
- (or go to chainlist, type "Litheum" in the search bar and click on "Include Testnets")
click on "Connect Wallet"

Option 2: Adding Litheum Testnet to Metamask using the network configuration

Open Metamask and click on the network selector (upper left).
Click on "Add Custom Network"
In Chain ID field enter "1174"
By Network Name click "Suggested name: Litheum Test Network"
In RPC URL field enter "https://testnet.litheum.com"
By Currency Symbol click "Suggested currency symbol: LTH"
For Block explorer URL enter "https://explorer.litheum.com"
Click on "Save"

Blockchain Security

In this Chapter we will explain some of the theoretical origins of the design of Proof of Performance in hopes that this understanding will help you leverage Litheum better and to help you design decentralized applications and infrastructure that embrase the concept of True Decentralization.

The Origins of Blockchain Security

Often in discussions of blockchain security strong focus on cryptographic techniques overshadows a more fundamental analysis.

An important fact to realize when considering the origins of blockchain security is that all incentive is ultimately derived from utility. this may not immediately be obvious however something that most engineers in the space do understand.

If we first consider that a consensus can be generalized as a game built using cryptographic primitives to enable collateralized attestation then we can understand any type of consensus within this framework. To put it clearly, both the hashing hardware and a Proof of Work based consensus and the stake in a Proof of Stake based consensus can be understood as being a form of collateral. Those nodes which act within the rules of the consensus are rewarded for their collateral and behavior whereas those nodes which act against the consensus are penalized. That penalty is levied in the form of wasted electricity and capital in PoW or in the form of slashing is PoS. This punitive mechanism is critical to the design of a consensus which is why all steak-based consensuses must have a slashing mechanism for more information vitalics writings on what's known as the nothing at stake problem cab be found.

With this framework in our minds we can now consider that nodes must be incentivized to deploy their collateral. this is a purely economic consideration and we can see that it is impossible to achieve decentralized consensus without incentive for this collateral to be deployed. Further this incentive must be some form of payment to the nodes. this can come in two forms either a fee can be paid by the user when a transaction is included or an inflationary mechanism can be used to extract value from the token holders. In either case a fee must be born by the users. is there for reasonable to conclude that the users would only accept such a fee in exchange for some utility. this is actually quite well understood as the increased perception of the security of Bitcoin causes it to highest price this higher price incentivizes further deployment of difficulty solving collateral which in turn makes the chain more secure. the reason that users are willing to suffer an inflationary degradation is because of the perceived utility of holding the token. we can thereby understand that it is ultimately the perceived utility of the blockchain network which underpins it's security.

Because high throughput is also a form of utility it is thereby reasonable to conclude that a higher throughput chain could in theory also be more secure however there is an understanding currently within the blockchain industry that the exact opposite is true. The reason for this will be discussed in the next section.

Why previous Blockchains are intentionally limited

Although people may understand that utility is value and value is security, there is still a perception that blockchains cannot achieve both scale and decentralization.

The reason for this is actually quite simple, if viewed from the right perspective. A blockchain is a network application and when we view a blockchain in its entirety and enumerate all of its functionswhich are needed, I.E. the RPCs, we discover that not every RPC is incentivized by the typical consensus.

When we reframe our thinking and view a blockchain as a network application the idea of consensus can be understood more deeply. Although there is a tendency to focus on cryptography and block production in the context of consensus we can also consider consensus over an RPC. Specifically if we consider the incentives for a miner to share a block with another miner, in the case that the first miner has produced the block there is a consensus over the RPC. I.E. the block producer wants to send the block to the second miner and the second miner wants to receive the block so that it can continue to do work at the tip of the longest chain. it is actually the consensus on this RPC that enables the network to function, although many people see it as a sort of secondary effect of the difficult hash algorithum, it is in fact the primary effect which needs to be achieved by the consensus in order for the blockchain to work.

If we consider that data must be shared from the network to wallets and to other nodes which includes things like transactions in the mempool, EVM state data, and peer-to-peer metadata it immediately becomes clear that in fact there is no consensus for these RPCs. For this reason, if a chain is to remain decentralized, it iss critical that these RPCs be provided by volunteers. In order to ensure that the costs for these volunteer remains tolerable, the blockchain must be severely limited. This is why it is understaood that Bitcoin needs so-called "full nodes". This is also why there is a concern around the RPC problem since 2017 and a healthy skepticism towards chains which claim to be able to scale safely without discussing this issue directly.

With this understanding it should be simple to understand that the task of consensus design is to create an incentive for every RPC which is critical to the blockchain's function. This concept is what we call True Decentralization.

However there is still one issue which needs to be resolved. If there is no limit to the size of blocks then there is no limits on supply and demand and there is no mechanism for price discovery. When we say supply and demand we mean supply of transaction processing and demand for transaction processing, I.E. inclusion of a transaction into a block and it's propagation to the network within a block. We call this resource blockspace.

The solution to this issue is discussed in the next section.

Higher Fees versus Lower Fees

Because the end users want a low fee and the runners want a high fee, A balance needs to be struck. This is one of the trickier pieces of Litheums consensus.

There are two variables which must to be determined by this supply and demand mechanism. the first is the size of the block which is measured in LTH. The second is the gas price. These two variables determine the gas throughput of the system in combination with the block time. We do this by measuring the supply and demand and adjusting the variables.

REDACTED/CONFIDENTIAL. THE DETAILS OF THIS MECHANISM ARE CONFIDENTIAL AND WILL BE SHARED BEFORE MAINNET LAUNCH.

Utility is Security

Now that we understand that the root of blockchain security is based on utility we can discuss the security properties of Proof of Performance in more detail in this chapter.

How Big Blocks are More Secure

As we've seen in the previous chapter by eliminating the need for volunteers a consensus can avoid the need to be intentionally limited. But not only does Litheum avoid suffering security degradation at higher scale as we discussed in the previous chapter, Litheum also becomes more secure as the blocks become bigger.

To understand this it's i mportant to realize that with Proof of Performance bigger blocks are also more difficult to produce. We measure contribution to block production via the RPCs and the size of the blocks in fees. A fee paying transaction cannot be created without some node having provided data via an RPC to the wallet which is creating the transaction.

This can also be understood when we consider that utility is the ultimate origin of security as we discussed earlier.

PoP: The Blockchain is the Difficulty

Another way to understand proof of performance is that the blockchain itself is the difficulty.

In other words it is the actions of the network which are needed by other nodes in the network and by wallets which is what proof of performance measures in order to produce a block.

This perspective not only informs us about how Litheum is able to scale but also has implications for the subject of what's called now “Data Availability” or the ability for third parties nodes and wallets to receive data from the chain.

Because the rpcs are the difficulty, it's important that we only allow nodes to serve correct data. Serving incorrect data is considered out-of-consensus behavior and is slashable. A very helpful side effect of this approach is that it's much easier to communicate with Litheum as a network then for other stake based chains.

Data Availability under PoW

One very helpful side effect of the proof of work consensus is that the work can be independently evaluated by anyone even without fairly having access to the network. because the difficult has can be independently verified as containing a large amount of difficulty, if anyone has the block headers then with some reasonable assumptions it's easy to verify that a new block header or the current block header is Legitimate. and because it contains both half of the previous block and the Merkel root of the current block, these two cryptographic Primitives can be used to validate state.

Although this is a very clever mechanism, it's still suffers from scaling issue as it is difficult for a note or wallet to get such State including both block headers and transactions.

Data Availability under PoW

Proof of stake systems instead must rely on significant amounts of knowledge of the staking table to determine which validator sequencer or other node is permitted to create a state transition, I.E. block. Of course these proof of stake systems also suffer from the scaling issue which we've discussed.

Data Availability under PoP

Litheum on the other hand because the rpcs, I.E the network itself, is the difficulty, any data produced by nodes in the network is highly trustable as the production of falsified or incorrect data is considered a slashable offense as a necessary mechanism in the consensus.

By bootstrapping viaa this concept and including a list of nodes, i.e. the staking tables, via an RPC, Litheum enables wallets decentralized applications and nodes to communicate with itself in a more robust way which we will discuss in the next section.

Communicating with Litheum - The Security of Signed Data

Because the production of data from a node is a form of work or the difficulty in proof of performance, it is possible for third parties, wallets, and other nodes to communicate with Litheum as a network rather than communicating only with a single node.

Of course, in the end, a single node is communicated with in order to receive a response to an RPC. In other words when someone wants to communicate with Litheum the network will provide a list of nodes which then provide further data. of course this process must be bootstrapped and it's not possible to communicate with a node prior to knowing what node to communicate with, however even via a bootstrapping mechanism the correctness of these rpcs can also be bootstrapped once the data is received.

what this means is that cross chain or cross infrastructure Communications is available out of the box in a proof of performance context. for things like storage, bridges, and oracles this capability offers a natural platform.

We believe that a Proof-of-Performance-like mechanism or infrastructure which is built in a Truly Decentralized way offers a greatly superior means of building these infrastructural necessities in a decentralized way.

Bootstrapping Communication

TODO

Differences between Litheum and Others

Instant Finality

**Future Work**

Because there's no need for a fee market or a replace-by-fee mechanism on Litheum it's possible to implement instant finality in a very simple way.

A sent transaction on Litheum can never be replaced once it's been signed and sent. in the case that a second transaction using the same nonce is produced, any actor with one of the transactions can submit it in the case where the other is added to a block in order to slash the wallet, claiming the fees associated with the transactions as well as a potential additional penalty (if the wallet has funds).

However this system only guarantees payment risk up to the value of the fee, however, any additional funds held by the wallet are potentially at risk, as the wallet would not be able to guarantee to remove those funds before they are slashed.

For any given block height a wallet is able to send transactions to a limited number of Transaction Runners. if the wallet user wishes to prove that a transaction has been sent to some other actor, that actor can simply query the mempool of those Transaction Runners to see if the transaction has been broadcast.

In the future, Litheum-specific wallets and block explorers will support the ability for users to understand the strength of finality for a given transaction.

Building Infrastructure

**Future Work**

Because Litheum is able to guarantee a market-based and supply-based price for transactions it's possible to use Litheum as the game layer of many services which can be provided by nodes serving various technological at a kind of layer 2 position.

Additionally it's easier to properly design these payment and economic game layers of the systems in a way which properly distribute costs to the end user in a way which has long-term viability. in other words if a service has value then the end user should be willing to pay for it either directly or indirectly and in order for that service to remain decentralized it's best for that payment channel to be directed on chain.

Another way to think about this is that Litheum is the ultimate platform for Depin.

As soon as the layer 1 is complete the Litheum team will be focusing on various Solutions leveraging these techniques which should assist dap developers to build truly decentralized experiences. this includes services for cross chain and off chain data communications, storage, and real time instant settlement.

However, we also prefer for these service functions to be built by 3rd parties. Please reach out if you're interested to understand more about building Truly Decentralized infrastructure and services.

Storage: Litheum Depot

**Future Work**

Building a storage system in a decentralized way is both a litmus test for the web3 Industry to demonstrate its capability as storage is a fairly simple and universally needed use case, however it is also proven to be difficult to implement in a way which can balance the needs of all the actors in the system including the service providers, the service consumers, and the end-users.

We believe that different every storage use cases need different solutions. Your balance of Litheum should be stored on the Truly Decentralized and highly robuse base layer, however we don't need the CSS for our blog stored in the same way. Additionally there may be middle ground for mission critical data which needs to be robustly stored and cannot suffer any downtime but which doesn't need to be stored on the base layer.

There are multiple ways to consider using Litheum and Proof of Performance as part of a storage solution.

The first and most simple is to simply use the base layer, Litheum itself, for storage.

A second solution which may be simple and robust is a blockchain like a system which uses Litheum for its economics, Proof of Performance for its network incentives, and an additional Arweave-inspired rule added to the consensus rules to guarantee storage and availability of historical data. However it's important to note that this system would provide much better performance than are we've as the weave only provides need for data to be validated but doesn't provide a means for that historical data to be provided to end users and other nodes in the network.

I'm more flexible yet complex solution may involve uptime guarantees via collateralized services providers built with a game similar to Filecoin. Again the economic game itself would leverage the LTH token and the base Litheum layer for economic relationships between actors in this system.

Cross-chain and Off-chain Communication

**Future Work**

It is easy to push data to a blockchain, however to facilitate fetching data from off-chain resources such as other chains or centralized services a different technique is needed.

This critical capability is needed for infrastructure or services such as oracles and bridges.

In order to support this the Litheum team is proposing to build a fetch service which leverages the base layer for its game and incentivizes nodes which we call Fetchers to request data from third parties. This data is then encrypted, added to the chain, and later revealed. Those Fetchers which agree on the result (as determined by a function the requestor provides) are rewarded.