Lynx: Vision For A Truly Open And Decentralized Internet

Currently, blockchain technology faces several challenges related to scalability, extensibility, and decentralization. These problems have become exceptionally prominent recently due to the massive increase in usage of blockchain networks and its underlying technologies. We believe that these issues originate from existing frameworks for consensus and participation in modern blockchain protocols. This paper proposes a number of innovations to revitalize decentralized networks including an high performant blockchain architecture, custom subnetwork implementations, and a probabilistic BFT consensus mechanism for rapid transactional finality. By passively securing information through already essential interactions between nodes, we provide practical means for achieving rapid finality without undermining network efficiency. Additionally, by enabling nodes to access and participate on the network without requiring intensive financial or technological prerequisites, we introduce a “zero-barrier” entry point for all devices. All things considered, we put forward an open-source and readily accessible protocol for powering expeditious transfers of digital information across a scalable and secure network.

Preface

This paper is intended to be a technical overview of one of the many possible paths that may be taken in further advancing the current blockchain model, included with some reasoning as to why this direction is practical. It presents, in as much detail as possible, the components of blockchain technology which need to be revised along with their respective technical solutions. It should be noted that this paper is not intended to be a formal specification or otherwise. It is not intended to be complete nor to be a final product. Additionally, this paper should not be expected to outline the nonessential components of the protocol like programming languages, APIs, or unrelated blockchain concepts. The several ideas covered in this paper will be subject to change or removal depending on how the community assesses them. This paper should be considered strictly experimental and only used as a blueprint for the initial development of the idea. It is expected that large portions of this paper will be revised as the concepts are implemented into real world applications. This document includes a core description of the Lynx Protocol with potential concepts to consider for implementation. It is planned that the core description will be used as the basis for several proof-of-concepts. Furthermore, the minimum viable product would use this framework together with additional concepts provided by the community in order for the project to reach its goals.

Blockchain and Existing Concepts
Current State of Blockchain

Blockchain technology has made tremendous strides in terms of developing and improving current network infrastructure. Compared to traditional network models where a central authority governs and regulates what information is able to be stored and transmitted on a platform, blockchain has distributed this power among its participants. However, in order to participate in most modern blockchain protocols, a node must meet two requirements: Complete Ledger: Each node must have a complete ledger or blockchain. Specifically, each node must synchronize their blockchain with the rest of the network before participating in important operations such as validation. This becomes an issue when a network matures and millions of transactions are included in the blockchain. For instance, Bitcoin’s current state includes 390 GB worth of information as of 2022, while the average mobile phone can store as much as 128 GB. Clearly, this limits accessibility to the network because individuals only in possession of performant hardware and a significant amount of disk space can participate. Financial Stake: Each node must stake something of value in order to become a network validator. In proof-of-stake systems, it is required that all participants provide upfront collateral as means for becoming a transaction validator. Networks that are developed using this model such as the highly anticipated Ethereum 2.0, require that nodes stake 32 ETH which is approximately $100,000 or 3 BTC. On the other hand, proof-of-work networks also require collateral, however, the stake amount is undefined and is directly correlated to the amount of cryptographic “work” a node is willing to contribute. Although both of these methods provide practical frameworks for validating transactions and securing a network, they provide innate financial barriers for less fortunate individuals to access a given peer-to-peer network. These two issues are the primary limiting factors discouraging widespread adoption of blockchain technologies. As such, modifications to the current blockchain standard are unequivocally necessary in order to increase accessibility and decentralization of peer-to-peer networks.

Global State

State is a term used to describe the particular condition a given system is in at a specific time. In blockchain applications, the state can be described as a “snapshot” that represents an entire blockchain after a new state transition occurs. State transitions in blockchain refer to the process of appending a new block to the end of the chain. Each block includes information relating to account balances, transactions, and storage. Usually, state is not determined by iterating through an entire blockchain because that would be extremely inefficient and timely as a blockchain grows. Instead, a cryptographic hash called a root hash is generated using the information contained in the newly appended block and the block preceding it. Since each block’s state includes the state of the previous block and thus all blocks in the blockchain, a root hash provides an exceptionally productive and secure method for representing state in blockchain applications.

