![]() |
||
---|---|---|
app | ||
migrations | ||
src | ||
.envrc | ||
.gitignore | ||
.pre-commit-config.yaml | ||
Cargo.lock | ||
Cargo.toml | ||
README.md | ||
flake.lock | ||
flake.nix | ||
rust-toolchain.toml |
README.md
CL L2 V0
This repo is a sandbox for the Cardano Lightning's L2 (V0).
A key aim of this repo is to try and assess available libraries in order to establish our key dependencies.
Setup
This repo use nix flakes with a shell available. Otherwise ymmv.
Context
CL depends on the use on signing/verification key pair cryptography. The signing key may be used to handover all the participants funds. The signing key must be handled with care.
A router node must run their infrastructure on highly available machines, in order to provide good service to their partners. The router might choose to use an infrastructure provider to host their nodes. The router must produce the signatures for cheques and snapshots in the course of standard channel operations. A priori the machine will contain signing keys. What if the machine is compromised?
An attacker with access to the machine could send all funds to the partner of the channel, or produce a tx that a partner signs, making it a valid mutual tx. In either case, they are at the detriment of the router.
Instead, we may outsource the signing process to a separate machine - the signing server. This sever can:
- serve requests to only whitelisted requesters. It can be more easily protected from ddos type attacks and probing by an attacker.
- has minimal, relatively fixed, API. It will receive fewer updates each of which can be reviewed more thoroughly, and have shorter/tighter software supply chains, than might be true for the general service on the HA machine.
In addition, the signing service could be split using, say, FROST.
Design
Data
Persistent keys
These are the signing keys available to the machine and found at startup of the service.
Ephemeral keys
Perhaps also called proxy keys.
An ephemeral key consists of the following properties:
- Verification key
- Persistent key
- Expires at
- Signature
Signing Server Actions
Add
An add is performed by "admin" to create new ephemeral keys.
An add
request has the following fields
- Verification key
- Persistent key
- Expires at
- Signature
The request is deemed valid
- The persistent key is in the database
- The signature is valid wrt the persistent key, and the payload created by
(verification_key, expires_at)
(with some prefix?)
The result of a valid add
request is the ephemeral key is added to the
database with the obvious fields.
The response is either Ok()
or Error("help message!")
Sign
A sign action is the "standard" action that will occur.
A sign
request has the following fields
- Verification key
- Payload
- Signature
The request is deemed valid
- The verification key exists in the database
- The verification key has not expired
- The signature is valid wrt the payload and verification key
- The payload is "sensible" (TBC) - this is context specific.
The response to a valid request
- The signature produced by the persistent key associated to the verification key for the same payload.
Revoke
A revoke is the opposite of add. It is also performed exclusively by admin.
An revoke
request has the following fields
- Verification key
- Signature
The request is deemed valid
- The verification key is in the database
- The signature is valid wrt the associated persistent key, and the payload
created by
verification_key
(with some prefix?)
The result of a valid revoke
request is the ephemeral key is removed from the
database.
The response is either Ok()
or Error("help message!")
SIMPLIFICATION
The add
and revoke
endpoints are needed only by admin, and infrequently, or
in case of emergency. In contrast, sign
is needed with relatively high
frequency, and called by less trusted machines.
Thus, we assume that admin accesses the machine directly and simply adds the ephemeral keys to the db. This does not require a valid signature - if the pub key is registered, then a signature request is honored.
Client server actions
Demo task
Some way to trigger the client service to make a request to the server.
Notes
sqlx
The sqlx tool has a cli (available via the flake). This can handle migrations provided its opinionated design choices are adopted. See here.
export DATABASE_URL=sqlite:./db/cll2v0.db
sqlx database create
sqlx migration run
The database must be initialised before starting the application.
libp2p
TODO