stateless-blockchain - GitLite

KO | EN

gitlite — search

#javascript #hacktoberfest #llm #go #machine-learning #deep-learning #macos #windows #awesome #awesome-list #security #pytorch #mcp #open-source

stateless-blockchain

(★ 64)

Stateless Blockchain on Substrate using RSA Accumulators

파일 탐색기

최종 버전 다운로드 (.zip)

- - lib.rs
  - proofs.rs
  - subroutines.rs
  - witnesses.rs
- Cargo.toml
- - lib.rs
- Cargo.lock
- Cargo.toml
- - config.yml
- - favicon.ico
  - index.html
  - manifest.json
  - Substrate-Logo.png
- - Accounts.js
  - AccountSelector.js
  - App.js
  - Events.js
  - index.js
  - Mint.js
  - State.js
  - Transaction.js
  - Witness.js
- .env
- config-overrides.js
- LICENSE
- package-lock.json
- package.json
- README.md
- yarn-error.log
- yarn.lock
- - lib.rs
  - stateless.rs
- build.rs
- Cargo.toml
- init.sh
- chain_spec.rs
- cli.rs
- main.rs
- service.rs
- - binary.rs
  - lib.rs
  - vc.rs
- Cargo.lock
- Cargo.toml
.gitignore
build.rs
Cargo.lock
Cargo.toml
LICENSE
README.md
substrate-node-rename.sh

# 설치 가이드

1. 코드 내려받기

git clone https://github.com/paritytech/stateless-blockchain

깃허브에서 프로젝트 코드 전체를 내 컴퓨터로 내려받습니다.

cd stateless-blockchain

방금 내려받은 프로젝트 폴더 안으로 이동합니다.

2. Node.js

쉬움 추천

사전 준비물

Git GitHub에서 프로젝트 코드를 내려받으려면 필요합니다.
Node.js npm 명령어를 쓰려면 Node.js가 설치되어 있어야 합니다. LTS(장기지원) 버전을 추천합니다.

cd client

이 프로젝트의 관련 파일이 하위 폴더 안에 있어서, 먼저 그 폴더로 이동합니다.

npm install

package.json에 명시된 라이브러리들을 내려받아 설치합니다.

npm start

개발/실행 서버를 켭니다.

