Extensible payment engine StarksPay: When lightning network meets STARKs

Author: Tom Brand, Uri Kolodny & Avihu Levy translation & proofreading: stormpang & A sword

Source: Ethereum fans

Editor's Note: The original title is "Introduction | StarksPay: When Lightning Network Meets STARKs"

Long story short: StarkPay is a scalable payment engine based on STARK technology that addresses many of the shortcomings of Lightning, the Layer 2 payment solution.

• Bitcoin Investment God: How to quickly filter out 1% of valuable tokens
• The road to the Internet, the blockchain is back
• In just 21 days, 18 provincial and municipal leaders voiced the blockchain, and entrepreneurs may welcome the biggest policy dividend!

-Image Source: Unsplash, author: Cade Roberts –

StarkWare's first STARK technology application is a Layer-2 scalable engine. We recently released StarkDEX, a decentralized exchange (DEX) scalable engine (see the link for early results).

We applied the scalable engine to the cryptocurrency payment scenario and built the StarkPay. The emergence of stable currency satisfies the scholastic currency as a necessary medium for the exchange medium. However, the ecosystem still lacks an extensible payment system. We believe that StarkPay can meet this need.

This article will compare and analyze StarkPay and Lightning Networks (the most famous bitcoin payment scalability solution). We will first review the advantages and disadvantages of the lightning network. Then, explain the StarkPay infrastructure and give an example of its execution flow. Finally, analyze the advantages and disadvantages of StarkPay, as well as the improvement of the shortcomings.

This article will not discuss the privacy protection aspects of the two programs.

Lightning network

Since Poon and Dryja released the white paper in 2016, Lightning Networks has attracted widespread public attention. The Lightning Network currently has more than 3,000 nodes and the value of the entire network locked assets exceeds $2 million. The Lightning Torch has also exceeded $100, and high-tech giants Jack Dorsey and Reid Hoffman and financial giant Fidelity are also involved.

Lightning was proposed to extend the Bitcoin network. As one of the earliest emerging Layer-2 solutions, it was genius to propose to move transactions to the chain without changing the security model of the blockchain. It hopes to not only increase the size of the transaction, but also guarantee low latency and minimum transaction fees. The Lightning Network also has several drawbacks: Active demand : The payer must be online to complete the payment – this is not surprising. However, unlike Bitcoin, in lightning networks, the payee must also be online in order to sign the underlying transaction using the private keys of both parties (the operational considerations will be elaborated later). To make matters worse, starting from the establishment of the chain channel between the two parties, the payee must always monitor the blockchain status to ensure that the payer does not submit the old status of their balance and close the channel. The routing node must also be online before the upstream and downstream channels time out to participate in the protocol and perform duties (ie, route payment requests) before the upstream HTLC (hash time lock) times out.

The Lightning Network attempted to introduce a watchtower node to address the need for users to continuously monitor the blockchain. The watchtower node provides a blockchain network condition monitoring service by charging a fee to the user.

Low capital utilization : In general, the payer is willing to lock in some assets (for example, using a debit card) for convenience. But in the lightning network, each user needs to lock a fund in each channel, thus breaking up a user's funds.

To make matters worse, if the underlying transaction is not sent directly from the payer to the payee (for example, the transfer amount is X), but is forwarded through other routing nodes, the routing nodes involved also need to lock at least X. funds.

Ideally (from the perspective of capital utilization), the upper limit of the star network mobility of a single central node is the amount of funds that the central node is willing to lock. The paying party's locked funds do not contribute to network mobility. In other words, routing nodes are needed to bring mobility to the network, which is a somewhat surprising and undesirable feature.

If we want to avoid such a centralized network, what kind of problems will we encounter? Reducing the level of network centralization requires an increase in the diversity of routing path selection. However, in a transfer, the more nodes participating in the route, the higher the transaction cost will be (this is because the funds used for routing need to be locked for a period of time, and no interest can be generated during the lockout period). Specifically, if Alice wants to send 1 bitcoin to Bob via 5 routing nodes, then a total of 5 bitcoins need to be locked in the lightning network. This cost (and the cost of malicious attacks when the routing nodes do not match) must be translated into the costs incurred by the counterparty. Now the lightning network does not charge this part of the payment to the payer, but based on the altruistic behavior of early users of the network to maintain the normal operation of the network.

