This commit is contained in:
waalge 2024-12-22 16:53:37 +00:00
parent cd02716fe7
commit 0d72bc00e3
5 changed files with 218 additions and 45 deletions

Binary file not shown.

Before

Width:  |  Height:  |  Size: 14 KiB

After

Width:  |  Height:  |  Size: 14 KiB

View File

@ -31,20 +31,25 @@
</style>
<link rel="stylesheet" href="https://unpkg.com/reveal.js@^4//dist/theme/black.css" id="theme">
<style>
.reveal, .reveal h1, .reveal h2, .reveal h3, .reveal h4, .reveal h5, .reveal h6
body {
font-family: ui-sans-serif;
}
.reveal h1, .reveal h2, .reveal h3, .reveal h4, .reveal h5, .reveal h6
{
font-family:"jetbrains-mono", "Times New Roman", Times;
font-family:"TruenoSemiBold", "ui-sans-serif";
}
@font-face{
font-family:jetbrains-mono;src:local("TruenoSemiBold"),
font-family:"TruenoSemiBold";
src:local("TruenoSemiBold"),
url("./fonts/TruenoSemiBold.woff2") format("woff2");
font-weight: 600;
}
.black h2 {
background-color: #020210;
}
.reveal ul {
list-style-type: " ";
list-style-type: "- ";
}
.reveal .slides p {
@ -64,21 +69,166 @@
<section id="title-slide" data-background-image="./assets/logo.png" data-background-opacity="0.3" data-background-size="contain">
<h1 class="title">Cardano Lightning</h1>
<p class="subtitle">xxx</p>
<p class="subtitle">Permissionless, near instant, highly scalable</p>
</section>
<section>
<section id="the-problem" class="title-slide slide level2">
<h2>The Problem</h2>
<section id="problem" class="title-slide slide level2">
<h2>Problem</h2>
</section>
<section id="payment-system" class="slide level3">
<h3>Payment system</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>Users want secure, fast, low cost transactions</p>
</blockquote>
<p>However participants have different priorities, <em>eg</em></p>
<ul>
<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="existing-systems-12" class="slide level3">
<h3>Existing systems (1/2)</h3>
<ul>
<li>Cash: Permissionless, instant, scalable-ish (lots of people can use
it at the same time, but only to pay people near them), questionable
security (fraud happens).</li>
<li>Bank transfer: Permissioned, some instant others very slow,
scalable.</li>
<li>Contactless/ Card: Permissioned, near instant, scalable</li>
</ul>
</section>
<section id="section" class="slide level3">
<h3>… (2/2)</h3>
<ul>
<li>Decentralised Ledger *: permissionless, maybe fast or scalable but
generally not both.</li>
</ul>
<p><span style="font-size: small"> * There are many different designs of
decentralised ledger, each with different choices and trade-offs. Some
permissioned, some more decentralised than others, some faster,
<em>etc</em>. </span></p>
</section>
<section id="market-size" class="slide level3">
<h3>Market size</h3>
<ul>
<li><p>Contactless transactions will reach $11 trillion by 2027 <span
style="font-size: small"> source : Juniper Research </span></p></li>
<li><p>Market Cap for crypto : &gt; $3 trillion <span
style="font-size: small"> source : coinmarketcap.com (Dec 2024)
</span></p></li>
</ul>
</section>
<section id="intersection" class="slide level3">
<h3>Intersection</h3>
<blockquote>
<p>Can we have contactless like experience but permissionless.</p>
</blockquote>
</section>
<section id="problem-statement" class="slide level3">
<h3>Problem statement</h3>
<p>We want a payment system that is:</p>
<ol type="1">
<li>Permissionless</li>
<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 isnt 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="solution" class="title-slide slide level2">
<h2>Solution</h2>
</section>
<section id="cardano-lightning" class="slide level3">
<h3>Cardano Lightning</h3>
</section>
<section id="design" class="slide level3">
<h3>Design</h3>
<ul>
<li>A perturbation on BLN: its a Lightning Network</li>
<li>Focused on addressing the key technical blockers to it being used as
a day-to-day payment system.</li>
</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. Theres 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>Cardanos 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="team" class="title-slide slide level2">
<h2>Team</h2>
</section>
<section id="section-1" class="slide level3">
<h3></h3>
<ul>
<li><span class="citation" data-cites="waalge">@waalge</span></li>
<li><span class="citation" data-cites="paluh">@paluh</span></li>
<li><span class="citation" data-cites="nhenin">@nhenin</span></li>
</ul>
</section></section>
</div>
</div>

View File

@ -1,18 +1,23 @@
<style>
.reveal, .reveal h1, .reveal h2, .reveal h3, .reveal h4, .reveal h5, .reveal h6
body {
font-family: ui-sans-serif;
}
.reveal h1, .reveal h2, .reveal h3, .reveal h4, .reveal h5, .reveal h6
{
font-family:"jetbrains-mono", "Times New Roman", Times;
font-family:"TruenoSemiBold", "ui-sans-serif";
}
@font-face{
font-family:jetbrains-mono;src:local("TruenoSemiBold"),
font-family:"TruenoSemiBold";
src:local("TruenoSemiBold"),
url("./fonts/TruenoSemiBold.woff2") format("woff2");
font-weight: 600;
}
.black h2 {
background-color: #020210;
}
.reveal ul {
list-style-type: " ";
list-style-type: "- ";
}
.reveal .slides p {

View File

@ -12,71 +12,80 @@ background-image: ./assets/background.svg
background-opacity: "0.35"
---
## The Problem
## Problem
### Payments
A fundamental part of commerce: payment.
There are three parties
- A fundamental part of all commerce: payment.
### Who?
There are three parties involved in a payment
- Consumer (ie payer)
- Provider (ie payee)
- Facilitator
These types of users require different functionality.
All of us are consumers, some are providers, a few are facilitators.
Important features:
### What users want
- Security
- Speed
- Cost
> Users want secure, fast, low cost transactions
> People want secure, fast, low cost transactions
However participants have different priorities, _eg_
### Existing systems
- Consumers want ease-of-use
- Providers want fast confirmation
- Facilitators need to handle at scale
### 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
### ... (2/2)
- Decentralised Ledger \*: permissionless, maybe fast or scalable but generally not both.
\* : There are many different designs of decentralised ledger,
<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>
### Market size
Near instant payments
> Contactless transactions will reach $11 trillion by 2027
- Contactless transactions will reach $11 trillion by 2027 <span style="font-size: small"> source : Juniper Research </span>
source : Juniper Research
- Market Cap for crypto : > $3 trillion <span style="font-size: small"> source : coinmarketcap.com (Dec 2024) </span>
Permissionless systems:
### Intersection
> Market Cap for crypto : > $3 trillion
> Can we have contactless like experience but permissionless.
source : coinmarketcap.com (Dec 2024)
### Problem statement
### Permissionless Payment system
We want a payment system that is:
Can we have contactless like experience but Permissionless?
1. Secure Permissionless
1. Permissionless and secure
2. Near instant
3. Highly scalable
### Nearest solution: Bitcoin Lightning
### Bitcoin Lightning Network?
Closest to meeting the aims. In a lightning network:
In a lightning network:
- The network is fundamentally a set of channels, not a shared ledger.
- There is no need to reach consensus, or globally broadcasting state.
- Payments are routed across channels by participants.
- Speed of payment isn't a global property, but a more local one.
### BLN problems
BLN does this and is the closest to meeting our aims.
### Problems with BLN
However it has some issues:
@ -85,7 +94,9 @@ However it has some issues:
Liquidity is required to enable payments to be routed across a network.
Moving capital between channels requires multiple transactions.
## The Solution: Cardano Lightning
## Solution
### Cardano Lightning
### Design
@ -95,12 +106,19 @@ to it being used as a day-to-day payment system.
### Tailored Nodes
CL recognises a diversity in user needs.
CL recognises a diversity users have a diversity of needs.
- Consumers want a super lightweight node, minimal resources, runs on their phone.
- Some businesses might be happy running their own servers, others wont.
The do need to integrate payments into their existing business operations.
- Those with capital and wanting to put it to use can setup as network routers.
- 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.
### Leveraging Cardano
- Cardano's more powerful scripting language allows
us to achieve more with less. In particular we can optimize capital allocation for nodes.
- 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.
## Team

View File

@ -4,6 +4,6 @@
url('./fonts/TruenoSemiBold.woff2') format('woff2'),
url('./fonts/TruenoSemiBold.woff') format('woff'),
url('./fonts/TruenoSemiBold.ttf') format('ttf');
font-weight: 400;
font-weight: 100;
font-style: normal;
}