Skip to content

Instantly share code, notes, and snippets.

@niftynei
Last active April 24, 2023 09:38
Show Gist options
  • Star 1 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save niftynei/5f9373568e2cf6d15db6c7546a43f763 to your computer and use it in GitHub Desktop.
Save niftynei/5f9373568e2cf6d15db6c7546a43f763 to your computer and use it in GitHub Desktop.
draft of nifty's talk
WELCOME to Nifty's Presentation on LAYER-2s
Today we're talking about layer-2s
Big thank you to Trey de Bonis the content organizer
for inviting me to present on layer-2s; this is one of my
favorite topics to nerd out about.
let's start with the "obvious" question:
what is a layer-2?
generally speaking, a layer-2 is a accounting system
which lets you transact with a "layer-1" asset independent
of the 'native' layer-1 accounting system
in bitcoin, the native accounting system is the
block ledger. to transact on layer-1 in bitcoin
you make a transaction and get that transaction
into a block. viola, you have transacted on layer-1
ok so layer-2 uses some other system for doing accounting
quick aside here, what is an "accounting system"?
it's a system that tracks who owns how much of an asset.
ok so a layer-2 is an accounting system (ledger)
that isn't the same as the layer-1\*
common examples:
- lightning
- fedimints
- liquid sidechain
- proposals: spacechains, statechains, rollups
- eth: optimism + arbitrum + aztec?
what are the accounting systems these use?
- lightning: cached layer-1 txs
- fedimint: chaumian tokens
- liquid federation: a whole 2nd blockchain
- rollups: ???
- state/space: cached layer-1 txs ??
- eth rollups: a whole 2nd blockchain
every once in a while you get a wise-guy who asks:
"What about CoinBase?"
"Aren't they also a layer-2?"
Well let's look at the facts.
You send your bitcoin on layer-1 to Coinbase. they put it
into their onchain multisig, and in return they issue you
an entry into their database which says how much bitcoin
you own.
this .. passes the test of "a secondary accounting system
that lets you transact in the layer-1 object"
like if i have a bitcoin in coinbase and i want to send it
to a friend also on coinbase, coinbase can just update their
database entries for our accounts and badda bing badda BOOM.
bitcoin has been transacted without needing to touch a blockchain.
but this is... unsatisfactory?
who thinks this is unsatisfactory?
ok so clearly a "real" layer-2 definition needs a
bit more than "a separate accounting system"
here's what i've come up with:
- a layer-2 is a separate accounting system where the
authorization to execute a transaction must be granted
by the holder of the account primitive
in other words, you can't make a valid transaction on a
layer-2 without a valid signature of the party that owns the
layer-2 asset.
in this sense, coinbase's database would NOT be a layer-2, since
anyone who works at coinbase can validly update their database
ok i think we've neatly resolved that. nice.
there's a bit more we could go into about
how layer-2s are related to layer-1s; like where
does the "authority" to transact the layer-1 asset come from?
generally speaking, you have to lock up the asset in the
layer-1; you've got to put it into a separate account,
sort of "earmarking it" like "ok this segment of layer-1 asset
value will be transacted not here but in a different layer-2
system"
in bitcoin this typcially means you put your layer-1 bitcoin
into a multisig contract. and it stays there for the duration
of its "layer-2 lifetime". then you transact with some
'option' on your claim to some portion of the bitcoin
held in this multisig, and these claims are negotiated using
whatever "accounting system" the layer-2 is using
liquid bitcoin, this means you peg-in (eg lock up your layer-1
bitcoin into the federation's multisig) and in exchange you're
issued "liquid-bitcoin" credits on the liquid blockchain.
you can then transact 'in bitcoin' over on the liquid blockchain
(faster and less expensive than on mainchain?) maybe more confidential?
similarly, with an e-cash mint you lock your bitcoins into
the mint federation's multisig, and in exchange they give you
"e-cash tokens". hard to audit, but hard to track. double sword of
privacy etc etc.
then you can trade these e-cash tokens, which are "as good as bitcoin";
e-cash tokens require signatures from the person who was granted them
to be spent. (layer-2 requires auth from holder to validate txs)
so we have a decent understanding of a layer-2 now...
let's talk a little bit about "why layer-2s"
the general idea is that layer-2s allow for "batching" of
transactions in a different accounting medium; this increases
the number of people that can transact with bitcoin primitives,
but distributes the load of the "transaction processing" to a variety
of accounting ledgers.
in other words, it makes it cheaper and more people can change the state
of their bitcoin claims (eg transact) at the same time; far exceeding the
'native capacity' of the layer-1. ok that's pretty cool.
ok so let's do a little bit of comparison of existing layer-2 proposals?
let's make a list! maybe we'll update it later..
- broadcast scope of state changes
"who finds out about ledger changes"
- liveness requirements
"who needs to be available/participate for me to make a tx"
- cost of transactions
"what's this gonna cost me?"
- granulatrity of transactions
"what's the minimum transaction size i
can make on this accting ledger"
- ruggability
"who's got keys to the multisig i put my L1 assets into"
- exitability
"who do i need to ask to get my L1 tokens back"
broadcast scope!
layer-1: everyone needs to know
lightning: everyone along the payment path needs to know
- if this is just one-hop, 2 people
- max of 20 hops, so 21 people MAX
e-cash: you, person you're paying, the bank
liquid: everyone on liquid needs to know\*
- confidential txs hides the amts/destinations
- but the data gets broadcast to everyone, encrypted
rollups: ??
liveness requirements:
layer-1: miners, really
- eventually everyone on the network validates tx
but at that point it's already been "effectuated",
the state has already irrevocably updated
lightning: everyone on the path, max 21
- note that this gets complicated for multiparty channels,
and is honestly the biggest blocker at 'scaling LN'
in a layer-1 efficient manner...
liquid: federation signatories
- same as layer-1 wrt lazy validation of all participants
e-cash mints: the mint needs to be online;
federation signatories or single mint
- iiuc cashu has single mint, can't go down/offline
- fedimints have a federated mint, so some quorum of the mint
btc rollups: ???
eth rollups: central tx processor/blockbuilder
cost of tx:
layer-1: depends on your time horizon, current competing tx congestion,
and 'size' of your transaction
lightning: number of hops used and volume of payment made
liquid: same as layer-1, with the caveat that there's more
blockspace (faster blocks)
e-cash mints: no idea; free-ish?
eth rollups: fraction of the cost, iiuc it's a function
of cost of committing batched txs to main-chain?
btc rollups: ???
granularity:
layer-1: dust-limit, ~150 satoshis
lightning: 1/100ths of a satoshi
liquid: ???, probably similar to layer-1
e-cash mints: issue tokens in denominations, so would depend on the mint
TODO: look up cashu/fedimint's default values
btc rollups: ??
eth rollups: same as the layer-1 network
ruggability:
- layer-1: non-existant (not your keys not your coins)
- lightning: current lightning, maintaining your state history;
eltoo/future LN, maintaining most recent state
- liquid: federation defects
- e-cash: depends on mint configuration;
- fedrated mints: federation defects
- cashu: ???
- btc rollups: ??
- eth rollups: multisig on mainchain bridge contract?
- did they use a multisig?
- is the bridge contract safe from hacking?
exitability:
layer-1: where you going exactly?
lightning: any time you want (layer-1 fees depending)
- unilateral (no permission required)
liquid: must ask federation to peg out your funds
e-cash:
- federations: must ask federation to de-peg funds
- cashu: ask the mint to de-peg funds
btc rollups: ???
eth rollups:
- ask the contract operator to send you back funds on mainchain
- 3rd parties that'll do it for you faster (trust required?)
i am way out of time. here's some things we didn't talk about.
- non-bitcoin assets using bitcoin ledger as their accounting
mechanism. these aren't layer-2s because they're not
new accounting systems for bitcoin; in some ways
they're making *bitcoin's* layer one into a layer-two for
whatever asset (generally held elsewhere... or not!?)
nifty-coin anyone? anyone?
- ordinals.
not an accounting system; but is a *numbering* system
eg. gives greater granularity to existing accounts
held on bitcoin
ok if you liked this, and want more nifty content:
- twitter @niftynei
- teach bitcoin protocol @base58btc
~~ https://base58.info ~~
- taproot class in june (prague/nyc)
- lightning this july (nashville!)
- more stuff online + coming this year!
- sometimes i write things
- chainfail.substack.com
- basicbitch.software
- book on bitcoin txs .. sometime TM
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment