Ecosyste.ms: Awesome
An open API service indexing awesome lists of open source software.
https://github.com/nervosnetwork/ckb-simple-account-layer
An account layer implementation for Nervos CKB
https://github.com/nervosnetwork/ckb-simple-account-layer
Last synced: 4 days ago
JSON representation
An account layer implementation for Nervos CKB
- Host: GitHub
- URL: https://github.com/nervosnetwork/ckb-simple-account-layer
- Owner: nervosnetwork
- License: mit
- Archived: true
- Created: 2020-04-24T08:48:37.000Z (over 4 years ago)
- Default Branch: develop
- Last Pushed: 2021-08-12T08:40:39.000Z (over 3 years ago)
- Last Synced: 2024-04-14T04:07:49.362Z (7 months ago)
- Language: C
- Homepage:
- Size: 329 KB
- Stars: 8
- Watchers: 11
- Forks: 3
- Open Issues: 8
-
Metadata Files:
- Readme: README.md
- License: COPYING
Awesome Lists containing this project
- awesome-nervos-ckb - CKB Simple Account Layer
README
# ckb-simple-account-layer
**NOTE**: this repository is now only for legacy purposes, we have put together a more complete and secure design as a [Sparse Merkle Tree](https://github.com/nervosnetwork/sparse-merkle-tree) data structure. Please use the SMT implementation for all future projects.
A CKB account layer solution. This project consists of 3 parts:
* Minimal single header C parts for integrating an existing VM(whether it's JavaScript VM, Forth VM, EVM, Move VM, etc.) with an account based design. We are providing C source file since we are only defining a minimal integration layer, in this case, a C implementation provides maximum interoperability. Your VM can be written in any language supported by RISC-V, such as Rust.
* A Rust generator crate for interacting with the account layer on CKB, including querying account state, running VM programs to generate transactions containing latest state changes, etc.
* A nodejs binding on the Rust crate to provide the same functionality to JavaScript/TypeScript. We do have plan to deeply integrate ckb-simple-account-layer with [lumos](https://github.com/nervosnetwork/lumos).To save on-chain storage requirement, currently we use a [SMT](https://github.com/jjyr/sparse-merkle-tree) based design: only the state root hash is stored in a cell on CKB. The current state values will be calculated and managed off-chain. Since all the validation logic will be executed on-chain, everyone can then verify current state values calculated from the series of transactions on chain. We are not jeopardizing the security of such a design in the decentralized manner.
One novelty of this account layer, is that it only requires the developers to provide a VM implementation running on RISC-V. The generator part also executes the same VM via a customized CKB VM instance to generate updates. This way we are minimizing the efforts taken to build an account layer on CKB.