Merkle Patricia TreeFIGURE 1. A simplified overview of a Modified Merkle Patricia Trie. Starting from the bottom, pairs of buckets containing information are concatenated together and hashed. This process is repeated until only one hash exists. This hash at the top of the trie represents the root hash. If any information is modified within the original trie (left), it is easy to detect this change as there will be an inconsistency existing somewhere up the chain in the modified trie (right).

In blockchain networks like Ethereum, state is represented using a data structure called a Modified Merkle Patricia Trie. This trie structure is responsible for generating root hashes representing core information essential to the functionality of the network. For instance, a specific Modified Merkle Patricia Trie, known as a World State Trie, is used to keep information relating to all Ethereum accounts up to date. The World State Trie can be seen as a global state that is constantly referred to and updated by transaction executions. It should be noted that when an Ethereum account is updated, the entire state of the network is changed as well.

Smart Contracts

In reality, engaging in trade with another individual usually requires two things: a contract and a third party to ensure that there are no breaches of that contract. There are several problems inherent to this framework. First of all, both parties must have faith in each other to follow through with their end of the contract. This leads to even more discrepancies as there could be issues relating to interpretation of the contract, competency, and even time constraints. Additionally, both parties have to trust that the third party responsible for ensuring the contract does not act with malicious intent. For instance, a third party could intercept and steal the item of value being transferred or they could have a personal bias favoring one of the parties. All things considered, traditional contracts are exceptionally poor in assuring that both parties will execute. Fortunately, smart contracts provide a method for two parties to engage in trade without any trust being established. Smart contracts are self-executing contracts that are made publicly available on a blockchain. Similarly to a traditional contract, they include written terms of agreement between two parties. However, instead of the terms being inscribed on a legal document, they are directly written in lines of code. Since smart contracts run on a blockchain, they can not be controlled by a third party. Rather, a smart contract is considered self-executing as its code can only be run when certain conditions are met. Probably one of the most simple and popular analogies for smart contracts is to think of them as a vending machine. In this example, an individual provides an input, usually in the form of an item selection and money, and the machine dispenses your snack without another trusted person being present. This idea of an autonomous agent facilitating transactions can pertain to a greater number of applications relating to ownership, finance, and even governance. As such, smart contracts are essential to blockchain systems and provide a multitude of interfaces for individuals to interact with.

Decentralization's Lack of Adoption

Regardless of the technological potential that blockchain offers, the world has yet to fully experience a complete migration to decentralized products. We believe this is due to a number of failures inherent to existing blockchain frameworks such as issues relating to information centrality, scalability, accessibility, and extensibility. Information Centrality: The idea that information can only be managed and stored by one or very few individuals due to technological, geographical, or financial constraints. In regards to blockchain, only individuals in possession of premium hardware can store a complete ledger. As a network matures, it becomes exponentially more difficult for nodes to participate because of spatial constraints. Scalability: The ability for a network to efficiently manage throughput, especially during peak conditions when resources are exhausted. Due to the outdated mechanisms powering existing blockchain applications, networks are unable to meet demand when there are a significant amount of network requests submitted. Ultimately, this leads to a considerable decrease in throughput and exceedingly high fees. Accessibility: The quality of being able to connect to and participate on a network. Current consensus mechanisms require that all network participants provide a financial and/or spatial stake. In most blockchain environments, a complete ledger and financial stake of fiat or digital currency are required to actively participate in the validation of transactions. Extensibility: The ability to support a wide range of applications with new capabilities or functionalities. In current frameworks for decentralized applications, the number of network requests a user is able to make directly corresponds to their financial wellbeing. To put it simply, the more financially well off an individual is, the more use they can get out an application. In smart contract supported networks, this discrepancy exists because there are no alternative methods for nodes to provide the necessary computing power and storage to operate an application without requiring upfront transaction fees. Currently, we intend to address all of these problems with improvements to the current framework of blockchain. That said, we believe that the Lynx Protocol will also serve as a vehicle for solving even more complex problems inherent to present decentralized applications as the idea further develops.

