<p>From the point of view of an application developer, it is for now much easier to use layer 1 features.<br />
This is due to being able to externalize your burden on the network.</p>
<h1>1. Hey nodes, will you do my job?</h1>
<h3>Blocks are expensive to produce</h3>
<p>You don't need to have much DOS concerns in your application if you are only reacting to onchain payments. But what happens if you do an expensive operation each time your Lightning node accepts an HTLC ?..</p>
<h3>Backups are simple</h3>
<p>You don't have to think much about backing up the state of your application for your user: your data is public and stored by everyone. Your user only has to back up a very small amount of data.</p>
<p>On Lightning, you are responsible for your own data. That's sometimes surprising to users who have been accustomed to (ab)using the block chain for years :).<br />
In addition, on Lightning in its current form you are in a pretty bad position should you miss a single state backup. But <a href="https://blockstream.com/eltoo.pdf" rel="nofollow noreferrer">this may be fixed in the future</a>.</p>
<h3>The security model is simple(r)</h3>
<p>Even if there are some pitfalls and idiosyncrasies in Bitcoin, it's way harder to reason about assumptions you can reasonably make for your software and what you can convey to your user is a reasonable usage of your software.</p>
<p>For instance, &quot;may i allow my user to re-import their HD wallet master account in another wallet?&quot;</p>
<ul>
<li>Bitcoin onchain: sure, what could go wrong?</li>
<li>Bitcoin offchain: meh. It's <a href="https://github.com/ElementsProject/lightning/pull/4171#issuecomment-722687237" rel="nofollow noreferrer">not that simple</a>.</li>
</ul>
<p>The same goes with &quot;may i dig a hole, put my wallet in there, come back in a year, and still be in full possession of my coins ?&quot;</p>
<ul>
<li>Bitcoin onchain: sure, what could go wrong?</li>
<li>Bitcoin offchain: meh. It's <a href="https://github.com/lightningnetwork/lightning-rfc/blob/master/05-onchain.md#abstract" rel="nofollow noreferrer">not that simple</a>.</li>
</ul>
<h3>Bootstrapping is simpler</h3>
<p>Even if we usually make the analogy to &quot;send coins to&quot;, Bitcoin onchain did not require interactivity. Just send the transaction to every single node on the network, make them verify it for you and call it a (lazy) day.</p>
<p>Now with Lightning for someone to start paying they need to find a way to connect to the payee, actually making the above analogy closer from the truth as they are actually transferring data.<br />
For someone to start receiving payments, they also need to &quot;be able&quot; to be paid (have enough inbound liquidity).</p>
<h3>Payments get increasingly more secure</h3>
<p>Under Lightning's assumptions, a payment will be almost instantly &quot;secure&quot; :tm:<br />
In practice, arguably even more so than a handful of onchain confirmations. However, maybe not more than a hundred. Or not than a thousand, or ten thousands confirmations.</p>
<p>For some applications (such as making very large payments), you may want to use this feature unique to the block chain: don't consider a payment to be made until a reorganization of the block chain that deep would put the entire currency down anyway.</p>
<h1>2. Hey nodes, can you be more qualified at my job?</h1>
<p>Of course, there are also drawbacks to (ab)using the chain.</p>
<h3>Decent payment security is slow to bootstrap</h3>
<p>Getting the first confirmation may be infinitely longer than on a layer 2 system. If you ask &quot;if my payment can go through successfully, when is it going to be finalized?&quot;:</p>
<ul>
<li>Bitcoin Lightning: immediately. <em>(this assumes unstuck payments)</em></li>
<li>Bitcoin onchain: well, lemme explain you the block space market.</li>
</ul>
<h3>UTXO management</h3>
<p>This logic is one you can't outsource to the nodes :). It's pretty difficult optimization problem that highly depend on the usage that is going to be made of your software. It takes a deep understanding of the tradeoffs and knowledge of the existing solutions to the developer to make a sensible decision.</p>
<p>On Lightning, you don't have to manage coins. The value is similar to a flux rather than to actual physical, indivisible coins.</p>
<h3>Fees orthogonal to payments and fee management</h3>
<p>Onchain fees depend on the actual transaction (in the database sense of the term) size, not on the actual payment. They are in addition very unreliable, in theory you really <a href="https://bitcoin.stackexchange.com/questions/99894/how-do-you-reliably-estimate-mining-fees/101205#101205">can't know for sure that your transaction is going to make it into a block in advance</a>. You are really hoping for the best.<br />
The counter measures for adapting to this always-moving block space market incur an additional cost in knowledge and understanding (and complexity of implementation) to the application developer, similarly to coin selection (which is tightly related).</p>
<p>&quot;how much is my finalized payment going to cost me?&quot;:</p>
<ul>
<li>Bitcoin Lightning: a proportional fee of <code>x</code> sats per million of sats transferred and a fixed fee of <code>y</code>.</li>
<li>Bitcoin onchain: well, lemme explain you the block space market.</li>
</ul>
<h3>Higher usage cost</h3>
<p>As the demand for the finite resource of block space increases, so are average fees premium to be included as soon as possible in the chain. This makes some design of application not possible onchain anymore, re-aligning the incentives of (ab)using the network to incur less burden to the software / user of the software.</p>
<h3>Lack of features</h3>
<p>Onchain nodes are pretty restricted in what they can verify for you. Some more complex systems can be emulated on a L2 network with different trust assumptions than the base trustless network (eg with sidechains).<br />
The advantage of not doing it onchain here is that it's opt-in: you don't have to make the entire network and economy accept to augment their functionalities in order to bear even more burden than previously.</p>
<p>Some features may be either backward incompatible or present tradeoffs that not everyone would accept. Their addition to the base layer would raise big questions about the censorship resistance of the system and finally the point of using it in the first place.</p>

