search

bosagora / agora

POC Node implementation for CoinNet
https://bosagora.io
MIT License
37 stars 22 forks source link

Flash layer research & development #1266

Closed AndrejMitrovic closed 3 years ago

AndrejMitrovic commented 3 years ago

I've opened this issue so we can discuss ideas, link to any interesting research papers, and show any prototypes related to payment channels (Flash).

This is an incomplete list.

High-level overview

We want to build a second-layer solution to make Agora scalable and to enable micro-payments.

Goals

We have at least the following goals:

Requirements

Flash validator incentives

There needs to be an incentive for a validator to be part of the flash layer. Anything staked over 40k will be used to create channels, we need to incentivize the operator to stake more.

Script support

LN-Penalty vs Eltoo

Understand that today Lightning Network is actually a stack of protocols. Eltoo is a competing Update layer implementation that has many benefits over LN-Penalty. See this image: https://blockstream.com/img/blog/2018-04-30/lightning-layers.png

LN-Penalty

Eltoo

Knowledge resources

Eltoo resources

Eltoo prototypes

Only known prototype: https://github.com/remyers/signet2/blob/eltoo/test/functional/simulate_eltoo.py

Slashing

I will submit more thoughts later, this is my initial brain dump.

AndrejMitrovic commented 3 years ago

Christian Decker, the author of Eltoo, has kindly offered to help us with the adoption of Eltoo (most probably through reviews, guidance) if we end up deciding on implementing this update mechanism.

AndrejMitrovic commented 3 years ago

Multi-party channels could enable so-called Channel Factories, which might alleviate (or reduce) the need for multi-hop HTLC's. There's a paper for this which I haven't read yet: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC6124062/pdf/rsos180089.pdf - and an associated youtube video: https://www.youtube.com/watch?v=PUDWGH_MvmQ

ferencdg commented 3 years ago

for anyone starting out with the ligthning network, I found this as an okay source to read: https://lightning.network/lightning-network-paper.pdf

however some concepts are not clearly explained in the doc above, so better start with the following list and go back to the lighning network doc after reading this list:

  1. as Andrei already suggested: https://cypherpunks-core.github.io/bitcoinbook/ch07.html
  2. RSMC: https://en.wikiversity.org/wiki/Revocable_Sequence_Maturity_Contracts
  3. Hash Lock: https://en.bitcoin.it/wiki/Hashlock
  4. HTLC: https://en.bitcoin.it/wiki/Hash_Time_Locked_Contracts
  5. Transaction malleability: https://en.bitcoinwiki.org/wiki/Transaction_Malleability
AndrejMitrovic commented 3 years ago

I'm making good progress on getting a basic script execution engine developed. I'm hoping to have something ready by Wednesday night so we can start writing LN/Eltoo scripts (as well as other rudimentary scripting with the subset of opcodes we will initially support).

Note that we do not intend to replicate the entire list of opcodes as found in Bitcoin (also many of their opcodes are deprecated). Instead, we'll support the basic set of features needed for LN. For everything else (math, advanced scripting) we will use WebASM.

It's crucial that our engine behaves the same on all platforms.

ferencdg commented 3 years ago

I'm making good progress on getting a basic script execution engine developed. I'm hoping to have something ready by Wednesday night so we can start writing LN/Eltoo scripts (as well as other rudimentary scripting with the subset of opcodes we will initially support).

Note that we do not intend to replicate the entire list of opcodes as found in Bitcoin (also many of their opcodes are deprecated). Instead, we'll support the basic set of features needed for LN. For everything else (math, advanced scripting) we will use WebASM.

It's crucial that our engine behaves the same on all platforms.

Thanks for the update Andrei and good progress. I went through most of the docs you posted here, let me know if I can be of any help before the execution engine is finshed, otherwise I will just continue to go through more docs

ferencdg commented 3 years ago

I looked at how the ligthning protocol could be implemented, if we had an Ethereum-like execution engine

Here is an interesting article: https://www.blunderingcode.com/a-lightning-network-in-two-pages-of-solidity/

The final code is 128 lines and relatively straightforward to understand. The code doesn't just achieve the same as eltoo(update layer), but:

  1. it contains some support for multi hope payments, that can be improved upon
  2. can be (somewhat easily) extended to support multi party payment channels
  3. can be (somewhat easily) extended to support new participants joining and leaving a payment channel
  4. makes writing the other layers of the lightning network easier(layers other than the update layer) for example 4.1 routing protocol: it is easy to query all the 'payment channel smart contracts' on the network and use some routing algorithm 4.2 less messages/transaction needs to be exchanged compared to eltoo 4.3 no need for generating extra keys(and backing them up) as opposed to eltoo: eltoo requires generating new keys for every possible settlement transactions, and we have as many possible settlement transactions as commit transactions
  5. very easy to implement any kind of punishment mechanism

The solidity program in the referenced article probably contains a few bugs here and there, but generally seems correct.

The eltoo solutions seems to be built upon bitcoin primites like: CHECKLOCKTIMEVERIFY, SIGHASH_NOINPUT and also requires other improvements like segregated withness. I think if we implemented a proper Etherum like execution engine(which is promised in the whitepaper), then we could greatly simplify the entire lighning network implementation. But this is just my two BOScoins.

AndrejMitrovic commented 3 years ago

The final code is 128 lines and relatively straightforward to understand

Yes it does look nice. But it requires a lot of underlying support code to make those lines actually compile and work though. :)

I think if we implemented a proper Etherum like execution engine(which is promised in the whitepaper), then we could greatly simplify the entire lighning network implementation.

I think this would end up being a multi-year effort. However, if we build support for WebAssembly then a lot of that effort can be lifted since there are existing WebASM engines which already exist, some of which have metering support (e.g. gas limits). Some good resources listed here:

