Compare commits
No commits in common. "e68c14079be136668c5bfd6e2611460baf6c90fd" and "0d72bc00e3bb68b9308d3e5e4090784dab92c7ab" have entirely different histories.
e68c14079b
...
0d72bc00e3
27
flake.lock
27
flake.lock
|
|
@ -5,11 +5,11 @@
|
|||
"nixpkgs-lib": "nixpkgs-lib"
|
||||
},
|
||||
"locked": {
|
||||
"lastModified": 1763759067,
|
||||
"narHash": "sha256-LlLt2Jo/gMNYAwOgdRQBrsRoOz7BPRkzvNaI/fzXi2Q=",
|
||||
"lastModified": 1733312601,
|
||||
"narHash": "sha256-4pDvzqnegAfRkPwO3wmwBhVi/Sye1mzps0zHWYnP88c=",
|
||||
"owner": "hercules-ci",
|
||||
"repo": "flake-parts",
|
||||
"rev": "2cccadc7357c0ba201788ae99c4dfa90728ef5e0",
|
||||
"rev": "205b12d8b7cd4802fbcb8e8ef6a0f1408781a4f9",
|
||||
"type": "github"
|
||||
},
|
||||
"original": {
|
||||
|
|
@ -20,11 +20,11 @@
|
|||
},
|
||||
"nixpkgs": {
|
||||
"locked": {
|
||||
"lastModified": 1764517877,
|
||||
"narHash": "sha256-pp3uT4hHijIC8JUK5MEqeAWmParJrgBVzHLNfJDZxg4=",
|
||||
"lastModified": 1734424634,
|
||||
"narHash": "sha256-cHar1vqHOOyC7f1+tVycPoWTfKIaqkoe1Q6TnKzuti4=",
|
||||
"owner": "NixOS",
|
||||
"repo": "nixpkgs",
|
||||
"rev": "2d293cbfa5a793b4c50d17c05ef9e385b90edf6c",
|
||||
"rev": "d3c42f187194c26d9f0309a8ecc469d6c878ce33",
|
||||
"type": "github"
|
||||
},
|
||||
"original": {
|
||||
|
|
@ -36,17 +36,14 @@
|
|||
},
|
||||
"nixpkgs-lib": {
|
||||
"locked": {
|
||||
"lastModified": 1761765539,
|
||||
"narHash": "sha256-b0yj6kfvO8ApcSE+QmA6mUfu8IYG6/uU28OFn4PaC8M=",
|
||||
"owner": "nix-community",
|
||||
"repo": "nixpkgs.lib",
|
||||
"rev": "719359f4562934ae99f5443f20aa06c2ffff91fc",
|
||||
"type": "github"
|
||||
"lastModified": 1733096140,
|
||||
"narHash": "sha256-1qRH7uAUsyQI7R1Uwl4T+XvdNv778H0Nb5njNrqvylY=",
|
||||
"type": "tarball",
|
||||
"url": "https://github.com/NixOS/nixpkgs/archive/5487e69da40cbd611ab2cadee0b4637225f7cfae.tar.gz"
|
||||
},
|
||||
"original": {
|
||||
"owner": "nix-community",
|
||||
"repo": "nixpkgs.lib",
|
||||
"type": "github"
|
||||
"type": "tarball",
|
||||
"url": "https://github.com/NixOS/nixpkgs/archive/5487e69da40cbd611ab2cadee0b4637225f7cfae.tar.gz"
|
||||
}
|
||||
},
|
||||
"root": {
|
||||
|
|
|
|||
|
|
@ -25,13 +25,10 @@
|
|||
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"
|
||||
|
|
@ -47,7 +44,7 @@
|
|||
shellHook = ''
|
||||
echo 1>&2 "Welcome to the development shell!"
|
||||
'';
|
||||
name = "devshell";
|
||||
name = "glossary-devshell";
|
||||
packages = [
|
||||
pkgs.pandoc
|
||||
pkgs.caddy
|
||||
|
|
|
|||
Binary file not shown.
|
Before Width: | Height: | Size: 96 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 61 KiB After Width: | Height: | Size: 14 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 61 KiB After Width: | Height: | Size: 14 KiB |
|
|
@ -3,12 +3,12 @@
|
|||
<head>
|
||||
<meta charset="utf-8">
|
||||
<meta name="generator" content="pandoc">
|
||||
<title>Konduit.channel</title>
|
||||
<title>Cardano Lightning</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/dist/reset.css">
|
||||
<link rel="stylesheet" href="https://unpkg.com/reveal.js/dist/reveal.css">
|
||||
<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">
|
||||
<style>
|
||||
.reveal .sourceCode { /* see #7635 */
|
||||
overflow: visible;
|
||||
|
|
@ -29,24 +29,21 @@
|
|||
}
|
||||
.display.math{display: block; text-align: center; margin: 0.5rem auto;}
|
||||
</style>
|
||||
<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">
|
||||
<link rel="stylesheet" href="https://unpkg.com/reveal.js@^4//dist/theme/black.css" id="theme">
|
||||
<style>
|
||||
body {
|
||||
font-family: "JetBrains Mono", monospace;
|
||||
font-family: ui-sans-serif;
|
||||
}
|
||||
.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: "JetBrains Mono", monospace;
|
||||
font-family:"TruenoSemiBold", "ui-sans-serif";
|
||||
}
|
||||
|
||||
@font-face{
|
||||
font-family: "JetBrains Mono", monospace;
|
||||
font-family:"TruenoSemiBold";
|
||||
src:local("TruenoSemiBold"),
|
||||
url("./fonts/TruenoSemiBold.woff2") format("woff2");
|
||||
font-weight: 600;
|
||||
}
|
||||
|
||||
.black h2 {
|
||||
background-color: #020210;
|
||||
}
|
||||
|
|
@ -57,6 +54,7 @@
|
|||
|
||||
.reveal .slides p {
|
||||
margin: 2rem 0;
|
||||
text-align:left;
|
||||
}
|
||||
|
||||
.reveal .slides blockquote > p {
|
||||
|
|
@ -70,398 +68,177 @@
|
|||
<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">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>
|
||||
<h1 class="title">Cardano Lightning</h1>
|
||||
<p class="subtitle">Permissionless, near instant, highly scalable</p>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<section id="what-is" class="title-slide slide level2">
|
||||
<h2>What is …</h2>
|
||||
<section id="problem" class="title-slide slide level2">
|
||||
<h2>Problem</h2>
|
||||
|
||||
</section>
|
||||
<section id="konduit" class="slide level3">
|
||||
<h3>Konduit?</h3>
|
||||
<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>
|
||||
<blockquote>
|
||||
<p>A Cardano to Bitcoin Lighting Pipe</p>
|
||||
<p>Users want secure, fast, low cost transactions</p>
|
||||
</blockquote>
|
||||
<!--
|
||||
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>
|
||||
<p>However participants have different priorities, <em>eg</em></p>
|
||||
<ul>
|
||||
<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 <-> 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>
|
||||
<li>Consumers want ease-of-use</li>
|
||||
<li>Providers want fast confirmation</li>
|
||||
<li>Facilitators need to handle at scale</li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="overhead" class="slide level3">
|
||||
<h3>Overhead?</h3>
|
||||
<section id="existing-systems-12" class="slide level3">
|
||||
<h3>Existing systems (1/2)</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>
|
||||
<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 : > $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>
|
||||
</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]
|
||||
<section id="solution" class="title-slide slide level2">
|
||||
<h2>Solution</h2>
|
||||
|
||||
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 id="cardano-lightning" class="slide level3">
|
||||
<h3>Cardano Lightning</h3>
|
||||
</section>
|
||||
<section id="other-deets" class="slide level3">
|
||||
<h3>Other deets</h3>
|
||||
<section id="design" class="slide level3">
|
||||
<h3>Design</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>
|
||||
<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>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="tailored-nodes" class="slide level3">
|
||||
<h3>Tailored Nodes</h3>
|
||||
<p>CL recognises a diversity users have a diversity of needs.</p>
|
||||
<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>
|
||||
</ul>
|
||||
<!--
|
||||
-->
|
||||
</section></section>
|
||||
<section>
|
||||
<section id="demo" class="title-slide slide level2">
|
||||
<h2>Demo ?!</h2>
|
||||
<section id="team" class="title-slide slide level2">
|
||||
<h2>Team</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>
|
||||
<section id="section-1" class="slide level3">
|
||||
<h3></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>
|
||||
<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>
|
||||
</ul>
|
||||
</section></section>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<script src="https://unpkg.com/reveal.js/dist/reveal.js"></script>
|
||||
<script src="https://unpkg.com/reveal.js@^4//dist/reveal.js"></script>
|
||||
|
||||
<!-- reveal.js plugins -->
|
||||
<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 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>
|
||||
|
||||
|
|
|
|||
|
|
@ -1,20 +1,17 @@
|
|||
<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: "JetBrains Mono", monospace;
|
||||
font-family: ui-sans-serif;
|
||||
}
|
||||
.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: "JetBrains Mono", monospace;
|
||||
font-family:"TruenoSemiBold", "ui-sans-serif";
|
||||
}
|
||||
|
||||
@font-face{
|
||||
font-family: "JetBrains Mono", monospace;
|
||||
font-family:"TruenoSemiBold";
|
||||
src:local("TruenoSemiBold"),
|
||||
url("./fonts/TruenoSemiBold.woff2") format("woff2");
|
||||
font-weight: 600;
|
||||
}
|
||||
|
||||
.black h2 {
|
||||
background-color: #020210;
|
||||
}
|
||||
|
|
@ -25,6 +22,7 @@ body {
|
|||
|
||||
.reveal .slides p {
|
||||
margin: 2rem 0;
|
||||
text-align:left;
|
||||
}
|
||||
|
||||
.reveal .slides blockquote > p {
|
||||
|
|
|
|||
340
src/index.md
340
src/index.md
|
|
@ -1,316 +1,130 @@
|
|||
---
|
||||
title: Konduit.channel
|
||||
subtitle: "[A bunch of ideas in 15mins]"
|
||||
mainfont: monospace
|
||||
title: Cardano Lightning
|
||||
subtitle: Permissionless, near instant, highly scalable
|
||||
mainfont: TruenoSemiBold
|
||||
background-image: ./assets/background.svg
|
||||
background-opacity: "0.35"
|
||||
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
|
||||
---
|
||||
|
||||
## What is ...
|
||||
## Problem
|
||||
|
||||
### Konduit?
|
||||
### Payments
|
||||
|
||||
> A Cardano to Bitcoin Lighting Pipe
|
||||
- A fundamental part of all commerce: payment.
|
||||
|
||||
<!--
|
||||
The first question is then "what is Bitcoin Lightning"
|
||||
-->
|
||||
### Who?
|
||||
|
||||
### Bitcoin Lightning?
|
||||
There are three parties involved in a payment
|
||||
|
||||
... 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.
|
||||
- Consumer (ie payer)
|
||||
- Provider (ie payee)
|
||||
- Facilitator
|
||||
|
||||
<!--
|
||||
A slight abbreviation of the wiki entry
|
||||
All of us are consumers, some are providers, a few are facilitators.
|
||||
|
||||
A slightly trucated opening lines from the wikipedia page.
|
||||
Whoever provided or endorsed this version clearly thinks this point is moot.
|
||||
-->
|
||||
### What users want
|
||||
|
||||
### The problem?
|
||||
> Users want secure, fast, low cost transactions
|
||||
|
||||
::: {style="display:flex;flex-direction:row;justify-content: space-around; align-items: center;"}
|
||||
However participants have different priorities, _eg_
|
||||
|
||||
|
||||
- Consumers want ease-of-use
|
||||
- Providers want fast confirmation
|
||||
- Facilitators need to handle at scale
|
||||
|
||||
- Scalability
|
||||
- Finality
|
||||
- Tx fees
|
||||
### Existing systems (1/2)
|
||||
|
||||
:::
|
||||
- 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
|
||||
|
||||
<!--
|
||||
The classic complaints about (real) L1s
|
||||
### ... (2/2)
|
||||
|
||||
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.
|
||||
- Decentralised Ledger \*: permissionless, maybe fast or scalable but generally not both.
|
||||
|
||||
On finality, we arn't really competing with web2.
|
||||
Payment providers can retroactively deny payments (no source).
|
||||
<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>
|
||||
|
||||
We, Cardano, have the same problem.
|
||||
One route to remedy: don't reinvent the wheel, piggy back on their wheel.
|
||||
-->
|
||||
### Market size
|
||||
|
||||
### The ask
|
||||
|
||||
Can we go from Cardano to BLN?
|
||||
- Contactless transactions will reach $11 trillion by 2027 <span style="font-size: small"> source : Juniper Research </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.
|
||||
-->
|
||||
- Market Cap for crypto : > $3 trillion <span style="font-size: small"> source : coinmarketcap.com (Dec 2024) </span>
|
||||
|
||||
## Lightning / BLN
|
||||
### Intersection
|
||||
|
||||
<!--
|
||||
A lightning round on Lightning network
|
||||
-->
|
||||
> Can we have contactless like experience but permissionless.
|
||||
|
||||
### Overview
|
||||
### Problem statement
|
||||
|
||||
- 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
|
||||
We want a payment system that is:
|
||||
|
||||
<!--
|
||||
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.
|
||||
1. Permissionless and secure
|
||||
2. Near instant
|
||||
3. Highly scalable
|
||||
|
||||
Immediate questions:
|
||||
### Bitcoin Lightning Network?
|
||||
|
||||
- Do i need a channel with everyone I want to pay? If so whats the point?
|
||||
- How is this a network?
|
||||
In a lightning network:
|
||||
|
||||
An asside: This is a super interesting setup.
|
||||
Subscription based services are "handwave" north of a trillion dollars and growing.
|
||||
-->
|
||||
- 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.
|
||||
|
||||
### Hops
|
||||
BLN does this and is the closest to meeting our aims.
|
||||
|
||||
- 2 channels: Alice <-> Bob; Bob <-> Charlie
|
||||
- Alice ~> Charlie ?
|
||||
- Alice ~> Bob ~> Charlie.
|
||||
- Problem: Naive hops require trust
|
||||
### Problems with BLN
|
||||
|
||||
<!--
|
||||
How to make a set of channels a network.
|
||||
However it has some issues:
|
||||
|
||||
Shoe horning in another idea:
|
||||
- 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.
|
||||
|
||||
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.
|
||||
-->
|
||||
## Solution
|
||||
|
||||
### HTLCs
|
||||
### Cardano Lightning
|
||||
|
||||
- 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`
|
||||
### Design
|
||||
|
||||
<!--
|
||||
Enter HTLCs
|
||||
- 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.
|
||||
|
||||
This is a basic implementation of an HTLC.
|
||||
### Tailored Nodes
|
||||
|
||||
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.
|
||||
CL recognises a diversity users have a diversity of needs.
|
||||
|
||||
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
|
||||
-->
|
||||
- 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.
|
||||
|
||||
### Routes
|
||||
### Leveraging Cardano
|
||||
|
||||
- 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)
|
||||
- Cardano's more powerful scripting language allows
|
||||
us to achieve more with less. In particular we can optimize capital allocation for nodes.
|
||||
|
||||
<!--
|
||||
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).
|
||||
- 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.
|
||||
|
||||
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.)
|
||||
## Team
|
||||
|
||||
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
|
||||
- @waalge
|
||||
- @paluh
|
||||
- @nhenin
|
||||
|
|
|
|||
Loading…
Reference in New Issue