dymensionxyz/dymint

Sequencing Engine for Dymension RollApps

dymint's Issues

Update dependabot reviewers list

Add blockBatchSize param to the config

Update stateIndex and syncTarget from SL events

Fix CONTRIBUTING.md link to point to dYmension labels

Create a makefile for common functionalities

add a manager method for submitting new batch to the DA

Fix unstable tests

Some tests are unstable. Some examples:

• p2p tests
• mempool tests

We should make sure all tests are stable and consistent.

block time configuration

We would like to be able to configure a block time and also support 0 block time where the blocks are produced in a loop without a ticker.

Raise panic when the connection between dymint and the SL refused (and we hit the retry limit)

Add a contrib dir and configure git prehook

Add a contrib dir with basic tools like git pre-commit hook for now

create a mock client for interacting with dymension settlement layer

Overview

Until our SL will be ready for testing will start by mocking it's basic functionality.

IMO we need to support the following functionality for the first iteration:

1. Getting batches and options to filter by:
   1. specific height
   2. height_gte
   3. no filter returns the latest batch for that ORU chain.
2. Write batch
3. Mechanism to emulate events published by the SL - for now newBatch event.

Find a cleaner way to integrate a cosmos client

Currently some validations are commented out in the cosmosclient.
We are using a hybrid cosmosclient of ignite and parts copied from the cosmos-sdk.
Ideally we would like to write a cleaner design.

Update design document to fit dYmension adjustments

Change da client to handle batch types as opposed to block types

Currently the DA layer assumes a block struct is given for saving and fetching.
We'll want to change it to handle the batch struct.

Fix possible race condition with batch submission

Can cause race condition issue

gossip blocks

Overview

Currently full nodes are only aware of new blocks upon submission to the hub.

Problem

High latency - if a light client is connected to a non-sequencer full node, it will only get a tx response when a batch is submitted which causes a huge tx response time for light clients connected to non-sequencer full node.
DDOS vector - For a sentry architecture (for DDOS protection) we will want the ability to position full nodes in a public subnet which communicate with the sequencer over a private connection.

Possible solution

Gossip the block and its commit before writing the batch to the hub.

Pros

1. Reduce load from the sequencer both in check tx validation time and num of connections.
2. Support for sentry architecture.

Cons

1. Higher tx latency. Especially if multiple hops are involved.
2. Require more validation strategies and possible rollback as the full nodes are updated with blocks in an optimistic way (and not directly from the hub).

Current assumption

All gossiped blocks are valid (i.e trusted sequencer)

TODO

Handle the case where the blocks gossiped are different then the block registered on the DA

Disclaimer

There are multiple ways to mitigate DDOS attacks and maintain a high SLA. The decisions on which route to take are the responsibility of the sequencer operator and they will be slashed for downtime. We want to make sure though we provide the sequencer operator with a flexible DDOS strategy by allowing block gossiping.

Dependencies

• #156
• #157
• #159
• #158

Change sync mechanism to work with events emitted from the SL

Currently the sync mechanism naively relies on the success on each tx broadcasted without verifying it.
Change it to wait for an event from the SL.

sending tx to SL fails with address prefix error

Fix block times: save times in nanoseconds instead of seconds

clean up unnecessary files from repo

Block processing should use storage atomically

Currently ApplyBlock, SaveBlock, Commit and SaveBlockResponses are executed as completely separate operations - this potentially leads to inconsistencies in database.

Ideally all those operations should use single KV batch to ensure atomicity.

Support block batching for writing to the DA and the settlement layer

Overview

Batch write to the DA and after to the settlement. In case the DA write succeeds but the settlement fails, we will retry the entire flow. The source of truth is the settlement so we don't care about the extra data written to the DA.

We will only be able to write to the settlement if we are synced and assuming it's our turn as decided by the SL.
The current batch size can be determined by comparing local height to syncTarget which should reflect the current height on the SL.
Upon successful submission we can update the syncTarget manually.

Depends on

• #15
• #32
• #21
• #26
• #13

Support persistent store in the SL mock