There is a proposal to replace Ethereum's VM with webasm:

That being said, I wanted to start with a simple subset of Bitcoin's scripting language with the associated opcodes needed for LN/Eltoo. Bitcoin uses the UTXO model just like us so it makes it easy to adapt their solutions. Its scripting language and "VM" is not turing complete and is trivial to implement. And we don't need to adapt everything they've built, e.g. we can ignore backwards compatibility support code.

Later we could even consider dropping it entirely in place of WebASM, but I feel it's important that we have something functional and working with our limited time constraints. With WebASM you could use any language to build the smart contracts, of course. But I do not believe we should design a completely new language (turing-complete or otherwise) or write our own custom VM rather than use WebASM.

As for Solidity itself, it seems to be a rather poorly designed language. There's good comments about it here: https://news.ycombinator.com/item?id=14807779

That doesn't mean the EVM itself is bad, but it goes to show how difficult it is to actually design a secure and well-balanced language.

Perhaps a good division of workload would be to have one dev pursue WebASM, while the other tries to implement the simplest proof of concept using a subset of bitcoin opcodes as described in the LT / Eltoo whitepaper? Alternatively if you really want to pursue something like Solidity + EVM, that's also an option - but my personal guess is this will take an incredible amount of time to implement. And it's not something I'm willing to work on.

Anyway let me know your thoughts!

ferencdg commented 3 years ago

Perhaps a good division of workload would be to have one dev pursue WebASM,

sorry if I was ambiguos: when I said something Ethereum-like I meant something that is Turing-complete(or at least a bit more feature rich than bitcoin script). I do agree with you that we should not re-design or re-implement something that already exists.

AndrejMitrovic commented 3 years ago

A quick compilation of research topics I was interested in. Some of these may not be fully thought of ideas, so I may be wrong on some of these.

ferencdg commented 3 years ago

"Are there any proposals to use an alternative to SIGHASH_NOINPUT" If we believe that the participants will mostly play by the rules and don't broadcast outdated commit transactions, then we don't really need SIGHASH_NOINPUT. If someone does broadcast an outdated version of the transaction, then the other party could reply the entire chain of transactions. This is not ideal becaues we then need to remember all the commit transactions and also the blockchain will have intermediate commit transactions. However if this kind of behavior is rare, it would not add too much to the block chain size. We might have to bite the bullet here and just implement SIGHASH_NOINPUT.

"How can we use multi-party channels, where the number of participants is >2" I think it is a straigtforward extension of the protocol as mentioned in some of the presentation

"Is it possible to add funds to a channel without closing and re-opening it?" I think if we had channel factories(which deals with adding/removing participants) then it would solve this problem too. If Alice want to add some new funds to the transaction, then she just add her new funds as Alice2 like she is a new participant. I think channel factories might allow adding increasing funds directly too, so we don't even need Alice2.

"Path finding" We need to make sure that just by looking into the blockchain this 'open payment channel' transactions are distiguisable from normal transactions. By doing so everyone can find the path for multi hop payments. Regarding the validators: I think they should keep all their money above 40k in 'reserve' and not allocate payment channels until they are needed. Let's say Alice wants to pay Bob(by establishing a payment channel) and Alice has a payment channel with validatorA and Bob has a channel with validatorB. Let's say Alice don't want to open a direct payment channel with Bob. Alice will ask ValidatorA to open the channel and ValidatorA would open a payment channel with validatorB(or add extra money to the already existing payment channel if they had before) So Validators don't preallocate payment channels beforehand.

"Watchtowers" I don't think watchtowers need any secrets, I think they only need the latest commit/settlement transaction. We need watchtowers regardless of eltoo having no penalty systems. If we don't have watchtowers, then the parties have to be online all the time monitoring the blockchain for outdated commit transactions. One more question is how do we know that a watchtower has no interest in NOT broadcasting the commit transactions that we asked him to do.

AndrejMitrovic commented 3 years ago

If we believe that the participants will mostly play by the rules and don't broadcast outdated commit transactions, then we don't really need SIGHASH_NOINPUT.

We cannot assume participants will act in our good interest. Always assume the worst case so we can build a reliable protocol.

If someone does broadcast an outdated version of the transaction, then the other party could reply the entire chain of transactions.

If you have to replay the entire sequence of transactions then that defeats the purpose of the lightning layer - it's not scalable anymore. Furthermore you would have to pay fees for every single transaction, and not all of your transactions would be guaranteed to be accepted (feelsfees might change, they might get accepted after many blocks because of the total number of transactions, etc). This is also described in section 4 of the Eltoo whitepaper.

AndrejMitrovic commented 3 years ago

@ferencdg please don't edit my comments. You can just use the reply button for that.

ferencdg commented 3 years ago

@ferencdg please don't edit my comments. You can just use the reply button for that.

sorry my mistake, I wanted to reply to it. I see you already rolled back my edit.

ferencdg commented 3 years ago

apart from the bitcoin book Andrei suggested, for anyone starting out with bitcoin or lighning network, this university course is very useful(and free): https://www.coursera.org/learn/cryptocurrency

they have a chapter on micropayments that can help understand lightning network more easily

AndrejMitrovic commented 3 years ago

sorry my mistake, I wanted to reply to it. I see you already rolled back my edit.

No worries, it happens.

apart from the bitcoin book Andrei suggested, for anyone starting out with bitcoin or lighning network, this university course is very useful(and free): https://www.coursera.org/learn/cryptocurrency

Thanks a lot! It would be good to post any other links you've found here so the rest of the team can learn from it.

AndrejMitrovic commented 3 years ago

I'm closing down this issue as there was no new discoveries worth posting about here.