Modern Consensus Protocols

Current algorithms for consensus on peer-to-peer networks provide reliable methods for keeping information consistent among its participants. However, they do so by synchronizing a global state which all nodes use to validate transactions to build on top of the blockchain. By maintaining a common global state, nodes can continue to work together on processing transactions. However, an issue arises when a network is subject to a high amount of demand. This is because consensus for agreeing on a new state change can only be provided by one node. Thus, if there were an influx of transactions being submitted to the network, the burden of providing consensus would be limited to that node’s ability to collect transactions and propose a new block. Synchrony in current blockchain consensus mechanisms is devastating to the throughput of a network because it requires that all participants be in agreement before continuing their processes. This applies equally to the two main consensus algorithms: proof-of-work and proof-of-stake. Proof-of-work is an older consensus protocol primarily used by Bitcoin and Ethereum which involves the utilization of computational work to determine the current state of a blockchain. On the other hand, proof-of-stake, a more modern and green approach, involves delegating a network’s processing power to a subset of nodes called Validators. These particular nodes have provided some form of monetary stake in order to take on the responsibility of maintaining the integrity of the network. Information is kept consistent by penalizing validators acting with malicious intent and rewarding honest validators for their contribution to the network. While staking provides its own set of challenges, synchrony on blockchain networks is primarily responsible for exacerbating limitations related to throughput. Therefore, it seems rational that one reasonable direction to explore, as a path to a more scalable and decentralized platform, is to provide methods in which network participants are able to asynchronously process transactions without undermining the security of the network. This is primarily how the Lynx Protocol plans to solve blockchain’s inherent problem of scalability.

Lynx

The intent of Lynx is to create a rapidly scalable platform for developing decentralized applications, providing a number of key innovations that enable high throughput and security across a peer-to-peer network. Lynx does this by utilizing a modified version of proof of history, a performant blockchain infrastructure based on cryptographic proofs using sequential squaring. Combined with a rapidly scalable and low overhead consensus protocol, Snowball Consensus, peers are able to add to their local ledger without the need for querying an entire network. Unlike other blockchain-based networks, Lynx is able to provide its users with fee-less computational power and storage through the use of application specific subnetworks. Nodes are then able to receive compensation proportionate to the amount of services they provide for a given application. This creates a significant amount of opportunities for “freemium” applications where users are not charged for using network storage. Additionally, like other Turing-complete platforms, Lynx allows for transfers of ownership, custom transaction formats, and state-transition functions made possible by smart contract deployment. With a plethora of innovations, Lynx plans to provide users with a high throughput, decentralized platform without the need for sacrificing its security.

Parties: Application Specific Subnetworks

Currently, frameworks for decentralized applications (dApps) provide very limited options in regards to utility. According to Ethereum, there are only three types of applications: financial, semi-financial, and decentralized governance applications. Although these examples are revolutionary compared to traditional programs, it becomes obvious that decentralized applications are not utilizing their full potential. Much like traditional, centralized products, dApps should be able to serve a wider range of programs such as multiplayer video games, social media platforms, web browsers, educational software, and so much more. However, because blockchain applications require that nodes must store a global state, it becomes impossible for the entire network or a subset of nodes to act like a truly decentralized backend. As such, we propose a framework for application specific subnetworks called parties in which nodes can opt in to contribute computing power and storage for any given application without undermining the network’s security. Similar to how neighborhoods have their own specific rules or local ordinances that only apply to their residences, parties have their own set of rules pertaining to its fees, security, and tokenomics. Lynx’s consensus mechanism provides a general protocol for processing information which parties will use as a basis. On top of that, a party can create additional rules which best suits its application. For example, a party which hosts multiplayer video games may require that all nodes don’t collect a transaction fee when processing a user’s network request. Given the high frequency nature of online video games, it would not be realistic to incur a cost to a player for every time they interact with the network. Additionally, parties are able to create their own network tokens, essentially subnetwork-specific cryptocurrencies used to facilitate transactions. Each subnetwork’s economy can be made with custom rules relating to tokenomics and issuance that best suit its applications’ needs. It should also be noted that since parties inherit the qualities of its parent network, LX transactions can also be processed by communicating with the entire Lynx Network in addition to the subnetwork. Lastly, due to some applications needing more security than others, a party may require that a certain threshold of consensus be achieved before assuming finality. Applications relating to finance, governance, or any platform responsible for transferring sensitive information may consider this necessary in order for the application to operate as planned. Much like existing decentralized applications, parties are dependent on smart contracts to handle server-side operations. However, unlike existing frameworks, it is not required that all nodes store smart contracts as a part of their global state. Thanks to distributed state chains, nodes can optionally decide to maintain the state of a contract account if they deem it financially viable for them. But how can a node consider whether storing a contract is worth it to them on a subnetwork where fees are nonexistent? Compensation for nodes lending their computing power and storage does not have to be direct. For instance, nodes can receive indirect compensation by issuing themselves network tokens proportional to the amount of computational work they have carried out. In freemium subnetworks, in-app purchases and fees not relating to the primary service provided by the application, can be pooled to support participating nodes. The network tokens generated can then be swapped with LX or other digital assets existing in the pool to ultimately receive proportional compensation.