The centralization trend of the lightning network ecosystem can alleviate the problem of low capital utilization. The degree of lightning network centralization is clearly an interesting topic.

Operational Security Challenges : The most controversial point of centralized trading is that they create a honeypot that can be attacked by an attacker. However, as the network expands, Lightning Network Routing nodes create more temporary honeypots. Imagine a situation in which a private key in the hot wallet needs to be exposed: the centralized exchange only needs to briefly expose the private key for the time period they choose. But in lightning networks, routing nodes must always expose private keys in order to provide near real-time services. At the same time, in order to provide stable routing services, they need to ensure that each channel has sufficient funds. This constitutes an ideal honeypot: sufficient funds and private keys exposed in the hot wallet. In order to make up for the capital required to protect this honeypot, the routing node is likely to increase this investment into the transaction fee.

The transaction completion rate decreases as the payment amount increases : Considering that each channel in multi-hop payment needs to lock more than the payment amount, these payments have fewer routes to choose from in the network, so a higher amount of transaction payment may be completed. Less sexual. Since channel routing limits the size of the capacity, an increase in the amount of payment may result in a higher transaction cost. Ideally, the user would of course want the transaction completion rate to be independent of the transaction amount.

Transaction completion rates decrease with increased directionality : similar to the negative impact of increased payment amounts, when many payers pay a fee to a payee at the same time (for example, consumers in the real world pay merchants), they will compete for limited The routing node's funding capacity (pointing to the payee). Please note that the Lightning Torch Relay did not prove that the Lightning Network could cope with this scenario.

In general, the total resource consumption of Lightning Network seems to be related not only to the number of participants or the amount paid, but also to the number of payments. This is obviously a serious injury to the payment expansion plan.

[Insert: For the sake of simplicity, we assume that the routing problem in the lightning network has been perfectly solved and the service is provided free of charge. Of course, some people think this is a problem]

StarkPay

StarkPay's goal is to provide a scalable, cost-effective, unmanaged payment solution with no active demand.

Component

The StarkPay consists of two parts, the lower chain assembly and the upper chain assembly.

Under the chain

• Payment Processor: Interact with the payer and payee.
• Payer Balance Tree: Updated by Prover (Witness Node) and guaranteed availability (more on this later).
• Provener: Generates STARK evidence to prove the validity of several batches of payments from the payment processor and the validity of the payer balance update.

Chain

• Payment Contract: StarkPay's Fund In/Out (Lock/Unlock) station, along with a commitment to update the payer balance (the payer balance update is stored under the chain, and the promised contract is verified to be stored on the chain after verification).
• Verifier contract: Verifies the STARK evidence generated by the witness node (Prover) and feeds the verification result back to the payment contract.

Let's bring the above model into some basic scenarios:

Deposit ("inbound")

The payer deposits the cryptographic currency into the payment contract. The deposit funds are transferred to the chain balance tree through STARK evidence. This operation is similar to the Lightning Network Channel setup process, but one important difference is that the Inbound operation in StarkPay can specify multiple asset recipient addresses.

Withdrawal ("outbound")

Also by using STARK to prove the evidence, the funds in the chain balance tree are transferred to the payment contract, and then the payment is convenient to withdraw the balance from the payment contract. This operation is similar to the channel shutdown process of a lightning network.

Alice transfers to Bob via StarkPay

