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

622 lines
20 KiB
HTML
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<meta name="generator" content="pandoc">
<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/dist/reset.css">
<link rel="stylesheet" href="https://unpkg.com/reveal.js/dist/reveal.css">
<style>
.reveal .sourceCode { /* see #7635 */
overflow: visible;
}
code{white-space: pre-wrap;}
span.smallcaps{font-variant: small-caps;}
div.columns{display: flex; gap: min(4vw, 1.5em);}
div.column{flex: auto; overflow-x: auto;}
div.hanging-indent{margin-left: 1.5em; text-indent: -1.5em;}
/* The extra [class] is a hack that increases specificity enough to
override a similar rule in reveal.js */
ul.task-list[class]{list-style: none;}
ul.task-list li input[type="checkbox"] {
font-size: inherit;
width: 0.8em;
margin: 0 0.8em 0.2em -1.6em;
vertical-align: middle;
}
.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">
<style>
body {
font-family: "JetBrains Mono", monospace;
}
.reveal h1, .reveal h2, .reveal h3, .reveal h4, .reveal h5, .reveal h6
{
font-family: "JetBrains Mono", monospace;
}
@font-face{
font-family: "JetBrains Mono", monospace;
font-weight: 600;
}
.black h2 {
background-color: #020210;
}
.reveal ul {
list-style-type: "- ";
}
.reveal .slides p {
margin: 2rem 0;
}
.reveal .slides blockquote > p {
text-align:center;
}
</style>
</head>
<body>
<div class="reveal">
<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>
</section>
<section>
<section id="what-is" class="title-slide slide level2">
<h2>What is …</h2>
</section>
<section id="konduit" class="slide level3">
<h3>Konduit?</h3>
<blockquote>
<p>A Cardano to Bitcoin Lighting Pipe</p>
</blockquote>
<!--
The first question is then "what is Bitcoin Lightning"
-->
</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>Scalability</li>
<li>Finality</li>
<li>Tx fees</li>
</ul>
</div>
<!--
You cannot walk into a cafe, say, and purchase a coffee on the L1.
Ok its probably fine (we have no traffic, long rollbacks don't happen. wink emoji).
But it shouldn't make sense: We cannot have all the nodes handling everyone's morning coffee purchase.
It does not scale.
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="overhead" class="slide level3">
<h3>Overhead?</h3>
<ul>
<li>Alice (client) must remember their keys</li>
<li>Must be able to produce a signature</li>
<li>Maybe some other state (&lt; 100 bytes) or 2 trips.</li>
</ul>
</section></section>
<section>
<section id="konduit-1" class="title-slide slide level2">
<h2>Konduit</h2>
<!--
Ok. Back on topic: how are we going to meet the ask
-->
</section>
<section id="subbit-htlcs" class="slide level3">
<h3>Subbit + HTLCs</h3>
<p>Not IOUs, but cheques + squashes</p>
<pre class="cddl"><code>cheque_body = [index, amount, timeout, lock]
cheque = [cheque_body, signature]
excludes = [* index]
squash_body = [amount, index, excludes]
squash = [squash_body, signature]</code></pre>
<!--
The role is essentially the same.
The signature is of a message that is a mild reworking of the version in subbit.
On a happy path, a cheque is made, a secret learned and shared, and the cheque is squashed.
-->
</section>
<section id="keep-the-boons" class="slide level3">
<h3>Keep the boons</h3>
<ul>
<li>Alice still doesn’t need chain liveness</li>
<li>Bob unilateral subs now have the evidence:</li>
</ul>
<pre class="cddl"><code>unlocked = [cheque_body, signature, secret]
receipt = [squash, [*unlocked]] </code></pre>
<!--
On the happy path the list of unlockeds will be empty.
But maybe Alice goes offline before bob learns the secret.
-->
</section>
<section id="other-deets" class="slide level3">
<h3>Other deets</h3>
<ul>
<li>Token free design</li>
<li>“Batch” txs are first class</li>
<li>“Mutual” txs are first class and invoke no futher verification steps
(beyond <code>required_signers</code>)</li>
</ul>
<!--
-->
</section></section>
<section>
<section id="demo" class="title-slide slide level2">
<h2>Demo ?!</h2>
</section>
<section id="soon" class="slide level3">
<h3>Soon™</h3>
</section></section>
<section>
<section id="ideas" class="title-slide slide level2">
<h2>Ideas</h2>
</section>
<section id="ideas-inner" class="slide level3" style="display:none">
<h3 style="display:none">ideas inner</h3>
<ul>
<li>The topology of our networks should reflect their usage</li>
<li>Cardano’s super power: verify signatures of arbitrary data</li>
<li>All dapps should be L2s</li>
<li>A dapp devs main role is to keep user’s from others</li>
<li>You don’t need tokens</li>
</ul>
</section></section>
</div>
</div>
<script src="https://unpkg.com/reveal.js/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>
// Full list of configuration options available at:
// https://revealjs.com/config/
Reveal.initialize({
// Display controls in the bottom right corner
controls: true,
// Help the user learn the controls by providing hints, for example by
// bouncing the down arrow when they first encounter a vertical slide
controlsTutorial: true,
// Determines where controls appear, "edges" or "bottom-right"
controlsLayout: 'bottom-right',
// Visibility rule for backwards navigation arrows; "faded", "hidden"
// or "visible"
controlsBackArrows: 'faded',
// Display a presentation progress bar
progress: true,
// Display the page number of the current slide
slideNumber: false,
// 'all', 'print', or 'speaker'
showSlideNumber: 'all',
// Add the current slide number to the URL hash so that reloading the
// page/copying the URL will return you to the same slide
hash: true,
// Start with 1 for the hash rather than 0
hashOneBasedIndex: false,
// Flags if we should monitor the hash and change slides accordingly
respondToHashChanges: true,
// Push each slide change to the browser history
history: false,
// Enable keyboard shortcuts for navigation
keyboard: true,
// Enable the slide overview mode
overview: true,
// Disables the default reveal.js slide layout (scaling and centering)
// so that you can use custom CSS layout
disableLayout: false,
// Vertical centering of slides
center: true,
// Enables touch navigation on devices with touch input
touch: true,
// Loop the presentation
loop: false,
// Change the presentation direction to be RTL
rtl: false,
// see https://revealjs.com/vertical-slides/#navigation-mode
navigationMode: 'default',
// Randomizes the order of slides each time the presentation loads
shuffle: false,
// Turns fragments on and off globally
fragments: true,
// Flags whether to include the current fragment in the URL,
// so that reloading brings you to the same fragment position
fragmentInURL: true,
// Flags if the presentation is running in an embedded mode,
// i.e. contained within a limited portion of the screen
embedded: false,
// Flags if we should show a help overlay when the questionmark
// key is pressed
help: true,
// Flags if it should be possible to pause the presentation (blackout)
pause: true,
// Flags if speaker notes should be visible to all viewers
showNotes: false,
// Global override for autoplaying embedded media (null/true/false)
autoPlayMedia: null,
// Global override for preloading lazy-loaded iframes (null/true/false)
preloadIframes: null,
// Number of milliseconds between automatically proceeding to the
// next slide, disabled when set to 0, this value can be overwritten
// by using a data-autoslide attribute on your slides
autoSlide: 0,
// Stop auto-sliding after user input
autoSlideStoppable: true,
// Use this method for navigation when auto-sliding
autoSlideMethod: null,
// Specify the average time in seconds that you think you will spend
// presenting each slide. This is used to show a pacing timer in the
// speaker view
defaultTiming: null,
// Enable slide navigation via mouse wheel
mouseWheel: false,
// The display mode that will be used to show slides
display: 'block',
// Hide cursor if inactive
hideInactiveCursor: true,
// Time before the cursor is hidden (in ms)
hideCursorTime: 5000,
// Opens links in an iframe preview overlay
previewLinks: false,
// Transition style (none/fade/slide/convex/concave/zoom)
transition: 'slide',
// Transition speed (default/fast/slow)
transitionSpeed: 'default',
// Transition style for full page slide backgrounds
// (none/fade/slide/convex/concave/zoom)
backgroundTransition: 'fade',
// Number of slides away from the current that are visible
viewDistance: 3,
// Number of slides away from the current that are visible on mobile
// devices. It is advisable to set this to a lower number than
// viewDistance in order to save resources.
mobileViewDistance: 2,
// Parallax background image
parallaxBackgroundImage: './assets/background.svg', // e.g. "'https://s3.amazonaws.com/hakim-static/reveal-js/reveal-parallax-1.jpg'"
// reveal.js plugins
plugins: [
RevealNotes,
RevealSearch,
RevealZoom
]
});
</script>
</body>
</html>
Reference in New Issue View Git Blame Copy Permalink