Applications

In general, applications that require a significant amount of smart contract calls are well-suited for utilizing the Lynx Network. Due to high transaction output and party implementation, decentralized applications will be able to thrive with minimal or non-existent transaction fees. Much like Ethereum and other smart contract supported blockchains, Lynx will be able to provide users with more powerful ways of creating token systems, financial derivatives, and decentralized governance. In addition to these essential decentralized applications, Lynx can also support the following:

Freemium Application Models

Lynx's implementation of parties enables developers to make free-to-use applications. Like traditional freemium products, in-app monetizations still exist as means for providing incentives for nodes to contribute computing power and storage. However, unlike decentralized applications on blockchain based networks, transaction fees are not required from users for essential operations on the platform. For example, a battle royale styled multiplayer video game could benefit immensely from the use of parties. Providing a zero-cost financial barrier maximizes users interaction on the platform and even increases transactions of in-app purchases. In the case of video games, money pooled from in-game cosmetics could potentially be more than enough compensation for maintaining the network.

Video Games

An open source video game utilizing Lynx's party feature can benefit the gaming community tremendously. Unlike blockchain-based games, nodes can provide computing power and storage for users without having to pay a fee for each network request. This provides for an optimal gaming experience because users will be less concerned about the financial risk involved with just casually playing the game. Utilizing a video game's subnetwork, a popular game can securely process user interaction by acting as a decentralized backend. Instead of directing all backend requests to a centralized server like traditional multiplayer video games, a player's request will be processed by the entire subnetwork. By making use of proof-of-consensus, a player will receive rapid responses from the network with extremely low latency. It should also be noted that since a subnetwork is decentralized, if outages were to occur, the network would still remain live. For as long as nodes exist on the subnetwork, the game should continue to run without interruption. Competitive gaming has grown exponentially in the past decade with thousands of tournaments being held annually. However, due to the centralized nature of the operations necessary to run a tournament, competitors have not experienced a fair and quantitatively-based competitive setting. Utilizing Lynx's distributed ledger, smart contracts listening to in-game events can accurately depict the winner of a match and even distribute prize-money to competitors. Smart contracts can be replicated to be used for large-scale tournaments or minor wager matches involving just two individuals.

Video Streaming

Transcoding a video can be a very expensive process. It’s one of the hidden costs that consumers do not see directly or understand. However, from a developer perspective, minimizing these costs are essential to the success of the underlying product. A solution to this problem is to distribute the computing power of streaming. By creating a party in which nodes are given video data to transcode, users can experience uninterrupted streams relating to their favorite topics. In order to provide this service, network transcoders must receive incentives proportional to the computing power they offer. These incentives can be given out in the form of network tokens. Combined with in-app monetization like platform-specific emoticons, video advertisements, or transaction fees from streamer donations, video miners can swap out their network tokens for LX pooled from those sources of income.

High Frequency Trading

