open-transaction-pool's Introduction

CKB Open Transaction Pool

About CKB Open Transaction

CKB Open Transaction (OTX) is an extensible transaction format and workflow engine that supports the combination of multiple partial signed OTXs or multi-signed OTXs off-chain to construct a CKB transaction.

Compared to the CKB Transaction format described in the RFC 0022-transaction-structure, OTX can carry more auxiliary information to describe how it can be aggregated into a complete CKB transaction.

This project is an extensible OTX solution based on memory pools. We have developed several user cases in different application scenarios to make the solution reusable and versatile, which facilitates the secondary development of dApps.

Design Philosophy

We believe that the optimal architecture involves processing OTXs as a data stream. This architecture utilizes a Broker to collect OTXs and dispatch them to Agents.

An Agent serves as both a Consumer and a Producer. It receives OTXs from the Broker, executes its logic, and notifies the Broker of its processing result.

This project is an implementation of this design concept. It uses the memory pool as the Broker and plugins as Agents to expand its application business logic.

Open Transaction Lock Script

Open transactions require support from a corresponding lock script, which should follow the RFC: Composable Open Transaction Lock Script. The locking script that adheres to this RFC can support the partial signing of transactions, providing great convenience for subsequent aggregation and reducing the cost of interaction.

The lock script used in this project is provided by the Omni lock script. We have also utilized the CKB SDK, which has started to support this lock script.

Documentation

Quick Start
RPC Documentation
Projects Layout
Pool and Plugin
Scenario Application Pattern
- Payment
- Swap

Integration Test

The integration-tests sub-project provides various scenarios for applying OTX, which helps in understanding the project.

The integration-tests README outlines how to build a local development environment.

Existing scenario application cases include:

Payment: Dust Collector
Swap: Atomic Swap
... more will be added later

Thank you for your contribution to the open-source community!

open-transaction-pool's People

Contributors

Stargazers

Watchers

open-transaction-pool's Issues

There's no document for the otx format specification used in the new swap builtin plugin

Refactor the code to make it easy to add plugins

Re-organize the code so it's easy to implement a plugin in its own crate. Take care of the dependencies between crates. Also create a template for the pool extension crate. Now adding a plugin requires a lot of boilerplate code.

Make it easy to add plugins in Rust. For example, add an Service struct, that we can use it to start the service in our own src/main.rs:

import otx_service;

fn main() {
    let mut service = OtxService::new();
    service.add_plugin(MyPlugin::new());
    
    service.run();
}

Publish crates

Use uniform prefix for all crates
Ensure there's no conflict
Refer to the script to publish crates in ckb

ethanyuan / open-transaction-pool Goto Github PK

open-transaction-pool's Introduction

CKB Open Transaction Pool

About CKB Open Transaction

Design Philosophy

Open Transaction Lock Script

Documentation

Integration Test

open-transaction-pool's People

Contributors

Stargazers

Watchers

Forkers

open-transaction-pool's Issues

There's no document for the otx format specification used in the new swap builtin plugin

Refactor the code to make it easy to add plugins

Publish crates

Let JSONRPC serializes Open Transaction into JSON

Recommend Projects

React

Vue.js

Typescript

TensorFlow

Django

Laravel

D3

Recommend Topics

javascript

web

server

Machine learning

Visualization

Game

Recommend Org

Facebook

Microsoft

Google

Alibaba

D3

Tencent