Currently we only support in memory store for the SL mock.
This causes the need to delete the data dir after every local run.
Add support for persistent store.

Create integration tests infrastructure between the SL and dymint

Change the RPC endpoints to be compatible with our light client

Use dymension cosmosclient

Create a benchmarking tool

Use tendermint benchmarking tools and change them to work with dymint

Clean tests and move common code to test util

• Move common code to testutil
• Make sure every test does one thing and all boilerplate code is extracted
• Make sure test package names are unified by the convention '_test'

add a manager method for submitting new batch to the settlement

Get specific batch at state index missing rollapp id param

Remove headers gossiping

Currently it's unnecessary as the sync happens through the SL.
We will gossiping of blocks/headers data down the road for optimization of sync.

Change blocks sync mechanism to be from the settlement layer (and not from the DA)

Overview

We need to change our basic mechanism of syncing to use the settlement layer as the source of truth of which blocks to fetch from the DA vs syncing all the blocks (not just the ORU's) from the DA as currently happens. Below is the basic flow as I see it.

Basic flow

Syncing

1. Run a loop which constantly tries to sync blocks Until it reaches `syncTarget`
    1. Loop gets its `syncTarget` from settlement layer events.
    2. Every interval call `GetLatestBatch`
3. When current block height ≥ `syncTarget` Change `isSync=true`
4. If it’s the node turn to be an aggregator and `isSync=false` , need to wait until `isSync=true` before start producing.

Retrieving

 1. Retrieving of blocks will be done from the DA.  
 3. Optimization: gossip blocks to peers for faster sync 

Depends on

• #15

Optimization

• #12

Create a benchmarking script to generate result matrix

Overview

Create a script to run the benchmarking tool with different parameters and upload the generated results to the repo

Some parameters to play with

1. machine type
2. tx broadcast type
3. num connections
4. tx load
5. different dymint block times
6. transactions size

Required result

At the end we would like to receive a matrix which includes the different params and the TPS and latency from each param setup.

generic handling of events by type

Currently the SL dymension client to have a generic handling of events by type (currently supporting only one type)

Add code coverage

Overview

Currently code coverage is not enforced either in pre-commit hook or in the CI level.

• Add code coverage enforcement to pre-hook
• Add code coverage enforcement to the CI

Add telemetry for monitoring node activity

Write relevant metrics which can then be used by node operators for monitoring and getting alerts on the node activity. Reference could be taken from tendermint monitoring.

TODO: define the relevant metrics

Import the relevant proto file from dymension repo instead importing the module

Overview

Currently we're importing the dymension module in order to use the relevant types for sending transactions.
This creates unnecessary coupling and was created as a quick solution instead of importing the proto file which required a different grpc module for generating the the relevant structures.

create RPC client for sending state update to the SL

Write events from settlement layer to event bus

We would like to consume the settlement events in the manager and act upon it.

Add docs directory with relevant ADRS

Add a polygon avail DA client

Block syncTarget initialized in a wrong way

Refactor and improve the CI pipeline

Fix rpc commit message: empty height should returns the latest height

Create a docker compose for running a rollapp network

Overview

For testing purposes, we want an easy way to start a rollapp network with multiple peers where currently one is pre-selected to be the aggregator/sequencer and the rest are non-aggregator nodes syncing from the sequencer.

Better enforcement on dymint flags

Currently some flags are required but are not enforced.
Moreover some should be set with sane defaults.
The purpose of this task is to improve the general experience of running the dymint node using the CLI.

Change references from optimint to dymint

The code contains a lot of references to optimint.
Change it to dymint and remove irrelevant docs and materials which doesn't apply to dymint.

Enhance the RPC client for subscribing to events from the settlement layer

Create a way to run dymint in a standalone mode

Overview

Currently dymint needs to be ran as part of cosmos-sdk app.
For better testing and benchmarking abilities, we would like to have the ability to run dymint as a standalone using a kvstore embedded app, similarly to what tendermint offers.

Clean up code

• Move common testing functionalities and structs to testutils package
• Create constants/types for repeating variables
• enforce DRY where possible
• Make sure all packages are blackbox tested