Skip to content

AbdelStark/askeladd

Repository files navigation

Askeladd

Censorship-resistant global proving network.

GitHub Workflow Status (with event)

Bitcoin Nostr Bitcoin Lightning Rust

About

Askeladd is a censorship-resistant global proving network, for anyone to be able to generate validity proofs, using STWO prover, and verify them. It enables to submit proving request to the network and retrieve the generated proof for any given request. Askeladd leverages Nostr for the communication layer, to gossip the proving requests and generated proofs, following the NIP-90 - Data Vending Machine specification.

Disclaimer: Askeladd is only a proof of concept and should not be used in a production environment. It's a work in progress as a showcase of the STWO prover and the Nostr protocol.

Check out this video demonstration of Askeladd in action:

asciicast

Architecture

graph LR
    Customer((DVM Customer))
    SP[DVM Service Provider]
    Nostr[Nostr Network]
    STWO_P[STWO Prover]
    STWO_V[STWO Verifier]

    Customer -->|1. Submit Proving Request<br>Kind: 5600| Nostr
    Nostr -->|2. Fetch Request| SP
    SP -->|3. Generate Proof| STWO_P
    SP -->|4. Publish Proof<br>Kind: 6600| Nostr
    Nostr -->|5. Fetch Proof| Customer
    Customer -->|6. Verify Proof| STWO_V

    classDef customer fill:#f9d71c,stroke:#333,stroke-width:2px;
    classDef provider fill:#66b3ff,stroke:#333,stroke-width:2px;
    classDef network fill:#333,stroke:#333,stroke-width:2px,color:#fff;
    classDef prover fill:#ff9999,stroke:#333,stroke-width:2px;
    classDef verifier fill:#b19cd9,stroke:#333,stroke-width:2px;

    class Customer customer;
    class SP provider;
    class Nostr network;
    class STWO_P prover;
    class STWO_V verifier;
Loading

Typical flow:

  1. User submits a proving request to the network (DVM Job Kind 5600)
  2. A DVM Service Provider picks the request and generates a proof using the STWO prover.
  3. The proof is published to the Nostr network (DVM Job Result Kind 6600).
  4. The DVM Customer can verify the proof using the STWO verifier.

Running the demo

Using docker-compose

./scripts/demo_docker_compose_local_relayer.sh

Manually

Create a .env file, you can use the .env.example file as a reference.

cp .env.example .env

# Set the relay URL in the .env file

# Using a local relay
APP_SUBSCRIBED_RELAYS=ws://localhost:8080

# Or a public relay
APP_SUBSCRIBED_RELAYS=wss://relay.nostr.net

(Optional, if you want to run a local nostr relay) In a terminal, run the local nostr relay:

docker run -p 8080:8080 scsibug/nostr-rs-relay

In a terminal, run the prover agent:

cargo run --bin dvm_service_provider

In a terminal, run the user CLI:

cargo run --bin dvm_customer

The user CLI binary will submit a proving request to the Nostr network. The prover agent will generate a proof for the request and publish it to the Nostr network. The user CLI binary will be able to verify the proof.

Askeladd DVM Marketplace

See the Askeladd DVM Marketplace for more information.

This requires to build the STWO WASM bindings and to copy the generated artifacts.

Go to crates/stwo_wasm and run wasm-pack build --target web to build the STWO WASM bindings.

Then copy the generated pkg directory to askeladd-dvm-marketplace/src/.

🀝 Contributing

We love contributions! If you have ideas for improvements or find any issues, please open an issue or submit a pull request.

πŸ“œ License

This project is licensed under the MIT License - see the LICENSE file for details.

πŸ™ Acknowledgements

This demo is powered by the amazing STWO Prover from StarkWare. A big thank you to the StarkWare team and all contributors!

πŸ“š Resources