117 lines
3.3 KiB
Markdown
117 lines
3.3 KiB
Markdown
|
|
## Problem
|
|
|
|
### Payments
|
|
|
|
- A fundamental part of all commerce: payment.
|
|
|
|
<!--
|
|
A slightly trucated opening lines from the wikipedia page.
|
|
Whoever provided or endorsed this version clearly thinks this point is moot.
|
|
-->
|
|
|
|
### Who?
|
|
|
|
There are three parties involved in a payment
|
|
|
|
- Consumer (ie payer)
|
|
- Provider (ie payee)
|
|
- Facilitator
|
|
|
|
All of us are consumers, some are providers, a few are facilitators.
|
|
|
|
### What users want
|
|
|
|
> Users want secure, fast, low cost transactions
|
|
|
|
However participants have different priorities, _eg_
|
|
|
|
- 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.
|
|
|
|
<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
|
|
|
|
|
|
- Contactless transactions will reach $11 trillion by 2027 <span style="font-size: small"> source : Juniper Research </span>
|
|
|
|
- Market Cap for crypto : > $3 trillion <span style="font-size: small"> source : coinmarketcap.com (Dec 2024) </span>
|
|
|
|
### Intersection
|
|
|
|
> Can we have contactless like experience but permissionless.
|
|
|
|
### Problem statement
|
|
|
|
We want a payment system that is:
|
|
|
|
1. Permissionless and secure
|
|
2. Near instant
|
|
3. Highly scalable
|
|
|
|
### Bitcoin 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 does this and is the closest to meeting our aims.
|
|
|
|
### Problems with BLN
|
|
|
|
However it has some issues:
|
|
|
|
- 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.
|
|
|
|
## Solution
|
|
|
|
### Cardano Lightning
|
|
|
|
### Design
|
|
|
|
- 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.
|
|
|
|
### Tailored Nodes
|
|
|
|
CL recognises a diversity users have a diversity of needs.
|
|
|
|
- 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
|