Compare commits
3 Commits
0d72bc00e3
...
e68c14079b
| Author | SHA1 | Date |
|---|---|---|
waalge
|
e68c14079b | |
|
waalge
|
5e31ac9bf8 | |
|
waalge
|
4911f6b3e3 |
27
flake.lock
27
flake.lock
|
|
@ -5,11 +5,11 @@
|
||||||
"nixpkgs-lib": "nixpkgs-lib"
|
"nixpkgs-lib": "nixpkgs-lib"
|
||||||
},
|
},
|
||||||
"locked": {
|
"locked": {
|
||||||
"lastModified": 1733312601,
|
"lastModified": 1763759067,
|
||||||
"narHash": "sha256-4pDvzqnegAfRkPwO3wmwBhVi/Sye1mzps0zHWYnP88c=",
|
"narHash": "sha256-LlLt2Jo/gMNYAwOgdRQBrsRoOz7BPRkzvNaI/fzXi2Q=",
|
||||||
"owner": "hercules-ci",
|
"owner": "hercules-ci",
|
||||||
"repo": "flake-parts",
|
"repo": "flake-parts",
|
||||||
"rev": "205b12d8b7cd4802fbcb8e8ef6a0f1408781a4f9",
|
"rev": "2cccadc7357c0ba201788ae99c4dfa90728ef5e0",
|
||||||
"type": "github"
|
"type": "github"
|
||||||
},
|
},
|
||||||
"original": {
|
"original": {
|
||||||
|
|
@ -20,11 +20,11 @@
|
||||||
},
|
},
|
||||||
"nixpkgs": {
|
"nixpkgs": {
|
||||||
"locked": {
|
"locked": {
|
||||||
"lastModified": 1734424634,
|
"lastModified": 1764517877,
|
||||||
"narHash": "sha256-cHar1vqHOOyC7f1+tVycPoWTfKIaqkoe1Q6TnKzuti4=",
|
"narHash": "sha256-pp3uT4hHijIC8JUK5MEqeAWmParJrgBVzHLNfJDZxg4=",
|
||||||
"owner": "NixOS",
|
"owner": "NixOS",
|
||||||
"repo": "nixpkgs",
|
"repo": "nixpkgs",
|
||||||
"rev": "d3c42f187194c26d9f0309a8ecc469d6c878ce33",
|
"rev": "2d293cbfa5a793b4c50d17c05ef9e385b90edf6c",
|
||||||
"type": "github"
|
"type": "github"
|
||||||
},
|
},
|
||||||
"original": {
|
"original": {
|
||||||
|
|
@ -36,14 +36,17 @@
|
||||||
},
|
},
|
||||||
"nixpkgs-lib": {
|
"nixpkgs-lib": {
|
||||||
"locked": {
|
"locked": {
|
||||||
"lastModified": 1733096140,
|
"lastModified": 1761765539,
|
||||||
"narHash": "sha256-1qRH7uAUsyQI7R1Uwl4T+XvdNv778H0Nb5njNrqvylY=",
|
"narHash": "sha256-b0yj6kfvO8ApcSE+QmA6mUfu8IYG6/uU28OFn4PaC8M=",
|
||||||
"type": "tarball",
|
"owner": "nix-community",
|
||||||
"url": "https://github.com/NixOS/nixpkgs/archive/5487e69da40cbd611ab2cadee0b4637225f7cfae.tar.gz"
|
"repo": "nixpkgs.lib",
|
||||||
|
"rev": "719359f4562934ae99f5443f20aa06c2ffff91fc",
|
||||||
|
"type": "github"
|
||||||
},
|
},
|
||||||
"original": {
|
"original": {
|
||||||
"type": "tarball",
|
"owner": "nix-community",
|
||||||
"url": "https://github.com/NixOS/nixpkgs/archive/5487e69da40cbd611ab2cadee0b4637225f7cfae.tar.gz"
|
"repo": "nixpkgs.lib",
|
||||||
|
"type": "github"
|
||||||
}
|
}
|
||||||
},
|
},
|
||||||
"root": {
|
"root": {
|
||||||
|
|
|
||||||
|
|
@ -25,10 +25,13 @@
|
||||||
build = pkgs.writeShellScriptBin "build"
|
build = pkgs.writeShellScriptBin "build"
|
||||||
''
|
''
|
||||||
pandoc -t revealjs \
|
pandoc -t revealjs \
|
||||||
|
-V revealjs-url=https://unpkg.com/reveal.js \
|
||||||
--from markdown+yaml_metadata_block+link_attributes \
|
--from markdown+yaml_metadata_block+link_attributes \
|
||||||
-H src/header.html \
|
-H src/header.html \
|
||||||
-o public/index.html \
|
-o public/index.html \
|
||||||
-s \
|
-s \
|
||||||
|
--slide-level 3 \
|
||||||
|
--toc \
|
||||||
src/index.md
|
src/index.md
|
||||||
'';
|
'';
|
||||||
serve = pkgs.writeShellScriptBin "serve"
|
serve = pkgs.writeShellScriptBin "serve"
|
||||||
|
|
@ -44,7 +47,7 @@
|
||||||
shellHook = ''
|
shellHook = ''
|
||||||
echo 1>&2 "Welcome to the development shell!"
|
echo 1>&2 "Welcome to the development shell!"
|
||||||
'';
|
'';
|
||||||
name = "glossary-devshell";
|
name = "devshell";
|
||||||
packages = [
|
packages = [
|
||||||
pkgs.pandoc
|
pkgs.pandoc
|
||||||
pkgs.caddy
|
pkgs.caddy
|
||||||
|
|
|
||||||
Binary file not shown.
|
After Width: | Height: | Size: 96 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 14 KiB After Width: | Height: | Size: 61 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 14 KiB After Width: | Height: | Size: 61 KiB |
|
|
@ -3,12 +3,12 @@
|
||||||
<head>
|
<head>
|
||||||
<meta charset="utf-8">
|
<meta charset="utf-8">
|
||||||
<meta name="generator" content="pandoc">
|
<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-capable" content="yes">
|
||||||
<meta name="apple-mobile-web-app-status-bar-style" content="black-translucent">
|
<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">
|
<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/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/reveal.css">
|
||||||
<style>
|
<style>
|
||||||
.reveal .sourceCode { /* see #7635 */
|
.reveal .sourceCode { /* see #7635 */
|
||||||
overflow: visible;
|
overflow: visible;
|
||||||
|
|
@ -29,21 +29,24 @@
|
||||||
}
|
}
|
||||||
.display.math{display: block; text-align: center; margin: 0.5rem auto;}
|
.display.math{display: block; text-align: center; margin: 0.5rem auto;}
|
||||||
</style>
|
</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>
|
<style>
|
||||||
body {
|
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-face{
|
||||||
font-family:"TruenoSemiBold";
|
font-family: "JetBrains Mono", monospace;
|
||||||
src:local("TruenoSemiBold"),
|
|
||||||
url("./fonts/TruenoSemiBold.woff2") format("woff2");
|
|
||||||
font-weight: 600;
|
font-weight: 600;
|
||||||
}
|
}
|
||||||
|
|
||||||
.black h2 {
|
.black h2 {
|
||||||
background-color: #020210;
|
background-color: #020210;
|
||||||
}
|
}
|
||||||
|
|
@ -54,7 +57,6 @@
|
||||||
|
|
||||||
.reveal .slides p {
|
.reveal .slides p {
|
||||||
margin: 2rem 0;
|
margin: 2rem 0;
|
||||||
text-align:left;
|
|
||||||
}
|
}
|
||||||
|
|
||||||
.reveal .slides blockquote > p {
|
.reveal .slides blockquote > p {
|
||||||
|
|
@ -68,177 +70,398 @@
|
||||||
<div class="slides">
|
<div class="slides">
|
||||||
|
|
||||||
<section id="title-slide" data-background-image="./assets/logo.png" data-background-opacity="0.3" data-background-size="contain">
|
<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>
|
<h1 class="title">Konduit.channel</h1>
|
||||||
<p class="subtitle">Permissionless, near instant, highly scalable</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>
|
||||||
|
|
||||||
<section>
|
<section>
|
||||||
<section id="problem" class="title-slide slide level2">
|
<section id="what-is" class="title-slide slide level2">
|
||||||
<h2>Problem</h2>
|
<h2>What is …</h2>
|
||||||
|
|
||||||
</section>
|
</section>
|
||||||
<section id="payments" class="slide level3">
|
<section id="konduit" class="slide level3">
|
||||||
<h3>Payments</h3>
|
<h3>Konduit?</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>
|
|
||||||
<blockquote>
|
<blockquote>
|
||||||
<p>Users want secure, fast, low cost transactions</p>
|
<p>A Cardano to Bitcoin Lighting Pipe</p>
|
||||||
</blockquote>
|
</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>
|
<ul>
|
||||||
<li>Consumers want ease-of-use</li>
|
<li>Scalability</li>
|
||||||
<li>Providers want fast confirmation</li>
|
<li>Finality</li>
|
||||||
<li>Facilitators need to handle at scale</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 <-> Bob; Bob <-> Charlie</li>
|
||||||
|
<li>Alice ~> Charlie ?</li>
|
||||||
|
<li>Alice ~> Bob ~> 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 ~> 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 - 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, 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>
|
</ul>
|
||||||
</section>
|
</section>
|
||||||
<section id="existing-systems-12" class="slide level3">
|
<section id="overhead" class="slide level3">
|
||||||
<h3>Existing systems (1/2)</h3>
|
<h3>Overhead?</h3>
|
||||||
<ul>
|
<ul>
|
||||||
<li>Cash: Permissionless, instant, scalable-ish (lots of people can use
|
<li>Alice (client) must remember their keys</li>
|
||||||
it at the same time, but only to pay people near them), questionable
|
<li>Must be able to produce a signature</li>
|
||||||
security (fraud happens).</li>
|
<li>Maybe some other state (< 100 bytes) or 2 trips.</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 : > $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>
|
|
||||||
</ul>
|
</ul>
|
||||||
</section></section>
|
</section></section>
|
||||||
<section>
|
<section>
|
||||||
<section id="solution" class="title-slide slide level2">
|
<section id="konduit-1" class="title-slide slide level2">
|
||||||
<h2>Solution</h2>
|
<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>
|
||||||
<section id="cardano-lightning" class="slide level3">
|
<section id="keep-the-boons" class="slide level3">
|
||||||
<h3>Cardano Lightning</h3>
|
<h3>Keep the boons</h3>
|
||||||
</section>
|
|
||||||
<section id="design" class="slide level3">
|
|
||||||
<h3>Design</h3>
|
|
||||||
<ul>
|
<ul>
|
||||||
<li>A perturbation on BLN: its a Lightning Network</li>
|
<li>Alice still doesn’t need chain liveness</li>
|
||||||
<li>Focused on addressing the key technical blockers to it being used as
|
<li>Bob unilateral subs now have the evidence:</li>
|
||||||
a day-to-day payment system.</li>
|
|
||||||
</ul>
|
</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>
|
||||||
<section id="tailored-nodes" class="slide level3">
|
<section id="other-deets" class="slide level3">
|
||||||
<h3>Tailored Nodes</h3>
|
<h3>Other deets</h3>
|
||||||
<p>CL recognises a diversity users have a diversity of needs.</p>
|
|
||||||
<ul>
|
<ul>
|
||||||
<li>For consumers we have a lightweight node, minimal resources, and
|
<li>Token free design</li>
|
||||||
runs on their phone.</li>
|
<li>“Batch” txs are first class</li>
|
||||||
<li>Some providers might be happy running their own servers, others
|
<li>“Mutual” txs are first class and invoke no futher verification steps
|
||||||
wont. There’s a flexible CL node + SDK to suit a full spectrum of
|
(beyond <code>required_signers</code>)</li>
|
||||||
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>
|
|
||||||
</ul>
|
</ul>
|
||||||
|
<!--
|
||||||
|
-->
|
||||||
</section></section>
|
</section></section>
|
||||||
<section>
|
<section>
|
||||||
<section id="team" class="title-slide slide level2">
|
<section id="demo" class="title-slide slide level2">
|
||||||
<h2>Team</h2>
|
<h2>Demo ?!</h2>
|
||||||
|
|
||||||
</section>
|
</section>
|
||||||
<section id="section-1" class="slide level3">
|
<section id="soon" class="slide level3">
|
||||||
<h3></h3>
|
<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>
|
<ul>
|
||||||
<li><span class="citation" data-cites="waalge">@waalge</span></li>
|
<li>The topology of our networks should reflect their usage</li>
|
||||||
<li><span class="citation" data-cites="paluh">@paluh</span></li>
|
<li>Cardano’s super power: verify signatures of arbitrary data</li>
|
||||||
<li><span class="citation" data-cites="nhenin">@nhenin</span></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>
|
</ul>
|
||||||
</section></section>
|
</section></section>
|
||||||
</div>
|
</div>
|
||||||
</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 -->
|
<!-- reveal.js plugins -->
|
||||||
<script src="https://unpkg.com/reveal.js@^4//plugin/notes/notes.js"></script>
|
<script src="https://unpkg.com/reveal.js/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/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/zoom/zoom.js"></script>
|
||||||
|
|
||||||
<script>
|
<script>
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -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>
|
<style>
|
||||||
body {
|
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-face{
|
||||||
font-family:"TruenoSemiBold";
|
font-family: "JetBrains Mono", monospace;
|
||||||
src:local("TruenoSemiBold"),
|
|
||||||
url("./fonts/TruenoSemiBold.woff2") format("woff2");
|
|
||||||
font-weight: 600;
|
font-weight: 600;
|
||||||
}
|
}
|
||||||
|
|
||||||
.black h2 {
|
.black h2 {
|
||||||
background-color: #020210;
|
background-color: #020210;
|
||||||
}
|
}
|
||||||
|
|
@ -22,7 +25,6 @@ body {
|
||||||
|
|
||||||
.reveal .slides p {
|
.reveal .slides p {
|
||||||
margin: 2rem 0;
|
margin: 2rem 0;
|
||||||
text-align:left;
|
|
||||||
}
|
}
|
||||||
|
|
||||||
.reveal .slides blockquote > p {
|
.reveal .slides blockquote > p {
|
||||||
|
|
|
||||||
340
src/index.md
340
src/index.md
|
|
@ -1,130 +1,316 @@
|
||||||
---
|
---
|
||||||
title: Cardano Lightning
|
title: Konduit.channel
|
||||||
subtitle: Permissionless, near instant, highly scalable
|
subtitle: "[A bunch of ideas in 15mins]"
|
||||||
mainfont: TruenoSemiBold
|
mainfont: monospace
|
||||||
background-image: ./assets/background.svg
|
|
||||||
background-opacity: "0.35"
|
|
||||||
title-slide-attributes:
|
title-slide-attributes:
|
||||||
data-background-image: ./assets/logo.png
|
data-background-image: ./assets/logo.png
|
||||||
data-background-size: contain
|
data-background-size: contain
|
||||||
data-background-opacity: "0.3"
|
data-background-opacity: "0.3"
|
||||||
background-image: ./assets/background.svg
|
background-image: ./assets/background.svg
|
||||||
background-opacity: "0.35"
|
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)
|
... a payment protocol built on bitcoin intended to enable fast transactions among participating nodes
|
||||||
- Provider (ie payee)
|
and has been proposed as a solution to the bitcoin scalability problem.
|
||||||
- Facilitator
|
|
||||||
|
|
||||||
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
|
|
||||||
|
|
||||||
### 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">
|
On finality, we arn't really competing with web2.
|
||||||
\* There are many different designs of decentralised ledger,
|
Payment providers can retroactively deny payments (no source).
|
||||||
each with different choices and trade-offs.
|
|
||||||
Some permissioned, some more decentralised than others, some faster, _etc_.
|
|
||||||
</span>
|
|
||||||
|
|
||||||
### 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
|
Lightning is a network of two party channels.
|
||||||
3. Highly scalable
|
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.
|
An asside: This is a super interesting setup.
|
||||||
- There is no need to reach consensus, or globally broadcasting state.
|
Subscription based services are "handwave" north of a trillion dollars and growing.
|
||||||
- Payments are routed across channels by participants.
|
-->
|
||||||
- Speed of payment isn't a global property, but a more local one.
|
|
||||||
|
|
||||||
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.
|
Shoe horning in another idea:
|
||||||
- Difficult to efficiently manage capital.
|
|
||||||
Liquidity is required to enable payments to be routed across a network.
|
|
||||||
Moving capital between channels requires multiple transactions.
|
|
||||||
|
|
||||||
## 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
|
Enter HTLCs
|
||||||
to it being used as a day-to-day payment system.
|
|
||||||
|
|
||||||
### 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.
|
A warning: the term HTLC is used to mean the "contract", the output at the contract, the would be output in tx not submitted,
|
||||||
- Some providers might be happy running their own servers, others wont.
|
and the general concept illustrated
|
||||||
There's a flexible CL node + SDK to suit a full spectrum of usecases.
|
-->
|
||||||
|
|
||||||
### Leveraging Cardano
|
### Routes
|
||||||
|
|
||||||
- Cardano's more powerful scripting language allows
|
- C ~> A : Invoice including lock.
|
||||||
us to achieve more with less. In particular we can optimize capital allocation for nodes.
|
- 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.
|
This is the message flow, at least for the happy path.
|
||||||
They receive income on the service they provide, each payment they facilitate in routing.
|
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
|
## Cardano Lightning
|
||||||
- @paluh
|
|
||||||
- @nhenin
|
### 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