Resdb Fastmcp
No description available
Ask AI about Resdb Fastmcp
Powered by Claude Β· Grounded in docs
I know everything about Resdb Fastmcp. Ask me about installation, configuration, usage, or troubleshooting.
0/500
Reviews
Documentation
ResilientDB: Global-Scale Sustainable Blockchain Fabric
ResilientDB is a High Throughput Yielding Permissioned Blockchain Fabric founded by ExpoLab at UC Davis in 2018. ResilientDB advocates a system-centric design by adopting a multi-threaded architecture that encompasses deep pipelines. Further, ResilientDB separates the ordering of client transactions from their execution, which allows it to process messages out-of-order.
Downloads:
Download address for run-directly software package: https://downloads.apache.org/incubator/resilientdb/
Quick Facts on ResilientDB
- ResilientDB orders client transactions through a highly optimized implementation of the PBFT [Castro and Liskov, 1998] protocol, which helps to achieve consensus among its replicas. ResilientDB also supports deploying other state-of-the-art consensus protocols [release are planned] such as GeoBFT [blog, released], PoE, RCC, RingBFT, PoC, SpotLess, HotStuff, and DAG.
- ResilientDB requires deploying at least 3f+1 replicas, where f (f > 0) is the maximum number of arbitrary (or malicious) replicas.
- ResilientDB supports primary-backup architecture, which designates one of the replicas as the primary (replica with identifier 0). The primary replica initiates consensus on a client transaction, while backups agree to follow a non-malicious primary.
- ResilientDB exposes a wide range of interfaces such as a Key-Value store, Smart Contracts, UTXO, and Python SDK. Following are some of the decentralized applications (DApps) built on top of ResilientDB: NFT Marketplace and Debitable.
- To persist blockchain, chain state, and metadata, ResilientDB provides durability through LevelDB.
- ResilientDB provides access to a seamless GUI display for deployment and maintenance, and supports Grafana for plotting monitoring data.
- [Historial Facts] The ResilientDB project was founded by Mohammad Sadoghi along with his students (Suyash Gupta as the lead Architect, Sajjad Rahnama as the lead System Designer, and Jelle Hellings) at UC Davis in 2018 and was open-sourced in late 2019. On September 30, 2021, we released ResilientDB v-3.0. In 2022, ResilientDB was completely re-written and re-architected (Junchao Chen as the lead Architect, Dakai Kang as the lead Recovery Architect along with the entire NexRes Team), paving the way for a new sustainable foundation, referred to as NexRes (Next Generation ResilientDB). Thus, on September 30, 2022, NexRes-v1.0.0 was born, marking a new beginning for ResilientDB. On October 21, 2023, ResilientDB was officially accepted into Apache Incubation.
Online Documentation:
The latest ResilientDB documentation, including a programming guide, is available on our blog repository. This README file provides basic setup instructions.
Table of Contents
- Software Stack Architecture
- SDK Layer: Python SDK and Wallet - ResVault
- Interface Layer: Key-Value, Solidity Smart Contract, Unspent Transaction Output (UTXO) Model, ResilientDB Database Connectivity (RDBC) API
- Platform Layer: Consensus Manager Architecture (ordering, recovery, network, chain management)
- Execution Layer: Transaction Manager Design (Runtime)
- Chain Layer: Chain State & Storage Manager Design (durability)
- Installing & Deploying ResilientDB
- Build Your First Application: KV Service, UTXO
- Dashboard: Monitoring, Deployment, Data Pipeline
- System Parameters & Configuration
- Continuous Integration & Testing
OS Requirements
Ubuntu 20+
Project Structure
incubator-resilientdb/
βββ api/ # API layer and interfaces
βββ benchmark/ # Performance benchmarking tools
β βββ protocols/ # Protocol-specific benchmarks
β βββ pbft/ # PBFT protocol benchmarks
β βββ poe/ # PoE protocol benchmarks
βββ chain/ # Blockchain chain management
β βββ state/ # Chain state management
β βββ storage/ # Storage layer (LevelDB, etc.)
βββ common/ # Common utilities and libraries
β βββ crypto/ # Cryptographic functions
β βββ lru/ # LRU cache implementation
β βββ proto/ # Protocol buffer definitions
β βββ test/ # Testing utilities
β βββ utils/ # General utilities
βββ ecosystem/ # Ecosystem components (git subtrees)
β βββ cache/ # Caching implementations
β β βββ resilient-node-cache/ # Node.js caching
β β βββ resilient-python-cache/ # Python caching
β βββ deployment/ # Deployment and infrastructure
β β βββ ansible/ # Ansible playbooks
β β βββ orbit/ # Orbit deployment tool
β βββ graphql/ # GraphQL service
β βββ monitoring/ # Monitoring and observability
β β βββ reslens/ # ResLens monitoring tool
β β βββ reslens-middleware/ # ResLens middleware
β βββ sdk/ # Software Development Kits
β β βββ resdb-orm/ # Python ORM
β β βββ resvault-sdk/ # ResVault SDK
β β βββ rust-sdk/ # Rust SDK
β βββ smart-contract/ # Smart contract ecosystem
β β βββ rescontract/ # ResContract repository
β β βββ resilient-contract-kit/ # Contract development toolkit
β β βββ smart-contract-graphql/ # Smart contract GraphQL service
β βββ tools/ # Development and operational tools
β βββ create-resilient-app/ # App scaffolding tool
β βββ resvault/ # ResVault tool
βββ executor/ # Transaction execution engine
β βββ common/ # Common execution utilities
β βββ contract/ # Smart contract execution
β βββ kv/ # Key-value execution
β βββ utxo/ # UTXO execution
βββ interface/ # Client interfaces and APIs
β βββ common/ # Common interface utilities
β βββ contract/ # Smart contract interface
β βββ kv/ # Key-value interface
β βββ rdbc/ # ResilientDB Database Connectivity
β βββ utxo/ # UTXO interface
βββ monitoring/ # Core monitoring components
βββ platform/ # Core platform components
β βββ common/ # Common platform utilities
β βββ config/ # Configuration management
β βββ consensus/ # Consensus protocols
β β βββ checkpoint/ # Checkpoint management
β β βββ execution/ # Transaction execution
β β βββ ordering/ # Transaction ordering
β β βββ recovery/ # Recovery mechanisms
β βββ networkstrate/ # Network strategy layer
β βββ proto/ # Protocol definitions
β βββ rdbc/ # RDBC implementation
β βββ statistic/ # Statistics and metrics
βββ proto/ # Protocol buffer definitions
β βββ contract/ # Smart contract protos
β βββ kv/ # Key-value protos
β βββ utxo/ # UTXO protos
βββ scripts/ # Deployment and utility scripts
β βββ deploy/ # Deployment scripts
βββ service/ # Service implementations
β βββ contract/ # Smart contract service
β βββ kv/ # Key-value service
β βββ tools/ # Service tools
β βββ utils/ # Service utilities
β βββ utxo/ # UTXO service
βββ third_party/ # Third-party dependencies
βββ tools/ # Development and build tools
Note: The ecosystem/ directory contains git subtrees for ecosystem components. You can clone the repository without ecosystem components for a smaller, faster download. See ecosystem/README.md for details.
Build and Deploy ResilientDB
Next, we show how to quickly build ResilientDB and deploy 4 replicas and 1 client proxy on your local machine. The proxy acts as an interface for all the clients. It batches client requests and forwards these batches to the replica designated as the leader. The 4 replicas participate in the PBFT consensus to order and execute these batches. Post execution, they return the response to the leader.
Install dependencies:
./INSTALL.sh
For non-root users, see INSTALL/README.md
Run ResilientDB (Providing a Key-Value Service):
./service/tools/kv/server_tools/start_kv_service.sh
- This script starts 4 replicas and 1 client. Each replica instantiates a key-value store.
Build Interactive Tools:
bazel build service/tools/kv/api_tools/kv_service_tools
Issues
If you cannot build the project successfully, try to reduce the bazel jobs here.
Functions
ResilientDB supports two types of functions: version-based and non-version-based. Version-based functions will leverage versions to protect each update, versions must be obtained before updating a key.
Note: Version-based functions are not compatible with non-version-based functions. Do not use both in your applications.
We show the functions below and show how to use kv_service_tools to test the function.
Version-Based Functions
Get
Obtain the value of key with a specific version v.
kv_service_tools --config config_file --cmd get_with_version --key key --version v
| parameters | descriptions |
|---|---|
| config | the path of the client config which points to the db entrance |
| cmd | get_with_version |
| key | the key you want to obtain |
| version | the version you want to obtain. (If the v is 0, it will return the latest version |
Example:
bazel-bin/service/tools/kv/api_tools/kv_service_tools --config service/tools/config/interface/service.config --cmd get_with_version --key key1 --version 0
Results:
get key = key1, value = value: "v2" version: 2
Set
Set value to the key key based on version v.
kv_service_tools --config config_file --cmd set_with_version --key key --version v --value value
| parameters | descriptions |
|---|---|
| config | the path of the client config which points to the db entrance |
| cmd | set_with_version |
| key | the key you want to set |
| version | the version you have obtained. (If the version has been changed during the update, the transaction will be ignored) |
| value | the new value |
Example:
bazel-bin/service/tools/kv/api_tools/kv_service_tools --config service/tools/config/interface/service.config --cmd set_with_version --key key1 --version 0 --value v1
Results:
set key = key1, value = v3, version = 2 done, ret = 0
current value = value: "v3" version: 3
Get Key History
Obtain the update history of key key within the versions [v1, v2].
kv_service_tools --config config_file --cmd get_history --key key --min_version v1 --max_version v2
| parameters | descriptions |
|---|---|
| config | the path of the client config which points to the db entrance |
| cmd | get_history |
| key | the key you want to obtain |
| min_version | the minimum version you want to obtain |
| max_version | the maximum version you want to obtain |
Example:
bazel-bin/service/tools/kv/api_tools/kv_service_tools --config service/tools/config/interface/service.config --cmd get_history --key key1 --min_version 1 --max_version 2
Results:
get history key = key1, min version = 1, max version = 2
value =
item {
β key: "key1"
β value_info {
ββ value: "v1"
ββ version: 2
β}
}
item {
β key: "key1"
β value_info {
ββ value: "v0"
ββ version: 1
β}
}
Get Top
Obtain the recent top_number history of the key key.
kv_service_tools --config config_path --cmd get_top --key key --top top_number
| parameters | descriptions |
|---|---|
| config | the path of the client config which points to the db entrance |
| cmd | get_top |
| key | the key you want to obtain |
| top | the number of the recent updates |
Example:
bazel-bin/service/tools/kv/api_tools/kv_service_tools --config service/tools/config/interface/service.config --cmd get_top --key key1 --top 1
Results:
key = key1, top 1
value =
item {
βkey: "key1"
βvalue_info {
ββ value: "v2"
ββ version: 3
β}
}
Get Key Range
Obtain the values of the keys in the ranges [key1, key2]. Do not use this function in your practice code
kv_service_tools --config config_file --cmd get_key_range_with_version --min_key key1 --max_key key2
| parameters | descriptions |
|---|---|
| config | the path of the client config which points to the db entrance |
| cmd | get_key_range_with_version |
| min_key | the minimum key |
| max_key | the maximum key |
Example:
bazel-bin/service/tools/kv/api_tools/kv_service_tools --config service/tools/config/interface/service.config --cmd get_key_range_with_version --min_key key1 --max_key key3
Results:
min key = key1 max key = key2
getrange value =
item {
β key: "key1"
β value_info {
ββ value: "v0"
ββ version: 1
β }
}
item {
β key: "key2"
β value_info {
ββ value: "v1"
ββ version: 1
β }
}
Non-Version-Based Function
Set
Set value to the key key.
kv_service_tools --config config_file --cmd set --key key --value value
| parameters | descriptions |
|---|---|
| config | the path of the client config which points to the db entrance |
| cmd | set |
| key | the key you want to set |
| value | the new value |
Example:
bazel-bin/service/tools/kv/api_tools/kv_service_tools --config service/tools/config/interface/service.config --cmd set --key key1 --value value1
Results:
set key = key1, value = v1, done, ret = 0
Get
Obtain the value of key.
kv_service_tools --config config_file --cmd get --key key
| parameters | descriptions |
|---|---|
| config | the path of the client config which points to the db entrance |
| cmd | get |
| key | the key you want to obtain |
Example:
bazel-bin/service/tools/kv/api_tools/kv_service_tools --config service/tools/config/interface/service.config --cmd get --key key1
Results:
get key = key1, value = "v2"
Get Key Range
Obtain the values of the keys in the ranges [key1, key2]. Do not use this function in your practice code
kv_service_tools --config config_path --cmd get_key_range --min_key key1 --max_key key2
| parameters | descriptions |
|---|---|
| config | the path of the client config which points to the db entrance |
| cmd | get_key_range |
| min_key | the minimum key |
| max_key | the maximum key |
Example:
bazel-bin/service/tools/kv/api_tools/kv_service_tools --config service/tools/config/interface/service.config --cmd get_key_range --min_key key1 --max_key key3
Results:
getrange min key = key1, max key = key3
value = [v3,v2,v1]
Deployment Script
We also provide access to a deployment script that allows deployment on distinct machines.
Deploy via Docker
-
Install Docker
Before getting started, make sure you have Docker installed on your system. If you don't have Docker already, you can download and install it from the official Docker website. -
Pull the Latest ResilientDB Image
Choose the appropriate ResilientDB image for your machine's architecture:-
For amd architecture, run:
docker pull expolab/resdb:amd64 -
For Apple Silicon (M1/M2) architecture, run:
docker pull expolab/resdb:arm64
-
-
Run a Container with the Pulled Image
Launch a Docker container using the ResilientDB image you just pulled:-
For amd architecture, run:
docker run -d --name myserver expolab/resdb:amd64 -
For Apple Silicon (M1/M2) architecture, run:
docker run -d --name myserver expolab/resdb:arm64
-
-
Test with Set and Get Commands Exec into the running server:
docker exec -it myserver bash -
NOTE: If you encounter a Connection Refused error
Run the following command within the container:
./service/tools/kv/server_tools/start_kv_service.shVerify the functionality of the service by performing set and get operations provided above functions.
Custom Ports
When starting the service locally, current services are running on 10000 port-base with 5 services where the server config is located here
If you want to change the setting, you need to generate the certificates.
Go the the workspace where the resilientdb repo is localted.
Change the setting parameters here and run the script:
./service/tools/kv/server_tools/generate_config.sh
Then re-run the start script:
./service/tools/kv/server_tools/start_kv_service.sh
Smart Contract
If you want to use smart contracts, please go to: https://blog.resilientdb.com/2025/02/14/GettingStartedSmartContract.html