In blockchain based applications, high frequency trading is directly based on a network's block time speed. This is because transactions or trades are not final until blocks are ordered and validated by the entire network. Using distributed state chains as a data structure makes the transition of ownership of digital products seamless. These trades can be made using sub-currencies representing assets like gold or company stocks, governance tokens, and even tokens wrapped to the price of other cryptocurrencies. Due to throughput on the Lynx network being so high and minimal computing power to process transactions, transaction fees will be minimized to incentivize more state transitions.

Decentralized Health Monitoring

The Internet of Things describes physical objects that monitor and exchange real world data with other devices and systems. Currently in decentralized applications, real world data is computed by oracle nodes, a group of specialized nodes who report on a datapoint. While this is a great solution for information that is public and readily available for anyone to retrieve, it fails to touch on information that is private like data relating to an individual’s health. Using sensors included in digital wearables such as Apple Watch, Fitbit, or Samsung’s Galaxy Watch, individuals can transmit their sensitive health information in an anonymous setting. The data collected can be aggregated and then used to identify unusual health patterns. By sending an alert to the user, an individual can seek medical attention to prevent a further decline in health. As this idea further develops, we plan to see technology specifically designed for this application in the form of implants and other various medical devices.

Miscellanea and Concerns
Proof-Of-Consensus
Proof-Of-ConsensusFIGURE 3. Basic overview of the process included in providing a proof of consensus. Nodes will sign transaction approvals with their private key in order to generate a 512-bit bit string. The bit string is completely unique to that node’s account. As such, attempting to modify a proof of consensus is infeasible unless you are in possession of its private key.

Consensus between two parties is an essential task when transferring information. Given the fact that peer-to-peer networks are exactly that, a trustless platform for rapid exchanges of information, network participants must always have protocols in place for keeping information consistent while acting independently from the rest of the network. Traditional methods for consensus involve selecting a single node or block leader to propose a collection of transactions to be added to a network’s blockchain. Although it is assumed that almost all nodes connected to a network have the technological ability to validate and secure a block, almost all modern blockchain protocols favor designating this power to a single node. Centralizing the act of block validation undermines a network’s efficiency immensely. However, given the synchronous nature of blockchain, this the most practical method for keeping information consistent in a decentralized manner. Sacrificing efficiency for consensus in blockchain applications is the root problem of all issues related to scalability. As such, creating a new protocol in which all network participants are able to contribute to the processing of a transaction, will be necessary for exponentially increasing the throughput of a network. Lynx’s proof-of-consensus algorithm provides an asynchronous method for maintaining network consistency while distributing the processing power for securing transactions. The steps involved for processing a transaction are as follows:

  1. A transaction is created, signed, and broadcasted to the rest of the network.

  2. Nodes across the network receive the transaction and attempt to validate it. If the transaction is deemed well-formed and valid, approve the transaction by signing its data package. If not, ignore it and restart from step #1.

  3. Broadcast and receive signatures of approval to the rest of the network.

  4. Sign incoming signatures of approval and check if the 512-bit output begins with a sequence of consecutive zeros longer than any already existing bit string provided by the network.

  5. If the bit string output does in fact begin with a sequence of consecutive zeros longer than any already existing, broadcast that information to the rest of the network as proof of collecting consensus.

Energy Efficiency

Mining in a proof-of-consensus system is very similar to Bitcoin’s proof-of-work concept as it involves utilizing a cryptographic function to provide evidence of consensus. However, what differentiates between the two and makes proof-of-consensus an exponentially more efficient and green solution is that the computational power used to process a transaction is strictly limited to the resources provided by the network. In proof-of-work, computational power is bounded by access to real world resources, usually in the form of electricity. However, since peer-to-peer networks are essentially virtual economies, its resources are purely virtual as well. In the case of Lynx, a node’s ability to sign incoming transaction approvals prohibits any excessive energy use because there are only so many participants on the network. If an attacker were to create an excessive amount of accounts and flood the network with approval attestations, then they only would be benefitting the network as they would provide more consensus while only incurring electricity and storage costs to themselves.

