waalge
/
cl-pitch
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Compare commits

base: waalge:0d72bc00e3bb68b9308d3e5e4090784dab92c7ab
Branches Tags
waalge:main
waalge:w/konduit-presentation
...
compare: waalge:e68c14079be136668c5bfd6e2611460baf6c90fd
Branches Tags
waalge:w/konduit-presentation
waalge:main

3 Commits
0d72bc00e3 ... e68c14079b

Author SHA1 Message Date
waalge e68c14079b konduit presentation 2025-12-05 09:31:19 +00:00
waalge 5e31ac9bf8 a draft of the talk 2025-12-03 21:34:44 +00:00
waalge 4911f6b3e3 build broke 2025-12-03 11:38:27 +00:00
8 changed files with 663 additions and 246 deletions
Show Stats Expand all files Collapse all files

27
flake.lock
View File

@ -5,11 +5,11 @@
"nixpkgs-lib": "nixpkgs-lib"
},
"locked": {
"lastModified": 1733312601,
"narHash": "sha256-4pDvzqnegAfRkPwO3wmwBhVi/Sye1mzps0zHWYnP88c=",
"lastModified": 1763759067,
"narHash": "sha256-LlLt2Jo/gMNYAwOgdRQBrsRoOz7BPRkzvNaI/fzXi2Q=",
"owner": "hercules-ci",
"repo": "flake-parts",
"rev": "205b12d8b7cd4802fbcb8e8ef6a0f1408781a4f9",
"rev": "2cccadc7357c0ba201788ae99c4dfa90728ef5e0",
"type": "github"
},
"original": {
@ -20,11 +20,11 @@
},
"nixpkgs": {
"locked": {
"lastModified": 1734424634,
"narHash": "sha256-cHar1vqHOOyC7f1+tVycPoWTfKIaqkoe1Q6TnKzuti4=",
"lastModified": 1764517877,
"narHash": "sha256-pp3uT4hHijIC8JUK5MEqeAWmParJrgBVzHLNfJDZxg4=",
"owner": "NixOS",
"repo": "nixpkgs",
"rev": "d3c42f187194c26d9f0309a8ecc469d6c878ce33",
"rev": "2d293cbfa5a793b4c50d17c05ef9e385b90edf6c",
"type": "github"
},
"original": {
@ -36,14 +36,17 @@
},
"nixpkgs-lib": {
"locked": {
"lastModified": 1733096140,
"narHash": "sha256-1qRH7uAUsyQI7R1Uwl4T+XvdNv778H0Nb5njNrqvylY=",
"type": "tarball",
"url": "https://github.com/NixOS/nixpkgs/archive/5487e69da40cbd611ab2cadee0b4637225f7cfae.tar.gz"
"lastModified": 1761765539,
"narHash": "sha256-b0yj6kfvO8ApcSE+QmA6mUfu8IYG6/uU28OFn4PaC8M=",
"owner": "nix-community",
"repo": "nixpkgs.lib",
"rev": "719359f4562934ae99f5443f20aa06c2ffff91fc",
"type": "github"
},
"original": {
"type": "tarball",
"url": "https://github.com/NixOS/nixpkgs/archive/5487e69da40cbd611ab2cadee0b4637225f7cfae.tar.gz"
"owner": "nix-community",
"repo": "nixpkgs.lib",
"type": "github"
}
},
"root": {

5
flake.nix
View File

@ -25,10 +25,13 @@
build = pkgs.writeShellScriptBin "build"
''
pandoc -t revealjs \
-V revealjs-url=https://unpkg.com/reveal.js \
--from markdown+yaml_metadata_block+link_attributes \
-H src/header.html \
-o public/index.html \
-s \
--slide-level 3 \
--toc \
src/index.md
'';
serve = pkgs.writeShellScriptBin "serve"
@ -44,7 +47,7 @@
shellHook = ''
echo 1>&2 "Welcome to the development shell!"
'';
name = "glossary-devshell";
name = "devshell";
packages = [
pkgs.pandoc
pkgs.caddy

BIN
public/assets/does-it-scale.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 96 KiB

BIN
public/assets/logo.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 14 KiB

After

Width:  |  Height:  |  Size: 61 KiB

BIN
public/favicon.ico
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 14 KiB

After

Width:  |  Height:  |  Size: 61 KiB

521
public/index.html
View File

@ -3,12 +3,12 @@
<head>
<meta charset="utf-8">
<meta name="generator" content="pandoc">
<title>Cardano Lightning</title>
<title>Konduit.channel</title>
<meta name="apple-mobile-web-app-capable" content="yes">
<meta name="apple-mobile-web-app-status-bar-style" content="black-translucent">
<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no, minimal-ui">
<link rel="stylesheet" href="https://unpkg.com/reveal.js@^4//dist/reset.css">
<link rel="stylesheet" href="https://unpkg.com/reveal.js@^4//dist/reveal.css">
<link rel="stylesheet" href="https://unpkg.com/reveal.js/dist/reset.css">
<link rel="stylesheet" href="https://unpkg.com/reveal.js/dist/reveal.css">
<style>
.reveal .sourceCode { /* see #7635 */
overflow: visible;
@ -29,21 +29,24 @@
}
.display.math{display: block; text-align: center; margin: 0.5rem auto;}
</style>
<link rel="stylesheet" href="https://unpkg.com/reveal.js@^4//dist/theme/black.css" id="theme">
<link rel="stylesheet" href="https://unpkg.com/reveal.js/dist/theme/black.css" id="theme">
<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link href="https://fonts.googleapis.com/css2?family=JetBrains+Mono:ital,wght@0,100..800;1,100..800&display=swap" rel="stylesheet">
<style>
body {
font-family: ui-sans-serif;
font-family: "JetBrains Mono", monospace;
}
.reveal h1, .reveal h2, .reveal h3, .reveal h4, .reveal h5, .reveal h6
.reveal h1, .reveal h2, .reveal h3, .reveal h4, .reveal h5, .reveal h6
{
font-family:"TruenoSemiBold", "ui-sans-serif";
font-family: "JetBrains Mono", monospace;
}
@font-face{
font-family:"TruenoSemiBold";
src:local("TruenoSemiBold"),
url("./fonts/TruenoSemiBold.woff2") format("woff2");
font-family: "JetBrains Mono", monospace;
font-weight: 600;
}
.black h2 {
background-color: #020210;
}
@ -54,7 +57,6 @@
.reveal .slides p {
margin: 2rem 0;
text-align:left;
}
.reveal .slides blockquote > p {
@ -68,177 +70,398 @@
<div class="slides">
<section id="title-slide" data-background-image="./assets/logo.png" data-background-opacity="0.3" data-background-size="contain">
<h1 class="title">Cardano Lightning</h1>
<p class="subtitle">Permissionless, near instant, highly scalable</p>
<h1 class="title">Konduit.channel</h1>
<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>
<section id="problem" class="title-slide slide level2">
<h2>Problem</h2>
<section id="what-is" class="title-slide slide level2">
<h2>What is …</h2>
</section>
<section id="payments" class="slide level3">
<h3>Payments</h3>
<ul>
<li>A fundamental part of all commerce: payment.</li>
</ul>
</section>
<section id="who" class="slide level3">
<h3>Who?</h3>
<p>There are three parties involved in a payment</p>
<ul>
<li>Consumer (ie payer)</li>
<li>Provider (ie payee)</li>
<li>Facilitator</li>
</ul>
<p>All of us are consumers, some are providers, a few are
facilitators.</p>
</section>
<section id="what-users-want" class="slide level3">
<h3>What users want</h3>
<section id="konduit" class="slide level3">
<h3>Konduit?</h3>
<blockquote>
<p>Users want secure, fast, low cost transactions</p>
<p>A Cardano to Bitcoin Lighting Pipe</p>
</blockquote>
<p>However participants have different priorities, <em>eg</em></p>
<!--
The first question is then "what is Bitcoin Lightning"
-->
</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.
-->
</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>Consumers want ease-of-use</li>
<li>Providers want fast confirmation</li>
<li>Facilitators need to handle at scale</li>
<li>Scalability</li>
<li>Finality</li>
<li>Tx fees</li>
</ul>
</div>
<!--
The classic complaints about (real) L1s
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.
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="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
-->
</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: 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 on the L1 that underwrite L2 messages.
For example you could have a channel with the coffee shop,
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?
An asside: This is a super interesting setup.
Subscription based services are "handwave" north of a trillion dollars and growing.
-->
</section>
<section id="hops" class="slide level3">
<h3>Hops</h3>
<ul>
<li>2 channels: Alice &lt;-&gt; Bob; Bob &lt;-&gt; Charlie</li>
<li>Alice ~&gt; Charlie ?</li>
<li>Alice ~&gt; Bob ~&gt; Charlie.</li>
<li>Problem: Naive hops require trust</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.
-->
</section>
<section id="htlcs" class="slide level3">
<h3>HTLCs</h3>
<ul>
<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: 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.
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
-->
</section>
<section id="routes" class="slide level3">
<h3>Routes</h3>
<ul>
<li>C ~&gt; A : Invoice including lock.</li>
<li>A ~&gt; B : HTLC with timeout <code>T</code> and lock</li>
<li>B ~&gt; C : HTLC with timeout <code>T - delta</code> and lock</li>
<li>C ~&gt; B : Secret</li>
<li>B ~&gt; C : Commitment to pay (no htlc)</li>
<li>B ~&gt; A : Secret</li>
<li>A ~&gt; B : Commitment to pay (no htlc)</li>
</ul>
<!--
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).
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="existing-systems-12" class="slide level3">
<h3>Existing systems (1/2)</h3>
<section id="overhead" class="slide level3">
<h3>Overhead?</h3>
<ul>
<li>Cash: Permissionless, instant, scalable-ish (lots of people can use
it at the same time, but only to pay people near them), questionable
security (fraud happens).</li>
<li>Bank transfer: Permissioned, some instant others very slow,
scalable.</li>
<li>Contactless/ Card: Permissioned, near instant, scalable</li>
</ul>
</section>
<section id="section" class="slide level3">
<h3>… (2/2)</h3>
<ul>
<li>Decentralised Ledger *: permissionless, maybe fast or scalable but
generally not both.</li>
</ul>
<p><span style="font-size: small"> * There are many different designs of
decentralised ledger, each with different choices and trade-offs. Some
permissioned, some more decentralised than others, some faster,
<em>etc</em>. </span></p>
</section>
<section id="market-size" class="slide level3">
<h3>Market size</h3>
<ul>
<li><p>Contactless transactions will reach $11 trillion by 2027 <span
style="font-size: small"> source : Juniper Research </span></p></li>
<li><p>Market Cap for crypto : &gt; $3 trillion <span
style="font-size: small"> source : coinmarketcap.com (Dec 2024)
</span></p></li>
</ul>
</section>
<section id="intersection" class="slide level3">
<h3>Intersection</h3>
<blockquote>
<p>Can we have contactless like experience but permissionless.</p>
</blockquote>
</section>
<section id="problem-statement" class="slide level3">
<h3>Problem statement</h3>
<p>We want a payment system that is:</p>
<ol type="1">
<li>Permissionless and secure</li>
<li>Near instant</li>
<li>Highly scalable</li>
</ol>
</section>
<section id="bitcoin-lightning-network" class="slide level3">
<h3>Bitcoin Lightning Network?</h3>
<p>In a lightning network:</p>
<ul>
<li>The network is fundamentally a set of channels, not a shared
ledger.</li>
<li>There is no need to reach consensus, or globally broadcasting
state.</li>
<li>Payments are routed across channels by participants.</li>
<li>Speed of payment isn’t a global property, but a more local one.</li>
</ul>
<p>BLN does this and is the closest to meeting our aims.</p>
</section>
<section id="problems-with-bln" class="slide level3">
<h3>Problems with BLN</h3>
<p>However it has some issues:</p>
<ul>
<li>Large technical and resource overhead to use. Every user must run a
node.</li>
<li>Difficult to efficiently manage capital. Liquidity is required to
enable payments to be routed across a network. Moving capital between
channels requires multiple transactions.</li>
<li>Alice (client) must remember their keys</li>
<li>Must be able to produce a signature</li>
<li>Maybe some other state (&lt; 100 bytes) or 2 trips.</li>
</ul>
</section></section>
<section>
<section id="solution" class="title-slide slide level2">
<h2>Solution</h2>
<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="cardano-lightning" class="slide level3">
<h3>Cardano Lightning</h3>
</section>
<section id="design" class="slide level3">
<h3>Design</h3>
<section id="keep-the-boons" class="slide level3">
<h3>Keep the boons</h3>
<ul>
<li>A perturbation on BLN: its a Lightning Network</li>
<li>Focused on addressing the key technical blockers to it being used as
a day-to-day payment system.</li>
<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="tailored-nodes" class="slide level3">
<h3>Tailored Nodes</h3>
<p>CL recognises a diversity users have a diversity of needs.</p>
<section id="other-deets" class="slide level3">
<h3>Other deets</h3>
<ul>
<li>For consumers we have a lightweight node, minimal resources, and
runs on their phone.</li>
<li>Some providers might be happy running their own servers, others
wont. There’s a flexible CL node + SDK to suit a full spectrum of
usecases.</li>
</ul>
</section>
<section id="leveraging-cardano" class="slide level3">
<h3>Leveraging Cardano</h3>
<ul>
<li><p>Cardano’s more powerful scripting language allows us to achieve
more with less.</p></li>
<li><p>In particular we can optimize capital allocation for
nodes.</p></li>
<li><p>For the facilitators, we have a node for efficient handling of
many channels concurrently. Those with capital and wanting to put it to
use become the facilitators. They receive income on the service they
provide, each payment they facilitate in routing.</p></li>
<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="team" class="title-slide slide level2">
<h2>Team</h2>
<section id="demo" class="title-slide slide level2">
<h2>Demo ?!</h2>
</section>
<section id="section-1" class="slide level3">
<h3></h3>
<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><span class="citation" data-cites="waalge">@waalge</span></li>
<li><span class="citation" data-cites="paluh">@paluh</span></li>
<li><span class="citation" data-cites="nhenin">@nhenin</span></li>
<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>
<script src="https://unpkg.com/reveal.js@^4//dist/reveal.js"></script>
<script src="https://unpkg.com/reveal.js/dist/reveal.js"></script>
<!-- reveal.js plugins -->
<script src="https://unpkg.com/reveal.js@^4//plugin/notes/notes.js"></script>
<script src="https://unpkg.com/reveal.js@^4//plugin/search/search.js"></script>
<script src="https://unpkg.com/reveal.js@^4//plugin/zoom/zoom.js"></script>
<script src="https://unpkg.com/reveal.js/plugin/notes/notes.js"></script>
<script src="https://unpkg.com/reveal.js/plugin/search/search.js"></script>
<script src="https://unpkg.com/reveal.js/plugin/zoom/zoom.js"></script>
<script>

16
src/header.html
View File

@ -1,17 +1,20 @@
<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link href="https://fonts.googleapis.com/css2?family=JetBrains+Mono:ital,wght@0,100..800;1,100..800&display=swap" rel="stylesheet">
<style>
body {
font-family: ui-sans-serif;
font-family: "JetBrains Mono", monospace;
}
.reveal h1, .reveal h2, .reveal h3, .reveal h4, .reveal h5, .reveal h6
.reveal h1, .reveal h2, .reveal h3, .reveal h4, .reveal h5, .reveal h6
{
font-family:"TruenoSemiBold", "ui-sans-serif";
font-family: "JetBrains Mono", monospace;
}
@font-face{
font-family:"TruenoSemiBold";
src:local("TruenoSemiBold"),
url("./fonts/TruenoSemiBold.woff2") format("woff2");
font-family: "JetBrains Mono", monospace;
font-weight: 600;
}
.black h2 {
background-color: #020210;
}
@ -22,7 +25,6 @@ body {
.reveal .slides p {
margin: 2rem 0;
text-align:left;
}
.reveal .slides blockquote > p {

340
src/index.md
View File

@ -1,130 +1,316 @@
---
title: Cardano Lightning
subtitle: Permissionless, near instant, highly scalable
mainfont: TruenoSemiBold
background-image: ./assets/background.svg
background-opacity: "0.35"
title: Konduit.channel
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
---
## Problem
## What is ...
### Payments
### Konduit?
- A fundamental part of all commerce: payment.
> A Cardano to Bitcoin Lighting Pipe
### Who?
<!--
The first question is then "what is Bitcoin Lightning"
-->
There are three parties involved in a payment
### Bitcoin Lightning?
- Consumer (ie payer)
- Provider (ie payee)
- Facilitator
... 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.
All of us are consumers, some are providers, a few are facilitators.
<!--
A slight abbreviation of the wiki entry
### What users want
A slightly trucated opening lines from the wikipedia page.
Whoever provided or endorsed this version clearly thinks this point is moot.
-->
> Users want secure, fast, low cost transactions
### The problem?
However participants have different priorities, _eg_
::: {style="display:flex;flex-direction:row;justify-content: space-around; align-items: center;"}
- Consumers want ease-of-use
- Providers want fast confirmation
- Facilitators need to handle at scale
![](./assets/does-it-scale.jpg)
### Existing systems (1/2)
- Scalability
- Finality
- Tx fees
- Cash: Permissionless, instant, scalable-ish (lots of people can use it at the same time, but only to pay people near them),
questionable security (fraud happens).
- Bank transfer: Permissioned, some instant others very slow, scalable.
- Contactless/ Card: Permissioned, near instant, scalable
:::
### ... (2/2)
<!--
The classic complaints about (real) L1s
- Decentralised Ledger \*: permissionless, maybe fast or scalable but generally not both.
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.
<span style="font-size: small">
\* There are many different designs of decentralised ledger,
each with different choices and trade-offs.
Some permissioned, some more decentralised than others, some faster, _etc_.
</span>
On finality, we arn't really competing with web2.
Payment providers can retroactively deny payments (no source).
### Market size
We, Cardano, have the same problem.
One route to remedy: don't reinvent the wheel, piggy back on their wheel.
-->
### The ask
- Contactless transactions will reach $11 trillion by 2027 <span style="font-size: small"> source : Juniper Research </span>
Can we go from Cardano to BLN?
- Market Cap for crypto : > $3 trillion <span style="font-size: small"> source : coinmarketcap.com (Dec 2024) </span>
<!--
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.
-->
### Intersection
## Lightning / BLN
> Can we have contactless like experience but permissionless.
<!--
A lightning round on Lightning network
-->
### Problem statement
### Overview
We want a payment system that is:
- A network of two party channels
- L1: Each channel is "underwritten" by locked funds
- L2: exchanging messages alters how and who can claim these funds
1. Permissionless and secure
2. Near instant
3. Highly scalable
<!--
Lightning is a network of two party channels.
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 coffee is paid for via an L2 message.
### Bitcoin Lightning Network?
Immediate questions:
In a lightning network:
- Do i need a channel with everyone I want to pay? If so whats the point?
- How is this a network?
- The network is fundamentally a set of channels, not a shared ledger.
- There is no need to reach consensus, or globally broadcasting state.
- Payments are routed across channels by participants.
- Speed of payment isn't a global property, but a more local one.
An asside: This is a super interesting setup.
Subscription based services are "handwave" north of a trillion dollars and growing.
-->
BLN does this and is the closest to meeting our aims.
### Hops
### Problems with BLN
- 2 channels: Alice <-> Bob; Bob <-> Charlie
- Alice ~> Charlie ?
- Alice ~> Bob ~> Charlie.
- Problem: Naive hops require trust
However it has some issues:
<!--
How to make a set of channels a network.
- Large technical and resource overhead to use. Every user must run a node.
- Difficult to efficiently manage capital.
Liquidity is required to enable payments to be routed across a network.
Moving capital between channels requires multiple transactions.
Shoe horning in another idea:
## Solution
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.
-->
### Cardano Lightning
### HTLCs
### Design
- 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`
- A perturbation on BLN: its a Lightning Network
- Focused on addressing the key technical blockers
to it being used as a day-to-day payment system.
<!--
Enter HTLCs
### Tailored Nodes
This is a basic implementation of an HTLC.
CL recognises a diversity users have a diversity of needs.
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.
- For consumers we have a lightweight node, minimal resources, and runs on their phone.
- Some providers might be happy running their own servers, others wont.
There's a flexible CL node + SDK to suit a full spectrum of usecases.
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
-->
### Leveraging Cardano
### Routes
- Cardano's more powerful scripting language allows
us to achieve more with less. In particular we can optimize capital allocation for nodes.
- C ~> A : Invoice including lock.
- A ~> B : HTLC with timeout `T` 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)
- For the facilitators, we have a node for efficient handling of many channels concurrently.
Those with capital and wanting to put it to use become the facilitators.
They receive income on the service they provide, each payment they facilitate in routing.
<!--
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).
## Team
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!
-->
- @waalge
- @paluh
- @nhenin
## 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