Five solutions for implementing dApp extensions

The implementation of the scalability solution has arrived! This article explores some of the more scalable solutions that are currently available, the trade-offs between the different solutions, and the sharing of developer resources available for development.

Background: scalability issues

“Why is scalability difficult to achieve? I often talk about scalability trilemma, where blockchain systems must weigh between different features. It’s hard to have three features at the same time. One of them is decentralization, the other is scalability, and the third is security." — Vitalik Buterin, November 2017

Unlicensed public-chain platforms such as Bitcoin and Ethereum have chosen to optimize security and decentralization at Layer 1 rather than high transaction throughput. Anyone who wants to be a validator can participate, and becoming a verifier requires only a relatively small amount of time and money.

Nodes involved in mining in the PoW mechanism protect the entire blockchain network from 51% attacks (according to the price of April 2019, the attack costs of this attack on the Ethereum blockchain and the Bitcoin blockchain respectively It is about $100,000 per hour and more than $350,000).

Ethereum's truly unlicensed decentralized attributes and high security make it the platform of choice for the global economic trust layer and ensures the security of blockchain applications on the platform.

• Innovation workshop talks about blockchain: core business has not yet appeared
• Grab the PoS: Fire coins, fish ponds and the sea, leaving little room for you.
• Blockchain revenue is 260 million or 666,000 – easy to see the stock blockchain fog

However, security and decentralization come at the expense of scalability. Currently, Ethereum handles about 5 transactions per second, and if there are 6 transactions per second, there will be an overload problem, and in theory, the limit of simple transactions processed per second is 14-15. For any mainstream existing consumer or financial application, this number is a slap in the face.

“The core limitation is that a public blockchain like Ethereum requires every node in the network to process every transaction.” –Josh Stark, February 2018

In the Ethereum 2.0 phase, the Ethereum Foundation (EF) has an advanced roadmap to upgrade the Ethereum blockchain infrastructure, which will greatly improve the scalability of Ethereum in the next few years.

However, many projects currently build applications on the Ethereum platform, and these programs now need to be extended! In addition, based on the actual use cases of these applications, even if Serenity (Eth 2.0) has been implemented, you may not want all transactions to run on the Ethereum main network (ie the first tier), but instead choose the second tier solution. .

Current major challenges

• Slow — low transaction throughput, network latency dependency in full block;
• Expensive — users must pay gas for each transaction
• Poor user experience – the user must sign each transaction and wait for the transaction to be confirmed before the next transaction can be executed.

Scalability scheme

 

There are currently scalable solutions for extending transaction throughput, and of course there are other solutions that include under-chain calculations and other extension vectors, but this article will focus on the following expansion scenarios:

• Under-chain message signing (meta-transaction) — use Ethereum key pairs to sign messages under the chain, store and issue events, or pass events to P2P, and then update based on the content and signatures on those messages State on the chain;
• Payment channel — a chain of channels for value exchange between the two parties, and trading on the chain;
• Status channel — implements a chain-down channel that updates the status of the transaction between the two parties, and performs a final status update on the transaction on the chain;
• Sidechain x bridges – full-featured sidechains can be anchored to the Ethereum main network by bridging only contract and relay mechanisms;
• Plasma chain — A fully functional child chain periodically submits its state tree to the root chain (the Ethereum main network).

Compromise of the extensibility scheme

Description & implementation of the extended solution

The following extensibility solutions are open source and can be used by developers to build applications. Although all the extensions are in development and deployment is deployed between the main networks, security audits are strongly recommended (the implementation below) Projects for an extended program do not include projects that have not yet released available products or tokens).

01. Message Signature

• The user signs the message under the chain using the keccak256 hash algorithm using the key pair (public key + private key);
• Messages can be stored in IPFS (Interstellar File System) or DB (Database) and then processed in batches into a chain transaction;
• The message can also be delivered via P2P, and once the message (via the public key) is verified as coming from a valid or authorized party, the message can be entered as oracle into the smart contract of the primary network;
• The smart contract then receives and executes the information;
• During the ETH Berlin conference, MakerDAO proposed a solution for price forecasting under the chain using a message signing method.

Related resources :

• Karl Floersch — Hash algorithm and message signing basics:

Https://cryptoeconomics.study/

Mario Conti — Price prediction via chained signature messages (price oracle):

https://view.ly/v/Rt275OYzLCI1

Vitalik Buterin — oracle:

Https://blog.ethereum.org/2014/07/22/ethereum-and-oracles/ 02. Payment Channel & Status Channel

State channels consist of three main steps:

• Both parties to the transaction lock the initial blockchain status (such as the balance of the two parties) in a smart contract that is very similar to a multi-signed wallet. This ensures that funds in the wallet can be unlocked and transferred only after both parties have signed the update.
• Both parties implement the transaction by passing status updates between batches, such as updates to the balance. If the parties agree, a status update is "signed" and the status update is submitted to the smart contract to unlock the funds;
• When the parties complete the transaction, they each submit a status update to the smart contract. If the status updates submitted by both parties match, the status of the blockchains on both sides (such as the balance of both parties) will be unlocked, which is usually different from the initial state of both parties.

Payment channels:

The payment channel is a restricted state channel solution that is limited to payments for ETH or ERC20 tokens. Its simplified structure allows for greater throughput and more efficient design because only one (or several) states are updated, ie net balance.

Dispute resolution :

• Each status update signed by both parties to the transaction is assigned a "nounce", a unique number used to confirm the update. Newer nouce will ban old nonce.

• Once Party A submits a status update, a challenge period will be initiated. During this challenge period, Party B can submit a status update with an updated nonce. When the challenge period ends, updates with the latest nonce will be used to unlock the blockchain state and allocate funds appropriately.

Existing projects & implementations:

• Raiden (Thunder Network) is a chain payment channel solution for Ethereum expansion, which can bring close-range instant payment, low transaction cost and high scalability for Ethereum. The network works well with Ethereum and all digital tokens that comply with the ERC20 specification. Check out the link to access more content:

Https://kauri.io/article/e875bf0e94444f86b3dcdebc730f6c7f/v1/raiden:-generalized-state-channels

Connext is building an open source P2P micropayment infrastructure, and the project's first product uses a payment channel on the Ethereum blockchain . The payment channel operation aggregates many of the underlying transactions into a smaller number of on-chain transactions. Check out the link to access more content:

Https://kauri.io/article/ea598e8c666c413e8df0a6dd106a1c28/v1/connext:-peer-to-peer-payment-channels 03. Side chain x bridge (bridge)

Bridging (or relaying) passes information from the sidechain to the main network, and its sidechain runs its own consensus algorithm. Lock values ​​or states (or both) on the primary network and run dApps on the sidechain to collect and process transactions.

• The user mortgages the Ethereum or ERC20 token from the main network to bridge the contract.
• dApp runs as needed, then the user withdraws their Ethereum or ERC20 to the main network
• The user only pays two transactions for the gas — mortgage and withdrawal
• Users can also pay small transaction fees on the sidechain (Loom and POA have operating costs. Loom uses their own tokens to charge dApp fees, while POA requires users to pay for gas charges with POA tokens on the sidechain)

Related information :

• Watch the video: Parity Bridge Test Network — Kovan Ethereum – ERC20 Token Test Deployment
• Melonport and Colony are already developing and testing Parity bridges, and Swarm.City and Giveth are still helping to test arbitrary messaging.
• https://wiki.parity.io/Bridge; https://github.com/poanetwork/poa-bridge-contracts

Existing projects and implementation:

• The POA Network is a platform based on Ethereum that provides an open source framework for smart contracts. The POA Network is an Ethereum sidechain that uses the Proof of Authority as its consensus mechanism.

• Loom Ethereum's Layer 2 expansion solution focuses on social and gaming dApps that require very high throughput. The Loom SDK can generate a sidechain called dAppChain using a dPoS consensus that supports high scalability optimization.

• SKALE 's flexible side chains offer all the benefits of a standard full-capacity side chain and provide a secure network for truly decentralized networks. Elastic side chains are high performance, configurable and compatible with Ethereum/Web3.

04. Plasma Chain

Overview:

• Initialize the Plasma blockchain. Write a contract and submit it to the root chain;
• Localized calculations. It is only necessary to periodically submit the block hash of Plasma to the blockchain;
• Consensus rules in the definition of anti-counterfeiting. If an invalid block occurs, anyone can submit a security statement and roll back the transaction to the blockchain.

Existing projects and implementations :

• Including FourthStateLabs, OmiseGo, Kyokan, Plasma Group and other projects, see details:

Https://kauri.io/article/3103de2a3a874f348013b96d157451be/v7/plasma-roundup:-from-mvp-to-mainnet

• Kyokan MVP implements the smallest feasible Plasma that pays pure attention to payment use cases so that App developers can now experience Plasma and view the MVP tutorial:

Https://kauri.io/article/7f9e1c04f3964016806becc33003bdf3/v4/minimum-viable-plasma-the-kyokan-implementation

• Plasma Group is committed to creating an open Plasma implementation for the larger Ethereum community. Our mission is to drive the development of Layer 2 scalable solutions by exploring the full potential of the Plasma framework. understand more:

Https://kauri.io/public-profile/4c1f7c394b9fdbe23dcbe64e7b537b5354c71b24) Author | Andreas Wallendahl

Compile | Jhonny & Iris

We will continue to update Blocking; if you have any questions or suggestions, please contact us!