Emitter positioning and design

[driftluo]

Position

The emitter is used to help the user synchronize the cell state on the ckb to the relayer, and after the relayer synchronizes the cell synchronized by the emitter to the axon, the axon can execute and verify the corresponding

Design

Listen to the state of cells in the ckb chain through the ckb full node and the built-in indexer, and update it to the relayer synchronously

Users Register and delete

The user registers the cell feature that needs attention in the emitter via filter, and the emitter will automatically listen to its changes

pub struct SearchKey {
    pub script: Script,
    pub script_type: ScriptType,
    pub filter: Option<SearchKeyFilter>,
}

pub struct SearchKeyFilter {
    pub script: Option<Script>,
    pub script_len_range: Option<[Uint64; 2]>,
    pub output_data_len_range: Option<[Uint64; 2]>,
    pub output_capacity_range: Option<[Uint64; 2]>,
}

// rpc interface

fn register(seachkey: SearchKey, start_number: blocknumber) -> bool

fn delete(seachkey: SearchKey) -> bool

SearchKey is similar to ckb-indexer, but with some unnecessary functions removed

Internal Status

Thanks to the ckb-indexer, Emitter itself only needs to record a relatively small amount of state:

struct state {
  indexer_tip: number and hash,
  keys_state: HashMap<searchkey, Arc<CellsState>>
}

struct CellState {
 scan_tip: number and hash,
 search_key,
}

The disk regularly retains this data and that's it. After the startup is loaded, each key has a separate Future to do its own task, independent of each other, and only needs to update its own state to the global after each processing and submission of a section of data, and periodically flush it to the disk, even without database support

The general process is as follows：

1. Scan cells’ transactions， Analyze them
2. Submit to relayer
3. Submit the key‘s scan tip
4. Timed flush of Scan status to disk