• Alice signs a transaction with Bob and sends the transaction to the payment processor (Alice does not give up her money supervision).
• The payment processor sends a batch of payment transactions (including Alice's payment) to the witness node.
• The witness node generates the STARK evidence for this payment to prove the validity of the payment and the account balance update, as follows:
  • Verify the digital signature of the payment;
  • Verify that the payer has sufficient funds;
  • Update the balance commitment (for example: Merkle root).
• The witness node sends STARK proof evidence and a balance commitment to the verification contract on the chain. If the verification passes, the verifier sends a new balance commitment to the payment contract and stores it on the chain (as described above).

For witnesses who do not need to introduce trust assumptions, malicious or careless witnesses cannot make the verification contract believe that invalid proof is valid.

Advantage

We believe that the StarkPay architecture provides the expected benefits:

Scalability : The computing resources consumed by StarkPay increase as the number of payers and payments increases. More importantly, changes in computing resources are no longer tied to the total amount of circulation. We have achieved an ideal result: StarkPay is capable of supporting more than 10,000 transactions within a single block (within the current Etherum gasLimit limit).

It is worth noting that STARK moderately consumes extremely scarce computing resources on the chain: the resources it consumes grow logarithmically as the scale of calculations under the chain increases. Specifically: To increase StarPay throughput by a factor of 10, the computing resource consumption on the chain needs to be reduced by less than 50%.

Interrupt: If the standard for expansion is set to Amount/sec instead of Transaction/sec, then StarkPay has no upper limit.

High capital utilization : Just like the metaphor of the debit card, in StarkPay, there is no need to lock in additional funds other than the funds that each payer wants to use under the chain. Of particular importance is the lack of liquidity requirements for payment processors and witnesses.

Inactive demand : The payee balance is updated without being kept online. In all scenarios (deposits, withdrawals, and payments), transactions can be constructed offline and later sent to the blockchain or payment processor.

Unmanaged : The payer does not need to host the cryptocurrency to StarkPay. All operations require the signature of the payer, and even if the witness is evil or uncooperative, they can withdraw the locked funds directly from the payment contract at any time (subsequent blogs will elaborate on the safe exit).

In this regard, StarkPay has the same effect as Lightning Network, and users still retain control over funds.

Disadvantage

StarkPay has some obvious drawbacks:

Data availability : In order to take full advantage of STARK's chain logarithmic scalability, data is best stored under the chain, but this will cause transaction data to be unavailable. In order to trust and break the scalability ceiling, data availability is a challenge that every Plasm-based expansion solution must address.

Improvement plan :

• Batch-record transactions on the chain: We believe that in this mode StarkPay can easily handle hundreds of transactions per second.
• A possible direction for future data in the chain: building a data availability witness alliance, the union's signature of the certificate submitted to the chain certifier contract indicates that the data is available under the chain. The chain verifier contract will not accept evidence that this certificate is missing. It is worth noting that the alliance is not entrusted with ensuring the validity of the system state – they cannot steal funds or invalidate the state of the system.
  In order to support a more decentralized solution, this alliance will gradually be phased out.

Centralization: The Provers node will initially be operated by StarkWare. This brings the risk of centralization and review.

improve proposals:

• Centralization: Other market participants (including other payment processors) will naturally provide their own witness nodes (Provers). In the long run, witness nodes can compete for evidence generation services in the network through consensus algorithms. Note that because the state is only changed by valid proof, the witness node cannot attack the network by switching to an invalid state. In this sense, the StarkPay approach is much like the Layer-1 consensus solution.
• REVIEW: On StarkPay, STARK can also be used to protect privacy. Specifically, the payer can hide their transaction content, even if it is a witness node. The calculation statement generated by the witness node is generated after it has verified a batch of independent transactions received from the payer, so others cannot trace a single transaction from it.

Latency : Unlike the instant settlement guaranteed by the point-to-point lightning channel, the time required to generate proof for high volume transactions is currently a few minutes.

Improvement plan :

• The witness node can submit a commitment to the payment contract on the chain immediately after verifying the received batch of transactions, and at the same time generate proof evidence. The payee has a few minutes to bear the risk that the witness node will detain evidence indefinitely. This risk can be compensated by holding a witness node fund. It is worth noting that the delay of StarkPay is the consensus delay of the main chain for the evidence submission transaction, rather than the near-instant chain transaction processing delay in the lightning network.
  At the same time, latency should not be equal to throughput: StarkPay can achieve higher throughput levels by increasing the computing resources of witnesses (all resources under the chain).

There is no solution for Bitcoin : In its current form, Bitcoin does not yet support efficient chain STARK verification.

Mitigation : If you have a solution, be sure to let us know. Prior to this, we will focus on adapting the blockchain that supports STARK verification on efficient chains.

In this paper, we introduce a STARK algorithm-based scalable engine (StarkPay) for cryptocurrency payment scenarios. We first analyzed the current hottest Bitcoin expansion solution, Lightning Network, and compared it to StarkPay. Our conclusion is that StarkPay offers a compelling alternative to the lightning network in several notable dimensions.

Thanks to Vitalik Buterin, Patrick McCorry, Jim Posen and Dan Robinson for their comments on this draft.

 

(Finish)

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