Alternative to ETCD - POC

[anandrgitnirman]

Do a quick POC to have an alternatiive storage for channel state , we are looking at redis / cockraoch DB . We are also looking at making the Daemon even more generic to support an alternate storage

[stellarspot]

There is a description why ETCD has been chosen as the payment channel data storage:
https://github.com/singnet/wiki/blob/master/payment-channel/PaymentChannelStorage.md

The main idea was the data storage for payment channel need to satisfy Consistency requirements in CAP theorem.

What side of the CAP theorem does Redis satisfy?

The quick search gave me a link www.credera.com

Redis Cluster was designed as a general solution for high availability and horizontal scalability for all users of the database. As such, it was designed from the ground up with the major value additions to Redis in mind: performance and a strong data model. Because of this, Redis Cluster implements neither true availability nor consistency of the CAP theorem.

[astroseger]

@anandrgitnirman Why ETCD is a problem?

The architecture of current system is based on assumption that storage has strong consistency. If we use storage without strong consistency then we open ourselves to different kinds of attacks and troubles (the simplest problem --- cluster partition). It seems you cannot solve these problems without strong consistency.

[anandrgitnirman]

@astroseger , As a platform we are looking at enabling other Storage systems, giving the service provider more flexibility , this excercise is only a POC to see how compatible we are to allow for different storages ( Agree , there needs to be strong consistency) .

[anandrgitnirman]

There is a description why ETCD has been chosen as the payment channel data storage:
https://github.com/singnet/wiki/blob/master/payment-channel/PaymentChannelStorage.md

The main idea was the data storage for payment channel need to satisfy Consistency requirements in CAP theorem.

What side of the CAP theorem does Redis satisfy?

The quick search gave me a link www.credera.com

Redis Cluster was designed as a general solution for high availability and horizontal scalability for all users of the database. As such, it was designed from the ground up with the major value additions to Redis in mind: performance and a strong data model. Because of this, Redis Cluster implements neither true availability nor consistency of the CAP theorem.

hi @stellarspot , thanks for Sharing all the details , I have changed the description , goal is to also see how easy it is to on board a new DB ( totally agree with you and @astroseger ) that we need to strong consistency

[vsbogd]

Different service providers may have different requirements on performance and availability. Some of them may even not need distributed databases. And using another db instead of ETCD may significantly simplify setup for them. So adding different db integrations to daemon makes sense.