a draft of the talk
This commit is contained in:
waalge
parent
4911f6b3e3
commit
5e31ac9bf8
|
|
@ -30,7 +30,8 @@
|
|||
-H src/header.html \
|
||||
-o public/index.html \
|
||||
-s \
|
||||
--slide-level 2 \
|
||||
--slide-level 3 \
|
||||
--toc \
|
||||
src/index.md
|
||||
'';
|
||||
serve = pkgs.writeShellScriptBin "serve"
|
||||
|
|
|
|||
Binary file not shown.
|
Before Width: | Height: | Size: 14 KiB After Width: | Height: | Size: 61 KiB |
|
|
@ -71,82 +71,155 @@
|
|||
|
||||
<section id="title-slide" data-background-image="./assets/logo.png" data-background-opacity="0.3" data-background-size="contain">
|
||||
<h1 class="title">Konduit.channel</h1>
|
||||
<p class="subtitle">(Actually why all* dapps should be L2s)</p>
|
||||
<p class="subtitle">[A bunch of ideas in 15mins]</p>
|
||||
</section>
|
||||
<section id="TOC">
|
||||
<nav role="doc-toc">
|
||||
<h2 id="toc-title">toc</h2>
|
||||
<ul>
|
||||
<li><a href="#/what-is" id="/toc-what-is">What is …</a>
|
||||
<ul>
|
||||
<li><a href="#/konduit" id="/toc-konduit">Konduit?</a></li>
|
||||
<li><a href="#/bitcoin-lightning" id="/toc-bitcoin-lightning">Bitcoin
|
||||
Lightning?</a></li>
|
||||
<li><a href="#/the-problem" id="/toc-the-problem">The problem?</a></li>
|
||||
<li><a href="#/the-ask" id="/toc-the-ask">The ask</a></li>
|
||||
</ul></li>
|
||||
<li><a href="#/lightning-bln" id="/toc-lightning-bln">Lightning /
|
||||
BLN</a>
|
||||
<ul>
|
||||
<li><a href="#/overview" id="/toc-overview">Overview</a></li>
|
||||
<li><a href="#/hops" id="/toc-hops">Hops</a></li>
|
||||
<li><a href="#/htlcs" id="/toc-htlcs">HTLCs</a></li>
|
||||
<li><a href="#/routes" id="/toc-routes">Routes</a></li>
|
||||
</ul></li>
|
||||
<li><a href="#/cardano-lightning" id="/toc-cardano-lightning">Cardano
|
||||
Lightning</a>
|
||||
<ul>
|
||||
<li><a href="#/pitch" id="/toc-pitch">Pitch</a></li>
|
||||
</ul></li>
|
||||
<li><a href="#/subbit.xyz" id="/toc-subbit.xyz">Subbit.xyz</a>
|
||||
<ul>
|
||||
<li><a href="#/trustless-subscriptions"
|
||||
id="/toc-trustless-subscriptions">Trustless<sup>*</sup>
|
||||
subscriptions</a></li>
|
||||
<li><a href="#/iou" id="/toc-iou">IOU</a></li>
|
||||
<li><a href="#/unidirectionality-boons"
|
||||
id="/toc-unidirectionality-boons">Unidirectionality boons</a></li>
|
||||
<li><a href="#/overhead" id="/toc-overhead">Overhead?</a></li>
|
||||
</ul></li>
|
||||
<li><a href="#/konduit-1" id="/toc-konduit-1">Konduit</a>
|
||||
<ul>
|
||||
<li><a href="#/subbit-htlcs" id="/toc-subbit-htlcs">Subbit +
|
||||
HTLCs</a></li>
|
||||
<li><a href="#/keep-the-boons" id="/toc-keep-the-boons">Keep the
|
||||
boons</a></li>
|
||||
<li><a href="#/other-deets" id="/toc-other-deets">Other deets</a></li>
|
||||
</ul></li>
|
||||
<li><a href="#/demo" id="/toc-demo">Demo ?!</a>
|
||||
<ul>
|
||||
<li><a href="#/soon" id="/toc-soon">Soon™</a></li>
|
||||
</ul></li>
|
||||
<li><a href="#/ideas" id="/toc-ideas">Ideas</a>
|
||||
<ul>
|
||||
<li><a href="#/ideas-inner" id="/toc-ideas-inner">ideas inner</a></li>
|
||||
</ul></li>
|
||||
</ul>
|
||||
</nav>
|
||||
</section>
|
||||
|
||||
<section id="outline" class="slide level2">
|
||||
<h2>Outline</h2>
|
||||
<ul>
|
||||
<li>What is …</li>
|
||||
<li>Architecture</li>
|
||||
<li>HTLs</li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="what-is" class="slide level2">
|
||||
<section>
|
||||
<section id="what-is" class="title-slide slide level2">
|
||||
<h2>What is …</h2>
|
||||
<h3 id="konduit">Konduit?</h3>
|
||||
|
||||
</section>
|
||||
<section id="konduit" class="slide level3">
|
||||
<h3>Konduit?</h3>
|
||||
<blockquote>
|
||||
<p>A Cardano to Bitcoin Lighting Pipe</p>
|
||||
</blockquote>
|
||||
<!--
|
||||
The first question is then "what is Bitcoin Lightning"
|
||||
-->
|
||||
<h3 id="bitcoin-lightning">Bitcoin Lightning?</h3>
|
||||
<p>… a payment protocol built on the bitcoin intended to enable fast
|
||||
</section>
|
||||
<section id="bitcoin-lightning" class="slide level3">
|
||||
<h3>Bitcoin Lightning?</h3>
|
||||
<p>… a payment protocol built on bitcoin intended to enable fast
|
||||
transactions among participating nodes and has been proposed as a
|
||||
solution to the bitcoin scalability problem.</p>
|
||||
<!--
|
||||
<!--
|
||||
A slight abbreviation of the wiki entry
|
||||
|
||||
A slightly trucated opening lines from the wikipedia page.
|
||||
Whoever provided or endorsed this version clearly thinks this point is moot.
|
||||
-->
|
||||
<h3 id="the-problem">The problem?</h3>
|
||||
</section>
|
||||
<section id="the-problem" class="slide level3">
|
||||
<h3>The problem?</h3>
|
||||
<div
|
||||
style="display:flex;flex-direction:row;justify-content: space-around; align-items: center;">
|
||||
<p><img data-src="./assets/does-it-scale.jpg" /></p>
|
||||
<ul>
|
||||
<li>Scalability</li>
|
||||
<li>Finality</li>
|
||||
<li>Tx fees</li>
|
||||
</ul>
|
||||
</div>
|
||||
<!--
|
||||
You cannot walk into a cafe, say, and purchase a coffee on the L1.
|
||||
Ok its probably fine (we have no traffic, long rollbacks don't happen. wink emoji).
|
||||
But it shouldn't make sense: We cannot have all the nodes handling everyone's morning coffee purchase.
|
||||
It does not scale.
|
||||
|
||||
In truth, we are not really competing with web2 on finality.
|
||||
On finality, we arn't really competing with web2.
|
||||
Payment providers can retroactively deny payments (no source).
|
||||
|
||||
We, Cardano, have the same problem.
|
||||
One route to remedy: don't reinvent the wheel, piggy back on their wheel.
|
||||
-->
|
||||
</section>
|
||||
<section id="lightning" class="slide level2">
|
||||
<h2>Lightning</h2>
|
||||
<section id="the-ask" class="slide level3">
|
||||
<h3>The ask</h3>
|
||||
<p>Can we go from Cardano to BLN?</p>
|
||||
<!--
|
||||
Lightning exists. It has some level of adoption.
|
||||
Some cafes accept lighting payments.
|
||||
Could we open this up to ada holders?!
|
||||
Not for the merchants necessarily, but for the consumers.
|
||||
-->
|
||||
</section></section>
|
||||
<section>
|
||||
<section id="lightning-bln" class="title-slide slide level2">
|
||||
<h2>Lightning / BLN</h2>
|
||||
<!--
|
||||
A lightning round on Lightning network
|
||||
-->
|
||||
<h3 id="overview">Overview</h3>
|
||||
</section>
|
||||
<section id="overview" class="slide level3">
|
||||
<h3>Overview</h3>
|
||||
<ul>
|
||||
<li>A network of two party channels</li>
|
||||
<li>L1: Each channel is “underwritten” by locked funds</li>
|
||||
<li>L2: exchange messages altering how and who can claim these
|
||||
<li>L2: exchanging messages alters how and who can claim these
|
||||
funds</li>
|
||||
</ul>
|
||||
<!--
|
||||
Lightning is a network of two party channels.
|
||||
Each channel corresponds to a utxo holding the funds that underwrite L2 messages.
|
||||
Each channel corresponds to a utxo holding the funds on the L1 that underwrite L2 messages.
|
||||
For example you could have a channel with the coffee shop,
|
||||
and for each morning, you hand them (ie the L2) an IOU that allows
|
||||
and for each morning coffee is paid for via an L2 message.
|
||||
|
||||
Immediate questions:
|
||||
|
||||
- Do i need a channel with everyone I want to pay? If so whats the point?
|
||||
- How is this a network?
|
||||
|
||||
Ok. How is this a network?
|
||||
Do i need a channel with everyone I want to pay? Whats the point.
|
||||
An asside: This is a super interesting setup.
|
||||
|
||||
Subscriptions are "handwave" a trillion dollar and growing.
|
||||
In some sectors we barely buy to own anymore. There's a
|
||||
|
||||
Shoe horning in another idea:
|
||||
The topology of our networks should reflect their use case.
|
||||
The L1 makes it as easy for anyone to pay anyone:
|
||||
a very flexible basis, but this is basically nobodies use case.
|
||||
I'm far more likely to pay somone i've already paid, than someone at random.
|
||||
Subscription based services are "handwave" north of a trillion dollars and growing.
|
||||
-->
|
||||
<h3 id="hops">Hops</h3>
|
||||
</section>
|
||||
<section id="hops" class="slide level3">
|
||||
<h3>Hops</h3>
|
||||
<ul>
|
||||
<li>2 channels: Alice <-> Bob; Bob <-> Charlie</li>
|
||||
<li>Alice ~> Charlie ?</li>
|
||||
|
|
@ -155,56 +228,229 @@ funds</li>
|
|||
</ul>
|
||||
<!--
|
||||
How to make a set of channels a network.
|
||||
|
||||
Shoe horning in another idea:
|
||||
|
||||
The topology of our networks should reflect their use case.
|
||||
The L1 makes it as easy for anyone to pay anyone:
|
||||
a very flexible basis, but this is basically nobodies use case.
|
||||
I'm far more likely to pay somone i've already paid, than someone at random.
|
||||
-->
|
||||
<h3 id="htlcs">HTLCs</h3>
|
||||
</section>
|
||||
<section id="htlcs" class="slide level3">
|
||||
<h3>HTLCs</h3>
|
||||
<ul>
|
||||
<li>Hashed TimeLocked Contract (also, utxo and general mechanism).</li>
|
||||
<li>A contract parameterized by (<code>timeout</code>,
|
||||
<code>lock</code>, <code>payer</code>, <code>payee</code> ) with two
|
||||
spend:</li>
|
||||
<li>Trustless hops</li>
|
||||
<li>Hashed TimeLocked Contract</li>
|
||||
<li>Parameterized by <code>(timeout, lock, payer, payee)</code></li>
|
||||
<li>Two spend pathways:
|
||||
<ul>
|
||||
<li>Ok:
|
||||
<ul>
|
||||
<li>Before <code>timeout</code>,</li>
|
||||
<li>Has <code>secret</code> (<code>hash(secret) == lock</code>)</li>
|
||||
<li>Signed by <code>payee</code></li>
|
||||
</ul></li>
|
||||
<li>Ko:
|
||||
<ul>
|
||||
<li>After <code>timeout</code>,</li>
|
||||
<li>Has <code>payee</code></li>
|
||||
</ul></li>
|
||||
<li>Ok: Signed by <code>payee</code>; Before <code>timeout</code>; Has
|
||||
<code>secret</code></li>
|
||||
<li>Ko: Signed by <code>payer</code>; After <code>timeout</code></li>
|
||||
</ul></li>
|
||||
<li>Note: <code>hash(secret) == lock</code></li>
|
||||
</ul>
|
||||
<!--
|
||||
Enter HTLCs
|
||||
|
||||
This is a basic implementation of an HTLC.
|
||||
|
||||
In practice we want to reuse the same locked funds multiple times,
|
||||
and for values, timeouts, and locks that are not apriori known.
|
||||
But ultimately, its some version of this.
|
||||
|
||||
This bit is the essence of an atomic swap.
|
||||
A warning: the term HTLC is used to mean the "contract", the output at the contract, the would be output in tx not submitted,
|
||||
and the general concept illustrated
|
||||
-->
|
||||
<h3 id="routes">Routes</h3>
|
||||
</section>
|
||||
<section id="routes" class="slide level3">
|
||||
<h3>Routes</h3>
|
||||
<ul>
|
||||
<li>C ~> A : Invoice including lock.</li>
|
||||
<li>A ~> B : HTLC with timeout <code>T</code> and lock</li>
|
||||
<li>B ~> C : HTLC with timeout <code>T - d</code> and lock</li>
|
||||
<li>B ~> C : HTLC with timeout <code>T - delta</code> and lock</li>
|
||||
<li>C ~> B : Secret</li>
|
||||
<li>B ~> C : Commitment to pay (no htlc)</li>
|
||||
<li>B ~> A : Secret</li>
|
||||
<li>A ~> B : Commitment to pay (no htlc)</li>
|
||||
</ul>
|
||||
<!--
|
||||
This is the message flow
|
||||
This is a basic implementation of an HTLC.
|
||||
In practice we want to reuse the same locked funds multiple times,
|
||||
and for values, timeouts, and locks that are not apriori known.
|
||||
But ultimately, its some version of this.
|
||||
This is the message flow, at least for the happy path.
|
||||
We need to unpack the unhappy branch on each line.
|
||||
"What if the message never arrives" (sent or otherwise).
|
||||
|
||||
This bit is the essence of an atomic swap.
|
||||
Now we know how lightning works.
|
||||
We have avoided saying what these commitments look like.
|
||||
Implementation detail.
|
||||
We haven't said anything about finding viable routes.
|
||||
(Essentially magic.)
|
||||
|
||||
But we've said very little about bitcoin.
|
||||
Great so we should just implement lightning on Cardano!
|
||||
-->
|
||||
</section></section>
|
||||
<section>
|
||||
<section id="cardano-lightning" class="title-slide slide level2">
|
||||
<h2>Cardano Lightning</h2>
|
||||
|
||||
</section>
|
||||
<section id="pitch" class="slide level3">
|
||||
<h3>Pitch</h3>
|
||||
<ul>
|
||||
<li>Do Lightning but on Cardano</li>
|
||||
</ul>
|
||||
<div class="fragment">
|
||||
<ul>
|
||||
<li>And better</li>
|
||||
</ul>
|
||||
<!--
|
||||
Why? Its a fun project.
|
||||
|
||||
Lightning is too complicated.
|
||||
Its hard to reason about, its hard to implement, its hard to adapt.
|
||||
|
||||
Lightning has two key problems:
|
||||
|
||||
- All nodes are full nodes (anyone can route, and has to run a full node)
|
||||
- Fund drift
|
||||
|
||||
Both are manifestations that lightning topology does not reflect the problematic.
|
||||
We have good reason to think we can do much better on these fronts using Cardano.
|
||||
|
||||
Recall that the original ask is to get from Cardano to BLN (not back again)
|
||||
Every feature comes at some cost.
|
||||
Full lightning is not cheap (it also doesn't yet exist).
|
||||
The CL project is happening and is the reason I'm here, but this was not the ask.
|
||||
|
||||
One more digression: Why was invited to build CL?
|
||||
-->
|
||||
</div>
|
||||
</section></section>
|
||||
<section>
|
||||
<section id="subbit.xyz" class="title-slide slide level2">
|
||||
<h2>Subbit.xyz</h2>
|
||||
|
||||
</section>
|
||||
<section id="trustless-subscriptions" class="slide level3">
|
||||
<h3>Trustless<sup>*</sup> subscriptions</h3>
|
||||
<ul>
|
||||
<li>Alice wants to subscribe to Bob’s service</li>
|
||||
<li>Alice locks funds on the L1; Bob sees</li>
|
||||
<li>Each request Alice includes an “IOU”; Bob verifies and responds</li>
|
||||
<li>At Bob’s leisure, he claims (<code>subs</code>) funds owed</li>
|
||||
</ul>
|
||||
<p>An embarrassingly simple L2</p>
|
||||
<!--
|
||||
At any point either party can stop participating.
|
||||
Moreover, they are able to claim the funds demonstrably theirs
|
||||
(perhaps after a waiting period).
|
||||
|
||||
The astricks is to indicate that Bob may cheat Alice in his response.
|
||||
Alice ought to stop using the service as soon as this is the case.
|
||||
-->
|
||||
</section>
|
||||
<section id="iou" class="slide level3">
|
||||
<h3>IOU</h3>
|
||||
<pre class="cddl"><code>amount = int
|
||||
signature = bytestring .size 64
|
||||
iou = #6.121( [ amount, signature ] )</code></pre>
|
||||
<pre class="cddl"><code>tag = bytestring
|
||||
message = #6.121( [ tag, amount ] ) </code></pre>
|
||||
<!--
|
||||
Each channel has a `tag`. This allows Alice to use her key for multiple channels.
|
||||
|
||||
This is it.
|
||||
Bob presents this to the L1 and takes funds owed.
|
||||
Note this doesn't close the channel, and the action is ~idempotent.
|
||||
That is, if Bob reused the same IOU he'd not be able to extract any more funds.
|
||||
-->
|
||||
</section>
|
||||
<section id="unidirectionality-boons" class="slide level3">
|
||||
<h3>Unidirectionality boons</h3>
|
||||
<ul>
|
||||
<li>Alice’s safety is not dependent on chain liveness</li>
|
||||
<li>Bob’s sub is unilateral. No contestation.</li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="overhead" class="slide level3">
|
||||
<h3>Overhead?</h3>
|
||||
<ul>
|
||||
<li>Alice (client) must remember their keys</li>
|
||||
<li>Must be able to produce a signature</li>
|
||||
<li>Maybe some other state (< 100 bytes) or 2 trips.</li>
|
||||
</ul>
|
||||
</section></section>
|
||||
<section>
|
||||
<section id="konduit-1" class="title-slide slide level2">
|
||||
<h2>Konduit</h2>
|
||||
<!--
|
||||
Ok. Back on topic: how are we going to meet the ask
|
||||
-->
|
||||
</section>
|
||||
<section id="subbit-htlcs" class="slide level3">
|
||||
<h3>Subbit + HTLCs</h3>
|
||||
<p>Not IOUs, but cheques + squashes</p>
|
||||
<pre class="cddl"><code>cheque_body = [index, amount, timeout, lock]
|
||||
cheque = [cheque_body, signature]
|
||||
|
||||
excludes = [* index]
|
||||
squash_body = [amount, index, excludes]
|
||||
squash = [squash_body, signature]</code></pre>
|
||||
<!--
|
||||
The role is essentially the same.
|
||||
The signature is of a message that is a mild reworking of the version in subbit.
|
||||
|
||||
On a happy path, a cheque is made, a secret learned and shared, and the cheque is squashed.
|
||||
-->
|
||||
</section>
|
||||
<section id="keep-the-boons" class="slide level3">
|
||||
<h3>Keep the boons</h3>
|
||||
<ul>
|
||||
<li>Alice still doesn’t need chain liveness</li>
|
||||
<li>Bob unilateral subs now have the evidence:</li>
|
||||
</ul>
|
||||
<pre class="cddl"><code>unlocked = [cheque_body, signature, secret]
|
||||
receipt = [squash, [*unlocked]] </code></pre>
|
||||
<!--
|
||||
On the happy path the list of unlockeds will be empty.
|
||||
But maybe Alice goes offline before bob learns the secret.
|
||||
-->
|
||||
</section>
|
||||
<section id="other-deets" class="slide level3">
|
||||
<h3>Other deets</h3>
|
||||
<ul>
|
||||
<li>Token free design</li>
|
||||
<li>“Batch” txs are first class</li>
|
||||
<li>“Mutual” txs are first class and invoke no futher verification steps
|
||||
(beyond <code>required_signers</code>)</li>
|
||||
</ul>
|
||||
<!--
|
||||
-->
|
||||
</section></section>
|
||||
<section>
|
||||
<section id="demo" class="title-slide slide level2">
|
||||
<h2>Demo ?!</h2>
|
||||
|
||||
</section>
|
||||
<section id="soon" class="slide level3">
|
||||
<h3>Soon™</h3>
|
||||
</section></section>
|
||||
<section>
|
||||
<section id="ideas" class="title-slide slide level2">
|
||||
<h2>Ideas</h2>
|
||||
|
||||
</section>
|
||||
<section id="ideas-inner" class="slide level3" style="display:none">
|
||||
<h3 style="display:none">ideas inner</h3>
|
||||
<ul>
|
||||
<li>The topology of our networks should reflect their usage</li>
|
||||
<li>Cardano’s super power: verify signatures of arbitrary data</li>
|
||||
<li>All dapps should be L2s</li>
|
||||
<li>A dapp devs main role is to keep user’s from others</li>
|
||||
<li>You don’t need tokens</li>
|
||||
</ul>
|
||||
</section></section>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
|
|
|
|||
263
src/index.md
263
src/index.md
|
|
@ -1,21 +1,17 @@
|
|||
---
|
||||
title: Konduit.channel
|
||||
subtitle: (Actually why all\* dapps should be L2s)
|
||||
mainfont: Monobrain
|
||||
subtitle: "[A bunch of ideas in 15mins]"
|
||||
mainfont: monospace
|
||||
title-slide-attributes:
|
||||
data-background-image: ./assets/logo.png
|
||||
data-background-size: contain
|
||||
data-background-opacity: "0.3"
|
||||
background-image: ./assets/background.svg
|
||||
background-opacity: "0.35"
|
||||
toc-title: "toc"
|
||||
toc-depth: 1
|
||||
---
|
||||
|
||||
## Outline
|
||||
|
||||
- What is ...
|
||||
- Architecture
|
||||
- HTLs
|
||||
|
||||
## What is ...
|
||||
|
||||
### Konduit?
|
||||
|
|
@ -28,20 +24,27 @@ background-opacity: "0.35"
|
|||
|
||||
### Bitcoin Lightning?
|
||||
|
||||
... a payment protocol built on the bitcoin intended to enable fast transactions among participating nodes
|
||||
... a payment protocol built on bitcoin intended to enable fast transactions among participating nodes
|
||||
and has been proposed as a solution to the bitcoin scalability problem.
|
||||
|
||||
<!--
|
||||
<!--
|
||||
A slight abbreviation of the wiki entry
|
||||
|
||||
A slightly trucated opening lines from the wikipedia page.
|
||||
Whoever provided or endorsed this version clearly thinks this point is moot.
|
||||
-->
|
||||
|
||||
### The problem?
|
||||
|
||||
::: {style="display:flex;flex-direction:row;justify-content: space-around; align-items: center;"}
|
||||
|
||||
|
||||
|
||||
- Scalability
|
||||
- Finality
|
||||
- Tx fees
|
||||
|
||||
:::
|
||||
|
||||
<!--
|
||||
You cannot walk into a cafe, say, and purchase a coffee on the L1.
|
||||
|
|
@ -49,11 +52,25 @@ and has been proposed as a solution to the bitcoin scalability problem.
|
|||
But it shouldn't make sense: We cannot have all the nodes handling everyone's morning coffee purchase.
|
||||
It does not scale.
|
||||
|
||||
In truth, we are not really competing with web2 on finality.
|
||||
On finality, we arn't really competing with web2.
|
||||
Payment providers can retroactively deny payments (no source).
|
||||
|
||||
We, Cardano, have the same problem.
|
||||
One route to remedy: don't reinvent the wheel, piggy back on their wheel.
|
||||
-->
|
||||
|
||||
## Lightning
|
||||
### The ask
|
||||
|
||||
Can we go from Cardano to BLN?
|
||||
|
||||
<!--
|
||||
Lightning exists. It has some level of adoption.
|
||||
Some cafes accept lighting payments.
|
||||
Could we open this up to ada holders?!
|
||||
Not for the merchants necessarily, but for the consumers.
|
||||
-->
|
||||
|
||||
## Lightning / BLN
|
||||
|
||||
<!--
|
||||
A lightning round on Lightning network
|
||||
|
|
@ -63,26 +80,21 @@ and has been proposed as a solution to the bitcoin scalability problem.
|
|||
|
||||
- A network of two party channels
|
||||
- L1: Each channel is "underwritten" by locked funds
|
||||
- L2: exchange messages altering how and who can claim these funds
|
||||
- L2: exchanging messages alters how and who can claim these funds
|
||||
|
||||
<!--
|
||||
Lightning is a network of two party channels.
|
||||
Each channel corresponds to a utxo holding the funds that underwrite L2 messages.
|
||||
Each channel corresponds to a utxo holding the funds on the L1 that underwrite L2 messages.
|
||||
For example you could have a channel with the coffee shop,
|
||||
and for each morning, you hand them (ie the L2) an IOU that allows
|
||||
and for each morning coffee is paid for via an L2 message.
|
||||
|
||||
Immediate questions:
|
||||
|
||||
- Do i need a channel with everyone I want to pay? If so whats the point?
|
||||
- How is this a network?
|
||||
|
||||
Ok. How is this a network?
|
||||
Do i need a channel with everyone I want to pay? Whats the point.
|
||||
An asside: This is a super interesting setup.
|
||||
|
||||
Subscriptions are "handwave" a trillion dollar and growing.
|
||||
In some sectors we barely buy to own anymore. There's a
|
||||
|
||||
Shoe horning in another idea:
|
||||
The topology of our networks should reflect their use case.
|
||||
The L1 makes it as easy for anyone to pay anyone:
|
||||
a very flexible basis, but this is basically nobodies use case.
|
||||
I'm far more likely to pay somone i've already paid, than someone at random.
|
||||
Subscription based services are "handwave" north of a trillion dollars and growing.
|
||||
-->
|
||||
|
||||
### Hops
|
||||
|
|
@ -94,46 +106,209 @@ and has been proposed as a solution to the bitcoin scalability problem.
|
|||
|
||||
<!--
|
||||
How to make a set of channels a network.
|
||||
|
||||
Shoe horning in another idea:
|
||||
|
||||
The topology of our networks should reflect their use case.
|
||||
The L1 makes it as easy for anyone to pay anyone:
|
||||
a very flexible basis, but this is basically nobodies use case.
|
||||
I'm far more likely to pay somone i've already paid, than someone at random.
|
||||
-->
|
||||
|
||||
### HTLCs
|
||||
|
||||
- Hashed TimeLocked Contract (also, utxo and general mechanism).
|
||||
- A contract parameterized by (`timeout`, `lock`, `payer`, `payee` ) with two spend:
|
||||
- Two spend pathways:
|
||||
- Ok:
|
||||
- Before `timeout`,
|
||||
- Has `secret` (`hash(secret) == lock`)
|
||||
- Signed by `payee`
|
||||
- Ko:
|
||||
- After `timeout`,
|
||||
- Has `payee`
|
||||
- Trustless hops
|
||||
- Hashed TimeLocked Contract
|
||||
- Parameterized by `(timeout, lock, payer, payee)`
|
||||
- Two spend pathways:
|
||||
- Ok: Signed by `payee`; Before `timeout`; Has `secret`
|
||||
- Ko: Signed by `payer`; After `timeout`
|
||||
- Note: `hash(secret) == lock`
|
||||
|
||||
<!--
|
||||
Enter HTLCs
|
||||
|
||||
This is a basic implementation of an HTLC.
|
||||
|
||||
In practice we want to reuse the same locked funds multiple times,
|
||||
and for values, timeouts, and locks that are not apriori known.
|
||||
But ultimately, its some version of this.
|
||||
|
||||
This bit is the essence of an atomic swap.
|
||||
A warning: the term HTLC is used to mean the "contract", the output at the contract, the would be output in tx not submitted,
|
||||
and the general concept illustrated
|
||||
-->
|
||||
|
||||
### Routes
|
||||
|
||||
- C ~> A : Invoice including lock.
|
||||
- A ~> B : HTLC with timeout `T` and lock
|
||||
- B ~> C : HTLC with timeout `T - d` and lock
|
||||
- B ~> C : HTLC with timeout `T - delta` and lock
|
||||
- C ~> B : Secret
|
||||
- B ~> C : Commitment to pay (no htlc)
|
||||
- B ~> A : Secret
|
||||
- A ~> B : Commitment to pay (no htlc)
|
||||
|
||||
<!--
|
||||
This is the message flow
|
||||
This is a basic implementation of an HTLC.
|
||||
In practice we want to reuse the same locked funds multiple times,
|
||||
and for values, timeouts, and locks that are not apriori known.
|
||||
But ultimately, its some version of this.
|
||||
This is the message flow, at least for the happy path.
|
||||
We need to unpack the unhappy branch on each line.
|
||||
"What if the message never arrives" (sent or otherwise).
|
||||
|
||||
This bit is the essence of an atomic swap.
|
||||
Now we know how lightning works.
|
||||
We have avoided saying what these commitments look like.
|
||||
Implementation detail.
|
||||
We haven't said anything about finding viable routes.
|
||||
(Essentially magic.)
|
||||
|
||||
But we've said very little about bitcoin.
|
||||
Great so we should just implement lightning on Cardano!
|
||||
-->
|
||||
|
||||
## Cardano Lightning
|
||||
|
||||
### Pitch
|
||||
|
||||
- Do Lightning but on Cardano
|
||||
|
||||
. . .
|
||||
|
||||
- And better
|
||||
|
||||
<!--
|
||||
Why? Its a fun project.
|
||||
|
||||
Lightning is too complicated.
|
||||
Its hard to reason about, its hard to implement, its hard to adapt.
|
||||
|
||||
Lightning has two key problems:
|
||||
|
||||
- All nodes are full nodes (anyone can route, and has to run a full node)
|
||||
- Fund drift
|
||||
|
||||
Both are manifestations that lightning topology does not reflect the problematic.
|
||||
We have good reason to think we can do much better on these fronts using Cardano.
|
||||
|
||||
Recall that the original ask is to get from Cardano to BLN (not back again)
|
||||
Every feature comes at some cost.
|
||||
Full lightning is not cheap (it also doesn't yet exist).
|
||||
The CL project is happening and is the reason I'm here, but this was not the ask.
|
||||
|
||||
One more digression: Why was invited to build CL?
|
||||
-->
|
||||
|
||||
## Subbit.xyz
|
||||
|
||||
### Trustless<sup>\*</sup> subscriptions
|
||||
|
||||
- Alice wants to subscribe to Bob's service
|
||||
- Alice locks funds on the L1; Bob sees
|
||||
- Each request Alice includes an "IOU"; Bob verifies and responds
|
||||
- At Bob's leisure, he claims (`subs`) funds owed
|
||||
|
||||
An embarrassingly simple L2
|
||||
|
||||
<!--
|
||||
At any point either party can stop participating.
|
||||
Moreover, they are able to claim the funds demonstrably theirs
|
||||
(perhaps after a waiting period).
|
||||
|
||||
The astricks is to indicate that Bob may cheat Alice in his response.
|
||||
Alice ought to stop using the service as soon as this is the case.
|
||||
-->
|
||||
|
||||
### IOU
|
||||
|
||||
```cddl
|
||||
amount = int
|
||||
signature = bytestring .size 64
|
||||
iou = #6.121( [ amount, signature ] )
|
||||
```
|
||||
|
||||
```cddl
|
||||
tag = bytestring
|
||||
message = #6.121( [ tag, amount ] )
|
||||
```
|
||||
|
||||
<!--
|
||||
Each channel has a `tag`. This allows Alice to use her key for multiple channels.
|
||||
|
||||
This is it.
|
||||
Bob presents this to the L1 and takes funds owed.
|
||||
Note this doesn't close the channel, and the action is ~idempotent.
|
||||
That is, if Bob reused the same IOU he'd not be able to extract any more funds.
|
||||
-->
|
||||
|
||||
### Unidirectionality boons
|
||||
|
||||
- Alice's safety is not dependent on chain liveness
|
||||
- Bob's sub is unilateral. No contestation.
|
||||
|
||||
### Overhead?
|
||||
|
||||
- Alice (client) must remember their keys
|
||||
- Must be able to produce a signature
|
||||
- Maybe some other state (< 100 bytes) or 2 trips.
|
||||
|
||||
## Konduit
|
||||
|
||||
<!--
|
||||
Ok. Back on topic: how are we going to meet the ask
|
||||
-->
|
||||
|
||||
### Subbit + HTLCs
|
||||
|
||||
Not IOUs, but cheques + squashes
|
||||
|
||||
```cddl
|
||||
cheque_body = [index, amount, timeout, lock]
|
||||
cheque = [cheque_body, signature]
|
||||
|
||||
excludes = [* index]
|
||||
squash_body = [amount, index, excludes]
|
||||
squash = [squash_body, signature]
|
||||
```
|
||||
|
||||
<!--
|
||||
The role is essentially the same.
|
||||
The signature is of a message that is a mild reworking of the version in subbit.
|
||||
|
||||
On a happy path, a cheque is made, a secret learned and shared, and the cheque is squashed.
|
||||
-->
|
||||
|
||||
### Keep the boons
|
||||
|
||||
- Alice still doesn't need chain liveness
|
||||
- Bob unilateral subs now have the evidence:
|
||||
|
||||
```cddl
|
||||
unlocked = [cheque_body, signature, secret]
|
||||
receipt = [squash, [*unlocked]]
|
||||
```
|
||||
|
||||
<!--
|
||||
On the happy path the list of unlockeds will be empty.
|
||||
But maybe Alice goes offline before bob learns the secret.
|
||||
-->
|
||||
|
||||
### Other deets
|
||||
|
||||
- Token free design
|
||||
- "Batch" txs are first class
|
||||
- "Mutual" txs are first class and invoke no futher verification steps
|
||||
(beyond `required_signers`)
|
||||
|
||||
<!--
|
||||
-->
|
||||
|
||||
## Demo ?!
|
||||
|
||||
### Soon™
|
||||
|
||||
## Ideas
|
||||
|
||||
### ideas inner {style="display:none"}
|
||||
|
||||
- The topology of our networks should reflect their usage
|
||||
- Cardano's super power: verify signatures of arbitrary data
|
||||
- All dapps should be L2s
|
||||
- A dapp devs main role is to keep user's from others
|
||||
- You don't need tokens
|
||||
|
|
|
|||
Loading…
Reference in New Issue