ergoplatform / ergoplatform/ergo-appkit

SPV workflow for verifying a payment with NiPoPoW

Open
#187 0 comments 2 reactions 0 assignees View on GitHub
Dominant language
Java
Stars
44
Forks
34
PR merge metrics
No merged PRs in 30d

Description

# SPV workflow for verifying a payment with NiPoPoW

Created from ergo-lib [#495](https://github.com/ergoplatform/sigma-rust/issues/495)

Using NiPoPoW described in [KMZ17](https://fc20.ifca.ai/preproceedings/74.pdf)

## Goal
Prove that a payment (ERG and/or tokens) was made on the blockchain.

**EDIT: For a recent payment it would be faster to use UTXO proof described in [#502](https://github.com/ergoplatform/sigma-rust/issues/502)**

## Step 1. Prove that a tx with a given id in a block with a given id exists in the blockchain.

### Step 1.1. Prove that a block with a given id exists in the blockchain.

- 1.1.1. Ask proofs from known nodes via [`/nipopow/proof/{m}/{k}/{headerId}`](https://github.com/ergoplatform/ergo/blob/66ae8ad214e0f56bd8ad39bda0c752fe5a3354a4/src/main/resources/api/openapi.yaml#L2731).

- 1.1.2. Feed all received proofs into [`NipopowVerifier.process()`]( https://github.com/ergoplatform/ergo/blob/66ae8ad214e0f56bd8ad39bda0c752fe5a3354a4/src/main/scala/org/ergoplatform/local/NipopowVerifier.scala#L13-L27).

- 1.1.3. Check that `verifier.bestProof.suffixHead.id` is our block id;

### Step 1.2. Prove that a tx with a given id exists in the blockchain.

- 1.2.1. Ask any node for [`MerkleProof`](https://github.com/input-output-hk/scrypto/blob/88fc0ee4e1eecf3d63e5986487b243b3548bb707/src/main/scala/scorex/crypto/authds/merkle/MerkleProof.scala#L25-L26) via [`/blocks/{headerId}/proofFor/{txId}`](https://github.com/ergoplatform/ergo/blob/66ae8ad214e0f56bd8ad39bda0c752fe5a3354a4/src/main/resources/api/openapi.yaml#L2539-L2570);

- 1.2.2. Confirm the tx id is in the block with [`merkleProof.valid(header.transactionsRoot)`](https://github.com/input-output-hk/scrypto/blob/2237785131ee0946e44d6a5aec2ef0fc0731efce/src/main/scala/scorex/crypto/authds/merkle/MerkleProof.scala#L28-L38);

See Step 1.1 in ergo-lib example [workflow](https://github.com/ergoplatform/sigma-rust/blob/96952de25a34170ba9fea9b1fe533d284dd857e0/bindings/ergo-lib-wasm/tests_browser/test_rest_api.js#L49-L77)

## Step 2. Check the box with the payment

### Step 2.1 Get the whole tx for tx id from Step 1
It can either be provided along with the tx id in Step 1 or fetched from the node. It is verified by serializing the tx and calculating its id and then comparing it to the tx id confirmed in Step 1.2.

### Step 2.2. Confirm the payment is in this tx
Find the output box protected with a certain script (e.g certain PK) and check that its value and/or tokens are as expected.

# Implement the missing parts in appkit:
- REST API calls support mentioned above;
- move `NipopowProof`, `NipopowVerifier`, and all dependent types from node code into a lib ~~(ergo-wallet?)~~ https://github.com/ergoplatform/ergo/issues/1965
- expose `NipopowProof`, `NipopowVerifier`, `MerkleProof` with mentioned above properties/methods in appkit public API.

EDIT: Actually, I'm pretty sure that the above NiPoPoW-related types would better be in a dedicated ergo-nipopow lib since they are not directly related to wallet features. However, the bigger challenge will be the dependent more low-level types like `Header`, etc. Seems like they should be moved to their own separate lib (ergo-core/ergo-chain-types?).

Contributor guide

No contributing guide indexed for this repository

Research direction

Start with the REST endpoints `/nipopow/proof/{m}/{k}/{headerId}` and `/blocks/{headerId}/proofFor/{txId}`, then review `NipopowVerifier.process()` and `MerkleProof.valid(...)` referenced in the issue. Done would require REST API support and public appkit exposure for `NipopowProof`, `NipopowVerifier`, and `MerkleProof`, while the proposed library boundaries and dependent types still need resolution.

Written by the indexing model from the issue text.

Assessment

Tech stack
java, kotlin, scala
Domain
api, blockchain
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.