CC BY-SA 4.0
2021-04-03T10:56:20.463Z
2021-04-03T11:02:48.963Z
2021-04-03T11:02:48.963Z
Antoine Poinsot
<p>I'm looking for a good example and explanation from a software architecture perspective BUT for general audience about the benefits of solving and having blockchain features on Layer 1 not disregarding any Layer 2 solution or blockchain but in fact comparing.</p>
<p>In example any scaling solution for off-chain transaction will definitely face speed issues in comparison to one that was solved on the original design of the blockchain.</p>
<p>It's not a fair comparison because both have their reasons, their strengths and their fame but if you take lightning or æternity state channels you will have some design flaws that should be talked about to help people to understand and decide based on more than just marketing.</p>
<p>Again this isn't in any way a critic towards any of the solution but an example to talk about design and architecture and not about which had better marketing.</p>

CC BY-SA 4.0
2021-03-24T09:45:19.657Z
I think it's in essence a great question that deserves a decent answer to link to it. I'm thinking of a wanna-be decent answer and i find some terms of your question confusing. First, i think you mean "technological perspective" rather than "software architecture perspective"? Then you state "any scaling solution for off-chain transaction will definitely face speed issues in comparison to one that was solved on the original design of the blockchain". I can't help but say it's plainly objectively wrong. Could you shed some light on this one so i can take a shot at writing an answer ? :)
Antoine Poinsot
CC BY-SA 4.0
2021-03-24T10:36:37.363Z
Thanks for reading my question @darosior . For the first statement I think it's right as I'm speaking about the architecture of the software piece/s rather than technological perspective as a broader concept. For the second statement  that's exactly what I'm trying to get an answer, if you planned such features while you were designing your software and you did it well it should run better and faster that if you put something on top tomorrow to get those features.
Omar Saadoun
CC BY-SA 4.0
2021-03-24T10:39:15.267Z
Oh, then you were talking about pace in software *development* ? I misinterpreted it for "The speed of /Bitcoin usage/". Then i think i can write an appropriate answer, thanks!
Antoine Poinsot
CC BY-SA 4.0
2021-03-31T10:49:20.397Z
I'm putting concrete examples of developed technologies that show exactly my concern and question. This is not a theoric question but a practical one on based on architecture practices and software engineering.
Omar Saadoun
CC BY-SA 4.0
2021-03-31T11:23:23.747Z
Sorry completely forgot about it, will write a response soon with practical examples.
Antoine Poinsot
<blockchain><lightning-network><altcoin><architecture>
What's the advantages of using the block chain as opposed to L2 solutions
Omar Saadoun
# What's the advantages of using the block chain as opposed to L2 solutions

(Asked by: username_0 on 2021-03-17)

I'm looking for a good example and explanation from a software architecture perspective BUT for general audience about the benefits of solving and having blockchain features on Layer 1 not disregarding any Layer 2 solution or blockchain but in fact comparing.

In example any scaling solution for off-chain transaction will definitely face speed issues in comparison to one that was solved on the original design of the blockchain.

It's not a fair comparison because both have their reasons, their strengths and their fame but if you take lightning or æternity state channels you will have some design flaws that should be talked about to help people to understand and decide based on more than just marketing.

Again this isn't in any way a critic towards any of the solution but an example to talk about design and architecture and not about which had better marketing.

**Tags:** blockchain, lightning-network, altcoin, architecture

> **Comments:**
> **username_1**: I think it's in essence a great question that deserves a decent answer to link to it. I'm thinking of a wanna-be decent answer and i find some terms of your question confusing. First, i think you mean "technological perspective" rather than "software architecture perspective"? Then you state "any scaling solution for off-chain transaction will definitely face speed issues in comparison to one that was solved on the original design of the blockchain". I can't help but say it's plainly objectively wrong. Could you shed some light on this one so i can take a shot at writing an answer ? :)  
> **username_0**: Thanks for reading my question @darosior . For the first statement I think it's right as I'm speaking about the architecture of the software piece/s rather than technological perspective as a broader concept. For the second statement  that's exactly what I'm trying to get an answer, if you planned such features while you were designing your software and you did it well it should run better and faster that if you put something on top tomorrow to get those features.  
> **username_1**: Oh, then you were talking about pace in software *development* ? I misinterpreted it for "The speed of /Bitcoin usage/". Then i think i can write an appropriate answer, thanks!  
> **username_0**: I'm putting concrete examples of developed technologies that show exactly my concern and question. This is not a theoric question but a practical one on based on architecture practices and software engineering.  
> **username_1**: Sorry completely forgot about it, will write a response soon with practical examples.  

---

## 1 answers

### Answer by username_1 on 2021-04-03. Score: 3

From the point of view of an application developer, it is for now much easier to use layer 1 features.  
This is due to being able to externalize your burden on the network.

# 1. Hey nodes, will you do my job?

### Blocks are expensive to produce

You don't need to have much DOS concerns in your application if you are only reacting to onchain payments. But what happens if you do an expensive operation each time your Lightning node accepts an HTLC ?..

### Backups are simple

You don't have to think much about backing up the state of your application for your user: your data is public and stored by everyone. Your user only has to back up a very small amount of data.

On Lightning, you are responsible for your own data. That's sometimes surprising to users who have been accustomed to (ab)using the block chain for years :).  
In addition, on Lightning in its current form you are in a pretty bad position should you miss a single state backup. But [this may be fixed in the future](https://blockstream.com/eltoo.pdf).

### The security model is simple(r)

Even if there are some pitfalls and idiosyncrasies in Bitcoin, it's way harder to reason about assumptions you can reasonably make for your software and what you can convey to your user is a reasonable usage of your software.

For instance, "may i allow my user to re-import their HD wallet master account in another wallet?"

* Bitcoin onchain: sure, what could go wrong?
* Bitcoin offchain: meh. It's [not that simple](https://github.com/ElementsProject/lightning/pull/4171#issuecomment-722687237).

The same goes with "may i dig a hole, put my wallet in there, come back in a year, and still be in full possession of my coins ?"

* Bitcoin onchain: sure, what could go wrong?
* Bitcoin offchain: meh. It's [not that simple](https://github.com/lightningnetwork/lightning-rfc/blob/master/05-onchain.md#abstract).

### Bootstrapping is simpler

Even if we usually make the analogy to "send coins to", Bitcoin onchain did not require interactivity. Just send the transaction to every single node on the network, make them verify it for you and call it a (lazy) day.

Now with Lightning for someone to start paying they need to find a way to connect to the payee, actually making the above analogy closer from the truth as they are actually transferring data.  
For someone to start receiving payments, they also need to "be able" to be paid (have enough inbound liquidity).

### Payments get increasingly more secure

Under Lightning's assumptions, a payment will be almost instantly "secure" :tm:  
In practice, arguably even more so than a handful of onchain confirmations. However, maybe not more than a hundred. Or not than a thousand, or ten thousands confirmations.

For some applications (such as making very large payments), you may want to use this feature unique to the block chain: don't consider a payment to be made until a reorganization of the block chain that deep would put the entire currency down anyway.

# 2. Hey nodes, can you be more qualified at my job?

Of course, there are also drawbacks to (ab)using the chain.

### Decent payment security is slow to bootstrap

Getting the first confirmation may be infinitely longer than on a layer 2 system. If you ask "if my payment can go through successfully, when is it going to be finalized?":

* Bitcoin Lightning: immediately. *(this assumes unstuck payments)*
* Bitcoin onchain: well, lemme explain you the block space market.

### UTXO management

This logic is one you can't outsource to the nodes :). It's pretty difficult optimization problem that highly depend on the usage that is going to be made of your software. It takes a deep understanding of the tradeoffs and knowledge of the existing solutions to the developer to make a sensible decision.

On Lightning, you don't have to manage coins. The value is similar to a flux rather than to actual physical, indivisible coins.

### Fees orthogonal to payments and fee management

Onchain fees depend on the actual transaction (in the database sense of the term) size, not on the actual payment. They are in addition very unreliable, in theory you really [can't know for sure that your transaction is going to make it into a block in advance](https://bitcoin.stackexchange.com/questions/99894/how-do-you-reliably-estimate-mining-fees/101205#101205). You are really hoping for the best.  
The counter measures for adapting to this always-moving block space market incur an additional cost in knowledge and understanding (and complexity of implementation) to the application developer, similarly to coin selection (which is tightly related).

"how much is my finalized payment going to cost me?":

* Bitcoin Lightning: a proportional fee of `x` sats per million of sats transferred and a fixed fee of `y`.
* Bitcoin onchain: well, lemme explain you the block space market.

### Higher usage cost

As the demand for the finite resource of block space increases, so are average fees premium to be included as soon as possible in the chain. This makes some design of application not possible onchain anymore, re-aligning the incentives of (ab)using the network to incur less burden to the software / user of the software.

### Lack of features

Onchain nodes are pretty restricted in what they can verify for you. Some more complex systems can be emulated on a L2 network with different trust assumptions than the base trustless network (eg with sidechains).  
The advantage of not doing it onchain here is that it's opt-in: you don't have to make the entire network and economy accept to augment their functionalities in order to bear even more burden than previously.

Some features may be either backward incompatible or present tradeoffs that not everyone would accept. Their addition to the base layer would raise big questions about the censorship resistance of the system and finally the point of using it in the first place.


---

