Jura Second Layer Solution
Introduction
Layer 2 blockchain technology is often referred to as an “off-chain” solution. Its main purpose is to scale blockchain transaction capacity while retaining the decentralization benefits of a distributed protocol.
Solving the scalability problem will significantly help with blockchain mainstream adoption.
To build a good blockchain ecosystem, we need a few things in the architecture to balance the needs of security, decentralization, and scalability. Basically, rather than changing the base protocol, we add smart contracts on the main blockchain protocol that interact with activities off-chain.
Layer 2 tech will help us scale the blockchain platforms in whatever industry they’re implemented in and compete with the likes of established, centralized systems like Visa or MasterCard.
Here we provide Jura’s second layer solution. In the Jura network, each account information is stored and processed in FUSUS data. The smart contract in Jura is an internal contract account which basically is also FUSUS data. Jura’s second layer solution caters to both off-chain state channel for both Jura and other existing decentralized technologies which desire to utilize the scalability of Jura to be ultrafast and near feeless while remaining decentralized and secure.
JURA Second Layer Protocol
The aim of Jura’s second layer is to incentivize and enforce smart contracts. The approach is simple:
Construct a smart contract on the main chain
The second layer’s history and its computation is committed to efficiently prove that something is in the set without storing it (saves storage)
If a conflict happens among the second layer participants, the Merkle proofs from different participants are broadcasted and committed to the main chain which after consensus comes to a decision (e.g. penalize the false participant). Currently, there are a lot of decentralized projects that can scale by using Jura’s second layer protocol.
JURA Smart Contract Specification
JURA smart contract, in the form of Fusus data, is initialized by external account and controlled by the code in that account. The receiving transactions and message calls form the DAG in the Fusus data structure which is the same process for checking balance by sending a balance-amount transaction to oneself. The sending transactions form a sending chain. These sending transactions then apply transactions and message calls to get you to a new state. Every sending transaction is also responsible for calculating the latest state.
Since the second layer solution doesn’t commit state transition for every sending transaction for the global ledger, it does make sense to specify a type of smart contract that also involves multiple participants and commits state transition during finality or conflict.
This type of smart contract can be inherited from other decentralized projects by transferring the contract deposit, initial state and rules for computation. We call this type of smart contract the second layer smart contract!
State Channel in JURA
To create a multi-participant off-chain state, we need to initialize a second layer smart contract with a certain amount of deposit. This will allow participants to interact within the smart contract: exchanging tokens, playing chess, insurance etc.
Participants will interact with each other by sending transactions or message calls to the smart contract which Fusus will record as a receiving transaction. If these transactions are independent and not order-sensitive, these transactions will form a DAG which has the potential to increase the throughput. But every time Fusus gets dependent transactions, it will generate a sending for the purpose of state transition and the order is naturally sorted out.
The receiving transactions between two consecutive sending transactions in a second layer smart contract are defined as an interaction round. It is followed by a state transaction which must be signed by all stakeholding participants.
For example, if the contract keeps the balance between Bob, Alice and David, if one state transition is Bob sending money to Alice, then the balanced output of Bob and Alice changed, but not David. This round of state transition must be signed by Alice and Bob, but not David. This is necessary to keep the proof minimal. In Fusus, the sending transactions hold the state transition whereas the second layer smart contract process off-chain state transition. Participants must agree in order to proceed.
This is what the process looks like:
The smart contract specifics a data in storage as “output at stake”
Next state contains the header of the previously signed “output at stake” to achieve security and finality between participants.
The smart contract keeps a “summary state”. If the state channel is a payment channel, the “summary state” records all deposits in this channel.
Note: As “output at stake” is an explicit result after computation, it solves the problem if participants have different environments and output is enforced to come to consensus off-chain to proceed. The ”summary state” must match the total state of all participants’ individual state in this channel. In a payment channel, it means that each participants’ balance inside this channel must add up to the total deposit in this channel.
The case for a participant to exit the channel is not as trivial as new participants. Exiting may happen when participants think validators withhold the transaction or simply want to quit this channel. Exiting requires on chain state update. Normally, if one wants to quit a channel, one must broadcast a state that in the channel after which its ”output at stake” no longer change. We do not expect one to commit the most current state as state transition happens very fast inside the channel. Once it provides the merkelized proof of that state, it needs to wait for some time for other participants’ attesting. If any other participant in that channel provides a newer signed state with some change to that participant state, which proves that this participant is dishonest, and fine will be paid.
In the next section, we will discuss the types of application which need to process a large number of transactions every second.
Stay tuned.