All of these actions both result in the proof of consensus being inconsistent with the corresponding account state. If any transaction data was modified, the account state’s 512-bit hash along with any succeeding states’ hash would show that any amount of information was changed as the chain would be broken. Comparably, if any data pertaining to an account state was changed, its hash would also be inconsistent with subsequent account states. If an attacker were to attempt to modify a proof of consensus provided by another node, it would be infeasible for them to do so because they would need access to their private key in order for the rest of the network to consider it valid. A way around this would be to randomly generate a 512-bit hash that would miraculously correspond with a Lynx account. However, the probability of this occurring is astronomically miniscule and would ultimately incur ridiculous financial costs to the attacker.

51% Attacks

A 51% attack is perhaps the problem most feared in the blockchain industry because it allows for nodes to double spend. In a proof-of-work environment, 51% attacks occur when a single miner or mining group takes majority control of the network's hash power. If this were to take place, the attacker would be able to hijack the blockchain and ultimately confirm blocks with illegitimate transactions. Attacks like this require a significant amount of computing power and coordination which makes it extremely difficult to carry out. Similarly, in proof-of-stake based validation systems, a 51% attack takes place when a validator controls the majority of all staked currency in a given network. If done correctly, the attacker would be able to append faulty blocks to the blockchain and slash whatever stakes they please. In proof-of-consensus, a 51% attack occurs when an individual or group is in possession of 51% of all node identities on the network. Fortunately, this is an extremely difficult task to accomplish due to the high electricity and storage costs that would be incurred on the attacker from repeatedly downloading the current state of an account. Additionally, the number of transaction approvals needed to be downloaded and signed to generate a proof of consensus increases exponentially with every added account made by the attacker. The number of approvals needed to be downloaded and signed by an attacker can be represented by this equation:

`A = (n * (n - 1)) + L`
  • Let A represent the number of approvals needed to be downloaded and signed by an attacker,

  • Let n represent the number of actively participating accounts generated by the attacker,

  • Let L represent the number of actively participating accounts owned by the rest of the Lynx Network.

Unlike other blockchain protocols, proof-of-consensus does not incentivize mining pools. Due to the hash power necessary to provide a proof of consensus being limited to an account, it would be infeasible to coordinate a group of miners to share the rewards without having to have some amount of trust that the account who generated the proof of consensus would disperse those funds to the rest of the pool. As such, mining pools with 51% control of a network can not exist on Lynx.

Conclusion

The Lynx Network was originally conceived as a new protocol for decentralizing computation and storage for nodes. By enabling network participants with an incomplete ledger and lack of stake to participate in the validation of incoming transactions, centralization ceases to be an issue. Not only does the Lynx Protocol give more freedom to nodes to make well informed and independent decisions, but it provides the necessary tools for a network to handle rapid expansion. Additionally, the possibilities of applications utilizing the Lynx Network are endless with subnetwork parties enabling developers to provide computing power and storage to users without incurring a cost. Unlike other blockchain-based networks, applications with persistent network requests like multiplayer video games and video streaming will be able to exist in a decentralized manner. All things considered, the Lynx Network provides a next-level smart contract supported network with an array of new decentralized applications for the next generation of cryptocurrency.

References
  1. Bitcoin Whitepaper
  2. Ethereum Whitepaper
  3. Polkadot Whitepaper
  4. Merkle Trie
  5. Patricia Trie
    Table of Contents
    Lynx: Vision For A Truly Open And Decentralized Internet
    Preface
    Blockchain and Existing Concepts
    Current State of Blockchain
    Global State
    Smart Contracts
    Decentralization's Lack of Adoption
    Modern Consensus Protocols
    Lynx
    Lynx Accounts
    Distributed State Chain
    Proof-Of-Consensus and Mining
    Parties: Application Specific Subnetworks
    Applications
    Freemium Application Models
    Video Games
    Video Streaming
    High Frequency Trading
    Decentralized Health Monitoring
    Miscellanea and Concerns
    Energy Efficiency
    Modifying a Distributed State Chain
    51% Attacks
    Conclusion
    References

Want to Get Involved?

Join The CommunityJoin The Community

or learn more about the Lynx Protocol

Discord logo
Github logo
Twitter logo
Linkedin logo
© 2022 Lynx Foundation. All rights reserved