✅ 명령어 실행 후 터미널에 나타나는 주소(보통 http://localhost:3000 형태)를 브라우저에서 열어보세요.

3. Rust

보통

사전 준비물

Git GitHub에서 프로젝트 코드를 내려받으려면 필요합니다.
Rust (rustup) rustup으로 설치하면 cargo도 함께 설치됩니다.

cargo build --release

Rust 프로젝트를 컴파일합니다.

cargo run

빌드 후 바로 실행까지 진행합니다.

✅ cargo build가 에러 없이 끝나면 성공입니다. target/ 폴더에 실행 파일이 생성됩니다.

// repository documentation

Was this content helpful?

★ 0 (0 ratings)

# Stateless Blockchain Experiment

## Disclaimer
This repository is purely experimental and is not production quality. The design choices made in this project
are impractical from both a security and usability standpoint. Additionally, the following code has not been checked for
correctness, style, or efficiency.

## Testing the Project

In the root directory:

* To build the project, run `cargo build --release`
* To start the chain, run `./target/release/stateless-blockchain --dev --execution-block-construction=Native`
* If you need to reset the chain, run `./target/release/stateless-blockchain purge-chain --dev`
* If you would like to execute tests, run `cargo test -p stateless-blockchain-runtime --release`

In the accumulator-client directory (you must use nightly Rust):

* Install `wasm-pack` if you don't already have it `cargo install wasm-pack`
* Run `wasm-pack build` to compile the crate to WASM.
* Inside "pkg", run `npm link`

In the client directory:

* Run `npm install` to install all necessary dependencies.
* Run `npm link accumulator-client` to link to the generated WASM files.
* Run `yarn start` to start a local server on localhost:8000.

## Overview and Background
This project implements a UTXO-based stateless blockchain on Substrate using an RSA accumulator. A cryptographic accumulator is
a short commitment to a set that includes small witnesses(a Merkle Tree is a type of accumulator). However, compared
to Merkle Trees, accumulators have constant size inclusion proofs, can efficiently add and delete(dynamic), and can support
both membership and non-membership proofs(universal). These features make accumulators a suitable fit for the stateless
validation model.

In this scheme, validating parties only need to track a single dynamic accumulator that represents a commitment to
the state instead of actually having to store the entire state(such as the UTXO set in Bitcoin). Similarly, users only need to
store their own UTXOs and membership proofs. However, since users must constantly watch for updates to the accumulator
in order to update their proofs, a data service provider who handles witnesses on behalf of users is likely to be used in
practice. This particular implementation includes batching and aggregation techniques from this paper:
https://eprint.iacr.org/2018/1188.pdf.

## Details

### Setup
The accumulator can be instantiated with a group of unknown order such as an RSA group. Any RSA number up to RSA-2048
is supported(see the "accumulator" crate root). Accumulators can be instantiated with no trusted setup using class groups
but remain mostly a research topic at the moment.

### Mechanics
The workflow of a stateless blockchain is as follows:

1. A mechanism like Proof-of-Work or some other minting mechanism can be used to add new coins to the accumulator.
2. To spend a coin, users construct transactions that include their UTXO, the membership witness for that UTXO, and a
valid transaction output.
3. At the finalization of a block, the miner/validator aggregates all of the inclusion proofs from the spent UTXOs and
uses it to batch delete them from the accumulator. Similarly, the miner/validator batch adds the newly created UTXOs
to the accumulator. At each step, the miner/validator outputs a proof of correctness that the deletion/addition was
executed correctly.

### Structure
The base of this project is a simple Substrate runtime. However, the core accumulator logic is stored in the "accumulator"
crate and includes all of the integer specific functions, succinct proofs of exponentiation, and functions for creating
or updating membership witnesses.

The front-end for this project is stored in the "client" directory and implements a simple React page based on the
Substrate Front-End template.

"accumulator-client" is a wrapper crate for "accumulator" that uses wasm-bindgen to export several accumulator
functions to WASM. This is necessary so that the front-end can interact with the accumulator.

## Limitations

Since this is an experimental project, there exists numerous limitations.

* Instead of using a Proof-of-Work module, this runtime allows users to trivially mint new coins.
* The "UTXOs" that are created more closely resemble non-fungible tokens and are not explicitly value bearing(only contain
identifier and owner).
* Users can only submit one transaction per block and each transaction is limited to one input and one output.
* Instead of aggregating inclusion proofs in memory, the "blockchain" must temporarily write the details of each incoming
transaction to storage (but are erased at the end of the block). This is currently the only viable method for processing
incoming extrinsics without modifying Substrate itself.
* The scheme does not verify any signatures. Signatures could be aggregated within a block using BLS signatures.

##  Miscellaneous

The primary computational bottleneck occurs when a UTXO is hashed to a prime representation. Although this implementation
uses a deterministic variant of the Miller-Rabin primality test that is "efficient", since we have used a small
lambda value for testing, it can still be a limiting factor. Page 24 of https://eprint.iacr.org/2018/1188.pdf presents
a modification to the inclusion proofs such that the verifier only needs to perform one round of primality checking
instead of rederiving the hash representation(which involves about log(lambda) rounds). If transactions are taking too
long to process, the block time can be modified by changing "MinimumPeriod" in the crate root of the runtime.

With regard to semantics, it is important to note that this implementation is not *actually* a stateless blockchain since
the runtime still utilizes the underlying storage trie of Substrate as well as multiple SRML components. However, the
storage requirements are still fairly minimal.

## Vector Commitments

The directory titled "vector-commitment" is a crate that implements both binary and general vector commitments using
the RSA accumulator. A vector commitment is a primitive that allows for the commitment of an ordered list of elements
where elements can only be opened at their corresponding indices(position binding). Particularly, one can use a vector
commitment to commit to a binary vector by mapping the indices of elements that are 1 to primes and then batch adding
them to an accumulator. A subset of those indices can be opened with constant sized openings by utilizing the batching
functionality from the accumulator. This scheme can be further generalized to accumulate a key-value store using a large
sparse vector and finally used to build an account-based stateless blockchain.

## Future Work

Here is a non-comprehensive list of potential future steps.

* Implementing more complex UTXO logic.
* Integrating a Proof-of-Work module.
* Creating a UX friendly front-end.
* Creating a data service provider.
* Investigating class groups.
* Signature aggregation.
* Explore accumulator unions and multiset accumulators.
* Creating an account-based stateless blockchain runtime.

## Reading List

* https://eprint.iacr.org/2018/1188.pdf
* https://www.zeroknowledge.fm/88
* https://blog.goodaudience.com/deep-dive-on-rsa-accumulators-230bc84144d9
* http://diyhpl.us/wiki/transcripts/stanford-blockchain-conference/2019/accumulators/
* https://scalingbitcoin.org/transcript/tokyo2018/accumulators
* https://ethresear.ch/t/accumulators-scalability-of-utxo-blockchains-and-data-availability/176
* https://www.youtube.com/watch?v=tqqsbsAHJzs
* https://ethresear.ch/t/rsa-accumulators-for-plasma-cash-history-reduction/3739
* https://crypto.stackexchange.com/questions/66396/cryptographic-accumulators-accumulator-size-vs-max-number-of-set-members

Note: This repository will no longer be maintained by its original owner after November 2019.